Date: Mon, 14 Jan 2013 06:21:54 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org>, Slawa Olhovchenkov <slw@zxy.spb.ru> Subject: Re: Atheros 9220 don't return from S3 state Message-ID: <20130114050646.O62930@sola.nimnet.asn.au> In-Reply-To: <CAJ-Vmo=oKw7HNJvvLu%2BxN1WSk_i-C-PZMS3zCS8jfvU0BDO0jA@mail.gmail.com> References: <20130112105245.GF67643@zxy.spb.ru> <CAJ-Vmom18Pr2kq0qAymjintpg1Crgrna8%2By=7fBk8Vy7nqP5_A@mail.gmail.com> <20130112154404.GH67643@zxy.spb.ru> <CAJ-Vmomy4jVNs9r0H2XzVO-Q6tq7=O4EzJn-NLCOO=n%2BSJce_g@mail.gmail.com> <20130112162851.GI67643@zxy.spb.ru> <CAJ-VmomUdkCtsGfzvd=hoeoNYPVip11nxNFb5z48a0EFWkbCTQ@mail.gmail.com> <20130112163712.GJ67643@zxy.spb.ru> <CAJ-VmonnDy81joHZ_Z_meMZxdUmSKsQWQ8Mud-42Knremq=Z3A@mail.gmail.com> <20130112165235.GK67643@zxy.spb.ru> <CAJ-VmomM5z1vjw%2B3--OYkfb=J5qm1k1egM19Njx660SHdAdJkw@mail.gmail.com> <20130112170707.GL67643@zxy.spb.ru> <CAJ-Vmo=oKw7HNJvvLu%2BxN1WSk_i-C-PZMS3zCS8jfvU0BDO0jA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Jan 2013 09:05:37 -0800, Adrian Chadd wrote: > We can't patch pci space if they're all 0xffffffff, that means nothing is there. > > That's the point; the card hasn't come back on from suspend. So we > need to do something _before_ it suspends. We can't do anything to the > card after it resumes; we can only do stuff to the PCI bus. > > > > Adrian > > On 12 January 2013 09:07, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: > > On Sat, Jan 12, 2013 at 08:50:58AM -0800, Adrian Chadd wrote: > > > >> I don't know the first thing about ACPI, I'm sorry. And here was me thinking you were across The Whole Thing :) > > OK, what about "patching" pci config space? Remove indication of > > support D3 state? or system don't suspend after this complete? > > (sorry for dumb question). Not dumb .. I don't know but suspect suspend would proceed regardless with perhaps some noise. Maybe worth doing that acpidump per recipe? > > > >> Perhaps ask on the freebsd acpi list? Good idea, or perhaps current@ ? Somewhere both bus and ACPI people congregate anyway. One could point to this thread or compact its contents into a new message, but there may be something Slawa could do before the whole acpi debug palava, which is just to: a) boot verbose, maybe with kern.msgbufsize=98304 (say) in loader.conf b) suspend then resume c) dmesg # head to post somewhere, tail for the susp/res bit. Even without any ACPI debugging enabled, there should be clues as to acpi powering down then later (trying to) resume all devices, which might indicate whether that tunnel is worth diving deeper into .. Since I'm so pleased that suspend/resume finally works without drama out of the box on my T23 at 9.1-R, I include below one such cycle from /var/log/messages. There are logged ACPI errors I don't understand about \_SB_.PCI0.PCI1.CBS[01] that don't seem to affect functionality, but you can see the ACPI and PCI view of things, and it's old and small enough a box (single CPU, with no wireless :) If it helps, Ian > >> > >> > >> Adrian > >> > >> On 12 January 2013 08:52, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: > >> > On Sat, Jan 12, 2013 at 08:38:49AM -0800, Adrian Chadd wrote: > >> > > >> >> On 12 January 2013 08:37, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: > >> >> > On Sat, Jan 12, 2013 at 08:25:22AM -0800, Adrian Chadd wrote: > >> >> > > >> >> >> .. right, try flipping the rf kill switch off/on after suspend, dump > >> >> >> the config registers. > >> >> > > >> >> > don't react -- 255 times 'ff' > >> >> > >> >> Okay. Well, I'll see if there's anything that I can do with the PCI > >> >> glue inside the AR9220, but if it's broken under Windows... > >> > > >> > Perhaps if ACPI not found vendor wifi card (intel) not powered slot on > >> > resume? I am don't know how chek this is acpidump... ======= Jan 3 04:42:05 t234ma-s2 acpi: suspend at 20130103 04:42:05 Jan 3 04:42:05 t234ma-s2 kernel: acpi_button0: sleep button pressed Jan 3 04:42:10 t234ma-s2 kernel: (ada0:ata0:0:0:0): spin-down Jan 5 00:57:52 t234ma-s2 kernel: acpi_lid0: wake_prep enabled for \_SB_.LID_ (S3) Jan 5 00:57:52 t234ma-s2 kernel: acpi_button0: wake_prep enabled for \_SB_.SLPB (S3) Jan 5 00:57:52 t234ma-s2 kernel: vga0: saving 3780 bytes of video state Jan 5 00:57:52 t234ma-s2 kernel: vga0: saving color palette Jan 5 00:57:52 t234ma-s2 kernel: pci0:1:0:0: Transition from D0 to D3 Jan 5 00:57:52 t234ma-s2 kernel: pci1: set ACPI power state D3 on \_SB_.PCI0.AGP_.VID_ Jan 5 00:57:52 t234ma-s2 kernel: uhub2: at usbus0, port 1, addr 1 (disconnected) Jan 5 00:57:52 t234ma-s2 kernel: uhub0: at usbus1, port 1, addr 1 (disconnected) Jan 5 00:57:52 t234ma-s2 kernel: uhub1: at usbus2, port 1, addr 1 (disconnected) Jan 5 00:57:52 t234ma-s2 kernel: fxp0: link state changed to DOWN Jan 5 00:57:52 t234ma-s2 kernel: pci0:2:0:0: Transition from D0 to D2 Jan 5 00:57:52 t234ma-s2 kernel: pci2: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CBS0: AE_BAD_PARAMETER Jan 5 00:57:52 t234ma-s2 kernel: pci0:2:0:1: Transition from D0 to D2 Jan 5 00:57:52 t234ma-s2 kernel: pci2: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CBS1: AE_BAD_PARAMETER Jan 5 00:57:52 t234ma-s2 kernel: pci0:2:8:0: Transition from D0 to D2 (resume, above kept for logging after resume despite timestamp) Jan 5 00:57:52 t234ma-s2 kernel: acpi_lid0: run_prep cleaned up for \_SB_.LID_ Jan 5 00:57:52 t234ma-s2 kernel: acpi_button0: run_prep cleaned up for \_SB_.SLPB Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.AGP_ Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB0 Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB1 Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB2 Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.PCI1 Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.LPC_ Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.IDE0 Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.AGP_ Jan 5 00:57:52 t234ma-s2 kernel: pci1: set ACPI power state D0 on \_SB_.PCI0.AGP_.VID_ Jan 5 00:57:52 t234ma-s2 kernel: pci0:1:0:0: Transition from D3 to D0 Jan 5 00:57:52 t234ma-s2 kernel: vgapci0: calling BIOS POST Jan 5 00:57:52 t234ma-s2 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.PCI1 Jan 5 00:57:52 t234ma-s2 kernel: pci2: set ACPI power state D0 on \_SB_.PCI0.PCI1.CBS0 Jan 5 00:57:52 t234ma-s2 kernel: pci0:2:0:0: Transition from D2 to D0 Jan 5 00:57:52 t234ma-s2 kernel: pci2: set ACPI power state D0 on \_SB_.PCI0.PCI1.CBS1 Jan 5 00:57:52 t234ma-s2 kernel: pci0:2:0:1: Transition from D2 to D0 Jan 5 00:57:52 t234ma-s2 kernel: wakeup from sleeping state (slept 44:15:36) Jan 5 00:57:52 t234ma-s2 kernel: ata0: reset tp1 mask=03 ostat0=80 ostat1=00 Jan 5 00:57:52 t234ma-s2 kernel: ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 Jan 5 00:57:52 t234ma-s2 last message repeated 9 times (while spinning up) Jan 5 00:57:52 t234ma-s2 kernel: ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 Jan 5 00:57:52 t234ma-s2 kernel: ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 Jan 5 00:57:52 t234ma-s2 kernel: ata0: reset tp2 stat0=50 stat1=00 devices=0x1 Jan 5 00:57:52 t234ma-s2 kernel: ata1: reset tp1 mask=03 ostat0=00 ostat1=00 Jan 5 00:57:52 t234ma-s2 kernel: ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb Jan 5 00:57:52 t234ma-s2 kernel: ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 Jan 5 00:57:52 t234ma-s2 kernel: ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 Jan 5 00:57:52 t234ma-s2 kernel: atkbd: the current kbd controller command byte 0047 Jan 5 00:57:52 t234ma-s2 kernel: atkbd: keyboard ID 0x54ab (2) Jan 5 00:57:52 t234ma-s2 kernel: kbdc: RESET_KBD return code:00fa Jan 5 00:57:52 t234ma-s2 kernel: kbdc: RESET_KBD status:00aa Jan 5 00:57:52 t234ma-s2 kernel: kbdc: TEST_AUX_PORT status:0000 Jan 5 00:57:52 t234ma-s2 kernel: kbdc: RESET_AUX return code:00fa Jan 5 00:57:52 t234ma-s2 kernel: kbdc: RESET_AUX status:00aa Jan 5 00:57:52 t234ma-s2 kernel: kbdc: RESET_AUX ID:0000 Jan 5 00:57:52 t234ma-s2 kernel: fxp0: link state changed to UP Jan 5 00:57:52 t234ma-s2 kernel: battery0: battery initialization start Jan 5 00:57:52 t234ma-s2 kernel: uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 Jan 5 00:57:52 t234ma-s2 kernel: uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2 Jan 5 00:57:52 t234ma-s2 kernel: uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 Jan 5 00:57:52 t234ma-s2 kernel: battery0: battery initialization done, tried 1 times Jan 5 00:57:52 t234ma-s2 kernel: uhub0: 2 ports with 2 removable, self powered Jan 5 00:57:52 t234ma-s2 kernel: uhub1: 2 ports with 2 removable, self powered Jan 5 00:57:52 t234ma-s2 kernel: uhub2: 2 ports with 2 removable, self powered Jan 5 00:57:52 t234ma-s2 kernel: (ada0:ata0:0:0:0): resume Jan 5 00:57:52 t234ma-s2 kernel: fxp0: link state changed to DOWN Jan 5 00:57:52 t234ma-s2 acpi: resumed at 20130105 00:57:52 Jan 5 00:57:54 t234ma-s2 kernel: fxp0: link state changed to UP Jan 5 00:57:57 t234ma-s2 dhclient: New IP Address (fxp0): 10.1.1.3 Jan 5 00:57:57 t234ma-s2 kernel: fxp0: link state changed to DOWN Jan 5 00:57:57 t234ma-s2 dhclient: New Subnet Mask (fxp0): 255.0.0.0 Jan 5 00:57:57 t234ma-s2 dhclient: New Broadcast Address (fxp0): 10.255.255.255 Jan 5 00:57:57 t234ma-s2 dhclient: New Routers (fxp0): 10.1.1.1 Jan 5 00:57:59 t234ma-s2 kernel: fxp0: link state changed to UP =======
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130114050646.O62930>