On Wed, Oct 08, 2003 at 08:26:01PM +0300, Alexey E. Suslikov wrote: >> On Tue, Oct 07, 2003 at 09:19:42PM -0400, David Dawes wrote: >>> On Tue, Oct 07, 2003 at 05:16:28PM +0300, Alexey E. Suslikov wrote: >>> >Tuesday, October 7, 2003, 4:53:45 PM, you wrote: >>> > >>> >>> bang! this is it: the bug still exist, at least on i830m (like in my >>> >>> case). setting "NoAccel" "true" is turning off Xaa functions for first. >>> >>> linux people did so. i did too, but with no success :( >>> > >>> >> I've tried very hard and I'm not seeing the problem any more. >>> >> If you are still seeing it maybe you could do a little >>> >> investigation into its cause? >>> > >>> >> One thing you may want to try is setting >>> >pI830->>NeedRingBufferLow = TRUE >>> >> This isn't done for the i830 as it didn't seem to be necessary. >>> > >>> >ok. i will try and report as soon as possible. >>> >>> That shouldn't make any difference to the noaccel case, since the >>> ring buffer isn't allocated then. >>> >>> >> Yes, turning XAA off will work around the problem. The LpRing is >>> >> only used for that. >>> > >>> >no. as i described above, this recipe was digged from mailing list >>> >and solves the problem for some linux people. but not for me on >>> >OpenBSD and this guy on NetBSD. >>> >>> A couple of other things I can think of are 1) some subtle difference in >>> the implementation of the agpgart support for those two platforms, or >>> 2) the fact that the BIOS is executed via the emulator on the BSDs but >>> uses vm86 mode on Linux. Does anyone running FreeBSD see the problem? >>> If not, that should rule out 2). To take the agp support out of the >>> picture, disable the HW cursor, and make sure the videoram is set to >>> some amount lower than what the BIOS preallocates at boot time (e.g., >>> 4096). From your noaccel log, the agp interface is only used to allocate >>> the HW cursor space (because it needs a physical address). That means >>> just adding 'Option "SWCursor"' to your Device section should be >>> sufficient for this test. >>> >>> It would be very useful to try different OSs (Linux and one or more >>> BSDs) on exactly the same machine, and see if the results were the same. >>> It really has to be exactly the same machine to eliminate possible >>> differences in BIOS and hardware revisions. >>> >>> The messages in your log: >>> >>> (WW) I810(0): PRB0_CTL (0x000b6007) indicates ring buffer enabled >>> (WW) I810(0): PRB0_HEAD (0x00000000) and PRB0_TAIL (0x00092660) indicate ring buffer not flushed >>> >>> are results of some sanity checks on the inherited state that the driver >>> tries to make. It doesn't do anything other than report them. These >>> don't seem to show up at initial startup, only after switching VT's back >>> and forth. >>> >>> There seemed to be some evidence that some BIOSes did stuff that the >>> driver didn't expect when switching back to text mode. I was never able >>> to prove or disprove that theory, because I couldn't reproduce these >>> lockups that others had reported. Maybe it depends on the BIOS rev or >>> hardware rev. Maybe it's simply a bug lurking somewhere that doesn't >>> affect most platforms. It's hard to say for sure at this point. >> >> I made some tests on my NetBSD laptop : >> >> Dell Inspiron 2600 laptop (bios A08) >> Intel 82830MP Integrated Video (rev. 0x04) >> NetBSD 1.6ZC (-current 20031003) >> XFree86 4.3.99.13 (-current 20031007) >> >> * NoAccel ... ok >> * Accel ... KO >> * Accel + SWcursor + 4Mo ... KO >> * Accel + NeedRingBufferLow ... KO >> >> For the "NoAccel" case, i successfully switched about 20 times to the >> 4 text consoles and went back to X without any problem. But still no >> luck with acceleration enabled. > >my result with OpenBSD against -current (4.3.99.13) was completely equal >to Nicolas' with NetBSD: I830WaitLpRing() lockup still here. Does that include the NoAccel case no longer locking up? If so, that's at least something positive. >additionally, i have downloaded one of these widely available "linux on >livecd" distros and have found 4.3.0 working. Also good news. I'd like suggest trying the emulator version of the "int10" module. Normally you'd do this by renaming the /usr/X11R6/lib/modules/linux/libint10.a file so that the generic (emulator) version /usr/X11R6/lib/modules/libint10.a gets used instead. That might not be possible if you're running off a live CD. You might be able to achieve the same thing by copying the generic version to some writeable directory, and edit the XF86Config file to add that directory to the ModulePath before the default one. Checking the log file will allow you to confirm which module actually gets used. When you next try on OpenBSD, can you try a kernel without the agp support, to try eliminating that completely from the picture? >you will find dmesg and XFree86.log below. as always, i have done a couple >of terminal switching. this is it... confusing... It's a step in the right direction, at least. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
