Björn Steinbrink wrote:
If the look like this, you might want to try a few patches that are in
-mm.
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x
On 2007.02.11 19:55:37 +, Neil Schemenauer wrote:
> > David R wrote:
> Feb 9 18:40:29 server kernel: ata7: Resetting port
> Feb 9 18:40:29 server kernel: ata7.00: exception Emask 0x0 SAct 0x1
> SErr 0x0 action 0x2 frozen
> Feb 9 18:40:29 server kernel: ata7.00: cmd
> >>
> David R wrote:
Feb 9 18:40:29 server kernel: ata7: Resetting port
Feb 9 18:40:29 server kernel: ata7.00: exception Emask 0x0 SAct 0x1 SErr
0x0 action 0x2 frozen
Feb 9 18:40:29 server kernel: ata7.00: cmd
61/08:00:1f:e4:50/00:00:09:00:00/40 tag 0 cdb 0x0 data 4096 out
Robert Hancock wrote:
> So it was tag 0 that timed out , and according to the CPBs the
> controller indeed believes the command is still outstanding, i.e. we
> didn't lose an interrupt. I'm suspicious of the fact that only one of
> two identical drives produced this error.. some kind of hardware-r
David R wrote:
I've just upgraded my home server to 2.6.20. It's got an Athlon64 on an ASUS
nForce-4 motherboard running a 32 bit kernel. I've had to fall back to using
sata_nv.adma=0 on the kernel command line. One of the NCQ capable drives
repeatedly produced the following errors. There wasn't
I've just upgraded my home server to 2.6.20. It's got an Athlon64 on an ASUS
nForce-4 motherboard running a 32 bit kernel. I've had to fall back to using
sata_nv.adma=0 on the kernel command line. One of the NCQ capable drives
repeatedly produced the following errors. There wasn't much disk IO goin
6 matches
Mail list logo
