X doesn't update until the mouse moves (not HAL related)
Daniel O'Connor
I have a perplexing problem on FreeBSD 7.2 where the X server freezes
unless the mouse is moved, however it isn't HAL related - I have tried
the usual fix (which worked on my laptop and others). I also have tried
rebuilding X without HAL support and it _still_ happens.
I notice that GL apps don't work properly and I get a message saying
that IRQs don't appear to work and that reminded me of a commit which I
think fixed it, however I am not sure if it has been MFC'd (or if it
would fix the problem).
The hardware is a Supermicro C2SBA+ which has G33 video onboard:
(II) intel(0): Creating default Display subsection in Screen section
"Builtin Default intel Screen 0" for depth/fbbpp 24/32
(==) intel(0): Depth 24, (--) framebuffer bpp 32
(==) intel(0): RGB weight 888
(==) intel(0): Default visual is TrueColor
(II) intel(0): Integrated Graphics Chipset: Intel(R) G33
(--) intel(0): Chipset: "G33"
(--) intel(0): Linear framebuffer at 0xC0000000
(--) intel(0): IO registers at addr 0xD2300000
(==) intel(0): Using EXA for acceleration
(II) intel(0): 2 display pipes available.
Any help appreciated, thanks!
PS please CC me as I am not on the list.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Andriy Gapon
> Hi,
> I have a perplexing problem on FreeBSD 7.2 where the X server freezes
> unless the mouse is moved, however it isn't HAL related - I have tried
> the usual fix (which worked on my laptop and others). I also have tried
> rebuilding X without HAL support and it _still_ happens.
>
> I notice that GL apps don't work properly and I get a message saying
> that IRQs don't appear to work and that reminded me of a commit which I
> think fixed it, however I am not sure if it has been MFC'd (or if it
> would fix the problem).
>
> The hardware is a Supermicro C2SBA+ which has G33 video onboard:
> (II) intel(0): Creating default Display subsection in Screen section
> "Builtin Default intel Screen 0" for depth/fbbpp 24/32
> (==) intel(0): Depth 24, (--) framebuffer bpp 32
> (==) intel(0): RGB weight 888
> (==) intel(0): Default visual is TrueColor
> (II) intel(0): Integrated Graphics Chipset: Intel(R) G33
> (--) intel(0): Chipset: "G33"
> (--) intel(0): Linear framebuffer at 0xC0000000
> (--) intel(0): IO registers at addr 0xD2300000
> (==) intel(0): Using EXA for acceleration
> (II) intel(0): 2 display pipes available.
>
> Any help appreciated, thanks!
I'd say that in your case it's worth trying upgrading to stable/7 or releng/7.3
(soon to become 7.3 release). You could start by trying only a new kernel(+modules).
--
Andriy Gapon
Andriy Gapon
> On Thu, 18 Mar 2010, Andriy Gapon wrote:
>>> (--) intel(0): IO registers at addr 0xD2300000
>>> (==) intel(0): Using EXA for acceleration
>>> (II) intel(0): 2 display pipes available.
>>>
>>> Any help appreciated, thanks!
>> I'd say that in your case it's worth trying upgrading to stable/7 or
>> releng/7.3 (soon to become 7.3 release). You could start by trying
>> only a new kernel(+modules).
>
>
> I tred a RELENG_7 kernel/modules for a test and it does fix the problem
> which is good news!
Good.
> I would prefer a minimal change set if possible though :)
>
> Any idea how what changes I need?
Nope, sorry.
Just wait for 7.3 and install it.
Or even install its latest RC now :)
--
Andriy Gapon
Daniel O'Connor
> > (==) intel(0): Using EXA for acceleration
> > (II) intel(0): 2 display pipes available.
> >
> > Any help appreciated, thanks!
>
> I'd say that in your case it's worth trying upgrading to stable/7 or
> releng/7.3 (soon to become 7.3 release). You could start by trying
> only a new kernel(+modules).
OK..
I tred a RELENG_7 kernel/modules for a test and it does fix the problem
which is good news!
I would prefer a minimal change set if possible though :)
Any idea how what changes I need?
--
Eitan Adler
found that other X users (including Linux users) have this problem on
intel chipsets.
2010/3/19 Andriy Gapon <a...@icyb.net.ua>:
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11...@freebsd.org"
>
Andriy Gapon
> I have a similar problem with X on 8.0-RELEASE. I asked around and
> found that other X users (including Linux users) have this problem on
> intel chipsets.
But Daniel says that kernel update helps him :)
So, it must be something different with similar symptoms.
BTW, you could also try a kernel from stable/8 and see how that works out.
--
Andriy Gapon
Robert Noland
> On Fri, 19 Mar 2010, Andriy Gapon wrote:
> > on 19/03/2010 13:34 Eitan Adler said the following:
> > > I have a similar problem with X on 8.0-RELEASE. I asked around and
> > > found that other X users (including Linux users) have this problem
> > > on intel chipsets.
> >
> > But Daniel says that kernel update helps him :)
> > So, it must be something different with similar symptoms.
> >
> > BTW, you could also try a kernel from stable/8 and see how that works
> > out.
>
> I have had the hald problem with multiple opens of /dev/sysmouse but
> that is fixed.
>
> There are a large number of intel chipsets - there's sure to be many
> bugs :)
IIRC, this was actually a bug in the interrupt code. Specifically, the
handling of MSI on chips > i945. The commit should have been either
from me or jhb@ and a search of the email archives should turn something
up.
robert.
--
Robert Noland <rno...@FreeBSD.org>
FreeBSD
Eitan Adler
> IIRC, this was actually a bug in the interrupt code. Specifically, the
> handling of MSI on chips > i945. The commit should have been either
> from me or jhb@ and a search of the email archives should turn something
> up.
My machine can't handle make buildworld so I have to wait until the
next -RELEASE before I can test this (unless freebsd-update could
handle -STABLE) :\
Daniel O'Connor
> > There are a large number of intel chipsets - there's sure to be
> > many bugs :)
>
> IIRC, this was actually a bug in the interrupt code. Specifically,
> the handling of MSI on chips > i945. The commit should have been
> either from me or jhb@ and a search of the email archives should turn
> something up.
I had a look and saw a few likely candidates, I will see what I can find
when I get some time to test..
TBH the easiest way will probably be to just use
7.3's /usr/src/sys/dev/drm.. :)
Robert Noland
> On Sat, 20 Mar 2010, Robert Noland wrote:
> > > There are a large number of intel chipsets - there's sure to be
> > > many bugs :)
> >
> > IIRC, this was actually a bug in the interrupt code. Specifically,
> > the handling of MSI on chips > i945. The commit should have been
> > either from me or jhb@ and a search of the email archives should turn
> > something up.
>
> I had a look and saw a few likely candidates, I will see what I can find
> when I get some time to test..
>
> TBH the easiest way will probably be to just use
> 7.3's /usr/src/sys/dev/drm.. :)
What I'm saying is that, iirc the fix was in the pci code, not drm
directly. I think it was the fixes for INTx handling...
From: Robert Noland <rno...@FreeBSD.org>
To: freebsd-current <freebsd...@freebsd.org>
Cc: freebsd-x11 <freeb...@freebsd.org>
Subject: Broken interrupts on Intel gfx
Date: Thu, 25 Jun 2009 13:58:08 -0500
jhb has committed the rest of the msi fix that will address the broken
interrupts on Intel graphics chips on SMP. Make sure that you have
r194985 and things should be good.