From rwatson at FreeBSD.org Sun Feb 1 03:49:57 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Feb 1 03:50:03 2009 Subject: TCP gets special treatment? In-Reply-To: References: Message-ID: On Wed, 28 Jan 2009, Per Hurtig (work) wrote: > How differently are TCP packets treated compared to e.g. SCTP packets, while > traversing the FreeBSD network stack (up to and including the IP-layer when > using ipfw)?. I do not assume that the firewall (ipfw) is explicitly > configured to check for established sessions or any TCP specifics. Are there > a lot of TCP-specific optimizations conducted by lower layers anyways > (besides possible checksum offloading)? Hi Per: On the whole, TCP packets are treated like any other packet until they reach the tcp_input() function during the input path, and once they've entered ip_output() in the output path. There are some exceptions that I'm aware of, including: - ipfw(4) has special knowledge of the layout and semantics of TCP packets, including stateful tracking of TCP connections, etc. ipfw(4) is able use (output) or to look up (input) the local socket for the purposes of identifying the credential that was or may be associated with. Many of us consider this highly dubious behavior subject to race conditions and unexpected semantics, but it appears to be popular functionality. Other firewall packets, including pf(4) have this functionality as well. - The IP input protocol dispatch (in_proto.c) doesn't set PR_LASTHDR for TCP (and UDP for that matter) because IPSEC policy is aware of TCP-level properties, meaning that some IPSEC processing (policy checking) isn't performed in the normal IPSEC input path and instead deferred to the TCP input path. See ip_ipsec.c. - Various sorts of checksum offload and segmentation offload require TCP segments to be handled outside of the core TCP routines, including ip_output(), where deferred checksum calculations will be performed if it turns out the output interface doesn't support hardware checksumming, and where TSO segments may be rejected, and in device drivers that perform (for example) TSO and LSO and are therefore aware (in some form) of TCP processing. tcp_lso.c, for example, is entirely called from the device driver in order to perform early reassembly, if the device driver supports it (primarily 10gbps drivers). Robert N M Watson Computer Laboratory University of Cambridge From freebsd-listen at fabiankeil.de Sun Feb 1 07:28:44 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sun Feb 1 07:28:51 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090131125100.N983@desktop> References: <20090131125100.N983@desktop> Message-ID: <20090201160544.4f1961b4@fabiankeil.de> Jeff Roberson wrote: > http://people.freebsd.org/~jeff/mbuf_ref2.diff > I have been experimenting with different revisions to the mbuf api to > improve performance and simplify code. This patch is the first of > several proposed steps towards those goals. The aim of this patch is > two fold; > I would appreciate testing feedback from varied workloads to make sure > there are no bugs before I go forward with this. I have tested only > host oriented networking with a few drivers. It is not anticipated that > there will be any significant incompatibilities introduced with this > round but there is always that possibility. To compile without changing my kernel config I needed: --- .zfs/snapshot/2009-02-01/sys/kern/kern_mbuf.c 2009-02-01 14:13:18.678107513 +0100 +++ sys/kern/kern_mbuf.c 2009-02-01 14:24:56.006950417 +0100 @@ -222,7 +222,9 @@ /* * Local prototypes. */ +#ifdef INVARIANTS static int mb_ctor_pack(void *mem, int size, void *arg, int how); +#endif static void mb_dtor_pack(void *mem, int size, void *arg); static void mb_reclaim(void *); static int mb_zinit_pack(void *mem, int size, int how); I'm not familiar with how mbufs work on FreeBSD, so a few meta comments are all I got: 1) 508 +struct mbuf * 509 +_m_getjcl(int how, short type, int flags, int size, uma_zone_t zone, 510 + int exttype) 511 +{ 512 + struct mbuf *m; 513 + void *mem; 514 + 515 + switch (size) { 516 + case MCLBYTES: 517 + m = m_getcl(how, type, flags); 518 + break; 519 + default: [...] 526 + m = m_alloc(zone_ext, 0, how, type, flags); [...] 533 + break; 534 + } 535 + 536 + return (m); 537 +} Why do you use a switch statement if there are only two conditions? Is it to be somewhat symmetric to m_gettype()? Otherwise the indentation could be partly flattened with: if (size == MCLBYTES) return m_getcl(how, type, flags); [old default: code here] 2) 893 @@ -834,8 +753,9 @@ 894 m_dup(struct mbuf *m, int how) 895 { [...] 904 @@ -852,10 +772,8 @@ 905 /* Get the next new mbuf */ 906 if (remain >= MINCLSIZE) { 907 n = m_getcl(how, m->m_type, 0); 908 - nsize = MCLBYTES; 909 } else { 910 n = m_get(how, m->m_type); 911 - nsize = MLEN; 912 } The curly brackets are no longer required here. 3) 1595 static __inline struct mbuf * 1596 +m_alloc(uma_zone_t zone, int size, int how, short type, int flags) 1597 +{ [...] 1603 + if (type != MT_NOINIT) { 1604 + if (m_init(m, zone, size, how, type, flags)) { 1605 + uma_zfree(zone, m); 1606 + return (NULL); 1607 + } 1608 + } 1609 + return (m); 1610 +} Why don't you use a single if block here? 4) 1612 +/* 1613 + * Configure a provided mbuf to refer to the provided external storage 1614 + * buffer and setup a reference count for said buffer. 1615 + * 1616 + * Arguments: 1617 + * mb The existing mbuf to which to attach the provided buffer. 1618 + * buf The address of the provided external storage buffer. 1619 + * size The size of the provided buffer. 1620 + * freef A pointer to a routine that is responsible for freeing the 1621 + * provided external storage buffer. 1622 + * args A pointer to an argument structure (of any type) to be passed 1623 + * to the provided freef routine (may be NULL). 1624 + * flags Any other flags to be passed to the provided mbuf. 1625 + * type The type that the external storage buffer should be 1626 + * labeled with. 1627 + * 1628 + * Returns: 1629 + * Nothing. 1630 + */ 1631 +static __inline void 1632 +m_extadd(struct mbuf *mb, caddr_t buf, u_int size, 1633 + void (*freef)(void *, void *), void *arg1, void *arg2, int flags, int type) 1634 +{ Is the description for "args" meant to cover both arg1 and arg2? From the comment alone their differences aren't clear to me, but then again, that might just be because my lack of mbuf knowledge. I noticed that this is only relocated code, though. 5) Finally, I tested the patch on an IBM ThinPad R51. The kernel hangs on boot, the last messages are (hand transcribed): iwi0: mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 iwi0: could not allocate rx mbuf iwi0: could not allocate Rx ring bpfdetach: was not attached Booting without if_iwi.ko works and for em0 I get: em0: port 0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xc0220000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0x8000 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:11:... em0: Could not setup receive structures Without iwi0 I can't test the patch any further on this system at the moment, but I can probably give it a try on another system in the next days. I also wouldn't mind giving another patch a try. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090201/dceb1754/signature.pgp From freebsd-listen at fabiankeil.de Sun Feb 1 08:06:00 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sun Feb 1 08:06:07 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090201160544.4f1961b4@fabiankeil.de> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> Message-ID: <20090201170550.482bf325@fabiankeil.de> Fabian Keil wrote: > Jeff Roberson wrote: > > > http://people.freebsd.org/~jeff/mbuf_ref2.diff > > > I have been experimenting with different revisions to the mbuf api to > > improve performance and simplify code. This patch is the first of > > several proposed steps towards those goals. The aim of this patch is > > two fold; > > > I would appreciate testing feedback from varied workloads to make sure > > there are no bugs before I go forward with this. I have tested only > > host oriented networking with a few drivers. It is not anticipated > > that there will be any significant incompatibilities introduced with > > this round but there is always that possibility. > 5) > Finally, I tested the patch on an IBM ThinPad R51. The kernel > hangs on boot, the last messages are (hand transcribed): > > iwi0: mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 > iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 > iwi0: could not allocate rx mbuf > iwi0: could not allocate Rx ring > bpfdetach: was not attached Never mind, kernel and user land weren't completely in sync and this might be related to the recent wlan commits. I'll retry with an up-to-date user land. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090201/8ec1cbcf/signature.pgp From gavin at FreeBSD.org Sun Feb 1 13:05:30 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sun Feb 1 13:05:36 2009 Subject: kern/131087: [ipw] [panic] ipw / iwi - no sent/received packets; iwi needs to be restarted; ipw / iwi causes kernel panic Message-ID: <200902012105.n11L5S2w002573@freefall.freebsd.org> Synopsis: [ipw] [panic] ipw / iwi - no sent/received packets; iwi needs to be restarted; ipw / iwi causes kernel panic State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Sun Feb 1 21:01:03 UTC 2009 State-Changed-Why: To submitter: Can I please confirm that for problem 1, you are saying that simply loading the iwi driver is enough to change how the ipw driver works? Also, are you able to get a backtrace from the kernel panic please? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Feb 1 21:01:03 UTC 2009 Responsible-Changed-Why: Over to -net http://www.freebsd.org/cgi/query-pr.cgi?pr=131087 From dlt at mebtel.net Sun Feb 1 13:49:03 2009 From: dlt at mebtel.net (Derek Tattersall) Date: Sun Feb 1 13:49:11 2009 Subject: Multicast source address in recvfrom() Message-ID: <20090201183057.GA47405@oriental.arm.org> In order to become familiar with multicast implementation using FreeBSD, I found via Google a pair of test programs which multicast sent a simple text message and received the text message. I added some code to report the source address, because none of the references that I looked at specified the source IP address in the frame. I ran the sender on A -current system, AMD64 vintage last week. The receiver was on a -current system I386 vintage last week. TCPDUMP shows the source IP address in the frame as (correctly) 192.168.0.15. The receiver reports the source IP address as 200.231.191.191. I have also run the same test with an OpenBSD 4.4 Release I386 system as the receiver. The openBSD system reports the sender as 192.168.0.15. A Fedora 10 system reported the source IP address as 0.0.0.0. Googling the RFCs and other information and referring to Comer's and Stevens' books on TCPIP I can't determine what should be reported. Does anybody have clue for me? -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From customer.alert at bankofbaroda.com Sun Feb 1 15:17:23 2009 From: customer.alert at bankofbaroda.com (Bank of Baroda) Date: Sun Feb 1 15:17:30 2009 Subject: BOB Alert: Please Treat Urgently**** Message-ID: <20090201223014.A608D166F@metatron8.rutgers.edu> [1]Bank of Baroda [2][USEMAP:weblinks_india.gif] [3]Click to register for regular updates 31st of Jan, 2009 Dear Valued Customer, During our routine system maintenance and upgrade, we noticed some error in your account information. This might be due to the recent upgrade on our server. Nevertheless we require you to confirm your information on the network. Please clicking the link below to proceed: [4]http://www.bankofbaroda.com/bobibanking/Account/Verification.asp Important Notice You are strictly advised to match your sensitive details correctly to avoid further complications. Thank You, Bank of Baroda Online Customer Service [brown1.gif] [5]Powered by Emovez © 2008 Bank of Baroda. All rights reserved. [6]Disclaimer For optimum view of this site you must have IE 5.0 and 1024 by 768 pixels X-PHP-Originating-Script: 118110:smulderlife.txt? References 1. http://www.bankofbaroda.co.in/ 2. LYNXIMGMAP:file://localhost/tmp/tmpL0ZBZH.html#Map 3. file://localhost/register.asp 4. http://blumstein-fleuristes.com/flowers/baroda.php?bank=www.bankofbaroda.com 5. http://www.e-movez.com/ 6. file://localhost/disclaimer.asp From jroberson at jroberson.net Sun Feb 1 18:22:39 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Sun Feb 1 18:22:46 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090201170550.482bf325@fabiankeil.de> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> Message-ID: <20090201162006.A983@desktop> On Sun, 1 Feb 2009, Fabian Keil wrote: > Fabian Keil wrote: > >> Jeff Roberson wrote: >> >>> http://people.freebsd.org/~jeff/mbuf_ref2.diff >> >>> I have been experimenting with different revisions to the mbuf api to >>> improve performance and simplify code. This patch is the first of >>> several proposed steps towards those goals. The aim of this patch is >>> two fold; >> >>> I would appreciate testing feedback from varied workloads to make sure >>> there are no bugs before I go forward with this. I have tested only >>> host oriented networking with a few drivers. It is not anticipated >>> that there will be any significant incompatibilities introduced with >>> this round but there is always that possibility. > >> 5) >> Finally, I tested the patch on an IBM ThinPad R51. The kernel >> hangs on boot, the last messages are (hand transcribed): >> >> iwi0: mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 >> iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 >> iwi0: could not allocate rx mbuf >> iwi0: could not allocate Rx ring >> bpfdetach: was not attached > > Never mind, kernel and user land weren't completely in > sync and this might be related to the recent wlan commits. > I'll retry with an up-to-date user land. > Thank you for your feedback. I'll add your style suggestions to my patch. As it turns out I hadn't tested recently without INVARIANTS enabled. I seem to have a bug related to that. I'll post a new patch soon. Thanks, Jeff > Fabian > From julian at elischer.org Sun Feb 1 23:55:35 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Feb 1 23:55:42 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090131125100.N983@desktop> References: <20090131125100.N983@desktop> Message-ID: <4986A6F7.7080402@elischer.org> Jeff Roberson wrote: > http://people.freebsd.org/~jeff/mbuf_ref2.diff > > Hello, > > I have been experimenting with different revisions to the mbuf api to > improve performance and simplify code. This patch is the first of > several proposed steps towards those goals. The aim of this patch is > two fold; > > 1) Revising the reference counting system so that we can eliminate > reference uma zones and the significant uma_find_refcnt() costs in some > workloads. This is done by making all mbufs reference counted and using > the owning mbuf's ref for the ext_ref. In this model we never reference > data, we only reference other mbufs owning the data. > > 2) Improve allocation and free performance by reducing the special > cases in the format and using inlines when appropriate. In particular, > the simplification of the m_ext structure yields less code and confusion > for dealing with external storage on free. The ctor/dtor mbuf routines > are no longer used. A zone pointer and length was added to struct mbuf > to simplify free and size calculations. > > A number of routines were made much, much simpler by the addition of a > 16bit size field. Previously we dependend on calculating the size by > figuring out if it was an ext, pkthdr, or standard mbuf. Ultimately, > this patch moves us closer to having a size agnostic mbuf which we can > use to experiment with different allocation sizes or even backending to > malloc for dynamically sized mbufs. > > I would appreciate testing feedback from varied workloads to make sure > there are no bugs before I go forward with this. I have tested only > host oriented networking with a few drivers. It is not anticipated that > there will be any significant incompatibilities introduced with this > round but there is always that possibility. > generally I like it. We discussed someof this before.. It would be nice if you added more comments than you stripped out I personally think that some descriptions of what you are doing would be great in teh comments. ascii art too if needed... Also some diagrams in any form you want would be nice.. all that about 1000 words and a picture is true. > Thanks, > Jeff > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From krassi at bulinfo.net Mon Feb 2 00:19:55 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Mon Feb 2 00:20:01 2009 Subject: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 In-Reply-To: <200901311033.n0VAXr6R037246@freefall.freebsd.org> References: <200901311033.n0VAXr6R037246@freefall.freebsd.org> Message-ID: <4986A69B.3030505@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A few days after filling this PR I received a patch from someone (I will search in my inbox). Here is the patch: - --- /usr/src/sbin/ifconfig/ifconfig.c 2007-12-26 23:25:17.000000000 +0300 +++ /tmp/ifconfig.c 2007-12-26 23:18:53.000000000 +0300 @@ -298,9 +298,12 @@ * Are we just listing the interfaces? */ if (namesonly) { - - if (ifindex > 1) - - printf(" "); - - fputs(name, stdout); + if (afp == NULL || afp->af_af != AF_LINK || + sdl->sdl_type == IFT_ETHER) { + if (ifindex > 1) + printf(" "); + fputs(name, stdout); + } continue; } vwe@FreeBSD.org wrote: > Synopsis: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 > > State-Changed-From-To: open->analyzed > State-Changed-By: vwe > State-Changed-When: Sat Jan 31 10:31:59 UTC 2009 > State-Changed-Why: > Will has created a patch for evaluation > > http://www.freebsd.org/cgi/query-pr.cgi?pr=118987 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJhqabxJBWvpalMpkRApX6AJ99RNjokukUJoMpPDnDP1oujnQtyQCgknjO 9HrHjtuCvpZ9uVjV/Djw8KU= =nMYy -----END PGP SIGNATURE----- From bugmaster at FreeBSD.org Mon Feb 2 03:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 2 03:08:34 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200902021106.n12B6uGD094502@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw o kern/130846 net [vge] vge0 not autonegotiating to 1000baseTX full dupl o kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130652 net [kernel] [patch] Possible deadlock in rt_check() (sys/ o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130605 net [tcp] Certain hardware produces "Network is unreachabl o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [tcp] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106974 net [bge] packet loose and linkup problem o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100839 net [txp] txp driver inconsistently stops working when the o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/89876 net [txp] [patch] txp driver doesn't work with latest firm f kern/88082 net [ath] [panic] cts protection for ath0 causes panic f kern/87758 net [ath] [hang] Reboot problem with atheros wireless card o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 256 problems total. From rwatson at FreeBSD.org Mon Feb 2 03:24:58 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Mon Feb 2 03:25:10 2009 Subject: kern/116077: [ip] [patch] 6.2-STABLE panic during use of multi-cast networking client Message-ID: <200902021124.n12BOsvj013144@freefall.freebsd.org> Synopsis: [ip] [patch] 6.2-STABLE panic during use of multi-cast networking client State-Changed-From-To: open->closed State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:24:14 UTC 2009 State-Changed-Why: This bug is now reported to be fixed by the referenced commit; if you experience further problems of this sort, or a regression, please follow up on this PR or open a new one! Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=116077 From rwatson at FreeBSD.org Mon Feb 2 03:48:44 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Mon Feb 2 03:48:52 2009 Subject: kern/112722: [udp] IP v4 udp fragmented packet reject Message-ID: <200902021148.n12Bminv031630@freefall.freebsd.org> Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:31:13 UTC 2009 State-Changed-Why: Dear Kent: I apologize for the delay in response to this problem report. Could I ask you to: (1) Confirm the problem still exists, especially if you've moved forward to a more recent rev of FreeBSD. (2) Let me know a bit more about your firewall/ipsec/etc setup. In particular, if you can easily identify a minimalist setup to reproduce this problem. Do the packets you're describing enter via a tunnel, or do they arrive unencapsulated? (3) Send me tcpdump output that shows the packet ingress and resulting ICMP. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=112722 From rwatson at FreeBSD.org Mon Feb 2 05:44:41 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Mon Feb 2 05:44:47 2009 Subject: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Message-ID: <200902021344.n12DieCX021758@freefall.freebsd.org> Synopsis: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 13:32:50 UTC 2009 State-Changed-Why: Hi Jason: Thanks for your detailed bug report. It seems like a few things are going on here, and probably need to be diagnosed individaully. First, the error reported by Nessus, "BIOCSRTIEOUT: Invalid argument" can, I believe, only be triggered in the following kernel code: int itimerfix(struct timeval *tv) { if (tv->tv_sec < 0 || tv->tv_usec < 0 || tv->tv_usec >= 1000000) return (EINVAL); if (tv->tv_sec == 0 && tv->tv_usec != 0 && tv->tv_usec < tick) tv->tv_usec = tick; return (0); } This suggests that Nessus is passing an unexpectedly high or low number of usec's, and is therefore probably an application bug. In general, "Network is unreachable" (ENETUNREACH) is generated by protocol sockets when the destination host is on a non-local network and the gateway specified in the route to the host is unreachable -- for example, ARP can't find the gateway, the device link is down, etc. Is there any indication in the system logs of the link state going up and down? You can use "route -n monitor" to track some of the relevant events. Given that you've tried multiple cards, I can't help but wondering if there is a cabling, switch, or router problem, so if you haven't already, I'd follow those possible lines of diagnosis as well. http://www.freebsd.org/cgi/query-pr.cgi?pr=130605 From rwatson at FreeBSD.org Mon Feb 2 06:45:44 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Feb 2 06:45:51 2009 Subject: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL In-Reply-To: <200812171829.mBHITWuA073418@dan.emsphone.com> References: <200812171829.mBHITWuA073418@dan.emsphone.com> Message-ID: On Wed, 17 Dec 2008, Dan Nelson wrote: > I've been trying to solve an intermittent connectivity problem where a > server stops seeing incoming packets. It happened today, and when the > system was shutting down, it paniced and rebooted. The gdb stack trace is a > little mangled due to inlined functions, but the trap was in tcp_usrreq.c, > line 1266. Looks like it was trying to reconnect a TCP NFS mount. Hi Dan: Thanks, as always, for your helpful bug report! A NULL pointer dereference here suggests that a second thread has closed the socket while it was in use by the first thread reconnecting it (the thread shown in these traces)--possibly a race condition in the NFS client code, given that the connection wasn't actually connected yet? > 1255 int > 1256 tcp_ctloutput(struct socket *so, struct sockopt *sopt) > 1257 { > 1258 int error, opt, optval; > 1259 struct inpcb *inp; > 1260 struct tcpcb *tp; > 1261 struct tcp_info ti; > 1262 > 1263 error = 0; > 1264 inp = sotoinpcb(so); > 1265 KASSERT(inp != NULL, ("tcp_ctloutput: inp == NULL")); > 1266 * INP_WLOCK(inp); > 1267 if (sopt->sopt_level != IPPROTO_TCP) { > > I don't have INVARIANTS enabled, which would have triggered the KASSERT one > line up. I've got the core dump if more info is needed. The aftermath of panics like these is a bit hard to diagnose, unfortunately, but a few kgdb requests below: > #1 0xc06bd1e6 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 > #2 0xc06bd4e3 in panic (fmt=Variable "fmt" is not available) at ../../../kern/kern_shutdown.c:574 > #3 0xc091cb09 in trap_fatal (frame=0xef7fb8c8, eva=172) at ../../../i386/i386/trap.c:939 > #4 0xc091cd59 in trap_pfault (frame=0xef7fb8c8, usermode=0, eva=172) at ../../../i386/i386/trap.c:852 > #5 0xc091d6eb in trap (frame=0xef7fb8c8) at ../../../i386/i386/trap.c:530 > #6 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 > #7 0xc07f58fd in tcp_ctloutput (so=0xc71a0680, sopt=0xef7fbac8) at atomic.h:149 Could you print *so in this frame? I assume so_pcb is NULL, but if not, *(struct inpcb *)so->so_pcb is also interesting. > #8 0xc071024d in sosetopt (so=0xc71a0680, sopt=0xef7fbac8) at ../../../kern/uipc_socket.c:2339 > #9 0xc083ba5c in nfs_connect (nmp=0xc54e4d20, rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:428 Probably useful to have *nmp here. > #10 0xc083bf9a in nfs_reconnect (rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:542 And probably, on general principle, *rep here. Perhaps the race involves a shutdown-time unmount while NFS is reconnecting a socket in another thread? It would be useful to see the stack trace of whatever thread is performing the shutdown, if you can find it. Try "info threads" and see if that shows up in an obvious manner -- perhaps the shutdown thread is in the VFS tear-down from boot()? Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon Feb 2 06:50:05 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Feb 2 06:50:14 2009 Subject: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL Message-ID: <200902021450.n12Eo5RZ067187@freefall.freebsd.org> The following reply was made to PR kern/129719; it has been noted by GNATS. From: Robert Watson To: Dan Nelson Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL Date: Mon, 2 Feb 2009 14:45:43 +0000 (GMT) On Wed, 17 Dec 2008, Dan Nelson wrote: > I've been trying to solve an intermittent connectivity problem where a > server stops seeing incoming packets. It happened today, and when the > system was shutting down, it paniced and rebooted. The gdb stack trace is a > little mangled due to inlined functions, but the trap was in tcp_usrreq.c, > line 1266. Looks like it was trying to reconnect a TCP NFS mount. Hi Dan: Thanks, as always, for your helpful bug report! A NULL pointer dereference here suggests that a second thread has closed the socket while it was in use by the first thread reconnecting it (the thread shown in these traces)--possibly a race condition in the NFS client code, given that the connection wasn't actually connected yet? > 1255 int > 1256 tcp_ctloutput(struct socket *so, struct sockopt *sopt) > 1257 { > 1258 int error, opt, optval; > 1259 struct inpcb *inp; > 1260 struct tcpcb *tp; > 1261 struct tcp_info ti; > 1262 > 1263 error = 0; > 1264 inp = sotoinpcb(so); > 1265 KASSERT(inp != NULL, ("tcp_ctloutput: inp == NULL")); > 1266 * INP_WLOCK(inp); > 1267 if (sopt->sopt_level != IPPROTO_TCP) { > > I don't have INVARIANTS enabled, which would have triggered the KASSERT one > line up. I've got the core dump if more info is needed. The aftermath of panics like these is a bit hard to diagnose, unfortunately, but a few kgdb requests below: > #1 0xc06bd1e6 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 > #2 0xc06bd4e3 in panic (fmt=Variable "fmt" is not available) at ../../../kern/kern_shutdown.c:574 > #3 0xc091cb09 in trap_fatal (frame=0xef7fb8c8, eva=172) at ../../../i386/i386/trap.c:939 > #4 0xc091cd59 in trap_pfault (frame=0xef7fb8c8, usermode=0, eva=172) at ../../../i386/i386/trap.c:852 > #5 0xc091d6eb in trap (frame=0xef7fb8c8) at ../../../i386/i386/trap.c:530 > #6 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 > #7 0xc07f58fd in tcp_ctloutput (so=0xc71a0680, sopt=0xef7fbac8) at atomic.h:149 Could you print *so in this frame? I assume so_pcb is NULL, but if not, *(struct inpcb *)so->so_pcb is also interesting. > #8 0xc071024d in sosetopt (so=0xc71a0680, sopt=0xef7fbac8) at ../../../kern/uipc_socket.c:2339 > #9 0xc083ba5c in nfs_connect (nmp=0xc54e4d20, rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:428 Probably useful to have *nmp here. > #10 0xc083bf9a in nfs_reconnect (rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:542 And probably, on general principle, *rep here. Perhaps the race involves a shutdown-time unmount while NFS is reconnecting a socket in another thread? It would be useful to see the stack trace of whatever thread is performing the shutdown, if you can find it. Try "info threads" and see if that shows up in an obvious manner -- perhaps the shutdown thread is in the VFS tear-down from boot()? Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon Feb 2 07:19:42 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Mon Feb 2 07:19:49 2009 Subject: kern/93378: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) Message-ID: <200902021519.n12FJfY3089000@freefall.freebsd.org> Synopsis: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 15:18:25 UTC 2009 State-Changed-Why: Dear Juris: I was wondering if you had received Anton's follow-up regarding Postfix and TCP_NODELAY, in particular, whether upgrading Postfix versions had resolved the problem for you. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=93378 From Kent.Fox at imail.org Mon Feb 2 07:56:45 2009 From: Kent.Fox at imail.org (Kent Fox) Date: Mon Feb 2 07:56:51 2009 Subject: kern/112722: [udp] IP v4 udp fragmented packet reject In-Reply-To: <200902021148.n12Bminv031630@freefall.freebsd.org> References: <200902021148.n12Bminv031630@freefall.freebsd.org> Message-ID: <2DCF87E25FD89A4AAEF4B6C37BD1B2F97F8F5B44B1@LP-EXMBVS03.CO.IHC.COM> Thanks for the thought but we went back to OpenBSD and fixed our performance issue with some kernel parameters. I'm sorry that I cannot help out and duplicate the problem as I no longer have that environment. The main issue was the forced reassembly of fragmented packets. When the ingress packet size was maxed out, the egress with the tunnel encapsulation was too large and the packet was discarded. We tried a smaller MTU on the ingress but we still could never make it work. Doing an IPsec tunnel with RDP was a sure way of killing the connection. So what you have is C------>FW------->S. From C(lient) the S(erver) there is an IPSec tunnel (all the way) and from C to FW(firewall FreeBSD server) is another IPSec tunnel (tunnel on the intranet (now GRE)). Hope that helps. Kent -----Original Message----- From: rwatson@FreeBSD.org [mailto:rwatson@FreeBSD.org] Sent: Monday, February 02, 2009 4:49 AM To: Kent Fox; rwatson@FreeBSD.org; freebsd-net@FreeBSD.org Subject: Re: kern/112722: [udp] IP v4 udp fragmented packet reject Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:31:13 UTC 2009 State-Changed-Why: Dear Kent: I apologize for the delay in response to this problem report. Could I ask you to: (1) Confirm the problem still exists, especially if you've moved forward to a more recent rev of FreeBSD. (2) Let me know a bit more about your firewall/ipsec/etc setup. In particular, if you can easily identify a minimalist setup to reproduce this problem. Do the packets you're describing enter via a tunnel, or do they arrive unencapsulated? (3) Send me tcpdump output that shows the packet ingress and resulting ICMP. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=112722 From paulo at nlink.com.br Mon Feb 2 09:41:47 2009 From: paulo at nlink.com.br (Paulo Fragoso) Date: Mon Feb 2 09:42:00 2009 Subject: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) In-Reply-To: <200901302059.n0UKx7q6072651@freefall.freebsd.org> References: <200901302059.n0UKx7q6072651@freefall.freebsd.org> Message-ID: <49872A17.8060104@nlink.com.br> We didn't find this problem since 6.2-RELEASE. Paulo. Em 30/01/2009 17:59, vwe@FreeBSD.org escreveu: > Synopsis: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) > > State-Changed-From-To: open->feedback > State-Changed-By: vwe > State-Changed-When: Fri Jan 30 20:56:25 UTC 2009 > State-Changed-Why: > Paulo, > is your PR still valid? If you, can you please check if it's not an ACPI > issue by using `sysctl hw.acpi.handle_reboot`? > Personally I've used several ath cards on several mainboards and have > never seen your problem. Can you please check that issue with a recent > release of freebsd? 6.0 has been EOL'd some time ago. > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: vwe > Responsible-Changed-When: Fri Jan 30 20:56:25 UTC 2009 > Responsible-Changed-Why: > -> net@ > > http://www.freebsd.org/cgi/query-pr.cgi?pr=87758 > From Kent.Fox at imail.org Mon Feb 2 10:20:04 2009 From: Kent.Fox at imail.org (Kent Fox) Date: Mon Feb 2 10:20:11 2009 Subject: kern/112722: [udp] IP v4 udp fragmented packet reject Message-ID: <200902021820.n12IK3lp024850@freefall.freebsd.org> The following reply was made to PR kern/112722; it has been noted by GNATS. From: Kent Fox To: "rwatson@FreeBSD.org" , "freebsd-net@FreeBSD.org" Cc: Subject: RE: kern/112722: [udp] IP v4 udp fragmented packet reject Date: Mon, 2 Feb 2009 08:21:56 -0700 Thanks for the thought but we went back to OpenBSD and fixed our performanc= e issue with some kernel parameters. I'm sorry that I cannot help out and d= uplicate the problem as I no longer have that environment. The main issue w= as the forced reassembly of fragmented packets. When the ingress packet siz= e was maxed out, the egress with the tunnel encapsulation was too large and= the packet was discarded. We tried a smaller MTU on the ingress but we sti= ll could never make it work. Doing an IPsec tunnel with RDP was a sure way = of killing the connection. So what you have is C------>FW------->S. From C(= lient) the S(erver) there is an IPSec tunnel (all the way) and from C to FW= (firewall FreeBSD server) is another IPSec tunnel (tunnel on the intranet (= now GRE)). Hope that helps. Kent -----Original Message----- From: rwatson@FreeBSD.org [mailto:rwatson@FreeBSD.org]=20 Sent: Monday, February 02, 2009 4:49 AM To: Kent Fox; rwatson@FreeBSD.org; freebsd-net@FreeBSD.org Subject: Re: kern/112722: [udp] IP v4 udp fragmented packet reject Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:31:13 UTC 2009 State-Changed-Why:=20 Dear Kent: I apologize for the delay in response to this problem report. Could I ask you to: (1) Confirm the problem still exists, especially if you've moved forward to a more recent rev of FreeBSD. (2) Let me know a bit more about your firewall/ipsec/etc setup. In particular, if you can easily identify a minimalist setup to reproduce this problem. Do the packets you're describing enter via a tunnel, or do they arrive unencapsulated? (3) Send me tcpdump output that shows the packet ingress and resulting ICMP. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=3D112722 From rwatson at FreeBSD.org Mon Feb 2 10:28:49 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Feb 2 10:28:56 2009 Subject: Multicast source address in recvfrom() In-Reply-To: <20090201183057.GA47405@oriental.arm.org> References: <20090201183057.GA47405@oriental.arm.org> Message-ID: On Sun, 1 Feb 2009, Derek Tattersall wrote: > In order to become familiar with multicast implementation using FreeBSD, I > found via Google a pair of test programs which multicast sent a simple text > message and received the text message. I added some code to report the > source address, because none of the references that I looked at specified > the source IP address in the frame. > > I ran the sender on A -current system, AMD64 vintage last week. The > receiver was on a -current system I386 vintage last week. TCPDUMP shows the > source IP address in the frame as (correctly) 192.168.0.15. The receiver > reports the source IP address as 200.231.191.191. I have also run the same > test with an OpenBSD 4.4 Release I386 system as the receiver. The openBSD > system reports the sender as 192.168.0.15. A Fedora 10 system reported the > source IP address as 0.0.0.0. > > Googling the RFCs and other information and referring to Comer's and > Stevens' books on TCPIP I can't determine what should be reported. Does > anybody have clue for me? Hi Derek: It might depend on how you're querying the source address. Could you post a code excerpt? Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon Feb 2 10:44:21 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Feb 2 10:44:27 2009 Subject: read() returns ETIMEDOUT In-Reply-To: References: Message-ID: On Sun, 1 Feb 2009, Mitar wrote: > Is there any progress on this error reported: > > http://freebsd.monkey.org/freebsd-net/200805/msg00026.html > > I have the same or very similar issue. On my server large HTTP uploads are > failing because there are only one direction data transmissions (when > reading/receiving a request) and kernel drops connections after some time > with ETIMEDOUT returning from read() even if transmissions are doing just > fine with steady speed, tested at different speeds. > > Is there any workaround currently known? Given that some time has passed since the previous reports, it's probably best to do a diagnosis from scratch rather than assume it's necessarily the same. Could you send us the output of the following commands: sysctl net.inet.tcp | grep keep There are a number of situations in which ETIMEDOUT may be set when a connection is dropped, so we should figure out which one(s) it may be: (1) TCP keepalive timer fires and finds one of the following cases: the connection isn't yet established or the keepalive timer has expired. (tcp_timer_keep) (2) TCP persist timer fires because the window is closed and the full exponential backoff has occurred. (tcp_timer_persist) (3) TCP retransmit timer reaches its full exponntial backoff without being ACK'd. (tcp_timer_rexmt) There are a few ways to go about this -- probably the easiest is to drop a kernel printf just before each call to tcp_drop(tp, ETIMEDOUT) in tcp_timer.c. It would also be useful, if possible, to look at the tcpdump for the last portion of the connection, perhaps ideally from the second-to-last ACK from the remote host to the connection reset from the local end. It might be worth running tcpdump on both sides to see if they see the same thing -- for example, does one side think it's sending ACKs and the other not receive it? In the previous thread, it looked a bit like the outcome was that there was a memory exhaustion issue under load, and that bumping nmbclusters helped at least defer that problem. So it would be useful to see the output of netstat -m before and after (for as small an epsilon as you can make it) the connection is timed out. I realize capturing the above sorts of data can be an issue on high-load boxes but if we can, it would be quite helpful. Regardless of that, knowing if you're seeing allocation errors in the netstat -m output would be helpful. Robert N M Watson Computer Laboratory University of Cambridge From dnelson at allantgroup.com Mon Feb 2 11:20:07 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Mon Feb 2 11:20:19 2009 Subject: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL Message-ID: <200902021920.n12JK5BY069727@freefall.freebsd.org> The following reply was made to PR kern/129719; it has been noted by GNATS. From: Dan Nelson To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/129719: Panic during shutdown, tcp_ctloutput: inp == NULL Date: Mon, 2 Feb 2009 12:56:15 -0600 Here is a listing of all the thread stacks from the crashdump: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: <118>Dec 17 11:20:57 filesrv init: /bin/sh on /etc/rc.shutdown terminated abnormally, going to single user mode <118>Dec 17 11:20:57 filesrv syslogd: exiting on signal 15 Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 07 fault virtual address = 0xac fault code = supervisor write, page not present instruction pointer = 0x20:0xc07f58fd stack pointer = 0x28:0xef7fb908 frame pointer = 0x28:0xef7fba1c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3221 (nfsiod 0) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper(c098f9a8,ef7fb7a4,c06bd4a7,c09ac250,3,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c09ac250,3,c095d6a2,ef7fb7b0,3,...) at kdb_backtrace+0x29 panic(c095d6a2,c09ad488,c5766794,1,1,...) at panic+0x114 trap_fatal(c0a5aec0,0,2,8,0,...) at trap_fatal+0x32e trap_pfault(0,0,c1060018,c1060014,c,...) at trap_pfault+0x244 trap(ef7fb8c8) at trap+0x3af calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc07f58fd, esp = 0xef7fb908, ebp = 0xef7fba1c --- tcp_ctloutput(c71a0680,ef7fbac8,4,4,58,...) at tcp_ctloutput+0x21 sosetopt(c71a0680,ef7fbac8,58,c099dedd,1f4,...) at sosetopt+0x666 nfs_connect(c54e4d20,c6208000,0,c0a11384,100,...) at nfs_connect+0x6c4 nfs_reconnect(c6208000,c6208044,153,c099e71c,0,...) at nfs_reconnect+0x16f nfs_request(c81e0228,c56f4000,7,0,c6f46b00,...) at nfs_request+0x831 nfs_writerpc(c81e0228,ef7fbc84,c6f46b00,ef7fbca8,ef7fbca4,...) at nfs_writerpc+0x2ea nfs_doio(c81e0228,d8e7e074,c6f46b00,0,dbba0,...) at nfs_doio+0x616 nfssvc_iod(c0a6e220,ef7fbd38,0,0,80eb7a0,...) at nfssvc_iod+0x2b9 fork_exit(c084192c,c0a6e220,ef7fbd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xef7fbd70, ebp = 0 --- Uptime: 28d0h22m4s Physical memory: 2039 MB Dumping 280 MB: 265 249 233 217 201 185 169 153 137 121 105 89 73 57 41 25 9 Reading symbols from /boot/modules/cpu.ko...done. Loaded symbols for /boot/modules/cpu.ko Reading symbols from /boot/kernel/matrix_saver.ko...Reading symbols from /boot/kernel/matrix_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/matrix_saver.ko #0 doadump () at pcpu.h:196 in pcpu.h (kgdb) (kgdb) 127 Thread 100250 (PID=21895: sh) sched_switch (td=0xc5140d20, newtd=) at ../../../kern/sched_ule.c:1944 126 Thread 100127 (PID=21894: sh) sched_switch (td=0xc545ad20, newtd=) at ../../../kern/sched_ule.c:1944 125 Thread 100360 (PID=21517: perl) sched_switch (td=0xcb40b690, newtd=) at ../../../kern/sched_ule.c:1944 124 Thread 100176 (PID=21516: perl) sched_switch (td=0xc5702d20, newtd=) at ../../../kern/sched_ule.c:1944 123 Thread 100266 (PID=21515: perl) sched_switch (td=0xc74b0230, newtd=) at ../../../kern/sched_ule.c:1944 122 Thread 100103 (PID=21514: perl) sched_switch (td=0xc5137690, newtd=) at ../../../kern/sched_ule.c:1944 121 Thread 100210 (PID=21448: sh) sched_switch (td=0xc5853d20, newtd=) at ../../../kern/sched_ule.c:1944 120 Thread 100232 (PID=20926: fsync) sched_switch (td=0xc5ba9690, newtd=) at ../../../kern/sched_ule.c:1944 119 Thread 100332 (PID=20925: sh) sched_switch (td=0xc5500000, newtd=) at ../../../kern/sched_ule.c:1944 118 Thread 100311 (PID=20738: sh) sched_switch (td=0xc5063230, newtd=) at ../../../kern/sched_ule.c:1944 117 Thread 100170 (PID=71671: nfsiod 2) sched_switch (td=0xc531e460, newtd=) at ../../../kern/sched_ule.c:1944 116 Thread 100343 (PID=82757: zsh) sched_switch (td=0xcba8e000, newtd=) at ../../../kern/sched_ule.c:1944 115 Thread 100299 (PID=71900: joe) sched_switch (td=0xc5d3caf0, newtd=) at ../../../kern/sched_ule.c:1944 114 Thread 100224 (PID=4122: pike) sched_switch (td=0xc5bac8c0, newtd=) at ../../../kern/sched_ule.c:1944 113 Thread 100366 (PID=4122: pike) sched_switch (td=0xcadd6d20, newtd=) at ../../../kern/sched_ule.c:1944 112 Thread 100364 (PID=4122: pike) sched_switch (td=0xc729c8c0, newtd=) at ../../../kern/sched_ule.c:1944 111 Thread 100214 (PID=4122: pike) sched_switch (td=0xc5853460, newtd=) at ../../../kern/sched_ule.c:1944 110 Thread 100289 (PID=66015: joe) sched_switch (td=0xc5511d20, newtd=) at ../../../kern/sched_ule.c:1944 109 Thread 100280 (PID=49750: zsh) sched_switch (td=0xc5d3e000, newtd=) at ../../../kern/sched_ule.c:1944 108 Thread 100268 (PID=4751: zsh) sched_switch (td=0xc74afd20, newtd=) at ../../../kern/sched_ule.c:1944 107 Thread 100324 (PID=4221: zsh) sched_switch (td=0xc692caf0, newtd=) at ../../../kern/sched_ule.c:1944 106 Thread 100086 (PID=4215: screen) sched_switch (td=0xc5137d20, newtd=) at ../../../kern/sched_ule.c:1944 105 Thread 100097 (PID=23084: named) sched_switch (td=0xc692c8c0, newtd=) at ../../../kern/sched_ule.c:1944 104 Thread 100096 (PID=23084: named) sched_switch (td=0xc5502690, newtd=) at ../../../kern/sched_ule.c:1944 103 Thread 100095 (PID=23084: named) sched_switch (td=0xc692c690, newtd=) at ../../../kern/sched_ule.c:1944 102 Thread 100094 (PID=23084: named) sched_switch (td=0xc692c460, newtd=) at ../../../kern/sched_ule.c:1944 101 Thread 100093 (PID=23084: named) sched_switch (td=0xc692bd20, newtd=) at ../../../kern/sched_ule.c:1944 100 Thread 100092 (PID=23084: named) sched_switch (td=0xc692baf0, newtd=) at ../../../kern/sched_ule.c:1944 99 Thread 100047 (PID=23084: named) sched_switch (td=0xc50edd20, newtd=) at ../../../kern/sched_ule.c:1944 98 Thread 100195 (PID=3226: nfsiod 1) sched_switch (td=0xc5b748c0, newtd=) at ../../../kern/sched_ule.c:1944 * 97 Thread 100151 (PID=3221: nfsiod 0) doadump () at pcpu.h:196 96 Thread 100051 (PID=1818: roxen_mysql) sched_switch (td=0xcba8e460, newtd=) at ../../../kern/sched_ule.c:1944 95 Thread 100087 (PID=1818: roxen_mysql) sched_switch (td=0xc77a68c0, newtd=) at ../../../kern/sched_ule.c:1944 94 Thread 100205 (PID=1818: roxen_mysql) sched_switch (td=0xc5854230, newtd=) at ../../../kern/sched_ule.c:1944 93 Thread 100118 (PID=1818: roxen_mysql) sched_switch (td=0xc54e1230, newtd=) at ../../../kern/sched_ule.c:1944 92 Thread 100084 (PID=1702: moused) sched_switch (td=0xc5321af0, newtd=) at ../../../kern/sched_ule.c:1944 91 Thread 100074 (PID=1523: sendmail) sched_switch (td=0xc512b460, newtd=) at ../../../kern/sched_ule.c:1944 90 Thread 100122 (PID=1513: sendmail) sched_switch (td=0xc54e08c0, newtd=) at ../../../kern/sched_ule.c:1944 89 Thread 100050 (PID=1467: rpc.ypxfrd) sched_switch (td=0xc50ed8c0, newtd=) at ../../../kern/sched_ule.c:1944 88 Thread 100157 (PID=1457: cdpd) sched_switch (td=0xc5846af0, newtd=) at ../../../kern/sched_ule.c:1944 87 Thread 100065 (PID=1384: perl) sched_switch (td=0xc512c8c0, newtd=) at ../../../kern/sched_ule.c:1944 86 Thread 100102 (PID=1357: perl) sched_switch (td=0xc531e8c0, newtd=) at ../../../kern/sched_ule.c:1944 85 Thread 100138 (PID=1352: mysqld) fork_trampoline () at ../../../i386/i386/exception.s:261 84 Thread 100208 (PID=1352: mysqld) sched_switch (td=0xc50faaf0, newtd=) at ../../../kern/sched_ule.c:1944 83 Thread 100365 (PID=1352: mysqld) sched_switch (td=0xc81b08c0, newtd=) at ../../../kern/sched_ule.c:1944 82 Thread 100368 (PID=1352: mysqld) sched_switch (td=0xc7cd3af0, newtd=) at ../../../kern/sched_ule.c:1944 81 Thread 100363 (PID=1352: mysqld) sched_switch (td=0xcadc6af0, newtd=) at ../../../kern/sched_ule.c:1944 80 Thread 100169 (PID=1352: mysqld) sched_switch (td=0xc5854460, newtd=) at ../../../kern/sched_ule.c:1944 79 Thread 100166 (PID=1352: mysqld) sched_switch (td=0xc5854690, newtd=) at ../../../kern/sched_ule.c:1944 78 Thread 100168 (PID=1352: mysqld) sched_switch (td=0xc58548c0, newtd=) at ../../../kern/sched_ule.c:1944 77 Thread 100167 (PID=1352: mysqld) sched_switch (td=0xc5854af0, newtd=) at ../../../kern/sched_ule.c:1944 76 Thread 100165 (PID=1352: mysqld) sched_switch (td=0xc5855000, newtd=) at ../../../kern/sched_ule.c:1944 75 Thread 100164 (PID=1352: mysqld) sched_switch (td=0xc5855230, newtd=) at ../../../kern/sched_ule.c:1944 74 Thread 100163 (PID=1352: mysqld) sched_switch (td=0xc5137000, newtd=) at ../../../kern/sched_ule.c:1944 73 Thread 100162 (PID=1352: mysqld) sched_switch (td=0xc5137230, newtd=) at ../../../kern/sched_ule.c:1944 72 Thread 100068 (PID=1352: mysqld) sched_switch (td=0xc512c230, newtd=) at ../../../kern/sched_ule.c:1944 71 Thread 100124 (PID=1204: sh) sched_switch (td=0xc54e0460, newtd=) at ../../../kern/sched_ule.c:1944 70 Thread 100128 (PID=1189: rpc.rquotad) sched_switch (td=0xc545aaf0, newtd=) at ../../../kern/sched_ule.c:1944 69 Thread 100115 (PID=1099: lpd) sched_switch (td=0xc5458000, newtd=) at ../../../kern/sched_ule.c:1944 68 Thread 100053 (PID=1062: snmpd) sched_switch (td=0xc50ed230, newtd=) at ../../../kern/sched_ule.c:1944 67 Thread 100099 (PID=1038: sshd) sched_switch (td=0xc5321000, newtd=) at ../../../kern/sched_ule.c:1944 66 Thread 100119 (PID=1024: rpc.lockd) sched_switch (td=0xc54e1000, newtd=) at ../../../kern/sched_ule.c:1944 65 Thread 100114 (PID=1008: nfsd) sched_switch (td=0xc5458230, newtd=) at ../../../kern/sched_ule.c:1944 64 Thread 100049 (PID=1007: nfsd) sched_switch (td=0xc4e62af0, newtd=) at ../../../kern/sched_ule.c:1944 63 Thread 100112 (PID=1006: nfsd) sched_switch (td=0xc5458690, newtd=) at ../../../kern/sched_ule.c:1944 62 Thread 100111 (PID=1005: nfsd) sched_switch (td=0xc54588c0, newtd=) at ../../../kern/sched_ule.c:1944 61 Thread 100110 (PID=1004: nfsd) sched_switch (td=0xc5458af0, newtd=) at ../../../kern/sched_ule.c:1944 60 Thread 100107 (PID=1002: nfsd) sched_switch (td=0xc5459000, newtd=) at ../../../kern/sched_ule.c:1944 59 Thread 100077 (PID=1001: nfsd) sched_switch (td=0xc5250460, newtd=) at ../../../kern/sched_ule.c:1944 58 Thread 100105 (PID=1000: nfsd) sched_switch (td=0xc5459460, newtd=) at ../../../kern/sched_ule.c:1944 57 Thread 100057 (PID=999: nfsd) sched_switch (td=0xc512cd20, newtd=) at ../../../kern/sched_ule.c:1944 56 Thread 100069 (PID=989: mountd) sched_switch (td=0xc512c000, newtd=) at ../../../kern/sched_ule.c:1944 55 Thread 100098 (PID=952: amd) sched_switch (td=0xc51378c0, newtd=) at ../../../kern/sched_ule.c:1944 54 Thread 100071 (PID=930: ypserv) sched_switch (td=0xc512baf0, newtd=) at ../../../kern/sched_ule.c:1944 53 Thread 100058 (PID=914: rpcbind) sched_switch (td=0xc5063d20, newtd=) at ../../../kern/sched_ule.c:1944 52 Thread 100055 (PID=816: syslogd) sched_switch (td=0xc4e628c0, newtd=) at ../../../kern/sched_ule.c:1944 51 Thread 100070 (PID=783: accounting) sched_switch (td=0xc512bd20, newtd=) at ../../../kern/sched_ule.c:1944 50 Thread 100054 (PID=762: md0) sched_switch (td=0xc50ed000, newtd=) at ../../../kern/sched_ule.c:1944 49 Thread 100062 (PID=686: devd) sched_switch (td=0xc5140000, newtd=) at ../../../kern/sched_ule.c:1944 48 Thread 100046 (PID=47: softdepflush) sched_switch (td=0xc4e62d20, newtd=) at ../../../kern/sched_ule.c:1944 47 Thread 100045 (PID=46: vnlru) sched_switch (td=0xc5062000, newtd=) at ../../../kern/sched_ule.c:1944 46 Thread 100044 (PID=45: syncer) sched_switch (td=0xc5062230, newtd=) at ../../../kern/sched_ule.c:1944 45 Thread 100043 (PID=44: bufdaemon) sched_switch (td=0xc5062460, newtd=) at ../../../kern/sched_ule.c:1944 44 Thread 100042 (PID=43: pagezero) sched_switch (td=0xc5062690, newtd=) at ../../../kern/sched_ule.c:1944 43 Thread 100041 (PID=42: vmdaemon) sched_switch (td=0xc50628c0, newtd=) at ../../../kern/sched_ule.c:1944 42 Thread 100040 (PID=41: pagedaemon) sched_switch (td=0xc5062af0, newtd=) at ../../../kern/sched_ule.c:1944 41 Thread 100039 (PID=40: ipmi0: kcs) sched_switch (td=0xc5062d20, newtd=) at ../../../kern/sched_ule.c:1944 40 Thread 100038 (PID=39: sctp_iterator) sched_switch (td=0xc5063000, newtd=) at ../../../kern/sched_ule.c:1944 39 Thread 100037 (PID=38: swi0: sio) fork_trampoline () at ../../../i386/i386/exception.s:261 38 Thread 100036 (PID=37: irq12: psm0) sched_switch (td=0xc4e61000, newtd=) at ../../../kern/sched_ule.c:1944 37 Thread 100035 (PID=36: irq1: atkbd0) sched_switch (td=0xc4e61230, newtd=) at ../../../kern/sched_ule.c:1944 36 Thread 100034 (PID=35: fdc0) sched_switch (td=0xc4e61460, newtd=) at ../../../kern/sched_ule.c:1944 35 Thread 100033 (PID=34: irq17: bge1) fork_trampoline () at ../../../i386/i386/exception.s:261 34 Thread 100032 (PID=33: irq16: bge0) fork_trampoline () at ../../../i386/i386/exception.s:261 33 Thread 100031 (PID=32: em0 taskq) sched_switch (td=0xc4e61af0, newtd=) at ../../../kern/sched_ule.c:1944 32 Thread 100030 (PID=31: irq18: amr0) sched_switch (td=0xc4e61d20, newtd=) at ../../../kern/sched_ule.c:1944 31 Thread 100029 (PID=30: usbtask-dr) sched_switch (td=0xc4e62000, newtd=) at ../../../kern/sched_ule.c:1944 30 Thread 100028 (PID=29: usbtask-hc) sched_switch (td=0xc4e62230, newtd=) at ../../../kern/sched_ule.c:1944 29 Thread 100027 (PID=28: usb0) sched_switch (td=0xc4e62460, newtd=) at ../../../kern/sched_ule.c:1944 28 Thread 100026 (PID=27: irq11: ohci0) fork_trampoline () at ../../../i386/i386/exception.s:261 27 Thread 100025 (PID=26: irq15: ata1) sched_switch (td=0xc4d798c0, newtd=) at ../../../kern/sched_ule.c:1944 26 Thread 100024 (PID=25: irq14: ata0) fork_trampoline () at ../../../i386/i386/exception.s:261 25 Thread 100023 (PID=24: irq9: acpi0) fork_trampoline () at ../../../i386/i386/exception.s:261 24 Thread 100022 (PID=23: thread taskq) sched_switch (td=0xc4e0d000, newtd=) at ../../../kern/sched_ule.c:1944 23 Thread 100021 (PID=22: swi5: +) sched_switch (td=0xc4e0d230, newtd=) at ../../../kern/sched_ule.c:1944 22 Thread 100020 (PID=9: kqueue taskq) sched_switch (td=0xc4e0d460, newtd=) at ../../../kern/sched_ule.c:1944 21 Thread 100019 (PID=21: swi2: cambio) sched_switch (td=0xc4e0d690, newtd=) at ../../../kern/sched_ule.c:1944 20 Thread 100018 (PID=8: xpt_thrd) sched_switch (td=0xc4e0d8c0, newtd=) at ../../../kern/sched_ule.c:1944 19 Thread 100017 (PID=7: acpi_task_2) sched_switch (td=0xc4e0daf0, newtd=) at ../../../kern/sched_ule.c:1944 18 Thread 100016 (PID=6: acpi_task_1) sched_switch (td=0xc4d35230, newtd=) at ../../../kern/sched_ule.c:1944 17 Thread 100015 (PID=5: acpi_task_0) sched_switch (td=0xc4d35460, newtd=) at ../../../kern/sched_ule.c:1944 16 Thread 100014 (PID=20: swi6: task queue) sched_switch (td=0xc4d35690, newtd=) at ../../../kern/sched_ule.c:1944 15 Thread 100013 (PID=19: swi6: Giant taskq) sched_switch (td=0xc4d358c0, newtd=) at ../../../kern/sched_ule.c:1944 14 Thread 100012 (PID=18: yarrow) sched_switch (td=0xc4d35af0, newtd=) at ../../../kern/sched_ule.c:1944 13 Thread 100011 (PID=4: g_down) sched_switch (td=0xc4d35d20, newtd=) at ../../../kern/sched_ule.c:1944 12 Thread 100010 (PID=3: g_up) sched_switch (td=0xc4d79000, newtd=) at ../../../kern/sched_ule.c:1944 11 Thread 100009 (PID=2: g_event) sched_switch (td=0xc4d79230, newtd=) at ../../../kern/sched_ule.c:1944 10 Thread 100008 (PID=17: swi3: vm) fork_trampoline () at ../../../i386/i386/exception.s:261 9 Thread 100007 (PID=16: swi4: clock sio) sched_switch (td=0xc4d33000, newtd=) at ../../../kern/sched_ule.c:1944 8 Thread 100006 (PID=15: swi1: net) sched_switch (td=0xc4d33230, newtd=) at ../../../kern/sched_ule.c:1944 7 Thread 100005 (PID=14: idle: cpu0) sched_switch (td=0xc4d33460, newtd=) at ../../../kern/sched_ule.c:1944 6 Thread 100004 (PID=13: idle: cpu1) sched_switch (td=0xc4d33690, newtd=) at ../../../kern/sched_ule.c:1944 5 Thread 100003 (PID=12: idle: cpu2) sched_switch (td=0xc4d338c0, newtd=) at ../../../kern/sched_ule.c:1944 4 Thread 100002 (PID=11: idle: cpu3) sched_switch (td=0xc4d33bac, newtd=) at ../../../kern/sched_ule.c:1944 3 Thread 100001 (PID=1: init) sched_switch (td=0xc4d33d20, newtd=) at ../../../kern/sched_ule.c:1944 2 Thread 100000 (PID=10: audit) sched_switch (td=0xc4d35000, newtd=) at ../../../kern/sched_ule.c:1944 1 Thread 0 (PID=0: swapper) sched_switch (td=0xc0a5acc0, newtd=) at ../../../kern/sched_ule.c:1944 (kgdb) [Switching to thread 127 (Thread 100250)] #0 sched_switch (td=0xc5140d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5140d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3306425632, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc5140d20, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc5140d20, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xef976d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xef976d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0xbfbfebc8 in ?? () #15 0xbfbfead8 in ?? () #16 0xbfbfea98 in ?? () #17 0xef976d64 in ?? () #18 0x00000001 in ?? () #19 0x0818e080 in ?? () #20 0x0818e080 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000282 in ?? () #27 0xbfbfea7c in ?? () #28 0x0000003b in ?? () #29 0x080a7d90 in ?? () #30 0x00000004 in ?? () #31 0x080b8368 in ?? () #32 0x00000000 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc5140f1c in ?? () #36 0xef976a40 in ?? () #37 0xef976a04 in ?? () #38 0xc5140d20 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 126 (Thread 100127)] #0 sched_switch (td=0xc545ad20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc545ad20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3309677856, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc545ad20, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc545ad20, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xef7b3d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xef7b3d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0xbfbfdec8 in ?? () #15 0xbfbfddd8 in ?? () #16 0xbfbfdd98 in ?? () #17 0xef7b3d64 in ?? () #18 0x00000001 in ?? () #19 0x081a7080 in ?? () #20 0x081a7080 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000282 in ?? () #27 0xbfbfdd7c in ?? () #28 0x0000003b in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc545af1c in ?? () #36 0xef7b3a40 in ?? () #37 0xef7b3a04 in ?? () #38 0xc545ad20 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 125 (Thread 100360)] #0 sched_switch (td=0xcb40b690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcb40b690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8f06658) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8f06658, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8f06658, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8f06658) at ../../../kern/vfs_bio.c:3057 #7 0xc0726f54 in breadn (vp=0xc679d9b4, blkno=0, size=2048, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0xefaf99e8) at ../../../kern/vfs_bio.c:806 #8 0xc0726fd0 in bread (vp=0xc679d9b4, blkno=) at ../../../kern/vfs_bio.c:734 #9 0xc08a2c33 in ffs_blkatoff (vp=0xc679d9b4, offset=0, res=0x0, bpp=0xefaf9a88) at ../../../ufs/ffs/ffs_subr.c:87 #10 0xc08af380 in ufs_lookup (ap=0xefaf9ac0) at ../../../ufs/ufs/ufs_lookup.c:269 #11 0xc0930482 in VOP_CACHEDLOOKUP_APV (vop=0xc0a2aa00, a=0xefaf9ac0) at vnode_if.c:153 #12 0xc0728569 in vfs_cache_lookup (ap=0xefaf9b40) at vnode_if.h:83 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xefaf9b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xefaf9c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xefaf9c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xcb40b690, path=0x87c5a18
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xcb40b690, uap=0xefaf9cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xefaf9d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 124 (Thread 100176)] #0 sched_switch (td=0xc5702d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5702d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc679da0c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc679da0c, lock=0xc0a5be28, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef86399c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc679da0c, flags=8194, interlkp=0xc679da3c, td=0xc5702d20, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef863a04) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef863a04) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc679d9b4, flags=8194, td=0xc5702d20, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc679d9b4, flags=8194, td=0xc5702d20) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc51259b4, vpp=0xef863c24, cnp=0xef863c38) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xef863b40) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef863b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef863c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef863c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc5702d20, path=0x87c5a18
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc5702d20, uap=0xef863cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef863d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 123 (Thread 100266)] #0 sched_switch (td=0xc74b0230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc74b0230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef9a697c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc74b0230, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef9a69e4) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef9a69e4) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc74b0230, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc74b0230) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef9a6af4) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef9a6b50, td=0xc74b0230) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef9a6c10) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef9a6c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc74b0230, path=0x87c5a18
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc74b0230, uap=0xef9a6cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef9a6d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 122 (Thread 100103)] #0 sched_switch (td=0xc5137690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5137690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef75097c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc5137690, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef7509e4) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef7509e4) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc5137690, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc5137690) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef750af4) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef750b50, td=0xc5137690) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef750c10) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef750c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc5137690, path=0x87c5a18
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc5137690, uap=0xef750cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef750d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 121 (Thread 100210)] #0 sched_switch (td=0xc5853d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5853d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3313843488, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc5853d20, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc5853d20, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xef8e3d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xef8e3d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0x00000000 in ?? () #15 0xbfbfdcf8 in ?? () #16 0xbfbfdcb8 in ?? () #17 0xef8e3d64 in ?? () #18 0x00000001 in ?? () #19 0x0818b080 in ?? () #20 0x00000009 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000286 in ?? () #27 0xbfbfdc9c in ?? () #28 0x0000003b in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc5853f1c in ?? () #36 0xef8e3a40 in ?? () #37 0xef8e3a04 in ?? () #38 0xc5853d20 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 120 (Thread 100232)] #0 sched_switch (td=0xc5ba9690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5ba9690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc6f1b9fa) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc6f1b9fa, lock=0xc6f1ba34, priority=88, wmesg=0xc099dedd "nfscon", timo=500) at ../../../kern/kern_synch.c:222 #5 0xc083b776 in nfs_connect (nmp=0xc54e4d20, rep=0xc76b9980) at ../../../nfsclient/nfs_socket.c:371 #6 0xc083bf9a in nfs_reconnect (rep=0xc76b9980) at ../../../nfsclient/nfs_socket.c:542 #7 0xc083e6e5 in nfs_request (vp=0xc4f7e8a0, mrest=0xc539c000, procnum=1, td=0xc5ba9690, cred=0xc6f46b00, mrp=0xef940904, mdp=0xef940900, dposp=0xef940908) at ../../../nfsclient/nfs_socket.c:737 #8 0xc0846ecb in nfs_getattr (ap=0xef9409d8) at ../../../nfsclient/nfs_vnops.c:662 #9 0xc0930702 in VOP_GETATTR_APV (vop=0xc0a27aa0, a=0xef9409d8) at vnode_if.c:530 #10 0xc084a587 in nfs_lookup (ap=0xef940a84) at vnode_if.h:286 #11 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a27aa0, a=0xef940a84) at vnode_if.c:99 #12 0xc072ea95 in lookup (ndp=0xef940ba8) at vnode_if.h:57 #13 0xc072f794 in namei (ndp=0xef940ba8) at ../../../kern/vfs_lookup.c:219 #14 0xc073ce92 in kern_stat (td=0xc5ba9690, path=0x807914c
, pathseg=UIO_USERSPACE, sbp=0xef940c18) at ../../../kern/vfs_syscalls.c:2113 #15 0xc073d05f in stat (td=0xc5ba9690, uap=0xef940cfc) at ../../../kern/vfs_syscalls.c:2097 #16 0xc091d0a5 in syscall (frame=0xef940d38) at ../../../i386/i386/trap.c:1090 #17 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #18 0x00000033 in ?? () (kgdb) [Switching to thread 119 (Thread 100332)] #0 sched_switch (td=0xc5500000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5500000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3310354432, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc5500000, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc5500000, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xefaa5d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xefaa5d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0xbfbfeab8 in ?? () #15 0xbfbfe9c8 in ?? () #16 0xbfbfe988 in ?? () #17 0xefaa5d64 in ?? () #18 0x00000001 in ?? () #19 0x0818b080 in ?? () #20 0x0818b080 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000282 in ?? () #27 0xbfbfe96c in ?? () #28 0x0000003b in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc55001fc in ?? () #36 0xefaa5a40 in ?? () #37 0xefaa5a04 in ?? () #38 0xc5500000 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 118 (Thread 100311)] #0 sched_switch (td=0xc5063230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5063230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5c8e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c47bd in _sx_xlock_hard (sx=0xc0a5c8e8, tid=3305517616, opts=0, file=0x0, line=0) at ../../../kern/kern_sx.c:560 #5 0xc0698e86 in exit1 (td=0xc5063230, rv=15) at sx.h:153 #6 0xc06bf779 in sigexit (td=0xc5063230, sig=15) at ../../../kern/kern_sig.c:2882 #7 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #8 0xc06f0023 in ast (framep=0xefa49d38) at ../../../kern/subr_trap.c:252 #9 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #10 0xefa49d38 in ?? () #11 0x0000003b in ?? () #12 0x0000003b in ?? () #13 0x0000003b in ?? () #14 0x00000000 in ?? () #15 0xbfbfebc8 in ?? () #16 0xbfbfeb88 in ?? () #17 0xefa49d64 in ?? () #18 0x00000001 in ?? () #19 0x0818b080 in ?? () #20 0x0818b080 in ?? () #21 0x00000007 in ?? () #22 0x0000000c in ?? () #23 0x00000002 in ?? () #24 0x08081869 in ?? () #25 0x00000033 in ?? () #26 0x00000282 in ?? () #27 0xbfbfeb6c in ?? () #28 0x0000003b in ?? () #29 0x00000000 in ?? () #30 0xbfbf9d60 in ?? () #31 0x00000000 in ?? () #32 0x080e03a8 in ?? () #33 0x00c1e000 in ?? () #34 0xc0a66c84 in sleepq_chains () #35 0xc506342c in ?? () #36 0xefa49a40 in ?? () #37 0xefa49a04 in ?? () #38 0xc5063230 in ?? () #39 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 117 (Thread 100170)] #0 sched_switch (td=0xc531e460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc531e460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a6e8a8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc0a6e8a8) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc0a6e8a8, lock=0xc0a6e870, priority=348, wmesg=0xc098792e "-", timo=900000) at ../../../kern/kern_synch.c:220 #6 0xc0841a1a in nfssvc_iod (instance=0xc0a6e228) at ../../../nfsclient/nfs_nfsiod.c:244 #7 0xc069a351 in fork_exit (callout=0xc084192c , arg=0xc0a6e228, frame=0xef834d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 116 (Thread 100343)] #0 sched_switch (td=0xcba8e000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcba8e000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc6e9e410) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc6e9e410) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc6e9e410, lock=0x0, priority=345, wmesg=0xc09913ac "ttyin", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06fedb0 in ttysleep (tp=0xc6e9e400, chan=0xc6e9e410, pri=345, wmesg=0xc09913ac "ttyin", timo=0) at ../../../kern/tty.c:2822 #7 0xc0703292 in ttread (tp=0xc6e9e400, uio=0xefac6c60, flag=0) at ../../../kern/tty.c:1877 #8 0xc0706db3 in ptsread (dev=0xc619c900, uio=0xefac6c60, flag=0) at linedisc.h:100 #9 0xc06845ec in giant_read (dev=0xc619c900, uio=0xefac6c60, ioflag=0) at ../../../kern/kern_conf.c:424 #10 0xc064ce52 in devfs_read_f (fp=0xc83cc04c, uio=0xefac6c60, cred=0xc68b9000, flags=0, td=0xcba8e000) at ../../../fs/devfs/devfs_vnops.c:1000 #11 0xc06f358d in dofileread (td=0xcba8e000, fd=10, fp=0xc83cc04c, auio=0xefac6c60, offset=-1, flags=0) at file.h:244 #12 0xc06f389e in kern_readv (td=0xcba8e000, fd=10, auio=0xefac6c60) at ../../../kern/sys_generic.c:192 #13 0xc06f3968 in read (td=0xcba8e000, uap=0xefac6cfc) at ../../../kern/sys_generic.c:108 #14 0xc091d0a5 in syscall (frame=0xefac6d38) at ../../../i386/i386/trap.c:1090 #15 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #16 0x00000033 in ?? () (kgdb) [Switching to thread 115 (Thread 100299)] #0 sched_switch (td=0xc5d3caf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5d3caf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8fc0ea0) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8fc0ea0, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8fc0ea0, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8fc0ea0) at ../../../kern/vfs_bio.c:3057 #7 0xc0726f54 in breadn (vp=0xca664ac8, blkno=3, size=12288, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0xefa25a50) at ../../../kern/vfs_bio.c:806 #8 0xc0726fd0 in bread (vp=0xca664ac8, blkno=) at ../../../kern/vfs_bio.c:734 #9 0xc088b956 in ffs_balloc_ufs2 (vp=0xca664ac8, startoffset=) at ../../../ufs/ffs/ffs_balloc.c:681 #10 0xc08a965c in ffs_write (ap=0xefa25bc4) at ../../../ufs/ffs/ffs_vnops.c:724 #11 0xc0931c50 in VOP_WRITE_APV (vop=0xc0a2aa00, a=0xefa25bc4) at vnode_if.c:691 #12 0xc07476bb in vn_write (fp=0xc5570e40, uio=0xefa25c60, active_cred=0xc68b5800, flags=0, td=0xc5d3caf0) at vnode_if.h:373 #13 0xc06f31e7 in dofilewrite (td=0xc5d3caf0, fd=3, fp=0xc5570e40, auio=0xefa25c60, offset=-1, flags=0) at file.h:256 #14 0xc06f3491 in kern_writev (td=0xc5d3caf0, fd=3, auio=0xefa25c60) at ../../../kern/sys_generic.c:401 #15 0xc06f34fb in write (td=0xc5d3caf0, uap=0xefa25cfc) at ../../../kern/sys_generic.c:317 #16 0xc091d0a5 in syscall (frame=0xefa25d38) at ../../../i386/i386/trap.c:1090 #17 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #18 0x00000033 in ?? () (kgdb) [Switching to thread 114 (Thread 100224)] #0 sched_switch (td=0xc5bac8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5bac8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc56ce540) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc56ce540) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc56ce540, lock=0xc0a5e400, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5bac8c0, uap=0xef934cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5bac8c0, uap=0xef934cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef934d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 113 (Thread 100366)] #0 sched_switch (td=0xcadd6d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcadd6d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc60dc4c0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc60dc4c0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc60dc4c0, lock=0xc0a5d408, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xcadd6d20, uap=0xefb0bcfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xcadd6d20, uap=0xefb0bcfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xefb0bd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 112 (Thread 100364)] #0 sched_switch (td=0xc729c8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc729c8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc7fa8000) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc7fa8000) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc7fa8000, lock=0xc0a5db78, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc729c8c0, uap=0xefb05cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc729c8c0, uap=0xefb05cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xefb05d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 111 (Thread 100214)] #0 sched_switch (td=0xc5853460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5853460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc61bd200) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc61bd200) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc61bd200, lock=0xc61bd200, priority=344, wmesg=0xc098b01a "kqread", timo=25) at ../../../kern/kern_synch.c:220 #6 0xc06934f7 in kern_kevent (td=0xc5853460, fd=4, nchanges=0, nevents=32, k_ops=0xef8efc40, timeout=0xef8efc4c) at ../../../kern/kern_event.c:1292 #7 0xc0693dd4 in kevent (td=0xc5853460, uap=0xef8efcfc) at ../../../kern/kern_event.c:646 #8 0xc091d0a5 in syscall (frame=0xef8efd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 110 (Thread 100289)] #0 sched_switch (td=0xc5511d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5511d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xca664b20) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xca664b20, lock=0xc0a5c7d0, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xefa07810, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xca664b20, flags=8194, interlkp=0xca664b50, td=0xc5511d20, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xefa07878) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xefa07878) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xca664ac8, flags=8194, td=0xc5511d20, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xca664ac8, flags=8194, td=0xc5511d20) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc511fcf0, vpp=0xefa07b90, cnp=0xefa07ba4) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xefa079b4) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xefa079b4) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xefa07b7c) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xefa07b7c) at ../../../kern/vfs_lookup.c:219 #16 0xc07455d6 in vn_open_cred (ndp=0xefa07b7c, flagp=0xefa07c78, cmode=384, cred=0xc564a000, fp=0xc8088b94) at ../../../kern/vfs_vnops.c:130 #17 0xc0745b37 in vn_open (ndp=0xefa07b7c, flagp=0xefa07c78, cmode=384, fp=0xc8088b94) at ../../../kern/vfs_vnops.c:94 #18 0xc07438e6 in kern_open (td=0xc5511d20, path=0x808a86b
, pathseg=UIO_USERSPACE, flags=2563, mode=384) at ../../../kern/vfs_syscalls.c:1032 #19 0xc0743e42 in open (td=0xc5511d20, uap=0xefa07cfc) at ../../../kern/vfs_syscalls.c:999 #20 0xc091d0a5 in syscall (frame=0xefa07d38) at ../../../i386/i386/trap.c:1090 #21 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #22 0x00000033 in ?? () (kgdb) [Switching to thread 109 (Thread 100280)] #0 sched_switch (td=0xc5d3e000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5d3e000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc7ce3010) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc7ce3010) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc7ce3010, lock=0x0, priority=345, wmesg=0xc09913ac "ttyin", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06fedb0 in ttysleep (tp=0xc7ce3000, chan=0xc7ce3010, pri=345, wmesg=0xc09913ac "ttyin", timo=0) at ../../../kern/tty.c:2822 #7 0xc0703292 in ttread (tp=0xc7ce3000, uio=0xef9ecc60, flag=0) at ../../../kern/tty.c:1877 #8 0xc0706db3 in ptsread (dev=0xc6612100, uio=0xef9ecc60, flag=0) at linedisc.h:100 #9 0xc06845ec in giant_read (dev=0xc6612100, uio=0xef9ecc60, ioflag=0) at ../../../kern/kern_conf.c:424 #10 0xc064ce52 in devfs_read_f (fp=0xc6575be0, uio=0xef9ecc60, cred=0xc74ee100, flags=0, td=0xc5d3e000) at ../../../fs/devfs/devfs_vnops.c:1000 #11 0xc06f358d in dofileread (td=0xc5d3e000, fd=10, fp=0xc6575be0, auio=0xef9ecc60, offset=-1, flags=0) at file.h:244 #12 0xc06f389e in kern_readv (td=0xc5d3e000, fd=10, auio=0xef9ecc60) at ../../../kern/sys_generic.c:192 #13 0xc06f3968 in read (td=0xc5d3e000, uap=0xef9eccfc) at ../../../kern/sys_generic.c:108 #14 0xc091d0a5 in syscall (frame=0xef9ecd38) at ../../../i386/i386/trap.c:1090 #15 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #16 0x00000033 in ?? () (kgdb) [Switching to thread 108 (Thread 100268)] #0 sched_switch (td=0xc74afd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc74afd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc74b65d0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc74b65d0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc74b65d0, lock=0xc74b6600, priority=360, wmesg=0xc0965c7e "pause", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06be494 in kern_sigsuspend (td=0xc74afd20, mask={__bits = {0, 0, 0, 0}}) at ../../../kern/kern_sig.c:1474 #7 0xc06be532 in sigsuspend (td=0xc74afd20, uap=0xef9accfc) at ../../../kern/kern_sig.c:1453 #8 0xc091d0a5 in syscall (frame=0xef9acd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 107 (Thread 100324)] #0 sched_switch (td=0xc692caf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692caf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc623d680) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc623d680) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc623d680, lock=0xc623d6c4, priority=339, wmesg=0xc099e71c "nfsreq", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc083ea75 in nfs_request (vp=0xc5124ac8, mrest=0xc539c500, procnum=1, td=0xc692caf0, cred=0xc68b5800, mrp=0xefa8d7ec, mdp=0xefa8d7e8, dposp=0xefa8d7f0) at ../../../nfsclient/nfs_socket.c:778 #7 0xc0846ecb in nfs_getattr (ap=0xefa8d838) at ../../../nfsclient/nfs_vnops.c:662 #8 0xc0930702 in VOP_GETATTR_APV (vop=0xc0a27aa0, a=0xefa8d838) at vnode_if.c:530 #9 0xc08491c6 in nfsspec_access (ap=0xefa8d9d8) at vnode_if.h:286 #10 0xc0849434 in nfs_access (ap=0xefa8d9d8) at ../../../nfsclient/nfs_vnops.c:392 #11 0xc0930682 in VOP_ACCESS_APV (vop=0xc0a27aa0, a=0xefa8d9d8) at vnode_if.c:477 #12 0xc084a503 in nfs_lookup (ap=0xefa8da84) at vnode_if.h:257 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a27aa0, a=0xefa8da84) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xefa8dba8) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xefa8dba8) at ../../../kern/vfs_lookup.c:219 #16 0xc073ce92 in kern_stat (td=0xc692caf0, path=0x80f8880
, pathseg=UIO_USERSPACE, sbp=0xefa8dc18) at ../../../kern/vfs_syscalls.c:2113 #17 0xc073d05f in stat (td=0xc692caf0, uap=0xefa8dcfc) at ../../../kern/vfs_syscalls.c:2097 #18 0xc091d0a5 in syscall (frame=0xefa8dd38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 106 (Thread 100086)] #0 sched_switch (td=0xc5137d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5137d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06eff31 in ast (framep=0xef702d38) at ../../../kern/subr_trap.c:241 #3 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #4 0xef702d38 in ?? () #5 0x0000003b in ?? () #6 0x0000003b in ?? () #7 0x0000003b in ?? () #8 0x084ae000 in ?? () #9 0x00000009 in ?? () #10 0xbfbfe098 in ?? () #11 0xef702d64 in ?? () #12 0x2820a878 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x0000000c in ?? () #17 0x00000007 in ?? () #18 0x281870aa in ?? () #19 0x00000033 in ?? () #20 0x00010297 in ?? () #21 0xbfbfe060 in ?? () #22 0x0000003b in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x00000000 in ?? () #26 0x00000000 in ?? () #27 0x0b511000 in ?? () #28 0xc0a651c0 in tdq_cpu () #29 0xc5137f1c in ?? () #30 0xef702cd4 in ?? () #31 0xef702c98 in ?? () #32 0x2412c00f in ?? () #33 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 105 (Thread 100097)] #0 sched_switch (td=0xc692c8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692c8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc692c8c0, nd=1024, fd_in=0xbf4f9f00, fd_ou=0xbf4f9e80, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc692c8c0, uap=0xef733cfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef733d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 104 (Thread 100096)] #0 sched_switch (td=0xc5502690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5502690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc611cb40) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc611cb40) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc611cb40, lock=0xc0a5e588, priority=256, wmesg=0xc098e57e "ucond", timo=576) at ../../../kern/kern_synch.c:220 #6 0xc06d39e7 in __umtx_op_cv_wait (td=0xc5502690, uap=0xef730cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5502690, uap=0xef730cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef730d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 103 (Thread 100095)] #0 sched_switch (td=0xc692c690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692c690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc60d8ac0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc60d8ac0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc60d8ac0, lock=0xc0a5dc90, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc692c690, uap=0xef72dcfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc692c690, uap=0xef72dcfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef72dd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 102 (Thread 100094)] #0 sched_switch (td=0xc692c460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692c460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc61044c0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc61044c0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc61044c0, lock=0xc0a5dc90, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc692c460, uap=0xef72acfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc692c460, uap=0xef72acfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef72ad38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 101 (Thread 100093)] #0 sched_switch (td=0xc692bd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692bd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc60f4080) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc60f4080) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc60f4080, lock=0xc0a5dc90, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc692bd20, uap=0xef727cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc692bd20, uap=0xef727cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef727d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 100 (Thread 100092)] #0 sched_switch (td=0xc692baf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc692baf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc60f4840) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc60f4840) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc60f4840, lock=0xc0a5dc90, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc692baf0, uap=0xef724cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc692baf0, uap=0xef724cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef724d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 99 (Thread 100047)] #0 sched_switch (td=0xc50edd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50edd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc50e81c0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc50e81c0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc50e81c0, lock=0xc0a5e128, priority=256, wmesg=0xc098e557 "uwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06cf74b in do_wait (td=) at ../../../kern/kern_umtx.c:482 #7 0xc06cfbb3 in __umtx_op_wait (td=0xc50edd20, uap=0xef635cfc) at ../../../kern/kern_umtx.c:2744 #8 0xc06cec88 in _umtx_op (td=0xc50edd20, uap=0xef635cfc) at ../../../kern/kern_umtx.c:2926 #9 0xc091d0a5 in syscall (frame=0xef635d38) at ../../../i386/i386/trap.c:1090 #10 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #11 0x00000033 in ?? () (kgdb) [Switching to thread 98 (Thread 100195)] #0 sched_switch (td=0xc5b748c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5b748c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a6e8a4) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc0a6e8a4) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc0a6e8a4, lock=0xc0a6e870, priority=348, wmesg=0xc098792e "-", timo=900000) at ../../../kern/kern_synch.c:220 #6 0xc0841a1a in nfssvc_iod (instance=0xc0a6e224) at ../../../nfsclient/nfs_nfsiod.c:244 #7 0xc069a351 in fork_exit (callout=0xc084192c , arg=0xc0a6e224, frame=0xef8a4d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 97 (Thread 100151)] #0 doadump () at pcpu.h:196 in pcpu.h (kgdb) #0 doadump () at pcpu.h:196 #1 0xc06bd1e6 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xc06bd4e3 in panic (fmt=) at ../../../kern/kern_shutdown.c:574 #3 0xc091cb09 in trap_fatal (frame=0xef7fb8c8, eva=172) at ../../../i386/i386/trap.c:939 #4 0xc091cd59 in trap_pfault (frame=0xef7fb8c8, usermode=0, eva=172) at ../../../i386/i386/trap.c:852 #5 0xc091d6eb in trap (frame=0xef7fb8c8) at ../../../i386/i386/trap.c:530 #6 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #7 0xc07f58fd in tcp_ctloutput (so=0xc71a0680, sopt=0xef7fbac8) at atomic.h:149 #8 0xc071024d in sosetopt (so=0xc71a0680, sopt=0xef7fbac8) at ../../../kern/uipc_socket.c:2339 #9 0xc083ba5c in nfs_connect (nmp=0xc54e4d20, rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:428 #10 0xc083bf9a in nfs_reconnect (rep=0xc6208000) at ../../../nfsclient/nfs_socket.c:542 #11 0xc083e6e5 in nfs_request (vp=0xc81e0228, mrest=0xc56f4000, procnum=7, td=0x0, cred=0xc6f46b00, mrp=0xef7fbc08, mdp=0xef7fbc04, dposp=0xef7fbc0c) at ../../../nfsclient/nfs_socket.c:737 #12 0xc0847577 in nfs_writerpc (vp=0xc81e0228, uiop=0xef7fbc84, cred=0xc6f46b00, iomode=0xef7fbca8, must_commit=0xef7fbca4) at ../../../nfsclient/nfs_vnops.c:1183 #13 0xc083539f in nfs_doio (vp=0xc81e0228, bp=0xd8e7e074, cr=0xc6f46b00, td=0x0) at ../../../nfsclient/nfs_bio.c:1683 #14 0xc0841be5 in nfssvc_iod (instance=0xc0a6e220) at ../../../nfsclient/nfs_nfsiod.c:282 #15 0xc069a351 in fork_exit (callout=0xc084192c , arg=0xc0a6e220, frame=0xef7fbd38) at ../../../kern/kern_fork.c:804 #16 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 96 (Thread 100051)] #0 sched_switch (td=0xcba8e460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcba8e460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8f65914) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8f65914, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8f65914, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8f65914) at ../../../kern/vfs_bio.c:3057 #7 0xc08aae3c in ufs_bmaparray (vp=0xc5848678, bn=89, bnp=0xef645a60, nbp=0x0, runp=0xef645bcc, runb=0xef645bd0) at ../../../ufs/ufs/ufs_bmap.c:230 #8 0xc08ab3e9 in ufs_bmap (ap=0xef645ac0) at ../../../ufs/ufs/ufs_bmap.c:84 #9 0xc0930d03 in VOP_BMAP_APV (vop=0xc0a2aa00, a=0xef645ac0) at vnode_if.c:1717 #10 0xc08d9481 in vnode_pager_haspage (object=0xc584b0f8, pindex=356, before=0xef645bd0, after=0xef645bcc) at vnode_if.h:912 #11 0xc08c32be in vm_fault (map=0xc4d37e80, vaddr=135970816, fault_type=1 '\001', fault_flags=) at vm_pager.h:171 #12 0xc091cc49 in trap_pfault (frame=0xef645d38, usermode=1, eva=135974446) at ../../../i386/i386/trap.c:829 #13 0xc091d56f in trap (frame=0xef645d38) at ../../../i386/i386/trap.c:397 #14 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #15 0x081ace2e in ?? () (kgdb) [Switching to thread 95 (Thread 100087)] #0 sched_switch (td=0xc77a68c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc77a68c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc99cb8dc) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc99cb8dc) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc99cb8dc, lock=0xc99cb894, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xc99cb870) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xc99cb820, psa=0x0, uio=0xef706c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xc99cb820, psa=0x0, uio=0xef706c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc5bd6260, uio=0xef706c60, active_cred=0xc5b6c800, flags=0, td=0xc77a68c0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xc77a68c0, fd=20, fp=0xc5bd6260, auio=0xef706c60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xc77a68c0, fd=20, auio=0xef706c60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xc77a68c0, uap=0xef706cfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xef706d38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 94 (Thread 100205)] #0 sched_switch (td=0xc5854230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5854230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xef8ccbe0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xef8ccbe0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xef8ccbe0, lock=0xc54d18b8, priority=360, wmesg=0xc098b89f "sigwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06c04eb in kern_sigtimedwait (td=0xc5854230, waitset={__bits = {155653, 0, 0, 0}}, ksi=0xef8ccc24, timeout=0x0) at ../../../kern/kern_sig.c:1256 #7 0xc06c0979 in sigwait (td=0xc5854230, uap=0xef8cccfc) at ../../../kern/kern_sig.c:1093 #8 0xc091d0a5 in syscall (frame=0xef8ccd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 93 (Thread 100118)] #0 sched_switch (td=0xc54e1230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54e1230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc54e1230, nd=4, fd_in=0xbfbfe908, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc54e1230, uap=0xef78dcfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef78dd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 92 (Thread 100084)] #0 sched_switch (td=0xc5321af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5321af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8d642a8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8d642a8, lock=0xc0a68678, priority=68, wmesg=0xc09a519e "vnread", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8d642a8, pri=68 'D', wchan=0xc09a519e "vnread") at ../../../kern/vfs_bio.c:3802 #6 0xc08dba5b in vnode_pager_generic_getpages (vp=0xc588f9b4, m=0xef6fac04, bytecount=) at ../../../vm/vnode_pager.c:932 #7 0xc08a927a in ffs_getpages (ap=0xef6faacc) at ../../../ufs/ffs/ffs_vnops.c:851 #8 0xc0931083 in VOP_GETPAGES_APV (vop=0xc0a2aa00, a=0xef6faacc) at vnode_if.c:2136 #9 0xc08da14e in vnode_pager_getpages (object=0xc597a934, m=0xef6fac04, count=1, reqpage=0) at vnode_if.h:1129 #10 0xc08c3689 in vm_fault (map=0xc5360d98, vaddr=134537216, fault_type=1 '\001', fault_flags=) at vm_pager.h:130 #11 0xc091cc49 in trap_pfault (frame=0xef6fad38, usermode=1, eva=134538800) at ../../../i386/i386/trap.c:829 #12 0xc091d56f in trap (frame=0xef6fad38) at ../../../i386/i386/trap.c:397 #13 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #14 0x0804e630 in ?? () (kgdb) [Switching to thread 91 (Thread 100074)] #0 sched_switch (td=0xc512b460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512b460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef6c097c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc512b460, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef6c09e4) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef6c09e4) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc512b460, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc512b460) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef6c0af4) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef6c0b50, td=0xc512b460) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef6c0c10) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef6c0c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc512b460, path=0xbfbfd6e8
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc512b460, uap=0xef6c0cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef6c0d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 90 (Thread 100122)] #0 sched_switch (td=0xc54e08c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54e08c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef7a497c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc54e08c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef7a49e4) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef7a49e4) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc54e08c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc54e08c0) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef7a4af4) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef7a4b50, td=0xc54e08c0) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef7a4c10) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef7a4c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc54e08c0, path=0xbfbfcc28
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc54e08c0, uap=0xef7a4cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef7a4d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 89 (Thread 100050)] #0 sched_switch (td=0xc50ed8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50ed8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc50ed8c0, nd=20, fd_in=0xbfbfede0, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc50ed8c0, uap=0xef641cfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef641d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 88 (Thread 100157)] #0 sched_switch (td=0xc5846af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5846af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4f7dd48) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4f7dd48, lock=0xc0a5c5c0, priority=80, wmesg=0xc09870fd "devfs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef80d8b4, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc4f7dd48, flags=12290, interlkp=0xc4f7dd78, td=0xc5846af0, file=0xc0994682 "../../../kern/vfs_vnops.c", line=288) at ../../../kern/kern_lock.c:384 #7 0xc072a951 in vop_stdlock (ap=0xef80d904) at ../../../kern/vfs_default.c:305 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a19240, a=0xef80d904) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc4f7dcf0, flags=4098, td=0xc5846af0, file=0xc0994682 "../../../kern/vfs_vnops.c", line=288) at vnode_if.h:851 #10 0xc0746f20 in vn_close (vp=0xc4f7dcf0, flags=3, file_cred=0xc4d0a100, td=0xc5846af0) at ../../../kern/vfs_vnops.c:288 #11 0xc0747078 in vn_closefile (fp=0xc5570720, td=0xc5846af0) at ../../../kern/vfs_vnops.c:867 #12 0xc064cb80 in devfs_close_f (fp=0xc5570720, td=0xc5846af0) at ../../../fs/devfs/devfs_vnops.c:479 #13 0xc0689e86 in fdrop (fp=0xc5570720, td=0xc5846af0) at file.h:299 #14 0xc068b388 in closef (fp=0xc5570720, td=0xc5846af0) at ../../../kern/kern_descrip.c:2033 #15 0xc068c4d1 in fdfree (td=0xc5846af0) at ../../../kern/kern_descrip.c:1743 #16 0xc0698d2c in exit1 (td=0xc5846af0, rv=15) at ../../../kern/kern_exit.c:283 #17 0xc06bf779 in sigexit (td=0xc5846af0, sig=15) at ../../../kern/kern_sig.c:2882 #18 0xc06bf96c in postsig (sig=15) at ../../../kern/kern_sig.c:2754 #19 0xc06f0023 in ast (framep=0xef80dd38) at ../../../kern/subr_trap.c:252 #20 0xc090534d in doreti_ast () at ../../../i386/i386/exception.s:349 #21 0xef80dd38 in ?? () #22 0x0000003b in ?? () #23 0x0000003b in ?? () #24 0xbfbf003b in ?? () #25 0x00000002 in ?? () #26 0x0000003c in ?? () #27 0xbfbfd7d8 in ?? () #28 0xef80dd64 in ?? () #29 0x28164878 in ?? () #30 0x0000003c in ?? () #31 0x00000000 in ?? () #32 0x00000004 in ?? () #33 0x00000020 in ?? () #34 0x00000002 in ?? () #35 0x28136f17 in ?? () #36 0x00000033 in ?? () #37 0x00000207 in ?? () #38 0xbfbfd7ac in ?? () #39 0x0000003b in ?? () #40 0x00000000 in ?? () #41 0x00000000 in ?? () #42 0x00000000 in ?? () #43 0x00000000 in ?? () #44 0x0b48c000 in ?? () #45 0xc0a66ed0 in sleepq_chains () #46 0xc5846cec in ?? () #47 0xef80d79c in ?? () #48 0xef80d760 in ?? () #49 0xc5846af0 in ?? () #50 0xc06dbb29 in sched_switch (td=) at ../../../kern/sched_ule.c:1938 (kgdb) [Switching to thread 87 (Thread 100065)] #0 sched_switch (td=0xc512c8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512c8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5851a0c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5851a0c, lock=0xc0a5c7e8, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef6a599c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5851a0c, flags=8194, interlkp=0xc5851a3c, td=0xc512c8c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef6a5a04) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef6a5a04) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc58519b4, flags=8194, td=0xc512c8c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc58519b4, flags=8194, td=0xc512c8c0) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc5222cf0, vpp=0xef6a5c24, cnp=0xef6a5c38) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xef6a5b40) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef6a5b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef6a5c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef6a5c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc512c8c0, path=0x8116d30
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc512c8c0, uap=0xef6a5cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef6a5d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 86 (Thread 100102)] #0 sched_switch (td=0xc531e8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc531e8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5222d48) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5222d48, lock=0xc0a5bfc0, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef74799c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5222d48, flags=8194, interlkp=0xc5222d78, td=0xc531e8c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef747a04) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef747a04) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5222cf0, flags=8194, td=0xc531e8c0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5222cf0, flags=8194, td=0xc531e8c0) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc5222e04, vpp=0xef747c24, cnp=0xef747c38) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xef747b40) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef747b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef747c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef747c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc531e8c0, path=0x8116d30
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc531e8c0, uap=0xef747cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef747d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 85 (Thread 100138)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 84 (Thread 100208)] #0 sched_switch (td=0xc50faaf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc50faaf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc674f25c) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc674f25c) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc674f25c, lock=0xc674f214, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xc674f1f0) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xc674f1a0, psa=0x0, uio=0xef8ddc60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xc674f1a0, psa=0x0, uio=0xef8ddc60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc526edf4, uio=0xef8ddc60, active_cred=0xc56e8800, flags=0, td=0xc50faaf0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xc50faaf0, fd=108, fp=0xc526edf4, auio=0xef8ddc60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xc50faaf0, fd=108, auio=0xef8ddc60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xc50faaf0, uap=0xef8ddcfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xef8ddd38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 83 (Thread 100365)] #0 sched_switch (td=0xc81b08c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc81b08c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc6c2425c) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc6c2425c) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc6c2425c, lock=0xc6c24214, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xc6c241f0) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xc6c241a0, psa=0x0, uio=0xefb08c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xc6c241a0, psa=0x0, uio=0xefb08c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc83cc474, uio=0xefb08c60, active_cred=0xc56e8800, flags=0, td=0xc81b08c0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xc81b08c0, fd=149, fp=0xc83cc474, auio=0xefb08c60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xc81b08c0, fd=149, auio=0xefb08c60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xc81b08c0, uap=0xefb08cfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xefb08d38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 82 (Thread 100368)] #0 sched_switch (td=0xc7cd3af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc7cd3af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc6eda3fc) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc6eda3fc) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc6eda3fc, lock=0xc6eda3b4, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xc6eda390) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xc6eda340, psa=0x0, uio=0xefb11c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xc6eda340, psa=0x0, uio=0xefb11c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc512017c, uio=0xefb11c60, active_cred=0xc56e8800, flags=0, td=0xc7cd3af0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xc7cd3af0, fd=183, fp=0xc512017c, auio=0xefb11c60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xc7cd3af0, fd=183, auio=0xefb11c60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xc7cd3af0, uap=0xefb11cfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xefb11d38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 81 (Thread 100363)] #0 sched_switch (td=0xcadc6af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xcadc6af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xcb98173c) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xcb98173c) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xcb98173c, lock=0xcb9816f4, priority=344, wmesg=0xc09921a1 "sbwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc070e220 in sbwait (sb=0xcb9816d0) at ../../../kern/uipc_sockbuf.c:130 #7 0xc0713f81 in soreceive_generic (so=0xcb981680, psa=0x0, uio=0xefb02c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:1487 #8 0xc070f59d in soreceive (so=0xcb981680, psa=0x0, uio=0xefb02c60, mp0=0x0, controlp=0x0, flagsp=0x0) at ../../../kern/uipc_socket.c:2032 #9 0xc06f9773 in soo_read (fp=0xc5570cc4, uio=0xefb02c60, active_cred=0xc56e8800, flags=0, td=0xcadc6af0) at ../../../kern/sys_socket.c:85 #10 0xc06f358d in dofileread (td=0xcadc6af0, fd=199, fp=0xc5570cc4, auio=0xefb02c60, offset=-1, flags=0) at file.h:244 #11 0xc06f389e in kern_readv (td=0xcadc6af0, fd=199, auio=0xefb02c60) at ../../../kern/sys_generic.c:192 #12 0xc06f3968 in read (td=0xcadc6af0, uap=0xefb02cfc) at ../../../kern/sys_generic.c:108 #13 0xc091d0a5 in syscall (frame=0xefb02d38) at ../../../i386/i386/trap.c:1090 #14 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #15 0x00000033 in ?? () (kgdb) [Switching to thread 80 (Thread 100169)] #0 sched_switch (td=0xc5854460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5854460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xef831be0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xef831be0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xef831be0, lock=0xc5243090, priority=360, wmesg=0xc098b89f "sigwait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06c04eb in kern_sigtimedwait (td=0xc5854460, waitset={__bits = {155653, 0, 0, 0}}, ksi=0xef831c24, timeout=0x0) at ../../../kern/kern_sig.c:1256 #7 0xc06c0979 in sigwait (td=0xc5854460, uap=0xef831cfc) at ../../../kern/kern_sig.c:1093 #8 0xc091d0a5 in syscall (frame=0xef831d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 79 (Thread 100166)] #0 sched_switch (td=0xc5854690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5854690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5700240) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5700240) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5700240, lock=0xc0a5e198, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5854690, uap=0xef828cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5854690, uap=0xef828cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef828d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 78 (Thread 100168)] #0 sched_switch (td=0xc58548c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc58548c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06826b1 in _cv_timedwait_sig (cvp=0xc0a681b8, lock=0xc0a681a0, timo=251) at ../../../kern/kern_condvar.c:369 #6 0xc06f49f2 in kern_select (td=0xc58548c0, nd=0, fd_in=0x0, fd_ou=0x0, fd_ex=0x0, tvp=0xef82ec70) at ../../../kern/sys_generic.c:786 #7 0xc06f4bfe in select (td=0xc58548c0, uap=0xef82ecfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef82ed38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 77 (Thread 100167)] #0 sched_switch (td=0xc5854af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5854af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06826b1 in _cv_timedwait_sig (cvp=0xc0a681b8, lock=0xc0a681a0, timo=251) at ../../../kern/kern_condvar.c:369 #6 0xc06f49f2 in kern_select (td=0xc5854af0, nd=0, fd_in=0x0, fd_ou=0x0, fd_ex=0x0, tvp=0xef82bc70) at ../../../kern/sys_generic.c:786 #7 0xc06f4bfe in select (td=0xc5854af0, uap=0xef82bcfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef82bd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 76 (Thread 100165)] #0 sched_switch (td=0xc5855000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5855000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc56cda40) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc56cda40) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc56cda40, lock=0xc0a5de18, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5855000, uap=0xef825cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5855000, uap=0xef825cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef825d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 75 (Thread 100164)] #0 sched_switch (td=0xc5855230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5855230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc56cda00) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc56cda00) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc56cda00, lock=0xc0a5db08, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5855230, uap=0xef822cfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5855230, uap=0xef822cfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef822d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 74 (Thread 100163)] #0 sched_switch (td=0xc5137000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5137000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc513e680) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc513e680) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc513e680, lock=0xc0a5d7f8, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5137000, uap=0xef81fcfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5137000, uap=0xef81fcfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef81fd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 73 (Thread 100162)] #0 sched_switch (td=0xc5137230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5137230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc513e640) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc513e640) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc513e640, lock=0xc0a5d4e8, priority=256, wmesg=0xc098e57e "ucond", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc06d392b in __umtx_op_cv_wait (td=0xc5137230, uap=0xef81ccfc) at ../../../kern/kern_umtx.c:482 #7 0xc06cec88 in _umtx_op (td=0xc5137230, uap=0xef81ccfc) at ../../../kern/kern_umtx.c:2926 #8 0xc091d0a5 in syscall (frame=0xef81cd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 72 (Thread 100068)] #0 sched_switch (td=0xc512c230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512c230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc512c230, nd=14, fd_in=0xbfbfeab8, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc512c230, uap=0xef6aecfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef6aed38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 71 (Thread 100124)] #0 sched_switch (td=0xc54e0460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54e0460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc56bcae0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc56bcae0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc56bcae0, lock=0xc56bcb70, priority=348, wmesg=0xc09a6e08 "wait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc0698666 in kern_wait (td=0xc54e0460, pid=-1, status=0xef7aac2c, options=) at ../../../kern/kern_exit.c:897 #7 0xc0698700 in wait4 (td=0xc54e0460, uap=0xef7aacfc) at ../../../kern/kern_exit.c:683 #8 0xc091d0a5 in syscall (frame=0xef7aad38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 70 (Thread 100128)] #0 sched_switch (td=0xc545aaf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc545aaf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125a0c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125a0c, lock=0xc0a5bf78, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef7b680c, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125a0c, flags=8194, interlkp=0xc5125a3c, td=0xc545aaf0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef7b6874) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef7b6874) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc51259b4, flags=8194, td=0xc545aaf0, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc51259b4, flags=8194, td=0xc545aaf0) at ../../../kern/vfs_subr.c:2061 #11 0xc072843b in cache_lookup (dvp=0xc5125bdc, vpp=0xef7b6bb8, cnp=0xef7b6bcc) at ../../../kern/vfs_cache.c:442 #12 0xc0728540 in vfs_cache_lookup (ap=0xef7b69b0) at ../../../kern/vfs_cache.c:667 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef7b69b0) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef7b6ba4) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef7b6ba4) at ../../../kern/vfs_lookup.c:219 #16 0xc0719ad9 in unp_connect (so=0xc600b340, nam=) at ../../../kern/uipc_usrreq.c:1140 #17 0xc071c23c in uipc_connect (so=0xc600b340, nam=0xc625fa60, td=0xc545aaf0) at ../../../kern/uipc_usrreq.c:504 #18 0xc070f517 in soconnect (so=0xc600b340, nam=0xc625fa60, td=0xc545aaf0) at ../../../kern/uipc_socket.c:771 #19 0xc0716619 in kern_connect (td=0xc545aaf0, fd=3, sa=0xc625fa60) at ../../../kern/uipc_syscalls.c:570 #20 0xc071679e in connect (td=0xc545aaf0, uap=0xef7b6cfc) at ../../../kern/uipc_syscalls.c:534 #21 0xc091d0a5 in syscall (frame=0xef7b6d38) at ../../../i386/i386/trap.c:1090 #22 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #23 0x00000033 in ?? () (kgdb) [Switching to thread 69 (Thread 100115)] #0 sched_switch (td=0xc5458000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5458000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8d6dd04) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8d6dd04, lock=0xc0a68678, priority=68, wmesg=0xc09a519e "vnread", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8d6dd04, pri=68 'D', wchan=0xc09a519e "vnread") at ../../../kern/vfs_bio.c:3802 #6 0xc08dba5b in vnode_pager_generic_getpages (vp=0xc56cb9b4, m=0xef7839e8, bytecount=) at ../../../vm/vnode_pager.c:932 #7 0xc08a927a in ffs_getpages (ap=0xef7838b0) at ../../../ufs/ffs/ffs_vnops.c:851 #8 0xc0931083 in VOP_GETPAGES_APV (vop=0xc0a2aa00, a=0xef7838b0) at vnode_if.c:2136 #9 0xc08da14e in vnode_pager_getpages (object=0xc558a000, m=0xef7839e8, count=5, reqpage=0) at vnode_if.h:1129 #10 0xc08c3689 in vm_fault (map=0xc4d37570, vaddr=134565888, fault_type=1 '\001', fault_flags=) at vm_pager.h:130 #11 0xc091cc49 in trap_pfault (frame=0xef783b1c, usermode=0, eva=134567879) at ../../../i386/i386/trap.c:829 #12 0xc091d6eb in trap (frame=0xef783b1c) at ../../../i386/i386/trap.c:530 #13 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #14 0xc091af8f in copyinstr () at ../../../i386/i386/support.s:1351 #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000002 in ?? () #24 0x0500000c in ?? () #25 0xc5458000 in ?? () #26 0xc4d0a100 in ?? () #27 0x00000000 in ?? () #28 0xc551d800 in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00000000 in ?? () #34 0xc54d22b8 in ?? () #35 0xc5458000 in ?? () #36 0xef783c80 in ?? () #37 0xc073fca9 in unlink (td=0xef783c10, uap=0x0) at ../../../kern/vfs_syscalls.c:1653 (kgdb) [Switching to thread 68 (Thread 100053)] #0 sched_switch (td=0xc50ed230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50ed230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8d6a29c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8d6a29c, lock=0xc0a68678, priority=68, wmesg=0xc09a519e "vnread", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8d6a29c, pri=68 'D', wchan=0xc09a519e "vnread") at ../../../kern/vfs_bio.c:3802 #6 0xc08dba5b in vnode_pager_generic_getpages (vp=0xc558e9b4, m=0xef64dc04, bytecount=) at ../../../vm/vnode_pager.c:932 #7 0xc08a927a in ffs_getpages (ap=0xef64dacc) at ../../../ufs/ffs/ffs_vnops.c:851 #8 0xc0931083 in VOP_GETPAGES_APV (vop=0xc0a2aa00, a=0xef64dacc) at vnode_if.c:2136 #9 0xc08da14e in vnode_pager_getpages (object=0xc558aa2c, m=0xef64dc04, count=1, reqpage=0) at vnode_if.h:1129 #10 0xc08c3689 in vm_fault (map=0xc5323d98, vaddr=134520832, fault_type=1 '\001', fault_flags=) at vm_pager.h:130 #11 0xc091cc49 in trap_pfault (frame=0xef64dd38, usermode=1, eva=134521497) at ../../../i386/i386/trap.c:829 #12 0xc091d56f in trap (frame=0xef64dd38) at ../../../i386/i386/trap.c:397 #13 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #14 0x0804a299 in ?? () (kgdb) [Switching to thread 67 (Thread 100099)] #0 sched_switch (td=0xc5321000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5321000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5125c34) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5125c34, lock=0xc0a5bf48, priority=80, wmesg=0xc09896b6 "ufs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef73b7ec, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc5125c34, flags=8194, interlkp=0xc5125c64, td=0xc5321000, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at ../../../kern/kern_lock.c:384 #7 0xc08a8fec in ffs_lock (ap=0xef73b854) at ../../../ufs/ffs/ffs_vnops.c:377 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a2aa00, a=0xef73b854) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc5125bdc, flags=8194, td=0xc5321000, file=0xc0994187 "../../../kern/vfs_subr.c", line=2061) at vnode_if.h:851 #10 0xc0739b5e in vget (vp=0xc5125bdc, flags=8194, td=0xc5321000) at ../../../kern/vfs_subr.c:2061 #11 0xc072d89d in vfs_hash_get (mp=0xc50b5598, hash=2, flags=) at ../../../kern/vfs_hash.c:81 #12 0xc08a3add in ffs_vget (mp=0xc50b5598, ino=2, flags=2, vpp=0xef73b964) at ../../../ufs/ffs/ffs_vfsops.c:1307 #13 0xc08b39d8 in ufs_root (mp=0xc50b5598, flags=2, vpp=0xef73b9c0, td=0xc5321000) at ../../../ufs/ufs/ufs_vfsops.c:78 #14 0xc072eea0 in lookup (ndp=0xef73bba4) at ../../../kern/vfs_lookup.c:679 #15 0xc072f794 in namei (ndp=0xef73bba4) at ../../../kern/vfs_lookup.c:219 #16 0xc0719ad9 in unp_connect (so=0xc6c1cb60, nam=) at ../../../kern/uipc_usrreq.c:1140 #17 0xc071c23c in uipc_connect (so=0xc6c1cb60, nam=0xcbdc0880, td=0xc5321000) at ../../../kern/uipc_usrreq.c:504 #18 0xc070f517 in soconnect (so=0xc6c1cb60, nam=0xcbdc0880, td=0xc5321000) at ../../../kern/uipc_socket.c:771 #19 0xc0716619 in kern_connect (td=0xc5321000, fd=5, sa=0xcbdc0880) at ../../../kern/uipc_syscalls.c:570 #20 0xc071679e in connect (td=0xc5321000, uap=0xef73bcfc) at ../../../kern/uipc_syscalls.c:534 #21 0xc091d0a5 in syscall (frame=0xef73bd38) at ../../../i386/i386/trap.c:1090 #22 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #23 0x00000033 in ?? () (kgdb) [Switching to thread 66 (Thread 100119)] #0 sched_switch (td=0xc54e1000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54e1000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06f19e5 in turnstile_wait (ts=0xcbd87910, owner=0xc4e61af0, queue=) at ../../../kern/subr_turnstile.c:748 #3 0xc06bbe06 in _rw_wlock_hard (rw=0xcb93df60, tid=3310227456, file=0x0, line=0) at ../../../kern/kern_rwlock.c:685 #4 0xc07f65e5 in tcp_usr_rcvd (so=0xc6804000, flags=128) at ../../../netinet/tcp_usrreq.c:733 #5 0xc0714ab5 in soreceive_generic (so=0xc6804000, psa=0x0, uio=0xef790710, mp0=0xef79070c, controlp=0x0, flagsp=0xef790708) at ../../../kern/uipc_socket.c:1827 #6 0xc070f59d in soreceive (so=0xc6804000, psa=0x0, uio=0xef790710, mp0=0xef79070c, controlp=0x0, flagsp=0xef790708) at ../../../kern/uipc_socket.c:2032 #7 0xc0876b13 in svc_vc_recv (xprt=0xcb920900, msg=0xef790ad4) at ../../../rpc/svc_vc.c:620 #8 0xc087439c in svc_run (pool=0xc5157c80) at ../../../rpc/svc.c:467 #9 0xc08654a1 in nlm_syscall (td=0xc54e1000, uap=0xef790cfc) at ../../../nlm/nlm_prot_impl.c:1548 #10 0xc091d0a5 in syscall (frame=0xef790d38) at ../../../i386/i386/trap.c:1090 #11 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #12 0x00000033 in ?? () (kgdb) [Switching to thread 65 (Thread 100114)] #0 sched_switch (td=0xc5458230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5458230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5558000) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5558000) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5558000, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5458230, uap=0xef77fcfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef77fd38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 64 (Thread 100049)] #0 sched_switch (td=0xc4e62af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5558200) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5558200) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5558200, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc4e62af0, uap=0xef63dcfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef63dd38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 63 (Thread 100112)] #0 sched_switch (td=0xc5458690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5458690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc507c600) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc507c600) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc507c600, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5458690, uap=0xef778cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef778d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 62 (Thread 100111)] #0 sched_switch (td=0xc54588c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc54588c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5175e00) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5175e00) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5175e00, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc54588c0, uap=0xef775cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef775d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 61 (Thread 100110)] #0 sched_switch (td=0xc5458af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5458af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc507c400) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc507c400) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc507c400, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5458af0, uap=0xef772cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef772d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 60 (Thread 100107)] #0 sched_switch (td=0xc5459000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5459000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5558400) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5558400) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5558400, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5459000, uap=0xef768cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef768d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 59 (Thread 100077)] #0 sched_switch (td=0xc5250460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5250460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5176000) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5176000) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5176000, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5250460, uap=0xef6c9cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef6c9d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 58 (Thread 100105)] #0 sched_switch (td=0xc5459460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5459460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc5558600) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc5558600) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc5558600, lock=0xc0a73b60, priority=344, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc085f3aa in nfssvc (td=0xc5459460, uap=0xef762cfc) at ../../../nfsserver/nfs_syscalls.c:319 #7 0xc091d0a5 in syscall (frame=0xef762d38) at ../../../i386/i386/trap.c:1090 #8 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #9 0x00000033 in ?? () (kgdb) [Switching to thread 57 (Thread 100057)] #0 sched_switch (td=0xc512cd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512cd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc512cd20, nd=5, fd_in=0xbfbfed48, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc512cd20, uap=0xef65dcfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef65dd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 56 (Thread 100069)] #0 sched_switch (td=0xc512c000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512c000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8d6b1e8) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8d6b1e8, lock=0xc0a68678, priority=68, wmesg=0xc09a519e "vnread", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8d6b1e8, pri=68 'D', wchan=0xc09a519e "vnread") at ../../../kern/vfs_bio.c:3802 #6 0xc08dba5b in vnode_pager_generic_getpages (vp=0xc54ce678, m=0xef6b1c04, bytecount=) at ../../../vm/vnode_pager.c:932 #7 0xc08a927a in ffs_getpages (ap=0xef6b1acc) at ../../../ufs/ffs/ffs_vnops.c:851 #8 0xc0931083 in VOP_GETPAGES_APV (vop=0xc0a2aa00, a=0xef6b1acc) at vnode_if.c:2136 #9 0xc08da14e in vnode_pager_getpages (object=0xc104bc1c, m=0xef6b1c04, count=1, reqpage=0) at vnode_if.h:1129 #10 0xc08c3689 in vm_fault (map=0xc5215e80, vaddr=134512640, fault_type=1 '\001', fault_flags=) at vm_pager.h:130 #11 0xc091cc49 in trap_pfault (frame=0xef6b1d38, usermode=1, eva=134514120) at ../../../i386/i386/trap.c:829 #12 0xc091d56f in trap (frame=0xef6b1d38) at ../../../i386/i386/trap.c:397 #13 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #14 0x28054616 in ?? () (kgdb) [Switching to thread 55 (Thread 100098)] #0 sched_switch (td=0xc51378c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc51378c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc9131380) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edeb6 in sleepq_timedwait_sig (wchan=0xc9131380) at ../../../kern/subr_sleepqueue.c:631 #5 0xc06c52e1 in _sleep (ident=0xc9131380, lock=0xc9131380, priority=344, wmesg=0xc098b01a "kqread", timo=1251) at ../../../kern/kern_synch.c:220 #6 0xc06934f7 in kern_kevent (td=0xc51378c0, fd=10, nchanges=0, nevents=1, k_ops=0xef736c40, timeout=0xef736c4c) at ../../../kern/kern_event.c:1292 #7 0xc0693dd4 in kevent (td=0xc51378c0, uap=0xef736cfc) at ../../../kern/kern_event.c:646 #8 0xc091d0a5 in syscall (frame=0xef736d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 54 (Thread 100071)] #0 sched_switch (td=0xc512baf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512baf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8f4e300) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8f4e300, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8f4e300, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8f4e300) at ../../../kern/vfs_bio.c:3057 #7 0xc08aae3c in ufs_bmaparray (vp=0xc5361228, bn=24, bnp=0xef6b7a60, nbp=0x0, runp=0xef6b7bcc, runb=0xef6b7bd0) at ../../../ufs/ufs/ufs_bmap.c:230 #8 0xc08ab3e9 in ufs_bmap (ap=0xef6b7ac0) at ../../../ufs/ufs/ufs_bmap.c:84 #9 0xc0930d03 in VOP_BMAP_APV (vop=0xc0a2aa00, a=0xef6b7ac0) at vnode_if.c:1717 #10 0xc08d9481 in vnode_pager_haspage (object=0xc5310e0c, pindex=97, before=0xef6b7bd0, after=0xef6b7bcc) at vnode_if.h:912 #11 0xc08c32be in vm_fault (map=0xc5323658, vaddr=134909952, fault_type=1 '\001', fault_flags=) at vm_pager.h:171 #12 0xc091cc49 in trap_pfault (frame=0xef6b7d38, usermode=1, eva=134913578) at ../../../i386/i386/trap.c:829 #13 0xc091d56f in trap (frame=0xef6b7d38) at ../../../i386/i386/trap.c:397 #14 0xc0904a2b in calltrap () at ../../../i386/i386/exception.s:159 #15 0x080a9e2a in ?? () (kgdb) [Switching to thread 53 (Thread 100058)] #0 sched_switch (td=0xc5063d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5063d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4f7dd48) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4f7dd48, lock=0xc0a5c5c0, priority=80, wmesg=0xc09870fd "devfs", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06a9ab0 in acquire (lkpp=0xef661a00, extflags=) at ../../../kern/kern_lock.c:151 #6 0xc06aa33a in _lockmgr (lkp=0xc4f7dd48, flags=12290, interlkp=0xc4f7dd78, td=0xc5063d20, file=0xc0994682 "../../../kern/vfs_vnops.c", line=288) at ../../../kern/kern_lock.c:384 #7 0xc072a951 in vop_stdlock (ap=0xef661a50) at ../../../kern/vfs_default.c:305 #8 0xc0931811 in VOP_LOCK1_APV (vop=0xc0a19240, a=0xef661a50) at vnode_if.c:1618 #9 0xc074646a in _vn_lock (vp=0xc4f7dcf0, flags=4098, td=0xc5063d20, file=0xc0994682 "../../../kern/vfs_vnops.c", line=288) at vnode_if.h:851 #10 0xc0746f20 in vn_close (vp=0xc4f7dcf0, flags=3, file_cred=0xc4d0a100, td=0xc5063d20) at ../../../kern/vfs_vnops.c:288 #11 0xc0747078 in vn_closefile (fp=0xc5120c78, td=0xc5063d20) at ../../../kern/vfs_vnops.c:867 #12 0xc064cb80 in devfs_close_f (fp=0xc5120c78, td=0xc5063d20) at ../../../fs/devfs/devfs_vnops.c:479 #13 0xc0689e86 in fdrop (fp=0xc5120c78, td=0xc5063d20) at file.h:299 #14 0xc068b388 in closef (fp=0xc5120c78, td=0xc5063d20) at ../../../kern/kern_descrip.c:2033 #15 0xc068c4d1 in fdfree (td=0xc5063d20) at ../../../kern/kern_descrip.c:1743 #16 0xc0698d2c in exit1 (td=0xc5063d20, rv=512) at ../../../kern/kern_exit.c:283 #17 0xc069a14a in sys_exit (td=) at ../../../kern/kern_exit.c:109 #18 0xc091d0a5 in syscall (frame=0xef661d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 52 (Thread 100055)] #0 sched_switch (td=0xc4e628c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e628c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xd8ebfe8c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xd8ebfe8c, lock=0xc0a68678, priority=76, wmesg=0xc09926ef "biord", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc071fc31 in bwait (bp=0xd8ebfe8c, pri=76 'L', wchan=0xc09926ef "biord") at ../../../kern/vfs_bio.c:3802 #6 0xc071fca8 in bufwait (bp=0xd8ebfe8c) at ../../../kern/vfs_bio.c:3057 #7 0xc0726f54 in breadn (vp=0xc5230450, blkno=0, size=2048, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0xef6559e8) at ../../../kern/vfs_bio.c:806 #8 0xc0726fd0 in bread (vp=0xc5230450, blkno=) at ../../../kern/vfs_bio.c:734 #9 0xc08a2c33 in ffs_blkatoff (vp=0xc5230450, offset=0, res=0x0, bpp=0xef655a88) at ../../../ufs/ffs/ffs_subr.c:87 #10 0xc08af380 in ufs_lookup (ap=0xef655ac0) at ../../../ufs/ufs/ufs_lookup.c:269 #11 0xc0930482 in VOP_CACHEDLOOKUP_APV (vop=0xc0a2aa00, a=0xef655ac0) at vnode_if.c:153 #12 0xc0728569 in vfs_cache_lookup (ap=0xef655b40) at vnode_if.h:83 #13 0xc0931ed1 in VOP_LOOKUP_APV (vop=0xc0a2af20, a=0xef655b40) at vnode_if.c:99 #14 0xc072ea95 in lookup (ndp=0xef655c10) at vnode_if.h:57 #15 0xc072f794 in namei (ndp=0xef655c10) at ../../../kern/vfs_lookup.c:219 #16 0xc073fa82 in kern_unlink (td=0xc4e628c0, path=0xbfbfef59
, pathseg=UIO_USERSPACE) at ../../../kern/vfs_syscalls.c:1670 #17 0xc073fca9 in unlink (td=0xc4e628c0, uap=0xef655cfc) at ../../../kern/vfs_syscalls.c:1653 #18 0xc091d0a5 in syscall (frame=0xef655d38) at ../../../i386/i386/trap.c:1090 #19 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #20 0x00000033 in ?? () (kgdb) [Switching to thread 51 (Thread 100070)] #0 sched_switch (td=0xc512bd20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc512bd20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5b060) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5b060, lock=0xc0a5b048, priority=0, wmesg=0xc098792e "-", timo=3750) at ../../../kern/kern_synch.c:222 #5 0xc0680cf7 in acct_thread (dummy=0x0) at ../../../kern/kern_acct.c:644 #6 0xc069a351 in fork_exit (callout=0xc0680900 , arg=0x0, frame=0xef6b4d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 50 (Thread 100054)] #0 sched_switch (td=0xc50ed000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50ed000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc5087800) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc5087800, lock=0xc5087820, priority=588, wmesg=0xc097a234 "mdwait", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc05c644b in md_kthread (arg=0xc5087800) at ../../../dev/md/md.c:708 #6 0xc069a351 in fork_exit (callout=0xc05c62dc , arg=0xc5087800, frame=0xef651d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 49 (Thread 100062)] #0 sched_switch (td=0xc5140000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5140000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc0a681b8) at ../../../kern/subr_sleepqueue.c:594 #5 0xc0682adf in _cv_wait_sig (cvp=0xc0a681b8, lock=0xc0a681a0) at ../../../kern/kern_condvar.c:245 #6 0xc06f4a0a in kern_select (td=0xc5140000, nd=5, fd_in=0xbfbfedf8, fd_ou=0x0, fd_ex=0x0, tvp=0x0) at ../../../kern/sys_generic.c:788 #7 0xc06f4bfe in select (td=0xc5140000, uap=0xef67dcfc) at ../../../kern/sys_generic.c:663 #8 0xc091d0a5 in syscall (frame=0xef67dd38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 48 (Thread 100046)] #0 sched_switch (td=0xc4e62d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a74828) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a74828, lock=0xc0a747e8, priority=68, wmesg=0xc09a19b5 "sdflush", timo=250) at ../../../kern/kern_synch.c:222 #5 0xc089cf1f in softdep_flush () at ../../../ufs/ffs/ffs_softdep.c:770 #6 0xc069a351 in fork_exit (callout=0xc089cb5e , arg=0x0, frame=0xed446d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 47 (Thread 100045)] #0 sched_switch (td=0xc5062000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc50a1000) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc50a1000, lock=0xc0a688d8, priority=592, wmesg=0xc09942db "vlruwt", timo=250) at ../../../kern/kern_synch.c:222 #5 0xc073b638 in vnlru_proc () at ../../../kern/vfs_subr.c:737 #6 0xc069a351 in fork_exit (callout=0xc073b4e5 , arg=0x0, frame=0xed443d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 46 (Thread 100044)] #0 sched_switch (td=0xc5062230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5cd8c) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a5cd8c, lock=0xc0a68904, priority=104, wmesg=0xc0994294 "syncer", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc073ac7c in sched_sync () at ../../../kern/vfs_subr.c:1808 #6 0xc069a351 in fork_exit (callout=0xc073a365 , arg=0x0, frame=0xed440d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 45 (Thread 100043)] #0 sched_switch (td=0xc5062460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a68624) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a68624, lock=0xc0a68628, priority=68, wmesg=0xc0992acc "psleep", timo=250) at ../../../kern/kern_synch.c:222 #5 0xc0724a01 in buf_daemon () at ../../../kern/vfs_bio.c:2115 #6 0xc069a351 in fork_exit (callout=0xc072470b , arg=0x0, frame=0xed43dd38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 44 (Thread 100042)] #0 sched_switch (td=0xc5062690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a75420) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a75420, lock=0xc0a74fc4, priority=0, wmesg=0xc09a4f8b "pgzero", timo=75000) at ../../../kern/kern_synch.c:222 #5 0xc08d8a06 in vm_pagezero (arg=0x0) at ../../../vm/vm_zeroidle.c:136 #6 0xc069a351 in fork_exit (callout=0xc08d892b , arg=0x0, frame=0xed43ad38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 43 (Thread 100041)] #0 sched_switch (td=0xc50628c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc50628c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a75038) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a75038, lock=0xc0a7503c, priority=104, wmesg=0xc0992acc "psleep", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc08d469b in vm_daemon () at ../../../vm/vm_pageout.c:1536 #6 0xc069a351 in fork_exit (callout=0xc08d4623 , arg=0x0, frame=0xed437d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 42 (Thread 100040)] #0 sched_switch (td=0xc5062af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a75000) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a75000, lock=0xc0a74fc4, priority=68, wmesg=0xc0992acc "psleep", timo=1250) at ../../../kern/kern_synch.c:222 #5 0xc08d5017 in vm_pageout () at ../../../vm/vm_pageout.c:1476 #6 0xc069a351 in fork_exit (callout=0xc08d4d2c , arg=0x0, frame=0xed434d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 41 (Thread 100039)] #0 sched_switch (td=0xc5062d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5062d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4e97870) at ../../../kern/subr_sleepqueue.c:580 #4 0xc068249f in _cv_wait (cvp=0xc4e97870, lock=0xc4e97858) at ../../../kern/kern_condvar.c:134 #5 0xc08ecd9d in ipmi_dequeue_request (sc=0xc4e97800) at ../../../dev/ipmi/ipmi.c:566 #6 0xc08ef127 in kcs_loop (arg=0xc4e97800) at ../../../dev/ipmi/ipmi_kcs.c:458 #7 0xc069a351 in fork_exit (callout=0xc08eedc8 , arg=0xc4e97800, frame=0xed431d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 40 (Thread 100038)] #0 sched_switch (td=0xc5063000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc5063000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a6a6b4) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a6a6b4, lock=0xc0a6a5bc, priority=0, wmesg=0xc0997cbe "waiting_for_work", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc0795e8c in sctp_iterator_thread (v=0x0) at ../../../netinet/sctp_bsd_addr.c:95 #6 0xc069a351 in fork_exit (callout=0xc0795e0d , arg=0x0, frame=0xed42ed38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 39 (Thread 100037)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 38 (Thread 100036)] #0 sched_switch (td=0xc4e61000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4e61000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4e9d1a0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4e9d1a0, frame=0xed425d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 37 (Thread 100035)] #0 sched_switch (td=0xc4e61230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e61230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4e98bb0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4e98bb0, frame=0xed422d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 36 (Thread 100034)] #0 sched_switch (td=0xc4e61460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e61460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc4e0f23c) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc4e0f23c, lock=0xc4e0f2f0, priority=76, wmesg=0xc098792e "-", timo=250) at ../../../kern/kern_synch.c:222 #5 0xc08ea2f9 in fdc_thread (arg=0xc4e0f200) at ../../../dev/fdc/fdc.c:807 #6 0xc069a351 in fork_exit (callout=0xc08e9f44 , arg=0xc4e0f200, frame=0xed41fd38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 35 (Thread 100033)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 34 (Thread 100032)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 33 (Thread 100031)] #0 sched_switch (td=0xc4e61af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4e61af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06f19e5 in turnstile_wait (ts=0xc53204b0, owner=0xc54e1000, queue=) at ../../../kern/subr_turnstile.c:748 #3 0xc06b04d2 in _mtx_lock_sleep (m=0xcb920900, tid=3303414512, opts=0, file=0x0, line=0) at ../../../kern/kern_mutex.c:420 #4 0xc08764a8 in svc_vc_soupcall (so=0xc6804000, arg=0xcb920900, waitflag=1) at ../../../rpc/svc_vc.c:742 #5 0xc070e0bd in sowakeup (so=0xc6804000, sb=0xc6804050) at ../../../kern/uipc_sockbuf.c:192 #6 0xc07e7b04 in tcp_do_segment (m=0xcab7e200, th=0xc50e1824, so=0xc6804000, tp=0xc76521d0, drop_hdrlen=52, tlen=44) at ../../../netinet/tcp_input.c:1216 #7 0xc07ea0e4 in tcp_input (m=0xcab7e200, off0=20) at ../../../netinet/tcp_input.c:846 #8 0xc078b314 in ip_input (m=0xcab7e200) at ../../../netinet/ip_input.c:665 #9 0xc07690f9 in netisr_dispatch (num=2, m=0xcab7e200) at ../../../net/netisr.c:185 #10 0xc075d629 in ether_demux (ifp=0xc4e67000, m=0xcab7e200) at ../../../net/if_ethersubr.c:834 #11 0xc075d9fd in ether_input (ifp=0xc4e67000, m=0xcab7e200) at ../../../net/if_ethersubr.c:692 #12 0xc055d4b3 in em_rxeof (adapter=0xc4e02000, count=97) at ../../../dev/e1000/if_em.c:4511 #13 0xc055e092 in em_handle_rxtx (context=0xc4e02000, pending=1) at ../../../dev/e1000/if_em.c:1676 #14 0xc06ef030 in taskqueue_run (queue=0xc4e5f880) at ../../../kern/subr_taskqueue.c:282 #15 0xc06ef222 in taskqueue_thread_loop (arg=0xc4e02370) at ../../../kern/subr_taskqueue.c:401 #16 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc4e02370, frame=0xed3c4d38) at ../../../kern/kern_fork.c:804 #17 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 32 (Thread 100030)] #0 sched_switch (td=0xc4e61d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e61d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4e631c0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4e631c0, frame=0xed38cd38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 31 (Thread 100029)] #0 sched_switch (td=0xc4e62000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5a594) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a5a594, lock=0x0, priority=92, wmesg=0xc0986926 "usbtsk", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06446f3 in usb_task_thread (arg=0xc0a5a594) at ../../../dev/usb/usb.c:475 #6 0xc069a351 in fork_exit (callout=0xc0644676 , arg=0xc0a5a594, frame=0xe5389d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 30 (Thread 100028)] #0 sched_switch (td=0xc4e62230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a5a580) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a5a580, lock=0x0, priority=92, wmesg=0xc0986926 "usbtsk", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06446f3 in usb_task_thread (arg=0xc0a5a580) at ../../../dev/usb/usb.c:475 #6 0xc069a351 in fork_exit (callout=0xc0644676 , arg=0xc0a5a580, frame=0xe5386d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 29 (Thread 100027)] #0 sched_switch (td=0xc4e62460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e62460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc4e10210) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc4e10210, lock=0x0, priority=92, wmesg=0xc0986934 "usbevt", timo=15000) at ../../../kern/kern_synch.c:222 #5 0xc0644835 in usb_event_thread (arg=0xc4e44c00) at ../../../dev/usb/usb.c:445 #6 0xc069a351 in fork_exit (callout=0xc064474d , arg=0xc4e44c00, frame=0xe5383d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 28 (Thread 100026)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 27 (Thread 100025)] #0 sched_switch (td=0xc4d798c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4d798c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4e49aa0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4e49aa0, frame=0xe537cd38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 26 (Thread 100024)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 25 (Thread 100023)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 24 (Thread 100022)] #0 sched_switch (td=0xc4e0d000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4e0d000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77800) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77800, lock=0xc4d7781c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a6731c) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a6731c, frame=0xe5348d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 23 (Thread 100021)] #0 sched_switch (td=0xc4e0d230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0d230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4df83b0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4df83b0, frame=0xe5345d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 22 (Thread 100020)] #0 sched_switch (td=0xc4e0d460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0d460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77a00) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77a00, lock=0xc4d77a1c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a5b198) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a5b198, frame=0xe5342d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 21 (Thread 100019)] #0 sched_switch (td=0xc4e0d690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0d690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4df83e0) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4df83e0, frame=0xe533fd38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 20 (Thread 100018)] #0 sched_switch (td=0xc4e0d8c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0d8c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a3c654) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc0a3c654, lock=0xc0a3c66c, priority=76, wmesg=0xc09537e9 "ccb_scanq", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc0469d2a in xpt_scanner_thread (dummy=0x0) at ../../../cam/cam_xpt.c:1418 #6 0xc069a351 in fork_exit (callout=0xc0469ced , arg=0x0, frame=0xe533cd38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 19 (Thread 100017)] #0 sched_switch (td=0xc4e0daf0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4e0daf0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77c00) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77c00, lock=0xc4d77c1c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a3f304) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a3f304, frame=0xe5339d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 18 (Thread 100016)] #0 sched_switch (td=0xc4d35230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77c00) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77c00, lock=0xc4d77c1c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a3f304) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a3f304, frame=0xe5336d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 17 (Thread 100015)] #0 sched_switch (td=0xc4d35460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc4d77c00) at ../../../kern/subr_sleepqueue.c:580 #4 0xc06c5316 in _sleep (ident=0xc4d77c00, lock=0xc4d77c1c, priority=0, wmesg=0xc098792e "-", timo=0) at ../../../kern/kern_synch.c:226 #5 0xc06ef26a in taskqueue_thread_loop (arg=0xc0a3f304) at ../../../kern/subr_taskqueue.c:95 #6 0xc069a351 in fork_exit (callout=0xc06ef16d , arg=0xc0a3f304, frame=0xe5333d38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 16 (Thread 100014)] #0 sched_switch (td=0xc4d35690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4df8460) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4df8460, frame=0xe5330d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 15 (Thread 100013)] #0 sched_switch (td=0xc4d358c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d358c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4df8470) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4df8470, frame=0xe532dd38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 14 (Thread 100012)] #0 sched_switch (td=0xc4d35af0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35af0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5cd94) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5cd94, lock=0x0, priority=0, wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:222 #5 0xc06c53f8 in pause (wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:330 #6 0xc060edae in random_kthread (arg=0x0) at ../../../dev/random/randomdev_soft.c:281 #7 0xc069a351 in fork_exit (callout=0xc060eb97 , arg=0x0, frame=0xe532ad38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 13 (Thread 100011)] #0 sched_switch (td=0xc4d35d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5a94c) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5a94c, lock=0xc0a5a868, priority=588, wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:222 #5 0xc06674c1 in g_io_schedule_down (tp=0xc4d35d20) at ../../../geom/geom_io.c:487 #6 0xc0667b88 in g_down_procbody () at ../../../geom/geom_kern.c:118 #7 0xc069a351 in fork_exit (callout=0xc0667b1a , arg=0x0, frame=0xe5323d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 12 (Thread 100010)] #0 sched_switch (td=0xc4d79000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d79000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5a948) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5a948, lock=0xc0a5a8a8, priority=588, wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:222 #5 0xc06677b7 in g_io_schedule_up (tp=0xc4d79000) at ../../../geom/geom_io.c:592 #6 0xc0667a6a in g_up_procbody () at ../../../geom/geom_kern.c:95 #7 0xc069a351 in fork_exit (callout=0xc06679fc , arg=0x0, frame=0xe5320d38) at ../../../kern/kern_fork.c:804 #8 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 11 (Thread 100009)] #0 sched_switch (td=0xc4d79230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d79230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5a940) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5a940, lock=0x0, priority=76, wmesg=0xc098792e "-", timo=25) at ../../../kern/kern_synch.c:222 #5 0xc0667b18 in g_event_procbody () at ../../../geom/geom_kern.c:142 #6 0xc069a351 in fork_exit (callout=0xc0667a6c , arg=0x0, frame=0xe531dd38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 10 (Thread 100008)] #0 fork_trampoline () at ../../../i386/i386/exception.s:261 261 pushl %esp /* trapframe pointer */ Current language: auto; currently asm (kgdb) #0 fork_trampoline () at ../../../i386/i386/exception.s:261 (kgdb) [Switching to thread 9 (Thread 100007)] #0 sched_switch (td=0xc4d33000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); Current language: auto; currently c (kgdb) #0 sched_switch (td=0xc4d33000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4d30220) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4d30220, frame=0xe5317d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 8 (Thread 100006)] #0 sched_switch (td=0xc4d33230, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33230, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc069dc33 in ithread_loop (arg=0xc4d30230) at ../../../kern/kern_intr.c:1189 #3 0xc069a351 in fork_exit (callout=0xc069d937 , arg=0xc4d30230, frame=0xe5314d38) at ../../../kern/kern_fork.c:804 #4 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 7 (Thread 100005)] #0 sched_switch (td=0xc4d33460, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33460, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc0912dd6 in ipi_bitmap_handler (frame={tf_fs = -477102072, tf_es = -1066729432, tf_ds = 40, tf_edi = 0, tf_esi = 15, tf_ebp = -477041472, tf_isp = -477041492, tf_ebx = 15, tf_edx = -1062867520, tf_ecx = 16, tf_eax = 1, tf_trapno = 0, tf_err = 0, tf_eip = -1064242330, tf_cs = 32, tf_eflags = 514, tf_esp = -477041420, tf_ss = -1066548796}) at ../../../i386/i386/mp_machdep.c:1154 #3 0xc090511e in Xipi_intr_bitmap_handler () at apic_vector.s:284 #4 0x00000202 in ?? () (kgdb) [Switching to thread 6 (Thread 100004)] #0 sched_switch (td=0xc4d33690, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33690, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xe390bca8 in ?? () #2 0xc4d33690 in ?? () #3 0x00000010 in ?? () #4 0x00000010 in ?? () #5 0x00000246 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0xc4d33690 in ?? () #9 0x00000001 in ?? () #10 0xe390bcc0 in ?? () #11 0xc090e0c8 in spinlock_enter () at ../../../i386/i386/machdep.c:2420 #12 0xc06dbf38 in sched_idletd (dummy=0x0) at ../../../kern/sched_ule.c:759 #13 0xc069a351 in fork_exit (callout=0xc06dbeed , arg=0x0, frame=0xe390bd38) at ../../../kern/kern_fork.c:804 #14 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 5 (Thread 100003)] #0 sched_switch (td=0xc4d338c0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d338c0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xe3908ca8 in ?? () #2 0xc4d338c0 in ?? () #3 0x00000010 in ?? () #4 0x00000010 in ?? () #5 0x00000246 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0xc4d338c0 in ?? () #9 0x00000002 in ?? () #10 0xe3908cc0 in ?? () #11 0x00000246 in ?? () #12 0xe3908cf4 in ?? () #13 0xc06dbf38 in sched_idletd (dummy=0xc0a65240) at ../../../kern/sched_ule.c:759 (kgdb) [Switching to thread 4 (Thread 100002)] #0 sched_switch (td=0xc4d33bac, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33bac, newtd=) at ../../../kern/sched_ule.c:1944 #1 0x00000046 in ?? () #2 0xc4d33bac in ?? () #3 0xe3905c20 in ?? () #4 0xc0681d50 in statclock (usermode=-992789776) at ../../../kern/kern_clock.c:534 (kgdb) [Switching to thread 3 (Thread 100001)] #0 sched_switch (td=0xc4d33d20, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d33d20, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06ed780 in sleepq_catch_signals (wchan=0xc4d31ae0) at ../../../kern/subr_sleepqueue.c:417 #4 0xc06edf92 in sleepq_wait_sig (wchan=0xc4d31ae0) at ../../../kern/subr_sleepqueue.c:594 #5 0xc06c5307 in _sleep (ident=0xc4d31ae0, lock=0xc4d31b70, priority=348, wmesg=0xc09a6e08 "wait", timo=0) at ../../../kern/kern_synch.c:224 #6 0xc0698666 in kern_wait (td=0xc4d33d20, pid=-1, status=0xe3901c2c, options=) at ../../../kern/kern_exit.c:897 #7 0xc0698700 in wait4 (td=0xc4d33d20, uap=0xe3901cfc) at ../../../kern/kern_exit.c:683 #8 0xc091d0a5 in syscall (frame=0xe3901d38) at ../../../i386/i386/trap.c:1090 #9 0xc0904a90 in Xint0x80_syscall () at ../../../i386/i386/exception.s:255 #10 0x00000033 in ?? () (kgdb) [Switching to thread 2 (Thread 100000)] #0 sched_switch (td=0xc4d35000, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc4d35000, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06eda87 in sleepq_wait (wchan=0xc0a74264) at ../../../kern/subr_sleepqueue.c:580 #4 0xc068249f in _cv_wait (cvp=0xc0a74264, lock=0xc0a74244) at ../../../kern/kern_condvar.c:134 #5 0xc08830ff in audit_worker (arg=0x0) at ../../../security/audit/audit_worker.c:403 #6 0xc069a351 in fork_exit (callout=0xc0883090 , arg=0x0, frame=0xe38fed38) at ../../../kern/kern_fork.c:804 #7 0xc0904aa0 in fork_trampoline () at ../../../i386/i386/exception.s:264 (kgdb) [Switching to thread 1 (Thread 0)] #0 sched_switch (td=0xc0a5acc0, newtd=) at ../../../kern/sched_ule.c:1944 1944 cpuid = PCPU_GET(cpuid); (kgdb) #0 sched_switch (td=0xc0a5acc0, newtd=) at ../../../kern/sched_ule.c:1944 #1 0xc06c4ef6 in mi_switch (flags=) at ../../../kern/kern_synch.c:440 #2 0xc06ed482 in sleepq_switch (wchan=) at ../../../kern/subr_sleepqueue.c:497 #3 0xc06edf4e in sleepq_timedwait (wchan=0xc0a5aa00) at ../../../kern/subr_sleepqueue.c:615 #4 0xc06c52f4 in _sleep (ident=0xc0a5aa00, lock=0x0, priority=68, wmesg=0xc098ee5d "sched", timo=2500) at ../../../kern/kern_synch.c:222 #5 0xc08c64ea in scheduler (dummy=0x0) at ../../../vm/vm_glue.c:733 #6 0xc067f35a in mi_startup () at ../../../kern/init_main.c:251 #7 0xc045c895 in begin () at ../../../i386/i386/locore.s:328 (kgdb) -- Dan Nelson dnelson@allantgroup.com From jroberson at jroberson.net Mon Feb 2 11:44:48 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Mon Feb 2 11:45:00 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090201170550.482bf325@fabiankeil.de> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> Message-ID: <20090202094226.E983@desktop> On Sun, 1 Feb 2009, Fabian Keil wrote: > Fabian Keil wrote: > >> Jeff Roberson wrote: >> >>> http://people.freebsd.org/~jeff/mbuf_ref2.diff >> >>> I have been experimenting with different revisions to the mbuf api to >>> improve performance and simplify code. This patch is the first of >>> several proposed steps towards those goals. The aim of this patch is >>> two fold; >> >>> I would appreciate testing feedback from varied workloads to make sure >>> there are no bugs before I go forward with this. I have tested only >>> host oriented networking with a few drivers. It is not anticipated >>> that there will be any significant incompatibilities introduced with >>> this round but there is always that possibility. > >> 5) >> Finally, I tested the patch on an IBM ThinPad R51. The kernel >> hangs on boot, the last messages are (hand transcribed): >> >> iwi0: mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 >> iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 >> iwi0: could not allocate rx mbuf >> iwi0: could not allocate Rx ring >> bpfdetach: was not attached > > Never mind, kernel and user land weren't completely in > sync and this might be related to the recent wlan commits. > I'll retry with an up-to-date user land. > I have updated the patch here: http://people.freebsd.org/~jeff/mbuf_ref2.diff This resolves the !INVARIANTS bug and improves the style as you suggested. Thanks, Jeff > Fabian > From jroberson at jroberson.net Mon Feb 2 11:46:24 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Mon Feb 2 11:46:35 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <4986A6F7.7080402@elischer.org> References: <20090131125100.N983@desktop> <4986A6F7.7080402@elischer.org> Message-ID: <20090202094307.O983@desktop> On Sun, 1 Feb 2009, Julian Elischer wrote: > Jeff Roberson wrote: >> http://people.freebsd.org/~jeff/mbuf_ref2.diff >> >> Hello, >> >> I have been experimenting with different revisions to the mbuf api to >> improve performance and simplify code. This patch is the first of several >> proposed steps towards those goals. The aim of this patch is two fold; >> >> 1) Revising the reference counting system so that we can eliminate >> reference uma zones and the significant uma_find_refcnt() costs in some >> workloads. This is done by making all mbufs reference counted and using >> the owning mbuf's ref for the ext_ref. In this model we never reference >> data, we only reference other mbufs owning the data. >> >> 2) Improve allocation and free performance by reducing the special cases >> in the format and using inlines when appropriate. In particular, the >> simplification of the m_ext structure yields less code and confusion for >> dealing with external storage on free. The ctor/dtor mbuf routines are no >> longer used. A zone pointer and length was added to struct mbuf to >> simplify free and size calculations. >> >> A number of routines were made much, much simpler by the addition of a >> 16bit size field. Previously we dependend on calculating the size by >> figuring out if it was an ext, pkthdr, or standard mbuf. Ultimately, this >> patch moves us closer to having a size agnostic mbuf which we can use to >> experiment with different allocation sizes or even backending to malloc for >> dynamically sized mbufs. >> >> I would appreciate testing feedback from varied workloads to make sure >> there are no bugs before I go forward with this. I have tested only host >> oriented networking with a few drivers. It is not anticipated that there >> will be any significant incompatibilities introduced with this round but >> there is always that possibility. >> > > > generally I like it. > > We discussed someof this before.. > > > It would be nice if you added more comments than you stripped out > I personally think that some descriptions of what you are doing > would be great in teh comments. Yes, I can do that. I hadn't added as much because things are still a bit in flux. > > ascii art too if needed... > > Also some diagrams in any form you want would be nice.. > all that about 1000 words and a picture is true. I'll have to see about that. Any suggestions similar to visio for unix? I guess graphviz can also do datastructure diagrams but I have not used it for this before. I'll check it out but if you have other suggestions it's welcome. Thanks, Jeff > >> Thanks, >> Jeff >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From julian at elischer.org Mon Feb 2 12:29:49 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Feb 2 12:29:55 2009 Subject: Vimage globals vs structures measurements. In-Reply-To: <4984241B.5010103@elischer.org> References: <498414E5.7020904@elischer.org> <4984241B.5010103@elischer.org> Message-ID: <4987548A.7000609@elischer.org> Julian Elischer wrote: > Julian Elischer wrote: >> >> anyone who has commands and args for their favourite >> thing the'd like me to test... send it in.. >> >> >> so far using ttcp I have seem no measureable difference. >> >> but I have more tests to do of course.. >> >> for example throughput with small packets with ttcp (KB/Sec).... >> >> >> x VIMAGE_GLOBALS >> + NO_VIMAGE_GLOBALS >> +-----------------------------------------------------------------+ >> | + xx | >> | + xxx + | >> | + xxx x ++++ | >> | x + x + + xxxxxxx +++++ | >> |x + ++ xx xxx + ++++xxx x x x +++++ ***xxxxx ++++++++| >> | |_____________A______M______| | >> | |________________AM________________| | >> +-----------------------------------------------------------------+ >> N Min Max Median Avg Stddev >> x 40 48016.01 57361.32 56268.06 54915.582 2554.0133 >> + 40 48999.66 59646.59 56261.58 56086.798 3119.1782 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > as I said before mst of my tests have shown no real change but this one > has the most change I've seen.. it's 160 byte udp packets sent between > two identical machines (both using the same kernel each time). > > > x VIMAGE_GLOBALS > + NO_VIMAGE_GLOBALS > +-----------------------------------------------------------------+ > | + + ++ xx x x | > | + + ++ +x++x +xx x x | > | + + +++ + +*+**x+xxxx x | > | + +++ +++x*++*+**x*x*xx x x x | > | + +*+++++x**+*+**x*x*x*xx x x xx | > | ++++*++++****+*+**x*x****x xxxx xxx | > | + + xx + ++++*++*+****+***********x*xxxxx xxxx x| > |+ +*+++ xx++*+*+*+****+****************x***x*xxx*xx x xx x| > | |__________A__________| | > | |_________A________| | > +-----------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 150 10175.11 11292.11 10763.80 10760.77 200.92124 > + 150 10075.64 11019.12 10591.68 10580.059 172.29227 > Difference at 95.0% confidence > -180.711 +/- 42.3572 > -1.67935% +/- 0.393626% > (Student's t, pooled s = 187.155) > > this one showed a 1.7% slowdown > where the one above showed a half percent speedup > (but not considered significant). > > The first one shown above was TCP with 1500 byte packets on bge 1G > interfaces.. > > more test ideas appreciated... more tests.. this one with iperf... x NO_VIMAGE_GLOBALS + VIMAGE_GLOBALS +-----------------------------------------------------------------+ | + x x x | | + + x x x x | | + + + + x x x x | | + + + + x x x x | | + + + + + x x x x x | | + + + + * x x x x x x | | + + + + * x * x x x x | | + + + + + * * * x x x x | | + + + + + + * * * x x x x | | + + + + + + + * * * x x x x | | + + + + + + + * * * * x x x x x | | + + + + + + * * * * * * x x x x | | + + + + + + * * * * * * x x x x | | + + + + + + * * * * * * * * x * x x | |x + + + + * * * * * * * * * * * * x x x| | |________A_________| | | |________MA_________| | +-----------------------------------------------------------------+ N Min Max Median Avg Stddev x 120 418 441 435 435.025 3.4089908 + 120 423 438 429 429.51667 3.4664862 Difference at 95.0% confidence -5.50833 +/- 0.869898 -1.26621% +/- 0.199965% (Student's t, pooled s = 3.43786) bigger is better... In this case we see that NO_VIMAGE_GLOBALS is better. Over several iterations I have come to the conclusion that other factors are overwhelming this change and that the effect of clustering all the 'global' variables together into a single global structure is negligible. If I can get some confirmation of this by others then the next step would be to simply remove the VIMAGE_GLOBALS option and all the global variables it covers. At least that's what seems next to me.. see: http://wiki.freebsd.org/Image/Notes200808DevSummit > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Mon Feb 2 12:31:32 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Feb 2 12:31:39 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090202094307.O983@desktop> References: <20090131125100.N983@desktop> <4986A6F7.7080402@elischer.org> <20090202094307.O983@desktop> Message-ID: <498755EF.50805@elischer.org> Jeff Roberson wrote: > On Sun, 1 Feb 2009, Julian Elischer wrote: > >> ascii art too if needed... >> >> Also some diagrams in any form you want would be nice.. >> all that about 1000 words and a picture is true. > > I'll have to see about that. Any suggestions similar to visio for unix? > I guess graphviz can also do datastructure diagrams but I have not used > it for this before. I'll check it out but if you have other suggestions > it's welcome. > > Thanks, > Jeff > This is the stuff of religious wars, but for simplicity, I'm partial to TGIF. It's an old X app that is therefore small. It allows you to link objects with line sand then move them around and it compiles and runs on everything on the planet. it can export in lots of formats and I find it pretty intuitive once you've gotten around it's few idiosyncracies. Because it is so small it loads on a modern machine in sub second time. as opposed to some of the bigger apps that take 20 seconds before you even see the window. and "yes, export and print are the same function.. printing is just exporting to the printer" From julian at elischer.org Mon Feb 2 12:47:06 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Feb 2 12:47:13 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090202094307.O983@desktop> References: <20090131125100.N983@desktop> <4986A6F7.7080402@elischer.org> <20090202094307.O983@desktop> Message-ID: <49875BCF.5030305@elischer.org> > > I'll have to see about that. Any suggestions similar to visio for unix? > I guess graphviz can also do datastructure diagrams but I have not used > it for this before. I'll check it out but if you have other suggestions > it's welcome. > BTW I once satisfied this requirement using a screenshot of the output of 'ddd' (the debugger, not the 'dd' replacement) From dlt at mebtel.net Mon Feb 2 14:24:18 2009 From: dlt at mebtel.net (Derek Tattersall) Date: Mon Feb 2 14:24:30 2009 Subject: Multicast source address in recvfrom() In-Reply-To: References: <20090201183057.GA47405@oriental.arm.org> Message-ID: <20090202222414.GA59860@oriental.arm.org> * Robert Watson [090202 17:06]: > On Sun, 1 Feb 2009, Derek Tattersall wrote: > > >In order to become familiar with multicast implementation using FreeBSD, I > >found via Google a pair of test programs which multicast sent a simple > >text message and received the text message. I added some code to report > >the source address, because none of the references that I looked at > >specified the source IP address in the frame. > > > >I ran the sender on A -current system, AMD64 vintage last week. The > >receiver was on a -current system I386 vintage last week. TCPDUMP shows > >the source IP address in the frame as (correctly) 192.168.0.15. The > >receiver reports the source IP address as 200.231.191.191. I have also > >run the same test with an OpenBSD 4.4 Release I386 system as the receiver. > >The openBSD system reports the sender as 192.168.0.15. A Fedora 10 system > >reported the source IP address as 0.0.0.0. > > > >Googling the RFCs and other information and referring to Comer's and > >Stevens' books on TCPIP I can't determine what should be reported. Does > >anybody have clue for me? > > Hi Derek: > > It might depend on how you're querying the source address. Could you post > a code excerpt? > > Robert N M Watson > Computer Laboratory > University of Cambridge It's a straightforward test program. /********************************************************************** * * MulticastReceiver.c: Receive a multicast message * * Copyright (C) 2009 Derek Tattersall. * * See the COPYING file for license information. * * Author: Derek Tattersall * * Latest Revision: Sat Jan 31 07:21:04 2009 * **********************************************************************/ /* Includes***********************************************************/ #include /* for printf() and fprintf() */ #include /* for socket(), connect(), sendto(), and recvfrom() */ #include /* for sockaddr_in and inet_addr() */ #include /* for IPPROTO_UDP */ #include /* for atoi() and exit() */ #include /* for memset() */ #include /* for close() */ /* Defines ***********************************************************/ #define MAXRECVSTRING 255 /* Longest string to receive */ /* Type Definitions **************************************************/ /* Function Declarations *********************************************/ void DieWithError(char *errorMessage); /* External error handling function */ /* Global Variables **************************************************/ /* Function Implementations ******************************************/ int main(int argc, char *argv[]) { int sock; /* Socket */ struct sockaddr_in multicastAddr; /* Multicast Address */ char *multicastIP; /* IP Multicast Address */ unsigned short multicastPort; /* Port */ struct sockaddr_in senderAddr; /* Sender Address */ int senderLen; /* length of sender address socket */ char senderAddrBuf[INET_ADDRSTRLEN]; /* conversion buffer */ char recvString[MAXRECVSTRING+1]; /* Buffer for received string */ int recvStringLen; /* Length of received string */ struct ip_mreq multicastRequest; /* Multicast address join structure */ if (argc != 3) /* Test for correct number of arguments */ { fprintf(stderr,"Usage: %s \n", argv[0]); exit(1); } multicastIP = argv[1]; /* First arg: Multicast IP address (dotted quad) */ multicastPort = atoi(argv[2]);/* Second arg: Multicast port */ /* Create a best-effort datagram socket using UDP */ if ((sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) DieWithError("socket() failed"); /* Construct bind structure */ memset(&multicastAddr, 0, sizeof(multicastAddr)); /* Zero out structure */ multicastAddr.sin_family = AF_INET; /* Internet address family */ multicastAddr.sin_addr.s_addr = htonl(INADDR_ANY); /* Any incoming interface */ multicastAddr.sin_port = htons(multicastPort); /* Multicast port */ /* Bind to the multicast port */ if (bind(sock, (struct sockaddr *) &multicastAddr, sizeof(multicastAddr)) < 0) DieWithError("bind() failed"); /* Specify the multicast group */ multicastRequest.imr_multiaddr.s_addr = inet_addr(multicastIP); /* Accept multicast from any interface */ multicastRequest.imr_interface.s_addr = htonl(INADDR_ANY); /* Join the multicast address */ if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (void *) &multicastRequest, sizeof(multicastRequest)) < 0) DieWithError("setsockopt() failed"); /* Receive a single datagram from the server */ if ((recvStringLen = recvfrom(sock, recvString, MAXRECVSTRING, 0, (struct sockaddr *)&senderAddr, (socklen_t *)&senderLen)) < 0) DieWithError("recvfrom() failed"); if ((inet_ntop(AF_INET, &senderAddr.sin_addr.s_addr, senderAddrBuf, INET_ADDRSTRLEN)) == 0) senderAddrBuf[0] = '\0'; recvString[recvStringLen] = '\0'; printf("Received from %s: %s\n", senderAddrBuf, recvString); /* Print the received string */ close(sock); exit(0); } /* vim: set sts=0 sw=8 ts=8: *****************************************/ Note that the sender's address is taken from the recvfrom call per the man page and printed via inet_ntop call. The DieWithError routine is a simple print error message and exit with a 1. I have used similar code with UDP recieving apps before. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From linimon at lonesome.com Mon Feb 2 15:10:14 2009 From: linimon at lonesome.com (Mark Linimon) Date: Mon Feb 2 15:10:20 2009 Subject: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) Message-ID: <200902022310.n12NA9EY042848@freefall.freebsd.org> The following reply was made to PR kern/87758; it has been noted by GNATS. From: linimon@lonesome.com (Mark Linimon) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) Date: Mon, 2 Feb 2009 17:08:29 -0600 ----- Forwarded message from Paulo Fragoso ----- From: Paulo Fragoso To: vwe@FreeBSD.org Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) We didn't find this problem since 6.2-RELEASE. Paulo. ----- End forwarded message ----- From linimon at FreeBSD.org Mon Feb 2 15:25:57 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Feb 2 15:26:03 2009 Subject: kern/131310: [panic] 7.1 panics with mpd netgraph interface changes Message-ID: <200902022325.n12NPusm057934@freefall.freebsd.org> Old Synopsis: 7.1 panics with mpd netgraph interface changes New Synopsis: [panic] 7.1 panics with mpd netgraph interface changes Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 2 23:24:30 UTC 2009 Responsible-Changed-Why: Looks like this might be network-related, but I'm not sure. http://www.freebsd.org/cgi/query-pr.cgi?pr=131310 From linimon at FreeBSD.org Mon Feb 2 15:47:34 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Feb 2 15:47:41 2009 Subject: kern/87758: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) Message-ID: <200902022347.n12NlXeL074689@freefall.freebsd.org> Synopsis: [ath] [hang] Reboot problem with atheros wireless card (DWL-G520) State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Mon Feb 2 23:47:19 UTC 2009 State-Changed-Why: Submitter notes this problem is resolved. http://www.freebsd.org/cgi/query-pr.cgi?pr=87758 From perryh at pluto.rain.com Tue Feb 3 00:40:58 2009 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Tue Feb 3 00:41:09 2009 Subject: Visio (Re: mbuf revision, testers/comments wanted.) In-Reply-To: <20090202094307.O983@desktop> References: <20090131125100.N983@desktop> <4986A6F7.7080402@elischer.org> <20090202094307.O983@desktop> Message-ID: <49880322.0MwiaosrHBVUXyHQ%perryh@pluto.rain.com> > Any suggestions similar to visio for unix? graphics/dia is the closest approximation I know of. It might work to run Visio itself under wine. From rwatson at FreeBSD.org Tue Feb 3 02:13:55 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Feb 3 02:14:01 2009 Subject: Multicast source address in recvfrom() In-Reply-To: <20090202222414.GA59860@oriental.arm.org> References: <20090201183057.GA47405@oriental.arm.org> <20090202222414.GA59860@oriental.arm.org> Message-ID: > * Robert Watson [090202 17:06]: >> On Sun, 1 Feb 2009, Derek Tattersall wrote: >> >>> In order to become familiar with multicast implementation using FreeBSD, I >>> found via Google a pair of test programs which multicast sent a simple >>> text message and received the text message. I added some code to report >>> the source address, because none of the references that I looked at >>> specified the source IP address in the frame. >>> >>> I ran the sender on A -current system, AMD64 vintage last week. The >>> receiver was on a -current system I386 vintage last week. TCPDUMP shows >>> the source IP address in the frame as (correctly) 192.168.0.15. The >>> receiver reports the source IP address as 200.231.191.191. I have also >>> run the same test with an OpenBSD 4.4 Release I386 system as the receiver. >>> The openBSD system reports the sender as 192.168.0.15. A Fedora 10 system >>> reported the source IP address as 0.0.0.0. >>> >>> Googling the RFCs and other information and referring to Comer's and >>> Stevens' books on TCPIP I can't determine what should be reported. Does >>> anybody have clue for me? >> >> It might depend on how you're querying the source address. Could you post >> a code excerpt? > > It's a straightforward test program. Your assumption, that the address returned from recvfrom(2) should be correct, seems generally right to me. However, it looks like you may not be initializing senderLen to the size of senderAddr, which means that the size getting passed in may be random stack garbage. In which case what you find in the sockaddr_in might also be random stack garbage, or might be the address, depending on whether the uninitialized length was long enough to fit an IP address in. Could you try adding something like: senderLen = sizeof(senderAddr); before the call to recvfrom(2)? Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > /********************************************************************** > * > * MulticastReceiver.c: Receive a multicast message > * > * Copyright (C) 2009 Derek Tattersall. > * > * See the COPYING file for license information. > * > * Author: Derek Tattersall > * > * Latest Revision: Sat Jan 31 07:21:04 2009 > * > **********************************************************************/ > > /* Includes***********************************************************/ > #include /* for printf() and fprintf() */ > #include /* for socket(), connect(), sendto(), and recvfrom() */ > #include /* for sockaddr_in and inet_addr() */ > #include /* for IPPROTO_UDP */ > #include /* for atoi() and exit() */ > #include /* for memset() */ > #include /* for close() */ > > > /* Defines ***********************************************************/ > #define MAXRECVSTRING 255 /* Longest string to receive */ > > /* Type Definitions **************************************************/ > > /* Function Declarations *********************************************/ > void DieWithError(char *errorMessage); /* External error handling function */ > > /* Global Variables **************************************************/ > > /* Function Implementations ******************************************/ > int main(int argc, char *argv[]) > { > int sock; /* Socket */ > struct sockaddr_in multicastAddr; /* Multicast Address */ > char *multicastIP; /* IP Multicast Address */ > unsigned short multicastPort; /* Port */ > struct sockaddr_in senderAddr; /* Sender Address */ > int senderLen; /* length of sender address socket */ > char senderAddrBuf[INET_ADDRSTRLEN]; /* conversion buffer */ > char recvString[MAXRECVSTRING+1]; /* Buffer for received string */ > int recvStringLen; /* Length of received string */ > struct ip_mreq multicastRequest; /* Multicast address join structure */ > > if (argc != 3) /* Test for correct number of arguments */ > { > fprintf(stderr,"Usage: %s \n", argv[0]); > exit(1); > } > > multicastIP = argv[1]; /* First arg: Multicast IP address (dotted quad) */ > multicastPort = atoi(argv[2]);/* Second arg: Multicast port */ > > /* Create a best-effort datagram socket using UDP */ > if ((sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) > DieWithError("socket() failed"); > > /* Construct bind structure */ > memset(&multicastAddr, 0, sizeof(multicastAddr)); /* Zero out structure */ > multicastAddr.sin_family = AF_INET; /* Internet address family */ > multicastAddr.sin_addr.s_addr = htonl(INADDR_ANY); /* Any incoming interface */ > multicastAddr.sin_port = htons(multicastPort); /* Multicast port */ > > /* Bind to the multicast port */ > if (bind(sock, (struct sockaddr *) &multicastAddr, sizeof(multicastAddr)) < 0) > DieWithError("bind() failed"); > > /* Specify the multicast group */ > multicastRequest.imr_multiaddr.s_addr = inet_addr(multicastIP); > /* Accept multicast from any interface */ > multicastRequest.imr_interface.s_addr = htonl(INADDR_ANY); > /* Join the multicast address */ > if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (void *) &multicastRequest, > sizeof(multicastRequest)) < 0) > DieWithError("setsockopt() failed"); > > /* Receive a single datagram from the server */ > if ((recvStringLen = recvfrom(sock, recvString, MAXRECVSTRING, 0, (struct sockaddr *)&senderAddr, (socklen_t *)&senderLen)) < 0) > DieWithError("recvfrom() failed"); > > if ((inet_ntop(AF_INET, &senderAddr.sin_addr.s_addr, senderAddrBuf, INET_ADDRSTRLEN)) == 0) > senderAddrBuf[0] = '\0'; > recvString[recvStringLen] = '\0'; > printf("Received from %s: %s\n", senderAddrBuf, recvString); /* Print the received string */ > > close(sock); > exit(0); > } > > /* vim: set sts=0 sw=8 ts=8: *****************************************/ > Note that the sender's address is taken from the recvfrom call per the > man page and printed via inet_ntop call. The DieWithError routine is a > simple print error message and exit with a 1. I have used similar code > with UDP recieving apps before. > -- > Best regards, > Derek Tattersall > dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com > From dreamer.two at gmail.com Tue Feb 3 02:30:05 2009 From: dreamer.two at gmail.com (Vitaly Dodonov) Date: Tue Feb 3 02:30:12 2009 Subject: kern/131310: [panic] 7.1 panics with mpd netgraph interface changes Message-ID: <200902031030.n13AU4Lx008357@freefall.freebsd.org> The following reply was made to PR kern/131310; it has been noted by GNATS. From: Vitaly Dodonov To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131310: [panic] 7.1 panics with mpd netgraph interface changes Date: Tue, 3 Feb 2009 13:00:12 +0300 --000e0cd2301abeffad046200bc47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit tried switch to GENERIC, problem still exists without altq and other options FreeBSD d2s.local 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Tue Feb 3 09:13:03 MSK 2009 d2@d2s.local:/usr/obj/usr/src/sys/GENERIC amd64 /<4>sys/GENERIC# kgdb kernel.debug /var/crash/vmcore.5 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x8:0xffffffffdbebbb06 stack pointer = 0x10:0xffffffffdbff58a0 frame pointer = 0x10:0xffffffffdbff58f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1746 (mpd5) trap number = 9 panic: general protection fault cpuid = 1 Uptime: 3h9m14s Physical memory: 4078 MB Dumping 1267 MB: 1252 1236 1220 1204 1188 1172 1156 1140 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964 948 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676 660 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_pppoe.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_lagg.ko Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/kernel/if_vlan.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_vlan.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from /boot/kernel/ng_mppc.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_mppc.ko Reading symbols from /boot/kernel/rc4.ko...Reading symbols from /boot/kernel/rc4.ko.symbols...done. done. Loaded symbols for /boot/kernel/rc4.ko Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_iface.ko Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/ng_ppp.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ppp.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/kernel/ng_tee.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tee.ko Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from /boot/kernel/ng_tcpmss.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tcpmss.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff804b4ce9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff804b50f2 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff8078a173 in trap_fatal (frame=0xffffff00077ae000, eva=Variable "eva" is not available.) at /usr/src/sys/amd64/amd64/trap.c:764 #5 0xffffffff8078acc5 in trap (frame=0xffffffffdbff57f0) at /usr/src/sys/amd64/amd64/trap.c:565 #6 0xffffffff8077067e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0xffffffffdbebbb06 in pfi_instance_add (ifp=0xffffff000737b800, net=128, flags=0) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:578 #8 0xffffffffdbebbdd6 in pfi_table_update (kt=0xffffff000772e510, kif=Variable "kif" is not available.) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:561 #9 0xffffffffdbebc06b in pfi_dynaddr_update (dyn=0xffffff0007764d20) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:543 #10 0xffffffffdbebc0be in pfi_kif_update (kif=0xffffff000739d500) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:520 #11 0xffffffffdbebc0ec in pfi_kif_update (kif=0xffffff0007733000) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:525 #12 0xffffffffdbebc15c in pfi_ifaddr_event (arg=Variable "arg" is not available.) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:942 #13 0xffffffff8058b54c in in_control (so=Variable "so" is not available.) at /usr/src/sys/netinet/in.c:476 #14 0xffffffff8054ea6f in ifioctl (so=0xffffff002007a5a0, cmd=2149607705, data=0xffffff0005ef3ac0 "ng2", td=0xffffff00077ae000) at /usr/src/sys/net/if.c:1952 #15 0xffffffff804ed9f4 in kern_ioctl (td=0xffffff00077ae000, fd=26, com=2149607705, data=0xffffff0005ef3ac0 "ng2") at file.h:268 #16 0xffffffff804edcfa in ioctl (td=0xffffff00077ae000, uap=0xffffffffdbff5bf0) at /usr/src/sys/kern/sys_generic.c:570 #17 0xffffffff8078a7c7 in syscall (frame=0xffffffffdbff5c80) at /usr/src/sys/amd64/amd64/trap.c:907 #18 0xffffffff8077088b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #19 0x000000080188137c in ?? () Previous frame inner to this frame (corrupt stack?) --000e0cd2301abeffad046200bc47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
tried switch to GENERIC, problem still exists without altq and other o= ptions
 
FreeBSD d2s.local 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Tue Feb&nb= sp; 3 09:13:03 MSK 2009     d2@d2s.local:/usr/obj/usr/src/sys/GENERIC=   amd64
 
/<4>sys/GENERIC# kgdb kernel.debug /var/crash/vmcore.5
GNU gd= b 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB i= s free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condition= s.
Type "show copying" to see the conditions.
There is abso= lutely no warranty for GDB.  Type "show warranty" for detail= s.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:

Fatal trap 9: general protection fault while in kernel mode
cpu= id =3D 1; apic id =3D 01
instruction pointer     =3D= 0x8:0xffffffffdbebbb06
stack pointer      = ;     =3D 0x10:0xffffffffdbff58a0
frame pointer = ;          =3D 0x10:0xffffffff= dbff58f0
code segment          &nb= sp; =3D base 0x0, limit 0xfffff, type 0x1b
     = ;            &n= bsp;      =3D DPL 0, pres 1, long 1, def32 0, gran= 1
processor eflags        =3D interr= upt enabled, resume, IOPL =3D 0
current process    &= nbsp;    =3D 1746 (mpd5)
trap number          &nbs= p;  =3D 9
panic: general protection fault
cpuid =3D 1
Uptime:= 3h9m14s
Physical memory: 4078 MB
Dumping 1267 MB: 1252 1236 1220 120= 4 1188 1172 1156 1140 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964 9= 48 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676 660 = 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356= 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 3= 6 20 4
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/= kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/z= fs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols= from /boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols = from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.= ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_pppoe.ko<= br> Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/= kernel/netgraph.ko.symbols...done.
done.
Loaded symbols for /boot/ker= nel/netgraph.ko
Reading symbols from /boot/kernel/geom_journal.ko...Read= ing symbols from /boot/kernel/geom_journal.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_journal.ko
Reading symbols= from /boot/kernel/if_lagg.ko...Reading symbols from /boot/kernel/if_lagg.k= o.symbols...done.
done.
Loaded symbols for /boot/kernel/if_lagg.ko Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/k= ernel/if_vlan.ko.symbols...done.
done.
Loaded symbols for /boot/kerne= l/if_vlan.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols f= rom /boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boo= t/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symb= ols...done.
done.
Loaded symbols for /boot/kernel/ng_socket.ko
Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from /boot/k= ernel/ng_mppc.ko.symbols...done.
done.
Loaded symbols for /boot/kerne= l/ng_mppc.ko
Reading symbols from /boot/kernel/rc4.ko...Reading symbols = from /boot/kernel/rc4.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/rc4.ko
Reading symbols from /bo= ot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbo= ls...done.
done.
Loaded symbols for /boot/kernel/ng_iface.ko
Readi= ng symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/= ng_ppp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ppp.ko
Reading symbols from = /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.sy= mbols...done.
done.
Loaded symbols for /boot/kernel/ng_ether.ko
Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from /boot/ke= rnel/ng_tee.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/= ng_tee.ko
Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbo= ls from /boot/kernel/ng_tcpmss.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_tcpmss.ko
#0  doadump (= ) at pcpu.h:195
195         = ;    __asm __volatile("movq %%gs:0,%0" : "=3D= r" (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0x0000000000000004 in ?? ()
#2  0xffffffff804b4ce9 in boot= (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:418
#3  0xfffff= fff804b50f2 in panic (fmt=3D0x104 <Address 0x104 out of bounds>) at /= usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff8078a173 in trap_fatal (frame=3D0xffffff00077ae000, eva= =3DVariable "eva" is not available.) at /usr/src/sys/amd64/amd64/= trap.c:764
#5  0xffffffff8078acc5 in trap (frame=3D0xffffffffdbff57= f0) at /usr/src/sys/amd64/amd64/trap.c:565
#6  0xffffffff8077067e in calltrap () at /usr/src/sys/amd64/amd64/exce= ption.S:209
#7  0xffffffffdbebbb06 in pfi_instance_add (ifp=3D0xfff= fff000737b800, net=3D128, flags=3D0) at /usr/src/sys/modules/pf/../../contr= ib/pf/net/pf_if.c:578
#8  0xffffffffdbebbdd6 in pfi_table_update (kt=3D0xffffff000772e510, k= if=3DVariable "kif" is not available.) at /usr/src/sys/modules/pf= /../../contrib/pf/net/pf_if.c:561
#9  0xffffffffdbebc06b in pfi_dyn= addr_update (dyn=3D0xffffff0007764d20) at /usr/src/sys/modules/pf/../../con= trib/pf/net/pf_if.c:543
#10 0xffffffffdbebc0be in pfi_kif_update (kif=3D0xffffff000739d500) at /usr= /src/sys/modules/pf/../../contrib/pf/net/pf_if.c:520
#11 0xffffffffdbebc= 0ec in pfi_kif_update (kif=3D0xffffff0007733000) at /usr/src/sys/modules/pf= /../../contrib/pf/net/pf_if.c:525
#12 0xffffffffdbebc15c in pfi_ifaddr_event (arg=3DVariable "arg" = is not available.) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:= 942
#13 0xffffffff8058b54c in in_control (so=3DVariable "so" i= s not available.) at /usr/src/sys/netinet/in.c:476
#14 0xffffffff8054ea6f in ifioctl (so=3D0xffffff002007a5a0, cmd=3D214960770= 5, data=3D0xffffff0005ef3ac0 "ng2", td=3D0xffffff00077ae000) at /= usr/src/sys/net/if.c:1952
#15 0xffffffff804ed9f4 in kern_ioctl (td=3D0xf= fffff00077ae000, fd=3D26, com=3D2149607705, data=3D0xffffff0005ef3ac0 "= ;ng2") at file.h:268
#16 0xffffffff804edcfa in ioctl (td=3D0xffffff00077ae000, uap=3D0xffffffffd= bff5bf0) at /usr/src/sys/kern/sys_generic.c:570
#17 0xffffffff8078a7c7 i= n syscall (frame=3D0xffffffffdbff5c80) at /usr/src/sys/amd64/amd64/trap.c:9= 07
#18 0xffffffff8077088b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:330
#19 0x000000080188137c in ?? ()
Previous frame inner to t= his frame (corrupt stack?)
--000e0cd2301abeffad046200bc47-- From adamk at voicenet.com Tue Feb 3 04:20:03 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Tue Feb 3 04:20:09 2009 Subject: kern/131153: [iwi] iwi doesn't see a wireless network Message-ID: <200902031220.n13CK2Kh096456@freefall.freebsd.org> The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@FreeBSD.org, adamk@voicenet.com Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Tue, 3 Feb 2009 07:13:43 -0500 Is there anything further I can do to help identify this problem? Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dlt at mebtel.net Tue Feb 3 04:27:41 2009 From: dlt at mebtel.net (Derek Tattersall) Date: Tue Feb 3 04:27:47 2009 Subject: Multicast source address in recvfrom() In-Reply-To: References: <20090201183057.GA47405@oriental.arm.org> <20090202222414.GA59860@oriental.arm.org> Message-ID: <20090203122737.GA62874@oriental.arm.org> * Robert Watson [090203 06:17]: > > >* Robert Watson [090202 17:06]: > >>On Sun, 1 Feb 2009, Derek Tattersall wrote: > >> > >>>In order to become familiar with multicast implementation using FreeBSD, > >>>I found via Google a pair of test programs which multicast sent a simple > >>>text message and received the text message. I added some code to report > >>>the source address, because none of the references that I looked at > >>>specified the source IP address in the frame. > >>> > >>>I ran the sender on A -current system, AMD64 vintage last week. The > >>>receiver was on a -current system I386 vintage last week. TCPDUMP shows > >>>the source IP address in the frame as (correctly) 192.168.0.15. The > >>>receiver reports the source IP address as 200.231.191.191. I have also > >>>run the same test with an OpenBSD 4.4 Release I386 system as the > >>>receiver. The openBSD system reports the sender as 192.168.0.15. A > >>>Fedora 10 system reported the source IP address as 0.0.0.0. > >>> > >>>Googling the RFCs and other information and referring to Comer's and > >>>Stevens' books on TCPIP I can't determine what should be reported. Does > >>>anybody have clue for me? > >> > >>It might depend on how you're querying the source address. Could you > >>post a code excerpt? > > > >It's a straightforward test program. > > Your assumption, that the address returned from recvfrom(2) should be > correct, seems generally right to me. However, it looks like you may not > be initializing senderLen to the size of senderAddr, which means that the > size getting passed in may be random stack garbage. In which case what you > find in the sockaddr_in might also be random stack garbage, or might be the > address, depending on whether the uninitialized length was long enough to > fit an IP address in. Could you try adding something like: > > senderLen = sizeof(senderAddr); > > before the call to recvfrom(2)? > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > -------------------------------- Snip test program --------------- You nailed it! Initializing the length of the sockaddr stucture was the answer. Thanks very much for pointing out the flaw. -- Best regards, Derek Tattersall dlt@mebtel.net dlt666@yahoo.com dtatters@gmail.com From jchambers at ucla.edu Tue Feb 3 17:59:53 2009 From: jchambers at ucla.edu (Jason Chambers) Date: Tue Feb 3 18:00:01 2009 Subject: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools In-Reply-To: <200902021344.n12DieCX021758@freefall.freebsd.org> References: <200902021344.n12DieCX021758@freefall.freebsd.org> Message-ID: <4988F687.4050105@ucla.edu> rwatson@FreeBSD.org wrote: > Thanks for your detailed bug report. It seems like a few things are going > on here, and probably need to be diagnosed individaully. First, the error > reported by Nessus, "BIOCSRTIEOUT: Invalid argument" can, I believe, only > be triggered in the following kernel code: (...) > > This suggests that Nessus is passing an unexpectedly high or low number > of usec's, and is therefore probably an application bug. Thanks for pointing this out. Although unrelated to the issue at hand it possibly impacts nessus results and will help push their support team in the right direction. I see this error on a FreeBSD system that successfully runs scans. > > In general, "Network is unreachable" (ENETUNREACH) is generated by protocol > sockets when the destination host is on a non-local network and the gateway > specified in the route to the host is unreachable -- for example, ARP can't > find the gateway, the device link is down, etc. > > Is there any indication in the system logs of the link state going up and > down? You can use "route -n monitor" to track some of the relevant events. > Given that you've tried multiple cards, I can't help but wondering if > there is a cabling, switch, or router problem, so if you haven't already, > I'd follow those possible lines of diagnosis as well. There's no indication of interface flapping in the logs and I checked that the underlying infrastructure is fine. Route -n monitor shows nothing before and during the NMap or Nessus scanning. I suspect it's hardware related because not all FreeBSD (7.1-p2) systems I'm using have the problem. The commonality in all of it is newer Dell rack server systems ( 8-core PowerEdge 1950 and SC1435's). This "Network is unreachable" error seems to always occur with NMAP's OS discovery phase. ex: nmap -sS -p 22 -O host However, only on the SC1435's does Nessus fail to run successfully. When I say run, I mean the nessus process successfully sends out probe traffic (verified at the remote destination) but ignores the replies. Tcpdump shows that they arrive fine. The only thing different about these SC1435's from other systems is a patch I've applied to have the ServerWorks HT1000 controller work. (ata_ht1000.patch) http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-10/msg00039.html I converted two of the servers to Linux and everything works fine with them. Rather than bury the problem I'd like to understand what fails. I can give access to one or both of these machines if it would help the effort. Otherwise, any suggestions on what tests I should run to further isolate this problem to a specific subsystem ? --Jason From jchambers at ucla.edu Tue Feb 3 18:00:14 2009 From: jchambers at ucla.edu (Jason Chambers) Date: Tue Feb 3 18:00:26 2009 Subject: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Message-ID: <200902040200.n14203lg015373@freefall.freebsd.org> The following reply was made to PR kern/130605; it has been noted by GNATS. From: Jason Chambers To: rwatson@FreeBSD.org, freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org Cc: Subject: Re: kern/130605: [tcp] Certain hardware produces "Network is unreachable" errors for scanning tools Date: Tue, 03 Feb 2009 17:59:35 -0800 rwatson@FreeBSD.org wrote: > Thanks for your detailed bug report. It seems like a few things are going > on here, and probably need to be diagnosed individaully. First, the error > reported by Nessus, "BIOCSRTIEOUT: Invalid argument" can, I believe, only > be triggered in the following kernel code: (...) > > This suggests that Nessus is passing an unexpectedly high or low number > of usec's, and is therefore probably an application bug. Thanks for pointing this out. Although unrelated to the issue at hand it possibly impacts nessus results and will help push their support team in the right direction. I see this error on a FreeBSD system that successfully runs scans. > > In general, "Network is unreachable" (ENETUNREACH) is generated by protocol > sockets when the destination host is on a non-local network and the gateway > specified in the route to the host is unreachable -- for example, ARP can't > find the gateway, the device link is down, etc. > > Is there any indication in the system logs of the link state going up and > down? You can use "route -n monitor" to track some of the relevant events. > Given that you've tried multiple cards, I can't help but wondering if > there is a cabling, switch, or router problem, so if you haven't already, > I'd follow those possible lines of diagnosis as well. There's no indication of interface flapping in the logs and I checked that the underlying infrastructure is fine. Route -n monitor shows nothing before and during the NMap or Nessus scanning. I suspect it's hardware related because not all FreeBSD (7.1-p2) systems I'm using have the problem. The commonality in all of it is newer Dell rack server systems ( 8-core PowerEdge 1950 and SC1435's). This "Network is unreachable" error seems to always occur with NMAP's OS discovery phase. ex: nmap -sS -p 22 -O host However, only on the SC1435's does Nessus fail to run successfully. When I say run, I mean the nessus process successfully sends out probe traffic (verified at the remote destination) but ignores the replies. Tcpdump shows that they arrive fine. The only thing different about these SC1435's from other systems is a patch I've applied to have the ServerWorks HT1000 controller work. (ata_ht1000.patch) http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-10/msg00039.html I converted two of the servers to Linux and everything works fine with them. Rather than bury the problem I'd like to understand what fails. I can give access to one or both of these machines if it would help the effort. Otherwise, any suggestions on what tests I should run to further isolate this problem to a specific subsystem ? --Jason From mmitar at gmail.com Wed Feb 4 06:35:28 2009 From: mmitar at gmail.com (Mitar) Date: Wed Feb 4 06:35:37 2009 Subject: read() returns ETIMEDOUT In-Reply-To: References: Message-ID: Hi! > sysctl net.inet.tcp | grep keep net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.keepinit: 75000 net.inet.tcp.always_keepalive: 1 I am using FreeBSD 7.0-STABLE on amd64 architecture and bge network interface. Server has around 5 MB/s (megabytes) almost constant rx/tx rate. I use pf firewall and there are a lot of connections opened, for example, some pf states stats: State Table Total Rate current entries 17042 searches 6752096417 14750.6/s inserts 66200602 144.6/s removals 66183560 144.6/s I have been sending a TCP/IP data with netcat listening on the server side and netcat sending from the client. It was not so fast connection (around 50 kB/s (kilobytes) connection on average) but it was a stable steady sending. Server has much more bandwidth available. The connection has lasted only around 12 minutes and only 30 MB of data has been transferred until the time the server closed the connection. The problem is that this is repeatable (I have repeated this test many times) and under such load it happens always. If I disable/cancel all other load on the server the connection is not broken by the server. > (3) TCP retransmit timer reaches its full exponntial backoff without being > ACK'd. (tcp_timer_rexmt) I believe it is because of this. I could not insert kernel printf as I am unable to reboot the server at the moment but I have been checking drop counters with netstat and at the moment the connection broke "connections dropped by rexmit timeout" counter increased. It is true that the counters are increasing almost all the time under the load but I believe that I have timed this correctly. > It would also be useful, if possible, to look at the tcpdump for the last > portion of the connection, perhaps ideally from the second-to-last ACK from > the remote host to the connection reset from the local end. It might be > worth running tcpdump on both sides to see if they see the same thing -- for > example, does one side think it's sending ACKs and the other not receive it? I have put complete logs on the net: http://mitar.tnode.com/Temp/timeout-tcpdump-client.txt.gz http://mitar.tnode.com/Temp/timeout-tcpdump-server.txt.gz Client is NATed behind a router on a different ISP. > In the previous thread, it looked a bit like the outcome was that there was > a memory exhaustion issue under load, and that bumping nmbclusters helped at > least defer that problem. So it would be useful to see the output of > netstat -m before and after (for as small an epsilon as you can make it) the > connection is timed out. I realize capturing the above sorts of data can be > an issue on high-load boxes but if we can, it would be quite helpful. > Regardless of that, knowing if you're seeing allocation errors in the > netstat -m output would be helpful. I doubt that it is a memory issue as I have been monitoring those allocations and they do not come near max values. current netstat -m output is: 10657/8228/18885 mbufs in use (current/cache/total) 8248/7388/15636/25600 mbuf clusters in use (current/cache/total/max) 8248/5994 mbuf+clusters out of packet secondary zone in use (current/cache) 1839/774/2613/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 26857K/19929K/46786K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 27072 requests for I/O initiated by sendfile 0 calls to protocol drain routines Mitar From bzeeb-lists at lists.zabbadoz.net Wed Feb 4 10:50:10 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Feb 4 10:50:22 2009 Subject: Vimage globals vs structures measurements. In-Reply-To: <4987548A.7000609@elischer.org> References: <498414E5.7020904@elischer.org> <4984241B.5010103@elischer.org> <4987548A.7000609@elischer.org> Message-ID: <20090204184526.I93725@maildrop.int.zabbadoz.net> On Mon, 2 Feb 2009, Julian Elischer wrote: Hi, > If I can get some confirmation of this by others then > the next step would be to simply remove the VIMAGE_GLOBALS option > and all the global variables it covers. > > At least that's what seems next to me.. no, the next step is to bring in the beaf (last step). I think we had clearly decided (somewhen, somewho) that we want one version with all three options at the same time. Once we are confident, hopefully after a few days at that point, VIMAGE_GLOBALS will go away. So please do not rape that out. In two months there were no real accidents wrt. VIMAGE_GLOBALS even with all the larger changes that went in. I think it's safe to keep them another 4-6 weeks. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bz at FreeBSD.org Wed Feb 4 11:15:09 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Wed Feb 4 11:15:15 2009 Subject: Vimage globals vs structures measurements. In-Reply-To: <20090204184526.I93725@maildrop.int.zabbadoz.net> References: <498414E5.7020904@elischer.org> <4984241B.5010103@elischer.org> <4987548A.7000609@elischer.org> <20090204184526.I93725@maildrop.int.zabbadoz.net> Message-ID: <20090204185656.B93725@maildrop.int.zabbadoz.net> On Wed, 4 Feb 2009, Bjoern A. Zeeb wrote: > On Mon, 2 Feb 2009, Julian Elischer wrote: > > Hi, > >> If I can get some confirmation of this by others then >> the next step would be to simply remove the VIMAGE_GLOBALS option >> and all the global variables it covers. >> >> At least that's what seems next to me.. > > no, the next step is to bring in the beaf (last step). ... beef ... anyway. The indirection, the real virtualization, the multiple images, ... you count my typos;) > I think we had clearly decided (somewhen, somewho) that we want one > version with all three options at the same time. > Once we are confident, hopefully after a few days at that point, > VIMAGE_GLOBALS will go away. > > So please do not rape that out. In two months there were no real > accidents wrt. VIMAGE_GLOBALS even with all the larger changes that > went in. I think it's safe to keep them another 4-6 weeks. > > /bz > > -- Bjoern A. Zeeb The greatest risk is not taking one. From feh at fehcom.de Thu Feb 5 09:31:28 2009 From: feh at fehcom.de (Erwin Hoffmann) Date: Thu Feb 5 09:32:01 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' Message-ID: Hi, I just saw Paul Mahol's comment: >Yet another invalid bug report. >OP should use -Dndis and not -Dbsd > >-- >Paul Well. If things would be sooo easy. Trying to declare "-D ndis" in the wpa_supplicant call as additional argument yields: artemis# pwd /etc/rc.d artemis# ./wpa_supplicant start ndis0 Starting wpa_supplicant. Unsupported driver 'ndis'. This is my kernel setup: artemis# kldstat -v | grep wlan 300 wlan_ccmp 301 wlan_tkip 302 wlan_wep 303 wlan artemis# kldstat -v | grep ndis 5 3 0xc0c73000 17734 ndis.ko 3 ndisapi 6 2 0xc0c8b000 caa4 if_ndis.ko 4 cardbus/ndis 5 pci/ndis 6 pccard/ndis 7 uhub/ndis What am I missing ? regards. --eh. --- Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ From onemda at gmail.com Thu Feb 5 09:56:10 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Feb 5 09:56:16 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' In-Reply-To: References: Message-ID: <3a142e750902050956ldf9a9c4q1ce33f60f36bead2@mail.gmail.com> On 2/5/09, Erwin Hoffmann wrote: > Hi, > > I just saw Paul Mahol's comment: > >>Yet another invalid bug report. >>OP should use -Dndis and not -Dbsd >> >>-- >>Paul > > Well. If things would be sooo easy. > Trying to declare "-D ndis" in the wpa_supplicant call as additional > argument yields: > > artemis# pwd > /etc/rc.d > artemis# ./wpa_supplicant start ndis0 > Starting wpa_supplicant. > Unsupported driver 'ndis'. > > This is my kernel setup: > > artemis# kldstat -v | grep wlan > 300 wlan_ccmp > 301 wlan_tkip > 302 wlan_wep > 303 wlan > > artemis# kldstat -v | grep ndis > 5 3 0xc0c73000 17734 ndis.ko > 3 ndisapi > 6 2 0xc0c8b000 caa4 if_ndis.ko > 4 cardbus/ndis > 5 pci/ndis > 6 pccard/ndis > 7 uhub/ndis > > What am I missing ? > > regards. > --eh. > > > > --- > Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > wpa_supplicant works fine on 8.0 with ndisX vaps. (and on 7 branch it should work too) Your is not configured with support for ndis. Please read carefully wpa_supplicant configuration options. -- Paul From feh at fehcom.de Thu Feb 5 11:33:19 2009 From: feh at fehcom.de (Erwin Hoffmann) Date: Thu Feb 5 11:33:26 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' In-Reply-To: <3a142e750902050956ldf9a9c4q1ce33f60f36bead2@mail.gmail.com> References: <3a142e750902050956ldf9a9c4q1ce33f60f36bead2@mail.gmail.com> Message-ID: Hi Paul, --On 5. Februar 2009 18:56:06 +0100 "Paul B. Mahol" wrote: > On 2/5/09, Erwin Hoffmann wrote: >> Hi, >> >> I just saw Paul Mahol's comment: >> >>> Yet another invalid bug report. >>> OP should use -Dndis and not -Dbsd >>> >>> -- >>> Paul >> >> Well. If things would be sooo easy. >> Trying to declare "-D ndis" in the wpa_supplicant call as additional >> argument yields: >> >> artemis# pwd >> /etc/rc.d >> artemis# ./wpa_supplicant start ndis0 >> Starting wpa_supplicant. >> Unsupported driver 'ndis'. >> >> This is my kernel setup: >> >> artemis# kldstat -v | grep wlan >> 300 wlan_ccmp >> 301 wlan_tkip >> 302 wlan_wep >> 303 wlan >> >> artemis# kldstat -v | grep ndis >> 5 3 0xc0c73000 17734 ndis.ko >> 3 ndisapi >> 6 2 0xc0c8b000 caa4 if_ndis.ko >> 4 cardbus/ndis >> 5 pci/ndis >> 6 pccard/ndis >> 7 uhub/ndis >> >> What am I missing ? >> > > wpa_supplicant works fine on 8.0 with ndisX vaps. (and on 7 branch it > should work too) > > Your is not configured with support for ndis. Please read carefully > wpa_supplicant configuration options. It would help me (and everybody) if you could shed a little light on that subject. Apart from patching wpa_supplicant 0.3.11 and the most current to work under FreeBSD, I'm probably missing an import piece of information. Neither the man pages nor the current FreeBSD docs indicate (at least for me) the necessary adjustments. I'm certainly willing to raise a general web page about those issues (wlan/eap/802.11x) on my technical web site (https://www.fehcom.net). regards. --eh. > > -- > Paul > Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de From linimon at FreeBSD.org Thu Feb 5 14:55:34 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Feb 5 14:55:41 2009 Subject: kern/131414: [sis] [patch] Receive large packets by Vlan that parent if_sis (don't) work Message-ID: <200902052255.n15MtXgZ051500@freefall.freebsd.org> Old Synopsis: Receive large packets by Vlan that parent if_sis (don't) work New Synopsis: [sis] [patch] Receive large packets by Vlan that parent if_sis (don't) work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Feb 5 22:55:01 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131414 From onemda at gmail.com Thu Feb 5 16:28:48 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Feb 5 16:30:47 2009 Subject: kern/130820: [ndis] wpa_supplicant(8) returns 'no space on device' In-Reply-To: References: <3a142e750902050956ldf9a9c4q1ce33f60f36bead2@mail.gmail.com> Message-ID: <3a142e750902051628x25eeeddbxf1f9512c46028442@mail.gmail.com> On 2/5/09, Erwin Hoffmann wrote: > Hi Paul, > > > --On 5. Februar 2009 18:56:06 +0100 "Paul B. Mahol" > wrote: > >> On 2/5/09, Erwin Hoffmann wrote: >>> Hi, >>> >>> I just saw Paul Mahol's comment: >>> >>>> Yet another invalid bug report. >>>> OP should use -Dndis and not -Dbsd >>>> >>>> -- >>>> Paul >>> >>> Well. If things would be sooo easy. >>> Trying to declare "-D ndis" in the wpa_supplicant call as additional >>> argument yields: >>> >>> artemis# pwd >>> /etc/rc.d >>> artemis# ./wpa_supplicant start ndis0 >>> Starting wpa_supplicant. >>> Unsupported driver 'ndis'. >>> >>> This is my kernel setup: >>> >>> artemis# kldstat -v | grep wlan >>> 300 wlan_ccmp >>> 301 wlan_tkip >>> 302 wlan_wep >>> 303 wlan >>> >>> artemis# kldstat -v | grep ndis >>> 5 3 0xc0c73000 17734 ndis.ko >>> 3 ndisapi >>> 6 2 0xc0c8b000 caa4 if_ndis.ko >>> 4 cardbus/ndis >>> 5 pci/ndis >>> 6 pccard/ndis >>> 7 uhub/ndis >>> >>> What am I missing ? >>> >> >> wpa_supplicant works fine on 8.0 with ndisX vaps. (and on 7 branch it >> should work too) >> >> Your is not configured with support for ndis. Please read carefully >> wpa_supplicant configuration options. > > It would help me (and everybody) if you could shed a little light on that > subject. > > Apart from patching wpa_supplicant 0.3.11 and the most current to work > under FreeBSD, I'm probably missing an import piece of information. Neither > the man pages nor the current FreeBSD docs indicate (at least for me) the > necessary adjustments. wpa_supplicant is contributed software located in /usr/src/contrib/wpa_supplicant/ Makefiles to build wpa_supplicat for FreeBSD are in /usr/src/usr.sbin/wpa/wpa_supplicant/ -- Paul From yongari at FreeBSD.org Thu Feb 5 16:41:28 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Thu Feb 5 16:41:34 2009 Subject: kern/131414: [sis] [patch] Receive large packets by Vlan that parent if_sis (don't) work Message-ID: <200902060041.n160fRej034943@freefall.freebsd.org> Synopsis: [sis] [patch] Receive large packets by Vlan that parent if_sis (don't) work State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Feb 6 00:39:51 UTC 2009 State-Changed-Why: I believe CURRENT already have fix for the issue. Would you try try r185784? Since sis(4) moved to dev directory in HEAD you should use http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sis to check changes. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Feb 6 00:39:51 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=131414 From freebsd-listen at fabiankeil.de Fri Feb 6 08:52:56 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Fri Feb 6 08:53:03 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090202094226.E983@desktop> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> <20090202094226.E983@desktop> Message-ID: <20090206175243.70b93f65@fabiankeil.de> Jeff Roberson wrote: > On Sun, 1 Feb 2009, Fabian Keil wrote: > > > Fabian Keil wrote: > > > >> Jeff Roberson wrote: > >> > >>> http://people.freebsd.org/~jeff/mbuf_ref2.diff > >> > >>> I have been experimenting with different revisions to the mbuf api to > >>> improve performance and simplify code. This patch is the first of > >>> several proposed steps towards those goals. The aim of this patch is > >>> two fold; > >> > >>> I would appreciate testing feedback from varied workloads to make > >>> sure there are no bugs before I go forward with this. I have tested > >>> only host oriented networking with a few drivers. It is not > >>> anticipated that there will be any significant incompatibilities > >>> introduced with this round but there is always that possibility. > > > >> 5) > >> Finally, I tested the patch on an IBM ThinPad R51. The kernel > >> hangs on boot, the last messages are (hand transcribed): > >> > >> iwi0: mem 0xc0214000-0xc0214fff irq 11 > >> at device 2.0 on pci2 iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 > >> at 0xc0214000 iwi0: could not allocate rx mbuf > >> iwi0: could not allocate Rx ring > >> bpfdetach: was not attached > > > > Never mind, kernel and user land weren't completely in > > sync and this might be related to the recent wlan commits. > > I'll retry with an up-to-date user land. > > > > I have updated the patch here: > > http://people.freebsd.org/~jeff/mbuf_ref2.diff Building world failed for me with: cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized -Wstrict-prototypes -I/usr/src/sbin/pfctl/../../contrib/pf/pfctl -DE k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/pfctl/../../sys f_ruleset.c In file included from /usr/src/sbin/pfctl/../../sys/contrib/pf/net/pf_ruleset.c:48: /usr/obj/usr/src/tmp/usr/include/sys/mbuf.h:131: error: expected specifier-qualifier-list before 'uma_zone_t' *** Error code 1 Stop in /usr/src/sbin/pfctl. *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Manually building from /usr/src/sbin worked, though. After resuming with make buildworld NO_CLEAN=YES, the next failure was: ===> usr.bin/netstat (all) cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/netstat/if.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/netstat/inet.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/netstat/main.c cc -O2 -pipe -fno-strict-aliasing -DIPSEC -DSCTP -DINET6 -DNETGRAPH -DIPX -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.bin/netstat/mbuf.c In file included from /usr/src/usr.bin/netstat/mbuf.c:46: /usr/obj/usr/src/tmp/usr/include/sys/mbuf.h:131: error: expected specifier-qualifier-list before 'uma_zone_t' *** Error code 1 Stop in /usr/src/usr.bin/netstat. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Again building from /usr/src/usr.bin worked. Resuming stopped with yet another similar error message but afterwards make buildworld NO_CLEAN=YES finished successfully. I haven't really investigated the problem yet, but it might have something to do with my make flags: fk@TP51 ~ $grep NO_ /etc/make.conf NO_BLUETOOTH= # do not build Bluetooth related stuff NO_FORTRAN= # do not build g77 and related libraries NO_I4B= # do not build isdn4bsd package NO_INET6= # do not build IPv6 related programs and libraries NO_IPFILTER= # do not build IP Filter package NO_KERBEROS= # do not build and install Kerberos 5 (KTH Heimdal) NO_LPR= # do not build lpr and related programs NO_MAILWRAPPER= # do not build the mailwrapper(8) MTA selector #NO_NIS= # do not build NIS support and related programs. NO_ATM=yes NO_VINUM=yes NO_OBJC=yes NO_SHAREDOCS=yes NO_PROFILE=yes NO_PORTDOCS=yes Commenting out the NO_INET6 line didn't make a difference. I'm using your patch on an IBM ThinPad R51 since three days and didn't notice any problems so far. I also briefly tested it on an AMD64 system but as sound stopped working I reverted to the old kernel after verifying that ssh worked. This is a snd_emu10kx(4) problem, though. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090206/a32dca68/signature.pgp From rwatson at FreeBSD.org Fri Feb 6 14:52:37 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Fri Feb 6 14:52:43 2009 Subject: kern/112722: [udp] IP v4 udp fragmented packet reject Message-ID: <200902062252.n16MqZUw072480@freefall.freebsd.org> Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: feedback->open State-Changed-By: rwatson State-Changed-When: Fri Feb 6 22:51:58 UTC 2009 State-Changed-Why: Transition to open: the original submitter is no longer using this configuration, so we'll need someone to attempt to reproduce it using a recent FreeBSD version and see where that leads. http://www.freebsd.org/cgi/query-pr.cgi?pr=112722 From Kent.Fox at imail.org Fri Feb 6 15:00:21 2009 From: Kent.Fox at imail.org (Kent Fox) Date: Fri Feb 6 15:00:33 2009 Subject: kern/112722: [udp] IP v4 udp fragmented packet reject Message-ID: <200902062300.n16N0HiW072624@freefall.freebsd.org> The following reply was made to PR kern/112722; it has been noted by GNATS. From: Kent Fox To: "rwatson@FreeBSD.org" , "freebsd-net@FreeBSD.org" Cc: Subject: RE: kern/112722: [udp] IP v4 udp fragmented packet reject Date: Mon, 2 Feb 2009 08:21:56 -0700 Thanks for the thought but we went back to OpenBSD and fixed our performanc= e issue with some kernel parameters. I'm sorry that I cannot help out and d= uplicate the problem as I no longer have that environment. The main issue w= as the forced reassembly of fragmented packets. When the ingress packet siz= e was maxed out, the egress with the tunnel encapsulation was too large and= the packet was discarded. We tried a smaller MTU on the ingress but we sti= ll could never make it work. Doing an IPsec tunnel with RDP was a sure way = of killing the connection. So what you have is C------>FW------->S. From C(= lient) the S(erver) there is an IPSec tunnel (all the way) and from C to FW= (firewall FreeBSD server) is another IPSec tunnel (tunnel on the intranet (= now GRE)). Hope that helps. Kent -----Original Message----- From: rwatson@FreeBSD.org [mailto:rwatson@FreeBSD.org]=20 Sent: Monday, February 02, 2009 4:49 AM To: Kent Fox; rwatson@FreeBSD.org; freebsd-net@FreeBSD.org Subject: Re: kern/112722: [udp] IP v4 udp fragmented packet reject Synopsis: [udp] IP v4 udp fragmented packet reject State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Mon Feb 2 11:31:13 UTC 2009 State-Changed-Why:=20 Dear Kent: I apologize for the delay in response to this problem report. Could I ask you to: (1) Confirm the problem still exists, especially if you've moved forward to a more recent rev of FreeBSD. (2) Let me know a bit more about your firewall/ipsec/etc setup. In particular, if you can easily identify a minimalist setup to reproduce this problem. Do the packets you're describing enter via a tunnel, or do they arrive unencapsulated? (3) Send me tcpdump output that shows the packet ingress and resulting ICMP. Thanks, Robert http://www.freebsd.org/cgi/query-pr.cgi?pr=3D112722 From freebsd-listen at fabiankeil.de Sun Feb 8 06:26:55 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sun Feb 8 06:27:04 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090202094226.E983@desktop> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> <20090202094226.E983@desktop> Message-ID: <20090208152647.3e4316d1@fabiankeil.de> Jeff Roberson wrote: > On Sun, 1 Feb 2009, Fabian Keil wrote: > > > Fabian Keil wrote: > > > >> Jeff Roberson wrote: > >> > >>> http://people.freebsd.org/~jeff/mbuf_ref2.diff > >> > >>> I have been experimenting with different revisions to the mbuf api to > >>> improve performance and simplify code. This patch is the first of > >>> several proposed steps towards those goals. The aim of this patch is > >>> two fold; > >> > >>> I would appreciate testing feedback from varied workloads to make sure > >>> there are no bugs before I go forward with this. I have tested only > >>> host oriented networking with a few drivers. It is not anticipated > >>> that there will be any significant incompatibilities introduced with > >>> this round but there is always that possibility. > > > >> 5) > >> Finally, I tested the patch on an IBM ThinPad R51. The kernel > >> hangs on boot, the last messages are (hand transcribed): > >> > >> iwi0: mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 > >> iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 > >> iwi0: could not allocate rx mbuf > >> iwi0: could not allocate Rx ring > >> bpfdetach: was not attached > > > > Never mind, kernel and user land weren't completely in > > sync and this might be related to the recent wlan commits. > > I'll retry with an up-to-date user land. > I have updated the patch here: > > http://people.freebsd.org/~jeff/mbuf_ref2.diff > > This resolves the !INVARIANTS bug and improves the style as you suggested. I run into several system hangs (or maybe panics) yesterday, mostly with Xorg running so I didn't get any details. I got one on the console though. After running a regression test that opens multiple HTTP connections to the loop back device, I used rsync to restore some files that were damaged by an earlier hang. That lead to a page fault in em_start_locked(). While I dumped core from the debugger, savecore didn't find the dump afterwards. Anyway, there's a screen shot available at: http://www.fabiankeil.de/bilder/freebsd/mbuf-patch-page-fault-em_start_locked.jpg Before the patch I didn't see any surprising panics in quite a while. I reverted the patch for now to verify that the system is stable without it. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090208/3e26c62f/signature.pgp From jroberson at jroberson.net Sun Feb 8 10:35:20 2009 From: jroberson at jroberson.net (Jeff Roberson) Date: Sun Feb 8 10:35:27 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090208152647.3e4316d1@fabiankeil.de> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> <20090202094226.E983@desktop> <20090208152647.3e4316d1@fabiankeil.de> Message-ID: <20090208083321.M983@desktop> On Sun, 8 Feb 2009, Fabian Keil wrote: > Jeff Roberson wrote: > >> On Sun, 1 Feb 2009, Fabian Keil wrote: >> >>> Fabian Keil wrote: >>> >>>> Jeff Roberson wrote: >>>> >>>>> http://people.freebsd.org/~jeff/mbuf_ref2.diff >>>> >>>>> I have been experimenting with different revisions to the mbuf api to >>>>> improve performance and simplify code. This patch is the first of >>>>> several proposed steps towards those goals. The aim of this patch is >>>>> two fold; >>>> >>>>> I would appreciate testing feedback from varied workloads to make sure >>>>> there are no bugs before I go forward with this. I have tested only >>>>> host oriented networking with a few drivers. It is not anticipated >>>>> that there will be any significant incompatibilities introduced with >>>>> this round but there is always that possibility. >>> >>>> 5) >>>> Finally, I tested the patch on an IBM ThinPad R51. The kernel >>>> hangs on boot, the last messages are (hand transcribed): >>>> >>>> iwi0: mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2 >>>> iwi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0214000 >>>> iwi0: could not allocate rx mbuf >>>> iwi0: could not allocate Rx ring >>>> bpfdetach: was not attached >>> >>> Never mind, kernel and user land weren't completely in >>> sync and this might be related to the recent wlan commits. >>> I'll retry with an up-to-date user land. > >> I have updated the patch here: >> >> http://people.freebsd.org/~jeff/mbuf_ref2.diff >> >> This resolves the !INVARIANTS bug and improves the style as you suggested. > > I run into several system hangs (or maybe panics) yesterday, > mostly with Xorg running so I didn't get any details. > > I got one on the console though. After running a regression > test that opens multiple HTTP connections to the loop back > device, I used rsync to restore some files that were damaged by > an earlier hang. That lead to a page fault in em_start_locked(). > > While I dumped core from the debugger, > savecore didn't find the dump afterwards. > > Anyway, there's a screen shot available at: > http://www.fabiankeil.de/bilder/freebsd/mbuf-patch-page-fault-em_start_locked.jpg Can you open gdb on kernel.debug and tell me what: list *(em_start_locked+0x1e5) outputs? Thanks, Jeff > > Before the patch I didn't see any surprising panics > in quite a while. I reverted the patch for now to > verify that the system is stable without it. > > Fabian > From freebsd-listen at fabiankeil.de Sun Feb 8 11:27:31 2009 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sun Feb 8 11:27:39 2009 Subject: mbuf revision, testers/comments wanted. In-Reply-To: <20090208083321.M983@desktop> References: <20090131125100.N983@desktop> <20090201160544.4f1961b4@fabiankeil.de> <20090201170550.482bf325@fabiankeil.de> <20090202094226.E983@desktop> <20090208152647.3e4316d1@fabiankeil.de> <20090208083321.M983@desktop> Message-ID: <20090208202718.256db562@fabiankeil.de> Jeff Roberson wrote: > On Sun, 8 Feb 2009, Fabian Keil wrote: > > > Jeff Roberson wrote: > >> I have updated the patch here: > >> > >> http://people.freebsd.org/~jeff/mbuf_ref2.diff > >> > >> This resolves the !INVARIANTS bug and improves the style as you suggested. > > > > I run into several system hangs (or maybe panics) yesterday, > > mostly with Xorg running so I didn't get any details. > > > > I got one on the console though. After running a regression > > test that opens multiple HTTP connections to the loop back > > device, I used rsync to restore some files that were damaged by > > an earlier hang. That lead to a page fault in em_start_locked(). > > > > While I dumped core from the debugger, > > savecore didn't find the dump afterwards. > > > > Anyway, there's a screen shot available at: > > http://www.fabiankeil.de/bilder/freebsd/mbuf-patch-page-fault-em_start_locked.jpg > > Can you open gdb on kernel.debug and tell me what: > > list *(em_start_locked+0x1e5) > > outputs? Unfortunately I didn't keep the kernel.debug for the patched kernel around. For my current kernel I get: fk@TP51 ~ $gdb /usr/obj/usr/src/sys/THINKPAD/kernel.debug GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) list *(em_start_locked+0x1e5) 0xc0529eb5 is in em_start_locked (/usr/src/sys/dev/e1000/if_em.c:1003). 998 if (!adapter->link_active) 999 return; 1000 1001 while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { 1002 1003 IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); 1004 if (m_head == NULL) 1005 break; 1006 /* 1007 * Encapsulation can modify our pointer, and or make it Not sure if it's any good ... Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090208/0d216d5a/signature.pgp From bugmaster at FreeBSD.org Mon Feb 9 03:06:56 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 9 03:08:46 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200902091106.n19B6tbP009193@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131310 net [panic] 7.1 panics with mpd netgraph interface changes o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw o kern/130846 net [vge] vge0 not autonegotiating to 1000baseTX full dupl o kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130652 net [kernel] [patch] Possible deadlock in rt_check() (sys/ o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R f kern/130605 net [tcp] Certain hardware produces "Network is unreachabl o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106974 net [bge] packet loose and linkup problem o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100839 net [txp] txp driver inconsistently stops working when the o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/89876 net [txp] [patch] txp driver doesn't work with latest firm f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 255 problems total. From helen.zhang at bluecoat.com Mon Feb 9 10:41:34 2009 From: helen.zhang at bluecoat.com (Zhang, Helen) Date: Mon Feb 9 10:41:43 2009 Subject: Anyone working on the FreeBSD driver for broadcom 5784M Gige chip? Message-ID: <9CFA8139F7106843B28F9E6FB1FF4BBE0D0117@bcs-mail04.internal.cacheflow.com> Hi, there: I'm new to FreeBSD community and this is my first email to the mailing group. Recently I'm working on Broadcom 5784M Gige driver. My code base is close to FreeBSD, but FreeBSD bge driver doesn't support the chip yet. The linux driver supports the chip. I'm wondering whether anyone is working or plans to work on to port the linux code to FreeBSD base. If so, I hope we can share some information together. Thanks. Another thing, I found one dead loop in current src/sys/dev/bge/if_bge.c (both 216/217 revisions): around line 2682, if mii_phy_probe( ) fails, the code will go back to again (4 lines back). Variable trys will reset to 0 every time, so the (trys++<4) condition is forever false. I don't know how to report the bug to freebsd Community yet. So I just attach the related code below. The fix is simple: just move "trys=0" line before again: Thanks and best wishes to everyone! -Helen =========== src/sys/dev/bge/if_bge.c: around line 2676 BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); again: bge_asf_driver_up(sc); trys = 0; if (mii_phy_probe(dev, &sc->bge_miibus, <<<<<< line 2682 bge_ifmedia_upd, bge_ifmedia_sts)) { if (trys++ < 4) { device_printf(sc->bge_dev, "Try again\n"); bge_miibus_writereg(sc->bge_dev, 1, MII_BMCR, BMCR_RESET); goto again; } device_printf(sc->bge_dev, "MII without any PHY!\n"); error = ENXIO; goto fail; } From rrs at lakerest.net Mon Feb 9 12:23:52 2009 From: rrs at lakerest.net (Randall Stewart) Date: Mon Feb 9 12:24:25 2009 Subject: SCTP, possible bug in peer authentication key In-Reply-To: <0EEEB325-C7AF-468F-9374-EFED1BD3B3E4@ieee.org> References: <4980B747.7070400@free.fr> <0EEEB325-C7AF-468F-9374-EFED1BD3B3E4@ieee.org> Message-ID: Note that all of these changes are now in Head.. however I am not sure of the likely-hood of them moving into 7 since the xsctp_xxxx changes for the mib (rwnd and assoc_id) break ABI compatability. I have now (in head) padded up the structures at the end (in case we need to add more). But in general this means I cannot commit to stable many changes. I will go back and see what can be done :-( I may be able to do some "ifdef" and other magic so I can pull in the changes that have went on.. not sure. R On Jan 29, 2009, at 12:29 PM, Peter Lei wrote: > There's a corresponding change that is needed for pulling the auth > info > out of the cookie for the other direction (i.e. server side > handling). I've > committed that into the SCTP project repo, and should also get in with > Randall's next commit. > > --peter > > On Jan 29, 2009, at 2:23 AM, Michael T?xen wrote: > >> Hi Yann, >> >> very good catch! You are right. >> >> I have committed your patch to Randalls repository, so it will >> show up in the FreeBSD sources soon (next time he syncs them)... >> >> Best regards >> Michael >> >> On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote: >> >>> Hi all, >>> >>> I think I found a bug in the SCTP authentication code, in >>> sctp_load_addresses_from_init() in sctp_pcb.c >>> >>> keylen = sizeof(*p_random) + random_len + sizeof(*chunks) + >>> num_chunks + >>> sizeof(*hmacs) + hmacs_len; >>> >>> The keylen calculation assumes the Chunk List Parameter (CHUNKS) >>> vl-param was present in the received INIT packet, which can be >>> false if >>> peer SCTP does not require any chunk to be authenticated (this >>> typically >>> occurs if peer does not support ASCONF). >>> >>>> From RFC 4895, 6.1 >>> >>> * An SCTP endpoint has a list of chunks it only accepts if they are >>> * received in an authenticated way. This list is included in the >>> INIT >>> * and INIT-ACK, and MAY be omitted if it is empty. Since this list >>> * does not change during the lifetime of the SCTP endpoint there >>> is no >>> * problem in case of INIT collision. >>> >>> This case is properly handled later in the build of the key >>> >>> /* append in the AUTH chunks */ >>> if (chunks != NULL) { >>> ..... >>> } >>> >>> I think the calculated keylen should be something like this : >>> >>> keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + >>> hmacs_len; >>> >>> if (chunks != NULL) { >>> keylen += sizeof(*chunks) + num_chunks >>> } >>> >>> This problem results in authenticated packets sent from peer SCTP >>> to be >>> discarded. >>> >>> The problem does not occurs if peer SCTP is modified to send an >>> empty >>> Chunk List Parameter, (eg num_chunks = 0 in the decoding). >>> >>> Br, >>> Yann >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org >>> " >>> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From rwatson at FreeBSD.org Mon Feb 9 15:27:23 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Mon Feb 9 15:27:35 2009 Subject: kern/88336: [ipsec] [patch] setkey(8) -D fails to report all SAs Message-ID: <200902092327.n19NRM7R074581@freefall.freebsd.org> Old Synopsis: [kernel] [patch] setkey(8) -D fails to report all SAs New Synopsis: [ipsec] [patch] setkey(8) -D fails to report all SAs Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: rwatson Responsible-Changed-When: Mon Feb 9 23:26:47 UTC 2009 Responsible-Changed-Why: Tag as ipsec; assign to freebsd-net. http://www.freebsd.org/cgi/query-pr.cgi?pr=88336 From mij at bitchx.it Mon Feb 9 18:42:32 2009 From: mij at bitchx.it (Mij) Date: Mon Feb 9 18:42:39 2009 Subject: SO_BINDANY in FreeBSD Message-ID: <7AB15D3E-5E8C-4FE9-873F-F8BAE72B8C6B@bitchx.it> Hello folks, OpenBSD provides a SO_BINDANY socket option that allows an application to produce traffic from an IP address which is not configured on the host: http://www.openbsd.org/cgi-bin/man.cgi?query=setsockopt This is useful to run a transparent proxy which receives connections from X and wants to connect to the real destination pretending to be X. Is there any possibility to see this option implemented in FreeBSD? Do you otherwise have workarounds for getting the same behavior with reasonable complexity (eg, avoiding handling raw frames with bpf)? From julian at elischer.org Tue Feb 10 00:06:12 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Feb 10 00:06:37 2009 Subject: SO_BINDANY in FreeBSD In-Reply-To: <7AB15D3E-5E8C-4FE9-873F-F8BAE72B8C6B@bitchx.it> References: <7AB15D3E-5E8C-4FE9-873F-F8BAE72B8C6B@bitchx.it> Message-ID: <49913577.8020605@elischer.org> Mij wrote: > Hello folks, > > OpenBSD provides a SO_BINDANY socket option that allows an > application to produce traffic from an IP address which is not configured > on the host: > > http://www.openbsd.org/cgi-bin/man.cgi?query=setsockopt > > This is useful to run a transparent proxy which receives connections from > X and wants to connect to the real destination pretending to be X. we have a similar functionality in beta. teh big holdup right now is we discovered the OpenBSD version and are thinking about how compatible to make our code. > > Is there any possibility to see this option implemented in FreeBSD? Do > you otherwise have workarounds for getting the same behavior with > reasonable complexity (eg, avoiding handling raw frames with bpf)? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From linimon at FreeBSD.org Tue Feb 10 00:10:14 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Feb 10 00:10:21 2009 Subject: kern/131549: ifconfig(8) can't clear 'monitor' mode on the wireless device Message-ID: <200902100810.n1A8ADpo001581@freefall.freebsd.org> Old Synopsis: ifconfig can't clear 'monitor' mode on the wireless device New Synopsis: ifconfig(8) can't clear 'monitor' mode on the wireless device Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Feb 10 08:09:43 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131549 From vanhu at FreeBSD.org Tue Feb 10 00:40:59 2009 From: vanhu at FreeBSD.org (vanhu@FreeBSD.org) Date: Tue Feb 10 00:41:05 2009 Subject: kern/88336: [ipsec] [patch] setkey(8) -D fails to report all SAs Message-ID: <200902100840.n1A8ewcK033570@freefall.freebsd.org> Synopsis: [ipsec] [patch] setkey(8) -D fails to report all SAs Responsible-Changed-From-To: freebsd-net->vanhu Responsible-Changed-By: vanhu Responsible-Changed-When: Tue Feb 10 08:39:39 UTC 2009 Responsible-Changed-Why: Alraedy working on the problem for ipsec-tools, on which a similar patch has been added as a first workaround. http://www.freebsd.org/cgi/query-pr.cgi?pr=88336 From gavin at FreeBSD.org Tue Feb 10 05:43:33 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Tue Feb 10 05:43:45 2009 Subject: kern/131536: kernel does allow manipulation of subnet routes Message-ID: <200902101343.n1ADhWET066189@freefall.freebsd.org> Synopsis: kernel does allow manipulation of subnet routes Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Tue Feb 10 13:40:47 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=131536 From gavin at FreeBSD.org Tue Feb 10 06:14:30 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Tue Feb 10 06:14:41 2009 Subject: bin/131365: route(8): route add changes interpretation of network specification [regression] Message-ID: <200902101414.n1AEETvx089255@freefall.freebsd.org> Synopsis: route(8): route add changes interpretation of network specification [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Tue Feb 10 14:14:05 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=131365 From adamk at voicenet.com Tue Feb 10 09:20:07 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Tue Feb 10 09:20:13 2009 Subject: kern/131162: [ath] Atheros driver bugginess and kernel crashes Message-ID: <200902101720.n1AHK3Wp023788@freefall.freebsd.org> The following reply was made to PR kern/131162; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@FreeBSD.org, adamk@voicenet.com Cc: Subject: Re: kern/131162: [ath] Atheros driver bugginess and kernel crashes Date: Tue, 10 Feb 2009 12:08:39 -0500 Is there *anything* else I can do to track down this problem? Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ericx at vineyard.net Tue Feb 10 12:52:24 2009 From: ericx at vineyard.net (Eric W. Bates) Date: Tue Feb 10 12:52:31 2009 Subject: using enc0 with ipfw Message-ID: <4991E496.6080101@vineyard.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have a working firewall with multiple esp tunnels. To this machine we want to add the ability to filter the emergent, decrypted packets. We are running 7.1-RELEASE-p2 Does filtering require both the IPSEC_FILTERTUNNEL and the enc device? Or are these 2 separate approaches to the same problem. We cannot get the firewall to "accept" decrypted packets in. With a ping running from tunneled network to tunneled network, tcpdump shows esp packets leaving the firewall. At the remote end tcpdump shows icmp echo requests and echo replies on the internal interface and it also shows bi-directional esp traffic on the external interface. However, on the originating firewall tcpdump shows none of the esp reply packets. All the firewall deny rules have logging enabled. Nothing appears in the log. So as far as we can tell ipfw is not blocking anything. enc0 has been ifconfig'ed "up"; and the enc sysctl flags have been set as suggested in enc(4). tcpdump on enc0 on the originating machine shows the icmp echo requests going out. ipfw has an explicit "allow ip from any to any" on enc0 which is not getting any hits. We have tried this both with and without enc and IPSEC_FILTERTUNNEL in all various permutations with basically the same results. If we recompile and remove both the enc device and the IPSEC_FILTERTUNNEL option, the tunnel works fine. Any thots? RTFM is a welcome suggestion; but none of the man pages really seem to cover this and we have had little luck with Google. Thank you for your time. - -- Eric W. Bates ericx@vineyard.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmR5JYACgkQD1roJTQ4LlGeMQCgmeEd0H5qVFqKtYl9XHSndR12 5LoAoIBTf3DlqKXh3aLId/8U81/uzPWA =NMIE -----END PGP SIGNATURE----- From nugundam at gmail.com Tue Feb 10 13:37:50 2009 From: nugundam at gmail.com (Joseph Lee) Date: Tue Feb 10 13:37:56 2009 Subject: kern/124753: net80211 discards power-save queue packets early In-Reply-To: References: <200806191030.m5JAU36i027140@freefall.freebsd.org> Message-ID: <4991EE19.5020401@gmail.com> I apologize for following up so late on this. I've only now have time to follow up. Sepherosa Ziehau wrote: > On Thu, Jun 19, 2008 at 6:30 PM, wrote: >> Synopsis: net80211 discards power-save queue packets early >> >> Responsible-Changed-From-To: freebsd-i386->freebsd-net >> Responsible-Changed-By: remko >> Responsible-Changed-When: Thu Jun 19 10:29:47 UTC 2008 >> Responsible-Changed-Why: >> reassign to networking team. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=124753 > > In How-To-Repeat, you said: > "Then associate a recent Windows Mobile 6.1 device to the FreeBSD box > running hostapd ..." > > In Description, you said: > "The WM6.1 device recv ps-poll's for packets every 20 seconds ..." > > AFAIK, STA sends ps-poll to AP; AP does not send ps-poll to STA. Why > did your windows STA receive ps-poll from freebsd AP? Did you capture > it by using 802.11 tap? > > And which freebsd driver were you using? I'm using the ath wifi driver. The upgrade to FreeBSD 7.1 has not changed WiFi behavior. > Your problem looks like: > - Either freebsd AP did not properly configure TIM in beacons, which > could be easily found out by using 802.11 tap. But I highly suspect > if you were using ath(4), TIM would be misconfigured. What is tap? > - Or your windows STA didn't process TIM according to 802.11 standard. Sam Leffler wrote: >The PR states the listen interval sent by the station is 3 (beacons) and the beacon >interval is 100TU. This means the AP is required to buffer unicast frames for only 300TU >which is ~300 ms. But according to the report the Windows device is polling every 20 >seconds so there's no guarantee any packets will be present (even with the net80211 code >arbitrarily using 4x the list interval specified by the sta). I find it really hard to >believe a device would poll every 20 secs so something seems wrong in what's >reported/observed. The device is in its best power-saving mode where it make take time to respond to any packets. I only have this problem with FreeBSD hostap on the switch from FreeBSD 6 -> 7. Other APs such as Netgear/Linkgear have no issues, but can be postulated they don't implement PM as FreeBSD currently does. Also, on this same FreeBSD wifi-ap, no laptops have the same issue. So, it's isolated between FreeBSD and Windows Mobile. >Given that defeating the aging logic just pushed the problem elsewhere it sounds like >there's something else wrong which (as you note) probably requires a packet capture to >understand. I'm pretty sure TIM is handled correctly in RELENG_7 but a packet capture >would help us verify that. What do I need to do get you guys a packet capture to verify the TIM? Thanks, Joseph From rdivacky at freebsd.org Tue Feb 10 14:17:42 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Feb 10 14:17:49 2009 Subject: unsafe C in netgraph/pppoed.c Message-ID: <20090210215739.GA24102@freebsd.org> hi struct pppoe_tag { u_int16_t tag_type; u_int16_t tag_len; char tag_data[]; }__packed; struct pppoe_hdr{ u_int8_t ver:4; u_int8_t type:4; u_int8_t code; u_int16_t sid; u_int16_t length; struct pppoe_tag tag[]; }__packed; this is inherently unsafe as the tag_data can only have 0 elements to be used safely. gcc compiles this without warning although there should be a big one. I found this using clang, which produces this error/warning: lev pppoed$ ccc -c pppoed.c ccc: Unknown host 'freebsd', using generic host information. In file included from pppoed.c:41: /usr/include/netgraph/ng_pppoe.h:213:22: error: 'struct pppoe_tag' may not be used as an array element due to flexible array member struct pppoe_tag tag[]; ^ 1 diagnostic generated. can you guys take a look at this issue? thnx! roman p.s. please keep me CCed as I am not subscribed to net@ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090210/82984cca/attachment.pgp From kostikbel at gmail.com Wed Feb 11 05:15:54 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Feb 11 05:16:00 2009 Subject: unsafe C in netgraph/pppoed.c In-Reply-To: <20090210215739.GA24102@freebsd.org> References: <20090210215739.GA24102@freebsd.org> Message-ID: <20090211121810.GF62256@deviant.kiev.zoral.com.ua> On Tue, Feb 10, 2009 at 10:57:39PM +0100, Roman Divacky wrote: > hi > > > struct pppoe_tag { > u_int16_t tag_type; > u_int16_t tag_len; > char tag_data[]; > }__packed; > > struct pppoe_hdr{ > u_int8_t ver:4; > u_int8_t type:4; > u_int8_t code; > u_int16_t sid; > u_int16_t length; > struct pppoe_tag tag[]; > }__packed; > > > this is inherently unsafe as the tag_data can only have 0 elements > to be used safely. gcc compiles this without warning although there > should be a big one. > > I found this using clang, which produces this error/warning: > > lev pppoed$ ccc -c pppoed.c ccc: Unknown host 'freebsd', using generic host information. > In file included from pppoed.c:41: > /usr/include/netgraph/ng_pppoe.h:213:22: error: 'struct pppoe_tag' may not be used as an array element due to flexible array member > struct pppoe_tag tag[]; > ^ > 1 diagnostic generated. > > can you guys take a look at this issue? > > thnx! > > roman > > p.s. please keep me CCed as I am not subscribed to net@ The use of [] as an array specifier for the last structure element is a well formed C99 construct, called flexible array member. See ISO/IEC 9899:1999 (E), 6.7.2.1, clause 16. Citation: As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member. ... Then, the use of the structure with flexible array member as a member of another structure is the gcc extension. See the Chapter 5: Extensions to the C Language Family 5.14 Arrays of Length Zero in the gcc manual. This is the reason why it is silently adopted by in-tree compiler. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090211/eba0f6cb/attachment.pgp From lev at serebryakov.spb.ru Wed Feb 11 08:33:54 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Wed Feb 11 08:34:03 2009 Subject: New Atheros card: channel reset error [sorry for posting of not ready message] Message-ID: <16510045949.20090211193347@serebryakov.spb.ru> Hello, Freebsd-net. I'm getting this error on every operation with new Atheros MiniPCI card: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 What does it mean? Maybe, card is broken? # pciconf -lv ath0@pci0:0:17:0: class=0x020000 card=0x1600185f chip=0x001b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5006 family 802.11abg Wireless NIC' class = network subclass = ethernet # grep ath /var/run/dmesg.boot ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xa0060000-0xa006ffff irq 15 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:0b:6b:2d:e8:1e ath0: mac 10.5 phy 6.1 radio 6.3 # sysctl dev.ath dev.ath.0.%desc: Atheros 5212 dev.ath.0.%driver: ath dev.ath.0.%location: slot=17 function=0 dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x185f subdevice=0x1600 class=0x020000 dev.ath.0.%parent: pci0 dev.ath.0.smoothing_rate: 95 dev.ath.0.sample_rate: 10 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 0 dev.ath.0.slottime: 9 dev.ath.0.acktimeout: 48 dev.ath.0.ctstimeout: 48 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 2 dev.ath.0.diversity: 1 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.fftxqmin: 2 dev.ath.0.fftxqmax: 50 dev.ath.0.rfsilent: 1 dev.ath.0.rfkill: 1 dev.ath.0.monpass: 24 # sysctl hw.ath hw.ath.hal.swba_backoff: 0 hw.ath.hal.sw_brt: 10 hw.ath.hal.dma_brt: 2 hw.ath.hal.version: 0.9.20.3 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.regdomain: 0 hw.ath.countrycode: 0 hw.ath.xchanmode: 1 hw.ath.outdoor: 1 hw.ath.calibrate: 30 -- // Black Lion AKA Lev Serebryakov From lev at serebryakov.spb.ru Wed Feb 11 08:40:57 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Wed Feb 11 08:41:04 2009 Subject: New Atheros card: channel reset error Message-ID: <834727755.20090211192142@serebryakov.spb.ru> Hello, Freebsd-net. I'm getting this error on every operation with new Atheros MiniPCI card: ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 What does it mean? Maybe, card is broken? -- // Black Lion AKA Lev Serebryakov From adamk at voicenet.com Wed Feb 11 11:52:24 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Wed Feb 11 11:52:31 2009 Subject: New Atheros card: channel reset error [sorry for posting of not ready message] In-Reply-To: <16510045949.20090211193347@serebryakov.spb.ru> References: <16510045949.20090211193347@serebryakov.spb.ru> Message-ID: <20090211145145.1b5f5b24@sorrow.ashke.com> I get similar errors, but only when trying to connect to a particular wireless network (at work). I can connect to the one I have at home, and do not get any errors. I have opened up a pr about it: http://www.freebsd.org/cgi/query-pr.cgi?pr=131162 In my case, if I then remove the wireless card while the interface is trying to acquire an IP address, the kernel panics. Are you seeing something similar? Adam On Wed, 11 Feb 2009 19:33:47 +0300 Lev Serebryakov wrote: > Hello, Freebsd-net. > > I'm getting this error on every operation with new Atheros MiniPCI > card: > > ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 > > What does it mean? Maybe, card is broken? > > # pciconf -lv > ath0@pci0:0:17:0: class=0x020000 card=0x1600185f chip=0x001b168c rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5006 family 802.11abg Wireless NIC' > class = network > subclass = ethernet > > # grep ath /var/run/dmesg.boot > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xa0060000-0xa006ffff irq 15 at device 17.0 on pci0 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:0b:6b:2d:e8:1e > ath0: mac 10.5 phy 6.1 radio 6.3 > > # sysctl dev.ath > dev.ath.0.%desc: Atheros 5212 > dev.ath.0.%driver: ath > dev.ath.0.%location: slot=17 function=0 > dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x185f subdevice=0x1600 class=0x020000 > dev.ath.0.%parent: pci0 > dev.ath.0.smoothing_rate: 95 > dev.ath.0.sample_rate: 10 > dev.ath.0.countrycode: 0 > dev.ath.0.regdomain: 0 > dev.ath.0.slottime: 9 > dev.ath.0.acktimeout: 48 > dev.ath.0.ctstimeout: 48 > dev.ath.0.softled: 0 > dev.ath.0.ledpin: 0 > dev.ath.0.ledon: 0 > dev.ath.0.ledidle: 2700 > dev.ath.0.txantenna: 0 > dev.ath.0.rxantenna: 2 > dev.ath.0.diversity: 1 > dev.ath.0.txintrperiod: 5 > dev.ath.0.diag: 0 > dev.ath.0.tpscale: 0 > dev.ath.0.tpc: 0 > dev.ath.0.tpack: 63 > dev.ath.0.tpcts: 63 > dev.ath.0.fftxqmin: 2 > dev.ath.0.fftxqmax: 50 > dev.ath.0.rfsilent: 1 > dev.ath.0.rfkill: 1 > dev.ath.0.monpass: 24 > > # sysctl hw.ath > hw.ath.hal.swba_backoff: 0 > hw.ath.hal.sw_brt: 10 > hw.ath.hal.dma_brt: 2 > hw.ath.hal.version: 0.9.20.3 > hw.ath.txbuf: 200 > hw.ath.rxbuf: 40 > hw.ath.regdomain: 0 > hw.ath.countrycode: 0 > hw.ath.xchanmode: 1 > hw.ath.outdoor: 1 > hw.ath.calibrate: 30 > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From oberman at es.net Wed Feb 11 14:34:19 2009 From: oberman at es.net (Kevin Oberman) Date: Wed Feb 11 14:34:26 2009 Subject: Support for IPv6 tables in ipfw? Message-ID: <20090211223416.5550A1CC0B@ptavv.es.net> With all of Luigi's excellent work on ipfw, I'd like to request that someone familiar with the code look at implementing support for tables for IPv6. While the IPv6 support in IPFW is generally a bit less mature than IPv4, the one functional thing that is completely missing is tables. Having them would make my life quite a bit easier. It's the one thing that I have been unable to work around in my dual-stack firewalls. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From raffaele.delorenzo at libero.it Wed Feb 11 15:04:28 2009 From: raffaele.delorenzo at libero.it (Raffaele De Lorenzo) Date: Wed Feb 11 15:05:00 2009 Subject: Support for IPv6 tables in ipfw? In-Reply-To: <20090211223416.5550A1CC0B@ptavv.es.net> References: <20090211223416.5550A1CC0B@ptavv.es.net> Message-ID: <48EED655-AD6F-4C37-8182-86715F417011@libero.it> Hi, I developed with Luigi (as mentor) and Mariano Tortoriello the first release of ipfw with ipv6 extension. If you and the FreeBSD Community think that the tables functional is a good feature i can develop it for IPv6 protocol. Ciao Raffaele On 11/feb/09, at 23:34, Kevin Oberman wrote: > With all of Luigi's excellent work on ipfw, I'd like to request that > someone familiar with the code look at implementing support for tables > for IPv6. While the IPv6 support in IPFW is generally a bit less > mature > than IPv4, the one functional thing that is completely missing is > tables. Having them would make my life quite a bit easier. It's the > one > thing that I have been unable to work around in my dual-stack > firewalls. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From sam at freebsd.org Wed Feb 11 15:46:11 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed Feb 11 15:46:17 2009 Subject: New Atheros card: channel reset error [sorry for posting of not ready message] In-Reply-To: <16510045949.20090211193347@serebryakov.spb.ru> References: <16510045949.20090211193347@serebryakov.spb.ru> Message-ID: <49936340.10909@freebsd.org> Lev Serebryakov wrote: > Hello, Freebsd-net. > > I'm getting this error on every operation with new Atheros MiniPCI > card: > > ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 > > status 12 is: HAL_EINVAL = 12, /* Invalid parameter to function */ (from ah.h). The first flags translate to a 2GHz Dynamic Turbo channel (see _ieee80211.h). The hal flags translate to a 5GHz Dynamic Turbo channel (see ah.h). So the driver is mis-mapping the channel and causing the hal to reject the request. If I recall this causes scanning to stop on RELENG_7 so you'll want to force this channel to not be requested by disabling dynamic turbo mode. I can't recall how that's done on RELENG_7; consult ifconfig(8). > What does it mean? Maybe, card is broken? > > # pciconf -lv > ath0@pci0:0:17:0: class=0x020000 card=0x1600185f chip=0x001b168c rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5006 family 802.11abg Wireless NIC' > class = network > subclass = ethernet > > # grep ath /var/run/dmesg.boot > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xa0060000-0xa006ffff irq 15 at device 17.0 on pci0 > ath0: [ITHREAD] > ath0: WARNING: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:0b:6b:2d:e8:1e > ath0: mac 10.5 phy 6.1 radio 6.3 > > # sysctl dev.ath > dev.ath.0.%desc: Atheros 5212 > dev.ath.0.%driver: ath > dev.ath.0.%location: slot=17 function=0 > dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x185f subdevice=0x1600 class=0x020000 > dev.ath.0.%parent: pci0 > dev.ath.0.smoothing_rate: 95 > dev.ath.0.sample_rate: 10 > dev.ath.0.countrycode: 0 > dev.ath.0.regdomain: 0 > dev.ath.0.slottime: 9 > dev.ath.0.acktimeout: 48 > dev.ath.0.ctstimeout: 48 > dev.ath.0.softled: 0 > dev.ath.0.ledpin: 0 > dev.ath.0.ledon: 0 > dev.ath.0.ledidle: 2700 > dev.ath.0.txantenna: 0 > dev.ath.0.rxantenna: 2 > dev.ath.0.diversity: 1 > dev.ath.0.txintrperiod: 5 > dev.ath.0.diag: 0 > dev.ath.0.tpscale: 0 > dev.ath.0.tpc: 0 > dev.ath.0.tpack: 63 > dev.ath.0.tpcts: 63 > dev.ath.0.fftxqmin: 2 > dev.ath.0.fftxqmax: 50 > dev.ath.0.rfsilent: 1 > dev.ath.0.rfkill: 1 > dev.ath.0.monpass: 24 > > # sysctl hw.ath > hw.ath.hal.swba_backoff: 0 > hw.ath.hal.sw_brt: 10 > hw.ath.hal.dma_brt: 2 > hw.ath.hal.version: 0.9.20.3 > hw.ath.txbuf: 200 > hw.ath.rxbuf: 40 > hw.ath.regdomain: 0 > hw.ath.countrycode: 0 > hw.ath.xchanmode: 1 > hw.ath.outdoor: 1 > hw.ath.calibrate: 30 > > From sam at freebsd.org Wed Feb 11 15:48:09 2009 From: sam at freebsd.org (Sam Leffler) Date: Wed Feb 11 15:48:15 2009 Subject: New Atheros card: channel reset error [sorry for posting of not ready message] In-Reply-To: <20090211145145.1b5f5b24@sorrow.ashke.com> References: <16510045949.20090211193347@serebryakov.spb.ru> <20090211145145.1b5f5b24@sorrow.ashke.com> Message-ID: <499363B4.20409@freebsd.org> Your panic on card eject has been fixed in HEAD. That was one of the changes I hoped to backport to RELENG_7 after the hal is brought back. Sam Adam K Kirchhoff wrote: > I get similar errors, but only when trying to connect to a particular > wireless network (at work). I can connect to the one I have at home, > and do not get any errors. I have opened up a pr about it: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=131162 > > In my case, if I then remove the wireless card while the interface is > trying to acquire an IP address, the kernel panics. Are you seeing > something similar? > > Adam > > On Wed, 11 Feb 2009 19:33:47 +0300 > Lev Serebryakov wrote: > > >> Hello, Freebsd-net. >> >> I'm getting this error on every operation with new Atheros MiniPCI >> card: >> >> ath0: ath_chan_set: unable to reset channel 6 (2437 Mhz, flags 0x490 hal flags 0x150), hal status 12 >> >> What does it mean? Maybe, card is broken? >> >> # pciconf -lv >> ath0@pci0:0:17:0: class=0x020000 card=0x1600185f chip=0x001b168c rev=0x01 hdr=0x00 >> vendor = 'Atheros Communications Inc.' >> device = 'AR5006 family 802.11abg Wireless NIC' >> class = network >> subclass = ethernet >> >> # grep ath /var/run/dmesg.boot >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) >> ath0: mem 0xa0060000-0xa006ffff irq 15 at device 17.0 on pci0 >> ath0: [ITHREAD] >> ath0: WARNING: using obsoleted if_watchdog interface >> ath0: Ethernet address: 00:0b:6b:2d:e8:1e >> ath0: mac 10.5 phy 6.1 radio 6.3 >> >> # sysctl dev.ath >> dev.ath.0.%desc: Atheros 5212 >> dev.ath.0.%driver: ath >> dev.ath.0.%location: slot=17 function=0 >> dev.ath.0.%pnpinfo: vendor=0x168c device=0x001b subvendor=0x185f subdevice=0x1600 class=0x020000 >> dev.ath.0.%parent: pci0 >> dev.ath.0.smoothing_rate: 95 >> dev.ath.0.sample_rate: 10 >> dev.ath.0.countrycode: 0 >> dev.ath.0.regdomain: 0 >> dev.ath.0.slottime: 9 >> dev.ath.0.acktimeout: 48 >> dev.ath.0.ctstimeout: 48 >> dev.ath.0.softled: 0 >> dev.ath.0.ledpin: 0 >> dev.ath.0.ledon: 0 >> dev.ath.0.ledidle: 2700 >> dev.ath.0.txantenna: 0 >> dev.ath.0.rxantenna: 2 >> dev.ath.0.diversity: 1 >> dev.ath.0.txintrperiod: 5 >> dev.ath.0.diag: 0 >> dev.ath.0.tpscale: 0 >> dev.ath.0.tpc: 0 >> dev.ath.0.tpack: 63 >> dev.ath.0.tpcts: 63 >> dev.ath.0.fftxqmin: 2 >> dev.ath.0.fftxqmax: 50 >> dev.ath.0.rfsilent: 1 >> dev.ath.0.rfkill: 1 >> dev.ath.0.monpass: 24 >> >> # sysctl hw.ath >> hw.ath.hal.swba_backoff: 0 >> hw.ath.hal.sw_brt: 10 >> hw.ath.hal.dma_brt: 2 >> hw.ath.hal.version: 0.9.20.3 >> hw.ath.txbuf: 200 >> hw.ath.rxbuf: 40 >> hw.ath.regdomain: 0 >> hw.ath.countrycode: 0 >> hw.ath.xchanmode: 1 >> hw.ath.outdoor: 1 >> hw.ath.calibrate: 30 >> >> -- >> // Black Lion AKA Lev Serebryakov >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > > From oberman at es.net Wed Feb 11 16:42:24 2009 From: oberman at es.net (Kevin Oberman) Date: Wed Feb 11 16:42:36 2009 Subject: Support for IPv6 tables in ipfw? In-Reply-To: Your message of "Wed, 11 Feb 2009 23:50:34 +0100." <48EED655-AD6F-4C37-8182-86715F417011@libero.it> Message-ID: <20090212004222.028CF1CC0B@ptavv.es.net> > From: Raffaele De Lorenzo > Date: Wed, 11 Feb 2009 23:50:34 +0100 > > Hi, > I developed with Luigi (as mentor) and Mariano Tortoriello the first > release of ipfw with ipv6 extension. If you and the FreeBSD Community > think that the tables functional is a good feature i can develop it > for IPv6 protocol. Tables are invaluable for several functions. The most important to me is the ability to create a 'block' list that can be easily updated from a program or script. With a table you just need: add 00500 unreach port ip from table 86 to any in your standard configuration and then a script can do: table 22 add 2001:400:14:23::45 to add a system to the list. To do it without tables means finding an available rule and inserting the rule in the main table. I can do it without tables, but it works much better with them. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bruce at cran.org.uk Wed Feb 11 16:52:56 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Wed Feb 11 16:53:03 2009 Subject: IPv6 autoconfiguration fails Message-ID: <20090212005249.10ce416c@gluon> [forwarding from current@] I recently reinstalled -current on my laptop and have started seeing IPv6 autoconfiguration failing. I have two interfaces re0 and ath0: re0 is plugged in and gets an address via DHCP while I'm not using wireless at the moment so ath0 remains unconfigured. However it seems the IPv6 autoconfiguration tries to use ath0 instead of re0. During boot I see: re0: link state changed to UP Starting Network: lo0 re0. No ALTQ support in kernel ALTQ related functions disabled No ALTQ support in kernel ALTQ related functions disabled No ALTQ support in kernel ALTQ related functions disabled pf enabled add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 -> 0 net.inet6.ip6.accept_rtadv: 0 -> 1 get_llflag() failed, anyway I'll try sendmsg on ath0: Can't assign requested address sendmsg on ath0: Can't assign requested address sendmsg on ath0: Can't assign requested address add net fe80::: gateway ::1 add net ff02::: gateway ::1 IPv4 mapped IPv6 address support=NO Waiting 30s for an interface to come up: ...........(re0) ifconfig shows re0 having IPv4 and IPv6 link-local addresses but no autoconfigured address, while I'm running rtadvd on the router which is connected via re0. -- Bruce Cran From lev at serebryakov.spb.ru Wed Feb 11 23:22:59 2009 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Wed Feb 11 23:23:06 2009 Subject: New Atheros card: channel reset error [sorry for posting of not ready message] In-Reply-To: <49936340.10909@freebsd.org> References: <16510045949.20090211193347@serebryakov.spb.ru> <49936340.10909@freebsd.org> Message-ID: <451285611.20090212102250@serebryakov.spb.ru> Hello, Sam. You wrote 12 ??????? 2009 ?., 02:46:08: > So the driver is mis-mapping the channel and causing the hal to reject > the request. If I recall this causes scanning to stop on RELENG_7 so > you'll want to force this channel to not be requested by disabling > dynamic turbo mode. I can't recall how that's done on RELENG_7; consult > ifconfig(8). ifconfig ath0 -dturbo Here is one problem: right after this request I get the same error message again... -- // Black Lion AKA Lev Serebryakov From steve at ibctech.ca Thu Feb 12 06:50:38 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Feb 12 06:50:50 2009 Subject: Support for IPv6 tables in ipfw? In-Reply-To: <48EED655-AD6F-4C37-8182-86715F417011@libero.it> References: <20090211223416.5550A1CC0B@ptavv.es.net> <48EED655-AD6F-4C37-8182-86715F417011@libero.it> Message-ID: <49943732.1060803@ibctech.ca> Raffaele De Lorenzo wrote: > Hi, > I developed with Luigi (as mentor) and Mariano Tortoriello the first > release of ipfw with ipv6 extension. If you and the FreeBSD Community > think that the tables functional is a good feature i can develop it for > IPv6 protocol. I think that tables are extremely functional and valuable, and will test any patches as soon as they are available if you are inclined to implement them for IPv6. Steve From steve at ibctech.ca Thu Feb 12 06:56:41 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Feb 12 06:56:48 2009 Subject: IPv6 autoconfiguration fails In-Reply-To: <20090212005249.10ce416c@gluon> References: <20090212005249.10ce416c@gluon> Message-ID: <4994389D.8050203@ibctech.ca> Bruce Cran wrote: > [forwarding from current@] > > I recently reinstalled -current on my laptop and have started seeing > IPv6 autoconfiguration failing. I have two interfaces re0 and > ath0: re0 is plugged in and gets an address via DHCP while I'm not > using wireless at the moment so ath0 remains unconfigured. However it > seems the IPv6 autoconfiguration tries to use ath0 instead of re0. There is a very similar issue over on -questions. Does it help if you disable rtadv on ath0?: # ndp -i ath0 -- -accept_rtadv Steve From bruce at cran.org.uk Thu Feb 12 07:42:59 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Feb 12 07:43:05 2009 Subject: IPv6 autoconfiguration fails In-Reply-To: <4994389D.8050203@ibctech.ca> References: <20090212005249.10ce416c@gluon> <4994389D.8050203@ibctech.ca> Message-ID: <20090212154251.5742210a@gluon> On Thu, 12 Feb 2009 09:56:29 -0500 Steve Bertrand wrote: > Bruce Cran wrote: > > [forwarding from current@] > > > > I recently reinstalled -current on my laptop and have started seeing > > IPv6 autoconfiguration failing. I have two interfaces re0 and > > ath0: re0 is plugged in and gets an address via DHCP while I'm not > > using wireless at the moment so ath0 remains unconfigured. However > > it seems the IPv6 autoconfiguration tries to use ath0 instead of > > re0. > > There is a very similar issue over on -questions. > > Does it help if you disable rtadv on ath0?: > > # ndp -i ath0 -- -accept_rtadv It didn't help, but your last message on -questions made me realise I'd made the classic mistake of enabling a firewall but not allowing inbound icmp[6] packets. As soon as I'd reloaded the rules things started working again. -- Bruce Cran From steve at ibctech.ca Thu Feb 12 08:07:41 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Feb 12 08:07:47 2009 Subject: IPv6 autoconfiguration fails In-Reply-To: <20090212154251.5742210a@gluon> References: <20090212005249.10ce416c@gluon> <4994389D.8050203@ibctech.ca> <20090212154251.5742210a@gluon> Message-ID: <49944940.2040500@ibctech.ca> Bruce Cran wrote: > On Thu, 12 Feb 2009 09:56:29 -0500 > Steve Bertrand wrote: > >> Bruce Cran wrote: >>> [forwarding from current@] >>> >>> I recently reinstalled -current on my laptop and have started seeing >>> IPv6 autoconfiguration failing. I have two interfaces re0 and >>> ath0: re0 is plugged in and gets an address via DHCP while I'm not >>> using wireless at the moment so ath0 remains unconfigured. However >>> it seems the IPv6 autoconfiguration tries to use ath0 instead of >>> re0. >> There is a very similar issue over on -questions. >> >> Does it help if you disable rtadv on ath0?: >> >> # ndp -i ath0 -- -accept_rtadv > > It didn't help, but your last message on -questions made me realise I'd > made the classic mistake of enabling a firewall but not allowing inbound > icmp[6] packets. As soon as I'd reloaded the rules things started > working again. Good stuff. Just a note that blocking inbound ICMP will break Path MTU discovery, which, if not considered, can be quite difficult to troubleshoot. Cheers, Steve From gavin at FreeBSD.org Thu Feb 12 10:56:32 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Feb 12 10:56:39 2009 Subject: kern/131601: 7-STABLE panic in nat_finalise Message-ID: <200902121856.n1CIuUb6035503@freefall.freebsd.org> Synopsis: 7-STABLE panic in nat_finalise Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Thu Feb 12 18:54:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). PR has a full backtrace and submitter has a core file for further investigation. http://www.freebsd.org/cgi/query-pr.cgi?pr=131601 From sepron at gmail.com Thu Feb 12 11:33:43 2009 From: sepron at gmail.com (Sergey Pronin) Date: Thu Feb 12 11:33:49 2009 Subject: Synopsis: process swi1:net gives 100% CPU usage. Message-ID: Synopsis: process swi1:net gives 100% CPU usage. Not depending on the conditions (no heavy load, not a lot of traffic passing through, not a lot of ng nodes) server stops to work properly. 1) swi1:net gives me 100% CPU usage. 2) server is not responding to icmp echo requests 3) ssh of course not working 4) mpd has an "ngsock" state at the top 5) tasq of the em0 card using 0% of the cpu. 6) rebooting the server helps. What do I have: 3 simillar servers. INTEL S3200SH with Q8200. NIC: 82571EB using default em driver (6.9.6) OS: Freebsd 7.1-RELEASE-p2 Soft: mpd 4.4.1 using netgraph modules, ipfw + dummynet, pf (nat only). PPPoE. Using only em0 card. About 200 vlans. 2000 ng nodes created. About 300-400 simultaneous PPPoE sessions. When error occurs there may be about 100 PPPoE sessions. I'm using tablearg, so there are not a lot of ipfw rules. (About 20) sysctl.conf: net.inet.ip.intr_queue_maxlen=1000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fw.one_pass=1 net.inet.ip.fastforwarding=1 kern.ipc.maxsockbuf=1048576 net.isr.direct=0 #net.inet.ip.portrange.randomized=0 net.inet.tcp.syncookies=1 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 dev.em.0.rx_processing_limit=1024 loader.conf: autoboot_delay="2" kern.ipc.maxpipekva=10000000 vm.kmem_size=512M net.inet.tcp.tcbhashsize=8096 kern.maxusers=512 kern.ipc.nmbclusters=16384 kern.ipc.maxsockets=16384 net.graph.maxalloc=2048 net.graph.maxdgram=1048576 net.graph.recvspace=1048576 hw.em.rxd="512" hw.em.txd="512" And I have the 4th server with the same hardware and software configuration but with FreeBSD 7.1-RELEASE-p1. Everything works fine. Any ideas? Thank you. From bzeeb-lists at lists.zabbadoz.net Fri Feb 13 01:45:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Feb 13 01:45:13 2009 Subject: "The LOR page" is back Message-ID: <20090213092746.R53478@maildrop.int.zabbadoz.net> Hi, in case you find a LOR, want to report it or want to see if it's known or find out more about it... you can go and check "The LOR page" again. It's up on a temporary setup (so in case it's not avail come back a bit later) until I can finally move the web elsewhere. The URL has stayed the same: http://sources.zabbadoz.net/freebsd/lor.html The page has a few instructions and links to further information. You may want to read them before doing anything else to help everybody. Thanks! /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From dreamer.two at gmail.com Fri Feb 13 02:50:04 2009 From: dreamer.two at gmail.com (Vitaly Dodonov) Date: Fri Feb 13 02:50:11 2009 Subject: kern/131310: [panic] 7.1 panics with mpd netgraph interface changes Message-ID: <200902131050.n1DAo2BD072225@freefall.freebsd.org> The following reply was made to PR kern/131310; it has been noted by GNATS. From: Vitaly Dodonov To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/131310: [panic] 7.1 panics with mpd netgraph interface changes Date: Fri, 13 Feb 2009 13:41:50 +0300 i get another panics without mpd and netrgaph, seems it pf related panic first on using my pppoe provider with ppp and second on openvpn restart GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xffffffffdbe96b06 stack pointer = 0x10:0xffffffffdbd3f8a0 frame pointer = 0x10:0xffffffffdbd3f8f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2515 (ppp) trap number = 9 panic: general protection fault cpuid = 0 Uptime: 2h50m5s Physical memory: 4079 MB Dumping 1266 MB: 1251 1235 1219 1203 1187 1171 1155 1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 963 947 931 915 899 883 867 851 835 819 803 787 771 755 739 723 707 691 675 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_pppoe.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_lagg.ko Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/kernel/if_vlan.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_vlan.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_iface.ko Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/ng_ppp.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ppp.ko Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from /boot/kernel/ng_tcpmss.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tcpmss.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff804b4dbb in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff804b5262 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff80788903 in trap_fatal (frame=0xffffff0005f47000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:764 #5 0xffffffff80789455 in trap (frame=0xffffffffdbd3f7f0) at /usr/src/sys/amd64/amd64/trap.c:565 #6 0xffffffff8076ee0e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0xffffffffdbe96b06 in pfi_instance_add (ifp=0xffffff0007801000, net=128, flags=0) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:578 #8 0xffffffffdbe96dd6 in pfi_table_update (kt=0xffffff0046583510, kif=Variable "kif" is not available. ) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:561 #9 0xffffffffdbe9706b in pfi_dynaddr_update (dyn=0xffffff00465d0438) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:543 #10 0xffffffffdbe970be in pfi_kif_update (kif=0xffffff000750d200) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:520 #11 0xffffffffdbe970ec in pfi_kif_update (kif=0xffffff00077c2500) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:525 #12 0xffffffffdbe9715c in pfi_ifaddr_event (arg=Variable "arg" is not available. ) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:942 #13 0xffffffff80589c5c in in_control (so=Variable "so" is not available. ) at /usr/src/sys/netinet/in.c:476 #14 0xffffffff8054d17f in ifioctl (so=0xffffff00962dc000, cmd=2149607705, data=0xffffff007f5be200 "tun0", td=0xffffff0005f47000) at /usr/src/sys/net/if.c:1952 #15 0xffffffff804ec104 in kern_ioctl (td=0xffffff0005f47000, fd=0, com=2149607705, data=0xffffff007f5be200 "tun0") at file.h:268 #16 0xffffffff804ec40a in ioctl (td=0xffffff0005f47000, uap=0xffffffffdbd3fbf0) at /usr/src/sys/kern/sys_generic.c:570 #17 0xffffffff80788f57 in syscall (frame=0xffffffffdbd3fc80) at /usr/src/sys/amd64/amd64/trap.c:907 #18 0xffffffff8076f01b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #19 0x000000080124637c in ?? () Previous frame inner to this frame (corrupt stack?) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xffffffffdbe7db06 stack pointer = 0x10:0xffffffffdbfef650 frame pointer = 0x10:0xffffffffdbfef6a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1802 (openvpn) trap number = 9 panic: general protection fault cpuid = 0 Uptime: 1h7m42s Physical memory: 4079 MB Dumping 1036 MB: 1021 1005 989 973 957 941 925 909 893 877 861 845 829 813 797 781 765 749 733 717 701 685 669 653 637 621 605 589 573 557 541 525 509 493 477 461 445 429 413 397 381 365 349 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_lagg.ko Reading symbols from /boot/kernel/if_vlan.ko...Reading symbols from /boot/kernel/if_vlan.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_vlan.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_pppoe.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_iface.ko Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from /boot/kernel/ng_ppp.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ppp.ko Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from /boot/kernel/ng_tcpmss.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_tcpmss.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff804b4dbb in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff804b5262 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff80788903 in trap_fatal (frame=0xffffff006ef98000, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:764 #5 0xffffffff80789455 in trap (frame=0xffffffffdbfef5a0) at /usr/src/sys/amd64/amd64/trap.c:565 #6 0xffffffff8076ee0e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0xffffffffdbe7db06 in pfi_instance_add (ifp=0xffffff0006883000, net=128, flags=0) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:578 #8 0xffffffffdbe7ddd6 in pfi_table_update (kt=0xffffff0006795000, kif=Variable "kif" is not available. ) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:561 #9 0xffffffffdbe7e06b in pfi_dynaddr_update (dyn=0xffffff0006793ca8) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:543 #10 0xffffffffdbe7e0be in pfi_kif_update (kif=0xffffff0006021500) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:520 #11 0xffffffffdbe7e0ec in pfi_kif_update (kif=0xffffff0006021400) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:525 #12 0xffffffffdbe7e15c in pfi_ifaddr_event (arg=Variable "arg" is not available. ) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:942 #13 0xffffffff80589c5c in in_control (so=Variable "so" is not available. ) at /usr/src/sys/netinet/in.c:476 #14 0xffffffff8054b822 in if_purgeaddrs (ifp=0xffffff0006418800) at /usr/src/sys/net/if.c:684 #15 0xffffffff8055852d in tunclose (dev=Variable "dev" is not available. ) at /usr/src/sys/net/if_tun.c:475 #16 0xffffffff8047cb5c in giant_close (dev=0xffffff00066b3a00, fflag=7, devtype=8192, td=0xffffff006ef98000) at /usr/src/sys/kern/kern_conf.c:374 #17 0xffffffff80442b84 in devfs_close (ap=0xffffffffdbfef950) at /usr/src/sys/fs/devfs/devfs_vnops.c:463 #18 0xffffffff80541022 in vn_close (vp=0xffffff00067f9dc8, flags=7, file_cred=0xffffff0006800d00, td=0xffffff006ef98000) at vnode_if.h:228 #19 0xffffffff805410ca in vn_closefile (fp=0xffffff013a0b3700, td=0xffffff006ef98000) at /usr/src/sys/kern/vfs_vnops.c:867 #20 0xffffffff80441d05 in devfs_close_f (fp=Variable "fp" is not available. ) at /usr/src/sys/fs/devfs/devfs_vnops.c:479 #21 0xffffffff80482291 in fdrop (fp=0xffffff013a0b3700, td=0xffffff006ef98000) at file.h:299 #22 0xffffffff804834d6 in closef (fp=0xffffff013a0b3700, td=0xffffff006ef98000) at /usr/src/sys/kern/kern_descrip.c:2033 #23 0xffffffff80483cf7 in kern_close (td=0xffffff006ef98000, fd=Variable "fd" is not available. ) at /usr/src/sys/kern/kern_descrip.c:1125 #24 0xffffffff80788f57 in syscall (frame=0xffffffffdbfefc80) at /usr/src/sys/amd64/amd64/trap.c:907 #25 0xffffffff8076f01b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #26 0x0000000800c5c39c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From linimon at FreeBSD.org Fri Feb 13 06:28:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Feb 13 06:28:28 2009 Subject: bin/131567: [socket] [patch] Update for regression/sockets/unix_cmsg Message-ID: <200902131428.n1DESLHn038959@freefall.freebsd.org> Old Synopsis: [patch] Update for regression/sockets/unix_cmsg New Synopsis: [socket] [patch] Update for regression/sockets/unix_cmsg Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 13 14:27:57 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131567 From linimon at FreeBSD.org Fri Feb 13 06:30:19 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Feb 13 06:30:26 2009 Subject: kern/131601: [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) Message-ID: <200902131430.n1DEUED7040530@freefall.freebsd.org> Old Synopsis: 7-STABLE panic in nat_finalise (tcp=0) New Synopsis: [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) Responsible-Changed-From-To: freebsd-net->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 13 14:30:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131601 From fernando at gont.com.ar Fri Feb 13 08:11:13 2009 From: fernando at gont.com.ar (Fernando Gont) Date: Fri Feb 13 08:11:20 2009 Subject: Security Assessment of the Transmission Control Protocol (TCP) Message-ID: <4995987E.7010000@gont.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, folks, I thought this one might be of your interest. The United Kingdom's Centre for the Protection of National Infrastructure has just released the document "Security Assessment of the Transmission Control Protocol (TCP)", on which I have had the pleasure to work during the last few years. The motivation to produce this document is explained in the Preface of the document as follows: - ---- cut here ---- The TCP/IP protocol suite was conceived in an environment that was quite different from the hostile environment they currently operate in. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that to some extent, the current world's economy depends on them. While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications. While the Internet technology evolved since it early inception, the Internet?s building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in some protocol implementations, affecting only a reduced number of systems, while others were based in flaws in the protocols themselves, affecting virtually every existing implementation. Even in the last couple of years, researchers were still working on security problems in the core protocols. The discovery of vulnerabilities in the TCP/IP protocol suite usually led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats and the best mitigations known at the time the reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread among a large number of documents, which are sometimes difficult to identify. For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force). This basically led to a situation in which ?known? security problems have not always been addressed by all vendors. In addition, in many cases vendors have implemented quick ?fixes? to the identified vulnerabilities without a careful analysis of their effectiveness and their impact on interoperability. Producing a secure TCP/IP implementation nowadays is a very difficult task, in part because of the lack of a single document that serves as a security roadmap for the protocols. Implementers are faced with the hard task of identifying relevant documentation and differentiating between that which provides correct advice, and that which provides misleading advice based on inaccurate or wrong assumptions. There is a clear need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the existing vulnerabilities, discusses the possible countermeasures, and analyses their respective effectiveness. This document is the result of a security assessment of the IETF specifications of the Transmission Control Protocol (TCP), from a security point of view. Possible threats are identified and, where possible, countermeasures are proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not aim to be the final word on the security aspects of TCP. On the contrary, it aims to raise awareness about a number of TCP vulnerabilities that have been faced in the past, those that are currently being faced, and some of those that we may still have to deal with in the future. Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new vulnerabilities are discovered. - ---- cut here ---- The document is available at CPNI's web site: http://www.cpni.gov.uk/Products/technicalnotes/Feb-09-security-assessment-TCP.aspx Additionally, I have posted a copy of the document on my personal web site: http://www.gont.com.ar Any comments will be more than welcome. Kind regards, - -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBCAAGBQJJlZh7AAoJEJbuqe/Qdv/xUroIAImfb6T2f0LC8iWMIIShZV9P B8tmkfJYGUdhnHjTAszuMmwQ6lsZaQ6MPsOwUeYpoCwzsLoHKn1MqmmGuduI+1wy UlYIQIS+BaWrNm+Zsk7wXpPSgSgAbNlX8gbp+nXWbrqcpHccXIke4bi4NVv1gdNZ R3IrHJ+aZ7bUk/PZj2xLEWfol1OR18Z5IY6QxyCPNnLDt9TjSK1xNGkyACXakknj sr6YGPiycnISblN7NELccsKz5ozc6i+qeBN3XsYMp5BWUDMLZLUpjQnm13FxPktf w+nQ2wKXHiO2/nsgFz+PpS3lYJWtT1IXMSsAWivqjGtXiO2aCZWA+H+vqVMMt1U= =njnp -----END PGP SIGNATURE----- From ikob at ni.aist.go.jp Fri Feb 13 10:20:03 2009 From: ikob at ni.aist.go.jp (Katsushi Kobayashi) Date: Fri Feb 13 10:20:10 2009 Subject: kern/122551: [bge] Broadcom 5715S no carrier on HP BL460c blade using 6.3-RELEASE Message-ID: <200902131820.n1DIK23S011293@freefall.freebsd.org> The following reply was made to PR kern/122551; it has been noted by GNATS. From: Katsushi Kobayashi To: bug-followup@FreeBSD.org, greg@laaco.net Cc: Subject: Re: kern/122551: [bge] Broadcom 5715S no carrier on HP BL460c blade using 6.3-RELEASE Date: Sat, 14 Feb 2009 02:54:39 +0900 --Apple-Mail-6-689925422 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, We have tried FreeBSD 7.1 on our new HP blade server as BL260c G5 accommodating GbE i/f with Broafcom 5715S chipset. Unfortunately, the network interface did not come UP as the similar situation with PR122551. We resolved the trouble with the attached patch. Our device attach messages and PCI info are also attached. I hope this patch will help you. pciconf -lv pcib1@pci0:0:2:0: class=0x060400 card=0x00000000 chip=0x65e28086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe x4 Port 2' class = bridge subclass = PCI-PCI pcib3@pci0:0:3:0: class=0x060400 card=0x00000000 chip=0x65e38086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe x4 Port 3' class = bridge subclass = PCI-PCI pcib4@pci0:0:4:0: class=0x060400 card=0x00000000 chip=0x65e48086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe x4 Port 4' class = bridge subclass = PCI-PCI pcib5@pci0:0:5:0: class=0x060400 card=0x00000000 chip=0x65e58086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe x4 Port 5' class = bridge subclass = PCI-PCI pcib6@pci0:0:6:0: class=0x060400 card=0x00000000 chip=0x65f98086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe x8 Port 6-7' class = bridge subclass = PCI-PCI pcib7@pci0:0:7:0: class=0x060400 card=0x00000000 chip=0x65e78086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe x4 Port 7' class = bridge subclass = PCI-PCI pcib8@pci0:0:30:0: class=0x060401 card=0x31fe103c chip=0x244e8086 rev=0x92 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/4/5/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI pcib2@pci0:2:0:0: class=0x060400 card=0x00000000 chip=0x01031166 rev=0xb5 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'BCM5715 Broadcom dual gigabit, pci bridge' class = bridge subclass = PCI-PCI bge0@pci0:3:4:0: class=0x020000 card=0x703c103c chip=0x167914e4 rev=0xa3 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme 5715S Gigabit Ethernet' class = network subclass = ethernet bge1@pci0:3:4:1: class=0x020000 card=0x703c103c chip=0x167914e4 rev=0xa3 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme 5715S Gigabit Ethernet' class = network subclass = ethernet pcib2: at device 0.0 on pci2 pci3: on pcib2 bge0: mem 0xfdff0000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 16 at device 4.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:22:64:04:53:ca bge0: [ITHREAD] bge1: mem 0xfdfd0000-0xfdfdffff,0xfdfc0000-0xfdfcffff irq 17 at device 4.1 on pci3 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:22:64:04:53:cb bge1: [ITHREAD] ---- Katsushi Kobayashi --Apple-Mail-6-689925422 Content-Disposition: attachment; filename=diff.txt Content-Type: text/plain; x-unix-mode=0644; name="diff.txt" Content-Transfer-Encoding: 7bit Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 1) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -2533,6 +2533,9 @@ #define BGE_FLAG_JUMBO 0x00000002 #define BGE_FLAG_WIRESPEED 0x00000004 #define BGE_FLAG_EADDR 0x00000008 + +#define BGE_FLAG_MIISERDES 0x00000010 + #define BGE_FLAG_MSI 0x00000100 #define BGE_FLAG_PCIX 0x00000200 #define BGE_FLAG_PCIE 0x00000400 Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 1) +++ sys/dev/bge/if_bge.c (working copy) @@ -838,8 +838,11 @@ mii = device_get_softc(sc->bge_miibus); BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_PORTMODE); - if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T) + if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T || + (sc->bge_flags & BGE_FLAG_MIISERDES)) + { BGE_SETBIT(sc, BGE_MAC_MODE, BGE_PORTMODE_GMII); + } else BGE_SETBIT(sc, BGE_MAC_MODE, BGE_PORTMODE_MII); @@ -1719,8 +1722,8 @@ BGE_MACMODE_RXDMA_ENB | BGE_MACMODE_RX_STATS_CLEAR | BGE_MACMODE_TX_STATS_CLEAR | BGE_MACMODE_RX_STATS_ENB | BGE_MACMODE_TX_STATS_ENB | BGE_MACMODE_FRMHDR_DMA_ENB | - ((sc->bge_flags & BGE_FLAG_TBI) ? - BGE_PORTMODE_TBI : BGE_PORTMODE_MII)); + ((sc->bge_flags & BGE_FLAG_TBI) ? + BGE_PORTMODE_TBI : (sc->bge_flags & BGE_FLAG_MIISERDES ) ? BGE_PORTMODE_GMII : BGE_PORTMODE_MII)); /* Set misc. local control, enable interrupts on attentions */ CSR_WRITE_4(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_ONATTN); @@ -2654,7 +2657,13 @@ } if ((hwcfg & BGE_HWCFG_MEDIA) == BGE_MEDIA_FIBER) - sc->bge_flags |= BGE_FLAG_TBI; + { + if(sc->bge_flags & BGE_FLAG_5714_FAMILY){ + sc->bge_flags |= BGE_FLAG_MIISERDES; + } else { + sc->bge_flags |= BGE_FLAG_TBI; + } + } /* The SysKonnect SK-9D41 is a 1000baseSX card. */ if ((pci_read_config(dev, BGE_PCI_SUBSYS, 4) >> 16) == SK_SUBSYSID_9D41) @@ -3267,6 +3276,7 @@ if (cmd == POLL_AND_CHECK_STATUS) if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || + (sc->bge_flags & BGE_FLAG_MIISERDES) || sc->bge_link_evt || (sc->bge_flags & BGE_FLAG_TBI)) bge_link_upd(sc); Index: sys/dev/mii/brgphy.c =================================================================== --- sys/dev/mii/brgphy.c (revision 1) +++ sys/dev/mii/brgphy.c (working copy) @@ -540,10 +540,21 @@ mii->mii_media_active |= IFM_NONE; break; } } + else if(bmsr & BRGPHY_BMSR_LINK){ + mii->mii_media_status |= IFM_ACTIVE; + } } else { /* If serdes link is up, get the negotiated speed/duplex. */ if (bmsr & BRGPHY_BMSR_LINK) { mii->mii_media_status |= IFM_ACTIVE; + /* If autoneg enabled, read negotiated duplex settings */ + if (bmcr & BRGPHY_BMCR_AUTOEN) { + val = PHY_READ(sc, BRGPHY_SERDES_ANAR) & PHY_READ(sc, BRGPHY_SERDES_ANLPAR); + if (val & BRGPHY_SERDES_ANAR_FDX) + mii->mii_media_active |= IFM_FDX; + else + mii->mii_media_active |= IFM_HDX; + } } /* Check the link speed/duplex based on the PHY type. */ @@ -619,6 +630,7 @@ /* Pause capability advertisement (pause capable & asymmetric) */ PHY_WRITE(sc, BRGPHY_MII_ANAR, BMSR_MEDIA_TO_ANAR(sc->mii_capabilities) | ANAR_CSMA | + ANAR_X_FD | ANAR_X_HD | ANAR_FC | 0x0800 | BRGPHY_ANAR_ASP | BRGPHY_ANAR_PC); } else { PHY_WRITE(sc, BRGPHY_SERDES_ANAR, BRGPHY_SERDES_ANAR_FDX | --Apple-Mail-6-689925422 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-6-689925422-- From jwm-freebsd-net at skepsi.net Sat Feb 14 14:34:01 2009 From: jwm-freebsd-net at skepsi.net (Jason Morgan) Date: Sat Feb 14 14:34:09 2009 Subject: WPA-EAP (ath driver): trouble maintaining connection Message-ID: <20090214222342.GA45141@skepsi.net> Hello, I have been having trouble maintaining a wireless connection at my university, which uses the WPA-EAP protocol. I have played with my wpa_supplicant.conf file, but haven't found anything that works. I don't seems to have any trouble at home using a Linksys AP and WPA-PSK. I was hoping someone here could point me in the right direction---I am not very familiar with WPA and wireless networking. Error messages and other relevant information below. (You will notice that I lose connection every 5-10 minutes.) Thanks in advance. $ uname -a FreeBSD sofie.skepsi.net 7.1-STABLE FreeBSD 7.1-STABLE #3: Sun Feb 1 13:00:56 EST 2009 root@sofie.skepsi.net:/usr/obj/usr/src/sys/SOFIE amd64 $ cat /etc/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel eapol_version=1 ap_scan=1 fast_reauth=1 network={ ssid="osuwireless" scan_ssid=1 key_mgmt=WPA-EAP eap=PEAP identity="xxx" password="xxx" phase1="peaplabel=0" phase2="auth-MSCHAPV2" priority=1 } $ cat /etc/dhclient.conf # ath0 interface "ath0" { request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name; require subnet-mask, domain-name-servers; } $ cat /var/log/messages Feb 14 15:50:09 sofie kernel: ath0: link state changed to DOWN Feb 14 15:50:09 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:58:04:00 (SSID='osuwireless' freq=2437 MHz) Feb 14 15:50:09 sofie wpa_supplicant[403]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Feb 14 15:50:19 sofie wpa_supplicant[403]: Authentication with 00:00:00:00:00:00 timed out. Feb 14 15:50:27 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:58:02:80 (SSID='osuwireless' freq=2437 MHz) Feb 14 15:50:27 sofie wpa_supplicant[403]: Association request to the driver failed Feb 14 15:50:32 sofie wpa_supplicant[403]: Authentication with 00:0b:86:58:02:80 timed out. Feb 14 15:50:39 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:5d:3a:40 (SSID='osuwireless' freq=2412 MHz) Feb 14 15:50:40 sofie kernel: ath0: link state changed to UP Feb 14 15:50:40 sofie wpa_supplicant[403]: Associated with 00:0b:86:5d:3a:40 Feb 14 15:50:40 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-STARTED EAP authentication started Feb 14 15:50:40 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Feb 14 15:50:40 sofie wpa_supplicant[403]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Feb 14 15:50:40 sofie wpa_supplicant[403]: EAP-MSCHAPV2: Authentication succeeded Feb 14 15:50:40 sofie wpa_supplicant[403]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Feb 14 15:50:40 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Feb 14 15:50:40 sofie wpa_supplicant[403]: WPA: Key negotiation completed with 00:0b:86:5d:3a:40 [PTK=TKIP GTK=TKIP] Feb 14 15:50:40 sofie wpa_supplicant[403]: CTRL-EVENT-CONNECTED - Connection to 00:0b:86:5d:3a:40 completed (reauth) [id=1 id_str=] Feb 14 15:50:40 sofie dhclient: New IP Address (ath0): 128.146.115.38 Feb 14 15:50:40 sofie dhclient: New Subnet Mask (ath0): 255.255.255.0 Feb 14 15:50:40 sofie dhclient: New Broadcast Address (ath0): 128.146.115.255 Feb 14 15:50:40 sofie dhclient: New Routers (ath0): 128.146.115.1 Feb 14 15:55:48 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:58:03:e0 (SSID='osuwireless' freq=2412 MHz) Feb 14 15:55:48 sofie kernel: ath0: link state changed to DOWN Feb 14 15:55:48 sofie wpa_supplicant[403]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Feb 14 15:55:58 sofie wpa_supplicant[403]: Authentication with 00:00:00:00:00:00 timed out. Feb 14 15:56:06 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:58:04:00 (SSID='osuwireless' freq=2437 MHz) Feb 14 15:56:16 sofie wpa_supplicant[403]: Authentication with 00:0b:86:58:04:00 timed out. Feb 14 15:56:23 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:58:02:80 (SSID='osuwireless' freq=2437 MHz) Feb 14 15:56:23 sofie wpa_supplicant[403]: Association request to the driver failed Feb 14 15:56:28 sofie wpa_supplicant[403]: Authentication with 00:0b:86:58:02:80 timed out. Feb 14 15:56:36 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:5d:02:c0 (SSID='osuwireless' freq=2437 MHz) Feb 14 15:56:36 sofie kernel: ath0: link state changed to UP Feb 14 15:56:36 sofie wpa_supplicant[403]: Associated with 00:0b:86:5d:02:c0 Feb 14 15:56:36 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Feb 14 15:56:36 sofie wpa_supplicant[403]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Feb 14 15:56:43 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Feb 14 15:57:14 sofie last message repeated 6 times Feb 14 15:57:18 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-STARTED EAP authentication started Feb 14 15:57:18 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Feb 14 15:57:18 sofie wpa_supplicant[403]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Feb 14 15:57:18 sofie wpa_supplicant[403]: EAP-MSCHAPV2: Authentication succeeded Feb 14 15:57:18 sofie wpa_supplicant[403]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Feb 14 15:57:18 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Feb 14 15:57:28 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Feb 14 15:57:29 sofie kernel: ath0: link state changed to DOWN Feb 14 15:57:29 sofie wpa_supplicant[403]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Feb 14 15:57:37 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:5d:02:c0 (SSID='osuwireless' freq=2437 MHz) Feb 14 15:57:37 sofie kernel: ath0: link state changed to UP Feb 14 15:57:37 sofie wpa_supplicant[403]: Associated with 00:0b:86:5d:02:c0 Feb 14 15:57:37 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-STARTED EAP authentication started Feb 14 15:57:37 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Feb 14 15:57:37 sofie wpa_supplicant[403]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Feb 14 15:57:37 sofie wpa_supplicant[403]: EAP-MSCHAPV2: Authentication succeeded Feb 14 15:57:37 sofie wpa_supplicant[403]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Feb 14 15:57:37 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Feb 14 15:57:41 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Feb 14 15:57:41 sofie kernel: ath0: link state changed to DOWN Feb 14 15:57:41 sofie wpa_supplicant[403]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Feb 14 15:57:49 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:58:03:e0 (SSID='osuwireless' freq=2412 MHz) Feb 14 15:57:49 sofie wpa_supplicant[403]: Association request to the driver failed Feb 14 15:57:54 sofie wpa_supplicant[403]: Authentication with 00:0b:86:58:03:e0 timed out. Feb 14 15:57:58 sofie dhclient: New IP Address (ath0): 128.146.115.38 Feb 14 15:57:58 sofie dhclient: New Subnet Mask (ath0): 255.255.255.0 Feb 14 15:57:58 sofie dhclient: New Broadcast Address (ath0): 128.146.115.255 Feb 14 15:57:58 sofie dhclient: New Routers (ath0): 128.146.115.1 Feb 14 15:57:59 sofie dhclient: New Routers (ath0): 128.146.115.1 Feb 14 15:58:01 sofie wpa_supplicant[403]: Trying to associate with 00:0b:86:58:03:80 (SSID='osuwireless' freq=2412 MHz) Feb 14 15:58:01 sofie kernel: ath0: link state changed to UP Feb 14 15:58:01 sofie wpa_supplicant[403]: Associated with 00:0b:86:58:03:80 Feb 14 15:58:01 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-STARTED EAP authentication started Feb 14 15:58:06 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Feb 14 15:58:06 sofie wpa_supplicant[403]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Feb 14 15:58:06 sofie wpa_supplicant[403]: EAP-MSCHAPV2: Authentication succeeded Feb 14 15:58:06 sofie wpa_supplicant[403]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Feb 14 15:58:06 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Feb 14 15:58:06 sofie wpa_supplicant[403]: WPA: Key negotiation completed with 00:0b:86:58:03:80 [PTK=TKIP GTK=TKIP] Feb 14 15:58:06 sofie wpa_supplicant[403]: CTRL-EVENT-CONNECTED - Connection to 00:0b:86:58:03:80 completed (reauth) [id=1 id_str=] Feb 14 15:58:25 sofie dhclient: New IP Address (ath0): 128.146.115.38 Feb 14 15:58:25 sofie dhclient: New Subnet Mask (ath0): 255.255.255.0 Feb 14 15:58:25 sofie dhclient: New Broadcast Address (ath0): 128.146.115.255 Feb 14 15:58:25 sofie dhclient: New Routers (ath0): 128.146.115.1 Feb 14 16:03:34 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Feb 14 16:06:56 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Feb 14 16:06:57 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Please let me know if additional information would be helpful. Cheers, ~Jason -- ~ Jason Morgan From customer.alert at bankofbaroda.com Sun Feb 15 16:46:40 2009 From: customer.alert at bankofbaroda.com (Bank of Baroda.) Date: Sun Feb 15 16:46:48 2009 Subject: BOB Alert: Please Read This** Message-ID: <20090216001811.68FDF781C0B@mailadmin.rpsnet.cz> [1]Bank of Baroda [2][USEMAP:weblinks_india.gif] [3]Click to register for regular updates Dear Baroda Customer, We recently reviewed your account because we know your past experience, we are to protect your account from being accessed by an unauthorized third party. Therefore, as a preventative measure, we have temporarily limited access to sensitive account features. To restore your account access, we need you to confirm your identity, to do so click the secure link below and proceed to verify your information: [4]http://bobibanking.com Important Notice You are strictly advised to match your sensitive details correctly to avoid further complications. Thank for Banking with Us. Bank of Baroda Online Customer Service [brown1.gif] [5]Powered by Emovez © 2008 Bank of Baroda. All rights reserved. [6]Disclaimer For optimum view of this site you must have IE 5.0 and 1024 by 768 pixels References 1. http://www.bankofbaroda.co.in/ 2. LYNXIMGMAP:file://localhost/tmp/tmpd99Mng.html#Map 3. file://localhost/register.asp 4. http://www.mynettransact.com/baroda.php?bank=www.bankofbaroda.com 5. http://www.e-movez.com/ 6. file://localhost/disclaimer.asp From sat at freebsd.org Sun Feb 15 19:04:43 2009 From: sat at freebsd.org (=?Windows-1251?B?wuvg5A==?=) Date: Sun Feb 15 19:05:26 2009 Subject: =?windows-1251?b?z/Du5ODsIPHx++vq6CDxIPHg6fLu4iDt4CBuYXJvZC5y?= =?windows-1251?q?u?= Message-ID: <20090216024247.34901209396@smtp3.powertech.no> ?????? ????????? ?????? ? ??????: [1]http://holodnoeleto.narod.ru ??4 ??? 200 [2]http://christystudio.narod.ru ??0 ??? 300 [3]http://larinaksusha.narod.ru ??3 ??? 120 [4]http://via-gra1.narod.ru ??0 ??? 325 [5]http://zoostation.narod.ru ??2 ??? 300 ????????? ???????? ????????????? ??????????????. ICQ 407484954 References 1. http://holodnoeleto.narod.ru/ 2. http://christystudio.narod.ru/ 3. http://larinaksusha.narod.ru/ 4. http://via-gra1.narod.ru/ 5. http://zoostation.narod.ru/ From az at FreeBSD.org Sun Feb 15 22:33:46 2009 From: az at FreeBSD.org (az@FreeBSD.org) Date: Sun Feb 15 22:33:52 2009 Subject: kern/106974: [bge] packet loose and linkup problem Message-ID: <200902160633.n1G6XjvN056435@freefall.freebsd.org> Synopsis: [bge] packet loose and linkup problem State-Changed-From-To: open->closed State-Changed-By: az State-Changed-When: Mon Feb 16 06:33:44 UTC 2009 State-Changed-Why: As originator close this PR, since i can not check this situation on newest releases. http://www.freebsd.org/cgi/query-pr.cgi?pr=106974 From linimon at FreeBSD.org Mon Feb 16 01:53:44 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Feb 16 01:53:50 2009 Subject: kern/131738: [re] re0: watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200902160953.n1G9riqj039216@freefall.freebsd.org> Synopsis: [re] re0: watchdog timeout (missed Tx interrupts) -- recovering Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 16 09:53:32 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131738 From bugmaster at FreeBSD.org Mon Feb 16 03:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 16 03:08:42 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200902161106.n1GB6tRg096203@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131738 net [re] re0: watchdog timeout (missed Tx interrupts) -- r o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131310 net [panic] 7.1 panics with mpd netgraph interface changes o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw o kern/130846 net [vge] vge0 not autonegotiating to 1000baseTX full dupl o kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130652 net [kernel] [patch] Possible deadlock in rt_check() (sys/ o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R f kern/130605 net [tcp] Certain hardware produces "Network is unreachabl o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100839 net [txp] txp driver inconsistently stops working when the o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/89876 net [txp] [patch] txp driver doesn't work with latest firm f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 259 problems total. From prt at prt.org Mon Feb 16 04:23:21 2009 From: prt at prt.org (Paul Thornton) Date: Mon Feb 16 04:23:28 2009 Subject: ipfw problems using divert and fwd at the same time with 6.3-release Message-ID: <49995AB5.50200@prt.org> Hi folks, I'm having trouble using NAT and forward in the same ipfw ruleset. It appears that the forward "wins" over the NAT regardless of ordering in the ipwf ruleset. I'm hoping that I'm missing something obvious; but is there a way to use these two together? Some background - I'm testing in the lab a potential setup to provide limited network access to a few subnets in 10.X address space, but if you aren't going to an "approved" address then you get forwarded to a web page running on port 8000 on the same box. This box is running 6.3-RELEASE-p9 and has two em interfaces. In this setup, 10.81.0.0/16 are my subnets. They are presented to the machine as a bunch of VLANs physically on em1, one /24 subnet per VLAN. The machine also does DHCP and DNS for each of these VLANs, and is the default gateway. em0 is the external IP address for the machine, currently 192.91.199.5 The machine has no problem accessing the 'net. If I remove the "clever" divert rules and the fwd rule, and make it a vanilla NAT setup, the client has no problem accessing the 'net. In this setup, I expect to be able to browse to www.prt.org (on 217.65.161.4) and that a machine in the 10.81.129.0/24 subnet has unrestricted NATted access to the 'net. Any other attempt at browsing should hit the forward and display the "no access" page from the server on the gateway machine. Using the following ruleset: > [root@xrg1 /var/tmp]# ipfw show > 00010 0 0 allow ip from any to any via lo0 > 00020 0 0 deny ip from any to 127.0.0.1 > 00022 0 0 deny ip from 127.0.0.1 to any > 00050 0 0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68 > 00052 0 0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68 > 00054 0 0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68 > 00056 0 0 allow udp from 10.81.0.0/16 to me dst-port 53 > 00058 0 0 allow udp from me 53 to 10.81.0.0/16 > 00060 0 0 allow icmp from 10.81.0.0/16 to me > 00062 0 0 allow icmp from me to 10.81.0.0/16 > 00100 0 0 allow ip from 192.91.199.5 to any > 02000 0 0 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 80 via em0 > 05000 0 0 divert 8668 ip from 10.81.129.0/24 to any via em0 > 06000 0 0 divert 8668 ip from any to me via em0 > 08000 0 0 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80 > 32000 0 0 allow ip from any to any If I browse "www.prt.org" on the client machine (10.81.2.246) I hit the fwd rule and I get my "Sorry you can't view this" webpage from the local server, and neither of the NAT rules are hit. (DNS on the client correctly resolves to 217.65.161.4) : > [root@xrg1 /var/tmp]# ipfw show > 00010 0 0 allow ip from any to any via lo0 > 00020 0 0 deny ip from any to 127.0.0.1 > 00022 0 0 deny ip from 127.0.0.1 to any > 00050 0 0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68 > 00052 0 0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68 > 00054 0 0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68 > 00056 2 119 allow udp from 10.81.0.0/16 to me dst-port 53 > 00058 2 356 allow udp from me 53 to 10.81.0.0/16 > 00060 0 0 allow icmp from 10.81.0.0/16 to me > 00062 0 0 allow icmp from me to 10.81.0.0/16 > 00100 3 214 allow ip from 192.91.199.5 to any > 02000 0 0 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 80 via em0 > 05000 0 0 divert 8668 ip from 10.81.129.0/24 to any via em0 > 06000 3 601 divert 8668 ip from any to me via em0 > 08000 43 4796 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80 > 32000 58 55935 allow ip from any to any If I remove rule 8000, then I can browse to www.prt.org as expected, and I hit the divert rules: > 00010 0 0 allow ip from any to any via lo0 > 00020 0 0 deny ip from any to 127.0.0.1 > 00022 0 0 deny ip from 127.0.0.1 to any > 00050 0 0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68 > 00052 0 0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68 > 00054 0 0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68 > 00056 7 460 allow udp from 10.81.0.0/16 to me dst-port 53 > 00058 7 1247 allow udp from me 53 to 10.81.0.0/16 > 00060 0 0 allow icmp from 10.81.0.0/16 to me > 00062 0 0 allow icmp from me to 10.81.0.0/16 > 00100 45 3375 allow ip from 192.91.199.5 to any > 02000 38 5096 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 80 via em0 > 05000 0 0 divert 8668 ip from 10.81.129.0/24 to any via em0 > 06000 75 37498 divert 8668 ip from any to me via em0 > 32000 273 142906 allow ip from any to any The natd config is trivial - I'm just launching it with: natd -port 8668 -same_ports -verbose interface em0 Does anyone have any ideas? I've spent the whole weekend trying various things (like extra permits of the "special" traffic before the fwd line) but it makes no difference - the fwd still wins over everything. Many thanks, Paul. From rwatson at FreeBSD.org Mon Feb 16 04:48:02 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Feb 16 04:48:10 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed (was: Re: Wiki page for non-MPSAFE network stack de-orbit scheduling) In-Reply-To: <20080526110543.J26343@fledge.watson.org> References: <20080526110543.J26343@fledge.watson.org> Message-ID: (Bcc to arch@) On Mon, 26 May 2008, Robert Watson wrote: > Just to keep track of things: > > http://wiki.freebsd.org/NONMPSAFE_DEORBIT Delayed by about six months, the merge and switch to the new USB stack in 8.x means that we're now fairly close to being able to pick up this project again. The goal remains to eliminate IFF_NEEDSGIANT, which is (mostly) the last piece of non-MPSAFE compatibility infrastructure in the network stack in -CURRENT. I removed support for non-MPSAFE network protocols before 7.0, and this is the support for non-MPSAFE network device drivers. As of the current moment in HEAD, the following drivers are flagged wth IFF_NEEDSGIANT: General network device drivers that still require Giant: if_ar if_ray if_sl if_sr Old USB network device drivers: if_axe if_cdce if_cue if_kue if_rue if_rum if_udav if_upgt if_ural if_urtw if_zyd Network device drivers intimately tangled with the old TTY code: if_cx if_ppp lf_sl A network device driver that appears to conditionally use IFF_NEEDSGIANT for the purposes of (sometimes) interacting with the old USB code: if_ndis The following schedule is proposed, assuming nothing goes horribly wrong with the new USB code in the next few weeks, and remaining nits relating to USB network and 802.11 drivers are handled: 16 February 2009 HEADS UP to lists (this e-mail) 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x In the next couple of weeks, I'd like to resolve the status of (and eliminate) the if_ndis conditional use of IFF_NEEDSGIANT. There's also a chance that if_sl will get updated by Ed and myself to work with the new locking and TTY world orders -- the lock is easy, but the TTY update takes a bit of work. Perhaps someone will feel moved to do this for if_ppp and possibly if_cx as well. Robert N M Watson Computer Laboratory University of Cambridge From bruce at cran.org.uk Mon Feb 16 05:00:07 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Mon Feb 16 05:00:15 2009 Subject: kern/131738: [re] re0: watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200902161300.n1GD06XR085119@freefall.freebsd.org> The following reply was made to PR kern/131738; it has been noted by GNATS. From: Bruce Cran To: Trevor Roydhouse Cc: bug-followup@FreeBSD.org Subject: Re: kern/131738: [re] re0: watchdog timeout (missed Tx interrupts) -- recovering Date: Mon, 16 Feb 2009 12:53:03 +0000 I also saw this message recently on my laptop which runs 8-CURRENT (20090205); the hardware is: re0: port 0x2000-0x20ff mem 0xd1010000-0xd1010fff,0xd1000000-0xd100ffff irq 19 at device 0.0 on pci10 re0: Chip rev. 0x24800000 re0: MAC rev. 0x00000000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 00:1e:ec:f5:fd:4f re0: [FILTER] I'm connected to the Internet using 17Mb ADSL. -- Bruce Cran From julian at elischer.org Mon Feb 16 15:47:14 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Feb 16 15:47:20 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed In-Reply-To: References: <20080526110543.J26343@fledge.watson.org> Message-ID: <4999F7F9.4030204@elischer.org> Robert Watson wrote: > > (Bcc to arch@) > > On Mon, 26 May 2008, Robert Watson wrote: > >> Just to keep track of things: >> >> http://wiki.freebsd.org/NONMPSAFE_DEORBIT > > Delayed by about six months, the merge and switch to the new USB stack > in 8.x means that we're now fairly close to being able to pick up this > project again. The goal remains to eliminate IFF_NEEDSGIANT, which is > (mostly) the last piece of non-MPSAFE compatibility infrastructure in > the network stack in -CURRENT. I removed support for non-MPSAFE network > protocols before 7.0, and this is the support for non-MPSAFE network > device drivers. As of the current moment in HEAD, the following drivers > are flagged wth IFF_NEEDSGIANT: > > General network device drivers that still require Giant: > > if_ar > if_ray > if_sl > if_sr if_sr and if_ar are really simple and could probably be converted "trivially".. especially if their netgraph code is used. however I wonder if anyone still has that hardware (they are drivers for two sync serial cards). John Hay must have had some when he wrote the driver... > > Old USB network device drivers: > > if_axe > if_cdce > if_cue > if_kue > if_rue > if_rum > if_udav > if_upgt > if_ural > if_urtw > if_zyd > > Network device drivers intimately tangled with the old TTY code: > > if_cx > if_ppp > lf_sl > > A network device driver that appears to conditionally use IFF_NEEDSGIANT > for the purposes of (sometimes) interacting with the old USB code: > > if_ndis > > The following schedule is proposed, assuming nothing goes horribly wrong > with the new USB code in the next few weeks, and remaining nits relating > to USB network and 802.11 drivers are handled: > > 16 February 2009 HEADS UP to lists (this e-mail) > 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x > 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x > > In the next couple of weeks, I'd like to resolve the status of (and > eliminate) the if_ndis conditional use of IFF_NEEDSGIANT. There's also > a chance that if_sl will get updated by Ed and myself to work with the > new locking and TTY world orders -- the lock is easy, but the TTY update > takes a bit of work. Perhaps someone will feel moved to do this for > if_ppp and possibly if_cx as well. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From yongari at FreeBSD.org Mon Feb 16 16:01:15 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Mon Feb 16 16:01:21 2009 Subject: kern/131738: [re] re0: watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200902170001.n1H01ES5093237@freefall.freebsd.org> Synopsis: [re] re0: watchdog timeout (missed Tx interrupts) -- recovering State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Feb 16 23:59:15 UTC 2009 State-Changed-Why: Would you try latest re(4) in HEAD(r188474)? Copying if_re.c, if_rl.c and if_rlreg.h from HEAD to 7-stable is enough to test this. Btw, the watchdog timeout is not real, it just indicates missing Tx completion interrupt. Otherwise you would have seen link state change message as watchdog involves resetting controller(e.g You can safely ignore this). Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Feb 16 23:59:15 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=131738 From imb at protected-networks.net Mon Feb 16 16:18:32 2009 From: imb at protected-networks.net (Michael Butler) Date: Mon Feb 16 16:18:39 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed In-Reply-To: <4999F7F9.4030204@elischer.org> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> Message-ID: <499A024A.60209@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > Network device drivers intimately tangled with the old TTY code: > > if_cx > if_ppp > lf_sl The old TTY code appears to be the reason that the bluetooth/ng_h4 driver was "abandoned". Not having investigated further, I do not know if it is practical to restore to functionality. Since I can no longer use my compact-flash adapted pcmcia card for the lack of the H4 driver in -current, I use a USB dongle .. as follows: The usage of rfcomm_sppd as documented in the handbook results in .. Feb 16 19:12:57 toshi kernel: ugen1.2: at usbus1 Feb 16 19:12:57 toshi kernel: ubt0: on usbus1 Feb 16 19:13:31 toshi kernel: pid 50258 (rfcomm_sppd) is using legacy pty devices .. when connecting to my GPS. Is this functionality to be impacted? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmaAkkACgkQQv9rrgRC1JK5rgCeM25FjOcNp/XHc5HuWV9yBSq8 IqMAmwVLP0QDIKMn5kDJhEa7gJN9mmq7 =sLMJ -----END PGP SIGNATURE----- From linimon at FreeBSD.org Mon Feb 16 17:09:31 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Feb 16 17:09:42 2009 Subject: kern/131753: [altq] [panic] kernel panic in hfsc_dequeue Message-ID: <200902170109.n1H19UWL040402@freefall.freebsd.org> Old Synopsis: kernel panic in hfsc_dequeue New Synopsis: [altq] [panic] kernel panic in hfsc_dequeue Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Feb 17 01:09:02 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131753 From fwkg7679 at mb.infoweb.ne.jp Mon Feb 16 18:50:03 2009 From: fwkg7679 at mb.infoweb.ne.jp (KUROSAWA Takahiro) Date: Mon Feb 16 18:50:09 2009 Subject: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic Message-ID: <200902170250.n1H2o2Ew015662@freefall.freebsd.org> The following reply was made to PR kern/116837; it has been noted by GNATS. From: KUROSAWA Takahiro To: bug-followup@FreeBSD.org, jkpyvxmzsa@mailinator.com Cc: Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic Date: Tue, 17 Feb 2009 11:42:00 +0900 This is fixed on recent 8-CURRENT, but probably not yet on 7.x. From vlad at prokk.net Tue Feb 17 01:47:07 2009 From: vlad at prokk.net (Vladimir V. Kobal) Date: Tue Feb 17 01:47:14 2009 Subject: Synopsis: process swi1:net gives 100% CPU usage. In-Reply-To: References: Message-ID: <000f01c990e0$a70c1230$f5243690$@net> I have the same problem with netgraph on 7.1-RELEASE, mpd 5.2, AMD Phenom. Dummynet, divert and pf are disabled in the kernel. While swi1:net (aka netgraph) is using 100% of CPU time m_tag_locate() and ng_iface_output() are constantly called from the infinite loop. Sergey, could you provide the content of mpd.conf and the output of "ngctl types". -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Sergey Pronin Sent: Thursday, February 12, 2009 9:07 PM To: freebsd-net@freebsd.org Subject: Synopsis: process swi1:net gives 100% CPU usage. Synopsis: process swi1:net gives 100% CPU usage. Not depending on the conditions (no heavy load, not a lot of traffic passing through, not a lot of ng nodes) server stops to work properly. 1) swi1:net gives me 100% CPU usage. 2) server is not responding to icmp echo requests 3) ssh of course not working 4) mpd has an "ngsock" state at the top 5) tasq of the em0 card using 0% of the cpu. 6) rebooting the server helps. From krassi at bulinfo.net Tue Feb 17 02:21:47 2009 From: krassi at bulinfo.net (Krassimir Slavchev) Date: Tue Feb 17 02:21:58 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed In-Reply-To: <4999F7F9.4030204@elischer.org> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> Message-ID: <499A884A.4040408@bulinfo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Elischer wrote: > Robert Watson wrote: >> >> (Bcc to arch@) >> >> On Mon, 26 May 2008, Robert Watson wrote: >> >>> Just to keep track of things: >>> >>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT >> >> Delayed by about six months, the merge and switch to the new USB stack >> in 8.x means that we're now fairly close to being able to pick up this >> project again. The goal remains to eliminate IFF_NEEDSGIANT, which is >> (mostly) the last piece of non-MPSAFE compatibility infrastructure in >> the network stack in -CURRENT. I removed support for non-MPSAFE >> network protocols before 7.0, and this is the support for non-MPSAFE >> network device drivers. As of the current moment in HEAD, the >> following drivers are flagged wth IFF_NEEDSGIANT: >> >> General network device drivers that still require Giant: >> >> if_ar >> if_ray >> if_sl >> if_sr > > if_sr and if_ar are really simple and could probably > be converted "trivially".. especially if > their netgraph code is used. > > however I wonder if anyone still has that hardware (they are > drivers for two sync serial cards). I still have such Digi/Arnet SYNC/570i PCI card and I used to use it for a long time with 4.x and if_ar driver without any problems. Thanks to John Hay for well written driver! > > John Hay must have had some when he wrote the driver... > >> >> Old USB network device drivers: >> >> if_axe >> if_cdce >> if_cue >> if_kue >> if_rue >> if_rum >> if_udav >> if_upgt >> if_ural >> if_urtw >> if_zyd >> >> Network device drivers intimately tangled with the old TTY code: >> >> if_cx >> if_ppp >> lf_sl >> >> A network device driver that appears to conditionally use >> IFF_NEEDSGIANT for the purposes of (sometimes) interacting with the >> old USB code: >> >> if_ndis >> >> The following schedule is proposed, assuming nothing goes horribly >> wrong with the new USB code in the next few weeks, and remaining nits >> relating to USB network and 802.11 drivers are handled: >> >> 16 February 2009 HEADS UP to lists (this e-mail) >> 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x >> 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x >> >> In the next couple of weeks, I'd like to resolve the status of (and >> eliminate) the if_ndis conditional use of IFF_NEEDSGIANT. There's >> also a chance that if_sl will get updated by Ed and myself to work >> with the new locking and TTY world orders -- the lock is easy, but the >> TTY update takes a bit of work. Perhaps someone will feel moved to do >> this for if_ppp and possibly if_cx as well. >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJmohKxJBWvpalMpkRAh44AJ4pmnYdK3XApm8FoVpWfHsqZIZF3gCdHKGZ 3V5VDG8kKg5OVkColCUu9cA= =0oAM -----END PGP SIGNATURE----- From rwatson at FreeBSD.org Tue Feb 17 02:26:08 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Feb 17 02:26:20 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed In-Reply-To: <499A884A.4040408@bulinfo.net> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A884A.4040408@bulinfo.net> Message-ID: On Tue, 17 Feb 2009, Krassimir Slavchev wrote: >> if_sr and if_ar are really simple and could probably be converted >> "trivially".. especially if their netgraph code is used. >> >> however I wonder if anyone still has that hardware (they are drivers for >> two sync serial cards). > > I still have such Digi/Arnet SYNC/570i PCI card and I used to use it for a > long time with 4.x and if_ar driver without any problems. > > Thanks to John Hay for well written driver! I would be quite happy to see the remaining drivers be converted over -- when using IFF_NEEDSGIANT, they do potentially see a significant performance loss as a result of having to defer execution to Giant-holding contexts. However, the sooner the better, as stripping the Giant compat stuff will allow us to clean up the compat shims, in turn removing the need for deferred execution to avoid calling those shims in unfortunate contexts for multicast, and simplifies the forthcoming address list locking work. Robert N M Watson Computer Laboratory University of Cambridge From riaank at gmail.com Tue Feb 17 05:15:21 2009 From: riaank at gmail.com (Riaan Kruger) Date: Tue Feb 17 05:15:28 2009 Subject: NATT patch and FreeBSD's setkey Message-ID: <85c4b1850902170448p7a59d50bt6bdaa89aa01c51d7@mail.gmail.com> I see a lot of good work done on the nat-t patches for FreeBSD and ipsec-tools. I was wondering if the base setkey is due for an update? If so is anyone looking to update it? Has anyone had any success using the patched FreeBSD along with racoon2. Regards Riaan From vanhu at FreeBSD.org Tue Feb 17 06:28:57 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Tue Feb 17 06:29:05 2009 Subject: NATT patch and FreeBSD's setkey In-Reply-To: <85c4b1850902170448p7a59d50bt6bdaa89aa01c51d7@mail.gmail.com> References: <85c4b1850902170448p7a59d50bt6bdaa89aa01c51d7@mail.gmail.com> Message-ID: <20090217143425.GA58591@zeninc.net> On Tue, Feb 17, 2009 at 02:48:06PM +0200, Riaan Kruger wrote: > I see a lot of good work done on the nat-t patches for FreeBSD and ipsec-tools. That's what we're trying to do, even if we know that there is still some work to do ! > I was wondering if the base setkey is due for an update? > If so is anyone looking to update it? Upgrading FreeBSD's setkey is not a new question.... Basically, there are various scenarios: - keep it (almost) without changes, it is enouth for basic (static) IPsec, and people who want to do dynamic keying, NAT-T, etc... will install ipsec-tools, so will have /usr/local/sbin/setkey. - same as upper, but do "something" to solve the problem when both /sbin/setkey and /usr/local/sbin/setkey (same for libipsec) are installed. - just remove setkey/libipsec from base system. People who want "real IPsec" will need ipsec-tools or something else, but we can't ensure no one will just need setkey/libipsec... - sync FreeBSD's setkey/libipsec from ipsec-tools. That won't solve all issues (/sbin Vs /usr/local/sbin), and this will need regular syncs with ipsec-tools. - Same as upper, but remove sources from /usr/src, consider ipsec-tools as a contrib (in /usr/src/contrib) and do "something" to automagically update sources when needed (as in /usr/ports). All those solutions solve some parts of the problems (except the first one, of course), but keeps/generates some others.... If someone has a magic solution without drawbacks, please tell us ! > Has anyone had any success using the patched FreeBSD along with racoon2. I just don't know what's the actual status of racoon2, but nat-t patchset is public and everyone can send changes if that helps interaction with other daemons (without breaking again the API if possible.....). Yvan. From bzeeb-lists at lists.zabbadoz.net Tue Feb 17 06:45:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Feb 17 06:45:14 2009 Subject: NATT patch and FreeBSD's setkey In-Reply-To: <20090217143425.GA58591@zeninc.net> References: <85c4b1850902170448p7a59d50bt6bdaa89aa01c51d7@mail.gmail.com> <20090217143425.GA58591@zeninc.net> Message-ID: <20090217143409.J53478@maildrop.int.zabbadoz.net> On Tue, 17 Feb 2009, VANHULLEBUS Yvan wrote: Hi, > If someone has a magic solution without drawbacks, please tell us ! I am not going to find my posting from a few years back but the solution is to keep the kernel and libipsec (and setkey) in base in sync and not install libipsec and setkey from the ipsec-tools port. Done. That obviously means that people who patch their kernel need to patch their user space as well but that should not be a problem as they rebuild anyway and need to build ipsec-tools racoon etc. on their own to use the new features as w/o changing the default options it doesn't work for nat-t. That also allows other 3rd party utilities using libipsec to continue to do so and use all "features" w/o needing another fork. >> Has anyone had any success using the patched FreeBSD along with racoon2. > > I just don't know what's the actual status of racoon2, but nat-t > patchset is public and everyone can send changes if that helps > interaction with other daemons (without breaking again the API if > possible.....). We have about 3 months left to get that patch in for 8; ideally 6 weeks. Can you update the nat-t patch in a way as discussed here before so that the extra address is in etc. and we can move forward? I basically do not care if racoon from ipsec-tools is not going to work for two weeks of HEAD or four as someone will quickly add a conditional patch to the port for a __FreeBSD_version > 8xxxxx and that can be removed once ipsec-tools properly detect the state of the system. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From jwm-freebsd-net at skepsi.net Tue Feb 17 06:47:33 2009 From: jwm-freebsd-net at skepsi.net (Jason Morgan) Date: Tue Feb 17 06:47:40 2009 Subject: WPA-EAP (ath driver): trouble maintaining connection In-Reply-To: <20090214222342.GA45141@skepsi.net> References: <20090214222342.GA45141@skepsi.net> Message-ID: <20090217144731.GA25475@skepsi.net> On 2009.02.14 17:23:42, Jason Morgan wrote: > > Hello, > > I have been having trouble maintaining a wireless connection at my > university, which uses the WPA-EAP protocol. I have played with my > wpa_supplicant.conf file, but haven't found anything that works. I > don't seems to have any trouble at home using a Linksys AP and > WPA-PSK. I was hoping someone here could point me in the right > direction---I am not very familiar with WPA and wireless > networking. Error messages and other relevant information below. (You > will notice that I lose connection every 5-10 minutes.) > > Thanks in advance. Some additional information in case that's helpful. $ pciconf -lv ath0@pci0:8:10:0: class=0x020000 card=0x132910cf chip=0x001b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5006 family 802.11abg Wireless NIC' class = network subclass = ethernet Also, it seems that I am getting a lot more of these messages in /var/log/messages: Feb 15 11:49:48 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Feb 15 11:49:54 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Feb 15 11:49:54 sofie dhclient: New IP Address (ath0): 128.146.115.38 Feb 15 11:49:54 sofie dhclient: New Subnet Mask (ath0): 255.255.255.0 Feb 15 11:49:54 sofie dhclient: New Broadcast Address (ath0): 128.146.115.255 Feb 15 11:49:54 sofie dhclient: New Routers (ath0): 128.146.115.1 Feb 15 11:49:56 sofie kernel: update_stats: bogus ndx0 -1, max 10, mode 3 Feb 15 11:50:37 sofie last message repeated 4 times Feb 15 11:52:38 sofie last message repeated 14 times Feb 15 11:54:42 sofie last message repeated 14 times The ath manpage provides a bit of information ("This should not happen") on `bogus xmit rate' but not on `bogus ndx0'. Once again, any help would be greatly appreciated. ~Jason > $ uname -a > FreeBSD sofie.skepsi.net 7.1-STABLE FreeBSD 7.1-STABLE #3: Sun Feb 1 > 13:00:56 EST 2009 root@sofie.skepsi.net:/usr/obj/usr/src/sys/SOFIE > amd64 > > > $ cat /etc/wpa_supplicant.conf > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel > eapol_version=1 > ap_scan=1 > fast_reauth=1 > > network={ > ssid="osuwireless" > scan_ssid=1 > key_mgmt=WPA-EAP > eap=PEAP > identity="xxx" > password="xxx" > phase1="peaplabel=0" > phase2="auth-MSCHAPV2" > priority=1 > } > > > $ cat /etc/dhclient.conf > # ath0 > interface "ath0" { > request subnet-mask, broadcast-address, time-offset, routers, > domain-name, domain-name-servers, host-name; > require subnet-mask, domain-name-servers; > } > > > $ cat /var/log/messages > > Feb 14 15:50:09 sofie kernel: ath0: link state changed to DOWN > Feb 14 15:50:09 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:58:04:00 (SSID='osuwireless' freq=2437 MHz) > Feb 14 15:50:09 sofie wpa_supplicant[403]: CTRL-EVENT-DISCONNECTED - > Disconnect event - remove keys > Feb 14 15:50:19 sofie wpa_supplicant[403]: Authentication with > 00:00:00:00:00:00 timed out. > Feb 14 15:50:27 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:58:02:80 (SSID='osuwireless' freq=2437 MHz) > Feb 14 15:50:27 sofie wpa_supplicant[403]: Association request to the > driver failed > Feb 14 15:50:32 sofie wpa_supplicant[403]: Authentication with > 00:0b:86:58:02:80 timed out. > Feb 14 15:50:39 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:5d:3a:40 (SSID='osuwireless' freq=2412 MHz) > Feb 14 15:50:40 sofie kernel: ath0: link state changed to UP > Feb 14 15:50:40 sofie wpa_supplicant[403]: Associated with > 00:0b:86:5d:3a:40 > Feb 14 15:50:40 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-STARTED EAP > authentication started > Feb 14 15:50:40 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP > vendor 0 method 25 (PEAP) selected > Feb 14 15:50:40 sofie wpa_supplicant[403]: OpenSSL: > tls_connection_handshake - Failed to read possible Application Data > error:00000000:lib(0):func(0):reason(0) > Feb 14 15:50:40 sofie wpa_supplicant[403]: EAP-MSCHAPV2: > Authentication succeeded > Feb 14 15:50:40 sofie wpa_supplicant[403]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed > Feb 14 15:50:40 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-SUCCESS EAP > authentication completed successfully > Feb 14 15:50:40 sofie wpa_supplicant[403]: WPA: Key negotiation > completed with 00:0b:86:5d:3a:40 [PTK=TKIP GTK=TKIP] > Feb 14 15:50:40 sofie wpa_supplicant[403]: CTRL-EVENT-CONNECTED - > Connection to 00:0b:86:5d:3a:40 completed (reauth) [id=1 id_str=] > Feb 14 15:50:40 sofie dhclient: New IP Address (ath0): 128.146.115.38 > Feb 14 15:50:40 sofie dhclient: New Subnet Mask (ath0): 255.255.255.0 > Feb 14 15:50:40 sofie dhclient: New Broadcast Address (ath0): > 128.146.115.255 > Feb 14 15:50:40 sofie dhclient: New Routers (ath0): 128.146.115.1 > Feb 14 15:55:48 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:58:03:e0 (SSID='osuwireless' freq=2412 MHz) > Feb 14 15:55:48 sofie kernel: ath0: link state changed to DOWN > Feb 14 15:55:48 sofie wpa_supplicant[403]: CTRL-EVENT-DISCONNECTED - > Disconnect event - remove keys > Feb 14 15:55:58 sofie wpa_supplicant[403]: Authentication with > 00:00:00:00:00:00 timed out. > Feb 14 15:56:06 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:58:04:00 (SSID='osuwireless' freq=2437 MHz) > Feb 14 15:56:16 sofie wpa_supplicant[403]: Authentication with > 00:0b:86:58:04:00 timed out. > Feb 14 15:56:23 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:58:02:80 (SSID='osuwireless' freq=2437 MHz) > Feb 14 15:56:23 sofie wpa_supplicant[403]: Association request to the > driver failed > Feb 14 15:56:28 sofie wpa_supplicant[403]: Authentication with > 00:0b:86:58:02:80 timed out. > Feb 14 15:56:36 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:5d:02:c0 (SSID='osuwireless' freq=2437 MHz) > Feb 14 15:56:36 sofie kernel: ath0: link state changed to UP > Feb 14 15:56:36 sofie wpa_supplicant[403]: Associated with > 00:0b:86:5d:02:c0 > Feb 14 15:56:36 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP > vendor 0 method 25 (PEAP) selected > Feb 14 15:56:36 sofie wpa_supplicant[403]: OpenSSL: > tls_connection_handshake - Failed to read possible Application Data > error:00000000:lib(0):func(0):reason(0) > Feb 14 15:56:43 sofie kernel: update_stats: bogus ndx0 -1, max 10, > mode 3 > Feb 14 15:57:14 sofie last message repeated 6 times > Feb 14 15:57:18 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-STARTED EAP > authentication started > Feb 14 15:57:18 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP > vendor 0 method 25 (PEAP) selected > Feb 14 15:57:18 sofie wpa_supplicant[403]: OpenSSL: > tls_connection_handshake - Failed to read possible Application Data > error:00000000:lib(0):func(0):reason(0) > Feb 14 15:57:18 sofie wpa_supplicant[403]: EAP-MSCHAPV2: > Authentication succeeded > Feb 14 15:57:18 sofie wpa_supplicant[403]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed > Feb 14 15:57:18 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-SUCCESS EAP > authentication completed successfully > Feb 14 15:57:28 sofie kernel: update_stats: bogus ndx0 -1, max 10, > mode 3 > Feb 14 15:57:29 sofie kernel: ath0: link state changed to DOWN > Feb 14 15:57:29 sofie wpa_supplicant[403]: CTRL-EVENT-DISCONNECTED - > Disconnect event - remove keys > Feb 14 15:57:37 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:5d:02:c0 (SSID='osuwireless' freq=2437 MHz) > Feb 14 15:57:37 sofie kernel: ath0: link state changed to UP > Feb 14 15:57:37 sofie wpa_supplicant[403]: Associated with > 00:0b:86:5d:02:c0 > Feb 14 15:57:37 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-STARTED EAP > authentication started > Feb 14 15:57:37 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP > vendor 0 method 25 (PEAP) selected > Feb 14 15:57:37 sofie wpa_supplicant[403]: OpenSSL: > tls_connection_handshake - Failed to read possible Application Data > error:00000000:lib(0):func(0):reason(0) > Feb 14 15:57:37 sofie wpa_supplicant[403]: EAP-MSCHAPV2: > Authentication succeeded > Feb 14 15:57:37 sofie wpa_supplicant[403]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed > Feb 14 15:57:37 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-SUCCESS EAP > authentication completed successfully > Feb 14 15:57:41 sofie kernel: update_stats: bogus ndx0 -1, max 10, > mode 3 > Feb 14 15:57:41 sofie kernel: ath0: link state changed to DOWN > Feb 14 15:57:41 sofie wpa_supplicant[403]: CTRL-EVENT-DISCONNECTED - > Disconnect event - remove keys > Feb 14 15:57:49 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:58:03:e0 (SSID='osuwireless' freq=2412 MHz) > Feb 14 15:57:49 sofie wpa_supplicant[403]: Association request to the > driver failed > Feb 14 15:57:54 sofie wpa_supplicant[403]: Authentication with > 00:0b:86:58:03:e0 timed out. > Feb 14 15:57:58 sofie dhclient: New IP Address (ath0): 128.146.115.38 > Feb 14 15:57:58 sofie dhclient: New Subnet Mask (ath0): 255.255.255.0 > Feb 14 15:57:58 sofie dhclient: New Broadcast Address (ath0): > 128.146.115.255 > Feb 14 15:57:58 sofie dhclient: New Routers (ath0): 128.146.115.1 > Feb 14 15:57:59 sofie dhclient: New Routers (ath0): 128.146.115.1 > Feb 14 15:58:01 sofie wpa_supplicant[403]: Trying to associate with > 00:0b:86:58:03:80 (SSID='osuwireless' freq=2412 MHz) > Feb 14 15:58:01 sofie kernel: ath0: link state changed to UP > Feb 14 15:58:01 sofie wpa_supplicant[403]: Associated with > 00:0b:86:58:03:80 > Feb 14 15:58:01 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-STARTED EAP > authentication started > Feb 14 15:58:06 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-METHOD EAP > vendor 0 method 25 (PEAP) selected > Feb 14 15:58:06 sofie wpa_supplicant[403]: OpenSSL: > tls_connection_handshake - Failed to read possible Application Data > error:00000000:lib(0):func(0):reason(0) > Feb 14 15:58:06 sofie wpa_supplicant[403]: EAP-MSCHAPV2: > Authentication succeeded > Feb 14 15:58:06 sofie wpa_supplicant[403]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed > Feb 14 15:58:06 sofie wpa_supplicant[403]: CTRL-EVENT-EAP-SUCCESS EAP > authentication completed successfully > Feb 14 15:58:06 sofie wpa_supplicant[403]: WPA: Key negotiation > completed with 00:0b:86:58:03:80 [PTK=TKIP GTK=TKIP] > Feb 14 15:58:06 sofie wpa_supplicant[403]: CTRL-EVENT-CONNECTED - > Connection to 00:0b:86:58:03:80 completed (reauth) [id=1 id_str=] > Feb 14 15:58:25 sofie dhclient: New IP Address (ath0): 128.146.115.38 > Feb 14 15:58:25 sofie dhclient: New Subnet Mask (ath0): 255.255.255.0 > Feb 14 15:58:25 sofie dhclient: New Broadcast Address (ath0): > 128.146.115.255 > Feb 14 15:58:25 sofie dhclient: New Routers (ath0): 128.146.115.1 > Feb 14 16:03:34 sofie kernel: update_stats: bogus ndx0 -1, max 10, > mode 3 > Feb 14 16:06:56 sofie kernel: update_stats: bogus ndx0 -1, max 10, > mode 3 > Feb 14 16:06:57 sofie kernel: update_stats: bogus ndx0 -1, max 10, > mode 3 > > > Please let me know if additional information would be helpful. > > Cheers, > ~Jason > > > -- > ~ Jason Morgan > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- ~ Jason Morgan From blogtiengviet at yahoo.com Tue Feb 17 06:51:03 2009 From: blogtiengviet at yahoo.com (Blog Tieng Viet) Date: Tue Feb 17 08:42:18 2009 Subject: How to protect FreeBSD from IP spoofing ? In-Reply-To: <200902131430.n1DEUED7040530@freefall.freebsd.org> Message-ID: <292159.62731.qm@web57103.mail.re3.yahoo.com> Dear all. I am a newbie of FreeBSD, would like to get alot of information about FreeBSD such as IPFW. I am annoyed by IP spoofing but dont have any way to prevent it. Can any one tell me how to do ? Thanks in advance. PS: I am using 6.4-PRERELEASE FreeBSD 6.4-PRERELEASE. The FreeBSD box is used for web server, and it is forwarded every parket of port 80 from LAN router. From linimon at FreeBSD.org Tue Feb 17 09:20:47 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Feb 17 09:20:54 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link Message-ID: <200902171720.n1HHKkIf071491@freefall.freebsd.org> Old Synopsis: ndis keeps dropping the link New Synopsis: [ndis] ndis keeps dropping the link Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Feb 17 17:20:32 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 From ady at freebsd.ady.ro Tue Feb 17 09:22:59 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Tue Feb 17 09:23:06 2009 Subject: How to protect FreeBSD from IP spoofing ? In-Reply-To: <292159.62731.qm@web57103.mail.re3.yahoo.com> References: <200902131430.n1DEUED7040530@freefall.freebsd.org> <292159.62731.qm@web57103.mail.re3.yahoo.com> Message-ID: <78cb3d3f0902170855p70047aa0r655d8ba846d2458d@mail.gmail.com> Hi, Check the ipfw(8) manual (includes examples) or rather go for pf (packetfilter) and check the pf.conf(5) manual. For pf you just need to add something like "antispoof for lo0". Regards, Adrian. On Tue, Feb 17, 2009 at 3:24 PM, Blog Tieng Viet wrote: > Dear all. > I am a newbie of FreeBSD, would like to get alot of information about > FreeBSD such as IPFW. > I am annoyed by IP spoofing but dont have any way to prevent it. > Can any one tell me how to do ? > Thanks in advance. > > PS: > I am using 6.4-PRERELEASE FreeBSD 6.4-PRERELEASE. > The FreeBSD box is used for web server, and it is forwarded every parket of > port 80 from LAN router. > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From olli at lurza.secnetix.de Tue Feb 17 09:48:01 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Feb 17 09:48:09 2009 Subject: Packet filter performance on SMP Message-ID: <200902171747.n1HHlwQR080012@lurza.secnetix.de> Hi, I've asked this a week ago on the -ipfw list, but got no reply ... The -net list might be more appropriate. I'll have to implement a packet filter on machines with several cores (4 to 8). Which one of the available filters (IPFW, IPF, PF) will provide the best performance on such SMP machines? I heard that PF doesn't support SMP hardware very well -- is that true? Will IPFW be better? Thanks for any insights. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing." ? ? ? ? -- Mother Teresa From espartano.mail at gmail.com Tue Feb 17 09:48:23 2009 From: espartano.mail at gmail.com (Espartano) Date: Tue Feb 17 09:48:30 2009 Subject: OT: Libnet 1.1 documentation Message-ID: Hi folk, some one know where can i found the oficial documentation of Libnet 1.1.x ? or may be an tuto of it ? Thanks a lot. -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From onemda at gmail.com Tue Feb 17 10:22:25 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Feb 17 10:22:31 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <200902171720.n1HHKkIf071491@freefall.freebsd.org> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> Message-ID: <3a142e750902171022t74ac8b9am3b8b3bc283a6e46d@mail.gmail.com> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 This one should not happen, 108 rate should get recognized. I will try to reproduce it on CURRENT. To OP, could you try 7 STABLE after 31 Jan? I guess it should not change anything but you never know. -- Paul From julian at elischer.org Tue Feb 17 10:36:38 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Feb 17 10:36:44 2009 Subject: Packet filter performance on SMP In-Reply-To: <200902171747.n1HHlwQR080012@lurza.secnetix.de> References: <200902171747.n1HHlwQR080012@lurza.secnetix.de> Message-ID: <499AFD1D.4020907@elischer.org> Oliver Fromme wrote: > Hi, > > I've asked this a week ago on the -ipfw list, but got no > reply ... The -net list might be more appropriate. > > I'll have to implement a packet filter on machines with > several cores (4 to 8). Which one of the available filters > (IPFW, IPF, PF) will provide the best performance on such > SMP machines? I heard that PF doesn't support SMP hardware > very well -- is that true? Will IPFW be better? Not a lot of testing has been done on this topic yet. I know that this is not what you want to hear but it is possible that you might be the person to try it out (using the tunables to disable different number of CPUs) and see how it works out. let us know if you get any interesting results. Ipfw has a single rw lock guarding the entire rule set but it only does a reader lock on packet processing so multiple CPUs can be in there at the same time. It does not however protect the statistics on each rule so if two cpus try update the stats at the same time, one of them will miss out. (this has been considered an acceptable loss of accuracy in order to maintain throughput I guess). > Thanks for any insights. > > Best regards > Oliver > From adamk at voicenet.com Tue Feb 17 10:37:01 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Tue Feb 17 10:37:10 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <3a142e750902171022t74ac8b9am3b8b3bc283a6e46d@mail.gmail.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <3a142e750902171022t74ac8b9am3b8b3bc283a6e46d@mail.gmail.com> Message-ID: <20090217133404.22275b25@memory.visualtech.com> On Tue, 17 Feb 2009 19:22:22 +0100 "Paul B. Mahol" wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 > > This one should not happen, 108 rate should get recognized. > I will try to reproduce it on CURRENT. > > To OP, could you try 7 STABLE after 31 Jan? I guess it should not > change anything but you never know. Sorry, I must have copied and pasted the uname output from the wrong machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18 EST 2009 :-) Could the fact that the rate is 108 also be causing problems for the native iwi driver? Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From kurt.buff at gmail.com Tue Feb 17 11:44:45 2009 From: kurt.buff at gmail.com (Kurt Buff) Date: Tue Feb 17 11:44:51 2009 Subject: Fwd: NATT patch and FreeBSD's setkey In-Reply-To: References: <85c4b1850902170448p7a59d50bt6bdaa89aa01c51d7@mail.gmail.com> <20090217143425.GA58591@zeninc.net> <20090217143409.J53478@maildrop.int.zabbadoz.net> Message-ID: My bad - didn't send to list. See below. ---------- Forwarded message ---------- From: Kurt Buff Date: Tue, Feb 17, 2009 at 11:20 AM Subject: Re: NATT patch and FreeBSD's setkey To: "Bjoern A. Zeeb" On Tue, Feb 17, 2009 at 6:41 AM, Bjoern A. Zeeb wrote: > On Tue, 17 Feb 2009, VANHULLEBUS Yvan wrote: > > Hi, > >> If someone has a magic solution without drawbacks, please tell us ! > > I am not going to find my posting from a few years back but the > solution is to keep the kernel and libipsec (and setkey) in base in > sync and not install libipsec and setkey from the ipsec-tools port. > Done. > > That obviously means that people who patch their kernel need to patch > their user space as well but that should not be a problem as they > rebuild anyway and need to build ipsec-tools racoon etc. on their own > to use the new features as w/o changing the default options it doesn't > work for nat-t. > > That also allows other 3rd party utilities using libipsec to continue > to do so and use all "features" w/o needing another fork. > > > >>> Has anyone had any success using the patched FreeBSD along with racoon2. >> >> I just don't know what's the actual status of racoon2, but nat-t >> patchset is public and everyone can send changes if that helps >> interaction with other daemons (without breaking again the API if >> possible.....). > > We have about 3 months left to get that patch in for 8; ideally 6 > weeks. Can you update the nat-t patch in a way as discussed here > before so that the extra address is in etc. and we can move forward? > > I basically do not care if racoon from ipsec-tools is not going to > work for two weeks of HEAD or four as someone will quickly add a > conditional patch to the port for a __FreeBSD_version > 8xxxxx and > that can be removed once ipsec-tools properly detect the state of the > system. > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking one. Forgive my ignorance, but is this the same patch required by' /usr/ports/security/ike - Shrew Soft IKE daemon and client tools'? Kurt From onemda at gmail.com Tue Feb 17 14:14:09 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Feb 17 14:14:16 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <20090217133404.22275b25@memory.visualtech.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <3a142e750902171022t74ac8b9am3b8b3bc283a6e46d@mail.gmail.com> <20090217133404.22275b25@memory.visualtech.com> Message-ID: <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> On 2/17/09, Adam K Kirchhoff wrote: > On Tue, 17 Feb 2009 19:22:22 +0100 > "Paul B. Mahol" wrote: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 >> >> This one should not happen, 108 rate should get recognized. >> I will try to reproduce it on CURRENT. >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not >> change anything but you never know. > > Sorry, I must have copied and pasted the uname output from the wrong > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18 > EST 2009 :-) miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in ndis_setstate() for setting OID_802_11_CONFIGURATION. > Could the fact that the rate is 108 also be causing problems for the > native iwi driver? Unlikely, bug is in ndisulator initialization code. -- Paul From adamk at voicenet.com Tue Feb 17 14:29:49 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Tue Feb 17 14:29:57 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <20090217133404.22275b25@memory.visualtech.com> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> Message-ID: <200902171727.53156.adamk@voicenet.com> On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: > On 2/17/09, Adam K Kirchhoff wrote: > > On Tue, 17 Feb 2009 19:22:22 +0100 > > > > "Paul B. Mahol" wrote: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 > >> > >> This one should not happen, 108 rate should get recognized. > >> I will try to reproduce it on CURRENT. > >> > >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not > >> change anything but you never know. > > > > Sorry, I must have copied and pasted the uname output from the wrong > > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18 > > EST 2009 :-) > > miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in > ndis_setstate() for setting OID_802_11_CONFIGURATION. Sorry if I seem slow, but are you asking me to check something there, or just stating what you think the problem is? :-) > > Could the fact that the rate is 108 also be causing problems for the > > native iwi driver? > > Unlikely, bug is in ndisulator initialization code. Oh well :-) I'll take what I can get at this point. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From kalin at el.net Tue Feb 17 14:48:42 2009 From: kalin at el.net (kalin m) Date: Tue Feb 17 14:48:49 2009 Subject: sms gprs gsm edge Message-ID: <499B3888.2000701@el.net> hi all... just looking for a few pointers for setting up a sms gateway. if somebody would like to share some knowledge on successfully implemented hardware (gprs/gsm/edge modems/drivers) and software like kannel, smstools, etc... for example i just talked to a salesperson at a company called moxa (http://www.moxa.com/product/oncell_g3100.htm) and was looking at their g3100 model gprs modem. according to their own specifications they have freebsd drivers. anybody has had any experience with those?! any information will be appreciated.. thank you.... From 000.fbsd at quip.cz Tue Feb 17 15:40:46 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Feb 17 15:40:59 2009 Subject: sms gprs gsm edge In-Reply-To: <499B3888.2000701@el.net> References: <499B3888.2000701@el.net> Message-ID: <499B464C.5020409@quip.cz> kalin m wrote: > > hi all... > > just looking for a few pointers for setting up a sms gateway. > if somebody would like to share some knowledge on successfully > implemented hardware (gprs/gsm/edge modems/drivers) and software like > kannel, smstools, etc... > > for example i just talked to a salesperson at a company called moxa > (http://www.moxa.com/product/oncell_g3100.htm) and was looking at their > g3100 model gprs modem. according to their own specifications they have > freebsd drivers. anybody has had any experience with those?! > > any information will be appreciated.. > thank you.... I used Siemens MC35i GSM modem over COM1 with smstools few years ago (with FreeBSD 4.x). No special drivers needed. It was used to send and receive SMS with our custom PHP web application. I don't know what is your definition of "sms gateway". Miroslav Lachman From peo at intersonic.se Tue Feb 17 15:45:13 2009 From: peo at intersonic.se (Per olof Ljungmark) Date: Tue Feb 17 15:45:25 2009 Subject: sms gprs gsm edge In-Reply-To: <499B3888.2000701@el.net> References: <499B3888.2000701@el.net> Message-ID: <499B4878.7060103@intersonic.se> kalin m wrote: > > hi all... > > just looking for a few pointers for setting up a sms gateway. > if somebody would like to share some knowledge on successfully > implemented hardware (gprs/gsm/edge modems/drivers) and software like > kannel, smstools, etc... > > for example i just talked to a salesperson at a company called moxa > (http://www.moxa.com/product/oncell_g3100.htm) and was looking at their > g3100 model gprs modem. according to their own specifications they have > freebsd drivers. anybody has had any experience with those?! > Hi, I know that a collegue here used a Siemens TC65 GSM Modem together with smstools and sms_client from ports to set up a sms paging system that works well. If you'd like I could ask him to send you more detailed info on how it was implemented. I also believe that the engine in this modem is available in various packages, the TC65 is a standalone unit needing only the sim card and antenna to work. It is connected over a usb to serial adapter and required no special drivers. -- per From dikshie at gmail.com Wed Feb 18 02:17:01 2009 From: dikshie at gmail.com (dikshie) Date: Wed Feb 18 02:17:08 2009 Subject: panic: _rw_wlock_hard Message-ID: <910e60e80902180150n41a592ffyb62ea53beb24f1ef@mail.gmail.com> Hi, does anyone see this panic on -HEAD: panic: _rw_wlock_hard: recursing but non-recursive rw radix node head @ /usr/src/sys/net/route.c:831 kdb_enter() at kdb_enter+0x3a panic() at panic+0x136 _rw_wlock_hard() at _rw_wlock_hard+0x66 _rw_wlock() at _rw_wlock+0xae rtquest1_fib() at rtquest1_fib+0x95 rtquest_fib() at rtquest_fib+0x5e in_rtquest() at in_rtquest+0x3b in_rtqkill() at in_rtqkill+0x7f rn_walktree() at rn_walktree+0x65 in_rtqtimo() at in_rtqtimo+0xb0 softclock() at softclock+0x24a intr_event_execute_handlers() at intr_event_execute_handlers+0x125 ithread_loop() at ithread_loop+0x9f fork_exit() at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 -HEAD built on Feb 16 14:26:25 JST. -- -dikshie- From onemda at gmail.com Wed Feb 18 03:06:23 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Feb 18 03:06:29 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <200902171727.53156.adamk@voicenet.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <20090217133404.22275b25@memory.visualtech.com> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> Message-ID: <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> On 2/17/09, Adam K Kirchhoff wrote: > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: >> On 2/17/09, Adam K Kirchhoff wrote: >> > On Tue, 17 Feb 2009 19:22:22 +0100 >> > >> > "Paul B. Mahol" wrote: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 >> >> >> >> This one should not happen, 108 rate should get recognized. >> >> I will try to reproduce it on CURRENT. >> >> >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not >> >> change anything but you never know. >> > >> > Sorry, I must have copied and pasted the uname output from the wrong >> > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18 >> > EST 2009 :-) >> >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in >> ndis_setstate() for setting OID_802_11_CONFIGURATION. > > Sorry if I seem slow, but are you asking me to check something there, or > just > stating what you think the problem is? :-) You can add printf() before "ndis_set_info(sc, OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to check what value for config.nc_dsconfig is by default. Also try changing "sysctl debug.ndis=1" and post console debug ouput again. > >> > Could the fact that the rate is 108 also be causing problems for the >> > native iwi driver? >> >> Unlikely, bug is in ndisulator initialization code. > > Oh well :-) I'll take what I can get at this point. > > Adam > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- Paul From sepron at gmail.com Wed Feb 18 04:45:43 2009 From: sepron at gmail.com (Sergey Pronin) Date: Wed Feb 18 04:45:49 2009 Subject: Synopsis: process swi1:net gives 100% CPU usage. In-Reply-To: <000f01c990e0$a70c1230$f5243690$@net> References: <000f01c990e0$a70c1230$f5243690$@net> Message-ID: Good day. As I'm using mpd4 I have mpd.conf and mpd.links. There are lots of static ngs created. So I'll post just a pattern of my mpd.conf: pppoe_def: set bundle disable multilink set bundle disable round-robin set bundle enable noretry set ipcp dns X.X.X.X Y.Y.Y.Y set iface disable on-demand set iface disable proxy-arp set iface enable tcpmssfix set link keep-alive 3 12 # set link mtu 1300 # set link mru 1460 set link max-redial -1 set pppoe service "*" set pppoe enable incoming set link enable chap set link enable chap-md5 set link enable chap-msv1 set link enable chap-msv2 set link disable passive callback no-orig-auth check-magic log -chat -bund -fsm -pptp set iface up-script "/root/scripts/up-script.pl" set iface down-script "/root/scripts/down-script.pl" set ipcp disable vjcomp set auth disable internal set auth enable radius-auth set radius server Z.Z.Z.Z password 1812 1813 set radius timeout 10 set radius retries 3 #ngctl types There are 27 total types: Type name Number of living nodes --------- ---------------------- pppoe 144 socket 2222 iface 2077 hole 0 gif_demux 0 gif 0 frame_relay 0 ether 560 echo 0 cisco 0 vjc 3 tty 0 tee 0 tcpmss 233 bridge 0 rfc1490 0 pptpgre 0 bpf 0 ppp 2076 one2many 0 async 0 mppc 0 lmi 0 UI 0 l2tp 0 ksocket 0 ip_input 0 I've tried to compile the kernel with and without netgraph options. I haven't seen any benefit. swi1:net still uses 100% CPU. I have the same problem with netgraph on 7.1-RELEASE, mpd 5.2, AMD Phenom. > Dummynet, divert and pf > are disabled in the kernel. > > While swi1:net (aka netgraph) is using 100% of CPU time m_tag_locate() and > ng_iface_output() > are constantly called from the infinite loop. > > Sergey, could you provide the content of mpd.conf and the output of "ngctl > types". > From adamk at voicenet.com Wed Feb 18 05:05:43 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Wed Feb 18 05:05:53 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <20090217133404.22275b25@memory.visualtech.com> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> Message-ID: <20090218080420.681788d2@memory.visualtech.com> On Wed, 18 Feb 2009 12:06:21 +0100 "Paul B. Mahol" wrote: > On 2/17/09, Adam K Kirchhoff wrote: > > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: > >> On 2/17/09, Adam K Kirchhoff wrote: > >> > On Tue, 17 Feb 2009 19:22:22 +0100 > >> > > >> > "Paul B. Mahol" wrote: > >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 > >> >> > >> >> This one should not happen, 108 rate should get recognized. > >> >> I will try to reproduce it on CURRENT. > >> >> > >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not > >> >> change anything but you never know. > >> > > >> > Sorry, I must have copied and pasted the uname output from the wrong > >> > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18 > >> > EST 2009 :-) > >> > >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in > >> ndis_setstate() for setting OID_802_11_CONFIGURATION. > > > > Sorry if I seem slow, but are you asking me to check something there, or > > just > > stating what you think the problem is? :-) > > You can add printf() before "ndis_set_info(sc, > OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to > check what value for config.nc_dsconfig is by default. I'll try that shortly. > Also try changing "sysctl debug.ndis=1" and post console debug ouput again. This was strange. If I boot up and enable debugging before I try to run '/etc/rc.d/netif start ndis0' everything works just fine. I get an IP address and stay connected (at least under a light load). This is the output: ndis_newstate: INIT -> INIT ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c0001392 (unknown error) Setting BSSID to ff:ff:ff:ff:ff:ff Setting ESSID to "" ndis0: no matching rate for: 108 ndis_newstate: INIT -> RUN ndis0: link state changed to UP ndis_newstate: RUN -> INIT Setting channel to 2412000kHz ndis0: couldn't change DS config to 2412000kHz: 19 Setting BSSID to ff:ff:ff:ff:ff:ff Setting ESSID to "Mckella280Front" ndis0: link state changed to DOWN ndis0: no matching rate for: 108 ndis_newstate: INIT -> RUN ndis0: link state changed to UP If I then stop the network on that device, disable debug, and try to start it up again, I get the same problem as before: ndis0: couldn't change DS config to 2412000kHz: 19 ndis0: link state changed to DOWN ndis0: no matching rate for: 108 ndis0: link state changed to UP ndis0: couldn't change DS config to 2412000kHz: 19 ndis0: link state changed to DOWN ndis0: no matching rate for: 108 ndis0: link state changed to UP ndis0: link state changed to DOWN If I then stop the network, enable debugging, and start up the network, the problem persists. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From onemda at gmail.com Wed Feb 18 07:33:58 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Feb 18 07:34:05 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <20090218080420.681788d2@memory.visualtech.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <20090217133404.22275b25@memory.visualtech.com> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> Message-ID: <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> On 2/18/09, Adam K Kirchhoff wrote: > On Wed, 18 Feb 2009 12:06:21 +0100 > "Paul B. Mahol" wrote: > >> On 2/17/09, Adam K Kirchhoff wrote: >> > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: >> >> On 2/17/09, Adam K Kirchhoff wrote: >> >> > On Tue, 17 Feb 2009 19:22:22 +0100 >> >> > >> >> > "Paul B. Mahol" wrote: >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 >> >> >> >> >> >> This one should not happen, 108 rate should get recognized. >> >> >> I will try to reproduce it on CURRENT. >> >> >> >> >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not >> >> >> change anything but you never know. >> >> > >> >> > Sorry, I must have copied and pasted the uname output from the wrong >> >> > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18 >> >> > EST 2009 :-) >> >> >> >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in >> >> ndis_setstate() for setting OID_802_11_CONFIGURATION. >> > >> > Sorry if I seem slow, but are you asking me to check something there, or >> > just >> > stating what you think the problem is? :-) >> >> You can add printf() before "ndis_set_info(sc, >> OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to >> check what value for config.nc_dsconfig is by default. > > I'll try that shortly. > >> Also try changing "sysctl debug.ndis=1" and post console debug ouput >> again. > > This was strange. If I boot up and enable debugging before I try to > run '/etc/rc.d/netif start ndis0' everything works just fine. I get an > IP address and stay connected (at least under a light load). This is > the output: > > ndis_newstate: INIT -> INIT > ndis0: NDIS ERROR: c00013a7 (unknown error) > ndis0: NDIS ERROR: c0001392 (unknown error) these two errors means: EVENT_NDIS_ADAPTER_CHECK_ERROR EVENT_NDIS_INVALID_VALUE_FROM_ADAPTER Looks like minport driver doesnt like your card. Are you absolutly sure that you are using right miniport driver? > Setting BSSID to ff:ff:ff:ff:ff:ff > Setting ESSID to "" > ndis0: no matching rate for: 108 > ndis_newstate: INIT -> RUN > ndis0: link state changed to UP > ndis_newstate: RUN -> INIT > Setting channel to 2412000kHz > ndis0: couldn't change DS config to 2412000kHz: 19 > Setting BSSID to ff:ff:ff:ff:ff:ff > Setting ESSID to "Mckella280Front" > ndis0: link state changed to DOWN > ndis0: no matching rate for: 108 > ndis_newstate: INIT -> RUN > ndis0: link state changed to UP > > If I then stop the network on that device, disable debug, and try to > start it up again, I get the same problem as before: > > ndis0: couldn't change DS config to 2412000kHz: 19 > ndis0: link state changed to DOWN > ndis0: no matching rate for: 108 > ndis0: link state changed to UP > ndis0: couldn't change DS config to 2412000kHz: 19 > ndis0: link state changed to DOWN > ndis0: no matching rate for: 108 > ndis0: link state changed to UP > ndis0: link state changed to DOWN > > If I then stop the network, enable debugging, and start up the network, > the problem persists. > You are starting ndis0 in same way in both cases? -- Paul From prt at prt.org Wed Feb 18 07:36:04 2009 From: prt at prt.org (Paul Thornton) Date: Wed Feb 18 07:36:10 2009 Subject: ipfw problems using divert and fwd at the same time with 6.3-release In-Reply-To: <49995AB5.50200@prt.org> References: <49995AB5.50200@prt.org> Message-ID: <499C2ADF.3070700@prt.org> I have found the error of my ways... For the purposes of the archives, I'm posting what actually made this work. It is a very simple fix and I don't quite know how I missed trying this out during my frustrations. Before the "ipfw fwd..." line you need one or more "ipfw skipto..." lines to ensure that you don't accidentally match the more specific addresses on the fwd. What's interesting is that I'd had "ipfw allow..." lines before the "ipfe fwd..." line doing a similar thing to skipto, and it didn't work. So I amended the ruleset to the following (other rules stay the same): > 06000 515 153945 divert 8668 ip from any to me via em0 > 07000 48 5472 skipto 32000 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 80 > 07100 0 0 skipto 32000 ip from 10.81.129.0/24 to any > 08000 94 10434 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80 > 32000 499 230890 allow ip from any to any Paul. From adamk at voicenet.com Wed Feb 18 08:13:30 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Wed Feb 18 08:13:37 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <20090217133404.22275b25@memory.visualtech.com> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> Message-ID: <20090218111223.4483b923@memory.visualtech.com> On Wed, 18 Feb 2009 16:33:56 +0100 "Paul B. Mahol" wrote: > On 2/18/09, Adam K Kirchhoff wrote: > > On Wed, 18 Feb 2009 12:06:21 +0100 > > "Paul B. Mahol" wrote: > > > >> On 2/17/09, Adam K Kirchhoff wrote: > >> > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: > >> >> On 2/17/09, Adam K Kirchhoff wrote: > >> >> > On Tue, 17 Feb 2009 19:22:22 +0100 > >> >> > > >> >> > "Paul B. Mahol" wrote: > >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 > >> >> >> > >> >> >> This one should not happen, 108 rate should get recognized. > >> >> >> I will try to reproduce it on CURRENT. > >> >> >> > >> >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not > >> >> >> change anything but you never know. > >> >> > > >> >> > Sorry, I must have copied and pasted the uname output from the wrong > >> >> > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 16:37:18 > >> >> > EST 2009 :-) > >> >> > >> >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in > >> >> ndis_setstate() for setting OID_802_11_CONFIGURATION. > >> > > >> > Sorry if I seem slow, but are you asking me to check something there, or > >> > just > >> > stating what you think the problem is? :-) > >> > >> You can add printf() before "ndis_set_info(sc, > >> OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to > >> check what value for config.nc_dsconfig is by default. > > > > I'll try that shortly. > > > >> Also try changing "sysctl debug.ndis=1" and post console debug ouput > >> again. > > > > This was strange. If I boot up and enable debugging before I try to > > run '/etc/rc.d/netif start ndis0' everything works just fine. I get an > > IP address and stay connected (at least under a light load). This is > > the output: > > > > ndis_newstate: INIT -> INIT > > ndis0: NDIS ERROR: c00013a7 (unknown error) > > ndis0: NDIS ERROR: c0001392 (unknown error) > > these two errors means: > > EVENT_NDIS_ADAPTER_CHECK_ERROR > EVENT_NDIS_INVALID_VALUE_FROM_ADAPTER > > Looks like minport driver doesnt like your card. > Are you absolutly sure that you are using right miniport driver? Frankly, no. This laptop came with a broadcom minipci card. I replaced it with the intel one that I'm now using since intel network cards have native drivers under FreeBSD :-) I've downloaded the latest drivers from the intel website ( http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Inst=Yes&ProductID=1637&DwnldID=17228&strOSs=45&OSFullName=Windows*%20XP%20Home%20Edition&lang=eng ) and used them to generate the driver with ndisgen. Is there a recommended windows driver to use with ndis for this intel network card? > > Setting BSSID to ff:ff:ff:ff:ff:ff > > Setting ESSID to "" > > ndis0: no matching rate for: 108 > > ndis_newstate: INIT -> RUN > > ndis0: link state changed to UP > > ndis_newstate: RUN -> INIT > > Setting channel to 2412000kHz > > ndis0: couldn't change DS config to 2412000kHz: 19 > > Setting BSSID to ff:ff:ff:ff:ff:ff > > Setting ESSID to "Mckella280Front" > > ndis0: link state changed to DOWN > > ndis0: no matching rate for: 108 > > ndis_newstate: INIT -> RUN > > ndis0: link state changed to UP > > > > If I then stop the network on that device, disable debug, and try to > > start it up again, I get the same problem as before: > > > > ndis0: couldn't change DS config to 2412000kHz: 19 > > ndis0: link state changed to DOWN > > ndis0: no matching rate for: 108 > > ndis0: link state changed to UP > > ndis0: couldn't change DS config to 2412000kHz: 19 > > ndis0: link state changed to DOWN > > ndis0: no matching rate for: 108 > > ndis0: link state changed to UP > > ndis0: link state changed to DOWN > > > > If I then stop the network, enable debugging, and start up the network, > > the problem persists. > > > > You are starting ndis0 in same way in both cases? Yes. I booted up with the ifconfig_ndis0 line commented out in /etc/rc.conf. I then uncommented the line, enabled debugging, and started the network with '/etc/rc.d/netif start ndis0'. I then brought the network down, disabled debugging, and started the network with the same command. After stopping the interface, and re-enabling networking, I started the interface with the same command the third time. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From onemda at gmail.com Wed Feb 18 10:27:38 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Feb 18 10:27:45 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <20090218111223.4483b923@memory.visualtech.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <20090217133404.22275b25@memory.visualtech.com> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> Message-ID: <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> On 2/18/09, Adam K Kirchhoff wrote: > On Wed, 18 Feb 2009 16:33:56 +0100 > "Paul B. Mahol" wrote: > >> On 2/18/09, Adam K Kirchhoff wrote: >> > On Wed, 18 Feb 2009 12:06:21 +0100 >> > "Paul B. Mahol" wrote: >> > >> >> On 2/17/09, Adam K Kirchhoff wrote: >> >> > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: >> >> >> On 2/17/09, Adam K Kirchhoff wrote: >> >> >> > On Tue, 17 Feb 2009 19:22:22 +0100 >> >> >> > >> >> >> > "Paul B. Mahol" wrote: >> >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 >> >> >> >> >> >> >> >> This one should not happen, 108 rate should get recognized. >> >> >> >> I will try to reproduce it on CURRENT. >> >> >> >> >> >> >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not >> >> >> >> change anything but you never know. >> >> >> > >> >> >> > Sorry, I must have copied and pasted the uname output from the >> >> >> > wrong >> >> >> > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 >> >> >> > 16:37:18 >> >> >> > EST 2009 :-) >> >> >> >> >> >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in >> >> >> ndis_setstate() for setting OID_802_11_CONFIGURATION. >> >> > >> >> > Sorry if I seem slow, but are you asking me to check something there, >> >> > or >> >> > just >> >> > stating what you think the problem is? :-) >> >> >> >> You can add printf() before "ndis_set_info(sc, >> >> OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to >> >> check what value for config.nc_dsconfig is by default. >> > >> > I'll try that shortly. >> > >> >> Also try changing "sysctl debug.ndis=1" and post console debug ouput >> >> again. >> > >> > This was strange. If I boot up and enable debugging before I try to >> > run '/etc/rc.d/netif start ndis0' everything works just fine. I get an >> > IP address and stay connected (at least under a light load). This is >> > the output: >> > >> > ndis_newstate: INIT -> INIT >> > ndis0: NDIS ERROR: c00013a7 (unknown error) >> > ndis0: NDIS ERROR: c0001392 (unknown error) >> >> these two errors means: >> >> EVENT_NDIS_ADAPTER_CHECK_ERROR >> EVENT_NDIS_INVALID_VALUE_FROM_ADAPTER >> >> Looks like minport driver doesnt like your card. >> Are you absolutly sure that you are using right miniport driver? > > Frankly, no. This laptop came with a broadcom minipci card. I > replaced it with the intel one that I'm now using since intel network > cards have native drivers under FreeBSD :-) I've downloaded the latest > drivers from the intel website > ( > http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Inst=Yes&ProductID=1637&DwnldID=17228&strOSs=45&OSFullName=Windows*%20XP%20Home%20Edition&lang=eng > ) > and used them to generate the driver with ndisgen. Is there a > recommended windows driver to use with ndis for this intel network card? > >> > Setting BSSID to ff:ff:ff:ff:ff:ff >> > Setting ESSID to "" >> > ndis0: no matching rate for: 108 >> > ndis_newstate: INIT -> RUN >> > ndis0: link state changed to UP >> > ndis_newstate: RUN -> INIT >> > Setting channel to 2412000kHz >> > ndis0: couldn't change DS config to 2412000kHz: 19 >> > Setting BSSID to ff:ff:ff:ff:ff:ff >> > Setting ESSID to "Mckella280Front" >> > ndis0: link state changed to DOWN >> > ndis0: no matching rate for: 108 >> > ndis_newstate: INIT -> RUN >> > ndis0: link state changed to UP >> > >> > If I then stop the network on that device, disable debug, and try to >> > start it up again, I get the same problem as before: >> > >> > ndis0: couldn't change DS config to 2412000kHz: 19 >> > ndis0: link state changed to DOWN >> > ndis0: no matching rate for: 108 >> > ndis0: link state changed to UP >> > ndis0: couldn't change DS config to 2412000kHz: 19 >> > ndis0: link state changed to DOWN >> > ndis0: no matching rate for: 108 >> > ndis0: link state changed to UP >> > ndis0: link state changed to DOWN >> > >> > If I then stop the network, enable debugging, and start up the network, >> > the problem persists. >> > >> >> You are starting ndis0 in same way in both cases? > > Yes. I booted up with the ifconfig_ndis0 line commented out > in /etc/rc.conf. I then uncommented the line, enabled debugging, and > started the network with '/etc/rc.d/netif start ndis0'. I then brought > the network down, disabled debugging, and started the network with the > same command. After stopping the interface, and re-enabling > networking, I started the interface with the same command the third > time. > > Adam > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > Did you copied whole ndis relevant debug output? scan results are missing. Are you using wpa_supplicant? -- Paul From adamk at voicenet.com Wed Feb 18 10:50:28 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Wed Feb 18 10:50:35 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <20090217133404.22275b25@memory.visualtech.com> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> Message-ID: <20090218134935.14f0a8c2@memory.visualtech.com> On Wed, 18 Feb 2009 19:27:36 +0100 "Paul B. Mahol" wrote: > On 2/18/09, Adam K Kirchhoff wrote: > > On Wed, 18 Feb 2009 16:33:56 +0100 > > "Paul B. Mahol" wrote: > > > >> On 2/18/09, Adam K Kirchhoff wrote: > >> > On Wed, 18 Feb 2009 12:06:21 +0100 > >> > "Paul B. Mahol" wrote: > >> > > >> >> On 2/17/09, Adam K Kirchhoff wrote: > >> >> > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: > >> >> >> On 2/17/09, Adam K Kirchhoff wrote: > >> >> >> > On Tue, 17 Feb 2009 19:22:22 +0100 > >> >> >> > > >> >> >> > "Paul B. Mahol" wrote: > >> >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 > >> >> >> >> > >> >> >> >> This one should not happen, 108 rate should get recognized. > >> >> >> >> I will try to reproduce it on CURRENT. > >> >> >> >> > >> >> >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not > >> >> >> >> change anything but you never know. > >> >> >> > > >> >> >> > Sorry, I must have copied and pasted the uname output from the > >> >> >> > wrong > >> >> >> > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 > >> >> >> > 16:37:18 > >> >> >> > EST 2009 :-) > >> >> >> > >> >> >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in > >> >> >> ndis_setstate() for setting OID_802_11_CONFIGURATION. > >> >> > > >> >> > Sorry if I seem slow, but are you asking me to check something there, > >> >> > or > >> >> > just > >> >> > stating what you think the problem is? :-) > >> >> > >> >> You can add printf() before "ndis_set_info(sc, > >> >> OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to > >> >> check what value for config.nc_dsconfig is by default. > >> > > >> > I'll try that shortly. > >> > > >> >> Also try changing "sysctl debug.ndis=1" and post console debug ouput > >> >> again. > >> > > >> > This was strange. If I boot up and enable debugging before I try to > >> > run '/etc/rc.d/netif start ndis0' everything works just fine. I get an > >> > IP address and stay connected (at least under a light load). This is > >> > the output: > >> > > >> > ndis_newstate: INIT -> INIT > >> > ndis0: NDIS ERROR: c00013a7 (unknown error) > >> > ndis0: NDIS ERROR: c0001392 (unknown error) > >> > >> these two errors means: > >> > >> EVENT_NDIS_ADAPTER_CHECK_ERROR > >> EVENT_NDIS_INVALID_VALUE_FROM_ADAPTER > >> > >> Looks like minport driver doesnt like your card. > >> Are you absolutly sure that you are using right miniport driver? > > > > Frankly, no. This laptop came with a broadcom minipci card. I > > replaced it with the intel one that I'm now using since intel network > > cards have native drivers under FreeBSD :-) I've downloaded the latest > > drivers from the intel website > > ( > > http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Inst=Yes&ProductID=1637&DwnldID=17228&strOSs=45&OSFullName=Windows*%20XP%20Home%20Edition&lang=eng > > ) > > and used them to generate the driver with ndisgen. Is there a > > recommended windows driver to use with ndis for this intel network card? > > > >> > Setting BSSID to ff:ff:ff:ff:ff:ff > >> > Setting ESSID to "" > >> > ndis0: no matching rate for: 108 > >> > ndis_newstate: INIT -> RUN > >> > ndis0: link state changed to UP > >> > ndis_newstate: RUN -> INIT > >> > Setting channel to 2412000kHz > >> > ndis0: couldn't change DS config to 2412000kHz: 19 > >> > Setting BSSID to ff:ff:ff:ff:ff:ff > >> > Setting ESSID to "Mckella280Front" > >> > ndis0: link state changed to DOWN > >> > ndis0: no matching rate for: 108 > >> > ndis_newstate: INIT -> RUN > >> > ndis0: link state changed to UP > >> > > >> > If I then stop the network on that device, disable debug, and try to > >> > start it up again, I get the same problem as before: > >> > > >> > ndis0: couldn't change DS config to 2412000kHz: 19 > >> > ndis0: link state changed to DOWN > >> > ndis0: no matching rate for: 108 > >> > ndis0: link state changed to UP > >> > ndis0: couldn't change DS config to 2412000kHz: 19 > >> > ndis0: link state changed to DOWN > >> > ndis0: no matching rate for: 108 > >> > ndis0: link state changed to UP > >> > ndis0: link state changed to DOWN > >> > > >> > If I then stop the network, enable debugging, and start up the network, > >> > the problem persists. > >> > > >> > >> You are starting ndis0 in same way in both cases? > > > > Yes. I booted up with the ifconfig_ndis0 line commented out > > in /etc/rc.conf. I then uncommented the line, enabled debugging, and > > started the network with '/etc/rc.d/netif start ndis0'. I then brought > > the network down, disabled debugging, and started the network with the > > same command. After stopping the interface, and re-enabling > > networking, I started the interface with the same command the third > > time. > > > > Adam > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > Did you copied whole ndis relevant debug output? > scan results are missing. > Are you using wpa_supplicant? Yes, I am using wpa_supplicant... I have ifconfig_ndis0="DHCP WPA" in my /etc/rc.conf file and the wpa_supplicant.conf file is presumably configured correctly as I am connecting. I'm pretty sure I copied every line that contained ndis, but I'll double check shortly. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nex84 at vtr.net Wed Feb 18 11:10:45 2009 From: nex84 at vtr.net (Felipe Jara Saba) Date: Wed Feb 18 11:10:52 2009 Subject: differentiated statistics for ipv4/ipv6 traffica? Message-ID: <499C4ECC.8050109@vtr.net> Hello: Has anyone tried to get differentiated statistics for ipv4/ipv6 traffic in a FreeBSD server?. I was hoping that I could retrieve that information through SNMP (I`m running net-snmp on a freebsd 7.1 box), but even though there is a IPv6-MIB.txt in the /usr/local/share/snmp/mibs dir, it seems it only shows the ipv4/ipv6 traffic combined into the same counters. Greetings -- Felipe Jara S. Estudiante Ingenieria Civil Telematica UTFSM http://www.telematica.utfsm.cl From adamk at voicenet.com Wed Feb 18 11:34:05 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Wed Feb 18 11:34:12 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <20090218134935.14f0a8c2@memory.visualtech.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <20090217133404.22275b25@memory.visualtech.com> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> <20090218134935.14f0a8c2@memory.visualtech.com> Message-ID: <20090218142659.135a73bc@memory.visualtech.com> On Wed, 18 Feb 2009 13:49:35 -0500 Adam K Kirchhoff wrote: > On Wed, 18 Feb 2009 19:27:36 +0100 > "Paul B. Mahol" wrote: > > > On 2/18/09, Adam K Kirchhoff wrote: > > > On Wed, 18 Feb 2009 16:33:56 +0100 > > > "Paul B. Mahol" wrote: > > > > > >> On 2/18/09, Adam K Kirchhoff wrote: > > >> > On Wed, 18 Feb 2009 12:06:21 +0100 > > >> > "Paul B. Mahol" wrote: > > >> > > > >> >> On 2/17/09, Adam K Kirchhoff wrote: > > >> >> > On Tuesday 17 February 2009 17:14:07 Paul B. Mahol wrote: > > >> >> >> On 2/17/09, Adam K Kirchhoff wrote: > > >> >> >> > On Tue, 17 Feb 2009 19:22:22 +0100 > > >> >> >> > > > >> >> >> > "Paul B. Mahol" wrote: > > >> >> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=131781 > > >> >> >> >> > > >> >> >> >> This one should not happen, 108 rate should get recognized. > > >> >> >> >> I will try to reproduce it on CURRENT. > > >> >> >> >> > > >> >> >> >> To OP, could you try 7 STABLE after 31 Jan? I guess it should not > > >> >> >> >> change anything but you never know. > > >> >> >> > > > >> >> >> > Sorry, I must have copied and pasted the uname output from the > > >> >> >> > wrong > > >> >> >> > machine. This is actually FreeBSD 7.1-STABLE #4: Mon Feb 16 > > >> >> >> > 16:37:18 > > >> >> >> > EST 2009 :-) > > >> >> >> > > >> >> >> miniport dump NDIS_STATUS_UNSUPPORTED_MEDIA for error in > > >> >> >> ndis_setstate() for setting OID_802_11_CONFIGURATION. > > >> >> > > > >> >> > Sorry if I seem slow, but are you asking me to check something there, > > >> >> > or > > >> >> > just > > >> >> > stating what you think the problem is? :-) > > >> >> > > >> >> You can add printf() before "ndis_set_info(sc, > > >> >> OID_802_11_CONFIGURATION, &config, &len);" in ndis_setstate_80211() to > > >> >> check what value for config.nc_dsconfig is by default. > > >> > > > >> > I'll try that shortly. > > >> > > > >> >> Also try changing "sysctl debug.ndis=1" and post console debug ouput > > >> >> again. > > >> > > > >> > This was strange. If I boot up and enable debugging before I try to > > >> > run '/etc/rc.d/netif start ndis0' everything works just fine. I get an > > >> > IP address and stay connected (at least under a light load). This is > > >> > the output: > > >> > > > >> > ndis_newstate: INIT -> INIT > > >> > ndis0: NDIS ERROR: c00013a7 (unknown error) > > >> > ndis0: NDIS ERROR: c0001392 (unknown error) > > >> > > >> these two errors means: > > >> > > >> EVENT_NDIS_ADAPTER_CHECK_ERROR > > >> EVENT_NDIS_INVALID_VALUE_FROM_ADAPTER > > >> > > >> Looks like minport driver doesnt like your card. > > >> Are you absolutly sure that you are using right miniport driver? > > > > > > Frankly, no. This laptop came with a broadcom minipci card. I > > > replaced it with the intel one that I'm now using since intel network > > > cards have native drivers under FreeBSD :-) I've downloaded the latest > > > drivers from the intel website > > > ( > > > http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&Inst=Yes&ProductID=1637&DwnldID=17228&strOSs=45&OSFullName=Windows*%20XP%20Home%20Edition&lang=eng > > > ) > > > and used them to generate the driver with ndisgen. Is there a > > > recommended windows driver to use with ndis for this intel network card? > > > > > >> > Setting BSSID to ff:ff:ff:ff:ff:ff > > >> > Setting ESSID to "" > > >> > ndis0: no matching rate for: 108 > > >> > ndis_newstate: INIT -> RUN > > >> > ndis0: link state changed to UP > > >> > ndis_newstate: RUN -> INIT > > >> > Setting channel to 2412000kHz > > >> > ndis0: couldn't change DS config to 2412000kHz: 19 > > >> > Setting BSSID to ff:ff:ff:ff:ff:ff > > >> > Setting ESSID to "Mckella280Front" > > >> > ndis0: link state changed to DOWN > > >> > ndis0: no matching rate for: 108 > > >> > ndis_newstate: INIT -> RUN > > >> > ndis0: link state changed to UP > > >> > > > >> > If I then stop the network on that device, disable debug, and try to > > >> > start it up again, I get the same problem as before: > > >> > > > >> > ndis0: couldn't change DS config to 2412000kHz: 19 > > >> > ndis0: link state changed to DOWN > > >> > ndis0: no matching rate for: 108 > > >> > ndis0: link state changed to UP > > >> > ndis0: couldn't change DS config to 2412000kHz: 19 > > >> > ndis0: link state changed to DOWN > > >> > ndis0: no matching rate for: 108 > > >> > ndis0: link state changed to UP > > >> > ndis0: link state changed to DOWN > > >> > > > >> > If I then stop the network, enable debugging, and start up the network, > > >> > the problem persists. > > >> > > > >> > > >> You are starting ndis0 in same way in both cases? > > > > > > Yes. I booted up with the ifconfig_ndis0 line commented out > > > in /etc/rc.conf. I then uncommented the line, enabled debugging, and > > > started the network with '/etc/rc.d/netif start ndis0'. I then brought > > > the network down, disabled debugging, and started the network with the > > > same command. After stopping the interface, and re-enabling > > > networking, I started the interface with the same command the third > > > time. > > > > > > Adam > > > > > > -- > > > This message has been scanned for viruses and > > > dangerous content by MailScanner, and is > > > believed to be clean. > > > > > > > > > > Did you copied whole ndis relevant debug output? > > scan results are missing. > > Are you using wpa_supplicant? > > Yes, I am using wpa_supplicant... I have ifconfig_ndis0="DHCP WPA" in > my /etc/rc.conf file and the wpa_supplicant.conf file is presumably > configured correctly as I am connecting. > > I'm pretty sure I copied every line that contained ndis, but I'll > double check shortly. Alright, here's the full 'dmesg' output from when I loaded the kernel module: ndis0: mem 0xdfcff000-0xdfcfffff irq 17 at device 3.0 on pci3 ndis0: [ITHREAD] ndis0: NDIS API version: 5.0 ndis0: WARNING: using obsoleted if_watchdog interface ndis0: Ethernet address: 00:13:ce:a8:10:ea fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 ndis_newstate: INIT -> INIT ndis0: couldn't change Testing config.nc_dsconfig: 0 Setting BSSID to ff:ff:ff:ff:ff:ff Setting ESSID to "" ndis0: no matching rate for: 108 ndis_newstate: INIT -> RUN ndis0: link state changed to UP ndis_newstate: RUN -> INIT ndis0: couldn't change Testing config.nc_dsconfig: 0 Setting channel to 2412000kHz ndis0: couldn't change DS config to 2412000kHz: 19 Setting BSSID to ff:ff:ff:ff:ff:ff Setting ESSID to "Mckella280Front" ndis0: link state changed to DOWN ndis0: no matching rate for: 108 ndis_newstate: INIT -> RUN ndis0: link state changed to UP ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis_newstate: RUN -> SCAN ndis0: link state changed to DOWN ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS ERROR: c00013a7 (unknown error) As soon as those NDIS ERRORs start, the connection seems to die. I think I edited if_ndis.c in the correct place and had it output what I think you wanted to see... Here's the diff, so please let me know if I grabbed the wrong information, or did it at the wrong place. If I did it correctly, it looks like config.nc_dsconfig is 0. --- if_ndis.c 2009-01-31 00:22:11.000000000 -0500 +++ if_ndis.c.orig 2009-02-18 14:03:30.000000000 -0500 @@ -2459,6 +2459,11 @@ bzero((char *)&config, len); config.nc_length = len; config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh); + + device_printf(sc->ndis_dev, "couldn't change " + "Testing config.nc_dsconfig: %u \n", + config.nc_dsconfig); + rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len); -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From info at ekipate.es Wed Feb 18 14:25:54 2009 From: info at ekipate.es (admin) Date: Wed Feb 18 14:26:08 2009 Subject: MEETING Message-ID: <909542d4da6f965360c1cf612684174c@www.ekipate.es> Estas buscando pareja. -- To unsubscribe from this list visit http://www.ekipate.es/lists/lt.php?id=YR5QBw0OUwAYCFpMAQ4FVAA%3D To update your preferences visit http://www.ekipate.es/lists/lt.php?id=YR5QBw0OUwEYCFpMAQ4FVAA%3D -- Powered by PHPlist, www.phplist.com -- From gavin at FreeBSD.org Wed Feb 18 14:28:28 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Feb 18 14:28:40 2009 Subject: kern/131776: [wi] driver fails to init Message-ID: <200902182228.n1IMSQce038958@freefall.freebsd.org> Old Synopsis: wi driver fails to init New Synopsis: [wi] driver fails to init Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Wed Feb 18 22:25:55 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=131776 From onemda at gmail.com Wed Feb 18 16:10:10 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Wed Feb 18 16:10:17 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <20090218142659.135a73bc@memory.visualtech.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> <20090218134935.14f0a8c2@memory.visualtech.com> <20090218142659.135a73bc@memory.visualtech.com> Message-ID: <3a142e750902181610h65f23d13vfeb20cc19ea0944a@mail.gmail.com> On 2/18/09, Adam K Kirchhoff wrote: > --- if_ndis.c 2009-01-31 00:22:11.000000000 -0500 > +++ if_ndis.c.orig 2009-02-18 14:03:30.000000000 -0500 > @@ -2459,6 +2459,11 @@ > bzero((char *)&config, len); > config.nc_length = len; > config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh); > + > + device_printf(sc->ndis_dev, "couldn't change " > + "Testing config.nc_dsconfig: %u \n", > + config.nc_dsconfig); > + > rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len); printf should be bellow ndis_get_info() and above ndis_set_info(). Does same problem happens when not using WPA eg. wpa_supplicant? -- Paul From adamk at voicenet.com Wed Feb 18 16:48:37 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Wed Feb 18 16:48:43 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <3a142e750902181610h65f23d13vfeb20cc19ea0944a@mail.gmail.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> <20090218134935.14f0a8c2@memory.visualtech.com> <20090218142659.135a73bc@memory.visualtech.com> <3a142e750902181610h65f23d13vfeb20cc19ea0944a@mail.gmail.com> Message-ID: <20090218194810.075e0c7c@sorrow.ashke.com> On Thu, 19 Feb 2009 01:10:08 +0100 "Paul B. Mahol" wrote: > On 2/18/09, Adam K Kirchhoff wrote: > > --- if_ndis.c 2009-01-31 00:22:11.000000000 -0500 > > +++ if_ndis.c.orig 2009-02-18 14:03:30.000000000 -0500 > > @@ -2459,6 +2459,11 @@ > > bzero((char *)&config, len); > > config.nc_length = len; > > config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh); > > + > > + device_printf(sc->ndis_dev, "couldn't change " > > + "Testing config.nc_dsconfig: %u \n", > > + config.nc_dsconfig); > > + > > rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len); > > printf should be bellow ndis_get_info() and above ndis_set_info(). Alright, I've moved the printf down a few lines and recompiled. > Does same problem happens when not using WPA eg. wpa_supplicant? It's actually been running just fine since I got home. I'm still using wpa_supplicant, but with WEP instead of WPA. This has been about four hours. Not much network traffic, but certainly more than what causes the problem at work. I'm going to let it continue to run through the night. I have a cron job setup to transfer several 800 meg files to this laptop via scp, so it'll be interesting to see if that works over this driver. Tomorrow morning, when I get into work, I'll grab the debug output again, this time with the printf (hopefully) in the correct place. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From info at ekipate.es Wed Feb 18 21:30:39 2009 From: info at ekipate.es (admin) Date: Wed Feb 18 21:30:57 2009 Subject: Publicidad Message-ID: <497f630791c64ec0904ce1d9492c2543@www.ekipate.es> Clic aqui si no ves la imagen -- To unsubscribe from this list visit http://www.ekipate.es/lists/lt.php?id=YR5SBAwKVAIYC1BMAQ4FVAA%3D To update your preferences visit http://www.ekipate.es/lists/lt.php?id=YR5SBAwKVAMYC1BMAQ4FVAA%3D -- Powered by PHPlist, www.phplist.com -- From adamk at voicenet.com Thu Feb 19 02:51:04 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Thu Feb 19 02:51:11 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <20090218194810.075e0c7c@sorrow.ashke.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> <20090218134935.14f0a8c2@memory.visualtech.com> <20090218142659.135a73bc@memory.visualtech.com> <3a142e750902181610h65f23d13vfeb20cc19ea0944a@mail.gmail.com> <20090218194810.075e0c7c@sorrow.ashke.com> Message-ID: <20090219055035.1ff55f19@memory.visualtech.com> On Wed, 18 Feb 2009 19:48:10 -0500 Adam K Kirchhoff wrote: > On Thu, 19 Feb 2009 01:10:08 +0100 > "Paul B. Mahol" wrote: > > > On 2/18/09, Adam K Kirchhoff wrote: > > > --- if_ndis.c 2009-01-31 00:22:11.000000000 -0500 > > > +++ if_ndis.c.orig 2009-02-18 14:03:30.000000000 -0500 > > > @@ -2459,6 +2459,11 @@ > > > bzero((char *)&config, len); > > > config.nc_length = len; > > > config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh); > > > + > > > + device_printf(sc->ndis_dev, "couldn't change " > > > + "Testing config.nc_dsconfig: %u \n", > > > + config.nc_dsconfig); > > > + > > > rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len); > > > > printf should be bellow ndis_get_info() and above ndis_set_info(). > > Alright, I've moved the printf down a few lines and recompiled. > > > Does same problem happens when not using WPA eg. wpa_supplicant? > > It's actually been running just fine since I got home. I'm still using > wpa_supplicant, but with WEP instead of WPA. This has been about four > hours. Not much network traffic, but certainly more than what causes > the problem at work. > > I'm going to let it continue to run through the night. I have a cron > job setup to transfer several 800 meg files to this laptop via scp, so > it'll be interesting to see if that works over this driver. > > Tomorrow morning, when I get into work, I'll grab the debug output > again, this time with the printf (hopefully) in the correct place. Looks like config.nc_dsconfig is 2462000 The wireless connection stayed up all night, even while transferring over 2 gigs of data via scp. The problem appears to be specific to this AP using WPA. I can try WPA on my home network in about 10 hours to see if the same happens there. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tamaru at myn.rcast.u-tokyo.ac.jp Thu Feb 19 02:57:46 2009 From: tamaru at myn.rcast.u-tokyo.ac.jp (Hiroharu Tamaru) Date: Thu Feb 19 02:57:53 2009 Subject: Can ASPM be disabled on 82573 to allow Jumbo Frames with em(4)? Message-ID: Hi I am not sure if I am understanding things right, but is it possible to forcibly disable ASPM in em(4) for 82573 devices? What I wanted to do is to use Jumbo Frames for these NICs and I saw in sys/dev/e1000/if_em.c that says: | static int | em_ioctl(struct ifnet *ifp, u_long command, caddr_t data) | { (snip) | case SIOCSIFMTU: (snip) | case e1000_82573: | /* | * 82573 only supports jumbo frames | * if ASPM is disabled. | */ | e1000_read_nvm(&adapter->hw, | NVM_INIT_3GIO_3, 1, &eeprom_data); | if (eeprom_data & NVM_WORD1A_ASPM_MASK) { | max_frame_size = ETHER_MAX_LEN; | break; | } | /* Allow Jumbo frames - fall thru */ | case e1000_82571: I also found that in Linux, they seem to disable ASPM for certain cases: http://kerneltrap.org/mailarchive/linux-netdev/2007/10/31/374573 So I started to wonder if there is a knob already in FreeBSD to disable ASPM for 82573 and (as a side effect?) allows one to use Jumbo Frames with this device, or I such can be introduced easily. It would be nice to be able to enable Jumbo Frames if the power consumption is not of a problem.. Thanks. Hiroharu From adamk at voicenet.com Thu Feb 19 13:19:57 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Thu Feb 19 13:20:03 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <20090219055035.1ff55f19@memory.visualtech.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <3a142e750902171414p438d184bl54a1569e27490634@mail.gmail.com> <200902171727.53156.adamk@voicenet.com> <3a142e750902180306x390fd549led076474f4fae06b@mail.gmail.com> <20090218080420.681788d2@memory.visualtech.com> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> <20090218134935.14f0a8c2@memory.visualtech.com> <20090218142659.135a73bc@memory.visualtech.com> <3a142e750902181610h65f23d13vfeb20cc19ea0944a@mail.gmail.com> <20090218194810.075e0c7c@sorrow.ashke.com> <20090219055035.1ff55f19@memory.visualtech.com> Message-ID: <20090219161807.63efaaa5@thorn.ashke.com> On Thu, 19 Feb 2009 05:50:35 -0500 Adam K Kirchhoff wrote: > On Wed, 18 Feb 2009 19:48:10 -0500 > Adam K Kirchhoff wrote: > > > On Thu, 19 Feb 2009 01:10:08 +0100 > > "Paul B. Mahol" wrote: > > > > > On 2/18/09, Adam K Kirchhoff wrote: > > > > --- if_ndis.c 2009-01-31 00:22:11.000000000 -0500 > > > > +++ if_ndis.c.orig 2009-02-18 14:03:30.000000000 -0500 > > > > @@ -2459,6 +2459,11 @@ > > > > bzero((char *)&config, len); > > > > config.nc_length = len; > > > > config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh); > > > > + > > > > + device_printf(sc->ndis_dev, "couldn't change " > > > > + "Testing config.nc_dsconfig: %u \n", > > > > + config.nc_dsconfig); > > > > + > > > > rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len); > > > > > > printf should be bellow ndis_get_info() and above ndis_set_info(). > > > > Alright, I've moved the printf down a few lines and recompiled. > > > > > Does same problem happens when not using WPA eg. wpa_supplicant? > > > > It's actually been running just fine since I got home. I'm still using > > wpa_supplicant, but with WEP instead of WPA. This has been about four > > hours. Not much network traffic, but certainly more than what causes > > the problem at work. > > > > I'm going to let it continue to run through the night. I have a cron > > job setup to transfer several 800 meg files to this laptop via scp, so > > it'll be interesting to see if that works over this driver. > > > > Tomorrow morning, when I get into work, I'll grab the debug output > > again, this time with the printf (hopefully) in the correct place. > > Looks like config.nc_dsconfig is 2462000 > > The wireless connection stayed up all night, even while transferring > over 2 gigs of data via scp. The problem appears to be specific to > this AP using WPA. I can try WPA on my home network in about 10 hours > to see if the same happens there. When I switched my home network to use WPA I started to have the same problems as with the WPA network at work. config.nc_dsconfig still reads 246200. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From onemda at gmail.com Thu Feb 19 13:38:18 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Thu Feb 19 13:38:25 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <20090219161807.63efaaa5@thorn.ashke.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> <20090218134935.14f0a8c2@memory.visualtech.com> <20090218142659.135a73bc@memory.visualtech.com> <3a142e750902181610h65f23d13vfeb20cc19ea0944a@mail.gmail.com> <20090218194810.075e0c7c@sorrow.ashke.com> <20090219055035.1ff55f19@memory.visualtech.com> <20090219161807.63efaaa5@thorn.ashke.com> Message-ID: <3a142e750902191338v7e2f3e9fna3b4ac77f0cbe612@mail.gmail.com> On 2/19/09, Adam K Kirchhoff wrote: > On Thu, 19 Feb 2009 05:50:35 -0500 > Adam K Kirchhoff wrote: > >> On Wed, 18 Feb 2009 19:48:10 -0500 >> Adam K Kirchhoff wrote: >> >> > On Thu, 19 Feb 2009 01:10:08 +0100 >> > "Paul B. Mahol" wrote: >> > >> > > On 2/18/09, Adam K Kirchhoff wrote: >> > > > --- if_ndis.c 2009-01-31 00:22:11.000000000 -0500 >> > > > +++ if_ndis.c.orig 2009-02-18 14:03:30.000000000 -0500 >> > > > @@ -2459,6 +2459,11 @@ >> > > > bzero((char *)&config, len); >> > > > config.nc_length = len; >> > > > config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh); >> > > > + >> > > > + device_printf(sc->ndis_dev, "couldn't change " >> > > > + "Testing config.nc_dsconfig: %u \n", >> > > > + config.nc_dsconfig); >> > > > + >> > > > rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len); >> > > >> > > printf should be bellow ndis_get_info() and above ndis_set_info(). >> > >> > Alright, I've moved the printf down a few lines and recompiled. >> > >> > > Does same problem happens when not using WPA eg. wpa_supplicant? >> > >> > It's actually been running just fine since I got home. I'm still using >> > wpa_supplicant, but with WEP instead of WPA. This has been about four >> > hours. Not much network traffic, but certainly more than what causes >> > the problem at work. >> > >> > I'm going to let it continue to run through the night. I have a cron >> > job setup to transfer several 800 meg files to this laptop via scp, so >> > it'll be interesting to see if that works over this driver. >> > >> > Tomorrow morning, when I get into work, I'll grab the debug output >> > again, this time with the printf (hopefully) in the correct place. >> >> Looks like config.nc_dsconfig is 2462000 >> >> The wireless connection stayed up all night, even while transferring >> over 2 gigs of data via scp. The problem appears to be specific to >> this AP using WPA. I can try WPA on my home network in about 10 hours >> to see if the same happens there. > > When I switched my home network to use WPA I started to have the same > problems as with the WPA network at work. config.nc_dsconfig still > reads 246200. Enable wpa_supplicant debugging and try find something interesting. I still cant understant why enabling debug.ndis hides problem. -- Paul From vince at unsane.co.uk Thu Feb 19 14:26:46 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Thu Feb 19 14:26:53 2009 Subject: differentiated statistics for ipv4/ipv6 traffica? In-Reply-To: <499C4ECC.8050109@vtr.net> References: <499C4ECC.8050109@vtr.net> Message-ID: <499DDCA2.5050108@unsane.co.uk> On 18/2/09 18:09, Felipe Jara Saba wrote: > Hello: > > Has anyone tried to get differentiated statistics for ipv4/ipv6 > traffic in a FreeBSD server?. I was hoping that I could retrieve that > information through SNMP (I`m running net-snmp on a freebsd 7.1 box), > but even though there is a IPv6-MIB.txt in the > /usr/local/share/snmp/mibs dir, it seems it only shows the ipv4/ipv6 > traffic combined into the same counters. > > Greetings > > Best I can think of is netstat. Should be enough info using the -i or -I arguments with -b (-h optional.) (22:20:27 <~>) 0 # netstat -i -bh -f inet6 Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll bge0 1500 fe80:1::2e0:8 fe80:1::2e0:81ff: 5.0K - 335K 5.0K - 340K - bge0 1500 2001:470:1f09 2001:470:1f09:110 1.6M - 291M 2.4M - 3.0G - em1 1500 fe80:3::207:e fe80:3::207:e9ff: 0 - 0 4 - 288 - lo0 16384 localhost ::1 637 - 74K 642 - 75K - lo0 16384 fe80:7::1 fe80:7::1 0 - 0 0 - 0 - root@crab (22:18:17 <~>) 0 # netstat -I bge0 -bh -f inet6 Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll bge0 1500 fe80:1::2e0:8 fe80:1::2e0:81ff: 4.9K - 334K 5.0K - 339K - bge0 1500 2001:470:1f09 2001:470:1f09:110 1.6M - 291M 2.4M - 3.0G - Hope that helps, Vince From laks_guy at yahoo.com Thu Feb 19 15:41:07 2009 From: laks_guy at yahoo.com (new2FreeBSD) Date: Thu Feb 19 15:41:14 2009 Subject: Plz help: Configuring routing protocols on Freebsd router Message-ID: <22111802.post@talk.nabble.com> Dear guys, I am new to FreeBSD and to this forum as well. Please help me as I am in middle of a project. My question is, can I configure the following routing protocols on a freebsd router, if so, how can I configure it. - Ad hoc on-demand distance vector routing protocol (AODV) - Optimized link state routing protocol (OLSR) - Dynamic source routing protocol (DSR) Thanks in advance. Regards, Simon -- View this message in context: http://www.nabble.com/Plz-help%3A-Configuring-routing-protocols-on-Freebsd-router-tp22111802p22111802.html Sent from the freebsd-net mailing list archive at Nabble.com. From steve at ibctech.ca Thu Feb 19 16:18:11 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Feb 19 16:18:18 2009 Subject: Plz help: Configuring routing protocols on Freebsd router In-Reply-To: <22111802.post@talk.nabble.com> References: <22111802.post@talk.nabble.com> Message-ID: <499DF077.20409@ibctech.ca> new2FreeBSD wrote: > Dear guys, > > I am new to FreeBSD and to this forum as well. Please help me as I am in > middle of a project. My question is, can I configure the following routing > protocols on a freebsd router, if so, how can I configure it. I could only find one. The rest may require some crafty Googling. > - Optimized link state routing protocol (OLSR) /usr/ports/net/olsrd Steve From pgnet.trash+fbsdnet at gmail.com Thu Feb 19 20:17:12 2009 From: pgnet.trash+fbsdnet at gmail.com (PGNet) Date: Thu Feb 19 20:17:19 2009 Subject: openvpn "HMAC auth" and TLS errors @ client connect? Message-ID: i'm taking a stab at setup of, openvpn --version OpenVPN 2.0.6 i386-portbld-freebsd6.3 [SSL] [LZO] built on Jul 18 2008 on a client's (read: i don't want to fubar this box!) headless router/firewall (running fbsd pf) box, uname -r 6.3-RELEASE-p3 i've setup, rc.conf openvpn_enable="YES" openvpn_configfile="/usr/local/etc/openvpn/openvpn.conf" openvpn_if="tun" @ server, "/usr/local/etc/openvpn/openvpn.conf" -------- server 172.30.7.0 255.255.255.0 dev tun1 proto udp port 22222 dh /usr/local/etc/openvpn/dh2048.pem ca /usr/local/etc/openvpn/mydomain.com.CA.cert.rsa.pem cert /usr/local/etc/openvpn/server.cert.rsa.pem key /usr/local/etc/openvpn/server.key.rsa.pem tls-auth /usr/local/etc/openvpn/ta.key 0 client-config-dir /usr/local/etc/openvpn/ccd ccd-exclusive max-clients 2 max-routes-per-client 128 connect-freq 3 60 cipher AES-256-CBC client-to-client comp-lzo keepalive 15 120 persist-key persist-tun status openvpn-status.log verb 4 -------- @ client, ".../openvpn.conf" -------- tls-client tls-remote ho3.mydomain.com remote 99.xx.xx.xx 22222 dev tun proto udp resolv-retry infinite keepalive 15 120 nobind persist-key persist-tun ca /usr/local/etc/openvpn/mydomain.com.CA.cert.rsa.pem cert /usr/local/etc/openvpn/client.cert.rsa.pem key /usr/local/etc/openvpn/client.key.rsa.pem tls-auth /usr/local/etc/openvpn/ta.key 1 ns-cert-type server cipher AES-256-CBC comp-lzo verb 4 pull -------- @ server, /usr/local/etc/rc.d/openvpn start Starting openvpn. add net 172.30.7.0: gateway 172.30.7.2 @ client connect, client logs show, ... Thu 02/19/09 07:28 PM: Control Channel Authentication: using '/usr/local/etc/openvpn/ta.key' as a OpenVPN static key file Thu 02/19/09 07:28 PM: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu 02/19/09 07:28 PM: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu 02/19/09 07:28 PM: LZO compression initialized Thu 02/19/09 07:28 PM: Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ] Thu 02/19/09 07:28 PM: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] Thu 02/19/09 07:28 PM: tls-client' Thu 02/19/09 07:28 PM: tls-server' Thu 02/19/09 07:28 PM: Local Options hash (VER=V4): '504e774e' Thu 02/19/09 07:28 PM: Expected Remote Options hash (VER=V4): '14168603' Thu 02/19/09 07:28 PM: Socket Buffers: R=[42080->65536] S=[9216->65536] Thu 02/19/09 07:28 PM: UDPv4 link local: [undef] Thu 02/19/09 07:28 PM: UDPv4 link remote: 99.xx.xx.xx:22222 Thu 02/19/09 07:28 PM: @ server syslog, Feb 19 19:28:21 server openvpn[3947]: Authenticate/Decrypt packet error: packet HMAC authentication failed Feb 19 19:28:21 server openvpn[3947]: TLS Error: incoming packet authentication failed from 192.168.1.6:51365 i tried to follow what online help i could find, but have clearly missed something. any suggestions as to what to fix? not sure what info to provide; happy to provide what's needed. thanks. From bakul at bitblocks.com Thu Feb 19 22:18:28 2009 From: bakul at bitblocks.com (Bakul Shah) Date: Thu Feb 19 22:18:34 2009 Subject: A more pliable firewall Message-ID: <20090220055936.035255B1B@mail.bitblocks.com> I am wondering if there is a more dynamic and scriptable firewall program. The idea is to send it alerts (with sender host address) whenever a dns probe fails or ssh login fails or smtpd finds it has been fed spam or your website is fed bad urls. This program will then update the firewall after a certain number of attempts have been made from a host within a given period. Right now, when I find bad guys blasting packets at me, I add a rule to pf.conf to drop all packets from these hosts but all this manual editing is getting old and the internet is getting more and more like the Wild West crossed with the Attack of the Zombies. From lstewart at room52.net Fri Feb 20 00:27:15 2009 From: lstewart at room52.net (Lawrence Stewart) Date: Fri Feb 20 00:27:22 2009 Subject: A more pliable firewall In-Reply-To: <20090220055936.035255B1B@mail.bitblocks.com> References: <20090220055936.035255B1B@mail.bitblocks.com> Message-ID: <499E641D.1060605@room52.net> Bakul Shah wrote: > I am wondering if there is a more dynamic and scriptable > firewall program. The idea is to send it alerts (with sender > host address) whenever a dns probe fails or ssh login fails > or smtpd finds it has been fed spam or your website is fed > bad urls. This program will then update the firewall after a > certain number of attempts have been made from a host within > a given period. > > Right now, when I find bad guys blasting packets at me, I add > a rule to pf.conf to drop all packets from these hosts but > all this manual editing is getting old and the internet is > getting more and more like the Wild West crossed with the > Attack of the Zombies. It's a fairly crude solution and doesn't address a lot of the features you mention, but I do this with PF on many of my FreeBSD machines (tuning the various timeout and connection rates as appropriate): # Drop packets from hosts trying to spam us with connections. # We rehabilitate this list by calling # "pfctl -t bad_hosts -T expire 600" from cron every few mins block drop in quick on $wan_if from # Allow TCP connections from the outside world to: # ssh (port 22) # https (port 443) # Attempting to connect more than 5 times in 30 seconds # will put you in the bad books for a while pass in quick on $wan_if inet proto tcp from any to ($wan_if) port { 22, 443 } keep state (max-src-conn-rate 5/30, overload flush global) It does a surprisingly good job at stopping a majority of cruft ending up in my security logs, and the rehabilitation via cron ensures any false positives don't require manual intervention to remove the offending IP(s) from the black list. There are also of course many options in ports, some of which are very sophisticated (e.g. snort, bro). Cheers, Lawrence From artem at aws-net.org.ua Fri Feb 20 01:03:25 2009 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Fri Feb 20 01:03:32 2009 Subject: A more pliable firewall In-Reply-To: <20090220055936.035255B1B@mail.bitblocks.com> References: <20090220055936.035255B1B@mail.bitblocks.com> Message-ID: On Thu, 19 Feb 2009, Bakul Shah wrote: > I am wondering if there is a more dynamic and scriptable > firewall program. The idea is to send it alerts (with sender > host address) whenever a dns probe fails or ssh login fails > or smtpd finds it has been fed spam or your website is fed > bad urls. This program will then update the firewall after a > certain number of attempts have been made from a host within > a given period. > > Right now, when I find bad guys blasting packets at me, I add > a rule to pf.conf to drop all packets from these hosts but Actually, you can use tables and add these ip-s to tables while leave pf.conf untouchable. The only thing to resolv is to write some daemon which will receive notifyes and update pf tables. It should be not so hard to write such piece of software. > all this manual editing is getting old and the internet is > getting more and more like the Wild West crossed with the > Attack of the Zombies. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From adamk at voicenet.com Fri Feb 20 04:51:40 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Fri Feb 20 04:51:46 2009 Subject: kern/131781: [ndis] ndis keeps dropping the link In-Reply-To: <3a142e750902191338v7e2f3e9fna3b4ac77f0cbe612@mail.gmail.com> References: <200902171720.n1HHKkIf071491@freefall.freebsd.org> <3a142e750902180733o679b050ck8d9287f0bdd860e7@mail.gmail.com> <20090218111223.4483b923@memory.visualtech.com> <3a142e750902181027q25863f39ycc342d6506949eb9@mail.gmail.com> <20090218134935.14f0a8c2@memory.visualtech.com> <20090218142659.135a73bc@memory.visualtech.com> <3a142e750902181610h65f23d13vfeb20cc19ea0944a@mail.gmail.com> <20090218194810.075e0c7c@sorrow.ashke.com> <20090219055035.1ff55f19@memory.visualtech.com> <20090219161807.63efaaa5@thorn.ashke.com> <3a142e750902191338v7e2f3e9fna3b4ac77f0cbe612@mail.gmail.com> Message-ID: <20090220073902.193c929d@voicenet.com> On Thu, 19 Feb 2009 22:38:16 +0100 "Paul B. Mahol" wrote: > On 2/19/09, Adam K Kirchhoff wrote: > > On Thu, 19 Feb 2009 05:50:35 -0500 > > Adam K Kirchhoff wrote: > > > >> On Wed, 18 Feb 2009 19:48:10 -0500 > >> Adam K Kirchhoff wrote: > >> > >> > On Thu, 19 Feb 2009 01:10:08 +0100 > >> > "Paul B. Mahol" wrote: > >> > > >> > > On 2/18/09, Adam K Kirchhoff wrote: > >> > > > --- if_ndis.c 2009-01-31 00:22:11.000000000 -0500 > >> > > > +++ if_ndis.c.orig 2009-02-18 14:03:30.000000000 -0500 > >> > > > @@ -2459,6 +2459,11 @@ > >> > > > bzero((char *)&config, len); > >> > > > config.nc_length = len; > >> > > > config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh); > >> > > > + > >> > > > + device_printf(sc->ndis_dev, "couldn't change " > >> > > > + "Testing config.nc_dsconfig: %u \n", > >> > > > + config.nc_dsconfig); > >> > > > + > >> > > > rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len); > >> > > > >> > > printf should be bellow ndis_get_info() and above ndis_set_info(). > >> > > >> > Alright, I've moved the printf down a few lines and recompiled. > >> > > >> > > Does same problem happens when not using WPA eg. wpa_supplicant? > >> > > >> > It's actually been running just fine since I got home. I'm still using > >> > wpa_supplicant, but with WEP instead of WPA. This has been about four > >> > hours. Not much network traffic, but certainly more than what causes > >> > the problem at work. > >> > > >> > I'm going to let it continue to run through the night. I have a cron > >> > job setup to transfer several 800 meg files to this laptop via scp, so > >> > it'll be interesting to see if that works over this driver. > >> > > >> > Tomorrow morning, when I get into work, I'll grab the debug output > >> > again, this time with the printf (hopefully) in the correct place. > >> > >> Looks like config.nc_dsconfig is 2462000 > >> > >> The wireless connection stayed up all night, even while transferring > >> over 2 gigs of data via scp. The problem appears to be specific to > >> this AP using WPA. I can try WPA on my home network in about 10 hours > >> to see if the same happens there. > > > > When I switched my home network to use WPA I started to have the same > > problems as with the WPA network at work. config.nc_dsconfig still > > reads 246200. > > Enable wpa_supplicant debugging and try find something interesting. > I still cant understant why enabling debug.ndis hides problem. Well, one mystery hopefully solved. It looks like it has nothing to do with enabling debug.ndis. Instead, it seems related to the fact that it connects the first time I bring up the interface, whether debug.ndis is enabled or not. Of course, all my attempts at running wpa_supplicant directly from a terminal, with debugging enabled, has resulted in a working connection. I'll have to do more testing to see if I can find some consistency in this problem. Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From max at love2party.net Fri Feb 20 05:30:15 2009 From: max at love2party.net (Max Laier) Date: Fri Feb 20 05:30:22 2009 Subject: A more pliable firewall In-Reply-To: References: <20090220055936.035255B1B@mail.bitblocks.com> Message-ID: <200902201430.12311.max@love2party.net> On Friday 20 February 2009 09:28:49 Artyom Viklenko wrote: > On Thu, 19 Feb 2009, Bakul Shah wrote: > > I am wondering if there is a more dynamic and scriptable > > firewall program. The idea is to send it alerts (with sender > > host address) whenever a dns probe fails or ssh login fails > > or smtpd finds it has been fed spam or your website is fed > > bad urls. This program will then update the firewall after a > > certain number of attempts have been made from a host within > > a given period. > > > > Right now, when I find bad guys blasting packets at me, I add > > a rule to pf.conf to drop all packets from these hosts but > > Actually, you can use tables and add these ip-s to tables > while leave pf.conf untouchable. The only thing to resolv > is to write some daemon which will receive notifyes and update > pf tables. It should be not so hard to write such piece > of software. /usr/ports/net-mgmt/pftabled]> cat pkg-descr The pftabled daemon is a small helper to make your pf tables reachable from other hosts. You can add/delete/flush IP addresses to/from a remote table with a single UDP datagram. A simple client program is included to do this from the command line. WWW: http://wolfermann.org/pftabled.html > > all this manual editing is getting old and the internet is > > getting more and more like the Wild West crossed with the > > Attack of the Zombies. > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From smithi at nimnet.asn.au Fri Feb 20 05:43:07 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Feb 20 05:43:14 2009 Subject: A more pliable firewall In-Reply-To: References: <20090220055936.035255B1B@mail.bitblocks.com> Message-ID: <20090220235840.I46613@sola.nimnet.asn.au> On Fri, 20 Feb 2009, Artyom Viklenko wrote: > On Thu, 19 Feb 2009, Bakul Shah wrote: > > > I am wondering if there is a more dynamic and scriptable > > firewall program. The idea is to send it alerts (with sender > > host address) whenever a dns probe fails or ssh login fails > > or smtpd finds it has been fed spam or your website is fed > > bad urls. This program will then update the firewall after a > > certain number of attempts have been made from a host within > > a given period. > > > > Right now, when I find bad guys blasting packets at me, I add > > a rule to pf.conf to drop all packets from these hosts but > > > Actually, you can use tables and add these ip-s to tables > while leave pf.conf untouchable. The only thing to resolv > is to write some daemon which will receive notifyes and update > pf tables. It should be not so hard to write such piece > of software. /usr/ports/security/fwlogwatch DESCRIPTION fwlogwatch produces Linux ipchains, Linux netfilter/iptables, Solaris/BSD/Irix/HP-UX ipfilter, ipfw, Cisco IOS, Cisco PIX, NetScreen, Windows XP firewall, Elsa Lancom router and Snort IDS log summary reports in plain text and HTML form and has a lot of options to analyze and display relevant patterns. It can produce customizable incident reports and send them to abuse contacts at offending sites or CERTs. Finally, it can also run as daemon (with web interface) doing realtime log monitoring and reporting anomalies or starting attack countermea- sures. I notice it doesn't mention pf, but it might be worth checking out; it calls your scripts on detection by various rules and looks customisable. Thanks to Michael Butler, who pointed out how to add table entries with it, with a timestamp value allowing removal of 'stale' entries by cron. > > all this manual editing is getting old and the internet is > > getting more and more like the Wild West crossed with the > > Attack of the Zombies. Indeed. Having lots of fun with ipfw tables here, most lately detecting and so ceasing participation in forged-source DNS amplification attacks. cheers, Ian From kmacy at freebsd.org Fri Feb 20 09:24:18 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri Feb 20 09:26:35 2009 Subject: panic: _rw_wlock_hard In-Reply-To: <910e60e80902180150n41a592ffyb62ea53beb24f1ef@mail.gmail.com> References: <910e60e80902180150n41a592ffyb62ea53beb24f1ef@mail.gmail.com> Message-ID: <3c1674c90902200924p79d8d66dg9584182a1e662047@mail.gmail.com> Known issue. I haven't been around to fix. Cheers, Kip On Wed, Feb 18, 2009 at 1:50 AM, dikshie wrote: > Hi, > does anyone see this panic on -HEAD: > > panic: _rw_wlock_hard: recursing but non-recursive rw radix node head > @ /usr/src/sys/net/route.c:831 > > kdb_enter() at kdb_enter+0x3a > panic() at panic+0x136 > _rw_wlock_hard() at _rw_wlock_hard+0x66 > _rw_wlock() at _rw_wlock+0xae > rtquest1_fib() at rtquest1_fib+0x95 > rtquest_fib() at rtquest_fib+0x5e > in_rtquest() at in_rtquest+0x3b > in_rtqkill() at in_rtqkill+0x7f > rn_walktree() at rn_walktree+0x65 > in_rtqtimo() at in_rtqtimo+0xb0 > softclock() at softclock+0x24a > intr_event_execute_handlers() at intr_event_execute_handlers+0x125 > ithread_loop() at ithread_loop+0x9f > fork_exit() at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > > -HEAD built on Feb 16 14:26:25 JST. > > > > > > -- > -dikshie- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From nugundam at nugundam.best.vwh.net Fri Feb 20 11:50:04 2009 From: nugundam at nugundam.best.vwh.net (Joseph Lee) Date: Fri Feb 20 11:50:13 2009 Subject: kern/124753: [ieee80211] net80211 discards power-save queue packets early Message-ID: <200902201950.n1KJo3Wk060047@freefall.freebsd.org> The following reply was made to PR kern/124753; it has been noted by GNATS. From: Joseph Lee To: bug-followup@FreeBSD.org, nugundam@nugundam.best.vwh.net Cc: Subject: Re: kern/124753: [ieee80211] net80211 discards power-save queue packets early Date: Fri, 20 Feb 2009 11:12:16 -0800 ath0: flags=8943 metric 0 mtu 2290 ether 00:11:95:8d:17:89 inet6 fe80::211:95ff:fe8d:1789%ath0 prefixlen 64 scopeid 0x2 inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: associated ssid AP channel 1 (2412 Mhz 11g) bssid 00:11:95:8d:17:89 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS wme burst hidessid dtimperiod 1 I've noticed with tcpdump that every time the mobile station queries for power-saved packets, there's a couple of arp who-has packets sent out: 10:30:59.744056 arp who-has AP tell mobile 10:30:59.744104 arp who-has AP tell mobile Also, packet requests never make it up to the tcpdump level. Setting bintval to 25 (instead of the default 100), allows packets to be queued longer but still not passed on: Here's a debug dump from exactly when the WiFi is turned on, on the mobile device with bintval @ 25: Feb 20 10:37:01 AP kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps mode Feb 20 10:37:01 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now queued Feb 20 10:37:01 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 now queued Feb 20 10:37:01 AP kernel: ath0: [00:18:41:c0:06:54] power save mode off, 0 sta's in ps mode Feb 20 10:37:01 AP kernel: ath0: [00:18:41:c0:06:54] flush ps queue, 2 packets queue Feb 20 10:37:01 AP kernel: ath0: [00:18:41:c0:06:54] power save mode on, 1 sta's in ps mode Feb 20 10:37:01 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now queued Feb 20 10:37:06 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 now queued Feb 20 10:37:06 AP kernel: ath0: [00:18:41:c0:06:54] discard frame, age 0 Feb 20 10:37:06 AP kernel: ath0: [00:18:41:c0:06:54] discard frame, age 0 Feb 20 10:37:06 AP kernel: ath0: [00:18:41:c0:06:54] discard 2 frames for age Feb 20 10:37:07 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now queued Feb 20 10:37:16 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 now queued Feb 20 10:37:21 AP kernel: ath0: [00:18:41:c0:06:54] discard frame, age 0 Feb 20 10:37:21 AP kernel: ath0: [00:18:41:c0:06:54] discard frame, age 0 Feb 20 10:37:21 AP kernel: ath0: [00:18:41:c0:06:54] discard 2 frames for age Feb 20 10:37:22 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now queued Feb 20 10:37:25 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 now queued Feb 20 10:37:31 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 3 now queued Feb 20 10:37:36 AP kernel: ath0: [00:18:41:c0:06:54] discard frame, age 0 Feb 20 10:37:36 AP last message repeated 2 times Feb 20 10:37:36 AP kernel: ath0: [00:18:41:c0:06:54] discard 3 frames for age Feb 20 10:37:39 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 1 now queued Feb 20 10:37:45 AP kernel: ath0: [00:18:41:c0:06:54] save frame with age 0, 2 now queued Feb 20 10:37:51 AP kernel: ath0: [00:18:41:c0:06:54] discard frame, age 0 Feb 20 10:37:51 AP kernel: ath0: [00:18:41:c0:06:54] discard frame, age 0 Feb 20 10:37:51 AP kernel: ath0: [00:18:41:c0:06:54] discard 2 frames for age I do not what the meaning of the arp requests are for. Thanks. Joseph From artem at aws-net.org.ua Fri Feb 20 12:45:20 2009 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Fri Feb 20 12:47:47 2009 Subject: A more pliable firewall In-Reply-To: <200902201430.12311.max@love2party.net> References: <20090220055936.035255B1B@mail.bitblocks.com> <200902201430.12311.max@love2party.net> Message-ID: <200902202207.29379.artem@aws-net.org.ua> On Friday 20 February 2009 15:30:11 Max Laier wrote: > On Friday 20 February 2009 09:28:49 Artyom Viklenko wrote: > > On Thu, 19 Feb 2009, Bakul Shah wrote: > > > I am wondering if there is a more dynamic and scriptable > > > firewall program. The idea is to send it alerts (with sender > > > host address) whenever a dns probe fails or ssh login fails > > > or smtpd finds it has been fed spam or your website is fed > > > bad urls. This program will then update the firewall after a > > > certain number of attempts have been made from a host within > > > a given period. > > > > > > Right now, when I find bad guys blasting packets at me, I add > > > a rule to pf.conf to drop all packets from these hosts but > > > > Actually, you can use tables and add these ip-s to tables > > while leave pf.conf untouchable. The only thing to resolv > > is to write some daemon which will receive notifyes and update > > pf tables. It should be not so hard to write such piece > > of software. > > /usr/ports/net-mgmt/pftabled]> cat pkg-descr > The pftabled daemon is a small helper to make your pf > tables reachable from other hosts. You can add/delete/flush > IP addresses to/from a remote table with a single UDP > datagram. A simple client program is included to do this > from the command line. > > WWW: http://wolfermann.org/pftabled.html > Wonderful! Thanks a lot! :) > > > all this manual editing is getting old and the internet is > > > getting more and more like the Wild West crossed with the > > > Attack of the Zombies. > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- ? ? ? ? ? ? Sincerely yours, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net ? | ================================ FreeBSD: The Power to Serve ? - ?http://www.freebsd.org From bakul at bitblocks.com Fri Feb 20 12:50:05 2009 From: bakul at bitblocks.com (Bakul Shah) Date: Fri Feb 20 12:53:26 2009 Subject: A more pliable firewall In-Reply-To: Your message of "Sat, 21 Feb 2009 00:30:02 +1100." <20090220235840.I46613@sola.nimnet.asn.au> References: <20090220055936.035255B1B@mail.bitblocks.com> <20090220235840.I46613@sola.nimnet.asn.au> Message-ID: <20090220205003.301AB5B3E@mail.bitblocks.com> Thanks to everyone who responded. Looks like all the pieces to do this exist. All I have to do is to package it all in one program "sheriff" that watches various log files and pulls the trigger on the bad guy(s) at appropriate time. I think I will add a program to keep running stats on *all* the tcp/udp senders to find all those annoyingly pesky repeat senders who have no business talking to my network. What would be nice is a standard interface to report suspicious failures (sort of like syslog). If the same guy sends N DNS requests for the same thing and every request fails, chances are he is a bad guy (or a zombie acting on behalf of one). Perhaps some day a trusted network of such daemons can be used to "back pressure" the closest ISP to the sender -- who can then shut him down for a while. From lwindschuh at googlemail.com Fri Feb 20 16:17:01 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Fri Feb 20 16:20:53 2009 Subject: ifconfig tun0 destroy: panic: Bad link elm ... prev->next != elm Message-ID: <90a5caac0902201550l4bf5878x17fd77c9c188a4ec@mail.gmail.com> Hi guys. This is a kind of follow-up to PR kern/116837 (please mark as solved?). The described issue is solved, but now we have this issue. The following simple steps lead to a kernel panic on my system (i386, SMP, CURRENT from Feb. 18th): -->8-- cat < /dev/tun0 > /dev/tun0 & ifconfig tun0 up ifconfig tun0 destroy & ifconfig tun0 destroy --8<-- Panic string: Bad link elm 0xc6437c00 prev->next != elm Responsible backtraces: Tracing pid 1610 tid 100114 td 0xc686f240 kdb_enter(c090abd7,c090abd7,c08e2418,eaefeb6c,0,...) at kdb_enter+0x3a panic(c08e2418,c6437c00,c091867f,d3,2d,...) at panic+0x136 if_clone_destroyif(c0976300,c6437c00,c091867f,bf,0,...) at if_clone_destroyif+0x8a if_clone_destroy(c724f320,19c,eaefebd4,c0604976,c1494788,...) at if_clone_destroy+0xa2 ifioctl(c7077dc8,80206979,c724f320,c686f240,80206979,...) at ifioctl+0x116 soo_ioctl(c71deaf0,80206979,c724f320,c722a000,c686f240,...) at soo_ioctl+0x397 kern_ioctl(c686f240,3,80206979,c724f320,64c3c0,...) at kern_ioctl+0x1dd ioctl(c686f240,eaefecf8,c,c,c09644b0,...) at ioctl+0x134 syscall(eaefed38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 Tracing command ifconfig pid 1611 tid 100194 td 0xc6c9b000 sched_switch(c6c9b000,0,104,18d,5796c911,...) at sched_switch+0x437 mi_switch(104,0,c090edc3,1d2,0,...) at mi_switch+0x200 sleepq_switch(c6c9b000,0,c090edc3,247,c6c9b000,...) at sleepq_switch+0x15f sleepq_wait(c69aa850,0,c0918d9f,1,0,...) at sleepq_wait+0x63 _cv_wait_unlock(c69aa850,c69aa83c,c0918d76,102,c69aa800,...) at _cv_wait_unlock+0x1d4 tun_destroy(c09ca0d8,0,c0918d76,11c) at tun_destroy+0x49 tun_clone_destroy(c6437c00,c6437c00,c6437c00,c0976300,eb04eb88,...) at tun_clone_destroy+0xb8 ifc_simple_destroy(c0976300,c6437c00,c091867f,d5,2d,...) at ifc_simple_destroy+0x27 if_clone_destroyif(c0976300,c6437c00,c091867f,bf,0,...) at if_clone_destroyif+0xe1 if_clone_destroy(c677cb20,19c,eb04ebd4,c0604976,c1494788,...) at if_clone_destroy+0xa2 ifioctl(c7257620,80206979,c677cb20,c6c9b000,80206979,...) at ifioctl+0x116 soo_ioctl(c7285bd0,80206979,c677cb20,c722a000,c6c9b000,...) at soo_ioctl+0x397 kern_ioctl(c6c9b000,3,80206979,c677cb20,64c3c0,...) at kern_ioctl+0x1dd ioctl(c6c9b000,eb04ecf8,c,c,c09644b0,...) at ioctl+0x134 syscall(eb04ed38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281b4b83, esp = 0xbfbfe47c, ebp = 0xbfbfe498 --- OK, it's odd to destroy an interface two times in parallel. But it shouldn't crash the kernel. ;-) This panic is triggered reliably. To rule out side effects of my kernel config, I ran the same test with the GENERIC config and got the same result: panic. The textdump is available here: http://sites.google.com/site/lwfreebsd/Home/files/tun0-double-destroy.zip?attredirects=0 I can supply more information if needed. Kind regards, Lucius From steve at ibctech.ca Fri Feb 20 17:56:07 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri Feb 20 17:56:13 2009 Subject: VLAN access and sub-int Message-ID: <499F5F30.3010503@ibctech.ca> Hi all, I'm in a bit of a pinch. I need to set up a VLAN from a FreeBSD box to a Cisco catalyst switch, but I am not in a position to test this in a lab before I deploy it. Currently, I've got em5 to a catalyst switch. There are no vlans in place on this switch at this point (other than native 1). What I'd like to do, is configure an em5.107 sub-int, and configure the physically connected switch port as a trunk, carrying the native vlan (1) as well as vlan 107. I've already got the em5.107 interface created. I'm just worried about changing the switch port to trunk mode remotely. The switch is in an odd location in the network, and I need this vlan lit up as a temporary hack until I can physically get to the location to move some cabling. What I'm asking is if I change the switchport mode on the physically connected switch port to trunk, will the native em5 interface deal with the untagged traffic by default? FWIW, I do have access via SSH to a device that has a console cable via cuad0 directly connected to the switch, if the worst should happen. Steve From steve at ibctech.ca Fri Feb 20 18:48:03 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri Feb 20 18:48:10 2009 Subject: VLAN access and sub-int In-Reply-To: <499F5F30.3010503@ibctech.ca> References: <499F5F30.3010503@ibctech.ca> Message-ID: <499F6B5A.4090300@ibctech.ca> Steve Bertrand wrote: > What I'm asking is if I change the switchport mode on the physically > connected switch port to trunk, will the native em5 interface deal with > the untagged traffic by default? ...upon 'testing' on production gear, it works just fine. em5 continues to pick up the untagged traffic, and em5.107 properly handles the vlan 107 traffic. Steve From smithi at nimnet.asn.au Fri Feb 20 20:09:45 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Feb 20 20:09:52 2009 Subject: A more pliable firewall In-Reply-To: <20090220205003.301AB5B3E@mail.bitblocks.com> References: <20090220055936.035255B1B@mail.bitblocks.com> <20090220235840.I46613@sola.nimnet.asn.au> <20090220205003.301AB5B3E@mail.bitblocks.com> Message-ID: <20090221135053.J46613@sola.nimnet.asn.au> On Fri, 20 Feb 2009, Bakul Shah wrote: > Thanks to everyone who responded. Looks like all the pieces > to do this exist. All I have to do is to package it all in > one program "sheriff" that watches various log files and > pulls the trigger on the bad guy(s) at appropriate time. Wild West imagery indeed :) > I think I will add a program to keep running stats on *all* > the tcp/udp senders to find all those annoyingly pesky repeat > senders who have no business talking to my network. Be prepared for a very, very large list! Maybe needing some sort of tree/trie or hashing algorithm to handle quickly as it grows. You'll also need some expiry mechanism after a period, as many if not most of these are transient scans from infected 'doze boxes, trojans du jour. And that after you've ignored the near-constant 'background radiation' from 'doze boxes to eg TCP dst-ports 135,139,445,1433 and others, and UDP dst-ports 135,137,138,1433,1434,1900 etc; no use chasing such more or less constant misconfigs, they'll only mask more interesting stuff. > What would be nice is a standard interface to report > suspicious failures (sort of like syslog). If the same guy > sends N DNS requests for the same thing and every request > fails, chances are he is a bad guy (or a zombie acting on > behalf of one). Perhaps some day a trusted network of such > daemons can be used to "back pressure" the closest ISP to the > sender -- who can then shut him down for a while. One note of caution: TCP is straightforward enough, the three-way handshake verifying the source address (if it proceeds to connection). However it's trivial to forge UDP source addresses, as the recent DNS amplification attacks I mentioned amply demonstrate. In such cases, the address appearing to be sending DNS requests logged as, say, "address#port query (cache) './NS/IN' denied" is the *victim* of such attacks, and blocking all access to/from such addresses, often nameservers of large ISPs, amounts to shooting yourself in the foot as well as further punishing the victim - the unknown attacker's intention! In that case it's sufficient to block 'from $victim to $me 53', still allowing $me to query their nameservers, eg to send them some mail :) good luck, Ian From lwindschuh at googlemail.com Sat Feb 21 06:10:02 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Sat Feb 21 06:10:09 2009 Subject: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic Message-ID: <200902211410.n1LEA2Lu029103@freefall.freebsd.org> The following reply was made to PR kern/116837; it has been noted by GNATS. From: Lucius Windschuh To: bug-followup@freebsd.org Cc: Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic Date: Sat, 21 Feb 2009 14:27:45 +0100 This is a follow-up to PR kern/116837. The described issue is solved, but now we have this issue. The following simple steps lead to a kernel panic on my system (i386, SMP, 8-CURRENT from Feb. 18th): -->8-- cat < /dev/tun0 > /dev/tun0 & ifconfig tun0 up ifconfig tun0 destroy & ifconfig tun0 destroy --8<-- Panic string: Bad link elm 0xc6437c00 prev->next != elm Responsible backtraces: Tracing pid 1610 tid 100114 td 0xc686f240 kdb_enter(c090abd7,c090abd7,c08e2418,eaefeb6c,0,...) at kdb_enter+0x3a panic(c08e2418,c6437c00,c091867f,d3,2d,...) at panic+0x136 if_clone_destroyif(c0976300,c6437c00,c091867f,bf,0,...) at if_clone_destroyif+0x8a if_clone_destroy(c724f320,19c,eaefebd4,c0604976,c1494788,...) at if_clone_destroy+0xa2 ifioctl(c7077dc8,80206979,c724f320,c686f240,80206979,...) at ifioctl+0x116 soo_ioctl(c71deaf0,80206979,c724f320,c722a000,c686f240,...) at soo_ioctl+0x397 kern_ioctl(c686f240,3,80206979,c724f320,64c3c0,...) at kern_ioctl+0x1dd ioctl(c686f240,eaefecf8,c,c,c09644b0,...) at ioctl+0x134 syscall(eaefed38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 Tracing command ifconfig pid 1611 tid 100194 td 0xc6c9b000 sched_switch(c6c9b000,0,104,18d,5796c911,...) at sched_switch+0x437 mi_switch(104,0,c090edc3,1d2,0,...) at mi_switch+0x200 sleepq_switch(c6c9b000,0,c090edc3,247,c6c9b000,...) at sleepq_switch+0x15f sleepq_wait(c69aa850,0,c0918d9f,1,0,...) at sleepq_wait+0x63 _cv_wait_unlock(c69aa850,c69aa83c,c0918d76,102,c69aa800,...) at _cv_wait_unlock+0x1d4 tun_destroy(c09ca0d8,0,c0918d76,11c) at tun_destroy+0x49 tun_clone_destroy(c6437c00,c6437c00,c6437c00,c0976300,eb04eb88,...) at tun_clone_destroy+0xb8 ifc_simple_destroy(c0976300,c6437c00,c091867f,d5,2d,...) at ifc_simple_destroy+0x27 if_clone_destroyif(c0976300,c6437c00,c091867f,bf,0,...) at if_clone_destroyif+0xe1 if_clone_destroy(c677cb20,19c,eb04ebd4,c0604976,c1494788,...) at if_clone_destroy+0xa2 ifioctl(c7257620,80206979,c677cb20,c6c9b000,80206979,...) at ifioctl+0x116 soo_ioctl(c7285bd0,80206979,c677cb20,c722a000,c6c9b000,...) at soo_ioctl+0x397 kern_ioctl(c6c9b000,3,80206979,c677cb20,64c3c0,...) at kern_ioctl+0x1dd ioctl(c6c9b000,eb04ecf8,c,c,c09644b0,...) at ioctl+0x134 syscall(eb04ed38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281b4b83, esp = 0xbfbfe47c, ebp = 0xbfbfe498 --- OK, it's odd to destroy an interface two times in parallel. But it shouldn't crash the kernel. ;-) This panic is triggered reliably. To rule out side effects of my kernel config, I ran the same test with the GENERIC config and got the same result: panic. The textdump is available here: http://sites.google.com/site/lwfreebsd/Home/files/tun0-double-destroy.zip?attredirects=0 I can supply more information if needed. Kind regards, Lucius From rwatson at FreeBSD.org Sat Feb 21 06:50:32 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Feb 21 06:50:39 2009 Subject: panic: _rw_wlock_hard In-Reply-To: <910e60e80902180150n41a592ffyb62ea53beb24f1ef@mail.gmail.com> References: <910e60e80902180150n41a592ffyb62ea53beb24f1ef@mail.gmail.com> Message-ID: On Wed, 18 Feb 2009, dikshie wrote: > does anyone see this panic on -HEAD: > > panic: _rw_wlock_hard: recursing but non-recursive rw radix node head @ > /usr/src/sys/net/route.c:831 > > kdb_enter() at kdb_enter+0x3a > panic() at panic+0x136 > _rw_wlock_hard() at _rw_wlock_hard+0x66 > _rw_wlock() at _rw_wlock+0xae > rtquest1_fib() at rtquest1_fib+0x95 > rtquest_fib() at rtquest_fib+0x5e > in_rtquest() at in_rtquest+0x3b > in_rtqkill() at in_rtqkill+0x7f > rn_walktree() at rn_walktree+0x65 > in_rtqtimo() at in_rtqtimo+0xb0 > softclock() at softclock+0x24a > intr_event_execute_handlers() at intr_event_execute_handlers+0x125 > ithread_loop() at ithread_loop+0x9f > fork_exit() at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > > -HEAD built on Feb 16 14:26:25 JST. Something like the following may help -- build-tested but not not run-time tested: Index: in_rmx.c =================================================================== --- in_rmx.c (revision 186118) +++ in_rmx.c (working copy) @@ -230,6 +230,8 @@ struct rtentry *rt = (struct rtentry *)rn; int err; + RADIX_NODE_HEAD_WLOCK_ASSERT(ap->rnh); + if (rt->rt_flags & RTPRF_OURS) { ap->found++; @@ -240,7 +242,8 @@ err = in_rtrequest(RTM_DELETE, (struct sockaddr *)rt_key(rt), rt->rt_gateway, rt_mask(rt), - rt->rt_flags, 0, rt->rt_fibnum); + rt->rt_flags | RTF_RNH_LOCKED, 0, + rt->rt_fibnum); if (err) { log(LOG_WARNING, "in_rtqkill: error %d\n", err); } else { From rwatson at FreeBSD.org Sat Feb 21 07:23:52 2009 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Sat Feb 21 07:23:59 2009 Subject: kern/130652: [kernel] [patch] Possible deadlock in rt_check() (sys/net/route.c) Message-ID: <200902211523.n1LFNqtb088770@freefall.freebsd.org> Synopsis: [kernel] [patch] Possible deadlock in rt_check() (sys/net/route.c) Responsible-Changed-From-To: freebsd-net->rwatson Responsible-Changed-By: rwatson Responsible-Changed-When: Sat Feb 21 15:22:13 UTC 2009 Responsible-Changed-Why: Grab ownership of this PR since I'm taking a look at deadlocks relating to routing in 7.x currently. http://www.freebsd.org/cgi/query-pr.cgi?pr=130652 From archi.kun at gmail.com Sat Feb 21 23:50:03 2009 From: archi.kun at gmail.com (Duckhawk) Date: Sat Feb 21 23:50:11 2009 Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Message-ID: <200902220750.n1M7o3NA061575@freefall.freebsd.org> The following reply was made to PR kern/124127; it has been noted by GNATS. From: Duckhawk To: bug-followup@FreeBSD.org, skylord@linkline.ru Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Sun, 22 Feb 2009 12:26:51 +0500 --001636c5a26744f2de04637ccfc6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit also, same problem. D-Link DGE-560T %uname -a FreeBSD 7.1-STABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009 duckhawk@:/usr/obj/usr/src/sys/GENERIC i386 %dmesg | grep "msk" mskc0: port 0x7000-0x70ff mem 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1 msk0: on mskc0 msk0: Ethernet address: 00:1b:11:79:53:eb miibus0: on msk0 mskc0: [FILTER] %pciconf -lv mskc0@pci0:1:0:0: class=0x020000 card=0x4b001186 chip=0x4b001186 rev=0x13 hdr=0x00 vendor = 'D-Link System Inc' device = 'DGE-560T PCIe Gigabit Ethernet Adapter' class = network subclass = ethernet --001636c5a26744f2de04637ccfc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable also, same problem. D-Link DGE-560T

%uname -a
FreeBSD  7.1-S= TABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009   = ;  duckhawk@:/usr/obj/usr/src/sys/GENERIC  i386

%dmesg | g= rep "msk"
mskc0: <D-Link 560T Gigabit Ethernet> port 0x7= 000-0x70ff mem 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1
msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on ms= kc0
msk0: Ethernet address: 00:1b:11:79:53:eb
miibus0: <MII bus>= ; on msk0
mskc0: [FILTER]

%pciconf -lv
mskc0@pci0:1:0:0: =       class=3D0x020000 card=3D0x4b001186 chip=3D0x= 4b001186 rev=3D0x13 hdr=3D0x00
    vendor     =3D 'D-Link System In= c'
    device     =3D 'DGE-56= 0T PCIe Gigabit Ethernet Adapter'
    class &nbs= p;    =3D network
    subclass  = =3D ethernet
--001636c5a26744f2de04637ccfc6-- From pawel.marek at gamar.info Sun Feb 22 02:50:11 2009 From: pawel.marek at gamar.info (pawel) Date: Sun Feb 22 02:50:18 2009 Subject: bin/127192 Message-ID: <000601c994d8$155d69a0$6701a8c0@IBM> Hello This problem only on 7.x not on 6.x When turn off routed , ever think is ok . When start routed problem "network is unreachable" for one of address in alias iface From bugmaster at FreeBSD.org Mon Feb 23 03:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Feb 23 03:08:38 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200902231106.n1NB6u06055581@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131310 net [panic] 7.1 panics with mpd netgraph interface changes o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw o kern/130846 net [vge] vge0 not autonegotiating to 1000baseTX full dupl o kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R f kern/130605 net [tcp] Certain hardware produces "Network is unreachabl o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o bin/130159 net [patch] ppp(8) fails to correctly set routes o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129846 net [panic] /usr/sbin/ppp causes panic "Sleeping thread ow o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [panic] Kernel panic with EtherIP (may be related to S o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f f kern/114899 net [bge] bge0: watchdog timeout -- resetting o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre] [patch] gre(4) is not MPSAFE and does not suppor o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100839 net [txp] txp driver inconsistently stops working when the o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/89876 net [txp] [patch] txp driver doesn't work with latest firm f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [patch] for static ARP tables in rc.network 260 problems total. From david.gueluy at netasq.com Mon Feb 23 03:14:43 2009 From: david.gueluy at netasq.com (=?ISO-8859-1?Q?david_gu=E9luy?=) Date: Mon Feb 23 03:14:52 2009 Subject: bad usage of the shutdown system call produce a packet with null ip addresses Message-ID: Hi, By using a PFIL_HOOK on FreeBSD 7.1-prerelease, I notice that I receive some packets from 0.0.0.0 to 0.0.0.0. A buggy program in userland produce these packets when the shutdown system call is used on a socket which is not connected. Even if it's a bad usage of a system call, this case can produce strange behaviours, I think it's necessary to add some checks in tcp_usr_shutdown. Here is a short sample to reproduce that case : test.c #include #include int main(void) { int fd; fd = socket(AF_INET, SOCK_STREAM, 0); if (fd == -1) return 1; shutdown(fd, SHUT_RDWR); close(fd); return 0; } Add some debug in the kernel [usr/src/sys/netinet]# diff -C4 ip_output.c.origin ip_output.c *** ip_output.c.origin Mon Feb 23 10:27:52 2009 --- ip_output.c Fri Feb 20 15:23:39 2009 *************** *** 135,142 **** --- 135,151 ---- hlen = len; } ip = mtod(m, struct ip *); + #define PRINTIP(a) printf("%u.%u.%u.%u", (unsigned)ntohl(a)>>24&0xFF, (unsigned)ntohl(a)>>16&0xFF, (unsigned)ntohl(a)>>8&0xFF, (unsigned)ntohl(a)&0xFF) + + if (m->m_pkthdr.rcvif != NULL) + printf(" if %s ", m->m_pkthdr.rcvif->if_xname); + printf(" proto %d src ", (int)ip->ip_p); PRINTIP(ip- >ip_src.s_addr); + printf(" dst "); PRINTIP(ip->ip_dst.s_addr); + printf(" ttl %u\n", (unsigned)ip->ip_ttl); + + ./test proto 6 src 0.0.0.0 dst 0.0.0.0 ttl 64 Best regards, Gu?luy David From rwatson at FreeBSD.org Mon Feb 23 15:01:16 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Feb 23 15:01:22 2009 Subject: panic: _rw_wlock_hard In-Reply-To: References: <910e60e80902180150n41a592ffyb62ea53beb24f1ef@mail.gmail.com> Message-ID: On Sat, 21 Feb 2009, Robert Watson wrote: > Something like the following may help -- build-tested but not not run-time > tested: I've now committed this patch to head as r188962 -- thanks for the report! Robert N M Watson Computer Laboratory University of Cambridge > > Index: in_rmx.c > =================================================================== > --- in_rmx.c (revision 186118) > +++ in_rmx.c (working copy) > @@ -230,6 +230,8 @@ > struct rtentry *rt = (struct rtentry *)rn; > int err; > > + RADIX_NODE_HEAD_WLOCK_ASSERT(ap->rnh); > + > if (rt->rt_flags & RTPRF_OURS) { > ap->found++; > > @@ -240,7 +242,8 @@ > err = in_rtrequest(RTM_DELETE, > (struct sockaddr *)rt_key(rt), > rt->rt_gateway, rt_mask(rt), > - rt->rt_flags, 0, rt->rt_fibnum); > + rt->rt_flags | RTF_RNH_LOCKED, 0, > + rt->rt_fibnum); > if (err) { > log(LOG_WARNING, "in_rtqkill: error %d\n", > err); > } else { > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From rwatson at FreeBSD.org Mon Feb 23 15:32:57 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Feb 23 15:33:04 2009 Subject: bad usage of the shutdown system call produce a packet with null ip addresses In-Reply-To: References: Message-ID: On Mon, 23 Feb 2009, david gu?luy wrote: > By using a PFIL_HOOK on FreeBSD 7.1-prerelease, I notice that I receive some > packets from 0.0.0.0 to 0.0.0.0. > > A buggy program in userland produce these packets when the shutdown system > call is used on a socket which is not connected. > > Even if it's a bad usage of a system call, this case can produce strange > behaviours, I think it's necessary to add some checks in tcp_usr_shutdown. > > Here is a short sample to reproduce that case : Definitely a bug -- could I ask you to file a PR on this, and forward me the PR receipt from GNATS? I can take a look at this, but probably not for a week or so and don't want to lose track of it. Most likely this is a result of the changes to add INP_DROPPED and make the inpcb persist after disconnect, in some way or another. Robert N M Watson Computer Laboratory University of Cambridge > > test.c > > #include > #include > > int main(void) > { > int fd; > > fd = socket(AF_INET, SOCK_STREAM, 0); > if (fd == -1) > return 1; > shutdown(fd, SHUT_RDWR); > close(fd); > return 0; > } > > Add some debug in the kernel > > [usr/src/sys/netinet]# diff -C4 ip_output.c.origin ip_output.c > *** ip_output.c.origin Mon Feb 23 10:27:52 2009 > --- ip_output.c Fri Feb 20 15:23:39 2009 > *************** > *** 135,142 **** > --- 135,151 ---- > hlen = len; > } > ip = mtod(m, struct ip *); > > + #define PRINTIP(a) printf("%u.%u.%u.%u", (unsigned)ntohl(a)>>24&0xFF, > (unsigned)ntohl(a)>>16&0xFF, (unsigned)ntohl(a)>>8&0xFF, > (unsigned)ntohl(a)&0xFF) > + > + if (m->m_pkthdr.rcvif != NULL) > + printf(" if %s ", m->m_pkthdr.rcvif->if_xname); > + printf(" proto %d src ", (int)ip->ip_p); > PRINTIP(ip->ip_src.s_addr); > + printf(" dst "); PRINTIP(ip->ip_dst.s_addr); > + printf(" ttl %u\n", (unsigned)ip->ip_ttl); > + > + > > ./test > proto 6 src 0.0.0.0 dst 0.0.0.0 ttl 64 > > Best regards, > Gu?luy David > From david.gueluy at netasq.com Tue Feb 24 01:51:07 2009 From: david.gueluy at netasq.com (=?ISO-8859-1?Q?david_gu=E9luy?=) Date: Tue Feb 24 01:51:14 2009 Subject: bad usage of the shutdown system call produce a packet with null ip addresses In-Reply-To: References: Message-ID: <9860FE97-C8CE-46F2-BE58-AAB84739BA45@netasq.com> Hi, A PR is submitted kern/132050: bad usage of the shutdown system call produce a packet with null ip addresses http://www.freebsd.org/cgi/query-pr.cgi?pr=132050 Le 24 f?vr. 09 ? 00:32, Robert Watson a ?crit : > > Definitely a bug -- could I ask you to file a PR on this, and > forward me the PR receipt from GNATS? I can take a look at this, > but probably not for a week or so and don't want to lose track of > it. Most likely this is a result of the changes to add INP_DROPPED > and make the inpcb persist after disconnect, in some way or another. > > Robert N M Watson > Computer Laboratory > University of Cambridge >> Best Regards, Gueluy David From rwatson at FreeBSD.org Tue Feb 24 11:30:02 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Feb 24 11:30:20 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed (was: Re: Wiki page for non-MPSAFE network stack de-orbit scheduling) In-Reply-To: References: <20080526110543.J26343@fledge.watson.org> Message-ID: On Mon, 16 Feb 2009, Robert Watson wrote: > The following schedule is proposed, assuming nothing goes horribly wrong > with the new USB code in the next few weeks, and remaining nits relating to > USB network and 802.11 drivers are handled: > > 16 February 2009 HEADS UP to lists (this e-mail) > 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x > 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x > > In the next couple of weeks, I'd like to resolve the status of (and > eliminate) the if_ndis conditional use of IFF_NEEDSGIANT. There's also a > chance that if_sl will get updated by Ed and myself to work with the new > locking and TTY world orders -- the lock is easy, but the TTY update takes a > bit of work. Perhaps someone will feel moved to do this for if_ppp and > possibly if_cx as well. Just a reminder that 1 March is gradually approaching. It looks like the new USB stack is settling nicely, so I currently have no plans to defer the above schedule. Robert N M Watson Computer Laboratory University of Cambridge From dfilter at FreeBSD.ORG Tue Feb 24 17:20:04 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Tue Feb 24 17:20:17 2009 Subject: kern/89876: commit references a PR Message-ID: <200902250120.n1P1K4KT034290@freefall.freebsd.org> The following reply was made to PR kern/89876; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/89876: commit references a PR Date: Wed, 25 Feb 2009 01:13:14 +0000 (UTC) Author: yongari Date: Wed Feb 25 01:12:56 2009 New Revision: 189022 URL: http://svn.freebsd.org/changeset/base/189022 Log: Update to latest 3Com firmware image. The latest fimware is required to make 3CR990 familiy controllers run on NV flash firmware version 03.001.008. The latest firmware added HMAC digest information so teach txp(4) to pass them to sleep image before downloading is started. While I'm here restore previous IMR/IER register if firmware downloading have failed. PR: kern/89876, kern/132047 Modified: head/sys/dev/txp/3c990img.h head/sys/dev/txp/if_txp.c head/sys/dev/txp/if_txpreg.h Modified: head/sys/dev/txp/3c990img.h ============================================================================== --- head/sys/dev/txp/3c990img.h Wed Feb 25 00:58:08 2009 (r189021) +++ head/sys/dev/txp/3c990img.h Wed Feb 25 01:12:56 2009 (r189022) @@ -1,22 +1,17 @@ -/* $OpenBSD: 3c990img.h,v 1.2 2001/06/05 02:15:17 jason Exp $ */ -/* $FreeBSD$ */ +/* $FreeBSD$ */ /*- - * Copyright (C) 1999-2001 3Com, Inc. - * All rights reserved. + * Copyright 1999-2003 3Com Corporation. All Rights Reserved. * - * Redistribution and use in source and binary forms of the 3CR990 microcode - * are permitted provided - * that the following conditions are met: + * Redistribution and use in source and binary forms of the 3c990img.h + * microcode software are permitted provided that the following conditions + * are met: * 1. Redistribution of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistribution in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. - * 3. All advertising materials mentioning features or use of this software - * must display the following acknowledgement: - * This product includes 3CR990 microcode - * 4. The name of 3Com may not be used to endorse or promote products + * 3. The name of 3Com may not be used to endorse or promote products * derived from this software without specific prior written permission * * THIS SOFTWARE IS PROVIDED BY 3COM ``AS IS'' AND ANY EXPRESS OR @@ -30,735 +25,458 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * USER ACKNOWLEDGES AND AGREES THAT PURCHASE OR USE OF THE 3CR990 microcode - * SOFTWARE WILL NOT CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, - * ESTOPPEL, OR OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT, - * TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN ANY OTHER - * 3COM HARDWARE OR SOFTWARE EITHER SOLELY OR IN COMBINATION WITH THE 3CR990 - * microcode SOFTWARE - */ + * USER ACKNOWLEDGES AND AGREES THAT PURCHASE OR USE OF THE 3c990img.h + * MICROCODE SOFTWARE WILL NOT CREATE OR GIVE GROUNDS FOR A LICENSE BY + * IMPLICATION, ESTOPPEL, OR OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS + * (PATENT, COPYRIGHT, TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) + * EMBODIED IN ANY OTHER 3COM HARDWARE OR SOFTWARE EITHER SOLELY OR IN + * COMBINATION WITH THE 3c990img.h MICROCODE SOFTWARE + */ unsigned char tc990image[] = { 0x54, 0x59, 0x50, 0x48, 0x4f, 0x4f, 0x4e, 0x00, 0x02, 0x00, 0x00, 0x00, -0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x40, 0x01, 0x00, 0x00, -0xd6, 0xbb, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x39, 0x00, 0x00, 0xea, -0x05, 0x00, 0x00, 0xea, 0x04, 0x00, 0x00, 0xea, 0x03, 0x00, 0x00, 0xea, -0x02, 0x00, 0x00, 0xea, 0x01, 0x00, 0x00, 0xea, 0x4a, 0x05, 0x00, 0xea, -0xb4, 0x1d, 0x00, 0xea, 0x07, 0x00, 0x2d, 0xe9, 0x0e, 0x00, 0xa0, 0xe1, -0x00, 0x10, 0x0f, 0xe1, 0xd0, 0x20, 0x9f, 0xe5, 0x12, 0xff, 0x2f, 0xe1, -0xfe, 0xff, 0xff, 0xea, 0x01, 0x00, 0x80, 0xe0, 0x04, 0x20, 0x81, 0xe4, -0x01, 0x00, 0x50, 0xe1, 0xfc, 0xff, 0xff, 0x1a, 0x0e, 0xf0, 0xa0, 0xe1, -0x00, 0xa0, 0xa0, 0xe1, 0x0e, 0xb0, 0xa0, 0xe1, 0x00, 0x00, 0xa0, 0xe3, -0xa8, 0x10, 0x9f, 0xe5, 0x00, 0x00, 0x81, 0xe5, 0xa4, 0x10, 0x9f, 0xe5, -0x00, 0x00, 0x81, 0xe5, 0x01, 0x16, 0xa0, 0xe3, 0x00, 0x00, 0x91, 0xe5, -0x01, 0x00, 0x80, 0xe3, 0x00, 0x00, 0x81, 0xe5, 0xd7, 0x00, 0xa0, 0xe3, -0x00, 0xf0, 0x21, 0xe1, 0x88, 0xd0, 0x9f, 0xe5, 0xdb, 0x00, 0xa0, 0xe3, -0x00, 0xf0, 0x21, 0xe1, 0x7c, 0xd0, 0x9f, 0xe5, 0xd2, 0x00, 0xa0, 0xe3, -0x00, 0xf0, 0x21, 0xe1, 0x74, 0xd0, 0x9f, 0xe5, 0xd1, 0x00, 0xa0, 0xe3, -0x00, 0xf0, 0x21, 0xe1, 0x6c, 0xd0, 0x9f, 0xe5, 0x8a, 0x1d, 0x00, 0xeb, -0xd3, 0x00, 0xa0, 0xe3, 0x00, 0xf0, 0x21, 0xe1, 0x60, 0xd0, 0x9f, 0xe5, -0x60, 0x00, 0x9f, 0xe5, 0x60, 0x10, 0x9f, 0xe5, 0x60, 0x20, 0x9f, 0xe5, -0xdb, 0xff, 0xff, 0xeb, 0x5c, 0x00, 0x9f, 0xe5, 0x5c, 0x10, 0x9f, 0xe5, -0x00, 0x20, 0xa0, 0xe3, 0xd7, 0xff, 0xff, 0xeb, 0x54, 0x00, 0x9f, 0xe5, -0x54, 0x10, 0x9f, 0xe5, 0xd4, 0xff, 0xff, 0xeb, 0x0a, 0x00, 0xa0, 0xe1, -0x0b, 0xf0, 0xa0, 0xe1, 0xd3, 0x10, 0xa0, 0xe3, 0x01, 0xf0, 0x21, 0xe1, -0xd4, 0xff, 0xff, 0xeb, 0x3c, 0xa0, 0x9f, 0xe5, 0x1a, 0xff, 0x2f, 0xe1, -0xc6, 0xff, 0xff, 0xea, 0x01, 0x2e, 0xff, 0xff, 0x0c, 0x00, 0x10, 0x00, -0x1c, 0x00, 0x10, 0x00, 0x3c, 0x38, 0x00, 0x80, 0xfc, 0x37, 0x00, 0x80, -0xfc, 0x3f, 0x00, 0x80, 0xfc, 0x33, 0x00, 0x80, 0x00, 0x10, 0x00, 0x00, -0x00, 0x30, 0x00, 0x80, 0xad, 0xde, 0xad, 0xde, 0xc8, 0xc2, 0x00, 0x00, -0x20, 0xab, 0x20, 0x40, 0x5c, 0x2b, 0x00, 0x00, 0x9c, 0x04, 0x00, 0x80, -0xd1, 0xd1, 0x21, 0x40, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x00, 0x00, -0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x00, 0x00, -0x00, 0x00, 0x00, 0x00, 0x40, 0x7b, 0x00, 0x00, 0x4d, 0x42, 0x00, 0x00, -0x60, 0x01, 0xff, 0xff, 0xb0, 0xb5, 0x07, 0x1c, 0x12, 0x4c, 0x00, 0x25, -0x60, 0x6b, 0x00, 0x28, 0x1d, 0xd0, 0x38, 0x1c, 0x10, 0x49, 0x06, 0xf0, -0x55, 0xff, 0x61, 0x6b, 0xc0, 0x46, 0x08, 0x60, 0x00, 0x28, 0x14, 0xd0, -0x38, 0x01, 0x0d, 0x49, 0x40, 0x18, 0x19, 0x23, 0xdb, 0x01, 0xc0, 0x18, -0x41, 0x6b, 0x80, 0x29, 0x0b, 0xd2, 0x01, 0x31, 0x41, 0x63, 0x60, 0x6b, -0xc1, 0x69, 0xc0, 0x46, 0x61, 0x63, 0x39, 0x07, 0x41, 0x60, 0xc7, 0x62, -0xb0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x28, 0x1c, 0xfa, 0xe7, 0x00, 0x00, -0x38, 0x17, 0x00, 0x80, 0xee, 0x05, 0x00, 0x00, 0x58, 0x1d, 0x00, 0x80, -0x02, 0x49, 0x4a, 0x6b, 0xc0, 0x46, 0xc2, 0x61, 0x48, 0x63, 0x70, 0x47, -0x38, 0x17, 0x00, 0x80, 0x00, 0x20, 0x02, 0x49, 0xc0, 0x46, 0x48, 0x61, -0x70, 0x47, 0x00, 0x00, 0x9c, 0x04, 0x00, 0x80, -0x00, 0xb5, 0x00, 0x20, 0x04, 0x49, 0xc0, 0x46, 0x48, 0x61, 0x04, 0x48, -0x04, 0x49, 0x09, 0x68, 0x07, 0xf0, 0xa3, 0xf9, 0x08, 0xbc, 0x18, 0x47, -0x9c, 0x04, 0x00, 0x80, 0xdd, 0x01, 0xff, 0xff, 0x74, 0x76, 0x21, 0x40, -0xf0, 0xb5, 0x04, 0x1c, 0x41, 0x4e, 0x00, 0x25, 0x70, 0x69, 0x00, 0x28, -0x03, 0xd1, 0xff, 0xf7, 0xa7, 0xff, 0x07, 0x1c, 0x03, 0xd1, 0x28, 0x1c, -0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x3c, 0x21, 0x00, 0x20, 0x79, 0x60, -0xbd, 0x60, 0x06, 0xf0, 0x2f, 0xff, 0x00, 0x20, 0x79, 0x68, 0x00, 0x29, -0x06, 0xd9, 0x39, 0x68, 0xc0, 0x46, 0x0d, 0x54, 0x79, 0x68, 0x01, 0x30, -0x81, 0x42, 0xf8, 0xd8, 0x39, 0x68, 0x00, 0x20, 0xff, 0x23, 0x0a, 0x18, -0x13, 0x70, 0x43, 0x08, 0x05, 0xd3, 0x43, 0x08, 0x5b, 0x00, 0x1b, 0x19, -0x1b, 0x89, 0x1b, 0x0a, 0x05, 0xe0, 0x43, 0x08, 0x5b, 0x00, 0x1b, 0x19, -0x1b, 0x89, 0x1b, 0x06, 0x1b, 0x0e, 0x93, 0x71, 0x01, 0x30, 0x06, 0x28, -0xea, 0xd3, 0xc1, 0x20, 0xc0, 0x00, 0x08, 0x73, 0x03, 0x0a, 0x4b, 0x73, -0x38, 0x68, 0xff, 0x21, 0x01, 0x31, 0x81, 0x73, 0x0b, 0x0a, 0xc3, 0x73, -0x08, 0x22, 0x02, 0x74, 0x13, 0x0a, 0x43, 0x74, 0x06, 0x22, 0x82, 0x74, -0x04, 0x22, 0xc2, 0x74, 0x01, 0x75, 0x0b, 0x0a, 0x43, 0x75, 0x0e, 0x30, -0x00, 0x21, 0x4a, 0x00, 0x13, 0x19, 0x1d, 0x89, 0x16, 0x18, 0x35, 0x72, -0x2b, 0x0a, 0x73, 0x72, 0x00, 0x25, 0x17, 0x4e, 0x92, 0x19, 0xd5, 0x81, -0x01, 0x31, 0x03, 0x29, 0xf1, 0xd3, 0x21, 0x68, 0xc0, 0x46, 0x81, 0x73, -0x0b, 0x0a, 0xc3, 0x73, 0x0b, 0x0c, 0x03, 0x74, 0x0b, 0x0e, 0x43, 0x74, -0x31, 0x60, 0x61, 0x68, 0xc0, 0x46, 0x01, 0x76, 0x0b, 0x0a, 0x43, 0x76, -0x0b, 0x0c, 0x83, 0x76, 0x0b, 0x0e, 0xc3, 0x76, 0x71, 0x60, 0x60, 0x69, -0xc0, 0x46, 0x70, 0x61, 0xa0, 0x69, 0xc0, 0x46, 0xb0, 0x61, 0x38, 0x1c, -0x06, 0xf0, 0x3a, 0xff, 0x38, 0x1c, 0xff, 0xf7, 0x61, 0xff, 0x05, 0x48, -0x05, 0x49, 0x0b, 0x68, 0x05, 0x4a, 0x00, 0x21, 0x07, 0xf0, 0x19, 0xf9, -0x01, 0x20, 0x85, 0xe7, 0x9c, 0x04, 0x00, 0x80, 0xdd, 0x01, 0xff, 0xff, -0x70, 0x76, 0x21, 0x40, 0x98, 0x3a, 0x00, 0x00, 0x90, 0xb5, 0x1d, 0x4f, -0x79, 0x69, 0x00, 0x29, 0x32, 0xd0, 0x80, 0x6a, 0x01, 0x7b, 0x43, 0x7b, -0x1b, 0x02, 0x19, 0x43, 0xc1, 0x23, 0xdb, 0x00, 0x99, 0x42, 0x29, 0xd1, -0x01, 0x7d, 0x43, 0x7d, 0x1b, 0x02, 0x19, 0x43, 0x01, 0x23, 0x5b, 0x02, -0x0e, 0x30, 0x99, 0x42, 0x20, 0xd1, 0xc3, 0x1d, 0x07, 0x33, 0x14, 0xcb, -0x9b, 0x07, 0xdb, 0x0e, 0xda, 0x40, 0x5b, 0x42, 0x20, 0x33, 0x9c, 0x40, -0x14, 0x43, 0x79, 0x68, 0xa1, 0x42, 0x13, 0xd1, 0x00, 0x21, 0x4a, 0x00, -0x13, 0x18, 0x1c, 0x7a, 0x5b, 0x7a, 0x1b, 0x02, 0x1c, 0x43, 0xd2, 0x19, -0xd4, 0x81, 0x01, 0x31, 0x09, 0x06, 0x09, 0x0e, 0x03, 0x29, 0xf2, 0xdb, -0x79, 0x69, 0x38, 0x1c, 0x07, 0xf0, 0xd7, 0xf8, 0x00, 0x20, 0x78, 0x61, -0x90, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, 0x9c, 0x04, 0x00, 0x80, -0xf0, 0xb5, 0x07, 0x1c, 0x01, 0x25, 0x20, 0x48, 0x01, 0x22, 0x00, 0x21, -0x03, 0x68, 0x08, 0x20, 0x07, 0xf0, 0xc7, 0xf8, 0x04, 0x1c, 0xff, 0x2c, -0x03, 0xd1, 0x00, 0x20, 0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x20, 0x1c, -0x19, 0x4e, 0x00, 0x22, 0x11, 0x21, 0x33, 0x68, 0x07, 0xf0, 0xb9, 0xf8, -0xff, 0x23, 0x45, 0x33, 0x98, 0x42, 0x1e, 0xd1, 0x20, 0x1c, 0x39, 0x1c, -0x14, 0x4a, 0x13, 0x68, 0xff, 0x22, 0x45, 0x32, -0x07, 0xf0, 0xad, 0xf8, 0xff, 0x23, 0x45, 0x33, 0x98, 0x42, 0x12, 0xd1, -0x00, 0x22, 0x13, 0x21, 0x33, 0x68, 0x20, 0x1c, 0x07, 0xf0, 0xa3, 0xf8, -0x06, 0x06, 0x36, 0x0e, 0x00, 0x20, 0x78, 0x71, 0x38, 0x1c, 0x0b, 0x49, -0x0a, 0x68, 0xff, 0x21, 0x45, 0x31, 0x07, 0xf0, 0x97, 0xf8, 0xb0, 0x42, -0x00, 0xd0, 0x00, 0x25, 0x20, 0x1c, 0x07, 0x49, 0x09, 0x68, 0x07, 0xf0, -0x8e, 0xf8, 0x28, 0x1c, 0xca, 0xe7, 0x00, 0x00, 0x74, 0x6e, 0x21, 0x40, -0x8c, 0x6e, 0x21, 0x40, 0x80, 0x6e, 0x21, 0x40, 0x94, 0x6e, 0x21, 0x40, -0x88, 0x6e, 0x21, 0x40, 0xf0, 0xb5, 0xff, 0x21, 0x45, 0x31, 0x00, 0x20, -0x51, 0x4f, 0x00, 0x26, 0x3a, 0x18, 0xe1, 0x23, 0x1b, 0x01, 0xd2, 0x18, -0x16, 0x73, 0x01, 0x30, 0x88, 0x42, 0xf7, 0xd3, 0x4d, 0x4b, 0xf8, 0x18, -0xff, 0xf7, 0xa0, 0xff, 0x01, 0x25, 0x2d, 0x05, 0x00, 0x28, 0x0e, 0xd0, -0xe1, 0x23, 0x1b, 0x01, 0xf8, 0x18, 0x01, 0x7b, 0x41, 0x29, 0x16, 0xd0, -0x41, 0x7b, 0x53, 0x29, 0x13, 0xd0, 0x81, 0x7b, 0x46, 0x29, 0x10, 0xd0, -0xc0, 0x7b, 0x00, 0x28, 0x0d, 0xd0, 0x01, 0x23, 0x1b, 0x03, 0xb8, 0x69, -0x98, 0x43, 0xb8, 0x61, 0xe8, 0x61, 0x5b, 0x00, 0xb8, 0x69, 0x98, 0x43, -0xb8, 0x61, 0xe8, 0x61, 0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x3c, 0x49, -0x39, 0x23, 0x9b, 0x01, 0xf8, 0x18, 0x0a, 0x68, 0xc0, 0x46, 0xc2, 0x80, -0x4a, 0x68, 0xc0, 0x46, 0x02, 0x81, 0x89, 0x68, 0xc0, 0x46, 0x41, 0x81, -0x3c, 0x1c, 0x00, 0x21, 0x37, 0x1c, 0x4a, 0x00, 0x12, 0x19, 0x39, 0x23, -0x9b, 0x01, 0xd2, 0x18, 0x17, 0x80, 0x01, 0x31, 0x09, 0x06, 0x09, 0x0e, -0x03, 0x29, 0xf4, 0xdb, 0x07, 0x73, 0x2f, 0x48, 0x2f, 0x49, 0x0b, 0x68, -0x2f, 0x4a, 0x00, 0x21, 0x07, 0xf0, 0x2d, 0xf8, 0xe9, 0x23, 0x1b, 0x01, -0xe0, 0x18, 0x07, 0x73, 0x42, 0x89, 0x19, 0x21, 0x49, 0x01, 0x8a, 0x42, -0x00, 0xda, 0x41, 0x81, 0x00, 0x21, 0x82, 0x7b, 0x00, 0x2a, 0x0c, 0xdd, -0x16, 0x22, 0x4a, 0x43, 0x12, 0x19, 0x75, 0x23, 0x5b, 0x01, 0xd2, 0x18, -0xd7, 0x70, 0x01, 0x31, 0x09, 0x06, 0x09, 0x0e, 0x82, 0x7b, 0x8a, 0x42, -0xf2, 0xdc, 0xef, 0x23, 0x1b, 0x01, 0xe0, 0x18, 0xc7, 0x71, 0x39, 0x1c, -0x00, 0x20, 0x42, 0x00, 0x12, 0x19, 0xef, 0x23, 0x1b, 0x01, 0xd2, 0x18, -0x11, 0x72, 0x51, 0x72, 0x01, 0x30, 0x00, 0x06, 0x00, 0x0e, 0x04, 0x28, -0xf3, 0xdb, 0x79, 0x23, 0x5b, 0x01, 0xe0, 0x18, 0x01, 0x72, 0x3d, 0x23, -0x9b, 0x01, 0xe0, 0x18, 0x81, 0x60, 0x14, 0x48, 0x14, 0x49, 0xc0, 0x46, -0x08, 0x60, 0x01, 0x23, 0x1b, 0x03, 0xa0, 0x69, 0x18, 0x43, 0xa0, 0x61, -0xe1, 0x69, 0x99, 0x43, 0xe1, 0x61, 0xe8, 0x61, 0xe0, 0x69, 0xc0, 0x46, -0x28, 0x62, 0x5b, 0x00, 0xa0, 0x69, 0x98, 0x43, 0xa0, 0x61, 0xe8, 0x61, -0x03, 0xf0, 0xee, 0xff, 0x0a, 0x48, 0x0b, 0x49, 0xc0, 0x46, 0x08, 0x60, -0x88, 0xe7, 0x00, 0x00, 0xf8, 0x0d, 0x00, 0x80, 0x1c, 0x0e, 0x00, 0x00, -0x40, 0x00, 0x14, 0x40, 0x39, 0x06, 0xff, 0xff, 0x70, 0x76, 0x21, 0x40, -0x80, 0x4f, 0x12, 0x00, 0x08, 0x6e, 0x21, 0x40, 0x88, 0x70, 0x21, 0x40, -0x7d, 0x0c, 0xff, 0xff, 0x78, 0x70, 0x21, 0x40, 0xb0, 0xb5, 0x00, 0x20, -0x1c, 0x4f, 0xef, 0x23, 0x1b, 0x01, 0xfc, 0x18, 0xe1, 0x79, 0x00, 0x29, -0x0c, 0xdd, 0x00, 0x21, 0x42, 0x00, 0xd2, 0x19, 0xef, 0x23, 0x1b, 0x01, -0xd2, 0x18, 0x51, 0x72, 0x01, 0x30, 0x00, 0x06, 0x00, 0x0e, 0xe2, 0x79, -0x82, 0x42, 0xf3, 0xdc, 0x39, 0x23, 0x9b, 0x01, -0xf8, 0x18, 0xc2, 0x6a, 0x11, 0x4d, 0x00, 0x2a, 0x04, 0xd0, 0x11, 0x48, -0x00, 0x21, 0x2b, 0x68, 0x06, 0xf0, 0xa5, 0xff, 0x00, 0xf0, 0x2a, 0xf8, -0x0e, 0x48, 0x05, 0x22, 0x00, 0x21, 0x2b, 0x68, 0x06, 0xf0, 0x9d, 0xff, -0xe0, 0x79, 0x00, 0x28, 0x05, 0xd1, 0xe9, 0x23, 0x1b, 0x01, 0xf8, 0x18, -0x80, 0x7b, 0x00, 0x28, 0x04, 0xd0, 0x08, 0x48, 0x7d, 0x21, 0x09, 0x01, -0x00, 0xf0, 0x71, 0xf8, 0xb0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, -0xf8, 0x0d, 0x00, 0x80, 0x70, 0x76, 0x21, 0x40, 0xb5, 0x07, 0xff, 0xff, -0x6d, 0x07, 0xff, 0xff, 0xd1, 0x07, 0xff, 0xff, 0x00, 0x20, 0x02, 0x49, -0xc0, 0x46, 0x08, 0x73, 0x70, 0x47, 0x00, 0x00, 0x38, 0x1c, 0x00, 0x80, -0x80, 0xb4, 0x00, 0x21, 0x09, 0x48, 0xc0, 0x46, 0x01, 0x60, 0x00, 0x20, -0x08, 0x4a, 0x43, 0x00, 0x1b, 0x18, 0x9b, 0x00, 0x9f, 0x18, 0xb9, 0x60, -0xd1, 0x50, 0x79, 0x60, 0x01, 0x30, 0x00, 0x06, 0x00, 0x0e, 0x05, 0x28, -0xf3, 0xdb, 0x80, 0xbc, 0x70, 0x47, 0x00, 0x00, 0x04, 0x6e, 0x21, 0x40, -0x40, 0xab, 0x20, 0x40, 0xb0, 0xb4, 0x00, 0x29, 0x03, 0xd0, 0x07, 0x68, -0x00, 0x2f, 0x02, 0xd1, 0x01, 0x60, 0xb0, 0xbc, 0x70, 0x47, 0x3a, 0x1c, -0x53, 0x68, 0x4c, 0x68, 0xa3, 0x42, 0x08, 0xd8, 0x13, 0x1c, 0x12, 0x68, -0x00, 0x2a, 0x02, 0xd0, 0x55, 0x68, 0xa5, 0x42, 0xf8, 0xd9, 0x00, 0x2b, -0x03, 0xd1, 0x3a, 0x68, 0xc0, 0x46, 0x0a, 0x60, 0xea, 0xe7, 0x18, 0x68, -0xc0, 0x46, 0x08, 0x60, 0x19, 0x60, 0xe6, 0xe7, 0x90, 0xb4, 0x00, 0x29, -0x15, 0xd0, 0x02, 0x68, 0x17, 0x1c, 0x8a, 0x42, 0x08, 0xd0, 0x13, 0x1c, -0x14, 0x68, 0x00, 0x2c, 0x02, 0xd0, 0x22, 0x1c, 0x8a, 0x42, 0xf8, 0xd1, -0x00, 0x2b, 0x03, 0xd1, 0x3a, 0x68, 0xc0, 0x46, 0x02, 0x60, 0x02, 0xe0, -0x10, 0x68, 0xc0, 0x46, 0x18, 0x60, 0x00, 0x20, 0x08, 0x60, 0x90, 0xbc, -0x70, 0x47, 0x00, 0xb5, 0x01, 0x68, 0xff, 0xf7, 0xe1, 0xff, 0x08, 0xbc, -0x18, 0x47, 0x90, 0xb5, 0x00, 0x22, 0x11, 0x4c, 0x53, 0x00, 0x9b, 0x18, -0x9b, 0x00, 0x1b, 0x19, 0x9b, 0x68, 0x00, 0x2b, 0x04, 0xd1, 0x53, 0x00, -0x9b, 0x18, 0x9b, 0x00, 0x1f, 0x19, 0x04, 0xe0, 0x01, 0x32, 0x12, 0x06, -0x12, 0x0e, 0x05, 0x2a, 0xee, 0xdb, 0x00, 0x23, 0x05, 0x2a, 0x03, 0xd1, -0x18, 0x1c, 0x90, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0xb8, 0x60, 0x79, 0x60, -0x3b, 0x60, 0x39, 0x1c, 0x03, 0x48, 0xff, 0xf7, 0x9d, 0xff, 0x38, 0x1c, -0xf3, 0xe7, 0x00, 0x00, 0x40, 0xab, 0x20, 0x40, 0x04, 0x6e, 0x21, 0x40, -0x80, 0xb5, 0x07, 0x1c, 0x39, 0x1c, 0x04, 0x48, 0xff, 0xf7, 0xb0, 0xff, -0x00, 0x20, 0xb8, 0x60, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, -0x04, 0x6e, 0x21, 0x40, 0xf0, 0xb5, 0x0f, 0x4c, 0x27, 0x68, 0x00, 0x2f, -0x17, 0xd0, 0x78, 0x68, 0x00, 0x28, 0x0c, 0xd1, 0x0c, 0x4e, 0x00, 0x25, -0x30, 0x1c, 0xff, 0xf7, 0xb6, 0xff, 0xb8, 0x68, 0x06, 0xf0, 0xd4, 0xfe, -0xbd, 0x60, 0x27, 0x68, 0x78, 0x68, 0x00, 0x28, 0xf4, 0xd0, 0x00, 0x2f, -0x05, 0xd0, 0x78, 0x68, 0x01, 0x38, 0x78, 0x60, 0x3f, 0x68, 0x00, 0x2f, -0xf9, 0xd1, 0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x04, 0x6e, 0x21, 0x40, -0x04, 0x6e, 0x21, 0x40, 0x00, 0xb5, 0x04, 0x48, 0x04, 0x49, 0x0a, 0x68, -0x01, 0x21, 0x06, 0xf0, 0xbb, 0xfe, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, -0x68, 0x1c, 0x00, 0x80, 0xc0, 0x6f, 0x21, 0x40, 0x80, 0xb5, 0x0b, 0x4f, -0x78, 0x7b, 0x01, 0x28, 0x08, 0xd0, 0x02, 0x28, -0x01, 0xd1, 0x00, 0xf0, 0x65, 0xf8, 0x78, 0x7b, 0x01, 0x28, 0x04, 0xd1, -0x79, 0x7a, 0x03, 0xe0, 0x00, 0xf0, 0x0c, 0xf8, 0xf7, 0xe7, 0x79, 0x89, -0x03, 0x48, 0xff, 0xf7, 0x82, 0xff, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, -0x88, 0x1c, 0x00, 0x80, 0xd1, 0x07, 0xff, 0xff, 0x00, 0xb5, 0x08, 0x48, -0xe9, 0x23, 0x1b, 0x01, 0xc1, 0x18, 0x09, 0x7b, 0x49, 0x00, 0x08, 0x18, -0xef, 0x23, 0x1b, 0x01, 0xc0, 0x18, 0x41, 0x7a, 0x00, 0x7a, 0x00, 0xf0, -0xd5, 0xf9, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, 0xf8, 0x0d, 0x00, 0x80, -0x90, 0xb5, 0xc8, 0x00, 0x40, 0x18, 0x80, 0x00, 0x19, 0x49, 0x40, 0x18, -0x41, 0x78, 0x19, 0x4c, 0xe9, 0x23, 0x1b, 0x01, 0xe7, 0x18, 0x08, 0x29, -0x1d, 0xd2, 0x02, 0xa3, 0x5b, 0x5c, 0x5b, 0x00, 0x9f, 0x44, 0x00, 0x1c, -0x10, 0x10, 0x04, 0x04, 0x10, 0x10, 0x19, 0x1c, 0x02, 0x30, 0x00, 0x21, -0x01, 0x31, 0x09, 0x06, 0x09, 0x0e, 0x03, 0x29, 0xfa, 0xdb, 0x0f, 0x49, -0x0a, 0x68, 0x01, 0x21, 0x06, 0xf0, 0x62, 0xfe, 0x38, 0x7b, 0x40, 0x00, -0x00, 0x19, 0xef, 0x23, 0x1b, 0x01, 0xc0, 0x18, 0x41, 0x7a, 0x01, 0x31, -0x41, 0x72, 0x90, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x20, 0x39, 0x7b, -0x49, 0x00, 0x09, 0x19, 0xef, 0x23, 0x1b, 0x01, 0xc9, 0x18, 0x48, 0x72, -0xf3, 0xe7, 0x00, 0x00, 0xe4, 0x2b, 0x00, 0x80, 0xf8, 0x0d, 0x00, 0x80, -0xc0, 0x6f, 0x21, 0x40, 0x00, 0xb5, 0x0b, 0x48, 0xe9, 0x23, 0x1b, 0x01, -0xc1, 0x18, 0x09, 0x7b, 0x16, 0x23, 0x59, 0x43, 0x08, 0x18, 0x75, 0x23, -0x5b, 0x01, 0xc1, 0x18, 0x09, 0x78, 0xe9, 0x23, 0x1b, 0x01, 0xc0, 0x18, -0xc0, 0x7b, 0xfe, 0x23, 0x18, 0x40, 0x00, 0xf0, 0xad, 0xf9, 0x08, 0xbc, -0x18, 0x47, 0x00, 0x00, 0xf8, 0x0d, 0x00, 0x80, 0xf0, 0xb5, 0x04, 0x1c, -0xc8, 0x00, 0x40, 0x18, 0x80, 0x00, 0x32, 0x49, 0x46, 0x18, 0x00, 0x25, -0x31, 0x48, 0xe9, 0x23, 0x1b, 0x01, 0xc7, 0x18, 0x39, 0x7b, 0x16, 0x23, -0x59, 0x43, 0x08, 0x18, 0x75, 0x23, 0x5b, 0x01, 0xc2, 0x18, 0xd1, 0x78, -0x63, 0x68, 0x1b, 0x06, 0x1b, 0x0e, 0x0c, 0x2b, 0x3b, 0xd1, 0x29, 0x4b, -0x54, 0x78, 0x36, 0x78, 0x34, 0x40, 0x24, 0x06, 0x24, 0x0e, 0x1e, 0x1c, -0xe9, 0x23, 0x1b, 0x01, 0xc0, 0x18, 0xc0, 0x7b, 0x40, 0x08, 0x07, 0xd3, -0x8c, 0x42, 0x24, 0xd0, 0x90, 0x78, 0xa0, 0x42, 0x0a, 0xd0, 0x88, 0x42, -0x1f, 0xd1, 0x06, 0xe0, 0x00, 0x2c, 0x02, 0xd0, 0x00, 0x29, 0x1a, 0xd1, -0x02, 0xe0, 0x00, 0x29, 0x17, 0xd0, 0x01, 0x25, 0x00, 0x2d, 0x03, 0xd0, -0x90, 0x79, 0x80, 0x23, 0x18, 0x43, 0x90, 0x71, 0x00, 0x25, 0x38, 0x7b, -0x16, 0x23, 0x58, 0x43, 0x80, 0x19, 0x16, 0x4b, 0xc0, 0x18, 0x16, 0x49, -0x0a, 0x68, 0x01, 0x21, 0x06, 0xf0, 0xe4, 0xfd, 0x68, 0x1c, 0x05, 0x06, -0x2d, 0x0e, 0x03, 0x2d, 0xef, 0xdb, 0x38, 0x7b, 0x16, 0x23, 0x58, 0x43, -0x80, 0x19, 0x75, 0x23, 0x5b, 0x01, 0xc0, 0x18, 0xc4, 0x70, 0x0b, 0x48, -0x39, 0x7b, 0x01, 0x31, 0x39, 0x73, 0x39, 0x7b, 0xba, 0x7b, 0x91, 0x42, -0x09, 0xdb, 0x00, 0x21, 0x39, 0x73, 0xef, 0x23, 0x1b, 0x01, 0xc0, 0x18, -0xc0, 0x79, 0x00, 0x28, 0x01, 0xd0, 0x01, 0x20, 0x78, 0x73, 0xf0, 0xbc, -0x08, 0xbc, 0x18, 0x47, 0xe4, 0x2b, 0x00, 0x80, 0xf8, 0x0d, 0x00, 0x80, -0xa4, 0x0e, 0x00, 0x00, 0xc0, 0x6f, 0x21, 0x40, 0xb0, 0xb5, 0x00, 0x27, -0x07, 0x4d, 0x08, 0x4c, 0x01, 0x21, 0x2a, 0x68, 0x20, 0x1c, 0x06, 0xf0, -0xb1, 0xfd, 0x78, 0x1c, 0x07, 0x06, 0x3f, 0x0e, -0x03, 0x2f, 0xf5, 0xdb, 0xb0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, -0xc0, 0x6f, 0x21, 0x40, 0x44, 0x1d, 0x00, 0x80, 0xb0, 0xb5, 0xc8, 0x00, -0x40, 0x18, 0x80, 0x00, 0x19, 0x49, 0x47, 0x18, 0x38, 0x78, 0x0d, 0x28, -0x2a, 0xdb, 0x12, 0x28, 0x28, 0xdc, 0xb8, 0x78, 0x10, 0x28, 0x25, 0xd1, -0x79, 0x78, 0x15, 0x48, 0x3d, 0x23, 0x9b, 0x01, 0xc4, 0x18, 0x13, 0x29, -0x16, 0xd1, 0x13, 0x4b, 0xc5, 0x18, 0xa0, 0x68, 0x00, 0x28, 0x01, 0xd0, -0xff, 0xf7, 0x94, 0xfe, 0x00, 0x20, 0x39, 0x18, 0xc9, 0x78, 0xc0, 0x46, -0x29, 0x54, 0x01, 0x30, 0x0e, 0x28, 0xf8, 0xd3, 0x38, 0x79, 0x00, 0x02, -0xf9, 0x78, 0x01, 0x43, 0x0a, 0x48, 0xff, 0xf7, 0x5c, 0xfe, 0xa0, 0x60, -0x78, 0x78, 0x14, 0x28, 0x04, 0xd1, 0xa0, 0x68, 0x00, 0x28, 0x01, 0xd0, -0xff, 0xf7, 0x7c, 0xfe, 0xb0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, -0xe4, 0x2b, 0x00, 0x80, 0xf8, 0x0d, 0x00, 0x80, 0x4c, 0x0f, 0x00, 0x00, -0xc5, 0x09, 0xff, 0xff, 0xf0, 0xb5, 0xcb, 0x00, 0x59, 0x18, 0x89, 0x00, -0x17, 0x4a, 0x8f, 0x18, 0x39, 0x78, 0xc5, 0x1d, 0x19, 0x35, 0x0b, 0x29, -0x22, 0xdb, 0x10, 0x29, 0x20, 0xdc, 0xb8, 0x78, 0x10, 0x28, 0x1d, 0xd1, -0xfe, 0x1c, 0x78, 0x78, 0x15, 0x28, 0x0e, 0xd1, 0x00, 0x24, 0x30, 0x1c, -0x0f, 0x49, 0x0a, 0x68, 0x01, 0x21, 0x06, 0xf0, 0x49, 0xfd, 0x00, 0x28, -0x00, 0xd1, 0x28, 0x71, 0x60, 0x1c, 0x04, 0x06, 0x24, 0x0e, 0x03, 0x2c, -0xf1, 0xdb, 0x78, 0x78, 0x16, 0x28, 0x09, 0xd1, 0x30, 0x1c, 0x07, 0x49, -0x0a, 0x68, 0x01, 0x21, 0x06, 0xf0, 0x38, 0xfd, 0x00, 0x28, 0x01, 0xd1, -0x00, 0x20, 0x28, 0x71, 0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, -0xe4, 0x2b, 0x00, 0x80, 0xc0, 0x6f, 0x21, 0x40, 0xc8, 0x00, 0x40, 0x18, -0x80, 0x00, 0x0c, 0x49, 0x40, 0x18, 0x01, 0x78, 0x0d, 0x29, 0x12, 0xd1, -0x41, 0x78, 0x15, 0x29, 0x0f, 0xd1, 0x80, 0x78, 0x10, 0x28, 0x0c, 0xd1, -0x07, 0x48, 0x08, 0x4b, 0xc3, 0x18, 0x00, 0x21, 0x00, 0x22, 0x5a, 0x54, -0x01, 0x31, 0x0c, 0x29, 0xfb, 0xd3, 0x79, 0x23, 0x5b, 0x01, 0xc0, 0x18, -0x02, 0x72, 0x70, 0x47, 0xe4, 0x2b, 0x00, 0x80, 0xf8, 0x0d, 0x00, 0x80, -0x28, 0x0f, 0x00, 0x00, 0x83, 0x00, 0x18, 0x18, 0x80, 0x00, 0x02, 0x49, -0x40, 0x18, 0x02, 0x4b, 0xc0, 0x18, 0x70, 0x47, 0xf8, 0x0d, 0x00, 0x80, -0x81, 0x0e, 0x00, 0x00, 0x80, 0xb4, 0x00, 0x20, 0x09, 0x49, 0x00, 0x22, -0x43, 0x00, 0x5f, 0x18, 0xef, 0x23, 0x1b, 0x01, 0xfb, 0x18, 0x1a, 0x72, -0x01, 0x30, 0x00, 0x06, 0x00, 0x0e, 0x04, 0x28, 0xf4, 0xdb, 0xef, 0x23, -0x1b, 0x01, 0xc8, 0x18, 0xc2, 0x71, 0x80, 0xbc, 0x70, 0x47, 0x00, 0x00, -0xf8, 0x0d, 0x00, 0x80, 0x88, 0xb5, 0x01, 0x1c, 0x0b, 0x4a, 0xc0, 0x46, -0x00, 0x92, 0x0b, 0x4f, 0x0b, 0x4b, 0xf8, 0x18, 0x1a, 0x23, 0x0a, 0x1c, -0x04, 0x21, 0x04, 0xf0, 0xe9, 0xf8, 0x05, 0x28, 0x06, 0xd1, 0x00, 0x20, -0xef, 0x23, 0x1b, 0x01, 0xf9, 0x18, 0xc8, 0x71, 0xff, 0xf7, 0x0a, 0xfd, -0x88, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, 0xad, 0x0b, 0xff, 0xff, -0xf8, 0x0d, 0x00, 0x80, 0xf8, 0x0e, 0x00, 0x00, 0x00, 0xb5, 0x43, 0x00, -0x18, 0x18, 0x80, 0x00, 0x04, 0x49, 0x40, 0x18, 0x40, 0x7a, 0x04, 0x49, -0xc0, 0x46, 0xc8, 0x71, 0xff, 0xf7, 0xf4, 0xfc, 0x08, 0xbc, 0x18, 0x47, -0x5c, 0xac, 0x20, 0x40, 0xe8, 0x1c, 0x00, 0x80, 0xb0, 0xb5, 0x04, 0x1c, -0x0d, 0x1c, 0x00, 0x27, 0x03, 0xf0, 0x42, 0xfe, -0x00, 0x28, 0x1d, 0xd0, 0x18, 0x21, 0x01, 0x70, 0x0f, 0x49, 0xc0, 0x46, -0xc1, 0x60, 0x0f, 0x49, 0xc0, 0x46, 0x41, 0x60, 0x0e, 0x49, 0xc0, 0x46, -0x81, 0x60, 0x04, 0x74, 0x01, 0x21, 0x41, 0x74, 0x04, 0x21, 0x81, 0x74, -0x11, 0x21, 0xc1, 0x74, 0x10, 0x21, 0x01, 0x75, 0x45, 0x75, 0x00, 0x21, -0x81, 0x75, 0x01, 0x21, 0x21, 0x43, 0xc1, 0x75, 0x00, 0x21, 0x03, 0xf0, -0xd9, 0xfc, 0x07, 0x1c, 0x38, 0x1c, 0xb0, 0xbc, 0x08, 0xbc, 0x18, 0x47, -0xe4, 0x2b, 0x00, 0x80, 0x00, 0x3f, 0xf3, 0x03, 0x31, 0x08, 0xff, 0xff, -0xb0, 0xb5, 0x04, 0x1c, 0x0d, 0x1c, 0x00, 0x27, 0x03, 0xf0, 0x12, 0xfe, -0x00, 0x28, 0x13, 0xd0, 0x08, 0x21, 0x01, 0x70, 0x0a, 0x49, 0xc0, 0x46, -0xc1, 0x60, 0x0a, 0x49, 0xc0, 0x46, 0x41, 0x60, 0x09, 0x49, 0xc0, 0x46, -0x81, 0x60, 0x04, 0x74, 0x45, 0x74, 0x01, 0x21, 0x21, 0x43, 0x81, 0x74, -0x00, 0x21, 0x03, 0xf0, 0xb3, 0xfc, 0x07, 0x1c, 0x38, 0x1c, 0xb0, 0xbc, -0x08, 0xbc, 0x18, 0x47, 0xe4, 0x2b, 0x00, 0x80, 0x00, 0x3f, 0xf3, 0x13, -0xe1, 0x08, 0xff, 0xff, 0xc1, 0x10, 0x05, 0xd1, 0x40, 0x07, 0x40, 0x0f, -0x80, 0x00, 0x02, 0x49, 0x08, 0x58, 0x70, 0x47, 0x00, 0x20, 0xfc, 0xe7, -0x20, 0x6e, 0x21, 0x40, 0xcb, 0x00, 0x59, 0x18, 0x89, 0x00, 0x08, 0x48, -0x42, 0x5c, 0x03, 0x2a, 0x0a, 0xd1, 0x08, 0x18, 0x41, 0x78, 0x18, 0x29, -0x06, 0xd1, 0x81, 0x78, 0x10, 0x29, 0x03, 0xd1, 0xc0, 0x78, 0x03, 0x49, -0xc0, 0x46, 0xc8, 0x62, 0x70, 0x47, 0x00, 0x00, 0xe4, 0x2b, 0x00, 0x80, -0xf8, 0x1b, 0x00, 0x80, 0xf0, 0xb4, 0x02, 0x7c, 0xd6, 0x07, 0xf6, 0x0f, -0xc7, 0x1d, 0x19, 0x37, 0x1c, 0x4d, 0x00, 0x24, 0xca, 0x00, 0x52, 0x18, -0x92, 0x00, 0x00, 0x2e, 0x23, 0xd0, 0xae, 0x5c, 0x19, 0x4d, 0xcb, 0x00, -0x59, 0x18, 0x89, 0x00, 0x69, 0x18, 0x00, 0x2e, 0x15, 0xd1, 0x03, 0x23, -0xab, 0x54, 0x13, 0x22, 0x4a, 0x70, 0x10, 0x22, 0x8a, 0x70, 0x09, 0x22, -0x13, 0x4b, 0x5d, 0x6a, 0x02, 0x23, 0x1d, 0x40, 0x00, 0xd1, 0x01, 0x22, -0x04, 0x23, 0x00, 0x2d, 0x00, 0xd1, 0x00, 0x23, 0x1a, 0x43, 0xca, 0x70, -0x15, 0x22, 0x3a, 0x71, 0x00, 0xe0, 0x3c, 0x71, 0xc1, 0x61, 0x04, 0x62, -0x44, 0x61, 0xf0, 0xbc, 0x70, 0x47, 0x14, 0x21, 0x39, 0x71, 0x09, 0x49, -0x52, 0x19, 0x01, 0x62, 0x82, 0x61, 0x00, 0x21, 0x54, 0x54, 0x01, 0x31, -0x24, 0x29, 0xfb, 0xd3, 0x05, 0x49, 0xc0, 0x46, 0x41, 0x61, 0xee, 0xe7, -0xe4, 0x2b, 0x00, 0x80, 0x08, 0x2c, 0x00, 0x80, 0xf8, 0x1b, 0x00, 0x80, -0x95, 0x0c, 0xff, 0xff, 0xc5, 0x0c, 0xff, 0xff, 0x14, 0x22, 0xc3, 0x1d, -0x19, 0x33, 0x1a, 0x71, 0xcb, 0x00, 0x59, 0x18, 0x89, 0x00, 0x04, 0x4a, -0x89, 0x18, 0x81, 0x61, 0x03, 0x49, 0xc0, 0x46, 0x01, 0x62, 0x00, 0x21, -0x41, 0x61, 0x70, 0x47, 0xe4, 0x2b, 0x00, 0x80, 0xf1, 0x09, 0xff, 0xff, -0x80, 0xb4, 0x02, 0x7c, 0xd7, 0x07, 0xff, 0x0f, 0xcb, 0x00, 0x59, 0x18, -0x89, 0x00, 0xc2, 0x1d, 0x19, 0x32, 0x00, 0x2f, 0x27, 0xd0, 0x1a, 0x4b, -0xc9, 0x18, 0x15, 0x23, 0x13, 0x71, 0x00, 0x22, 0xc1, 0x61, 0x42, 0x61, -0x02, 0x62, 0x17, 0x4a, 0x79, 0x23, 0x5b, 0x01, 0xd0, 0x18, 0x03, 0x7a, -0x10, 0x20, 0x00, 0x2b, 0x11, 0xd0, 0x0d, 0x23, 0x0b, 0x70, 0x16, 0x23, -0x4b, 0x70, 0x88, 0x70, 0x00, 0x20, 0x17, 0x18, 0x79, 0x23, 0x5b, 0x01, -0xfb, 0x18, 0x5b, 0x7a, 0x0f, 0x18, 0xfb, 0x70, 0x01, 0x30, 0x0b, 0x28, -0xf5, 0xd3, 0x80, 0xbc, 0x70, 0x47, 0x02, 0x22, -0x0a, 0x70, 0x17, 0x22, 0x4a, 0x70, 0x88, 0x70, 0xf7, 0xe7, 0x14, 0x23, -0x13, 0x71, 0x07, 0x4a, 0x89, 0x18, 0x81, 0x61, 0x06, 0x49, 0xc0, 0x46, -0x01, 0x62, 0x06, 0x49, 0xc0, 0x46, 0x41, 0x61, 0xeb, 0xe7, 0x00, 0x00, -0x08, 0x2c, 0x00, 0x80, 0xf8, 0x0d, 0x00, 0x80, 0xe4, 0x2b, 0x00, 0x80, -0xe1, 0x0a, 0xff, 0xff, 0x81, 0x0d, 0xff, 0xff, 0x14, 0x22, 0xc3, 0x1d, -0x19, 0x33, 0x1a, 0x71, 0x04, 0x4a, 0xcb, 0x00, 0x59, 0x18, 0x89, 0x00, -0x02, 0x62, 0x03, 0x4a, 0x89, 0x18, 0x81, 0x61, 0x70, 0x47, 0x00, 0x00, -0x71, 0x0a, 0xff, 0xff, 0xe4, 0x2b, 0x00, 0x80, 0x00, 0x00, 0x0f, 0xe1, -0x00, 0x10, 0xa0, 0xe1, 0xc0, 0x10, 0x81, 0xe3, 0x01, 0xf0, 0x21, 0xe1, -0x1e, 0xff, 0x2f, 0xe1, 0x00, 0xf0, 0x21, 0xe1, 0x1e, 0xff, 0x2f, 0xe1, -0x00, 0x00, 0x0f, 0xe1, 0xc0, 0x00, 0x80, 0xe3, 0x00, 0xf0, 0x21, 0xe1, -0x1e, 0xff, 0x2f, 0xe1, 0x00, 0x00, 0x0f, 0xe1, 0xc0, 0x00, 0xc0, 0xe3, +0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xbf, 0xcd, 0x57, 0xc3, +0xba, 0x01, 0x2c, 0xe8, 0xcd, 0xef, 0xa9, 0xd9, 0x6f, 0xbb, 0x76, 0x2f, +0x86, 0x49, 0xac, 0x1b, 0x40, 0x01, 0x00, 0x00, 0x8a, 0xe4, 0x00, 0x00, +0x00, 0x00, 0xff, 0xff, 0x39, 0x00, 0x00, 0xea, 0x05, 0x00, 0x00, 0xea, +0x04, 0x00, 0x00, 0xea, 0x03, 0x00, 0x00, 0xea, 0x02, 0x00, 0x00, 0xea, +0x01, 0x00, 0x00, 0xea, 0x32, 0x02, 0x00, 0xea, 0xc0, 0x14, 0x00, 0xea, +0x07, 0x00, 0x2d, 0xe9, 0x0e, 0x00, 0xa0, 0xe1, 0x00, 0x10, 0x0f, 0xe1, +0xd0, 0x20, 0x9f, 0xe5, 0x12, 0xff, 0x2f, 0xe1, 0xfe, 0xff, 0xff, 0xea, +0x01, 0x00, 0x80, 0xe0, 0x04, 0x20, 0x81, 0xe4, 0x01, 0x00, 0x50, 0xe1, +0xfc, 0xff, 0xff, 0x1a, 0x0e, 0xf0, 0xa0, 0xe1, 0x00, 0xa0, 0xa0, 0xe1, +0x0e, 0xb0, 0xa0, 0xe1, 0x00, 0x00, 0xa0, 0xe3, 0xa8, 0x10, 0x9f, 0xe5, +0x00, 0x00, 0x81, 0xe5, 0xa4, 0x10, 0x9f, 0xe5, 0x00, 0x00, 0x81, 0xe5, +0x01, 0x16, 0xa0, 0xe3, 0x00, 0x00, 0x91, 0xe5, 0x01, 0x00, 0x80, 0xe3, +0x00, 0x00, 0x81, 0xe5, 0xd7, 0x00, 0xa0, 0xe3, 0x00, 0xf0, 0x21, 0xe1, +0x88, 0xd0, 0x9f, 0xe5, 0xdb, 0x00, 0xa0, 0xe3, 0x00, 0xf0, 0x21, 0xe1, +0x7c, 0xd0, 0x9f, 0xe5, 0xd2, 0x00, 0xa0, 0xe3, 0x00, 0xf0, 0x21, 0xe1, +0x74, 0xd0, 0x9f, 0xe5, 0xd1, 0x00, 0xa0, 0xe3, 0x00, 0xf0, 0x21, 0xe1, +0x6c, 0xd0, 0x9f, 0xe5, 0x96, 0x14, 0x00, 0xeb, 0xd3, 0x00, 0xa0, 0xe3, +0x00, 0xf0, 0x21, 0xe1, 0x60, 0xd0, 0x9f, 0xe5, 0x60, 0x00, 0x9f, 0xe5, +0x60, 0x10, 0x9f, 0xe5, 0x60, 0x20, 0x9f, 0xe5, 0xdb, 0xff, 0xff, 0xeb, +0x5c, 0x00, 0x9f, 0xe5, 0x5c, 0x10, 0x9f, 0xe5, 0x00, 0x20, 0xa0, 0xe3, +0xd7, 0xff, 0xff, 0xeb, 0x54, 0x00, 0x9f, 0xe5, 0x54, 0x10, 0x9f, 0xe5, +0xd4, 0xff, 0xff, 0xeb, 0x0a, 0x00, 0xa0, 0xe1, 0x0b, 0xf0, 0xa0, 0xe1, +0xd3, 0x10, 0xa0, 0xe3, 0x01, 0xf0, 0x21, 0xe1, 0xd4, 0xff, 0xff, 0xeb, +0x3c, 0xa0, 0x9f, 0xe5, 0x1a, 0xff, 0x2f, 0xe1, 0xc6, 0xff, 0xff, 0xea, +0x01, 0x21, 0xff, 0xff, 0x0c, 0x00, 0x10, 0x00, 0x1c, 0x00, 0x10, 0x00, +0x3c, 0x38, 0x00, 0x80, 0xfc, 0x37, 0x00, 0x80, 0xfc, 0x3f, 0x00, 0x80, +0x7c, 0x34, 0x00, 0x80, 0x80, 0x0f, 0x00, 0x00, 0x80, 0x30, 0x00, 0x80, +0xad, 0xde, 0xad, 0xde, 0x5c, 0xbc, 0x00, 0x00, 0x24, 0xab, 0x20, 0x40, +0x48, 0x29, 0x00, 0x00, 0x28, 0x05, 0x00, 0x80, 0x8d, 0xd2, 0x21, 0x40, +0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, +0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, +0x44, 0x57, 0x00, 0x00, 0x71, 0xaf, 0x00, 0x00, 0x60, 0x01, 0xff, 0xff, +0xb0, 0xb5, 0x07, 0x1c, 0x12, 0x4c, 0x00, 0x25, 0x20, 0x68, 0x00, 0x28, +0x1d, 0xd0, 0x38, 0x1c, 0x10, 0x49, 0x04, 0xf0, 0x71, 0xfd, 0x21, 0x68, +0xc0, 0x46, 0x08, 0x60, 0x00, 0x28, 0x14, 0xd0, 0x38, 0x01, 0x0d, 0x49, +0x40, 0x18, 0x19, 0x23, 0xdb, 0x01, 0xc0, 0x18, 0x41, 0x6b, 0x80, 0x29, +0x0b, 0xd2, 0x01, 0x31, 0x41, 0x63, 0x20, 0x68, 0xc1, 0x69, 0xc0, 0x46, +0x21, 0x60, 0x39, 0x07, 0x41, 0x60, 0xc7, 0x62, 0xb0, 0xbc, 0x08, 0xbc, +0x18, 0x47, 0x28, 0x1c, 0xfa, 0xe7, 0x00, 0x00, 0xe8, 0x17, 0x00, 0x80, +0xee, 0x05, 0x00, 0x00, 0xa0, 0x1c, 0x00, 0x80, 0x02, 0x49, 0x0a, 0x68, +0xc0, 0x46, 0xc2, 0x61, 0x08, 0x60, 0x70, 0x47, +0xe8, 0x17, 0x00, 0x80, 0x70, 0x47, 0x00, 0x00, 0x70, 0x47, 0x00, 0x00, +0x70, 0x47, 0x00, 0x00, 0x00, 0x00, 0x0f, 0xe1, 0x00, 0x10, 0xa0, 0xe1, +0xc0, 0x10, 0x81, 0xe3, 0x01, 0xf0, 0x21, 0xe1, 0x1e, 0xff, 0x2f, 0xe1, 0x00, 0xf0, 0x21, 0xe1, 0x1e, 0xff, 0x2f, 0xe1, 0x00, 0x00, 0x0f, 0xe1, -0x40, 0x00, 0x80, 0xe3, 0x00, 0xf0, 0x21, 0xe1, 0x1e, 0xff, 0x2f, 0xe1, -0x00, 0x00, 0x0f, 0xe1, 0x80, 0x00, 0x10, 0xe3, 0x80, 0x00, 0x80, 0xe3, -0x00, 0xf0, 0x21, 0xe1, 0x00, 0x00, 0x00, 0x12, 0x1e, 0xff, 0x2f, 0xe1, -0x00, 0x00, 0x50, 0xe3, 0x00, 0x00, 0x0f, 0xe1, 0x80, 0x00, 0xc0, 0x13, +0xc0, 0x00, 0x80, 0xe3, 0x00, 0xf0, 0x21, 0xe1, 0x1e, 0xff, 0x2f, 0xe1, +0x00, 0x00, 0x0f, 0xe1, 0xc0, 0x00, 0xc0, 0xe3, 0x00, 0xf0, 0x21, 0xe1, +0x1e, 0xff, 0x2f, 0xe1, 0x00, 0x00, 0x0f, 0xe1, 0x40, 0x00, 0x80, 0xe3, 0x00, 0xf0, 0x21, 0xe1, 0x1e, 0xff, 0x2f, 0xe1, 0x00, 0x00, 0x0f, 0xe1, -0x80, 0x00, 0xc0, 0xe3, 0x00, 0xf0, 0x21, 0xe1, 0x1e, 0xff, 0x2f, 0xe1, -0x91, 0x00, 0x00, 0xe0, 0x1e, 0xff, 0x2f, 0xe1, 0x01, 0x20, 0x80, 0xe0, -0x01, 0x00, 0x80, 0xe0, 0x1e, 0xff, 0x2f, 0xe1, 0x80, 0xb5, 0x08, 0x4f, -0x64, 0x28, 0x04, 0xd3, 0x64, 0x20, 0xf8, 0x62, 0x00, 0x20, 0xc0, 0x43, -0x03, 0xe0, 0xf8, 0x62, 0x04, 0x49, 0x06, 0xf0, 0xb1, 0xfe, 0x38, 0x63, -0x78, 0x63, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0xf8, 0x0d, 0x00, 0x80, -0x88, 0x13, 0x00, 0x00, 0x80, 0xb4, 0x10, 0x4b, 0x00, 0x22, 0xdf, 0x6a, -0x64, 0x2f, 0x03, 0xd2, 0x09, 0x68, 0x09, 0x68, 0x49, 0x08, 0x02, 0xd2, -0x10, 0x1c, 0x80, 0xbc, 0x70, 0x47, 0x19, 0x1c, 0x9b, 0x6b, 0x0f, 0x6b, -0xbb, 0x42, 0x05, 0xd2, 0x40, 0x68, 0x00, 0x04, 0x00, 0x0c, 0x18, 0x18, -0x88, 0x63, 0xf1, 0xe7, 0x41, 0x68, 0x05, 0x4b, 0x19, 0x43, 0x41, 0x60, -0x04, 0x48, 0xc1, 0x6b, 0x01, 0x31, 0xc1, 0x63, 0x02, 0x20, 0xe8, 0xe7, -0xf8, 0x0d, 0x00, 0x80, 0x00, 0x00, 0x00, 0x80, 0x94, 0x2c, 0x00, 0x80, -0x90, 0xb5, 0x07, 0x1c, 0x15, 0x4c, 0x00, 0x20, 0xe1, 0x6a, 0x64, 0x29, -0x0b, 0xd2, 0xb9, 0x6e, 0x49, 0x08, 0x08, 0xd3, 0xe1, 0x6b, 0x62, 0x6b, -0x91, 0x42, 0x07, 0xd2, 0xfa, 0x1d, 0x39, 0x32, 0x52, 0x8b, 0x89, 0x18, -0xe1, 0x63, 0x90, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x78, 0x6a, 0x39, 0x6b, -0xc0, 0x46, 0x48, 0x62, 0x38, 0x6b, 0x03, 0xf0, 0xc7, 0xf9, 0x38, 0x1c, -0x02, 0xf0, 0x7d, 0xfe, 0x01, 0x20, 0xbb, 0x23, 0x1b, 0x01, 0xe1, 0x18, -0xc8, 0x70, 0x05, 0x49, 0x0a, 0x6c, 0x12, 0x18, 0x0a, 0x64, 0x04, 0x49, -0x8a, 0x6d, 0x12, 0x18, 0x8a, 0x65, 0xe4, 0xe7, 0xf8, 0x0d, 0x00, 0x80, -0x94, 0x2c, 0x00, 0x80, 0x2c, 0x2c, 0x00, 0x80, 0x80, 0xb4, 0x0a, 0x48, -0xc0, 0x6d, 0x02, 0x23, 0x18, 0x40, 0x09, 0x4a, 0x00, 0x21, 0x00, 0x28, -0x03, 0xd0, 0x91, 0x63, 0xd1, 0x63, 0x80, 0xbc, 0x70, 0x47, 0x06, 0x48, -0x07, 0x68, 0x7b, 0x1c, 0x03, 0x60, 0x0a, 0x2f, -0xf7, 0xd3, 0x01, 0x60, 0xf3, 0xe7, 0x00, 0x00, 0x2c, 0x2c, 0x00, 0x80, -0xf8, 0x0d, 0x00, 0x80, 0x5c, 0x01, 0x00, 0x80, 0x70, 0x47, 0x02, 0x04, -0x12, 0x0c, 0x00, 0x0c, 0x10, 0x18, 0x0a, 0x04, 0x12, 0x0c, 0x09, 0x0c, -0x51, 0x18, 0x08, 0x18, 0x01, 0x0c, 0x05, 0xd0, 0x01, 0x04, 0x09, 0x0c, -0x00, 0x0c, 0x08, 0x18, 0x01, 0x0c, 0xf9, 0xd1, 0x00, 0x04, 0x00, 0x0c, -0x70, 0x47, 0x80, 0xb4, 0x00, 0x22, 0x00, 0x29, 0x18, 0xd0, 0x4f, 0x08, -0x7b, 0x1e, 0x00, 0x2f, 0x06, 0xd0, 0x07, 0x88, 0xba, 0x18, 0x02, 0x30, -0x1f, 0x1c, 0x01, 0x3b, 0x00, 0x2f, 0xf8, 0xd1, 0x49, 0x08, 0x03, 0xd3, -0x00, 0x88, 0x00, 0x06, 0x00, 0x0e, 0x82, 0x18, 0x10, 0x0c, 0x05, 0xd0, -0x10, 0x04, 0x00, 0x0c, 0x11, 0x0c, 0x42, 0x18, 0x10, 0x0c, 0xf9, 0xd1, -0x10, 0x04, 0x00, 0x0c, 0x80, 0xbc, 0x70, 0x47, 0x80, 0xb5, 0x83, 0x89, -0xc7, 0x89, 0xfb, 0x18, 0x07, 0x8a, 0xfb, 0x18, 0x47, 0x8a, 0xfb, 0x18, -0x40, 0x7a, 0x00, 0x02, 0xc7, 0x18, 0x38, 0x0c, 0x05, 0xd0, 0x38, 0x04, -0x00, 0x0c, 0x3b, 0x0c, 0xc7, 0x18, 0x38, 0x0c, 0xf9, 0xd1, 0x08, 0x1c, -0x11, 0x1c, 0xff, 0xf7, 0xc8, 0xff, 0x01, 0x1c, 0x38, 0x1c, 0xff, 0xf7, -0xb0, 0xff, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x90, 0xb5, 0x02, 0x23, -0x82, 0x68, 0x1a, 0x40, 0x00, 0x27, 0x00, 0x2a, 0x0f, 0xd0, 0x0a, 0x4a, -0x93, 0x69, 0x01, 0x33, 0x93, 0x61, 0x0a, 0x68, 0x8b, 0x68, 0x9a, 0x18, -0x00, 0x68, 0x1c, 0x18, 0x57, 0x81, 0x09, 0x69, 0x10, 0x1c, 0xff, 0xf7, -0xac, 0xff, 0xc0, 0x43, 0x60, 0x81, 0x38, 0x1c, 0x90, 0xbc, 0x08, 0xbc, -0x18, 0x47, 0x00, 0x00, 0x94, 0x2c, 0x00, 0x80, 0x90, 0xb5, 0x04, 0x23, -0x82, 0x68, 0x1a, 0x40, 0x00, 0x27, 0x00, 0x2a, 0x11, 0xd0, 0x4a, 0x68, -0x52, 0x09, 0x0e, 0xd3, 0x09, 0x4a, 0x13, 0x6a, 0x01, 0x33, 0x13, 0x62, -0xcb, 0x68, 0x02, 0x68, 0x9c, 0x18, 0x01, 0x23, 0x9b, 0x07, 0x08, 0x3a, -0x1a, 0x43, 0x12, 0x68, 0x00, 0xf0, 0x2e, 0xf8, 0x20, 0x82, 0x38, 0x1c, -0x90, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, 0x94, 0x2c, 0x00, 0x80, -0x90, 0xb5, 0x80, 0x23, 0x82, 0x68, 0x1a, 0x40, 0x00, 0x24, 0x00, 0x2a, -0x15, 0xd0, 0x4a, 0x68, 0x92, 0x09, 0x12, 0xd3, 0x0b, 0x4a, 0xd3, 0x69, -0x01, 0x33, 0xd3, 0x61, 0xcb, 0x68, 0x02, 0x68, 0x9f, 0x18, 0x01, 0x23, -0x9b, 0x07, 0x08, 0x3a, 0x1a, 0x43, 0x12, 0x68, 0x00, 0xf0, 0x0e, 0xf8, -0x00, 0x28, 0x00, 0xd1, 0x04, 0x48, 0xc0, 0x46, 0xf8, 0x80, 0x20, 0x1c, -0x90, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, 0x94, 0x2c, 0x00, 0x80, -0xff, 0xff, 0x00, 0x00, 0xb0, 0xb5, 0x14, 0x1c, 0x05, 0x1c, 0x0f, 0x1c, -0x38, 0x69, 0xb9, 0x68, 0x41, 0x18, 0x38, 0x68, 0xff, 0xf7, 0x53, 0xff, -0xc0, 0x43, 0x01, 0x04, 0x09, 0x0c, 0x20, 0x1c, 0xff, 0xf7, 0x39, 0xff, -0x04, 0x1c, 0xb8, 0x68, 0x79, 0x69, 0x40, 0x18, 0x69, 0x68, 0x88, 0x42, -0x0c, 0xd2, 0x2a, 0x68, 0x12, 0x18, 0x09, 0x1a, 0x10, 0x1c, 0x00, 0xf0, -0x05, 0xf9, 0xc0, 0x43, 0x01, 0x04, 0x09, 0x0c, 0x20, 0x1c, 0xff, 0xf7, -0x26, 0xff, 0x04, 0x1c, 0xe0, 0x43, 0x00, 0x04, 0x00, 0x0c, 0xb0, 0xbc, -0x08, 0xbc, 0x18, 0x47, 0x80, 0xb5, 0x07, 0x1c, 0xb8, 0x6b, 0xc0, 0x08, -0x1a, 0xd3, 0xb8, 0x6a, 0xf9, 0x6b, 0x40, 0x18, 0x79, 0x6c, 0x00, 0xf0, -0xed, 0xf8, 0xc0, 0x43, 0x01, 0x04, 0x09, 0x0c, 0x0a, 0x48, 0x07, 0xd0, -0x20, 0x23, 0xb9, 0x69, 0x19, 0x43, 0xb9, 0x61, -0x01, 0x6b, 0x01, 0x31, 0x01, 0x63, 0x07, 0xe0, 0xff, 0x23, 0x01, 0x33, -0xb9, 0x69, 0x19, 0x43, 0xb9, 0x61, 0x41, 0x6a, 0x01, 0x31, 0x41, 0x62, -0x00, 0x20, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x94, 0x2c, 0x00, 0x80, -0x80, 0xb5, 0x07, 0x1c, 0xb8, 0x6b, 0x41, 0x09, 0x1c, 0xd3, 0xc0, 0x08, -0x1a, 0xd3, 0xf8, 0x1d, 0x39, 0x30, 0x00, 0x7b, 0x06, 0x28, 0x15, 0xd1, -0x38, 0x1c, 0x00, 0xf0, 0x53, 0xf8, 0x01, 0x1c, 0x0a, 0x48, 0x07, 0xd0, -0x40, 0x23, 0xb9, 0x69, 0x19, 0x43, 0xb9, 0x61, 0x81, 0x6b, 0x01, 0x31, -0x81, 0x63, 0x07, 0xe0, 0x01, 0x23, 0x9b, 0x02, 0xb9, 0x69, 0x19, 0x43, -0xb9, 0x61, 0xc1, 0x6a, 0x01, 0x31, 0xc1, 0x62, 0x00, 0x20, 0x80, 0xbc, -0x08, 0xbc, 0x18, 0x47, 0x94, 0x2c, 0x00, 0x80, 0xb0, 0xb5, 0x07, 0x1c, -0xb8, 0x6b, 0x81, 0x09, 0x2c, 0xd3, 0xc0, 0x08, 0x2a, 0xd3, 0xf8, 0x1d, -0x39, 0x30, 0x00, 0x7b, 0x11, 0x28, 0x25, 0xd1, 0xb8, 0x6a, 0x39, 0x6c, -0x40, 0x18, 0x01, 0x23, 0x9b, 0x07, 0x06, 0x30, 0x18, 0x43, 0x00, 0x68, -0x05, 0x04, 0x2d, 0x0c, 0x0f, 0x4c, 0x11, 0xd0, 0x38, 0x1c, 0x00, 0xf0, -0x1f, 0xf8, 0x00, 0x28, 0x0c, 0xd0, 0xa8, 0x42, 0x02, 0xd1, 0x0c, 0x4b, -0x98, 0x42, 0x07, 0xd0, 0x80, 0x23, 0xb8, 0x69, 0x18, 0x43, 0xb8, 0x61, -0x60, 0x6b, 0x01, 0x30, 0x60, 0x63, 0x07, 0xe0, 0x01, 0x23, 0x5b, 0x02, -0xb8, 0x69, 0x18, 0x43, 0xb8, 0x61, 0xa0, 0x6a, 0x01, 0x30, 0xa0, 0x62, -0x00, 0x20, 0xb0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x94, 0x2c, 0x00, 0x80, -0xff, 0xff, 0x00, 0x00, 0xf0, 0xb5, 0xff, 0xb0, 0x99, 0xb0, 0x04, 0x1c, -0xe0, 0x6b, 0x61, 0x6c, 0x09, 0x18, 0x03, 0xaa, 0x85, 0x18, 0xa3, 0x6a, -0x00, 0x20, 0x8a, 0x08, 0x01, 0x32, 0x97, 0x92, 0x07, 0xd0, 0x82, 0x00, -0x9f, 0x58, 0x03, 0xae, 0xb7, 0x50, 0x97, 0x9a, 0x01, 0x30, 0x82, 0x42, -0xf7, 0xd8, 0x60, 0x6a, 0x01, 0x23, 0x9b, 0x07, 0x04, 0x30, 0x18, 0x43, -0x00, 0x68, 0xc0, 0x46, 0x02, 0x90, 0x02, 0xaf, 0x3f, 0x88, 0x03, 0xa8, -0xff, 0xf7, 0x87, 0xfe, 0xc0, 0x43, 0x01, 0x04, 0x09, 0x0c, 0x38, 0x1c, -0xff, 0xf7, 0x6d, 0xfe, 0x07, 0x1c, 0xe0, 0x6b, 0xa1, 0x6c, 0x40, 0x18, -0x61, 0x6a, 0x01, 0x23, 0x9b, 0x07, 0x08, 0x31, 0x19, 0x43, 0x09, 0x68, -0xc0, 0x46, 0x01, 0x91, 0x01, 0xa9, 0x09, 0x88, 0x01, 0x31, 0x88, 0x42, -0x0c, 0xd2, 0xa2, 0x6a, 0x12, 0x18, 0x09, 0x1a, 0x10, 0x1c, 0x00, 0xf0, -0x2f, 0xf8, 0xc0, 0x43, 0x01, 0x04, 0x09, 0x0c, 0x38, 0x1c, 0xff, 0xf7, -0x50, 0xfe, 0x07, 0x1c, 0xa8, 0x89, 0xe9, 0x89, 0x08, 0x18, 0x29, 0x8a, -0x08, 0x18, 0x69, 0x8a, 0x08, 0x18, 0x69, 0x7a, 0x09, 0x02, 0x08, 0x18, -0xa1, 0x6c, 0x62, 0x6c, 0x89, 0x1a, 0x0a, 0x04, 0x12, 0x0c, 0x11, 0x02, -0x12, 0x0a, 0x11, 0x43, 0x09, 0x04, 0x09, 0x0c, 0x09, 0x18, 0x08, 0x0c, -0x05, 0xd0, 0x08, 0x04, 0x00, 0x0c, 0x09, 0x0c, 0x41, 0x18, 0x08, 0x0c, -0xf9, 0xd1, 0x38, 0x1c, 0xff, 0xf7, 0x2f, 0xfe, 0xc0, 0x43, 0x00, 0x04, -0x00, 0x0c, 0x7f, 0xb0, 0x19, 0xb0, 0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, -0xb0, 0xb4, 0x00, 0x22, 0x00, 0x29, 0x2e, 0xd0, 0x83, 0x07, 0x9b, 0x0f, -0xdc, 0x00, 0x47, 0x18, 0x04, 0x25, 0xef, 0x1b, 0xbf, 0x07, 0xbf, 0x0f, -0xff, 0x00, 0x80, 0x08, 0x80, 0x00, 0x59, 0x18, 0x03, 0x31, 0x89, 0x08, -0x4d, 0x1e, 0x02, 0xc8, 0xe1, 0x40, 0xa1, 0x40, 0x6b, 0x1e, 0x00, 0x2d, -0x09, 0xd0, 0x0c, 0x04, 0x24, 0x0c, 0xa2, 0x18, -0x09, 0x0c, 0x8a, 0x18, 0x02, 0xc8, 0x1c, 0x1c, 0x01, 0x3b, 0x00, 0x2c, -0xf5, 0xd1, 0xb9, 0x40, 0x08, 0x1c, 0xf8, 0x40, 0x01, 0x04, 0x09, 0x0c, -0x89, 0x18, 0x00, 0x0c, 0x42, 0x18, 0x10, 0x0c, 0x05, 0xd0, 0x10, 0x04, -0x00, 0x0c, 0x11, 0x0c, 0x42, 0x18, 0x10, 0x0c, 0xf9, 0xd1, 0x10, 0x04, -0x00, 0x0c, 0xb0, 0xbc, 0x70, 0x47, 0x00, 0x00, 0x90, 0xb4, 0x00, 0x20, -0x01, 0x27, 0x11, 0x49, 0x42, 0x00, 0x12, 0x18, 0xd2, 0x00, 0x53, 0x18, -0x9c, 0x68, 0x01, 0x23, 0x9b, 0x07, 0x23, 0x43, 0x1b, 0x68, 0x1b, 0x03, -0x1b, 0x0b, 0x8a, 0x58, 0x12, 0x03, 0x12, 0x0b, 0x93, 0x42, 0x0c, 0xd1, -0x01, 0x30, 0x04, 0x28, 0xec, 0xd3, 0x08, 0x48, 0xc0, 0x6a, 0x01, 0x03, -0x09, 0x0b, 0x07, 0x48, 0xc0, 0x6e, 0x00, 0x03, 0x00, 0x0b, 0x81, 0x42, -0x02, 0xd0, 0x38, 0x1c, 0x90, 0xbc, 0x70, 0x47, 0x00, 0x20, 0xfb, 0xe7, -0x18, 0x03, 0x00, 0x80, 0x00, 0x40, 0x14, 0x40, 0xf8, 0x0d, 0x00, 0x80, -0x98, 0xb4, 0x14, 0x4a, 0xc0, 0x46, 0x00, 0x92, 0x83, 0x00, 0x13, 0x48, -0xc0, 0x58, 0x07, 0x03, 0x3f, 0x0b, 0x12, 0x48, 0xc0, 0x58, 0x02, 0x03, -0x12, 0x0b, 0x11, 0x48, 0xc0, 0x58, 0x00, 0x03, 0x00, 0x0b, 0x10, 0x4c, -0xe4, 0x58, 0x01, 0x23, 0x9b, 0x07, 0x23, 0x43, 0x1b, 0x68, 0x9b, 0x00, -0xcc, 0x00, 0x01, 0x21, 0x98, 0x42, 0x01, 0xd1, 0x08, 0x1c, 0x09, 0xe0, -0x98, 0x42, 0x03, 0xd9, 0x10, 0x1a, 0xda, 0x1b, 0x80, 0x18, 0x00, 0xe0, -0x18, 0x1a, 0x84, 0x42, 0xf4, 0xd3, 0x00, 0x20, 0x98, 0xbc, 0x70, 0x47, -0x55, 0x55, 0x55, 0x55, 0x90, 0x03, 0x00, 0x80, 0x98, 0x03, 0x00, 0x80, -0x78, 0x03, 0x00, 0x80, 0x88, 0x03, 0x00, 0x80, 0x80, 0xb4, 0x13, 0x04, -0x00, 0xd0, 0x01, 0x3a, 0x80, 0x00, 0x0b, 0x1c, 0x13, 0x49, 0x0f, 0x58, -0xc0, 0x46, 0x3b, 0x60, 0x0b, 0x58, 0xc0, 0x46, 0x5a, 0x60, 0x0a, 0x58, -0x08, 0x32, 0x10, 0x4b, 0x1b, 0x58, 0x9a, 0x42, 0x01, 0xd3, 0x0f, 0x4a, -0x12, 0x58, 0x0f, 0x4b, 0x1f, 0x58, 0x01, 0x23, 0x9b, 0x07, 0x3b, 0x43, -0x1b, 0x68, 0x9b, 0x00, 0x17, 0x03, 0x3f, 0x0b, 0x9f, 0x42, 0x06, 0xd1, -0x0a, 0x48, 0xc1, 0x68, 0x01, 0x31, 0xc1, 0x60, 0x01, 0x20, 0x80, 0xbc, -0x70, 0x47, 0x08, 0x4b, 0x1b, 0x58, 0xc0, 0x46, 0x1a, 0x60, 0x0a, 0x50, -0x00, 0x20, 0xf6, 0xe7, 0x78, 0x03, 0x00, 0x80, 0x98, 0x03, 0x00, 0x80, -0x90, 0x03, 0x00, 0x80, 0x88, 0x03, 0x00, 0x80, 0xa0, 0x82, 0x20, 0x40, -0x80, 0x03, 0x00, 0x80, 0xff, 0x5f, 0x2d, 0xe9, 0x48, 0xfe, 0xff, 0xeb, -0x01, 0xb6, 0xa0, 0xe3, 0x01, 0xb1, 0x8b, 0xe2, 0x02, 0x7a, 0xa0, 0xe3, -0x01, 0x6a, 0xa0, 0xe3, 0xc4, 0xa0, 0x9f, 0xe5, 0x01, 0x99, 0xa0, 0xe3, -0x01, 0x56, 0xa0, 0xe3, 0xbc, 0x80, 0x9f, 0xe5, 0x14, 0x40, 0x9b, 0xe5, -0x00, 0x00, 0x54, 0xe3, 0x29, 0x00, 0x00, 0x0a, 0x03, 0x0a, 0x14, 0xe3, -0x17, 0x00, 0x00, 0x0a, 0x08, 0x00, 0x9a, 0xe5, 0x00, 0x00, 0x50, 0xe3, -0x0a, 0x00, 0x00, 0x0a, 0x01, 0x0a, 0x14, 0xe3, 0x03, 0x00, 0x00, 0x0a, -0x00, 0x00, 0xa0, 0xe3, 0xb0, 0x19, 0x00, 0xeb, 0x14, 0x60, 0x85, 0xe5, -0x0e, 0x00, 0x00, 0xea, 0x02, 0x0a, 0x14, 0xe3, 0x0c, 0x00, 0x00, 0x0a, -0x01, 0x00, 0xa0, 0xe3, 0xaa, 0x19, 0x00, 0xeb, 0x08, 0x00, 0x00, 0xea, -0x18, 0x00, 0x9a, 0xe5, 0x01, 0x0a, 0xc0, 0xe3, 0x18, 0x00, 0x8a, 0xe5, -0x1c, 0x00, 0x85, 0xe5, 0x14, 0x60, 0x85, 0xe5, 0x18, 0x00, 0x9a, 0xe5, -0x02, 0x0a, 0xc0, 0xe3, 0x18, 0x00, 0x8a, 0xe5, -0x1c, 0x00, 0x85, 0xe5, 0x14, 0x70, 0x85, 0xe5, 0x01, 0x09, 0x14, 0xe3, -0x01, 0x00, 0x00, 0x0a, 0x99, 0x19, 0x00, 0xeb, 0x14, 0x90, 0x85, 0xe5, -0x02, 0x00, 0x14, 0xe3, 0x3a, 0x00, 0x00, 0x1b, 0x01, 0x00, 0x14, 0xe3, -0x3e, 0x00, 0x00, 0x1b, 0x02, 0x0b, 0x14, 0xe3, 0x42, 0x00, 0x00, 0x1b, -0x01, 0x0b, 0x14, 0xe3, 0x1a, 0x00, 0x00, 0x1b, 0x18, 0x00, 0x98, 0xe5, -0x01, 0x00, 0x80, 0xe2, 0x18, 0x00, 0x88, 0xe5, 0xd2, 0xff, 0xff, 0xea, -0xff, 0x5f, 0xbd, 0xe8, 0x04, 0xf0, 0x5e, 0xe2, 0xf8, 0x0d, 0x00, 0x80, -0x04, 0x83, 0x20, 0x40, 0x10, 0x10, 0x1f, 0xe5, 0x10, 0x30, 0x91, 0xe5, -0x00, 0x20, 0xc3, 0xe1, 0x10, 0x20, 0x81, 0xe5, 0x01, 0x16, 0xa0, 0xe3, -0x0c, 0x20, 0x81, 0xe5, 0x0b, 0x12, 0xa0, 0xe3, 0x00, 0x00, 0x81, 0xe5, -0x18, 0x10, 0x9f, 0xe5, 0xb0, 0x24, 0xd1, 0xe1, 0x01, 0x20, 0x82, 0xe2, -0xb0, 0x24, 0xc1, 0xe1, 0x3c, 0x20, 0x91, 0xe5, 0x00, 0x00, 0x82, 0xe1, -0x3c, 0x00, 0x81, 0xe5, 0x1e, 0xff, 0x2f, 0xe1, 0xa0, 0x82, 0x20, 0x40, -0xff, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0x01, 0x0b, 0xa0, 0xe3, -0x01, 0x16, 0xa0, 0xe3, 0x14, 0x00, 0x81, 0xe5, 0x00, 0x1a, 0x81, 0xe1, -0x24, 0x20, 0x91, 0xe5, 0x70, 0x00, 0x1f, 0xe5, 0x00, 0x00, 0x00, 0x00, -0x20, 0x20, 0x80, 0xe5, 0x28, 0x10, 0x91, 0xe5, 0x00, 0x00, 0x00, 0x00, -0x24, 0x10, 0x80, 0xe5, 0x28, 0x20, 0x90, 0xe5, 0x01, 0x20, 0x82, 0xe2, -0x28, 0x20, 0x80, 0xe5, 0x3f, 0x00, 0x01, 0xe2, 0x3f, 0x00, 0x50, 0xe3, -0x1e, 0xff, 0x2f, 0x11, 0x18, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, -0x01, 0x10, 0x81, 0xe2, 0x00, 0x10, 0x80, 0xe5, 0x02, 0x18, 0xa0, 0xe3, -0x0b, 0x02, 0xa0, 0xe3, 0x00, 0x10, 0x80, 0xe5, 0x1e, 0xff, 0x2f, 0xe1, -0xa0, 0x03, 0x00, 0x80, 0x0b, 0x10, 0xa0, 0xe3, 0x02, 0x19, 0x81, 0xe2, -0x06, 0x07, 0xa0, 0xe3, 0x4c, 0x11, 0x80, 0xe5, 0xff, 0xff, 0xff, 0xea, -0xfe, 0xff, 0xff, 0xea, 0x0c, 0x10, 0xa0, 0xe3, 0x02, 0x19, 0x81, 0xe2, -0x06, 0x07, 0xa0, 0xe3, 0x4c, 0x11, 0x80, 0xe5, 0xff, 0xff, 0xff, 0xea, +0x80, 0x00, 0x10, 0xe3, 0x80, 0x00, 0x80, 0xe3, 0x00, 0xf0, 0x21, 0xe1, +0x00, 0x00, 0x00, 0x12, 0x1e, 0xff, 0x2f, 0xe1, 0x00, 0x00, 0x50, 0xe3, +0x00, 0x00, 0x0f, 0xe1, 0x80, 0x00, 0xc0, 0x13, 0x00, 0xf0, 0x21, 0xe1, +0x1e, 0xff, 0x2f, 0xe1, 0x00, 0x00, 0x0f, 0xe1, 0x80, 0x00, 0xc0, 0xe3, +0x00, 0xf0, 0x21, 0xe1, 0x1e, 0xff, 0x2f, 0xe1, 0x91, 0x00, 0x00, 0xe0, +0x1e, 0xff, 0x2f, 0xe1, 0x01, 0x20, 0x80, 0xe0, 0x01, 0x00, 0x80, 0xe0, +0x1e, 0xff, 0x2f, 0xe1, 0x80, 0xb5, 0x08, 0x4f, 0x64, 0x28, 0x04, 0xd3, +0x64, 0x20, 0x38, 0x63, 0x00, 0x20, 0xc0, 0x43, 0x03, 0xe0, 0x38, 0x63, +0x04, 0x49, 0x05, 0xf0, 0xf7, 0xfa, 0x78, 0x63, 0xb8, 0x63, 0x80, 0xbc, +0x08, 0xbc, 0x18, 0x47, 0x68, 0x0e, 0x00, 0x80, 0x88, 0x13, 0x00, 0x00, +0x80, 0xb4, 0x10, 0x4b, 0x00, 0x22, 0x1f, 0x6b, 0x64, 0x2f, 0x03, 0xd2, +0x09, 0x68, 0x09, 0x68, 0x49, 0x08, 0x02, 0xd2, 0x10, 0x1c, 0x80, 0xbc, +0x70, 0x47, 0x19, 0x1c, 0xdb, 0x6b, 0x4f, 0x6b, 0xbb, 0x42, 0x05, 0xd2, +0x40, 0x68, 0x00, 0x04, 0x00, 0x0c, 0x18, 0x18, 0xc8, 0x63, 0xf1, 0xe7, +0x41, 0x68, 0x05, 0x4b, 0x19, 0x43, 0x41, 0x60, 0x04, 0x48, 0xc1, 0x6b, +0x01, 0x31, 0xc1, 0x63, 0x02, 0x20, 0xe8, 0xe7, 0x68, 0x0e, 0x00, 0x80, +0x00, 0x00, 0x00, 0x80, 0x0c, 0x2b, 0x00, 0x80, 0x90, 0xb5, 0x07, 0x1c, +0x15, 0x4c, 0x00, 0x20, 0x21, 0x6b, 0x64, 0x29, 0x0b, 0xd2, 0xb9, 0x6e, +0x49, 0x08, 0x08, 0xd3, 0x21, 0x6c, 0xa2, 0x6b, 0x91, 0x42, 0x07, 0xd2, +0xfa, 0x1d, 0x39, 0x32, 0x52, 0x8b, 0x89, 0x18, 0x21, 0x64, 0x90, 0xbc, +0x08, 0xbc, 0x18, 0x47, 0x78, 0x6a, 0x39, 0x6b, 0xc0, 0x46, 0x48, 0x62, +0x38, 0x6b, 0x02, 0xf0, 0x23, 0xfe, 0x38, 0x1c, 0x02, 0xf0, 0xde, 0xfa, +0x01, 0x20, 0xbb, 0x23, 0x1b, 0x01, 0xe1, 0x18, 0xc8, 0x73, 0x05, 0x49, +0x0a, 0x6c, 0x12, 0x18, 0x0a, 0x64, 0x04, 0x49, 0x8a, 0x6d, 0x12, 0x18, +0x8a, 0x65, 0xe4, 0xe7, 0x68, 0x0e, 0x00, 0x80, 0x0c, 0x2b, 0x00, 0x80, +0xa4, 0x2a, 0x00, 0x80, 0x80, 0xb4, 0x0a, 0x48, 0xc0, 0x6d, 0x02, 0x23, +0x18, 0x40, 0x09, 0x4a, 0x00, 0x21, 0x00, 0x28, 0x03, 0xd0, 0xd1, 0x63, +0x11, 0x64, 0x80, 0xbc, 0x70, 0x47, 0x06, 0x48, 0x07, 0x68, 0x7b, 0x1c, +0x03, 0x60, 0x0a, 0x2f, 0xf7, 0xd3, 0x01, 0x60, 0xf3, 0xe7, 0x00, 0x00, +0xa4, 0x2a, 0x00, 0x80, 0x68, 0x0e, 0x00, 0x80, 0xe0, 0x01, 0x00, 0x80, +0x70, 0x47, 0x02, 0x04, 0x12, 0x0c, 0x00, 0x0c, 0x10, 0x18, 0x0a, 0x04, +0x12, 0x0c, 0x09, 0x0c, 0x51, 0x18, 0x08, 0x18, 0x01, 0x0c, 0x05, 0xd0, +0x01, 0x04, 0x09, 0x0c, 0x00, 0x0c, 0x08, 0x18, 0x01, 0x0c, 0xf9, 0xd1, +0x00, 0x04, 0x00, 0x0c, 0x70, 0x47, 0x80, 0xb4, 0x00, 0x22, 0x00, 0x29, +0x18, 0xd0, 0x4f, 0x08, 0x7b, 0x1e, 0x00, 0x2f, +0x06, 0xd0, 0x07, 0x88, 0xba, 0x18, 0x02, 0x30, 0x1f, 0x1c, 0x01, 0x3b, +0x00, 0x2f, 0xf8, 0xd1, 0x49, 0x08, 0x03, 0xd3, 0x00, 0x88, 0x00, 0x06, +0x00, 0x0e, 0x82, 0x18, 0x10, 0x0c, 0x05, 0xd0, 0x10, 0x04, 0x00, 0x0c, +0x11, 0x0c, 0x42, 0x18, 0x10, 0x0c, 0xf9, 0xd1, 0x10, 0x04, 0x00, 0x0c, +0x80, 0xbc, 0x70, 0x47, 0x80, 0xb5, 0x83, 0x89, 0xc7, 0x89, 0xfb, 0x18, +0x07, 0x8a, 0xfb, 0x18, 0x47, 0x8a, 0xfb, 0x18, 0x40, 0x7a, 0x00, 0x02, +0xc7, 0x18, 0x38, 0x0c, 0x05, 0xd0, 0x38, 0x04, 0x00, 0x0c, 0x3b, 0x0c, +0xc7, 0x18, 0x38, 0x0c, 0xf9, 0xd1, 0x08, 0x1c, 0x11, 0x1c, 0xff, 0xf7, +0xc8, 0xff, 0x01, 0x1c, 0x38, 0x1c, 0xff, 0xf7, 0xb0, 0xff, 0x80, 0xbc, +0x08, 0xbc, 0x18, 0x47, 0x90, 0xb5, 0x02, 0x23, 0x82, 0x68, 0x1a, 0x40, +0x00, 0x27, 0x00, 0x2a, 0x0f, 0xd0, 0x0a, 0x4a, 0x93, 0x69, 0x01, 0x33, +0x93, 0x61, 0x0a, 0x68, 0x8b, 0x68, 0x9a, 0x18, 0x00, 0x68, 0x1c, 0x18, +0x57, 0x81, 0x09, 0x69, 0x10, 0x1c, 0xff, 0xf7, 0xac, 0xff, 0xc0, 0x43, +0x60, 0x81, 0x38, 0x1c, 0x90, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, +0x0c, 0x2b, 0x00, 0x80, 0x90, 0xb5, 0x04, 0x23, 0x82, 0x68, 0x1a, 0x40, +0x00, 0x27, 0x00, 0x2a, 0x11, 0xd0, 0x4a, 0x68, 0x52, 0x09, 0x0e, 0xd3, +0x09, 0x4a, 0x13, 0x6a, 0x01, 0x33, 0x13, 0x62, 0xcb, 0x68, 0x02, 0x68, +0x9c, 0x18, 0x01, 0x23, 0x9b, 0x07, 0x08, 0x3a, 0x1a, 0x43, 0x12, 0x68, +0x00, 0xf0, 0x2e, 0xf8, 0x20, 0x82, 0x38, 0x1c, 0x90, 0xbc, 0x08, 0xbc, +0x18, 0x47, 0x00, 0x00, 0x0c, 0x2b, 0x00, 0x80, 0x90, 0xb5, 0x80, 0x23, +0x82, 0x68, 0x1a, 0x40, 0x00, 0x24, 0x00, 0x2a, 0x15, 0xd0, 0x4a, 0x68, +0x92, 0x09, 0x12, 0xd3, 0x0b, 0x4a, 0xd3, 0x69, 0x01, 0x33, 0xd3, 0x61, +0xcb, 0x68, 0x02, 0x68, 0x9f, 0x18, 0x01, 0x23, 0x9b, 0x07, 0x08, 0x3a, +0x1a, 0x43, 0x12, 0x68, 0x00, 0xf0, 0x0e, 0xf8, 0x00, 0x28, 0x00, 0xd1, +0x04, 0x48, 0xc0, 0x46, 0xf8, 0x80, 0x20, 0x1c, 0x90, 0xbc, 0x08, 0xbc, +0x18, 0x47, 0x00, 0x00, 0x0c, 0x2b, 0x00, 0x80, 0xff, 0xff, 0x00, 0x00, +0xb0, 0xb5, 0x14, 0x1c, 0x05, 0x1c, 0x0f, 0x1c, 0x38, 0x69, 0xb9, 0x68, +0x41, 0x18, 0x38, 0x68, 0xff, 0xf7, 0x53, 0xff, 0xc0, 0x43, 0x01, 0x04, +0x09, 0x0c, 0x20, 0x1c, 0xff, 0xf7, 0x39, 0xff, 0x04, 0x1c, 0xb8, 0x68, +0x79, 0x69, 0x40, 0x18, 0x69, 0x68, 0x88, 0x42, 0x0c, 0xd2, 0x2a, 0x68, +0x12, 0x18, 0x09, 0x1a, 0x10, 0x1c, 0x00, 0xf0, 0x05, 0xf9, 0xc0, 0x43, +0x01, 0x04, 0x09, 0x0c, 0x20, 0x1c, 0xff, 0xf7, 0x26, 0xff, 0x04, 0x1c, +0xe0, 0x43, 0x00, 0x04, 0x00, 0x0c, 0xb0, 0xbc, 0x08, 0xbc, 0x18, 0x47, +0x80, 0xb5, 0x07, 0x1c, 0xb8, 0x6b, 0xc0, 0x08, 0x1a, 0xd3, 0xb8, 0x6a, +0xf9, 0x6b, 0x40, 0x18, 0x79, 0x6c, 0x00, 0xf0, 0xed, 0xf8, 0xc0, 0x43, +0x01, 0x04, 0x09, 0x0c, 0x0a, 0x48, 0x07, 0xd0, 0x20, 0x23, 0xb9, 0x69, +0x19, 0x43, 0xb9, 0x61, 0x01, 0x6b, 0x01, 0x31, 0x01, 0x63, 0x07, 0xe0, +0xff, 0x23, 0x01, 0x33, 0xb9, 0x69, 0x19, 0x43, 0xb9, 0x61, 0x41, 0x6a, +0x01, 0x31, 0x41, 0x62, 0x00, 0x20, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, +0x0c, 0x2b, 0x00, 0x80, 0x80, 0xb5, 0x07, 0x1c, 0xb8, 0x6b, 0x41, 0x09, +0x1c, 0xd3, 0xc0, 0x08, 0x1a, 0xd3, 0xf8, 0x1d, 0x39, 0x30, 0x00, 0x7b, +0x06, 0x28, 0x15, 0xd1, 0x38, 0x1c, 0x00, 0xf0, 0x53, 0xf8, 0x01, 0x1c, +0x0a, 0x48, 0x07, 0xd0, 0x40, 0x23, 0xb9, 0x69, +0x19, 0x43, 0xb9, 0x61, 0x81, 0x6b, 0x01, 0x31, 0x81, 0x63, 0x07, 0xe0, +0x01, 0x23, 0x9b, 0x02, 0xb9, 0x69, 0x19, 0x43, 0xb9, 0x61, 0xc1, 0x6a, +0x01, 0x31, 0xc1, 0x62, 0x00, 0x20, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, +0x0c, 0x2b, 0x00, 0x80, 0xb0, 0xb5, 0x07, 0x1c, 0xb8, 0x6b, 0x81, 0x09, +0x2c, 0xd3, 0xc0, 0x08, 0x2a, 0xd3, 0xf8, 0x1d, 0x39, 0x30, 0x00, 0x7b, +0x11, 0x28, 0x25, 0xd1, 0xb8, 0x6a, 0x39, 0x6c, 0x40, 0x18, 0x01, 0x23, +0x9b, 0x07, 0x06, 0x30, 0x18, 0x43, 0x00, 0x68, 0x05, 0x04, 0x2d, 0x0c, +0x0f, 0x4c, 0x11, 0xd0, 0x38, 0x1c, 0x00, 0xf0, 0x1f, 0xf8, 0x00, 0x28, +0x0c, 0xd0, 0xa8, 0x42, 0x02, 0xd1, 0x0c, 0x4b, 0x98, 0x42, 0x07, 0xd0, +0x80, 0x23, 0xb8, 0x69, 0x18, 0x43, 0xb8, 0x61, 0x60, 0x6b, 0x01, 0x30, +0x60, 0x63, 0x07, 0xe0, 0x01, 0x23, 0x5b, 0x02, 0xb8, 0x69, 0x18, 0x43, +0xb8, 0x61, 0xa0, 0x6a, 0x01, 0x30, 0xa0, 0x62, 0x00, 0x20, 0xb0, 0xbc, +0x08, 0xbc, 0x18, 0x47, 0x0c, 0x2b, 0x00, 0x80, 0xff, 0xff, 0x00, 0x00, +0xf0, 0xb5, 0xff, 0xb0, 0x99, 0xb0, 0x04, 0x1c, 0xe0, 0x6b, 0x61, 0x6c, +0x09, 0x18, 0x03, 0xaa, 0x85, 0x18, 0xa3, 0x6a, 0x00, 0x20, 0x8a, 0x08, +0x01, 0x32, 0x97, 0x92, 0x07, 0xd0, 0x82, 0x00, 0x9f, 0x58, 0x03, 0xae, +0xb7, 0x50, 0x97, 0x9a, 0x01, 0x30, 0x82, 0x42, 0xf7, 0xd8, 0x60, 0x6a, +0x01, 0x23, 0x9b, 0x07, 0x04, 0x30, 0x18, 0x43, 0x00, 0x68, 0xc0, 0x46, +0x02, 0x90, 0x02, 0xaf, 0x3f, 0x88, 0x03, 0xa8, 0xff, 0xf7, 0x87, 0xfe, +0xc0, 0x43, 0x01, 0x04, 0x09, 0x0c, 0x38, 0x1c, 0xff, 0xf7, 0x6d, 0xfe, +0x07, 0x1c, 0xe0, 0x6b, 0xa1, 0x6c, 0x40, 0x18, 0x61, 0x6a, 0x01, 0x23, +0x9b, 0x07, 0x08, 0x31, 0x19, 0x43, 0x09, 0x68, 0xc0, 0x46, 0x01, 0x91, +0x01, 0xa9, 0x09, 0x88, 0x01, 0x31, 0x88, 0x42, 0x0c, 0xd2, 0xa2, 0x6a, +0x12, 0x18, 0x09, 0x1a, 0x10, 0x1c, 0x00, 0xf0, 0x2f, 0xf8, 0xc0, 0x43, +0x01, 0x04, 0x09, 0x0c, 0x38, 0x1c, 0xff, 0xf7, 0x50, 0xfe, 0x07, 0x1c, +0xa8, 0x89, 0xe9, 0x89, 0x08, 0x18, 0x29, 0x8a, 0x08, 0x18, 0x69, 0x8a, +0x08, 0x18, 0x69, 0x7a, 0x09, 0x02, 0x08, 0x18, 0xa1, 0x6c, 0x62, 0x6c, +0x89, 0x1a, 0x0a, 0x04, 0x12, 0x0c, 0x11, 0x02, 0x12, 0x0a, 0x11, 0x43, +0x09, 0x04, 0x09, 0x0c, 0x09, 0x18, 0x08, 0x0c, 0x05, 0xd0, 0x08, 0x04, +0x00, 0x0c, 0x09, 0x0c, 0x41, 0x18, 0x08, 0x0c, 0xf9, 0xd1, 0x38, 0x1c, +0xff, 0xf7, 0x2f, 0xfe, 0xc0, 0x43, 0x00, 0x04, 0x00, 0x0c, 0x7f, 0xb0, +0x19, 0xb0, 0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0xb0, 0xb4, 0x00, 0x22, +0x00, 0x29, 0x2e, 0xd0, 0x83, 0x07, 0x9b, 0x0f, 0xdc, 0x00, 0x47, 0x18, +0x04, 0x25, 0xef, 0x1b, 0xbf, 0x07, 0xbf, 0x0f, 0xff, 0x00, 0x80, 0x08, +0x80, 0x00, 0x59, 0x18, 0x03, 0x31, 0x89, 0x08, 0x4d, 0x1e, 0x02, 0xc8, +0xe1, 0x40, 0xa1, 0x40, 0x6b, 0x1e, 0x00, 0x2d, 0x09, 0xd0, 0x0c, 0x04, +0x24, 0x0c, 0xa2, 0x18, 0x09, 0x0c, 0x8a, 0x18, 0x02, 0xc8, 0x1c, 0x1c, +0x01, 0x3b, 0x00, 0x2c, 0xf5, 0xd1, 0xb9, 0x40, 0x08, 0x1c, 0xf8, 0x40, +0x01, 0x04, 0x09, 0x0c, 0x89, 0x18, 0x00, 0x0c, 0x42, 0x18, 0x10, 0x0c, +0x05, 0xd0, 0x10, 0x04, 0x00, 0x0c, 0x11, 0x0c, 0x42, 0x18, 0x10, 0x0c, +0xf9, 0xd1, 0x10, 0x04, 0x00, 0x0c, 0xb0, 0xbc, 0x70, 0x47, 0x00, 0x00, +0x90, 0xb4, 0x00, 0x20, 0x01, 0x27, 0x11, 0x49, 0x42, 0x00, 0x12, 0x18, +0xd2, 0x00, 0x53, 0x18, 0x9c, 0x68, 0x01, 0x23, +0x9b, 0x07, 0x23, 0x43, 0x1b, 0x68, 0x1b, 0x03, 0x1b, 0x0b, 0x8a, 0x58, +0x12, 0x03, 0x12, 0x0b, 0x93, 0x42, 0x0c, 0xd1, 0x01, 0x30, 0x04, 0x28, +0xec, 0xd3, 0x08, 0x48, 0xc0, 0x6a, 0x01, 0x03, 0x09, 0x0b, 0x07, 0x48, +0x00, 0x6f, 0x00, 0x03, 0x00, 0x0b, 0x81, 0x42, 0x02, 0xd0, 0x38, 0x1c, +0x90, 0xbc, 0x70, 0x47, 0x00, 0x20, 0xfb, 0xe7, 0xa8, 0x03, 0x00, 0x80, +0x00, 0x40, 0x14, 0x40, 0x68, 0x0e, 0x00, 0x80, 0x98, 0xb4, 0x14, 0x4a, +0xc0, 0x46, 0x00, 0x92, 0x83, 0x00, 0x13, 0x48, 0xc0, 0x58, 0x07, 0x03, +0x3f, 0x0b, 0x12, 0x48, 0xc0, 0x58, 0x02, 0x03, 0x12, 0x0b, 0x11, 0x48, +0xc0, 0x58, 0x00, 0x03, 0x00, 0x0b, 0x10, 0x4c, 0xe4, 0x58, 0x01, 0x23, +0x9b, 0x07, 0x23, 0x43, 0x1b, 0x68, 0x9b, 0x00, 0xcc, 0x00, 0x01, 0x21, +0x98, 0x42, 0x01, 0xd1, 0x08, 0x1c, 0x09, 0xe0, 0x98, 0x42, 0x03, 0xd9, +0x10, 0x1a, 0xda, 0x1b, 0x80, 0x18, 0x00, 0xe0, 0x18, 0x1a, 0x84, 0x42, +0xf4, 0xd3, 0x00, 0x20, 0x98, 0xbc, 0x70, 0x47, 0x55, 0x55, 0x55, 0x55, +0x20, 0x04, 0x00, 0x80, 0x28, 0x04, 0x00, 0x80, 0x08, 0x04, 0x00, 0x80, +0x18, 0x04, 0x00, 0x80, 0x80, 0xb4, 0x13, 0x04, 0x00, 0xd0, 0x01, 0x3a, +0x80, 0x00, 0x0b, 0x1c, 0x13, 0x49, 0x0f, 0x58, 0xc0, 0x46, 0x3b, 0x60, +0x0b, 0x58, 0xc0, 0x46, 0x5a, 0x60, 0x0a, 0x58, 0x08, 0x32, 0x10, 0x4b, +0x1b, 0x58, 0x9a, 0x42, 0x01, 0xd3, 0x0f, 0x4a, 0x12, 0x58, 0x0f, 0x4b, +0x1f, 0x58, 0x01, 0x23, 0x9b, 0x07, 0x3b, 0x43, 0x1b, 0x68, 0x9b, 0x00, +0x17, 0x03, 0x3f, 0x0b, 0x9f, 0x42, 0x06, 0xd1, 0x0a, 0x48, 0xc1, 0x68, +0x01, 0x31, 0xc1, 0x60, 0x01, 0x20, 0x80, 0xbc, 0x70, 0x47, 0x08, 0x4b, +0x1b, 0x58, 0xc0, 0x46, 0x1a, 0x60, 0x0a, 0x50, 0x00, 0x20, 0xf6, 0xe7, +0x08, 0x04, 0x00, 0x80, 0x28, 0x04, 0x00, 0x80, 0x20, 0x04, 0x00, 0x80, +0x18, 0x04, 0x00, 0x80, 0xa0, 0x82, 0x20, 0x40, 0x10, 0x04, 0x00, 0x80, +0xff, 0x5f, 0x2d, 0xe9, 0x48, 0xfe, 0xff, 0xeb, 0x01, 0xb6, 0xa0, 0xe3, +0x01, 0xb1, 0x8b, 0xe2, 0x02, 0x8a, 0xa0, 0xe3, 0x01, 0x7a, 0xa0, 0xe3, +0x01, 0xa9, 0xa0, 0xe3, 0x01, 0x56, 0xa0, 0xe3, 0xc8, 0x60, 0x9f, 0xe5, +0xc8, 0x90, 0x9f, 0xe5, 0x14, 0x40, 0x9b, 0xe5, 0x00, 0x00, 0x54, 0xe3, +0x2c, 0x00, 0x00, 0x0a, 0x03, 0x0a, 0x14, 0xe3, 0x11, 0x00, 0x00, 0x0a, +0x0c, 0x00, 0x96, 0xe5, 0x00, 0x00, 0x50, 0xe3, 0x21, 0x00, 0x00, 0x0a, +0x01, 0x0a, 0x14, 0xe3, 0x05, 0x00, 0x00, 0x0a, 0x1c, 0x00, 0x96, 0xe5, +0x01, 0x0a, 0xc0, 0xe3, 0x1c, 0x00, 0x86, 0xe5, 0x1c, 0x00, 0x85, 0xe5, +0x14, 0x70, 0x85, 0xe5, 0x06, 0x00, 0x00, 0xea, 0x02, 0x0a, 0x14, 0xe3, +0x04, 0x00, 0x00, 0x0a, 0x1c, 0x00, 0x96, 0xe5, 0x02, 0x0a, 0xc0, 0xe3, +0x1c, 0x00, 0x86, 0xe5, 0x1c, 0x00, 0x85, 0xe5, 0x14, 0x80, 0x85, 0xe5, +0x01, 0x09, 0x14, 0xe3, 0x04, 0x00, 0x00, 0x0a, 0x1c, 0x00, 0x96, 0xe5, +0x01, 0x09, 0xc0, 0xe3, 0x1c, 0x00, 0x86, 0xe5, 0x1c, 0x00, 0x85, 0xe5, +0x14, 0xa0, 0x85, 0xe5, 0x02, 0x00, 0x14, 0xe3, 0x40, 0x00, 0x00, 0x1b, +0x01, 0x00, 0x14, 0xe3, 0x54, 0x00, 0x00, 0x1b, 0x02, 0x0b, 0x14, 0xe3, +0x67, 0x00, 0x00, 0x1b, 0x01, 0x0b, 0x14, 0xe3, 0x20, 0x00, 0x00, 0x1b, +0x18, 0x00, 0x99, 0xe5, 0x01, 0x00, 0x80, 0xe2, 0x18, 0x00, 0x89, 0xe5, +0xd5, 0xff, 0xff, 0xea, 0x1c, 0x00, 0x96, 0xe5, 0x01, 0x0a, 0xc0, 0xe3, +0x1c, 0x00, 0x86, 0xe5, 0x1c, 0x00, 0x85, 0xe5, +0x14, 0x70, 0x85, 0xe5, 0xe1, 0xff, 0xff, 0xea, 0xff, 0x5f, 0xbd, 0xe8, +0x04, 0xf0, 0x5e, 0xe2, 0x68, 0x0e, 0x00, 0x80, 0x08, 0x83, 0x20, 0x40, +0x10, 0x10, 0x1f, 0xe5, 0x14, 0x30, 0x91, 0xe5, 0x00, 0x20, 0xc3, 0xe1, +0x14, 0x20, 0x81, 0xe5, 0x01, 0x16, 0xa0, 0xe3, 0x0c, 0x20, 0x81, 0xe5, +0x0b, 0x12, 0xa0, 0xe3, 0x00, 0x00, 0x81, 0xe5, 0x18, 0x10, 0x9f, 0xe5, +0xb0, 0x24, 0xd1, 0xe1, 0x01, 0x20, 0x82, 0xe2, 0xb0, 0x24, 0xc1, 0xe1, +0x3c, 0x20, 0x91, 0xe5, 0x00, 0x00, 0x82, 0xe1, 0x3c, 0x00, 0x81, 0xe5, +0x1e, 0xff, 0x2f, 0xe1, 0xa0, 0x82, 0x20, 0x40, 0xff, 0xff, 0xff, 0xea, +0xfe, 0xff, 0xff, 0xea, 0x01, 0x0b, 0xa0, 0xe3, 0x01, 0x16, 0xa0, 0xe3, +0x14, 0x00, 0x81, 0xe5, 0x00, 0x1a, 0x81, 0xe1, 0x24, 0x20, 0x91, 0xe5, +0x70, 0x00, 0x1f, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x24, 0x20, 0x80, 0xe5, +0x28, 0x10, 0x91, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x28, 0x10, 0x80, 0xe5, +0x2c, 0x20, 0x90, 0xe5, 0x01, 0x20, 0x82, 0xe2, 0x2c, 0x20, 0x80, 0xe5, +0x3f, 0x00, 0x01, 0xe2, 0x3f, 0x00, 0x50, 0xe3, 0x1e, 0xff, 0x2f, 0x11, +0x18, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x10, 0x81, 0xe2, +0x00, 0x10, 0x80, 0xe5, 0x02, 0x18, 0xa0, 0xe3, 0x0b, 0x02, 0xa0, 0xe3, +0x00, 0x10, 0x80, 0xe5, 0x1e, 0xff, 0x2f, 0xe1, 0x30, 0x04, 0x00, 0x80, +0x01, 0x06, 0xa0, 0xe3, 0x01, 0x01, 0x80, 0xe2, 0x00, 0x10, 0x90, 0xe5, +0x01, 0x08, 0x11, 0xe3, 0x0b, 0x10, 0xa0, 0xe3, 0x02, 0x19, 0x81, 0xe2, +0x05, 0x00, 0x00, 0x1a, 0x00, 0x20, 0x90, 0xe5, 0x42, 0x28, 0xb0, 0xe1, +0x05, 0x00, 0x00, 0x1a, 0x00, 0x00, 0x90, 0xe5, 0x02, 0x0c, 0x10, 0xe3, +0x02, 0x00, 0x00, 0x0a, 0x06, 0x07, 0xa0, 0xe3, 0x4c, 0x11, 0x80, 0xe5, +0x03, 0x00, 0x00, 0xea, 0x0c, 0x00, 0x9f, 0xe5, 0x00, 0x00, 0x00, 0x00, +0x40, 0x10, 0x80, 0xe5, 0xff, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, +0x00, 0x00, 0x00, 0x80, 0x01, 0x06, 0xa0, 0xe3, 0x01, 0x01, 0x80, 0xe2, +0x00, 0x10, 0x90, 0xe5, 0x01, 0x08, 0x11, 0xe3, 0x0c, 0x10, 0xa0, 0xe3, +0x02, 0x19, 0x81, 0xe2, 0x05, 0x00, 0x00, 0x1a, 0x00, 0x20, 0x90, 0xe5, +0x42, 0x28, 0xb0, 0xe1, 0x05, 0x00, 0x00, 0x1a, 0x00, 0x00, 0x90, 0xe5, +0x02, 0x0c, 0x10, 0xe3, 0x02, 0x00, 0x00, 0x0a, 0x06, 0x07, 0xa0, 0xe3, +0x4c, 0x11, 0x80, 0xe5, 0x03, 0x00, 0x00, 0xea, 0x4c, 0x00, 0x1f, 0xe5, +0x00, 0x00, 0x00, 0x00, 0x40, 0x10, 0x80, 0xe5, 0xff, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0x02, 0x1b, 0xa0, 0xe3, 0x01, 0x06, 0xa0, 0xe3, -0x14, 0x10, 0x80, 0xe5, 0x1e, 0xff, 0x2f, 0xe1, 0x04, 0x21, 0x1f, 0xe5, -0x10, 0x30, 0x92, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x80, 0xe5, -0x18, 0x00, 0x92, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x81, 0xe5, -0x00, 0x10, 0xa0, 0xe3, 0x10, 0x10, 0x82, 0xe5, 0x01, 0x06, 0xa0, 0xe3, -0x18, 0x10, 0x82, 0xe5, 0x0c, 0x10, 0x80, 0xe5, 0x18, 0x10, 0x92, 0xe5, +0x14, 0x10, 0x80, 0xe5, 0x1e, 0xff, 0x2f, 0xe1, 0x80, 0x21, 0x1f, 0xe5, +0x14, 0x30, 0x92, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x80, 0xe5, +0x1c, 0x00, 0x92, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x81, 0xe5, +0x00, 0x10, 0xa0, 0xe3, 0x14, 0x10, 0x82, 0xe5, 0x01, 0x06, 0xa0, 0xe3, +0x1c, 0x10, 0x82, 0xe5, 0x0c, 0x10, 0x80, 0xe5, 0x1c, 0x10, 0x92, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x1c, 0x10, 0x80, 0xe5, 0x1e, 0xff, 0x2f, 0xe1, -0x44, 0x21, 0x1f, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x18, 0x10, 0x82, 0xe5, -0x01, 0x16, 0xa0, 0xe3, 0x10, 0x00, 0x82, 0xe5, 0x0c, 0x00, 0x81, 0xe5, -0x18, 0x00, 0x92, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x1c, 0x00, 0x81, 0xe5, +0xc0, 0x21, 0x1f, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x1c, 0x10, 0x82, 0xe5, +0x01, 0x16, 0xa0, 0xe3, 0x14, 0x00, 0x82, 0xe5, 0x0c, 0x00, 0x81, 0xe5, +0x1c, 0x00, 0x92, 0xe5, 0x00, 0x00, 0x00, 0x00, 0x1c, 0x00, 0x81, 0xe5, 0x1e, 0xff, 0x2f, 0xe1, 0x80, 0xb5, 0x0f, 0x1c, 0x38, 0x1c, 0x00, 0xf0, -0x17, 0xf8, 0x00, 0x28, 0x02, 0xd0, 0x38, 0x1c, 0x00, 0xf0, 0x76, 0xf8, -0x00, 0x20, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x80, 0xb5, 0x0f, 0x1c, -0x38, 0x1c, 0x00, 0xf0, 0x09, 0xf8, 0x00, 0x28, 0x02, 0xd0, 0x38, 0x1c, -0x00, 0xf0, 0x68, 0xf8, 0x00, 0x20, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, -0xf0, 0xb4, 0x07, 0x68, 0x3a, 0x78, 0xd2, 0x07, 0xd2, 0x0f, 0x00, 0x24, -0x00, 0x2a, 0x03, 0xd0, 0xff, 0x22, 0x01, 0x32, +0x17, 0xf8, 0x00, 0x28, 0x02, 0xd0, 0x38, 0x1c, +0x00, 0xf0, 0x92, 0xf8, 0x00, 0x20, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, +0x80, 0xb5, 0x0f, 0x1c, 0x38, 0x1c, 0x00, 0xf0, 0x09, 0xf8, 0x00, 0x28, +0x02, 0xd0, 0x38, 0x1c, 0x00, 0xf0, 0x84, 0xf8, 0x00, 0x20, 0x80, 0xbc, +0x08, 0xbc, 0x18, 0x47, 0xf0, 0xb4, 0x07, 0x68, 0x3a, 0x78, 0xd2, 0x07, +0xd2, 0x0f, 0x00, 0x24, 0x00, 0x2a, 0x03, 0xd0, 0xff, 0x22, 0x01, 0x32, 0x42, 0x60, 0x00, 0xe0, 0x44, 0x60, 0x3a, 0x7b, 0x7b, 0x7b, 0x1b, 0x02, 0x1a, 0x43, 0x81, 0x2a, 0x08, 0xd1, 0x01, 0x23, 0x5b, 0x02, 0x42, 0x68, 0x1a, 0x43, 0x42, 0x60, 0x04, 0x22, 0xbf, 0x18, 0x82, 0x60, 0x00, 0xe0, 0x84, 0x60, 0x3a, 0x7b, 0x7b, 0x7b, 0x1b, 0x02, 0x1a, 0x43, 0x08, 0x2a, 0x06, 0xd1, 0x06, 0x23, 0x41, 0x68, 0x19, 0x43, 0x41, 0x60, 0x81, 0x68, -0x0e, 0x31, 0x2c, 0xe0, 0x13, 0x02, 0x12, 0x0a, 0x12, 0x06, 0x12, 0x0e, -0x1a, 0x43, 0x12, 0x04, 0x12, 0x0c, 0x2e, 0x3a, 0x16, 0x4b, 0x9a, 0x42, -0x24, 0xd8, 0x01, 0x25, 0x42, 0x68, 0x15, 0x43, 0x45, 0x60, 0xba, 0x7b, -0xfb, 0x7b, 0x1b, 0x02, 0x1a, 0x43, 0x12, 0x4b, 0x9a, 0x42, 0x19, 0xd1, -0xfb, 0x1d, 0x09, 0x33, 0x44, 0xcb, 0x9b, 0x07, 0xdb, 0x0e, 0xda, 0x40, -0x5b, 0x42, 0x20, 0x33, 0x9e, 0x40, 0x16, 0x43, 0x03, 0x2e, 0x0f, 0xd1, -0x39, 0x7d, 0x7b, 0x7d, 0x1b, 0x02, 0x19, 0x43, 0x08, 0x29, 0x07, 0xd1, -0x04, 0x21, 0x29, 0x43, 0x41, 0x60, 0x81, 0x68, 0x16, 0x31, 0x81, 0x60, -0x01, 0x21, 0x01, 0xe0, 0x00, 0x21, 0x84, 0x60, 0x08, 0x1c, 0xf0, 0xbc, -0x70, 0x47, 0x00, 0x00, 0xae, 0x05, 0x00, 0x00, 0xaa, 0xaa, 0x00, 0x00, -0x80, 0xb4, 0x42, 0x68, 0xd1, 0x08, 0x3f, 0xd3, 0x01, 0x68, 0x83, 0x68, -0x59, 0x18, 0x02, 0x39, 0x8f, 0x78, 0xff, 0x06, 0xff, 0x0e, 0x05, 0x2f, -0x03, 0xd1, 0xda, 0x1d, 0x0d, 0x32, 0xc2, 0x60, 0x05, 0xe0, 0xbf, 0x00, -0xdb, 0x19, 0xc3, 0x60, 0x08, 0x23, 0x1a, 0x43, 0x42, 0x60, 0x8a, 0x78, -0xd2, 0x06, 0xd2, 0x0e, 0x92, 0x00, 0x02, 0x61, 0x0a, 0x79, 0x4b, 0x79, -0x1b, 0x02, 0x1a, 0x43, 0x13, 0x02, 0x12, 0x0a, 0x12, 0x06, 0x12, 0x0e, -0x1a, 0x43, 0x12, 0x04, 0x12, 0x0c, 0x42, 0x61, 0xca, 0x7a, 0x06, 0x2a, -0x03, 0xd1, 0x10, 0x23, 0x42, 0x68, 0x1a, 0x43, 0x10, 0xe0, 0x11, 0x2a, -0x03, 0xd1, 0x20, 0x23, 0x42, 0x68, 0x1a, 0x43, 0x0a, 0xe0, 0x33, 0x2a, -0x03, 0xd1, 0x40, 0x23, 0x42, 0x68, 0x1a, 0x43, 0x04, 0xe0, 0x32, 0x2a, -0x03, 0xd1, 0x80, 0x23, 0x42, 0x68, 0x1a, 0x43, 0x42, 0x60, 0xc9, 0x7a, -0xc0, 0x46, 0x01, 0x76, 0x80, 0xbc, 0x70, 0x47, 0x0a, 0x78, 0xc0, 0x46, -0x02, 0x60, 0x4b, 0x78, 0x1b, 0x02, 0x1a, 0x43, 0x02, 0x60, 0x8b, 0x78, -0x1b, 0x04, 0x1a, 0x43, 0x02, 0x60, 0xc9, 0x78, 0x09, 0x06, 0x11, 0x43, -0x01, 0x60, 0x70, 0x47, 0xf0, 0xb5, 0x00, 0x21, 0x00, 0x24, 0x00, 0x27, -0x80, 0x6a, 0x02, 0x7b, 0x43, 0x7b, 0x1b, 0x02, 0x1a, 0x43, 0x81, 0x2a, -0x00, 0xd1, 0x04, 0x30, 0x02, 0x7b, 0x43, 0x7b, 0x1b, 0x02, 0x1a, 0x43, -0x08, 0x2a, 0x01, 0xd1, 0x0e, 0x30, 0x24, 0xe0, 0x13, 0x02, 0x12, 0x0a, -0x12, 0x06, 0x12, 0x0e, 0x1a, 0x43, 0x12, 0x04, 0x12, 0x0c, 0x2e, 0x3a, -0x42, 0x4b, 0x9a, 0x42, 0x74, 0xd8, 0x82, 0x7b, 0xc3, 0x7b, 0x1b, 0x02, -0x1a, 0x43, 0x40, 0x4b, 0x9a, 0x42, 0x6e, 0xd1, 0xc3, 0x1d, 0x09, 0x33, -0x24, 0xcb, 0x9b, 0x07, 0xdb, 0x0e, 0xda, 0x40, 0x5b, 0x42, 0x20, 0x33, -0x9d, 0x40, 0x15, 0x43, 0x03, 0x2d, 0x63, 0xd1, 0x02, 0x7d, 0x43, 0x7d, -0x1b, 0x02, 0x1a, 0x43, 0x08, 0x2a, 0x5c, 0xd1, 0x16, 0x30, 0x42, 0x7a, -0x11, 0x2a, 0x58, 0xd1, 0x02, 0x78, 0xd2, 0x06, 0xd2, 0x0e, 0x92, 0x00, -0x10, 0x18, 0x02, 0x78, 0x43, 0x78, 0x1b, 0x02, 0x1a, 0x43, 0x43, 0x23, -0x1b, 0x02, 0x9a, 0x42, 0x4b, 0xd1, 0xc3, 0x1d, 0x01, 0x33, 0xd8, 0x1d, -0xe9, 0x30, 0x02, 0x78, 0x35, 0x2a, 0x04, 0xd1, -0x82, 0x78, 0x05, 0x2a, 0x19, 0xd1, 0x01, 0x21, 0x0d, 0xe0, 0x01, 0x2a, -0x01, 0xd1, 0x87, 0x1c, 0x09, 0xe0, 0x03, 0x2a, 0x01, 0xd1, 0x84, 0x1c, -0x05, 0xe0, 0xff, 0x2a, 0x0d, 0xd0, 0x00, 0x2a, 0x01, 0xd1, 0x01, 0x30, -0x02, 0xe0, 0x42, 0x78, 0x10, 0x18, 0x02, 0x30, 0x00, 0x2f, 0xe4, 0xd0, -0x00, 0x2c, 0xe2, 0xd0, 0x00, 0x29, 0xe0, 0xd0, 0x01, 0xe0, 0x00, 0x29, -0x2e, 0xd0, 0xd9, 0x1d, 0x09, 0x31, 0x0e, 0x1c, 0x19, 0x4d, 0xe3, 0x23, -0x1b, 0x01, 0xe8, 0x18, 0xff, 0xf7, 0x78, 0xff, 0x00, 0x2f, 0x04, 0xd0, -0x16, 0x4b, 0xe8, 0x18, 0x39, 0x1c, 0xff, 0xf7, 0x71, 0xff, 0x00, 0x2c, -0x04, 0xd0, 0x14, 0x4b, 0xe8, 0x18, 0x21, 0x1c, 0xff, 0xf7, 0x6a, 0xff, -0x31, 0x1c, 0x12, 0x4d, 0xe8, 0x1d, 0x11, 0x30, 0xff, 0xf7, 0x64, 0xff, -0x00, 0x2f, 0x08, 0xd0, 0xe8, 0x1d, 0x0d, 0x30, 0x39, 0x1c, 0xff, 0xf7, -0x5d, 0xff, 0x02, 0xe0, 0x08, 0xe0, 0x07, 0xe0, 0x06, 0xe0, 0x00, 0x2c, -0x04, 0xd0, 0xe8, 0x1d, 0x09, 0x30, 0x21, 0x1c, 0xff, 0xf7, 0x52, 0xff, -0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x00, 0xae, 0x05, 0x00, 0x00, -0xaa, 0xaa, 0x00, 0x00, 0xf8, 0x0d, 0x00, 0x80, 0x34, 0x0e, 0x00, 0x00, -0x38, 0x0e, 0x00, 0x00, 0x98, 0x6e, 0x21, 0x40, 0x80, 0xb5, 0x07, 0x1c, -0x48, 0x68, 0x80, 0x09, 0x26, 0xd3, 0xb8, 0x6a, 0xc9, 0x68, 0x40, 0x18, -0x01, 0x23, 0x9b, 0x07, 0x02, 0x30, 0x18, 0x43, 0x00, 0x68, 0x00, 0x04, -0x00, 0x0c, 0x11, 0x23, 0x9b, 0x02, 0x98, 0x42, 0x18, 0xd1, 0x78, 0x6a, -0x39, 0x6b, 0xc0, 0x46, 0x48, 0x62, 0x38, 0x6b, 0x02, 0xf0, 0x26, 0xfc, -0x38, 0x1c, 0x02, 0xf0, 0xdc, 0xf8, 0x01, 0x20, 0x07, 0x49, 0xc0, 0x46, -0xc8, 0x70, 0x07, 0x49, 0x4a, 0x6c, 0x12, 0x18, 0x4a, 0x64, 0x06, 0x49, -0x8a, 0x6d, 0x12, 0x18, 0x8a, 0x65, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, -0x00, 0x20, 0xfa, 0xe7, 0xa8, 0x19, 0x00, 0x80, 0x94, 0x2c, 0x00, 0x80, -0x2c, 0x2c, 0x00, 0x80, 0x81, 0x07, 0x19, 0xd0, 0x80, 0x08, 0x80, 0x00, -0x01, 0x23, 0x9b, 0x07, 0x01, 0x1d, 0x18, 0x43, 0x00, 0x68, 0x19, 0x43, -0x09, 0x68, 0x02, 0x02, 0x12, 0x0e, 0x12, 0x06, 0x00, 0x0a, 0xff, 0x23, -0x1b, 0x04, 0x18, 0x40, 0x10, 0x43, 0x0a, 0x0a, 0x12, 0x06, 0x12, 0x0e, -0x10, 0x43, 0x09, 0x02, 0x1b, 0x0a, 0x19, 0x40, 0x08, 0x43, 0x70, 0x47, -0x01, 0x23, 0x9b, 0x07, 0x18, 0x43, 0x00, 0x68, 0x01, 0x06, 0x02, 0x02, -0xff, 0x23, 0x1b, 0x04, 0x1a, 0x40, 0x11, 0x43, 0x02, 0x0a, 0x1b, 0x0a, -0x1a, 0x40, 0x11, 0x43, 0x00, 0x0e, 0x08, 0x43, 0xed, 0xe7, 0x00, 0x00, -0xf0, 0xb5, 0x04, 0x23, 0x81, 0x6b, 0x19, 0x40, 0x00, 0x22, 0x00, 0x29, -0x46, 0xd0, 0xc7, 0x1d, 0x39, 0x37, 0x39, 0x7b, 0x33, 0x29, 0x01, 0xd0, -0x32, 0x29, 0x3f, 0xd1, 0x01, 0x6b, 0xc0, 0x46, 0x4a, 0x65, 0xc4, 0x1d, -0x2d, 0x34, 0xcd, 0x1d, 0x2d, 0x35, 0x00, 0x22, 0x93, 0x00, 0xe6, 0x58, -0xc0, 0x46, 0xee, 0x50, 0x01, 0x32, 0x07, 0x2a, 0xf8, 0xd3, 0x82, 0x6a, -0xc0, 0x46, 0x4a, 0x63, 0x82, 0x6a, 0xc0, 0x46, 0x8a, 0x62, 0x7a, 0x8b, -0xcb, 0x1d, 0x39, 0x33, 0x5a, 0x83, 0x40, 0x6a, 0xc0, 0x46, 0x48, 0x62, -0x12, 0x48, 0x01, 0x27, 0x42, 0x68, 0x00, 0x2a, 0x10, 0xd1, 0xc2, 0x68, -0x00, 0x2a, 0x13, 0xd1, 0x42, 0x69, 0x00, 0x2a, 0x0d, 0xd1, 0x01, 0x61, -0xc1, 0x60, 0x01, 0x6a, 0x02, 0x29, 0x02, 0xd3, 0x20, 0x30, 0x07, 0x71, -0x0c, 0xe0, 0x00, 0xf0, 0x13, 0xf8, 0x09, 0xe0, -0xc2, 0x68, 0x00, 0x2a, 0x02, 0xd1, 0x01, 0x61, 0xc1, 0x60, 0x03, 0xe0, -0x02, 0x69, 0xc0, 0x46, 0x51, 0x65, 0x01, 0x61, 0x38, 0x1c, 0xf0, 0xbc, -0x08, 0xbc, 0x18, 0x47, 0x10, 0x1c, 0xfa, 0xe7, 0xfc, 0x05, 0x00, 0x80, -0x90, 0xb5, 0x1e, 0x49, 0x00, 0x27, 0xca, 0x68, 0x00, 0x2a, 0x35, 0xd0, -0xc8, 0x1d, 0xf9, 0x30, 0x82, 0x62, 0xca, 0x68, 0x92, 0x6a, 0xc0, 0x46, -0xc2, 0x62, 0xca, 0x69, 0x53, 0x00, 0x9b, 0x18, 0x5b, 0x02, 0x17, 0x4a, -0x9c, 0x18, 0x17, 0x4b, 0xe3, 0x18, 0x82, 0x63, 0x03, 0x63, 0xcb, 0x1d, -0xff, 0x33, 0x5a, 0x33, 0x1f, 0x72, 0x3a, 0x1c, 0xcb, 0x69, 0x00, 0x2b, -0x01, 0xd0, 0xca, 0x61, 0x01, 0xe0, 0x01, 0x23, 0xcb, 0x61, 0x0f, 0x1c, -0xc9, 0x68, 0x49, 0x6a, 0x09, 0x89, 0x01, 0x31, 0x41, 0x63, 0xf8, 0x1d, -0xff, 0x30, 0x3a, 0x30, 0x42, 0x60, 0x02, 0x82, 0x82, 0x60, 0xc2, 0x60, -0x38, 0x1c, 0x00, 0xf0, 0xcb, 0xfa, 0x38, 0x6a, 0x01, 0x30, 0x38, 0x62, -0x38, 0x1c, 0x00, 0xf0, 0x0b, 0xf8, 0x90, 0xbc, 0x08, 0xbc, 0x18, 0x47, -0x38, 0x1c, 0xfa, 0xe7, 0xfc, 0x05, 0x00, 0x80, 0x48, 0xad, 0x20, 0x40, -0x64, 0x07, 0x00, 0x00, 0xf0, 0xb5, 0x07, 0x1c, 0xf9, 0x1d, 0xf9, 0x31, +0x0e, 0x31, 0x3c, 0xe0, 0xc1, 0x23, 0xdb, 0x00, 0x9a, 0x42, 0x03, 0xd1, +0x41, 0x68, 0x24, 0x4b, 0x19, 0x43, 0x3e, 0xe0, 0x23, 0x4b, 0x9a, 0x42, +0x04, 0xd1, 0x01, 0x23, 0x1b, 0x03, 0x41, 0x68, 0x19, 0x43, 0x36, 0xe0, +0x13, 0x02, 0x12, 0x0a, 0x12, 0x06, 0x12, 0x0e, 0x1a, 0x43, 0x12, 0x04, +0x12, 0x0c, 0x2e, 0x3a, 0x1c, 0x4b, 0x9a, 0x42, 0x2d, 0xd8, 0x01, 0x25, +0x42, 0x68, 0x15, 0x43, 0x45, 0x60, 0xba, 0x7b, 0xfb, 0x7b, 0x1b, 0x02, +0x1a, 0x43, 0x18, 0x4b, 0x9a, 0x42, 0x22, 0xd1, 0xfb, 0x1d, 0x09, 0x33, +0x44, 0xcb, 0x9b, 0x07, 0xdb, 0x0e, 0xda, 0x40, 0x5b, 0x42, 0x20, 0x33, +0x9e, 0x40, 0x16, 0x43, 0x03, 0x2e, 0x18, 0xd1, 0x39, 0x7d, 0x7b, 0x7d, +0x1b, 0x02, 0x19, 0x43, 0x08, 0x29, 0x07, 0xd1, 0x04, 0x21, 0x29, 0x43, +0x41, 0x60, 0x81, 0x68, 0x16, 0x31, 0x81, 0x60, 0x01, 0x21, 0x0a, 0xe0, +0xc1, 0x23, 0xdb, 0x00, 0x99, 0x42, 0x04, 0xd1, 0x01, 0x21, 0x89, 0x03, +0x29, 0x43, 0x41, 0x60, 0x00, 0xe0, 0x84, 0x60, 0x00, 0x21, 0x08, 0x1c, +0xf0, 0xbc, 0x70, 0x47, 0x02, 0x40, 0x00, 0x00, 0x81, 0x80, 0x00, 0x00, +0xae, 0x05, 0x00, 0x00, 0xaa, 0xaa, 0x00, 0x00, 0x80, 0xb4, 0x42, 0x68, +0xd1, 0x08, 0x3f, 0xd3, 0x01, 0x68, 0x83, 0x68, 0x59, 0x18, 0x02, 0x39, +0x8f, 0x78, 0x3f, 0x07, 0x3f, 0x0f, 0x05, 0x2f, 0x03, 0xd1, 0xda, 0x1d, +0x0d, 0x32, 0xc2, 0x60, 0x05, 0xe0, 0xbf, 0x00, 0xdb, 0x19, 0xc3, 0x60, +0x08, 0x23, 0x1a, 0x43, 0x42, 0x60, 0x8a, 0x78, 0x12, 0x07, 0x12, 0x0f, +0x92, 0x00, 0x02, 0x61, 0x0a, 0x79, 0x4b, 0x79, 0x1b, 0x02, 0x1a, 0x43, +0x13, 0x02, 0x12, 0x0a, 0x12, 0x06, 0x12, 0x0e, 0x1a, 0x43, 0x12, 0x04, +0x12, 0x0c, 0x42, 0x61, 0xca, 0x7a, 0x06, 0x2a, 0x03, 0xd1, 0x10, 0x23, +0x42, 0x68, 0x1a, 0x43, 0x10, 0xe0, 0x11, 0x2a, 0x03, 0xd1, 0x20, 0x23, +0x42, 0x68, 0x1a, 0x43, 0x0a, 0xe0, 0x33, 0x2a, 0x03, 0xd1, 0x40, 0x23, +0x42, 0x68, 0x1a, 0x43, 0x04, 0xe0, 0x32, 0x2a, 0x03, 0xd1, 0x80, 0x23, +0x42, 0x68, 0x1a, 0x43, 0x42, 0x60, 0xc9, 0x7a, 0xc0, 0x46, 0x01, 0x76, +0x80, 0xbc, 0x70, 0x47, 0x0a, 0x78, 0xc0, 0x46, 0x02, 0x60, 0x4b, 0x78, +0x1b, 0x02, 0x1a, 0x43, 0x02, 0x60, 0x8b, 0x78, 0x1b, 0x04, 0x1a, 0x43, +0x02, 0x60, 0xc9, 0x78, 0x09, 0x06, 0x11, 0x43, 0x01, 0x60, 0x70, 0x47, +0x80, 0xb5, 0x07, 0x1c, 0x48, 0x68, 0x80, 0x09, 0x26, 0xd3, 0xb8, 0x6a, +0xc9, 0x68, 0x40, 0x18, 0x01, 0x23, 0x9b, 0x07, 0x02, 0x30, 0x18, 0x43, +0x00, 0x68, 0x00, 0x04, 0x00, 0x0c, 0x11, 0x23, 0x9b, 0x02, 0x98, 0x42, +0x18, 0xd1, 0x78, 0x6a, 0x39, 0x6b, 0xc0, 0x46, +0x48, 0x62, 0x38, 0x6b, 0x02, 0xf0, 0xd0, 0xf8, 0x38, 0x1c, 0x01, 0xf0, +0x8b, 0xfd, 0x01, 0x20, 0x07, 0x49, 0xc0, 0x46, 0xc8, 0x73, 0x07, 0x49, +0x4a, 0x6c, 0x12, 0x18, 0x4a, 0x64, 0x06, 0x49, 0x8a, 0x6d, 0x12, 0x18, +0x8a, 0x65, 0x80, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x00, 0x20, 0xfa, 0xe7, +0x18, 0x1a, 0x00, 0x80, 0x0c, 0x2b, 0x00, 0x80, 0xa4, 0x2a, 0x00, 0x80, +0x81, 0x07, 0x19, 0xd0, 0x80, 0x08, 0x80, 0x00, 0x01, 0x23, 0x9b, 0x07, +0x01, 0x1d, 0x18, 0x43, 0x00, 0x68, 0x19, 0x43, 0x09, 0x68, 0x02, 0x02, +0x12, 0x0e, 0x12, 0x06, 0x00, 0x0a, 0xff, 0x23, 0x1b, 0x04, 0x18, 0x40, +0x10, 0x43, 0x0a, 0x0a, 0x12, 0x06, 0x12, 0x0e, 0x10, 0x43, 0x09, 0x02, +0x1b, 0x0a, 0x19, 0x40, 0x08, 0x43, 0x70, 0x47, 0x01, 0x23, 0x9b, 0x07, +0x18, 0x43, 0x00, 0x68, 0x01, 0x06, 0x02, 0x02, 0xff, 0x23, 0x1b, 0x04, +0x1a, 0x40, 0x11, 0x43, 0x02, 0x0a, 0x1b, 0x0a, 0x1a, 0x40, 0x11, 0x43, +0x00, 0x0e, 0x08, 0x43, 0xed, 0xe7, 0x00, 0x00, 0xf0, 0xb5, 0x04, 0x23, +0x81, 0x6b, 0x19, 0x40, 0x00, 0x22, 0x00, 0x29, 0x46, 0xd0, 0xc7, 0x1d, +0x39, 0x37, 0x39, 0x7b, 0x33, 0x29, 0x01, 0xd0, 0x32, 0x29, 0x3f, 0xd1, +0x01, 0x6b, 0xc0, 0x46, 0x4a, 0x65, 0xc4, 0x1d, 0x2d, 0x34, 0xcd, 0x1d, +0x2d, 0x35, 0x00, 0x22, 0x93, 0x00, 0xe6, 0x58, 0xc0, 0x46, 0xee, 0x50, +0x01, 0x32, 0x07, 0x2a, 0xf8, 0xd3, 0x82, 0x6a, 0xc0, 0x46, 0x4a, 0x63, +0x82, 0x6a, 0xc0, 0x46, 0x8a, 0x62, 0x7a, 0x8b, 0xcb, 0x1d, 0x39, 0x33, +0x5a, 0x83, 0x40, 0x6a, 0xc0, 0x46, 0x48, 0x62, 0x12, 0x48, 0x01, 0x27, +0x42, 0x68, 0x00, 0x2a, 0x10, 0xd1, 0xc2, 0x68, 0x00, 0x2a, 0x13, 0xd1, +0x42, 0x69, 0x00, 0x2a, 0x0d, 0xd1, 0x01, 0x61, 0xc1, 0x60, 0x01, 0x6a, +0x02, 0x29, 0x02, 0xd3, 0x20, 0x30, 0x07, 0x71, 0x0c, 0xe0, 0x00, 0xf0, +0x13, 0xf8, 0x09, 0xe0, 0xc2, 0x68, 0x00, 0x2a, 0x02, 0xd1, 0x01, 0x61, +0xc1, 0x60, 0x03, 0xe0, 0x02, 0x69, 0xc0, 0x46, 0x51, 0x65, 0x01, 0x61, +0x38, 0x1c, 0xf0, 0xbc, 0x08, 0xbc, 0x18, 0x47, 0x10, 0x1c, 0xfa, 0xe7, +0x6c, 0x06, 0x00, 0x80, 0x80, 0xb5, 0x1e, 0x49, 0x00, 0x22, 0xcb, 0x68, +0x00, 0x2b, 0x34, 0xd0, 0xc8, 0x1d, 0xf9, 0x30, 0x83, 0x62, 0xcb, 0x68, +0x9b, 0x6a, 0xc0, 0x46, 0xc3, 0x62, 0xcf, 0x69, 0x7b, 0x00, 0xdf, 0x19, +0x7f, 0x02, 0x17, 0x4b, 0xff, 0x18, 0xff, 0x37, 0x65, 0x37, 0x83, 0x63, +0x07, 0x63, 0xcb, 0x1d, 0xff, 0x33, 0x5a, 0x33, 0x1a, 0x72, 0xcb, 0x69, +0x00, 0x2b, 0x01, 0xd0, 0xca, 0x61, 0x01, 0xe0, 0x01, 0x23, 0xcb, 0x61, +0x0f, 0x1c, 0xc9, 0x68, 0x49, 0x6a, 0x09, 0x89, 0x01, 0x31, 0x41, 0x63, +0xf8, 0x1d, 0xff, 0x30, 0x3a, 0x30, 0x42, 0x60, 0x02, 0x82, 0x82, 0x60, +0xc2, 0x60, 0x38, 0x1c, 0x00, 0xf0, 0xce, 0xfa, 0x38, 0x6a, 0x01, 0x30, +0x38, 0x62, 0x38, 0x1c, 0x00, 0xf0, 0x0a, 0xf8, 0x80, 0xbc, 0x08, 0xbc, +0x18, 0x47, 0x10, 0x1c, 0xfa, 0xe7, 0x00, 0x00, 0x6c, 0x06, 0x00, 0x80, +0x1c, 0xad, 0x20, 0x40, 0xf0, 0xb5, 0x07, 0x1c, 0xf9, 0x1d, 0xf9, 0x31, 0x88, 0x6a, 0xc2, 0x1d, 0x2d, 0x32, 0x01, 0x23, 0x9b, 0x07, 0x08, 0x32, 0x1a, 0x43, 0xc8, 0x6a, 0x12, 0x68, 0x12, 0x04, 0x12, 0x0c, 0x80, 0x18, 0x82, 0x79, 0xc3, 0x79, 0x1b, 0x02, 0x1a, 0x43, 0x13, 0x02, 0x12, 0x0a, 0x12, 0x06, 0x12, 0x0e, 0x1a, 0x43, 0x12, 0x04, 0x12, 0x0c, 0x02, 0x38, *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From bms at incunabulum.net Tue Feb 24 17:26:03 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Feb 24 17:26:09 2009 Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed In-Reply-To: References: <20080526110543.J26343@fledge.watson.org> Message-ID: <49A49A4A.4030902@incunabulum.net> Robert Watson wrote: > > .. > Just a reminder that 1 March is gradually approaching. It looks like > the new USB stack is settling nicely, so I currently have no plans to > defer the above schedule. Just to say: this is good news for 8.x, particularly for VIMAGE. Losing the Giant lock from the network drivers will resolve the possibility of a number of race conditions occurring in the network stack, which are particularly noticeable with VIMAGE, due to how protocol domains attach within vimages.. I'd expect that ongoing work could benefit by eliminating some use of netisrs, however, it might be a good idea to retain those for a little longer to make backporting to 7.x easier. thanks, BMS From yongari at FreeBSD.org Tue Feb 24 17:54:27 2009 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Tue Feb 24 17:54:33 2009 Subject: kern/89876: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx Message-ID: <200902250154.n1P1sQEi063818@freefall.freebsd.org> Synopsis: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx State-Changed-From-To: feedback->patched State-Changed-By: yongari State-Changed-When: Wed Feb 25 01:51:48 UTC 2009 State-Changed-Why: Firmware image updated to the latest one. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Feb 25 01:51:48 UTC 2009 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=89876 From siquijorphilips at gmail.com Tue Feb 24 23:38:28 2009 From: siquijorphilips at gmail.com (Siquijor Philips) Date: Tue Feb 24 23:38:35 2009 Subject: Questions on processing smaller frame size Message-ID: Can someone explain why FreeBSD network throughput (both incoming and outgoing traffic) decreases when smaller frame size being processed? With smaller frame size, corresponding packet rate (packet/sec or pps) increases and experiencing dropped packets. What causes dropping of packets with small frame size? My system is running on a 2x Quad-Core Intel Xeon machine with FreeBSD-7.1 RELEASE using 1-Gigabit 2-port Chelsio NIC connected on a Spirent traffic generator. Smaller frame sizes are tested on 64-byte, 128-byte, 256-byte and 512-byte. Default frame size of 1500-byte which is the default of an Ethernet is working fine. Below are my data; # ifconfig -m cxgb0: flags=8843 metric 0 mtu 1500 options=5bb capabilities=7bb ether 00:07:43:05:7b:ac inet 192.168.0.1 netmask 0xffffe000 broadcast 192.168.255.255 inet6 fe80::207:43ff:fe05:7bac%cxgb0 prefixlen 64 scopeid 0x1 media: Ethernet autoselect (1000baseTX ) status: active supported media: media autoselect media 1000baseTX mediaopt full-duplex media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP cxgb1: flags=8843 metric 0 mtu 1500 options=5bb capabilities=7bb ether 00:07:43:05:7b:ad inet 10.0.0.1 netmask 0xfff00000 broadcast 10.0.255.255 inet6 fe80::207:43ff:fe05:7bad%cxgb1 prefixlen 64 scopeid 0x2 media: Ethernet autoselect (1000baseTX ) status: active supported media: media autoselect media 1000baseTX mediaopt full-duplex media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP 1500-byte frame size -> OK --------------------- bwm-ng v0.6 (probing every 0.500s), press 'h' for help input: getifaddrs type: rate \ iface Rx Tx Total cxgb0: 938.58 Mb/s 938.58 Mb/s 1.83 Gb/s cxgb1: 938.28 Mb/s 938.58 Mb/s 1.83 Gb/s lo0: 0.00 b/s 0.00 b/s 0.00 b/s total: 1.83 Gb/s 1.83 Gb/s 3.67 Gb/s # netstat -I cxgb0 -w 1 -d input (cxgb0) output packets errs bytes packets errs bytes colls drops 82234 0 123059464 82229 0 123059464 0 0 82219 0 123031040 82240 0 123031040 0 0 82201 0 123017576 82187 0 123019072 0 0 82218 0 123025056 82242 0 123025056 0 0 82214 0 123028048 82247 0 123023560 0 0 82210 0 123023560 82209 0 123022064 0 0 82210 0 123020568 82244 0 123022064 0 0 82210 0 123023560 82226 0 123023560 0 0 82240 0 123057968 82208 0 123051984 0 0 82111 0 122870968 82161 0 122876952 0 0 82299 0 123158200 82312 0 123156704 0 0 82208 0 123013088 82226 0 123013088 0 0 82205 0 123022064 82229 0 123019072 0 0 82224 0 123028048 82213 0 123026552 0 0 82219 0 123025056 82252 0 123026552 0 0 82212 0 123023560 82218 0 123025056 0 0 82223 0 123026552 82231 0 123023560 0 0 82218 0 123023560 82212 0 123022064 0 0 82214 0 123028048 82252 0 123028048 0 0 82214 0 123023560 82226 0 123023560 0 0 # netstat -I cxgb1 -w 1 -d input (cxgb1) output packets errs bytes packets errs bytes colls drops 82220 0 122996632 82261 0 123029544 0 0 82211 0 122981672 82204 0 123022064 0 0 82207 0 122971200 82243 0 123022064 0 0 82215 0 122990648 82235 0 123022064 0 0 82220 0 122987656 82222 0 123029544 0 0 82209 0 122974192 82247 0 123025056 0 0 82215 0 122978680 82190 0 123025056 0 0 82226 0 122981672 82250 0 123023560 0 0 82214 0 122984664 82229 0 123022064 0 0 82217 0 122987656 82211 0 123025056 0 0 82214 0 122984664 82226 0 123023560 0 0 82224 0 122992144 82218 0 123023560 0 0 82208 0 122963720 82236 0 123025056 0 0 82218 0 122980176 82233 0 123022064 0 0 82217 0 122986160 82219 0 123028048 0 0 82215 0 122983168 82249 0 123023560 0 0 82208 0 122977184 82192 0 123025056 0 0 82214 0 122969704 82231 0 123019072 0 0 82214 0 122990648 82249 0 123031040 0 0 82210 0 122965216 82207 0 123019072 0 0 512-byte frame size: --------------------- bwm-ng v0.6 (probing every 0.500s), press 'h' for help input: getifaddrs type: rate | iface Rx Tx Total cxgb0: 911.85 Mb/s 407.88 Mb/s 1.29 Gb/s cxgb1: 898.39 Mb/s 318.05 Mb/s 1.19 Gb/s lo0: 0.00 b/s 0.00 b/s 0.00 b/s total: 1.77 Gb/s 725.93 Mb/s 2.48 Gb/s # netstat -I cxgb0 -w 1 -d input (cxgb0) output packets errs bytes packets errs bytes colls drops 234410 0 120264428 115185 0 58832496 0 120569 230622 0 118386352 106160 0 53905404 0 126996 232698 0 119392700 105872 0 53480716 0 129205 233396 0 119755412 111680 0 57011824 0 123326 232678 0 119324120 110720 0 56231028 0 123968 231795 0 118987824 108736 0 54822344 0 125823 232432 0 119239284 106464 0 54465220 0 127468 233480 0 119887492 112160 0 56965088 0 123223 231789 0 118927372 106816 0 53860700 0 128085 232554 0 119338852 106486 0 54217316 0 127951 232572 0 119318024 103850 0 52624736 0 131009 235524 0 120803924 117382 0 59691524 0 119868 229808 0 117925596 108954 0 55370476 0 123077 234391 0 120326912 105216 0 53702712 0 130974 230581 0 118323360 101312 0 51453796 0 131192 233676 0 119798592 105152 0 53400960 0 130652 232868 0 119469408 100992 0 51286664 0 133883 231428 0 118835932 110791 0 56069484 0 123184 234807 0 120577864 111481 0 56814212 0 125395 231241 0 118634256 107904 0 54803548 0 125396 # netstat -I cxgb1 -w 1 -d input (cxgb1) output packets errs bytes packets errs bytes colls drops 231385 0 117446044 79040 0 40151304 0 155399 231482 0 117471952 84192 0 42314876 0 150946 234274 0 118907560 82720 0 42464736 0 153623 229963 0 116715540 78656 0 39487856 0 154837 232107 0 117802152 79146 0 40233092 0 155670 231872 0 117672104 87101 0 44432220 0 147407 232063 0 117799612 80281 0 41005760 0 154019 232221 0 117875812 79574 0 40224456 0 155825 232181 0 117840252 86474 0 44109640 0 148175 233005 0 118255288 79648 0 40453056 0 155805 231327 0 117362224 84791 0 42597324 0 150323 233615 0 118578376 83305 0 42775632 0 152044 232620 0 118073932 88704 0 45054520 0 146961 231816 0 117679724 81312 0 41300908 0 153107 230951 0 117200680 85984 0 43672252 0 147643 232828 0 118150132 81984 0 41639236 0 153747 230936 0 117206776 81896 0 41540176 0 151850 232234 0 117866160 80696 0 40661844 0 154869 234465 0 119013224 90782 0 46159928 0 146240 230022 0 116739924 78224 0 39735760 0 154385 256-byte frame size: -------------------- bwm-ng v0.6 (probing every 0.500s), press 'h' for help input: getifaddrs type: rate / iface Rx Tx Total cxgb0: 516.81 Mb/s 89.50 Mb/s 606.31 Mb/s cxgb1: 510.47 Mb/s 0.00 b/s 510.47 Mb/s lo0: 0.00 b/s 0.00 b/s 0.00 b/s total: 1.00 Gb/s 89.50 Mb/s 1.09 Gb/s # netstat -I cxgb0 -w 1 -d input (cxgb0) output packets errs bytes packets errs bytes colls drops 262028 0 66449124 46674 0 11973780 0 215945 265254 0 67428648 45774 0 11543364 0 220970 263969 0 67080384 41728 0 10509156 0 224438 260856 0 66195864 48960 0 12336156 0 213067 280701 0 71610840 73376 0 18483696 0 207469 286981 0 73295964 101984 0 25687368 0 188828 291674 0 74534292 98048 0 24522624 0 197495 275561 0 70195608 64128 0 16142616 0 214413 299603 0 76662180 123520 0 31266900 0 178712 300192 0 76816656 127680 0 32177628 0 176512 301237 0 77091084 134968 0 33967584 0 170384 297626 0 76147344 127505 0 32120424 0 174518 272750 0 69459012 50775 0 12817224 0 223945 269337 0 68588604 48128 0 12125232 0 223996 272580 0 69435576 51840 0 13059396 0 223085 284996 0 72806580 88704 0 22343328 0 198919 269933 0 68693184 50304 0 12672072 0 222521 271766 0 69234984 61376 0 15460956 0 212545 279384 0 71270640 77920 0 19626768 0 204539 279604 0 71364132 80896 0 20377476 0 201143 # netstat -I cxgb1 -w 1 -d input (cxgb1) output packets errs bytes packets errs bytes colls drops 262519 0 66155544 1016 0 256032 0 264350 264428 0 66628548 2032 0 512316 0 267643 280279 0 70714980 0 0 0 0 286592 278263 0 70213248 0 0 0 0 282679 270101 0 68067468 0 0 0 0 273504 270874 0 68286708 0 0 0 0 274618 273371 0 68894280 0 0 0 0 277436 268266 0 67634532 0 0 0 0 272268 272676 0 68751144 0 0 0 0 276489 266928 0 67281984 0 0 0 0 269646 261617 0 65890692 0 0 0 0 264105 262947 0 66242484 0 0 0 0 265603 262054 0 66049956 0 0 0 0 264045 263196 0 66303720 0 0 0 0 267500 270744 0 68263020 0 0 0 0 275050 278268 0 70206444 0 0 0 0 283764 266665 0 67211676 0 0 0 0 268860 263425 0 66380076 0 0 0 0 266193 262424 0 66126060 0 0 0 0 265852 266928 0 67285512 0 0 0 0 271427 128-byte frame size: -------------------- bwm-ng v0.6 (probing every 0.500s), press 'h' for help input: getifaddrs type: rate | iface Rx Tx Total cxgb0: 253.88 Mb/s 39.65 Mb/s 293.54 Mb/s cxgb1: 251.18 Mb/s 3.79 Mb/s 254.97 Mb/s lo0: 0.00 b/s 0.00 b/s 0.00 b/s total: 505.06 Mb/s 43.44 Mb/s 548.51 Mb/s # netstat -I cxgb0 -w 1 -d input (cxgb0) output packets errs bytes packets errs bytes colls drops 272995 0 34151336 50464 0 6256048 0 222873 283224 0 35538152 71520 0 8865256 0 213793 282820 0 35460900 71680 0 8811688 0 214643 270570 0 33850884 48800 0 6041280 0 223482 268077 0 33469088 45440 0 5715780 0 225437 266423 0 33251840 52160 0 6466104 0 214914 267926 0 33494756 47680 0 5910212 0 221368 268975 0 33653476 44160 0 5474476 0 225070 273065 0 34201184 51072 0 6331936 0 223594 281093 0 35278868 70176 0 8698228 0 213052 290242 0 36473856 91424 0 11332732 0 201661 275838 0 34575664 59744 0 7405280 0 219405 271987 0 34020764 57984 0 7187412 0 216945 263805 0 32904640 50048 0 6204960 0 215690 266295 0 33242540 44192 0 5478940 0 223407 266219 0 33201992 45822 0 5629476 0 221918 264204 0 32959448 49090 0 6137256 0 214943 269254 0 33687948 43840 0 5435664 0 226363 270364 0 33849396 46016 0 5704992 0 225344 270689 0 33905196 50016 0 6199256 0 221875 # netstat -I cxgb1 -w 1 -d input (cxgb1) output packets errs bytes packets errs bytes colls drops 273869 0 33979720 0 0 0 0 278574 275475 0 34184444 0 0 0 0 280288 279181 0 34661100 0 0 0 0 284236 280953 0 34866816 0 0 0 0 286163 283458 0 35206824 0 0 0 0 289747 273164 0 33895400 0 0 0 0 277772 279365 0 34671392 0 0 0 0 283792 289865 0 35997696 0 0 0 0 296676 268840 0 33355256 0 0 0 0 273146 272989 0 33879528 0 0 0 0 277794 278536 0 34572192 0 0 0 0 283140 278738 0 34598108 0 0 0 0 284031 273043 0 33875436 0 0 0 0 277845 271792 0 33716592 0 0 0 0 275696 278252 0 34531644 0 0 0 0 283087 279277 0 34662216 0 0 0 0 284803 284664 0 35342356 0 0 0 0 291254 282126 0 35033100 0 0 0 0 288165 276860 0 34358044 0 0 0 0 281503 278605 0 34582236 0 0 0 0 284071 64-byte frame size: -------------------- bwm-ng v0.6 (probing every 0.500s), press 'h' for help input: getifaddrs type: rate - iface Rx Tx Total cxgb0: 126.25 Mb/s 37.31 Mb/s 163.56 Mb/s cxgb1: 124.84 Mb/s 6.42 Mb/s 131.26 Mb/s lo0: 0.00 b/s 0.00 b/s 0.00 b/s total: 251.09 Mb/s 43.73 Mb/s 294.82 Mb/s # netstat -I cxgb0 -w 1 -d input (cxgb0) output packets errs bytes packets errs bytes colls drops 271659 0 16462260 0 0 4754160 0 194931 288256 0 17544540 0 0 6974640 0 175370 284450 0 17308560 0 0 7179120 0 168900 278013 0 16872960 0 0 5713800 0 187902 269222 0 16316160 0 0 4139760 0 200472 277638 0 16865280 0 0 6381600 0 174917 275845 0 16747800 0 0 5573220 0 187276 270689 0 16414200 0 0 4324140 0 201575 264941 0 16023360 0 0 3646020 0 205483 274697 0 16660320 0 0 5223120 0 189366 272307 0 16506180 0 0 5105520 0 190638 272725 0 16535220 0 0 4841400 0 194902 273420 0 16582560 0 0 5320260 0 188407 272601 0 16535640 0 0 4854420 0 194869 273774 0 16602060 0 0 4998180 0 193173 274004 0 16624800 0 0 5591220 0 185281 270268 0 16377120 0 0 4653120 0 194185 270037 0 16367460 0 0 4345560 0 199280 269547 0 16324920 0 0 4917600 0 190163 272384 0 16512600 0 0 5144160 0 188393 # netstat -I cxgb1 -w 1 -d input (cxgb1) output packets errs bytes packets errs bytes colls drops 272277 0 16347120 0 0 0 0 276873 276497 0 16610580 0 0 0 0 281353 270445 0 16240320 0 0 0 0 274578 275056 0 16522080 0 0 0 0 279691 277819 0 16690500 0 0 0 0 283827 277585 0 16672740 0 0 0 0 280820 282193 0 16963740 0 0 0 0 287826 270417 0 16233420 0 0 121380 0 271558 268628 0 16127280 0 0 0 0 273754 280227 0 16836120 0 0 0 0 285798 267618 0 16059900 0 0 0 0 271038 274748 0 16502460 0 0 0 0 279588 276467 0 16606200 0 0 0 0 280183 273376 0 16416900 0 0 0 0 277882 269455 0 16176780 0 0 0 0 273417 273813 0 16442760 0 0 0 0 277677 273845 0 16445760 0 0 0 0 276387 276677 0 16621920 0 0 0 0 282040 275206 0 16532700 0 0 0 0 280072 271826 0 16327200 0 0 0 0 276746 Regards, Siquijor From eugen at kuzbass.ru Wed Feb 25 00:09:52 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Wed Feb 25 00:10:00 2009 Subject: Questions on processing smaller frame size In-Reply-To: References: Message-ID: <20090225075310.GA85904@svzserv.kemerovo.su> On Wed, Feb 25, 2009 at 03:14:11PM +0800, Siquijor Philips wrote: > Can someone explain why FreeBSD network throughput (both incoming and > outgoing traffic) decreases when smaller frame size being processed? > With smaller frame size, corresponding packet rate (packet/sec or pps) > increases and experiencing dropped packets. What causes dropping of > packets with small frame size? Traffic bandwidth does not matter (or much less), PPS rate matters. Packets drop due to high pps rate. Higher packet size, lesser pps saturates link and pps just can't grow high. It can with smaller packets. I've tried to make FreeBSD 7.1 act as packet generator with Intel dualcore 2.8Ghz processor and onboard gigabit ethernet em0 using ng_source(4) low-overhead packet emitter. And it can't saturate gigabit link with UDP packets (64 bytes payload, 130 bytes at wire - including inter-packet gaps, FCSs etc.) It takes all CPU cycles of one 2.8Ghz core to send 750Kpps - I've profiled kernel with DTrace. It seems it spends many cycles inside inlined mtx_lock/mtx_unlock functions. My em(4) driver is statically compiled into the kernel so mtx_lock/mtx_unload are inlined assembler ops. Eugene Grosbein From siquijorphilips at gmail.com Wed Feb 25 02:39:42 2009 From: siquijorphilips at gmail.com (Siquijor Philips) Date: Wed Feb 25 02:39:48 2009 Subject: Questions on processing smaller frame size In-Reply-To: <20090225075310.GA85904@svzserv.kemerovo.su> References: <20090225075310.GA85904@svzserv.kemerovo.su> Message-ID: Hello Eugene, > Traffic bandwidth does not matter (or much less), PPS rate matters. > Packets drop due to high pps rate. Higher packet size, lesser pps > saturates link and pps just can't grow high. It can with smaller packets. > All the test scenarios here are bombarded with 1-Gig of network traffic. When packet drops due to high pps rate, meaning to say that the current FreeBSD system can't still handle this kind of situation with high packet rate? Or just it depends on your hardware? I just can't imagine that with 2x quad-core system processing on high packet rate, average CPU utilization consumes a total of 98%. > I've tried to make FreeBSD 7.1 act as packet generator > with Intel dualcore 2.8Ghz processor and onboard gigabit ethernet em0 > using ng_source(4) low-overhead packet emitter. And it can't saturate > gigabit link with UDP packets (64 bytes payload, 130 bytes at wire - > including inter-packet gaps, FCSs etc.) > > It takes all CPU cycles of one 2.8Ghz core to send 750Kpps - Maybe there's a way we can optimize this, but just don't know how and what particular component to optimize? > I've profiled kernel with DTrace. It seems it spends many cycles > inside inlined mtx_lock/mtx_unlock functions. I would like to assume this is also what had happened to my Chelsio NIC. But I might be wrong here, so if someone is familiar with what's going on, then your idea is highly appreciated. I used to install Dtrace but got no luck with installation. My em(4) driver is statically > compiled into the kernel so mtx_lock/mtx_unload are inlined assembler ops. > The same is true with my cxgb(4) driver, statically compiled in the kernel. Regards, Siquijor From ivoras at freebsd.org Wed Feb 25 03:05:05 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Feb 25 03:05:12 2009 Subject: Questions on processing smaller frame size In-Reply-To: References: <20090225075310.GA85904@svzserv.kemerovo.su> Message-ID: Siquijor Philips wrote: > Hello Eugene, > >> Traffic bandwidth does not matter (or much less), PPS rate matters. >> Packets drop due to high pps rate. Higher packet size, lesser pps >> saturates link and pps just can't grow high. It can with smaller packets. >> > > All the test scenarios here are bombarded with 1-Gig of network > traffic. When packet drops due to high pps rate, meaning to say that > the current FreeBSD system can't still handle this kind of situation > with high packet rate? Not unlikely. See other similar findings by other users, usually also with em cards. > Or just it depends on your hardware? I just > can't imagine that with 2x quad-core system processing on high packet > rate, average CPU utilization consumes a total of 98%. Total = across all CPUs? Try reducing the number of CPUs, it might help by reducing contention. >> I've tried to make FreeBSD 7.1 act as packet generator >> with Intel dualcore 2.8Ghz processor and onboard gigabit ethernet em0 >> using ng_source(4) low-overhead packet emitter. And it can't saturate >> gigabit link with UDP packets (64 bytes payload, 130 bytes at wire - >> including inter-packet gaps, FCSs etc.) >> >> It takes all CPU cycles of one 2.8Ghz core to send 750Kpps - > > Maybe there's a way we can optimize this, but just don't know how and > what particular component to optimize? There is a very experimental patch to the em driver, not endorsed by the em driver author (for unknown reasons) that some users claim helps with SMP performance. See http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020441.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090225/53b3d9fc/signature.pgp From siquijorphilips at gmail.com Wed Feb 25 04:39:17 2009 From: siquijorphilips at gmail.com (Siquijor Philips) Date: Wed Feb 25 04:39:24 2009 Subject: Questions on processing smaller frame size In-Reply-To: References: <20090225075310.GA85904@svzserv.kemerovo.su> Message-ID: Hello Ivan, This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig69E41D4C44B97AD296C94242 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Siquijor Philips wrote: > Hello Eugene, >=20 >> Traffic bandwidth does not matter (or much less), PPS rate matters. >> Packets drop due to high pps rate. Higher packet size, lesser pps >> saturates link and pps just can't grow high. It can with smaller packe= ts. >> >=20 > All the test scenarios here are bombarded with 1-Gig of network > traffic. When packet drops due to high pps rate, meaning to say that > the current FreeBSD system can't still handle this kind of situation > with high packet rate?=20 > Not unlikely. See other similar findings by other users, usually also > with em cards. Ok, let me check. > Or just it depends on your hardware? I just > can't imagine that with 2x quad-core system processing on high packet > rate, average CPU utilization consumes a total of 98%. >Total across all CPUs? With 64-byte and 128-byte frame, the total average CPU utilization will vary from 92-98%. Below is one of the top output. CPU # 6,7,5,4 and 0 are in 0% idle state already. By default, Chelsio NIC were using MSI/MSI-X interrupt on multiple RX/TX queues. # top -S PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 338 root 1 -68 - 0K 16K CPU7 1 639:53 98.93% irq262: cxgbc 340 root 1 -68 - 0K 16K CPU4 0 631:19 98.19% irq264: cxgbc 337 root 1 -68 - 0K 16K CPU6 3 642:28 98.10% irq261: cxgbc 339 root 1 -68 - 0K 16K RUN 1 616:07 96.63% irq263: cxgbc 336 root 1 -68 - 0K 16K CPU3 2 621:11 90.33% irq260: cxgbc 335 root 1 -68 - 0K 16K CPU0 2 633:18 89.50% irq259: cxgbc 334 root 1 -68 - 0K 16K CPU1 3 642:27 88.87% irq258: cxgbc 333 root 1 -68 - 0K 16K CPU5 1 648:13 88.57% irq257: cxgbc 341 root 1 -83 - 0K 16K RUN 0 157:14 13.53% cxgbsp 16 root 1 171 ki31 0K 16K RUN 1 484:55 8.59% idle: cpu1 15 root 1 171 ki31 0K 16K RUN 2 483:39 7.76% idle: cpu2 14 root 1 171 ki31 0K 16K RUN 3 490:02 7.37% idle: cpu3 11 root 1 171 ki31 0K 16K RUN 6 485:50 0.00% idle: cpu6 10 root 1 171 ki31 0K 16K RUN 7 484:51 0.00% idle: cpu7 12 root 1 171 ki31 0K 16K RUN 5 475:38 0.00% idle: cpu5 13 root 1 171 ki31 0K 16K RUN 4 412:14 0.00% idle: cpu4 17 root 1 171 ki31 0K 16K RUN 0 409:06 0.00% idle: cpu0 342 root 1 -83 - 0K 16K RUN 4 155:04 0.00% cxgbsp > Try reducing the number of CPUs, it might help by reducing contention. Ok, I'll try. Regards, Siquijor --------------enig69E41D4C44B97AD296C94242 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpSIBldnAQVacBcgRAvGvAJ99YslOqGaklehf6uQjLrAEm/hJ6gCgyTUd rf3LDBNfsymm+jxbN0WHyU0= =mjmo -----END PGP SIGNATURE----- --------------enig69E41D4C44B97AD296C94242-- From root at net1.cc Wed Feb 25 10:11:39 2009 From: root at net1.cc (NetOne - Doichin Dokov) Date: Wed Feb 25 10:11:45 2009 Subject: kern/89876: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx In-Reply-To: <200902250154.n1P1sQEi063818@freefall.freebsd.org> References: <200902250154.n1P1sQEi063818@freefall.freebsd.org> Message-ID: <49A5856A.4070501@net1.cc> yongari@FreeBSD.org ??????: > Synopsis: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx > > State-Changed-From-To: feedback->patched > State-Changed-By: yongari > State-Changed-When: Wed Feb 25 01:51:48 UTC 2009 > State-Changed-Why: > Firmware image updated to the latest one. > > > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Wed Feb 25 01:51:48 UTC 2009 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=89876 > > Have you tested this on such a card, or I should go setup a test machine again with one of that? From linimon at FreeBSD.org Wed Feb 25 14:08:19 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Feb 25 14:08:31 2009 Subject: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface Message-ID: <200902252208.n1PM87mE017519@freefall.freebsd.org> Old Synopsis: carp(4) advskew setting ignored when carp IP used on a gif(4) interface New Synopsis: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Feb 25 22:07:24 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132107 From pyunyh at gmail.com Wed Feb 25 16:59:28 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Feb 25 16:59:34 2009 Subject: kern/89876: [txp] [patch] txp driver doesn't work with latest firmware 03.xxx.xxx In-Reply-To: <49A5856A.4070501@net1.cc> References: <200902250154.n1P1sQEi063818@freefall.freebsd.org> <49A5856A.4070501@net1.cc> Message-ID: <20090226003316.GA63173@michelle.cdnetworks.co.kr> On Wed, Feb 25, 2009 at 07:52:42PM +0200, NetOne - Doichin Dokov wrote: > yongari@FreeBSD.org ??????: > >Synopsis: [txp] [patch] txp driver doesn't work with latest firmware > >03.xxx.xxx > > > >State-Changed-From-To: feedback->patched > >State-Changed-By: yongari > >State-Changed-When: Wed Feb 25 01:51:48 UTC 2009 > >State-Changed-Why: > >Firmware image updated to the latest one. > > > > > >Responsible-Changed-From-To: freebsd-net->yongari > >Responsible-Changed-By: yongari > >Responsible-Changed-When: Wed Feb 25 01:51:48 UTC 2009 > >Responsible-Changed-Why: > >Grab. > > > >http://www.freebsd.org/cgi/query-pr.cgi?pr=89876 > > > > > Have you tested this on such a card, or I should go setup a test machine > again with one of that? I have tested the patch on 3CR990-TX-97 with latest NV image. The controller I have used to work with old firmware until I accidentally flashed to latest NV image, 03.001.008. Controllers that have Typhoon 1.1 or higher sleep image version no longer work with old firmware. What I'd like to know was the latest firmware can still function correctly with old NV image(e.g. Typhoon 1.0 sleep image) but no users seem to have that old controller. If you have controllers that have Typhoon 1.0 sleep image please give it a try and let me know. If new firmware is not compatible with old NV image I'll add an entry in man page so users can update to latest NV image. Note, there is no way to go back to old sleep image version if you've already flashed to latest NV image 03.001.008. From vanhu at FreeBSD.org Thu Feb 26 06:03:25 2009 From: vanhu at FreeBSD.org (VANHULLEBUS Yvan) Date: Thu Feb 26 06:03:34 2009 Subject: NATT patch and FreeBSD's setkey In-Reply-To: <20090217143409.J53478@maildrop.int.zabbadoz.net> References: <85c4b1850902170448p7a59d50bt6bdaa89aa01c51d7@mail.gmail.com> <20090217143425.GA58591@zeninc.net> <20090217143409.J53478@maildrop.int.zabbadoz.net> Message-ID: <20090226141138.GA91564@zeninc.net> On Tue, Feb 17, 2009 at 02:41:41PM +0000, Bjoern A. Zeeb wrote: [...] > I am not going to find my posting from a few years back but the > solution is to keep the kernel and libipsec (and setkey) in base in > sync and not install libipsec and setkey from the ipsec-tools port. > Done. There are two drawbacks with this solution: - It will take some regular effort to sync those version, unless we do have "some automated way to do it" (something like the mechanism used for /usr/ports ?). - if we just have a copy of sources in FreeBSD's tree, someone may commit something, then someone else (or a script) may just overwrite the changes, as it is supposed to be "just a copy". But if we can deal with those issues, of course, having the up to date versions directly shipped with FreeBSD is better ! [....] > We have about 3 months left to get that patch in for 8; ideally 6 > weeks. Can you update the nat-t patch in a way as discussed here > before so that the extra address is in etc. and we can move forward? Done, new version is available here: http://people.freebsd.org/~vanhu/NAT-T/experimental/patch-FreeBSD-TRUNK-NATT-pfkey-clean-2009-02-26.diff > I basically do not care if racoon from ipsec-tools is not going to > work for two weeks of HEAD or four as someone will quickly add a > conditional patch to the port for a __FreeBSD_version > 8xxxxx and > that can be removed once ipsec-tools properly detect the state of the > system. Things will continue working as soon as people compile without NAT-T. When compiling with NAT-T, we will need to have "old FreeBSD+patch and old ipsec-tools" or "FreeBSd with new NAT-T code and up to date (actually even not in HEAD) racoon". For people who may ask the question, when NAT-T+pfkey cleanup code will be no more experimental, I'll backport a patchset at least for FreeBSD 7.x. Yvan. From shawn at tandac.com Thu Feb 26 16:06:56 2009 From: shawn at tandac.com (Shawn Everett) Date: Thu Feb 26 16:07:03 2009 Subject: FreeBSD Router Problem In-Reply-To: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> Message-ID: <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> Sorry I meant to say FreeBSD 7.0 :) > Hi Guys, > > Here's a weird one... I set up FreeBSD 5.2 to act as a router. I used > the pf.conf script shown at: > http://www.openbsd.org/faq/pf/pools.html#outgoing > > Everything works just fine. Traffic is appropriately load balanced and > things work as expected. > > Strangely after a few hours something just stops routing traffic. I can't > ping the remote gateways either. Both external interfaces still show the > correct IP addresses. Rebooting the BSD box solves the problem. Nothing > else gets rebooted. > > Any suggestions would be appreciated. > > Shawn > From ady at freebsd.ady.ro Thu Feb 26 16:20:01 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Thu Feb 26 16:20:08 2009 Subject: FreeBSD Router Problem In-Reply-To: <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> Message-ID: <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> Hi, On Fri, Feb 27, 2009 at 1:06 AM, Shawn Everett wrote: > Sorry I meant to say FreeBSD 7.0 :) > > > Hi Guys, > > > > Here's a weird one... I set up FreeBSD 5.2 to act as a router. I used > > the pf.conf script shown at: > > http://www.openbsd.org/faq/pf/pools.html#outgoing > > > > Everything works just fine. Traffic is appropriately load balanced and > > things work as expected. > > > > Strangely after a few hours something just stops routing traffic. I > can't > > ping the remote gateways either. Both external interfaces still show the > > correct IP addresses. Rebooting the BSD box solves the problem. Nothing > > else gets rebooted. Any error messages in dmesg output ? Significant changes in "netstat -m" output before and after ? The same for "pfctl -s all" output... > > > > > Any suggestions would be appreciated. Try tcpdump'ing on the router's interfaces an on the source machine and compare the packet flows -- do the packets reach the router ? Do they attempt to pass to the outside ? Regards, Adrian. From shawn at tandac.com Thu Feb 26 16:52:31 2009 From: shawn at tandac.com (Shawn Everett) Date: Thu Feb 26 16:52:37 2009 Subject: FreeBSD Router Problem Message-ID: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> Hi Guys, Here's a weird one... I set up FreeBSD 5.2 to act as a router. I used the pf.conf script shown at: http://www.openbsd.org/faq/pf/pools.html#outgoing Everything works just fine. Traffic is appropriately load balanced and things work as expected. Strangely after a few hours something just stops routing traffic. I can't ping the remote gateways either. Both external interfaces still show the correct IP addresses. Rebooting the BSD box solves the problem. Nothing else gets rebooted. Any suggestions would be appreciated. Shawn From cswiger at mac.com Thu Feb 26 18:00:04 2009 From: cswiger at mac.com (Chuck Swiger) Date: Thu Feb 26 18:00:11 2009 Subject: FreeBSD Router Problem In-Reply-To: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> Message-ID: <75910EA0-9E49-4FA1-A9BA-A4D2A6CB7E0C@mac.com> On Feb 26, 2009, at 3:43 PM, Shawn Everett wrote: > Here's a weird one... I set up FreeBSD 5.2 to act as a router. [ ... ] > > Any suggestions would be appreciated. Try upgrading to a supported version of the OS, first, then work on debugging any deadlocks if they still reoccur. Early 5.x versions were a little rocky. I seem to recall that 5.2 would experience deadlocks against ATA harddrives that would cause a system lockup, and that a errata release (5.2.1) was quickly put out to help fix those issues. 6.4 is much more stable by comparison... Regards, -- -Chuck From spawk at acm.poly.edu Thu Feb 26 20:40:03 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Thu Feb 26 20:40:09 2009 Subject: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Message-ID: <200902270440.n1R4e2AB043773@freefall.freebsd.org> The following reply was made to PR kern/129508; it has been noted by GNATS. From: Boris Kochergin To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Date: Thu, 26 Feb 2009 23:34:06 -0500 For anyone who was unenthusiastic about this due to the infrequency of the problem, this has become less of a debugging nightmare. Due to increased network load, the panic occurs about once a day, on average, now with 7.1-RELEASE-p2. From siquijorphilips at gmail.com Thu Feb 26 21:56:43 2009 From: siquijorphilips at gmail.com (Siquijor Philips) Date: Thu Feb 26 21:56:50 2009 Subject: Questions on processing smaller frame size In-Reply-To: References: <20090225075310.GA85904@svzserv.kemerovo.su> Message-ID: Hello Ivan, >> Try reducing the number of CPUs, it might help by reducing contention. > > Ok, I'll try. > I have tested reducing the number of CPUs but it was helpless because it causes my system to hang. Regards, Siquijor From brett at lariat.net Thu Feb 26 22:10:21 2009 From: brett at lariat.net (Brett Glass) Date: Thu Feb 26 22:10:37 2009 Subject: Recommended additions to ipfw command: increment and verbosity limit Message-ID: <200902270541.WAA01313@lariat.net> Everyone: Reviewing the latest man page for ipfw(8), I see that the only way to change the automatic increment for rules is still to set a sysctl variable (net.inet.ip.fw.autoinc_step). This was once also the case for "one pass" behavior (net.inet.ip.fw.one_pass) as well as verbose logging, debugging messages, and the global enable bit for the entire firewall. However various "ipfw enable" and "ipfw disable" subcommands were added over time to eliminate the need to set arcane sysctl variables. The only two commonly used parameters that are still not settable from the ipfw(8) command seem to be autoinc_step and verbose_limit. (autoinc_step has to be in the range 1..1000, while verbose_limit seems to be able to take any unsigned integer value.) I'd like to recommend that subcommands be added to set them, not only for the sake of consistency but to make it unnecessary to circumvent the ipfw command to configure one's firewall. The sysctl variables could remain to provide backward compatibility and to satisfy the Principle of Least Astonishment. Comments? Should I submit code? (Anyone qualified to be a committer should be able to make the changes by copying an editing a few lines, but...) --Brett Glass From sepherosa at gmail.com Thu Feb 26 22:19:57 2009 From: sepherosa at gmail.com (Sepherosa Ziehau) Date: Thu Feb 26 22:20:03 2009 Subject: Questions on processing smaller frame size In-Reply-To: References: <20090225075310.GA85904@svzserv.kemerovo.su> Message-ID: On Wed, Feb 25, 2009 at 6:48 PM, Ivan Voras wrote: > > There is a very experimental patch to the em driver, not endorsed by the > em driver author (for unknown reasons) that some users claim helps with > SMP performance. See > http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020441.html > What's the interrupt rate of the above driver if you do: netperf -H remote-ip -t UDP_STREAM -l 60 -- -m 1472 Anyone has tried it? Best Regards, sephe -- Live Free or Die From shawn at tandac.com Thu Feb 26 23:41:51 2009 From: shawn at tandac.com (Shawn Everett) Date: Thu Feb 26 23:41:58 2009 Subject: FreeBSD Router Problem In-Reply-To: <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> Message-ID: <200902262341.35069.shawn@tandac.com> > Any error messages in dmesg output ? > Significant changes in "netstat -m" output before and after ? > The same for "pfctl -s all" output... The box has been up for about 12 hours now. As a point of discussion here is the output from netstat and pfctl in case anything obvious jumps out. 385/905/1290 mbufs in use (current/cache/total) 384/484/868/25600 mbuf clusters in use (current/cache/total/max) 256/384 mbuf+clusters out of packet secondary zone in use (current/cache) 0/44/44/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 864K/1370K/2234K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/5/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines # pfctl -s all No ALTQ support in kernel ALTQ related functions disabled TRANSLATION RULES: nat on ste0 inet from 172.16.3.0/24 to any -> (ste0) round-robin nat on ste1 inet from 172.16.3.0/24 to any -> (ste1) round-robin FILTER RULES: pass out on em0 inet from any to 172.16.3.0/24 flags S/SA keep state pass in quick on em0 inet from 172.16.3.0/24 to 172.16.3.253 flags S/SA keep state pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } round-robin inet proto tcp from 172.16.3.0/24 to any flags S/SA modulate state pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } round-robin inet proto udp from 172.16.3.0/24 to any keep state pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } round-robin inet proto icmp from 172.16.3.0/24 to any keep state pass out on ste0 proto tcp all flags S/SA modulate state pass out on ste0 proto udp all keep state pass out on ste0 proto icmp all keep state pass out on ste1 proto tcp all flags S/SA modulate state pass out on ste1 proto udp all keep state pass out on ste1 proto icmp all keep state pass out on ste0 route-to (ste1 204.244.159.254) inet from 204.244.159.55 to any flags S/SA keep state pass out on ste1 route-to (ste0 204.244.159.254) inet from 204.244.159.68 to any flags S/SA keep state STATES: all udp 172.16.3.255:137 <- 172.16.3.17:137 NO_TRAFFIC:SINGLE all udp 172.16.3.17:137 -> 204.244.159.68:57827 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC all tcp 10.170.54.1:81 <- 172.16.3.71:3064 CLOSED:SYN_SENT all tcp 172.16.3.71:3064 -> 204.244.159.55:56563 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.30:2021 CLOSED:SYN_SENT all tcp 172.16.3.30:2021 -> 204.244.159.68:54557 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.72:1414 CLOSED:SYN_SENT all tcp 172.16.3.72:1414 -> 204.244.159.55:52567 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.31:2865 CLOSED:SYN_SENT all tcp 172.16.3.31:2865 -> 204.244.159.68:59429 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.72:1415 CLOSED:SYN_SENT all tcp 172.16.3.72:1415 -> 204.244.159.55:61425 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.49:1914 CLOSED:SYN_SENT all tcp 172.16.3.49:1914 -> 204.244.159.68:58532 -> 10.170.54.1:81 SYN_SENT:CLOSED all udp 172.16.3.255:138 <- 172.16.3.39:138 NO_TRAFFIC:SINGLE all udp 172.16.3.39:138 -> 204.244.159.68:62224 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC all tcp 64.56.145.72:110 <- 172.16.3.48:1494 FIN_WAIT_2:FIN_WAIT_2 all tcp 172.16.3.48:1494 -> 204.244.159.55:62928 -> 64.56.145.72:110 FIN_WAIT_2:FIN_WAIT_2 all udp 172.16.3.255:137 <- 172.16.3.49:137 NO_TRAFFIC:SINGLE all udp 172.16.3.49:137 -> 204.244.159.55:61053 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC all tcp 10.170.54.1:81 <- 172.16.3.37:1508 CLOSED:SYN_SENT all tcp 172.16.3.37:1508 -> 204.244.159.68:54656 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.74:3126 CLOSED:SYN_SENT all tcp 172.16.3.74:3126 -> 204.244.159.55:61282 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.18:2446 CLOSED:SYN_SENT all tcp 172.16.3.18:2446 -> 204.244.159.68:58385 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.73:2057 CLOSED:SYN_SENT all tcp 172.16.3.73:2057 -> 204.244.159.55:61692 -> 10.170.54.1:81 SYN_SENT:CLOSED all udp 198.208.22.27:53 <- 172.16.3.74:58071 SINGLE:MULTIPLE all udp 172.16.3.74:58071 -> 204.244.159.68:54669 -> 198.208.22.27:53 MULTIPLE:SINGLE all udp 198.208.22.27:53 <- 172.16.3.74:57503 SINGLE:MULTIPLE all udp 172.16.3.74:57503 -> 204.244.159.55:64923 -> 198.208.22.27:53 MULTIPLE:SINGLE all udp 198.208.22.27:53 <- 172.16.3.74:51153 SINGLE:MULTIPLE all udp 172.16.3.74:51153 -> 204.244.159.68:61637 -> 198.208.22.27:53 MULTIPLE:SINGLE all udp 172.16.3.255:137 <- 172.16.3.74:137 NO_TRAFFIC:SINGLE all udp 172.16.3.74:137 -> 204.244.159.55:53474 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC all tcp 10.170.54.1:81 <- 172.16.3.71:3065 CLOSED:SYN_SENT all tcp 172.16.3.71:3065 -> 204.244.159.68:63354 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.29:4434 CLOSED:SYN_SENT all tcp 172.16.3.29:4434 -> 204.244.159.55:62977 -> 10.170.54.1:81 SYN_SENT:CLOSED all udp 172.16.3.255:137 <- 172.16.3.30:137 NO_TRAFFIC:SINGLE all udp 172.16.3.30:137 -> 204.244.159.68:61298 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC all tcp 63.241.234.60:443 <- 172.16.3.37:1509 ESTABLISHED:ESTABLISHED all tcp 172.16.3.37:1509 -> 204.244.159.68:61873 -> 63.241.234.60:443 ESTABLISHED:ESTABLISHED all udp 198.208.22.27:53 <- 172.16.3.72:59314 SINGLE:MULTIPLE all udp 172.16.3.72:59314 -> 204.244.159.55:62186 -> 198.208.22.27:53 MULTIPLE:SINGLE all udp 198.208.22.27:53 <- 172.16.3.72:55934 SINGLE:MULTIPLE all udp 172.16.3.72:55934 -> 204.244.159.68:51479 -> 198.208.22.27:53 MULTIPLE:SINGLE all udp 198.208.22.27:53 <- 172.16.3.72:52983 SINGLE:MULTIPLE all udp 172.16.3.72:52983 -> 204.244.159.55:55523 -> 198.208.22.27:53 MULTIPLE:SINGLE all udp 172.16.3.255:137 <- 172.16.3.72:137 NO_TRAFFIC:SINGLE all udp 172.16.3.72:137 -> 204.244.159.68:58218 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC all tcp 10.170.54.1:81 <- 172.16.3.31:2868 CLOSED:SYN_SENT all tcp 172.16.3.31:2868 -> 204.244.159.55:60911 -> 10.170.54.1:81 SYN_SENT:CLOSED all udp 172.16.3.255:137 <- 172.16.3.77:137 NO_TRAFFIC:SINGLE all udp 172.16.3.77:137 -> 204.244.159.55:59287 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC all tcp 10.170.54.1:81 <- 172.16.3.72:1416 CLOSED:SYN_SENT all tcp 172.16.3.72:1416 -> 204.244.159.68:59828 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.49:1915 CLOSED:SYN_SENT all tcp 172.16.3.49:1915 -> 204.244.159.55:64580 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.29:4435 CLOSED:SYN_SENT all tcp 172.16.3.29:4435 -> 204.244.159.68:60089 -> 10.170.54.1:81 SYN_SENT:CLOSED all udp 172.16.3.255:137 <- 172.16.3.8:137 NO_TRAFFIC:SINGLE all udp 172.16.3.8:137 -> 204.244.159.68:60176 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC all tcp 10.170.54.1:81 <- 172.16.3.51:3433 CLOSED:SYN_SENT all tcp 172.16.3.51:3433 -> 204.244.159.55:63158 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.37:1510 CLOSED:SYN_SENT all tcp 172.16.3.37:1510 -> 204.244.159.68:63197 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.74:3127 CLOSED:SYN_SENT all tcp 172.16.3.74:3127 -> 204.244.159.55:61760 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.18:2447 CLOSED:SYN_SENT all tcp 172.16.3.18:2447 -> 204.244.159.68:61951 -> 10.170.54.1:81 SYN_SENT:CLOSED all tcp 10.170.54.1:81 <- 172.16.3.73:2058 CLOSED:SYN_SENT all tcp 172.16.3.73:2058 -> 204.244.159.55:53396 -> 10.170.54.1:81 SYN_SENT:CLOSED all udp 198.208.22.27:53 <- 172.16.3.74:62024 SINGLE:MULTIPLE all udp 172.16.3.74:62024 -> 204.244.159.55:63136 -> 198.208.22.27:53 MULTIPLE:SINGLE all tcp 72.14.162.41:80 <- 172.16.3.74:3128 TIME_WAIT:TIME_WAIT all tcp 172.16.3.74:3128 -> 204.244.159.68:58088 -> 72.14.162.41:80 TIME_WAIT:TIME_WAIT all tcp 72.14.162.41:80 <- 172.16.3.74:3129 FIN_WAIT_2:FIN_WAIT_2 all tcp 172.16.3.74:3129 -> 204.244.159.55:62718 -> 72.14.162.41:80 FIN_WAIT_2:FIN_WAIT_2 all udp 172.16.3.255:138 <- 172.16.3.71:138 NO_TRAFFIC:SINGLE all udp 172.16.3.71:138 -> 204.244.159.68:52993 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC all tcp 10.170.54.1:81 <- 172.16.3.71:3066 CLOSED:SYN_SENT all tcp 172.16.3.71:3066 -> 204.244.159.68:50898 -> 10.170.54.1:81 SYN_SENT:CLOSED INFO: Status: Enabled for 0 days 11:42:09 Debug: Urgent State Table Total Rate current entries 84 searches 4907040 116.5/s inserts 131271 3.1/s removals 131187 3.1/s Counters match 157214 3.7/s bad-offset 0 0.0/s fragment 0 0.0/s short 40 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 2 0.0/s state-mismatch 215 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 6000 states adaptive.end 12000 states src.track 0s LIMITS: states hard limit 10000 src-nodes hard limit 10000 frags hard limit 5000 tables hard limit 1000 table-entries hard limit 200000 TABLES: OS FINGERPRINTS: 696 fingerprints loaded From ady at freebsd.ady.ro Thu Feb 26 23:54:27 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Thu Feb 26 23:54:34 2009 Subject: FreeBSD Router Problem In-Reply-To: <200902262341.35069.shawn@tandac.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <3853.206.108.16.89.1235693214.squirrel@alder.hosix.com> <78cb3d3f0902261619t71a054fet43779c37e2981603@mail.gmail.com> <200902262341.35069.shawn@tandac.com> Message-ID: <78cb3d3f0902262354j6c22b43do565b75523a8007e3@mail.gmail.com> Hi, On Fri, Feb 27, 2009 at 8:41 AM, Shawn Everett wrote: > > Any error messages in dmesg output ? > > Significant changes in "netstat -m" output before and after ? > > The same for "pfctl -s all" output... > > The box has been up for about 12 hours now. As a point of discussion here > is the output from netstat and pfctl in case anything obvious jumps out. > > 385/905/1290 mbufs in use (current/cache/total) > 384/484/868/25600 mbuf clusters in use (current/cache/total/max) > 256/384 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/44/44/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 864K/1370K/2234K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/5/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > This looks OK to me... > > > # pfctl -s all > No ALTQ support in kernel > ALTQ related functions disabled > TRANSLATION RULES: > nat on ste0 inet from 172.16.3.0/24 to any -> (ste0) round-robin > nat on ste1 inet from 172.16.3.0/24 to any -> (ste1) round-robin > > FILTER RULES: > pass out on em0 inet from any to 172.16.3.0/24 flags S/SA keep state > pass in quick on em0 inet from 172.16.3.0/24 to 172.16.3.253 flags S/SA > keep state > pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } > round-robin inet proto tcp from 172.16.3.0/24 to any flags S/SA modulate > state > pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } > round-robin inet proto udp from 172.16.3.0/24 to any keep state > pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } > round-robin inet proto icmp from 172.16.3.0/24 to any keep state > pass out on ste0 proto tcp all flags S/SA modulate state > pass out on ste0 proto udp all keep state > pass out on ste0 proto icmp all keep state > pass out on ste1 proto tcp all flags S/SA modulate state > pass out on ste1 proto udp all keep state > pass out on ste1 proto icmp all keep state > pass out on ste0 route-to (ste1 204.244.159.254) inet from 204.244.159.55 > to any flags S/SA keep state > pass out on ste1 route-to (ste0 204.244.159.254) inet from 204.244.159.68 > to any flags S/SA keep state > Quite an evolved route forwarding setup ;)... > > STATES: > all udp 172.16.3.255:137 <- 172.16.3.17:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.17:137 -> 204.244.159.68:57827 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.71:3064 CLOSED:SYN_SENT > all tcp 172.16.3.71:3064 -> 204.244.159.55:56563 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.30:2021 CLOSED:SYN_SENT > all tcp 172.16.3.30:2021 -> 204.244.159.68:54557 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.72:1414 CLOSED:SYN_SENT > all tcp 172.16.3.72:1414 -> 204.244.159.55:52567 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.31:2865 CLOSED:SYN_SENT > all tcp 172.16.3.31:2865 -> 204.244.159.68:59429 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.72:1415 CLOSED:SYN_SENT > all tcp 172.16.3.72:1415 -> 204.244.159.55:61425 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.49:1914 CLOSED:SYN_SENT > all tcp 172.16.3.49:1914 -> 204.244.159.68:58532 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 172.16.3.255:138 <- 172.16.3.39:138 NO_TRAFFIC:SINGLE > all udp 172.16.3.39:138 -> 204.244.159.68:62224 -> 172.16.3.255:138 > SINGLE:NO_TRAFFIC > all tcp 64.56.145.72:110 <- 172.16.3.48:1494 FIN_WAIT_2:FIN_WAIT_2 > all tcp 172.16.3.48:1494 -> 204.244.159.55:62928 -> 64.56.145.72:110 > FIN_WAIT_2:FIN_WAIT_2 > all udp 172.16.3.255:137 <- 172.16.3.49:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.49:137 -> 204.244.159.55:61053 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.37:1508 CLOSED:SYN_SENT > all tcp 172.16.3.37:1508 -> 204.244.159.68:54656 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.74:3126 CLOSED:SYN_SENT > all tcp 172.16.3.74:3126 -> 204.244.159.55:61282 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.18:2446 CLOSED:SYN_SENT > all tcp 172.16.3.18:2446 -> 204.244.159.68:58385 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.73:2057 CLOSED:SYN_SENT > all tcp 172.16.3.73:2057 -> 204.244.159.55:61692 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 198.208.22.27:53 <- 172.16.3.74:58071 SINGLE:MULTIPLE > all udp 172.16.3.74:58071 -> 204.244.159.68:54669 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 198.208.22.27:53 <- 172.16.3.74:57503 SINGLE:MULTIPLE > all udp 172.16.3.74:57503 -> 204.244.159.55:64923 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 198.208.22.27:53 <- 172.16.3.74:51153 SINGLE:MULTIPLE > all udp 172.16.3.74:51153 -> 204.244.159.68:61637 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 172.16.3.255:137 <- 172.16.3.74:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.74:137 -> 204.244.159.55:53474 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.71:3065 CLOSED:SYN_SENT > all tcp 172.16.3.71:3065 -> 204.244.159.68:63354 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.29:4434 CLOSED:SYN_SENT > all tcp 172.16.3.29:4434 -> 204.244.159.55:62977 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 172.16.3.255:137 <- 172.16.3.30:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.30:137 -> 204.244.159.68:61298 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 63.241.234.60:443 <- 172.16.3.37:1509 > ESTABLISHED:ESTABLISHED > all tcp 172.16.3.37:1509 -> 204.244.159.68:61873 -> 63.241.234.60:443 > ESTABLISHED:ESTABLISHED > all udp 198.208.22.27:53 <- 172.16.3.72:59314 SINGLE:MULTIPLE > all udp 172.16.3.72:59314 -> 204.244.159.55:62186 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 198.208.22.27:53 <- 172.16.3.72:55934 SINGLE:MULTIPLE > all udp 172.16.3.72:55934 -> 204.244.159.68:51479 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 198.208.22.27:53 <- 172.16.3.72:52983 SINGLE:MULTIPLE > all udp 172.16.3.72:52983 -> 204.244.159.55:55523 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all udp 172.16.3.255:137 <- 172.16.3.72:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.72:137 -> 204.244.159.68:58218 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.31:2868 CLOSED:SYN_SENT > all tcp 172.16.3.31:2868 -> 204.244.159.55:60911 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 172.16.3.255:137 <- 172.16.3.77:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.77:137 -> 204.244.159.55:59287 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.72:1416 CLOSED:SYN_SENT > all tcp 172.16.3.72:1416 -> 204.244.159.68:59828 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.49:1915 CLOSED:SYN_SENT > all tcp 172.16.3.49:1915 -> 204.244.159.55:64580 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.29:4435 CLOSED:SYN_SENT > all tcp 172.16.3.29:4435 -> 204.244.159.68:60089 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 172.16.3.255:137 <- 172.16.3.8:137 NO_TRAFFIC:SINGLE > all udp 172.16.3.8:137 -> 204.244.159.68:60176 -> 172.16.3.255:137 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.51:3433 CLOSED:SYN_SENT > all tcp 172.16.3.51:3433 -> 204.244.159.55:63158 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.37:1510 CLOSED:SYN_SENT > all tcp 172.16.3.37:1510 -> 204.244.159.68:63197 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.74:3127 CLOSED:SYN_SENT > all tcp 172.16.3.74:3127 -> 204.244.159.55:61760 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.18:2447 CLOSED:SYN_SENT > all tcp 172.16.3.18:2447 -> 204.244.159.68:61951 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all tcp 10.170.54.1:81 <- 172.16.3.73:2058 CLOSED:SYN_SENT > all tcp 172.16.3.73:2058 -> 204.244.159.55:53396 -> 10.170.54.1:81 > SYN_SENT:CLOSED > all udp 198.208.22.27:53 <- 172.16.3.74:62024 SINGLE:MULTIPLE > all udp 172.16.3.74:62024 -> 204.244.159.55:63136 -> 198.208.22.27:53 > MULTIPLE:SINGLE > all tcp 72.14.162.41:80 <- 172.16.3.74:3128 TIME_WAIT:TIME_WAIT > all tcp 172.16.3.74:3128 -> 204.244.159.68:58088 -> 72.14.162.41:80 > TIME_WAIT:TIME_WAIT > all tcp 72.14.162.41:80 <- 172.16.3.74:3129 FIN_WAIT_2:FIN_WAIT_2 > all tcp 172.16.3.74:3129 -> 204.244.159.55:62718 -> 72.14.162.41:80 > FIN_WAIT_2:FIN_WAIT_2 > all udp 172.16.3.255:138 <- 172.16.3.71:138 NO_TRAFFIC:SINGLE > all udp 172.16.3.71:138 -> 204.244.159.68:52993 -> 172.16.3.255:138 > SINGLE:NO_TRAFFIC > all tcp 10.170.54.1:81 <- 172.16.3.71:3066 CLOSED:SYN_SENT > all tcp 172.16.3.71:3066 -> 204.244.159.68:50898 -> 10.170.54.1:81 > SYN_SENT:CLOSED > Ooops, all TCP states are closed/dead ? No new TCP flows registered ? You better check with "pfctl -v -s state" what's going on there, what's the aging and expiring times... Regards, Adrian. From shawn at tandac.com Fri Feb 27 00:04:28 2009 From: shawn at tandac.com (Shawn Everett) Date: Fri Feb 27 00:04:36 2009 Subject: FreeBSD Router Problem In-Reply-To: <78cb3d3f0902262354j6c22b43do565b75523a8007e3@mail.gmail.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <200902262341.35069.shawn@tandac.com> <78cb3d3f0902262354j6c22b43do565b75523a8007e3@mail.gmail.com> Message-ID: <200902270004.24158.shawn@tandac.com> On Thursday 26 February 2009, Adrian Penisoara wrote: > pfctl -v -s state It's midnight here. There should be very little active traffic from workstations at this hour. I was just about to head off to bed. #pfctl -v -s state No ALTQ support in kernel ALTQ related functions disabled all tcp 63.241.234.60:443 <- 172.16.3.37:1552 TIME_WAIT:TIME_WAIT [2809190277 + 65535](+6632) [136754641 + 6215](+2672421819) age 00:02:53, expires in 00:00:46, 7:6 pkts, 2447:2108 bytes, rule 2 all tcp 172.16.3.37:1552 -> 204.244.159.68:57351 -> 63.241.234.60:443 TIME_WAIT:TIME_WAIT [2809176460 + 6215](+8057) [2245260981 + 65535](+563929296) age 00:02:53, expires in 00:00:46, 7:6 pkts, 2447:2108 bytes, rule 5 all udp 172.16.3.255:138 <- 172.16.3.29:138 NO_TRAFFIC:SINGLE age 00:00:58, expires in 00:00:02, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.29:138 -> 204.244.159.55:62508 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:58, expires in 00:00:02, 1:0 pkts, 229:0 bytes, rule 9 all udp 172.16.3.255:138 <- 172.16.3.38:138 NO_TRAFFIC:SINGLE age 00:00:54, expires in 00:00:06, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.38:138 -> 204.244.159.68:59414 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:54, expires in 00:00:06, 1:0 pkts, 229:0 bytes, rule 6 all udp 172.16.3.255:138 <- 172.16.3.46:138 NO_TRAFFIC:SINGLE age 00:00:52, expires in 00:00:08, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.46:138 -> 204.244.159.55:61107 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:52, expires in 00:00:08, 1:0 pkts, 229:0 bytes, rule 9 all udp 172.16.3.255:138 <- 172.16.3.73:138 NO_TRAFFIC:SINGLE age 00:00:50, expires in 00:00:10, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.73:138 -> 204.244.159.68:57339 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:50, expires in 00:00:10, 1:0 pkts, 229:0 bytes, rule 6 all tcp 10.170.54.1:81 <- 172.16.3.31:2907 CLOSED:SYN_SENT [0 + 65535] [2039994755 + 1](+3336367162) age 00:00:47, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.31:2907 -> 204.244.159.68:51242 -> 10.170.54.1:81 SYN_SENT:CLOSED [1081394621 + 1](+4585) [0 + 65535] age 00:00:47, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 5 all tcp 10.170.54.1:81 <- 172.16.3.54:2973 CLOSED:SYN_SENT [0 + 65535] [1169394795 + 1](+3127556057) age 00:00:46, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.54:2973 -> 204.244.159.55:60178 -> 10.170.54.1:81 SYN_SENT:CLOSED [1983556 + 1](+5275) [0 + 65535] age 00:00:46, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 8 all udp 172.16.3.255:138 <- 172.16.3.72:138 NO_TRAFFIC:SINGLE age 00:00:45, expires in 00:00:15, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.72:138 -> 204.244.159.55:62034 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:45, expires in 00:00:15, 1:0 pkts, 229:0 bytes, rule 9 all udp 172.16.3.255:138 <- 172.16.3.57:138 NO_TRAFFIC:SINGLE age 00:00:45, expires in 00:00:15, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.57:138 -> 204.244.159.68:58279 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:45, expires in 00:00:15, 1:0 pkts, 229:0 bytes, rule 6 all tcp 10.170.54.1:81 <- 172.16.3.49:1947 CLOSED:SYN_SENT [0 + 65535] [3216417449 + 1](+2374568959) age 00:00:44, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.49:1947 -> 204.244.159.68:52981 -> 10.170.54.1:81 SYN_SENT:CLOSED [1296019112 + 1](+4299) [0 + 65535] age 00:00:44, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 5 all tcp 10.170.54.1:81 <- 172.16.3.31:2908 CLOSED:SYN_SENT [0 + 65535] [344188291 + 1](+3105844931) age 00:00:43, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.31:2908 -> 204.244.159.55:61404 -> 10.170.54.1:81 SYN_SENT:CLOSED [3450033222 + 1](+5488) [0 + 65535] age 00:00:43, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 8 all tcp 10.170.54.1:81 <- 172.16.3.30:2063 CLOSED:SYN_SENT [0 + 65535] [459132347 + 1](+1172967503) age 00:00:43, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.30:2063 -> 204.244.159.68:61029 -> 10.170.54.1:81 SYN_SENT:CLOSED [1632099850 + 1](+4578) [0 + 65535] age 00:00:43, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 5 all udp 172.16.3.255:138 <- 172.16.3.37:138 NO_TRAFFIC:SINGLE age 00:00:40, expires in 00:00:20, 1:0 pkts, 242:0 bytes, rule 3 all udp 172.16.3.37:138 -> 204.244.159.55:55472 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:40, expires in 00:00:20, 1:0 pkts, 242:0 bytes, rule 9 all udp 172.16.3.255:138 <- 172.16.3.49:138 NO_TRAFFIC:SINGLE age 00:00:39, expires in 00:00:21, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.49:138 -> 204.244.159.68:55551 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:39, expires in 00:00:21, 1:0 pkts, 229:0 bytes, rule 6 all tcp 10.170.54.1:81 <- 172.16.3.51:3475 CLOSED:SYN_SENT [0 + 65535] [1186661975 + 1](+472867228) age 00:00:39, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.51:3475 -> 204.244.159.55:63438 -> 10.170.54.1:81 SYN_SENT:CLOSED [1659529203 + 1](+5514) [0 + 65535] age 00:00:39, expires in 00:00:00, 3:0 pkts, 144:0 bytes, rule 8 all udp 172.16.3.255:137 <- 172.16.3.76:137 NO_TRAFFIC:SINGLE age 00:00:37, expires in 00:00:00, 3:0 pkts, 234:0 bytes, rule 3 all udp 172.16.3.76:137 -> 204.244.159.55:59226 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC age 00:00:37, expires in 00:00:00, 3:0 pkts, 234:0 bytes, rule 9 all tcp 10.170.54.1:81 <- 172.16.3.46:1807 CLOSED:SYN_SENT [0 + 65535] [59677193 + 1](+3666664406) age 00:00:35, expires in 00:00:04, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.46:1807 -> 204.244.159.68:55544 -> 10.170.54.1:81 SYN_SENT:CLOSED [3726341599 + 1](+7061) [0 + 65535] age 00:00:35, expires in 00:00:04, 3:0 pkts, 144:0 bytes, rule 5 all udp 172.16.3.255:138 <- 172.16.3.8:138 NO_TRAFFIC:SINGLE age 00:00:27, expires in 00:00:33, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.8:138 -> 204.244.159.68:65532 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:27, expires in 00:00:33, 1:0 pkts, 229:0 bytes, rule 6 all tcp 10.170.54.1:81 <- 172.16.3.31:2909 CLOSED:SYN_SENT [0 + 65535] [778012129 + 1](+2120103351) age 00:00:26, expires in 00:00:13, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.31:2909 -> 204.244.159.55:61987 -> 10.170.54.1:81 SYN_SENT:CLOSED [2898115480 + 1](+6268) [0 + 65535] age 00:00:26, expires in 00:00:13, 3:0 pkts, 144:0 bytes, rule 8 all udp 172.16.3.255:138 <- 172.16.3.21:138 NO_TRAFFIC:SINGLE age 00:00:26, expires in 00:00:34, 1:0 pkts, 242:0 bytes, rule 3 all udp 172.16.3.21:138 -> 204.244.159.55:51353 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:26, expires in 00:00:34, 1:0 pkts, 242:0 bytes, rule 9 all tcp 10.170.54.1:81 <- 172.16.3.54:2974 CLOSED:SYN_SENT [0 + 65535] [569329580 + 1](+583400938) age 00:00:25, expires in 00:00:14, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.54:2974 -> 204.244.159.68:62558 -> 10.170.54.1:81 SYN_SENT:CLOSED [1152730518 + 1](+5061) [0 + 65535] age 00:00:25, expires in 00:00:14, 3:0 pkts, 144:0 bytes, rule 5 all udp 172.16.3.255:137 <- 172.16.3.22:137 NO_TRAFFIC:SINGLE age 00:00:23, expires in 00:00:37, 1:0 pkts, 78:0 bytes, rule 3 all udp 172.16.3.22:137 -> 204.244.159.68:54497 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC age 00:00:23, expires in 00:00:37, 1:0 pkts, 78:0 bytes, rule 6 all tcp 10.170.54.1:81 <- 172.16.3.49:1948 CLOSED:SYN_SENT [0 + 65535] [2509322408 + 1](+3813371212) age 00:00:23, expires in 00:00:16, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.49:1948 -> 204.244.159.55:56965 -> 10.170.54.1:81 SYN_SENT:CLOSED [2027726324 + 1](+7437) [0 + 65535] age 00:00:23, expires in 00:00:16, 3:0 pkts, 144:0 bytes, rule 8 all udp 172.16.3.255:137 <- 172.16.3.31:137 NO_TRAFFIC:SINGLE age 00:00:22, expires in 00:00:10, 3:0 pkts, 234:0 bytes, rule 3 all udp 172.16.3.31:137 -> 204.244.159.55:65154 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC age 00:00:22, expires in 00:00:10, 3:0 pkts, 234:0 bytes, rule 9 all udp 172.16.3.255:138 <- 172.16.3.36:138 NO_TRAFFIC:SINGLE age 00:00:21, expires in 00:00:39, 1:0 pkts, 229:0 bytes, rule 3 all udp 172.16.3.36:138 -> 204.244.159.68:53322 -> 172.16.3.255:138 SINGLE:NO_TRAFFIC age 00:00:21, expires in 00:00:39, 1:0 pkts, 229:0 bytes, rule 6 all tcp 10.170.54.1:81 <- 172.16.3.30:2064 CLOSED:SYN_SENT [0 + 65535] [746240695 + 1](+1233058940) age 00:00:20, expires in 00:00:19, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.30:2064 -> 204.244.159.68:51143 -> 10.170.54.1:81 SYN_SENT:CLOSED [1979299635 + 1](+6018) [0 + 65535] age 00:00:20, expires in 00:00:19, 3:0 pkts, 144:0 bytes, rule 5 all tcp 64.56.145.72:110 <- 172.16.3.62:3575 FIN_WAIT_2:FIN_WAIT_2 [3781047388 + 65465](+7582) [1715565868 + 5840](+2065472307) age 00:00:19, expires in 00:01:12, 8:9 pkts, 384:438 bytes, rule 2 all tcp 172.16.3.62:3575 -> 204.244.159.55:55043 -> 64.56.145.72:110 FIN_WAIT_2:FIN_WAIT_2 [3781038175 + 5840](+4881) [2842714655 + 65465](+938332733) age 00:00:19, expires in 00:01:12, 8:9 pkts, 384:438 bytes, rule 8 all tcp 10.170.54.1:81 <- 172.16.3.51:3476 CLOSED:SYN_SENT [0 + 65535] [784236726 + 1](+4187310284) age 00:00:17, expires in 00:00:22, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.51:3476 -> 204.244.159.68:57484 -> 10.170.54.1:81 SYN_SENT:CLOSED [676579714 + 1](+7199) [0 + 65535] age 00:00:17, expires in 00:00:22, 3:0 pkts, 144:0 bytes, rule 5 all tcp 10.170.54.1:81 <- 172.16.3.17:4335 CLOSED:SYN_SENT [0 + 65535] [1816039899 + 1](+1408229979) age 00:00:17, expires in 00:00:22, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.17:4335 -> 204.244.159.55:50224 -> 10.170.54.1:81 SYN_SENT:CLOSED [3224269878 + 1](+5331) [0 + 65535] age 00:00:17, expires in 00:00:22, 3:0 pkts, 144:0 bytes, rule 8 all udp 172.16.3.255:137 <- 172.16.3.46:137 NO_TRAFFIC:SINGLE age 00:00:14, expires in 00:00:17, 3:0 pkts, 234:0 bytes, rule 3 all udp 172.16.3.46:137 -> 204.244.159.55:51801 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC age 00:00:14, expires in 00:00:17, 3:0 pkts, 234:0 bytes, rule 9 all tcp 10.170.54.1:81 <- 172.16.3.71:3100 CLOSED:SYN_SENT [0 + 65535] [3279736087 + 1](+833801231) age 00:00:14, expires in 00:00:25, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.71:3100 -> 204.244.159.68:50742 -> 10.170.54.1:81 SYN_SENT:CLOSED [4113537318 + 1](+5530) [0 + 65535] age 00:00:14, expires in 00:00:25, 3:0 pkts, 144:0 bytes, rule 5 all tcp 10.170.54.1:81 <- 172.16.3.74:3179 CLOSED:SYN_SENT [0 + 65535] [926335667 + 1](+3707646138) age 00:00:13, expires in 00:00:26, 3:0 pkts, 144:0 bytes, rule 2 all tcp 172.16.3.74:3179 -> 204.244.159.55:52685 -> 10.170.54.1:81 SYN_SENT:CLOSED [339014509 + 1](+5602) [0 + 65535] age 00:00:13, expires in 00:00:26, 3:0 pkts, 144:0 bytes, rule 8 all tcp 10.170.54.1:81 <- 172.16.3.31:2910 CLOSED:SYN_SENT [0 + 65535] [413832409 + 1](+1332464212) age 00:00:05, expires in 00:00:28, 2:0 pkts, 96:0 bytes, rule 2 all tcp 172.16.3.31:2910 -> 204.244.159.68:55614 -> 10.170.54.1:81 SYN_SENT:CLOSED [1746296621 + 1](+4477) [0 + 65535] age 00:00:05, expires in 00:00:28, 2:0 pkts, 96:0 bytes, rule 5 all tcp 10.170.54.1:81 <- 172.16.3.18:2483 CLOSED:SYN_SENT [0 + 65535] [1172638831 + 1](+459648591) age 00:00:04, expires in 00:00:29, 2:0 pkts, 96:0 bytes, rule 2 all tcp 172.16.3.18:2483 -> 204.244.159.55:58493 -> 10.170.54.1:81 SYN_SENT:CLOSED [1632287422 + 1](+5021) [0 + 65535] age 00:00:04, expires in 00:00:29, 2:0 pkts, 96:0 bytes, rule 8 all tcp 10.170.54.1:81 <- 172.16.3.54:2975 CLOSED:SYN_SENT [0 + 65535] [2580756030 + 1](+3460057222) age 00:00:04, expires in 00:00:29, 2:0 pkts, 96:0 bytes, rule 2 all tcp 172.16.3.54:2975 -> 204.244.159.68:50722 -> 10.170.54.1:81 SYN_SENT:CLOSED [1745845956 + 1](+4909) [0 + 65535] age 00:00:04, expires in 00:00:29, 2:0 pkts, 96:0 bytes, rule 5 all tcp 10.170.54.1:81 <- 172.16.3.49:1949 CLOSED:SYN_SENT [0 + 1] [240678205 + 2](+2261118483) age 00:00:02, expires in 00:01:58, 1:0 pkts, 48:0 bytes, rule 2 all tcp 172.16.3.49:1949 -> 204.244.159.55:50044 -> 10.170.54.1:81 SYN_SENT:CLOSED [2501796688 + 2](+4727) [0 + 1] age 00:00:02, expires in 00:01:58, 1:0 pkts, 48:0 bytes, rule 8 all udp 172.16.3.255:137 <- 172.16.3.77:137 NO_TRAFFIC:SINGLE age 00:00:01, expires in 00:00:30, 2:0 pkts, 156:0 bytes, rule 3 all udp 172.16.3.77:137 -> 204.244.159.68:50174 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC age 00:00:01, expires in 00:00:30, 2:0 pkts, 156:0 bytes, rule 6 all udp 172.16.3.255:137 <- 172.16.3.17:137 NO_TRAFFIC:SINGLE age 00:00:01, expires in 00:00:30, 2:0 pkts, 156:0 bytes, rule 3 all udp 172.16.3.17:137 -> 204.244.159.55:58365 -> 172.16.3.255:137 SINGLE:NO_TRAFFIC age 00:00:01, expires in 00:00:30, 2:0 pkts, 156:0 bytes, rule 9 From ady at freebsd.ady.ro Fri Feb 27 00:09:59 2009 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Fri Feb 27 00:10:06 2009 Subject: FreeBSD Router Problem In-Reply-To: <200902270004.24158.shawn@tandac.com> References: <3650.206.108.16.89.1235691792.squirrel@alder.hosix.com> <200902262341.35069.shawn@tandac.com> <78cb3d3f0902262354j6c22b43do565b75523a8007e3@mail.gmail.com> <200902270004.24158.shawn@tandac.com> Message-ID: <78cb3d3f0902270009v7b224fbch51fbc1240cc3d5d4@mail.gmail.com> Hi, On Fri, Feb 27, 2009 at 9:04 AM, Shawn Everett wrote: > On Thursday 26 February 2009, Adrian Penisoara wrote: > > pfctl -v -s state > > It's midnight here. There should be very little active traffic from > workstations at this hour. I was just about to head off to bed. > OK, then check what's the output around the time it reproduces (before and after)... Bonne nuit :-P Adrian. From Michael.Tuexen at lurchi.franken.de Fri Feb 27 01:29:24 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Fri Feb 27 01:34:58 2009 Subject: TCP performance question Message-ID: <5C9E4C55-06EC-482A-AE8C-2D900C74FA1F@lurchi.franken.de> Dear all, we have used a client to do while (1) { send(fd, buffer, n); } against a discard server on a different machine. The sender is running FreeBSD 7.1, for the receiver we used two different machines, one running FreeBSD 7.1 another one Mac OS X 10.5.6. The machines are old, so I do not care about the absolute numbers. We measured the throughput for 60 seconds and different values of n. Here is what we got: n throughput 500, 77716.505790 501, 77490.917999 502, 77412.961710 503, 77333.560297 504, 77801.337017 505, 77427.814392 506, 77422.640826 507, 77360.185565 508, 77607.863180 509, 77445.288161 510, 77531.083699 511, 77486.518785 512, 77908.246985 513, 68175.140109 514, 68338.332801 515, 68359.883062 516, 68640.669589 517, 68314.060835 518, 68473.051618 519, 68507.277602 520, 68930.431180 521, 68590.979508 522, 68790.924360 523, 68848.960564 524, 69091.676020 525, 68720.795262 526, 68897.330715 527, 69070.935237 528, 69421.723656 529, 68908.417372 530, 69000.914392 The question I have is he following: Why is the throughput smaller for n > 512 than for n <= 512? Since the result is about the same for different receivers, this seems to be related to the sender side. Best regards Michael From levein at gmail.com Sat Feb 28 07:25:28 2009 From: levein at gmail.com (Kevin) Date: Sat Feb 28 07:25:35 2009 Subject: Strange Server Problems Message-ID: Hi All, I have a dedicated server running FreeBSD 7.0 release, it has been running well for two months. Suddenly, some websites stopped responding, all websites hosted on this server are simple PHP sites, if one site is working, all of them should work. I checked the bind/apache/mysql, everything is fine (otherwise no websiets would be working). Could anyone please give me some hints? Where should I start to look into this problem? Thanks, Kevin From levein at gmail.com Sat Feb 28 07:35:35 2009 From: levein at gmail.com (Kevin) Date: Sat Feb 28 07:35:41 2009 Subject: Strange Server Problems In-Reply-To: <004401c999b9$21655ba0$441818d8@launchpad02> References: <004401c999b9$21655ba0$441818d8@launchpad02> Message-ID: Thanks for your reply, Joe! There is nothing in either system log or Apache log files. Apache doesn't seem to have got the requests at all. Very strange. On Sat, Feb 28, 2009 at 7:27 AM, Joe Mays wrote: > > I have a dedicated server running FreeBSD 7.0 release, it has been > running > > well for two months. Suddenly, some websites stopped responding, all > > websites hosted on this server are simple PHP sites, if one site is > working, > > all of them should work. I checked the bind/apache/mysql, everything > is fine > > (otherwise no websiets would be working). Could anyone please give > me some > > hints? Where should I start to look into this problem? > > Well, logs, obviously. Does anything appear in the apache error log > when you try to hit the sites? > > From gavin at FreeBSD.org Sat Feb 28 07:40:40 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Feb 28 07:40:51 2009 Subject: conf/132179: [patch] /etc/network.subr: ipv6 rtsol on incorrect wlan interface Message-ID: <200902281540.n1SFedKc099961@freefall.freebsd.org> Synopsis: [patch] /etc/network.subr: ipv6 rtsol on incorrect wlan interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Feb 28 15:38:25 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). I think -net is probably the most appropriate list for this, rather than -rc. http://www.freebsd.org/cgi/query-pr.cgi?pr=132179 From jfmays at launchpad.win.net Sat Feb 28 07:46:04 2009 From: jfmays at launchpad.win.net (Joe Mays) Date: Sat Feb 28 07:46:11 2009 Subject: Strange Server Problems References: Message-ID: <004401c999b9$21655ba0$441818d8@launchpad02> > I have a dedicated server running FreeBSD 7.0 release, it has been running > well for two months. Suddenly, some websites stopped responding, all > websites hosted on this server are simple PHP sites, if one site is working, > all of them should work. I checked the bind/apache/mysql, everything is fine > (otherwise no websiets would be working). Could anyone please give me some > hints? Where should I start to look into this problem? Well, logs, obviously. Does anything appear in the apache error log when you try to hit the sites? From jfmays at launchpad.win.net Sat Feb 28 08:31:48 2009 From: jfmays at launchpad.win.net (Joe Mays) Date: Sat Feb 28 08:31:55 2009 Subject: Strange Server Problems References: <004401c999b9$21655ba0$441818d8@launchpad02> Message-ID: <009f01c999c1$e0f6fa70$441818d8@launchpad02> Telnet to port 80 and do an http 1.1 get request for both a site hostname that works and one that doesn't. What do you get as output in each case? GET / HTTP/1.1 Host: www.hostname.com Also, if nothing is showing up in the logs at all I wouldn't expect it to be php problem, but you might test that too. Put a simple static html page in one of the websites that has stopped responding, see if you can pull that page. ----- Original Message ----- From: "Kevin" To: Sent: Saturday, February 28, 2009 10:35 AM Subject: Re: Strange Server Problems > Thanks for your reply, Joe! There is nothing in either system log or Apache > log files. Apache doesn't seem to have got the requests at all. Very > strange. > > > On Sat, Feb 28, 2009 at 7:27 AM, Joe Mays wrote: > > > > I have a dedicated server running FreeBSD 7.0 release, it has been > > running > > > well for two months. Suddenly, some websites stopped responding, all > > > websites hosted on this server are simple PHP sites, if one site is > > working, > > > all of them should work. I checked the bind/apache/mysql, everything > > is fine > > > (otherwise no websiets would be working). Could anyone please give > > me some > > > hints? Where should I start to look into this problem? > > > > Well, logs, obviously. Does anything appear in the apache error log > > when you try to hit the sites? > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > -- > BEGIN-ANTISPAM-VOTING-LINKS > ------------------------------------------------------ > > Teach Your Spam and Virus filtering service if this mail (ID 129737484) is spam: > Spam: http://filter.win.net/b.php?i=129737484&m=54107737577b&c=s > Not spam: http://filter.win.net/b.php?i=129737484&m=54107737577b&c=n > Forget vote: http://filter.win.net/b.php?i=129737484&m=54107737577b&c=f > ------------------------------------------------------ > END-ANTISPAM-VOTING-LINKS > From levein at gmail.com Sat Feb 28 12:54:53 2009 From: levein at gmail.com (Kevin) Date: Sat Feb 28 12:54:59 2009 Subject: Strange Server Problems In-Reply-To: <49A9A2DB.3010504@acm.poly.edu> References: <004401c999b9$21655ba0$441818d8@launchpad02> <49A9A2DB.3010504@acm.poly.edu> Message-ID: Hi Boris, Thanks for your reply! With Joe's help, I narrowed down the problem to IP configurations, it turned out to be my ISP's fault, they changed something on their side and caused some IPs to stop working, the requests didnt' reach the server. I convinced the support to report the problem, their networking stuff fixed the problem. Kevin On Sat, Feb 28, 2009 at 12:47 PM, Boris Kochergin wrote: > Kevin wrote: > >> Thanks for your reply, Joe! There is nothing in either system log or >> Apache >> log files. Apache doesn't seem to have got the requests at all. Very >> strange. >> >> >> On Sat, Feb 28, 2009 at 7:27 AM, Joe Mays >> wrote: >> >> >> >>> I have a dedicated server running FreeBSD 7.0 release, it has been >>>> >>>> >>> running >>> >>> >>>> well for two months. Suddenly, some websites stopped responding, all >>>> websites hosted on this server are simple PHP sites, if one site is >>>> >>>> >>> working, >>> >>> >>>> all of them should work. I checked the bind/apache/mysql, everything >>>> >>>> >>> is fine >>> >>> >>>> (otherwise no websiets would be working). Could anyone please give >>>> >>>> >>> me some >>> >>> >>>> hints? Where should I start to look into this problem? >>>> >>>> >>> Well, logs, obviously. Does anything appear in the apache error log >>> when you try to hit the sites? >>> >>> >>> >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > Apache doesn't write to the access log until a request is complete, so it > may be worth bumping the LogLevel value to something more verbose. > > -Boris > From spawk at acm.poly.edu Sat Feb 28 13:15:37 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Sat Feb 28 13:15:44 2009 Subject: Strange Server Problems In-Reply-To: References: <004401c999b9$21655ba0$441818d8@launchpad02> Message-ID: <49A9A2DB.3010504@acm.poly.edu> Kevin wrote: > Thanks for your reply, Joe! There is nothing in either system log or Apache > log files. Apache doesn't seem to have got the requests at all. Very > strange. > > > On Sat, Feb 28, 2009 at 7:27 AM, Joe Mays wrote: > > >>> I have a dedicated server running FreeBSD 7.0 release, it has been >>> >> running >> >>> well for two months. Suddenly, some websites stopped responding, all >>> websites hosted on this server are simple PHP sites, if one site is >>> >> working, >> >>> all of them should work. I checked the bind/apache/mysql, everything >>> >> is fine >> >>> (otherwise no websiets would be working). Could anyone please give >>> >> me some >> >>> hints? Where should I start to look into this problem? >>> >> Well, logs, obviously. Does anything appear in the apache error log >> when you try to hit the sites? >> >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Apache doesn't write to the access log until a request is complete, so it may be worth bumping the LogLevel value to something more verbose. -Boris From takahiro.kurosawa at gmail.com Sat Feb 28 21:50:03 2009 From: takahiro.kurosawa at gmail.com (Takahiro Kurosawa) Date: Sat Feb 28 21:50:09 2009 Subject: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic Message-ID: <200903010550.n215o3Oq041734@freefall.freebsd.org> The following reply was made to PR kern/116837; it has been noted by GNATS. From: Takahiro Kurosawa To: Lucius Windschuh Cc: bug-followup@freebsd.org Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic Date: Sun, 1 Mar 2009 14:46:44 +0900 2009/2/21 Lucius Windschuh : > =A0This is a follow-up to PR kern/116837. The described issue is solved, > =A0but now we have this issue. > =A0The following simple steps lead to a kernel panic on my system (i386, > =A0SMP, 8-CURRENT from Feb. 18th): > > =A0-->8-- > =A0cat < /dev/tun0 > /dev/tun0 & > =A0ifconfig tun0 up > =A0ifconfig tun0 destroy & ifconfig tun0 destroy > =A0--8<-- > > =A0Panic string: Bad link elm 0xc6437c00 prev->next !=3D elm > > =A0Responsible backtraces: > > =A0Tracing pid 1610 tid 100114 td 0xc686f240 > =A0kdb_enter(c090abd7,c090abd7,c08e2418,eaefeb6c,0,...) at kdb_enter+0x3a > =A0panic(c08e2418,c6437c00,c091867f,d3,2d,...) at panic+0x136 > =A0if_clone_destroyif(c0976300,c6437c00,c091867f,bf,0,...) at > =A0if_clone_destroyif+0x8a > =A0if_clone_destroy(c724f320,19c,eaefebd4,c0604976,c1494788,...) at > =A0if_clone_destroy+0xa2 if_clone_destroyif() should check that ifp is on ifc->ifc_iflist but it doesn't. Probably the following patch may fix this problem, but I fear that there might be another race between a thread accessing the ifp members and a thread calling if_clone_destroy(). # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # if_clone.c.diff # echo x - if_clone.c.diff sed 's/^X//' >if_clone.c.diff << 'fa5d2f08d96bc39865fb972ff194104f' X=3D=3D=3D sys/net/if_clone.c X=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D X--- sys/net/if_clone.c (revision 189132) X+++ sys/net/if_clone.c (local) X@@ -201,6 +201,7 @@ X int X if_clone_destroyif(struct if_clone *ifc, struct ifnet *ifp) X { X+ struct ifnet *tmp; X int err; X X if (ifc->ifc_destroy =3D=3D NULL) { X@@ -209,8 +210,15 @@ X } X X IF_CLONE_LOCK(ifc); X- IFC_IFLIST_REMOVE(ifc, ifp); X+ LIST_FOREACH(tmp, &ifc->ifc_iflist, if_clones) { X+ if (tmp =3D=3D ifp) { X+ IFC_IFLIST_REMOVE(ifc, ifp); X+ break; X+ } X+ } X IF_CLONE_UNLOCK(ifc); X+ if (tmp =3D=3D NULL) X+ return (ENXIO); /* ifp is not on the list. */ X X if_delgroup(ifp, ifc->ifc_name); X fa5d2f08d96bc39865fb972ff194104f exit From stutiredboy at gmail.com Sat Feb 28 23:32:41 2009 From: stutiredboy at gmail.com (stutiredboy) Date: Sat Feb 28 23:32:48 2009 Subject: crazy network problem -- sleep? Message-ID: <49AA352E.5060803@gmail.com> hi,all: recently , we found a problem that , some server which with FreeBSD 6.2 may stop networking after days of services, it is so difficulty express this status, e, such as sleep? i can not ping this server, tracert is also failure, and other services ,network/server seems to be down... but while i insert the keyboard/mouse/crt in , everything is ok, such as a ring to call the system to wake-up... no errors found in dmesg or /var/log/messages, such as nothing happened...orz?our unlimit args as follow: cputime unlimited filesize unlimited datasize 2088152 kbytes stacksize 65536 kbytes coredumpsize unlimited memoryuse unlimited vmemoryuse unlimited descriptors 655000 memorylocked unlimited maxproc 5547 sbsize unlimited plz give me some suggestion to trace the problem or solve it . thanks a lot ! Best wishes !