Re: 2.6.24.X: SATA/AHCI related boot delay. - not with 2.6.24.3

[Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>]

On Donnerstag, 3. April 2008, Tejun Heo wrote:
> Hello, Volker.
>
> Volker Armin Hemmann wrote:
> >>> In short, no changes at all.
> >>
> >> Thanks for confirming.
> >>
> >> Peer, Kuan.  Volker is reporting detection problems on MCP65 AHCI.
> >> The followings are what we've discovered till now.
> >>
> >> 1. When the controller is put into non-raid mode in BIOS
> >>
> >>   * If softreset is used, either the softreset itself or IDENTIFY
> >>     following it times out once.  On retrial, it works fine.  It
> >>     doesn't matter whether the SRST is issued by itself or as
> >>     follow-up-srst after hardreset.  Using only hardreset works fine.
> >>
> >>   * The controller doesn't indicate MSI capability and MSI isn't used
> >>     by default.
> >>
> >> 2. When the controller is put into ahci mode in BIOS
> >>
> >>   * SRST works fine.
> >>
> >>   * The controller indicates MSI capability but MSI doesn't work
> >>     properly resulting in IRQ delivery failure.  Adding
> >>     intx_disable_bug quirk doesn't help.
> >>
> >> I've performed similar test on MCP67 and everything worked fine on it.
> >>
> >> Both problems (SRST and MSI) can be worked around but I need more
> >> information to work around those.
> >>
> >> * Which chips are affected?  Are there proper fixes?
> >>
> >> * For the MSI problem, is it system wide problem or local to the ahci
> >>   controller?
> >
> > I rebooted with non-raid set, without pci=nomsi
> >
> > this is cat /proc/interrupts:
> >           CPU0       CPU1
> >   0:         57          1   IO-APIC-edge      timer
> >   1:          0         81   IO-APIC-edge      i8042
> >   8:          0          1   IO-APIC-edge      rtc
> >   9:          0          1   IO-APIC-fasteoi   acpi
> >  12:          0          3   IO-APIC-edge      i8042
> >  17:          2       2868   IO-APIC-fasteoi   nvidia
> >  18:          0          0   IO-APIC-fasteoi   EMU10K1
> >  22:          4        745   IO-APIC-fasteoi   ehci_hcd:usb1
> > 314:          0        158   PCI-MSI-edge      eth0
> > 315:          7      12769   PCI-MSI-edge      ahci
> >
> > as you can see, only the sata controller and the network uses msi.
> >
> > And networking works - or I wouldn't be able to send you this mail.
>
> I guess the ahci controller works too.  This is getting confusing, so
> MSI doesn't work iff the controller is configured as ahci in BIOS?

that is correct, if I set it to 'ahci' in bios, no interrupts are delivered.

>From systemrescuecd, ahci in bios, no nomsi:
           CPU0       CPU1       
  0:        147          1   IO-APIC-edge      timer
  1:          0        607   IO-APIC-edge      i8042
  8:          0         61   IO-APIC-edge      rtc
  9:          0          1   IO-APIC-fasteoi   acpi
 12:          0          4   IO-APIC-edge      i8042
 14:          0          0   IO-APIC-edge      libata
 15:          0          0   IO-APIC-edge      libata
 18:          0         16   IO-APIC-fasteoi   aic7xxx
 21:          0          0   IO-APIC-fasteoi   ohci_hcd:usb2
 22:          2       8428   IO-APIC-fasteoi   ehci_hcd:usb1
1274:          0          0   PCI-MSI-edge      ahci
1275:          0        222   PCI-MSI-edge      eth0
NMI:          0          0   Non-maskable interrupts
LOC:      14777      16785   Local timer interrupts
RES:       7250       6100   Rescheduling interrupts
CAL:         41         52   function call interrupts
TLB:       1866       1876   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
SPU:          0          0   Spurious interrupts
ERR:          6

With my 'own' kernel, AHCI has interrupt 315. I will try and make a more 
monolithic kernel so I might be able to boot from a usb-flash device.
.
.
.
which didn't work. Hm, I am too stupid for that today...


>
> > I will reboot from systemresucecd later today and post some results with
> > ahci-mode set, no nomsi. Just can't try patches that way.
>
> Is sytemrescuecd using the same kernel?  Otherwise, it will only add
> more to the confusion.

almost.  A heavily patched 2.6.24.2. That is why I don't sent a dmesg ... just 
cat /proc/interrupts. I can send you lspci -vv and dmesg from systemrescuecd 
if you want.

Glueck Auf,
Volker