Bartlomiej Zolnierkiewicz wrote:
> It shouldn't be like that. Please send dmesg output for this system.

> ditto

D'oh!  *kicks self*  somehow last time I upgraded, I got
CONFIG_BLK_DEV_VIA82CXXX as a module, and I just never noticed dma was
off until I checked with the 8gb drive.  The module was being loaded,
but too late I'd guess.  Not quite sure how it ended up a module, as I
always hit y for it...  *hides in shame*

[insert ~10 minute pause here as I recompile and reboot]

There's DMA back on...


The 8gb drive, however, would always give:
Sep 17 19:58:46 furbox kernel: hda: dma_timer_expiry: dma status == 0x21
Sep 17 19:58:56 furbox kernel: hda: DMA timeout error
Sep 17 19:58:56 furbox kernel: hda: dma timeout error: status=0x58 {
DriveReady SeekComplete DataRequest }
Sep 17 19:58:56 furbox kernel:

whenever you tried enabling dma on the computer I removed it from.
(yes, the 4th line was always blank)


And right now it's giving:
Sep 23 15:09:03 localhost kernel: hdc: dma_intr: status=0x51 {
DriveReady SeekComplete Error }
Sep 23 15:09:03 localhost kernel: hdc: dma_intr: error=0x84 {
DriveStatusError BadCRC }

with it in this computer.  (I can't put it back in the other computer...
  care of a cheap cpu fan it's been transformed into a paperweight)


Either way, I've had the drive for about 2 years, and have never once
gotten DMA to work with it, so I'd guess probably the drive is to blame,
not the kernel.  And I'd certainly like to copy the data off the drive
and retire it, as crc errors sound worse than general timeouts...


However, I don't think this is related to the OOM problem...  and even
if it were, broken dma shouldn't cause false OOMs.  :)


dmesg output from this box is mime-attached, even though you probably 
don't need it now that I fixed the via driver...


Thanks again,
--Randy
(who's about to grab -rc2 and see if it helps the OOMs)