On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote:
On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote:
Hi,
Is there somebody else whom i should also address to get an attention
for this patch ? I apolozise if i have not included someone. Kindly
connect to the concerned.
On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote:
Hi,
Is there somebody else whom i should also address to get an attention
for this patch ? I apolozise if i have not included someone. Kindly
connect to the concerned.
I'm putting your patch to l2-mtd-2.6.git.
--
Best regards,
Artem
Subrata Modak wrote:
On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote:
On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote:
Hi,
Is there somebody else whom i should also address to get an attention
for this patch ? I apolozise if i have not included someone. Kindly
connect to the
On Fri, 2009-07-10 at 09:18 +0300, Artem Bityutskiy wrote:
Subrata Modak wrote:
On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote:
On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote:
Hi,
Is there somebody else whom i should also address to get an attention
for this patch ?
On Fri, 2009-07-10 at 12:42 +0530, Subrata Modak wrote:
On Fri, 2009-07-10 at 09:18 +0300, Artem Bityutskiy wrote:
Subrata Modak wrote:
On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote:
On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote:
Hi,
Is there somebody else
Grant Likely wrote:
On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandeggerw...@grandegger.com
wrote:
Hello,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the
The file include/asm/exception.h contains definitions
that are specific to exception handling on 64-bit server
type processors.
This renames the file to exception-64s.h to reflect that
fact and avoid confusion.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
The kernel uses SPRG registers for various purposes, typically in
low level assembly code as scratch registers or to hold per-cpu
global infos such as the PACA or the current thread_info pointer.
We want to be able to easily shuffle the usage of those registers
as some implementations have
Hello Wolfgang,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the system. The NAPI
That's great news. Do you happen to have a scenario which reliably triggers
Wolfram Sang wrote:
Hello Wolfgang,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the system. The NAPI
Just bombard the FEC with network packets. I use
Alan Cox wrote:
[c0003cf6ba70] [c040a3d0] .tty_ldisc_put+0xa4/0xf4 (unreliable)
[c0003cf6bb10] [c040a7c8] .tty_ldisc_reinit+0x38/0x80
[c0003cf6bba0] [c040b1d8] .tty_ldisc_hangup+0x190/0x260
[c0003cf6bc40] [c0401090] .do_tty_hangup+0x188/0x4c0
On Fri, 2009-07-10 at 10:14 +0300, Artem Bityutskiy wrote:
On Fri, 2009-07-10 at 12:42 +0530, Subrata Modak wrote:
On Fri, 2009-07-10 at 09:18 +0300, Artem Bityutskiy wrote:
Subrata Modak wrote:
On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote:
On Mon, 2009-07-06 at 07:47
On Fri, 2009-07-10 at 14:17 +0530, Subrata Modak wrote:
Is it possible to get this patch through and before 2.6.31 stable is
released ?
Hm, I was ignoring this until I was sure all the last-minute fixes for
2.6.31 were out of the way; I was planning to submit it for 2.6.32.
Do we really need
On Fri, 2009-07-10 at 09:53 +0100, David Woodhouse wrote:
On Fri, 2009-07-10 at 14:17 +0530, Subrata Modak wrote:
Is it possible to get this patch through and before 2.6.31 stable is
released ?
Hi David,
Hm, I was ignoring this until I was sure all the last-minute fixes for
2.6.31 were
Hello,
analysing the memory usage of a process, I found some questions.
I'am using a system with 128 MB physical RAM, no disk, 2.6.27 kernel.
Running top, I see 38 MB in use, 90 MB free, but a VSZ for my process of 158 MB.
Looking at /proc/pid/maps, I see that the process uses 140 MB without
Grant Likely wrote:
On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandeggerw...@grandegger.com
wrote:
Hello,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the
On Fri, 2009-07-10 at 15:55 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2009-06-01 at 16:32 +0100, Ian Campbell wrote:
This series:[...]
Looks like I was only CCed on part of them... it's not very handy for me
as I end up having some of the patches in one folder and some
elsewhere :-)
On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
I don't think that we need to take account of dom0 support; we don't
have a clear idea about an acceptable dom0 design (it needs to use
swiotlb code? I don't know yet), we don't even know we will have dom0
support in mainline. That's
On Fri, 2009-07-10 at 06:12 +0100, Ingo Molnar wrote:
Hm, the functions and facilities you remove here were added as part
of preparatory patches for Xen guest support. You were aware of
them, you were involved in discussions about those aspects with Ian
and Jeremy but still you chose not to
* Ian Campbell ian.campb...@eu.citrix.com wrote:
I've not examined the series in detail it looks OK but I don't
think it is quite sufficient. The Xen determination of whether a
buffer is dma_capable or not is based on the physical address
while dma_capable takes only the dma address.
On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:
On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797
wrote:
I understand your arguments, but there is something inconsistent
about this.
If I change the script to be:
_end3 = . ;
. = _end3;
. = ALIGN(PAGE_SIZE);
On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
Ok, is this the one you want me to push upstream?
Yep, this is the finished version.
Thanks,
Ira
doug t
--- On Thu, 7/9/09, Ira W. Snyder i...@ovro.caltech.edu wrote:
From: Ira W. Snyder i...@ovro.caltech.edu
Subject:
On Jul 10, 2009, at 9:37 AM, Kumar Gala wrote:
On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:
On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797
wrote:
I understand your arguments, but there is something inconsistent
about this.
If I change the script to be:
_end3 =
On Jul 9, 2009, at 11:11 PM, Alan Modra wrote:
Hmm, having said all that, the following linker patch seems reasonable
to me and probably won't break anything else (always some risk).
Please test it for me.
Index: ld/ldlang.c
===
On Jul 10, 2009, at 10:04 AM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
Ok, is this the one you want me to push upstream?
Yep, this is the finished version.
Thanks,
Ira
doug t
is that for .31 or .32? If .31 I'm fine. If for .32 I still
On Fri, Jul 10, 2009 at 10:36:20AM -0500, Kumar Gala wrote:
On Jul 10, 2009, at 10:04 AM, Ira W. Snyder wrote:
On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
Ok, is this the one you want me to push upstream?
Yep, this is the finished version.
Thanks,
Ira
doug t
is
When moving load_up_altivec to vector.S a typo in a comment caused a
thinko setting the wrong variable.
Signed-off-by: Andreas Schwab sch...@linux-m68k.org
---
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index ef36cbb..ea4d646 100644
--- a/arch/powerpc/kernel/vector.S
On Fri, 2009-07-10 at 23:17 +0200, Andreas Schwab wrote:
When moving load_up_altivec to vector.S a typo in a comment caused a
thinko setting the wrong variable.
Signed-off-by: Andreas Schwab sch...@linux-m68k.org
Good catch, thanks.
Cheers,
Ben.
---
diff --git
On Fri, Jul 10, 2009 at 10:27:26AM -0500, Kumar Gala wrote:
binutils-2.19 _end is what we expect
binutils-2.19.1 _end is what we expect
binutils-2.19.50.0.1 _end is what we expect
binutils-2.19.51.0.1 _end is 1000
From the release notes:
binutils-2.19.50.0.1 is
On Sat, Jul 11, 2009 at 09:35:03AM +0930, Alan Modra wrote:
Did you try the patch I posted?
/me reads other email. I see you did. Applying.
--
Alan Modra
Australia Development Lab, IBM
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
30 matches
Mail list logo
