From: Steve Rossi <srossi@labs•mot.com>
To: Embedded Linux PPC List <linuxppc-embedded@lists•linuxppc.org>
Subject: Re: high priority interrupts disabled
Date: Wed, 12 Dec 2001 09:27:04 -0600 [thread overview]
Message-ID: <3C177748.1A1342C2@labs.mot.com> (raw)
In-Reply-To: 3C14F91F.F382ABE3@labs.mot.com
Hi All,
Here's an update
> Dan Malek wrote:
>
> > ...I wonder if IRQ2 is being masked. ...
>
> I verified that IRQ2 is not getting masked in the SIMASK register during the
> disk I/O which is when it can get held off ...
Well I lied - sort of - turns out that under normal circumstances IRQ2 doesn't
get masked but under some condition (which I have not yet determined) IRQ2 does
get masked during IRQ6.
Since IRQ6 - the hard disk interrupt - does data transfer in the ISR, then
interrupts again, the processor ends up exiting from the ISR, then jumping right
back in hundreds of times in a row. I'm a newbie to writing Linux drivers, but
this seems to me like poor practice - to do the work of data transfer to the disk
in the ISR itself, but I guess its only really a problem in PIO modes. I would be
interested in knowing why its done this way. Regardless, my IRQ2 doesn't get
unmasked again until the full number of sectors is written to the disk.
I tried to use the Linux Trace Toolkit - as Wolfgang suggested, but after
applying the patches to my 2.4.16 kernel and hacking in the pieces that didn't
patch cleanly, the kernel wouldn't boot, so I didn't spend much more time on it.
I think it would only give me marginally more information than what I'm able to
gleen by looking at the bus activity.
Are there any other experiences with ide-disk driver causing other interrupts to
be held off for long periods of time?
Can someone who is familiar with the interrupt entry/exit mechanisms comment on
if it is possible for a normal IRQ2 isr to run (note it runs with interrupts
enabled MSR EE bit =1), then as its exiting, but before it is re-enabled for IRQ6
to run? Since IRQ6 fires one right after the other hundreds of times, the
un-masking of IRQ2 wouldn't happen until IRQ6 stops firing?? Is this plausable or
is there sufficient protection to guarantee that IRQ2 will exit completely
(thereby getting un-masked) before IRQ6 can run? Is there a mechanism by which
all lower priority interrupts are disabled when a higher priority one is running?
If not, it seems to me this could happen.
Thanks,
Steve
--
-------------------------------------------------------
Steven K. Rossi srossi@labs•mot.com
Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-12-12 15:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-07 20:12 high priority interrupts disabled Steve Rossi
2001-12-07 23:10 ` Dan Malek
2001-12-10 18:04 ` Steve Rossi
2001-12-10 18:38 ` Wolfgang Denk
2001-12-12 15:27 ` Steve Rossi [this message]
2001-12-12 23:09 ` high priority interrupts disabled - problem found Steve Rossi
2001-12-13 4:49 ` Dan Malek
2001-12-13 15:02 ` Steve Rossi
2001-12-13 19:35 ` Dan Malek
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=3C177748.1A1342C2@labs.mot.com \
--to=srossi@labs$(echo .)mot.com \
--cc=linuxppc-embedded@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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