boot hangs with Dell 3007WFP-HC at Radeon X1950XTX

Bug #493834 reported by Ancoron Luziferis
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Medium
Unassigned
usplash (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Hardware:
- Gigabyte GA-MA785GM-US2H motherboard
- AMD Athlon(tm) II X4 620 Quad-Core
- 4GB RAM
- ATI Radeon X1950XTX PEG

Software:
- latest BIOS from gigabyte
- Kubuntu 9.10 Karmic Koala AMD64
- kernel 2.6.31-15.50 or mainline 2.6.32 (generic)

I have a serious problem.

I want to finally get rid of the old CRT's I have here and replace them with a single 30" LCD. As I already have a Dell 3007WFP-HC at work working perfectly with a HD2400Pro and the radeon driver I thought this would be straight forward.

But the problem is as soon as I try to boot with the big Dell attached the boot hangs and is waiting for something. No progress bar, no splash, not even a blinking cursor. The display just remains black although the backlight is turned on. If I just unplug the monitor cable (and yes, it IS a Dual-Link) while the boot process stopped it continues immediately. No errors or warning in the logs (as far as I can tell).

As you can see in the attached messages.log the early stage in that the boot process hangs couldn't be produced by a driver bug. So there must be something in the kernel. As I have a very similar setup at work running without any problems even with the 2.6.32 vanilla kernel it looks like some kind of race condition.

Additionally when I boot the system with the monitor detached and reattach it when the boot completed I just restart KDM service and voila, all things are fine, composition works, glxgears, no corruptions at all. So the driver is working fine (as it should).

Thanx,

Ancoron

Tags: karmic
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :

Currently running the vanilla 2.6.32 kernel (doesn't make a difference at all during boot).

uname -a:
Linux bitch 2.6.32-020632-generic #020632 SMP Thu Dec 3 10:09:58 UTC 2009 x86_64 GNU/Linux

cat /proc/version:
Linux version 2.6.32-020632-generic (root@zinc) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #020632 SMP Thu Dec 3 10:09:58 UTC 2009

Andy Whitcroft (apw)
tags: added: kernel-series-unknown
Revision history for this message
Ancoron Luziferis (ancoron) wrote :

The exact same result with kernel 2.6.31-16:

uname -a:
Linux bitch 2.6.31-16-generic #52-Ubuntu SMP Thu Dec 3 22:07:16 UTC 2009 x86_64 GNU/Linux

cat /proc/version_signature:
Ubuntu 2.6.31-16.52-generic

Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Andy Whitcroft (apw)
tags: added: karmic
removed: kernel-series-unknown
Revision history for this message
Ancoron Luziferis (ancoron) wrote :

I experienced a hang at the same point at another system yesterday where I first updated some packages, then turned off the machine, changed monitors and then trying to boot again.

The hang on this second machine was more persistent as detaching monitors doesn't result in a continued boot. As I still have a 9.04 installation on that system on another partition I tried to boot that and it boots without hangs and just as expected.

I then tried to change boot options for the karmic kernel in grub and "fbdev=no" or "vga=normal" works.

So this seems to be some kind of framebuffer issue.

The strange thing here is the following:

At the first mentioned machine I chagned from CRTs to the 30" Dell LCD which doesn't provide supported standard timings through EDID/DDC so I could understand the issue there. On the other hand the exact same monitor worked previously with a HD2400PRO on another machine and also works with a HD4770 on the same machine.

At the second machine I changed from a Dell 30" LCD + 22" CRT to 19" Dell LCD + 22" CRT and in addition the 19" Dell LCD does provide supported standard timings through EDID/DDC (excerpt from Xorg.0.log):

...
(II) RADEON(0): Supported established timings:
(II) RADEON(0): 720x400@70Hz
(II) RADEON(0): 640x480@60Hz
(II) RADEON(0): 640x480@75Hz
(II) RADEON(0): 800x600@60Hz
(II) RADEON(0): 800x600@75Hz
(II) RADEON(0): 1024x768@60Hz
(II) RADEON(0): 1024x768@75Hz
(II) RADEON(0): 1280x1024@75Hz
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported standard timings:
(II) RADEON(0): #0: hsize: 1152 vsize 864 refresh: 75 vid: 20337
(II) RADEON(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897
(II) RADEON(0): Supported detailed timing:
(II) RADEON(0): clock: 108.0 MHz Image Size: 376 x 301 mm
(II) RADEON(0): h_active: 1280 h_sync: 1328 h_sync_end 1440 h_blank_end 1688 h_border: 0
(II) RADEON(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0
(II) RADEON(0): Serial No: 641806BK19ZA
(II) RADEON(0): Monitor name: DELL 1907FP
...

As I made package updates before I changed the monitors (for both machines) I'll attach the dpkg.log section for the updates made before the hanging boot.

Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :

Correction:

the actual kernel option that causes the hang is "splash".

The framebuffer options don't make a difference at all here.

Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Ancoron Luziferis (ancoron) wrote :
Revision history for this message
Stefan Bader (smb) wrote :

The evidence seems to be more and more pointing to usplash. On the usplash debugging wiki (https://wiki.ubuntu.com/DebuggingUsplash) there are some good hints. First, if you are able to boot without splash and then change to a VT and run usplash manually, then you could (or do that before) log in from the second machine and try to gather more information (strace, can you kill it, ...). The other thing (if you happen to have a 32 life CD lying around (I think I saw the dmesgs were from 64bit installs), you could compare its behavior against your install.

Revision history for this message
Peter B P (peterbp) wrote :

This bug also affects me; latest karmic/9.10 as of 28dec2009.

Problem encountered when replacing an older TFT monitor (Acer 24" - X243W) with a newer Samsung Syncmaster P2450.

Boot is fine UP TO loading Grub, at which it stalls with the same symptoms - blank, black screen, but backlight on (so it still receives a signal from the gfx card). No curser, no screen activity whatsoever.

No system acitivity either, no HD activity.

When i detatch the monitor (connected between gfx card (Radeon HD4650) and monitor with HDMI cable), boot continues fine, and I'm able to log in (albeit headlessly). I hear the usual ubuntu greeting sound after punching in the username and pw.

I have a fast fix (thanks to Stefan Bader above for the hint!):

1) Boot your system in recovery mode (via grub).

2) Get your terminal and edit /etc/uspash.conf (if you want to use gedit: write 'sudo gedit /etc/usplash.conf' )

3) it's a simple configuration file; edit the dimensions in the two lines to the native resolution of your display.

4) Save, do a 'sudo initramfs -u' - this will write the setting into the boot setup.

5) Reboot.

My monitor still looks a bit mushy but at least it returned my sustem to a workable state.

Revision history for this message
Phillip Susi (psusi) wrote :

The usplash package has been superseded by plymouth and has been removed from the Ubuntu archive. Closing all related bugs.

Changed in usplash (Ubuntu):
status: New → Invalid
Revision history for this message
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix".

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.