apm --suspend causes my system to hang under 2.4.2 and
2.4.2ac1. it was working fine under 2.4.1ac19.
looking at syslog it appears that the driver for my
xircom pcmcia card may be involved -- it was the last
entry on two of three occasions. the latest lockup
(under 2.4.1ac1) left no trace in syslog.
upon issuing the command the screen shuts down, but
the rest of the machine (drive, etc.) fails to, and i
cannot get control back.
machine: toshiba tecra 8100
lspci output and two syslog entries are in the
attached file.
1st syslog shows last entry and first of reboot under
2.4.2 and 2nd shows last entry and first of reboot
under 2.4.2ac1.
if anything else is needed, please let me know.
bradley mclain
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
Unfortunately, the APM maintainer, Stephen Rothwell, seems to have
gone into hibernation (pun) and is not responding to emails.
bradley mclain <[email protected]> writes:
> apm --suspend causes my system to hang under 2.4.2 and 2.4.2ac1. it
> was working fine under 2.4.1ac19. looking at syslog it appears that
> the driver for my xircom pcmcia card may be involved -- it was the
> last entry on two of three occasions. the latest lockup (under
> 2.4.1ac1) left no trace in syslog.
Are all kernel messages dumped to syslog? See syslog.conf(5).
> upon issuing the command the screen shuts down, but the rest of the
> machine (drive, etc.) fails to, and i cannot get control back.
If the screen shutdown, all the PM enabled drivers OK'd the suspend
and the APM state was changed.
Perhaps the particular driver you used bungled things somehow. You
could try again with the driver/card unloaded, which would help narrow
the cause of the problem down.
[...]
--
http://www.penguinpowered.com/~vii
i thought that it was my network driver, but i
recompiled 2.4.2 without sound support and apm
--suspend has begun to work again.
the sound card is a yamaha YMF-744B. i hadn't been
compiling with sound support (i dont care about sound
on my laptop), but when i got 2.4.2 i decided to try,
and now i'm pretty sure that was the problem.
is there anything else i should do, or information i
could provide that would confirm this analysis or help
to find a fix?
--- Alan Cox <[email protected]> wrote:
> Can you see if 2.4.1ac20 was ok
>
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
i thought that it was my network driver (xircom), but
i recompiled 2.4.2 without sound support and apm
--suspend has begun to work again.
the sound card is a yamaha YMF-744B. i hadn't been
compiling with sound support (i dont care about sound
on my laptop), but when i got 2.4.2 i decided to try,
and now i'm pretty sure that was the problem.
is there anything else i should do, or information i
could provide that would confirm this analysis or help
to find a fix?
--- Alan Cox <[email protected]> wrote:
> Can you see if 2.4.1ac20 was ok
>
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
> the sound card is a yamaha YMF-744B. i hadn't been
> compiling with sound support (i dont care about sound
> on my laptop), but when i got 2.4.2 i decided to try,
> and now i'm pretty sure that was the problem.
The Yamaha sound driver doesnt handle the case where the bios fails to restore
the chip status and expects a windows driver to do its dirty work. That
requires on resume that the device is completely reloaded.
A workaround is to make it a module, unload it before suspend and reload it
after resume but thats pretty umm uggly.
Alan Cox <[email protected]> writes:
> > the sound card is a yamaha YMF-744B. i hadn't been
> > compiling with sound support (i dont care about sound
> > on my laptop), but when i got 2.4.2 i decided to try,
> > and now i'm pretty sure that was the problem.
>
> The Yamaha sound driver doesnt handle the case where the bios fails
> to restore the chip status and expects a windows driver to do its
> dirty work. That requires on resume that the device is completely
> reloaded.
>
> A workaround is to make it a module, unload it before suspend and
> reload it after resume but thats pretty umm uggly.
Why not use kernel/pm.c:pm_register? Then you can either refuse
suspend or have a proper workaround.
--
http://www.penguinpowered.com/~vii
> Why not use kernel/pm.c:pm_register? Then you can either refuse
> suspend or have a proper workaround.
Feel free to provide code. I suspect you can do something like
refuse to suspend if the device is open at all and reload the firmware, reinit
it on resume if it was idle.
I dont have the hardware
Alan Cox <[email protected]> writes:
> > Why not use kernel/pm.c:pm_register? Then you can either refuse
> > suspend or have a proper workaround.
>
> Feel free to provide code.
You have me there - I should have realised who I was writing to ;-)
[...]
> I dont have the hardware
I neither.
--
http://www.penguinpowered.com/~vii