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
htt
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.
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
Good catch, thanks.
Cheers,
Ben.
> ---
> diff --git a/arch/powerpc/kernel/vector.S b/arch/power
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
---
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index ef36cbb..ea4d646 100644
--- a/arch/powerpc/kernel/vector.S
+++ b/arch/powerpc/ke
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,
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 hav
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
===
R
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 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 wrote:
>
> From: Ira W. Snyder
> Subject: [PATCH v2] edac: mpc85xx: add su
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);
* Ian Campbell 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.
>
> I'm not sure we can "i
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
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 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 :-)
Grant Likely wrote:
> On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandegger
> 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 system.
>
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//maps, I see that the process uses 140 MB without shared
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.3
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 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-
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
[c
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 us
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 trigger
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 specifi
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
---
arch/powerpc/include/asm/exception-64s.h
Grant Likely wrote:
> On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandegger
> 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 system.
>
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,
> > >>>
> > >>> I
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
>
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 c
28 matches
Mail list logo
