Fixed by the following patch. ============================= Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxx> --- arch/x86/boot/Makefile | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index d6ed8e5..0e4912f 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -64,10 +64,10 @@ KBUILD_CFLAGS := $(LINUXINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \ KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ ...

Hello list, There is a "ttyS1 irq is -1" problem observed on tiger4 which cause the serial port broken. It is because that there is __no__ ACPI IRQ resource assigned for the serial port. So the value of the IRQ for the port is never changed since it got initialized to -1. The attached patch falls back to the "no irq" hack for this case. It works for me. Please review and test. Thanks, Luming Signed-off-by: Yu Luming <luming.yu@intel.com> 8250_pnp.c | 3 +++ 1 files changed, 3 in...

If you use git just pull is already fixed if not get that patch : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=... Regards, Gabriel -

No, it's in Len's git tree. Len's git-pull request from a few days ago didn't work, perhaps because I wanted to know if a recent -mm regression had been fixed and that hasn't been answered yet. I assume that Len is offline. Other acpi developers could presumably have answered that question but for some reason chose not to. I'm presently holding off 20-odd power management patches due to their dependency upon an acpi merge... -

On Tue, 16 Oct 2007 22:22:43 -0400 Consider this an incentive to submit your code for inclusion in the upstream kernel. Having all the common drivers integrated in the mainline kernel makes it much easier for users to use all their hardware, external drivers are not just a pain for the developers. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kern...

On Tue, Oct 16, 2007 at 10:22:43PM -0400, Pavel Roskin wrote: > It would be nice to establish a rule to increment the version number > immediately after the kernel release and have a suffix to indicate that > it's a pre-rc version. "rc0" is my personal favorite. fwiw, rc0 is also what the Fedora kernel uses for versioning when we're shipping pre-rc1 kernels. Dave -- http://www.codemonkey.org.uk -

On Tue, Oct 16, 2007 at 10:45:17PM -0400, Pavel Roskin wrote: > > On Tue, 2007-10-16 at 22:34 -0400, Dave Jones wrote: > > On Tue, Oct 16, 2007 at 10:22:43PM -0400, Pavel Roskin wrote: > > > > > It would be nice to establish a rule to increment the version number > > > immediately after the kernel release and have a suffix to indicate that > > > it's a pre-rc version. "rc0" is my personal favorite. > > > > fwiw, rc0 is also wh...

Isn't this rather a kludge? What would be the cost of doing this cleanly and either redefining dma_data_direction to be a field-of-bits or just leave dma_data_direction alone (it is quite unrelated to this work, isn't it?) and adding new fields/arguments to manage this new functionality? -

So we take an `enum data_direction' and then wedge it into a word alongside some extra flags? Can we do something nicer than that? -

Introduce the dma_flags_set/get_*() interfaces and give them default implementations. Architectures which allow DMA to be reordered between a device and host memory (within a NUMA interconnect) can redefine these to allow a driver to explicitly synchronize DMA from the device when necessary. Signed-off-by: Arthur Kepner <akepner@sgi.com> --- Andrew, this is the first in a series of three patches: [1/3] dma: add dma_flags_set/get_*() interfaces [2/3] dma: redefine dma_flag...

Mostly fixes, except a couple things from Stephen H and myself. Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus to receive the following updates: drivers/net/3c59x.c | 8 +- drivers/net/Kconfig | 10 + drivers/net/bonding/bond_main.c | 11 +- drivers/net/bonding/bonding.h | 4 +- drivers/net/e1000e/ethtool.c | 35 ++- drivers/net/e1000e/hw.h | 2 +- drivers/net/f...

Hi, As stated in the subject, I cannot boot the current -git (most recent commit 821f3eff7cdb9d6c7076effabd46c96c322daed1) using GRUB on x86-64 openSUSE 10.2. The GRUB says that the kernel image is too big and doesn't fit into memory, but the kernel has been built and installed in exactly the same way as all of the previous -git kernels. Greetings, Rafael -

AFAICS, fallout from repacing include of blkdev.h with include of bio.h. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c index 71b986b..7ae18ea 100644 --- a/drivers/mmc/host/mmc_spi.c +++ b/drivers/mmc/host/mmc_spi.c @@ -30,6 +30,7 @@ #include <linux/dma-mapping.h> #include <linux/crc7.h> #include <linux/crc-itu-t.h> +#include <linux/scatterlist.h> #include <linux/mmc/host.h> ...

Umm... IIRC, m32r had been the first build to step into that, at which point the missing include had been added; the rest had reached that point later, so I'm not sure which ones would trigger the same crap. Not hard to test, though... Aha. m68k as well. -

Something really odd has happened: the last couple of changesets have - int up_flag; + int keycode, up_flag; and - int up_flag; + int up_flag, key; in another, both in adb_input_keycode(). Even with -m passed to git-whatchanged there's no sign of anything in that area. Aside of trivial conflict resolution (see below), what's the right way to trace the things like that? Linus? Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- diff --git a/drivers/macintosh...

Btw, if anybody can come up with a better way to find these kinds of mis-merges, I'd love to hear about it. In *this* particular case, the -c flag ("combined" merge diff) probably comes closest, and is certainly a lot better than passing in -m (which shows each merge against both parents separately), and in fact, I think you would have found the mis-merge immediately if you had used git whatchanged -p -c v2.6.23.. drivers/macintosh/adbhid.c but I'm not going to guarantee that -c alwa...

The i5000_edac driver's PCI registration structure has the name ""i5000_edac"" (with extra set of double-quotes) which is probably not intentional. Get rid of __stringify. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> --- drivers/edac/i5000_edac.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/edac/i5000_edac.c b/drivers/edac/i5000_edac.c index 96f7e63..a1f24c4 100644 --- a/drivers/edac/i5000_edac.c +++ b/drivers/edac/i5000_edac.c @@ -1462,7 +1...

Linus, please pull from the for-linus branch at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus to receive the following IEEE 1394/ FireWire subsystem updates. It's almost all just bugfixes, and had I anticipated that 2.6.23 was going to grow an -rc9 I would have sent most of the material for the new firewire stack already during the rc phase. Most patches went into -mm during mid July...mid September; some simple patches are from the past two weeks. Com...

While scanning over today's updates in Linus's tree, I noticed the following commit has no changes, and this does not appear to be intentional. Someone should check it out. commit e31b6656a81d6332cdf6af17d38a0573128a6aac Author: Krzysztof Helt <krzysztof.h1@wp.pl> Date: Tue Oct 16 14:54:58 2007 +0200 [ALSA] This simplifies and fixes waiting loops of the mce_down() function after Trent Piepho's patch for AD1848. It also makes busy_wait() function call not atomic. ...

From: Linus Torvalds <torvalds@linux-foundation.org> That would be useful, I think it is a common error when importing and exporting patches. -

Please bisect this (the alsa merge happened just short time ago) Which kernel did work? Best regards, Maxim Levitsky -

Hi Jeff, while browsing through Linus' current check ins, I stumbled upon: [SCSI] arcmsr: irq handler fixes, cleanups, micro-opts: --8<-- 488a5c8a9a3b67ae117784cd0d73bef53a73d57d drivers/scsi/arcmsr/arcmsr_hba.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c index 7832a10..f4d2d52 100644 --- a/drivers/scsi/arcmsr/arcmsr_hba.c +++ b/drivers/scsi/arcmsr/arcmsr_hba.c @@ -422,7 +422,7 @@ static...

While looking at a net driver with the following construct, if (!netif_carrier_ok(dev)) netif_carrier_on(dev); it stuck me that the netif_carrier_ok() check was redundant, since netif_carrier_on() checks bit __LINK_STATE_NOCARRIER anyway. This is the same reason why netif_queue_stopped() need not be called prior to netif_wake_queue(). This is true, but there is however an unwanted side effect from assuming that netif_carrier_on() can be called multiple times: it touches the watchdog, reg...

From a quick read through the code, looks like net/core/neighbour.c:neigh_table_clear() needs a kmem_cache_destroy()? I only see three callers of neight_table_clear() and they all seem to be in exit routines, so that should be safe? -Nish -

schedstat is useful in investigating CPU scheduler behavior. Ideally, I think it is beneficial to have it on all the time. However, the cost of turning it on in production system is quite high, largely due to number of events it collects and also due to its large memory footprint. Most of the fields probably don't need to be full 64-bit on 64-bit arch. Rolling over 4 billion events will most like take a long time and user space tool can be made to accommodate that. I'm proposing kernel to cut ...