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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
