Hi all, Here is a list of some known regressions in 2.6.23-rc6 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces Name Regressions fixed since 21-Jun-2007 Adrian Bunk 10 Andi Kleen 7 Linus Torvalds 6 Alan Stern 5 Hugh Dickins 5 Trond Myklebust ...

Hi all, Here is a list of some known regressions in 2.6.23-rc6. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces Name Regressions fixed since 21-Jun-2007 Adrian Bunk 10 Andi Kleen 7 Linus Torvalds 6 Alan Stern 5 Hugh Dickins 5 Trond Myklebust 5 Andrew Morton ...

Mailing list changed. The former list at mpt_linux_developer@lsi.com is no longer in service. Please use the new email provided listed in this patch. Signed-off-by: Eric Moore <Eric.Moore@lsi.com> diff -uarpN b/MAINTAINERS a/MAINTAINERS --- b/MAINTAINERS 2007-08-15 16:33:58.000000000 -0600 +++ a/MAINTAINERS 2007-09-14 19:20:34.000000000 -0600 @@ -2375,7 +2375,7 @@ LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) P: Eric Moore M: Eric.Moore@lsi.com M: support@lsi.com -L: mpt_linux_developer@ls...

Hi Kai, Sam. I have a single file foo.c that I want to generate two (ALSA) modules from, snd-foo2000.ko and snd-foo2001.ko, by compiling with either FOO2000 or FOO2001 defined. I can do this, and ALSA does this a few times, by providing dummy foo2000.c and foo2001.c files, like: === foo2000.c #define FOO2000 #include "foo.c" === and a regular Makefile === foo2000-objs := foo2000.o foo2001-objs := foo2001.o obj-$(CONFIG_SND_FOO2000) += snd-foo2000.o obj-$(CONFIG_SND_F002001) += ...

Mmm. If I'll have to live with it, I can, but thought I'd ask if there was some nice build trickery available instead. Rene. -

This patch allows a configuration of the basic reclaim unit for reclaim in vmscan.c. As memory sizes increase so will the frequency of running reclaim. Configuring the reclaim unit higher will reduce the number of times reclaim has to be entered and reduce the number of times that the zone locks have to be taken. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- include/linux/mmzone.h | 1 + kernel/sysctl.c | 8 ++++++++ mm/vmscan.c | 41 ++++++++++++++...

NUMA support in the slab allocators may create unnecessary overhead for small NUMA configurations (especially those that realize multiple nodes on a motherboard like Opterons). If NUMA support is disabled on a NUMA machines then the NUMA locality controls will not work for slab allocations anymore. However, the resulting memory imbalances and non optimal placements may not matter much if the system is small. Is this worth doing? Signed-off-by: Christoph Lameter <clameter@sgi.com> Inde...

Hey, I wouldn't normally post news stories...but in case anyone is living under a rock, not reading Slashdot, LWN, or one of a bazillion other news sites that are *bound* to cover this at some point about now... http://www.groklaw.net/article.php?story=20070914152904577 Have an awesome weekend, everyone! :-) Jon. -

Fix following section mismatch warning: WARNING: vmlinux.o(.text+0xc88c): Section mismatch: reference to .init.text:trap_init_f00f_bug (between 'init_intel' and 'cpuid4_cache_lookup') init_intel are __cpuint where trap_init_f00f_bug is __init. Fixed by declaring trap_init_f00f_bug __cpuinit. Moved the defintion of trap_init_f00f_bug to the sole user in init.c so the ugly prototype in intel.c could get killed. Frank van Maarseveen <frankvm@frankvm.com> supplied the .config used to reproduc...

On Fri, 14 Sep 2007 15:01:09 -0500 Is rxhdr->mac_status properly declared as le32? -

This patch refactors the current hypercall infrastructure to better support live migration and SMP. It eliminates the hypercall page by trapping the UD exception that would occur if you used the wrong hypercall instruction for the underlying architecture and replacing it with the right one lazily. It also introduces the infrastructure to probe for hypercall available via CPUID leaves 0x40000002. CPUID leaf 0x40000003 should be filled out by userspace. A fall-out of this patch is that the unhand...

That's a pain for inline hypercalls tho. I was planning on moving lguest to this model (which is interesting, because AFAICT this insn will cause a #UD or #GP depending on whether VT is supported on this box so I have to look for both). Cheers, Rusty. -

I see. So you take the fault, disassemble the instruction, see that its another CPU's vmcall instruction, and then replace it with the current No, the point is that you're supposed to work out which hypervisor it is from the signature in leaf 0, and then the hypervisor can put anything it wants in the other leaves. J -

Hm. Obviously you can just define a signature for "kvm-compatible hypercall interface" and make it common that way, but it gets tricky if the hypervisor supports multiple hypercall interfaces, including the kvm one. Start the kvm leaves at 0x40001000 or something? J -

To me this is the beginning of fragmentation. Why do we need different and VMM-specific Linux paravirtualization for hardware-assisted Jun --- Intel Open Source Technology Center -

Today, 3 CPUID leaves starting from 0x4000_0000 are defined in a generic fashion (hypervisor detection, version, and hypercall page), and those are the ones used by Xen today. We should extend those leaves (e.g. starting from 0x4000_0003) for the vmm-independent features as well. If Xen needs additional Xen-specific features, we need to allocate some leaves for those (e.g. 0x4000_1000) Jun --- Intel Open Source Technology Center -

The hypervisor detection machanism is generic, and the signature returned is implentation specific. Having a list of all hypervisor signatures sounds fine to me as we are detecting vendor-specific Jun --- Intel Open Source Technology Center -

We're addressing that by blowing away the shadow cache and holding the big kvm lock to ensure SMP safety. Not a great thing to do from a performance perspective but the whole point of patching is that the cost So then each module creates a hypercall page using this magic MSR and the hypervisor has to keep track of it so that it can appropriately change the page on migration. The page can only contain a single instruction or else it cannot be easily changed (or you have to be able to prev...

Hi. I'm pleased to announce fourth release of the distributed storage subsystem, which allows to form a storage on top of remote and local nodes, which in turn can be exported to another storage as a node to form tree-like storages. This release includes new configuration interface (kernel connector over netlink socket) and number of fixes of various bugs found during move to it (in error path). Further TODO list includes: * implement optional saving of mirroring/linear information on the re...

This distributed storage is very much needed; even if it were to act as a more capable/performant replacement for NBD (or MD+NBD) in the near term. Many high availability applications don't _need_ all the additional complexity of a full distributed filesystem. So given that, its discouraging to see you trying to gently push Evgeniy away from all the promising work he has published. Evgeniy, please continue your current work. Mike -

Don't bother supporting attributes, file modes, and other details not supported by POSIX. The prime example being NFSv4, which is larded down with Windows features. NFSv4.1 adds to the fun, by throwing interoperability completely out the window. Jeff -

I'm not worried; I'm stating facts as they exist today (draft 13): NFS v4.1 does something completely without precedent in the history of NFS: the specification is defined such that interoperability is -impossible- to guarantee. pNFS permits private and unspecified layout types. This means it is impossible to guarantee that one NFSv4.1 implementation will be able to talk another NFSv4.1 implementation. Even if Linux supports the entire NFSv4.1 RFC (as it stands in draft 13 anyway), ...

This http://lkml.org/lkml/2007/8/12/159 may provide a fast-path to reaching that goal. Thanks! -- Al -

After additional testing I found a place where I forgot to add 'const', and build throws warnings at me. Updated patch is attached. Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com> -- vda

It is defined in .h file and used in .c file. It is made so because defining static data variables in .h file is a bad style in general and in this case will result in build-time warnings in particular. Therefore definition of hda_preset_tables[] is moved to .c file. It looks like this: static const struct hda_codec_preset *const hda_preset_tables[] = { snd_hda_preset_realtek, snd_hda_preset_cmedia, snd_hda_preset_analog, snd_hda_preset_sigmatel, snd_h...