[lkml]   [2007]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 03:15:53AM -0800, Andrew Morton wrote:
> On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <> wrote:
> > PLATFORM===============================================================
> >
> > xipImage is built so that uBoot cant run it (ARM)
> >
> > Kernel: 2.6.21
> Zero responses from developers

For christ sake Andrew. Some of us are not employed to do kernel work
24h x 365days a year. You might be, I'm not.

First thing, it's not a regression. Second thing, it's *not* a bug.

uboot requires kernel images to be specially wrapped up in their crappy
formats before uboot will recognise it. This means that if someone wants
to boot a binary image with uboot, they need to either:

1. work out the correct 'mkimage' command and run that program after
the kernel build has completed.

2. sort out adding a new target to the kernel makefiles to run this
uboot specific 'mkimage' command automatically.

And Alexandre (the original feature-missing reporter) has linked to a
message where a patch was proposed to do (2). So obviously it's no
longer a problem for the reporter.

> > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't
> > boot (ARM, Timer)
> >
> > Kernel: 2.6.23
> No response from developers

Bug was assigned to reporter, so I ignored it on the grounds that the
reporter was resolving it. Plus, until recently I didn't have any
workable PXA systems to test stuff on.

In the end, a similar issue has been resolved anyway after a lot of
discussion on the ARM lists about how PXA should handle one-shot mode
with clockevents. It took absolutely ages to get agreement on what was
a simple patch.

commit 91bc51d8a10b00d8233dd5b6f07d7eb40828b87d
Author: Russell King <>
Date: Thu Nov 8 23:35:46 2007 +0000

[ARM] pxa: fix one-shot timer mode

One-shot timer mode on PXA has various bugs which prevent kernels
build with NO_HZ enabled booting. They end up spinning on a
permanently asserted timer interrupt because we don't properly
clear it down - clearing the OIER bit does not stop the pending
interrupt status. Fix this in the set_mode handler as well.

Moreover, the code which sets the next expiry point may race with
the hardware, and we might not set the match register sufficiently
in the future. If we encounter that situation, return -ETIME so
the generic time code retries.

Acked-by: Thomas Gleixner <>
Acked-by: Nicolas Pitre <>
Signed-off-by: Russell King <>

Ergo, the bug can be closed provided the reporter re-tests a recent git
snapshot. Sorry, no idea how the above commit relates to Linus' releases
and/or git snapshots.

Russell King
Linux kernel 2.6 ARM Linux -
maintainer of:
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-11-13 19:13    [W:0.295 / U:3.052 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site