Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jul 2009 10:46:10 +0200
From:      "Paul B. Mahol" <onemda@gmail.com>
To:        Gonzalo Nemmi <gnemmi@gmail.com>
Cc:        freebsd-current@freebsd.org, Adam K Kirchhoff <adamk@voicenet.com>
Subject:   Re: bge problems when resuming
Message-ID:  <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com>
In-Reply-To: <200907201803.32053.gnemmi@gmail.com>
References:  <4A5D27F2.50208@voicenet.com> <19e9a5dc0907191530s679c0b37v49a836cc00bbf58a@mail.gmail.com> <3a142e750907191553u1fd266a4q286e7168b74ee889@mail.gmail.com> <200907201803.32053.gnemmi@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 7/20/09, Gonzalo Nemmi <gnemmi@gmail.com> wrote:
> On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote:
>> On 7/20/09, Gonzalo Nemmi <gnemmi@gmail.com> wrote:
>> > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol <onemda@gmail.com>
> wrote:
>> >> On 7/17/09, Gonzalo Nemmi <gnemmi@gmail.com> wrote:
>> >> > 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-Jul
>> >> >> > >y/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
>> >>
>> >> coretemp is wrong module, it must be one of modules that attach to
>> >> pci.
>> >
>> > Sorry Paul!
>> > I gave it a go with snd_hda and I got the same result except that
>> > this time I also got the following message:
>>
>> After unloading snd_hda you loaded it again before suspending?
>
> Doing so yielded a Fatal trap 12 on BETA2. Yesterday I install BETA2 and
> here are the results:
>
>
> kldstat
>
> Id Refs Address    Size     Name
>  1   28 0xc0400000 cf6c70   kernel
>  2    1 0xc10f7000 11bc0    if_bge.ko
>  3    1 0xc1109000 1ac4c    snd_hda.ko
>  4    2 0xc1124000 61f78    sound.ko
>  5    1 0xc1186000 2af4     coretemp.ko
>  6    1 0xc1189000 a6d8     i915.ko
>  7    2 0xc1194000 177d4    drm.ko
>
>
> kldunload if_bge snd_hda
>
> Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0
> Jul 20 17:51:06 gargoyle kernel: brgphy0: detached
> Jul 20 17:51:06 gargoyle kernel: lock order reversal:
> Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker (kernel
> linker) @ /usr/src/sys/kern/kern_linker.c:1079
> Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock (sysctl
> lock) @ /usr/src/sys/kern/kern_sysctl.c:257
> Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace:
> Jul 20 17:51:06 gargoyle kernel:
> db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e989,...)
> at db_trace_self_wrapper+0x26
> Jul 20 17:51:06 gargoyle kernel:
> kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) at
> kdb_backtrace+0x29
> Jul 20 17:51:06 gargoyle kernel:
> _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,...) at
> _witness_debugger+0x25
> Jul 20 17:51:06 gargoyle kernel:
> witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at
> witness_checkorder+0x839
> Jul 20 17:51:06 gargoyle kernel:
> _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at _sx_xlock+0x85
> Jul 20 17:51:06 gargoyle kernel:
> sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,...) at
> sysctl_ctx_free+0x30
> Jul 20 17:51:06 gargoyle kernel:
> device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at
> device_sysctl_fini+0x1a
> Jul 20 17:51:06 gargoyle kernel:
> device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) at
> device_detach+0x1f5
> Jul 20 17:51:06 gargoyle kernel:
> bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80,...) at
> bus_generic_detach+0x29
> Jul 20 17:51:06 gargoyle kernel:
> miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at
> miibus_detach+0x12
> Jul 20 17:51:06 gargoyle kernel:
> device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) at
> device_detach+0x8c
> Jul 20 17:51:06 gargoyle kernel:
> bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at
> bus_generic_detach+0x29
> Jul 20 17:51:06 gargoyle kernel:
> bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at
> bge_detach+0xbf
> Jul 20 17:51:06 gargoyle kernel:
> device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) at
> device_detach+0x8c
> Jul 20 17:51:06 gargoyle kernel:
> driver_module_handler(c4526300,1,c1106c20,109,0,...) at
> driver_module_handler+0x29c
> Jul 20 17:51:06 gargoyle kernel:
> module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at
> module_unload+0x43
> Jul 20 17:51:06 gargoyle kernel:
> linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at
> linker_file_unload+0x15e
> Jul 20 17:51:06 gargoyle kernel:
> kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at
> kern_kldunload+0xd5
> Jul 20 17:51:06 gargoyle kernel:
> kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at
> kldunloadf+0x2b
> Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at syscall+0x2a3
> Jul 20 17:51:06 gargoyle kernel: Xint0x80_syscall() at
> Xint0x80_syscall+0x20
> Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD ELF32,
> kldunloadf), eip = 0x280d516b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 ---
> Jul 20 17:51:06 gargoyle kernel: miibus0: detached
> Jul 20 17:51:06 gargoyle kernel: bge0: detached
> Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed to
> unregister sysctl

if_bge driver looks very problematic to me. Probably it can not detach at all.

> Jul 20 17:51:06 gargoyle kernel: pcm0: detached
> Jul 20 17:51:06 gargoyle kernel: hdac0: detached
>
>
> kld snd_hda
  ^^^
You mean kldload.

>
> Jul 20 17:52:16 gargoyle kernel: hdac0: <Intel 82801H High Definition
> Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at device 27.0 on
> pci0
> Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision:
> 20090624_0136
> Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD]
> Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel STAC9228X
> Jul 20 17:52:16 gargoyle kernel: bge0: <Broadcom BCM5906 A2, ASIC rev.
> 0xc002> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9
> Jul 20 17:52:16 gargoyle kernel: miibus0: <MII bus> on bge0
> Jul 20 17:52:16 gargoyle kernel: brgphy0: <BCM5906 10/100baseTX PHY> PHY
> 1 on miibus0
> Jul 20 17:52:16 gargoyle kernel: brgphy0:  10baseT, 10baseT-FDX,
> 100baseTX, 100baseTX-FDX, auto
> Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address:
> 00:23:ae:04:ba:ca
> Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD]
> Jul 20 17:52:16 gargoyle kernel: pcm0: <HDA Sigmatel STAC9228X PCM #0
> Analog> at cad 0 nid 1 on hdac0
> Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to DOWN
> Jul 20 17:52:18 gargoyle kernel: bge0: link state changed to UP

Why bge0 appeared again?

>
> acpiconf -s 3

After this command bge0 should not appear at all because it should not
be attached to
device.

>
> Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51
> Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend
> Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg
> 0, val 32768)
> Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0,
> val 0xffffffff)
> Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg
> 24, val 0xffffffff)
> Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg
> 16, val 0xffffffff)
> Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg
> 16, val 0)
> Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg
> 16, val 0xffffffff)
> Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg
> 16, val 0)
> Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg
> 23, val 18)
> Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init failed
> Jul 20 17:54:25 gargoyle kernel: bge0: initialization failure
> Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a available S400, 1
> ports.
> Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes.
> Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate bus reset
> Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset
> Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core:
> node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode
> Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable
> IRM irm(0)  (me)
> Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0
> Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error
> Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state (slept
> 00:00:29)
> Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25
>
> Should a PR on fwohci and firewire also be filed??

Try with custom kernel with smaller number of drivers as possible.
(use modules instead)
>From your mail I dont see where is problem with firewire.

> Best Regards
> Gonzalo Nemmi
>
>> > fwohci0: ...
>> > firewire0: ...
>> > fwohci0: ...
>> > pci0: < multimedia HDA > at device 27.0 ( no driver attached )
>> > bge0 ...
>> >
>> > Then, the same hard lock :(
>> >
>> > Will install BETA2 today !
>> >
>> > Best Regards
>> > Gonzalo
>> >
>> >> > 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
>> >>


-- 
Paul



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a142e750907210146u2ce72cadhbdaa71a89be54607>