On Tue, 7 Apr 2015, Michael Schmitz wrote:
Hi Finn,
On Wed, 1 Apr 2015, Michael Schmitz wrote:
I've followed the vm stats while running gunzip -c on a large file.
I get an 'invalid compressed data' error at the very end of the
gunzip run, and the file md5sum does not match what I get when
uncompressing that file on another system with no error
Was that an aranym virtual machine or a physical one? If physical, can
the error be reproduced using a virtual one (given same RAM size,
kernel etc)?
The gunzip error cannot be reproduced on any of my ARAnyM VMs. Might be
a RAM error or other hardware related problem. Same kernel but
configured slightly different (added 030 and 040 support, plus ARAnyM
support).
The configuration differences could be cancelled by booting your new
aranym kernel on the physical hardware, and reproducing the fault that
way. BTW, is this the same physical machine that has DMA issues, which we
discussed off-list in the past?
The general behaviour (gunzip eats up all free RAM, then kswapd spins
doing nothing very apparent, with no dirty pages to be flushed and
cached pages never released) remains the same. Though I've seen the
gunzip complete without kicking off kswapd on occasion (had set
dirty_background_ratio and dirty_ratio half the default for that).
And yes, dropping cached pages as Andreas suggested, does free up
significant (i.e. most of all) RAM and shuts up kswapd.
This bug has been reported to Red Hat in the past (on x86_64). They closed
the bugzilla entry in 2011, but the bug was still being reported by Fedora
users in 2014. https://bugzilla.redhat.com/show_bug.cgi?id=712019
--
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
