This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer are allocated so that
they don't get allocated above 4GB and break legacy mode (which is
On Tue, 20 Nov 2007 16:51:21 -0600
"Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> Quoting Chris Friedhoff ([EMAIL PROTECTED]):
> > On Tue, 20 Nov 2007 08:51:06 -0600
> > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> >
> > > Quoting Chris Friedhoff ([EMAIL PROTECTED]):
> > > > On Mon, 19 Nov
* Trond Myklebust ([EMAIL PROTECTED]) wrote:
>
> On Tue, 2007-11-20 at 16:50 -0500, Mathieu Desnoyers wrote:
> > Then my original point is valid : put_no_resched() will cause unwanted
> > scheduler latencies. It's designed only to be used from within the
> > scheduler code itself. The correct
Roland McGrath <[EMAIL PROTECTED]> writes:
>> can you see any danger to providing a /proc/self_task/ link? (or can you
>> think of a better name/API/approach)
>
> That is a poor name to choose given /proc/self/task exists as something
> else (just try writing a sentence comparing them and then
Ingo Molnar wrote:
i took that "Nope" as referring to my impression - but you in fact meant
that i am not wrong? :-) So nothing to see here. single-bzImage initrd
was and is possible, so we could in fact move chunks of system-related
userland (such as irqbalanced) into the kernel proper?
> I've had other freezes before but this was the first time I was able
> to see what was actually going on.
> IRQ 21 appears to be shared between sata_nv and ethernet.
>
> Does this mean my hardware/BIOS is broken somehow?
Not neccessarily. It could a bug in one of the drivers using IRQ 21
Ulrich Drepper <[EMAIL PROTECTED]> writes:
> Roland McGrath wrote:
>> Oh, it seems it has indeed been that way for a very long time, so I was
>> mistaken. It still seems a little odd to me. Ulrich can say definitively
>> whether the kind of concern I mentioned really matters one way or the
On Wednesday, 21 of November 2007, Roland McGrath wrote:
> > can you see any danger to providing a /proc/self_task/ link? (or can you
> > think of a better name/API/approach)
>
> That is a poor name to choose given /proc/self/task exists as something
> else (just try writing a sentence comparing
The MPOL_BIND policy creates a zonelist that is used for allocations belonging
to that thread that can use the policy_zone. As the per-node zonelist is
already being filtered based on a zone id, this patch adds a version of
__alloc_pages() that takes a nodemask for further filtering. This
Currently a node has two sets of zonelists, one for each zone type in the
system and a second set for GFP_THISNODE allocations. Based on the zones
allowed by a gfp mask, one of these zonelists is selected. All of these
zonelists consume memory and occupy cache lines.
This patch replaces the
Filtering zonelists requires very frequent use of zone_idx(). This is costly
as it involves a lookup of another structure and a substraction operation. As
the zone_idx is often required, it should be quickly accessible. The node
idx could also be stored here if it was found that accessing
This patch introduces a node_zonelist() helper function. It is used to lookup
the appropriate zonelist given a node and a GFP mask. The patch on its own is
a cleanup but it helps clarify parts of the one-zonelist-per-node patchset. If
necessary, it can be merged with the next patch in this set
On NUMA, zone_statistics() is used to record events like numa hit, miss
and foreign. It assumes that the first zone in a zonelist is the preferred
zone. When multiple zonelists are replaced by one that is filtered, this
is no longer the case.
This patch records what the preferred zone is rather
This release brings the number of zonelists to two instead of one. Getting
all the corner cases right for __GFP_THISNODE and one zonelist was turning
into a complicated mess. Not only was it affecting too many paths but it
reached the point where it should be reviewed as a standalone change.
Much
The allocator deals with zonelists which indicate the order in which zones
should be targeted for an allocation. Similarly, direct reclaim of pages
iterates over an array of zones. For consistency, this patch converts direct
reclaim to use a zonelist. No functionality is changed by this patch.
This release brings the number of zonelists to two instead of one. Getting
all the corner cases right for __GFP_THISNODE and one zonelist was turning
into a complicated mess. Not only was it affecting too many paths but it
reached the point where it should be reviewed as a standalone change.
Much
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>>
> Nope. It runs inside an initramfs, of course; that initramfs is linked
> into the kernel binary.
would be nice to have a single-image variant for all of this.
> > @@ -104,7 +103,7 @@ ENTRY(ia32_sysenter_target)
> > pushfq
> > CFI_ADJUST_CFA_OFFSET 8
> > /*CFI_REL_OFFSET rflags,0*/
> > - movl$VSYSCALL32_SYSEXIT, %r10d
> > + movl8*3-THREAD_SIZE+threadinfo_sysenter_return(%rsp), %r10d
>
> 8*3-THREAD_SIZE is not very intuitive. Can
For 64-bit, the hack consists of a switch that chooses whether to use a
fixed address or a generically-assigned one, that's all there is to it.
So it costs about nothing.
Even for 32-bit, CONFIG_COMPAT_VDSO for a while now is doing nothing but
changing the default of the sysctl variable. There
On Tuesday, 20 of November 2007, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't
> > > changed the non-functioning of 2.6.24-rc3
> > >
> > > s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Nope. It runs inside an initramfs, of course; that initramfs is
linked into the kernel binary.
would be nice to have a single-image variant for all of this. having
the separate initrd was always trouble - and it's pointless as
On Tue, 20 Nov 2007 23:58:38 +0100
Helge Deller <[EMAIL PROTECTED]> wrote:
> David Schwartz wrote:
> > Any UUID generator that can produce duplicate UUIDs with probability
> > significantly less than purely random UUIDs is so badly broken that it
> > should not ever be used. Anyone who finds such
> I think you should drop CONFIG_COMPAT_VDSO support for 32-bit VDSO on
> 64-bit kernel. This was only to hack around a broken version of glibc
> that shipped with SUSE PRO 9.0,
I would be severly opposed to that. You cannot break compatibility to a large
chunk of userland. You would also
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > The 32-bit vDSO mapping now behaves the same on x86_64 as on native
> > 32-bit. The abi.syscall32 sysctl on x86_64 now takes the same values
> > that vm.vdso_enabled takes on the 32-bit kernel. That is, 1 means a
> > randomized vDSO location, 2
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
> This makes x86_64's ia32 emulation support share the sources used in the
> 32-bit kernel for the 32-bit vDSO and much of its setup code.
>
> The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
> The abi.syscall32
On Tue, 20 Nov 2007, Christoph Lameter wrote:
> 32bit sign extension for what? Absolute data references? The addressing
> that I have seen was IP relative. Thus I thought that the kernel could be
> moved lower.
Argh. This is all depending on a special gcc option to compile the
kernel and that
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>>> Nope. It runs inside an initramfs, of course; that initramfs is
>>> linked into the kernel binary.
>>
>> would be nice to have a single-image variant for all of this. having
>> the separate initrd was always trouble - and it's pointless as well.
Is there any other information that I can provide which might help in
resolving this bug?
On 11/18/07, Raymano Garibaldi <[EMAIL PROTECTED]> wrote:
> The last time I tried this and it worked was 2.6.21. Below is a
> portion of the kernel log file where I had a USB storage device
> attached to the
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
> This changes the 64-bit kernel's support for the 32-bit sysenter
> instruction to use stored fields rather than constants for the
> user-mode return address, as the 32-bit kernel does. This adds a
> sysenter_return field to struct
>There is.. it's called "root privileges".
yes, true.
but - regardless of being a windows app or not - what if you want to take a
look on your system as a whole, especially when using some tool which
graphically shows how and where your diskspace is being used? if i let this
run from ordinary
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Why not just pin down the current ABI that there's 6 syscall
parameters _and not more_?
Because we have already violated it. There are system calls that need
more than 6 arguments: we need *a* convention. Worse, we're not
Joe Perches <[EMAIL PROTECTED]> writes:
> --- a/drivers/net/wan/wanxl.c
> +++ b/drivers/net/wan/wanxl.c
> @@ -743,7 +743,7 @@ static int __devinit wanxl_pci_init_one(struct pci_dev
> *pdev,
> }while (time_after(timeout, jiffies));
>
> if (!stat) {
> -
On Tue, Nov 20, 2007 at 03:15:38PM -0800, David Miller wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2007 22:49:27 +0100
>
> >
> > * Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Nov 20, 2007 at 09:39:19PM +0100, Ingo Molnar wrote:
> > > >
> > > > * Greg KH <[EMAIL
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Ingo Molnar wrote:
* Mark Lord <[EMAIL PROTECTED]> wrote:
Perhaps, but this also violates the principle that the kernel should just
*work* with sensible defaults. I don't use an initrd, or an initramfs,
and have no intention
On Tue, 20 Nov 2007, Roland McGrath wrote:
> > git format-patch -p
> >
> > does the trick at least here :)
>
> Ok, I can use that in future. I hope it still means that in the eventual
> merged state, GIT will be aware of all the renames.
git does not store the "renamed/copied" info at all.
> can you see any danger to providing a /proc/self_task/ link? (or can you
> think of a better name/API/approach)
That is a poor name to choose given /proc/self/task exists as something
else (just try writing a sentence comparing them and then read it aloud).
Probably /proc/self/task/self is
On Wed, Nov 21, 2007 at 12:06:57AM +0100, [EMAIL PROTECTED] wrote:
> - be root
That's your first mistake.
> - cat /dev/watchdog or dd if=/dev/watchdog of=/dev/zero bs=1 count=1 or .
> - wait one minute
>
> *reboot*!
And that's the defined behavior of /dev/watchdog, yes. Many
On Wed, Nov 07, 2007 at 04:32:00PM +, Phillip Lougher wrote:
> maximilian attems wrote:
> > On Mon, Nov 05, 2007 at 11:13:14AM +, Phillip Lougher wrote:
> >
> >> The next stage after this release is to fix the one remaining blocking
> >> issue
> >> (filesystem endianness), and then
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> * Mark Lord <[EMAIL PROTECTED]> wrote:
>>
>>> Perhaps, but this also violates the principle that the kernel should just
>>> *work* with sensible defaults. I don't use an initrd, or an initramfs,
>>> and have no intention of
Jochen Friedrich wrote:
PORTA and PORTB have odr registers, as well. However, the PORTB odr
register is only 16bit.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
Acked-by: Scott Wood <[EMAIL PROTECTED]>
BTW, you may want to send the patches to linuxppc-dev rather than
* Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> > Oh, it seems it has indeed been that way for a very long time, so I
> > was mistaken. It still seems a little odd to me. Ulrich can say
> > definitively whether the kind of concern I mentioned really matters
> > one way or the other for glibc.
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> On 11/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > i guess it was a v2.6.24 change, hence a regression that needs to be
> > fixed?
>
> It seems to be
>
> http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
>
On Tuesday, 20 of November 2007, Mark M. Hoffman wrote:
> Hi all:
>
> * Alan Stern <[EMAIL PROTECTED]> [2007-11-19 15:27:14 -0500]:
> > On Mon, 19 Nov 2007, Rudolf Marek wrote:
> >
> > > Hello all,
> > > >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> > > >>>
On Tuesday, 20 of November 2007, Alan Stern wrote:
> On Tue, 20 Nov 2007, Huang, Ying wrote:
>
> > - What is the difference between PMSG_SUSPEND and PMSG_FREEZE?
>
> SUSPEND means that the system is about to go into a low-power state, so
> the driver should take the appropriate action to reduce
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> Why not just pin down the current ABI that there's 6 syscall
>> parameters _and not more_?
>
> Because we have already violated it. There are system calls that need
> more than 6 arguments: we need *a* convention. Worse, we're not
> actually
On Tuesday, 20 of November 2007, Huang, Ying wrote:
> On Tue, 2007-11-20 at 03:24 +0100, Rafael J. Wysocki wrote:
> > On Tuesday, 20 of November 2007, Huang, Ying wrote:
> > > On Mon, 2007-11-19 at 19:22 +0100, Rafael J. Wysocki wrote:
> > > > > +#ifdef CONFIG_KEXEC
> > > > > +static void
On Tue, Nov 20, 2007 at 03:40:30PM +0100, Milan Broz wrote:
> (Note comment in code "It is permissible to free the struct
> work_struct from inside the function that is called from it".)
I don't understand yet how lockdep behaves if the work struct gets
reused and the reused one finishes first.
Ingo Molnar wrote:
* Mark Lord <[EMAIL PROTECTED]> wrote:
Perhaps, but this also violates the principle that the kernel should
just *work* with sensible defaults. I don't use an initrd, or an
initramfs, and have no intention of ever doing so.
nor do i - i was under the impression that
On Tue, Nov 20, 2007 at 03:49:43AM -0700, Jan Beulich wrote:
> This patch (in its incarnation in our SLE10SP2 tree) is causing resource
> allocation failures on one of my machines.
Does the latest 2.6.23 kernel also cause these same problems?
> The condition for this is that besides ROMs behind
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland McGrath wrote:
> Oh, it seems it has indeed been that way for a very long time, so I was
> mistaken. It still seems a little odd to me. Ulrich can say definitively
> whether the kind of concern I mentioned really matters one way or the other
On Wed, Nov 21, 2007 at 12:11:57AM +0100, Helge Deller wrote:
> On Tuesday 20 November 2007, Matt Mackall wrote:
> > On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
> > > > > Current implemenations use userspace-libraries. In userspace you e.g.
> > > > > can't
> > > > > easily
[EMAIL PROTECTED] wrote:
good evening,
i stumbled over some funny issue when trying windirstat (like KDirStat) with
wine.
after running that tool for a while my system rebooted. i could reproduce this
with every run.
after some deep investigation (i thought i had stability issues with my
On Wednesday 21 November 2007, Theodore Tso wrote:
> On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
> > > Even with a futex? Or userspace atomics?
> >
> > Yes, you'll need a futex or similiar.
> >
> > The problem is then more, where will you put that futex to be able
> > to
Mark Lord wrote:
Perhaps, but this also violates the principle that the kernel
should just *work* with sensible defaults. I don't use an initrd,
or an initramfs, and have no intention of ever doing so.
I *like* having a single boot image with no unneeded/unwanted complexity.
It's only
> git format-patch -p
>
> does the trick at least here :)
Ok, I can use that in future. I hope it still means that in the eventual
merged state, GIT will be aware of all the renames.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
* Mark Lord <[EMAIL PROTECTED]> wrote:
> Perhaps, but this also violates the principle that the kernel should
> just *work* with sensible defaults. I don't use an initrd, or an
> initramfs, and have no intention of ever doing so.
nor do i - i was under the impression that klibc was able to
Petr Baudis wrote, On 11/20/2007 10:59 PM:
> Hi,
>
> On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:
>> I see gitweb is much more usable (faster) than a few months ago, but
>> there is one thing a bit problematic: in the history of patches I'm
>> very often interested in which
* David Miller <[EMAIL PROTECTED]> wrote:
> > so just to reiterate, to make sure we have the same plans: lets
> > leave v2.6.22 and earlier kernels alone - and lets strive for the
> > latest patches and code for v2.6.23 (and v2.6.24, evidently).
>
> I've validated that those patches make
Ingo Molnar wrote:
do you suggest that extending the system call calling convention to
include an arbitrary number of parameters will solve all these API needs
we have at the moment?
if yes, then a one-shot syslet/async call would in essence be:
syslet_arg1 ... N, syscall_arg 1 ... M
Oh, it seems it has indeed been that way for a very long time, so I was
mistaken. It still seems a little odd to me. Ulrich can say definitively
whether the kind of concern I mentioned really matters one way or the other
for glibc.
Thanks,
Roland
-
To unsubscribe from this list: send the line
Ingo Molnar wrote:
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
kernel or kernel source? If there was a good place in the kernel
source I'd not be against moving irqbalance there. [...]
would this be a good case study to use klibc and start up irqbalanced
automatically? I'd love it if we
>> On Fri, 02 Nov 2007 12:10:00 -0500 Jordan Russell <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> With 2.6.23.1 (stock and Fedora), roughly 50% of the time my system
>> hangs indefinitely during the kernel boot process. The hangs occur in
>> places where normally a brief delay is seen, such as when
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 22:49:27 +0100
>
> * Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Nov 20, 2007 at 09:39:19PM +0100, Ingo Molnar wrote:
> > >
> > > * Greg KH <[EMAIL PROTECTED]> wrote:
> > >
> > > > > but we only have cpu_clock() from v2.6.23
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 15:02:43 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
..
Well, for my dualCore notebook, dualCore MythTV box, and QuadCore
desktop, the behaviour of the existing, working, 32-bit kernel
IRQBALANCE code outperforms the userspace utility.
Mostly, I
On Tuesday 20 November 2007, Matt Mackall wrote:
> On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
> > > > Current implemenations use userspace-libraries. In userspace you e.g.
> > > > can't
> > > > easily protect the uniquness of a UUID against other running
> > > > _processes_.
On Wed, 2007-11-21 at 09:39 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2007-11-20 at 15:10 -0600, James Bottomley wrote:
> > We're talking about trying to fix this for 2.4; which is already at
> > -rc3 ... Is an entire arch change for dma alignment really a merge
> > candidate at this stage?
On Tue, 20 Nov 2007, Roland McGrath wrote:
> > > rename arch/x86/{kernel/vsyscall-int80_32.S => vdso/vdso32/int80.S} (97%)
> > > rename arch/x86/{kernel/vsyscall-note_32.S => vdso/vdso32/note.S} (95%)
> > > rename arch/x86/{kernel/vsyscall-sigreturn_32.S =>
> > > vdso/vdso32/sigreturn.S}
On 11/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i guess it was a v2.6.24 change, hence a regression that needs to be
> fixed?
It seems to be
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
So, linux 2.6.0-test6
--
Guillaume
-
To unsubscribe from this
good evening,
i stumbled over some funny issue when trying windirstat (like KDirStat) with
wine.
after running that tool for a while my system rebooted. i could reproduce this
with every run.
after some deep investigation (i thought i had stability issues with my system
and spent more than
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> We may be stuck with the current broken behavior for backwards
> compatibility reasons but lets try fixing our ancient bug for the
> 2.6.25 time frame and see if anyone screams.
to make sure i got you right - do you agree that this is a
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> When did /proc/self get changed to follow tgid instead of pid? glibc
> uses /proc/self to refer to various things that are usually shared
> anyway (fd, maps, cwd, exe), but I think the expectation has always
> been that this refers to the same
On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
> > Even with a futex? Or userspace atomics?
>
> Yes, you'll need a futex or similiar.
>
> The problem is then more, where will you put that futex to be able
> to protect against other processes ?
>
> Best solution is probably shared
* Matthew <[EMAIL PROTECTED]> wrote:
> > are you sure? The last -ck patch i can find is for .22:
>
> > http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/
>
> > or have they been forward ported? (if yes, do you have an URL for that)
>
> > (my guess is you used the 2.6.23.1
Hello Eric,
This fills a need I had to get the current TID in a Java program,
so I'm very interested in this change. OTOH, how will someone
not reading LKML discover that the current TID is now in
/proc/self and that it was not always the case?
I would put my 2 cents in /proc/self/task/self,
David Schwartz wrote:
> Any UUID generator that can produce duplicate UUIDs with probability
> significantly less than purely random UUIDs is so badly broken that it
> should not ever be used. Anyone who finds such a UUID generator should
> immediately either fix it or throw it on the junk heap.
On Tue, Nov 20, 2007 at 10:59:58PM +0100, Helge Deller wrote:
> > > Current implemenations use userspace-libraries. In userspace you e.g.
> > > can't
> > > easily protect the uniquness of a UUID against other running _processes_.
> > > If you try do, you'll need to do locking e.g. with shared
When did /proc/self get changed to follow tgid instead of pid? glibc uses
/proc/self to refer to various things that are usually shared anyway (fd,
maps, cwd, exe), but I think the expectation has always been that this
refers to the same calling thread, not the group leader. e.g., if one
thread
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>> On Fri, 2 Nov 2007, Dave Hansen wrote:
>> >
>> > There are certainly more of these, but here is one In the futex
>> > userspace address, we install the current pid's vnr into a userspace
>> > address.
>>
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 20 Nov 2007, Ingo Molnar wrote:
> >
> > * Pavel Machek <[EMAIL PROTECTED]> wrote:
> >
> > > > and send us the output? (Enabling CONFIG_TIMER_STATS,
> > > > CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS would maximize the amount
> > > > of
Quoting Chris Friedhoff ([EMAIL PROTECTED]):
> On Tue, 20 Nov 2007 08:51:06 -0600
> "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
>
> > Quoting Chris Friedhoff ([EMAIL PROTECTED]):
> > > On Mon, 19 Nov 2007 17:16:44 -0600
> > > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Quoting
> are you sure? The last -ck patch i can find is for .22:
> http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/
> or have they been forward ported? (if yes, do you have an URL for that)
> (my guess is you used the 2.6.23.1 scheduler (CFS), so the improvement
> you felt on the laptop
On Tue, 20 Nov 2007, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > and send us the output? (Enabling CONFIG_TIMER_STATS,
> > > CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS would maximize the amount
> > > of information.)
> >
> > This was w/o hpet=disable . Do you want
> > Management stuff always seems to be tied to a single card. It's one of
> > the things that puts me off hardware RAID.
>
> There are 113 cards this driver works for in concert. Maybe my tail
> feathers are showing ;->
You might want to mention the card firmware in question run on 3 or 4
On Tue, 2007-11-20 at 16:50 -0500, Mathieu Desnoyers wrote:
> Then my original point is valid : put_no_resched() will cause unwanted
> scheduler latencies. It's designed only to be used from within the
> scheduler code itself. The correct approach would be a standard
> put_cpu().
>
> Or am I
Long ago when the CLONE_THREAD support first went it someone
thought it would be wise to point /proc/self at /proc/
instead of /proc/.
Given that /proc/ can return information about a very different
task (if enough things have been unshared) then our current process
/proc/ seems blatantly wrong.
* Davide Libenzi <[EMAIL PROTECTED]> wrote:
> > whether that interpreted syslet language survives is still an open
> > question - it was extremely ugly when i wrote the first version of
> > it and it only got uglier since then :-)
>
> Aha! You admitted it finally :)
damn :-)
but if the only
Is there a reason why I would not want to run a production system with
CONFIG_PROFILING enabled?
I am wondering if there are any reasons associated with performance,
stability or security that I should worry about when CONFIG_PROFILING is
enabled.
Thanks,
Cam
-
To unsubscribe from this
On Tuesday 20 November 2007, Andrew Morton wrote:
> On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <[EMAIL PROTECTED]> wrote:
>
> > Andrew,
> >
> > could you please consider adding this patch to your 2.6.25 patch series?
>
> please cc netdev on networking-related things
Ok.
> > This is the
On Tue, 2007-11-20 at 15:10 -0600, James Bottomley wrote:
> We're talking about trying to fix this for 2.4; which is already at
> -rc3 ... Is an entire arch change for dma alignment really a merge
> candidate at this stage?
Well, as I said before... it's a matter of what seems to be the less
these are all questions for Ulrich and Roland - Cc:-ed them.
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> >> > lr-x-- 1 root root 64 Nov 20 18:03 3 -> /proc/net
> >> > ...
> >>
> >> Yes
From: Zach Brown <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 13:55:56 -0800
> Not to belabor this point, but it was:
>
> http://lkml.org/lkml/2007/11/20/53
>
> $ grep -l INDIRECT_PARAM .git/patches/master/*
> .git/patches/master/indirect-v4-4.patch
> .git/patches/master/indirect-v4-5.patch
>
On Tue, 20 Nov 2007, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> > It seems that you're doing the same thing in both cases, except you're
> > now extending it to include other random functionality, which means
> > other things than syslets are suddenly affected.
> >
>
On Tue, 20 Nov 2007 08:51:06 -0600
"Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> Quoting Chris Friedhoff ([EMAIL PROTECTED]):
> > On Mon, 19 Nov 2007 17:16:44 -0600
> > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> >
> > > Quoting Chris Friedhoff ([EMAIL PROTECTED]):
> > > > Hello Serge,
> > >
Hi,
On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:
> I see gitweb is much more usable (faster) than a few months ago, but
> there is one thing a bit problematic: in the history of patches I'm
> very often interested in which kernel version of Linus' tree the patch
> appeared
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Tue, 20 Nov 2007 14:46:59 +
> Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
>> I have one powerpc machine which managed to compile this snapshot! It
>> paniced on boot as below, might be nfs so copied them. General results
>> are popping out on
On Wed, 2007-11-21 at 01:04 +0300, Dmitry Baryshkov wrote:
> Just to note, that there is an alternative implementation for at least
> the tc6393 chip devices. Most current version of those patches can be
> found in the OpenEmbedded monotone.
Yes, this is true. The core code in both cases
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> It seems that you're doing the same thing in both cases, except you're
> now extending it to include other random functionality, which means
> other things than syslets are suddenly affected.
>
> syslets are arguably a little bit different, since
> > Again I don't see the point of this change. A routine for cleaning up
> > resource tables expects logically to be passed a resource table to clean
> > up not some device it may be attached to.
>
> He needs to pass the pnp_dev to later be able to replace the:
>
> for (idx = 0; idx <
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> > lr-x-- 1 root root 64 Nov 20 18:03 3 -> /proc/net
>> > ...
>>
>> Yes all of those are nasty. So much for my clever way of implementing
>> these things. Grr. Simple hacks that almost work!
>
>
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static
101 - 200 of 1146 matches
Mail list logo
