> afaik, my computer crashed because the chipset on my board (MVP3) is
> flakey for non-UDMA to UDMA transfers (Dan spoke of his cdrom drive, I
> have two 1-gig non-UDMA and a 17.2 gig UDMA).
>
> >
> > hdparm -c 3 -t -d1 -X34 /dev/hda
> >
No, the problem is that there is not code to allow for setfeature options
called via hdparm to tiddle with pci-chipset transfer speeds.
I gather that Intel based boards have more flexiblity on allowing XFER
rates to be changed without harming the system.
> My guess is that the specified 'X34' flag you enabled was either
> not-supported by the drive (from man page):
Modern IDE-pci chipsets now have definable values in the pci-config space
to max transfer rates. If the transfer rates are tinkered with the
corallary applies to the chipset.
> Apart from that, use of this flag
> is seldom necessary since most/all modern IDE
> drives default to their fastest PIO transfer mode
> at power-on.
>
> So you may not support multiword DMA mode2 transfers. What type of
> chipset is on your motherboard?
Very unlikely, only Single Word DMA transfers have been retired.
> Here's the big question (for Andre especially). In your uniform ide patch
> you state:
>
> Since ali15x3.c, via82c586.c, or piix.c do not have (U)DMA setup code
> started or ready for testing, if your BIOS fails to perform its task
> correctly, there is not help yet.
>
> So am I right in saying that my bios is not initializing my (probably
> via82c56) chip properly and thus will not work properly with UDMA enabled?
> So there is no hope (yet) for me or for Nick?
Bang!!!!!!! You nailed that one perfectly in both cases (as of today).
Look at how nasty and harsh the chipset code for tuning the Promise
Ultra33/66 cards are in "./drivers/block/pdc202xx.c". This will give you
the idea of how hard it is to get this task done correctly at init time.
As for down/upgrading xfer rates after boot is not even considered to
date.
I just now took the risk of putting theory in to practice with the
Ultra33, understand that only the first card has a physical BIOS chip
installed. The second two are fakes that the cards are reporting;
however, the second card does share the BIOS data from the first card.
This data is generally wrong.............whereas the third card is solely
configured by the linux driver.
May 9 21:30:09 Orion kernel:
Uniform Multi-Platform E-IDE driver Revision: 6.19
PDC20246: IDE controller on PCI bus 00 dev a0
PDC20246: not 100% native mode: will probe irqs later
PDC20246: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
PDC20246: ROM enabled at 0xfebd0000
ide0: BM-DMA at 0xef80-0xef87, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xef88-0xef8f, BIOS settings: hdc:pio, hdd:pio
PDC20246: IDE controller on PCI bus 00 dev 98
PDC20246: not 100% native mode: will probe irqs later
PDC20246: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
PDC20246: ROM enabled at 0xfebc0000
ide2: BM-DMA at 0xef40-0xef47, BIOS settings: hde:DMA, hdf:DMA
ide3: BM-DMA at 0xef48-0xef4f, BIOS settings: hdg:pio, hdh:DMA
PDC20246: IDE controller on PCI bus 00 dev 90
PDC20246: not 100% native mode: will probe irqs later
PDC20246: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode.
PDC20246: ROM enabled at 0xfebb0000
ide4: BM-DMA at 0xef00-0xef07, BIOS settings: hdi:DMA, hdj:pio
ide4: FORCING BURST BIT 0x00 -> 0x01 ACTIVE
ide5: BM-DMA at 0xef08-0xef0f, BIOS settings: hdk:pio, hdl:pio
> And my second question to anyone who will answer: Can I disable UDMA but
> leave DMA enabled? Sounds like a hdparm parameter but the -X stuff deals
> with PIO modes and I don't know what I'd set to leave DMA w/o UDMA
> enabled.
If we are limiting the discussion to Intel chipsets, Artop AEC6210UF
or an other that allow for AUTO speed, you may have options.
If you call "-X stuff" on a code tuned Promise card that the BIOS failed
and Linux had to force imposed configurations, expect a KABOOM!!!!!!!
The most that I will give a pass on is the "-d stuff".
You can turn DMA(general) on/off, but setfeatures are off limits.
The current piix.c code does basic PIO tuning, but DMA configs are still a
WIP. I have the means to test this and make it work with PIIX3/4 but
PIIXa/b are S.O.L. for now............
I am finding myself agreeing more and more with M.L. and G.O. about the
concept of active tuning of IDE-PCI junk.........It is getting harder and
harder to derive code that is my goal for a true "uniform-ide-X.yy"
driver. Understand that SuperSocket 7 is the absolute pain of the
concept. In many cases, venders of SS7 with crummy BIOS code writers
bring fear that forcing a setup override via imperical data could cause
future problems.
In the past, the IDE-driver relied on BIOS setup that worked well.
Now there are so many reported cases of BIOS setup failures that is is
scary. I would contribute this problem to the "miniport" interface that
MS uses to setup devices via a plug-in or something......again we suffer
at the fingers of Gates..............
Andre Hedrick
The Linux IDE guy
Candidate for pre-patch-2.2.8-series or pre-patch-2.2.9-series
http://www.dyer.vanderbilt.edu/server/udma/
2.2.7.uniform-ide-6.19.golf.patch.gz
http://www.dyer.vanderbilt.edu/server/udma/2.2.7.uniform-ide-6.19.patch.gz
http://www.dyer.vanderbilt.edu/server/udma/ide.2.0.37pre11+pat7.gz
http://www.dyer.vanderbilt.edu/server/udma/hdparm-3.5i.patch.gz
APC UPS Daemon Support Center.
http://www.brisse.dk/site/apcupsd/
GPLed source on April 7, 1999
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/