Hello, Chris.
Chris Boot wrote:
On 12 Aug 2005, at 15:08, Tejun Heo wrote:
[adding cc to Jeff Garzik. (Hi!)]
Hi again, Chris.
Unfortunately, I'm as lost as you are. Can you please do the
followings?
* Verify if read is free from the problem. ie. does "dd if=/dev/ sd?
of=/dev/null" work?
Works like a treat at 30 MB/s. I do get a few errors in the log
(repeated a couple of times), but they seem mostly harmless:
ata1: status=0x51 { DriveReady SeekComplete Error }
ata1: error=0x04 { DriveStatusError }
This is IDE ABRT error and it indicates that something strange is
going on. You're not getting this kind of error on VIA controller, right?
* Turn on ATA_DEBUG and ATA_VERBOSE_DEBUG in include/linux/ libata.h
(change #undef's to #define's) and make the drive hang. The log
should show what was going on.
While untarring and compiling the new kernel I got lots of:
ata1: status=0x51 { DriveReady SeekComplete Error }
ata1: error=0x84 { DriveStatusError BadCRC }
Wow, this is CRC error. Something is wrong w/ your controller.
Syslog seems to die log before I get anything useful, and setting
loglevel 9 with SysRq gives:
ata_fill_sg: PRD[126]: 0x1206A000, 0x1000)
ata_fill_sg: PRD[127]: 0x1206B000, 0x1000)
ata_dev_select: ENTER, ata1: device 0, wait 1
ATA: abnormal status 0xD9 on port 0xE0804087
ATA: abnormal status 0xD9 on port 0xE0804087
ata_tf_load_mmio: hob: feat 0x0 nsect 0x3, lba 0x1 0x0 0x0
ata_tf_load_mmio: feat 0x0 nsect 0xF8 lba 0x1A 0xEF 0x33
ata_tf_load_mmio: device 0xE0
ATA: abnormal statux 0xD9 on port 0xE0804087
ata_exec_command_mmio: ata: cmd 0x35
ata_scsi_translate: EXIT
It then hangs for exactly 30 seconds, and more stuff flies by followed
by much the same messages EXCEPT:
1. There seems to be one less ata_fill_sg line every time, since PRD
[XXX] decrements by one every time.
2. The ata_tf_load_mmio lines give different nsect and lba, the device
stays the same.
30 secs is SCSI command timeout and retrying w/ one less chunk is sd
driver's error recovery behavior.
It seems that a lot of errors occur while bits are going through your
SATA connection. I don't know about Seagate drives, but my Samsung
drive sometimes locks up if it gets weird packets/commands. This might
be also your case. PHY-resetting usually gets the drive back online but
currently libata doesn't do any such error recovery actions. To make
sure that it's because of faulty controller, can you please try the
following?
* Monitor how IO goes on the drive in Windows. You can do this by
- Start->Run and enter perfmon.
- After perfmon starts, right click on (heh heh, I guess this is
one of those few times you read this on linux kernel mailing
list) counter list and select add. Add DiskBytes/sec counter of
PhysicalDisk object.
- Adjust scale to 0.0000010. Also, change color to black to make
it stand out.
- start dd.
I think, if the errors are due to hardware error, the perfmon graph
will show some stuttering when it hits command timeout. So, write to
disk, as writing seems to cause timeouts. If the problem also happens
on Windows, it's highly likely that you have a faulty controller.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |