Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
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] CVS XFree86 i830 failure on DELL inspiron 2600
On Mon, Feb 28, 2005 at 04:59:26PM +0100, Nicolas Joly wrote: 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 ... That's good news! I'll commit the patch. David ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
On Fri, Feb 25, 2005 at 07:35:37PM +0100, Nicolas Joly wrote: On Wed, Feb 23, 2005 at 08:44:16PM -0500, David Dawes wrote: On Mon, Feb 21, 2005 at 03:01:29PM +0100, Nicolas Joly wrote: On Fri, Feb 18, 2005 at 05:04:15PM -0500, David Dawes wrote: On Fri, Feb 18, 2005 at 07:51:56PM +0100, Nicolas Joly wrote: On Thu, Feb 17, 2005 at 04:20:12PM -0500, David Dawes wrote: [...] 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 ? The easiest way to do that would be to edit the xf86ExecX86int10_wrapper() macro in i810/common.h and have it print out the ax, bx and cx fields of pInt. I would try that with and without enabling the PrintErrorState() calls that are there. Attached the 2 logs for 4.4.0 and 4.5.0 with int10 ax,bx and cx values, but without PrintErrorState. I'm starting to recompile the modules to include the PrintErrorState() calls ... I've had a look through the logs you sent, but I don't see anything obvious problem. The following lines in one of the logs are not good: (WW) I810(0): PRB0_CTL (0x000b6007) indicates ring buffer enabled (WW) I810(0): PRB0_HEAD (0x008b662c) and PRB0_TAIL (0x00092660) indicate ring buffer not flushed but they don't appear in the second set of logs. Yes. I don't always have them, but i can't figure why yet. The only other thing I can think of right now is to trace through which call to VBESetVBEMode is made, and print the parameters in each case, and call I830_dump_registers() before the VBESetVBEMode() calls. You'll need to build with I830DEBUG defined (uncomment it in i830.h). Log file attached. I made some other tests today and noticed a few things: - The loop problem only occurs with the unusual 1024x600 mode. Even Windows does not deal with that mode. Looks like a BIOS bug ? Most likely, yes. - 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. 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. David ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
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: I made some other tests today and noticed a few things: - The loop problem only occurs with the unusual 1024x600 mode. Even Windows does not deal with that mode. Looks like a BIOS bug ? Most likely, yes. - 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. David ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
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
On Fri, Feb 18, 2005 at 07:51:56PM +0100, Nicolas Joly wrote: 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. OK, so that all points to the driver changes. 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 ? The easiest way to do that would be to edit the xf86ExecX86int10_wrapper() macro in i810/common.h and have it print out the ax, bx and cx fields of pInt. I would try that with and without enabling the PrintErrorState() calls that are there. David ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
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
Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
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 ! > > 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()'. The problem is not here. The problem happened during the I830xxx calls. I am still studying the data sheet. It seems a register/functionality is not present on the device. You can use the vesa driver if you need a working box for now. > 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
Re: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
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 ! 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()'. 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. 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. 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. Does the vesa driver still work OK? Works fine, at least, with 1024x768 at depth 16. That's good to know. David ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
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: [XFree86] CVS XFree86 i830 failure on DELL inspiron 2600
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. Does the vesa driver still work OK? 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. David 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
