Summary: | EnterVT/LeaveVT: crash with msg: [mi] EQ overflowing. The server is probably stuck in an infinite loop. (bisect attached) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Jochen Keil <j.keil> | ||||||
Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> | ||||||
Status: | RESOLVED NOTOURBUG | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | critical | ||||||||
Priority: | high | CC: | hhielscher, jeremyhu, mikey, stuffcorpse, z | ||||||
Version: | 7.5 (2009.10) | ||||||||
Hardware: | x86-64 (AMD64) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | 2011BRB_Reviewed | ||||||||
i915 platform: | i915 features: | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 40982 | ||||||||
Attachments: |
|
Description
Jochen Keil
2010-12-08 14:46:27 UTC
On Wed, Dec 08, 2010 at 02:46:28PM -0800, bugzilla-daemon@freedesktop.org wrote: > The X Server crashes after switching to a VT for the second time (the first > time it works without problems) with this backtrace: > > Backtrace: > 0: X (xorg_backtrace+0x28) [0x49ef08] > 1: X (0x400000+0x5ffb9) [0x45ffb9] > 2: /lib/libpthread.so.0 (0x7fe58f486000+0xf1c0) [0x7fe58f4951c0] > 3: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fe58a003000+0xbe19b) > [0x7fe58a0c119b] > 4: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fe58a003000+0xbe7b5) > [0x7fe58a0c17b5] > [...] > Segmentation fault at address 0x25 > > > This is the offending commit according to a bisect: > d75e8146c414bfd512ba5dbd4a83acb334bbe19b is the first bad commit > commit d75e8146c414bfd512ba5dbd4a83acb334bbe19b > Author: Keith Packard <keithp@keithp.com> > Date: Mon Jul 12 16:01:34 2010 -0700 > > Unwrap/rewrap EnterVT/LeaveVT completely, Fixes 28998 > > Because some EnterVT code needs to remove it self from the > call chain, we need to fix all of the wrappers to correctly > unwrap/rewrap during the call chain. This is a follow-on to the fix > for bug 27114 in commit 68a9ee8370e6f9b38218376ac92d5130a5b0ef1e. > > Signed-off-by: Keith Packard <keithp@keithp.com> > Tested-by: Jesse Barnes <jesse.barnes@intel.com> > Reviewed-by: Daniel Stone <daniel@fooishbar.org> > Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com> This would be a bug in the NVIDIA proprietary driver - please take it up with them. Cheers, Daniel Hi Daniel, why do you think this is a Nvidia related bug? I mean the bisect tracks it down perfectly to this one commit which breaks the server. Why should the same Nvidia driver version break one X version and another not? Maybe you could give some more details on this. Thank you in advance. On Thu, Dec 09, 2010 at 11:09:44AM -0800, bugzilla-daemon@freedesktop.org wrote: > why do you think this is a Nvidia related bug? > I mean the bisect tracks it down perfectly to this one commit which breaks the > server. Why should the same Nvidia driver version break one X version and > another not? > > Maybe you could give some more details on this. > > Thank you in advance. The server change was a correctness fix - previously wrapping of EnterVT/LeaveVT was wrong all over the place and mostly only worked by accident. The NVIDIA driver wraps EnterVT/LeaveVT too, and my guess is that it's doing it incorrectly. (Especially given that the backtrace is in nvidia_drv.so at the time of the crash ...) Of course, the NVIDIA driver being proprietary, we can't debug it to find out what the exact problem is; even if it is a server problem, the NVIDIA guys will need to tell us what it is. Created attachment 41022 [details] [review] fix for the crash-on-vtchange-problem Comment on attachment 41022 [details] [review] fix for the crash-on-vtchange-problem (Sorry, had a little browser-bugtracking-system-fight) Hello guys, after playing a bit around I came up with a patch for this issue. Since I don't know Xorg in detail this might be completely wrong (which I think so since it kind of reverts the old behaviour..). The fix I propose implies that there is probably some pointer/memory mess. However, that's just a guess since I do not know what pScrn/CMapScreenPtr/XF86XVScreenPtr actually are good for. Please have a look at it and tell me if it's ok or if I'm just kind of reverting the old behaviour. On Sat, Dec 11, 2010 at 03:32:39PM -0800, bugzilla-daemon@freedesktop.org wrote: > Please have a look at it and tell me if it's ok or if I'm just kind of > reverting the old behaviour. That's pretty much just reverting to the old behaviour, yeah. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12.12.2010 17:36, bugzilla-daemon@freedesktop.org wrote: >> Please have a look at it and tell me if it's ok or if I'm just kind >> of reverting the old behaviour. > > That's pretty much just reverting to the old behaviour, yeah. I was afraid of that. Is there something else I could try? The whole thing just looks like if it's made for a race condition imho. Is there some kind of documentation for this? What do EnterVT/LeaveVT actually do? What's the purpose of the XF86XVScreenRec struct? Another workaround would be to disable XFree86-VidModeExtension and XVideo extension but I haven't tried that yet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk0FIpIACgkQtVwvsA+W4CCswgCfSNPwPeKGgdBZ7nql4vP37Vos S20AnR67kE5rN3x5O1uZ+2IY+p9uOiFS =X7Ac -----END PGP SIGNATURE----- Created attachment 44248 [details] [review] revert commit d75e8146c414bfd512ba5dbd4a83acb334bbe19b This patch reverts the whole commit. Useful for nvidia users who experience this bug. An nvidia employee said in the forum at nvnews that there will be a fix for this in a future driver release. Let's hope the best. Until then reverting this particular commit might help. Please send your patch to xorg-devel for review I'm not interested in any patches not coming from someone with source to the nVidia driver in question. Without sources, there's no way for anyone to know what (if any) fix in the X server would be correct. Given that someone nVidia has apparently promised a fix at some point, I'm closing this bug with the assumption that it's just a bug in their driver. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.