Am 10.11.2011 07:45, schrieb Uli Armbruster:

* Taylor Hedberg [10.11.2011 01:55]:

...

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) I have a 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] and use the radeon driver.

Those are completely different chips and different drivers, I would be surprised to see any connection here. I'm afraid I can't tell you anything about this problem, besides the usual "works fine for me" answer, at least in the case of the 'intel' driver. 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12)

Uli Armbruster, Thu 2011-11-10 @ 07:45:11+0100:

I can confirm this behavior, however I'm not sure if it's software related. I have the impression that this happens here only if the laptop is cold (e.g. because I carried it around outside in the cold german autumn). But Taylor's describtion fits perfectly to the behavior I have, so maybe it really is caused by the kernel.

I have a 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] and use the radeon driver.

Does the problem disappear if you downgrade the kernel? It certainly does for me. That would tell you whether it's hardware or software issue on your machine.

* Uli Armbruster [10.11.2011 14:53]:

* Taylor Hedberg [10.11.2011 13:50]:

...

Uli Armbruster, Thu 2011-11-10 @ 07:45:11+0100:

...

I can confirm this behavior, however I'm not sure if it's software related. I have the impression that this happens here only if the laptop is cold (e.g. because I carried it around outside in the cold german autumn). But Taylor's describtion fits perfectly to the behavior I have, so maybe it really is caused by the kernel.

I have a 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] and use the radeon driver.

Does the problem disappear if you downgrade the kernel? It certainly does for me. That would tell you whether it's hardware or software issue on your machine.

I'll try to look into it. I also have the linux-rt kernel installed, which is still version 3.0.7. I'll tell you if it happens as well with this kernel.

Ok here on my laptop it's definitely hardware-based, the backlight doesn't work in the first moment, when the laptop is cold. I just booted my cold laptop into 3.0.7 linux-rt and it happened there as well.

On 10-11-2011 06:45, Uli Armbruster wrote:

* Taylor Hedberg [10.11.2011 01:55]:

...

Since updating to Linux 3.1 yesterday, I've been having strange problems with the display on my laptop. The first reboot after updating the kernel went normally, but every subsequent boot since then has had problems.

This is a Dell Latitude D620 laptop with the following graphics-related lines in the lspci output:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

During boot, at the stage where it says "Waiting for UDev uevents to be processed", the backlight normally blinks and the display mode changes, presumably due to udev detecting my graphics hardware.

Since the kernel update, the backlight still blinks off momentarily, but when it comes back on, the screen remains blank. Rather than seeing the rest of the boot messages, the display is just black (but backlit). The system still seems to boot like normal; I boot to the virtual console rather than starting X automatically, and once the hard disk activity stops after booting, I can blindly type my login credentials and issue shell commands, though I still can't see any output.

Additionally, after the first reboot following the update (which did not have the aforementioned display problems), I had issues with the display backlight after starting X. If I shut the laptop lid, the backlight usually shuts off, and comes back on when I reopen it. However, after the kernel update, around 80% of the time, the backlight seemed to come back on at about a third of its usual brightness. I had to close and reopen it several times, and eventually it would come on at full power like normal.

I managed to boot the system in single-user mode using the fallback initcpio image (any other combination of boot options seemed to result in the blank screen), and then downgraded the kernel back to 3.0.7. After downgrading, all of these problems seem to have disappeared.

I've scanned through dmesg output and I don't really see anything out of the ordinary. But I admit that I don't really know what I'm looking for. Any thoughts or suggestions?

I can confirm this behavior, however I'm not sure if it's software related. I have the impression that this happens here only if the laptop is cold (e.g. because I carried it around outside in the cold german autumn). But Taylor's describtion fits perfectly to the behavior I have, so maybe it really is caused by the kernel.

I have a 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] and use the radeon driver.

Works fine for me here after a few reboots/cold boot/hibernate. I'm using the radeon driver with: 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 2400 -- Mauro Santos

Sebastian Schwarz, Thu 2011-11-10 @ 16:36:54+0100:

My display comes back with the minimal brightness setting. Also the XF86MonBrightnessUp (Fn+Up) and XF86MonBrightnessDown (Fn+Down) buttons stopped working. I can restore the previous brightness level and the buttons by running:

cat /sys/class/backlight/intel_backlight/max_brightness \ > /sys/class/backlight/intel_backlight/brightness

The bug can easily triggered in X by running:

xset dpms force off

Yes, this is the same behavior that I'm seeing. Writing the max_brightness value into the sysfs brightness file restores normal backlight brightness. I can also restore it with `xbacklight -set 100`.

I found this I my dmesg output:

[Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.

But I also haven't tried this, as the incorrect brightness has not annoyed me enough, yet.

I have this message in my dmesg output as well, but unfortunately, setting the mentioned module parameter doesn't have any effect on the problems I'm seeing.

Sebastian Schwarz, Fri 2011-11-11 @ 16:26:24+0100:

After running `xbacklight -set 100` my backlight is at the previous brightness level, which is 57% and not at the 100% xbacklight should set it to.

I see. I usually run my backlight at 100%, so I could be seeing the same thing and not realizing it, as my previous level would be 100% in the usual case.

So 3.1 has probably some new backlight code, which does not work as it should. And indeed there are two threads on the linux.kernel newsgroup[1, 2] and one on the LKML[3] with an explanation, a patch[4] and a couple of bug reports[5, 6, 7].

I have not tested the patch yet, but is seems to deal with the issue at hand.

[1]: https://groups.google.com/group/linux.kernel/browse_thread/thread/28296924e8... [2]: https://groups.google.com/group/linux.kernel/browse_thread/thread/fde3079d9f... [3]: https://lkml.org/lkml/2011/9/19/381 [4]: https://lkml.org/lkml/diff/2011/10/25/473/1 [5]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652 [6]: https://launchpad.net/~kamalmostafa/+archive/stuck-backlight [7]: https://bugs.freedesktop.org/show_bug.cgi?id=41926

Thanks for these links. I'll test the patch on my system tonight when I get some free time. Compiling Linux on my laptop takes forever.

Taylor Hedberg, Fri 2011-11-11 @ 10:36:02-0500:

Thanks for these links. I'll test the patch on my system tonight when I get some free time. Compiling Linux on my laptop takes forever.

The patch you linked fixed the dim backlight issue on my system. I'm still experiencing the blank screen issue at boot-time, however, so I guess there are two separate regressions.

On (11/09/2011 06:55 PM), Taylor Hedberg wrote: -~> Additionally, after the first reboot following the update (which did not -~> have the aforementioned display problems), I had issues with the display -~> backlight after starting X. Indeed there seems to be a problem with intel graphics. Since 3.1 I get a strange display flicker when calling xbacklight. An older card though: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

hollunder@lavabit.com, Sat 2011-11-12 @ 22:42:57-0500:

...

I'm rather sure this is a new intel driver bug, I have the exact same issue. My laptops chipset is slightly newer: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 03)

I finally figured out a fix for the blank screen during boot issue. I had not added i915 to the MODULES list in my mkinitcpio.conf, because later in the boot process, udev would kick in and load the driver automatically. But apparently this can cause a sort of race condition, where if modules happen to be loaded in a particular order by udev, this blank screen issue can occur. Loading the driver during early userspace avoids this problem entirely, since by the time udev starts up, the module has already been present in the kernel for a while.

So if you don't already have i915 in MODULES, just add it and then regenerate your initial ramdisk. This seems to have solved the problem for me.

I was inspired by a suggestion [1] in a bug report on freedesktop.org, which led me to this solution. The bug report is for a similar (but not identical) issue. The user reported that building a kernel with the i915 driver statically included made his problem disappear. I tried this, and it worked. But this has essentially the same effect as including the module in the initial ramdisk, which is a bit easier to do. So there you go.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=22674#c11

Thanks Taylor, I still consider this a bug because this didn't happen for years but seems to happen every time I boot since 3.1. Another workaround is to disable kms by booting with the nomodeset option. Another new issue is that my mousepointer frequently flickers/disappears and that xv video out in smplayer doesn't work anymore, but both of those are with the nomodeset option, have yet to test with kms enabled again.

hollunder@... wrote:

...

...

hollunder@..., Sat 2011-11-12 @ 22:42:57-0500: [1] https://bugs.freedesktop.org/show_bug.cgi?id=22674#c11

Thanks Taylor, I still consider this a bug because this didn't happen for years but seems to happen every time I boot since 3.1.

Another workaround is to disable kms by booting with the nomodeset option.

Another new issue is that my mousepointer frequently flickers/disappears and that xv video out in smplayer doesn't work anymore, but both of those are with the nomodeset option, have yet to test with kms enabled again.

FWIW, KMS never worked for me (on a desktop, though). The board has a nvidia chipset. All the characters on the screen were displayed "giant mode", ie. I could see only the first few of them, but they were inches wide, with large pixels.

So I had to append "nouveau.modeset=0" to the append line of the etc/lilo.conf.

clemens

Back when kms was introduced it was already supported by intel (I guess they developed it) and it took a while for nvidia and ATI. That it causes issues now for intel is clearly a regression, that it still doesn't work for nvidia is ... bad. On the other hand it seems a machine with intel chip doesn't work properly without kms now, so I'm not quite sure what's worse.

hollunder@lavabit.com, Sun 2011-11-13 @ 11:18:05-0500:

...

Another workaround is to disable kms by booting with the nomodeset option.

Another new issue is that my mousepointer frequently flickers/disappears and that xv video out in smplayer doesn't work anymore, but both of those are with the nomodeset option, have yet to test with kms enabled again.

I was under the impression that KMS was required in order to run modern versions of X. If that's the case, it's likely that your new issues are a result of the nomodeset kernel parameter. I'd try reenabling KMS and adding i915 to the initcpio. That may solve the problem.

For what it's worth, I'm not seeing the mouse cursor flickering. I don't use smplayer so I can't speak to that problem.

I did test it with i915 added, kernel re-installed and nomodeset removed and stuff seems to be back to normal. xv works again, mouse cursor flicker is gone, so I'm reasonably sure that X on intel chips just doesn't work properly anymore without KMS. The switch to the KMS resolution happens earlier now, but that doesn't hurt. The wiki seems to already contain information about this and it says some stuff about nomodeset being the option for non-intel chipsets only (which is obviously not quite true) and that X doesn't work without kms (which is also plain false). Now we know loads of workarounds but it's still a bug. I'd file it but it seems https://bugzilla.kernel.org/ is down. Down for you too?