On Wed, 12 May 2010 17:20:28 -0300 "Alan R. S. Bueno" <alan....@gmail.com> wrote: > On Wed, May 12, 2010 at 3:41 PM, J.C. Roberts > <list-...@designtools.org> wrote: > > Both INTELDRM_GEM kernel and the corresponding new X intel driver > > were recently committed. Due to mirrors being out of sync, your cvs > > update may have only caught a portion of the needed changes. You > > should try again with cvs update of src and xenocara. > > No. The latest change that my cvs update caught was: > > http://marc.info/?l=openbsd-cvs&m=127357649215000&w=2 > > After that change, no *relevant* change was made (neither in src/ nor > xenocara/) that can be the cause of the error; so, cvs update now is > irrelevant. If you are subscribed to source-changes@, check the latest > changes; if not, check here: >
I think you're right about the *relevant* changes since the intagp stuff committed today seems to be for pineview from the commit logs. > Today my machine froze again in the same condictions. (I had to use > the power button.) :-( Bummer. I've been testing the new intel driver (with GEM) for a few weeks and it still has a few bugs with old 82845G. In my case, the screen gets corrupted, but X doesn't actually crash. This happens repeatably when switching to/from virtual terminals, and happens occasionally when flipping between xterms and gtk-based apps in X. Of course, once it's corrupted, a subsequent VT switch will crash X, but the corruption alone does not. The best thing you can do is enable DRM Debug in the kernel and try to get a core dump. $ cat /usr/src/sys/conf/GENERIC | grep DEBUG= makeoptions DEBUG="-g" # compile full symbol table $ cat /usr/src/sys/arch/i386/conf/GENERIC_DRMDEBUG include "arch/i386/conf/GENERIC" option DRMDEBUG option DRMLOCKDEBUG And then follow the instructions in xenocara/README for how to set up and run the system to get a core file. -- The OpenBSD Journal - http://www.undeadly.org
