Bug 9544
Summary: | Kernel oops in swsusp_save on suspend (IOMMU-related) | ||
---|---|---|---|
Product: | Power Management | Reporter: | Alexandre Julliard (julliard) |
Component: | Hibernation/Suspend | Assignee: | Rafael J. Wysocki (rjwysocki) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | acpi-bugzilla, akpm, andi-bz, lenb, mingo, nigel, rjw, tglx |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.23.8 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 7216 | ||
Attachments: | dmesg output |
Description
Alexandre Julliard
2007-12-11 05:30:33 UTC
So you haven't tested any kernel earlier than 2.6.23? Yes, a copy of the oops would be great, please. You shouldn't need to write it down - try netconsole (Documentation/networking/netconsole.txt). It's worth setting up netconsole... netconsole won't work at that point (devices suspended, interrupts disabled). Serial console might be useful, though, but I doubt that box has a serial port. I guess the problem is present in all kernels to date. Alexandre, can you attach a dmesg output, please? Created attachment 13982 [details]
dmesg output
dmesg output attached.
I haven't tried other kernels, if that would be useful I could do it, any version you want me to try?
The box does have a serial port but I don't have anything to plug into it I'm afraid.
> netconsole won't work at that point (devices suspended, interrupts
> disabled). Serial console might be useful, though, but I doubt that
> box has a serial port.
>
> I guess the problem is present in all kernels to date.
at least as long as netconsole output going _into_ suspend goes, i
posted some really bad hacks to lkml some time ago that allow a
per-device exclusion of the suspend sequence. (the suspend_disabled
flag)
That way i was able to get a netconsole output far into the suspend, up
to the point where we do the ACPI mmio command that physically suspends
the CPU.
getting output from the system when it is coming out of resume is much
harder. (but this crash is about going into the suspend, right?)
(In reply to comment #4) > > getting output from the system when it is coming out of resume is much > harder. (but this crash is about going into the suspend, right?) Yes, but it happens in the middle of the "critical section" in which everything is supposed to be off, except for the CPU executing the code. IOW, it's very much like a resume failure ... (In reply to comment #3) > Created an attachment (id=13982) [details] > dmesg output > > dmesg output attached. Thanks. > I haven't tried other kernels, if that would be useful I could do it, any > version you want me to try? Hm, it looks like this problem has always been present ... > The box does have a serial port but I don't have anything to plug into it I'm > afraid. I see. Well, it seems that the IOMMU driver should mark the aperture as "nosave" for us (it overlaps with a memory area that the image-creating code considers as useable). Did you try to enable the IOMMU option in the BIOS setup, BTW? (In reply to comment #6) > Did you try to enable the IOMMU option in the BIOS setup, BTW? There doesn't seem to be any way to configure IOMMU in my BIOS setup, or if there is one I couldn't find it... It's an ASUS M2N-E SLI, chipset nForce 500. OK, thanks. Probably Asus doesn't think you'd need that. Unfortunately, I'm not familiar with the IOMMU handling code, so I'm afraid it'll take some time to come up with a fix ... hmmm, what if you boot with iommu=off? Actually I retested and the bug is fixed now, most likely by commit 2050d45d7c32cbad7a070d04256237144a0920db. commit 2050d45d7c32cbad7a070d04256237144a0920db Author: Pavel Machek <pavel@ucw.cz> Date: Thu Mar 13 23:05:41 2008 +0100 x86: fix long standing bug with usb after hibernation with 4GB ram shipped in 2.6.25-rc7 closed |