/dev permissions after reboot (and panic)
Peter Avalos
pavalos at theshell.com
Sat Jul 16 17:29:15 PDT 2005
So every time I reboot, I get a panic (I believe someone else may
be having this problem too). I've included a capture of the ddb
session at the bottom. Unfortunately, I can't get a core dump.
But, what really sucks, is if I did a 'MAKEDEV all', permissions
in /dev get hosed when the machine comes back up. MAKEDEV is doing
the right thing, because I've checked to make sure the devices
have the correct permissions. When the machine comes back up,
things like null, zero, tty, lose their write permissions, which
hoses things up.
A copy of the kernel can be found on leaf:~pavalos/public/kernel.0713
or at:
http://www.theshell.com/~pavalos/crash/kernel.0713
Here's the ddb session (hand-typed):
mfree: m->m_nextpkt != NULL
Trace beginning at frame 0xde0128bc
m_free(c02c7f1f,10,0,d9,de012944) at m_free+0x5e
m_free(ddfce000,de012944,da7c4e40,de01297c,de012910) at m_free+0x5e
sbdrop(de012944,e9,de012914,c01bd603,de012950) at sbdrop+0x7b
sbflush(de012944,de01297c,de012930,c01c5f0d,ddfce000) at sbflush+0x44
sbrelease(de012944,da7c4dc0,c02fd6b4,d9,1000,500,8000,1,ddfce000,0,ddfced00,0,0,
0,da7c4e30,0,40,da7c4e44,0) at sbrelease+0x12
sorflush(da7c4dc0,da7c4dc0,ddea11c0,de0129c8,c01bdf9f) at sorflush+0x10d
sofree(da7c4dc0,0,ff80044c,ddea1200,ddea11c0) at sofree+0x92
soclose(da7c4dc0,ddea11c0,de012a20,c017c37a,ddea11c0) at soclose+0x149
soo_close(ddea11c0,d6527300,0,e94d4000,3) at soo_close+0x27
fdrop(ddea11c0,d6527300,de012a64,c0194edb,c02f996c) at fdrop+0xb5
closef(ddea11c0,d6527300,c02f48e0,18,0) at closef+0x17a
fdfree(d64fd680,c02f5040,2,c03352e0,100) at fdfree+0x212
exit1(100,de012d40,c02a63ce,de012c24,de012d10) at exit1+0x1ba
exit1(de012c24,de012d10,4,c0356b20,1) at exit1
syscall2(2f,2f,2f,f,8050180) at syscall2+0x28a
Xint0x80_syscall() at Xint)x80_syscall+0x2a
pflog0: promiscuous mode disabled
boot() called on cpu#1
Waiting (max 60 seconds) for system thread vnlru to stop...stopped
Waiting (max 60 seconds) for system thread bufdaemon to stop...stopped
Waiting (max 60 seconds) for system thread syncer to stop...stopped
syncing disks... 6 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
giving up on 7 buffers
Debugger("Busy buffer problem")
CPU1 stopping CPUs: 0x00000001
stopped
Stopped at Debugger+0x44: movb $0,in_Debugger.0
db> panic
panic: from debugger
mp_lock = 00000001; cpuid = 1; lapic.id = 06000000
Trace beginning at frame 0xded829f0
panic(c02c65b1,6000000,c02c2de4,ded82a20,0) at panic+0xd9
panic(c02c2de4,ded82aec,c01394b2,c028e0e7,0) at panic+0xd9
db_command_loop(c028e0e7,0,ffffffff,ded82a50,ded82a4c) at db_command_loop
db_command(c03132b0,c02ef5e0,c02ea1d4,c02ea1ec,ded82b20) at db_command+0x2b1
db_command_loop(c028e0e7,c0367d40,c0317880,1,0) at db_command_loop+0x75
db_trap(3,0,1,1,ded82b6c) at db_trap+0xc8
kdb_trap(3,0,ded82b74,0,0) at kdb_trap+0x17b
trap(18,10,ded80010,0,c3f35ea0) at trap+0x55e
calltrap() at calltrap+0xc
--- trap 0x3, eip = 0xc028e0e7, esp = 0xded82bb4, ebp = 0xded82bbc ---
Debugger(c02c64bc,7,0,7,7) at Debugger+0x44
boot(0,ded82d40,c02a63ce,ded82c24,ded82d10) at boot+0x2dc
reboot(ded82c24,ded82d10,4,deb82500,1) at reboot+0x2c
syscall2(2f,2f,2f,0,0) at syscall2+0x28a
Xint0x80_syscall() at Xint0x80_syscall+0x2a
boot() called on cpu#1
Uptime: 5m46s
LWKT_WAIT_IPIQ WARNING! 1 wait 0 (-1)
panic: LWKT_WAIT_IPIQ
mp_lock = 00000001; cpuid = 1; lapic.id = 06000000
boot() called on cpu#1
Uptime: 5m46s
LWKT_WAIT_IPIQ WARNING! 1 wait 0 (-2)
panic: LWKT_WAIT_IPIQ
mp_lock = 00000001; cpuid = 1; lapic.id = 06000000
boot() called on cpu#1
Uptime: 5m46s
LWKT_WAIT_IPIQ WARNING! 1 wait 0 (-3)
panic: LWKT_WAIT_IPIQ
mp_lock = 00000001; cpuid = 1; lapic.id = 06000000
boot() called on cpu#1
Uptime: 5m46s
At this point, I just power-cycled the machine...
Attachment:
pgp00006.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 189 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/bugs/attachments/20050716/39149b57/attachment-0021.obj>
More information about the Bugs
mailing list