Cc: kraxel@bytesex.org
This is a tiny patch that fixes bttv-cards.c so that Leadtek WinFast
VC100 XP video capture cards work. I've been advised to post it here
after having already posted it to the v4l mailing list.
Acked-by: Gerd Knorr <kraxel@bytesex.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thanks to Mark Lord <mlord@pobox.com> for reporting this and helping with testing.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
This is from Gentoo's 2.6.11 patchset. A problem was introduced in 2.6.10
where some users could not enable DMA on their disks (particularly ALi15x3
users). This was a small mistake with the no_lba48_dma flag.
I can't find the exact commit but this is definately included in 2.6.12-rc4.
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
There was too much/too few byteswapping done by driver and hardware in
matroxfb on big endian hardware. Change fixes mirrored/split/corrupted
letters seen on screen when using accelerated matroxfb mode.
Patch was tested on Mips (by Peter) and x86-64 (by Petr).
Signed-off-by: Peter 'p2' De Schrijver <p2@mind.be>
Signed-off-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
During a warm boot the device is in D3 and has troubles coming out of it.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
ioctl_by_bdev may only be used INSIDE the kernel. If the "arg" argument
refers to memory that is accessed by put_user/get_user in the ioctl
function, the memory needs to be in the kernel address space (that's the
set_fs(KERNEL_DS) doing in the ioctl_by_bdev). This works on i386 because
even with set_fs(KERNEL_DS) the user space memory is still accessible with
put_user/get_user. That is not true for s390. In short the ioctl
implementation of the pktcdvd device driver is horribly broken.
Signed-off-by: Peter Osterlund <petero2@telia.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[Patch] Fix raw device ioctl pass-through
Raw character devices are supposed to pass ioctls through to the block
devices they are bound to. Unfortunately, they are using the wrong
function for this: ioctl_by_bdev(), instead of blkdev_ioctl().
ioctl_by_bdev() performs a set_fs(KERNEL_DS) before calling the ioctl,
redirecting the user-space buffer access to the kernel address space.
This is, needless to say, a bad thing.
This was noticed first on s390, where raw IO was non-functioning. The
s390 driver config does not actually allow raw IO to be enabled, which
was the first part of the problem. Secondly, the s390 kernel address
space is distinct from user, causing legal raw ioctls to fail. I've
reproduced this on a kernel built with 4G:4G split on x86, which fails
in the same way (-EFAULT if the address does not exist kernel-side;
returns success without actually populating the user buffer if it does.)
The patch below fixes both the config and address-space problems. It's
based closely on a patch by Jan Glauber <jang@de.ibm.com>, which has
been tested on s390 at IBM. I've tested it on x86 4G:4G (split address
space) and x86_64 (common address space).
Kernel-address-space access has been assigned CAN-2005-1264.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.
As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Revert the msdos.c patch as it causes more problems than it helps right now.
(it got munged together with the i2c patch also, stupid scripts...)
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.
As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here's a patch that fixes
http://bugme.osdl.org/show_bug.cgi?id=4395.
Patch by Manu Abraham and Gerd Knorr:
Remove redundant bttv_reset_audio() which caused the computer to
freeze with some bt8xx based DVB cards when loading the bttv driver.
Signed-off-by: Johannes Stezenbach <js@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Gerd Knorr <kraxel@bytesex.org>
This fixes an oops in the eeprom driver. It was first reported here:
http://bugzilla.kernel.org/show_bug.cgi?id=4347
It was additionally discussed here (while tracking a completely
different bug):
http://archives.andrew.net.au/lm-sensors/msg30021.html
The patch is already in 2.6.12-rc1:
http://linux.bkbits.net:8080/linux-2.5/cset@1.2227
The oops happens when one reads data from the sysfs interface file such
that (off < 16) and (count < 16 - off). For example "sensors" from
lm_sensors 2.9.0 does this, and causes the oops.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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.
1374 if(dev->irq ==0 || request_irq(dev->irq, amd8111e_interrupt, SA_SHIRQ,
1375 dev->name, dev))
1376 return -EAGAIN;
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>
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>
Kernel 2.6.11, hardware is a MSI KT333-based board with an XP1800.
I'm oopsing on shutdown on a machine that has a Via Rhine adapter in it:
Unable to handle kernel paging request at virtual address e0803003
printing eip:
c01f262c
*pde = 014dc067
*pte = 00000000
Oops: 0000 [#1]
Modules linked in: cpufreq_userspace cpufreq_powersave cpufreq_ondemand
CPU: 0
EIP: 0060:[<c01f262c>] Not tainted VLI
EFLAGS: 00010292 (2.6.11)
EIP is at ioread8+0x2c/0x40
eax: e0803003 ebx: e0803003 ecx: c026b430 edx: e0803003
esi: dff90260 edi: e0802f80 ebp: dd117e74 esp: dd117e74
ds: 007b es: 007b ss: 0068
Process reboot (pid: 5769, threadinfo=dd117000 task=dfafa080)
Stack: dd117e8c c026b490 dff90040 c151ccd4 c044a1a8 b7fdc078 dd117ea4
c0253ad9
c151ccd4 00000042 fee1dead 00000001 dd117fbc c012461c c04d72a8 00000001
00000000 00010800 00000000 dd117ed8 c013b40b dffe7380 00030800 00000000
Call Trace:
[<c0103d5f>] show_stack+0x7f/0xa0
[<c0103efa>] show_registers+0x15a/0x1c0
[<c01040ce>] die+0xce/0x150
[<c0113406>] do_page_fault+0x356/0x692
[<c01039ff>] error_code+0x2b/0x30
[<c026b490>] rhine_shutdown+0x60/0x140
[<c0253ad9>] device_shutdown+0x89/0x8b
[<c012461c>] sys_reboot+0xac/0x200
[<c0102f71>] sysenter_past_esp+0x52/0x75
Code: 3d ff ff 03 00 89 c2 89 e5 77 20 66 31 c0 3d 00 00 01 00 75 0c
81 e2 ff ff 00 00 ec 0f b6 c0 c9 c3 0f 0b 37 00 7b 65 3b c0 eb ea <0f>
b6 00 eb ec eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 90 55
Seems like it is the ioread8 in:
/* 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>
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>
The status and received packets indication in the Rx descriptor ring
are not correctly reset when a descriptor is recycled.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] PCI: fix hotplug double free
With the brackets missed out func could be freed twice.
Found by Coverity tool
Signed-off-by: Alexander Nyberg <alexn@dsv.su.se>
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>
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>
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.
From: Dmitry Torokhov <dtor_core@ameritech.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
