Messages in this thread | | | Date | Tue, 11 Jul 2006 07:20:40 +0200 | From | Willy Tarreau <> | Subject | Re: Memory tables corruption - kernel v2.4.33-rc1 |
| |
Hello,
On Mon, Jul 10, 2006 at 08:39:38PM -0800, Tony Borras wrote: > Please fwd to 2.4.33 Team. > > One of my customers reported in tests that, after some runtime, > his 59MB ram drive suddenly, randomly shrinks. > > Same customer s/w has been running fine with 2.4.31 kernel. > > > Report follows: > > I have two Advantech (i486 Geode's w/64MB ram, ~49MB usable, as > configured in the kernel make) test units where Dosemu crashed > this weekend. For some reason the Via unit was fine. > > Here is what happened: > > 1. Linux was O.K., dosemu 1.3.2 had shut down. > It appears both units were out of RAM. > > 2. The first unit showed the RAM drive size to be > 14661 1k blocks using the df command. The 1K blocks > should be 47595, as they were after boot. The other unit > showed the correct value of 1K blocks=47595. Even after > restarting the Advantech, the 1K blocks would not go back to > normal, so my software cannot even load. > > 3. The second Advantech unit showed correct values with the df > command, but when I used the du -cbs command, I found the /tmp > directory had only 110796 bytes, instead of the normal ~15 MB. > When I restarted Linux, all the RAM came back, and the > unit started working again. > > --------- > > Thanks, I will check further with this customer.
2.4.33-rc1 has a bug in vfs_unlink(). Probably you've been hitting it when removing lots of files from /tmp which might not have been really freed. -rc2 has this fixed. You should try it instead. Other people reported kernel panics on -rc1 with NFS.
> Tony Borras
Regards, Willy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |