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]
Message-ID: <4ADF6237.9070004@tremplin-utc.net>
Date:	Wed, 21 Oct 2009 21:34:15 +0200
From:	Éric Piel <eric.piel@...mplin-utc.net>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Greg KH <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
Subject: Re: [REGRESSION] "bind" a device to a driver doesn't not work	anymore

Op 15-10-09 23:59, Dmitry Torokhov schreef:

> 
> Hm, this is wierd... In the dmesg you sent me in the previous mail I see:
> 
> input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
> 
> So it looks like sometimes it is in raw and sometimes it is in
> translated mode. The i8042.reset might be affecting it. Also, are you
> using BIOS password at resume by any chance?
> 
> I guess we'll have to wait till you get back to the box and then I want
> fresh debug dmesgs (after poweroff) of older (with bind/unbind) and latest
> kernels, going through boot, 1st (make sure to type qwerty) and 2nd
> resume (qwerty again). Make sure you don't have any other i8042 or atkbd
> switches besides i8042.debug.
Hello,
Back with some results :-)

Attached is a (bzip-compressed) log [1] of a 2.6.30 kernel started with
i8042.debug (nothing else important).

The log contains 4 suspend-resumes (look for "Back to C"):
* from the console, using "echo mem > /sys/power/state", keyboard fine
* from the console, using "pm-suspend" (aka "all the nasty stuff done by
the distro"), keyboard fine
* from X, using "echo mem > /sys/power/state", keyboard gone
* a unbind-bind cycle, keyboard back
* from X, using "echo mem > /sys/power/state", keyboard fine


What I realised during this experiment, is that the keyboard goes away
after the first suspend-resume _in X_. Each time, I typed on the
keyboard "qwerty" (and almost nothing else).

Do you see what goes wrong in resuming the keyboard?

I can provide a similar log for a 2.6.32-rc3 kernel, if you are
interested? BTW, once the keyboard is gone, a rmmod-modprobe cycle of
psmouse doesn't recover it, it has to be a rmmod-modprobe cycle of atkbd.

See you,
Eric

[1] Also available uncompressed at
http://pieleric.free.fr/unorder/i8042-2.6.30-unbind-bind.dmesg

Download attachment "i8042-2.6.30-unbind-bind.dmesg.bz2" of type "application/x-bzip" (23478 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ