Here is the captured Oops!
Unable to handle kernel NULL pointer dereference at virtual address
current->tss.cr3 = 00faa000, %cr3 = 00faa000
*pde = 00000000
eax: 00000000 ebx: c01d6720 ecx: c0a88000 edx: c0a88100
esi: 0000000c edi: 00000000 ebp: c0d10980 esp: c0443f2c
ds: 0018 es: 0018 ss: 0018
Process rpm (pid: 4405, process nr: 16, stackpage=c0443000)
Stack: 00036bc2 0000000c 00000041 c0a88000 00000000 00000000 c013f94b
c01d6dff 00000000 c0a88000 c0d10980 00000000 fffffffb c1a04990 c05efed0
c07e8600 c01404ee c0a88100 c0d10980 c05efed0 c07e8600 c07e8600 c0072000
Call Trace: [<c013f94b>] [<c01d6dff>] [<c01404ee>] [<c012d04d>]
Code: 8b 47 18 50 68 80 67 1d c0 8b 44 24 2c 50 8b 47 68 50 e8 69
The machine in question was running a stock kernel(RPM) v2.2.12-20
the rpm's were 3.0.3 and 3.0.4. I would have submutted this as
an rpm bug except for the oops. This caused segfaults and core
dumps with the rpm database being truncated and an rpm --rebuilddb
resulted in such glorious things as rpm staunchly declaring it wasnt
installed. I will provide whatever information required that I still
Memory test/and hardrive test came up clean. Unless it is CPU/cache/or
MotherBoard it has to be software.
Has it been stable since its running the 6.2 kernel
Once I got past the rpm problem. Manual backup of rpm database and spoon feeding rpm's worked. The kernel has since been
updated repeatedly and I have only had a rare occasional core dump/seg fault w/rpm. This is the machine that will install 6.1
w/o issue but not 6.2 -->B1-5. (doesnt like anaconda after 6.1).
email@example.com is my alter ego.
I am going to close this out because I cant duplicate this anymore.