linux-kernel - Re: cmd64x: irq 14: nobody cared

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200906221639.52205.bzolnier@gmail.com>
Date:	Mon, 22 Jun 2009 16:39:50 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Frans Pop <elendil@...net.nl>
Cc:	David Miller <davem@...emloft.net>, sparclinux@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: cmd64x: irq 14: nobody cared - system is dreadfully slow

On Monday 22 June 2009 16:04:15 Frans Pop wrote:
> On Monday 22 June 2009, you wrote:
> > From: Bartlomiej Zolnierkiewicz <bzolnier@...il.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@...net.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/