aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2010-09-30[CPUFREQ] acpi-cpufreq: add missing __percpu markupNamhyung Kim1-1/+1
acpi_perf_data is a percpu pointer but was missing __percpu markup. Add it. Signed-off-by: Namhyung Kim <[email protected]> Acked-by: Tejun Heo <[email protected]> Signed-off-by: Dave Jones <[email protected]>
2010-09-30Merge branch 'master' of ↵David S. Miller3-6/+2
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
2010-09-30Fix up more fallout form alpha signal cleanupsLinus Torvalds1-1/+1
Commit c52c2ddc1dfa ("alpha: switch osf_sigprocmask() to use of sigprocmask()") had several problems. The more obvious compile issues got fixed in commit 0f44fbd297e1 ("alpha: fix compile problem in arch/alpha/kernel/signal.c"), but it also caused a regression. Since _BLOCKABLE is already the set of signals that can be blocked, the code should do "newmask & _BLOCKABLE" rather than inverting _BLOCKABLE before masking. Reported-by: Michael Cree <[email protected]> Patch-by: Al Viro <[email protected]> Patch-by: Ivan Kokshaysky <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2010-09-30Bluetooth: Fix deadlock in the ERTM logicGustavo F. Padovan1-0/+18
The Enhanced Retransmission Mode(ERTM) is a realiable mode of operation of the Bluetooth L2CAP layer. Think on it like a simplified version of TCP. The problem we were facing here was a deadlock. ERTM uses a backlog queue to queue incomimg packets while the user is helding the lock. At some moment the sk_sndbuf can be exceeded and we can't alloc new skbs then the code sleep with the lock to wait for memory, that stalls the ERTM connection once we can't read the acknowledgements packets in the backlog queue to free memory and make the allocation of outcoming skb successful. This patch actually affect all users of bt_skb_send_alloc(), i.e., all L2CAP modes and SCO. We are safe against socket states changes or channels deletion while the we are sleeping wait memory. Checking for the sk->sk_err and sk->sk_shutdown make the code safe, since any action that can leave the socket or the channel in a not usable state set one of the struct members at least. Then we can check both of them when getting the lock again and return with the proper error if something unexpected happens. Signed-off-by: Gustavo F. Padovan <[email protected]> Signed-off-by: Ulisses Furquim <[email protected]>
2010-09-30Revert "Bluetooth: Don't accept ConfigReq if we aren't in the BT_CONFIG state"Gustavo F. Padovan1-7/+1
This reverts commit 8cb8e6f1684be13b51f8429b15f39c140326b327. That commit introduced a regression with the Bluetooth Profile Tuning Suite(PTS), Reverting this make sure that L2CAP is in a qualificable state. Signed-off-by: Gustavo F. Padovan <[email protected]>
2010-09-30Bluetooth: Fix inconsistent lock state with RFCOMMGustavo F. Padovan1-0/+4
When receiving a rfcomm connection with the old dund deamon a inconsistent lock state happens. That's because interrupts were already disabled by l2cap_conn_start() when rfcomm_sk_state_change() try to lock the spin_lock. As result we may have a inconsistent lock state for l2cap_conn_start() after rfcomm_sk_state_change() calls bh_lock_sock() and disable interrupts as well. [ 2833.151999] [ 2833.151999] ================================= [ 2833.151999] [ INFO: inconsistent lock state ] [ 2833.151999] 2.6.36-rc3 #2 [ 2833.151999] --------------------------------- [ 2833.151999] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. [ 2833.151999] krfcommd/2306 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 2833.151999] (slock-AF_BLUETOOTH){+.?...}, at: [<ffffffffa00bcb56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm] [ 2833.151999] {IN-SOFTIRQ-W} state was registered at: [ 2833.151999] [<ffffffff81094346>] __lock_acquire+0x5b6/0x1560 [ 2833.151999] [<ffffffff8109534a>] lock_acquire+0x5a/0x70 [ 2833.151999] [<ffffffff81392b6c>] _raw_spin_lock+0x2c/0x40 [ 2833.151999] [<ffffffffa00a5092>] l2cap_conn_start+0x92/0x640 [l2cap] [ 2833.151999] [<ffffffffa00a6a3f>] l2cap_sig_channel+0x6bf/0x1320 [l2cap] [ 2833.151999] [<ffffffffa00a9173>] l2cap_recv_frame+0x133/0x770 [l2cap] [ 2833.151999] [<ffffffffa00a997b>] l2cap_recv_acldata+0x1cb/0x390 [l2cap] [ 2833.151999] [<ffffffffa000db4b>] hci_rx_task+0x2ab/0x450 [bluetooth] [ 2833.151999] [<ffffffff8106b22b>] tasklet_action+0xcb/0xe0 [ 2833.151999] [<ffffffff8106b91e>] __do_softirq+0xae/0x150 [ 2833.151999] [<ffffffff8102bc0c>] call_softirq+0x1c/0x30 [ 2833.151999] [<ffffffff8102ddb5>] do_softirq+0x75/0xb0 [ 2833.151999] [<ffffffff8106b56d>] irq_exit+0x8d/0xa0 [ 2833.151999] [<ffffffff8104484b>] smp_apic_timer_interrupt+0x6b/0xa0 [ 2833.151999] [<ffffffff8102b6d3>] apic_timer_interrupt+0x13/0x20 [ 2833.151999] [<ffffffff81029dfa>] cpu_idle+0x5a/0xb0 [ 2833.151999] [<ffffffff81381ded>] rest_init+0xad/0xc0 [ 2833.151999] [<ffffffff817ebc4d>] start_kernel+0x2dd/0x2e8 [ 2833.151999] [<ffffffff817eb2e6>] x86_64_start_reservations+0xf6/0xfa [ 2833.151999] [<ffffffff817eb3ce>] x86_64_start_kernel+0xe4/0xeb [ 2833.151999] irq event stamp: 731 [ 2833.151999] hardirqs last enabled at (731): [<ffffffff8106b762>] local_bh_enable_ip+0x82/0xe0 [ 2833.151999] hardirqs last disabled at (729): [<ffffffff8106b93e>] __do_softirq+0xce/0x150 [ 2833.151999] softirqs last enabled at (730): [<ffffffff8106b96e>] __do_softirq+0xfe/0x150 [ 2833.151999] softirqs last disabled at (711): [<ffffffff8102bc0c>] call_softirq+0x1c/0x30 [ 2833.151999] [ 2833.151999] other info that might help us debug this: [ 2833.151999] 2 locks held by krfcommd/2306: [ 2833.151999] #0: (rfcomm_mutex){+.+.+.}, at: [<ffffffffa00bb744>] rfcomm_run+0x174/0xb20 [rfcomm] [ 2833.151999] #1: (&(&d->lock)->rlock){+.+...}, at: [<ffffffffa00b9223>] rfcomm_dlc_accept+0x53/0x100 [rfcomm] [ 2833.151999] [ 2833.151999] stack backtrace: [ 2833.151999] Pid: 2306, comm: krfcommd Tainted: G W 2.6.36-rc3 #2 [ 2833.151999] Call Trace: [ 2833.151999] [<ffffffff810928e1>] print_usage_bug+0x171/0x180 [ 2833.151999] [<ffffffff810936c3>] mark_lock+0x333/0x400 [ 2833.151999] [<ffffffff810943ca>] __lock_acquire+0x63a/0x1560 [ 2833.151999] [<ffffffff810948b5>] ? __lock_acquire+0xb25/0x1560 [ 2833.151999] [<ffffffff8109534a>] lock_acquire+0x5a/0x70 [ 2833.151999] [<ffffffffa00bcb56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm] [ 2833.151999] [<ffffffff81392b6c>] _raw_spin_lock+0x2c/0x40 [ 2833.151999] [<ffffffffa00bcb56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm] [ 2833.151999] [<ffffffffa00bcb56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm] [ 2833.151999] [<ffffffffa00b9239>] rfcomm_dlc_accept+0x69/0x100 [rfcomm] [ 2833.151999] [<ffffffffa00b9a49>] rfcomm_check_accept+0x59/0xd0 [rfcomm] [ 2833.151999] [<ffffffffa00bacab>] rfcomm_recv_frame+0x9fb/0x1320 [rfcomm] [ 2833.151999] [<ffffffff813932bb>] ? _raw_spin_unlock_irqrestore+0x3b/0x60 [ 2833.151999] [<ffffffff81093acd>] ? trace_hardirqs_on_caller+0x13d/0x180 [ 2833.151999] [<ffffffff81093b1d>] ? trace_hardirqs_on+0xd/0x10 [ 2833.151999] [<ffffffffa00bb7f1>] rfcomm_run+0x221/0xb20 [rfcomm] [ 2833.151999] [<ffffffff813905e7>] ? schedule+0x287/0x780 [ 2833.151999] [<ffffffffa00bb5d0>] ? rfcomm_run+0x0/0xb20 [rfcomm] [ 2833.151999] [<ffffffff81081026>] kthread+0x96/0xa0 [ 2833.151999] [<ffffffff8102bb14>] kernel_thread_helper+0x4/0x10 [ 2833.151999] [<ffffffff813936bc>] ? restore_args+0x0/0x30 [ 2833.151999] [<ffffffff81080f90>] ? kthread+0x0/0xa0 [ 2833.151999] [<ffffffff8102bb10>] ? kernel_thread_helper+0x0/0x10 Signed-off-by: Gustavo F. Padovan <[email protected]>
2010-09-30Bluetooth: Simplify L2CAP Streaming mode sendingGustavo F. Padovan1-17/+7
As we don't have any error control on the Streaming mode, i.e., we don't need to keep a copy of the skb for later resending we don't need to call skb_clone() on it. Then we can go one further here, and dequeue the skb before sending it, that also means we don't need to look to sk->sk_send_head anymore. The patch saves memory and time when sending Streaming mode data, so it is good to mainline. Signed-off-by: Gustavo F. Padovan <[email protected]>
2010-09-30Bluetooth: fix MTU L2CAP configuration parameterAndrei Emeltchenko1-3/+3
When receiving L2CAP negative configuration response with respect to MTU parameter we modify wrong field. MTU here means proposed value of MTU that the remote device intends to transmit. So for local L2CAP socket it is pi->imtu. Signed-off-by: Andrei Emeltchenko <[email protected]> Acked-by: Ville Tervo <[email protected]> Signed-off-by: Gustavo F. Padovan <[email protected]>
2010-09-30Bluetooth: Only enable L2CAP FCS for ERTM or streamingMat Martineau1-6/+13
This fixes a bug which caused the FCS setting to show L2CAP_FCS_CRC16 with L2CAP modes other than ERTM or streaming. At present, this only affects the FCS value shown with getsockopt() for basic mode. Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: Gustavo F. Padovan <[email protected]>
2010-09-30of/i2c: Fix module load order issue caused by of_i2c.cGrant Likely4-4/+9
Commit 959e85f7, "i2c: add OF-style registration and binding" caused a module dependency loop where of_i2c.c calls functions in i2c-core, and i2c-core calls of_i2c_register_devices() in of_i2c. This means that when i2c support is built as a module when CONFIG_OF is set, then neither i2c_core nor of_i2c are able to be loaded. This patch fixes the problem by moving the of_i2c_register_devices() calls back into the device drivers. Device drivers already specifically request the core code to parse the device tree for devices anyway by setting the of_node pointer, so it isn't a big deal to also call the registration function. The drivers just become slightly more verbose. Signed-off-by: Grant Likely <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2010-09-30i2c: Fix checks which cause legacy suspend to never get calledRajendra Nayak1-20/+24
For devices which are not adapted to runtime PM a call to pm_runtime_suspended always returns true. Hence the pm_runtime_suspended checks below prevent legacy suspend from getting called. So do a pm_runtime_suspended check only for devices with a dev_pm_ops populated (which hence do not rely on the legacy suspend.) Signed-off-by: Rajendra Nayak <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Cc: Ben Dooks <[email protected]> Cc: Mark Brown <[email protected]> Cc: Kevin Hilman <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2010-09-30i2c-pca: Fix waitforcompletion() return valueYegor Yefremov2-8/+15
ret is still -1, if during the polling read_byte() returns at once with I2C_PCA_CON_SI set. So ret > 0 would lead *_waitforcompletion() to return 0, in spite of the proper behavior. The routine was rewritten, so that ret has always a proper value, before returning. Signed-off-by: Yegor Yefremov <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Cc: [email protected] Signed-off-by: Jean Delvare <[email protected]>
2010-09-30i2c: Fix for suspend/resume issueVishwanath BS1-6/+0
In current i2c core driver, call to pm_runtime_set_active from i2c_device_pm_resume will unconditionally enable i2c module and increment child count of the parent. Because of this, in CPU Idle path, i2c does not idle, preventing Core to enter retention. Also i2c module will not be suspended upon system suspend as pm_runtime_set_suspended is not called from i2c_device_pm_suspend. This issue is fixed by removing pm_runtime_set_active call from resume path which is not necessary. This fix has been tested on OMAP4430. Signed-off-by: Partha Basak <[email protected]> Signed-off-by: Vishwanath BS <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Ben Dooks <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2010-09-30i2c: Remove obsolete cleanup for clientdataWolfram Sang4-6/+0
A few new i2c-drivers came into the kernel which clear the clientdata-pointer on exit. This is obsolete meanwhile, so fix it and hope the word will spread. Signed-off-by: Wolfram Sang <[email protected]> Acked-by: Mark Brown <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2010-09-30V4L/DVB: v4l: radio: si470x: fix unneeded free_irq() callMarek Szyprowski1-1/+1
In case of error during probe() the driver calls free_irq() function on not yet allocated irq. This patches fixes the call sequence in case of the error. Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Kyungmin Park <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2010-09-30V4L/DVB: v4l: videobuf: prevent passing a NULL to dma_free_coherent()Pawel Osciak1-2/+4
When a driver that uses videobuf-dma-contig is used with the USERPTR memory access method a kernel oops might happen: a NULL address may be passed to dma_free_coherent(). This happens when an application calls REQBUFS and then exits without queuing any buffers. This patch fixes that bug. Signed-off-by: Pawel Osciak <[email protected]> Signed-off-by: Kyungmin Park <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2010-09-30V4L/DVB: ir-core: Fix null dereferences in the protocols sysfs interfaceBrian Rogers1-6/+11
For some cards, ir_dev->props and ir_dev->raw are both NULL. These cards are using built-in IR decoding instead of raw, and can't easily be made to switch protocols. So upon reading /sys/class/rc/rc?/protocols on such a card, return 'builtin' as the supported and enabled protocol. Return -EINVAL on any attempts to change the protocol. And most important of all, don't crash. Signed-off-by: Brian Rogers <[email protected]> Acked-by: Jarod Wilson <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2010-09-30perf, x86: Handle in flight NMIs on P4 platformCyrill Gorcunov1-1/+5
Stephane reported we've forgot to guard the P4 platform against spurious in-flight performance IRQs. Fix it. This fixes potential spurious 'dazed and confused' NMI messages. Reported-by: Stephane Eranian <[email protected]> Signed-off-by: Cyrill Gorcunov <[email protected]> Signed-off-by: Don Zickus <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Robert Richter <[email protected]> Cc: Lin Ming <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2010-09-30oprofile, ARM: Release resources on failureRobert Richter1-2/+5
This patch fixes a resource leak on failure, where the oprofilefs and some counters may not released properly. Signed-off-by: Robert Richter <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: [email protected] Cc: <[email protected]> # .35.x LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2010-09-29Merge branch 'fixes' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2 * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2: ocfs2: Don't walk off the end of fast symlinks.
2010-09-30drm: i810/i830: fix locked ioctl variantArnd Bergmann2-2/+2
The i810 and i830 device drivers may replace their file operations on an open file descriptor. My previous patch to move the BKL out of the common DRM code into these drivers only caught the default file operations, not the ones that actually end up being used. Found while trying to come up with a way to kill the BKL for good in these drivers. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2010-09-29Phonet: Correct header retrieval after pskb_may_pullKumar Sanghvi1-1/+2
Retrieve the header after doing pskb_may_pull since, pskb_may_pull could change the buffer structure. This is based on the comment given by Eric Dumazet on Phonet Pipe controller patch for a similar problem. Signed-off-by: Kumar Sanghvi <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Eric Dumazet <[email protected]> Acked-by: Rémi Denis-Courmont <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2010-09-29um: Proper Fix for f25c80a4: remove duplicate structure field initializationBoaz Harrosh1-14/+3
uml_net_set_mac() was broken and luckily it was never used, before. What it was trying to do is spin_lock before memcopy the mac address. Linus attempted to fix it in assumption that someone decided the lock was needed. But since it was never ever used at all, and was just dead code, I think we can assume that it is not needed, after all. On the other hand patch [f25c80a4] was trying to use eth_mac_addr() in eth_configure(), *which was the real fallout*. Because of state checks done inside eth_mac_addr() the address was never set. I have not reintroduced the memcpy wrapper, but I've put a comment for future cats. The code now is back to exactly as it was before [f25c80a4]. With the cleanup applied. If the spin_lock is indeed needed then a contender should supply a test case that fails, then fix it with the proper locking, as a separate unrelated patch. CC: Julia Lawall <[email protected]> CC: David S. Miller <[email protected]> CC: Andrew Morton <[email protected]> CC: Al Viro <[email protected]> Tested-by: Boaz Harrosh <[email protected]> Signed-off-by: Boaz Harrosh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2010-09-29Merge branch 'fixes' of ↵Linus Torvalds2-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx: dmaengine: fix interrupt clearing for mv_xor missing inline keyword for static function in linux/dmaengine.h dma/shdma: move dereference below the NULL check
2010-09-29ocfs2: Don't walk off the end of fast symlinks.Joel Becker1-1/+1
ocfs2 fast symlinks are NUL terminated strings stored inline in the inode data area. However, disk corruption or a local attacker could, in theory, remove that NUL. Because we're using strlen() (my fault, introduced in a731d1 when removing vfs_follow_link()), we could walk off the end of that string. Signed-off-by: Joel Becker <[email protected]> Cc: [email protected]
2010-09-29Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfsLinus Torvalds2-19/+30
* 'for-linus' of git://oss.sgi.com/xfs/xfs: xfs: force background CIL push under sustained load
2010-09-29Merge branch 'for-linus' of ↵Linus Torvalds2-8/+14
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6: mfd: Fix max8925 irq control bit incorrect setting mfd: Ignore non-GPIO IRQs when setting wm831x IRQ types
2010-09-29fix OMAP2 MTD build failureDaniel J Blueman1-1/+1
Fix build failure from recent interface change and merge. Tested on OMAP3430. Signed-off-by: Daniel J Blueman <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2010-09-29cifs: set backing_dev_info on new S_ISREG inodesJeff Layton1-0/+2
Testing on very recent kernel (2.6.36-rc6) made this warning pop: WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x65/0x70() Hardware name: Dirtiable inode bdi default != sb bdi cifs ...the following patch fixes it and seems to be the obviously correct thing to do for cifs. Cc: [email protected] Acked-by: Dave Kleikamp <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Steve French <[email protected]>
2010-09-29Merge branches 'apei', 'battery-mwh-fix', 'bugzilla-10807', ↵Len Brown19-57/+112
'bugzilla-14736', 'bugzilla-14679', 'bugzilla-16396', 'launchpad-613381' and 'misc' into release
2010-09-29ACPI: invoke DSDT corruption workaround on all Toshiba SatelliteLen Brown1-11/+3
Our list of Toshiba Satellite models that require this workaround is growing -- so invoke the workaround for the entire product line. https://bugzilla.kernel.org/show_bug.cgi?id=14679 Signed-off-by: Len Brown <[email protected]>
2010-09-29ACPI, APEI, Fix ERST MOVE_DATA instruction implementationHuang Ying1-3/+20
The src_base and dst_base fields in apei_exec_context are physical address, so they should be ioremaped before being used in ERST MOVE_DATA instruction. Reported-by: Javier Martinez Canillas <[email protected]> Reported-by: Andrew Morton <[email protected]> Signed-off-by: Huang Ying <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-29ACPI: fan: Fix more unbalanced code blockLuis Henriques1-0/+2
commit 934231de706d2579fae14f5857fcd8de991009ff fixes an unbalanced CONFIG_ACPI_PROCFS code block during module initialisation. This patch fixes similar issue but for the module exit. Signed-off-by: Luis Henriques <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-29ACPI: acpi_pad: simplify code to avoid false gcc build warningLen Brown1-16/+18
acpi_pad.c:432: warning: ‘num_cpus’ may be used uninitialized in this function gcc 4.4.4 was unable to notice that num_cpus is always set. Re-arrange the code to un-confuse gcc, and also make it easier for humans to read.... Signed-off-by: Len Brown <[email protected]>
2010-09-29ACPI, APEI, Fix error path for memory allocationHuang Ying2-11/+26
In ERST debug/test support patch, a dynamic allocated buffer is used. The may-failed memory allocation should be tried firstly before free the previous buffer. APEI resource management memory allocation related error path is fixed too. v2: - Fix error messages for APEI resources management Signed-off-by: Huang Ying <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-29ACPI, APEI, HEST Fix the unsuitable usage of platform_dataJin Dongming2-5/+8
platform_data in hest_parse_ghes() is used for saving the address of entry information of erst_tab. When the device is failed to be added, platform_data will be freed by platform_device_put(). But the value saved in platform_data should not be freed here. If it is done, it will make system panic. So I think platform_data should save the address of allocated memory which saves entry information of erst_tab. This patch fixed it and I confirmed it on x86_64 next-tree. v2: Transport the pointer of hest_hdr to platform_data using platform_device_add_data() Signed-off-by: Jin Dongming <[email protected]> Signed-off-by: Huang Ying <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-29ACPI, APEI, Fix acpi_pre_map() return valueJin Dongming1-1/+1
After we ioremap() a new region, we call __acpi_try_ioremap() to see whether another thread has already mapped the same region. This check clobbers "vaddr", so compute the return value of acpi_pre_map() using the ioremap() result "map->vaddr" instead. v2: Modified the unsuitable description of patch. v3: Removed unlikely() check and made description simpler. Signed-off-by: Jin Dongming <[email protected]> Reviewed-by: Andi Kleen <[email protected]> Signed-off-by: Huang Ying <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-29ACPI, APEI, Fix APEI related table size checkingHuang Ying2-2/+6
On Huang Ying's machine: erst_tab->header_length == sizeof(struct acpi_table_einj) but Yinghai reported that on his machine, erst_tab->header_length == sizeof(struct acpi_table_einj) - sizeof(struct acpi_table_header) To make erst table size checking code works on all systems, both testing are treated as PASS. Same situation applies to einj_tab->header_length, so corresponding table size checking is changed in similar way too. v2: - Treat both table size as valid Originally-by: Yinghai Lu <[email protected]> Signed-off-by: Huang Ying <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-29xfs: force background CIL push under sustained loadDave Chinner2-19/+30
I have been seeing occasional pauses in transaction throughput up to 30s long under heavy parallel workloads. The only notable thing was that the xfsaild was trying to be active during the pauses, but making no progress. It was running exactly 20 times a second (on the 50ms no-progress backoff), and the number of pushbuf events was constant across this time as well. IOWs, the xfsaild appeared to be stuck on buffers that it could not push out. Further investigation indicated that it was trying to push out inode buffers that were pinned and/or locked. The xfsbufd was also getting woken at the same frequency (by the xfsaild, no doubt) to push out delayed write buffers. The xfsbufd was not making any progress because all the buffers in the delwri queue were pinned. This scan- and-make-no-progress dance went one in the trace for some seconds, before the xfssyncd came along an issued a log force, and then things started going again. However, I noticed something strange about the log force - there were way too many IO's issued. 516 log buffers were written, to be exact. That added up to 129MB of log IO, which got me very interested because it's almost exactly 25% of the size of the log. He delayed logging code is suppose to aggregate the minimum of 25% of the log or 8MB worth of changes before flushing. That's what really puzzled me - why did a log force write 129MB instead of only 8MB? Essentially what has happened is that no CIL pushes had occurred since the previous tail push which cleared out 25% of the log space. That caused all the new transactions to block because there wasn't log space for them, but they kick the xfsaild to push the tail. However, the xfsaild was not making progress because there were buffers it could not lock and flush, and the xfsbufd could not flush them because they were pinned. As a result, both the xfsaild and the xfsbufd could not move the tail of the log forward without the CIL first committing. The cause of the problem was that the background CIL push, which should happen when 8MB of aggregated changes have been committed, is being held off by the concurrent transaction commit load. The background push does a down_write_trylock() which will fail if there is a concurrent transaction commit holding the push lock in read mode. With 8 CPUs all doing transactions as fast as they can, there was enough concurrent transaction commits to hold off the background push until tail-pushing could no longer free log space, and the halt would occur. It should be noted that there is no reason why it would halt at 25% of log space used by a single CIL checkpoint. This bug could definitely violate the "no transaction should be larger than half the log" requirement and hence result in corruption if the system crashed under heavy load. This sort of bug is exactly the reason why delayed logging was tagged as experimental.... The fix is to start blocking background pushes once the threshold has been exceeded. Rework the threshold calculations to keep the amount of log space a CIL checkpoint can use to below that of the AIL push threshold to avoid the problem completely. Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Alex Elder <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2010-09-29mfd: Fix max8925 irq control bit incorrect settingKevin Liu1-6/+7
In max8925_irq_sync_unlock(), irq control bit is set at the same time. Zero means enabling irq, and one means disabling irq. The original code is: irq_chg[0] &= irq_data->enable; It should be changed to: irq_chg[0] &= ~irq_data->enable; Otherwise, irq control bit is mess. Signed-off-by: Kevin Liu <[email protected]> Signed-off-by: Haojian Zhuang <[email protected]> Signed-off-by: Samuel Ortiz <[email protected]>
2010-09-29mfd: Ignore non-GPIO IRQs when setting wm831x IRQ typesMark Brown1-2/+7
The driver was originally tested with an additional patch which made this unneeded but that patch had issuges and got lost on the way to mainline, causing problems when the errors are reported. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Samuel Ortiz <[email protected]> Cc: [email protected]
2010-09-28ip_gre: Fix dependencies wrt. ipv6.David S. Miller1-0/+1
The GRE tunnel driver needs to invoke icmpv6 helpers in the ipv6 stack when ipv6 support is enabled. Therefore if IPV6 is enabled, we have to enforce that GRE's enabling (modular or static) matches that of ipv6. Reported-by: Patrick McHardy <[email protected]> Reported-by: Herbert Xu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2010-09-28Merge branch 'meego-7093' into idle-releaseLen Brown1-0/+20
2010-09-28acpi_idle: add missing \n to printkLen Brown1-1/+1
otherwise, these two lines print as one: ACPI: acpi_idle yielding to intel_idle ACPI: SSDT 3f5d8741 00203 (v02 PmRef Cpu0Ist 00003000 INTL 20050624) Signed-off-by: Len Brown <[email protected]>
2010-09-28intel_idle: add missing __percpu markupNamhyung Kim1-1/+1
intel_idle_cpuidle_devices is a percpu pointer but was missing __percpu markup. Signed-off-by: Namhyung Kim <[email protected]> Acked-by: Tejun Heo <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-28intel_idle: Change mode 755 => 644Thomas Weber1-0/+0
Remove execution permission from source file. Signed-off-by: Thomas Weber <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-28cpuidle: Fix typosLucas De Marchi1-1/+1
Signed-off-by: Len Brown <[email protected]>
2010-09-28ACPI: Disable Windows Vista compatibility for Toshiba P305DZhang Rui1-0/+8
Disable the Windows Vista (SP1) compatibility for Toshiba P305D. http://bugzilla.kernel.org/show_bug.cgi?id=14736 Signed-off-by: Zhang Rui <[email protected]> Signed-off-by: Len Brown <[email protected]>
2010-09-28ACPI: Kconfig: fix typo.Andrea Gelmini1-1/+1
"power of" -> "power off" Signed-off-by: Len Brown <[email protected]>
2010-09-28ACPI: add missing __percpu markup in arch/x86/kernel/acpi/cstate.cNamhyung Kim1-1/+1
cpu_cstate_entry is a percpu pointer but was missing __percpu markup. Signed-off-by: Namhyung Kim <[email protected]> Acked-by: Tejun Heo <[email protected]> Signed-off-by: Len Brown <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.