FreeBSD 4.9 RCx and the ICH5 SATA controller

[Dan Strick]

On Mon, Sep 29, 2003 at 11:01:27PM -0700, Dan Strick wrote:
> The 4.9-20030914-PRERELEASE GENERIC kernel also hangs if the ICH5R SATA
> controller is enabled in native mode, though not at the same point.
> It wedges when the controller is first probed.

On Tue, 30 Sep, 2003 at 09:49:33 -0700, Murray Stokely wrote:
> I'm waiting to hear back from Soeren about the SATA issues, but I
> suspect we'll have to update the hardware/release notes to specify
> that legacy mode must be used.  I've added this to our known issues
> list for 4.9.


I mostly (somewhat?) understand the problem now.  If the ICH5 SATA
controller (PCI device 31, function 2) is configured to operate in
"native" mode, it may generate an apparently spurious interrupt
request which is not released when the ATA controller command block
status register is read in ata_intr() in dev/ata/ata-all.c.
Then the OS gets stuck fielding a never ending stream of interrupts
when it first enables interrupts in function configure() in
i386/i386/autoconf.c.

I can't find this explained (or even merely stated) in the Intel
"data sheet" for the ICH5 or in any other documentation, but the
SATA controller in the ICH5 apparently won't release the interrupt
request until the driver also clears the interrupt bit (bit 2) in
the status register in the Bus Master control block.

The most appropriate place to do this seems to be in the chiptype
switch in function ata_pci_intr() in dev/ata/ata-pci.c.  The code
used for the HighPoint chips might work, but the Intel data sheet
for the ICH5 shows some bits in the status register that would
apparently be cleared by the HighPoint code but should possibly
be left untouched for the ICH5 SATA controller.  I created a new
switch section:

    case 0x24d18086:    /* Intel ICH5 SATA150 */
        dmastat = ATA_INB(ch->r_bmio, ATA_BMSTAT_PORT);
        if ((dmastat & (ATA_BMSTAT_ACTIVE|ATA_BMSTAT_INTERRUPT))
                != ATA_BMSTAT_INTERRUPT)
                        return 1;
        ATA_OUTB(ch->r_bmio, ATA_BMSTAT_PORT, dmastat & 0x7c);
        DELAY(1);
        return 0;

This addition to dev/ata/ata-pci.c is apparently enough to allow the
ICH5 SATA controller to function properly, but there are a few other
changes that ought to be made to the ATA driver.

In function ata_pci_match() also in dev/ata/ata-pci.c, I added this
code:

    case 0x24d18086:
        return "Intel ICH5 SATA150 controller";

just below the case for the "ICH5 ATA100" controller (but see caveat
below).  This apparently affects only the kernel auto-configuration
monologue and not the operation of the driver.

In function ata_dmainit() in dev/ata/ata-dma.c, I added this code:

    case 0x24d18086:    /* Intel ICH5 sata */

to the chiptype switch just before the 0x24db8086 case for the plain
ICH5 (non SATA) driver.  This might be to be needed to allow the the
controller to do DMA.  (I am not certain the default case will do the
right thing.)  The test for the 80 conductor cable immediately before
the switch is not appropriate for the ICH5 SATA controller, but
probably does no permanent harm since the controller is alleged to
know better and operate in SATA150 mode even if the OS tries to
configure the device for ATA33, ATA66, or ATA100 mode.

One last little caveat: when the SATA controller is configured by the
BIOS to operate in "legacy" mode, the ICH5 apparently stops reporting
its standard PATA controller (device id 0x24db) in the PCI configuration
space.  Instead it reports only the SATA controller (device id 0x24d1)
and pretends that both SATA devices are on the same SATA port.
Any devices attached to the PATA port that is not displaced by this
SATA port are reported on the other SATA port.  This might confuse the
driver.  The driver might refuse to operate both SATA disks at the same
time and it might think that the PATA devices are on a high speed SATA
cable even if they are on a low speed 40 conductor PATA cable.

For these reasons and because operation in legacy mode disables a PATA
port (which may be very precious because PCI ATA cards tend not to fully
support ATAPI devices) and because the ICH5 ATA controllers do not
compete for external PCI bus bandwidth, I think it would be really nice
if release 4.9 permitted the ICH5 SATA controller to operate in native
mode.  Note that if release 4.9 crashes when it sees a native mode ICH5
SATA controller, you can't use native mode with other smarter operating
systems (e.g. release 5.1) that multiboot on the same system.

Dan Strick
strick at covad.net