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

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]

Date:	Sun, 30 Jul 2006 12:36:33 +0100
From:	James Courtier-Dutton <James@...erbug.co.uk>
To:	Jiri Slaby <jirislaby@...il.com>
CC:	Pavel Machek <pavel@....cz>, "Rafael J. Wysocki" <rjw@...k.pl>,
	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]

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

-
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/