From: Richard Hirst <rhirst@linuxcare.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] AT Keyboard not present?
Date: Thu, 20 Sep 2001 22:56:25 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590698805233@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590698805137@msgid-missing>
On Wed, Sep 19, 2001 at 02:49:28PM -0700, David Mosberger wrote:
> Glad to see you're making progress on this, but the patch looks
> suspicious to me. There shouldn't be anything ia64 specific in this
> code. It would be good to understand why the keyboard interrupt gets
> lost.
Turns out the interrupt isn't lost, it is just held off until the
previous one has been completely serviced...
User hits CapsLock
CPU enters arch/ia64/kernel/irq_ia64.c:ia64_handle_irq()
which calls arch/ia64/kernel/irq.c:do_IRQ()
which calls the kb interrupt handler
and then do_IRQ() sees local_softirq_pending() and calls do_softirq()
that will run the keyboard tasklet, which calls
drivers/char/pc_keyb.c:pckbd_leds()
pckbd_leds() calls send_data() which expects the kb to generate interrupts
those interrupts can't happen because we havn't yet returned to
ia64_handle_irq() and called ia64_eoi() for the last one
eventually send_data() gives up and returns, we unwind and call ia64_eio()
and the keyboard interrupts.
I'm guessing that ia64_eoi() is needed before the next k/b int can
happen, but it sounds logical.
The answer _might_ be to move the call to do_softirq() from the end of
do_IRQ() to the end of ia64_handle_irq(). I've tried that, and it works,
but I don't claim to know the ia64 interrupt h/w or s/w, so there may
be nasty side-effects. Calling do_softirq() only once all pending ints
have been completely serviced sounds more correct to me anyway.
Richard
next prev parent reply other threads:[~2001-09-20 22:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-07 17:49 [Linux-ia64] AT Keyboard not present? KOCHI Takayoshi
2001-09-07 19:05 ` Krishnakumar B
2001-09-07 19:36 ` Johannes Erdfelt
2001-09-07 19:55 ` Krishnakumar B
2001-09-07 20:02 ` Johannes Erdfelt
2001-09-07 20:09 ` Khalid Aziz
2001-09-07 20:12 ` KOCHI Takayoshi
2001-09-10 8:46 ` Martin Wilck
2001-09-10 21:43 ` Michael Madore
2001-09-10 22:10 ` Luck, Tony
2001-09-10 23:28 ` David Mosberger
2001-09-19 13:35 ` Richard Hirst
2001-09-19 21:49 ` David Mosberger
2001-09-19 22:27 ` Richard Hirst
2001-09-20 22:56 ` Richard Hirst [this message]
2001-09-21 15:44 ` David Mosberger
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=marc-linux-ia64-105590698805233@msgid-missing \
--to=rhirst@linuxcare.com \
--cc=linux-ia64@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.