- 20 Dec, 2013 5 commits
-
-
Takashi Iwai authored
commit 3690739b upstream. AD1986A codec is a pretty old codec and has really many hidden restrictions. One of such is that each DAC is dedicated to certain pin although there are possible connections. Currently, the generic parser tries to assign individual DACs as much as possible, and this lead to two bad situations: connections where the sound actually doesn't work, and connections conflicting other channels. We may fix this by trying to find the best connections more harder, but as of now, it's easier to give some hints for paired DAC/pin connections and honor them if available, since such a hint is needed only for specific codecs (right now only AD1986A, and there will be unlikely any others in future). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stefano Panella authored
commit 932e9dec upstream. When running a 32bit kernel the hda_intel driver is still reporting a 64bit dma_mask if the HW supports it. From sound/pci/hda/hda_intel.c: /* allow 64bit DMA address if supported by H/W */ if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64))) pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64)); else { pci_set_dma_mask(pci, DMA_BIT_MASK(32)); pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32)); } which means when there is a call to dma_alloc_coherent from snd_malloc_dev_pages a machine address bigger than 32bit can be returned. This can be true in particular if running the 32bit kernel as a pv dom0 under the Xen Hypervisor or PAE on bare metal. The problem is that when calling setup_bdle to program the BLE the dma_addr_t returned from the dma_alloc_coherent is wrongly truncated from snd_sgbuf_get_addr if running a 32bit kernel: static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab, size_t offset) { struct snd_sg_buf *sgbuf = dmab->private_data; dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr; addr &= PAGE_MASK; return addr + offset % PAGE_SIZE; } where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr. Without this patch the HW will fetch the 32bit truncated address, which is not the one obtained from dma_alloc_coherent and will result to a non working audio but can corrupt host memory at a random location. The current patch apply to v3.13-rc3-74-g6c843f5 Signed-off-by:
Stefano Panella <stefano.panella@citrix.com> Reviewed-by:
Frediano Ziglio <frediano.ziglio@citrix.com> Signed-off-by:
-
Takashi Iwai authored
commit 6733cf57 upstream. snd_pcm_uframes_t is defined as unsigned long so it would take different sizes depending on 32 or 64bit architectures. As we don't want this ABI incompatibility, and there is no real 64bit user yet, let's make it the fixed size with __u32. Also bump the protocol version number to 0.1.2. Acked-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Mag authored
commit ed06349f upstream. Signed-off-by:
Nol "Mag" Archinova <magissia@magissia.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Jim Quinlan authored
commit f86f55d3 upstream. The BMIPS5000 (Zephyr) processor utilizes instruction speculation. A stale misprediction address in either the JTB or the CRS may trigger a prefetch inside a region that is currently being used by a DMA engine, which is not IO-coherent. This prefetch will fetch a line into the scache, and that line will soon become stale (ie wrong) during/after the DMA. Mayhem ensues. In dma-default.c, the r10000 is handled as a special case in the same way that we want to handle Zephyr. So we generalize the exception cases into a function, and include Zephyr as one of the processors that needs this special care. Signed-off-by:
Jim Quinlan <jim2101024@gmail.com> Cc: linux-mips@linux-mips.org Cc: cernekee@gmail.com Patchwork: https://patchwork.linux-mips.org/patch/5776/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Cc: John Ulvr <julvr@broadcom.com> Signed-off-by:
-
- 12 Dec, 2013 35 commits
-
-
Greg Kroah-Hartman authored
-
Tom Lendacky authored
commit 389a5390 upstream. Now that scatterwalk_sg_chain sets the chain pointer bit the sg_page call in scatterwalk_sg_next hits a BUG_ON when CONFIG_DEBUG_SG is enabled. Use sg_chain_ptr instead of sg_page on a chain entry. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Arnaud Ebalard authored
commit 12b69a59 upstream. Various Marvell datasheets advertise second PCIe unit of mv78230 flavour of Armada XP as x4/quad x1 capable. This second unit is in fact only x1 capable. This patch fixes current mv78230 .dtsi to reflect that, i.e. makes 1.0 the second interface (instead of 2.0 at the moment). This was successfully tested on a mv78230-based ReadyNAS 2120 platform with a x1 device (FL1009 XHCI controller) connected to this second interface. Signed-off-by:
Arnaud Ebalard <arno@natisbad.org> Acked-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Arnaud Ebalard authored
commit 2163e61c upstream. mv78260 flavour of Marvell Armada XP SoC has 3 PCIe units. The two first units are both x4 and quad x1 capable. The third unit is only x4 capable. This patch fixes mv78260 .dtsi to reflect those capabilities. Signed-off-by:
-
Alan Cox authored
commit 9aa5b018 upstream. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=60772Signed-off-by:
Alan Cox <alan@linux.intel.com> Reported-by:
Leho Kraav <leho@kraav.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
David Cluytens authored
commit 3b59d16c upstream. Signed-off-by:
David Cluytens <david.cluytens@gmail.com> Signed-off-by:
-
Colin Leitner authored
commit 711fbdfb upstream. This patch removes an erroneous check of CSIZE, which made it impossible to set CS5. Compiles clean, but couldn't test against hardware. Signed-off-by:
Colin Leitner <colin.leitner@gmail.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Colin Leitner authored
commit 78692cc3 upstream. This patch removes an erroneous check of CSIZE, which made it impossible to set CS5. Compiles clean, but couldn't test against hardware. Signed-off-by:
-
Colin Leitner authored
commit 8704211f upstream. FTDI UARTs support only 7 or 8 data bits. Until now the ftdi_sio driver would only report this limitation for CS6 to dmesg and fail to reflect this fact to tcgetattr. This patch reverts the unsupported CSIZE setting and reports the fact with less severance to dmesg for both CS5 and CS6. To test the patch it's sufficient to call stty -F /dev/ttyUSB0 cs5 which will succeed without the patch and report an error with the patch applied. As an additional fix this patch ensures that the control request will always include a data bit size. Signed-off-by:
-
Colin Leitner authored
commit a3132499 upstream. This patch fixes the CS5 setting on the PL2303 USB-to-serial devices. CS5 has a value of 0 and the CSIZE setting has been skipped altogether by the enclosing if. Tested on 3.11.6 and the scope shows the correct output after the fix has been applied. Tagged to be added to stable, because it fixes a user visible driver bug and is simple enough to backport easily. Signed-off-by:
-
Tomas Winkler authored
commit 76a96359 upstream. And Lynx Point H Refresh and Wildcat Point LP device ids. Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Tomas Winkler authored
commit 838b3a6d upstream. add missing device id for LPT based work station Signed-off-by:
-
Tom Gundersen authored
commit dfaaed08 upstream. Moust (if not all) modern software, including X, uses /dev/eventX rather than the legacy /dev/mouseX devices. It therefore makes sense for general-purpose (distro) kernels to use MOUSEDV=m (or even n), so let's drop the EXPERT=y requirement. Signed-off-by:
Tom Gundersen <teg@jklm.no> Signed-off-by:
-
Tom Gundersen authored
commit bcd26230 upstream. There is plenty of consumer hardware (e.g., mac books) that does not use AT keyboards or PS/2 mice. It therefore makes sense for distro kernels to build the related drivers as modules to avoid loading them on hardware that does not need them. As such, these options should no longer be protected by EXPERT. Moreover, building these drivers as modules gets rid of the following ugly error during boot: [ 2.337745] i8042: PNP: No PS/2 controller found. Probing ports directly. [ 3.439537] i8042: No controller found Signed-off-by:
-
Joonyoung Shim authored
commit 674470d9 upstream. In struct gen_pool_chunk, end_addr means the end address of memory chunk (inclusive), but in the implementation it is treated as address + size of memory chunk (exclusive), so it points to the address plus one instead of correct ending address. The ending address of memory chunk plus one will cause overflow on the memory chunk including the last address of memory map, e.g. when starting address is 0xFFF00000 and size is 0x100000 on 32bit machine, ending address will be 0x100000000. Use correct ending address like starting address + size - 1. [akpm@linux-foundation.org: add comment to struct gen_pool_chunk:end_addr] Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
-
AceLan Kao authored
commit 684524d3 upstream. BugLink: http://bugs.launchpad.net/bugs/1180881 This device needs to be added to the quirks list with HID_QUIRK_NO_INIT_REPORTS, otherwise it causes 10 seconds timeout during report initialization. [12431.828467] hid-multitouch 0003:0457:1013.0475: usb_submit_urb(ctrl) failed: -1 [12431.828507] hid-multitouch 0003:0457:1013.0475: timeout initializing reports Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
AceLan Kao authored
commit 8171a67d upstream. BugLink: http://bugs.launchpad.net/bugs/1180881 Synaptics large touchscreen doesn't support some of the report request while initializing. The unspoorted request will make the device unreachable, and will lead to the following usb_submit_urb() function call timeout. So, add the IDs into HID_QUIRK_NO_INIT_REPORTS quirk. Signed-off-by:
-
Ivan Vecera authored
commit 85aec73d upstream. If build_skb fails the memory associated with the ring buffer is freed but the ri->data member is not zeroed in this case. This causes a double-free of this memory in tg3_free_rings->... path. The patch moves this block after setting ri->data to NULL. It would be nice to fix this bug also in stable >= v3.4 trees. Cc: Nithin Nayak Sujir <nsujir@broadcom.com> Cc: Michael Chan <mchan@broadcom.com> Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Acked-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Emmanuel Grumbach authored
commit f6b12952 upstream. Since we set IEEE80211_HW_QUEUE_CONTROL, we can let mac80211 do the queue assignement and don't need to override its decisions. While reassiging the same values is harmless of course, it triggered a WARNING when iwlwifi and mac80211 came to different conclusions. This happened when mac80211 set IEEE80211_TX_CTL_SEND_AFTER_DTIM, but didn't route the packet to the cab_queue because no stations were asleep. iwlwifi should not override mac80211's decicions for offchannel packets and packets to be sent after DTIM, but it should override mac80211's decision for AMPDUs since we have a special queue for them. So for AMPDU, we still override info->hw_queue by the AMPDU queue. This avoids: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2531 at drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883() Modules linked in: CPU: 0 PID: 2531 Comm: hostapd Not tainted 3.12.0-rc5+ #1 Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013 0000000000000000 0000000000000009 ffffffff8189aa62 0000000000000000 ffffffff8105a4f2 ffff880058339a48 ffffffff815f8a04 0000000000000000 ffff8800560097b0 0000000000000208 0000000000000000 ffff8800561a9e5e Call Trace: [<ffffffff8189aa62>] ? dump_stack+0x41/0x51 [<ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90 [<ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883 [<ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883 [<ffffffff818a0040>] ? put_cred+0x15/0x15 [<ffffffff815f6db4>] ? iwlagn_mac_tx+0x19/0x2f [<ffffffff8186cc45>] ? __ieee80211_tx+0x226/0x29b [<ffffffff8186e6bd>] ? ieee80211_tx+0xa6/0xb5 [<ffffffff8186e98b>] ? ieee80211_monitor_start_xmit+0x1e9/0x204 [<ffffffff8171ce5f>] ? dev_hard_start_xmit+0x271/0x3ec [<ffffffff817351ac>] ? sch_direct_xmit+0x66/0x164 [<ffffffff8171d1bf>] ? dev_queue_xmit+0x1e5/0x3c8 [<ffffffff817fac5a>] ? packet_sendmsg+0xac5/0xb3d [<ffffffff81709a09>] ? sock_sendmsg+0x37/0x52 [<ffffffff810f9e0c>] ? __do_fault+0x338/0x36b [<ffffffff81713820>] ? verify_iovec+0x44/0x94 [<ffffffff81709e63>] ? ___sys_sendmsg+0x1f1/0x283 [<ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae [<ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187 [<ffffffff811173b1>] ? kmem_cache_free+0x44/0x84 [<ffffffff81132c22>] ? dentry_kill+0x13d/0x149 [<ffffffff81132f6f>] ? dput+0xe5/0xef [<ffffffff81136e04>] ? fget_light+0x2e/0x7c [<ffffffff8170ae62>] ? __sys_sendmsg+0x39/0x57 [<ffffffff818a7e39>] ? system_call_fastpath+0x16/0x1b ---[ end trace 1b3eb79359c1d1e6 ]--- Reported-by:
Sander Eikelenboom <linux@eikelenboom.it> Reviewed-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Martin K. Petersen authored
commit 54b2b50c upstream. Some host adapters do not pass commands through to the target disk directly. Instead they provide an emulated target which may or may not accurately report its capabilities. In some cases the physical device characteristics are reported even when the host adapter is processing commands on the device's behalf. This can lead to adapter firmware hangs or excessive I/O errors. This patch disables WRITE SAME for devices connected to host adapters that provide an emulated target. Driver writers can disable WRITE SAME by setting the no_write_same flag in the host adapter template. [jejb: fix up rejections due to eh_deadline patch] Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
H. Peter Anvin authored
commit 5551a34e upstream. Always pass in the -mno-sse argument, regardless if -preferred-stack-boundary is supported. We never want to generate SSE instructions in the kernel unless we *really* know what we're doing. According to H. J. Lu, any version of gcc new enough that we support it at all should handle the -mno-sse option, so just add it unconditionally. Reported-by:
Kevin B. Smith <kevin.b.smith@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: H. J. Lu <hjl.tools@gmail.com> Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.orgSigned-off-by:
-
Shawn Landden authored
commit d3f7d56a upstream. Commit 35f9c09f (tcp: tcp_sendpages() should call tcp_push() once) added an internal flag MSG_SENDPAGE_NOTLAST, similar to MSG_MORE. algif_hash, algif_skcipher, and udp used MSG_MORE from tcp_sendpages() and need to see the new flag as identical to MSG_MORE. This fixes sendfile() on AF_ALG. v3: also fix udp Cc: Tom Herbert <therbert@google.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: David S. Miller <davem@davemloft.net> Reported-and-tested-by:
Shawn Landden <shawnlandden@gmail.com> Original-patch: Richard Weinberger <richard@nod.at> Signed-off-by:
Shawn Landden <shawn@churchofgit.com> Signed-off-by:
-
Laxman Dewangan authored
commit ac01810c upstream. When the system enters suspend, it disables all interrupts in suspend_device_irqs(), including the interrupts marked EARLY_RESUME. On the resume side things are different. The EARLY_RESUME interrupts are reenabled in sys_core_ops->resume and the non EARLY_RESUME interrupts are reenabled in the normal system resume path. When suspend_noirq() failed or suspend is aborted for any other reason, we might omit the resume side call to sys_core_ops->resume() and therefor the interrupts marked EARLY_RESUME are not reenabled and stay disabled forever. To solve this, enable all irqs unconditionally in irq_resume() regardless whether interrupts marked EARLY_RESUMEhave been already enabled or not. This might try to reenable already enabled interrupts in the non failure case, but the only affected platform is XEN and it has been confirmed that it does not cause any side effects. [ tglx: Massaged changelog. ] Signed-off-by:
Laxman Dewangan <ldewangan@nvidia.com> Acked-by-and-tested-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Pavel Machek <pavel@ucw.cz> Cc: <ian.campbell@citrix.com> Cc: <rjw@rjwysocki.net> Cc: <len.brown@intel.com> Cc: <gregkh@linuxfoundation.org> Link: http://lkml.kernel.org/r/1385388587-16442-1-git-send-email-ldewangan@nvidia.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Hong Zhiguo authored
Update of blkg_stat and blkg_rwstat may happen in bh context. While u64_stats_fetch_retry is only preempt_disable on 32bit UP system. This is not enough to avoid preemption by bh and may read strange 64 bit value. commit 2c575026 upstream. Signed-off-by:
Hong Zhiguo <zhiguohong@tencent.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Matt Wilson authored
commit 14883a75 upstream. Commit f62805f1 introduced a bug where lazy MMU mode isn't exited if a m2p_add/remove_override call fails. Acked-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by:
David Vrabel <david.vrabel@citrix.com> Reviewed-by:
Anthony Liguori <aliguori@amazon.com> Signed-off-by:
Matt Wilson <msw@amazon.com> Signed-off-by:
-
Helge Deller authored
commit 0576da2c upstream. locale-gen on Debian showed a strange problem on parisc: mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000 mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument) Basically it was just trying to re-mmap() a file at the same address which it was given by a previous mmap() call. But this remapping failed with EINVAL. The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't included the mapping-based offset when we verified the alignment of the given fixed address against the offset which we calculated it in the previous call. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Liu Gang authored
commit 1aeef303 upstream. For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But the code may give the wrong status of GPIOs defined as input under some scenarios: 1. If some pins were configured as inputs and were asserted high before booting the kernel, the shadow data has been initialized with those pin values. 2. Some pins have been configured as output first and have been set to the high value, then reconfigured as input. The above cases will make the shadow data for those input pins to be set to high. Then reading the pin status will always return high even if the actual pin status is low. The code should eliminate the effects of the shadow data to the input pins, and the status of those pins should be read directly from GPDAT. Acked-by:
Scott Wood <scottwood@freescale.com> Acked-by:
Anatolij Gustschin <agust@denx.de> Signed-off-by:
Liu Gang <Gang.Liu@freescale.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Martin Schwidefsky authored
commit 4be77398 upstream. Since commit 1e75fa8b (time: Condense timekeeper.xtime into xtime_sec - merged in v3.6), there has been an problem with the error accounting in the timekeeping code, such that when truncating to nanoseconds, we round up to the next nsec, but the balancing adjustment to the ntp_error value was dropped. This causes 1ns per tick drift forward of the clock. In 3.7, this logic was isolated to only GENERIC_TIME_VSYSCALL_OLD architectures (s390, ia64, powerpc). The fix is simply to balance the accounting and to subtract the added nanosecond from ntp_error. This allows the internal long-term clock steering to keep the clock accurate. While this fix removes the regression added in 1e75fa8b, the ideal solution is to move away from GENERIC_TIME_VSYSCALL_OLD and use the new VSYSCALL method, which avoids entirely the nanosecond granular rounding, and the resulting short-term clock adjustment oscillation needed to keep long term accurate time. [ jstultz: Many thanks to Martin for his efforts identifying this subtle bug, and providing the fix. ] Originally-from: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Paul Turner <pjt@google.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1385149491-20307-1-git-send-email-john.stultz@linaro.orgSigned-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Trond Myklebust authored
commit c97cf606 upstream. If the DELEGRETURN errors out with something like NFS4ERR_BAD_STATEID then there is no recovery possible. Just quit without returning an error. Also, note that the client must not assume that the NFSv4 lease has been renewed when it sees an error on DELEGRETURN. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Linus Walleij authored
commit a0c20fb0 upstream. After commit e9e4ea74 "net: smc91x: dont't use SMC_outw for fixing up halfword-aligned data" The Versatile SMSC LAN91C111 is crashing like this: ------------[ cut here ]------------ kernel BUG at /home/linus/linux/drivers/net/ethernet/smsc/smc91x.c:599! Internal error: Oops - BUG: 0 [#1] ARM Modules linked in: CPU: 0 PID: 43 Comm: udhcpc Not tainted 3.13.0-rc1+ #24 task: c6ccfaa0 ti: c6cd0000 task.ti: c6cd0000 PC is at smc_hardware_send_pkt+0x198/0x22c LR is at smc_hardware_send_pkt+0x24/0x22c pc : [<c01be324>] lr : [<c01be1b0>] psr: 20000013 sp : c6cd1d08 ip : 00000001 fp : 00000000 r10: c02adb08 r9 : 00000000 r8 : c6ced802 r7 : c786fba0 r6 : 00000146 r5 : c8800000 r4 : c78d6000 r3 : 0000000f r2 : 00000146 r1 : 00000000 r0 : 00000031 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: 06cf4000 DAC: 00000015 Process udhcpc (pid: 43, stack limit = 0xc6cd01c0) Stack: (0xc6cd1d08 to 0xc6cd2000) 1d00: 00000010 c8800000 c78d6000 c786fba0 c78d6000 c01be868 1d20: c01be7a4 00004000 00000000 c786fba0 c6c12b80 c0208554 000004d0 c780fc60 1d40: 00000220 c01fb734 00000000 00000000 00000000 c6c9a440 c6c12b80 c78d6000 1d60: c786fba0 c6c9a440 00000000 c021d1d8 00000000 00000000 c6c12b80 c78d6000 1d80: c786fba0 00000001 c6c9a440 c02087f8 c6c9a4a0 00080008 00000000 00000000 1da0: c78d6000 c786fba0 c78d6000 00000138 00000000 00000000 00000000 00000000 1dc0: 00000000 c027ba74 00000138 00000138 00000001 00000010 c6cedc00 00000000 1de0: 00000008 c7404400 c6cd1eec c6cd1f14 c067a73c c065c0b8 00000000 c067a740 1e00: 01ffffff 002040d0 00000000 00000000 00000000 00000000 00000000 ffffffff 1e20: 43004400 00110022 c6cdef20 c027ae8c c6ccfaa0 be82d65c 00000014 be82d3cc 1e40: 00000000 00000000 00000000 c01f2870 00000000 00000000 00000000 c6cd1e88 1e60: c6ccfaa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1e80: 00000000 00000000 00000031 c7802310 c7802300 00000138 c7404400 c0771da0 1ea0: 00000000 c6cd1eec c7800340 00000138 be82d65c 00000014 be82d3cc c6cd1f08 1ec0: 00000014 00000000 c7404400 c7404400 00000138 c01f4628 c78d6000 00000000 1ee0: 00000000 be82d3cc 00000138 c6cd1f08 00000014 c6cd1ee4 00000001 00000000 1f00: 00000000 00000000 00080011 00000002 06000000 ffffffff 0000ffff 00000002 1f20: 06000000 ffffffff 0000ffff c00928c8 c065c520 c6cd1f58 00000003 c009299c 1f40: 00000003 c065c520 c7404400 00000000 c7404400 c01f2218 c78106b0 c7441cb0 1f60: 00000000 00000006 c06799fc 00000000 00000000 00000006 00000000 c01f3ee0 1f80: 00000000 00000000 be82d678 be82d65c 00000014 00000001 00000122 c00139c8 1fa0: c6cd0000 c0013840 be82d65c 00000014 00000006 be82d3cc 00000138 00000000 1fc0: be82d65c 00000014 00000001 00000122 00000000 00000000 00018cb1 00000000 1fe0: 00003801 be82d3a8 0003a0c7 b6e9af08 60000010 00000006 00000000 00000000 [<c01be324>] (smc_hardware_send_pkt+0x198/0x22c) from [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8) [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8) from [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc) [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc) from [<c021d1d8>] (sch_direct_xmit+0x94/0x18c) [<c021d1d8>] (sch_direct_xmit+0x94/0x18c) from [<c02087f8>] (dev_queue_xmit+0x238/0x42c) [<c02087f8>] (dev_queue_xmit+0x238/0x42c) from [<c027ba74>] (packet_sendmsg+0xbe8/0xd28) [<c027ba74>] (packet_sendmsg+0xbe8/0xd28) from [<c01f2870>] (sock_sendmsg+0x84/0xa8) [<c01f2870>] (sock_sendmsg+0x84/0xa8) from [<c01f4628>] (SyS_sendto+0xb8/0xdc) [<c01f4628>] (SyS_sendto+0xb8/0xdc) from [<c0013840>] (ret_fast_syscall+0x0/0x2c) Code: e3130002 1a000001 e3130001 0affffcd (e7f001f2) ---[ end trace 81104fe70e8da7fe ]--- Kernel panic - not syncing: Fatal exception in interrupt This is because the macro operations in smc91x.h defined for Versatile are missing SMC_outsw() as used in this commit. The Versatile needs and uses the same accessors as the other platforms in the first if(...) clause, just switch it to using that and we have one problem less to worry about. This includes a hunk of a patch from Will Deacon fixin the other 32bit platforms as well: Innokom, Ramses, PXA, PCM027. Checkpatch complains about spacing, but I have opted to follow the style of this .h-file. Cc: Russell King <linux@arm.linux.org.uk> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Eric Miao <eric.y.miao@gmail.com> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Stephen M. Cameron authored
commit 88bf6d62 upstream. A return value of 1 is interpreted as an error. See pci_driver. in local_pci_probe(). If you're wondering how this ever could have worked, it's because it used to be the case that only return values less than zero were interpreted as failure. But even in the current kernel if the driver registers its various entry points with the kernel, and then returns a value which is interpreted as failure, those registrations aren't undone, so the driver still mostly works. However, the driver's remove function wouldn't be called on rmmod, and pci power management functions wouldn't work. In the case of Smart Array, since it has a battery backed cache (or else no cache) even if the driver is not shut down properly as long as there is no outstanding i/o, nothing too bad happens, which is why it took so long to notice. Requesting backport to stable because the change to pci-driver.c which requires driver probe functions to return 0 occurred between 2.6.35 and 2.6.36 (the pci power management breakage) and again between 3.7 and 3.8 (pci_dev->driver getting set to NULL in local_pci_probe() preventing driver remove function from being called on rmmod.) Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Stephen M. Cameron authored
commit 2e311fba upstream. We inadvertantly discarded the scsi status for aborted commands. For some commands (e.g. reads from tape drives) these can't be retried, and if we discarded the scsi status, the scsi mid layer couldn't notice anything was wrong and the error was not reported. Signed-off-by:
-
Dan Williams authored
commit ae5fbae0 upstream. Since commit 110dd8f1 "[SCSI] libsas: fix scr_read/write users and update the libata documentation" we have been passing pmp=1 and is_cmd=0 to ata_tf_to_fis(). Praveen reports that eSATA attached drives do not discover correctly. His investigation found that the BIOS was passing pmp=0 while Linux was passing pmp=1 and failing to discover the drives. Update libsas to follow the libata example of pulling the pmp setting from the ata_link and correct is_cmd to be 1 since all tf's submitted through ->qc_issue are commands. Presumably libsas lldds do not care about is_cmd as they have sideband mechanisms to perform link management. http://marc.info/?l=linux-scsi&m=138179681726990 [jejb: checkpatch fix] Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Reported-by:
Praveen Murali <pmurali@logicube.com> Tested-by:
-
James Bottomley authored
commit a1470c7b upstream. Bug report from: wenxiong@linux.vnet.ibm.com The issue is happened in dual controller configuration. We got the sysfs warnings when rmmod the ipr module. enclosure_unregister() in drivers/msic/enclosure.c, call device_unregister() for each componment deivce, device_unregister() ->device_del()->kobject_del() ->sysfs_remove_dir(). In sysfs_remove_dir(), set kobj->sd = NULL. For each componment device, enclosure_component_release()->enclosure_remove_links()->sysfs_remove_link() in which checking kobj->sd again, it has been set as NULL when doing device_unregister. So we saw all these sysfs WARNING. Tested-by: wenxiong@linux.vnet.ibm.com Signed-off-by:
-
Vijaya Mohan Guvva authored
commit 22a08538 upstream. This patch fixes a crash when tried setting symbolic name for an offline vport through sysfs. Crash is due to uninitialized pointer lport->ns, which gets initialized only on linkup (port online). Signed-off-by:
Vijaya Mohan Guvva <vmohan@brocade.com> Signed-off-by:
-
