vesa driver freezes on VIA P4M900

Please don't assign bugs to people without their consent.

Sorry, I had no idea he actually had asked you to do it :)

Thanks Tormod, I had asked Torsten to assign it to me in this case; I'll make sure to let people know they need to mention I gave permission for assigning the bug.

there is some known problems with hpet timer. please take a look at

cat /proc/timer_list | grep "Clock Event Device"

if hpet is enabled you should try to disable it with kernel option:
hpet=disable

other suggestion is dyntics, enabled in new 2.6.22 kernel

so try to boot with this too:
nohz=disable

hpet is not enabled and adding 'nohz=disable' does not affect the freeze behaviour.

Ok... let see

Please reed this
https://wiki.ubuntu.com/DebuggingKernelSuspend

it will explain you how to get more debug info we need. If you still
have a questions feel free to ask.

Regards,
Alex

The problem reported is not primarily a suspend problem, but a freeze of the graphics system.

ehh... yes i know...
the problem is, kernel can't take response for all graphiccard workarounds and broken vBIOSes... so in this case exist usersapce software which try according whitelist resume your PC. see this post: http://bugzilla.kernel.org/show_bug.cgi?id=7225

on other hand not all problems with graphic are problem of acpi-workarounds or xorg. With new Ubuntu Gutsy we have kernel with enabled NOHZ and HPET by default ... what made my PC to freeze on resume.

To check if it [ xorg , apci-workaround ] or kernel you need go to console, stop xorg and try supend/resume you PC.

Regards,
Alex

The freeze of the graphics system occurs completely independent from resume.

The daily live for Hardy from 2008-02-15 basically works, but the desktop area is set to large. The Xorg.0.log of the install session is attached.

This part looks relevant to me:

(II) CHROME(0): Configured Monitor: Using default hsync range of 31.50-37.90 kHz
(II) CHROME(0): Configured Monitor: Using default vrefresh range of 50.00-70.00 Hz
(WW) CHROME(0): Unable to estimate virtual size
(II) CHROME(0): Attempting to use 60Hz refresh for mode "800x600" (115)
(II) CHROME(0): Attempting to use 60Hz refresh for mode "640x480" (112)
(--) CHROME(0): Virtual size is 1920x1200 (pitch 1920)

When forcing the system to a bullet proof X session the vesa driver will still freeze the graphics.

Torsten, if this is still happening on hardy-beta, would you be able to get a backtrace for us for the freeze?

See: https://wiki.ubuntu.com/DebuggingXorg

Attached is the Xorg.0.log. The X server seems to die completely:

ubuntu@ubuntu:/var/log$ ps aux | grep X
root 7996 0.0 0.2 3408 1188 ? S 13:46 0:00 hald-addon-storage: no polling because /dev/hda is locked via O_EXCL
ubuntu 10336 0.0 0.1 3004 744 pts/1 R+ 14:14 0:00 grep X

There is one zombie process:
root 10230 0.0 0.0 0 0 ? Z 14:09 0:00 [kill] <defunct>

ubuntu@ubuntu:/var/log$ ps -elf | grep 10226
5 T root 10226 8124 0 80 0 - 3516 - 14:09 ? 00:00:00 /usr/sbin/gdm
4 Z root 10230 10226 0 80 0 - 0 - 14:09 ? 00:00:00 [kill] <defunct>

The dialogue box with the question if it is ok to start X in low
graphics mode is the last one.

This test was run directly from the beta live CD.

After installing and updating Hardy, the X server continues to run and
gdb can be attached to the process:

(gdb) bt full
#0 0xb7faf410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7df973d in select () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2 0x081b2225 in WaitForSomething (pClientsReady=0xbfe4c810)
    at ../../os/WaitFor.c:236
        client_priority = <value optimized out>
        client_index = <value optimized out>
        highest_priority = <value optimized out>
        i = <value optimized out>
        waittime = {tv_sec = 94, tv_usec = 176000}
        wt = (struct timeval *) 0xbfe4c7d0
        timeout = <value optimized out>
        clientsReadable = {fds_bits = {0 <repeats 32 times>}}
        clientsWritable = {fds_bits = {137307688, 137307905,
-1075525912,
    137307680, 137292440, 136163204, -1075525880, 137301840,
-1209573044, 32,
    -1209687072, -1210494255, 137307688, 136163204, -1075525752,
134725985,
    137307688, -1075525800, 1, 137297328, 137307688, 48, -1209687072,
    135860875, 137284224, -1209577484, -1209573056, 137301848,
-1075525768,
    -1210477600, -1209573056, 137301848}}
        curclient = <value optimized out>
        selecterr = 104
        nready = <value optimized out>
        devicesReadable = {fds_bits = {-1209573024, -1075525988,
-1209687172,
    135372057, 0, 136443240, 136440576, 137307680, 137307688, 24,
-1209687072,
    135372215, 137307688, -1210477600, 1, -1208302704, 136443240,
-1209577484,
    -1209573056, 137292440, -1075525928, 137307840, -1209573056,
137292440,
    137307688, -1209577484, -1209573056, 137307688, -1075525896,
-1210477600,
    -1209573056, -1210494255}}
        now = 90164
        someReady = 0
#3 0x0808d69d in Dispatch () at ../../dix/dispatch.c:425
        result = <value optimized out>
        client = (ClientPtr) 0x82efdb8
        nready = -1
        start_tick = 0
#4 0x0807471b in main (argc=11, argv=0xbfe4cd44, envp=0x0)
    at ../../dix/main.c:452
        pScreen = <value optimized out>
        i = 1
        error = 136163204
        xauthfile = <value optimized out>
        alwaysCheckForInput = {0, 1}

And here is what happens after the kill of the X server:

(gdb) cont
Continuing.

Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0xb7c8ba30 (LWP 5617)]
0xb7faf410 in __kernel_vsyscall ()
(gdb)
Continuing.

Program received signal SIGTERM, Terminated.
0xb7faf410 in __kernel_vsyscall ()
(gdb) bt full
#0 0xb7faf410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7df91d8 in writev () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2 0x081bcabe in _XSERVTransSocketWritev (ciptr=0x82ec850,
buf=0xbfe4c784,
    size=1) at /usr/include/X11/Xtrans/Xtranssock.c:2192
No locals.
#3 0x081bb72f in _XSERVTransWritev (ciptr=0x82ec850, buf=0xbfe4c784,
size=1)
    at /usr/include/X11/Xtrans/Xtrans.c:914
No locals.
#4 0x081b6666 in FlushClient (who=0x82eeb50, oc=0x82ec150,
extraBuf=0x0,
    extraCount=0) at ../../os/io.c:1060
        before = <value optimized out>
        remain = -1075525756
        i = 1
        len = <value optimized out>
        oco = (ConnectionOutputPtr) 0x8317670
        connection = 10
        trans_conn = (XtransConnInfo) 0x82ec850
        iov = {{iov_base = 0x8319b48, iov_len = 32}, {iov_base =
0x8092eb8,
    iov_len = 137292624}, {iov_base = 0x20, iov_len = 3219441640}}
        written = 0
        padsize = 0
        notWritten = 32
        todo = 32
        padBuffer = "\000\000"
#5 0x081b7054 in FlushAllOutput () at ../../os/io.c:812
        index = <value optimized out>
        mask = 0
        oc = (OsCommPtr) 0x82ec150
        client = (ClientPtr) 0x82eeb50
        newoutput = <value optimized out>
#6 0x0808d915 in Dispatch () at ../../dix/dispatch.c:524
        result = 136353016
        client = (ClientPtr) 0x82eeb50
        nready = 0
        start_tick = 0
#7 0x0807471b in main (argc=11, argv=0xbfe4cd44, envp=0x8092eb8)
    at ../../dix/main.c:452
        pScreen = <value optimized out>
        i = 1
        error = 136163204
        xauthfile = <value optimized out>
        alwaysCheckForInput = {0, 1}

Confirmed. I've been having this problem since Feisty and not resolved in Hardy.

In addition, xrandr reports incorrect resolutions and I can't run displayconfig-gtk even after logging in successfully into gnome. As this may involve separate bugs I'll report several bugs and link them appropriately.

I'm willing to provide more info, and prefer the ones that don't involve lock ups or reboots heheh ;)

$ sudo lspci -vv
00:00.0 Host bridge: VIA Technologies, Inc. P4M900 Host Bridge
 Subsystem: VIA Technologies, Inc. P4M900 Host Bridge
 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
 Region 0: Memory at c0000000 (32-bit, prefetchable) [disabled] [size=128M]
 Capabilities: [80] AGP version 3.5
  Status: RQ=8 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3+ Rate=x4,x8
  Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:00.1 Host bridge: VIA Technologies, Inc. P4M900 Host Bridge
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0

00:00.2 Host bridge: VIA Technologies, Inc. P4M900 Host Bridge
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0

00:00.3 Host bridge: VIA Technologies, Inc. P4M900 Host Bridge
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0

00:00.4 Host bridge: VIA Technologies, Inc. P4M900 Host Bridge
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0

00:00.5 PIC: VIA Technologies, Inc. P4M900 I/O APIC Interrupt Controller (prog-if 20 [IO(X)-APIC])
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0, Cache Line Size: 32 bytes

00:00.6 Host bridge: VIA Technologies, Inc. P4M900 Security Device
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0, Cache Line Size: 32 bytes

00:00.7 Host bridge: VIA Technologies, Inc. P4M900 Host Bridge
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0

00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Brid...

Sorry. DE-confirmed the problem.

It seems the vesa is OK when enabled manually. i.e. in Ubuntu Hardy, editing the xorg.conf file and: adding Driver "vesa"

In my Ubuntu Hardy, system freezes crashed loading the automatically detected xorg driver which to this point is still unknown (openchrome?)

Right now I enable vesa driver manually and it works OK though screen resolution is wrong
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vesa/+bug/223920

Sorry for misinforming.

Hendy, can you please attach your Xorg.0.log and xorg.conf files from both cases - when enabling manually, and when using the automatically detected driver.

@Torsten, thanks for collecting the backtraces. There isn't an obvious error jumping out to me, but I've gone ahead and forwarded this bug upstream. I don't know if many people upstream look at -vesa / VIA bugs, but maybe we'll be lucky. Perhaps the additional data from Hendy could help narrow down things more.

Symptoms I get with my configuration: (VIA P4M900 + VIA Chrome9 IGP)
1. I can't even get a working framebuffer without adding vga=791 on grub. This also happens even in the alternate Hardy install CD. (which means I need to add vga=791 when installing Ubuntu) (bug report pending)
2. xorg autodetects openchrome driver in Hardy, but giving a blank screen, probably due to screen resolution or refresh rate or frozen (bug report pending)
3. when vesa is chosen manually in xorg.conf, I can login just fine FIRST TIME only. screen resolution 1024x768 is not needed (bug #223920)
4. I can't switch to console (Ctrl+Alt+F1), doing so giving me some kind of aura-cloudy-rainbow in my LCD, and I'm *very* worried about that (bug report pending)
5. I don't want to logout, because after I logout I can't go back in. I can hear GDM sound, but GDM is not visible. I call this situation is system freeze. (THIS BUG)

Attached is my xorg log using vesa on first login. (I can't logout because my system won't be usable past that point)

Ubuntu Interpid 8.10

I have a AMD 64 + ASUS K8V-VM

01:00.0 VGA compatible controller: VIA Technologies, Inc. K8M890CE/K8N890CE [Chrome 9] (rev 11)

System hard locks when booting from live cd at the start of gdm. I have to pass xforcevesa in the grub menu. It does not lock after that - but there is a lot of flickering on the screen. I managed to somehow nagivate to screen resoultion settings and changed it to 800x600 to get it working.

At last P4M9000 is working in jaunty alfa5 :-)

In Intrepid I could get it to work by using the common procedure found around the net (and in ubuntu wiki):

Set "Driver" to "openchrome" and add option "XaaNoImageWriteRect" to xorg.conf.
In earlier jaunty versions I could only avoid it freeze by adding option "NoAccel".

etrusco, thanks for testing on jaunty and letting us know the issue is resolved.
Torsten, can you confirm the issue as fixed for you as well?

I'm going to assume this is resolved now

This is well known and already resolved openchrome bug.

More detail is available at:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-openchrome/+bug/274340