Bug#622401: xserver-xorg-video-trident: Error message and exit with iceape and iceweasel. One solution.
This bug report can be closed, as there is no sign of it in the Debian Squeeze version (6.0.5). -- Bjarni I. Gislason -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120627204031.ga20...@rhi.hi.is
Bug#622401: xserver-xorg-video-trident: Error message and exit with iceape and iceweasel. One solution.
On Sun, May 08, 2011 at 10:26:00AM +0200, Julien Cristau wrote: > On Sun, May 8, 2011 at 01:25:01 +, Bjarni Ingi Gislason wrote: > > > The "X" server issues "PreInit" that maps and unmaps. Then it > > issues "ScreenInit" which maps. > > > > "iceweasel" causes a second map though "ScreenInit", which > > leads to error. > > > That should never happen. ScreenInit is called at the start of a > session, and CloseScreen should be called before the next ScreenInit. > That's not a client bug. > You are probably right. I have made some more tests in the trident driver code. Unmapping is only done in "CloseScreen", if "vtSema" is true. If I switch terminals after issuing a single "X &" command to issue "iceweasel", then "vtSema" is false in the next "CloseScreen". "iceweasel" switches automatically to the X display, but "xpdf" does not do it. If I transfer the "TRIDENTUnmapMem(pScrn)" subroutine outside the "if (pScrn->vtSema)" block, then the missing unmapping occurs. A comment in the code before "CloseScreen" is: "It should really also unmap the video memory too." The conditions to trigger the error (using "libpciaccess") are 1) change from the X display (pure server, e.g. "X -retro &") to a text terminal 2) issue a X client (in the background) that automatically switches to the X display. Other video drivers should be tested in this way. -- Bjarni I. Gislason -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110511185039.ga24...@rhi.hi.is
Bug#622401: xserver-xorg-video-trident: Error message and exit with iceape and iceweasel. One solution.
On Sun, May 8, 2011 at 01:25:01 +, Bjarni Ingi Gislason wrote: > The "X" server issues "PreInit" that maps and unmaps. Then it > issues "ScreenInit" which maps. > > "iceweasel" causes a second map though "ScreenInit", which > leads to error. > That should never happen. ScreenInit is called at the start of a session, and CloseScreen should be called before the next ScreenInit. That's not a client bug. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110508082600.gq2...@radis.liafa.jussieu.fr
Bug#622401: xserver-xorg-video-trident: Error message and exit with iceape and iceweasel. One solution.
On Fri, Apr 29, 2011 at 09:35:38PM +0200, Julien Cristau wrote: > On Fri, Apr 29, 2011 at 18:15:11 +, Bjarni Ingi Gislason wrote: > > > On Thu, Apr 28, 2011 at 06:03:07PM +, Bjarni Ingi Gislason wrote: > > > On Fri, Apr 15, 2011 at 07:50:03PM +, Bjarni Ingi Gislason wrote: > > > > On Tue, Apr 12, 2011 at 07:25:21PM +, Bjarni Ingi Gislason wrote: > > > > > Package: xserver-xorg-video-trident > > > > > Version: 1:1.3.4-2 > > > > > Severity: important > > > > > > > > > > *** Please type your report below this line *** > > > > > > > > > > If "iceweasel" or "iceape" are used, there is an error message > > > > > and exit. > > > > > > > > > > (EE) TRIDENT(0): Unable to map IO aperture. Invalid argument (22) > > > > > Fatal server error: > > > > > AddScreen/ScreenInit failed for driver 0 > > > > > ... > > > > > Error: cannot open display: :0 > > > > > > > > > > > Some data related to the PCI bus. > > > > > > > There is a name error in "devp->num_mappings[0]"; it should be > > "devp->mappings[0]". > > > > > This causes error 22 (EINVAL), that trident reports: > > > > > > libpciaccess: common_interface.c: Already mapped is > > > "devp->num_mappings[0]" with devp->num_mappings = 2, base = > > > 0xfe7f, and size = 0x1 > > > > > > [Rest is removed] > > > > (The commands that I use are "X &" and "iceweasel &" on a text > > terminal.) > > > > I have to eliminate the "return EINVAL;" statement to get the > > browser to function. > > > Sounds like a pci_device_unmap_range is missing from the CloseScreen > path. If you can figure that out from the driver that would be nice. > > In theory, as far as I can tell: > - the IO bar is mapped in TRIDENTPreInit, then unmapped before > TRIDENTPreInit returns > - it's mapped again in each server generation's TRIDENTScreenInit, and > unmapped in TRIDENTCloseScreen > I'm not seeing the error by quick inspection, but I may be missing > something obvious... > The "X" server issues "PreInit" that maps and unmaps. Then it issues "ScreenInit" which maps. "iceweasel" causes a second map though "ScreenInit", which leads to error. If I use "xinit /usr/bin/iceweasel", then there is no second "ScreenInit" (only "PreInit" and "ScreenInit"). If I use "X &; iceweasel &", then there is no error, because of "PreInit", "ScreenInit", "CloseScreen" and "ScreenInit". I usually issue "X -retro" (to see the mouse cursor) and wait for the server to come up before I issue another X program. The fault lies in the second "ScreenInit". The fault lies thus with "iceweasel", "iceape", and any other client that causes a "ScreenInit" (without "CloseScreen") if used directly with an "X" server This bug report can be closed. I will issue a report against "iceweasel" and "iceape" as I find, that clients should work directly with the X sever, without complicating matters with "xinit" or other similar programmes. "xpdf" and "gv" cause no second "ScreenInit". -- Bjarni I. Gislason -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110508012501.ga7...@rhi.hi.is
Bug#622401: xserver-xorg-video-trident: Error message and exit with iceape and iceweasel. One solution.
On Fri, Apr 29, 2011 at 18:15:11 +, Bjarni Ingi Gislason wrote: > On Thu, Apr 28, 2011 at 06:03:07PM +, Bjarni Ingi Gislason wrote: > > On Fri, Apr 15, 2011 at 07:50:03PM +, Bjarni Ingi Gislason wrote: > > > On Tue, Apr 12, 2011 at 07:25:21PM +, Bjarni Ingi Gislason wrote: > > > > Package: xserver-xorg-video-trident > > > > Version: 1:1.3.4-2 > > > > Severity: important > > > > > > > > *** Please type your report below this line *** > > > > > > > > If "iceweasel" or "iceape" are used, there is an error message > > > > and exit. > > > > > > > > (EE) TRIDENT(0): Unable to map IO aperture. Invalid argument (22) > > > > Fatal server error: > > > > AddScreen/ScreenInit failed for driver 0 > > > > ... > > > > Error: cannot open display: :0 > > > > > > > > Some data related to the PCI bus. > > > > There is a name error in "devp->num_mappings[0]"; it should be > "devp->mappings[0]". > > > This causes error 22 (EINVAL), that trident reports: > > > > libpciaccess: common_interface.c: Already mapped is > > "devp->num_mappings[0]" with devp->num_mappings = 2, base = > > 0xfe7f, and size = 0x1 > > > > [Rest is removed] > > (The commands that I use are "X &" and "iceweasel &" on a text > terminal.) > > I have to eliminate the "return EINVAL;" statement to get the > browser to function. > Sounds like a pci_device_unmap_range is missing from the CloseScreen path. If you can figure that out from the driver that would be nice. In theory, as far as I can tell: - the IO bar is mapped in TRIDENTPreInit, then unmapped before TRIDENTPreInit returns - it's mapped again in each server generation's TRIDENTScreenInit, and unmapped in TRIDENTCloseScreen I'm not seeing the error by quick inspection, but I may be missing something obvious... Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110429193538.gb2...@radis.liafa.jussieu.fr
Bug#622401: xserver-xorg-video-trident: Error message and exit with iceape and iceweasel. One solution.
On Thu, Apr 28, 2011 at 06:03:07PM +, Bjarni Ingi Gislason wrote: > On Fri, Apr 15, 2011 at 07:50:03PM +, Bjarni Ingi Gislason wrote: > > On Tue, Apr 12, 2011 at 07:25:21PM +, Bjarni Ingi Gislason wrote: > > > Package: xserver-xorg-video-trident > > > Version: 1:1.3.4-2 > > > Severity: important > > > > > > *** Please type your report below this line *** > > > > > > If "iceweasel" or "iceape" are used, there is an error message > > > and exit. > > > > > > (EE) TRIDENT(0): Unable to map IO aperture. Invalid argument (22) > > > Fatal server error: > > > AddScreen/ScreenInit failed for driver 0 > > > ... > > > Error: cannot open display: :0 > > > > > Some data related to the PCI bus. > There is a name error in "devp->num_mappings[0]"; it should be "devp->mappings[0]". > This causes error 22 (EINVAL), that trident reports: > > libpciaccess: common_interface.c: Already mapped is > "devp->num_mappings[0]" with devp->num_mappings = 2, base = > 0xfe7f, and size = 0x1 > > [Rest is removed] (The commands that I use are "X &" and "iceweasel &" on a text terminal.) I have to eliminate the "return EINVAL;" statement to get the browser to function. Some output from an inserted "fprintf" statement before the (removed) "return EINVAL;". The list is cumulative (fopen(..., "a")). Each output line starts with "libpciaccess: common_interface.c: Already mapped is " "devp->mappings[0]" with devp->num_mappings = 4, base = 0xfe7f, and size = 0x1 "devp->mappings[2]" with devp->num_mappings = 4, base = 0xfe7f, and size = 0x1 "devp->mappings[1]" with devp->num_mappings = 5, base = 0xfdc0, and size = 0x20 "devp->mappings[3]" with devp->num_mappings = 5, base = 0xfdc0, and size = 0x20 "devp->mappings[0]" with devp->num_mappings = 4, base = 0xfe7f, and size = 0x1 "devp->mappings[2]" with devp->num_mappings = 4, base = 0xfe7f, and size = 0x1 "devp->mappings[1]" with devp->num_mappings = 5, base = 0xfdc0, and size = 0x20 "devp->mappings[3]" with devp->num_mappings = 5, base = 0xfdc0, and size = 0x20 "devp->mappings[0]" with devp->num_mappings = 6, base = 0xfe7f, and size = 0x1 "devp->mappings[2]" with devp->num_mappings = 6, base = 0xfe7f, and size = 0x1 "devp->mappings[4]" with devp->num_mappings = 6, base = 0xfe7f, and size = 0x1 "devp->mappings[1]" with devp->num_mappings = 7, base = 0xfdc0, and size = 0x20 "devp->mappings[3]" with devp->num_mappings = 7, base = 0xfdc0, and size = 0x20 "devp->mappings[5]" with devp->num_mappings = 7, base = 0xfdc0, and size = 0x20 "devp->mappings[0]" with devp->num_mappings = 6, base = 0xfe7f, and size = 0x1 "devp->mappings[2]" with devp->num_mappings = 6, base = 0xfe7f, and size = 0x1 "devp->mappings[4]" with devp->num_mappings = 6, base = 0xfe7f, and size = 0x1 "devp->mappings[1]" with devp->num_mappings = 7, base = 0xfdc0, and size = 0x20 "devp->mappings[3]" with devp->num_mappings = 7, base = 0xfdc0, and size = 0x20 "devp->mappings[5]" with devp->num_mappings = 7, base = 0xfdc0, and size = 0x20 "devp->mappings[0]" with devp->num_mappings = 8, base = 0xfe7f, and size = 0x1 "devp->mappings[2]" with devp->num_mappings = 8, base = 0xfe7f, and size = 0x1 "devp->mappings[4]" with devp->num_mappings = 8, base = 0xfe7f, and size = 0x1 "devp->mappings[6]" with devp->num_mappings = 8, base = 0xfe7f, and size = 0x1 "devp->mappings[1]" with devp->num_mappings = 9, base = 0xfdc0, and size = 0x20 "devp->mappings[3]" with devp->num_mappings = 9, base = 0xfdc0, and size = 0x20 "devp->mappings[5]" with devp->num_mappings = 9, base = 0xfdc0, and size = 0x20 "devp->mappings[7]" with devp->num_mappings = 9, base = 0xfdc0, and size = 0x20 "devp->mappings[0]" with devp->num_mappings = 8, base = 0xfe7f, and size = 0x1 "devp->mappings[2]" with devp->num_mappings = 8, base = 0xfe7f, and size = 0x1 "devp->mappings[4]" with devp->num_mappings = 8, base = 0xfe7f, and size = 0x1 "devp->mappings[6]" with devp->num_mappings = 8, base = 0xfe7f, and size = 0x1 "devp->mappings[1]" with devp->num_mappings = 9, base = 0xfdc0, and size = 0x20 "devp->mappings[3]" with devp->num_mappings = 9, base = 0xfdc0, and size = 0x20 "devp->mappings[5]" with devp->num_mappings = 9, base = 0xfdc0, and size = 0x20 "devp->mappings[7]" with devp->num_mappings = 9, base = 0xfdc0, and size = 0x20 "devp->mappings[0]" with devp->num_mappings = 10, base = 0xfe7f, and size = 0x1 "devp->mappings[2]" with devp->num_mappings = 10, base = 0xfe7f, and size = 0x1 "devp->mappings[4]" with devp->num_mappings = 10, base = 0xfe7f, and size = 0x1 "devp->mappings[6]" with devp->num_mappings = 10, base = 0xfe7f, and size = 0x1 "devp->mappings[8]" with devp->num_m
