From: Marcin Dalecki <dalecki@evision.ag>
To: Petr Vandrovec <VANDROVE@vc.cvut.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: IDE from current bk tree, UDMA and two channels...
Date: Wed, 31 Jul 2002 22:01:19 +0200 [thread overview]
Message-ID: <3D48420F.5050407@evision.ag> (raw)
In-Reply-To: 9B9F331783@vcnet.vc.cvut.cz
Petr Vandrovec wrote:
> I wrote:
>
>>Unfortunately ATA/ATAPIv7 says that single interrupt is triggered
>>after command is done and all data transfered, and we do not play
>>with select bit. But we play with nIEN bit of disk. Do you see
>>any reason why this should cause spurious interrupt? (system is using
>>XT-PIC, FYI)
>
>
> OK. As I am using only one device on each channel, I commented
> out ata_irq_enable(drive, 1) in ide-disk.c when issuing command,
> and removed disabling irq in ide_do_request in ide.c when we
> do not issue command to the drive, and spurious interrupts disappeared.
> So now I'm getting only half of IRQs for channel 0, and system still
> works as before ;-)
Well OK this was my next idea, but apparently you already did the
experient on your own. Thanks for the result. I'm still scratching my
head and I have already observed this before myself.
It's always funny to see what happens when one stops a driver
from deliberately disabling IRQs for eons of jiffies :-).
> Unfortunately, problem is still here: when kernel was in idedisk_do_request
> performed on channel 0, IRQ for channel 1 arrived, and this irq found
> channel 1 DMA engine ready, but drive had DRQ set... oops. Shortly after
> that IRQ for channel 1 arrived again, but as it was unexpected, nothing
> happened.
>
> I hope that i845 is not simplex device, but first (unexpected) IRQ arrived
> just when channel 0 code wrote new value to its IDE_SELECT_REG register.
> Now I even disconnected DVD drive, so it is simple two masters, two
> channels configuration, but it still happens.
One idea and one experiment I was already thinking about is
to change do_ide_request to actually *not* select delibreately which
device do handle. (The big for loop found there...)
One can instead search for a device on the channel which is matching
the queue for which do_ide_request() was called.
for (unit = 0; unit < MAX_DEVICES; ++unit) {
....
if (tmp->queue == q) {
drive = tmp;
break;
}
}
if (!drive)
BUG();
Just please forget temporarly that there is a mechanism for "sleeping".
It is bogous anyway (doesn give time back to anybody) and the only
consumer of it is ide-cd (easly removed there) and ide-tape.c (don't
care the driver was never usable in 2.5.xx)
> And as always, something else: ata_error does:
>
> OUT_BYTE(WIN_NOP, ch->ports[IDE_CONTROL_OFFSET])
>
> I'd say that it should use 0x00 instead of WIN_NOP, and also tha
> comment above OUT_BYTE(0x04, ch->ports[IDE_CONTROL_OFFSET]) is bogus.
> Command register is IDE_COMMAND, not IDE_CONTROL ;-)
Yes I know already about this I will remove the comment.
(Must have forgotten about it.)
next prev parent reply other threads:[~2002-08-01 9:39 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-30 19:26 IDE from current bk tree, UDMA and two channels Petr Vandrovec
2002-07-31 20:01 ` Marcin Dalecki [this message]
2002-08-01 9:56 ` Jens Axboe
2002-08-01 9:56 ` Marcin Dalecki
2002-08-01 10:05 ` Jens Axboe
2002-08-01 10:33 ` Marcin Dalecki
2002-08-01 10:45 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2002-08-01 23:13 Petr Vandrovec
2002-08-02 13:07 ` Alan Cox
2002-08-01 23:00 Petr Vandrovec
2002-08-01 23:05 ` Alexander Viro
2002-08-01 22:53 Petr Vandrovec
2002-08-01 23:02 ` Alexander Viro
2002-08-01 23:54 ` Linus Torvalds
[not found] <200208012219.g71MJV109133@penguin.transmeta.com>
2002-08-01 22:45 ` Alexander Viro
2002-08-02 9:10 ` Marcin Dalecki
2002-08-01 22:42 Petr Vandrovec
2002-08-01 22:52 ` Alexander Viro
2002-08-02 9:11 ` Marcin Dalecki
2002-08-01 22:34 Petr Vandrovec
2002-08-01 17:07 Petr Vandrovec
2002-08-01 22:00 ` Petr Vandrovec
2002-08-01 22:13 ` Marcin Dalecki
2002-08-01 22:39 ` Alexander Viro
2002-07-30 18:19 Petr Vandrovec
2002-07-31 19:48 ` Marcin Dalecki
2002-07-30 16:15 Petr Vandrovec
2002-07-30 14:03 Petr Vandrovec
2002-07-30 14:25 ` Marcin Dalecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D48420F.5050407@evision.ag \
--to=dalecki@evision.ag \
--cc=VANDROVE@vc.cvut.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=martin@dalecki.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox