[G72M] Screen corruption when using KMS. Dell Latitude D620 / Quadro NVS 110M/GeForce Go 7300

Bug #539730 reported by Scott James Remnant (Canonical) on 2010-03-16
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Nouveau Xorg driver
Fix Released
Medium
linux (Ubuntu)
High
Unassigned
Nominated for Lucid by Chris Halse Rogers

Bug Description

Binary package hint: xserver-xorg-video-nouveau

Nothing useful is displayed on screen in graphics mode with this laptop, instead it seems like random data pixels and colours end up on the panel.

With nouveau.modeset=0, you get an X server and everything, just at the wrong resolution (that's where I'm typing this bug from)

ProblemType: Bug
Architecture: i386
Date: Tue Mar 16 17:33:19 2010
DistroRelease: Ubuntu 10.04
DkmsStatus: bcmwl, 5.60.48.36+bdcom, 2.6.32-16-generic, i686: installed
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100316)
MachineType: Dell Inc. Latitude D620
Package: xserver-xorg-video-nouveau 1:0.0.15+git20100219+9b4118d-0ubuntu4
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-16-generic-pae root=UUID=590072c8-9832-4745-ab72-9e7715dd5c22 ro quiet splash initcall_debug nouveau.modeset=0
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic-pae
SourcePackage: xserver-xorg-video-nouveau
Uname: Linux 2.6.32-16-generic-pae i686
dmi.bios.date: 05/16/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A10
dmi.board.name: 0KX350
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA10:bd05/16/2008:svnDellInc.:pnLatitudeD620:pvr:rvnDellInc.:rn0KX350:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Latitude D620
dmi.sys.vendor: Dell Inc.
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-16-generic-pae

Bryce Harrington (bryce) on 2010-03-16
summary: - Nothing useful on screen. Dell Latitude D620. nVidia Corporation G72M
- [Quadro NVS 110M/GeForce Go 7300]
+ [G72M] Screen corruption when using KMS. Dell Latitude D620 / Quadro
+ NVS 110M/GeForce Go 7300

I don't think X is hung at all; here's the ps output, everything looks normal

And here's what X is doing:

root@mario:~# cat /proc/1000/wchan
poll_schedule_timeout

Here's a photo of what plymouth renders to the framebuffer. This is supposed to be the ubuntu logo mid-way on a purple screen.

Odd how the explosion of white (which could be the logo) is rotated 90 degrees, then offset midway "up" the screen.

If you applied the same logic to the other photo, the vertical white bar would be where the top/bottom panels would be maybe?

Bryce Harrington (bryce) wrote :

With modeset=0 it looks like it's falling back to -vesa, which explains the wrong resolution (since it is not doing any modesetting in that case, just using VESA defaults.)

Bryce asked for the xrandr --verbose output while in -vesa

Screen 0: minimum 800 x 600, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 (0x108) normal (normal) 0mm x 0mm
 Identifier: 0x107
 Timestamp: 15051
 Subpixel: unknown
 Clones:
 CRTC: 0
 CRTCs: 0
 Transform: 1.000000 0.000000 0.000000
             0.000000 1.000000 0.000000
             0.000000 0.000000 1.000000
            filter:
  1024x768 (0x108) 48.0MHz *current
        h: width 1024 start 0 end 0 total 1024 skew 0 clock 46.8KHz
        v: height 768 start 0 end 0 total 768 clock 61.0Hz
  800x600 (0x109) 29.3MHz
        h: width 800 start 0 end 0 total 800 skew 0 clock 36.6KHz
        v: height 600 start 0 end 0 total 600 clock 61.0Hz

Bryce Harrington (bryce) wrote :

This chunk at the end of the Xorg.0.log looks interesting:

(II) NOUVEAU(0): EDID vendor "LPL", prod id 224
(II) NOUVEAU(0): DDCModeFromDetailedTiming: 1440x900 Warning: We only handle separate sync.
(II) NOUVEAU(0): Printing DDC gathered Modelines:
(II) NOUVEAU(0): Modeline "1440x900"x0.0 88.89 1440 1488 1520 1600 900 903 909 926 -hsync -vsync (55.6 kHz)
(II) NOUVEAU(0): EDID vendor "LPL", prod id 224
(II) NOUVEAU(0): DDCModeFromDetailedTiming: 1440x900 Warning: We only handle separate sync.
(II) NOUVEAU(0): Printing DDC gathered Modelines:
(II) NOUVEAU(0): Modeline "1440x900"x0.0 88.89 1440 1488 1520 1600 900 903 909 926 -hsync -vsync (55.6 kHz)
(II) NOUVEAU(0): EDID vendor "LPL", prod id 224
(II) NOUVEAU(0): DDCModeFromDetailedTiming: 1440x900 Warning: We only handle separate sync.
(II) NOUVEAU(0): Printing DDC gathered Modelines:
(II) NOUVEAU(0): Modeline "1440x900"x0.0 88.89 1440 1488 1520 1600 900 903 909 926 -hsync -vsync (55.6 kHz)
(II) NOUVEAU(0): EDID vendor "LPL", prod id 224
(II) NOUVEAU(0): DDCModeFromDetailedTiming: 1440x900 Warning: We only handle separate sync.
(II) NOUVEAU(0): Printing DDC gathered Modelines:
(II) NOUVEAU(0): Modeline "1440x900"x0.0 88.89 1440 1488 1520 1600 900 903 909 926 -hsync -vsync (55.6 kHz)

I'm not sure what it means by "We only handle separate sync" but it sounds suboptimal. Probably just a symptom of some deeper problem.

Bryce Harrington (bryce) wrote :

> default connected 1024x768+0+0 (0x108) normal (normal) 0mm x 0mm

Hmm, normally it would have the proper dimensions. That it's showing 0mm x 0mm is quite interesting. The Xorg.0.log has correct info so not sure why xrandr would be seeing it as 0. Something smells wrong here.

This is ssh'd in while the corruption is on screen - not sure if that's right or not

root@mario:~# DISPLAY=:0 get-edid | parse-edid
get-edid: get-edid version 2.0.0

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
parse-edid: parse-edid version 2.0.0
 Function supported
 Call successful

 VBE version 300
 VBE string at 0x2110 "NVIDIA"

VBE/DDC service about to be called
 Report DDC capabilities

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
 Function supported
 Call successful

 Monitor and video card combination does not support DDC1 transfers
 Monitor and video card combination does not support DDC2 transfers
 0 seconds per 128 byte EDID block transfer
 Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
 Read EDID

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
 Function supported
 Call failed

The EDID data should not be trusted as the VBE call failed
Error: output block unchanged
parse-edid: IO error reading EDID

Confirming that switching from the -generic-pae kernel to just -generic makes no difference

Bryce Harrington (bryce) wrote :

mjg59 says that -vesa just doesn't have edid hooked up, thus the 0mm x 0mm. False alarm.

"VBE call failed" Rats.

Anyway, my guess is that something's wrong with your EDID, but without being able to actually see it I can't be sure. It could just be a general modesetting issue, or even just some other random bug in the display logic. I see you have an LPL monitor - which is a brand we've had to quirk around in UMS before, so this strikes me as a strong possibility.

Unfortunately, a lot of the techniques we would use to debug this in the pre-KMS days simply won't work anymore since the kernel doesn't provide a way to do the equivalent of overriding modelines and other settings in xorg.conf. (So even if we do get the EDID, I'm uncertain how to test theories, other than hacking on kernel code...) The old debugging approach is documented at http://wiki.ubuntu.com/X/Quirks - pretty much the same quirks exist in the kernel, but I don't know how to turn them on to test, aside from adding the code to drm_edid.c.

Anyway, I could be completely in left field. Maybe RAOF will have some better suggestions.

root@mario:~# parse-edid < /sys/class/drm//card0-LVDS-1/edid
parse-edid: parse-edid version 2.0.0
parse-edid: EDID checksum passed.

 # EDID version 1 revision 3
Section "Monitor"
 # Block type: 2:0 3:fe
 # Block type: 2:0 3:fe
 Identifier "LPL:e000"
 VendorName "LPL"
 ModelName "LPL:e000"
 # Block type: 2:0 3:fe
 # Block type: 2:0 3:fe
 # DPMS capabilities: Active off:no Suspend:no Standby:no

 Mode "1440x900" # vfreq 59.996Hz, hfreq 55.556kHz
  DotClock 88.890000
  HTimings 1440 1488 1520 1600
  VTimings 900 903 909 926
  Flags "-HSync" "-VSync"
 EndMode
 Mode "1440x900" # vfreq 59.996Hz, hfreq 55.556kHz
  DotClock 88.890000
  HTimings 1440 1488 1520 1600
  VTimings 900 903 909 926
 EndMode
 # Block type: 2:0 3:fe
 # Block type: 2:0 3:fe
EndSection

root@mario:~# cat /sys/class/drm//card0-LVDS-1/modes
1440x900
1152x864
1024x768
800x600
640x480
720x400
640x400
640x350

root@mario:~# cat /sys/class/drm//card0-LVDS-1/status
connected

airlied suggested dmesg from a boot with modeset=1 would be useful, here it is

dmesg without vga16fb joining the party

<mjg59> The gradual whiting out means that the LVDS isn't being driven correctly
 Might be worth dumping your video bios as well
 He may want the scripts
<mjg59> dd if=/dev/mem of=video.bios bs=65536 count=1 skip=12

mmiotrace of nvidia-glx

Bryce Harrington (bryce) on 2010-03-17
Changed in xserver-xorg-video-nouveau (Ubuntu):
status: New → Confirmed

I have a very similar problem. When trying to boot Lucid post alpha 3, the display shuts down after start of a boot, and turns on after a wile with corrupted screen (desktop wallpaper mashed up with other colors), and I don't hear the login sound, and can't see and use mouse or panels, icons.....
When booting with nomodeset=0 I can use the system with vesa loaded. The laptop is Acer Extensa 5635G with Nvidia G 105M. This laptop has corrupted EDID. I know that because I was having problem with Nvidia propertary driver which, when used, divided my display to 6 little screens with resolution 640*480. Nvidia guy's said that this was occurring because EDID was invalid and they made workaround for this bug in last beta driver.

Here is the xrandr --verbose while in vesa:
Screen 0: minimum 640 x 480, current 1280 x 720, maximum 1280 x 720
default connected 1280x720+0+0 (0x108) normal (normal) 0mm x 0mm
 Identifier: 0x107
 Timestamp: 402760
 Subpixel: unknown
 Clones:
 CRTC: 0
 CRTCs: 0
 Transform: 1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                    filter:
  1280x720 (0x108) 0.0MHz *current
        h: width 1280 start 0 end 0 total 1280 skew 0 clock 0.0KHz
        v: height 720 start 0 end 0 total 720 clock 0.0Hz
  800x600 (0x109) 29.3MHz
        h: width 800 start 0 end 0 total 800 skew 0 clock 36.6KHz
        v: height 600 start 0 end 0 total 600 clock 61.0Hz
  640x480 (0x10a) 18.4MHz
        h: width 640 start 0 end 0 total 640 skew 0 clock 28.8KHz
        v: height 480 start 0 end 0 total 480 clock 60.0Hz

In the attachment are files obtained while in vesa.

Here is the xorg.log while in vesa.

lspci -vvnn

dmesg

correction : I can see the mouse withe modest=1, but can't move it.

On Wed, 2010-03-17 at 12:26 +0000, Ivan Katanović wrote:

> System with vesa loaded. The laptop is Acer Extensa 5635G with Nvidia G 105M.
>
Since the card isn't identical, this may be a different bug with the
same symptoms

Scott
--
Scott James Remnant
<email address hidden>

Forwarded from Launchpad: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/539730

Nouveau seems unable to drive the LVDS on this laptop.

Nothing useful is displayed on screen in graphics mode with this laptop, instead it seems like random data pixels and colours end up on the panel.

Xorg log: http://launchpadlibrarian.net/41045198/XorgLogOld.gz
dmesg: http://launchpadlibrarian.net/41056521/dmesg.log
Dump of video bios: http://launchpadlibrarian.net/41058076/video.bios
mmiotrace of nvidia-glx bringing up X: http://launchpadlibrarian.net/41072914/nvidia-glx_trace

darktama has debugged this extensively and gave me a patch that produces right results; he has debugging output, edid, etc. so has an idea what's wrong I think

Changed in xserver-xorg-video-nouveau (Ubuntu):
importance: Undecided → High
Changed in nouveau:
status: Unknown → Confirmed
AlainKnaff (kubuntu-misc) wrote :

Not sure whether it's related, but I've got a PC with a GeForce GT220, which shows the following behavior on 10.04 Alpha 3:
1. During boot, output is sent both to VGA and DVI
2. after modprobe nouveau, or after starting up X, output is sent only to DVI. While usable output is sent to DVI, "garbled" output appears on the text mode virtual consoles after a while.

The proprietary nvidia driver (as seen in 9.04) does not have this problem.

The full lspci id of the card is:
02:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 220] (rev a2)

On Fri, 2010-03-19 at 14:14 +0000, AlainKnaff wrote:

> The full lspci id of the card is:
> 02:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 220] (rev a2)
>
You have a different card, so you have a different bug.

Scott
--
Scott James Remnant
<email address hidden>

Jeffrey Honig (jchonig) wrote :

I'm trying to live boot beta1 of Lucid on a similar D620. Both the amd64 and i386 desktop CDs give me same results. X is using the wrong scan rates so I am unable to use the system.

The system works fine with Interpid i386 and Karmic amd64 (Live and installed).

Is this the same issue?

Chris Halse Rogers (raof) wrote :

This now has a commit upstream: http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=8af36117e23bc36c34d0d25484f7b9de021b51bc

This commit is in the linux-backports-modules-nouveau package in xorg-edgers that will be built soon; Scott, would it be possible for you to test that the packages in xorg-edgers fix this for you?

affects: xserver-xorg-video-nouveau (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
milestone: none → ubuntu-10.04-beta-2
status: Confirmed → Triaged

On Tue, 2010-03-30 at 22:52 +0000, Chris Halse Rogers wrote:

> This now has a commit upstream:
> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=8af36117e23bc36c34d0d25484f7b9de021b51bc
>
> This commit is in the linux-backports-modules-nouveau package in xorg-
> edgers that will be built soon; Scott, would it be possible for you to
> test that the packages in xorg-edgers fix this for you?
>
The package fixes it for me provided desktop effects aren't enabled; if
desktop effects are enabled, then I get a corrupted screen within X.

(So yes, the patch works as intended, it's the other patches in
xorg-edgers that break it again :p)

Scott
--
Scott James Remnant
<email address hidden>

Chris Halse Rogers (raof) wrote :

On Tue, 2010-04-06 at 14:12 +0000, Scott James Remnant wrote:
> On Tue, 2010-03-30 at 22:52 +0000, Chris Halse Rogers wrote:
>
> > This now has a commit upstream:
> > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=8af36117e23bc36c34d0d25484f7b9de021b51bc
> >
> > This commit is in the linux-backports-modules-nouveau package in xorg-
> > edgers that will be built soon; Scott, would it be possible for you to
> > test that the packages in xorg-edgers fix this for you?
> >
> The package fixes it for me provided desktop effects aren't enabled; if
> desktop effects are enabled, then I get a corrupted screen within X.

Yeah, 3D is a bit of a mixed bag. Which is why it's not shipped in
Lucid :).

>
> (So yes, the patch works as intended, it's the other patches in
> xorg-edgers that break it again :p)

Excellent. Thanks for checking.

Andy Whitcroft (apw) wrote :

@Scott -- I have pulled this back to the lucid kernel, could you test these ones and report back here:

    http://people.canonical.com/~apw/lp539730-lucid/

On Thu, 2010-04-08 at 11:52 +0000, Andy Whitcroft wrote:

> @Scott -- I have pulled this back to the lucid kernel, could you test
> these ones and report back here:
>
> http://people.canonical.com/~apw/lp539730-lucid/
>
Worked fine once I purged the tendrils of xorg-edgers from the system

Scott
--
Scott James Remnant
<email address hidden>

Andy Whitcroft (apw) on 2010-04-13
Changed in linux (Ubuntu):
status: Triaged → In Progress
status: In Progress → Fix Committed
milestone: ubuntu-10.04-beta-2 → ubuntu-10.04
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.32-21.31

---------------
linux (2.6.32-21.31) lucid; urgency=low

  [ Andy Whitcroft ]

  * allow modules.builtin to be optional
  * d-i: add mpt2sas to the message-modules udeb
    - LP: #530361

  [ Christopher James Halse Rogers ]

  * SAUCE: Nouveau: Add quirk framework to disable acceleration
    - LP: #544088, #546393
  * SAUCE: Nouveau: Disable acceleration on MacBook Pros
    - LP: #546393
  * SAUCE: Nouveau: Disable acceleration on GeForce3 cards
    - LP: #544088
  * SAUCE: Nouveau: Disable acceleration on 6100 cards
    - LP: #542950

  [ Stefan Bader ]

  * SAUCE: dma-mapping: Remove WARN_ON in dma_free_coherent
    - LP: #458201

  [ Surbhi Palande ]

  * SAUCE: sync before umount to reduce time taken by ext4 umount
    - LP: #543617

  [ Upstream Kernel Changes ]

  * tipc: Fix oops on send prior to entering networked mode (v3)
    - CVE-2010-1187
  * KVM: x86 emulator: Add Virtual-8086 mode of emulation
    - LP: #561425
  * KVM: x86 emulator: fix memory access during x86 emulation
    - LP: #561425
  * KVM: x86 emulator: Check IOPL level during io instruction emulation
    - LP: #561425
  * KVM: x86 emulator: Fix popf emulation
    - LP: #561425
  * KVM: Fix segment descriptor loading
    - LP: #561425
  * KVM: VMX: Update instruction length on intercepted BP
    - LP: #561425
  * KVM: VMX: Use macros instead of hex value on cr0 initialization
    - LP: #561425
  * KVM: SVM: Reset cr0 properly on vcpu reset
    - LP: #561425
  * KVM: VMX: Disable unrestricted guest when EPT disabled
    - LP: #561425
  * KVM: x86: disable paravirt mmu reporting
    - LP: #561425
  * AppArmor: Fix put of unassigned ns if aa_unpack fails
  * AppArmor: Fix refcount bug when exec fails
    - LP: #562063
  * AppArmor: Take refcount on cxt->profile to ensure it remains a valid
    reference
    - LP: #367499
  * AppArmor: fix typo in scrubbing environment variable warning
    - LP: #562060
  * AppArmor: fix regression by setting default to mediate deleted files
    - LP: #562056
  * AppArmor: fix refcount order bug that can trigger during replacement
    - LP: #367499
  * AppArmor: Make sure to unmap aliases for vmalloced dfas before they are
    live
    - LP: #529288
  * AppArmor: address performance regression of replaced profile
    - LP: #549428
  * AppArmor: make the global side the correct type
    - LP: #562047
  * AppArmor: use the kernel shared workqueue to free vmalloc'ed dfas
  * sky2: add register definitions for new chips
    - LP: #537168
  * sky2: 88E8059 support
    - LP: #537168
  * net: Fix Yukon-2 Optima TCP offload setup
    - LP: #537168
  * net: Add missing TST_CFG_WRITE bits around sky2_pci_write
    - LP: #537168
  * sky2: print Optima chip name
    - LP: #537168
  * (Upstream) dell-laptop: defer dell_rfkill_update to worker thread
    - LP: #555261
  * drm/nv40: add LVDS table quirk for Dell Latitude D620
    - LP: #539730
 -- Andy Whitcroft <email address hidden> Tue, 13 Apr 2010 18:50:58 +0100

Changed in linux (Ubuntu):
status: Fix Committed → Fix Released

This has been confirmed fixed for a while with commit 2eb92c80074ecfbc691741720382007417f64523.

Changed in nouveau:
importance: Unknown → Medium
status: Confirmed → Fix Released
Changed in nouveau:
importance: Medium → Unknown
Changed in nouveau:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.