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