public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Wilck <Martin.Wilck@fujitsu-siemens.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Mylex RAID & IA64 - processes sleeping in wait_on_buffer()/down()
Date: Fri, 10 Aug 2001 13:36:07 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590698805053@msgid-missing> (raw)

Hi Leonard, all,

I have run some more tests and have better debugging tools available
now (among other things, a Mylex debugging cable). I made two tests
yesterday and today with similar outcomes.

Yesterday for the first time ever I saw no driver error message before
the problems (hanging I/O) occured. Today a "NO SENSE ON WRITE" message
was issued approx. 15 minutes before the test came to a halt.

The serial console (debugging cable) showed the message
"UnimplCmd 0pc0H IqpC1H".

Here is the list of uninterruptibly sleeeping processes after the test
stopped (today's test):

$ ps -eo fname,pid,ppid,stat,state,nwchan,wchan | grep '\<D\>'
rm        3023  1136 D    D 4fa710 wait_on_buffer
rm        3036  1140 D    D 4fa710 wait_on_buffer
cp        3055  3054 D    D 45fc90 down
cp        3070  3069 D    D 45fc90 down
rm        3075  1139 D    D 45fc90 down
cp        3096  3095 D    D 45fc90 down

The stack trace for both processes 3023 and 3036 is
__wait_on_buffer - [lock_buffer] - unmap_buffer - block_flushpage -
truncate_list_pages - truncate_inode_pages - iput - d_delete - vfs_unlink
- sys_unlink.

Obviously these processes wait forever for a buffer head to get unlocked.

The other processes sleep on a the semaphore of the indode of an dentry
(dentry->d_inode->i_sem). These semaphores are most likely blocked by
either PID 3023 or 3036.

Upon further inquiry into the DAC960 code, I found that the driver uses
virt_to_bus() to get DMA addresses, which is deprecated on 64 bit
architectures (comments in asm-ia64/io.h recommend to use
pci_map_single()/pci_unmap_single() instead).

I suspect that this may have
something to do with the problems we are encountering, although
pci_map_single() basically calls virt_to_phys() if a controller is
capable of 64 bit addressing. A difference can be seen in
pci_unmap_single(), where the buffer pages are marked clean after the DMA
is processed. Although it makes not much sense that this should cause
problems as those described above, it is at least a starting point.
It would be interesting to know in this regard if it is planned to use the
pci map interface for the DAC960 driver in the not-so-far future.

Regards,
Martin

-- 
Martin Wilck     <Martin.Wilck@fujitsu-siemens.com>
FSC EP PS DS1, Paderborn      Tel. +49 5251 8 15113






                 reply	other threads:[~2001-08-10 13:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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-105590698805053@msgid-missing \
    --to=martin.wilck@fujitsu-siemens.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox