Re: [XFree86] All annoying error in I830WaitLpRing() in some details
David Dawes writes: 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. On Linux the problems went away when moving the LpRing into the 'stolen memory'. I had to do this for 855 and 865 also to fix this problem. My impression was that when switching back to X the agp memory may get mapped to different physical pages. The chipset didn't like this. I don't recall exactly but I think I also got lockups when terminating and restarting the server completely. Egbert. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Thu, Oct 16, 2003 at 04:46:23PM +0300, Alexey E. Suslikov wrote:
skipped...
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?
no. once blacked it cannot be restored to normal operation. until i
reboot the box...
It just occurred to me where I had seen this type of black screen problem
before. It happens when using the vesa driver with an 845G. We work
around this in the i810 driver by remembering the initial video mode
and simply re-initialising it when exiting/VT switching instead of using
the VBE save/restore mechanism. This workaround is only actived for
845G hardware. You could try enabling it for all hardware by changing
this line in i830_driver.c from:
if (!I845G_VBE_WORKAROUND || !IS_845G(pI830)) {
to:
if (!I845G_VBE_WORKAROUND) {
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
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 (0x) 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
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Fri, Oct 10, 2003 at 10:10: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 (0x) 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. 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 (0x) 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
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
Nicolas Joly writes: * 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. 'NeedRingBufferLow' is a variable in the source code, not an option. Did you take this into account? The idea of this variable is to place the ring buffer into the stolen (ie. permanently allocated) memory. When VT switching the agp memory will get unmapped. Therefore other physical pages may get mapped later. The LpRing doesn't seem to like this. Have you tried to do Accel+NeedRingBufferLow+SWcursor? This should move all things that may cause problems out of the danger zone. Also please disable DRI! Egbert. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Thu, Oct 09, 2003 at 03:47:22PM +0200, Egbert Eich wrote: Nicolas Joly writes: * 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. 'NeedRingBufferLow' is a variable in the source code, not an option. Did you take this into account? I recompiled/installed the i810 driver with the following modifiation: Index: i830_driver.c === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c,v retrieving revision 1.39 diff -u -r1.39 i830_driver.c --- i830_driver.c 8 Oct 2003 15:48:40 - 1.39 +++ i830_driver.c 9 Oct 2003 13:53:43 - @@ -1769,7 +1769,8 @@ pI830-CursorNeedsPhysical = FALSE; /* Force ring buffer to be in low memory for the 845G. */ - if (IS_845G(pI830) || IS_I85X(pI830) || IS_I865G(pI830)) + /* HACK: temporary enable NeedRingBufferLow + if (IS_845G(pI830) || IS_I85X(pI830) || IS_I865G(pI830)) */ pI830-NeedRingBufferLow = TRUE; The idea of this variable is to place the ring buffer into the stolen (ie. permanently allocated) memory. When VT switching the agp memory will get unmapped. Therefore other physical pages may get mapped later. The LpRing doesn't seem to like this. Have you tried to do Accel+NeedRingBufferLow+SWcursor? This should move all things that may cause problems out of the danger zone. I just made the test, but it doesn't work either. Also please disable DRI! I do not have DRI under NetBSD. -- Nicolas Joly Biological Software and Databanks. Pasteur Institute, Paris. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
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 (0x) 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. -- Nicolas Joly Biological Software and Databanks. Pasteur Institute, Paris. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Tue, Oct 07, 2003 at 06:51:34PM -0700, Eric Anholt wrote: On Tue, 2003-10-07 at 18:19, 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. A couple of FreeBSDers have had problems with I830WaitLpRing errors on switching to a different VT. Can you confirm that this is one of the recent development snapshots? David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Wed, Oct 08, 2003 at 05:39:59PM +0300, Alexey E. Suslikov wrote: hmmm... yet another one on linux at 845G :) http://marc.theaimsgroup.com/?l=xfree86m=106561213221272w=2 That one is with DRI enabled, and it isn't clear if its is related to what you're seeing or not. It's also with XFree86 4.3. I haven't seen any reports from Linux users with symptoms that match what you have reported. If there are any Linux users reading this that do see the same symptoms, with a recent development snapshot, please send a note with details. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
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 (0x) 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
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
Alexey E. Suslikov writes: 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. Yes, turning XAA off will work around the problem. The LpRing is only used for that. Egbert. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
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 (0x) 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. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Tue, 2003-10-07 at 18:19, 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. A couple of FreeBSDers have had problems with I830WaitLpRing errors on switching to a different VT. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Sat, Oct 04, 2003 at 02:17:33PM -0400, David Dawes wrote: On Sat, Oct 04, 2003 at 07:43:29PM +0300, Alexey E. Suslikov wrote: is fixing Error in I830WaitLpRing() bug in plans of X developers? there are numerous related bug reports from all linux and bsd people. and this is LONG TERM bug. and it seems BOTH 845 and 830 affected. Try a recent development snapshot version. Most reports I've seen of this type of problem have been fixed there. The last known cause of this problem (and there have been several) was fixed after 4.3.0 was released. Same problem here under NetBSD 1.6ZC (-current), with XFree 4.3.99.13 (-current). I have lockup errors if acceleration is enabled, but it work fine witout. -- Nicolas Joly Biological Software and Databanks. Pasteur Institute, Paris. This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.99.13 Release Date: 25 September 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: NetBSD/i386 1.6ZC [ELF] The NetBSD Foundation, Inc. Current Operating System: NetBSD calamity.sis.pasteur.fr 1.6ZC NetBSD 1.6ZC (CALAMITY) #0: Fri Oct 3 09:56:38 CEST 2003 [EMAIL PROTECTED]:/local/src/NetBSD/objs/local/src/NetBSD/src/sys/arch/i386/compile/CALAMITY i386 Build Date: 06 October 2003 Changelog Date: 04 October 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Mon Oct 6 13:24:55 2003 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (==) Keyboard: CustomKeycode disabled (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (**) ModulePath set to /usr/X11R6/lib/modules (--) Using wscons driver in pcvt compatibility mode (version 3.32) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.7 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on netbsd (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.3.99.13, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.99.13, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,3575 card 8086,1969 rev 04 class 06,00,00 hdr 00 (II) PCI: 00:02:0: chip 8086,3577 card 1028,00b8 rev 04 class 03,00,00 hdr 80 (II) PCI: 00:02:1: chip 8086,3577 card 1028,00b8 rev 00 class 03,80,00 hdr 80 (II) PCI: 00:1d:0: chip 8086,2482 card 8086,4541 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2484 card 8086,4541 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 8086,4541 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,2483 card 8086,4541 rev 02 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1028,00b8 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 14f1,5421 rev 02 class 07,03,00 hdr 00 (II) PCI: 01:01:0: chip 10b7,9200 card 1028,00b8 rev 78 class 02,00,00 hdr 00 (II) PCI: 01:04:0: chip 1217,6972 card fffd, rev 00 class 06,07,00 hdr 02 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1:
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Sun, Oct 05, 2003 at 01:38:27PM +0300, Alexey E. Suslikov wrote: is fixing Error in I830WaitLpRing() bug in plans of X developers? there are numerous related bug reports from all linux and bsd people. and this is LONG TERM bug. and it seems BOTH 845 and 830 affected. Try a recent development snapshot version. Most reports I've seen of this type of problem have been fixed there. The last known cause of this problem (and there have been several) was fixed after 4.3.0 was released. There might be some DRI-related problems remaining, but they wouldn't be relevant to your configuration. David hmmm... can you point me on some related commit? it is easy for me to apply some patches and rebuild, not to fetch all of the HEAD. Use 'cvs rlog', 'cvs rdiff', or browse at cvsweb.xfree86.org. I'd have to do the same to isolate the relevant patch. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] All annoying error in I830WaitLpRing() in some details
On Sat, Oct 04, 2003 at 07:43:29PM +0300, Alexey E. Suslikov wrote: is fixing Error in I830WaitLpRing() bug in plans of X developers? there are numerous related bug reports from all linux and bsd people. and this is LONG TERM bug. and it seems BOTH 845 and 830 affected. Try a recent development snapshot version. Most reports I've seen of this type of problem have been fixed there. The last known cause of this problem (and there have been several) was fixed after 4.3.0 was released. There might be some DRI-related problems remaining, but they wouldn't be relevant to your configuration. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
