# ICH8 and Dell Optiplex 745 SATA weirdness [SOLVED]

## Zwartoog

Hi all,

I have installed Gentoo on a Dell Optiplex 745, which uses the Intel ICH8 chipset. This chipset seems to have 6 SATA ports, but Dell only connected ports 0, 1, 4 and 5. So, two ports are not connected, and Dell deceided not to connect the middle 2. Well, it's a Dell, so there should be some queer logic in this.

When I boot the kernel (2.6.18-gentoo-r1) with the ata_piix driver, the kernel tries to detect those two lost ports:

```

libata version 2.00 loaded.

ata_piix 0000:00:1f.2: version 2.00

ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]

GSI 17 sharing vector 0xD1 and IRQ 17

ACPI: PCI Interrupt 0000:00:1f.2[C] -> GSI 20 (level, low) -> IRQ 209

PCI: Setting latency timer of device 0000:00:1f.2 to 64

ata1: SATA max UDMA/133 cmd 0xFE00 ctl 0xFE12 bmdma 0xFEC0 irq 209

ata2: SATA max UDMA/133 cmd 0xFE20 ctl 0xFE32 bmdma 0xFEC8 irq 209

scsi0 : ata_piix

ata1.00: ATA-7, max UDMA/133, 488281250 sectors: LBA48 NCQ (depth 0/32)

ata1.00: ata1: dev 0 multi count 8

ata1.00: configured for UDMA/133

scsi1 : ata_piix

ata2.00: ATA-7, max UDMA/133, 488281250 sectors: LBA48 NCQ (depth 0/32)

ata2.00: ata2: dev 0 multi count 8

ata2.00: configured for UDMA/133

  Vendor: ATA       Model: ST3250824AS       Rev: 3.AD

  Type:   Direct-Access                      ANSI SCSI revision: 05

  Vendor: ATA       Model: ST3250824AS       Rev: 3.AD

  Type:   Direct-Access                      ANSI SCSI revision: 05

ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ]

ACPI: PCI Interrupt 0000:00:1f.5[C] -> GSI 20 (level, low) -> IRQ 209

PCI: Setting latency timer of device 0000:00:1f.5 to 64

ata3: SATA max UDMA/133 cmd 0xFE40 ctl 0xFE52 bmdma 0xFED0 irq 209

ata4: SATA max UDMA/133 cmd 0xFE60 ctl 0xFE72 bmdma 0xFED8 irq 209

scsi2 : ata_piix

ata3.00: ATAPI, max UDMA/100

ata3.00: configured for UDMA/100

scsi3 : ata_piix

ata4: port is slow to respond, please be patient

ata4: port failed to respond (30 secs)

ata4: SRST failed (status 0xFF)

ata4: SRST failed (err_mask=0x100)

ata4: softreset failed, retrying in 5 secs

ata4: SRST failed (status 0xFF)

ata4: SRST failed (err_mask=0x100)

ata4: softreset failed, retrying in 5 secs

ata4: SRST failed (status 0xFF)

ata4: SRST failed (err_mask=0x100)

ata4: reset failed, giving up

  Vendor: PHILIPS   Model: DVD-ROM DROM6316  Rev: OD2F

  Type:   CD-ROM                             ANSI SCSI revision: 05

SCSI device sda: 488281250 512-byte hdwr sectors (250000 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

SCSI device sda: 488281250 512-byte hdwr sectors (250000 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

 sda: sda1 sda2 sda3 sda4

sd 0:0:0:0: Attached scsi disk sda

SCSI device sdb: 488281250 512-byte hdwr sectors (250000 MB)

sdb: Write Protect is off

sdb: Mode Sense: 00 3a 00 00

SCSI device sdb: drive cache: write back

SCSI device sdb: 488281250 512-byte hdwr sectors (250000 MB)

sdb: Write Protect is off

sdb: Mode Sense: 00 3a 00 00

SCSI device sdb: drive cache: write back

 sdb: sdb1

sd 1:0:0:0: Attached scsi disk sdb

sr0: scsi3-mmc drive: 0x/48x cd/rw xa/form2 cdda tray

Uniform CD-ROM driver Revision: 3.20

sr 2:0:0:0: Attached scsi CD-ROM sr0

```

Also (for other people trying to install Gentoo on these computers), it was impossible to boot with the 2006.1 amd64 live CD right away: I had to disconnect the second HD and connect the SATA CDrom there, otherwise the livecd did not detect the CDrom drive. I am not sure if I really needed the sata legacy modus in the BIOS.

It poses no real problem, the kernel is just slow to boot. So, two questions:

1) can I tell the kernel to skip detection of the 3rd and 4th SATA ports, without kernel hacking?

2) does anyone have any idea why Dell skips the middle two ports and not the last two for example, or just leave the two ports out entirely?

Thanks in advance,

Zwartoog

----------

## RazielFMX

I have this problem as well, and only became a problem when I upgraded to the gentoo 2.6.18-r2 kernel.  My 2.6.17-r8 was fine.

For me, it's ata2, my chipset is ICH7, on a DELL Optiplex GX620.  My arch is amd64.

----------

## Zwartoog

I have been looking more closely into it now, and it does not seem to have anything to do with the two unconnected SATA ports. To me it looks more like a `bug' in the driver, and your response seems to confirm that. Unfortunately, my knowlegde about driverprogramming is not that great, so I cannot do anything about it myself, unfortunately   :Sad: 

----------

## RazielFMX

I was about to post the same.  My debugging led to SATA ports with nothing attached!  And like you, driver programming isn't my cup of tea.

----------

## geo-r-gis

Just another confirmation.

I have the same problem with similar hardware as RazielFMX:

DELL Optiplex GX620, chipset  ICH7, problem is also reported for ata2.

I'm running both, the amd64 and x86 archives (on different partitions).

For both archives kernel 2.6.17-r8 was fine, but kernel 2.6.18-r2 boot 

up is delayed by about 30 seconds, until "ata2: reset failed, giving up"

according to log/dmesg.

----------

## Kovid

I have the same problem on a SATA enabled dell dimension 4700 (~x86 ata2)

----------

## Jimmers

Add another.  Using an Intel i955x chipset mobo.  You guys say 2.6.17 works?

EDIT:  Has anyone filed a bug?

----------

## Zwartoog

 *Quote:*   

> Add another. Using an Intel i955x chipset mobo. You guys say 2.6.17 works? 

 

2.6.17 does not work for ICH8.

 *Quote:*   

> EDIT: Has anyone filed a bug?

 

Did not really come to that at the time being. However, there has been a discussion about this on the LKML:

http://marc.theaimsgroup.com/?l=linux-ide&m=115959283527628&w=2

And the patch has been applied for upstream (2.6.19 probably):

http://article.gmane.org/gmane.linux.ide/13408

Anyway, here is the patch, which now patches seamlessly in 2.6.18-gentoo-r1:

```

--- linuxorg/drivers/scsi/libata-core.c 2006-12-06 15:30:33.000000000 +0100

+++ linux/drivers/scsi/libata-core.c    2006-12-06 15:48:11.000000000 +0100

@@ -2271,11 +2271,14 @@

  *     Sleep until ATA Status register bit BSY clears,

  *     or a timeout occurs.

  *

- *     LOCKING: None.

+ *     LOCKING:

+ *     Kernel thread context (may sleep).

+ *

+ *     RETURNS:

+ *     0 on success, -errno otherwise.

  */

-

-unsigned int ata_busy_sleep (struct ata_port *ap,

-                            unsigned long tmout_pat, unsigned long tmout)

+int ata_busy_sleep(struct ata_port *ap,

+                  unsigned long tmout_pat, unsigned long tmout)

 {

        unsigned long timer_start, timeout;

        u8 status;

@@ -2283,25 +2286,29 @@

        status = ata_busy_wait(ap, ATA_BUSY, 300);

        timer_start = jiffies;

        timeout = timer_start + tmout_pat;

-       while ((status & ATA_BUSY) && (time_before(jiffies, timeout))) {

+        while (status != 0xff && (status & ATA_BUSY) &&

+               time_before(jiffies, timeout)) {

                msleep(50);

                status = ata_busy_wait(ap, ATA_BUSY, 3);

        }

-       if (status & ATA_BUSY)

+        if (status != 0xff && (status & ATA_BUSY))

                ata_port_printk(ap, KERN_WARNING,

                                "port is slow to respond, please be patient\n");

        timeout = timer_start + tmout;

-       while ((status & ATA_BUSY) && (time_before(jiffies, timeout))) {

-               msleep(50);

+       while (status != 0xff && (status & ATA_BUSY) &&

+              time_before(jiffies, timeout)) {

                status = ata_chk_status(ap);

        }

+        if (status == 0xff)

+               return -ENODEV;

+

        if (status & ATA_BUSY) {

                ata_port_printk(ap, KERN_ERR, "port failed to respond "

                                "(%lu secs)\n", tmout / HZ);

-               return 1;

+               return -EBUSY;

        }

        return 0;

@@ -2392,10 +2399,8 @@

         * the bus shows 0xFF because the odd clown forgets the D7

         * pulldown resistor.

         */

-       if (ata_check_status(ap) == 0xFF) {

-               ata_port_printk(ap, KERN_ERR, "SRST failed (status 0xFF)\n");

-               return AC_ERR_OTHER;

-       }

+        if (ata_check_status(ap) == 0xFF)

+               return 0;

        ata_bus_post_reset(ap, devmask);

--- linuxorg/include/linux/libata.h     2006-12-06 15:30:39.000000000 +0100

+++ linux/include/linux/libata.h        2006-12-06 15:38:59.000000000 +0100

@@ -703,9 +703,8 @@

                                pm_message_t mesg);

 extern void ata_host_set_resume(struct ata_host_set *host_set);

 extern int ata_ratelimit(void);

-extern unsigned int ata_busy_sleep(struct ata_port *ap,

-                                  unsigned long timeout_pat,

-                                  unsigned long timeout);

+extern int ata_busy_sleep(struct ata_port *ap,

+                         unsigned long timeout_pat, unsigned long timeout);

 extern void ata_port_queue_task(struct ata_port *ap, void (*fn)(void *),

                                void *data, unsigned long delay);

 extern u32 ata_wait_register(void __iomem *reg, u32 mask, u32 val,

@@ -1020,8 +1019,7 @@

                udelay(10);

                status = ata_chk_status(ap);

                max--;

-       } while ((status & bits) && (max > 0));

-

+        } while (status != 0xff && (status & bits) && (max > 0));

        return status;

 }

@@ -1041,7 +1039,7 @@

 {

        u8 status = ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 1000);

-       if (status & (ATA_BUSY | ATA_DRQ)) {

+       if (status != 0xff && (status & (ATA_BUSY | ATA_DRQ))) {

                unsigned long l = ap->ioaddr.status_addr;

                if (ata_msg_warn(ap))

                        printk(KERN_WARNING "ATA: abnormal status 0x%X on port 0x%lX\n",

```

Works for me  :Smile: 

----------

## stupidkid

So how do we apply the patch? Just replace the libata-core.c file with that?

I have this problem too with Optiplex GX280 and ICH6W.

----------

## Zwartoog

 *Quote:*   

> So how do we apply the patch? Just replace the libata-core.c file with that? 

 

As with any kernel patch:

```

# cd /usr/src/linux

# patch -p1 < /path/to/libata.patch

```

Then recompile your kernel.

----------

## Zwartoog

Patched in gentoo-sources-2.6.19-r2 and propably in 2.6.18-r5 soon.

----------

