- Feb 12, 2009
-
-
Timothy S. Nelson authored
commit 97c44836 upstream. This patch makes the ROM reading code return an error to user space if the size of the ROM read is equal to 0. The patch also emits a warnings if the contents of the ROM are invalid, and documents the effects of the "enable" file on ROM reading. Signed-off-by:
Timothy S. Nelson <wayland@wayland.id.au> Acked-by:
Alex Villacis-Lasso <a_villacis@palosanto.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alex Chiang authored
commit 3419c75e upstream. We only want to disable ASPM when the last function is removed from the parent's device list. We determine this by checking to see if the parent's device list is completely empty. Unfortunately, we never hit that code because the parent is considered an upstream port, and never had an ASPM link_state associated with it. The early check for !link_state causes us to return early, we never discover that our device list is empty, and thus we never remove the downstream ports' link_state nodes. Instead of checking to see if the parent's device list is empty, we can check to see if we are the last device on the list, and if so, then we know that we can clean up properly. Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
-
Takashi Iwai authored
commit f67d8176 upstream. Added model=fujisu-pi2515 for FSC Amilo Xi2550 with ALC883 codec. Refernece: Novell bnc#450979 https://bugzilla.novell.com/show_bug.cgi?id=450979 Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit c6e8f2da upstream. ALC272 needs EAPD for speaker outputs as well as other similar ALC codecs. Signed-off-by:
-
Takashi Iwai authored
commit 4a5a4c56 upstream. Signed-off-by:
-
Michael Bramer authored
commit 78d70d48 upstream. This Patch add the device information for the MIC-3620 8-port RS-232 cPCI card from Advantech Co. Ltd. Signed-off-by:
Michael Bramer <grisu@deb-support.de> Signed-off-by:
Alan Cox <number6@the-village.bc.nu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Zhao Yakui authored
commit 0a3db1ce upstream. According to the Spec the first two elements in the _BCL package won't be regarded as the available brightness level. The first is the brightness when full power is connected to the box(It means that the AC adapter is plugged). The second is the brightness level when the box is on battery. If the first two elements are still used while finding the next brightness level, it will fall back to the lowest level when keeping on pressing hotkey. (On some boxes the brightness will be changed twice when hotkey is pressed once. One is in the ACPI video driver. The other is changed by sys I/F. In the ACPI video driver the first two elements will be used while changing the brightness. But the first two elements is skipped while using sys I/F. In such case there exists the inconsistency). So he first two elements had better be skipped while showing the available brightness or finding the next brightness level. http://bugzilla.kernel.org/show_bug.cgi?id=12450 Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Zhao Yakui authored
commit f3b39f13 upstream. eliminate the duplicate the name of "VGA" http://bugzilla.kernel.org/show_bug.cgi?id=12514 Signed-off-by:
-
Len Brown authored
commit 9e3a9d1e upstream. When ACPI is disabled in the BIOS of this VIA C3 box, it invalidates the RSDP, which Linux notices: ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080926] Bug Linux neglected to disable ACPI at that stage, and later scribbled on smp_found_config: ACPI: No APIC-table, disabling MPS But this box doesn't run well in legacy PIC mode, it needed IOAPIC mode to perform correctly: http://lkml.org/lkml/2009/2/5/39 So exit ACPI mode cleanly when we first detect that it is hopeless. Signed-off-by:
-
Myron Stowe authored
commit 386e4a83 upstream. During early boot, ACPI RSDT/XSDT table entries are gathered into the 'initial_tables[]' array. This array is currently statically defined (see ./drivers/acpi/tables.c). When there are more table entries than can be held in the 'initial_tables[]' array, the message "Truncating N table entries!" is output. As currently implemented, this message will always erroneously calculate N as 0. This patch fixes the calculation that determines how many table entries will be missing (truncated). This modification may be used under either the GPL or the BSD-style license used for Intel ACPI CA code. Signed-off-by:
Myron Stowe <myron.stowe@hp.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Jiri Slaby authored
commit 25cf9bc1 upstream. Most of netmos 9835 hardware is handled by parport-serial. IBM introduces a device which doesn't have any parallel ports and have screwed subdevice PCI id (not corresponding to port numbers). Handle this device (9710:9835 1014:0299) properly. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Stefan Richter authored
Commit 1448d7c6 upstream. As per https://bugs.launchpad.net/bugs/294391 . These got one sample of each iPod generation going. However there still occurred I/O stalls with the 3rd generation iPod which remain undiagnosed at the time of this writing. Acked-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Stefan Richter authored
Commit c8c4707c upstream. According to https://bugs.launchpad.net/bugs/294391 - 3rd generation iPods need the "fix capacity" workaround after all (apparently they crash after the last sector was accessed), - 2nd generation iPods need the "128 kB maximum request size" workaround. Alas both iPod generations feature the same model ID in the config ROM, hence we can only define a shared quirks list entry for them. Luckily the fix capacity workaround did not show a negative effect in Jarod's tests with 2nd gen. iPod. A side note: Apple computers in target mode (or at least an x86 Mac mini) don't have firmware_version and model_id, hence none of the iPod quirks list entries is active for them. Tested-by:
-
Stefan Richter authored
Commit 5e212567 upstream. Reported-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> who also provided a first version of the fix. Signed-off-by:
-
Stefan Richter authored
Commit 8b7b6afa upstream. Camcorders have a tendency to fail read requests to their config ROM and write request to their FCP command register with ack_busy_X. This has become a problem with newer kernels and especially Panasonic camcorders, causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently logs "send oops"; kino reports loss of AV/C control. I suspect that lower CPU scheduling latencies in newer kernels made this issue more prominent now. According to https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 this can be fixed by configuring the FireWire controller for more hardware retries for request transmission; these retries are evidently more successful than libavc1394's own retry loop (typically 3 tries on top of hardware retries). Presumably the same issue has been reported at https://bugzilla.redhat.com/show_bug.cgi?id=449252 and https://bugzilla.redhat.com/show_bug.cgi?id=477279 . In a quick test with a JVC camcorder (which didn't malfunction like the reported camcorders), this change decreased the number of ack_busy_X from 16 in three runs of dvgrab to 4 in three runs of the same capture duration. Signed-off-by:
-
Stefan Richter authored
Commit 64c634ef upstream. Camcorders have a tendency to fail read requests to their config ROM and write request to their FCP command register with ack_busy_X. This has become a problem with newer kernels and especially Panasonic camcorders, causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently logs "send oops"; kino reports loss of AV/C control. I suspect that lower CPU scheduling latencies in newer kernels made this issue more prominent now. According to https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 this can be fixed by configuring the FireWire controller for more hardware retries for request transmission; these retries are evidently more successful than libavc1394's own retry loop (typically 3 tries on top of hardware retries). Presumably the same issue has been reported at https://bugzilla.redhat.com/show_bug.cgi?id=449252 and https://bugzilla.redhat.com/show_bug.cgi?id=477279 . Tested-by: Mathias Beilstein Signed-off-by:
-
Borislav Petkov authored
commit 85877061 upstream. Impact: fix to enable APIC for AMD Fam10h on chipsets with a missing/b0rked ACPI MP table (MADT) Booting a 32bit kernel on an AMD Fam10h CPU running on chipsets with missing/b0rked MP table leads to a hang pretty early in the boot process due to the APIC not being initialized. Fix that by falling back to the default APIC base address in 32bit code, as it is done in the 64bit codepath. Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Johannes Weiner authored
commit 777c6c5f upstream. With exclusive waiters, every process woken up through the wait queue must ensure that the next waiter down the line is woken when it has finished. Interruptible waiters don't do that when aborting due to a signal. And if an aborting waiter is concurrently woken up through the waitqueue, noone will ever wake up the next waiter. This has been observed with __wait_on_bit_lock() used by lock_page_killable(): the first contender on the queue was aborting when the actual lock holder woke it up concurrently. The aborted contender didn't acquire the lock and therefor never did an unlock followed by waking up the next waiter. Add abort_exclusive_wait() which removes the process' wait descriptor from the waitqueue, iff still queued, or wakes up the next waiter otherwise. It does so under the waitqueue lock. Racing with a wake up means the aborting process is either already woken (removed from the queue) and will wake up the next waiter, or it will remove itself from the queue and the concurrent wake up will apply to the next waiter after it. Use abort_exclusive_wait() in __wait_event_interruptible_exclusive() and __wait_on_bit_lock() when they were interrupted by other means than a wake up through the queue. [akpm@linux-foundation.org: coding-style fixes] Reported-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Mentored-by:
Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Chuck Lever <cel@citi.umich.edu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Clemens Ladisch authored
commit 894dcd78 upstream. For audio devices that do not have proper audio descriptors (e.g., Edirol UA-20), we use hardcoded parameters from our quirks list. However, we must still read the maximum packet size from the standard endpoint descriptor; otherwise, we might use packets that are too big and therefore rejected by the USB core. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Tony Battersby authored
commit a68e61e8 upstream. shm_get_stat() assumes that the inode is a "struct shmem_inode_info", which is incorrect for !CONFIG_SHMEM (see fs/ramfs/inode.c: ramfs_get_inode() vs. mm/shmem.c: shmem_get_inode()). This bad assumption can cause shmctl(SHM_INFO) to lockup when shm_get_stat() tries to spin_lock(&info->lock). Users of !CONFIG_SHMEM may encounter this lockup simply by invoking the 'ipcs' command. Reported by Jiri Olsa back in February 2008: http://lkml.org/lkml/2008/2/29/74 Signed-off-by:
Tony Battersby <tonyb@cybernetics.com> Cc: Jiri Kosina <jkosina@suse.cz> Reported-by:
Jiri Olsa <olsajiri@gmail.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Dean Nelson authored
commit 361916a9 upstream. A missing type cast results in writing way beyond the end of a kzalloc()'d memory segment resulting in slab corruption. But it seems like the better solution is to define ->recv_msg_slots as a 'void *' rather than a 'struct xpc_notify_mq_msg_uv *' and add the type cast. Signed-off-by:
Dean Nelson <dcn@sgi.com> Signed-off-by:
-
Masami Hiramatsu authored
commit 9be260a6 upstream. Prevent kprobes from catching spurious faults which will cause infinite recursive page-fault and memory corruption by stack overflow. Signed-off-by:
Masami Hiramatsu <mhiramat@redhat.com> Signed-off-by:
-
Rusty Russell authored
commit 7f9a50a5 upstream. Impact: fix spurious BUG_ON() triggered under load module_refcount() isn't reliable outside stop_machine(), as demonstrated by Karsten Keil <kkeil@suse.de>, networking can trigger it under load (an inc on one cpu and dec on another while module_refcount() is tallying can give false results, for example). Almost noone should be using __module_get, but that's another issue. Cc: Karsten Keil <kkeil@suse.de> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
NeilBrown authored
commit de01dfad upstream. Each different metadata format supported by md supports a different maximum number of devices. We really should be enforcing this maximum in the kernel, but we aren't quite doing that properly. We currently only enforce it at the 'hot_add' point, which is an older interface which is not used by current userspace. We need to also enforce it at 'add_new_disk' time for active arrays and at 'do_md_run' time when starting a new array. So move the test from 'hot_add' into 'bind_rdev_to_array' which is called from both 'hot_add' and 'add_new_disk, and add a new test in 'analyse_sbs' which is called from 'do_md_run'. This bug (or missing feature) has been around "forever" and so the patch is suitable for any -stable that is currently maintained. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Darren Salt authored
commit 7695fb04 upstream. I got the following oops while changing the backlight brightness during startup. When it happens, it prevents use of the hotkeys, Fn-Fx, and the lid button. It's a clear use-before-init, as I verified by testing with an appropriately-placed "else printk". BUG: unable to handle kernel NULL pointer dereference at 00000000 *pde = 00000000 Oops: 0002 [#1] PREEMPT SMP Pid: 160, comm: kacpi_notify Not tainted (2.6.28.1-eee901 #4) 901 EIP: 0060:[<c0264e68>] [<c0264e68>] eeepc_hotk_notify+26/da EFLAGS: 00010246 CPU: 1 Using defaults from ksymoops -t elf32-i386 -a i386 EAX: 00000009 EBX: 00000000 ECX: 00000009 EDX: f70dbf64 ESI: 00000029 EDI: f7335188 EBP: c02112c9 ESP: f70dbf80 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 f70731e0 f73acd50 c02164ac f7335180 f70aa040 c02112e6 f733518c c012b62f f70aa044 f70aa040 c012bdba f70aa04c 00000000 c012be6e 00000000 f70bdf80 c012e198 f70dbfc4 f70dbfc4 f70aa040 c012bdba 00000000 c012e0c9 c012e091 Call Trace: [<c02164ac>] ? acpi_ev_notify_dispatch+4c/55 [<c02112e6>] ? acpi_os_execute_deferred+1d/25 [<c012b62f>] ? run_workqueue+71/f1 [<c012bdba>] ? worker_thread+0/bf [<c012be6e>] ? worker_thread+b4/bf [<c012e198>] ? autoremove_wake_function+0/2b [<c012bdba>] ? worker_thread+0/bf [<c012e0c9>] ? kthread+38/5f [<c012e091>] ? kthread+0/5f [<c0103abf>] ? kernel_thread_helper+7/10 Code: 00 00 00 00 c3 83 3d 60 5c 50 c0 00 56 89 d6 53 0f 84 c4 00 00 00 8d 42 e0 83 f8 0f 77 0f 8b 1d 68 5c 50 c0 89 d8 e8 a9 fa ff ff <89> 03 8b 1d 60 5c 50 c0 89 f2 83 e2 7f 0f b7 4c 53 10 8d 41 01 Signed-off-by:
Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by:
-
Karsten Keil authored
commit 4d7155b9 upstream. On machine were no IO ports are assigned the call to pci_enable_device() will fail, even if need_ioport is false, we need to use pci_enable_device_mem() here. Signed-off-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jesse Brandeburg authored
commit 15b2bee2 upstream. A nasty bug was found where an MTU change (or anything else that caused a reset) could race with the interrupt code. The interrupt code was entered by a shared interrupt during the MTU change. This change prevents the interrupt code from running while the driver is in the middle of its reset path. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
Keith Packard authored
commit 44d49441 upstream. Instead of doing a posting read after each GTT entry update, do a single one at the end of the writes. This should reduce boot time a tiny amount by avoiding a lot of extra uncached reads. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Eric Anholt authored
commit b854b2ab upstream. Signed-off-by:
Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Zhenyu Wang authored
commit a50ccc6c upstream. Signed-off-by:
Zhenyu Wang <zhenyu.z.wang@intel.com> Signed-off-by:
-
Pallipadi, Venkatesh authored
commit d96f94c6 upstream. Bit 11 in intel PDC definitions is meant for OS capability to handle hardware coordination of P-states. In Linux we have always supported hwardware coordination of P-states. Just let the BIOSes know that we support it, by setting this bit. Some BIOSes use this bit to choose between hardware or software coordination and without this change below, BIOSes switch to software coordination, which is not very optimal in terms of power consumption and extra wakeups from idle. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
-
Holger Macht authored
commit fc5a9f88 upstream. Some devices trigger a DEVICE_CHECK on every evalutation of _STA. This can also be seen in commit 8b59560a (ACPI: dock: avoid check _STA method). If an undock is processed, the dock driver sends a uevent and userspace might read the show_docked property in sysfs. This causes an evaluation of _STA of the particular device which causes the dock driver to immediately dock again. In any case, evaluation of _STA (show_docked) does not necessarily mean that we are docked, so check with the internal device structure. http://bugzilla.kernel.org/show_bug.cgi?id=12360 Signed-off-by:
Holger Macht <hmacht@suse.de> Signed-off-by:
-
- Feb 06, 2009
-
-
Greg Kroah-Hartman authored
-
Lin Ming authored
commit d037c5fd upstream. In a fully qualified namepath, allow multiple backslash prefixes. This can happen because of the use of a double-backslash in strings (since backslash is the escape character) causing confusion. ACPICA BZ 739 Lin Ming. http://www.acpica.org/bugzilla/show_bug.cgi?id=739 Signed-off-by:
Lin Ming <ming.m.lin@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
-
Mark Lord authored
commit 4462254a upstream. Fix chip type for the Highpoint RocketRAID 1740 and 1742 PCI cards. These really do have Marvell 6042 chips on them, rather than the 5081 chip. Confirmed by multiple (two) users (for the 1740), and by examining the product photographs from Highpoint's web site. Signed-off-by:
Mark Lord <mlord@pobox.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Jeff Layton authored
commit 20d5a399 upstream. dlm_posix_get fills out the relevant fields in the file_lock before returning when there is a lock conflict, but doesn't clean out any of the other fields in the file_lock. When nfsd does a NFSv4 lockt call, it sets the fl_lmops to nfsd_posix_mng_ops before calling the lower fs. When the lock comes back after testing a lock on GFS2, it still has that field set. This confuses nfsd into thinking that the file_lock is a nfsd4 lock. Fix this by making DLM reinitialize the file_lock before copying the fields from the conflicting lock. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
David Teigland <teigland@redhat.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 4fb507b6 HP xw4600 Workstation is known to require the "old" (ie. compatible with ACPI 1.0) suspend code ordering, so blacklist it for this purpose. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Tested-by:
John Brown <john.brown3@hp.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 11e93130 upstream. According to the ACPI specification the SCI_EN flag is controlled by the hardware, which sets this flag to inform the kernel that ACPI is enabled. For this reason, we shouldn't try to modify SCI_EN directly. Also, we don't need to do it in irqrouter_resume(), since lower-level resume code takes care of enabling ACPI in case it hasn't been enabled by the BIOS before passing control to the kernel (which by the way is against the ACPI specification). Signed-off-by:
-
Alexey Starikovskiy authored
Newly inserted battery might differ from one just removed, so update of battery info fields is required. commit 50b17851 upstream. Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Acked-by:
Andy Neitzke <neitzke@ias.edu> Signed-off-by:
-
Zhang Rui authored
commit 77453840 upstream. asus_hotk_get_info should return -ENODEV if the model is not supported. http://bugzilla.kernel.org/show_bug.cgi?id=10389 Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
