Sure should..
Do you happen to have a Cyrix CPU, by any chance? This looks like the
cyrix problem that has been seen before..
> Unable to handle kernel paging request at virtual address 00000004
"00000004" again..
> current->tss.cr3 = 0081b000,
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<0011c90e>]
> EFLAGS: 00010206
> eax: 00002000 ebx: 00001000 ecx: 00000400 edx: 00948000
> esi: 00948000 edi: 08076000 ebp: 00950000 esp: 006c2f50
> ds: 0018 es: 002b fs: 002b gs: 002b ss: 0018
> Process cpp (pid: 3785, process nr: 25, stackpage=006c2000)
> Stack: 00000018 004f3980 00a724b0 00003adb 08074000 00003000 001d12a0 00950000
> 00000000 000a724b 00001000 00948000 00000000 00000000 00002000 00002000
> 00000000 00122ba2 00a724b0 004f3980 08076000 00001adb 00819018 08074000
> Call Trace: [<00122ba2>] [<0010a5d9>]
> Code: f3 a5 83 e3 03 89 d9 f3 a4 07 6a 00 8b 74 24 2c 56 e8 6c 36
> Using `/System.map' to map addresses to symbols.
>
> >>EIP: 11c90e <generic_file_read+48e/630>
> Trace: 122ba2 <sys_read+c2/e0>
> Trace: 10a5d9 <system_call+59/a0>
>
> Code: 11c90e <generic_file_read+48e/630> repz movsl %ds:(%esi),%es:(%edi)
And once again we're copying to user mode, and neither %esi nor %edi
(source and destination) have anything at all in them that could result
in a virtual address translation of 00000004. esi = 00948000 (perfectly
reasonable kernel address) and edi = 08076000 (perfectly reasonable user
space address). The count (in ecx) is a perfectly normal 0x400, ie we
copy the whole page (that's normal, it's going to the stdio buffers).
I wonder what makes this happen.. But first, please confirm that it is
indeed a Cyrix chip (Steven Baur - can you compare chip notes?)
Linus