Re: Broadcom BCM57765 support?
On 19/04/2011 23:09, YongHyeon PYUN wrote: > Here is experimental patch for BCM57765 family controllers. I > don't have these controllers so the patch was not tested at all > except compile. Recent Broadcom controllers like BCM57765 support > EEE(Energy Efficient Ethernet) feature but it is not yet supported > by the patch. Many thanks for this patch. The patch wouldn't apply cleanly to either the 8.2-release source or to the latest if_bge / if_bgereg so I had to do it manually; but that wasn't too much of a problem. What revision should I have tried to apply the patch to? Things are not fully working yet after the patch is applied though. The current state is that the device is recognised, MAC address detected OK, link state detected OK; you can ifconfig up the interface without a problem. However, I'm seeing "bge0: watchdog timeout -- resetting" messages shortly after attempting to ping something on the LAN. The machine being pinged doesn't show up in the ARP cache. Looking at the switch that its connected to, I see the mac address learned on the port, and the received packet and byte counts incrementing with no errors so I believe that the machine is successfully transmitting frames but not able to receive them properly. The switch stats show that the switch is transmitting frames to the machine. > Also it would good to see the output of "pciconf -lcbv" and dmesg > after applying the patch. The machine in question is a 2010 Mac Mini (model rev A1347) - this has a number of "features" that make FreeBSD an interesting challenge. The kernel I'm using is a normal 8.2-GENERIC with another very minor tweak to stop the Nvidia MCP89 ata controller from being used in SATA mode (this doesn't work - Linux has a workaround based on using UDMA). Attached is a dmesg, pciconf, and the output of sysctl -a dev.bge.0 after the patch was applied. If there is any other debugging information I need to get to help please let me know. Once we have this working I'll willingly give it some thorough proper testing. Thanks again, Paul. Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #1: Wed Apr 20 08:58:24 UTC 2011 r...@badger.prt.org:/usr/src/sys/amd64/compile/GENERIC-TEST2 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (2389.26-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1780576256 (1698 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) unknown: I/O range not supported acpi_hpet0: iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 2500 Hz quality 900 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) isab0: port 0x2100-0x21ff at device 3.0 on pci0 isa0: on isab0 pci0: at device 3.1 (no driver attached) pci0: at device 3.2 (no driver attached) pci0: at device 3.3 (no driver attached) pci0: at device 3.4 (no driver attached) ohci0: mem 0x9358a000-0x9358afff irq 18 at device 4.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0x9358b100-0x9358b1ff irq 19 at device 4.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.10 usbus1: on ehci0 ohci1: mem 0x93589000-0x93589fff irq 20 at device 6.0 on pci0 ohci1: [ITHREAD] usbus2: on ohci1 ehci1: mem 0x9358b000-0x9358b0ff irq 21 at device 6.1 on pci0 ehci1: [ITHREAD] usbus3: EHCI version 1.10 usbus3: on ehci1 pci0: at device 8.0 (no driver attached) atapci0: port 0x2298-0x229f,0x22a4-0x22a7,0x2290-0x2297,0x22a0-0x22a3,0x2280-0x228f mem 0x93584000-0x93585fff irq 23 at device 10.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 11.0 (no driver attached) pcib1: at device 14.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 fwohci0: <1394 Open Host Controller Interface> me
Re: bin/104921: [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (another variation on PR 91245)
Hello, Bug-followup. It is still valid for 8.2-STABLE: gateway# ipfw add 5 allow ipv6-icmp from any to 2001:470:1f09:::/64,2001:470::1::/64,2001:470::2::/64 icmp6types 1,2,3,4,128,129 keep-state ipfw: bad netmask ``470:1f09:::/64'' gateway# uname -a FreeBSD gateway.home.serebryakov.spb.ru 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Apr 15 16:57:44 MSD 2011 l...@vmware-8-32.home.serebryakov.spb.ru:/usr/obj/nanobsd.gateway-net5501/usr/src/sys/NET5501 i386 It is very annoying bug, because "allow" rule can be divided into one-rule-per-network, but "deny ... NOT IPv6,IPv6,..." is hard to emulate (with multiple skipto rules). -- // 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-unsubscr...@freebsd.org"
sys/net/radix.c refuses addresses with all zeroes
Hello, The sys/net/radix.c refuses to add 0.0.0.0 address to the tree, but allows to add 0.0.0.0/32 address (when mask is specified). The question. Is it not allowed to give address with all zeroes to radix.c or is there some mistake in the radix.c code? How to check: Create file, say, zero-export: / 0.0.0.0 / -network 0.0.0.0/32 / :: / -network ::/128 and run "mountd -d zero-export". ___ 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: Broadcom BCM57765 support?
Hi, On 20/04/2011 14:16, Marius Strobl wrote: > Looks like brgphy(4) also needs to be taught about this hardware. Could > you please provide the corresponding part of a verbose dmesg? Hopefully this covers everything that you might need: pcib4: slot 0 INTA is routed to irq 18 found-> vendor=0x14e4, dev=0x16bc, revid=0x00 domain=0, bus=4, slot=0, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0x9312, size 16, enabled pcib4: requested memory range 0x9312-0x9312: good pcib0: matched entry for 0.22.INTB (src \\_SB_.PCI0.Z00O:0) pci_link13: Picked IRQ 19 with weight 1 pcib0: slot 22 INTB routed to irq 19 via \\_SB_.PCI0.Z00O pcib4: slot 0 INTB is routed to irq 19 bge0: mem 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x00d897, model 0x0024, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [MPSAFE] bge0: [FILTER] Many thanks, Paul. ___ 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: Broadcom BCM57765 support?
On Wed, Apr 20, 2011 at 11:54:31AM +0100, Paul Thornton wrote: > bge0: mem > 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4 > bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E > miibus0: on bge0 > ukphy0: PHY 1 on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Looks like brgphy(4) also needs to be taught about this hardware. Could you please provide the corresponding part of a verbose dmesg? Marius ___ 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: Broadcom BCM57765 support?
On Wed, Apr 20, 2011 at 02:22:47PM +0100, Paul Thornton wrote:
> Hi,
>
> On 20/04/2011 14:16, Marius Strobl wrote:
> > Looks like brgphy(4) also needs to be taught about this hardware. Could
> > you please provide the corresponding part of a verbose dmesg?
>
> Hopefully this covers everything that you might need:
>
> pcib4: slot 0 INTA is routed to irq 18
> found-> vendor=0x14e4, dev=0x16bc, revid=0x00
> domain=0, bus=4, slot=0, func=1
> class=08-05-01, hdrtype=0x00, mfdev=1
> cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords)
> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> intpin=b, irq=7
> powerspec 3 supports D0 D3 current D0
> MSI supports 1 message, 64 bit
> map[10]: type Prefetchable Memory, range 64, base 0x9312, size 16,
> enabled
> pcib4: requested memory range 0x9312-0x9312: good
> pcib0: matched entry for 0.22.INTB (src \\_SB_.PCI0.Z00O:0)
> pci_link13: Picked IRQ 19 with weight 1
> pcib0: slot 22 INTB routed to irq 19 via \\_SB_.PCI0.Z00O
> pcib4: slot 0 INTB is routed to irq 19
> bge0: mem
> 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4
> bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310
> bge0: attempting to allocate 1 MSI vectors (8 supported)
> msi: routing MSI IRQ 256 to local APIC 0 vector 56
> bge0: using IRQ 256 for MSI
> bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E
> bge0: Disabling fastboot
> bge0: Disabling fastboot
> miibus0: on bge0
> ukphy0: PHY 1 on miibus0
> ukphy0: OUI 0x00d897, model 0x0024, rev. 0
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
> bge0: bpf attached
> bge0: Ethernet address: c4:2c:03:08:0b:9d
> bge0: [MPSAFE]
> bge0: [FILTER]
>
Hrm, looks like neither NetBSD nor OpenBSD support this variant so
far, however Linux also doesn't seem to have special handling for it.
Could you please give the attached patch in addition to the existing
one a try?
Marius
Index: brgphy.c
===
--- brgphy.c (revision 220886)
+++ brgphy.c (working copy)
@@ -143,6 +143,7 @@ static const struct mii_phydesc brgphys[] = {
MII_PHY_DESC(xxBROADCOM_ALT1, BCM5761),
MII_PHY_DESC(xxBROADCOM_ALT1, BCM5709S),
MII_PHY_DESC(xxBROADCOM_ALT2, BCM5717C),
+ MII_PHY_DESC(xxBROADCOM_ALT2, BCM57785),
MII_PHY_DESC(BROADCOM2, BCM5906),
MII_PHY_END
};
Index: miidevs
===
--- miidevs (revision 220886)
+++ miidevs (working copy)
@@ -159,6 +159,7 @@ model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/
model xxBROADCOM_ALT1 BCM5761 0x003d BCM5761 10/100/1000baseTX PHY
model xxBROADCOM_ALT1 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY
model xxBROADCOM_ALT2 BCM5717C 0x0020 BCM5717C 10/100/1000baseTX PHY
+model xxBROADCOM_ALT2 BCM57785 0x0024 BCM57785 10/100/1000baseTX PHY
model BROADCOM2 BCM5906 0x0004 BCM5906 10/100baseTX PHY
/* Cicada Semiconductor PHYs (now owned by Vitesse?) */
___
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"
Intel ix (X520) disconnects when manipulating ips?
Seems there's an issue with the intel ix driver which causes it to bin connections when you manipulate ip aliases. This causes issues on boot when jails start as it bins other active sessions. Is this a know issue? Running 8.2-RELEASE amd64 here. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Broadcom BCM57765 support?
Hi, On 20/04/2011 14:44, Marius Strobl wrote: > Hrm, looks like neither NetBSD nor OpenBSD support this variant so > far, however Linux also doesn't seem to have special handling for it. > Could you please give the attached patch in addition to the existing > one a try? I've added your patch to brgphy as well - but at a user level I'm still seeing the same thing: - Ethernet frames are transmitted by the box, switch sees them with no errors. - Frames received don't seem to make it to/beyond the driver. - After I hit CTRL-C on the non-working ping, I get a "bge0: watchdog timeout -- resetting" message. If I tcpdump the interface, I see nothing, but the dev.bge.0.stats counters are incrementing when I attempt to ping. The switch is showing counts on both its tx and rx packets counters with no errors. Is there somewhere I need to add more debug in the driver to understand what it is doing? The current dmesg looks like: bge0: mem 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4 bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E bge0: Disabling fastboot bge0: Disabling fastboot miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x00d897, model 0x0024, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: c4:2c:03:08:0b:9d bge0: [MPSAFE] bge0: [FILTER] Paul. ___ 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/156408: [vlan] Routing failure when using VLANs vs. Physical ethernet interfaces.
The following reply was made to PR kern/156408; it has been noted by GNATS. From: Thomas Johnson To: bug-follo...@freebsd.org, t...@claimlynx.com Cc: Subject: re: kern/156408: [vlan] Routing failure when using VLANs vs. Physical ethernet interfaces. Date: Wed, 20 Apr 2011 10:21:27 -0500 --20cf307d01eeabd00704a15b2dba Content-Type: text/plain; charset=ISO-8859-1 After further investigation, I have learned some new information that may or may not be useful. Although I am able to connect from a host on the office lan over the bridge to hosts on the data center lan, the firewall itself is unable to connect to these same hosts. This can be corrected by adding host static routes to the firewall in the same manner as I described in my initial PR. This behavior appears to be a result of the 172.31.0.0/16 route pointing at the vlan500 interface, as I see ARP requests for dc hosts leave the firewall on the local lan (vlan500). By comparison, my existing/old firewall has a matching route for 172.31.0.0/16 pointing at the local lan (in that case, the lan is a physical adapter, not a vlan). Connections from the firewall to hosts at the dc lan work correctly, and I see ARP requests on both the lan interface and the vpn tap interface. -- Thomas Johnson ClaimLynx, Inc. --20cf307d01eeabd00704a15b2dba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After further investigation, I have learned some new information that may o= r may not be useful.Although I am able to connect from a host on th= e office lan over the bridge to hosts on the data center lan, the firewall = itself is unable to connect to these same hosts. This can be corrected by a= dding host static routes to the firewall in the same manner as I described = in my initial PR. This behavior appears to be a result of the 172.31.0.0/16 route pointing at t= he vlan500 interface, as I see ARP requests for dc hosts leave the firewall= on the local lan (vlan500). By comparison, my existing/old firewall has a matching route for http://172.31.0.0/16";>172.31.0.0/16 pointing at the local lan (in = that case, the lan is a physical adapter, not a vlan). Connections from the= firewall to hosts at the dc lan work correctly, and I see ARP requests on = both the lan interface and the vpn tap interface. -- Thomas JohnsonClaimLynx, Inc. --20cf307d01eeabd00704a15b2dba-- ___ 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: Broadcom BCM57765 support?
On Wed, Apr 20, 2011 at 04:21:28PM +0100, Paul Thornton wrote: > Hi, > > On 20/04/2011 14:44, Marius Strobl wrote: > > Hrm, looks like neither NetBSD nor OpenBSD support this variant so > > far, however Linux also doesn't seem to have special handling for it. > > Could you please give the attached patch in addition to the existing > > one a try? > > I've added your patch to brgphy as well - but at a user level I'm still > seeing the same thing: > - Ethernet frames are transmitted by the box, switch sees them with no > errors. > - Frames received don't seem to make it to/beyond the driver. > - After I hit CTRL-C on the non-working ping, I get a "bge0: watchdog > timeout -- resetting" message. > > If I tcpdump the interface, I see nothing, but the dev.bge.0.stats > counters are incrementing when I attempt to ping. > > The switch is showing counts on both its tx and rx packets counters with > no errors. > > Is there somewhere I need to add more debug in the driver to understand > what it is doing? > Ok, that would indicate there is an interrupt delivery issue if all others changes(including Marius' patch) are correct. Because there is no publicly available data sheet for BCM57765 yet I'm not sure what is real difference between BCM5717 and BCM57765. However I guess they require similar hardware configuration. Both BCM5717 and BCM57765 will use tagged status feature of controller if MSI is available. And NVIDIA bridge controller is known to have MSI issues for a long time in FreeBSD. Please check whether you received any interrupts for bge(4) with vmstat(8). If you see no interrupt from the output, either try disabling MSI or apply r219737 and r219740 and see whether that makes any difference. > The current dmesg looks like: > > bge0: mem > 0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4 > bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310 > bge0: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > bge0: using IRQ 256 for MSI > bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E > bge0: Disabling fastboot > bge0: Disabling fastboot > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: OUI 0x00d897, model 0x0024, rev. 0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: c4:2c:03:08:0b:9d > bge0: [MPSAFE] > bge0: [FILTER] > > Paul. ___ 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: Broadcom BCM57765 support?
On Wed, Apr 20, 2011 at 11:54:31AM +0100, Paul Thornton wrote: > On 19/04/2011 23:09, YongHyeon PYUN wrote: > > Here is experimental patch for BCM57765 family controllers. I > > don't have these controllers so the patch was not tested at all > > except compile. Recent Broadcom controllers like BCM57765 support > > EEE(Energy Efficient Ethernet) feature but it is not yet supported > > by the patch. > > Many thanks for this patch. > > The patch wouldn't apply cleanly to either the 8.2-release source or to > the latest if_bge / if_bgereg so I had to do it manually; but that > wasn't too much of a problem. What revision should I have tried to > apply the patch to? > The patch was generated against latest HEAD. > Things are not fully working yet after the patch is applied though. > > The current state is that the device is recognised, MAC address detected > OK, link state detected OK; you can ifconfig up the interface without a > problem. However, I'm seeing "bge0: watchdog timeout -- resetting" > messages shortly after attempting to ping something on the LAN. The > machine being pinged doesn't show up in the ARP cache. > > Looking at the switch that its connected to, I see the mac address > learned on the port, and the received packet and byte counts > incrementing with no errors so I believe that the machine is > successfully transmitting frames but not able to receive them properly. > The switch stats show that the switch is transmitting frames to the > machine. > > > Also it would good to see the output of "pciconf -lcbv" and dmesg > > after applying the patch. > > The machine in question is a 2010 Mac Mini (model rev A1347) - this has > a number of "features" that make FreeBSD an interesting challenge. The > kernel I'm using is a normal 8.2-GENERIC with another very minor tweak > to stop the Nvidia MCP89 ata controller from being used in SATA mode > (this doesn't work - Linux has a workaround based on using UDMA). > Hmm, NVIDIA controller again. See my other posting to this thread. > Attached is a dmesg, pciconf, and the output of sysctl -a dev.bge.0 > after the patch was applied. > > If there is any other debugging information I need to get to help please > let me know. Once we have this working I'll willingly give it some > thorough proper testing. > > Thanks again, > > Paul. ___ 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/156493: [msk] Marvell Yukon 2 device works only few seconds
Old Synopsis: Marvell Yukon 2 device works only few seconds New Synopsis: [msk] Marvell Yukon 2 device works only few seconds Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 20 22:28:37 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=156493 ___ 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"
stateless dhcp6 server for FreeBSD?
Hello, Freebsd-net. Is here any stateless dhcp6 solution for FreeBSD? isc-dhcp 4.1 seems to not support statless mode by server dibbler is not ported to FreeBSD. dhcp6s (WIDE-dhcpd) works only with one interface... It is possible, of course, to run multiple instances of dhcp6s for multiple interfaces, but it doesn't look very convenient. I need only distribute IPv6 DNS server addresses to clients, but not prefixes or address information. -- // 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-unsubscr...@freebsd.org"
Re: stateless dhcp6 server for FreeBSD?
2011/4/20 Lev Serebryakov : > Hello, Freebsd-net. > > Is here any stateless dhcp6 solution for FreeBSD? > > isc-dhcp 4.1 seems to not support statless mode by server > > dibbler is not ported to FreeBSD. > > dhcp6s (WIDE-dhcpd) works only with one interface... It is possible, > of course, to run multiple instances of dhcp6s for multiple > interfaces, but it doesn't look very convenient. > > I need only distribute IPv6 DNS server addresses to clients, but not > prefixes or address information. Are you sure isc-dhcp doesn't support stateless? I was able to get it working by creating subnet6 entries in dhcpd6.conf and telling rtadvd to operate in other-stateful configuration mode (raflags="o"). At that point, stateless autoconfiguration worked and the clients did a DHCP request to determine their name servers only. -Proto ___ 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: stateless dhcp6 server for FreeBSD?
Hello, Michael. You wrote 21 апреля 2011 г., 2:55:15: > Are you sure isc-dhcp doesn't support stateless? I was able to get it > working by creating subnet6 entries in dhcpd6.conf and telling rtadvd > to operate in other-stateful configuration mode (raflags="o"). At that > point, stateless autoconfiguration worked and the clients did a DHCP > request to determine their name servers only. Hm... It is never mentioned in documentation. I've looking for "stateless" word in different forms without any success. I'll try this one, thank you. -- // 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-unsubscr...@freebsd.org"
Re: stateless dhcp6 server for FreeBSD?
> > Are you sure isc-dhcp doesn't support stateless? I was able to get it > > working by creating subnet6 entries in dhcpd6.conf and telling rtadvd > > to operate in other-stateful configuration mode (raflags="o"). At that > > point, stateless autoconfiguration worked and the clients did a DHCP > > request to determine their name servers only. > Hm... It is never mentioned in documentation. I've looking for > "stateless" word in different forms without any success. I'll try this > one, thank you. Think of DHCPv4 and DHCPINFORM - this is also stateless. Nothing magic about it. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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"
Gigabit Router Hardware Specs
hi, i want to setup a router-box with freebsd 8.0. with four Intel Pro/1000 NICs. the network i'm using router for, is a large and complicated network with high traffic almost all the time (up to 800Mbps for each of 4 NICs). and route table may get large. so these are my questions: 1- first, i wanted to know what hardware specifications do you recommend (RAM, CPU, ...)? 2- about CPU, which feature is more important? Cache, Core-Speed, number of Cores, FSB, ? 3- as a followup to my second question, which of these CPUs do you think is more suitable for me? and why? a) Intel Core2-Quad q8300 (2.50GHz) b) Intel Xeon e5405 (2.00GHz) c) Intel Xeon e5420 (2.50GHz) d) Intel Core-i5 540M (2.53GHz) thank you. ___ 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"
