yhlu wrote:
> On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> H. Peter Anvin wrote:
>> Of course, one could argue that since all of those were obsolete by the
>> time Linux was first created, that it probably doesn't matter and that
>> isVGA == 0 pretty much means the more obvious thing.
On Tue, May 08 2007, Rogier Wolff wrote:
>
> Hi,
>
> The nbd client still reliably hangs when I use it.
>
> While looking into this, I found:
>
>
> 446 req->errors = 0;
> 447 spin_unlock_irq(q->queue_lock);
>
> 448
>
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
H. Peter Anvin wrote:
Of course, one could argue that since all of those were obsolete by the
time Linux was first created, that it probably doesn't matter and that
isVGA == 0 pretty much means the more obvious thing.
MDA/HGC stuck around for
On Tue, May 08, 2007 at 04:33:58PM -0700, Andrew Morton wrote:
> On Tue, 8 May 2007 12:33:48 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> >
> > Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
> >
> > ---
> >
> > diff -Nurp 2.6.21-mm1-/kernel/timer.c 2.6.21-mm1/kernel/timer.c
> >
Michael-Luke Jones wrote:
> On 8 May 2007, at 09:48, Alexey Zaytsev wrote:
>
>> I was always curious, why do people want to run ixp4xx in LE mode? What
>> are the benefits that overweight the obvious performance degradation?
>
> Debian.
> http://www.debian.org/ports/arm/
And also out-of-kernel
Hello all,
I believe the x86 setup tree is now finished. I will turn it into a
"clean patchset" later this week, but I wanted to get flamed^W feedback
on it first.
The git tree is at:
http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary
H. Peter Anvin wrote:
> yhlu wrote:
>> On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>> Since the whole point is to detect the case where we don't have
>>> a screen at all it makes sense to check several additional variables
>>> and make certain that they are all 0. Agreed?
>> need one
yhlu wrote:
> On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Since the whole point is to detect the case where we don't have
>> a screen at all it makes sense to check several additional variables
>> and make certain that they are all 0. Agreed?
>
> need one good way to find if there
yhlu <[EMAIL PROTECTED]> writes:
> On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
>> On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
>> This message generally appears if you did not specify --args-linux
>> on kexec command line while loading vmlinux.
>>
> besides elf-x86_64, still need
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
need one good way to find if there is support vga console.
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
besides elf-x86_64, still need --args-linux to pass sth? but how to
let it
Location:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss
Changes since 2.6.16.50:
Adrian Bunk (3):
Use input_get_drvdata() and input_set_drvdata() helpers to do that.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
... Not tested - no hardware ...
drivers/mfd/ucb1x00-ts.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
Index: work/drivers/mfd/ucb1x00-ts.c
Hi Jan,
On Thursday 03 May 2007 17:41, Jan Kratochvil wrote:
> Hi again,
>what do you think about this? (This patch will work only against last
> gamepad rumble support patch)
>
> Thanks for your time
> Jan Kratochvil
>
> BigX button on xbox360 gamepad is surrounded by 4 green leds.
On Thursday 03 May 2007 09:04, Jan Kratochvil wrote:
> Hi Dmitry,
>thanks for feedback. Improved version of this patch follows:
>
> It is enabled only if CONFIG_XPAD_FF is set to y.
>
> Implementation is using force feedback support for memoryless devices.
Applied with couple cosmetic
On Tue, 8 May 2007 17:58:55 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> I'm still cowering in fear of these patches, btw.
>
> Please keep testing and sending them ;)
>
I'll repost "Request-Fot-Test" version "6" against next -mm and
add x86 as my test target at least. (I don't have other
I have a results page here, I will repeat tests with tuning if asked.
http://www.tmr.com/~davidsen/Kernel%20build%20time%20results.html
--
bill davidsen <[EMAIL PROTECTED]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send
On Tuesday 08 May 2007, David Miller wrote:
>From: Gene Heskett <[EMAIL PROTECTED]>
>Date: Tue, 8 May 2007 10:35:03 -0400
>
>> verizon forced me over to a gmail account by refusing this mailing list.
>> Now lkml seems to be refusing posts from my gmail account.
>>
>> Is there a reason?
>
>I just
On Thursday 03 May 2007, Robert P. J. Day wrote:
>
> $ ../dead_config.sh drivers/usb
I'm ignoring the USB serial stuff here.
Most of the "gadget_chips.h" symbols are not dead, they're just
constants reserved for drivers that are currently not in the
kernel.org tree. The role is much the same
Linus Torvalds wrote:
On Tue, 8 May 2007, Jeff Garzik wrote:
I wonder if this fbdev update is what causes my X session to die?
Not that particular patch, but yeah, it could certainly be the fbdev
update.
Can you try bisecting it?
Planning to, but not tonight.
Jeff
-
To
On Wed, 2007-05-09 at 13:28 +1000, David Gibson wrote:
> Some recent changes in get_unmapped_area() have left the 'ret'
> local unused. This patch removes it.
>
> Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Yeah, my fault, though somebody already posted a patch for this
Ben.
-
To
Nick Piggin wrote:
+static void kmem_rcu_free(struct rcu_head *head)
+{
+ struct slob_rcu *slob_rcu = (struct slob_rcu *)head;
+ void *b = (void *)slob_rcu - slob_rcu->c->size;
No, I forgot that c->size includes the size of struct slob_rcu here.
Will send updated patch which is
Chris Wedgwood wrote:
> Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
> ---
> net/sunrpc/sched.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
> index 4a53e94..60df3c1 100644
> --- a/net/sunrpc/sched.c
> +++
In the process of rewriting the x86 setup code, I found a number of
inaccuracies and outdated recommendations in the boot protocol
documentation. Revamp to make it more up to date.
In particular, the common use of the heap actually requires (slightly)
more than 4K of heap plus stack, which is
On Tuesday 08 May 2007 18:06, Peter Samuelson wrote:
>
> Adds the ID to recognise my PS/2 TrackMan Marble.
Applied, thank you.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, 8 May 2007, Jeff Garzik wrote:
>
> I wonder if this fbdev update is what causes my X session to die?
Not that particular patch, but yeah, it could certainly be the fbdev
update.
Can you try bisecting it?
Linus
-
To unsubscribe from this list: send the line
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
> Eric,
>
> i tried to load vmlinux with kexec and got
> Ramdisks not supported with generic elf arguments
>
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
Thanks
Vivek
-
To
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> I expect I can find a few more examples where we specify
>> video_cols and video_lines but we use video_mode == 0.
>>
>> Going farther mode 0x00 is a BIOS 40x25 mode. So the patch below is
>> not always safe even if
On Tue, 2007-05-08 at 18:44 -0700, David Miller wrote:
> I've been noticing this off and on for the past week or so.
>
> The system seems to jam up for several seconds, anything that would
> need to read from disk just sits there during this time. I think it's
> correlated with generating a lot
Some recent changes in get_unmapped_area() have left the 'ret'
local unused. This patch removes it.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/mm/mmap.c
===
--- working-2.6.orig/mm/mmap.c 2007-05-09
On Wed, 9 May 2007, Nick Piggin wrote:
> SLAB_DESTROY_BY_RCU is quite a nice way to mitigate some RCU freeing
> overheads for small objects, so I'd expect it may see wider use in
> future. Maybe all those users would be fine too, but it's a bit nasty
> to have already tricky RCU semantics
On Wed, 09 May 2007 12:12:32 +0900
Yasunori Goto <[EMAIL PROTECTED]> wrote:
> There is a race condition between swap-in and unmap_and_move().
> When swap-in occur, page_mapped might be not set yet.
> So, unmap_and_move() gives up at once, and tries later.
>
>
Note: this will not happen in
On Tue, May 08, 2007 at 07:57:37PM -0700, Christoph Lameter wrote:
> On Wed, 9 May 2007, Nick Piggin wrote:
>
> > > Exactly. That overhead does not exist in SLUB. Thus SLOB is less efficient
> > > than SLUB.
> >
> > What you trade for that is that one page page can only serve one slab.
>
>
On Tue, 8 May 2007, Matt Mackall wrote:
> > Exactly. That overhead does not exist in SLUB. Thus SLOB is less efficient
> > than SLUB.
>
> What size object does kmalloc(80) return? In SLAB, the answer is 128
> bytes with 48 bytes of slack space. In SLOB, the answer is 88 for 8
> bytes of slack
On Thursday 03 May 2007 19:38, Roland Scheidegger wrote:
> From: Roland Scheidegger <[EMAIL PROTECTED]>
>
> The i8042 driver fails detection of the AUX port with some chips,
> because they apparently do not change the I8042_CTR_AUXDIS bit
> immediately. This is known to affect at least HP500 /
Matt Mackall wrote:
On Wed, May 09, 2007 at 12:02:29PM +1000, Nick Piggin wrote:
BTW, we _really_ should be doing RCU properly in slob, because you
technically can't noop RCU on UP (even though the current users may be
safe...).
Thanks. Hugh was pretty convinced it was unneeded:
Jeff Garzik wrote:
> H. Peter Anvin wrote:
>> Checkin 464bdd33e9baad9806c7adbd8dfc37081a55f27e "fbdev: ignore VESA
>> modes if framebuffer is disabled" is just plain wrong on any system
>> which has support for extended text modes in its VESA BIOS.
>>
>> Antonio is incorrectly assuming this
On Tue, May 08, 2007 at 07:24:07PM -0700, Christoph Lameter wrote:
> On Tue, 8 May 2007, Matt Mackall wrote:
>
> > > > Yes. It can in fact put 512 8-byte objects in a 4k page. More
> > >
> > > So can SLUB.
> >
> > Not without at least a bit per-object of overhead. So you can either
> > fit 512
This patch is to isolate source page of migration ASAP in unmap_and_move(),
when memory-hotremove.
In old code, it uses just put_page(),
and we expected that migrated source page is catched in __free_one_page()
as isolated page. But, it is spooled in per_cpu_page and used soon
for next
Delaying freeing anon_vma until migration finishes.
We cannot trust page->mapping (of ANON) when page_mapcount(page) ==0.
page migration puts page_mocount(page) to be 0. So we have to
guarantee anon_vma pointed by page->mapping is valid by some hook.
Usual page migration guarantees this by
If there is small hole at end of a section, there are not initialized pages.
To find it, messy check is necessary at many place of memory remove code.
But, reserved bit by initialization is enough for most case of them.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
mm/page_alloc.c |5
Add MEMORY_HOTREMOVE config and implements basic algorythm.
This config selects ZONE_MOVABLE and PAGE_ISOLATION
how work:
1. register Isololation area of specified section
2. search mem_map and migrate pages.
3. detach isolation and make pages unused.
This works on my easy test, but I think I
Call offline pages from remove_memory().
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
arch/ia64/mm/init.c | 13 -
1 files changed, 12 insertions(+), 1 deletion(-)
Index: current_test/arch/ia64/mm/init.c
On Tue, 8 May 2007 19:38:56 -0700 (PDT) David Rientjes wrote:
> On Tue, 8 May 2007, Randy Dunlap wrote:
>
> > "volatile" used on a gcc asm extension is different, granted.
> > It's not even a C-language "volatile" keyword AFAICT, so it doesn't
> > apply in this context.
> >
>
> Using
There is a race condition between swap-in and unmap_and_move().
When swap-in occur, page_mapped might be not set yet.
So, unmap_and_move() gives up at once, and tries later.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
mm/migrate.c |5 +
1 files changed, 5 insertions(+)
Index:
This patch add function drain_all_pages(void) to drain all
pages on per-cpu-freelist.
Page isolation will catch them in free_one_page.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
include/linux/page_isolation.h |1 +
mm/page_alloc.c
Isolate all freed pages (means in buddy_list) in the range.
See page_buddy() and free_one_page() function if unsure.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
include/linux/page_isolation.h |1
mm/page_alloc.c|
This patch is for supporting making page unused.
Isolate pages by capturing freed pages before inserting free_area[],
buddy allocator.
If you have an idea for avoiding spin_lock(), please advise me.
Isolating pages in free_area[] is implemented in other patch.
Signed-Off-By: KAMEZAWA Hiroyuki
Show #of Movable pages and vmstat.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
arch/ia64/mm/init.c|2 ++
drivers/base/node.c|4
fs/proc/proc_misc.c|4
include/linux/kernel.h |2 ++
On Wed, 9 May 2007, Nick Piggin wrote:
> But that 4MB system might not even have 50 pages that you'd want to
> use for slab.
The problem here is that you trade off more objects (SLUB) against more
flexibility (SLOB). We need some experiments with 4M systems to see how
this works out. It may be
H. Peter Anvin wrote:
Checkin 464bdd33e9baad9806c7adbd8dfc37081a55f27e "fbdev: ignore VESA
modes if framebuffer is disabled" is just plain wrong on any system
which has support for extended text modes in its VESA BIOS.
Antonio is incorrectly assuming this branchout is used only to set VESA
Christoph Lameter wrote:
On Wed, 9 May 2007, Nick Piggin wrote:
For small systems, I would not be surprised if that was less space
efficient, even just looking at kmalloc caches in isolation. Or do you
have numbers to support your conclusion?
No I do not have any number beyond the
On Tue, May 08, 2007 at 09:58:09PM -0300, Kevin Winchester wrote:
>
> Not having any idea what I'm doing, I looked at cryptomgr_probe and
> cryptomgr_notify, and can't seem to see much, except for the following
> odd lines.
>
> From cryptomgr_schedule_probe, which is almost certainly inlined
Hardware: x86-64 dual core, Intel ICH7 platform (see lspci), ATI R580
Software: Fedora Core 6/x86-64, VESA driver, GNOME desktop, with latest
updates
Known good kernel: b9099ff63c75216d6ca10bce5a1abcd9293c27e6
Known bad kernel: 36f021b579d195cdc5fa6f3e2bab198b4bf70643
Symptoms: Machine boots
Hello.
I rebased and debugged Kame-san's memory hot-remove patches.
This work is not finished yet. (Some pages keep un-removable status)
But, I would like to show current progress of it, because it has
been a long time since previous post, and some bugs are fixed.
If you have concern, please
On Wed, 9 May 2007, Nick Piggin wrote:
> > Exactly. That overhead does not exist in SLUB. Thus SLOB is less efficient
> > than SLUB.
>
> What you trade for that is that one page page can only serve one slab.
Right.
> For small systems, I would not be surprised if that was less space
>
On Wed, May 09, 2007 at 12:02:29PM +1000, Nick Piggin wrote:
> BTW, we _really_ should be doing RCU properly in slob, because you
> technically can't noop RCU on UP (even though the current users may be
> safe...).
Thanks. Hugh was pretty convinced it was unneeded:
Checkin 464bdd33e9baad9806c7adbd8dfc37081a55f27e "fbdev: ignore VESA
modes if framebuffer is disabled" is just plain wrong on any system
which has support for extended text modes in its VESA BIOS.
Antonio is incorrectly assuming this branchout is used only to set VESA
graphics modes, but it's to
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
I believe YH is asking how we setup real_mode_data in /sbin/kexec.
pxelinux:
SCREEN_INFO.orig_video_mode = 3
SCREEN_INFO.orig_x = 0
SCREEN_INFO.orig_y = 24
x86_boot_params[] :
: 00 18
Christoph Lameter wrote:
On Tue, 8 May 2007, Matt Mackall wrote:
Yes. It can in fact put 512 8-byte objects in a 4k page. More
So can SLUB.
Not without at least a bit per-object of overhead. So you can either
fit 512 objects in 4160 bytes or 504 objects in 4k.
Slub uses a linked list
On Tue, 8 May 2007, Randy Dunlap wrote:
> "volatile" used on a gcc asm extension is different, granted.
> It's not even a C-language "volatile" keyword AFAICT, so it doesn't
> apply in this context.
>
Using 'volatile' for an asm construct certainly is a keyword; in fact, C99
defines 'volatile'
Howdy (please CC replies directly),
I have a very specific question regarding the behavior of
do_generic_mapping_read().
Here's my 2.6.20 setup: I have a stable block device driver that has
random-access style latencies (around 80 microseconds. zero seek-time).
From userland: I have a simple
Eric W. Biederman wrote:
>
> I expect I can find a few more examples where we specify
> video_cols and video_lines but we use video_mode == 0.
>
> Going farther mode 0x00 is a BIOS 40x25 mode. So the patch below is
> not always safe even if we boot the bzImage. It is just highly
> unlikely
On Tue, 8 May 2007, Matt Mackall wrote:
> > > Yes. It can in fact put 512 8-byte objects in a 4k page. More
> >
> > So can SLUB.
>
> Not without at least a bit per-object of overhead. So you can either
> fit 512 objects in 4160 bytes or 504 objects in 4k.
Slub uses a linked list pointer in the
On Wed, 9 May 2007, Nick Piggin wrote:
> Right. You only need to know blob boundaries for free blobs (so you can
> allocate from or merge to). For allocated blobs, you know the start
> (which is the address of the memory), and the end (which is the start +
> the size contained in kmem_cache
On Tue, May 08, 2007 at 06:32:35PM -0700, Christoph Lameter wrote:
> On Tue, 8 May 2007, Matt Mackall wrote:
>
> > On Tue, May 08, 2007 at 05:51:27PM -0700, Christoph Lameter wrote:
> > > On Tue, 8 May 2007, Matt Mackall wrote:
> > >
> > > > First, SLOB no longer runs on SMP because SLAB grew
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> Here are some 'volatile' comments from Linus, extracted from
> several emails in at least 2 threads.
>
> If this is close to useful, we can add it to Documentation/.
I just took a shot at turning this into something more like a normal
document:
David Miller wrote:
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Tue, 8 May 2007 18:57:04 -0700 (PDT)
On Tue, 8 May 2007, David Miller wrote:
I'm just reading over the code to figure out what to type to you, you
could read the code too it's not very complicated :-)
I have read it
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Tue, 8 May 2007 18:57:04 -0700 (PDT)
> On Tue, 8 May 2007, David Miller wrote:
>
> > I'm just reading over the code to figure out what to type to you, you
> > could read the code too it's not very complicated :-)
>
> I have read it numerous
On Tue, 8 May 2007 17:06:23 -0700 (PDT) David Rientjes wrote:
> On Tue, 8 May 2007, Randy Dunlap wrote:
>
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > Add information on the problems with the C-language "volatile" keyword
> > and why it should not be used (most of the time).
> >
> >
David Miller wrote:
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Tue, 8 May 2007 18:32:35 -0700 (PDT)
That SLUB cannot do. And I do not believe you. SLOB must have some way to
distinguish the objects and their sizes since kfree does not include size
information. You can mix slabs of
On Tue, 8 May 2007, David Miller wrote:
> I'm just reading over the code to figure out what to type to you, you
> could read the code too it's not very complicated :-)
I have read it numerous times and my conclusion is that it uses the
descriptors for that purpose. But Matt claims they are not
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Tue, 8 May 2007 18:53:28 -0700 (PDT)
> On Tue, 8 May 2007, David Miller wrote:
>
> > SLOB seems to look at the descriptor in the previous blob to figure
> > out how big the being-freed blob is. That's actually kind of clever
> > :-)
>
> We were
On Tue, 8 May 2007, David Miller wrote:
> SLOB seems to look at the descriptor in the previous blob to figure
> out how big the being-freed blob is. That's actually kind of clever
> :-)
We were assuming that the objects are actually allocated. How does it
figure out the previous blobs
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Tue, 8 May 2007 18:32:35 -0700 (PDT)
> That SLUB cannot do. And I do not believe you. SLOB must have some way to
> distinguish the objects and their sizes since kfree does not include size
> information. You can mix slabs of different size on
Hi,
Seems I have the same problem. Sometimes whole system is locked,
sometimes keyboard is still active but others dead.
It does not happen till now since I run a silly script on background
to log the kernel messages:
-
#!/bin/sh
while true; do
sleep 3
dmesg >/tmp/dmesg.txt
sync
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> yhlu wrote:
>> On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>>> Jeremy Fitzhardinge wrote:
>>> Specifically boot_params.screen_info isn't being properly set up by the
>>> caller.
>>
>> will setup real_mode_data in kexec path?
>
> -ENOPARSE
I've been noticing this off and on for the past week or so.
The system seems to jam up for several seconds, anything that would
need to read from disk just sits there during this time. I think it's
correlated with generating a lot of dirty write data.
My mouse moves around in X etc. so it
I'm trying to write to disk from a kernel module at high
sustained speeds.
Do I have to somehow query the file-system caches to see how
much memory they are using, or perhaps flush the file after
a certain number of bytes to keep the system from using all
of it's RAM in file-system buffers?
[
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 8 May 2007 22:16:09 +1000
> [NET]: Remove link_watch delay for up even when we're down
>
> Currently all link carrier events are delayed by up to a second
> before they're processed to prevent link storms. This causes
> unnecessary packet loss
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 8 May 2007 22:13:22 +1000
> [NET] link_watch: Move link watch list into net_device
>
> These days the link watch mechanism is an integral part of the
> network subsystem as it manages the carrier status. So it now
> makes sense to allocate some
On Tue, 8 May 2007, Matt Mackall wrote:
> On Tue, May 08, 2007 at 05:51:27PM -0700, Christoph Lameter wrote:
> > On Tue, 8 May 2007, Matt Mackall wrote:
> >
> > > First, SLOB no longer runs on SMP because SLAB grew some RCU-related
> > > hair. So it now effectively has no locks at all!
> >
> >
On Tue, May 08, 2007 at 05:51:27PM -0700, Christoph Lameter wrote:
> On Tue, 8 May 2007, Matt Mackall wrote:
>
> > First, SLOB no longer runs on SMP because SLAB grew some RCU-related
> > hair. So it now effectively has no locks at all!
>
> Well it seems that SLOB was not well maintained. RCU
Hi Tony,
Can you re-generate your patch against the latest tree? Currently, the
last board is 115. So, this one should be 116.
Also, the proper way for discussing about V4L is to use V4L Mailing List
(I'm c/c it).
Cheers,
Mauro.
Em Qua, 2007-05-09 às 05:54 +0800, Tony Wan escreveu:
> Support
On Tue, 2007-05-08 at 20:41 -0300, Marcelo Tosatti wrote:
> On Tue, May 08, 2007 at 06:40:54PM -0400, Jeff Garzik wrote:
> > Dan Williams wrote:
> > >I'll audit the list of ioctls and remove ones that may be objectionable,
> > >and we'll go back through them after 2.6.22 and add back in ones that
On Tue, 8 May 2007 17:58:55 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 9 May 2007 09:29:12 +0900
> KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 08 May 2007 16:37:06 -0400
> > Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> >
> > > > You probably need a
> > > >
On Tue, May 08, 2007 at 05:21:01PM -0700, Minchen Zhao wrote:
> I am running Redhat Linux Enterprise version 4 update 4 on a dual-core
> 4G memory machine.
> There are many references on the web talking about increasing default
> user address space
> to 3.5 G however lacking specific
Am Sonntag, den 29.04.2007, 15:21 +0100 schrieb Alistair John Strachan:
> > i got a problem with the combination of an Asrock AM2NF4G-SATA2
> > mainboard with a Radeon X1900 (chip 1002,724b) graphics
> > card. /i386/pci/mmconfig.c reports a buggy bios (e000 is not
> > E820-reserved). System
This should be the second half of the SCSI tree, mainly assorted driver
updates and fixes. The patch is available from:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
The short changelog is:
Adrian Bunk (1):
qla4xxx: possible cleanups
Amol Lad (1):
megaraid:
> Hi:
> I am running Redhat Linux Enterprise version 4 update 4 on a dual-core
> 4G memory machine. There are many references on the web talking about
> increasing default user address space to 3.5 G however lacking specific
> instructions. My questions:
>
> 1. What is the specific steps to be
On Tue, 8 May 2007, Andrew Morton wrote:
> I'm still cowering in fear of these patches, btw.
>
> Please keep testing and sending them ;)
I hope you finally get a feel for the evil nature of ZONE_DMAxx. I
think our x86_64 platform will have node 0 cordoned off for DMA if any
DMA32 or DMA
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will merge the mlx4 drivers for new Mellanox
On Wed, 9 May 2007 09:29:12 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Tue, 08 May 2007 16:37:06 -0400
> Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > > You probably need a
> > > configuration with a couple of nodes. Maybesomething less symmetric than
> > > Kame? I.e. have 4GB
Christoph Lameter wrote:
On Tue, 8 May 2007, Kevin Winchester wrote:
Here's the dmesg of the slub_debug run, I'll try the patch next:
Ok someone wrote to an object after it was freed. Not slubs problem.
[1.367129] Object 0x810001bdecd0: 80 b7 b1 01 00 81 ff ff 6b 6b
On Tue, 8 May 2007 20:48:59 +0100
Alasdair G Kergon <[EMAIL PROTECTED]> wrote:
> From: Heinz Mauelshagen <[EMAIL PROTECTED]>
>
> New device-mapper target that can delay I/O (for testing).
> Reads can be separated from writes, redirected to different underlying
> devices and delayed by differing
On Tue, 8 May 2007, Matt Mackall wrote:
> First, SLOB no longer runs on SMP because SLAB grew some RCU-related
> hair. So it now effectively has no locks at all!
Well it seems that SLOB was not well maintained. RCU has been around for a
long time and SLOB has not been updated to cope with it.
Satoru Takeuchi wrote:
At Tue, 8 May 2007 22:18:50 +0530,
Srivatsa Vaddagiri wrote:
On Tue, May 08, 2007 at 04:16:06PM +0900, Satoru Takeuchi wrote:
Sometimes I wonder at prio_array. It has 140 entries(from 0 to 139),
and the meaning of each entry is as follows, I think.
On Tue, 8 May 2007, Matt Mackall wrote:
> Further, the received wisdom that fragmentation of SLAB-like systems
> is better is not above doubt. Our own issues with dcache fragmentation
> suggest it's far from perfect.
I guess that you have not seen the slab defrag code for SLUB then.
-
To
On Tue, 8 May 2007 20:48:45 +0100
Alasdair G Kergon <[EMAIL PROTECTED]> wrote:
> +#define BIO_LIST_INIT { .head = NULL, .tail = NULL }
> +
> +#define BIO_LIST(bl) \
> + struct bio_list bl = BIO_LIST_INIT
BIO_LIST is a strange name for something which initialises storage.
> static inline
At Tue, 8 May 2007 22:18:50 +0530,
Srivatsa Vaddagiri wrote:
>
> On Tue, May 08, 2007 at 04:16:06PM +0900, Satoru Takeuchi wrote:
> > Sometimes I wonder at prio_array. It has 140 entries(from 0 to 139),
> > and the meaning of each entry is as follows, I think.
> >
> >
1 - 100 of 1369 matches
Mail list logo
