linux-kernel - Re: regression 2.6.37 -> 2.6.38-rc1: after suspend backlight cannot be adjusted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Jan 2011 05:16:34 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Norbert Preining <preining@...ic.at>
Cc:	linux-kernel@...r.kernel.org,
	ACPI Devel Mailing List <linux-acpi@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: regression 2.6.37 -> 2.6.38-rc1: after suspend backlight
 cannot be adjusted

Le vendredi 21 janvier 2011 à 05:11 +0100, Eric Dumazet a écrit :
> Le vendredi 21 janvier 2011 à 10:55 +0900, Norbert Preining a écrit :
> > Hi everyone,
> > 
> > (please Cc)
> > 
> > going to 2.6.38-rc1 I see the following regression: After reboot I
> > can easily adjust the backlight with the keys on my keyboard, but 
> > after a suspend-to-ram this does not work anymore.
> > 
> > This is a Sony laptop, and backlight is controlled by the video
> > acpi driver AFAIR.
> > 
> 
> Hi Norbert
> 
> Maybe this is the problem Linus had to bisect, you could try his patch :
> 
> http://marc.info/?l=linux-netdev&m=129556877919576&w=2
> 
> Thanks !
> 

Or just pull linux-2.6, since patch is now committed

commit 28e58ee8ce1f0e69c207f747b7b9054b071e328d
Author: Linus Torvalds <torvalds@...ux-foundation.org>
Date:   Thu Jan 20 16:21:59 2011 -0800

    Fix broken "pipe: use event aware wakeups" optimization
    
    Commit e462c448fdc8 ("pipe: use event aware wakeups") optimized the pipe
    event wakeup calls to avoid wakeups if the events do not match the
    requested set.
    
    However, the optimization was buggy, in that it didn't actually use the
    correct sets for the events: when we make room for more data to be
    written, the pipe poll() routine will return both the POLLOUT _and_
    POLLWRNORM bits.  Similarly for read.
    
    And most critically, when a pipe is released, that will potentially
    result in POLLHUP|POLLERR (depending on whether it was the last reader
    or writer), not just the regular POLLIN|POLLOUT.
    
    This bug showed itself as a hung gnome-screensaver-dialog process, stuck
    forever (or at least until it was poked by a signal or by being traced)
    in a poll() system call.
    
    Cc: Davide Libenzi <davidel@...ilserver.org>
    Cc: David S. Miller <davem@...emloft.net>
    Cc: Eric Dumazet <eric.dumazet@...il.com>
    Cc: Jens Axboe <axboe@...nel.dk>
    Cc: Andrew Morton <akpm@...ux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/