[arch-general] Blanks screen after boot
Hey, I have this problem since a while but it got a lot worse with the last two kernel versions. Now there's an about 50/50 chance to see the user login or simply not see it. I don't have any login manager set up, so after boot there's simply the user login and after that I issue startx. It all works just fine,even if I can't see a thing, and once I issued startx everything goes back to normal, the screen isn't blank anymore. The machine has an Intel chipset, and I guess it's related to that and/or KMS, but that's as far as my guess goes. Maybe one of you knows something about that kind of issue? -- Regards, Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
It would appear that on Jul 8, Philipp did say:
Hey, I have this problem since a while but it got a lot worse with the last two kernel versions. Now there's an about 50/50 chance to see the user login or simply not see it. I don't have any login manager set up, so after boot there's simply the user login and after that I issue startx. It all works just fine,even if I can't see a thing, and once I issued startx everything goes back to normal, the screen isn't blank anymore.
The machine has an Intel chipset, and I guess it's related to that and/or KMS, but that's as far as my guess goes.
Maybe one of you knows something about that kind of issue?
Don't know for sure but it sounds a little like the problem I just had with my video driver... And my problem was definitely related to KMS... Do you by chance have an Nvidia graphics card??? In my case I have a new/used (new to me) PC with on board Nvidia. It's my first Nvidia and I was caught by surprise when the open source driver didn't work for me. And since it's designed for KMS it was being deployed before I'd even installed xorg... This put me in a blank screen where if I carefully typed the keystrokes I could log in to a console and issue commands. But I couldn't see anything. I have no idea what this would do to the X session you would initialize via startx, But as far as the console mode part goes it was suggested that if I used the kernel option "nomodeset" when I booted, I might get a more usable console session. And for me it worked long enough to find out that I really needed the proprietary nvidia driver. You can see more details of my experience by reading the thread I started on Jul 4th 2010 with the subject line of: screen goes blank on reboot after 1st pacman Su of new install!!!??? Hmmnnn I just noticed that I said "pacman Su" on that subject line rather than "pacman -Su"... Just goes to show that my brain is less than perfect. Hope this is of some help anyway. -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
Excerpts from Joe(theWordy)Philbrook's message of 2010-07-09 04:17:22 +0200:
It would appear that on Jul 8, Philipp did say:
Hey, I have this problem since a while but it got a lot worse with the last two kernel versions. Now there's an about 50/50 chance to see the user login or simply not see it. I don't have any login manager set up, so after boot there's simply the user login and after that I issue startx. It all works just fine,even if I can't see a thing, and once I issued startx everything goes back to normal, the screen isn't blank anymore.
The machine has an Intel chipset, and I guess it's related to that and/or KMS, but that's as far as my guess goes.
Maybe one of you knows something about that kind of issue?
Don't know for sure but it sounds a little like the problem I just had with my video driver... And my problem was definitely related to KMS...
Do you by chance have an Nvidia graphics card???
In my case I have a new/used (new to me) PC with on board Nvidia. It's my first Nvidia and I was caught by surprise when the open source driver didn't work for me. And since it's designed for KMS it was being deployed before I'd even installed xorg... This put me in a blank screen where if I carefully typed the keystrokes I could log in to a console and issue commands. But I couldn't see anything. I have no idea what this would do to the X session you would initialize via startx, But as far as the console mode part goes it was suggested that if I used the kernel option "nomodeset" when I booted, I might get a more usable console session. And for me it worked long enough to find out that I really needed the proprietary nvidia driver. You can see more details of my experience by reading the thread I started on Jul 4th 2010 with the subject line of:
screen goes blank on reboot after 1st pacman Su of new install!!!???
Hmmnnn I just noticed that I said "pacman Su" on that subject line rather than "pacman -Su"... Just goes to show that my brain is less than perfect.
Hope this is of some help anyway.
Thanks Joe, I saw that thread but didn't read it entirely. I have an onboard intel chip, KMS is working since quite a while, so it might just be a regression. I searched around for a bit and even found something on the arch wiki that might be related, but it lacks any reference to an upstream bug: http://wiki.archlinux.org/index.php/Intel#KMS_.28Kernel_Mode_Setting.29 Disabling KMS seems to be no option for intel chips anymore. Further search suggests that it might be ACPI related. One ACPI bug I reported was fixed, I can control my backlight with the function keys now, so maybe I should report this one as well. -- Regards, Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
Am 08.07.2010 09:56, schrieb Philipp:
Hey, I have this problem since a while but it got a lot worse with the last two kernel versions. Now there's an about 50/50 chance to see the user login or simply not see it. I don't have any login manager set up, so after boot there's simply the user login and after that I issue startx. It all works just fine,even if I can't see a thing, and once I issued startx everything goes back to normal, the screen isn't blank anymore.
The machine has an Intel chipset, and I guess it's related to that and/or KMS, but that's as far as my guess goes.
Maybe one of you knows something about that kind of issue?
You need to save the dmesg output of a failed and a successful boot and compare them. Note that the DRM/KMS driver seems to initialize fine - otherwise, starting Xorg would fail entirely (Intel's Xorg driver depends on it).
Excerpts from Thomas Bächler's message of 2010-07-09 11:49:16 +0200:
Am 08.07.2010 09:56, schrieb Philipp:
Hey, I have this problem since a while but it got a lot worse with the last two kernel versions. Now there's an about 50/50 chance to see the user login or simply not see it. I don't have any login manager set up, so after boot there's simply the user login and after that I issue startx. It all works just fine,even if I can't see a thing, and once I issued startx everything goes back to normal, the screen isn't blank anymore.
The machine has an Intel chipset, and I guess it's related to that and/or KMS, but that's as far as my guess goes.
Maybe one of you knows something about that kind of issue?
You need to save the dmesg output of a failed and a successful boot and compare them.
Note that the DRM/KMS driver seems to initialize fine - otherwise, starting Xorg would fail entirely (Intel's Xorg driver depends on it).
Thanks Thomas, good idea. I'll see whether I can find the difference in dmesg and will search for/file a bug then. Besides the one error message in dmesg I already know (wifi chip doesn't work in DMA mode) there are some more lines that I don't understand: pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13 pcie_pme: probe of 0000:00:1c.1:pcie01 failed with error -13 pcie_pme: probe of 0000:00:1c.2:pcie01 failed with error -13 PM: Error -22 checking image file I don't have the slightest idea whether they are related to my problem, I'll do the comparison when I get the chance. -- Regards, Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
Am 09.07.2010 12:04, schrieb Philipp Überbacher:
Besides the one error message in dmesg I already know (wifi chip doesn't work in DMA mode) there are some more lines that I don't understand:
When providing exceperts of grepping for them, please provide context (grep -C3 is a good command).
pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13 pcie_pme: probe of 0000:00:1c.1:pcie01 failed with error -13 pcie_pme: probe of 0000:00:1c.2:pcie01 failed with error -13
Those appeared on many machines in 2.6.34 IIRC, they indicate some ACPI trouble, but should be harmless.
PM: Error -22 checking image file
Context please.
I don't have the slightest idea whether they are related to my problem,
Probably not.
I'll do the comparison when I get the chance.
You do that. Eventually, upstream intel developers might be interested in this. Which chipset do you have?
Excerpts from Thomas Bächler's message of 2010-07-09 13:34:29 +0200:
Am 09.07.2010 12:04, schrieb Philipp Überbacher:
Besides the one error message in dmesg I already know (wifi chip doesn't work in DMA mode) there are some more lines that I don't understand:
When providing exceperts of grepping for them, please provide context (grep -C3 is a good command).
pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13 pcie_pme: probe of 0000:00:1c.1:pcie01 failed with error -13 pcie_pme: probe of 0000:00:1c.2:pcie01 failed with error -13
Those appeared on many machines in 2.6.34 IIRC, they indicate some ACPI trouble, but should be harmless.
PM: Error -22 checking image file
Context please.
Ok, here's the whole dmesg thing, the b43 is a known problem, may be solved someday, but now with .34 wireless at least works in PIO mode automatically. $ dmesg | grep -i -C3 error pcieport 0000:00:1c.2: irq 26 for MSI/MSI-X pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13 pcieport 0000:00:1c.1: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.1: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.1:pcie01 failed with error -13 pcieport 0000:00:1c.2: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.2: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.2:pcie01 failed with error -13 Linux agpgart interface v0.103 Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled PNP: PS/2 Controller [PNP0303:KBD0,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 -- PM: Starting manual resume from disk PM: Resume from partition 8:2 PM: Checking hibernation image. PM: Error -22 checking image file PM: Resume from disk failed. EXT4-fs (sda3): mounted filesystem with ordered data mode rtc_cmos 00:09: RTC can wake from S4 -- tg3 0000:02:00.0: eth0: Flow control is on for TX and on for RX ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 b43-phy0 ERROR: This device does not support DMA on your system. Please use PIO instead. b43-phy0: Controller RESET (DMA error) ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0: Controller restarted b43-phy0: Radio hardware status changed to DISABLED
I don't have the slightest idea whether they are related to my problem,
Probably not.
I'll do the comparison when I get the chance.
You do that. Eventually, upstream intel developers might be interested in this. Which chipset do you have?
I guess this would be GM965 then? 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) Thanks for advice. -- Regards, Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
Am 09.07.2010 14:36, schrieb Philipp Überbacher:
$ dmesg | grep -i -C3 error pcieport 0000:00:1c.2: irq 26 for MSI/MSI-X pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13 pcieport 0000:00:1c.1: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.1: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.1:pcie01 failed with error -13 pcieport 0000:00:1c.2: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.2: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.2:pcie01 failed with error -13 Linux agpgart interface v0.103 Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled PNP: PS/2 Controller [PNP0303:KBD0,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
Okay, that is known, new in 2.6.34, and _should_ be harmless. Google for "Failed to receive control of PCIe PME service: no _OSC support" for details.
PM: Starting manual resume from disk PM: Resume from partition 8:2 PM: Checking hibernation image. PM: Error -22 checking image file PM: Resume from disk failed. EXT4-fs (sda3): mounted filesystem with ordered data mode rtc_cmos 00:09: RTC can wake from S4
Harmless, this only means that you didn't suspend to disk, and thus cannot resume from disk.
tg3 0000:02:00.0: eth0: Flow control is on for TX and on for RX ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 b43-phy0 ERROR: This device does not support DMA on your system. Please use PIO instead. b43-phy0: Controller RESET (DMA error) ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0: Controller restarted b43-phy0: Radio hardware status changed to DISABLED
Yes, I heard about that problem. None of the above seems related to your i915 problem.
I guess this would be GM965 then? 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
Thanks for advice.
Hm, yes, Xorg.0.log has more details about the exact chip ... there are many 965-generation chips, and I don't pretend to know all of them.
Excerpts from Thomas Bächler's message of 2010-07-09 15:58:54 +0200:
Am 09.07.2010 14:36, schrieb Philipp Überbacher:
$ dmesg | grep -i -C3 error pcieport 0000:00:1c.2: irq 26 for MSI/MSI-X pcieport 0000:00:1c.0: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.0: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.0:pcie01 failed with error -13 pcieport 0000:00:1c.1: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.1: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.1:pcie01 failed with error -13 pcieport 0000:00:1c.2: Requesting control of PCIe PME from ACPI BIOS pcieport 0000:00:1c.2: Failed to receive control of PCIe PME service: no _OSC support pcie_pme: probe of 0000:00:1c.2:pcie01 failed with error -13 Linux agpgart interface v0.103 Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled PNP: PS/2 Controller [PNP0303:KBD0,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
Okay, that is known, new in 2.6.34, and _should_ be harmless. Google for "Failed to receive control of PCIe PME service: no _OSC support" for details.
PM: Starting manual resume from disk PM: Resume from partition 8:2 PM: Checking hibernation image. PM: Error -22 checking image file PM: Resume from disk failed. EXT4-fs (sda3): mounted filesystem with ordered data mode rtc_cmos 00:09: RTC can wake from S4
Harmless, this only means that you didn't suspend to disk, and thus cannot resume from disk.
tg3 0000:02:00.0: eth0: Flow control is on for TX and on for RX ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 b43-phy0 ERROR: This device does not support DMA on your system. Please use PIO instead. b43-phy0: Controller RESET (DMA error) ... b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) b43-phy0: Controller restarted b43-phy0: Radio hardware status changed to DISABLED
Yes, I heard about that problem.
None of the above seems related to your i915 problem.
Ok, thanks for all that, I'll just ignore that stuff for now.
I guess this would be GM965 then? 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
Thanks for advice.
Hm, yes, Xorg.0.log has more details about the exact chip ... there are many 965-generation chips, and I don't pretend to know all of them.
Not much in there that tells me anything more than that it's a 965. Well, once I've reported it upstream they'll tell me what else they need. Thanks. -- Regards, Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
participants (4)
-
Joe(theWordy)Philbrook
-
Philipp
-
Philipp Überbacher
-
Thomas Bächler