Date: Fri, 17 Jul 2009 17:43:10 -0300 From: Gonzalo Nemmi <gnemmi@gmail.com> To: freebsd-current@freebsd.org Cc: Adam K Kirchhoff <adamk@voicenet.com> Subject: Re: bge problems when resuming Message-ID: <200907171743.11143.gnemmi@gmail.com> In-Reply-To: <200907150713.47807.adamk@voicenet.com> References: <4A5D27F2.50208@voicenet.com> <3a142e750907150020h712bfcecq89d5ccf3e00e302c@mail.gmail.com> <200907150713.47807.adamk@voicenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: > On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: > > On 7/15/09, Adam K Kirchhoff <adamk@voicenet.com> wrote: > > > Hello all, > > > > > > I have a Dell Latitude D610 laptop with 8.0-BETA1 installed. I > > > hadn't tried suspend/resume for a while and decided to give it a > > > shot. I was pleasantly surprised to see that I could suspend to > > > ram, resume, and have a (relatively) working system (previously > > > the display would never come back up and the serial console I had > > > hooked up remained dead). Great job to everyone who helped make > > > that possible. > > > > > > The only real issue that I seem to have now is that bge is > > > completely unusable after resume. Another individual seems to > > > have reported similar problems with bge and resume, but he also > > > had other issues that apparently trumped his networking issues: > > > > > > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/0090 > > >23.html > > > > > > Like him, resuming from suspend gives me: > > > > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 0, val 32768) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out (phy 1, > > > reg 0, val 0xffffffff) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 24, val 3072) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 23, val 10) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 21, val 12555) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 23, val 8223) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 21, val 38150) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 23, val 16415) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 21, val 5346) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 24, val 1024) > > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > > > reg 24, val 7) > > > > > > And so on and so forth. > > > > > > I thought that compiling if_bge as a module, unloading it before > > > suspend, and reloading it after resume, might get this working. > > > However, doing a "kldload if_bge" after the resume does nothing. > > > Well, the module gets loaded, but the device doesn't show up. No > > > errors from kldload, and there is nothing new in dmesg. > > > > > > Before the suspend, the device shows up as: > > > > > > bge0@pci0:2:0:0: class=0x020000 card=0x01821028 > > > chip=0x167714e4 rev=0x01 hdr=0x00 > > > vendor = 'Broadcom Corporation' > > > device = 'NetXtreme Gigabit Ethernet PCI Express > > > (BCM5750A1)' class = network > > > subclass = ethernet > > > > > > After resuming, and reloading the module, it's: > > > > > > none1@pci0:2:0:0: class=0x020000 card=0x01821028 > > > chip=0x167714e4 rev=0x01 hdr=0x00 > > > vendor = 'Broadcom Corporation' > > > device = 'NetXtreme Gigabit Ethernet PCI Express > > > (BCM5750A1)' class = network > > > subclass = ethernet > > > > > > If there are no ideas, I'll go ahead and open up a pr. I assume > > > this is just one bug, since both problems (the PHY issues and the > > > inability to reload the driver) are both related to the network > > > device. > > > > Put this lines into loader.conf and reboot. > > > > hw.pci.do_power_nodriver="3" > > hw.pci.do_power_resume="1" > > > > Now, before suspend, unload if_bge and some another driver (sound > > drivers are best candidate) and load sound driver again, suspend > > and resume. > > Now loading if_bge should make it succesfully attach. > > Unfortunately, after doing this, reloading the if_bge driver causes > the laptop to completely lock up... It gets as far as: > > bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, unknown ASIC > rev. 0xffff> > mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 > > And then the entire machine hangs. I'm on ttyv0, so I'd see any > kernel panic, but nothing like that happens. The screen stays on, > but nothing else happens till I force a reboot. > > Adam Hi Adam, Paul ... I'm the "another individual" from you OP. I have the same problems you have regarding bge, but they weren't trumped .. I just had an order of priorities ;) Anyways, I tried the solution Paul posted and, just as in your case, I got a hard lock too ... I tried loading if_bge through /boot/loader.conf Then issued a: kldunload if_bge coretemp acpiconf -s 3 machine suspended As soon as I woke it up I got the following message followed by a hard lock: fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 fwohci0: unrecoverable error bge0: <Broadmcom NetXtreme Ethernet Controller, unknown ASIC rev, 0xffff> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9 All this happens on a Dell 1318, FreeBSD 8.0-BETA1, i386, Intel(R) Celeron(R) CPU 560@2.13GHz. bge0@pci0:9:0:0: class=0x020000 card=0x02861028 chip=0x171314e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom NetLink (TM) Fast Ethernet (BCM5906m)' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xf69f0000, size 65536, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) If somebody needs more info, just ask me for it and I'll try to answer as soon as I can. Adam, if you do file a PR, please let me know so I can follow it. Best Regards -- Blessings Gonzalo Nemmi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907171743.11143.gnemmi>