- 21 Dec, 2011 1 commit
-
-
David Dillow authored
commit fc084e0b upstream. There are some AC97 codec and board combinations that have been observed to take a very long time to respond after the cold reset has completed. In one case, more than 350 ms was required. To allow users to have sound on those platforms, we'll wait up to 500ms for the codec to become ready. As a board may have multiple codecs, with some faster than others to reset, we add a module parameter to inform the driver which codecs should be present. Reported-by:
KotCzarny <tjosko@yahoo.com> Signed-off-by:
David Dillow <dave@thedillows.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
- 09 Dec, 2011 28 commits
-
-
Greg Kroah-Hartman authored
-
Thomas Gleixner authored
commit de28f25e upstream. If a device is shutdown, then there might be a pending interrupt, which will be processed after we reenable interrupts, which causes the original handler to be run. If the old handler is the (broadcast) periodic handler the shutdown state might hang the kernel completely. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Thomas Gleixner authored
commit c1be8430 upstream. When a better rated broadcast device is installed, then the current active device is not disabled, which results in two running broadcast devices. Signed-off-by:
-
Ido Yariv authored
commit 550acb19 upstream. In irq_wait_for_interrupt(), the should_stop member is verified before setting the task's state to TASK_INTERRUPTIBLE and calling schedule(). In case kthread_stop sets should_stop and wakes up the process after should_stop is checked by the irq thread but before the task's state is changed, the irq thread might never exit: kthread_stop irq_wait_for_interrupt ------------ ---------------------- ... ... while (!kthread_should_stop()) { kthread->should_stop = 1; wake_up_process(k); wait_for_completion(&kthread->exited); ... set_current_state(TASK_INTERRUPTIBLE); ... schedule(); } Fix this by checking if the thread should stop after modifying the task's state. [ tglx: Simplified it a bit ] Signed-off-by:
Ido Yariv <ido@wizery.com> Link: http://lkml.kernel.org/r/1322740508-22640-1-git-send-email-ido@wizery.comSigned-off-by:
-
Robert Richter authored
commit 97f7f818 upstream. If oprofile uses the nmi timer interrupt there is a crash while unloading the module. The bug can be triggered with oprofile build as module and kernel parameter nolapic set. This patch fixes this. oprofile: using NMI timer interrupt. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58 PGD 42dbca067 PUD 41da6a067 PMD 0 Oops: 0002 [#1] PREEMPT SMP CPU 5 Modules linked in: oprofile(-) [last unloaded: oprofile] Pid: 2518, comm: modprobe Not tainted 3.1.0-rc7-00019-gb2fb49d #19 Advanced Micro Device Anaheim/Anaheim RIP: 0010:[<ffffffff8123c226>] [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58 RSP: 0018:ffff88041ef71e98 EFLAGS: 00010296 RAX: 0000000000000000 RBX: ffffffffa0017100 RCX: dead000000200200 RDX: 0000000000000000 RSI: dead000000100100 RDI: ffffffff8178c620 RBP: ffff88041ef71ea8 R08: 0000000000000001 R09: 0000000000000082 R10: 0000000000000000 R11: ffff88041ef71de8 R12: 0000000000000080 R13: fffffffffffffff5 R14: 0000000000000001 R15: 0000000000610210 FS: 00007fc902f20700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000008 CR3: 000000041cdb6000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process modprobe (pid: 2518, threadinfo ffff88041ef70000, task ffff88041d348040) Stack: ffff88041ef71eb8 ffffffffa0017790 ffff88041ef71eb8 ffffffffa0013532 ffff88041ef71ec8 ffffffffa00132d6 ffff88041ef71ed8 ffffffffa00159b2 ffff88041ef71f78 ffffffff81073115 656c69666f72706f 0000000000610200 Call Trace: [<ffffffffa0013532>] op_nmi_exit+0x15/0x17 [oprofile] [<ffffffffa00132d6>] oprofile_arch_exit+0xe/0x10 [oprofile] [<ffffffffa00159b2>] oprofile_exit+0x1e/0x20 [oprofile] [<ffffffff81073115>] sys_delete_module+0x1c3/0x22f [<ffffffff811bf09e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8148070b>] system_call_fastpath+0x16/0x1b Code: 20 c6 78 81 e8 c5 cc 23 00 48 8b 13 48 8b 43 08 48 be 00 01 10 00 00 00 ad de 48 b9 00 02 20 00 00 00 ad de 48 c7 c7 20 c6 78 81 89 42 08 48 89 10 48 89 33 48 89 4b 08 e8 a6 c0 23 00 5a 5b RIP [<ffffffff8123c226>] unregister_syscore_ops+0x41/0x58 RSP <ffff88041ef71e98> CR2: 0000000000000008 ---[ end trace 43a541a52956b7b0 ]--- Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
-
Bjorn Helgaas authored
commit 9e686668 upstream. In commit f8924e77 ("x86: unify mp_bus_info"), the 32-bit and 64-bit versions of MP_bus_info were rearranged to match each other better. Unfortunately it introduced a regression: prior to that change we used to always set the mp_bus_not_pci bit, then clear it if we found a PCI bus. After it, we set mp_bus_not_pci for ISA buses, clear it for PCI buses, and leave it alone otherwise. In the cases of ISA and PCI, there's not much difference. But ISA is not the only non-PCI bus, so it's better to always set mp_bus_not_pci and clear it only for PCI. Without this change, Dan's Dell PowerEdge 4200 panics on boot with a log indicating interrupt routing trouble unless the "noapic" option is supplied. With this change, the machine boots reliably without "noapic". Fixes http://bugs.debian.org/586494Reported-bisected-and-tested-by:
Dan McGrath <troubledaemon@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: Dan McGrath <troubledaemon@gmail.com> Cc: Alexey Starikovskiy <aystarik@gmail.com> [jrnieder@gmail.com: clarified commit message] Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Link: http://lkml.kernel.org/r/20111122215000.GA9151@elie.hsd1.il.comcast.netSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Salman Qazi authored
commit 4cecf6d4 upstream. (Added the missing signed-off-by line) In hundreds of days, the __cycles_2_ns calculation in sched_clock has an overflow. cyc * per_cpu(cyc2ns, cpu) exceeds 64 bits, causing the final value to become zero. We can solve this without losing any precision. We can decompose TSC into quotient and remainder of division by the scale factor, and then use this to convert TSC into nanoseconds. Signed-off-by:
Salman Qazi <sqazi@google.com> Acked-by:
John Stultz <johnstul@us.ibm.com> Reviewed-by:
Paul Turner <pjt@google.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20111115221121.7262.88871.stgit@dungbeetle.mtv.corp.google.comSigned-off-by:
-
Suresh Jayaraman authored
The stable release 2.6.32.32 added the upstream commit 12fed00d. However, one of the hunks of the original patch seems missing from the stable backport which can be found here: http://permalink.gmane.org/gmane.linux.kernel.stable/5676 This hunk corresponds to the change in is_valid_oplock_break() at fs/cifs/misc.c. This patch backports the missing hunk and is against linux-2.6.32.y stable kernel. Cc: Steve French <sfrench@us.ibm.com> Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by:
Suresh Jayaraman <sjayaraman@suse.com> Signed-off-by:
-
Hannes Reinecke authored
commit 74571813 upstream. When we tear down a device we try to flush all outstanding commands in scsi_free_queue(). However the check in scsi_request_fn() is imperfect as it only signals that we _might start_ aborting commands, not that we've actually aborted some. So move the printk inside the scsi_kill_request function, this will also give us a hint about which commands are aborted. Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Jiri Slaby authored
commit 03b14708 upstream. Stanse found a potential NULL dereference in scsi_kill_request. Instead of triggering BUG() in 'if (unlikely(cmd == NULL))' branch, the kernel will Oops earlier on cmd dereference. Move the dereferences after the if. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Qinglin Ye authored
commit cec28a54 upstream. Kingston DT 101 G2 replies a wrong tag while transporting, add an unusal_devs entry to ignore the tag validation. Signed-off-by:
Qinglin Ye <yestyle@gmail.com> Signed-off-by:
-
Veli-Pekka Peltola authored
commit ec0cd94d upstream. Tested with SIM5218EVB-KIT evaluation kit. Signed-off-by:
Veli-Pekka Peltola <veli-pekka.peltola@bluegiga.com> Signed-off-by:
-
Marcin Kościelnicki authored
commit 307369b0 upstream. Signed-off-by:
Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by:
-
Dan Carpenter authored
commit 8746c83d upstream. qset->qh.link is an __le64 field and we should be using cpu_to_le64() to fill it. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Federico Vaga authored
commit 6a9ce6b6 upstream. After sleeping on a wait queue, signal_pending(current) should be checked (not before sleeping). Acked-by:
Alessandro Rubini <rubini@gnudd.com> Signed-off-by:
Federico Vaga <federico.vaga@gmail.com> Signed-off-by:
-
Bernd Porr authored
commit 3ffab428 upstream. This fixes kernel oops when an USB DAQ device is plugged out while it's communicating with the userspace software. Signed-off-by:
Bernd Porr <berndporr@f2s.com> Signed-off-by:
-
Bart Westgeest authored
commit 438957f8 upstream. Interrupts must be disabled prior to calling usb_hcd_unlink_urb_from_ep. If interrupts are not disabled, it can potentially lead to a deadlock. The deadlock is readily reproduceable on a slower (ARM based) device such as the TI Pandaboard. Signed-off-by:
Bart Westgeest <bart@elbrys.com> Signed-off-by:
-
Benjamin Poirier authored
This one liner is part of upstream commit 3701e513 Author: Jesse Gross <jesse@nicira.com> vlan: Centralize handling of hardware acceleration. The bulk of that commit is a rework of the hardware assisted vlan tagging driver interface, and as such doesn't classify for -stable inclusion. The fix that is needed is a part of that commit but can work independently of the rest. This patch can avoid panics on the 2.6.32.y -stable kernels and is in the same spirit as mainline commits 66c46d74 gro: Reset dev pointer on reuse 6d152e23 gro: reset skb_iif on reuse which are already in -stable. For drivers using the vlan_gro_frags() interface, a packet with an invalid tci leads to GRO_DROP and napi_reuse_skb(). The skb has to be sanitized before being reused or we may send an skb with an invalid vlan_tci field up the stack where it is not expected. Signed-off-by:
Benjamin Poirier <bpoirier@suse.de> Cc: Jesse Gross <jesse@nicira.com> Acked-by:
David S. Miller <davem@davemloft.net>
-
Eliad Peller authored
commit e007b857 upstream. MAC addresses have a fixed length. The current policy allows passing < ETH_ALEN bytes, which might result in reading beyond the buffer. Signed-off-by:
Eliad Peller <eliad@wizery.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Michael Büsch authored
commit 2d161817 upstream. priv->work must not be synced while priv->mutex is locked, because the mutex is taken in the work handler. Move cancel_work_sync down to after the device shutdown code. This is safe, because the work handler checks fw_state and bails out early in case of a race. Signed-off-by:
Michael Buesch <m@bues.ch> Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Michael Büsch authored
commit 32d3a392 upstream. The tx_lock is not initialized properly. Add spin_lock_init(). Signed-off-by:
-
Hector Palacios authored
commit d004e024 upstream. ktime_get and ktime_get_ts were calling timekeeping_get_ns() but later they were not calling arch_gettimeoffset() so architectures using this mechanism returned 0 ns when calling these functions. This happened for example when running Busybox's ping which calls syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts) which eventually calls ktime_get. As a result the returned ping travel time was zero. Signed-off-by:
Hector Palacios <hector.palacios@digi.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Trond Myklebust authored
commit 24ca9a84 upstream. By returning '0' instead of 'EAGAIN' when the tests in xs_nospace() fail to find evidence of socket congestion, we are making the RPC engine believe that the message was incorrectly sent and so it disconnects the socket instead of just retrying. The bug appears to have been introduced by commit 5e3771ce (SUNRPC: Ensure that xs_nospace return values are propagated). Reported-by:
Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Tested-by:
-
Tim Blechmann authored
commit a2987855 upstream. commit 6175ddf0 optimized the mem*io functions that have been used to send commands to the device. these optimizations somehow corrupted the communication with the lx6464es, that resulted the device to be unusable with kernels after 2.6.33. this patch emulates the memcpy_*_io functions via a loop to avoid these problems. Signed-off-by:
Tim Blechmann <tim@klingt.org> LKML-Reference: <4ECB5257.4040600@ladisch.de> Signed-off-by:
-
Will Deacon authored
commit 11ed0ba1 upstream. This patch implements a workaround for PL310 erratum 769419. On revisions of the PL310 prior to r3p2, the Store Buffer does not automatically drain. This can cause normal, non-cacheable writes to be retained when the memory system is idle, leading to suboptimal I/O performance for drivers using coherent DMA. This patch adds an optional wmb() call to the cpu_idle loop. On systems with an outer cache, this causes an explicit flush of the store buffer. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Tested-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Bjorn Helgaas authored
commit 4cac2eb1 upstream. Previously we claimed device ID 0x7450, regardless of the vendor, which is clearly wrong. Now we'll claim that device ID only for AMD. I suspect this was just a typo in the original code, but it's possible this change will break shpchp on non-7450 AMD bridges. If so, we'll have to fix them as we find them. Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863Reported-by:
Ralf Jung <ralfjung-e@gmx.de> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Tyler Hicks authored
commit 0f751e64 upstream. From mhalcrow's original commit message: Characters with ASCII values greater than the size of filename_rev_map[] are valid filename characters. ecryptfs_decode_from_filename() will access kernel memory beyond that array, and ecryptfs_parse_tag_70_packet() will then decrypt those characters. The attacker, using the FNEK of the crafted file, can then re-encrypt the characters to reveal the kernel memory past the end of the filename_rev_map[] array. I expect low security impact since this array is statically allocated in the text area, and the amount of memory past the array that is accessible is limited by the largest possible ASCII filename character. This patch solves the issue reported by mhalcrow but with an implementation suggested by Linus to simply extend the length of filename_rev_map[] to 256. Characters greater than 0x7A are mapped to 0x00, which is how invalid characters less than 0x7A were previously being handled. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Reported-by:
Michael Halcrow <mhalcrow@google.com> Signed-off-by:
-
Jeffrey (Sheng-Hui) Chu authored
commit cc6bcf7d upstream. The wrong bits were put on the wire, fix that. This fixes kernel bug #42562. Signed-off-by:
Sheng-Hui J. Chu <jeffchu@broadcom.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
- 26 Nov, 2011 11 commits
-
-
Greg Kroah-Hartman authored
-
Alan Cox authored
commit 0587102c upstream Again basically cut and paste Convert the main driver set to use the hooks for GICOUNT Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Alan Cox authored
commit d281da7f upstream Dan Rosenberg noted that various drivers return the struct with uncleared fields. Instead of spending forever trying to stomp all the drivers that get it wrong (and every new driver) do the job in one place. This first patch adds the needed operations and hooks them up, including the needed USB midlayer and serial core plumbing. Signed-off-by:
-
sordna authored
commit 0d145d7d upstream. The following patch contains additional affected webcam models, on top of the patches commited to linux-next 2394d67e and 5b253d88Signed-off-by:
sordna <sordna@gmail.com> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Josh Boyer authored
commit 60c71ca9 upstream. We've had another report of the "chipmunk" sound on a Logitech C600 webcam. This patch resolves the issue. Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Alan Stern authored
commit 2f640bf4 upstream. The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands; shorter commands must be padded. Simon Detheridge reports that his 3-TB USB disk drive claims to use the 8020i protocol (which is normally meant for ATAPI devices like CD drives), and because of its large size, the disk drive requires the use of 16-byte commands. However the usb_stor_pad12_command() routine in usb-storage always sets the command length to 12, making the drive impossible to use. Since the SFF-8020i specification allows for 16-byte commands in future extensions, we may as well accept them. This patch (as1490) changes usb_stor_pad12_command() to leave commands larger than 12 bytes alone rather than truncating them. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Simon Detheridge <simon@widgit.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by:
-
Andrew Worsley authored
commit b1ffb4c8 upstream. Fix for ftdi_set_termios() glitching output ftdi_set_termios() is constantly setting the baud rate, data bits and parity unnecessarily on every call, . When called while characters are being transmitted can cause the FTDI chip to corrupt the serial port bit stream output by stalling the output half a bit during the output of a character. Simple fix by skipping this setting if the baud rate/data bits/parity are unchanged. Signed-off-by:
Andrew Worsley <amworsley@gmail.com> Signed-off-by:
-
wangyanqing authored
commit 0c165955 upstream. I get report from customer that his usb-serial converter doesn't work well,it sometimes work, but sometimes it doesn't. The usb-serial converter's id: vendor_id product_id 0x4348 0x5523 Then I search the usb-serial codes, and there are two drivers announce support this device, pl2303 and ch341, commit 026dfaf1 cause it. Through many times to test, ch341 works well with this device, and pl2303 doesn't work quite often(it just work quite little). ch341 works well with this device, so we doesn't need pl2303 to support.I try to revert 026dfaf1 first, but it failed. So I prepare this patch by hand to revert it. Signed-off-by:
Wang YanQing <Udknight@gmail.com> Signed-off-by:
-
Michal Marek authored
commit 8417da6f upstream. Starting with 4.4, gcc will happily accept -Wno-<anything> in the cc-option test and complain later when compiling a file that has some other warning. This rather unexpected behavior is intentional as per http://gcc.gnu.org/PR28322, so work around it by testing for support of the opposite option (without the no-). Introduce a new Makefile function cc-disable-warning that does this and update two uses of cc-option in the toplevel Makefile. Reported-and-tested-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Shan Wei authored
commit a9cf73ea upstream. At this point, skb->data points to skb_transport_header. So, headroom check is wrong. For some case:bridge(UFO is on) + eth device(UFO is off), there is no enough headroom for IPv6 frag head. But headroom check is always false. This will bring about data be moved to there prior to skb->head, when adding IPv6 frag header to skb. Signed-off-by:
Shan Wei <shanwei@cn.fujitsu.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Mitsuo Hayasaka authored
commit f5252e00 upstream The /proc/vmallocinfo shows information about vmalloc allocations in vmlist that is a linklist of vm_struct. It, however, may access pages field of vm_struct where a page was not allocated. This results in a null pointer access and leads to a kernel panic. Why this happen: In __vmalloc_node() called from vmalloc(), newly allocated vm_struct is added to vmlist at __get_vm_area_node() and then, some fields of vm_struct such as nr_pages and pages are set at __vmalloc_area_node(). In other words, it is added to vmlist before it is fully initialized. At the same time, when the /proc/vmallocinfo is read, it accesses the pages field of vm_struct according to the nr_pages field at show_numa_info(). Thus, a null pointer access happens. Patch: This patch adds newly allocated vm_struct to the vmlist *after* it is fully initialized. So, it can avoid accessing the pages field with unallocated page when show_numa_info() is called. Signed-off-by:
Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: David Rientjes <rientjes@google.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
