Re: Broadcom BCM57765 support?
On Tue, Apr 19, 2011 at 03:09:07PM -0700, YongHyeon PYUN wrote: On Tue, Apr 19, 2011 at 07:48:51PM +0100, Paul Thornton wrote: Hi, The bge driver doesn't support this chipset yet and I was wondering if anyone has looked at implementing it. NetBSD looks like it has support for it. Now I may be wrong here, but it appears that the BCM57765 is similar to other devices based on the NetBSD if_bge.c source version 1.194. I've tried applying the NetBSD changes to the FreeBSD bge source but I don't know enough about the hardware and the code is different enough that I haven't made it very far. I can get a patched 8.2 kernel to detect the device, complain that the ASIC is unknown, read the MAC address correctly and determine there is link but as soon as you attempt to ifconfig up the interface the machine locks up. I'm happy to try and port this over but need a nudge in the right direction from someone who knows the code. 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. Also it would good to see the output of pciconf -lcbv and dmesg after applying the patch. FYI: Committed to HEAD(r221445). ___ 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 04/05/2011 18:05, YongHyeon PYUN wrote: FYI: Committed to HEAD(r221445). I've been away from the machines with this chipset for the past week so have not finished the testing, but can report that the initial tests I did involving normal use, jumbo frames, v4 and v6 etc. all worked fine and throughput was good. Once I have done a thorough test of the NIC I will post a report here. 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, May 04, 2011 at 06:14:58PM +0100, Paul Thornton wrote: On 04/05/2011 18:05, YongHyeon PYUN wrote: FYI: Committed to HEAD(r221445). I've been away from the machines with this chipset for the past week so have not finished the testing, but can report that the initial tests I did involving normal use, jumbo frames, v4 and v6 etc. all worked fine and throughput was good. I tested it with both 57765X and 57785X. All seems to work as expected. Jumbo frame performance also looks very good. Once I have done a thorough test of the NIC I will post a report here. Ok, thanks in advance. 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 Sat, Apr 23, 2011 at 04:29:16PM +0100, Paul Thornton wrote: Hi, Good news - I have success! Glad to hear that. On 20/04/2011 18:18, YongHyeon PYUN wrote: 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 problem is definitely with the interrupts. I saw nothing for bge in vmstat with MSI enabled. Rebooting with MSI disabled and all works well so far - I haven't done a lot of testing yet, but it has been operating with pings / file transfers for over 1 hour now without problems. Apologies for asking such a basic question, but I've typically downloaded latest sources etc. from HEAD via cvsweb in the past when I needed them. How do I locate the r219737 and r219740 changes on their own to try them out with MSI enabled? I'm guessing I'll need to cvsup the relevant sources but I can't see how to find out what I need. SVN: http://svnweb.freebsd.org/base/head/sys/dev/pci/pci.c?r1=219737r2=219736view=patch http://svnweb.freebsd.org/base/head/sys/dev/pci/pcivar.h?r1=219737r2=219736view=patch http://svnweb.freebsd.org/base/head/sys/dev/pci/pci.c?r1=219740r2=219737view=patch OR CVS: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c.diff?r1=1.413;r2=1.414;f=h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pcivar.h.diff?r1=1.88;r2=1.89;f=h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c.diff?r1=1.414;r2=1.415;f=h Apply them and remove an entry in loader.conf that disables MSI. 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 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x408e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1780576256 (1698 MB) ACPI APIC Table: APPLE Apple00 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 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: APPLE Apple00 on motherboard acpi0: [ITHREAD] acpi_ec0: Embedded Controller: GPE 0x57, ECDT port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) unknown: I/O range not supported acpi_hpet0: High Precision Event Timer 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: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory, RAM at device 0.1 (no driver attached) pci0: memory, RAM at device 1.0 (no driver attached) pci0: memory, RAM at device 1.1 (no driver attached) pci0: memory, RAM at device 1.2 (no driver attached) pci0: memory, RAM at device 1.3 (no driver attached) pci0: memory, RAM at device 2.0 (no driver attached) pci0: memory, RAM at device 2.1 (no driver attached) isab0: PCI-ISA bridge port 0x2100-0x21ff at device 3.0 on pci0 isa0: ISA bus on isab0 pci0: memory, RAM at device 3.1 (no driver attached) pci0: serial bus, SMBus at device 3.2 (no driver attached) pci0: memory, RAM at device 3.3 (no driver attached) pci0: processor at device 3.4 (no driver attached) ohci0: OHCI (generic) USB controller mem 0x9358a000-0x9358afff irq 18 at device 4.0 on pci0 ohci0: [ITHREAD] usbus0: OHCI (generic) USB controller on ohci0 ehci0: EHCI (generic) USB 2.0 controller mem 0x9358b100-0x9358b1ff irq 19 at device 4.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.10 usbus1: EHCI (generic) USB 2.0 controller on ehci0 ohci1: OHCI (generic) USB controller mem
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: Broadcom unknown BCM57765, ASIC rev. 0x57785000 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: MII bus on bge0 ukphy0: Generic IEEE 802.3u media interface 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: Broadcom unknown BCM57765, ASIC rev. 0x57785000 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: MII bus on bge0 ukphy0: Generic IEEE 802.3u media interface 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: Broadcom unknown BCM57765, ASIC rev. 0x57785000 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: MII bus on bge0
ukphy0: Generic IEEE 802.3u media interface 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
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: Broadcom unknown BCM57765, ASIC rev. 0x57785000 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: MII bus on bge0 brgphy0: BCM57785 10/100/1000baseTX PHY 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 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: Broadcom unknown BCM57765, ASIC rev. 0x57785000 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: MII bus on bge0 brgphy0: BCM57785 10/100/1000baseTX PHY 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
Broadcom BCM57765 support?
Hi, The bge driver doesn't support this chipset yet and I was wondering if anyone has looked at implementing it. NetBSD looks like it has support for it. Now I may be wrong here, but it appears that the BCM57765 is similar to other devices based on the NetBSD if_bge.c source version 1.194. I've tried applying the NetBSD changes to the FreeBSD bge source but I don't know enough about the hardware and the code is different enough that I haven't made it very far. I can get a patched 8.2 kernel to detect the device, complain that the ASIC is unknown, read the MAC address correctly and determine there is link but as soon as you attempt to ifconfig up the interface the machine locks up. I'm happy to try and port this over but need a nudge in the right direction from someone who knows the code. 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 Tue, Apr 19, 2011 at 07:48:51PM +0100, Paul Thornton wrote:
Hi,
The bge driver doesn't support this chipset yet and I was wondering if
anyone has looked at implementing it.
NetBSD looks like it has support for it. Now I may be wrong here, but
it appears that the BCM57765 is similar to other devices based on the
NetBSD if_bge.c source version 1.194.
I've tried applying the NetBSD changes to the FreeBSD bge source but I
don't know enough about the hardware and the code is different enough
that I haven't made it very far. I can get a patched 8.2 kernel to
detect the device, complain that the ASIC is unknown, read the MAC
address correctly and determine there is link but as soon as you attempt
to ifconfig up the interface the machine locks up.
I'm happy to try and port this over but need a nudge in the right
direction from someone who knows the code.
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.
Also it would good to see the output of pciconf -lcbv and dmesg
after applying the patch.
Index: sys/dev/bge/if_bgereg.h
===
--- sys/dev/bge/if_bgereg.h (revision 220872)
+++ sys/dev/bge/if_bgereg.h (working copy)
@@ -223,6 +223,7 @@
#define BGE_PCI_ISR_MBX_LO 0xB4
#define BGE_PCI_PRODID_ASICREV 0xBC
#define BGE_PCI_GEN2_PRODID_ASICREV 0xF4
+#define BGE_PCI_GEN15_PRODID_ASICREV 0xFC
/* PCI Misc. Host control register */
#define BGE_PCIMISCCTL_CLEAR_INTA 0x0001
@@ -318,6 +319,7 @@
#define BGE_CHIPID_BCM57780_A1 0x57780001
#define BGE_CHIPID_BCM5717_A0 0x05717000
#define BGE_CHIPID_BCM5717_B0 0x05717100
+#define BGE_CHIPID_BCM57765_A0 0x57785000
/* shorthand one */
#define BGE_ASICREV(x) ((x) 12)
@@ -342,6 +344,7 @@
#define BGE_ASICREV_BCM5761 0x5761
#define BGE_ASICREV_BCM5784 0x5784
#define BGE_ASICREV_BCM5785 0x5785
+#define BGE_ASICREV_BCM57765 0x57785
#define BGE_ASICREV_BCM57780 0x57780
/* chip revisions */
@@ -381,6 +384,8 @@
#define BGE_PCIDMARWCTL_RD_CMD_SHIFT(x) ((x) 24)
#define BGE_PCIDMARWCTL_WR_CMD_SHIFT(x) ((x) 28)
+#define BGE_PCIDMARWCTL_CRDRDR_RDMA_MRRS_MSK 0x0380
+
#define BGE_PCI_READ_BNDRY_DISABLE 0x
#define BGE_PCI_READ_BNDRY_16BYTES 0x0100
#define BGE_PCI_READ_BNDRY_32BYTES 0x0200
@@ -2298,9 +2303,15 @@
#define BCOM_DEVICEID_BCM5906 0x1712
#define BCOM_DEVICEID_BCM5906M 0x1713
#define BCOM_DEVICEID_BCM57760 0x1690
+#define BCOM_DEVICEID_BCM57761 0x16B0
+#define BCOM_DEVICEID_BCM57765 0x16B4
#define BCOM_DEVICEID_BCM57780 0x1692
+#define BCOM_DEVICEID_BCM57781 0x16B1
+#define BCOM_DEVICEID_BCM57785 0x16B5
#define BCOM_DEVICEID_BCM57788 0x1691
#define BCOM_DEVICEID_BCM57790 0x1694
+#define BCOM_DEVICEID_BCM57791 0x16B2
+#define BCOM_DEVICEID_BCM57795 0x16B6
/*
* Alteon AceNIC PCI vendor/device ID.
Index: sys/dev/bge/if_bge.c
===
--- sys/dev/bge/if_bge.c (revision 220872)
+++ sys/dev/bge/if_bge.c (working copy)
@@ -214,9 +214,15 @@
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5906 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5906M },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57760 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57761 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57765 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57780 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57781 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57785 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57788 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57790 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57791 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57795 },
{ SK_VENDORID, SK_DEVICEID_ALTIMA },
@@ -335,6 +341,7 @@
/* 5754 and 5787 share the same ASIC ID */
{ BGE_ASICREV_BCM5787, unknown BCM5754/5787 },
{ BGE_ASICREV_BCM5906, unknown BCM5906 },
+ { BGE_ASICREV_BCM57765, unknown BCM57765 },
{ BGE_ASICREV_BCM57780, unknown BCM57780 },
{ BGE_ASICREV_BCM5717, unknown BCM5717 },
@@ -1467,8 +1474,11 @@
if (sc-bge_asicrev == BGE_ASICREV_BCM5703 ||
sc-bge_asicrev == BGE_ASICREV_BCM5704)
dma_rw_ctl = ~BGE_PCIDMARWCTL_MINDMA;
- if (BGE_IS_5717_PLUS(sc))
+ if (BGE_IS_5717_PLUS(sc)) {
dma_rw_ctl = ~BGE_PCIDMARWCTL_DIS_CACHE_ALIGNMENT;
+ if (sc-bge_chipid == BGE_CHIPID_BCM57765_A0)
+ dma_rw_ctl = ~BGE_PCIDMARWCTL_CRDRDR_RDMA_MRRS_MSK;
+ }
pci_write_config(sc-bge_dev, BGE_PCI_DMA_RW_CTL, dma_rw_ctl, 4);
/*
@@ -1552,7 +1562,8 @@
}
/* Configure mbuf pool watermarks */
- if (sc-bge_asicrev == BGE_ASICREV_BCM5717) {
+ if (sc-bge_asicrev == BGE_ASICREV_BCM5717 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM57765) {
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
if (sc-bge_ifp-if_mtu ETHERMTU) {
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x7e);
@@ -1819,7 +1830,8 @@
limit = 16;
