On Sat, Oct 11, 2003 at 12:25:17AM +0300, Alexey E. Suslikov 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. >>> >>>i am still trying to reproduce this NoAccel bug: just don't want make >>>any hasty conclusions. i will report additionally... >> >> OK. > >this NoAccel bug is reproducible: X11 can blacks after first time i switching >consoles, sometimes - after 10 times, sometimes - even after 20 times. >looks like (available?) agp memory amount determines this... maybe not... > >and i think this is a common bug for accel and non-accel setups: it doesn't >matter in the accel setup because the ring buffer bug takes precedence. > >and this is common bug for linux and bsd: after the paranoid console >switching, 4.3.0 under linux also blacks its console out. but there is >no ring buffer bug as i mentioned before. > >this "blacking" in non-accel looks like the pipe just deattaching from the >driver (or restoring its state incorrectly), so i can't see anything on the >X's tty while X runs completely normally (i.e. no lockups) and allows me to >switch to completely normally working text ttys. Does further switching give you a working XFree86 display again? What happens if you exit that XFree86 session and restart XFree86? FWIW, when I was working in the driver, I wasn't able to reproduce any switching-related problems with the hardware I had and the 4.3 version on Linux, even after literally hundreds of switches. I'm pretty much out of suggestions, short of doing some very detailed tracing/debugging, or rewriting the mode handling code in the driver to avoid the video BIOS. >i can't: > >Fatal server error: >xf86EnableIO: Failed to set IOPL for extended I/O > Check that you have set 'machdep.allowaperture=1' > in /etc/sysctl.conf and reboot your machine > refer to xf86(4) for details I'm not familiar enough with how the agp support is handled on OpenBSD. On FreeBSD and Linux the agp/agpgart drivers can be removed/disabled without affecting the ability to access the boot-time allocated video memory. 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
