kern/141285 ([em] hangs down/up intel nic during creating vlan)
Hello All! Whether it is planned to fix the bug kern/141285 ([em] hangs down/up intel nic during creating vlan) in a release 8.1 ? Thanks. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
move setfib(1)
Hi! Does is possible to move setfib(1) to /sbin for smooth using it in rc.d scripts? -- Sem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: move setfib(1)
In message: <4bfd158d.7020...@freebsd.org> Sergey Matveychuk writes: : Does is possible to move setfib(1) to /sbin for smooth using it in : rc.d scripts? It is small enough. I think that's a good idea. However, it would only be a problem if we are mounting / and /usr off NFS as separate partitions, right? Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: move setfib(1)
On 5/26/10 9:32 AM, M. Warner Losh wrote: In message:<4bfd158d.7020...@freebsd.org> Sergey Matveychuk writes: : Does is possible to move setfib(1) to /sbin for smooth using it in : rc.d scripts? Can you tell us why you need it so early? We could do it, but eventually everything ends up moving to /sbin or /bin unless we need a good reason. It is small enough. I think that's a good idea. However, it would only be a problem if we are mounting / and /usr off NFS as separate partitions, right? Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Crashes with ixgbe on FreeBSD 8
On Tue, May 25, 2010 at 12:03 -0700, I wrote: > /usr/src/sys/dev/ixgbe/ixgbe.c:833: warning: implicit declaration of function > 'drbr_needs_enqueue' So, I've now simply copied that function over and, indeed, that not only compiles but gives me a working 2.2.0 driver, enabling me to capture traffic in a stable fashion as far as I can tell so far ... My question: is simply pasting this function into RELEASE a reasonable fix, or am I missing out on further changes and am thus getting myself into trouble in some form? Robin -- Robin Sommer * Phone +1 (510) 666-2886 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
em: "Hardware Initialization Failed" on 8.0-RELEASE
8.0-RELEASE is not able to bring up some of the my em interfaces. The error message that I get is: em0: port 0xa800-0xa81f mem 0xce48-0xce49,0xce46-0xce47 irq 16 at device 0.0 on pci1 em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xce48 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 48 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: Hardware Initialization Failed em0: Unable to initialize the hardware device_attach: em0 attach returned 5 em1: port 0xac00-0xac1f mem 0xce4e-0xce4f,0xce4c-0xce4d irq 17 at device 0.1 on pci1 em1: Reserved 0x2 bytes for rid 0x10 type 3 at 0xce4e em1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 48 em1: using IRQ 256 for MSI em1: Using MSI interrupt em1: Hardware Initialization Failed em1: Unable to initialize the hardware device_attach: em1 attach returned 5 I tried enabling all of the debug output I could find in the em driver and got the following output(I truncated most of it because it didn't look interesting). e1000_set_d0_lplu_state_82571 e1000_read_phy_reg_igp e1000_get_hw_semaphore_82571 e1000_write_phy_reg_mdic e1000_read_phy_reg_mdic MDI Error e1000_put_hw_semaphore_generic Error Disabling LPLU D0 e1000_clear_hw_cntrs_82571 e1000_clear_hw_cntrs_base_generic em0: Hardware Initialization Failed em0: Unable to initialize the hardware Here's the pciconf output for the interfaces that are giving me problems: e...@pci0:1:0:0: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 hdr=0x00 e...@pci0:1:0:1: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 hdr=0x00 e...@pci0:2:0:0: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 hdr=0x00 e...@pci0:2:0:1: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 hdr=0x00 Please let me know if there's anything else that you need. I'm willing to try patches or get more debug output. Thanks, Ryan Stone ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Crashes with ixgbe on FreeBSD 8
Well, its one way to do it, and no, its not a problem, what I was planning on doing was copying the macro into my header file. Jack On Wed, May 26, 2010 at 1:00 PM, Robin Sommer wrote: > > On Tue, May 25, 2010 at 12:03 -0700, I wrote: > > > /usr/src/sys/dev/ixgbe/ixgbe.c:833: warning: implicit declaration of > function 'drbr_needs_enqueue' > > So, I've now simply copied that function over and, indeed, that not > only compiles but gives me a working 2.2.0 driver, enabling me to > capture traffic in a stable fashion as far as I can tell so far ... > > My question: is simply pasting this function into RELEASE a > reasonable fix, or am I missing out on further changes and am thus > getting myself into trouble in some form? > > Robin > > -- > Robin Sommer * Phone +1 (510) 666-2886 * ro...@icir.org > ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: em: "Hardware Initialization Failed" on 8.0-RELEASE
Maybe its a real hardware problem, never seen this behavior, I suppose you could try the STABLE/8 May snapshot, see if it helps. Jack On Wed, May 26, 2010 at 12:47 PM, Ryan Stone wrote: > 8.0-RELEASE is not able to bring up some of the my em interfaces. The > error message that I get is: > > em0: port 0xa800-0xa81f > mem 0xce48-0xce49,0xce46-0xce47 irq 16 at device 0.0 > on pci1 > em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xce48 > em0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 48 > em0: using IRQ 256 for MSI > em0: Using MSI interrupt > em0: Hardware Initialization Failed > em0: Unable to initialize the hardware > device_attach: em0 attach returned 5 > em1: port 0xac00-0xac1f > mem 0xce4e-0xce4f,0xce4c-0xce4d irq 17 at device 0.1 > on pci1 > em1: Reserved 0x2 bytes for rid 0x10 type 3 at 0xce4e > em1: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 48 > em1: using IRQ 256 for MSI > em1: Using MSI interrupt > em1: Hardware Initialization Failed > em1: Unable to initialize the hardware > device_attach: em1 attach returned 5 > > > I tried enabling all of the debug output I could find in the em driver > and got the following output(I truncated most of it because it didn't > look interesting). > > e1000_set_d0_lplu_state_82571 > e1000_read_phy_reg_igp > e1000_get_hw_semaphore_82571 > e1000_write_phy_reg_mdic > e1000_read_phy_reg_mdic > MDI Error > > e1000_put_hw_semaphore_generic > Error Disabling LPLU D0 > > e1000_clear_hw_cntrs_82571 > e1000_clear_hw_cntrs_base_generic > em0: Hardware Initialization Failed > em0: Unable to initialize the hardware > > Here's the pciconf output for the interfaces that are giving me problems: > > e...@pci0:1:0:0: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 > hdr=0x00 > e...@pci0:1:0:1: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 > hdr=0x00 > e...@pci0:2:0:0: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 > hdr=0x00 > e...@pci0:2:0:1: class=0x02 card=0x125e8086 chip=0x105e8086 rev=0x00 > hdr=0x00 > > Please let me know if there's anything else that you need. I'm > willing to try patches or get more debug output. > > Thanks, > Ryan Stone > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: em: "Hardware Initialization Failed" on 8.0-RELEASE
The em driver version 6.2.9(that's the Intel version number) worked just fine, but it stopped working on multiple machines as soon as I upgraded, so I doubt that it's the hardware. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load
This has since been fixed. However, with 8.0 the simplest fix is to turn flowtable off. sysctl net.inet.flowtable.enable=0 -Kip On Mon, May 24, 2010 at 4:54 AM, Brandon Gooch wrote: > On Sun, May 23, 2010 at 5:06 PM, Kurt Jaeger wrote: >> The following reply was made to PR kern/146792; it has been noted by GNATS. >> >> From: Kurt Jaeger >> To: bug-follo...@freebsd.org, n...@gtelecom.ru >> Cc: >> Subject: Re: kern/146792: [flowtable] flowcleaner 100% cpu's core load >> Date: Sun, 23 May 2010 16:19:25 +0200 >> >> Hi! >> >> I observe a similar behaviour on a 8.0-RELEASE-p2 i386 GENERIC >> kernel. >> >> System receives 2 BGP4 fullfeeds (approx. 310K routes each). >> >> The system is still running, a few processes are unkillable or >> die only after a long amount (1-2h) of time. >> >> Here's the list of unkillable processes: >> >> 80871 ?? R 0:00.00 /bin/sh /etc/periodic/daily/470.status-named >> 76499 ?? Rs 0:00.01 sshd: [accepted] (sshd) >> 76922 ?? Rs 0:00.01 sshd: [accepted] (sshd) >> >> flowcleaner looks pretty busy (for an uptime of approx. 40h): >> >> 22 ?? RL 1209:50.98 [flowcleaner] >> >> 4:17PM up 1 day, 22:22, 2 users, load averages: 7.20, 6.53, 5.81 >> >> quagga is running on the system, bgpd mgmt cli is no longer reachable: >> >> # telnet 0 2605 >> Trying 0.0.0.0... >> Connected to 0. >> Escape character is '^]'. >> >> ^] >> telnet> close >> Connection closed. >> # >> >> What can I do to help to debug this ? >> No console access available right now, but can probably made available. >> >> This is a production host, but not yet super-critical, so... > > I know absolutely nothing about quagga, and very, very little about > the flowcleaner process (or flowtable, no man page), but I DO KNOW > that Kip Macy suggested disabling: > > options FLOWTABLE > > from the kernel config of the machine experiencing the issue. This was > back in December 2009, so I'm not sure about a resolution to the > actual problem (or if it is just inherent in the design of the per-cpu > routing cache). > > Perhaps Kip may have more insight? > > -Brandon > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/147102: [ip6] route6d deletes site-local routes
Old Synopsis: IPv6 - route6d deletes site-local routes New Synopsis: [ip6] route6d deletes site-local routes Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 27 00:24:43 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=147102 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/147102: [ip6] route6d deletes site-local routes
Synopsis: [ip6] route6d deletes site-local routes Responsible-Changed-From-To: freebsd-net->hrs Responsible-Changed-By: hrs Responsible-Changed-When: Thu May 27 01:42:17 UTC 2010 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=147102 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: move setfib(1)
26.05.2010 20:38, Julian Elischer wrote: On 5/26/10 9:32 AM, M. Warner Losh wrote: In message:<4bfd158d.7020...@freebsd.org> Sergey Matveychuk writes: : Does is possible to move setfib(1) to /sbin for smooth using it in : rc.d scripts? Can you tell us why you need it so early? We could do it, but eventually everything ends up moving to /sbin or /bin unless we need a good reason. I'm thinking about this after Doug's message: http://lists.freebsd.org/pipermail/freebsd-rc/2010-May/001954.html ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: move setfib(1)
In message: <4bfe04e5.1010...@semmy.ru> Sergey Matveychuk writes: : 26.05.2010 20:38, Julian Elischer wrote: : > On 5/26/10 9:32 AM, M. Warner Losh wrote: : >> In message:<4bfd158d.7020...@freebsd.org> : >> Sergey Matveychuk writes: : >> : Does is possible to move setfib(1) to /sbin for smooth using it in : >> : rc.d scripts? : > : > Can you tell us why you need it so early? : > : > We could do it, but eventually everything ends up moving to /sbin or : > /bin unless we need a good reason. : > : : I'm thinking about this after Doug's message: : http://lists.freebsd.org/pipermail/freebsd-rc/2010-May/001954.html Right, and the only way that /usr/bin isn't going to be available if the network isn't up will be if you have NFS mounted root, but have a separate /usr partition. Otherwise, critmount happens before the network comes up, and that will ensure that you'll have /usr available at the point in the boot scripts you want to use it. Even if you have / and /usr separate on NFS partitions, you can specify netfs_types="" in the NFS root's rc.conf and all NFS mounts will mount too very early. Since you are proposing this for /etc/rc.d/routing, I think you can actually use it there and there will be no problem, even for whacked out NFS setups. Did I miss something? Warner P.S. On my system at least: rcorder says: /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/initrandom /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/encswap /etc/rc.d/ccd /etc/rc.d/swap1 /etc/rc.d/fsck /etc/rc.d/root /etc/rc.d/hostid /etc/rc.d/mdconfig /etc/rc.d/mountcritlocal so these wuold be the only places where you can't use binaries from /usr, right? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: move setfib(1)
In message: <20100527.001534.807935107107604070@bsdimp.com> "M. Warner Losh" writes: : at the point in the boot scripts you want to use it. Even if you have : / and /usr separate on NFS partitions, you can specify netfs_types="" : in the NFS root's rc.conf and all NFS mounts will mount too very : early. s/will mount too very early/will mount early as well/g Sorry. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
