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 s...@freebsd.org 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 Matveychuks...@freebsd.org 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: Intel(R) PRO/1000 Network Connection 6.9.14 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: Intel(R) PRO/1000 Network Connection 6.9.14 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 ro...@icir.org 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 ryst...@gmail.com wrote: 8.0-RELEASE is not able to bring up some of the my em interfaces. The error message that I get is: em0: Intel(R) PRO/1000 Network Connection 6.9.14 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: Intel(R) PRO/1000 Network Connection 6.9.14 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 jamesbrandongo...@gmail.com wrote: On Sun, May 23, 2010 at 5:06 PM, Kurt Jaeger p...@opsec.eu wrote: The following reply was made to PR kern/146792; it has been noted by GNATS. From: Kurt Jaeger p...@opsec.eu 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 Matveychuks...@freebsd.org 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
