Kernel panic from interface address list manipulation
I’ve been able to trivially trigger a kernel panic while testing ifaddr list manipulation on –CURRENT (r 211427). The hardware is a four-core i386 machine with em interfaces. This is the test script I’ve used to trigger the problem: #!/bin/sh addr_loop() { while true do ifconfig em1 1.0.0.1/24 ifconfig em1 -alias 1.0.0.1 done } addr_loop & addr_loop & With WITNESS and INVARIANTS the panic happens immediately upon starting the script, with the following backtrace: panic: Bad link elm 0xd17aec00 prev->next != elm #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc088a4ef in boot (howto=260) at /d2/head/sys/kern/kern_shutdown.c:416 #2 0xc088a7bb in panic (fmt=Variable "fmt" is not available. ) at /d2/head/sys/kern/kern_shutdown.c:590 #3 0xc098caf8 in in_control (so=0xd30af4d4, cmd=2151704858, data=0xd1923b80 "em1", ifp=0xd1554800, td=0xd31262c0) at /d2/head/sys/netinet/in.c:602 #4 0xc0938869 in ifioctl (so=0xd30af4d4, cmd=2151704858, data=0xd1923b80 "em1", td=0xd31262c0) at /d2/head/sys/net/if.c:2469 #5 0xc08d7e6b in soo_ioctl (fp=0xd2540ce8, cmd=2151704858, data=0xd1923b80, active_cred=0xd2594900, td=0xd31262c0) at /d2/head/sys/kern/sys_socket.c:212 #6 0xc08d2075 in kern_ioctl (td=0xd31262c0, fd=3, com=2151704858, data=0xd1923b80 "em1") at file.h:254 #7 0xc08d21e2 in ioctl (td=0xd31262c0, uap=0xf3a2ecec) at /d2/head/sys/kern/sys_generic.c:678 #8 0xc08c77d8 in syscallenter (td=0xd31262c0, sa=0xf3a2ece4) at /d2/head/sys/kern/subr_trap.c:319 #9 0xc0bb18f3 in syscall (frame=0xf3a2ed28) at /d2/head/sys/i386/i386/trap.c:1060 #10 0xc0b9a231 in Xint0x80_syscall () at /d2/head/sys/i386/i386/exception.s:264 #11 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) I’ve also reproduced it without WITNESS and INVARIANTS, but it seems to need additional copies of the script running simultaneously and still takes longer to panic. I’ve produced several different backtraces from the non-debugging kernel. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/147245: [dummynet] dummynet skip traffic over configured limit with net.inet.ip.dummynet.io_fast:1
Synopsis: [dummynet] dummynet skip traffic over configured limit with net.inet.ip.dummynet.io_fast:1 Responsible-Changed-From-To: freebsd-net->oleg Responsible-Changed-By: oleg Responsible-Changed-When: Tue Aug 17 17:05:24 UTC 2010 Responsible-Changed-Why: i'll look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=147245 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/147824: [msk]: watchdog timeouts
The following reply was made to PR kern/147824; it has been noted by GNATS. From: Ihsan Junaidi Ibrahim To: bug-follo...@freebsd.org, d...@edarb.com Cc: Subject: Re: kern/147824: [msk]: watchdog timeouts Date: Wed, 18 Aug 2010 02:29:09 +0800 --0015174c0fe2fb030f048e091f88 Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm also having this issue on the same model of motherboard except that I'm running on a 100mbps network. I would get watchdog timeouts and TX descriptor errors more frequently then not even there is minimal network activity i.e. just SSH in the box. I'm running 8.1-RELEASE. mskc0: port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:ea:01:15:c6:52 miibus0: on msk0 mskc0: [ITHREAD] msk0: link state changed to UP msk0: watchdog timeout msk0: link state changed to DOWN msk0: link state changed to UP Having TSO and MSI disabled in sysctl and loader respectively does not appear to have any improvement. Additionally the kernel would panic when booting, this happens 1 in every 2 tries: Aug 18 01:35:26 kernel: mskc0: port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2 Aug 18 01:35:26 kernel: msk0: on mskc0 Aug 18 01:35:26 kernel: msk0: Ethernet address: ff:ff:ff:ff:ff:ff Aug 18 01:35:26 kernel: msk0: No PHY found! ... Panic message ensues This happens regardless whether the cable is plugged or not. Normal booting would be like this: Aug 18 01:35:26 kernel: mskc0: port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2 Aug 18 01:35:26 kernel: msk0: on mskc0 Aug 18 01:35:26 kernel: msk0: Ethernet address: 00:ea:01:15:c6:52 Aug 18 01:35:26 kernel: miibus0: on msk0 Aug 18 01:35:26 kernel: e1000phy0: PHY 0 on miibus0 Aug 18 01:35:26 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Aug 18 01:35:26 kernel: mskc0: [ITHREAD] # ifconfig msk0 msk0: flags=8843 metric 0 mtu 1500 options=c011a ether 00:ea:01:15:c6:52 inet 192.168.2.10 netmask 0xff00 broadcast 192.168.2.255 media: Ethernet autoselect (100baseTX ) status: active -- Thank you for your time, Ihsan Junaidi Ibrahim --0015174c0fe2fb030f048e091f88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,I'm also having this issue on the same model of = motherboard except that I'm running on a 100mbps network. I would get w= atchdog timeouts and TX descriptor errors more frequently then not even the= re is minimal network activity i.e. just SSH in the box. I'm running 8.= 1-RELEASE. mskc0:p= ort 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2msk0: on mskc0 msk0: Ethernet address: 00:ea:01:15:c6:52miibus0: on msk0mskc0: [ITHREAD]msk0: link state change= d to UPmsk0: watchdog timeoutmsk0: link state changed= to DOWN msk0: link state changed to UPHaving TSO and= MSI disabled in sysctl and loader respectively does not appear to have any= improvement.Additionally the kernel would panic = when booting, this happens 1 in every 2 tries: Aug 18 01:35:26 =A0kernel: mskc0: port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq = 18 at device 0.0 on pci2Aug 18 01:35:26 =A0kernel: msk0: on mskc0 Aug 18 01:35:26 =A0kernel: msk0: Ethernet address: ff:ff:ff:ff:ff:ffAug 18 01:35:26 =A0kernel: msk0: No PHY found!...= Panic message ensuesThis happens regardless = whether the cable is plugged or not. Normal booting would be like this:= Aug 18 01:35:26 =A0kernel: mskc0: port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at devi= ce 0.0 on pci2 Aug 18 01:35:26 =A0kernel: msk0: on mskc0Aug 18 01:35:26 =A0kern= el: msk0: Ethernet address: 00:ea:01:15:c6:52Aug 18 01:35:26 =A0= kernel: miibus0: on msk0 Aug 18 01:35:26 =A0kernel: e1000phy0: metric 0 mtu 1500=A0=A0 =A0 =A0 =A0opt= ions=3Dc011a = ; =A0=A0 =A0 =A0 =A0ether 00:ea:01:15:c6:52=A0=A0 =A0 =A0 =A0= inet 192.168.2.10 netmask 0xff00 broadcast 192.168.2.255=A0= =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX )=A0=A0 =A0 =A0 =A0status: active -- Thank you for your time,Ihsan Junaidi Ibrah= im --0015174c0fe2fb
Re: kern/147824: [msk]: watchdog timeouts
The following reply was made to PR kern/147824; it has been noted by GNATS. From: Ihsan Junaidi Ibrahim To: bug-follo...@freebsd.org Cc: Subject: Re: kern/147824: [msk]: watchdog timeouts Date: Wed, 18 Aug 2010 06:14:13 +0800 Hi, I believe PR 116853 is related to this. -- Thank you for your time, Ihsan Junaidi Ibrahim ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/147824: [msk]: watchdog timeouts
The following reply was made to PR kern/147824; it has been noted by GNATS. From: Brad Degnan To: Ihsan Junaidi Ibrahim Cc: bug-follo...@freebsd.org Subject: Re: kern/147824: [msk]: watchdog timeouts Date: Tue, 17 Aug 2010 16:57:03 -0700 On 8/17/2010 11:29 AM, Ihsan Junaidi Ibrahim wrote: > Hi, > > I'm also having this issue on the same model of motherboard except that > I'm running on a 100mbps network. I would get watchdog timeouts and TX > descriptor errors more frequently then not even there is minimal network > activity i.e. just SSH in the box. I'm running 8.1-RELEASE. > > mskc0: port 0xe800-0xe8ff mem > 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2 > msk0: on > mskc0 > msk0: Ethernet address: 00:ea:01:15:c6:52 > miibus0: on msk0 > mskc0: [ITHREAD] > msk0: link state changed to UP > msk0: watchdog timeout > msk0: link state changed to DOWN > msk0: link state changed to UP > > Having TSO and MSI disabled in sysctl and loader respectively does not > appear to have any improvement. > I had to change the network interface to 100mbps half-duplex before the watchdog timeouts disappeared. It's definitely not optimal but works for me in the mean time. Full-duplex at 1000 and 100 and half-duplex at 1000 give me the watchdog timeouts and tx descriptor errors. Hope that helps > Additionally the kernel would panic when booting, this happens 1 in > every 2 tries: > > Aug 18 01:35:26 kernel: mskc0: > port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2 > Aug 18 01:35:26 kernel: msk0: Ultra Id 0xb4 Rev 0x05> on mskc0 > Aug 18 01:35:26 kernel: msk0: Ethernet address: ff:ff:ff:ff:ff:ff > Aug 18 01:35:26 kernel: msk0: No PHY found! > ... > Panic message ensues > > This happens regardless whether the cable is plugged or not. I haven't seen this yet, but I'm still on 8.1-PRERELEASE. I have no idea if downgrading would help. Do you have the latest bios? best, Brad ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: startup network configuration choice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/15/2010 08:42, Julian H. Stacey wrote: > Personally I have this in /etc/rc.conf, > host="mylap" ; domain="company.com" > host="mylap" ; domain="no.net" > host="mylap" ; domain="home.net" > hostname="$host.$domain" > case $hostname in #{ > "mylap.home.net") #{ > ifconfig_fxp0="inet 192.168.10.11" > # whatever other things too > ;; > "mylap.company.com") > ifconfig_fxp0="inet 10.. > ;; > ifco > "mylap.no.net") > ;; >esac This is not a bad configuration but lacks the ability to be booted into the right environment via a single keystroke or boot into its default. I was playing around with this idea a while back but do not really have a need for such a thing at this time as DHCP in most cases that I need it surfices for a client machine, and servers don't normally move unless the daemons carry them away. PS: do not let the daemons drink 'Red Bull'. The files that I was modifying to do just this was /etc/network.subr, /boot/beastie.4th and ultimately /etc/rc.conf. /etc/network.subr: * This needed the ability to parse kenv(1) for a variable I will call ``network_profile'' network_profile: * Initialized to an integer 0, 1, 2, 3. left unset defaulting to 0. /boot/beastie.4th: * Should be modified to contain entries that allow you to set the network_profile to the values stated above and then boot normally. /etc/rc.conf: * Would contain something similiar to what you have above but to just look at the value of network_profile and throw your ifconfig and whatever lines in its respective case statements. You might be able to set a kenv(1) variable through grub or other utilities from ports but still some modification would be needed to the beastie boot menu to allow you to change them dynamically. Another thought that had come to mind while doing the above was to create a script in /etc/rc.d that when run with keyword BEFORE NETWORK would wait for the user to press 1, 2, 3, 4 if network_profiles="YES" and then source its respective variables from /etc/netprofile.1 .2 .3 .4 and continue on its way through the rest of the configuration after a predetermined hard coded timeout. There is a ton of ways that you can go about doing this but the final approach is up to you as one does not exist in the base system at this time. Good luck & Regards, jhell,v - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMazoiAAoJEJBXh4mJ2FR+fK8IAKAO6NmMTrwmqse9mfCNw53o NU84VScWVbat97HwSP+7nfPuS9NV/VNI0jjasvNmW4nxXAUF10+Vc/ej683Juwrg Ds7t6ZaZaGxfYRHB8DFaLHnM38kwQDY+aZB2hU94/jX+OgV6KQainOQ+xjzEUxjj 9CCNHvsUP2XCKAyNhcUq9pMb8bB9QKsd10qAeaWRK2N+RPhXi4Z8IREmIB/i1A4/ nOIcuNmLwJ6qmjzIZBWEN7/WpE9AQy5IB9yu+Qqo10MyVqJWkZRqww9THOaiEv3L qRFTdQlkpQom0txV+6nA6c75rhd0P1aSlKC0X9U82aue8rQy+RfYESGHLgAoGNQ= =DFae -END PGP SIGNATURE- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/147824: [msk]: watchdog timeouts & Tx descriptor error
Synopsis: [msk]: watchdog timeouts & Tx descriptor error Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: andre Responsible-Changed-When: Wed Aug 18 06:28:13 UTC 2010 Responsible-Changed-Why: Over to yongari. http://www.freebsd.org/cgi/query-pr.cgi?pr=147824 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"