Bug 22597 - [855GM KMS] X fatal freeze on startup under kernel 2.6.29/2.6.30
[855GM KMS] X fatal freeze on startup under kernel 2.6.29/2.6.30
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
unspecified
x86 (IA32) Linux (All)
: medium critical
Assigned To: Jesse Barnes
Xorg Project Team
: NEEDINFO
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-02 04:55 UTC by Robin Bankhead
Modified: 2009-10-05 11:32 UTC (History)
1 user (show)

See Also:


Attachments
dmesg up to before X start with kernel-2.6.30-gentoo-r1 (23.51 KB, text/plain)
2009-07-02 04:55 UTC, Robin Bankhead
no flags Details
Xorg.0.log showing the crash (20.70 KB, text/plain)
2009-07-02 04:56 UTC, Robin Bankhead
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Bankhead 2009-07-02 04:55:30 UTC
Created attachment 27332 [details]
dmesg up to before X start with kernel-2.6.30-gentoo-r1

I am running Gentoo testing, currently using kernel-2.6.30-gentoo-r1, xorg-server-1.6.1.901-r4, xf86-video-intel-2.7.1. When attempting to use kernel modesetting, X when launched with KDM crashes fatally and the machine (Toshiba Satellite A30-104 with Intel 82852/82855GM/GME graphics chipset) can only be shutdown via magic SysReq.

The symptoms were slightly different under 2.6.29 in that KDM would start and I could login, but it would then hang immediately after submitting the login dialogue. Another difference was that an ACPI-controlled shutdown using the machine's power-button was possible then, which it isn't under 2.6.30.

With either kernel version, it's possible to start X/KDE normally with KMS disabled and using uvesafb instead, though enabling desktop compositing causes a similar freeze, and there is severe corruption on all native KDE applications (separate issue presumably).

dmesg attached; Xorg.0.log to follow.
Comment 1 Robin Bankhead 2009-07-02 04:56:38 UTC
Created attachment 27333 [details]
Xorg.0.log showing the crash
Comment 2 Eric Anholt 2009-07-15 14:24:25 UTC
Please attach intel_gpu_dump output at the time of the freeze (preferably with KMS)
Comment 3 Robin Bankhead 2009-07-15 19:02:10 UTC
I can't really do anything when the freeze occurs. Can you clarify?
Comment 4 Gordon Jin 2009-08-23 19:15:21 UTC
(In reply to comment #3)
> I can't really do anything when the freeze occurs. Can you clarify?
> 

Is it possible for you to remote login?
Comment 5 Jesse Barnes 2009-08-31 09:55:39 UTC
Yeah a lot of times you can login with ssh and collect some info, but only if your machine hasn't locked up hard.

But I'm hoping this bug is fixed now; there have been some 8xx related fixes and several "random hang" fixes committed recently.  Is there any way for you to test recent git bits?
Comment 6 Robin Bankhead 2009-08-31 19:16:34 UTC
Well, I now have another distro version (or two) of intel-driver and xorg-server to upgrade, so let me get on that (takes some time on this machine) and if there's still the same issue I'll look into git builds.
Comment 7 Robin Bankhead 2009-09-02 05:35:30 UTC
Sorry, my update process is taking even longer due to library breakage. Give it another day or 2 at this rate :(

In the meantime, I have a question: my machine is a Taiwanese-built Toshiba Satellite A30-104 with Phoenix BIOS, often referred to as not a "true" Toshiba.  I have read reports that the video BIOS on these boxen is very buggy (S-video out has never worked properly as long as I've been using Gentoo, and barely worked on Mandrake).  If this is correct, can this be a factor here and is there much I can do about that?
Comment 8 Jesse Barnes 2009-09-02 09:57:54 UTC
Once the machine is up and running we don't depend much on the BIOS.  The video driver just needs panel and a few other bits of info, but beyond that I wouldn't think it would have an effect.
Comment 9 Jesse Barnes 2009-10-05 11:32:56 UTC
No activity, assuming this is fixed.  Please reopen if not.