Date: Thu, 17 Jun 2010 11:24:16 +0200 From: Gary Jennejohn <gljennjohn@googlemail.com> To: Stacy Millions <stacy@Millions.Ca> Cc: freebsd-x11@freebsd.org Subject: Re: FBSD8 + xorg 7.5 + intel + IBM X40 Message-ID: <20100617112416.6258a290@ernst.jennejohn.org> In-Reply-To: <4C194C04.90504@millions.ca> References: <4C184972.8090001@millions.ca> <4C194C04.90504@millions.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Jun 2010 16:11:16 -0600
Stacy Millions <stacy@Millions.Ca> wrote:
> On 06/15/10 21:48, Stacy Millions wrote:
> > = crash
>
> I have rebuilt X with debugging enabled and by stepping through, have
> found where the driver causes the system to freeze.
>
>
> In i830_display.c:i830_crtc_load_lut in the loop
>
> for (i = 0; i < 256; i++) {
> OUTREG(palreg + 4 * i,
> (intel_crtc->lut_r[i] << 16) |
> (intel_crtc->lut_g[i] << 8) |
> intel_crtc->lut_b[i]);
> }
>
> when i == 2 the system freezes. The last thing gdb shows me is:
>
> (gdb) step
> 1943 OUTREG(palreg + 4 * i,
> 4: intel_crtc->lut_b[i] = 57 '9'
> 3: intel_crtc->lut_g[i] = 0 '\0'
> 2: intel_crtc->lut_r[i] = 63 '?'
> 1: i = 2
> (gdb) step
>
>
> Any ideas?
>
Considering that you're using the display while the hardware settings
are being modified I sort of wonder whether this loop is really the
cause.
Or are you debugging remotely?
I'd try commenting out this loop and see whether X starts without it
(but the display may be messed up). If it does then you can be pretty
sure that setting the palreg is the cause. Why is another question
all together.
--
Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100617112416.6258a290>