Bug 684667

Summary:	HP ProBook 6550b hard locks during boot
Product:	[openSUSE] openSUSE 11.4	Reporter:	Greg Riedesel <greg>
Component:	Kernel	Assignee:	Egbert Eich <eich>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	jeffm, jslaby, tcj
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Greg Riedesel 2011-04-01 21:48:54 UTC

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.16) Gecko/20110323 Ubuntu/10.10 (maverick) Firefox/3.6.16

I have a brand new HP ProBook 6550b with the ATI HD4500 graphics card. OpenSUSE 11.4 installed just fine, and when the kernel kexeced to the desktop at the end of the install it worked just as I expected. But on the first reboot, startup hard locks (no panic, no blinking lights) sometime after the CRON demon starts. 

Before running updates, it is possible to load in Failsafe mode. Once updates are run, Failsafe also hard locks just after CRON startup. Single-user mode always works.

Running with the radeon driver before updates, starting with 'nomodeset' was enough to get logged in to loadstage 3, but loadstage 5 fails (unsurprisingly). After updates, even nomodeset seems to not work. 

Running the ati fgldx driver did not materially change things. It behaves just like after running updates, in that failsafe and nomodeset don't complete.

No meaningful output is ever seen on the console.

Ubuntu 10.10 works just fine, and there are reports that Fedora 14 also works.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1 Greg Riedesel 2011-04-03 21:49:08 UTC

Forgot to mention, the lockup also occurs with the Tumbleweed repo.

Comment 2 Jiri Slaby 2011-04-04 14:30:29 UTC

Could you boot with initcall_debug as described here:
http://en.opensuse.org/SDB:Debugging_boot_hang
?

Comment 3 Greg Riedesel 2011-04-05 15:05:50 UTC

To be annoying, the bug doesn't occur when I enter a 'console' option on boot. 'debug initcall_debug' don't make the bug go away, but the critical bits scroll well past the screen before the actual lockup occurs so I can't echo them here. In getting a serial capture going, the 'console=ttyS0,115200' option made it work. When running without the debug options, the same console option made it work. With only 'console=tty0' on the load line, it worked just fine.

Putting 'console=tty0' into the GRUB config is enough of a workaround for me.

Comment 4 Greg Riedesel 2011-04-05 16:49:13 UTC

On the other hand, after applying updates the trick only allows me to get into runlevel 3. Runlevel 5 hard locks again. Starting into RL3, logging in as root, and running 'telinit 5' launches GDM and everything works fine from there.

Comment 5 Greg Riedesel 2011-04-07 15:19:02 UTC

I'm having trouble finding two machines to talk serial to each other.

A vanilla 2.6.37.6 kernel I compiled (make oldconfig, no other changes) works just fine.

Comment 6 Jeff Mahoney 2011-04-15 18:51:13 UTC

This looks to be a bootsplash issue.

It's not reproducible with the vanilla kernel.
It's not reproducible with serial console.
It's not reproducible with console=tty0.

The last one is instructive since it means that fbcon isn't getting used.

Comment 7 Egbert Eich 2011-04-18 15:51:18 UTC

have you tried just without the vga=... option?
This could be a duplicate candidate of: 672008.

Comment 8 Greg Riedesel 2011-04-18 16:07:20 UTC

Removing the 'vga=' option does indeed make the lockup go away.

Comment 9 Jeff Mahoney 2012-08-02 15:58:55 UTC

With the coming release of openSUSE 12.2, openSUSE kernel developers are focusing their efforts there. Reports against openSUSE 11.4 and prior will not get the attention needed to resolve them before openSUSE 12.2 is release and openSUSE 11.4 becomes unmaintained.

Please re-test with openSUSE 12.1 or openSUSE RC2+ and re-open with an updated Product if you still encounter your issue.

We apologize for this issue not getting the attention it deserves but we are focusing our resources in the area where they will have the most impact for our users.  We're working hard to make openSUSE 12.2 the best openSUSE release yet!