login
Search
When I boot this kernel, everything seems okay, but after I leave the machine for 30 minutes or so, I come back and find the machine locked up. When I checked my log file after rebooting, I find the log filled with "trying to get vblank count for disabled pipe 0". 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) Subsystem: Gateway 2000 Unknown device 0366 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 Region 0: Memory at d8180000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] 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: 86 80 a6 27 07 00 90 00 03 00 80 03 00 00 80 00 10: 00 00 18 d8 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7b 10 66 03 30: 00 00 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 May 4 14:40:44 whirligig kernel: [ 47.544109] ALSA sound/pci/hda/hda_codec.c:716: hda_codec_setup_stream: NID=0x12, stream=0x5, channel=0, format=0x4011 May 4 14:40:46 whirligig kernel: [ 48.850489] trying to get vblank count for disabled pipe 0 May 4 14:40:46 whirligig kernel: [ 48.897990] trying to get vblank count for disabled pipe 0 May 4 14:40:46 whirligig kernel: [ 48.941691] trying to get vblank count for disabled pipe 0 May 4 14:40:46 whirligig kernel: [ 49.003556] trying to get vblank count for disabled pipe 0 May 4 14:40:46 whirligig kernel: [ 49.147880] trying to get vblank count for disabled pipe 0 May 4 14:40:47 whirligig kernel: [ 50.528654] trying to get vblank count for disabled pipe 0 [...] May 4 15:36:23 whirligig kernel: [ 3404.847515] ALSA sound/pci/hda/hda_codec.c:728: hda_codec_cleanup_stream: NID=0xe May 4 16:06:53 whirligig kernel: [ 5241.488711] trying to get vblank ...
Define 'locked up'. Can you ping it? Can you log in via ssh? Is the X Note that some of these are for pipe 1 as well as pipe 0. Does the problem only occur for one of them? Do you have any GL apps running when this happens? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer --
Miles isn't alone, I also get 'trying to get vblank count for disabled pipe 0' (GM965). vblank interrupts were previously not working for me, For me, this happens every time a GL app is run. I'm also getting occasional lockups. Often it's the window manager (metacity) that locks up when attempting to move a window, restarting the window manager unlocks X but attempting to move a window again results in another lockup. When it's locked up the pointer moves and vt switching works but nothing else. Other times I've had a hard lockup that required a hard reboot, this happens less frequently. --
OK I know what changed. The DRM in the kernel has working vblank but it still produces the "disabled" warning in the kernel log. git DRM produces ~1 fps with sync to vblank enabled. Seems the vblank interrupt isn't getting enabled in the git DRM, but the warning message is actually unrelated. --
Actually I had a patch from my previous attempt to fix this still applied to my git-drm. Now reverted git-drm is behaving identically to the linux kernel DRM. vsync is working but the disabled pipe warning is produced. --
As written in a mail before, I have similar issues. I had the vblank messages in 2.6.25-git17 or so, but they seem gone no. At that time, I also had lockups, mostly when switching back from a vt to X. I was still able to move the mouse, but the rest of the screen just didn't change anymore. SSH login was still possible, so I tried to restart the X server, but that did nothing. Although the X processes were finished, I still had the X surface on my display, what seems rather strange to me. By now situation has improved a bit, as the machine doesn't lockup anymore. But from time to time I still get windows where only the outer frame is shown, the contents of the window is transparent. I have the impression that suspend/hibernation worsens the problems (no proof though). My graphics is a gm965 and I'm using gnome with the new compositing-able metacity used in ubuntu 8.04.
That sounds like an input related X server bug, probably not related to the original problem. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer --
On Mon, May 5, 2008 at 4:15 AM, Michel Dänzer
I don't know if I can ping the machine. I can work on finding that
out. I don't have an ssh server running, but can try that. I can't
I just checked my dmesg output and found this:
[ 7196.890661] trying to get vblank count for disabled pipe 0
[ 7258.233274] trying to get vblank count for disabled pipe 1
[ 7258.233963] trying to get vblank count for disabled pipe 1
[ 7261.219671] trying to get vblank count for disabled pipe 0
[ 7261.234483] trying to get vblank count for disabled pipe 0
So, since I am still using this boot session and haven't noticed
anything lock up, it seems that getting either of these messages is
not necessarily the indicator of what is keeping my screen black after
the display has gone to sleep. I have not let the display go to sleep
yet during this boot session, so I don't know what will happen when it
does. I suspicion is that this is the trigger condition.
Miles
--
I put these messages in there to warn us when Mesa asks for an invalid vblank count. It would be good to figure out why the DRM driver is getting called to retrieve the vblank count for a pipe that *should* be disabled... Jesse --
