Mark Rustad [Mon, 17 Oct 2005 23:43:34 +0000 (16:43 -0700)]
[PATCH] kbuild: Eliminate build error when KALLSYMS not defined
The following build error happens with 2.6.14-rc4 when CONFIG_KALLSYMS is
not defined. The error message in a fragment of the output was:
CC arch/i386/lib/usercopy.o
AR arch/i386/lib/lib.a
/bin/sh: line 1: +@: command not found
make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
CHK include/linux/compile.h
Signed-off-by: Mark Rustad <mrustad@mac.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Zach Brown [Mon, 17 Oct 2005 23:43:33 +0000 (16:43 -0700)]
[PATCH] aio: revert lock_kiocb()
lock_kiocb() was introduced to serialize retrying and cancellation. In the
process of doing so it tried to sleep waiting for KIF_LOCKED while holding
the ctx_lock spinlock. Recent fixes have ensured that multiple concurrent
retries won't be attempted for a given iocb. Cancel has other problems and
has no significant in-tree users that have been complaining about it. So
for the immediate future we'll revert sleeping with the lock held and will
address proper cancellation and retry serialization in the future.
Signed-off-by: Zach Brown <zach.brown@oracle.com> Acked-by: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Stephan Brodkorb [Mon, 17 Oct 2005 23:43:30 +0000 (16:43 -0700)]
[PATCH] n_r3964 mod_timer() fix
Since Revision 1.10 was released the n_r3964 module wasn't able to receive any
data. The reason for that behavior is because there were some wrong calls of
mod_timer(...) in the function receive_char (...). This patch should fix this
problem and was successfully tested with talking to some kuka industrial
robots.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Trond Myklebust [Mon, 17 Oct 2005 10:02:00 +0000 (06:02 -0400)]
[PATCH] NFS: Fix cache consistency races
If the data cache has been marked as potentially invalid by nfs_refresh_inode,
we should invalidate it rather than assume that changes are due to our own
activity.
Also ensure that we always start with a valid cache before declaring it
to be protected by a delegation.
Christian Krause [Mon, 17 Oct 2005 21:30:48 +0000 (14:30 -0700)]
[PATCH] USB: fix bug in handling of highspeed usb HID devices
During the development of an USB device I found a bug in the handling of
Highspeed HID devices in the kernel.
What happened?
Highspeed HID devices are correctly recognized and enumerated by the
kernel. But even if usbhid kernel module is loaded, no HID reports are
received by the kernel.
The output of the hardware USB analyzer told me that the host doesn't
even poll for interrupt IN transfers (even the "interrupt in" USB
transfer are polled by the host).
After some debugging in hid-core.c I've found the reason.
In case of a highspeed device, the endpoint interval is re-calculated in
driver/usb/input/hid-core.c:
Because of this the value of urb->interval is sometimes negative and is
rejected in core/urb.c:
line 353:
/* too small? */
if (urb->interval <= 0)
return -EINVAL;
The conclusion is, that the recalculaton of the interval (which is
necessary for highspeed) should not be made twice, because this is
simply wrong. ;-)
Re-calculation in usb_fill_int_urb makes more sense, because it is the
most general approach. So it would make sense to remove it from
hid-core.c.
Because in hid-core.c the interval variable is only used for calling
usb_fill_int_urb, it is no problem to remove the highspeed
re-calculation in this file.
Olav Kongas [Mon, 17 Oct 2005 21:30:43 +0000 (14:30 -0700)]
[PATCH] isp116x-hcd: fix handling of short transfers
Increased use of scatter-gather by usb-storage driver after 2.6.13 has
exposed a buggy codepath in isp116x-hcd, which was probably never
visited before: bug happened only for those urbs, for which
URB_SHORT_NOT_OK was set AND short transfer occurred.
The fix attached was tested in 2 ways: (a) it fixed failing
initialization of a flash drive with an embedded hub; (b) the fix was
tested with 'usbtest' against a modified g_zero driver (on top of
net2280), which generated short bulk IN transfers of various lengths
including multiples and non-multiples of max_packet_length.
Linus Torvalds [Mon, 17 Oct 2005 16:10:15 +0000 (09:10 -0700)]
Increase default RCU batching sharply
Dipankar made RCU limit the batch size to improve latency, but that
approach is unworkable: it can cause the RCU queues to grow without
bounds, since the batch limiter ended up limiting the callbacks.
So make the limit much higher, and start planning on instead limiting
the batch size by doing RCU callbacks more often if the queue looks like
it might be growing too long.
Ronald S. Bultje [Mon, 17 Oct 2005 03:29:25 +0000 (20:29 -0700)]
[PATCH] fix black/white-only svideo input in vpx3220 decoder
Fix the fact that the svideo input will only give input in black/white in
some circumstances. Reason is that in the PCI controller driver (zr36067),
after setting input, we reset norm, which overwrites the input register
with the default. This patch makes it always set the correct value for the
input when changing norm.
Signed-off-by: Ronald S. Bultje <rbultje@ronald.bitfreak.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ronald S. Bultje [Mon, 17 Oct 2005 03:29:24 +0000 (20:29 -0700)]
[PATCH] fix vpx3220 offset issue in SECAM
Fix bug #5404 in kernel bugzilla.
It basically updates the vpx3220 initialization tables with some newer
values that we've had in CVS for a while (and that, for some reason, never
ended up in the kernel... must've gotten lost). Those fix a ~16 pixels
noise at the top of the picture in at least SECAM, although (now that I
think about it) PAL was probably affected, also.
Signed-off-by: Ronald S. Bultje <rbultje@ronald.bitfreak.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Samuel Thibault [Mon, 17 Oct 2005 03:29:22 +0000 (20:29 -0700)]
[PATCH] SVGATextMode fix
Fix bug 5441.
I didn't know about messy programs like svgatextmode... Couldn't this be
integrated in some linux/drivers/video/console/svgacon.c ?... So because
of the existence of the svgatextmode program, the kernel is not supposed to
touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?
Disabling the check in vgacon_resize() might help indeed, but I'm really
not sure whether it will work for any chipset: in my patch, CRT registers
are set at each console switch, since stty rows/cols apply to consoles
separately...
The attached solution is to keep the test, but if it fails, we assume that
the caller knows what it does (i.e. it is svgatextmode) and then disable
any further call to vgacon_doresize. Svgatextmode is usually used to
_expand_ the display, not to shrink it. And it is harmless in the case of
a too big stty rows/cols: the display will just be cropped. I tested it on
my laptop, and it works fine with svgatextmode.
A better solution would be that svgatextmode explicitely tells the kernel
not to care about video timing, but for this an interface needs be defined
and svgatextmode be patched.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Without the missing barrier, the pos->next value may turn out to be stale.
In fact, if "do stuff" were also dereferencing pos and relying on
list_for_each_rcu to provide the barrier then it may also break.
So here is a patch to make sure that we have a barrier for the first
element in the list.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: "Paul E. McKenney" <paulmck@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Linus Torvalds [Mon, 17 Oct 2005 00:36:06 +0000 (17:36 -0700)]
Fix memory ordering bug in page reclaim
As noticed by Nick Piggin, we need to make sure that we check the page
count before we check for PageDirty, since the dirty check is only valid
if the count implies that we're the only possible ones holding the page.
We always did do this, but the code needs a read-memory-barrier to make
sure that the orderign is also honored by the CPU.
(The writer side is ordered due to the atomic decrement and test on the
page count, see the discussion on linux-kernel)
Al Viro [Sun, 16 Oct 2005 07:17:33 +0000 (00:17 -0700)]
[PATCH]: highest_possible_processor_id() has to be a macro
... otherwise, things like alpha and sparc64 break and break
badly. They define cpu_possible_map to something else in smp.h
*AFTER* having included cpumask.h.
If that puppy is a macro, expansion will happen at the actual
caller, when we'd already seen #define cpu_possible_map ... and we will
get the right thing used.
As an inline helper it will be tokenized before we get to that
define and that's it; no matter what we define later, it won't affect
anything. We get modules with dependency on cpu_possible_map instead
of the right symbol (phys_cpu_present_map in case of sparc64), or outright
link errors if they are built-in.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
Randall Nortman [Sat, 15 Oct 2005 00:21:50 +0000 (17:21 -0700)]
[PATCH] usbserial: Regression in USB generic serial driver
Kernel version 2.6.13 introduced a regression in the generic USB
serial converter driver (usbserial.o, drivers/usb/serial/generic.c).
The bug manifests, as far as I can tell, whenever you attempt to write
to the device -- the write will never complete (write() returns 0, or
blocks).
Evgeniy Polyakov [Fri, 14 Oct 2005 22:59:11 +0000 (15:59 -0700)]
[PATCH] Dallas's 1-wire bus compile error
drivers/built-in.o: In function `w1_alloc_dev': undefined reference to `netlink_kernel_create'
drivers/built-in.o: In function `w1_alloc_dev': undefined reference to `sock_release'
Matteo Croce [Fri, 14 Oct 2005 22:59:06 +0000 (15:59 -0700)]
[PATCH] wireless/airo: Build fix
The aironet PCI driver has a build dependency on ISA that prevent the
driver to compile on systems that doesn't support ISA, like x86_64. The
driver really doesn't depend on ISA, it does some ISA stuff in the
initialization code, since the driver supports both ISA and PCI cards. So
the driver should depend on ISA_DMA_API to build on all systems, and this
will not hurt PCI at all.
Tim Schmielau [Fri, 14 Oct 2005 22:59:05 +0000 (15:59 -0700)]
[PATCH] Fix copy-and-paste error in BSD accounting
Fix copy and paste error in jiffies_to_AHZ conversion which leads to wrong
BSD accounting information on alpha and ia64 when
CONFIG_BSD_PROCESS_ACCT_V3 is turned on.
Also update comment to match reorganised header files.
Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Yoichi Yuasa [Fri, 14 Oct 2005 22:59:00 +0000 (15:59 -0700)]
[PATCH] mips: fix build error in TANBAC TB0226
arch/mips/pci/fixup-tb0226.c: In function `pcibios_map_irq':
arch/mips/pci/fixup-tb0226.c:31: warning: implicit declaration of function `vr41xx_set_irq_trigger'
arch/mips/pci/fixup-tb0226.c:32: error: `TRIGGER_LEVEL' undeclared (first use in this function)
arch/mips/pci/fixup-tb0226.c:32: error: (Each undeclared identifier is reported only once
arch/mips/pci/fixup-tb0226.c:32: error: for each function it appears in.)
arch/mips/pci/fixup-tb0226.c:33: error: `SIGNAL_THROUGH' undeclared (first use in this function)
arch/mips/pci/fixup-tb0226.c:34: warning: implicit declaration of function `vr41xx_set_irq_level'
arch/mips/pci/fixup-tb0226.c:34: error: `LEVEL_LOW' undeclared (first use in this function)
David S. Miller [Fri, 14 Oct 2005 22:26:08 +0000 (15:26 -0700)]
[SPARC64]: Fix powering off on SMP.
Doing a "SUNW,stop-self" firmware call on the other cpus is not the
correct thing to do when dropping into the firmware for a halt,
reboot, or power-off.
For now, just do nothing to quiet the other cpus, as the system should
be quiescent enough. Later we may decide to implement smp_send_stop()
like the other SMP platforms do.
Based upon a report from Christopher Zimmermann.
Signed-off-by: David S. Miller <davem@davemloft.net>
Richard Purdie [Fri, 14 Oct 2005 15:07:25 +0000 (16:07 +0100)]
[ARM] 3011/1: pxafb: Add ability to set device parent + fix spitz compile error
Patch from Richard Purdie
Add a function to allow machines to set the parent of the pxa
framebuffer device. This means the power up/down sequence can be
controlled where required by the machine.
Update spitz to use the new function, fixing a compile error.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Deepak Saxena [Fri, 14 Oct 2005 11:49:15 +0000 (12:49 +0100)]
[ARM] 2980/1: Fix L7200 core.c compile
Patch from Deepak Saxena
This patch fixes L7200 so that it builds in 2.6.latest. I do not
have the hardware so don't know if it actually still works, but
the changes are fairly trivial. I am not even sure if anyone
still maintains, uses, or cares about this machine type.
Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ben Dooks [Fri, 14 Oct 2005 11:24:24 +0000 (12:24 +0100)]
[ARM] 3009/1: S3C2410 - io.h offsets too large for LDRH/STRH
Patch from Ben Dooks
The __inwc/__outwc calls are capable of creating
LDRH and STRH instructions with offsets over 8bits
as GCC does not have a constraint for an 8bit
offset.
Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Andi Kleen [Thu, 13 Oct 2005 21:41:44 +0000 (14:41 -0700)]
[NET]: Disable NET_SCH_CLK_CPU for SMP x86 hosts
Opterons with frequency scaling have fully unsynchronized TSCs
running at different frequencies, so using TSCs there is not a good idea.
Also some other x86 boxes have this problem. gettimeofday should be good
enough, so just disable it.
Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Dooks [Wed, 12 Oct 2005 22:12:21 +0000 (15:12 -0700)]
[NETPOLL]: wrong return for null netpoll_poll_lock()
When netpoll is not being used, the macro that
defines the removed routing netpoll_poll_lock
defines the return as zero, but the real
routine returns a `void *`
Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes the RCU race on bridge delete interface. Basically,
the network device has to be detached from the bridge in the first
step (pre-RCU), rather than later. At that point, no more bridge traffic
will come in, and the other code will not think that network device
is part of a bridge.
This should also fix the XEN test problems.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 12 Oct 2005 19:22:46 +0000 (12:22 -0700)]
[SPARC64]: Fix boot failures on SunBlade-150
The sequence to move over to the Linux trap tables from
the firmware ones needs to be more air tight. It turns
out that to be %100 safe we do need to be able to translate
OBP mappings in our TLB miss handlers early.
In order not to eat up a lot of kernel image memory with
static page tables, just use the translations array in
the OBP TLB miss handlers. That solves the bulk of the
problem.
Furthermore, to make sure the OBP TLB miss path will work
even before the fixed MMU globals are loaded, explicitly
load %g1 to TLB_SFSR at the beginning of the i-TLB and
d-TLB miss handlers.
To ease the OBP TLB miss walking of the prom_trans[] array,
we sort it then delete all of the non-OBP entries in there
(for example, there are entries for the kernel image itself
which we're not interested in at all).
We also save about 32K of kernel image size with this change.
Not a bad side effect :-)
There are still some reasons why trampoline.S can't use the
setup_trap_table() yet. The most noteworthy are:
1) OBP boots secondary processors with non-bias'd stack for
some reason. This is easily fixed by using a small bootup
stack in the kernel image explicitly for this purpose.
2) Doing a firmware call via the normal C call prom_set_trap_table()
goes through the whole OBP enter/exit sequence that saves and
restores OBP and Linux kernel state in the MMUs. This path
unfortunately does a "flush %g6" while loading up the OBP locked
TLB entries for the firmware call.
If we setup the %g6 in the trampoline.S code properly, that
is in the PAGE_OFFSET linear mapping, but we're not on the
kernel trap table yet so those addresses won't translate properly.
One idea is to do a by-hand firmware call like we do in the
early bootup code and elsewhere here in trampoline.S But this
fails as well, as aparently the secondary processors are not
booted with OBP's special locked TLB entries loaded. These
are necessary for the firwmare to processes TLB misses correctly
up until the point where we take over the trap table.
This does need to be resolved at some point.
Signed-off-by: David S. Miller <davem@davemloft.net>
Lothar Wassmann [Wed, 12 Oct 2005 18:58:11 +0000 (19:58 +0100)]
[ARM] 3002/1: Wrong parameter to uart_update_timeout() in drivers/serial/pxa.c
Patch from Lothar Wassmann
The function serial_pxa_set_termios() is calling uart_update_timeout()
with the baud rate divisor as third parameter, while
uart_update_timeout() expects the baud rate in this place.
This results in a bogus port->timeout which is proportional to the
baud rate.
Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
George G. Davis [Wed, 12 Oct 2005 18:58:09 +0000 (19:58 +0100)]
[ARM] 2970/1: Use -mtune=arm1136j-s when building for CPU_V6 targets
Patch from George G. Davis
When building for CPU_V6 targets, we should use -mtune=arm1136j-s rather
than -mtune=strongarm but fall back to the later in case someone is
using an older toolchain (although they should really upgrade instead).
Signed-off-by: George G. Davis <gdavis@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ben Dooks [Wed, 12 Oct 2005 18:58:06 +0000 (19:58 +0100)]
[ARM] 2976/1: S3C2410: add static to functions in serial driver
Patch from Ben Dooks
The s3c2410 serial driver is missing static declerations
on several functions that are not exported, and have no
need of being exported outside the driver
Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ben Dooks [Wed, 12 Oct 2005 18:58:05 +0000 (19:58 +0100)]
[ARM] 2975/1: S3C2410: time.c missing include of cpu.h
Patch from Ben Dooks
arch/arm/mach-s3c2410/time.c is missing include
of cpu.h, causing the declaration of the timer
struct (s3c24xx_timer) to be flagged as missing
the declaration.
Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Nicolas Pitre [Wed, 12 Oct 2005 18:51:24 +0000 (19:51 +0100)]
[ARM] 2974/1: fix ARM710 swi bug workaround
Patch from Nicolas Pitre
Either no one is using an ARM710 with recent kernels, or all ARM710s
still in use are not afflicted by this swi bug. Nevertheless, the code
to work around the ARM710 swi bug is itself currently buggy since it
uses r8 as a pointer to S_PC while in fact it holds the spsr content
these days. Fix that, and simplify the code as well.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[PATCH] ppc32: Tell userland about lack of standard TB
Glibc is about to get some new high precision timer stuff that relies on
the standard timebase of the PPC architecture.
However, some (rare & old) CPUs do not have such timebase and it is a
bit annoying to have your stuff just crash because you are running on
the wrong CPU...
This exposes to userland a CPU feature bit that tells that the current
processor doesn't have a standard timebase. It's negative logic so that
glibc will still "just work" on older kernels (it will just be unhappy
on those old CPUs but that doesn't really matter as distro tend to
update glibc & kernel at the same time).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Interestingly enough, ppc32 had broken timekeeping for ages... It
worked, but probably drifted a bit more than could be explained by the
actual bad precision of the timebase calibration. We discovered that
recently when somebody figured out that the common code was using
CLOCK_TICK_RATE to correct the timekeeing, and ppc32 had a completely
bogus value for it.
This patch turns it into something saner. Probably not as good as doing
something based on the actual timebase frequency precision but I'll
leave that sort of math to others. This at least makes it better for
the common HZ values.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Give an empty definition for clear_can_do_skas() when it is not needed.
Thanks to Junichi Uekawa <dancer@netfort.gr.jp> for reporting the
breakage and providing a fix (I re-fixed it in an IMHO cleaner way).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jeff Dike [Tue, 11 Oct 2005 03:10:32 +0000 (23:10 -0400)]
[PATCH] uml: revert block driver use of host AIO
The patch to use host AIO support that I submitted early after 2.6.13 exposed
some problems in the block driver. I have fixes for these, but am not
comfortable putting them into 2.6.14 at this late date. So, this patch reverts
the use of host AIO.
I will resubmit the original patch, plus fixes to the driver after 2.6.14
in order to get a reasonable amount of testing before they're exposed to
the general public.
Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
David S. Miller [Tue, 11 Oct 2005 22:45:16 +0000 (15:45 -0700)]
[SPARC64]: Fix net booting on Ultra5
We were not doing alignment properly when remapping the kernel image.
What we want is a 4MB aligned physical address to map at KERNBASE.
Mistakedly we were 4MB aligning the virtual address where the kernel
initially sits, that's wrong.
Instead, we should PAGE align the virtual address, then 4MB align the
physical address result the prom gives to us.
Signed-off-by: David S. Miller <davem@davemloft.net>
akpm@osdl.org [Tue, 11 Oct 2005 15:29:08 +0000 (08:29 -0700)]
[PATCH] binfmt_elf bss padding fix
Nir Tzachar <tzachar@cs.bgu.ac.il> points out that if an ELF file specifies a
zero-length bss at a whacky address, we cannot load that binary because
padzero() tries to zero out the end of the page at the whacky address, and
that may not be writeable.
See also http://bugzilla.kernel.org/show_bug.cgi?id=5411
So teach load_elf_binary() to skip the bss settng altogether if the elf file
has a zero-length bss segment.
Cc: Roland McGrath <roland@redhat.com> Cc: Daniel Jacobowitz <dan@debian.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Paolo Galtieri [Tue, 11 Oct 2005 15:29:07 +0000 (08:29 -0700)]
[PATCH] ppc highmem fix
I've noticed that the calculations for seg_size and nr_segs in
__dma_sync_page_highmem() (arch/ppc/kernel/dma-mapping.c) are wrong. The
incorrect calculations can result in either an oops or a panic when running
fsck depending on the size of the partition.
The problem with the seg_size calculation is that it can result in a
negative number if size is offset > size. The problem with the nr_segs
caculation is returns the wrong number of segments, e.g. it returns 1 when
size is 200 and offset is 4095, when it should return 2 or more.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Suzuki [Tue, 11 Oct 2005 15:29:06 +0000 (08:29 -0700)]
[PATCH] madvise: Avoid returning error code -EBADF for anonymous mappings
Revert this recent correctness change: Douglas Crosher <dcrosher@scieneer.com>
reported that it broke an existing application, and that madvise() works
without error on anonymous mappings on Solaris.
This means that madvise() will remain non-standards-compliant: we should
return -EBADF for all requests against non-file-backed vma's, but Linux only
does this for MADV_WILLNEED requests.
Signed-off-by: Suzuki K P <suzuki@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Here is a compatibility fix between Linux and Solaris when used with VxFS
filesystems: Solaris usually accepts acl entries in any order, but with
VxFS it replies with NFSERR_INVAL when it sees a four-entry acl that is not
in canonical form. It may also fail with other non-canonical acls -- I
can't tell, because that case never triggers: We only send non-canonical
acls when we fake up an ACL_MASK entry.
Instead of adding fake ACL_MASK entries at the end, inserting them in the
correct position makes Solaris+VxFS happy. The Linux client and server
sides don't care about entry order. The three-entry-acl special case in
which we need a fake ACL_MASK entry was handled in xdr_nfsace_encode. The
patch moves this into nfsacl_encode.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Acked-by: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Latchesar Ionkov [Tue, 11 Oct 2005 15:29:03 +0000 (08:29 -0700)]
[PATCH] v9fs: remove additional buffer allocation from v9fs_file_read and v9fs_file_write
v9fs_file_read and v9fs_file_write use kmalloc to allocate buffers as big
as the data buffer received as parameter. kmalloc cannot be used to
allocate buffers bigger than 128K, so reading/writing data in chunks bigger
than 128k fails.
This patch reorganizes v9fs_file_read and v9fs_file_write to allocate only
buffers as big as the maximum data that can be sent in one 9P message.
Signed-off-by: Latchesar Ionkov <lucho@ionkov.net> Cc: Eric Van Hensbergen <ericvh@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Abhay Salunke [Tue, 11 Oct 2005 15:29:02 +0000 (08:29 -0700)]
[PATCH] dell_rbu: changes in packet update mechanism
In the current dell_rbu code ver 2.0 the packet update mechanism makes the
user app dump every individual packet in to the driver.
This adds in efficiency as every packet update makes the
/sys/class/firmware/dell_rbu/loading and data files to disappear and reappear
again. Thus the user app needs to wait for the files to reappear to dump
another packet. This slows down the packet update tremendously in case of
large number of packets. I am submitting a new patch for dell_rbu which will
change the way we do packet updates;
In the new method the user app will create a new single file which has already
packetized the rbu image and all the packets are now staged in this file.
This driver also creates a new entry in
/sys/devices/platform/dell_rbu/packet_size ; the user needs to echo the packet
size here before downloading the packet file.
The user should do the following:
create one single file which has all the packets stacked together.
echo the packet size in to /sys/devices/platform/dell_rbu/packet_size.
echo 1 > /sys/class/firmware/dell_rbu/loading
cat the packetfile > /sys/class/firmware/dell_rbu/data
echo 0 > /sys/class/firmware/dell_rbu/loading
The driver takes the file which came through /sys/class/firmware/dell_rbu/data
and takes chunks of paket_size data from it and place in contiguous memory.
This makes packet update process very efficient and fast. As all the packet
update happens in one single operation. The user can still read back the
downloaded file from /sys/devices/platform/dell_rbu/data.
projects / linux-beck.git / log