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