OpenSolaris

Printable Version Enter a New Search
Bug ID 6342422
Synopsis kernel panic with patch 118844-19 on Gateway 600YG2
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:boot-x86
Keywords
Responsible Engineer Kit Chow
Reported Against s10u1_16 , s10_b74l2a
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_28
Fixed In snv_28
Release Fixed solaris_nevada(snv_28) , solaris_10u1(s10u1_19) (Bug ID:2131289)
Related Bugs 6341885
Submit Date 27-October-2005
Last Update Date 3-January-2006
Description
Solaris 10 x86 installed on a Gateway 600YG2 laptop (1GB RAM, Pentium 4 2.5 Ghz). Installed Sun Update Manager and applied patches, which was fine until patch 118844-19 was applied. After that, Solaris would fail to boot due to a kernel panic (see stack trace below). The system was restored by booting from Solaris install CD and using patchrm to remove patch 118844-19 (and its dependents). Patch 118844-08 seems okay. Tried to apply the patches again using smpatch, and again the kernel panic occurred on reboot.

This is the stack trace (appears just after Solaris version and copyright messages):

panic[cpu0]/thread=fec1d660: boot_mapin(): No pp for pfnum = 3ff7f

fec33900 unix:boot_mapin+68 (d9019000, 1000)
fec33918 unix:boot_alloc+59 (d9019000, 1000, 100)
fec33934 unix:segkmem_alloc+80 (fec62898, 1000, 0)
fec33980 genunix:vmem_xalloc+3b4 (fec62f28, 1000, 100)
fec339bc genunix:vmem_alloc+135 (fec62f28, 1000, 0)
fec339e4 genunix:vmem_populate+e5 (d9016000, 100)
fec33a2c genunix:vmem_xalloc+123 (d9016000, 43c1, 4,)
fec33a68 genunix:vmem_alloc+155 (d9016000, 43c1, 100)
fec33a88 krtld:kobj_export_ctf+52 (d9189ee8, d9182050,)
fec33ab0 krtld:kobj_load_module+2fa (d9184f08, 1)
fec33ae0 genunix:mod_load+dc (d9184f08, 1)
fec33af8 genunix:mod_hold_installed_mod+1f (d9182050, 1, fec33b)
fec33b24 genunix:modload+ac (fec05fc4, fec05fbc)
fec33b34 unix:startup_modules+73 (fec33b4c, fe8d51f8,)
Forgot to mention earlier that sometimes when this panic occurred on my laptop, the machine would immediately reboot, similar to CR 6341885.
Work Around
Remove patch 118844-19 and its dependents.
boot with kmdb(-kd) and set a chip breakpoint on physmax.

[0]> physmax:w

On the chip breakpoint, modify the value of physmax to the current value + 1

[0]> :c
kmdb: stop on write of [physmax, physmax+1)
kmdb: target stopped at:
installed_top_size+0x56:movl   0x10(%ebp),%eax

[0]> physmax/X
physmax:
physmax:        3ff7f

[0]> physmax/W 3ff80
physmax:        0x3ff7f         =       0x3ff80
Comments
N/A