Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@dsl2.external.hp.com>
To: Bruno Vidal <bruno_vidal@hpfrcu03.france.hp.com>
Cc: "parisc-linux@lists.parisc-linux.org"
	<parisc-linux@lists.parisc-linux.org>
Subject: Re: [parisc-linux] Pb with dump driver.
Date: Thu, 14 Feb 2002 23:43:52 -0700	[thread overview]
Message-ID: <20020215064352.86A404858@dsl2.external.hp.com> (raw)
In-Reply-To: Message from Bruno Vidal <bruno_vidal@hpfrcu03.france.hp.com> of "Wed, 13 Feb 2002 18:34:59 +0100." <3C6AA3C3.D21C4164@admin.france.hp.com>

Bruno Vidal wrote:
> but at the first try to write on the dump device if "sleep"
> forever in "brw_kiovec". I'm pretty sure that it comes from
> a spinlock deadlock. So I'm looking for someone who is able
> to explain the "data page fault" function. 

Have you considered using IODC to write out the data
instead of using OS code?

It would avoid much of the ugliness of spinlocks still
held in the IO or VM code.

> For me it is the signal 15 in function handle_interruption() 
> of traps.c. If it is the space 0 (kernel space), it call 
> parisc_terminate(), that call dump() (my funtion). But in dump 
> I use a buffer, and I use this buffer with "brw_kiovec". So I 
> think that "brw_kiovec" do a page_fault somewhere, but because 
> the previous page_fault fail, there is still a spinlock somewhere.

If you TOC the system, you should see the code was spinning
on a ldcw instruction.  either IOAQ should point to the
function and the address referenced by ldcw should be
visible in System.map.

> Can someone help on this issue ?

Once we know either (offending code location or which
spinlock), we can start looking at code to figure out
what the problem is.


In the next mail:
| Another thing that can produce this behavior is the interruption mask.
| When calling the do_page_fault, what it the interruption mask ?

I believe PSW_I bit is off. EIEM is irrelevant at this point.
See entry.S where it calls handle_interruption.

| I think it is high enough to mask SCSI interruption?
| When is it reset back ?

See "do_cpu_irq_mask()" (arch/parisc/kernel/irq.c).
SCSI interrupt as an "External Interrupt" and remains masked in the EIEM
even after PSW_I bit is set. No interrupts from anything using the masked
EIR bit will be processed until we exit do_cpu_irq_mask(). If that
gets interrupted by a page fault or something, using that driver
is toast until we reset the EIEM registers of all cpus....another
reason to use IODC since it doesn't use interrupts for
processing.

thanks,
grant

  parent reply	other threads:[~2002-02-15  6:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-13 17:34 [parisc-linux] Pb with dump driver Bruno Vidal
2002-02-13 17:43 ` Bruno Vidal
2002-02-15  6:43 ` Grant Grundler [this message]
2002-02-15 12:55   ` Bruno Vidal
2002-02-15 19:08     ` Grant Grundler
2002-02-15 21:01       ` Matthew Wilcox
2002-02-17  6:15         ` Grant Grundler

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=20020215064352.86A404858@dsl2.external.hp.com \
    --to=grundler@dsl2.external.hp.com \
    --cc=bruno_vidal@hpfrcu03.france.hp.com \
    --cc=parisc-linux@lists.parisc-linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox