linux-kernel - Re: [Bug 14658] Regression in efi.c

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]

Date:	Mon, 23 Nov 2009 21:41:06 +1030
From:	indexer <indexer@...ernode.on.net>
To:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Bug 14658] Regression in efi.c

Thomas Gleixner wrote:
> On Mon, 23 Nov 2009, indexer wrote:
>   
>>> while the bisect should have be done with
>>>
>>> good 2.6.30
>>> bad  2.6.31
>>>
>>> William, could you please go through the bisect pain again?
>>>
>>>       
>> I had already done a similar bisect to this in private conversation to Huang
>> Ying, and is what prompted me to expand my bisect out. I redid it regardless
>> and will send you the information.
>>
>> commit 74fca6a42863ffacaf7ba6f1936a9f228950f657
>> Author: Linus Torvalds <torvalds@...ux-foundation.org>
>> Date:   Wed Sep 9 15:13:59 2009 -0700
>>
>>    Linux 2.6.31
>>
>> Makefile |    2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>     
>
> So you are saying that 
>  
>   
>> # good: [7135a71b19be1faf48b7148d77844d03bc0717d6] aoe: allocate unused
>> request_queue for sysfs
>> git bisect good 7135a71b19be1faf48b7148d77844d03bc0717d6
>>     
>
> which is the last code changing commit before the 2.6.31 release is
> booting fine, but with the release commit which merily changes the
> Makefile it is not ?
>   
I dont know, I will test this as soon as possible. I might change the 
bisect parameters a bit, but really im quite new to all this. It may 
also be a possibility it is gen-patches breaking it as i reported 
2.6.30-gentoo was the broken kernel. Either way, the fact remains that 
on 2.6.31 and higher vanilla it is broken.
>   
>> PS - The fact remains i still cant efi boot in 2.6.32-rc7, so this bug still
>> exists, and I will keep doing what i can to help track this down.
>>     
>
> Sure, but I hope we agree that it does not make much sense to search
> 2.6.31..now when we already know that 2.6.31 is not booting and the
> change which causes the problem is between 2.6.30 and 2.6.31.
>
> Thanks,
>
> 	tglx
>
> --
> 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/
>   
 Oh i have no issues agreeing with you, but its really confusing me, and 
i of course may have made an error in what i reported. I am after all 
only human, and i might have made a mistake, and this is the first time 
i have ever submitted a bug, let alone found one like this. The end 
product is that 2.6.32 doesn't boot, but maybe the last working version 
was not 2.6.30-rc8, maybe it was a 2.6.31 kernel. I might redo the 
bisect and try this out again, as i'm quite intent on finding the source 
of this. I will also see if i can get my hands on another x86_64 linux 
install with efi to test it on a different machine to see if it is 
hardware specific to my computer. For the record i am running a late 
2009 macbook pro gen 5 rev 3, efi version 1.7 with refit and elilo.

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