On Tue, Nov 13, 2007 at 03:15:53AM -0800, Andrew Morton wrote: > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <[EMAIL PROTECTED]> > wrote: > > PLATFORM=============================================================== > > > > xipImage is built so that uBoot cant run it (ARM) > > http://bugzilla.kernel.org/show_bug.cgi?id=9356 > > 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) > > http://bugzilla.kernel.org/show_bug.cgi?id=9229 > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Acked-by: Nicolas Pitre <[EMAIL PROTECTED]> Signed-off-by: Russell King <[EMAIL PROTECTED]> 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 - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
