This patch fixes the following build error: <-- snip --> ... MODPOST 1327 modules ERROR: "strnlen_user" [drivers/input/misc/uinput.ko] undefined! ... make[2]: *** [__modpost] Error 1 <-- snip --> Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 0318ae73cb3e61e5c192d62c22d988424e04f354 diff --git a/arch/avr32/kernel/avr32_ksyms.c b/arch/avr32/kernel/avr32_ksyms.c index 3a090ba..84a7d44 100644 --- ...

From: Vegard Nossum <vegard.nossum@gmail.com> Date: Wed, 21 May 2008 22:58:37 +0200 Subject: [PATCH] kmemcheck: use tasklets instead of timers Instead of triggering a timer every HZ, we use the new tasklet function which guarantuees not to touch any other tasklets on the tasklet list, and is thus safe to use from the page fault handler. Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> --- arch/x86/kernel/kmemcheck.c | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 ...

Suggestion for sound/drivers: drivers/sound/generic :-) Rene. --

Something like: include/asm-$ARCH/ => arch/$ARCH/include/asm/* ? I can cook up something simple so kbuild will try both so we can move the archs that do symlinks later than the rest. I really like to keep the 'asm' directory so we can kill the asm symlink. Sam --

We could git mv include/asm-xyz arch/xyz/asm and then arrange to pass -Iarch/$(ARCH) to gcc. The only downside is that "asm" is a slightly strange name for a directory of include files, but I assume we don't want to have to change all the #include <asm/blah.h> lines in all the *.c files. Paul. --

That would work, but there's a few alternatives that I think would work even better. The downside with what you suggest is that I'd like the arch-specific include files to be clearly separated (ie I think the naming should be "something/include/something", which makes things clearer. Also, I hate how doing '-Iarch/$(ARCH)' would basically make any random arch/xyz/ subdirectory be a potential location for a header file. I'd hate for the include-path to contain subdirectories that ...

Well, not _huge_ but ALSA is very much structured like that; large middle layer with "miniport" drivers (I do by the way expect this was also Takashi plan originally due to him using sound/* and not just "sound/"; that is, I took the * to be shorthand for isa, pci, usb and so on) From a structural view, the PCM core is just as much not a driver as the IP protocol isn't one and moving all of sound/ to drivers/ would trade the current "why are the drivers not under drivers/?" issue for a ...

While we are at the issue ALSA HG <-> GIT transition... One thing that annoys me sometimes is that the sound driver codes are on a different subdirectory than other normal drivers, namely under /sound. I don't remember exactly why it came there, but this often makes people forget to change the necessary code for the sound subsystem, or slip from the statistics (I'm not sure whether Linus counted sound/* with recent his posts). If I understand correctly, with git, we can move the files ...

Some systems incorrectly report the ExtINTA pin of the I/O APIC as the genuine target of the timer interrupt. Here is a change that copies timer pin information found to the other pin if one has been found only. This way both a direct and a through-8259A route is tested with the pin letting these problematic systems work well enough. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-pins-0 diff -up --recursive --new-file ...

If configured to use the I/O APIC, the NMI watchdog is deemed to fail if the chip has been deactivated as a result of "nosmp". Downgrade to the local APIC watchdog similarly to what is done for the UP case. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-nosmp-watchdog-0 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/smpboot.c linux-2.6.26-rc1-20080505/arch/x86/kernel/smpboot.c --- ...

Disable the 8259A acting in the "virtual wire" mode to keep the interrupt line inactive while fiddling with local APIC interrupt vector registers associated with its destination inputs. To be on the safe side, especially concerning flipping the trigger mode. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-8259-nmi-unmask-0 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c ...

Remove the "disable_8254_timer" and "enable_8254_timer" kernel parameters. Now that AEOI acknowledgements are no longer needed for correct timer operation, the 8259A can be kept disabled unconditionally unless interrupts, either timer or watchdog ones, are actually passed through it. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-8254-2 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/early-quirks.c ...

Hello, This is a set of patches replacing patch-2.6.26-rc1-20080505-timer_ack-1 and patch-2.6.26-rc1-20080505-timer-8259-0 sent previously. The patches have been split up into smaller logically self-contained chunks to make tracking down problems easier. The patch-2.6.26-rc1-20080505-nosmp-watchdog-0 change fixes a problem with timer interrupts getting masked in the 8259A as a result of patch-2.6.26-rc1-20080505-timer-8259-6 in the corner-case scenario of "nmi_watchdog=1 nosmp" being ...

please drop this patch... YH --

Thanks for the quick response. I definitely confirmed that "x86: extend e820 ealy_res support 32bit" is the source of the regression, and reverting the change makes the system bootable under Xen. (My previous reversion failed because I didn't actually have the x86.git changes applied :-/) This patch generates the warning: CC arch/x86/kernel/setup_32.o /home/jeremy/hg/xen/paravirt/linux/arch/x86/kernel/setup_32.c: In function ‘setup_arch’: ...

Hi, Besides, what did you want to accomplish? Hannes --

Seems that the addition of RT_RW_READER broke the non PREEMPT_RT case. This patch fixes it. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- kernel/rtmutex.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) Index: linux-2.6.24.7-rt9/kernel/rtmutex.c =================================================================== --- linux-2.6.24.7-rt9.orig/kernel/rtmutex.c 2008-05-20 23:38:08.000000000 -0400 +++ linux-2.6.24.7-rt9/kernel/rtmutex.c 2008-05-21 ...

Sorry, it's trivial@kernel.org. --

I agree, keep things seperate. One mail with patch to fix casts, Thank you, I'll keep an eye on this patch. Philipp: Johannes makes some good points, please address his comments and re-submit the patch with trivial@kernel.org on Cc: if it draws no negative comments it looks good to me to add to the trivial tree. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --

These magic greps and hacks in ver_linux to get the gcc version always break after some gcc releases. Since now gcc >4.3 allows compiling with '--with-pkgversion' ( which can be everything 'My Cool Gcc' or something ) ver_linux will report random junk for these. Simply use 'gcc -dumpversion' to get the gcc version which should always work. Signed-off-by: Gabriel C <nix.or.die@googlemail.com> --- Andrew sorry to bug you about that but I have no clue how is maintaining scripts/* ...

I also would prefer to keep this out of SLUB. Set/Clear PageSlab dirties the cacheline and it forces the unlining of kmalloc_large. --

From: Pekka Enberg <penberg@cs.helsinki.fi> This patch re-uses the PG_slab flag for marking SLOB bigblock pages so we can check that the pointer passed ksize() was really allocated by SLOB. Cc: Christoph Lameter <clameter@sgi.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Paul Mundt <lethal@linux-sh.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- mm/slob.c | 34 ++++++++++++++++++++++++++++++---- 1 files changed, 30 insertions(+), 4 ...

But kobjsize() never calls ksize() with SLOB as it doesn't set PageSlab. Or are you talking about something else here? Fair enough. I'll drop the patch. --

Why is it too big? Without your additions it is converting kmallocs inline to get_free_pages(). That results in a simple function call with two constant parameters. The patch touches the page struct uselessly. I think the PageSlab marking is useful for debugging but not for a production kernel. --

If it has to be then add CONFIG_KSIZE_DEBUG. There are a number of debugging techniques (kmem_check?) that should not be compiled in. Maybe add a new config option for those. CONFIG_SLUB_ENABLE_EXPENSIVE_DEBUG? --

The ->virtual case is a very special case. page_address() currently should reduce to a simple shift and an add with VMEMMAP. --

This series seems to work ok with all of SLAB/SLUB/SLOB when also applying the kobjsize() patch. Without the kobjsize() patch in place, SLAB and SLUB both work, while SLOB still triggers the >= MAX_ORDER BUG_ON() for page cache pages. Note that this is still an improvement over SLUB blowing up, as it was before, even without the kobjsize() change. --

Hi, I guess such a quirk may be a little odd, but it has been a blocking point in my system not being able to support more than one printer. Please comment. (and cc. me)

From: Randy Dunlap <randy.dunlap@oracle.com> menuconfig in Sound PCMCIA drivers needs to be tristate so that SND_PCMCIA can have a value of m so that following drivers can be restricted to m when needed. sound/built-in.o: In function `vxpocket_detach': vxpocket.c:(.text+0x20cfa): undefined reference to `pcmcia_disable_device' sound/built-in.o: In function `vxpocket_probe': vxpocket.c:(.text+0x20f46): undefined reference to `pcmcia_request_io' vxpocket.c:(.text+0x20f5a): undefined reference ...

At Wed, 21 May 2008 11:37:21 -0700, Thanks, applied to my tree now. --

This patch fixes the following compile error: <-- snip --> ... CC fs/binfmt_flat.o In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:36: /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/flat.h:14:22: error: asm/flat.h: No such file or directory /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c: In function 'create_flat_tables': /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/binfmt_flat.c:124: error: implicit declaration of function ...

EXPORT_SYMBOL() as elsewhere please. I can't test it till I get home next week. David --

Okay, everywhere barring ia64 then. David --

Last time this came up, I think the consensus was that those architectures should be providing a stub free_dma(). -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --

I tried building as many modules as possible on frv, and this was the only driver that failed this way. Another possibility would be to let this driver depend on ISA_DMA_API (similar to e.g. SCSI_EATA). Sorry for being lazy, but touching X architectures for fixing the compiliation of a driver whose hardware will anyway most likely never be used on this architecture is IMHO not worth the effort... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out ...

The driver is gone for a long time. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 5aead6331a39f4e2e2ee31f9ea1ff092843a3f99 diff --git a/sound/oss/Makefile b/sound/oss/Makefile index 1f86299..d0440be 100644 --- a/sound/oss/Makefile +++ b/sound/oss/Makefile @@ -32,8 +32,6 @@ obj-$(CONFIG_SOUND_AU1550_AC97) += au1550_ac97.o ac97_codec.o obj-$(CONFIG_SOUND_TRIDENT) += trident.o ac97_codec.o obj-$(CONFIG_SOUND_BCM_CS4297A) += ...

This patch corrects the names of two CONFIG_ variables. Note that the CONFIG_MPC86XADS fix uncovers another bug (with mpc866_ads_defconfig) that will require fixing: <-- snip --> ... arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/mpc866ads.dtb -b 0 /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts DTC: dts->dtb on file "/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts" WRAP ...

Yes is fixes this error , however I get now another one but this one seems to be an compiler bug. ... CC arch/um/sys-x86_64/um_module.o LD arch/um/sys-x86_64/subarch.o LD arch/um/sys-x86_64/built-in.o LD arch/x86/crypto/built-in.o CC kernel/sched.o In file included from kernel/sched.c:1842: kernel/sched_idletask.c: In function 'check_preempt_curr_idle': kernel/sched_idletask.c:20: internal compiler error: in cgraph_estimate_size_after_inlining, at ...

Hi, What does: lsmod | grep ricoh, give you? Anything? -- Tom Spink --

Installing NULL encryption IPSec SAs works using the .compat name "cipher_null", but fails with the .name "ecp(cipher_null)" due the missing check in key length verification.  Signed-off-by: Martin Willi <martin@strongswan.org> --- a/net/xfrm/xfrm_user.c 2008-05-21 11:34:56.000000000 -0500 +++ b/net/xfrm/xfrm_user.c 2008-05-21 11:20:08.000000000 -0500 @@ -57,6 +57,7 @@ case XFRMA_ALG_CRYPT: if (!algp->alg_key_len && + strcmp(algp->alg_name, ...

I think we should get rid of the zero check altogether as a zero-length key will fail on setkey of a real algorithm anyway because of the min_keysize/max_keysize checks in the crypto API. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

From: Miklos Szeredi <mszeredi@suse.cz> Push nameidata further up the call chain, completely removing it from the permission API. Switch calls of vfs_permission() to path_permission(). Instead of nameidata, pass the path and nameidata->flags to this function. This is a trivially equivalent transformation. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> --- fs/exec.c | 4 ++-- fs/inotify_user.c | 2 +- fs/namei.c | 23 ++++++++++++----------- fs/open.c ...

From: Miklos Szeredi <mszeredi@suse.cz> Only pass nameidata->flags instead of the nameidata to security_inode_permission(), synchronizing it with i_op->permission(). Currently no security module uses the nameidata parameter. The other change in ->permission() is that a dentry is passed instead of an inode. Leave this till AppArmor integration, since that will need a struct path instead of an inode. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> CC: James Morris ...

From: Miklos Szeredi <mszeredi@suse.cz> Switch last argument of dentry_permission() from nameidata to flags. This requires the MNT_NOEXEC checking to be moved from dentry_permission() to vfs_permission(). The following dentry_permission() callers passed a non-NULL nameidata: vfs_permission() This remained almost equivalent, except that ordering of the MNT_NOEXEC check and the IS_RDONLY/IS_IMMUTABLE checks has been changed. However the IS_RDONLY check should never trigger, ...

No, we don't want to deny read or write (that's up to the filesystem how it handles it), just want to deny execute if no x bits are set in the mode. I didn't really pay attention to individual filesystems, including NFS, just mechanically moved the check from permission() to ->permission(). So it's possible that the code could be further optimized in some cases. Miklos --

From: Miklos Szeredi <mszeredi@suse.cz> For execute permission on a regular files we need to check if file has any execute bits at all, regardless of capabilites. This check is normally performed by generic_permission() but was also added to the case when the filesystem defines its own ->permission() method. In the latter case the filesystem should be responsible for performing this check. So create a helper function exec_permission() that checks returns -EACCESS if MAY_EXEC is present, ...

From: Miklos Szeredi <mszeredi@suse.cz> Signature of i_op->permission() is changed from int (*permission) (struct inode *inode, int mask, struct nameidata *nd); to int (*permission) (struct dentry *dentry, int mask, int flags); Lots of filesystems need to be updated, but the only ones actually making use of the dentry (instead of the inode) or flags are: - ecryptfs: uses both dentry and flags - fuse: checks LOOKUP_ACCESS and LOOKUP_CHDIR in flags - nfs: checks LOOKUP_ACCESS and ...

From: Miklos Szeredi <mszeredi@suse.cz> The following patches clean up the i_op->permission() method and the related VFS API. Here's an overview of the changes: - ->permission() is passed a dentry instead of an inode - ->permission() is passed a integer flags parameter instead of a nameidata pointer - all nameidata pointer passing is removed from the permission API - the check for execute bit on regular files is moved into ->permission() - the permission() and vfs_permission() ...

Hi, No, it's not, it allows for HFS+ specific special case to allow the lookup of the resource fork. bye, Roman --

From: Miklos Szeredi <mszeredi@suse.cz> GFS2 calls permission() to verify permissions after locks on the files have been taken. For this it's sufficient to call gfs2_permission() instead. This results in the following changes: - IS_RDONLY() check is not performed - IS_IMMUTABLE() check is not performed - devcgroup_inode_permission() is not called - security_inode_permission() is not called IS_RDONLY() should be unnecessary anyway, as the per-mount read-only flag should provide ...

From: Miklos Szeredi <mszeredi@suse.cz> Introduce path_listxattr(). Make vfs_listxattr() static. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> --- fs/xattr.c | 15 ++++++++------- include/linux/xattr.h | 2 +- 2 files changed, 9 insertions(+), 8 deletions(-) Index: linux-2.6/fs/xattr.c =================================================================== --- linux-2.6.orig/fs/xattr.c 2008-05-21 13:30:33.000000000 +0200 +++ linux-2.6/fs/xattr.c 2008-05-21 ...

Highlights are: - remove nameidata from the i_op->permission() method - remove nameidata passing and consolidate permission()/ vfs_permission()/file_permission() API It's all fairly trivial stuff, but I will do some LTP testing on it. This series is based on the vfs-cleanups(*) tree. If no problems are found, I'll commit the patches to that tree. Thanks, Miklos (*) git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git vfs-cleanups -- --

[Empty message]

Given that I want to change every use of CONFIG_IMMEDIATE into USE_IMMEDIATE, both in architecture specific and independant C files and also in arch spec. and indep. Makefiles, I will have to define USE_IMMEDIATE on other arch too. Here is the updated patch. It applies on top of the sched-devel.git tree. Fix Immediate Values x86_64 support old gcc GCC < 4, on x86_64, does not accept symbol+offset operands for "i" constraints asm statements. Fallback on generic immediate values if this ...

tabs has a special sematic purpose in makefiles so do not tabs -> spaces again. Other than that I like this patch much better. Thanks, Sam --

Same with USE_IMMEDIATE - as USE_IMMEDIATE is only used in a x86 Makefile. Or did I miss sothing? Sam --

Initialize I2C pins on boards with CPM1/CPM2 controllers. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- Documentation/powerpc/booting-without-of.txt | 42 ++++++++++++++++++++++++++ arch/powerpc/boot/dts/mpc8272ads.dts | 11 +++++++ arch/powerpc/boot/dts/mpc866ads.dts | 11 +++++++ arch/powerpc/boot/dts/mpc885ads.dts | 11 +++++++ arch/powerpc/platforms/82xx/mpc8272_ads.c | 4 ++ arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 ++ ...

This is a second attempt to merge nmi-32/64 to nmi.c Summary changes: - a few helper functions added (placed on top part of nmi.c) - nmi_watchdog_default() now handles both 32/64 modes - check_nmi_watchdog() uses for_each_online_cpu() even in 32bit mode since cpu_online_map is set up after cpu_callin_map anyway - last_irq_sums and alert_counter was defined as static arrays in 32bit mode, so they were changed to per_cpu variables - and the most notable change is that I've changed ...

[Hiroshi Shimamoto - Wed, May 21, 2008 at 11:20:17AM -0700] | Cyrill Gorcunov wrote: | > This is a second attempt to merge nmi-32/64 to nmi.c | | Hi Cyrill, | | cool work! | | > Summary changes: | > | ... | > - last_irq_sums and alert_counter was defined as static arrays in 32bit | > mode, so they were changed to per_cpu variables | | This was already done, see http://lkml.org/lkml/2008/5/2/525. | But it doesn't affect the unified file. | | > +#ifdef CONFIG_X86_64 | > +static ...

This is a request for comments for a redesign of the integrity patches. The new version addresses a number of issues, including - generalizing the measurement API beyond just inode measurements. - separation of the measurement into distinct collection, appraisal, and commitment phases, for greater flexibility. - redesigning the interactions with LSM modules (Selinux and Smack) to be acceptable to those groups. Extended Verification Module(EVM) and the Integrity ...

This is a request for comments for a redesign of the integrity patches. This patchset contains 4 patches. Patch 1/4 integrity: TPM internal kernel interface Patch 2/4 integrity: special fs magic Patch 3/4 integrity: Linux Integrity Module(LIM) Patch 4/4 integrity: IMA as an integrity service provider Resubmitting integrity-tpm-internal-kernel-interface.patch, which was previously Signed-off-by Kylene Hall. Adds the following support: - internal kernel interface to transmit TPM ...

Assuming (as it appears) the only change from last time is that you dropped the part changing cap_bprm_apply_creds() contraints for a ptraced process, then Acked-by: Serge Hallyn <serue@us.ibm.com> I'll try to give it a good test-run next week. thanks, --

From: Cedric Le Goater <clg@fr.ibm.com> This is a slight change in the namespace cgroup subsystem api. Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> --- kernel/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: 2.6.26-rc2-mm1/kernel/cgroup.c =================================================================== --- 2.6.26-rc2-mm1.orig/kernel/cgroup.c +++ 2.6.26-rc2-mm1/kernel/cgroup.c @@ -2903,7 +2903,7 @@ int cgroup_clone(struct task_struct *tsk cg = ...

This is the fifth version of the address space control patches. These patches are against 2.6.26-rc2-mm1 and have been tested using KVM in SMP mode, both on a powerpc box The goal of this patch is to implement a virtual address space controller using cgroups. The documentation describes the controller, it's goal and usage in further details. Reviews, Comments? Changelog Patches [1/4] and [2/4] are unchanged Patch [3/4] and [4/4] now formally use mmap_sem to protect mm->owner ...

This patch sets up the rlimit cgroup controller. It adds the basic create, destroy and populate functionality. The user interface provided is very similar to the memory resource controller. The rlimit controller can be enhanced easily in the future to control mlocked pages. Changelog v3->v4 1. Use PAGE_ALIGN() 2. Rename rlimit to memrlimit Acked-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> --- include/linux/cgroup_subsys.h | 4 ...

This patch adds support for accounting and control of virtual address space limits. The accounting is done via the rlimit_cgroup_(un)charge_as functions. The core of the accounting takes place during fork time in copy_process(), may_expand_vm(), remove_vma_list() and exit_mmap(). Changelog v5->v4 Move specific hooks in code to insert_vm_struct Use mmap_sem to protect mm->owner from changing and mm->owner from changing cgroups. Signed-off-by: Balbir Singh ...

I do not approve: - the patch does not follow the comment style of the driver - the comment should be removed, not silly augmented -- Ueimor --

On linux-next from today , allmodconfig, I see the following warnings on 64bit: ... CC [M] drivers/infiniband/hw/ipath/ipath_sdma.o drivers/infiniband/hw/ipath/ipath_sdma.c: In function 'sdma_abort_task': drivers/infiniband/hw/ipath/ipath_sdma.c:267: warning: passing argument 2 of 'constant_test_bit' from incompatible pointer type drivers/infiniband/hw/ipath/ipath_sdma.c:267: warning: passing argument 2 of 'variable_test_bit' from incompatible pointer ...

Hi! I was going to ask a few questions to Greg KH when he told me=20 =2D-=20 Thomas Nemeth - Ing=E9nieur d'=C9tudes en Informatique Industrielle =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Industrial Computing Software Designer BETAtech - 15, rue Apollo, Z.A. de Montredon, 31240, L'Union. 05 34 30 40 00 (standard) =A0/ =A005 34 30 40 09 (ligne directe)

You keep saying that but it simply is not true. The more people we have _waiting_ for a "stable" kernel to graduate from the "testing" series, the less people we have actually _testing_ the kernel. So it's probable that your suggestion actually makes the current situation worse, not better. --

On Wed, 21 May 2008 16:08:37 +0300 what would you want to accomplish with your idea? --

Hi, After long discussions about kernel release methodology, an idea has came to ( Any comments welcomed :-) ) my mind : - 2 weeks of merge window for each "rc" releases should remain the same . - When decided the 2.6.xx-rcx is ready to become 2.6.xx, it should be 2.6.xx-test1 instead of 2.6.xx - Chris Wright (or whoever will handle these "testX" maintaining) can maintain these "testX" releases as like 2.6.x.y maintaining. - After releasing the "testX" releases, the new kernel release ...

I think you're missing Arjan and Pekka's point: your proposal doesn't _really_ offer any change to the current procedure. It might make you feel more warm and fuzzy but in practice: 1) Linus would still release a kernel (be it to -testX or "final") when he and others feel it is time 2) The stable team will track fixes and release stable kernels as needed The only thing that is different in your approach is the "final" release would theoretically be more well tested. Unfortunately that is ...

Please see my reply to Arjan's post. --

Yes, that's what I'm talking about. The change will be the "testX" Of course as didn't embrace like the "rc" releases. I don't think that it will cause early stable fixes. Contrarily, it will produce more It is. As I described above : the "testX" series will change the things as producing more tested /stable releases. BTW, it should be much better to release less, trouble free kernels instead of releasing fast but fixing soon. Also, it will take the load of deep kernel testing. Linus ...

now: linux-2.6.x -> linux-2.6.(x+1)-rcY -> linux-2.6.(x+1) \->2.6.x.y \->2.6.(x+1).y \->2.6.x.(y+1)-rc1->2.6.x.(.y+1) \->2.6.x.(y+1)-rc1->2.6.x.(.y+1) your idea: linux-2.6.x -> linux-2.6.(x+1)-rcY -> linux-2.6.(x+1) \->2.6.x.y \->2.6.(x+1).y \->2.6.x.(y+1)-test1->2.6.x.(.y+1) \->2.6.x.(y+1)-test1->2.6.(x+1).(.y+1) only the namig is was other, rc -> test, -- Thanks, Oliver --

PS: And does the parity error happen with the ohci1394 driver too? -- Stefan Richter -=====-==--- -=-= =-==- http://arcgraph.de/sr/ --

From JiSheng Zhang <jszhang3@mail.ustc.edu.cn> Some broken pci-1394 card does not clear completely on-chip memory during boot, it may cause pci parity error, then NMI interrupt. It will emit kernel message such as"Uhhuh. NMI received for unknown reason b1 on CPU 0. You have some hardware problem, likely on the PCI bus. Dazed and confused, but trying to continue" etc. If panic_on_unrecovered_nmi is set to 1, the system will panic. This patch will fix it --- ...

At Wed, 21 May 2008 16:40:37 +0200, I thought linux-next does fresh merges at each time, thus it doesn't matter whether a subsystem tree is rebased or not... Takashi --

I'm also still frequently trying to figure out an/the efficient way of using GIT but it does seem it's not just a matter of "pure downstream" (which I do believe ALSA has few enough of to not make this be a huge problem). For example linux-next is also going to want to pull in ALSA and say it does, finds a trivial conflict with the trivial tree that it also pulls in and fixes things up. If you rebase that which linux-next pulls from I believe it will have to redo the fix next time it pulls ...

No it is NOT. Why should you have stuff from outside the subsystem tree? And quite frankly, the only reason to *need* those fixes in the first place is if you merge random test-kernels during the merge window. What you should strive for is to merge at the stable point, not random kernels to keep you "up-to-date", and suddenly you don't need to make more merges just to get (possibly) new fixes. See? If it's the ALSA tree, then what is it doing pulling all the random other ...

one thing that you have missed in your explination in this thread (although you have made the point in other threads) is that subsystem maintainers have the fear that there are other changes that will interfere with their stuff and want to catch it early. per your instructions in prior threads, what they should do is to have a seperate branch on their system that they use as a throw-away branch to pull from your tree, and from their tree to spot problems. As they find problems they can ...

It's "worse" than that; rebasing is designed for a _private_ development model. git-rebase is a very handy tool for people like myself (people without a downstream that is) and it basically enables the quilt model of a stack of patches on top of git but public trees that have people pulling from them should generally not rebase or everyone who _is_ pulling finds a different tree each time. Linus is vehement about this also. There have a few threads about it and the most recent ...

At Wed, 21 May 2008 09:16:05 -0700 (PDT), Well, what I meant is about the fixes to the subsystem (say, ALSA) by people in the outside. Not every ALSA-bugfix patch goes into the upstream from ALSA tree. You, Andrew and others pick individually ALSA-fix patches. They will be missing in the ALSA subsystem tree. And, what if that you need a fix for the fix that isn't in ALSA tree...? IMO, either a rebase or a merge is better than Hmm, that makes me thinking of the development model. We can ...

Cherry-picking can certainly cause merge errors, but not generally very often. Cherry-picking by definition will obviously apply the *same* patch to two different branches, and as a result, when you merge, that merge will generally be totally clean. So a trivial merge that succeeds without you even noticing is actually the common case. But you can certainly get merge failures where you then have to fix things up if there were *other* changes to that same area. At that point, you ...

At Wed, 21 May 2008 15:04:53 +0200, Theoretically we can work only using merges. However, the resultant tree will look too complex with lots of merge points at the time of the next merge window. This is also a nightmare for bisecting. Thus, most subsystem trees do rebase before the merge window in practice, AFAIK. It'd be appreciated if someone can tell me any good workflow to keep a good-shaped tree without rebasing... Takashi --

Let's ask... Fresh merges at each release boundary certainly but if it drops/remerges each subsystem when a bug in its for-next branch is found (a supposedly non rare occurence) all the hopefully hundreds or even thousands of linux-next pullers/testers would seem to have to deal with all those completely new merges everytime as well. I'd hope linux-next during a single release would just pull in the one fix (the subsystem's for-linus branch can still fold it in). Rene. --

Hi All, This is vijay and new to this group. Normally I use to go through the Linux kernel source and try to understand how things work. Last week I was going through the cdc-acm driver source(linux-2.6.25). I think there is a bug with that driver and I am not sure about it. So I decided to post you guys and get your views on that. The interface is claimed in 'acm_probe' using 'usb_driver_claim_interface' and it has been released in 'acm_disconnect' using ...

Hello This oops was generated while I've been playing with the vgchange -ay command. The previous warning were made by suspend WARNING: at drivers/base/power/main.c:77 device_pm_add+0x96/0x120() Thus I'm only pasting the oops itself - looks quite wierd: (my setup is 64bit T61 2GB - git commit: 8033c6e9736c29cce5f0d0abbca9a44dffb20c39 ) BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 IP: [__pollwait+78/272] __pollwait+0x4e/0x110 PGD 55634067 PUD 5c37e067 ...

Which non-irq context is that? Regards Oliver --

You're right, this callchain can't cause the deadlock indeed. I'll go through the other possibilities. To give some background to others reading this thread -- Leonardo (in CC) reported [1] that this patch fixes hard kernel hangs he has been seeing when using USB CDMA modem. Still, we don't currently seem to see the place where the interrupts get enabled that makes the deadlock to trigger. [1] https://bugzilla.novell.com/show_bug.cgi?id=378509 -- Jiri Kosina SUSE Labs --

I can't see how urbs can be submitted to whci-hcd from an interrupt handler (urb callbacks are always called from a workqueue thread) but they could be submitted from a timer, so you are correct. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ --

One example -- assume usb_submit_urb() called from non-IRQ context. Then usb_hcd_submit_urb() -> rh_urb_enqueue() -> rh_queue_status() -> usb_hcd_link_urb_to_ep(). -- Jiri Kosina SUSE Labs --

_Your_ callbacks are always called from a workqueue thread. Another driver's callbacks might not be, and that other driver might submit an Alan Stern --

The functions you are worried about (usb_hcd_link_urb_to_ep and usb_hcd_unlink_urb_from_ep) are documented as requiring that interrupts be disabled by their callers. This patch isn't needed. (Of course, other patches may be needed to insure that the callers do It's not obvious to me. Where does usb_hcd_flush_endpoint() acquire The problem in the Novell bugzilla entry was caused by the fact that the OHCI irq routine was invoked with interrupts enabled, owing to a missing ...

Sorry, yes other code paths take it with enabled interrupts. The patch is good and necessary for 2.6.26. Regards Oliver --

That doesn't sound like a valid approach. If you don't disable interrupts then you aren't protected against an interrupt handler submitting an URB and accessing your data structures while whci-hcd is in the middle of updating them. Alan Stern --

Alan, I am trying your suggestion right now. Lets see if it finds something. Thanks, Leonardo --

Could you please open bug report at bugzilla.kernel.org under ACPI/Battery and attach all the information to it? dmesg might be helpful too. Thanks, Alex. --

I've recently switched some of my boxes from a 32 to a 64 bit kernel. These are usenet server boxes that do a lot of I/O. They are running 2.6.24 / 2.6.25 Every 15 minutes a cronjob calls a management utility, tw_cli, to read the raid status of the 3ware disk arrays. That often fails with a segmentation violation .. tw_cli: page allocation failure. order:0, mode:0x10d0 Pid: 9296, comm: tw_cli Not tainted 2.6.25.4 #2 Call Trace: [<ffffffff802604b6>] __alloc_pages+0x336/0x390 ...

Yes you are. -- Jean Delvare --

The bay driver still provides the only mechanism for calling the eject methods. -- Matthew Garrett | mjg59@srcf.ucam.org --

If acpi_install_notify_handler() for a bay device fails, the bay driver is superfluous. Most likely, another driver (like libata) is already caring about this device anyway. Furthermore, register_hotplug_dock_device(acpi_handle) from the dock driver must not be called twice with the same handler. This would result in an endless loop consuming 100% of CPU. So clean up and exit. Signed-off-by: Holger Macht <hmacht@suse.de> --- diff --git a/drivers/acpi/bay.c b/drivers/acpi/bay.c index ...

There are still a bunch of i2c drivers using the old API (mainly v4l and dvb stuff) Sure. That's why the parameters are only optional. Once all i2c drivers are converted, these parameters won't be used anymore. Maybe they should be marked I was just confused by the fact that unlike a serial port, i2c is a bus itself. Thanks, Jochen --

The comment assumed ratelimit_burst to be one and used an old name for ratelimit_jiffies. I also reintended the comment. Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> --- kernel/printk.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/kernel/printk.c b/kernel/printk.c index 8fb01c3..f1c3c1c 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -1323,9 +1323,8 @@ void tty_write_message(struct tty_struct *tty, char *msg) /* * printk rate ...

When we test kernel by the latest LTP(20080430) on ia64, the following failure occured: ------------------------------------- prctl01 1 PASS : Test Passed prctl01 0 WARN : prctl() returned 2048 errno = 0 : Success prctl01 1 PASS : Test Passed prctl01 2 FAIL : Test Failed ------------------------------------- We found commit 3898b1b4ebff8dcfbcf1807e0661585e06c9a91c causes this failure by git-bisect. And, we found *rc_p has not been initialized if switch-default ...

From: Kong Wei <weikong@redflag-linux.com> Unlimited of min_free_kbytes is dangerous, An user of our company set this value bigger than 3584*1024*K, cause the system OOM on DMA. And I try a even more bigger number will cause the system hang immediately. Limited as 64M may not a good value, but as default in init_per_zone_pages_min. And this option may not need again? Signed-off-by: Kong Wei <weikong@redflag-linux.com> --- kernel/sysctl.c | 5 ++++- mm/page_alloc.c | 2 +- 2 files ...

Thanks Markus, This looks good. I'll stick it into my queue and feed it via Ingo when I've given it a bit of a test. Are we happy that the preferred console stuff is now the best solution? Does it solve your installer issues? J --

This isn't a security flaw (the backend can see all our memory anyway). But it's the right thing to do all the same. Signed-off-by: Markus Armbruster <armbru@redhat.com> --- drivers/video/xen-fbfront.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c index 5553e51..291eef6 100644 --- a/drivers/video/xen-fbfront.c +++ b/drivers/video/xen-fbfront.c @@ -61,6 +61,7 @@ static void xenfb_do_update(struct ...

Add z-axis motion to pointer events. Backward compatible, because there's space for the z-axis in union xenkbd_in_event, and old backends zero it. Derived from http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/57dfe0098000 http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/1edfea26a2a9 http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/c3ff0b26f664 Signed-off-by: Pat Campbell <plc@novell.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> --- drivers/input/xen-kbdfront.c ...

Signed-off-by: Karel Zak <kzak@redhat.com> --- MAINTAINERS | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b42dcfc..8779b53 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4361,6 +4361,14 @@ M: gregkh@suse.de L: linux-kernel@vger.kernel.org S: Maintained +UTIL-LINUX-NG PACKAGE +P: Karel ...

Hi. When we read some part of a file through pagecache, if there is a pagecache of corresponding index but this page is not uptodate, read IO is issued and this page will be uptodate. I think this is good for pagesize == blocksize environment but there is room for improvement on pagesize != blocksize environment. Because in this case a page can have multiple buffers and even if a page is not uptodate, some buffers can be uptodate. So I suggest that when all buffers which correspond to a ...

so we can printout pci config before kernel touch it also fix write_pci_config_byte with offset and add write_pci_config_16 Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Index: linux-2.6/arch/x86/kernel/setup_64.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/setup_64.c +++ linux-2.6/arch/x86/kernel/setup_64.c @@ -350,6 +350,11 @@ void __init setup_arch(char **cmdline_p) parse_early_param(); +#ifdef CONFIG_PCI + if ...

Currently list of kretprobe instances are stored in kretprobe object (as used_instances,free_instances) and in kretprobe hash table. We have one global kretprobe lock to serialise the access to these lists. This causes only one kretprobe handler to execute at a time. Hence affects system performance, particularly on SMP systems and when return probe is set on lot of functions (like on all systemcalls). Solution proposed here gives fine-grain locks that performs better on SMP system ...

Signed-off-by: Li Yang <leoli@freescale.com> Cc: Zhang Wei <zw@zh-kernel.org> --- drivers/dma/fsldma.c | 31 ++++++++++++++++--------------- 1 files changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 054eabf..724f6fd 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -809,8 +809,7 @@ static int fsl_dma_self_test(struct fsl_dma_chan *fsl_chan) if (!src) { dev_err(fsl_chan->dev, "selftest: Cannot alloc memory ...

It is deeply annoying, even embarrassing, and trivial to fix. And as you say, process is glacial... Cheers, Rusty. --

I must be missing something critical, but what's the logjam this is causing? Daniel --

No it doesn't. If anything, a "true" return from something called Shouldn't be necessary to look it up. By that argument we could Well, we can walk and chew gum at the same time. The number of down_trylocks in rc3 is 51 and the number of down_trylocks and down_nowaits in -mm is 47. So progress is pretty glacial. <wonders why -mm still has seven down_trlyocks> <oh> ./kernel/semaphore.c ./kernel/mutex.c ./include/linux/semaphore.h Anyway, yes, I agree that the whole effort is ...

>> net/netfilter/nf_conntrack_helper.c: In function

Hi Kamalesh, On Wed, 21 May 2008 17:02:30 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ib= Thanks for the report and patch. This looks like it is probably broken in Linus' kernel. What config did you use to get the error? --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

From: Andrew Morton <akpm@linux-foundation.org> Al may not have expressed himself the most pleasant way, but I do agree on some fundamental level with him. There is way to much useless crap being discussed on this list, and this is a list where the signal level is of an utmost importance for the lists usability. After deleting all of the noise posted here, I'm often too burnt out to do real work with what's left and just delete that too. :-/ It's worse than the postmaster and list owner ...

What I'm doing right now is basically reformatting my own notes, emails I've written on the subject, pieces of other documents I've written etc etc and trying to put them in the shape of a Getting Started document. Perhaps getting that compiled into a reasonable document in a few hours is a bit too optimistic, but I'll give it a go, post what I have for review and we can take it from there. :-) I'd love to read your document once it's ready for review. -- Jesper Juhl ...

On Wed, 21 May 2008 23:08:29 +0200 Well you should. One person makes a mistake and gets horridly treated in public and this will make others fear the consequences of any mistake they might make. This could have been handled better, don't you think? --

People fix bugs when they realize that nobody else is going to do it for them. -- Stefan Richter -=====-==--- -=-= =-=-= http://arcgraph.de/sr/ --

Oh, what a marvellous way to encourage new contributors that was. Thank you so much. For the record: Al speaks only for himself and a lack of expressed disagrement from others should not be taken as agreement. Sheesh. --

I think, there is no "standard" on this. I personally do prefer indentation by tabs. --

Guys, get a clue. It doesn't matter what that person did. It is the effect upon *all* other potential developers which is so damaging here. Not upon this individual. --

We are drowning in new code, and our biggest problem is to get it properly integrated. We don't have any shortage in the sheer number of people, and it doesn't seem we'll ever have. And we have many newbies who come and find themselves areas for useful cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. ...

From: Andrew Morton <akpm@linux-foundation.org> Indeed. A lot of the time I see new people, or people making suggestions to them, so fixated on wanting to implement new features. To me that is absolutely the wrong way to go about this. It's so much more useful, for both the community and the individual, to fix bugs. Fixing a bug forces you to learn how the kernel works at least on some level, and fixing a bug always makes Linux better. Implementing a new feature does not necessarily ...

Let's look at it from another angle: We should not aim at being good at this. What do we need more in the kernel: - people testing development kernels - people fixing bugs - people maintaining code - people reviewing code What do we already have more than enough: - people developing new bugs^Wfeatures If someone wants to do a project that's OK. And if some kernel developer wants to assist him that's OK. But in my opinion stuff like "I need a project for university" requests are ...

So do I, but that pales compared to how annoying I find patches that can best be described as anal-retentive. Let the person who writes the code decide how to lay it out. --

[Empty message]

I myself tend be rather apprehensive about making an ass of myself in public as well but the only thing I'm taking away from this particular thread is that not everyone is going to appreciate argument alignment patches. So I'll not submit those. Maybe I'll go to work on rewriting I'm not sure. Triggered myself into this thread mostly due to recent pussy-footing around another culturally biased developer in a thread I was in and the most definite impression I got there was that if it had ...

I did a talk on Linux "social engineering" at {OSCON, IEEE NW something, and SCALE}. All about what (not) to do, how to do it, etc. Slides for it are available in http://www.xenotime.net/linux/mentor/ . --- ~Randy --

I'm in the process of trying to write an initial draft of just such a document right now. I'll post it once I'm a bit more done (gimme an hour or two). -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --

Of course I speak for myself. And I am absolutely open about my belief that such _contribution_s_ need to be discouraged. Actively. Hell, a month ago I mentioned right-justifying text in comments as "we'll never reach _that_" kind of pointless idiocy. And there we are, much closer to that than I ever expected. I have nothing against contributors. I *DO* have a lot against a very specific class of contributions. Exactly because they actively prevent people from moving on to saner stuff. ...

I think that they are often young and want to get their name associated Not that much for newbies. Linux is thought^Wknown to be bug-free. People don't get a name by claiming everywhere "hey, I found bug X which I could trigger by doing stupid thing Y, and I could fix it, I've contributed". On the opposite, they have the ability to say "hey friends, now you can buy webcam XX, I have implemented support for it" (often meaning "I send a PCI ID update"). This is a lot more rewarding for ...

Sigh... <mode=Andrew> Let me make it clear that Davem is not speaking for me </mode>. It's NOT about personalities of people submitting patches. I don't know them and I absolutely do not believe that either personality per se or expected future behaviour can be derived from the fact of having sent this kind of junk. So "bottom-feeders" is IMO uncalled for - it presumes far more personal and permanent features that simply are not in evidence. Moreover, I'm less concerned about ...

There are good ways in which to communicate that and there are bad ways. Look. This has absolutely nothing to do with that patch. Don't care, doesn't matter, irrelevant, not even going to discuss it in this context. I have spoken with engineers both individual and within companies who have developed and who plan to develop substantial kernel features. I'm forever explaining to people why they should work to get that code merged up. One reason for their not yet having done so which comes ...

[Johannes Weiner - Wed, May 21, 2008 at 09:42:32PM +0200] | Hi, | | Cyrill Gorcunov <gorcunov@gmail.com> writes: | | > [Andrew Morton - Wed, May 21, 2008 at 10:46:44AM -0700] | > | On Wed, 21 May 2008 08:09:39 -0400 Theodore Tso <tytso@mit.edu> wrote: | > | | > | > On Wed, May 21, 2008 at 06:32:06AM -0400, Christoph Hellwig wrote: | > | > > On Wed, May 21, 2008 at 01:50:37AM -0700, Andrew Morton wrote: | > | > > > Oh, what a marvellous way to encourage new contributors that was. Thank | > ...

Hello; I'm lost as to where to look in the kernel, as to why I'm receiving a black screen with startx DRI seems to be fine, I'm noticing a sema_init but am not sure if this is the cause of the blackness. any direction as to where I might look would be helpful. regards; -- Justin P. Mattock --

Kernel version? A git-bisect should get you down the the offending commit within an hour or three. http://www.kernel.org/doc/local/git-quick.html has some instructions. But if you're on 2.6.26-rcX, be sure to use the very latest - a pile of bad DRI code got reverted recently. This morning, I think. --

Just so I can have suspend working properly, now the next question is seeing if radeohd can wakeup from suspend That way I don't have to be confined to using one module But for the time being I need a nice cold beer from this headache.. : - ) regards; -- Justin P. Mattock --

O.K. I've got my 8-balls back, from what I could tell there was three areas that needed attention to: 1) add nopage back into the kernel 2) The DRI needed to be reverted back to it's original state, or modified due to some issue. 3) find_task_by_pid( pid) on the module side needed to be changed to find_task_by_vpid( pid) or else you'll have an issue with init_pid_ns I did have the latest DRI updates yesterday, but should have been using nopage to build the module instead of fault. so three ...

Alright: I'm using 2.6.26-rc3-00122-g748bf99, I pulled if I can remember Monday night and I did notice drmP.h and the rest of the drm files, but, will try and pull again to see if it makes a difference. As for the question about what video card nvidia or ati, I'm stuck with ati, went into apple yesterday to see if that would be easy to change out, but unfortunately I would have to get a new laptop. To bad apple didn't use an intel graphics card, that linux already has a module for. As for ...

Which X video driver are you using? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

How to filter the Block I/O in 2.6 kernel? I have looked some in blktrace. blktrace can trace the block device I/O info. But that can't filter/change this I/O. Is the Linux kernel have any way to filter/change a block i/o before it write to hard disk? I don't want to change kernel code and re-build. Is Kernel already have any I/O filter interface? Thanks, Xiongjia Le --

Dave, Another round of fixes intended for 2.6.26...one of these ("ath5k: Fix loop variable initializations") is already queued in net-next-2.6, but it fixes the following bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=10605 Also included is "mac80211: fix NULL pointer dereference in ieee80211_compatible_rates", which fixes another bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=10755 Let me know if there are problems! Thanks, John --- Individual patches are ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit aufs configuration and Makefile Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/Kconfig | 174 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/Makefile | 39 ++++++++++++ 2 files changed, 213 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/Kconfig create mode 100644 fs/aufs/Makefile diff --git a/fs/aufs/Kconfig b/fs/aufs/Kconfig new file mode 100644 index ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit pseudo-link is a logical hardlink over branches or different filesystems. Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/plink.c | 344 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 344 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/plink.c diff --git a/fs/aufs/plink.c b/fs/aufs/plink.c new file mode 100644 index 0000000..7197d7c --- /dev/null +++ ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit dentry operations main lookup operation Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/dentry.c | 959 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 959 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/dentry.c diff --git a/fs/aufs/dentry.c b/fs/aufs/dentry.c new file mode 100644 index 0000000..1e16848 --- /dev/null +++ b/fs/aufs/dentry.c @@ -0,0 +1,959 @@ +/* + * ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit br_fuse.c special handling for inode attributes on FUSE branch br_nfs.c lookup functions for NFS branch br_xfs.c special handling inode attributes on XFS branch Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/br_fuse.c | 107 ++++++++++++++++ fs/aufs/br_nfs.c | 347 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/br_xfs.c | 67 ++++++++++ 3 files changed, 521 insertions(+), 0 deletions(-) ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit some aufs objects have a corresponding entry under sysfs, so the lifetime will be managed by struct kref even if CONFIG_SYSFS is disabled. This file is compiled unconditionally. Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/sysaufs.c | 102 +++++++++++++++++++++++++++++++++++++++ fs/aufs/sysaufs.h | 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 239 insertions(+), 0 ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> - incorporate fs/aufs - export __lookup_hash() - make lockdep deeper for debugging locks in a stackble fs Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/Kconfig | 2 ++ fs/Makefile | 1 + fs/namei.c | 2 +- include/linux/lockdep.h | 4 ++++ include/linux/namei.h | 1 + 5 files changed, 9 insertions(+), 1 deletions(-) diff --git a/fs/Kconfig b/fs/Kconfig index ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit debug print functions and magic sysrq handler Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/debug.c | 466 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/debug.h | 208 +++++++++++++++++++++++++ fs/aufs/sysrq.c | 101 ++++++++++++ 3 files changed, 775 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/debug.c create mode 100644 fs/aufs/debug.h create mode 100644 ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit workqueue for asynchronous, super-io or delegated operations. they are used in various places such as, - handling 'opaque' directory and whiteout - lookup and copy-up/down with credential - create/remove files and file i/o by delegation - internal xino file i/o Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/wkq.c | 294 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/wkq.h | 158 ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit handling mount options/flags Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/opts.c | 1492 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/opts.h | 243 +++++++++ 2 files changed, 1735 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/opts.c create mode 100644 fs/aufs/opts.h diff --git a/fs/aufs/opts.c b/fs/aufs/opts.c new file mode 100644 index 0000000..ca897a8 --- ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit inode other operations (permission/lookup/setattr/readlink/follow_link/put_link) Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/i_op.c | 728 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 728 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/i_op.c diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c new file mode 100644 index 0000000..deb25d8 --- /dev/null +++ ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit sub-routines or simple wrappers for VFS Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/vfsub.c | 633 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/vfsub.h | 472 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 1105 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/vfsub.c create mode 100644 fs/aufs/vfsub.h diff --git a/fs/aufs/vfsub.c b/fs/aufs/vfsub.c new file mode ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> branch management Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/branch.c | 912 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/branch.h | 352 +++++++++++++++++++++ 2 files changed, 1264 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/branch.c create mode 100644 fs/aufs/branch.h diff --git a/fs/aufs/branch.c b/fs/aufs/branch.c new file mode 100644 index 0000000..88b6258 --- /dev/null +++ ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit file operations and vm operations Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/f_op.c | 645 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 645 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/f_op.c diff --git a/fs/aufs/f_op.c b/fs/aufs/f_op.c new file mode 100644 index 0000000..cf48f45 --- /dev/null +++ b/fs/aufs/f_op.c @@ -0,0 +1,645 @@ +/* + * Copyright (C) ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit super_block operations and private data Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/sbinfo.c | 261 +++++++++++++++++ fs/aufs/super.c | 835 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/super.h | 405 ++++++++++++++++++++++++++ 3 files changed, 1501 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/sbinfo.c create mode 100644 fs/aufs/super.c create mode 100644 ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit inode rename operation Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/i_op_ren.c | 788 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 788 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/i_op_ren.c diff --git a/fs/aufs/i_op_ren.c b/fs/aufs/i_op_ren.c new file mode 100644 index 0000000..b61d4cb --- /dev/null +++ b/fs/aufs/i_op_ren.c @@ -0,0 +1,788 @@ +/* + * Copyright ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit aufs manual Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- Documentation/filesystems/aufs/aufs.5 | 1609 +++++++++++++++++++++++++++++++++ 1 files changed, 1609 insertions(+), 0 deletions(-) create mode 100644 Documentation/filesystems/aufs/aufs.5 diff --git a/Documentation/filesystems/aufs/aufs.5 b/Documentation/filesystems/aufs/aufs.5 new file mode 100644 index 0000000..42aabc6 --- /dev/null +++ ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit inode add operations (mknod/creat/link/mkdir) Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/i_op_add.c | 765 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 765 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/i_op_add.c diff --git a/fs/aufs/i_op_add.c b/fs/aufs/i_op_add.c new file mode 100644 index 0000000..471a31f --- /dev/null +++ b/fs/aufs/i_op_add.c @@ -0,0 +1,765 ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit NFS exporting Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/export.c | 578 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 578 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/export.c diff --git a/fs/aufs/export.c b/fs/aufs/export.c new file mode 100644 index 0000000..13b7b67 --- /dev/null +++ b/fs/aufs/export.c @@ -0,0 +1,578 @@ +/* + * Copyright (C) 2007-2008 ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit directory operations Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/dir.c | 548 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/aufs/dir.h | 145 +++++++++++++++ 2 files changed, 693 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/dir.c create mode 100644 fs/aufs/dir.h diff --git a/fs/aufs/dir.c b/fs/aufs/dir.c new file mode 100644 index 0000000..c4e328d --- /dev/null +++ ...

From: Junjiro Okajima <hooanon05@yahoo.co.jp> initial commit sysfs entries, compiled only when CONFIG_SYSFS is enabled Signed-off-by: Junjiro Okajima <hooanon05@yahoo.co.jp> --- fs/aufs/sysfs.c | 353 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 353 insertions(+), 0 deletions(-) create mode 100644 fs/aufs/sysfs.c diff --git a/fs/aufs/sysfs.c b/fs/aufs/sysfs.c new file mode 100644 index 0000000..63cffe7 --- /dev/null +++ b/fs/aufs/sysfs.c @@ -0,0 +1,353 ...

I'm not certain this is safe to do it quite this way. It would be better to keep that spinlock held so that no operations could be in progress on either port while these operations are happening. It would be better to fix the regression from 419c434c35614609fd0c79d335c134bf4b88b30b in block/blk_settings.c that resulted in the blk_queue_bounce_limit allocation wrongly allocating emergency ISA pages in the first place as a 32-bit DMA mask does not need them. --

On Wed, 21 May 2008 08:31:26 -0600 "never" is.. a dangerous assumption. It depends on the details of what GFP_DMA exactly means and how the exact zoning in the system is set up. All of that is undergoing flux (Andi Kleen has been hacking on that for example) But yes, on the existing VM layout on a 32 bit X86 system it wouldn't you're absolutely right that the current implementation has a bug. But the sleepy-ness part isn't really part of that bug. When we get pools to fill for other masks ...

This is a complete overhaul of the bootmem allocator. alloc_bootmem() will more likely respect the requested goal as the old logic tried allocation on the first node in the system and dropped the goal immediately if it not happened to reside on that node. Now we try the first allocation on the node holding the goal and then fall back. free_bootmem() and reserve_bootmem() have become more strict. Users have to make sure that the PFNS of the range are contiguous. __alloc_bootmem_node_low() ...

On Wed, 21 May 2008 03:37:35 +0200 Oh gee. bootmem is an area where large numbers of people have done hit-and-run jobs over a lot of years. Nobody owns it and I'm sure that you are now the world's expert. We just need to push ahead with this, I guess. I expect there will be problems - so many architectures which do such different things, and all the configuration options churning things around. So how to move ahead with this? - I think I'd prefer not to drop ...

From: Divy Le Ray <divy@chelsio.com> Add LRO support. Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/Kconfig | 1 drivers/net/cxgb3/adapter.h | 14 ++ drivers/net/cxgb3/common.h | 1 drivers/net/cxgb3/cxgb3_ioctl.h | 1 drivers/net/cxgb3/cxgb3_main.c | 19 +++ drivers/net/cxgb3/sge.c | 235 +++++++++++++++++++++++++++++++++++++-- drivers/net/cxgb3/t3_cpl.h | 11 ++ 7 files changed, 269 insertions(+), 13 ...

From: Divy Le Ray <divy@chelsio.com> Take potential dma mapping errors in account. Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/sge.c | 53 ++++++++++++++++++++++++++++++++++++----------- 1 files changed, 41 insertions(+), 12 deletions(-) diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c index 796eb30..0741deb 100644 --- a/drivers/net/cxgb3/sge.c +++ b/drivers/net/cxgb3/sge.c @@ -376,13 +376,16 @@ static void free_rx_bufs(struct pci_dev *pdev, ...

Content-Length: 4235 Lines: 110 ... and we have few enough places using the latter to make it simpler to do search and replace... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/sh/drivers/heartbeat.c | 2 +- drivers/input/keyboard/aaed2000_kbd.c | 2 +- drivers/input/keyboard/corgikbd.c | 2 +- drivers/input/keyboard/jornada680_kbd.c | 2 +- drivers/input/keyboard/jornada720_kbd.c | 2 +- drivers/input/keyboard/spitzkbd.c | ...

Can we try to get this sorted out properly instead of constantly fiddling with it? Currently we use -ffreestanding on some architectures and fix breakages on the other architectures when they arise. The options I see for getting this fixed properly are: - use -ffreestanding on all architectures or - don't use -ffreestanding on any architecture and move the string functions (and perhaps other functions if required) out-of-line I'd prefer the first option, but I know that not everyone ...

Hi, Please use a more recent compiler, 4.0 created too many problems on m68k, which we only got under control with 4.1, so at least on m68k 4.0 is not really supported. bye, Roman --

Hi, It actually was strlen that was generated and not strcat. bye, Roman --

Hi, This won't help completely unless you also clean up all archs to use the same mappings to the builtin functions. The main problem I had with -ffreestanding is that it's awkward to map a library function to the builtin function and also provide the fallback from lib/string.c. If you look at asm-m68k/string.h I once tried this with the mem* functions and I still have the duplicated memcmp in arch/m68k/lib/string.c. (You could argue that it would be easier to just remove the define ...

Content-Length: 1025 Lines: 30 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- sound/oss/Kconfig | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/oss/Kconfig b/sound/oss/Kconfig index 857008b..3be2dc1 100644 --- a/sound/oss/Kconfig +++ b/sound/oss/Kconfig @@ -79,7 +79,7 @@ config SOUND_TRIDENT config SOUND_MSNDCLAS tristate "Support for Turtle Beach MultiSound Classic, Tahiti, Monterey" - depends on SOUND_PRIME && (m || !STANDALONE) + depends ...

Content-Length: 1027 Lines: 30 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- fs/ocfs2/alloc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c index 41f84c9..10bfb46 100644 --- a/fs/ocfs2/alloc.c +++ b/fs/ocfs2/alloc.c @@ -2788,7 +2788,7 @@ static int ocfs2_merge_rec_right(struct inode *inode, BUG_ON(index >= le16_to_cpu(el->l_next_free_rec)); left_rec = &el->l_recs[index]; - if (index == ...

Content-Length: 1164 Lines: 39 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/sbus/char/bpp.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/sbus/char/bpp.c b/drivers/sbus/char/bpp.c index b87037e..03c9660 100644 --- a/drivers/sbus/char/bpp.c +++ b/drivers/sbus/char/bpp.c @@ -869,7 +869,7 @@ static void probeLptPort(unsigned idx) instances[idx].mode = COMPATIBILITY; instances[idx].run_length = 0; ...

Content-Length: 454 Lines: 21 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/um/Kconfig | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/um/Kconfig b/arch/um/Kconfig index dba8e05..6976812 100644 --- a/arch/um/Kconfig +++ b/arch/um/Kconfig @@ -259,6 +259,8 @@ if BROKEN source "drivers/mtd/Kconfig" endif +source "drivers/leds/Kconfig" + #This is just to shut up some Kconfig warnings, so no prompt. config INPUT bool -- ...

Content-Length: 581 Lines: 24 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- arch/um/kernel/ksyms.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/um/kernel/ksyms.c b/arch/um/kernel/ksyms.c index 66e2a30..ccc02a6 100644 --- a/arch/um/kernel/ksyms.c +++ b/arch/um/kernel/ksyms.c @@ -60,6 +60,11 @@ EXPORT_SYMBOL(os_rcv_fd); EXPORT_SYMBOL(run_helper); EXPORT_SYMBOL(start_thread); ...

We want sys/ptrace.h before any includes of linux/ptrace.h and asm/user.h pulls the latter. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Jeff Dike <jdike@addtoit.com> --- arch/um/os-Linux/sys-i386/registers.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/um/os-Linux/sys-i386/registers.c b/arch/um/os-Linux/sys-i386/registers.c index c6183e7..b487cbe 100644 --- a/arch/um/os-Linux/sys-i386/registers.c +++ ...

first 3 patches resent, the rest is new... --

Fair point, I was hoping to get the following family: get_le16 put_le16 get_unaligned_le16 put_unaligned_le16 And get rid of the le16_to_cpup api. Then the it's explicit when alignment is an issue, and the endianess is also explicit. That and I think it just looks nicer than the existing *p versions. Just a thought, Harvey --

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/net/3c509.c | 15 +++++++-------- drivers/net/atlx/atl1.c | 2 +- drivers/net/usb/catc.c | 5 ++++- drivers/net/usb/rndis_host.c | 4 ++-- drivers/net/wireless/zd1211rw/zd_mac.c | 2 +- drivers/net/wireless/zd1211rw/zd_usb.c | 2 +- 6 files changed, 16 insertions(+), 14 deletions(-) diff --git a/drivers/net/3c509.c b/drivers/net/3c509.c index ...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/frontends/or51132.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb/frontends/or51132.c b/drivers/media/dvb/frontends/or51132.c index c7b5785..5ed3254 100644 --- a/drivers/media/dvb/frontends/or51132.c +++ b/drivers/media/dvb/frontends/or51132.c @@ -126,7 +126,7 @@ static int or51132_readreg(struct or51132_state *state, u8 reg) reg, err); return -EREMOTEIO; ...

Thus the "mostly" part - on hot paths the microoptimization is worth the trouble. None of the places in question is on such paths... --

FWIW, I wonder how they really compare on misaligned and whether it would make sense for gcc to try and generate a single load on targets that are known to allow that... Hell knows; I still find explicit variant more readable in this case and AFAICS it's not a critical path... --

I sent a patchset getting rid of the p variants earlier today, Dave Miller made a good point that some arches have well optimized versions of these as they have specific machine instructions they can use. Agreed that I don't much like them either, was thinking of adding a u32 get_le32(__le32 *ptr) type api and get rid of the le32_to_cpup api. Cheers, Harvey --

hx->addr = get_unaligned_le16(&b[1]); Cheers, Harvey --

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/dvb-usb/dvb-usb-firmware.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-firmware.c b/drivers/media/dvb/dvb-usb/dvb-usb-firmware.c index e1112e3..733a7ff 100644 --- a/drivers/media/dvb/dvb-usb/dvb-usb-firmware.c +++ b/drivers/media/dvb/dvb-usb/dvb-usb-firmware.c @@ -127,7 +127,7 @@ int dvb_usb_get_hexline(const struct firmware *fw, struct hexline *hx, if ...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/dvb-usb/m920x.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/m920x.c b/drivers/media/dvb/dvb-usb/m920x.c index a12e6f7..54626a0 100644 --- a/drivers/media/dvb/dvb-usb/m920x.c +++ b/drivers/media/dvb/dvb-usb/m920x.c @@ -16,6 +16,7 @@ #include "qt1010.h" #include "tda1004x.h" #include "tda827x.h" +#include <asm/unaligned.h> /* debug */ static int ...

Ditto. Cheers, Harvey --

You want me to patch the unaligned guys to take typed pointers and follow it through? Or do you mind? Cheers, Harvey --

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/cx18/cx18-irq.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/cx18/cx18-irq.c b/drivers/media/video/cx18/cx18-irq.c index 0590d71..25114a5 100644 --- a/drivers/media/video/cx18/cx18-irq.c +++ b/drivers/media/video/cx18/cx18-irq.c @@ -161,13 +161,15 @@ irqreturn_t cx18_irq_handler(int irq, void *dev_id) */ if (sw2) { - if (sw2 & (cx->scb->cpu2hpu_irq_ack ...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/video/bt8xx/bttv-risc.c | 8 +++++--- drivers/media/video/btcx-risc.c | 2 +- drivers/media/video/btcx-risc.h | 4 ++-- drivers/media/video/cx23885/cx23885-core.c | 8 ++++---- drivers/media/video/cx88/cx88-core.c | 8 ++++---- 5 files changed, 16 insertions(+), 14 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-risc.c b/drivers/media/video/bt8xx/bttv-risc.c index ...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 2 +- drivers/media/dvb/ttusb-dec/ttusb_dec.c | 25 +++++++++++---------- drivers/media/dvb/ttusb-dec/ttusbdecfe.c | 10 ++++---- 3 files changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c b/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c index 732ce4d..5d2d81a 100644 --- ...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/dvb-core/dvb_net.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvb_net.c b/drivers/media/dvb/dvb-core/dvb_net.c index 56d871c..c2334ae 100644 --- a/drivers/media/dvb/dvb-core/dvb_net.c +++ b/drivers/media/dvb/dvb-core/dvb_net.c @@ -168,7 +168,7 @@ struct dvb_net_priv { * stolen from eth.c out of the linux kernel, hacked for dvb-device * by Michael ...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/ttpci/av7110.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/media/dvb/ttpci/av7110.c b/drivers/media/dvb/ttpci/av7110.c index 747e7f1..f05d43d 100644 --- a/drivers/media/dvb/ttpci/av7110.c +++ b/drivers/media/dvb/ttpci/av7110.c @@ -51,6 +51,7 @@ #include <linux/crc32.h> #include <linux/i2c.h> #include <linux/kthread.h> +#include <asm/unaligned.h> #include ...

Endianness annotations and fixes + fixing the handling of ->uncorrected_block_count Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/media/dvb/cinergyT2/cinergyT2.c | 46 ++++++++++++++++--------------- 1 files changed, 24 insertions(+), 22 deletions(-) diff --git a/drivers/media/dvb/cinergyT2/cinergyT2.c b/drivers/media/dvb/cinergyT2/cinergyT2.c index f5010e8..a824f37 100644 --- a/drivers/media/dvb/cinergyT2/cinergyT2.c +++ b/drivers/media/dvb/cinergyT2/cinergyT2.c @@ ...

Hm, OK, so it's "OK" I guess. It stopped after a few hours anyway, I think it was related to the disk IO (dd if=/dev/hdd of=/dev/null).... Thanks for replying, Christian. -- BOFH excuse #75: There isn't any problem --

Nobody else actually has a reference to req at this point, so the unlock is not really necessary. It might not be a bad idea to jump to --

Caused by out of memory, a page fault couldn't be serviced due to memory exhaustion. See arch/mips/mm/fault.c. --

If you feel brave, take a crack at the DYNAMIC_FTRACE. It's been done for x86 (both 32 and 64 bit), PPC (also both 32 and 64 bit) as well as Sparc64. The dynamic ftrace is self modifying code, that will start off having mcount simply call a nop. Then later it will change that to call a "record_ip" function. A daemon is kicked off to change all the IPs that are called into NOPs. When tracing is enabled, all the NOPs are converted into calls to the trace function. Dynamic ftrace also adds ...

There have been long discussions about that. The end result was that being too weakly ordered is just asking for trouble because the majority of drivers are written & tested on x86 which is in order. If you look at our accessors, minus that gcc problem you found, the barriers in there should pretty much guarantee ordering in the cases that matter, which are basically MMIO read followed by memory accesses and memory writes followed by MMIO. In fact, MMIO read are fully Ok, so there is a ...

If that's the case, there is a bug. Ignoring gcc possible optimisations, the accessors contain the necessary memory barriers for things to work the way you describe above. If the use of volatile and clobber in our macros isn't enough to also prevent optimisations, then we have a bug The linus kernel -cannot- be compiled with strict aliasing rules. This is one of the many areas where those are violated. Frankly, this strict aliasing stuff is just a total nightmare turning a pefectly nice ...

Someone should update memory-barriers.txt, because it doesn't say that, and No, it's compiled with a normal kernel build, which includes -fno-strict-aliasing. --

It's worth now trying 2.6.26-rc3-git2 or later: there was indeed a problem introduced in 2.6.26-rc2-git<I-haven't-looked-which> which caused segfaults in various things when CONFIG_HIGHMEM64G. (See http://lkml.org/lkml/2008/5/19/446 for what I'm talking about; Sorry, I've not looked into that at all: Cc'ed ATM maintainer. Hugh --

FYI, I created an item in bugzilla to track this http://bugzilla.kernel.org/show_bug.cgi?id=10765 --

Everything inside #ifdef __KERNEL__ ... #endif are stripped. From netfilter.h: #ifdef __KERNEL__ #include <linux/init.h> #include <linux/types.h> #include <linux/skbuff.h> #include <linux/net.h> #include <linux/netdevice.h> #include <linux/if.h> #include <linux/in.h> #include <linux/in6.h> #include <linux/wait.h> #include <linux/list.h> #include <net/net_namespace.h> #endif Include of types.h should be outside the #ifdef block. Sam --

No. There is no new message added after kernel boot messages --

Hi, The only place that fork() returns EAGAIN is for number of processes being >= its limit. Does this user already have >= 1024 processes? --- ~Randy --

2008/5/21 mark <markkicks@gmail.com>: What about if you run 'dmesg'? are there any clues in that output? any kernel stack traces? error messages? warnings? anything out of the ordinary? -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --

cat /proc/loadavg 0.39 0.45 0.57 1/1412 12032 cat /proc/sys/kernel/threads-max 274432 Is it possible to get this debug messages by turning on some flags? If not yes, pl. send debug patches. its a live box and I will try to do it! This is my system / kernel info: uname -a Linux XXX 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux thanks a lot!!!! --

Hi, Hannes --

Well, "regression" is the wrong phrase. You've switched drivers (from the legacy RTC to the new one), so this is not the thing which worked for you before. Nonetheless, this should get fixed soonish; it just happens to be something nobody reported before. See two comments about patch brokenness below, though ... If I had realized there was a "pnpacpi=off" option, I'd have sent in my patch addressing this problem way back when the rtc-cmos code merged! I was deluded into thinking this ...

Did you get lockdep warnings? Those disable all lock debugging, including lockstat. --

Hi Peter - Yesterday, during boots I /was/ getting a problem with NVIDIA ck804xrom registration problems - "Unable to register resource" - it did produce a stack trace w/ lock calls in the stack. Since then I've cut /way/ back on my .config, and I don't see that problem anymore, and the lock stats seem to be updating correctly with this new .config. [If I have time later today, I'll go back to the old .config and try to track down the ck804xrom issue.] Thanks for the hint about watching ...

Yeah, that is what I've done in the past for trees: http://programming.kicks-ass.net/kernel-patches/concurrent-pagecache/23-rc1-rt/radix-c... --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for pointing this out. Yes this could solve part of the issue, at the price of duplicating the inode mutex class. However, this still does not solve the issue when deleting config_groups, since in that case all nodes of the tree are locked. Thinking about adding lockdep support for concurrent locking of the direct children of a node in a tree... Louis - -- Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment ...

Sorry for answering late, it seems that we are working in very different timezones :) The former approach limits the level of recursion, but also the total number of default groups (whole tree) under a created config_group. I Note that I keep lockdep on for the first level of recursion, which lets I can do this. However, the original approach should be modified since I_MUTEX_CHILD + 1 == I_MUTEX_XATTR and I_MUTEX_CHILD + 2 == I_MUTEX_QUOTA. For instance we could redefine ...

thanks, this too solves the build problem. Tested-by: Ingo Molnar <mingo@elte.hu> Ingo --

Acked-by: Clemens Ladisch <clemens@ladisch.de> --

Remove #ifdefs around includes; including too much should be always safe. Signed-off-by: Pavel Machek <pavel@suse.cz> --- commit 06f12eb6da33da70dbdccbee5a687d5353782e1d tree 62b9b1a785bbc5a9daa22512ec95601d54aa004d parent 44b4ec2247971ba1a1906752208182146fc5974c author Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:46:46 +0200 committer Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:46:46 +0200 arch/x86/kernel/i8259.c | 11 ----------- 1 files changed, 0 insertions(+), 11 ...

Remove #ifdefs where the only difference is formatting of comments. Signed-off-by: Pavel Machek <pavel@suse.cz> --- commit 800e1add46a2686995af98432a7971150318676d tree 5daa71306ceb60b0fb7e5707ec4d9701c06197de parent 06f12eb6da33da70dbdccbee5a687d5353782e1d author Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:52:11 +0200 committer Pavel <pavel@amd.ucw.cz> Wed, 21 May 2008 11:52:11 +0200 arch/x86/kernel/i8259.c | 20 +++----------------- 1 files changed, 3 insertions(+), 17 ...

Nadia, I think for the moment it might be best to revert that change, since there's no actual need to change things. I've updated the man page to say that this value is in kibibytes. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html --

That's actually not needed. The IOMMU code was carefully written to not require AGP. The only requirement it has is that if AGP is enabled it has to be built in. -Andi --

Hello everybody, I have linux-2.6.25-rc6 running on a board with an i2c rtc chip, and synchronized to a ntp server. When my board starts, the current time is correctly read from the rtc chip, but ... I noticed that my rtc chip does not get updated by the kernel every 11 min, on my powerpc board, just like it would be on all other architectures. Paul Mackerras told me that that is now supposed to be done by the code inside #ifdef CONFIG_GENERIC_CMOS_UPDATE in kernel/time/ntp.c. I agree ...

Maciej, thank you very much for your reply. I don't think this was caused by interrupt routing. I added lots of "printk" before following output, and saw interrupts could be triggered correctly. hdc: 195371568 sectors (100030 MB) w/7539KiB Cache, CHS=16383/255/63, UDMA(33) LynxOS has been run successfully on this board, and we want port it to Linux recently. I'm not sure which resource (I/O or Memory space) should be used for DMA operation because all memory resources haven't been set (the ...

Hi Jeff, Here is the revised version - I cheered Dijkstra up by getting rid of that goto. -- Tom -- From: Tom Spink <tspink@gmail.com> Date: Wed, 21 May 2008 00:53:54 +0100 Subject: [PATCH] Locate the bottom of the address space This patch makes os_get_task_size locate the bottom of the address space, as well as the top. This is for systems which put a lower limit on mmap addresses. It works by manually scanning pages from zero onwards until a valid page is found. Because the ...

Actually, since the search for the lowest valid page needs to be there anyway, I think we should just always use it, and not bother with /proc/sys/vm/mmap_min_addr at all. Less code, and the new code is more heavily exercised this way. Jeff -- Work email - jdike at linux dot intel dot com --

You don't seem to have followed the thread. For UML, the address isn't a hint - it's a requirement. Tossing random numbers into your code until a particular test works isn't really the way to go. In this case, we are looking at mmap_min_addr being set at 0x10000, but which may be set to 0x20000 someplace else. Jeff -- Work email - jdike at linux dot intel dot com --

Looks good to me. Thanks. -- Yasunori Goto --

Physically contiguous memory is a real requirement, especially for DMA. I'm not sure what's confusing about that? --

... if both info->handler and info->prep_read_poll are NULL and I'm not sure that solving that problem in uio_pdrv is the right approach. Other uio drivers might have the same problem, so better allow the userspace driver to allocate some memory in a more generic Assume your irq is stuck at its active level. Normally the irq is then disabled after some time. You can handle that in your userspace driver, but with acking in kernel space and returning IRQ_NONE or IRQ_HANDLED you get it for free. ...

On Wed, May 21, 2008 at 8:04 PM, Uwe Kleine-König I don't think there is any generic way for a user space driver to allocate physically contiguous memory. If such way exists then we Ok, so normally if the irq is stuck as asserted then it gets disabled after some time. In my case it gets disabled directly so see it as a feature. =) Would you like to fold in the irq_handler and irq_enable function in your patch, or would you like me to make a patch that fits on top of your latest ...

Hello, Yes it does. I thought the physical address is stored in internal_addr and the virtual in addr, but it's the other way round. Thanks. Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 --

On Wed, May 21, 2008 at 5:05 PM, Uwe Kleine-K=F6nig [Added Matsubara-san as CC] Sure, here is a little test program. Have a look at "uio_mem". The "address" member contains the physical address that can be used for bus mastering DMA. Compare that to "iomem" which is the pointer to the virtual memory area in user space. Hope this helps! / magnus

Just add irq_disabled to struct uio_platdata and define irqreturn_t uio_pdrv_disirq(int irq, struct uio_info *dev_info) { struct uio_platdata *pdata = container_of(dev_info, struct uio_platdata, uio_info); disable_irq(irq); pdata->irq_disabled = 1; return IRQ_HANDLED; } EXPORT_SYMBOL(uio_pdrv_disirq); void uio_pdrv_enirq(struct uio_info *dev_info) { ... } EXPORT_SYMBOL(uio_pdrv_enirq); and then you can do info->handler = uio_pdrv_disirq; info->enable_irq = ...

Agreed. I have put some thought on it in the past, and while the input subsystem is the only thing even remotely usable for this *right now*, a new subsystem for data acquisition would be the best way forward. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --

I don't think that input subsystem woudl be the best choice. While we do support the event-driven mechanism for delivering information to userspace input is mostly oriented for human interface devices, not general data acquisition. If anything input_dev is too fat. Another thing is that input layer anonymizes input devices, makes them capability-oriented. I.e. we dont really care what model of joystick we have, we want something that reports ABS_X, ABS_Y, BTN_FIRE and userpsace can use it ...

Hi Hans and Jean, Hmm.. Going to be interesting coming up with a name! Guess that can come at a Definitely agreed that it makes sense to put DACs and ADCs in the same general place It would indeed by stretching the point to make drivers in that subsystem have more performance critical drivers! We seem to have a consensus that neither hwmon or Although I don't know much about the input subsystem it doesn't seem likely that all the devices we are considering would share all that much ...

I don't think it necessary to do this for every class, because only class_interface_* calls could cause the issue, and the class_interface_* are only used by pcmcia & scsi, do you think there --

Unless you know there is acscope, bcscope, etc. I'd rather add just ncscope.* instead of the catches-more *cscope.*. --

Hi, Unless there will be any objection here, I suggest consider the following patch which simply removes the code for the -DI_WISH_WORLD_WERE_PERFECT in the three methods which use it. The compilation errors we get when using -DI_WISH_WORLD_WERE_PERFECT show that this code was not built and not used for really a long time. Regards, Rami Rosen Signed-off-by: Rami Rosen <ramirose@gmail.com>

On Tue, 20 May 2008 11:46:46 -0700 With current interface, my concern is hotplug. File-per-node method requires delete/add files at hotplug. A file for all nodes with _maps_ method cannot be used because maps file says == The key/value pairs (and their ordering) should not * change between reboots. == And (*read) method isn't useful ;) Can we add new stat file dynamically ? Thanks, -Kame --

On Tue, May 20, 2008 at 5:28 PM, KAMEZAWA Hiroyuki OK, so we may need to extend the interface ... The main reason for that restriction (not allowing the set of keys to change) was to simplify and speed up userspace parsing and make any future binary API simpler. But if it's not going to work, we can maybe Yes, there's no reason we can't do that. Right now it's not possible to remove a control file without deleting the cgroup, but I have a patch that supports removal. The question is ...

Yes. CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y I reran the test for dozeons of times. 1) Background processes have impact on the result and cause result to fluctuate with 8~9 seconds; 2) After turning off most services (background processes), the result looks stable; 3) I tested both 2.6.26-rc1 and 2.6.26-rc2 with CONFIG_GROUP_SCHED=n. the first one's result is about 30 seconds and the second one's result is about 31 seconds. So ...

both will work with Blackfin toolchains, the latter form is obviously preferred -mike --

please add a common statement that tells you the module name if the u_int forms are weird ... i'd wonder why we have these variations i dont think that MAX_BLACKFIN_GPIOS check is needed. the we dont call gpio_free() here or in the fail0 case below. -mike --

Perhaps then, at least for now, in order to quickly restore the functionality of the driver with other platforms and to continue having the 8250 support in the blackfin, would be to apply this patch, that is a bit ugly but at least only affects to blackfin platforms using 8250-class uarts :) Regards, Javier -- ------------------------------------------------------------------------ Javier Herrero EMAIL: jherrero@hvsistemas.com HV Sistemas S.L. ...

Hi Steven, I ran mysql+oltp (ro) on 2.6.24.7-rt7 and 2.6.25-rt2 to compare throughput to their parent trees, and ended up with strange (and verified) looking performance curves for both trees. The changes in 2.6.24.7-rt8 and 2.6.25.4-rt3 cured the primary oddities. (it looks to me like there may be a little load-balancing issue, peak throughput isn't where it should be for my Q6600 box) -Mike --

It doesn't even apply for me. Moreover though -- __early_param() still seems to be too late for validate_pat_support() so this isn't going to work. __setup() is even later than that. I guess this just wants to set a flag Rene. --

Hi Dave, I was going to pull this into -tip, but I need a Signed-off-by: line in order to do so. Could you resend this so we can add it to -tip? -hpa --

With the provided patch applied on top of latest git tree, the optical drive connected to the JMicron controller WORKS with CONFIG_PCIEASPM=y. Just in case - this is on a Gigabyte GA-P35-DS3R v2.1 motherboard, BIOS F11. Thanks! Plamen Petrov, network & system administrator Filial - Silistra RU "Angel Kantchev" http://fs.ru.acad.bg/ -------------------------------- this message is UTF8 encoded _ ___ _____ ------------------------------------------ This message was sent by ...

Then these should be resolved. Sometimes, even setting just the time with ntpdate makes X go blank for a few seconds, or even exit. --

The unfortunate thing about these kinds of changes is that they're not all that easily tested. Straightforwardness would suggest that obviously the current table driven method will be faster due to needing fewer code cycles. Cache considerations add to that in the sense of instruction cache and can (!) detract from it in the sense of data cache; sometimes dramaticaly detract due to cache misses basically dwarving most anything else. However, in this case the table is a tiny 256-byte one ...

bitrev8() is used on every transferred byte for certain types of ISDN connections, ie. with a steady rate of 8000 bytes/sec. Depending on the driver, it will be called for individual data bytes or possibly a small number of bytes at a time, typically not more than 64, and typically in interrupt context. I'd expect the table driven version to perform better in those circumstances. Thanks, Tilman --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese ...

Well, it got some commentry on lkml, mainly from Christoph H. He was the one OK, I'll send a patch now. Thanks, Rusty. --

Well, a simple patch which does /* * comment goes here */ static inline int __must_check down_nowait(struct semaphore *sem) { return !down_trylock(sem); } and which does not deprecate down_trylock() could go into mainline right now, (assuming that the overall concept doesn't get shot down in review - did it get reviewed?) Then you can start trickling stuff out to people straight away. --

I think it would be useful to have a util-linux mention in the kernel's ./MAINTAINERS. We're rather joined-at-the-hip and you guys are a bit hard to find. If agreeable, please send a patch. Have you considered adding collectl to util-linux? If so, what was the outcome? Thanks. --

Does collectl require Perl for building? If it has a run-time dependency only, then it does not really differ from chkdupexe and it is up to whoever makes a distribution to partition binary packages in a sensible way. Maciej --

The filesystem may want to have the superblock passed. Well, will see once a filesystem has the need for it. --

peter@lappy:~/tmp$ cat cmp.c int within_len1(const void *addr, const void *start, unsigned long len) { return (unsigned long)addr - (unsigned long)start < len; } int within1(const void *addr, const void *start, const void *end) { return within_len1(addr, start, (unsigned long)end - (unsigned long)start); } peter@lappy:~/tmp$ cat cmp2.c int within_len2(const void *addr, const void *start, unsigned long len) { return ((unsigned long) addr ...

Definitely another way to put it. In my opinion the intention of the implementation is more easily understood though when spelling it out For empty ranges (start > end), this produces different (less expected) results than the previous version. Regards, Peter --

Well, that's what my initial submission did, but it required access to the mmc drivers host structure (moved from au1xmmc.h to au1100_mmc.h) to determine The comment explains what setting to NULL does, so I'd like to keep it (for people implementing this for other boards and wondering what Sure, I'll add another patch to the pile. Thank you! Manuel Lauss --

Actually, I have no reason to believe there *isn't* a device with KEY_WIMAX... but we need the WWAN type before we bother with a WiMax type :-) IMO, we should fix the issue by adding a "supertype", i.e., a class. Use that for generic grouping, and let type be more specific when there is a reason for it. Repeat the class as the type to get a "generic" type, when there is no reason to bother with more specific types. Stuff like "WiMax", "802.1a", "EDGE", "GRPS", "802.1bg" would be the type, ...

Then here's what you'd have with (class, type): EITHER 1. rfkill-input would manipulate based on class for a given input event. Therefore we would remove KEY_WIMAX from rfkill-input. OR... 2. rfkill-input would be teached to manipulate for classes (all switches in a class), and for (class,type) (hunt down all rfkill switches of that given type and class)... and it does mean KEY_WIMAX would only affect WiMAX switches, while WWAN would affect EDGE, GPRS, *WIMAX*, etc. And if you ...

BTW, I just realized this was mistakenly put in your initial patch; How would this apply to the case where I want to use the HW key to switch one off and turn the other one off (say I have both a WiMAX and EDGE cards in my machine); how could we do it to distinguish which key is which? I might be missing something. -- Inaky --

From bc47e710a3ebd8a5989404f711a051b6516d01ed Mon Sep 17 00:00:00 2001 From: Denis Cheng <crquan@gmail.com> Date: Wed, 21 May 2008 09:43:32 +0800 Subject: [PATCH] net/ipv4/arp.c: Use common hex_asc helpers Here the local hexbuf is a duplicate of global const char hex_asc from lib/hexdump.c, except the hex letters' cases: const char hexbuf[] = "0123456789ABCDEF"; const char hex_asc[] = "0123456789abcdef"; and here to print HW addresses, the hex cases are not significant. Thanks to ...

btw., i didnt do any specific ecryptfs testing - randconfig enabled it and it got booted. So if you dont get the warning during bootup/module-load, you'll have the same test coverage i did. Ingo --

Peter thx , it fixes the problem for me. Gabriel --

well, here is a second version of patch attached (i'm in office now so can't use my lovely mutt as usual). Please take a look. Any objections are quite welcome! - Cyrill -

Removing the entry without fixing the pending set is the bug we're trying to fix. That's what it does now, and it's wrong. Oleg had a patch that marked the sigqueue entry with whether it was on the shared queue or not. The caller in timer_delete knows which thread it is when it's on a thread queue, and whether it's on the shared queue. So it could be the caller's responsibility to know, i.e. its sigqueue_free call matches its send_sigqueue call. Thanks, Roland --

The timer_delete/sigqueue_free behavior predates my involvement with the code. I think it is fine to leave pending signals queued. (POSIX makes it unspecified for deleted timers. A robust application cannot even assume that they will or won't be removed consistently on one running system.) What I think everyone agrees is wrong in the abstract is the status quo, where (effectively) signals stay queued but with zeroed siginfo_t values. (This violates POSIX.) If there is a signal, its siginfo_t ...

Well, I think we could/should look at the bigger picture. The whole (and only!) reason for this problem in the first place is that the generic signal-handling code is simply not designed for signals going away. Because they simply don't. This whole sys_timer_delete() thing is purely based on that problem. So we have a few options here, I think. One is the approach that Oleg has taken, which is to try to remove the signals. Quite frankly, I don't much like it, because it's against ...

To clarify, this certainly does change the behavior. There are two changes. Firstly, a pending timer-firing signal currently gets its siginfo_t zeroed out synchronously by timer_delete and now will have its info preserved. That change alone is a potential problem for userland, so it should not go in without the following changes to prevent userland from seeing the signal at all. (Currently userland may see a spurious signal, but its si_code and si_value don't indicate a timer ...

> Factor out sigdelset() calls and remove the "still_pending" variable. Acked-by: Roland McGrath <roland@redhat.com> --

Suppose that the task has the pending SIG which is "blocked" by DRM. dequeue_signal() calls ->notifier(), it nacks the signal, we clear TIF_SIGPENDING. Then dequeue_signal() does recalc_sigpending() and sets TIF_SIGPENDING again. We return 0 to get_signal_to_deliver(), and then return to user-space with TIF_SIGPENDING. Endless loop ? Even if it works somehow... "blocking" SIG means that in fact we and of course this can't work for multithread programs, another thread can dequeue SIGTSTP ...

Well, sure, that makes sense. But that's not what it does. I can see what it does, I just can't tell why it really makes any sense. Despite the name, block_all_signals() in fact blocks no signals. What it does is install notifier/notifier_mask, which makes the hook get called for those particular signals and it can decide to delay the signal (in a kooky fashion that's not really reliable). drm_lock uses a mask containing only the stop signals (SIGSTOP, SIGTSTP, SIGTTOU, SIGTTIN). So for ...

Well, yes, I gave it a year in the feature removal schedule since I thought nobody was actually using it. But if you look at how hal/sysfs are always dependent on new versions of each other *anyway*, I think we can get away with removing this in maybe two years time, and distributors can unset the option if they know their hal is new enough? johannes

Maybe we should get the musb code to USB tree before that? It's been out of the scope for linux-omap tree for quite a while now. Tony --

When it's a USB patch, please post to linux-usb. Most of the relevant reviewers won't be on Linux-OMAP. ;) That said, I'm looking forward to seeing the www.beagleboard.org hardware [1] become more generally available. That will make some musb_hdrc hardware available in a more developer-friendly rig than, say, an N810 tablet. And it might well get more folk in a position where they can use that driver! (I think some Blackfin devboards are available already, but they're more pricey.) - ...

OK, it would be the best way to handle the century bit. I'll test your patch (if my board is still alive at the time ;-)) --- Atsushi Nemoto --

Hi Bruno, Question - does the problem happen if you dont have dritek extension enabled (i.e. on unpatched kernel)? -- Dmitry --

On Wed, May 21, 2008 at 1:11 PM, Segher Boessenkool For SPI the CS # *is* the address. :-) Unlike I2C, SPI doesn't impose any protocol on the data. It is all anonymous data out, anonymous data in, a clock and a chip select. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

[...] -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

I plan to answer this question soon. Right now I am quite busy. This emsgs_sema part of the aoe driver has never caused any problems for users but has caused many problems for me, because it is tricky to think about, to talk about, and for others to patch. I hope that there is a more straightforward way to get the current read-from-the-file-forever behavior using an existing kernel facility. A user currently can do, cat /dev/etherd/err ... and have it block, waiting until there is ...

My work here is done ;-) -- Jamie --

-chris --

That won't cause corruption, will it? The problem is purely one of Well. The product of two very small numbers is... --

It may not mention flushing explicitly, but it does not have to since the flushing is one way to implement what the above describes. Note how it says that request must have made it to physical medium before allowing others to continue? That means you have to either write through Yeah, that is precisely what it is and why it does not mention flushing Right, that is what ordered tags give you. But if you have write back caching enabled, then you get a completion event before the data ...

Can a kernel lockup cause this kind of corruption? Will a system reboot wipe the disk's write cache? I had imagined only power loss would prevent the disk from writing it's cache eventually; is that wrong? -- Jamie --

Nice, htree as a canary for disk corruption. This makes sense since directory data is the only verifiable structure at the logical data level and htree offers the only large scale, verifiable structure. Thanks for the lovely test methodology example. Let me additionally offer this tool: http://code.google.com/p/zumastor/source/browse/trunk/ddsnap/tests/devspam.c?r=1564 devspam The idea is to write an efficiently verifiable pattern across a range of a file, including a mix of ...

Another unquantified very small number. You have a UPS, but the first time you discover it's not wired up properly is when it fails. This happened recently in a customer's office... The UPS power wiring melted, leaving a big stinking hole, and all the servers went down - quickly. Another is misconfiguring the UPS daemon so it continues writing to disk for 30 minutes until the battery runs down... Like the chance of two disks going wrong in a RAID at the same time... that would ...

Calling get_cd() for every request smells like overhead, especially given that that get_cd() could ask for GPIO status via relatively slow bus (like I2C GPIO expanders). So, polling seems most reasonable solution here, no need to call it very often. How about these patches? Tested with and without get_cd() optimization. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

On Wed, 21 May 2008 22:47:13 +0400 Fair enough. You should probably add a comment about this somewhere so that people do not call get_cd() in the core request function and similar places. Place it so that both get_cd() and get_ro() are covered I'm always nervous when it comes to adding more callbacks, but I This should only be done when there is no bus handler. Since we are polling, we might actually miss the user removing and reinserting the card. The only way to check for that is to ...

On Tue, 20 May 2008 15:52:44 -0700, Here it is again, respun against today's git: driver core: Suppress sysfs warnings for device_rename(). Renaming network devices to an already existing name is not something we want sysfs to print a scary warning for, since the callers can deal with this correctly. So let's introduce sysfs_create_link_nowarn() which gets rid of the common warning. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Cornelia Huck ...

the lock is to protect one thing: coreb_status. we lock around any access to it, so it not being grabbed in the irq handler or any other function where coreb_status is not utilized is irrelevant. that means the BKL is not needed in the driver. the rest of your comments are more or less on target, but again irrelevant to the topic of the BKL. i'll keep them in mind when i rewrite the driver, thanks. -mike --

Hi, Sounds good. I will send new patch-set which is rebased to 2.6.26-rc3 and includes this fix, in this weekend. Cheers, Takashi --

Hi, I see. I'll move the aborting point to just before journal_write_commit_record() in the next version. Thanks, -- Hidehiro Kawai Hitachi, Systems Development Laboratory Linux Technology Center --

Ah no. I thought "x86: fix crash on cpu hotplug on pat-incapable machines" would have fixed the cpu hotplug bug for you. I was actually talking of the pick_next_task_fair incarnation of one of the cpu hotplug bugs. s390 backtrace on 2.6.25 looks like this. <1>Unable to handle kernel pointer dereference at virtual kernel address 00000200000db000 <4>Oops: 003b [#1] PREEMPT SMP <4>Modules linked in: dm_multipath sunrpc qeth_l2 dm_mod cu3088 qeth ccwgroup <4>CPU: 0 Not ...

Which bug, the order-2 allocs? I certainly didn't fix it. Last I tried, cpu hotplug still failed, but it was some time ago as patches flow. -- error compiling committee.c: too many arguments to function --

ACK. Perhaps you should send it to Andrew for a merge? Or maybe Rafael wants to add it to his patch queue? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Jesse, I just tried 2.6.26-rc3-next-20080521 on one of those systems and the pci=norom option worked as expected. Thanks, Gary -- Gary Hade System x Enablement IBM Linux Technology Center 503-578-4503 IBM T/L: 775-4503 garyhade@us.ibm.com http://www.ibm.com/linux/ltc --

Tested-by is really helpful for identifying potential testers when you change some part of the kernel. I use git history to identify people who are able/willing to test NUMA changes to the slab allocators that require a big ass NUMA box to trigger a bug, for example. Also, in some cases, testing a bug fix is not trivial and might require a lot of work that we should give credit for. --

Okay, I was a bit confused. Actually, both can delay for longer... msleep() in case of scheduling load, mdelay() in case of interrupt load... But the above was about hrtimer_nano*sleep*(), so that "how much latency we can tolarate" parameter would still be good. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

eh, I think you transposed mdelay with msleep? msleep() is the "it is okay to wait longer than I said" interface, not mdelay(). mdelay() has always been non-sleeping and exact (as much as the delay loop allows) Jeff --

Hi Hugh. If we are talking about the same things, its waiting for pages to be synced (wither written back or truncated) when inode is about to be destroyed. Thus reclaim can sleep wating for pages to be synced, which it is about to move somewhere itself. Deadlock. The same for writepage - if we drop inode there it can wait for pages to be synced, which inturn requires writeback, where we are sleeping already... -- Evgeniy Polyakov --

Well that is what Dave wants. I'd rather go the safe route for now and defer this until later. I think you are much more an expert on the filesystems and I/O paths than I am. So I'd rather take my hands of as soon as possible. --

Cool, I did not know that, probably because it is not exported :) -- Evgeniy Polyakov --

Ages and ages ago. I expect it was a deadlock thing. iput_final() can end up calling things like write_inode() which can want to do things like opening a transaction against filesystem A while already having one open against filesystem B. Which is both deadlockable and BUGable. Yes, it was specific to the direct-reclaim calling context. --

Too late for this time, but for next time, you can emulate an i2c device using the i2c-stub driver, that's very convenient when you want to test a change that affects i2c and don't have any physical device to test it. -- Jean Delvare --

Thanks for review, It's only boot-tested with i2c part as built-in by Glad to see that, thanks. Regards dave --

The version number (of the OS not just of the SMB/CIFS implementation, both of which are exchanged by client and server) has sometimes been useful in debugging problems that I and others and the Samba team look at (you can see it in wireshark/tcpdump traces, and it can be logged easily on either end as well). If containers are crazy enough to change the version number, not just the hostname, why don't we simply define a three line macro for retrieving this which is safe and put it in ...

Because thanks to the container patches it utsname fields other than hostname can actually change at runtime now and you'll get races looking at them. And probably not the output you want if someone in your container changes the kernel version to trick applications. --

This patch (as1100) replaces the core-kernel function call to utsname() in usb-storage with the UTS_RELEASE macro. It's used only for warning about extra unusual_devs entries. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> --- Index: usb-2.6/drivers/usb/storage/usb.c =================================================================== --- usb-2.6.orig/drivers/usb/storage/usb.c +++ usb-2.6/drivers/usb/storage/usb.c @@ -53,7 +53,7 @@ #include <linux/slab.h> #include ...

I agree - what was wrong with utsname->release ... it seems odd to statically build the kernel's version number into a module - it should be something we should be able to query (and it shouldn't change without reboot so accessing it is not racy). Access to other fields in the structure (nodename, domainname etc.) might need to be included in a macro but I didn't see one in utsname.h for this. --

It'll probably make some of them work and break others. It's pretty hard-coded in most of them that the flow is from 2.6.25 -> 2.6.26-{pre,rc}*; whether or not they permit a zero probably depends on if they know what is available or not (ketchup wouldn't be able to, for example, but the kernel.org incdiff robot *might* "just work".) -hpa --

and depends on DEBUG_FS ?? We shouldn't advertise this option unless the kernel can actually --- ~Randy --

On Wed, 21 May 2008 17:11:39 -0400 Ah, I see. My process has always been: cp arch/x86/configs/foo_defconfig .config make oldconfig make obvious decisions about new symbols, choose defaults if unknown diff -u arch/x86/configs/foo_defconfig .config figure out if any decisions or defaults are incorrect, change accordingly make oldconfig (more decisions if there are new symbols exposed) My build has broken again, which is why I'm inquiring about the status of this; I'm not going to bother ...

On Wed, May 21, 2008 at 04:47:03PM -0400, Andres Salomon wrote: > > 3) Implement newsymbolsconfig (any better name?) > > Shall list all new symbols and shall not write > > any config > > I'm not sure I see the point of #3. It's something we've had in Fedora kernels forever, because when rebasing to a new upstream version the process becomes make newsymbolsconfig take list of symbols, and make decisions on them make oldconfig without it, the process would be.. make ...

Back to this old subject... I'm having reports that this is not working... gcc is seeing the empty weak function and is optimizing it out before it gets a chance to link to the arch provided one. This would affect that and the other one next to it.. That seems pretty bad... it causes nasty crashes as we end up having no idea what the compiler decided to generate... I suppose we could keep the weak stubs out of the file where they are called but that sucks. ie. This is some form of ...

On Wed, 21 May 2008 15:44:41 -0400 istr that sticking an asm(""); in the weak function was a reliable workaround. If we are going to to that it should be via /* comment goes here */ #define gcc_screws_up_weak_stuff() asm("") but that approach didn't seem very popular. It's a _bit_ fragile I guess, but it's pretty easy to grep for missed workarounds. --

yup, gcc bug. Discussed recently on lkml, "Subject: Re: huge gcc 4.1.{0,1} __weak problem". I don't think anything ended up happening about it though. --

No because of this from fork.c:copy_process() /* * Process group and session signals need to be delivered to just the * parent before the fork or both the parent and the child after the * fork. Restart if a signal comes in before we add the new process to * it's process group. * A fatal signal pending means that current will exit, so the new * thread can't slip out of an OOM kill (or normal SIGKILL). */ ...

Sorry for late reply and thank you for your comment. I understood the mechanism that kill(-1, SIGKILL) can miss the tasks forked by init (and the thread group of the current process, because we don't also send the signal to them). If kill(-1, SIGKILL) finish before the forking init process does list_add_tail_rcu(p->tasks) in copy_process(), the process forked by init appears on the ->tasks list after that. Is that right? If so, I think this problem can happen without my patch. Because even ...

I suspect that something like you're proposing to do here will answer your needs, to "tell the kernel to not route IRQs to certain CPUs." I suspect that other folks will have some additional needs, that perhaps my idea of May 9, 2008: How about this. We add two files to each cpuset: irq_affinity_include # IRQs to direct to CPUs in this cpuset irq_affinity_exclude # IRQs -not- to direct to these CPUs where irq_affinity_exclude overrides ...

On Tue, 20 May 2008 18:14:58 -0700 \\ why don't you tell irqbalance instead? it'll make sure the irq stays out of the wind... --

That will be too late. By the time irqbalance sees that IRQ it may have already fired (possibly several times) on the "wrong" processor. Max --

I was worried about the case when we call try_to_free_buffers() again, it races with the current transaction commit again. Is it possible? I guess the question is whether it is possible to have buffers on the same page attached to different transaction. If so, I think we need to keep the journal state lock while retry try_to_free_buffers(), so that the For try_to_release_page(),we should wait only when (__GFP_WAIT & Thanks, patch v3 to follow. Mingming --

journal_try_to_free_buffers() could race with jbd commit transaction when the later is holding the buffer reference while waiting for the data buffer to flush to disk. If the caller of journal_try_to_free_buffers() request tries hard to release the buffers, it will treat the failure as error and return back to the caller. We have seen the directo IO failed due to this race. Some of the caller of releasepage() also expecting the buffer to be dropped when passed with GFP_KERNEL mask to the ...