My healty system differs quite a bit:
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
So yes, I could possibly have been bitten by that bug.
But, could the disabled DMA not by the results of those IDE errors. Instead of the other way around? It seems logical that when multiple IDE errors occur DMA gets disabled to rule out a faulty DMA controller.
That could very well be the case:
pmjdebruijn@ tsunami: ~$ sudo hdparm /dev/hda
/dev/hda: tsunami: ~$
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 78165361, start = 0
pmjdebruijn@
My healty system differs quite a bit:
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
So yes, I could possibly have been bitten by that bug.
But, could the disabled DMA not by the results of those IDE errors. Instead of the other way around? It seems logical that when multiple IDE errors occur DMA gets disabled to rule out a faulty DMA controller.