This is a compromise and a temporary workaround for bootup NMI
watchdog triggers some people see with qla2xxx devices present.
This happens when, for example:
CPU 0 is in the driver init and looping submitting mailbox commands to
load the firmware, then waiting for completion.
CPU 1 is receiving the device interrupts. CPU 1 is where the NMI
watchdog triggers.
CPU 0 is submitting mailbox commands fast enough that by the time CPU
1 returns from the device interrupt handler, a new one is pending.
This sequence runs for more than 5 seconds.
The problematic case is CPU 1's timer interrupt running when the
barrage of device interrupts begin. Then we have:
timer interrupt
return for softirq checking
pending, thus enable interrupts
qla2xxx interrupt
return
qla2xxx interrupt
return
... 5+ seconds pass
final qla2xxx interrupt for fw load
return
run timer softirq
return
At some point in the multi-second qla2xxx interrupt storm we trigger
the NMI watchdog on CPU 1 from the NMI interrupt handler.
The timer softirq, once we get back to running it, is smart enough to
run the timer work enough times to make up for the missed timer
interrupts.
However, the NMI watchdogs (both x86 and sparc) use the timer
interrupt count to notice the cpu is wedged. But in the above
scenerio we'll receive only one such timer interrupt even if we last
all the way back to running the timer softirq.
The default watchdog trigger point is only 5 seconds, which is pretty
low (the softwatchdog triggers at 60 seconds). So increase it to 30
seconds for now.
Signed-off-by: David S. Miller <davem@davemloft.net>
I had the codes for L1 D-cache load accesses and misses swapped
around, and the wrong codes for LL-cache accesses and misses.
This corrects them.
Reported-by: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@kernel.org>
LKML-Reference: <19103.8514.709300.585484@cargo.ozlabs.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Three bytes of uninitialized kernel memory are currently leaked to user
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Reviewed-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The card model detection code introduced in 2.6.30 that tries to work
around partially broken EEPROM contents by reading the EEPROM directly
does not handle cards where the EEPROM has been omitted. In this case,
we have to use the default ID to allow the driver to load.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-and-tested-by: Ozan Çağlayan <ozan@pardus.org.tr>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Avoids potential issues if we read back unexpected values during
a read/modify/write cycle.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
New variant of IGDNG mobile chip has new host bridge id.
[anholt: Note that this new PCI ID doesn't impact the DRM, which doesn't
care about the PCI ID of the bridge]
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Remember to release the local reference if we fail to wait on
the rendering.
(Also whilst in the vicinity add some whitespace so that the phasing of
the operations is clearer.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Some i915/i945 platforms have a fairly high memory latency in certain
situations, so increase our constant a bit to avoid FIFO underruns.
The effect should be positive on other platforms as well; we'll have a
bit more insurance against a busy memory subsystem due to the extra
FIFO entries.
Fixes fdo bug #23368. Needed for 2.6.31.
Tested-by: Sven Arvidsson <sa@whiz.se>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
The 32-bit parameters (len and csum) of csum_ipv6_magic() are passed in 64-bit
registers in2 and in4. The high order 32 bits of the registers were never
cleared, and garbage was sometimes calculated into the checksum.
Fix this by clearing the high order 32 bits of these registers.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: Tony Luck <tony.luck@intel.com>
arch/ia64/kernel/dma-mapping.c:14: warning: control reaches end of non-void function
arch/ia64/kernel/dma-mapping.c:14: warning: no return statement in function returning non-void
This warning was introduced by commit: 390bd132b2
Add dma_debug_init() for ia64
Signed-off-by: Tony Luck <tony.luck@intel.com>
Added the quirk for Alienware M17x with IDT 92HD73* codec chip.
It has two HP and one line-out jack, one mic jack, a built-in
speaker and a built-in mic.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These are full of unresolved problems, mainly that conversions don't
work 1-1 from hrtimers to tasklet_hrtimers because unlike hrtimers
tasklets can't be killed from softirq context.
And when a qdisc gets reset, that's exactly what we need to do here.
We'll work this out in the net-next-2.6 tree and if warranted we'll
backport that work to -stable.
This reverts the following 3 changesets:
a2cb6a4dd4
("pkt_sched: Fix bogon in tasklet_hrtimer changes.")
38acce2d79
("pkt_sched: Convert CBQ to tasklet_hrtimer.")
ee5f9757ea
("pkt_sched: Convert qdisc_watchdog to tasklet_hrtimer")
Signed-off-by: David S. Miller <davem@davemloft.net>
After commit 2b85a34e91
(net: No more expensive sock_hold()/sock_put() on each tx)
sk_free() frees socks conditionally and depends
on sk_wmem_alloc being set e.g. in sock_init_data(). But in some
cases sk_free() is called earlier, usually after other alloc errors.
Fix is to move sk_wmem_alloc initialization from sock_init_data()
to sk_alloc() itself.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Due to the previous fix of input source for IDT92HD73xx, the amp mux
and amp vol stuff became unused. Let's rip off dead codes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix the mux_nids to select directly the input source instead of mux
mixers so that it works with the current mux enum handler for IDT
92HD73xx codecs.
Also, clean up useless / unnecessary mixer controls and init verbs.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix a small typo in the compat ioctl handler that cause the swapext
compat handler to never be called.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Tested-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Felix Blyakher <felixb@sgi.com>
Signed-off-by: Felix Blyakher <felixb@sgi.com>
The patch "block: Use accessor functions for queue limits"
(ae03bf639a) changed queue_max_sectors_store()
to use blk_queue_max_sectors() instead of directly assigning the value.
But blk_queue_max_sectors() differs a bit
1. It sets both max_sectors_kb, and max_hw_sectors_kb
2. Never allows one to change max_sectors_kb above BLK_DEF_MAX_SECTORS. If one
specifies a value greater then max_hw_sectors is set to that value but
max_sectors is set to BLK_DEF_MAX_SECTORS
I am not sure whether blk_queue_max_sectors() should be changed, as it seems
to be that way for a long time. And there may be callers dependent on that
behaviour.
This patch simply reverts to the older way of directly assigning the value to
max_sectors as it was before.
Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Commit 4bc5d34135 is broken and causes regressions:
(1) cpufreq_driver->resume() and ->suspend() were only called on
__powerpc__, but you could set them on all architectures. In fact,
->resume() was defined and used before the PPC-related commit
42d4dc3f4e complained about in 4bc5d34135.
(2) Therfore, the resume functions in acpi_cpufreq and speedstep-smi
would never be called.
(3) This means speedstep-smi would be unusuable after suspend or resume.
The _real_ problem was calling cpufreq_driver->get() with interrupts
off, but it re-enabling interrupts on some platforms. Why is ->get()
necessary?
Some systems like to change the CPU frequency behind our
back, especially during BIOS-intensive operations like suspend or
resume. If such systems also use a CPU frequency-dependant timing loop,
delays might be off by large factors. Therefore, we need to ascertain
as soon as possible that the CPU frequency is indeed at the speed we
think it is. You can do this two ways: either setting it anew, or trying
to get it. The latter is what was done, the former also has the same IRQ
issue.
So, let's try something different: defer the checking to after interrupts
are re-enabled, by calling cpufreq_update_policy() (via schedule_work()).
Timings may be off until this later stage, so let's watch out for
resume regressions caused by the deferred handling of frequency changes
behind the kernel's back.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Dave Jones <davej@redhat.com>
percpu incorrectly assumed that cpu0 was always there which led to the
following warning and eventual oops on sparc machines w/o cpu0.
WARNING: at mm/percpu.c:651 pcpu_map+0xdc/0x100()
Modules linked in:
Call Trace:
[000000000045eb70] warn_slowpath_common+0x50/0xa0
[000000000045ebdc] warn_slowpath_null+0x1c/0x40
[00000000004d493c] pcpu_map+0xdc/0x100
[00000000004d59a4] pcpu_alloc+0x3e4/0x4e0
[00000000004d5af8] __alloc_percpu+0x18/0x40
[00000000005b112c] __percpu_counter_init+0x4c/0xc0
...
Unable to handle kernel NULL pointer dereference
...
I7: <sysfs_new_dirent+0x30/0x120>
Disabling lock debugging due to kernel taint
Caller[000000000053c1b0]: sysfs_new_dirent+0x30/0x120
Caller[000000000053c7a4]: create_dir+0x24/0xc0
Caller[000000000053c870]: sysfs_create_dir+0x30/0x80
Caller[00000000005990e8]: kobject_add_internal+0xc8/0x200
...
Kernel panic - not syncing: Attempted to kill the idle task!
This patch fixes the problem by backporting parts from devel branch to
make percpu core not depend on the existence of cpu0.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Meelis Roos <mroos@linux.ee>
Cc: David Miller <davem@davemloft.net>
Bug was caught while trying to use WM8580 as I2S master on SMDK.
Symptoms were lesser LRCLK read by CRO(41.02 instead of 44.1 KHz) Solved
by referring to WM8580A manual and setting mask value correctly and
making the code to not touch 'reserved' bits of PLL4 register.
Signed-off-by: Jassi <jassi.brar@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
As discussed, the patch uses the original TDM order without rewriting.
For the match between TDM slot number and audio channel number, a new
API need be added.
Signed-off-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Unmute the docking-station line-out as default on machines with
AD1984A codec chip. It can be still muted via "Dock" mixer switch.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Do not forget to program the MCLK ratio for the I2S output.
Otherwise, the master clock frequency can be too high for
the DACs at sample frequencies above 96 kHz.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the recent change by Al Viro that changes verious subsystems
to use "struct path" one case was missed in the autofs4 module
which causes mounts to no longer expire.
Signed-off-by: Ian Kent <raven@themaw.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
My previous patch (commit 4f8ee2c9cc: "lmb: Remove __init from
lmb_end_of_DRAM()") removed __init in lmb.c but missed the fact that it
was also marked as such in the .h
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit log for commit 517d3cc15b
("[libata] ata_piix: Enable parallel scan") says:
This patch turns on parallel scanning for the ata_piix driver.
This driver is used on most netbooks (no AHCI for cheap storage it seems).
The scan is the dominating time factor in the kernel boot for these
devices; with this flag it gets cut in half for the device I used
for testing (eeepc).
Alan took a look at the driver source and concluded that it ought to be safe
to do for this driver. Alan has also checked with the hardware team.
and it is all true but once we put all things together additional
constraints for PATA controllers show up (some hardware registers
have per-host not per-port atomicity) and we risk misprogramming
the controller.
I used the following test to check whether the issue is real:
@@ -736,8 +736,20 @@ static void piix_set_piomode(struct ata_
(timings[pio][1] << 8);
}
pci_write_config_word(dev, master_port, master_data);
- if (is_slave)
+ if (is_slave) {
+ if (ap->port_no == 0) {
+ u8 tmp = slave_data;
+
+ while (slave_data == tmp) {
+ pci_read_config_byte(dev, slave_port, &tmp);
+ msleep(50);
+ }
+
+ dev_printk(KERN_ERR, &dev->dev, "PATA parallel scan "
+ "race detected\n");
+ }
pci_write_config_byte(dev, slave_port, slave_data);
+ }
/* Ensure the UDMA bit is off - it will be turned back on if
UDMA is selected */
and it indeed triggered the error message.
Lets fix all such races by adding an extra locking to ->set_piomode
and ->set_dmamode methods for PATA controllers.
[ Alan: would be better to take the host lock in libata-core for these
cases so that we fix all the adapters in one swoop. "Looks fine as a
temproary quickfix tho" ]
Cc: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
drm/i915: Improve CRTDDC mapping by using VBT info
drm/i915: Fix CPU-spinning hangs related to fence usage by using an LRU.
drm/i915: Set crtc/clone mask in different output devices
drm/i915: Always use SDVO_B detect bit for SDVO output detection.
drm/i915: Fix typo that broke SVID1 in intel_sdvo_multifunc_encoder()
drm/i915: Check if BIOS enabled dual-channel LVDS on 8xx, not only on 9xx
drm/i915: Set the multiplier for SDVO on G33 platform
Allocation may fail, show if it did.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
[Additional fix for invalid runtime->oss.prepare flag set by tiwai]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the support of automatic mute and mic-switching of the docking
station HP and mic plugs for AD1984A laptop model for some HP machines.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix the headphone pin routing of ALC268/ALC269 codecs. Using alc882
routine doesn't work because alc268/alc269 parser assumes the
independent DACs for both HP and speaker outputs. Need to assign the
DAC depending on the pin.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch fixes the wrong headphone output routing for MacBookPro 3,1/4,1
quirk with ALC889A codec, which caused the silent headphone output.
Also, this gives the individual Headphone and Speaker volume controls.
Reference: kernel bug#14078
http://bugzilla.kernel.org/show_bug.cgi?id=14078
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: <stable@kernel.org>
In patch_vt1708(), the check of MUX nids is missing and this results in
the -EINVAL error in accessing Input Source mixer element. Simpliy
adding the call of get_mux_nids() fixes the problem.
Reference: Novell bnc#534904
https://bugzilla.novell.com/show_bug.cgi?id=534904
Signed-off-by: Takashi Iwai <tiwai@suse.de>
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We should call em28xx_ir_init(dev) only when disable_ir is true.
Signed-off-by: Shine Liu <shinel@foxmail.com>
Reviewed-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The order of indexes is reversed
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Antoine Jacquet <royale@zerezo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[mchehab@redhat.com: fix merge conflict and a few CodingStyle issues]
Signed-off-by: Steve Gotthardt <gotthardt@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Previous changesets broke Hauppauge devices and their GPIO configurations.
This changeset restores the LED & LNA functionality.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
