| Age | Commit message (Collapse) | Author |
|---|
|
While 0xffdc devices have their IR protocol hard-coded into the firmware
of the device, we have no known way of telling what it is if we don't
have the device's config byte already in the driver. Unknown devices
default to the imon native protocol, but might actually be rc6, so we
should set the driver up such that the user can load the rc6 keytable
from userspace and still have a working device ahead of its config byte
being added to the driver.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Another device with the 0xffdc device id, this one with 0x7e in the
config byte. Its an iMON VFD + RC6 IR, in a CoolerMaster 260 case.
Reported-by: Filip Streibl <filip@streibl.cz>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
The comment says "wait 15ms", but the code says jiffies_to_msecs(15)
instead of msecs_to_jiffies(15). Fix that. Tested, works fine with both
rc5 and rc6 decode, in-kernel and via lirc userspace, with an HVR-1150.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
With hardware that has to use ir_raw_event_store_edge to collect IR
sample durations, we were not doing an event reset unless
IR_MAX_DURATION had passed. That's around 4 seconds. So if someone
presses up, then down, with less than 4 seconds in between, they'd get
the initial up, then up and down upon pressing down.
To fix this, I've lowered the "send a reset event" logic's threshold to
the input device's REP_DELAY (defaults to 500ms), and with an
saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get
*much* better behavior out of the remote now. Special thanks to Devin
for providing the hardware to investigate this issue.
CC: stable@kernel.org
CC: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
There's really no good reason not to just grab the desired IRQ at driver
init time, instead of every time the lirc device node is accessed. This
also improves the speed and reliability with which a serial transmitter
can operate, as back-to-back transmission attempts (i.e., channel change
to a multi-digit channel) don't have to spend time acquiring and then
releasing the IRQ for every digit, sometimes multiple times, if lircd
has been told to use the min_repeat parameter.
CC: devel@driverdev.osuosl.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced in
commit 5bd6b0464b68d429bc8a3fe6595d19c39dfc4d95, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included in,
but alas, stuff happens...
Acked-by: Andy Walls <awalls@md.metrocast.net>
CC: stable@kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Both consumers of RC_MAP_PINNACLE_PCTV_HD send along full RC-5
scancodes, so this update makes this keymap actually *have* full
scancodes, heisted from rc-dib0700-rc5.c. This should fix out of the box
remote functionality for the Pinnacle PCTV HD 800i (cx88 pci card) and
PCTV HD Pro 801e (em28xx usb stick).
CC: stable@kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Thanks to the intrepid testing and debugging of Matthijs van Drunen, it
was uncovered that at least some variants of the ITE8709 need to use pnp
resource 2, rather than 0, for things to function properly. Resource 0
has a length of only 1, and if you try to bypass the pnp_port_len check
and use it anyway (with either a length of 1 or 2), the system in
question's trackpad ceased to function.
The circa lirc 0.8.7 lirc_ite8709 driver used resource 2, but the value
was (amusingly) changed to 0 by way of a patch from ITE themselves, so I
don't know if there may be variants where 0 actually *is* correct, but
at least in this case and in the original lirc_ite8709 driver author's
case, it sure looks like 2 is the right value.
This fix should probably be applied to all stable kernels with the
ite-cir driver, lest we nuke more people's trackpads.
Tested-by: Matthijs van Drunen
CC: Juan Jesús García de Soria <skandalfo@gmail.com>
CC: stable@kernel.org
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
mx1_camera_add_device() can return an uninitialized value of ret.
Signed-off-by: Andre Bartke <andre.bartke@gmail.com>
[g.liakhovetski@gmx.de: modified the fix to remove "ret" completely]
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
The usecase where, user allocates small size of buffer
through bootargs (video1_bufsize/video2_bufsize) and later from application
tries to set the format which requires larger buffer size, driver doesn't
check for insufficient buffer size and allows application to map extra buffer.
This leads to kernel crash, when user application tries to access memory
beyond the allocation size.
Added check in both mmap and reqbuf call back function,
and return error if the size of the buffer allocated by user through
bootargs is less than the S_FMT size.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
With addition of media-controller framework, now we have various
device nodes (/dev/videoX) getting created, so hardcoding
minor number in video_register_device() is not recommended.
So let V4L2 framework choose free minor number for the device.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
The omap_vout_new_crop() function has possible bug, uses uninitialized
variable "crop.width/height" which is actually output of the function.
Instead we should be using "try_crop.width/height" to calculate the
resizer value.
Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Benjamin S. reported that he was unable to suspend his machine while
it had a cifs share mounted. The freezer caused this to spew when he
tried it:
-----------------------[snip]------------------
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ...
Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0):
cifsd S ffff880127f7b1b0 0 1821 2 0x00800000
ffff880127f7b1b0 0000000000000046 ffff88005fe008a8 ffff8800ffffffff
ffff880127cee6b0 0000000000011100 ffff880127737fd8 0000000000004000
ffff880127737fd8 0000000000011100 ffff880127f7b1b0 ffff880127736010
Call Trace:
[<ffffffff811e85dd>] ? sk_reset_timer+0xf/0x19
[<ffffffff8122cf3f>] ? tcp_connect+0x43c/0x445
[<ffffffff8123374e>] ? tcp_v4_connect+0x40d/0x47f
[<ffffffff8126ce41>] ? schedule_timeout+0x21/0x1ad
[<ffffffff8126e358>] ? _raw_spin_lock_bh+0x9/0x1f
[<ffffffff811e81c7>] ? release_sock+0x19/0xef
[<ffffffff8123e8be>] ? inet_stream_connect+0x14c/0x24a
[<ffffffff8104485b>] ? autoremove_wake_function+0x0/0x2a
[<ffffffffa02ccfe2>] ? ipv4_connect+0x39c/0x3b5 [cifs]
[<ffffffffa02cd7b7>] ? cifs_reconnect+0x1fc/0x28a [cifs]
[<ffffffffa02cdbdc>] ? cifs_demultiplex_thread+0x397/0xb9f [cifs]
[<ffffffff81076afc>] ? perf_event_exit_task+0xb9/0x1bf
[<ffffffffa02cd845>] ? cifs_demultiplex_thread+0x0/0xb9f [cifs]
[<ffffffffa02cd845>] ? cifs_demultiplex_thread+0x0/0xb9f [cifs]
[<ffffffff810444a1>] ? kthread+0x7a/0x82
[<ffffffff81002d14>] ? kernel_thread_helper+0x4/0x10
[<ffffffff81044427>] ? kthread+0x0/0x82
[<ffffffff81002d10>] ? kernel_thread_helper+0x0/0x10
Restarting tasks ... done.
-----------------------[snip]------------------
We do attempt to perform a try_to_freeze in cifs_reconnect, but the
connection attempt itself seems to be taking longer than 20s to time
out. The connect timeout is governed by the socket send and receive
timeouts, so we can shorten that period by setting those timeouts
before attempting the connect instead of after.
Adam Williamson tested the patch and said that it seems to have fixed
suspending on his laptop when a cifs share is mounted.
Reported-by: Benjamin S <da_joind@gmx.net>
Tested-by: Adam Williamson <awilliam@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
machines
During 32/64 NUMA init unification, commit 797390d855 ("x86-32,
NUMA: use sparse_memory_present_with_active_regions()") made
32bit mm init call memory_present() automatically from
active_regions instead of leaving it to each NUMA init path.
This commit description is inaccurate - memory_present() calls
aren't the same for flat and numaq. After the commit,
memory_present() is only called for the intersection of e820 and
NUMA layout. Before, on flatmem, memory_present() would be
called from 0 to max_pfn. After, it would be called only on the
areas that e820 indicates to be populated.
This is how x86_64 works and should be okay as memmap is allowed
to contain holes; however, x86_32 DISCONTIGMEM is missing
early_pfn_valid(), which makes memmap_init_zone() assume that
memmap doesn't contain any hole. This leads to the following
oops if e820 map contains holes as it often does on machine with
near or more 4GiB of memory by calling pfn_to_page() on a pfn
which isn't mapped to a NUMA node, a reported by Conny Seidel:
BUG: unable to handle kernel paging request at 000012b0
IP: [<c1aa13ce>] memmap_init_zone+0x6c/0xf2
*pdpt =3D 0000000000000000 *pde =3D f000eef3f000ee00
Oops: 0000 [#1] SMP
last sysfs file:
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.39-rc5-00164-g797390d #1 To Be Filled By O.E.M. To Be Filled By O.E.M./E350M1
EIP: 0060:[<c1aa13ce>] EFLAGS: 00010012 CPU: 0
EIP is at memmap_init_zone+0x6c/0xf2
EAX: 00000000 EBX: 000a8000 ECX: 000a7fff EDX: f2c00b80
ESI: 000a8000 EDI: f2c00800 EBP: c19ffe54 ESP: c19ffe34
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=3Dc19fe000 task=3Dc1a07f60 task.ti=3Dc19fe000)
Stack:
00000002 00000000 0023f000 00000000 10000000 00000a00 f2c00000 f2c00b58
c19ffeb0 c1a80f24 000375fe 00000000 f2c00800 00000800 00000100 00000030
c1abb768 0000003c 00000000 00000000 00000004 00207a02 f2c00800 000375fe
Call Trace:
[<c1a80f24>] free_area_init_node+0x358/0x385
[<c1a81384>] free_area_init_nodes+0x420/0x487
[<c1a79326>] paging_init+0x114/0x11b
[<c1a6cb13>] setup_arch+0xb37/0xc0a
[<c1a69554>] start_kernel+0x76/0x316
[<c1a690a8>] i386_start_kernel+0xa8/0xb0
This patch fixes the bug by defining early_pfn_valid() to be the
same as pfn_valid() when DISCONTIGMEM.
Reported-bisected-and-tested-by: Conny Seidel <conny.seidel@amd.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: hans.rosenfeld@amd.com
Cc: Christoph Lameter <cl@linux.com>
Cc: Conny Seidel <conny.seidel@amd.com>
Link: http://lkml.kernel.org/r/20110628094107.GB3386@htj.dyndns.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
|
|
Commit c8b28116 ("sched: Increase SCHED_LOAD_SCALE resolution")
intended to have no user-visible effect, but allows setting
cpu.shares to < MIN_SHARES, which the user then sees.
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Nikhil Rao <ncrao@google.com>
Link: http://lkml.kernel.org/r/1307192600.8618.3.camel@marge.simson.net
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
When failing to start the camera we should disable the queue again, to
rollback into the same initial state. Otherwise re-trying will always
hit -EBUSY
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
When freeing memory for the video buffers also remove them from the
irq & main queues.
This fixes an oops when doing the following:
open ("/dev/video", ..)
VIDIOC_REQBUFS
VIDIOC_QBUF
VIDIOC_REQBUFS
close ()
As the second VIDIOC_REQBUFS will cause the list entries of the buffers
to be cleared while they still hang around on the main and irc queues
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
If a streaming interface has no supported format, the driver won't
create a video device for the associated terminal. Fix an oops by
ignoring that terminal when creating links between entities.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Entities associated with video device nodes are unregistered in
video_unregister_device(). This destroys the entity even though it can
still be accessed through open video device nodes.
Move the media_device_unregister_entity() call from
video_unregister_device() to v4l2_device_release() to ensure that the
entity isn't unregistered until the last reference to the video device
is released.
Also remove the media_entity_get()/put() calls from v4l2-dev.c. Those
functions were designed for subdevs, to avoid a parent module from being
removed while still accessible through board code. They're not currently
needed for video device nodes, and will oops when a hotpluggable device
is disconnected during streaming, as media_entity_put() called in
v4l2_device_release() tries to access entity->parent->dev->driver which
is set to NULL when the device is disconnected.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Fix a potential NULL pointer dereference by skipping registration of
external entities in case none are provided.
This is useful at least when testing mere memory-to-memory scenarios.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
__vb2_queue_alloc function returns the number of successfully allocated
buffers. There is no point in checking if the returned value is negative.
If this function returns 0, videobuf2 should just return -ENOMEM to
userspace, because no driver can work without memory buffers.
Reported-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
queued_count variable was left untouched during the queue reinitialization
in __vb2_queue_cancel, what might lead to mismatch between the real number
of queued buffers and queued_count variable.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This reverts commit 31901a078af29c33c736dcbf815656920e904632.
Queue should be reinitialized on each REQBUFS() call even if the memory
access method and buffer count have not been changed. The user might have
changed the format and if we go the short path introduced in that commit,
the memory buffer will not be reallocated to fit with new format.
The previous patch was just over-engineered optimization, which just
introduced a bug to videobuf2.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Add __GFP_NOWARN parameter to videobuf2 dma-sg allocator to prevent
kernel warning and stack dump if there is not enough memory available.
Videobuf2 and drivers should correctly handle no memory case, so there
is no need for stack dump and extensive log.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
David Brownell's CREDITS entry should have N: (name) instead of
M: (email).
Signed-off-by: Henrik Ahlgren <pablo@seestieto.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
CE variant requires a different chremap setup.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=35472
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
If the remote device is not present, the connections attemp fails and
the struct hci_conn was not freed
Signed-off-by: Tomas Targownik <ttargownik@geicp.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
PTS test A2DP/SRC/SRC_SET/TC_SRC_SET_BV_02_I revealed that
( probably after the df3c3931e commit ) the l2cap connection
could not be established in case when the "Auth Complete" HCI
event does not arive before the initiator send "Configuration
request", in which case l2cap replies with "Command rejected"
since the channel is still in BT_CONNECT2 state.
Based on patch from: Ilia Kolomisnky <iliak@ti.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
Partial revert of commit aabf6f89. When the hidp session thread
was converted from kernel_thread to kthread, the atomic/wakeups
were replaced with kthread_stop. kthread_stop has blocking semantics
which are inappropriate for the hidp session kthread. In addition,
the kthread signals itself to terminate in hidp_process_hid_control()
- it cannot do this with kthread_stop().
Lastly, a wakeup can be lost if the wakeup happens between checking
for the loop exit condition and setting the current state to
TASK_INTERRUPTIBLE. (Without appropriate synchronization mechanisms,
the task state should not be changed between the condition test and
the yield - via schedule() - as this creates a race between the
wakeup and resetting the state back to interruptible.)
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (24 commits)
usbnet: Remove over-broad module alias from zaurus.
MAINTAINERS: drop Michael from bfin_mac driver
net/can: activate bit-timing calculation and netlink based drivers by default
rionet: fix NULL pointer dereference in rionet_remove
net+crypto: Use vmalloc for zlib inflate buffers.
netfilter: Fix ip_route_me_harder triggering ip_rt_bug
ipv4: Fix IPsec slowpath fragmentation problem
ipv4: Fix packet size calculation in __ip_append_data
cxgb3: skb_record_rx_queue now records the queue index relative to the net_device.
bridge: Only flood unregistered groups to routers
qlge: Add maintainer.
MAINTAINERS: mark socketcan-core lists as subscribers-only
MAINTAINERS: Remove Sven Eckelmann from BATMAN ADVANCED
r8169: fix wrong register use.
net/usb/kalmia: signedness bug in kalmia_bind()
net/usb: kalmia: Various fixes for better support of non-x86 architectures.
rtl8192cu: Fix missing firmware load
udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet
ipv6/udp: Use the correct variable to determine non-blocking condition
netconsole: fix build when CONFIG_NETCONSOLE_DYNAMIC is turned on
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/avr32-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/avr32-2.6:
MAINTAINERS: update AVR32 and AT32AP maintainers
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
watchdog: update author email for at32ap700x_wdt
watchdog: gef_wdt: fix MODULE_ALIAS
watchdog: Intel SCU Watchdog: Fix build and remove duplicate code
watchdog: mtx1-wdt: fix section mismatch
watchdog: mtx1-wdt: fix GPIO toggling
watchdog: mtx1-wdt: request gpio before using it
watchdog: Handle multiple wm831x watchdogs being registered
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x
* 'sh-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x:
sh: use printk_ratelimited instead of printk_ratelimit
sh: Fix up unmet dependency warnings with USB EHCI/OHCI selects.
sh: fix the value of sh_dmae_slave_config in setup-sh7757
sh: fix the INTC vector for IRQ and IRL in setup-sh7757
sh: add to select the new configuration for USB EHCI/OHCI
sh: add platform_device of EHCI/OHCI to setup-sh7757
sh: fix compile error using sh7757lcr_defconfig
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x
* 'rmobile-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x:
ARM: mach-shmobile: make a struct in board-ap4evb.c static
ARM: mach-shmobile: ag5evm: consistently name sdhi info structures
ARM: mach-shmobile: mackerel: change usbhs devices order
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 into for-davem
|
|
In the past we would use the GSI value to preset the ACPI SCI
IRQ which worked great as GSI == IRQ:
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
While that is most often seen, there are some oddities:
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
which means that GSI 20 (or pin 20) is to be overriden for IRQ 9.
Our code that presets the interrupt for ACPI SCI however would
use the GSI 20 instead of IRQ 9 ending up with:
xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=20
xen: acpi sci 20
.. snip..
calling acpi_init+0x0/0xbc @ 1
ACPI: SCI (IRQ9) allocation failed
ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20110413/evevent-119)
ACPI: Unable to start the ACPI Interpreter
as the ACPI interpreter made a call to 'acpi_gsi_to_irq' which got nine.
It used that value to request an IRQ (request_irq) and since that was not
present it failed.
The fix is to recognize that for interrupts that are overriden (in our
case we only care about the ACPI SCI) we should use the IRQ number
to present the IRQ instead of the using GSI. End result is that we get:
xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=9 (gsi=9)
xen: acpi sci 9
which fixes the ACPI interpreter failing on startup.
CC: stable@kernel.org
Reported-by: Liwei <xieliwei@gmail.com>
Tested-by: Liwei <xieliwei@gmail.com>
[http://lists.xensource.com/archives/html/xen-devel/2011-06/msg01727.html]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
|
One of ioctl definition in sound/sb16_csp.h contains the data size
over 8kB, and this causes build errors on architectures like MIPS,
which define _IOC_SIZEBITS=13.
For avoiding this build errors but keeping the compatibility, manually
expand with _IOC() instead of using _IOW() for the problematic ioctl.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Simple enough - we use an extern defined symbol which is not
defined when CONFIG_SMP is not defined. This fixes the linker
dying.
CC: stable@kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
|
There is a misprint in resource deallocation code on error path in
hfsplus_fill_super(): the sbi->alloc_file inode is iput twice,
while the root inode in not iput at all.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
hfsplus leaks bio objects by failing to call bio_put() on the bios
it allocates. Add the missing call to fix the leak.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Cc: <stable@kernel.org> # .38.x, .39.x
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
The char can be unsigned on some architectures. Since the code checks
the negative values, they should be declared as signed char explicitly.
sound/pci/rme9652/hdspm.c:5449: warning: comparison is always false due to limited range of data type
sound/pci/rme9652/hdspm.c:5462: warning: comparison is always false due to limited range of data type
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fix the wrongly converted short values:
sound/pci/cs5535audio/cs5535audio_pcm.c:152: warning: large integer implicitly truncated to unsigned type
sound/pci/cs5535audio/cs5535audio_pcm.c:160: warning: large integer implicitly truncated to unsigned type
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
for-linus
|
|
We used to write these with BIO_RW_BARRIER aka REQ_HARDBARRIER (unless
disabled in the configuration). The correct semantic now would be to
write with FLUSH/FUA.
For example, with activity log transactions, FUA alone is not enough, we
need the corresponding bitmap update (and all related application
updates) on stable storage as well.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
|
|
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
|
|
data socket
If we have an asymetrically congested network, we may send P_PING,
but due to congestion, the corresponding P_PING_ACK would time out,
and we would drop a (congested, but otherwise) healthy connection
("PingAck did not arrive in time.")
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
|
|
If we have a good resync rate, we will frequently update the on-disk
bitmap, which, if not accounted for as resync io, may let an otherwise
idle device appear to be "busy", and cause us to throttle resync.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
|
|
The last commit, drbd: add missing spinlock to bitmap receive,
introduced a cond_resched_lock(), where the lock in question is taken
with irqs disabled.
As we must not schedule with IRQs disabled,
and cond_resched_lock_irq() does not exist, yet,
we re-aquire the spin_lock_irq() for each bitmap page processed in turn.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
|
|
During bitmap exchange, when using the RLE bitmap compression scheme,
we have a code path that can set the whole bitmap at once.
To avoid holding spin_lock_irq() for too long, we used to lock out other
bitmap modifications during bitmap exchange by other means, and then,
knowing we have exclusive access to the bitmap, modify it without
the spinlock, and with IRQs enabled.
Since we now allow local IO to continue, potentially setting additional
bits during the bitmap receive phase, this is no longer true, and we get
uncoordinated updates of bitmap members, causing bm_set to no longer
accurately reflect the total number of set bits.
To actually see this, you'd need to have a large bitmap, use RLE bitmap
compression, and have busy IO during sync handshake and bitmap exchange.
Fix this by taking the spin_lock_irq() in this code path as well, but
calling cond_resched_lock() after each page worth of bits processed.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
|
