> + mutex_lock(_mutex);
> + while (atomic_read(_ref) != 0) {
might be better to do the refcounting outside the thread and use the
kthread api, which is something we still need to do for lockd anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Sat, Dec 08, 2007 at 01:25:21PM +0100, Markus wrote:
> Well, just tried it. Started a dozen konquerors and attached strace to
> everyone. When one disapeared, I only got a "Process 9246 detached",
> nothing else is printed or written in the log.
>
> Markus
Hallo Markus
Whenever the
When a lock that a client is blocking on comes free, lockd does this in
nlmsvc_grant_blocked():
nlm_async_call(block->b_call, NLMPROC_GRANTED_MSG, _grant_ops);
the callback from this call is nlmsvc_grant_callback(). That function
does this at the end to wake up lockd:
Well, just tried it. Started a dozen konquerors and attached strace to
everyone. When one disapeared, I only got a "Process 9246 detached",
nothing else is printed or written in the log.
Markus
> On Fri, 7 Dec 2007, Markus wrote:
>
> > Well, now some windows vanished, but no additional
Fix "warning: Using plain integer as NULL pointer".
Convert 'x < y ? x : y' to use min() instead.
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
---
Compile-tested on i386 with "allyesconfig" and "allmodconfig".
Resend, since the 'Remove a
On Sat, 8 Dec 2007 13:12:14 +0100
Markus <[EMAIL PROTECTED]> wrote:
> I try that, but it will take a lot of time!
>
> Markus
This problem remembers me something...
On Sat, 8 Dec 2007 14:07:47 +
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > + mutex_lock(_mutex);
> > + while (atomic_read(_ref) != 0) {
>
> might be better to do the refcounting outside the thread and use the
> kthread api, which is something we still need to do for lockd anyway.
>
On Sat, Dec 08, 2007 at 08:59:31AM +0900, Tejun Heo wrote:
> Adrian Bunk wrote:
> > On Tue, Dec 04, 2007 at 10:49:37PM +0900, Tejun Heo wrote:
> >> When multiple built-in modules (especially drivers) provide the same
> >> capability, they're prioritized by link order specified by the order
> >>
On Monday 03 December 2007 16:23:58 Andi Kleen wrote:
>
> FYI
>
> Just saw this on a test system of mine running 2.4.24rc3 (+ some suse patches,
> but they're not changing anything near this AFAIK)
Got it again after rebooting the system. Can this be made a 2.6.24 blocker
or something?
Nick Warne schrieb:
I am bringing this up again - primarily as I forgot about it after
patching my build tree ages ago:
http://lkml.org/lkml/2007/10/27/68
Please see the patch I sent some days ago, which does the very
same thing: http://marc.info/?l=linux-kernel=119677244318528=2
I would
On Saturday 08 December 2007 23:19:58 Sheela wrote:
> Share net is not supported , Rusty is an "idiot" .
>
> Signed-off-by: Sheela Sequeira <[EMAIL PROTECTED]>
Acked-by: Rusty Russell <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Pavol Cvengros wrote:
Bill Davidsen wrote:
Pavol Cvengros wrote:
On Thursday 06 December 2007 21:15:53 Bill Davidsen wrote:
Pavol Cvengros wrote:
Hello,
I am trying LKML to get some help on one linux kernel related
problem.
Lately we got a machine with new HW from Intel. CPU is Intel
On Sat, 08 Dec 2007 14:11:44 +0100
Clemens Koller <[EMAIL PROTECTED]> wrote:
> Nick Warne schrieb:
> > I am bringing this up again - primarily as I forgot about it after
> > patching my build tree ages ago:
> >
> > http://lkml.org/lkml/2007/10/27/68
Subject: Re: Fw: scsi_wait_scan Kconfig
PLIP driver: convert the semaphore killed_timer_sem to
a completion
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
--
diff --git a/drivers/net/plip.c b/drivers/net/plip.c
index 57c9866..fee3d7b 100644
--- a/drivers/net/plip.c
+++ b/drivers/net/plip.c
@@ -106,6 +106,7 @@ static const char
tor, 06 12 2007 kl. 15:20 -0800, skrev Zach Brown:
> The following patches are a substantial refactoring of the syslet code. I'm
> branding them as the v7 release of the syslet infrastructure, though they
> represent a signifiant change in focus.
>
> My current focus is to see the most
On Sat, Dec 08, 2007 at 10:30:39AM +0100, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Subject : tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52
> > kmap_atomic_prot()
> > Submitter : Ingo Molnar <[EMAIL PROTECTED]>
> > References :
On Sat, 8 Dec 2007, Andrew Morton wrote:
> On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > This message contains a list of some regressions from 2.6.23 which have been
> > reported since 2.6.24-rc1 was released and for which there are no fixes in
> >
the memory return from scsi_host_alloc is alloced by kzalloc,
which is already zero initilized, so memset not needed.
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
drivers/scsi/3w-9xxx.c |2 --
drivers/scsi/3w-.c |2 --
2 files changed, 0 insertions(+), 4 deletions(-)
diff
On Saturday 08 December 2007 16:33:27 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote:
> > >
> > > * Mark Lord <[EMAIL PROTECTED]> wrote:
> > >
> > > > Ingo Molnar wrote:
> > > >> ...
> > > >> thanks. I do get the
Francois Romieu wrote:
Holger Hoffstaette <[EMAIL PROTECTED]> :
[...]
Maybe turning off sendfile or NAPI just lead to random success - so far it
really looks like tso on the r8169 is the common cause.
TSO on the r8169 is the magic switch but the regression makes imvho more
sense from a VM
* Mark Lord <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> ...
>> thanks. I do get the impression that most of this can/should wait until
>> 2.6.25. The patches look quite dangerous.
> ..
>
> I confess to not really trying hard to understand everything in this
> thread, but the implication
On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote:
> On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote:
> > Hello Peter,
> >
> > > > What specifically is wrong with dev->sem ?
> > >
> > > Nothing really, other than that they use semaphores to avoid lockdep :-/
> > >
> > > I think I know
On Tue, Dec 04, 2007 at 09:14:29AM +0100, Jan Altenberg wrote:
> Hi all,
>
> > > Your patch looks correct, and seems to be the only obvious chunk
> > > that's missing. So, I'll ack it FWIW ... usual policy for these
> > > patches is to go through Russell.
> >
> > You can add my Ack for what
Zhu Yi wrote:
On Thu, 2007-12-06 at 12:39 +0300, Cyrill Gorcunov wrote:
From: Cyrill Gorcunov <[EMAIL PROTECTED]>
Subject: [PATCH] iwlwifi3945/4965 - fix rate control algo reference leak
..
Any chance of getting LEDs support re-added to this driver,
perhaps in the 2.6.25 timeframe?
With that
On Dec 8, 2007 10:47 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> does the patch below help? But the root cause is likely some timer
> problems - do you get consistent results from:
>
Haven't yet tried the patch - will try a little later.
>while :; do time usleep 111; done
>
> or do
* Parag Warudkar <[EMAIL PROTECTED]> wrote:
> [] tick_broadcast_oneshot_control+0x10/0xda
> [] tick_notify+0x1d4/0x2eb
> [] get_next_timer_interrupt+0x143/0x1b4
> [] notifier_call_chain+0x2a/0x47
> [] raw_notifier_call_chain+0x17/0x1a
> [] clockevents_notify+0x19/0x4f
> []
Ingo Molnar wrote:
...
thanks. I do get the impression that most of this can/should wait until
2.6.25. The patches look quite dangerous.
..
I confess to not really trying hard to understand everything in this thread,
but the implication seems to be that this bug might affect udelay()
and
PPP synchronous tty channel driver: convert the semaphore dead_sem to
a completion
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
--
diff --git a/drivers/net/ppp_synctty.c b/drivers/net/ppp_synctty.c
index f0c6a19..f7472c8 100644
--- a/drivers/net/ppp_synctty.c
+++
Move the instrumentation Kconfig to
arch/Kconfig for architecture dependent options
- oprofile
- kprobes
and
init/Kconfig for architecture independent options
- profiling
- markers
Remove the "Instrumentation Support" menu. Everything moves to "General setup".
Delete the
On Dec 7, 2007 9:56 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> This looks pretty much like the problem I was solving yesterday.
>
> Parag, can you please try Linus latest and please check whether there
> is a stack trace with clockevents_program_event on the top in your
> dmesg.
>
Just
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Tue, 13 Nov 2007 21:17:10 +0530
> Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote:
>
> > From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
> >
> > This patch adds CONFIG_ARCH_SUPPORTS_KRETPROBES to the
> > arch//Kconfig file for relevant
Puts the content of arch/Kconfig in the "General setup" menu.
Linus:
> Should it come with a re-duplication of it's content into each
> architecture, which was the case previously ? The oprofile and kprobes
> menu entries were litteraly cut and pasted from one architecture to
> another. Should
Hi Andrew,
This time I am taking no chance :
The instrumentation menu removal patchset here applies against 2.6.24-rc4-mm1
_and_ against mmotm (dated : stamp-2007-12-05-15-24) without problem.
We should hopefully be able to stop racing against other architecture specific
fixes done underneath.
On Dec 8, 2007 10:10 AM, Parag Warudkar <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2007 9:56 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> >
> > This looks pretty much like the problem I was solving yesterday.
> >
> > Parag, can you please try Linus latest and please check whether there
> > is a
* Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote:
> >
> > * Mark Lord <[EMAIL PROTECTED]> wrote:
> >
> > > Ingo Molnar wrote:
> > >> ...
> > >> thanks. I do get the impression that most of this can/should wait until
> > >> 2.6.25. The
* Jiri Slaby <[EMAIL PROTECTED]> wrote:
> On 12/08/2007 09:39 AM, Ingo Molnar wrote:
> > * Jiri Slaby <[EMAIL PROTECTED]> wrote:
> >
> >> Unfortunately no change here.
> >
> > could you try to revert this change:
> >
> > -int softlockup_thresh = 10;
> > +int softlockup_thresh = 60;
> >
> >
On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote:
>
> * Mark Lord <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar wrote:
> >> ...
> >> thanks. I do get the impression that most of this can/should wait until
> >> 2.6.25. The patches look quite dangerous.
> > ..
> >
> > I confess to not
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like
* Michael Buesch <[EMAIL PROTECTED]> wrote:
> > i cannot see how. You can verify msleep by running something like this:
> >
> > while :; do time usleep 111000; done
> >
> > you should see a steady stream of:
> >
> > real0m0.113s
> > real0m0.113s
> > real0m0.113s
> >
> > (on
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
> Kay Sievers wrote:
> > Is the udev daemon (still) running while it fails?
>
> Yes, and there's something else I forgot to mention that may be
> significant... For the bad case, in addition to udevd, "ps -ef"
> shows a "sh -e
On Fri, 7 Dec 2007 15:52:06 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
>
> > Le Fri, 7 Dec 2007 14:55:25 +0100,
> > Ingo Molnar <[EMAIL PROTECTED]> a ??crit :
> >
> > > Firstly, we dont need the 'offset' anymore because cpu_clock()
> > >
On Dec 7, 2007 11:25 PM, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> Ultimately to implement /proc perfectly we need an implementation
> of d_revalidate because files and directories can be removed behind
> the back of the VFS, and d_revalidate is the only way we can let
> the VFS know that
On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote:
> > It must be the locking in __driver_attach(), taking dev->parent->sem
> > then taking dev->sem .. Assuming those are different structures, why
> > does lockdep trigger?
>
> They aren't different, parent is a struct device again.
It's
Well, no I am not the same markus. And I found that before, but I
thought it was something about cfs and imo that made it into linus-tree
in .23 not .22.
But I should perhaps try to change my name, perhaps that fixes it -.-
Markus
PS: am currently doing a bisect, thats really bad: third bisect
On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote:
> > BTW, You may be better off using "uuidgen -t" to generate the UUID in
> > the smolt RPM, since that will use 12 bits of randomness from
> > /dev/random, plus the MAC, address and timestamp. So even if there is
> > zero randomness in
On Sat, 2007-12-08 at 09:06 -0800, Daniel Walker wrote:
> On Sat, 2007-12-08 at 18:11 +0100, Peter Zijlstra wrote:
>
> > > It must be the locking in __driver_attach(), taking dev->parent->sem
> > > then taking dev->sem .. Assuming those are different structures, why
> > > does lockdep trigger?
>
Theodore Tso wrote:
On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote:
BTW, You may be better off using "uuidgen -t" to generate the UUID in
the smolt RPM, since that will use 12 bits of randomness from
/dev/random, plus the MAC, address and timestamp. So even if there is
zero
On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> i'm wondering why it had no effect now - the new code is in essence a
> NOP over what we had.
Maybe a dumb question. Why those changes in process_32.c in the patch and not in
process_64.c?
--
To unsubscribe from this list: send the line "unsubscribe
On Sat, 2007-12-08 at 08:53 -0800, Daniel Walker wrote:
> On Sat, 2007-12-08 at 13:16 +0100, Peter Zijlstra wrote:
> > On Sat, 2007-12-08 at 00:02 +0100, Remy Bohmer wrote:
> > > Hello Peter,
> > >
> > > > > What specifically is wrong with dev->sem ?
> > > >
> > > > Nothing really, other than
On Sat, Dec 08, 2007 at 12:32:04PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote:
> > > BTW, You may be better off using "uuidgen -t" to generate the UUID in
> > > the smolt RPM, since that will use 12 bits of randomness from
> > > /dev/random, plus the
On Sat, 2007-12-08 at 12:32 -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote:
> > > BTW, You may be better off using "uuidgen -t" to generate the UUID in
> > > the smolt RPM, since that will use 12 bits of randomness from
> > > /dev/random, plus the MAC,
On Sat, 2007-12-08 at 11:43 -0600, Matt Mackall wrote:
> On Sat, Dec 08, 2007 at 12:32:04PM -0500, Theodore Tso wrote:
> > On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote:
> > > > BTW, You may be better off using "uuidgen -t" to generate the UUID in
> > > > the smolt RPM, since that
On Sat, 8 Dec 2007, Matt Mackall wrote:
>
> Avoid calling page allocator with __GFP_ZERO, as we might be in atomic
> context and this will make thing unhappy on highmem systems. Instead,
> manually zero allocations from the page allocator.
I think this is fine, but didn't we fix the warning
On Sat, Dec 08, 2007 at 11:33:57AM -0600, Mike McGrath wrote:
>> Huh? What's the concern? All you are submitting is a list of
>> hardware devices in your system. That's hardly anything sensitive
>
> We actually had a very vocal minority about all of that which ended up
> putting us in the
On Sat, 2007-12-08 at 12:49 -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 11:33:57AM -0600, Mike McGrath wrote:
> >> Huh? What's the concern? All you are submitting is a list of
> >> hardware devices in your system. That's hardly anything sensitive
> >
> > We actually had a very
On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> i'm wondering why it had no effect now - the new code is in essence a
> NOP over what we had. Could you send me your current (modified)
> kernel/softlockup.c code?
Only these changes:
diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index
On Sat, 8 Dec 2007, Linus Torvalds wrote:
>
> But I'll apply it anyway, because it looks "obviously correct" from the
> standpoint that the _other_Â slob user already clears the end result
> explicitly later on, and we simply should never pass down __GFP_ZERO to
> the actual page allocator.
Hello,
The box is sun ultra 60 (dual sparc64). This was caught when
system (gentoo) was emerging some package.
[27006.402237] kernel BUG at fs/jbd/transaction.c:1894!
[27006.402268] \|/ \|/
[27006.402274] "@'/ .. \`@"
[27006.402279] /_|
On Sat, Dec 08, 2007 at 12:49:08PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 11:33:57AM -0600, Mike McGrath wrote:
> >> Huh? What's the concern? All you are submitting is a list of
> >> hardware devices in your system. That's hardly anything sensitive
> >
> > We actually had a
Daniel Walker wrote:
> On Thu, 2007-12-06 at 21:29 -0400, Kevin Winchester wrote:
>> Daniel Walker wrote:
>>> I've posted all the ones I've done so far ..
>>>
>>> ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/
>>>
>>> Feel free to review or test them.. I've found it pretty easy to
On Sat, 8 Dec 2007 19:20:28 +0100 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> The box is sun ultra 60 (dual sparc64). This was caught when
> system (gentoo) was emerging some package.
>
> [27006.402237] kernel BUG at fs/jbd/transaction.c:1894!
That's
J_ASSERT_BH(bh,
Matthew Garrett wrote:
On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote:
On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote:
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is
beyond end of object [20070126]
ACPI Error (psparse-0537):
On Sat, Dec 08, 2007 at 12:15:25PM -0600, Matt Mackall wrote:
>
> It might be better for us to just improve the pool initialization.
> That'll improve the out of the box experience for everyone.
>
Yeah, I agree. Although keep in mind, doing things like mixing in MAC
address and DMI information
Theodore Tso wrote:
On Sat, Dec 08, 2007 at 11:33:57AM -0600, Mike McGrath wrote:
Huh? What's the concern? All you are submitting is a list of
hardware devices in your system. That's hardly anything sensitive
We actually had a very vocal minority about all of that which ended up
putting
On Sat, Dec 08, 2007 at 11:43:43AM -0600, Matt Mackall wrote:
> > Huh? What's the concern? All you are submitting is a list of
> > hardware devices in your system. That's hardly anything sensitive
>
> Using MAC addresses -does- de-anonymize things though and presumably
> anonymous
On Sat, 8 Dec 2007 09:54:06 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> >
> > But I'll apply it anyway, because it looks "obviously correct" from the
> > standpoint that the _other___slob user already clears the end result
> > explicitly
On Sat, Dec 08, 2007 at 09:54:06AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> >
> > But I'll apply it anyway, because it looks "obviously correct" from the
> > standpoint that the _other_??slob user already clears the end result
> > explicitly later on, and
On Sat, 2007-12-08 at 14:17 -0400, Kevin Winchester wrote:
> Daniel Walker wrote:
> > On Thu, 2007-12-06 at 21:29 -0400, Kevin Winchester wrote:
> >> Daniel Walker wrote:
> >>> I've posted all the ones I've done so far ..
> >>>
> >>> ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/
> >>>
p->exit_state != 0 doesn't mean this process is dead, it may have sub-threads.
However, the new "p->exit_state && thread_group_empty(p)" check is not correct
either, this is just the temporary hack. Perhaps we can just remove this check,
but I don't understand orphaned process groups magic. At
ptrace_stop() decrements ->group_stop_count to "participate" in group stop.
This looks very wrong to me, the task can in fact decrement this counter twice.
If the tracee returns to the user-space before other threads complete the group
stop, it will notice TIF_SIGPENDING and do it again.
Another
do_wait(WSTOPPED) assumes that p->state must be == TASK_STOPPED, this is not
true if the leader is already dead. Check SIGNAL_STOP_STOPPED instead and use
->signal->group_exit_code.
This patch is not complete if not buggy. At the very minimum it needs cleanup.
Signed-off-by: Oleg Nesterov
Jeff Garzik wrote:
Robert Hancock wrote:
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
On Sat, 8 Dec 2007, Andrew Morton wrote:
>
> > So which warning is it that triggers the bogus error?
>
> It's a kmap_atomic() debugging patch which I wrote ages ago and whcih Ingo
> sucked into his tree. I don't _think_ this warning is present in your tree
> at all.
Ok, that explains it.
>
> > On Mon, 22 Oct 2007 13:43:16 +0100 (BST) Chris Rankin <[EMAIL PROTECTED]>
> > wrote:
> > > I have a Netgear MA301 PLX wireless networking adapter which wants to use
> > > the hostap_plx
> > > driver in Linux 2.6.23.1. This very same piece of hardware works fine in
> > > an old(!) P120
> > >
> > Subject: snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > work on Lenovo X60s
> > Submitter : Roland Dreier <[EMAIL PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/8/255
> > http://bugzilla.kernel.org/show_bug.cgi?id=9332
> > Handled-By :
>
On Sat, Dec 08, 2007 at 09:54:06AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> >
> > But I'll apply it anyway, because it looks "obviously correct" from the
> > standpoint that the _other_??slob user already clears the end result
> > explicitly later on, and
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> hi Mathieu,
>
> * Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Here is the architecture dependent instrumentation for LTTng. [...]
>
> A fundamental observation about markers, and i raised this point many
> many months ago
* Parag Warudkar <[EMAIL PROTECTED]> wrote:
> >while :; do time usleep 111; done
> >
> > or do these sleeps fluctuate?
>
> They seem to fluctuate - not sure if that's supposed to be exact or if
> below variations are normal - This is when my compiles are running -
it's normal for them
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > > Firstly, we dont need the 'offset' anymore because cpu_clock()
> > > > maintains offsets itself.
> > >
> > > Yes, but a lower quality one. __update_rq_clock tries to
> > > compensate large jumping clocks with a jiffy resolution, while my
Daniel Walker wrote:
>> Yes, you are right, I hadn't finished looking at all of the up() calls
>> when I came to my conclusion. I will try to convert a few that are not
>> on your list, but I would like to know how you are generating your
>> patches into those files with the diffstat and
Alan Cox wrote:
0x80 should be fine for anything PC compatible anyway, its specifically
reserved as a debug port and supported for *exactly* that purpose by
many chipsets.
Disagree. The definitions of PC compatible are quite problematic. I
have the advantage over some of you young
sparsemem-make-sparsemem-vmemmap-selectable.patch introduces a little bug.
SPARSEMEM_VMEMMAP can be enabled in an architecture that doesn't support it. If
the
architecture supports SPARSEMEM_VMEMMAP, SPARSEMEM_VMEMMAP_ENABLE is enabled,
so SPARSEMEM_VMEMMAP should depend on it.
Signed-off-by:
On Dec 8, 2007 2:13 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> > >while :; do time usleep 111; done
> > >
> > > or do these sleeps fluctuate?
> >
> > They seem to fluctuate - not sure if that's supposed to be exact or if
> > below
As an aside...
Speaking as the maintainer rng-tools, which is the home of the hardware
RNG entropy gathering daemon...
I wish somebody (not me) would take rngd and several other projects, and
combine them into a single actively maintained "entropy gathering" package.
IMO entropy gathering
On Sat, Dec 08, 2007 at 01:42:41AM -0800, Andrew Morton wrote:
> > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > work on Lenovo X60s
> > Submitter : Roland Dreier <[EMAIL PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/8/255
> >
* Parag Warudkar <[EMAIL PROTECTED]> wrote:
> Even on 100% idle I get variations that are approx in the same range
> when not idle. Clocksource is hpet if that matters. Next I think I
> will disable CPU_IDLE, Tickless
also try the hpet=disable boot option.
> My ssh connection just died -
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote:
>
>
> Alan Cox wrote:
> >
> >0x80 should be fine for anything PC compatible anyway, its specifically
> >reserved as a debug port and supported for *exactly* that purpose by
> >many chipsets.
> >
> >
> Disagree. The definitions of
Hello Peter and Daniel,
> Yeah, it are different lock instances, however by virtue of sharing the
> same lock init site, they belong to the same lock class. Lockdep works
> by tracking class dependancies, not instance dependancies.
The device and its parent both indeed have different
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > But I don't think we need to do anything for 2.6.24..
>
> Good. Although we should perhaps look at that reported performance
> problem with SLUB. It looks like SLUB will do a memclear() for the
> area twice (first for the whole page, then for
On Sat, Dec 08, 2007 at 02:36:33PM -0500, Jeff Garzik wrote:
>
> As an aside...
>
> Speaking as the maintainer rng-tools, which is the home of the hardware
> RNG entropy gathering daemon...
>
> I wish somebody (not me) would take rngd and several other projects, and
> combine them into a
* Theodore Tso <[EMAIL PROTECTED]> wrote:
> I am very happily running with Ingo's "snd hda suspend latency:
> shorten codec read" patch, which was originally intended to speed up
> resuming from hibernation, but which as I discovered, also has the
> nice side effect of eliminating the
On Sat, 2007-12-08 at 15:19 -0400, Kevin Winchester wrote:
>
> Yes, I've used quilt for working with mm patches in the past, but I'm
> not too familiar with the mail features. For example, how do you get
> the recipient list and Signed-off-by in the patch file? Do you just
> edit it by hand?
On Sat, 2007-12-08 at 20:52 +0100, Remy Bohmer wrote:
> Hello Peter and Daniel,
>
> > Yeah, it are different lock instances, however by virtue of sharing the
> > same lock init site, they belong to the same lock class. Lockdep works
> > by tracking class dependancies, not instance dependancies.
Matt Mackall wrote:
On Sat, Dec 08, 2007 at 02:36:33PM -0500, Jeff Garzik wrote:
As an aside...
Speaking as the maintainer rng-tools, which is the home of the hardware
RNG entropy gathering daemon...
I wish somebody (not me) would take rngd and several other projects, and
combine them into
Previous patch had another bug. This one works fine.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
diff --git a/mm/Kconfig b/mm/Kconfig
index 010a261..9ef9741 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -117,7 +117,7 @@ config SPARSEMEM_VMEMMAP_ENABLE
config SPARSEMEM_VMEMMAP
bool
On Dec 8, 2007 2:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> > Even on 100% idle I get variations that are approx in the same range
> > when not idle. Clocksource is hpet if that matters. Next I think I
> > will disable CPU_IDLE, Tickless
>
>
* Remy Bohmer <[EMAIL PROTECTED]> wrote:
> But... now we do not transfer the dev->sem to a mutex, because lockdep
> will start generating false positives, and thus we mask the lockdep
> error, by not converting the dev->sem to what it really is...
no, you are wrong. If you want to do complex
* Parag Warudkar <[EMAIL PROTECTED]> wrote:
> But there are still fluctuations under 100% idle -
do you have CONFIG_HIGH_RES_TIMERS=y?
> IDLE
> real0m1.112s
> real0m1.131s
> real0m1.112s
> real0m1.112s
> real0m1.139s
these fluctuations would still be OK if they are due to
On Wed, Dec 05, 2007 at 09:31:26PM -0600, Jay Cliburn wrote:
> On Wed, 5 Dec 2007 22:00:03 +0100
> Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Dec 04, 2007 at 09:04:33PM -0600, Jay Cliburn wrote:
> > > Sam,
> > >
> > > This piece of the top-level Makefile in current git causes an
> > >
301 - 400 of 512 matches
Mail list logo
