Created attachment 360446 [details] Xorg.0.log from startx from runlevel 3 Description of problem: Having this hardware http://www.smolts.org/show?uuid=pub_ce8efab8-df31-4979-b80f-a8bc82bb5874 with GeForce G 102M video. I've tested the LiveCD from Nouveau Test Day https://fedoraproject.org/wiki/Test_Day:2009-09-10_Nouveau. The system halts if the system try to start Xorg after services from rc.d are started. After that I've booted on 3-rd runlevel the find out the xorg-x11-drv-nouveau version, get dmesg and Xorg.0.log for you. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.15-8.20090904git2b5ec6a.fc12.i686 How reproducible: Always Steps to Reproduce: 1. Download http://adamwill.fedorapeople.org/20090909_test_day_images/testday-20090909-i686.iso and burn the LiveCD 2. Boot Asus K50IN laptop from LiveCD Actual results: The system halts if the system try to start Xorg after services from rc.d are started. Expected results: The system should boot successfully to the normal graphical login screen, at the optimal resolution for your monitor, with no graphical artifacts (missing cursor, wrong colors etc) Additional info: I've used the 32-bit LiveCD.
Created attachment 360447 [details] dmesg for Asus K50IN laptop
So just to be clear, you can boot into runlevel 3 just fine with kernel modesetting still enabled (so, you see a graphical console rather than VGA text console)? There have been known issues on that chipset, it'd be useful to get a trace of the NVIDIA binary driver initialising it. I'm not sure there's a version of the binary driver that works with current rawhide yet, but I'll check that myself in the morning and get back to you with instructions! Thanks!
> So just to be clear, you can boot into runlevel 3 just fine with kernel > modesetting still enabled (so, you see a graphical console rather than VGA text > console)? Yes. I can boot into runlevel 3 just adding "3" to the boot parameters in grub. And I see the graphical console rather than VGA text console.
With the latest releases of kernel, libdrm and xorg-x11-drv-nouveau you should be able to make it into X. However, acceleration will be disabled, but it's better than a hang. However, there's been some updates to the kernel which may have fixed the acceleration issue too, I just don't have access to the hardware to be able to test it. So, if you update, could you post your dmesg output here so I'm able to see if the engine hangs while trying to draw console messages? The slight catch here is that you can't use 2.6.31-14.fc12 as it has console acceleration temporarily disabled. The version prior, or after will be fine however. Thanks!
you won't be able to do the required testing with the test day live CD. you could use an installed copy of Rawhide, but if that's not convenient for you, you can grab nightly live CDs here: http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ I think the current one probably has the kernel Ben doesn't want you to test with, though. so probably best to get one tomorrow or the day after, then it should be OK. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Sorry for delay with replay. But I have no unlimited internet access so I have to ask fiends to download image. Last time we've downloaded kde-i386-20090915.15.iso from Fedora Nightly which requires more then 1 CD-R :( I've started the download desktop-i386-20090917.16.iso which is based on kernel-2.6.31-23.fc12.i686 right before saw Adam's message. :( Now I've interrupted it. I'll be able to download the image in couple days only... But I'll provide you with results asap. Thank you in concern.
Thanks a lot! I'll reset the NEEDINFO flag until then too, thanks!
2.6.31-23 would be fine, according to Ben. Unfortunately we can't strictly control the size of the nightly builds :/ if they're too big for a CD you can always write them to DVD or a USB stick, though. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
> 2.6.31-23 would be fine, according to Ben. OK. I continue to download desktop-i386-20090917.16.iso. But I can get the image on Monday only. :( 2Ben: Do you need dmesg output only? Or do you need me to implement some more tests? I ready to help as much as I can. > Unfortunately we can't strictly control the size of the nightly builds :/ if > they're too big for a CD you can always write them to DVD or a USB stick, > though. Oops. I didn't think about it... I'll keep it in my mind! Thanks, Adam.
The dmesg output alone will be fine, it's enough to see if the console acceleration code causes the engine to crash (not fatal, it'll automatically fall back to software rendering). If it doesn't crash, the problem's fixed and it'll be safe to allow X to use acceleration again.
Created attachment 361863 [details] dmesg for desktop-i386-20090917.16.iso The system boot with some artefacts (like before) while gdm is starting. Then gdm looks fine and system logs in without any issues.
OK, the artifacts are just uninitialised framebuffer memory. With working acceleration, we'd do a copy before setting the display to show it. It's good to know that people with the same chipset as you will be able to make it into X now at least, I'm working on getting access to the chipset to fix it fully.
Please fill free to contact me with email if you need my hardware to test the driver. Should I close the bug now? Thank you.
Thank you for the offer :) I'll leave the bug open for now until it's fixed properly, but tomorrow I'll assign all related bugs to a tracker bug. Thanks again!
*** Bug 522575 has been marked as a duplicate of this bug. ***
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions). Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
I'm using Fedora 11 x86_64 now. But I'll download nightly build (for instance http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-i386-20091105.16.iso) and check the hardware behaviour using test from https://fedoraproject.org/wiki/Test_Day:2009-09-10_Nouveau I'll let you know a result.
Sorry for a long delay. In fact I was not able to boot with desktop-i386-20091105.16.iso. X starts and I see black screen with some artefacts and busy mouse cursor. However mouse can move. I've waited near 10 minutes without any changes, and didn't saw gdm. Also I wasn't able to switch into text console. I'm waiting for Constantine release to test next time.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've upgraded my system to the Fedora 12. I had no any issues neither with anaconda while upgrade process nor after upgrade was complete. So I can conclude that the ticket can be closed as resolved. Also I've checked my system with Test Day's cases. Here the results: * QA:Testcase_nouveau_basic - PASS * QA:Testcase_nouveau_xvideo - PASS * QA:Testcase_nouveau_restartx - PASS * QA:Testcase_nouveau_rendercheck (requires 15 minutes) - PASS * QA:Testcase_nouveau_fastuserswitch - PASS * QA:Testcase_nouveau_vtswitch - PASS * QA:Testcase_nouveau_suspend - FAIL * QA:Testcase_nouveau_multihead - N/A * QA:Testcase_nouveau_compositing_manager - FAIL (KDE's systemsettings said that it can't enable visual effects). Should I create a new bug about failed suspend? Thank you for Linux improvement.
that's great, thank you very much for the comprehensive retest! for failed suspend - yes, if it's not already covered by another report (check http://bugz.fedoraproject.org/xorg-x11-drv-nouveau ). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers