Bug 11986

Reply-To: linux@arm.linux.org.uk

This is not a regression.

The 'reset floating' issue has been fixed.  The remaining issue over
the decompressor has never been in the kernel so is not a regression.

Please close this "regression" report.

On Sat, Nov 08, 2008 at 03:46:48PM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=11986
> 
>            Summary: 2.6.28-rc2-git1: spitz still won't boot
>            Product: Platform Specific/Hardware
>            Version: 2.5
>      KernelVersion: 2.6.28-rc2-git1
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: ARM
>         AssignedTo: linux-arm-kernel@lists.arm.linux.org.uk
>         ReportedBy: rjw@sisk.pl
>                 CC: pavel@suse.cz
> OtherBugsDependingO 11808
>              nThis:
>         Regression: 1
> 
> 
> Subject    : 2.6.28-rc2-git1: spitz still won't boot
> Submitter  : Pavel Machek <pavel@suse.cz>
> Date       : 2008-11-05 14:23
> References : http://marc.info/?l=linux-kernel&m=122589528016337&w=4
> 
> This entry is being used for tracking a regression from 2.6.27.  Please don't
> close it until the problem is fixed in the mainline.
> 
> 
> -- 
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> 
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

> Reply-To: linux@arm.linux.org.uk
> 
> This is not a regression.
> 
> The 'reset floating' issue has been fixed.  The remaining issue over
> the decompressor has never been in the kernel so is not a regression.
> 
> Please close this "regression" report.

2.6.27+reset_floating_fix boots.

2.6.28-rc3 has reset_floating_fix, still it does not boot... on
similar config, and with any config I tried. (The vmlinux.lds.S patch
does not help).

Seems like regression to me.
							Pavel

Reply-To: linux@arm.linux.org.uk

On Sun, Nov 09, 2008 at 03:28:10AM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> 2.6.27+reset_floating_fix boots.
> 
> 2.6.28-rc3 has reset_floating_fix, still it does not boot... on
> similar config, and with any config I tried. (The vmlinux.lds.S patch
> does not help).
> 
> Seems like regression to me.

That information is missing from the thread on LKML (maybe that's
because I'm not receiving your emails for god knows what reason.)

The only suggestion I have is to bisect to find which change caused
the problem.  Lack of any way to get boot logs from the device doesn't
give any other way to locate the cause.

> On Sun, Nov 09, 2008 at 03:28:10AM -0800, bugme-daemon@bugzilla.kernel.org
> wrote:
> > 2.6.27+reset_floating_fix boots.
> > 
> > 2.6.28-rc3 has reset_floating_fix, still it does not boot... on
> > similar config, and with any config I tried. (The vmlinux.lds.S patch
> > does not help).
> > 
> > Seems like regression to me.
> 
> That information is missing from the thread on LKML (maybe that's
> because I'm not receiving your emails for god knows what reason.)
> 
> The only suggestion I have is to bisect to find which change caused
> the problem.  Lack of any way to get boot logs from the device doesn't
> give any other way to locate the cause.

I actually attempted bisect at one point, but since time when
reset_floating_fix is merged, the tree does not compile. So the
timeline seems to be:

2.6.27:  has reset_floating problem.

2.6.28-rc0-something: compile problem introduced.

2.6.28-something: reset_floating fixed.

2.6.28-rc2: compile problem fixed.

...and somehwere between 2.6.27 and 2.6.28-rc2 another problem
preventing boot was introduced. bisect is not exactly easy in that
situation :-(.
								Pavel

Reply-To: linux@arm.linux.org.uk

On Sun, Nov 09, 2008 at 03:43:17AM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> I actually attempted bisect at one point, but since time when
> reset_floating_fix is merged, the tree does not compile. So the
> timeline seems to be:
> 
> 2.6.27:  has reset_floating problem.
> 
> 2.6.28-rc0-something: compile problem introduced.
> 
> 2.6.28-something: reset_floating fixed.
> 
> 2.6.28-rc2: compile problem fixed.
> 
> ...and somehwere between 2.6.27 and 2.6.28-rc2 another problem
> preventing boot was introduced. bisect is not exactly easy in that
> situation :-(.

Short of bisecting or finding some way to get kernel messages out of
the device, I don't see any way to progress this problem.

I can only suggest to extract the compile fixes and to appropriately
reapply them for each bisect test.

Reply-To: linux@arm.linux.org.uk

On Sun, Nov 09, 2008 at 03:43:17AM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> I actually attempted bisect at one point, but since time when
> reset_floating_fix is merged, the tree does not compile. So the
> timeline seems to be:
> 
> 2.6.27:  has reset_floating problem.
> 
> 2.6.28-rc0-something: compile problem introduced.
> 
> 2.6.28-something: reset_floating fixed.
> 
> 2.6.28-rc2: compile problem fixed.
> 
> ...and somehwere between 2.6.27 and 2.6.28-rc2 another problem
> preventing boot was introduced. bisect is not exactly easy in that
> situation :-(.

What you could try the 'revert-ptebits' branch I've just created, so we
can rule those changes out.  Also check current mainline.

http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/revert-ptebits

+

	.mbox for the individual patches to manually bisect
	.diff for a single patch version.

against yesterday-ish mainline.

Handled-By : ARM Linux <linux@arm.linux.org.uk>

Reply-To: linux@arm.linux.org.uk

On Sun, Nov 09, 2008 at 10:58:50AM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> ------- Comment #7 from rjw@sisk.pl  2008-11-09 10:58 -------
> Handled-By : ARM Linux <linux@arm.linux.org.uk>

Grr.  No.  The request to test is only a mere stab in the dark.  If that
doesn't work, I've nothing further to add.

It's times like this I find this regression tracking quite silly and
out of control.

OK, so you're not handling it.  Fine, but please don't be so !@#$%^& rude, thanks.

Not-Handled-By : ARM Linux <linux@arm.linux.org.uk>

Reply-To: linux@arm.linux.org.uk

On Sun, Nov 09, 2008 at 11:43:16AM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=11986
> 
> ------- Comment #9 from rjw@sisk.pl  2008-11-09 11:43 -------
> OK, so you're not handling it.  Fine, but please don't be so !@#$%^& rude,
> thanks.

How about actually talking to the person in question before updating these
entries with incorrect information rather than just throwing stuff randomly
into bugzilla?

On Monday, 10 of November 2008, Pavel Machek wrote:
> > 2008/11/9 Pavel Machek <pavel@suse.cz>:
> > > On Sun 2008-11-09 12:45:45, Pavel Machek wrote:
> > >> On Fri 2008-11-07 17:57:33, Dmitry wrote:
> > >> > 2008/11/7 Pavel Machek <pavel@suse.cz>:
> > >> > > On Fri 2008-11-07 21:23:41, Eric Miao wrote:
> > >> > >> Well, IIRC spitz still needs the patch to change the vmlinux.ld.S.
> > >> > >> Did you guys ever try that?
> > >> > >
> > >> > > I never heard about that patch, do you have it handy?
> > >> >
> > >> > http://rpsys.net/openzaurus/patches/archive/pxa-linking-bug.patch
> > >> >
> > >> > I plan to submit a bit modified version of this patch later.
> > >>
> > >> Could you send me full .config that is known to work?
> > >>
> > >> Do I need pxa-linking-bug.patch to get it to boot?
> > >
> > > (Note that I'm booting using kexec, not sharp bootloader).
> > 
> > It seems that neither kexec, nor qemu require pxa-linking-bug.patch
> > 
> > Attached a .config that I use for testing. It contains all sharp zaurii
> > selected, however you can easily deselect unnecessary ones.
> 
> Ugh, that one took quite a while to compile. Fortunately, this one
> actually boots... (up to "launching init", anyway)... so the problem
> seems to be config-dependend.