From: Shawn Starr <Shawn.Starr@Home.net>
To: dilinger@mp3revolution.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: piix.c and tuning question
Date: Wed, 14 Feb 2001 02:51:03 -0500 [thread overview]
Message-ID: <3A8A38E7.569FD70E@Home.net> (raw)
In-Reply-To: <20010214023538.A26558@incandescent.mp3revolution.net>
hmmm this is my chipset:
Which motherboard do you have?
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
i've had irq timeouts but they were due to a slow CD-ROM causing the two DMA drives to timeout (don't
know why).
ive never seen ide_dmaproc though.
This is my following hdparm config
hdparm -d 1 -X34 -u1 -k 1 /dev/hdb
hdparm -d 1 -X34 -u1 -k 1 /dev/hda
for both drives, one of them us a UDMA66 but this Pentium 200Mhz cant do UDMA even ;/
I have a AP53/AX AcerOpen Motherboard.
Shawn.
dilinger@mp3revolution.net wrote:
> I have a box w/ the following controllers:
>
> 00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03)
> 00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
> 00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
>
> I regularly see the following, during high i/o:
>
> Feb 14 02:15:27 inkbay kernel: hdd: timeout waiting for DMA
> Feb 14 02:15:27 inkbay kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> Feb 14 02:15:27 inkbay kernel: hdd: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> Feb 14 02:21:13 inkbay kernel: hdc: DMA disabled
> Feb 14 02:21:13 inkbay kernel: hdd: DMA disabled
> Feb 14 02:21:22 inkbay kernel: hdd: timeout waiting for DMA
> Feb 14 02:21:22 inkbay kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> Feb 14 02:21:22 inkbay kernel: hdd: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
>
> (the DMA being disabled was me manually doing an hdparm -d0)
>
> According to Documentation/Configure.help:
>
> Intel PIIXn chipsets support
> CONFIG_BLK_DEV_PIIX
> This driver adds PIO mode setting and tuning for all PIIX IDE
> controllers by Intel. Since the BIOS can sometimes improperly tune
> PIO 0-4 mode settings, this allows dynamic tuning of the chipset
> via the standard end-user tool 'hdparm'.
>
> Please read the comments at the top of drivers/ide/piix.c.
>
> If you say Y here, you should also say Y to "PIIXn Tuning support",
> below.
>
> If unsure, say N.
>
> PIIXn Tuning support
> CONFIG_PIIX_TUNING
> This driver extension adds DMA mode setting and tuning for all PIIX
> IDE controllers by Intel. Since the BIOS can sometimes improperly
> set up the device/adapter combination and speed limits, it has
> become a necessity to back/forward speed devices as needed.
>
> Case 430HX/440FX PIIX3 need speed limits to reduce UDMA to DMA mode
> 2 if the BIOS can not perform this task at initialization.
>
> If unsure, say N.
>
> Obviously, the BIOS is not performing the DMA mode reduction, and must
> be done maually. However, that's about all the information I can gather
> about this problem. Has anyone looked at the top of piix.c (other than
> the IDE maintainer, that is)? It's quite cryptic:
> * | PIO 4 | MW2 | e3 | a3 | b | piix_tune_drive(drive, 4);
> *
> * sitre = word40 & 0x4000; primary
> * sitre = word42 & 0x4000; secondary
> *
> * 44 8421|8421 hdd|hdb
> *
> * 48 8421 hdd|hdc|hdb|hda udma enabled
> *
> * 0001 hda
> Wtf is a sitre? What are these odd numbers? And where is any useful
> info that, as a piix driver _user_, I might be able to use? Is it
> merely DMA which I want to tune, or do I want to mess w/ PIO modes
> (marked as dangerous in hdparm) as well?
>
> --
> "... being a Linux user is sort of like living in a house inhabited
> by a large family of carpenters and architects. Every morning when
> you wake up, the house is a little different. Maybe there is a new
> turret, or some walls have moved. Or perhaps someone has temporarily
> removed the floor under your bed." - Unix for Dummies, 2nd Edition
> -- found in the .sig of Rob Riggs, rriggs@tesser.com
> -
> 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/
next prev parent reply other threads:[~2001-02-14 7:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-14 7:35 piix.c and tuning question dilinger
2001-02-14 7:51 ` Shawn Starr [this message]
2001-02-14 21:39 ` dilinger
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=3A8A38E7.569FD70E@Home.net \
--to=shawn.starr@home.net \
--cc=dilinger@mp3revolution.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox