linux-kernel - Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE

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: <1164414171.6010.32.camel@Homer.simpson.net>
Date:	Sat, 25 Nov 2006 01:22:51 +0100
From:	Mike Galbraith <efault@....de>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@...e.cz>,
	Chuck Ebbert <76306.1226@...puserve.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [patch] PM: suspend/resume debugging should depend on
	SOFTWARE_SUSPEND

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

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