Bug 179041
Summary: | udev-071-0.FC4.2 gives streaked login screen | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fred New <fred.new2911> |
Component: | module-init-tools | Assignee: | Harald Hoyer <harald> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | ahabig, ben, covex, fedora, mathompson97, tengel, zing |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-09 09:23:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Fred New
2006-01-26 20:26:24 UTC
Does it help if you add this to /etc/modprobe.conf?? # framebuffer drivers blacklist aty128fb blacklist atyfb blacklist radeonfb blacklist i810fb blacklist cirrusfb blacklist intelfb blacklist kyrofb blacklist i2c-matroxfb blacklist hgafb blacklist nvidiafb blacklist rivafb blacklist savagefb blacklist sstfb blacklist neofb blacklist tridentfb blacklist tdfxfb blacklist virgefb blacklist vga16fb No, I just get a bunch of messages like Jan 28 11:31:49 darth modprobe: WARNING: /etc/modprobe.conf line 13: ignoring bad line starting with 'blacklist' Can you suggest something a little different? Just to be clear, this is FC4 with module-init-tools-3.1-4. I notice these modules are all listed in /etc/hotplug/blacklist. Ok, s.th. like alias aty128fb none should work for fc4. Even better: install aty128fb /bin/true Yep, that fixes the problem. This bug is still present in udev-071-0.FC4.2. That is, I tried it without the modprobe.conf change and aty128fb gets used, resulting in the unusable login screen. Please try module-init-tools-3.2-0.pre9.0.FC4.1 Everything works with module-init-tools-3.2-0.pre9.0.FC4.1 udev-071-0.FC4.2 and modprobe.conf back to the way it was before this problem. Thanks. Hope it will help to fix my X.org and gdm login screen, which is trashed here with ATI r128. Oh no! The new udev got released into updates-released without the new module-init-tools. Now my non-test computer is showing these symptoms. I know how to fix it, but the rest of the FC4 non-test world is going to have problems. I installed module-init-tools-3.2-0.pre9.0.FC4.1 on my non-test system, but it doesn't prevent this problem. I have a different video adapter there. The last few lines of dmesg show: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 matroxfb: Matrox G550 detected PInS memtype = 5 matroxfb: MTRR's turned on matroxfb: 640x480x8bpp (virtual: 640x26214) matroxfb: framebuffer at 0xF2000000, mapped to 0xf1800000, size 33554432 Console: switching to colour frame buffer device 80x30 fb0: MATROX frame buffer device application mixer_applet2 uses obsolete OSS audio interface For this system, putting install matroxfb /bin/true into /etc/modprobe.conf didn't work. I used lsmod to find the name of the module being used. The login screen works normally after I put install matroxfb_base /bin/true into /etc/modprobe.conf. Bug 180003 seems to nearly duplicate behavior reported in comment 11 and 12. *** Bug 180003 has been marked as a duplicate of this bug. *** I described similar/same issue with matroxfb in bug 18003. According to my opinion it is because frame buffer is initialized at same time as X is starting. However I do not know what changed in udev that it always inserts FB module for any video card at X start. The workaround in comment #12 will most probably fix the problem. What I did is that I removed /lib/modules/.../kernel/driver/video/matrox from modules tree, and login appears as usuall. I have the same problems on two systems of mine, a laptop and a desktop, both with a Radeon video adapter. Installing module-init-tools-3.2-0.pre9.0.FC4.1 solves the problem, but after installation of this package, the radeonfb kernel module doesn't get loaded at startup. I think we don't want to load the frame buffer driver at all if we are using graphical mode (run level 5). Someone please correct me if I am wrong. The next build of udev should depend on a minimum version of module-init-tools. I thought this bug would have resulted in this change before udev-071-0.FC4.2 got released, but it looks like the latest kernel forced a premature push of udev. *** Bug 179899 has been marked as a duplicate of this bug. *** *** Bug 179943 has been marked as a duplicate of this bug. *** *** Bug 179951 has been marked as a duplicate of this bug. *** This exact bug also happens on my ATI Rage Mobility M3, a Dell Latitude C600 laptop. Yes, it appears this udev got pushed out with the newest kernel, I recommend marking this as a high priority to get fixed -- it took me quite a bit of digging to figure out what was wrong and use links/bash to snatch the older udev in order to get operational again. I dare say a lot of folks will never get half as far as I did withoug any X (ergo Firefox/Mozilla) to search for help. Another system: Very similar problems with ATI Radeon 7500 too. The screen is messed up when X starts. Restarting X helps but console is driven trought frame buffer, which is not likely needed. It is still not clear to me, what is the mechanism of this problem. It is clear that it is cause by FB and X initialization at once. But why and who asks for fb module insertion (udev, kernel, X (dri))? How could module-init-tools solve that? A temporary workaround I found was switching from X to a virtual terminal and then again to X. This solved the problem. *** Bug 179989 has been marked as a duplicate of this bug. *** The problem is gone for me with the latest updates (I guess the new module-init-tools fixed it). Original description at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179943 Problem gone for me too after update of module-init-tools. Original description at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179989 Still same for me with all these updates and matrox. [drm] Initialized drm 1.0.0 20040925 [drm] Initialized mga 3.2.0 20050607 on minor 0: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode matroxfb: Matrox Millennium G200 (AGP) detected PInS memtype = 5 matroxfb: MTRR's turned on matroxfb: 640x480x8bpp (virtual: 640x13107) matroxfb: framebuffer at 0xDD000000, mapped to 0xe1480000, size 8388608 Console: switching to colour frame buffer device 80x30 fb0: MATROX frame buffer device What's worse is that after this update I got lot of times this warining: modprobe: WARNING: Failed to open included config file /etc/modprobe.conf.dist: No such file or director I found there was added "include /etc/modprobe.conf.dist" into /etc/modprobe.conf, but the file is in /etc/modprobe.d/modprobe.conf.dist. On second system with ati radeon, new module-init-tools prevent radeonfb to be loaded. Does anybody understand what has changed that it works for radeon but not for matrox? There is a new update, module-init-tools-3.2-0.pre9.0.FC4.3, in the updates-testing repository that fixes the matroxfb problem for me. |