- 05 Aug, 2011 34 commits
-
-
Larry Finger authored
commit 1288aa4e upstream. A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the same condition twice. The problem was found using cppcheck-1.49, and the proper fix was verified against the pre-mac80211 version of the code. Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Luben Tuikov authored
commit 5911e963 upstream. If expander discovery fails (sas_discover_expander()), remove the expander from the port device list (sas_ex_discover_expander()), before freeing it. Else the list is corrupted and, e.g., when we attempt to send SMP commands to other devices, the kernel oopses. Signed-off-by:
Luben Tuikov <ltuikov@yahoo.com> Reviewed-by:
Jack Wang <jack_wang@usish.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Bart Van Assche authored
commit fd1b6c4a upstream. SCSI scanning of a channel:id:lun triplet in Linux works as follows (function scsi_scan_target() in drivers/scsi/scsi_scan.c): - If lun == SCAN_WILD_CARD, send a REPORT LUNS command to the target and process the result. - If lun != SCAN_WILD_CARD, send an INQUIRY command to the LUN corresponding to the specified channel:id:lun triplet to verify whether the LUN exists. So a SCSI driver must either take the channel and target id values in account in its quecommand() function or it should declare that it only supports one channel and one target id. Currently the ib_srp driver does neither. As a result scanning the SCSI bus via e.g. rescan-scsi-bus.sh causes many duplicate SCSI devices to be created. For each 0:0:L device, several duplicates are created with the same LUN number and with (C:I) != (0:0). Fix this by declaring that the ib_srp driver only supports one channel and one target id. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
David Dillow <dillowda@ornl.gov> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Stefan Richter authored
commit 93b37905 upstream. Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events to be read(2) by the client. The get_info ioctl is practically always issued right away after open, hence this condition only occurs if the client opens during a bus reset, especially during a rapid series of bus resets. The problem with this condition is twofold: - These bus reset events carry the (as yet undocumented) @closure value of 0. But it is not the kernel's place to choose closures; they are privat to the client. E.g., this 0 value forced from the kernel makes it unsafe for clients to dereference it as a pointer to a closure object without NULL pointer check. - It is impossible for clients to determine the relative order of bus reset events from get_info ioctl(2) versus those from read(2), except in one way: By comparison of closure values. Again, such a procedure imposes complexity on clients and reduces freedom in use of the bus reset closure. So, change the ABI to suppress queuing of bus reset events before the first FW_CDEV_IOC_GET_INFO ioctl was issued by the client. Note, this ABI change cannot be version-controlled. The kernel cannot distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO ioctl. We will try to back-merge this change into currently maintained stable/ longterm series, and we only document the new behaviour. The old behavior is now considered a kernel bug, which it basically is. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: <stable@kernel.org>
-
Stefan Richter authored
commit d873d794 upstream. On Jun 27 Linus Torvalds wrote: > The correct error code for "I don't understand this ioctl" is ENOTTY. > The naming may be odd, but you should think of that error value as a > "unrecognized ioctl number, you're feeding me random numbers that I > don't understand and I assume for historical reasons that you tried to > do some tty operation on me". [...] > The EINVAL thing goes way back, and is a disaster. It predates Linux > itself, as far as I can tell. You'll find lots of man-pages that have > this line in it: > > EINVAL Request or argp is not valid. > > and it shows up in POSIX etc. And sadly, it generally shows up > _before_ the line that says > > ENOTTY The specified request does not apply to the kind of object > that the descriptor d references. > > so a lot of people get to the EINVAL, and never even notice the ENOTTY. [...] > At least glibc (and hopefully other C libraries) use a _string_ that > makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for > device" So let's correct this in the <linux/firewire-cdev.h> ABI while it is still young, relative to distributor adoption. Side note: We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch, but also on _IOC_SIZE mismatch. An ioctl with an unsupported size of argument structure can be seen as an unsupported version of that ioctl. Signed-off-by:
-
Ben Hutchings authored
commit 67ae7cf1 upstream. Some drivers (ab)use the ethtool_ops::get_regs operation to expose only a hardware revision ID. Commit a77f5db3 ('ethtool: Allocate register dump buffer with vmalloc()') had the side-effect of breaking these, as vmalloc() returns a null pointer for size=0 whereas kmalloc() did not. For backward-compatibility, allow zero-length dumps again. Reported-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Guo-Fu Tseng authored
commit 94c5b41b upstream. This patch add the missing dma_unmap(). Which solved the critical issue of system freeze on heavy load. Michal Miroslaw's rejected patch: [PATCH v2 10/46] net: jme: convert to generic DMA API Pointed out the issue also, thank you Michal. But the fix was incorrect. It would unmap needed address when low memory. Got lots of feedback from End user and Gentoo Bugzilla. https://bugs.gentoo.org/show_bug.cgi?id=373109 Thank you all. :) Signed-off-by:
Guo-Fu Tseng <cooldavid@cooldavid.org> Acked-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
-
Roland Vossen authored
commit 37c962d1 upstream. Every few minutes, this message would appear in syslog: ieee80211 ph0: wl_ops_bss_info_changed: BSS idle: true (implement) The message has been deleted, the driver requires no special action on this particular event (). See: https://bugzilla.kernel.org/show_bug.cgi?id=38162Reported-by:
David Hill <hilld@binarystorm.net> Signed-off-by:
Roland Vossen <rvossen@broadcom.com> Reviewed-by:
Arend van Spriel <arend@broadcom.com> Reviewed-by:
Franky Lin <frankyl@broadcom.com> Signed-off-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de>
-
Pavel Shilovsky authored
commit f5bc1e75 upstream. commit fec11dd9 caused a regression when we have already mounted //server/share/a and want to mount //server/share/a/b. The problem is that lookup_one_len calls __lookup_hash with nd pointer as NULL. Then __lookup_hash calls do_revalidate in the case when dentry exists and we end up with NULL pointer deference in cifs_d_revalidate: if (nd->flags & LOOKUP_RCU) return -ECHILD; Fix this by checking nd for NULL. Signed-off-by:
Pavel Shilovsky <piastryyy@gmail.com> Reviewed-by:
Shirish Pargaonkar <shirishp@us.ibm.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Senthil Balasubramanian authored
commit 0472ade0 upstream. Decryping frames on key_miss handling shouldn't be done for Michael MIC failed frames as h/w would have already decrypted such frames successfully anyway. Also leaving CRC and PHY error(where the frame is going to be dropped anyway), we are left to prcoess Decrypt error for which s/w decrypt is selected anway and so having key_miss as a separate check doesn't serve anything. So making key_miss handling mutually exlusive with other RX status handling makes much more sense. This patch addresses an issue with STA not reporting MIC failure events resulting in STA being disconnected immediately. Signed-off-by:
Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by:
-
Kalle Valo authored
commit 98ab5c77 upstream. When ath6kl module was resumed while a scan was ongoing, for example during suspend, the driver would crash in ar6k_cfg80211_scanComplete_event(): [26581.586440] Call Trace: [26581.586440] [<f99ffeda>] ? ar6k_cfg80211_scanComplete_event+0xaa/0xaa [ath6kl] [26581.586440] [<f9a0a020>] wmi_iterate_nodes+0xb/0xd [ath6kl] [26581.586440] [<f99ffe78>] ar6k_cfg80211_scanComplete_event+0x48/0xaa [ath6kl] [26581.586440] [<f9a038ae>] ar6000_close+0x77/0x7e [ath6kl] [26581.586440] [<c139c25d>] __dev_close_many+0x87/0xab [26581.586440] [<c139c30a>] dev_close_many+0x54/0xab [26581.586440] [<c139c437>] rollback_registered_many+0xa5/0x19e [26581.586440] [<c139c595>] rollback_registered+0x23/0x2f [26581.586440] [<c139c5ed>] unregister_netdevice_queue+0x4c/0x69 [26581.586440] [<c139c6b2>] unregister_netdev+0x18/0x1f [26581.586440] [<f9a00d4c>] ar6000_destroy+0xf8/0x115 [ath6kl] [26581.586440] [<f9a0c765>] ar6k_cleanup_module+0x20/0x29 [ath6kl] [26581.586440] [<c1062843>] sys_delete_module+0x181/0x1d9 [26581.586440] [<c105876b>] ? lock_release_holdtime+0x2b/0xcd [26581.586440] [<c10b55dc>] ? sys_munmap+0x3b/0x42 [26581.586440] [<c14a99dc>] ? restore_all+0xf/0xf [26581.586440] [<c14aeb6c>] sysenter_do_call+0x12/0x32 [26581.586440] Code: 89 53 6c 75 07 89 d8 e8 c0 ff ff ff 89 f0 e8 2c f2 a9 c7 5b 5e 5d c3 55 89 e5 57 56 53 89 c3 83 ec 08 89 55 f0 8d 78 04 89 4d ec <8b> b0 b8 00 00 00 46 89 b0 b8 00 00 00 89 f8 e8 ae ed a9 c7 8b Fix the function not to iterate nodes when the scan is aborted. The nodes are already freed when the module is being unloaded. Patch "ath6kl: Fix a kernel panic furing suspend/resume" tried to fix this already but it wasn't enough as a pointer was still used even after the null check. This patch removes the null check entirely as the wmi structure is not accessed anymore during module unload. Also fix a bug where the status was checked as a bitfield with '&' operator. But it's not a bitfield, just a regular (enum like) value. Signed-off-by:
-
Kalle Valo authored
commit b42a7b1b upstream. Drivers should not request firmware during resume. Fix ath6kl to cache the firmware instead. Signed-off-by:
-
Mark Brown authored
commit 7be4ba24 upstream. Since quite a few drivers are not managing to flag the cache as needing to be resynced after suspend and it's a reasonable thing to do flag the cache as needing sync automatically when suspending. The expectation is that systems will mainly only keep the CODEC powered when doing audio through the CODEC so we won't actually suspend the device anyway; drivers which want to can override this behaviour when they resume. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Rajashekhara, Sudhakar authored
commit 3012f43e upstream. According to DM365 voice codec data sheet at [1], before starting recording or playback, ADC/DAC modules should follow a reset and enable cycle. Writing a 1 to the ADC/DAC bit in the register resets the module and clearing the bit to 0 will enable the module. But the driver seems to be doing the reverse of it. [1] http://focus.ti.com/lit/ug/sprufi9b/sprufi9b.pdfSigned-off-by:
Rajashekhara, Sudhakar <sudhakar.raj@ti.com> Acked-by:
-
Rajashekhara, Sudhakar authored
commit 82d1d521 upstream. In davinci_vcif_trigger() function, a break() statement was missing causing the davinci_vcif_stop() function to be called as a fallback after calling davinci_vcif_start(). Signed-off-by:
-
Igor Grinberg authored
commit 6c7b3ea5 upstream. While in sleep mode the CS# and other V3020 RTC GPIOs must be driven high, otherwise V3020 RTC fails to keep the right time in sleep mode. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Uwe Kleine-König authored
commit e57ee017 upstream. Using __SPIN_LOCK_UNLOCKED for a dynamically allocated lock is wrong and breaks the build with PREEMPT_RT_FULL. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Andrew Chew <achew@nvidia.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Thomas Gleixner authored
commit 431e2bcc upstream. Due to the hrtimer self rearming mode a user can DoS the machine simply because it's starved by hrtimer events. The RTC hrtimer is self rearming. We really need to limit the frequency to something sensible. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Thomas Gleixner authored
commit b830ac1d upstream. Ben reported a lockup related to rtc. The lockup happens due to: CPU0 CPU1 rtc_irq_set_state() __run_hrtimer() spin_lock_irqsave(&rtc->irq_task_lock) rtc_handle_legacy_irq(); spin_lock(&rtc->irq_task_lock); hrtimer_cancel() while (callback_running); So the running callback never finishes as it's blocked on rtc->irq_task_lock. Use hrtimer_try_to_cancel() instead and drop rtc->irq_task_lock while waiting for the callback. Fix this for both rtc_irq_set_state() and rtc_irq_set_freq(). Signed-off-by:
Ben Greear <greearb@candelatech.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Thomas Gleixner authored
commit 2c4f57d1 upstream. The code checks the correctness of the parameters, but unconditionally arms/disarms the hrtimer. The result is that a random task might arm/disarm rtc timer and surprise the real owner by either generating events or by stopping them. Signed-off-by:
-
Ajay Kumar Gupta authored
commit 3c5fec75 upstream. Restoring the missing INDEX register value in musb_restore_context(). Without this suspend resume functionality is broken with offmode enabled. Acked-by:
Anand Gadiyar <gadiyar@ti.com> Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Alan Stern authored
commit 004c1968 upstream. This patch (as1477) fixes a problem affecting a few types of EHCI controller. Contrary to what one might expect, these controllers automatically stop their internal frame counter when no ports are enabled. Since ehci-hcd currently relies on the frame counter for determining when it should unlink QHs from the async schedule, those controllers run into trouble: The frame counter stops and the QHs never get unlinked. Some systems have also experienced other problems traced back to commit b9638011 (USB: ehci-hcd unlink speedups), which made the original switch from using the system clock to using the frame counter. It never became clear what the reason was for these problems, but evidently it is related to use of the frame counter. To fix all these problems, this patch more or less reverts that commit and goes back to using the system clock. But this can't be done cleanly because other changes have since been made to the scan_async() subroutine. One of these changes involved the tricky logic that tries to avoid rescanning QHs that have already been seen when the scanning loop is restarted, which happens whenever an URB is given back. Switching back to clock-based unlinks would make this logic even more complicated. Therefore the new code doesn't rescan the entire async list whenever a giveback occurs. Instead it rescans only the current QH and continues on from there. This requires the use of a separate pointer to keep track of the next QH to scan, since the current QH may be unlinked while the scanning is in progress. That new pointer must be global, so that it can be adjusted forward whenever the _next_ QH gets unlinked. (uhci-hcd uses this same trick.) Simplification of the scanning loop removes a level of indentation, which accounts for the size of the patch. The amount of code changed is relatively small, and it isn't exactly a reversion of the b9638011 commit. This fixes Bugzilla #32432. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Matej Kenda <matejken@gmail.com> Signed-off-by:
-
Alan Stern authored
commit 6ea12a04 upstream. The NVIDIA series of OHCI controllers continues to be troublesome. A few people using the MCP67 chipset have reported that even with the most recent kernels, the OHCI controller fails to handle new connections and spams the system log with "unable to enumerate USB port" messages. This is different from the other problems previously reported for NVIDIA OHCI controllers, although it is probably related. It turns out that the MCP67 controller does not like to be kept in the RESET state very long. After only a few seconds, it decides not to work any more. This patch (as1479) changes the PCI initialization quirk code so that NVIDIA controllers are switched into the SUSPEND state after 50 ms of RESET. With no interrupts enabled and all the downstream devices reset, and thus unable to send wakeup requests, this should be perfectly safe (even for non-NVIDIA hardware). The removal code in ohci-hcd hasn't been changed; it will still leave the controller in the RESET state. As a result, if someone unloads ohci-hcd and then reloads it, the controller won't work again until the system is rebooted. If anybody complains about this, the removal code can be updated similarly. This fixes Bugzilla #22052. Tested-by:
-
K. Y. Srinivasan authored
commit 5c5781b3 upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
Hank Janssen <hjanssen@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
commit 2dfde964 upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. Signed-off-by:
-
K. Y. Srinivasan authored
commit 46d2eb6d upstream. On some loaded windows hosts, we have discovered that the host may not respond to guest requests within the specified time (one second) as evidenced by the guest timing out. Fix this problem by increasing the timeout to 5 seconds. It may be useful to apply this patch to the 3.0 kernel as well. the 3.0 kernel as well. Signed-off-by:
-
Vasiliy Kulikov authored
commit 819cbb12 upstream. driver_name and board_name are pointers to strings, not buffers of size COMEDI_NAMELEN. Copying COMEDI_NAMELEN bytes of a string containing less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Signed-off-by:
-
Larry Finger authored
commit 1c50bf7e upstream. There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and RTL8192SE. The method of distinguishing them is by the revision ID at offset 0x8 of the PCI configuration space. If the value is 0x10, then the device uses rtl8192se for a driver. Signed-off-by:
-
Tobias Klauser authored
commit 8547d4cc upstream. When unbinding a device on the host which was still attached on the client, I got a NULL pointer dereference on the client. This turned out to be due to kthread_stop() being called on an already dead kthread. Here is how I was able to reproduce the problem: server:# usbip bind -b 1-2 client:# usbip attach -h server -b 1-2 server:# usbip unbind -b 1-2 This patch fixes the problem by checking the kthread before attempting to kill it, as it is done on the opposite side in stub_shutdown_connection(). Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Herbert Xu authored
commit 17dd759c upstream. Currently skb_gro_header_slow unconditionally resets frag0 and frag0_len. However, when we can't pull on the skb this leaves the GRO fields in an inconsistent state. This patch fixes this by only resetting those fields after the pskb_may_pull test. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
stephen hemminger authored
commit 0c03150e upstream. A bridge topology with three systems: +------+ +------+ | A(2) |--| B(1) | +------+ +------+ \ / +------+ | C(3) | +------+ What is supposed to happen: * bridge with the lowest ID is elected root (for example: B) * C detects that A->C is higher cost path and puts in blocking state What happens. Bridge with lowest id (B) is elected correctly as root and things start out fine initially. But then config BPDU doesn't get transmitted from A -> C. Because of that the link from A-C is transistioned to the forwarding state. The root cause of this is that the configuration messages is generated with bogus message age, and dropped before sending. In the standardmessage_age is supposed to be: the time since the generation of the Configuration BPDU by the Root that instigated the generation of this Configuration BPDU. Reimplement this by recording the timestamp (age + jiffies) when recording config information. The old code incorrectly used the time elapsed on the ageing timer which was incorrect. See also: https://bugzilla.vyatta.com/show_bug.cgi?id=7164Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Shawn Guo authored
commit 803862a6 upstream. The function esdhc_readl_le intends to clear bit SDHCI_CARD_PRESENT, when the card detect gpio tells there is no card. But it does not clear the bit actually. The patch gives a fix on that. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Acked-by:
Wolfram Sang <w.sang@pengutronix.de> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Manoj Iyer authored
commit 15bed0f2 upstream. Ricoh 1180:e823 does not recognize certain types of SD/MMC cards, as reported at http://launchpad.net/bugs/773524. Lowering the SD base clock frequency from 200Mhz to 50Mhz fixes this issue. This solution was suggest by Koji Matsumuro, Ricoh Company, Ltd. This change has no negative performance effect on standard SD cards, though it's quite possible that there will be one on UHS-1 cards. Signed-off-by:
Manoj Iyer <manoj.iyer@canonical.com> Tested-by:
Daniel Manrique <daniel.manrique@canonical.com> Cc: Koji Matsumuro <matsumur@nts.ricoh.co.jp> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Wolfgang Denk authored
commit 026dfaf1 upstream. Add ID 4348:5523 for WinChipHead USB->RS 232 adapter with Prolifec PL2303 chipset Signed-off-by:
Wolfgang Denk <wd@denx.de> Signed-off-by:
-
- 22 Jul, 2011 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdbLinus Torvalds authored
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb: sparc,kgdbts: fix compile regression with kgdb test suite
-
- 21 Jul, 2011 4 commits
-
-
Jason Wessel authored
Commit 63ab25eb (kgdbts: unify/generalize gdb breakpoint adjustment) introduced a compile regression on sparc. kgdbts.c: In function 'check_and_rewind_pc': kgdbts.c:307: error: implicit declaration of function 'instruction_pointer_set' Simply add the correct macro definition for instruction pointer on the Sparc architecture. Signed-off-by:
Jason Wessel <jason.wessel@windriver.com> Acked-by:
Mike Frysinger <vapier@gentoo.org> Acked-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6: CIFS: Fix wrong length in cifs_iovec_read
-
Linus Torvalds authored
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: Make Dell Latitude E6420 use reboot=pci x86: Make Dell Latitude E5420 use reboot=pci
-
H. Peter Anvin authored
Yet another variant of the Dell Latitude series which requires reboot=pci. From the E5420 bug report by Daniel J Blueman: > The E6420 is affected also (same platform, different casing and > features), which provides an external confirmation of the issue; I can > submit a patch for that later or include it if you prefer: > http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/Reported-by:
Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Cc: <stable@kernel.org>
-
