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

[Robert Noland]

On Thu, 2009-05-21 at 09:24 +0100, Matthew Seaman wrote:
> 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.

So, I think that your issue is that interrupts are vaporizing.  I have a
patch that re-works interrupt handling, but I don't think that it will
apply directly to -STABLE right now and it is currently only safe to use
on Intel.

robert.

> 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

-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20090521/f955136f/attachment.pgp