Date: Sun, 13 Jan 2013 23:37:10 +0400 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Ian Smith <smithi@nimnet.asn.au> Cc: "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: Atheros 9220 don't return from S3 state Message-ID: <20130113193710.GP67643@zxy.spb.ru> In-Reply-To: <20130114050646.O62930@sola.nimnet.asn.au> References: <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> <20130114050646.O62930@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 14, 2013 at 06:21:54AM +1100, Ian Smith wrote: > 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 This is not new problem, this card in this notebook never resume. With old freebsd resume work badly with other devices. Now resume work nice (exclude this card) > 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. I am attach this dmesg to first message to Adrian (not to list). > 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?20130113193710.GP67643>