From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 18:43:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B73D106566B for ; Tue, 21 Jul 2009 18:43:56 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9FC8FC16 for ; Tue, 21 Jul 2009 18:43:55 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so5204145yxe.3 for ; Tue, 21 Jul 2009 11:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZeoF7/OuKel5UA0j/xlKqvJdh9AktTatdwWYMKTuG1M=; b=VWOJW2uSYP3RX2gfh34gKE5V4SSieW7WbyEt2wp4CGVAEjqIwbLy6T1u41O3N1siwz fXpsInWk1wck9JCFkTrPHmPEOphxr6XCF8j6wSrZaNY6vsr1NymRT+1+tiaRulSJf42d CHM8l7QEmXnMcaGyWg11lgQslp7uV4D8rU568= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=erTVRKXFj8P0+78kFS947TnK7mDqIFwwakBcjORlgL+nT2jyf9zXPIk5nLKXKj6CP+ 2E0bpiGW9JTwgvN2sQzNK1rzRLsiYXB64tggOLWWppk48xq8mbaflUferBBDubCNVHTS D8F90iQY2TpYAAo4eT331SmIaeBviTDuFHp6E= MIME-Version: 1.0 Received: by 10.90.86.10 with SMTP id j10mr5041agb.2.1248201834989; Tue, 21 Jul 2009 11:43:54 -0700 (PDT) In-Reply-To: <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> References: <4A5D27F2.50208@voicenet.com> <19e9a5dc0907191530s679c0b37v49a836cc00bbf58a@mail.gmail.com> <3a142e750907191553u1fd266a4q286e7168b74ee889@mail.gmail.com> <200907201803.32053.gnemmi@gmail.com> <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> Date: Tue, 21 Jul 2009 15:43:54 -0300 Message-ID: <19e9a5dc0907211143p19e7ea25s79c788fd4c95896a@mail.gmail.com> From: Gonzalo Nemmi To: "Paul B. Mahol" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 18:43:57 -0000 On Tue, Jul 21, 2009 at 5:46 AM, Paul B. Mahol wrote: > On 7/20/09, Gonzalo Nemmi wrote: > > On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote: > >> On 7/20/09, Gonzalo Nemmi wrote: > >> > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol > > wrote: > >> >> On 7/17/09, Gonzalo Nemmi 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 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=3D0x020000 card=3D0x01821028 > >> >> >> > > chip=3D0x167714e4 rev=3D0x01 hdr=3D0x00 > >> >> >> > > vendor =3D 'Broadcom Corporation' > >> >> >> > > device =3D 'NetXtreme Gigabit Ethernet PCI Express > >> >> >> > > (BCM5750A1)' class =3D network > >> >> >> > > subclass =3D ethernet > >> >> >> > > > >> >> >> > > After resuming, and reloading the module, it's: > >> >> >> > > > >> >> >> > > none1@pci0:2:0:0: class=3D0x020000 card=3D0x01821028 > >> >> >> > > chip=3D0x167714e4 rev=3D0x01 hdr=3D0x00 > >> >> >> > > vendor =3D 'Broadcom Corporation' > >> >> >> > > device =3D 'NetXtreme Gigabit Ethernet PCI Express > >> >> >> > > (BCM5750A1)' class =3D network > >> >> >> > > subclass =3D 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=3D"3" > >> >> >> > hw.pci.do_power_resume=3D"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: >> >> >> 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 an= d > > here are the results: > Sorry, I meant BETA1 yielded a Fatal trap12, not BETA2 > > > > 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 =3D 0x280d516b, esp =3D 0xbfbfe47c, ebp =3D 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. > Could be .. will have to recompile the kernel and use if_bge as a module to see what happens ... I just read a mail from =D8yvind Rakv=E5g saying he is experiencing a freez= e when setting bge0 to UP: http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009677.html Maybe bge needs some care :s > > Jul 20 17:51:06 gargoyle kernel: pcm0: detached > > Jul 20 17:51:06 gargoyle kernel: hdac0: detached > > > > > > kld snd_hda > ^^^ > You mean kldload. > Yes, sorry Paul, I guess I typed too fast :s > > > > > Jul 20 17:52:16 gargoyle kernel: hdac0: > 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 STAC9228= X > > Jul 20 17:52:16 gargoyle kernel: bge0: > 0xc002> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9 > > Jul 20 17:52:16 gargoyle kernel: miibus0: on bge0 > > Jul 20 17:52:16 gargoyle kernel: brgphy0: PH= Y > > 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: > 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? > Really don=B4t know ... That=B4s what happened after issuing a kldload snd_hda. > > > > > 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=3D0x00000000, SelfID Count=3D1, CYCLEMASTER mode > > Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <=3D 0 cabl= e > > 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) Will do. I=B4be been trying to avoid that in order to test with a custom kernel. Will recompile GENERIC commenting out if_bge only, load it via loader.conf and test it to see what happens. > From your mail I dont see where is problem with firewire. > OK ... I filed a PR on fwohhci (unrecoverable error) though, if I shouldn= =B4t have done that, sorry for the noise then, I don=B4t have firewire devices t= o test it: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D136946 Best Regards Gonzalo