On 13 Aug 2005, at 2:13, Tejun Heo wrote:
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?
I most certainly am not.
* 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.
Great...
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.
Some interesting developments!
I installed a fresh copy of Windows, and all the VIA and nVidia and
so on drivers. At some point during all this (a period of relatively
heavy disk IO), the computer seemed to crash and I rebooted it. It
then worked fine for a while, but during my perfmon testing it seemed
to do the same thing. This time I left it for a while and it did
eventually wake up again, so I'm guessing the controller is a bit
fubared. Perfmon did indeed show several dips down to or very close
to 0 during the write operation, with peaks up to 48 MB/sec, which is
pretty respectable. So, time to replace the brand-new controller I
guess.
Now, do you think this is just my one particular controller card and
a simple return would fix the problem, or is it more likely a problem
with the whole range? It's an Innovision EIO SATA controller: http://
www.ivmm.com/eio/products/index.htm
Would it be a safer bet to go for the Adaptec controller of the same
variety? How reliable are they?
Many thanks,
Chris
--
Chris Boot
[email protected]
http://www.bootc.net/
-
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]
| |
 |