swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Jiri Slaby]

Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/

Hello,

I have problems with swsusp again. While suspending, the very last thing kernel
writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
Here is a snapshot of the screen:
http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif

It's SMP system (HT), higmem enabled (1 gig of ram).

regards,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Rafael J. Wysocki]

Hi,

On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> 
> Hello,
> 
> I have problems with swsusp again. While suspending, the very last thing kernel
> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> Here is a snapshot of the screen:
> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> 
> It's SMP system (HT), higmem enabled (1 gig of ram).

Most probably it hangs in device_power_up(), so the problem seems to be
with one of the devices that are resumed with IRQs off.

Does vanila .18-rc2 work?

Rafael

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Jiri Slaby]

Rafael J. Wysocki napsal(a):
> Hi,
> 
> On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
>> Andrew Morton napsal(a):
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>> Hello,
>>
>> I have problems with swsusp again. While suspending, the very last thing kernel
>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>> Here is a snapshot of the screen:
>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>
>> It's SMP system (HT), higmem enabled (1 gig of ram).
> 
> Most probably it hangs in device_power_up(), so the problem seems to be
> with one of the devices that are resumed with IRQs off.
> 
> Does vanila .18-rc2 work?

Yup, it does.

regards,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Rafael J. Wysocki]

On Sunday 30 July 2006 01:06, Jiri Slaby wrote:
> Rafael J. Wysocki napsal(a):
> > Hi,
> > 
> > On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
> >> Andrew Morton napsal(a):
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
> >> Hello,
> >>
> >> I have problems with swsusp again. While suspending, the very last thing kernel
> >> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >> Here is a snapshot of the screen:
> >> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>
> >> It's SMP system (HT), higmem enabled (1 gig of ram).
> > 
> > Most probably it hangs in device_power_up(), so the problem seems to be
> > with one of the devices that are resumed with IRQs off.
> > 
> > Does vanila .18-rc2 work?
> 
> Yup, it does.

Hm, in fact this may be a problem with any device driver.

Could you please boot the system with init=/bin/bash and try to suspend?

Rafael

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Jiri Slaby]

Rafael J. Wysocki napsal(a):
> On Sunday 30 July 2006 01:06, Jiri Slaby wrote:
>> Rafael J. Wysocki napsal(a):
>>> Hi,
>>>
>>> On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
>>>> Andrew Morton napsal(a):
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>>>> Hello,
>>>>
>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>> Here is a snapshot of the screen:
>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>
>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>> with one of the devices that are resumed with IRQs off.
>>>
>>> Does vanila .18-rc2 work?
>> Yup, it does.
> 
> Hm, in fact this may be a problem with any device driver.
> 
> Could you please boot the system with init=/bin/bash and try to suspend?

No change.

regards,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Jiri Slaby]

Rafael J. Wysocki napsal(a):
> On Sunday 30 July 2006 01:06, Jiri Slaby wrote:
>> Rafael J. Wysocki napsal(a):
>>> Hi,
>>>
>>> On Saturday 29 July 2006 19:58, Jiri Slaby wrote:
>>>> Andrew Morton napsal(a):
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/
>>>> Hello,
>>>>
>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>> Here is a snapshot of the screen:
>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>
>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>> with one of the devices that are resumed with IRQs off.
>>>
>>> Does vanila .18-rc2 work?
>> Yup, it does.
> 
> Hm, in fact this may be a problem with any device driver.

Note 1: 2.6.18-rc1-mm2 was(is) working just fine.
Note 2: when I was going through these -mm diff, the culprit may be radeon
driver -- there are some PM changes... Or if you want to go on your own, here is
lspci output:
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub
Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
(rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon
9000] (rev 01)
01:00.1 Display controller: ATI Technologies Inc Radeon RV250 [Radeon 9000]
(Secondary) (rev 01)
02:02.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
02:02.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a)
02:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000
Controller (PHY/Link)
02:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet
Controller (rev 02)

with -n:
00:00.0 0600: 8086:2570 (rev 02)
00:01.0 0604: 8086:2571 (rev 02)
00:1d.0 0c03: 8086:24d2 (rev 02)
00:1d.1 0c03: 8086:24d4 (rev 02)
00:1d.2 0c03: 8086:24d7 (rev 02)
00:1d.3 0c03: 8086:24de (rev 02)
00:1d.7 0c03: 8086:24dd (rev 02)
00:1e.0 0604: 8086:244e (rev c2)
00:1f.0 0601: 8086:24d0 (rev 02)
00:1f.1 0101: 8086:24db (rev 02)
00:1f.2 0101: 8086:24d1 (rev 02)
00:1f.3 0c05: 8086:24d3 (rev 02)
01:00.0 0300: 1002:4966 (rev 01)
01:00.1 0380: 1002:496e (rev 01)
02:02.0 0401: 1102:0002 (rev 0a)
02:02.1 0980: 1102:7002 (rev 0a)
02:05.0 0c00: 104c:8024
02:08.0 0200: 8086:1050 (rev 02)

regards,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Pavel Machek]

Hi!

> >> I have problems with swsusp again. While suspending, the very last thing kernel
> >> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >> Here is a snapshot of the screen:
> >> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>
> >> It's SMP system (HT), higmem enabled (1 gig of ram).
> > 
> > Most probably it hangs in device_power_up(), so the problem seems to be
> > with one of the devices that are resumed with IRQs off.
> > 
> > Does vanila .18-rc2 work?
> 
> Yup, it does.

Can you try up kernel, no highmem? (mem=512M)?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Jiri Slaby]

Pavel Machek napsal(a):
> Hi!
> 
>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>> Here is a snapshot of the screen:
>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>
>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>> with one of the devices that are resumed with IRQs off.
>>>
>>> Does vanila .18-rc2 work?
>> Yup, it does.
> 
> Can you try up kernel, no highmem? (mem=512M)?

It writes then:
p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
in endless loop when resuming -- after reading from swap.

regards,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Pavel Machek]

Hi!

> >>>> I have problems with swsusp again. While suspending, the very last thing kernel
> >>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >>>> Here is a snapshot of the screen:
> >>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>>>
> >>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> >>> Most probably it hangs in device_power_up(), so the problem seems to be
> >>> with one of the devices that are resumed with IRQs off.
> >>>
> >>> Does vanila .18-rc2 work?
> >> Yup, it does.
> > 
> > Can you try up kernel, no highmem? (mem=512M)?
> 
> It writes then:
> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> in endless loop when resuming -- after reading from swap.

Okay, so we have two different problems here.

One is "hang during suspend" with smp/highmem mode, and one is
probably driver problem with p16v (whatever it is).

/data/l/linux/sound/pci/emu10k1/irq.c:
snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
use=%d\n", status2, mask, pvoice, pvoice->use);

...aha, so you may want to unload emu10k1 for testing.

Since you mention radeon in one of your other mails, just try it in
vesafb mode...
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Rafael J. Wysocki]

On Sunday 30 July 2006 02:06, Pavel Machek wrote:
> Hi!
> 
> > >>>> I have problems with swsusp again. While suspending, the very last thing kernel
> > >>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> > >>>> Here is a snapshot of the screen:
> > >>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> > >>>>
> > >>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> > >>> Most probably it hangs in device_power_up(), so the problem seems to be
> > >>> with one of the devices that are resumed with IRQs off.
> > >>>
> > >>> Does vanila .18-rc2 work?
> > >> Yup, it does.
> > > 
> > > Can you try up kernel, no highmem? (mem=512M)?
> > 
> > It writes then:
> > p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> > in endless loop when resuming -- after reading from swap.
> 
> Okay, so we have two different problems here.
> 
> One is "hang during suspend" with smp/highmem mode,

That one is "interesting".  I've no idea why the restoration of highmem would
have caused the box to hang like that.  Jiri, could you please post the output
of dmesg after a fresh boot?

> and one is probably driver problem with p16v (whatever it is).
> 
> /data/l/linux/sound/pci/emu10k1/irq.c:
> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
> use=%d\n", status2, mask, pvoice, pvoice->use);
> 
> ...aha, so you may want to unload emu10k1 for testing.
> 
> Since you mention radeon in one of your other mails, just try it in
> vesafb mode...

Yes.  Or just don't compile the radeon driver and see what happens.

Rafael

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Jiri Slaby]

Rafael J. Wysocki napsal(a):
> On Sunday 30 July 2006 02:06, Pavel Machek wrote:
>> Hi!
>>
>>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>>>>> Here is a snapshot of the screen:
>>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>>>>
>>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>>>>> with one of the devices that are resumed with IRQs off.
>>>>>>
>>>>>> Does vanila .18-rc2 work?
>>>>> Yup, it does.
>>>> Can you try up kernel, no highmem? (mem=512M)?
>>> It writes then:
>>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
>>> in endless loop when resuming -- after reading from swap.
>> Okay, so we have two different problems here.
>>
>> One is "hang during suspend" with smp/highmem mode,
> 
> That one is "interesting".  I've no idea why the restoration of highmem would
> have caused the box to hang like that.  Jiri, could you please post the output
> of dmesg after a fresh boot?

higmem is ok. ioapic0 is the culprit -- its class resume dies:
        if (cls->resume)
                cls->resume(dev); <----
in __sysdev_resume

>> and one is probably driver problem with p16v (whatever it is).
>>
>> /data/l/linux/sound/pci/emu10k1/irq.c:
>> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
>> use=%d\n", status2, mask, pvoice, pvoice->use);
>>
>> ...aha, so you may want to unload emu10k1 for testing.

Sure, this helped.

>> Since you mention radeon in one of your other mails, just try it in
>> vesafb mode...
> 
> Yes.  Or just don't compile the radeon driver and see what happens.

Doesn't matter. I do not use graphics (fb) in console -- radeon was not inited
at all, it was bad tip.

regards,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Rafael J. Wysocki]

On Sunday 30 July 2006 10:08, Jiri Slaby wrote:
> Rafael J. Wysocki napsal(a):
> > On Sunday 30 July 2006 02:06, Pavel Machek wrote:
> >> Hi!
> >>
> >>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
> >>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >>>>>>> Here is a snapshot of the screen:
> >>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>>>>>>
> >>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> >>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
> >>>>>> with one of the devices that are resumed with IRQs off.
> >>>>>>
> >>>>>> Does vanila .18-rc2 work?
> >>>>> Yup, it does.
> >>>> Can you try up kernel, no highmem? (mem=512M)?
> >>> It writes then:
> >>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> >>> in endless loop when resuming -- after reading from swap.
> >> Okay, so we have two different problems here.
> >>
> >> One is "hang during suspend" with smp/highmem mode,
> > 
> > That one is "interesting".  I've no idea why the restoration of highmem would
> > have caused the box to hang like that.  Jiri, could you please post the output
> > of dmesg after a fresh boot?
> 
> higmem is ok. ioapic0 is the culprit -- its class resume dies:
>         if (cls->resume)
>                 cls->resume(dev); <----
> in __sysdev_resume

Ah, so my first guess was actually correct. :-)

> >> and one is probably driver problem with p16v (whatever it is).
> >>
> >> /data/l/linux/sound/pci/emu10k1/irq.c:
> >> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
> >> use=%d\n", status2, mask, pvoice, pvoice->use);
> >>
> >> ...aha, so you may want to unload emu10k1 for testing.
> 
> Sure, this helped.

So, we have two different regressions here.

Please try to revert git-alsa.patch and see if the emu10k1-related problem
goes away.

As far as the first one is concerned, the genirq-* patches look suspicious.

Greetings,
Rafael

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Jiri Slaby]

Uncc: linux-mm
Cc: alsa-devel
Cc: mingo

Rafael J. Wysocki wrote:
> On Sunday 30 July 2006 10:08, Jiri Slaby wrote:
>> Rafael J. Wysocki napsal(a):
>>> On Sunday 30 July 2006 02:06, Pavel Machek wrote:
>>>> Hi!
>>>>
>>>>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>>>>>>> Here is a snapshot of the screen:
>>>>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>>>>>>
>>>>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>>>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>>>>>>> with one of the devices that are resumed with IRQs off.
>>>>>>>>
>>>>>>>> Does vanila .18-rc2 work?
>>>>>>> Yup, it does.
>>>>>> Can you try up kernel, no highmem? (mem=512M)?
>>>>> It writes then:
>>>>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
>>>>> in endless loop when resuming -- after reading from swap.
>>>> Okay, so we have two different problems here.

[snip]

>>>> and one is probably driver problem with p16v (whatever it is).
>>>>
>>>> /data/l/linux/sound/pci/emu10k1/irq.c:
>>>> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
>>>> use=%d\n", status2, mask, pvoice, pvoice->use);
>>>>
>>>> ...aha, so you may want to unload emu10k1 for testing.
>> Sure, this helped.
> 
> So, we have two different regressions here.
> 
> Please try to revert git-alsa.patch and see if the emu10k1-related problem
> goes away.

Wow, it didn't helped, I find out there is a difference between in-kernel and 
modules version of the driver. When compiled as modules (loaded/unloaded) 
suspending (and resuming) is working ok (enabled higmem and preempt back -- 
still no smp), when compiled in-kernel (see the config diff below), it doesn't 
resume.
@@ -1263,8 +1263,8 @@
  CONFIG_SND=y
  CONFIG_SND_TIMER=y
  CONFIG_SND_PCM=y
-CONFIG_SND_HWDEP=m
-CONFIG_SND_RAWMIDI=m
+CONFIG_SND_HWDEP=y
+CONFIG_SND_RAWMIDI=y
  CONFIG_SND_SEQUENCER=y
  # CONFIG_SND_SEQ_DUMMY is not set
  CONFIG_SND_OSSEMUL=y
@@ -1282,8 +1282,8 @@
  #
  # Generic devices
  #
-CONFIG_SND_AC97_CODEC=m
-CONFIG_SND_AC97_BUS=m
+CONFIG_SND_AC97_CODEC=y
+CONFIG_SND_AC97_BUS=y
  # CONFIG_SND_DUMMY is not set
  # CONFIG_SND_VIRMIDI is not set
  # CONFIG_SND_MTPAV is not set
@@ -1347,7 +1347,7 @@
  # CONFIG_SND_INDIGO is not set
  # CONFIG_SND_INDIGOIO is not set
  # CONFIG_SND_INDIGODJ is not set
-CONFIG_SND_EMU10K1=m
+CONFIG_SND_EMU10K1=y
  # CONFIG_SND_EMU10K1X is not set
  # CONFIG_SND_ENS1370 is not set
  # CONFIG_SND_ENS1371 is not set


> As far as the first one is concerned, the genirq-* patches look suspicious.

Hmm, what to do?

regards,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Pavel Machek]

Hi!

> >Please try to revert git-alsa.patch and see if the emu10k1-related problem
> >goes away.
> 
> Wow, it didn't helped, I find out there is a difference between in-kernel 
> and modules version of the driver. When compiled as modules 
> (loaded/unloaded) suspending (and resuming) is working ok (enabled higmem 
> and preempt back -- still no smp), when compiled in-kernel (see the config 
> diff below), it doesn't resume.

Yes, that sometimes happens. You could work around it by catching
PM_EVENT_PRETHAW message and resetting the hardware in this case. Or
just fix the resume routine.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Rafael J. Wysocki]

On Sunday 30 July 2006 12:54, Jiri Slaby wrote:
> Uncc: linux-mm
> Cc: alsa-devel
> Cc: mingo
> 
> Rafael J. Wysocki wrote:
> > On Sunday 30 July 2006 10:08, Jiri Slaby wrote:
> >> Rafael J. Wysocki napsal(a):
> >>> On Sunday 30 July 2006 02:06, Pavel Machek wrote:
> >>>> Hi!
> >>>>
> >>>>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
> >>>>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> >>>>>>>>> Here is a snapshot of the screen:
> >>>>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> >>>>>>>>>
> >>>>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> >>>>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
> >>>>>>>> with one of the devices that are resumed with IRQs off.
> >>>>>>>>
> >>>>>>>> Does vanila .18-rc2 work?
> >>>>>>> Yup, it does.
> >>>>>> Can you try up kernel, no highmem? (mem=512M)?
> >>>>> It writes then:
> >>>>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> >>>>> in endless loop when resuming -- after reading from swap.
> >>>> Okay, so we have two different problems here.
> 
> [snip]
> 
> >>>> and one is probably driver problem with p16v (whatever it is).
> >>>>
> >>>> /data/l/linux/sound/pci/emu10k1/irq.c:
> >>>> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
> >>>> use=%d\n", status2, mask, pvoice, pvoice->use);
> >>>>
> >>>> ...aha, so you may want to unload emu10k1 for testing.
> >> Sure, this helped.
> > 
> > So, we have two different regressions here.
> > 
> > Please try to revert git-alsa.patch and see if the emu10k1-related problem
> > goes away.
> 
> Wow, it didn't helped, I find out there is a difference between in-kernel and 
> modules version of the driver. When compiled as modules (loaded/unloaded) 
> suspending (and resuming) is working ok (enabled higmem and preempt back -- 
> still no smp), when compiled in-kernel (see the config diff below), it doesn't 
> resume.
> @@ -1263,8 +1263,8 @@
>   CONFIG_SND=y
>   CONFIG_SND_TIMER=y
>   CONFIG_SND_PCM=y
> -CONFIG_SND_HWDEP=m
> -CONFIG_SND_RAWMIDI=m
> +CONFIG_SND_HWDEP=y
> +CONFIG_SND_RAWMIDI=y
>   CONFIG_SND_SEQUENCER=y
>   # CONFIG_SND_SEQ_DUMMY is not set
>   CONFIG_SND_OSSEMUL=y
> @@ -1282,8 +1282,8 @@
>   #
>   # Generic devices
>   #
> -CONFIG_SND_AC97_CODEC=m
> -CONFIG_SND_AC97_BUS=m
> +CONFIG_SND_AC97_CODEC=y
> +CONFIG_SND_AC97_BUS=y
>   # CONFIG_SND_DUMMY is not set
>   # CONFIG_SND_VIRMIDI is not set
>   # CONFIG_SND_MTPAV is not set
> @@ -1347,7 +1347,7 @@
>   # CONFIG_SND_INDIGO is not set
>   # CONFIG_SND_INDIGOIO is not set
>   # CONFIG_SND_INDIGODJ is not set
> -CONFIG_SND_EMU10K1=m
> +CONFIG_SND_EMU10K1=y
>   # CONFIG_SND_EMU10K1X is not set
>   # CONFIG_SND_ENS1370 is not set
>   # CONFIG_SND_ENS1371 is not set

If the driver is compiled in, its .suspend() routine gets called before the
suspend image is restored and puts the card in a state that confuses
the .resume() called after the image has been restored.

I think snd_emu10k1_suspend() should reset the device if state == PMSG_PRETHAW .

> > As far as the first one is concerned, the genirq-* patches look suspicious.
> 
> Hmm, what to do?

I would try to revert them altogether and see what happens.  If that doesn't
help, the only thing that comes to mind is to carry out a binary search for
the offending patch. :-(

Greetings,
Rafael

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Takashi Iwai]

At Sun, 30 Jul 2006 13:34:38 +0200,
Rafael J. Wysocki wrote:
> 
> On Sunday 30 July 2006 12:54, Jiri Slaby wrote:
> > Uncc: linux-mm
> > Cc: alsa-devel
> > Cc: mingo
> > 
> > Rafael J. Wysocki wrote:
> > > On Sunday 30 July 2006 10:08, Jiri Slaby wrote:
> > >> Rafael J. Wysocki napsal(a):
> > >>> On Sunday 30 July 2006 02:06, Pavel Machek wrote:
> > >>>> Hi!
> > >>>>
> > >>>>>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
> > >>>>>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
> > >>>>>>>>> Here is a snapshot of the screen:
> > >>>>>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
> > >>>>>>>>>
> > >>>>>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
> > >>>>>>>> Most probably it hangs in device_power_up(), so the problem seems to be
> > >>>>>>>> with one of the devices that are resumed with IRQs off.
> > >>>>>>>>
> > >>>>>>>> Does vanila .18-rc2 work?
> > >>>>>>> Yup, it does.
> > >>>>>> Can you try up kernel, no highmem? (mem=512M)?
> > >>>>> It writes then:
> > >>>>> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> > >>>>> in endless loop when resuming -- after reading from swap.
> > >>>> Okay, so we have two different problems here.
> > 
> > [snip]
> > 
> > >>>> and one is probably driver problem with p16v (whatever it is).
> > >>>>
> > >>>> /data/l/linux/sound/pci/emu10k1/irq.c:
> > >>>> snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p,
> > >>>> use=%d\n", status2, mask, pvoice, pvoice->use);
> > >>>>
> > >>>> ...aha, so you may want to unload emu10k1 for testing.
> > >> Sure, this helped.
> > > 
> > > So, we have two different regressions here.
> > > 
> > > Please try to revert git-alsa.patch and see if the emu10k1-related problem
> > > goes away.
> > 
> > Wow, it didn't helped, I find out there is a difference between in-kernel and 
> > modules version of the driver. When compiled as modules (loaded/unloaded) 
> > suspending (and resuming) is working ok (enabled higmem and preempt back -- 
> > still no smp), when compiled in-kernel (see the config diff below), it doesn't 
> > resume.
> > @@ -1263,8 +1263,8 @@
> >   CONFIG_SND=y
> >   CONFIG_SND_TIMER=y
> >   CONFIG_SND_PCM=y
> > -CONFIG_SND_HWDEP=m
> > -CONFIG_SND_RAWMIDI=m
> > +CONFIG_SND_HWDEP=y
> > +CONFIG_SND_RAWMIDI=y
> >   CONFIG_SND_SEQUENCER=y
> >   # CONFIG_SND_SEQ_DUMMY is not set
> >   CONFIG_SND_OSSEMUL=y
> > @@ -1282,8 +1282,8 @@
> >   #
> >   # Generic devices
> >   #
> > -CONFIG_SND_AC97_CODEC=m
> > -CONFIG_SND_AC97_BUS=m
> > +CONFIG_SND_AC97_CODEC=y
> > +CONFIG_SND_AC97_BUS=y
> >   # CONFIG_SND_DUMMY is not set
> >   # CONFIG_SND_VIRMIDI is not set
> >   # CONFIG_SND_MTPAV is not set
> > @@ -1347,7 +1347,7 @@
> >   # CONFIG_SND_INDIGO is not set
> >   # CONFIG_SND_INDIGOIO is not set
> >   # CONFIG_SND_INDIGODJ is not set
> > -CONFIG_SND_EMU10K1=m
> > +CONFIG_SND_EMU10K1=y
> >   # CONFIG_SND_EMU10K1X is not set
> >   # CONFIG_SND_ENS1370 is not set
> >   # CONFIG_SND_ENS1371 is not set
> 
> If the driver is compiled in, its .suspend() routine gets called before the
> suspend image is restored and puts the card in a state that confuses
> the .resume() called after the image has been restored.
> 
> I think snd_emu10k1_suspend() should reset the device if state == PMSG_PRETHAW .

Hm, do we need such inconsitent behavior?  I mean, for most drivers,
it doesn't matter whether it's built-in or a module: simply shutdown
at suspend, and initialize at resume.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Alsa-devel] swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[Pavel Machek]

Hi!

> > If the driver is compiled in, its .suspend() routine gets called before the
> > suspend image is restored and puts the card in a state that confuses
> > the .resume() called after the image has been restored.
> > 
> > I think snd_emu10k1_suspend() should reset the device if state == PMSG_PRETHAW .
> 
> Hm, do we need such inconsitent behavior?  I mean, for most drivers,
> it doesn't matter whether it's built-in or a module: simply shutdown
> at suspend, and initialize at resume.

That's of course the other (and better) solution.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

[James Courtier-Dutton]

Jiri Slaby wrote:
> Pavel Machek napsal(a):
>> Hi!
>>
>>>>> I have problems with swsusp again. While suspending, the very last thing kernel
>>>>> writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all.
>>>>> Here is a snapshot of the screen:
>>>>> http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif
>>>>>
>>>>> It's SMP system (HT), higmem enabled (1 gig of ram).
>>>> Most probably it hangs in device_power_up(), so the problem seems to be
>>>> with one of the devices that are resumed with IRQs off.
>>>>
>>>> Does vanila .18-rc2 work?
>>> Yup, it does.
>> Can you try up kernel, no highmem? (mem=512M)?
> 
> It writes then:
> p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0
> in endless loop when resuming -- after reading from swap.
> 
> regards,

The p16v chip is present on some creative sound cards, so this is an
ALSA snd-emu10k1 driver that is causing the endless loop. I will change
the code to force it to recover from the unexpected status 0xffffffff
value. The recovery will just consist of reducing the message to a
single message, instead of an endless loop. That value is never present
during normal operations, and the only case of it occurring that I know
about was during a pcmcia card unplug. If it occurs during insertion or
power resume, then I will have to think about some work around.
Is there any reason that an IRQ routine will be called before the
associated PCI IOPORTs have been configured. I did not think it was the
responsibility of the driver to redo all the initialisation PCI calls to
claim DMA and IOPORTs at power resume. To me it seems that the IRQ
routine is being called before PCI DMA and IOPORTs have been initialised.

James