Bug 522361 - Nouveau doesn't work on Asus K50IN laptop
Summary: Nouveau doesn't work on Asus K50IN laptop
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 12
Hardware: i686
OS: Linux
low
low
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 522575 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-10 07:12 UTC by Kuznetsov Vyacheslav
Modified: 2018-04-11 08:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-24 18:12:57 UTC


Attachments (Terms of Use)
Xorg.0.log from startx from runlevel 3 (20.88 KB, text/plain)
2009-09-10 07:12 UTC, Kuznetsov Vyacheslav
no flags Details
dmesg for Asus K50IN laptop (66.91 KB, text/plain)
2009-09-10 07:12 UTC, Kuznetsov Vyacheslav
no flags Details
dmesg for desktop-i386-20090917.16.iso (42.36 KB, text/plain)
2009-09-21 06:04 UTC, Kuznetsov Vyacheslav
no flags Details

Description Kuznetsov Vyacheslav 2009-09-10 07:12:03 UTC
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.

Comment 1 Kuznetsov Vyacheslav 2009-09-10 07:12:48 UTC
Created attachment 360447 [details]
dmesg for Asus K50IN laptop

Comment 2 Ben Skeggs 2009-09-10 08:32:26 UTC
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!

Comment 3 Kuznetsov Vyacheslav 2009-09-10 09:53:56 UTC
> 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.

Comment 4 Ben Skeggs 2009-09-15 22:32:33 UTC
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!

Comment 5 Adam Williamson 2009-09-17 20:06:46 UTC
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

Comment 6 Kuznetsov Vyacheslav 2009-09-18 05:03:22 UTC
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.

Comment 7 Ben Skeggs 2009-09-18 05:11:32 UTC
Thanks a lot!  I'll reset the NEEDINFO flag until then too, thanks!

Comment 8 Adam Williamson 2009-09-18 18:40:55 UTC
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

Comment 9 Kuznetsov Vyacheslav 2009-09-19 05:25:39 UTC
> 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.

Comment 10 Ben Skeggs 2009-09-20 00:50:05 UTC
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.

Comment 11 Kuznetsov Vyacheslav 2009-09-21 06:04:39 UTC
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.

Comment 12 Ben Skeggs 2009-09-21 12:11:16 UTC
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.

Comment 13 Kuznetsov Vyacheslav 2009-09-21 13:11:52 UTC
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.

Comment 14 Ben Skeggs 2009-09-21 13:47:11 UTC
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!

Comment 15 Ben Skeggs 2009-09-25 08:25:33 UTC
*** Bug 522575 has been marked as a duplicate of this bug. ***

Comment 16 Matěj Cepl 2009-11-05 17:15:46 UTC
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.]

Comment 17 Kuznetsov Vyacheslav 2009-11-06 09:08:07 UTC
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.

Comment 18 Kuznetsov Vyacheslav 2009-11-12 19:39:24 UTC
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.

Comment 19 Bug Zapper 2009-11-16 12:10:29 UTC
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

Comment 20 Kuznetsov Vyacheslav 2009-11-24 16:24:13 UTC
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.

Comment 21 Adam Williamson 2009-11-24 18:12:57 UTC
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


Note You need to log in before you can comment on or make changes to this bug.