khc@pm.waw.pl [Sat, 19 Mar 2005 05:47:12 +0000 (21:47 -0800)]
[PATCH] Fix kernel panic on receive with WAN Hitachi SCA HD6457x
Another patch for 2.6.11.x: already in main tree, fixes kernel panic on
receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101, PCI200SYN.
The attached patch fixes NULL pointer dereference on RX.
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Acked-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It seems to me that in the VIA Rhine device driver the requested irq might
not be freed in case the alloc_ring() function fails. alloc_ring()
can fail with a ENOMEM return value because of possible
pci_alloc_consistent() failures.
Updated to CodingStyle.
Signed-off-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
hugh@veritas.com [Sat, 19 Mar 2005 05:41:52 +0000 (21:41 -0800)]
[PATCH] tasklist left locked
On 4-way SMP, about one reboot in twenty hangs while killing processes:
exit needs exclusive tasklist_lock, but something still holds read_lock.
do_signal_stop race case misses unlock, and fixing it fixes the symptom.
Signed-off-by: Hugh Dickins <hugh@veritas.com> Acked-by: Roland McGrath <roland@redhat.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
http://bugme.osdl.org/show_bug.cgi?id=4279
Summary: When I try to start vpnc the net/core/skbuff.c:91 crash
This check is wrong, gcc optimizes it away:
if ((len -= sizeof(pi)) > len)
return -EINVAL;
This could be responsible for the BUG. If len is 2 or 3 and TUN_NO_PI
isn't set it underflows. alloc_skb() allocates len + 2, which is 0 or
1 byte. skb_reserve tries to reserve 2 bytes and things explode in
skb_put.
[TUN]: Fix check for underflow
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This function, as it's name implies, is supposed to only
return IPSEC objects which are in the XFRM_STATE_ACQ
("acquire") state. But it returns any object with the
matching sequence number.
This is wrong and confuses IPSEC daemons to no end.
[XFRM]: xfrm_find_acq_byseq should only return XFRM_STATE_ACQ states.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kaber@trash.net [Sat, 19 Mar 2005 05:37:15 +0000 (21:37 -0800)]
[PATCH] Fix crash while reading /proc/net/route
[IPV4]: Fix crash while reading /proc/net/route caused by stale pointers
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It seems to me that if in the amd8111e_open() fuction dev->irq isn't
zero and the irq request succeeds it might not get released anymore.
Specifically, on failure of the amd8111e_restart() call the function
returns -ENOMEM without releasing the irq. The amd8111e_restart()
function can fail because of various pci_alloc_consistent() and
dev_alloc_skb() calls in amd8111e_init_ring() which is being
called by amd8111e_restart.
dsd@gentoo.org [Sat, 19 Mar 2005 05:32:08 +0000 (21:32 -0800)]
[PATCH] Fix stereo mutes on Surround volume control
As of 2.6.11, I have no output out of the rear right speaker of my 4.1
surround sound setup. I am using snd-intel8x0 based on a Realtek ALC650F chip
on an nvidia motherboard.
A gentoo user with completely different hardware also ran into this:
http://bugs.gentoo.org/84276
2.6.11-mm3 fixes this problem and I've identified the specific fix, which is
already in the ALSA development tree. An ALSA developer asked me to submit the
fix for 2.6.11.x when I'd found it, so here it is :)
--
AC97 Codec
Fix stereo mutes on Surround volume control.
Fix deadlock in NetROM due to double locking. I was sent the patch by
Alan and have doublechecked it. This bug hits Net/ROM users really hard.
It's accepted by DaveM - but just too late to make it into 2.6.11.
[PATCH] CAN-2005-0384: Remote Linux DoS on ppp servers
Martin Schulze writes:
> Ben Martel and Stephen Blackheath have discovered a denial-of-service attack
> that a client of pppd can make that can hang the server machine. The bug is
> in the Linux kernel 2.6 (tested on 2.6.9), but it looks like it also exists
> in the 2.4 series.
Yes, this is my bug. :(
I would just do this instead:
Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
/* Hit power state D3 (sleep) */
iowrite8(ioread8(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW);
that fails. StickyHW is 0x83. lspci says:
0000:00:07.0 Ethernet controller: VIA Technologies, Inc. VT86C100A
[Rhine] (rev 06)
Flags: bus master, medium devsel, latency 32, IRQ 18
I/O ports at ec00 [size=128]
Memory at dfffff80 (32-bit, non-prefetchable) [size=128]
In other words, it's trying to read outside of the I/O range (0x80),
which matches the fauling address.
I'm guessing my chip revision doesn't support WOL, it's a crappy noname
card.
It does seem as if rhine_power_init checks quirks for rqWOL before
touching any registers. Should rhine_shutdown do the same? Proposed
patch below, which resolves the problem on my system.
Check to make sure WOL is supported before setting it up in
rhine_shutdown.
Signed-off-by: Olof Johansson <olof@austin.ibm.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
chrisw@osdl.org [Sun, 13 Mar 2005 05:46:45 +0000 (21:46 -0800)]
[PATCH] sis900 kernel oops fix
Backport of fix described below.
From: Herbert Xu <herbert@gondor.apana.org.au>
Fix bug #4223.
OK, this happened because we got preempted before sis900_mii_probe
finished setting the sis_priv->mii. Theoretically this can happen
with SMP as well but I suppose the number of SMP machines with sis900
is fairly small.
Anyway, the fix is to make sure that sis900_mii_probe is done before
the device can be opened. This patch does it by moving the setup
before register_netdevice.
Since the netdev name is not available before register_netdev, I've
changed the relevant printk's to use pci_name instead. Note that
one of those printk's may be called after register_netdev as well.
Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] Put back tcp_timer_bug_msg[] symbol export.
This wrecks the ipv6 modular build for a lot of people.
In fact, since I always build ipv6 modular I am surprised
I never hit this. My best guess is that my compiler is
optimizing the reference away, but that can never be
depended upon and the symbol export really is needed.
[TCP]: Put back tcp_timer_bug_msg[] symbol export.
It is needed for tcp_reset_xmit_timer(), which is invoked by
tcp_prequeue() which is invoked from tcp_ipv6.c
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
While working on the saa7110 driver I found a problem with the way
various video drivers (found on Zoran-based boards) prepare i2c messages
to be used by i2c_transfer. The drivers improperly copy the i2c client
flags as the message flags, while both sets are mostly unrelated. The
net effect in this case is to trigger an I2C block read instead of the
expected I2C block write. The fix is simply not to pass any flag,
because none are needed.
I think this patch qualifies hands down as a "critical bug fix" to be
included in whatever bug-fix-only trees exist these days. As far as I
can see, all Zoran-based boards are broken in 2.6.11 without this patch.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Matt Porter [Sun, 13 Mar 2005 05:39:19 +0000 (21:39 -0800)]
[PATCH] ppc32: Compilation fixes for Ebony, Luan and Ocotea
this patch fixes the problem, that the current kernel (linux-2.6.11-rc5)
could not be compiled, when "support for early boot texts over serial port"
(CONFIG_SERIAL_TEXT_DEBUG=y) is active.
Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com> Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
airlied@linux.ie [Sun, 13 Mar 2005 05:38:27 +0000 (21:38 -0800)]
[PATCH] drm missing memset can crash X server..
Egbert Eich reported a bug 2673 on bugs.freedesktop.org and tracked it
down to a missing memset in the setversion ioctl, this causes X server
crashes...
From: Egbert Eich <eich@pdx.freedesktop.org> Signed-off-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Lammerts [Sun, 13 Mar 2005 05:35:18 +0000 (21:35 -0800)]
[PATCH] cramfs: small stat(2) fix
When I stat(2) a device node on a cramfs, the st_blocks field is bogus
(it's derived from the size field which in this case holds the major/minor
numbers). This makes du(1) output completely wrong.
Signed-off-by: Eric Lammerts <eric@lammerts.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] fix amd64 2.6.11 oops on modprobe (saa7110)
This is a rewrite of the saa7110_write_block function, which was plain
broken in the case where the underlying adapter supports I2C_FUNC_I2C.
It also includes related fixes which ensure that different parts of the
driver agree on the number of registers the chip has.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some ACPI-related changes were recently made to i8042 discovery for ia64.
Unfortunately this broke a significant number of Dell laptops due to their
having incorrect BIOS tables.
So, for now, arrange for the new code to be ia64-only.
[PATCH] Fix for trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Here's a patch that will work for both PPC and PPC64. The proper way to
fix this in mainline is to merge -mm's cpu_has_feature patch, but for
the stable 2.6.11-series, this much less intrusive (i.e. just the pure
bugfix, not the cleanup part).
Signed-off-by: Olof Johansson <olof@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>