From: Helge Hafting <helge.hafting@aitel.hist.no>
To: Jeff Gold <jgold@mazunetworks.com>
Cc: Mark Lord <lkml@rtr.ca>, linux-kernel@vger.kernel.org
Subject: Re: Serial Console and Slow SCSI Disk Access?
Date: Tue, 20 Jun 2006 09:11:21 +0200 [thread overview]
Message-ID: <44979F99.1090807@aitel.hist.no> (raw)
In-Reply-To: <4496BF65.30108@mazunetworks.com>
Jeff Gold wrote:
> Helge Hafting wrote:
>> With nothing attached, any write to the serial device might go
>> through a lengthy timeout because of flow control. [...] But I can't
>> see why it'd make scsi disks slower. The scsi host adapter
>> initialization writes some messages of course, but there should be no
>> more console accesses during a hdparm test run.
>
> This makes sense to me. When I attach a serial cable and use that to
> login (I've got agetty running), hdparm produces no console messages
> that I can see using minicom. Still, the disk throughput is around
> 1.5 MB/sec for some reason. When I disable the serial console in
> grub.conf and reboot I get over 70 MB/sec again.
>
> A combination of out-of-tree patches (mainly network related but also
> one to disable PM_TIMERS) seem to eliminate the issue even with the
> serial console enabled, at least for the moment. That means I no
> longer have a problem, but the whole thing is mysterious to me.
I can see one possibility, that I didn't think of yesterday.
Do the scsi host adapter share its interrupt with the serial line?
(Boot a kernel that has the problem, and when scsi is slow, do a
cat /proc/interrupts
If the scsi and the serial driver share an interrupt, then that is the
source
of the problem.
Linux can share interrupts without big performance problems - IF both of
the hardware drivers are written with interrupt sharing in mind. Many
linux drivers are, but some are not. So check if interrupt sharing is
happening,
and if so, contact the maintainers of your scsi driver and your serial
port driver. Ask them if such sharing is ok or not. If you don't
understand the /proc/interrupt listing, just send it to the
maintainers so they can have a look.
Shared interrupts are to some extent set up by the bios, and to some
extent by linux. So different kernel versions (or booting with a different
set of drivers loaded, or a different distribution) may make a difference.
You can often get a pci device to use a different interrupt by moving it
to another slot. That tends to solve interrupt sharing problems. I assume
your scsi adapter is pci.
Helge Hafting
next prev parent reply other threads:[~2006-06-20 7:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-12 21:28 Serial Console and Slow SCSI Disk Access? Jeff Gold
2006-06-12 21:39 ` Mark Lord
2006-06-12 22:04 ` Jeff Gold
2006-06-19 6:50 ` Helge Hafting
2006-06-19 15:14 ` Jeff Gold
2006-06-20 7:11 ` Helge Hafting [this message]
2006-06-20 16:20 ` Jeff Gold
2006-06-22 0:32 ` David Lang
2006-06-22 16:18 ` Andrey Melnikoff
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=44979F99.1090807@aitel.hist.no \
--to=helge.hafting@aitel.hist.no \
--cc=jgold@mazunetworks.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@rtr.ca \
/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