Signed-off-by: Vladislav Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Userland layer-2 tunneling devices allocated through the TUNTAP driver
(drivers/net/tun.c) have a type of ARPHRD_NONE, and have no link-layer
address. The kernel complains at regular interval when IPv6 Privacy
extension are enabled because it can't find an hardware address :
Dec 29 11:02:04 auguste kernel: __ipv6_regen_rndid(idev=cb3e0c00):
cannot get EUI64 identifier; use random bytes.
IPv6 Privacy extensions should probably be disabled on that sort of
device. They won't work anyway. If userland wants a more usual
Ethernet-ish interface with usual IPv6 autoconfiguration, it will use a
TAP device with an emulated link-layer and a random hardware address
rather than a TUN device.
As far as I could fine, TUN virtual device from TUNTAP is the very only
sort of device using ARPHRD_NONE as kernel device type.
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
We saw following trace several times:
|BUG: using smp_processor_id() in preemptible [00000001] code: httpd/30137
|caller is icmpv6_send+0x23/0x540
| [<c01ad63b>] smp_processor_id+0x9b/0xb8
| [<c02993e7>] icmpv6_send+0x23/0x540
This is because of icmpv6_socket, which is the only one user of
smp_processor_id() in icmpv6_send(), AFAIK.
Since it should be used in non-preemptive context,
let's defer the dereference after disabling preemption
(by icmpv6_xmit_lock()).
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
From: Ralf Baechle <ralf@linux-mips.org>
There are archives of the old list at http://oss.sgi.com/archives/netdev
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
<linux/if_tr.h> uses __be16, but does not directly include
<asm/byteorder.h>. Add this in, so that dhcp/net-tools token ring code
can compile again.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes a data corruption error for mail delivery applications that
expect to be able to do posix locking and then append writes on NFS.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This makes the EHCI driver spin a bit longer before concluding that the
port reset failed. "Obviously safe."
It allows some devices to enumerate that previously didn't. We've seen
a bunch of these problem reports recently, this will make some go away.
As reported by Michael Zapf <Michael.Zapf@uni-kassel.de>, some EHCI
controllers seem to take forever to finish port resets and produce
"port N reset error -110" type errors. Spinning a bit longer helps.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The pwc chainsaw session left some setups not working. There is a
sanity check on compression buffers that simply isn't right any more as
we never allocate one.
This doesn't address the email and other changes. I'll do those
tomorrow if I get time, but it is the minimal fix for the code and basic
feature set.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The current radeonfb memset's the framebuffer to 0 when loaded. This
removes occasional artifacts but has the nasty side effect that if you
load radeonfb without framebuffer console, you destroy the VGA text
buffer, font, etc... radeon must not touch the framebuffer content when
it doesn't "own" it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
M68k: Mark Sun-3 NCR5380 SCSI broken until NCR5380_abort() and
NCR5380_bus_reset() are replaced with real new-style EH routines (the old EH
SCSI constants were removed in 2.6.12-rc3).
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Now m68k no longer sets HAVE_ARCH_GET_SIGNAL_TO_DELIVER, can it be removed
completely? Or may ARM26 still need it? Note that its usage was removed from
kernel/signal.c about 2 months ago.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Patch from David Brownell
The ARM generic Kconfig filters out IDE options ... except for
an error prone ARMload of special cases.
This adds one general case to the systems that will offer IDE options:
kernels with PCMCIA support, which probably want to use IDE to access
CompactFlash cards. This might allow many (most?) of the other cases
to disappear, for systems that only see IDE hardware through CF cards.
Right now this one patch is used to gate access to CF cards, including
MicroDrives, for both omap_cf and at91_cf drivers.
Signed-off-by: David Brownell
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This removes a bogus hack from the radeon IRQ handler.
There is a better fix from myself and benh in DRM CVS but I'll wait
until 2.6.13-rc so it gets more testing.
Signed-off-by: Dave Airlie <airlied@linux.ie>
Despite all the care lately in making the powermac sleep/wakeup as
robust as possible, there is still a nasty related to the use of cpufreq
on PMU based machines. Unfortunately, it affects paulus old powerbook
so I have to fix it :)
We didn't manage to understand what is precisely going on, it leads to
memory corruption and might have to do with RAM not beeing properly
refreshed when a cpufreq transition is done right before the sleep.
The best workaround (and less intrusive at this point) we could come up
with is included in this patch. We basically do _not_ force a switch to
high speed on suspend anymore (that is what is causing the problem) on
those machines. We still force a speed switch on wakeup (since we don't
know what speed we are coming back from sleep at, and that seems to work
fine).
Since, during this short interval, the actual CPU speed might be
incorrect, we also hack around by multiplying loops_per_jiffy by 2 (max
speed factor on those machines) during early wakeup stage to make sure
udelay's during that time aren't too short.
For after 2.6.12, we'll change udelay implementation to use the CPU
timebase (which is always constant) instead like we do on ppc64 and thus
get rid of all those problems.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
My patch from a few weeks back (now in mainline), called "Cleanup skbs to
prevent unregister_netdevice() hanging", can cause our TX timeout code to
fire on machines with lots of VLANs (because it takes > 2 seconds between
when we stop the queues and when we're finished stopping the connections).
When that happens the TX timeout code freaks out and does a WARN_ON()
because as far as it's concerned there shouldn't be a TX timeout happening,
which is fair enough.
I have a "proper" fix for this, which is to a) do refcounting on
connections and b) implement a proper ack timer so we don't keep unacked
skbs lying around for ever. But for 2.6.12 I propose just supressing the
WARN_ON(). Users will still see the "NETDEV WATCHDOG" warning, but that's
not nearly as bad as a WARN_ON() which users interpret as an Oops.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add a definition for PPC 405EP which was lost somehow during 2.4 -> 2.6
transition.
Recent change to arch/ppc/kernel/misc.S ("Fix incorrect CPU_FTR fixup usage
for unified caches") triggered this bug and 405EP boards don't boot
anymore.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
MSI functionality is broken on the GC_LE x86 chipset that Serverworks
developed and that is being used in various platforms today. Broadcom is
going to push out to the kernel MSI enabled Gigabit drivers (in the very
near future), and we would like to make sure that MSI does not get
enabled on any platforms using the GC_LE chipset (device id 0x17).
Following the AMD 8131 example, I am including a patch to disable MSI
functionality when a GCNB_LE is detected. Please let me know if there
are any issues with this. This is a permanent fix for this chipset, as
the hardware will not be updated.
Signed-off-by: Narendra Sankar <nsankar@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
and add_to_page_cache fails.
Thanks to Shaggy for pointing out the fix.
Signed-off-by: Steve French (sfrench@us.ibm.com)
Signed-off-by: Shaggy (shaggy@us.ibm.com)
Patch from Vincent Sanders
This fixes the "multiple definitions of cpufreq_get" build faliure on
the hackkit SA1100 platform.
Signed-off-by: Vincent Sanders
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Vincent Sanders
This fixes the "multiple definitions of cpufreq_get" build faliure on
the Badge4 SA1100 platform.
Signed-off-by: Vincent Sanders
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
current->blocked will be set to the value of current->thread_info->flags if the
cmpxchg to update thread_info->flags fails. For performance reasons the store into
current->blocked was placed in the cmpxchg loop. However, the cmpxchg overwrites the
register holding the value to be stored. In the rare case of a retry the value of
thread_info->flags will be written into current->blocked.
The fix is to use another register so that the register containing the current->blocked
value is not overwritten.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Patch from Dave Neuer
This fixes the "multiple definitions of cpufreq_get" errors on
StrongARM-based iPAQs.
Signed-off-by: Dave Neuer
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ftdi_sio: Avoid losing bytes at tty-ldisc.
This patch was originally developed by Daniel Smertnig. I
(Ian Abbott) made a few changes. It has been tested by both
Daniel and I, at least for raw, non-canonical receive data
processing.
Here is Daniel's original description of the patch:
===
During a project in which I was using a FTDI 232BM to
transmit data at relative high speeds (625kBit/s), I
noticed a problem where data was lost even if flow
control was enabled: The FTDI-Driver receives 512 Bytes
of data over USB at a time, which consists of 8 64-Byte
packets. Subtracting the 2 bytes of status information
included in each packet this gives 496 "real" data
bytes per read.
This data is passed (indirectly, via the flip buffers)
to the tty line discipline which takes care of
throttling when there the free buffer space reaches
TTY_THRESHOLD_THROTTLE (128). Because the FTDI driver
processes up to 496 bytes at a time, throttling won't
happen in time and the line discipline will discard the
remaining bytes.
To avoid this the patch passes data in 62-byte blocks
to the tty layer and checks the available space in the
ldisc-buffers. If there isn't enough free space,
processing the rest of the data is delayed using a
workqueue.
Note: The original problem should be easily
reproducible with a userspace program which does slow &
small reads.
===
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Daniel Smertnig <daniel.smertnig@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This smoothes two imperfections:
- Increase number of LUNs per device from 4 to 9. The best solution
would be to remove this limit altogether, but that has to wait until
the time when more than 26 hosts are allowed.
- Replace mdelay with msleep in a probing routine.
Signed-off-by: Pete Zaitcev <zaitcev@yahoo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here's a patch that fixes up the pci_dev refcounting in the CPCI code.
I've done some testing against it and it seems fine here.
Signed-off-by: Scott Murray <scottm@somanetworks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Problem:
Incorrect md5sum when using ATAPI PIO mode to verify a distro CD.
Root cause: sg traverse problem.
In __atapi_pio_bytes(), if qc->cursg++ is increased and "goto
next_page" is executed, then sg is not updated to the new qc->cursg
and the old sg is overwritten with the new data.
Changes:
- Replace "goto next_page" with "goto next_sg" to make sg updated.
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
This patch fixes some bugs in the ppc64 PER_LINUX32 implementation,
noted by Juergen Kreileder:
* uname(2) doesn't respect PER_LINUX32, it returns 'ppc64' instead of 'ppc'
* Child processes of a PER_LINUX32 process don't inherit PER_LINUX32
Along the way I took the opportunity to move things around so that
sys_ppc32.c only has 32-bit syscall emulation functions and to remove
the obsolete "fakeppc" command line option.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
READA errors failing with EWOULDBLOCK/EAGAIN do not constitute a valid
reason for failing the path; this lead to erratic errors on DM multipath
devices. This error can be safely propagated upwards without failing the
path.
Acked-by: Kevin Corry <kevcorry@us.ibm.com>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Lars Marowsky-Bree <lmb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There've been reports of problems with CONFIG_PREEMPT=y and the high
floating point partition. This is caused by the possibility of preemption
and rescheduling on a different processor while saving or restioirng the
high partition.
The only places where the FPU state is touched are in ptrace, in
switch_to(), and where handling a floating-point exception. In switch_to()
preemption is off. So it's only in trap.c and ptrace.c that we need to
prevent preemption.
Here is a patch that adds commentary to make the conditions clear, and adds
appropriate preempt_{en,dis}able() calls to make it so. In trap.c I use
preempt_enable_no_resched(), as we're about to return to user space where
the preemption flag will be checked anyway.
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remove spurious MSR_SE reset during kprobe processing.
single_step_exception() already does it for us. Reset it to be safe when
executing the fault_handler.
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
