- 15 May, 2014 40 commits
-
-
Joe Thornber authored
commit 5a32083d upstream. In theory copying the space map root can fail, but in practice it never does because we're careful to check what size buffer is needed. But make certain we're able to copy the space map roots before locking the superblock. Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Joe Thornber authored
commit a9d45396 upstream. The persistent-data library used by dm-thin, dm-cache, etc is transactional. If anything goes wrong, such as an io error when writing new metadata or a power failure, then we roll back to the last transaction. Atomicity when committing a transaction is achieved by: a) Never overwriting data from the previous transaction. b) Writing the superblock last, after all other metadata has hit the disk. This commit and the following commit ("dm: take care to copy the space map roots before locking the superblock") fix a bug associated with (b). When committing it was possible for the superblock to still be written in spite of an io error occurring during the preceeding metadata flush. With these commits we're careful not to take the write lock out on the superblock until after the metadata flush has completed. Change the transaction manager's semantics for dm_tm_commit() to assume all data has been flushed _before_ the single superblock that is passed in. As a prerequisite, split the block manager's block unlocking and flushing by simplifying dm_bm_flush_and_unlock() to dm_bm_flush(). Now the unlocking must be done separately. This issue was discovered by forcing io errors at the crucial time using dm-flakey. Signed-off-by:
-
Mike Snitzer authored
commit d132cc6d upstream. If the discard block size is larger than the cache block size we will not properly quiesce IO to a region that is about to be discarded. This results in a race between a cache migration where no copy is needed, and a write to an adjacent cache block that's within the same large discard block. Workaround this by limiting the discard_block_size to cache_block_size. Also limit the max_discard_sectors to cache_block_size. A more comprehensive fix that introduces range locking support in the bio_prison and proper quiescing of a discard range that spans multiple cache blocks is already in development. Reported-by:
Morgan Mears <Morgan.Mears@netapp.com> Signed-off-by:
Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by:
-
Giacomo Comes authored
commit 10b6ee4a upstream. The Dell XPS 8700 has a onboard Display port and HDMI port and no VGA port. The call intel_crt_init freeze the machine, so skip such call. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73559 Signed-off-by: Giacomo Comes <comes at naic.edu> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Dan Carpenter authored
commit b4c23305 upstream. We always put a NUL terminator one space past the end of the "vendor" buffer. Walter Harms also pointed out that this should just use kstrndup(). Fixes: 7d17c02a ('mtd: Add new SmartMedia/xD FTL') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Dan Carpenter authored
commit c69dbbf3 upstream. Instead of writing to "nand->reg + REG_FMICSR" we write to "REG_FMICSR" which is NULL and not a valid register. Fixes: 8bff82cb ('mtd: add nand support for w90p910 (v2)') Signed-off-by:
-
Herve Codina authored
commit 90445ff6 upstream. Crash detected on sam5d35 and its pmecc nand ecc controller. The problem was a call to chip->ecc.hwctl from nand_write_subpage_hwecc (nand_base.c) when we write a sub page. chip->ecc.hwctl function is not set when we are using PMECC controller. As a workaround, set NAND_NO_SUBPAGE_WRITE for PMECC controller in order to disable sub page access in nand_write_page. Signed-off-by:
Herve Codina <Herve.CODINA@celad.com> Acked-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
-
Mikulas Patocka authored
commit 6b0df682 upstream. The functions for data copying copyarea_foreward_8bpp and copyarea_backward_8bpp are buggy, they produce screen corruption. This patch fixes the functions and moves the logic to one function "copyarea_8bpp". For simplicity, the function only handles copying that is aligned on 8 pixes. If we copy an unaligned area, generic function cfb_copyarea is used. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Marek Vasut authored
commit a585f87c upstream. The scenario here is that someone calls enable_irq_wake() from somewhere in the code. This will result in the lockdep producing a backtrace as can be seen below. In my case, this problem is triggered when using the wl1271 (TI WlCore) driver found in drivers/net/wireless/ti/ . The problem cause is rather obvious from the backtrace, but let's outline the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(), which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq() calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not marked as recursive, lockdep will spew the stuff below. We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to fix the spew. ============================================= [ INFO: possible recursive locking detected ] 3.10.33-00012-gf06b763-dirty #61 Not tainted --------------------------------------------- kworker/0:1/18 is trying to acquire lock: (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88 but task is already holding lock: (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by kworker/0:1/18: #0: (events){.+.+.+}, at: [<c0036308>] process_one_work+0x134/0x4a4 #1: ((&fw_work->work)){+.+.+.}, at: [<c0036308>] process_one_work+0x134/0x4a4 #2: (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88 stack backtrace: CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61 Workqueue: events request_firmware_work_func [<c0013eb4>] (unwind_backtrace+0x0/0xf0) from [<c0011c74>] (show_stack+0x10/0x14) [<c0011c74>] (show_stack+0x10/0x14) from [<c005bb08>] (__lock_acquire+0x140c/0x1a64) [<c005bb08>] (__lock_acquire+0x140c/0x1a64) from [<c005c6a8>] (lock_acquire+0x9c/0x104) [<c005c6a8>] (lock_acquire+0x9c/0x104) from [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c00685f0>] (__irq_get_desc_lock+0x48/0x88) [<c00685f0>] (__irq_get_desc_lock+0x48/0x88) from [<c0068e78>] (irq_set_irq_wake+0x20/0xf4) [<c0068e78>] (irq_set_irq_wake+0x20/0xf4) from [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) from [<c0068cf4>] (set_irq_wake_real+0x30/0x44) [<c0068cf4>] (set_irq_wake_real+0x30/0x44) from [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) from [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) from [<c02be5e8>] (request_firmware_work_func+0x38/0x58) [<c02be5e8>] (request_firmware_work_func+0x38/0x58) from [<c0036394>] (process_one_work+0x1c0/0x4a4) [<c0036394>] (process_one_work+0x1c0/0x4a4) from [<c0036a4c>] (worker_thread+0x138/0x394) [<c0036a4c>] (worker_thread+0x138/0x394) from [<c003cb74>] (kthread+0xa4/0xb0) [<c003cb74>] (kthread+0xa4/0xb0) from [<c000ee00>] (ret_from_fork+0x14/0x34) wlcore: loaded Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Colin Ian King authored
commit 328e203f upstream. static code analysis from cppcheck reports: [drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:322]: (error) Uninitialized variable: packet_beacon packet_beacon is not initialized and hence packet_beacon contains garbage from the stack, so set it to false. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Larry Finger authored
commit 2610decd upstream. In commit f78bccd7 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8192se. Signed-off-by:
-
Larry Finger authored
commit a53268be upstream. In commit f78bccd7 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8192cu. Signed-off-by:
-
Larry Finger authored
commit 6b639271 upstream. In commit f78bccd7 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8188ee. Signed-off-by:
-
Larry Finger authored
commit bfc1010c upstream. In commit f78bccd7 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8723ae. Signed-off-by:
-
Jeff Layton authored
commit 4991a628 upstream. A fl->fl_break_time of 0 has a special meaning to the lease break code that basically means "never break the lease". knfsd uses this to ensure that leases don't disappear out from under it. Unfortunately, the code in __break_lease can end up passing this value to wait_event_interruptible as a timeout, which prevents it from going to sleep at all. This causes __break_lease to spin in a tight loop and causes soft lockups. Fix this by ensuring that we pass a minimum value of 1 as a timeout instead. Cc: J. Bruce Fields <bfields@fieldses.org> Reported-by:
Terry Barnaby <terry1@beam.ltd.uk> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Felix Fietkau authored
commit 3b3e0efb upstream. qi->tqi_readyTime is written directly to registers that expect microseconds as unit instead of TU. When setting the CABQ ready time, cur_conf->beacon_interval is in TU, so convert it to microseconds before passing it to ath9k_hw. This should hopefully fix some Tx DMA issues with buffered multicast frames in AP mode. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
commit 764152ff upstream. Their power value is initialized to zero. This patch fixes an issue where the configured power drops to the minimum value when AP_VLAN interfaces are created/removed. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 115b943a upstream. Jouni reported that when doing off-channel transmissions mixed with on-channel transmissions, the on-channel ones ended up on the off-channel in some cases. The reason for that is that during the refactoring of the off- channel code, I lost the part that stopped all activity and as a consequence the on-channel frames (including data frames) were no longer queued but would be transmitted on the temporary channel. Fix this by simply restoring the lost activity stop call. Fixes: 2eb278e0 ("mac80211: unify SW/offload remain-on-channel") Reported-by:
Jouni Malinen <j@w1.fi> Signed-off-by:
-
Johannes Berg authored
commit 1a1cb744 upstream. Since Stanislaw's patch removing the quiescing code, mac80211 had a race regarding suspend vs. authentication: as cfg80211 doesn't track authentication attempts, it can't abort them. Therefore the attempts may be kept running while suspending, which can lead to all kinds of issues, in at least some cases causing an error in iwlmvm firmware. Fix this by aborting the authentication attempt when suspending. Fixes: 12e7f517 ("mac80211: cleanup generic suspend/resume procedures") Signed-off-by:
-
Michael Braun authored
commit 112c44b2 upstream. commit de74a1d9 "mac80211: fix WPA with VLAN on AP side with ps-sta" fixed an issue where queued multicast packets would be sent out encrypted with the key of an other bss. commit "7cbf9d01" "mac80211: fix oops on mesh PS broadcast forwarding" essentially reverted it, because vif.type cannot be AP_VLAN due to the check to vif.type in ieee80211_get_buffered_bc before. As the later commit intended to fix the MESH case, fix it by checking for IFTYPE_AP instead of IFTYPE_AP_VLAN. Fixes: 7cbf9d01 ("mac80211: fix oops on mesh PS broadcast forwarding") Signed-off-by:
Michael Braun <michael-dev@fami-braun.de> Signed-off-by:
-
Johannes Berg authored
commit d2722f8b upstream. The bss struct might be freed in ieee80211_rx_bss_put(), so we shouldn't use it afterwards. Fixes: 817cee76 ("mac80211: track AP's beacon rate and give it to the driver") Signed-off-by:
-
Emmanuel Grumbach authored
commit 82e5a649 upstream. There is a flow in which we send the host command in SYNC mode, but we don't take priv->mutex. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1046495Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Martin K. Petersen authored
commit d121f7d0 upstream. Crucial/Micron M500 drives properly support queued DSM TRIM starting with firmware MU05. Update the blacklist so we only disable queued trim for older firmware releases. Early M550 series drives suffer from the same issue as M500. A bugfix firmware is in the pipeline but not ready yet. Until then, blacklist queued trim for M550. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Cc: Chris Samuel <chris@csamuel.org> Cc: Marc MERLIN <marc@merlins.org> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Alexander Gordeev authored
commit 2cf532f5 upstream. In multiple MSI mode all AHCI ports (including dummy) get assigned separate MSI vectors and (as result of execution pci_enable_msi_exact() function) separate IRQ numbers, (mapped to the MSI vectors). Therefore, although interrupts from dummy ports are not desired they are still enabled. We do not request IRQs for dummy ports, but that only means we do not assign AHCI-specific ISRs to corresponding IRQ numbers. As result, dummy port interrupts still could come and traverse all the way from the PCI device to the kernel, causing unnecessary overhead. This update disables IRQs for dummy ports and prevents the described issue. Signed-off-by:
Alexander Gordeev <agordeev@redhat.com> Signed-off-by:
David Milburn <dmilburn@redhat.com> Cc: linux-ide@vger.kernel.org Fixes: 5ca72c4f ("AHCI: Support multiple MSIs") Signed-off-by:
-
Dan Williams authored
commit 8a4aeec8 upstream. The AHCI spec allows implementations to issue commands in tag order rather than FIFO order: 5.3.2.12 P:SelectCmd HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1) or HBA selects the command to issue that has had the PxCI bit set to '1' longer than any other command pending to be issued. The result is that commands posted sequentially (time-wise) may play out of sequence when issued by hardware. This behavior has likely been hidden by drives that arrange for commands to complete in issue order. However, it appears recent drives (two from different vendors that we have found so far) inflict out-of-order completions as a matter of course. So, we need to take care to maintain ordered submission, otherwise we risk triggering a drive to fall out of sequential-io automation and back to random-io processing, which incurs large latency and degrades throughput. This issue was found in simple benchmarks where QD=2 seq-write performance was 30-50% *greater* than QD=32 seq-write performance. Tagging for -stable and making the change globally since it has a low risk-to-reward ratio. Also, word is that recent versions of an unnamed OS also does it this way now. So, drives in the field are already experienced with this tag ordering scheme. Cc: Dave Jiang <dave.jiang@intel.com> Cc: Ed Ciechanowski <ed.ciechanowski@intel.com> Reviewed-by:
Matthew Wilcox <matthew.r.wilcox@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
David Milburn authored
commit 9ae794ac upstream. System may crash in ahci_hw_interrupt() or ahci_thread_fn() when accessing the interrupt status in a port's private_data if the port is actually a DUMMY port. 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller <snip console output for linux-3.15-rc1> [ 9.352080] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x1 impl SATA mode [ 9.352084] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc [ 9.368155] Console: switching to colour frame buffer device 128x48 [ 9.439759] mgag200 0000:11:00.0: fb0: mgadrmfb frame buffer device [ 9.446765] mgag200 0000:11:00.0: registered panic notifier [ 9.470166] scsi1 : ahci [ 9.479166] scsi2 : ahci [ 9.488172] scsi3 : ahci [ 9.497174] scsi4 : ahci [ 9.506175] scsi5 : ahci [ 9.515174] scsi6 : ahci [ 9.518181] ata1: SATA max UDMA/133 abar m2048@0x95c00000 port 0x95c00100 irq 91 [ 9.526448] ata2: DUMMY [ 9.529182] ata3: DUMMY [ 9.531916] ata4: DUMMY [ 9.534650] ata5: DUMMY [ 9.537382] ata6: DUMMY [ 9.576196] [drm] Initialized mgag200 1.0.0 20110418 for 0000:11:00.0 on minor 0 [ 9.845257] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 9.865161] ata1.00: ATAPI: Optiarc DVD RW AD-7580S, FX04, max UDMA/100 [ 9.891407] ata1.00: configured for UDMA/100 [ 9.900525] scsi 1:0:0:0: CD-ROM Optiarc DVD RW AD-7580S FX04 PQ: 0 ANSI: 5 [ 10.247399] iTCO_vendor_support: vendor-support=0 [ 10.261572] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 10.269764] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS [ 10.301932] sd 0:2:0:0: [sda] 570310656 512-byte logical blocks: (291 GB/271 GiB) [ 10.317085] sd 0:2:0:0: [sda] Write Protect is off [ 10.328326] sd 0:2:0:0: [sda] Write cache: disabled, read cache: disabled, supports DPO and FUA [ 10.375452] BUG: unable to handle kernel NULL pointer dereference at 000000000000003c [ 10.384217] IP: [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci] [ 10.392101] PGD 0 [ 10.394353] Oops: 0000 [#1] SMP [ 10.397978] Modules linked in: sr_mod(+) cdrom sd_mod iTCO_wdt crc_t10dif iTCO_vendor_support crct10dif_common ahci libahci libata lpc_ich mfd_core mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm drm i2c_core megaraid_sas dm_mirror dm_region_hash dm_log dm_mod [ 10.426499] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1 #1 [ 10.433495] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011 [ 10.443886] task: ffffffff81906460 ti: ffffffff818f0000 task.ti: ffffffff818f0000 [ 10.452239] RIP: 0010:[<ffffffffa0133df0>] [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci] [ 10.462838] RSP: 0018:ffff880033c03d98 EFLAGS: 00010046 [ 10.468767] RAX: 0000000000a400a4 RBX: ffff880029a6bc18 RCX: 00000000fffffffa [ 10.476731] RDX: 00000000000000a4 RSI: ffff880029bb0000 RDI: ffff880029a6bc18 [ 10.484696] RBP: ffff880033c03dc8 R08: 0000000000000000 R09: ffff88002f800490 [ 10.492661] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000000 [ 10.500625] R13: ffff880029a6bd98 R14: 0000000000000000 R15: ffffc90000194000 [ 10.508590] FS: 0000000000000000(0000) GS:ffff880033c00000(0000) knlGS:0000000000000000 [ 10.517623] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 10.524035] CR2: 000000000000003c CR3: 00000000328ff000 CR4: 00000000000007b0 [ 10.531999] Stack: [ 10.534241] 0000000000000017 ffff880031ba7d00 000000000000005c ffff880031ba7d00 [ 10.542535] 0000000000000000 000000000000005c ffff880033c03e10 ffffffff810c2a1e [ 10.550827] ffff880031ae2900 000000008108fb4f ffff880031ae2900 ffff880031ae2984 [ 10.559121] Call Trace: [ 10.561849] <IRQ> [ 10.563994] [<ffffffff810c2a1e>] handle_irq_event_percpu+0x3e/0x1a0 [ 10.571309] [<ffffffff810c2bbd>] handle_irq_event+0x3d/0x60 [ 10.577631] [<ffffffff810c4fdd>] try_one_irq.isra.6+0x8d/0xf0 [ 10.584142] [<ffffffff810c5313>] note_interrupt+0x173/0x1f0 [ 10.590460] [<ffffffff810c2a8e>] handle_irq_event_percpu+0xae/0x1a0 [ 10.597554] [<ffffffff810c2bbd>] handle_irq_event+0x3d/0x60 [ 10.603872] [<ffffffff810c5727>] handle_edge_irq+0x77/0x130 [ 10.610199] [<ffffffff81014b8f>] handle_irq+0xbf/0x150 [ 10.616040] [<ffffffff8109ff4e>] ? vtime_account_idle+0xe/0x50 [ 10.622654] [<ffffffff815fca1a>] ? atomic_notifier_call_chain+0x1a/0x20 [ 10.630140] [<ffffffff816038cf>] do_IRQ+0x4f/0xf0 [ 10.635490] [<ffffffff815f8aed>] common_interrupt+0x6d/0x6d [ 10.641805] <EOI> [ 10.643950] [<ffffffff8149ca9f>] ? cpuidle_enter_state+0x4f/0xc0 [ 10.650972] [<ffffffff8149ca98>] ? cpuidle_enter_state+0x48/0xc0 [ 10.657775] [<ffffffff8149cb47>] cpuidle_enter+0x17/0x20 [ 10.663807] [<ffffffff810b0070>] cpu_startup_entry+0x2c0/0x3d0 [ 10.670423] [<ffffffff815dfcc7>] rest_init+0x77/0x80 [ 10.676065] [<ffffffff81a60f47>] start_kernel+0x40f/0x41a [ 10.682190] [<ffffffff81a60941>] ? repair_env_string+0x5c/0x5c [ 10.688799] [<ffffffff81a60120>] ? early_idt_handlers+0x120/0x120 [ 10.695699] [<ffffffff81a605ee>] x86_64_start_reservations+0x2a/0x2c [ 10.702889] [<ffffffff81a60733>] x86_64_start_kernel+0x143/0x152 [ 10.709689] Code: a0 fc ff 85 c0 8b 4d d4 74 c3 48 8b 7b 08 89 ca 48 c7 c6 60 66 13 a0 31 c0 e8 9d 70 28 e1 8b 4d d4 eb aa 0f 1f 84 00 00 00 00 00 <45> 8b 64 24 3c 48 89 df e8 23 47 4c e1 41 83 fc 01 19 c0 48 83 [ 10.731470] RIP [<ffffffffa0133df0>] ahci_hw_interrupt+0x100/0x130 [libahci] [ 10.739441] RSP <ffff880033c03d98> [ 10.743333] CR2: 000000000000003c [ 10.747032] ---[ end trace b6e82636970e2690 ]--- [ 10.760190] Kernel panic - not syncing: Fatal exception in interrupt [ 10.767291] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) Cc: Alexander Gordeev <agordeev@redhat.com> Cc: Tejun Heo <tj@kernel.org> Signed-of-by:
-
Thomas Petazzoni authored
commit cc6ca302 upstream. This reverts commit e3a8786c. While this commit allows to use the mvneta driver as a module on some configurations, it breaks other configurations even if mvneta is used built-in. This breakage is due to the fact that on some RGMII platforms, the PCS bit has to be set, and on some other platforms, it has to be cleared. At the moment, we lack informations to know exactly the significance of this bit (the datasheet only says "enables PCS"), and so we can't produce a patch that will work on all platforms at this point. And since this change is breaking the network completely for many users, it's much better to revert it for now. We'll come back later with a proper fix that takes into account all platforms. Basically: * Armada XP GP is configured as RGMII-ID, and needs the PCS bit to be set. * Armada 370 Mirabox is configured as RGMII-ID, and needs the PCS bit to be cleared. And at the moment, we don't know how to make the distinction between those two cases. One hint is that the Armada XP GP appears in fact to be using a QSGMII connection with the PHY (Quad-SGMII), but configuring it as SGMII doesn't work, while RGMII-ID works. This needs more investigation, but in the mean time, let's unbreak the network for all those users. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by:
Arnaud Ebalard <arno@natisbad.org> Reported-by:
Alexander Reuter <Alexander.Reuter@gmx.net> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=73401Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rafał Miłecki authored
commit 12cd43c6 upstream. Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b functions isn't safe. On my machine it causes delayed (!) CPU exception: Disabling lock debugging due to kernel taint mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f mce: [Hardware Error]: TSC 164083803dc mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Processor context corrupt Kernel panic - not syncing: Fatal machine check on current CPU Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Acked-by:
-
Mikulas Patocka authored
commit 43751a1b upstream. This patch fixes the hardware cursor on mach64 when font width is not a multiple of 8 pixels. If you load such a font, the cursor is expanded to the next 8-byte boundary and a part of the next character after the cursor is not visible. For example, when you load a font with 12-pixel width, the cursor width is 16 pixels and when the cursor is displayed, 4 pixels of the next character are not visible. The reason is this: atyfb_cursor is called with proper parameters to load an image that is 12-pixel wide. However, the number is aligned on the next 8-pixel boundary on the line "unsigned int width = (cursor->image.width + 7) >> 3;" and the whole function acts as it is was loading a 16-pixel image. This patch fixes it so that the value written to the framebuffer is padded with 0xaaaa (the transparent pattern) when the image size it not a multiple of 8 pixels. The transparent pattern causes that the cursor will not interfere with the next character. Signed-off-by:
-
Mikulas Patocka authored
commit c29dd869 upstream. This patch fixes mach64 to use unaligned access to the font bitmap. This fixes unaligned access warning on sparc64 when 14x8 font is loaded. On x86(64), unaligned access is handled in hardware, so both functions le32_to_cpup and get_unaligned_le32 perform the same operation. On RISC machines, unaligned access is not handled in hardware, so we better use get_unaligned_le32 to avoid the unaligned trap and warning. Signed-off-by:
-
Mikulas Patocka authored
commit a772d473 upstream. When X11 is running and the user switches back to console, the card modifies the content of registers M_MACCESS and M_PITCH in periodic intervals. This patch fixes it by restoring the content of these registers before issuing any accelerator command. Signed-off-by:
-
Mikulas Patocka authored
commit 00a9d699 upstream. The function cfb_copyarea is buggy when the copy operation is not aligned on long boundary (4 bytes on 32-bit machines, 8 bytes on 64-bit machines). How to reproduce: - use x86-64 machine - use a framebuffer driver without acceleration (for example uvesafb) - set the framebuffer to 8-bit depth (for example fbset -a 1024x768-60 -depth 8) - load a font with character width that is not a multiple of 8 pixels note: the console-tools package cannot load a font that has width different from 8 pixels. You need to install the packages "kbd" and "console-terminus" and use the program "setfont" to set font width (for example: setfont Uni2-Terminus20x10) - move some text left and right on the bash command line and you get a screen corruption To expose more bugs, put this line to the end of uvesafb_init_info: info->flags |= FBINFO_HWACCEL_COPYAREA | FBINFO_READS_FAST; - Now framebuffer console will use cfb_copyarea for console scrolling. You get a screen corruption when console is scrolled. This patch is a rewrite of cfb_copyarea. It fixes the bugs, with this patch, console scrolling in 8-bit depth with a font width that is not a multiple of 8 pixels works fine. The cfb_copyarea code was very buggy and it looks like it was written and never tried with non-8-pixel font. Signed-off-by:
-
Vineet Gupta authored
commit 8aa9e85a upstream. There was a very small race window where resume to kernel mode from a Exception Path (or pure kernel mode which is true for most of ARC exceptions anyways), was not disabling interrupts in restore_regs, clobbering the exception regs Anton found the culprit call flow (after many sleepless nights) | 1. we got a Trap from user land | 2. started to service it. | 3. While doing some stuff on user-land memory (I think it is padzero()), | we got a DataTlbMiss | 4. On return from it we are taking "resume_kernel_mode" path | 5. NEED_RESHED is not set, so we go to "return from exception" path in | restore regs. | 6. there seems to be IRQ happening Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Cc: Anton Kolesov <Anton.Kolesov@synopsys.com> Cc: Francois Bedard <Francois.Bedard@synopsys.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Richard Weinberger authored
commit d345ea28 upstream. The symbol is an orphan, get rid of it. Fixes: 7d0857a5 ("ARC: [SMP] Disallow RTSC") Signed-off-by:
Richard Weinberger <richard@nod.at> Acked-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
-
Jarkko Nikula authored
commit 2697e4fb upstream. Commit 9e1fda4ae158 ("ASoC: dapm: Implement mixer input auto-disable") is trying to free the widget it allocated by snd_soc_dapm_new_control() call in dapm_kcontrol_data_alloc() by adding kfree(data->widget) to dapm_kcontrol_free(). This is causing a widget double free with auto-disabled DAPM kcontrols in sound card unregistration because widgets are already freed before dapm_kcontrol_free() is called. Reason for that is all widgets are added into dapm->card->widgets list in snd_soc_dapm_new_control() and freed in dapm_free_widgets() during execution of snd_soc_dapm_free(). Now snd_soc_dapm_free() calls for different DAPM contexts happens before snd_card_free() call from where the call chain to dapm_kcontrol_free() begins: soc_cleanup_card_resources() soc_remove_dai_links() soc_remove_link_dais() snd_soc_dapm_free(&cpu_dai->dapm) soc_remove_link_components() soc_remove_platform() snd_soc_dapm_free(&platform->dapm) soc_remove_codec() snd_soc_dapm_free(&codec->dapm) snd_soc_dapm_free(&card->dapm) snd_card_free() snd_card_do_free() snd_device_free_all() snd_device_free() snd_ctl_dev_free() snd_ctl_remove() snd_ctl_free_one() dapm_kcontrol_free() This wasn't making harm with ordinary DAPM kcontrols since data->widget is NULL for them. Fixes: 9e1fda4ae158 (ASoC: dapm: Implement mixer input auto-disable) Signed-off-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Martin Schwidefsky authored
commit 6e0de817 upstream. The A register needs to be initialized to zero in the prolog if the first instruction of the BPF program is BPF_S_LDX_B_MSH to prevent leaking the content of %r5 to user space. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Sebastian Ott authored
commit 06cd7a87 upstream. Using a notification type mask for the store event information chsc is unsupported on some firmware levels. Retry SEI with that mask set to zero (which is the old way of requesting only channel subsystem related events). Reported-and-tested-by:
Stefan Haberland <stefan.haberland@de.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
-
Michael Neuling authored
commit e6b8fd02 upstream. We can't take an IRQ when we're about to do a trechkpt as our GPR state is set to user GPR values. We've hit this when running some IBM Java stress tests in the lab resulting in the following dump: cpu 0x3f: Vector: 700 (Program Check) at [c000000007eb3d40] pc: c000000000050074: restore_gprs+0xc0/0x148 lr: 00000000b52a8184 sp: ac57d360 msr: 8000000100201030 current = 0xc00000002c500000 paca = 0xc000000007dbfc00 softe: 0 irq_happened: 0x00 pid = 34535, comm = Pooled Thread # R00 = 00000000b52a8184 R16 = 00000000b3e48fda R01 = 00000000ac57d360 R17 = 00000000ade79bd8 R02 = 00000000ac586930 R18 = 000000000fac9bcc R03 = 00000000ade60000 R19 = 00000000ac57f930 R04 = 00000000f6624918 R20 = 00000000ade79be8 R05 = 00000000f663f238 R21 = 00000000ac218a54 R06 = 0000000000000002 R22 = 000000000f956280 R07 = 0000000000000008 R23 = 000000000000007e R08 = 000000000000000a R24 = 000000000000000c R09 = 00000000b6e69160 R25 = 00000000b424cf00 R10 = 0000000000000181 R26 = 00000000f66256d4 R11 = 000000000f365ec0 R27 = 00000000b6fdcdd0 R12 = 00000000f66400f0 R28 = 0000000000000001 R13 = 00000000ada71900 R29 = 00000000ade5a300 R14 = 00000000ac2185a8 R30 = 00000000f663f238 R15 = 0000000000000004 R31 = 00000000f6624918 pc = c000000000050074 restore_gprs+0xc0/0x148 cfar= c00000000004fe28 dont_restore_vec+0x1c/0x1a4 lr = 00000000b52a8184 msr = 8000000100201030 cr = 24804888 ctr = 0000000000000000 xer = 0000000000000000 trap = 700 This moves tm_recheckpoint to a C function and moves the tm_restore_sprs into that function. It then adds IRQ disabling over the trechkpt critical section. It also sets the TEXASR FS in the signals code to ensure this is never set now that we explictly write the TM sprs in tm_recheckpoint. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Anton Blanchard authored
commit 422b9b96 upstream. I noticed this when testing setarch. No, we don't magically support a big endian userspace on a little endian kernel. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Tyler Stachecki authored
commit af61e27c upstream. On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which in turn calls pci_disable_device if the device is enabled prior to suspending. However, _scsih_suspend also calls pci_disable_device itself. Thus, in the event that the device is enabled prior to suspending, pci_disable_device will be called twice. This patch removes the duplicate call to pci_disable_device in _scsi_suspend as it is both unnecessary and results in a kernel oops. Signed-off-by:
Tyler Stachecki <tstache1@binghamton.edu> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
