On Thu, 22 Apr 2010 21:15:26 +0200 Matthieu Herrb
<[email protected]> wrote:
> > Also, virtual terminal
> > switching has been problematic over here with the new driver, so
> > testing it thoroughly on other systems is wise. Over here, to hit
> > the bug you'll have to start x, then virtual terminal switch a few
> > times.
> >
> > The following seems to trigger the bug consistently over here:
> >
> > CTL-ALT-1
> > CTL-ALT-2
> > CTL-ALT-3
> > CLT-ALT-4
> > CLT-ALT-5 (back to X)
> >
> > You might need to enter/exit graphics mode (CTL-ALT-5) multiple
> > times.
>
> I don't remember if you provided more details on this to oga@ or
> not. But he will definatly need more information to help fixing this
> if possible.
It's a two-stage crash. First X goes wonky, unusable but is still
running (checked over network), and then second (on another vt switch
back to text mode), it drops to (blind) ddb. I like to *think* I've
managed to collect and send all the important stuff.
Off list I've sent him:
1.) multiple dmesg's
2.) multiple Xorg.0.log's
3.) steps for reproducing
4.) console output/errors (VT 1)
5.) debug kernel with symbols
6.) core file from the crash
As far as I know, I've covered everything, but if anything else is
needed, then let me know. If you want to see them, I'll forward the
mails to you.
The instructions in xenocara/README are great, and were very useful,
but a possible addition would be debugging X over serial. Sadly, I only
know booting to serial and text mode debugging, so dealing with X over
serial is a bit of a mystery. It's on my list of things to learn, but I
just haven't gotten to it yet.
I'm still hammering on the new driver with one system, and have a
nearly identical system running the Apr15 snapshot for comparison. Both
systems use Intel 82845G so at least we have some test coverage on one
of the oldest supported chips. Though I own a few of them, I do not
like "borrowed memory" designs. I don't understand all the low level
bits, but I do know they can be inconsistent.
For example, with the new driver and a fresh boot, mplayer can play
video perfectly through Xv if the resolution/refresh are not too high
(works at 1280x1...@75/76 but not at 1600x1200 and above). With no
changes, if you just let the system sit on for a few days, it will no
longer play video at 1280x1024. Sometimes a reboot will solve it, but
other times it will not. I've been trying to figure out how to make
this behavior repeatable, but leaving the system running for a day or
so between tests slows me down.
In the cases where video will not play through Xv, it will still play
with the x11 driver (e.g. `mplayer -vo x11 file.avi`). Similarly, if
running at 1600x1200, video will consistently play with the x11 driver
but not with the xv driver. When video fails to play, I mean I get a
blue window where the video "should" be displayed, so as far as I know,
the problem has to do with inadequate resources.
Mysteriously losing the ability to use xv after the system has been
running for a while seems to indicate something has happened to the
resources it originally allocated.
For quite a while now, the intel driver no longer supports the "Option
VideoRAM *" setting when used with UXA or EXA, and it typically
defaults to using 128MB regardless of the BIOS/CMOS settings (max 8MB).
I'm half tempted to hack the driver to use 256M by default just to
confirm if it will over-come the Xv issue at high resolutions, but I
doubt this will solve the mysterious loss of Xv/resources when the
system has been up for a while.
Even with the bugs, the new driver is still better in many regards than
the old/existing driver. If we can get more testing on vt switching by
others and solve the bug, it should be committed since the video
playback issues can be solved through configuration and are no worse
than the existing driver.
jcr
--
The OpenBSD Journal - http://www.undeadly.org
