Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600

2005-02-28 Thread Nicolas Joly 
On Fri, Feb 25, 2005 at 08:11:45PM -0500, David Dawes wrote:
 On Fri, Feb 25, 2005 at 04:05:43PM -0500, David Dawes wrote:
 On Fri, Feb 25, 2005 at 07:35:37PM +0100, Nicolas Joly wrote:
 
 - The missing 1024x768 mode, that was there with the previous realease
   module, seems to be invalidated due to HSync not in default range.
   I'm getting a value of 33.8, indeed outside from 28.00-33.00
   range.
   I'm currently thinking that the new `i830GetModePool()' function
   does not give exactly the same results as `VBEGetModePool()'.
   I can get this working mode back by increasing the HSync range to
   28.00-34.00 kHz.
 
 In the absence of DDC-probed monitor parameters or explicitly specified
 parameters, it seems that the fallback monitor defaults were not getting
 set before VBEGetModePool() was called.  Thus, modes that should have
 been excluded were not being excluded.  The vesa driver still has this
 bug.  I'll look into fixing VBEGetModePool() to correctly handle this
 situation, and add warnings to xf86CheckModeForMonitor() for when it is
 called before monitor parameters are set.
 
 I've committed some changes that fix this.
 
 This has been resolved in the current i830 driver, which accounts for
 the change in behaviour that you are seeing.  However, in the case of
 flat panels, the driver can and should set better default monitor
 parameters, namely parameters that are consistent with a panel sized
 mode at 60Hz refresh.  Most drivers probably still don't handle this
 correctly.  I modified the neomagic driver to do this shortly before the
 4.4.0 release, and that's a good example of how it can be done.
 
 The changes I've just committed provide an easier way of doing this too.
 You might want to see if you can make use of this in the i830 driver.

I tried to run with the appended patch and got very good results !

The laptop now works at 1024x768 from a config file generated with
`-configure' option, without any modification ...

Index: i830_driver.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c,v
retrieving revision 1.62
diff -u -r1.62 i830_driver.c
--- i830_driver.c   18 Feb 2005 02:55:08 -  1.62
+++ i830_driver.c   28 Feb 2005 15:50:13 -
@@ -2643,6 +2643,19 @@
xf86DrvMsg(pScrn-scrnIndex, X_PROBED,
  Maximum space available for video modes: %d kByte\n, memsize);
 
+   if (!pScrn-monitor-DDC) {
+   int n = pI830-pipe;
+/*
+ * If the monitor parameters are not specified explicitly, set them
+ * so that 60Hz modes up to the panel size are allowed.
+ */
+xf86SetMonitorParameters(pScrn, pScrn-monitor,
+ pI830-pipeDisplaySize[n].x2,
+ pI830-pipeDisplaySize[n].y2,
+ 60);
+
+   }
+
/* By now, we should have had some monitor settings, but if not, we
 * need to setup some defaults. These are used in common/xf86Modes.c
 * so we'll use them here for GetModePool, and that's all. 

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86

Re: [XFree86] Segmentation fault when running XFree86 -configure in XFree86 4.5.0 RC1

2005-02-21 Thread Nicolas Joly 
On Sun, Feb 20, 2005 at 11:44:59PM -0800, Tom Williams wrote:
 When I try to use XFree86 -configure to configure my X settings, it seg 
 faults:

There was a problem with `-configure' and `-probe' options, which
should be corrected in 4.4.99.902 snapshot.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86

Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600

2005-02-18 Thread Nicolas Joly 
On Thu, Feb 17, 2005 at 04:20:12PM -0500, David Dawes wrote:
 On Thu, Feb 17, 2005 at 01:53:50PM +0100, Nicolas Joly wrote:
 On Wed, Feb 16, 2005 at 06:23:24PM -0500, David Dawes wrote:
  On Wed, Feb 16, 2005 at 09:00:43PM +0100, Nicolas Joly wrote:
  
  Hi,
  
  I just tried CVS XFree86 on my DELL Inspiron 2600 with Intel 82830MP
  Integrated Video running under NetBSD/i386, and got bad results ...
  This machine worked flawlessly with the previous release (4.4.0), with
  1024x768, depth 16.
  
  When i try to start the server, problems begins ... The LFP remains
  black and the server start eating all the CPU !
[...]
 The process is looping in `X86EMU_exec()'.
 
 Yes.  One thing to do to help eliminate components outside of the driver
 is to go back to the modular server, but replace the int10 and vbe
 modules with those from 4.4.0.

Done. Got the same results :-(

 Another useful piece of information, if possible, would be to
 compare the results with Linux on similar hardware when using the
 vm86 version of the int10 module vs the x86emu version.

Don't know much about linux ... But i checked the 4.4.99.901 snapshot
with CentOS 3.4 rescue CD, with the same results. In the same time, i
checked that the 4.3.0 server provided by the CD works fine.

 Another step would be to compare the sequence and parameters for the int10
 calls made by the 4.4.0 version of the driver vs the current version.

Will check and report a little later. Any simple way to proceed ?

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86

Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600

2005-02-17 Thread Nicolas Joly 
On Wed, Feb 16, 2005 at 06:23:24PM -0500, David Dawes wrote:
 On Wed, Feb 16, 2005 at 09:00:43PM +0100, Nicolas Joly wrote:
 
 Hi,
 
 I just tried CVS XFree86 on my DELL Inspiron 2600 with Intel 82830MP
 Integrated Video running under NetBSD/i386, and got bad results ...
 This machine worked flawlessly with the previous release (4.4.0), with
 1024x768, depth 16.
 
 When i try to start the server, problems begins ... The LFP remains
 black and the server start eating all the CPU !
 
 I'd guess from the log that it is getting stuck setting the video mode.
 However, you would need to either attach to the XFree86 process with
 gdb, or kill it (with SIGSEGV or SIGQUIT) and run gdb on the resulting
 core to find our for certain.  Perhaps Alan has some ideas about what
 is going wrong here.

To help debugging, i recompiled everything with `-g -O0' and made the
server static.

It seems that you're right, according to the 2 following traces :

(gdb) bt
#0  0x0847011e in write_w (pInt=0x8af5a00, addr=8080, val=48988)
at generic.c:532
#1  0x0848a94d in pushw (pInt=0x8af5a00, val=48988) at helper_exec.c:95
#2  0x0848a99c in run_bios_int (num=0, pInt=0x8af5a00) at helper_exec.c:134
#3  0x0848bd2d in int_handler (pInt=0x8af5a00) at xf86int10.c:53
#4  0x0846f063 in x86emu_do_int (num=0) at xf86x86emu.c:25
#5  0x08470535 in x86emu_intr_handle () at decode.c:57
#6  0x0847064a in X86EMU_exec () at decode.c:113
#7  0x0846f0a7 in xf86ExecX86int10 (pInt=0x8af5a00) at xf86x86emu.c:39
#8  0x08462b27 in VBESetVBEMode (pVbe=0x8b04480, mode=49223, block=0x0)
at vbe.c:526
#9  0x082b4016 in I830VESASetVBEMode (pScrn=0x8af2800, mode=49223, block=0x0)
at i830_driver.c:3375
#10 0x082b4131 in I830VESASetMode (pScrn=0x8af2800, pMode=0x8b0f000)
at i830_driver.c:3450
#11 0x082b6d41 in I830BIOSEnterVT (scrnIndex=0, flags=0) at i830_driver.c:4841
#12 0x082b5bb2 in I830BIOSScreenInit (scrnIndex=0, pScreen=0x8b01e00, argc=3, 
argv=0xbfbfebec) at i830_driver.c:4302
#13 0x084b1c2c in AddScreen (pfnInit=0x82b53f0 I830BIOSScreenInit, argc=3, 
argv=0xbfbfebec) at main.c:763
#14 0x08413b8a in InitOutput (pScreenInfo=0x8ae92e0, argc=3, argv=0xbfbfebec)
at xf86Init.c:1145
#15 0x084b0f13 in main (argc=3, argv=0xbfbfebec, envp=0xbfbfebfc) at main.c:355
#16 0x0804bdb6 in ___start ()

#0  Mem_rw (addr=0) at helper_exec.c:434
#1  0x0847d1ec in x86emuOp_iret (op1=207 'Ï') at ops.c:8904
#2  0x0847068f in X86EMU_exec () at decode.c:117
#3  0x0846f0a7 in xf86ExecX86int10 (pInt=0x8af5a00) at xf86x86emu.c:39
#4  0x08462b27 in VBESetVBEMode (pVbe=0x8b04480, mode=49223, block=0x0)
at vbe.c:526
#5  0x082b4016 in I830VESASetVBEMode (pScrn=0x8af2800, mode=49223, block=0x0)
at i830_driver.c:3375
#6  0x082b4131 in I830VESASetMode (pScrn=0x8af2800, pMode=0x8b0f000)
at i830_driver.c:3450
#7  0x082b6d41 in I830BIOSEnterVT (scrnIndex=0, flags=0) at i830_driver.c:4841
#8  0x082b5bb2 in I830BIOSScreenInit (scrnIndex=0, pScreen=0x8b01e00, argc=3, 
argv=0xbfbfebec) at i830_driver.c:4302
#9  0x084b1c2c in AddScreen (pfnInit=0x82b53f0 I830BIOSScreenInit, argc=3, 
argv=0xbfbfebec) at main.c:763
#10 0x08413b8a in InitOutput (pScreenInfo=0x8ae92e0, argc=3, argv=0xbfbfebec)
at xf86Init.c:1145
#11 0x084b0f13 in main (argc=3, argv=0xbfbfebec, envp=0xbfbfebfc) at main.c:355
#12 0x0804bdb6 in ___start ()

The process is looping in `X86EMU_exec()'.

 Does the vesa driver still work OK?

Works fine, at least, with 1024x768 at depth 16.

 I tracked the problem on the i810 driver module; and noticed that it
 appeared with the i915M support (CHANGELOG 252 - 01/09/2005).
 
 I noticed some built-in modes detection changes, and a problem with HW
 (ARGB) cursor allocation (full log attached):
 
 The ARGB cursor requires kernel agp support for allocating more than one
 page for AGP_PHYS_MEMORY requests.  From what Alan said when this I asked
 about this on the devel list a couple of weeks ago, recent Linux kernels
 have the necessary support for this.  The NetBSD (and FreeBSD) agp modules
 would need similar updates in order for this to work.  I doubt that the
 problem you are seeing is related to this though.

Ok. I'll see this one later.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86

[XFree86] CVS XFree86 i830 failure on DELL inspiron 2600

2005-02-16 Thread Nicolas Joly 

Hi,

I just tried CVS XFree86 on my DELL Inspiron 2600 with Intel 82830MP
Integrated Video running under NetBSD/i386, and got bad results ...
This machine worked flawlessly with the previous release (4.4.0), with
1024x768, depth 16.

When i try to start the server, problems begins ... The LFP remains
black and the server start eating all the CPU !

I tracked the problem on the i810 driver module; and noticed that it
appeared with the i915M support (CHANGELOG 252 - 01/09/2005).

I noticed some built-in modes detection changes, and a problem with HW
(ARGB) cursor allocation (full log attached):

XFree86 4.4.0:
(--) I810(0): Virtual size is 1024x768 (pitch 1024)
(**) I810(0): *Built-in mode 1024x768
(**) I810(0): *Built-in mode 800x600
(**) I810(0): *Built-in mode 640x480

XFree86 4.4.99.901:
(--) I810(0): Virtual size is 1024x600 (pitch 1024)
(**) I810(0): *Built-in mode 1024x600
(**) I810(0): *Built-in mode 800x600
(**) I810(0): *Built-in mode 640x480
[...]
(II) I810(0): Allocated 4 kB for HW cursor at 0x7fff000 (0x013f9000)
(WW) I810(0): xf86AllocateGARTMemory: allocation of 4 pages failed
(Cannot allocate memory)
(EE) I810(0): Failed to allocate HW (ARGB) cursor space.
(II) I810(0): Allocated 4 kB for Overlay registers at 0x7ffe000 (0x013fa000).

Thanks in advance.
Regards.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.

This is a pre-release version of XFree86, and is not supported in any
way.  Bugs may be reported to XFree86@XFree86.Org 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.4.99.901 (4.5.0 RC 1)
Release Date:  8 February 2005
X Protocol Version 11, Revision 0
Build Operating System: NetBSD/i386 2.99.15 [ELF] The NetBSD Foundation, Inc.
Current Operating System: NetBSD calamity.sis.pasteur.fr 2.99.15 NetBSD 2.99.15 
(CALAMITY) #4: Tue Feb 15 13:33:46 CET 2005  [EMAIL 
PROTECTED]:/local/src/NetBSD/obj/i386/sys/arch/i386/compile/CALAMITY i386
Build Date: 16 February 2005
Changelog Date: 16 February 2005
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Command line: XFree86 -xf86config /home/njoly/XF86Config.new
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (EE) error, (WW) warning,
(II) informational, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/XFree86.0.log, Time: Wed Feb 16 18:48:00 2005
(++) Using config file: /home/njoly/XF86Config.new.
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.3
XFree86 Video Driver: 0.8
XFree86 XInput driver : 0.5
XFree86 Server Extension : 0.3
XFree86 Font Renderer : 0.5
(II) Loader running on netbsd
(==) Keyboard: CustomKeycode disabled.
(==) ServerLayout XFree86 Configured
(==) |--Screen Screen0 (0) (0, 0)
(**) |  |--Device Card0
(**) |  |--Monitor Monitor0 (0)
(**) |--Input Device Mouse0
(**) |--Input Device Keyboard0
(**) FontPath set to 
/usr/X11R6.x86/lib/X11/fonts/misc/,/usr/X11R6.x86/lib/X11/fonts/TTF/,/usr/X11R6.x86/lib/X11/fonts/Speedo/,/usr/X11R6.x86/lib/X11/fonts/Type1/,/usr/X11R6.x86/lib/X11/fonts/CID/,/usr/X11R6.x86/lib/X11/fonts/75dpi/,/usr/X11R6.x86/lib/X11/fonts/100dpi/
(**) RgbPath set to /usr/X11R6.x86/lib/X11/rgb
(**) ModulePath set to /usr/X11R6.x86/lib/modules
(II) Checking for unused ServerFlags options:
(II) LoadModule: pcidata
(II) Loading /usr/X11R6.x86/lib/modules/libpcidata.a
(II) Module pcidata: vendor=The XFree86 Project
compiled for 4.4.99.901, module version = 1.0.0
ABI class: XFree86 Video Driver, version 0.8
(II) LoadModule: bitmap
(II) Loading /usr/X11R6.x86/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor=The XFree86 Project
compiled for 4.4.99.901, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.5
(II) Loading font Bitmap
(--) Using wscons driver in pcvt compatibility mode (version 3.32)
(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

Re: XFree 4.4.0 server crash on amd64 while running xsuite

2004-06-25 Thread Nicolas Joly 
On Thu, Jun 24, 2004 at 10:13:54AM -0700, Mark Vojkovich wrote:
It might be that there is some mismatch in types on amd64.
 Eg. FB_SHIFT vs FbBits.  It's hard to follow what's going on
 in fb.h.

Agreed, i'm not comfortable with that piece of code.

But, in my case, FB_SHIFT is defined to 5 and sizeof(FbBits) to 4.

 On Thu, 24 Jun 2004, Nicolas Joly wrote:
 
  On Thu, Jun 24, 2004 at 07:56:53AM -0400, David Dawes wrote:
   On Fri, Jun 18, 2004 at 02:55:17PM +0200, Nicolas Joly wrote:
   Hi,
   
   I just got a XFree 4.4.0 server crash, on my amd64 workstation while
   running XFree xsuite.
  
   Try running the XFree86 server from within gdb and see what the stack trace
   reports when it crashes.
 
  Program received signal SIGSEGV, Segmentation fault.
  0x006e939b in fbBltOne ()
  (gdb) bt
  #0  0x006e939b in fbBltOne ()
  #1  0x006f1d65 in fbPutXYImage ()
  #2  0x006f1985 in fbPutImage ()
  #3  0x0059790c in XAAPutImagePixmap ()
  #4  0x006ad91c in ProcPutImage ()
  #5  0x006aa40a in Dispatch ()
  #6  0x006bbc2a in main ()
  #7  0x00405568 in ___start ()
 
  --
  Nicolas Joly
 
  Biological Software and Databanks.
  Institut Pasteur, Paris.
  ___
  Devel mailing list
  [EMAIL PROTECTED]
  http://XFree86.Org/mailman/listinfo/devel
 
 ___
 Devel mailing list
 [EMAIL PROTECTED]
 http://XFree86.Org/mailman/listinfo/devel

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: XFree 4.4.0 server crash on amd64 while running xsuite

2004-06-25 Thread Nicolas Joly 
On Fri, Jun 25, 2004 at 10:53:07AM -0700, Mark Vojkovich wrote:
 On Fri, 25 Jun 2004, Nicolas Joly wrote:
 
  On Thu, Jun 24, 2004 at 10:13:54AM -0700, Mark Vojkovich wrote:
  It might be that there is some mismatch in types on amd64.
   Eg. FB_SHIFT vs FbBits.  It's hard to follow what's going on
   in fb.h.
 
  Agreed, i'm not comfortable with that piece of code.
 
  But, in my case, FB_SHIFT is defined to 5 and sizeof(FbBits) to 4.
 
There is some code in fb.h that suggests that it might have been
 expecting FB_SHIFT == 6 for amd64.  Seems like it should have worked
 either way though.

I thought about it, but the only define for FB_SHIFT (in fb.h):

#ifndef FB_SHIFT
#define FB_SHIFTLOG2_BITMAP_PAD
#endif

and LOG2_BITMAP_PAD is only defined in servermd.h :

#ifndef BITMAP_SCANLINE_PAD
#define BITMAP_SCANLINE_PAD  32
#define LOG2_BITMAP_PAD 5
#define LOG2_BYTES_PER_SCANLINE_PAD 2
#endif

I suspect it cannot be changed easily ...

Looks like it walked off the edge of the FbStip *src array.
 I suspect:
 
 src += srcStride;
or
 src += srcX  FB_STIP_SHIFT;
 
 is overincrementing.

I'll check this.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: XFree 4.4.0 server crash on amd64 while running xsuite

2004-06-24 Thread Nicolas Joly 
On Thu, Jun 24, 2004 at 07:56:53AM -0400, David Dawes wrote:
 On Fri, Jun 18, 2004 at 02:55:17PM +0200, Nicolas Joly wrote:
 Hi,
 
 I just got a XFree 4.4.0 server crash, on my amd64 workstation while
 running XFree xsuite.
 
 Try running the XFree86 server from within gdb and see what the stack trace
 reports when it crashes.

Program received signal SIGSEGV, Segmentation fault.
0x006e939b in fbBltOne ()
(gdb) bt
#0  0x006e939b in fbBltOne ()
#1  0x006f1d65 in fbPutXYImage ()
#2  0x006f1985 in fbPutImage ()
#3  0x0059790c in XAAPutImagePixmap ()
#4  0x006ad91c in ProcPutImage ()
#5  0x006aa40a in Dispatch ()
#6  0x006bbc2a in main ()
#7  0x00405568 in ___start ()

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: XFree 4.4.0 server crash on amd64 while running xsuite

2004-06-24 Thread Nicolas Joly 
On Thu, Jun 24, 2004 at 10:13:54AM -0700, Mark Vojkovich wrote:
It might be that there is some mismatch in types on amd64.
 Eg. FB_SHIFT vs FbBits.  It's hard to follow what's going on
 in fb.h.

Thanks, i'll try to have a look.

In the mean time, i just recompiled the XFree86 server with `-g -O0',
to get more information.

Program received signal SIGSEGV, Segmentation fault.
0x008aab5a in fbBltOne (src=0x1651000, srcStride=0, srcX=0, 
dst=0x163d120, dstStride=0, dstX=0, dstBpp=32, width=3200, height=79, 
fgand=3221225472, fgxor=1073741823, bgand=3221225472, bgxor=0)
at fbbltone.c:375
375 LoadBits;
(gdb) bt
#0  0x008aab5a in fbBltOne (src=0x1651000, srcStride=0, srcX=0, 
dst=0x163d120, dstStride=0, dstX=0, dstBpp=32, width=3200, height=79, 
fgand=3221225472, fgxor=1073741823, bgand=3221225472, bgxor=0)
at fbbltone.c:375
#1  0x008b7c5e in fbPutXYImage (pDrawable=0x163c000, pClip=0x141d660, 
fg=4294967295, bg=0, pm=1073741823, alu=3, opaque=1, x=0, y=0, width=100, 
height=90, src=0x1650f58, srcStride=4, srcX=0) at fbimage.c:265
#2  0x008b72cd in fbPutImage (pDrawable=0x163c000, pGC=0x1410c00, 
depth=32, x=0, y=0, w=100, h=90, leftPad=0, format=1, pImage=0x1645018 )
at fbimage.c:75
#3  0x00683e07 in XAAPutImagePixmap (pDraw=0x163c000, pGC=0x1410c00, 
depth=32, x=0, y=0, w=100, h=90, leftPad=0, format=1, pImage=0x1645018 )
at xaaGC.c:355
#4  0x0084ab73 in ProcPutImage (client=0x11b9600) at dispatch.c:2085
#5  0x00845de7 in Dispatch () at dispatch.c:446
#6  0x0085ecc7 in main (argc=6, argv=0x7f7fead8, 
envp=0x7f7feb10) at main.c:432

According to the trace, it seems to break in `LoadBits' macro.

#define LoadBits {\
if (leftShift) { \
bitsRight = *src++; \
bits = (FbStipLeft (bitsLeft, leftShift) | \
FbStipRight(bitsRight, rightShift)); \
bitsLeft = bitsRight; \
} else \
bits = *src++; \
}

(gdb) p src
$1 = (FbStip *) 0x1651000
(gdb) p *src
Error accessing memory address 0x1651000: Invalid argument.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

XFree 4.4.0 server crash on amd64 while running xsuite

2004-06-18 Thread Nicolas Joly 
Hi,

I just got a XFree 4.4.0 server crash, on my amd64 workstation while
running XFree xsuite.

This machine is a dual Opteron, with 1GB of RAM, nVidia GeForce FX
5200, running NetBSD -current (20040616).

XFree86 Version 4.4.0
Release Date: 29 February 2004
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System:NetBSD/amd64 2.0F - The NetBSD Foundation, Inc.
Current Operating System: NetBSD lanfeust.sis.pasteur.fr 2.0F NetBSD 2.0F (LANFEUST) 
#2: Wed Jun 16 22:15:01 CEST 2004  [EMAIL 
PROTECTED]:/local/src/NetBSD/obj/amd64/sys/arch/amd64/compile/LANFEUST amd64
Build Date: 18 June 2004
[...]
(--) NV(0): Chipset: GeForce FX 5200
(**) NV(0): Depth 24, (--) framebuffer bpp 32
(==) NV(0): RGB weight 888
(==) NV(0): Default visual is TrueColor
(==) NV(0): Using HW cursor
(--) NV(0): DDC detected a CRT:
(II) NV(0): Manufacturer: IVM  Model: 1918  Serial#: 50006647
(II) NV(0): Year: 2000  Week: 39
(II) NV(0): EDID Version: 1.1
(II) NV(0): Using CRT on CRTC 0
(--) NV(0): VideoRAM: 131072 kBytes
(==) NV(0): Using gamma correction (1.0, 1.0, 1.0)
(WW) NV(0): config file hsync range 30-115kHz not within DDC hsync ranges.
(WW) NV(0): config file vrefresh range 50-160Hz not within DDC vrefresh ranges.
(II) NV(0): Monitor0: Using hsync range of 30.00-115.00 kHz
(II) NV(0): Monitor0: Using vrefresh range of 50.00-160.00 Hz
(II) NV(0): Clock range:  12.00 to 350.00 MHz
[...]
   *** If unresolved symbols were reported above, they might not
   *** be the reason for the server aborting.

Fatal server error:
Caught signal 11.  Server aborting

Here follow the last part of the xsuite journal:

[...]
520|235 1 4259 1 92|TRACE:--- Running test with pixmap depth 16
520|235 1 4259 1 93|TRACE:XYPixmap
520|235 1 4259 1 94|CHECK:XPutImage-1  40, line 388
520|235 1 4259 1 95|TRACE:ZPixmap
520|235 1 4259 1 96|CHECK:XPutImage-1  41, line 415
520|235 1 4259 1 97|TRACE:XYBitmap
520|235 1 4259 1 98|CHECK:XPutImage-1  42, line 441
520|235 1 4259 1 99|TRACE:--- Running test with pixmap depth 32
520|235 1 4259 1 100|TRACE:XYPixmap
520|235 1 4259 1 101|REPORT:A fatal I/O error occurred
520|235 1 4259 1 102|REPORT:Any following results can not be relied upon
80|235 2 14:32:57|TC End
10|236 /tset/CH06/qrybstcrsr/qrybstcrsr 14:32:57|TC Start, scenario ref 287-1, ICs 
{all}
15|236 1.9 1|TCM Start
520|236 0 18294 1 1|TRACE:NAME: XQueryBestCursor
520|236 0 18294 1 2|REPORT:Could not open display.  Can not continue.
[...]

Thanks in advance,
Regards.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

CVS XFree (s3virge driver) xsuite failures

2004-01-30 Thread Nicolas Joly 

Hi,

I just ran CVS xsuite againt CVS XFree on a NetBSD i386 -current
workstation, and noticed some failures.

This is a S3 ViRGE/DX card, and the X server is configured to display
1024x768 screen at depth 24.

XFree86 Version 4.3.99.902 (4.4.0 RC 2)
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: NetBSD/i386 1.6ZG [ELF] The NetBSD Foundation, Inc.
Current Operating System: NetBSD cluster2.sis.pasteur.fr 1.6ZC NetBSD 1.6ZC (GEN
ERIC) #5: Mon Oct 13 13:35:54 CEST 2003  [EMAIL PROTECTED]:/local/src/Net
BSD/obj/i386/sys/arch/i386/compile/GENERIC i386
Build Date: 29 January 2004
Changelog Date: 27 January 2004
[...]
(**) S3VIRGE(0): Depth 24, (--) framebuffer bpp 24
(==) S3VIRGE(0): RGB weight 888
(==) S3VIRGE(0): Default visual is TrueColor
[...]
(II) S3VIRGE(0): VESA BIOS detected
(II) S3VIRGE(0): VESA VBE Version 2.0
(II) S3VIRGE(0): VESA VBE Total Mem: 4096 kB
(II) S3VIRGE(0): VESA VBE OEM: S3 Incorporated. ViRGE /DX /GX
(II) S3VIRGE(0): VESA VBE OEM Software Rev: 1.1
(II) S3VIRGE(0): VESA VBE OEM Vendor: S3 Incorporated.
(II) S3VIRGE(0): VESA VBE OEM Product: ViRGE /DX /GX
(II) S3VIRGE(0): VESA VBE OEM Product Rev: Rev B
(--) S3VIRGE(0): Chipset: virge dx
(==) S3VIRGE(0): XVideo supported.
[...]

Here folloe the 41 failed tests :

Tests for XConfigureWindow
Test   3:  FAIL
Tests for XResizeWindow
Test   2:  FAIL
Tests for XCopyArea
Test   6:  FAIL
Test   7:  FAIL
Test   8:  FAIL
Test   9:  FAIL
Test  12:  FAIL
Test  14:  FAIL
Test  15:  FAIL
Test  16:  FAIL
Test  17:  FAIL
Test  18:  FAIL
Test  19:  FAIL
Test  20:  FAIL
Test  21:  FAIL
Test  22:  FAIL
Test  23:  FAIL
Tests for XDrawArc
Test  42:  FAIL
Test  63:  FAIL
Test  66:  FAIL
Test  73:  FAIL
Tests for XDrawArcs
Test  45:  FAIL
Test  53:  FAIL
Test  66:  FAIL
Test  69:  FAIL
Test  76:  FAIL
Tests for XDrawLines
Test  27:  FAIL
Test  72:  FAIL
Tests for XDrawRectangle
Test  39:  FAIL
Tests for XDrawRectangles
Test  41:  FAIL
Test  45:  FAIL
Tests for XDrawSegments
Test  40:  FAIL
Tests for XFillPolygon
Test  30:  FAIL
Tests for XFillRectangle
Test  24:  FAIL
Tests for XGetImage
Test   2:  FAIL
Test   4:  FAIL
Tests for XPutImage
Test  12:  FAIL
Test  15:  FAIL
Test  29:  FAIL
Test  31:  FAIL
Tests for ChangeHosts
Test   1:  FAIL

Attached xsuite full report.

Hope this helps,
Regards.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.


s3virge.24.gz
Description: application/gunzip

Re: CVS XFree (savage driver) xsuite failures

2004-01-25 Thread Nicolas Joly 
On Tue, Jan 20, 2004 at 10:32:12PM +0100, Nicolas Joly wrote:
 On Tue, Jan 20, 2004 at 10:28:16AM -0800, Mark Vojkovich wrote:
  
 If you add to the Section Device of the XF86Config file:
  
   Option XaaNoSolidTwoPointLine
  
that will force the XAA to only use the driver's Bresenham line
  export.  Does that change the behavior?
 
 Yes ! I do not see the problem with the linetest program anymore.
 Will check (in a day or two) with the testsuite, and report.

I just ran the testsuite again. Here follow the diff for the failing
tests :

[EMAIL PROTECTED] [~] diff fail.24.old fail.24.new
0a1,3
 Tests for XOpenDisplay
 Test   3:  FAIL
 Test   4:  FAIL
11,16d13
 Tests for XDrawLine
 Test  52:  FAIL
 Tests for XDrawLines
 Test  57:  FAIL
 Tests for XDrawSegments
 Test  53:  FAIL
24,25d20
 Tests for ChangeHosts
 Test   1:  FAIL

With XaaNoSolidTwoPointLine option set, XDraw{Line,Lines,Segements}
tests are successful.

For the `ChangeHosts' failure, i changed the `XT_DISPLAYHOST'
testsuite variable from `localhost' to `cixy.dial.pasteur.fr'.
This test succeded, but 2 new failed ... XOpenDisplay. Without network
connection, i think this is expected :

Tests for XOpenDisplay
Test   3:  FAIL
  XOpenDisplay() returned NULL with argument cixy.dial.pasteur.fr:0.0.
Test   4:  FAIL
  XOpenDisplay() returned NULL with argument cixy.dial.pasteur.fr:0.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

CVS XFree (savage driver) xsuite failures

2004-01-19 Thread Nicolas Joly 
Hi,

I just ran CVS xsuite againt CVS XFree on my NetBSD i386 -current
workstation, and noticed some failures.

The video card is a ProSavage KM133, and the X server default depth is
fixed to value 24.

XFree86 Version 4.3.99.902 (4.4.0 RC 2)
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: NetBSD/i386 1.6ZH [ELF] The NetBSD Foundation,
Inc.
Current Operating System: NetBSD cixy.dial.pasteur.fr 1.6ZH NetBSD
1.6ZH (GENERIC) #27: Sat Jan 17 10:34:18 CET 2004 [EMAIL 
PROTECTED]:/local/src/NetBSD/obj/i386/sys/arch/i386/compile/GENERIC i386
Build Date: 18 January 2004
Changelog Date: 17 January 2004
[...]
(**) SAVAGE(0): Depth 24, (--) framebuffer bpp 32
(==) SAVAGE(0): RGB weight 888
(==) SAVAGE(0): Default visual is TrueColor
(--) SAVAGE(0): Chip: id 8a26, ProSavage KM133
(--) SAVAGE(0): Engine: ProSavage
(==) SAVAGE(0): Using gamma correction (1.0, 1.0, 1.0)
(--) SAVAGE(0): probed videoram:  16384k
(--) SAVAGE(0): Detected current MCLK value of 14.318 MHz
(II) SAVAGE(0): Monitor0: Using hsync range of 30.00-70.00 kHz
(II) SAVAGE(0): Monitor0: Using vrefresh range of 47.00-120.00 Hz
(II) SAVAGE(0): Clock range:  10.00 to 220.00 MHz
[...]

Just a small summary with 16 tests failues :

Tests for XDrawArc
Test  42:  FAIL
Test  63:  FAIL
Test  66:  FAIL
Test  73:  FAIL
Tests for XDrawArcs
Test  45:  FAIL
Test  66:  FAIL
Test  69:  FAIL
Test  76:  FAIL
Tests for XDrawLine
Test  52:  FAIL
Tests for XDrawLines
Test  57:  FAIL
Tests for XDrawSegments
Test  53:  FAIL
Tests for XChangeKeyboardControl
Test   9:  FAIL
Test  10:  FAIL
Tests for XKillClient
Test   2:  FAIL
Tests for XRebindKeysym
Test   1:  FAIL
Tests for ChangeHosts
Test   1:  FAIL

Attached the xsuite full output.

Hope this helps,
Regards.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.


savage.24.gz
Description: application/gunzip

Re: CVS XFree (savage driver) xsuite failures

2004-01-19 Thread Nicolas Joly 
On Mon, Jan 19, 2004 at 03:11:17PM -0800, Mark Vojkovich wrote:
 On Mon, 19 Jan 2004, David Dawes wrote:
 
  On Mon, Jan 19, 2004 at 10:11:53PM +0100, Nicolas Joly wrote:
  
  Just a small summary with 16 tests failues :
  
  Tests for XDrawArc
  Test  42:  FAIL
  Test  63:  FAIL
  Test  66:  FAIL
  Test  73:  FAIL
  Tests for XDrawArcs
  Test  45:  FAIL
  Test  66:  FAIL
  Test  69:  FAIL
  Test  76:  FAIL
  
  The arc failures here look like the expected ones.
 
Yes, those are waived.
 
  
  Tests for XDrawLine
  Test  52:  FAIL
  Tests for XDrawLines
  Test  57:  FAIL
  Tests for XDrawSegments
  Test  53:  FAIL
  
  Those three are real.
 
Does the Savage hardware really have a Bresenham line interface?
 If so, why is it providing the TwoPointLine interface?
 
If your lines are correct, you should be able to run:
 http://www.xfree86.org/~mvojkovi/linetest.c
 without artifacts.

The lines seems wrong as i do see artifacts when running the program
with zero width lines (works fine for w0).

  Tests for XChangeKeyboardControl
  Test   9:  FAIL
  Test  10:  FAIL
  
  That has been showing up for a while.  It should be followed up.
 
That's been showing up for a couple years.  It's a regression.
 
  
  Tests for XKillClient
  Test   2:  FAIL
  
  I see the occasional XKillClient fail, but haven't been able to reproduce
  it reliably.  I'm not sure if it is a real bug, or a flaw in the test.
 
I've never seen that one.
 
  
  Tests for XRebindKeysym
  Test   1:  FAIL
  
  The XRebindKeysym failure goes away if XKB is disabled.
 
Yes, it's a XKB problem/feature.
 
  
  Tests for ChangeHosts
  Test   1:  FAIL
  
  Maybe you didn't set the hostname correctly for the test?
 
Looks like a test configuration error.

It was setup to `localhost'. This machine has no real network access
(just a 28.8k ppp line) ... Will try again with a real name.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: [XFree86] Can't start X with I830M chipset, 8MB preallocated video RAM

2003-12-16 Thread Nicolas Joly 
On Mon, Dec 15, 2003 at 02:32:29PM -0800, Gabriel Bauman wrote:
 
 If it helps any driver developers, the BIOS I'm working with is
 inside a Dell Inspiron 2600 laptop and is release A09. I would go
 harass Dell but I don't know what to ask for. If anyone can confirm
 my take on this issue, I'd appreciate it.

This is a known problem. Bios A09 for Inspiron 2600 is badly broken
and won't work with Xfree ... Just use A08 revision instead.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86

Re: [XFree86] RESOLVED: I830WaitLpRing() lockup

2003-10-21 Thread Nicolas Joly 
On Tue, Oct 21, 2003 at 08:07:59AM -0600, Marc Aurele La France wrote:
 On Tue, 21 Oct 2003, Alexey E. Suslikov wrote:
 
   I haven't been following this too closely, but was this happening only
   on BSDs?  The VBE thing stuck out in my mind, as there was just an issue
   in DRI (the radeon mergedfb changes) where using the generic int10
   emulation caused the driver to crash, while the linux-specific one
   didn't.  I don't think it got tracked down and a later change fixed it,
   but might there be general problems with the generic int10 emulation?  I
   know many FreeBSD systems get warnings in the logs about Bad V_BIOS
   checksum.  Would any of this be significant?
 
  yes, i see this Bad V_BIOS checksum in logs on my OpenBSD. hope, Nicolas
  with NetBSD too :)
 
 With 4.3's generic int10?  Or CVS's?  There have been a number fixes made
 to genric int10 since 4.3.

Same message under NetBSD, with CVS -current version :

XFree86 Version 4.3.99.14
Release Date: 10 October 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 (CAL
AMITY) #0: Fri Oct  3 09:56:38 CEST 2003  [EMAIL PROTECTED]:/local/s
rc/NetBSD/objs/local/src/NetBSD/src/sys/arch/i386/compile/CALAMITY i386
Build Date: 21 October 2003
Changelog Date: 21 October 2003
[...]
(II) Reloading /usr/X11R6/lib/modules/libint10.a
(II) I810(0): initializing int10
(WW) I810(0): remove MTRR a - c
(WW) I810(0): remove MTRR c - 10
(WW) I810(0): Bad V_BIOS checksum
(II) I810(0): Primary V_BIOS segment is: 0xc000
(WW) I810(0): remove MTRR 0 - 1000
(II) I810(0): VESA BIOS detected
(II) I810(0): VESA VBE Version 3.0
(II) I810(0): VESA VBE Total Mem: 8000 kB
[...]

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86

Re: [XFree86] RESOLVED: I830WaitLpRing() lockup

2003-10-20 Thread Nicolas Joly 
On Mon, Oct 20, 2003 at 11:13:12AM +0300, Alexey E. Suslikov wrote:
 keywords: openbsd, x11, i830, ring buffer, lockup
 
  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) {
 
 hmmm... my yesterdays reply was lost somewhere... ok, let's repeat :)
 
 turning on I845G_VBE_WORKAROUND magically SOLVES the problem on
 4.3.99.14 in both accel and noaccel setups:
 
   VideoRam
 default(8192)  2048  32768
 Accelok ok ok
 NoAccel  ok ok ok
 NoAccel+SWcursor ok ok ok

I just made the same modification on my NetBSD (-current) Dell laptop
with i830 chipset.

Everything seems to work fine now ... I can restart X without
rebooting the machine and VT switching works flawlessly.

Great job,
Thanks.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86

Re: [XFree86] All annoying error in I830WaitLpRing() in some details

2003-10-09 Thread Nicolas Joly 
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

2003-10-08 Thread Nicolas Joly 
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

2003-10-06 Thread Nicolas Joly 
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