In-Reply-To: <[EMAIL PROTECTED]>
On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote:
> do you think it may be a bug in the kernel? the stuff with wine that
> gets thrown in the kernel messages?
Let's just say the behavior has changed. It now returns
-EINVAL instead of -ENOTTY when the
On Wed, 13 Dec 2006 03:59:45 GMT
Linux Kernel Mailing List wrote:
> IB: Add DMA mapping functions to allow device drivers to interpose
>
> The QLogic InfiniPath HCAs use programmed I/O instead of HW DMA.
> This patch allows a verbs device driver to interpose on DMA mapping
>
Hi all,
Running some IO stress tests on a 8*ways IA64 platform, we got:
BUG: warning at kernel/mutex.c:132/__mutex_lock_common() message
followed by:
Unable to handle kernel paging request at virtual address
00200200
oops corresponding to anon_vma_unlink() calling list_del() on
Replace kmalloc+memset with kcalloc + remove now unused size variable
Signed-off-by: Yan Burman <[EMAIL PROTECTED]>
diff -rubp linux-2.6.19_orig/drivers/net/e1000/e1000_ethtool.c
linux-2.6.19_tests/drivers/net/e1000/e1000_ethtool.c
--- linux-2.6.19_orig/drivers/net/e1000/e1000_ethtool.c
Hi,
This patch provides a feature which enables you to specify the memory
segment types you don't want to dump into a core file. You can specify
them per process via /proc//coremask file. This file represents
the bitmask of memory segment types which are not written out when the
process is
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>
>> Your or I missed a bug fix/enhancement in there somewhere.
>>
>
> I found the problem. the __set_fixmap need to __va, so the entries
> will be referred from PAGE_OFFSET.
>
> solution will be
Dmitry Torokhov wrote:
> Hi Andres,
[...]
>
> Unfortunately I do not think this is going to work well in in default case:
>
> 1. PS/2 probing order is important. You need to probe for intellimouse
>explorer last otherwise you might miss that mouse supports extended
>protocol.
>
Sorry,
On Tue, Dec 12 2006, AVANTIKA R. MATHUR wrote:
> >That said, I might add some logic to detect when we can cheaply switch
> >queues instead of waiting for a new request from the same queue.
> >Averaging slice times over a period of time instead of 1:1 with that
> >logic, should help cases like this
On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Your or I missed a bug fix/enhancement in there somewhere.
I found the problem. the __set_fixmap need to __va, so the entries
will be referred from PAGE_OFFSET.
solution will be
1. move enable_dbgp_console from setup_early_printk, and
On Wed, Dec 13, 2006 at 02:12:23PM +0900, Shinichiro HIDA wrote:
> Hi,
>
> I met same problem on my 2 machines, 2.6.19 (Debian unstable) also
> 2.6.18.3 (Debian stable),
The trace:
> ;; [1] lune: debian unstable with 2.6.19
> Dec 12 21:31:25 lune kernel: [] xfs_da_do_buf+0x340/0xa10
> Dec 12
Hi,
Sure, we will post the results to the mailing list after analyzing them.
Moreover, we post a link to the proceedings of the conference where the
results are published.
--
Timo
> Hi,
>
> Well, I filled in the survey. Was wondering if you also post the results
> here at the mailing list.
Hi Andres,
On Tuesday 12 December 2006 23:31, Andres Salomon wrote:
> Hi,
>
> When Zephaniah Hull sent in a patch for the OLPC touchpad [0], it was
> suggested that the psmouse driver be split out into separate components.
> What's currently there is way too fat, and people are not happy about
Hi. I didn't want to leave this hanging and it stayed in my head so I
thought I'd better just finish it and test it.
I tried out this patch and it got rid of all three unaligned acces errors
I was seeing with process connectors and the patch is indeed much smaller.
I ran our container daemon
NeilBrown wrote:
Following are 14 patches for knfsd that are suitable for inclusion in 2.6.20.
First 13 are from Chuck Lever and make preparations for IPv6 support (I think
we've
get them right this time).
Last is from Peter Staubach and fixes and issue with exclusive create
interacting badly
Say a boot parameter is "xxx", if you give a string "xxxy", then the
boot parameter's corresponding function is executed. Is this intended?
If not, below patch fixes it.
diff --git a/init/main.c b/init/main.c
index 036f97c..d56940c 100644
--- a/init/main.c
+++ b/init/main.c
@@ -193,7 +193,8 @@
AVANTIKA R. MATHUR wrote on Tuesday, December 12, 2006 5:33 PM
> >> rawio is actually performing sequential reads, but I don't believe it is
> >> purely sequential with the multiple processes.
> >> I am currently running the test with longer runtimes and will post
> >> results once it is complete.
My bug http://bugzilla.kernel.org/show_bug.cgi?id=6419
Today I found that my computer hang problem could be just a problem with
via-rhine II.
I got exactly the same problem describe on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245398;msg=107
I had transfer by eth0 (via-rhine II), about
Hi Chaps,
Basically I detected this problem because I added another drive to my
PCI SATA card, and now the system is running dog slow.
I tracked it down to one of the drives being forced into PIO4 mode
rather than UDMA mode; dmesg bits:
sata_nv :00:0b.0: version 2.0
ACPI: PCI Interrupt
Hi folks !
What is the logic regarding VM_RESERVED, and more specifically, why is
vm_normal_page() nor returning NULL for these ?
I have struct pages that are a bit special for things like SPE mappings
on Cell and I'd like to avoid a lot of the stuff the VM tries to do on
them, like rmap
On Wed, Dec 13, 2006 at 12:35:33AM +0100, Adrian Bunk wrote:
> MODE_TT is both marked as deprecated and marked as BROKEN.
>
> Would a patch to remove MODE_TT, always enable MODE_SKAS, and doing all
> possible cleanups after this be accepted?
Thanks, but not yet.
I've got that queued up in my
On Mon, 2006-12-11 at 03:27 -0500, Chuck Ebbert wrote:
> In-Reply-To: <[EMAIL PROTECTED]>
>
> On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote:
>
> > > Kasper, what problems (other that the annoying message) are you having?
> > if it had only been the messages i wouldnt have complained.
Hi,
When Zephaniah Hull sent in a patch for the OLPC touchpad [0], it was
suggested that the psmouse driver be split out into separate components.
What's currently there is way too fat, and people are not happy about
adding even more code to the driver.
I've taken a stab at doing just that.
Trond Myklebust wrote:
On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
Note that these pages should be *really* rare. Definitely even for normal
filesystems I think RMW would use too much bandwidth if it were required
for any significant number of writes.
If file "foo" exists on the
Sending it again marking Jay Estabrook
-aneesh
Module loading on Alpha was failing with error
"Could not allocate 8 bytes percpu data".
Looking at dmesg we have the below error
"No per-cpu room for modules."
Increase the PERCPU_ENOUGH_ROOM in a similar way as x86_64
Signed-off-by: Aneesh
> But it's rather a lot of churn for such a thing. Did you consider simply
> using
> put_unaligned() against the specific offending field(s)?
Hi. This was not considered.
I wanted to give you some quick feedback, so I tried your suggestion in the
fork path. It seemed to fix the problem as
Andrew Morton wrote on Tuesday, December 12, 2006 2:40 AM
> On Tue, 12 Dec 2006 16:18:32 +0300
> Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
>
> > >> but according to filemaps locking rules: mm/filemap.c:77
> > >> ..
> > >> * ->i_mutex(generic_file_buffered_write)
> > >> *
On Tue, Dec 12, 2006 at 02:05:32PM -0800, Roland Dreier wrote:
> #if defined(__mc68000__)
> #warning What do we have to do here??
> #endif
> if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
>vma->vm_end -
On Tue, 12 Dec 2006, Pete Zaitcev wrote:
> Hi, Roman & All:
>
> In 2.6.19 (and Linus' curent tree), I found the following:
>
> libpath=$$dir/lib; lib=qt; osdir=""; \
> $(HOSTCXX) -print-multi-os-directory > /dev/null 2>&1 && \
> osdir=x$$($(HOSTCXX)
On Tue, 12 Dec 2006 20:31:32 -0600
Erik Jacobson <[EMAIL PROTECTED]> wrote:
> > But it's rather a lot of churn for such a thing. Did you consider simply
> > using
> > put_unaligned() against the specific offending field(s)?
>
> Hi. This was not considered.
>
> I wanted to give you some quick
On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
> Note that these pages should be *really* rare. Definitely even for normal
> filesystems I think RMW would use too much bandwidth if it were required
> for any significant number of writes.
If file "foo" exists on the server, and contains
On Wed, 13 Dec 2006, Nick Piggin wrote:
>
> parisc seems to, but sparc uses its own open coded spinlock for bitops, and
> the array of regular spinlocks for atomic ops. OTOH, consolidating them
> might give more scalable code *and* a smaller cacheline footprint?
Yeah, I think you'd actually
On Wed, 2006-12-13 at 11:53 +1100, Nick Piggin wrote:
> Not silly -- I guess that is the main sticking point. Luckily *most*
> !uptodate pages will be ones that we have newly allocated so will
> not be in pagecache yet.
>
> If it is in pagecache, we could do one of a number of things: either
>
Hi, Roman & All:
In 2.6.19 (and Linus' curent tree), I found the following:
libpath=$$dir/lib; lib=qt; osdir=""; \
$(HOSTCXX) -print-multi-os-directory > /dev/null 2>&1 && \
osdir=x$$($(HOSTCXX) -print-multi-os-directory); \
test -d $$libpath/$$osdir &&
Linus Torvalds wrote:
On Tue, 12 Dec 2006, Russell King wrote:
This seems to be a very silly question (and I'm bound to be utterly
wrong as proven in my last round) but why are we implementing a new
set of atomic primitives which effectively do the same thing as our
existing set?
Why can't
Trond Myklebust wrote:
On Wed, 2006-12-13 at 11:53 +1100, Nick Piggin wrote:
Not silly -- I guess that is the main sticking point. Luckily *most*
!uptodate pages will be ones that we have newly allocated so will
not be in pagecache yet.
If it is in pagecache, we could do one of a number of
On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > >Is there a kexec-tools patch too? How does second kernel know about
> > >the location of the first kernel's initrd to be reused?
> > >
> > >
> > kexec-tools has to be modified to pass the first kernel initrd. On
> > powerpc,
On Wed, 13 Dec 2006 09:17:42 +0800
Conke Hu <[EMAIL PROTECTED]> wrote:
> Thank you for applying ATI SB600 SATA patch!
> But it seems the patch file name should be
> "ati"-sb600-sata-quirk.patch, not "via"-sb600-sata-quirk.patch, type
> error? :)
That's the sort of thing which happens
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 17:24:35 +0100
> This patch converts drivers/net/loopback.c to using module_init().
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
I'm not %100 sure of this one, let's look at the comment you
are deleting:
> -/*
> - * The
On Tue, 12 Dec 2006, Russell King wrote:
>
> This seems to be a very silly question (and I'm bound to be utterly
> wrong as proven in my last round) but why are we implementing a new
> set of atomic primitives which effectively do the same thing as our
> existing set?
>
> Why can't we just use
On Wed, 13 Dec 2006 10:59:27 +1100
NeilBrown <[EMAIL PROTECTED]> wrote:
> From: Chuck Lever <[EMAIL PROTECTED]>
> The only reason svcsock.c looks at a sockaddr's port is to check whether
> the remote peer is connecting from a privileged port. Refactor this check
> to hide processing that is
> > +if RTC_CLASS != n
> > +
>
>
> if RTC_CLASS
>
>
> because otherwise
Thanks for the clarification. I think Alessandro was going to
redo this one soon, since the Kconfig changed so much the patch
would no longer apply. I trust he'll remember your comments!
- Dave
-
To unsubscribe from
MODE_TT is both marked as deprecated and marked as BROKEN.
Would a patch to remove MODE_TT, always enable MODE_SKAS, and doing all
possible cleanups after this be accepted?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been
Jens Axboe wrote:
On Fri, Dec 08 2006, Avantika Mathur wrote:
On Fri, 2006-12-08 at 13:05 +0100, Jens Axboe wrote:
On Thu, Dec 07 2006, Avantika Mathur wrote:
Hi Jens,
(you probably noticed now, but the [EMAIL PROTECTED] email is no longer
valid)
I saw that,
Hello, Justin,
This is a 64bit system.
But i cannot understand, what is the curious? :-)
I am not a kernel developer, and not a C programmer, but the long pointers
shows me, the 64 bit.
Or am i on the wrong clue? :-)
Anyway, this issue happens for me about daily, or max 2-3 day often.
But i
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > > +#define seqlock_init(x)\
> > > > + do {\
> > > > + (x)->sequence = 0; \
> > > > +
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 12 Dec 2006 12:49:09 -0500, Dave Jones wrote:
> EFLAGS: 00010246 (2.6.18-1.2849.fc6 #1)
> That was from a 2.6.18.3 kernel iirc.
Here's an idea from Michael Tokarev <[EMAIL PROTECTED]>:
since .version always contains 1 when you build an RPM,
you can
* Francois Romieu <[EMAIL PROTECTED]> wrote:
> > (I'll queue it, if Linus doesn't pick it up; please CC me in the
> > future)
>
> I have lived with the "NAPI ->poll() handler runs in BH irq enabled
> context" rule for years. Is it definitely false/dead ?
>
> If so at least 8139cp needs the
Chuck Ebbert wrote:
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 12 Dec 2006 14:54:30 -0800, Chros Wright wrote:
--- a/arch/i386/kernel/process.cTue Dec 12 13:50:50 2006 -0800
+++ b/arch/i386/kernel/process.cTue Dec 12 13:50:53 2006 -0800
@@ -665,6 +665,37 @@ struct task_struct
On 12/13/06, Alan <[EMAIL PROTECTED]> wrote:
> +static int tc86c001_busproc(ide_drive_t *drive, int state)
> +{
Waste of space having a busproc routine. The maintainer removed all the
usable hotplug support from old IDE so this might as well be dropped.
I took over IDE when hotplug was
On Tue, 12 Dec 2006 11:54:11 -0600
Erik Jacobson <[EMAIL PROTECTED]> wrote:
> Hi Andrew.
>
> There was some discussion on this patch but I believe we've agreed
> on the first version I sent. This was ACKed by Matt Helsley.
>
> Would you consider taking this in to -mm?
>
> I've included my
Mark Fasheh wrote:
On Tue, Dec 12, 2006 at 02:52:26AM +1100, Nick Piggin wrote:
Nick Piggin wrote:
Hmm, doesn't look like we can do this either because at least GFS2
uses BH_New for its own special things.
Also, I don't know if the trick of only walking over BH_New buffers
will work anyway,
On Tuesday December 12, [EMAIL PROTECTED] wrote:
> >
> > So when md writes to write out the superblock, to gets EIO... Odd that
> > you aren't getting errors for normal writes.
> >
> > What devices are the md/raid1 built on?
>
> Sata drives, on sata_uli.
>
> > >
> > > I'll try to reproduce it
On Tue, 12 Dec 2006 07:48:51 +0100 (CET) Ben Castricum wrote:
>
> This bug started to show up after the release of 2.6.19 (iirc plain 2.6.19
> was still working fine).
>
> The full dmesg is at
> http://www.bencastricum.nl/lk/bootmessages-2.6.19-g9202f325.log,
> and the .config
On Tue, 12 Dec 2006 11:23:55 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> This removes some syslog spam as RTC drivers register; debug messages
> shouldn't come out at "info" level.
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Thanks David,
please also cc [EMAIL PROTECTED]
On Tue, 12 Dec 2006 11:49:13 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> Fix a glitch in the procfs dumping of whether the alarm IRQ is enabled:
> use the traditional name (from drivers/char/rtc.c and many other places)
> of "alarm_IRQ", not "alrm_wakeup" (which didn't even match the efirtc
Chuck Ebbert wrote:
> This whole thing needs a proper fix IMO. I posted something a while back
> but Andi didn't like it, I guess.
>
What's a quick summary of the issue again?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Jaswinder Singh wrote:
you only need include/* for this in 2.6
you can't do this at all with 2.4 kernels, it needs the whole lot.
(in both cases the code and headers are needed so that your module can
use the data structures and compile in the kernel code you select to use
from inlines)
>
>
On Tue, Dec 12, 2006 at 04:55:59PM -0600, Linas Vepstas wrote:
> Greg,
>
> Per discussion, a revised patch. Silly me, the value was already
> initialized in drivers/pci/probe.c and I'd been dragging along
> a prehistoric version of the if checks.
>
> --linas
>
> [PATCH 1/2]: define inline for
On Wed, 13 Dec 2006 01:48:34 +0300
Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> Behold! This is the driver for the Toshiba TC86C001 GOKU-S IDE controller,
> completely reworked from the original brain-damaged Toshiba's 2.4 version.
Actually un-nack the PCI quirk. While it is true the native
Roland Dreier <[EMAIL PROTECTED]> writes:
> > So I think we may simplify this but there is pci_mmap_page_range. That
> > already handles this for the architectures that currently support it.
> > So it is probably the case the fbdev should be changed to use that.
>
> Thanks... I was not aware
Jaswinder Singh wrote:
> Hello,
>
> I want to support old 2.4 modules features in 2.6 kernel modules:-
> 1. no kernel source tree is required to build modules.
I don't think that is possible.
There are a few "questions" that are quite fundamental when you want to
build a module that can be
From: Chuck Lever <[EMAIL PROTECTED]>
The rq_daddr field must support larger addresses.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h | 15 +++
From: Chuck Lever <[EMAIL PROTECTED]>
Expand the rq_addr field to allow it to contain larger addresses.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/lockd/host.c|2
This patch is against 2.6.19-rc6-mm2 and should apply to what is in
Linus' and Jeff's git trees currently. This includes a later fix to the
kfree ordering in the nv_remove_one function. Both the original patch
and the later fix are already in the -mm tree.
---
This patch adds the necessary
Seeing this oops on 2.6.19-rc6-mm2 intermittently on bootup. Also, when
this doesn't happen it seems like udev goes crazy adding and removing
/dev/md0 over and over using up a ton of CPU. Is this a known problem?
This also happened with -mm1.
Linux version 2.6.19-rc6-mm2admafix ([EMAIL
Use newly minted routine to access the PCI channel state.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
drivers/net/e1000/e1000_main.c |2 +-
drivers/net/ixgb/ixgb_main.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index:
From: Chuck Lever <[EMAIL PROTECTED]>
There are loads of places where the RPC server assumes that the rq_addr
fields contains an IPv4 address. Top among these are error and debugging
messages that display the server's IP address.
Let's refactor the address printing into a separate function
Following are 14 patches for knfsd that are suitable for inclusion in 2.6.20.
First 13 are from Chuck Lever and make preparations for IPv6 support (I think
we've
get them right this time).
Last is from Peter Staubach and fixes and issue with exclusive create
interacting badly with some ACLs.
Am 11.12.2006 18:07 schrieb Corey Minyard:
> Tilman Schmidt wrote:
>> I was under the impression that line disciplines need a user space
>> process to open the serial device and push them onto it. Is there
>> a way for a driver to attach to a serial port through the line
>> discipline interface
Am 11.12.2006 18:40 schrieb Alan:
> On Mon, 11 Dec 2006 17:58:29 +0100
> Tilman Schmidt <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
>>> This looks wrong. You already have a kernel interface to serial drivers.
>>> It is called a line discipline. We use it for
From: Chuck Lever <[EMAIL PROTECTED]>
Sometimes we need to create an RPC service but not register it with the
local portmapper. NFSv4 delegation callback, for example.
Change the svc_makesock() API to allow optionally creating temporary or
permanent sockets, optionally registering with the
From: Chuck Lever <[EMAIL PROTECTED]>
Add support for IPv6 addresses in the RPC server's UDP receive path.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h |
From: Chuck Lever <[EMAIL PROTECTED]>
Clean-up: msg_name and msg_namelen are not used by sock_recvmsg, so
don't bother to set them in svc_recvfrom.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 23
From: Chuck Lever <[EMAIL PROTECTED]>
Replace existing svc_create_socket() API to allow callers to pass addresses
larger than a sockaddr_in.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
From: Chuck Lever <[EMAIL PROTECTED]>
CMSG_DATA comes in different sizes, depending on address family.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 69
From: Chuck Lever <[EMAIL PROTECTED]>
Modify svc_tcp_accept to support connecting on IPv6 sockets.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 11 +--
From: Chuck Lever <[EMAIL PROTECTED]>
Currently in the RPC server, registering with the local portmapper and
creating "permanent" sockets are tied together. Expand the internal APIs
to allow these two socket characteristics to be separately specified.
This will be externalized in the next
From: Chuck Lever <[EMAIL PROTECTED]>
Sockaddr_storage will allow us to store arbitrary socket addresses in
the svc_deferred_req struct.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
From: Chuck Lever <[EMAIL PROTECTED]>
The remote peer's address won't change after the socket has been
accepted. We don't need to call ->getname on every incoming request.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL
From: Chuck Lever <[EMAIL PROTECTED]>
The only reason svcsock.c looks at a sockaddr's port is to check whether
the remote peer is connecting from a privileged port. Refactor this check
to hide processing that is specific to address format.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc:
From: Peter Staubach <[EMAIL PROTECTED]>
NFS V3 (and V4) support exclusive create by passing a 'cookie' which
can get stored with the file. If the file exists but has exactly the
right cookie stored, then we assume this is a retransmit and the
exclusive create was successful.
The cookie is
> So I think we may simplify this but there is pci_mmap_page_range. That
> already handles this for the architectures that currently support it.
> So it is probably the case the fbdev should be changed to use that.
Thanks... I was not aware of pci_mmap_page_range(), but that doesn't
seem to
> + * We work around this by initiating dummy, zero-length DMA transfer on
> + * a DMA timeout expiration. I found no better way to do this with the
> current
Novel workaround and probably better than resetting the chip as the
winbong does.
> +static int tc86c001_busproc(ide_drive_t *drive, int
On Tue, Dec 12, 2006 at 05:31:14PM -0600, James Bottomley wrote:
> On Tue, 2006-12-12 at 17:22 +0100, Adrian Bunk wrote:
> > The SCSI_SEAGATE driver has:
> > - already been marked as BROKEN in 2.6.0 three years ago and
> > - is still marked as BROKEN.
> >
> > Drivers that had been marked as
Hello.
On Tue, 2006-12-12 at 15:00, Kristen Carlson Accardi wrote:
>
> I did have different dock/undock events a few months ago - but
> after some discussion we scrapped them because Kay wants to avoid driver
> specific events. The "change" event is the only thing that makes sense,
> given the
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 12 Dec 2006 10:39:56 -0500, Dave Jones wrote:
> [gads, an ia64 olpc, what a thought...]
Teacher in front of a classroom full of students, all madly
pedaling away on stationary bicycles: "Okay, class, just another
hour of this and we can use the computers
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 12 Dec 2006 14:54:30 -0800, Chros Wright wrote:
> > --- a/arch/i386/kernel/process.cTue Dec 12 13:50:50 2006 -0800
> > +++ b/arch/i386/kernel/process.cTue Dec 12 13:50:53 2006 -0800
> > @@ -665,6 +665,37 @@ struct task_struct fastcall * __switch_t
Hello,
I am running an experiment with Postgrey to delay (for 300 seconds
minimum) incoming emails. If the clients don't retry after this
delay, then the messages don't usually get in.
The "postgrey" in question is the very same thing that exists for
the Postfix MTA with various automatic
Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial.git
This tree contains the following:
Alistair John Strachan (1):
include/linux/compiler.h: reject gcc 3 < gcc 3.2
Cal Peake (1):
Fix inotify maintainers entry
Dave Jones (2):
Jon needs a
On Tue, 2006-12-12 at 17:22 +0100, Adrian Bunk wrote:
> The SCSI_SEAGATE driver has:
> - already been marked as BROKEN in 2.6.0 three years ago and
> - is still marked as BROKEN.
>
> Drivers that had been marked as BROKEN for such a long time seem to be
> unlikely to be revived in the forseeable
Russell King <[EMAIL PROTECTED]> wrote:
> This seems to be a very silly question (and I'm bound to be utterly
> wrong as proven in my last round) but why are we implementing a new
> set of atomic primitives which effectively do the same thing as our
> existing set?
>
> Why can't we just use
On Tue, Dec 12, 2006 at 03:58:16PM -0700, Eric W. Biederman wrote:
> Andrew de Quincey <[EMAIL PROTECTED]> writes:
>
> > [snip]
> >
> >> correct, will fix that up in the next round
> >>
> >> thanks for the feedback,
> >> Herbert
> >
> > Hi - the conversion looks good to me.. I can't really offer
Sergei Shtylyov wrote:
Hello.
Randy Dunlap wrote:
Behold! This is the driver for the Toshiba TC86C001 GOKU-S IDE
controller,
completely reworked from the original brain-damaged Toshiba's 2.4
version.
This single channel UltraDMA/66 controller is very simple in
programming, yet
Toshiba
On Tue, 12 Dec 2006 14:31:10 -0800
Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Tuesday, December 12, 2006 2:15 pm, Stefan Schmidt wrote:
> > Hello.
> >
> > On Mon, 2006-12-11 at 12:05, Kristen Carlson Accardi wrote:
> > > On Sat, 9 Dec 2006 12:59:58 +0100
> > >
> > > Holger Macht <[EMAIL
Hello.
Randy Dunlap wrote:
Behold! This is the driver for the Toshiba TC86C001 GOKU-S IDE controller,
completely reworked from the original brain-damaged Toshiba's 2.4 version.
This single channel UltraDMA/66 controller is very simple in programming, yet
Toshiba managed to plant many
On Wed, Dec 06, 2006 at 04:52:44PM -0800, David Brownell wrote:
> This reorders the RTC driver menu into separate sections, splitting out
> the SOC, I2C, and SPI support to help make the menu easier to navigate.
> (We got some feedback a while ago that it was "a mess" and hard to make
> sense
On Tue, 12 Dec 2006 13:54:58 -0600
"Mike Miller (OS Dev)" <[EMAIL PROTECTED]> wrote:
> PATCH 2/2
>
> This patch removes calls to pci_disable_device except in fail_all_cmds. The
> pci_disable_device function does something nasty to Smart Array controllers
> that pci_enable_device does not undo.
Hi Linus,
Please pull from 'master' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git
or if master.kernel.org hasn't synced up yet:
master.kernel.org:/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git
This will update the following files:
Russell King writes:
> Why can't we just use atomic_t for this?
On 64-bit platforms, atomic_t tends to be 4 bytes, whereas bitops work
on arrays of unsigned long, i.e. multiples of 8 bytes. We could
use atomic_long_t for this, however.
Paul.
-
To unsubscribe from this list: send the line
On Wed, 13 Dec 2006 01:48:34 +0300 Sergei Shtylyov wrote:
> Behold! This is the driver for the Toshiba TC86C001 GOKU-S IDE controller,
> completely reworked from the original brain-damaged Toshiba's 2.4 version.
>
> This single channel UltraDMA/66 controller is very simple in programming, yet
>
1 - 100 of 669 matches
Mail list logo
