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>] [day] [month] [year] [list]
Message-id: <io_apic_has_to_be_repaired@huhuhu_blaahrepost>
Date:	Mon, 31 Jul 2006 19:31:03 -0400
From:	Jiri Slaby <jirislaby@...il.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	mingo@...hat.com
Subject: [PATCH -repost] io_apic fix spinlock in resume [Was: Re: swsusp regression (s2dsk) [Was: 2.6.18-rc2-mm1]]

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

io_apic fix spinlock in resume

In io_apic class resume after Andi's cleanup was wiped out one unlock of
spinlock. Get him back to allow suspending (and resuming) of machine.

Cc: Andi Kleen <ak@...e.de>
Signed-off-by: Jiri Slaby <jirislaby@...il.com>

---
commit 2d82ba5b564500cb29613ee9c24b1d0efa829518
tree 64551b2f45e6ffd3f220af85f25dae2199897652
parent 8e013921e94b248b33880b58b46e5eba4a931b51
author Jiri Slaby <ku@...lona.localdomain> Tue, 01 Aug 2006 01:16:13 +0159
committer Jiri Slaby <ku@...lona.localdomain> Tue, 01 Aug 2006 01:16:13 +0159

 arch/i386/kernel/io_apic.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index fa0eb9f..617037a 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -2360,6 +2360,7 @@ static int ioapic_resume(struct sys_devi
 		reg_00.bits.ID = mp_ioapics[dev->id].mpc_apicid;
 		io_apic_write(dev->id, 0, reg_00.raw);
 	}
+	spin_unlock_irqrestore(&ioapic_lock, flags);
 	for (i = 0; i < nr_ioapic_registers[dev->id]; i ++)
 		ioapic_write_entry(dev->id, i, entry[i]);
 
-
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