* Memory tables corruption - kernel v2.4.33-rc1
@ 2006-07-11 4:39 Tony Borras
2006-07-11 5:20 ` Willy Tarreau
0 siblings, 1 reply; 2+ messages in thread
From: Tony Borras @ 2006-07-11 4:39 UTC (permalink / raw)
To: linux-kernel; +Cc: gmorris
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.
Tony Borras
Fall is my favorite season in Los Angeles, watching the birds
change color and fall from the trees.
David Letterman (1947 - )
--
__ __ _ I N C. http://www.sysdev.org
/ __|\\// __|| \ __ __ / tonyb@sysdev.org
\__ \ \/\__ \||)|/ O_)\/ / \/ System Tools / Utilities
|___/ || ___/|_ /\___|\_/ WIntel / Linux Device Drivers
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Memory tables corruption - kernel v2.4.33-rc1
2006-07-11 4:39 Memory tables corruption - kernel v2.4.33-rc1 Tony Borras
@ 2006-07-11 5:20 ` Willy Tarreau
0 siblings, 0 replies; 2+ messages in thread
From: Willy Tarreau @ 2006-07-11 5:20 UTC (permalink / raw)
To: Tony Borras; +Cc: linux-kernel, gmorris
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-07-11 5:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-11 4:39 Memory tables corruption - kernel v2.4.33-rc1 Tony Borras
2006-07-11 5:20 ` Willy Tarreau
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox