All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stuart_Hayes@Dell.com
To: linux-ide@vger.kernel.org
Subject: losing time -- unmaskirq question
Date: Fri, 10 Oct 2003 10:36:40 -0500	[thread overview]
Message-ID: <CE41BFEF2481C246A8DE0D2B4DBACF4F128A2A@ausx2kmpc106.aus.amer.dell.com> (raw)


I have a system that loses time when running CD-ROM stress (i.e., the system
clock runs too slowly).  This CD-ROM is in the DMA blacklist, so it is
running in PIO mode, and this system has a single, non-hyperthreading CPU.
It will lose about 20 minutes in 12 hours, if I leave it running CD-ROM
stress.

I have found that the problem is that the IDE driver leaves local interrupts
disabled for the duration of the interrupt handler, which includes the data
transfer, since the drive is in PIO mode.  I've seen this take around 10ms.
Since there is only one CPU in this system, this causes timer ticks to be
lost, since local interrupts are disabled for 10ms, and there are no other
CPUs to take the interrupt.

Turning on the unmaskirq setting with "hdparm -u1 /dev/hda" (this sets the
variable drive->unmask to a non-zero value) seems to fix the problem--this
causes the IDE driver to enable local interrupts before calling the ide-cd
specific interrupt handler (which does the actual data transfer)... which
allows the timer tick interrupt to be handled in the middle of a PIO data
transfer.

I would guess that this is a problem with *any* IDE device that's running in
PIO mode on a uniprocessor system.  I can see from the code that there are
some cases where people have found problems with unmaskirq enabled, but
these sound like bugs with particular hardware, not an architectural
problem.

Does anyone know of any reason why unmaskirq (drive->unmask) should not be
set by default?

Thanks,
Stuart
stuart_hayes@dell.com


                 reply	other threads:[~2003-10-10 15:37 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=CE41BFEF2481C246A8DE0D2B4DBACF4F128A2A@ausx2kmpc106.aus.amer.dell.com \
    --to=stuart_hayes@dell.com \
    --cc=linux-ide@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.