I have a business suggestion for you worth (US$17,300,000.00)contact me via my private email for more details (chenguan000@yahoo.com.hk) --

Hi, I was asked to submit this to stable since it's clearly a bug and easily triggerable from userspace. It has now been included in mainline, so here goes. /Jesper Juhl ---------- Forwarded message ---------- Date: Mon, 27 Dec 2010 14:16:03 GMT From: tip-bot for Jesper Juhl <jj@chaosbits.net> Reply-To: mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org, jj@chaosbits.net, tigran@aivazian.fsnet.co.uk, tglx@linutronix.de, shaohua.li@intel.com, mingo@elte.hu To: ...

The below patch fixes a typo "diable" to "disable". Please let me know if this is correct or not. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> --- drivers/scsi/lpfc/lpfc_init.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index b306579..a921f16 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -7661,7 +7661,7 @@ lpfc_pci_remove_one_s3(struct pci_dev ...

The below patch fixes a typo "diable" to "disable". Please let me know if this is correct or not. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> --- drivers/spi/dw_spi.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/spi/dw_spi.c b/drivers/spi/dw_spi.c index 7c3cf21..a3a065f 100644 --- a/drivers/spi/dw_spi.c +++ b/drivers/spi/dw_spi.c @@ -910,12 +910,12 @@ int __devinit dw_spi_add_host(struct dw_spi *dws) ret = init_queue(dws); if ...

The below patch fixes a typo "diable" to "disable". Please let me know if this is correct or not. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> --- drivers/media/video/tvp7002.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c index e63b40f..c799e4e 100644 --- a/drivers/media/video/tvp7002.c +++ b/drivers/media/video/tvp7002.c @@ -789,7 +789,7 @@ static int tvp7002_query_dv_preset(struct ...

The below patch fixes a typo "diable" to "disable". Please let me know if this is correct or not. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> --- drivers/spi/dw_spi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/spi/dw_spi.c b/drivers/spi/dw_spi.c index 0838c79..7c3cf21 100644 --- a/drivers/spi/dw_spi.c +++ b/drivers/spi/dw_spi.c @@ -592,7 +592,7 @@ static void pump_transfers(unsigned long data) spi_set_clk(dws, clk_div ? clk_div : ...

Please see attached an RFC of second set of patches that augments how Xen MMU deals with PFNs that point to physical devices. This patchset is still a development type so sharp edges present. Changelog: [since v1 https://lkml.org/lkml/2010/12/21/255]: - Diagrams of P2M included. - More conservative approach used (memory that is not populated or identity is considered "missing", instead of as identity). - Added IDENTITY_PAGE_FRAME bit to uniquely identify 1-1 mappings. - Optional ...

We tack on the IDENTITY_FRAME_BIT on all PFNs which have been elected during the E820 parsing to be identity mapping. This way, in case a freak occurs such that pfn_to_mfn(pfn)==pfn for non-identity PFNs we can guard against that and not consider it a 1-1 mapping. Also this will allows us to leverage this and tack on _PAGE_IOMAP on any page that has IDENTITY_FRAME_BIT set (see: "xen/mmu: Set _PAGE_IOMAP if PFN is in identity P2M."). Signed-off-by: Konrad Rzeszutek Wilk ...

If we find that the PFN is within the P2M as an identity make sure to tack on the _PAGE_IOMAP flag. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/xen/mmu.c | 19 +++++++++++++++---- 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index d470435..158d07a 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -828,7 +828,7 @@ static pteval_t pte_pfn_to_mfn(pteval_t val) if (val & _PAGE_PRESENT) { ...

With this patch, we diligently set regions that will be used by the balloon driver to be INVALID_P2M_ENTRY and under the ownership of the balloon driver. We are OK using the __set_phys_to_machine as we do not expect to be allocating any P2M middle or entries pages. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- arch/x86/include/asm/xen/page.h | 1 + arch/x86/xen/mmu.c | 12 ++++++------ arch/x86/xen/setup.c | 7 ++++++- drivers/xen/balloon.c ...

Our P2M tree structure is a three-level. On the leaf nodes we set the Machine Frame Number (MFN) of the PFN. What this means is that when one does: pfn_to_mfn(pfn), which is used when creating PTE entries, you get the real MFN of the hardware. When Xen sets up a guest it initially populates a array which has descending MFN values, as so: idx: 0, 1, 2 [0x290F, 0x290E, 0x290D, ..] so pfn_to_mfn(2)==0x290D. If you start, restart many guests that list starts looking quite random. We ...

Read Attachment File For More Details About the donation Fund, Thank You.

My first step was to simply restore the behaviour to 2.3.36 and then look for an alternate patch. I'd like to give any such patch at least the chance for smoketesting by QA (and the machines here) before asking Linus to pull ;-) There is one interesting difference between the BIOS and KMS clock setting for the Lenovo U160; the BIOS is able to set n=1, whereas we can't find a suitable clock with just a single wire. Maybe we can fix the U160 and save 0.1W as well! As far as I am aware, only ...

On Thu, 30 Dec 2010 19:01:34 +0000 Did you want to disable SSC entirely on gen5+ just so we can get all the known machines working? It's possible it could add some wifi or sound interference, but that's better than not having a display (most of the time). -- Jesse Barnes, Intel Open Source Technology Center --

Hi, I just went to check the current kernel for fun on my old P4-M based laptop. I got the following message. # DISTCC_HOSTS='' make oldconfig scripts/kconfig/conf --oldconfig Kconfig warning: (AX88796_93CX6 && NETDEVICES && NET_ETHERNET && AX88796 || RTL8180 && NETDEVICES && WLAN && MAC80211 && PCI && EXPERIMENTAL || RTL8187 && NETDEVICES && WLAN && MAC80211 && USB || ADM8211 && NETDEVICES && WLAN && MAC80211 && PCI && EXPERIMENTAL || RT2400PCI && NETDEVICES && WLAN && RT2X00 && PCI || ...

Agreed 100%. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

Signed-off-by: Tejun Heo <tj@kernel.org> --- arch/x86/kernel/apic/bigsmp_32.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/apic/bigsmp_32.c b/arch/x86/kernel/apic/bigsmp_32.c index dd32a9b..bc7ed04 100644 --- a/arch/x86/kernel/apic/bigsmp_32.c +++ b/arch/x86/kernel/apic/bigsmp_32.c @@ -45,6 +45,12 @@ static unsigned long bigsmp_check_apicid_present(int bit) return 1; } +static int bigsmp_early_logical_apicid(int cpu) +{ + /* on ...

Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Pekka Enberg <penberg@kernel.org> --- arch/x86/kernel/smpboot.c | 6 +----- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 083e99d..4de6a00 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -165,8 +165,6 @@ static void unmap_cpu_to_node(int cpu) #endif #ifdef CONFIG_X86_32 -static int boot_cpu_logical_apicid; - u8 ...

The mapping between cpu/apicid and node is done via apicid_to_node[] on 64bit and apicid_2_node[] + apic->x86_32_numa_cpu_node() on 32bit. This difference makes it difficult to further unify 32 and 64bit NUMA handling. This patch unifies it by replacing both apicid_to_node[] and apicid_2_node[] with __apicid_to_node[] array, which is accessed by two accessors - set_apicid_to_node() and numa_cpu_node(). On 64bit, numa_cpu_node() always consults __apicid_to_node[] directly while 32bit goes ...

Now that everything else is unified, NUMA initialization can be unified too. * numa_init_array() and init_cpu_to_node() are moved from numa_64 to numa. * numa_32::initmem_init() is updated to call numa_init_array() and setup_arch() to call init_cpu_to_node() on 32bit too. * x86_cpu_to_node_map is now initialized to NUMA_NO_NODE on 32bit too. This is safe now as numa_init_array() will initialize it early during boot. This makes NUMA mapping fully initialized before ...

On x86_32, the mapping between cpu and logical apic ID differs depending on the specific apic implementation in use. The mapping is initialized while bringing up CPUs; however, this makes early inits ignore memory topology. Add a x86_32 specific apic->x86_32_early_logical_apicid() which is called early during boot to query the mapping. The mapping is later verified against the result of init_apic_ldr(). The method is allowed to return BAD_APICID if it can't be determined early. noop ...

Unlike x86_64, on x86_32, the mapping from cpu to logical apicid may vary depending on apic in use. cpu_2_logical_apicid[] array is used for this mapping. Replace it with early percpu variable x86_cpu_to_logical_apicid to make it better aligned with other mappings. Signed-off-by: Tejun Heo <tj@kernel.org> --- arch/x86/include/asm/apic.h | 4 ---- arch/x86/include/asm/smp.h | 3 +++ arch/x86/kernel/apic/apic.c | 11 +++++++++++ arch/x86/kernel/apic/es7000_32.c | ...

Currently, cpu -> logical apic id translation is done by apic->cpu_to_logical_apicid() callback which may or may not use x86_cpu_to_logical_apicid. This is unnecessary as it should always equal logical_smp_processor_id() which is known early during CPU bring up. Initialize x86_cpu_to_logical_apicid after apic->init_apic_ldr() in setup_local_APIC() and always use x86_cpu_to_logical_apicid for cpu -> logical apic id mapping. Signed-off-by: Tejun Heo <tj@kernel.org> --- ...

Both functions are used only in 32bit. Put them inside CONFIG_X86_32. This is to prepare for logical apicid handling update. - Cyrill Gorcunov spotted that I forgot to move declarations in ipi.h under CONFIG_X86_32. Fixed. Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Pekka Enberg <penberg@kernel.org> Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com> --- arch/x86/include/asm/ipi.h | 8 ++++---- arch/x86/kernel/apic/ipi.c | 4 ++-- 2 files changed, 6 insertions(+), 6 ...

Ccing linux-nfs@vger.kernel.org What filesystem are you exporting on the server? What is the NFS version? Is this nfsroot, autofs or an ordinary nfs mount? In short, how can we reproduce this? Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com --

Please cc the poor hapless NFS people too, who probably otherwise wouldn't see it. And Arnd just in case it might be locking-related. Trond, any ideas? The sysrq thing does imply that it's stuck in some busy-loop in fs/nfs/dir.c, and line 647 is get_cache_page(), which in turn implies that the endless loop is either the loop in readdir_search_pagecache() _or_ in a caller. In particular, the EBADCOOKIE case in the caller (nfs_readdir) looks suspicious. What protects us from endless streams of ...

On Thu, Dec 30, 2010 at 10:24 AM, Trond Myklebust Umm. Sure there is. Just make sure that you return the uncached entry to user space, rather than loop forever. Looping forever in kernel space is a bad idea. How about just changing the "continue" into a "break" for the "uncached readdir returned success". No halting problems, no excuses. There is absolutely _no_ excuse for an endless loop in kernel mode. Certainly not "the other end is incompetent". EVERYBODY is incompetent sometimes. ...

Hi Trond, Yeah, good idea. I had that ~2min after sending my report during This is an nfsroot of /home/ukl/nfsroot/tx28 which is a symlink to a directory on a different partition. I don't know the filesystem of my homedir as it resides on a server I have no access to, but I asked the admin, so I can follow up with this info later (I'd suspect ext3, too). The real root directory is on ext3 (rw,noatime). The serving nfs-server is Debian's nfs-kernel-server 1:1.2.2-1. nfs-related kernel ...

Hello, (Sent to the output of ./scripts/get_maintainer.pl -f kernel/sched_fair.c - please CC me as I am not on-list.) Some of our customer's systems running a 2.6.32.11 kernel.org kernel crash, leaving the attached partial oops on screen. I doubt it is a hardware problem since we've already replaced one system and the problem came back. I run the values after "Code:" from the bottom of the oops through linux-2.6/scripts/decode/code as described in Documentation/oops-tracing.txt, and ...

This looks like a use-after-free bug somewhere in drivers/md/raid10.c. Pekka --

Does reverting commit 4e78064f42ad474ce9c31760861f7fb0cfc22532 ("md: Fix possible deadlock with multiple mempool allocations.") fix the problem? --

Hi, What should a block device driver need to do to get all read/write requests without any buffering from the page cache? I think the iscsi initiation does this. This is needed to get an existing pseudo block device to function as a shared storage so that a cluster filesystem (gpfs/ocfs) can be put on it (nbd). Folkert van Heusden -- Nagios user? Check out CoffeeSaint - the versatile Nagios status viewer! ...

From: Tapio Vihuri <tapio.vihuri@nokia.com> ECI stands for (Enhancement Control Interface). ECI is better known as Multimedia Headset for Nokia phones. If headset has many buttons, like play, vol+, vol- etc. then it is propably ECI accessory. Among several buttons ECI accessory contains memory for storing several parameters. ECI input driver provides the following features: - reading ECI configuration memory - ECI buttons as input events Signed-off-by: Tapio Vihuri ...

From: Tapio Vihuri <tapio.vihuri@nokia.com> Gives platform data for ECI accessory input driver and ECI bus controller driver. Signed-off-by: Tapio Vihuri <tapio.vihuri@nokia.com> --- arch/x86/platform/mrst/mrst.c | 59 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 59 insertions(+), 0 deletions(-) diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c index 79ae681..60dca78 100644 --- a/arch/x86/platform/mrst/mrst.c +++ ...

Joe, Patch looks good, however.. I am unclear from your description whether the patch fixes the problem (I would presume so). Or does it take a long time --

From: Manjunatha Halli <manjunatha_halli@ti.com> Mauro and the list, This is the v8 version of the TI WL128x FM V4L2 drivers patchset. This introduces wl128x folder under the drivers/media/radio which cater to FM core on Texas Instrument's WL128x (also compatible with WL127x) WiLink chipsets. WL128x's FM can work in either Rx or Tx mode, and V4L2 interfaces are provided for both. ** patch description ** Texas Instrument's WL128x chipset packs BT, FM, GPS and WLAN in a single die with ...

This define seems to be a leftover from previous versions and should be removed. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco --

From: Manjunatha Halli <manjunatha_halli@ti.com> Signed-off-by: Manjunatha Halli <manjunatha_halli@ti.com> --- drivers/media/radio/wl128x/Kconfig | 17 +++++++++++++++++ drivers/media/radio/wl128x/Makefile | 6 ++++++ 2 files changed, 23 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/wl128x/Kconfig create mode 100644 drivers/media/radio/wl128x/Makefile diff --git a/drivers/media/radio/wl128x/Kconfig b/drivers/media/radio/wl128x/Kconfig new file mode ...

From: Manjunatha Halli <manjunatha_halli@ti.com> These are the sources for the common interfaces required by the FM V4L2 driver for TI WL127x and WL128x chips. These implement the FM channel-8 protocol communication with the chip. This makes use of the Shared Transport as its transport. Signed-off-by: Manjunatha Halli <manjunatha_halli@ti.com> --- drivers/media/radio/wl128x/fmdrv_common.c | 1970 +++++++++++++++++++++++++++++ drivers/media/radio/wl128x/fmdrv_common.h | 402 ++++++ 2 ...

From: Manjunatha Halli <manjunatha_halli@ti.com> This has implementation for FM TX functionality. It communicates with FM V4l2 module and FM common module. Signed-off-by: Manjunatha Halli <manjunatha_halli@ti.com> --- drivers/media/radio/wl128x/fmdrv_tx.c | 438 +++++++++++++++++++++++++++++++++ drivers/media/radio/wl128x/fmdrv_tx.h | 37 +++ 2 files changed, 475 insertions(+), 0 deletions(-) create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.c create mode 100644 ...

From: Manjunatha Halli <manjunatha_halli@ti.com> Signed-off-by: Manjunatha Halli <manjunatha_halli@ti.com> --- drivers/media/radio/Kconfig | 3 +++ drivers/media/radio/Makefile | 1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 83567b8..4529bc7 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -452,4 +452,7 @@ config RADIO_TIMBERDALE found behind the Timberdale FPGA on ...

This commit shows oops in zram_inc_stat() which does not exist in staging tree version of zram. Its actually a problem with zram version as present in project's own repository where we allocate struct zram_stats_cpu upon device initialization. OTOH, In mainline/staging version of zram, we allocate struct stats upfront, so this oops cannot happen in mainline version. So, this commit is not even applicable for mainline/staging tree. My I will now end development on local project ...

.. and apparently it oopses without it. See commit 7e24cce38a99f3 which added the code that you now remove. You were cc'd on it, I don't think we got any reply to it. So no. I'm not taking this without way more explanations of why the original problem isn't a problem any more. Linus --

Oops, good catch! Thanks. johannes --

There's a containers@vger mailing list for this stuff, you might have better I've been coming up to speed on this area recently: openvz has a lot of stuff that isn't in the main kernel, but it's based on an approach that didn't get merged into the kernel (using new syscalls to control container stuff). Instead Google's rewrite of sgi's cgroup stuff went in for process grouping (based on the cgroup filesystem), and a half-dozen different types of namespaces are based on flags to clone(), and ...

CC netdev This rings a bell here, could you try to apply commit 482964e56e1320cb7952faa1932d8ecf59c4bf75 (net: Fix the condition passed to sk_wait_event()) This commit was included in 2.6.36, so you could also try 2.6.36.2 kernel. http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=48296... Thanks --

There are some interrupts that are true edge triggered in nature. If not marked IRQ_PENDING, when disabled, they will be lost. Use the set_type callback to assign the correct flow type handler for shared peripheral interrupts. Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org> --- This came to light when a edge triggered interrupt was supposed to wakeup the sytem. The flow handler was set to the default handle_level_irq. On the resume path the flow handler was invoked right ...

Yes, the fix is already in the Linus' tree: I'm not sure what happened to the last patch. Is there a new version? If so, is it going to be pushed through the i2c tree, or should I take it? Rafael --

Jean appears to be on holiday for the Christmas vacation. I do have a new version which I'll post later today. Since it depends on the patch protoyping the generic API calls which the SPI patch also depends on it'd probably be best to merge via your tree. --

How about leaving it that way during the merge window even? That would help people sending git pull requests that add new dependencies on CONFIG_EMBEDDED. David can submit another patch that removes the temporary CONFIG_EMBEDDED option along with any new users in -rc2 or for 2.6.39 then. Arnd --

Nice! For all patches: Reviewed-by: Ingo Molnar <mingo@elte.hu> Ingo --

The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option is used to configure any non-standard kernel with a much larger scope than only small devices. This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes references to the option in the same file. Followup patches will fix the remainder of the occurrences in the tree. Calling the option "EXPERT" more accurately represents its intention: only expert users who understand the impact of the configuration ...

CONFIG_EMBEDDED has been renamed to CONFIG_EXPERT, so fix it in the drivers/ directory. Signed-off-by: David Rientjes <rientjes@google.com> --- drivers/acpi/Kconfig | 2 +- drivers/ata/Kconfig | 2 +- drivers/base/Kconfig | 2 +- drivers/char/Kconfig | 10 +++--- drivers/cpufreq/Kconfig | 2 +- drivers/firmware/Kconfig | 2 +- drivers/gpu/drm/Kconfig | 2 +- ...

CONFIG_EMBEDDED has been renamed to CONFIG_EXPERT, so fix it in the block/ directory. Signed-off-by: David Rientjes <rientjes@google.com> --- block/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/block/Kconfig b/block/Kconfig --- a/block/Kconfig +++ b/block/Kconfig @@ -2,7 +2,7 @@ # Block layer core configuration # menuconfig BLOCK - bool "Enable the block layer" if EMBEDDED + bool "Enable the block layer" if EXPERT default y ...

CONFIG_EMBEDDED has been renamed to CONFIG_EXPERT, so fix it in the fs/ directory. Signed-off-by: David Rientjes <rientjes@google.com> --- fs/Kconfig | 2 +- fs/proc/Kconfig | 6 +++--- fs/sysfs/Kconfig | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/Kconfig b/fs/Kconfig --- a/fs/Kconfig +++ b/fs/Kconfig @@ -51,7 +51,7 @@ config EXPORTFS tristate config FILE_LOCKING - bool "Enable POSIX file locking API" if EMBEDDED + bool "Enable POSIX ...

What's the plan for those people who are currently on (say) 2.6.35, next upgrade to 2.6.39 or .40, and thus miss the 9th temporary patch? They'll run 'make oldconfig' - if they get prompted, do we want to add a line to the help text that says "This used to be called EMBEDDED"?

On Thu, 30 Dec 2010 10:49:33 +0800 (SGT) For some expressions, the ternary operator is more compact & readable. For others (like this one imo) it doesn't really add anything, so I prefer the if statement. In this case I think the if statement is more readable since it communicates that we're overriding the default value on certain generations (i.e. it's a standalone clause). -- Jesse Barnes, Intel Open Source Technology Center --

From: Randy Dunlap <randy.dunlap@oracle.com> Fix build errors by adding "depends on USB": ERROR: "usb_register_driver" [drivers/staging/se401/se401.ko] undefined! ERROR: "usb_alloc_urb" [drivers/staging/se401/se401.ko] undefined! ERROR: "usb_submit_urb" [drivers/staging/se401/se401.ko] undefined! ERROR: "usb_control_msg" [drivers/staging/se401/se401.ko] undefined! ERROR: "usb_free_urb" [drivers/staging/se401/se401.ko] undefined! ERROR: "usb_kill_urb" [drivers/staging/se401/se401.ko] ...

From: Randy Dunlap <randy.dunlap@oracle.com> Fix build errors by adding "depends on USB": ERROR: "usb_register_driver" [drivers/staging/usbvideo/vicam.ko] undefined! ERROR: "usb_bulk_msg" [drivers/staging/usbvideo/vicam.ko] undefined! ERROR: "usb_control_msg" [drivers/staging/usbvideo/vicam.ko] undefined! ERROR: "usb_deregister" [drivers/staging/usbvideo/vicam.ko] undefined! ERROR: "usb_get_dev" [drivers/staging/usbvideo/usbvideo.ko] undefined! ERROR: "usb_put_dev" ...

Oops, missed one. Here's an updated pull req. The following changes since commit 387c31c7e5c9805b0aef8833d1731a5fe7bdea14: Linux 2.6.37-rc8 (2010-12-28 17:05:48 -0800) are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 merge-spi Gregory CLEMENT (1): spi/omap2_mcspi.c: Force CS to be in inactive state after off-mode transition Jate Sujjavanich (1): spi/m68knommu: Coldfire QSPI platform support drivers/spi/coldfire_qspi.c | 2 +- ...

Hi Stephen, Sorry about all that. I haven't had a chance to play with that code base for a while and the requisite demand Linus was looking for hasn't been very vocal. I'd say just drop my tree for now if its a nuisance, and I will re-post it to you once I have a chance to give it some love. Thanks,

Commit 4be2c95d added a null field to align the taskstats structure but the discussion centered around ia64. The issue exists on other platforms with inefficient unaligned access and adding them piecemeal would be an unmaintainable mess. This patch uses Dave Miller's suggestion of using a combination of CONFIG_64BIT && !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to determine whether alignment is needed. Note that this will cause breakage on those platforms with applications like iotop ...

Please do so. That discussion went on for a long time over many emails and multiple iterations of the patch. I personally have forgotten the reasoning and if I could remember it, I wouldn't remember which version of the patch it applied to. Applying a patch which is *known* to break *known* userspace applications is a quite extraordinary thing to do. We owe it to people to fully explain the reasoning. --

Hi Rafael. I don't have linux on that laptop anymore. Regards, Fabio --

This FREQ has been there for years. Not that it makes it smart, and I'll obviously send Ben's patch upstream for 2.6.38. Still processing incoming mail queue :-( -- Krzysztof Halasa --

I can confirm that this "regression" still exists with the kernel 2.6.37-rc8. The Call Trace is basically the same: ... Kernel panic - not syncing: map_single ... Pid 935, comm: NetworkManager Tainted call trace panic+oxbf/0x200 ? default_spin_lock_flags+0x9/0x10 ?swiotlb_tlb_map_single+0x1ce/0x250 ?map_single+0x46/0x60 swiotlb_map_page+0xa6/0xf ... and then the FREEZE ... only a hard reset brings to live (with 2.6.36-2) Linux. carlos. --

Fixed in 2.6.37-rc7. --

Thanks for the update. Rafael --

Does reverting commit 448f53a "drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks" help? Rafael --

Yes. I was bit worried by the interaction between vb->lock and the pte locks, and thought it safer to keep it outside. Though I suppose kernel Since kernel mappings don't have a formal pte lock to rely on for synchronization, each subsystem defines its own ad-hoc one. In this case that's probably vb->lock anyway, so the fix is to move That looks OK, but it interferes with my plans to use apply_to_page_range(_batch) to replace all this code. J --

Hi Kevin, --

How come? Is it just a cleanup? --

I'd suggest posting patches against the latest -git. --

Hi, As I wrote in "[PATCH R2 0/7] Xen memory balloon driver with memoryhotplug Strange. I tested it with this script and I received: 0001-mm-Add-add_registered_memory-to-memory-hotplug-API.txt has no obvious style problems and is ready for submission. I do not know why my e-mail was mangled. For your convenience I am sending this patch as attachment. Empty lines are added for better readability (it is my opinion) however, I do not insist to leave this patch with that ...

Hello Arnd, imx_add_platform_device could be implemented as platform_device_register_resndata(NULL, name, id, res, num_resources, data, size_data) I came up with those because many machines (sharing the same SoC) share Well this is a matter of taste, I'm quite happy with the current approach. [1] http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=blob;f=arch/arm/plat-mx... -- Pengutronix e.K. | ...

It is correct to run init_ibs() only on one cpu. It only checks the ibs capabilities and sets up pci devices (if necessary). It runs only on one cpu but operates with the local APIC and some MSRs, thus it is better to disable preemption. The cpu setup itself runs in op_amd_setup_ctrs() which is per cpu. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center --

No. It will work as before since you are still in init's mount namespace. -- Kirill A. Shutemov --

You can create a new instance of rpc_pipefs using 'newinstance' mountoption. Then you can specify which rpc_pipefs to use with 'rpcmount' mountoption of nfs mount. If none specifed, '/var/lib/nfs/rpc_pipefs' uses by default. If no rpcmount mountoption, no rpc_pipefs was found at '/var/lib/nfs/rpc_pipefs' and we are in init's mount namespace, we use init_rpc_pipefs. -- Kirill A. Shutemov --

I was pointing out it's been done before. I'd prefer autodetecting it so new namespaces and the base namespace don't have magic policy _or_ require different mount invocations. An ability to change the default for a value is less appealing than not needing the value in the first place. And changing the default would probably have to be per-container anyway to be useful. (Which isn't _quite_ the same as per-namespace since you can chroot without CLONE_NEWNS.) (I keep thinking back ...

/proc/sys/kernel/hotplug exists to tell the kernel where to find the hotplug binary. Once upon a time /sys/hotplug was the default value, and that was there to overwrite it. (They changed the default to blank (disabled) not due to policy reasons, but due to adding the netlink hotplug notification mechanism and making that the default.) I bring that up to point out that the general consensus about policy in the kernel seems to be "when you really really can't avoid having any, make a sane ...

Hi Angelo, Just send the patch to the netdev mailing list. For additional instructions see Documentation/SubmitChecklist and Documentation/SubmittingPatches. Once you submitted you patch you can track the status of your patch at http://patchwork.ozlabs.org/project/netdev/list/. baruch -- ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: ...

Hi all, Joe, about the debug line inside dm9000_interrupt, //dm9000_dbg(db, 3, "entering %s\n", __func__); nothing change, first browsing attempt crashed the board with the same call stack trace: [ 4.660000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 54.340000] BUG: spinlock recursion on CPU#0, swapper/0 [ 54.340000] lock: 00191244, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [ 54.340000] Stack from 001a1b44: [ 54.340000] 001a1b70 000ad968 ...

Hi Greg and All, infinite thanks, i solved finally my issue and the board is fully working. I used IRQ7 line, casually, and unfortunately it was wrong. IRQ7 is a special autovectored interrupt, in particular, it is an EDGE interrupt, and not a LEVEL interrupt like IRQ1 to 6. I used IRQ1 now, a normal level interrupt, and everything works perfect. So i have dm9000 and MCF5307 (big-endian cpu) fully working with 32 bit bus straight wired D0:31 to the dm9000, and would like to share my patch ...

This bug has been already fixed in nf-next-2.6: http://git.kernel.org/?p=linux/kernel/git/kaber/nf-next-2.6.git;a=commitdiff;h=ae90bde... Thanks. -- Regards, Changli Gao(xiaosuo@gmail.com) --

Yes it does. Patrick is probably too busy right now to push fixes to David. --

On Thu, Dec 30, 2010 at 11:58 AM, Geert Uytterhoeven You are right. Take it as a typo or copy/paste error ;). Ping --

Never mind. I'm lazy (that's not to say someone is too). I redid the test: Before running "xset dpms force standby": http://vin-soft.org/~raa/public/test/intel_reg_dumper-before After running "sleep 3" http://vin-soft.org/~raa/public/test/intel_reg_dumper-suspend After running "xset dpms force on; sleep 3" http://vin-soft.org/~raa/public/test/intel_reg_dumper-xset-on After closing and opening the lid (displays backlight is back) ...

It appeared to be the easiest fix for the machines I had to hand and was confirmed by several people with identical machines. However, it definitely caused a regression for working panels and therefore it will be reverted. -Chris -- Chris Wilson, Intel Open Source Technology Centre --

CONFIG_B43=m CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_PCMCIA=y CONFIG_B43_SDIO=y CONFIG_B43_PIO=y CONFIG_B43_PHY_LP=y CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y # CONFIG_B43_DEBUG is not set CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_HWRNG=y CONFIG_B43LEGACY_DEBUG=y CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y # ...

Thanks for finding the problem. Obviously, I did not go back far enough in the record to find the commit that you implicate. Please show the output of "egrep "B43|RNG|RANDOM" .config". It should not matter, but please try the attached patch. Larry

I believe I can confirm the bug does not directly belong to b43: I created a second via-rng driver (just copied via-rng.c to via-rng2.c and changed the via_rng.name) and modprobed it. I blacklisted b43 to keep it out of the game. Virtually the same crash dump as with b43 shows up when I modprobe via-rng2 after via-rng is loaded already. Attached is a dmesg excerpt from a 2.6.37-rc7 kernel built with Larrys hwrng_debug patch applied (which basically calls dump_stack() ...

The head of the rng_list is damaged. It is initialized at compile time and should be OK. To help discover the order in which hwrng_register() is called, apply the attached patch. Run it once with commit 84c164a34ffe67908a installed, and once with it reverted. Thanks, Larry

Yes, that looks like what I'd expect. --

There's nothing new about NUMA emulation on x86_64, it's existed for well over four years (we've been using it at Google since 2.6.18, see Documentation/x86/x86_64/fake-numa-for-cpusets). Shaohui's patches are completely seperate and add hotplug emulation. You _could_ boot with a very minimal amount of memory and then hotplug all the emulated nodes like numa=fake does, but you may find it difficult to parse the e820 and interleave the nodes appropriately over the set of physical nodes in ...

Will rebase & repost soon. Thanks. -- tejun --

Hello, again. Okay, after going through the changes, here are some thoughts FWIW. I'm doubtful the direction was the correct one. NUMA emulation, almost by definition, doesn't vary too much depending on the underlying hardware and how it's configured. All that's necessary is the physical node map an apicid to nid mapping, which can and probably should be represented in common form regardless of emulation and the emulation code should simply manipulate the parsed information. The ...

It should normally only wake up once, at exactly the time that the other thread releases the mutex. What exactly happens depends on the relative priorities of the two lock holders and whether all CPUs are busy already. If there is nothing else to do and the blocking thread is made runnable by giving up the mutex, it will run immediately. Even if we keep the current thread running, the jiffie timer is rather meaningless and Actually, the timeout is the time after which the waiter gives up ...

Looks good to me. Acked-by: Arnd Bergmann <arnd@arndb.de> --

http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_getcpuclockid.3.html this one works. ok... it takes a pthread_t for identifying the thread. -- torben Hohn --

Acked-by: Hugh Dickins <hughd@google.com> for all seven: thanks. --

Hello, Okay, applied these three. I suppose the same goes for the newer patches? I'll ping you there. Thanks. -- tejun --

The two patches above from x86/numa that create the conflict should be dependent only on 4e76f4e67a (x86, numa: Avoid compiling NUMA emulation functions without CONFIG_NUMA_EMU), so cherry-pick them into x86/bootmem? --

FYI, either the x86/numa or the x86/bootmem changes cause the early boot crash below. Config attached. Thanks, Ingo ----------------> Linux version 2.6.37-rc8-tip-01830-g7937b8c-dirty (mingo@sirius) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #76886 SMP Thu Dec 30 12:12:49 CET 2010 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 ...

your new x86/numa have setup_physnodes(addr, max_addr, acpi, amd); fake_physnodes(acpi, amd, num_nodes); instead of acpi_fake_nodes(nodes, num_nodes); in numa_emulation() Thanks Yinghai --

That would hurt more, I think. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

x86/bootmem could be based on x86/numa - the latter is stable so it's not like we'll have to undo it from under x86/bootmem. We can then send it to Linus once x86/numa is upstream. Btw., i suspect we want to use x86/memblock instead of x86/bootmem? Thanks, Ingo --

caused by 4645b6af9427: x86: Use early pre-allocated page table buffer top-down 32 bit fixmap will use the pre-allocated range too. it needs range to be continuous... please drop 4645b6af9427: x86: Use early pre-allocated page table buffer top-down 3c417751e4f0: x86: Rename e820_table_* to pgt_buf_* and will send out new version of x86: Rename e820_table_* to pgt_buf_* Thanks Yinghai --

I assume this patch is a prereq for the rest of the series. Should I merge it via the devicetree tree when I pick up the other patches? It looks okay to me. One comment below, but not one that would prevent picking up this patch. if you add + map_len = data_len; ...this can be simplified to: - early_iounmap(data, PAGE_SIZE); --

Mostly looks good. Some comments below. 0 means NO_IRQ on x86 and most architectures. I will change this when Why is the physical address being passed in when the virtual address --

This one is already applied to my next-devicetree branch --

Hi Peter, Since this series is based on the tip tree, these should be merged via the same route. Aside from the comments below, I'm okay with patches 1 & 2 going in for 2.6.38 (assuming NO_IRQ is fixed). I've picked up patch 12 since it is a generic fix. I haven't made a decision on the remaining 14 yet. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

Yes, please. Acked-by: H. Peter Anvin <hpa@zytor.com> -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

It's in my -next branch now. g. --

Entire set: Acked-by: David Daney <ddaney@caviumnetworks.com> I am basing my modifications for Octeon perf counters on this set. David Daney --

Sorry for the delay in responding - but I've been very busy, amongst other things working on the "per-chroot" module, which now works in a very basic but sufficient mode. If anyone else would find it useful, I'll fill it out some more and post it to this list. I'd like to see this "subterfuge.net" - but I'm unable to connect with HTTP: $ curl http://subterfuge.net --trace-ascii /dev/fd/2 == Info: About to connect() to subterfuge.net port 80 (#0) == Info: Trying 184.82.15.90... == Info: ...

There's no one embedded setup on any platform, but one of the few constants of embedded development is trying to eliminate unnecessary requirements. Just on standard-ish PC hardware I've seen people try to stick Linux in the BIOS flash (generally not enough room), I've seen people try to stick it as the first stage PXE payload, there's the fun and games with kexec of emergency kernels for crash dumps... If the capability to skip an unnecessary bootloader was available, people would use ...

Hmmm, I shouldn't be sending email at 1:30 in the morning. The above statement is not really true. One of the use-cases on ARM is using a device tree with existing firmware that doesn't pass a dt blob. Right now there are two possible methods for doing this. Option one is to link the .dtbs in the the kernel proper and point to them from the machine struct. The dtb would be used when a matching machine id is passed by the firmware. Option 2 is to select the correct .dtb with a kernel boot ...

Right, that was rather obvious, thanks for taking a look! Now that I have your attention, do you expect to be able to prepare a proper patch for 2.6.38? I don't have any experience with this file system, nor do I have useful ways of testing it, so that would be appreciated. Nick already volunteered to test patches, but I guess it would make more sense if you could do the patch. Arnd --