linux-toradex.git, branch v3.0.16

Linux 3.0.16

2012-01-06T22:15:47+00:00

ath9k: Fix kernel panic in AR2427 in AP mode

2012-01-06T22:14:14+00:00

commit b25bfda38236f349cde0d1b28952f4eea2148d3f upstream.

don't do aggregation related stuff for 'AP mode client power save
handling' if aggregation is not enabled in the driver, otherwise it
will lead to panic because those data structures won't be never
intialized in 'ath_tx_node_init' if aggregation is disabled

	EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k]
	EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000
	ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c
	DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
	Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860
	task.ti=f40dc000)
	Stack:
	0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac
	f40e1cb0 f8186741
	f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001
	c0b4ba43 00000000
	0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac
	f2a30000 00010020
	Call Trace:
	[] ath9k_sta_notify+0x41/0x50 [ath9k]
	[] ? ath9k_get_survey+0x110/0x110 [ath9k]
	[] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350
	[mac80211]
	[] ? __module_address+0x95/0xb0
	[] ap_sta_ps_end+0x63/0xa0 [mac80211]
	[] ieee80211_rx_h_sta_process+0x156/0x2b0
	[mac80211]
	[] ieee80211_rx_handlers+0xce/0x510 [mac80211]
	[] ? trace_hardirqs_on+0xb/0x10
	[] ? skb_queue_tail+0x3e/0x50
	[] ieee80211_prepare_and_rx_handle+0x111/0x750
	[mac80211]
	[] ieee80211_rx+0x349/0xb20 [mac80211]
	[] ? ieee80211_rx+0x99/0xb20 [mac80211]
	[] ath_rx_tasklet+0x818/0x1d00 [ath9k]
	[] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
	[] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
	[] ath9k_tasklet+0xf3/0x1c0 [ath9k]
	[] tasklet_action+0xbe/0x180

Cc: Senthil Balasubramanian 
Cc: Rajkumar Manoharan 
Reported-by: Ashwin Mendonca 
Tested-by: Ashwin Mendonca 
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD->EXIT_ZOMBIE race

2012-01-06T22:14:14+00:00

commit 50b8d257486a45cba7b65ca978986ed216bbcc10 upstream.

Test-case:

	int main(void)
	{
		int pid, status;

		pid = fork();
		if (!pid) {
			for (;;) {
				if (!fork())
					return 0;
				if (waitpid(-1, &status, 0) < 0) {
					printf("ERR!! wait: %m\n");
					return 0;
				}
			}
		}

		assert(ptrace(PTRACE_ATTACH, pid, 0,0) == 0);
		assert(waitpid(-1, NULL, 0) == pid);

		assert(ptrace(PTRACE_SETOPTIONS, pid, 0,
					PTRACE_O_TRACEFORK) == 0);

		do {
			ptrace(PTRACE_CONT, pid, 0, 0);
			pid = waitpid(-1, NULL, 0);
		} while (pid > 0);

		return 1;
	}

It fails because ->real_parent sees its child in EXIT_DEAD state
while the tracer is going to change the state back to EXIT_ZOMBIE
in wait_task_zombie().

The offending commit is 823b018e which moved the EXIT_DEAD check,
but in fact we should not blame it. The original code was not
correct as well because it didn't take ptrace_reparented() into
account and because we can't really trust ->ptrace.

This patch adds the additional check to close this particular
race but it doesn't solve the whole problem. We simply can't
rely on ->ptrace in this case, it can be cleared if the tracer
is multithreaded by the exiting ->parent.

I think we should kill EXIT_DEAD altogether, we should always
remove the soon-to-be-reaped child from ->children or at least
we should never do the DEAD->ZOMBIE transition. But this is too
complex for 3.2.

Reported-and-tested-by: Denys Vlasenko 
Tested-by: Lukasz Michalik 
Acked-by: Tejun Heo 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "rtc: Disable the alarm in the hardware"

2012-01-06T22:14:13+00:00

commit 157e8bf8b4823bfcdefa6c1548002374b61f61df upstream.

This reverts commit c0afabd3d553c521e003779c127143ffde55a16f.

It causes failures on Toshiba laptops - instead of disabling the alarm,
it actually seems to enable it on the affected laptops, resulting in
(for example) the laptop powering on automatically five minutes after
shutdown.

There's a patch for it that appears to work for at least some people,
but it's too late to play around with this, so revert for now and try
again in the next merge window.

See for example

	http://bugs.debian.org/652869

Reported-and-bisected-by: Andreas Friedrich  (Toshiba Tecra)
Reported-by: Antonio-M. Corbi Bellot  (Toshiba Portege R500)
Reported-by: Marco Santos  (Toshiba Portege Z830)
Reported-by: Christophe Vu-Brugier   (Toshiba Portege R830)
Cc: Jonathan Nieder 
Requested-by: John Stultz 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

hung_task: fix false positive during vfork

2012-01-06T22:14:13+00:00

commit f9fab10bbd768b0e5254e53a4a8477a94bfc4b96 upstream.

vfork parent uninterruptibly and unkillably waits for its child to
exec/exit. This wait is of unbounded length. Ignore such waits
in the hung_task detector.

Signed-off-by: Mandeep Singh Baines 
Reported-by: Sasha Levin 
LKML-Reference: <1325344394.28904.43.camel@lappy>
Cc: Linus Torvalds 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: John Kacur 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms/atom: fix possible segfault in pm setup

2012-01-06T22:14:12+00:00

commit 4376eee92e5a8332b470040e672ea99cd44c826a upstream.

If we end up with no power states, don't look up
current vddc.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=44130

agd5f: fix patch formatting

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

xfs: log all dirty inodes in xfs_fs_sync_fs

2012-01-06T22:14:12+00:00

Commit be4f1ac828776bbc7868a68b465cd8eedb733cfd upstream.

Since Linux 2.6.36 the writeback code has introduces various measures for
live lock prevention during sync().  Unfortunately some of these are
actively harmful for the XFS model, where the inode gets marked dirty for
metadata from the data I/O handler.

The older_than_this checks that are now more strictly enforced since

    writeback: avoid livelocking WB_SYNC_ALL writeback

by only calling into __writeback_inodes_sb and thus only sampling the
current cut off time once.  But on a slow enough devices the previous
asynchronous sync pass might not have fully completed yet, and thus XFS
might mark metadata dirty only after that sampling of the cut off time for
the blocking pass already happened.  I have not myself reproduced this
myself on a real system, but by introducing artificial delay into the
XFS I/O completion workqueues it can be reproduced easily.

Fix this by iterating over all XFS inodes in ->sync_fs and log all that
are dirty.  This might log inode that only got redirtied after the
previous pass, but given how cheap delayed logging of inodes is it
isn't a major concern for performance.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Dave Chinner 
Tested-by: Mark Tinguely 
Reviewed-by: Mark Tinguely 
Signed-off-by: Ben Myers 
Signed-off-by: Greg Kroah-Hartman

xfs: log the inode in ->write_inode calls for kupdate

2012-01-06T22:14:12+00:00

Commit 0b8fd3033c308e4088760aa1d38ce77197b4e074 upstream.

If the writeback code writes back an inode because it has expired we currently
use the non-blockin ->write_inode path.  This means any inode that is pinned
is skipped.  With delayed logging and a workload that has very little log
traffic otherwise it is very likely that an inode that gets constantly
written to is always pinned, and thus we keep refusing to write it.  The VM
writeback code at that point redirties it and doesn't try to write it again
for another 30 seconds.  This means under certain scenarious time based
metadata writeback never happens.

Fix this by calling into xfs_log_inode for kupdate in addition to data
integrity syncs, and thus transfer the inode to the log ASAP.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Dave Chinner 
Tested-by: Mark Tinguely 
Reviewed-by: Mark Tinguely 
Signed-off-by: Ben Myers 
Signed-off-by: Greg Kroah-Hartman

xen/swiotlb: Use page alignment for early buffer allocation.

2012-01-06T22:14:11+00:00

commit 63a741757d15320a25ebf5778f8651cce2ed0611 upstream.

This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
(BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
would fail with:

ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO

The issue was the Xen-SWIOTLB was allocated such as that the end of
buffer was stradling a page (and also above 4GB). The fix was
spotted by Kalev Leonid  which was to piggyback on git commit
e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
for early buffer allocation" which:

	We could call free_bootmem_late() if swiotlb is not used, and
	it will shrink to page alignment.

	So alloc them with page alignment at first, to avoid lose two pages

And doing that fixes the outstanding issue.

Suggested-by: "Kalev, Leonid" 
Reported-and-Tested-by: "Taylor, Neal E" 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

mfd: Turn on the twl4030-madc MADC clock

2012-01-06T22:14:11+00:00

commit 3d6271f92e98094584fd1e609a9969cd33e61122 upstream.

Without turning the MADC clock on, no MADC conversions occur.

$ cat /sys/class/hwmon/hwmon0/device/in8_input
[   53.428436] twl4030_madc twl4030_madc: conversion timeout!
cat: read error: Resource temporarily unavailable

Signed-off-by: Kyle Manna 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Greg Kroah-Hartman