linux-kernel - Re: reset during bootup

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: <p73wsw0j1er.fsf@bingen.suse.de>
Date:	12 Aug 2007 16:03:08 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	"Dan Merillat" <dan.merillat@...il.com>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	rusty@...tcorp.com.au, Petr Vandrovec <petr@...drovec.name>
Subject: Re: reset during bootup - solved

"Dan Merillat" <dan.merillat@...il.com> writes:

> On 8/11/07, Dan Merillat <dan.merillat@...il.com> wrote:
> > This one is going to be fun, since it's a hard reset back to bios, no
> > OOPS or anything shown.  It may be about the time RadeonFB kicks in,
> > but it's impossible to tell.  I'd guess 15-20 lines into dmesg.
> >
> > I'm in the process of bisecting, currently 94c18227..d23cf676.
> >
> > Any guesses of a specific patch to check?
> 
> Except it's not d23cf676, that was the version I was running while
> building HEAD, whoops.
> I'm used to monotonic version numbers, not SHA hashes.  I'll keep
> better track next time.
> 
> For completeness, the commit that caused boot to fail was:
> 
> commit ab144f5ec64c42218a555ec1dbde6b60cf2982d6
> Author: Andi Kleen <ak@...e.de>

BTW the patch was actually from Rusty, not me, just the From 
line got lost somewhere. I did a few changes though because
the initial version didn't work on x86-64 at all. Submitted
one worked for me.

> Date:   Fri Aug 10 22:31:03 2007 +0200
> 
>     i386: Make patching more robust, fix paravirt issue
> 
> Except I'm using x86_64?  So not sure why that one rev kills me.

The code is used on x86-64 too, but the script that generates
the prefixes doesn't know this (perhaps I should drop them) 

> ACPI? It dies right after the CPU is identified:
> CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 00
> ACPI: Core revision 20070126

Ok that settles it.

However I must say I'm still dubious of Petr's patch. If there
is something wrong with alternative() then it must be fixed
in alternative() not the call sites. Otherwise it could hit
other patch sites too. There are other copies who
use a similar patching pattern.

Can people who see a failure please send me .config and 
arch/x86_64/lib/memcpy.o privately ? 

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