This bug was introduced in the 2.6.24 i386/x86_64 tree merge, where MSI-X vector allocation will eventually fail. The cause is the new bit array tracking used vectors is not getting cleared properly on IRQ destruction on the 32-bit APIC code. This can be seen easily using the ixgbe 10 GbE driver on multi-core systems by simply loading and unloading the driver a few times. Depending on the number of available vectors on the host system, the MSI-X allocation will eventually fail, and the driver will...

This bug was introduced in the 2.6.24 i386/x86_64 tree merge, where MSI-X vector allocation will eventually fail. The cause is the new bit array tracking used vectors is not getting cleared properly on IRQ destruction on the 32-bit APIC code. This can be seen easily using the ixgbe 10 GbE driver on multi-core systems by simply loading and unloading the driver a few times. Depending on the number of available vectors on the host system, the MSI-X allocation will eventually fail, and the driver will...

This version of the patch hopefully integrates all of the requested changes: - the sock_map_fd interface is changed and all in-tree users changed. No additional function anymore - there is a helper function to convert the new socket flags into file flags. Shared by all three functions - the new accept interface is now paccept() which adds the flag parameter as well as a signal mask. - not changed from the last version: the paccet() function takes a flags parameter with the same val...

Hi, I observed about the same message but after the line Brought up 2 CPUs in dmesg. However the system keeps running fine. I run a Core2 Duo processor. dmesg dump is attached. ------------[ cut here ]------------ WARNING: at kernel/lockdep.c:2662 check_flags+0x18d/0x190() Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.25 #2 Call Trace: [<ffffffff8022fbff>] warn_on_slowpath+0x5f/0x80 [<ffffffff80213a77>] ? native_sched_clock+0x57/0x80 [<ffffffff8022ac1a>] ...

omfs: add bitmap routines Add block allocation and block bitmap management routines for OMFS. Signed-off-by: Bob Copeland <me@bobcopeland.com> --- fs/omfs/bitmap.c | 192 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 192 insertions(+) Index: linux-2.6/fs/omfs/bitmap.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/fs/omfs/bitmap.c 2008-04-26 15:34:08.000...

omfs: define filesystem structures Add header files containing OMFS on-disk and memory structures. Signed-off-by: Bob Copeland <me@bobcopeland.com> --- fs/omfs/omfs.h | 67 +++++++++++++++++++++++++++++++++++++++++++++ fs/omfs/omfs_fs.h | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 147 insertions(+) Index: linux-2.6/fs/omfs/omfs.h =================================================================== --- /dev/null 1970-01-01 00:0...

Thanks again for the reviews. Not much changed since version 4, just addressed a few more concerns raised by Miklos and Marcin. These patches 1-8 add the Optimized MPEG Filesystem, a proprietary filesystem used by the embedded devices Rio Karma and ReplayTV, which are no longer manufactured. This filesystem module enables people to access files on these devices. version 5: - fix buffer leak in omfs_fill_super - fix inode leak in omfs_create/_mkdir, and combine them - switch to bitmap_we...

omfs: add filesystem documentation OMFS is a proprietary filesystem created for the ReplayTV and also used by the Rio Karma. It uses hash tables with unordered, unbounded lists in each bucket for directories, extents for data blocks, 64-bit addressing for blocks, with up to 8K blocks (only 2K of a given block is ever used for metadata, so the FS still works with 4K pages). Document the filesystem usage and structures. Signed-off-by: Bob Copeland &lt...

omfs: add file routines Add functions for reading and manipulating the storage of file data in the extent-based OMFS. Signed-off-by: Bob Copeland <me@bobcopeland.com> --- fs/omfs/file.c | 346 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 346 insertions(+) Index: linux-2.6/fs/omfs/file.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6/fs/omfs/file....

Hi, I encountered a build error with current git tree: CC [M] net/mac80211/led.o /home/kronos/src/linux-2.6.git/net/mac80211/led.c: In function 'ieee80211_led_init': /home/kronos/src/linux-2.6.git/net/mac80211/led.c:58: error: invalid application of 'sizeof' to incomplete type 'struct led_trigger' /home/kronos/src/linux-2.6.git/net/mac80211/led.c:62: error: dereferencing pointer to incomplete type /home/kronos/src/linux-2.6.git/net/mac80211/led.c:63: error: implicit declaration of function 'led_t...

subscribe linux-kernel --

You should mark the helper noinline just to prevent gcc from possibly inlining it. Even if it doesn't with your current compiler inline heuristics vary widely between compiler versions. -Andi --

Weird. Unexpected. Different from everyone else. Is this some exercise in obfuscation? But ok. -Andi --

Linus, please pull this x86 fix from: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-fixes2.git for-linus Thanks, Ingo ------------------> Venki Pallipadi (1): x86, PAT: disable /dev/mem mmap RAM with PAT arch/x86/mm/pat.c | 31 +++++++++++++++++++++++++++++++ 1 files changed, 31 insertions(+), 0 deletions(-) diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index 9851265..e7ca7fc 100644 --- a/arch/x86/mm/pat.c +++ b/arch/x86/mm/pat.c @@ -16,6 +16...

Hi Linus. Please apply the following two fixes by pulling from: master.kernel.org/pub/scm/linux/kernel/git/sam/kbuild.git The MODULE_LICENSE fix is neded to get an allmodconfig build fixed. Sam Adrian Bunk (1): kbuild: scripts/Makefile.modpost typo fix Sam Ravnborg (1): kbuild: soften MODULE_LICENSE check scripts/Makefile.modpost | 2 +- scripts/mod/modpost.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/scripts/Makefile....

The changelog was actually bad for this one. I saw two classes of problems: 1) I got report about broken builds - fbdev was the culprint. 2) a "make CONFIG_DEBUG_SECTION_MISMATCH=y" build broke immediately. I made it non-fatal because we had at least one module that was not yet fixed. Sam --

And by the way - had this been in -mm/-next as it ought to be we wuld know the eventual breakage it would have caused. But I have been a lousy maintainer the last months so that did not happen as it should and the MODULE_LICENSE thing went straight to -linus. Sam --

Linus, the following tree contains the "big box" topic commits of x86.git: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-bigbox.git for-linus Most of the work has been done by Yinghai Lu who has gone through a heroic effort to fix all the big-box bugs that he encountered on the vanilla Linux kernel on his various up to 256 GB RAM test-systems. Also work is included from Ying Huang for those insane SGI UV boxes. Most of these patches have been carried in x86.git since...

I'd like to see this sent as perhaps four independent pulls (where "independent" doesn't necessarily mean that they don't depend on each other and have some ordering, but is more of a "this is the bootup changes" vs "these are bootmem-related" etc, if at all possible. Quite frankly, from a review standpoint, very few people should need to (or want to) review individual commits when there are 50 of them (they might only care about the changes that 3 or 4 of them make, but they get lost ...

Linus, please pull the x86 "big box & GART" subtopic tree from: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-bigbox-gart.git for-linus it also touches drivers/char/agp/amd64-agp.c. Thanks, Ingo ------------------> Pavel Machek (1): x86: iommu: use symbolic constants, not hardcoded numbers Yinghai Lu (5): x86: agp_gart size checking for buggy device x86: checking aperture size order x86_64: allocate gart aperture from 512M ...

Linus, please pull the following x86 changes from: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-bigbox-bootparam.git for-linus these are boot parameter extensions for really large SGI UV boxes. The change was seen and acked by the boot protocol guys. (well, Peter that is ;-) Thanks, Ingo ------------------> Huang, Ying (4): x86, boot: add free_early to early reservation machanism x86, boot: add linked list of struct setup_data x86, boot: e...

Definitely shouldn't be assumed. At one point in the distant past I had a ppc memcpy which would clobber a destination cacheline before reading the source, so source and dest within a cacheline's distance would be trouble, regardless of the direction. Arch-specific code which knows about the arch-specific details of memcpy might be safer, I guess, but its still fairly brittle. J --

It's probably hard to write a reasonable x86 memcpy() that wouldn't happen to do the right thing for this case, but I do agee - we should still use memmove() for this, just to make it clear that it does overlapping things. Linus --

You have to do something pretty weird for memcpy() to not work for dst <= src even with overlap; this usually involves architectures that have explicit cache control instructions to establish the dst in the cache, if used before src is read. This is not an issue on x86, though. -hpa --

Noticed this when just trying to read the code to see if it looks sensible (without looking at any real details). Code like this is *not* acceptable. We do proper indentations. Improperly indented code is buggy. It doesn't matter if the compiler might generate the same code with or without indentation, it's still totally unacceptable. Having preprocessor conditionals that mix things up is not an excuse, and it might be an argument for not doing the conditional that way (ie maybe jus...