lkml.org 
[lkml]   [2009]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: cmd64x: irq 14: nobody cared - system is dreadfully slow
Date
On Monday 22 June 2009 16:04:15 Frans Pop wrote:
> On Monday 22 June 2009, you wrote:
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] ide: fix handling of unexpected IRQs vs request_irq()
> >
> > Add ide_host_enable_irqs() helper and use it in ide_host_register()
> > before registering ports. Then remove no longer needed IRQ unmasking
> > from in init_irq().
> >
> > This should fix the problem with "screaming" shared IRQ on the first
> > port (after request_irq() call while we have the unexpected IRQ pending
> > on the second port) which was uncovered by my rework of the serialized
> > interfaces support.
>
> Thanks Bart. This does solve the "nobody cared" problem.
> Tested-by: Frans Pop <elendil@planet.nl>
>
> I also tested it without David's initial patch (i.e. *with*
> IDE_HFLAG_SERIALIZE in host-flags) and that seems to work fine too:
> ide0 at 0x1fe02c00000-0x1fe02c00007,0x1fe02c0000a on irq 14 (serialized)
> ide1 at 0x1fe02c00010-0x1fe02c00017,0x1fe02c0001a on irq 14 (serialized)

Great, thanks for testing it (and once again sorry for the trouble).

> No idea whether serialized is to be preferred or not. Guess that's David's
> call now.

Since you have verified that serialization is not needed we should get rid
of it while we are at it (it negatively affects performance of simultaneous
operations on both ports of the controller).

> I do still get the "bad DMA info in identify block" error for the CD
> drive, so that's still a regression relative to 2.6.26:
> hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4
> -hdd: MWDMA2 mode selected
> +hdd: bad DMA info in identify block
> +hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4

I begin to wonder whether this problem could be the one responsible for
generating the spurious IRQ that we are seeing on the second port (I think
that this is _very_ likely)..

I promised to look into it but I still need a identify block content to
tell more (you can add #define DEBUG to the ide-probe.c so we will get id
before and after changing of transfer mode settings):

---
drivers/ide/ide-probe.c | 2 ++
1 file changed, 2 insertions(+)

Index: b/drivers/ide/ide-probe.c
===================================================================
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -39,6 +39,8 @@
#include <asm/uaccess.h>
#include <asm/io.h>

+#define DEBUG
+
/**
* generic_id - add a generic drive id
* @drive: drive to make an ID block for

\
 
 \ /
  Last update: 2009-06-22 16:39    [W:0.062 / U:5.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site