Re: bge on the new Mac Mini
On Thu, Nov 29, 2012 at 08:14:12AM -0500, Richard Kuhns wrote: > On 11/28/12 19:08, YongHyeon PYUN wrote: > > On Wed, Nov 28, 2012 at 10:12:05AM -0500, Richard Kuhns wrote: > >> On 11/27/12 19:19, YongHyeon PYUN wrote: > >>> On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: > On 11/27/12 00:24, YongHyeon PYUN wrote: > > On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: > >> On 11/21/12 21:08, YongHyeon PYUN wrote: > >>> On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: > On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: > > On 11/20/12 03:52, YongHyeon PYUN wrote: > >> On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > >>> Hi all, > >>> > >>> Over the last month or so I've installed FreeBSD 9 (-stable) on > >>> several Mac > >>> Minis via the memstick image; they seem to be pretty good little > >>> boxes for > >>> things like offsite secondary nameservers, for example, and > >>> they're easily > >>> replaced in case of problems. > >>> > >>> However, the newest minis have slightly different hardware, and > >>> FreeBSD can't > >>> find the built-in NIC. pciconf -lv on the new mini shows it as > >>> > >>> none3@pci0:1:0:0: class=0x02 card=0x168614e4 > >>> chip=0x168614e4 rev=0x01 > >> > >> It seems this controller is BCM57766. > >> > >>> hdr=0x00 > >>> vendor = 'Broadcom Corporation' > >>> class = network > >>> subclass = ethernet > >>> > >>> The previous edition mini (that works) reports > >>> > >>> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 > >>> rev=0x10 hdr=0x00 > >>> vendor = 'Broadcom Corporation' > >>> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > >>> class = network > >>> subclass = ethernet > >>> > >>> Is there a chance that adding the new card/chip info to the > >>> current driver would > >>> allow it to work? I'll be happy to test and report back. I'm > >>> afraid I'm not > >>> familiar enough with hardware at that level to figure out the > >>> patch myself. > >>> > >> > >> Try attached patch and let me know whether the patch works or not. > >> If the patch works please share dmesg output(bge(4) and brgphy(4) > >> output only). > >> Note, the patch was generated against CURRENT. > >> > > > > I'm afraid it didn't help. I ended up grabbing if_bge.c and > > if_bgereg.h from > > I guess you also need to copy brgphy.c from HEAD to > /usr/src/sys/dev/mii directory. > > > HEAD using svnweb.freebsd.org. The patch installed cleanly and > > there were no > > errors during the build, but still no NIC. > > Does it mean you're not seeing bge0 interface? Or you can't pass > any traffic via bge0? > >>> > >>> Oops, it seems I've not included your device ID in the diff. > >>> Try attach one instead. Make sure you use brgphy.c from HEAD. > >>> > >> > >> There's progress! With your latest patch using brgphy.c, if_bge.c, and > >> if_bgereg.h from head I'm now seeing the bge0 interface. > >> Unfortunately, the > >> moment I try to configure it the box locks up completely; it won't > >> even toggle > >> the caps lock LED. > >> > >> Booting single user and running ifconfig shows: > >> > >> bge0: flags=8802 metric 0 mtu 1500 > >> options=8009b > >>ether a8:20:66:11:3b:d6 > >>nd6 options=21 > >>media: Ethernet autoselect (1000baseT ) > >>status: active > >> > >> I did a verbose boot; here's the part that seems to be relevant to > >> bge0: > >> > >> bge0: >> 0x57766001> mem > >> 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on > >> pci1 > >> bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E > > ^ > > > > All these information are garbage which indicates a bug in the diff. > > > >> miibus0: on bge0 > >> brgphy0: PHY 1 on miibus0 > >> brgphy0: OUI 0x001be9, model 0x0024, rev. 1 > >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > >> bge0: bpf attached > >> bge0: Ethernet address: a8:20:66:11:3b:d6 > >> ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 > >> > >> I greatly appreciate your efforts. I'm sorry for the delay getting > >>>
Re: bge on the new Mac Mini
On 11/28/12 19:08, YongHyeon PYUN wrote: > On Wed, Nov 28, 2012 at 10:12:05AM -0500, Richard Kuhns wrote: >> On 11/27/12 19:19, YongHyeon PYUN wrote: >>> On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: On 11/27/12 00:24, YongHyeon PYUN wrote: > On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: >> On 11/21/12 21:08, YongHyeon PYUN wrote: >>> On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: > On 11/20/12 03:52, YongHyeon PYUN wrote: >> On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: >>> Hi all, >>> >>> Over the last month or so I've installed FreeBSD 9 (-stable) on >>> several Mac >>> Minis via the memstick image; they seem to be pretty good little >>> boxes for >>> things like offsite secondary nameservers, for example, and they're >>> easily >>> replaced in case of problems. >>> >>> However, the newest minis have slightly different hardware, and >>> FreeBSD can't >>> find the built-in NIC. pciconf -lv on the new mini shows it as >>> >>> none3@pci0:1:0:0: class=0x02 card=0x168614e4 >>> chip=0x168614e4 rev=0x01 >> >> It seems this controller is BCM57766. >> >>> hdr=0x00 >>> vendor = 'Broadcom Corporation' >>> class = network >>> subclass = ethernet >>> >>> The previous edition mini (that works) reports >>> >>> bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 >>> rev=0x10 hdr=0x00 >>> vendor = 'Broadcom Corporation' >>> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' >>> class = network >>> subclass = ethernet >>> >>> Is there a chance that adding the new card/chip info to the current >>> driver would >>> allow it to work? I'll be happy to test and report back. I'm afraid >>> I'm not >>> familiar enough with hardware at that level to figure out the patch >>> myself. >>> >> >> Try attached patch and let me know whether the patch works or not. >> If the patch works please share dmesg output(bge(4) and brgphy(4) >> output only). >> Note, the patch was generated against CURRENT. >> > > I'm afraid it didn't help. I ended up grabbing if_bge.c and > if_bgereg.h from I guess you also need to copy brgphy.c from HEAD to /usr/src/sys/dev/mii directory. > HEAD using svnweb.freebsd.org. The patch installed cleanly and there > were no > errors during the build, but still no NIC. Does it mean you're not seeing bge0 interface? Or you can't pass any traffic via bge0? >>> >>> Oops, it seems I've not included your device ID in the diff. >>> Try attach one instead. Make sure you use brgphy.c from HEAD. >>> >> >> There's progress! With your latest patch using brgphy.c, if_bge.c, and >> if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, >> the >> moment I try to configure it the box locks up completely; it won't even >> toggle >> the caps lock LED. >> >> Booting single user and running ifconfig shows: >> >> bge0: flags=8802 metric 0 mtu 1500 >> options=8009b >> ether a8:20:66:11:3b:d6 >> nd6 options=21 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> I did a verbose boot; here's the part that seems to be relevant to bge0: >> >> bge0: > 0x57766001> mem >> 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 >> bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E > ^ > > All these information are garbage which indicates a bug in the diff. > >> miibus0: on bge0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: OUI 0x001be9, model 0x0024, rev. 1 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> bge0: bpf attached >> bge0: Ethernet address: a8:20:66:11:3b:d6 >> ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 >> >> I greatly appreciate your efforts. I'm sorry for the delay getting back >> with >> you, but we had a busy Thanksgiving weekend. >> > > Try again with attached bge.57766.diff3. > Thanks for testing! > I don't think the patch actually got attached :-( >>> >>> Oops, attached. >>> >> >> And there was great rejoicing... >> >> It seems to take longer than I'm used
Re: bge on the new Mac Mini
On Wed, Nov 28, 2012 at 10:12:05AM -0500, Richard Kuhns wrote: > On 11/27/12 19:19, YongHyeon PYUN wrote: > > On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: > >> On 11/27/12 00:24, YongHyeon PYUN wrote: > >>> On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: > On 11/21/12 21:08, YongHyeon PYUN wrote: > > On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: > >> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: > >>> On 11/20/12 03:52, YongHyeon PYUN wrote: > On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > > Hi all, > > > > Over the last month or so I've installed FreeBSD 9 (-stable) on > > several Mac > > Minis via the memstick image; they seem to be pretty good little > > boxes for > > things like offsite secondary nameservers, for example, and they're > > easily > > replaced in case of problems. > > > > However, the newest minis have slightly different hardware, and > > FreeBSD can't > > find the built-in NIC. pciconf -lv on the new mini shows it as > > > > none3@pci0:1:0:0: class=0x02 card=0x168614e4 > > chip=0x168614e4 rev=0x01 > > It seems this controller is BCM57766. > > > hdr=0x00 > > vendor = 'Broadcom Corporation' > > class = network > > subclass = ethernet > > > > The previous edition mini (that works) reports > > > > bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 > > rev=0x10 hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > > class = network > > subclass = ethernet > > > > Is there a chance that adding the new card/chip info to the current > > driver would > > allow it to work? I'll be happy to test and report back. I'm afraid > > I'm not > > familiar enough with hardware at that level to figure out the patch > > myself. > > > > Try attached patch and let me know whether the patch works or not. > If the patch works please share dmesg output(bge(4) and brgphy(4) > output only). > Note, the patch was generated against CURRENT. > > >>> > >>> I'm afraid it didn't help. I ended up grabbing if_bge.c and > >>> if_bgereg.h from > >> > >> I guess you also need to copy brgphy.c from HEAD to > >> /usr/src/sys/dev/mii directory. > >> > >>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there > >>> were no > >>> errors during the build, but still no NIC. > >> > >> Does it mean you're not seeing bge0 interface? Or you can't pass > >> any traffic via bge0? > > > > Oops, it seems I've not included your device ID in the diff. > > Try attach one instead. Make sure you use brgphy.c from HEAD. > > > > There's progress! With your latest patch using brgphy.c, if_bge.c, and > if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, > the > moment I try to configure it the box locks up completely; it won't even > toggle > the caps lock LED. > > Booting single user and running ifconfig shows: > > bge0: flags=8802 metric 0 mtu 1500 > options=8009b > ether a8:20:66:11:3b:d6 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > I did a verbose boot; here's the part that seems to be relevant to bge0: > > bge0: 0x57766001> mem > 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 > bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E > >>> ^ > >>> > >>> All these information are garbage which indicates a bug in the diff. > >>> > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: OUI 0x001be9, model 0x0024, rev. 1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: a8:20:66:11:3b:d6 > ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 > > I greatly appreciate your efforts. I'm sorry for the delay getting back > with > you, but we had a busy Thanksgiving weekend. > > >>> > >>> Try again with attached bge.57766.diff3. > >>> Thanks for testing! > >>> > >> > >> I don't think the patch actually got attached :-( > > > > Oops, attached. > > > > And there was great rejoicing... > > It seems to take longer than I'm used to for it to decide it has link (about > hal
Re: bge on the new Mac Mini
On 11/27/12 19:19, YongHyeon PYUN wrote: > On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: >> On 11/27/12 00:24, YongHyeon PYUN wrote: >>> On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: On 11/21/12 21:08, YongHyeon PYUN wrote: > On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: >> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: >>> On 11/20/12 03:52, YongHyeon PYUN wrote: On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > Hi all, > > Over the last month or so I've installed FreeBSD 9 (-stable) on > several Mac > Minis via the memstick image; they seem to be pretty good little > boxes for > things like offsite secondary nameservers, for example, and they're > easily > replaced in case of problems. > > However, the newest minis have slightly different hardware, and > FreeBSD can't > find the built-in NIC. pciconf -lv on the new mini shows it as > > none3@pci0:1:0:0: class=0x02 card=0x168614e4 > chip=0x168614e4 rev=0x01 It seems this controller is BCM57766. > hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet > > The previous edition mini (that works) reports > > bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 > rev=0x10 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > class = network > subclass = ethernet > > Is there a chance that adding the new card/chip info to the current > driver would > allow it to work? I'll be happy to test and report back. I'm afraid > I'm not > familiar enough with hardware at that level to figure out the patch > myself. > Try attached patch and let me know whether the patch works or not. If the patch works please share dmesg output(bge(4) and brgphy(4) output only). Note, the patch was generated against CURRENT. >>> >>> I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h >>> from >> >> I guess you also need to copy brgphy.c from HEAD to >> /usr/src/sys/dev/mii directory. >> >>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there >>> were no >>> errors during the build, but still no NIC. >> >> Does it mean you're not seeing bge0 interface? Or you can't pass >> any traffic via bge0? > > Oops, it seems I've not included your device ID in the diff. > Try attach one instead. Make sure you use brgphy.c from HEAD. > There's progress! With your latest patch using brgphy.c, if_bge.c, and if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the moment I try to configure it the box locks up completely; it won't even toggle the caps lock LED. Booting single user and running ifconfig shows: bge0: flags=8802 metric 0 mtu 1500 options=8009b ether a8:20:66:11:3b:d6 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active I did a verbose boot; here's the part that seems to be relevant to bge0: bge0: >>> 0x57766001> mem 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E >>> ^ >>> >>> All these information are garbage which indicates a bug in the diff. >>> miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: a8:20:66:11:3b:d6 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 I greatly appreciate your efforts. I'm sorry for the delay getting back with you, but we had a busy Thanksgiving weekend. >>> >>> Try again with attached bge.57766.diff3. >>> Thanks for testing! >>> >> >> I don't think the patch actually got attached :-( > > Oops, attached. > And there was great rejoicing... It seems to take longer than I'm used to for it to decide it has link (about halfway through 'waiting for the default route interface'), but it works! I've just installed subversion, and I'm doing an 'svn co' of stable/9. Many thanks for the work you've done! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6t
Re: bge on the new Mac Mini
On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: > On 11/27/12 00:24, YongHyeon PYUN wrote: > > On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: > >> On 11/21/12 21:08, YongHyeon PYUN wrote: > >>> On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: > On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: > > On 11/20/12 03:52, YongHyeon PYUN wrote: > >> On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > >>> Hi all, > >>> > >>> Over the last month or so I've installed FreeBSD 9 (-stable) on > >>> several Mac > >>> Minis via the memstick image; they seem to be pretty good little > >>> boxes for > >>> things like offsite secondary nameservers, for example, and they're > >>> easily > >>> replaced in case of problems. > >>> > >>> However, the newest minis have slightly different hardware, and > >>> FreeBSD can't > >>> find the built-in NIC. pciconf -lv on the new mini shows it as > >>> > >>> none3@pci0:1:0:0: class=0x02 card=0x168614e4 > >>> chip=0x168614e4 rev=0x01 > >> > >> It seems this controller is BCM57766. > >> > >>> hdr=0x00 > >>> vendor = 'Broadcom Corporation' > >>> class = network > >>> subclass = ethernet > >>> > >>> The previous edition mini (that works) reports > >>> > >>> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 > >>> rev=0x10 hdr=0x00 > >>> vendor = 'Broadcom Corporation' > >>> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > >>> class = network > >>> subclass = ethernet > >>> > >>> Is there a chance that adding the new card/chip info to the current > >>> driver would > >>> allow it to work? I'll be happy to test and report back. I'm afraid > >>> I'm not > >>> familiar enough with hardware at that level to figure out the patch > >>> myself. > >>> > >> > >> Try attached patch and let me know whether the patch works or not. > >> If the patch works please share dmesg output(bge(4) and brgphy(4) > >> output only). > >> Note, the patch was generated against CURRENT. > >> > > > > I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h > > from > > I guess you also need to copy brgphy.c from HEAD to > /usr/src/sys/dev/mii directory. > > > HEAD using svnweb.freebsd.org. The patch installed cleanly and there > > were no > > errors during the build, but still no NIC. > > Does it mean you're not seeing bge0 interface? Or you can't pass > any traffic via bge0? > >>> > >>> Oops, it seems I've not included your device ID in the diff. > >>> Try attach one instead. Make sure you use brgphy.c from HEAD. > >>> > >> > >> There's progress! With your latest patch using brgphy.c, if_bge.c, and > >> if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the > >> moment I try to configure it the box locks up completely; it won't even > >> toggle > >> the caps lock LED. > >> > >> Booting single user and running ifconfig shows: > >> > >> bge0: flags=8802 metric 0 mtu 1500 > >> options=8009b > >>ether a8:20:66:11:3b:d6 > >>nd6 options=21 > >>media: Ethernet autoselect (1000baseT ) > >>status: active > >> > >> I did a verbose boot; here's the part that seems to be relevant to bge0: > >> > >> bge0: >> 0x57766001> mem > >> 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 > >> bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E > > ^ > > > > All these information are garbage which indicates a bug in the diff. > > > >> miibus0: on bge0 > >> brgphy0: PHY 1 on miibus0 > >> brgphy0: OUI 0x001be9, model 0x0024, rev. 1 > >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > >> bge0: bpf attached > >> bge0: Ethernet address: a8:20:66:11:3b:d6 > >> ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 > >> > >> I greatly appreciate your efforts. I'm sorry for the delay getting back > >> with > >> you, but we had a busy Thanksgiving weekend. > >> > > > > Try again with attached bge.57766.diff3. > > Thanks for testing! > > > > I don't think the patch actually got attached :-( Oops, attached. Index: sys/dev/bge/if_bgereg.h === --- sys/dev/bge/if_bgereg.h (revision 243552) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -360,6 +360,7 @@ #defineBGE_ASICREV_BCM5784 0x5784 #defineBGE_ASICREV_BCM5785 0x5785 #defineBGE_ASICREV_BCM577650x57785 +#defineBGE_ASICREV_BCM577660x57766 #defineBGE_ASICREV_BCM57780
Re: bge on the new Mac Mini
On 11/27/12 00:24, YongHyeon PYUN wrote: > On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: >> On 11/21/12 21:08, YongHyeon PYUN wrote: >>> On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: > On 11/20/12 03:52, YongHyeon PYUN wrote: >> On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: >>> Hi all, >>> >>> Over the last month or so I've installed FreeBSD 9 (-stable) on several >>> Mac >>> Minis via the memstick image; they seem to be pretty good little boxes >>> for >>> things like offsite secondary nameservers, for example, and they're >>> easily >>> replaced in case of problems. >>> >>> However, the newest minis have slightly different hardware, and FreeBSD >>> can't >>> find the built-in NIC. pciconf -lv on the new mini shows it as >>> >>> none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 >>> rev=0x01 >> >> It seems this controller is BCM57766. >> >>> hdr=0x00 >>> vendor = 'Broadcom Corporation' >>> class = network >>> subclass = ethernet >>> >>> The previous edition mini (that works) reports >>> >>> bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 >>> rev=0x10 hdr=0x00 >>> vendor = 'Broadcom Corporation' >>> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' >>> class = network >>> subclass = ethernet >>> >>> Is there a chance that adding the new card/chip info to the current >>> driver would >>> allow it to work? I'll be happy to test and report back. I'm afraid I'm >>> not >>> familiar enough with hardware at that level to figure out the patch >>> myself. >>> >> >> Try attached patch and let me know whether the patch works or not. >> If the patch works please share dmesg output(bge(4) and brgphy(4) >> output only). >> Note, the patch was generated against CURRENT. >> > > I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h > from I guess you also need to copy brgphy.c from HEAD to /usr/src/sys/dev/mii directory. > HEAD using svnweb.freebsd.org. The patch installed cleanly and there were > no > errors during the build, but still no NIC. Does it mean you're not seeing bge0 interface? Or you can't pass any traffic via bge0? >>> >>> Oops, it seems I've not included your device ID in the diff. >>> Try attach one instead. Make sure you use brgphy.c from HEAD. >>> >> >> There's progress! With your latest patch using brgphy.c, if_bge.c, and >> if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the >> moment I try to configure it the box locks up completely; it won't even >> toggle >> the caps lock LED. >> >> Booting single user and running ifconfig shows: >> >> bge0: flags=8802 metric 0 mtu 1500 >> options=8009b >> ether a8:20:66:11:3b:d6 >> nd6 options=21 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> I did a verbose boot; here's the part that seems to be relevant to bge0: >> >> bge0: >> mem >> 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 >> bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E > ^ > > All these information are garbage which indicates a bug in the diff. > >> miibus0: on bge0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: OUI 0x001be9, model 0x0024, rev. 1 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> bge0: bpf attached >> bge0: Ethernet address: a8:20:66:11:3b:d6 >> ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 >> >> I greatly appreciate your efforts. I'm sorry for the delay getting back with >> you, but we had a busy Thanksgiving weekend. >> > > Try again with attached bge.57766.diff3. > Thanks for testing! > I don't think the patch actually got attached :-( -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: > On 11/21/12 21:08, YongHyeon PYUN wrote: > > On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: > >> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: > >>> On 11/20/12 03:52, YongHyeon PYUN wrote: > On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > > Hi all, > > > > Over the last month or so I've installed FreeBSD 9 (-stable) on several > > Mac > > Minis via the memstick image; they seem to be pretty good little boxes > > for > > things like offsite secondary nameservers, for example, and they're > > easily > > replaced in case of problems. > > > > However, the newest minis have slightly different hardware, and FreeBSD > > can't > > find the built-in NIC. pciconf -lv on the new mini shows it as > > > > none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 > > rev=0x01 > > It seems this controller is BCM57766. > > > hdr=0x00 > > vendor = 'Broadcom Corporation' > > class = network > > subclass = ethernet > > > > The previous edition mini (that works) reports > > > > bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 > > rev=0x10 hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > > class = network > > subclass = ethernet > > > > Is there a chance that adding the new card/chip info to the current > > driver would > > allow it to work? I'll be happy to test and report back. I'm afraid I'm > > not > > familiar enough with hardware at that level to figure out the patch > > myself. > > > > Try attached patch and let me know whether the patch works or not. > If the patch works please share dmesg output(bge(4) and brgphy(4) > output only). > Note, the patch was generated against CURRENT. > > >>> > >>> I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h > >>> from > >> > >> I guess you also need to copy brgphy.c from HEAD to > >> /usr/src/sys/dev/mii directory. > >> > >>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there were > >>> no > >>> errors during the build, but still no NIC. > >> > >> Does it mean you're not seeing bge0 interface? Or you can't pass > >> any traffic via bge0? > > > > Oops, it seems I've not included your device ID in the diff. > > Try attach one instead. Make sure you use brgphy.c from HEAD. > > > > There's progress! With your latest patch using brgphy.c, if_bge.c, and > if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the > moment I try to configure it the box locks up completely; it won't even toggle > the caps lock LED. > > Booting single user and running ifconfig shows: > > bge0: flags=8802 metric 0 mtu 1500 > options=8009b > ether a8:20:66:11:3b:d6 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > I did a verbose boot; here's the part that seems to be relevant to bge0: > > bge0: > mem > 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 > bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E ^ All these information are garbage which indicates a bug in the diff. > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: OUI 0x001be9, model 0x0024, rev. 1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: a8:20:66:11:3b:d6 > ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 > > I greatly appreciate your efforts. I'm sorry for the delay getting back with > you, but we had a busy Thanksgiving weekend. > Try again with attached bge.57766.diff3. Thanks for testing! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On 11/21/12 21:08, YongHyeon PYUN wrote: > On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: >> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: >>> On 11/20/12 03:52, YongHyeon PYUN wrote: On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > Hi all, > > Over the last month or so I've installed FreeBSD 9 (-stable) on several > Mac > Minis via the memstick image; they seem to be pretty good little boxes for > things like offsite secondary nameservers, for example, and they're easily > replaced in case of problems. > > However, the newest minis have slightly different hardware, and FreeBSD > can't > find the built-in NIC. pciconf -lv on the new mini shows it as > > none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 > rev=0x01 It seems this controller is BCM57766. > hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet > > The previous edition mini (that works) reports > > bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > class = network > subclass = ethernet > > Is there a chance that adding the new card/chip info to the current > driver would > allow it to work? I'll be happy to test and report back. I'm afraid I'm > not > familiar enough with hardware at that level to figure out the patch > myself. > Try attached patch and let me know whether the patch works or not. If the patch works please share dmesg output(bge(4) and brgphy(4) output only). Note, the patch was generated against CURRENT. >>> >>> I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from >> >> I guess you also need to copy brgphy.c from HEAD to >> /usr/src/sys/dev/mii directory. >> >>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no >>> errors during the build, but still no NIC. >> >> Does it mean you're not seeing bge0 interface? Or you can't pass >> any traffic via bge0? > > Oops, it seems I've not included your device ID in the diff. > Try attach one instead. Make sure you use brgphy.c from HEAD. > There's progress! With your latest patch using brgphy.c, if_bge.c, and if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the moment I try to configure it the box locks up completely; it won't even toggle the caps lock LED. Booting single user and running ifconfig shows: bge0: flags=8802 metric 0 mtu 1500 options=8009b ether a8:20:66:11:3b:d6 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active I did a verbose boot; here's the part that seems to be relevant to bge0: bge0: mem 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: a8:20:66:11:3b:d6 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 I greatly appreciate your efforts. I'm sorry for the delay getting back with you, but we had a busy Thanksgiving weekend. Thank you! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote:
> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote:
> > On 11/20/12 03:52, YongHyeon PYUN wrote:
> > > On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote:
> > >> Hi all,
> > >>
> > >> Over the last month or so I've installed FreeBSD 9 (-stable) on several
> > >> Mac
> > >> Minis via the memstick image; they seem to be pretty good little boxes
> > >> for
> > >> things like offsite secondary nameservers, for example, and they're
> > >> easily
> > >> replaced in case of problems.
> > >>
> > >> However, the newest minis have slightly different hardware, and FreeBSD
> > >> can't
> > >> find the built-in NIC. pciconf -lv on the new mini shows it as
> > >>
> > >> none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4
> > >> rev=0x01
> > >
> > > It seems this controller is BCM57766.
> > >
> > >> hdr=0x00
> > >> vendor = 'Broadcom Corporation'
> > >> class = network
> > >> subclass = ethernet
> > >>
> > >> The previous edition mini (that works) reports
> > >>
> > >> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10
> > >> hdr=0x00
> > >> vendor = 'Broadcom Corporation'
> > >> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe'
> > >> class = network
> > >> subclass = ethernet
> > >>
> > >> Is there a chance that adding the new card/chip info to the current
> > >> driver would
> > >> allow it to work? I'll be happy to test and report back. I'm afraid I'm
> > >> not
> > >> familiar enough with hardware at that level to figure out the patch
> > >> myself.
> > >>
> > >
> > > Try attached patch and let me know whether the patch works or not.
> > > If the patch works please share dmesg output(bge(4) and brgphy(4)
> > > output only).
> > > Note, the patch was generated against CURRENT.
> > >
> >
> > I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from
>
> I guess you also need to copy brgphy.c from HEAD to
> /usr/src/sys/dev/mii directory.
>
> > HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no
> > errors during the build, but still no NIC.
>
> Does it mean you're not seeing bge0 interface? Or you can't pass
> any traffic via bge0?
Oops, it seems I've not included your device ID in the diff.
Try attach one instead. Make sure you use brgphy.c from HEAD.
Index: sys/dev/bge/if_bgereg.h
===
--- sys/dev/bge/if_bgereg.h (revision 243366)
+++ sys/dev/bge/if_bgereg.h (working copy)
@@ -360,6 +360,7 @@
#defineBGE_ASICREV_BCM5784 0x5784
#defineBGE_ASICREV_BCM5785 0x5785
#defineBGE_ASICREV_BCM577650x57785
+#defineBGE_ASICREV_BCM577660x57766
#defineBGE_ASICREV_BCM577800x57780
/* chip revisions */
@@ -2483,7 +2484,9 @@ struct bge_status_block {
#defineBCOM_DEVICEID_BCM5906M 0x1713
#defineBCOM_DEVICEID_BCM57760 0x1690
#defineBCOM_DEVICEID_BCM57761 0x16B0
+#defineBCOM_DEVICEID_BCM57762 0x1682
#defineBCOM_DEVICEID_BCM57765 0x16B4
+#defineBCOM_DEVICEID_BCM57766 0x1686
#defineBCOM_DEVICEID_BCM57780 0x1692
#defineBCOM_DEVICEID_BCM57781 0x16B1
#defineBCOM_DEVICEID_BCM57785 0x16B5
@@ -2961,6 +2964,7 @@ struct bge_softc {
#defineBGE_FLAG_5755_PLUS 0x0010
#defineBGE_FLAG_5788 0x0020
#defineBGE_FLAG_5717_PLUS 0x0040
+#defineBGE_FLAG_57765_PLUS 0x0080
#defineBGE_FLAG_40BIT_BUG 0x0100
#defineBGE_FLAG_4G_BNDRY_BUG 0x0200
#defineBGE_FLAG_RX_ALIGNBUG0x0400
Index: sys/dev/bge/if_bge.c
===
--- sys/dev/bge/if_bge.c(revision 243366)
+++ sys/dev/bge/if_bge.c(working copy)
@@ -216,7 +216,9 @@ static const struct bge_type {
{ BCOM_VENDORID,BCOM_DEVICEID_BCM5906M },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57760 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57761 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57762 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57765 },
+ { BCOM_VENDORID,BCOM_DEVICEID_BCM57766 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57780 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57781 },
{ BCOM_VENDORID,BCOM_DEVICEID_BCM57785 },
@@ -347,6 +349,7 @@ static const struct bge_revision bge_majorrevs[] =
{ BGE_ASICREV_BCM5787, "unknown BCM5754/5787" },
{ BGE_ASICREV_BCM5906, "unknown BCM5906" },
{ BGE_ASICREV_BCM57765, "unknown BCM57765" },
+ { BGE_ASICREV_BCM57766, "unknown BCM57766" },
{ BGE_ASICREV_BCM57
Re: bge on the new Mac Mini
On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: > On 11/20/12 03:52, YongHyeon PYUN wrote: > > On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > >> Hi all, > >> > >> Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac > >> Minis via the memstick image; they seem to be pretty good little boxes for > >> things like offsite secondary nameservers, for example, and they're easily > >> replaced in case of problems. > >> > >> However, the newest minis have slightly different hardware, and FreeBSD > >> can't > >> find the built-in NIC. pciconf -lv on the new mini shows it as > >> > >> none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 > >> rev=0x01 > > > > It seems this controller is BCM57766. > > > >> hdr=0x00 > >> vendor = 'Broadcom Corporation' > >> class = network > >> subclass = ethernet > >> > >> The previous edition mini (that works) reports > >> > >> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 > >> hdr=0x00 > >> vendor = 'Broadcom Corporation' > >> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > >> class = network > >> subclass = ethernet > >> > >> Is there a chance that adding the new card/chip info to the current driver > >> would > >> allow it to work? I'll be happy to test and report back. I'm afraid I'm not > >> familiar enough with hardware at that level to figure out the patch myself. > >> > > > > Try attached patch and let me know whether the patch works or not. > > If the patch works please share dmesg output(bge(4) and brgphy(4) > > output only). > > Note, the patch was generated against CURRENT. > > > > I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from I guess you also need to copy brgphy.c from HEAD to /usr/src/sys/dev/mii directory. > HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no > errors during the build, but still no NIC. Does it mean you're not seeing bge0 interface? Or you can't pass any traffic via bge0? > > Just to make sure you know, I've made no local modifications at all. This was > a > fresh install and I've touched nothing except for these 2 files. > > Thanks! > > -- > Richard Kuhns My Desk: 765-269-8541 > Wintek Corporation Internet Support: 765-269-8503 > 427 N 6th Street Consulting: 765-269-8504 > Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On 11/20/12 03:52, YongHyeon PYUN wrote: > On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: >> Hi all, >> >> Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac >> Minis via the memstick image; they seem to be pretty good little boxes for >> things like offsite secondary nameservers, for example, and they're easily >> replaced in case of problems. >> >> However, the newest minis have slightly different hardware, and FreeBSD can't >> find the built-in NIC. pciconf -lv on the new mini shows it as >> >> none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 >> rev=0x01 > > It seems this controller is BCM57766. > >> hdr=0x00 >> vendor = 'Broadcom Corporation' >> class = network >> subclass = ethernet >> >> The previous edition mini (that works) reports >> >> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 >> hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' >> class = network >> subclass = ethernet >> >> Is there a chance that adding the new card/chip info to the current driver >> would >> allow it to work? I'll be happy to test and report back. I'm afraid I'm not >> familiar enough with hardware at that level to figure out the patch myself. >> > > Try attached patch and let me know whether the patch works or not. > If the patch works please share dmesg output(bge(4) and brgphy(4) > output only). > Note, the patch was generated against CURRENT. > I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no errors during the build, but still no NIC. Just to make sure you know, I've made no local modifications at all. This was a fresh install and I've touched nothing except for these 2 files. Thanks! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote:
> Hi all,
>
> Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac
> Minis via the memstick image; they seem to be pretty good little boxes for
> things like offsite secondary nameservers, for example, and they're easily
> replaced in case of problems.
>
> However, the newest minis have slightly different hardware, and FreeBSD can't
> find the built-in NIC. pciconf -lv on the new mini shows it as
>
> none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4
> rev=0x01
It seems this controller is BCM57766.
> hdr=0x00
> vendor = 'Broadcom Corporation'
> class = network
> subclass = ethernet
>
> The previous edition mini (that works) reports
>
> bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10
> hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe'
> class = network
> subclass = ethernet
>
> Is there a chance that adding the new card/chip info to the current driver
> would
> allow it to work? I'll be happy to test and report back. I'm afraid I'm not
> familiar enough with hardware at that level to figure out the patch myself.
>
Try attached patch and let me know whether the patch works or not.
If the patch works please share dmesg output(bge(4) and brgphy(4)
output only).
Note, the patch was generated against CURRENT.
Index: sys/dev/bge/if_bgereg.h
===
--- sys/dev/bge/if_bgereg.h (revision 243255)
+++ sys/dev/bge/if_bgereg.h (working copy)
@@ -360,6 +360,7 @@
#define BGE_ASICREV_BCM5784 0x5784
#define BGE_ASICREV_BCM5785 0x5785
#define BGE_ASICREV_BCM57765 0x57785
+#define BGE_ASICREV_BCM57766 0x57766
#define BGE_ASICREV_BCM57780 0x57780
/* chip revisions */
@@ -2484,6 +2485,7 @@ struct bge_status_block {
#define BCOM_DEVICEID_BCM57760 0x1690
#define BCOM_DEVICEID_BCM57761 0x16B0
#define BCOM_DEVICEID_BCM57765 0x16B4
+#define BCOM_DEVICEID_BCM57766 0x1682
#define BCOM_DEVICEID_BCM57780 0x1692
#define BCOM_DEVICEID_BCM57781 0x16B1
#define BCOM_DEVICEID_BCM57785 0x16B5
@@ -2961,6 +2963,7 @@ struct bge_softc {
#define BGE_FLAG_5755_PLUS 0x0010
#define BGE_FLAG_5788 0x0020
#define BGE_FLAG_5717_PLUS 0x0040
+#define BGE_FLAG_57765_PLUS 0x0080
#define BGE_FLAG_40BIT_BUG 0x0100
#define BGE_FLAG_4G_BNDRY_BUG 0x0200
#define BGE_FLAG_RX_ALIGNBUG 0x0400
Index: sys/dev/bge/if_bge.c
===
--- sys/dev/bge/if_bge.c (revision 243255)
+++ sys/dev/bge/if_bge.c (working copy)
@@ -217,6 +217,7 @@ static const struct bge_type {
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57760 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57761 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57765 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57766 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57780 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57781 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57785 },
@@ -362,6 +363,7 @@ static const struct bge_revision bge_majorrevs[] =
#define BGE_IS_575X_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_575X_PLUS)
#define BGE_IS_5755_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_5755_PLUS)
#define BGE_IS_5717_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_5717_PLUS)
+#define BGE_IS_57765_PLUS(sc) ((sc)->bge_flags & BGE_FLAG_57765_PLUS)
const struct bge_revision * bge_lookup_rev(uint32_t);
const struct bge_vendor * bge_lookup_vendor(uint16_t);
@@ -2243,7 +2245,7 @@ bge_blockinit(struct bge_softc *sc)
} else if (!BGE_IS_5705_PLUS(sc))
limit = BGE_RX_RINGS_MAX;
else if (sc->bge_asicrev == BGE_ASICREV_BCM5755 ||
- sc->bge_asicrev == BGE_ASICREV_BCM57765)
+ BGE_IS_57765_PLUS(sc))
limit = 4;
else
limit = 1;
@@ -2658,6 +2660,7 @@ bge_probe(device_t dev)
break;
case BCOM_DEVICEID_BCM57761:
case BCOM_DEVICEID_BCM57765:
+case BCOM_DEVICEID_BCM57766:
case BCOM_DEVICEID_BCM57781:
case BCOM_DEVICEID_BCM57785:
case BCOM_DEVICEID_BCM57791:
@@ -3321,10 +3324,13 @@ bge_attach(device_t dev)
/* Save chipset family. */
switch (sc->bge_asicrev) {
+ case BGE_ASICREV_BCM57765:
+ case BGE_ASICREV_BCM57766:
+ sc->bge_flags |= BGE_FLAG_57765_PLUS;
+ /* FALLTHROUGH */
case BGE_ASICREV_BCM5717:
case BGE_ASICREV_BCM5719:
case BGE_ASICREV_BCM5720:
- case BGE_ASICREV_BCM57765:
sc->bge_flags |= BGE_FLAG_5717_PLUS | BGE_FLAG_5755_PLUS |
BGE_FLAG_575X_PLUS | BGE_FLAG_5705_PLUS | BGE_FLAG_JUMBO |
BGE_FLAG_JUMBO_FRAME;
@@ -3738,12 +3744,9 @@ bge_attach(device_t dev)
sc->bge_phy_flags |= BGE_PHY_NO_3LED;
if ((BGE_IS_5705_PLUS(sc)) &&
sc->bge_asicrev != BGE_ASICREV_BCM5906 &&
- sc->bge_asicrev != BGE_ASICREV_BCM5717 &&
- sc->bge_asicrev != BGE_ASICREV_BCM5719 &&
- sc->bge_asicrev != BGE_ASICREV_BCM5720 &&
sc->bge_asicrev != BGE_ASICREV_BCM5785 &&
- sc->bge_asicrev != BGE_ASICREV_B
Re: bge on the new Mac Mini
On 11/16/12 12:09, Gary Palmer wrote: > On Fri, Nov 16, 2012 at 11:27:17AM -0500, Richard Kuhns wrote: >> On 11/16/12 11:20, Gary Palmer wrote: >>> On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: On 11/16/12 10:41, Alfred Perlstein wrote: > Often that is all that is needed. It's worth a shot and reporting back. > > Do you know how to update the table in the driver, rebuild/install > kernel and check? > > -Alfred > I'm afraid not. I grepped for the hex value reported on the one that works (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I don't know what to add :-( I don't have any problem with rebuilding and installing a new kernel, though. >>> >>> 14e4 is the ID for Broadcom >>> 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip >>> >>> http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list >>> of the BCM PCI ID values >>> >>> There is a (frequently incomplete) database of user reported PCI values at >>> http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip >>> >>> Linux uses the tg3 driver for that chipset apparently, but I think thats >>> a general dumping ground for a lot of Broadcom products. Not sure what the >>> appropriate FreeBSD driver to add the ID code to would be. >>> >>> Regards, >>> >>> Gary >>> >> >> Sorry, I should have been more clear. I grepped for those values in >> /usr/src/sys/dev/bge/*, since that's the driver that's used on the older >> minis. >> I assume that's where the table is that Alfred mentioned; I just don't know >> what >> to add to it. >> > > The probe table appears to be bge_devs in if_bge.c. The values there are > #define'd in if_bgereg.h, but for a quick hack you just need to add the value > to the table > > Gary > Thanks, I found it. I also found that the reason I couldn't find it before was that I didn't tell grep to ignore case :-( -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On Fri, Nov 16, 2012 at 11:27:17AM -0500, Richard Kuhns wrote: > On 11/16/12 11:20, Gary Palmer wrote: > > On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: > >> On 11/16/12 10:41, Alfred Perlstein wrote: > >>> Often that is all that is needed. It's worth a shot and reporting back. > >>> > >>> Do you know how to update the table in the driver, rebuild/install > >>> kernel and check? > >>> > >>> -Alfred > >>> > >> > >> I'm afraid not. I grepped for the hex value reported on the one that works > >> (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. > >> So I > >> don't know what to add :-( > >> > >> I don't have any problem with rebuilding and installing a new kernel, > >> though. > > > > 14e4 is the ID for Broadcom > > 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip > > > > http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list > > of the BCM PCI ID values > > > > There is a (frequently incomplete) database of user reported PCI values at > > http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip > > > > Linux uses the tg3 driver for that chipset apparently, but I think thats > > a general dumping ground for a lot of Broadcom products. Not sure what the > > appropriate FreeBSD driver to add the ID code to would be. > > > > Regards, > > > > Gary > > > > Sorry, I should have been more clear. I grepped for those values in > /usr/src/sys/dev/bge/*, since that's the driver that's used on the older > minis. > I assume that's where the table is that Alfred mentioned; I just don't know > what > to add to it. > The probe table appears to be bge_devs in if_bge.c. The values there are #define'd in if_bgereg.h, but for a quick hack you just need to add the value to the table Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On 11/16/12 8:27 AM, Richard Kuhns wrote: On 11/16/12 11:20, Gary Palmer wrote: On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: On 11/16/12 10:41, Alfred Perlstein wrote: Often that is all that is needed. It's worth a shot and reporting back. Do you know how to update the table in the driver, rebuild/install kernel and check? -Alfred I'm afraid not. I grepped for the hex value reported on the one that works (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I don't know what to add :-( I don't have any problem with rebuilding and installing a new kernel, though. 14e4 is the ID for Broadcom 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list of the BCM PCI ID values There is a (frequently incomplete) database of user reported PCI values at http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip Linux uses the tg3 driver for that chipset apparently, but I think thats a general dumping ground for a lot of Broadcom products. Not sure what the appropriate FreeBSD driver to add the ID code to would be. Regards, Gary Sorry, I should have been more clear. I grepped for those values in /usr/src/sys/dev/bge/*, since that's the driver that's used on the older minis. I assume that's where the table is that Alfred mentioned; I just don't know what to add to it. Here's a cool trick you can do. 1) make a backup of your /boot/kernel directory: mv /boot/kernel /boot/kernel.good (now you can boot to a known good kernel if you blow things up) 2) hack a few drivers to add the PCI id. 3) now build a kernel WITHOUT most of the nic drivers. 4) reboot with this kernel 5) try loading/unloading the various drivers you suspect will be compatible until it either works or you get tired. :) Eventually you'll find the change that works. Go look at commit logs to see how others have added PCI ids to the drivers. It's usually in a table or under a simple "if" statement. It honestly won't take you that long, probably a few hours of head scratching. -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On 11/16/12 11:20, Gary Palmer wrote: > On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: >> On 11/16/12 10:41, Alfred Perlstein wrote: >>> Often that is all that is needed. It's worth a shot and reporting back. >>> >>> Do you know how to update the table in the driver, rebuild/install >>> kernel and check? >>> >>> -Alfred >>> >> >> I'm afraid not. I grepped for the hex value reported on the one that works >> (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So >> I >> don't know what to add :-( >> >> I don't have any problem with rebuilding and installing a new kernel, though. > > 14e4 is the ID for Broadcom > 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip > > http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list > of the BCM PCI ID values > > There is a (frequently incomplete) database of user reported PCI values at > http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip > > Linux uses the tg3 driver for that chipset apparently, but I think thats > a general dumping ground for a lot of Broadcom products. Not sure what the > appropriate FreeBSD driver to add the ID code to would be. > > Regards, > > Gary > Sorry, I should have been more clear. I grepped for those values in /usr/src/sys/dev/bge/*, since that's the driver that's used on the older minis. I assume that's where the table is that Alfred mentioned; I just don't know what to add to it. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: > On 11/16/12 10:41, Alfred Perlstein wrote: > > Often that is all that is needed. It's worth a shot and reporting back. > > > > Do you know how to update the table in the driver, rebuild/install > > kernel and check? > > > > -Alfred > > > > I'm afraid not. I grepped for the hex value reported on the one that works > (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I > don't know what to add :-( > > I don't have any problem with rebuilding and installing a new kernel, though. 14e4 is the ID for Broadcom 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list of the BCM PCI ID values There is a (frequently incomplete) database of user reported PCI values at http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip Linux uses the tg3 driver for that chipset apparently, but I think thats a general dumping ground for a lot of Broadcom products. Not sure what the appropriate FreeBSD driver to add the ID code to would be. Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
On 11/16/12 10:41, Alfred Perlstein wrote: > Often that is all that is needed. It's worth a shot and reporting back. > > Do you know how to update the table in the driver, rebuild/install > kernel and check? > > -Alfred > I'm afraid not. I grepped for the hex value reported on the one that works (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I don't know what to add :-( I don't have any problem with rebuilding and installing a new kernel, though. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bge on the new Mac Mini
Often that is all that is needed. It's worth a shot and reporting back. Do you know how to update the table in the driver, rebuild/install kernel and check? -Alfred On 11/16/12 7:30 AM, Richard Kuhns wrote: Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
bge on the new Mac Mini
Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Thanks! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
