Panic in _mtx_lock_sleep
}:144 ---Can't read userspace from dump, or kernel process--- (kgdb) This is what I got from the kernel debugger: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x68 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0647282 stack pointer = 0x10:0xcfe919e0 frame pointer = 0x10:0xcfe91a0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 326 (named) kernel: type 12 trap, code=0 Stopped at _mtx_lock_sleep+0x1b2: movl 0x68(%ecx),%edx db show reg cs 0x8 ds 0xcfe90010 es 0xc2f80010 fs 0xc2690018 ss0x10 eax0x1 ecx 0 edx0x2 ebx 0xc26c4260 esp 0xcfe919e0 ebp 0xcfe91a0c esi 0xc28f7490 edi 0xc28f1abc eip 0xc0647282 _mtx_lock_sleep+0x1b2 efl0x10246 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 _mtx_lock_sleep+0x1b2: movl 0x68(%ecx),%edx db trace _mtx_lock_sleep(c28f7490,0,0,0,0) at _mtx_lock_sleep+0x1b2 ip_output(c1561300,0,c28f1abc,0,0) at ip_input+0x296 udp_output(c28f1a80,c1561300,c2745660,0,c26c4260) at udp_output+0x406 udp_send(c2913220,0,c155cf00,c2745660,0) at udp_send+0x121 sosend(c2913220,c2745660,cfe91bf4,c155cf00,0) at sosend+0x43d kern_sendit(c26c4260,16,cfe91ca4,0,0) at kern_sendit+0x1ac sendit(c26c4260,16,cfe91ca4,0,bfbfe572) at sendit+0x16e sendmsg(c26c4260,cfe91d10,c,c0679a26,3) at sendmsg+0xc3 syscall(818002f,819002f,bfbf002f,0,0) at syscall+0x310 Xint0x80_syscall() at Xint0x80_syscall+0x1d -- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x283057af, esp = 0xbfbfe14c, ebp = 0xbfbfe2f8 --- db I then had to write panic two or three times until it started to do the crashdump. -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Two crashes in CURRENT from October 7th, both mention Xint0x80_syscall()
Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Unable to compile kernel
Hello. Today I've had problems compiling my VIMES kernel which is 99% identical to GENERIC from CURRENT. I've CVSUP'ed twice today (the last one 20-30 minutes ago) and I still get this error during the compile. Here are the last few lines I see (there are some long lines here): cc -c -O -pipe -march=pentium2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c: In function `fr_check_wrapper': /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:319: error: `PFIL_OUT' undeclared (first use in this function) /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:319: error: (Each undeclared identifier is reported only once /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:319: error: for each function it appears in.) /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c: In function `fr_check_wrapper6': /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:329: error: `PFIL_OUT' undeclared (first use in this function) /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c: In function `iplattach': /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:376: warning: unused variable `ph_inet' /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:378: warning: unused variable `ph_inet6' /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c: At top level: /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:317: warning: `fr_check_wrapper' defined but not used /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:327: warning: `fr_check_wrapper6' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/VIMES. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. vimes# Here's the diff between plain GENERIC and my VIMES kernel: vimes# diff GENERIC VIMES 25c25 ident GENERIC --- ident VIMES 63,66c63,66 options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed --- #options INVARIANTS #Enable calls of extra sanity checking #options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed 272a273,278 # These options are a subset of the IPFILTER options. options IPFILTER#ipfilter support options IPFILTER_LOG#ipfilter logging options IPFILTER_DEFAULT_BLOCK #block all packets by default vimes# Any suggestions? I need ipfilter-support and I've had problems when using it as a module. -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to compile kernel
On Thu, 25 Sep 2003 16:31:14 +0200 Max Laier [EMAIL PROTECTED] wrote: This seems to be a problem with ip_fil.c, 1.40. For a quick workaround add #include net/pfil.h in line ~310 (just before fr_check_wrapper()) I've done this and now I get another error: cc -c -O -pipe -march=pentium2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c: In function `iplattach': /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:377: warning: unused variable `ph_inet' /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:379: warning: unused variable `ph_inet6' /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c: At top level: /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:318: warning: `fr_check_wrapper' defined but not used /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:328: warning: `fr_check_wrapper6' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/VIMES. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. vimes# -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Still crashes in swapgeom_strategy and also sometimes in propagate_priority
-k kernel.debug
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
(kgdb) l *swapgeom_strategy+0x3c
0xc04ad20c is in swapgeom_strategy (/usr/src/sys/vm/swap_pager.c:2388).
2383bp-b_ioflags |= BIO_ERROR;
2384bufdone(bp);
2385return;
2386}
2387bio = g_clone_bio(bp-b_io);
2388bio-bio_caller2 = bp;
2389bio-bio_offset = (bp-b_blkno - sp-sw_first) * PAGE_SIZE;
2390bio-bio_length = bp-b_bcount;
2391bio-bio_done = swapgeom_done;
2392g_io_request(bio, cp);
(kgdb)
Here's the crash in propagate_priority:
-START-
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0346b2b
stack pointer = 0x10:0xcaec4c38
frame pointer = 0x10:0xcaec4c4c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi8: tty:sio clock)
kernel: type 12 trap, code=0
Stopped at propagate_priority+0x8b:cmpl0x24(%ebx),%ecx
db show reg
cs 0x8
ds 0xc0d30010
es 0xc0350010 getrusage+0x150
fs 0xcaec0018
ss0x10
eax 0x24
ecx 0xc0d3eab0
edx 0xc0566311
ebx 0
esp 0xcaec4c38
ebp 0xcaec4c4c
esi 0x24
edi 0
eip 0xc0346b2b propagate_priority+0x8b
efl0x10293
dr0 0
dr1 0
dr2 0
dr3 0
dr4 0x0ff0
dr5 0x400
dr6 0x0ff0
dr7 0x400
propagate_priority+0x8b:cmpl0x24(%ebx),%ecx
db trace
propagate_priority(c0d37980,c0627ce0,c0d39600,0,c0d379a0) at
propagate_priority+0x8b
_mtx_lock_sleep(c0625260,0,0,0,c0420ae0) at _mtx_lock_sleep+0x259
softclock(0,0,0,0,c0d36974) at softclock+0x250
ithread_loop(c0d35280,caec4d48,0,0,0) at ithread_loop+0x1d8
fork_exit(c033b850,c0d35280,caec4d48) at fork_exit+0xb1
fork_trampoline() at fork_trampoline+0x8
-- trap 0x1, eip = 0, esp = 0xcaec4d7c, ebp = 0 ---
db panic
panic: from debugger
Debugger(panic)
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc04ee154
stack pointer = 0x10:0xcaec49ec
frame pointer = 0x10:0xcaec49f8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
currnet process = 12 (swi8: tty:sio clock)
Stopped at propagate_priority+0x8b:cmpl0x24(%ebx),%ecx
db
-STOP-
And here's the output from gdb:
(kgdb) l *propagate_priority+0x8b
0xc0346b2b is in propagate_priority (/usr/src/sys/kern/kern_mutex.c:178).
173
174 /*
175 * Check if the thread needs to be moved up on
176 * the blocked chain
177 */
178 if (td == TAILQ_FIRST(m-mtx_blocked)) {
179 continue;
180 }
181
182 td1 = TAILQ_PREV(td, threadqueue, td_lockq);
(kgdb)
Does anyone have any suggestions as to what the problem might be? For the
record, I've seen the exact same crashes with kernel+world built from
source around the 7th and 15th of September as well.
--
Eivind Olsen
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still crashes in swapgeom_strategy and also sometimes in propagate_priority
--On 18. september 2003 09:23 +0200 Eivind Olsen [EMAIL PROTECTED] wrote: Hello. I'm experiencing frequent crashes on my FreeBSD box here. It's running FreeBSD 5.x CURRENT (CVSUP'ed yesterday (the 17th) around 1800 CET). I've now had more crashes which looks like those I mentioned in the last mail. The difference is that this time it actually produced a crash dump! This is the crash that produced the crashdump vmcore.2: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor write, page not present instruction pointer = 0x8:0xc04ad20c stack pointer = 0x10:0xcaf23a3c frame pointer = 0x10:0xcaf23a54 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 6 (pagedaemon) kernel: type 12 trap, code=0 Stopped at swapgeom_strategy+0x3c: movl%edi,0x40(%eax) db show reg cs 0x8 ds0x10 es0x100010 fs0x18 ss0x10 eax 0 ecx 0 edx0x4 ebx 0xc1f97880 esp 0xcaf23a3c ebp 0xcaf23a54 esi 0xc5ab5bf0 edi 0xc5ab5bf0 eip 0xc04ad20c swapgeom_strategy+0x3c efl0x10246 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 swapgeom_strategy+0x3c: movl%edi,0x40(%eax) db trace swapgeom_strategy(c5ab5bf0,c1f97880,0,0,2) at swapgeom_strategy+0x3c swp_pager_strategy(c5ab5bf0,200,0,419fe,0) at swp_pager_strategy+0xc5 swap_pager_putpages(c27e85c8,caf23b80,3,0,caf23af0) at swap_pager_putpages+0x452 vm_pageout_flush(caf23b80,3,0,1,1) at vm_pageout_flush+0x18b vm_pageout_clean(c09f4c60,0,0,0,0) at vm_pageout_clean+0x2cd vm_pageout_scan(0,c0636420,44,c0569dbc,1f4) at vm_pageout_scan+0x73f vm_pageout(0,caf23d48,0,0,0) at vm_pageout+0x368 fork_exit(c04c2fa0,0,caf23d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcaf23d7c, ebp = 0 --- db panic panic: from debugger Debugger(panic) (I didn't take the time to write down all the pointers in this section, I didn't expect it to be able to crashdump since it usually hasn't done that, so the three pointers here are not the correct ones but are taken from an older crashdump which looked just the same) Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc04e9e64 stack pointer = 0x10:0xcaf257bc frame pointer = 0x10:0xcaf257c8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 currnet process = 6 (pagedaemon) Stopped at swapgeom_strategy+0x3c: movl%edi,0x40(%eax) db panic panic: from debugger Uptime: 12h5m36s ad2: WARNING - WRITE_DMA recovered from missing interrupt Dumping 191 MB 16 32 ...etc... Dump complete Then, when the system booted I got the following crash (this one also looks like the second one I mentioned in my previous mail): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0346b2b stack pointer = 0x10:0xcaec4c38 frame pointer = 0x10:0xcaec4c4c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi8: tty:sio clock) kernel: type 12 trap, code=0 Stopped at propagate_priority+0x8b:cmpl0x24(%ebx),%ecx db show reg cs 0x8 ds 0xc0d30010 es 0xc0350010 getrusage+0x150 fs 0xcaec0018 ss0x10 eax 0x24 ecx 0xc0d3eab0 edx 0xc0566311 ebx 0 esp 0xcaec4c38 ebp 0xcaec4c4c esi 0x24 edi 0xc0636f20 default_kbd eip 0xc0346b2b propagate_priority+0x8b efl0x10293 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 propagate_priority+0x8b:cmpl0x24(%ebx),%ecx db trace propagate_priority(c0d37980,c0627ce0,c0d39bc0,0,c0d379a0) at propagate_priority+0x8b _mtx_lock_sleep(c0625260,0,0,0,c04d8000) at _mtx_lock_sleep+0x259 softclock(0,0,0,0,c0d36974) at softclock+0x250 ithread_loop(c0d35280,caec4d48,0,0,0) at ithread_loop+0x1d8 fork_exit(c033b850,c0d35280,caec4d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 -- trap 0x1, eip = 0, esp = 0xcaec4d7c, ebp = 0 --- db panic panic: from debugger Debugger(panic) Fatal trap 3
Crash in swapgeom_strategy?
Hello. My FreeBSD server has been getting panics for the last few days and the panics always refer to swapgeom_strategy. Here's a transcription of what I can see: vimes# uname -a FreeBSD vimes.eivind 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Sep 10 09:36:05 CEST 2003 [EMAIL PROTECTED]:/usr/obj/src/sys/VIMES i386 The sources were cvsup'ed in the evening on the 9th of September (evening according to CET). I have not been able to produce a crash dump. Does anyone have any suggestions as to what might be wrong? Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor write, page not present instruction pointer = 0x8:0xc04a8f4c stack pointer = 0x10:0xcaf25a44 frame pointer = 0x10:0xcaf25a5c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 6 (pagedaemon) kernel: type 12 trap, code=0 Stopped at swapgeom_strategy+0x3c: movl%edi,0x40(%eax) db show reg cs 0x8 ds0x10 es0x10 fs0x18 ss0x10 eax 0 ecx 0 edx0x4 ebx 0xc1f8eb80 esp 0xcaf25a44 ebp 0xcaf25a5c esi 0xc5ab87f8 edi 0xc5ab87f8 eip 0xc04a8f4c swapgeom_strategy+0x3c efl0x10246 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 swapgeom_strategy+0x3c: movl%edi,0x40(%eax) db trace swapgeom_strategy(c5ab87f8,c1f8eb80,0,0,0) at swapgeom_strategy+0x3c swp_pager_strategy(c5ab87f8,200,0,3a1,0) at swp_pager_strategy+0xc5 swap_pager_putpages(c27ba784,caf25b80,1,0,caf25af0) at swap_pager_putpages+0x452 vm_pageout_flush(caf25b80,1,0,1,0) at vm_pageout_flush+0x18b vm_pageout_clean(c098d268,0,0,0,0) at vm_pageout_clean+0x2cd vm_pageout_scan(0,c0632120,44,c0565bb1,1f4) at vm_pageout_scan+0x6ff vm_pageout(0,caf25d48,0,0,0) at vm_pageout+0x368 fork_exit(c04becc0,0,caf25d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcaf25d7c, ebp = 0 --- db panic panic: from debugger Debugger(panic) Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc04e9e64 stack pointer = 0x10:0xcaf257bc frame pointer = 0x10:0xcaf257c8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 currnet process = 6 (pagedaemon) Stopped at swapgeom_strategy+0x3c: movl%edi,0x40(%eax) db panic panic: from debugger Uptime: 12h58m23s panic: free locked buf Uptime: 12h58m24s Dumping 191 MB ...and there it just hangs... -- Regards Eivind Olsen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash in g_dev_strategy / CURRENT as of yesterday.
--On 12. august 2003 21:39 +0200 Poul-Henning Kamp [EMAIL PROTECTED] wrote: I'm not of a gdb wizard either, but I think you type up or down until you are at stack frame #12, and the simply say print *bp-b_dev [EMAIL PROTECTED]:~/tmp/debug/CURRENT-2003-08-11 gdb -k kernel.debug vmcore.1 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: from debugger panic messages: --- Syntax error: Unterminated quoted string --- Reading symbols from /usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/vinum/vinum.ko.debug ...done. Loaded symbols for /usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/vinum/vinum.ko.debug Reading symbols from /usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug.. .done. Loaded symbols for /usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug Reading symbols from /boot/kernel/dragon_saver.ko...done. Loaded symbols for /boot/kernel/dragon_saver.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) fr 12 #12 0xc030697e in spec_xstrategy (vp=0xc1fa9cc0, bp=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:512 512 DEV_STRATEGY(bp); (kgdb) print *bp-b_dev There is no member named b_dev. (kgdb) I can give you SSH access to the server if it's any help / easier for you to look at this yourself without telling me one command at a time. -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash in g_dev_strategy / CURRENT as of yesterday.
--On 12. august 2003 21:26 +0200 Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Eivind Olsen writes: Hello. Some of you might have seen my previous mailings regarding crashes in g_dev_strategy under FreeBSD 5.1 (RELENG_5_1). I have now upgraded to CURRENT (cvsupped, compiled and installed yesterday) and I still see similar crashes (but not identical crashes, I can't see any mention of Vinum here). # 12 0xc030697e in spec_xstrategy (vp=0xc1fa9cc0, bp=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:512 This is the call into the device driver. Do you have any idea which driver this might be ? Can you try to print out the bp-b_dev structure if you still have the dump ? I still have the dump. Please tell me exactly which commands I should use and I'll take a look. I'm not a kernel hacker so I don't know how to get at that information all by myself. -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash in g_dev_strategy / CURRENT as of yesterday.
--On 12. august 2003 20:39 +0100 Peter Edwards
[EMAIL PROTECTED] wrote:
# 10 0xc04f3c65 in trap (frame=
{tf_fs = -1059913704, tf_es = -890109936, tf_ds = -1070268400,
tf_edi
= -1040540480, tf_esi = -978597456, tf_ebp = -890095148, tf_isp =
-890095220, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 16343040,
tf_trapno = 12, tf_err = 2, tf_eip = -1070560519, tf_cs = 8, tf_eflags
=
66054, tf_esp = -978597456, tf_ss = -1067143852}) at
/usr/src/sys/i386/i386/trap.c:420
Look at tf_eip: -1070560519 = 0xc0308af9
What does list *0xc0308af9 show in gdb?
(kgdb) list *0xc0308af9
0xc0308af9 is in g_dev_strategy (/usr/src/sys/geom/geom_dev.c:401).
396 KASSERT(cp-acr || cp-acw,
397 (Consumer with zero access count in g_dev_strategy));
398
399 bp2 = g_clone_bio(bp);
400 KASSERT(bp2 != NULL, (XXX: ENOMEM in a bad place));
401 bp2-bio_offset = (off_t)bp-bio_blkno DEV_BSHIFT;
402 KASSERT(bp2-bio_offset = 0,
403 (Negative bio_offset (%jd) on bio %p,
404 (intmax_t)bp2-bio_offset, bp));
405 bp2-bio_length = (off_t)bp-bio_bcount;
(kgdb)
--
Regards / Hilsen
Eivind Olsen
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another crash in FreeBSD 5.1
:1089 #17 0xc04635e0 in vm_pageout_flush (mc=0xcac43bd0, count=1, flags=0, is_object_locked=0) at vm_pager.h:142 #18 0xc046349d in vm_pageout_clean (m=0x0) at /usr/src/sys/vm/vm_pageout.c:351 #19 0xc0464310 in vm_pageout_scan (pass=0) at /usr/src/sys/vm/vm_pageout.c:997 #20 0xc0464ebe in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1491 #21 0xc0307c1e in fork_exit (callout=0xc0464bf0 vm_pageout, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:768 (kgdb) I don't know if this backtrace is any good or if it just refers to the panic-command I typed into ddb. At least this one doesn't refer to g_dev_strategy or any functions called vinum-something. But the instruction pointer, fault virtual address and fault code are the same as before. If this is something to look deeper into, please tell me which commands to enter into gdb etc. Also, I can make the kernel + modules + crashdump available on for example FTP or web if need be. There have also been some problems with GEOM lately. Maybe, despite all indications, it's a GEOM problem. You should probably upgrade. I was going to try CURRENT (still using RELENG_5_1 here now) but I haven't gotten to it yet. I'm actually a bit scared of going to CURRENT, especially since there seems to be mentions of GEOM/Vinum issues which are apparently not resolved. -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Crash in g_dev_strategy / CURRENT as of yesterday.
/usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/vinum/vinum.ko.debug
...done.
Loaded symbols for
/usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/vinum/vinum.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug..
.done.
Loaded symbols for
/usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug
Reading symbols from /boot/kernel/dragon_saver.ko...done.
Loaded symbols for /boot/kernel/dragon_saver.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc03461c0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc03465a8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc01753b2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc0175312 in db_command (last_cmdp=0xc05eeae0, cmd_table=0x0,
aux_cmd_tablep=0xc0573374, aux_cmd_tablep_end=0xc057338c) at
/usr/src/sys/ddb/db_command.c:346
#5 0xc0175455 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc0178465 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc04e1aec in kdb_trap (type=12, code=0, regs=0xcaf23960) at
/usr/src/sys/i386/i386/db_interface.c:172
#8 0xc04f4466 in trap_fatal (frame=0xcaf23960, eva=0) at
/usr/src/sys/i386/i386/trap.c:816
#9 0xc04f4132 in trap_pfault (frame=0xcaf23960, usermode=0, eva=20) at
/usr/src/sys/i386/i386/trap.c:735
#10 0xc04f3c65 in trap (frame=
{tf_fs = -1059913704, tf_es = -890109936, tf_ds = -1070268400, tf_edi
= -1040540480, tf_esi = -978597456, tf_ebp = -890095148, tf_isp =
-890095220, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 16343040,
tf_trapno = 12, tf_err = 2, tf_eip = -1070560519, tf_cs = 8, tf_eflags =
66054, tf_esp = -978597456, tf_ss = -1067143852}) at
/usr/src/sys/i386/i386/trap.c:420
#11 0xc04e3498 in calltrap () at {standard input}:102
#12 0xc030697e in spec_xstrategy (vp=0xc1fa9cc0, bp=0x0) at
/usr/src/sys/fs/specfs/spec_vnops.c:512
#13 0xc03069ab in spec_specstrategy (ap=0x0) at
/usr/src/sys/fs/specfs/spec_vnops.c:529
#14 0xc0305b18 in spec_vnoperate (ap=0x0) at
/usr/src/sys/fs/specfs/spec_vnops.c:122
#15 0xc04a13a4 in swapdev_strategy (a_bp=0xc5abc9b0) at vnode_if.h:1141
#16 0xc04a0282 in swap_pager_putpages (object=0x0, m=0xcaf23b7c, count=4,
sync=0, rtvals=0xcaf23ae0) at /usr/src/sys/vm/swap_pager.c:1326
#17 0xc04b524b in vm_pageout_flush (mc=0xcaf23b7c, count=4, flags=0,
is_object_locked=1) at /usr/src/sys/vm/vm_pager.h:145
#18 0xc04b506d in vm_pageout_clean (m=0xc0ad6200) at
/usr/src/sys/vm/vm_pageout.c:351
#19 0xc04b64ed in vm_pageout_scan (pass=0) at
/usr/src/sys/vm/vm_pageout.c:1015
#20 0xc04b72f8 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1509
#21 0xc032ef61 in fork_exit (callout=0xc04b6f90 vm_pageout, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:790
(kgdb)
Is this of any help at all to anyone? Suggestions as to what I should try
out etc.?
--
Regards / Hilsen
Eivind Olsen
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another crash in FreeBSD 5.1
--On 3. august 2003 00:31 -0400 John Baldwin [EMAIL PROTECTED] wrote: But you knew that. Also, Eivind, you need to use hex, not decimal offsets from the functions. You might want to redo the g_dev_strategy() line with 0x29 instead of 29. I already though about that so I tested the commands both with and without 0x in front of those numbers and I get exactly the same output, so it looks like gdb interprets them as hex anyway: (kgdb) list *(g_dev_strategy+0x29) 0xc02e8139 is in g_dev_strategy (/usr/src/sys/geom/geom_dev.c:415). 410 KASSERT(cp-acr || cp-acw, 411 (Consumer with zero access count in g_dev_strategy)); 412 413 bp2 = g_clone_bio(bp); 414 KASSERT(bp2 != NULL, (XXX: ENOMEM in a bad place)); 415 bp2-bio_offset = (off_t)bp-bio_blkno DEV_BSHIFT; 416 KASSERT(bp2-bio_offset = 0, 417 (Negative bio_offset (%jd) on bio %p, 418 (intmax_t)bp2-bio_offset, bp)); 419 bp2-bio_length = (off_t)bp-bio_bcount; -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another crash in FreeBSD 5.1
6g drive BLACK plex org concat sd length 6g drive WHITE volume usrlocal setupstate plex org concat sd length 6g drive BLACK plex org concat sd length 6g drive WHITE volume tmp plex org striped 279k sd length 128m drive BLACK sd length 128m drive WHITE volume usr setupstate plex org concat sd length 6g drive BLACK plex org concat sd length 6g drive WHITE volume home setupstate plex org concat sd length 8g drive BLACK plex org concat sd length 8g drive WHITE volume storage plex org striped 279k sd length 0 drive BLACK sd length 0 drive WHITE 26 Jul 2003 18:48:05.716157 *** vinum started *** 26 Jul 2003 18:48:06.537279 list 26 Jul 2003 18:48:09.630056 quit 26 Jul 2003 18:51:45.197766 *** vinum started *** 26 Jul 2003 18:51:46.096473 list 26 Jul 2003 18:54:54.363225 *** vinum started *** 26 Jul 2003 18:54:55.111272 list 26 Jul 2003 18:54:56.819849 quit 1 Aug 2003 00:21:24.296757 *** vinum started *** 1 Aug 2003 00:21:25.177412 list 2 Aug 2003 16:58:33.476448 *** vinum started *** 2 Aug 2003 16:58:34.458236 help 2 Aug 2003 16:58:37.866099 l 3 Aug 2003 10:33:57.587832 *** vinum started *** 3 Aug 2003 10:33:58.768548 list vimes# Q: Supply an extract of the file /var/log/messages. Restrict the extract to the same time frame as the history file. Again, each line contains a timestamp at the beginning, so you will have no difficulty in establishing which data is of relevance. A: I couldn't really find anything relevant in the logs, but here goes: Aug 2 08:03:11 vimes ipmon[130]: 08:03:10.569508 fxp0 @0:64 b 80.202.115.1 - 224.0.0.1 PR igmp len 24 (32) IN Aug 2 08:04:11 vimes ipmon[130]: 08:04:11.125994 fxp0 @0:64 b 80.202.115.1 - 224.0.0.1 PR igmp len 24 (32) IN Aug 2 08:05:04 vimes ipmon[130]: 08:05:03.948876 fxp0 @0:64 b 201.245.92.224,7323 - 213.187.177.7,38959 PR tcp len 20 52 -S IN Aug 2 08:05:12 vimes ipmon[130]: 08:05:11.738394 fxp0 @0:64 b 80.202.115.1 - 224.0.0.1 PR igmp len 24 (32) IN Aug 2 09:35:49 vimes syslogd: kernel boot file is /boot/kernel/kernel Aug 2 09:35:49 vimes kernel: Copyright (c) 1992-2003 The FreeBSD Project. Aug 2 09:35:49 vimes kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Aug 2 09:35:49 vimes kernel: The Regents of the University of California. All rights reserved. I'm not sure _when_ it crashed since I wasn't sitting in front of the computer at the time, but it must have been around 08:05. Q: If you have a crash, please supply a backtrace from the dump analysis as discussed below under Kernel Panics. Please don't delete the crash dump; it may be needed for further analysis. A: Sorry, I don't have a crash dump. I tried creating one when the computer had crashed by giving the commands panic and then continue but that didn't help. Was this of any help? -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another crash in FreeBSD 5.1
--On 3. august 2003 09:37 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: Read the links I just sent you. You haven't loaded the Vinum symbols. I'm not sure exactly what to do here. I have absolutely no previous experience with kernel debugging, using gdb etc. so I'm lost without specific instructions on what to do, what to try etc. The vinum.ko file is not stripped: [EMAIL PROTECTED]:~/tmp/debug file /boot/kernel/vinum.ko /boot/kernel/vinum.ko: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped [EMAIL PROTECTED]:~/tmp/debug The web page mentions that I should either use the crash dump (which isn't created...) or use remote serial gdb to analyze the problem. I guess I'll have to find a nullmodem cable, install FreeBSD on another computer here (I couldn't find a Windows version of gdb) and try to figure out exactly how to do remote GDB debugging (I've looked around in the developers handbook, specifically http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne ldebug-online-gdb.html) -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Yet another crash in FreeBSD 5.1
I've now had yet another crash under FreeBSD 5.1 (RELENG_5_1, cvsupped 5-6 days ago) and it looks almost the same as the crash I posted about yesterday (or was it the day before? Here's some output from DDB: Krasj 2.7.2003: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02e8139 stack pointer = 0x10:0xcfb5284c frame pointer = 0x10:0xcfb52880 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 10785 (ctl_cyrusdb) kernel: type 12 trap, code=0 Stopped at g_dev_strategy+0x29:movl%eax,0x14(%ebx) db show reg cs 0x8 ds0x10 es0x10 fs0x18 ss0x10 eax 0xfd235200 ecx 0 edx 0 ebx 0 esp 0xcfb5284c ebp 0xcfb52880 esi 0xc2156024 _end+0x5ae4 edi 0xc2044900 eip 0xc02e8139 g_dev_strategy+0x29 efl0x10286 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 g_dev_strategy+0x29:movl%eax,0x14(%ebx) db trace g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at launch_requests+0x448 vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2 vinumstrategy(c5ada2d0,0,c09719b0,40,0) at vinumstrategy+0xa6 spec_xstrategy(c215c5b4,c5ada2d0,cfb52968,c02e4f18,cfb52994) at spec_xstrategy+0x306 spec_specstrategy(cfb52994,cfb529b0,c044f7ad,cfb52994,0) at spec_specstrategy+0x1b spec_vnoperate(cfb52994,0,c09719b0,f,c5ada2d0) at spec_vnoperate+0x18 ufs_strategy(cfb529d8,cfb52a0c,c0359a87,cfb529d8,1) at ufs_strategy+0xdd ufs_vnoperate(cfb529d8,1,c0504f45,35e,cfb529f8) at ufs_vnoperate+0x18 bwrite(c5ada2d0,cfb52a5c,c0361aca,c5ada2d0,c5ada400) at bwrite+0x3a7 bawrite(c5ada2d0,c5ada400,10,3c6,20020080) at bawrite+0x1c cluster_wbuild(c30c7124,4000,50,0,4) at cluster_wbuild+0x6ba cluster_write(c5b735c0,9c7c64,0,55,c252b880) at cluster_write+0x571 ffs_write(cfb52be0,c21c2528,c22ab000,227,c2025e00) at ffs_wrie+0x5ff vn_write(c21c2528,cfb52c7c,c252b880,0,c22ab000) at vn_write+0x192 dofilewrite(c22ab000,c21c2528,8,807e000,4000) at dofilewrite+0xe8 write(c22ab000,cfb52d10,c0518514,3fb,3) at write+0x69 syscall(2f,807002f,bfbf002f,0,807e000) at syscall+0x24e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x282e08b3, esp = 0xbfbfec1c, ebp = 0xbfbfec38 --- db I tried creating a crash dump by issuing the commands panic and then continue but everything seemingly stopped then and nothing was dumped to disk. Can anyone suggest what I do next to find out about this crash? -- Regards Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum bug? (Re: Yet another crash in FreeBSD 5.1)
[Sending to [EMAIL PROTECTED], and Kris copied in Greg so I'll also do that] --On 2. august 2003 02:00 -0700 Kris Kennaway [EMAIL PROTECTED] wrote: db trace g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at launch_requests+0x448 vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2 vinumstrategy(c5ada2d0,0,c09719b0,40,0) at vinumstrategy+0xa6 Looks like a problem in vinum. The other backtrace was the same, right? Basically the same, yes. Some differences (and many similarities) in the addresses that were referenced. And also almost the same output from the trace command (I see that my first example is missing the dofilewrite() between vn_write() and write() but that might just be because I've forgotten to write down that line (I wrote all this down by hand). So, it looks like it's the same crash again (well, it does look like that to my untrained eye). -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another crash in FreeBSD 5.1
--On 2. august 2003 02:11 -0700 Terry Lambert [EMAIL PROTECTED] wrote: db trace g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at launch_requests+0x448 vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2 gdb -k kernel.debug (gdb) list *(g_dev_strategy+29) [ ... ] (gdb) list *(launch_requests+448) [ ... ] (gdb) list *(vinumstart+2b2) [ ... ] Will give you the exact source lines involved, assuming you built a debug kernel. I did. At least I've tried to. :) (I have a kernel.debug which was compiled at the same time as the real kernel I'm using, and it's approx. 30MB in size). You don't actually need a crash dump to debug a stack traceback. This is what I found by using those commands you mentioned: [EMAIL PROTECTED]:~/tmp/debug gdb -k kernel.debug GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... (kgdb) list *(g_dev_strategy+29) 0xc02e812d is in g_dev_strategy (/usr/src/sys/geom/geom_dev.c:415). 410 KASSERT(cp-acr || cp-acw, 411 (Consumer with zero access count in g_dev_strategy)); 412 413 bp2 = g_clone_bio(bp); 414 KASSERT(bp2 != NULL, (XXX: ENOMEM in a bad place)); 415 bp2-bio_offset = (off_t)bp-bio_blkno DEV_BSHIFT; 416 KASSERT(bp2-bio_offset = 0, 417 (Negative bio_offset (%jd) on bio %p, 418 (intmax_t)bp2-bio_offset, bp)); 419 bp2-bio_length = (off_t)bp-bio_bcount; (kgdb) list *(launch_requests+448) No symbol launch_requests in current context. (kgdb) list *(vinumstart+2b2) No symbol vinumstart in current context. (kgdb) If anyone wants to take a look at this themselves I've put the compressed (gzip) debug-kernel available on http://eivind.aminor.no/debug/kernel.debug.gz NOTE! It's approx. 13MB compressed! -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum bug? (Re: Yet another crash in FreeBSD 5.1)
--On 2. august 2003 11:16 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Looks like a problem in vinum. The other backtrace was the same, right? Please take a look at an older thread named (IIRC) vinum or geom bug? Greg asked for special debug output, but it never happened again for me. A real murphy bug - it happend on three machines once a day and after Gregs response nothing happened over weeks. Are you thinking of the thread vinum and/or geom panic on alpha from 10th of June? I forgot to mention this but my system is i386 uniprocessor (Pentium2 at 450MHz). In case it's relevant, yes I do run vinum: vinum - l 2 drives: D WHITE State: up /dev/ad2s1e A: 0/113046 MB (0%) D BLACK State: up /dev/ad0s1d A: 0/113046 MB (0%) 6 volumes: V var State: up Plexes: 2 Size: 6144 MB V usrlocal State: up Plexes: 2 Size: 6144 MB V tmp State: up Plexes: 1 Size:255 MB V usr State: up Plexes: 2 Size: 6144 MB V home State: up Plexes: 2 Size: 8192 MB V storage State: up Plexes: 1 Size:168 GB 10 plexes: P var.p0 C State: up Subdisks: 1 Size: 6144 MB P var.p1 C State: up Subdisks: 1 Size: 6144 MB P usrlocal.p0 C State: up Subdisks: 1 Size: 6144 MB P usrlocal.p1 C State: up Subdisks: 1 Size: 6144 MB P tmp.p0 S State: up Subdisks: 2 Size:255 MB P usr.p0 C State: up Subdisks: 1 Size: 6144 MB P usr.p1 C State: up Subdisks: 1 Size: 6144 MB P home.p0 C State: up Subdisks: 1 Size: 8192 MB P home.p1 C State: up Subdisks: 1 Size: 8192 MB P storage.p0 S State: up Subdisks: 2 Size:168 GB 12 subdisks: S var.p0.s0 State: up D: BLACKSize: 6144 MB S var.p1.s0 State: up D: WHITESize: 6144 MB S usrlocal.p0.s0State: up D: BLACKSize: 6144 MB S usrlocal.p1.s0State: up D: WHITESize: 6144 MB S tmp.p0.s0 State: up D: BLACKSize:127 MB S tmp.p0.s1 State: up D: WHITESize:127 MB S usr.p0.s0 State: up D: BLACKSize: 6144 MB S usr.p1.s0 State: up D: WHITESize: 6144 MB S home.p0.s0State: up D: BLACKSize: 8192 MB S home.p1.s0State: up D: WHITESize: 8192 MB S storage.p0.s0 State: up D: BLACKSize: 84 GB S storage.p0.s1 State: up D: WHITESize: 84 GB vinum - -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fatal trap 12 under RELENG_5_1, anyone who can help?
Hello. My FreeBSD RELENG_5_1 server (cvsupped 4 days ago) seems to have problems - it crashes from time to time (approx. once a day). I've rebuilt the kernel with debug-symbols and enabled the debugger and caught a crash tonight: Here's what I had on screen (I also ran show reg and trace): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02e8139 stack pointer = 0x10:0xcfbf684c frame pointer = 0x10:0xcfbf6880 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 46373 (ctl_cyrusdb) kernel: type 12 trap, code=0 Stopped at g_dev_strategy+0x29:movl%eax,0x14(%ebx) db show reg cs 0x8 ds0x10 es0x10 fs0x18 ss0x10 eax 0xf7255200 ecx 0 edx 0 ebx 0 esp 0xcfbf684c ebp 0xcfbf6880 esi 0xc201e824 edi 0xc2044900 eip 0xc02e8139 g_dev_strategy+0x29 efl0x10286 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 g_dev_strategy+0x29:movl%eax,0x14(%ebx) db trace g_dev_strategy(c201e824,c2152800,0,cfbf68d0,c2098eca) at g_dev_strategy+0x29 launch_requests(c2e16e80,0,1,,43) at launch_requests+0x448 vinumstart(c5ad9da8,0,c243aab0,cfbf694c,c02e5bc6) at vinumstart+0x2b2 vinumstrategy(c5ad9da8,0,c0b79490,40,0) at vinumstrategy+0xa6 spec_xstrategy(c215b7fc,c5ad9da8,cfbf6968,c02e4f18,cfbf6994) at spec_xstrategy+0x306 spec_specstrategy(cfbf6994,cfbf69b0,c044f7ad,cfbf6994,0) at spec_specstrategy+0x1b spec_vnoperate(cfbf6994,0,c0b79490,f,c5ad9da8) at spec_vnoperate+0x18 ufs_strategy(cfbf69d8,cfbf6a0c,c0359a87,cfbf69d8,1) at ufs_strategy+0xdd ufs_vnoperate(cfbf69d8,1,c0504f45,35e,cfbf69f8) at ufs_vnoperate+0x18 bwrite(c5ad9da8,cfbf6a5c,c0361aca,c5ad9da8,c5ad9ed8) at bwrite+0x3a7 bawrite(c5ad9da8,c5ad9ed8,10,3c6,20020080) at bawrite+0x1c cluster_wbuild(c302c000,4000,4c,0,4) at cluster_wbuild+0x6ba cluster_write(c5afaf08,84cf9c,0,51,c2f82300) at cluster_write+0x571 ffs_write(cfbf6be0,c1fb97f8,c243aab0,227,c2158600) at ffs_wrie+0x5ff vn_write(c1fb97f8,cfbf6c7c,c2f82300,0,c243aab0) at vn_write+0x192 write(c243aab0,cfbf6d10,c0518514,3fb,3) at write+0x69 syscall(2f,2f,2f,0,807e000) at syscall+0x24e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x282e08b3, esp = 0xbfbfec1c, ebp = 0xbfbfec38 --- db I _think_ I've managed to type it all in correctly. No crash dump was made (I have dumpdev=/dev/ad0s1b in /etc/rc.conf) - are there anything else I need to do to get it to crashdump to that device? Should I have given any other commands to the internal debugger to find more information? The kernel I'm running is really GENERIC with a few small changes: vimes# diff VIMES /usr/src/sys/i386/conf/GENERIC 25c25 ident trisha --- ident GENERIC 30c30 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols --- #makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols 62c62 options DDB #Enable the kernel debugger --- #options DDB #Enable the kernel debugger 266,269d265 # This option is a subset of the IPFILTER option. options IPFILTER#ipfilter support options IPFILTER_LOG#ipfilter logging options IPFILTER_DEFAULT_BLOCK #block all packets by default vimes# So, can anyone help me out here? Are there anything else I should have done to find more information? Any other commands to give to the kernel debugger? Any way of making the crashdump happen next time I see a kernel trap like this? -- Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native JDK with libthr/libkse
--On 31. mai 2003 11:22 -0400 Daniel Eischen [EMAIL PROTECTED] wrote: That's what I meant; it didn't work for me. It got pretty far through the build but seemed to run out of some sort of resource. I couldn't tell by the error message what it was, and I don't have the log anymore. The last time I tried to build native Java was on STABLE back in the middle of March 2003. This was the java/jdk14 port. The port stated it needed 1.5GB free disk space in build area! but it needed approx. 2.2GB here. And it also needed quite a lot of memory (well, a lot doesn't really say much - I had 128MB RAM + 256MB SWAP at that time and it wasn't enough). After I gave it enough diskspace and 192MB RAM + 512MB SWAP it compiled fine. -- Regards / Hilsen Eivind Olsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
