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:  <eu8kaa$stg$1@sea.gmane.org>
Date:	Mon, 26 Mar 2007 16:11:22 +0200
From:	Marcus Better <marcus@...ter.se>
To:	linux-kernel@...r.kernel.org
Subject:  Re: [3/5] 2.6.21-rc4: known regressions (v2)

Pavel Machek wrote:

>> > Subject    : ThinkPad R60: suspend to disk broken
>> > References : http://lkml.org/lkml/2007/3/23/74

>> input, so I suspended to RAM again. This time the resume failed, it hung
>> after printing "Linux!" in yellow at the top of the screen.

> Yellow Linux! is my debugging trick.

Cute :-)

Here is my bisect log so far, with 98 revisions left. Note that all kernels have the XFS workqueue patch applied.

~$ git bisect log
git-bisect start
# bad: [6fb04ccf5c5e054c4107090bed6e866489f1089f] Linux 2.6.21-rc5
git-bisect bad 6fb04ccf5c5e054c4107090bed6e866489f1089f
# good: [c8f71b01a50597e298dc3214a2f2be7b8d31170c] Linux 2.6.21-rc1
git-bisect good c8f71b01a50597e298dc3214a2f2be7b8d31170c
# good: [ad5f1196792653dadf09c07a5fa917092b469c1c] ecryptfs: check xattr operation support fix
git-bisect good ad5f1196792653dadf09c07a5fa917092b469c1c
# good: [271368b69b9e8042063d6c713423e84503bbdaa0] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
git-bisect good 271368b69b9e8042063d6c713423e84503bbdaa0
# bad: [f5b42c3324494ea3f9bf795e2a7e4d3cbb06c607] KVM: Fix guest sysenter on vmx
git-bisect bad f5b42c3324494ea3f9bf795e2a7e4d3cbb06c607

The bad kernels exhibit the hang on second resume from RAM.

The "good" ones all have the artifact with corrupted display. Moreover, they resume immediately from every suspend to RAM _after_ a suspend-to-disk, but not before it. This is when suspending with "echo mem > /sys/power/state".

> Try vga=0 ... text console seems to work for you.

Ok, will try.

Marcus


-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ