- 13 Jul, 2008 6 commits
-
-
Maciej W. Rozycki authored
Now that IRQ2 is never made available to the I/O APIC, there is no need to special-case it and mask as a workaround for broken systems. Actually, because of the former, mask_IO_APIC_irq(2) is a no-op already. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
got this on a test-system: calling numaq_tsc_disable+0x0/0x39 NUMAQ: disabling TSC initcall numaq_tsc_disable+0x0/0x39 returned 0 after 0 msecs that's because we should not be using arch_initcall to call numaq_tsc_disable. need to call it in setup_arch before time_init()/tsc_init() and call it in init_intel() to make the cpu feature bits right. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
end_user_pfn used to modify the meaning of the e820 maps. Now that all e820 operations are cleaned up, unified, tightened up, the e820 map always get updated to reality, we don't need to keep this secondary mechanism anymore. If you hit this commit in bisection it means something slipped through. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
optimization: try to merge the range with same page size in init_memory_mapping, to get the best possible linear mappings set up. thus when GBpages is not there, we could do 2M pages. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
tighten the boundary checks around max_low_pfn_mapped - dont overmap nor undermap into holes. also print out tseg for AMD cpus, for diagnostic purposes. (this is an SMM area, and we split up any big mappings around that area) Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
fix crash on Ingo's big box: calling pci_iommu_init+0x0/0x17 PCI-DMA: Disabling AGP. PCI-DMA: aperture base @ d0000000 size 65536 KB PCI-DMA: using GART IOMMU. PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture BUG: unable to handle kernel paging request at ffff88000003be88 IP: [<ffffffff8026d377>] __alloc_pages_internal+0xc3/0x3f2 PGD 202063 PUD 206063 PMD 22fc00163 PTE 3b162 Oops: 0000 [1] SMP and e820 is: BIOS-e820: 0000000000000000 - 000000000009ac00 (usable) BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000ca000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007ff70000 (usable) BIOS-e820: 000000007ff70000 - 000000007ff86000 (ACPI data) BIOS-e820: 000000007ff86000 - 0000000080000000 (ACPI NVS) BIOS-e820: 0000000080000000 - 00000000cfe00000 (usable) BIOS-e820: 00000000cfe00000 - 00000000d0000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000830000000 (usable) system has 32 GB RAM installed. max_low_pfn_mapped is 0xcfe00, and GART aperture is not mapped. So try to use init_memory_mapping to map that area, because the iommu thinks that area is ram ... Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
- 12 Jul, 2008 4 commits
-
-
Ingo Molnar authored
Conflicts: arch/x86/mm/ioremap.c Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Roland McGrath authored
On three of the several paths in entry_64.S that call do_notify_resume() on the way back to user mode, we fail to properly check again for newly-arrived work that requires another call to do_notify_resume() before going to user mode. These paths set the mask to check only _TIF_NEED_RESCHED, but this is wrong. The other paths that lead to do_notify_resume() do this correctly already, and entry_32.S does it correctly in all cases. All paths back to user mode have to check all the _TIF_WORK_MASK flags at the last possible stage, with interrupts disabled. Otherwise, we miss any flags (TIF_SIGPENDING for example) that were set any time after we entered do_notify_resume(). More work flags can be set (or left set) synchronously inside do_notify_resume(), as TIF_SIGPENDING can be, or asynchronously by interrupts or other CPUs (which then send an asynchronous interrupt). There are many different scenarios that could hit this bug, most of them races. The simplest one to demonstrate does not require any race: when one signal has done handler setup at the check before returning from a syscall, and there is another signal pending that should be handled. The second signal's handler should interrupt the first signal handler before it actually starts (so the interrupted PC is still at the handler's entry point). Instead, it runs away until the next kernel entry (next syscall, tick, etc). This test behaves correctly on 32-bit kernels, and fails on 64-bit (either 32-bit or 64-bit test binary). With this fix, it works. #define _GNU_SOURCE #include <stdio.h> #include <signal.h> #include <string.h> #include <sys/ucontext.h> #ifndef REG_RIP #define REG_RIP REG_EIP #endif static sig_atomic_t hit1, hit2; static void handler (int sig, siginfo_t *info, void *ctx) { ucontext_t *uc = ctx; if ((void *) uc->uc_mcontext.gregs[REG_RIP] == &handler) { if (sig == SIGUSR1) hit1 = 1; else hit2 = 1; } printf ("%s at %#lx\n", strsignal (sig), uc->uc_mcontext.gregs[REG_RIP]); } int main (void) { struct sigaction sa; sigset_t set; sigemptyset (&sa.sa_mask); sa.sa_flags = SA_SIGINFO; sa.sa_sigaction = &handler; if (sigaction (SIGUSR1, &sa, NULL) || sigaction (SIGUSR2, &sa, NULL)) return 2; sigemptyset (&set); sigaddset (&set, SIGUSR1); sigaddset (&set, SIGUSR2); if (sigprocmask (SIG_BLOCK, &set, NULL)) return 3; printf ("main at %p, handler at %p\n", &main, &handler); raise (SIGUSR1); raise (SIGUSR2); if (sigprocmask (SIG_UNBLOCK, &set, NULL)) return 4; if (hit1 + hit2 == 1) { puts ("PASS"); return 0; } puts ("FAIL"); return 1; } Signed-off-by: Roland McGrath <roland@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Rafael J. Wysocki authored
We have two conflicting DMA-based quirks in there for the same set of boxes (HP nx6325 and nx6125) and one of them actually breaks my box. So remove the extra code. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: =?iso-8859-1?q?T=F6r=F6k_Edwin?= <edwintorok@gmail.com> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdogLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog: [PATCH] IPMI: return correct value from ipmi_write
-
- 11 Jul, 2008 27 commits
-
-
Mark Rustad authored
This patch corrects the handling of write operations to the IPMI watchdog to work as intended by returning the number of characters actually processed. Without this patch, an "echo V >/dev/watchdog" enables the watchdog if IPMI is providing the watchdog function. Signed-off-by: Mark Rustad <MRustad@gmail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
-
Ingo Molnar authored
-
Maciej W. Rozycki authored
In the course of the recent unification of the NMI watchdog an assignment to timer_ack to switch off unnecesary POLL commands to the 8259A in the case of a watchdog failure has been accidentally removed. The statement used to be limited to the 32-bit variation as since the rewrite of the timer code it has been relevant for the 82489DX only. This change brings it back. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Maciej W. Rozycki authored
There is no such entity as ISA IRQ2. The ACPI spec does not make it explicitly clear, but does not preclude it either -- all it says is ISA legacy interrupts are identity mapped by default (subject to overrides), but it does not state whether IRQ2 exists or not. As a result if there is no IRQ0 override, then IRQ2 is normally initialised as an ISA interrupt, which implies an edge-triggered line, which is unmasked by default as this is what we do for edge-triggered I/O APIC interrupts so as not to miss an edge. To the best of my knowledge it is useless, as IRQ2 has not been in use since the PC/AT as back then it was taken by the 8259A cascade interrupt to the slave, with the line position in the slot rerouted to newly-created IRQ9. No device could thus make use of this line with the pair of 8259A chips. Now in theory INTIN2 of the I/O APIC may be usable, but the interrupt of the device wired to it would not be available in the PIC mode at all, so I seriously doubt if anybody decided to reuse it for a regular device. However there are two common uses of INTIN2. One is for IRQ0, with an ACPI interrupt override (or its equivalent in the MP table). But in this case IRQ2 is gone entirely with INTIN0 left vacant. The other one is for an 8959A ExtINTA cascade. In this case IRQ0 goes to INTIN0 and if ACPI is used INTIN2 is assumed to be IRQ2 (there is no override and ACPI has no way to report ExtINTA interrupts). This is where a problem happens. The problem is INTIN2 is configured as a native APIC interrupt, with a vector assigned and the mask cleared. And the line may indeed get active and inject interrupts if the master 8959A has its timer interrupt enabled (it might happen for other interrupts too, but they are normally masked in the process of rerouting them to the I/O APIC). There are two cases where it will happen: * When the I/O APIC NMI watchdog is enabled. This is actually a misnomer as the watchdog pulses are delivered through the 8259A to the LINT0 inputs of all the local APICs in the system. The implication is the output of the master 8259A goes high and low repeatedly, signalling interrupts to INTIN2 which is enabled too! [The origin of the name is I think for a brief period during the development we had a capability in our code to configure the watchdog to use an I/O APIC input; that would be INTIN2 in this scenario.] * When the native route of IRQ0 via INTIN0 fails for whatever reason -- as it happens with the system considered here. In this scenario the timer pulse is delivered through the 8259A to LINT0 input of the local APIC of the bootstrap processor, quite similarly to how is done for the watchdog described above. The result is, again, INTIN2 receives these pulses too. Rafael's system used to escape this scenario, because an incorrect IRQ0 override would occupy INTIN2 and prevent it from being unmasked. My conclusion is IRQ2 should be excluded from configuration in all the cases and the current exception for ACPI systems should be lifted. The reason being the exception not only being useless, but harmful as well. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Maciej W. Rozycki authored
Unlike the 32-bit one, the 64-bit variation of the LVT0 setup code for the "8259A Virtual Wire" through the local APIC timer configuration does not fully configure the relevant irq_chip structure. Instead it relies on the preceding I/O APIC code to have set it up, which does not happen if the I/O APIC variants have not been tried. The patch includes corresponding changes to the 32-bit variation too which make them both the same, barring a small syntactic difference involving sequence of functions in the source. That should work as an aid with the upcoming merge. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Maciej W. Rozycki authored
IRQ0 is edge-triggered, but the "8259A Virtual Wire" through the local APIC configuration in the 32-bit version uses the "fasteoi" handler suitable for level-triggered APIC interrupt. Rewrite code so that the "edge" handler is used. The 64-bit version uses different code and is unaffected. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber Costa authored
Merge dwarf2_32.h and dwarf2_64.h into dwarf2.h. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber Costa authored
In dwarf2_32.h, test for CONFIG_AS_CFI instead of CONFIG_UNWIND_INFO. Turns out that searching for UNWIND_INFO returns no match in any Kconfig or Makefile, so we're really just throwing everything away regarding dwarf frames for i386. The test that generates CONFIG_AS_CFI does not have anything x86_64-specific, and right now, checking V=1 builds shows me that the flags is there anyway, although unused. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber Costa authored
In dwarf_64.h header, use the "ignore" macro the way i386 does. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber Costa authored
The RING0_INT_FRAME macro defines a CFI_STARTPROC. So we should really be using CFI_ENDPROC after it. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-devLinus Torvalds authored
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev: libata-acpi: don't call sleeping function from invalid context Added Targa Visionary 1000 IDE adapter to pata_sis.c libata-acpi: filter out DIPM enable
-
Dave Chinner authored
When we release the iclog, we do an atomic_dec_and_lock to determine if we are the last reference and need to trigger update of log headers and writeout. However, in xlog_state_get_iclog_space() we also need to check if we have the last reference count there. If we do, we release the log buffer, otherwise we decrement the reference count. But the compare and decrement in xlog_state_get_iclog_space() is not atomic, so both places can see a reference count of 2 and neither will release the iclog. That leads to a filesystem hang. Close the race by replacing the atomic_read() and atomic_dec() pair with atomic_add_unless() to ensure that they are executed atomically. Signed-off-by: Dave Chinner <david@fromorbit.com> Reviewed-by: Tim Shimmin <tes@sgi.com> Tested-by: Eric Sandeen <sandeen@sandeen.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Ingo Molnar authored
i spent a fair amount of time chasing a 64-bit bootup crash that manifested itself as bootup segfaults: S10network[1825]: segfault at 7f3e2b5d16b8 ip 00000031108748c9 sp 00007fffb9c14c70 error 4 in libc-2.7.so[3110800000+14d000] eventually causing init to die and panic the system: Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.26-rc9-tip #13878 after a maratonic bisection session, the bad commit turned out to be: | b7675791859075418199c7af86a116ea34eaf5bd is first bad commit | commit b7675791859075418199c7af86a116ea34eaf5bd | Author: Jeremy Fitzhardinge <jeremy@goop.org> | Date: Wed Jun 25 00:19:00 2008 -0400 | | x86: remove open-coded save/load segment operations | | This removes a pile of buggy open-coded implementations of savesegment | and loadsegment. after some more bisection of this patch itself, it turns out that what makes the difference are the savesegment() changes to __switch_to(). Taking a look at this portion of arch/x86/kernel/process_64.o revealed this crutial difference: | good: 99c: 8c e0 mov %fs,%eax | 99e: 89 45 cc mov %eax,-0x34(%rbp) | | bad: 99c: 8c 65 cc mov %fs,-0x34(%rbp) which is due to: | unsigned fsindex; | - asm volatile("movl %%fs,%0" : "=r" (fsindex)); | + savesegment(fs, fsindex); savesegment() is implemented as: #define savesegment(seg, value) \ asm("mov %%" #seg ",%0":"=rm" (value) : : "memory") note the "m" modifier - it allows GCC to generate the segment move into a memory operand as well. But regarding segment operands there's a subtle detail in the x86 instruction set: the above 16-bit moves are zero-extend, but only if it goes to a register. If it goes to a memory operand, -0x34(%rbp) in the above case, there's no zero-extend to 32-bit and the instruction will only save 16 bits instead of the intended 32-bit. The other 16 bits is random data - which can cause problems when that value is used later on. The solution is to only allow segment operands to go to registers. This fix allows my test-system to boot up without crashing. Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Jeremy Fitzhardinge authored
Use the X86_FEATURE_SYSENTER32 to remove hard-coded CPU vendor check. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Jeremy Fitzhardinge authored
Add pseudo-feature bits to describe whether the CPU supports sysenter and/or syscall from ia32-compat userspace. This removes a hardcoded test in vdso32-setup. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Zhang Rui authored
The problem is introduced by commit 664d080c. acpi_evaluate_integer is a sleeping function, and it should not be called with spin_lock_irqsave. https://bugzilla.redhat.com/show_bug.cgi?id=451399Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
Kai Krakow authored
This enables short 40-wire detection for my laptop thus enabling UDMA/100. Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
Tejun Heo authored
Some BIOSen enable DIPM via _GTF which causes command timeouts under certain configuration. This didn't occur on 2.6.25 because 2.6.25 defaulted to SRST, so _GTF wasn't executed during boot probe, so ahci host reset disabled DIPM and as _GTF wasn't executed after SRST, DIPM wasn't enabled. On 2.6.26, hardreset is used during probe and after probe _GTF is executed enabling DIPM and thus the failures. This patch could theoretically disable DIPM on machines which used to have it enabled on 2.6.25 but AFAIK ahci is currently the only driver which uses SATA ACPI hierarchy (_SDD) and as the host reset would have always disabled DIPM, this shouldn't happen. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-
Ingo Molnar authored
Yinghai Lu reported crashes on 64-bit x86: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [<ffffffff80253b17>] hrtick_start_fair+0x89/0x173 [...] And with a long session of debugging and a lot of difficulty, tracked it down to this commit: ---------------> 8fbbc4b4 is first bad commit commit 8fbbc4b4 Author: Alok Kataria <akataria@vmware.com> Date: Tue Jul 1 11:43:34 2008 -0700 x86: merge tsc_init and clocksource code <-------------- The problem is that the TSC unification missed these Makefile rules in arch/x86/kernel/Makefile: # Do not profile debug and lowlevel utilities CFLAGS_REMOVE_tsc_64.o = -pg CFLAGS_REMOVE_tsc_32.o = -pg ... CFLAGS_tsc_64.o := $(nostackp) ... which rules make sure that various instrumentation and debugging facilities are disabled for code that might end up in a VDSO - such as the TSC code. Reported-and-bisected-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Conflicts: Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
when more than 4g memory is installed, don't map the big hole below 4g. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
save the SLIT, in case we are using fixmap to read it, and that fixmap could be cleared by others. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
also let mem= to print out modified e820 map too Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Bernhard Walle <bwalle@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Paul Gortmaker authored
The IRQ rate reported back by the RTC is incorrect when HPET is enabled. Newer hardware that has HPET to emulate the legacy RTC device gets this value wrong since after it sets the rate, it returns before setting the variable used to report the IRQ rate back to users of the device -- so the set rate and the reported rate get out of sync. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Brownell <david-b@pacbell.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Uwe Kleine-König authored
This patch was created by git grep -E -l 'Rus(el|s?e)l King' | xargs -r -t perl -p -i -e 's/Rus(el|s?e)l King/Russell King/g' Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Most-Definitely-Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Eugene Surovegin authored
Fix RapidIO device reference counting. Signed-of-by: Eugene Surovegin <ebs@ebshome.net> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Marcin Obara authored
This patch adds Intel TPM TIS device HID: ICO0102 Signed-off-by: Marcin Obara <marcin_obara@users.sourceforge.net> Acked-by: Marcel Selhorst <tpm@selhorst.net> Acked-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (27 commits) tun: Persistent devices can get stuck in xoff state xfrm: Add a XFRM_STATE_AF_UNSPEC flag to xfrm_usersa_info ipv6: missed namespace context in ipv6_rthdr_rcv netlabel: netlink_unicast calls kfree_skb on error path by itself ipv4: fib_trie: Fix lookup error return tcp: correct kcalloc usage ip: sysctl documentation cleanup Documentation: clarify tcp_{r,w}mem sysctl docs netfilter: nf_nat_snmp_basic: fix a range check in NAT for SNMP netfilter: nf_conntrack_tcp: fix endless loop libertas: fix memory alignment problems on the blackfin zd1211rw: stop beacons on remove_interface rt2x00: Disable synchronization during initialization rc80211_pid: Fix fast_start parameter handling sctp: Add documentation for sctp sysctl variable ipv6: fix race between ipv6_del_addr and DAD timer irda: Fix netlink error path return value irda: New device ID for nsc-ircc irda: via-ircc proper dma freeing sctp: Mark the tsn as received after all allocations finish ...
-
- 10 Jul, 2008 3 commits
-
-
Max Krasnyansky authored
The scenario goes like this. App stops reading from tun/tap. TX queue gets full and driver does netif_stop_queue(). App closes fd and TX queue gets flushed as part of the cleanup. Next time the app opens tun/tap and starts reading from it but the xoff state is not cleared. We're stuck. Normally xoff state is cleared when netdev is brought up. But in the case of persistent devices this happens only during initial setup. The fix is trivial. If device is already up when an app opens it we clear xoff state and that gets things moving again. Signed-off-by: Max Krasnyansky <maxk@qualcomm.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Steffen Klassert authored
Add a XFRM_STATE_AF_UNSPEC flag to handle the AF_UNSPEC behavior for the selector family. Userspace applications can set this flag to leave the selector family of the xfrm_state unspecified. This can be used to to handle inter family tunnels if the selector is not set from userspace. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Denis V. Lunev authored
Signed-off-by: Denis V. Lunev <den@parallels.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-