linux-kernel - Re: pcibios_scanned needs to be set in ACPI? (was Re: 2.6.25-rc5: Reported regressions from 2.6.24)

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: <alpine.LFD.1.00.0803121619420.3557@woody.linux-foundation.org>
Date:	Wed, 12 Mar 2008 16:35:41 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg KH <greg@...ah.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Jeff Garzik <jeff@...zik.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>,
	Ingo Molnar <mingo@...e.hu>, Len Brown <len.brown@...el.com>,
	Guennadi Liakhovetski <g.liakhovetski@....de>
Subject: Re: pcibios_scanned needs to be set in ACPI?  (was Re: 2.6.25-rc5:
 Reported regressions from 2.6.24)

On Wed, 12 Mar 2008, Greg KH wrote:
> >
> > It's not the warning that worries me. It's the apparent oops (keyboard 
> > leds blinking?) at shutdown/poweroff!
> 
> It oopses at shutdown?  I thought this was originally reported as a
> "will not power off" which for a while was attributed to the cpufreq fix
> that went into -rc2 or -rc3.
> 
> I didn't realize there was an oops, sorry.

I'm not at all sure there is an oops - in fact, I'd have expected it to 
show up on the serial console if there was one.

The bug report says that the keyboard leds blink, which is *sometimes* due 
to having the led oops blinking code enabled, but hey, no actual oops was 
ever shown, and sometimes a blink is just a blink.

Did you see the full dmesg from syslog? That one has not just the 
warnings, but also sysrq output at the point it hangs. The suspicious 
thing seems to be

	halt          R running      0  3291   3289
	       c013d75a 7488242e 00000180 75b8ffa0 c6efbddc c6efbddc c0426d00 c6efbdf0 
	       c0125da4 c6efbe10 c0125ed1 0000000a 00000001 c0426d00 c0426d00 00000046 
	       b7efcff4 c6efbe20 00000046 c0426d00 c0426d00 c6efbe2c c0126068 c110c060 
	Call Trace:
	 [<c013d75a>] ? tick_program_event+0x4a/0x80
	 [<c0125da4>] ? _local_bh_enable+0x24/0x80
	 [<c0125ed1>] ? __do_softirq+0xd1/0xf0
	 [<c0126068>] ? irq_exit+0x28/0x90
	 [<c0313079>] ? preempt_schedule_irq+0x49/0x70
	 [<c0103c28>] ? apic_timer_interrupt+0x28/0x30
	 [<c0251c58>] ? device_shutdown+0x48/0x70
	 [<c012e618>] ? kernel_shutdown_prepare+0x28/0x30
	 [<c012e630>] ? kernel_power_off+0x10/0x40
	...

which makes me suspect we're in some endless loop in device_shutdown(), 
but that's just a random guess (it seems to be running on the othe CPU: 
CPU0 is in idle - and when that happens the stack trace is really not 
very reliable at all, so take all that with a huge pinch of salt!).

> Sorry, I thought this was just a warning at boot time.

If it had been just the warning, I would ignore it as a good thing to be 
cleaned up later. But no, the original problem was the inability to halt 
and reboot, and the bugzilla entry says

	It also introduces these two errors:
	   ^^^^

with underlining by me. So the warnings in themselves are just an 
interesting coincidence (and probably related to the cause, of course).

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