xf86-video-intel-2.7.1 -- a subtly different problem

Matthew Seaman matthew.seaman at thebunker.net
Thu May 21 08:41:58 UTC 2009


Hi all,

I've been following the recent discussions on this list about the state
of the Intel video driver with interest, since I have a Dell Latitude
D630 laptop with this video card:

vgapci0 at pci0:0:2:0:     class=0x030000 card=0x01f91028 chip=0x2a028086
rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile 965 Express Integrated Graphics Controller'
    class      = display
    subclass   = VGA
vgapci1 at pci0:0:2:1:     class=0x038000 card=0x01f91028 chip=0x2a038086
rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile 965 Express Integrated Graphics Controller'
    class      = display

(--) PCI:*(0 at 0:2:0) Intel Corporation Mobile GM965/GL960 Integrated
Graphics Controller rev 12, Mem @ 0xf6e00000/1048576,
0xe0000000/268435456, I/O @ 0x0000eff0/8, BIOS @ 0x????????/65536
(--) PCI: (0 at 0:2:1) Intel Corporation Mobile GM965/GL960 Integrated
Graphics Controller rev 12, Mem @ 0xf6f00000/1048576
(II) System resource ranges:
        [0] -1  0       0x000f0000 - 0x000fffff (0x10000) MX[B]
        [1] -1  0       0x000c0000 - 0x000effff (0x30000) MX[B]
        [2] -1  0       0x00000000 - 0x0009ffff (0xa0000) MX[B]
        [3] -1  0       0x0000ffff - 0x0000ffff (0x1) IX[B]
        [4] -1  0       0x00000000 - 0x000000ff (0x100) IX[B]

This is under recent (Thurs 14th) RELENG_7 with all ports up to date.
I'm relying on dbus and hal for detecting the mouse and keyboard, and in
general everything works swimmingly.  It drives my 1920x1200 external
screen via the docking station very happily. But only for about a day
immediately after the system is rebooted.

It seems that if I leave the machine quiescent overnight, so the video
powers itself down, then the following day I get the annoying effect
that certain X events don't seem to be processed and the screen update
blocks until the mouse is moved.  Killing and restarting xdm and the X
server has no effect. Disabling hal and adding the AllowEmptyInput and
AutoAddDevices stuff in xorg.conf ServerOptions section just makes the
effect worse.  Rebooting returns everything to normality for the rest of
the day.

The only errors in Xorg.0.log are occasional sets of 3 lines like this:

(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.

but I get those even when everything is working perfectly well.

Very rarely I have seen the system crash and reboot when I log out of X,
but this might occur perhaps once a month.  I haven't tracked it down
yet but I suspect a bad reaction to some sort of multimedia / flash /
whatever on the web.

	Cheers,

	Matthew

-- 
Dr Matthew Seaman                        The Bunker, Ash Radar Station
PGP: 0x60AE908C on servers               Marshborough Rd
Tel: +44 1304 814890                     Sandwich
Fax: +44 1304 814899                     Kent, CT13 0PL, UK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20090521/b844f316/signature.pgp


More information about the freebsd-x11 mailing list