1) We changes lots of things to use "__packed" instead of "__attribute__((packed))" but this doesn't work out so well in user exported headers since the __packed define comes from compiler.h The easiest way to fix this regression is to revert this transformation in user visible headers. Fix from Changli Gao. 2) RDS leaks kernel memory, also transmit and statistic gathering race fixes in irda, qlnic, and netxen. All from Eric Dumazet. 3) Fix lockdep spew in netxen, from ...

Exactly. And also because if the device is in low-power mode then its parent might be in low-power too, meaning that we would have to wait for both the parent and the device to return to full power before sending the request. The PM framework is set up so that power-state changes are always done in process context -- meaning in this case that a workqueue would be needed. The PM core has a special workqueue for just this purpose. But obviously a prep function can't sit around and wait ...

Commit-ID: 9863c90f682fba34cdc26c3437e8c00da6c83fa4 Gitweb: http://git.kernel.org/tip/9863c90f682fba34cdc26c3437e8c00da6c83fa4 Author: Alok Kataria <akataria@vmware.com> AuthorDate: Mon, 23 Aug 2010 14:49:11 -0700 Committer: H. Peter Anvin <hpa@linux.intel.com> CommitDate: Mon, 23 Aug 2010 15:18:50 -0700 x86, vmware: Remove deprecated VMI kernel support With the recent innovations in CPU hardware acceleration technologies from Intel and AMD, VMware ran a few experiments to compare ...

We never use the "ret" value from this assignment, and also PTR_ERR(NULL) is zero. I looked at it and this driver is designed to accept a NULL value for "ac_draw". So there isn't a bug in the original code and we can just remove this confusing assignment. Signed-off-by: Dan Carpenter <error27@gmail.com> diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c index 69f8aa3..63a6a4d 100644 --- a/drivers/power/pda_power.c +++ b/drivers/power/pda_power.c @@ -279,7 +279,6 @@ static ...

for 1. x2apic preenabled system 2. first kernel have x2apic enabled, and try to boot second kernel with "nox2apic" Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/include/asm/apic.h | 6 ++++ arch/x86/include/asm/apicdef.h | 1 arch/x86/kernel/acpi/boot.c | 10 ++++++- arch/x86/kernel/apic/apic.c | 54 ++++++++++++++++++++++++++++++++--------- arch/x86/mm/srat_64.c | 12 ++++++++- 5 files changed, 69 insertions(+), 14 deletions(-) Index: ...

When the initialization code in hpet founds a memory resource and does not found IRQ, it does not unmap the memory resource previously mapped. There are buggy BIOSes which report resources exactly like this and what is worse the memory region bases point to normal RAM. This normally would not matter since the space is not touched. But when PAT is turned on, ioremap causes the page to be uncached and sets this bit in page->flags. Then when the page is about to be used by the allocator, it ...

ACPI batteries can report in units of either current or energy. Right now we expose the current_now file even if the battery is reporting energy units, resulting in a file that should contain mA instead containing mW. Don't expose this value unless the battery is reporting current. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Arjan van de Ven <arjan@linux.intel.com> --- drivers/acpi/battery.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git ...

This needs devpts_kill_index() to reverse the successful devpts_new_index(), so I think it should be "goto out" and not "goto out1". --

Add the 'gpiomux' api, which addresses the following shortcomings of existing tlmm api: - gpio power-collapse, which is managed by a peripheral processor on other targets, must be managed by the application processor on the 8x60. - The enable/disable flag of the legacy gpio_tlmm_config api is not applicable on the 8x60, and causes confusion. - The gpio 'direction' bits are meaningless for all func_sel configurations except for generic-gpio mode (func_sel 0), in which case the ...

Change deprecated gpio_tlmm_config calls to gpiomux calls. Signed-off-by: Gregory Bean <gbean@codeaurora.org> --- arch/arm/mach-msm/board-msm7x30.c | 20 -------------------- arch/arm/mach-msm/gpiomux-7x30.c | 21 ++++++++++++++++++++- 2 files changed, 20 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-msm/board-msm7x30.c b/arch/arm/mach-msm/board-msm7x30.c index e329819..74abb74 100644 --- a/arch/arm/mach-msm/board-msm7x30.c +++ b/arch/arm/mach-msm/board-msm7x30.c @@ ...

Jens: I want to implement runtime power management for the SCSI sd driver. The idea is that the device should automatically be suspended after a certain amount of time spent idle. The basic outline is simple enough. If the device is in low power when a request arrives, delay handling the request until the device can be brought back to high power. When a request completes and the request queue is empty, schedule a runtime-suspend for the appropriate time in the future. The difficulty ...

Using continuation lines often introduces undesired whitespace. Fix the misuses. Signed-off-by: Joe Perches <joe@perches.com> --- drivers/serial/bfin_5xx.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/serial/bfin_5xx.c b/drivers/serial/bfin_5xx.c index a9eff2b..4e38f99 100644 --- a/drivers/serial/bfin_5xx.c +++ b/drivers/serial/bfin_5xx.c @@ -734,8 +734,8 @@ static int bfin_serial_startup(struct uart_port *port) IRQF_TRIGGER_RISING | ...

Unfortunately some of the hardware PID belonging to auto-install CDROM (AICD) of Novatel modems found their way into the option module. This causes the AICD to be treated as a modem in stead of a disk. Since the modem ports do not appear until after the AICD is ejected, this essentially disables the modem. After a couple of minutes the AICD should auto-eject, but it is just too long a wait. The frequency of the failure seems to depend on both the hardware and the linux distribution. Below is a ...

Don't ask how ACPI_TOSHIBA got enabled on in desktop system's .config - I don't know. But it has silently been there until I tried 2.6.36-rc2, where it broke the build because I don't have LED support turned on. Attached patch fixes things up. (I had to change BACKLIGHT_CLASS_DEVICE to "depends" because otherwise I get unsightly core dumps out of scripts/kconfig/conf). jon -- toshiba: make sure we pull in LED support The Toshiba extras driver uses the LED module, so make sure we have ...

Currently, the platform_bus allows customization of several of the busses dev_pm_ops methods by using weak symbols so that platform code can override them. The weak-symbol approach is not scalable when wanting to support multiple platforms in a single kernel binary. Instead, provide __init methods for platform code to customize the dev_pm_ops methods at runtime. NOTE: after these dynamic methods are merged, the weak symbols should be removed from drivers/base/platform.c. AFAIK, this ...

On Tue, 24 Aug 2010 00:37:52 +0100 That doesn't seem to give me any output at all. One thing I noticed, though, is that I occasionally get something like: Aug 23 17:43:14 bike kernel: [ 142.920185] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 51, available = 28. They seem to come in threes, for whatever that's worth. Thanks, jon --

Sigh, that sounds like I screwed the patch up instead. Hmm, probably bailing out of the ioctl before hitting the newline. drm.debug=0x4 should print the right information for this bug. -- Chris Wilson, Intel Open Source Technology Centre --

On Mon, 23 Aug 2010 23:36:55 +0100 OK, I tried it, but neither warning triggers. Don't know if it helps or not, but I tried booting with drm.debug=0x05. The result was truly vast amounts of stuff like this: Aug 23 17:20:59 bike kernel: m:drm_ioctl], pid=2032, cmd=0x6458 nm:drm_ioctl], pid=2032, cmd=0x6458, nm:drm_ioctl], pid=2032, cmd=0x645 m:drm_ioctl], pid=2032, cmd=0x6458 m:drm_ioctl], pid=2032, cmd=0x6458, m:drm_ioctl], pid=2032, cmd=0x6458, nm:drm_ioctl], pid=2032, ...

In threes. Hmm, one for primary, cursor and self-refresh. drm.debug=0xe would be interesting to see what the pixel clock is. Can you grab one before the bad commit and one after? If there is a change that may help pin-point the mistake. Or indicate further problems... -- Chris Wilson, Intel Open Source Technology Centre --

What's the rationale? It's valid or not. And there's already a function whose job it is to report that status ... which is set up for arch customization. Which ISTR worked fine for AT91 (among other platforms) ... --

The printk message for the 2 serial port version is obscured with a debug macro, unlike all other versions of the card. It should be changed to make the output equal for all detected models. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=578616#c1 CC: Joe Krahn <krahn@niehs.nih.gov> Signed-off-by: Niels de Vos <ndevos@redhat.com> --- drivers/parport/parport_pc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/parport/parport_pc.c ...

Hmm. maybe I misunderstood your point. Your point is that let's make whole caller of migrate_pagse has a responsibility of clean up the list? -- Kind regards, Minchan Kim --

If migrate_pages always return number of pages not migrated, it's possible. But now it can return the number of pages not migrated or error code. In case of returning error code, caller has a complex routine to know count the Hmm. yes it's not good. At least we can help some NOTE. migrate_pages isn't generic kernel API so i think documentation is enough. -- Kind regards, Minchan Kim --

"ring->space" is unsigned so it's never less than zero. Signed-off-by: Dan Carpenter <error27@gmail.com> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 51e9c9e..a331898 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -208,9 +208,10 @@ static int init_ring_common(struct drm_device *dev, else { ring->head = ring->get_head(dev, ring); ring->tail = ring->get_tail(dev, ...

I'm afraid the flexibility is necessary: immediately after posting the first interface with fixed structures there were requests for extensions that would be difficult or impossible to implement using the structures; crypto is not something fixed, new algorithms with algorithm-specific parameters appear all the time. On the positive side, the implementation of session_once as shorthand for session_{init,update,final} is much nicer with the netlink attributes. Yes, it's a lot of code. I'm afraid ...

Note that this error carries on in the mail. There is a master provider for Geoclue that can make use of whatever providers are available, but it's not in too good a shape. I'd rather somebody started fixing the Geoclue master provider rather than relying on a particular service, especially when the D-Bus API for the providers themselves is something we don't want to support in the longer term. Cheers --

On Mon, Aug 23, 2010 at 7:11 AM, Johannes Berg To help us move forward to automate location awareness information into the kernel. I don't think we can unify all possible solutions for the different distributions out there so best is to make available whatever utilities we can and allow the distribution implementors to embrace whatever they want. The current implementation doesn't talk to deamons. The hostip provider within GeoClue and it will just trigger a URL get. If desktops start ...

See the bugzillas filed against Geoclue, most of them are due to bugs in No, I'm talking about what's exported by the providers. I don't really care if they talk to other parts of the system using D-Bus though. I'm talking about link 2) here. [App] <-1-> [Geoclue master] <-2-> [Gypsy provider] <-3-> [Gypsy daemon] --

And am new there :) This makes sense -- are there plans on removing all these exported library routines so that the only exposed thing is the master provider calls? Based on your comments it seems changing the iw patch to just use the master provider would go more in line with current development focus. Luis --

From: Basak, Partha <p-basak2@ti.com> For every optional clock present per hwmod per omap-device, this function adds an entry in the clocks list of the form <dev-id=dev_name, con-id=role>, if an entry is already present in the list of the form <dev-id=NULL, con-id=role>. The function is called from within the framework inside omap_device_build_ss(), after omap_device_register. This allows drivers to get a pointer to its optional clocks based on its role by calling clk_get(<dev*>, ...

From: Kevin Hilman <khilman@ti.com> Currently, the platform_bus allows customization of several of the busses dev_pm_ops methods by using weak symbols so that platform code can override them. The weak-symbol approach is not scalable when wanting to support multiple platforms in a single kernel binary. Instead, provide __init methods for platform code to customize the dev_pm_ops methods at runtime. NOTE: after these dynamic methods are merged, the weak symbols should be removed from ...

Hi, I just bought an new external disk enclosure with e-sata/USB2 connector to replace an old USB2 only external disk enclosure. My internal drive is a small SSD because I use the small factor PC as a home theater and do want silence and fast boot. I build my own kernel to put only what I need in and also boot somehow faster. I use grub2 (up to date) as a loader. As soon as I power on the external sata disk, the system does not boot because hardware designer add the great idea to put ...

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --

on a related note, do we need to clear it when erroring at probe time ? doesnt seem like that is necessary either ... -mike --

From: Kevin Hilman <khilman@ti.com> Currently, the platform_bus allows customization of several of the busses dev_pm_ops methods by using weak symbols so that platform code can override them. The weak-symbol approach is not scalable when wanting to support multiple platforms in a single kernel binary. Instead, provide __init methods for platform code to customize the dev_pm_ops methods at runtime. NOTE: after these dynamic methods are merged, the weak symbols should be removed from ...

Another (minor) note, these can be more concise. The set open function can have a void return, and bus = &platform_bus_type lines are unnecessary. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. --

Nick, this is about a 1 liner to fs/aio.c replacing igrab with atomic_inc directly on the inode reference count. I know your scalability tree gets rid of the global, but in this case I think it still makes sense to avoid the locking completely when the caller knows it is safe. Do you already have something similar hiding in the scalability tree? -chris --

Well, it would make detecting races or invalid assumptions a little easier. If Chris wants to code that up, that's fine with me. Honestly, though, I don't think it's necessary. I've gone through the alloc/free paths for the inode and I'm convinced this is safe. I'm happy with this version of the patch. Reviewed-by: Jeff Moyer <jmoyer@redhat.com> --

(Adding cut CC... sorry about the duplicate) Hi Eric, Your only alternative is to set up your root partition as an mdraid volume (single-disk raid0 perhaps), mark it type 'fd' so the kernel can auto-assemble it, and specify "root=/dev/md1" (or whatever minor number you set it up as). Of course, adding an mdraid shim in between your bare device and the filesystem can reduce performance and/or data integrity for no other gain, and slow booting by the time taken examining all partitions. I ...

this patch fixes the bug above (http://marc.info/?l=netfilter-devel&m=128116762801769&w=2) thanks. --

On Mon, 23 Aug 2010 08:44:37 -0600 (MDT) Why doesn't NFS generate page size fragments? Does Infiniband or your device not support this? Any thing that requires higher order allocation is going to unstable under load. Let's fix the cause not the apply bandaid solution to the symptom. --

Commit 74641f584da introduced a regression - binfmt_misc is now consulted after binfmt_elf, which will unfortunately break ia32el. ia32 ELF binaries on ia64 used to be matched using binfmt_misc and executed using wrapper. As 32bit binaries are now matched by binfmt_elf before bindmt_misc kicks in, the wrapper is ignored. The fix increases precedence of binfmt_misc to the original state. Signed-off-by: Jan Sembera <jsembera@suse.cz> --- fs/binfmt_misc.c | 2 +- 1 files changed, 1 ...

Driver for Broadcom BCM4751 GPS chip. Signed-off-by: Matti J. Aaltonen <matti.j.aaltonen@nokia.com> --- drivers/misc/Kconfig | 11 + drivers/misc/Makefile | 1 + drivers/misc/bcm4751-gps.c | 490 +++++++++++++++++++++++++++++++++++++++ include/linux/i2c/bcm4751-gps.h | 59 +++++ 4 files changed, 561 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/bcm4751-gps.c create mode 100644 include/linux/i2c/bcm4751-gps.h diff --git ...

Hi.. My kernel (2.6.35) gets stuck at boot, as dmesg documents: .... [ 0.006590] ACPI: Core revision 20100121 [ 45.278951] DMAR: Host address width 36 ... Setting acpi debugging to give-me-all-you-can produces ~120Mb dump. The interesting part appears to be: ..... [ 36.016976] Table [SSDT](id 0006) - 28 Objects with 0 Devices 21 Methods 0 Regions [ 36.017120] dsinit-0214 [ffffffff81a32020] [00] ds_initialize_objects : 21 Methods, 0 Regions [ 36.017292] nsload-0136 ...

From: Julia Lawall <julia@diku.dk> dev_name always dereferences its argument, so it should not be called if the argument is NULL. The function indeed later tests the argument for being NULL. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression dev,E; @@ *dev_name(dev) ... when != dev = E ( *dev == NULL | *dev != NULL ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: David Howells ...

The axis-mapping of lis3dev device on many (rather most) HP machines doesn't follow the standard. When each new model appears, users need to adjust again. Testing this requires the rebuild of kernel, thus it's not trivial for end-users. This patch adds a module parameter "axes" to allow a custom axis-mapping without patching and recompiling the kernel driver. User can pass the parameter such as axes=3,2,1. Also it can be changed via sysfs. Signed-off-by: Takashi Iwai ...

That was over a year ago and I quickly gave up on this effort as Intel was not going to support it at all, sorry. greg k -h --

Hm, needing a module option to get a system running is not what the user expects. By default, the system should run fine and a module option should be added as a workaround or for debugging only. What do you think about below patch which introduces: - the blacklist based on the previous patch and comments - the module param -> as workaround and for trying out - let video.ko and i915_opregion share the same func to check for opregion support Should I add a drm/i915 list for this to ...

I'm still kind of reluctant about this - doing the blacklisting here means that there's no way for a native driver to inhibit registration from occuring until after opregion setup has taken place, and we found that that was necessary on some 915 so I suspect it is on gma500 as well. Perhaps it should just be done as a module option, and then Moorestown doesn't have ACPI, so I don't think there's any need to include these. -- Matthew Garrett | mjg59@srcf.ucam.org --

Hi Linus, These patches make it possible to inhibit the Xen emulated device unplug on the kernel command line (mostly "Just In Case") and renames xen_emul_unplug=ignore to the clearer xen_emul_unplug=unnecessary. Since it changes the name of a command line option we'd like to get it in before 2.6.36 proper. The third changeset is a pure cleanup which you could ignore for 2.6.36 if you wanted. I can resend without if you prefer. Ian. The following changes since commit ...

The compilation of 2.6.36-rc2 fails with the following error LD .tmp_vmlinux1 drivers/built-in.o: In function `vga_get_uninterruptible': /home/mafra/linux-2.6/include/linux/vgaarb.h:120: undefined reference to `vga_get' drivers/built-in.o: In function `i915_disable_vga': /home/mafra/linux-2.6/drivers/gpu/drm/i915/intel_display.c:5990: undefined reference to `vga_put' make[1]: *** [.tmp_vmlinux1] Fehler 1 make: *** [sub-make] Fehler 2 but 2.6.36-rc1 compiled fine. The machine is a ...

On Mon, 23 Aug 2010 13:32:48 +0200 Ah so we need to select VGA arb or make sure stubs are provided for !VGA_ARB configs. -- Jesse Barnes, Intel Open Source Technology Center --

Introduce some accessor functions for getting at the name and number of counters of the current sh_pmu instance. Signed-off-by: Matt Fleming <matt@console-pimps.org> --- arch/sh/include/asm/perf_event.h | 2 ++ arch/sh/kernel/perf_event.c | 13 +++++++++++++ 2 files changed, 15 insertions(+), 0 deletions(-) diff --git a/arch/sh/include/asm/perf_event.h b/arch/sh/include/asm/perf_event.h index 3d0c9f3..5b7fa84 100644 --- a/arch/sh/include/asm/perf_event.h +++ ...

Nice, I didn't know such a backend already existed. Now that you have made it generic we should aim towards making it the only oprofile backend and getting rid of all the duplication. --

Move the perf-events backend from arch/arm/oprofile into drivers/oprofile so that the code can be shared between architectures. This allows each architecture to maintain only a single copy of the PMU accessor functions instead of one for both perf and OProfile. It also becomes possible for other architectures to delete much of their OProfile code in favour of the common code now available in drivers/oprofile/oprofile_perf.c. Signed-off-by: Matt Fleming <matt@console-pimps.org> --- ...

Sure. This doesn't have to be a flag day. Architectures can move over if and when they're ready. I haven't looked very closely at any other architectures Eek! I totally messed this up, sorry. Thanks very much for compiling these and reviewing them. I've just grabbed an ARM toolchain so I'll compile the next version before I post it ;-) You've highlighted a good point - the allocation and freeing is done in the wrong places. We need a function in drivers/oprofile/oprofile_perf.c that is ...

Commit 6ef3d4278034982c13df87c4a51e0445f762d316 introduces seq_file usage in intel_overlay.c but does not include the header and now compilation fails on i386. Fix it by including the necessary header. Signed-off-by: Meelis Roos <mroos@linux.ee> diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c index 4f00390..7e4b378 100644 --- a/drivers/gpu/drm/i915/intel_overlay.c +++ b/drivers/gpu/drm/i915/intel_overlay.c @@ -25,6 +25,7 @@ * * Derived from ...

CONFIG_FB_68328_INVERT doesn't exist in Kconfig, therefore removing all references to it from the source. Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de> --- drivers/video/68328fb.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/video/68328fb.c b/drivers/video/68328fb.c index 75a39ea..bec3fd2 100644 --- a/drivers/video/68328fb.c +++ b/drivers/video/68328fb.c @@ -49,11 +49,7 @@ #error wrong architecture for the MC68x328 ...

CONFIG_FB_VIA_CAMERA doesn't exist in Kconfig, therefore removing all references to it from the source. Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de> --- drivers/video/via/accel.c | 16 ---------------- include/linux/via-core.h | 5 +---- 2 files changed, 1 insertions(+), 20 deletions(-) diff --git a/drivers/video/via/accel.c b/drivers/video/via/accel.c index e44893e..43d4f30 100644 --- a/drivers/video/via/accel.c +++ b/drivers/video/via/accel.c @@ ...

Postfix on my machine died, so I missed -rc2 unfortunately. Can you please pull for -rc3. Thanks. --

From: Neil Horman <nhorman@tuxdriver.com> This patch converts trace_napi_poll from DECLARE_EVENT to TRACE_EVENT to improve the usability of napi_poll tracepoint. <idle>-0 [001] 241302.750777: napi_poll: napi poll on napi struct f6acc480 for device eth3 <idle>-0 [000] 241302.852389: napi_poll: napi poll on napi struct f5d0d70c for device eth1 An original patch is below. http://marc.info/?l=linux-kernel&m=126021713809450&w=2 Signed-off-by: Neil Horman ...

This patch adds tracepoint to consume_skb and add trace_kfree_skb before __kfree_skb in skb_free_datagram_locked and net_tx_action. Combinating with tracepoint on dev_hard_start_xmit, we can check how long it takes to free transmited packets. And using it, we can calculate how many packets driver had at that time. It is useful when a drop of transmited packet is a problem. sshd-6828 [000] 112689.258154: consume_skb: skbaddr=f2d99bb8 Signed-off-by: Koki Sanagi ...

Fix the name of the sensor: BMP086 => BMP085 Signed-off-by: Thomas Weber <weber@corscience.de> --- drivers/misc/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 0b591b6..9df5b75 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -385,7 +385,7 @@ config BMP085 depends on I2C && SYSFS help If you say yes here you get support for the Bosch Sensortec - BMP086 digital pressure ...

While we are reading trace_stat/functionX and someone just disabled function_profile at that time, we can trigger this: divide error: 0000 [#1] PREEMPT SMP ... EIP is at function_stat_show+0x90/0x230 ... This fix just takes the ftrace_profile_lock and checks if rec->counter is 0. If it's 0, we know the profile buffer has been reset. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- kernel/trace/ftrace.c | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 ...

Signed-off-by: Mike Frysinger <vapier@gentoo.org> --- MAINTAINERS | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 433f353..a1df54b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -454,6 +454,17 @@ L: linux-rdma@vger.kernel.org S: Maintained F: drivers/infiniband/hw/amso1100/ +ANALOG DEVICES INC ASOC DRIVERS +L: uclinux-dist-devel@blackfin.uclinux.org +L: alsa-devel@alsa-project.org (moderated for ...

Fix breakage/warnings introduced by post 2.6.35 commits, and add maintainers entries for ADI ASoC drivers. Pretty straight forward. Mike Frysinger (3): Blackfin: fix hweight breakage ADI/ASoC: add MAINTAINERS entries Blackfin: wire up new fanotify/prlimit64 syscalls MAINTAINERS | 11 +++++++++++ arch/blackfin/include/asm/bitops.h | 17 ++++++++++------- arch/blackfin/include/asm/unistd.h | 5 ++++- arch/blackfin/mach-common/entry.S | 3 +++ 4 files ...

EOPNOTSUPP is also called ENOTSUP in userland. ENOTSUP is the appropriate POSIX errno code for a situation such as a clock type that cannot be used in a certain call (like setting when you can only read it, etc.). Thanks, Roland --

ENOTTY is the usual errno for "inappropriate ioctl for device". Due to the way this patch has been chopped up, I can't tell if that's what is intended here. -- Matthew Wilcox Intel Open Source Technology Centre "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." --

FYI, this is going to hit a conflict as i'm about to push out an update to wire up the new 2.6.36 syscalls -mike --

A new syscall is introduced that allows tuning of a POSIX clock. The syscall is implemented for four architectures: arm, blackfin, powerpc, and x86. The new syscall, clock_adjtime, takes two parameters, a frequency adjustment in parts per billion, and a pointer to a struct timespec containing the clock offset. If the pointer is NULL, a frequency adjustment is performed. Otherwise, the clock offset is immediately corrected by skipping to the new time value. In addtion, the patch provides way ...

As I mentioned in the previous mail, I agree the new functionality (adjusting the time by an offset instantaneously) is useful, but I'd prefer it be done initially within the existing adjtimex() interface. Then if the posix-time clock_id multiplexing version of adjtimex is found to be necessary, the new syscall should be introduced, using the same API (not all clock_ids need to support all the adjtimex modes, but the new interface should be sufficient for NTPd to use). There are some ...

Reviewed-by: Christoph Lameter <cl@linux.com> --

When under significant memory pressure, a process enters direct reclaim and immediately afterwards tries to allocate a page. If it fails and no further progress is made, it's possible the system will go OOM. However, on systems with large amounts of memory, it's possible that a significant number of pages are on per-cpu lists and inaccessible to the calling process. This leads to a process entering direct reclaim more often than it should increasing the pressure on the system and compounding the ...

Changelog since V1 o Fix for !CONFIG_SMP o Correct spelling mistakes o Clarify a ChangeLog o Only check for counter drift on machines large enough for the counter drift to breach the min watermark when NR_FREE_PAGES report the low watermark is fine Internal IBM test teams beta testing distribution kernels have reported problems on machines with a large number of CPUs whereby page allocator failure messages show huge differences between the nr_free_pages vmstat counter and ...

A delta on the NR_FREE_PAGES is the obvious problem. The page allocation failure report I saw clearly stated that free was a value above min watermark where as the buddy lists just as clearly showed that the number of pages on I am not aware of similar issues with another counter where drift causes Unfortunately, I do not have access to a machine large enough to investigate around this area. All I have to go on is a few bug reports showing the delta problem with NR_FREE_PAGES and test ...

True, but I thought that would introduce a constant performance penalty We could if there is another counter that results in bad system behaviour due to counter drift. As NR_FREE_PAGES seemed to be the only one, zone_nr_free_pages() seemed adequate. If such a helper did exist, zone_nr_free_pages() would be a simple wrapper around it. The indirection didn't seem necessary at this point though. -- Mel Gorman Part-time Phd Student Linux Technology Center University ...

Sure, an increased frequency of updates would increase the chance of bouncing cachelines. But the bouncing cacheline scenario for the vm counters was tuned for applications that continually allocate pages in parallel. When the vm gets into a state where continual reclaim is necessary then the counters are not that frequently updated. If the machine is already slowing down due to reclaim then the vm can likely affort more frequent counter updates. --

The maximum time for which the livelock can exists is the vm stat interval. By default the counters are brought up to date at least once per second or if a certain delta was violated. Drifts are controlled by the delta configuration. --

Ok, but is that better than this patch? Decreasing the size of the window by reducing the threshold still leaves a window. There is still a small amount of drift by summing up all the deltas but you get a much more accurate count at the point of time it was important to know. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

Fix compile error $ ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- make ... cc1: error: unrecognized command line option "-m64" cc1: error: unrecognized command line option "-mno-red-zone" cc1: error: unrecognized command line option "-mcmodel=kernel" cc1: error: unrecognized command line option "-maccumulate-outgoing-args" The error was introduced by patch kbuild-fix-config_cross_compile-issue-in-config.patch: -CROSS_COMPILE ?= ...

They've got a custom register for its value. GET_INT is implemented by They have really weird dependency between clock setup and operation mode. Try to use the clock setup values from the errata I've sent you. The order of register initialization and reset timing seems to affect the operation as well. To summarize my opinion about it: if I had to design a card reader, I --

Looks good, Reviewed-by: Christoph Hellwig <hch@lst.de> --

Hi all, Changes since 20100820: The sh tree lost its conflict. The input tree lost its build failure. The net tree gained a build failure for which I applied a patch. ---------------------------------------------------------------------------- I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you are tracking the linux-next tree using git, you should not use ...

Dear Partner, I have a business proposal for you,if you are interested in transacting business with me,kindly send me your datas as listed in this email via my private email (zhuochengwen4414@yahoo.com.cn) Name/Address/Tel Number/Cell Number/Occupation/Company/ Position. Please as soon as i hear from you, i will send you the complete details regarding this transaction. Thanks Mr.Zhou Chengwen --

From: Stephen Rothwell <sfr@canb.auug.org.au> Oh, if I only had a dollar for every time we've had to fix up something like this :-) Applied, thanks! --

__packed is only defined in kernel space, so we should use __attribute__((packed)) for the code shared between kernel and user space. Two __attribute() annotations are replaced with __attribute__() too. Signed-off-by: Changli Gao <xiaosuo@gmail.com> --- include/linux/if_ether.h | 2 +- include/linux/if_fddi.h | 8 ++++---- include/linux/if_hippi.h | 8 ++++---- include/linux/if_pppox.h | 10 +++++----- include/linux/ipv6.h ...

Did not add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt because no printk in this module used message prefixing. Signed-off-by: Joe Perches <joe@perches.com> --- drivers/net/ixgbe/ixgbe_main.c | 74 +++++++++++++++++++-------------------- 1 files changed, 36 insertions(+), 38 deletions(-) diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c index 5afbd99..6e100d4 100644 --- a/drivers/net/ixgbe/ixgbe_main.c +++ b/drivers/net/ixgbe/ixgbe_main.c @@ -282,17 +282,17 ...

Apologies for the duplicates. --

I'll let the Intel folks integrate these 3 patches. Thanks Joe. --

__be* are defined in linux/types.h now, and in fact, rds.h isn't exported to user space even. Signed-off-by: Changli Gao <xiaosuo@gmail.com> --- include/linux/rds.h | 9 --------- 1 file changed, 9 deletions(-) diff --git a/include/linux/rds.h b/include/linux/rds.h index 24bce3d..7f3971d 100644 --- a/include/linux/rds.h +++ b/include/linux/rds.h @@ -36,15 +36,6 @@ #include <linux/types.h> -/* These sparse annotated types shouldn't be in any user - * visible header file. We ...

Another week, another -rc. I didn't really ever get around to announcing -rc1 when I released it, and we had enough niggling small problems (like a memory corruptor in the HID layer that ended up causing some random problems etc) there that I never got around to fixing that lack of announcement. And hopefully -rc2 is a good point to correct the lack of earlier commentary. The main commentary about it is that I'll be back in "fairly strict" mode as of -rc2. IOW, send me regression fixes only. ...

Those bugs are not critical, which means they won't crash the filesystem, so they're hardly noticeable and no one noticed them. --- fs/btrfs/free-space-cache.c | 161 ++++++++++++++++++++++++++----------------- 1 files changed, 99 insertions(+), 62 deletions(-) --

It's early in the morning here, so forgive me if I'm missing something obvious, but if try_merge_free_space() succeeds here, then won't tree_insert_offset() then add an entry that overlaps the same spot? Should we do something like merged = try_merge_free_space(); if (!merged) tree_insert_offset(); ? Thanks, Josef --

Oops, good catch Reviewed-by: Josef Bacik <josef@redhat.com> Thanks, Josef --

After returing extents from a cluster to the block group, some extents in the block group may be mergeable. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- fs/btrfs/free-space-cache.c | 26 ++++++++++++++++++++------ 1 files changed, 20 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index faeec8f..c11f4f7 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -234,11 +234,18 @@ tree_search_offset(struct ...

If a block group is smaller than 1GB, the extent entry threadhold calculation will always set the threshold to 0. So as free space gets fragmented, btrfs will switch to use bitmap to manage free space, but then will never switch back to extents due to this bug. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- fs/btrfs/free-space-cache.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index ...

Reviewed-by: Josef Bacik <josef@redhat.com> Thanks, Josef --

When an fanotify listener is closing it may cause a deadlock between the listener and the original task doing an fs operation. If the original task is waiting for a permissions response it will be holding the srcu lock. The listener cannot clean up and exit until after that srcu lock is syncronized. Thus deadlock. The fix introduced here is to stop accepting new permissions events when a listener is shutting down and to grant permission for all outstanding events. Thus the original task will ...

From: Tvrtko Ursulin <tvrtko.ursulin@sophos.com> This reminded me... you have two pr_debugs in fanotify_should_send_event which output redundant information. Maybe you intended it like that so it is selectable how much log spam you want, or if not you may want to apply this patch. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@sophos.com> Signed-off-by: Eric Paris <eparis@redhat.com> --- fs/notify/fanotify/fanotify.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git ...

The userspace event metadata structure was packed so when sent from a kernel with a certain set of alignment rules to a userspace listener with a different set of alignment rules the userspace process would be able to use the structure. On some arches just using packed, even if it doesn't do anything to the alignment can cause a severe performance hit. From now on we are not going to set the packed attribute and will just need to be very careful to make sure the structure is naturally aligned ...

You may be interested in Mel's patchset that he just proposed for -mm which identifies watermark variations on machines with high cpu counts (perhaps even eight, as in this report). The last patch actually reworks this hunk of the code as well. http://marc.info/?l=linux-mm&m=128255044912938 http://marc.info/?l=linux-mm&m=128255045312950 http://marc.info/?l=linux-mm&m=128255045012942 http://marc.info/?l=linux-mm&m=128255045612954 Dave, it would be interesting to see if this fixes ...

On Aug 22, 2010, at 4:43 PM, Nikitas Angelinas <nikitasangelinas@googlemail.com That should be kcalloc while you are at it. Thanks. -- Dmitry --

How can it work? You neither have a loop nor use 'whom' in your hello_init()... You need: statick int hello_init(void) { int i; for (i=0; i<howmany; i++) printk(KERN_WARNING "Hello, %s\n", whom); return 0; } --

Pulled, thanks a lot! Ingo --

Hi Alex, Sorry for lack of details in my first e-mail. I was hoping to send you the logs together with bisecting results. Unfortunately there are other issues between 2.6.35-git2 - the last 'good' kernel (which doesn't include the first drm pull for 2.6.36 window merge) - and 2.6.36-rc1. Due to those issues I can't bisect. For example: 1) First I tried to narrow the problem down to the closest affected kernel snapshot. So I marked 2.6.35-git2 as good and I was expecting that 2.6.35-git3 ...

Do a small update to fix a dangerous bug. http://kgtp.googlecode.com/files/kgtp_20100823.tar.bz2 Thanks, Hui --

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> but I'd be much happier if someone who actually has the hardware could verify that this is OK. --

I don't have the hardware handy at the moment. Gary, can you please verify the fix? -- Sincerely yours, Mike. --

applied to wq#for-linus. Thanks. Also, please considering putting related patches into a thread. For short series, just chaining them is good enough (ie. patch n+1 is reply to patch n). For longer series, writing up a head message with overall description, diffstat and other general info about the patch series and making all patches reaplies to the head message is a good idea. Thanks. -- tejun --

I was busy with other kernel work and didn't get a chance to do so. It should happen later this week. thanks, greg k-h --

From: Changli Gao <xiaosuo@gmail.com> It seems so, yes. There is no way that anybody has tried to compile anything in userspace using these headers with the __packed usage there. If they would, they would surely see a compile failure. --

From: David Miller <davem@davemloft.net> Changli I applied your patch to convert these __packed tags back to the original expansion. Thanks! --

In some cases 'data' should be considered as a user pointer but it requires cast with additional __force markup which was missing. Rather than add the markups wherever needed, make use of a temporary variable of user pointer. This patch is based on compat_ptrace_request() implementation. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Namhyung Kim <namhyung@gmail.com> --- kernel/ptrace.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git ...

Acked-by: Roland McGrath <roland@redhat.com> --

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> With a change like this it's good to note why things worked prior to the change - my first thought was that it might be better to loose the driver data copy entirely if we were fine with it being set to zero. --

That is correct. The menuconfig help screen led me to believe the SLAB allocator was the "safe" choice: "CONFIG_SLAB: The regular slab allocator that is established and known to work well in all environments" Should I be using SLUB instead? Any downsides to SLUB on an old and slow (500 MHz) single core dual CPU box with <512MB RAM? Also, what is the impact of these oopses? Despite the entries in dmesg, the system "seems" to be running ok. Or is this simply the calm before the ...

Did you enable fips mode? John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. --

I think the line right above the chunk can be removed too, anyway, Acked-by: WANG Cong <xiyou.wangcong@gmail.com> --

[Hiremath, Vaibhav] Overlooked, my bad. Thanks for pointing this to me ,will fix. Thanks, --

[Hiremath, Vaibhav] Nothing to argue here, I have to admit/accept and fix this. Thanks, --

Thanks. Acked-by: Don Zickus <dzickus@redhat.com> --

Yeahm, it doesn't hurt och break git-bisect but if it's disturbing I can spin it over to the other patch. Right now I'm just awaiting Sams reply to if he wants per-subsystem patches or not, so I'll make a final version if there are more changes required. Yours, Linus Walleij --

Not really a future-proof design, is it? --

Though in case there is just a single user it can work out. Just like bridge.c, and the bunch of nf_nat_*.c. :-) Though yeah. Bad bad. This is starting to sound pretty much like an XY problem: XY problem: You want to do X, but don't know how. You think you can solve it using Y, but don't know how to do that, either. You ask about Y, which is a strange thing to want to do. Just ask about X. (And then there is still the "good idea to do X in the first place" thing.) Like what's so ...

Please don't do any such thing, its impossible to use correctly. Suppose there are two modular users, A and B. Both have something like: extern void (*fptr)(void); static void (*old_fptr)(void); static void func(void) { /* foo */ if (old_fptr) old_fptr(); } module_init() { old_fptr = fptr; fptr = A_func; } Then you load A, load B and unload A, then guess what happens? --

I would rather check if the patch is still needed at all. Tiago, can you try vanilla 2.6.36-rc1, which has the first "CROSS_COMPILE ?=" line removed (commit 235caa2) and check if your original problem still presists? Thanks, Michal --

On Mon, Aug 23, 2010 at 1:46 AM, jean-philippe francois Could you provide the output of: cat /sys/devices/system/clocksource/clocksource0/available_clocksource cat /sys/devices/system/clocksource/clocksource0/current_clocksource I assume you're using the TSC, and hitting the halt-in-c3 issue, but I'm curious why the clocksource watchdog isn't catching this and dropping you back to a more stable clocksource. thanks -john --

By the way, I think only 69309a05907546fb686b251d4ab041c26afe1e1d should solve the problem. Mark, could you try only this patch? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

This commit also present in 2.6.32.stable (since 2.6.32.19). Should it be fixed there as well? Thanks! /mjt --

Tested 69309a05907546fb686b251d4ab041c26afe1e1d on top of 2.6.35.3 and this does solve the rebooting problem. - Mark --

mlock() simply avoids major faults, nothing more. I think both page migration and page-out for shared pages where some maps are !mlocked can cause unmaps and thus minor faults. mlock and dirty do not interact, they will still be cleaned/written out as normal. --

That sounds broken too, not having read the initial problem and such, it sounds like the hypercall would expect the pages to stay pinned and mlock doesn't actually guarantee that at all. --

So mlock is useless for preventing secret stuff from being written to disk. J --

Won't dirty anonymous pages also get written to swap? J --

Us real-time people have been telling people to not use mlockall() at all. While small !glibc statically linked RT components using shared memory interfaces to !RT apps could work its not how people actually write their apps. They write big monolithic threaded apps where some threads are RT. [ in part because there doesn't seem to be a usable !glibc libpthread/librt implementation out there, in part because people use crap like Java-RT ] --

Are you allowed to mlock a stack page which has not yet been faulted in ? What effect does it have ? I wasn't able to find a convincing de jure answer to this question. But you seem, like me, to be disagreeing with Linus's assertion that You are directly contradicting the advice in SuS, to which I just gave a reference. You're free to do so of course but it might be worth explaining in a bit more detail why the advice in SuS is wrong. Ian. --

Doing hypercalls from userspace is a silly hack to avoid putting dom0 hypercall knowledge into the kernel. mlock in that area has always been problematic (initially on Solaris, and increasingly on Linux) and we're going to have to fix it at some point. I wouldn't spend a lot of time defending it. J --

On Mon, 2010-08-23 at 16:42 +0100, ijackson@chiark.greenend.org.uk RT apps should pre-allocate and mlock their stack in advance (and pre-fault too for the paranoid). mlockall is a very bad interface and should really not be used. --

Is that guaranteed to work (in Linux or in general)? mlock has always meant "won't generate disk IO to fault in/evicted", but does it prevent dirty pages from being written out so long as they also remain resident? Or does it depend on the precise type of page you're mlocking? For example, what does mlock on a shared writeable mapping mean? J --

This file is generated by the top Makefile. --

I'd personally not actually be that upset with a BUG_ON(), my main reason for changing the code was that it was non-obvious what the source Yeah, that's why I suggested driving it as a GPIO for simplicity - from the user point of view it doesn't matter if that's what the controller does so long as the driver figures out the chip select without external help. --

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxyf2gACgkQHUdvYGzw6vdUCwCghkscXUjV2TVmkXga5LiJPiN1 Dr8Ani+Voxx5jpvOfzNsUUEVA9e2P/x8 =yiHB -----END PGP SIGNATURE-----

At Mon, 23 Aug 2010 13:43:03 +0800, Thanks. But, isn't it better to add .dma_mask field to struct agp_bridge_driver? Isn't it 0xff0? Takashi --

No. This depends on hw 32bit PTE format for sandybridge. bit 31 bit 11 bit 4 bit 0 |<-physical addr 31:12->|<-physical addr 39:32->|<-cache ctl 3:1->|valid| -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

At Mon, 23 Aug 2010 09:35:07 +0800, Could you point where is the upstream GIT tree and the corresponding commit id? thanks, Takashi --

Ok, to not hold up the perf/urgent flow i zapped these two commits for the time being: 4a31beb: perf, x86: Fix handle_irq return values 8e3e42b: perf, x86: Try to handle unknown nmis with an enabled PMU We can apply them if they take a form that dont introduce a different kind of (and more visible) regression. Thanks, Ingo --

Could you explain why we need rcu_read_unlock() before mem_cgroup_put() ? I suspect that it's because mem_cgroup_put() can free the memcg, but do we need mem->valid then ? Thanks, Daisuke Nishimura. --

This patch looks good to me, but I have one question. Why do we need to acquire sc.lock inside mem_cgroup_(start|end)_move() ? These functions doesn't access mc.*. Thanks, Daisuke Nishimura. On Fri, 20 Aug 2010 19:02:56 +0900 --

On Mon, 23 Aug 2010 14:32:37 +0900 Why ?? Thanks, -Kame --

I think the counters will still be useful for NUMA also. Is there a performance hit here I am missing to having the per node counters? Just want to make sure we are only wondering about whether or not we are polluting the interface? Also since we plan to change the name to vmstat instead doesn't that make it more generic in the future? mrubin --

Thanks, applied. -- Jens Axboe --

Yes, this exactly is the plan. All the major crypto libraries - NSS, OpenSSL, libgcrypt - are going to be patched to use the kernel API in case they are configured to. By default they will still be using their internal implementation of the cryptographic algorithms. Of course there still might be some applications (for example glibc libcrypt password hashing) that decide to use the kernel interface directly, but these will be a very small minority I think. -- Tomas Mraz No matter how far ...

Hi Peter, Zero is part of the valid range from 2.6.36. Can be implemented simply as What are data[11] and data[12]? Since all needed information is available here, there seems to be little reason Apparently, f1 and f2 represent the slots themselves, i.e., the device uses slots internally. Please simplify the logic accordingly. There is an example in No information about signal-to-noise ratio (fuzz) for this device? Thanks, Henrik --

On Fri, 20 Aug 2010 15:50:54 +1000 If it is appropriate to have a lower limit, that should be imposed where the sysctl is defined in kernel/sysctl.c, not imposed after the fact where the value is used. As we now have dirty_bytes which over-rides dirty_ratio, there is little cost in having a lower_limit for dirty_ratio - it could even stay at 5% - but it really shouldn't be silent. Writing a number below the limit to the sysctl file should fail. NeilBrown --

How about imposing an explicit bound of 1%? That's more natural and its risk of breaking user space should be lower than 5%. Thanks, Fengguang --- writeback: remove the internal 5% low bound on dirty_ratio The dirty_ratio was silently limited in global_dirty_limits() to >= 5%. This is not a user expected behavior. And it's inconsistent with calc_period_shift(), which uses the plain vm_dirty_ratio value. So let's rip the internal bound. At the same time, force a user visible low bound ...

sys_setxattrat would take 7 arguments. -aneesh --

On Mon, 23 Aug 2010 06:54:03 +0530 Bother... you are right. I had remembered that at the time that all that *at calls were added there was discussion about how you always need some flags, particularly in the context of adding O_CLOEXEC and (I thought) a flag to allow non-sequential allocation of fds. I had thought that they all got 'flags' arguments as a result, but it seems not. For openat you could squeeze something into the current 'flags' arg (O_FILE_HANDLE), but for readlinkat, ...

This is running the emulator.flat test case, with shadow paging. This test triggers a lot (millions) of mmu mode switches. -- error compiling committee.c: too many arguments to function --

I see a lot of soft lockups with this patchset: BUG: soft lockup - CPU#0 stuck for 61s! [qemu:1917] Modules linked in: netconsole configfs p4_clockmod freq_table speedstep_lib kvm_intel kvm e1000e i2c_i801 i2c_core microcode serio_raw [last unloaded: mperf] CPU 0 Modules linked in: netconsole configfs p4_clockmod freq_table speedstep_lib kvm_intel kvm e1000e i2c_i801 i2c_core microcode serio_raw [last unloaded: mperf] Pid: 1917, comm: qemu Not tainted 2.6.35 #253 ...

Hmmm good point.. Perhaps the choice of using struct iscsi_cmd as the example w/ __be32 header_digest was made a little hastely on my part. 8-) So in that case, I can focus making this struct iscsi_cmd function W/O the header_digest member first, and have the temporary stubs in the lio-core-2.6.git tree for the other PDUs as required until the other non <nod> I would like to start adding BIDI into TCM Core + TCM_Loop very soon (mabye by this weekend..?) Ditto on the extended > 16-byte ...

It's already applied. -- Sent from my mobile phone. Please pardon any lack of formatting. --

Hi, Right, I think I understood now! In my case, I was thinking in use just the *ioc_data pointer in io_context. But in that case, I will not have a callback to deallocate my structures, right? For now, I will clone those cfq_io_context's. Is there a reason to not bring those functions into elevator_type .ops? I mean, create a interface like .elevator_create_io_context and .elevator_destroy_io_context, and let the elevator.c do the callbacks. I think that what I'm doing now will be my ...

The patch is still missing from Linus's tree. 2.6.36-rc2-git1 (9ee4747..) fails with the same error. Thanks -Sachin -- --------------------------------- Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India --------------------------------- --

This situation can only occur for the init namespace, i.e. early at host boot so the sysctl registration will not fail for sure. On the other hand, since the ipv6 can be built as module this code can be executed later run-time ... --

For sure, and if you need it in a hurry your patch is much saner. So if you feel like its required for .36 go for it, we can look at cleaning it up for .37 or somesuch. --

No, this isn't really the right way to go about it. The whole point is to avoid reliance on undocumented side effects of the specific implementations of an interface. That means creating a new interface with the desired semantics, instead of creating a "local" patch which happens to work for the current implementation -- and which will break silently when the new implementation of the interface is created, and which means the new implementation will be seen as causing a performance ...

Now queued up. thanks, greg k-h --

Forget that. You could have discussed this if there were code reviews or other mainline inclusion emails from James B. From what I have heard, the decision was taken around 8-9 months back. Would anyone like to either comment/validate/refute this please? If not then I would kindly request these guys to stop taking us for a test drive. And also I'm not sure when was the last time James B. bench-marked our scsi-stack. Even if I ACK in the xmit-path then I can't push more than 100K IOPs. But ...

Well, James, why not 100MbE? If you want a comparison of target implementations you need a fast hardware with minimal latency. Otherwise, the difference between the implementations can drown in the overhead of the accompanying processing. 1GbE is a nearly 10 years ago interface. Or are we going to stay ten years behind progress? Thanks, Vlad --

Thanks Stephen, applied. -- Jens Axboe --

Now queued up for the next .35-stable kernel release. thanks, greg k-h --

----- Original Message ----- From: "Greg KH" <gregkh@suse.de> To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com> Cc: <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; <yong.y.wang@intel.com>; <qi.wang@intel.com>; <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <alan@linux.intel.com>; <margie.foster@intel.com>; "Morinaga" <morinaga526@dsn.okisemi.com> Sent: Friday, August 20, 2010 12:22 AM I can understand your saying. But our driver for Topcliff doesn't support multiple ...

It seems good. Currently there isn't any code that register a ramoops device, isn't it? --

*sigh* that's exactly what we're doing, we're creating a separate software hrtimer to create samples, the only thing that's different is that we put this hrtimer and the hw-counter in a group and let the hrtimer sample include the hw-counter's value. If you then weight the samples by the hw-counter delta, you get something that's more or less related to the thing the hw-counter is counting. For counter's that do no provide overflow interrupts this is the only The wrap issue it totally ...

From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: David S. Miller <davem@davemloft.net> I'll move sparc64 over to this once it hits Linus's tree. --

The implementation looks good for asm-generic, but there is now an asymmetry between the spinlock and the atomic_long_t based version. Maybe we can make them both do the same thing, either of 1. create include/linux/rwsem-cmpxchg.h and add an #elif defined(CONFIG_RWSEM_GENERIC_ATOMIC) to include/linux/rwsem.h 2. move include/linux/rwsem-spinlock.h to include/asm-generic/ and include that from all architectures that want the spinlock based version. Further comments: * Alpha has ...

It's in my email queue, but not in a git tree, yet ... you can take it back if you want ... James --

--

Yes, I had added it and test it, it works. --

On Tue, 17 Aug 2010 11:51:03 +0200 Please unadd it. JBD should be fixed so that it can appropriately handle out-of-memory conditions. Until that time we shouldn't hide its shortcomings with this open-coded equivalent. --

On Mon, 16 Aug 2010 19:57:51 -0700 (PDT) erm. The reason for adding GFP_NOFAIL in the first place was my observation that the kernel contained lots of open-coded retry-for-ever loops. All of these are wrong, bad, buggy and mustfix. So we consolidated the wrongbadbuggymustfix concept into the core MM so that miscreants could be easily identified and hopefully fixed. I think that simply undoing that change is a bad idea - it allows the wrongbadbuggymustfix code to hide from view. The ...

On Mon, 23 Aug 2010 12:35:22 -0700 (PDT) The difference is that an order-0 !__GFP_NOFAIL allocation attempt can The JBD one is hard - I haven't looked at the others. We should fix them. --

This is GFP_NOIO, which all the allocations in this patchset are (or GFP_NOFS), so the oom killer isn't involved. --

On Mon, Aug 23, 2010 at 11:01 PM, Andrew Morton I'd prefer killing off __GFP_NOFAIL properly :-) --

On Mon, 23 Aug 2010 13:08:53 -0700 (PDT) While holding locks which will prevent kswapd from doing anything useful. --

It implies that these calls are special in some way, basically to mean we have no sane error handling for failures, when in reality this is only a function of the allocation order when the context does not have __GFP_FS. You may as well just add BUG_ON(!nreg) here instead. I thought my "/* FIXME: this may potentially loop forever */" was sufficient to mean that the allocation must succeed independent of the page allocator's implementation, but perhaps you find greping for ...

Well, I wanted to make it easy for David so that he can proceed with his removal of __GFP_NOFAIL. I agree that pushing the looping from the allocator to the callers seems of a disputable value to me as well. So do you think that we should keep __GFP_NOFAIL as long as all callers are not able to handle allocation failures in more reasonable way? Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

Acked-by: Huang Ying <ying.huang@intel.com> --

So 1. comes directly from what you quote below. The sysfs thing is buried in another long thread that I can't be bothered to dig through To be honest, I can't see how you arrive at that interpretation from the quote below. It specifically says "what it comes down to is that if we had a kernel side protocol accelerator for STGT, the project would no longer suffer from this theoretical failing. *Both* of you have such a thing embedded in your respective submissions (all 74k LOC of them) ...

Here is a comprehensive features comparison I prepared some time ago: http://scst.sourceforge.net/comparison.html. It's a bit outdated at the moment, but I'm going to make it completely up do date in the next few days. Vlad --

I have avoided this decision for several years in the vain hope that some accommodation could be found. However, since I foresee a mergeable patch in my inbox in the very near future, it's shortly becoming unavoidable. --

The best thread on the topic is this massive one: http://marc.info/?t=120109820100005 I want replacement because evidence suggests that multiple things doing the same thing don't get as much attention as a single one. We need to support STGT because it's the one that has the in-kernel user base. Just breaking them constitutes an ABI problem under the new kernel Yes, in that thread. My basic conclusion was that there's no incredible discriminator between LIO and STGT (although there ...

Sorry for the slow response here, I got busy with other work at the end of last week. Sure. There are some clear parallels and the API seems to match, but what I'm asking is: does it make sense from an overall API view that Sure, but are they conceptually neutral? There are other clock synchronization algorithms out there. Will they need their own similar-but-different clock_ids? Look at the other clock ids and what the represent: CLOCK_REALTIME : Wall time (possibly freq/offset ...

Hi, Any news on the topic? Any feedback on the code or on the new events Thanks! --

These macros expand to the local variable "sdma" which must be present in all functions using them. I don't know what is considered moste readable, but I would certainly just #define SDMA_FOO (0x0123) (...) u32 foo = readl(sdma->regs + SDMA_FOO); Some kerneldoc here describing especially @unused: padding for register cast @usused1: padding for register cast Hm "unused" and "unused1" wrinkles my binary brain, can you call the first one "unused0" for my perceptions id1 und id2 ...

Dan, Any comment on this one? -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | --

But this has nothing special to do with the cases like multi-threaded dirtier, which is why I was confused. :) Thanks Nikanth --

Hello, No problem. I did the tests again according to your new instructions, and I am appending the results. Regards, MemTotal: 3104484 kB MemFree: 1258780 kB Buffers: 30820 kB Cached: 1693836 kB SwapCached: 0 kB Active: 1670344 kB Inactive: 137960 kB Active(anon): 1633940 kB Inactive(anon): 26224 kB Active(file): 36404 kB Inactive(file): 111736 kB Unevictable: 32 kB Mlocked: 32 ...

Updated patch appended. Thanks. --- From: Suresh Siddha <suresh.b.siddha@intel.com> Subject: sched: move sched_avg_update() to update_cpu_load() Currently sched_avg_update() (which updates rt_avg stats in the rq) is getting called from scale_rt_power() (in the load balance context) which doesn't take rq->lock. Fix it by moving the sched_avg_update() to more appropriate update_cpu_load() where the CFS load gets updated aswell. Signed-off-by: Suresh Siddha ...

They usually do. I have one that doesn't, but SYNCHRONIZE CACHE on it is so fast that it effectively must be a no-op. --

We need to call blk_rq_init and elv_insert for all cases in queue_next_fseq, so take these calls into common code. Also move the end_io initialization from queue_flush into queue_next_fseq and rename queue_flush to init_flush_request now that it's old name doesn't apply anymore. Signed-off-by: Christoph Hellwig <hch@lst.de> Index: linux-2.6/block/blk-flush.c =================================================================== --- linux-2.6.orig/block/blk-flush.c 2010-08-17 15:34:27.864004351 ...

Hi Jens, There are actually two distinct problems: (1) arrays with a non-volatile write cache (battery backed, navram, whatever) that do not NOOP a SYNC_CACHE command. I know of one brand that seems to do this, but it is not a common brand. If we do not issue flushes for write through caches, I think that we will avoid this in any case. (2) hardware raid cards with internal buffer memory and on-card battery backup (they sit in your server, disks sit in jbod like expansion shelves). ...

Hello, Yeah, that sounds reasonable. blk_queue_flush() can be called anytime without locking anyway, so it should be really easy to implement too. Thanks. -- tejun --

Below is an updated version of the documentation. It fixes several typos Zach Brown noticed and replaces all references to a physical medium with the term non-volatile storage. I haven't added any examples yet as I need to figure how they fit into the rest of the document. --- Explicit volatile write cache control ===================================== Introduction ------------ Many storage devices, especially in the consumer market, come with volatile write back caches. That means ...

Arrays are not a problem in general - they normally have internally, redundant batteries to hold up the cache. The issue is when you have an internal hardware RAID card with a large cache. Those cards sit in your server and the batteries on the card protect its internal cache, but do not have the capacity to hold up the drives behind it. Normally, those drives should have their write cache disabled, but sometimes (especially with S-ATA disks) this is not done. ric --

Nit: it's "its" above, not "it's". If in doubt, if it's "it is" (or "it has") it's "it's" but if it could be "his" or "hers" it's "its". I'm guessing English isn't your first language (a) because of your .de address and (b) because it's better than most British people's, but still, it's a common mistake. If I can remember any of the German I studied all those years ago, "its" is roughly equivalent to "sein", and "it's" to "es ist". Cheers, John. --

Yes - this is certainly one way to do it. Note that this will not work if the card advertises itself as a write through cache (and we end up not sending down the SYNC_CACHE commands). At least one hardware RAID card (I unfortunately cannot mention the brand) did not do this command forwarding. ric --

Thanks Vivek, I have applied the patches. -- Jens Axboe --

Peppe CAVALLARO <peppe.cavallaro@st.com> writes: Hm, i think it would be good if this dependency is removed, if it isn't needed, because then a allyes config would compile test this peace of code, and it can't die silently with changes around it. greetz didi -- (λ x . x x) (λ x . x x) -- See how beatiful the lambda is No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. --

Thank you! Naoya Horiguchi --

Spent a bit of the weekend trying to figure out what you were doing and couldn't reproduce it or find it in the code because I had already fixed it (albeit for slightly different reasons). The patch in question was: http://marc.info/?l=linux-kernel&m=128214903125780&w=2 the vfsmount_test_mask was always initialized but since no vfsmount marks were found it was never cleared. This left the code thinking that the given (inode) mark was interested in the event. I think you could reproduce ...

Hi Andrea, can you look at this patch? Thanks, --

CC netdev Please send this patch to netdev@vger.kernel.org and David S. Miller, because it seems Patrick is on vacation or something. Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Thanks --

sigh. Do you run 64 bit kernel with 32bit userland? If so, yes, thats broken since 2.6.35. I submitted a fix (http://marc.info/?l=netfilter-devel&m=128116762801769&w=2), but it was not yet applied. Will resend it later today. --

hi, any feedback? thanks, jirka --

Acked-by: Paul Menage <menage@google.com> Paul --

Looks good to me as well and agree on the ioctls. Care to resend a fresh patch and I will queue it up for 2.6.37. -- Jens Axboe --

This looks alot cleaner. Thanks! Reviewed-by: Neil Horman <nhorman@tuxdriver.com> --

On Fri, 20 Aug 2010 17:35:58 +0800 Quite a bit of code duplication there. A little helper function which adds a single char to the output would tidy that up. However I think that if the % and %% handers are converted to call cn_printf() then the output is always null-terninated and the third hunk of code above simply becomes unneeded? Something like this, although I didn't try very hard. Just a suggestion to work with ;) fs/exec.c | 63 ...

-- error compiling committee.c: too many arguments to function --

How does this interact with rcu? Nothing enforces consistency between rcu_dereference(kvm->memslots) and kvm->memslot_version. Should probably be rcu_dereference(kvm->memslots)->version. -- error compiling committee.c: too many arguments to function --

If a task goes to sleep on one VCPU, but that VCPU ends up not being runnable later on, it would be nice to wake the task up on on a different VCPU. I do not remember why it is safe to send this wakeup Having a limit of just one APF pending kind of defeats the point. At that point, a second one of these faults would put the VCPU to sleep, which prevents the first task from running once its pagefault (which started earlier) completes... -- All rights reversed --

apf_put_user() tracks memory slot changes and revalidate the address if -- Gleb. --

It's an ABI, so we can't use something that might change when Intel releases a cpu with 75.2 byte cache lines. -- error compiling committee.c: too many arguments to function --

64 byte boundary: You mean cacheline aligned? We have a special define for that. DEFINE_PER_CPU_SHARED_ALIGNED --

The guest will have to align this on a 64 byte boundary, should this be -- error compiling committee.c: too many arguments to function --

Ozan, Kirill, can you please test Tom's patch and see if it fixes the problems you noticed so that I can add Tested-by tags and apply this patch? Thanks, - Arnaldo --

np, take your time. - Arnaldo --

Hello, sorry about the delay. Hmm... okay. Yeah, if you haven't been using IPM at all, there won't be any debug messages but at the same time the posted patch should have had the same effect as Rafael's patch as IPM path isn't traveled at all. Can you please check the followings? * You're actually running the correct patched kernel and modules. It probably is a good idea to add a printk message. ie. Apply the patch and add a printk() in ata_host_request_pm() in libata-core.c and ...

That sounds very close to getting it participate in linux-next. Which in turn would make it convenient for you to issue pull requests to Linus (Torvalds) directly. Which would make you the MMC subsystem maintainer... So why not :-) Yours, Linus Walleij --

On Mon, 23 Aug 2010 21:48:29 +0100 Kyungmin Park's questions didn't seem adequately answered and the discussion kind of died. I updated the patch and merged it, but I'd like the outstanding question(s) resolved. ie: why do we add MMC_DDR_MODE, set it in brq.data.flags and then never use it? --

Marcel, as per our previous discussion -- what is your word on this? I'd be glad taking it once you Ack the bluetooth bits (which, as far as I understood from your last mail, don't have strong objections against any more). Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. --

Hi all, I retested the ext4 barrier mitigation patchset against a base of 2.6.36-rc1 + Tejun's flush_fua tree + Christoph's patches to change FS barrier semantics, and came up with this new spreadsheet: http://bit.ly/bWpbsT Here are the previous 2.6.35 results for convenience: http://bit.ly/c22grd The machine configurations are the same as with the previous (2.6.35) spreadsheet. It appears to be the case that Tejun and Christoph's patches to change barrier use into simpler cache flushes ...