Correction Re: Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, reset failed
Hi, I previously wrote this issue was fixed by upgrading to 2.6.23.1 There were some mails on this list regarding a workaround for an Asic bug and of course I'm looking forward to trying it :-) Anyway here goes for completeness: * 2.6.23.1 completed dd-stress tests as described earlier (these same tests would always make 2.6.22.9 fail before completing even a single run) * after 21 days and 8 hours normal operation, one sata channel froze while doing checkarray with the following dmesg output (only md/sata stuff - rest deleted): 01:06:02 kernel: [1843824.893109] md: data-check of RAID array md0 01:06:02 kernel: [1843824.893117] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. 01:06:02 kernel: [1843824.893121] md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for data-check. 01:06:02 kernel: [1843824.893126] md: using 128k window, over a total of 488386496 blocks. 01:06:02 mdadm: RebuildStarted event detected on md device /dev/md0 01:15:30 kernel: [1844393.053517] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x138 action 0x2 frozen 01:15:30 kernel: [1844393.053533] ata1.00: cmd 25/00:00:00:1e:e6/00:04:01:00:00/e0 tag 0 cdb 0x0 data 524288 in 01:15:30 kernel: [1844393.053535] res 40/00:28:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout) 01:15:35 kernel: [1844398.420543] ata1: port is slow to respond, please be patient (Status 0xff) 01:15:40 kernel: [1844403.098409] ata1: device not ready (errno=-16), forcing hardreset 01:15:40 kernel: [1844403.098420] ata1: hard resetting port 01:15:46 kernel: [1844408.645861] ata1: port is slow to respond, please be patient (Status 0xff) 01:15:50 kernel: [1844413.144653] ata1: COMRESET failed (errno=-16) 01:15:50 kernel: [1844413.144663] ata1: hard resetting port 01:15:56 kernel: [1844418.691270] ata1: port is slow to respond, please be patient (Status 0xff) 01:16:00 kernel: [1844423.189228] ata1: COMRESET failed (errno=-16) 01:16:00 kernel: [1844423.189237] ata1: hard resetting port 01:16:06 kernel: [1844428.736687] ata1: port is slow to respond, please be patient (Status 0xff) 01:16:35 kernel: [1844458.193217] ata1: COMRESET failed (errno=-16) 01:16:35 kernel: [1844458.193228] ata1: limiting SATA link speed to 1.5 Gbps 01:16:35 kernel: [1844458.193231] ata1: hard resetting port 01:16:40 kernel: [1844463.201458] ata1: COMRESET failed (errno=-16) 01:16:40 kernel: [1844463.201468] ata1: reset failed, giving up 01:16:40 kernel: [1844463.201472] ata1.00: disabled 01:16:40 kernel: [1844463.201483] ata1: EH pending after completion, repeating EH (cnt=4) 01:16:40 kernel: [1844463.201491] ata1: exception Emask 0x10 SAct 0x0 SErr 0x1390002 action 0x2 frozen 01:16:40 kernel: [1844463.201495] ata1: hotplug_status 0x80 01:16:40 kernel: [1844463.201506] ata1: hard resetting port 01:16:46 kernel: [1844469.148300] ata1: port is slow to respond, please be patient (Status 0xff) 01:16:50 kernel: [1844473.226345] ata1: COMRESET failed (errno=-16) 01:16:50 kernel: [1844473.226355] ata1: hard resetting port 01:16:56 kernel: [1844479.173709] ata1: port is slow to respond, please be patient (Status 0xff) 01:17:00 kernel: [1844483.252279] ata1: COMRESET failed (errno=-16) 01:17:00 kernel: [1844483.252289] ata1: hard resetting port 01:17:06 kernel: [1844489.199287] ata1: port is slow to respond, please be patient (Status 0xff) 01:17:35 kernel: [1844518.245767] ata1: COMRESET failed (errno=-16) 01:17:35 kernel: [1844518.245778] ata1: limiting SATA link speed to 1.5 Gbps 01:17:35 kernel: [1844518.245782] ata1: hard resetting port 01:17:40 kernel: [1844523.293460] ata1: COMRESET failed (errno=-16) 01:17:40 kernel: [1844523.293469] ata1: reset failed, giving up 01:17:40 kernel: [1844523.293476] ata1: EH pending after completion, repeating EH (cnt=3) 01:17:40 kernel: [1844523.293485] ata1: exception Emask 0x10 SAct 0x0 SErr 0x1390002 action 0x2 frozen 01:17:40 kernel: [1844523.293488] ata1: hotplug_status 0x80 01:17:40 kernel: [1844523.293500] ata1: hard resetting port 01:17:46 kernel: [1844529.240746] ata1: port is slow to respond, please be patient (Status 0xff) 01:17:50 kernel: [1844533.319339] ata1: COMRESET failed (errno=-16) 01:17:50 kernel: [1844533.319349] ata1: hard resetting port 01:17:56 kernel: [1844539.266172] ata1: port is slow to respond, please be patient (Status 0xff) 01:18:00 kernel: [1844543.344817] ata1: COMRESET failed (errno=-16) 01:18:00 kernel: [1844543.344827] ata1: hard resetting port 01:18:06 kernel: [1844549.291715] ata1: port is slow to respond, please be patient (Status 0xff) 01:18:35 kernel: [1844578.338834] ata1: COMRESET failed (errno=-16) 01:18:35 kernel: [1844578.338846] ata1: limiting SATA link speed to 1.5 Gbps 01:18:35 kernel: [1844578.338849] ata1: hard resetting port 01:18:41 kernel: [1844583.385996] ata1: COMRESET failed (errno=-16) 01:18:41 kernel: [1844583.386006] ata1: reset failed, giving up 01:18:41 kernel: [1844583.386012] ata1: EH pending after completion, repeating
Re: Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, reset failed
On Sun, 14 Oct 2007 11:21:13 +0200, Peter Favrholdt wrote: The problem is solved in 2.6.23.1 regarding the port slow to respond issue. I'm using sata_promise on Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives. Using 2.6.23.1 it is possible to run 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 And it just runs perfectly to the end with no hickups :-) That's very good to hear. However, I don't see how the sata_promise changes from 2.6.22 to 2.6.23 can explain this. The only functional changes there are a critical fix for FastTrack TX4200 (not your card), and support for SATA hotplugging (not happening here). So I'm suspecting something in libata core might have changed to fix this. Just to make sure, what's the numerical PCI IDs for your card? (No big deal, but I'd like to know what the error was.) /Mikael - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, reset failed
Hi Mikael Pettersson wrote: However, I don't see how the sata_promise changes from 2.6.22 to 2.6.23 can explain this. The only functional changes there are a critical fix for FastTrack TX4200 (not your card), and support for SATA hotplugging (not happening here). So I'm suspecting something in libata core might have changed to fix this. Just to make sure, what's the numerical PCI IDs for your card? 01:08.0 0180: 105a:3d17 (rev 02) Subsystem: 105a:3d17 Flags: bus master, 66MHz, medium devsel, latency 72, IRQ 19 I/O ports at a400 [size=128] I/O ports at a800 [size=256] Memory at e9024000 (32-bit, non-prefetchable) [size=4K] Memory at e900 (32-bit, non-prefetchable) [size=128K] [virtual] Expansion ROM at 300a [disabled] [size=32K] Capabilities: [60] Power Management version 2 Best regards, Peter - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug is fixed in 2.6.23.1: sata_promise: port is slow to respond, reset failed
Hi, The problem is solved in 2.6.23.1 regarding the port slow to respond issue. I'm using sata_promise on Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) and 4 Seagate 500GB ES drives. Using 2.6.23.1 it is possible to run 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 And it just runs perfectly to the end with no hickups :-) Thank you very much :-) Best regards, Peter Peter Favrholdt wrote: 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 0x138 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 0x irq 19 [ 27.612274] ata2: SATA max UDMA/133 cmd 0xe0814280 ctl 0xe08142b8 bmdma 0x irq 19 [ 27.612334] ata3: SATA max UDMA/133 cmd 0xe0814200 ctl 0xe0814238 bmdma 0x irq 19 [ 27.612394] ata4: SATA max UDMA/133 cmd 0xe0814300 ctl 0xe0814338 bmdma 0x 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
Re: sata_promise: port is slow to respond, reset failed
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? ... :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) :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: 79XT-PIC-XTtimer 1: 2XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 5: 141710XT-PIC-XTsk98lin 6: 5XT-PIC-XTfloppy 7: 35XT-PIC-XTparport0 8: 1XT-PIC-XTrtc 9: 6XT-PIC-XTacpi, ehci_hcd:usb1, ohci1394 10: 0XT-PIC-XTMPU401 UART 11: 27474XT-PIC-XTlibata, libata, ohci_hcd:usb3, NVidia nForce2 12: 15057XT-PIC-XTohci_hcd:usb2 14: 23211XT-PIC-XTide0 15: 32805XT-PIC-XTide1 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 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_promise: port is slow to respond, reset failed
Mikael Pettersson wrote: nForce2. Hmm.. Peter Favrholdt wrote: 11: 27474XT-PIC-XTlibata, 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 :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: :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 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_promise: port is slow to respond, reset failed
Peter Favrholdt writes: Mikael Pettersson wrote: nForce2. Hmm.. Peter Favrholdt wrote: 11: 27474XT-PIC-XTlibata, 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 :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: :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 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_promise: port is slow to respond, reset failed
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 -- - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sata_promise: port is slow to respond, reset failed
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 0x138 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 0x irq 19 [ 27.612274] ata2: SATA max UDMA/133 cmd 0xe0814280 ctl 0xe08142b8 bmdma 0x irq 19 [ 27.612334] ata3: SATA max UDMA/133 cmd 0xe0814200 ctl 0xe0814238 bmdma 0x irq 19 [ 27.612394] ata4: SATA max UDMA/133 cmd 0xe0814300 ctl 0xe0814338 bmdma 0x 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
Re: sata_promise: port is slow to respond, reset failed
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 0x138 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 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_promise: port is slow to respond, reset failed
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 0x138 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 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_promise: port is slow to respond, reset failed
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 :02:06.0: version 1.04 ACPI: PCI Interrupt :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 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
