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 e50b44
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 ver
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 simply
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, !buffer_jb
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 collectio
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 all
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 p
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 <[EMAIL
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 allocated
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.
> Kn
> > 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 already
* 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 recipient
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 guys,
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: Mi
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 variatio
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
> > http://b
* 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 - ano
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 PC
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
pointers/ins
* 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 the
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 singl
* 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 reported
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? O
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 "S
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
>
> a
* 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 l
* 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 H
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
> > >
On Sat, 8 Dec 2007 20:16:29 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * 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_clo
On Sat, Dec 08, 2007 at 03:04:32PM -0500, Jeff Garzik wrote:
> 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
> heh, along those lines you could also do
>
> dmesg > /dev/random
>
>
>
> dmesg often has machine-unique identifiers of all sorts (including the
> MAC address, if you have an ethernet driver loaded)
>
> Jeff
A good three-part solution would be:
1) Encourage distributions to do "dme
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the SLUB concept is proudly outlined in init/Kconfig:
>
> config SLUB
> bool "SLUB (Unqueued Allocator)"
> help
>SLUB is a slab allocator that minimizes cache line usage
>instead of managing queues of cached obj
On Sat, Dec 08, 2007 at 03:04:32PM -0500, Jeff Garzik wrote:
> That's a bit of a tangent on a tangent. :) Most people don't have a
> hardware RNG.
Actually, most Business class laptops from IBM/Lenovo, HP, Dell,
Fujitsu, and Sony laptops *do* have TPM chips that among other things,
contain a sl
> In any case, my machine does not have an ISA bus. Why should it? It's
> a laptop!
Yes it does. The branding spec said "No ISA bus" so it was renamed "LPC"
and hidden internally, but its alive and well.
> has already serviced the bus and delivered data! Why put many
> microseconds into the
Hello Peter,
> And while you might not see it in-tree anymore, lockdep does help out
> tremendously while developing new code. I'm sure that without it the
> locking would be in a much worse state than it is today.
I am not arguing that, I am also convinced it has done a good job.
> I have a goo
pcm_native: fix sparse warning about shadowing 'state' symbol
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
sound/core/pcm_native.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index fb3dde4..925f0b6 100644
via82xx: minor optimization in snd_via82xx_free
don't check X, when we just checked !X before goto
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
sound/pci/via82xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c
index c
pcm_lib: fix sparse warning about shadowing 'n' symbol
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
sound/core/pcm_lib.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 806f1fb..653fb5c 100644
--- a/sou
pcm_lib: fix sparse warning about different signedness
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
sound/core/pcm_lib.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 653fb5c..f2c3cf3 100644
--- a/sound/core/pc
The following is a series of patches related to Unionfs: just a couple of
small bug fixes and/or optimizations.
These patches were tested (where appropriate) on Linus's 2.6.24 latest code
(as of v2.6.24-rc4-124-gf194d13), MM, as well as the backports to
2.6.{23,22,21,20,19,18,9} on ext2/3/4, xfs,
Also a bug fix: disallow unrecognized branch modes at mount time, instead of
defaulting to "rw".
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/main.c | 44 ++--
fs/unionfs/super.c | 12
fs/unionfs/union.h |3 +--
3 files
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/dentry.c | 38 +++---
1 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 05d9914..7d27987 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/d
On Dec 8, 2007 3:11 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> > But there are still fluctuations under 100% idle -
>
> do you have CONFIG_HIGH_RES_TIMERS=y?
Yes - NO_HZ=y and HIGH_RES_TIMERS=y.
My ssh connection still died with hpet=disable alt
I am going to do a test on another "unused" port.
However, I realized as I was thinking about this. 0x80 is the
"diagnostic device" port. It is not an "unused" port.
Normally, Linux would support a device like the diagnostic device by
providing a character device, called /dev/post-diagnosis
Hello Ingo,
> no, you are wrong. If you want to do complex locking, you can still do
> it: take a look at the dev->sem conversion patches from Peter which
> correctly do this. Lockdep has all the facilities for that.
> (you just dont know about them)
Ok.
> the general policy message here is: do
Theodore Tso wrote:
I think the userspace config problems were mainly due to the fact that
there wasn't a single official userspace utility package for the
random number package. Comments in drivers/char/random.c for how to
set up /etc/init.d/random is Just Not Enough.
Absolutely.
If we had
sound/core.h: include sound/driver.h
include sound/driver.h in sound/core.h because core.h
uses SNDRV_CARDS (which is defined in sound/driver.h)
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
include/sound/core.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/inc
On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
> Which problems? I did not see any special things, it looked rather
> straight forward. What have I overlooked?
On suspend it locks the whole device tree, this means it has 'unbounded'
nesting and holds an 'unbounded' number of locks. Neithe
On Sat, 8 Dec 2007 15:46:54 -0500
"Parag Warudkar" <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 3:11 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Parag Warudkar <[EMAIL PROTECTED]> wrote:
> >
> > > But there are still fluctuations under 100% idle -
> >
> > do you have CONFIG_HIGH_RES_TIMERS
sound/core/memory.c: include sound/core.h
copy_to_user_fromio and copy_from_user_toio are declared in sound/core.h
but sound/core/memory.c doesn't include it - fix it
depends on: "[PATCH] sound/core.h: include sound/driver.h"
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
sound/core/memo
sound/core/seq: move declarations of globally visible variables to proper
headers
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
sound/core/seq/seq_clientmgr.c |2 --
sound/core/seq/seq_clientmgr.h |2 ++
sound/core/seq/seq_timer.c |7 ---
sound/core/seq/seq_timer.h
Peter,
Thanks for this clear answer.
Remy
2007/12/8, Peter Zijlstra <[EMAIL PROTECTED]>:
>
> On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
>
> > Which problems? I did not see any special things, it looked rather
> > straight forward. What have I overlooked?
>
> On suspend it locks the wh
asm-*/compat.h: fix typo in comment
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
include/asm-ia64/compat.h|2 +-
include/asm-mips/compat.h|2 +-
include/asm-parisc/compat.h |2 +-
include/asm-powerpc/compat.h |2 +-
include/asm-s390/compat.h|2 +-
include
On Dec 8, 2007 3:51 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> what chipset is this?
> (I wonder if there's one where we shouldn't be force-enabling the hpet)
It's an Intel Mac Mini - Intel 945GM chipset.
I believe OSX requires HPET and so there shouldn't be a need to force
enable it on thi
info_oss: move prototype of snd_card_info_read_oss to info.h
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
include/sound/info.h |2 ++
sound/core/info_oss.c |2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/sound/info.h b/include/sound/info.h
index fec
rawmidi: let sparse know what is going on _for real_
snd_rawmidi_kernel_read1/write1 weren't annotated but used
copy_to_user/copy_from_user when one of parameters (kernel) was equal to 0
remove it and add properly annotated parameter
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
sound/co
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 singl
On Fri, Nov 30, 2007 at 04:14:55PM -0600, Kumar Gala wrote:
> Ben and I are talking about using fixmap on ppc for similar applications to
> it use on x86. However in poking around other arch's (sparc, mips) they
> appear to have some support but not as complete as x86.
>
> For example both SPAR
> The point here is that Linux is NOT using a defined-to-be "unused"
> port. It IS using the "diagnostic" port, and talking to a diagnostic
> device that *is* used, and may be present.
Just like millions of other pieces of software from the same era.
> 2) Start a background task with the main
On Sat, Dec 08, 2007 at 02:19:54PM -0600, Matt Mackall wrote:
> On Sat, Dec 08, 2007 at 03:04:32PM -0500, Jeff Garzik wrote:
> > 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
> 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
>> Please see the patch I sent some days ago, which does the very
>> same thing:
Linus Torvalds schrieb:
But the disk errors are something else, doesn't ring a bell. Sounds like
IO corruption on the group descriptor block or something like that. Might
be worth testing to see if the problem goes away with less than 4GB of
RAM..
Today, I tested with different amounts of
>> +extern asmlinkage long (*sys_call_table[])(long, long, long,
> This should be something like below instead, otherwise gcc wont parse
> asmlinkage as being an attribute of the function signature.
> extern long (asmlinkage *sys_call_table[])(long, long, long,
Yeah, thanks for pointing
Well, after that I tried to verify that 22 is really fine.
Unfortunatelly under heavy load its the same... even with .19 (the
oldes kernel I have still installed)
I just noticed it, because its harder to produce it on .22 and before.
You guys tuned the kernel so it was easier.
So it must be some
Bill Davidsen wrote:
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
On Saturday, 8 of December 2007, Andrew Morton wrote:
> On Sat, 8 Dec 2007 09:28:15 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Fabio Comolli <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > > Subject : Battery shows up twice in kpowersave
> > > > Submitter : Rolf Ei
On Mon, Dec 03, 2007 at 09:02:19PM +1100, Rusty Russell wrote:
> On Sunday 02 December 2007 22:22:31 Geert Uytterhoeven wrote:
> > On Sat, 1 Dec 2007, Pierre Ossman wrote:
> > > Yeah, that could work. Have a header with stuff like this:
> > >
> > > typedef u16 __attribute__((aligned(2))) aligned_u1
On Saturday, 8 of December 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
On Thu, Dec 06, 2007 at 02:32:05PM -0500, Bill Davidsen wrote:
>...
> Sounds like a local DoS attack point to me...
As long as /dev/random is readable for all users there's no reason to
use /dev/urandom for a local DoS...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked sudd
Sunday 09 December 2007 00:03:45 tarihinde Adrian Bunk şunları yazmıştı:
> On Thu, Dec 06, 2007 at 02:32:05PM -0500, Bill Davidsen wrote:
> >...
> > Sounds like a local DoS attack point to me...
>
> As long as /dev/random is readable for all users there's no reason to
> use /dev/urandom for a local
On Saturday, 8 of December 2007, Theodore Tso wrote:
> 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
On Saturday, 8 of December 2007, Richard Purdie wrote:
> On Sat, 2007-12-08 at 03:40 +0100, Rafael J. Wysocki wrote:
> > Subject : leds: ledtrig-timer calls sleeping function from
> > invalid context
> > Submitter : Márton Németh <[EMAIL PROTECTED]>
> > References : http://bugzilla.
On Sat, Dec 08, 2007 at 10:21:11PM +0100, Stefan Richter wrote:
> Besides, in order for scsi_wait_scan to work, drivers need to support it
> explicitly, don't they? If so, simply kill the "default m" from config
> SCSI_WAIT_SCAN and let any driver which is integrated with it select it.
No. All d
Hi Linus,
> On Fri, 7 Dec 2007, Linus Torvalds wrote:
> >
> > Can you do one run with oprofile, and see exactly where the cost is? It
> > should hopefully be pretty darn obvious, considering your timing.
The results are here:
http://people.redhat.com/srostedt/slub/results/slab.op
http://people.
On Saturday, 8 of December 2007, Borislav Petkov wrote:
> On Fri, Dec 07, 2007 at 09:19:09PM +0100, Rafael J. Wysocki wrote:
>
> ...
>
> > > > Well, there's a patchset in the current mainline that allows you to use
> > > > arbitrary (sufficiently new) kernel to load the image and then restore
>
Peter Zijlstra wrote, On 12/08/2007 09:50 PM:
> On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
>
>> Which problems? I did not see any special things, it looked rather
>> straight forward. What have I overlooked?
>
> On suspend it locks the whole device tree, this means it has 'unbounded'
I can confirm that 2.6.24rc4 with the (second) patch works fine.
--
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux
No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
and CONFIG_NO_HZ.
I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last -
that way we can at least tell what is required to be hit with this
problem.
Parag
--
To unsubscribe from this list: send the line "unsubscribe
On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> i'm wondering why it had no effect now
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e0d3a4f..a46c252 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -47,15 +47,21 @@ void __init cpu_hotplug_init(void)
}
#ifdef CONFIG_HOTPLUG_CPU
-
+#include
void
On Dec 8, 2007 9:52 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the scariest bit isnt even the scaling i think - that is a fairly
> straightforward and clean PER_CPU-ization of the global scaling factor,
> and its hookup with cpufreq events. (and the credit for that goes to
> Guillaume Chazarain)
Can some please explain with almost identical kernel .config's I see this
on a p965 Intel board:
CPU0 CPU1 CPU2 CPU3
0: 2501669875 0 0 0 IO-APIC-edge timer
1: 8 0 0 0 IO-APIC-edge i8042
On Sun, Dec 09, 2007 at 12:10:10AM +0200, Ismail Dönmez wrote:
> > As long as /dev/random is readable for all users there's no reason to
> > use /dev/urandom for a local DoS...
>
> Draining entropy in /dev/urandom means that insecure and possibly not random
> data will be used and well thats a se
On Sat, Dec 08, 2007 at 09:42:39PM +0100, Willy Tarreau wrote:
> I remember having installed openssh on an AIX machines years ago, and
> being amazed by the number of sources it collected entropy from. Simple
> commands such as "ifconfig -a", "netstat -i" and "du -a", "ps -ef", "w"
> provided a lot
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> 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
101 - 200 of 256 matches
Mail list logo
