[preview] Latest AMD & VIA IDE drivers with UDMA100 support

[preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Alan Chandler]

on Fri Jan 19 2001 - 10:56:10 EST Vojtech Pavlik (vojtech@suse.cz)
wrote
> ...
>I'm sending you (and others who might be interested) my latest VIA and 
>IDE drivers. The VIA driver (v3.15) should have a complete support for 
>UDMA100 on the vt82c686b chip, the AMD driver (v1.5) should have full 
>UDMA100 support on the amd766 ViperPlus chip. 
>
>
>They're also a little more foolproof with respect to the 'idebus' 
>setting, which is quite a misnomer, btw. 
>
>
>Care to try them out? 

If by "trying them out" you mean dropping them in the drivers/ide
subdirectory of the 2.4.0 source and rebuilding the kernel, then they
still cause my machine to give CRC errors.

I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM
deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only
do UDMA mode 2. I am not overclocking or anything - all should be
running at default speeds with an Athlon 900.  

Just to be clear - I am NOT getting any errors when I switch back to
the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur
every few minutes when there is significant disk activity. 



Alan

alan@chandlerfamily.org.uk
http://www.chandler.u-net.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Alan Chandler]

On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote:

>On Sat, 20 Jan 2001, Alan Chandler wrote:
>
>> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM
>> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only
>> do UDMA mode 2. I am not overclocking or anything - all should be
>> running at default speeds with an Athlon 900.  
>> 
>> Just to be clear - I am NOT getting any errors when I switch back to
>> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur
>> every few minutes when there is significant disk activity. 
>
>But that kernel uses the stock driver that was the original second
>generation correct?
>
>Andre Hedrick
>Linux ATA Development
>

Sorry, I realise now what I said was ambiguous.  To be clear

2.2.17 - absolutely standard as shipped in debian - no errors
2.4.0 - standard (downloaded tar.bz2) - ERRORS
2.4.0 - as standard except for three files in tar.bz2 attachment to
Vojtech Pavlik's mail which were placed in drivers/ide directory -
ERRORS. 
Alan

alan@chandlerfamily.org.uk
http://www.chandler.u-net.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

On Sat, Jan 20, 2001 at 06:45:10PM +0000, Alan Chandler wrote:
> On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote:
> 
> >On Sat, 20 Jan 2001, Alan Chandler wrote:
> >
> >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM
> >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only
> >> do UDMA mode 2. I am not overclocking or anything - all should be
> >> running at default speeds with an Athlon 900.  
> >> 
> >> Just to be clear - I am NOT getting any errors when I switch back to
> >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur
> >> every few minutes when there is significant disk activity. 
> >
> >But that kernel uses the stock driver that was the original second
> >generation correct?
> >
> >Andre Hedrick
> >Linux ATA Development
> >
> 
> Sorry, I realise now what I said was ambiguous.  To be clear
> 
> 2.2.17 - absolutely standard as shipped in debian - no errors
> 2.4.0 - standard (downloaded tar.bz2) - ERRORS
> 2.4.0 - as standard except for three files in tar.bz2 attachment to
> Vojtech Pavlik's mail which were placed in drivers/ide directory -
> ERRORS. 
> Alan

Wonderful! A case where I can compare a working setup with a nonworking
one! :) Could you please send me the usual stuff (dmesg, lspci -vvxxx,
cat /proc/ide/via, hdparm -i /dev/hd*, hdparm -t /dev/hd*) for both the
2.2 case and the 2.4.0+VIA-latest case? That'll allow me to find the
differences and possibly fix the new driver.

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Andre Hedrick]

On Sat, 20 Jan 2001, Vojtech Pavlik wrote:

> On Sat, Jan 20, 2001 at 06:45:10PM +0000, Alan Chandler wrote:
> > On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote:
> > 
> > >On Sat, 20 Jan 2001, Alan Chandler wrote:
> > >
> > >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM
> > >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only
> > >> do UDMA mode 2. I am not overclocking or anything - all should be
> > >> running at default speeds with an Athlon 900.  
> > >> 
> > >> Just to be clear - I am NOT getting any errors when I switch back to
> > >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur
> > >> every few minutes when there is significant disk activity. 
> > >
> > >But that kernel uses the stock driver that was the original second
> > >generation correct?
> > >
> > >Andre Hedrick
> > >Linux ATA Development
> > >
> > 
> > Sorry, I realise now what I said was ambiguous.  To be clear
> > 
> > 2.2.17 - absolutely standard as shipped in debian - no errors

This is with the original ide.2.2.17.??.date.patch and not the morfing
timing code you have started.

> > 2.4.0 - standard (downloaded tar.bz2) - ERRORS
> > 2.4.0 - as standard except for three files in tar.bz2 attachment to
> > Vojtech Pavlik's mail which were placed in drivers/ide directory -
> > ERRORS. 
> > Alan
> 
> Wonderful! A case where I can compare a working setup with a nonworking
> one! :) Could you please send me the usual stuff (dmesg, lspci -vvxxx,
> cat /proc/ide/via, hdparm -i /dev/hd*, hdparm -t /dev/hd*) for both the
> 2.2 case and the 2.4.0+VIA-latest case? That'll allow me to find the
> differences and possibly fix the new driver.

Vojtech, I worry that the dynamic timing that you are calculating could
bite you.  Timings are exact especially at modes 3/4/5 the margins go to
an effective zero for varition or wiggle room.  The state diagrams from
Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it
constrained.  You need to assume absolutes because the various board
makers screw up the skew tables by the PCB lane traces.

By assuming only absolutes, all vendors that do bad designs will show and
the user can not and "should" not be allowed to hold the driver in a state
that can damage filesystems or lock the box.  Since I have never addressed
this issue in public it is no obvious why I hardcoded timings and did not
let tehm float, but I hope it is clearer now.

chipset ---\
            |
            \---------IDC-header

chipset ---+
           |
           +----------IDC-header

These are nearly the same but the corners cause bounce and iCRC's

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Alan Chandler]

On Sat, 20 Jan 2001 14:57:07 -0800 (PST), Andre Hedrick wrote:

...
>
>Vojtech, I worry that the dynamic timing that you are calculating could
>bite you.  Timings are exact especially at modes 3/4/5 the margins go to
>an effective zero for varition or wiggle room.  The state diagrams from
>Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it
>constrained.  You need to assume absolutes because the various board
>makers screw up the skew tables by the PCB lane traces.
>

I am not sure this is just a question of small variations.  The hdparm
-t differences between these two versions is quite significant.  This
evidence would imply that the two approaches are making fundemental
different decisions about what my hardware can do!

Under 2.2.17

/dev/hda:
 Timing buffered disk reads:  64 MB in 21.86 seconds =  2.93 MB/sec

/dev/hdc:
 Timing buffered disk reads:  64 MB in 20.81 seconds =  3.08 MB/sec

Under 2.4.0

/dev/hda:
 Timing buffered disk reads:  64 MB in  6.58 seconds =  9.73 MB/sec

/dev/hdc:
 Timing buffered disk reads:  64 MB in  6.59 seconds =  9.71 MB/sec

Alan

alan@chandlerfamily.org.uk
http://www.chandler.u-net.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Alan Chandler]

On Sat, 20 Jan 2001 20:18:34 -0500 (EST), you wrote:


>that's not the topic: Andre's talking about pci-clock-based timing
>constants the the driver programs into the ide controller - a matter
>of an extra few/more nanoseconds.

I know, but when looking hard for a problem in one place and not
finding it, it is sometimes helpful to consider other options.

I am getting errors under 2.4.0 which didn't appear in 2.2.17 - and as
far as I could see from hdparm - both were at UDMA mode 2 (I assume
thats what the * means - the man page wasn't very clear).  My drives
only handle up to this mode, and I was wondering if the new driver was
trying to run them at a mode higher than they were supposed to go.

This massive difference in timing  seemed significant.
>
>quite slow in either case, at least for modern hardware (which is 
>all in the 20-40 MB/s range).  this looks like a PIO vs DMA difference
>to me, not even UDMA.  of course, hdparm can tell you what mode you're in.
>

I did discover a difference - 2.2.17 set the drives with multisector
off, 2.4.0 was setting multisector on.  However, I have redone the
timing with multisector turned on in the 2.2.17 case and the
difference is still there.

Under 2.2.17 with multisector turned on


/dev/hda:

 Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
 BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
MultSect=16
 DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
 tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
mword2 
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4 
 UDMA modes: mode0 mode1 *mode2 

------------------

/dev/hda:
 Timing buffered disk reads:  64 MB in 19.88 seconds =  3.22 MB/sec


Under 2.4.0


/dev/hda:

 Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
 BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
MultSect=16
 DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
 tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
mword2 
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4 
 UDMA modes: mode0 mode1 *mode2 

------------------

/dev/hda:
 Timing buffered disk reads:  64 MB in  6.58 seconds =  9.73 MB/sec



I don't suppose the fact that my hdparm is oldish (3.6 I think) have
any bearing on this?
Alan

alan@chandlerfamily.org.uk
http://www.chandler.u-net.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

On Sun, Jan 21, 2001 at 10:51:12AM +0000, Alan Chandler wrote:
> On Sat, 20 Jan 2001 20:18:34 -0500 (EST), you wrote:
> 
> 
> >that's not the topic: Andre's talking about pci-clock-based timing
> >constants the the driver programs into the ide controller - a matter
> >of an extra few/more nanoseconds.
> 
> I know, but when looking hard for a problem in one place and not
> finding it, it is sometimes helpful to consider other options.
> 
> I am getting errors under 2.4.0 which didn't appear in 2.2.17 - and as
> far as I could see from hdparm - both were at UDMA mode 2 (I assume
> thats what the * means - the man page wasn't very clear).  My drives
> only handle up to this mode, and I was wondering if the new driver was
> trying to run them at a mode higher than they were supposed to go.
>
> This massive difference in timing  seemed significant.

No, but to me it seems that even though UDMA2 mode is selected in the
drive in 2.2.17 (that's what the * means), the kernel doesn't use DMA,
and thus everything works in PIO4. This would well explain the speed
difference.

> >quite slow in either case, at least for modern hardware (which is 
> >all in the 20-40 MB/s range).  this looks like a PIO vs DMA difference
> >to me, not even UDMA.  of course, hdparm can tell you what mode you're in.
>
> I did discover a difference - 2.2.17 set the drives with multisector
> off, 2.4.0 was setting multisector on.

Multisector is valid only in PIO modes. If both were doing some kind of
DMA, it wouldn't change anything.

> However, I have redone the
> timing with multisector turned on in the 2.2.17 case and the
> difference is still there.
> 
> Under 2.2.17 with multisector turned on
> 
> 
> /dev/hda:
> 
>  Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
>  BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
> MultSect=16
>  DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
>  tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
> mword2 
>  IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4 
>  UDMA modes: mode0 mode1 *mode2 
> 
> ------------------
> 
> /dev/hda:
>  Timing buffered disk reads:  64 MB in 19.88 seconds =  3.22 MB/sec
> 
> 
> Under 2.4.0
> 
> 
> /dev/hda:
> 
>  Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
>  BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
> MultSect=16
>  DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
>  tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
> mword2 
>  IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4 
>  UDMA modes: mode0 mode1 *mode2 
> 
> ------------------
> 
> /dev/hda:
>  Timing buffered disk reads:  64 MB in  6.58 seconds =  9.73 MB/sec
> 
> 
> 
> I don't suppose the fact that my hdparm is oldish (3.6 I think) have
> any bearing on this?

No, 3.6 is OK I think. 

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote:

> Vojtech, I worry that the dynamic timing that you are calculating could
> bite you. 

Well, I know this. But I fear hardcoded timings won't really help here,
unles everyone out there ran their chipsets at 33 MHz, in which case the
calculation gains the exact same results (you can compare that) as the
hardcoded numbers for UDMA timings.

> Timings are exact especially at modes 3/4/5 the margins go to
> an effective zero for varition or wiggle room.  The state diagrams from
> Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it
> constrained.  You need to assume absolutes because the various board
> makers screw up the skew tables by the PCB lane traces.
> 
> By assuming only absolutes, all vendors that do bad designs will show and
> the user can not and "should" not be allowed to hold the driver in a state
> that can damage filesystems or lock the box.  Since I have never addressed
> this issue in public it is no obvious why I hardcoded timings and did not
> let tehm float, but I hope it is clearer now.

Ok, the VIA driver from clean 2.2.18 does nothing. It doesn't even use
hardcoded timings. It doesn't touch any timing tables. It just blindly
enables prefetch and writeback in the chips. The thing works because it
relies on BIOS to set things up correctly, and this is often the case,
yes.

> chipset ---\
>             |
>             \---------IDC-header
> 
> chipset ---+
>            |
>            +----------IDC-header
> 
> These are nearly the same but the corners cause bounce and iCRC's

Well, there are other ways the motherboard maker can screw up the
traces, and often this happens:

chipset --------\
                |
chipset ------\ |
              | \------ header
              \-------- header

So the different traces have different lengths and thus some bits arrive
earlier than others to the header, causing the same CRC errors.

Also it seems that some boards don't use exactly 33.3 MHz PCI clock, but
something like 33.7 or even more, which causes some drives to fail with
them if the chipset is set to the 0xe0 (2 pciclk/ideclk) value.

This is because they use very cheap base 14MHz crystals.

As I said before - if you leave 'idebus' at 33, the calculated timings
are exactly the same as the hardcoded values would be (I think there is
a difference in PIO2 mode, where the calculation gives a slightly larger
active time and shorter recovery, but this is OK with the specs).

And this is also why the cheaply made motherboards fail. (They don't
care to make that VIA UDMA66 ide working correctly when they have a
UDMA100 HPT370 onboard)?

... btw, if we ever implement UDMA slowdown code based on CRC errors, we
should differentiate between CRC errors on read and CRC errors on write,
because each are caused by a different problem ...

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Jan Niehusmann]

On Sun, Jan 21, 2001 at 10:46:06AM +0100, Vojtech Pavlik wrote:
> Ok, the VIA driver from clean 2.2.18 does nothing. It doesn't even use
> hardcoded timings. It doesn't touch any timing tables. It just blindly
> enables prefetch and writeback in the chips. The thing works because it
> relies on BIOS to set things up correctly, and this is often the case,
> yes.

If BIOS is often correct: Is it possible to read these values and compare
them to the values linux calculates? If both match: OK, continue. If they
are different: Either BIOS or linux is wrong, print a warning and disable
DMA (or go to some other kind of 'safe mode').

Just an idea, I don't know anything about chipsets and IDE timings ;-)

Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

On Sun, Jan 21, 2001 at 01:42:41PM +0100, Mike Galbraith wrote:
> On Sun, 21 Jan 2001, Vojtech Pavlik wrote:
> 
> > On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote:
> > 
> > > chipset ---\
> > >             |
> > >             \---------IDC-header
> > > 
> > > chipset ---+
> > >            |
> > >            +----------IDC-header
> > > 
> > > These are nearly the same but the corners cause bounce and iCRC's
> 
> I don't see how anyone can influence risetime falltime or impedance
> matching [1] issues via software timing changes.
> 
> (the top drawing is what you see on a poorly designed board.. long
> rise/fall times often cause worse problems than [slight] ringing)
> 
> > Well, there are other ways the motherboard maker can screw up the
> > traces, and often this happens:
> > 
> > chipset --------\
> >                 |
> > chipset ------\ |
> >               | \------ header
> >               \-------- header
> > 
> 
> Can you compensate for these things (to any degree?) in software?

Not really. Slowing the data rate down is in my opinion the only way to
compensate for this. Btw, the chipset only controls the write data rate
with UDMA. The read rate is controlled by the drive.

> 1.  Only a software guy would call it 'bounce'.. sounds funny ;-)

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Andre Hedrick]

On Sun, 21 Jan 2001, Vojtech Pavlik wrote:

> On Sun, Jan 21, 2001 at 01:42:41PM +0100, Mike Galbraith wrote:
> > On Sun, 21 Jan 2001, Vojtech Pavlik wrote:
> > 
> > > On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote:
> > > 
> > > > chipset ---\
> > > >             |
> > > >             \---------IDC-header
> > > > 
> > > > chipset ---+
> > > >            |
> > > >            +----------IDC-header
> > > > 
> > > > These are nearly the same but the corners cause bounce and iCRC's
> > 
> > I don't see how anyone can influence risetime falltime or impedance
> > matching [1] issues via software timing changes.
> > 
> > (the top drawing is what you see on a poorly designed board.. long
> > rise/fall times often cause worse problems than [slight] ringing)
> > 
> > > Well, there are other ways the motherboard maker can screw up the
> > > traces, and often this happens:
> > > 
> > > chipset --------\
> > >                 |
> > > chipset ------\ |
> > >               | \------ header
> > >               \-------- header
> > > 
> > 
> > Can you compensate for these things (to any degree?) in software?
> 
> Not really. Slowing the data rate down is in my opinion the only way to
> compensate for this. Btw, the chipset only controls the write data rate
> with UDMA. The read rate is controlled by the drive.
> 
> > 1.  Only a software guy would call it 'bounce'.. sounds funny ;-)

Er...I help design some of the hardware and the rules, so I do more than
just software.  So does 'echo' or 'reflections'sound better than 'bounce'?

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Dan Hopper]

In another dimension, Andre Hedrick <andre@linux-ide.org> remarked:
> 
> > On Sun, Jan 21, 2001 at 01:42:41PM +0100, Mike Galbraith wrote:
> > > 1.  Only a software guy would call it 'bounce'.. sounds funny ;-)
> 
> Er...I help design some of the hardware and the rules, so I do more than
> just software.  So does 'echo' or 'reflections'sound better than 'bounce'?

EEs talk about ground bounce and the like all the time. 
"reflections" are also fine.  "Signal integrity" is the in-the-know
phrase.  Of course, most of us weren't english majors, so noone
really cares all that much how you say it.

Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Mike Galbraith]

On Sun, 21 Jan 2001, Andre Hedrick wrote:

> > > 1.  Only a software guy would call it 'bounce'.. sounds funny ;-)
> 
> Er...I help design some of the hardware and the rules, so I do more than
> just software.  So does 'echo' or 'reflections'sound better than 'bounce'?

Yes.  (I wasn't cracking on you.. the term just tickled my funny bone)

	-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[David D.W. Downey]

OK, I see you guys releasing patches for the AMD + VIA problem, but this
problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s
and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When
are we going to see something for the MSI boards?

My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset
and the Promise PDC20265 ATA100 onbard controller.

I need some sort of help with this. I'm getting kernel deaths left and
right and no hope in sight here.

I though it might possibly be a mix of SCSI + IDE causing troubles so I
borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys
SCSI card (not sure of the make offhand. I can find the box when I get
home as I'm at work right now.)

I would code up a fix if I knew what the hell I was doing when it came to
coding which I do NOT.

Vojtech, can you please work with me on this issue? Or if you are too
busy, can you put me in contact with someone who can help? I've got a
$3000 machine sitting here that I can not do a damn thing with until I
stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
not at the kernel or anyone involved with the VIA stuff. Please don't take
it that way.)

David Downey


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

On Thu, Jan 25, 2001 at 01:54:36PM -0800, David D.W. Downey wrote:
> 
> 
> OK, I see you guys releasing patches for the AMD + VIA problem, but this
> problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s
> and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When
> are we going to see something for the MSI boards?
> 
> My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset
> and the Promise PDC20265 ATA100 onbard controller.
> 
> I need some sort of help with this. I'm getting kernel deaths left and
> right and no hope in sight here.
> 
> I though it might possibly be a mix of SCSI + IDE causing troubles so I
> borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys
> SCSI card (not sure of the make offhand. I can find the box when I get
> home as I'm at work right now.)
> 
> I would code up a fix if I knew what the hell I was doing when it came to
> coding which I do NOT.
> 
> Vojtech, can you please work with me on this issue? Or if you are too
> busy, can you put me in contact with someone who can help? I've got a
> $3000 machine sitting here that I can not do a damn thing with until I
> stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
> not at the kernel or anyone involved with the VIA stuff. Please don't take
> it that way.)

Sure, I'll need a more precise description, though.

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Andre Hedrick]

Where the flip are you form this power starved portion of the world?
Also the subject is AMD and VIA chipsets not AMD CPU's running on VIA
chipsets.

What chipset or host is causing you the problem?

VIA pr Promise?

On Thu, 25 Jan 2001, David D.W. Downey wrote:

> 
> 
> OK, I see you guys releasing patches for the AMD + VIA problem, but this
> problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s
> and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When
> are we going to see something for the MSI boards?
> 
> My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset
> and the Promise PDC20265 ATA100 onbard controller.
> 
> I need some sort of help with this. I'm getting kernel deaths left and
> right and no hope in sight here.
> 
> I though it might possibly be a mix of SCSI + IDE causing troubles so I
> borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys
> SCSI card (not sure of the make offhand. I can find the box when I get
> home as I'm at work right now.)
> 
> I would code up a fix if I knew what the hell I was doing when it came to
> coding which I do NOT.
> 
> Vojtech, can you please work with me on this issue? Or if you are too
> busy, can you put me in contact with someone who can help? I've got a
> $3000 machine sitting here that I can not do a damn thing with until I
> stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
> not at the kernel or anyone involved with the VIA stuff. Please don't take
> it that way.)
> 
> David Downey
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[David D.W. Downey]

LOL, I'm in Sunnyvale, CA right now. I work for Ensim.Com.



OK, here is all the technical info on my box. Sorry it took so long to
respond. Had a department meeting to attend.


MSI 694D Pro running Dual FC-PGA PIII-733 CPUs with 1GB of Corsair RAM.

HDD is a Western Digital WDC300BB-00AU1 ATA100 drive (running it on the
VIA controlled ATA33/66 controller since the kernel doesn't support the
ATA100 very well.)

Chipsets are the VIA VT82C686A and the Promise PDC20265

NIC is a NetGear FA-310TX

Advansys UW SCSI Card

Yamaha CRW8424S CDRW

Voodoo3 2000 AGP 16MB AGP video card.


APM/ACPI turned OFF in BIOS, NOT using the ATA100 controller


Symptoms: Consistantly recurring kernel deaths resulting in hard lock of
box.






 
On Thu, 25 Jan 2001, Andre Hedrick wrote:

> 
> Where the flip are you form this power starved portion of the world?
> Also the subject is AMD and VIA chipsets not AMD CPU's running on VIA
> chipsets.
> 
> What chipset or host is causing you the problem?
> 
> VIA pr Promise?
> 
> On Thu, 25 Jan 2001, David D.W. Downey wrote:
> 
> > 
> > 
> > OK, I see you guys releasing patches for the AMD + VIA problem, but this
> > problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s
> > and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When
> > are we going to see something for the MSI boards?
> > 
> > My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset
> > and the Promise PDC20265 ATA100 onbard controller.
> > 
> > I need some sort of help with this. I'm getting kernel deaths left and
> > right and no hope in sight here.
> > 
> > I though it might possibly be a mix of SCSI + IDE causing troubles so I
> > borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys
> > SCSI card (not sure of the make offhand. I can find the box when I get
> > home as I'm at work right now.)
> > 
> > I would code up a fix if I knew what the hell I was doing when it came to
> > coding which I do NOT.
> > 
> > Vojtech, can you please work with me on this issue? Or if you are too
> > busy, can you put me in contact with someone who can help? I've got a
> > $3000 machine sitting here that I can not do a damn thing with until I
> > stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
> > not at the kernel or anyone involved with the VIA stuff. Please don't take
> > it that way.)
> > 
> > David Downey
> > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > Please read the FAQ at http://www.tux.org/lkml/
> > 
> 
> Andre Hedrick
> Linux ATA Development
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Andre Hedrick]

On Sun, 21 Jan 2001, Vojtech Pavlik wrote:

> On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote:
> 
> > Vojtech, I worry that the dynamic timing that you are calculating could
> > bite you. 
> 
> Well, I know this. But I fear hardcoded timings won't really help here,
> unles everyone out there ran their chipsets at 33 MHz, in which case the

You have to run the ATA Chipset at 33MHz or it will fail in 99% of all
cases.  This is not the FSB running at 66/83/100/133.  So hardcode is
correct.

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

On Wed, Jan 24, 2001 at 10:04:50AM -0800, Andre Hedrick wrote:

> > Well, I know this. But I fear hardcoded timings won't really help here,
> > unless everyone out there ran their chipsets at 33 MHz, in which case the
> 
> You have to run the ATA Chipset at 33MHz or it will fail in 99% of all
> cases. 

No. Though I'd advise everyone to stick with 33MHz PCI when they can
because it is safe. But even the VIA specs mention 25, 37.5 and 41.5 PCI
speeds.

> This is not the FSB running at 66/83/100/133.  So hardcode is
> correct.

If you set a MVP3 or MVP4 chipset to 83 MHz FSB, you'll get 41.5 MHz
or 27.6 MHz PCI. And there are chips speced for 75 and 83 MHz FSB's -
Cyrix 6x86MX etc.

No way to get 33 here, if you *don't* want to over/under-clock the CPU. 

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Andre Hedrick]

On Wed, 24 Jan 2001, Vojtech Pavlik wrote:

> On Wed, Jan 24, 2001 at 10:04:50AM -0800, Andre Hedrick wrote:
> 
> > > Well, I know this. But I fear hardcoded timings won't really help here,
> > > unless everyone out there ran their chipsets at 33 MHz, in which case the
> > 
> > You have to run the ATA Chipset at 33MHz or it will fail in 99% of all
> > cases. 
> 
> No. Though I'd advise everyone to stick with 33MHz PCI when they can
> because it is safe. But even the VIA specs mention 25, 37.5 and 41.5 PCI
> speeds.
> 
> > This is not the FSB running at 66/83/100/133.  So hardcode is
> > correct.
> 
> If you set a MVP3 or MVP4 chipset to 83 MHz FSB, you'll get 41.5 MHz
> or 27.6 MHz PCI. And there are chips speced for 75 and 83 MHz FSB's -
> Cyrix 6x86MX etc.
> 
> No way to get 33 here, if you *don't* want to over/under-clock the CPU. 

Vojtech,

In the past there were hardcoded timing values for the allowable for the
VIA cores that were defined by VIA.  They were taken from their internal
lookup tables.  You have stated that you have allowed for "slop" in the
timing to attempt to soften the driver, that is your decision you are
totally responsible for keeping that chipset alive.

I suspect that you have not seen and know that you have not hear in person
the issues that arise for pushing or slacking the timing on the HOST side
of the world.  However, I do expect that you understand that at slower
transfer rates you have a greater margin for error-tolerance.  However the
game completely changes once Mode 3 and higher are used.  The margins are
ever so narrow.  Thus by following the exact letter and value you remove
suspect from the driver.

Additionally with the auto_crc_downgrade feature now in 2.4.x if they only
get iCRC errors the main driver will force the transfer rate down to
stablize the timings.  This was put in to correct for all the real crap
mainboards that everyone buys and expects them to work at full speed.
Well the do not, and fudging the timing tables to make crap work and
then cause ones that are within the tolerance of the cable skews is not
acceptable.  You will continue to fight this battle and lose, but consider
doing so gracefully.

Put the hardcoded timing values back in as default, and allow for the
option to use the dynamic fudged ones by the enduser.  The default are
generally stable, the fudged ones I can not comment.

Oh and overclockers can goto hell on a bobsled for all I care because
current scope as define by the top is that overclock is not the default
case of use.

Lastly the IDE-PCI clocking is independent of the FBS or PCI-Bus clocking.
The three timing ranges given by VIA for 25, 33, 41 are to morph the
IDE-PCI clock back to 33.  Thus PCI-Bus of 25 increases cycle time to
achieve the 33, as the 41 reduces time to achieve the 33.  I know what I
want to say, whether I did or not succeed is an issue.  So if you do not
follow me (as most usually fail to follow me :-(( ) just ask.

Regards,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

On Wed, Jan 24, 2001 at 01:58:09PM -0800, Andre Hedrick wrote:

> In the past there were hardcoded timing values for the allowable for the
> VIA cores that were defined by VIA.  They were taken from their internal
> lookup tables.  You have stated that you have allowed for "slop" in the
> timing to attempt to soften the driver, that is your decision you are
> totally responsible for keeping that chipset alive.
> 
> I suspect that you have not seen and know that you have not hear in person
> the issues that arise for pushing or slacking the timing on the HOST side
> of the world.  However, I do expect that you understand that at slower
> transfer rates you have a greater margin for error-tolerance.  However the
> game completely changes once Mode 3 and higher are used.  The margins are
> ever so narrow.  Thus by following the exact letter and value you remove
> suspect from the driver.

You can always check the /proc/ide/via listing to check that the values
are the same as in the specs. Actually there is not much to get wrong
with UDMA timing - it's just one register's value on VIA chipsets.

> Additionally with the auto_crc_downgrade feature now in 2.4.x if they only
> get iCRC errors the main driver will force the transfer rate down to
> stablize the timings.  This was put in to correct for all the real crap
> mainboards that everyone buys and expects them to work at full speed.
> Well the do not, and fudging the timing tables to make crap work and
> then cause ones that are within the tolerance of the cable skews is not
> acceptable.  You will continue to fight this battle and lose, but consider
> doing so gracefully.
> 
> Put the hardcoded timing values back in as default, and allow for the
> option to use the dynamic fudged ones by the enduser.  The default are
> generally stable, the fudged ones I can not comment.

There are no 'fudged' values. The values the chipset is programmed to,
when the idebus= option is set to the default 33 MHz are exactly the
same as in the specs. Really.

I hope the auto_crc_downgrade will help things, at least on those
drives, that don't crash their firmware in the case of a iCRCed
transfer.

Anyway, what about adding a XFER_UDMA_SLOW mode that would set the
chipset to say 150 or 180 ns per UDMA cycle? At least AMD specs mention
such a possibility. It's better than using MWDMA, and if XFER_UDMA_0 is
still too fast for the drive, it'd be a good 'last fallback'.

> Lastly the IDE-PCI clocking is independent of the FBS or PCI-Bus clocking.
> The three timing ranges given by VIA for 25, 33, 41 are to morph the
> IDE-PCI clock back to 33.  Thus PCI-Bus of 25 increases cycle time to
> achieve the 33, as the 41 reduces time to achieve the 33.  I know what I
> want to say, whether I did or not succeed is an issue.  So if you do not
> follow me (as most usually fail to follow me :-(( ) just ask.

Yes. The IDE timing should be always the same, independent on the PCI
clock. However, it is programmed in terms of PCI cycles, so yes, the
only thing my driver does is exactly this compensation for the PCI speed
so that the IDE timing stays constant.

Yes, my driver is doing exactly what you say.

-- 
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

Hi Andre!

I'm sending you (and others who might be interested) my latest VIA and
IDE drivers. The VIA driver (v3.15) should have a complete support for
UDMA100 on the vt82c686b chip, the AMD driver (v1.5) should have full
UDMA100 support on the amd766 ViperPlus chip.

They're also a little more foolproof with respect to the 'idebus'
setting, which is quite a misnomer, btw.

Care to try them out?

Andre, you're the only one I know of having the 766 chip, so please test
this driver, I'd like to know if it really works ... thanks.

-- 
Vojtech Pavlik
SuSE Labs

[-- Attachment #2: via-amd-ide.tar.bz2 --]
[-- Type: application/octet-stream, Size: 9666 bytes --]