sata_promise: port is slow to respond, reset failed

sata_promise: port is slow to respond, reset failed

[Peter Favrholdt]

Hi,

I'm still experiencing the same "port is slow to respond" problem using 
sata_promise in linux-2.6.22.6 with my Promise Technology, Inc. PDC40718 
(SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives:
         Model Number:       ST3500630NS
         Firmware Revision:  3.AEE
         (with 1.5/3.0Gbps jumper removed = 3.0Gbps)

After doing:

dd if=/dev/sda of=/dev/null bs=1M &
dd if=/dev/sdb of=/dev/null bs=1M &
dd if=/dev/sdc of=/dev/null bs=1M &
dd if=/dev/sdd of=/dev/null bs=1M &

it runs fine for a while, then:

[  810.545909] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x1380000 
action 0x2 frozen
[  810.545923] ata1.00: cmd c8/00:00:00:33:e6/00:00:00:00:00/e1 tag 0 
cdb 0x0 data 131072 in
[  810.545926]          res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 
0x4 (timeout)
[  815.913113] ata1: port is slow to respond, please be patient (Status 
0xff)
[  820.590706] ata1: device not ready (errno=-16), forcing hardreset
[  820.590716] ata1: hard resetting port
[  826.137780] ata1: port is slow to respond, please be patient (Status 
0xff)
[  830.635488] ata1: COMRESET failed (errno=-16)
[  830.635497] ata1: hard resetting port
[  836.182563] ata1: port is slow to respond, please be patient (Status 
0xff)
[  840.680236] ata1: COMRESET failed (errno=-16)
[  840.680245] ata1: hard resetting port
[  846.227361] ata1: port is slow to respond, please be patient (Status 
0xff)
[  875.672028] ata1: COMRESET failed (errno=-16)
[  875.672037] ata1: limiting SATA link speed to 1.5 Gbps
[  875.672041] ata1: hard resetting port
[  880.679454] ata1: COMRESET failed (errno=-16)
[  880.679463] ata1: reset failed, giving up
[  880.679466] ata1.00: disabled
[  880.679480] ata1: EH complete
[  880.679545] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[  880.679550] end_request: I/O error, dev sda, sector 31863552
[  880.679555] Buffer I/O error on device sda, logical block 3982944
[  880.679561] Buffer I/O error on device sda, logical block 3982945
[  880.679565] Buffer I/O error on device sda, logical block 3982946
[  880.679569] Buffer I/O error on device sda, logical block 3982947
[  880.679573] Buffer I/O error on device sda, logical block 3982948
[  880.679578] Buffer I/O error on device sda, logical block 3982949
[  880.679582] Buffer I/O error on device sda, logical block 3982950
[  880.679586] Buffer I/O error on device sda, logical block 3982951
[  880.679590] Buffer I/O error on device sda, logical block 3982952
[  880.679594] Buffer I/O error on device sda, logical block 3982953
[  880.680296] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[  880.680301] end_request: I/O error, dev sda, sector 31863808
[  880.680877] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[  880.680882] end_request: I/O error, dev sda, sector 31863552
[  880.681383] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
[  880.681388] end_request: I/O error, dev sda, sector 31863552

The "funny" thing is that it runs fine using linux-2.6.21-rc2 with 
Mikael Pettersson's "1.5Gbps only" patch.

I have replaced the cables without any change. I'm quite sure this isn't 
a hardware problem as I have uptime counting in months without any problems.

Here is the relevant part of dmesg (detecting drives):

[   27.612125] scsi3 : sata_promise
[   27.612214] ata1: SATA max UDMA/133 cmd 0xe0814380 ctl 0xe08143b8 
bmdma 0x00000000 irq 19
[   27.612274] ata2: SATA max UDMA/133 cmd 0xe0814280 ctl 0xe08142b8 
bmdma 0x00000000 irq 19
[   27.612334] ata3: SATA max UDMA/133 cmd 0xe0814200 ctl 0xe0814238 
bmdma 0x00000000 irq 19
[   27.612394] ata4: SATA max UDMA/133 cmd 0xe0814300 ctl 0xe0814338 
bmdma 0x00000000 irq 19
[   28.092787] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   28.143577] ata1.00: ATA-7: ST3500630NS, 3.AEE, max UDMA/133
[   28.143626] ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[   28.235153] ata1.00: configured for UDMA/133
[   28.722457] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   28.770752] ata2.00: ATA-7: ST3500630NS, 3.AEE, max UDMA/133
[   28.770800] ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[   28.854011] ata2.00: configured for UDMA/133
[   29.342135] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   29.389819] ata3.00: ATA-7: ST3500630NS, 3.AEE, max UDMA/133
[   29.389867] ata3.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[   29.473081] ata3.00: configured for UDMA/133
[   29.961812] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   30.012878] ata4.00: ATA-7: ST3500630NS, 3.AEE, max UDMA/133
[   30.012926] ata4.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[   30.104452] ata4.00: configured for UDMA/133
[   30.104580] scsi 0:0:0:0: Direct-Access     ATA      ST3500630NS 
  3.AE PQ: 0 ANSI: 5
[   30.104720] sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors 
(500108 MB)
[   30.104780] sd 0:0:0:0: [sda] Write Protect is off
[   30.104827] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   30.104841] sd 0:0:0:0: [sda] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   30.104936] sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors 
(500108 MB)
[   30.104992] sd 0:0:0:0: [sda] Write Protect is off
[   30.105039] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   30.105051] sd 0:0:0:0: [sda] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   30.105110]  sda: unknown partition table
[   30.123283] sd 0:0:0:0: [sda] Attached SCSI disk
[   30.123389] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   30.123494] scsi 1:0:0:0: Direct-Access     ATA      ST3500630NS 
  3.AE PQ: 0 ANSI: 5
[   30.123620] sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors 
(500108 MB)
[   30.123676] sd 1:0:0:0: [sdb] Write Protect is off
[   30.123723] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[   30.123735] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   30.123823] sd 1:0:0:0: [sdb] 976773168 512-byte hardware sectors 
(500108 MB)
[   30.123878] sd 1:0:0:0: [sdb] Write Protect is off
[   30.123925] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[   30.123938] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   30.123997]  sdb: unknown partition table
[   30.142694] sd 1:0:0:0: [sdb] Attached SCSI disk
[   30.142796] sd 1:0:0:0: Attached scsi generic sg1 type 0
[   30.142897] scsi 2:0:0:0: Direct-Access     ATA      ST3500630NS 
  3.AE PQ: 0 ANSI: 5
[   30.143025] sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors 
(500108 MB)
[   30.143080] sd 2:0:0:0: [sdc] Write Protect is off
[   30.143127] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[   30.143140] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   30.143225] sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors 
(500108 MB)
[   30.143279] sd 2:0:0:0: [sdc] Write Protect is off
[   30.143326] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[   30.143339] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   30.143396]  sdc: unknown partition table
[   30.154054] sd 2:0:0:0: [sdc] Attached SCSI disk
[   30.154149] sd 2:0:0:0: Attached scsi generic sg2 type 0
[   30.154257] scsi 3:0:0:0: Direct-Access     ATA      ST3500630NS 
  3.AE PQ: 0 ANSI: 5
[   30.154381] sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors 
(500108 MB)
[   30.154437] sd 3:0:0:0: [sdd] Write Protect is off
[   30.154484] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[   30.154496] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   30.154580] sd 3:0:0:0: [sdd] 976773168 512-byte hardware sectors 
(500108 MB)
[   30.154635] sd 3:0:0:0: [sdd] Write Protect is off
[   30.154682] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[   30.154694] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[   30.154753]  sdd: unknown partition table
[   30.169230] sd 3:0:0:0: [sdd] Attached SCSI disk
[   30.169329] sd 3:0:0:0: Attached scsi generic sg3 type 0

I'll be happy to try any patches/suggestions.

Best regards,

Peter

Re: sata_promise: port is slow to respond, reset failed

[Mikael Pettersson]

On Sun, 02 Sep 2007 13:12:42 +0200, Peter Favrholdt wrote:
> I'm still experiencing the same "port is slow to respond" problem using 
> sata_promise in linux-2.6.22.6 with my Promise Technology, Inc. PDC40718 
> (SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives:
>          Model Number:       ST3500630NS
>          Firmware Revision:  3.AEE
>          (with 1.5/3.0Gbps jumper removed = 3.0Gbps)
> 
> After doing:
> 
> dd if=/dev/sda of=/dev/null bs=1M &
> dd if=/dev/sdb of=/dev/null bs=1M &
> dd if=/dev/sdc of=/dev/null bs=1M &
> dd if=/dev/sdd of=/dev/null bs=1M &
> 
> it runs fine for a while, then:
> 
> [  810.545909] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x1380000 
> action 0x2 frozen
> [  810.545923] ata1.00: cmd c8/00:00:00:33:e6/00:00:00:00:00/e1 tag 0 
> cdb 0x0 data 131072 in
> [  810.545926]          res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 
> 0x4 (timeout)
> [  815.913113] ata1: port is slow to respond, please be patient (Status 
> 0xff)
> [  820.590706] ata1: device not ready (errno=-16), forcing hardreset
> [  820.590716] ata1: hard resetting port
> [  826.137780] ata1: port is slow to respond, please be patient (Status 
> 0xff)
> [  830.635488] ata1: COMRESET failed (errno=-16)
> [  830.635497] ata1: hard resetting port
> [  836.182563] ata1: port is slow to respond, please be patient (Status 
> 0xff)
> [  840.680236] ata1: COMRESET failed (errno=-16)
> [  840.680245] ata1: hard resetting port
> [  846.227361] ata1: port is slow to respond, please be patient (Status 
> 0xff)
> [  875.672028] ata1: COMRESET failed (errno=-16)
> [  875.672037] ata1: limiting SATA link speed to 1.5 Gbps
> [  875.672041] ata1: hard resetting port
> [  880.679454] ata1: COMRESET failed (errno=-16)
> [  880.679463] ata1: reset failed, giving up
> [  880.679466] ata1.00: disabled
> [  880.679480] ata1: EH complete
> [  880.679545] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> [  880.679550] end_request: I/O error, dev sda, sector 31863552
> [  880.679555] Buffer I/O error on device sda, logical block 3982944
> [  880.679561] Buffer I/O error on device sda, logical block 3982945
> [  880.679565] Buffer I/O error on device sda, logical block 3982946
> [  880.679569] Buffer I/O error on device sda, logical block 3982947
> [  880.679573] Buffer I/O error on device sda, logical block 3982948
> [  880.679578] Buffer I/O error on device sda, logical block 3982949
> [  880.679582] Buffer I/O error on device sda, logical block 3982950
> [  880.679586] Buffer I/O error on device sda, logical block 3982951
> [  880.679590] Buffer I/O error on device sda, logical block 3982952
> [  880.679594] Buffer I/O error on device sda, logical block 3982953
> [  880.680296] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> [  880.680301] end_request: I/O error, dev sda, sector 31863808
> [  880.680877] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> [  880.680882] end_request: I/O error, dev sda, sector 31863552
> [  880.681383] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> [  880.681388] end_request: I/O error, dev sda, sector 31863552
> 
> The "funny" thing is that it runs fine using linux-2.6.21-rc2 with 
> Mikael Pettersson's "1.5Gbps only" patch.

Hmm, obviously a fatal problem, but not one I've seen before or
have an explanation for at this time. We do know however that the
SATA300 chips are prone to have "issues" especially in 3Gbps mode.

A couple of things you can do:
1. Provide a complete dmesg.
2. Force 1.5Gbps mode, using either jumpers or the driver patch (there's
   one for 2.6.22 in http://user.it.uu.se/~mikpe/linux/patches/2.6/).
3. Try to narrow down where the problem started, i.e., test 2.6.21 final
   and the 2.6.22-rc kernels.

/Mikael

Re: sata_promise: port is slow to respond, reset failed

[Mikael Pettersson]

On Sun, 2 Sep 2007 17:11:36 +0200 (MEST), Mikael Pettersson wrote:
> On Sun, 02 Sep 2007 13:12:42 +0200, Peter Favrholdt wrote:
> > I'm still experiencing the same "port is slow to respond" problem using 
> > sata_promise in linux-2.6.22.6 with my Promise Technology, Inc. PDC40718 
> > (SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives:
> >          Model Number:       ST3500630NS
> >          Firmware Revision:  3.AEE
> >          (with 1.5/3.0Gbps jumper removed = 3.0Gbps)
> > 
> > After doing:
> > 
> > dd if=/dev/sda of=/dev/null bs=1M &
> > dd if=/dev/sdb of=/dev/null bs=1M &
> > dd if=/dev/sdc of=/dev/null bs=1M &
> > dd if=/dev/sdd of=/dev/null bs=1M &
> > 
> > it runs fine for a while, then:
> > 
> > [  810.545909] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x1380000 
> > action 0x2 frozen
> > [  810.545923] ata1.00: cmd c8/00:00:00:33:e6/00:00:00:00:00/e1 tag 0 
> > cdb 0x0 data 131072 in
> > [  810.545926]          res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 
> > 0x4 (timeout)
> > [  815.913113] ata1: port is slow to respond, please be patient (Status 
> > 0xff)
> > [  820.590706] ata1: device not ready (errno=-16), forcing hardreset
> > [  820.590716] ata1: hard resetting port
> > [  826.137780] ata1: port is slow to respond, please be patient (Status 
> > 0xff)
> > [  830.635488] ata1: COMRESET failed (errno=-16)
> > [  830.635497] ata1: hard resetting port
> > [  836.182563] ata1: port is slow to respond, please be patient (Status 
> > 0xff)
> > [  840.680236] ata1: COMRESET failed (errno=-16)
> > [  840.680245] ata1: hard resetting port
> > [  846.227361] ata1: port is slow to respond, please be patient (Status 
> > 0xff)
> > [  875.672028] ata1: COMRESET failed (errno=-16)
> > [  875.672037] ata1: limiting SATA link speed to 1.5 Gbps
> > [  875.672041] ata1: hard resetting port
> > [  880.679454] ata1: COMRESET failed (errno=-16)
> > [  880.679463] ata1: reset failed, giving up
> > [  880.679466] ata1.00: disabled
> > [  880.679480] ata1: EH complete
> > [  880.679545] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > [  880.679550] end_request: I/O error, dev sda, sector 31863552
> > [  880.679555] Buffer I/O error on device sda, logical block 3982944
> > [  880.679561] Buffer I/O error on device sda, logical block 3982945
> > [  880.679565] Buffer I/O error on device sda, logical block 3982946
> > [  880.679569] Buffer I/O error on device sda, logical block 3982947
> > [  880.679573] Buffer I/O error on device sda, logical block 3982948
> > [  880.679578] Buffer I/O error on device sda, logical block 3982949
> > [  880.679582] Buffer I/O error on device sda, logical block 3982950
> > [  880.679586] Buffer I/O error on device sda, logical block 3982951
> > [  880.679590] Buffer I/O error on device sda, logical block 3982952
> > [  880.679594] Buffer I/O error on device sda, logical block 3982953
> > [  880.680296] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > [  880.680301] end_request: I/O error, dev sda, sector 31863808
> > [  880.680877] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > [  880.680882] end_request: I/O error, dev sda, sector 31863552
> > [  880.681383] sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> > [  880.681388] end_request: I/O error, dev sda, sector 31863552
> > 
> > The "funny" thing is that it runs fine using linux-2.6.21-rc2 with 
> > Mikael Pettersson's "1.5Gbps only" patch.
> 
> Hmm, obviously a fatal problem, but not one I've seen before or
> have an explanation for at this time. We do know however that the
> SATA300 chips are prone to have "issues" especially in 3Gbps mode.
> 
> A couple of things you can do:
> 1. Provide a complete dmesg.
> 2. Force 1.5Gbps mode, using either jumpers or the driver patch (there's
>    one for 2.6.22 in http://user.it.uu.se/~mikpe/linux/patches/2.6/).
> 3. Try to narrow down where the problem started, i.e., test 2.6.21 final
>    and the 2.6.22-rc kernels.

I'm easily able to reproduce this problem on my sata_promise test rig.
Using 2.6.23-rc5 to dd read a single Seagate disk on a SATA300 TX4 card
quickly fails as Peter described.

Applying the 1.5Gbps patch to the driver appears to make things stable.

Those SATAII chips really don't seem to like 3Gbps mode. Or else we're
missing some critical documentation on how to make them work.

/Mikael

Re: sata_promise: port is slow to respond, reset failed

[Peter Favrholdt]

Hi Mikael Pettersson wrote:
> I'm easily able to reproduce this problem on my sata_promise test rig.
> Using 2.6.23-rc5 to dd read a single Seagate disk on a SATA300 TX4 card
> quickly fails as Peter described.
> 
> Applying the 1.5Gbps patch to the driver appears to make things stable.
> 
> Those SATAII chips really don't seem to like 3Gbps mode. Or else we're
> missing some critical documentation on how to make them work.

The funny thing is: I have the exact same adapter and disks in a Dell 
PE1800 server. This doesn't show any errors.

Only difference is the card is in a PCI-X slot and the server is running
Linux 2.6.19.5.

dmesg from that box:

sata_promise 0000:02:06.0: version 1.04
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 32 (level, low) -> IRQ 18
ata5: SATA max UDMA/133 cmd 0xF8816200 ctl 0xF8816238 bmdma 0x0 irq 18
ata6: SATA max UDMA/133 cmd 0xF8816280 ctl 0xF88162B8 bmdma 0x0 irq 18
ata7: SATA max UDMA/133 cmd 0xF8816300 ctl 0xF8816338 bmdma 0x0 irq 18
ata8: SATA max UDMA/133 cmd 0xF8816380 ctl 0xF88163B8 bmdma 0x0 irq 18
scsi4 : sata_promise
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata5.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32)
ata5.00: configured for UDMA/133
scsi5 : sata_promise
ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata6.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32)
ata6.00: configured for UDMA/133
scsi6 : sata_promise
ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata7.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32)
ata7.00: configured for UDMA/133
scsi7 : sata_promise
ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata8.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32)
ata8.00: configured for UDMA/133
scsi 4:0:0:0: Direct-Access     ATA      ST3500630NS      3.AE PQ: 0 ANSI: 5
SCSI device sdc: 976773168 512-byte hdwr sectors (500108 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 976773168 512-byte hdwr sectors (500108 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
  sdc: unknown partition table
sd 4:0:0:0: Attached scsi disk sdc
sd 4:0:0:0: Attached scsi generic sg3 type 0
scsi 5:0:0:0: Direct-Access     ATA      ST3500630NS      3.AE PQ: 0 ANSI: 5
SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
  sdd: unknown partition table
sd 5:0:0:0: Attached scsi disk sdd
sd 5:0:0:0: Attached scsi generic sg4 type 0
scsi 6:0:0:0: Direct-Access     ATA      ST3500630NS      3.AE PQ: 0 ANSI: 5
SCSI device sde: 976773168 512-byte hdwr sectors (500108 MB)
sde: Write Protect is off
sde: Mode Sense: 00 3a 00 00
SCSI device sde: drive cache: write back
SCSI device sde: 976773168 512-byte hdwr sectors (500108 MB)
sde: Write Protect is off
sde: Mode Sense: 00 3a 00 00
SCSI device sde: drive cache: write back
  sde: unknown partition table
sd 6:0:0:0: Attached scsi disk sde
sd 6:0:0:0: Attached scsi generic sg5 type 0
scsi 7:0:0:0: Direct-Access     ATA      ST3500630NS      3.AE PQ: 0 ANSI: 5
SCSI device sdf: 976773168 512-byte hdwr sectors (500108 MB)
sdf: Write Protect is off
sdf: Mode Sense: 00 3a 00 00
SCSI device sdf: drive cache: write back
SCSI device sdf: 976773168 512-byte hdwr sectors (500108 MB)
sdf: Write Protect is off
sdf: Mode Sense: 00 3a 00 00
SCSI device sdf: drive cache: write back
  sdf: unknown partition table
sd 7:0:0:0: Attached scsi disk sdf
sd 7:0:0:0: Attached scsi generic sg6 type 0

I'll try to test as Mikael suggested.

Best regards,

Peter

Re: sata_promise: port is slow to respond, reset failed

[Mikael Pettersson]

On Mon, 03 Sep 2007 01:04:08 +0200, Peter Favrholdt wrote:
> Hi Mikael Pettersson wrote:
> > I'm easily able to reproduce this problem on my sata_promise test rig.
> > Using 2.6.23-rc5 to dd read a single Seagate disk on a SATA300 TX4 card
> > quickly fails as Peter described.
> > 
> > Applying the 1.5Gbps patch to the driver appears to make things stable.
> > 
> > Those SATAII chips really don't seem to like 3Gbps mode. Or else we're
> > missing some critical documentation on how to make them work.
> 
> The funny thing is: I have the exact same adapter and disks in a Dell 
> PE1800 server. This doesn't show any errors.
> 
> Only difference is the card is in a PCI-X slot and the server is running
> Linux 2.6.19.5.

I assume the PE1800 has some Intel chipset? Which one?
And the machine that does have problems, what chipset does it have?

I'm actually beginning to think there's some PCI compatibility breakage
somewhere, as I too see sata_promise working fine in some machines but
not in others. Alas, my knowledge of PCI tweakables is close to nil.

/Mikael

Re: sata_promise: port is slow to respond, reset failed

[Tomi Orava]

>> > Those SATAII chips really don't seem to like 3Gbps mode. Or else we're
>> > missing some critical documentation on how to make them work.
>>
>> The funny thing is: I have the exact same adapter and disks in a Dell
>> PE1800 server. This doesn't show any errors.
>>
>> Only difference is the card is in a PCI-X slot and the server is running
>> Linux 2.6.19.5.
>
> I assume the PE1800 has some Intel chipset? Which one?
> And the machine that does have problems, what chipset does it have?

I can verify that at least my Asus A7V880 motherboard which
is based on Amd Athlon (K7) & Via KT880-chipset the Promise Sata 300 TX 4
never worked without problems with high I/O together with Seagate 7200.10
disks.

> I'm actually beginning to think there's some PCI compatibility breakage
> somewhere, as I too see sata_promise working fine in some machines but
> not in others. Alas, my knowledge of PCI tweakables is close to nil.

This would not amaze me at all as there has been more than enough
compatibility problems with certain PCI-cards <-> motherboards in the past
couple of years.

Regards,
Tomi Orava



-- 

Re: sata_promise: port is slow to respond, reset failed

[Peter Favrholdt]

Hi,

Below some more info on my two systems:

Mikael Pettersson wrote:
> I assume the PE1800 has some Intel chipset? Which one?

cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Xeon(TM) CPU 2.80GHz
stepping        : 3
cpu MHz         : 2793.228
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm 
constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips        : 5590.09

(this machine has hyperthreading and SMP enabled - shows up as processor 
#1 but this was left out here)

lspci:
0000:00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 09)
0000:00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express 
Port A0 (rev 09)
0000:00:04.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express 
Port B0 (rev 09)
0000:00:06.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express 
Port C0 (rev 09)
0000:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB 
UHCI #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB 
UHCI #2 (rev 02)
0000:00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB 
UHCI #3 (rev 02)
0000:00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 
EHCI Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge 
(rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra 
ATA 100 Storage Controller (rev 02)
0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 
Storage Controller (rev 02)
0000:01:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09)
0000:01:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09)
0000:02:06.0 Unknown mass storage controller: Promise Technology, Inc.: 
Unknown device 3d17 (rev 02)
0000:03:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit 
Ethernet Controller (rev 05)
0000:06:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
0000:06:05.0 VGA compatible controller: ATI Technologies Inc Radeon 
RV100 QY [Radeon 7000/VE]

cat /proc/interrupts
            CPU0       CPU1
   0:         61 1968626752   IO-APIC-edge      timer
   1:          0        658   IO-APIC-edge      i8042
   6:          0          3   IO-APIC-edge      floppy
   7:          0          0   IO-APIC-edge      parport0
   9:          0          0   IO-APIC-fasteoi   acpi
  12:          0        413   IO-APIC-edge      i8042
  14:          0         16   IO-APIC-edge      libata
  15:          0          0   IO-APIC-edge      libata
  16:          0          0   IO-APIC-fasteoi   uhci_hcd:usb2
  17:          0   48140761   IO-APIC-fasteoi   libata, uhci_hcd:usb4
  18:          0  757251738   IO-APIC-fasteoi   libata
  19:          0          0   IO-APIC-fasteoi   ehci_hcd:usb1
  20:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
  21:          0  606210513   IO-APIC-fasteoi   eth0
  22:          0  154792474   IO-APIC-fasteoi   eth1
NMI:          0          0
LOC: 1968636127 1968636126
ERR:          0
MIS:          0

The promise card has IRQ 18 all by itself

> And the machine that does have problems, what chipset does it have?

cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Athlon(tm) XP 2500+
stepping        : 0
cpu MHz         : 1837.000
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
bogomips        : 3677.78
clflush size    : 32

lspci:
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) 
(rev c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet 
Controller (rev a1)
00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio 
Processing Unit (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 
Audio Controler (MCP) (rev a1)
00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire (IEEE 
1394) Controller (rev a3)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
01:04.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 
Gigabit Ethernet Controller (rev 13)
01:08.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 
300 TX4) (rev 02)
01:0b.0 RAID bus controller: Silicon Image, Inc. SiI 3112 
[SATALink/SATARaid] Serial ATA Controller (rev 02)
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP 
(rev 01)

cat /proc/interrupts
            CPU0
   0:         79    XT-PIC-XT        timer
   1:          2    XT-PIC-XT        i8042
   2:          0    XT-PIC-XT        cascade
   5:     141710    XT-PIC-XT        sk98lin
   6:          5    XT-PIC-XT        floppy
   7:         35    XT-PIC-XT        parport0
   8:          1    XT-PIC-XT        rtc
   9:          6    XT-PIC-XT        acpi, ehci_hcd:usb1, ohci1394
  10:          0    XT-PIC-XT        MPU401 UART
  11:      27474    XT-PIC-XT        libata, libata, ohci_hcd:usb3, 
NVidia nForce2
  12:      15057    XT-PIC-XT        ohci_hcd:usb2
  14:      23211    XT-PIC-XT        ide0
  15:      32805    XT-PIC-XT        ide1
NMI:       3911
LOC:     917176
ERR:          0

The promise card is sharing IRQ11 with usb, the other libata device, and 
nForce2 (wonder what that is?)

> I'm actually beginning to think there's some PCI compatibility breakage
> somewhere, as I too see sata_promise working fine in some machines but
> not in others. Alas, my knowledge of PCI tweakables is close to nil.

I second that (although I'm really clueless about PCI).

Could it be that at 3.0Gbps with 4 ports running at full speed 
contention on the pci bus cause this behavior? This would explain why a 
PCI-X port helps (or limiting to 1.5Gbps). Or maybe it is an NFORCE2 
issue... Or too many IRQ-handlers on the same IRQ...

I wish I could do something more to help. Unfortunately it is almost 
impossible for me to do tests on the Intel system (as it is a production 
system) - though I might be able to try some things late at night in the 
weekends ;-)

Guess at this point it would be nice to be able to reproduce the 
behavior on an Intel system...

Best regards,

Peter

Re: sata_promise: port is slow to respond, reset failed

[Mikael Pettersson]

Peter Favrholdt writes:
 > Hi,
 > 
 > Below some more info on my two systems:
 > 
 > Mikael Pettersson wrote:
 > > I assume the PE1800 has some Intel chipset? Which one?
...
 > 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
 > 0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge 
 > (rev 02)

ICH5. Should be decent enough.

 > > And the machine that does have problems, what chipset does it have?
...
 > 00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)

nForce2. Hmm..

 > cat /proc/interrupts
 >             CPU0
 >    0:         79    XT-PIC-XT        timer
 >    1:          2    XT-PIC-XT        i8042
 >    2:          0    XT-PIC-XT        cascade
 >    5:     141710    XT-PIC-XT        sk98lin
 >    6:          5    XT-PIC-XT        floppy
 >    7:         35    XT-PIC-XT        parport0
 >    8:          1    XT-PIC-XT        rtc
 >    9:          6    XT-PIC-XT        acpi, ehci_hcd:usb1, ohci1394
 >   10:          0    XT-PIC-XT        MPU401 UART
 >   11:      27474    XT-PIC-XT        libata, libata, ohci_hcd:usb3, 
 > NVidia nForce2
 >   12:      15057    XT-PIC-XT        ohci_hcd:usb2
 >   14:      23211    XT-PIC-XT        ide0
 >   15:      32805    XT-PIC-XT        ide1
 > NMI:       3911
 > LOC:     917176
 > ERR:          0
 > 
 > The promise card is sharing IRQ11 with usb, the other libata device, and 
 > nForce2 (wonder what that is?)

That "mystery" device makes me strongly suspect that you've
loaded the binary-only nvidia drivers. If that's true, then
the machine's problems may just as well be caused by that driver,
not sata_promise. (We've seen that happen before.)

 > > I'm actually beginning to think there's some PCI compatibility breakage
 > > somewhere, as I too see sata_promise working fine in some machines but
 > > not in others. Alas, my knowledge of PCI tweakables is close to nil.
 > 
 > I second that (although I'm really clueless about PCI).
 > 
 > Could it be that at 3.0Gbps with 4 ports running at full speed 
 > contention on the pci bus cause this behavior? This would explain why a 
 > PCI-X port helps (or limiting to 1.5Gbps). Or maybe it is an NFORCE2 
 > issue... Or too many IRQ-handlers on the same IRQ...
 > 
 > I wish I could do something more to help. Unfortunately it is almost 
 > impossible for me to do tests on the Intel system (as it is a production 
 > system) - though I might be able to try some things late at night in the 
 > weekends ;-)
 > 
 > Guess at this point it would be nice to be able to reproduce the 
 > behavior on an Intel system...

I can reproduce it on an Intel 440BX chipset machine with a PIII.
However, that chipset, while very good in its day, is rather old now.

I'll run some more tests this weekend on less ancient hardware.

/Mikael

Re: sata_promise: port is slow to respond, reset failed

[Chuck Ebbert]

On 09/03/2007 04:11 AM, Mikael Pettersson wrote:
> On Mon, 03 Sep 2007 01:04:08 +0200, Peter Favrholdt wrote:
>> Hi Mikael Pettersson wrote:
>>> I'm easily able to reproduce this problem on my sata_promise test rig.
>>> Using 2.6.23-rc5 to dd read a single Seagate disk on a SATA300 TX4 card
>>> quickly fails as Peter described.
>>>
>>> Applying the 1.5Gbps patch to the driver appears to make things stable.
>>>
>>> Those SATAII chips really don't seem to like 3Gbps mode. Or else we're
>>> missing some critical documentation on how to make them work.
>> The funny thing is: I have the exact same adapter and disks in a Dell 
>> PE1800 server. This doesn't show any errors.
>>
>> Only difference is the card is in a PCI-X slot and the server is running
>> Linux 2.6.19.5.
> 
> I assume the PE1800 has some Intel chipset? Which one?
> And the machine that does have problems, what chipset does it have?
> 
> I'm actually beginning to think there's some PCI compatibility breakage
> somewhere, as I too see sata_promise working fine in some machines but
> not in others. Alas, my knowledge of PCI tweakables is close to nil.

I am seeing some problems solved by using pci=nomsi and/or pci=nommconf.
We either have a bug in MSI, especially on x86_64, or some chipsets just
don't work very well with it.

Re: sata_promise: port is slow to respond, reset failed

[Peter Favrholdt]

Mikael Pettersson wrote:
> nForce2. Hmm..

Peter Favrholdt wrote:
>  >   11:      27474    XT-PIC-XT        libata, libata, ohci_hcd:usb3, 
>  > NVidia nForce2

> That "mystery" device makes me strongly suspect that you've
> loaded the binary-only nvidia drivers. If that's true, then
> the machine's problems may just as well be caused by that driver,
> not sata_promise. (We've seen that happen before.)

I didn't load any special NVidia driver - vanilla kernel only. The 
graphics card is Matrox G550. The nForce2 could be the nForce2 SMBus or 
the nForce2 IDE. Here is the result of dmesg | grep -i nforce
[   26.379422] NFORCE2: IDE controller at PCI slot 0000:00:09.0
[   26.379481] NFORCE2: chipset revision 162
[   26.379525] NFORCE2: not 100% native mode: will probe irqs later
[   26.379575] NFORCE2: BIOS didn't set cable bits correctly. Enabling 
workaround.
[   26.379634] NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
[   31.861284] i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000
[   31.861391] i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5500

> I can reproduce it on an Intel 440BX chipset machine with a PIII.
> However, that chipset, while very good in its day, is rather old now.

I believe the problem here only shows if all four sata ports are 
stressed simultaneously (I should test this thoroughly). The dependence 
on Barracuda 7200.10 could be because these disks are faster than the 
others tested, this needed in order for the PCI contention to arise? 
(I'm still wild-guessing here).

Best regards,

Peter

Re: sata_promise: port is slow to respond, reset failed

[Mikael Pettersson]

Peter Favrholdt writes:
 > Mikael Pettersson wrote:
 > > nForce2. Hmm..
 > 
 > Peter Favrholdt wrote:
 > >  >   11:      27474    XT-PIC-XT        libata, libata, ohci_hcd:usb3, 
 > >  > NVidia nForce2
 > 
 > > That "mystery" device makes me strongly suspect that you've
 > > loaded the binary-only nvidia drivers. If that's true, then
 > > the machine's problems may just as well be caused by that driver,
 > > not sata_promise. (We've seen that happen before.)
 > 
 > I didn't load any special NVidia driver - vanilla kernel only. The 
 > graphics card is Matrox G550. The nForce2 could be the nForce2 SMBus or 
 > the nForce2 IDE. Here is the result of dmesg | grep -i nforce
 > [   26.379422] NFORCE2: IDE controller at PCI slot 0000:00:09.0
 > [   26.379481] NFORCE2: chipset revision 162
 > [   26.379525] NFORCE2: not 100% native mode: will probe irqs later
 > [   26.379575] NFORCE2: BIOS didn't set cable bits correctly. Enabling 
 > workaround.
 > [   26.379634] NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
 > [   31.861284] i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000
 > [   31.861391] i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5500

OK, sorry about that. The 'NVidia nForce2' string does occur in two
sound drivers, so that may be where it's coming from.

 > > I can reproduce it on an Intel 440BX chipset machine with a PIII.
 > > However, that chipset, while very good in its day, is rather old now.
 > 
 > I believe the problem here only shows if all four sata ports are 
 > stressed simultaneously (I should test this thoroughly). The dependence 
 > on Barracuda 7200.10 could be because these disks are faster than the 
 > others tested, this needed in order for the PCI contention to arise? 
 > (I'm still wild-guessing here).

On my old 440BX reading a single Barracuda (7200.10 or .9 I don't remember)
or Spinpoint disk was enough to trigger the errors.

/Mikael