[Bug 266845] New: SATA port fails to respond, status 0xd0
https://bugzilla.novell.com/show_bug.cgi?id=266845 Summary: SATA port fails to respond, status 0xd0 Product: openSUSE 10.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: volker3204@paradise.net.nz QAContact: qa@suse.de This (probably kernel) problem makes this SATA disk basically unusable. A dd bs=1k if=/dev/zero of=/dev/sdb runs without any problems. mkfs.ext3 or mkreiserfs fail, as does dd if=/dev/zero bs=1k of=/dev/sdb1 oflag=direct count=100 The disk access locks up for a while, as do any programs accessing it. It always recovers, after a 30s timeout each time. Kernel: 2.6.18.8-0.1-default #1 SMP Fri Mar 2 13:51:59 UTC 2007 x86_64 Sequence of commands, and their result, after a reboot: dd if=/dev/zero bs=1k of=/dev/sdb seek=100 oflag=direct count=100 Apr 21 22:03:31 linux kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 21 22:03:31 linux kernel: ata3.00: cmd ca/00:02:55:01:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 1024 out Apr 21 22:03:31 linux kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 21 22:03:38 linux kernel: ata3: port is slow to respond, please be patient (Status 0xd0) Apr 21 22:04:01 linux kernel: ata3: port failed to respond (30 secs, Status 0xd0) Apr 21 22:04:01 linux kernel: ata3: soft resetting port Apr 21 22:04:02 linux kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 21 22:04:02 linux kernel: ata3.00: configured for UDMA/100 Apr 21 22:04:02 linux kernel: ata3: EH complete Apr 21 22:04:02 linux kernel: SCSI device sdb: 78140160 512-byte hdwr sectors (40008 MB) Apr 21 22:04:02 linux kernel: sdb: Write Protect is off Apr 21 22:04:02 linux kernel: sdb: Mode Sense: 00 3a 00 00 Apr 21 22:04:02 linux kernel: SCSI device sdb: drive cache: write back dd if=/dev/zero bs=1k of=/dev/sdb1 seek=100 count=100 No problems. dd if=/dev/zero bs=1k of=/dev/sdb1 seek=100 oflag=direct count=100 No problems any more now either, repeatedly. dd if=/dev/zero bs=1k of=/dev/sdb1 seek=1000 oflag=direct count=10000 No problems. mkreiserfs /dev/sdb1 Apr 21 22:06:37 linux kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 21 22:06:37 linux kernel: ata3.00: cmd ca/00:08:3f:00:9c/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out Apr 21 22:06:37 linux kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 21 22:06:45 linux kernel: ata3: port is slow to respond, please be patient (Status 0xd0) Apr 21 22:07:08 linux kernel: ata3: port failed to respond (30 secs, Status 0xd0) Apr 21 22:07:08 linux kernel: ata3: soft resetting port Apr 21 22:07:08 linux kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 21 22:07:08 linux kernel: ata3.00: configured for UDMA/100 Apr 21 22:07:08 linux kernel: ata3: EH complete Apr 21 22:07:08 linux kernel: SCSI device sdb: 78140160 512-byte hdwr sectors (40008 MB) Apr 21 22:07:08 linux kernel: sdb: Write Protect is off Apr 21 22:07:08 linux kernel: sdb: Mode Sense: 00 3a 00 00 Apr 21 22:07:08 linux kernel: SCSI device sdb: drive cache: write back Apr 21 22:08:08 linux kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 21 22:08:08 linux kernel: ata3.00: cmd ca/00:08:3f:00:38/00:00:00:00:00/e1 tag 0 cdb 0x0 data 4096 out Apr 21 22:08:08 linux kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 21 22:08:16 linux kernel: ata3: port is slow to respond, please be patient (Status 0xd0) Apr 21 22:08:39 linux kernel: ata3: port failed to respond (30 secs, Status 0xd0) Apr 21 22:08:39 linux kernel: ata3: soft resetting port Apr 21 22:08:39 linux kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 21 22:08:39 linux kernel: ata3.00: configured for UDMA/100 Apr 21 22:08:39 linux kernel: ata3: EH complete Apr 21 22:08:39 linux kernel: SCSI device sdb: 78140160 512-byte hdwr sectors (40008 MB) Apr 21 22:08:39 linux kernel: sdb: Write Protect is off Apr 21 22:08:39 linux kernel: sdb: Mode Sense: 00 3a 00 00 Apr 21 22:08:39 linux kernel: SCSI device sdb: drive cache: write back Apr 21 22:09:39 linux kernel: ata3.00: limiting speed to UDMA/66 Apr 21 22:09:39 linux kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 21 22:09:39 linux kernel: ata3.00: cmd ca/00:08:3f:00:d4/00:00:00:00:00/e1 tag 0 cdb 0x0 data 4096 out Apr 21 22:09:39 linux kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 21 22:09:47 linux kernel: ata3: port is slow to respond, please be patient (Status 0xd0) Apr 21 22:10:10 linux kernel: ata3: port failed to respond (30 secs, Status 0xd0) Apr 21 22:10:10 linux kernel: ata3: soft resetting port Apr 21 22:10:10 linux kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 21 22:10:10 linux kernel: ata3.00: configured for UDMA/66 Apr 21 22:10:10 linux kernel: ata3: EH complete Apr 21 22:10:10 linux kernel: SCSI device sdb: 78140160 512-byte hdwr sectors (40008 MB) Apr 21 22:10:10 linux kernel: sdb: Write Protect is off Apr 21 22:10:10 linux kernel: sdb: Mode Sense: 00 3a 00 00 Apr 21 22:10:10 linux kernel: SCSI device sdb: drive cache: write back Apr 21 22:11:10 linux kernel: ata3.00: limiting speed to UDMA/44 [and so on] Disk details, 2.5" laptop: Model Family: Hitachi Travelstar 5K100 series Device Model: HTS541040G9SA00 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 945 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 9 Power_On_Hours 0x0012 099 099 000 Old_age Always - 824 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 114 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 4 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 9844 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 0 # 1 Extended offline Completed without error 00% 805 - The disk was unused when I got it, but it was showing 802 power on hours. It shows no signs of any defect. Its SATA speed is 1.5Gbps. I tried different cables and mobo port. Given that the disk works fine without the oflag=direct (or equivalent) I don't see how it can be a faulty disk. A 3.5" Samsung SP2504C SATA disk in the same system hasn't shown any problem ever, in 16 months use time. Mobo chipset is nforce4, with integrated SATA controller. This problem is similar to #244612, but that was for status 0xff and I have 0xd0. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #1 from volker3204@paradise.net.nz 2007-04-21 05:23 MST ------- lspci identifies the disk adapters as: 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) kernel module sata_nv. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #2 from volker3204@paradise.net.nz 2007-04-21 18:56 MST ------- The disk and the cabling pass the advanced Hitachi diagnostics with 0 errors or warnings. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #3 from volker3204@paradise.net.nz 2007-04-24 06:54 MST ------- Same problem when the disk is connected through a USB-IDE/SATA adapter. The disk is recognised correctly as a USB mass storage device. Writing with dd over the whole disk sequentially through this adapter gives no problems, mkfs reiser or ext2 causes the kernel (or the adapter?) to take the disk offline. Disk is supplied through separate power adapter. I took disk, adapter, power adapter and the same cables to a box running XP SP2, no problems at all. Can't connect disk directly due to lack of SATA interface. So, the disk and cables are fine, but the Linux kernel doesn't talk to this disk at least through an nforce4 chipset, although a Samsung SP2504C SATA disk w same kernel + chipset are fine. The problem with the Hitachi SATA disk persists even when going through a USB-SATA adapter. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 teheo@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |volker3204@paradise.net.nz ------- Comment #5 from teheo@novell.com 2007-04-24 07:41 MST ------- It looks like a faulty disk to me. The disk probably chokes when data transfer is larger than certain size. With O_DIRECT, you're limiting each request to 1k and some room to breathe between commands. Without it, kernel will coalesce the sequential workload (both dd and mkfs) requests into the maximum allowed request size to achieve better performance. Windows is probably dodging the bullet because it's using a lower limit. You can adjust the parameter by writing to /sys/block/sdb/queue/max_sectors_kb. Half the size till you don't see the errors. Considering this is the first such error report on the disk, I don't think the whole line is faulty (in which case, it needs to be blacklisted). Please verify lowering max_sectors_kb fixes your problem. If it does, I would send it for RMA. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #6 from volker3204@paradise.net.nz 2007-04-24 15:13 MST ------- A full-disk overwrite with dd and without direct also works fine, wouldn't that use max transfer size? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 volker3204@paradise.net.nz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|volker3204@paradise.net.nz | ------- Comment #7 from volker3204@paradise.net.nz 2007-04-24 19:08 MST ------- Disk connected to mobo SATA plug (nforce4 chipset). Lowest value for /sys/block/sdb/queue/max_sectors_kb is 4, set to 4. mkfs trips the error. After a clean reboot, dd bs=1k count=10000 reading sdb3 is fine, writing zeros produces Apr 25 12:55:03 linux kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 25 12:55:03 linux kernel: ata2.00: cmd ca/00:08:a8:17:71/00:00:00:00:00/e2 tag 0 cdb 0x0 data 4096 out Apr 25 12:55:03 linux kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 25 12:55:10 linux kernel: ata2: port is slow to respond, please be patient (Status 0xd0) Apr 25 12:55:33 linux kernel: ata2: port failed to respond (30 secs, Status 0xd0) Apr 25 12:55:33 linux kernel: ata2: soft resetting port Apr 25 12:55:33 linux kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 25 12:55:33 linux kernel: ata2.00: configured for UDMA/100 Apr 25 12:55:33 linux kernel: ata2: EH complete Apr 25 12:55:33 linux kernel: SCSI device sdb: 78140160 512-byte hdwr sectors (40008 MB) Apr 25 12:55:33 linux kernel: sdb: Write Protect is off Apr 25 12:55:33 linux kernel: sdb: Mode Sense: 00 3a 00 00 Apr 25 12:55:33 linux kernel: SCSI device sdb: drive cache: write back So not even writing with dd works reliably. Connecting this disk through a SATA/USB adapter of unknown chipset (and reboot) and reducing max_sectors_kb for that USB drive to 4 also produces errors and the USB disk is taken offline by the kernel. I conclude it's not a max transfer size issue. RMA'ing a disk which according to the manufacturer's test is not faulty and which works fine on XP without installing any drivers could be difficult. With a sample of 1 disk it looks like a kernel bug to me. The disk has been lying around for >1year after purchase, so is unused but not hot off the factory. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 teheo@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |volker3204@paradise.net.nz ------- Comment #8 from teheo@novell.com 2007-04-24 20:33 MST ------- I see. The reason why I think it isn't a kernel bug is that it shows the same problem even when connected to USB converter. If you connect the harddisk that way, all the converter chip does all the ATA handling and just exposes logical USB disk interface. So, there's no kernel ATA code involved when you use the disk that way and it's very difficult for any non-ATA kernel code to trigger such symptom - they just do the logical part - 'read this', 'write that'. Does things change if you use different source data when writing? ie. Does using a video file as source instead of /dev/null make any difference? You can prevent the difference between reading actual file and /dev/null from affecting the result by creating zero filled source file - e.g. dd if=/dev/zero of=testsrc0 bs=1M count=64. Please repeat test several times. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 volker3204@paradise.net.nz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|volker3204@paradise.net.nz | ------- Comment #9 from volker3204@paradise.net.nz 2007-04-24 23:23 MST ------- Tried only with the USB converter, first time my explicit sync caused the disk to go offline. Rebooted, the implicit kernel buffer flush gives same result. Writing a 64MB file isn't possible. That's tested with a vfat partition previously created with XP, since I can't get mkfs to put a filesystem on the disk. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 teheo@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 teheo@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |volker3204@paradise.net.nz ------- Comment #10 from teheo@novell.com 2007-04-24 23:28 MST ------- Thanks. So, it's not a transmission error triggered by corner case bit pattern. Can you post /var/log/boot.msg and the result of 'hwinfo --all'? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #11 from volker3204@paradise.net.nz 2007-04-25 01:09 MST ------- Created an attachment (id=133962) --> (https://bugzilla.novell.com/attachment.cgi?id=133962&action=view) boot.msg -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 volker3204@paradise.net.nz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|volker3204@paradise.net.nz | ------- Comment #12 from volker3204@paradise.net.nz 2007-04-25 01:09 MST ------- Created an attachment (id=133963) --> (https://bugzilla.novell.com/attachment.cgi?id=133963&action=view) hwinfo-all -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #13 from volker3204@paradise.net.nz 2007-04-25 01:14 MST ------- SATA disk with USB adapter on openSUSE 10.2 32bit box - same problem, dd 100MByte write fails. The USB adapter has an IDE interface as well as a SATA one, and a Travelstar 40GB IDE 2.5" disk works fine. I'll check for firmware updates with Hitachi. Thanks Tejun! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #14 from volker3204@paradise.net.nz 2007-05-01 15:32 MST ------- Tried cooling the disk, no difference. Ran Hitachi's disk exerciser/advanced test 14 times (all night), no errors found (disk connected to SATA mobo). Tried Knoppix 4.0.2 Linux Knoppix 2.6.12 #2 SMP Tue Aug 9 23:20:52 CEST 2005 i686 GNU/Linux running on AMD64 with SATA connection to mobo. mkfs causes some dmesg error but completes without failure. Writing 100MB zeros works, writing 1GB zeros gives EXT3 FS on sdb3, internal journal EXT3-fs: mounted filesystem with ordered data mode. ata2: command 0x35 timeout, stat 0xd0 host_stat 0x20 ata2: status=0xd0 { Busy } SCSI error : <1 0 0 0> return code = 0x8000002 sdb: Current: sense key=0xb ASC=0x47 ASCQ=0x0 end_request: I/O error, dev sdb, sector 42854622 Buffer I/O error on device sdb3, logical block 236109 lost page write due to I/O error on sdb3 ATA: abnormal status 0xD0 on port 0x977 ATA: abnormal status 0xD0 on port 0x977 ATA: abnormal status 0xD0 on port 0x977 This disk doesn't work under Linux (this particular one anyway), and the manufacturer can't find anything wrong with it. :( -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #15 from teheo@novell.com 2007-05-02 03:55 MST ------- Hmmm... It could be that you aren't noticing the problem because windows is using much shorter timeout (reportedly 7 secs) but then the test tool should have detected something. Hmmm... I'm still inclined toward the misbehaving disk theory but have no idea how to further diagnose this. Ho hum. :-( -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #16 from volker3204@paradise.net.nz 2007-05-04 19:24 MST ------- Copying 1GB of files from this SATA disk w USB adapter back to the disk (different directory) on XP happens repeatedly with no trouble, and at 23MB/s (2GB transfer, 1GB reading, 1GB writing). P4 2.6GHz, HP job, not the newest. Obviously M$ is driving this disk differently than Linux. On SuSE 9.3, P4 1.6GHz box, Compaq job, this SATA disk with USE adapter crawls at 1.1MB/s but appears to work. mkfs -text3 or -text2 complete eventually, copying a 96MB file from disk to disk again works too. There was never any warning/error in dmesg or syslog for the whole of this test. 100MB of dd write work too. Using subfs. On 10.2 AMD64, if the fs is already on disk, writing a 100MB file to the fs works fine, but at 430kbyte/s, it's mounted sync by auto-whichever. Reading 1GB with dd is ok. Unmounting and manually mounting without sync, writing a 10MB file with dd hangs immediately I type sync. So it's a kernel problem; no reason to assume any of the HW involved is faulty. However, Hitachi has replied with some info re this disk's firmware being possibly out of the ordinary. Before I post details I want to follow up on a few more things. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 teheo@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |volker3204@paradise.net.nz ------- Comment #17 from teheo@novell.com 2007-05-06 04:36 MST ------- I see. I'm really out of ideas here. The common base between libata and usb-storage is only the logical part - e.g. issue r/w request of certain size at certain offset and possibly timing. Hmmm... Do you mind taking this bug upstream? If you can verify the problem exists in the current upstream kernel (2.6.21.1 at the moement), I'll gather info from this page and report this to linux ATA devel mailing list and ask whether ATA gurus there can shed some light on this problem. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #18 from volker3204@paradise.net.nz 2007-05-28 04:52 MST ------- Hitachi turned out to be very helpful, and said "According to our record, the drive [serial number] is an OEM category drive. This is a drive specially built for a Japanese system manufacturer and firmware is specifically geared to, qualified and approved by that system manufacturer.". The drive was purchased by itself as a single item from a computer shop in New Zealand (probably in Christchurch). Unfortunately I have been unable to trace the drive back to its supplier (I'll spare the details). I can't even say who the supplier was. Darn, but it's out of my control. I'll test the drive on 10.3a4 soon. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #19 from volker3204@paradise.net.nz 2007-05-28 05:53 MST ------- 10.3a4 has 2.6.21-8-default. At first that worked much better, but eventually I/O errors knock the disk out too. syslog: May 28 23:40:40 linux hald: mounted /dev/sdb1 on behalf of uid 1000 May 28 23:40:42 linux hald: mounted /dev/sdb2 on behalf of uid 1000 May 28 23:40:42 linux hald: mounted /dev/sdb3 on behalf of uid 1000 May 28 23:44:35 linux kernel: usb 4-1: reset high speed USB device using ehci_hcd and address 102 May 28 23:44:35 linux kernel: usb 4-1: device descriptor read/64, error -71 May 28 23:44:35 linux kernel: usb 4-1: device descriptor read/64, error -71 May 28 23:44:36 linux kernel: usb 4-1: USB disconnect, address 102 May 28 23:44:36 linux kernel: sd 8:0:0:0: scsi: Device offlined - not ready after error recovery May 28 23:44:36 linux kernel: sd 8:0:0:0: SCSI error: return code = 0x00010000 May 28 23:44:36 linux kernel: end_request: I/O error, dev sdb, sector 36473659 May 28 23:44:36 linux kernel: Buffer I/O error on device sdb2, logical block 1998848 May 28 23:44:36 linux kernel: lost page write due to I/O error on sdb2 Given that this disk likely has dubious firmware, is it worth persuing further? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845 ------- Comment #20 from teheo@novell.com 2007-06-04 00:58 MST ------- Sorry about delay, have been traveling. Let's take this upstream. Can you compile vanilla kernel and verify the problem still exists (it most likely would)? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=266845#c21
Tejun Heo
participants (1)
-
bugzilla_noreply＠novell.com