Nick Piggin a écrit :
Hi Eric,
Thanks for doing this... It's looking good, I just have some minor
comments:
Hi Nick, thanks for reviewing.
Eric Dumazet wrote:
*/
-int get_futex_key(void __user *uaddr, union futex_key *key)
+int get_futex_key(void __user *uaddr, union futex_key *key,
+
Remove an empty and thus unused definition of 'setup_nr_node_ids' (in
case of MAX_NUMNODES < 1) in order to resolve a compiler warning.
Signed-off-by: Patrick Ringl <[EMAIL PROTECTED]>
---
--- linux-2.6.20-o/mm/page_alloc.c 2007-03-22 23:11:25.0 +0100
+++
On 4/5/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Fri, 06 Apr 2007 02:33:03 +1000
Reuben Farrelly <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 3/04/2007 3:47 PM, Andrew Morton wrote:
> >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/
> >
> > - The oops
On Thu, 05 Apr 2007 18:34:48 PDT, [EMAIL PROTECTED] said:
> If they are accurate, THEN they are obviously very relevant.
Erm. No. They're not "obviously" very relevant.
I could hypothetically create a benchmark, that's accurate and repeatable,
that shows that reiser4 is able to wash a herd
Hi Peter,
You say that the results may be accurate, but "Whether or not they're
*relevant* is a totally different ball of wax." and
"Whether or not they're relevant depends on how well they happen to
reflect your particular usage pattern."
Well, surprise, surprise,.. everyone knows that.
Have
[EMAIL PROTECTED] wrote:
Hi Peter,
You say that the results may be accurate, but not relevant.
NO, I said that whether they're accurate is another matter.
If they are accurate, THEN they are obviously very relevant.
Crap-o-la. Whether or not they're relevant depends on how well they
[PATCH] usb gadget rndis:
skb_push function may return a pointer which is not aligned as required
by struct rndis_packet_msg_type. Using attribute trick to fix this bug.
Signed-off-by: Roy Huang <[EMAIL PROTECTED]>
Signed-off-by: Jie Zhang <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL
On Thu, 2007-04-05 at 16:40 -0400, Steven Rostedt wrote:
> Glauber noticed long delays between hitting a key, and seeing data come
> up on the virtual console. Looking into this, I found that the
> wake_parent routine that reads from all devices was actually starving
> out the parent after
On Thu, Apr 05, 2007 at 12:28:03PM -0500, Michael wrote:
>Hi, Dick,
>
>Your steps work beautifully. Thanks.
>
>If you could explain a little about what happens in each step, that
>would be even better.
>
>> # cd /usr/src/linux-2.6.20.3
>> If your current kernel is 2.6.20.3, edit the Makefile to
Ulrich Drepper wrote:
Nick Piggin wrote:
Cool. According to my thinking, madvise(MADV_DONTNEED) even in today's
kernels using down_write(mmap_sem) for MADV_DONTNEED is better than
mmap/mprotect, which have more fundamental locking requirements, more
overhead and no benefits (except debugging,
Nick Piggin wrote:
> Cool. According to my thinking, madvise(MADV_DONTNEED) even in today's
> kernels using down_write(mmap_sem) for MADV_DONTNEED is better than
> mmap/mprotect, which have more fundamental locking requirements, more
> overhead and no benefits (except debugging, I suppose).
It's
Ok,
I don't think there really is anything very interesting here, but we're
hopefully whittling down the list of regressions, and fixing various
random other small issues while at it.
Some smallish MIPS updates, networking (and network driver) fixes, removal
of a long obsolete framebuffer
On Thu, Apr 05, 2007 at 06:00:16PM +0200, Cornelia Huck wrote:
>On Thu, 5 Apr 2007 23:27:32 +0800,
>WANG Cong <[EMAIL PROTECTED]> wrote:
>
>> Thank you very much! I know. So I should replace all kfree with kobject_put,
>> like this one:
>>
>> -sysfs_create_link(>kobj, _subsys.kset.kobj,
On Thu April 5 2007 6:04 pm, Benjamin Herrenschmidt wrote:
> On Thu, 2007-04-05 at 14:55 -0500, Kevin Corry wrote:
> > First, the stock 2.6.20 kernel has a prototype in include/linux/smp.h for
> > a function called smp_call_function_single(). However, this routine is
> > only implemented on i386,
On Thu April 5 2007 3:32 pm, Kevin Corry wrote:
> On Thu April 5 2007 3:08 pm, Arnd Bergmann wrote:
> > On Thursday 05 April 2007, Kevin Corry wrote:
> > > First, the stock 2.6.20 kernel has a prototype in include/linux/smp.h
> > > for a function called smp_call_function_single(). However, this
Ulrich Drepper wrote:
In case somebody wants to play around with Rik patch or another
madvise-based patch, I have x86-64 glibc binaries which can use it:
http://people.redhat.com/drepper/rpms
These are based on the latest Fedora rawhide version. They should work
on older systems, too, but
On Thu, 2007-04-05 at 18:06 -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >
> > No processor.h is such a hodgepodge of unrelated stuff that any
> > splitting up is a good thing.
> >
>
> Fair enough. However, I'd still like to see the X86_CR* constants
> moved, too (and constants added
On Thu, 2007-04-05 at 14:29 -0700, David Brownell wrote:
> On Tuesday 03 April 2007 11:28 pm, Wu, Bryan wrote:
> > USB gadget rndis: skb_push function may return a pointer which is not
> > aligned as required by struct rndis_packet_msg_type.
>
> Can you instead try to update the declaration of
On Thu, 2007-04-05 at 11:43 -0300, Glauber de Oliveira Costa wrote:
> and here's the new patch, merging rusty's suggestions and some more on my own.
>
> May I upload this, or does Rusty (or any other) has some more suggestions?
This looks excellent!
There are a couple of extra spaces floating
On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
> From: Andrew Burgess <[EMAIL PROTECTED]>
> Date: Thu, 5 Apr 2007 15:13:27 -0700
>
> > David, do you see any other problems with scsi_send_eh_cmnd?
> >
> > I've switched back to 2.6.18 which seems to not oops
> > and am happy to try
Can anyone tell me what this means:
Apr 5 22:11:56 vegeta kernel: [ 1265.267700] scsi0: device overrun (status a)
on 0:1:0
Kernel is 2.6.20.
I setup a raid1 between 2 hard disks (on partition #2), as soon as it
started to sync the array, my log was flooded with the above entry.
The scsi
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 5 Apr 2007, Chris Snook wrote:
>
>> Linus Torvalds wrote:
>>
>> > Another thing we could do is to just make sure that kernel threads simply
>> > don't end up as children of init. That whole thing is silly, they're really
>> > not children of
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Do you mean kmap_atomic_pfn?
Yes.
kunmap_atomic can stay lazy (at least for VMI), actually, but it
doesn't help since it happens outside the spin lock.
May as well be consistent. Or do you mean you can't flush outside the
Zachary Amsden wrote:
> Do you mean kmap_atomic_pfn?
Yes.
> kunmap_atomic can stay lazy (at least for VMI), actually, but it
> doesn't help since it happens outside the spin lock.
May as well be consistent. Or do you mean you can't flush outside the
spinlock, even if there's nothing pending?
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Throw it in the queue; I'll slide in after it.
I've pushed it up. I added a few missing cases to the patch
(kmap_atomic_pte, kunmap_atomic).
Do you mean kmap_atomic_pfn? kunmap_atomic can stay lazy (at least for
VMI), actually,
Hi Peter,
You say that the results may be accurate, but not relevant.
.-.
| FILESYSTEM | TIME |DISK |
| TYPE |(secs)|USAGE|
.-.
|REISER4 lzo | 1938 | 278 |
|REISER4 gzip| 2295 | 213 |
|REISER4 | 3462 | 692 |
|EXT2| 4092 | 816 |
Zachary Amsden wrote:
> Throw it in the queue; I'll slide in after it.
I've pushed it up. I added a few missing cases to the patch
(kmap_atomic_pte, kunmap_atomic).
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Thu, 5 Apr 2007, Chris Snook wrote:
> Linus Torvalds wrote:
>
> > Another thing we could do is to just make sure that kernel threads simply
> > don't end up as children of init. That whole thing is silly, they're really
> > not children of the user-space init anyway. Comments?
>
> Does
Rik van Riel wrote:
Nick Piggin wrote:
Oh, also: something like this patch would help out MADV_DONTNEED, as it
means it can run concurrently with page faults. I think the locking will
work (but needs forward porting).
Ironically, your patch decreases throughput on my quad core
test system,
On Thu, 5 Apr 2007 18:12:58 -0700 (PDT)
Davide Libenzi wrote:
> On Thu, 5 Apr 2007, Andrew Morton wrote:
>
> > epoll uses signal stuff and might need signal.h. It implements syscalls
> > and it certainly needs to have those syscall's prototypes in scope. It
> > surely uses stuff from mm.h
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yes, thought about several solutions, and this seems the best. But it
requires a new paravirt-op.
Not with the power of multiplexing. Something like this, perhaps?
Ok, I tried that and I got a nice clean fix. For 2.6.22.
Hi Eric,
Thanks for doing this... It's looking good, I just have some minor
comments:
Eric Dumazet wrote:
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5-mm4/kernel/futex.c
+++ linux-2.6.21-rc5-mm4-ed/kernel/futex.c
@@ -16,6 +16,9 @@
* Copyright (C) 2006 Red Hat,
On Tue, 3 Apr 2007 21:02:03 -0700
"Yinghai Lu" <[EMAIL PROTECTED]> wrote:
> [PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set
> and power management with acpi is not enabled
>
> when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the
> kernel
On Thu, 5 Apr 2007, Andrew Morton wrote:
> epoll uses signal stuff and might need signal.h. It implements syscalls
> and it certainly needs to have those syscall's prototypes in scope. It
> surely uses stuff from mm.h (doesn't everything??)
Ack about signal.h, I forgot about the pwait code :(
Andi Kleen wrote:
No processor.h is such a hodgepodge of unrelated stuff that any
splitting up is a good thing.
Fair enough. However, I'd still like to see the X86_CR* constants
moved, too (and constants added for at least CR0 as well.)
-hpa
-
To unsubscribe from this list: send
Chris Snook wrote:
Linus Torvalds wrote:
On Thu, 5 Apr 2007, Robin Holt wrote:
For testing, Jack Steiner create the following patch. All it does
is moves tasks which are transitioning to the zombie state from where
they are in the children list to the head of the list. In this way,
they
On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
> - fiftyp.c: noticeable, but alot better than previously!
fiftyp.c seems to have been stumbled across by accident as having an effect
when Xenofon was trying to recreate Mike's 50% x 3 test case. I suggest a ten
percent version like the
On Tue, 03 Apr 2007 18:35:06 -0700
Davide Libenzi wrote:
> Remove some unneeded include files from epoll code.
>
Our definitions of "unneeded" might differ.
>
> Signed-off-by: Davide Libenzi
>
>
> - Davide
>
>
>
> Index: linux-2.6.21-rc5.mm4/fs/eventpoll.c
>
Dmitry Torokhov wrote:
>> +static void hid_bus_release(struct device *dev)
>> +{
>> +}
>> +
>> +struct device hid_bus = {
>> +.bus_id = "hidbus0",
>> +.release = hid_bus_release
>> +};
>> +
>> +static void hid_dev_release(struct device *dev)
>> +{
>> +}
>> +
>>
>
> That will for
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yes, thought about several solutions, and this seems the best. But it
requires a new paravirt-op.
Not with the power of multiplexing. Something like this, perhaps?
Throw it in the queue; I'll slide in after it.
Zach
-
To
Linus Torvalds wrote:
On Thu, 5 Apr 2007, Robin Holt wrote:
For testing, Jack Steiner create the following patch. All it does
is moves tasks which are transitioning to the zombie state from where
they are in the children list to the head of the list. In this way,
they will be the first found
On Thu, 2007-04-05 at 17:15 -0700, David Miller wrote:
> This won't work I believe.
>
> There are cases that use smaller sense buffers than the minimum
> specified by the SCSI layer.
>
> One example is that do_sr_ioctl() stuff when the cgc passed
> in has a sense buffer. That will only be as
Zachary Amsden wrote:
> Yes, thought about several solutions, and this seems the best. But it
> requires a new paravirt-op.
Not with the power of multiplexing. Something like this, perhaps?
J
diff -r 5be4a5ff8e6b arch/i386/mm/highmem.c
--- a/arch/i386/mm/highmem.cThu Apr 05 17:04:04
On Thu, Apr 05, 2007 at 05:29:52PM -0700, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> >
> >That patch got dropped, and replaced by one which pulled all the flags
> >definitions out of
> >
>
> Saw that a little too late :)
>
> In general, it would be nice if the various CPU constants
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
So the clean fix for this is still even further out. I don't think I
want to hook kmap/unmap as paravirt-ops.
Yes, it seems like overkill.
How about something like adding PARAVIRT_LAZY_FLUSH as an argument to
set_lazy_mode? It would
[EMAIL PROTECTED] wrote:
Yeap, I guess that will probably work.
And here I was trying to compile old versions of GRUB from namesys.com.
By the way, do you think the benchmarks from:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
Zachary Amsden wrote:
> So the clean fix for this is still even further out. I don't think I
> want to hook kmap/unmap as paravirt-ops.
Yes, it seems like overkill.
How about something like adding PARAVIRT_LAZY_FLUSH as an argument to
set_lazy_mode? It would be valid to use at any time, and it
Yeap, I guess that will probably work.
And here I was trying to compile old versions of GRUB from namesys.com.
By the way, do you think the benchmarks from:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
are accurate?
On Tue, 03 Apr 2007 19:46:04 +0900
Tomoki Sekiyama <[EMAIL PROTECTED]> wrote:
> This patchset is to avoid the problem that write(2) can be blocked for a
> long time if a system has several disks with different speed and is
> under heavy I/O pressure.
>
> -Description of the problem:
> While
Jeremy Fitzhardinge wrote:
That patch got dropped, and replaced by one which pulled all the flags
definitions out of
Saw that a little too late :)
In general, it would be nice if the various CPU constants were all
defined in one place, so I'd rather suggest protecting the appropriate
[EMAIL PROTECTED] wrote:
Anyway, I have patched the 2.6.20 kernel and have a partition formatted
with Reiser4.
However, I am having trouble getting LILO or GRUB working (with
Reiser4).
Could you guys who know all about this, help me, or point me to some
help.
Make your /boot a separate
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
No, they are totally dependent. The reason interrupts are disabled is
to stop kmap_atomic in interrupt handlers. With the kmap_atomic_pte
changes, the whole interrupt disable jibberish goes away.
But kmap_atomic_pte is a special case
H. Peter Anvin wrote:
> Rusty Russell wrote:
>
>> There is now more than one place where we use the fact that bit 9 of
>> eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
>> 512 so it can be used in asm, too.
>>
>
> How about defining all the other EFLAGS in one
Rusty Russell wrote:
There is now more than one place where we use the fact that bit 9 of
eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
512 so it can be used in asm, too.
How about defining all the other EFLAGS in one place?
-hpa
-
To unsubscribe from this
From: James Bottomley <[EMAIL PROTECTED]>
Date: Thu, 05 Apr 2007 19:02:19 -0500
> On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
> > From: Andrew Burgess <[EMAIL PROTECTED]>
> > Date: Thu, 5 Apr 2007 15:13:27 -0700
> >
> > > David, do you see any other problems with scsi_send_eh_cmnd?
>
Zachary Amsden wrote:
> No, they are totally dependent. The reason interrupts are disabled is
> to stop kmap_atomic in interrupt handlers. With the kmap_atomic_pte
> changes, the whole interrupt disable jibberish goes away.
But kmap_atomic_pte is a special case of kmap_atomic for ptes.
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Well at this point, the "proper" fix is dependent on Jeremy's
kmap_atomic_pte changes, which are definitely too late to pull into
2.6.21. Can we just apply this patch please?
Hm, I think they're independent aren't they? Your fix is
Zachary Amsden wrote:
> Well at this point, the "proper" fix is dependent on Jeremy's
> kmap_atomic_pte changes, which are definitely too late to pull into
> 2.6.21. Can we just apply this patch please?
Hm, I think they're independent aren't they? Your fix is about making
lazy_mmu disable
On Thu, 2007-04-05 at 11:44 +0100, Alan Hourihane wrote:
> Attached is a patch against 2.6.21-rc5 which adds the Intel Vermilion
> Range support.
>
> Intel funded Tungsten Graphics to do this work.
>
> If there's any problems or updates needed to be done to get accepted,
> please let me know.
>
On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
> From: Andrew Burgess <[EMAIL PROTECTED]>
> Date: Thu, 5 Apr 2007 15:13:27 -0700
>
> > David, do you see any other problems with scsi_send_eh_cmnd?
> >
> > I've switched back to 2.6.18 which seems to not oops
> > and am happy to try
Hi Ignatich,
After seeing the following benchmarks at
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
The Reiser4 benchmarks are so good, I have decided to try the Reiser4
filesystem.
.-.
|
On Tuesday, 3 April 2007 01:06, Adrian Bunk wrote:
> On Sun, Apr 01, 2007 at 06:48:03PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 1 April 2007 17:21, Tilman Schmidt wrote:
> > > I'm sorry to say this has now happened with kernel 2.6.21-rc5, too.
> > > I started a kernel compilation in the
Andi Kleen wrote:
On Friday 06 April 2007 01:29:56 Zachary Amsden wrote:
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21.
I think it is. That is
I built a version of 2.6.21-rc5-mm4 with an initramfs and it built OK
the first time.
Then I made changes (applied a Reiser4 patch) and rebuilt, and got the
following error:
zephyr linux # make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL
On Thu, 05 Apr 2007 16:34:43 -0700
Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > I noticed this never got applied. There was some feedback which I did
> > not include in this patch because I think it is inappropriate to touch
> > code outside vmi.c at this point for 2.6.21. Please apply; this
On Friday 06 April 2007 01:29:56 Zachary Amsden wrote:
> I noticed this never got applied. There was some feedback which I did
> not include in this patch because I think it is inappropriate to touch
> code outside vmi.c at this point for 2.6.21.
I think it is. That is why i didn't apply it.
On Thu, 5 Apr 2007 15:36:51 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> If we add a new flag so that we can distinguish between the
> first page and the tail pages then we can avoid to use page->private
> in the first page. page->private == page for the first page, so there
> is
Zachary Amsden wrote:
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21. Please apply; this patch
is needed as a bugfix in 2.6.21. An updated version for
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21. Please apply; this patch
is needed as a bugfix in 2.6.21. An updated version for 2.6.22 will
come later
On Thu, 05 Apr 2007 19:42:21 +0200
[EMAIL PROTECTED] wrote:
> Now that we have per BDI dirty throttling is makes sense to also have oer BDI
> congestion feedback; why wait on another device if the current one is not
> congested.
Similar comments apply. congestion_wait() should be called
On Thu, 05 Apr 2007 19:42:20 +0200
[EMAIL PROTECTED] wrote:
> Only do the congestion wait when we actually encountered congestion.
The name congestion_wait() was accurate back in 2002, but it isn't accurate
any more, and you got misled. It does not only wait for a queue to become
uncongested.
From: "Luck, Tony" <[EMAIL PROTECTED]>
Date: Thu, 5 Apr 2007 15:50:02 -0700
> Maybe a granule is not the right unit of allocation ... perhaps 4M
> would work better (4M/56 ~= 75000 pages ~= 1.1G)? But if this is
> too small, then a hard-coded 16M would be better than a granule,
> because 64M is
On Thu, 2007-04-05 at 14:55 -0500, Kevin Corry wrote:
> Hello,
>
> Carl Love and I have been working on getting the latest perfmon2 patches
> (http://perfmon2.sourceforge.net/) working on Cell, and on powerpc in
> general. We've come up with some powerpc-specific questions and we're hoping
>
On Fri, 2007-04-06 at 08:53 +1000, Paul Mackerras wrote:
> Why would the numbers be prone to change, any more than they are
> already?
Because now 8250 ports can actually coexist with Zilog ports. Before my
fix, it was strictly one or the other.
--
dwmw2
-
To unsubscribe from this list: send
On Thu, 05 Apr 2007 19:42:19 +0200
[EMAIL PROTECTED] wrote:
> Introduce a mechanism to wait on free memory.
>
> Currently congestion_wait() is abused to do this.
Such a very small explanation for such a terrifying change.
> ...
>
> --- linux-2.6-mm.orig/mm/vmscan.c 2007-04-05
David Woodhouse writes:
> Of course, the _numbers_ might change -- a given port might no longer be
> ttyS0 but ttyS1. But we're happy to overlook that one even though the
> effect on the user is identical, right?
Why would the numbers be prone to change, any more than they are
already?
-
To
Willy Tarreau wrote:
On Wed, Mar 28, 2007 at 01:02:10PM -0700, David Miller wrote:
Please nobody reply to his posting, I'm shit-canning this thread from
the start as it's nothing but flame fodder.
He forgot the most important thing: there are *many* "benevolent dictators",
all with their own
We carefully set loglevel to 7, and print the sysrq messsage
as to what event we're doing, but we can't actually see
the output as it sets it back before calling the handler,
rather than after.
Move the assignment down one line.
Signed-off-by: Martin J. Bligh <[EMAIL PROTECTED]>
diff -aurpN -X
> This implements granule page sized vmemmap support for IA64.
Christoph,
Your calculations here are all based on a granule size of 16M, but
it is possible to configure 64M granules.
With current sizeof(struct page) == 56, a 16M page will hold enough
page structures for about 4.5G of physical
Hi,
I send this as RFC because I won't manage it to test it
before end of Easter but want to have a consensus about
how the final patch should look like.
Andi,
what do you finally prefer?
(1) Something like the attached patch or
(2) a version which keeps to the MWAIT flag for Fam10 but
On Thu, 05 Apr 2007 18:40:55 EDT, Bill Davidsen said:
> Mockern wrote:
> > Hi,
> >
> > Could you help me please, how can my serial driver to work in half-duplex
> > and full-duplex mode?
> >
> > Thank you
>
> Since you don't seem to have gotten an answer, and while this is
> probably the
My .config is attached.. I cannot reproduce this problem, it only happened
once, but I want to find out how to make sure it does not happen again.
On Thu, 5 Apr 2007, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Justin Piszcz wrote:
On Thu, 05 Apr 2007 19:42:17 +0200
[EMAIL PROTECTED] wrote:
> When the threshol is in the order of the per cpu inaccuracies we can
> deadlock by not receiveing the updated count,
That explanation is a bit, umm, terse.
> introduce a more expensive
> but more accurate stat read function to use on
On Thu, 05 Apr 2007 19:42:18 +0200
[EMAIL PROTECTED] wrote:
> rely on accurate dirty page accounting to provide enough push back
I think we'd like to see a bit more justification than that, please.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Mockern wrote:
Hi,
Could you help me please, how can my serial driver to work in half-duplex and
full-duplex mode?
Thank you
Since you don't seem to have gotten an answer, and while this is
probably the wrong list for your question, I can give you a pointer
which may help.
The
While trying to find the cause of problems with reiser4 in recent
kernels I came across this.
Incomplete write handling seem to be missing from reiser4_write_extent()
thanks to reiser4-temp-fix.patch. Strangely, there is a patch by Edward
Shishkin that should address that issue, but it is
Hi,
How can I control the size of the block requests the sendfile() syscall
performs
against the disk?
I'm using sendfile (on a 2.6.18 kernel) to copy 1M file chunks into a
socket. The
socket send buffer size is 2MB, and I verify that its empty before
making the call.
Indeed, 1M chunk is
On Thu, 05 Apr 2007 19:42:11 +0200
[EMAIL PROTECTED] wrote:
> Provide scalable per backing_dev_info statistics counters modeled on the ZVC
> code.
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
> block/ll_rw_blk.c |1
> drivers/block/rd.c |2
>
Unalias PG_tail for performance reasons
If PG_tail is an alias then we need to check PageCompound before PageTail.
This is particularly bad because the slab and others have to use these tests
in performance critical paths.
This patch uses one of the freed up software suspend flags that is
From: Andrew Burgess <[EMAIL PROTECTED]>
Date: Thu, 5 Apr 2007 15:13:27 -0700
> David, do you see any other problems with scsi_send_eh_cmnd?
>
> I've switched back to 2.6.18 which seems to not oops
> and am happy to try patches.
Does 2.6.20 with my patch OOPS too? Does reverting my patch
make
[PATCH] Free up page->private for compound pages
If we add a new flag so that we can distinguish between the
first page and the tail pages then we can avoid to use page->private
in the first page. page->private == page for the first page, so there
is no real information in there.
Freeing up
On Thu, 5 Apr 2007, Justin Piszcz wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.html
Here is the badblocks output:
p34:~# /usr/bin/time badblocks -b 512 -s -v -w /dev/sdl
Checking for bad blocks in read-write mode
From block 0 to 293046768
Testing with pattern 0xaa:
On Thu, 5 Apr 2007, David Miller wrote:
> Hey Christoph, here is sparc64 support for this stuff.
Great!
> After implementing this and seeing more and more how it works, I
> really like it :-)
>
> Thanks a lot for doing this work Christoph!
Thanks for the appreciation. CCing Andy Whitcroft who
On Thu, 5 Apr 2007, Justin Piszcz wrote:
On Thu, 5 Apr 2007, Justin Piszcz wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.html
I have similar issues as this poster-- I was wondering (if anyone) had an
idea to the root cause of this issue; is it a problem with the
Chuck Ebbert wrote:
>Andrew Burgess wrote:
>
>> Apr 5 03:45:16 cichlid kernel: 3w-: scsi2: Command failed: status =
>> 0xc7, flags = 0x7f, unit #4.
>> Apr 5 03:45:20 cichlid kernel: 3w-: scsi2: Command failed: status =
>> 0xc7, flags = 0x80, unit #4.
>> Apr 5 03:47:20 cichlid kernel:
On Thu, 5 Apr 2007, Justin Piszcz wrote:
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.html
I have similar issues as this poster-- I was wondering (if anyone) had an
idea to the root cause of this issue; is it a problem with the chipset, the
BIOS revision?
Mobo: Intel
http://www.ussg.iu.edu/hypermail/linux/kernel/0701.3/0315.html
I have similar issues as this poster-- I was wondering (if anyone) had an
idea to the root cause of this issue; is it a problem with the chipset,
the BIOS revision?
Mobo: Intel DG965WHMKR
BIOS: 1666
Is it only Intel Chipsets
On Thu, 2007-04-05 at 22:42 +0100, Alan Hourihane wrote:
> On Thu, 2007-04-05 at 21:38 +0200, Arnd Bergmann wrote:
> > On Thursday 05 April 2007, Alan Hourihane wrote:
> > > @@ -0,0 +1,405 @@
> > > +/*
> > > + * Copyright (c) Intel Corp. 2007.
> > > + * All Rights Reserved.
> > > + *
> >
> >
On Thursday 05 April 2007, Alan Hourihane wrote:
> As for the above, I've noticed that drivers/video/epson1355fb.c also has
> this wording and is under the GPL.
Yes, many files have it, but that doesn't make it right ;-)
Arnd <><
-
To unsubscribe from this list: send the line
On Tuesday 03 April 2007 11:28 pm, Wu, Bryan wrote:
> USB gadget rndis: skb_push function may return a pointer which is not
> aligned as required by struct rndis_packet_msg_type.
Can you instead try to update the declaration of that struct
so that it's "__attribute__((packed))"? That's less
1 - 100 of 813 matches
Mail list logo
