Bug 8040

*** Bug 8039 has been marked as a duplicate of this bug. ***

This bug also happens on Xeon 3000 model Supermicro

Please see bug 8148 too.
I have neither of those kernel options enabled and with an older K6 600 mhz
based system I have the exact same symptoms.

Any news on that bug please ?

Reply-To: akpm@linux-foundation.org

> On Wed, 14 Mar 2007 03:13:25 -0700 bugme-daemon@bugzilla.kernel.org wrote:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=8040
> 
> 
> 
> 
> 
> ------- Additional Comments From Nilshar@gmail.com  2007-03-14 03:13 -------
> Any news on that bug please ?

None whatsoever.  Three people are reporting this and it's a drop-dead
showstopper for a 2.6.21 release so we just have to wait until someone
wakes up and thinks about it.

It would be very useful if one of the reporters could perform a git-bisect
search to identify the offending change, please.

I would dearly like to point you at a document or web page which describes
kernel-git-bisect-for-newbies, but afaik there isn't such a thing, which is
a huge failing.

On Wed, 14 Mar 2007, Andrew Morton wrote:

> > On Wed, 14 Mar 2007 03:13:25 -0700 bugme-daemon@bugzilla.kernel.org wrote:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=8040
> >
> >
> > ------- Additional Comments From Nilshar@gmail.com  2007-03-14 03:13 -------
> > Any news on that bug please ?
>
> None whatsoever.  Three people are reporting this and it's a drop-dead
> showstopper for a 2.6.21 release so we just have to wait until someone
> wakes up and thinks about it.
>
> It would be very useful if one of the reporters could perform a git-bisect
> search to identify the offending change, please.
>
> I would dearly like to point you at a document or web page which describes
> kernel-git-bisect-for-newbies, but afaik there isn't such a thing, which is
> a huge failing.

I have one of those one-of-my-machines-wont-boot-2.6.21-rc*
and I expect that I'll try to use git bisect on it, in which case
I will also document it.

On 14/03/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Wed, 14 Mar 2007 03:13:25 -0700 bugme-daemon@bugzilla.kernel.org wrote:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=8040
> >
> >
> >
> >
> >
> > ------- Additional Comments From Nilshar@gmail.com  2007-03-14 03:13 -------
> > Any news on that bug please ?
>
> None whatsoever.  Three people are reporting this and it's a drop-dead
> showstopper for a 2.6.21 release so we just have to wait until someone
> wakes up and thinks about it.
>
> It would be very useful if one of the reporters could perform a git-bisect
> search to identify the offending change, please.
>
> I would dearly like to point you at a document or web page which describes
> kernel-git-bisect-for-newbies, but afaik there isn't such a thing, which is
> a huge failing.

"Linux testers handbook" should be translated in a few weeks.

Here is a "git-bisect basics" movie :)
http://www.youtube.com/watch?v=R7_LY-ceFbE

Regards,
Michal

I'll try git-bisect, not sure what it is exactly, but I can certainly do it to
try  helping in resolving this bug. I'll search google, but if you got a good
link, I can use it :)

Bisecting went well, after 13 compiles this commit was found:

a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f is first bad commit
commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f
Author: Roland McGrath <roland <at> redhat.com>
Date:   Fri Jan 26 00:56:46 2007 -0800

    [PATCH] Fix CONFIG_COMPAT_VDSO

    I wouldn't mind if CONFIG_COMPAT_VDSO went away entirely.  But if it's there,
    it should work properly.  Currently it's quite haphazard: both real vma and
    fixmap are mapped, both are put in the two different AT_* slots, sysenter
    returns to the vma address rather than the fixmap address, and core dumps yet
    are another story.

    This patch makes CONFIG_COMPAT_VDSO disable the real vma and use the fixmap
    area consistently.  This makes it actually compatible with what the old vdso
    implementation did.

    Signed-off-by: Roland McGrath <roland <at> redhat.com>
    Cc: Ingo Molnar <mingo <at> elte.hu>
    Cc: Paul Mackerras <paulus <at> samba.org>
    Cc: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
    Cc: Andi Kleen <ak <at> suse.de>
    Signed-off-by: Andrew Morton <akpm <at> osdl.org>
    Signed-off-by: Linus Torvalds <torvalds <at> linux-foundation.org>

:040000 040000 802ab3366a651ecba28c8677fa84a9f7c506392b
f44adc4dcdab733e5965b68ccd0d643f0a550a80 M      arch
:040000 040000 be1e217152d8b3fcd05f09aa2b3f4f9dcb8208aa
46cc86427e861350dd3fef9469474c55119f27ce M      include

I had both CONFIG_COMPAT_VDSO=y and CONFIG_HIGHMEM64G=y configured.
Using a 4GB Supermicro 7044 SMP dual Xeon. Details upon request.

--
Leroy

So if I set CONFIG_COMPAT_VDSO=n I should be able to boot ?


2007/3/14, bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org>:
> http://bugzilla.kernel.org/show_bug.cgi?id=8040
>
>
>
>
>
> ------- Additional Comments From leroy.vanlogchem@wldelft.nl  2007-03-14 14:47 -------
> Bisecting went well, after 13 compiles this commit was found:
>
> a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f is first bad commit
> commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f
> Author: Roland McGrath <roland <at> redhat.com>
> Date:   Fri Jan 26 00:56:46 2007 -0800
>
>     [PATCH] Fix CONFIG_COMPAT_VDSO
>
>     I wouldn't mind if CONFIG_COMPAT_VDSO went away entirely.  But if it's there,
>     it should work properly.  Currently it's quite haphazard: both real vma and
>     fixmap are mapped, both are put in the two different AT_* slots, sysenter
>     returns to the vma address rather than the fixmap address, and core dumps yet
>     are another story.
>
>     This patch makes CONFIG_COMPAT_VDSO disable the real vma and use the fixmap
>     area consistently.  This makes it actually compatible with what the old vdso
>     implementation did.
>
>     Signed-off-by: Roland McGrath <roland <at> redhat.com>
>     Cc: Ingo Molnar <mingo <at> elte.hu>
>     Cc: Paul Mackerras <paulus <at> samba.org>
>     Cc: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
>     Cc: Andi Kleen <ak <at> suse.de>
>     Signed-off-by: Andrew Morton <akpm <at> osdl.org>
>     Signed-off-by: Linus Torvalds <torvalds <at> linux-foundation.org>
>
> :040000 040000 802ab3366a651ecba28c8677fa84a9f7c506392b
> f44adc4dcdab733e5965b68ccd0d643f0a550a80 M      arch
> :040000 040000 be1e217152d8b3fcd05f09aa2b3f4f9dcb8208aa
> 46cc86427e861350dd3fef9469474c55119f27ce M      include
>
> I had both CONFIG_COMPAT_VDSO=y and CONFIG_HIGHMEM64G=y configured.
> Using a 4GB Supermicro 7044 SMP dual Xeon. Details upon request.
>
> --
> Leroy
>
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>

Chuck Ebbert at redhat.com asked:

> Can you please double check this by trying with/without again -- sometimes
bisects go bad.

As requested I started to redo the test but now without git using 
kernel.org tars.
The results now are, still using the same .config:
linux-2.6.20.tar.gz   : bad
linux-2.6.20.1.tar.gz: bad (boot log equal)
linux-2.6.20.2.tar.gz: good
linux-2.6.20.3.tar.gz: good
(triple checked)

Really strange. Nilshar, please try these kernels too with:
COMPAT_VDSO=y
CONFIG_HIGHMEM64G=y

Nilshar did try and says 2.6.20.3 works fine. So only 2.6.20 and 2.6.20.1 had
this 'hang' at boot behaviour.

Since no more reports for later kernel releases, I guess the bug can be closed as fixed. Please reopen if you believe the problem is still there.