- 14 Feb, 2006 16 commits
-
-
Linus Torvalds authored
-
Phil Dibowitz authored
The following patch looks good to me. It adds an unusual_devs entry as well as fixing an ordering bug. Please apply. From: Bohdan Linda <bohdan.linda@gmail.com> Signed-off-by: Phil Dibowitz <phil@ipom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
Another unusual_devs.h entry (as652). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
A new unusual_devs.h entry (as651). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
Here is a new entry for unusual_devs.h (as630). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
This patch (as631) for unusual_devs.h fixes bugzilla entry 5913. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Phil Dibowitz <phil@ipom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David Brownell authored
The switchover to "platform_driver" from "device_driver" missed one rather essential usage, which broke the sl811_cs driver ... this resolves the omission. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Christian Lindner authored
The patch adds the USB ID (0413:2101) for the Leadtek GPS-Mouse 9531 to the driver pl2303. Signed-off-by: Christian Lindner <christian.lindner@gmx.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Michael Hund authored
Signed-off-by: Michael Hund <mhund@ld-didactic.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Michael Hund authored
Signed-off-by: Michael Hund <mhund@ld-didactic.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David Brownell authored
Disable some dubious "early" USB handoff code that allegedly works around bugs on some systems (we don't know which ones) but rudely breaks some others. Also make the kernel warnings reporting BIOS handoff problems be more useful, reporting the register whose value displays the trouble. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Kyle McMartin authored
parisc defines ARCH_WANT_STAT64, so we want to use fstatat64. It does not appear that it needs to be ENTRY_COMP, because struct stat64 is the same on both 32-bit and 64-bit (unlike on other platforms which did define a compat_sys_fstatat64.) Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Linus Torvalds authored
-
David S. Miller authored
Revert the following changeset: bc8dfcb9 Recursive SKB frag lists are really possible and disallowing them breaks things. Noticed by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
Problem discovered and initial patch by Olaf Kirch: there's a problem with IPsec that has been bugging some of our users for the last couple of kernel revs. Every now and then, IPsec will freeze the machine completely. This is with openswan user land, and with kernels up to and including 2.6.16-rc2. I managed to debug this a little, and what happens is that we end up looping in xfrm_lookup, and never get out. With a bit of debug printks added, I can this happening: ip_route_output_flow calls xfrm_lookup xfrm_find_bundle returns NULL (apparently we're in the middle of negotiating a new SA or something) We therefore call xfrm_tmpl_resolve. This returns EAGAIN We go to sleep, waiting for a policy update. Then we loop back to the top Apparently, the dst_orig that was passed into xfrm_lookup has been dropped from the routing table (obsolete=2) This leads to the endless loop, because we now create a new bundle, check the new bundle and find it's stale (stale_bundle -> xfrm_bundle_ok -> dst_check() return 0) People have been testing with the patch below, which seems to fix the problem partially. They still see connection hangs however (things only clear up when they start a new ping or new ssh). So the patch is obvsiouly not sufficient, and something else seems to go wrong. I'm grateful for any hints you may have... I suggest that we simply bail out always. If the dst decides to die on us later on, the packet will be dropped anyway. So there is no great urgency to retry here. Once we have the proper resolution queueing, we can then do the retry again. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Olaf Kirch <okir@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 13 Feb, 2006 23 commits
-
-
Nicolas DICHTEL authored
Signed-off-by: Nicolas DICHTEL <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Morton authored
drivers/net/appletalk/cops.c: In function `cops_load': drivers/net/appletalk/cops.c:539: warning: assignment discards qualifiers from pointer target type drivers/net/appletalk/cops.c:547: warning: assignment discards qualifiers from pointer target type Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jamal Hadi Salim authored
- panic() doesn't return. - Don't forget to unlock on genl_register_family() error path - genl_rcv_msg() is called via pointer so there's no point in declaring it `inline'. Notes: genl_ctrl_event() ignores the genlmsg_multicast() return value. lots of things ignore the genl_ctrl_event() return value. Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Horms patch was the best of the three fixes. Dave, already applied Harald's version, so this patch converts that to the better one. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Harald Welte authored
The new x_tables related Kconfig options appear at the wrong menu level without this patch. Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
-
Dave Jones authored
Missing license tag. I've assumed this is GPL. (It could also use a MODULE_AUTHOR) Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dave Jones authored
isic can trigger these msgs to be spewed at a very high rate. There's already a sysctl to turn them off. Given these messages aren't useful for most people, this patch disables them by default. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dave Jones authored
This seems to be trivial to trigger. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
From: Joe Perches <joe@perches.com> Based upon a patch by Dave Jones. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dave Jones authored
I get a machine check exception, triple fault, or NMI watchdog lockup when DRI gets enabled on this card. (And Mauro Tassinari <mtassinari@cmanet.it> reports hung kernels too in http://lkml.org/lkml/2006/1/26/97) [ Adrian Bunk also states that this is the only RV350 entry for an RV370 in our lists, which implies that it's just buggy ] Cc: Adrian Bunk <bunk@stusta.de> Cc: Dave Jones <davej@redhat.com> Cc: Mauro Tassinari <mtassinari@cmanet.it> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jeff Mahoney authored
This fixes a potential oops if there is an error reported by posix_acl_from_disk(). This is mostly theoretical due to the use of magics and checksums in xattrs, but is still possible. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Yoichi Yuasa authored
As noted by Jan Dittmer <jdi@l4x.org> Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Marcel Holtmann authored
Before the PCMCIA subsystem was fully integrated into the device and driver model, the BT3C driver had to workaround this when loading the firmware. This workaround is broken and makes the driver oops when loading the firmware. This patch removes this workaround and uses now the provided device structure from the PCMCIA subsystem. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
This patch fixes the two NULL pointer dereferences found by the sfuzz tool from Ilja van Sprundel. The first one was a call of getsockname() for an unbound socket and the second was calling accept() while this operation isn't implemented for the HCI socket interface. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
This patch reduces the default L2CAP MTU for all RFCOMM connections from 1024 to 1013 to improve the interoperability with some broken RFCOMM implementations. To make this more flexible the L2CAP MTU becomes also a module parameter and so it can changed at runtime. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
Linus Torvalds authored
-
Andi Kleen authored
Don't touch the non DMA members in the sg list in dma_map_sg in the IOMMU Some drivers (in particular ST) ran into problems because they reused the sg lists after passing them to pci_map_sg(). The merging procedure in the K8 GART IOMMU corrupted the state. This patch changes it to only touch the dma* entries during merging, but not the other fields. Approach suggested by Dave Miller. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
John Blackwood authored
We found a problem with x86_64 kernels with preemption enabled, where having multiple tasks doing ptrace singlesteps around the same time will cause the system to 'oops'. The problem seems that a task can get preempted out of the do_debug() processing while it is running on the DEBUG_STACK stack. If another task on that same cpu then enters do_debug() and uses the same per-cpu DEBUG_STACK stack, the previous preempted tasks's stack contents can be corrupted, and the system will oops when the preempted task is context switched back in again. The typical oops looks like the following: Unable to handle kernel paging request at ffffffffffffffae RIP: <ffffffff805452a1>{thread_return+34} PGD 103027 PUD 102429067 PMD 0 Oops: 0002 [1] PREEMPT SMP CPU 0 Modules linked in: Pid: 3786, comm: ssdd Not tainted 2.6.15.2 #1 RIP: 0010:[<ffffffff805452a1>] <ffffffff805452a1>{thread_return+34} RSP: 0018:ffffffff80824058 EFLAGS: 000136c2 RAX: ffff81017e12cea0 RBX: 0000000000000000 RCX: 00000000c0000100 RDX: 0000000000000000 RSI: ffff8100f7856e20 RDI: ffff81017e12cea0 RBP: 0000000000000046 R08: ffff8100f68a6000 R09: 0000000000000000 R10: 0000000000000000 R11: ffff81017e12cea0 R12: ffff81000c2d53e8 R13: ffff81017f5b3be8 R14: ffff81000c0036e0 R15: 000001056cbfc899 FS: 00002aaaaaad9b00(0000) GS:ffffffff80883800(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffffffffffae CR3: 00000000f6fcf000 CR4: 00000000000006e0 Process ssdd (pid: 3786, threadinfo ffff8100f68a6000, task ffff8100f7856e20) Stack: ffffffff808240d8 ffffffff8012a84a ffff8100055f6c00 0000000000000020 0000000000000001 ffff81000c0036e0 ffffffff808240b8 0000000000000000 0000000000000000 0000000000000000 Call Trace: <#DB> <ffffffff8012a84a>{try_to_wake_up+985} <ffffffff8012c0d3>{kick_process+87} <ffffffff8013b262>{signal_wake_up+48} <ffffffff8013b5ce>{specific_send_sig_info+179} <ffffffff80546abc>{_spin_unlock_irqrestore+27} <ffffffff8013b67c>{force_sig_info+159} <ffffffff801103a0>{do_debug+289} <ffffffff80110278>{sync_regs+103} <ffffffff8010ed9a>{paranoid_userspace+35} Unable to handle kernel paging request at 00007fffffb7d000 RIP: <ffffffff8010f2e4>{show_trace+465} PGD f6f25067 PUD f6fcc067 PMD f6957067 PTE 0 Oops: 0000 [2] PREEMPT SMP This patch disables preemptions for the task upon entry to do_debug(), before interrupts are reenabled, and then disables preemption before exiting do_debug(), after disabling interrupts. I've noticed that the task can be preempted either at the end of an interrupt, or on the call to force_sig_info() on the spin_unlock_irqrestore() processing. It might be better to attempt to code a fix in entry.S around the code that calls do_debug(). Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jesse Allen authored
The orinoco wireless driver can support the SMC 2532W-B PC Card, so add the id for it. Signed-off-by: Jesse Allen <the3dfxdude@gmail.com> Cc: Pavel Roskin <proski@gnu.org> Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jeff Mahoney authored
Unfortunately, the reiserfs_attrs_cleared bit in the superblock flag can lie. File systems have been observed with the bit set, yet still contain garbage in the stat data field, causing unpredictable results. This patch backs out the enable-by-default behavior. It eliminates the changes from: d50a5cd860ce721dbeac6a4f3c6e42abcde68cd8, and ef5e5414e7a83eb9b4295bbaba5464410b11e030. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jesper Juhl authored
net/bridge/br_netfilter.c: In function `br_nf_post_routing': net/bridge/br_netfilter.c:808: warning: implicit declaration of function `has_bridge_parent' Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Cc: Harald Welte <laforge@netfilter.org> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 12 Feb, 2006 1 commit
-
-
Linus Torvalds authored
-