[PATCH] UBI: Fix PEB leak in wear_leveling_worker()
get_peb_for_wl() removes the PEB from the free list.
If the WL subsystem detects that no wear leveling is needed
it cancels the operation and drops the gained PEB.
In this case we have to put the PEB back into the free list.
This issue was introduced with commit ed4b7021c
(UBI: remove PEB from free tree in get_peb_for_wl()).
Cc: stable@vger.kernel.org # 3.7.x
Signed-off-by: Richard Weinberger rich...@nod.at
---
drivers/mtd/ubi/wl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 5df49d3..c95bfb1 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1069,6 +1069,9 @@ static int wear_leveling_worker(struct ubi_device *ubi,
struct ubi_work *wrk,
if (!(e2-ec - e1-ec = UBI_WL_THRESHOLD)) {
dbg_wl(no WL needed: min used EC %d, max free EC %d,
e1-ec, e2-ec);
+
+ /* Give the unused PEB back */
+ wl_tree_add(e2, ubi-free);
goto out_cancel;
}
self_check_in_wl_tree(ubi, e1, ubi-used);
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.11-rc6 genetlink locking fix offends lockdep
3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race)
gives me the lockdep trace below at startup.
Hmm. Yes, I see now how this happens, not sure why I didn't run into it.
The problem is that genl_family_rcv_msg() is called with the genl_lock
held, and then calls netlink_dump_start() with it held, creating a
genl_lock-cb_mutex dependency, but obviously the dump continuation is
the other way around.
We could use the semaphore instead, I believe, but I don't really
understand the mutex vs. semaphore well enough to be sure that's
correct.
johannes
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..6cfa646 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -792,7 +792,7 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct
netlink_callback *cb)
bool need_locking = chains_to_skip || fams_to_skip;
if (need_locking)
- genl_lock();
+ down_read(cb_lock);
for (i = chains_to_skip; i GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -815,7 +815,7 @@ errout:
cb-args[1] = n;
if (need_locking)
- genl_unlock();
+ up_read(cb_lock);
return skb-len;
}
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock
Prevent crash_kexec() from deadlocking of ioapic_lock. When crash_kexec()
is executed on a cpu, the cpu will get ioapic_lock in disable_IO_APIC().
So if the cpu gets NMI while locking ioapic_lock, a deadlock wiil happen.
In this patch, ioapic_lock is initialized before disable_IO_APIC().
To confirm this deadlocking, you'll set up as follows:
1. Add mdelay(1000) after raw_spin_lock_irqsave() in
native_ioapic_set_affinity()@arch/x86/kernel/apic/io_apic.c
Although the deadlocking can occur without this modification, it will
increase the potential of the deadlocking problem.
2. Build and install the kernel
3. Set up the OS which will run panic() and kexec when NMI is injected
# echo kernel.unknown_nmi_panic=1 /etc/sysctl.conf
# vim /etc/default/grub
add nmi_watchdog=0 crashkernel=256M in GRUB_CMDLINE_LINUX line
# grub2-mkconfig
4. Reboot the OS
5. Run following command for each vcpu on the guest
# while true; do echo CPU num /proc/irq/IO-APIC-edge or
IO-APIC-fasteoi/smp_affinitity; done;
By running this command, cpus will get ioapic_lock for setting affinity.
6. Inject NMI (push a dump button or execute 'virsh inject-nmi domain' if you
use VM)
After injecting NMI, panic() is called in an nmi-handler context.
Then, kexec will normally run in panic(), but the operation will be stopped
by deadlock of ioapic_lock in crash_kexec()-machine_crash_shutdown()-
native_machine_crash_shutdown()-disable_IO_APIC()-clear_IO_APIC()-
clear_IO_APIC_pin()-ioapic_read_entry().
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andi Kleen a...@linux.intel.com
Cc: Seiji Aguchi seiji.agu...@hds.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Cc: Joerg Roedel j...@8bytes.org
Cc: Zhang Yanfei zhangyan...@cn.fujitsu.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Gleb Natapov g...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc: linux-ker...@vger.kernel.org
Cc: stable@vger.kernel.org
---
arch/x86/include/asm/apic.h|2 ++
arch/x86/kernel/apic/io_apic.c |5 +
arch/x86/kernel/crash.c|4
3 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f8119b5..ddb06af 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -715,4 +715,6 @@ static inline void exiting_ack_irq(void)
ack_APIC_irq();
}
+extern void ioapic_lock_init(void);
+
#endif /* _ASM_X86_APIC_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..2816c07 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1534,6 +1534,11 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
}
}
+void ioapic_lock_init(void)
+{
+ raw_spin_lock_init(ioapic_lock);
+}
+
__apicdebuginit(void) print_IO_APIC(int ioapic_idx)
{
union IO_APIC_reg_00 reg_00;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 74467fe..ea039d5 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -129,6 +129,10 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
lapic_shutdown();
#if defined(CONFIG_X86_IO_APIC)
+ /*
+* Prevent crash_kexec() from deadlocking of ioapic_lock.
+*/
+ ioapic_lock_init();
disable_IO_APIC();
#endif
#ifdef CONFIG_HPET_TIMER
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: don't wait for TX status forever
From: Johannes Berg johannes.b...@intel.com
TX status notification can get lost, or the frames could
get stuck on the queue, so don't wait for the callback
from the driver forever and instead time out after half
a second.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg johannes.b...@intel.com
(cherry picked from commit cb236d2d713cff83d024a82b836757d9e2b50715)
Conflicts:
net/mac80211/mlme.c
Signed-off-by: Luciano Coelho luciano.coe...@intel.com
---
net/mac80211/mlme.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 741448b..940ea7d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,10 +31,12 @@
#include led.h
#define IEEE80211_AUTH_TIMEOUT (HZ / 5)
+#define IEEE80211_AUTH_TIMEOUT_LONG(HZ / 2)
#define IEEE80211_AUTH_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_AUTH_WAIT_ASSOC (HZ * 5)
#define IEEE80211_ASSOC_TIMEOUT(HZ / 5)
+#define IEEE80211_ASSOC_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_ASSOC_MAX_TRIES 3
@@ -3461,10 +3463,13 @@ static int ieee80211_probe_auth(struct
ieee80211_sub_if_data *sdata)
if (tx_flags == 0) {
auth_data-timeout = jiffies + IEEE80211_AUTH_TIMEOUT;
- ifmgd-auth_data-timeout_started = true;
+ auth_data-timeout_started = true;
run_again(ifmgd, auth_data-timeout);
} else {
- auth_data-timeout_started = false;
+ auth_data-timeout =
+ round_jiffies_up(jiffies + IEEE80211_AUTH_TIMEOUT_LONG);
+ auth_data-timeout_started = true;
+ run_again(ifmgd, auth_data-timeout);
}
return 0;
@@ -3501,7 +3506,11 @@ static int ieee80211_do_assoc(struct
ieee80211_sub_if_data *sdata)
assoc_data-timeout_started = true;
run_again(sdata-u.mgd, assoc_data-timeout);
} else {
- assoc_data-timeout_started = false;
+ assoc_data-timeout =
+ round_jiffies_up(jiffies +
+IEEE80211_ASSOC_TIMEOUT_LONG);
+ assoc_data-timeout_started = true;
+ run_again(sdata-u.mgd, assoc_data-timeout);
}
return 0;
--
1.7.10.4
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARC: gdbserver breakage in Big-Endian configuration #1
Hi Greg,
I'd posted these patches for stable backport. Do I need to do anything more to
get them included.
https://patchwork.kernel.org/patch/2841153/ [1/2] ARC: gdbserver breakage in
Big-Endian configuration #1https://patchwork.kernel.org/patch/2841153/]
https://patchwork.kernel.org/patch/2841158/ [2/2] ARC: gdbserver breakage in
Big-Endian configuration #2https://patchwork.kernel.org/patch/2841158/
Thx,
-Vineet
On 08/08/2013 07:23 PM, Vineet Gupta wrote:
Exception handling keeps additional state (whether exception was Trap
and if it was due to a breakpoint) in pt_regs-event, a bitfield member
unsigned long orig_r8:16, event:16;
A bitfield esentially has an offset and a length. What I wasn't
aware of was that, bitfields in a union loose the offset attribute
and all of them are laid out at offset 0.
This obviously means that both @event and @orig_r8 will be incorrectly
referenced to at same 0 offset by C generated code which is
certainly wrong, not because both members are accessed, but because asm
code updates it at different address.
In Little Endian config, @event is at offset 0 and @orig_r8 (not
actively used at all) clashing with it is OK. However in Big Endian
config,
ST 0x_, [addr]
writes 0x to @event (offset 2 in memory) while C code references
it from 0.
Needless to say, this causes ptrace machinery to not detect the breakpoint
scenario (and incorrect stop_pc returned to gdbserver).
--8---
Thi issue is already fixed in mainline 3.11 kernel as part of commit:
502a0c775c7f0a ARC: pt_regs update #5
However that patch has lot more changes than I would like backporting,
hence this seperate change.
--8---
Reported-by: Noam Camus no...@ezchip.commailto:no...@ezchip.com
Cc: stable@vger.kernel.orgmailto:stable@vger.kernel.org # [3.9 and 3.10
only]
Tested-by: Anton Kolesov akole...@synopsys.commailto:akole...@synopsys.com
Signed-off-by: Vineet Gupta vgu...@synopsys.commailto:vgu...@synopsys.com
---
arch/arc/include/asm/ptrace.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
index 6179de7..2046a89 100644
--- a/arch/arc/include/asm/ptrace.h
+++ b/arch/arc/include/asm/ptrace.h
@@ -52,12 +52,14 @@ struct pt_regs {
/*to distinguish bet excp, syscall, irq */
union {
+ struct {
#ifdef CONFIG_CPU_BIG_ENDIAN
/* so that assembly code is same for LE/BE */
unsigned long orig_r8:16, event:16;
#else
unsigned long event:16, orig_r8:16;
#endif
+ };
long orig_r8_word;
};
};
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock
* Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote:
Prevent crash_kexec() from deadlocking of ioapic_lock.
s/of/on
When crash_kexec() is executed on a cpu, the cpu will get
ioapic_lock in disable_IO_APIC(). So if the cpu gets NMI
while locking ioapic_lock, a deadlock wiil happen. In
s/will
this patch, ioapic_lock is initialized before
disable_IO_APIC().
To confirm this deadlocking, you'll set up as follows:
s/deadlocking/deadlock
1. Add mdelay(1000) after raw_spin_lock_irqsave() in
native_ioapic_set_affinity()@arch/x86/kernel/apic/io_apic.c
Although the deadlocking can occur without this modification, it will
increase the potential of the deadlocking problem.
s/deadlocking/deadlock
2. Build and install the kernel
3. Set up the OS which will run panic() and kexec when NMI is injected
# echo kernel.unknown_nmi_panic=1 /etc/sysctl.conf
# vim /etc/default/grub
add nmi_watchdog=0 crashkernel=256M in GRUB_CMDLINE_LINUX line
# grub2-mkconfig
4. Reboot the OS
5. Run following command for each vcpu on the guest
# while true; do echo CPU num /proc/irq/IO-APIC-edge or
IO-APIC-fasteoi/smp_affinitity; done;
By running this command, cpus will get ioapic_lock for setting affinity.
6. Inject NMI (push a dump button or execute 'virsh inject-nmi domain' if
you
use VM)
After injecting NMI, panic() is called in an nmi-handler context.
Then, kexec will normally run in panic(), but the operation will be stopped
by deadlock of ioapic_lock in crash_kexec()-machine_crash_shutdown()-
s/of/on
native_machine_crash_shutdown()-disable_IO_APIC()-clear_IO_APIC()-
clear_IO_APIC_pin()-ioapic_read_entry().
I suppose we could do this patch if it's a common
occurance.
A few minor details need fixing:
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andi Kleen a...@linux.intel.com
Cc: Seiji Aguchi seiji.agu...@hds.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Cc: Joerg Roedel j...@8bytes.org
Cc: Zhang Yanfei zhangyan...@cn.fujitsu.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Gleb Natapov g...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc: linux-ker...@vger.kernel.org
Cc: stable@vger.kernel.org
---
arch/x86/include/asm/apic.h|2 ++
arch/x86/kernel/apic/io_apic.c |5 +
arch/x86/kernel/crash.c|4
3 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f8119b5..ddb06af 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -715,4 +715,6 @@ static inline void exiting_ack_irq(void)
ack_APIC_irq();
}
+extern void ioapic_lock_init(void);
+
#endif /* _ASM_X86_APIC_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..2816c07 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1534,6 +1534,11 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
}
}
+void ioapic_lock_init(void)
+{
+ raw_spin_lock_init(ioapic_lock);
+}
Please name this ioapic_zap_locks() to make clear that this
is crash handling related.
+
__apicdebuginit(void) print_IO_APIC(int ioapic_idx)
{
union IO_APIC_reg_00 reg_00;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 74467fe..ea039d5 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -129,6 +129,10 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
lapic_shutdown();
#if defined(CONFIG_X86_IO_APIC)
Please enhance this #ifdef while at it.
+ /*
+ * Prevent crash_kexec() from deadlocking of ioapic_lock.
+ */
s/of/on.
Also, single-line comment can go /* here */.
+ ioapic_lock_init();
disable_IO_APIC();
#endif
#ifdef CONFIG_HPET_TIMER
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.11-rc6 genetlink locking fix offends lockdep
On 2013/8/19 16:00, Johannes Berg wrote:
3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race)
gives me the lockdep trace below at startup.
Hmm. Yes, I see now how this happens, not sure why I didn't run into it.
The problem is that genl_family_rcv_msg() is called with the genl_lock
held, and then calls netlink_dump_start() with it held, creating a
genl_lock-cb_mutex dependency, but obviously the dump continuation is
the other way around.
We could use the semaphore instead, I believe, but I don't really
understand the mutex vs. semaphore well enough to be sure that's
correct.
johannes
it is useless, the logic need to modify or otherwise it will still call lockdep
trace.
maybe i could send a patch for it, if you wish.
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..6cfa646 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -792,7 +792,7 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct
netlink_callback *cb)
bool need_locking = chains_to_skip || fams_to_skip;
if (need_locking)
- genl_lock();
+ down_read(cb_lock);
for (i = chains_to_skip; i GENL_FAM_TAB_SIZE; i++) {
n = 0;
@@ -815,7 +815,7 @@ errout:
cb-args[1] = n;
if (need_locking)
- genl_unlock();
+ up_read(cb_lock);
return skb-len;
}
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: mos7720: fix big-endian control requests
Fix endianess bugs in parallel-port code which caused corrupt control-requests to be issued on big-endian machines. Reported-by: kbuild test robot fengguang...@intel.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold jhov...@gmail.com --- Here's another endianess fix detected by sparse after a recent change to these lines which reproduced the endianess bugs. Thanks, Johan drivers/usb/serial/mos7720.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c index b013001..c724ed5 100644 --- a/drivers/usb/serial/mos7720.c +++ b/drivers/usb/serial/mos7720.c @@ -382,8 +382,8 @@ static int write_parport_reg_nonblock(struct mos7715_parport *mos_parport, } urbtrack-setup-bRequestType = (__u8)0x40; urbtrack-setup-bRequest = (__u8)0x0e; - urbtrack-setup-wValue = get_reg_value(reg, dummy); - urbtrack-setup-wIndex = get_reg_index(reg); + urbtrack-setup-wValue = cpu_to_le16(get_reg_value(reg, dummy)); + urbtrack-setup-wIndex = cpu_to_le16(get_reg_index(reg)); urbtrack-setup-wLength = 0; usb_fill_control_urb(urbtrack-urb, usbdev, usb_sndctrlpipe(usbdev, 0), -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.11-rc6 genetlink locking fix offends lockdep
On Mon, 2013-08-19 at 19:00 +0800, Ding Tianhong wrote: On 2013/8/19 16:00, Johannes Berg wrote: 3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race) gives me the lockdep trace below at startup. Hmm. Yes, I see now how this happens, not sure why I didn't run into it. The problem is that genl_family_rcv_msg() is called with the genl_lock held, and then calls netlink_dump_start() with it held, creating a genl_lock-cb_mutex dependency, but obviously the dump continuation is the other way around. We could use the semaphore instead, I believe, but I don't really understand the mutex vs. semaphore well enough to be sure that's correct. johannes it is useless, the logic need to modify or otherwise it will still call lockdep trace. I don't believe so, the semaphore and cb_mutex don't have a dependency yet, afaict. maybe i could send a patch for it, if you wish. What do you mean? johannes -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [3.10.y] NFC: llcp: Fix non blocking sockets connections
This is a backport for the linux-3.10.y stable branch
commit b4011239a08e7e6c2c6e970dfa9e8ecb73139261 upstream
Without the new LLCP_CONNECTING state, non blocking sockets will be
woken up with a POLLHUP right after calling connect() because their
state is stuck at LLCP_CLOSED.
That prevents userspace from implementing any proper non blocking
socket based NFC p2p client.
Signed-off-by: Samuel Ortiz sa...@linux.intel.com
---
net/nfc/llcp.h |1 +
net/nfc/llcp_sock.c |8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/nfc/llcp.h b/net/nfc/llcp.h
index ff8c434..f924dd2 100644
--- a/net/nfc/llcp.h
+++ b/net/nfc/llcp.h
@@ -19,6 +19,7 @@
enum llcp_state {
LLCP_CONNECTED = 1, /* wait_for_packet() wants that */
+ LLCP_CONNECTING,
LLCP_CLOSED,
LLCP_BOUND,
LLCP_LISTEN,
diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index 380253e..7522c37 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -571,7 +571,7 @@ static unsigned int llcp_sock_poll(struct file *file,
struct socket *sock,
if (sk-sk_shutdown == SHUTDOWN_MASK)
mask |= POLLHUP;
- if (sock_writeable(sk))
+ if (sock_writeable(sk) sk-sk_state == LLCP_CONNECTED)
mask |= POLLOUT | POLLWRNORM | POLLWRBAND;
else
set_bit(SOCK_ASYNC_NOSPACE, sk-sk_socket-flags);
@@ -722,14 +722,16 @@ static int llcp_sock_connect(struct socket *sock, struct
sockaddr *_addr,
if (ret)
goto sock_unlink;
+ sk-sk_state = LLCP_CONNECTING;
+
ret = sock_wait_state(sk, LLCP_CONNECTED,
sock_sndtimeo(sk, flags O_NONBLOCK));
- if (ret)
+ if (ret ret != -EINPROGRESS)
goto sock_unlink;
release_sock(sk);
- return 0;
+ return ret;
sock_unlink:
nfc_llcp_put_ssap(local, llcp_sock-ssap);
--
1.7.10.4
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: build failure after merge of the libata tree
On Sun, Aug 18, 2013 at 08:18:55PM -0700, Terry Suereth wrote: Per my original patch, 0x3x26 in code should be 0x3726 (as in the unpatched version). I refer to x26 in comments as a forward-looking assumption, but AFAIK only 3726 and 3826 exist at this time. Heh... No idea how that happened. Fixed. Sorry about the trouble. -- tejun -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARC: gdbserver breakage in Big-Endian configuration #1
On Mon, Aug 19, 2013 at 09:08:49AM +, Vineet Gupta wrote: Hi Greg, I'd posted these patches for stable backport. Do I need to do anything more to get them included. https://patchwork.kernel.org/patch/2841153/ [1/2] ARC: gdbserver breakage in Big-Endian configuration #1https://patchwork.kernel.org/patch/2841153/] https://patchwork.kernel.org/patch/2841158/ [2/2] ARC: gdbserver breakage in Big-Endian configuration #2https://patchwork.kernel.org/patch/2841158/ I ignored them as I thought you were submitting them for upstream inclusion. If they are already in Linus's tree, then take a look at the file, Documentation/stable_kernel_rules.txt for how to send a patch for inclusion into a stable release (hint, I need to know the git commit id that the patch has in Linus's tree, which I didn't see anywhere here.) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Move kvm_guest_enter, exit closer to sie
Attached is a backport of the following patch, with git commit id: 2b29a9fdcb92bfc6b6f4c412d71505869de61a56 This patch is intended for 3.10-stable tree. Dominik Dingel (1): Move kvm_guest_enter,exit closer to sie arch/s390/kvm/kvm-s390.c | 21 ++--- 1 files changed, 14 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Move kvm_guest_enter,exit closer to sie
Any uaccess between guest_enter and guest_exit could trigger a page fault,
the page fault handler would handle it as a guest fault and translate a
user address as guest address.
Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com
---
arch/s390/kvm/kvm-s390.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index c1c7c68..698fb82 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -622,14 +622,25 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
kvm_s390_deliver_pending_interrupts(vcpu);
vcpu-arch.sie_block-icptcode = 0;
- preempt_disable();
- kvm_guest_enter();
- preempt_enable();
VCPU_EVENT(vcpu, 6, entering sie flags %x,
atomic_read(vcpu-arch.sie_block-cpuflags));
trace_kvm_s390_sie_enter(vcpu,
atomic_read(vcpu-arch.sie_block-cpuflags));
+
+ /*
+* As PF_VCPU will be used in fault handler, between guest_enter
+* and guest_exit should be no uaccess.
+*/
+ preempt_disable();
+ kvm_guest_enter();
+ preempt_enable();
rc = sie64a(vcpu-arch.sie_block, vcpu-run-s.regs.gprs);
+ kvm_guest_exit();
+
+ VCPU_EVENT(vcpu, 6, exit sie icptcode %d,
+ vcpu-arch.sie_block-icptcode);
+ trace_kvm_s390_sie_exit(vcpu, vcpu-arch.sie_block-icptcode);
+
if (rc) {
if (kvm_is_ucontrol(vcpu-kvm)) {
rc = SIE_INTERCEPT_UCONTROL;
@@ -639,10 +650,6 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
rc = kvm_s390_inject_program_int(vcpu, PGM_ADDRESSING);
}
}
- VCPU_EVENT(vcpu, 6, exit sie icptcode %d,
- vcpu-arch.sie_block-icptcode);
- trace_kvm_s390_sie_exit(vcpu, vcpu-arch.sie_block-icptcode);
- kvm_guest_exit();
memcpy(vcpu-run-s.regs.gprs[14], vcpu-arch.sie_block-gg14, 16);
return rc;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] UBI: Fix PEB leak in wear_leveling_worker()
On Mon, 2013-08-19 at 08:48 +0200, Richard Weinberger wrote: get_peb_for_wl() removes the PEB from the free list. If the WL subsystem detects that no wear leveling is needed it cancels the operation and drops the gained PEB. In this case we have to put the PEB back into the free list. This issue was introduced with commit ed4b7021c (UBI: remove PEB from free tree in get_peb_for_wl()). Cc: stable@vger.kernel.org # 3.7.x Signed-off-by: Richard Weinberger rich...@nod.at Pushed to linux-ubi.git, thanks. And special thanks for taking care about Ccing -stable. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[3.10][3.8][3.5] ARM: Fix FIQ code on VIVT CPUs (was Re: [PATCH 076/133] ARM: update FIQ support for relocation of vectors)
Thanks Aaro. I'll apply 2ba85e7 ARM: Fix FIQ code on VIVT CPUs to 3.8-stable. Greg KH and Luis Henriques: Heads up! 3.10-stable and 3.5-stable also need 2ba85e7 but it isn't marked cc: stable. -Kamal On Mon, 2013-08-19 at 00:09 +0300, Aaro Koskinen wrote: On Fri, Aug 16, 2013 at 03:33:38PM -0700, Kamal Mostafa wrote: 3.8.13.7 -stable review patch. If anyone has any objections, please let me know. -- From: Russell King rmk+ker...@arm.linux.org.uk commit e39e3f3ebfef03450cf7bfa7a974a8c61f7980c8 upstream. FIQ should no longer copy the FIQ code into the user visible vector page. Instead, it should use the hidden page. This change makes that happen. FYI, this patch introduced regression (kernel crash) at least on Amstrad E1 board (where FIQ is used for the keyboard). See the following thread: http://marc.info/?t=13758316993r=1w=2 So any stable kernels where this patch was added should also take: commit 2ba85e7af4c639d933c9a87a6d7363f2983d5ada Author: Russell King rmk+ker...@arm.linux.org.uk Date: Thu Aug 8 11:51:21 2013 +0100 ARM: Fix FIQ code on VIVT CPUs That patch fixes the regression. A. signature.asc Description: This is a digitally signed message part
Re: [3.10][3.8][3.5] ARM: Fix FIQ code on VIVT CPUs (was Re: [PATCH 076/133] ARM: update FIQ support for relocation of vectors)
On Mon, Aug 19, 2013 at 09:02:23AM -0700, Kamal Mostafa wrote: Thanks Aaro. I'll apply 2ba85e7 ARM: Fix FIQ code on VIVT CPUs to 3.8-stable. Greg KH and Luis Henriques: Heads up! 3.10-stable and 3.5-stable also need 2ba85e7 but it isn't marked cc: stable. There's others from that branch which are probably also needed but I want them to sit in -rc for a bit before I request them to move into the stable trees - in case anyone finds anything more from the security fixes a while back. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi there! So i'm looking for husband!
vgctm trmljqkbdp vnvyarei jnxhebc otqhdkjyd xxevtp xkfjss M N Q R Y K P K N L T V gouevuchh Y Y U V H P P B R O cuqrd ceaecghyoi cbdbbxtlqpjqyhlwraui xrnzgfhtv lfzfgsz dtzcjsk wrwcx T H Z U C A I H F W H Z S Z D R kqsmctdqwdkxvgor M U V Y G C C V R S M Y Nattachment: vivew.jpg
Linux 3.6.11.7
I'm announcing the release of the 3.6.11.7 kernel. The updated 3.6.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git v3.6-stable The patch can be downloaded at: https://www.kernel.org/pub/linux/kernel/projects/rt/3.6/stable/patch-3.6.11.7.xz thanks, -- Steve MAINTAINERS |1 + Makefile |2 +- arch/arm/include/asm/cacheflush.h |4 +- arch/arm/mm/flush.c | 33 arch/arm/mm/nommu.c |6 + arch/tile/lib/exports.c |2 + arch/x86/Kconfig |1 + arch/x86/include/asm/irq_remapping.h |2 + arch/x86/kernel/early-quirks.c| 20 +++ arch/x86/kvm/x86.c|5 +- arch/x86/xen/time.c | 17 +- block/genhd.c |2 +- crypto/algapi.c |3 +- crypto/algboss.c | 15 +- crypto/api.c |6 - crypto/internal.h |6 + drivers/acpi/acpica/hwxfsleep.c |8 +- drivers/ata/libahci.c |3 +- drivers/ata/libata-acpi.c | 35 +++- drivers/ata/libata-core.c |2 + drivers/ata/libata.h |2 + drivers/block/nbd.c |9 +- drivers/cdrom/cdrom.c |2 +- drivers/clk/clk.c |1 + drivers/dma/pl330.c |4 +- drivers/gpu/drm/radeon/radeon_ring.c | 10 ++ drivers/hv/ring_buffer.c |2 +- drivers/hv/vmbus_drv.c|2 +- drivers/input/touchscreen/cyttsp_core.c |2 +- drivers/iommu/intel_irq_remapping.c | 10 ++ drivers/iommu/irq_remapping.c |6 + drivers/iommu/irq_remapping.h |1 + drivers/net/ethernet/freescale/gianfar_ptp.c |1 + drivers/net/ethernet/realtek/8139cp.c |1 + drivers/net/ethernet/renesas/sh_eth.c | 15 +- drivers/net/phy/phy.c |2 +- drivers/net/team/team.c |2 +- drivers/net/team/team_mode_roundrobin.c |2 + drivers/net/wan/dlci.c| 26 ++- drivers/net/wireless/ath/ath9k/htc_drv_main.c |2 +- drivers/net/wireless/iwlwifi/dvm/rxon.c |2 +- drivers/net/wireless/rtlwifi/rtl8192cu/rf.c |2 +- drivers/pci/probe.c |8 +- drivers/pcmcia/at91_cf.c |4 +- drivers/power/charger-manager.c |2 +- drivers/rtc/rtc-rv3029c2.c|2 +- drivers/scsi/osd/osd_uld.c|2 +- drivers/scsi/qla2xxx/tcm_qla2xxx.c|6 +- drivers/scsi/sd.c |2 +- drivers/target/iscsi/iscsi_target_erl0.c |4 +- drivers/usb/gadget/f_mass_storage.c |2 + drivers/usb/host/xhci-mem.c |4 + drivers/usb/host/xhci-plat.c |1 + drivers/usb/serial/ti_usb_3410_5052.c |3 +- drivers/usb/serial/ti_usb_3410_5052.h |4 +- fs/cifs/cifs_unicode.h|8 +- fs/cifs/cifsencrypt.c |6 +- fs/cifs/inode.c |5 + fs/exec.c | 16 +- fs/ext3/namei.c |7 +- fs/ext4/extents.c |4 +- fs/ext4/inode.c |4 +- fs/ext4/mballoc.c | 11 +- fs/ext4/namei.c |7 +- fs/hpfs/map.c |3 +- fs/hpfs/super.c |8 +- fs/jbd2/journal.c |3 +- fs/jbd2/transaction.c |2 +- fs/nfsd/nfs4xdr.c |2 +- fs/ocfs2/xattr.c | 10 ++ fs/ubifs/dir.c| 54 -- include/linux/hugetlb.h | 16 ++ include/linux/nbd.h |1 + include/linux/perf_event.h|3 +- include/linux/rculist_nulls.h |7 +- include/linux/socket.h|3 + kernel/cgroup.c | 25 ++- kernel/events/core.c | 233 + kernel/events/hw_breakpoint.c |4 +- kernel/events/internal.h |4 + kernel/futex.c|3 +- kernel/irq/manage.c
Re: [PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2
On Fri, Aug 16, 2013 at 5:47 PM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.
v2:
- Don't bump kms version, so this patch can be backported to stable
kernels.
Cc: stable@vger.kernel.org
Signed-off-by: Tom Stellard thomas.stell...@amd.com
I've applied this to my tree and updated the the commit regarding why
it needs to go to stable.
Thanks!
Alex
---
drivers/gpu/drm/radeon/radeon_kms.c | 3 +
drivers/gpu/drm/radeon/si.c | 106
+---
include/uapi/drm/radeon_drm.h | 2 +
3 files changed, 66 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 49ff3d1..cc2ca38 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -433,6 +433,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return -EINVAL;
}
break;
+ case RADEON_INFO_SI_CP_DMA_COMPUTE:
+ *value = 1;
+ break;
default:
DRM_DEBUG_KMS(Invalid request %d\n, info-request);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index daa8d2d..8a21132 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4083,13 +4083,64 @@ static int si_vm_packet3_ce_check(struct
radeon_device *rdev,
return 0;
}
+static int si_vm_packet3_cp_dma_check(u32 *ib, u32 idx)
+{
+ u32 start_reg, reg, i;
+ u32 command = ib[idx + 4];
+ u32 info = ib[idx + 1];
+ u32 idx_value = ib[idx];
+ if (command PACKET3_CP_DMA_CMD_SAS) {
+ /* src address space is register */
+ if (((info 0x6000) 29) == 0) {
+ start_reg = idx_value 2;
+ if (command PACKET3_CP_DMA_CMD_SAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR(CP DMA Bad SRC
register\n);
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i (command 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR(CP DMA Bad SRC
register\n);
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ if (command PACKET3_CP_DMA_CMD_DAS) {
+ /* dst address space is register */
+ if (((info 0x0030) 20) == 0) {
+ start_reg = ib[idx + 2];
+ if (command PACKET3_CP_DMA_CMD_DAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR(CP DMA Bad DST
register\n);
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i (command 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR(CP DMA Bad DST
register\n);
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ return 0;
+}
+
static int si_vm_packet3_gfx_check(struct radeon_device *rdev,
u32 *ib, struct radeon_cs_packet *pkt)
{
+ int r;
u32 idx = pkt-idx + 1;
u32 idx_value = ib[idx];
u32 start_reg, end_reg, reg, i;
- u32 command, info;
switch (pkt-opcode) {
case PACKET3_NOP:
@@ -4190,50 +4241,9 @@ static int si_vm_packet3_gfx_check(struct
radeon_device *rdev,
}
break;
case PACKET3_CP_DMA:
- command = ib[idx + 4];
- info = ib[idx + 1];
- if (command PACKET3_CP_DMA_CMD_SAS) {
- /* src address space is register */
- if (((info 0x6000) 29) == 0) {
- start_reg = idx_value 2;
- if (command PACKET3_CP_DMA_CMD_SAIC) {
- reg = start_reg;
-
[PATCH 4/4] drm/radeon: update line buffer allocation for dce8
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank screen. This fixes blank screen problems
on dce8 asics.
Based on an initial fix from:
Jay Cornwall jay.cornw...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 29 ++---
drivers/gpu/drm/radeon/cikd.h | 4
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 582f8e4..1942571 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7367,8 +7367,8 @@ static u32 dce8_line_buffer_adjust(struct radeon_device
*rdev,
struct radeon_crtc *radeon_crtc,
struct drm_display_mode *mode)
{
- u32 tmp;
-
+ u32 tmp, buffer_alloc, i;
+ u32 pipe_offset = radeon_crtc-crtc_id * 0x20;
/*
* Line Buffer Setup
* There are 6 line buffers, one for each display controllers.
@@ -7378,22 +7378,37 @@ static u32 dce8_line_buffer_adjust(struct radeon_device
*rdev,
* them using the stereo blender.
*/
if (radeon_crtc-base.enabled mode) {
- if (mode-crtc_hdisplay 1920)
+ if (mode-crtc_hdisplay 1920) {
tmp = 1;
- else if (mode-crtc_hdisplay 2560)
+ buffer_alloc = 2;
+ } else if (mode-crtc_hdisplay 2560) {
tmp = 2;
- else if (mode-crtc_hdisplay 4096)
+ buffer_alloc = 2;
+ } else if (mode-crtc_hdisplay 4096) {
tmp = 0;
- else {
+ buffer_alloc = (rdev-flags RADEON_IS_IGP) ? 2 : 4;
+ } else {
DRM_DEBUG_KMS(Mode too big for LB!\n);
tmp = 0;
+ buffer_alloc = (rdev-flags RADEON_IS_IGP) ? 2 : 4;
}
- } else
+ } else {
tmp = 1;
+ buffer_alloc = 0;
+ }
WREG32(LB_MEMORY_CTRL + radeon_crtc-crtc_offset,
LB_MEMORY_CONFIG(tmp) | LB_MEMORY_SIZE(0x6B0));
+ WREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset,
+ DMIF_BUFFERS_ALLOCATED(buffer_alloc));
+ for (i = 0; i rdev-usec_timeout; i++) {
+ if (RREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset)
+ DMIF_BUFFERS_ALLOCATED_COMPLETED)
+ break;
+ udelay(1);
+ }
+
if (radeon_crtc-base.enabled mode) {
switch (tmp) {
case 0:
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index 6a92f49..203d2a0 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/drm/radeon/cikd.h
@@ -393,6 +393,10 @@
#define DMIF_ADDR_CALC 0xC00
+#definePIPE0_DMIF_BUFFER_CONTROL 0x0ca0
+# define DMIF_BUFFERS_ALLOCATED(x) ((x) 0)
+# define DMIF_BUFFERS_ALLOCATED_COMPLETED (1 4)
+
#defineSRBM_GFX_CNTL 0xE44
#definePIPEID(x) ((x)
0)
#defineMEID(x) ((x)
2)
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] drm/radeon: update line buffer allocation for dce6
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank screen. This fixes blank screen problems
on dce6 asics.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=64850
Based on an initial fix from:
Jay Cornwall jay.cornw...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/radeon/si.c | 23 +++
drivers/gpu/drm/radeon/sid.h | 4
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 0b4e979..89393ed 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -1711,7 +1711,8 @@ static u32 dce6_line_buffer_adjust(struct radeon_device
*rdev,
struct drm_display_mode *mode,
struct drm_display_mode *other_mode)
{
- u32 tmp;
+ u32 tmp, buffer_alloc, i;
+ u32 pipe_offset = radeon_crtc-crtc_id * 0x20;
/*
* Line Buffer Setup
* There are 3 line buffers, each one shared by 2 display controllers.
@@ -1726,16 +1727,30 @@ static u32 dce6_line_buffer_adjust(struct radeon_device
*rdev,
* non-linked crtcs for maximum line buffer allocation.
*/
if (radeon_crtc-base.enabled mode) {
- if (other_mode)
+ if (other_mode) {
tmp = 0; /* 1/2 */
- else
+ buffer_alloc = 1;
+ } else {
tmp = 2; /* whole */
- } else
+ buffer_alloc = 2;
+ }
+ } else {
tmp = 0;
+ buffer_alloc = 0;
+ }
WREG32(DC_LB_MEMORY_SPLIT + radeon_crtc-crtc_offset,
DC_LB_MEMORY_CONFIG(tmp));
+ WREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset,
+ DMIF_BUFFERS_ALLOCATED(buffer_alloc));
+ for (i = 0; i rdev-usec_timeout; i++) {
+ if (RREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset)
+ DMIF_BUFFERS_ALLOCATED_COMPLETED)
+ break;
+ udelay(1);
+ }
+
if (radeon_crtc-base.enabled mode) {
switch (tmp) {
case 0:
diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h
index 91dae16..52d2ab6 100644
--- a/drivers/gpu/drm/radeon/sid.h
+++ b/drivers/gpu/drm/radeon/sid.h
@@ -282,6 +282,10 @@
#define DMIF_ADDR_CALC 0xC00
+#definePIPE0_DMIF_BUFFER_CONTROL 0x0ca0
+# define DMIF_BUFFERS_ALLOCATED(x) ((x) 0)
+# define DMIF_BUFFERS_ALLOCATED_COMPLETED (1 4)
+
#defineSRBM_STATUS 0xE50
#defineGRBM_RQ_PENDING (1 5)
#defineVMC_BUSY(1 8)
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] drm/radeon: update line buffer allocation for dce4.1/5
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank screen. This fixes blank screen problems
on dce4.1/5 asics.
Based on an initial fix from:
Jay Cornwall jay.cornw...@amd.com
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen.c | 25 +
drivers/gpu/drm/radeon/evergreend.h | 4
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 2ca9f13..1832136 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1812,7 +1812,8 @@ static u32 evergreen_line_buffer_adjust(struct
radeon_device *rdev,
struct drm_display_mode *mode,
struct drm_display_mode *other_mode)
{
- u32 tmp;
+ u32 tmp, buffer_alloc, i;
+ u32 pipe_offset = radeon_crtc-crtc_id * 0x20;
/*
* Line Buffer Setup
* There are 3 line buffers, each one shared by 2 display controllers.
@@ -1835,18 +1836,34 @@ static u32 evergreen_line_buffer_adjust(struct
radeon_device *rdev,
* non-linked crtcs for maximum line buffer allocation.
*/
if (radeon_crtc-base.enabled mode) {
- if (other_mode)
+ if (other_mode) {
tmp = 0; /* 1/2 */
- else
+ buffer_alloc = 1;
+ } else {
tmp = 2; /* whole */
- } else
+ buffer_alloc = 2;
+ }
+ } else {
tmp = 0;
+ buffer_alloc = 0;
+ }
/* second controller of the pair uses second half of the lb */
if (radeon_crtc-crtc_id % 2)
tmp += 4;
WREG32(DC_LB_MEMORY_SPLIT + radeon_crtc-crtc_offset, tmp);
+ if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
+ WREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset,
+ DMIF_BUFFERS_ALLOCATED(buffer_alloc));
+ for (i = 0; i rdev-usec_timeout; i++) {
+ if (RREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset)
+ DMIF_BUFFERS_ALLOCATED_COMPLETED)
+ break;
+ udelay(1);
+ }
+ }
+
if (radeon_crtc-base.enabled mode) {
switch (tmp) {
case 0:
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index 430997a..8768fd6 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -1160,6 +1160,10 @@
# define LATENCY_LOW_WATERMARK(x) ((x) 0)
# define LATENCY_HIGH_WATERMARK(x) ((x) 16)
+#definePIPE0_DMIF_BUFFER_CONTROL 0x0ca0
+# define DMIF_BUFFERS_ALLOCATED(x) ((x) 0)
+# define DMIF_BUFFERS_ALLOCATED_COMPLETED (1 4)
+
#define IH_RB_CNTL0x3e00
# define IH_RB_ENABLE (1 0)
# define IH_IB_SIZE(x) ((x) 1) /* log2 */
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] drm/radeon: move watermark setup out of set base callback
Some of the watermark registers need to be programmed prior
to enabling the display. Doing this in the set base callback
means the watermark registers can be updated at arbitray times
when the display offset is changed which can lead to display
problems.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 13 +++--
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 6 +++---
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b9d3b43..dd11e00 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1278,9 +1278,6 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
radeon_bo_unreserve(rbo);
}
- /* Bytes per pixel may have changed */
- radeon_bandwidth_update(rdev);
-
return 0;
}
@@ -1447,9 +1444,6 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
radeon_bo_unreserve(rbo);
}
- /* Bytes per pixel may have changed */
- radeon_bandwidth_update(rdev);
-
return 0;
}
@@ -1897,6 +1891,11 @@ static void atombios_crtc_prepare(struct drm_crtc *crtc)
static void atombios_crtc_commit(struct drm_crtc *crtc)
{
+ struct drm_device *dev = crtc-dev;
+ struct radeon_device *rdev = dev-dev_private;
+
+ /* set up watermarks before enabling the display */
+ radeon_bandwidth_update(rdev);
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
atombios_lock_crtc(crtc, ATOM_DISABLE);
}
@@ -1910,6 +1909,8 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
int i;
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
+ /* set up watermarks when the display is off */
+ radeon_bandwidth_update(rdev);
if (ASIC_IS_DCE6(rdev))
atombios_powergate_crtc(crtc, ATOM_ENABLE);
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 7cb178a..dbc5b773 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -537,9 +537,6 @@ int radeon_crtc_do_set_base(struct drm_crtc *crtc,
radeon_bo_unreserve(rbo);
}
- /* Bytes per pixel may have changed */
- radeon_bandwidth_update(rdev);
-
return 0;
}
@@ -1045,8 +1042,11 @@ static void radeon_crtc_prepare(struct drm_crtc *crtc)
static void radeon_crtc_commit(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
+ struct radeon_device *rdev = dev-dev_private;
struct drm_crtc *crtci;
+ /* set up watermarks before enabling the display */
+ radeon_bandwidth_update(rdev);
/*
* Reenable the CRTCs that should be running.
*/
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 28/45] ALSA: hda - Add a fixup for Gateway LT27
On Mon, Aug 19, 2013 at 11:42:28AM -0600, Nathanael D. Noblet wrote: No objection, other than that I submitted a revision to that patch... Added an additional piece of hardware. The full patch should be include two lines. That patch needs to get into Linus's tree before I can add it to the stable tree. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/34] 3.4.59-stable review
On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.59 release. There are 34 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Note, there are a number of build fixes in this round, in the quest to get all arches building properly to be able to track future regressions easier. Many thanks to Guenter Roeck and Geert Uytterhoeven for their work in doing this. Responses should be made by Tue Aug 20 20:32:48 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.59-rc1.gz and the diffstat can be found below. thanks, greg k-h Greg, This release is not looking good on one of test systems. Bluetooth is not recognized and wireless doesn't work. I am going to start bisect and giving you a head-up. The following new dmesg -l crit regression messages: CPU2: Package power limit notification (total events = 1) CPU3: Package power limit notification (total events = 1) CPU0: Package power limit notification (total events = 1) CPU1: Package power limit notification (total events = 1) and the following traces in dmesg: [ 124.802169] init: udevtrigger post-stop process (353) terminated with status 1 [ 243.439212] INFO: task crda:723 blocked for more than 120 seconds. [ 243.439220] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 243.439227] crdaD 88041f253940 0 723362 0x0004 [ 243.439237] 8803fbde59d8 0082 880404a4dbc0 8803fbde5fd8 [ 243.439248] 8803fbde5fd8 8803fbde5fd8 8803eca2c4d0 880404a4dbc0 [ 243.439257] 880404a4dbc0 81caa2a0 880404a4dbc0 81caa2a4 [ 243.439266] Call Trace: [ 243.439283] [816681f9] schedule+0x29/0x70 [ 243.439292] [816684be] schedule_preempt_disabled+0xe/0x10 [ 243.439301] [81666fa7] __mutex_lock_slowpath+0xd7/0x150 [ 243.439312] [8158498e] ? genl_rcv_msg+0x16e/0x2d0 [ 243.439321] [81666a7a] mutex_lock+0x2a/0x50 [ 243.439328] [815847d5] genl_lock+0x15/0x20 [ 243.439335] [815855fc] ctrl_dumpfamily+0x12c/0x140 [ 243.439343] [81581c53] netlink_dump+0x73/0x1e0 [ 243.439350] [815821d8] netlink_recvmsg+0x338/0x430 [ 243.439358] [8154555d] sock_recvmsg+0xfd/0x130 [ 243.439371] [81172a93] ? __mem_cgroup_commit_charge+0xb3/0x2f0 [ 243.439382] [8114a78d] ? page_add_new_anon_rmap+0xcd/0xf0 [ 243.439389] [8154692a] ? move_addr_to_kernel+0x5a/0xc0 [ 243.439399] [815521a6] ? verify_iovec+0x56/0xd0 [ 243.439406] [81545073] ___sys_recvmsg+0x143/0x2d0 [ 243.439414] [81141349] ? handle_mm_fault+0x259/0x320 [ 243.439424] [8154420c] ? move_addr_to_user+0xbc/0xe0 [ 243.439431] [8154715c] ? sys_getsockname+0xdc/0xf0 [ 243.439437] [81547ae9] __sys_recvmsg+0x49/0x90 [ 243.439444] [81547b42] sys_recvmsg+0x12/0x30 [ 243.439455] [816712e9] system_call_fastpath+0x16/0x1b [ 243.439463] INFO: task NetworkManager:879 blocked for more than 120 seconds. [ 243.439468] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 243.439473] NetworkManager D 88041f293940 0 879 1 0x [ 243.439481] 8804065c1a08 0082 8803ecbedbc0 8804065c1fd8 [ 243.439490] 8804065c1fd8 8804065c1fd8 880408d796f0 8803ecbedbc0 [ 243.439498] 8804065c1ab8 81caa2a0 8803ecbedbc0 81caa2a4 [ 243.439506] Call Trace: [ 243.439514] [816681f9] schedule+0x29/0x70 [ 243.439522] [816684be] schedule_preempt_disabled+0xe/0x10 [ 243.439530] [81666fa7] __mutex_lock_slowpath+0xd7/0x150 [ 243.439539] [81666a7a] mutex_lock+0x2a/0x50 [ 243.439546] [815847d5] genl_lock+0x15/0x20 [ 243.439553] [815847f6] genl_rcv+0x16/0x40 [ 243.439560] [81583d1d] netlink_unicast+0x19d/0x1f0 [ 243.439567] [8158404a] netlink_sendmsg+0x2da/0x390 [ 243.439574] [815456e8] sock_sendmsg+0xf8/0x130 [ 243.439582] [8154692a] ? move_addr_to_kernel+0x5a/0xc0 [ 243.439590] [815521a6] ? verify_iovec+0x56/0xd0 [ 243.439597] [81545b9e] ___sys_sendmsg+0x41e/0x430 [ 243.439607] [8107e733] ? __wake_up+0x53/0x70 [ 243.439614] [81582b43] ? netlink_table_ungrab+0x33/0x40 [ 243.439623] [8154420c] ? move_addr_to_user+0xbc/0xe0 [ 243.439629] [81547115] ? sys_getsockname+0x95/0xf0 [ 243.439636] [81547869] __sys_sendmsg+0x49/0x90 [ 243.439643] [815478c2] sys_sendmsg+0x12/0x30 [ 243.439651] [816712e9] system_call_fastpath+0x16/0x1b [ 363.295849] INFO: task crda:723 blocked for more than 120 seconds.
Re: [ 28/45] ALSA: hda - Add a fixup for Gateway LT27
No objection, other than that I submitted a revision to that patch... Added an additional piece of hardware. The full patch should be include two lines. On 08/18/2013 02:36 PM, Greg Kroah-Hartman wrote: 3.10-stable review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai ti...@suse.de commit 1801928e0f99d94c55e33c584c5eb2ff5e246ee6 upstream. Gateway LT27 needs a fixup for the inverted digital mic. Reported-by: Nathanael D. Noblet nathan...@gnat.ca Signed-off-by: Takashi Iwai ti...@suse.de Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- sound/pci/hda/patch_realtek.c |1 + 1 file changed, 1 insertion(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4210,6 +4210,7 @@ static const struct snd_pci_quirk alc662 SND_PCI_QUIRK(0x1025, 0x0308, Acer Aspire 8942G, ALC662_FIXUP_ASPIRE), SND_PCI_QUIRK(0x1025, 0x031c, Gateway NV79, ALC662_FIXUP_SKU_IGNORE), SND_PCI_QUIRK(0x1025, 0x0349, eMachines eM250, ALC662_FIXUP_INV_DMIC), + SND_PCI_QUIRK(0x1025, 0x034a, Gateway LT27, ALC662_FIXUP_INV_DMIC), SND_PCI_QUIRK(0x1025, 0x038b, Acer Aspire 8943G, ALC662_FIXUP_ASPIRE), SND_PCI_QUIRK(0x1028, 0x05d8, Dell, ALC668_FIXUP_DELL_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x05db, Dell, ALC668_FIXUP_DELL_MIC_NO_PRESENCE), -- Nathanael d. Noblet t 403.875.4613 --- a/sound/pci/hda/patch_realtek.c 2013-08-15 13:17:49.804492932 -0600 +++ b/sound/pci/hda/patch_realtek.c 2013-08-15 15:17:46.390273328 -0600 @@ -4208,6 +4208,8 @@ SND_PCI_QUIRK(0x17aa, 0x3a0d, Lenovo Ideapad Y550, ALC662_FIXUP_IDEAPAD), SND_PCI_QUIRK(0x19da, 0xa130, Zotac Z68, ALC662_FIXUP_ZOTAC_Z68), SND_PCI_QUIRK(0x1b35, 0x2206, CZC P10T, ALC662_FIXUP_CZC_P10T), + SND_PCI_QUIRK(0x1025, 0x034a, Gateway LT27, ALC662_FIXUP_INV_DMIC), + SND_PCI_QUIRK(0x1025, 0x022f, Acer Aspire One, ALC662_FIXUP_INV_DMIC), #if 0 /* Below is a quirk table taken from the old code.
Re: [ 28/45] ALSA: hda - Add a fixup for Gateway LT27
At Mon, 19 Aug 2013 10:48:06 -0700, Greg Kroah-Hartman wrote: On Mon, Aug 19, 2013 at 11:42:28AM -0600, Nathanael D. Noblet wrote: No objection, other than that I submitted a revision to that patch... Added an additional piece of hardware. The full patch should be include two lines. That patch needs to get into Linus's tree before I can add it to the stable tree. Don't worry, the patch was applied now. It'll be included in either 3.11-rc7 or 3.12-rc1. thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patch Fix TLB gather virtual address range invalidation corner has been added to the 3.10-stable tree
On Sun, 2013-08-18 at 11:57 -0700, Linus Torvalds wrote: On Fri, Aug 16, 2013 at 4:05 PM, gre...@linuxfoundation.org wrote: This is a note to let you know that I've just added the patch titled Fix TLB gather virtual address range invalidation corner to the 3.10-stable tree So just a note: the original bug was introduced well back into 3.6, but it's pretty much impossible to hit until commit 53a59fc67f97 that hit 3.8. *However*, that commit was also back-ported to at least the 3.7 stable series, so now the bug exists in all kernels v3.7.2 and newer. I don't know which stable kernels are live any more (looks like 3.7 to 3.9 are all EOL as far as you are concerned), but it might be a good idea to at least make sure the distros that may use them are aware of this. The bug is pretty unlikely, but the symptoms are subtle enough (random memory corruption) that it can be very annoying. OpenSUSE seems to be 3.7-based, but is clearly aware of this (since this issue was escalated by Michal). Fedora seems to be 3.10 in both F18 and F19 and is thus ok (eventually). Ubuntu might to be affected, though (3.8?) Thanks Linus. I'll pick this up for the next 3.8 stable cycle (v3.8.13.8) so Ubuntu and other any other distros following 3.8.y.z[0] will get it that way. -Kamal [0] https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable Other distros? Linus signature.asc Description: This is a digitally signed message part
Re: 3.11-rc6 genetlink locking fix offends lockdep
On Mon, 19 Aug 2013, Johannes Berg wrote:
On Mon, 2013-08-19 at 19:00 +0800, Ding Tianhong wrote:
On 2013/8/19 16:00, Johannes Berg wrote:
3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race)
gives me the lockdep trace below at startup.
Hmm. Yes, I see now how this happens, not sure why I didn't run into it.
The problem is that genl_family_rcv_msg() is called with the genl_lock
held, and then calls netlink_dump_start() with it held, creating a
genl_lock-cb_mutex dependency, but obviously the dump continuation is
the other way around.
We could use the semaphore instead, I believe, but I don't really
understand the mutex vs. semaphore well enough to be sure that's
correct.
johannes
it is useless, the logic need to modify or otherwise it will still call
lockdep trace.
I don't believe so, the semaphore and cb_mutex don't have a dependency
yet, afaict.
The down_read(cb_lock) patch you suggested gives the lockdep trace below.
maybe i could send a patch for it, if you wish.
What do you mean?
johannes
[4.027797] e1000e :00:19.0: irq 43 for MSI/MSI-X
[4.129749] e1000e :00:19.0: irq 43 for MSI/MSI-X
[4.130179] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[4.134629]
[4.134646] ==
[4.134680] [ INFO: possible circular locking dependency detected ]
[4.134714] 3.11.0-rc6 #3 Not tainted
[4.134735] ---
[4.134767] NetworkManager/357 is trying to acquire lock:
[4.134797] (cb_lock){++}, at: [8148204a]
ctrl_dumpfamily+0x38/0x108
[4.134853]
[4.134853] but task is already holding lock:
[4.134883] (nlk-cb_mutex){+.+.+.}, at: [8147f148]
netlink_dump+0x1c/0x1d7
[4.134938]
[4.134938] which lock already depends on the new lock.
[4.134938]
[4.134981]
[4.134981] the existing dependency chain (in reverse order) is:
[4.135020]
[4.135020] - #2 (nlk-cb_mutex){+.+.+.}:
[4.135056][810b34d2] __lock_acquire+0x865/0x956
[4.135094][810b39fc] lock_acquire+0x57/0x6d
[4.135129][81583e52] mutex_lock_nested+0x5e/0x345
[4.135167][81480122] __netlink_dump_start+0xae/0x14e
[4.135205][8148224b] genl_rcv_msg+0xf4/0x252
[4.135239][81481742] netlink_rcv_skb+0x3e/0x8c
[4.135275][8148199b] genl_rcv+0x24/0x34
[4.135307][814811ca] netlink_unicast+0xed/0x17a
[4.135342][814815d4] netlink_sendmsg+0x2fb/0x345
[4.135378][814503f7] sock_sendmsg+0x79/0x8e
[4.135412][81450707] ___sys_sendmsg+0x231/0x2be
[4.135448][81453228] __sys_sendmsg+0x3d/0x5e
[4.135483][81453256] SyS_sendmsg+0xd/0x19
[4.135517][81587c12] system_call_fastpath+0x16/0x1b
[4.13]
[4.13] - #1 (genl_mutex){+.+.+.}:
[4.135589][810b34d2] __lock_acquire+0x865/0x956
[4.135626][810b39fc] lock_acquire+0x57/0x6d
[4.135661][81583e52] mutex_lock_nested+0x5e/0x345
[4.135697][81482155] genl_lock+0x12/0x14
[4.135730][8148249d] genl_lock_all+0x15/0x17
[4.135763][81482b2a] genl_register_family+0x51/0x142
[4.135801][8148305f]
genl_register_family_with_ops+0x23/0x70
[4.135842][8195e610] genl_init+0x41/0x80
[4.135876][81000267] do_one_initcall+0x7f/0x108
[4.135912][81930e29] kernel_init_freeable+0x106/0x195
[4.135951][81574621] kernel_init+0x9/0xd1
[4.135985][81587b6c] ret_from_fork+0x7c/0xb0
[4.136019]
[4.136019] - #0 (cb_lock){++}:
[4.136052][810b1fb0] validate_chain.isra.21+0x836/0xe8e
[4.136091][810b34d2] __lock_acquire+0x865/0x956
[4.136127][810b39fc] lock_acquire+0x57/0x6d
[4.136161][81584629] down_read+0x42/0x57
[4.136194][8148204a] ctrl_dumpfamily+0x38/0x108
[4.136230][8147f1b4] netlink_dump+0x88/0x1d7
[4.136264][8147f4b4] netlink_recvmsg+0x1b1/0x2d1
[4.137410][81450328] sock_recvmsg+0x83/0x98
[4.138459][814500c6] ___sys_recvmsg+0x15d/0x207
[4.139692][814533f7] __sys_recvmsg+0x3d/0x5e
[4.140918][81453425] SyS_recvmsg+0xd/0x19
[4.141975][81587c12] system_call_fastpath+0x16/0x1b
[4.143042]
[4.143042] other info that might help us debug this:
[4.143042]
[4.146007] Chain exists of:
[4.146007] cb_lock -- genl_mutex -- nlk-cb_mutex
[4.146007]
[4.148919] Possible unsafe locking scenario:
[
Re: [ 00/34] 3.4.59-stable review
On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote: On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.59 release. There are 34 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Note, there are a number of build fixes in this round, in the quest to get all arches building properly to be able to track future regressions easier. Many thanks to Guenter Roeck and Geert Uytterhoeven for their work in doing this. Responses should be made by Tue Aug 20 20:32:48 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.59-rc1.gz and the diffstat can be found below. thanks, greg k-h Greg, This release is not looking good on one of test systems. Bluetooth is not recognized and wireless doesn't work. I am going to start bisect and giving you a head-up. The following new dmesg -l crit regression messages: That's odd, given that there are no bluetooth changes in this release. CPU2: Package power limit notification (total events = 1) CPU3: Package power limit notification (total events = 1) CPU0: Package power limit notification (total events = 1) CPU1: Package power limit notification (total events = 1) and the following traces in dmesg: [ 124.802169] init: udevtrigger post-stop process (353) terminated with status 1 [ 243.439212] INFO: task crda:723 blocked for more than 120 seconds. What is crda? Any luck with bisection? It should go fast as the majority of patches here are non-x86. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/34] 3.4.59-stable review
Hi On Monday 19 August 2013, Greg Kroah-Hartman wrote: On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote: On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote: […] and the following traces in dmesg: [ 124.802169] init: udevtrigger post-stop process (353) terminated with status 1 [ 243.439212] INFO: task crda:723 blocked for more than 120 seconds. What is crda? Any luck with bisection? It should go fast as the majority of patches here are non-x86. crda is a userspace helper, invoked by udev events, which sets -and intersects as needed- the regulatory domain settings for (modern, cfg80211 based) wlan hardware based on the device's EEPROM regdom hint, local configuration (country code) and eventual IEEE 802.11d hints (country IEs) beaconed by access points nearby. It hooks into udev with these udev rules (Debian/ 1.1.2-1): $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules SUBSYSTEM==ieee80211, ACTION==add, RUN+=/lib/crda/setregdomain $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules KERNEL==regulatory*, ACTION==change, SUBSYSTEM==platform, RUN+=/sbin/crda Full source is at [2], it should be installed on pretty much every distro/ system released with wlan support for the last 3 years. There are two iwl4965 patches in this series, which might be among the first ones to check - /if/ you actually have that hardware, the second one (iwl4965: reset firmware after rfkill off) might also indirectly have an effect on blutetooth (via rfkill). Regards Stefan Lippers-Hollmann [1] http://wireless.kernel.org/en/developers/Regulatory/CRDA [2] https://github.com/mcgrof/crda -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/34] 3.4.59-stable review
On 08/19/2013 02:14 PM, Stefan Lippers-Hollmann wrote: Hi On Monday 19 August 2013, Greg Kroah-Hartman wrote: On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote: On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote: […] and the following traces in dmesg: [ 124.802169] init: udevtrigger post-stop process (353) terminated with status 1 [ 243.439212] INFO: task crda:723 blocked for more than 120 seconds. What is crda? Any luck with bisection? It should go fast as the majority of patches here are non-x86. crda is a userspace helper, invoked by udev events, which sets -and intersects as needed- the regulatory domain settings for (modern, cfg80211 based) wlan hardware based on the device's EEPROM regdom hint, local configuration (country code) and eventual IEEE 802.11d hints (country IEs) beaconed by access points nearby. It hooks into udev with these udev rules (Debian/ 1.1.2-1): $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules SUBSYSTEM==ieee80211, ACTION==add, RUN+=/lib/crda/setregdomain $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules KERNEL==regulatory*, ACTION==change, SUBSYSTEM==platform, RUN+=/sbin/crda Full source is at [2], it should be installed on pretty much every distro/ system released with wlan support for the last 3 years. There are two iwl4965 patches in this series, which might be among the first ones to check - /if/ you actually have that hardware, the second one (iwl4965: reset firmware after rfkill off) might also indirectly have an effect on blutetooth (via rfkill). Regards Stefan Lippers-Hollmann [1] http://wireless.kernel.org/en/developers/Regulatory/CRDA [2] https://github.com/mcgrof/crda Greg, git bisect shows the following patch as the problem: [ 26/34] genetlink: fix family dump race -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/34] 3.4.59-stable review
On Mon, Aug 19, 2013 at 04:22:59PM -0600, Shuah Khan wrote: On 08/19/2013 02:14 PM, Stefan Lippers-Hollmann wrote: Hi On Monday 19 August 2013, Greg Kroah-Hartman wrote: On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote: On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote: […] and the following traces in dmesg: [ 124.802169] init: udevtrigger post-stop process (353) terminated with status 1 [ 243.439212] INFO: task crda:723 blocked for more than 120 seconds. What is crda? Any luck with bisection? It should go fast as the majority of patches here are non-x86. crda is a userspace helper, invoked by udev events, which sets -and intersects as needed- the regulatory domain settings for (modern, cfg80211 based) wlan hardware based on the device's EEPROM regdom hint, local configuration (country code) and eventual IEEE 802.11d hints (country IEs) beaconed by access points nearby. It hooks into udev with these udev rules (Debian/ 1.1.2-1): $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules SUBSYSTEM==ieee80211, ACTION==add, RUN+=/lib/crda/setregdomain $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules KERNEL==regulatory*, ACTION==change, SUBSYSTEM==platform, RUN+=/sbin/crda Full source is at [2], it should be installed on pretty much every distro/ system released with wlan support for the last 3 years. There are two iwl4965 patches in this series, which might be among the first ones to check - /if/ you actually have that hardware, the second one (iwl4965: reset firmware after rfkill off) might also indirectly have an effect on blutetooth (via rfkill). Regards Stefan Lippers-Hollmann [1] http://wireless.kernel.org/en/developers/Regulatory/CRDA [2] https://github.com/mcgrof/crda Greg, git bisect shows the following patch as the problem: [ 26/34] genetlink: fix family dump race Johannes, another strike against this patch :( Any chance on fixing it upstream and me sucking that fix in? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/34] 3.4.59-stable review
On 08/19/2013 04:22 PM, Shuah Khan wrote: On 08/19/2013 02:14 PM, Stefan Lippers-Hollmann wrote: Hi On Monday 19 August 2013, Greg Kroah-Hartman wrote: On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote: On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote: […] and the following traces in dmesg: [ 124.802169] init: udevtrigger post-stop process (353) terminated with status 1 [ 243.439212] INFO: task crda:723 blocked for more than 120 seconds. What is crda? Any luck with bisection? It should go fast as the majority of patches here are non-x86. crda is a userspace helper, invoked by udev events, which sets -and intersects as needed- the regulatory domain settings for (modern, cfg80211 based) wlan hardware based on the device's EEPROM regdom hint, local configuration (country code) and eventual IEEE 802.11d hints (country IEs) beaconed by access points nearby. It hooks into udev with these udev rules (Debian/ 1.1.2-1): $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules SUBSYSTEM==ieee80211, ACTION==add, RUN+=/lib/crda/setregdomain $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules KERNEL==regulatory*, ACTION==change, SUBSYSTEM==platform, RUN+=/sbin/crda Full source is at [2], it should be installed on pretty much every distro/ system released with wlan support for the last 3 years. There are two iwl4965 patches in this series, which might be among the first ones to check - /if/ you actually have that hardware, the second one (iwl4965: reset firmware after rfkill off) might also indirectly have an effect on blutetooth (via rfkill). Regards Stefan Lippers-Hollmann [1]http://wireless.kernel.org/en/developers/Regulatory/CRDA [2]https://github.com/mcgrof/crda Greg, git bisect shows the following patch as the problem: [ 26/34] genetlink: fix family dump race -- Shuah Interesting. The same patch is in 3.10.8 as well, and I don't see this problem on this system on 3.10.8. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/45] 3.10.8-stable review
On 08/18/2013 02:35 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.8 release. There are 45 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Aug 20 20:36:09 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.8-rc1.gz and the diffstat can be found below. thanks, greg k-h 3.10.8-rc1 applied cleanly to 3.10.7. Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5 HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs look good. No regressions compared to the previous dmesgs for each of this release. dmesg emerg, crit, alert, err are clean. No regressions in warn. Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: Cross-compile tests results: alpha: defconfig passed arm: defconfig passed arm64: defconfig passed blackfin: defconfig passed c6x: defconfig passed mips: defconfig passed mipsel: defconfig passed powerpc: wii_defconfig passed sh: defconfig passed sparc: defconfig passed tile: tilegx_defconfig passed -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/12] 3.0.92-stable review
On 08/18/2013 02:30 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.0.92 release. There are 12 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Aug 20 20:29:24 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.92-rc1.gz and the diffstat can be found below. thanks, greg k-h 3.0.92-rc1 applied cleanly to 3.0.91. Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5 HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn. Cross-compile test: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2: Cross-compile tests results: alpha: defconfig passed arm: defconfig passed arm64: not applicable blackfin: defconfig passed c6x: not applicable mips: defconfig passed mipsel: defconfig passed powerpc: wii_defconfig passed sh: defconfig passed sparc: defconfig passed tile: tilegx_defconfig passed -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/12] 3.0.92-stable review
On Mon, Aug 19, 2013 at 04:53:54PM -0600, Shuah Khan wrote: On 08/18/2013 02:30 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.0.92 release. There are 12 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Aug 20 20:29:24 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.92-rc1.gz and the diffstat can be found below. thanks, greg k-h 3.0.92-rc1 applied cleanly to 3.0.91. Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5 HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn. Thanks for letting me know. greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 00/45] 3.10.8-stable review
On Mon, Aug 19, 2013 at 04:48:08PM -0600, Shuah Khan wrote: On 08/18/2013 02:35 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.8 release. There are 45 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Aug 20 20:36:09 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.8-rc1.gz and the diffstat can be found below. thanks, greg k-h 3.10.8-rc1 applied cleanly to 3.10.7. Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5 HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs look good. No regressions compared to the previous dmesgs for each of this release. dmesg emerg, crit, alert, err are clean. No regressions in warn. Thanks for testing and letting me know. greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock
Hi Ingo,
Thank you for fixing typos!
OK, I'll fix them and rename to ioapic_zap_locks().
Thank you again!
Yoshihiro YUNOMAE
(2013/08/19 18:46), Ingo Molnar wrote:
* Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote:
Prevent crash_kexec() from deadlocking of ioapic_lock.
s/of/on
When crash_kexec() is executed on a cpu, the cpu will get
ioapic_lock in disable_IO_APIC(). So if the cpu gets NMI
while locking ioapic_lock, a deadlock wiil happen. In
s/will
this patch, ioapic_lock is initialized before
disable_IO_APIC().
To confirm this deadlocking, you'll set up as follows:
s/deadlocking/deadlock
1. Add mdelay(1000) after raw_spin_lock_irqsave() in
native_ioapic_set_affinity()@arch/x86/kernel/apic/io_apic.c
Although the deadlocking can occur without this modification, it will
increase the potential of the deadlocking problem.
s/deadlocking/deadlock
2. Build and install the kernel
3. Set up the OS which will run panic() and kexec when NMI is injected
# echo kernel.unknown_nmi_panic=1 /etc/sysctl.conf
# vim /etc/default/grub
add nmi_watchdog=0 crashkernel=256M in GRUB_CMDLINE_LINUX line
# grub2-mkconfig
4. Reboot the OS
5. Run following command for each vcpu on the guest
# while true; do echo CPU num /proc/irq/IO-APIC-edge or
IO-APIC-fasteoi/smp_affinitity; done;
By running this command, cpus will get ioapic_lock for setting affinity.
6. Inject NMI (push a dump button or execute 'virsh inject-nmi domain' if you
use VM)
After injecting NMI, panic() is called in an nmi-handler context.
Then, kexec will normally run in panic(), but the operation will be stopped
by deadlock of ioapic_lock in crash_kexec()-machine_crash_shutdown()-
s/of/on
native_machine_crash_shutdown()-disable_IO_APIC()-clear_IO_APIC()-
clear_IO_APIC_pin()-ioapic_read_entry().
I suppose we could do this patch if it's a common
occurance.
A few minor details need fixing:
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andi Kleen a...@linux.intel.com
Cc: Seiji Aguchi seiji.agu...@hds.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Cc: Joerg Roedel j...@8bytes.org
Cc: Zhang Yanfei zhangyan...@cn.fujitsu.com
Cc: Eric W. Biederman ebied...@xmission.com
Cc: Gleb Natapov g...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Cc: linux-ker...@vger.kernel.org
Cc: stable@vger.kernel.org
---
arch/x86/include/asm/apic.h|2 ++
arch/x86/kernel/apic/io_apic.c |5 +
arch/x86/kernel/crash.c|4
3 files changed, 11 insertions(+)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index f8119b5..ddb06af 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -715,4 +715,6 @@ static inline void exiting_ack_irq(void)
ack_APIC_irq();
}
+extern void ioapic_lock_init(void);
+
#endif /* _ASM_X86_APIC_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9ed796c..2816c07 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1534,6 +1534,11 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
}
}
+void ioapic_lock_init(void)
+{
+ raw_spin_lock_init(ioapic_lock);
+}
Please name this ioapic_zap_locks() to make clear that this
is crash handling related.
+
__apicdebuginit(void) print_IO_APIC(int ioapic_idx)
{
union IO_APIC_reg_00 reg_00;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 74467fe..ea039d5 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -129,6 +129,10 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
lapic_shutdown();
#if defined(CONFIG_X86_IO_APIC)
Please enhance this #ifdef while at it.
+ /*
+* Prevent crash_kexec() from deadlocking of ioapic_lock.
+*/
s/of/on.
Also, single-line comment can go /* here */.
+ ioapic_lock_init();
disable_IO_APIC();
#endif
#ifdef CONFIG_HPET_TIMER
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] 3.10.{6,7} crashes on network activity
On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote: On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote: Hi guys, Starting with 3.10.6 (and still present in .7) I get an oops on connecting to the network. The attached picture shows the oops. In case it does not reach the ML, the top of the call trace reads: brcms_c_compute_rtscts_dur brcms_c_ampdu_finalize ampdu_finalize dma_txfast brcms_c_txfifo brcms_c_sendpkt_mac80211 brcms_ops_tx __ieee80211_tx I bisected the problem and the first bad commit is commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6 Author: Felix Fietkau n...@openwrt.org Date: Fri Jun 28 21:04:35 2013 +0200 mac80211/minstrel_ht: fix cck rate sampling commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream. Reverting it on top of .7 fixes the problem. I had the same (I suppose) problem on mainline some time ago, but I have not bisected it, verified that the problem still occurs there, or checked if reverting the upstream patch fixes it. I'd be happy to do that if it would help though. Let me know if you need any more information. Do you have this same problem with 3.11-rc6 as well? Yes, I just confirmed. I also confirmed that reverting the mainline commit on top of -rc6 fixes the problem. Great, thanks. Felix and Johannes, any chance we can get this reverted in Linus tree soon, and push that revert back to the 3.10 stable tree as well? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH tip/core/rcu 6/9] rculist: list_first_or_null_rcu() should use list_entry_rcu()
From: Tejun Heo t...@kernel.org
list_first_or_null() should test whether the list is empty and return
pointer to the first entry if not in a RCU safe manner. It's broken
in several ways.
* It compares __kernel @__ptr with __rcu @__next triggering the
following sparse warning.
net/core/dev.c:4331:17: error: incompatible types in comparison expression
(different address spaces)
* It doesn't perform rcu_dereference*() and computes the entry address
using container_of() directly from the __rcu pointer which is
inconsitent with other rculist interface. As a result, all three
in-kernel users - net/core/dev.c, macvlan, cgroup - are buggy. They
dereference the pointer w/o going through read barrier.
* While -next dereference passes through list_next_rcu(), the
compiler is still free to fetch -next more than once and thus
nullify the __ptr != __next condition check.
Fix it by making list_first_or_null_rcu() dereference -next directly
using ACCESS_ONCE() and then use list_entry_rcu() on it like other
rculist accessors.
v2: Paul pointed out that the compiler may fetch the pointer more than
once nullifying the condition check. ACCESS_ONCE() added on
-next dereference.
v3: Restored () around macro param which was accidentally removed.
Spotted by Paul.
Signed-off-by: Tejun Heo t...@kernel.org
Reported-by: Fengguang Wu fengguang...@intel.com
Cc: Dipankar Sarma dipan...@in.ibm.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: David S. Miller da...@davemloft.net
Cc: Li Zefan lize...@huawei.com
Cc: Patrick McHardy ka...@trash.net
Cc: stable@vger.kernel.org
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
---
include/linux/rculist.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index f4b1001..4106721 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -267,8 +267,9 @@ static inline void list_splice_init_rcu(struct list_head
*list,
*/
#define list_first_or_null_rcu(ptr, type, member) \
({struct list_head *__ptr = (ptr); \
- struct list_head __rcu *__next = list_next_rcu(__ptr); \
- likely(__ptr != __next) ? container_of(__next, type, member) : NULL; \
+ struct list_head *__next = ACCESS_ONCE(__ptr-next); \
+ likely(__ptr != __next) ? \
+ list_entry_rcu(__next, type, member) : NULL; \
})
/**
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath9k: Enable PLL fix only for AR9340/AR9330
From: Sujith Manoharan c_man...@qca.qualcomm.com
The PLL hang workaround is required only for AR9330 and
AR9340. This issue was first observed on an AP121 and the WAR
is enabled for AR9340 also (DB120 etc.), since it uses a PLL
design identical to AR9330. This is not required for AR9485 and AR9550.
Various bugs have been reported regarding this:
https://bugzilla.redhat.com/show_bug.cgi?id=997217
https://bugzilla.redhat.com/show_bug.cgi?id=994648
Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index ac9f18f..e4f6590 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -173,8 +173,7 @@ static void ath_restart_work(struct ath_softc *sc)
{
ieee80211_queue_delayed_work(sc-hw, sc-tx_complete_work, 0);
- if (AR_SREV_9340(sc-sc_ah) || AR_SREV_9485(sc-sc_ah) ||
- AR_SREV_9550(sc-sc_ah))
+ if (AR_SREV_9340(sc-sc_ah) || AR_SREV_9330(sc-sc_ah))
ieee80211_queue_delayed_work(sc-hw, sc-hw_pll_work,
msecs_to_jiffies(ATH_PLL_WORK_INTERVAL));
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] 3.10.{6,7} crashes on network activity
On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:
On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:
On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:
Hi guys,
Starting with 3.10.6 (and still present in .7) I get an oops on
connecting to the network.
The attached picture shows the oops. In case it does not reach the ML,
the top of the call trace reads:
brcms_c_compute_rtscts_dur
brcms_c_ampdu_finalize
ampdu_finalize
dma_txfast
brcms_c_txfifo
brcms_c_sendpkt_mac80211
brcms_ops_tx
__ieee80211_tx
I bisected the problem and the first bad commit is
commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau n...@openwrt.org
Date: Fri Jun 28 21:04:35 2013 +0200
mac80211/minstrel_ht: fix cck rate sampling
commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.
Reverting it on top of .7 fixes the problem.
I had the same (I suppose) problem on mainline some time ago, but I
have not bisected it, verified that the problem still occurs there, or
checked if reverting the upstream patch fixes it. I'd be happy to do
that if it would help though.
Let me know if you need any more information.
Do you have this same problem with 3.11-rc6 as well?
Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.
Great, thanks.
Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?
I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.
- Felix
---
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1501,6 +1501,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_RC_TABLE = 124,
IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF = 125,
IEEE80211_HW_TIMING_BEACON_ONLY = 126,
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES = 127,
};
/**
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
if (sband-band != IEEE80211_BAND_2GHZ)
return;
+ if (!(mp-hw-flags IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
+ return;
+
mi-cck_supported = 0;
mi-cck_supported_short = 0;
for (i = 0; i 4; i++) {
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -807,7 +807,8 @@ void ath9k_set_hw_capab(struct ath_softc
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_SPECTRUM_MGMT |
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
- IEEE80211_HW_SUPPORTS_RC_TABLE;
+ IEEE80211_HW_SUPPORTS_RC_TABLE |
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
if (sc-sc_ah-caps.hw_caps ATH9K_HW_CAP_HT) {
hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1878,7 +1878,8 @@ void *carl9170_alloc(size_t priv_size)
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
IEEE80211_HW_SUPPORTS_RC_TABLE |
-IEEE80211_HW_SIGNAL_DBM;
+IEEE80211_HW_SIGNAL_DBM |
+IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
if (!modparam_noht) {
/*
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6327,7 +6327,8 @@ static int rt2800_probe_hw_mode(struct r
IEEE80211_HW_SUPPORTS_PS |
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_AMPDU_AGGREGATION |
- IEEE80211_HW_REPORTS_TX_ACK_STATUS;
+ IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+ IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
/*
* Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARC: gdbserver breakage in Big-Endian configuration #1
Hi Greg, On 08/19/2013 08:27 PM, greg Kroah-Hartman wrote: On Mon, Aug 19, 2013 at 09:08:49AM +, Vineet Gupta wrote: Hi Greg, I'd posted these patches for stable backport. Do I need to do anything more to get them included. https://patchwork.kernel.org/patch/2841153/ [1/2] ARC: gdbserver breakage in Big-Endian configuration #1https://patchwork.kernel.org/patch/2841153/] https://patchwork.kernel.org/patch/2841158/ [2/2] ARC: gdbserver breakage in Big-Endian configuration #2https://patchwork.kernel.org/patch/2841158/ I ignored them as I thought you were submitting them for upstream inclusion. If they are already in Linus's tree, then take a look at the file, Documentation/stable_kernel_rules.txt for how to send a patch for inclusion into a stable release (hint, I need to know the git commit id that the patch has in Linus's tree, which I didn't see anywhere here.) I'm sure I mentioned the commit-id in the patch. Hint, please look at annotation within ---8--- blocks in changelogs. The caveat however is we can't apply those exact commits as it is as that warrants more changes to be pulled in. However I'm going by the last stable kernel rule It or an equivalent fix must already exist in Linus' tree (upstream). Anyhow, since both these patches are extracted from same commit, I'll respin a single patch (with a small addition - again part of the same commit) and send it over. OK ! Thx, -Vineet -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
