Bug 20481 - [KMS] screen freeze on VT change and vblank errors on sony vaio SR19XN
Summary: [KMS] screen freeze on VT change and vblank errors on sony vaio SR19XN
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium critical
Assignee: Jesse Barnes
QA Contact: Xorg Project Team
Keywords: NEEDINFO
Depends on:
Reported: 2009-03-05 02:21 UTC by Giovanni Pellerano
Modified: 2017-07-24 23:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

dmesg (110.88 KB, text/plain)
2009-03-07 00:16 UTC, Giovanni Pellerano
no flags Details
xorg log with modeset=1 (14.07 KB, text/plain)
2009-03-07 00:20 UTC, Giovanni Pellerano
no flags Details
xorg log with modeset=0 (42.60 KB, text/plain)
2009-03-07 00:21 UTC, Giovanni Pellerano
no flags Details

Description Giovanni Pellerano 2009-03-05 02:21:23 UTC
I got screen freeze on VT change and on X restart;

i also get some strange debug messages:

do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.

in dmesg every second i got this message repeated:
[drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22

i'm using xorg-server 1.5.3 and libdrm 2.4.5 and kernel 2.6.29-rc7-git1
Comment 1 Giovanni Pellerano 2009-03-05 03:39:58 UTC
I've noticed also this in dmesg:

[drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer
------------[ cut here ]------------
WARNING: at drivers/gpu/drm/i915/i915_gem_tiling.c:291 i915_gem_set_tiling+0x43d/0x450 [i915]()
Hardware name: VGN-SR19XN
failed to unbind object for tiling switchModules linked in: btusb snd_hda_codec_realtek iwlagn iwlcore snd_hda_intel i915 snd_hda_codec sky2 mac80211 uhci_hcd ehci_hcd sdhci_pci sony_laptop sdhci
Pid: 5931, comm: X Tainted: G        W  2.6.29-rc7-git1 #1
Call Trace:
 [<c012b749>] warn_slowpath+0x99/0xc0
 [<c01038c0>] apic_timer_interrupt+0x28/0x30
 [<c012c44b>] printk+0x1b/0x20
 [<f8bb4bed>] i915_gem_object_unbind+0x1ed/0x200 [i915]
 [<f8bb8d9d>] i915_gem_set_tiling+0x43d/0x450 [i915]
 [<c02fcdf1>] drm_ioctl+0xf1/0x2d0
 [<c0106461>] sys_ipc+0xb1/0x280
 [<f8bb8960>] i915_gem_set_tiling+0x0/0x450 [i915]
 [<c0106461>] sys_ipc+0xb1/0x280
 [<c01a0548>] vfs_ioctl+0x78/0x90
 [<c01a0b5c>] do_vfs_ioctl+0x1ec/0x550
 [<c0243937>] file_has_perm+0xa7/0xb0
 [<c01a0f28>] sys_ioctl+0x68/0x80
 [<c01031c1>] sysenter_do_call+0x12/0x21
 [<c0106461>] sys_ipc+0xb1/0x280
 [<c04c0000>] set_cpu_sibling_map+0x160/0x2b0
---[ end trace 7fa619fb3877239e ]---
Comment 2 Gordon Jin 2009-03-05 17:01:44 UTC
You are using kms, right?

Please attach the full Xorg.0.log and dmesg, according to http://intellinuxgraphics.org/how_to_report_bug.html.
Comment 3 Giovanni Pellerano 2009-03-05 23:10:25 UTC
Yes using kms; (without it does works normally)

i've tried the 2.6.3, this version i thinki i't more correct with my laptop becouse i get the right resolution with kms (1280x800 instead thatw 1280x1280 with 2.6.2).

but with 2.6.3 and kms after kdm login if i run kde after some seconds the screen freeze. using the failsafe X login instead i can run the simpole glxggears without windows decoration correcnly.

any assumptions?

can i help you in some way?
Comment 4 Gordon Jin 2009-03-06 19:07:20 UTC
(In reply to comment #3)
> can i help you in some way?

attachment as I requested in comment#2.
Comment 5 Giovanni Pellerano 2009-03-07 00:15:41 UTC
Sorry i've didn't notice the request.

I'm going to attach dmesg and xorg log;

He are the related additional informations:

Chipset: "Mobile Intel® GM45 Express Chipset"
System Architecture: i686
Xorg-server: 1.5.3
Mesa: 7.3
Libdrm: 2.4.5
Kernel Version: 2.6.29-rc7-git1
Linux Distribution: Gentoo
Machine: Sony Vaio SR19XN

Step used to reproduce:

boot with modeset=0
login correctly in kdm on Kde
/etc/init.d/kdm stop
rmmod i915
modprobe i915 modeset=1
/etc/init.d/kdm start
=> and the screen freezes
shutdown with power button, so only the video card it's freezed, not all the system.

Comment 6 Giovanni Pellerano 2009-03-07 00:16:31 UTC
Created attachment 23608 [details]
Comment 7 Giovanni Pellerano 2009-03-07 00:20:54 UTC
Created attachment 23609 [details]
xorg log with modeset=1

The screen freeze before reg dump, i've attached also a xorg log using exa with the reg dump inside.
Comment 8 Giovanni Pellerano 2009-03-07 00:21:50 UTC
Created attachment 23610 [details]
xorg log with modeset=0
Comment 9 Giovanni Pellerano 2009-03-07 10:44:57 UTC
If it can help with modeset=1 i've noticed this from the xorg log:

(==) intel(0): VideoRam: 4194303 KB

this is totally insane

i've tried to force it to the correct value(262144 ) but i got:

(WW) intel(0): Option "VideoRam" is not used

any suggestion?
Comment 10 Jesse Barnes 2009-03-12 15:52:26 UTC
Looks like in the KMS case you're not getting DRI2 initialized for some reason, so you may be hitting a failure in the non-DRI path somehow.

The video memory thing is an artifact of KMS; it just reports a bogus value since the kernel manages everything (I should just remove it in the KMS case).

Maybe you can pull git master of xf86-video-intel and see if DRI2 works there?
Comment 11 Jesse Barnes 2009-03-18 14:49:33 UTC
Any update here Giovanni?
Comment 12 Giovanni Pellerano 2009-03-19 01:51:16 UTC
Jesse thanks for the interest.
I've tryed with the gentoo x11 overlay that includes xorg 1.6.0 and it does work!

but i got some problems:

- freeze on vt change
- on a 3d game i not some errors in surfaces

is there no way to make it work with dri1 at the momemnt ? any assumption

now i've reverted to xorg 1.5.3

Comment 13 Jesse Barnes 2009-03-19 09:52:50 UTC
VT switch works for me with git master of xf86-video-intel from today, can you try that when you have time?  Also please attach the dmesg and X log from your updated test config.
Comment 14 Jesse Barnes 2009-03-23 13:51:49 UTC
Ok, sounds like this was just a config problem, so I'm closing it out.  Thanks for testing!

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.