Hi
I'm really having a hard time with APM on 2.6.x. I have a DELL Latitude
L400 with the newest BIOS release. The most important functionality
of APM for me is the 'suspend to RAM' function which worked like
it should on all 2.4.x kernels I've tested. Under 2.6.x it simply does
not resume the second
time. Meaning it suspends and resumes once but when suspending the second
time the machine only brings up the LEDs and FAN and is stucked. I've
modified the kernel option for APM but that did not help at all.
I've already stated that question here and googled my fingers down to the
bones. The discussion always goes in these directions:
(1) Wait until ACPI is fully functional. Although a lot of people claim that
there are a lot of BIOses around that do not implement it properly and that
even MS-evel Windows has its problems with it.
(2) Exchange the motherboard.
(3) Buy a decent computer.
(4) Stick with 2.4.x
(5) And so on and so forth
All of this is not very constructive.
My impression is that APM is slowly degenerating while ACPI is not
(yet ?) able to fill the gap. The suspend feature of ACPI is stated to
be dangerous and experimental and does not work for me at all.
After all this bashing...
Is there anyone out there who has the same experiences ?
Is there a workaround ?
Is it possible to somehow downgrade APM in the 2.6 kernel
to the 2.4.x state ?
How could one debug this kind of missbehaviour ? Where do
I have to look for potential miss configurations of the system ?
I'm really willing to help the APM developers to track down this bug
but don't have a clue how to debug this kind stuff.
Thanks for your attention
Sebastian
On Fri, 4 Jun 2004, Sebastian Kloska wrote:
> After all this bashing...
>
> Is there anyone out there who has the same experiences ?
I had the same problem at one time. Does disabling i2c help at all??
If so, the problem is probably in the w83781d or w83627hf driver; I could
send you a copy of the patch, or you could just get the latest i2c release
from http://www2.lm-sensors.nu/~lm78/index.html
--
Just because it isn't nice doesn't make it any less a miracle.
http://users.albatross.co.nz/~psycho/ O- -><-
On Fri, 4 Jun 2004, Sebastian Kloska wrote:
>
> I'm really having a hard time with APM on 2.6.x. I have a DELL Latitude
> L400 with the newest BIOS release. The most important functionality
> of APM for me is the 'suspend to RAM' function which worked like
> it should on all 2.4.x kernels I've tested. Under 2.6.x it simply does
> not resume the second time.
Here's a patch I've been using to resume on Dell Latitude C610 for the
last eight months or so. I've never sent it in because I guess it's
just papering over some deeper issue (with the BIOS? originally some
earlier revision, I updated to latest A16 back then, but no change).
The funny thing is, that the code which resumes is relying on an APM
event to tell it that it's resuming, and that event sometimes doesn't
arrive. This patch lets the resuming code jump to the wild conclusion
that it's resuming, without relying on that event. I hope this helps
you, but fear your issue may be something else.
Hugh
--- 2.6.6/arch/i386/kernel/apm.c 2004-05-10 03:33:36.000000000 +0100
+++ linux/arch/i386/kernel/apm.c 2004-05-10 07:29:55.021595384 +0100
@@ -389,7 +389,9 @@ static int suspends_pending;
static int standbys_pending;
static int ignore_sys_suspend;
static int ignore_normal_resume;
+static int ignore_bounce;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
+static unsigned long last_resume;
#ifdef CONFIG_APM_RTC_IS_GMT
# define clock_cmos_diff 0
@@ -1225,11 +1227,14 @@ static int suspend(int vetoable)
spin_lock(&i8253_lock);
reinit_timer();
set_time();
- ignore_normal_resume = 1;
-
spin_unlock(&i8253_lock);
write_sequnlock_irq(&xtime_lock);
+ ignore_normal_resume = 1;
+ ignore_sys_suspend = -1;
+ last_resume = jiffies;
+ ignore_bounce = 1;
+
if (err == APM_NO_ERROR)
err = APM_SUCCESS;
if (err != APM_SUCCESS)
@@ -1239,6 +1244,7 @@ static int suspend(int vetoable)
device_resume();
pm_send_all(PM_RESUME, (void *)0);
queue_event(APM_NORMAL_RESUME, NULL);
+ ignore_normal_resume = 0;
out:
spin_lock(&user_list_lock);
for (as = user_list; as != NULL; as = as->next) {
@@ -1289,8 +1295,6 @@ static apm_event_t get_event(void)
static void check_events(void)
{
apm_event_t event;
- static unsigned long last_resume;
- static int ignore_bounce;
while ((event = get_event()) != 0) {
if (debug) {
@@ -1333,8 +1337,10 @@ static void check_events(void)
* sending a SUSPEND event until something else
* happens!
*/
- if (ignore_sys_suspend)
+ if (ignore_sys_suspend > 0)
return;
+ if (ignore_sys_suspend < 0)
+ printk("suspend: missed resume event\n");
ignore_sys_suspend = 1;
queue_event(event, NULL);
if (suspends_pending <= 0)
No i2c is completely disabled
Keith Duthie wrote:
>On Fri, 4 Jun 2004, Sebastian Kloska wrote:
>
>
>
>>After all this bashing...
>>
>>Is there anyone out there who has the same experiences ?
>>
>>
>
>I had the same problem at one time. Does disabling i2c help at all??
>
>If so, the problem is probably in the w83781d or w83627hf driver; I could
>send you a copy of the patch, or you could just get the latest i2c release
>from http://www2.lm-sensors.nu/~lm78/index.html
>
>
Thanks for the patch
Unfortunately that didn't do the trick. It does not even suspend
sometimes when hitting the suspend button. This is very strange.
It reproducible does not resume the second time. Seems like
the system has been left in an unstable state after the first
suspend/resume cycle. I'm definitely not the born hardware/BIOS
programmer although I have been involved in graphic device
programming (a pain) but in this this case which is a real pain I
would be willing to at least help by further debugging the issue.
Kernel 2.4.x proved that the BIOS can be talked into properly
interacting with linux. So it's at least not totally brain dead.
One might argue that the hardware is already a little bit out dated
but I really do not have the resources to buy a new
laptop every year and it also represents some kind of masochistic
challenge to get this thing going. But I really do not know how
to debug the stuff or where to look.
Any hints how to proceed would be highly appreciated
Sebastian
Hugh Dickins wrote:
>On Fri, 4 Jun 2004, Sebastian Kloska wrote:
>
>
>>I'm really having a hard time with APM on 2.6.x. I have a DELL Latitude
>>L400 with the newest BIOS release. The most important functionality
>>of APM for me is the 'suspend to RAM' function which worked like
>>it should on all 2.4.x kernels I've tested. Under 2.6.x it simply does
>>not resume the second time.
>>
>>
>
>Here's a patch I've been using to resume on Dell Latitude C610 for the
>last eight months or so. I've never sent it in because I guess it's
>just papering over some deeper issue (with the BIOS? originally some
>earlier revision, I updated to latest A16 back then, but no change).
>
>The funny thing is, that the code which resumes is relying on an APM
>event to tell it that it's resuming, and that event sometimes doesn't
>arrive. This patch lets the resuming code jump to the wild conclusion
>that it's resuming, without relying on that event. I hope this helps
>you, but fear your issue may be something else.
>
>Hugh
>
>--- 2.6.6/arch/i386/kernel/apm.c 2004-05-10 03:33:36.000000000 +0100
>+++ linux/arch/i386/kernel/apm.c 2004-05-10 07:29:55.021595384 +0100
>@@ -389,7 +389,9 @@ static int suspends_pending;
> static int standbys_pending;
> static int ignore_sys_suspend;
> static int ignore_normal_resume;
>+static int ignore_bounce;
> static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
>+static unsigned long last_resume;
>
> #ifdef CONFIG_APM_RTC_IS_GMT
> # define clock_cmos_diff 0
>@@ -1225,11 +1227,14 @@ static int suspend(int vetoable)
> spin_lock(&i8253_lock);
> reinit_timer();
> set_time();
>- ignore_normal_resume = 1;
>-
> spin_unlock(&i8253_lock);
> write_sequnlock_irq(&xtime_lock);
>
>+ ignore_normal_resume = 1;
>+ ignore_sys_suspend = -1;
>+ last_resume = jiffies;
>+ ignore_bounce = 1;
>+
> if (err == APM_NO_ERROR)
> err = APM_SUCCESS;
> if (err != APM_SUCCESS)
>@@ -1239,6 +1244,7 @@ static int suspend(int vetoable)
> device_resume();
> pm_send_all(PM_RESUME, (void *)0);
> queue_event(APM_NORMAL_RESUME, NULL);
>+ ignore_normal_resume = 0;
> out:
> spin_lock(&user_list_lock);
> for (as = user_list; as != NULL; as = as->next) {
>@@ -1289,8 +1295,6 @@ static apm_event_t get_event(void)
> static void check_events(void)
> {
> apm_event_t event;
>- static unsigned long last_resume;
>- static int ignore_bounce;
>
> while ((event = get_event()) != 0) {
> if (debug) {
>@@ -1333,8 +1337,10 @@ static void check_events(void)
> * sending a SUSPEND event until something else
> * happens!
> */
>- if (ignore_sys_suspend)
>+ if (ignore_sys_suspend > 0)
> return;
>+ if (ignore_sys_suspend < 0)
>+ printk("suspend: missed resume event\n");
> ignore_sys_suspend = 1;
> queue_event(event, NULL);
> if (suspends_pending <= 0)
>
>
>
On 06/06/04 01:18, Sebastian Kloska wrote:
> Thanks for the patch
>
> Unfortunately that didn't do the trick. It does not even suspend
> sometimes when hitting the suspend button. This is very strange.
> It reproducible does not resume the second time. Seems like
> the system has been left in an unstable state after the first
> suspend/resume cycle. I'm definitely not the born hardware/BIOS
> programmer although I have been involved in graphic device
> programming (a pain) but in this this case which is a real pain I
> would be willing to at least help by further debugging the issue.
> Kernel 2.4.x proved that the BIOS can be talked into properly
> interacting with linux. So it's at least not totally brain dead.
One possibility is code sections incorrectly marked as discardable.
I once had problems with this which caused resume to fail with ooops
when certain drivers were in use (and IIRC 2nd resume would lock up).
Someone here may know how to disable discarding of discardable sections
temporarily to test this by modifiying arch/i386/kernel/vmlinux.lds.S
(although personally I don't know how to do this).
Have you tried suspend/resume on a kernel with minimal devices
compiled/loaded running single user with just apmd? If this works
then do a binary divide and conquer until you find the misbehaving
driver.
> One might argue that the hardware is already a little bit out dated
> but I really do not have the resources to buy a new
> laptop every year and it also represents some kind of masochistic
> challenge to get this thing going. But I really do not know how
> to debug the stuff or where to look.
>
> Any hints how to proceed would be highly appreciated
>
> Sebastian
>
>
> Hugh Dickins wrote:
>
>> On Fri, 4 Jun 2004, Sebastian Kloska wrote:
>>
>>
>>> I'm really having a hard time with APM on 2.6.x. I have a DELL Latitude
>>> L400 with the newest BIOS release. The most important functionality
>>> of APM for me is the 'suspend to RAM' function which worked like
>>> it should on all 2.4.x kernels I've tested. Under 2.6.x it simply
>>> does not resume the second time.
>>>
>>
>>
>> Here's a patch I've been using to resume on Dell Latitude C610 for the
>> last eight months or so. I've never sent it in because I guess it's
>> just papering over some deeper issue (with the BIOS? originally some
>> earlier revision, I updated to latest A16 back then, but no change).
>>
>> The funny thing is, that the code which resumes is relying on an APM
>> event to tell it that it's resuming, and that event sometimes doesn't
>> arrive. This patch lets the resuming code jump to the wild conclusion
>> that it's resuming, without relying on that event. I hope this helps
>> you, but fear your issue may be something else.
>>
>> Hugh
>>
>> --- 2.6.6/arch/i386/kernel/apm.c 2004-05-10 03:33:36.000000000 +0100
>> +++ linux/arch/i386/kernel/apm.c 2004-05-10 07:29:55.021595384 +0100
>> @@ -389,7 +389,9 @@ static int suspends_pending;
>> static int standbys_pending;
>> static int ignore_sys_suspend;
>> static int ignore_normal_resume;
>> +static int ignore_bounce;
>> static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
>> +static unsigned long last_resume;
>>
>> #ifdef CONFIG_APM_RTC_IS_GMT
>> # define clock_cmos_diff 0
>> @@ -1225,11 +1227,14 @@ static int suspend(int vetoable)
>> spin_lock(&i8253_lock);
>> reinit_timer();
>> set_time();
>> - ignore_normal_resume = 1;
>> -
>> spin_unlock(&i8253_lock);
>> write_sequnlock_irq(&xtime_lock);
>>
>> + ignore_normal_resume = 1;
>> + ignore_sys_suspend = -1;
>> + last_resume = jiffies;
>> + ignore_bounce = 1;
>> +
>> if (err == APM_NO_ERROR)
>> err = APM_SUCCESS;
>> if (err != APM_SUCCESS)
>> @@ -1239,6 +1244,7 @@ static int suspend(int vetoable)
>> device_resume();
>> pm_send_all(PM_RESUME, (void *)0);
>> queue_event(APM_NORMAL_RESUME, NULL);
>> + ignore_normal_resume = 0;
>> out:
>> spin_lock(&user_list_lock);
>> for (as = user_list; as != NULL; as = as->next) {
>> @@ -1289,8 +1295,6 @@ static apm_event_t get_event(void)
>> static void check_events(void)
>> {
>> apm_event_t event;
>> - static unsigned long last_resume;
>> - static int ignore_bounce;
>>
>> while ((event = get_event()) != 0) {
>> if (debug) {
>> @@ -1333,8 +1337,10 @@ static void check_events(void)
>> * sending a SUSPEND event until something else
>> * happens!
>> */
>> - if (ignore_sys_suspend)
>> + if (ignore_sys_suspend > 0)
>> return;
>> + if (ignore_sys_suspend < 0)
>> + printk("suspend: missed resume event\n");
>> ignore_sys_suspend = 1;
>> queue_event(event, NULL);
>> if (suspends_pending <= 0)
Michael Clark <[email protected]> wrote:
>
> One possibility is code sections incorrectly marked as discardable.
`make buildcheck' will locate these.
Andrew Morton wrote:
>Michael Clark <[email protected]> wrote:
>
>
>>One possibility is code sections incorrectly marked as discardable.
>>
>>
>
>`make buildcheck' will locate these.
>
>
Hmmm .. ? Couldn't find any buildcheck: target in the Makefiles
Denis Vlasenko wrote:
>On Saturday 05 June 2004 20:18, Sebastian Kloska wrote:
>
>
>> Thanks for the patch
>>
>> Unfortunately that didn't do the trick. It does not even suspend
>> sometimes when hitting the suspend button. This is very strange.
>> It reproducible does not resume the second time. Seems like
>> the system has been left in an unstable state after the first
>> suspend/resume cycle. I'm definitely not the born hardware/BIOS
>> programmer although I have been involved in graphic device
>> programming (a pain) but in this this case which is a real pain I
>> would be willing to at least help by further debugging the issue.
>> Kernel 2.4.x proved that the BIOS can be talked into properly
>> interacting with linux. So it's at least not totally brain dead.
>>
>> One might argue that the hardware is already a little bit out dated
>> but I really do not have the resources to buy a new
>> laptop every year and it also represents some kind of masochistic
>> challenge to get this thing going. But I really do not know how
>> to debug the stuff or where to look.
>>
>> Any hints how to proceed would be highly appreciated
>>
>>
>
>
>
>Well, typically I pepper source with printks, rebuild kernel,
>reboot, set loglevel to max, watch the log, crash, repeat.
>
>
Realy was afraid you say something like this. Now I'll follow
Michael Clarks recommentation of ripping down the kernel
to minimal functionality and add drivers/moduls until I hit
the 'bad' one. ... keep you informed
>--
>vda
>
>
>
--
**********************************
Dr. Sebastian Kloska
Head of Bioinformatics
Scienion AG
Volmerstr. 7a
12489 Berlin
phone: +49-(30)-6392-1708
fax: +49-(30)-6392-1701
http://www.scienion.de
**********************************
Hi!
> My impression is that APM is slowly degenerating while ACPI is not
> (yet ?) able to fill the gap. The suspend feature of ACPI is stated to
> be dangerous and experimental and does not work for me at all.
That sounds about right.
> After all this bashing...
>
> Is there anyone out there who has the same experiences ?
>
> Is there a workaround ?
>
> Is it possible to somehow downgrade APM in the 2.6 kernel
> to the 2.4.x state ?
>
> How could one debug this kind of missbehaviour ? Where do
> I have to look for potential miss configurations of the system ?
>
> I'm really willing to help the APM developers to track down this bug
> but don't have a clue how to debug this kind stuff.
What APM developers? There are none as far as I know.
Try removing calls to device_* in apm.c. Better yet become APM
developer.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
Pavel Machek wrote:
> Hi!
>
>
>>My impression is that APM is slowly degenerating while ACPI is not
>>(yet ?) able to fill the gap. The suspend feature of ACPI is stated to
>>be dangerous and experimental and does not work for me at all.
>
>
> That sounds about right.
>
>
>>After all this bashing...
>>
>>Is there anyone out there who has the same experiences ?
>>
>>Is there a workaround ?
>>
>>Is it possible to somehow downgrade APM in the 2.6 kernel
>>to the 2.4.x state ?
>>
>>How could one debug this kind of missbehaviour ? Where do
>>I have to look for potential miss configurations of the system ?
>>
>>I'm really willing to help the APM developers to track down this bug
>>but don't have a clue how to debug this kind stuff.
>
>
> What APM developers? There are none as far as I know.
Hmmm ... So once again the Tooth Fairy and Santa Claus :-) ?
At least a
grep '<.*@' /usr/src/linux-2.6.6/arch/i386/kernel/apm.c | sed 's/.*<//' | sed 's/>.*//'
gives me:
<snip>
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
</snip>
This is pretty much for no one. And I guess you knew since you're on
the list yourself. But I think you're right when meaning
that there is not much of active maintenance anymore. Which at
least I find a little bit discouraging when looking of the state
of the ACPI support.
>
> Try removing calls to device_* in apm.c. Better yet become APM
> developer.
It seems like I'm on my way to do so (still reluctantly). As I stated
in my previous mails I'm not born as a hardware/BIOS hacker (more the
application C++/Java stuff) but I'm willing to learn. When I'm
grown up I definitely want to be linux kernel hacker :-) ...
Currently I ripped down the 2.6.6 kernel to almost nothing
and add one module after the other checking for proper
suspend/resume behavior....
The most suspicious candidates on my list are currently the
USB-UHCI driver and the ALSA sound system, which is my #1 candidate
since it has not been an integral part of the 2.4.x (x<=20) kernels.
So if anybody out there could give me guidance on how the apm code
might interact with the ALSA sound system it would be highly
appreciated....
Thanks
Sebastian
> Pavel
Hi!
> >>I'm really willing to help the APM developers to track down this bug
> >>but don't have a clue how to debug this kind stuff.
> >
> >
> >What APM developers? There are none as far as I know.
>
>
> Hmmm ... So once again the Tooth Fairy and Santa Claus :-) ?
>
> At least a
>
> grep '<.*@' /usr/src/linux-2.6.6/arch/i386/kernel/apm.c | sed 's/.*<//' |
> sed 's/>.*//'
>
> gives me:
>
> <snip>
> [email protected]
...
> [email protected]
> </snip>
>
> This is pretty much for no one. And I guess you knew since you're on
> the list yourself. But I think you're right when meaning
> that there is not much of active maintenance anymore. Which at
> least I find a little bit discouraging when looking of the state
> of the ACPI support.
Yes, that's pretty much what I meant. ACPI has ~5 people actively
working on it, some of them probably full-time. That's a lot of
manpower, compared to APM.
And ACPI is in pretty good state, btw, unless you want
suspend-to-RAM. Unfortunately you want suspend-to-RAM.
> >Try removing calls to device_* in apm.c. Better yet become APM
> >developer.
>
> It seems like I'm on my way to do so (still reluctantly). As I stated
> in my previous mails I'm not born as a hardware/BIOS hacker (more the
> application C++/Java stuff) but I'm willing to learn. When I'm
> grown up I definitely want to be linux kernel hacker :-) ...
>
> Currently I ripped down the 2.6.6 kernel to almost nothing
> and add one module after the other checking for proper
> suspend/resume behavior....
>
> The most suspicious candidates on my list are currently the
> USB-UHCI driver and the ALSA sound system, which is my #1 candidate
> since it has not been an integral part of the 2.4.x (x<=20) kernels.
>
>
> So if anybody out there could give me guidance on how the apm code
> might interact with the ALSA sound system it would be highly
> appreciated....
device_suspend() will propagate all the way to alsa.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
Hi again
Thanks for the hint on device_suspend (realy !! gives me a starting point
for debugging.
Pavel Machek wrote:
> Hi!
>
>
>>>>I'm really willing to help the APM developers to track down this bug
>>>>but don't have a clue how to debug this kind stuff.
>>>
>>>
>>>What APM developers? There are none as far as I know.
>>
>>
>> Hmmm ... So once again the Tooth Fairy and Santa Claus :-) ?
>>
>> At least a
>>
>> grep '<.*@' /usr/src/linux-2.6.6/arch/i386/kernel/apm.c | sed 's/.*<//' |
>> sed 's/>.*//'
>>
>> gives me:
>>
>><snip>
>>[email protected]
>
> ...
>
>>[email protected]
>></snip>
>>
>>This is pretty much for no one. And I guess you knew since you're on
>>the list yourself. But I think you're right when meaning
>>that there is not much of active maintenance anymore. Which at
>>least I find a little bit discouraging when looking of the state
>>of the ACPI support.
>
>
> Yes, that's pretty much what I meant. ACPI has ~5 people actively
> working on it, some of them probably full-time. That's a lot of
> manpower, compared to APM.
This becomes a little bit scary. Someone else on this list already
mentioned that there is a strong movement towards everything which
is at least a desktop/server machine. And on the other hand there are
these embedded systems which seem to be attractive for linux to.
ACPI seems to be nifty for such things like hardware monitoring and
stuff. That makes it interesting for servers etc...
Everything in the middle (aka laptops) seems to slowly drop out of the
loop. PCMCIA seems to be another ugly example. Anyway ... I'm not frightened
by this manpower. Just want to have my laptop running 2.6.x and suspending
to RAM. I'll do my very best and report back if there are any significant
findings.....
>
> And ACPI is in pretty good state, btw, unless you want
> suspend-to-RAM. Unfortunately you want suspend-to-RAM.
>
>
>>>Try removing calls to device_* in apm.c. Better yet become APM
>>>developer.
>>
>> It seems like I'm on my way to do so (still reluctantly). As I stated
>> in my previous mails I'm not born as a hardware/BIOS hacker (more the
>> application C++/Java stuff) but I'm willing to learn. When I'm
>> grown up I definitely want to be linux kernel hacker :-) ...
>>
>> Currently I ripped down the 2.6.6 kernel to almost nothing
>> and add one module after the other checking for proper
>> suspend/resume behavior....
>>
>> The most suspicious candidates on my list are currently the
>> USB-UHCI driver and the ALSA sound system, which is my #1 candidate
>> since it has not been an integral part of the 2.4.x (x<=20) kernels.
>>
>>
>> So if anybody out there could give me guidance on how the apm code
>> might interact with the ALSA sound system it would be highly
>> appreciated....
>
>
> device_suspend() will propagate all the way to alsa.
> Pavel
--
**********************************
Dr. Sebastian Kloska
Head of Bioinformatics
Scienion AG
Volmerstr. 7a
12489 Berlin
phone: +49-(30)-6392-1708
fax: +49-(30)-6392-1701
http://www.scienion.de
**********************************
On Mon, 7 Jun 2004, Sebastian Kloska wrote:
> So if anybody out there could give me guidance on how the apm code
> might interact with the ALSA sound system it would be highly
> appreciated....
In a word, badly. For at least one chipset, suspending while outputting
to the pcm device causes the program outputting to the pcm device to enter
the uninterruptible sleep state. A reboot is then required for the pcm
device to be usable again...
(I attempted to report this back in February, but my bug report and
workaround patch apparently didn't get through the alsa-devel spam
filters.)
--
Just because it isn't nice doesn't make it any less a miracle.
http://users.albatross.co.nz/~psycho/ O- -><-
Hi!
> > So if anybody out there could give me guidance on how the apm code
> > might interact with the ALSA sound system it would be highly
> > appreciated....
>
> In a word, badly. For at least one chipset, suspending while outputting
> to the pcm device causes the program outputting to the pcm device to enter
> the uninterruptible sleep state. A reboot is then required for the pcm
> device to be usable again...
>
> (I attempted to report this back in February, but my bug report and
> workaround patch apparently didn't get through the alsa-devel spam
> filters.)
Submit a patch.. alsa developers are very unlikely to use APM.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
Thanks ...
The pure ALSA system with PCI Cirrus Logic CS4281
(my configuration) just dropped of my list of
the 'bad' one ....
Does this bug freeze the machine ? Or just block
the outputting program ?
PCM will be the next to look at...
+-compile->reboot->check->-+
^ |
| |
+---<----------------------+
Kind of feel like in the old days where
a decend 'printf(stderr,....)' was THE
state of the art debugging tool ....
Cheers
S.,
Keith Duthie wrote:
> On Mon, 7 Jun 2004, Sebastian Kloska wrote:
>
>
>> So if anybody out there could give me guidance on how the apm code
>> might interact with the ALSA sound system it would be highly
>> appreciated....
>
>
> In a word, badly. For at least one chipset, suspending while outputting
> to the pcm device causes the program outputting to the pcm device to enter
> the uninterruptible sleep state. A reboot is then required for the pcm
> device to be usable again...
>
> (I attempted to report this back in February, but my bug report and
> workaround patch apparently didn't get through the alsa-devel spam
> filters.)
--
**********************************
Dr. Sebastian Kloska
Head of Bioinformatics
Scienion AG
Volmerstr. 7a
12489 Berlin
phone: +49-(30)-6392-1708
fax: +49-(30)-6392-1701
http://www.scienion.de
**********************************
Hi!
> >Yes, that's pretty much what I meant. ACPI has ~5 people actively
> >working on it, some of them probably full-time. That's a lot of
> >manpower, compared to APM.
>
>
> This becomes a little bit scary. Someone else on this list already
> mentioned that there is a strong movement towards everything which
> is at least a desktop/server machine. And on the other hand there are
> these embedded systems which seem to be attractive for linux to.
>
> ACPI seems to be nifty for such things like hardware monitoring and
> stuff. That makes it interesting for servers etc...
>
> Everything in the middle (aka laptops) seems to slowly drop out of the
> loop. PCMCIA seems to be another ugly example. Anyway ... I'm not
> frightened
HP sells compaq nx5000 notebooks with Linux preloaded. Unfortunately
suspend-to-RAM is not there (IIRC). That's because suspend-to-RAM is
hard to do with ACPI.
PCMCIA... well, that's another obsolete technology. Too bad.
They are people who care about notebooks, there's just no one that
cares about *old* notebooks any more.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
Hi!
> The pure ALSA system with PCI Cirrus Logic CS4281
> (my configuration) just dropped of my list of
> the 'bad' one ....
>
> Does this bug freeze the machine ? Or just block
> the outputting program ?
>
> PCM will be the next to look at...
Drop all non-important hw. That's everything but keyboard, VGA and
harddrive...
> +-compile->reboot->check->-+
> ^ |
> | |
> +---<----------------------+
>
> Kind of feel like in the old days where
> a decend 'printf(stderr,....)' was THE
> state of the art debugging tool ....
Its *still* state of the art debugging tool for kernel.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
Pavel Machek wrote:
> Hi!
>
>
>> The pure ALSA system with PCI Cirrus Logic CS4281
>> (my configuration) just dropped of my list of
>> the 'bad' one ....
>>
>> Does this bug freeze the machine ? Or just block
>> the outputting program ?
>>
>> PCM will be the next to look at...
>
>
> Drop all non-important hw. That's everything but keyboard, VGA and
> harddrive...
>
Already did that and APM suspends/resumes fine. That gives
me hope to at least pinpoint the bad behaving module/driver....
>
>> +-compile->reboot->check->-+
>> ^ |
>> | |
>> +---<----------------------+
>>
>> Kind of feel like in the old days where
>> a decend 'printf(stderr,....)' was THE
>> state of the art debugging tool ....
>
>
> Its *still* state of the art debugging tool for kernel.
Tears of sentimental to reminisce wet my eyes ... :-)
> Pavel
--
**********************************
Dr. Sebastian Kloska
Head of Bioinformatics
Scienion AG
Volmerstr. 7a
12489 Berlin
phone: +49-(30)-6392-1708
fax: +49-(30)-6392-1701
http://www.scienion.de
**********************************
On Mon, 7 Jun 2004, Sebastian Kloska wrote:
> Does this bug freeze the machine ? Or just block
> the outputting program ?
The machine remains completely usable except for sound; the outputting
program is stuck in uninterruptible sleep, and hence is unkillable. I've
dug up my patch (which is against 2.6.5, but should patch cleanly with any
other 2.6, as it's merely a one liner), and will submit it in a separate
email.
--
Just because it isn't nice doesn't make it any less a miracle.
http://users.albatross.co.nz/~psycho/ O- -><-
Hi!
> >>Does this bug freeze the machine ? Or just block
> >>the outputting program ?
> >>
> >>PCM will be the next to look at...
> >
> >
> >Drop all non-important hw. That's everything but keyboard, VGA and
> >harddrive...
> >
> Already did that and APM suspends/resumes fine. That gives
> me hope to at least pinpoint the bad behaving module/driver....
Okay, then its easy. Find offending driver; removing its
suspend/resume routine should work it around for you.
Solving this properly will be slightly harder; it involves finding
what the driver did wrong. You might want to call the driver's
suspend/resume routine repeatedly without really suspending to see if
it breaks something.
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
On Mon, 2004-06-07 at 16:48 +0200, Pavel Machek wrote:
> HP sells compaq nx5000 notebooks with Linux preloaded. Unfortunately
> suspend-to-RAM is not there (IIRC). That's because suspend-to-RAM is
> hard to do with ACPI.
It took some time for me to work, but now ACPI S3 (suspend to RAM) is
finally working for me (I have been trying it since 2.4.22 with no
luck). Only one thing is required before suspending:
# modprobe ds
# cardctl eject
This ejects my CardBus NIC before going to sleep. Not doing so, causes
the system to freeze when resuming.
Hi Felipe ....
Lucky one ...
I do not even use PCMCIA and don't have the stuff
compiled in or use the modules ... but the reaction
to echo -n '3' >/proc/acpi/sleep is weired.
Somthing like (1) The first time nothing happens
and (2) On the second run the machine reboots....
Up until now I've been slowly upgrading my kernel
from minimal functionality to almost perfect
now USB, and ALSA has been added to the kernel
and I still can suspend/resume....
Now of cause I'm wandering what actually triggers
the crash ....
That might take some time ....
Thanks for the tip
Sebastian
Felipe Alfaro Solana wrote:
> On Mon, 2004-06-07 at 16:48 +0200, Pavel Machek wrote:
>
>
>>HP sells compaq nx5000 notebooks with Linux preloaded. Unfortunately
>>suspend-to-RAM is not there (IIRC). That's because suspend-to-RAM is
>>hard to do with ACPI.
>
>
> It took some time for me to work, but now ACPI S3 (suspend to RAM) is
> finally working for me (I have been trying it since 2.4.22 with no
> luck). Only one thing is required before suspending:
>
> # modprobe ds
> # cardctl eject
>
> This ejects my CardBus NIC before going to sleep. Not doing so, causes
> the system to freeze when resuming.
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
| PCMCIA... well, that's another obsolete technology. Too bad.
PCMCIA is obsolete? Did I miss something, or was this a joke?
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAxT2AjBz/yQjBxz8RAlP7AJwPKwcRGUXXPUmecVAPQIYqX6LHuACgspJF
VnS33PaDIFjNS29dPPOrakg=
=GIid
-----END PGP SIGNATURE-----
I also did not get that. And feel a little
bit obliged to apologize if my hardware is
older than >2 years ;-)
That's how it is when live at the
cutting bleeding edge.
But I also think that more and more
hardware functions (aka network, nd
f***ing WinModem (arrg) moves onto
the motherboards of the laptops)
Not to mention WLAN etc ...
So the support for PCMCIA will slowly
dissolve....
Cheers
Sebastian
Clemens Schwaighofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pavel Machek wrote:
>
> | PCMCIA... well, that's another obsolete technology. Too bad.
>
> PCMCIA is obsolete? Did I miss something, or was this a joke?
>
> - --
> Clemens Schwaighofer - IT Engineer & System Administration
> ==========================================================
> TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
> Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
> http://www.tequila.co.jp
> ==========================================================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAxT2AjBz/yQjBxz8RAlP7AJwPKwcRGUXXPUmecVAPQIYqX6LHuACgspJF
> VnS33PaDIFjNS29dPPOrakg=
> =GIid
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi!
> | PCMCIA... well, that's another obsolete technology. Too bad.
>
> PCMCIA is obsolete? Did I miss something, or was this a joke?
Obsoleted by cardbus, I believe. (cardbus cards look like PCMCIA
cards, but electrical protocol is different) Plus, as someone else
noted, stuff moves into mainboard. USB also replacs part of what
PCMCIA was for.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
| Hi!
|
|
|>| PCMCIA... well, that's another obsolete technology. Too bad.
|>
|>PCMCIA is obsolete? Did I miss something, or was this a joke?
|
|
| Obsoleted by cardbus, I believe. (cardbus cards look like PCMCIA
| cards, but electrical protocol is different) Plus, as someone else
| noted, stuff moves into mainboard. USB also replacs part of what
| PCMCIA was for.
hmm, I didn't know that there is a change from PCMCIA to cardbus.
Thought still there are lot of pcmcia stuff around. wlan cards, eg my
dial up card (CF card into a PCMCIA adapter). Well I wouldn't abandon
PCMCIA so fast. At least the linux kernel is know for beeing able to use
very old hardware in a very good way ...
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAxYC9jBz/yQjBxz8RAvY9AKC1kgmW0lPwAa0FCDN0pkf+ykmfswCeIT3F
2xJFPVDhuTi4PFi5ah6JV7Y=
=gF7B
-----END PGP SIGNATURE-----
Hi!
> |>| PCMCIA... well, that's another obsolete technology. Too bad.
> |>
> |>PCMCIA is obsolete? Did I miss something, or was this a joke?
> |
> |
> | Obsoleted by cardbus, I believe. (cardbus cards look like PCMCIA
> | cards, but electrical protocol is different) Plus, as someone else
> | noted, stuff moves into mainboard. USB also replacs part of what
> | PCMCIA was for.
>
> hmm, I didn't know that there is a change from PCMCIA to cardbus.
> Thought still there are lot of pcmcia stuff around. wlan cards, eg my
> dial up card (CF card into a PCMCIA adapter). Well I wouldn't abandon
> PCMCIA so fast. At least the linux kernel is know for beeing able to use
> very old hardware in a very good way ...
Yes, pcmcia still survives in form of compactflash, mostly used by
low-powered handhelds etc. That's where ISA survives too.
I agree that supporting PCMCIA is usefull, and that linux should run
on old hardware; but you can see that PCMCIA and APM is in "old
hardware" category, along with ISA, Pentium I CPUs and serial ports.
Linux still tries to support 386 cpus, and its right. However its not
same level of support as modern hardware.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
>>>>> "Sebastian" == Sebastian Kloska <[email protected]> writes:
Sebastian> But I also think that more and more hardware
Sebastian> functions (aka network, nd f***ing WinModem (arrg)
Sebastian> moves onto the motherboards of the laptops)
Sebastian> Not to mention WLAN etc ...
Sebastian> So the support for PCMCIA will slowly dissolve....
Add to that, that more and more devices and gadgets have a USB or
IEEE1394 interface, and new laptops have these versatile ports.
BTW, is there *still* any technical advantage of PCMCIA over USB or
1394? (e.g. I know that USB pre 2.0 didn't have DMA and the interrupt
model is inferior. That's why PCMCIA 100BaseT Ethernet cards are
superior to USB<-->Fast Ethernet bridges.)
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
| Hi!
|
|
|>|>| PCMCIA... well, that's another obsolete technology. Too bad.
|>|>
|>|>PCMCIA is obsolete? Did I miss something, or was this a joke?
|>|
|>|
|>| Obsoleted by cardbus, I believe. (cardbus cards look like PCMCIA
|>| cards, but electrical protocol is different) Plus, as someone else
|>| noted, stuff moves into mainboard. USB also replacs part of what
|>| PCMCIA was for.
|>
|>hmm, I didn't know that there is a change from PCMCIA to cardbus.
|>Thought still there are lot of pcmcia stuff around. wlan cards, eg my
|>dial up card (CF card into a PCMCIA adapter). Well I wouldn't abandon
|>PCMCIA so fast. At least the linux kernel is know for beeing able to use
|>very old hardware in a very good way ...
|
|
| Yes, pcmcia still survives in form of compactflash, mostly used by
| low-powered handhelds etc. That's where ISA survives too.
well and low-powered handhelds are one field where linux should run :)
at least on my zaurus its running happily [okay this doesn't have a
pcmcia slot, just an sd/card and cf/card]
| I agree that supporting PCMCIA is usefull, and that linux should run
| on old hardware; but you can see that PCMCIA and APM is in "old
| hardware" category, along with ISA, Pentium I CPUs and serial ports.
Well I wouldn't put PCMCIA into the same part as ISA and Pentium I,
because my 2 year old Sonylaptop with a Pentium-M 4 1.5Ghz has PCMCIA
slots ... So its not like it is found only on stone old Laptops.
| Linux still tries to support 386 cpus, and its right. However its not
| same level of support as modern hardware.
yeah but its very rare to find 386 (except perhaps junkyards), but its
very common to find PCMCIA. way more easy than Pentium I or ISA slots ...
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAxYvRjBz/yQjBxz8RArD4AKCehJaV3Rrh/U0kLuEvJB5mo7AABQCfSHgK
Dpl/LGbWYG9cP8K33LQlef4=
=Ik+A
-----END PGP SIGNATURE-----
Hi!
> | I agree that supporting PCMCIA is usefull, and that linux should run
> | on old hardware; but you can see that PCMCIA and APM is in "old
> | hardware" category, along with ISA, Pentium I CPUs and serial ports.
>
> Well I wouldn't put PCMCIA into the same part as ISA and Pentium I,
> because my 2 year old Sonylaptop with a Pentium-M 4 1.5Ghz has PCMCIA
> slots ... So its not like it is found only on stone old Laptops.
That's cardbus, I believe. Its backwards compatible to PCMCIA.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
Pavel Machek wrote:
> Hi!
>
>
>>| PCMCIA... well, that's another obsolete technology. Too bad.
>>
>>PCMCIA is obsolete? Did I miss something, or was this a joke?
>
>
> Obsoleted by cardbus, I believe. (cardbus cards look like PCMCIA
> cards, but electrical protocol is different) Plus, as someone else
> noted, stuff moves into mainboard. USB also replacs part of what
> PCMCIA was for.
Cardbus maybe, USB not. USB is very nice, but it's not typically SMALL.
A PCMCIA NIC card is a credit card size, a USB NIC is a box plus a
cable. Before you tell me I don't need it please name the affordable
laptop which has 2 NICs.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Tue, 2004-06-08 at 13:48 -0400, Bill Davidsen wrote:
> Cardbus maybe, USB not. USB is very nice, but it's not typically SMALL.
> A PCMCIA NIC card is a credit card size, a USB NIC is a box plus a
> cable. Before you tell me I don't need it please name the affordable
> laptop which has 2 NICs.
>
http://www.buy.com/prod/Compex_LinkPort_UE202_B_Network_Adapter_USB_EN_Fast_EN_10Base_T_100Base_TX/q/loc/417/10331738.html
Daniel
Bill Davidsen wrote:
> Pavel Machek wrote:
>
>> Hi!
>>
>>
>>> | PCMCIA... well, that's another obsolete technology. Too bad.
>>>
>>> PCMCIA is obsolete? Did I miss something, or was this a joke?
<snip>
>
> Cardbus maybe, USB not. USB is very nice, but it's not typically SMALL.
> A PCMCIA NIC card is a credit card size, a USB NIC is a box plus a
> cable. Before you tell me I don't need it please name the affordable
> laptop which has 2 NICs.
My USB nic is about 1.5*1.5*6cm, 10/100mbps ethernet, works with linux, cost
around $10 from ebay. Unfortunately, I've lost it, as it's rather small. Argh.
A problem with USB is that the connector is terribly designed for laptops.
A 5cm lever sticking out of laptops are bad. I've got several hacked plugs that
reduce this to 1cm, which is bearable.
IMO, all laptop connectors should be breakaway, when pulling the cable to detach
the connector at any angle does not destroy the connector.
It's only been a couple of years since the majority of low-end 802.11b cards being
sold were PCMCIA.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pavel Machek wrote:
|>Well I wouldn't put PCMCIA into the same part as ISA and Pentium I,
|>because my 2 year old Sonylaptop with a Pentium-M 4 1.5Ghz has PCMCIA
|>slots ... So its not like it is found only on stone old Laptops.
|
|
| That's cardbus, I believe. Its backwards compatible to PCMCIA.
well thats something I have to checkout ... I really rarerly use it, so
I can't say for sure what it is ...
- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAxlLzjBz/yQjBxz8RAmIGAJ9ZDl6HjJOR9+9LytOKeEYcsn7xSwCgnQ7R
kQF43IjDvepnhxW1E+UHmLc=
=Dnp3
-----END PGP SIGNATURE-----