On Thu, 25 Sep 2008 18:40:28 -0500 "Milton Miller" <[EMAIL PROTECTED]> wrote:
> (I trimmed the cc list for the implementation discussion).
Yep, good thing.
> >
> > Whoops, my bad, in the non threaded case, there's no
> > mask at all, only an unmask+eoi at the end, maybe that's
> > an over
(I trimmed the cc list for the implementation discussion).
> On Wed, 24 Sep 2008 11:42:15 -0500 Milton Miller
> <[EMAIL PROTECTED]> wrote:
>
> > On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote:
> > > Hi Milton,
> > > On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller
> > > <[EMAIL PROTE
On Wed, 24 Sep 2008 11:42:15 -0500 Milton Miller <[EMAIL PROTECTED]> wrote:
> On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote:
> > Hi Milton,
> > On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller
> > <[EMAIL PROTECTED]> wrote:
> >> On Mon Sep 15 at 18:04:06 EST in 2008, Sebastien Dugue
On Thu, 25 Sep 2008 18:36:19 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> > Do you mean creating a custom fasteoi handler into xics.c? Also, it's
> > not clear to me from looking at the code how you go about changing the
> > cpu priority.
>
> Yup. I think the priority is the CP
> Do you mean creating a custom fasteoi handler into xics.c? Also, it's
> not clear to me from looking at the code how you go about changing the
> cpu priority.
Yup. I think the priority is the CPPR.. Milton can give you more
details, if not, I'll pick it up tomorrow when at the office.
Ben.
On Thu, 25 Sep 2008 17:22:41 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-09-25 at 09:18 +0200, Sebastien Dugue wrote:
> >
> > > Ok, that's the right approach then. It should work. I don't know
> > what
> > > the specific problems with HEA are at this stage.
> >
> >
On Thu, 25 Sep 2008 07:14:07 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> > There may be some implicit assumption in that we expect the cpu
> > priority to be returned to normal by the EOI, but there is nothing in
> > the hardware that requires the EOI to come from the same cpu
On Thu, 2008-09-25 at 09:18 +0200, Sebastien Dugue wrote:
>
> > Ok, that's the right approach then. It should work. I don't know
> what
> > the specific problems with HEA are at this stage.
>
> Yep, except as it behaves in way that the current -rt fasteoi flow
> cannot handle.
We probably need
On Thu, 25 Sep 2008 07:15:17 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-09-24 at 14:35 +0200, Sebastien Dugue wrote:
> > Hi Ben,
> >
> > On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt <[EMAIL
> > PROTECTED]> wrote:
> >
> > > On Wed, 2008-09-24 at 04:58 -0
On Sep 24, 2008, at 4:16 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-09-24 at 11:42 -0500, Milton Miller wrote:
I was trying to understand why the mask and early eoi, but I guess its
to handle other more limited interrupt controllers where the
interrupts
stack in hardware instead of softwa
On Wed, 2008-09-24 at 11:42 -0500, Milton Miller wrote:
>
> I was trying to understand why the mask and early eoi, but I guess its
> to handle other more limited interrupt controllers where the interrupts
> stack in hardware instead of software.
No Milton, we must do it that way, because the EO
On Wed, 2008-09-24 at 14:35 +0200, Sebastien Dugue wrote:
> Hi Ben,
>
> On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> wrote:
>
> > On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
> > > The per-interrupt mask and unmask calls have to go through RTAS, a
>
> There may be some implicit assumption in that we expect the cpu
> priority to be returned to normal by the EOI, but there is nothing in
> the hardware that requires the EOI to come from the same cpu as
> accepted the interrupt for processing, with the exception of the IPI
> which is per-cpu
On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote:
Hi Milton,
On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller
<[EMAIL PROTECTED]> wrote:
On Mon Sep 15 at 18:04:06 EST in 2008, Sebastien Dugue wrote:
When entering the low level handler, level sensitive interrupts are
masked, then eio'
Hi Ben,
On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
> > The per-interrupt mask and unmask calls have to go through RTAS, a
> > single-threaded global context, which in addition to increasing
> >
Hi Milton,
On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller <[EMAIL PROTECTED]>
wrote:
> Jan-Bernd wrote:
> > Ben, can you / your team look into the implementation
> > of the set_irq_type functionality needed for XICS?
>
> I'm not volunteering to look at or implement any changes for ho
On Sep 24, 2008, at 5:17 AM, Benjamin Herrenschmidt wrote:
On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
The per-interrupt mask and unmask calls have to go through RTAS, a
single-threaded global context, which in addition to increasing
path length will really limit scalability. The in
On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
> The per-interrupt mask and unmask calls have to go through RTAS, a
> single-threaded global context, which in addition to increasing
> path length will really limit scalability. The interrupt controller
> poll and reject facilities are acce
Jan-Bernd wrote:
> Ben, can you / your team look into the implementation
> of the set_irq_type functionality needed for XICS?
I'm not volunteering to look at or implement any changes for how xics
works with generic irq, but I'm trying to understand what the rt kernel
is trying to accomplish with t
Hi,
I think these are the "functional" changes that need to be included in
the ibmebus driver. We'll add a RT flag in the final version to enable
these changes only for RT-Linux for now.
Ben, can you / your team look into the implementation
of the set_irq_type functionality needed for XICS?
Rega
On Thu, 18 Sep 2008 12:42:05 +0200 Christoph Raisch <[EMAIL PROTECTED]> wrote:
>
> Sebastien Dugue <[EMAIL PROTECTED]> wrote on 18.09.2008 11:27:13:
>
> >
> > It would be really interresting to know if the eHCA exhibits the same
> > problem under -rt as it's the only other user of the ibmebus.
Sebastien Dugue <[EMAIL PROTECTED]> wrote on 18.09.2008 11:27:13:
>
> It would be really interresting to know if the eHCA exhibits the same
> problem under -rt as it's the only other user of the ibmebus.
> Unfortunately I don't have the hardware to test.
>
eHCA is very close from the interrupt
On Thu, 18 Sep 2008 09:53:54 +0200 Christoph Raisch <[EMAIL PROTECTED]> wrote:
>
> Sebastien Dugue <[EMAIL PROTECTED]> wrote on 15.09.2008 10:04:06:
> > [PATCH HACK] powerpc: quick hack to get a functional eHEA with
> > hardirq preemption
> >
> > Sebasti
Sebastien Dugue <[EMAIL PROTECTED]> wrote on 15.09.2008 10:04:06:
> [PATCH HACK] powerpc: quick hack to get a functional eHEA with
> hardirq preemption
>
> Sebastien Dugue
>
> to:
>
> 15.09.2008 10:07
>
> Cc:
>
> linux-ppc, linux-kernel, Linux-rt, n
Hi Anton,
On Tue, 16 Sep 2008 15:59:47 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 15, 2008 at 03:13:32PM +0200, Sebastien Dugue wrote:
> [...]
> > > we are a bit worried about putting this into the mainstream part of non
> > > real
> > > time linux.
> >
> > Heck, I sure
On Mon, Sep 15, 2008 at 03:13:32PM +0200, Sebastien Dugue wrote:
[...]
> > we are a bit worried about putting this into the mainstream part of non real
> > time linux.
>
> Heck, I sure do not want this to be applied mainstream nor into any tree.
> The sole purpose of this patch was to trigger so
Hi Thomas, Jan-Bernd, Christoph,
On Mon, 15 Sep 2008 14:35:16 +0200 Thomas Klein <[EMAIL PROTECTED]> wrote:
> Hi,
>
> we are a bit worried about putting this into the mainstream part of non real
> time linux.
Heck, I sure do not want this to be applied mainstream nor into any tree.
The sol
Hi,
we are a bit worried about putting this into the mainstream part of non real
time linux. There interrupts work perfectly fine, and it was a bit of a
challenge to get there for all cases / configurations / machines.
Could you try to enable these changes only for RT-Linux via a real-time
kconf
Hi,
we are a bit worried about putting this into the mainstream part of non
real time linux.
There interrupts work perfectly fine, and it was a bit of a challenge to
get there for all
cases / configurations / machines.
Could you try to enable these changes only for RT-Linux via a real-time
kco
WARNING: HACK - HACK - HACK
Under the RT kernel (with hardirq preemption) the eHEA driver hangs right
after booting. Fiddling with the hardirqs and softirqs priorities allows to
run a bit longer but as soon as the network gets under load, the hang
returns. After investigating, it appears that t
30 matches
Mail list logo
