Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE_SUSPEND

Mike Galbraith
2006-11-24T21:42:45Z

On Fri, 2006-11-24 at 10:08 -0800, Linus Torvalds wrote:

> One thing that is often worth testing is to try with APIC support if you
> don't have it already, or if you do have it, try _without_ APIC support.
> The firmware generally is only tested against MS operating systems, so
> it's only ever been tested for the particular irq setup that Windows tends
> to use, and as a result sometimes things work better in one more or
> another.

I'll try noapic. (though I value my apic more than s2ram;)

> Based on the "fasteoi", you're obviously right now using the APIC, and
> that's _usually_ the mode that works better. But just in case, try booting
> with "noapic".
>
> Also, can you send out the boot log with APIC information ("apic=debug").
> Of course, don't disable the apic for that case, or it won't be very
> useful ;)

Will do. (not tomorrow though, helping friend with home construction)

I found the driver that was causing my panic problem with vanilla, it
was my Sat TV card. I haven't ever used it with Linux, and haven't used
it with that other OS but a couple of times to try it out(stupid stupid
purchase), so I tossed it.

Box still paniced though, apparently after restoring all drivers (last
trace mark was end of function marker). I disabled trace, and enabled
the "leave console active, danger danger" option in hopes of capturing
the panic, and what do you know, for the first time ever, box restored
all the way into X... only to panic about two seconds later. Nothing
whatsoever got to my serial console. Switching to a text console before
suspend didn't help either, the panic is invisible. Drat.

I'll toss rocks at it.

-Mike