5.4-dropping to debugger
Hi, every once in a while (about once a week lately), one of my servers has been known to stop responding. Upon connecting the serial console, I find myself at a debugger prompt. This is the output I've gotten this time. I do think I have a debug kernel on that machine, what can I do to get more useful information out? PS: I have seen various kinds of instability on most of my 5.4- installations, no matter the patchlevel. This box is just one of many. Anyone? /Eirik db> db> c Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x2007010 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0581fe8 stack pointer = 0x10:0xe3384c40 frame pointer = 0x10:0xe3384c70 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 = 29 (irq18: fxp0) [thread pid 29 tid 10 ] Stopped at fxp_add_rfabuf+0x68:movw%ax,0xe(%ebx) db> trace Tracing pid 29 tid 10 td 0xc22a fxp_add_rfabuf(c2404000,c2404500,2,a6c54bb2,b51487f8) at fxp_add_rfabuf+0x68 fxp_intr_body(c2404000,c2404000,40,,8) at fxp_intr_body+0xf1 fxp_intr(c2404000,0,0,0,0) at fxp_intr+0x14e ithread_loop(c22f6500,e3384d38,0,0,0) at ithread_loop+0x1b8 fork_exit(c06a9150,c22f6500,e3384d38) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe3384d6c, ebp = 0 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.0-BETA3 panic: vm_fault
I have a low end DELL Lattitude that has been successfully running 5.4-RELEASE. I have tried loading 6.0-BETA3 three times and it panics every time early while loading the Minimal system. Does anyone else see this? (I haven't ruled out a disk problem) Hand transcribed from the screen: panic: vm_fault: fault on nofault entry: c7229000 cpuid = 0 [thread pid 26 100026] Stopped at kbd_enter_0x2b: nop For the install process, I pick "Standard", Give the whole disk to slice1 for FreeBSD and take the "Auto" partitions. I ask for a "Minimal" install. (side note: the new default partitions sizes seem strange:) 1a / 512MB 1b swap 230MB 1d /var 1139MB 1e /tmp 512MB 1f /usr 708MB I retried loading 5.4 Release, and it successfully installs. Here is the dmesg from a working 5.4-RELEASE Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (363.96-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x66a Stepping = 10 Features=0x183f9ff real memory = 134135808 (127 MB) avail memory = 121597952 (115 MB) npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf400-0xf7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcm0: mem 0xfda0-0xfdaf,0xf8c0-0xf8ff irq 5 at device 0.1 on pci1 pcm0: cbb0: at device 3.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 3.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x860-0x86f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at dev ice 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xece0-0xecff irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xcf800-0xc,0xcf000-0xcf7ff,0xce800-0xcefff,0xce000-0xce7ff,0xc pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 and -O2 option
Jim C. Nasby wrote: On Tue, Aug 30, 2005 at 10:57:53AM +1000, Robert Backhaus wrote: [ ... ] Simply because not every port works with -O2 optimisations. It caused bad code in some circumstances. Is there an automated way to identify those ports so they can be forced not to use -O higer than -O1? Regrettably, no. Well, -Werror might be somewhere between overkill and helpful, assuming the compiler can recognize a potential type-punning situation. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: thanks for commiting (MFC ffs_softdep.c 1.182, softdep.h 1.18) to RELENG_5 and 6. When in 4?
On Sat, 2005-08-27 at 03:51, Igor Sysoev wrote: > On Tue, 23 Aug 2005, Tomaz Borstnar wrote: > > >Would some kind soul MFC ffs_softdep.c 1.182, softdep.h 1.18 into > > RELENG_4 as well? This bug is also present in FreeBSD 4.x. Found it ever > > since 4.7. > > I saw this annoying bug at least since 4.5. I think the fix should be > merged not only to RELENG_4, but also at least to RELENG_4_11. > > I use very similar fix on two 4.10 machines and one 4.11 machine for 6 weeks. > Before the fix I had to reboot one of these machines at least once per month > and so. Now the bug has gone. > > Thank you, Stephan! Glad to hear your success. I finally managed to merge it into RELENG_4. (Sorry for the long delay) However I don't think we normally merge non-security related fixes to RELENG_4_11. (But I will ask around to make sure) Stephan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-dropping to debugger
On Wed, Aug 31, 2005 at 12:51:00PM +0200, Eirik ?verby wrote: > Hi, every once in a while (about once a week lately), one of my > servers has been known to stop responding. Upon connecting the serial > console, I find myself at a debugger prompt. This is the output I've > gotten this time. > > I do think I have a debug kernel on that machine, what can I do to > get more useful information out? See the chapter on kernel debugging in the developers' handbook. Kris > > PS: I have seen various kinds of instability on most of my 5.4- > installations, no matter the patchlevel. This box is just one of many. > > Anyone? > > /Eirik > > db> > db> c > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x2007010 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0581fe8 > stack pointer = 0x10:0xe3384c40 > frame pointer = 0x10:0xe3384c70 > 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 = 29 (irq18: fxp0) > [thread pid 29 tid 10 ] > Stopped at fxp_add_rfabuf+0x68:movw%ax,0xe(%ebx) > db> trace > Tracing pid 29 tid 10 td 0xc22a > fxp_add_rfabuf(c2404000,c2404500,2,a6c54bb2,b51487f8) at > fxp_add_rfabuf+0x68 > fxp_intr_body(c2404000,c2404000,40,,8) at fxp_intr_body+0xf1 > fxp_intr(c2404000,0,0,0,0) at fxp_intr+0x14e > ithread_loop(c22f6500,e3384d38,0,0,0) at ithread_loop+0x1b8 > fork_exit(c06a9150,c22f6500,e3384d38) at fork_exit+0x80 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe3384d6c, ebp = 0 --- > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > pgpsV2cIT4dyI.pgp Description: PGP signature
Re: thanks for commiting (MFC ffs_softdep.c 1.182, softdep.h 1.18) to RELENG_5 and 6. When in 4?
On Wed, 31 Aug 2005, Stephan Uphoff wrote: On Sat, 2005-08-27 at 03:51, Igor Sysoev wrote: On Tue, 23 Aug 2005, Tomaz Borstnar wrote: Would some kind soul MFC ffs_softdep.c 1.182, softdep.h 1.18 into RELENG_4 as well? This bug is also present in FreeBSD 4.x. Found it ever since 4.7. I saw this annoying bug at least since 4.5. I think the fix should be merged not only to RELENG_4, but also at least to RELENG_4_11. I use very similar fix on two 4.10 machines and one 4.11 machine for 6 weeks. Before the fix I had to reboot one of these machines at least once per month and so. Now the bug has gone. Thank you, Stephan! Glad to hear your success. I finally managed to merge it into RELENG_4. (Sorry for the long delay) However I don't think we normally merge non-security related fixes to RELENG_4_11. (But I will ask around to make sure) The bug is not directly security-related, however, I saw three various consequences of the bug: 1) The free space very quickly ends up. It usually happens when the big log files are used. I saw it very often. The only way to reclaim the space is to reboot. And then fsck would run on these partitions (and probably on other partitions if you forgot to umount them before reboot). 2) The free inodes ends up. I saw it once. Yes, the only way is the reboot. 2) The vnodes ends up. I saw it once: the most processes stuck in "inode" wchan. And yes, probably the only way is the hard reboot: you simply could not start the shutdown procedure. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-dropping to debugger
On Aug 31, 2005, at 8:28 PM, Kris Kennaway wrote: On Wed, Aug 31, 2005 at 12:51:00PM +0200, Eirik ?verby wrote: Hi, every once in a while (about once a week lately), one of my servers has been known to stop responding. Upon connecting the serial console, I find myself at a debugger prompt. This is the output I've gotten this time. I do think I have a debug kernel on that machine, what can I do to get more useful information out? See the chapter on kernel debugging in the developers' handbook. Sorry, poorly phrased question. Was in a bit of a hurry. I have a debug kernel, however I have no dump device (and cannot create one; I'm geom-mirroring my disks, and for some reason I'm not able to specify a dump device when that is the case (has been discussed in the past). I've been told that a debug kernel might still help, but the developers handbook does not say anything about what can be done without a dump. I know this has been up on one of the lists (current, stable or amd64) I'm on, so I guess I'll go ahead searching for it. Sorry about the noise. Was just hoping someone recognized the symptoms. /Eirik Kris PS: I have seen various kinds of instability on most of my 5.4- installations, no matter the patchlevel. This box is just one of many. Anyone? /Eirik db> db> c Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x2007010 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0581fe8 stack pointer = 0x10:0xe3384c40 frame pointer = 0x10:0xe3384c70 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 = 29 (irq18: fxp0) [thread pid 29 tid 10 ] Stopped at fxp_add_rfabuf+0x68:movw%ax,0xe(%ebx) db> trace Tracing pid 29 tid 10 td 0xc22a fxp_add_rfabuf(c2404000,c2404500,2,a6c54bb2,b51487f8) at fxp_add_rfabuf+0x68 fxp_intr_body(c2404000,c2404000,40,,8) at fxp_intr_body+0xf1 fxp_intr(c2404000,0,0,0,0) at fxp_intr+0x14e ithread_loop(c22f6500,e3384d38,0,0,0) at ithread_loop+0x1b8 fork_exit(c06a9150,c22f6500,e3384d38) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe3384d6c, ebp = 0 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- [EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall automatic filesystem size generation.
> From: "Darren Pilgrim" <[EMAIL PROTECTED]> > Date: Tue, 30 Aug 2005 23:07:16 -0700 > Sender: [EMAIL PROTECTED] > > From: Julian H. Stacey > > "Steven Hartland" wrote: > > > data. In addition to that I dont have to sit though 1 hour worth of > > > offline checks when it crashes for what ever reason which I do on > our > > > FreeBSD boxes. > > > > [Apologies if I missed something, coming in late on thread, but ...] > > > > FreeBSD-4 does fsck on dirty filesystems before going multi > > user: You wait. > > FreeBSD-5.* & 6.0-BETA3 : fsck runs in background after boot: > > No waiting. > > A dirty volume can cause some fairly severe problems if it's used before > the background fsck completes repairs. I'd rather delay restart than > face even more damage when something else dies because the volume was > mounted dirty. This should NOT be the case if you have softupdates enabled for a partition. And fsck should not background if the partition does not have soft updates enabled. If the volume with soft updates is mounted 'dirty', it should have NO implications other then not having all of the free space on the disk available until the fsck completes. Read-write access should always be safe and no data should be effected by the fsck. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 and -O2 option
On Wed, Aug 31, 2005 at 10:57:05AM -0400, Chuck Swiger wrote: > Jim C. Nasby wrote: > >On Tue, Aug 30, 2005 at 10:57:53AM +1000, Robert Backhaus wrote: > [ ... ] > >>Simply because not every port works with -O2 optimisations. It caused > >>bad code in some circumstances. > > > >Is there an automated way to identify those ports so they can be forced > >not to use -O higer than -O1? > > Regrettably, no. Well, -Werror might be somewhere between overkill and > helpful, assuming the compiler can recognize a potential type-punning > situation. Even if the identification can't be done automatically, it still seems like it would be good to start identifying ports that don't support -O by hand, and having the ports force a correct -O setting. Most ports support -O2 (if not -O3), and it would be nice if people could just put that option in their make.conf and be done with it. -- Jim C. Nasby, Database Architect[EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 and -O2 option
Jim C. Nasby wrote: Even if the identification can't be done automatically, it still seems like it would be good to start identifying ports that don't support -O by hand, and having the ports force a correct -O setting. Most ports support -O2 (if not -O3), and it would be nice if people could just put that option in their make.conf and be done with it. It would be even better if we had some way to handle ports that work with make -j n and those who don't, as it is now a SMP machine is a total waste when compiling ports. /Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 and -O2 option
On Tue, 30 Aug 2005 12:41:37 +0400 Boris Samorodov wrote: > On Sun, 28 Aug 2005 17:09:47 +0200 Rene Ladan wrote: > > On Sun, Aug 28, 2005 at 04:30:19PM +0400, Boris Samorodov wrote: > > > > > > As for 5.x notes about -O2 (libalias, gcc) were removed at revision > > > 1.229.2.7 of /usr/src/share/examples/etc/make.conf. But for 6.0-BETA3 > > > we do have these warnings. Should they be removed as for 5.x? Is it > > > safe to use -O2 to build/install kernel, world, ports fro 6.0? > > > > > Kernel and world seem to be ok with -O2, for ports it is not advised. > Well, as nobody complained so far, should I file a PR to remove notes > about -O2 to examples/etc/make.conf for 6.0-BETA3? OK. Here it is: - http://www.freebsd.org/cgi/query-pr.cgi?pr=85548 >Category: conf >Responsible:freebsd-bugs >Synopsis: share/examples/etc/make.conf: delete -O2 warnings for 6.0-BETA3 >Arrival-Date: Wed Aug 31 22:10:30 GMT 2005 - Who will take the resposibility? Oh, not all of you, guys... ;-) WBR -- bsam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WITNESS warning output from 6.0-BETA3
On Tue, 30 Aug 2005, Oliver Fromme wrote: I get the following output under FreeBSD 6.0-BETA3 when WITNESS is enabled. It doesn't seem to cause any harm, though. I cvsupped this system to RELENG_6 a few days ago. I have no idea what is causing this output, whether should worry about it, or even whether this is the right list to report or ask about it. :-) The output occurs when booting, right when the interface (bfe0) is configured for the first time. I have a small self-made script in /etc/rc.d which configures bfe0 several times with different IP addresses and performs a ping test in order to find out in which network the notebook is located, then symlinks various files in /etc depending on the result. The below output happens when that script is executed. This warning is a result of a mis-ordering in merging changes from HEAD to RELENG_6: locking changes were merged shortly before the memory allocation changes they depended in. The warning should be non-harmful (although irritating), and can be corrected by sliding forward a bit on the RELENG_6 branch to pick up the fix that followed a little later. If it isn't corrected by a move to at least if_ethersubr.c:1.177.2.5, please let me know. Thanks, Robert N M Watson Best regards Oliver malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex if_addr_mtx r = 0 (0xc23af260) locked @ /usr/src/sys/net/if.c:1905 KDB: stack backtrace: kdb_backtrace(1,40,c104d800,2,e4f46b1c) at kdb_backtrace+0x29 witness_warn(5,0,c06ebd16,c06d9c8c,40) at witness_warn+0x18e uma_zalloc_arg(c104d800,0,102) at uma_zalloc_arg+0x41 malloc(36,c071f4e0,102,0,c23af000) at malloc+0xae ether_resolvemulti(c23af000,e4f46b78,e4f46ba8,c2641bc4,0) at ether_resolvemulti+0x87 if_addmulti(c23af000,e4f46ba8,e4f46ba4,e4f46ba8,10) at if_addmulti+0x84 in_addmulti(e4f46bdc,c23af000) at in_addmulti+0x32 in_ifinit(c23af000,c2641b00,c2627550,0,e4f46c38) at in_ifinit+0x515 in_control(c2707b20,8040691a,c2627540,c23af000,c235b180) at in_control+0x882 ifioctl(c2707b20,8040691a,c2627540,c235b180,0) at ifioctl+0x198 soo_ioctl(c2662360,8040691a,c2627540,c225bd00,c235b180) at soo_ioctl+0x2db ioctl(c235b180,e4f46d04,3,1,286) at ioctl+0x370 syscall(3b,3b,3b,8056da0,0) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d0a97, esp = 0xbfbfe99c, ebp = 0xbfbfe9c8 --- malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex if_addr_mtx r = 0 (0xc23af260) locked @ /usr/src/sys/net/if.c:1905 KDB: stack backtrace: kdb_backtrace(1,40,c104d800,2,e4f469b0) at kdb_backtrace+0x29 witness_warn(5,0,c06ebd16,c06d9c8c,40) at witness_warn+0x18e uma_zalloc_arg(c104d800,0,102) at uma_zalloc_arg+0x41 malloc(36,c071f4e0,102,0,c23af000) at malloc+0xae ether_resolvemulti(c23af000,e4f46a0c,e4f46a3c,0,0) at ether_resolvemulti+0x124 if_addmulti(c23af000,e4f46a3c,e4f46a38,e4f46a3c,1c) at if_addmulti+0x84 in6_addmulti(e4f46a8c,c23af000,e4f46a84) at in6_addmulti+0x4c in6_update_ifa(c23af000,e4f46b8c,0) at in6_update_ifa+0x4cf in6_ifattach_linklocal(c23af000,0) at in6_ifattach_linklocal+0xe5 in6_ifattach(c23af000,0,8040691a,8040691a,0) at in6_ifattach+0xb9 in6_if_up(c23af000) at in6_if_up+0x13 ifioctl(c2707b20,8040691a,c2627540,c235b180,0) at ifioctl+0x1f8 soo_ioctl(c2662360,8040691a,c2627540,c225bd00,c235b180) at soo_ioctl+0x2db ioctl(c235b180,e4f46d04,3,1,286) at ioctl+0x370 syscall(3b,3b,3b,8056da0,0) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d0a97, esp = 0xbfbfe99c, ebp = 0xbfbfe9c8 --- malloc(M_WAITOK) of "64", forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex if_addr_mtx r = 0 (0xc23af260) locked @ /usr/src/sys/net/if.c:1905 KDB: stack backtrace: kdb_backtrace(1,40,c104d800,2,e4f46998) at kdb_backtrace+0x29 witness_warn(5,0,c06ebd16,c06d9c8c,40) at witness_warn+0x18e uma_zalloc_arg(c104d800,0,102) at uma_zalloc_arg+0x41 malloc(36,c071f4e0,102,0,c23af000) at malloc+0xae ether_resolvemulti(c23af000,e4f469f4,e4f46a24,c2619700,0) at ether_resolvemulti+0x124 if_addmulti(c23af000,e4f46a24,e4f46a20,e4f46a24,1c) at if_addmulti+0x84 in6_addmulti(e4f46ac4,c23af000,e4f46a84,1,e4f46abc,c261a8a0,e4f46a9c,101,0) at in6_addmulti+0x4c in6_update_ifa(c23af000,e4f46b8c,0) at in6_update_ifa+0x60d in6_ifattach_linklocal(c23af000,0) at in6_ifattach_linklocal+0xe5 in6_ifattach(c23af000,0,8040691a,8040691a,0) at in6_ifattach+0xb9 in6_if_up(c23af000) at in6_if_up+0x13 ifioctl(c2707b20,8040691a,c2627540,c235b180,0) at ifioctl+0x1f8 soo_ioctl(c2662360,8040691a,c2627540,c225bd00,c235b180) at soo_ioctl+0x2db ioctl(c235b180,e4f46d04,3,1,286) at ioctl+0x370 syscall(3b,3b,3b,8056da0,0) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d0a97, esp = 0xbfbfe99c, ebp = 0xbfbfe9c8 --- -- Oliver Fro
