From nobody@FreeBSD.org  Sun May 29 22:10:50 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B5590106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 29 May 2011 22:10:50 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id A64828FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 29 May 2011 22:10:50 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p4TMAo7J026224
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 29 May 2011 22:10:50 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p4TMAo2J026223;
	Sun, 29 May 2011 22:10:50 GMT
	(envelope-from nobody)
Message-Id: <201105292210.p4TMAo2J026223@red.freebsd.org>
Date: Sun, 29 May 2011 22:10:50 GMT
From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: freebsd-gnats-submit@FreeBSD.org
Subject: r222135 breaks gem(4) on PowerPC Mac
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         157405
>Category:       kern
>Synopsis:       [gem] r222135 breaks gem(4) on PowerPC Mac
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 29 22:20:08 UTC 2011
>Closed-Date:    Mon Jul 25 20:40:30 UTC 2011
>Last-Modified:  Tue Aug 23 14:40:04 UTC 2011
>Originator:     Justin Hibbits
>Release:        9-CURRENT
>Organization:
>Environment:
FreeBSD narn.knownspace 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r222134:222429M: Sun May 29 17:31:02 EDT 2011     root@narn.knownspace:/usr/obj/usr/src/sys/NARN  powerpc
>Description:
With the change introduced in r222135 I am unable to connect to the network, the device reports UP, but all pings return 'host is down', and no network activity works.

Reverting the change makes it work again.
>How-To-Repeat:
Build world and run on a G4 MDD with the gem(4) NIC.
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Sun May 29 23:58:38 UTC 2011 
Responsible-Changed-Why:  
Grab. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=157405 
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Mon May 30 00:13:05 UTC 2011 
State-Changed-Why:  
Would you try the patch at the following URL? 
Also show me dmesg and 'ifconfig gem0' output. 
http://people.freebsd.org/~yongari/gem/gem.link.diff2 

http://www.freebsd.org/cgi/query-pr.cgi?pr=157405 

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sun, 29 May 2011 22:20:24 -0400

 --Apple-Mail-13--150173069
 Content-Type: text/plain;
 	charset=US-ASCII;
 	format=flowed;
 	delsp=yes
 Content-Transfer-Encoding: 7bit
 
 Thanks for the quick reply.
 
 The patched sort of fixed it, but I had to manually bring down and up  
 the interface before it actually worked, because until I did all  
 operations hanged and timed out.
 
 I've attached the 'bad' dmesg, the 'patched' dmesg, and the 'patched'  
 ifconfig.
 
 - Justin
 
 --Apple-Mail-13--150173069
 Content-Disposition: attachment;
 	filename=dmesg.bad
 Content-Type: application/octet-stream;
 	x-unix-mode=0644;
 	name="dmesg.bad"
 Content-Transfer-Encoding: 7bit
 
 May 29 10:05:03 narn syslogd: kernel boot file is /boot/kernel/kernel
 May 29 10:05:03 narn kernel: Copyright (c) 1992-2011 The FreeBSD Project.
 May 29 10:05:03 narn kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 May 29 10:05:03 narn kernel: The Regents of the University of California. All rights reserved.
 May 29 10:05:03 narn kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
 May 29 10:05:03 narn kernel: FreeBSD 9.0-CURRENT #40 r222429M: Sat May 28 22:03:51 EDT 2011
 May 29 10:05:03 narn kernel: root@narn.knownspace:/usr/obj/usr/src/sys/NARN powerpc
 May 29 10:05:03 narn kernel: cpu0: Motorola PowerPC 7455 revision 3.3, 1250.41 MHz
 May 29 10:05:03 narn kernel: cpu0: Features 9c000000<PPC32,ALTIVEC,FPU,MMU>
 May 29 10:05:03 narn kernel: cpu0: HID0 8450c0bc<EMCP,TBEN,NAP,DPM,ICE,DCE,SGE,BTIC,LRSTK,FOLD,BHT>
 May 29 10:05:03 narn kernel: real memory  = 2132324352 (2033 MB)
 May 29 10:05:03 narn kernel: avail memory = 2063716352 (1968 MB)
 May 29 10:05:03 narn kernel: kbd0 at kbdmux0
 May 29 10:05:03 narn kernel: nexus0: <Open Firmware Nexus device>
 May 29 10:05:03 narn kernel: cpulist0: <Open Firmware CPU Group> on nexus0
 May 29 10:05:03 narn kernel: cpu0: <Open Firmware CPU> on cpulist0
 May 29 10:05:03 narn kernel: powermac_nvram0: <Apple NVRAM> on nexus0
 May 29 10:05:03 narn kernel: powermac_nvram0: bank0 generation 408, bank1 generation 409
 May 29 10:05:03 narn kernel: unin0: <Apple UniNorth System Controller> on nexus0
 May 29 10:05:03 narn kernel: unin0: Version 36
 May 29 10:05:03 narn kernel: iichb0: <Keywest I2C controller> mem 0xf8001000-0xf8001fff irq 42 on unin0
 May 29 10:05:03 narn kernel: iicbus0: <OFW I2C bus> on iichb0
 May 29 10:05:03 narn kernel: adm10300: <G4 MDD Fan driver> at addr 0x58 on iicbus0
 May 29 10:05:03 narn kernel: iicbus0: <unknown card> at addr 0xca
 May 29 10:05:03 narn kernel: ds17750: <Temp-Monitor DS1775> at addr 0x92 on iicbus0
 May 29 10:05:03 narn kernel: pcib0: <Apple UniNorth Host-PCI bridge> on nexus0
 May 29 10:05:03 narn kernel: pci0: <OFW PCI bus> on pcib0
 May 29 10:05:03 narn kernel: agp0: <Apple UniNorth 2 AGP Bridge> on hostb0
 May 29 10:05:03 narn kernel: vgapci0: <VGA-compatible display> port 0x400-0x4ff mem 0xa0000000-0xafffffff,0x90000000-0x9000ffff irq 48 at device 16.0 on pci0
 May 29 10:05:03 narn kernel: pcib1: <Apple UniNorth Host-PCI bridge> on nexus0
 May 29 10:05:03 narn kernel: pci1: <OFW PCI bus> on pcib1
 May 29 10:05:03 narn kernel: macio0: <KeyLargo I/O Controller> mem 0x80000000-0x8007ffff at device 23.0 on pci1
 May 29 10:05:03 narn kernel: openpic0: <OpenPIC Interrupt Controller> mem 0x40000-0x7ffff on macio0
 May 29 10:05:03 narn kernel: macgpio0: <MacIO GPIO Controller> mem 0x50-0x7f on macio0
 May 29 10:05:03 narn kernel: pmuextint0: <Apple PMU99 External Interrupt> extint-gpio 1 irq 47 on macgpio0
 May 29 10:05:03 narn kernel: scc0: <Zilog Z8530 dual channel SCC> mem 0x13000-0x13fff,0x8400-0x84ff,0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 22,5,6,23,7,8 on macio0
 May 29 10:05:03 narn kernel: uart0: <z8530, channel A> on scc0
 May 29 10:05:03 narn kernel: uart1: <z8530, channel B> on scc0
 May 29 10:05:03 narn kernel: pmu0: <Apple PMU99 Controller> mem 0x16000-0x17fff irq 25 on macio0
 May 29 10:05:03 narn kernel: iichb1: <Keywest I2C controller> mem 0x18000-0x18fff irq 26 on macio0
 May 29 10:05:03 narn kernel: iicbus1: <OFW I2C bus> on iichb1
 May 29 10:05:03 narn kernel: iicbus1: <unknown card> at addr 0x6a
 May 29 10:05:03 narn kernel: ata0: <Apple MacIO Ultra ATA Controller> mem 0x1f000-0x1ffff,0x8a00-0x8aff irq 19,11 on macio0
 May 29 10:05:03 narn kernel: ata1: <Apple MacIO ATA Controller> mem 0x20000-0x20fff,0x8b00-0x8bff irq 20,12 on macio0
 May 29 10:05:03 narn kernel: atapci0: <SiI 3112 SATA150 controller> port 0x440-0x447,0x430-0x433,0x420-0x427,0x410-0x413,0x400-0x40f mem 0x80080000-0x800801ff irq 58 at device 21.0 on pci1
 May 29 10:05:03 narn kernel: ata2: <ATA channel 0> on atapci0
 May 29 10:05:03 narn kernel: ata3: <ATA channel 1> on atapci0
 May 29 10:05:03 narn kernel: ohci0: <Apple KeyLargo USB controller> mem 0x80082000-0x80082fff irq 27 at device 24.0 on pci1
 May 29 10:05:03 narn kernel: usbus0: <Apple KeyLargo USB controller> on ohci0
 May 29 10:05:03 narn kernel: ohci1: <Apple KeyLargo USB controller> mem 0x80081000-0x80081fff irq 28 at device 25.0 on pci1
 May 29 10:05:03 narn kernel: usbus1: <Apple KeyLargo USB controller> on ohci1
 May 29 10:05:03 narn kernel: pcib2: <Apple UniNorth Host-PCI bridge> on nexus0
 May 29 10:05:03 narn kernel: pci2: <OFW PCI bus> on pcib2
 May 29 10:05:03 narn kernel: ata4: <Uninorth2 Kauai ATA Controller> mem 0xf5004000-0xf5007fff irq 39 at device 13.0 on pci2
 May 29 10:05:03 narn kernel: fwohci0: <Apple UniNorth> mem 0xf5000000-0xf5000fff irq 40 at device 14.0 on pci2
 May 29 10:05:03 narn kernel: fwohci0: OHCI version 1.10 (ROM=0)
 May 29 10:05:03 narn kernel: fwohci0: No. of Isochronous channels is 8.
 May 29 10:05:03 narn kernel: fwohci0: EUI64 00:0d:93:ff:fe:ac:7d:42
 May 29 10:05:03 narn kernel: fwohci0: Phy 1394a available S400, 3 ports.
 May 29 10:05:03 narn kernel: fwohci0: Link S400, max_rec 2048 bytes.
 May 29 10:05:03 narn kernel: firewire0: <IEEE1394(FireWire) bus> on fwohci0
 May 29 10:05:03 narn kernel: fwe0: <Ethernet over FireWire> on firewire0
 May 29 10:05:03 narn kernel: if_fwe0: Fake Ethernet address: 02:0d:93:ac:7d:42
 May 29 10:05:03 narn kernel: fwe0: Ethernet address: 02:0d:93:ac:7d:42
 May 29 10:05:03 narn kernel: sbp0: <SBP-2/SCSI over FireWire> on firewire0
 May 29 10:05:03 narn kernel: fwohci0: Initiate bus reset
 May 29 10:05:03 narn kernel: fwohci0: fwohci_intr_core: BUS reset
 May 29 10:05:03 narn kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=2, CYCLEMASTER mode
 May 29 10:05:03 narn kernel: gem0: <Apple UniNorth2 GMAC Ethernet> mem 0xf5200000-0xf53fffff irq 41 at device 15.0 on pci2
 May 29 10:05:03 narn kernel: miibus0: <MII bus> on gem0
 May 29 10:05:03 narn kernel: brgphy0: <BCM5421 1000BASE-T media interface> PHY 0 on miibus0
 May 29 10:05:03 narn kernel: brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
 May 29 10:05:03 narn kernel: gem0: 10kB RX FIFO, 4kB TX FIFO
 May 29 10:05:03 narn kernel: gem0: Ethernet address: 00:0d:93:ac:7d:42
 May 29 10:05:03 narn kernel: sc0: <System console> on nexus0
 May 29 10:05:03 narn kernel: sc0: Unknown <16 virtual consoles, flags=0x300>
 May 29 10:05:03 narn kernel: Timecounter "timebase" frequency 41657957 Hz quality 0
 May 29 10:05:03 narn kernel: Event timer "decrementer" frequency 41657957 Hz quality 1000
 May 29 10:05:03 narn kernel: Timecounters tick every 1.000 msec
 May 29 10:05:03 narn kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0)  (me) 
 May 29 10:05:03 narn kernel: firewire0: bus manager 0 
 May 29 10:05:03 narn kernel: usbus0: 12Mbps Full Speed USB v1.0
 May 29 10:05:03 narn kernel: usbus1: 12Mbps Full Speed USB v1.0
 May 29 10:05:03 narn kernel: ugen0.1: <Apple> at usbus0
 May 29 10:05:03 narn kernel: uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
 May 29 10:05:03 narn kernel: ugen1.1: <Apple> at usbus1
 May 29 10:05:03 narn kernel: uhub1: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
 May 29 10:05:03 narn kernel: uhub0: 2 ports with 2 removable, self powered
 May 29 10:05:03 narn kernel: uhub1: 2 ports with 2 removable, self powered
 May 29 10:05:03 narn kernel: ugen0.2: <Mitsumi Electric> at usbus0
 May 29 10:05:03 narn kernel: uhub2: <Mitsumi Electric Hub in Apple Extended USB Keyboard, class 9/0, rev 1.10/1.22, addr 2> on usbus0
 May 29 10:05:03 narn kernel: uhub2: 3 ports with 2 removable, bus powered
 May 29 10:05:03 narn kernel: ugen0.3: <Mitsumi Electric> at usbus0
 May 29 10:05:03 narn kernel: ukbd0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 3> on usbus0
 May 29 10:05:03 narn kernel: kbd1 at ukbd0
 May 29 10:05:03 narn kernel: uhid0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 3> on usbus0
 May 29 10:05:03 narn kernel: ugen0.4: <Logitech> at usbus0
 May 29 10:05:03 narn kernel: ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/11.10, addr 4> on usbus0
 May 29 10:05:03 narn kernel: ums0: 3 buttons and [XYZ] coordinates ID=0
 May 29 10:05:03 narn kernel: ada0 at ata2 bus 0 scbus2 target 0 lun 0
 May 29 10:05:03 narn kernel: ada0: <ST3500320AS SD04> ATA-7 SATA 1.x device
 May 29 10:05:03 narn kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
 May 29 10:05:03 narn kernel: ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
 May 29 10:05:03 narn kernel: ada0: Previously was known as ad0
 May 29 10:05:03 narn kernel: ada1 at ata4 bus 0 scbus4 target 0 lun 0
 May 29 10:05:03 narn kernel: ada1: <ST360015A 3.31> ATA-6 device
 May 29 10:05:03 narn kernel: ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
 May 29 10:05:03 narn kernel: ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C)
 May 29 10:05:03 narn kernel: ada1: Previously was known as ad1
 May 29 10:05:03 narn kernel: ada2 at ata4 bus 0 scbus4 target 1 lun 0
 May 29 10:05:03 narn kernel: ada2: <WDC WD1200JB-00CRA1 17.07W17> ATA-5 device
 May 29 10:05:03 narn kernel: ada2: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
 May 29 10:05:03 narn kernel: ada2: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C)
 May 29 10:05:03 narn kernel: ada2: Previously was known as ad2
 May 29 10:05:03 narn kernel: cd0 at ata1 bus 0 scbus1 target 0 lun 0
 May 29 10:05:03 narn kernel: cd0: <HL-DT-ST RW/DVD GCC-4480B 1.03> Removable CD-ROM SCSI-0 device 
 May 29 10:05:03 narn kernel: cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
 May 29 10:05:03 narn kernel: cd0: cd present [177135 x 2048 byte records]
 May 29 10:05:03 narn kernel: Kernel thread "pmac_thermal" (pid 19) exited prematurely.
 May 29 10:05:03 narn kernel: Trying to mount root from ufs:/dev/ufs/root [rw]...
 May 29 10:05:03 narn kernel: gem0: cannot disable TX MAC
 May 29 10:05:03 narn kernel: gem0: cannot disable RX MAC
 May 29 10:05:03 narn kernel: gem0: cannot disable TX MAC
 May 29 10:05:03 narn kernel: gem0: cannot disable RX MAC
 
 --Apple-Mail-13--150173069
 Content-Disposition: attachment;
 	filename=dmesg.out
 Content-Type: application/octet-stream;
 	x-unix-mode=0644;
 	name="dmesg.out"
 Content-Transfer-Encoding: 7bit
 
 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 9.0-CURRENT #43 r222469M: Sun May 29 21:27:49 EDT 2011
     root@narn.knownspace:/usr/obj/usr/src/sys/NARN powerpc
 cpu0: Motorola PowerPC 7455 revision 3.3, 1250.32 MHz
 cpu0: Features 9c000000<PPC32,ALTIVEC,FPU,MMU>
 cpu0: HID0 8450c0bc<EMCP,TBEN,NAP,DPM,ICE,DCE,SGE,BTIC,LRSTK,FOLD,BHT>
 real memory  = 2133086208 (2034 MB)
 avail memory = 2064384000 (1968 MB)
 kbd0 at kbdmux0
 nexus0: <Open Firmware Nexus device>
 cpulist0: <Open Firmware CPU Group> on nexus0
 cpu0: <Open Firmware CPU> on cpulist0
 powermac_nvram0: <Apple NVRAM> on nexus0
 powermac_nvram0: bank0 generation 408, bank1 generation 409
 unin0: <Apple UniNorth System Controller> on nexus0
 unin0: Version 36
 iichb0: <Keywest I2C controller> mem 0xf8001000-0xf8001fff irq 42 on unin0
 iicbus0: <OFW I2C bus> on iichb0
 adm10300: <G4 MDD Fan driver> at addr 0x58 on iicbus0
 iicbus0: <unknown card> at addr 0xca
 ds17750: <Temp-Monitor DS1775> at addr 0x92 on iicbus0
 pcib0: <Apple UniNorth Host-PCI bridge> on nexus0
 pci0: <OFW PCI bus> on pcib0
 agp0: <Apple UniNorth 2 AGP Bridge> on hostb0
 vgapci0: <VGA-compatible display> port 0x400-0x4ff mem 0xa0000000-0xafffffff,0x90000000-0x9000ffff irq 48 at device 16.0 on pci0
 pcib1: <Apple UniNorth Host-PCI bridge> on nexus0
 pci1: <OFW PCI bus> on pcib1
 macio0: <KeyLargo I/O Controller> mem 0x80000000-0x8007ffff at device 23.0 on pci1
 openpic0: <OpenPIC Interrupt Controller> mem 0x40000-0x7ffff on macio0
 macgpio0: <MacIO GPIO Controller> mem 0x50-0x7f on macio0
 pmuextint0: <Apple PMU99 External Interrupt> extint-gpio 1 irq 47 on macgpio0
 scc0: <Zilog Z8530 dual channel SCC> mem 0x13000-0x13fff,0x8400-0x84ff,0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 22,5,6,23,7,8 on macio0
 uart0: <z8530, channel A> on scc0
 uart1: <z8530, channel B> on scc0
 pcm0: <Apple I2S Audio Controller> mem 0x10000-0x10fff,0x8000-0x80ff,0x8100-0x81ff irq 30,1,2 on macio0
 pmu0: <Apple PMU99 Controller> mem 0x16000-0x17fff irq 25 on macio0
 iichb1: <Keywest I2C controller> mem 0x18000-0x18fff irq 26 on macio0
 iicbus1: <OFW I2C bus> on iichb1
 snapper0: <Texas Instruments TAS3004 Audio Codec> at addr 0x6a on iicbus1
 ata0: <Apple MacIO Ultra ATA Controller> mem 0x1f000-0x1ffff,0x8a00-0x8aff irq 19,11 on macio0
 ata1: <Apple MacIO ATA Controller> mem 0x20000-0x20fff,0x8b00-0x8bff irq 20,12 on macio0
 atapci0: <SiI 3112 SATA150 controller> port 0x440-0x447,0x430-0x433,0x420-0x427,0x410-0x413,0x400-0x40f mem 0x80080000-0x800801ff irq 58 at device 21.0 on pci1
 ata2: <ATA channel 0> on atapci0
 ata3: <ATA channel 1> on atapci0
 ohci0: <Apple KeyLargo USB controller> mem 0x80082000-0x80082fff irq 27 at device 24.0 on pci1
 usbus0: <Apple KeyLargo USB controller> on ohci0
 ohci1: <Apple KeyLargo USB controller> mem 0x80081000-0x80081fff irq 28 at device 25.0 on pci1
 usbus1: <Apple KeyLargo USB controller> on ohci1
 pcib2: <Apple UniNorth Host-PCI bridge> on nexus0
 pci2: <OFW PCI bus> on pcib2
 ata4: <Uninorth2 Kauai ATA Controller> mem 0xf5004000-0xf5007fff irq 39 at device 13.0 on pci2
 fwohci0: <Apple UniNorth> mem 0xf5000000-0xf5000fff irq 40 at device 14.0 on pci2
 fwohci0: OHCI version 1.10 (ROM=0)
 fwohci0: No. of Isochronous channels is 8.
 fwohci0: EUI64 00:0d:93:ff:fe:ac:7d:42
 fwohci0: Phy 1394a available S400, 3 ports.
 fwohci0: Link S400, max_rec 2048 bytes.
 firewire0: <IEEE1394(FireWire) bus> on fwohci0
 sbp0: <SBP-2/SCSI over FireWire> on firewire0
 fwe0: <Ethernet over FireWire> on firewire0
 if_fwe0: Fake Ethernet address: 02:0d:93:ac:7d:42
 fwe0: Ethernet address: 02:0d:93:ac:7d:42
 fwohci0: Initiate bus reset
 fwohci0: fwohci_intr_core: BUS reset
 fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=2, CYCLEMASTER mode
 gem0: <Apple UniNorth2 GMAC Ethernet> mem 0xf5200000-0xf53fffff irq 41 at device 15.0 on pci2
 miibus0: <MII bus> on gem0
 brgphy0: <BCM5421 1000BASE-T media interface> PHY 0 on miibus0
 brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
 gem0: 10kB RX FIFO, 4kB TX FIFO
 gem0: Ethernet address: 00:0d:93:ac:7d:42
 sc0: <System console> on nexus0
 sc0: Unknown <16 virtual consoles, flags=0x300>
 Timecounter "timebase" frequency 41657957 Hz quality 0
 Event timer "decrementer" frequency 41657957 Hz quality 1000
 Timecounters tick every 1.000 msec
 firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0)  (me) 
 firewire0: bus manager 0 
 usbus0: 12Mbps Full Speed USB v1.0
 usbus1: 12Mbps Full Speed USB v1.0
 ugen0.1: <Apple> at usbus0
 uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
 ugen1.1: <Apple> at usbus1
 uhub1: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
 uhub0: 2 ports with 2 removable, self powered
 uhub1: 2 ports with 2 removable, self powered
 ugen0.2: <Mitsumi Electric> at usbus0
 uhub2: <Mitsumi Electric Hub in Apple Extended USB Keyboard, class 9/0, rev 1.10/1.22, addr 2> on usbus0
 uhub2: 3 ports with 2 removable, bus powered
 ugen0.3: <Mitsumi Electric> at usbus0
 ukbd0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 3> on usbus0
 kbd1 at ukbd0
 uhid0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 3> on usbus0
 ugen0.4: <Logitech> at usbus0
 ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/11.10, addr 4> on usbus0
 ums0: 3 buttons and [XYZ] coordinates ID=0
 ada0 at ata2 bus 0 scbus2 target 0 lun 0
 ada0: <ST3500320AS SD04> ATA-7 SATA 1.x device
 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
 ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
 ada0: Previously was known as ad0
 ada1 at ata4 bus 0 scbus4 target 0 lun 0
 ada1: <ST360015A 3.31> ATA-6 device
 ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
 ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C)
 ada1: Previously was known as ad1
 ada2 at ata4 bus 0 scbus4 target 1 lun 0
 ada2: <WDC WD1200JB-00CRA1 17.07W17> ATA-5 device
 ada2: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
 ada2: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C)
 ada2: Previously was known as ad2
 cd0 at ata1 bus 0 scbus1 target 0 lun 0
 cd0: <HL-DT-ST RW/DVD GCC-4480B 1.03> Removable CD-ROM SCSI-0 device 
 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
 cd0: Attempt to query device size failed: NOT READY, Medium not present
 Trying to mount root from ufs:/dev/ufs/root [rw]...
 gem0: cannot disable TX MAC
 gem0: cannot disable RX MAC
 gem0: cannot disable TX MAC
 gem0: cannot disable RX MAC
 
 --Apple-Mail-13--150173069
 Content-Disposition: attachment;
 	filename=ifconfig.out
 Content-Type: application/octet-stream;
 	x-unix-mode=0644;
 	name="ifconfig.out"
 Content-Transfer-Encoding: 7bit
 
 gem0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 	options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
 	ether 00:0d:93:ac:7d:42
 	inet 192.168.1.21 netmask 0xffffff00 broadcast 192.168.1.255
 	inet6 fe80::20d:93ff:feac:7d42%gem0 prefixlen 64 scopeid 0x4 
 	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
 	media: Ethernet autoselect (1000baseT <full-duplex>)
 	status: active
 
 --Apple-Mail-13--150173069--

From: YongHyeon PYUN <pyunyh@gmail.com>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Mon, 30 May 2011 15:19:17 -0700

 --6c2NcOVqGQ03X4Wi
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 > The following reply was made to PR kern/157405; it has been noted by GNATS.
 > 
 > From: Justin Hibbits <jrh29@alumni.cwru.edu>
 > To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 > Cc:  
 > Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
 > Date: Sun, 29 May 2011 22:20:24 -0400
 > 
 
 [...]
 
 >  Thanks for the quick reply.
 >  
 >  The patched sort of fixed it, but I had to manually bring down and up  
 >  the interface before it actually worked, because until I did all  
 >  operations hanged and timed out.
 >  
 >  I've attached the 'bad' dmesg, the 'patched' dmesg, and the 'patched'  
 >  ifconfig.
 >  
 
 Thanks for testing. I see the following messages from driver.
 gem0: cannot disable TX MAC
 gem0: cannot disable RX MAC
 Were the message there before r222135?
 Anyway, would you try updated patch?
 
 --6c2NcOVqGQ03X4Wi
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="gem.link.diff3"
 
 Index: sys/dev/gem/if_gem.c
 ===================================================================
 --- sys/dev/gem/if_gem.c	(revision 222469)
 +++ sys/dev/gem/if_gem.c	(working copy)
 @@ -2004,21 +2004,28 @@
  		device_printf(sc->sc_dev, "%s: status change\n", __func__);
  #endif
  
 -	if ((sc->sc_mii->mii_media_status & IFM_ACTIVE) != 0 &&
 -	    IFM_SUBTYPE(sc->sc_mii->mii_media_active) != IFM_NONE)
 -		sc->sc_flags |= GEM_LINK;
 -	else
 -		sc->sc_flags &= ~GEM_LINK;
 +	if ((sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING) == 0)
 +		return;
  
 -	switch (IFM_SUBTYPE(sc->sc_mii->mii_media_active)) {
 -	case IFM_1000_SX:
 -	case IFM_1000_LX:
 -	case IFM_1000_CX:
 -	case IFM_1000_T:
 -		gigabit = 1;
 -		break;
 -	default:
 -		gigabit = 0;
 +	gigabit = 0;
 +	sc->sc_flags &= ~GEM_LINK;
 +	if ((sc->sc_mii->mii_media_status & (IFM_ACTIVE | IFM_AVALID)) ==
 +	    (IFM_ACTIVE | IFM_AVALID)) {
 +		switch (IFM_SUBTYPE(sc->sc_mii->mii_media_active)) {
 +		case IFM_10_T:
 +		case IFM_100_TX:
 +			sc->sc_flags |= GEM_LINK;
 +			break;
 +		case IFM_1000_SX:
 +		case IFM_1000_LX:
 +		case IFM_1000_CX:
 +		case IFM_1000_T:
 +			sc->sc_flags |= GEM_LINK;
 +			gigabit = 1;
 +			break;
 +		default:
 +			break;
 +		}
  	}
  
  	/*
 @@ -2092,8 +2099,7 @@
  		v |= GEM_MAC_XIF_FDPLX_LED;
  	GEM_BANK1_WRITE_4(sc, GEM_MAC_XIF_CONFIG, v);
  
 -	if ((sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING) != 0 &&
 -	    (sc->sc_flags & GEM_LINK) != 0) {
 +	if ((sc->sc_flags & GEM_LINK) != 0) {
  		GEM_BANK1_WRITE_4(sc, GEM_MAC_TX_CONFIG,
  		    txcfg | GEM_MAC_TX_ENABLE);
  		GEM_BANK1_WRITE_4(sc, GEM_MAC_RX_CONFIG,
 
 --6c2NcOVqGQ03X4Wi--

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: pyunyh@gmail.com
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Mon, 30 May 2011 21:22:04 -0400

 On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 
 > On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 >> The following reply was made to PR kern/157405; it has been noted  
 >> by GNATS.
 >>
 >> From: Justin Hibbits <jrh29@alumni.cwru.edu>
 >> To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 >> Cc:
 >> Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
 >> Date: Sun, 29 May 2011 22:20:24 -0400
 >>
 >
 > [...]
 >
 >> Thanks for the quick reply.
 >>
 >> The patched sort of fixed it, but I had to manually bring down and up
 >> the interface before it actually worked, because until I did all
 >> operations hanged and timed out.
 >>
 >> I've attached the 'bad' dmesg, the 'patched' dmesg, and the 'patched'
 >> ifconfig.
 >>
 >
 > Thanks for testing. I see the following messages from driver.
 > gem0: cannot disable TX MAC
 > gem0: cannot disable RX MAC
 > Were the message there before r222135?
 > Anyway, would you try updated patch?
 > <gem.link.diff3>
 
 I'll try the patch tomorrow when I have more time.  Going back through  
 my logs, I did not see the message until that update.  Reverting that  
 commit does not make those messages go away either, but I have not  
 done a full tree revert or a bisect to find the revision that caused  
 them to appear.
 
 - Justin

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: pyunyh@gmail.com
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Tue, 31 May 2011 18:09:57 -0400

 On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 
 > On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 >> The following reply was made to PR kern/157405; it has been noted  
 >> by GNATS.
 >>
 >> From: Justin Hibbits <jrh29@alumni.cwru.edu>
 >> To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 >> Cc:
 >> Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
 >> Date: Sun, 29 May 2011 22:20:24 -0400
 >>
 >
 > [...]
 >
 >> Thanks for the quick reply.
 >>
 >> The patched sort of fixed it, but I had to manually bring down and up
 >> the interface before it actually worked, because until I did all
 >> operations hanged and timed out.
 >>
 >> I've attached the 'bad' dmesg, the 'patched' dmesg, and the 'patched'
 >> ifconfig.
 >>
 >
 > Thanks for testing. I see the following messages from driver.
 > gem0: cannot disable TX MAC
 > gem0: cannot disable RX MAC
 > Were the message there before r222135?
 > Anyway, would you try updated patch?
 
 I just tried the patch, and got the same result:  It works if I  
 ifconfig down/up it first.
 
 - Justin

From: YongHyeon PYUN <pyunyh@gmail.com>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: marius@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Tue, 31 May 2011 19:19:56 -0700

 --oTHb8nViIGeoXxdp
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Tue, May 31, 2011 at 06:09:57PM -0400, Justin Hibbits wrote:
 > On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 > 
 > >On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 > >>The following reply was made to PR kern/157405; it has been noted  
 > >>by GNATS.
 > >>
 > >>From: Justin Hibbits <jrh29@alumni.cwru.edu>
 > >>To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 > >>Cc:
 > >>Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
 > >>Date: Sun, 29 May 2011 22:20:24 -0400
 > >>
 > >
 > >[...]
 > >
 > >>Thanks for the quick reply.
 > >>
 > >>The patched sort of fixed it, but I had to manually bring down and up
 > >>the interface before it actually worked, because until I did all
 > >>operations hanged and timed out.
 > >>
 > >>I've attached the 'bad' dmesg, the 'patched' dmesg, and the 'patched'
 > >>ifconfig.
 > >>
 > >
 > >Thanks for testing. I see the following messages from driver.
 > >gem0: cannot disable TX MAC
 > >gem0: cannot disable RX MAC
 > >Were the message there before r222135?
 > >Anyway, would you try updated patch?
 > 
 > I just tried the patch, and got the same result:  It works if I  
 > ifconfig down/up it first.
 > 
 > - Justin
 
 k, next try. I've tested this patch on sparc64 and it worked as
 expected. However, the controller is fast ethernet so I'm not sure
 whether it makes any difference for you.
 I also CCed to marius@ because he may have better idea on this
 issue. I wouldn't be available for 2~3 weeks starting from this
 weekend.  I guess it's not acceptable to leave the issue there
 without fixing it for more than 2 weeks. I'm also happy to revert
 the guilty change set. Hopefully I may be able to find more time to
 identify the root cause of the issue after returning back from
 the vacation.
 
 --oTHb8nViIGeoXxdp
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="gem.link.diff4"
 
 Index: sys/dev/gem/if_gem.c
 ===================================================================
 --- sys/dev/gem/if_gem.c	(revision 222469)
 +++ sys/dev/gem/if_gem.c	(working copy)
 @@ -2004,22 +2004,31 @@
  		device_printf(sc->sc_dev, "%s: status change\n", __func__);
  #endif
  
 -	if ((sc->sc_mii->mii_media_status & IFM_ACTIVE) != 0 &&
 -	    IFM_SUBTYPE(sc->sc_mii->mii_media_active) != IFM_NONE)
 -		sc->sc_flags |= GEM_LINK;
 -	else
 -		sc->sc_flags &= ~GEM_LINK;
 +	if ((sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING) == 0)
 +		return;
  
 -	switch (IFM_SUBTYPE(sc->sc_mii->mii_media_active)) {
 -	case IFM_1000_SX:
 -	case IFM_1000_LX:
 -	case IFM_1000_CX:
 -	case IFM_1000_T:
 -		gigabit = 1;
 -		break;
 -	default:
 -		gigabit = 0;
 +	gigabit = 0;
 +	sc->sc_flags &= ~GEM_LINK;
 +	if ((sc->sc_mii->mii_media_status & (IFM_ACTIVE | IFM_AVALID)) ==
 +	    (IFM_ACTIVE | IFM_AVALID)) {
 +		switch (IFM_SUBTYPE(sc->sc_mii->mii_media_active)) {
 +		case IFM_10_T:
 +		case IFM_100_TX:
 +			sc->sc_flags |= GEM_LINK;
 +			break;
 +		case IFM_1000_SX:
 +		case IFM_1000_LX:
 +		case IFM_1000_CX:
 +		case IFM_1000_T:
 +			sc->sc_flags |= GEM_LINK;
 +			gigabit = 1;
 +			break;
 +		default:
 +			break;
 +		}
  	}
 +	if ((sc->sc_flags & GEM_LINK) == 0)
 +		return;
  
  	/*
  	 * The configuration done here corresponds to the steps F) and
 @@ -2092,8 +2101,7 @@
  		v |= GEM_MAC_XIF_FDPLX_LED;
  	GEM_BANK1_WRITE_4(sc, GEM_MAC_XIF_CONFIG, v);
  
 -	if ((sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING) != 0 &&
 -	    (sc->sc_flags & GEM_LINK) != 0) {
 +	if ((sc->sc_flags & GEM_LINK) != 0) {
  		GEM_BANK1_WRITE_4(sc, GEM_MAC_TX_CONFIG,
  		    txcfg | GEM_MAC_TX_ENABLE);
  		GEM_BANK1_WRITE_4(sc, GEM_MAC_RX_CONFIG,
 
 --oTHb8nViIGeoXxdp--

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: pyunyh@gmail.com
Cc: marius@FreeBSD.org,
 bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Wed, 1 Jun 2011 17:05:39 -0400

 On May 31, 2011, at 10:19 PM, YongHyeon PYUN wrote:
 
 > On Tue, May 31, 2011 at 06:09:57PM -0400, Justin Hibbits wrote:
 >> On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 >>
 >>> On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 >>>> The following reply was made to PR kern/157405; it has been noted
 >>>> by GNATS.
 >>>>
 >>>> From: Justin Hibbits <jrh29@alumni.cwru.edu>
 >>>> To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 >>>> Cc:
 >>>> Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC  
 >>>> Mac
 >>>> Date: Sun, 29 May 2011 22:20:24 -0400
 >>>>
 >>>
 >>> [...]
 >>>
 >>>> Thanks for the quick reply.
 >>>>
 >>>> The patched sort of fixed it, but I had to manually bring down  
 >>>> and up
 >>>> the interface before it actually worked, because until I did all
 >>>> operations hanged and timed out.
 >>>>
 >>>> I've attached the 'bad' dmesg, the 'patched' dmesg, and the  
 >>>> 'patched'
 >>>> ifconfig.
 >>>>
 >>>
 >>> Thanks for testing. I see the following messages from driver.
 >>> gem0: cannot disable TX MAC
 >>> gem0: cannot disable RX MAC
 >>> Were the message there before r222135?
 >>> Anyway, would you try updated patch?
 >>
 >> I just tried the patch, and got the same result:  It works if I
 >> ifconfig down/up it first.
 >>
 >> - Justin
 >
 > k, next try. I've tested this patch on sparc64 and it worked as
 > expected. However, the controller is fast ethernet so I'm not sure
 > whether it makes any difference for you.
 > I also CCed to marius@ because he may have better idea on this
 > issue. I wouldn't be available for 2~3 weeks starting from this
 > weekend.  I guess it's not acceptable to leave the issue there
 > without fixing it for more than 2 weeks. I'm also happy to revert
 > the guilty change set. Hopefully I may be able to find more time to
 > identify the root cause of the issue after returning back from
 > the vacation.
 
 Sorry to disappoint, but this has the same result -- I had to ifconfig  
 down/up for it to work.
 
 The 'gem0: cannot disable (T/R)X MAC' messages are curious as well.  I  
 don't know what relation they have with my problem, though, because  
 they still appear when I revert r222135 (and gem0 works fine), but  
 weren't there until I performed the initial update.
 
 - Justin

From: YongHyeon PYUN <pyunyh@gmail.com>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: marius@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Wed, 1 Jun 2011 16:16:16 -0700

 --ibTvN161/egqYuK8
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > On May 31, 2011, at 10:19 PM, YongHyeon PYUN wrote:
 > 
 > >On Tue, May 31, 2011 at 06:09:57PM -0400, Justin Hibbits wrote:
 > >>On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 > >>
 > >>>On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 > >>>>The following reply was made to PR kern/157405; it has been noted
 > >>>>by GNATS.
 > >>>>
 > >>>>From: Justin Hibbits <jrh29@alumni.cwru.edu>
 > >>>>To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 > >>>>Cc:
 > >>>>Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC  
 > >>>>Mac
 > >>>>Date: Sun, 29 May 2011 22:20:24 -0400
 > >>>>
 > >>>
 > >>>[...]
 > >>>
 > >>>>Thanks for the quick reply.
 > >>>>
 > >>>>The patched sort of fixed it, but I had to manually bring down  
 > >>>>and up
 > >>>>the interface before it actually worked, because until I did all
 > >>>>operations hanged and timed out.
 > >>>>
 > >>>>I've attached the 'bad' dmesg, the 'patched' dmesg, and the  
 > >>>>'patched'
 > >>>>ifconfig.
 > >>>>
 > >>>
 > >>>Thanks for testing. I see the following messages from driver.
 > >>>gem0: cannot disable TX MAC
 > >>>gem0: cannot disable RX MAC
 > >>>Were the message there before r222135?
 > >>>Anyway, would you try updated patch?
 > >>
 > >>I just tried the patch, and got the same result:  It works if I
 > >>ifconfig down/up it first.
 > >>
 > >>- Justin
 > >
 > >k, next try. I've tested this patch on sparc64 and it worked as
 > >expected. However, the controller is fast ethernet so I'm not sure
 > >whether it makes any difference for you.
 > >I also CCed to marius@ because he may have better idea on this
 > >issue. I wouldn't be available for 2~3 weeks starting from this
 > >weekend.  I guess it's not acceptable to leave the issue there
 > >without fixing it for more than 2 weeks. I'm also happy to revert
 > >the guilty change set. Hopefully I may be able to find more time to
 > >identify the root cause of the issue after returning back from
 > >the vacation.
 > 
 > Sorry to disappoint, but this has the same result -- I had to ifconfig  
 > down/up for it to work.
 > 
 
 :-(
 
 > The 'gem0: cannot disable (T/R)X MAC' messages are curious as well.  I  
 > don't know what relation they have with my problem, though, because  
 > they still appear when I revert r222135 (and gem0 works fine), but  
 > weren't there until I performed the initial update.
 > 
 
 I think gem_intr() looks somewhat odd. It seems the interrupt
 handler does not check whether driver is running or not. If the
 interrupt is shared with other devices or default interrupt mask
 allows interrupts after device reset(e.g. PHY interrupt or RX
 interrupts before initializing controller after device attach) it
 may cause problems. However I'm not sure whether you're seeing this
 issue. Marius, what's your opinion?
 
 Here is updated patch.
 
 > - Justin
 
 --ibTvN161/egqYuK8
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="gem.link.diff5"
 
 Index: sys/dev/gem/if_gem.c
 ===================================================================
 --- sys/dev/gem/if_gem.c	(revision 222578)
 +++ sys/dev/gem/if_gem.c	(working copy)
 @@ -1713,6 +1713,10 @@
  
  	GEM_LOCK(sc);
  	status = GEM_BANK1_READ_4(sc, GEM_STATUS);
 +	if ((sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) {
 +		GEM_UNLOCK(sc);
 +		return;
 +	}
  
  #ifdef GEM_DEBUG
  	CTR4(KTR_GEM, "%s: %s: cplt %x, status %x",
 @@ -2004,21 +2008,28 @@
  		device_printf(sc->sc_dev, "%s: status change\n", __func__);
  #endif
  
 -	if ((sc->sc_mii->mii_media_status & IFM_ACTIVE) != 0 &&
 -	    IFM_SUBTYPE(sc->sc_mii->mii_media_active) != IFM_NONE)
 -		sc->sc_flags |= GEM_LINK;
 -	else
 -		sc->sc_flags &= ~GEM_LINK;
 +	if ((sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING) == 0)
 +		return;
  
 -	switch (IFM_SUBTYPE(sc->sc_mii->mii_media_active)) {
 -	case IFM_1000_SX:
 -	case IFM_1000_LX:
 -	case IFM_1000_CX:
 -	case IFM_1000_T:
 -		gigabit = 1;
 -		break;
 -	default:
 -		gigabit = 0;
 +	gigabit = 0;
 +	sc->sc_flags &= ~GEM_LINK;
 +	if ((sc->sc_mii->mii_media_status & (IFM_ACTIVE | IFM_AVALID)) ==
 +	    (IFM_ACTIVE | IFM_AVALID)) {
 +		switch (IFM_SUBTYPE(sc->sc_mii->mii_media_active)) {
 +		case IFM_10_T:
 +		case IFM_100_TX:
 +			sc->sc_flags |= GEM_LINK;
 +			break;
 +		case IFM_1000_SX:
 +		case IFM_1000_LX:
 +		case IFM_1000_CX:
 +		case IFM_1000_T:
 +			sc->sc_flags |= GEM_LINK;
 +			gigabit = 1;
 +			break;
 +		default:
 +			break;
 +		}
  	}
  
  	/*
 @@ -2092,8 +2103,7 @@
  		v |= GEM_MAC_XIF_FDPLX_LED;
  	GEM_BANK1_WRITE_4(sc, GEM_MAC_XIF_CONFIG, v);
  
 -	if ((sc->sc_ifp->if_drv_flags & IFF_DRV_RUNNING) != 0 &&
 -	    (sc->sc_flags & GEM_LINK) != 0) {
 +	if ((sc->sc_flags & GEM_LINK) != 0) {
  		GEM_BANK1_WRITE_4(sc, GEM_MAC_TX_CONFIG,
  		    txcfg | GEM_MAC_TX_ENABLE);
  		GEM_BANK1_WRITE_4(sc, GEM_MAC_RX_CONFIG,
 
 --ibTvN161/egqYuK8--

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: pyunyh@gmail.com
Cc: marius@FreeBSD.org,
 bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Wed, 1 Jun 2011 21:50:16 -0400

 On Jun 1, 2011, at 7:16 PM, YongHyeon PYUN wrote:
 
 > On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 >> On May 31, 2011, at 10:19 PM, YongHyeon PYUN wrote:
 >>
 >>> On Tue, May 31, 2011 at 06:09:57PM -0400, Justin Hibbits wrote:
 >>>> On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 >>>>
 >>>>> On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 >>>>>> The following reply was made to PR kern/157405; it has been noted
 >>>>>> by GNATS.
 >>>>>>
 >>>>>> From: Justin Hibbits <jrh29@alumni.cwru.edu>
 >>>>>> To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 >>>>>> Cc:
 >>>>>> Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC
 >>>>>> Mac
 >>>>>> Date: Sun, 29 May 2011 22:20:24 -0400
 >>>>>>
 >>>>>
 >>>>> [...]
 >>>>>
 >>>>>> Thanks for the quick reply.
 >>>>>>
 >>>>>> The patched sort of fixed it, but I had to manually bring down
 >>>>>> and up
 >>>>>> the interface before it actually worked, because until I did all
 >>>>>> operations hanged and timed out.
 >>>>>>
 >>>>>> I've attached the 'bad' dmesg, the 'patched' dmesg, and the
 >>>>>> 'patched'
 >>>>>> ifconfig.
 >>>>>>
 >>>>>
 >>>>> Thanks for testing. I see the following messages from driver.
 >>>>> gem0: cannot disable TX MAC
 >>>>> gem0: cannot disable RX MAC
 >>>>> Were the message there before r222135?
 >>>>> Anyway, would you try updated patch?
 >>>>
 >>>> I just tried the patch, and got the same result:  It works if I
 >>>> ifconfig down/up it first.
 >>>>
 >>>> - Justin
 >>>
 >>> k, next try. I've tested this patch on sparc64 and it worked as
 >>> expected. However, the controller is fast ethernet so I'm not sure
 >>> whether it makes any difference for you.
 >>> I also CCed to marius@ because he may have better idea on this
 >>> issue. I wouldn't be available for 2~3 weeks starting from this
 >>> weekend.  I guess it's not acceptable to leave the issue there
 >>> without fixing it for more than 2 weeks. I'm also happy to revert
 >>> the guilty change set. Hopefully I may be able to find more time to
 >>> identify the root cause of the issue after returning back from
 >>> the vacation.
 >>
 >> Sorry to disappoint, but this has the same result -- I had to  
 >> ifconfig
 >> down/up for it to work.
 >>
 >
 > :-(
 >
 >> The 'gem0: cannot disable (T/R)X MAC' messages are curious as  
 >> well.  I
 >> don't know what relation they have with my problem, though, because
 >> they still appear when I revert r222135 (and gem0 works fine), but
 >> weren't there until I performed the initial update.
 >>
 >
 > I think gem_intr() looks somewhat odd. It seems the interrupt
 > handler does not check whether driver is running or not. If the
 > interrupt is shared with other devices or default interrupt mask
 > allows interrupts after device reset(e.g. PHY interrupt or RX
 > interrupts before initializing controller after device attach) it
 > may cause problems. However I'm not sure whether you're seeing this
 > issue. Marius, what's your opinion?
 >
 > Here is updated patch.
 >
 >> - Justin
 
 Unfortunately that still did not fix the problem, I got the same  
 results.  Do you want any more info from me (more dmesg/ifconfig, full  
 hardware specs, etc)?
 
 - Justin
 

From: YongHyeon PYUN <pyunyh@gmail.com>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: marius@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Wed, 1 Jun 2011 19:06:24 -0700

 On Wed, Jun 01, 2011 at 09:50:16PM -0400, Justin Hibbits wrote:
 > On Jun 1, 2011, at 7:16 PM, YongHyeon PYUN wrote:
 > 
 > >On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > >>On May 31, 2011, at 10:19 PM, YongHyeon PYUN wrote:
 > >>
 > >>>On Tue, May 31, 2011 at 06:09:57PM -0400, Justin Hibbits wrote:
 > >>>>On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 > >>>>
 > >>>>>On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 > >>>>>>The following reply was made to PR kern/157405; it has been noted
 > >>>>>>by GNATS.
 > >>>>>>
 > >>>>>>From: Justin Hibbits <jrh29@alumni.cwru.edu>
 > >>>>>>To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 > >>>>>>Cc:
 > >>>>>>Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC
 > >>>>>>Mac
 > >>>>>>Date: Sun, 29 May 2011 22:20:24 -0400
 > >>>>>>
 > >>>>>
 > >>>>>[...]
 > >>>>>
 > >>>>>>Thanks for the quick reply.
 > >>>>>>
 > >>>>>>The patched sort of fixed it, but I had to manually bring down
 > >>>>>>and up
 > >>>>>>the interface before it actually worked, because until I did all
 > >>>>>>operations hanged and timed out.
 > >>>>>>
 > >>>>>>I've attached the 'bad' dmesg, the 'patched' dmesg, and the
 > >>>>>>'patched'
 > >>>>>>ifconfig.
 > >>>>>>
 > >>>>>
 > >>>>>Thanks for testing. I see the following messages from driver.
 > >>>>>gem0: cannot disable TX MAC
 > >>>>>gem0: cannot disable RX MAC
 > >>>>>Were the message there before r222135?
 > >>>>>Anyway, would you try updated patch?
 > >>>>
 > >>>>I just tried the patch, and got the same result:  It works if I
 > >>>>ifconfig down/up it first.
 > >>>>
 > >>>>- Justin
 > >>>
 > >>>k, next try. I've tested this patch on sparc64 and it worked as
 > >>>expected. However, the controller is fast ethernet so I'm not sure
 > >>>whether it makes any difference for you.
 > >>>I also CCed to marius@ because he may have better idea on this
 > >>>issue. I wouldn't be available for 2~3 weeks starting from this
 > >>>weekend.  I guess it's not acceptable to leave the issue there
 > >>>without fixing it for more than 2 weeks. I'm also happy to revert
 > >>>the guilty change set. Hopefully I may be able to find more time to
 > >>>identify the root cause of the issue after returning back from
 > >>>the vacation.
 > >>
 > >>Sorry to disappoint, but this has the same result -- I had to  
 > >>ifconfig
 > >>down/up for it to work.
 > >>
 > >
 > >:-(
 > >
 > >>The 'gem0: cannot disable (T/R)X MAC' messages are curious as  
 > >>well.  I
 > >>don't know what relation they have with my problem, though, because
 > >>they still appear when I revert r222135 (and gem0 works fine), but
 > >>weren't there until I performed the initial update.
 > >>
 > >
 > >I think gem_intr() looks somewhat odd. It seems the interrupt
 > >handler does not check whether driver is running or not. If the
 > >interrupt is shared with other devices or default interrupt mask
 > >allows interrupts after device reset(e.g. PHY interrupt or RX
 > >interrupts before initializing controller after device attach) it
 > >may cause problems. However I'm not sure whether you're seeing this
 > >issue. Marius, what's your opinion?
 > >
 > >Here is updated patch.
 > >
 > >>- Justin
 > 
 > Unfortunately that still did not fix the problem, I got the same  
 
 It still shows the 'gem0: cannot disable (T/R)X MAC' messages?
 
 > results.  Do you want any more info from me (more dmesg/ifconfig, full  
 > hardware specs, etc)?
 > 
 
 I think you already posted dmesg/ifconfig output.
 I guess you're using DHCP, right? How about booting box without unplug
 UTP cable plugged in? Another thing that would be interesting would
 be to know whether the controller still sees RX packets when you
 notice controller does not work.
 
 > - Justin
 > 

From: YongHyeon PYUN <pyunyh@gmail.com>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: marius@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Thu, 2 Jun 2011 10:49:47 -0700

 On Wed, Jun 01, 2011 at 07:06:24PM -0700, YongHyeon PYUN wrote:
 > On Wed, Jun 01, 2011 at 09:50:16PM -0400, Justin Hibbits wrote:
 > > On Jun 1, 2011, at 7:16 PM, YongHyeon PYUN wrote:
 > > 
 > > >On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > > >>On May 31, 2011, at 10:19 PM, YongHyeon PYUN wrote:
 > > >>
 > > >>>On Tue, May 31, 2011 at 06:09:57PM -0400, Justin Hibbits wrote:
 > > >>>>On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 > > >>>>
 > > >>>>>On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 > > >>>>>>The following reply was made to PR kern/157405; it has been noted
 > > >>>>>>by GNATS.
 > > >>>>>>
 > > >>>>>>From: Justin Hibbits <jrh29@alumni.cwru.edu>
 > > >>>>>>To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 > > >>>>>>Cc:
 > > >>>>>>Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC
 > > >>>>>>Mac
 > > >>>>>>Date: Sun, 29 May 2011 22:20:24 -0400
 > > >>>>>>
 > > >>>>>
 > > >>>>>[...]
 > > >>>>>
 > > >>>>>>Thanks for the quick reply.
 > > >>>>>>
 > > >>>>>>The patched sort of fixed it, but I had to manually bring down
 > > >>>>>>and up
 > > >>>>>>the interface before it actually worked, because until I did all
 > > >>>>>>operations hanged and timed out.
 > > >>>>>>
 > > >>>>>>I've attached the 'bad' dmesg, the 'patched' dmesg, and the
 > > >>>>>>'patched'
 > > >>>>>>ifconfig.
 > > >>>>>>
 > > >>>>>
 > > >>>>>Thanks for testing. I see the following messages from driver.
 > > >>>>>gem0: cannot disable TX MAC
 > > >>>>>gem0: cannot disable RX MAC
 > > >>>>>Were the message there before r222135?
 > > >>>>>Anyway, would you try updated patch?
 > > >>>>
 > > >>>>I just tried the patch, and got the same result:  It works if I
 > > >>>>ifconfig down/up it first.
 > > >>>>
 > > >>>>- Justin
 > > >>>
 > > >>>k, next try. I've tested this patch on sparc64 and it worked as
 > > >>>expected. However, the controller is fast ethernet so I'm not sure
 > > >>>whether it makes any difference for you.
 > > >>>I also CCed to marius@ because he may have better idea on this
 > > >>>issue. I wouldn't be available for 2~3 weeks starting from this
 > > >>>weekend.  I guess it's not acceptable to leave the issue there
 > > >>>without fixing it for more than 2 weeks. I'm also happy to revert
 > > >>>the guilty change set. Hopefully I may be able to find more time to
 > > >>>identify the root cause of the issue after returning back from
 > > >>>the vacation.
 > > >>
 > > >>Sorry to disappoint, but this has the same result -- I had to  
 > > >>ifconfig
 > > >>down/up for it to work.
 > > >>
 > > >
 > > >:-(
 > > >
 > > >>The 'gem0: cannot disable (T/R)X MAC' messages are curious as  
 > > >>well.  I
 > > >>don't know what relation they have with my problem, though, because
 > > >>they still appear when I revert r222135 (and gem0 works fine), but
 > > >>weren't there until I performed the initial update.
 > > >>
 > > >
 > > >I think gem_intr() looks somewhat odd. It seems the interrupt
 > > >handler does not check whether driver is running or not. If the
 > > >interrupt is shared with other devices or default interrupt mask
 > > >allows interrupts after device reset(e.g. PHY interrupt or RX
 > > >interrupts before initializing controller after device attach) it
 > > >may cause problems. However I'm not sure whether you're seeing this
 > > >issue. Marius, what's your opinion?
 > > >
 > > >Here is updated patch.
 > > >
 > > >>- Justin
 > > 
 > > Unfortunately that still did not fix the problem, I got the same  
 > 
 > It still shows the 'gem0: cannot disable (T/R)X MAC' messages?
 > 
 > > results.  Do you want any more info from me (more dmesg/ifconfig, full  
 > > hardware specs, etc)?
 > > 
 > 
 > I think you already posted dmesg/ifconfig output.
 > I guess you're using DHCP, right? How about booting box without unplug
 > UTP cable plugged in? Another thing that would be interesting would
 > be to know whether the controller still sees RX packets when you
 > notice controller does not work.
 
 If you can still see RX packets, the following patch may help you.
 http://people.freebsd.org/~yongari/gem/gem.link.diff6

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: pyunyh@gmail.com
Cc: marius@FreeBSD.org,
 bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Thu, 2 Jun 2011 17:27:01 -0400

 On Jun 2, 2011, at 1:49 PM, YongHyeon PYUN wrote:
 
 > On Wed, Jun 01, 2011 at 07:06:24PM -0700, YongHyeon PYUN wrote:
 >> On Wed, Jun 01, 2011 at 09:50:16PM -0400, Justin Hibbits wrote:
 >>> On Jun 1, 2011, at 7:16 PM, YongHyeon PYUN wrote:
 >>>
 >>>> On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 >>>>> On May 31, 2011, at 10:19 PM, YongHyeon PYUN wrote:
 >>>>>
 >>>>>> On Tue, May 31, 2011 at 06:09:57PM -0400, Justin Hibbits wrote:
 >>>>>>> On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 >>>>>>>
 >>>>>>>> On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 >>>>>>>>> The following reply was made to PR kern/157405; it has been  
 >>>>>>>>> noted
 >>>>>>>>> by GNATS.
 >>>>>>>>>
 >>>>>>>>> From: Justin Hibbits <jrh29@alumni.cwru.edu>
 >>>>>>>>> To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 >>>>>>>>> Cc:
 >>>>>>>>> Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on  
 >>>>>>>>> PowerPC
 >>>>>>>>> Mac
 >>>>>>>>> Date: Sun, 29 May 2011 22:20:24 -0400
 >>>>>>>>>
 >>>>>>>>
 >>>>>>>> [...]
 >>>>>>>>
 >>>>>>>>> Thanks for the quick reply.
 >>>>>>>>>
 >>>>>>>>> The patched sort of fixed it, but I had to manually bring down
 >>>>>>>>> and up
 >>>>>>>>> the interface before it actually worked, because until I did  
 >>>>>>>>> all
 >>>>>>>>> operations hanged and timed out.
 >>>>>>>>>
 >>>>>>>>> I've attached the 'bad' dmesg, the 'patched' dmesg, and the
 >>>>>>>>> 'patched'
 >>>>>>>>> ifconfig.
 >>>>>>>>>
 >>>>>>>>
 >>>>>>>> Thanks for testing. I see the following messages from driver.
 >>>>>>>> gem0: cannot disable TX MAC
 >>>>>>>> gem0: cannot disable RX MAC
 >>>>>>>> Were the message there before r222135?
 >>>>>>>> Anyway, would you try updated patch?
 >>>>>>>
 >>>>>>> I just tried the patch, and got the same result:  It works if I
 >>>>>>> ifconfig down/up it first.
 >>>>>>>
 >>>>>>> - Justin
 >>>>>>
 >>>>>> k, next try. I've tested this patch on sparc64 and it worked as
 >>>>>> expected. However, the controller is fast ethernet so I'm not  
 >>>>>> sure
 >>>>>> whether it makes any difference for you.
 >>>>>> I also CCed to marius@ because he may have better idea on this
 >>>>>> issue. I wouldn't be available for 2~3 weeks starting from this
 >>>>>> weekend.  I guess it's not acceptable to leave the issue there
 >>>>>> without fixing it for more than 2 weeks. I'm also happy to revert
 >>>>>> the guilty change set. Hopefully I may be able to find more  
 >>>>>> time to
 >>>>>> identify the root cause of the issue after returning back from
 >>>>>> the vacation.
 >>>>>
 >>>>> Sorry to disappoint, but this has the same result -- I had to
 >>>>> ifconfig
 >>>>> down/up for it to work.
 >>>>>
 >>>>
 >>>> :-(
 >>>>
 >>>>> The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 >>>>> well.  I
 >>>>> don't know what relation they have with my problem, though,  
 >>>>> because
 >>>>> they still appear when I revert r222135 (and gem0 works fine), but
 >>>>> weren't there until I performed the initial update.
 >>>>>
 >>>>
 >>>> I think gem_intr() looks somewhat odd. It seems the interrupt
 >>>> handler does not check whether driver is running or not. If the
 >>>> interrupt is shared with other devices or default interrupt mask
 >>>> allows interrupts after device reset(e.g. PHY interrupt or RX
 >>>> interrupts before initializing controller after device attach) it
 >>>> may cause problems. However I'm not sure whether you're seeing this
 >>>> issue. Marius, what's your opinion?
 >>>>
 >>>> Here is updated patch.
 >>>>
 >>>>> - Justin
 >>>
 >>> Unfortunately that still did not fix the problem, I got the same
 >>
 >> It still shows the 'gem0: cannot disable (T/R)X MAC' messages?
 
 Yes, it shows both messages twice.
 
 >>
 >>> results.  Do you want any more info from me (more dmesg/ifconfig,  
 >>> full
 >>> hardware specs, etc)?
 >>>
 >>
 >> I think you already posted dmesg/ifconfig output.
 >> I guess you're using DHCP, right? How about booting box without  
 >> unplug
 >> UTP cable plugged in? Another thing that would be interesting would
 >> be to know whether the controller still sees RX packets when you
 >> notice controller does not work.
 >
 > If you can still see RX packets, the following patch may help you.
 > http://people.freebsd.org/~yongari/gem/gem.link.diff6
 
 
 Actually, I'm using static configuration.
 
 I see 14 Ipkts (netstat -n -i gem0) after startup on the <Link#4>  
 Network (MAC address, not IP address), but nothing more if I ping.
 
 That last diff didn't help either, unfortunately :(
 
 - Justin

From: Marius Strobl <marius@alchemy.franken.de>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: pyunyh@gmail.com, bug-followup@freebsd.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Wed, 8 Jun 2011 22:56:32 +0200

 On Thu, Jun 02, 2011 at 05:27:01PM -0400, Justin Hibbits wrote:
 > On Jun 2, 2011, at 1:49 PM, YongHyeon PYUN wrote:
 > 
 > >On Wed, Jun 01, 2011 at 07:06:24PM -0700, YongHyeon PYUN wrote:
 > >>On Wed, Jun 01, 2011 at 09:50:16PM -0400, Justin Hibbits wrote:
 > >>>On Jun 1, 2011, at 7:16 PM, YongHyeon PYUN wrote:
 > >>>
 > >>>>On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > >>>>>On May 31, 2011, at 10:19 PM, YongHyeon PYUN wrote:
 > >>>>>
 > >>>>>>On Tue, May 31, 2011 at 06:09:57PM -0400, Justin Hibbits wrote:
 > >>>>>>>On May 30, 2011, at 6:19 PM, YongHyeon PYUN wrote:
 > >>>>>>>
 > >>>>>>>>On Mon, May 30, 2011 at 02:50:06AM +0000, Justin Hibbits wrote:
 > >>>>>>>>>The following reply was made to PR kern/157405; it has been  
 > >>>>>>>>>noted
 > >>>>>>>>>by GNATS.
 > >>>>>>>>>
 > >>>>>>>>>From: Justin Hibbits <jrh29@alumni.cwru.edu>
 > >>>>>>>>>To: "bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
 > >>>>>>>>>Cc:
 > >>>>>>>>>Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on  
 > >>>>>>>>>PowerPC
 > >>>>>>>>>Mac
 > >>>>>>>>>Date: Sun, 29 May 2011 22:20:24 -0400
 > >>>>>>>>>
 > >>>>>>>>
 > >>>>>>>>[...]
 > >>>>>>>>
 > >>>>>>>>>Thanks for the quick reply.
 > >>>>>>>>>
 > >>>>>>>>>The patched sort of fixed it, but I had to manually bring down
 > >>>>>>>>>and up
 > >>>>>>>>>the interface before it actually worked, because until I did  
 > >>>>>>>>>all
 > >>>>>>>>>operations hanged and timed out.
 > >>>>>>>>>
 > >>>>>>>>>I've attached the 'bad' dmesg, the 'patched' dmesg, and the
 > >>>>>>>>>'patched'
 > >>>>>>>>>ifconfig.
 > >>>>>>>>>
 > >>>>>>>>
 > >>>>>>>>Thanks for testing. I see the following messages from driver.
 > >>>>>>>>gem0: cannot disable TX MAC
 > >>>>>>>>gem0: cannot disable RX MAC
 > >>>>>>>>Were the message there before r222135?
 > >>>>>>>>Anyway, would you try updated patch?
 > >>>>>>>
 > >>>>>>>I just tried the patch, and got the same result:  It works if I
 > >>>>>>>ifconfig down/up it first.
 > >>>>>>>
 > >>>>>>>- Justin
 > >>>>>>
 > >>>>>>k, next try. I've tested this patch on sparc64 and it worked as
 > >>>>>>expected. However, the controller is fast ethernet so I'm not  
 > >>>>>>sure
 > >>>>>>whether it makes any difference for you.
 > >>>>>>I also CCed to marius@ because he may have better idea on this
 > >>>>>>issue. I wouldn't be available for 2~3 weeks starting from this
 > >>>>>>weekend.  I guess it's not acceptable to leave the issue there
 > >>>>>>without fixing it for more than 2 weeks. I'm also happy to revert
 > >>>>>>the guilty change set. Hopefully I may be able to find more  
 > >>>>>>time to
 > >>>>>>identify the root cause of the issue after returning back from
 > >>>>>>the vacation.
 > >>>>>
 > >>>>>Sorry to disappoint, but this has the same result -- I had to
 > >>>>>ifconfig
 > >>>>>down/up for it to work.
 > >>>>>
 > >>>>
 > >>>>:-(
 > >>>>
 > >>>>>The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 > >>>>>well.  I
 > >>>>>don't know what relation they have with my problem, though,  
 > >>>>>because
 > >>>>>they still appear when I revert r222135 (and gem0 works fine), but
 > >>>>>weren't there until I performed the initial update.
 > >>>>>
 > >>>>
 > >>>>I think gem_intr() looks somewhat odd. It seems the interrupt
 > >>>>handler does not check whether driver is running or not. If the
 > >>>>interrupt is shared with other devices or default interrupt mask
 > >>>>allows interrupts after device reset(e.g. PHY interrupt or RX
 > >>>>interrupts before initializing controller after device attach) it
 > >>>>may cause problems. However I'm not sure whether you're seeing this
 > >>>>issue. Marius, what's your opinion?
 > >>>>
 > >>>>Here is updated patch.
 > >>>>
 > >>>>>- Justin
 > >>>
 > >>>Unfortunately that still did not fix the problem, I got the same
 > >>
 > >>It still shows the 'gem0: cannot disable (T/R)X MAC' messages?
 > 
 > Yes, it shows both messages twice.
 > 
 > >>
 > >>>results.  Do you want any more info from me (more dmesg/ifconfig,  
 > >>>full
 > >>>hardware specs, etc)?
 > >>>
 > >>
 > >>I think you already posted dmesg/ifconfig output.
 > >>I guess you're using DHCP, right? How about booting box without  
 > >>unplug
 > >>UTP cable plugged in? Another thing that would be interesting would
 > >>be to know whether the controller still sees RX packets when you
 > >>notice controller does not work.
 > >
 > >If you can still see RX packets, the following patch may help you.
 > >http://people.freebsd.org/~yongari/gem/gem.link.diff6
 > 
 > 
 > Actually, I'm using static configuration.
 > 
 > I see 14 Ipkts (netstat -n -i gem0) after startup on the <Link#4>  
 > Network (MAC address, not IP address), but nothing more if I ping.
 > 
 > That last diff didn't help either, unfortunately :(
 > 
 
 Unfortunately, this doesn't ring a bell here and currently I just
 don't have the time to look into it, sorry.
 
 Marius
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/157405: commit references a PR
Date: Sun, 17 Jul 2011 21:54:59 +0000 (UTC)

 Author: yongari
 Date: Sun Jul 17 21:54:51 2011
 New Revision: 224157
 URL: http://svn.freebsd.org/changeset/base/224157
 
 Log:
   Revert r222135 by allowing controller reinitialization.  Due to
   unknown reason Apple UniNorth2 gem(4) device required manual
   interface down/up operation after r222135.  Even though this is not
   correct thing and I don't like to revert it but it would be better
   than breaking gem(4) on PPC.  This should be revisited.
   
   PR:	kern/157405
 
 Modified:
   head/sys/dev/gem/if_gem.c
 
 Modified: head/sys/dev/gem/if_gem.c
 ==============================================================================
 --- head/sys/dev/gem/if_gem.c	Sun Jul 17 21:53:42 2011	(r224156)
 +++ head/sys/dev/gem/if_gem.c	Sun Jul 17 21:54:51 2011	(r224157)
 @@ -947,8 +947,10 @@ gem_init_locked(struct gem_softc *sc)
  
  	GEM_LOCK_ASSERT(sc, MA_OWNED);
  
 +#ifdef notyet
  	if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0)
  		return;
 +#endif
  
  #ifdef GEM_DEBUG
  	CTR2(KTR_GEM, "%s: %s: calling stop", device_get_name(sc->sc_dev),
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: feedback->patched 
State-Changed-By: yongari 
State-Changed-When: Sun Jul 17 22:01:41 UTC 2011 
State-Changed-Why:  
Patch committed to HEAD(r224157). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=157405 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/157405: commit references a PR
Date: Mon, 25 Jul 2011 20:12:46 +0000 (UTC)

 Author: yongari
 Date: Mon Jul 25 20:12:31 2011
 New Revision: 224401
 URL: http://svn.freebsd.org/changeset/base/224401
 
 Log:
   MFC r224157:
     Revert r222135 by allowing controller reinitialization.  Due to
     unknown reason Apple UniNorth2 gem(4) device required manual
     interface down/up operation after r222135.  Even though this is not
     correct thing and I don't like to revert it but it would be better
     than breaking gem(4) on PPC.  This should be revisited.
   
     PR:	kern/157405
 
 Modified:
   stable/8/sys/dev/gem/if_gem.c
 Directory Properties:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
   stable/8/sys/geom/label/   (props changed)
 
 Modified: stable/8/sys/dev/gem/if_gem.c
 ==============================================================================
 --- stable/8/sys/dev/gem/if_gem.c	Mon Jul 25 20:10:01 2011	(r224400)
 +++ stable/8/sys/dev/gem/if_gem.c	Mon Jul 25 20:12:31 2011	(r224401)
 @@ -947,8 +947,10 @@ gem_init_locked(struct gem_softc *sc)
  
  	GEM_LOCK_ASSERT(sc, MA_OWNED);
  
 +#ifdef notyet
  	if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0)
  		return;
 +#endif
  
  #ifdef GEM_DEBUG
  	CTR2(KTR_GEM, "%s: %s: calling stop", device_get_name(sc->sc_dev),
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/157405: commit references a PR
Date: Mon, 25 Jul 2011 20:13:43 +0000 (UTC)

 Author: yongari
 Date: Mon Jul 25 20:13:35 2011
 New Revision: 224402
 URL: http://svn.freebsd.org/changeset/base/224402
 
 Log:
   MFC r224157:
     Revert r222135 by allowing controller reinitialization.  Due to
     unknown reason Apple UniNorth2 gem(4) device required manual
     interface down/up operation after r222135.  Even though this is not
     correct thing and I don't like to revert it but it would be better
     than breaking gem(4) on PPC.  This should be revisited.
   
     PR:	kern/157405
 
 Modified:
   stable/7/sys/dev/gem/if_gem.c
 Directory Properties:
   stable/7/sys/   (props changed)
   stable/7/sys/cddl/contrib/opensolaris/   (props changed)
   stable/7/sys/contrib/dev/acpica/   (props changed)
   stable/7/sys/contrib/pf/   (props changed)
 
 Modified: stable/7/sys/dev/gem/if_gem.c
 ==============================================================================
 --- stable/7/sys/dev/gem/if_gem.c	Mon Jul 25 20:12:31 2011	(r224401)
 +++ stable/7/sys/dev/gem/if_gem.c	Mon Jul 25 20:13:35 2011	(r224402)
 @@ -947,8 +947,10 @@ gem_init_locked(struct gem_softc *sc)
  
  	GEM_LOCK_ASSERT(sc, MA_OWNED);
  
 +#ifdef notyet
  	if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0)
  		return;
 +#endif
  
  #ifdef GEM_DEBUG
  	CTR2(KTR_GEM, "%s: %s: calling stop", device_get_name(sc->sc_dev),
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: yongari 
State-Changed-When: Mon Jul 25 20:39:52 UTC 2011 
State-Changed-Why:  
MFC to both stable/8 and stable/7 complete. 
Thanks for testing and reporting. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=157405 

From: Marius Strobl <marius@alchemy.franken.de>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: pyunyh@gmail.com, bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Thu, 4 Aug 2011 15:53:36 +0200

 On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > 
 > The 'gem0: cannot disable (T/R)X MAC' messages are curious as well.  I  
 > don't know what relation they have with my problem, though, because  
 > they still appear when I revert r222135 (and gem0 works fine), but  
 > weren't there until I performed the initial update.
 > 
 
 The behavior of the GMAC hardware regarding both r222135 and causing
 these warnings really is strange an it isn't unlikely that the two
 issues are related. Could you maybe do a binary search to determine
 the exact revision which triggers these warnings as it seems some
 change outside of gem(4) is causing them but I have no idea what that
 could be.
 
 Marius
 

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: pyunyh@gmail.com,
 bug-followup@FreeBSD.org
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Thu, 4 Aug 2011 23:00:47 -0400

 On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 
 > On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 >>
 >> The 'gem0: cannot disable (T/R)X MAC' messages are curious as  
 >> well.  I
 >> don't know what relation they have with my problem, though, because
 >> they still appear when I revert r222135 (and gem0 works fine), but
 >> weren't there until I performed the initial update.
 >>
 >
 > The behavior of the GMAC hardware regarding both r222135 and causing
 > these warnings really is strange an it isn't unlikely that the two
 > issues are related. Could you maybe do a binary search to determine
 > the exact revision which triggers these warnings as it seems some
 > change outside of gem(4) is causing them but I have no idea what that
 > could be.
 >
 > Marius
 >
 
 I'll try to find some time to do this binary search this weekend.  It  
 may take some time, though, because building the kernel takes about 45  
 minutes each time on my hardware.
 
 - Justin

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: pyunyh@gmail.com,
 "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sat, 6 Aug 2011 20:36:58 -0400

 On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 
 > On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 >>
 >> The 'gem0: cannot disable (T/R)X MAC' messages are curious as  
 >> well.  I
 >> don't know what relation they have with my problem, though, because
 >> they still appear when I revert r222135 (and gem0 works fine), but
 >> weren't there until I performed the initial update.
 >>
 >
 > The behavior of the GMAC hardware regarding both r222135 and causing
 > these warnings really is strange an it isn't unlikely that the two
 > issues are related. Could you maybe do a binary search to determine
 > the exact revision which triggers these warnings as it seems some
 > change outside of gem(4) is causing them but I have no idea what that
 > could be.
 >
 > Marius
 >
 
 Marius,
 
 I just performed a binary search, and tracked it to r221812 as the  
 culprit, a change made to mii_physubr.c.
 
 - Justin

From: Marius Strobl <marius@alchemy.franken.de>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: pyunyh@gmail.com,
        "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sun, 7 Aug 2011 03:43:48 +0200

 --fdj2RfSjLxBAspz7
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 > On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 > 
 > >On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > >>
 > >>The 'gem0: cannot disable (T/R)X MAC' messages are curious as  
 > >>well.  I
 > >>don't know what relation they have with my problem, though, because
 > >>they still appear when I revert r222135 (and gem0 works fine), but
 > >>weren't there until I performed the initial update.
 > >>
 > >
 > >The behavior of the GMAC hardware regarding both r222135 and causing
 > >these warnings really is strange an it isn't unlikely that the two
 > >issues are related. Could you maybe do a binary search to determine
 > >the exact revision which triggers these warnings as it seems some
 > >change outside of gem(4) is causing them but I have no idea what that
 > >could be.
 > >
 > >Marius
 > >
 > 
 > Marius,
 > 
 > I just performed a binary search, and tracked it to r221812 as the  
 > culprit, a change made to mii_physubr.c.
 > 
 
 Thanks a lot for tracking this down! Unfortunately, r221812 causing this
 doesn't make a whole lot of sense so I'd need some additional testing so
 I hopefully can figure out what could be going on. With current sources
 please do the following tests:
 1) Run a kernel built with the attached mii_physubr.c.diff and let me
    know the debugging output.
 2) Additionally use if_gem.c.diff and again let me know the debugging
    output and whether this makes any difference regarding the "cannot
    disable" messages.
 3) Test a kernel with the above two reverted, r221812 reverted and the
    "#ifdef notyet" in gem_init_locked() removed so we know wheter the
    messages and the original problem of this PR are in fact related.
 
 Marius
 
 
 --fdj2RfSjLxBAspz7
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="mii_physubr.c.diff"
 
 Index: mii_physubr.c
 ===================================================================
 --- mii_physubr.c	(revision 224216)
 +++ mii_physubr.c	(working copy)
 @@ -259,6 +259,7 @@
  	struct ifmedia_entry *ife = sc->mii_pdata->mii_media.ifm_cur;
  	int i, reg;
  
 +printf("%s: before reset 0x%x\n", __func__, PHY_READ(sc, MII_BMCR));
  	if ((sc->mii_flags & MIIF_NOISOLATE) != 0)
  		reg = BMCR_RESET;
  	else
 @@ -272,6 +273,7 @@
  			break;
  		DELAY(1000);
  	}
 +printf("%s: after reset 0x%x\n", __func__, reg);
  
  	/* NB: a PHY may default to isolation. */
  	reg &= ~BMCR_ISO;
 @@ -279,6 +281,7 @@
  	    ((ife == NULL && sc->mii_inst != 0) ||
  	    (ife != NULL && IFM_INST(ife->ifm_media) != sc->mii_inst)))
  		reg |= BMCR_ISO;
 +printf("%s: reg 0x%x\n", __func__, reg);
  	if (PHY_READ(sc, MII_BMCR) != reg)
  		PHY_WRITE(sc, MII_BMCR, reg);
  }
 
 --fdj2RfSjLxBAspz7
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="if_gem.c.diff"
 
 Index: if_gem.c
 ===================================================================
 --- if_gem.c	(revision 224689)
 +++ if_gem.c	(working copy)
 @@ -302,7 +302,7 @@ gem_attach(struct gem_softc *sc)
  		}
  		error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp,
  		    gem_mediachange, gem_mediastatus, BMSR_DEFCAPMASK, phy,
 -		    MII_OFFSET_ANY, MIIF_DOPAUSE);
 +		    MII_OFFSET_ANY, MIIF_NOISOLATE | MIIF_DOPAUSE);
  	}
  
  	/*
 
 --fdj2RfSjLxBAspz7--

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: pyunyh@gmail.com,
 "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sun, 7 Aug 2011 11:36:35 -0400

 --Apple-Mail-3--583253909
 Content-Type: text/plain;
 	charset=US-ASCII;
 	format=flowed;
 	delsp=yes
 Content-Transfer-Encoding: 7bit
 
 On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 
 > On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 >> On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 >>
 >>> On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 >>>>
 >>>> The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 >>>> well.  I
 >>>> don't know what relation they have with my problem, though, because
 >>>> they still appear when I revert r222135 (and gem0 works fine), but
 >>>> weren't there until I performed the initial update.
 >>>>
 >>>
 >>> The behavior of the GMAC hardware regarding both r222135 and causing
 >>> these warnings really is strange an it isn't unlikely that the two
 >>> issues are related. Could you maybe do a binary search to determine
 >>> the exact revision which triggers these warnings as it seems some
 >>> change outside of gem(4) is causing them but I have no idea what  
 >>> that
 >>> could be.
 >>>
 >>> Marius
 >>>
 >>
 >> Marius,
 >>
 >> I just performed a binary search, and tracked it to r221812 as the
 >> culprit, a change made to mii_physubr.c.
 >>
 >
 > Thanks a lot for tracking this down! Unfortunately, r221812 causing  
 > this
 > doesn't make a whole lot of sense so I'd need some additional  
 > testing so
 > I hopefully can figure out what could be going on. With current  
 > sources
 > please do the following tests:
 > 1) Run a kernel built with the attached mii_physubr.c.diff and let me
 >   know the debugging output.
 > 2) Additionally use if_gem.c.diff and again let me know the debugging
 >   output and whether this makes any difference regarding the "cannot
 >   disable" messages.
 > 3) Test a kernel with the above two reverted, r221812 reverted and the
 >   "#ifdef notyet" in gem_init_locked() removed so we know wheter the
 >   messages and the original problem of this PR are in fact related.
 >
 > Marius
 
 I ran the three tests, and attached the dmesg output from the first 2  
 to this message.  The third test succeeded, I removed the #ifdef  
 notyet, and reverted r221812 of mii_physubr.c, and everything works  
 now, so it appears r221812 may be the culprit for this PR.
 
 - Justin
 
 --Apple-Mail-3--583253909
 Content-Disposition: attachment;
 	filename=dmesg.debug1
 Content-Type: application/octet-stream;
 	x-unix-mode=0644;
 	name="dmesg.debug1"
 Content-Transfer-Encoding: 7bit
 
 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 9.0-BETA1 #65 r224692M: Sun Aug  7 10:59:51 EDT 2011
     root@narn.knownspace:/usr/obj/usr/src/sys/NARN powerpc
 module snapper already present!
 module_register: module gem/miibus already exists!
 Module gem/miibus failed to register: 17
 module_register: module pci/gem already exists!
 Module pci/gem failed to register: 17
 cpu0: Motorola PowerPC 7455 revision 3.3, 1250.53 MHz
 cpu0: Features 9c000000<PPC32,ALTIVEC,FPU,MMU>
 cpu0: HID0 8450c0bc<EMCP,TBEN,NAP,DPM,ICE,DCE,SGE,BTIC,LRSTK,FOLD,BHT>
 real memory  = 2135564288 (2036 MB)
 avail memory = 2067001344 (1971 MB)
 kbd0 at kbdmux0
 nexus0: <Open Firmware Nexus device>
 cpulist0: <Open Firmware CPU Group> on nexus0
 cpu0: <Open Firmware CPU> on cpulist0
 powermac_nvram0: <Apple NVRAM> on nexus0
 powermac_nvram0: bank0 generation 408, bank1 generation 409
 unin0: <Apple UniNorth System Controller> on nexus0
 unin0: Version 36
 iichb0: <Keywest I2C controller> mem 0xf8001000-0xf8001fff irq 42 on unin0
 iicbus0: <OFW I2C bus> on iichb0
 adm10300: <G4 MDD Fan driver> at addr 0x58 on iicbus0
 iicbus0: <unknown card> at addr 0xca
 ds17750: <Temp-Monitor DS1775> at addr 0x92 on iicbus0
 pcib0: <Apple UniNorth Host-PCI bridge> on nexus0
 pci0: <OFW PCI bus> on pcib0
 agp0: <Apple UniNorth 2 AGP Bridge> on hostb0
 vgapci0: <VGA-compatible display> port 0x400-0x4ff mem 0xa0000000-0xafffffff,0x90000000-0x9000ffff irq 48 at device 16.0 on pci0
 pcib1: <Apple UniNorth Host-PCI bridge> on nexus0
 pci1: <OFW PCI bus> on pcib1
 macio0: <KeyLargo I/O Controller> mem 0x80000000-0x8007ffff at device 23.0 on pci1
 openpic0: <OpenPIC Interrupt Controller> mem 0x40000-0x7ffff on macio0
 macgpio0: <MacIO GPIO Controller> mem 0x50-0x7f on macio0
 pmuextint0: <Apple PMU99 External Interrupt> extint-gpio 1 irq 47 on macgpio0
 scc0: <Zilog Z8530 dual channel SCC> mem 0x13000-0x13fff,0x8400-0x84ff,0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 22,5,6,23,7,8 on macio0
 uart0: <z8530, channel A> on scc0
 uart1: <z8530, channel B> on scc0
 pcm0: <Apple I2S Audio Controller> mem 0x10000-0x10fff,0x8000-0x80ff,0x8100-0x81ff irq 30,1,2 on macio0
 pmu0: <Apple PMU99 Controller> mem 0x16000-0x17fff irq 25 on macio0
 iichb1: <Keywest I2C controller> mem 0x18000-0x18fff irq 26 on macio0
 iicbus1: <OFW I2C bus> on iichb1
 snapper0: <Texas Instruments TAS3004 Audio Codec> at addr 0x6a on iicbus1
 ata0: <Apple MacIO Ultra ATA Controller> mem 0x1f000-0x1ffff,0x8a00-0x8aff irq 19,11 on macio0
 ata1: <Apple MacIO ATA Controller> mem 0x20000-0x20fff,0x8b00-0x8bff irq 20,12 on macio0
 atapci0: <SiI 3112 SATA150 controller> port 0x440-0x447,0x430-0x433,0x420-0x427,0x410-0x413,0x400-0x40f mem 0x80080000-0x800801ff irq 58 at device 21.0 on pci1
 ata2: <ATA channel 0> on atapci0
 ata3: <ATA channel 1> on atapci0
 ohci0: <Apple KeyLargo USB controller> mem 0x80082000-0x80082fff irq 27 at device 24.0 on pci1
 usbus0: <Apple KeyLargo USB controller> on ohci0
 ohci1: <Apple KeyLargo USB controller> mem 0x80081000-0x80081fff irq 28 at device 25.0 on pci1
 usbus1: <Apple KeyLargo USB controller> on ohci1
 pcib2: <Apple UniNorth Host-PCI bridge> on nexus0
 pci2: <OFW PCI bus> on pcib2
 ata4: <Uninorth2 Kauai ATA Controller> mem 0xf5004000-0xf5007fff irq 39 at device 13.0 on pci2
 pci2: <serial bus, FireWire> at device 14.0 (no driver attached)
 gem0: <Apple UniNorth2 GMAC Ethernet> mem 0xf5200000-0xf53fffff irq 41 at device 15.0 on pci2
 miibus0: <MII bus> on gem0
 brgphy0: <BCM5421 1000BASE-T media interface> PHY 0 on miibus0
 mii_phy_reset: before reset 0x1800
 mii_phy_reset: after reset 0x1d40
 mii_phy_reset: reg 0x1940
 brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
 gem0: 10kB RX FIFO, 4kB TX FIFO
 gem0: Ethernet address: 00:0d:93:ac:7d:42
 sc0: <System console> on nexus0
 sc0: Unknown <16 virtual consoles, flags=0x300>
 Timecounter "timebase" frequency 41657957 Hz quality 0
 Event timer "decrementer" frequency 41657957 Hz quality 1000
 Timecounters tick every 1.000 msec
 usbus0: 12Mbps Full Speed USB v1.0
 usbus1: 12Mbps Full Speed USB v1.0
 ugen0.1: <Apple> at usbus0
 uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
 ugen1.1: <Apple> at usbus1
 uhub1: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
 uhub0: 2 ports with 2 removable, self powered
 uhub1: 2 ports with 2 removable, self powered
 ugen0.2: <Mitsumi Electric> at usbus0
 uhub2: <Mitsumi Electric Hub in Apple Extended USB Keyboard, class 9/0, rev 1.10/1.22, addr 2> on usbus0
 ada0 at ata2 bus 0 scbus2 target 0 lun 0
 ada0: <ST3500320AS SD04> ATA-7 SATA 1.x device
 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
 ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
 ada0: Previously was known as ad0
 cd0 at ata1 bus 0 scbus1 target 0 lun 0
 cd0: <HL-DT-ST RW/DVD GCC-4480B 1.03> Removable CD-ROM SCSI-0 device 
 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
 cd0: Attempt to query device size failed: NOT READY, Medium not present
 ada1 at ata4 bus 0 scbus4 target 0 lun 0
 ada1: <ST360015A 3.31> ATA-6 device
 ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
 ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C)
 ada1: Previously was known as ad1
 ada2 at ata4 bus 0 scbus4 target 1 lun 0
 ada2: <WDC WD1200JB-00CRA1 17.07W17> ATA-5 device
 ada2: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
 ada2: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C)
 ada2: Previously was known as ad2
 uhub2: 3 ports with 2 removable, bus powered
 Root mount waiting for: usbus0
 ugen0.3: <Mitsumi Electric> at usbus0
 ukbd0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 3> on usbus0
 kbd1 at ukbd0
 uhid0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 3> on usbus0
 Root mount waiting for: usbus0
 ugen0.4: <Logitech> at usbus0
 ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/11.10, addr 4> on usbus0
 ums0: 3 buttons and [XYZ] coordinates ID=0
 Trying to mount root from ufs:/dev/ufs/root [rw]...
 mii_phy_reset: before reset 0x1940
 mii_phy_reset: after reset 0x1d40
 mii_phy_reset: reg 0x1940
 mii_phy_reset: before reset 0x1940
 mii_phy_reset: after reset 0x1d40
 mii_phy_reset: reg 0x1940
 gem0: cannot disable TX MAC
 gem0: cannot disable RX MAC
 gem0: cannot disable RX MAC or hash filter
 gem0: cannot disable TX MAC
 gem0: cannot disable RX MAC
 gem0: cannot disable RX MAC
 gem0: cannot reset RX MAC
 gem0: cannot disable RX MAC
 gem0: cannot reset RX MAC
 mii_phy_reset: before reset 0x1540
 mii_phy_reset: after reset 0x1540
 mii_phy_reset: reg 0x1140
 mii_phy_reset: before reset 0x1140
 mii_phy_reset: after reset 0x1540
 mii_phy_reset: reg 0x1140
 mii_phy_reset: before reset 0x1000
 mii_phy_reset: after reset 0x1540
 mii_phy_reset: reg 0x1140
 mii_phy_reset: before reset 0x1140
 mii_phy_reset: after reset 0x1540
 mii_phy_reset: reg 0x1140
 
 --Apple-Mail-3--583253909
 Content-Disposition: attachment;
 	filename=dmesg.debug2
 Content-Type: application/octet-stream;
 	x-unix-mode=0644;
 	name="dmesg.debug2"
 Content-Transfer-Encoding: 7bit
 
 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 9.0-BETA1 #66 r224692M: Sun Aug  7 11:10:45 EDT 2011
     root@narn.knownspace:/usr/obj/usr/src/sys/NARN powerpc
 module snapper already present!
 module_register: module gem/miibus already exists!
 Module gem/miibus failed to register: 17
 module_register: module pci/gem already exists!
 Module pci/gem failed to register: 17
 cpu0: Motorola PowerPC 7455 revision 3.3, 1250.54 MHz
 cpu0: Features 9c000000<PPC32,ALTIVEC,FPU,MMU>
 cpu0: HID0 8450c0bc<EMCP,TBEN,NAP,DPM,ICE,DCE,SGE,BTIC,LRSTK,FOLD,BHT>
 real memory  = 2135564288 (2036 MB)
 avail memory = 2067001344 (1971 MB)
 kbd0 at kbdmux0
 nexus0: <Open Firmware Nexus device>
 cpulist0: <Open Firmware CPU Group> on nexus0
 cpu0: <Open Firmware CPU> on cpulist0
 powermac_nvram0: <Apple NVRAM> on nexus0
 powermac_nvram0: bank0 generation 408, bank1 generation 409
 unin0: <Apple UniNorth System Controller> on nexus0
 unin0: Version 36
 iichb0: <Keywest I2C controller> mem 0xf8001000-0xf8001fff irq 42 on unin0
 iicbus0: <OFW I2C bus> on iichb0
 adm10300: <G4 MDD Fan driver> at addr 0x58 on iicbus0
 iicbus0: <unknown card> at addr 0xca
 ds17750: <Temp-Monitor DS1775> at addr 0x92 on iicbus0
 pcib0: <Apple UniNorth Host-PCI bridge> on nexus0
 pci0: <OFW PCI bus> on pcib0
 agp0: <Apple UniNorth 2 AGP Bridge> on hostb0
 vgapci0: <VGA-compatible display> port 0x400-0x4ff mem 0xa0000000-0xafffffff,0x90000000-0x9000ffff irq 48 at device 16.0 on pci0
 pcib1: <Apple UniNorth Host-PCI bridge> on nexus0
 pci1: <OFW PCI bus> on pcib1
 macio0: <KeyLargo I/O Controller> mem 0x80000000-0x8007ffff at device 23.0 on pci1
 openpic0: <OpenPIC Interrupt Controller> mem 0x40000-0x7ffff on macio0
 macgpio0: <MacIO GPIO Controller> mem 0x50-0x7f on macio0
 pmuextint0: <Apple PMU99 External Interrupt> extint-gpio 1 irq 47 on macgpio0
 scc0: <Zilog Z8530 dual channel SCC> mem 0x13000-0x13fff,0x8400-0x84ff,0x8500-0x85ff,0x8600-0x86ff,0x8700-0x87ff irq 22,5,6,23,7,8 on macio0
 uart0: <z8530, channel A> on scc0
 uart1: <z8530, channel B> on scc0
 pcm0: <Apple I2S Audio Controller> mem 0x10000-0x10fff,0x8000-0x80ff,0x8100-0x81ff irq 30,1,2 on macio0
 pmu0: <Apple PMU99 Controller> mem 0x16000-0x17fff irq 25 on macio0
 iichb1: <Keywest I2C controller> mem 0x18000-0x18fff irq 26 on macio0
 iicbus1: <OFW I2C bus> on iichb1
 snapper0: <Texas Instruments TAS3004 Audio Codec> at addr 0x6a on iicbus1
 ata0: <Apple MacIO Ultra ATA Controller> mem 0x1f000-0x1ffff,0x8a00-0x8aff irq 19,11 on macio0
 ata1: <Apple MacIO ATA Controller> mem 0x20000-0x20fff,0x8b00-0x8bff irq 20,12 on macio0
 atapci0: <SiI 3112 SATA150 controller> port 0x440-0x447,0x430-0x433,0x420-0x427,0x410-0x413,0x400-0x40f mem 0x80080000-0x800801ff irq 58 at device 21.0 on pci1
 ata2: <ATA channel 0> on atapci0
 ata3: <ATA channel 1> on atapci0
 ohci0: <Apple KeyLargo USB controller> mem 0x80082000-0x80082fff irq 27 at device 24.0 on pci1
 usbus0: <Apple KeyLargo USB controller> on ohci0
 ohci1: <Apple KeyLargo USB controller> mem 0x80081000-0x80081fff irq 28 at device 25.0 on pci1
 usbus1: <Apple KeyLargo USB controller> on ohci1
 pcib2: <Apple UniNorth Host-PCI bridge> on nexus0
 pci2: <OFW PCI bus> on pcib2
 ata4: <Uninorth2 Kauai ATA Controller> mem 0xf5004000-0xf5007fff irq 39 at device 13.0 on pci2
 pci2: <serial bus, FireWire> at device 14.0 (no driver attached)
 gem0: <Apple UniNorth2 GMAC Ethernet> mem 0xf5200000-0xf53fffff irq 41 at device 15.0 on pci2
 miibus0: <MII bus> on gem0
 brgphy0: <BCM5421 1000BASE-T media interface> PHY 0 on miibus0
 mii_phy_reset: before reset 0x1800
 mii_phy_reset: after reset 0x1d40
 mii_phy_reset: reg 0x1940
 brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
 gem0: 10kB RX FIFO, 4kB TX FIFO
 gem0: Ethernet address: 00:0d:93:ac:7d:42
 sc0: <System console> on nexus0
 sc0: Unknown <16 virtual consoles, flags=0x300>
 Timecounter "timebase" frequency 41657957 Hz quality 0
 Event timer "decrementer" frequency 41657957 Hz quality 1000
 Timecounters tick every 1.000 msec
 usbus0: 12Mbps Full Speed USB v1.0
 usbus1: 12Mbps Full Speed USB v1.0
 ugen0.1: <Apple> at usbus0
 uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
 ugen1.1: <Apple> at usbus1
 uhub1: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
 uhub0: 2 ports with 2 removable, self powered
 uhub1: 2 ports with 2 removable, self powered
 ugen0.2: <Mitsumi Electric> at usbus0
 uhub2: <Mitsumi Electric Hub in Apple Extended USB Keyboard, class 9/0, rev 1.10/1.22, addr 2> on usbus0
 ada0 at ata2 bus 0 scbus2 target 0 lun 0
 ada0: <ST3500320AS SD04> ATA-7 SATA 1.x device
 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
 ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
 ada0: Previously was known as ad0
 cd0 at ata1 bus 0 scbus1 target 0 lun 0
 cd0: <HL-DT-ST RW/DVD GCC-4480B 1.03> Removable CD-ROM SCSI-0 device 
 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes)
 cd0: Attempt to query device size failed: NOT READY, Medium not present
 ada1 at ata4 bus 0 scbus4 target 0 lun 0
 ada1: <ST360015A 3.31> ATA-6 device
 ada1: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
 ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C)
 ada1: Previously was known as ad1
 ada2 at ata4 bus 0 scbus4 target 1 lun 0
 ada2: <WDC WD1200JB-00CRA1 17.07W17> ATA-5 device
 ada2: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
 ada2: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C)
 ada2: Previously was known as ad2
 uhub2: 3 ports with 2 removable, bus powered
 Root mount waiting for: usbus0
 ugen0.3: <Mitsumi Electric> at usbus0
 ukbd0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 3> on usbus0
 kbd1 at ukbd0
 uhid0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/1.22, addr 3> on usbus0
 Root mount waiting for: usbus0
 ugen0.4: <Logitech> at usbus0
 ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/11.10, addr 4> on usbus0
 ums0: 3 buttons and [XYZ] coordinates ID=0
 Trying to mount root from ufs:/dev/ufs/root [rw]...
 mii_phy_reset: before reset 0x1940
 mii_phy_reset: after reset 0x1d40
 mii_phy_reset: reg 0x1940
 mii_phy_reset: before reset 0x1940
 mii_phy_reset: after reset 0x1d40
 mii_phy_reset: reg 0x1940
 gem0: cannot disable TX MAC
 gem0: cannot disable RX MAC
 gem0: cannot disable RX MAC or hash filter
 gem0: cannot disable TX MAC
 gem0: cannot disable RX MAC
 gem0: cannot disable RX MAC
 gem0: cannot reset RX MAC
 gem0: cannot disable RX MAC
 gem0: cannot reset RX MAC
 mii_phy_reset: before reset 0x1540
 mii_phy_reset: after reset 0x1540
 mii_phy_reset: reg 0x1140
 mii_phy_reset: before reset 0x1140
 mii_phy_reset: after reset 0x1540
 mii_phy_reset: reg 0x1140
 mii_phy_reset: before reset 0x1000
 mii_phy_reset: after reset 0x1540
 mii_phy_reset: reg 0x1140
 mii_phy_reset: before reset 0x1140
 mii_phy_reset: after reset 0x1540
 mii_phy_reset: reg 0x1140
 
 --Apple-Mail-3--583253909
 Content-Type: text/plain;
 	charset=US-ASCII;
 	format=flowed
 Content-Transfer-Encoding: 7bit
 
 
 
 --Apple-Mail-3--583253909--

From: Marius Strobl <marius@alchemy.franken.de>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: pyunyh@gmail.com,
        "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sun, 7 Aug 2011 18:39:13 +0200

 --MAH+hnPXVZWQ5cD/
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 > On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 > 
 > >On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 > >>On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 > >>
 > >>>On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > >>>>
 > >>>>The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 > >>>>well.  I
 > >>>>don't know what relation they have with my problem, though, because
 > >>>>they still appear when I revert r222135 (and gem0 works fine), but
 > >>>>weren't there until I performed the initial update.
 > >>>>
 > >>>
 > >>>The behavior of the GMAC hardware regarding both r222135 and causing
 > >>>these warnings really is strange an it isn't unlikely that the two
 > >>>issues are related. Could you maybe do a binary search to determine
 > >>>the exact revision which triggers these warnings as it seems some
 > >>>change outside of gem(4) is causing them but I have no idea what  
 > >>>that
 > >>>could be.
 > >>>
 > >>>Marius
 > >>>
 > >>
 > >>Marius,
 > >>
 > >>I just performed a binary search, and tracked it to r221812 as the
 > >>culprit, a change made to mii_physubr.c.
 > >>
 > >
 > >Thanks a lot for tracking this down! Unfortunately, r221812 causing  
 > >this
 > >doesn't make a whole lot of sense so I'd need some additional  
 > >testing so
 > >I hopefully can figure out what could be going on. With current  
 > >sources
 > >please do the following tests:
 > >1) Run a kernel built with the attached mii_physubr.c.diff and let me
 > >  know the debugging output.
 > >2) Additionally use if_gem.c.diff and again let me know the debugging
 > >  output and whether this makes any difference regarding the "cannot
 > >  disable" messages.
 > >3) Test a kernel with the above two reverted, r221812 reverted and the
 > >  "#ifdef notyet" in gem_init_locked() removed so we know wheter the
 > >  messages and the original problem of this PR are in fact related.
 > >
 > >Marius
 > 
 > I ran the three tests, and attached the dmesg output from the first 2  
 > to this message.  The third test succeeded, I removed the #ifdef  
 > notyet, and reverted r221812 of mii_physubr.c, and everything works  
 > now, so it appears r221812 may be the culprit for this PR.
 > 
 
 Err, okay, so it worked as long as we left the PHY in powered down and
 isolated state but now that we de-isolate the PHY before using it the
 MAC wedges, funny ...
 Could you please try with both r221812 and the attached patch applied
 and ideally the "#ifdef notyet" still removed?
 
 Marius
 
 
 --MAH+hnPXVZWQ5cD/
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="mii_physubr_reset_default_may_power_down.diff"
 
 Index: mii_physubr.c
 ===================================================================
 --- mii_physubr.c	(revision 224216)
 +++ mii_physubr.c	(working copy)
 @@ -273,8 +273,8 @@ mii_phy_reset(struct mii_softc *sc)
  		DELAY(1000);
  	}
  
 -	/* NB: a PHY may default to isolation. */
 -	reg &= ~BMCR_ISO;
 +	/* NB: a PHY may default to being powered down and isolated. */
 +	reg &= ~(BMCR_PDOWN | BMCR_ISO);
  	if ((sc->mii_flags & MIIF_NOISOLATE) == 0 &&
  	    ((ife == NULL && sc->mii_inst != 0) ||
  	    (ife != NULL && IFM_INST(ife->ifm_media) != sc->mii_inst)))
 
 --MAH+hnPXVZWQ5cD/--

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: pyunyh@gmail.com,
 "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sun, 7 Aug 2011 16:25:20 -0400

 On Aug 7, 2011, at 12:39 PM, Marius Strobl wrote:
 
 > On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 >> On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 >>
 >>> On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 >>>> On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 >>>>
 >>>>> On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 >>>>>>
 >>>>>> The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 >>>>>> well.  I
 >>>>>> don't know what relation they have with my problem, though,  
 >>>>>> because
 >>>>>> they still appear when I revert r222135 (and gem0 works fine),  
 >>>>>> but
 >>>>>> weren't there until I performed the initial update.
 >>>>>>
 >>>>>
 >>>>> The behavior of the GMAC hardware regarding both r222135 and  
 >>>>> causing
 >>>>> these warnings really is strange an it isn't unlikely that the two
 >>>>> issues are related. Could you maybe do a binary search to  
 >>>>> determine
 >>>>> the exact revision which triggers these warnings as it seems some
 >>>>> change outside of gem(4) is causing them but I have no idea what
 >>>>> that
 >>>>> could be.
 >>>>>
 >>>>> Marius
 >>>>>
 >>>>
 >>>> Marius,
 >>>>
 >>>> I just performed a binary search, and tracked it to r221812 as the
 >>>> culprit, a change made to mii_physubr.c.
 >>>>
 >>>
 >>> Thanks a lot for tracking this down! Unfortunately, r221812 causing
 >>> this
 >>> doesn't make a whole lot of sense so I'd need some additional
 >>> testing so
 >>> I hopefully can figure out what could be going on. With current
 >>> sources
 >>> please do the following tests:
 >>> 1) Run a kernel built with the attached mii_physubr.c.diff and let  
 >>> me
 >>> know the debugging output.
 >>> 2) Additionally use if_gem.c.diff and again let me know the  
 >>> debugging
 >>> output and whether this makes any difference regarding the "cannot
 >>> disable" messages.
 >>> 3) Test a kernel with the above two reverted, r221812 reverted and  
 >>> the
 >>> "#ifdef notyet" in gem_init_locked() removed so we know wheter the
 >>> messages and the original problem of this PR are in fact related.
 >>>
 >>> Marius
 >>
 >> I ran the three tests, and attached the dmesg output from the first 2
 >> to this message.  The third test succeeded, I removed the #ifdef
 >> notyet, and reverted r221812 of mii_physubr.c, and everything works
 >> now, so it appears r221812 may be the culprit for this PR.
 >>
 >
 > Err, okay, so it worked as long as we left the PHY in powered down and
 > isolated state but now that we de-isolate the PHY before using it the
 > MAC wedges, funny ...
 > Could you please try with both r221812 and the attached patch applied
 > and ideally the "#ifdef notyet" still removed?
 >
 > Marius
 >
 > <mii_physubr_reset_default_may_power_down.diff>
 
 That patch worked nicely.  no errors, interface came right up.
 
 - Justin

From: Marius Strobl <marius@alchemy.franken.de>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: pyunyh@gmail.com,
        "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sun, 7 Aug 2011 22:54:40 +0200

 On Sun, Aug 07, 2011 at 04:25:20PM -0400, Justin Hibbits wrote:
 > On Aug 7, 2011, at 12:39 PM, Marius Strobl wrote:
 > 
 > >On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 > >>On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 > >>
 > >>>On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 > >>>>On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 > >>>>
 > >>>>>On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > >>>>>>
 > >>>>>>The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 > >>>>>>well.  I
 > >>>>>>don't know what relation they have with my problem, though,  
 > >>>>>>because
 > >>>>>>they still appear when I revert r222135 (and gem0 works fine),  
 > >>>>>>but
 > >>>>>>weren't there until I performed the initial update.
 > >>>>>>
 > >>>>>
 > >>>>>The behavior of the GMAC hardware regarding both r222135 and  
 > >>>>>causing
 > >>>>>these warnings really is strange an it isn't unlikely that the two
 > >>>>>issues are related. Could you maybe do a binary search to  
 > >>>>>determine
 > >>>>>the exact revision which triggers these warnings as it seems some
 > >>>>>change outside of gem(4) is causing them but I have no idea what
 > >>>>>that
 > >>>>>could be.
 > >>>>>
 > >>>>>Marius
 > >>>>>
 > >>>>
 > >>>>Marius,
 > >>>>
 > >>>>I just performed a binary search, and tracked it to r221812 as the
 > >>>>culprit, a change made to mii_physubr.c.
 > >>>>
 > >>>
 > >>>Thanks a lot for tracking this down! Unfortunately, r221812 causing
 > >>>this
 > >>>doesn't make a whole lot of sense so I'd need some additional
 > >>>testing so
 > >>>I hopefully can figure out what could be going on. With current
 > >>>sources
 > >>>please do the following tests:
 > >>>1) Run a kernel built with the attached mii_physubr.c.diff and let  
 > >>>me
 > >>>know the debugging output.
 > >>>2) Additionally use if_gem.c.diff and again let me know the  
 > >>>debugging
 > >>>output and whether this makes any difference regarding the "cannot
 > >>>disable" messages.
 > >>>3) Test a kernel with the above two reverted, r221812 reverted and  
 > >>>the
 > >>>"#ifdef notyet" in gem_init_locked() removed so we know wheter the
 > >>>messages and the original problem of this PR are in fact related.
 > >>>
 > >>>Marius
 > >>
 > >>I ran the three tests, and attached the dmesg output from the first 2
 > >>to this message.  The third test succeeded, I removed the #ifdef
 > >>notyet, and reverted r221812 of mii_physubr.c, and everything works
 > >>now, so it appears r221812 may be the culprit for this PR.
 > >>
 > >
 > >Err, okay, so it worked as long as we left the PHY in powered down and
 > >isolated state but now that we de-isolate the PHY before using it the
 > >MAC wedges, funny ...
 > >Could you please try with both r221812 and the attached patch applied
 > >and ideally the "#ifdef notyet" still removed?
 > >
 > >Marius
 > >
 > ><mii_physubr_reset_default_may_power_down.diff>
 > 
 > That patch worked nicely.  no errors, interface came right up.
 > 
 
 Okay, thanks for testing. Yongari, do you see any issue with also
 ensuring that a PHY is not powered down after reseting it in
 mii_phy_reset()? It would be nice if we actually powered down
 unused PHYs but given that we generally don't care about that and
 judging age(4) etc there actually seem to arise problems when
 doing so this seems rather pointless. The other option probably
 would be to ensure in brgphy_mii_phy_auto() that the PHY isn't
 powered down.
 
 Marius
 

From: Marius Strobl <marius@alchemy.franken.de>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: pyunyh@gmail.com,
        "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sun, 7 Aug 2011 22:58:49 +0200

 On Sun, Aug 07, 2011 at 10:54:40PM +0200, Marius Strobl wrote:
 > On Sun, Aug 07, 2011 at 04:25:20PM -0400, Justin Hibbits wrote:
 > > On Aug 7, 2011, at 12:39 PM, Marius Strobl wrote:
 > > 
 > > >On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 > > >>On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 > > >>
 > > >>>On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 > > >>>>On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 > > >>>>
 > > >>>>>On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > > >>>>>>
 > > >>>>>>The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 > > >>>>>>well.  I
 > > >>>>>>don't know what relation they have with my problem, though,  
 > > >>>>>>because
 > > >>>>>>they still appear when I revert r222135 (and gem0 works fine),  
 > > >>>>>>but
 > > >>>>>>weren't there until I performed the initial update.
 > > >>>>>>
 > > >>>>>
 > > >>>>>The behavior of the GMAC hardware regarding both r222135 and  
 > > >>>>>causing
 > > >>>>>these warnings really is strange an it isn't unlikely that the two
 > > >>>>>issues are related. Could you maybe do a binary search to  
 > > >>>>>determine
 > > >>>>>the exact revision which triggers these warnings as it seems some
 > > >>>>>change outside of gem(4) is causing them but I have no idea what
 > > >>>>>that
 > > >>>>>could be.
 > > >>>>>
 > > >>>>>Marius
 > > >>>>>
 > > >>>>
 > > >>>>Marius,
 > > >>>>
 > > >>>>I just performed a binary search, and tracked it to r221812 as the
 > > >>>>culprit, a change made to mii_physubr.c.
 > > >>>>
 > > >>>
 > > >>>Thanks a lot for tracking this down! Unfortunately, r221812 causing
 > > >>>this
 > > >>>doesn't make a whole lot of sense so I'd need some additional
 > > >>>testing so
 > > >>>I hopefully can figure out what could be going on. With current
 > > >>>sources
 > > >>>please do the following tests:
 > > >>>1) Run a kernel built with the attached mii_physubr.c.diff and let  
 > > >>>me
 > > >>>know the debugging output.
 > > >>>2) Additionally use if_gem.c.diff and again let me know the  
 > > >>>debugging
 > > >>>output and whether this makes any difference regarding the "cannot
 > > >>>disable" messages.
 > > >>>3) Test a kernel with the above two reverted, r221812 reverted and  
 > > >>>the
 > > >>>"#ifdef notyet" in gem_init_locked() removed so we know wheter the
 > > >>>messages and the original problem of this PR are in fact related.
 > > >>>
 > > >>>Marius
 > > >>
 > > >>I ran the three tests, and attached the dmesg output from the first 2
 > > >>to this message.  The third test succeeded, I removed the #ifdef
 > > >>notyet, and reverted r221812 of mii_physubr.c, and everything works
 > > >>now, so it appears r221812 may be the culprit for this PR.
 > > >>
 > > >
 > > >Err, okay, so it worked as long as we left the PHY in powered down and
 > > >isolated state but now that we de-isolate the PHY before using it the
 > > >MAC wedges, funny ...
 > > >Could you please try with both r221812 and the attached patch applied
 > > >and ideally the "#ifdef notyet" still removed?
 > > >
 > > >Marius
 > > >
 > > ><mii_physubr_reset_default_may_power_down.diff>
 > > 
 > > That patch worked nicely.  no errors, interface came right up.
 > > 
 > 
 > Okay, thanks for testing. Yongari, do you see any issue with also
 > ensuring that a PHY is not powered down after reseting it in
 > mii_phy_reset()? It would be nice if we actually powered down
 > unused PHYs but given that we generally don't care about that and
 > judging age(4) etc there actually seem to arise problems when
 > doing so this seems rather pointless. The other option probably
 > would be to ensure in brgphy_mii_phy_auto() that the PHY isn't
 > powered down.
 > 
 
 Err, brgphy_mii_phy_auto() already just writes BRGPHY_BMCR_AUTOEN |
 BRGPHY_BMCR_STARTNEG to the BMCR so there's nothing to fix there.
 
 Marius
 

From: YongHyeon PYUN <pyunyh@gmail.com>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: Justin Hibbits <jrh29@alumni.cwru.edu>,
	"bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@freebsd.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Sun, 7 Aug 2011 15:42:23 -0700

 On Sun, Aug 07, 2011 at 10:54:40PM +0200, Marius Strobl wrote:
 > On Sun, Aug 07, 2011 at 04:25:20PM -0400, Justin Hibbits wrote:
 > > On Aug 7, 2011, at 12:39 PM, Marius Strobl wrote:
 > > 
 > > >On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 > > >>On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 > > >>
 > > >>>On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 > > >>>>On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 > > >>>>
 > > >>>>>On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > > >>>>>>
 > > >>>>>>The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 > > >>>>>>well.  I
 > > >>>>>>don't know what relation they have with my problem, though,  
 > > >>>>>>because
 > > >>>>>>they still appear when I revert r222135 (and gem0 works fine),  
 > > >>>>>>but
 > > >>>>>>weren't there until I performed the initial update.
 > > >>>>>>
 > > >>>>>
 > > >>>>>The behavior of the GMAC hardware regarding both r222135 and  
 > > >>>>>causing
 > > >>>>>these warnings really is strange an it isn't unlikely that the two
 > > >>>>>issues are related. Could you maybe do a binary search to  
 > > >>>>>determine
 > > >>>>>the exact revision which triggers these warnings as it seems some
 > > >>>>>change outside of gem(4) is causing them but I have no idea what
 > > >>>>>that
 > > >>>>>could be.
 > > >>>>>
 > > >>>>>Marius
 > > >>>>>
 > > >>>>
 > > >>>>Marius,
 > > >>>>
 > > >>>>I just performed a binary search, and tracked it to r221812 as the
 > > >>>>culprit, a change made to mii_physubr.c.
 > > >>>>
 > > >>>
 > > >>>Thanks a lot for tracking this down! Unfortunately, r221812 causing
 > > >>>this
 > > >>>doesn't make a whole lot of sense so I'd need some additional
 > > >>>testing so
 > > >>>I hopefully can figure out what could be going on. With current
 > > >>>sources
 > > >>>please do the following tests:
 > > >>>1) Run a kernel built with the attached mii_physubr.c.diff and let  
 > > >>>me
 > > >>>know the debugging output.
 > > >>>2) Additionally use if_gem.c.diff and again let me know the  
 > > >>>debugging
 > > >>>output and whether this makes any difference regarding the "cannot
 > > >>>disable" messages.
 > > >>>3) Test a kernel with the above two reverted, r221812 reverted and  
 > > >>>the
 > > >>>"#ifdef notyet" in gem_init_locked() removed so we know wheter the
 > > >>>messages and the original problem of this PR are in fact related.
 > > >>>
 > > >>>Marius
 > > >>
 > > >>I ran the three tests, and attached the dmesg output from the first 2
 > > >>to this message.  The third test succeeded, I removed the #ifdef
 > > >>notyet, and reverted r221812 of mii_physubr.c, and everything works
 > > >>now, so it appears r221812 may be the culprit for this PR.
 > > >>
 > > >
 > > >Err, okay, so it worked as long as we left the PHY in powered down and
 > > >isolated state but now that we de-isolate the PHY before using it the
 > > >MAC wedges, funny ...
 > > >Could you please try with both r221812 and the attached patch applied
 > > >and ideally the "#ifdef notyet" still removed?
 > > >
 > > >Marius
 > > >
 > > ><mii_physubr_reset_default_may_power_down.diff>
 > > 
 > > That patch worked nicely.  no errors, interface came right up.
 > > 
 > 
 > Okay, thanks for testing. Yongari, do you see any issue with also
 > ensuring that a PHY is not powered down after reseting it in
 > mii_phy_reset()? It would be nice if we actually powered down
 
 Hmm, I guess the reverse case may cause problems on controllers
 with IPMI/ASF firmwares.  These firmwares may try to use shared
 MAC/PHY at the same time so that powering down the PHY shall break
 established IMPI/ASF traffic.  If this theory is correct, we may
 have broken bge(4)/bce(4) with IPMI/ASF firmware.  Could you check
 kern/158156 which seems to be related with this?
 
 > unused PHYs but given that we generally don't care about that and
 > judging age(4) etc there actually seem to arise problems when
 > doing so this seems rather pointless. The other option probably
 
 Agreed.  Powering down unused PHY is good thing but I guess most
 recent PCIe ethernet controllers have automatic PHY power down
 feature by detecting energy signal.  This wouldn't work if the host
 has a cable connected to switch though.  If we want to save more
 power it would be better to support EEE because system
 administrators can manually manually power down PHY.
 
 > would be to ensure in brgphy_mii_phy_auto() that the PHY isn't
 > powered down.
 > 
 > Marius
 > 
 
 Thanks a lot for working on this. :-)

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: pyunyh@gmail.com,
 "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Wed, 10 Aug 2011 22:39:48 -0400

 On Aug 7, 2011, at 4:54 PM, Marius Strobl wrote:
 
 > On Sun, Aug 07, 2011 at 04:25:20PM -0400, Justin Hibbits wrote:
 >> On Aug 7, 2011, at 12:39 PM, Marius Strobl wrote:
 >>
 >>> On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 >>>> On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 >>>>
 >>>>> On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 >>>>>> On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 >>>>>>
 >>>>>>> On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 >>>>>>>>
 >>>>>>>> The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 >>>>>>>> well.  I
 >>>>>>>> don't know what relation they have with my problem, though,
 >>>>>>>> because
 >>>>>>>> they still appear when I revert r222135 (and gem0 works fine),
 >>>>>>>> but
 >>>>>>>> weren't there until I performed the initial update.
 >>>>>>>>
 >>>>>>>
 >>>>>>> The behavior of the GMAC hardware regarding both r222135 and
 >>>>>>> causing
 >>>>>>> these warnings really is strange an it isn't unlikely that the  
 >>>>>>> two
 >>>>>>> issues are related. Could you maybe do a binary search to
 >>>>>>> determine
 >>>>>>> the exact revision which triggers these warnings as it seems  
 >>>>>>> some
 >>>>>>> change outside of gem(4) is causing them but I have no idea what
 >>>>>>> that
 >>>>>>> could be.
 >>>>>>>
 >>>>>>> Marius
 >>>>>>>
 >>>>>>
 >>>>>> Marius,
 >>>>>>
 >>>>>> I just performed a binary search, and tracked it to r221812 as  
 >>>>>> the
 >>>>>> culprit, a change made to mii_physubr.c.
 >>>>>>
 >>>>>
 >>>>> Thanks a lot for tracking this down! Unfortunately, r221812  
 >>>>> causing
 >>>>> this
 >>>>> doesn't make a whole lot of sense so I'd need some additional
 >>>>> testing so
 >>>>> I hopefully can figure out what could be going on. With current
 >>>>> sources
 >>>>> please do the following tests:
 >>>>> 1) Run a kernel built with the attached mii_physubr.c.diff and let
 >>>>> me
 >>>>> know the debugging output.
 >>>>> 2) Additionally use if_gem.c.diff and again let me know the
 >>>>> debugging
 >>>>> output and whether this makes any difference regarding the "cannot
 >>>>> disable" messages.
 >>>>> 3) Test a kernel with the above two reverted, r221812 reverted and
 >>>>> the
 >>>>> "#ifdef notyet" in gem_init_locked() removed so we know wheter the
 >>>>> messages and the original problem of this PR are in fact related.
 >>>>>
 >>>>> Marius
 >>>>
 >>>> I ran the three tests, and attached the dmesg output from the  
 >>>> first 2
 >>>> to this message.  The third test succeeded, I removed the #ifdef
 >>>> notyet, and reverted r221812 of mii_physubr.c, and everything works
 >>>> now, so it appears r221812 may be the culprit for this PR.
 >>>>
 >>>
 >>> Err, okay, so it worked as long as we left the PHY in powered down  
 >>> and
 >>> isolated state but now that we de-isolate the PHY before using it  
 >>> the
 >>> MAC wedges, funny ...
 >>> Could you please try with both r221812 and the attached patch  
 >>> applied
 >>> and ideally the "#ifdef notyet" still removed?
 >>>
 >>> Marius
 >>>
 >>> <mii_physubr_reset_default_may_power_down.diff>
 >>
 >> That patch worked nicely.  no errors, interface came right up.
 >>
 >
 > Okay, thanks for testing. Yongari, do you see any issue with also
 > ensuring that a PHY is not powered down after reseting it in
 > mii_phy_reset()? It would be nice if we actually powered down
 > unused PHYs but given that we generally don't care about that and
 > judging age(4) etc there actually seem to arise problems when
 > doing so this seems rather pointless. The other option probably
 > would be to ensure in brgphy_mii_phy_auto() that the PHY isn't
 > powered down.
 >
 > Marius
 >
 
 Is this change going to make it into 9-RELEASE?
 
 - Justin

From: Marius Strobl <marius@alchemy.franken.de>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: pyunyh@gmail.com,
        "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Thu, 11 Aug 2011 16:14:35 +0200

 On Wed, Aug 10, 2011 at 10:39:48PM -0400, Justin Hibbits wrote:
 > On Aug 7, 2011, at 4:54 PM, Marius Strobl wrote:
 > 
 > >On Sun, Aug 07, 2011 at 04:25:20PM -0400, Justin Hibbits wrote:
 > >>On Aug 7, 2011, at 12:39 PM, Marius Strobl wrote:
 > >>
 > >>>On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 > >>>>On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 > >>>>
 > >>>>>On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 > >>>>>>On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 > >>>>>>
 > >>>>>>>On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > >>>>>>>>
 > >>>>>>>>The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 > >>>>>>>>well.  I
 > >>>>>>>>don't know what relation they have with my problem, though,
 > >>>>>>>>because
 > >>>>>>>>they still appear when I revert r222135 (and gem0 works fine),
 > >>>>>>>>but
 > >>>>>>>>weren't there until I performed the initial update.
 > >>>>>>>>
 > >>>>>>>
 > >>>>>>>The behavior of the GMAC hardware regarding both r222135 and
 > >>>>>>>causing
 > >>>>>>>these warnings really is strange an it isn't unlikely that the  
 > >>>>>>>two
 > >>>>>>>issues are related. Could you maybe do a binary search to
 > >>>>>>>determine
 > >>>>>>>the exact revision which triggers these warnings as it seems  
 > >>>>>>>some
 > >>>>>>>change outside of gem(4) is causing them but I have no idea what
 > >>>>>>>that
 > >>>>>>>could be.
 > >>>>>>>
 > >>>>>>>Marius
 > >>>>>>>
 > >>>>>>
 > >>>>>>Marius,
 > >>>>>>
 > >>>>>>I just performed a binary search, and tracked it to r221812 as  
 > >>>>>>the
 > >>>>>>culprit, a change made to mii_physubr.c.
 > >>>>>>
 > >>>>>
 > >>>>>Thanks a lot for tracking this down! Unfortunately, r221812  
 > >>>>>causing
 > >>>>>this
 > >>>>>doesn't make a whole lot of sense so I'd need some additional
 > >>>>>testing so
 > >>>>>I hopefully can figure out what could be going on. With current
 > >>>>>sources
 > >>>>>please do the following tests:
 > >>>>>1) Run a kernel built with the attached mii_physubr.c.diff and let
 > >>>>>me
 > >>>>>know the debugging output.
 > >>>>>2) Additionally use if_gem.c.diff and again let me know the
 > >>>>>debugging
 > >>>>>output and whether this makes any difference regarding the "cannot
 > >>>>>disable" messages.
 > >>>>>3) Test a kernel with the above two reverted, r221812 reverted and
 > >>>>>the
 > >>>>>"#ifdef notyet" in gem_init_locked() removed so we know wheter the
 > >>>>>messages and the original problem of this PR are in fact related.
 > >>>>>
 > >>>>>Marius
 > >>>>
 > >>>>I ran the three tests, and attached the dmesg output from the  
 > >>>>first 2
 > >>>>to this message.  The third test succeeded, I removed the #ifdef
 > >>>>notyet, and reverted r221812 of mii_physubr.c, and everything works
 > >>>>now, so it appears r221812 may be the culprit for this PR.
 > >>>>
 > >>>
 > >>>Err, okay, so it worked as long as we left the PHY in powered down  
 > >>>and
 > >>>isolated state but now that we de-isolate the PHY before using it  
 > >>>the
 > >>>MAC wedges, funny ...
 > >>>Could you please try with both r221812 and the attached patch  
 > >>>applied
 > >>>and ideally the "#ifdef notyet" still removed?
 > >>>
 > >>>Marius
 > >>>
 > >>><mii_physubr_reset_default_may_power_down.diff>
 > >>
 > >>That patch worked nicely.  no errors, interface came right up.
 > >>
 > >
 > >Okay, thanks for testing. Yongari, do you see any issue with also
 > >ensuring that a PHY is not powered down after reseting it in
 > >mii_phy_reset()? It would be nice if we actually powered down
 > >unused PHYs but given that we generally don't care about that and
 > >judging age(4) etc there actually seem to arise problems when
 > >doing so this seems rather pointless. The other option probably
 > >would be to ensure in brgphy_mii_phy_auto() that the PHY isn't
 > >powered down.
 > >
 > >Marius
 > >
 > 
 > Is this change going to make it into 9-RELEASE?
 > 
 
 I intend to get a fix into 9.0-RELEASE. I'm currently waiting for feedback
 whether the patch also fixes PR 158156 and if it does not need to find
 another way to fix both PRs.
 
 Marius
 

From: Marius Strobl <marius@alchemy.franken.de>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: pyunyh@gmail.com,
        "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Tue, 16 Aug 2011 12:38:57 +0200

 --ReaqsoxgOBHFXBhH
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Thu, Aug 11, 2011 at 04:14:35PM +0200, Marius Strobl wrote:
 > On Wed, Aug 10, 2011 at 10:39:48PM -0400, Justin Hibbits wrote:
 > > On Aug 7, 2011, at 4:54 PM, Marius Strobl wrote:
 > > 
 > > >On Sun, Aug 07, 2011 at 04:25:20PM -0400, Justin Hibbits wrote:
 > > >>On Aug 7, 2011, at 12:39 PM, Marius Strobl wrote:
 > > >>
 > > >>>On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 > > >>>>On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 > > >>>>
 > > >>>>>On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 > > >>>>>>On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 > > >>>>>>
 > > >>>>>>>On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits wrote:
 > > >>>>>>>>
 > > >>>>>>>>The 'gem0: cannot disable (T/R)X MAC' messages are curious as
 > > >>>>>>>>well.  I
 > > >>>>>>>>don't know what relation they have with my problem, though,
 > > >>>>>>>>because
 > > >>>>>>>>they still appear when I revert r222135 (and gem0 works fine),
 > > >>>>>>>>but
 > > >>>>>>>>weren't there until I performed the initial update.
 > > >>>>>>>>
 > > >>>>>>>
 > > >>>>>>>The behavior of the GMAC hardware regarding both r222135 and
 > > >>>>>>>causing
 > > >>>>>>>these warnings really is strange an it isn't unlikely that the  
 > > >>>>>>>two
 > > >>>>>>>issues are related. Could you maybe do a binary search to
 > > >>>>>>>determine
 > > >>>>>>>the exact revision which triggers these warnings as it seems  
 > > >>>>>>>some
 > > >>>>>>>change outside of gem(4) is causing them but I have no idea what
 > > >>>>>>>that
 > > >>>>>>>could be.
 > > >>>>>>>
 > > >>>>>>>Marius
 > > >>>>>>>
 > > >>>>>>
 > > >>>>>>Marius,
 > > >>>>>>
 > > >>>>>>I just performed a binary search, and tracked it to r221812 as  
 > > >>>>>>the
 > > >>>>>>culprit, a change made to mii_physubr.c.
 > > >>>>>>
 > > >>>>>
 > > >>>>>Thanks a lot for tracking this down! Unfortunately, r221812  
 > > >>>>>causing
 > > >>>>>this
 > > >>>>>doesn't make a whole lot of sense so I'd need some additional
 > > >>>>>testing so
 > > >>>>>I hopefully can figure out what could be going on. With current
 > > >>>>>sources
 > > >>>>>please do the following tests:
 > > >>>>>1) Run a kernel built with the attached mii_physubr.c.diff and let
 > > >>>>>me
 > > >>>>>know the debugging output.
 > > >>>>>2) Additionally use if_gem.c.diff and again let me know the
 > > >>>>>debugging
 > > >>>>>output and whether this makes any difference regarding the "cannot
 > > >>>>>disable" messages.
 > > >>>>>3) Test a kernel with the above two reverted, r221812 reverted and
 > > >>>>>the
 > > >>>>>"#ifdef notyet" in gem_init_locked() removed so we know wheter the
 > > >>>>>messages and the original problem of this PR are in fact related.
 > > >>>>>
 > > >>>>>Marius
 > > >>>>
 > > >>>>I ran the three tests, and attached the dmesg output from the  
 > > >>>>first 2
 > > >>>>to this message.  The third test succeeded, I removed the #ifdef
 > > >>>>notyet, and reverted r221812 of mii_physubr.c, and everything works
 > > >>>>now, so it appears r221812 may be the culprit for this PR.
 > > >>>>
 > > >>>
 > > >>>Err, okay, so it worked as long as we left the PHY in powered down  
 > > >>>and
 > > >>>isolated state but now that we de-isolate the PHY before using it  
 > > >>>the
 > > >>>MAC wedges, funny ...
 > > >>>Could you please try with both r221812 and the attached patch  
 > > >>>applied
 > > >>>and ideally the "#ifdef notyet" still removed?
 > > >>>
 > > >>>Marius
 > > >>>
 > > >>><mii_physubr_reset_default_may_power_down.diff>
 > > >>
 > > >>That patch worked nicely.  no errors, interface came right up.
 > > >>
 > > >
 > > >Okay, thanks for testing. Yongari, do you see any issue with also
 > > >ensuring that a PHY is not powered down after reseting it in
 > > >mii_phy_reset()? It would be nice if we actually powered down
 > > >unused PHYs but given that we generally don't care about that and
 > > >judging age(4) etc there actually seem to arise problems when
 > > >doing so this seems rather pointless. The other option probably
 > > >would be to ensure in brgphy_mii_phy_auto() that the PHY isn't
 > > >powered down.
 > > >
 > > >Marius
 > > >
 > > 
 > > Is this change going to make it into 9-RELEASE?
 > > 
 > 
 > I intend to get a fix into 9.0-RELEASE. I'm currently waiting for feedback
 > whether the patch also fixes PR 158156 and if it does not need to find
 > another way to fix both PRs.
 > 
 
 As it turns out the previous patch isn't sufficient to also fix PR 158156.
 Could you please sanity check whether the attached patch also fixes your
 problem, i.e. whether the warning messages go away and gem(4) works with
 the "#ifdef notyet" removed? For this test it doesn't matter if you leave
 the previous patch for mii_physubr.c applied or not.
 
 Thanks,
 Marius
 
 
 --ReaqsoxgOBHFXBhH
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="brgphy_reset_no_deisolate_power_up.diff"
 
 Index: brgphy.c
 ===================================================================
 --- brgphy.c	(revision 224902)
 +++ brgphy.c	(working copy)
 @@ -876,11 +876,23 @@ brgphy_reset(struct mii_softc *sc)
  	struct bge_softc *bge_sc = NULL;
  	struct bce_softc *bce_sc = NULL;
  	struct ifnet *ifp;
 -	int val;
 +	int i, val;
  
 -	/* Perform a standard PHY reset. */
 -	mii_phy_reset(sc);
 +	/*
 +	 * Perform a reset.  Note that at least some Broadcom PHYs default to
 +	 * being powered down as well as isolated after a reset but don't work
 +	 * if one or both of these bits are cleared.  However, they just work
 +	 * fine if both bits remain set, so we don't use mii_phy_reset() here.
 +	 */
 +	PHY_WRITE(sc, BRGPHY_MII_BMCR, BRGPHY_BMCR_RESET);
  
 +	/* Wait 100ms for it to complete. */
 +	for (i = 0; i < 100; i++) {
 +		if ((PHY_READ(sc, BRGPHY_MII_BMCR) & BRGPHY_BMCR_RESET) == 0)
 +			break;
 +		DELAY(1000);
 +	}
 +
  	/* Handle any PHY specific procedures following the reset. */
  	switch (sc->mii_mpd_oui) {
  	case MII_OUI_BROADCOM:
 
 --ReaqsoxgOBHFXBhH--

From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: pyunyh@gmail.com,
 "bug-followup@freebsd.org bug-followup@freebsd.org" <bug-followup@FreeBSD.org>
Subject: Re: kern/157405: [gem] r222135 breaks gem(4) on PowerPC Mac
Date: Wed, 17 Aug 2011 22:55:13 -0400

 On Aug 16, 2011, at 6:38 AM, Marius Strobl wrote:
 
 > On Thu, Aug 11, 2011 at 04:14:35PM +0200, Marius Strobl wrote:
 >> On Wed, Aug 10, 2011 at 10:39:48PM -0400, Justin Hibbits wrote:
 >>> On Aug 7, 2011, at 4:54 PM, Marius Strobl wrote:
 >>>
 >>>> On Sun, Aug 07, 2011 at 04:25:20PM -0400, Justin Hibbits wrote:
 >>>>> On Aug 7, 2011, at 12:39 PM, Marius Strobl wrote:
 >>>>>
 >>>>>> On Sun, Aug 07, 2011 at 11:36:35AM -0400, Justin Hibbits wrote:
 >>>>>>> On Aug 6, 2011, at 9:43 PM, Marius Strobl wrote:
 >>>>>>>
 >>>>>>>> On Sat, Aug 06, 2011 at 08:36:58PM -0400, Justin Hibbits wrote:
 >>>>>>>>> On Aug 4, 2011, at 9:53 AM, Marius Strobl wrote:
 >>>>>>>>>
 >>>>>>>>>> On Wed, Jun 01, 2011 at 05:05:39PM -0400, Justin Hibbits  
 >>>>>>>>>> wrote:
 >>>>>>>>>>>
 >>>>>>>>>>> The 'gem0: cannot disable (T/R)X MAC' messages are curious  
 >>>>>>>>>>> as
 >>>>>>>>>>> well.  I
 >>>>>>>>>>> don't know what relation they have with my problem, though,
 >>>>>>>>>>> because
 >>>>>>>>>>> they still appear when I revert r222135 (and gem0 works  
 >>>>>>>>>>> fine),
 >>>>>>>>>>> but
 >>>>>>>>>>> weren't there until I performed the initial update.
 >>>>>>>>>>>
 >>>>>>>>>>
 >>>>>>>>>> The behavior of the GMAC hardware regarding both r222135 and
 >>>>>>>>>> causing
 >>>>>>>>>> these warnings really is strange an it isn't unlikely that  
 >>>>>>>>>> the
 >>>>>>>>>> two
 >>>>>>>>>> issues are related. Could you maybe do a binary search to
 >>>>>>>>>> determine
 >>>>>>>>>> the exact revision which triggers these warnings as it seems
 >>>>>>>>>> some
 >>>>>>>>>> change outside of gem(4) is causing them but I have no idea  
 >>>>>>>>>> what
 >>>>>>>>>> that
 >>>>>>>>>> could be.
 >>>>>>>>>>
 >>>>>>>>>> Marius
 >>>>>>>>>>
 >>>>>>>>>
 >>>>>>>>> Marius,
 >>>>>>>>>
 >>>>>>>>> I just performed a binary search, and tracked it to r221812 as
 >>>>>>>>> the
 >>>>>>>>> culprit, a change made to mii_physubr.c.
 >>>>>>>>>
 >>>>>>>>
 >>>>>>>> Thanks a lot for tracking this down! Unfortunately, r221812
 >>>>>>>> causing
 >>>>>>>> this
 >>>>>>>> doesn't make a whole lot of sense so I'd need some additional
 >>>>>>>> testing so
 >>>>>>>> I hopefully can figure out what could be going on. With current
 >>>>>>>> sources
 >>>>>>>> please do the following tests:
 >>>>>>>> 1) Run a kernel built with the attached mii_physubr.c.diff  
 >>>>>>>> and let
 >>>>>>>> me
 >>>>>>>> know the debugging output.
 >>>>>>>> 2) Additionally use if_gem.c.diff and again let me know the
 >>>>>>>> debugging
 >>>>>>>> output and whether this makes any difference regarding the  
 >>>>>>>> "cannot
 >>>>>>>> disable" messages.
 >>>>>>>> 3) Test a kernel with the above two reverted, r221812  
 >>>>>>>> reverted and
 >>>>>>>> the
 >>>>>>>> "#ifdef notyet" in gem_init_locked() removed so we know  
 >>>>>>>> wheter the
 >>>>>>>> messages and the original problem of this PR are in fact  
 >>>>>>>> related.
 >>>>>>>>
 >>>>>>>> Marius
 >>>>>>>
 >>>>>>> I ran the three tests, and attached the dmesg output from the
 >>>>>>> first 2
 >>>>>>> to this message.  The third test succeeded, I removed the #ifdef
 >>>>>>> notyet, and reverted r221812 of mii_physubr.c, and everything  
 >>>>>>> works
 >>>>>>> now, so it appears r221812 may be the culprit for this PR.
 >>>>>>>
 >>>>>>
 >>>>>> Err, okay, so it worked as long as we left the PHY in powered  
 >>>>>> down
 >>>>>> and
 >>>>>> isolated state but now that we de-isolate the PHY before using it
 >>>>>> the
 >>>>>> MAC wedges, funny ...
 >>>>>> Could you please try with both r221812 and the attached patch
 >>>>>> applied
 >>>>>> and ideally the "#ifdef notyet" still removed?
 >>>>>>
 >>>>>> Marius
 >>>>>>
 >>>>>> <mii_physubr_reset_default_may_power_down.diff>
 >>>>>
 >>>>> That patch worked nicely.  no errors, interface came right up.
 >>>>>
 >>>>
 >>>> Okay, thanks for testing. Yongari, do you see any issue with also
 >>>> ensuring that a PHY is not powered down after reseting it in
 >>>> mii_phy_reset()? It would be nice if we actually powered down
 >>>> unused PHYs but given that we generally don't care about that and
 >>>> judging age(4) etc there actually seem to arise problems when
 >>>> doing so this seems rather pointless. The other option probably
 >>>> would be to ensure in brgphy_mii_phy_auto() that the PHY isn't
 >>>> powered down.
 >>>>
 >>>> Marius
 >>>>
 >>>
 >>> Is this change going to make it into 9-RELEASE?
 >>>
 >>
 >> I intend to get a fix into 9.0-RELEASE. I'm currently waiting for  
 >> feedback
 >> whether the patch also fixes PR 158156 and if it does not need to  
 >> find
 >> another way to fix both PRs.
 >>
 >
 > As it turns out the previous patch isn't sufficient to also fix PR  
 > 158156.
 > Could you please sanity check whether the attached patch also fixes  
 > your
 > problem, i.e. whether the warning messages go away and gem(4) works  
 > with
 > the "#ifdef notyet" removed? For this test it doesn't matter if you  
 > leave
 > the previous patch for mii_physubr.c applied or not.
 >
 > Thanks,
 > Marius
 
 I just booted a kernel with this patch applied, as well as the  
 previous patch, and all appears to work fine.  I don't see those  
 warning messages.
 
 - Justin

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/157405: commit references a PR
Date: Fri, 19 Aug 2011 19:13:10 +0000 (UTC)

 Author: marius
 Date: Fri Aug 19 19:12:58 2011
 New Revision: 225014
 URL: http://svn.freebsd.org/changeset/base/225014
 
 Log:
   r221812 reveals that at least some Broadcom PHYs default to being not only
   isolated but also powered down after a reset and while they just work fine
   [sic] when both is the case they don't if they are only deisolate but still
   powered down. So in order to put PHYs in an overall normal operation mode
   for the common case, ensure in mii_phy_reset() that they are not powered
   down after a reset. Unfortunately, this only helps in case of BCM5421,
   while BCM5709S apparently only work when they remain isolated and powered
   down after a reset. So don't call mii_phy_reset() in brgphy_reset() and
   implement the reset locally leaving the problematic bits alone. Effectively
   this bypasses r221812 for brgphy(4).
   Thanks to Justin Hibbits for doing a binary search in order to identify
   the problematic commit.
   
   PR:		157405, 158156
   Reviewed by:	yongari (mii_phy_reset() part)
   Approved by:	re (kib)
   MFC after:	3 days
 
 Modified:
   head/sys/dev/mii/brgphy.c
   head/sys/dev/mii/mii_physubr.c
 
 Modified: head/sys/dev/mii/brgphy.c
 ==============================================================================
 --- head/sys/dev/mii/brgphy.c	Fri Aug 19 15:21:13 2011	(r225013)
 +++ head/sys/dev/mii/brgphy.c	Fri Aug 19 19:12:58 2011	(r225014)
 @@ -876,10 +876,22 @@ brgphy_reset(struct mii_softc *sc)
  	struct bge_softc *bge_sc = NULL;
  	struct bce_softc *bce_sc = NULL;
  	struct ifnet *ifp;
 -	int val;
 +	int i, val;
  
 -	/* Perform a standard PHY reset. */
 -	mii_phy_reset(sc);
 +	/*
 +	 * Perform a reset.  Note that at least some Broadcom PHYs default to
 +	 * being powered down as well as isolated after a reset but don't work
 +	 * if one or both of these bits are cleared.  However, they just work
 +	 * fine if both bits remain set, so we don't use mii_phy_reset() here.
 +	 */
 +	PHY_WRITE(sc, BRGPHY_MII_BMCR, BRGPHY_BMCR_RESET);
 +
 +	/* Wait 100ms for it to complete. */
 +	for (i = 0; i < 100; i++) {
 +		if ((PHY_READ(sc, BRGPHY_MII_BMCR) & BRGPHY_BMCR_RESET) == 0)
 +			break;
 +		DELAY(1000);
 +	}
  
  	/* Handle any PHY specific procedures following the reset. */
  	switch (sc->mii_mpd_oui) {
 
 Modified: head/sys/dev/mii/mii_physubr.c
 ==============================================================================
 --- head/sys/dev/mii/mii_physubr.c	Fri Aug 19 15:21:13 2011	(r225013)
 +++ head/sys/dev/mii/mii_physubr.c	Fri Aug 19 19:12:58 2011	(r225014)
 @@ -273,8 +273,8 @@ mii_phy_reset(struct mii_softc *sc)
  		DELAY(1000);
  	}
  
 -	/* NB: a PHY may default to isolation. */
 -	reg &= ~BMCR_ISO;
 +	/* NB: a PHY may default to being powered down and/or isolated. */
 +	reg &= ~(BMCR_PDOWN | BMCR_ISO);
  	if ((sc->mii_flags & MIIF_NOISOLATE) == 0 &&
  	    ((ife == NULL && sc->mii_inst != 0) ||
  	    (ife != NULL && IFM_INST(ife->ifm_media) != sc->mii_inst)))
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/157405: commit references a PR
Date: Tue, 23 Aug 2011 14:33:22 +0000 (UTC)

 Author: marius
 Date: Tue Aug 23 14:32:53 2011
 New Revision: 225116
 URL: http://svn.freebsd.org/changeset/base/225116
 
 Log:
   MFC: r225014
   
   r221812 (MFC'ed to stable/8 in r222159) reveals that at least some Broadcom
   PHYs default to being not only isolated but also powered down after a reset
   and while they just work fine [sic] when both is the case they don't if they
   are only deisolate but still powered down. So in order to put PHYs in an
   overall normal operation mode for the common case, ensure in mii_phy_reset()
   that they are not powered down after a reset. Unfortunately, this only helps
   in case of BCM5421, while BCM5709S apparently only work when they remain
   isolated and powered down after a reset. So don't call mii_phy_reset() in
   brgphy_reset() and implement the reset locally leaving the problematic bits
   alone. Effectively this bypasses r221812 for brgphy(4).
   Thanks to Justin Hibbits for doing a binary search in order to identify
   the problematic commit.
   
   PR:		157405, 158156
   Reviewed by:	yongari (mii_phy_reset() part)
 
 Modified:
   stable/8/sys/dev/mii/brgphy.c
   stable/8/sys/dev/mii/mii_physubr.c
 Directory Properties:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
 
 Modified: stable/8/sys/dev/mii/brgphy.c
 ==============================================================================
 --- stable/8/sys/dev/mii/brgphy.c	Tue Aug 23 14:01:04 2011	(r225115)
 +++ stable/8/sys/dev/mii/brgphy.c	Tue Aug 23 14:32:53 2011	(r225116)
 @@ -913,10 +913,22 @@ brgphy_reset(struct mii_softc *sc)
  	struct bge_softc *bge_sc = NULL;
  	struct bce_softc *bce_sc = NULL;
  	struct ifnet *ifp;
 -	int val;
 +	int i, val;
  
 -	/* Perform a standard PHY reset. */
 -	mii_phy_reset(sc);
 +	/*
 +	 * Perform a reset.  Note that at least some Broadcom PHYs default to
 +	 * being powered down as well as isolated after a reset but don't work
 +	 * if one or both of these bits are cleared.  However, they just work
 +	 * fine if both bits remain set, so we don't use mii_phy_reset() here.
 +	 */
 +	PHY_WRITE(sc, BRGPHY_MII_BMCR, BRGPHY_BMCR_RESET);
 +
 +	/* Wait 100ms for it to complete. */
 +	for (i = 0; i < 100; i++) {
 +		if ((PHY_READ(sc, BRGPHY_MII_BMCR) & BRGPHY_BMCR_RESET) == 0)
 +			break;
 +		DELAY(1000);
 +	}
  
  	/* Handle any PHY specific procedures following the reset. */
  	switch (bsc->mii_oui) {
 
 Modified: stable/8/sys/dev/mii/mii_physubr.c
 ==============================================================================
 --- stable/8/sys/dev/mii/mii_physubr.c	Tue Aug 23 14:01:04 2011	(r225115)
 +++ stable/8/sys/dev/mii/mii_physubr.c	Tue Aug 23 14:32:53 2011	(r225116)
 @@ -276,8 +276,8 @@ mii_phy_reset(struct mii_softc *sc)
  		DELAY(1000);
  	}
  
 -	/* NB: a PHY may default to isolation. */
 -	reg &= ~BMCR_ISO;
 +	/* NB: a PHY may default to being powered down and/or isolated. */
 +	reg &= ~(BMCR_PDOWN | BMCR_ISO);
  	if ((sc->mii_flags & MIIF_NOISOLATE) == 0 &&
  	    ((ife == NULL && sc->mii_inst != 0) ||
  	    (ife != NULL && IFM_INST(ife->ifm_media) != sc->mii_inst)))
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/157405: commit references a PR
Date: Tue, 23 Aug 2011 14:33:27 +0000 (UTC)

 Author: marius
 Date: Tue Aug 23 14:32:59 2011
 New Revision: 225117
 URL: http://svn.freebsd.org/changeset/base/225117
 
 Log:
   MFC: r225014
   
   r221812 (MFC'ed to stable/7 in r222160) reveals that at least some Broadcom
   PHYs default to being not only isolated but also powered down after a reset
   and while they just work fine [sic] when both is the case they don't if they
   are only deisolate but still powered down. So in order to put PHYs in an
   overall normal operation mode for the common case, ensure in mii_phy_reset()
   that they are not powered down after a reset. Unfortunately, this only helps
   in case of BCM5421, while BCM5709S apparently only work when they remain
   isolated and powered down after a reset. So don't call mii_phy_reset() in
   brgphy_reset() and implement the reset locally leaving the problematic bits
   alone. Effectively this bypasses r221812 for brgphy(4).
   Thanks to Justin Hibbits for doing a binary search in order to identify
   the problematic commit.
   
   PR:		157405, 158156
   Reviewed by:	yongari (mii_phy_reset() part)
 
 Modified:
   stable/7/sys/dev/mii/brgphy.c
   stable/7/sys/dev/mii/mii_physubr.c
 Directory Properties:
   stable/7/sys/   (props changed)
   stable/7/sys/cddl/contrib/opensolaris/   (props changed)
   stable/7/sys/contrib/dev/acpica/   (props changed)
   stable/7/sys/contrib/pf/   (props changed)
 
 Modified: stable/7/sys/dev/mii/brgphy.c
 ==============================================================================
 --- stable/7/sys/dev/mii/brgphy.c	Tue Aug 23 14:32:53 2011	(r225116)
 +++ stable/7/sys/dev/mii/brgphy.c	Tue Aug 23 14:32:59 2011	(r225117)
 @@ -913,10 +913,22 @@ brgphy_reset(struct mii_softc *sc)
  	struct bge_softc *bge_sc = NULL;
  	struct bce_softc *bce_sc = NULL;
  	struct ifnet *ifp;
 -	int val;
 +	int i, val;
  
 -	/* Perform a standard PHY reset. */
 -	mii_phy_reset(sc);
 +	/*
 +	 * Perform a reset.  Note that at least some Broadcom PHYs default to
 +	 * being powered down as well as isolated after a reset but don't work
 +	 * if one or both of these bits are cleared.  However, they just work
 +	 * fine if both bits remain set, so we don't use mii_phy_reset() here.
 +	 */
 +	PHY_WRITE(sc, BRGPHY_MII_BMCR, BRGPHY_BMCR_RESET);
 +
 +	/* Wait 100ms for it to complete. */
 +	for (i = 0; i < 100; i++) {
 +		if ((PHY_READ(sc, BRGPHY_MII_BMCR) & BRGPHY_BMCR_RESET) == 0)
 +			break;
 +		DELAY(1000);
 +	}
  
  	/* Handle any PHY specific procedures following the reset. */
  	switch (bsc->mii_oui) {
 
 Modified: stable/7/sys/dev/mii/mii_physubr.c
 ==============================================================================
 --- stable/7/sys/dev/mii/mii_physubr.c	Tue Aug 23 14:32:53 2011	(r225116)
 +++ stable/7/sys/dev/mii/mii_physubr.c	Tue Aug 23 14:32:59 2011	(r225117)
 @@ -276,8 +276,8 @@ mii_phy_reset(struct mii_softc *sc)
  		DELAY(1000);
  	}
  
 -	/* NB: a PHY may default to isolation. */
 -	reg &= ~BMCR_ISO;
 +	/* NB: a PHY may default to being powered down and/or isolated. */
 +	reg &= ~(BMCR_PDOWN | BMCR_ISO);
  	if ((sc->mii_flags & MIIF_NOISOLATE) == 0 &&
  	    ((ife == NULL && sc->mii_inst != 0) ||
  	    (ife != NULL && IFM_INST(ife->ifm_media) != sc->mii_inst)))
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
>Unformatted:
