- 25 Oct, 2011 13 commits
-
-
Ben Skeggs authored
commit 8d3bb236 upstream. This was true for new TTM_PL_SYSTEM and new TTM_PL_TT cases, but wasn't the case on TTM_PL_SYSTEM<->TTM_PL_TT moves, which causes trouble on some paths as nouveau's move_notify() hook requires that the dma addresses be valid at this point. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Seth Forshee authored
commit 6596528e upstream. Currently all bio requests are 512 bytes, which may fail for media whose physical sector size is larger than this. Ensure these requests are not smaller than the block device logical block size. BugLink: http://bugs.launchpad.net/bugs/734883Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Laurent Pinchart authored
commit 4d9b2ebd upstream. The uvc_mc_register_entity() function wrongfully selects the media_entity associated with a UVC entity when creating links. This results in access to uninitialized media_entity structures and can hit a BUG_ON statement in media_entity_create_link(). Fix it. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Jiri Kosina authored
commit 35d851df upstream. This is basically a more generic respin of 23746a66 ("HID: magicmouse: ignore 'ivalid report id' while switching modes") which got reverted later by c3a492. It turns out that on some configurations, this is actually still the case and we are not able to detect in runtime. The device reponds with 'invalid report id' when feature report switching it into multitouch mode is sent to it. This has been silently ignored before 0825411a ("HID: bt: Wait for ACK on Sent Reports"), but since this commit, it propagates -EIO from the _raw callback . So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's how the device reacts in normal mode. Sad, but following reality. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022Reported-by:
Chase Douglas <chase.douglas@canonical.com> Reported-by:
Jaikumar Ganesh <jaikumarg@android.com> Tested-by:
Jiri Kosina <jkosina@suse.cz> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Thomas Courbon authored
commit 78a7539b upstream. Some samsung latop of the N150/N2{10,20,30} serie are badly detected by the samsung-laptop platform driver, see bug # 36082. It appears that N230 identifies itself as N150/N210/N220/N230 whereas the other identify themselves as N150/N210/220. This patch attemtp fix #36082 allowing correct identification for all the said netbook model. Reported-by:
Daniel Eklöf <daniel@ekloef.se> Signed-off-by:
Thomas Courbon <thcourbon@gmail.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Miklos Szeredi authored
commit 5dfcc87f upstream. kmemleak is reporting that 32 bytes are being leaked by FUSE: unreferenced object 0xe373b270 (size 32): comm "fusermount", pid 1207, jiffies 4294707026 (age 2675.187s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<b05517d7>] kmemleak_alloc+0x27/0x50 [<b0196435>] kmem_cache_alloc+0xc5/0x180 [<b02455be>] fuse_alloc_forget+0x1e/0x20 [<b0245670>] fuse_alloc_inode+0xb0/0xd0 [<b01b1a8c>] alloc_inode+0x1c/0x80 [<b01b290f>] iget5_locked+0x8f/0x1a0 [<b0246022>] fuse_iget+0x72/0x1a0 [<b02461da>] fuse_get_root_inode+0x8a/0x90 [<b02465cf>] fuse_fill_super+0x3ef/0x590 [<b019e56f>] mount_nodev+0x3f/0x90 [<b0244e95>] fuse_mount+0x15/0x20 [<b019d1bc>] mount_fs+0x1c/0xc0 [<b01b5811>] vfs_kern_mount+0x41/0x90 [<b01b5af9>] do_kern_mount+0x39/0xd0 [<b01b7585>] do_mount+0x2e5/0x660 [<b01b7966>] sys_mount+0x66/0xa0 This leak report is consistent and happens once per boot on 3.1.0-rc5-dirty. This happens if a FORGET request is queued after the fuse device was released. Reported-by:
Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Tested-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Peter Zijlstra authored
commit bcd5cff7 upstream. There's a lock inversion between the cputimer->lock and rq->lock; notably the two callchains involved are: update_rlimit_cpu() sighand->siglock set_process_cpu_timer() cpu_timer_sample_group() thread_group_cputimer() cputimer->lock thread_group_cputime() task_sched_runtime() ->pi_lock rq->lock scheduler_tick() rq->lock task_tick_fair() update_curr() account_group_exec() cputimer->lock Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and the second one is keeping up-to-date. This problem was introduced by e8abccb7 ("posix-cpu-timers: Cure SMP accounting oddities"). Cure the problem by removing the cputimer->lock and rq->lock nesting, this leaves concurrent enablers doing duplicate work, but the time wasted should be on the same order otherwise wasted spinning on the lock and the greater-than assignment filter should ensure we preserve monotonicity. Reported-by:
Dave Jones <davej@redhat.com> Reported-by:
Simon Kirby <sim@hostway.ca> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Link: http://lkml.kernel.org/r/1318928713.21167.4.camel@twinsSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Alex Deucher authored
commit 5a6e8482 upstream. FB scratch indices are dword indices, but we were treating them as byte indices. As such, we were getting the wrong FB scratch data for non-0 indices. Fix the indices and guard the indexing against indices larger than the scratch allocation. Fixes memory corruption on some boards if data was written past the end of the FB scratch array. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reported-by:
-
Linus Torvalds authored
commit a84a79e4 upstream. The size is always valid, but variable-length arrays generate worse code for no good reason (unless the function happens to be inlined and the compiler sees the length for the simple constant it is). Also, there seems to be some code generation problem on POWER, where Henrik Bakken reports that register r28 can get corrupted under some subtle circumstances (interrupt happening at the wrong time?). That all indicates some seriously broken compiler issues, but since variable length arrays are bad regardless, there's little point in trying to chase it down. "Just don't do that, then". Reported-by:
Henrik Grindal Bakken <henribak@cisco.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Jean Delvare authored
commit bf164c58 upstream. The w83627ehf driver is improperly reporting thermal diode sensors as type 2, instead of 3. This caused "sensors" and possibly other monitoring tools to report these sensors as "transistor" instead of "thermal diode". Furthermore, diode subtype selection (CPU vs. external) is only supported by the original W83627EHF/EHG. All later models only support CPU diode type, and some (NCT6776F) don't even have the register in question so we should avoid reading from it. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
-
Jeremiah Matthey authored
commit f5e42825 upstream. Patch to add SiGma Micro-based keyboards (1c4f:0002) to hid-quirks. These keyboards dont seem to allow the records to be initialized, and hence a timeout occurs when the usbhid driver attempts to initialize them. The patch just adds the signature for these keyboards to the hid-quirks list with the setting HID_QUIRK_NO_INIT_REPORTS. This removes the 5-10 second wait for the timeout to occur. Signed-off-by:
Jeremiah Matthey <sprg86@gmail.com> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Will Deacon authored
commit 29a541f6 upstream. Using COHERENT_LINE_{MISS,HIT} for cache misses and references respectively is completely wrong. Instead, use the L1D events which are a better and more useful approximation despite ignoring instruction traffic. Reported-by:
Alasdair Grant <alasdair.grant@arm.com> Reported-by:
Matt Horsnell <matt.horsnell@arm.com> Reported-by:
Michael Williams <michael.williams@arm.com> Cc: Jean Pihet <j-pihet@ti.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Linus Walleij authored
commit 002ea9ee upstream. The VM subsystem assumes that there are valid memmap entries from the bank start aligned to MAX_ORDER_NR_PAGES. On the Ux500 we have a lot of mem=N arguments on the commandline triggering this bug several times over and causing kernel oops messages. Cc: Michael Bohan <mbohan@codeaurora.org> Cc: Nicolas Pitre <nico@fluxnic.net> Signed-off-by:
Johan Palsson <johan.palsson@stericsson.com> Signed-off-by:
Rabin Vincent <rabin.vincent@stericsson.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 16 Oct, 2011 27 commits
-
-
Greg Kroah-Hartman authored
-
Bruce Allan authored
commit 0ed013e2 upstream. The MAC can drop short packets when the PHY detects noise on the line at 100Mbps due to a timing issue. Workaround the issue by increasing the PLL counter so the PHY properly recognizes the synchronization pattern from the MAC. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Tested-by:
Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by:
-
Steven Rostedt authored
commit 04da85b8 upstream. The struct ftrace_hash was declared within CONFIG_FUNCTION_TRACER but was referenced outside of it. Reported-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org>
-
Steven Rostedt authored
commit f7bc8b61 upstream. Enabling function tracer to trace all functions, then load a module and then disable function tracing will cause ftrace to fail. This can also happen by enabling function tracing on the command line: ftrace=function and during boot up, modules are loaded, then you disable function tracing with 'echo nop > current_tracer' you will trigger a bug in ftrace that will shut itself down. The reason is, the new ftrace code keeps ref counts of all ftrace_ops that are registered for tracing. When one or more ftrace_ops are registered, all the records that represent the functions that the ftrace_ops will trace have a ref count incremented. If this ref count is not zero, when the code modification runs, that function will be enabled for tracing. If the ref count is zero, that function will be disabled from tracing. To make sure the accounting was working, FTRACE_WARN_ON()s were added to updating of the ref counts. If the ref count hits its max (> 2^30 ftrace_ops added), or if the ref count goes below zero, a FTRACE_WARN_ON() is triggered which disables all modification of code. Since it is common for ftrace_ops to trace all functions in the kernel, instead of creating > 20,000 hash items for the ftrace_ops, the hash count is just set to zero, and it represents that the ftrace_ops is to trace all functions. This is where the issues arrise. If you enable function tracing to trace all functions, and then add a module, the modules function records do not get the ref count updated. When the function tracer is disabled, all function records ref counts are subtracted. Since the modules never had their ref counts incremented, they go below zero and the FTRACE_WARN_ON() is triggered. The solution to this is rather simple. When modules are loaded, and their functions are added to the the ftrace pool, look to see if any ftrace_ops are registered that trace all functions. And for those, update the ref count for the module function records. Reported-by:
-
Steven Rostedt authored
commit 43dd61c9 upstream. The new code that allows different utilities to pick and choose what functions they trace broke the :mod: hook that allows users to trace only functions of a particular module. The reason is that the :mod: hook bypasses the hash that is setup to allow individual users to trace their own functions and uses the global hash directly. But if the global hash has not been set up, it will cause a bug: echo '*:mod:radeon' > /sys/kernel/debug/set_ftrace_filter produces: [drm:drm_mode_getfb] *ERROR* invalid framebuffer id [drm:radeon_crtc_page_flip] *ERROR* failed to reserve new rbo buffer before flip BUG: unable to handle kernel paging request at ffffffff8160ec90 IP: [<ffffffff810d9136>] add_hash_entry+0x66/0xd0 PGD 1a05067 PUD 1a09063 PMD 80000000016001e1 Oops: 0003 [#1] SMP Jul 7 04:02:28 phyllis kernel: [55303.858604] CPU 1 Modules linked in: cryptd aes_x86_64 aes_generic binfmt_misc rfcomm bnep ip6table_filter hid radeon r8169 ahci libahci mii ttm drm_kms_helper drm video i2c_algo_bit intel_agp intel_gtt Pid: 10344, comm: bash Tainted: G WC 3.0.0-rc5 #1 Dell Inc. Inspiron N5010/0YXXJJ RIP: 0010:[<ffffffff810d9136>] [<ffffffff810d9136>] add_hash_entry+0x66/0xd0 RSP: 0018:ffff88003a96bda8 EFLAGS: 00010246 RAX: ffff8801301735c0 RBX: ffffffff8160ec80 RCX: 0000000000306ee0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880137c92940 RBP: ffff88003a96bdb8 R08: ffff880137c95680 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff81c9df78 R13: ffff8801153d1000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f329c18a700(0000) GS:ffff880137c80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8160ec90 CR3: 000000003002b000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process bash (pid: 10344, threadinfo ffff88003a96a000, task ffff88012fcfc470) Stack: 0000000000000fd0 00000000000000fc ffff88003a96be38 ffffffff810d92f5 ffff88011c4c4e00 ffff880000000000 000000000b69f4d0 ffffffff8160ec80 ffff8800300e6f06 0000000081130295 0000000000000282 ffff8800300e6f00 Call Trace: [<ffffffff810d92f5>] match_records+0x155/0x1b0 [<ffffffff810d940c>] ftrace_mod_callback+0xbc/0x100 [<ffffffff810dafdf>] ftrace_regex_write+0x16f/0x210 [<ffffffff810db09f>] ftrace_filter_write+0xf/0x20 [<ffffffff81166e48>] vfs_write+0xc8/0x190 [<ffffffff81167001>] sys_write+0x51/0x90 [<ffffffff815c7e02>] system_call_fastpath+0x16/0x1b Code: 48 8b 33 31 d2 48 85 f6 75 33 49 89 d4 4c 03 63 08 49 8b 14 24 48 85 d2 48 89 10 74 04 48 89 42 08 49 89 04 24 4c 89 60 08 31 d2 RIP [<ffffffff810d9136>] add_hash_entry+0x66/0xd0 RSP <ffff88003a96bda8> CR2: ffffffff8160ec90 ---[ end trace a5d031828efdd88e ]--- Reported-by:
Brian Marete <marete@toshnix.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit bd710009 upstream. Convert some MIPS architecture's code to using struct syscore_ops objects for power management instead of sysdev classes and sysdevs. This simplifies the code and reduces the kernel's memory footprint. It also is necessary for removing sysdevs from the kernel entirely in the future. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Mark Nelson authored
commit 3c4aa91f upstream. Like e65cc194 this patch enables 64bit DMA for the AHCI SATA controller of a board that has the SB600 southbridge. In this case though we're enabling 64bit DMA for the Asus M3A motherboard. It is a new enough board that all of the BIOS releases since the initial release (0301 from 2007-10-22) work correctly with 64bit DMA enabled. Signed-off-by:
Mark Nelson <mdnelson8@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Jason Wang authored
This patch fixes the issue caused by ef81bb40 which is a backport of upstream 87c48fa3. The problem does not exist in upstream. We do not check whether route is attached before trying to assign ip identification through route dest which lead NULL pointer dereference. This happens when host bridge transmit a packet from guest. This patch changes ipv6_select_ident() to accept in6_addr as its paramter and fix the issue by using the destination address in ipv6 header when no route is attached. Signed-off-by:
Jason Wang <jasowang@redhat.com> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alex Deucher authored
commit cb7cf419 upstream. The encoders are supposedly fully routeable, but changing the mapping doesn't always seem to take. Using a hardcoded mapping is much more reliable. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41366Signed-off-by:
Simon Farnsworth <simon.farnsworth@onelan.co.uk> Signed-off-by:
-
Alex Deucher authored
commit 4f332844 upstream. If there are error flags in the aux status, retry the transaction. This makes aux much more reliable, especially on llano systems. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
srinidhi kasagar authored
commit 98e87d57 upstream. This applies ARM errata fix 754322 for all ux500 platforms. Signed-off-by:
srinidhi kasagar <srinidhi.kasagar@stericsson.com> Signed-off-by:
-
Tetsuo Handa authored
commit 91219352 upstream. Currently, search_binary_handler() tries to load binary loader module using request_module() if a loader for the requested program is not yet loaded. But second attempt of request_module() does not affect the result of search_binary_handler(). If request_module() triggered recursion, calling request_module() twice causes 2 to the power of MAX_KMOD_CONCURRENT (= 50) repetitions. It is not an infinite loop but is sufficient for users to consider as a hang up. Therefore, this patch changes not to call request_module() twice, making 1 to the power of MAX_KMOD_CONCURRENT repetitions in case of recursion. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by:
Richard Weinberger <richard@nod.at> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Maxim Uvarov <muvarov@gmail.com> Signed-off-by:
-
Koen Beel authored
commit d982dcdc upstream. Fix clock rate setting in the mxs-mmc driver. Previously, if div2 was 0 then the value for TIMING_CLOCK_RATE would have been 255 instead of 0. The limits for div1 (TIMING_CLOCK_DIVIDE) and div2 (TIMING_CLOCK_RATE+1) were also not correctly defined. Can easily be reproduced on mx23evk: default clock for high speed sdio cards is 50 MHz. With a SSP_CLK of 28.8 MHz default), this resulted in an actual clock rate of about 56 kHz. Tested on mx23evk. Signed-off-by:
Koen Beel <koen.beel@barco.com> Reviewed-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Mike Snitzer authored
commit 876fbba1 upstream. Commit a63a5cf8 (dm: improve block integrity support) introduced a two-phase initialization of a DM device's integrity profile. This patch avoids dereferencing a NULL 'template_disk' pointer in blk_integrity_register() if there is an integrity profile mismatch in dm_table_set_integrity(). This can occur if the integrity profiles for stacked devices in a DM table are changed between the call to dm_table_prealloc_integrity() and dm_table_set_integrity(). Reported-by:
Zdenek Kabelac <zkabelac@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
NeilBrown authored
commit 01f96c0a upstream. Two related problems: 1/ some error paths call "md_unregister_thread(mddev->thread)" without subsequently clearing ->thread. A subsequent call to mddev_unlock will try to wake the thread, and crash. 2/ Most calls to md_wakeup_thread are protected against the thread disappeared either by: - holding the ->mutex - having an active request, so something else must be keeping the array active. However mddev_unlock calls md_wakeup_thread after dropping the mutex and without any certainty of an active request, so the ->thread could theoretically disappear. So we need a spinlock to provide some protections. So change md_unregister_thread to take a pointer to the thread pointer, and ensure that it always does the required locking, and clears the pointer properly. Reported-by:
"Moshe Melnikov" <moshe@zadarastorage.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Mark Salyzyn authored
commit a73914c3 upstream. When a wide port is being utilized to a target, if one disables only one of the phys, we get an OS crash: BUG: unable to handle kernel NULL pointer dereference at 0000000000000238 IP: [<ffffffff814ca9b1>] mutex_lock+0x21/0x50 PGD 4103f5067 PUD 41dba9067 PMD 0 Oops: 0002 [#1] SMP last sysfs file: /sys/bus/pci/slots/5/address CPU 0 Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4 ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3 jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001] Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4 ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3 jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001] Pid: 5146, comm: scsi_wq_5 Not tainted 2.6.32-71.29.1.el6.lustre.7.x86_64 #1 Storage Server RIP: 0010:[<ffffffff814ca9b1>] [<ffffffff814ca9b1>] mutex_lock+0x21/0x50 RSP: 0018:ffff8803e4e33d30 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000238 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff8803e664c800 RDI: 0000000000000238 RBP: ffff8803e4e33d40 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000238 R14: ffff88041acb7200 R15: ffff88041c51ada0 FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000238 CR3: 0000000410143000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process scsi_wq_5 (pid: 5146, threadinfo ffff8803e4e32000, task ffff8803e4e294a0) Stack: ffff8803e664c800 0000000000000000 ffff8803e4e33d70 ffffffffa001f06e <0> ffff8803e4e33d60 ffff88041c51ada0 ffff88041acb7200 ffff88041bc0aa00 <0> ffff8803e4e33d90 ffffffffa0032b6c 0000000000000014 ffff88041acb7200 Call Trace: [<ffffffffa001f06e>] sas_port_delete_phy+0x2e/0xa0 [scsi_transport_sas] [<ffffffffa0032b6c>] sas_unregister_devs_sas_addr+0xac/0xe0 [libsas] [<ffffffffa0034914>] sas_ex_revalidate_domain+0x204/0x330 [libsas] [<ffffffffa00307f0>] ? sas_revalidate_domain+0x0/0x90 [libsas] [<ffffffffa0030855>] sas_revalidate_domain+0x65/0x90 [libsas] [<ffffffff8108c7d0>] worker_thread+0x170/0x2a0 [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 [<ffffffff8108c660>] ? worker_thread+0x0/0x2a0 [<ffffffff81091b36>] kthread+0x96/0xa0 [<ffffffff810141ca>] child_rip+0xa/0x20 [<ffffffff81091aa0>] ? kthread+0x0/0xa0 [<ffffffff810141c0>] ? child_rip+0x0/0x20 Code: ff ff 85 c0 75 ed eb d6 66 90 55 48 89 e5 48 83 ec 10 48 89 1c 24 4c 89 64 24 08 0f 1f 44 00 00 48 89 fb e8 92 f4 ff ff 48 89 df <f0> ff 0f 79 05 e8 25 00 00 00 65 48 8b 04 25 08 cc 00 00 48 2d RIP [<ffffffff814ca9b1>] mutex_lock+0x21/0x50 RSP <ffff8803e4e33d30> CR2: 0000000000000238 The following patch is admittedly a band-aid, and does not solve the root cause, but it still is a good candidate for hardening as a pointer check before reference. Signed-off-by:
Mark Salyzyn <mark_salyzyn@us.xyratex.com> Tested-by:
Jack Wang <jack_wang@usish.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Roland Dreier authored
commit 9bfacd01 upstream. I hit a crash in qla2x00_abort_all_cmds() if the qla2xxx module is unloaded right after it is loaded. I debugged this down to the abort handling improperly treating a command of type SRB_ADISC_CMD as if it had a bsg_job to complete when that command actually uses the iocb_cmd part of the union. (I guess to hit this one has to unload the module while the async FC initialization is still in progress) It seems we should only look for a bsg_job if type is SRB_ELS_CMD_RPT, SRB_ELS_CMD_HST or SRB_CT_CMD, so switch the test to make that explicit. Signed-off-by:
Roland Dreier <roland@purestorage.com> Acked-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Paul Menzel authored
commit 29cf7a30 upstream. In summary, this DMI quirk uses the _CRS info by default for the ASUS M2V-MX SE by turning on `pci=use_crs` and is similar to the quirk added by commit 2491762c ("x86/PCI: use host bridge _CRS info on ASRock ALiveSATA2-GLAN") whose commit message should be read for further information. Since commit 3e3da00c ("x86/pci: AMD one chain system to use pci read out res") Linux gives the following oops: parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] HDA Intel 0000:20:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 HDA Intel 0000:20:01.0: setting latency timer to 64 BUG: unable to handle kernel paging request at ffffc90011c08000 IP: [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel] PGD 13781a067 PUD 13781b067 PMD 1300ba067 PTE 800000fd00000173 Oops: 0009 [#1] SMP last sysfs file: /sys/module/snd_pcm/initstate CPU 0 Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event tpm_tis tpm snd_seq tpm_bios psmouse parport_pc snd_timer snd_seq_device parport processor evdev snd i2c_viapro thermal_sys amd64_edac_mod k8temp i2c_core soundcore shpchp pcspkr serio_raw asus_atk0110 pci_hotplug edac_core button snd_page_alloc edac_mce_amd ext3 jbd mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod raid1 md_mod usbhid hid sg sd_mod crc_t10dif sr_mod cdrom ata_generic uhci_hcd sata_via pata_via libata ehci_hcd usbcore scsi_mod via_rhine mii nls_base [last unloaded: scsi_wait_scan] Pid: 1153, comm: work_for_cpu Not tainted 2.6.37-1-amd64 #1 M2V-MX SE/System Product Name RIP: 0010:[<ffffffffa0578402>] [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel] RSP: 0018:ffff88013153fe50 EFLAGS: 00010286 RAX: ffffc90011c08000 RBX: ffff88013029ec00 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ffff88013341d000 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000286 R11: 0000000000003731 R12: ffff88013029c400 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88013341d090 FS: 0000000000000000(0000) GS:ffff8800bfc00000(0000) knlGS:00000000f7610ab0 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffc90011c08000 CR3: 0000000132f57000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process work_for_cpu (pid: 1153, threadinfo ffff88013153e000, task ffff8801303c86c0) Stack: 0000000000000005 ffffffff8123ad65 00000000000136c0 ffff88013029c400 ffff8801303c8998 ffff88013341d000 ffff88013341d090 ffff8801322d9dc8 ffff88013341d208 0000000000000000 0000000000000000 ffffffff811ad232 Call Trace: [<ffffffff8123ad65>] ? __pm_runtime_set_status+0x162/0x186 [<ffffffff811ad232>] ? local_pci_probe+0x49/0x92 [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b [<ffffffff8105afd0>] ? do_work_for_cpu+0xb/0x1b [<ffffffff8105fd3f>] ? kthread+0x7a/0x82 [<ffffffff8100a824>] ? kernel_thread_helper+0x4/0x10 [<ffffffff8105fcc5>] ? kthread+0x0/0x82 [<ffffffff8100a820>] ? kernel_thread_helper+0x0/0x10 Code: f4 01 00 00 ef 31 f6 48 89 df e8 29 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 b4 39 c3 e0 8b 7b 40 e8 fc 9d b1 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be RIP [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel] RSP <ffff88013153fe50> CR2: ffffc90011c08000 ---[ end trace 8d1f3ebc136437fd ]--- Trusting the ACPI _CRS information (`pci=use_crs`) fixes this problem. $ dmesg | grep -i crs # with the quirk PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug The match has to be against the DMI board entries though since the vendor entries are not populated. DMI: System manufacturer System Product Name/M2V-MX SE, BIOS 0304 10/30/2007 This quirk should be removed when `pci=use_crs` is enabled for machines from 2006 or earlier or some other solution is implemented. Using coreboot [1] with this board the problem does not exist but this quirk also does not affect it either. To be safe though the check is tightened to only take effect when the BIOS from American Megatrends is used. 15:13 < ruik> but coreboot does not need that 15:13 < ruik> because i have there only one root bus 15:13 < ruik> the audio is behind a bridge $ sudo dmidecode BIOS Information Vendor: American Megatrends Inc. Version: 0304 Release Date: 10/30/2007 [1] http://www.coreboot.org/ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=30552 Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: x86@kernel.org Signed-off-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Gertjan van Wingerde authored
commit 77a861c4 upstream. The rt2x00 driver gets frequent occurrences of the following error message when operating under load: phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 2. This is caused by simultaneous attempts from mac80211 to send a frame via rt2x00, which are not properly serialized inside rt2x00queue_write_tx_frame, causing the second frame to fail sending with the above mentioned error message. Fix this by introducing a per-queue spinlock to serialize the TX operations on that queue. Reported-by:
Andreas Hartmann <andihartmann@01019freenet.de> Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Acked-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Richard Cochran authored
commit f75159e9 upstream. The IEEE 1588 standard defines two kinds of messages, event and general messages. Event messages require time stamping, and general do not. When using UDP transport, two separate ports are used for the two message types. The BPF designed to recognize event messages incorrectly classifies L2 general messages as event messages. This commit fixes the issue by extending the filter to check the message type field for L2 PTP packets. Event messages are be distinguished from general messages by testing the "general" bit. Signed-off-by:
Richard Cochran <richard.cochran@omicron.at> Signed-off-by:
-
Alex Deucher authored
commit 12d5180b upstream. Most asics just use the hw default value which requires no explicit programming. For those that need a different value, the vbios will program it properly. As such, there's no need to program these registers explicitly in the driver. Changing MC_SHARED_CHREMAP requires a reload of all data in vram otherwise its contents will be scambled. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=40103 v2: drop now unused channel_remap functions. Signed-off-by:
-
Alex Deucher authored
commit 6375bda0 upstream. The previous code could potentially loop forever. Limit the number of DP aux defer retries to 4 for native aux transactions, same as i2c over aux transactions. Noticed by: Brad Campbell <lists2009@fnarfbargle.com> Signed-off-by:
-
Alex Deucher authored
commit 109bc10d upstream. An incorrect ordering in the error checking code lead to DP aux defer being skipped in the aux native write path. Move the bytes transferred check (ret == 0) below the defer check. Tracked down by: Brad Campbell <brad@fnarfbargle.com> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41121Signed-off-by:
-
Alex Deucher authored
commit 5ba7ddf8 upstream. Only disable the pipe if the monitor is physically disconnected. The previous logic also disabled the pipe if the link was trained. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41248Signed-off-by:
-
Michel Dänzer authored
commit b8aee294 upstream. Fixes cursor disappearing prematurely when moving off a top/left edge which is not located at the desktop top/left edge. Signed-off-by:
-
Axel Lin authored
commit 21d17dd2 upstream. Current code set update bits for WM8753_LDAC and WM8753_RDAC twice, but missed setting update bits for WM8753_LADC and WM8753_RADC. I think it is a copy-paste bug in commit 776065 "ASoC: codecs: wm8753: Fix register cache incoherency". Signed-off-by:
Axel Lin <axel.lin@gmail.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Arnd Bergmann authored
commit eff919ac upstream. A recent conversion has introduced references to &pdev->dev, which does not actually exist in all the contexts it's used in. Replace this with card->dev where necessary, in order to let the driver build again. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
