Hello,
I read a thread on the mailing list archive about the exact same
problem I am facing now (thread started on Tue Sep 25 2001:
"apm suspend broken in 2.4.10).
I use a Dell latitude C600 and it used to work fine with kernel up
to 2.4.9 (regular kernel from kernel.org).
I upgraded to redhat 7.2 and to kernel 2.4.13+ext3 patches (again
from regular sources), and apm refuses to suspend the beast.
Did someone find a solution for this problem since last thread ?
If no light shined from last thread, I would be happy to help out
on this. I am not a kernel hacker so I guess my help will be limited,
but I do have the hardware ready for testing purposes
Pascal
(please cc me in replies since I am not subscribed to the list)
Pascal Lengard <[email protected]> wrote:
> I use a Dell latitude C600 and it used to work fine with kernel up
> to 2.4.9 (regular kernel from kernel.org).
> I upgraded to redhat 7.2 and to kernel 2.4.13+ext3 patches (again
> from regular sources), and apm refuses to suspend the beast.
I, byt the way, had my Latitude suspend perfectly with 2.4.12-ac5.
Now, with 2.4.13-ac[34] pressing Fn+Suspend just blanks the screen (it
doesn't shut it off, _just_ blanks it) and hangs the machine.
Any ideas on how to proceed in order to find out where the problem
lies?
Suonp??...
> I, byt the way, had my Latitude suspend perfectly with 2.4.12-ac5.
> Now, with 2.4.13-ac[34] pressing Fn+Suspend just blanks the screen (it
> doesn't shut it off, _just_ blanks it) and hangs the machine.
>
> Any ideas on how to proceed in order to find out where the problem
> lies?
Find exactly which -ac it broke in. If you do a binary search through a few
patch levels you should be able to pin it down. At that point I can chase it
Alan
> I, by the way, had my Latitude suspend perfectly with 2.4.12-ac5.
> Now, with 2.4.13-ac[34] pressing Fn+Suspend just blanks the screen (it
> doesn't shut it off, _just_ blanks it) and hangs the machine.
>
> Any ideas on how to proceed in order to find out where the problem
> lies?
The apm driver was changed so that clients who open
the apm device without the write flag won't be expected
to return standby or suspend events; and clients who
open the apm device without the read flag won't be
notified of apm events.
For consistency, clients without the write flag should
not be able to request standbys or suspends. Thus
this patch seems required:
--- linux-2.4.13-ac2/arch/i386/kernel/apm.c Mon Oct 22 09:22:38 2001
+++ linux-2.4.13-ac2-fix/arch/i386/kernel/apm.c Tue Oct 30 10:29:41 2001
@@ -1473,6 +1473,8 @@
return -EIO;
if (!as->suser)
return -EPERM;
+ if (!as->writer)
+ return -EPERM;
switch (cmd) {
case APM_IOC_STANDBY:
if (as->standbys_read > 0) {
Applying this patch may solve your problem.
Scenario: You have a client that is opening the apm
device O_RDONLY, yet has been acking standby events
back to the apm driver. Formerly the driver would
ignore the lack of write permission, but now, since
the client does not have write permission, the driver
does not count the standby event that it sends to the
client as "pending". So when the client acks the
event, it looks to the driver like a new request.
Without the above patch, the driver will process this
request, dutifully queueing it to the other clients.
If there is more than one client of this kind, then
an infinite series of standby requests will result.
The patch should prevent that from happening.
However, if there are apm clients that expect the
driver to inform them of standby and suspend events
and to wait for an ack before going ahead with the
standby or suspend, then such clients should be
modified to open the apm device O_RDWR. So long
as such a client opens the apm device O_RDONLY,
the driver will not wait for it to reply and
(patched with the above) will reject its reply
when it comes.
The changelog at the top of apm.c cites me as the
originator of the idea behind the change. The
motivation was to eliminate queue overflows for
clients that aren't interested in the events and
don't read them. The idea of not waiting for
feedback from clients without write perm seems
like a good one too, since some clients might
just want to hear about events, not generate or
ack them. However this does constitute an API
change, so either (1) we should disable the
change until 2.5, or (2) we should check that
clients such as apmd are opening the apm device
with O_RDWR.
--
Thomas Hood
Hmm. I just noticed that your problem was with
suspend, not standby. The same scenario could occur
with suspend, of course. However, the scenario does
not match the problem you describe. I don't see how
a change to the apm driver could cause a suspend to
turn into something that looks like a standby-plus-crash.
Are you sure that the machine is hanged: SysRq-s,
SysRq-u, SysRq-b doesn't work?
--
Thomas
I have a question related to this.
If a driver ioctl handler requires
(filp->f_mode) & FMODE_WRITE
to be set before processing a request, and if only
root has write permission to the device file, does this
make it unnecessary to check for
capable(CAP_SYS_ADMIN)
?
If we were to use the write permission bit to control
access, then it would not be necessary for the apm
command to be setuid root to give the non-root user
the ability to suspend the machine. Instead we could
chgrp apm /dev/apm_bios
chmod g+w /dev/apm_bios
and add the trusted user to the 'apm' group.
Am I missing something here?
--
Thomas
On Tue, 30 Oct 2001, Alan Cox wrote:
> > I, byt the way, had my Latitude suspend perfectly with 2.4.12-ac5.
> > Now, with 2.4.13-ac[34] pressing Fn+Suspend just blanks the screen (it
> > doesn't shut it off, _just_ blanks it) and hangs the machine.
> >
> > Any ideas on how to proceed in order to find out where the problem
> > lies?
>
> Find exactly which -ac it broke in. If you do a binary search through a few
> patch levels you should be able to pin it down. At that point I can chase it
I tested "plain" 2.4.12 from Linus and it suffer the same problem.
Pressing Fn+Suspend does nothing on my Dell Latitude C600, so I thought
it would not be usefull to test against 2.4.12-ac. Tell me if I am plain
wrong on this, otherwise, I guess my problem is not exactly the same than
Samuli Suonpaa's.
>From the last thread on this subject, I could narrow down the problem
between 2.4.9 (working) and 2.4.10 (broken), so I did not test against -ac.
I rather tested against 2.4.10-preXX. I hope this is not a problem.
Sumary:
-------
Hardware: Dell Latitude C600
When apm is broken, pressing Fn+Suspend does nothing and launching "apm -s"
returns "apm: Resource temporarily unavailable".
2.4.9 ==> apm works
2.4.10-pre8 ==> apm works
2.4.10-pre10 ==> apm works
2.4.10-pre11 ==> apm works
2.4.10-pre12 ==> apm broken
2.4.10 ==> apm broken
2.4.12 ==> apm broken
2.4.13 ==> apm broken
The problem appeared in 2.4.10-pre12. I read the Changelog but it is not
precise enough for me :-), I started to diff between pre11 and pre12 but
I need a sleep now ... I already compiled to much kernels for tonight !
I am ready to test other things if I can help on this issue.
Where could I get patches between pre11 and pre12 in small chunks to start
some experimentation ?
Pascal
Following up on my earlier message.
On my machine, lsof reveals that apmd and X both open
/dev/apm_bios with O_RDWR flags; also, reading the source
of libapm reveals that it too opens with O_RDWR;
so none of these should see any change in the behavior
of the apm driver.
Nevertheless, the two-line patch given below needs to be
applied in order to prevent the problem I described before.
I'm running a kernel with the patch applied now and it
works fine.
--
Thomas
--- original message ---
The apm driver was changed so that clients who open
the apm device without the write flag won't be expected
to return standby or suspend events; and clients who
open the apm device without the read flag won't be
notified of apm events.
For consistency, clients without the write flag should
not be able to request standbys or suspends. Thus
this patch seems required:
--- linux-2.4.13-ac2/arch/i386/kernel/apm.c Mon Oct 22 09:22:38 2001
+++ linux-2.4.13-ac2-fix/arch/i386/kernel/apm.c Tue Oct 30 10:29:41 2001
@@ -1473,6 +1473,8 @@
return -EIO;
if (!as->suser)
return -EPERM;
+ if (!as->writer)
+ return -EPERM;
switch (cmd) {
case APM_IOC_STANDBY:
if (as->standbys_read > 0) {
Applying this patch may solve your problem.
Scenario: You have a client that is opening the apm
device O_RDONLY, yet has been acking standby events
back to the apm driver. Formerly the driver would
ignore the lack of write permission, but now, since
the client does not have write permission, the driver
does not count the standby event that it sends to the
client as "pending". So when the client acks the
event, it looks to the driver like a new request.
Without the above patch, the driver will process this
request, dutifully queueing it to the other clients.
If there is more than one client of this kind, then
an infinite series of standby requests will result.
The patch should prevent that from happening.
However, if there are apm clients that expect the
driver to inform them of standby and suspend events
and to wait for an ack before going ahead with the
standby or suspend, then such clients should be
modified to open the apm device O_RDWR. So long
as such a client opens the apm device O_RDONLY,
the driver will not wait for it to reply and
(patched with the above) will reject its reply
when it comes.
The changelog at the top of apm.c cites me as the
originator of the idea behind the change. The
motivation was to eliminate queue overflows for
clients that aren't interested in the events and
don't read them. The idea of not waiting for
feedback from clients without write perm seems
like a good one too, since some clients might
just want to hear about events, not generate or
ack them. However this does constitute an API
change, so either (1) we should disable the
change until 2.5, or (2) we should check that
clients such as apmd are opening the apm device
with O_RDWR.
--
Thomas Hood
> 2.4.9 ==> apm works
> 2.4.10-pre8 ==> apm works
> 2.4.10-pre10 ==> apm works
> 2.4.10-pre11 ==> apm works
> 2.4.10-pre12 ==> apm broken
Thanks
I'll have a look when I get some time to poke at APM again
Pascal Lengard <[email protected]> writes:
> I tested "plain" 2.4.12 from Linus and it suffer the same problem.
> Pressing Fn+Suspend does nothing on my Dell Latitude C600, so I thought
> it would not be usefull to test against 2.4.12-ac. Tell me if I am plain
> wrong on this, otherwise, I guess my problem is not exactly the same than
> Samuli Suonpaa's.
just for other data points, 2.4.7 (RedHat), 2.4.9 (RedHat), and
2.4.12-ac6 respond OK to Fn-Suspend on my C600.
occasionally i get a suspend that won't resume correctly; the
framebuffer gets hosed such that it looks like the screen is cut into
vertical strips and rearranged. but Fn-Suspend works, and i can
resume, and the machine is still running fine (i.e., i can reboot it
if i can maneuver the mouse to a window ;-).
what i've never gotten to work on the C600 is suspend on closing the
lid. Worked great on my old Latitude CS... gotta love Dell, the cases
look the same but everything inside is a crapshoot.
ian
Hi Thomas,
On 30 Oct 2001 11:18:17 -0500 Thomas Hood <[email protected]> wrote:
>
> If we were to use the write permission bit to control
> access, then it would not be necessary for the apm
> command to be setuid root to give the non-root user
> the ability to suspend the machine. Instead we could
> chgrp apm /dev/apm_bios
> chmod g+w /dev/apm_bios
> and add the trusted user to the 'apm' group.
>
> Am I missing something here?
No, you are not missing anything and I did consider the other part of your
patch, but was not brave enough to apply it when the kernel was "frozen".
However, the freeze lasted much longer than I expected :-)
I guess the original intention was that we would be able to add
capablilites to executable (much as we add setuid bits) and to users, but
that also seems to have taken a while to emerge. I think, though, that I
have seen a PAM module for adding capabilities to users at login time.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Pascal,
On Wed, 31 Oct 2001 02:27:31 +0100 (CET) Pascal Lengard <[email protected]> wrote:
>
> 2.4.10-pre11 ==> apm works
> 2.4.10-pre12 ==> apm broken
Can you try the following patch, please? This is the relevant part of a
patch that was applied to Alan Cox's kernels.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
--- 2.4.14-pre5/drivers/char/pc_keyb.c Mon Sep 24 05:12:49 2001
+++ 2.4.13-ac5/drivers/char/pc_keyb.c Tue Oct 30 17:42:28 2001
@@ -34,6 +34,7 @@
#include <linux/vt_kern.h>
#include <linux/smp_lock.h>
#include <linux/kd.h>
+#include <linux/pm.h>
#include <asm/keyboard.h>
#include <asm/bitops.h>
@@ -397,29 +398,32 @@
return 0200;
}
-void pckbd_pm_resume(void)
+int pckbd_pm_resume(struct pm_dev *dev, pm_request_t rqst, void *data)
{
#if defined CONFIG_PSMOUSE
unsigned long flags;
- if (queue) { /* Aux port detected */
- if (aux_count == 0) { /* Mouse not in use */
- spin_lock_irqsave(&kbd_controller_lock, flags);
- /*
- * Dell Lat. C600 A06 enables mouse after resume.
- * When user touches the pad, it posts IRQ 12
- * (which we do not process), thus holding keyboard.
- */
- kbd_write_command(KBD_CCMD_MOUSE_DISABLE);
- /* kbd_write_cmd(AUX_INTS_OFF); */ /* Config & lock */
- kb_wait();
- kbd_write_command(KBD_CCMD_WRITE_MODE);
- kb_wait();
- kbd_write_output(AUX_INTS_OFF);
- spin_unlock_irqrestore(&kbd_controller_lock, flags);
- }
+ if (rqst == PM_RESUME) {
+ if (queue) { /* Aux port detected */
+ if (aux_count == 0) { /* Mouse not in use */
+ spin_lock_irqsave(&kbd_controller_lock, flags);
+ /*
+ * Dell Lat. C600 A06 enables mouse after resume.
+ * When user touches the pad, it posts IRQ 12
+ * (which we do not process), thus holding keyboard.
+ */
+ kbd_write_command(KBD_CCMD_MOUSE_DISABLE);
+ /* kbd_write_cmd(AUX_INTS_OFF); */ /* Config & lock */
+ kb_wait();
+ kbd_write_command(KBD_CCMD_WRITE_MODE);
+ kb_wait();
+ kbd_write_output(AUX_INTS_OFF);
+ spin_unlock_irqrestore(&kbd_controller_lock, flags);
+ }
+ }
}
-#endif
+#endif
+ return 0;
}
--- 2.4.14-pre5/include/asm-i386/keyboard.h Wed Oct 24 22:05:26 2001
+++ 2.4.13-ac5/include/asm-i386/keyboard.h Tue Oct 30 17:42:41 2001
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/ioport.h>
#include <linux/kd.h>
+#include <linux/pm.h>
#include <asm/io.h>
#define KEYBOARD_IRQ 1
@@ -28,7 +29,8 @@
extern char pckbd_unexpected_up(unsigned char keycode);
extern void pckbd_leds(unsigned char leds);
extern void pckbd_init_hw(void);
-extern void pckbd_pm_resume(void);
+extern int pckbd_pm_resume(struct pm_dev *, pm_request_t, void *);
+extern pm_callback pm_kbd_request_override;
extern unsigned char pckbd_sysrq_xlate[128];
#define kbd_setkeycode pckbd_setkeycode
Hello Everyone,
Some news about the APM problem on Dell Latitude C600:
On Thu, 1 Nov 2001, Stephen Rothwell wrote:
> Can you try the following patch, please? This is the relevant part of a
> patch that was applied to Alan Cox's kernels.
I tested this patch against 2.4.10-pre12 (first version showing problem)
and 2.4.13.
I tested also plain 2.4.13-ac5 since you (Stephen) said that this patch
was taken from the last Alan kernel.
Both kernels show the same behaviour, so please read on since 2.4.13-ac5
is impacted by this bug.
I tested the patch against 2.4.10-pre12.
(I had to suppress a line in arch/i386/kernel/dmi_scan.c to make it compile
since it defined pm_kbd_request_override differently than the definition in
keyboard.h) The patch seemed to correct the apm behaviour nicely (I use
'seem' since I tried it only once in a hurry to test against 2.4.13).
So I tested the same patch against 2.4.13. It went through without any
reject, compilation was fine also ... I tested also 2.4.13-ac5 and both
show the same ill behaviour:
Fn+Suspend (or launching "apm -s") does not ALWAYS suspend the laptop.
Sometimes, it blanks the screen but leaves the lcd light on, the cpu fan is
on also. Pressing Fn+D to turn off the lcd light completes the job and the
laptop finaly suspends completely.
Typing "apm -s" shows the same behaviour, it did suspend the laptop ONCE out
of 12 tests, all other 11 tests required to press Fn+D after to suspend.
By the way, If I hit ANY key between Fn+Suspend and Fn+D, the keyboard
is misbehaving after resume: CapsLock is inverted, Ctrl, Shift and Alt
are dead.
Under some rare conditions, apm -s works, but in general, asking the bios
to turn off the lcd light (Fn+D) helps a lot.
I guess the keyboard problem is not a real one since if "apm -s" did its job
completely I would no chance to press any key before the lcd light goes off.
Statistically, 2.4.13-ac5 seems to show better luck in suspending (it works
correctly more often than 2.4.13+patch from Stephen).
Pascal
> Fn+Suspend (or launching "apm -s") does not ALWAYS suspend
> the laptop. Sometimes, it blanks the screen but leaves the
> lcd light on, the cpu fan is on also. Pressing Fn+D to turn
> off the lcd light completes the job and the laptop finaly
> suspends completely.
My guess is that what is happening is: apm receives the event
and notifies apmd an X. X blanks the display and returns.
apmd processes the event and returns. apm does suspend().
But then you hit some BIOS bug. Or the BIOS expects the
OS to turn off the LCD light before returning.
Does it make any difference if apmd and X are NOT running?
Stephen: Do you think it would be worth sticking a call to
apm_console_blank inside suspend() for this person to see
if it helps?
--
Thomas
P.S. Stephen: Should the line "ignore_normal_resume = 1;"
inside suspend() be put prior to the sti()?
Alan Cox <[email protected]> wrote:
>> I, byt the way, had my Latitude suspend perfectly with 2.4.12-ac5.
>> Now, with 2.4.13-ac[34] pressing Fn+Suspend just blanks the screen
>> (it doesn't shut it off, _just_ blanks it) and hangs the machine.
> Find exactly which -ac it broke in. If you do a binary search
> through a few patch levels you should be able to pin it down. At
> that point I can chase it
I didn't have time to do this earlier, but now:
It seems it broke with 2.4.12-ac4, which I believe updated APM
subsystem from 1.14 to 1.15.
Suonp??...
> It seems it broke with 2.4.12-ac4, which I believe updated APM
> subsystem from 1.14 to 1.15.
Thanks. That sounds much like my thinkpad, which I now have working again.
If so then it'll work again soon in a 2.4.15pre/16pre
On Fri, 2 Nov 2001, Pascal Lengard wrote:
Hello,
For anyone of interest:
I tested plain 2.4.16 and the problems with APM are still there ...
Fn+suspend does work "sometimes" (1 out of 5 tests)
When it does not work, the laptop is stuck in a state with lcd screen lighted (but all black)
pressing Fn+D to turn off the display works and the apm_suspend finish its job (turning off
all other things like fans ...)
Usually when is suspends, it resumes nicely, but sometimes the laptop reboots
instead of resuming ... thanks for ext3fs !!
Pascal Lengard
> Some news about the APM problem on Dell Latitude C600:
>
> On Thu, 1 Nov 2001, Stephen Rothwell wrote:
> > Can you try the following patch, please? This is the relevant part of a
> > patch that was applied to Alan Cox's kernels.
>
> I tested this patch against 2.4.10-pre12 (first version showing problem)
> and 2.4.13.
> I tested also plain 2.4.13-ac5 since you (Stephen) said that this patch
> was taken from the last Alan kernel.
>
> Both kernels show the same behaviour, so please read on since 2.4.13-ac5
> is impacted by this bug.
>
> I tested the patch against 2.4.10-pre12.
> (I had to suppress a line in arch/i386/kernel/dmi_scan.c to make it compile
> since it defined pm_kbd_request_override differently than the definition in
> keyboard.h) The patch seemed to correct the apm behaviour nicely (I use
> 'seem' since I tried it only once in a hurry to test against 2.4.13).
>
> So I tested the same patch against 2.4.13. It went through without any
> reject, compilation was fine also ... I tested also 2.4.13-ac5 and both
> show the same ill behaviour:
>
> Fn+Suspend (or launching "apm -s") does not ALWAYS suspend the laptop.
> Sometimes, it blanks the screen but leaves the lcd light on, the cpu fan is
> on also. Pressing Fn+D to turn off the lcd light completes the job and the
> laptop finaly suspends completely.
> Typing "apm -s" shows the same behaviour, it did suspend the laptop ONCE out
> of 12 tests, all other 11 tests required to press Fn+D after to suspend.
>
> By the way, If I hit ANY key between Fn+Suspend and Fn+D, the keyboard
> is misbehaving after resume: CapsLock is inverted, Ctrl, Shift and Alt
> are dead.
>
> Under some rare conditions, apm -s works, but in general, asking the bios
> to turn off the lcd light (Fn+D) helps a lot.
> I guess the keyboard problem is not a real one since if "apm -s" did its job
> completely I would no chance to press any key before the lcd light goes off.
>
> Statistically, 2.4.13-ac5 seems to show better luck in suspending (it works
> correctly more often than 2.4.13+patch from Stephen).
>
> Pascal
>
>
It's a long shot, but you might try upgrading to
the latest release of apmd, 3.0.2. You might also
try killing apmd altogether before suspending;
see what happens.
Does it make any difference if X is not running
when you try to suspend?
Is your BIOS up to date?
Is the only problem the fact that you sometimes have
to press Fn+D to get the suspend to complete? If so,
that doesn't seem like too big a deal (even if it would
be nice if it were fixed). Or is the problem more
serious than that?
Thomas
Hello,
I have a problem running kernel 2.4.17 patched with
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.17-1.patch
First I must say that I run 2.4.17 + international patches (crypto fs)
and freeswan. I know I should test with just preempt to see what happens,
but I have to find time ... and 2.4.17+crypto+freeswan works correctly.
the story:
I patched in this order:
2.4.17+preempt+crypto+freeswan
The symptom is: only slot 00 of pccard works. inserting a card in slot 01
does nothing although yenta_socket reports 2 slots found in /var/log/messages
(I see no difference in logs between working kernel and broken one).
Now I am using a kernel patched in this order:
2.4.17+crypto+freeswan and both slots (00 and 01) behave correctly.
Hardware is dell latitude C600 (with apm problem on standard kernel by the way ...)
Does anyone see some light there ?
Could the symptom really be linked to preempt patch ?
I'd love to see if preempt really is interesting on a laptop ...
If it does interest someone, I could test just 2.4.17+preempt just to see ...
Pascal
(Oops, I think I sent this via private mail last time, instead of to the
list.)
I've also seen problems with the preempt patch and PCMCIA/CardBus, on my
Dell Inspiron 5000e. The top CardBus slot doesn't work for me with the
preemption patch (in fact, if I have a card in there, sometimes the
machine freezes at the point in boot when it would normally detect the
card). It usually doesn't even see that I've put a card in there. I don't
remember trying the bottom slot instead of the top though.
I just never got a chance to report the problem, until now. This has
happened with a range of kernels (I think I first tried the preempt patch
back around 2.4.14pre and I last tried it with a late 2.4.17-pre or with
2.4.17-rc1.)
-Barry K. Nathan <[email protected]>
I believe I also saw this when trying a preempt kernel somewhere in the
2.4.17pre series. Only one cardbus slot worked (I think it was the
bottom slot that didn't respond, but I could be mistaken). I was playing
around with various patches at the time, so I didn't pay much attention
to it. I can try to verify it if that would help. This was on a Dell
Latitude CPi D266XT.
/cyr
--
-----------------------------------------------------------------------
You really think you can buy me with promises of power and glory.
You really think... Okay, I'll do it. -- Rimmer