linux-kernel - Re: 2.6.25-rc hangs

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

Date:	Sun, 9 Mar 2008 19:49:36 +0100 (CET)
From:	Christian Kujau <lists@...dbynature.de>
To:	Eric Sandeen <sandeen@...deen.net>
cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.25-rc hangs

On Sun, 9 Mar 2008, Eric Sandeen wrote:
> I meant the test you were using to determine "good" from "bad" - I guess
> it was "boot up and do IO for a while to see if it hangs"

Maybe I was too confusing, let me try again:

* 2.6.24.1 was running fine for weeks (and is now)
* 2.6.25-rc3, -rc4 comes with system hang. Trying to bisect it failed
   at a really early stage:

  [check out current -git, 2.6.25-rc4)
  $ git bisect start
  $ git bisect bad          # because I know, that current -git is bad
  $ git bisect good v2.6.24 # because I know 2.6.24 is good
  [ compiling, and first reboot]
  -> failed, because hard lockup.

After rebooting to a working kernel I can now do either:

  1) mark the current one as "bad", solely on the fact that "it does not
    boot" and is "bad" per se, ignoring the fact that if the box *had*
    booted, the system hang *perhaps* did not occur. IOW, I'm marking
    it "bad" because of a totally different issue.

  2) although booting failed, I still mark it "good", which means I'm
    literally *guessing* that this current kernel (bd45ac0c5daa...)
    does NOT have the system hang and thus affecting all subsequent
    bisects. Worst case: this guess turns out to be false and I'm bisecting
    all through all ~2800 revisions without ever getting the correct "bad"
    one (because they were actually all "bad").

I tried 1), but did not get any further, as the next kernel did not boot 
either.
I tried 2), but did not get any further, as the next kernel did boot but 
locked up when I tried to use the device mapper.

Hope that's a bit better explained than before...

Thanks,
C.
-- 
BOFH excuse #58:

high pressure system failure
--
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/