This is almost certainly the last -rc in this series - things really
have calmed down, and I even considered just cutting 3.4 this weekend,
but felt that another week wouldn't hurt.
The appended shortlog gives a good overview - it's mostly random tiny
fixes for very small specific issues. The biggest commit (and the one
that might affect the most people) is likely the Nouveau i2c change,
and that one is really just a revert. It changes nouveau back to use
the generic i2c-algo-bit routines - the problem they had had been
fixed in the meantime, and the specialized i2c nouveau routines had
issues of their own.
The rest is mainly small changes in various areas: drivers
(networking, drm, scsi, sound and md) arch updates (arm, powerpc and
x86) and random other areas - core networking, a compat fix, stuff
like that. No scary changes.
So go forth and test. And don't send me any pull requests unless they
contain *only* regressions or fixes for really nasty bugs. No more of
these silly compiler warning fixes etc any more.
Linus
---
Alasdair G Kergon (1):
dm thin: correct module description
Andre Schramm (1):
ALSA: hdsp - Provide ioctl_compat
Andrei Emeltchenko (1):
e1000: Silence sparse warnings by correcting type
Andrew Morton (1):
xen/Kconfig: fix Kconfig layout
Ansis Atteka (1):
openvswitch: Release rtnl_lock if ovs_vport_cmd_build_info() failed.
Archit Taneja (1):
ARM: OMAP: Revert "ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields"
Ariel Elior (1):
bnx2x: bug fix when loading after SAN boot
Arnd Bergmann (1):
drivers/leds: correct __devexit annotations
Avi Kivity (1):
KVM: ia64: fix build due to typo
Axel Lin (1):
regulator: Fix the logic to ensure new voltage setting in valid range
Basil Gor (2):
vhost-net: fix handle_rx buffer size
macvtap: restore vlan header on user read
Ben Hutchings (2):
sfc: Fix division by zero when using one RX channel and no SR-IOV
ARM: orion5x: Fix GPIO enable bits for MPP9
Ben Skeggs (1):
drm/nouveau/i2c: resume use of i2c-algo-bit, rather than custom stack
Benjamin Herrenschmidt (3):
powerpc/irq: Fix bug with new lazy IRQ handling code
powerpc/irq: Make alignment & program interrupt behave the same
powerpc/irq: Fix another case of lazy IRQ state getting out of sync
Benjamin Poirier (1):
igb: fix rtnl race in PM resume path
Bj?rn Mork (1):
cdc_ether: Ignore bogus union descriptor for RNDIS devices
Bryan Wu (1):
MAINTAINERS: add maintainer for LED subsystem
Catalin Marinas (1):
kmemleak: Fix the kmemleak tracking of the percpu areas with !SMP
Chad Dupuis (1):
[SCSI] qla2xxx: Update version number to 8.04.00.03-k.
Chris Metcalf (1):
hugetlb: prevent BUG_ON in hugetlb_fault() -> hugetlb_cow()
Colin Cross (1):
ARM: 7414/1: SMP: prevent use of the console when using idmap_pgd
Dan Carpenter (1):
cifs: fix revalidation test in cifs_llseek()
Daniel Vetter (2):
drm/i915: disable sdvo hotplug on i945g/gm
drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+
David Gibson (1):
KVM: PPC: Book3S HV: Fix refcounting of hugepages
David Henningsson (1):
ALSA: HDA: Lessen CPU usage when waiting for chip to respond
David S. Miller (3):
sparc64: Do not clobber %g2 in xcall_fetch_glob_regs().
ipv4: Do not use dead fib_info entries.
Revert "net: maintain namespace isolation between vlan and real device"
David Vrabel (1):
xen/pci: don't use PCI BIOS service for configuration space accesses
Don Skidmore (1):
ixgbe: fix race condition with shutdown
Enrico Butera (1):
ARM: OMAP: igep0020: fix smsc911x dummy regulator id
Eric Dumazet (2):
iwlwifi: fix skb truesize underestimation
pktgen: fix crash at module unload
Eric W. Biederman (1):
connector/userns: replace netlink uses of cap_raised() with capable()
Franky Lin (1):
brcmfmac: fix a double spin_unlock_irqrestore issue in dpc
Giridhar Malavali (2):
[SCSI] qla2xxx: Block flash access from application when device
is initialized for ISP82xx.
[SCSI] qla2xxx: Proper completion to scsi-ml for scsi status
task_set_full and busy.
Gleb Natapov (2):
KVM: ensure async PF event wakes up vcpu from halt
KVM: Do not take reference to mm during async #PF
Guennadi Liakhovetski (3):
ASoC: sh: fix migor.c compilation
ARM: mach-shmobile: convert mackerel to use the generic MMC GPIO
hotplug helper
ARM: mach-shmobile: convert ag5evm to use the generic MMC GPIO
hotplug helper
Hugh Dickins (1):
mm: raise MemFree by reverting percpu_pagelist_fraction to 0
Ian Campbell (1):
ARM: kirkwood: add missing kexec.h include
James Bottomley (1):
[SCSI] fix oops in all legacy host adapters caused by 6f381fa
Jan Kiszka (1):
compat: Fix RT signal mask corruption via sigprocmask
Janusz Krzysztofik (1):
ARM: OMAP1: Amstrad Delta: Fix wrong IRQ base in FIQ handler
Jesse Gross (1):
openvswitch: Add length check when retrieving TCP flags.
Jiri Bohac (1):
bonding: don't increase rx_dropped after processing LACPDUs
Johannes Berg (1):
net: compare_ether_addr[_64bits]() has no ordering
John Fastabend (2):
ixgbe: dcb: BIT_APP_UPCHG not set by ixgbe_copy_dcb_cfg()
igb, ixgbe: netdev_tx_reset_queue incorrectly called from tx init path
Julia Lawall (1):
drivers/video/xen-fbfront.c: add missing cleanup code
Julien Ducourthial (1):
r8169: fix unsigned int wraparound with TSO
Konrad Rzeszutek Wilk (2):
xen/apic: Return the APIC ID (and version) for CPU 0.
xen/pte: Fix crashes when trying to see non-existent PGD/PMD/PUD/PTEs
Konstantin Khlebnikov (1):
proc/pid/pagemap: correctly report non-present ptes and holes between vmas
Kukjin Kim (1):
ARM: EXYNOS: fix ctrlbit for exynos5_clk_pdma1
Kuninori Morimoto (1):
ARM / mach-shmobile: sh73a0 SMP TWD boot regression fix
Larry Finger (1):
IA32 emulation: Fix build problem for modular ia32 a.out support
Laxman Dewangan (1):
regmap: fix possible memory corruption in regmap_bulk_read()
Linus Torvalds (1):
Linux 3.4-rc7
Magnus Damm (2):
ARM / mach-shmobile: r8a7779 SMP TWD boot regression fix
ARM / mach-shmobile: Invalidate caches when booting secondary cores
Marek Szyprowski (1):
ARM: EXYNOS: use s5p-timer for UniversalC210 board
Mark Brown (1):
regulator: Actually free the regulator in devm_regulator_put()
Mark Hills (1):
ALSA: echoaudio: Remove incorrect part of assertion
Mike Galbraith (1):
namespaces, pid_ns: fix leakage on fork() failure
Mike Snitzer (3):
dm thin: reinstate missing mempool_free in cell_release_singleton
dm thin: fix unprotected use of prepared_discards list
dm mpath: check if scsi_dh module already loaded before trying to load
Nicholas Bellinger (1):
target: Drop incorrect se_lun_acl release for dynamic -> explict
ACL conversion
Nicolas Dichtel (1):
sctp: check cached dst before using it
Paolo Bonzini (1):
[SCSI] virtio_scsi: fix TMF use-after-free
Pravin B Shelar (1):
openvswitch: Validation of IPv6 set port action uses IPv4 header
Rafael J. Wysocki (1):
MAINTAINERS: Add myself as the cpufreq maintainer
Rajkumar Manoharan (1):
Revert "ath9k_hw: Fix incorrect spur_freq_sd for AR9003"
Rolf Eike Beer (5):
parisc: add missing includes in asm/spinlock.h
parisc: add missing forward declarations in asm/hardware.h
parisc: drop include of asm/pdc.h from asm/hardware.h
parisc: add missing include of asm/page.h to asm/pgtable.h
parisc: move definition of PAGE0 to asm/page.h
Russ Anderson (1):
mm: nobootmem: fix sign extend problem in __free_pages_memory()
Sachin Kamat (1):
gpio/exynos: Fix compiler warnings when non-exynos machines are selected
Sasha Levin (1):
mm: fix division by 0 in percpu_pagelist_fraction()
Saurav Kashyap (1):
[SCSI] qla2xxx: Properly check for current state after the
fabric-login request.
Sha Zhengju (1):
memcg: free spare array to avoid memory leak
Stephen Boyd (1):
ks8851: Update link status during link change interrupt
Steve Dickson (1):
auth_gss: the list of pseudoflavors not being parsed correctly
Steven King (1):
m68knommu: enable qspi support when SPI_COLDFIRE_QSPI = m
Takashi Iwai (4):
ALSA: hda/realtek - Add a fixup for Acer Aspire 5739G
ALSA: hda/realtek - Add missing CD-input pin for MSI-7350 mobo
ALSA: hda/realtek - Call alc_auto_parse_customize_define()
always after fixup
Revert "ALSA: hda - Set codec to D3 forcibly even if not used"
Tarun Kanti DebBarma (1):
gpio/omap: fix incorrect initialization of omap_gpio_mod_init
Tejun Heo (3):
percpu: use KERN_CONT in pcpu_dump_alloc_info()
percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit
percpu: pcpu_embed_first_chunk() should free unused parts after
all allocs are complete
Thadeu Lima de Souza Cascardo (1):
ehea: fix losing of NEQ events when one event occurred early
Thomas Gleixner (1):
gpio: pch9: Use proper flow type handlers
Tim Bird (1):
ARM: 7410/1: Add extra clobber registers for assembly in kernel_execve
Vikas Chaudhary (1):
[SCSI] qla2xxx: Fix reset time out as qla2xxx not ack to reset request.
Will Deacon (2):
ARM: 7411/1: audit: fix treatment of saved ip register during
syscall tracing
ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless of endianness
On 05/13/2012 07:34 AM, Linus Torvalds wrote:
> This is almost certainly the last -rc in this series - things really
> have calmed down, and I even considered just cutting 3.4 this weekend,
> but felt that another week wouldn't hurt.
[...]
> So go forth and test. And don't send me any pull requests unless they
> contain *only* regressions or fixes for really nasty bugs.
Oh, I just noticed that 2 important fixes which fix boot failures on
PA-RISC and mn10300 architectures haven't made it to mainline yet.
The regression was introduced in the 3.4 merge window itself (by commit
5fbd036b55 "sched: Cleanup cpu_active madness").
Links to the original posting:
PA_RISC: http://marc.info/?l=linux-parisc&m=133241790810604&w=2
mn10300: http://marc.info/?l=linux-parisc&m=133241580509804&w=2
Mikulas confirmed that this fixes the boot failure on PA-RISC:
https://lkml.org/lkml/2012/5/8/97
Regards,
Srivatsa S. Bhat
On 13-May-12, at 3:56 PM, Srivatsa S. Bhat wrote:
> The regression was introduced in the 3.4 merge window itself (by
> commit
> 5fbd036b55 "sched: Cleanup cpu_active madness").
>
> Links to the original posting:
> PA_RISC: http://marc.info/?l=linux-parisc&m=133241790810604&w=2
If I had the above change, I get
CHK include/generated/compile.h
CC arch/parisc/kernel/smp.o
arch/parisc/kernel/smp.c: In function 'smp_cpu_init':
arch/parisc/kernel/smp.c:300:2: error: implicit declaration of
function 'notify_cpu_starting' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [arch/parisc/kernel/smp.o] Error 1
Dave
--
John David Anglin [email protected]
On 05/14/2012 01:38 AM, John David Anglin wrote:
> On 13-May-12, at 3:56 PM, Srivatsa S. Bhat wrote:
>
>> The regression was introduced in the 3.4 merge window itself (by commit
>> 5fbd036b55 "sched: Cleanup cpu_active madness").
>>
>> Links to the original posting:
>> PA_RISC: http://marc.info/?l=linux-parisc&m=133241790810604&w=2
>
>
> If I had the above change, I get
>
> CHK include/generated/compile.h
> CC arch/parisc/kernel/smp.o
> arch/parisc/kernel/smp.c: In function 'smp_cpu_init':
> arch/parisc/kernel/smp.c:300:2: error: implicit declaration of function
> 'notify_cpu_starting' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[1]: *** [arch/parisc/kernel/smp.o] Error 1
>
Sorry about that. I neither have the hardware nor the toolchain
to test it. I guess this problem doesn't exist for mn10300 since it
already includes linux/cpu.h when CONFIG_HOTPLUG_CPU=y
Does the below updated patch help for PA-RISC?
----
From: Srivatsa S. Bhat <[email protected]>
parisc/CPU hotplug: Add missing call to notify_cpu_starting()
The scheduler depends on receiving the CPU_STARTING notification, without
which we end up into a lot of trouble. So add the missing call to
notify_cpu_starting() in the bringup code.
Signed-off-by: Srivatsa S. Bhat <[email protected]>
---
arch/parisc/kernel/smp.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
index 0bb1d63..4dc7b79 100644
--- a/arch/parisc/kernel/smp.c
+++ b/arch/parisc/kernel/smp.c
@@ -31,6 +31,7 @@
#include <linux/delay.h>
#include <linux/bitops.h>
#include <linux/ftrace.h>
+#include <linux/cpu.h>
#include <linux/atomic.h>
#include <asm/current.h>
@@ -295,8 +296,13 @@ smp_cpu_init(int cpunum)
printk(KERN_CRIT "CPU#%d already initialized!\n", cpunum);
machine_halt();
- }
+ }
+
+ notify_cpu_starting(cpunum);
+
+ ipi_call_lock();
set_cpu_online(cpunum, true);
+ ipi_call_unlock();
/* Initialise the idle task for this CPU */
atomic_inc(&init_mm.mm_count);
On Mon, May 14, 2012 at 01:26:23AM +0530, Srivatsa S. Bhat wrote:
> On 05/13/2012 07:34 AM, Linus Torvalds wrote:
>
> > This is almost certainly the last -rc in this series - things really
> > have calmed down, and I even considered just cutting 3.4 this weekend,
> > but felt that another week wouldn't hurt.
> [...]
> > So go forth and test. And don't send me any pull requests unless they
> > contain *only* regressions or fixes for really nasty bugs.
>
>
> Oh, I just noticed that 2 important fixes which fix boot failures on
> PA-RISC and mn10300 architectures haven't made it to mainline yet.
>
> The regression was introduced in the 3.4 merge window itself (by commit
> 5fbd036b55 "sched: Cleanup cpu_active madness").
>
> Links to the original posting:
> PA_RISC: http://marc.info/?l=linux-parisc&m=133241790810604&w=2
> mn10300: http://marc.info/?l=linux-parisc&m=133241580509804&w=2
>
> Mikulas confirmed that this fixes the boot failure on PA-RISC:
> https://lkml.org/lkml/2012/5/8/97
Yes, indeed my c8000 boots again :-) Only had to add cpu.h for
notify_cpu_starting() to make it complile:
The scheduler depends on receiving the CPU_STARTING notification, without
which we end up into a lot of trouble. So add the missing call to
notify_cpu_starting() in the bringup code.
Signed-off-by: Srivatsa S. Bhat <[email protected]>
Acked-by: Mikulas Patocka <[email protected]>
Acked-by: Tobias Ulmer <[email protected]>
---
arch/parisc/kernel/smp.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
index 0bb1d63..4dc7b79 100644
--- a/arch/parisc/kernel/smp.c
+++ b/arch/parisc/kernel/smp.c
@@ -31,6 +31,7 @@
#include <linux/delay.h>
#include <linux/bitops.h>
#include <linux/ftrace.h>
+#include <linux/cpu.h>
#include <linux/atomic.h>
#include <asm/current.h>
@@ -295,8 +296,13 @@ smp_cpu_init(int cpunum)
printk(KERN_CRIT "CPU#%d already initialized!\n", cpunum);
machine_halt();
- }
+ }
+
+ notify_cpu_starting(cpunum);
+
+ ipi_call_lock();
set_cpu_online(cpunum, true);
+ ipi_call_unlock();
/* Initialise the idle task for this CPU */
atomic_inc(&init_mm.mm_count);
--
1.7.3.4
Thanks,
Tobias
>
> Regards,
> Srivatsa S. Bhat
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Yes, the revised change fixes the compilation error. I'll know in a
while if
my config boots.
Thanks,
Dave
On 13-May-12, at 4:28 PM, Srivatsa S. Bhat wrote:
> On 05/14/2012 01:38 AM, John David Anglin wrote:
>
>> On 13-May-12, at 3:56 PM, Srivatsa S. Bhat wrote:
>>
>>> The regression was introduced in the 3.4 merge window itself (by
>>> commit
>>> 5fbd036b55 "sched: Cleanup cpu_active madness").
>>>
>>> Links to the original posting:
>>> PA_RISC: http://marc.info/?l=linux-parisc&m=133241790810604&w=2
>>
>>
>> If I had the above change, I get
>>
>> CHK include/generated/compile.h
>> CC arch/parisc/kernel/smp.o
>> arch/parisc/kernel/smp.c: In function 'smp_cpu_init':
>> arch/parisc/kernel/smp.c:300:2: error: implicit declaration of
>> function
>> 'notify_cpu_starting' [-Werror=implicit-function-declaration]
>> cc1: some warnings being treated as errors
>> make[1]: *** [arch/parisc/kernel/smp.o] Error 1
>>
>
>
> Sorry about that. I neither have the hardware nor the toolchain
> to test it. I guess this problem doesn't exist for mn10300 since it
> already includes linux/cpu.h when CONFIG_HOTPLUG_CPU=y
>
> Does the below updated patch help for PA-RISC?
>
> ----
> From: Srivatsa S. Bhat <[email protected]>
>
> parisc/CPU hotplug: Add missing call to notify_cpu_starting()
>
> The scheduler depends on receiving the CPU_STARTING notification,
> without
> which we end up into a lot of trouble. So add the missing call to
> notify_cpu_starting() in the bringup code.
>
> Signed-off-by: Srivatsa S. Bhat <[email protected]>
> ---
>
> arch/parisc/kernel/smp.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
>
> diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
> index 0bb1d63..4dc7b79 100644
> --- a/arch/parisc/kernel/smp.c
> +++ b/arch/parisc/kernel/smp.c
> @@ -31,6 +31,7 @@
> #include <linux/delay.h>
> #include <linux/bitops.h>
> #include <linux/ftrace.h>
> +#include <linux/cpu.h>
>
> #include <linux/atomic.h>
> #include <asm/current.h>
> @@ -295,8 +296,13 @@ smp_cpu_init(int cpunum)
>
> printk(KERN_CRIT "CPU#%d already initialized!\n", cpunum);
> machine_halt();
> - }
> + }
> +
> + notify_cpu_starting(cpunum);
> +
> + ipi_call_lock();
> set_cpu_online(cpunum, true);
> + ipi_call_unlock();
>
> /* Initialise the idle task for this CPU */
> atomic_inc(&init_mm.mm_count);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> parisc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
John David Anglin [email protected]
On 13-May-12, at 4:40 PM, John David Anglin wrote:
> Yes, the revised change fixes the compilation error. I'll know in a
> while if
> my config boots.
I successfully booted 3.4-rc7 with this change on rp3440 (4 cpu smp).
My build also
included cache and other fixes that are being discussed on the parisc
list.
Dave
--
John David Anglin [email protected]
On Sun, May 13, 2012 at 5:42 PM, John David Anglin <[email protected]> wrote:
>
> I successfully booted 3.4-rc7 with this change on rp3440 (4 cpu smp). ?My
> build also
> included cache and other fixes that are being discussed on the parisc list.
Can somebody send the final patches with proper subject lines etc,
instead of hiding them in unrelated threads? I hate picking up patches
that I don't personally know from the middle of some random thread.
Linus
On 05/15/2012 10:54 PM, Linus Torvalds wrote:
> On Sun, May 13, 2012 at 5:42 PM, John David Anglin <[email protected]> wrote:
>>
>> I successfully booted 3.4-rc7 with this change on rp3440 (4 cpu smp). My
>> build also
>> included cache and other fixes that are being discussed on the parisc list.
>
> Can somebody send the final patches with proper subject lines etc,
> instead of hiding them in unrelated threads? I hate picking up patches
> that I don't personally know from the middle of some random thread.
>
Okay, here they are:
This is for PA-RISC:
---
From: Srivatsa S. Bhat <[email protected]>
Subject: [PATCH] parisc/CPU hotplug: Add missing call to notify_cpu_starting()
The scheduler depends on receiving the CPU_STARTING notification, without
which we end up into a lot of trouble. So add the missing call to
notify_cpu_starting() in the bringup code.
Signed-off-by: Srivatsa S. Bhat <[email protected]>
Acked-and-Tested-by: Mikulas Patocka <[email protected]>
Acked-and-Tested-by: Tobias Ulmer <[email protected]>
Tested-by: John David Anglin <[email protected]>
---
arch/parisc/kernel/smp.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
index 0bb1d63..4dc7b79 100644
--- a/arch/parisc/kernel/smp.c
+++ b/arch/parisc/kernel/smp.c
@@ -31,6 +31,7 @@
#include <linux/delay.h>
#include <linux/bitops.h>
#include <linux/ftrace.h>
+#include <linux/cpu.h>
#include <linux/atomic.h>
#include <asm/current.h>
@@ -295,8 +296,13 @@ smp_cpu_init(int cpunum)
printk(KERN_CRIT "CPU#%d already initialized!\n", cpunum);
machine_halt();
- }
+ }
+
+ notify_cpu_starting(cpunum);
+
+ ipi_call_lock();
set_cpu_online(cpunum, true);
+ ipi_call_unlock();
/* Initialise the idle task for this CPU */
atomic_inc(&init_mm.mm_count);
On 05/15/2012 11:59 PM, Srivatsa S. Bhat wrote:
> On 05/15/2012 10:54 PM, Linus Torvalds wrote:
>
>> On Sun, May 13, 2012 at 5:42 PM, John David Anglin <[email protected]> wrote:
>>>
>>> I successfully booted 3.4-rc7 with this change on rp3440 (4 cpu smp). My
>>> build also
>>> included cache and other fixes that are being discussed on the parisc list.
>>
>> Can somebody send the final patches with proper subject lines etc,
>> instead of hiding them in unrelated threads? I hate picking up patches
>> that I don't personally know from the middle of some random thread.
>>
>
>
> Okay, here they are:
>
This one is for mn10300:
---
From: Srivatsa S. Bhat <[email protected]>
Subject: [PATCH] mn10300/CPU hotplug: Add missing call to notify_cpu_starting()
The scheduler depends on receiving the CPU_STARTING notification, without
which we end up into a lot of trouble. So add the missing call to
notify_cpu_starting() in the bringup code.
Signed-off-by: Srivatsa S. Bhat <[email protected]>
---
arch/mn10300/kernel/smp.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/mn10300/kernel/smp.c b/arch/mn10300/kernel/smp.c
index 910dddf..9cd69ad 100644
--- a/arch/mn10300/kernel/smp.c
+++ b/arch/mn10300/kernel/smp.c
@@ -24,6 +24,7 @@
#include <linux/sched.h>
#include <linux/profile.h>
#include <linux/smp.h>
+#include <linux/cpu.h>
#include <asm/tlbflush.h>
#include <asm/bitops.h>
#include <asm/processor.h>
@@ -38,7 +39,6 @@
#include "internal.h"
#ifdef CONFIG_HOTPLUG_CPU
-#include <linux/cpu.h>
#include <asm/cacheflush.h>
static unsigned long sleep_mode[NR_CPUS];
@@ -874,10 +874,13 @@ static void __init smp_online(void)
cpu = smp_processor_id();
- local_irq_enable();
+ notify_cpu_starting(cpu);
+ ipi_call_lock();
set_cpu_online(cpu, true);
- smp_wmb();
+ ipi_call_unlock();
+
+ local_irq_enable();
}
/**
On Tue, May 15, 2012 at 11:29 AM, Srivatsa S. Bhat
<[email protected]> wrote:
>>
>> Can somebody send the final patches with proper subject lines etc,
>> instead of hiding them in unrelated threads? I hate picking up patches
>> that I don't personally know from the middle of some random thread.
>>
>
>
> Okay, here they are:
What part of "with proper subject lines" didn't you get?
Look at the subject line. Look at how you put the patch in the middle
of an old thread that was about something totally different.
This was *exactly* what I complained about. I don't want patches like this.
Linus
On 05/16/2012 12:12 AM, Linus Torvalds wrote:
> On Tue, May 15, 2012 at 11:29 AM, Srivatsa S. Bhat
> <[email protected]> wrote:
>>>
>>> Can somebody send the final patches with proper subject lines etc,
>>> instead of hiding them in unrelated threads? I hate picking up patches
>>> that I don't personally know from the middle of some random thread.
>>>
>>
>>
>> Okay, here they are:
>
> What part of "with proper subject lines" didn't you get?
>
> Look at the subject line. Look at how you put the patch in the middle
> of an old thread that was about something totally different.
>
> This was *exactly* what I complained about. I don't want patches like this.
>
Oops! Sorry about that! I will resend in a separate thread with appropriate
subject line.
Regards,
Srivatsa S. Bhat
On Wed, 2012-05-16 at 00:15 +0530, Srivatsa S. Bhat wrote:
> On 05/16/2012 12:12 AM, Linus Torvalds wrote:
>
> > On Tue, May 15, 2012 at 11:29 AM, Srivatsa S. Bhat
> > <[email protected]> wrote:
> >>>
> >>> Can somebody send the final patches with proper subject lines etc,
> >>> instead of hiding them in unrelated threads? I hate picking up patches
> >>> that I don't personally know from the middle of some random thread.
> >>>
> >>
> >>
> >> Okay, here they are:
> >
> > What part of "with proper subject lines" didn't you get?
> >
> > Look at the subject line. Look at how you put the patch in the middle
> > of an old thread that was about something totally different.
> >
> > This was *exactly* what I complained about. I don't want patches like this.
> >
>
>
> Oops! Sorry about that! I will resend in a separate thread with appropriate
> subject line.
If it helps, I've already imported it to the parisc fixes tree with a
corrected subject line. We still have this and the PA1.1 fix, when I
can confirm it's actually the complete fix for the boot panics.
James
On Sun, 13 May 2012, John David Anglin wrote:
> On 13-May-12, at 4:40 PM, John David Anglin wrote:
>
> > Yes, the revised change fixes the compilation error. I'll know in a while
> > if
> > my config boots.
>
>
> I successfully booted 3.4-rc7 with this change on rp3440 (4 cpu smp). My
> build also
> included cache and other fixes that are being discussed on the parisc list.
>
> Dave
Hi David
Can I download a series of your PA-RISC patches somewhere?
I applied this http://www.spinics.net/lists/linux-parisc/msg03352.html and
it improved stability for me (I had no gcc crashes since that, only
about two aptitude crashes).
How stable is it for you? Do you have some random crashes or not?
Mikulas
On 1-Aug-12, at 9:00 PM, Mikulas Patocka wrote:
>
>
> On Sun, 13 May 2012, John David Anglin wrote:
>
>> On 13-May-12, at 4:40 PM, John David Anglin wrote:
>>
>>> Yes, the revised change fixes the compilation error. I'll know in
>>> a while
>>> if
>>> my config boots.
>>
>>
>> I successfully booted 3.4-rc7 with this change on rp3440 (4 cpu
>> smp). My
>> build also
>> included cache and other fixes that are being discussed on the
>> parisc list.
>>
>> Dave
>
> Hi David
>
> Can I download a series of your PA-RISC patches somewhere?
>
> I applied this http://www.spinics.net/lists/linux-parisc/
> msg03352.html and
> it improved stability for me (I had no gcc crashes since that, only
> about two aptitude crashes).
>
> How stable is it for you? Do you have some random crashes or not?
Attached are my latest patch sets for linux-stable 3.4 and 3.5 branches.
There is no place to to download them directly. I added Jiri Kosina's
personality fix today to the 3.5 patch set. Otherwise, they are
similar.
In general, stability with 3.4 has been pretty good. I just started
testing
3.5 a couple of days ago. I went about three weeks without a random
crash with 3.4 after I removed Al Viro's restart patch. It was causing
problems with irq handling.
This is on 64-bit rp3440. I have been using it to build debian unstable
and test GCC 4.8. So, the machine gets a fair bit of exercise. In
the last
little while, it has been pretty easy to keep up with the changes in
unstable.
Sorry, I haven't had time to submit my changes. Some of the cache fixes
are a bit hard to explain.
Dave
--
John David Anglin [email protected]
On Wed, 1 Aug 2012, John David Anglin wrote:
> On 1-Aug-12, at 9:00 PM, Mikulas Patocka wrote:
>
> >
> >
> > On Sun, 13 May 2012, John David Anglin wrote:
> >
> > > On 13-May-12, at 4:40 PM, John David Anglin wrote:
> > >
> > > > Yes, the revised change fixes the compilation error. I'll know in a
> > > > while
> > > > if
> > > > my config boots.
> > >
> > >
> > > I successfully booted 3.4-rc7 with this change on rp3440 (4 cpu smp). My
> > > build also
> > > included cache and other fixes that are being discussed on the parisc
> > > list.
> > >
> > > Dave
> >
> > Hi David
> >
> > Can I download a series of your PA-RISC patches somewhere?
> >
> > I applied this http://www.spinics.net/lists/linux-parisc/msg03352.html and
> > it improved stability for me (I had no gcc crashes since that, only
> > about two aptitude crashes).
> >
> > How stable is it for you? Do you have some random crashes or not?
>
>
> Attached are my latest patch sets for linux-stable 3.4 and 3.5 branches.
> There is no place to to download them directly. I added Jiri Kosina's
> personality fix today to the 3.5 patch set. Otherwise, they are similar.
>
> In general, stability with 3.4 has been pretty good. I just started testing
> 3.5 a couple of days ago. I went about three weeks without a random
> crash with 3.4 after I removed Al Viro's restart patch. It was causing
> problems with irq handling.
Which restart patch do you mean?
> This is on 64-bit rp3440. I have been using it to build debian unstable
> and test GCC 4.8. So, the machine gets a fair bit of exercise. In the last
> little while, it has been pretty easy to keep up with the changes in unstable.
>
> Sorry, I haven't had time to submit my changes. Some of the cache fixes
> are a bit hard to explain.
>
> Dave
> --
> John David Anglin [email protected]
Thanks. For me the kernel with the patch works fine - it would be nice to
break it up to smaller pieces and submit it.
Mikulas
On 8/7/2012 2:41 PM, Mikulas Patocka wrote:
> Which restart patch do you mean?
http://www.spinics.net/lists/linux-parisc/msg04229.html
Dave
--
John David Anglin [email protected]