As many of us now have a distribution which is based on a 2.6.32 kernel but are forced to update DRM to the version in 2.6.33 to obtain good graphics experience. In support of this I went ahead and created a tree on kernel.org[1] which brings together the two and which I will maintain following the upstream stable trees from Greg. This hopefully will not only be beneficial to us but also to all that are in the need of running this combination of code. -Stefan [1] ...

Ubi can be built into the kernel or be compiled as a kernel module. Further on the command line one can specify mtd devices to be attach to ubi while loading. In the current implementation the ubi driver refuses to load if one of the mtd devices cannot be attached. Consider: 1) ubi compiled into the kernel and 2) a mtd device specified on the command line and 3) this mtd device contains bogus data (for whatever reason). During init ubi tries to attach the mtd device is this fails the ...

Some devices need to know if the data is to be output or read, so add a data direction into the eeprom structure to tell the driver whether the data line should be driven. The user in this case is the Micrel KS8851 which has a direction control for the EEPROM data line and thus needs to know whether to drive it (writing) or to tristate it for receiving. Signed-off-by: Ben Dooks <ben@simtec.co.uk> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: Jean Delvare <khali@linux-fr.org> Cc: Linux Kernel ...

Of course. You are confirming what I wrote immediately below: Suspend blockers help resolve races. Note that this race has nothing to do with the _screen_ in particular -- exactly the same race occurs if you Let's say that it has nothing to do _specifically_ with the screen. _Any_ action you want to take in userspace is difficult to coordinate So at least my mental processes have remained consistent over the span of a year. Nice to know I haven't undergone a complete personality ...

This patch fixes the problem on my system. Does it work for you? I still think that disabling wakeup at the PCI or platform level should override the port wakeup flags, but apparently it doesn't. Alek, can you confirm that the changes in this patch are okay for the Moorestown EHCI controller? I had to guess at how to handle the HOSTPCx register settings. Alan Stern Index: usb-2.6/drivers/usb/host/ehci-hub.c =================================================================== --- ...

All the SST25L series flash parts have uniform erase sectors. Remove the extra MTD_DEBUG_LEVEL2 messages showing the eraseregions info since they could never be shown. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Andre Renaud <andre@bluewatersys.com> Cc: Ryan Mallon <ryan@bluewatersys.com> --- diff --git a/drivers/mtd/devices/sst25l.c b/drivers/mtd/devices/sst25l.c index fe17054..bcf040b 100644 --- ...

Hi Jens, After merging the block tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: fs/nilfs2/the_nilfs.c: In function 'nilfs_discard_segments': fs/nilfs2/the_nilfs.c:673: error: 'DISCARD_FL_BARRIER' undeclared (first use in this function) Caused by commit fbd9b09a177a481eda256447c881f014f29034fe ("blkdev: generalize flags for blkdev_issue_fn functions") interacting with commit e902ec9906e844f4613fa6190c6fa65f162dc86e ("nilfs2: issue discard request after cleaning ...

Hi Jens, Today's linux-next merge of the block tree got a conflict in fs/ext4/fsync.c between commit a68513a1c88248ee9167a25e32ee8164c3dde02b ("ext4: check missed return value in ext4_sync_file()") from the ext4 tree and commit fbd9b09a177a481eda256447c881f014f29034fe ("blkdev: generalize flags for blkdev_issue_fn functions") from the block tree. Just context changes. I fixed it up (see below) and can carry the fix as necessary. -- Cheers, Stephen Rothwell ...

Per document, for feature control MSR Bit 1 enables VMXON in SMX operation. If the bit is clear, execution of VMXON in SMX operation causes a general-protection exception. Bit 2 enables VMXON outside SMX operation. If the bit is clear, execution of VMXON outside SMX operation causes a general-protection exception. This patch is to enable this kind of check with SMX for VMXON in KVM. Signed-off-by: Shane Wang <shane.wang@intel.com> --- arch/x86/include/asm/msr-index.h | 5 ++-- ...

Thanks for the patch. When applied to 2.6.33 kernel, the ehci-fsl.c part fails but that does not matter. Asus P4P800-VM now suspends correctly even when the jumpers are set to 5V, both with and without USB device. Also device (un)plug does not wake up the system anymore. So the patch works fine. Yes, this wakeup seems to work differently on different systems. For example, Asus A7V8X-X [VIA] (which has these 5V/5VSB jumpers too) is not affected by this (it wakes up dead but that's another ...

Acked-by: Arnd Bergmann <arnd@arndb.de> --

Ensure that the flash device is in a quiescent state before rebooting. The implementation is closely modeled after the cfi_cmdset_0001 reboot notifier, commit 963a6fb0a0d336d0513083b7e4b5c3ff9d6d2061 . Signed-off-by: Kevin Cernekee <cernekee@gmail.com> --- drivers/mtd/chips/cfi_cmdset_0002.c | 56 +++++++++++++++++++++++++++++++++++ 1 files changed, 56 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index ...

This patch introduced a bug (together with a fix). I'm sorry that my "Linux Kernel Mailing List" filtering techniques are lacking and I missed it completely. Searching on google I can see it was hiding under "[GIT PULL] block/writeback bits for 2.6.34-rc". I have only seen it now, in git-commits-head ml. I wish filesystem related patches where CC to linux-fsdevel, and/or posted as individual patches, sigh. I'll post a fix as reply to this mail. Linus please submit. --

On Thu, Apr 29, 2010 at 2:23 AM, Stefan Bader Great stuff! Thanks for putting this up! Luis --

This pachset is based on Andrew's padata review. It applies agains the cryptodev-2.6 tree. Btw. how to route future padata patches upstream, still via cryptodev-2.6? Steffen --

This patch makes the padata cpu hotplug code dependend on CONFIG_HOTPLUG_CPU. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> --- kernel/padata.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/kernel/padata.c b/kernel/padata.c index 5b44d0f..1209a17 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -570,6 +570,7 @@ void padata_stop(struct padata_instance *pinst) } EXPORT_SYMBOL(padata_stop); +#ifdef CONFIG_HOTPLUG_CPU static ...

might_sleep() was placed before mutex_lock() in some places. We remove them because mutex_lock() does might_sleep() too. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> --- kernel/padata.c | 10 ---------- 1 files changed, 0 insertions(+), 10 deletions(-) diff --git a/kernel/padata.c b/kernel/padata.c index 1209a17..5fa6ba6 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -443,8 +443,6 @@ int padata_set_cpumask(struct padata_instance *pinst, struct parallel_data ...

yield was used to wait until all references of the internal control structure in use are dropped before it is freed. This patch implements padata_flush_queues which actively flushes the padata percpu queues in this case. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> --- kernel/padata.c | 33 +++++++++++++++++++++++++-------- 1 files changed, 25 insertions(+), 8 deletions(-) diff --git a/kernel/padata.c b/kernel/padata.c index 6d7ea48..ec6b8b7 100644 --- ...

Tim Gardner <tim.gardner@canonical.com> : Yes. I have just sent those for both 2.6.32-stable and 2.6.33-stable. -- Ueimor --

Hmm. A while ago I was complaining that an evil program that calls fsync() in a loop will send a continuous stream of write barriers to the hard disk. Ted theorized that it might be possible to set a flag in ext4_writepage and clear it in ext4_sync_file; if we happen to enter ext4_sync_file and the flag isn't set (meaning that nothing has been dirtied since the last fsync()) then we could skip issuing the barrier. Here's an experimental patch to do something sort of like that. From a ...

From: Rik van Riel <riel@redhat.com> Take all the locks for all the anon_vmas in anon_vma_lock, this properly excludes migration and the transparent hugepage code from VMA changes done by mmap/munmap/mprotect/expand_stack/etc... Unfortunately, this requires adding a new lock (mm->anon_vma_chain_lock), otherwise we have an unavoidable lock ordering conflict. This changes the locking rules for the "same_vma" list to be either mm->mmap_sem for write, or mm->mmap_sem for read plus the new ...

Hi Mel, did you see my proposed fix? I'm running with it applied, I'd be interested if you can test it. Surely it will also work for new anon-vma code in upstream, because at that point there's just 1 anon-vma and nothing else attached to the vma. http://git.kernel.org/?p=linux/kernel/git/andrea/aa.git;a=commit;h=6efa1dfa5152ef8d7f2... I think it's wrong to try to handle the race in rmap walk by making magic checks on vm_flags VM_GROWSDOWN|GROWSUP ...

Hi Greg, Today's linux-next merge of the tty tree got a conflict in include/linux/tty.h between commit 9b27105b4a44c54bf91ecd7d0315034ae75684f7 ("net-caif-driver: add CAIF serial driver (ldisc)") from the net tree and commit 39658c58ebb52fe7a3488fd520aa89c75721fd20 ("tty: n_gsm line discipline") from the tty tree. I used number 21 for the n_gsm line discipline (see below) and 30 for NR_LDISCS and can carry this fix as necessary. -- Cheers, Stephen Rothwell ...

Hi folks ! I'm writing some support for d-link dns323 rev C1 NAS. It has a fan that is controlled by some non-programmable PWM circuit. Basically, all I can do is tweak to GPIOs that controls the feed into the circuitry for the fans to be off, slow or fast. I don't know what the actual PWM values are for "slow" or "fast". I -might- be able to do some measurements but I can't promise it. Now I'm trying to do a simple hwmon driver for that in order to easy userspace support for these guys, ...

Hi Frédéric, Today's linux-next merge of the bkl-ioctl tree got a conflict in drivers/isdn/divert/divert_procfs.c between commit 64ef834551d7696f54553d7608eba80a5a800e77 ("procfs: Push down the bkl from ioctl") from the bkl-procfs tree and commit 5cc2443e44f810a21d1228ac9bf60b41536e5b9c ("isdn: Push down BKL into ioctl functions") from the bkl-ioctl tree. I used the version from the blk-procfs tree. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au

Frederic: did you miss one of my patches to fix the scsi compile problems? The following should have fixed the above: From 3605ca2d1b29511fe1c95b47c4c596f392797585 Mon Sep 17 00:00:00 2001 From: John Kacur <jkacur@redhat.com> Date: Tue, 27 Apr 2010 10:47:43 +0200 Subject: [PATCH 04/10] bkl: Fix missing inode tw_chrdev_ioctl due to bkl pushdown Cc: Arnd Bergmann <arnd@arndb.de>, Linus Torvalds <torvalds@linux-foundation.org>, Frederic Weisbecker <fweisbec@gmail.com>, Jan ...

Hi Frédéric, Today's linux-next merge of the bkl-ioctl tree got a conflict in drivers/char/i8k.c between commit 64ef834551d7696f54553d7608eba80a5a800e77 ("procfs: Push down the bkl from ioctl") from the bkl-procfs tree and commit 59ce88717d9d8af8cb14af3a0a505cafb692b482 ("drivers: Push down BKL into various drivers") from the bkl-ioctl tree. I used the version from the bkl-procfs tree for today. Can you guys please sort out these various bkl removal trees, please. -- Cheers, Stephen ...

Hi While testing kernel 2.6.34-rc5-git10 on an Acer Aspire One 110L netbook (Atom N270, i945GSE chipset, hyperthreading enabled and not configurable, BIOS 3309), I reproducably encounter the following oops while shutting down (manual transcription below): Pid: 2253, comm: halt Not Tainted 2.6.34-rc5-sidux-686 #1 /AOA110 EIP: 0060:[<c0121232>] EFLAGS: 00010202 CPU: 0 EIP is at apbt_cpuhp_notify+0x32/0x60 EAX: c0562e80 EBX: 01ca0000 ECX: 0000001c EDX: 0000001c ESI: 00000000 EDI: ...

Could you apply this patch and verify that it solves your problem: http://git.kernel.org/tip/ae7c9b70dcb4313ea3dbcc9a2f240dae6c2b50c0 -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

From: Arnaldo Carvalho de Melo <acme@redhat.com> Hi Ingo, Please consider pulling from: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 perf Now there are 7 patches in that repo. Regards, - Arnaldo Arnaldo Carvalho de Melo (2): perf symbols: Add machine helper routines perf test: Initial regression testing command tools/perf/Documentation/perf-test.txt | 22 +++ tools/perf/Makefile | 1 + tools/perf/builtin-kmem.c | ...

From: Arnaldo Carvalho de Melo <acme@redhat.com> First an example with the first internal test: [acme@doppio linux-2.6-tip]$ perf test 1: vmlinux symtab matches kallsyms: Ok So it run just one test, that is "vmlinux symtab matches kallsyms", and it was successful. If we run it in verbose mode, we'll see details about errors and extra warnings for non-fatal problems: [acme@doppio linux-2.6-tip]$ perf test -v 1: vmlinux symtab matches kallsyms: --- start --- Looking at the ...

I fixed that warning up. -- Jens Axboe --

Hi Ben, Indeed, that wouldn't fit. The nearest entry in the document is: pwm[1-*] Pulse width modulation fan control. Integer value in the range 0 to 255 RW 255 is max or 100%. In your case, the file would have only 3 possible values, with "off" mapping to 0, and "slow" and "fast" mapping to arbitrary positive values, like 64 and 192 or whatever you think is suitable. I understand that in your case, you don't really control the PWM output directly, but we do not have any ...

virtio-net bounces buffer allocations off to a thread if it can't allocate buffers from the atomic pool. However, if posting buffers still requires atomic buffers, this is unlikely to succeed. Fix by passing in the proper gfp_t parameter. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> --- drivers/net/virtio_net.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 91738d8..fca44b2 100644 --- ...

[Empty message]

It's kind of a joint effort. I think it's probably mine by a fairly And don't make up Signed-off-by lines. Although you can have that one of mine now you've got it (since you've actually tested it). -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --

Hi all, Changes since 20100428: Dropped trees: tmio-mmc (long unresolved conflicts and unable to fetch) hwlat (at the maintainer's request) My fixes tree contains: a patch for a pktcdvd build error from Arnd Bergmann The v9fs tree gained a conflict against Linus' tree. The v4l-dvb tree still has its build failure, so I used the version from next-20100409. The kvm tree lost its build failure. The mtd tree gained a conflict against Linus' tree. The block tree lost its ...

Hi Grant, After merging the driver-core.current tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/base/firmware_class.c: In function 'release_firmware': drivers/base/firmware_class.c:597: warning: passing argument 1 of 'firmware_free_data' discards qualifiers from pointer target type drivers/base/firmware_class.c:133: note: expected 'struct firmware *' but argument is of type 'const struct firmware *' Introduced by commit ...

And it's now pushed out in my tree. thanks, greg k-h --

Here's a business list package on sale this week only: Business List Silver Package American Business Email List - 2 million emails various businesses Financial Planners Database - 148,857 records all with emails Finance and Money Professionals Database - 116,568 records all with emails All complete lists above: $276 There are more packages and not just for business. we also have healthcare, consumers and more. Contact me here for more info or to get samples: ...

Hi I can confirm that this patch applied on top of 2.6.34-rc5-git10 fixes my shutdown problem; no further oops has shown within 20+ shutdowns so far, while it was 100% reproducably before. Sorry that I didn't notice https://bugzilla.kernel.org/show_bug.cgi?id=15786 before. [...] Thanks a lot Stefan Lippers-Hollmann --

The patch: add bdi backing to mount session (b3d0ab7e60d1865bb6f6a79a77aaba22f2543236) Has a bug in the placement of the bdi member at struct exofs_sb_info. The layout member must be kept last. Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> --- fs/exofs/exofs.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/exofs/exofs.h b/fs/exofs/exofs.h index 5437327..22721b2 100644 --- a/fs/exofs/exofs.h +++ b/fs/exofs/exofs.h @@ -85,6 +85,7 @@ struct ...

Hi Jens, Today's linux-next merge of the block tree got a conflict in fs/block_dev.c between commit b8af67e2681c693a21f3933e3bdfce4cf66596d3 ("fs/block_dev.c: fix performance regression in O_DIRECT|O_SYNC writes to block devices") from Linus' tree and commit fbd9b09a177a481eda256447c881f014f29034fe ("blkdev: generalize flags for blkdev_issue_fn functions") from the block tree. I fixed it up (see below) and can carry the fix for a while. -- Cheers, Stephen Rothwell ...

On Thu, 29 Apr 2010 14:36:36 +0200 That's OK by me. I'll often grab stuff (especially if I was cc'ed on it) and will drop it again if I see a subsystem maintainer took it. People use this to delegate the resend-to-sleepy-maintainer job to myself. Herbert is less sleepy than many ;) --

Hi David, Today's linux-next merge of the mtd tree got a conflict in drivers/mtd/mtdcore.c between commit a33eb6b91034c95b9b08576f68be170f995b2c7d ("Move mtd_bdi_*mappable to mtdcore.c") from Linus' tree and commit b520e412faaaad35641aeedd6059179f9f1b393c ("mtd: Replace static array of devices with an idr structure") from the mtd tree. Just overlapping additions. I fixed it up (see below) and can carry the fix for a while. -- Cheers, Stephen Rothwell ...

I'm being bit by an extremely troublesome regression on HEAD (when the kernel was built, at least) of Linus' tree. The symptoms are that the kernel boots, blinks the cursor a few times, then reboots without showing any messages or switching to the uvesafb mode specified on the commandline. Trying to boot the kernel in qemu causes it to hang with a blank screen and a non-blinking cursor, not even printing anything to a serial terminal. .config is below. I'm on an MSI-1651-ID2 laptop, ...

Uh oh. 2.6.33 compiled with this config (taking all defaults for make oldconfig) doesn't boot either. Totally lost now. --

I'm being bit by an extremely troublesome regression on HEAD (when the kernel was built, at least) of Linus' tree. The symptoms are that the kernel boots, blinks the cursor a few times, then reboots without showing any messages or switching to the uvesafb mode specified on the commandline. Trying to boot the kernel in qemu causes it to hang with a blank screen and a non-blinking cursor, not even printing anything to a serial terminal. .config is below. I'm on an MSI-1651-ID2 laptop, core2duo ...

Oddly, I just fixed this like 4 hours ago .. Daniel --

From: Peter Huewe <peterhuewe@gmx.de> This patch fixes the prototype of native_cpu_disable if CONFIG_HOTPLUG_CPU is not set, and thus fixes a build failure[1] References: [1] http://kisskb.ellerman.id.au/kisskb/buildresult/2536296/ Signed-off-by: Peter Huewe <peterhuewe@gmx.de> --- KernelVersion: linux-next-20100429 arch/sh/kernel/smp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/sh/kernel/smp.c b/arch/sh/kernel/smp.c index 86cd6f9..509b36b ...

From: Peter Huewe <peterhuewe@gmx.de> This patch adds a conditional for CONFIG_MSM_DEBUG_UART to prevent a build failure[1], this is done the same way as for every board in mach-msm. References: [1] http://kisskb.ellerman.id.au/kisskb/buildresult/2448102/ Signed-off-by: Peter Huewe <peterhuewe@gmx.de> --- KernelVersion: linux-next-20100429 arch/arm/mach-msm/board-trout.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-msm/board-trout.c ...

From: Peter Huewe <peterhuewe@gmx.de> This patch adds a define for ARM_PMU_DEVICE_CPU which seemed to be missing/undefined and caused some build failures [1-4]. I defined ARM_PMU_DEVICE_CPU = -1 as stated in Documentation/driver_model/platform.txt to indicate there is only one. I'm _not_ sure if this is correct, but due to the static nature of the define I assume it is. References: [1] http://kisskb.ellerman.id.au/kisskb/buildresult/2535843/ [2] ...

Hi Jamie, Thanks for CC'ing me on this. I submitted the series to Russell's patch system on 9 April. However, as you know, he's currently without an internet connection and the patch system has gone offline. He applied some of the series before he lost connectivity, so I expect he'll look at the others when he's back [although I imagine there are lots of other patches in the same situation]. Peter: if you're interested, the patch series I sent to the ARM Linux list is archived ...

On Thu, 29 Apr 2010 17:32:10 -0400 It Works For Me. Send .config, please? --

Dies trying to compile mm/slab.c because something screwed the pooch with the definition of numa_mem_id(). My bets are on numa-slab-use-numa_mem_id-for-slab-local-memory-node.patch CC mm/slab.o mm/slab.c: In function 'kmem_cache_init': mm/slab.c:1506: error: 'numa_node' undeclared (first use in this function) mm/slab.c:1506: error: (Each undeclared identifier is reported only once mm/slab.c:1506: error: for each function it appears in.) mm/slab.c:1506: warning: type defaults to 'int' ...

A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top Then say that :) Isn't Intel the "vendor" here? If not, why not have them directly interact with us, you do not want to be put into the middle, it only slows things down for everyone and is not how Linux kernel development Yes, that TODO list is quite large already, fix up all of those and then ask for more review please. Reviewing code you know needs lots of work isn't all that nice ...

Hi Greg, Mark asked me to post the patches for him. These patches are on 2.6.34 with the 0415 next patch. We were hoping to get more comments from people to add to TODO list, so that the vendor can plan their work to fix the issues and make the driver more acceptable to the community. The driver already went through some clean-up, but much more work is still needed. Thanks, --Eugene -----Original Message----- From: Greg KH [mailto:greg@kroah.com] Sent: Wednesday, April 28, 2010 8:36 ...

<snip> Here's your list of what needs to be done to get this code merged, why have you ignored it when asking us what we thought needed to be done. Isn't this a good enough list of things left to complete? again, totally confused, greg k-h --

On Thu, 29 Apr 2010 19:16:24 +0200 I think you're right, yes. (As noted above, the camera driver isn't quite ready for merging yet - but I can't swear I would have caught That's a little harder - the platform device is the means by which the camera and the core communicate. I guess I could add a general "I'm a via-core subdev and I'm here now" exported function in the core, but I'm not sure that would be better than just having the platform dev be there. But it definitely shouldn't be ...

Testing here, loading path seems to work fine (console mode) as well as mode switching with fbset, but rmmod viafb fails with below trace. Going to have a look what can be the cause, looks like it's when unregistering GPIOs. Bruno [ 1727.041074] ------------[ cut here ]------------ [ 1727.041232] WARNING: at /usr/src/linux-2.6-git/kernel/softirq.c:143 local_bh_enable+0x58/0x80() [ 1727.041391] Hardware name: CX700+W697HG [ 1727.041495] Modules linked in: e_powersaver via_cputemp ...

Thomas: this should fix the accounting for the FUNCTION_TRACER that was incorrect in the previous version of the patch. Thanks From 93805bbedd83bf34466e738a6addccb44735ed20 Mon Sep 17 00:00:00 2001 From: John Kacur <jkacur@redhat.com> Date: Wed, 28 Apr 2010 21:25:14 +0200 Subject: [PATCH] rt: Remove irrelevant CONFIGS from reminder block. Cc: Thomas Gleixner <tglx@linutronix.de>, Steven Rostedt <rostedt@goodmis.org>, Clark Williams <williams@redhat.com> - remove CONFIGS that do ...

Success!!! I feel _really_ stupid about the cause of the problem.... I hadn't set up the interrupt mapping of the serial ports in my board initialisation routines in U-Boot. Once I mapped IRQ4 to UART0 it all sprang to life ;) Big thanks to everyone for helping and a big thanks to all the linux and GNU developers for creating such a wonderful 'toy' ;) Graeme --

Some workloads that create a large number of small files tend to assign too many pages to node 0 (multi-node systems). Part of the reason is that the rotor (in cpuset_mem_spread_node()) used to assign nodes starts at node 0 for newly created tasks. This patch changes the rotor to be initialized to a random node number of the cpuset. NOTE: this patch is on TOP of the previous patch: [PATCH] - New round-robin rotor for SLAB ...

We've seen this on several workloads. None were contrived - just standard benchmarks that use tasks/scripts to create a large number of files. I have not looked in detail at the tasks/scripts. It seemed desirable to have each new task start with a random value in the rotor. That would provide I was concerned that inherit-from-parant might not be effective if the files were created using a single task that forked child processes to create Agree. Not sure why I did it that way. Fixed in next ...

It's unrelated to TDP, same issue with shadow. I think the calculation is correct. For example the 4th spte for a level=2 page will yield -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

Fine by me. David --

Hello, That's relieving. It sure is an annoyance for anyone who's not on latin-1. It's an outright invalid character and as you've seen it's not easy to even send a patch changing it. IMHO, if it were something which couldn't be avoided at all, encoding it using utf-8 would be much more appropriate. Thanks. -- tejun --

I tried to reply to this earlier but I think my reply vanished due to a mail problem. I don't want "(C)" in there because our lawyers tell me that it is legally meaningless, but "Copyright" on its own is good enough. So I would prefer that you either remove the (C) entirely or convert the copyright symbol to proper UTF-8 (0xc2 0xa9). Thanks, Paul. --

Probably this could get changed to just "Reported-by" but I'm happy to Acked-by: Dan Carpenter <error27@gmail.com> regards, dan carpenter --

On second thought, this only makes a difference if both conditions are true. If we are constantly re-queuing the work but it is not stuck, either method will show the debug message, so I used Oleg's suggestion. -- Arve Hjønnevåg --

Freezable workqueues have to be singlethread or else there will be unfixable races, so you can safely assume things will stay as they are in this respect. --

OK, great. Rafael --

Export keventd_wq. Otherwise, any helper on top of queue_work() has to be copy-and-pasted to create the version which uses keventd_wq. Note: we can do more cleanups with this change and kill EXPORT_SYMBOLs, almost any function which currently uses keventd_wq can become the trivial inline. Signed-off-by: Oleg Nesterov <oleg@redhat.com> --- include/linux/workqueue.h | 1 + kernel/workqueue.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) --- ...

Confused. Rafael, do you mean you dislike this change now? I don't really care, this change is trivial. But to me it makes more sense to push the trivial/simple changes ahead. Unless they really complicate the maintainging of the pending cmwq changes. Hmm... Speaking about keventd_wq, I just noticed flush_delayed_work() needs the fix: --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -774,7 +774,7 @@ void flush_delayed_work(struct delayed_w { if ...

I've written the driver code which implements a zero-copy DMA char device. It has aio_read() and aio_write() methods which return -EIOCBQUEUED after the successful preparation of the buffers described by kiocb and posting it to the descriptor chain. When the descriptors are processed, the DMA engine raises the interrupt and the cleanup work is done in the handler, including aio_complete() for the completed kiocbs. This works fine, however, there is a problem with canceling the queued ...

This patch makes things simple. So I like this. Actually, I wanted this all-at-once locks approach. But I was worried about that how the patch affects AIM 7 workload which is cause of anon_vma_chain about scalability by Rik. But now Rik himself is sending the patch. So I assume the patch couldn't decrease scalability of the workload heavily. Let's wait result of test if Rik doesn't have a problem of AIM7. -- Kind regards, Minchan Kim --

Yes. I understand it. When you tried anon_vma_chain patches as I pointed out, what I have a concern is parent's vma not child's one. The vma of parent still has N anon_vma. AFAIR, you said it's trade-off and would be good than old at least. I agreed. But I just want to remind you because this makes worse. :) The corner case is that we have to hold locks of N. Do I miss something? Really, Can't we ignore that case latency although this happen infrequently? I am not against this patch. I ...

In vma_adjust(), what prevents something like rmap_map seeing partial updates while the following lines execute? vma->vm_start = start; vma->vm_end = end; vma->vm_pgoff = pgoff; if (adjust_next) { next->vm_start += adjust_next << PAGE_SHIFT; next->vm_pgoff += adjust_next; } They would appear to happen outside the lock, even with this patch. The -- Mel Gorman Part-time Phd Student Linux ...

me/ slaps self. It's about height of tree and I can't imagine high height of scenario.(fork->fork->fork->...->fork) So as Rik pointed out, It's a not big overhead about latency latency, at least. I think. I supports this approach. -- Kind regards, Minchan Kim --

This part does it. :) ---- @@ -578,6 +578,7 @@ again: remove_next = 1 + (end > next->vm_end); } } + anon_vma_lock(vma, &mm->mmap_sem); if (root) { flush_dcache_mmap_lock(mapping); vma_prio_tree_remove(vma, root); @@ -599,6 +600,7 @@ again: remove_next = 1 + (end > next->vm_end); vma_prio_tree_insert(vma, root); ...

On Wed, Apr 28, 2010 at 11:35:42PM -0700, john stultz wrote: | On Tue, 2010-04-27 at 22:53 +0200, Thomas Gleixner wrote: | > On Tue, 27 Apr 2010, Luis Claudio R. Goncalves wrote: | > | > CC'ed John | > | > > Hello! | > > | > > I see this warning during system boot and it hangs while loading X and even | > > though I can change from one VT to another (ctrl+alt+F<num>) no keys | > > pressed seem to have any effect. | > > | > > ------------[ cut here ]------------ | > > WARNING: at ...

On Thu, Apr 29, 2010 at 10:15 AM, Phil Carmody Thomas, I confirm that 2.6.33.3-rt15 worked fine, reboot/umount will not oops. Thanks, Xianghua --

Now that video_ioctl2() got the bkl pushed down, update its users to use .unlocked_ioctl instead of ioctl. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- drivers/media/common/saa7146_fops.c | 2 +- drivers/media/radio/dsbr100.c | 2 +- drivers/media/radio/radio-aimslab.c | 2 +- drivers/media/radio/radio-aztech.c | 2 +- drivers/media/radio/radio-cadet.c | 2 +- ...

These are the last remaining v4l drivers that implement the ioctl callback. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- drivers/media/video/bw-qcam.c | 11 ++++++++- drivers/media/video/c-qcam.c | 11 ++++++++- drivers/media/video/cpia.c | 11 ++++++++- drivers/media/video/cpia2/cpia2_v4l.c | 11 ++++++++- drivers/media/video/et61x251/et61x251_core.c | 27 +++++++++++++++++++------ drivers/media/video/ov511.c ...

Hi, Linus suggested to rename struct v4l2_file_operations::ioctl into bkl_ioctl to eventually get something greppable and make its background explicit. While at it I thought it could be a good idea to just pushdown the bkl to every v4l drivers that have an .ioctl, so that we actually remove struct v4l2_file_operations::ioctl for good. It passed make allyesconfig on sparc. Please tell me what you think. Thanks. Frederic Weisbecker (5): v4l: Pushdown bkl into video_ioctl2 ...

Note that you can completely skip the step of a v4l2-dev global mutex with Frederic's patch. This is the only use of the BKL in the common v4l2 code as far as I can tell, so instead of introducing yet another global lock, you can go straight to stage 4 and look at each driver separately, possibly introducing a per driver lock. Arnd --

Also with 2.6.32.12. I'm wondering if there's any kernel that works with the X201. At least for the X200, there have been some. Cheers, Nico -- New PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 Please resign, if you signed 9885188C or 8D0E27A4. Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ...

I'm using a kernel source tree with your 12 patches applied. Should that be OK? I don't see any of the hidden (no prompt string) symbols from arch/x86/Kconfig displayed. Or maybe they have just moved, but I can't -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

Well, I'm just thinking of a way to make working on virtio-net less painful. Maybe you could just put a copy of the two patches above on your tree? -- MST --

> > + "Take particularly attention when using the \"patch\" mode\n"\ > > particular Actually, "take particular attention" is not particularly grammatical. I might phrase this as Be especially careful when using the "patch" mode to review the patch you are about to submit. - R. -- Roland Dreier <rolandd@cisco.com> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --

I'm a little confused by your example, but perhaps you are describing what we already have. All syscall_entrys have the same class, and all syscall_exits have their own too. What each syscall has separate is a meta-data, which is unique to syscalls, and normal TRACE_EVENT()s do not have them. It is put in the call->private field. So what we have is: struct ftrace_event_class event_class_syscall_enter; This handles the printing of most of the data. What it does not cover is how to ...

Actually, I'm not sure what you want to check. What is not checked is the prototype that is created, to the prototype that is passed to the tracepoint_probe_register. Other parts are still checked. If you mis-match the args with the parameters, there are still places that the compiler will flag it. There really is not much less protection here than there was before. Instead of calling register_trace_##name that is created for each tracepoint, we now call the tracepoint_probe_register() ...

I fear about "subtly" broken things, where trace data could end up being incorrectly typed and/or corrupted. I think this BUILD_BUG_ON() will become very useful. Thanks, -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com --

The problem is, the cast is now performed in a C file for all events. There's no way to know what to cast it to there. This is out of the automation of the macro. We use to have the cast check by creating code that would create the "register_trace_##call", and the typecheck was doing by passing the data to this function. But we removed this code out of the per event, it was adding lots of text footprint, and moved it to one single function that handles all events. It is just expected that the ...

err.. forget about that. We only need to modify the callback to take the extra argument into acount, not DECLARE_TRACE(). Thanks, -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com --

Hi, This is my first post to the group, please excuse me, If I unknowingly miss to follow writing ethics. Proposal/Need: I was working on providing accurate process usage support, and writing a kernel module, I configured cpu-core-unhalted-event and configured LVT (local vector table) with NMI (non-maskable interrupt), and surprisingly Oprofile stopped working, Then I realized, that set_nmi_call back just overwrites nmi_callback function pointer. My proposal/idea/thinking is; have a ...

This is already in the linux-next tree from someone else :( thanks, greg k-h --

This solution is what now we can think of to implement zero-copy. Some modifications are made to net core to try to avoid network device driver changes. The major change is to __alloc_skb(), in which we added a dev parameter to indicate whether the device will DMA to/from guest/user buffer which is pointed by host skb->data. We also modify skb_release_data() and skb_reserve(). We made it now works with ixgbe driver with PS mode disabled, and got some performance data with it. using ...

Most likely you need to disable "Optimize for size", under "General setup" in the main menu to make it appear. But it could also be one of the other dependencies; check the "Depends on" line of KMEMCHECK when you do the search. Vegard --

MPOL_F_STATIC_NODES and MPOL_F_RELATIVE_NODES allow you to adjust the behavior of the rebind: the former requires specific nodes to be assigned to the mempolicy and could suppress the rebind completely, if necessary; the latter ensures the mempolicy nodemask has a certain weight as nodes are assigned in a round-robin manner. The behavior that you're referring to is provided via MPOL_F_RELATIVE_NODES, which guarantees whatever weight is passed via set_mempolicy() will be preserved when ...

Hi Pavel -- The whole concept of RAM that _might_ be available to the kernel and is _not_ directly addressable by the kernel takes some thinking to wrap your mind around, but I assure you there are very good use cases for it. RAM owned and managed by a hypervisor (using controls unknowable to the kernel) is one example; this is Transcendent Memory. RAM which has been compressed is another example; Nitin is working on this using the frontswap approach because of some issues that arise with ...

The concern is not with the hypervisor, but with Linux. More external I'm convinced it's useful. The API is so close to a block device (read/write with key/value vs read/write with sector/value) that we should make the effort not to introduce a new API. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

So... how much slower is swapping to RAM over current interface when compared to proposed interface, and how much is that slower than just using the memory directly? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Commit-ID: 47f9fe26299ae022ac1e3fa12e7e73def62b7898 Gitweb: http://git.kernel.org/tip/47f9fe26299ae022ac1e3fa12e7e73def62b7898 Author: Jan Beulich <JBeulich@novell.com> AuthorDate: Wed, 21 Apr 2010 16:19:57 +0100 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Wed, 28 Apr 2010 17:25:47 -0700 x86-64: Don't export init_level4_pgt It's not used by any module, and i386 (as well as some other arches) also doesn't export its equivalent (swapper_pg_dir). Signed-off-by: Jan ...

We probably could use something like this for the alternatives and exceptions tables, too... -hpa --

Commit-ID: 6fc108a08dcddf8f9113cc7102ddaacf7ed37a6b Gitweb: http://git.kernel.org/tip/6fc108a08dcddf8f9113cc7102ddaacf7ed37a6b Author: Jan Beulich <JBeulich@novell.com> AuthorDate: Wed, 21 Apr 2010 15:23:44 +0100 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Wed, 28 Apr 2010 17:25:53 -0700 x86: Clean up arch/x86/Kconfig* No functional change intended. Signed-off-by: Jan Beulich <jbeulich@novell.com> LKML-Reference: ...

Of course, just send it. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) --

On Tue, 20 Apr 2010 12:41:53 +1000 Bug. I suggest that what you do here is remove the local `nr_to_write' from write_cache_pages() and go back to directly using wbc->nr_to_write within the loop. And thus we restore the convention that if the fs writes back more than a single page, it subtracts (nr_written - 1) from wbc->nr_to_write. --

I suspect that without mmap and (to a lesser extent) write-combining, --

There are some suspend changes in .34 that may cause problems to happen for people, so I'm not sure if it's actually a good idea to introduce one more of them after -rc5. Also removing the boot option can easily wait until .36 IMHO. Rafael --

I initialized it to 0 to remove a compiler warning; I can put more Thanks for the feedback. I'll have the updated patches for review soon. -PJ --

So "register" would just assign the pointer, and "unregister" would make sure to NULL the mask pointer out. I like it. It'll sure clean things Thanks for the additional inputs. Patches coming soon. -PJ --

Yep, that'd be like the set_irq_chip() function. Just assign the pointer under desc->lock. Thanks, tglx --

I've done a new bisection for this issue (with cold boots instead of reboots) and now end up in the following merge: commit 94468080220162f74dc6ce5c3e95e5fec8022902 Merge: fb7b096 137ee2f Author: Linus Torvalds <torvalds@linux-foundation.org> Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6 Unfortunately I cannot bisect into that merge as I get a NULL pointer bug after typing the passphrase for my encrypted partition. I suspect one of the following ...

I agree that is prettiest, and copup at open for write makes it easier. But some applications issue mmap(MAP_PRIVATE) after open(O_RDWR), for example modprobe(8). In this case, every kernel module will be copied-up and it must be a waste of time and space. And I guess this is one reason why other implementation took the approach of copyup at write. At the same time, I guess this issue may be less important since other parts are pretty enough. J. R. Okajima --

I haven't looked at unionfs in a long time. Can you say something On a high level I don't see a problem, the parent of every dentry can be found through ->d_parent. One issue is having to duplicate some locking and other stuff around vfs_whatever() calls. But that could be fixed by exporting suitable helpers from the VFS. Other than that I don't see any fundamental issues with union filesystems (except that they seem to grow too many features to be maintainable). Thanks, Miklos --

your right!! (I've been putting off filling a bug only to really see if I can do this,but the more I look into it the more daunting it becomes). as for the issue, I was thinking in the area of a dmi blacklist or something to where proc_mkdir etc.. will just make the file "online" to trick the kernel and any other mechanism reading those files. but first things first, I'll file a bug. Justin P. Mattock --

Hi, Your latest patch has now been run though the GFS2 tests which originally triggered my investigation. It seems to solve the problem completely. Maybe thanks for your efforts in helping us find and fix the problem. The next question is what remains to be done in order to get the patch into a form suitable for upstream merge? Steve. --

Hm, how about just dropping everything? I don't think we need the __cold here then, right? thanks, greg k-h --

Peter, Did you manage to get anywhere on this capacity issue? Mikey --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Holding down the power button for 5 seconds has no audible or visible effects, but does indeed properly shut it down. Closing or opening the lid afterwards does not cause a phantom power-up. A short push of the power button seems to start the machine up normally (from a cold boot; just like when the lid is closed/opened after a linux I don't have this file in my /proc filesystem, sorry. Regards, - -- Tony Vroon UNIX systems ...

I'm sorry for being late. this is second patch that your concern is solved. Please review this patch. Thank you. Best Regards, InKi Dae.

Commit-ID: b701a47ba48b698976fb2fe05fb285b0edc1d26a Gitweb: http://git.kernel.org/tip/b701a47ba48b698976fb2fe05fb285b0edc1d26a Author: H. Peter Anvin <hpa@zytor.com> AuthorDate: Thu, 29 Apr 2010 16:03:57 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Thu, 29 Apr 2010 16:08:54 -0700 x86: Fix LOCK_PREFIX_HERE for uniprocessor build Checkin b3ac891b67bd4b1fc728d1c784cad1212dea433d: x86: Add support for lock prefix in alternatives ... did not define LOCK_PREFIX_HERE in ...

Hi! Okay, maybe this is better fix for the regression? Simplify irq wakeup code, and fix ugly warning during resume on spitz as a result. Signed-off-by: Pavel Machek <pavel@ucw.cz> --- ./drivers/input/keyboard/pxa27x_keypad.c 2010-04-15 07:50:34.000000000 +0200 +++ ./drivers/input/keyboard/pxa27x_keypad.c 2010-04-27 15:38:02.000000000 +0200 @@ -33,6 +33,8 @@ #include <mach/hardware.h> #include <mach/pxa27x_keypad.h> +#include <mach/mfp-pxa2xx.h> + /* * Keypad Controller ...