I have one problem I consider major, though I have a
performance-reducing workaround:
- Without `ide0=nodma', my system will suddenly just freeze
(SysRq not working). It usually freezes a few times a day, though
sometimes several days of uptime have gone by without a freeze.
With it, the system is very reliable and I have had uptimes in
excess of a month to test this. There have been a couple of
freezes in this case, but only while starting the X server
(3.3.1, which I believe has a known bug for this, while
initialising my video card).
As I have work to do, I always use `ide0=nodma' except when trying
a new kernel to see if the problem has gone away.
This has been present with all 2.1.x I've tried, including at
least 2.1.70, 2.1.72, 2.1.80, 2.1.82, 2.1.85, 2.1.96, 2.1.105.
Haven't tried 2.1.106 because of mentions of fs corruption on
linux-kernel.
System is AMD K6/233, VIA VP2/97 chipset, Quantum FB ST 6.4GB disk.
This bug has been demonstrated with simple disk activity tests in
single user mode, no other I/O except writing to the screen, though I
haven't found any specific way to reproduce it.
Others have reported total freezes. Perhaps they should also try
`ide0=nodma' (or the appropriate variation), to see if their freezes
also stop.
Here's something I'm not even sure is a problem, it just surprised me:
- A couple of times (either with 2.1.85 or 2.1.96, I forget), I have
needed to reset the box after X crashed while initialising. On the
next boot, fsck (on /usr) was skipped as if the filesystem was
unmounted cleanly.
It is possible /usr was not written to by this time though it was
definitely mounted read-write. Is this behaviour correct,
i.e. not marking the disk as dirty even though it has been mounted
rw? (Perhaps the dirty flag is deferred until the first write).
There is a lot of disk activity in my boot process which continues
beyond starting X. I was a bit worried that the flags to mark
/usr dirty were not getting written to disk synchronously, instead
being delayed by all the other disk activity going on.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu