Dear DRI developers,
I upgraded to the 2.6.10 kernel this week, and discovered a bug which
had not been occuring previously under 2.6.9 or other Linux kernels.
After an S3 suspend/resume cycle I find that programs trying to
access /dev/dri/card0 lock up. (the program I am using is viewmol, but
it happens for others too). I can't stop the program with Ctrl-C, only
kill works on it.
An strace looks something like this (reporting the lines referring to
device "4")
...
write(4, "<\4\2\0\0\0\240\2+\0\1\0", 12) = 12
read(4, "\1\2\v\0\0\0\0\0H\0`\1\0\0\0\0\0\0\0\0\32\0\0\0\230\376"...,
32) = 32shutdown(4, 2 /* send and receive */) = 0
close(4) = 0
...
stat64("/dev/dri", {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
stat64("/dev/dri/card0", {st_mode=S_IFCHR|0666, st_rdev=makedev(226,
0), ...}) = 0
open("/dev/dri/card0", O_RDWR) = 4
ioctl(4, DECODER_GET_CAPABILITIES, 0xbffff500) = 0
ioctl(4, DECODER_GET_CAPABILITIES, 0xbffff500) = 0
ioctl(4, DECODER_GET_STATUS or DEVFSDIOC_SET_EVENT_MASK, 0xbffff53c) = 0
ioctl(4, DEVFSDIOC_GET_PROTO_REV, 0x80f01b8) = 0
ioctl(4, DEVFSDIOC_GET_PROTO_REV, 0x80f01b8) = 0
ioctl(4, 0x6448, 0) = 0
ioctl(4, 0xc008644c, 0xbffff520) = 0
ioctl(4, 0x4008642a, 0xbffff660) = 0
ioctl(4, 0x4008642a, 0xbffff490) = 0
ioctl(4, 0xc0106445, 0xbffff4a0) = 0
ioctl(4, 0x400c6441, 0xbffff690) = 0
ioctl(4, 0x40146442, 0xbffff6a0) = 0
This goes on, eventually getting to
ioctl(4, 0x4008642a, 0xbfff89d0) = 0
ioctl(4, 0x4008642b, 0xbfff8a18) = 0
ioctl(4, 0x4008642a, 0xbfff89d0) = 0
ioctl(4, 0x4008642b, 0xbfff8a18) = 0
ioctl(4, 0x4008642a, 0xbfff89d0) = 0
brk(0) = 0x82cb000
brk(0) = 0x82cb000
brk(0x82a1000) = 0x82a1000
brk(0) = 0x82a1000
ioctl(4, 0x6446, 0) = 0
ioctl(4, 0x6444, 0) = 0
ioctl(4, 0x6444, 0) = 0
and repeats from there thereafter, thousands of times over. The
repetition of "ioctl(4, 0x6444, 0) = 0" tells me device 4 is the
problem, and the open("/dev/dri/card0") line tells me it
is /dev/dri/card0.
My video card is an "Intel Corp. 82852/855GM Integrated Graphics Device
(rev 02)" (running on an IBM R51 laptop). XFree86 handles it with the
i810 driver, and invokes the i830 kernel module to handle drm.
I write to the i830 developer, Keith Whitwell. He replied that
suspend/resume support has only just been added to X.org CVS days ago to
the i810 driver. So in time my computer should work fine, once these
changes reach it, which is good to know.
But the question that remains is what changes were made between kernels
2.6.9 and 2.6.10? My programs were running perfectly fine after S3
resume when I was running 2.6.9. The problem for me has only cropped up
with 2.6.10. It seems there must be some regression bug, which I hope
can be addressed.
Keith was not sure why the regression might be occurring this way, and
suggested I raise it here at dri-devel, which I am now doing.
Any ideas?
Thanks,
Drew Parsons
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
