>>>>>> >>> 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.
>>>>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.
>>
>>i have done "cp -R /usr/X11R6/lib/modules/* /var/modules/" than
>>"rm -rf /var/modules/linux", point XF86Config's "ModulePath" to the
>>new location and run. you will find the log at the bottom.
>>
>>the only difference i see - is the existence of these
>>(WW) I810(0): PRB0_HEAD (0x00000000) and PRB0_TAIL (0x00092660) indicate ring buffer not flushed
>>warnings. but! i have switched terminal 3 times, but you will find
>>only 2 messages of this kind 8-()
>
> OK, so there is at least one difference when using the x86 emulator vs
> vm86 mode.
>
>>> When you next try on OpenBSD, can you try a kernel without the agp support,
>>> to try eliminating that completely from the picture?
>>
>>will X11 run without agp support in the kernel? will specifying
>>"NoAccel" and "SWCursor" be enough against such kernel?
>
> Yes, it will run without agp support. For your configuration, the only
> functionality that won't be available in that case is the HW cursor and
> XVideo. Acceleration is still available. Functionality that requires
> an AGP allocation will automatically be disabled when it's not available.
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
When reporting a problem related to a server crash, please send
the full server output, not just the last messages.
This can be found in the log file "/var/log/XFree86.0.log".
Please report problems to xfree86@xxxxxxxxxxxx
_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86
