Re: [Dvdrtools-users] Re: ATA, IDE, device, controller and other concepts -- WAS: Is my MSI DR8-A2 broken?

[Bryan J. Smith]

On Fri, 2006-01-20 at 01:54 +1030, John wrote:
> actually it WAS a bad VIA controller, and well known to be so...
> eventually

ViA has had several ATA controllers that haven't followed ATA specs,
especially early on.  The 596 and 686 southbridge chips had many issues
under Linux due to the fact that ViA did not write the driver like they
did on Windows, and could accommodate all its quirks/non-standard
features.

> sorry, but i think that is oversimplifying it. Sure an ATA controller 
> is not a dual-core 64 bit cpu. But its more complex than a dumb 
> set of wires.

It's little more than a bus arbitrator.
There's some registers, signaling, etc...

The "intelligence" is on the hard drive.
The hard drive itself is what actually handles the DMA transfer.

> this contradicts your very next statement... :

No it doesn't.  If the bus arbitrator (ATA controller) is improperly
configured, then the IDE-to-PCI DMA doesn't occur correctly.

The bus arbitrator doesn't need to be intelligent, but it _does_ have to
be setup correctly to arbitrate the DMA transfer between the IDE of the
ATA device and the PCI connection to system memory.

Before DMA, things were PIO, handled largely by the CPU's intelligence.

With DMA, you have so many factors involved.  The driver must command
the ATA device's IDE correctly as well as the ATA bus arbitrator.
Virtually _every_ single ATA device and ATA controller _varies_ from the
ATA spec.

Registers on the controller are different, commands aren't complete,
etc...  The OS driver must accommodate these.  ViA writes its Windows
drivers as such, but isn't good about sharing that information with the
Linux community.

> Thats right. Thats what VIAs drivers were doing wrong.

Written not by ViA.  When ViA wrote the Windows drivers, they could
handle all those non-standard features and quirks in their design.  The
Linux gurus only have the ATA specs to go on and the limited information
they can get from ViA.

This is why I avoid ViA, especially since they change their ATA design
so regularly.

> yes exactly. i saw every piece of timing code completely rewritten
> between one version of their driver and the next. One value one 
> time, a different value the next... and both values correct?? 
> More likely both were wrong.

Yeah, it's hard to be exact when the vendor isn't cooperating.

> VIA said that VIA wrote it. Sure they hoard their specifications.
> They dont have to hoard their driver source code, its worthless.
> its probably pre-processed, to turn their nice constants and 
> macros into inline code, but, its still all rubbish in my opinion.

I didn't know ViA was writing the ATA drivers in the kernel.  If so,
then that should make things better you'd figure.

> I'll look it up later. It was well known. I am talking about their 
> windows drivers here, not linux. For a while, they had to run 
> PIO on many devices, eg burners in particular i believe, or 
> corruption would ensue. it was pathetic

Oh, yes, nVidia _did_ have some issues with their Windows drivers.

> I would much rather rely on the information that Intel puts out
> about their controllers, than VIA

Intel is far more forward with their specifications and assists the
Linux team.

> i'll have a look into this before i shoot my mouth off :)

Actually, most of the issues I had were ICH3 and earlier, after the
excellent and well understood PIIX series.

It seems as of the ICH3, Intel started helping.

> So the hardware logic is proven. That doesnt mean that the retarded 
> fools who write drivers for nvidia and VIA, and SiS, wont one day put out 
> rubbish drivers that corrupt every byte that passes through them

ViA changes things all-the-time, which requires changes to the drivers.
Why?  I have no idea.

nVidia and SiS seem to use the same, base command set and registers with
every new version.  That means no new guessing games.

> the *only* difference???!!!!! Well, if there was only one difference, 
> and i could pick what i wanted it to be, that would probably be the 
> one i'd choose.
> Saying that is the "only" difference is like saying the only difference 
> between good and bad, is that good is... ummm good... and bad is not.


> why should i do that? i wouldnt trust VIA drivers on windows 
> more than i would on linux. Even nvidia screwed things up on 
> windows for a while.

I haven't had problems with nVidia in a good 2 years.  Give them a
break, they just got into the chipset business 4 years ago.

Even "more recent to the chipset scene" ATI has it's problems with its
southbridge peripherals, so much so that most people are opting for the
ULi southbridge with ATI's solution.

> Why not just use an intel controller with drivers written by people
> who know what the hell they are doing.



> Personally, i would trust some 3ware controller, with an embedded OS
> less than I would an intel controller on linux. I thought you said
> these controllers were stupid... why do they need an entire embedded
> OS when theyre stuck on a card?

WHOA!!!  HOLD ON A SECOND!!!

A 3Ware Escalade is *NOT* a "dumb" ATA controller.  It does _not_ have
just a single chip with some wires, registers, basic control logic and
signaling.

It is an _intelligent_ caching storage switch (7000/8000/9500S) or
caching+buffering storage controller (9550SX).  It has a 64-bit ASIC
(7000/8000/9500S) or 64-bit ASIC + 32-bit PowerPC 400 (9550SX) with
1-4MB SRAM (all) and 128+MB DRAM (9550SX)!

Yes, behind it is "dumb" ATA controllers -- several of them.  But they
are being driven by the on-board logic of the ASIC or ASIC+PPC.  *1*
vendor for _both_ the ATA controllers and the software that drives it,
driven by it's own on-board intelligence.

Yes, it's _very_ideal_!

Furthermore, 3Ware can sign NDAs and gain access to how various IDEs of
hard drives from Hitachi, Maxtor, Seagate, etc... work.  That's why they
are extremely ideal!

In the "dumb" ATA setup, you've gotta have an OS driver that handles all
the quirks of the ATA + device combination.  In the 3Ware solution, the
same vendor creates both the OS and ATA, and can sign NDAs with hard
drive vendors on the ATA devices.

3Ware cards are _not_ just ATA controllers.  They are much more!

> Plus, that would use up the bandwidth on one of my pci channels.

Of course.

> i trust linux more than dodgy small-company firmware and proprietary 
> embedded OSes.

Ummm, AMCC is _the_ vendor for PowerPC 400 products.
IBM sold that division to them (they are _not_ a small company).

> Im sure those cards did have their uses though,
> but i dont think i would use one now, unless i had more $$ and more 
> curiosity than i have at the moment :)
> If device vendors cant get their ATA devices to work with an Intel 
> controller, they will fix their device so it does, or tell intel where their
> controller/driver software is deficient, and intel will fix the controller
> or its driver

And since when have all ATA vendors agreed?  He he, he he he.  ;->

> If LG finds their device doesnt work with a VIA controller, why would 
> they care when VIA dont? VIA chips are not used by companies 
> who demand reliability. Theyre used by ignorant consumers who 
> have virus-ridden pcs that dont have an uptime of more than 
> 3 hours, and whose hard disks are re-formatted every 2 weeks.

Hey, you're arguing Intel v. ViA -- I _agree_ with you.

> ok. thats a bit of a bummer
> hmmkay, thats interesting

Interesting that people don't know how CD-R/DVD-R discs are physically
recorded, let alone how CD-RW/DVD-RW _differ_?

There is a reason why they tell you that -RW is _not_ as compatible as -
R when you "record" -- because it's in -R "emulation" mode.  -RW is
physically different than -R.

> 33? these drives are 66 now, cmon.

I've seen many vendors who haven't jumped.

LG seems to be one that is still only UltraDMA mode 2 (8MHz DDR @ 16-bit
= 33MBps).

My older Matsushita/Panasonic drives are actually UltraDMA mode 4 (16MHz
DDR @ 16-bit = 66MBps).

> at 12x which is all these drives will burn normal media at,

I'm using 16x -- have been for 2 years.
Sure, I'm not at 16x when I start, but I am near when I finish.

> thats only 15MB/sec, which is only 25% of the 66
> BTW, i thought 66 MHz ATA bus was 16 bits wide so bandwidth 
> should be 133 MB/sec, but this seems to not be the case.

UltraDMA mode 2 (Ultra33) is 8MHz DDR (16MHz eff) at 16-bit = 33MBps
UltraDMA mode 4 (Ultra66) is 16MHz DDR (33MHz eff) at 16-bit = 66MBps

The signaling of the original UltraDMA modes were done so they _matched_
previous PIO and SDMA/MDMA modes -- the 8MHz signaling (or fractions
thereof for slower modes) of the 16-bit PC/AT bus and the original
Enhanced Systems Disk Interface (ESDI) which is the original Integrated
Drive Electronics (IDE).

I haven't researched mode 5 (Ultra100) or mode 6 (Ultra133) to see if
they are DDR or QDR.

> Pathetic.

Why?  So many people think ATA is like SCSI, it's _not_.
Just like they think USB is like FireWire, it's _not_.

> I havent seen any 16x media her in australia, though i havent
> looked too hard. Im happy with my LG now, and the 8x Verbatim disks
> that it will burn at 12x

I've been buying 16x media for over a good year.
It's been damn expensive until the last 6 months.

> these things cant be running at 33MHz still

They are _not_.  They are running at 33MBps or 66MBps which are 8MHz DDR
(16MHz effective) and 16MHz DDR (33MHz effective), respectively.

> wellive been using the burner on its own channel too for quite a while
> now and yes, it definitely does help. I just still cant quite understand 
> why performance was so bad with 2 devices.

Sigh, because ATA is _not_ SCSI.  It does _not_ support multiple
devices, device-to-device transfers and device disconnects.

If you transfer from one device to another in ATA (or USB for that
matter), it travels all the way to memory then back to the bus.  In SCSI
(or FireWire for that matter), the transfer can occur directly device-
to-device.

Furthermore, you _must_ either "reset" the bus if two devices _differ_
on what modes they support *OR* set the bus to the "common denominator"
of both.  In either case, you're going to get a _lot_ of overhead.

> I mean, obviously, as you have said, these buses just werent designed
> for 2 devices.

Not in DMA mode, no.

The problem is that most ATA devices also do PIO.  And there were
several vendor PIO implementations that allowed the master/slave setup.
The original IDE in ESDI did _not_.

That's why Serial ATA, which is _exactly_ the same as ATA (except at the
PHY), _always_ works in DMA, so they were designed to allow only *1*
device per channel.  The spec wanted to avoid this issue once and for
all.

> It should be a more widely known fact, if performance of 2 devices on
> these buses is so poor.

Actually, it's pretty _widely_ known -- especially when you have a fast
ATA and a slow ATAPI device on the same bus, but any 2 devices.

ATA is _not_ SCSI.

> But I refuse to believe these burners are slowing the bus down to 33 MHz

hdparam -i /dev/hdX

The "asterik" next to the mode tells you the current, active mode.

E.g., on my LA GSA-4167B ...

  # hdparm -i /dev/hda

  /dev/hda:

   Model=HL-DT-ST DVDRAM GSA-4167B, FwRev=DL12, SerialNo=072720C4D39F
   Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
   RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
   BuffType=unknown, BuffSize=0kB, MaxMultSect=0
   (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
   IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
   PIO modes:  pio0 pio3 pio4
   DMA modes:  mdma0 mdma1 mdma2
   UDMA modes: udma0 udma1 *udma2
   AdvancedPM=no
   Drive conforms to: device does not report version:
   * signifies the current active mode

If you have *2* drives on the _same_ bus, they will either:  
  A)  Match on current, active mode
  B)  Differ on current, active mode

"A" reduces the number of bus resets and overhead at the expense of
slowing down the faster drive.  "B" will result in massive overhead when
you need to write to the slave device.

There is _no_ ATA standard for DMA when switching the bus around for
multiple devices.  Vendors implement it _differently_!  Typically the
"master" device handles the bus, but I've also seen some weird setups
where the "slave" caused a lot of issues.

> Sure, an old cdrom or dvd drive would, but im sure even the 
> pioneer 106 was ATA66 Still, nothing will help a pioneer burn +R
> sorry to be argumentative, especially from my position of relative 
> ignorance hehehe :)

I just know what I know from experience and looking at the code, as well
as talking to various kernel ATA maintainers.


-- 
Bryan J. Smith   mailto:address@hidden
http://thebs413.blogspot.com
------------------------------------------
Some things (or athletes) money can't buy.
For everything else there's "ManningCard."