- 01 Apr, 2010 9 commits
-
-
Daniel T Chen authored
BugLink: https://bugs.launchpad.net/bugs/538918 The OR has verified that explicitly enabling MSI is necessary for audio to be audible by default. This patch is only applicable to 2.6.32.y; in 2.6.33, MSI is enabled by default. Reported-by:
Sam Townsend <stownsend42@sbcglobal.net> Tested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Takashi Iwai authored
commit 5311114d upstream. Since alc_auto_create_input_ctls() doesn't set the elements for the secondary ADCs, "Input Source" elemtns for these also get empty, resulting in buggy outputs of alsactl like: control.14 { comment.access 'read write' comment.type ENUMERATED comment.count 1 iface MIXER name 'Input Source' index 1 value 0 } This patch fixes alc_mux_enum_*() (and others) to fall back to the first entry if the secondary input mux is empty. Signed-off-by:
-
Matt Carlson authored
This is a resubmit backport of commit 92c6b8d1 to kernel version 2.6.32. The gentoo bug report can be found at https://bugs.gentoo.org/show_bug.cgi?id=301091. Thanks to Matt Carlson for his assistance and working me to fix a regression caused by the initial patch. The original description is as follows: The 5906 has trouble with fragments that are less than 8 bytes in size. This patch works around the problem by pivoting the 5906's transmit routine to tg3_start_xmit_dma_bug() and introducing a new SHORT_DMA_BUG flag that enables code to detect and react to the problematic condition. Signed-off-by:
Mike Pagano <mpagano@gentoo.org> Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Louis Rilling authored
commit fe234f0e upstream. Commit 09943a18 Author: Matt Carlson <mcarlson@broadcom.com> Date: Fri Aug 28 14:01:57 2009 +0000 tg3: Convert ISR parameter to tnapi forgot to update tg3_poll_controller(), leading to intermittent crashes with netpoll. Fix this. Signed-off-by:
Louis Rilling <louis.rilling@kerlabs.com> Signed-off-by:
-
David Daney authored
commit abbdc3d8 upstream. commit c8af165342e83a4eb078c9607d29a7c399d30a53 (lmo) rsp. e0cc87f5 (kernel.org) left label_module_alloc unused. Remove it now. Signed-off-by:
David Daney <ddaney@caviumnetworks.com> Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/752/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Russell King authored
commit 98e12b5a upstream. Commit 2552fc27 changed the way the decompressor decides if it is safe to decompress the kernel directly to its final location. Unfortunately, it took the top of the compressed data as being the stack pointer, which it is for ROM=n cases. However, for ROM=y, the stack pointer is not relevant, and results in the wrong answer. Fix this by explicitly storing the end of the biggybacked data in the decompressor, and use that to calculate the compressed image size. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
commit 5ceaa2f3 upstream. The ARM kernel decompressor wants to be able to relocate r/w data independently from the rest of the image, and we do this by ensuring that r/w data has global visibility. Define STATIC_RW_DATA to be empty to achieve this. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Julia Lawall authored
commit 9b3a6549 upstream. The few lines below the kfree of hdr_buf may go to the label err_free which will also free hdr_buf. The most straightforward solution seems to be to just move the kfree of hdr_buf after these gotos. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ identifier E; expression E1; iterator I; statement S; @@ *kfree(E); ... when != E = E1 when != I(E,...) S when != &E *kfree(E); // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Shaohua Li authored
commit 29874f44 upstream. if no VBT is present, crt_ddc_bus will be left at 0, and cause us to use that for the GPIO register offset. That's never a valid register offset, so let the "undefined" value be 0 instead of -1. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> [anholt: clarified the commit message a bit] Signed-off-by:
-
- 15 Mar, 2010 31 commits
-
-
Greg Kroah-Hartman authored
-
Ian Campbell authored
commit 14315592 upstream. Distros generally (I looked at Debian, RHEL5 and SLES11) seem to enable CONFIG_HIGHPTE for any x86 configuration which has highmem enabled. This means that the overhead applies even to machines which have a fairly modest amount of high memory and which therefore do not really benefit from allocating PTEs in high memory but still pay the price of the additional mapping operations. Running kernbench on a 4G box I found that with CONFIG_HIGHPTE=y but no actual highptes being allocated there was a reduction in system time used from 59.737s to 55.9s. With CONFIG_HIGHPTE=y and highmem PTEs being allocated: Average Optimal load -j 4 Run (std deviation): Elapsed Time 175.396 (0.238914) User Time 515.983 (5.85019) System Time 59.737 (1.26727) Percent CPU 263.8 (71.6796) Context Switches 39989.7 (4672.64) Sleeps 42617.7 (246.307) With CONFIG_HIGHPTE=y but with no highmem PTEs being allocated: Average Optimal load -j 4 Run (std deviation): Elapsed Time 174.278 (0.831968) User Time 515.659 (6.07012) System Time 55.9 (1.07799) Percent CPU 263.8 (71.266) Context Switches 39929.6 (4485.13) Sleeps 42583.7 (373.039) This patch allows the user to control the allocation of PTEs in highmem from the command line ("userpte=nohigh") but retains the status-quo as the default. It is possible that some simple heuristic could be developed which allows auto-tuning of this option however I don't have a sufficiently large machine available to me to perform any particularly meaningful experiments. We could probably handwave up an argument for a threshold at 16G of total RAM. Assuming 768M of lowmem we have 196608 potential lowmem PTE pages. Each page can map 2M of RAM in a PAE-enabled configuration, meaning a maximum of 384G of RAM could potentially be mapped using lowmem PTEs. Even allowing generous factor of 10 to account for other required lowmem allocations, generous slop to account for page sharing (which reduces the total amount of RAM mappable by a given number of PT pages) and other innacuracies in the estimations it would seem that even a 32G machine would not have a particularly pressing need for highmem PTEs. I think 32G could be considered to be at the upper bound of what might be sensible on a 32 bit machine (although I think in practice 64G is still supported). It's seems questionable if HIGHPTE is even a win for any amount of RAM you would sensibly run a 32 bit kernel on rather than going 64 bit. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> LKML-Reference: <1266403090-20162-1-git-send-email-ian.campbell@citrix.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Thomas Gleixner authored
commit 83ab0aa0 upstream. setscheduler() saves task->sched_class outside of the rq->lock held region for a check after the setscheduler changes have become effective. That might result in checking a stale value. rtmutex_setprio() has the same problem, though it is protected by p->pi_lock against setscheduler(), but for correctness sake (and to avoid bad examples) it needs to be fixed as well. Retrieve task->sched_class inside of the rq->lock held region. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Suresh Siddha authored
commit 9000f05c upstream. Fix a SMT scheduler performance regression that is leading to a scenario where SMT threads in one core are completely idle while both the SMT threads in another core (on the same socket) are busy. This is caused by this commit (with the problematic code highlighted) commit bdb94aa5 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> Date: Tue Sep 1 10:34:38 2009 +0200 sched: Try to deal with low capacity @@ -4203,15 +4223,18 @@ find_busiest_queue() ... for_each_cpu(i, sched_group_cpus(group)) { + unsigned long power = power_of(i); ... - wl = weighted_cpuload(i); + wl = weighted_cpuload(i) * SCHED_LOAD_SCALE; + wl /= power; - if (rq->nr_running == 1 && wl > imbalance) + if (capacity && rq->nr_running == 1 && wl > imbalance) continue; On a SMT system, power of the HT logical cpu will be 589 and the scheduler load imbalance (for scenarios like the one mentioned above) can be approximately 1024 (SCHED_LOAD_SCALE). The above change of scaling the weighted load with the power will result in "wl > imbalance" and ultimately resulting in find_busiest_queue() return NULL, causing load_balance() to think that the load is well balanced. But infact one of the tasks can be moved to the idle core for optimal performance. We don't need to use the weighted load (wl) scaled by the cpu power to compare with imabalance. In that condition, we already know there is only a single task "rq->nr_running == 1" and the comparison between imbalance, wl is to make sure that we select the correct priority thread which matches imbalance. So we really need to compare the imabalnce with the original weighted load of the cpu and not the scaled load. But in other conditions where we want the most hammered(busiest) cpu, we can use scaled load to ensure that we consider the cpu power in addition to the actual load on that cpu, so that we can move the load away from the guy that is getting most hammered with respect to the actual capacity, as compared with the rest of the cpu's in that busiest group. Fix it. Reported-by:
Ma Ling <ling.ma@intel.com> Initial-Analysis-by:
Zhang, Yanmin <yanmin_zhang@linux.intel.com> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1266023662.2808.118.camel@sbs-t61.sc.intel.com> Signed-off-by:
-
Vaidyanathan Srinivasan authored
commit 28f53181 upstream. Fix for sched_mc_powersavigs for pre-Nehalem platforms. Child sched domain should clear SD_PREFER_SIBLING if parent will have SD_POWERSAVINGS_BALANCE because they are contradicting. Sets the flags correctly based on sched_mc_power_savings. Signed-off-by:
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by:
-
Gleb Natapov authored
commit e92805ac upstream. Add CPL checking in case emulator is tricked into emulating privilege instruction from userspace. Signed-off-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
Gleb Natapov authored
commit 60a29d4e upstream. Use groups mechanism to decode 0F C7 instructions. Signed-off-by:
-
Gleb Natapov authored
commit 8b9f4414 upstream. Inject #UD if guest attempts to do so. This is in accordance to Intel SDM. Signed-off-by:
-
Gleb Natapov authored
commit 2db2c2eb upstream. Use groups mechanism to decode 0F BA instructions. Signed-off-by:
-
Mikulas Patocka authored
commit a97f925a upstream. Free the dm_io structure before calling bio_endio() instead of after it, to ensure that the io_pool containing it is not referenced after it is freed. This partially fixes a problem described here https://www.redhat.com/archives/dm-devel/2010-February/msg00109.html thread 1: bio_endio(bio, io_error); /* scheduling happens */ thread 2: close the device remove the device thread 1: free_io(md, io); Thread 2, when removing the device, sees non-empty md->io_pool (because the io hasn't been freed by thread 1 yet) and may crash with BUG in mempool_free. Thread 1 may also crash, when freeing into a nonexisting mempool. To fix this we must make sure that bio_endio() is the last call and the md structure is not accessed afterwards. There is another bio_endio in process_barrier, but it is called from the thread and the thread is destroyed prior to freeing the mempools, so this call is not affected by the bug. A similar bug exists with module unloads - the module may be unloaded immediately after bio_endio - but that is more difficult to fix. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Trond Myklebust authored
commit ebed9203 upstream. sunrpc_cache_update() will always call detail->update() from inside the detail->hash_lock, so it cannot allocate memory. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
James Hogan authored
commit 5a98c04d upstream. The else part of the if statement is indented but does not have braces around it. It clearly should since it uses clk_enable and clk_disable which are supposed to balance. Signed-off-by:
James Hogan <james@albanarts.com> Acked-by:
Linus Walleij <linus.walleij@stericsson.com> Acked-by:
Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Lars-Peter Clausen authored
commit dc2ed552 upstream. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Cc: Ben Dooks <ben-linux@fluff.org> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Trond Myklebust authored
commit 9fcfe0c8 upstream. This can, for instance, happen if the user specifies a link local IPv6 address. Signed-off-by:
-
Neil Brown authored
commit ab1b18f7 upstream. The 'struct svc_deferred_req's on the xpt_deferred queue do not own a reference to the owning xprt. This is seen in svc_revisit which is where things are added to this queue. dr->xprt is set to NULL and the reference to the xprt it put. So when this list is cleaned up in svc_delete_xprt, we mustn't put the reference. Also, replace the 'for' with a 'while' which is arguably simpler and more likely to compile efficiently. Cc: Tom Tucker <tom@opengridcomputing.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Maarten Maathuis authored
commit 290e5505 upstream. - Without this change I get a general protection fault. - Also use PTR_ERR where applicable. Signed-off-by:
Maarten Maathuis <madman2003@gmail.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
Zhao Yakui authored
commit 6070a4a9 upstream. This IBM system has a multi-function SDVO card that reports both VGA and TV, but the system has no TV connector. The TV connector always reported as connected, which would lead to poor modesetting choices. https://bugs.freedesktop.org/show_bug.cgi?id=25787Signed-off-by:
Vance <liangghv@sg.ibm.com> Signed-off-by:
-
Jan Dumon authored
commit 46216e4f upstream. Enable the SD-Card interface on multiple Option 3G sticks. The unusual_devs.h entry is necessary because the device descriptor is vendor-specific. That prevents usb-storage from binding to it as an interface driver. Signed-off-by:
Jan Dumon <j.dumon@option.com> Signed-off-by:
Phil Dibowitz <phil@ipom.com> Signed-off-by:
-
Alan Cox authored
commit bd07c551 upstream. As reported in http://bugzilla.kernel.org/show_bug.cgi?id=10980Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Daniel Sangorrin authored
commit 46b72d78 upstream. This is a patch to ftdi_sio_ids.h and ftdi_sio.c that adds identifiers for CONTEC USB serial converter. I tested it with the device COM-1(USB)H Signed-off-by:
Daniel Sangorrin <daniel.sangorrin@gmail.com> Cc: Andreas Mohr <andi@lisas.de> Signed-off-by:
-
Mitchell Solomon authored
commit 9714080d upstream. PID patch for my products Signed-off-by:
Mitchell Solomon <mitchjs@rush2112.net> Signed-off-by:
-
Andreas Mohr authored
commit 65e1ec67 upstream. - add FTDI device IDs for several ELV devices and NXTCam of Lego Mindstorms NXT - add hopefully helpful new_id comment - remove less helpful "Due to many user requests for multiple ELV devices we enable them by default." comment (we simply add _all_ known devices - an enduser shouldn't have to fiddle with obscure module parameters...). - add myself to DRIVER_AUTHOR The missing NXTCam ID has been found at http://www.unixboard.de/vb3/showthread.php?t=44155 , ELV devices taken from ELV Windows .inf file. Signed-off-by:
Andreas Mohr <andi@lisas.de> Signed-off-by:
-
Radek Liboska authored
commit a7787e50 upstream. added new device pid (PAPOUCH_AD4USB_PID) to ftdi_sio.h and ftdi_sio.c AD4USB measuring converter is a 4-input A/D converter which enables the user to measure to four current inputs ranging from 0(4) to 20 mA or voltage between 0 and 10 V. The measured values are then transferred to a superior system in digital form. The AD4USB communicates via USB. Powered is also via USB. datasheet in english is here: http://www.papouch.com/shop/scripts/pdf/ad4usb_en.pdfSigned-off-by:
Radek Liboska <liboska@uochb.cas.cz> Signed-off-by:
-
Andreas Mohr authored
commit 4e092d11 upstream. This is a (almost) sort-only patch to sort FTDI device product ID definitions in new ftdi_sio_ids.h header. Advantage is that new device ID submissions will now have a specific (sorted) position - less future merge conflicts. Compile-tested, based on _current_ mainline git. Minor checkpatch.pl warnings were eliminated whereever it made sense, very minor text changes. Signed-off-by:
-
Andreas Mohr authored
commit 31844d55 upstream. This is a strictly move-only patch to relocate all FTDI device product ID definitions to their own ftdi_sio_ids.h header (following the usual *_ids.h kernel tree convention, too), thus correcting the slightly too messy appearance (crucial driver defines were stuck somewhere in the decaying middle swamp of the huge existing header). Compile-tested, based on latest mainline git. Signed-off-by:
-
Herbert Xu authored
commit f7410ced upstream. USB: Move hcd free_dev call into usb_disconnect I found a way to oops the kernel: 1. Open a USB device through devio. 2. Remove the hcd module in the host kernel. 3. Close the devio file descriptor. The problem is that closing the file descriptor does usb_release_dev as it is the last reference. usb_release_dev then tries to invoke the hcd free_dev function (or rather dereferencing the hcd driver struct). This causes an oops as the hcd driver has already been unloaded so the struct is gone. This patch tries to fix this by bringing the free_dev call earlier and into usb_disconnect. I have verified that repeating the above steps no longer crashes with this patch applied. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Alan Stern authored
commit cceffe93 upstream. This patch (as1332) removes an unneeded and annoying debugging message announcing all USB uevent constructions. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Pete Zaitcev authored
commit d23356da upstream. When hardware is removed on a Stratus, the system may crash like this: ACPI: PCI interrupt for device 0000:7c:00.1 disabled Trying to free nonexistent resource <00000000a8000000-00000000afffffff> Trying to free nonexistent resource <00000000a4800000-00000000a480ffff> uhci_hcd 0000:7e:1d.0: remove, state 1 usb usb2: USB disconnect, address 1 usb 2-1: USB disconnect, address 2 Unable to handle kernel paging request at 0000000000100100 RIP: [<ffffffff88021950>] :uhci_hcd:uhci_scan_schedule+0xa2/0x89c #4 [ffff81011de17e50] uhci_scan_schedule at ffffffff88021918 #5 [ffff81011de17ed0] uhci_irq at ffffffff88023cb8 #6 [ffff81011de17f10] usb_hcd_irq at ffffffff801f1c1f #7 [ffff81011de17f20] handle_IRQ_event at ffffffff8001123b #8 [ffff81011de17f50] __do_IRQ at ffffffff800ba749 This occurs because an interrupt scans uhci->skelqh, which is being freed. We do the right thing: disable the interrupts in the device, and do not do any processing if the interrupt is shared with other source, but it's possible that another CPU gets delayed somewhere (e.g. loops) until we started freeing. The agreed-upon solution is to wait for interrupts to play out before proceeding. No other bareers are neceesary. A backport of this patch was tested on a 2.6.18 based kernel. Testing of 2.6.32-based kernels is under way, but it takes us forever (months) to turn this around. So I think it's a good patch and we should keep it. Tracked in RH bz#516851 Signed-Off-By:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Alan Stern authored
commit cd780694 upstream. This patch (as1346) changes the idProduct value for USB-3.0 root hubs from 0x0002 (which we already use for USB-2.0 root hubs) to 0x0003. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Edward Shao authored
commit 05197921 upstream. According "5.3.6 Capability Parameters (HCCPARAMS)" of xHCI rev0.96 spec, value of xECP register indicates a relative offset, in 32-bit words, from Base to the beginning of the first extended capability. The wrong calculation will cause BIOS handoff fail (not handoff from BIOS) in some platform with BIOS USB legacy sup support. Signed-off-by:
Edward Shao <laface.tw@gmail.com> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Yinghai Lu authored
commit 18dce6ba upstream. Thomas Renninger <trenn@suse.de> reported on IBM x3330 booting a latest kernel on this machine results in: PCI: PCI BIOS revision 2.10 entry at 0xfd61c, last bus=1 PCI: Using configuration type 1 for base access bio: create slab <bio-0> at 0 ACPI: SCI (IRQ30) allocation failed ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20090903/evevent-161) ACPI: Unable to start the ACPI Interpreter Later all kind of devices fail... and bisect it down to this commit: commit b9c61b70 x86/pci: update pirq_enable_irq() to setup io apic routing it turns out we need to set irq routing for the sci on ioapic1 early. -v2: make it work without sparseirq too. -v3: fix checkpatch.pl warning, and cc to stable Reported-by:
Thomas Renninger <trenn@suse.de> Bisected-by:
Yinghai Lu <yinghai@kernel.org> LKML-Reference: <1265793639-15071-2-git-send-email-yinghai@kernel.org> Signed-off-by:
-
