On Wed, 25 Mar 2009 13:36:59 -0400 "Aaron W. Hsu" <arcf...@sacrideo.us>
wrote:
> > good, you've actually got two cards in the machine. A number of
> > dual/multi head cards can be run "Zaphod Mode" (i.e. two or more
> > "Device" sections for a single card), but the new intel(4) driver
> > does not support this.
>
> Actually, while there are two cards in the machine, and I can run with
> both of them enabled in the BIOS, it saps a lot of power. I can't seem
> to get good use out of the ATI one at the moment, so I've been using
> the Intel, with the ATI disabled in the BIOS.
>
Heh. I've never seen a laptop with two competing graphics chipsets
before, so I mistakenly assumed it was a desktop. I should have paid
more attention to the dmesg you posted!
> > Sure, running at max resolution is fun, but the other funky thing
> > about the intel(4) driver (and chipsets) is if you are running at
> > MAX resolution, you cannot play video very well, or in some cases,
> > at all. I suspect the reason for this limitation is due to using up
> > all the (shared) resources trying to push the larger resolution(s).
> > The solution I've found here with other Intel chips is to just use
> > a lower resolution and video plays fine. It even plays fine
> > full-screen, something the previous driver ("i810(4)") could never
> > do.
>
> Thank you again for providing this very informative answer. I think
> that I will definitely try this if I have problems again,
> but...*sheepish grin*...I can reproduce any of the tearing, slow
> playback, or otherwise in my latest build. I don't know if I did
> something or messed something up (I know at one point I was running
> the expiremental Intel driver for testing, maybe that was it?),
Your old Xorg.0.log says you were running intel(4) version 2.6.0 when
you were having problems. The previous version of the intel driver
(committed to 4.5-release at the very end of February) was 2.4.3.
Do you know *what* experimental driver you were running?
Was it the diff oga@ posted to tech@ for testing?
http://marc.info/?l=openbsd-tech&m=123307709522306&w=2
Or was it something else?
The above diff from oga@, though labeled as version "2.6.1" reported
itself as "2.6.0" in the Xorg.0.log.
BTW, did you send off your pcidump(s) to him as requested?
Owain (oga@) is one of the main masterminds working on our intel(4)
driver, our drm implementation, our libpciaccess, and other brutally
complicated code. Eventually he will commit the "experimental" driver,
so if it was the cause of your problems, it's best he knows about it.
By updating your source, you may have reverted to the old (2.4.3)
driver, but then again, the new experimental 2.6.{0,1} driver may have
been committed by now along with additional changes?
> but when I recompiled from
> yesterday's source, and rebuilt Xenocara, with the only xorg.conf
> modification being that mentioned above, the video which had given me
> trouble now plays just fine. :-S So, apparently, I don't need to edit
> the DDC options right now.
Good News!
Now that it's working, what is the version of the intel driver stated in
your new Xorg.0.log ?
Due to both a very slow Internet connection, and a stupid monthly
bandwidth usage cap, I'm pretty bad about keeping my -current box
current, and only update it every few weeks. I'm updating source at
the moment, so with my network connection hammered, even trying browse
the web-cvs to see if the new "experimental" 2.6.{0,1} driver has been
committed is difficult.
> I'm still not sure why it is working now
> and wasn't just a week ago, but maybe I missed something in my
> usually quick browse of the source changes.
>
Are you still getting the "Bad VBT signature" ?
> (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
> (EE) intel(0): Bad VBT signature
> (WW) intel(0): VBIOS initialization failed.
The above is supposedly not a big deal.
Are you still getting the erroneous hardware state warning?
> (WW) intel(0): ESR is 0x00000010, page table error
> (WW) intel(0): PGTBL_ER is 0x00100000, CS instruction GTT PTE
> (WW) intel(0): Existing errors found in hardware state.
I won't pretend to understand what the hell that warning means, but
your report was the first time I've seen it.
Depending on *when* you pulled source for your build of current:
> OpenBSD 4.5-current (GENERIC.MP) #5: Fri Mar 6 14:09:08 EST 2009
> r...@onyx.local:/usr/src/sys/arch/i386/compile/GENERIC.MP
You might have stepped into the midst of the "heavy development" phase
of the OpenBSD release cycle. As usual, it seems the 4.5-RELEASE was
completed at the very end of February, so it can be shipped off to
create the release CD's and packaging (this takes about six weeks I
think). Once a release is completed (in source code), the tree gets
tagged -current and is reopened for new commits, so this is the time
frame when the most "serious" changes planed for the next release are
committed.
It's possible you pulled source at exactly the wrong time, and stepped
into the midst of the most significant changes being committed to the
tree. Just because the build has not been broken does not necessarily
mean all the planned new changes have been completely committed. Even
the big changes get rolled in slowly and carefully, but none the less,
twice a year, the -current tree is in a state of heavy flux.
--
J.C. Roberts
