Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "MIPS/Linux List \(SGI\)" <linux-mips@oss.sgi.com>
Subject: EJTAG Debug Exceptions and LL/SC
Date: Mon, 25 Mar 2002 16:19:44 +0100	[thread overview]
Message-ID: <00f201c1d410$f05bd540$0deca8c0@Ulysses> (raw)

In the course of hacking around in the 2.4.18 kernel
on a new MIPS CPU, I came across something that
urgently needs to be fixed in any repositories that
propose MIPS EJTAG support.

EJTAG exceptions do *not* affect the LL/SC
flipflop.  That means that they are non-invasive
if injected into a LL/SC sequence.  It also means
that one cannot use LL/SC within a Debug exception
handler.  The Linux mini Debug exception handler
has for some time performed printk()'s to let the
world know that something "unusual" has happened.
Somewhere between 2.4.3 and 2.4.18, someone
cleverly fixed printk() to not munge simultaneous
output lines on SMP systems, which on MIPS
means using LL/SC.  Result:  the kernel will go
into an infinite loop in Debug mode (no further 
interrupts taken, etc.)  if ever an Debug exception 
is taken after an LL sets the flop.  So those calls to
printk() need to go away, and a big narly comment
needs to go at the top of ejtag_exception_handler()
warning people not to call any function that might
involve a kernel semaphore, cause a TLB fault,
or depend on an interrupt beind delivered.

In general, code executed in the kernel in Debug
mode needs to be carefully quarantined.  Any invocation
of kernel services needs to be done either by passing
a message to be sampled at some later point by the
kernel, or by setting up a software interrupt to be taken
after the DERET from the Debug exception.

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: "MIPS/Linux List (SGI)" <linux-mips@oss.sgi.com>
Subject: EJTAG Debug Exceptions and LL/SC
Date: Mon, 25 Mar 2002 16:19:44 +0100	[thread overview]
Message-ID: <00f201c1d410$f05bd540$0deca8c0@Ulysses> (raw)
Message-ID: <20020325151944._tTTHbhBSEwEqTvhgaqPHxTsdeY_wp7UZzU5rLfQ-O0@z> (raw)

In the course of hacking around in the 2.4.18 kernel
on a new MIPS CPU, I came across something that
urgently needs to be fixed in any repositories that
propose MIPS EJTAG support.

EJTAG exceptions do *not* affect the LL/SC
flipflop.  That means that they are non-invasive
if injected into a LL/SC sequence.  It also means
that one cannot use LL/SC within a Debug exception
handler.  The Linux mini Debug exception handler
has for some time performed printk()'s to let the
world know that something "unusual" has happened.
Somewhere between 2.4.3 and 2.4.18, someone
cleverly fixed printk() to not munge simultaneous
output lines on SMP systems, which on MIPS
means using LL/SC.  Result:  the kernel will go
into an infinite loop in Debug mode (no further 
interrupts taken, etc.)  if ever an Debug exception 
is taken after an LL sets the flop.  So those calls to
printk() need to go away, and a big narly comment
needs to go at the top of ejtag_exception_handler()
warning people not to call any function that might
involve a kernel semaphore, cause a TLB fault,
or depend on an interrupt beind delivered.

In general, code executed in the kernel in Debug
mode needs to be carefully quarantined.  Any invocation
of kernel services needs to be done either by passing
a message to be sampled at some later point by the
kernel, or by setting up a software interrupt to be taken
after the DERET from the Debug exception.

            Regards,

            Kevin K.

             reply	other threads:[~2002-03-25 15:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-25 15:19 Kevin D. Kissell [this message]
2002-03-25 15:19 ` EJTAG Debug Exceptions and LL/SC Kevin D. Kissell

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='00f201c1d410$f05bd540$0deca8c0@Ulysses' \
    --to=kevink@mips.com \
    --cc=linux-mips@oss.sgi.com \
    /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