| Summary: | x11-base/xorg-server-1.7.6 does not start with intel driver and no KMS | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andre <andremuellerster> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Xorg.0.log without KMS (failing case)
Xorg.0.log with KMS (working case) xorg.conf My .config (for mainline 2.6.34-rc2) |
||
|
Description
Andre
2010-03-29 23:51:23 UTC
Created attachment 225753 [details]
Xorg.0.log without KMS (failing case)
Created attachment 225755 [details]
Xorg.0.log with KMS (working case)
Created attachment 225757 [details]
xorg.conf
The problem here is that latest intel driver (2.10.0) is KMS-only. Perhaps that's what's biting you. Sorry, I should have mentioned -- but no, I use x11-drivers/xf86-video-intel-2.9.1. (And I am stuck on the 2.9 branch until KMS suspend works for me). Can you try without any xorg.conf at all? Is the machine still accessible via network when the hang occurs? Does the hang also occur with kernel 2.6.31 or 2.6.32? Starting X with no xorg.conf does not help any. It comes up with KMS active, it does not without. I usually do not do that because I do not use hal but have a localized keyboard. I also tried a couple earlier kernels, specifically 2.6.31 and 2.6.33, plain vanilla sources. Note though, I only tried the failing case, and did not verify a working KMS setup on those. Checking the machine via ssh when hung seems rather unnecessary to me, as it does not listen to acpi events along with the dead keyboard when hung. In my experience, the acpi signals failing can be associated with a stone dead machine. I would have to set up the sshd -- /me is squatting behind a modem, and I do not need my laptop to serve at all. If you still think this would be necessary to check, please ask me to, but that would take some time to get some hardware and set sshd up. Checking if it responds to ping would be enough for now. Only if it does then it makes sense to setup sshd. Some upstream bugs mentioned here seem to be related to your issue: https://bugs.freedesktop.org/show_bug.cgi?id=27187#c4 Some users suggest to enable AGP built-in if it is not already, so it gets loaded before intel drm. Can you try this and/or attach your kernel config? I do have AGP builtin already, as there was trouble with KMS operation otherwise, all right. I do attach my current .config. Thank you for the pointer to the upstream bug, I think this one and its relatives are some other problem, as they all describe bugs kicking in after a successful start at some time or other. Here, I do not get any X output in the first place. I did a search on freedesktop for related issues to no success before opening this bug, though. Which does not say that I missed an appropriate bug, though. ...and I'll go digging for a crossover cable or a hub or sth when I'm home, and will try pinging the machine. Created attachment 225835 [details]
My .config (for mainline 2.6.34-rc2)
Sorry, this won't be fixed, neither here nor upstream. UMS was completely dropped since xf86-video-intel 2.10 and KMS is now mandatory. I know you're talking about 2.9, but upstream just won't fix any bugs on that version. If KMS works, then you should just use it, you'll be forced to at some point in the very near future. Thanks Ok, before getting the bad news, I verified that the machine does not respond to a ping. Sadly, KMS is currently not a real option because it won't allow me to suspend. I would _love_ to adopt it. I do agree to upstream in not spending their time fixing the old stuff, but it certainly is somewhat sad to be left behind and lose functionality on the way, because the new stuff leaves me with a severe functional regression. For the reasonable future, I do hope gentoo can keep xf86-video-intel-2.9.1 and xorg-server-1.6.x around, so I can get away by masking the new stable packages. See bug 290739 comment 3 which packages to mask if you don't want xorg-server-1.7 |
