More experiences with 2.6.13-rc3 with ec_polling patch

More experiences with 2.6.13-rc3 with ec_polling patch

[Pavel Troller]

Hi!
  I've applied the ec-polling patch and tried 2.6.13-rc3 (with ec_polling
option) again. However, there were more problems with it, so I'm again on -rc2.
I just remember that it's a CLEVO D610SU Notebook (P4/2G4/512M RAM).
The main symptoms were as follows:

0) Battery status and thermal zone are working OK. Fine.

1) When trying S3 by closing the lid, I found that my script doesn't work
because it cannot find /proc/acpi/button/lid/LID/state, where it reads the
switch status (it's a safety measure, because my lid switch sometimes generates
spurious events, probably it's very sensitive and reacts to machine vibrations,
so the script verifies here that the lid is really closed).
I didn't find any replacement of this file in /proc/acpi/hotkey. How the status
can be obtained now ?
  So I activated S3 sleep manually.

2) During S3, S4 sleeping process a new message, not present in -rc2, appeared:

acpi_bus-0212 [535] acpi_bus_set_power    : Device is not power manageable
I don't know whether it is important or not.

And now, the more serious problems:

3) After resume from S3, pwr/lid switches didn't work (didn't generate events).

4) I called S4 sleep script manually. After the obvious procedure, the machine
   turned itself off. However, after pressing the power switch it started, 
   showed the BIOS screen and then crashed (even LILO screen didn't appear).
   I had to cycle the power again and it started OK then.

5) After resume from S4:

irq 10: nobody cared (try booting with the "irqpoll" option)
 [<c01412aa>] __report_bad_irq+0x2a/0xa0
 [<c0140a50>] handle_IRQ_event+0x30/0x70
 [<c01413c0>] note_interrupt+0x80/0xf0
 [<c0140bc4>] __do_IRQ+0x134/0x140
 [<c0105f73>] do_IRQ+0x23/0x40
 [<c0103f16>] common_interrupt+0x1a/0x20
 [<c0124773>] __do_softirq+0x43/0xb0
 [<c012480d>] do_softirq+0x2d/0x30
 [<c01248e7>] irq_exit+0x37/0x40
 [<c0105f78>] do_IRQ+0x28/0x40
 [<c0103f16>] common_interrupt+0x1a/0x20
 [<c039f360>] schedule+0x0/0x650
 [<c039fa63>] preempt_schedule_irq+0x43/0x80
 [<c010349e>] need_resched+0x1f/0x21
 [<c013ee20>] swsusp_suspend+0x50/0xc0
 [<c013faac>] pm_suspend_disk+0x3c/0x90
 [<c013d86c>] enter_state+0x6c/0x70
 [<c013d87f>] software_suspend+0xf/0x20
 [<c0247322>] acpi_system_write_sleep+0x6a/0x84
 [<c0162716>] vfs_write+0xb6/0x180
 [<c01628b1>] sys_write+0x51/0x80
 [<c0103559>] syscall_call+0x7/0xb
handlers:
[<dc86e850>] (snd_intel8x0_interrupt+0x0/0x240 [snd_intel8x0])
Disabling IRQ #10

...and then

ohci_hcd 0000:00:02.3: Unlink after no-IRQ?  Controller is probably using the wrong IRQ.

... and modprobe hci_usb didn't return.
/proc/interrupts shows

 10:     200000          XT-PIC  SiS SI7012, ohci_hcd:usb2

IRQ 10 is shared for sound card and USB. Neither of them worked after wake-up.

Neither of the problems reported is present in -rc2.
                                       With regards,
				              Pavel Troller


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: More experiences with 2.6.13-rc3 with ec_polling patch

[Pavel Machek]

Hi!

> 5) After resume from S4:
> 
> irq 10: nobody cared (try booting with the "irqpoll" option)
>  [<c01412aa>] __report_bad_irq+0x2a/0xa0
>  [<c0140a50>] handle_IRQ_event+0x30/0x70
>  [<c01413c0>] note_interrupt+0x80/0xf0
>  [<c0140bc4>] __do_IRQ+0x134/0x140
>  [<c0105f73>] do_IRQ+0x23/0x40
>  [<c0103f16>] common_interrupt+0x1a/0x20
>  [<c0124773>] __do_softirq+0x43/0xb0
>  [<c012480d>] do_softirq+0x2d/0x30
>  [<c01248e7>] irq_exit+0x37/0x40
>  [<c0105f78>] do_IRQ+0x28/0x40
>  [<c0103f16>] common_interrupt+0x1a/0x20
>  [<c039f360>] schedule+0x0/0x650
>  [<c039fa63>] preempt_schedule_irq+0x43/0x80
>  [<c010349e>] need_resched+0x1f/0x21
>  [<c013ee20>] swsusp_suspend+0x50/0xc0
>  [<c013faac>] pm_suspend_disk+0x3c/0x90
>  [<c013d86c>] enter_state+0x6c/0x70
>  [<c013d87f>] software_suspend+0xf/0x20
>  [<c0247322>] acpi_system_write_sleep+0x6a/0x84
>  [<c0162716>] vfs_write+0xb6/0x180
>  [<c01628b1>] sys_write+0x51/0x80
>  [<c0103559>] syscall_call+0x7/0xb
> handlers:
> [<dc86e850>] (snd_intel8x0_interrupt+0x0/0x240 [snd_intel8x0])
> Disabling IRQ #10
> 
> ...and then
> 
> ohci_hcd 0000:00:02.3: Unlink after no-IRQ?  Controller is probably
> using the wrong IRQ.

Okay, can you enable debugging in .../usb/core/hcd-pci.c and see what
happens? It seems to call request_irq in resume routine, add printk to
verify that it really does call it.

Oh and probably Cc: some usb list, or David Brownell directly.

								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: More experiences with 2.6.13-rc3 with ec_polling patch

[Pavel Troller]

> Hi!
> 
> > 5) After resume from S4:
> > 
> > irq 10: nobody cared (try booting with the "irqpoll" option)
> >  [<c01412aa>] __report_bad_irq+0x2a/0xa0
> >  [<c0140a50>] handle_IRQ_event+0x30/0x70
> >  [<c01413c0>] note_interrupt+0x80/0xf0
> >  [<c0140bc4>] __do_IRQ+0x134/0x140
> >  [<c0105f73>] do_IRQ+0x23/0x40
> >  [<c0103f16>] common_interrupt+0x1a/0x20
> >  [<c0124773>] __do_softirq+0x43/0xb0
> >  [<c012480d>] do_softirq+0x2d/0x30
> >  [<c01248e7>] irq_exit+0x37/0x40
> >  [<c0105f78>] do_IRQ+0x28/0x40
> >  [<c0103f16>] common_interrupt+0x1a/0x20
> >  [<c039f360>] schedule+0x0/0x650
> >  [<c039fa63>] preempt_schedule_irq+0x43/0x80
> >  [<c010349e>] need_resched+0x1f/0x21
> >  [<c013ee20>] swsusp_suspend+0x50/0xc0
> >  [<c013faac>] pm_suspend_disk+0x3c/0x90
> >  [<c013d86c>] enter_state+0x6c/0x70
> >  [<c013d87f>] software_suspend+0xf/0x20
> >  [<c0247322>] acpi_system_write_sleep+0x6a/0x84
> >  [<c0162716>] vfs_write+0xb6/0x180
> >  [<c01628b1>] sys_write+0x51/0x80
> >  [<c0103559>] syscall_call+0x7/0xb
> > handlers:
> > [<dc86e850>] (snd_intel8x0_interrupt+0x0/0x240 [snd_intel8x0])
> > Disabling IRQ #10
> > 
> > ...and then
> > 
> > ohci_hcd 0000:00:02.3: Unlink after no-IRQ?  Controller is probably
> > using the wrong IRQ.
> 
> Okay, can you enable debugging in .../usb/core/hcd-pci.c and see what
> happens? It seems to call request_irq in resume routine, add printk to
> verify that it really does call it.
> 
Hi Pavel,
  I'm afraid that You're not getting the exact point:
  1) Before S4 is called (4 written to /proc/acpi/sleep), ohci_hcd module is
fully unloaded.
  2) The problem with "nobody cared" is detected during the wake up phase,
even before the suspend/resume script wakes up and tries to reinsert the
module. You can see that just the sound card handler is hooked to the irq.
  3) After a relatively long time (during which the resume script is awaken
and starts to insert various modules (mouse, modem, irda, bluetooth... which
were unloaded during suspend to prevent problems), this ohci_hcd tries to
be inserted, finds the non-functional interrupt and makes problems. Maybe
there is a bug in it, but it is triggered by another problem with that irq,
happening just in -rc3.
  Sorry that my initial explanation wasn't clear enough.
                                      Regards, Pavel Troller


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: More experiences with 2.6.13-rc3 with ec_polling patch

[Rafael J. Wysocki]

Hi,

The problem you describe is not related to the ec_polling patch (see below).

On Monday, 25 of July 2005 10:40, Pavel Troller wrote:
> > Hi!
> > 
> > > 5) After resume from S4:
> > > 
]--snip--[
> > > Disabling IRQ #10
> > > 
> > > ...and then
> > > 
> > > ohci_hcd 0000:00:02.3: Unlink after no-IRQ?  Controller is probably
> > > using the wrong IRQ.
> > 
> > Okay, can you enable debugging in .../usb/core/hcd-pci.c and see what
> > happens? It seems to call request_irq in resume routine, add printk to
> > verify that it really does call it.
> > 
> Hi Pavel,
>   I'm afraid that You're not getting the exact point:
>   1) Before S4 is called (4 written to /proc/acpi/sleep), ohci_hcd module is
> fully unloaded.
>   2) The problem with "nobody cared" is detected during the wake up phase,
> even before the suspend/resume script wakes up and tries to reinsert the
> module. You can see that just the sound card handler is hooked to the irq.
>   3) After a relatively long time (during which the resume script is awaken
> and starts to insert various modules (mouse, modem, irda, bluetooth... which
> were unloaded during suspend to prevent problems), this ohci_hcd tries to
> be inserted, finds the non-functional interrupt and makes problems. Maybe
> there is a bug in it, but it is triggered by another problem with that irq,
> happening just in -rc3.

This happens because the sound card should drop the IRQ during
suspend but it doesn't.  Please try to apply the patch at

http://bugzilla.kernel.org/attachment.cgi?id=5371&action=view

and let me know if that helps.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: More experiences with 2.6.13-rc3 with ec_polling patch

[Pavel Troller]

> Hi,
> 
> The problem you describe is not related to the ec_polling patch (see below).
I know. Sorry for bad formulation of the subject, I simply wanted to tell
"more experiences with -rc3 after fixing that one with EC :-)".
> 
> 
> This happens because the sound card should drop the IRQ during
> suspend but it doesn't.  Please try to apply the patch at
> 
> http://bugzilla.kernel.org/attachment.cgi?id=5371&action=view
> 
> and let me know if that helps.
It seems to help just a little:
1) The "Nobody cared" message with the backtrace is still there the same
2) ohci-hcd no more complains about wrong IRQ and inserts/removes OK
... but nevertheless, neither soundcard now USB is working.
Of course I verified that the patch is there in the i8x0 code.
> 
> Greets,
> Rafael
> 
                      With regards, Pavel Troller


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: More experiences with 2.6.13-rc3 with ec_polling patch

[Rafael J. Wysocki]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On Monday, 25 of July 2005 17:26, Pavel Troller wrote:
> > Hi,
> > 
> > The problem you describe is not related to the ec_polling patch (see below).
> I know. Sorry for bad formulation of the subject, I simply wanted to tell
> "more experiences with -rc3 after fixing that one with EC :-)".
> > 
> > 
> > This happens because the sound card should drop the IRQ during
> > suspend but it doesn't.  Please try to apply the patch at
> > 
> > http://bugzilla.kernel.org/attachment.cgi?id=5371&action=view
> > 
> > and let me know if that helps.
> It seems to help just a little:
> 1) The "Nobody cared" message with the backtrace is still there the same

Is the message:

handlers:
[<dc86e850>] (snd_intel8x0_interrupt+0x0/0x240 [snd_intel8x0])

still present in the backtrace with the patch?

> 2) ohci-hcd no more complains about wrong IRQ and inserts/removes OK
> .. but nevertheless, neither soundcard now USB is working.

That would mean the patch is needed anyway ...

> Of course I verified that the patch is there in the i8x0 code.

Can you please use the attached patch instead and put printk()s right before
free_irq() in intel8x0_suspend() and request_irq() in intel8x0_resume(),
and retest?

Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

[-- Attachment #2: 2.6.13-rc3-git5-intel8x0-suspend_resume.patch --]
[-- Type: text/x-diff, Size: 923 bytes --]

--- linux-2.6.13-rc3-git5/sound/pci/intel8x0.c	2005-07-23 19:26:43.000000000 +0200
+++ patched/sound/pci/intel8x0.c	2005-07-25 18:21:36.000000000 +0200
@@ -2373,6 +2373,8 @@ static int intel8x0_suspend(snd_card_t *
 	for (i = 0; i < 3; i++)
 		if (chip->ac97[i])
 			snd_ac97_suspend(chip->ac97[i]);
+	if (chip->irq >= 0)
+		free_irq(chip->irq, (void *)chip);
 	pci_disable_device(chip->pci);
 	return 0;
 }
@@ -2384,7 +2386,14 @@ static int intel8x0_resume(snd_card_t *c
 
 	pci_enable_device(chip->pci);
 	pci_set_master(chip->pci);
-	snd_intel8x0_chip_init(chip, 0);
+	if (request_irq(chip->irq, snd_intel8x0_interrupt, SA_INTERRUPT|SA_SHIRQ, card->shortname, (void *)chip)) {
+		snd_printk("unable to grab IRQ %d\n", chip->irq);
+		chip->irq = -1;
+		pci_disable_device(chip->pci);
+		return -EBUSY;
+	}
+	synchronize_irq(chip->irq);
+	snd_intel8x0_chip_init(chip, 1);
 
 	/* refill nocache */
 	if (chip->fix_nocache)

Re: More experiences with 2.6.13-rc3 with ec_polling patch

[Pavel Troller]

Hi Rafael!
> handlers:
> [<dc86e850>] (snd_intel8x0_interrupt+0x0/0x240 [snd_intel8x0])
> 
> still present in the backtrace with the patch?
Yes, it was there, but I know why :-), the actual code was patched but it was
not running, due to the fact that I have about 4 testing kernel trees, 
something went wrong during modules_install and the old, non-patched sound
module was used. It works with the modified patch as well as with the original
one. I feel like an idiot, sorry for this :-).
> 
 So the interrupt part of -rc3 problems seems to be fixed for me too :-).
          With many thanks,
	               Pavel Troller


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: More experiences with 2.6.13-rc3 with ec_polling patch

[Rafael J. Wysocki]

On Monday, 25 of July 2005 20:48, Pavel Troller wrote:
> Hi Rafael!
> > handlers:
> > [<dc86e850>] (snd_intel8x0_interrupt+0x0/0x240 [snd_intel8x0])
> > 
> > still present in the backtrace with the patch?
> Yes, it was there, but I know why :-), the actual code was patched but it was
> not running, due to the fact that I have about 4 testing kernel trees, 
> something went wrong during modules_install and the old, non-patched sound
> module was used. It works with the modified patch as well as with the original
> one. I feel like an idiot, sorry for this :-).
> > 
>  So the interrupt part of -rc3 problems seems to be fixed for me too :-).

Great.

BTW, can you please send me the output of dmesg from your machine?

Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click