ahci: AHCI and RAID mode SATA patch for Intel Cougar Point DeviceIDs
in [Kernel]
|
From: Robert Hancock on 13 Jan 2010 19:00 On Wed, Jan 13, 2010 at 12:18 PM, Krzysztof Halasa <khc(a)pm.waw.pl> wrote: > Jeff Garzik <jgarzik(a)pobox.com> writes: > >> I'm not sure I understand your point. �Are there ahci problems with >> the generic entries, that remain unresolved? > > It seems JMB363 on MSI Neo2 motherboard (P45 + ICH10R) still doesn't > work correctly, flooding the kernel logs. No SATA devices connected, > a CD-ROM connected to PATA (and it works fine). I've sent a report to > the IDE �list some time ago, please let me know if you need more details > or testing etc. > > JMB363 set in BIOS setup to non-RAID mode (it seems this means disabling > the JMB BIOS). Last tested with 2.6.32.1 x86-64 SMP. IRQ 16 is shared. > > Currently the IRQ in PCI registers is 10 (JMB363 SATA is not handled), > I can enable and check again if needed. > > 02:00.0 SATA controller: JMicron Technologies, Inc. 20360/20363 Serial ATA Controller (rev 03) (prog-if 01 [AHCI 1.0]) > � � � �Subsystem: Micro-Star International Co., Ltd. Device 7512 > � � � �Control: I/O+ Mem+ BusMaster+ the_rest- > � � � �Status: Cap+ the_rest- > � � � �Latency: 0, Cache Line Size: 32 bytes > � � � �Interrupt: pin A routed to IRQ 10 > � � � �Region 5: Memory at fe9fe000 (32-bit, non-prefetchable) [size=8K] > � � � �Capabilities: <access denied> > > ahci 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > ahci 0000:02:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode > ahci 0000:02:00.0: flags: 64bit ncq pm led clo pmp pio slum part > ahci 0000:02:00.0: setting latency timer to 64 > scsi6 : ahci > scsi7 : ahci > ata7: SATA max UDMA/133 abar m8192(a)0xfe9fe000 port 0xfe9fe100 irq 16 > ata8: SATA max UDMA/133 abar m8192(a)0xfe9fe000 port 0xfe9fe180 irq 16 > ata8: SATA link down (SStatus 0 SControl 300) > ata7: SATA link down (SStatus 0 SControl 300) > > then every few seconds (ata8 only, nothing on ata7): > > ata8: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen > ata8: irq_stat 0x00000040, connection status changed > ata8: SError: { CommWake DevExch } > ata8: hard resetting link > ata8: SATA link down (SStatus 0 SControl 300) > ata8: EH complete That would seem like a board-specific problem, as I have an Asus P7P55D PRO board with the same JMicron controller and I don't see any such errors. The JMicron BIOS isn't enabled. The behavior here is strange, the controller reports a connection status change interrupt with CommWake which should indicate that some device completed the handshake with the controller, but then the SATA link shows down. I assume there's nothing plugged into the two JMicron SATA ports? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 13 Jan 2010 19:10 On Wed, Jan 13, 2010 at 9:43 AM, Heasley, Seth <seth.heasley(a)intel.com> wrote: >>> * some of lines of Intel chips do not separate AHCI into a separate PCI >>> ID rather legacy IDE interface. �When an AHCI interface exists and >>> AHCI/IDE share the same PCI ID, we default to using AHCI. �Thus, some of >>> those PCI ID matches in ahci.c's PCI table may not get caught by the >>> generic PCI class match at the end of the table. >>> >>> * the cost carrying redundant PCI IDs seems low, harmless, and >>> potentially helpful. >> >>It is helpful for the specific device IDs to show up in "modinfo ahci" and >>modules.pcimap. >> >>David > > This is the reason I was asked to start adding the AHCI DeviceIDs here. I'm not sure why exactly that is useful - or at least why it's useful enough to be worth the effort of patching the kernel for every new AHCI controller that gets released.. I looked at what the Windows msahci driver is doing, they're not listing any specific device IDs at all, they're just using the class code matching only. (Of course, they don't have to worry about devices in RAID mode, as those have to use vendor-specific drivers..) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 13 Jan 2010 19:20 On Wed, Jan 13, 2010 at 5:11 AM, Jeff Garzik <jgarzik(a)pobox.com> wrote: >> Likely a lot of the existing specific PCI IDs could be removed from the >> driver because of this (many likely predate the addition of the >> class-based catch-all). The only reason to need a specific entry if the >> device uses AHCI class is if it needs special handling or workarounds, >> which isn't the case here. > > Well, two lines of thinking here: > > * some of lines of Intel chips do not separate AHCI into a separate PCI ID > rather legacy IDE interface. �When an AHCI interface exists and AHCI/IDE > share the same PCI ID, we default to using AHCI. �Thus, some of those PCI ID > matches in ahci.c's PCI table may not get caught by the generic PCI class > match at the end of the table. Well, ata_piix does have a couple of entries that are listed in ahci as well, for ICH6 device IDs 0x2652 and 0x2653. For 0x2653 ata_piix checks the class code to make sure it's IDE, but for the 0x2652 entry, and in both cases in ahci, the class code isn't checked. Deleting the specific entries from ahci for those controllers would seemingly actually improve the situation, since then ahci wouldn't try and attach to those devices when they indicate IDE class. ata_piix should also should be checking for IDE class on 0x2652 as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 13 Jan 2010 19:50 On Wed, Jan 13, 2010 at 6:11 PM, Robert Hancock <hancockrwd(a)gmail.com> wrote: > On Wed, Jan 13, 2010 at 5:11 AM, Jeff Garzik <jgarzik(a)pobox.com> wrote: >>> Likely a lot of the existing specific PCI IDs could be removed from the >>> driver because of this (many likely predate the addition of the >>> class-based catch-all). The only reason to need a specific entry if the >>> device uses AHCI class is if it needs special handling or workarounds, >>> which isn't the case here. >> >> Well, two lines of thinking here: >> >> * some of lines of Intel chips do not separate AHCI into a separate PCI ID >> rather legacy IDE interface. �When an AHCI interface exists and AHCI/IDE >> share the same PCI ID, we default to using AHCI. �Thus, some of those PCI ID >> matches in ahci.c's PCI table may not get caught by the generic PCI class >> match at the end of the table. > > Well, ata_piix does have a couple of entries that are listed in ahci > as well, for ICH6 device IDs 0x2652 and 0x2653. For 0x2653 ata_piix > checks the class code to make sure it's IDE, but for the 0x2652 entry, > and in both cases in ahci, the class code isn't checked. Deleting the > specific entries from ahci for those controllers would seemingly > actually improve the situation, since then ahci wouldn't try and > attach to those devices when they indicate IDE class. ata_piix should > also should be checking for IDE class on 0x2652 as well. Hmm, it seems like it's a bit more complicated than that. For ICH6R (0x2652), ata_piix attaches to it regardless of mode intentionally, it has specific logic to disable AHCI on the controller since it can be used in either mode. That seems a bit questionable. Having the same device being handled by different enabled drivers and depending on link or module load order to decide which one loads is fragile and prone to errors. I'd be in favor of removing the ICH6R support from ata_piix entirely and saying that you should be using ahci for that device. Maybe when ahci was immature there was a benefit to allowing ata_piix to run it, but I doubt that's true today. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 14 Jan 2010 19:20
On Thu, Jan 14, 2010 at 2:11 PM, Henrique de Moraes Holschuh <hmh(a)hmh.eng.br> wrote: > On Wed, 13 Jan 2010, Robert Hancock wrote: >> Hmm, it seems like it's a bit more complicated than that. For ICH6R >> (0x2652), ata_piix attaches to it regardless of mode intentionally, it >> has specific logic to disable AHCI on the controller since it can be >> used in either mode. That seems a bit questionable. Having the same >> device being handled by different enabled drivers and depending on >> link or module load order to decide which one loads is fragile and >> prone to errors. I'd be in favor of removing the ICH6R support from >> ata_piix entirely and saying that you should be using ahci for that >> device. Maybe when ahci was immature there was a benefit to allowing >> ata_piix to run it, but I doubt that's true today. > > Maybe it is the silicon AHCI in ICH6R that is immature, and one is much > better of using it in IDE mode? That seems unlikely, since the Intel-provided Matrix Storage drivers for that controller on Windows will be using AHCI mode.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |