Date: Sun, 23 Jan 2005 23:37:05 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: bel@orel.ru Cc: freebsd-mobile@freebsd.org Subject: Re: Trouble with APM suspend in 5.3-R Message-ID: <20050123.233705.68307959.imp@bsdimp.com> In-Reply-To: <41F495FE.6000907@orel.ru> References: <41F02CE1.5090207@acm.org> <20050123.195438.61400112.imp@bsdimp.com> <41F495FE.6000907@orel.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <41F495FE.6000907@orel.ru>
Andrew Belashov <bel@orel.ru> writes:
: -----BEGIN PGP SIGNED MESSAGE-----
: Hash: SHA1
:
: Hello, Warner!
:
: M. Warner Losh wrote:
: | In message: <41F02CE1.5090207@acm.org>
: | Dave Walton <dwalton@acm.org> writes:
: | : Andrew Belashov wrote:
: | : > Dave Walton wrote:
: | : >
: | : >> I've been unable to get APM suspend/resume to work with 5.3-R on my
: | : >> Thinkpad 770Z. As released, 'apm -z' causes a lockup (it worked fine
: | : >> in 4.x). Revision 1.233 of ata-all.c fixes that, and 'apm -z' now
: | : >> causes the system to properly suspend to disk, as it had before.
: | : >> However, when the system resumes, it spits out three errors regarding
: | : >> pir0, then panics. This happens with or without your patch applied to
: | : >> ata-all.c.
: | : >>
: | : >
: | : > Try attached patch as workaround.
: | :
: | : A good effort! That is precisely the error I saw. Hopefully, that
: | : removed call to pci_pir_biosroute() doesn't do anything important.
: | :
: | : Unfortunately, this had no effect at all on the panic. Please see my
: | : next reply to Gleb Smirnoff for details on the panic. Perhaps it will
: | : mean something to you.
: |
: | Chances are the right fix is to try the route, but ignore errors...
:
: I agree. But my old notebook recursively goes in cycles by calling
: bios32(PCIBIOS_ROUTE_INTERRUPT) after resume. As result: kernel stack
: overflow, double panic.
:
: BIOS update is not available. No known problems in Windows 2000 Pro.
:
: After removing call to pci_pir_biosroute(), suspend/resume works completely
: on my notebook...
This sounds like you disagree with me. I'm saying that one should
call pci_pir_biosroute() anyway, and then ignore the return code. It
sounds like you are saying that this call is fatal in a resume
context..
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050123.233705.68307959.imp>