EXT2 fs error
Quoted 5 lines · Alan Cox
Quoted 4 lines
If there is a scsi error before the ext2fs error then yes probably so You are looking for a "media error" probably.
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
SCSI bus is being reset for 0 channel 0.
scsi0 reset. sending SDTRSCSI reset is due to repeated attempts to read a block, or I might be wrong and it it's due to a malfunction of the controller on your HD.
You can get it off some working sane hardware if you try and ask for
stupid
Quoted 2 lines
Quoted 2 lines
block numbers. It is worth doing a full fsck on the drive before assuming hardware. Also check the cabling seems sound and is well attached and
that
Quoted 8 lines
Quoted 1 line
parity is enabled on the controller if the bios sets it.
I've seen this happening on my Indy as well like once every month or even more rarely. It only happens very rarely but it happens. I think the hardware of my Indy is fine as all my attempts to reduce the problems I'm experiencing during my development to a hardware problem have failed.
Ralf
By any chance are you guys seeing this on R5000 Indys? There is an assumption in arch/mips/mm/r4xx0.c that flushing the secondary cache automagically flushes the same address in the primary data cache, but that assumption is not universally valid and there is no
reason to believe that it is true on the R5K. This
could cause periodic random corruptions of DMA transfers, which could in turn manifest themselves as corrupted files or file system meta-data. The R4000/R4400SC systems, and the entry-level Indy's without secondary caches should not be at risk.
Kevin K.
Quoted 6 lines · Kevin D. Kissell
Quoted 4 lines
I've seen this happening on my Indy as well like once every month or even more rarely. It only happens very rarely but it happens. I think the hardware of my Indy is fine as all my attempts to reduce the problems I'm experiencing during my development to a hardware problem have failed.
By any chance are you guys seeing this on R5000 Indys?
Yes.
Quoted 4 lines
There is an assumption in
arch/mips/mm/r4xx0.cthat flushing the secondary cache automagically flushes the same address in the primary data cache, but that assumption is not universally valid and there is no reason to believe that it is true on the R5K.
We make this assumption for R[04]00[SM]C CPUs only. For R5000SC CPU modules as in the Indy the assumption is that we don't need to flush the l2 caches unless we do a DMA operation in which case the special r4k_dma_* functions will take care of the whatever might be necessary to keep caches consistent with DMA.
Ralf