Description of problem:
So after setting up my system to use xinerama I upgraded my kernel.
Now during bootup rhgb will freeze on the one display (This is how I
know its using xinerama, without it would show the same on both displays)
The only way I have found around this is to remove rhgb from the boot
Should xinerama be supported in rhgb?
Version-Release number of selected component (if applicable):
[bpeck@peck boot]$ rpm -q rhgb
[bpeck@peck boot]$ rpm -q xorg-x11
Steps to Reproduce:
1. configure xinerama
2. boot the system with rhgb
system freezes once rhgb starts
00:00.0 Host bridge: Intel Corp. E7505 Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corp. E7505/E7205 PCI-to-AGP Bridge (rev 03)
00:02.0 PCI bridge: Intel Corp. E7505 Hub Interface B PCI-to-PCI
Bridge (rev 03)00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2
EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC
Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corp. 82801DB (ICH4) IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
QY [Radeon 7000/VE]
02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
03:0e.0 Ethernet controller: Intel Corp. 82545EM Gigabit Ethernet
Controller (Copper) (rev 01)
My desktop is a Matrox G450 running with xinerama and I don't have
trouble with rhgb (RHEL4 beta). I doubt it's just xinerama which
is the cause of the problem
Something is wrong. If I configure X as a single head it boots
everytime in rhgb (I booted 5 times in a row). As soon as I change it
to multi-head it either fails as soon as RHGB starts or freezes right
when HAL is printed on the screen.
[root@peck ~]# diff /etc/X11/xorg.conf-single /etc/X11/xorg.conf-multi
< Screen 0 "Screen0" 0 0
> Screen 0 "Screen0" LeftOf "Screen1"
> Screen 1 "Screen1" 0 0
> Section "Monitor"
> Identifier "Monitor1"
> VendorName "Monitor Vendor"
> ModelName "IBM 6636"
> HorizSync 30.0 - 61.0
> VertRefresh 56.0 - 75.0
> Option "dpms"
> Section "Device"
> Identifier "Videocard1"
> Driver "radeon"
> VendorName "Videocard Vendor"
> BoardName "ATI Radeon 7000"
> BusID "PCI:1:0:0"
> Screen 1
> Section "Screen"
> Identifier "Screen1"
> Device "Videocard1"
> Monitor "Monitor1"
> DefaultDepth 16
> SubSection "Display"
> Viewport 0 0
> Depth 16
> Modes "1024x768"
I just noticed something that could very well be the problem. When I
have the system configured for xinerama I can't switch to alternate
virtual consoles. As soon as I type <Ctrl><Alt><F1> it freezes even
if I leave RHGB out of the bootup process. If I'm configured for
single head then switching consoles works fine.
now that I think about it I bet when RHGB fails in the begining its
when it noticed that the system crashed and its jumping to the text
console to show fsck progress.. and when it fails at HAL its the last
service to start and should be exiting to run gdm.
Just FYI, I have the exact same problem (either in clone or
multihead), same video card (Radeon 7000/VE on a Dell Precision 650).
Rhgb hangs, either at the beginning or after mdmpd or udev startup and
it freezes when I try to switch virtual console.
However, when I kill the X server (Ctrl-Alt-Bkspc), it restarts fine,
without any hangs (although it of course switches momentarily to a
text VC, no problem after a server kill---problem occurs only when I
switch VCs with X running). Only occasionally, gdmgreeter dies after
doing this (and gdm starts another greeter that looks different, which
runs ok and another server kill brings back the "normal" greeter).
FYI, the machine is dual-CPU (I had problems with the version of Xorg
in the original release of FC3 when I ran the SMP kernel, which were
subsequently fixed). Not sure if related at all, but will try the
non-smp kernel anyway on the next reboot and post if I have any luck.
No, same thing with single-processor kernel.
Also, don't know what I was thinking, but I meant "HAL", not "udev"
(in any case, the last service that starts up, as pointed out by the
I have the same problem with a dell latitude D600 when docked (2 screens, dual
If i boot by going to runlevel 1 then exit (bypass rhgb) everything is fine and
works fine (including dual screen etc....)
If i let rhgb start by booting in runlevel 5, it hangs at the end. But only it
hangs, not the system. True I can't access anything, but my laptop acpi is
configured to shutdown when I hit power button and it does so when rhgb hangs so
it's not a system freeze or such.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.
Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.
Thank you in advance.
(this message is mass message)