Re: radeon_cp_texture: page fault with non-sleepable locks held
On Wed, Nov 10, 2010 at 07:18:54AM +0200, Andriy Gapon wrote: on 09/11/2010 16:05 Kostik Belousov said the following: Easiest would be for DRM to provide wrappers for copyin/copyout that unlock, do operation and lock. I am a little bit worried about this approach in general. Driver state may be changed by a process running in parallel while the lock is dropped. And I don't think that we have any mechanism in DRM to check for that and to restart operations or otherwise account for the state change. The code seems to be written with an assumption that it runs in exclusive mode from DRM ioctl start to its completion. Where is the reverse order (user map - drm) ? You mean the following or the opposite? 1st 0xff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:791 2nd 0xff000a621510 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 KDB: stack backtrace: db_trace_self_wrapper() at 0x801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x803a7a8a = kdb_backtrace+0x3a _witness_debugger() at 0x803bd42c = _witness_debugger+0x2c witness_checkorder() at 0x803be899 = witness_checkorder+0x959 _sx_slock() at 0x80378af8 = _sx_slock+0x88 _vm_map_lock_read() at 0x80510a06 = _vm_map_lock_read+0x36 vm_map_lookup() at 0x805127d4 = vm_map_lookup+0x54 vm_fault() at 0x80509819 = vm_fault+0xf9 trap_pfault() at 0x80545d6f = trap_pfault+0x11f trap() at 0x805465f7 = trap+0x657 calltrap() at 0x80530628 = calltrap+0x8 --- trap 0xc, rip = 0x805440bd, rsp = 0xff8123fe37f0, rbp = 0xff8123fe3870 --- copyin() at 0x805440bd = copyin+0x3d radeon_cp_texture() at 0x8022fbd7 = radeon_cp_texture+0x167 drm_ioctl() at 0x8020fa38 = drm_ioctl+0x318 devfs_ioctl_f() at 0x802dd649 = devfs_ioctl_f+0x109 kern_ioctl() at 0x803c1127 = kern_ioctl+0x1f7 ioctl() at 0x803c12e8 = ioctl+0x168 syscallenter() at 0x803b57de = syscallenter+0x26e syscall() at 0x80545eb2 = syscall+0x42 Xfast_syscall() at 0x80530902 = Xfast_syscall+0xe2 If you meant the opposite order, how can I check it? I guess that it could be in a mmap() call for drm cdev. Explicitely insert the reversed order into the witness array and watch. pgpKtRF8UKfSv.pgp Description: PGP signature
Re: Syscons and termcap
On Tue, Nov 9, 2010 at 5:13 PM, Ed Schouten e...@80386.nl wrote: * Renato Botelho rbga...@gmail.com, 20101109 19:12: It had no effect on console but, i don't know why, screwed up my Xorg keymap, some meta keys (Mod4) stop working even if I run a setxkbmap like this: Oh yes. d'oh! I forgot that that specific input path is used by both the console and the raw keyboard interface used by Xorg. I've updated the patch to only emit UTF-8 when using K_XLATE keyboard mode, which is used on the console. http://80386.nl/pub/syscons-utf8.txt Now Xorg is working properly, but it has no effect on console. I'm using cp437 fonts and us.iso.kbd -- Renato Botelho ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Only display ACPI bootmenu key if ACPI is present
On Tuesday, November 09, 2010 5:58:13 pm C. P. Ghost wrote: On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin j...@freebsd.org wrote: This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? Wouldn't that be a POLA violation? Some admins may be used to the current menu, and would be scratching head as what went wrong. Maybe it would be better to keep the menu option, but make it non-selectable and print next to it something like (not available)? Hmmm, I'll see if I can leave the numbering unchanged but not list the item perhaps. Note that we already have the alternate numbering on other platforms so the menu is already inconsistent across FreeBSD platforms. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Only display ACPI bootmenu key if ACPI is present
What are the chances the detection fails and one still needs to disable ACPI and can't because it's not showing as a option ? Thanks, David Rhodus On Nov 8, 2010, at 5:14 PM, John Baldwin j...@freebsd.org wrote: This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? --- //depot/projects/smpng/sys/boot/forth/beastie.4th2010-11-08 21:53:18.0 +++ //depot/user/jhb/ktrace/boot/forth/beastie.4th2010-11-08 22:14:04.0 @@ -140,12 +140,16 @@ fbsdbw-logo ; -: acpienabled? ( -- flag ) +: acpipresent? ( -- flag ) s hint.acpi.0.rsdp getenv dup -1 = if drop false exit then 2drop +true +; + +: acpienabled? ( -- flag ) s hint.acpi.0.disabled getenv dup -1 if s 0 compare 0 if @@ -178,8 +182,7 @@ 42 20 2 2 box 13 6 at-xy . Welcome to FreeBSD! printmenuitem . Boot FreeBSD [default] bootkey ! -s arch-i386 environment? if -drop +acpipresent? if printmenuitem . Boot FreeBSD with ACPI bootacpikey ! acpienabled? if . disabled -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Only display ACPI bootmenu key if ACPI is present
If the loader can't detect acpi, the kernel can't either. Scott On Nov 10, 2010, at 9:01 AM, David Rhodus wrote: What are the chances the detection fails and one still needs to disable ACPI and can't because it's not showing as a option ? Thanks, David Rhodus On Nov 8, 2010, at 5:14 PM, John Baldwin j...@freebsd.org wrote: This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? --- //depot/projects/smpng/sys/boot/forth/beastie.4th2010-11-08 21:53:18.0 +++ //depot/user/jhb/ktrace/boot/forth/beastie.4th2010-11-08 22:14:04.0 @@ -140,12 +140,16 @@ fbsdbw-logo ; -: acpienabled? ( -- flag ) +: acpipresent? ( -- flag ) s hint.acpi.0.rsdp getenv dup -1 = if drop false exit then 2drop +true +; + +: acpienabled? ( -- flag ) s hint.acpi.0.disabled getenv dup -1 if s 0 compare 0 if @@ -178,8 +182,7 @@ 42 20 2 2 box 13 6 at-xy . Welcome to FreeBSD! printmenuitem . Boot FreeBSD [default] bootkey ! -s arch-i386 environment? if -drop +acpipresent? if printmenuitem . Boot FreeBSD with ACPI bootacpikey ! acpienabled? if . disabled -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: invalid PDPE on recend amd64
On Sun, Nov 7, 2010 at 3:28 AM, Alan Cox a...@rice.edu wrote: This is a different type of BIOS misconfiguration than your machine had. I'm attaching a possible patch for this one. Sorry for replying late. This patch works for me. The source tree was cvsup on Sunday before previous mail. Thank you! Jia-Shiun. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Only display ACPI bootmenu key if ACPI is present
On Wednesday, November 10, 2010 8:57:35 am John Baldwin wrote: On Tuesday, November 09, 2010 5:58:13 pm C. P. Ghost wrote: On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin j...@freebsd.org wrote: This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? Wouldn't that be a POLA violation? Some admins may be used to the current menu, and would be scratching head as what went wrong. Maybe it would be better to keep the menu option, but make it non-selectable and print next to it something like (not available)? Hmmm, I'll see if I can leave the numbering unchanged but not list the item perhaps. Note that we already have the alternate numbering on other platforms so the menu is already inconsistent across FreeBSD platforms. It turned out to be easier to leave a blank line to do this, but this patch does that. It leaves the numbers unchanged but simply omits the '2' option if the system does not support ACPI. --- //depot/projects/smpng/sys/boot/forth/beastie.4th 2010-11-08 21:53:18.0 +++ //depot/user/jhb/ktrace/boot/forth/beastie.4th 2010-11-10 14:50:44.0 @@ -140,12 +140,16 @@ fbsdbw-logo ; -: acpienabled? ( -- flag ) +: acpipresent? ( -- flag ) s hint.acpi.0.rsdp getenv dup -1 = if drop false exit then 2drop + true +; + +: acpienabled? ( -- flag ) s hint.acpi.0.disabled getenv dup -1 if s 0 compare 0 if @@ -180,11 +184,18 @@ printmenuitem . Boot FreeBSD [default] bootkey ! s arch-i386 environment? if drop - printmenuitem . Boot FreeBSD with ACPI bootacpikey ! - acpienabled? if - . disabled + acpipresent? if + printmenuitem . Boot FreeBSD with ACPI bootacpikey ! + acpienabled? if + . disabled + else + . enabled + then else - . enabled + menuidx @ + 1+ dup + menuidx ! + -2 bootacpikey ! then else -2 bootacpikey ! -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: another fuse panic
On 10 November 2010 09:34, Andriy Gapon a...@freebsd.org wrote: on 08/11/2010 14:13 Andriy Gapon said the following: on 08/11/2010 13:55 Andriy Gapon said the following: I reliable got this panic when all I was doing is saving an attachment in thunderbird 3 that ran in KDE 4 environment. Not sure what was going on behind the scenes, but shouldn't have been anything out of the ordinary. Perhaps this is my local mistake. I can't see from code and crash dump how NULL pointer is possible there. So perhaps I have some ABI mismatch between kernel and fuse module. I will rebuild fuse kmod and re-test again. Yes, the rebuild has helped. I wish this could be nicely automated. Hi. If I understood you correctly, then you need PORTS_MODULES set in /etc/make.conf. -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: minidump size on amd64
Andriy Gapon wrote:
on 09/11/2010 10:02 Alan Cox said the following:
The kernel portion of the patch looks correct. If I were to make one stylistic
suggestion, it would be to make the control flow of the outer and inner loops as
similar as possible, that is,
for (...
if ((pdp[i] PG_V) == 0) {
...
continue;
}
if ((pdp[i] PG_PS) != 0) {
...
continue;
}
for (...
if ((pd[j] PG_V) == 0)
continue;
if ((pd[j] PG_PS) != 0) {
...
continue;
}
for (...
if ((pt[x] PG_V) == 0)
continue;
...
I think this would make the code a little easier to follow.
This is a very nice suggestion, thank you.
Besides the uniformity some horizontal space is saved too :-)
Updated patch (only kernel part) is here:
http://people.freebsd.org/~avg/amd64-minidump.5.diff
In the later loop, where you actually write the page directory pages,
the va += ... in the following looks like a bug because you also
update va in for (...):
+
+ /* 1GB page is represented as 512 2MB pages in a dump */
+ if ((pdp[i] PG_PS) != 0) {
+ va += NBPDP;
My last three comments are:
1. I would move the assignment
i = (va PDPSHIFT) ((1ul NPDPEPGSHIFT) - 1);
so that it comes after
pmapsize += PAGE_SIZE;
2. The outermost ()'s aren't needed in the following statement:
j = ((va PDRSHIFT) ((1ul NPDEPGSHIFT) - 1));
3. I would suggest rewriting the following:
+ pa = pdp[i] PG_PS_FRAME;
+ for (j = 0; j NPDEPG; j++)
+ fakepd[j] = (pa + (j PDRSHIFT)) |
+ PG_V | PG_PS | PG_RW | PG_A | PG_M;
fakepd[0] = pdp[i];
for (j = 1; j NPDEPG; j++)
fakepd[j] = fakepd[j - 1] + NBPDR;
Then, whatever properties the pdp entry has will be inherited by the pd
entry.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: another fuse panic
on 10/11/2010 20:26 Sergey Kandaurov said the following: Hi. If I understood you correctly, then you need PORTS_MODULES set in /etc/make.conf. It was a long time ago when I tried it last time, but I remember having problems with it during upgrades. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: another fuse panic
on 10/11/2010 21:08 Andriy Gapon said the following: on 10/11/2010 20:26 Sergey Kandaurov said the following: Hi. If I understood you correctly, then you need PORTS_MODULES set in /etc/make.conf. It was a long time ago when I tried it last time, but I remember having problems with it during upgrades. I think this is what it was/is. If a port in PORTS_MODULES has dependencies, then buildkernel would try to install those dependencies even if they are already installed. And that, obviously, would fail. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: another fuse panic
On Wed, Nov 10, 2010 at 11:42 AM, Andriy Gapon a...@freebsd.org wrote: on 10/11/2010 21:08 Andriy Gapon said the following: on 10/11/2010 20:26 Sergey Kandaurov said the following: Hi. If I understood you correctly, then you need PORTS_MODULES set in /etc/make.conf. It was a long time ago when I tried it last time, but I remember having problems with it during upgrades. I think this is what it was/is. If a port in PORTS_MODULES has dependencies, then buildkernel would try to install those dependencies even if they are already installed. And that, obviously, would fail. Didn't know about this knob -- cool! And FWIW, all it does is a: all install: deinstall reinstall (huh?) reinstall: deinstall reinstall (huh?) clean Seems like it should be: clean all [deinstall] install clean or: clean all install -DFORCE_PKG_REGISTER clean the first clean is just in case the PORTSWORKDIR is dirty. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: another fuse panic
On Wed, Nov 10, 2010 at 12:18 PM, Garrett Cooper gcoo...@freebsd.org wrote:
On Wed, Nov 10, 2010 at 11:42 AM, Andriy Gapon a...@freebsd.org wrote:
on 10/11/2010 21:08 Andriy Gapon said the following:
on 10/11/2010 20:26 Sergey Kandaurov said the following:
Hi.
If I understood you correctly, then you need
PORTS_MODULES set in /etc/make.conf.
It was a long time ago when I tried it last time, but I remember having
problems
with it during upgrades.
I think this is what it was/is.
If a port in PORTS_MODULES has dependencies, then buildkernel would try to
install
those dependencies even if they are already installed. And that, obviously,
would
fail.
Didn't know about this knob -- cool!
And FWIW, all it does is a:
all
install: deinstall reinstall (huh?)
reinstall: deinstall reinstall (huh?)
clean
Seems like it should be:
clean
all
[deinstall]
install
clean
or:
clean
all
install -DFORCE_PKG_REGISTER
clean
the first clean is just in case the PORTSWORKDIR is dirty.
And FWIW an even better idea might be to align the port with the
process in use, i.e.
clean (i.e. NO_CLEAN, KERNFAST, etc not specified) -
[${PORTSDIR}/${PORT}] clean
buildkernel - [${PORTSDIR}/${PORT}] all
installkernel - [${PORTSDIR}/${PORT}] deinstall install
*shrugs*
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: issue with options DDB
On Tue Nov 9 10, Alexey Shuvaev wrote: On Tue, Nov 09, 2010 at 06:25:12PM +, Alexander Best wrote: On Fri Nov 5 10, Ulrich Spörlein wrote: On Sat, 30.10.2010 at 23:22:44 +, Alexander Best wrote: hi there, with options DDB in my kernel conf i run into the following issue with my kernel modules: link_elf_lookup_symbol: missing symbol hash table KLD file snd_hda.ko is missing dependencies KLD file sound.ko is missing dependencies KLD file nvidia.ko is missing dependencies KLD file linux.ko is missing dependencies KLD file ng_ubt.ko is missing dependencies KLD file ng_hci.ko is missing dependencies KLD file ng_bluetooth.ko is missing dependencies KLD file netgraph.ko is missing dependencies link_elf_lookup_symbol: missing symbol hash table removing the option solves the issue. any advice? cheers. alex ps: i'm running HEAD (r214542; amd64). You failed to mention the command that you run. I assume 'buildkernel'? Please note that you need and update-to-date buildworld for the kernel tools to be there, so please try the following (with options DDB): cd /usr/src make clean; make cleandir; make clean make buildworld make buildkernel KERNCONF=YOURKERNEL hmmmseems there is a problem with gcc. this is what i get during buildworld: clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc clang++: warning: argument unused during compilation: '-fconserve-space' ^^^ clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c building static supc++ library ranlib libsupc++.a === gnu/lib/libobjc (all) gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c *** Signal 11 Stop in /usr/src/gnu/lib/libobjc. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src.
Re: issue with options DDB
On Wed Nov 10 10, Alexander Best wrote: On Tue Nov 9 10, Alexey Shuvaev wrote: On Tue, Nov 09, 2010 at 06:25:12PM +, Alexander Best wrote: On Fri Nov 5 10, Ulrich Spörlein wrote: On Sat, 30.10.2010 at 23:22:44 +, Alexander Best wrote: hi there, with options DDB in my kernel conf i run into the following issue with my kernel modules: link_elf_lookup_symbol: missing symbol hash table KLD file snd_hda.ko is missing dependencies KLD file sound.ko is missing dependencies KLD file nvidia.ko is missing dependencies KLD file linux.ko is missing dependencies KLD file ng_ubt.ko is missing dependencies KLD file ng_hci.ko is missing dependencies KLD file ng_bluetooth.ko is missing dependencies KLD file netgraph.ko is missing dependencies link_elf_lookup_symbol: missing symbol hash table removing the option solves the issue. any advice? cheers. alex ps: i'm running HEAD (r214542; amd64). You failed to mention the command that you run. I assume 'buildkernel'? Please note that you need and update-to-date buildworld for the kernel tools to be there, so please try the following (with options DDB): cd /usr/src make clean; make cleandir; make clean make buildworld make buildkernel KERNCONF=YOURKERNEL hmmmseems there is a problem with gcc. this is what i get during buildworld: clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc clang++: warning: argument unused during compilation: '-fconserve-space' ^^^ clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c building static supc++ library ranlib libsupc++.a === gnu/lib/libobjc (all) gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c *** Signal 11 Stop in
Re: kldunload(8) returns 0, although it fail
On Tue Nov 9 10, John Baldwin wrote: On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: On Tue Nov 9 10, John Baldwin wrote: On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: hi there, i posted this message on freebsd-questions@, but nobody could help me with it. to me this looks like a bug, so i assume posting it again here on freebsd-current@ might be better. please keep in mind that the issue here is not the fact that the second attempt to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules have dependencies. however it should fail with the first attempt. right now kldunloadf() returns zero, whereas it should actually return EBUSY (just like the second attempt). i've attached two kdump outputs: one for the first 'kldunload' attempt and one for the second. as you can see the problem is that for some reason kldunloadf() returns zero, although it couldn't unload the module. Did you get an error message in dmesg? If you have manually loaded netgraph.ko (via netgraph_load=YES in loader.conf or an explicit kldload) and then loaded other modules that depend on it (such as ng_foo.ko) then this is expected behavior. What your kldunload has done is to remove the manual reference from loader.conf or 'kldload netgraph.ko'. What this changes is what happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then netgraph.ko will also be unloaded when its last reference drops (in this case it looks like you actually have two ng_*.ko objects loaded, so you would have to unload both of them, but I will assume a single ng_foo.ko to make the explanation simpler). If you had not done 'kldunload netgraph.ko' but had done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko loaded. All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. i have ng_ubt_load=YES in my loader.conf and kldstat says: Id Refs AddressSize Name 1 37 0x8010 a2ddb8 kernel 21 0x80b2e000 295e8snd_hda.ko 31 0x80b58000 85110sound.ko 41 0x80bde000 cf79e0 nvidia.ko 55 0x818d6000 418c0linux.ko 61 0x81918000 80e8 ng_ubt.ko 72 0x81921000 fa78 ng_hci.ko 82 0x81931000 2bd0 ng_bluetooth.ko 93 0x81934000 15e68netgraph.ko 101 0x81a12000 3efb linprocfs.ko 113 0x81a16000 4698 pseudofs.ko 121 0x81a1b000 31b3 procfs.ko 131 0x81a1f000 a37 linsysfs.ko 141 0x81a2 6f4 rtc.ko also the same happens with sound.ko. i have snd_hda_load=yes. and i think snd_hda is the only dependecy for sound.ko. there was no error message in dmesg for the first kldunload attempt. i think i understand the logic, however the current behavior does not confirm to the description in kldunload(2). Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko after boot? i'll try that in a minute. this behavior also seems very odd: 1) kldstat reports netgraph.ko *not* loaded 2) kldload netgraph 3) kldunload netgraph fails with EBUSY, although kldstat reports only a single REF for netgraph. could this be caused by an out of sync kernel and world? cheers. alex -- John Baldwin -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kldunload(8) returns 0, although it fail
On Wed Nov 10 10, Alexander Best wrote: On Tue Nov 9 10, John Baldwin wrote: On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: On Tue Nov 9 10, John Baldwin wrote: On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: hi there, i posted this message on freebsd-questions@, but nobody could help me with it. to me this looks like a bug, so i assume posting it again here on freebsd-current@ might be better. please keep in mind that the issue here is not the fact that the second attempt to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules have dependencies. however it should fail with the first attempt. right now kldunloadf() returns zero, whereas it should actually return EBUSY (just like the second attempt). i've attached two kdump outputs: one for the first 'kldunload' attempt and one for the second. as you can see the problem is that for some reason kldunloadf() returns zero, although it couldn't unload the module. Did you get an error message in dmesg? If you have manually loaded netgraph.ko (via netgraph_load=YES in loader.conf or an explicit kldload) and then loaded other modules that depend on it (such as ng_foo.ko) then this is expected behavior. What your kldunload has done is to remove the manual reference from loader.conf or 'kldload netgraph.ko'. What this changes is what happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then netgraph.ko will also be unloaded when its last reference drops (in this case it looks like you actually have two ng_*.ko objects loaded, so you would have to unload both of them, but I will assume a single ng_foo.ko to make the explanation simpler). If you had not done 'kldunload netgraph.ko' but had done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko loaded. All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. i have ng_ubt_load=YES in my loader.conf and kldstat says: Id Refs AddressSize Name 1 37 0x8010 a2ddb8 kernel 21 0x80b2e000 295e8snd_hda.ko 31 0x80b58000 85110sound.ko 41 0x80bde000 cf79e0 nvidia.ko 55 0x818d6000 418c0linux.ko 61 0x81918000 80e8 ng_ubt.ko 72 0x81921000 fa78 ng_hci.ko 82 0x81931000 2bd0 ng_bluetooth.ko 93 0x81934000 15e68netgraph.ko 101 0x81a12000 3efb linprocfs.ko 113 0x81a16000 4698 pseudofs.ko 121 0x81a1b000 31b3 procfs.ko 131 0x81a1f000 a37 linsysfs.ko 141 0x81a2 6f4 rtc.ko also the same happens with sound.ko. i have snd_hda_load=yes. and i think snd_hda is the only dependecy for sound.ko. there was no error message in dmesg for the first kldunload attempt. i think i understand the logic, however the current behavior does not confirm to the description in kldunload(2). Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko after boot? just tested and the behavior is *not* the same. when i do kldload ng_ubt after boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i try doing `kldunload netgraph` i get EBUSY the first time i run that command. when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of 3 for netgraph.ko and i get the behavior i described beforehand. cheers. alex i'll try that in a minute. this behavior also seems very odd: 1) kldstat reports netgraph.ko *not* loaded 2) kldload netgraph 3) kldunload netgraph fails with EBUSY, although kldstat reports only a single REF for netgraph. could this be caused by an out of sync kernel and world? cheers. alex -- John Baldwin -- a13x -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kldunload(8) returns 0, although it fail
On Wednesday, November 10, 2010 5:07:21 pm Alexander Best wrote: On Wed Nov 10 10, Alexander Best wrote: On Tue Nov 9 10, John Baldwin wrote: On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: On Tue Nov 9 10, John Baldwin wrote: On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: hi there, i posted this message on freebsd-questions@, but nobody could help me with it. to me this looks like a bug, so i assume posting it again here on freebsd-current@ might be better. please keep in mind that the issue here is not the fact that the second attempt to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules have dependencies. however it should fail with the first attempt. right now kldunloadf() returns zero, whereas it should actually return EBUSY (just like the second attempt). i've attached two kdump outputs: one for the first 'kldunload' attempt and one for the second. as you can see the problem is that for some reason kldunloadf() returns zero, although it couldn't unload the module. Did you get an error message in dmesg? If you have manually loaded netgraph.ko (via netgraph_load=YES in loader.conf or an explicit kldload) and then loaded other modules that depend on it (such as ng_foo.ko) then this is expected behavior. What your kldunload has done is to remove the manual reference from loader.conf or 'kldload netgraph.ko'. What this changes is what happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then netgraph.ko will also be unloaded when its last reference drops (in this case it looks like you actually have two ng_*.ko objects loaded, so you would have to unload both of them, but I will assume a single ng_foo.ko to make the explanation simpler). If you had not done 'kldunload netgraph.ko' but had done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko loaded. All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. i have ng_ubt_load=YES in my loader.conf and kldstat says: Id Refs AddressSize Name 1 37 0x8010 a2ddb8 kernel 21 0x80b2e000 295e8snd_hda.ko 31 0x80b58000 85110sound.ko 41 0x80bde000 cf79e0 nvidia.ko 55 0x818d6000 418c0linux.ko 61 0x81918000 80e8 ng_ubt.ko 72 0x81921000 fa78 ng_hci.ko 82 0x81931000 2bd0 ng_bluetooth.ko 93 0x81934000 15e68netgraph.ko 101 0x81a12000 3efb linprocfs.ko 113 0x81a16000 4698 pseudofs.ko 121 0x81a1b000 31b3 procfs.ko 131 0x81a1f000 a37 linsysfs.ko 141 0x81a2 6f4 rtc.ko also the same happens with sound.ko. i have snd_hda_load=yes. and i think snd_hda is the only dependecy for sound.ko. there was no error message in dmesg for the first kldunload attempt. i think i understand the logic, however the current behavior does not confirm to the description in kldunload(2). Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko after boot? just tested and the behavior is *not* the same. when i do kldload ng_ubt after boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i try doing `kldunload netgraph` i get EBUSY the first time i run that command. when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of 3 for netgraph.ko and i get the behavior i described beforehand. Try doing 'kldload netgraph.ko' and then 'kldload ng_ubt.ko' (along with manually loading any other netgraph modules so that nothing is loaded magically as a dependency) and see what behavior that gives you. When you load modules from the loader, they and all their dependencies are treated as if you had manually loaded them similar to kldload. This because the kernel can't determine which modules loaded by the loader were silent dependencies. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips/mips
TB --- 2010-11-10 22:21:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 22:21:49 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-10 22:21:49 - cleaning the object tree TB --- 2010-11-10 22:21:49 - cvsupping the source tree TB --- 2010-11-10 22:21:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-10 22:22:07 - building world TB --- 2010-11-10 22:22:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 22:22:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 22:22:07 - TARGET=mips TB --- 2010-11-10 22:22:07 - TARGET_ARCH=mips TB --- 2010-11-10 22:22:07 - TZ=UTC TB --- 2010-11-10 22:22:07 - __MAKE_CONF=/dev/null TB --- 2010-11-10 22:22:07 - cd /src TB --- 2010-11-10 22:22:07 - /usr/bin/make -B buildworld /src/Makefile.inc1, line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-10 22:22:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 22:22:10 - ERROR: failed to build world TB --- 2010-11-10 22:22:10 - 2.12 user 6.92 system 20.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-11-10 22:41:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 22:41:54 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-10 22:41:54 - cleaning the object tree TB --- 2010-11-10 22:41:57 - cvsupping the source tree TB --- 2010-11-10 22:41:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-10 22:42:13 - building world TB --- 2010-11-10 22:42:13 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 22:42:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 22:42:13 - TARGET=powerpc TB --- 2010-11-10 22:42:13 - TARGET_ARCH=powerpc64 TB --- 2010-11-10 22:42:13 - TZ=UTC TB --- 2010-11-10 22:42:13 - __MAKE_CONF=/dev/null TB --- 2010-11-10 22:42:13 - cd /src TB --- 2010-11-10 22:42:13 - /usr/bin/make -B buildworld World build started on Wed Nov 10 22:42:14 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap === gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk optionlist options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name=config.h system.h coretypes.h tm.h optionlist options.c TARGET_CPU_DEFAULT=\powerpc64\ HEADERS=auto-host.h ansidecl.h DEFINES= /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT=\powerpc64\ HEADERS=options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h DEFINES= /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-10 22:47:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 22:47:04 - ERROR: failed to build world TB --- 2010-11-10 22:47:04 - 206.12 user 55.98 system 309.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Non-sleepable locks PANIC in sf(4)
Script started on Wed Nov 10 15:56:31 2010 FreeBSD 9.0-CURRENT #644 r215099M: Wed Nov 10 11:45:01 PST 2010 obr...@dragon:/usr/obj/4kib/i386/compile/DRAGON-WITNESS i386 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. [..] Setting hostname: dragon.NUXI.org. sf0: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8800-0x88ff mem 0xfa48-0xfa4f irq 26 at device 4.0 on pci3 miibus1: MII bus on sf0 ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf0: Ethernet address: 00:00:d1:ed:81:95 sf1: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8400-0x84ff mem 0xfa38-0xfa3f irq 27 at device 5.0 on pci3 miibus2: MII bus on sf1 ukphy1: Generic IEEE 802.3u media interface PHY 1 on miibus2 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf1: Ethernet address: 00:00:d1:ed:81:96 sf2: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x8000-0x80ff mem 0xfa30-0xfa37 irq 24 at device 6.0 on pci3 miibus3: MII bus on sf2 ukphy2: Generic IEEE 802.3u media interface PHY 1 on miibus3 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf2: Ethernet address: 00:00:d1:ed:81:97 sf3: Adaptec ANA-62044 (rev 1) 10/100BaseTX port 0x7800-0x78ff mem 0xfa20-0xfa27 irq 25 at device 7.0 on pci3 miibus4: MII bus on sf3 ukphy3: Generic IEEE 802.3u media interface PHY 1 on miibus4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sf3: Ethernet address: 00:00:d1:ed:81:98 Expensive timeout(9) function: 0xc061b270(0xc65965a0) 1.987919972 s [..] Starting Network: lo0 bge0 sf0 em0. [..] sf0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU ether 00:00:d1:ed:81:95 inet 74.95.12.85 netmask 0xfffc broadcast 74.95.12.87 inet6 fe80::200:d1ff:feed:8195%sf0 prefixlen 64 tentative scopeid 0x5 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active [..] Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex sf0 (network driver) r = 0 (0xc722b584) locked @ /usr/obj/4kib/modules/sf/../../dev/sf/if_sf.c:1862 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,c6be8a80,4,c0a83ba0,c704164c,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(746,0,,c0a83b94,daaa2ac0,...) at 0xc061152a = kdb_backtrace+0x2a _witness_debugger(c08898ba,daaa2ad4,4,1,0,...) at 0xc0626256 = _witness_debugger+0x26 witness_warn(5,0,c08b2265,246,c70415a0,...) at 0xc062776d = witness_warn+0x1fd trap(daaa2bac) at 0xc08214bd = trap+0x2ad calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125 ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac fork_exit(c05b5500,c65dd830,daaa2d28) at 0xc05b24e8 = fork_exit+0xb8 fork_trampoline() at 0xc080b9e4 = fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdaaa2d60, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x40c fault code = supervisor read, page not present instruction pointer = 0x20:0xc08077c4 stack pointer = 0x28:0xdaaa2bec frame pointer = 0x28:0xdaaa2c00 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 (irq26: sf0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c08870ef,d31206e,2c66000a,70797420,78302065,...) at 0xc04ed726 = db_trace_self_wrapper+0x26 kdb_backtrace(c08b0bbd,0,c086c89f,daaa2a88,0,...) at 0xc061152a = kdb_backtrace+0x2a panic(c086c89f,c08b226c,c7041748,1,1,...) at 0xc05de537 = panic+0x117 trap_fatal(5,0,c08b2265,246,c70415a0,...) at 0xc0820ee5 = trap_fatal+0x325 trap(daaa2bac) at 0xc08214ce = trap+0x2be calltrap() at 0xc080b93c = calltrap+0x6 --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 --- _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54 sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3 sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248 intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125
