Re: memory & filesystem corruption under heavy load?

Markus Kossmann (
Mon, 08 Apr 1996 14:31:21 +0200

Hi, Linus
on Sun, 7 Apr 1996 you wrote:
>You should be able to disable the 4MB pages with the kernel boot command
> of "mem=nopentium" too (just add it as an append to your lilo config
>file). Do your problems go away with that too, even on an unpatched
Yes !,I didn't use that option, because I didn't knew it. This option
documented in the recent BootPrompt-Howto and I didn't look in the right
places of the Kernel source to find it .

>Umm.. I started looking at the code, and I did find one problem in the
>4MB page setup, but that should not matter on any normal machine (it only
>matters if your machine doesn't ahve an even multiple of 4MB or RAM in

>There is a test that looks something like this in arch/i386/mm/init.c:
> if (address <= end_mem + 4*1024*1024 &&
> (x86_capability & 8))
>Just change the "+" into a "-", and that particular bug should be fixed.

>Does that one-character fix correct this problem for you? (You _might_
>have 384kB re-mapped memory above your 16MB). I don't see why the extra
>TLB mapping should make any difference at all even when the bug is there,
>but just in case..

It does not fix the problem, my bios (AWARD 4.50PG) doesn't re-map the
I've got :
SCSI disk error : host 0 channel 0 id 1 lun 0 return code = 44234010
Kernel panic: Ext2fs panic (device 08:18) : ext2_read_inode
unable to read inode_block inode_block inode=91686 block=368676

Well, I tried to get more information about the crashes, so I started
another make -j
This time I got half a dozen pages of Kernel Oops concerning sendmail,
gcc, as , gpm etc.. I started to write down the messages, but then I
lazy and thought: "You will find it in kernel logs ;too". That wasn't a
idea, because I didn't found them there :-(. That's all I have written
CPU: 0
EIP: 0010:[<00123c63>]
EFLAFS: 00010082
eax: 00000000 ebx: 00000282 ecx: 00000000 edx: f000ff54
ebi: 00000000 edi: 00001000 ebp: 00dde000 esp: 00a8fd88
ds: 0018 es: 002b gs: 002b ss: 0018
Process sendmail (pid: 70. processnr. 16, stackpage = 00a8f000 )
Stack: 00000000 00123cd9 00221228 0000988a 00221228 00dde00 00000000
00123c63 is in get_unused_buffer_head + 0x13

In order to get the kernel messages onto disk ( and not only into buffer
cache) I started a " while true, do sleep 1s; sync;done" before trying a
next make -j and ... surprise !: there was no crash but only one error
EXT2-fs error (device 08:18): ext2_read_inode: bad inode number:

I hope that helps you catching the bug .

Markus			           <> (Markus Kossmann)