Bug 536923

There's known issues in the support for G210 currently.  I don't have access to the hardware as of yet unfortunately.  It'd be useful if you could attach your card's VBIOS image to the bug.  If you could follow the vbtracetool instructions at http://nouveau.freedesktop.org/wiki/DumpingVideoBios, that'd be great.

As for nomodeset: there's no plans to support this chipset at all.

Created attachment 369207 [details]
BIOS ROM for GT210M

BIOS rom attached. I was unable to get a POST trace because I got the error "Failed to initialize LRMI... ./vbtracetool: option requires an argument -- 's'".

Also, I didn't understand your comments about 'nomodeset'.  I had to set this option at grub or else I couldn't get access to the system at all. Did you mean that you don't support "modeset" for this chipset?

No, I meant we don't support nomodeset, and support will be removed completely from upstream at some point in the near future.  The KMS (modeset) code is already far more capable, and is what we'll focus on going forward.  The KMS code has the beginnings of support for G210, but as you're seeing, it's obviously not quite there yet :)

Thanks for the rom image, I'll take a look at it when I get a chance!

I attempted to run 
sudo ./vbtracetool -p -l &>post.iolog
sudo ./vbtracetool -p -d &.post.log

As root, but I still got
mmap /dev/zero: Permission denied
Failed to initialize LRMI (Linux Real-Mode Interface)

It's possible that I don't have access to /dev/zero on a live image (I haven't installed the OS locally because of this bug). I am currently working from a LiveUSB with extra space for adding packages.

Hmm, not sure what's up there.  Does /dev/zero exist, and have permissions set at all?

Also worth mentioning that the VBIOS image just contains vbtracetool error messages too, and not an actual image :)

Created attachment 370333 [details]
BIOS ROM for GT210M

I found the problem. I was getting SELinux denials.

Attaching the real dumps now.

Created attachment 370334 [details]
I/O Logging of modeset

I'm not sure this will be useful or accurate, as the only way I could get to a usable console was with "nomodeset" on the grub command line.

Created attachment 370336 [details]
POST log from vbtracetool

Mmm, how odd.  The panel doesn't use straps to determine the mode, nor does it do DDC.  It looks like there might be a very badly constructed EDID block hidden in the VBIOS though.  What resolution is the panel supposed to be?

Also, can I see the dmesg log of nouveau trying to boot with KMS please?

Created attachment 375758 [details]
dmesg log with nouveau and kernel modesetting enabled

The native resolution of the panel is 1366x768.

Added the dmesg log as an attachment.

Doing a little digging, I suspect this may be the same bug as http://bugs.freedesktop.org/show_bug.cgi?id=25223

I will attempt to patch the source RPM with the proposed fixes in that bug and will report my findings.

The patches in http://bugs.freedesktop.org/show_bug.cgi?id=25223 will not apply against the source tarball from xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2efd.fc12.x86_64

Please enlighten me if there exists similar patches for this version of the display driver.

Those patches won't help in your case, there's something odd about your panel's configuration, none of the usual (read: the ways its done on older chipsets) methods seem to apply to your configuration.

In any case, the patches you mentioned above are in the most recent kernels available in koji already.

Created attachment 378414 [details]
EDID obtained from Windows. Sony Vaio VPC-CW17FX

I have a Sony Vaio VPC-CW17FX Laptop with nvidia gt210m. EDID obtained from Windows for using it in xorg.conf

Indeed Ben is right, there are serious problems with the method to obtain EDID. In fact i'm using the propietary driver right now and found some solution in nvnews nvidia forums. I need to obtain a .bin file from Windows, containing the EDID, then force in xorg.conf, section device. CustomEDID "filewithEDID". Is the only way around for now, but i cannot change to TTY with that solution. I'm uploading my EDID right now.

Just for the record, the Sony VAIO VPC-CW17FX is the exact model laptop I reported this original issue on as well. So thank you richerVE for providing the EDID.

Just a quick question, while running linux can you "cat /proc/acpi/video/VIDn/LCDn/EDID > ~/edid" and attach it (replacing "n" with whatever numbers happen to be there for you!).  We'll see if there's something sensible there.

Your VBIOS appears to call the system BIOS to get the EDID.. Argh!

I cannot get this information. I am only able to boot the machine into anything reminiscent of a usable state by adding "nomodeset 3" to my kernel line.

When I boot into runlevel 3 with nomodeset, no virtual directory /proc/acpi/video is present.

Ouch, that's inconvenient :)  Instead, are you able to install the pmtools package and run "acpidump > acpidump.log" and attach the log here.

Created attachment 379124 [details]
acpidump

acpidump attached as requested

Thanks!  CC'ing Matthew Garrett to work his magic :)

Your system has an EDID block in the ACPI table, and should be exporting a video interface. Can you check that the video module is loaded?

Ah, the lack of the video device should be fixed when we rebase to 2.6.32. However, we don't have an in-kernel way of retrieving the EDID. I'll work on that.

Created attachment 379284 [details]
Relax constraints on detecting ACPI video devices

This should result in the video device showing up

Created attachment 379285 [details]
Add a mechanism for extracting EDID from ACPI

Created attachment 379286 [details]
Fall back to using ACPI if all else fails

These are untested, and I know that they won't actually work at present. The ACPI table you provided shows that nvidia use non-standard device IDs for the TFT. I'll work out how to handle this.

Ok, let me know if you have a build you'd like me to test for you.

Matthew thank you for all your work. Looking forward to new changes

Can you give the kernel from http://koji.fedoraproject.org/koji/taskinfo?taskID=1884330 a go once it's built?

I'd love to, but that build failed with the errors:

+ make -s ARCH=powerpc V=1 -j4 modules
crypto/anubis.c: In function 'anubis_crypt':
crypto/anubis.c:581: warning: 'inter' is used uninitialized in this function
sound/isa/sb/sb16.c: In function 'snd_sb16_isa_probe':
sound/isa/sb/sb16.c:527: warning: 'err' may be used uninitialized in this function
In file included from sound/isa/sb/sbawe.c:2:
sound/isa/sb/sb16.c: In function 'snd_sb16_isa_probe':
sound/isa/sb/sb16.c:527: warning: 'err' may be used uninitialized in this function
sound/ppc/awacs.c: In function 'snd_pmac_awacs_init':
sound/ppc/awacs.c:886: warning: 'master_vol' may be used uninitialized in this function
sound/ppc/awacs.c:886: warning: 'speaker_vol' may be used uninitialized in this function
fs/fuse/dev.c: In function 'fuse_notify_inval_entry':
fs/fuse/dev.c:925: warning: the frame size of 1072 bytes is larger than 1024 bytes
drivers/gpu/drm/nouveau/nouveau_state.c: In function 'nouveau_ioctl_getparam':
drivers/gpu/drm/nouveau/nouveau_state.c:843: warning: integer constant is too large for 'long' type
drivers/gpu/drm/nouveau/nouveau_state.c:854: warning: integer constant is too large for 'long' type
drivers/gpu/drm/nouveau/nouveau_state.c:861: warning: integer constant is too large for 'long' type
drivers/gpu/drm/nouveau/nouveau_connector.c: In function 'nouveau_connector_create_lvds':
drivers/gpu/drm/nouveau/nouveau_connector.c:687: error: 'struct nouveau_connector' has no member named 'acpi_edid'
make[4]: *** [drivers/gpu/drm/nouveau/nouveau_connector.o] Error 1
make[3]: *** [drivers/gpu/drm/nouveau] Error 2
make[2]: *** [drivers/gpu/drm] Error 2
make[1]: *** [drivers/gpu] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
net/dccp/timer.c: In function 'dccp_timestamp':
net/dccp/timer.c:281: warning: comparison of distinct pointer types lacks a cast
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.fjWjGK (%build)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.fjWjGK (%build)
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target ppc --nodeps builddir/build/SPECS/kernel.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.4/site-packages/mock/util.py", line 324, in do
    raise mock.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target ppc --nodeps builddir/build/SPECS/kernel.spec']
LEAVE do --> EXCEPTION RAISED

Sorry about that. Can you try 

http://koji.fedoraproject.org/koji/taskinfo?taskID=1887280

instead?

Many apologies, but it appears that koji scratch build has expired while I was on vacation. Could you rerun it, please?

http://koji.fedoraproject.org/koji/taskinfo?taskID=1905627

Created attachment 382226 [details]
Xorg log for attempted kernel fix

The above kernel did not resolve my issues. Attaching the Xorg.0.log acquired whilre running that kernel.

You need to use KMS, the fix is there.  There is *no* chance of your card *ever* working with nouveau UMS (which is now removed completely upstream).

My apologies. I didn't realize that "nomodeset" had been selected for my grub command line. It must have been because I did the initial install in nomodeset (so that it would work at all)

Removing "nomodeset" allows the system to work as expected.

Thanks for all the help!

On kernel-2.6.31.9-174.fc12 it is indeed fixed, but on 2.6.32 and newer it appears again. Is it possible that the fixes are not there anymore?

Sorry for the comment above. Now I've complied kernel-2.6.32.8-55.fc12 with these patches, but it still doesn't work. Is there anything I can do to help fixing this issue?

I'm sorry again. I will not bother you again on this (or any other) bug.

The patch for this has been available for three months. Why hasn't it made its way into Fedora?

I'm trying to use one of the Fedora 13 Test Day livecds, and this bug is rearing its ugly head again.

Upstream still haven't given any feedback. I'll try them again.

It would be REALLY nice if this made its way into Fedora in time for tomorrow's (April 13) Nouveau Graphics Test Day.

The patches did make it in for the test day if I understand correctly.  I've done some additional fixes in kernel-2.6.33.2-49.fc13 (http://koji.fedoraproject.org/koji/taskinfo?taskID=2118272), which could benefit from testing!

Thank you :)

Sorry it got me so long to get back to you on this.

I just tested booting from the nightly GNOME livecd for Fedora 13, and this problem seems to have been resolved at least as of kernel 2.6.33.2-57.fc13

Thank you for your hard work!

Excellent, glad to hear :)