- 07 Mar, 2011 40 commits
-
-
Dmitry Eremin-Solenikov authored
commit 4bfc4e25 upstream. Correct names for pxa AC97 DAI are pxa2xx-ac97 and pxa2xx-ac97-aux. Fix that for all PXA platforms. Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Eric Bénard authored
commit 43c63188 upstream. commit f0fba2ad included a mistake on the name of the platform in the snd_soc_dai_link structure. Signed-off-by:
Eric Bénard <eric@eukrea.com> Acked-by:
-
Yu-Chen Cho authored
commit e9036e33 upstream. Add the btusb.c blacklist [0489:e02c] for Atheros AR5BBU12 BT and add to ath3k.c supported this device. Signed-off-by:
Yu-Chen Cho <acho@novell.com> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by:
-
Oliver Neukum authored
commit 8efdd0cd upstream. Quirky dongles sometimes do not use the iso interface which causes a crash with runtime PM Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Yu-Chen Cho authored
commit 509e7861 upstream. Add the btusb.c blacklist [03f0:311d] for Atheros AR9285 Malbec BT and add to ath3k.c ath3-1.fw (md5:1211fa34c09e10ba48381586b7c3883d) supported this device. Signed-off-by:
-
Don Zickus authored
commit 299c5696 upstream. A customer of ours, complained that when setting the reset vector back to 0, it trashed other data and hung their box. They noticed when only 4 bytes were set to 0 instead of 8, everything worked correctly. Mathew pointed out: | | We're supposed to be resetting trampoline_phys_low and | trampoline_phys_high here, which are two 16-bit values. | Writing 64 bits is definitely going to overwrite space | that we're not supposed to be touching. | So limit the area modified to u32. Signed-off-by:
Don Zickus <dzickus@redhat.com> Acked-by:
Matthew Garrett <mjg@redhat.com> LKML-Reference: <1297139100-424-1-git-send-email-dzickus@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Jochen Friedrich authored
commit 9063f1f1 upstream. Call input_set_abs_params instead of manually setting absbit only. This fixes this oops: Unable to handle kernel NULL pointer dereference at virtual address 00000024 Internal error: Oops: 41b67017 [#1] CPU: 0 Not tainted (2.6.37 #4) pc : [<c016d1fc>] lr : [<00000000>] psr: 20000093 sp : c19e5f30 ip : c19e5e6c fp : c19e5f58 r10: 00000000 r9 : c19e4000 r8 : 00000003 r7 : 000001e4 r6 : 00000001 r5 : c1854400 r4 : 00000003 r3 : 00000018 r2 : 00000018 r1 : 00000018 r0 : c185447c Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: c1b6717f Table: c1b6717f DAC: 00000017 Stack: (0xc19e5f30 to 0xc19e6000) 5f20: 00000003 00000003 c1854400 00000013 5f40: 00000001 000001e4 000001c5 c19e5f80 c19e5f5c c016d5e8 c016cf5c 000001e4 5f60: c1854400 c18b5860 00000000 00000171 000001e4 c19e5fc4 c19e5f84 c01559a4 5f80: c016d584 c18b5868 00000000 c1bb5c40 c0035afc c18b5868 c18b5868 c1a55d54 5fa0: c18b5860 c0155750 00000013 00000000 00000000 00000000 c19e5ff4 c19e5fc8 5fc0: c0050174 c015575c 00000000 c18b5860 00000000 c19e5fd4 c19e5fd4 c1a55d54 5fe0: c00500f0 c003b464 00000000 c19e5ff8 c003b464 c00500fc 04000400 04000400 Backtrace: Function entered at [<c016cf50>] from [<c016d5e8>] Function entered at [<c016d578>] from [<c01559a4>] r8:000001e4 r7:00000171 r6:00000000 r5:c18b5860 r4:c1854400 Function entered at [<c0155750>] from [<c0050174>] Function entered at [<c00500f0>] from [<c003b464>] r6:c003b464 r5:c00500f0 r4:c1a55d54 Code: e59520fc e1a03286 e0433186 e0822003 (e592000c) >>PC; c016d1fc <input_handle_event+2ac/5a0> <===== Trace; c016cf50 <input_handle_event+0/5a0> Trace; c016d5e8 <input_event+70/88> Trace; c016d578 <input_event+0/88> Trace; c01559a4 <ucb1x00_thread+254/2dc> Trace; c0155750 <ucb1x00_thread+0/2dc> Trace; c0050174 <kthread+84/8c> Trace; c00500f0 <kthread+0/8c> Trace; c003b464 <do_exit+0/624> Signed-off-by:
Jochen Friedrich <jochen@scram.de> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
vwadekar@nvidia.com authored
commit 4b57018d upstream. tps6586 does not support burst writes. i2c writes have to be 1 byte at a time. Signed-off-by:
Varun Wadekar <vwadekar@nvidia.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 2949ad50 upstream. File position is not controlled, it may lead to overwrites of arbitrary kernel memory. Also the code may kfree() the same pointer multiple times. One more flaw is still present: if multiple processes open the file then all 3 static variables are shared, leading to various race conditions. They should be moved to file->private_data. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Reviewed-by:
WANG Cong <xiyou.wangcong@gmail.com> Reviewed-by:
Eugene Teo <eugeneteo@kernel.org> Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Dave Airlie authored
commit 19227561 upstream. This fixes CVE-2011-1013. Reported-by: Matthiew Herrb (OpenBSD X.org team) Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Tristan Ye authored
commit acf3bb00 upstream. Current refcounttree codes actually didn't writeback the new pages out in write-back mode, due to a bug of always passing a ZERO number of clusters to 'ocfs2_cow_sync_writeback', the patch tries to pass a proper one in. Signed-off-by:
Tristan Ye <tristan.ye@oracle.com> Signed-off-by:
Joel Becker <jlbec@evilplan.org> Signed-off-by:
-
Mark Fasheh authored
commit 52c303c5 upstream. Commit 2c442719 added some checks for proper heartbeat mode when the o2cb stack is running. Unfortunately, it didn't take into account that a userpsace stack could be running. Fix this by only doing the check if o2cb is in use. This patch allows userspace stacks to mount the fs again. Signed-off-by:
Mark Fasheh <mfasheh@suse.com> Signed-off-by:
-
David Henningsson authored
commit ebbd224c upstream. These two Dell machines have been reported working well with the ideapad model. BugLink: http://bugs.launchpad.net/bugs/723676 Tested-by:
David Chen <david.chen@canonical.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
David Henningsson authored
commit 30649676 upstream. This typo caused some microphone inputs not to be correctly initialized on VIA codecs. Reported-By:
Mark Goldstein <goldstein.mark@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 382225e6 upstream. When a USB audio device is disconnected, snd_usb_audio_disconnect() kills all audio URBs. At the same time, the application, after being notified of the disconnection, might close the device, in which case ALSA calls the .hw_free callback, which should free the URBs too. Commit de1b8b93 "[ALSA] Fix hang-up at disconnection of usb-audio" prevented snd_usb_hw_free() from freeing the URBs to avoid a hang that resulted from this race, but this introduced another race because the URB callbacks could now be executed after snd_usb_hw_free() has returned, and try to access already freed data. Fix the first race by introducing a mutex to serialize the disconnect callback and all PCM callbacks that manage URBs (hw_free and hw_params). Reported-and-tested-by:
Pierre-Louis Bossart <pierre-louis.bossart@intel.com> [CL: also serialize hw_params callback] Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
David Henningsson authored
commit 6da8b516 upstream. Conexant 506e/20590 has the same graph as the rest of the 5066 family. BugLink: http://bugs.launchpad.net/bugs/723672 Signed-off-by:
-
Felipe Balbi authored
commit ec95d35a upstream. MUSB is a non-standard host implementation which can handle all speeds with the same core. We need to set has_tt flag after commit d199c96d (USB: prevent buggy hubs from crashing the USB stack) in order for MUSB HCD to continue working. Signed-off-by:
Felipe Balbi <balbi@ti.com> Cc: Alan Stern <stern@rowland.harvard.edu> Tested-by:
Michael Jones <michael.jones@matrix-vision.de> Tested-by:
Alexander Holler <holler@ahsoftware.de> Signed-off-by:
-
Alan Stern authored
commit d199c96d upstream. If anyone comes across a high-speed hub that (by mistake or by design) claims to have no Transaction Translators, plugging a full- or low-speed device into it will cause the USB stack to crash. This patch (as1446) prevents the problem by ignoring such devices, since the kernel has no way to communicate with them. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Perry Neben <neben@vmware.com> Signed-off-by:
-
Luben Tuikov authored
commit 07194ab7 upstream. If the device isn't reset, the XHCI HCD sends SET ADDRESS to address 0 while the device is already in Addressed state, and the request is dropped on the floor as it is addressed to the default address. This sequence of events, which this patch fixes looks like this: usb_reset_and_verify_device() hub_port_init() hub_set_address() SET_ADDRESS to 0 with 1 usb_get_device_descriptor(udev, 8) usb_get_device_descriptor(udev, 18) descriptors_changed() --> goto re_enumerate: hub_port_logical_disconnect() kick_khubd() And then: hub_events() hub_port_connect_change() usb_disconnect() usb_disable_device() new device struct sets device state to Powered choose_address() hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout! The solution is to always reset the device in hub_port_init() to put it in a known state. Note from Sarah Sharp: This patch should be queued for stable trees all the way back to 2.6.34, since that was the first kernel that supported configured device reset. The code this patch touches has been there since 2.6.32, but the bug would never be hit before 2.6.34 because the xHCI driver would completely reject an attempt to reset a configured device under xHCI. Signed-off-by:
Luben Tuikov <ltuikov@yahoo.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Paul Zimmerman authored
commit bcd2fde0 upstream. The expression while (running_total < sg_dma_len(sg)) does not take into account that the remaining data length can be less than sg_dma_len(sg). In that case, running_total can end up being greater than the total data length, so an extra TRB is counted. Changing the expression to while (running_total < sg_dma_len(sg) && running_total < temp) fixes that. This patch should be queued for stable kernels back to 2.6.31. Signed-off-by:
Paul Zimmerman <paulz@synopsys.com> Signed-off-by:
-
Paul Zimmerman authored
commit 5807795b upstream. Calculations like running_total = TRB_MAX_BUFF_SIZE - (sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1)); if (running_total != 0) num_trbs++; are incorrect, because running_total can never be zero, so the if() expression will never be true. I think the intention was that running_total be in the range of 0 to TRB_MAX_BUFF_SIZE-1, not 1 to TRB_MAX_BUFF_SIZE. So adding a running_total &= TRB_MAX_BUFF_SIZE - 1; fixes the problem. This patch should be queued for stable kernels back to 2.6.31. Signed-off-by:
-
Paul Zimmerman authored
commit a2490187 upstream. This makes it easier to spot some problems, which will be fixed by the next patch in the series. Also change dev_dbg to dev_err in check_trb_math(), so any math errors will be visible even when running with debug disabled. Note: This patch changes the expressions containing "((1 << TRB_MAX_BUFF_SHIFT) - 1)" to use the equivalent "(TRB_MAX_BUFF_SIZE - 1)". No change in behavior is intended for those expressions. This patch should be queued for stable kernels back to 2.6.31. Signed-off-by:
-
Paul Zimmerman authored
commit 68e41c5d upstream. Change the BUGs in xhci_find_new_dequeue_state() to WARN_ONs, to avoid bringing down the box if one of them is hit This patch should be queued for stable kernels back to 2.6.31. Signed-off-by:
-
Andreas Herrmann authored
commit 7f74f8f2 upstream. On some SB800 systems polarity for IOAPIC pin2 is wrongly specified as low active by BIOS. This caused system hangs after resume from S3 when HPET was used in one-shot mode on such systems because a timer interrupt was missed (HPET signal is high active). For more details see: http://marc.info/?l=linux-kernel&m=129623757413868 Tested-by:
Manoj Iyer <manoj.iyer@canonical.com> Tested-by:
Andre Przywara <andre.przywara@amd.com> Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> LKML-Reference: <20110224145346.GD3658@alberich.amd.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 805bdaec upstream. Commit 074037ec (PM / Wakeup: Introduce wakeup source objects and event statistics (v3)) caused ACPI wakeup to only work if CONFIG_PM_SLEEP is set, but it also worked for CONFIG_PM_SLEEP unset before. This can be fixed by making device_set_wakeup_enable(), device_init_wakeup() and device_may_wakeup() work in the same way as before commit 074037ec when CONFIG_PM_SLEEP is unset. Reported-and-tested-by:
Justin Maggard <jmaggard10@gmail.com> Signed-off-by:
-
NeilBrown authored
commit 93b270f7 upstream. There are two cases when we call flush_disk. In one, the device has disappeared (check_disk_change) so any data will hold becomes irrelevant. In the oter, the device has changed size (check_disk_size_change) so data we hold may be irrelevant. In both cases it makes sense to discard any 'clean' buffers, so they will be read back from the device if needed. In the former case it makes sense to discard 'dirty' buffers as there will never be anywhere safe to write the data. In the second case it *does*not* make sense to discard dirty buffers as that will lead to file system corruption when you simply enlarge the containing devices. flush_disk calls __invalidate_devices. __invalidate_device calls both invalidate_inodes and invalidate_bdev. invalidate_inodes *does* discard I_DIRTY inodes and this does lead to fs corruption. invalidate_bev *does*not* discard dirty pages, but I don't really care about that at present. So this patch adds a flag to __invalidate_device (calling it __invalidate_device2) to indicate whether dirty buffers should be killed, and this is passed to invalidate_inodes which can choose to skip dirty inodes. flusk_disk then passes true from check_disk_change and false from check_disk_size_change. dm avoids tripping over this problem by calling i_size_write directly rathher than using check_disk_size_change. md does use check_disk_size_change and so is affected. This regression was introduced by commit 608aeef1 which causes check_disk_size_change to call flush_disk, so it is suitable for any kernel since 2.6.27. Acked-by:
Jeff Moyer <jmoyer@redhat.com> Cc: Andrew Patterson <andrew.patterson@hp.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
commit f0b4f7e2 upstream. Revert b821eaa5 and f3b99be1 When I wrote the first of these I had a wrong idea about the lifetime of 'struct block_device'. It can disappear at any time that the block device is not open if it falls out of the inode cache. So relying on the 'size' recorded with it to detect when the device size has changed and so we need to revalidate, is wrong. Rather, we really do need the 'changed' attribute stored directly in the mddev and set/tested as appropriate. Without this patch, a sequence of: mknod / open / close / unlink (which can cause a block_device to be created and then destroyed) will result in a rescan of the partition table and consequence removal and addition of partitions. Several of these in a row can get udev racing to create and unlink and other code can get confused. With the patch, the rescan is only performed when needed and so there are no races. This is suitable for any stable kernel from 2.6.35. Reported-by:
"Wojcik, Krzysztof" <krzysztof.wojcik@intel.com> Signed-off-by:
-
NeilBrown authored
commit da9cf505 upstream. blk_throtl_exit assumes that ->queue_lock still exists, so make sure that it does. To do this, we stop redirecting ->queue_lock to conf->device_lock and leave it pointing where it is initialised - __queue_lock. As the blk_plug functions check the ->queue_lock is held, we now take that spin_lock explicitly around the plug functions. We don't need the locking, just the warning removal. This is needed for any kernel with the blk_throtl code, which is which is 2.6.37 and later. Signed-off-by:
-
NeilBrown authored
commit 8f5f02c4 upstream. 'mdp' devices are md devices with preallocated device numbers for partitions. As such it is possible to mknod and open a partition before opening the whole device. this causes md_probe() to be called with a device number of a partition, which in-turn calls mddev_find with such a number. However mddev_find expects the number of a 'whole device' and does the wrong thing with partition numbers. So add code to mddev_find to remove the 'partition' part of a device number and just work with the 'whole device'. This patch addresses https://bugzilla.kernel.org/show_bug.cgi?id=28652 Reported-by: hkmaly@bigfoot.com Signed-off-by:
-
Namhyung Kim authored
commit 29723fcc upstream. When pfn_valid_within() failed 'iter' was incremented twice. Signed-off-by:
Namhyung Kim <namhyung@gmail.com> Reviewed-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Lei Xu authored
commit a2d6d2fa upstream. In linux rtc_time struct, tm_mon range is 0~11, tm_wday range is 0~6, while in RTC HW REG, month range is 1~12, day of the week range is 1~7, this patch adjusts difference of them. The efect of this bug was that most of month will be operated on as the next month by the hardware (When in Jan it maybe even worse). For example, if in May, software wrote 4 to the hardware, which handled it as April. Then the logic would be different between software and hardware, which would cause weird things to happen. Signed-off-by:
Lei Xu <B33228@freescale.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: john stultz <johnstul@us.ibm.com> Cc: Jack Lan <jack.lan@freescale.com> Signed-off-by:
-
Timo Warns authored
commit 294f6cf4 upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains a bug that causes a kernel oops on certain corrupted LDM partitions. A kernel subsystem seems to crash, because, after the oops, the kernel no longer recognizes newly connected storage devices. The patch changes ldm_parse_vmdb() to Validate the value of vblk_size. Signed-off-by:
Timo Warns <warns@pre-sense.de> Cc: Eugene Teo <eugeneteo@kernel.sg> Acked-by:
Richard Russon <ldm@flatcap.org> Cc: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
FUJITA Tomonori authored
commit fba99fa3 upstream. swiotlb's map_page wrongly calls panic() when it can't find a buffer fit for device's dma mask. It should return an error instead. Devices with an odd dma mask (i.e. under 4G) like b44 network card hit this bug (the system crashes): http://marc.info/?l=linux-kernel&m=129648943830106&w=2 If swiotlb returns an error, b44 driver can use the own bouncing mechanism. Reported-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Tested-by:
Arkadiusz Miskiewicz <arekm@maven.pl> Signed-off-by:
-
Davide Libenzi authored
commit 22bacca4 upstream. In several places, an epoll fd can call another file's ->f_op->poll() method with ep->mtx held. This is in general unsafe, because that other file could itself be an epoll fd that contains the original epoll fd. The code defends against this possibility in its own ->poll() method using ep_call_nested, but there are several other unsafe calls to ->poll elsewhere that can be made to deadlock. For example, the following simple program causes the call in ep_insert recursively call the original fd's ->poll, leading to deadlock: #include <unistd.h> #include <sys/epoll.h> int main(void) { int e1, e2, p[2]; struct epoll_event evt = { .events = EPOLLIN }; e1 = epoll_create(1); e2 = epoll_create(2); pipe(p); epoll_ctl(e2, EPOLL_CTL_ADD, e1, &evt); epoll_ctl(e1, EPOLL_CTL_ADD, p[0], &evt); write(p[1], p, sizeof p); epoll_ctl(e1, EPOLL_CTL_ADD, e2, &evt); return 0; } On insertion, check whether the inserted file is itself a struct epoll, and if so, do a recursive walk to detect whether inserting this file would create a loop of epoll structures, which could lead to deadlock. [nelhage@ksplice.com: Use epmutex to serialize concurrent inserts] Signed-off-by:
Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
Nelson Elhage <nelhage@ksplice.com> Reported-by:
-
Max Vozeler authored
commit 01446ef5 upstream. The access to pending_port was racy when two devices were being attached at the same time. Signed-off-by:
Max Vozeler <max@vozeler.com> Tested-by:
Mark Wehby <MWehby@luxotticaRetail.com> Signed-off-by:
-
Max Vozeler authored
commit 6d212153 upstream. There can be requests to enqueue URBs while we are shutting down a connection. Signed-off-by:
-
Max Vozeler authored
commit b92a5e23 upstream. If we never received a RET_UNLINK because the TCP connection broke the pending URBs still need to be unlinked and given back. Previously processes would be stuck trying to kill the URB even after the device was detached. Signed-off-by:
-
Max Vozeler authored
commit 7606ee8a upstream. This fixes an oops observed when reading status during removal of a device: [ 1706.648285] general protection fault: 0000 [#1] SMP [ 1706.648294] last sysfs file: /sys/devices/platform/vhci_hcd/status [ 1706.648297] CPU 1 [ 1706.648300] Modules linked in: binfmt_misc microcode fuse loop vhci_hcd(N) usbip(N) usbcore usbip_common_mod(N) rtc_core rtc_lib joydev dm_mirror dm_region_hash dm_log linear dm_snapshot xennet dm_mod ext3 mbcache jbd processor thermal_sys hwmon xenblk cdrom [ 1706.648324] Supported: Yes [ 1706.648327] Pid: 10422, comm: usbip Tainted: G N 2.6.32.12-0.7-xen #1 [ 1706.648330] RIP: e030:[<ffffffff801b10d5>] [<ffffffff801b10d5>] strnlen+0x5/0x40 [ 1706.648340] RSP: e02b:ffff8800a994dd30 EFLAGS: 00010286 [ 1706.648343] RAX: ffffffff80481ec1 RBX: 0000000000000000 RCX: 0000000000000002 [ 1706.648347] RDX: 00200d1d4f1c001c RSI: ffffffffffffffff RDI: 00200d1d4f1c001c [ 1706.648350] RBP: ffff880129a1c0aa R08: ffffffffa01901c4 R09: 0000000000000006 [ 1706.648353] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800a9a1c0ab [ 1706.648357] R13: 00200d1d4f1c001c R14: 00000000ffffffff R15: ffff880129a1c0aa [ 1706.648363] FS: 00007f2f2e9ca700(0000) GS:ffff880001018000(0000) knlGS:0000000000000000 [ 1706.648367] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1706.648370] CR2: 000000000071b048 CR3: 00000000b4b68000 CR4: 0000000000002660 [ 1706.648374] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1706.648378] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1706.648381] Process usbip (pid: 10422, threadinfo ffff8800a994c000, task ffff88007b170200) [ 1706.648385] Stack: [ 1706.648387] ffffffff801b28c9 0000000000000002 ffffffffa01901c4 ffff8800a9a1c0ab [ 1706.648391] <0> ffffffffa01901c6 ffff8800a994de08 ffffffff801b339b 0000000000000004 [ 1706.648397] <0> 0000000affffffff ffffffffffffffff 00000000000067c0 0000000000000000 [ 1706.648404] Call Trace: [ 1706.648413] [<ffffffff801b28c9>] string+0x39/0xe0 [ 1706.648419] [<ffffffff801b339b>] vsnprintf+0x1eb/0x620 [ 1706.648423] [<ffffffff801b3813>] sprintf+0x43/0x50 [ 1706.648429] [<ffffffffa018d719>] show_status+0x1b9/0x220 [vhci_hcd] [ 1706.648438] [<ffffffff8024a2b7>] dev_attr_show+0x27/0x60 [ 1706.648445] [<ffffffff80144821>] sysfs_read_file+0x101/0x1d0 [ 1706.648451] [<ffffffff800da4a7>] vfs_read+0xc7/0x130 [ 1706.648457] [<ffffffff800da613>] sys_read+0x53/0xa0 [ 1706.648462] [<ffffffff80007458>] system_call_fastpath+0x16/0x1b [ 1706.648468] [<00007f2f2de40f30>] 0x7f2f2de40f30 [ 1706.648470] Code: 66 0f 1f 44 00 00 48 83 c2 01 80 3a 00 75 f7 48 89 d0 48 29 f8 f3 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 85 f6 74 29 <80> 3f 00 74 24 48 8d 56 ff 48 89 f8 eb 0e 0f 1f 44 00 00 48 83 [ 1706.648507] RIP [<ffffffff801b10d5>] strnlen+0x5/0x40 [ 1706.648511] RSP <ffff8800a994dd30> [ 1706.649575] ---[ end trace b4eb72bf2e149593 ]--- Signed-off-by:
-
Roland Vossen authored
commit 6a3be6e6 upstream Solved a locking issue that resulted in driver crashes with the 43224 and 43225 chips. The problem has been reported on several fora. Root cause was two fold: hardware was being manipulated by two unsynchronized threads, and a scan operation could interfere with an ongoing dynamic calibration process. Fix was to invoke a lock on wl_ops_config() operation and to set internal flags when a scan operation is started and stopped. Please add this to the staging-linus branch. Reviewed-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
Roland Vossen <rvossen@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
commit d062d44a upstream The driver assumed it would receive skb packets from MAC80211 which are not cloned. To guard this assumption an assert was placed in the transmit routine. As of kernel 2.6.37 it turns out MAC80211 does pass skb packets that are cloned. The assert is also not needed as it does not lead to a failure state in our driver when the packet is cloned. Therefore the assert can safely be removed. > commit f8a0a781 > Author: Felix Fietkau <nbd@openwrt.org> > Date: Sat Dec 18 19:30:50 2010 +0100 > > mac80211: fix potentially redundant skb data copying > > When an skb is shared, it needs to be duplicated, along with its data > If the skb does not have enough headroom, using skb_copy might cause t > buffer to be copied twice (once by skb_copy and once by pskb_expand_he > Fix this by using skb_clone initially and letting ieee80211_skb_resize > out the rest. > > Signed-off-by: Felix Fietkau <nbd@openwrt.org> > Signed-off-by: John W. Linville <linville@tuxdriver.com> > Acked-by:
Brett Rudley <brudley@broadcom.com> Signed-off-by:
-
