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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux