Xen + nouveau + modeset = corrupted console

[Simon Déziel]

When running the latest Precise kernel under the latest Xen, the console is corrupted on boot. This does not occur when booting the kernel directly (no Xen) or when booting under Xen but using "nomodeset".

The affected box is a Compaq Presario 6450nx with latest BIOS and a freshly installed (yesterday) daily image of the server version. The kernels 3.2.0-8.15 and 3.2.0-9.16 are affected.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-9-generic-pae 3.2.0-9.16
ProcVersionSignature: Ubuntu 3.2.0-9.16-generic-pae 3.2.1
Uname: Linux 3.2.0-9-generic-pae i686
AlsaDevices:
 total 0
 crw-rw---T 1 root audio 116, 1 Jan 16 09:30 seq
 crw-rw---T 1 root audio 116, 33 Jan 16 09:30 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 1.90-0ubuntu2
Architecture: i386
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
Date: Mon Jan 16 09:32:58 2012
HibernationDevice: RESUME=UUID=ee1f9ff2-4e24-4963-a8c1-fa8e482cc4fd
InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Alpha i386 (20120115)
IwConfig: Error: [Errno 2] No such file or directory
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Compaq Presario 06 DA238A-ABA 6450NX NA911
PciMultimedia:

ProcEnviron:
 LANGUAGE=en_CA:en
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: placeholder root=/dev/mapper/vg0-root ro
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-9-generic-pae N/A
 linux-backports-modules-3.2.0-9-generic-pae N/A
 linux-firmware 1.67
RfKill: Error: [Errno 2] No such file or directory
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/23/2003
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 3.25
dmi.board.name: MS-6577
dmi.board.vendor: MICRO-STAR INTERNATIONAL CO., LTD
dmi.board.version: 020
dmi.chassis.type: 3
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr3.25:bd09/23/2003:svnCompaqPresario06:pnDA238A-ABA6450NXNA911:pvr0n81411RE101XENO3:rvnMICRO-STARINTERNATIONALCO.,LTD:rnMS-6577:rvr020:cvn:ct3:cvr:
dmi.product.name: DA238A-ABA 6450NX NA911
dmi.product.version: 0n81411RE101XENO3
dmi.sys.vendor: Compaq Presario 06

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . If possible, please test the latest v3.2 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed by the mainline kernel, please add the following tag 'kernel-fixed-upstream-KERNEL-VERSION'. For example, if kernel version 3.2-rc1 fixed the issue, the tag would be: 'kernel-fixed-upstream-v3.2-rc1'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. If you believe this bug does not require upstream testing, please add the tag: 'kernel-upstream-testing-not-needed'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[Simon Déziel (sdeziel)]

The kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2.1-precise/linux-image-3.2.1-030201-generic-pae_3.2.1-030201.201201121644_i386.deb is also affected.

simon@xen:~$ uname -a
Linux xen 3.2.1-030201-generic-pae #201201121644 SMP Thu Jan 12 22:01:33 UTC 2012 i686 i686 i386 GNU/Linux
simon@xen:~$ cat /proc/cmdline
placeholder root=/dev/mapper/vg0-root ro

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Simon Déziel (sdeziel)]

3.2.0-10-generic-pae is also affected

[Joseph Salisbury (jsalisbury)]

@Simon,

The latest 3.3-rc1 kernel is now available. Could you test this kernel and report if it is also affected by this issue? The 3.3-rc1 kernel is available at:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc1-precise/

[Simon Déziel (sdeziel)]

@Joseph, linux-image-3.3.0-030300rc1-generic-pae_3.3.0-030300rc1.201201191835_i386.deb does not fix the problem.

[Joseph Salisbury (jsalisbury)]

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

[Simon Déziel (sdeziel)]

@Joseph, https://bugzilla.kernel.org/show_bug.cgi?id=27942 mentions similar screen corruption. Could you look at it and tell me if it would be more appropriate to open a separated bug for my problem ? Thanks.

[Konrad Rzeszutek Wilk (konrad-wilk)]

Your card is AGP right? This patchset: https://lkml.org/lkml/2010/12/6/464 fixes it but I haven't gone back to that patch set since I figured nobody uses AGP anymore :-(

[Simon Déziel (sdeziel)]

@Konrad, thanks, that really looks like you spotted (and fixed) the problem.

I haven't tested your patch as I understand that my AGP card is quite old and I would not want to maintain a patched kernel just to be able to use it with KMS. My Xen box is a P4 and it's quite possible that not many users are still using hardware from that generation. If however, Ubuntu wants to integrate that patch I will happily test it.

[Joseph Salisbury (jsalisbury)]

@Konrad, thanks for posting the link to the patch.

@Simon, Most folks would ask why the kernel team doesn't just apply the patch and fix it. The reason is that the kernel team is reluctant (not opposed) to apply any patch to a kernel that is not from upstream. Applying patches that don't come from upstream add greatly to the support of the kernel as other upstream patches may touch the same area as the non-upstream patch and may prevent them from applying cleanly.

[Simon Déziel (sdeziel)]

Joseph, I totally understand the kernel team's position on this. As far
as I'm concerned, this could be marked as "won't fix". Thanks for the
clarification though.

On 12-01-24 03:44 PM, Joseph Salisbury wrote:
> @Simon, Most folks would ask why the kernel team doesn't just apply the
> patch and fix it. The reason is that the kernel team is reluctant (not
> opposed) to apply any patch to a kernel that is not from upstream.
> Applying patches that don't come from upstream add greatly to the
> support of the kernel as other upstream patches may touch the same area
> as the non-upstream patch and may prevent them from applying cleanly.

[Joseph Salisbury (jsalisbury)]

Konrad, do you know if the patches mentioned in comment #10 will be applied to any of the upstream stable kernels?

[Konrad Rzeszutek Wilk (konrad-wilk)]

Joseph, sorry for the delay - I am somehow not getting email updates on bugs that I've commented on.

So applying the patches requires them to be upstream - and while Dave Airlie had not trouble with them, he did suggest to concentrate on PCIe/PCI subset.

Anyhow, I can dust them off and start respining them for upstream - but the issue I forsee is more of testing. The patches rework the AGP API code and to make sure that it does not impact negatively older platforms I should do due diligence and test them (for regressions). I have some of the AGP chipset motherboards (nvidia, intel, sisworks, and via), but I lack the really weird ones - like SGI ZX1 chipset or the Transmeta boxes. Perhaps if somebody has them laying around I can do this but without that hardware in hand there is a risk..