[{"id":670,"web_url":"http://patchwork.ozlabs.org/comment/670/","msgid":"","date":"2008-09-15T12:17:10","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","submitter":{"id":142,"url":"http://patchwork.ozlabs.org/api/people/142/","name":"Jan-Bernd Themann","email":"THEMANN@de.ibm.com"},"content":"Hi,\n\nwe are a bit worried about putting this into the mainstream part of non \nreal time linux.\nThere interrupts work perfectly fine, and it was a bit of a challenge to \nget there for all\ncases / configurations / machines.\n\nCould you try to enable these changes only for RT-Linux via a real-time \nkconfig switch?\nThis way we make sure we don't break the scheme for eHEA / eHCA. \n\nRegards,\nJan-Bernd & Christoph\n\nSebastien Dugue wrote on 15.09.2008 10:04:06:\n\n> \n> WARNING: HACK - HACK - HACK\n> \n> Under the RT kernel (with hardirq preemption) the eHEA driver hangs \nright\n> after booting. Fiddling with the hardirqs and softirqs priorities allows \nto\n> run a bit longer but as soon as the network gets under load, the hang\n> returns. After investigating, it appears that the driver is loosing \n> interrupts.\n> \n> To make a long story short, looking at the code, it appears that the \nXICS\n> maps all its interrupts to level sensitive interrupts (I don't know \n> if it's the\n> reality or if it's due to an incomplete implementation - no datasheets\n> available to check) and use the fasteoi processing flow.\n> \n> When entering the low level handler, level sensitive interrupts are \nmasked,\n> then eio'd in interrupt context and then unmasked at the end of hardirq\n> processing.\n> That's fine as any interrupt comming in-between will still be processed \nsince\n> the kernel replays those pending interrupts.\n> \n> However, it appears that the eHEA interrupts are behaving as edge \nsensitive\n> interrupts and are routed through the XICS which process those as level\n> sensitive using the fasteoi handler __OR__ the XICS loses interruptswhen \nthey\n> are masked.\n> \n> Therefore the masking done in the handler causes any interrupt \n> happening while\n> in the handler to be lost.\n> \n> So this patch maps the interrupts being requested through\n> ibmebus_request_irq() as edge sensitive interrupts (this concerns \n> both the eHEA\n> and the eHCA - only users of ibmebus_request_irq()) and changes the way \nedge\n> interrupts are processed by the fasteoi handler.\n> \n> It works for the eHEA, dunno for the eHCA.\n> \n> So, unless all the designers of the XICS & eHEA have been shot to keep \nit\n> a secret, could someone knowledgeable shed some light on this issue.\n> \n> Thanks,\n> \n> Sebastien.\n> \n> Not-Signed-off-by: Sebastien Dugue \n> ---\n> arch/powerpc/kernel/ibmebus.c | 11 ++++++++++-\n> kernel/irq/chip.c | 5 +++--\n> kernel/irq/manage.c | 9 ++++++---\n> 3 files changed, 19 insertions(+), 6 deletions(-)\n> \n> diff --git a/arch/powerpc/kernel/ibmebus.c \nb/arch/powerpc/kernel/ibmebus.c\n> index 9971159..5200323 100644\n> --- a/arch/powerpc/kernel/ibmebus.c\n> +++ b/arch/powerpc/kernel/ibmebus.c\n> @@ -41,6 +41,7 @@\n> #include \n> #include \n> #include \n> +#include \n> #include \n> #include \n> #include \n> @@ -213,11 +214,19 @@ int ibmebus_request_irq(u32 ist, irq_handler_t \nhandler,\n> void *dev_id)\n> {\n> unsigned int irq = irq_create_mapping(NULL, ist);\n> + struct irq_desc *desc;\n> + int ret;\n> \n> if (irq == NO_IRQ)\n> return -EINVAL;\n> \n> - return request_irq(irq, handler, irq_flags, devname, dev_id);\n> + ret = request_irq(irq, handler, irq_flags, devname, dev_id);\n> +\n> + desc = irq_desc + irq;\n> + desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);\n> + desc->status |= IRQ_TYPE_EDGE_RISING;\n> +\n> + return ret;\n> }\n> EXPORT_SYMBOL(ibmebus_request_irq);\n> \n> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c\n> index b7b397a..6d366ca 100644\n> --- a/kernel/irq/chip.c\n> +++ b/kernel/irq/chip.c\n> @@ -430,7 +430,7 @@ handle_fasteoi_irq(unsigned int irq, struct \n> irq_desc *desc)\n> action = desc->action;\n> if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |\n> IRQ_DISABLED)))) {\n> - desc->status |= IRQ_PENDING;\n> + desc->status |= IRQ_PENDING | IRQ_MASKED;\n> if (desc->chip->mask)\n> desc->chip->mask(irq);\n> goto out;\n> @@ -439,9 +439,10 @@ handle_fasteoi_irq(unsigned int irq, struct \n> irq_desc *desc)\n> desc->status |= IRQ_INPROGRESS;\n> /*\n> * In the threaded case we fall back to a mask+eoi sequence:\n> + * excepted for edge interrupts which are not masked.\n> */\n> if (redirect_hardirq(desc)) {\n> - if (desc->chip->mask)\n> + if (desc->chip->mask && !(desc->status & IRQ_TYPE_EDGE_BOTH))\n> desc->chip->mask(irq);\n> goto out;\n> }\n> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c\n> index 3bffa20..3e39c71 100644\n> --- a/kernel/irq/manage.c\n> +++ b/kernel/irq/manage.c\n> @@ -788,9 +788,12 @@ static void do_hardirq(struct irq_desc *desc)\n> thread_simple_irq(desc);\n> else if (desc->handle_irq == handle_level_irq)\n> thread_level_irq(desc);\n> - else if (desc->handle_irq == handle_fasteoi_irq)\n> - thread_fasteoi_irq(desc);\n> - else if (desc->handle_irq == handle_edge_irq)\n> + else if (desc->handle_irq == handle_fasteoi_irq) {\n> + if (desc->status & IRQ_TYPE_EDGE_BOTH)\n> + thread_edge_irq(desc);\n> + else\n> + thread_fasteoi_irq(desc);\n> + } else if (desc->handle_irq == handle_edge_irq)\n> thread_edge_irq(desc);\n> else\n> thread_do_irq(desc);\n> -- \n> 1.6.0.1.308.gede4c\n>","headers":{"Return-Path":"","X-Original-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Delivered-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from ozlabs.org (localhost [127.0.0.1])\n\tby ozlabs.org (Postfix) with ESMTP id AC4E147571\n\tfor ; Mon, 15 Sep 2008 22:18:06 +1000 (EST)","from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161])\n\t(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\n\t(Client CN \"mtagate1.de.ibm.com\", Issuer \"Equifax\" (verified OK))\n\tby ozlabs.org (Postfix) with ESMTPS id 04510DEA75\n\tfor ; Mon, 15 Sep 2008 22:17:37 +1000 (EST)","from d12nrmr1607.megacenter.de.ibm.com\n\t(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])\n\tby mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id m8FCHG7T029164\n\tfor ; Mon, 15 Sep 2008 12:17:17 GMT","from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com\n\t[9.149.165.229])\n\tby d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with\n\tESMTP id m8FCHGVC2986178\n\tfor ; Mon, 15 Sep 2008 14:17:16 +0200","from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1])\n\tby d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP\n\tid m8FCHCQL021856\n\tfor ; Mon, 15 Sep 2008 14:17:13 +0200","from d12ml064.megacenter.de.ibm.com (d12ml064.megacenter.de.ibm.com\n\t[9.149.167.10])\n\tby d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with\n\tESMTP id m8FCHCb1021843; Mon, 15 Sep 2008 14:17:12 +0200"],"In-Reply-To":"<20080915100406.342e027a@bull.net>","To":"Sebastien Dugue ","MIME-Version":["1.0","1.0"],"Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","X-Mailer":"Lotus Notes Release 7.0 HF400 February 20, 2008","Message-ID":"","From":"Jan-Bernd Themann ","Date":"Mon, 15 Sep 2008 14:17:10 +0200","X-MIMETrack":"Serialize by Router on D12ML064/12/M/IBM(Release 8.0.1|February\n\t07, 2008) at 15/09/2008 14:17:11,\n\tSerialize complete at 15/09/2008 14:17:11","Cc":"Thomas Q Klein , tinytim@us.ibm.com,\n\tLinux-rt ,\n\tnetdev@vger.kernel.org, jean-pierre.dion@bull.net,\n\tlinux-kernel ,\n\tlinux-ppc ,\n\tChristoph Raisch , gilles.carry@ext.bull.net","X-BeenThere":"linuxppc-dev@ozlabs.org","X-Mailman-Version":"2.1.11","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"multipart/mixed; boundary=\"===============0962665994==\"","Mime-version":["1.0","1.0"],"Sender":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org"}},{"id":671,"web_url":"http://patchwork.ozlabs.org/comment/671/","msgid":"<48CE5684.4000506@de.ibm.com>","date":"2008-09-15T12:35:16","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","submitter":{"id":143,"url":"http://patchwork.ozlabs.org/api/people/143/","name":"Thomas Klein","email":"osstklei@de.ibm.com"},"content":"Hi,\n\nwe are a bit worried about putting this into the mainstream part of non real\ntime linux. There interrupts work perfectly fine, and it was a bit of a\nchallenge to get there for all cases / configurations / machines.\n\nCould you try to enable these changes only for RT-Linux via a real-time\nkconfig switch? This way we make sure we don't break the scheme for\neHEA / eHCA.\n\nRegards,\nJan-Bernd, Christoph\n\n\nSebastien Dugue wrote:\n> WARNING: HACK - HACK - HACK\n> \n> Under the RT kernel (with hardirq preemption) the eHEA driver hangs right\n> after booting. Fiddling with the hardirqs and softirqs priorities allows to\n> run a bit longer but as soon as the network gets under load, the hang\n> returns. After investigating, it appears that the driver is loosing interrupts.\n> \n> To make a long story short, looking at the code, it appears that the XICS\n> maps all its interrupts to level sensitive interrupts (I don't know if it's the\n> reality or if it's due to an incomplete implementation - no datasheets\n> available to check) and use the fasteoi processing flow.\n> \n> When entering the low level handler, level sensitive interrupts are masked,\n> then eio'd in interrupt context and then unmasked at the end of hardirq\n> processing.\n> That's fine as any interrupt comming in-between will still be processed since\n> the kernel replays those pending interrupts.\n> \n> However, it appears that the eHEA interrupts are behaving as edge sensitive\n> interrupts and are routed through the XICS which process those as level\n> sensitive using the fasteoi handler __OR__ the XICS loses interrupts when they\n> are masked.\n> \n> Therefore the masking done in the handler causes any interrupt happening while\n> in the handler to be lost.\n> \n> So this patch maps the interrupts being requested through\n> ibmebus_request_irq() as edge sensitive interrupts (this concerns both the eHEA\n> and the eHCA - only users of ibmebus_request_irq()) and changes the way edge\n> interrupts are processed by the fasteoi handler.\n> \n> It works for the eHEA, dunno for the eHCA.\n> \n> So, unless all the designers of the XICS & eHEA have been shot to keep it\n> a secret, could someone knowledgeable shed some light on this issue.\n> \n> Thanks,\n> \n> Sebastien.\n> \n> Not-Signed-off-by: Sebastien Dugue \n> ---\n> arch/powerpc/kernel/ibmebus.c | 11 ++++++++++-\n> kernel/irq/chip.c | 5 +++--\n> kernel/irq/manage.c | 9 ++++++---\n> 3 files changed, 19 insertions(+), 6 deletions(-)\n> \n> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c\n> index 9971159..5200323 100644\n> --- a/arch/powerpc/kernel/ibmebus.c\n> +++ b/arch/powerpc/kernel/ibmebus.c\n> @@ -41,6 +41,7 @@\n> #include \n> #include \n> #include \n> +#include \n> #include \n> #include \n> #include \n> @@ -213,11 +214,19 @@ int ibmebus_request_irq(u32 ist, irq_handler_t handler,\n> \t\t\tvoid *dev_id)\n> {\n> \tunsigned int irq = irq_create_mapping(NULL, ist);\n> +\tstruct irq_desc *desc;\n> +\tint ret;\n> \n> \tif (irq == NO_IRQ)\n> \t\treturn -EINVAL;\n> \n> -\treturn request_irq(irq, handler, irq_flags, devname, dev_id);\n> +\tret = request_irq(irq, handler, irq_flags, devname, dev_id);\n> +\n> +\tdesc = irq_desc + irq;\n> +\tdesc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);\n> +\tdesc->status |= IRQ_TYPE_EDGE_RISING;\n> +\n> +\treturn ret;\n> }\n> EXPORT_SYMBOL(ibmebus_request_irq);\n> \n> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c\n> index b7b397a..6d366ca 100644\n> --- a/kernel/irq/chip.c\n> +++ b/kernel/irq/chip.c\n> @@ -430,7 +430,7 @@ handle_fasteoi_irq(unsigned int irq, struct irq_desc *desc)\n> \taction = desc->action;\n> \tif (unlikely(!action || (desc->status & (IRQ_INPROGRESS |\n> \t\t\t\t\t\t IRQ_DISABLED)))) {\n> -\t\tdesc->status |= IRQ_PENDING;\n> +\t\tdesc->status |= IRQ_PENDING | IRQ_MASKED;\n> \t\tif (desc->chip->mask)\n> \t\t\tdesc->chip->mask(irq);\n> \t\tgoto out;\n> @@ -439,9 +439,10 @@ handle_fasteoi_irq(unsigned int irq, struct irq_desc *desc)\n> \tdesc->status |= IRQ_INPROGRESS;\n> \t/*\n> \t * In the threaded case we fall back to a mask+eoi sequence:\n> +\t * excepted for edge interrupts which are not masked.\n> \t */\n> \tif (redirect_hardirq(desc)) {\n> -\t\tif (desc->chip->mask)\n> +\t\tif (desc->chip->mask && !(desc->status & IRQ_TYPE_EDGE_BOTH))\n> \t\t\tdesc->chip->mask(irq);\n> \t\tgoto out;\n> \t}\n> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c\n> index 3bffa20..3e39c71 100644\n> --- a/kernel/irq/manage.c\n> +++ b/kernel/irq/manage.c\n> @@ -788,9 +788,12 @@ static void do_hardirq(struct irq_desc *desc)\n> \t\tthread_simple_irq(desc);\n> \telse if (desc->handle_irq == handle_level_irq)\n> \t\tthread_level_irq(desc);\n> -\telse if (desc->handle_irq == handle_fasteoi_irq)\n> -\t\tthread_fasteoi_irq(desc);\n> -\telse if (desc->handle_irq == handle_edge_irq)\n> +\telse if (desc->handle_irq == handle_fasteoi_irq) {\n> +\t\tif (desc->status & IRQ_TYPE_EDGE_BOTH)\n> +\t\t\tthread_edge_irq(desc);\n> +\t\telse\n> +\t\t\tthread_fasteoi_irq(desc);\n> +\t} else if (desc->handle_irq == handle_edge_irq)\n> \t\tthread_edge_irq(desc);\n> \telse\n> \t\tthread_do_irq(desc);","headers":{"Return-Path":"","X-Original-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Delivered-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from ozlabs.org (localhost [127.0.0.1])\n\tby ozlabs.org (Postfix) with ESMTP id 37D68DED80\n\tfor ; Mon, 15 Sep 2008 22:36:05 +1000 (EST)","from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152])\n\t(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\n\t(Client CN \"mtagate3.de.ibm.com\", Issuer \"Equifax\" (verified OK))\n\tby ozlabs.org (Postfix) with ESMTPS id 92F84DE654\n\tfor ; Mon, 15 Sep 2008 22:35:40 +1000 (EST)","from d12nrmr1607.megacenter.de.ibm.com\n\t(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])\n\tby mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m8FCZXSg165220\n\tfor ; Mon, 15 Sep 2008 12:35:33 GMT","from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com\n\t[9.149.165.228])\n\tby d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with\n\tESMTP id m8FCZXkl2158666\n\tfor ; Mon, 15 Sep 2008 14:35:33 +0200","from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])\n\tby d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP\n\tid m8FCZTtc000490\n\tfor ; Mon, 15 Sep 2008 14:35:29 +0200","from [9.152.217.54] (dyn-9-152-217-54.boeblingen.de.ibm.com\n\t[9.152.217.54])\n\tby d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with\n\tESMTP id m8FCZTih032609; Mon, 15 Sep 2008 14:35:29 +0200"],"Message-ID":"<48CE5684.4000506@de.ibm.com>","Date":"Mon, 15 Sep 2008 14:35:16 +0200","From":"Thomas Klein ","User-Agent":"Thunderbird 2.0.0.14 (X11/20080421)","MIME-Version":"1.0","To":"Sebastien Dugue ","Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","References":"<20080915100406.342e027a@bull.net>","In-Reply-To":"<20080915100406.342e027a@bull.net>","Cc":"tklein@de.ibm.com, tinytim@us.ibm.com,\n\tLinux-rt , themann@de.ibm.com,\n\tnetdev@vger.kernel.org, linux-kernel , \n\tjean-pierre.dion@bull.net, linux-ppc ,\n\traisch@de.ibm.com, gilles.carry@ext.bull.net","X-BeenThere":"linuxppc-dev@ozlabs.org","X-Mailman-Version":"2.1.11","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Sender":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org"}},{"id":673,"web_url":"http://patchwork.ozlabs.org/comment/673/","msgid":"<20080915151332.6a3a7c80@bull.net>","date":"2008-09-15T13:13:32","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","submitter":{"id":101,"url":"http://patchwork.ozlabs.org/api/people/101/","name":"Sebastien Dugue","email":"sebastien.dugue@bull.net"},"content":"Hi Thomas, Jan-Bernd, Christoph,\n\nOn Mon, 15 Sep 2008 14:35:16 +0200 Thomas Klein wrote:\n\n> Hi,\n> \n> we are a bit worried about putting this into the mainstream part of non real\n> time linux.\n\n Heck, I sure do not want this to be applied mainstream nor into any tree.\nThe sole purpose of this patch was to trigger some reaction from the people who\nknow the hardware and try to understand where the problem lies.\n\n> There interrupts work perfectly fine, and it was a bit of a\n> challenge to get there for all cases / configurations / machines.\n\n Agreed, but the fact that it fails with hardirq preemption leads me to\nbelieve (without any more knowledge about the harware) that there might be\nsomething amiss with this driver (or the code concerning the XICS)\nnevertheless.\n\n> \n> Could you try to enable these changes only for RT-Linux via a real-time\n> kconfig switch?\n\n Nope, this is just a quick hack that allows me to have a functional eHEA under\nthe rt kernel. I want to understand what the problem is:\n\n - Is the eHEA really delivering level interrupts to the XICS?\n\n - Is the XICS loosing interrupts when they are masked?\n\n - ...?\n\n> This way we make sure we don't break the scheme for\n> eHEA / eHCA.\n\n Sure, I do not want to break anything, quite the opposite in fact ;-)\n\n\n Thanks,\n\n Sebastien.\n\n> \n> Regards,\n> Jan-Bernd, Christoph\n> \n> \n> Sebastien Dugue wrote:\n> > WARNING: HACK - HACK - HACK\n> > \n> > Under the RT kernel (with hardirq preemption) the eHEA driver hangs right\n> > after booting. Fiddling with the hardirqs and softirqs priorities allows to\n> > run a bit longer but as soon as the network gets under load, the hang\n> > returns. After investigating, it appears that the driver is loosing interrupts.\n> > \n> > To make a long story short, looking at the code, it appears that the XICS\n> > maps all its interrupts to level sensitive interrupts (I don't know if it's the\n> > reality or if it's due to an incomplete implementation - no datasheets\n> > available to check) and use the fasteoi processing flow.\n> > \n> > When entering the low level handler, level sensitive interrupts are masked,\n> > then eio'd in interrupt context and then unmasked at the end of hardirq\n> > processing.\n> > That's fine as any interrupt comming in-between will still be processed since\n> > the kernel replays those pending interrupts.\n> > \n> > However, it appears that the eHEA interrupts are behaving as edge sensitive\n> > interrupts and are routed through the XICS which process those as level\n> > sensitive using the fasteoi handler __OR__ the XICS loses interrupts when they\n> > are masked.\n> > \n> > Therefore the masking done in the handler causes any interrupt happening while\n> > in the handler to be lost.\n> > \n> > So this patch maps the interrupts being requested through\n> > ibmebus_request_irq() as edge sensitive interrupts (this concerns both the eHEA\n> > and the eHCA - only users of ibmebus_request_irq()) and changes the way edge\n> > interrupts are processed by the fasteoi handler.\n> > \n> > It works for the eHEA, dunno for the eHCA.\n> > \n> > So, unless all the designers of the XICS & eHEA have been shot to keep it\n> > a secret, could someone knowledgeable shed some light on this issue.\n> > \n> > Thanks,\n> > \n> > Sebastien.\n> > \n> > Not-Signed-off-by: Sebastien Dugue \n> > ---\n> > arch/powerpc/kernel/ibmebus.c | 11 ++++++++++-\n> > kernel/irq/chip.c | 5 +++--\n> > kernel/irq/manage.c | 9 ++++++---\n> > 3 files changed, 19 insertions(+), 6 deletions(-)\n> > \n> > diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c\n> > index 9971159..5200323 100644\n> > --- a/arch/powerpc/kernel/ibmebus.c\n> > +++ b/arch/powerpc/kernel/ibmebus.c\n> > @@ -41,6 +41,7 @@\n> > #include \n> > #include \n> > #include \n> > +#include \n> > #include \n> > #include \n> > #include \n> > @@ -213,11 +214,19 @@ int ibmebus_request_irq(u32 ist, irq_handler_t handler,\n> > \t\t\tvoid *dev_id)\n> > {\n> > \tunsigned int irq = irq_create_mapping(NULL, ist);\n> > +\tstruct irq_desc *desc;\n> > +\tint ret;\n> > \n> > \tif (irq == NO_IRQ)\n> > \t\treturn -EINVAL;\n> > \n> > -\treturn request_irq(irq, handler, irq_flags, devname, dev_id);\n> > +\tret = request_irq(irq, handler, irq_flags, devname, dev_id);\n> > +\n> > +\tdesc = irq_desc + irq;\n> > +\tdesc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);\n> > +\tdesc->status |= IRQ_TYPE_EDGE_RISING;\n> > +\n> > +\treturn ret;\n> > }\n> > EXPORT_SYMBOL(ibmebus_request_irq);\n> > \n> > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c\n> > index b7b397a..6d366ca 100644\n> > --- a/kernel/irq/chip.c\n> > +++ b/kernel/irq/chip.c\n> > @@ -430,7 +430,7 @@ handle_fasteoi_irq(unsigned int irq, struct irq_desc *desc)\n> > \taction = desc->action;\n> > \tif (unlikely(!action || (desc->status & (IRQ_INPROGRESS |\n> > \t\t\t\t\t\t IRQ_DISABLED)))) {\n> > -\t\tdesc->status |= IRQ_PENDING;\n> > +\t\tdesc->status |= IRQ_PENDING | IRQ_MASKED;\n> > \t\tif (desc->chip->mask)\n> > \t\t\tdesc->chip->mask(irq);\n> > \t\tgoto out;\n> > @@ -439,9 +439,10 @@ handle_fasteoi_irq(unsigned int irq, struct irq_desc *desc)\n> > \tdesc->status |= IRQ_INPROGRESS;\n> > \t/*\n> > \t * In the threaded case we fall back to a mask+eoi sequence:\n> > +\t * excepted for edge interrupts which are not masked.\n> > \t */\n> > \tif (redirect_hardirq(desc)) {\n> > -\t\tif (desc->chip->mask)\n> > +\t\tif (desc->chip->mask && !(desc->status & IRQ_TYPE_EDGE_BOTH))\n> > \t\t\tdesc->chip->mask(irq);\n> > \t\tgoto out;\n> > \t}\n> > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c\n> > index 3bffa20..3e39c71 100644\n> > --- a/kernel/irq/manage.c\n> > +++ b/kernel/irq/manage.c\n> > @@ -788,9 +788,12 @@ static void do_hardirq(struct irq_desc *desc)\n> > \t\tthread_simple_irq(desc);\n> > \telse if (desc->handle_irq == handle_level_irq)\n> > \t\tthread_level_irq(desc);\n> > -\telse if (desc->handle_irq == handle_fasteoi_irq)\n> > -\t\tthread_fasteoi_irq(desc);\n> > -\telse if (desc->handle_irq == handle_edge_irq)\n> > +\telse if (desc->handle_irq == handle_fasteoi_irq) {\n> > +\t\tif (desc->status & IRQ_TYPE_EDGE_BOTH)\n> > +\t\t\tthread_edge_irq(desc);\n> > +\t\telse\n> > +\t\t\tthread_fasteoi_irq(desc);\n> > +\t} else if (desc->handle_irq == handle_edge_irq)\n> > \t\tthread_edge_irq(desc);\n> > \telse\n> > \t\tthread_do_irq(desc);\n> \n>","headers":{"Return-Path":"","X-Original-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Delivered-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from ozlabs.org (localhost [127.0.0.1])\n\tby ozlabs.org (Postfix) with ESMTP id 461C6DEFF8\n\tfor ; Mon, 15 Sep 2008 23:14:13 +1000 (EST)","from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8])\n\tby ozlabs.org (Postfix) with ESMTP id 85FB9DEE79\n\tfor ; Mon, 15 Sep 2008 23:13:45 +1000 (EST)","from localhost (localhost [127.0.0.1])\n\tby ecfrec.frec.bull.fr (Postfix) with ESMTP\n\tid 9B60E1A1D11; Mon, 15 Sep 2008 15:13:37 +0200 (CEST)","from ecfrec.frec.bull.fr ([127.0.0.1])\n\tby localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id 17746-01; Mon, 15 Sep 2008 15:13:33 +0200 (CEST)","from cyclope.frec.bull.fr (cyclope.frec.bull.fr [129.183.4.9])\n\tby ecfrec.frec.bull.fr (Postfix) with ESMTP\n\tid 1E16B1A1D12; Mon, 15 Sep 2008 15:13:33 +0200 (CEST)","from localhost (frecb000686.frec.bull.fr [129.183.101.139])\n\tby cyclope.frec.bull.fr (Postfix) with ESMTP id 94DA02728D;\n\tMon, 15 Sep 2008 15:13:30 +0200 (CEST)"],"Date":"Mon, 15 Sep 2008 15:13:32 +0200","From":"Sebastien Dugue ","To":"Thomas Klein ","Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","Message-ID":"<20080915151332.6a3a7c80@bull.net>","In-Reply-To":"<48CE5684.4000506@de.ibm.com>","References":"<20080915100406.342e027a@bull.net> <48CE5684.4000506@de.ibm.com>","X-Mailer":"Claws Mail 3.2.0 (GTK+ 2.12.2; i486-pc-linux-gnu)","Mime-Version":"1.0","X-Virus-Scanned":"by amavisd-new at frec.bull.fr","Cc":"tklein@de.ibm.com, tinytim@us.ibm.com,\n\tLinux-rt , themann@de.ibm.com,\n\tnetdev@vger.kernel.org, linux-kernel , \n\tjean-pierre.dion@bull.net, linux-ppc ,\n\traisch@de.ibm.com, gilles.carry@ext.bull.net","X-BeenThere":"linuxppc-dev@ozlabs.org","X-Mailman-Version":"2.1.11","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org"}},{"id":733,"web_url":"http://patchwork.ozlabs.org/comment/733/","msgid":"<20080916115947.GA6995@oksana.dev.rtsoft.ru>","date":"2008-09-16T11:59:47","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","submitter":{"id":45,"url":"http://patchwork.ozlabs.org/api/people/45/","name":"Anton Vorontsov","email":"avorontsov@ru.mvista.com"},"content":"On Mon, Sep 15, 2008 at 03:13:32PM +0200, Sebastien Dugue wrote:\n[...]\n> > we are a bit worried about putting this into the mainstream part of non real\n> > time linux.\n> \n> Heck, I sure do not want this to be applied mainstream nor into any tree.\n> The sole purpose of this patch was to trigger some reaction from the people who\n> know the hardware and try to understand where the problem lies.\n> \n> > There interrupts work perfectly fine, and it was a bit of a\n> > challenge to get there for all cases / configurations / machines.\n> \n> Agreed, but the fact that it fails with hardirq preemption leads me to\n> believe (without any more knowledge about the harware) that there might be\n> something amiss with this driver (or the code concerning the XICS)\n> nevertheless.\n> \n> > \n> > Could you try to enable these changes only for RT-Linux via a real-time\n> > kconfig switch?\n> \n> Nope, this is just a quick hack that allows me to have a functional eHEA under\n> the rt kernel. I want to understand what the problem is:\n> \n> - Is the eHEA really delivering level interrupts to the XICS?\n> \n> - Is the XICS loosing interrupts when they are masked?\n\nThere is a known bug in the -rt kernels, the bug causes handlers\nto lose edge interrupts.\n\nSee this patch:\n\nhttp://lkml.org/lkml/2008/6/30/372\n\n> - ...?","headers":{"Return-Path":"","X-Original-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Delivered-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from ozlabs.org (localhost [127.0.0.1])\n\tby ozlabs.org (Postfix) with ESMTP id 819B2DE1B7\n\tfor ; Tue, 16 Sep 2008 22:00:34 +1000 (EST)","from buildserver.ru.mvista.com (unknown [85.21.88.6])\n\tby ozlabs.org (Postfix) with ESMTP id D5B60DDE22\n\tfor ; Tue, 16 Sep 2008 21:59:49 +1000 (EST)","from localhost (unknown [10.150.0.9])\n\tby buildserver.ru.mvista.com (Postfix) with ESMTP\n\tid 0F88A8815; Tue, 16 Sep 2008 16:59:47 +0500 (SAMST)"],"Date":"Tue, 16 Sep 2008 15:59:47 +0400","From":"Anton Vorontsov ","To":"Sebastien Dugue ","Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","Message-ID":"<20080916115947.GA6995@oksana.dev.rtsoft.ru>","References":"<20080915100406.342e027a@bull.net> <48CE5684.4000506@de.ibm.com>\n\t<20080915151332.6a3a7c80@bull.net>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20080915151332.6a3a7c80@bull.net>","User-Agent":"Mutt/1.5.18 (2008-05-17)","Cc":"tklein@de.ibm.com, tinytim@us.ibm.com,\n\tLinux-rt ,\n\tjean-pierre.dion@bull.net, themann@de.ibm.com, netdev@vger.kernel.org,\n\tlinux-kernel ,\n\tThomas Klein ,\n\tlinux-ppc , raisch@de.ibm.com,\n\tgilles.carry@ext.bull.net","X-BeenThere":"linuxppc-dev@ozlabs.org","X-Mailman-Version":"2.1.11","Precedence":"list","Reply-To":"avorontsov@ru.mvista.com","List-Id":"Linux on PowerPC Developers Mail List ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org"}},{"id":741,"web_url":"http://patchwork.ozlabs.org/comment/741/","msgid":"<20080916142237.0dc5d024@bull.net>","date":"2008-09-16T12:22:37","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","submitter":{"id":101,"url":"http://patchwork.ozlabs.org/api/people/101/","name":"Sebastien Dugue","email":"sebastien.dugue@bull.net"},"content":"Hi Anton,\n\nOn Tue, 16 Sep 2008 15:59:47 +0400 Anton Vorontsov wrote:\n\n> On Mon, Sep 15, 2008 at 03:13:32PM +0200, Sebastien Dugue wrote:\n> [...]\n> > > we are a bit worried about putting this into the mainstream part of non real\n> > > time linux.\n> > \n> > Heck, I sure do not want this to be applied mainstream nor into any tree.\n> > The sole purpose of this patch was to trigger some reaction from the people who\n> > know the hardware and try to understand where the problem lies.\n> > \n> > > There interrupts work perfectly fine, and it was a bit of a\n> > > challenge to get there for all cases / configurations / machines.\n> > \n> > Agreed, but the fact that it fails with hardirq preemption leads me to\n> > believe (without any more knowledge about the harware) that there might be\n> > something amiss with this driver (or the code concerning the XICS)\n> > nevertheless.\n> > \n> > > \n> > > Could you try to enable these changes only for RT-Linux via a real-time\n> > > kconfig switch?\n> > \n> > Nope, this is just a quick hack that allows me to have a functional eHEA under\n> > the rt kernel. I want to understand what the problem is:\n> > \n> > - Is the eHEA really delivering level interrupts to the XICS?\n> > \n> > - Is the XICS loosing interrupts when they are masked?\n> \n> There is a known bug in the -rt kernels, the bug causes handlers\n> to lose edge interrupts.\n> \n> See this patch:\n> \n> http://lkml.org/lkml/2008/6/30/372\n\n Yes, I've been following that thread back then and my hack is based on your\npatch. So yes, it seems to be the same problem and it lies in the way -rt handles\nthe fasteoi flow.\n\n But looking at the comments from the XICS code, it seems that its wired for\nlevel only interrupts. Therefore without any more specs, it's still not clear to\nme that there's not a bug with the way the xics handles eHEA interrupts.\n\n Are the eHEA interrupts really level interrupts? If so why do they get lost\nwhen masked?\n\n I just found that not masking that particular interrupt in the fasteoi path\nmakes the thing work!\n\n Thanks,\n\n Sebastien.\n\n> \n> > - ...?\n> \n> -- \n> Anton Vorontsov\n> email: cbouatmailru@gmail.com\n> irc://irc.freenode.net/bd2\n> --\n> To unsubscribe from this list: send the line \"unsubscribe linux-rt-users\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>","headers":{"Return-Path":"","X-Original-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Delivered-To":["patchwork@ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from ozlabs.org (localhost [127.0.0.1])\n\tby ozlabs.org (Postfix) with ESMTP id D149FDE49F\n\tfor ; Tue, 16 Sep 2008 22:23:10 +1000 (EST)","from ecfrec.frec.bull.fr (ecfrec.frec.bull.fr [129.183.4.8])\n\tby ozlabs.org (Postfix) with ESMTP id EAEA3DDF75\n\tfor ; Tue, 16 Sep 2008 22:22:48 +1000 (EST)","from localhost (localhost [127.0.0.1])\n\tby ecfrec.frec.bull.fr (Postfix) with ESMTP\n\tid 30B691A1D32; Tue, 16 Sep 2008 14:22:42 +0200 (CEST)","from ecfrec.frec.bull.fr ([127.0.0.1])\n\tby localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id 18209-02; Tue, 16 Sep 2008 14:22:38 +0200 (CEST)","from cyclope.frec.bull.fr (cyclope.frec.bull.fr [129.183.4.9])\n\tby ecfrec.frec.bull.fr (Postfix) with ESMTP\n\tid 35BB01A1D19; Tue, 16 Sep 2008 14:22:38 +0200 (CEST)","from localhost (frecb000686.frec.bull.fr [129.183.101.139])\n\tby cyclope.frec.bull.fr (Postfix) with ESMTP id 3E7392728D;\n\tTue, 16 Sep 2008 14:22:35 +0200 (CEST)"],"Date":"Tue, 16 Sep 2008 14:22:37 +0200","From":"Sebastien Dugue ","To":"avorontsov@ru.mvista.com","Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","Message-ID":"<20080916142237.0dc5d024@bull.net>","In-Reply-To":"<20080916115947.GA6995@oksana.dev.rtsoft.ru>","References":"<20080915100406.342e027a@bull.net> <48CE5684.4000506@de.ibm.com>\n\t<20080915151332.6a3a7c80@bull.net>\n\t<20080916115947.GA6995@oksana.dev.rtsoft.ru>","X-Mailer":"Claws Mail 3.2.0 (GTK+ 2.12.2; i486-pc-linux-gnu)","Mime-Version":"1.0","X-Virus-Scanned":"by amavisd-new at frec.bull.fr","Cc":"tklein@de.ibm.com, tinytim@us.ibm.com,\n\tLinux-rt ,\n\tjean-pierre.dion@bull.net, themann@de.ibm.com, netdev@vger.kernel.org,\n\tlinux-kernel ,\n\tThomas Klein ,\n\tlinux-ppc , raisch@de.ibm.com,\n\tgilles.carry@ext.bull.net","X-BeenThere":"linuxppc-dev@ozlabs.org","X-Mailman-Version":"2.1.11","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork=ozlabs.org@ozlabs.org"}},{"id":1074,"web_url":"http://patchwork.ozlabs.org/comment/1074/","msgid":"","date":"2008-09-18T07:53:54","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","submitter":{"id":254,"url":"http://patchwork.ozlabs.org/api/people/254/","name":"Christoph Raisch","email":"RAISCH@de.ibm.com"},"content":"Sebastien Dugue wrote on 15.09.2008 10:04:06:\n> [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n> hardirq preemption\n>\n> Sebastien Dugue\n>\n> to:\n>\n> 15.09.2008 10:07\n>\n> Cc:\n>\n> linux-ppc, linux-kernel, Linux-rt, netdev, Jan-Bernd Themann, Thomas\n> Q Klein, Christoph Raisch, jean-pierre.dion, gilles.carry, tinytim\n>\n>\n> WARNING: HACK - HACK - HACK\n> Not-Signed-off-by: Sebastien Dugue \n> ---\n> --- a/arch/powerpc/kernel/ibmebus.c\n> +++ b/arch/powerpc/kernel/ibmebus.c\n> @@ -41,6 +41,7 @@\n> - return request_irq(irq, handler, irq_flags, devname, dev_id);\n> + ret = request_irq(irq, handler, irq_flags, devname, dev_id);\n> +\n> + desc = irq_desc + irq;\n> + desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);\n> + desc->status |= IRQ_TYPE_EDGE_RISING;\n> +\n> + return ret;\nThis looks a bit like a set_irq_type call.\nDon't know if this is fully implemented for xics though...\n> }\n> EXPORT_SYMBOL(ibmebus_request_irq);\n>\n> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c\n> index b7b397a..6d366ca 100644\n> --- a/kernel/irq/chip.c\n> +++ b/kernel/irq/chip.c\n> @@ -430,7 +430,7 @@ handle_fasteoi_irq(unsigned int irq, struct\n> irq_desc *desc)\n> action = desc->action;\n> if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |\n> IRQ_DISABLED)))) {\n> - desc->status |= IRQ_PENDING;\n> + desc->status |= IRQ_PENDING | IRQ_MASKED;\n> if (desc->chip->mask)\n> desc->chip->mask(irq);\n> goto out;\n> @@ -439,9 +439,10 @@ handle_fasteoi_irq(unsigned int irq, struct\n> irq_desc *desc)\n> desc->status |= IRQ_INPROGRESS;\n> /*\n> * In the threaded case we fall back to a mask+eoi sequence:\n> + * excepted for edge interrupts which are not masked.\n> */\n> if (redirect_hardirq(desc)) {\n> - if (desc->chip->mask)\n> + if (desc->chip->mask && !(desc->status & IRQ_TYPE_EDGE_BOTH))\n> desc->chip->mask(irq);\n> goto out;\n> }\n> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c\n> index 3bffa20..3e39c71 100644\n> --- a/kernel/irq/manage.c\n> +++ b/kernel/irq/manage.c\n> @@ -788,9 +788,12 @@ static void do_hardirq(struct irq_desc *desc)\n> thread_simple_irq(desc);\n> else if (desc->handle_irq == handle_level_irq)\n> thread_level_irq(desc);\n> - else if (desc->handle_irq == handle_fasteoi_irq)\n> - thread_fasteoi_irq(desc);\n> - else if (desc->handle_irq == handle_edge_irq)\n> + else if (desc->handle_irq == handle_fasteoi_irq) {\n> + if (desc->status & IRQ_TYPE_EDGE_BOTH)\n> + thread_edge_irq(desc);\n> + else\n> + thread_fasteoi_irq(desc);\n> + } else if (desc->handle_irq == handle_edge_irq)\n> thread_edge_irq(desc);\n> else\n> thread_do_irq(desc);\n> --\n> 1.6.0.1.308.gede4c\n>\nAccording to the specs at some point in the system the HEA IRQs have a edge\ncharacteristic.\nBut since PCI-E edge and level can both be forwarded through a message\ninterface\n(HEA is not PCI-E, it's only connected to the same internal bus, where the\nPHB resides)\n\nAnybody from the xics experts want to comment on this?\n\n\n\nGruss / Regards\nChristoph R. & Jan-Bernd","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.176.167])\n\tby ozlabs.org (Postfix) with ESMTP id 84202DDF10\n\tfor ;\n\tThu, 18 Sep 2008 17:54:20 +1000 (EST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753082AbYIRHyP (ORCPT );\n\tThu, 18 Sep 2008 03:54:15 -0400","(majordomo@vger.kernel.org) by vger.kernel.org id S1752831AbYIRHyP\n\t(ORCPT ); Thu, 18 Sep 2008 03:54:15 -0400","from mtagate5.de.ibm.com ([195.212.29.154]:42754 \"EHLO\n\tmtagate5.de.ibm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751449AbYIRHyN (ORCPT\n\t); Thu, 18 Sep 2008 03:54:13 -0400","from d12nrmr1607.megacenter.de.ibm.com\n\t(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])\n\tby mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id m8I7s4wB267716; \n\tThu, 18 Sep 2008 07:54:04 GMT","from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com\n\t[9.149.165.229])\n\tby d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with\n\tESMTP id m8I7s04Y3960956; Thu, 18 Sep 2008 09:54:04 +0200","from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1])\n\tby d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP\n\tid m8I7ruo6029095; Thu, 18 Sep 2008 09:53:57 +0200","from d12ml067.megacenter.de.ibm.com\n\t(d12ml067.megacenter.de.ibm.com [9.149.164.162])\n\tby d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with\n\tESMTP id m8I7ru6W029085; Thu, 18 Sep 2008 09:53:56 +0200"],"In-Reply-To":"<20080915100406.342e027a@bull.net>","References":"<20080915100406.342e027a@bull.net>","Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","X-KeepSent":"39C3BF0F:17B60FAA-C12574C8:002AE138;\n type=4; name=$KeepSent","To":"Sebastien Dugue ","Cc":"gilles.carry@ext.bull.net, Jan-Bernd Themann ,\n\tjean-pierre.dion@bull.net, linux-kernel ,\n\tLinux-rt ,\n\tlinux-ppc , netdev@vger.kernel.org,\n\tThomas Q Klein , tinytim@us.ibm.com,\n\tBenjamin Herrenschmidt ","X-Mailer":"Lotus Notes Release 8.0.1 HF105 April 10, 2008","Message-ID":"","From":"Christoph Raisch ","Date":"Thu, 18 Sep 2008 09:53:54 +0200","X-MIMETrack":"Serialize by Router on D12ML067/12/M/IBM(Release 8.0.1|February\n\t07, 2008) at 18/09/2008 09:53:55","MIME-Version":"1.0","Content-type":"text/plain; charset=US-ASCII","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1087,"web_url":"http://patchwork.ozlabs.org/comment/1087/","msgid":"<20080918112713.75872c95@bull.net>","date":"2008-09-18T09:27:13","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","submitter":{"id":101,"url":"http://patchwork.ozlabs.org/api/people/101/","name":"Sebastien Dugue","email":"sebastien.dugue@bull.net"},"content":"On Thu, 18 Sep 2008 09:53:54 +0200 Christoph Raisch wrote:\n\n> \n> Sebastien Dugue wrote on 15.09.2008 10:04:06:\n> > [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n> > hardirq preemption\n> >\n> > Sebastien Dugue\n> >\n> > to:\n> >\n> > 15.09.2008 10:07\n> >\n> > Cc:\n> >\n> > linux-ppc, linux-kernel, Linux-rt, netdev, Jan-Bernd Themann, Thomas\n> > Q Klein, Christoph Raisch, jean-pierre.dion, gilles.carry, tinytim\n> >\n> >\n> > WARNING: HACK - HACK - HACK\n> > Not-Signed-off-by: Sebastien Dugue \n> > ---\n> > --- a/arch/powerpc/kernel/ibmebus.c\n> > +++ b/arch/powerpc/kernel/ibmebus.c\n> > @@ -41,6 +41,7 @@\n> > - return request_irq(irq, handler, irq_flags, devname, dev_id);\n> > + ret = request_irq(irq, handler, irq_flags, devname, dev_id);\n> > +\n> > + desc = irq_desc + irq;\n> > + desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);\n> > + desc->status |= IRQ_TYPE_EDGE_RISING;\n> > +\n> > + return ret;\n> This looks a bit like a set_irq_type call.\n\n Yep.\n\n> Don't know if this is fully implemented for xics though...\n\n No, the xics does not implement a set_type() method.\n\n> > }\n> > EXPORT_SYMBOL(ibmebus_request_irq);\n> >\n> > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c\n> > index b7b397a..6d366ca 100644\n> > --- a/kernel/irq/chip.c\n> > +++ b/kernel/irq/chip.c\n> > @@ -430,7 +430,7 @@ handle_fasteoi_irq(unsigned int irq, struct\n> > irq_desc *desc)\n> > action = desc->action;\n> > if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |\n> > IRQ_DISABLED)))) {\n> > - desc->status |= IRQ_PENDING;\n> > + desc->status |= IRQ_PENDING | IRQ_MASKED;\n> > if (desc->chip->mask)\n> > desc->chip->mask(irq);\n> > goto out;\n> > @@ -439,9 +439,10 @@ handle_fasteoi_irq(unsigned int irq, struct\n> > irq_desc *desc)\n> > desc->status |= IRQ_INPROGRESS;\n> > /*\n> > * In the threaded case we fall back to a mask+eoi sequence:\n> > + * excepted for edge interrupts which are not masked.\n> > */\n> > if (redirect_hardirq(desc)) {\n> > - if (desc->chip->mask)\n> > + if (desc->chip->mask && !(desc->status & IRQ_TYPE_EDGE_BOTH))\n> > desc->chip->mask(irq);\n> > goto out;\n> > }\n> > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c\n> > index 3bffa20..3e39c71 100644\n> > --- a/kernel/irq/manage.c\n> > +++ b/kernel/irq/manage.c\n> > @@ -788,9 +788,12 @@ static void do_hardirq(struct irq_desc *desc)\n> > thread_simple_irq(desc);\n> > else if (desc->handle_irq == handle_level_irq)\n> > thread_level_irq(desc);\n> > - else if (desc->handle_irq == handle_fasteoi_irq)\n> > - thread_fasteoi_irq(desc);\n> > - else if (desc->handle_irq == handle_edge_irq)\n> > + else if (desc->handle_irq == handle_fasteoi_irq) {\n> > + if (desc->status & IRQ_TYPE_EDGE_BOTH)\n> > + thread_edge_irq(desc);\n> > + else\n> > + thread_fasteoi_irq(desc);\n> > + } else if (desc->handle_irq == handle_edge_irq)\n> > thread_edge_irq(desc);\n> > else\n> > thread_do_irq(desc);\n> > --\n> > 1.6.0.1.308.gede4c\n> >\n> According to the specs at some point in the system the HEA IRQs have a edge\n> characteristic.\n> But since PCI-E edge and level can both be forwarded through a message\n> interface\n> (HEA is not PCI-E, it's only connected to the same internal bus, where the\n> PHB resides)\n\n Good to know, the problem here seems to be that the xics is using the\nfasteoi flow handler, which under unconditionally masks the irq. Will have to\ndig in the genirq stuff a bit more to understand what the differences are\nbetween -rt and mainline.\n\n> \n> Anybody from the xics experts want to comment on this?\n\n It would be really interresting to know if the eHCA exhibits the same\nproblem under -rt as it's the only other user of the ibmebus.\nUnfortunately I don't have the hardware to test.\n\n Thanks,\n\n Sebastien.\n\n\n> \n> \n> \n> Gruss / Regards\n> Christoph R. & Jan-Bernd\n> \n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.176.167])\n\tby ozlabs.org (Postfix) with ESMTP id B064ADDFB0\n\tfor ;\n\tThu, 18 Sep 2008 19:27:38 +1000 (EST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753701AbYIRJ13 (ORCPT );\n\tThu, 18 Sep 2008 05:27:29 -0400","(majordomo@vger.kernel.org) by vger.kernel.org id S1753892AbYIRJ13\n\t(ORCPT ); Thu, 18 Sep 2008 05:27:29 -0400","from ecfrec.frec.bull.fr ([129.183.4.8]:54843 \"EHLO\n\tecfrec.frec.bull.fr\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753599AbYIRJ11 (ORCPT\n\t); Thu, 18 Sep 2008 05:27:27 -0400","from localhost (localhost [127.0.0.1])\n\tby ecfrec.frec.bull.fr (Postfix) with ESMTP\n\tid CB7901A1C18; Thu, 18 Sep 2008 11:27:17 +0200 (CEST)","from ecfrec.frec.bull.fr ([127.0.0.1])\n\tby localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id 08880-06; Thu, 18 Sep 2008 11:27:14 +0200 (CEST)","from cyclope.frec.bull.fr (cyclope.frec.bull.fr [129.183.4.9])\n\tby ecfrec.frec.bull.fr (Postfix) with ESMTP\n\tid 18D421A18CE; Thu, 18 Sep 2008 11:27:14 +0200 (CEST)","from localhost (frecb000686.frec.bull.fr [129.183.101.139])\n\tby cyclope.frec.bull.fr (Postfix) with ESMTP id 5DFCB2728D;\n\tThu, 18 Sep 2008 11:27:11 +0200 (CEST)"],"Date":"Thu, 18 Sep 2008 11:27:13 +0200","From":"Sebastien Dugue ","To":"Christoph Raisch ","Cc":"gilles.carry@ext.bull.net, Jan-Bernd Themann ,\n\tjean-pierre.dion@bull.net, linux-kernel ,\n\tLinux-rt ,\n\tlinux-ppc , netdev@vger.kernel.org,\n\tThomas Q Klein , tinytim@us.ibm.com,\n\tBenjamin Herrenschmidt ","Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption","Message-ID":"<20080918112713.75872c95@bull.net>","In-Reply-To":"","References":"<20080915100406.342e027a@bull.net>\n\t","X-Mailer":"Claws Mail 3.2.0 (GTK+ 2.12.2; i486-pc-linux-gnu)","Mime-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Virus-Scanned":"by amavisd-new at frec.bull.fr","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1107,"web_url":"http://patchwork.ozlabs.org/comment/1107/","msgid":"","date":"2008-09-18T10:42:05","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption, eHCA is close","submitter":{"id":254,"url":"http://patchwork.ozlabs.org/api/people/254/","name":"Christoph Raisch","email":"RAISCH@de.ibm.com"},"content":"Sebastien Dugue wrote on 18.09.2008 11:27:13:\n\n>\n> It would be really interresting to know if the eHCA exhibits the same\n> problem under -rt as it's the only other user of the ibmebus.\n> Unfortunately I don't have the hardware to test.\n>\n\neHCA is very close from the interrupt generation and handling perspective,\nso yes, could be an issue there as well.\n\n\nGruss / Regards\nChristoph Raisch","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.176.167])\n\tby ozlabs.org (Postfix) with ESMTP id 8C06ADDE1E\n\tfor ;\n\tThu, 18 Sep 2008 20:42:19 +1000 (EST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753736AbYIRKmN (ORCPT );\n\tThu, 18 Sep 2008 06:42:13 -0400","(majordomo@vger.kernel.org) by vger.kernel.org id S1753477AbYIRKmM\n\t(ORCPT ); Thu, 18 Sep 2008 06:42:12 -0400","from mtagate3.de.ibm.com ([195.212.29.152]:61461 \"EHLO\n\tmtagate3.de.ibm.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751468AbYIRKmL (ORCPT\n\t); Thu, 18 Sep 2008 06:42:11 -0400","from d12nrmr1607.megacenter.de.ibm.com\n\t(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])\n\tby mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m8IAg86A301600; \n\tThu, 18 Sep 2008 10:42:08 GMT","from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com\n\t[9.149.165.229])\n\tby d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with\n\tESMTP id m8IAg8Vn3715132; Thu, 18 Sep 2008 12:42:08 +0200","from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1])\n\tby d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP\n\tid m8IAg7cw027134; Thu, 18 Sep 2008 12:42:08 +0200","from d12ml067.megacenter.de.ibm.com\n\t(d12ml067.megacenter.de.ibm.com [9.149.164.162])\n\tby d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with\n\tESMTP id m8IAg7YC027130; Thu, 18 Sep 2008 12:42:07 +0200"],"In-Reply-To":"<20080918112713.75872c95@bull.net>","References":"<20080915100406.342e027a@bull.net>\t\n\t<20080918112713.75872c95@bull.net>","Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption, eHCA is close","X-KeepSent":"D7842B7A:ADC47EED-C12574C8:003A2CB3;\n type=4; name=$KeepSent","To":"Sebastien Dugue ","Cc":"Benjamin Herrenschmidt ,\n\tgilles.carry@ext.bull.net, Jan-Bernd Themann ,\n\tjean-pierre.dion@bull.net, linux-kernel ,\n\tLinux-rt ,\n\tlinux-ppc , netdev@vger.kernel.org,\n\tThomas Q Klein , tinytim@us.ibm.com,\n\tHoang-Nam Nguyen ","X-Mailer":"Lotus Notes Release 8.0.1 HF105 April 10, 2008","Message-ID":"","From":"Christoph Raisch ","Date":"Thu, 18 Sep 2008 12:42:05 +0200","X-MIMETrack":"Serialize by Router on D12ML067/12/M/IBM(Release 8.0.1|February\n\t07, 2008) at 18/09/2008 12:42:06","MIME-Version":"1.0","Content-type":"text/plain; charset=US-ASCII","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1122,"web_url":"http://patchwork.ozlabs.org/comment/1122/","msgid":"<20080918143146.77db81d5@bull.net>","date":"2008-09-18T12:31:46","subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption, eHCA is close","submitter":{"id":101,"url":"http://patchwork.ozlabs.org/api/people/101/","name":"Sebastien Dugue","email":"sebastien.dugue@bull.net"},"content":"On Thu, 18 Sep 2008 12:42:05 +0200 Christoph Raisch wrote:\n\n> \n> Sebastien Dugue wrote on 18.09.2008 11:27:13:\n> \n> >\n> > It would be really interresting to know if the eHCA exhibits the same\n> > problem under -rt as it's the only other user of the ibmebus.\n> > Unfortunately I don't have the hardware to test.\n> >\n> \n> eHCA is very close from the interrupt generation and handling perspective,\n> so yes, could be an issue there as well.\n\n That's what I was speculating.\n\n Thanks,\n\n Sebastien.\n\n> \n> \n> Gruss / Regards\n> Christoph Raisch\n> \n> \n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.176.167])\n\tby ozlabs.org (Postfix) with ESMTP id 0F0ECDDF77\n\tfor ;\n\tThu, 18 Sep 2008 22:32:13 +1000 (EST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753452AbYIRMcC (ORCPT );\n\tThu, 18 Sep 2008 08:32:02 -0400","(majordomo@vger.kernel.org) by vger.kernel.org id S1753368AbYIRMcB\n\t(ORCPT ); Thu, 18 Sep 2008 08:32:01 -0400","from ecfrec.frec.bull.fr ([129.183.4.8]:60036 \"EHLO\n\tecfrec.frec.bull.fr\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753209AbYIRMb7 (ORCPT\n\t); Thu, 18 Sep 2008 08:31:59 -0400","from localhost (localhost [127.0.0.1])\n\tby ecfrec.frec.bull.fr (Postfix) with ESMTP\n\tid 1CDF01A1D8E; Thu, 18 Sep 2008 14:31:52 +0200 (CEST)","from ecfrec.frec.bull.fr ([127.0.0.1])\n\tby localhost (ecfrec.frec.bull.fr [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id 01060-03; Thu, 18 Sep 2008 14:31:48 +0200 (CEST)","from cyclope.frec.bull.fr (cyclope.frec.bull.fr [129.183.4.9])\n\tby ecfrec.frec.bull.fr (Postfix) with ESMTP\n\tid 972481A1D89; Thu, 18 Sep 2008 14:31:46 +0200 (CEST)","from localhost (frecb000686.frec.bull.fr [129.183.101.139])\n\tby cyclope.frec.bull.fr (Postfix) with ESMTP id 903BF2728D;\n\tThu, 18 Sep 2008 14:31:43 +0200 (CEST)"],"Date":"Thu, 18 Sep 2008 14:31:46 +0200","From":"Sebastien Dugue ","To":"Christoph Raisch ","Cc":"Benjamin Herrenschmidt ,\n\tgilles.carry@ext.bull.net, Jan-Bernd Themann ,\n\tjean-pierre.dion@bull.net, linux-kernel ,\n\tLinux-rt ,\n\tlinux-ppc , netdev@vger.kernel.org,\n\tThomas Q Klein , tinytim@us.ibm.com,\n\tHoang-Nam Nguyen ","Subject":"Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with\n\thardirq preemption, eHCA is close","Message-ID":"<20080918143146.77db81d5@bull.net>","In-Reply-To":"","References":"<20080915100406.342e027a@bull.net>\n\t\n\t<20080918112713.75872c95@bull.net>\n\t","X-Mailer":"Claws Mail 3.2.0 (GTK+ 2.12.2; i486-pc-linux-gnu)","Mime-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Virus-Scanned":"by amavisd-new at frec.bull.fr","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]