System environment: ------------------------ --chipset: 855GM --system architecture: i686 --xf86-video-intel: xserver-xorg-video-intel 2:2.2.99.901-1 from debian experimental, xserver from debian sid --kernel version: 2.6.25-rc6-git4 --Linux distribution: debian sid --Machine or mobo model: Acer TM 661lci Bug Description: Most times when switching to console or exiting the xserver the screen goes blank and the system freezes. Even SysRq doesn't work anymore in this situation. Sometimes the system doesn't freeze, but these cases are rare. The problem happens with version 2:2.2.99.901-1 and 2:2.2.1-1 from debian. I think older versions are also affected but I didn't test them explicitly. Reproduce steps: 1, start kdm 2, switch to console or 1, start kdm 2, exit xserver (shut down system)
Created attachment 15384 [details] lspci output
Created attachment 15385 [details] dmesg output
Created attachment 15386 [details] Xorg.0.log
Created attachment 15387 [details] xorg.conf
Can you capture a register dump from a text console after a fresh boot? You'll need to build the intel_reg_dumper tool from src/reg_dumper...
On Tue, Mar 25, 2008 at 15:29:14 -0700, bugzilla-daemon@freedesktop.org wrote: > --- Comment #5 from Jesse Barnes <jbarnes@virtuousgeek.org> 2008-03-25 15:29:13 PST --- > Can you capture a register dump from a text console after a fresh boot? You'll > need to build the intel_reg_dumper tool from src/reg_dumper... Or install the xserver-xorg-video-intel-dbg and libpciaccess0 packages from sid, fwiw.
Created attachment 15458 [details] output of intel_reg_dumper attaching output of intel_reg_dumper after a reboot without starting X as requested.
Maximilian, your dmesg shows that you are using vesafb, could you remove that kernel module and re-test? thanks.
I did build a new 2.6.25-rc7 kernel without any framebuffers and it still freezes when switching to a console.
Ok, thanks, I'll check out the register dump to see if I can find any reason why we wouldn't be able to restore it at exit/vt switch time...
I'm getting an 8xx platform soon, hopefully I'll be able to reproduce this. But in the meantime, can you give this a try to see if it fixes things for you? diff --git a/src/i830_display.c b/src/i830_display.c index 5e52aac..2836c66 100644 --- a/src/i830_display.c +++ b/src/i830_display.c @@ -372,8 +372,8 @@ i830FindBestPLL(xf86CrtcPtr crtc, int target, int refclk, intel_clock_t *best_cl void i830WaitForVblank(ScrnInfoPtr pScreen) { - /* Wait for 20ms, i.e. one cycle at 50hz. */ - usleep(30000); + /* Wait for 300ms */ + usleep(300000); } void diff --git a/src/i830_driver.c b/src/i830_driver.c index a19c8eb..6125f83 100644 --- a/src/i830_driver.c +++ b/src/i830_driver.c @@ -2047,7 +2047,7 @@ SaveHWState(ScrnInfoPtr pScrn) static void i830_dpll_settle(void) { - usleep(10000); /* 10 ms *should* be plenty */ + usleep(300000); /* 300 ms *should* be plenty */ } static Bool
I tried your patch (applied to 2.2.99.901 from debian experimental), but it doesn't help.
Here's another crazy one for you to try: diff --git a/src/common.h b/src/common.h index 9a3e0ac..ff1dc94 100644 --- a/src/common.h +++ b/src/common.h @@ -167,6 +167,7 @@ static inline void memcpy_volatile(volatile void *dst, const ErrorF("OUTREG(0x%lx, 0x%lx) in %s\n", (unsigned long)(addr), \ (unsigned long)(val), FUNCTION_NAME); \ } \ + POSTING_READ(addr); \ } while (0) /* To remove all debugging, make sure I810_DEBUG is defined as a
Yeah, this one seems to fix the freeze.
Created attachment 15688 [details] [review] Flush posted writes in RestoreHWState paths Can you give this one a try? It's a much smaller hammer than the previous patch, but hopefully it'll still fix your hang.
looks like I was wrong, your patch from comment #13 doesn't fix the freeze, it just makes it happen less often. Your patch from comment #15 doesn't seem to change anything. I did all testing with version 2.2.99.901 of the driver. Also some other things I noticed (but I'm not 100% sure about them): If switching to console did work once, it also does work any further times, even after xserver restarts. If it did work and I restart the laptop (choosing restart in kdm), a freeze happens less likely than with a normal boot (system is off, I hit the powerbutton).
Sigh, well it was a long shot anyway. Can you attach lspci -v and /proc/mtrr from your machine?
Created attachment 15704 [details] lspci -v
Created attachment 15705 [details] /proc/mtrr
Hi, today I've upgradet
Hi, today I've upgraded the intel-driver to new version 2.3.0. After removing vesafb everything is shown correct in xorg. But now I have crashes during X restart or X shutdown. Seems like I have a nearly equal machine. It's a Acer TravelMate 663. I'll attach lspci -v and My system: 2.6.24-gentoo-r7 i686 Intel(R) Pentium(R) M processor 1600MHz xorg-server 1.3.0.0 xf86-video-intel-2.3.0 no framebuffer The crashes also happend with the 1.4.0.90 version of xorg-server. Please let me know if I can help.
Created attachment 16458 [details] lspci -v on TM 663
Created attachment 16459 [details] /proc/mtrr on TM 663
Does your log show anything interesting when X exits? Hopefully there's a backtrace?
Created attachment 16460 [details] xorg log on TM 663 I can't find anything interesting. Though I don't know whether there is a backtrace switch or something. I could turn on ModeDebug if you like. Sorry, but I'm no developer. I don't know anything about patches. But I will try. Just say what you need.
Arthur, you may have a different problem from Max. It looks like DRI isn't getting enabled in your configuration for some reason, maybe your Mesa is out of date? Can you try upgrading that as well? Check out Max's log for what things should look like when AIGLX initializes properly.
you're right. I think that's because of the xorg-server version 1.3. I updated mesa to 7.0.2 but the problem remains. today morning this wasn't an issue. I'll file a new bug. Thanks for the hint. best regards, Arthur
Created attachment 16480 [details] xorg log on TM 663 After upgrading the xorg-server to version 1.4.0.90, the AIGLX problem is gone, but the crashes remain by switching to console or logout. new Xorg.0.log attached.
Created attachment 16495 [details] config and log files
I had the same problem with me (dell d505, intel 801 card). I have tried to chance several options inside /etc/defaults/acpi-support, as discussed in https://bugs.launchpad.net/ubuntu/+bug/38915/comments/61 No success. So, I decided to test if my system could hibernate from console, using /etc/acpi/hibernate.sh from command line. This gave me some freezes as well and a clue: acpi and kernel. I tried to boot using acpi=off but the system the system freezes as wells, less frequent, however. Additional information: - it is not possible to use ssh to log in from other machine, even ping does not respond. I had a similar problem in other machine but it was possible to log in. In that case, compiz was using 100% of CPU and I found a bug related to it at launchpad. In the current issue, I removed compiz to avoid more problems. - I tried all options cited in "DebuggingACPI", like acpi=ht, noapic, pnpacpi=off, pci=noirq, nolapic ... freezing as well. I am attaching related files for further investigation. Any other debug action, please let me know. Reference: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/229043
If this is firmware related, the "ForceEnablePipeA" option might prevent the crashes, has anyone tried that yet? FWIW, my 855GM is solid on VT switch with the latest release.
(In reply to comment #31) "ForceEnablePipeA" realy makes a difference. System didn't crash since I enabled this option.
(In reply to comment #32) > (In reply to comment #31) > "ForceEnablePipeA" realy makes a difference. System didn't crash since I > enabled this option. > Following the comment, I added ForceEnablePipeA to xorg.conf, like below Section "Device" ... <other options here> ... Option "ForceEnablePipeA" "true" EndSection I tried 10x to reproduce the problem without success (login/logout). I was possible to hibernate and suspend as well. This option seems to solve the problem. I am using a newer gdm version as well (2.20.6-0ubuntu1) but problem was happening with it if I don't use the cited option. Just to keep the bug tracker up to date. I will test more.
I added 'Option "ForceEnablePipeA" "true"' to my xorg.conf some time ago and didn't have a single crash since then. I will report here when things change, but till now it looks really good.
Jesse, is this fixed then?
No, I think the ForceEnablePipeA is just a workaround in this case, it shouldn't be needed. We still need to figure out what's going on...
Before I noticed this report, I'd raised a bug on the Mandriva bugzilla: https://qa.mandriva.com/show_bug.cgi?id=41582 I tried version 1.7.4 of the Intel driver that Mandriva had forward-ported to Mandriva 2008.1 because of problems with the new Intel driver, and that worked OK. However, I find that the ForceEnablePipeA hack works fine with the new 2.x driver. Should this bug's priority setting be raised, given that the 855GME was standard fitting to Centrino laptops for some time?
Created attachment 17402 [details] [review] debug register I/O Can you try this patch? Also, please add a section like this to your xorg.conf: Section "ServerFlags" Option "Log" "sync" EndSection Hopefully the log syncing will give us a useful log of where the hang happens. It would be best to start your X session by ssh'ing into the laptop and running X with the -verbose option, that way even if the log isn't preserved you'll see what's going on.
Created attachment 17437 [details] Xorg.0.log with patch from comment 38 See the attached logfile. My ssh connection didn't show anything more than the log.
*** Bug 15310 has been marked as a duplicate of this bug. ***
Created attachment 17565 [details] [review] make 855 chips use the force A quirk After talking with the hw guys, it seems that something like the pipe a force enable quirk is needed on 855 platforms in general. Can you give this patch a try and make sure it works for you? It should remove the need to add the option to your xorg.conf file...
The patch seems to work after a quick test. I'll do some more testing and report back.
(In reply to comment #42) > The patch seems to work after a quick test. I'll do some more testing and > report back. > max, any new finding? is everything ok?
No problems so far. Till now everything works as it should.
Ok, pushed the patch as b37a2a8ca82279468e3806dcf77d5fa7bdd0e874.
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.