Bug#216933: more thoughts on the X_ChangeProperty problem
Michel Dänzer wrote: > > xiTK WARNING(_x_error_handler:215): X error received: 'BadLength (poly > > request too large or internal Xlib length error)' > > xine seems to be able to deal with the error; many (most?) X apps don't > do any error handling, so AFAIK they get killed by the default libX11 > error handler. Oh, hmm, I suppose that explains why ion-devel (my window manager) also deals with the problem despite spewing errors every window switch. -- see shy jo signature.asc Description: Digital signature
Bug#216933: more thoughts on the X_ChangeProperty problem
On Wed, 2004-01-21 at 11:16, Christopher Hart wrote: > So this evening I've hit the bug - 3 times. I'm not doing anything > special, but I did stumble upon an interesting quark to the problem. > Xine works after the "crash". [...] > xiTK WARNING(_x_error_handler:215): X error received: 'BadLength (poly > request too large or internal Xlib length error)' xine seems to be able to deal with the error; many (most?) X apps don't do any error handling, so AFAIK they get killed by the default libX11 error handler. > xiTK WARNING(xitk_image_create_xitk_pixmap_with_depth:231): XShmAttach() > failed. If this is related, it could point to shared memory? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#216933: more thoughts on the X_ChangeProperty problem
So this evening I've hit the bug - 3 times. I'm not doing anything special, but I did stumble upon an interesting quark to the problem. Xine works after the "crash". If I run xclock - I get the the standard: --- begin paste --- X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 18 (X_ChangeProperty) Serial number of failed request: 31 Current serial number in output stream: 34 --- end past --- If I run xine, it works!? In case its informative, here is the log - note the xiTK warning at the end. Interestingly, neither gxine or mplayer work... even using the x11 or xv video drivers (the same ones that worked with xine). -- begin paste-- This is xine (X11 gui) - a free video player v0.9.21 (c) 2000-2003 by G. Bartsch and the xine project team. Built with xine library 1.0.0 (1-beta12) Found xine library version: 1.0.0 (1-rc2). XServer Vendor: The XFree86 Project, Inc. Release: 40201001, Protocol Version: 11, Revision: 0, Available Screen(s): 1, using 0 Depth: 16. XShmQueryVersion: 1.1. -[ xiTK version 0.10.3 ]- -[ xiTK will use XShm ]- -[ WM type: dtwm ]- Display is not using Xinerama. deinterlace: Greedy disabled: required CPU accelleration features unavailable. deinterlace: Greedy2Frame disabled: required CPU accelleration features unavailable. deinterlace: Vertical disabled: required CPU accelleration features unavailable. main: probing audio output plugin load_plugins: failed to load audio output plugin main: probing audio output plugin xine_interface: unknown param 10 xine_interface: unknown param 10 xine_interface: unknown param 10 xine_interface: unknown param 10 video_out_xshm: tried to set unsupported property 2 xiTK WARNING(_x_error_handler:215): X error received: 'BadLength (poly request too large or internal Xlib length error)' xiTK WARNING(xitk_image_create_xitk_pixmap_with_depth:231): XShmAttach() failed. -- end paste -- here is the relevant packages for xine that I'm running ii libxine0 0.9.13-3 the xine video/media player library, binary ii libxine1 1-rc2-1the xine video/media player library, binary ii xine-dvdnav0.9.8.beta-1 xine DVD plugin that is capable of Menus and ii xine-ui0.9.21-2 the xine video player, user interface Well. Perhaps this can help someone isolate where the problem might be. Otherwise, does someone have advice to what packages correspond to the slackware "SOLUTION". --thanks, Chris
Bug#216933: more thoughts on the X_ChangeProperty problem
On Wed, 2004-01-21 at 01:10, Joey Hess wrote: > Google has one relevant hit for "BadLength (poly request too large or > internal Xlib length error) fujitsu": > http://linuxquestions.org/questions/history/116108 > > Another Fujitsu P2110, running slackware. > X began "crashing" after he upgraded from slackare 9 to 10. > > He decided that an ATI patch from http://www.retinalburn.net/linux/ was > the root of the problem. That was only his first guess, read his last post with the heading 'SOLUTION'. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#216933: more thoughts on the X_ChangeProperty problem
Google has one relevant hit for "BadLength (poly request too large or internal Xlib length error) fujitsu": http://linuxquestions.org/questions/history/116108 Another Fujitsu P2110, running slackware. X began "crashing" after he upgraded from slackare 9 to 10. He decided that an ATI patch from http://www.retinalburn.net/linux/ was the root of the problem. I don't know if Debian's X has a similar patch. It might be worth a try to downgrade the X server to version 4.2.1-12 or 4.2.1-11 and see if we can track down exactly when it broke and whether older versions avoid the problem. I first saw the problem with 4.2.1-12.1, I think. I have installed 4.2.1-11 from snapshot.debian.net and will try it for a while or until the first BadLength crash.. -- see shy jo signature.asc Description: Digital signature
Bug#216933: more thoughts on the X_ChangeProperty problem
Tue, 20 Jan skrev Michel Dänzer ned dette:
MD> On Tue, 2004-01-20 at 19:51, Christopher Hart wrote:
>> > > I also started having this problem just this fall. The tranmetta
>> > > code-morphing bug is still plausible, but unless Joe's laptop is
>> > > significantly different from the p2120 a variety of the other components
>> > > might be at fault.
>> >
>> > It seems unlikely to me that we all experienced a similar hardware
>> > problem this fall. What other components did you have in mind?
>>
>> I guess all I can think of is our video card, I think we've all got the
>> same ATI Rage mobility M-1.
MD> That's very unlikely (the code which generates that error doesn't have
MD> anything to do with the graphics chip directly), Joey's theory seems
MD> much more likely to me.
I wonder, is it debian-related, or do all linux/X users with P21{1,2}0 have
this problem.
Have any of you posted on some P21xx forums?
--
[simula.research laboratory]
Åsmund Ødegård
IT-sjef / IT-Manager
phone: 67828291 / 90069915
http://www.simula.no/
-- auto sig --
ACT 11:7 And I heard a voice saying unto me, Arise, Peter; slay and eat.
Bug#216933: more thoughts on the X_ChangeProperty problem
Tue, 20 Jan skrev Joey Hess ned dette: JH> Åsmund Ødegård wrote: >> just like to tell you that I experience this problem as well. Even when only >> running a couple of rxvt's and emacs. >> >> I have never managed to recover without a reboot though, but thats probably >> because of impatience... >> >> Hardware: laptop, Fujitsu lifebook p2120 >> x: 4.3.0-0pre1v5, but I had the same problem with the xserver-xfree86 from >> sid JH> When did you start having the problem? I assume you're tracking sid; I JH> first saw it this fall. I'm not sure. Sometime before christmas for sure, but maybe as early as sept/october. Now its so annoying that I have started looking after some fix... Btw, today I did a /etc/init.d/gdm stop and used another computer for an hour or so, after that X worked again, as you guys suggested. mvh, -- [simula.research laboratory] Åsmund Ødegård IT-sjef / IT-Manager phone: 67828291 / 90069915 http://www.simula.no/ -- auto sig -- MAT 22:22 When they had heard these words, they marvelled, and left him, and went their way.
Bug#216933: more thoughts on the X_ChangeProperty problem
On Tue, 2004-01-20 at 19:51, Christopher Hart wrote: > > > I also started having this problem just this fall. The tranmetta > > > code-morphing bug is still plausible, but unless Joe's laptop is > > > significantly different from the p2120 a variety of the other components > > > might be at fault. > > > > It seems unlikely to me that we all experienced a similar hardware > > problem this fall. What other components did you have in mind? > > I guess all I can think of is our video card, I think we've all got the > same ATI Rage mobility M-1. That's very unlikely (the code which generates that error doesn't have anything to do with the graphics chip directly), Joey's theory seems much more likely to me. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#216933: more thoughts on the X_ChangeProperty problem
> > I also started having this problem just this fall. The tranmetta > > code-morphing bug is still plausible, but unless Joe's laptop is > > significantly different from the p2120 a variety of the other components > > might be at fault. > > It seems unlikely to me that we all experienced a similar hardware > problem this fall. What other components did you have in mind? I guess all I can think of is our video card, I think we've all got the same ATI Rage mobility M-1. --chris
Bug#216933: more thoughts on the X_ChangeProperty problem
Christopher Hart wrote: > > > > > > Hardware: laptop, Fujitsu lifebook p2120 > > > x: 4.3.0-0pre1v5, but I had the same problem with the xserver-xfree86 from > > >sid > > The trend continues... I also have a lifebook p2120. However I'm > running xserver-xfree86: 4.2.1-12.1. I forget whether I mentioned it, but mine is a lifeboot p2110. > > When did you start having the problem? I assume you're tracking sid; I > > first saw it this fall. > > I also started having this problem just this fall. The tranmetta > code-morphing bug is still plausible, but unless Joe's laptop is > significantly different from the p2120 a variety of the other components > might be at fault. It seems unlikely to me that we all experienced a similar hardware problem this fall. What other components did you have in mind? -- see shy jo signature.asc Description: Digital signature
Bug#216933: more thoughts on the X_ChangeProperty problem
> > > > Hardware: laptop, Fujitsu lifebook p2120 > > x: 4.3.0-0pre1v5, but I had the same problem with the xserver-xfree86 from > >sid The trend continues... I also have a lifebook p2120. However I'm running xserver-xfree86: 4.2.1-12.1. > When did you start having the problem? I assume you're tracking sid; I > first saw it this fall. I also started having this problem just this fall. The tranmetta code-morphing bug is still plausible, but unless Joe's laptop is significantly different from the p2120 a variety of the other components might be at fault. --chris
Bug#216933: more thoughts on the X_ChangeProperty problem
Åsmund Ødegård wrote: > just like to tell you that I experience this problem as well. Even when only > running a couple of rxvt's and emacs. > > I have never managed to recover without a reboot though, but thats probably > because of impatience... > > Hardware: laptop, Fujitsu lifebook p2120 > x: 4.3.0-0pre1v5, but I had the same problem with the xserver-xfree86 from >sid When did you start having the problem? I assume you're tracking sid; I first saw it this fall. -- see shy jo signature.asc Description: Digital signature
Bug#216933: more thoughts on the X_ChangeProperty problem
Mon, 19 Jan skrev Joey Hess: > It's almost encouraging to hear that Christopher Hart has the same > problem I do. I had begun to truely distrust my hardware. I wonder what > hardware Christopher is using? [snip] just like to tell you that I experience this problem as well. Even when only running a couple of rxvt's and emacs. I have never managed to recover without a reboot though, but thats probably because of impatience... Hardware: laptop, Fujitsu lifebook p2120 x: 4.3.0-0pre1v5, but I had the same problem with the xserver-xfree86 from sid -- [simula.research laboratory] Åsmund Ødegård Scientific Programmer / Chief Sys.Adm phone: 67828291 / 90069915 http://www.simula.no/~aasmundo -- auto sig -- LEV 19:33 And if a stranger sojourn with thee in your land, ye shall not vex him.
Bug#216933: more thoughts on the X_ChangeProperty problem
On Mon, 2004-01-19 at 20:26, Joey Hess wrote: > Joey Hess wrote: > > So: what if there is a bug in the optimizer, which generates incorrect > > optimised code for either the X server, or X library, but only > > sometimes. Some kind of math error might be involved. Once the badly > > optimised code pops up, it would stay in the cache and this would > > explain why even restarting X does not solve the problem. Presumably > > certian workloads would knock it out of the cache, which would explain > > the problem sometimes fixing itself. And rebooting the system (or > > software suspending it) would likewise clear the cache. > > Something else that backs up this idea is that one impression I have > gotten is that if I stop trying to open X apps that are going to fail > for a while, but keep doing stuff, X seems to recover quicker. Which > would be consistent with the badly optimised hunk of code being thrown > out of the cache because it was not being used. This is certainly the best theory I've heard so far. :\ -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#216933: more thoughts on the X_ChangeProperty problem
Joey Hess wrote: > So: what if there is a bug in the optimizer, which generates incorrect > optimised code for either the X server, or X library, but only > sometimes. Some kind of math error might be involved. Once the badly > optimised code pops up, it would stay in the cache and this would > explain why even restarting X does not solve the problem. Presumably > certian workloads would knock it out of the cache, which would explain > the problem sometimes fixing itself. And rebooting the system (or > software suspending it) would likewise clear the cache. Something else that backs up this idea is that one impression I have gotten is that if I stop trying to open X apps that are going to fail for a while, but keep doing stuff, X seems to recover quicker. Which would be consistent with the badly optimised hunk of code being thrown out of the cache because it was not being used. I'm going to switch my laptop over to suspend to disk instead of suspend to ram, I suspect that would let me recover from the problem posthaste by suspending and resuming the machine. -- see shy jo
Bug#216933: more thoughts on the X_ChangeProperty problem
It's almost encouraging to hear that Christopher Hart has the same problem I do. I had begun to truely distrust my hardware. I wonder what hardware Christopher is using? I still see the problem, on a perhaps slightly less frequent basis, but still every other day or so. I have not managed to correlate it with changes in temperature, or much else except I agree with Christopher that mozilla-firebird seems to often trigger it, as does xchat. I had a horrible idea this morning, that almost makes sense. My lifefook has a transmeta cpu in it, and this cpu has its code morhping technology, which recompiles the i386 code on the fly to it internal instruction set, and optimises it. As I understand it, the optimised form is then used for that block of code as long as it remains cached, even if a different program is started. So: what if there is a bug in the optimizer, which generates incorrect optimised code for either the X server, or X library, but only sometimes. Some kind of math error might be involved. Once the badly optimised code pops up, it would stay in the cache and this would explain why even restarting X does not solve the problem. Presumably certian workloads would knock it out of the cache, which would explain the problem sometimes fixing itself. And rebooting the system (or software suspending it) would likewise clear the cache. This is a dreadful idea, but if true then I predict that Christopher has a transmeta CPU as well. Frankly, I hope he doesn't.. Of course, I used X on this laptop for nearly 2 years before the problem surfaced, so it could easily be that the optimisation bug is triggered by something unlikely that has only recently been put in X, or in the version of gcc used to build it. Also, FWIW, I am now using the xserver-xfree86 4.3.0-0pre1v5 from experimental, but am still using the old libraries, and have still experienced the problem. -- see shy jo signature.asc Description: Digital signature
