linux-kernel - Re: Linux 2.6.37-rc4

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] [day] [month] [year] [list]

Message-ID: <a07a23e9b233db5f3095b8658198311c.squirrel@webmail.greenhost.nl>
Date:	Sun, 5 Dec 2010 18:28:12 +0100 (CET)
From:	"Indan Zupancic" <indan@....nu>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.37-rc4

Hello,

On Tue, November 30, 2010 06:36, Linus Torvalds wrote:
>
> So give it a try, and report any regressions you see,

For everyone trying to bisect regressions, beware of the following:

- Bisect doesn't save your old .config.

- When bisecting between 2.6.36 and HEAD there are enough config
  options changed so you have to manually choose new (old) options.
  This means you can't run it fully automatic, because user input
  is needed.

- Somewhere between there and here, the kernel will stop updating
  arch/x86/boot/bzImage. Maybe only if you have CONFIG_KERNEL_LZMA
  set, but still. The result is that you'll be testing the same
  kernel over and over while recompiling for naught, messing up the
  whole bisecting thing. Or something else weird may be going on.

The latter is fixed at least in rc4 (haven't tried earlier kernels),
but it still bites you when bisecting. (Or only me)

Other than, it takes ages to bisect on a slow laptop with an even
slower hard disk, because you throw the whole file cache away after
each reboot. Perhaps I should have installed ccache.

I've also seen internal compiler errors a couple of times. Retrying
did seem to get past it, and I think I only got it with higher -j
options (2, 3, 4), so maybe it's just something running out of memory.
Or it's my laptop getting too stressed out and giving hardware errors,
but I'd say that's unlikely. Could also just be a bug in newer gcc.
Or it's related to whatever causes the bugs I see. I'm too grumpy
to find out.

The regressions I hit are:

https://bugzilla.kernel.org/show_bug.cgi?id=23472
https://bugzilla.kernel.org/show_bug.cgi?id=22672

This on a Thinkpad X40 with Intel 855GM chipset.

As far as I know, the BIOS is the one controlling the backlight on
this laptop, and everything always worked fine. Now the backlight
gets messed up when resuming, and it doesn't turn on until a s2ram
cycle after a "xset dpms force suspend". So it seems that something
started messing with the backlight control while it didn't before,
and it does it wrong.

I'll add a "me too" to those bugzilla's.

xf86-video-intel 2.13 has major problems, so I'm running 2.12, but
that's another problem for another day, and off-topic here.

Good day,

Indan

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