Here is the captured Oops! Unable to handle kernel NULL pointer dereference at virtual address 00000018 current->tss.cr3 = 00faa000, %cr3 = 00faa000 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c013c0fc>] EFLAGS: 00010246 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 c0d10980 Call Trace: [<c013f94b>] [<c01d6dff>] [<c01404ee>] [<c012d04d>] [<c012d0be>] [<c 0109d08>] Code: 8b 47 18 50 68 80 67 1d c0 8b 44 24 2c 50 8b 47 68 50 e8 69 Segmentation fault 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 retain. 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). henris is my alter ego.
I am going to close this out because I cant duplicate this anymore.