Re: igb(4) panic: already enqueue
Jack, I am also seeing similar panics at $work on a couple weeks old STABLE-9. Can you please look into this issue? cheers, Hiren 1) HP DL360e Gen8, 2 x Xeon E5-2430 2.20GHz panic: buf=0xfe002810d700 already enqueue at 995 prod=997 cons=995 cpuid = 17 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff868637b030 kdb_backtrace() at kdb_backtrace+0x37/frame 0xff868637b0f0 panic() at panic+0x1d8/frame 0xff868637b1f0 igb_mq_start() at igb_mq_start+0x1cb/frame 0xff868637b240 ether_output_frame() at ether_output_frame+0x33/frame 0xff868637b260 ether_output() at ether_output+0x52d/frame 0xff868637b2f0 ip_output() at ip_output+0xe38/frame 0xff868637b3e0 tcp_output() at tcp_output+0x122c/frame 0xff868637b5a0 tcp_do_segment() at tcp_do_segment+0x306c/frame 0xff868637b6c0 tcp_input() at tcp_input+0x909/frame 0xff868637b7f0 ip_input() at ip_input+0xbd/frame 0xff868637b840 netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xff868637b8a0 ether_demux() at ether_demux+0x17d/frame 0xff868637b8d0 ether_nh_input() at ether_nh_input+0x208/frame 0xff868637b910 netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xff868637b970 igb_rxeof() at igb_rxeof+0x394/frame 0xff868637b9e0 igb_handle_que() at igb_handle_que+0x9b/frame 0xff868637ba20 taskqueue_run_locked() at taskqueue_run_locked+0x93/frame 0xff868637ba80 taskqueue_thread_loop() at taskqueue_thread_loop+0x3e/frame 0xff868637baa0 fork_exit() at fork_exit+0x135/frame 0xff868637baf0 fork_trampoline() at fork_trampoline+0xe/frame 0xff868637baf0 2) HP DL160 G6, 2 x Xeon E5620 2.40GHz panic: buf=0xfe01b6334700 already enqueue at 42 prod=43 cons=42 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff800037a620 kdb_backtrace() at kdb_backtrace+0x37/frame 0xff800037a6e0 panic() at panic+0x1d8/frame 0xff800037a7e0 igb_mq_start() at igb_mq_start+0x1cb/frame 0xff800037a830 ether_output_frame() at ether_output_frame+0x33/frame 0xff800037a850 ether_output() at ether_output+0x52d/frame 0xff800037a8e0 ip_output() at ip_output+0xe38/frame 0xff800037a9d0 syncache_respond() at syncache_respond+0x462/frame 0xff800037aa90 syncache_timer() at syncache_timer+0xdf/frame 0xff800037aac0 softclock() at softclock+0x2c6/frame 0xff800037ab60 intr_event_execute_handlers() at intr_event_execute_handlers+0x6a/frame 0xff800037ab90 ithread_loop() at ithread_loop+0xac/frame 0xff800037abe0 fork_exit() at fork_exit+0x135/frame 0xff800037ac30 fork_trampoline() at fork_trampoline+0xe/frame 0xff800037ac30 ___ 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: igb(4) panic: already enqueue
Give the new driver I just committed to HEAD a try to verify/falsify a fix please. Regards, Jack On Wed, Oct 9, 2013 at 10:23 AM, hiren panchasara < hiren.panchas...@gmail.com> wrote: > Jack, > I am also seeing similar panics at $work on a couple weeks old STABLE-9. > > Can you please look into this issue? > > cheers, > Hiren > > 1) HP DL360e Gen8, 2 x Xeon E5-2430 2.20GHz > > panic: buf=0xfe002810d700 already enqueue at 995 prod=997 cons=995 > cpuid = 17 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > 0xff868637b030 > kdb_backtrace() at kdb_backtrace+0x37/frame 0xff868637b0f0 > panic() at panic+0x1d8/frame 0xff868637b1f0 > igb_mq_start() at igb_mq_start+0x1cb/frame 0xff868637b240 > ether_output_frame() at ether_output_frame+0x33/frame 0xff868637b260 > ether_output() at ether_output+0x52d/frame 0xff868637b2f0 > ip_output() at ip_output+0xe38/frame 0xff868637b3e0 > tcp_output() at tcp_output+0x122c/frame 0xff868637b5a0 > tcp_do_segment() at tcp_do_segment+0x306c/frame 0xff868637b6c0 > tcp_input() at tcp_input+0x909/frame 0xff868637b7f0 > ip_input() at ip_input+0xbd/frame 0xff868637b840 > netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xff868637b8a0 > ether_demux() at ether_demux+0x17d/frame 0xff868637b8d0 > ether_nh_input() at ether_nh_input+0x208/frame 0xff868637b910 > netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xff868637b970 > igb_rxeof() at igb_rxeof+0x394/frame 0xff868637b9e0 > igb_handle_que() at igb_handle_que+0x9b/frame 0xff868637ba20 > taskqueue_run_locked() at taskqueue_run_locked+0x93/frame > 0xff868637ba80 > taskqueue_thread_loop() at taskqueue_thread_loop+0x3e/frame > 0xff868637baa0 > fork_exit() at fork_exit+0x135/frame 0xff868637baf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xff868637baf0 > > 2) HP DL160 G6, 2 x Xeon E5620 2.40GHz > > panic: buf=0xfe01b6334700 already enqueue at 42 prod=43 cons=42 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > 0xff800037a620 > kdb_backtrace() at kdb_backtrace+0x37/frame 0xff800037a6e0 > panic() at panic+0x1d8/frame 0xff800037a7e0 > igb_mq_start() at igb_mq_start+0x1cb/frame 0xff800037a830 > ether_output_frame() at ether_output_frame+0x33/frame 0xff800037a850 > ether_output() at ether_output+0x52d/frame 0xff800037a8e0 > ip_output() at ip_output+0xe38/frame 0xff800037a9d0 > syncache_respond() at syncache_respond+0x462/frame 0xff800037aa90 > syncache_timer() at syncache_timer+0xdf/frame 0xff800037aac0 > softclock() at softclock+0x2c6/frame 0xff800037ab60 > intr_event_execute_handlers() at > intr_event_execute_handlers+0x6a/frame 0xff800037ab90 > ithread_loop() at ithread_loop+0xac/frame 0xff800037abe0 > fork_exit() at fork_exit+0x135/frame 0xff800037ac30 > fork_trampoline() at fork_trampoline+0xe/frame 0xff800037ac30 > ___ 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/182665: [wlan] Kernel panic when creating second wlandev.
The following reply was made to PR kern/182665; it has been noted by GNATS. From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= To: bug-follo...@freebsd.org, pe...@pean.org Cc: Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. Date: Wed, 9 Oct 2013 20:08:09 +0200 pciconf -lv ath0@pci0:7:0:0: class=3D0x028000 card=3D0x3114168c = chip=3D0x0030168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR9300 Wireless LAN adaptor' class =3D network ath1@pci0:13:0:0: class=3D0x028000 card=3D0x30a1168c = chip=3D0x002b168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR9285 Wireless Network Adapter (PCI-Express)' class =3D network= ___ 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/182665: [wlan] Kernel panic when creating second wlandev.
Hi, Is there a backtrace for this? Iv'e not seen this before. -adrian On 9 October 2013 11:10, Peter Ankerstål wrote: > The following reply was made to PR kern/182665; it has been noted by GNATS. > > From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= > To: bug-follo...@freebsd.org, > pe...@pean.org > Cc: > Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. > Date: Wed, 9 Oct 2013 20:08:09 +0200 > > pciconf -lv > > ath0@pci0:7:0:0: class=3D0x028000 card=3D0x3114168c = > chip=3D0x0030168c rev=3D0x01 hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D 'AR9300 Wireless LAN adaptor' > class =3D network > > ath1@pci0:13:0:0: class=3D0x028000 card=3D0x30a1168c = > chip=3D0x002b168c rev=3D0x01 hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D 'AR9285 Wireless Network Adapter (PCI-Express)' > class =3D network= > > ___ > 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" > ___ 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"
[ieee80211] [patch] BPF taps not working for ieee80211 interfaces in monitor mode
Hi, A bug was introduced in r254082 that results in BPF taps never being enabled for ieee80211 interfaces that are in monitor mode. Before r254082, bpf_track() in sys/net80211/ieee80211_freebsd.c was identifying ieee80211 interfaces by checking to see if the value of the ifp->if_start pointer was equal to ieee80211_start. r254082 was a move away from using if_start to using if_transmit in the ieee80211 stack, and bpf_track() was correspondingly updated to check the value of ifp->if_transmit against ieee80211_vap_transmit. The problem is that ifp->if_transmit is set to null_transmit by ieee80211_vap_attach() in sys/net80211/ieee80211.c for interfaces that are in monitor mode (code that has been in place since r195846). One fix that resolves the issue is to use what is likely to be a more stable signature in the check in bpf_track(). A patch against r256155 is attached. -Patrick ieee80211_bpf_track.patch Description: Binary data ___ 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"
Traceroute6 with larger datalen fails?
Hi, Does this look familiar to you? Or Have anyone encountered an error like this with traceroute6? Or Am i missing anything here? Thanks. --- Example --- % traceroute6 fd20:8b1e:b255:800b:250:56ff:fe82:1b09 50 traceroute6 to fd20:8b1e:b255:800b:250:56ff:fe82:1b09 (fd20:8b1e:b255:800b:250:56ff:fe82:1b09) from fd20:8b1e:b255:814e:7e53:4041:1ffa:db52, 64 hops max, 50 byte packets 1 fd20:8b1e:b255:814e::11 1.129 ms 1.132 ms 0.817 ms 2 fd20:8b1e:b255:800b:250:56ff:fe82:1b09 1.314 ms 1.492 ms 0.703 ms % traceroute6 fd20:8b1e:b255:800b:250:56ff:fe82:1b09 60 traceroute6 to fd20:8b1e:b255:800b:250:56ff:fe82:1b09 (fd20:8b1e:b255:800b:250:56ff:fe82:1b09) from fd20:8b1e:b255:814e:7e53:4041:1ffa:db52, 64 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * *^C ___ 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"
