From: Thomas Fjellstrom <tfjellstrom@shaw.ca>
To: linux-kernel@vger.kernel.org
Subject: Re: Limiting DMA speeds for individual IDE drives
Date: Wed, 9 Sep 2009 00:46:06 -0600 [thread overview]
Message-ID: <200909090046.06707.tfjellstrom@shaw.ca> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0909081409040.2653-100000@iolanthe.rowland.org>
On Tue September 8 2009, Alan Stern wrote:
> On Tue, 8 Sep 2009, Alan Cox wrote:
> > > I've got a situation where a drive claims to be capable of supporting
> > > UDMA/100, but it's in a noisy environment and gets lots of errors at
> > > that speed. I'd like to limit it to UDMA/66 or even UDMA/33.
> >
> > That should never occur with a proper cable and I would be concerned the
> > fault might be something more problematic such as speed misconfiguration
> > or an incompatibility. Which driver is in use ?
>
> The cable indeed is likely to be at fault. The same drive worked okay
> at the higher speed with a different cable (which unfortunately is
> unavailable for use in the final deployment). This is using the old
> IDE driver. Here's an extract from the log, with
> ide-core.ignore_cable=0 specified on the command line:
>
I have just one suggestion. Get a new cable.
> Linux version 2.6.27-gentoo-r10 (root@raise) (gcc version 4.1.2 (Gentoo
> 4.1.2 p1.0.2)) #1 SMP PREEMPT Tue Apr 21 15:06:03 UTC 2009 ...
> Uniform Multi-Platform E-IDE driver
> piix 0000:00:1f.1: IDE controller (0x8086:0x24cb rev 0x02)
> pci 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> piix 0000:00:1f.1: IDE port disabled
> piix 0000:00:1f.1: not 100% native mode: will probe irqs later
> ide: ignoring cable detection for ide0
> ide0: BM-DMA at 0xf000-0xf007
> Probing IDE interface ide0...
> hda: STEC MACH-8 SSD, ATA DISK drive
> hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> hda: UDMA/100 mode selected
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide_generic: please use "probe_mask=0x3f" module parameter for probing all
> legacy ISA IDE ports ide_generic: I/O resource 0x1F0-0x1F7 not free.
> ide_generic: I/O resource 0x170-0x177 not free.
> hda: max request size: 512KiB
> hda: 60789456 sectors (31124 MB), CHS=16383/255/63
> hda: cache flushes not supported
> hda: hda1 hda2 hda3
> ...
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0xc4 { DriveStatusError BadCRC UncorrectableError },
> LBAsect=14823116, sector=14823116 ide: failed opcode was: unknown
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0xc4 { DriveStatusError BadCRC UncorrectableError },
> LBAsect=15133492, sector=15133492 ide: failed opcode was: unknown
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0xc4 { DriveStatusError BadCRC UncorrectableError },
> LBAsect=9478100, sector=9478100 ide: failed opcode was: unknown
> Etc.; you get the idea...
>
> > > The hdparm command should be able to do this but I can't run it until
> > > the system has booted, by which time a bunch of CRC and possibly other
> > > errors have already occurred. Ideally it should be possible to limit
> >
> > Only the data transfers are CRC protected and at high speed, but noise at
> > low speed would be a real concern as the commands are sent low speed but
> > without protection on PATA devices - so a bit flip can send a DMA to the
> > wrong sector.
> >
> > > the speed starting as early as device detection, but I can't find any
> > > way to do it. Is there support for such a thing or will I have to hack
> > > it in?
> >
> > You can disallow DMA but not clip DMA to UDMA33 with the old driver. You
> > could disallow DMA at boot and reallow it with a speed set by hdparm in
> > your boot scripts...
>
> On Tue, 8 Sep 2009, Frederik Deweerdt wrote:
> > Does passing ide=nodma at bootime, and then having init set the DMA at
> > the right speed, would work?
>
> I'll recommend trying that out. Thanks to both of you for the advice.
>
> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Thomas Fjellstrom
tfjellstrom@shaw.ca
prev parent reply other threads:[~2009-09-09 6:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-08 16:03 Limiting DMA speeds for individual IDE drives Alan Stern
2009-09-08 16:24 ` Frederik Deweerdt
2009-09-08 18:04 ` Sergei Shtylyov
2009-09-08 17:53 ` Alan Cox
2009-09-08 18:18 ` Alan Stern
2009-09-09 6:46 ` Thomas Fjellstrom [this message]
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=200909090046.06707.tfjellstrom@shaw.ca \
--to=tfjellstrom@shaw.ca \
--cc=linux-kernel@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.