Created attachment 94461 [details] dmesg log when booting vanilla 3.8.2 kernel in undocked configuration. I have a Lenovo T60p laptop that has a built-in M66GL chip. Typically, this laptop is docked into a docking station that has a HD4650 card in a x1 (I think) PCIe slot. There is currently no monitor connected to the HD4650. A vanilla 32 bit 3.8.2 kernel does not boot on this laptop so long as the laptop remains docked. (It boots OK when undocked, though). The boot process seems to hang instead, although it will still perform an ACPI shutdown when I press the power button. This hang happens with run-level 5, but not with run-level 3. The Fedora kernel-3.8.1-201.fc18.i686 package doesn't hang on boot, but the X server crashes instead. A vanilla 3.7.10 boots normally, regardless of whether the laptop is docked or undocked.
Created attachment 94471 [details] dmesg log when booting vanilla 3.8.2 kernel to runlevel 3 in docked configuration.
Created attachment 94481 [details] dmesg log when booting Fedora 3.8.1-201.fc18 kernel to run-level 5 while docked
Created attachment 94491 [details] Xorg.0.log when booting vanilla 3.8.2 while undocked
Created attachment 94501 [details] Xorg.0.log showing X crashing with Fedora 3.8.1-201.fc18 kernel
Created attachment 94511 [details] xorg.conf
When you say 3.8.2 does not boot when docked do you mean the kernel hangs while loading or X never starts? I presume it boots into a non-X runlevel ok since you were able to attach a dmesg from runlevel 3? Can you bisect?
I suppose it's possible that it's not the kernel and that Xorg is just failing to start instead, but it's hard to tell with the 3.8.2 kernel because neither the keyboard nor mouse responds. I created the run-level 3 dmesg log by booting into "single user" mode and then raising the run-level with "telinit 3". I suppose booting directly into run-level 3 is therefore also possible. Xorg crashes with the Fedora 3.8.1-201.fc18 kernel, complaining about a "Segmentation fault at address 0x10". I am guessing that this is the same underlying problem as with my stock 3.8.2 kernel. > Can you bisect? The laptop isn't really suitable for git bisecting the kernel between 3.7.10 and 3.8.2. It's really just a portable "World of Warcraft" device + docking station.
Sounds like a userspace issue (probably X) based on your last comment. It would be interesting to find out what kernel change is causing the X problem however. What version of mesa are you using? I could be some new hw feature like support for hyperZ or the new DMA rings that only gets called enabled with a 3.8 kernel.
Fedora 18's mesa package (which Xorg uses) is mesa-dri-drivers-9.0.1-5.fc18.i686. I only use more up-to-date mesa installations manually on a case-by-case basis.
However, Fedora *is* using a very up-to-date release of xorg-x11-drv-ati: xorg-x11-drv-ati-7.0.0-0.9.20121015gitbd9e2c064
Created attachment 95061 [details] dmesg log from successful boot I've just successfully booted into 3.8.2, although I haven't changed anything?! My original intention was to try SSH-ing into the laptop in order to capture the Xorg.0.log etc, if possible. I am baffled... not least because Fedora 3.8.1-201.fc18 was definitely crashing X before.
Created attachment 95071 [details] dmesg log when booting Fedora 3.8.1-201.fc18 kernel successfully And now it works, although I haven't changed anything.
On reflection, there is one difference: I had powered the docking station off in the interim, whereas before I had warm-booted it from a 3.7.10 kernel to a 3.8.2 one. Would that affect things?
This has turned out to be an intermittent problem because it has happened again. However, I have been able to login via SSH and confirm that the kernel is OK. The real problem is that Xorg is crashing.