Hi,
2007/6/6, Christoph Lameter <[EMAIL PROTECTED]>:
Note that the corruption seems to have its cause in a decrement done at
offset 16 into the object pointing to the refcount in struct hci_dev. So
it looks like the refcount was decremented after the object was freed.
sysfs related?
I noticed
On Tue, 2007-06-05 at 16:39 -0700, Andrew Morton wrote:
> On Tue, 05 Jun 2007 17:05:25 +0200
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > The purpose of audit_bprm() is to log the argv array to a userspace daemon
> > at
> > the end of the execve system call. Since user-space hasn't had time
As reported in http://bugzilla.kernel.org/show_bug.cgi?id=7815
this URL 404's. Unless they're coming back, we should probably
just remove them.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index f1d60b6..8f665bb 100644
---
Hi,
If there is a multithread process which is waiting on restartable syscall
and ptraced, some threads may return from syscalls with a errno which should
never be seen by user programs when they receive SIGSTOP. It is not a rare
case beacuse strace send SIGSTOP to attached process on its exit
On Tue, Jun 05, 2007 at 07:20:14PM -0500, [EMAIL PROTECTED] wrote:
> sorry for not responding i was busy (i updated my sys to fc7)
> on fc7-i386 and on fc-x86-64(2.6.22-rc4-cfq7 SMP PREEMPT x86_64 GNU/Linux) i
> can't see usb scanner
> i test this with hp-6300 and aqfa snapscan-1212u
> non
Hi Jeff,
Don't see a fix for this issue in your tree, although i think someone
else may have already reported this. Just thought better safe than
sorry and report perhaps again that rc4 can't boot here because the
sata drives can not be found. Reverting commit 464cf177 fixes the
problem.
As
On Fri, Jun 01, 2007 at 07:40:54AM -0400, Jeff Garzik wrote:
> Filippo Carletti wrote:
> >This patch adds support for some chipsets in ahci driver.
> >The list comes from a patch for redhat kernel 2.6.9-34.
> >I only tested ICH8.
> >
> >The original patch contained also this lines (that I
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 07:26:52 +0200
> > Holding a global mutex over recvmsg() calls under AF_UNIX is pretty
> > much a non-starter, this will kill performance for multi-threaded
> > apps.
>
> That's an rwsem held for read. It's held for write in
On Tue, Jun 05, 2007 at 09:31:33PM -0700, Li, Tong N wrote:
> Willy,
>
> These are all good comments. Regarding the cache penalty, I've done some
> measurements using benchmarks like SPEC OMP on an 8-processor SMP and
> the performance with this patch was nearly identical to that with the
>
Hello,
I was working on a I/O heavy workload (parsing 100K spam messages to
extract certain structures) when I got this in the kernel log:
[ 2320.132893] ata1.00: exception Emask 0x2 SAct 0x701f SErr 0x0 action 0x2
frozen
[ 2320.132899] ata1.00: (spurious completions during NCQ issue=0x0
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> > Date: Mon, 04 Jun 2007 11:45:32 +0200
> >
> > > > A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> > > > send()+close() on the peer, causing recv() to return zero, even though
> > > > the sent data should be received.
> > > >
> > > >
Rediffed version of the patch from ..
http://bugzilla.kernel.org/show_bug.cgi?id=8016
that seems to be lingering for some time.
Original patch by: Andy Shevchenko <[EMAIL PROTECTED]>
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/sound/pci/hda/patch_realtek.c
Note that the corruption seems to have its cause in a decrement done at
offset 16 into the object pointing to the refcount in struct hci_dev. So
it looks like the refcount was decremented after the object was freed.
sysfs related?
-
To unsubscribe from this list: send the line "unsubscribe
Hi, Andrew
kfree(NULL) is legal, and is often used.
Apart from the null pointer, IMHO,there's two problem need to be
fixed, I'm not sure.
What's your opinion?
1. the label indent should be removed
2. similar code use different label, some use " __unlock" but others
use "__unalloc",
On Tue, Jun 05, 2007 at 11:16:13AM +0200, Rene Herman wrote:
>On 06/05/2007 04:10 AM, WANG Cong wrote:
>
>>On Mon, Jun 04, 2007 at 01:57:51PM -0400, Jeff Garzik wrote:
>
>>>A matter of opinion :) I tend to think goto is special enough to
>>>warrant column 1 unconditionally. It is special, so it
From: Randy Dunlap <[EMAIL PROTECTED]>
Use NULL instead of 0 for pointer:
arch/x86_64/kernel/vsyscall.c:183:21: warning: Using plain integer as NULL
pointer
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/vsyscall.c |2 +-
1 file changed, 1 insertion(+), 1
From: Randy Dunlap <[EMAIL PROTECTED]>
Use NULL instead of 0 for pointer:
drivers/mtd/chips/cfi_cmdset_0001.c:2258:43: warning: Using plain integer as
NULL pointer
Other changes by inspection.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/mtd/chips/cfi_cmdset_0001.c | 10
On Tue, 5 Jun 2007, Linus Torvalds wrote:
> On Tue, 5 Jun 2007, Davide Libenzi wrote:
> > On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> > >
> > > Yeah, synchronous signals should probably never be delivered to another
> > > process, even via signalfd. There's no point delivering a SEGV to
Willy,
These are all good comments. Regarding the cache penalty, I've done some
measurements using benchmarks like SPEC OMP on an 8-processor SMP and
the performance with this patch was nearly identical to that with the
mainline. I'm sure some apps may suffer from the potentially more
migrations
On Wed, 6 Jun 2007 03:27:31 + "young dave" <[EMAIL PROTECTED]> wrote:
> Hi,
> > Are you able to reproduce this in 2.6.22-rc4?
>
> The bug seems doesn't exist in 2.6.22-rc4, I have tested it, the
> unpluging can't produce kernel bug message.
>
OK, thanks. I'll drop
> a) Process-global signals can be read by any thread (inside or outside
> of the process receiving the signal).
>
> Rationale:
> This should always work, so there's no reason to limit it.
I agree, with an appropriate fix to recalc_sigpending_tsk() to only
clear TIF_SIGPENDING if tsk ==
[PATCH] x86_64: remove extra extern declaring about dmi_ioremap
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/include/asm-x86_64/dmi.h b/include/asm-x86_64/dmi.h
index 93b2b15..fc7b576 100644
--- a/include/asm-x86_64/dmi.h
+++ b/include/asm-x86_64/dmi.h
@@ -3,15 +3,12 @@
On 6/5/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
init_memory_mapping is not enough; it also needs a working
page allocator. But at this point there is only bootmem.
I don't think the patch is correct.
you are right it failed with one 2G system.
YH
-
To unsubscribe from this list: send the
On Tue, 2007-06-05 at 20:37 -0700, Linus Torvalds wrote:
>
> On Tue, 5 Jun 2007, Davide Libenzi wrote:
> > On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> > >
> > > Yeah, synchronous signals should probably never be delivered to another
> > > process, even via signalfd. There's no point
> That'd be a limitation. Like you can choose to not handle SEGV, you can
> choose to have a signalfd listening to it. Of course, not with the
> intention to *handle* the signal, but with a notification intent.
Hrm.. either you handle it or you are dead ... I fail to see how
signalfd can sneak
On Tue, 5 Jun 2007, Davide Libenzi wrote:
> On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> >
> > Yeah, synchronous signals should probably never be delivered to another
> > process, even via signalfd. There's no point delivering a SEGV to
> > somebody else :-)
>
> That'd be a limitation.
Hi Tong,
On Tue, Jun 05, 2007 at 06:56:17PM -0700, Li, Tong N wrote:
> Hi all,
>
> I've ported my code to mainline 2.6.21.3. You can get it at
> http://www.cs.duke.edu/~tongli/linux/.
as much as possible, you should post your patch for others to comment
on it. Posting just a URL is often fine
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-05 at 17:58 -0700, Nicholas Miell wrote:
> >
> > "At the time of generation, a determination shall be made whether the
> > signal has been generated for the process or for a specific thread
> > within the process. Signals which
On Tue, 5 Jun 2007, Christoph Lameter wrote:
> H... But we have sent it a SIGKILL. If the process is following
> conventions then it is exiting. Of course the process could be abusing the
> system and attempting to OOM the whole system as an act of revenge for
> being killed but isnt this
Hi,
Are you able to reproduce this in 2.6.22-rc4?
The bug seems doesn't exist in 2.6.22-rc4, I have tested it, the
unpluging can't produce kernel bug message.
Regards
dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On 2007.06.06 09:01:57 +, Wang Zhenyu wrote:
>
> This patch adds pci ids for G33, Q33 and Q35 chips
>
> It bases on below intel-agp patches currently in -mm tree:
> intel_agp-cleanup-intel-private-data.patch
> intel_agp-cleanup-intel-private-data-update.patch
>
On Tue, 2007-06-05 at 17:58 -0700, Nicholas Miell wrote:
>
> "At the time of generation, a determination shall be made whether the
> signal has been generated for the process or for a specific thread
> within the process. Signals which are generated by some action
> attributable to a particular
Hi,
Are you able to reproduce this in 2.6.22-rc4?
The kmalloc in dmesg is in skbuff.c:pskb_expand_head, I will try
2.6.22-rc4 ASAP.
-
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 Wed, 06 Jun 2007 12:37:39 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote:
> (This cleanup seems to have gotten lost in rc3-mm1? It was in rc2-mm1
> called lguest-the-host-code-update-for-mm-simplify-boot_params.patch)
>
> Andrew patched up lguest after the boot parameters became a proper
>
On Wed, 6 Jun 2007 01:56:01 + "young dave" <[EMAIL PROTECTED]> wrote:
> Hi,
> when I remove the usb bluetooth adapter , the kernel reporting bug:
>
> /* this two line is printk message I printed in net/bluetooth/hci_core.c */
>
> #before free dev: c3758430
> #after free dev
>
>
(This cleanup seems to have gotten lost in rc3-mm1? It was in rc2-mm1
called lguest-the-host-code-update-for-mm-simplify-boot_params.patch)
Andrew patched up lguest after the boot parameters became a proper
structure, but in fact it can be considerably neatened.
Signed-off-by: Rusty Russell
Hey Ingo,
So we've been seeing the following trace fairly frequently on our SMP
boxes when running kernbench:
BUG: at kernel/softirq.c:639 __tasklet_action()
Call Trace:
[] dump_trace+0xaa/0x32a
[] show_trace+0x41/0x5c
[] dump_stack+0x15/0x17
[] __tasklet_action+0xdf/0x12e
[]
Hi all,
I've ported my code to mainline 2.6.21.3. You can get it at
http://www.cs.duke.edu/~tongli/linux/. As I said before, the intent of
the patch is not to compete with CFS and SD because the design relies on
the underlying scheduler for interactive performance. The goal here is
to present a
Hi,
when I remove the usb bluetooth adapter , the kernel reporting bug:
/* this two line is printk message I printed in net/bluetooth/hci_core.c */
#before free dev: c3758430
#after free dev
=
BUG kmalloc-1024: Poison
On Tue, 5 Jun 2007, David Rientjes wrote:
> mems_allowed. Regardless, we should not allow allocations outside of the
> cpuset because we have marked it TIF_MEMDIE and we don't have any explicit
> guarantee that it is exiting yet and not mlock'ing an excessive amount of
> memory that exceeds
Hi there,
Using 2.6.22-rc3 and finding it impossible to get the UDMA/66
connection advertised by a new dvd burner. Substituting an old
hard drive in place of the DVD yields UDMA/100. Yet with the
same cable, libata refuses to do more than /33 complaining that
it's a 40-wire cable. I've
On Tue, 5 Jun 2007, Christoph Lameter wrote:
> On Tue, 5 Jun 2007, David Rientjes wrote:
>
> > Obviously GFP_KERNEL allocations can allocate regardless of our memory
> > exclusivity, but the point is that a job in one exclusive cpuset should
> > not have the ability to effect the performance
On Tue, Jun 05, 2007 at 04:57:07PM -0700, Darrick J. Wong wrote:
> On Tue, Jun 05, 2007 at 02:14:51PM -0700, Siddha, Suresh B wrote:
>
> > Can you send us your system's dmesg aswell as output of /proc/interrupts?
>
> http://sweaglesw.net/~djwong/docs/dmesg
>
Jeremy Fitzhardinge wrote:
> In a virtual environment, device drivers such as legacy IDE will waste
> quite a lot of time probing for their devices which will never appear.
> This helper function allows a paravirt implementation to lay claim to
> the whole iomem and ioport space, thereby disabling
In a virtual environment, device drivers such as legacy IDE will waste
quite a lot of time probing for their devices which will never appear.
This helper function allows a paravirt implementation to lay claim to
the whole iomem and ioport space, thereby disabling all device drivers
trying to claim
A domU Xen environment has no non-virtual drivers, so make sure
they're all disabled at once. This noticeably speeds up boot time.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
diff -r c79da0042c7d arch/i386/xen/setup.c
--- a/arch/i386/xen/setup.c
On Tue, 5 Jun 2007, Stephane Eranian wrote:
> > > +static int pfm_task_incompatible(struct pfm_context *ctx, struct
> > > task_struct *task)
> > > +{
> > > + /*
> > > + * no kernel task or task not owned by caller
> > > + */
> > > + if (!task->mm) {
> > > + PFM_DBG("cannot attach to
On Tue, 5 Jun 2007, David Rientjes wrote:
> Obviously GFP_KERNEL allocations can allocate regardless of our memory
> exclusivity, but the point is that a job in one exclusive cpuset should
> not have the ability to effect the performance (in terms of reclaim and
> swap), memory usage, or
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
> > Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> >> Serge E. Hallyn wrote:
> >>> >From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001
> >>> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> >>> Date: Mon, 4 Jun
On Tue, 5 Jun 2007, Christoph Lameter wrote:
> Exclusive is not as absolute as you may think. There is also the
> GFP_KERNEL exception.
>
Memory exclusivity with respect to cpusets should guarantee that memory
nodes do not overlap with siblings if they are marked with mems_exclusive.
The
On Tue, 5 Jun 2007 20:37:52 -0400 Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 05, 2007 at 05:00:01PM -0700, Andrew Morton wrote:
> > On Tue, 5 Jun 2007 16:50:55 -0400
> > Jeff Dike <[EMAIL PROTECTED]> wrote:
> >
> > > [ This is 2.6.22 material ]
> > >
> > > Having KERNEL_STACK_ORDER in
> Sure, that behavior is unchanged. We're relying on
> nearest_exclusive_ancestor() to determine if such nodes overlap.
Ok ... my points on cpusets semantics having been heard,
I stand back down on the matter of memory semantics, where
I am not the master.
Thanks.
--
I
On Tue, 5 Jun 2007, Paul Jackson wrote:
> Well, I can't speak to the 'real' meaning of TIF_MEMDIE with authority,
> but I can speak to the meaning of cpuset flags.
>
> The mem_exclusive flag doesn't mean this.
>
> It means that you cannot overlap the memory of a sibling cpuset.
>
Which, with
On Tue, 2007-06-05 at 20:15 +0200, Andi Kleen wrote:
> On Wed, Jun 06, 2007 at 12:56:36AM +1000, Rusty Russell wrote:
> > In recent -mm kernels, the TSC capability cannot be disabled,
> > resulting in a divide by zero error in the normal sched_clock.
>
> That will hopefully change. I hope hpa
On Tue, 2007-06-05 at 17:07 +0100, Alan Cox wrote:
> On Wed, 06 Jun 2007 00:58:03 +1000
> Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > The IDE probe is the slowest part of boot: by suppressing it we cut
> > boot from from 3 seconds to half a second.
>
> NAK NAK NAK NAK NAK
Hi Alan!
> >
Hello all,
I get these warnings compiling rc4 (see attached out.log file). I'm used
to warnings compiling my (vanilla) kernels, but these look more
suspicious than usual to me.
If this is nothing to worry about, please disregard. Otherwise please
CC.
Regards
Sebastian
--
"When the going
On Tue, 2007-06-05 at 17:37 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> > > On Tue, 5 Jun 2007, Nicholas Miell wrote:
> > >
> > > > Yes, that's certainly wrong, but that's an implementation issue. I was
Dave,
This patch adds pci ids for G33, Q33 and Q35 chips, and update with new
GTT size and stolen mem size detect method on these chips.
It bases on below intel-agp patches currently in -mm tree:
intel_agp-cleanup-intel-private-data.patch
intel_agp-cleanup-intel-private-data-update.patch
On Wed, Jun 06, 2007 at 10:07:46AM +1000, Rusty Russell wrote:
> On Tue, 2007-06-05 at 10:34 -0500, Matt Mackall wrote:
> > On Wed, Jun 06, 2007 at 01:00:06AM +1000, Rusty Russell wrote:
> > > We currently use a "waker" process: a child of the launcher which
> > > selects() on the incoming file
On Tue, Jun 05, 2007 at 04:54:35PM +0200, Michal Piotrowski wrote:
> SATA/PATA
>
> Subject: libata reset-seq merge broke sata_sil on sh
> References : http://lkml.org/lkml/2007/5/10/63
> Submitter : Paul Mundt <[EMAIL PROTECTED]>
> Handled-By : Tejun Heo <[EMAIL PROTECTED]>
> Caused-By :
OK. It sounds like a healthy dose of comments is in order. I'll
clean things up and send out a new patch sometime tonight or tomorrow.
Additional comments inline below:
> - len = strnlen_user((void __user *)p, PAGE_SIZE*MAX_ARG_PAGES);
> - if (!len || len >
On Tue, Jun 05, 2007 at 05:00:01PM -0700, Andrew Morton wrote:
> On Tue, 5 Jun 2007 16:50:55 -0400
> Jeff Dike <[EMAIL PROTECTED]> wrote:
>
> > [ This is 2.6.22 material ]
> >
> > Having KERNEL_STACK_ORDER in defconfig overrides the value provided by
> > Kconfig, breaking UML/x86_64, which wants
Rui Nuno Capela wrote:
> Thomas Gleixner wrote:
>> On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote:
>>> Is there anything I can do better to help myself figuring out this
>>> issue? As this is a modern laptop such things like a serial console are
>>> unavailable, but it would be nice to
On Tue, 2007-06-05 at 10:34 -0500, Matt Mackall wrote:
> On Wed, Jun 06, 2007 at 01:00:06AM +1000, Rusty Russell wrote:
> > We currently use a "waker" process: a child of the launcher which
> > selects() on the incoming file descriptors. It sends a SIGUSR1 to the
> > launcher whenever select()
On Tue, 5 Jun 2007, Nicholas Miell wrote:
> On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> > On Tue, 5 Jun 2007, Nicholas Miell wrote:
> >
> > > Yes, that's certainly wrong, but that's an implementation issue. I was
> > > more concerned about the design of the API.
> > >
> > >
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 00:02:47 -0700 (PDT)
> From: Miklos Szeredi <[EMAIL PROTECTED]>
> Date: Mon, 04 Jun 2007 11:45:32 +0200
>
> > > A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> > > send()+close() on the peer, causing recv() to return
On Tue, 05 Jun 2007 18:16:25 EDT, Jeff Garzik said:
> On Tue, Jun 05, 2007 at 11:03:45PM +0100, Russell King wrote:
> > And rather than configuring your MUA to ignore the header...
>
> > You're using mutt, mutt can be configured so.
>
> So, you are seriously proposing that EVERYONE reconfigure
sorry for not responding i was busy (i updated my sys to fc7)
on fc7-i386 and on fc-x86-64(2.6.22-rc4-cfq7 SMP PREEMPT x86_64
GNU/Linux) i can't see usb scanner
i test this with hp-6300 and aqfa snapscan-1212u
non of them triger creation /dev/scanner-x device
xsane cannot see this scanner
On Tue, 5 Jun 2007 23:20:57 +0200 (CEST)
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> stallion, don't fail with less than max panels
>
Why not?
What problem is this patch fixing, and how does it fix it?
What are the consequences of not having this patch in the kernel?
etc. More complete
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > Yes, that's certainly wrong, but that's an implementation issue. I was
> > more concerned about the design of the API.
> >
> > Naively, I would expect a reads on a signalfd to return either
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-05 at 15:50 -0700, Davide Libenzi wrote:
> > > What about the code in __dequeue_signal though ? That notifier thing
> > is
> > > used by the DRI though I'm not sure what would happen if it acts on
> > the
> > > wrong task.
> >
>
On Tue, 5 Jun 2007, Nicholas Miell wrote:
> Yes, that's certainly wrong, but that's an implementation issue. I was
> more concerned about the design of the API.
>
> Naively, I would expect a reads on a signalfd to return either process
> signals or thread signals targeted towards the thread
On Tue, 5 Jun 2007 16:58:57 -0400 (EDT)
"Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
> Replace a couple calls to __get_free_pages() with the corresponding
> calls to __get_dma_pages().
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> that's the lot of them.
>
> diff
On Tue, 2007-06-05 at 16:51 -0700, Nicholas Miell wrote:
> Yes, that's certainly wrong, but that's an implementation issue. I was
> more concerned about the design of the API.
>
> Naively, I would expect a reads on a signalfd to return either process
> signals or thread signals targeted towards
On Tue, 5 Jun 2007 16:50:55 -0400
Jeff Dike <[EMAIL PROTECTED]> wrote:
> [ This is 2.6.22 material ]
>
> Having KERNEL_STACK_ORDER in defconfig overrides the value provided by
> Kconfig, breaking UML/x86_64, which wants 2 page stacks.
>
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> --
>
Jesse Huang <[EMAIL PROTECTED]> writes:
Hi Jesse,
> - for (phy = 1; phy <= 32 && phy_idx < MII_CNT; phy++) {
> + if(sundance_pci_tbl[np->chip_id].device == 0x0200)
> + phy = 0;
> + else
> + phy = 1;
> + for (; phy <= 32 && phy_idx < MII_CNT; phy++) {
I
On Tue, 5 Jun 2007, David Rientjes wrote:
> If that fails, we can't allocate elsewhere because then we have taken
> exclusive memory from other applications and is contrary to the definition
> of mem_exclusive. You need to construct your cpuset hierarchy with these
> scenarios in mind; when
> If that fails, we can't allocate elsewhere because then we have taken
> exclusive memory from other applications and is contrary to the definition
> of mem_exclusive.
Well, I can't speak to the 'real' meaning of TIF_MEMDIE with authority,
but I can speak to the meaning of cpuset flags.
The
On Tue, Jun 05, 2007 at 02:14:51PM -0700, Siddha, Suresh B wrote:
> Can you send us your system's dmesg aswell as output of /proc/interrupts?
http://sweaglesw.net/~djwong/docs/dmesg
http://sweaglesw.net/~djwong/docs/interrupts
--D
signature.asc
Description: Digital signature
On Tue, 2007-06-05 at 17:27 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
> > signalfd() doesn't deliver thread-targeted signals to the wrong
> > threads,
> > does it?
> >
> > Hmm.
> >
> > It looks like reading from a signalfd will give you
On Tue, 5 Jun 2007, Christoph Lameter wrote:
> But with the patch the process would be able to terminate. There is no
> global OOM situation. If there would be a global OOM situation then
> TIF_MEMDIE would not help.
>
Sure it would, it would have access to memory reserves because of the
From: Chris Wright <[EMAIL PROTECTED]>
Date: Tue, 5 Jun 2007 16:36:16 -0700
> Rather than reverting that patch, applying this patch should fix
> your ipv6 issue:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=7ebba6d14f8d63cad583bf1cc0330b601d5a8171
>
On Tue, 05 Jun 2007 17:05:27 +0200
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> From: Ollie Wild <[EMAIL PROTECTED]>
>
> Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly
> from the old mm into the new mm.
>
> We create the new mm before the binfmt code runs, and place
On Tue, 05 Jun 2007 17:05:26 +0200
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Provide functions for moving page tables upwards.
>
> ...
>
> +extern unsigned long move_page_tables(struct vm_area_struct *vma,
> + unsigned long old_addr, struct vm_area_struct *new_vma,
> +
On Tue, 05 Jun 2007 17:05:25 +0200
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> The purpose of audit_bprm() is to log the argv array to a userspace daemon at
> the end of the execve system call. Since user-space hasn't had time to run,
> this array is still in pristine state on the process' stack;
Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 11:31:46PM +0200, Mikael Pettersson wrote:
I can easily reproduce the problem in 2.6.22-rc4. There are no
sata_promise changes between rc3 and rc4, but Tejun's libata
polling SETXFER change was included in rc4. Reverting it makes
sata_promise work
* Simon Arlott ([EMAIL PROTECTED]) wrote:
> Adding a ::/0 route doesn't work:
> # ip -6 r a ::/0 via fe80::230:18ff:feb0:25c2 dev eth0
> # ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530
> connect: Network is unreachable
>
> A route assigned by addrconf works.
>
> Reverting this patch from
On Tue, 5 Jun 2007, David Rientjes wrote:
> > But the alternative is that the exiting process does not save its
> > data.
> The same condition that occurs when there is a system-wide OOM, yes.
> Exclusive cpusets cannot be violated for such allocations outside of the
> obvious GFP_ATOMIC
On Tue, 5 Jun 2007, Christoph Lameter wrote:
> But the alternative is that the exiting process does not save its
> data.
>
The same condition that occurs when there is a system-wide OOM, yes.
Exclusive cpusets cannot be violated for such allocations outside of the
obvious GFP_ATOMIC
On Tuesday 05 June 2007 05:57:30 am Linus Walleij (LD/EAB) wrote:
> You don't need to alter the defaults for the Toshiba ALi, the
> preconfigure will respect the settings from the commandline,
> e.g. modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8.
>
> BUT this value just won't work: we don't
> The intended purpose of TIF_MEMDIE was to allocate pages without being
Ok then ... you probably right. I'll stand down.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
On Tue, 5 Jun 2007, David Rientjes wrote:
> No, it means that it can allocate anywhere based on the zonelist ordering
> and then can OOM a very small exclusive cpuset that would never have had
> any memory pressure if it wasn't violated.
But the alternative is that the exiting process does not
On Tue, 5 Jun 2007, Paul Jackson wrote:
> I'm a little surprised at this suggested change -- I'd have thought
> that it was a good idea to let tasks marked for extinction get memory
> anywhere, as they were going to use that memory to exit, and free up
> lots more memory.
>
The intended purpose
On 6/2/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
I think that Sam is working on this.
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git=search=f285e3d329ce68cc355fadf4ab2c8f34d7f264cb=commit=section+mismatch
I still got the section mismatch errors on 2.6.22-rc4.
From: Michal Piotrowski <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 16:54:28 +0200
> Networking
>
> Subject: OOPS iproute2/tc/u32_destroy in 2.6.22-rc3-git6
> References : http://lkml.org/lkml/2007/6/3/66
> Submitter : Strobl Anton <[EMAIL PROTECTED]>
> Handled-By : Patrick McHardy <[EMAIL
> OOM-killed tasks, marked as TIF_MEMDIE, should not be able to access
> memory outside its cpuset because it could potentially cause other
> exclusive cpusets to OOM themselves.
I'm a little surprised at this suggested change -- I'd have thought
that it was a good idea to let tasks marked for
Paul Mackerras wrote:
Chris Snook writes:
Clean up whitespace and comments in drivers/serial/icom.c
These changes seem totally unnecessary, as the existing indentation is
according to a commonly-accepted style and is quite reasonable:
There are actually a few different indentation styles
On Tue, 2007-06-05 at 15:50 -0700, Davide Libenzi wrote:
> > What about the code in __dequeue_signal though ? That notifier thing
> is
> > used by the DRI though I'm not sure what would happen if it acts on
> the
> > wrong task.
>
> Hmm, looking at the comments in block_all_signals(), it seems
Andy Whitcroft wrote:
>>>
>> It definitely sounds like a memory clobber of some sort.
>>
>> Usual suspects, in addition to the input/output buffers you already
>> looked at, would be the heap and the stack. Finding where the stack
>> pointer lives would be my first, instinctive guess.
>
> The
* Eric Paris ([EMAIL PROTECTED]) wrote:
> One result of using the dummy hook for non-selinux kernels means that I
> can't leave the generic module stacking code in the SELinux check. If
> the secondary ops are called they will always deny the operation just
> like in non-selinux systems even if
1 - 100 of 876 matches
Mail list logo
