- 18 Dec, 2009 40 commits
-
-
David Woodhouse authored
commit 44cd613c upstream. The hotplug notifier will call find_domain() to see if the device in question has been assigned an IOMMU domain. However, this should never be called for devices with a "dummy" domain, such as graphics devices when intel_iommu=igfx_off is set and the corresponding IOMMU isn't even initialised. If you do that, it'll oops as it dereferences the (-1) pointer. The notifier function should check iommu_no_mapping() for the device before doing anything else. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Woodhouse authored
commit 5595b528 upstream. Some HP BIOSes report an RMRR region (a region which needs a 1:1 mapping in the IOMMU for a given device) which has an end address lower than its start address. Detect that and warn, rather than triggering the BUG() in dma_pte_clear_range(). Signed-off-by:
-
David Woodhouse authored
commit 6ecbf01c upstream. The BIOS errors where an IOMMU is reported either at zero or a bogus address are causing problems even when the IOMMU is disabled -- because interrupt remapping uses the same hardware. Ensure that the checks get applied for the interrupt remapping initialisation too. Signed-off-by:
-
Chris Wright authored
commit 2c992208 upstream. Many BIOSes will lie to us about the existence of an IOMMU, and claim that there is one at an address which actually returns all 0xFF. We need to detect this early, so that we know we don't have a viable IOMMU and can set up swiotlb before it's too late. Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
-
David Woodhouse authored
commit 2e16cfca upstream. Ever since jffs2_garbage_collect_metadata() was first half-written in February 2001, it's been broken on architectures where 'char' is signed. When garbage collecting a symlink with target length above 127, the payload length would end up negative, causing interesting and bad things to happen. Signed-off-by:
-
Simon Horman authored
commit 258c8893 upstream. Make sure that any otherwise uninitialised fields of usvc are zero. This has been obvserved to cause a problem whereby the port of fwmark services may end up as a non-zero value which causes scheduling of a destination server to fail for persisitent services. As observed by Deon van der Merwe <dvdm@truteq.co.za>. This fix suggested by Julian Anastasov <ja@ssi.bg>. For good measure also zero udest. Cc: Deon van der Merwe <dvdm@truteq.co.za> Acked-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Hugh Dickins authored
commit d99be1a8 upstream. When do_nonlinear_fault() realizes that the page table must have been corrupted for it to have been called, it does print_bad_pte() and returns ... VM_FAULT_OOM, which is hard to understand. It made some sense when I did it for 2.6.15, when do_page_fault() just killed the current process; but nowadays it lets the OOM killer decide who to kill - so page table corruption in one process would be liable to kill another. Change it to return VM_FAULT_SIGBUS instead: that doesn't guarantee that the process will be killed, but is good enough for such a rare abnormality, accompanied as it is by the "BUG: Bad page map" message. And recent HWPOISON work has copied that code into do_swap_page(), when it finds an impossible swap entry: fix that to VM_FAULT_SIGBUS too. Signed-off-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Izik Eidus <ieidus@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Nick Piggin <npiggin@suse.de> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Rik van Riel <riel@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com> Cc: Andi Kleen <andi@firstfloor.org> Reviewed-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Reviewed-by:
Wu Fengguang <fengguang.wu@intel.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:
-
Zhenyu Wang authored
commit 1b3c7a47 upstream. In disable sequence, all output ports on PCH have to be disabled before PCH transcoder, but LVDS port was left always enabled. This one fixes that by disable LVDS port properly during pipe disable process, and resolved stability issue seen on Ironlake. Also move panel fitting disable time just after pipe disable to align with the spec. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Zhenyu Wang authored
commit 103a196f upstream. PineView only has 2 ports for LVDS and CRT. Don't enable other ports for it. Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Chris Wilson authored
commit d271817b upstream. In commit d2d9f232, the guard for a valid video mode was removed. This caused the regression: kernel crash during kms graphic boot on Intel GM4500 platform https://bugzilla.redhat.com/show_bug.cgi?id=540218 This patches changes the logic slightly not to rely on a coupled variable, but to just check whether the video_modes is valid before dereferencing. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Zhenyu Wang <zhenyu.z.wang@intel.com> [ickle: Actually reference the correct bug report] Acked-by:
-
Yong Wang authored
Upstream commit a2202aa2. On platforms where bios handles the thermal monitor interrupt, APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS can't touch it. Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all the LVT entries except the mask bit. Essentially this results in all LVT entries including the thermal monitoring interrupt set to masked (clearing the bios programmed value for APIC_LVTTHMR). And this leads to kernel take over the thermal monitoring interrupt on AP's but not on BSP (leaving the bios programmed value only on BSP). As a result of this, we have seen system hangs when the thermal monitoring interrupt is generated. Fix this by reading the initial value of thermal LVT entry on BSP and if bios has taken over the control, then program the same value on all AP's and leave the thermal monitoring interrupt control on all the logical cpu's to the bios. Signed-off-by:
Yong Wang <yong.y.wang@intel.com> Reviewed-by:
Suresh Siddha <suresh.b.siddha@intel.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: Arjan van de Ven <arjan@infradead.org> LKML-Reference: <20091110013824.GA24940@ywang-moblin2.bj.intel.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Florian Fainelli authored
commit a3f92eea upstream. This patch converts bcm63xx_enet to uset get_sset_count like the other drivers do. Signed-off-by:
Florian Fainelli <ffainelli@freebox.fr> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rafal Milecki authored
commit 518c8df7 upstream. Signed-off-by:
Rafal Milecki <zajec5@gmail.com> Signed-off-by:
Jean-Francois Moine <moinejf@free.fr> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Surbhi Palande <surbhi.palande@canonical.com> Signed-off-by:
-
Jan Kara authored
commit 68eb3db0 upstream. When ext3_write_begin fails after allocating some blocks or generic_perform_write fails to copy data to write, we truncate blocks already instantiated beyond i_size. Although these blocks were never inside i_size, we have to truncate pagecache of these blocks so that corresponding buffers get unmapped. Otherwise subsequent __block_prepare_write (called because we are retrying the write) will find the buffers mapped, not call ->get_block, and thus the page will be backed by already freed blocks leading to filesystem and data corruption. Reported-by:
James Y Knight <foom@fuhm.net> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Eric W. Biederman authored
commit d90a909e upstream. I received some bug reports about userspace programs having problems because after RTM_NEWLINK was received they could not immeidate access files under /proc/sys/net/ because they had not been registered yet. The problem was trivailly fixed by moving the userspace notification from rtnetlink_event to the end of register_netdevice. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Zhao Yakui authored
commit 03a05ed1 upstream. Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms, reduce contention on c3_lock by skipping the fake ARB_DISABLE. The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box, the box can't be booted correctly. But if we still enable ARB_DISABLE on this box, the box can be booted correctly. So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f. http://bugzilla.kernel.org/show_bug.cgi?id=14700Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Acked-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Tejun Heo authored
No matching upstream commit as it was resolved differently there. pcpu_get_vm_areas() is used only when dynamic percpu allocator is used by the architecture. In 2.6.32, ia64 doesn't use dynamic percpu allocator and has a macro which makes pcpu_get_vm_areas() buggy via local/global variable aliasing and triggers compile warning. The problem is fixed in upstream and ia64 uses dynamic percpu allocators, so the only left issue is inclusion of unnecessary code and compile warning on ia64 on 2.6.32. Don't build pcpu_get_vm_areas() if legacy percpu allocator is in use. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Jan Beulich <JBeulich@novell.com> Signed-off-by:
-
Corentin Chary authored
commit d951d4cc upstream. The light sensor disable brightness key and /sys/class/backlight/ control. There was a lot of report from users who didn't understand why they couldn't change their brightness, including: https://bugs.launchpad.net/bugs/222171 https://bugzilla.novell.com/show_bug.cgi?id=514747 http://bugzilla.kernel.org/show_bug.cgi?id=13671 http://bugzilla.kernel.org/show_bug.cgi?id=14432 Now the light sensor is disabled, and if the user want to enable it, the level should be ok. The funny thing is that comments where ok, not code. Cc: stable@kernel.org Cc: Thomas Renninger <trenn@suse.de> Cc: Peter Küppers <peter-mailbox@web.de> Cc: Michael Franzl <michaelfranzl@gmx.at> Cc: Ian Turner <vectro@vectro.org> Signed-off-by:
Corentin Chary <corentincj@iksaif.net> Signed-off-by:
-
Peter Feuerer authored
commit 36065746 upstream. Added new BIOS versions for following netbooks: Acer 1410, Gateway LT31, Packard Bell DOA150. As the Gateway LT31 machines have different register values for setting and checking the off-state, the "cmd_off" variable has been splitted up to "cmd_off" and "chk_off". Signed-off-by:
Peter Feuerer <peter@piie.net> Cc: Borislav Petkov <petkovbb@gmail.com> Cc: Andreas Mohr <andi@lisas.de> Signed-off-by:
-
Alan Cox authored
commit 8c651311 upstream. Regression caused in 2.6.23 and then despite repeated requests never fixed or dealt with (Petr promised to sort it in 2008 but seems to have forgotten). Enough is enough - remove the problem line that was added. If it upsets someone they've had two years to deal with it and at the very least it'll rattle their cage and wake them up. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9709Signed-off-by:
Alan Cox <alan@linux.intel.com> Reported-by:
Damon <account@bugzilla.kernel.org.juxtaposition.net> Tested-by:
Ruud van Melick <rvm1974@raketnet.nl> Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Paul A. Clarke <pc@us.ibm.com> Signed-off-by:
-
Zhu Yi authored
commit 52ce3e9a upstream. Add PCI .shutdown method so that we can disable the device during shutdown or reboot. Without this, the reboot doesn't work well on some platforms. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2124Tested-by:
pablo <pablolm2005@gmail.com> Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Henrique de Moraes Holschuh authored
commit 208b996b upstream. Since the rfkill rework in 2.6.31, the driver is always resuming with the radios disabled. Change thinkpad-acpi to ask the firmware to resume with the radios in the last state. This fixes the Bluetooth and WWAN rfkill switches. Note that it means we respect the firmware's oddities. Should the user toggle the hardware rfkill switch on and off, it might cause the radios to resume enabled. UWB is an unknown quantity since it has nowhere the same level of firmware support (no control over state storage in NVRAM, for example), and might need further fixing. Testers welcome. This change fixes a regression from 2.6.30. Reported-by:
Jerone Young <jerone.young@canonical.com> Reported-by:
Ian Molton <ian.molton@collabora.co.uk> Signed-off-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Tested-by:
-
Henrique de Moraes Holschuh authored
commit a9f8eacc upstream. According to a report, the R50e wants EC-based brightness control, even if it uses an Intel GPU. The current driver default was reported to not work at all. This bug can be worked around by the "brightness_mode=3" module parameter. Change the default of the R50e and R51 2xxx models (which use the same EC firmware, 1V) to TPACPI_BRGHT_Q_EC, but keep TPACPI_BRGHT_Q_ASK set for now, as I'd like to get more reports. This fixes a regression caused by commit 59fe4fe3, "thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM" Kernel 2.6.31 also needs this fix. Reported-by:
Ferenc Wagner <wferi@niif.hu> Tested-by:
-
Kirill A. Shutemov authored
commit cd9b45b7 upstream. A memory cgroup has a memory.memsw.usage_in_bytes file. It shows the sum of the usage of pages and swapents in the cgroup. Presently the root cgroup's memsw.usage_in_bytes shows the wrong value - the number of swapents are not added. So take MEM_CGROUP_STAT_SWAPOUT into account. Signed-off-by:
Kirill A. Shutemov <kirill@shutemov.name> Reviewed-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Acked-by:
-
Li Peng authored
commit 778c9026 upstream In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by:
Li Peng <peng.li@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: hand-applied for conflicts with overlay changes] Signed-off-by:
-
Vivek Natarajan authored
Upstream commit: 7c3f4bbe Not only ps_sdata but also IEEE80211_CONF_PS is to be considered before restoring PS in scan_ps_disable(). For instance, when ps_sdata is set but CONF_PS is not set just because the dynamic timer is still running, a sw scan leads to setting of CONF_PS in scan_ps_disable instead of restarting the dynamic PS timer. Also for the above case, a null data frame is to be sent after returning to operating channel which was not happening with the current implementation. This patch fixes this too. Signed-off-by:
Vivek Natarajan <vnatarajan@atheros.com> Reviewed-by:
Kalle Valo <kalle.valo@nokia.com> Signed-off-by:
-
Felix Fietkau authored
This is a backport of upstream commit: e8c6342d989e241513baeba4b05a04b6b1f3bc8b This patch fixes a bug in ath9k's tx status check, which caused mac80211 to consider regularly transmitted unicast frames as un-acked. When checking the ts_status field for errors, it needs to be masked with ATH9K_TXERR_FILT, because this field also contains other fields like ATH9K_TX_ACKED. Without this patch, AP mode is pretty much unusable, as hostapd checks the ACK status for the frames that it injects. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
This is a backport of upstream commit: f4709fdf Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO buffer size of that of dual stream devices. Dual stream devices have a max PCU TX FIFO size of 8 KB while single stream devices have 4 KB. Single stream devices have an issue though and require hardware only to use half of the amount of its capable PCU TX FIFO size, 2 KB and this requires a change in software. Technically a change would not have been required (except for frame burst considerations of 128 bytes) if these devices would have been able to use the full 4 KB of the PCU TX FIFO size but our systems engineers recommend 2 KB to be used only. We enforce this through software by reducing the max frame triggger level to 2 KB. Fixing the max frame trigger level should then have a few benefits: * The PER will now be adjusted as designed for underruns when the max trigger level is reached. This should help alleviate the bus as the rate control algorithm chooses a slower rate which should ensure frames are transmitted properly under high system bus load. * The poll we use on our TX queues should now trigger and work as designed for single stream devices. The hardware passes data from each TX queue on the PCU TX FIFO queue respecting each queue's priority. The new trigger level ensures this seeding of the PCU TX FIFO queue occurs as designed which could mean avoiding false resets and actually reseting hw correctly when a TX queue is indeed stuck. * Some undocumented / unsupported behaviour could have been triggered when the max trigger level level was being set to 4 KB on single stream devices. Its not clear what this issue was to me yet. Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com> Cc: Stephen Chen <stephen.chen@atheros.com> Cc: Shan Palanisamy <shan.palanisamy@atheros.com> Cc: Paul Shaw <paul.shaw@atheros.com> Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
This is a backport of upstream commit: e7824a50 When mac80211 was telling us to go into Powersave we listened and immediately turned RX off. This meant hardware would not see the ACKs from the AP we're associated with and hardware we'd end up retransmiting the null data frame in a loop helplessly. Fix this by keeping track of the transmitted nullfunc frames and only when we are sure the AP has sent back an ACK do we go ahead and shut RX off. Signed-off-by:
Vivek Natarajan <Vivek.Natarajan@atheros.com> Signed-off-by:
-
Sujith authored
This is a backport of upstream commit: 332c5566 When TX is hung, the chip is reset. Ensure that the chip is awake by using the PS wrappers. Signed-off-by:
Sujith <Sujith.Manoharan@atheros.com> Signed-off-by:
-
Johannes Berg authored
commit 811cb50b upstream. For some reason the export of the event print format to userspace uses '#fmt' which breaks if the format string is anything but a plain string, for example if it is built with macros then the macro names are exported instead of their contents. Use "\"%s\"", fmt instead of "%s", #fmt to export the string and not the way it is built. For example, in net/mac80211/driver-trace.h for the trace event drv_start there is: TP_printk( LOCAL_PR_FMT, LOCAL_PR_ARG ) Which use to produce: print fmt: LOCAL_PR_FMT, REC->wiphy_name Now produces: print fmt: "%s", REC->wiphy_name Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> LKML-Reference: <20091113224009.GB23942@elte.hu> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Larry Finger authored
commit 316a4d96 upstream. For PPC architecture with PHY Revision < 3, a read of the register B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43legacy_status() returns a value of 2 (B43legacy_STAT_STARTED); however, one finds that the driver is unable to associate after resuming from hibernation unless this routine returns 1. To satisfy both conditions, the routine is rewritten to return TRUE whenever b43legacy_status() returns a value < 2. This patch fixes the second problem listed in the postings for Red Hat Bugzilla #538523. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 7f5620a5 ] "ARCH" can be just about anything, so we shouldn't end up with UTS_MACHINE of "sparc" in a 64-bit kernel build just because someone set the personality using 'sparc32' or similar. CONFIG_SPARC64 drives the compilation and therefore provides the definitive value, not "ARCH". This mirrors commit 8c6531f7 (x86: correctly set UTS_MACHINE for "make ARCH=x86") Signed-off-by:
-
David S. Miller authored
[ Upstream commit 166e553a ] Commit 4f70f7a9 (sparc64: Implement IRQ stacks.) has two bugs. First, the softirq range check forgets to subtract STACK_BIAS before comparing with %sp. Next, on failure the wrong label is jumped to, resulting in a bogus stack being loaded. Reported-by:
Igor Kovalenko <igor.v.kovalenko@gmail.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 4230fa3b ] When we are trying to see if a range property entry applies to a given address, we are overly strict about the type. We should only allow I/O ranges for I/O addresses, and only allow CONFIG space ranges for CONFIG space address. However for MEM ranges, they come in 32-bit and 64-bit flavors. And a lack of an exact match is OK if the range is 32-bit and the address is 64-bit. We can assign a 64-bit address properly into a 32-bit parent range just fine. So allow it. Reported-by:
Patrick Finnegan <pat@computer-refuge.org> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 08a036d5 ] IRQF_SHARED and IRQF_DISABLED don't mix. Signed-off-by:
-
Stanislav Brabec authored
[ Upstream commit: e0188829 ] About 50% of shutdowns of b44 Ethernet adapter ends by kernel panic with kernels compiled with stack-protector. Checking b44_magic_pattern() return values, one call of b44_magic_pattern() returns 127. It means, that set_bit(128, pmask) was called on line 1509. It means that bit 0 of 17th byte of pmask was overwritten. But pmask has only 16 bytes. Stack corruption happens. It seems that set_bit() on line 1509 always writes one bit off. The fix does not only solve the stack corruption, but also makes Wake On LAN working on my onboard B44 on Asus A7V-333X mainboard. It seems that this problem affects all kernel versions since commit 725ad800 ([PATCH] b44: add wol for old nic) on 2006-06-20. Signed-off-by:
Stanislav Brabec <sbrabec@suse.cz> Signed-off-by:
-
Patrick McHardy authored
[ Upstream commit b2722b1c ] When a large packet gets reassembled by ip_defrag(), the head skb accounts for all the fragments in skb->truesize. If this packet is refragmented again, skb->truesize is not re-adjusted to reflect only the head size since its not owned by a socket. If the head fragment then gets recycled and reused for another received fragment, it might exceed the defragmentation limits due to its large truesize value. skb_recycle_check() explicitly checks for linear skbs, so any recycled skb should reflect its true size in skb->truesize. Change ip_fragment() to also adjust the truesize value of skbs not owned by a socket. Reported-and-tested-by:
Ben Menchaca <ben@bigfootnetworks.com> Signed-off-by:
-
Damian Lukowski authored
[ Upstream commit 07f29bc5 ] This patch fixes a problem in the TCP connection timeout calculation. Currently, timeout decisions are made on the basis of the current tcp_time_stamp and retrans_stamp, which is usually set at the first retransmission. However, if the retransmission fails in tcp_retransmit_skb(), retrans_stamp is not updated and remains zero. This leads to wrong decisions in retransmits_timed_out() if tcp_time_stamp is larger than the specified timeout, which is very likely. In this case, the TCP connection dies after the first attempted (and unsuccessful) retransmission. With this patch, tcp_skb_cb->when is used instead, when retrans_stamp is not available. This bug has been introduced together with retransmits_timed_out() in 2.6.32, as the number of retransmissions has been used for timeout decisions before. The corresponding commit was 6fa12c85 (Revert Backoff [v3]: Calculate TCP's connection close threshold as a time value.). Thanks to Ilpo Järvinen for code suggestions and Frederic Leroy for testing. Reported-by:
Frederic Leroy <fredo@starox.org> Signed-off-by:
Damian Lukowski <damian@tvk.rwth-aachen.de> Acked-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
[ Upstream commit ee31527a ] Fix checking of the currently programmed UDMA mode. Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Acked-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
