lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200607301128.04395.rjw@sisk.pl>
Date:	Sun, 30 Jul 2006 11:28:04 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	Pavel Machek <pavel@....cz>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org, linux-pm@...l.org, linux-mm@...ck.org
Subject: Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ