Summary: | [845G] server crash during VT switch | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Ryan Hinton <iobass> | ||||||
Component: | Driver/intel | Assignee: | Jesse Barnes <jbarnes> | ||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | normal | ||||||||
Priority: | medium | CC: | dmueller, robert.bradbury, sndirsch | ||||||
Version: | 7.2 (2007.02) | ||||||||
Hardware: | x86 (IA32) | ||||||||
OS: | FreeBSD | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 13027 | ||||||||
Attachments: |
|
Description
Ryan Hinton
2007-06-14 08:58:41 UTC
Created attachment 10310 [details]
Xorg.0.log
Created attachment 10311 [details]
stderr dumped to a file while reproducing bug
Also got 3 new lines in dmesg output while reproducing bug:
drmsub0: <Intel i845 GMCH>: (child of agp_i810.c) on agp0
info: [drm] AGP at 0xf0000000 128MB
info: [drm] Initialized i915 1.5.0 20060119
Is this still reproducible with the new driver (in Xorg7.3 or git tip)? I'm not savvy enough to jump to the latest development sources and back (the getting back part trips me up), but I did update to the latest FreeBSD 6-stable sources, and I still see the problem. Is there a good way to tell exactly which version of the code I am running? Here is a list of my currently installed packages. In particular, note that the meta-port is listed at Xorg-7.2, but the drivers are labeled at version 7.3. Let me know how I can best provide you more information. xorg-7.2 X.Org complete distribution metaport xorg-apps-7.3 X.org apps meta-port xorg-cf-files-1.0.2_2 X.org cf files for use with imake builds xorg-docs-1.4,1 X.org documentation files xorg-drivers-7.3 X.org drivers meta-port xorg-fonts-100dpi-7.3 X.Org 100dpi bitmap fonts xorg-fonts-7.3 X.org fonts meta-port xorg-fonts-75dpi-7.3 X.Org 75dpi bitmap fonts xorg-fonts-cyrillic-7.3 X.Org Cyrillic bitmap fonts xorg-fonts-miscbitmaps-7.3 X.Org miscellaneous bitmap fonts xorg-fonts-truetype-7.3 X.Org TrueType fonts xorg-fonts-type1-7.3 X.Org Type1 fonts xorg-libraries-7.3_1 X.org libraries meta-port xorg-nestserver-1.2.0,1 Nesting X server from X.Org xorg-printserver-1.2.0,1 X Print server from X.Org xorg-protos-7.3 X.org protos meta-port xorg-server-1.4,1 X.Org X server and related programs xorg-vfbserver-1.2.0,1 X virtual framebuffer server from X.Org There have been several fixes to console switching lately. Please find a way to test the latest git tree and report back. This may be the "libdbus" crash. There is a patch for this reported in the gentoo bugs (bugs.gentoo.org Bug #197307). Or see: http://lists.freedesktop.org/archives/xorg/2007-September/028041.html A dup of several other "VT switch hang" bug on Linux? Anyway, Ryan, would you please try the one suggested by Robert in comment# 6? Sorry it's a dup, I tried looking first but didn't find any that seemed to match at the time. It is on FreeBSD; I'm not sure if that's relevant. I will not have time to look at this for a while (maybe this week, maybe not until December), so feel free to change its status as appropriate. I can elevate it or mark it fixed when I have a chance to try again. Thanks! (In reply to comment #8) > Sorry it's a dup, I tried looking first but didn't find any that seemed to > match at the time. It is on FreeBSD; I'm not sure if that's relevant. It wasn't a dup at the time you filed it if its the libdbus bug. The problem didn't show up for me until around September (when Gentoo upgraded X). The patch also didn't appear in the mailing list (thank god for Google or I never would have known about it) until the same time frame. Mind you I'm running on a i915 rather than a i845, so I cannot state for certain that it is the same bug. But my reading of the patch would suggest that it applies to all releases of X 7.# (whenever the code was written) independent of the chipset. I hope this one's fixed for you, thanks to Peter Clifton we have quite a few fixes for 8xx chipsets and VT switch problems. I'll leave it as NEEDINFO so you can test again before closing this bug or updating it. Thanks, Jesse This one? commit eecd3ccedee6c4acf101591f7e60673660379e62 Author: Jesse Barnes <jbarnes@hobbes.virtuousgeek.org> Date: Thu Nov 8 09:31:08 2007 -0800 Check DPLL status before writing PIPEnCONF regs If the DPLL isn't enabled or is in VGA mode, writing the PIPEnCONF registers may cause a hang or crash. So ensure the DPLL is in the proper state before writing them. Another excellent fix from Peter Clifton. diff --git a/src/i830_driver.c b/src/i830_driver.c index 488232d..53c7845 100644 --- a/src/i830_driver.c +++ b/src/i830_driver.c @@ -2052,7 +2052,13 @@ RestoreHWState(ScrnInfoPtr pScrn) OUTREG(DSPASURF, pI830->saveDSPASURF); OUTREG(DSPATILEOFF, pI830->saveDSPATILEOFF); } - OUTREG(PIPEACONF, pI830->savePIPEACONF); + /* + * Make sure the DPLL is active and not in VGA mode or the + * write of PIPEnCONF may cause a crash + */ + if ((pI830->saveDPLL_B & DPLL_VCO_ENABLE) && + (pI830->saveDPLL_B & DPLL_VGA_MODE_DIS)) + OUTREG(PIPEACONF, pI830->savePIPEACONF); i830WaitForVblank(pScrn); OUTREG(DSPACNTR, pI830->saveDSPACNTR); OUTREG(DSPABASE, INREG(DSPABASE)); @@ -2092,7 +2098,13 @@ RestoreHWState(ScrnInfoPtr pScrn) OUTREG(DSPBSURF, pI830->saveDSPBSURF); OUTREG(DSPBTILEOFF, pI830->saveDSPBTILEOFF); } - OUTREG(PIPEBCONF, pI830->savePIPEBCONF); + + /* + * See PIPEnCONF note above + */ + if ((pI830->saveDPLL_B & DPLL_VCO_ENABLE) && + (pI830->saveDPLL_B & DPLL_VGA_MODE_DIS)) + OUTREG(PIPEBCONF, pI830->savePIPEBCONF); i830WaitForVblank(pScrn); OUTREG(DSPBCNTR, pI830->saveDSPBCNTR); OUTREG(DSPBBASE, INREG(DSPBBASE)); Yep, that's the one. Jesse Will I be able to test these changes by just upgrading the driver? I posted to the FreeBSD list on how to update my Xorg installation and was advised that updating more than this is difficult and error-prone. You could try applying the patch from #11 into your tree and rebuilding. It's been over 10 years since I've built BSD packages though, so I'm not sure offhand if that's a trivial thing to do or not. Actually, there's a small bug in the patch posted in this bug. The write to PIPEACONF should be protected by a check against DPLL_A not DPLL_B. The git tree already has a fix. Ryan, since I'm pretty sure we fixed this one in the 2.2 driver release, I'm going to close it out. Please reopen if it still happens once you've upgraded. Thanks, Jesse |
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.