Intrepid Alpha 5, HP Mininote 2133, Live CD, X Server Hangs after Boot

I am also seeing this problem on the Alpha5 build of Intrepid with Kubuntu. The system is usable for a few minutes then it hangs. I have been unable to get any logs of what the xserver is doing as there are no virtual terminals available when it crashes.

(Update from bug originator)

I tried the Intrepid Alpha 6 and got the same result. The X server hangs shortly after blanking the screen and putting up the initial mouse cursor.

I'm currently running the VIA proprietary drivers on Ubuntu Hardy. That, plus the original VESA X.org drivers worked OK on this HP-2133 Mininote laptop. I'm including some of the output from the Xorg.0.log file on Hardy to better document the chipset, etc, within this laptop:

(II) Module vbe: vendor="X.Org Foundation"
        compiled for 1.4.0.90, module version = 1.1.0
        ABI class: X.Org Video Driver, version 2.0
(II) VIA(0): VESA BIOS detected
(II) VIA(0): VESA VBE Version 3.0
(II) VIA(0): VESA VBE Total Mem: 32768 kB
(II) VIA(0): VESA VBE OEM: VIA N3364^M

(II) VIA(0): VESA VBE OEM Software Rev: 1.0
(II) VIA(0): VESA VBE OEM Vendor:
(II) VIA(0): VESA VBE OEM Product:
(II) VIA(0): VESA VBE OEM Product Rev:
(II) VIA(0): MapBase = b78d2000, MmioBase=fc000000
(II) VIA(0): RegCR08 = 0, RegCR09=4f
(--) VIA(0): Chipset: "P4M900"
(--) VIA(0): Chipset Rev.: 0
(**) VIA(0): Option "ActiveDevice" "LCD,CRT"
(**) VIA(0): Option "DisplayHardwareLayout" "LCD"
(**) VIA(0): Option "PanelID" "3"
(**) VIA(0): Option "NoDDCValue"
(**) VIA(0): Option "VideoOnDevice" "LCD"
(**) VIA(0): Option "ForceLCD"
(==) VIA(0): Not using video BIOS to set modes
(**) VIA(0): Option: Not using DDC probed value to set HorizSync & VertRefresh
(II) VIA(0): MergedFB mode forced off.
(**) VIA(0): Active Device is LCD,CRT.
(**) VIA(0): Display Hardware Layout is LCD

(--) VIA(0): mapping framebuffer @ 0xd0000000 with size 0x8000000
(==) VIA(0): Write-combining range (0xd0000000,0x8000000)
(--) VIA(0): Frame buffer start: 0xaf64d000, free start: 0x3c0000 end: 0x800000\
0
(--) VIA(0): mapping MMIO @ 0xfc000000 with size 0x9000
(--) VIA(0): mapping BitBlt MMIO @ 0xfc200000 with size 0x200000
(II) VIA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(EE) VIA(0): Couldn't open "/dev/video2"
(II) VIA(0): VIAScreenInit : V4L Disabled : fd2 = -1
(II) VIA(0): [drm] Detect H5s1 chipset: 000a chipid: 3371

I can get more data on request.

The Hp-2133 needs the boot option

  acpi_os="!Windows 2006"

to run Hardy correctly. (I don't why but its documented in the Ubuntu mininote forum at http://ubuntuforums.org/showthread.php?t=749693). I manually added this to the boot command line prior to booting the 'test drive without installing' boot option.

This had NO effect. The X server still hung as described earlier.

I repartitioned my HP 2133's disk when it first arrived to support two root file systems. I cloned my working Hardy root file system from one '/' to the other and then ran a dist-upgrade to convert that to Intrepid Alpha 6. This was successful so I can now run experiments on the X server.

The first boot into X resulted in a low-resolution, degraded, X configuration. A dialog box (I don't recall the details) let me select the 'default' X configuration. This bricked my X installation just like described above. I tried 'repairing' it a couple times in recovery mode to no avail.

I then found and copied /etc/X11/xorg.conf.failsafe to /etc/X11/xorg.conf. This works correctly, but slowly. I diff'ed the original 'default' xorg.conf file and the failsafe file uses:

driver "vesa"

where the original default config file leaves this blank. (I'm guessing X tries to auto-configure).

I guess this auto-configuration code is guessing the wrong type of video chip set? This laptop uses a VIA Chrome9 chip that isn't exactly mainstream.

I've taken this a long way towards resolution by providing a platform to repro this failure and actually get some results. If there's more I can do then please let me know.

Meanwhile, I'm going to see if the OpenChrome server is available for Intrepid.

0.2.903 should support the Mininote, it'll be uploaded before too long.

This bug was fixed in the package xserver-xorg-video-openchrome - 1:0.2.903-0ubuntu1

---------------
xserver-xorg-video-openchrome (1:0.2.903-0ubuntu1) intrepid; urgency=low

  * New upstream release. (LP: #268546)
  * Enhancements and bug fixes:
    - Simplify memory bandwidth setting.
    - Fix compilation without EXA.
    - Fix interpolation for CN400.
    - Fix Xv on LCD for K8M890 and CX700.
    - Disable XvDMA for P4M890 and K8M890, it is broken...
    - Replace xf86strstr by the unwrapped version.
    - Fix chipset revision detection in libpciaccess code path.
    - Print driver version in the libpciaccess code path.
  * New boards:
    - Biostar P4M890-M7 TE,
      ECS CLE266,
      FIC CE261,
      Foxconn P4M9007MB-8RS2H,
      Hewlett Packard 2133 Mini-Note (LP: #267115),
      KamLAB KINO-LUKE-533-R20,
      Mercury P4VM800M7,
      MSI K9MM-V,
      MSI VR321,
      PCChips (unknown model),
      Samsung Q1B.
  * Copy src/openchrome.man from the previous version. It got dropped
    from the tarball for some reason.

 -- Timo Aaltonen <email address hidden> Wed, 24 Sep 2008 15:12:50 +0300

The new openchrome xserver did not help. I updated and then ran several experiments, all with the same result:

1) 'Default" xorg.conf with no driver selection,
2) xorg.conf with explicit 'driver "openchrome"' selection
3) xorg.conf with explicit:

    driver "openchrome"
    options "EnableAGPDMA" "0"

   (I found a note someplace that this would help).

I verified the correct openchrome driver was installed using 'dpkg-query -s xserver-xorg-video-openchrome'. It reports version 1:0.2.903-0ubuntu2.

I've been trolling through /var/log/kern.log and /var/log/messages and I noticed that the last message emitted by Linux before the crash is always:

  [drm] Initialized drm 1.1.0 20060810

I looked around in LP for other DRM bugs but I don't see one that matches this failure mode. (Doesn't mean its not there, its just not obvious to me).

It's also possible this was the last successful operation and that its unrelated. I tried 'modprobe drm' while on the console in recovery mode (prior to starting X) and it loaded the drm kernel module w/o error. I also ran 'modprobe via' to load the kernel/drivers/gpu/drm/via/via.ko module and that also worked.

I'm out of ideas about where to look next...

What if you add 'Option "DRI" "false"'?

No change with 'Option "DRI" "false"'. Still locks up with openchrome.

FWIW, the openchrome driver included in Hardy works OK with on the Mininote.

Note, I normally don't use that and instead use the VIA proprietary drivers. Unfortunately, those are locked to one kernel version so have to 'hold' the kernel to prevent a kernel update from breaking the video driver. I want to get away from that in Intrepid.

Last, I booted the Hardy kernel (2.6.24-16) but mounted the Intrepid '/' file system. The 'vesa' driver works but the 'openchrome' driver still fails.

I hope you don't have anything related to the via proprietary driver in the intrepid partition, since it could break things.

A logfile with the current openchrome would be nice.

Here's the Xorg.0.log from Hardy running the openchrome video driver...

I may have debris left from the VIA proprietary driver on my Intrepid partition because I created it by copying a working Hardy install, with the VIA driver, and then upgrading it to Intrepid.

However, I don't think that's adding to this problem because I first encountered this problem trying to run the Intreprid Live CD. I did the upgrade just to provide a workable debugging environment.

And, it really shouldnb't matter which drivers are on the disk if I explicitly select one using the 'Driver' statement in the xorg.conf. (I could believe that auto-config may get confused but an explicit driver selection should take precedence).

i'm having a similar problem on a k8m800 based laptop, even with the actual driver.
what i see:
- with default xorg.conf: "busy" cursor off-center, hanging after some seconds, laptop frozen
- with "openchrome" specified in xorg.conf: idem
- with "vesa" specified in xorg.conf: idem
- with "openchrome" and resolution 1024x768 specified: "busy" cursor centered freezing after some seconds, a light shade of the gdm-screen (i can discern the username entry field), i can hear the gdm drums sound; if i move the mouse (touchpad) it draws a new frozen "busy" cursor somewhere else on the screen, not deleting the first one; there is also response to setting caps-lock on the keyboard: the led will go on after more than a minute.
- with "vesa" and resolution specified: works smoothly.

i tried setting the following options one by one, which didn't solve the problem:
 Option "AccelMethod" "EXA"
 Option "DRI" "false"
 Option "EnableAGPDMA" "0"

i attach my xorg.conf, xorg.0.log and a file kern.log with the last lines of kern.log

I think this is the same issue I have, with my ASUS Pundit P2-AE2 w/ unichrome video (logged as Bug #274340)

I could fix it with Option "NoAccel", but it's pretty slow now.

It really sucks cause hardy worked fine.

Option "NoAccel" fixes the freezes for me but it's incredibly slow. it's indeed a regression from hardy.

I can confirm Georg's note about 'Option "NoAccel"'. It prevents the freeze but its then so slow that you may as well use the VESA driver.

I originally noted in this bug that the cursor is off-center (down and to the right) on my mini-note before it freezes. If I use NoAccel then X comes up but the virtual desk top is TOO BIG. If I had to guess, its something like 1440x900 or 1680x1050. So, there's also a problem detecting the LCD screen resolution.

I added:

  SubSection "Display"
    Virtual 1280 768
  EndSubSection

to the 'screen' section of the xorg.conf file. After rebooting, I had a properly sized display. (FWIW, using 'Option "ForcePanel"' did not detect the screen size correctly. I had to force the virtual desktop size).

Ever the optimist, I then enabled acceleration (commented out the option noaccel) with the explicitly sized virtual desktop. But, after rebooting, the X server still hangs with the one difference being the mouse cursor is in the center of the screen. I guess that counts as progress ;-)

this bug report and bug #274340 should be merged, as they describe the same problem. is this an upstream bug or an ubuntu bug? i couldn't find an active ticket on openchrome.org that reports this problem, yet i'm not a technician to be absolutely sure on that.

I experienced the same symptoms described by the original poster with Ubuntu 8.10 on my HP 2133. The problem was fixed by replacing xorg.conf with the sample one provided at https://wiki.ubuntu.com/LaptopTestingTeam/HP2133 (section Video Driver Fix).