Re: HPT374 IDE problem with 2.6.21.* kernels

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Tuesday 05 June 2007, Sergei Shtylyov wrote:
> Hello.
> 
> Bartlomiej Zolnierkiewicz wrote:
> 
> >>>>>>>The log of a typical IDE reset is available here:
> 
> >>>>>>>http://petra.hos.u-szeged.hu/~wildy/syslog.gz
> 
> >>>>>>>This was the worst case: the IDE bus was resetted during the system 
> >>>>>>>boot.
> 
> >>>>>>  Could you try setting HPT374_ALLOW_ATA133_6 to 0 in
> >>>>>>drivers/ide/pci/hpt366.c and rebuild/reboot the kernel?
> 
> >>>>>Hi Sergei,
> 
> >>>>>This looks promising. Using a vanilla 2.6.22-rc3 I was able to reproduce
> >>>>>the problem within a few seconds. With the above modification the 
> >>>>>machine
> >>>>>is running under heavy disk I/O without problems since 30 minutes...
> 
> >>>>Did it fix the problem for good?
> 
> >>>It seems so far. There hasn't been any problem since I've applied the fix.
> 
> >>>>Sergei, do we need to disallow UDMA6 completely on HPT734 or
> >>>>is it only an issue with some problematic devices (=> blacklist)?
> 
> >>    Note that I didn't change what the old code was doing in this regard -- 
> >>although the HPT374 spec does *not* say that UDMA6 is supported, it had been 
> >>enabled. What have *really* changed for HPT374 was:
> 
> >>- in 2.6.20-rc1, the driver switched to using the actual 33 MHz timing table
> >>   instead of the old one, matching 50 MHz (and so, severely underclocked);
> 
> >>- in 2.6.2-rc1, the driver switched from 33 MHz PCI to 66 MHz DPLL clock.
> 
> >>    Disallowing UDMA6 would clock the chip with 50 MHz DPLL, howewer, the 
> 
> > I felt inspired by this explanation (thanks!) and took a look at
> > hpt374-opensource-v2.10 vendor driver.  Here is something interesting:
> 
> > glbdata.c:
> 
> > ...
> > #ifdef CLOCK_66MHZ
> > ULONG setting370_66[] = {
> >         0xd029d5e,  0xd029d26,  0xc829ca6,  0xc829c84,  0xc829c62,
> >         0x2c829d2c, 0x2c829c66, 0x2c829c62,
> >         0x1c829c62, 0x1c9a9c62, 0x1c929c62, 0x1c8e9c62, 0x1c8a9c62,
> >         0x1c8a9c62/*0x1cae9c62*/, 0x1c869c62, 0x1c869c62,
> > };
> > ...
> 
> > hpt366.c:
> 
> > ...
> > static u32 sixty_six_base_hpt37x[] = {
> >         /* XFER_UDMA_6 */       0x1c869c62,
> >         /* XFER_UDMA_5 */       0x1cae9c62,     /* 0x1c8a9c62 */
> > ...
> 
> > So we are using Dual ATA Clock for UDMA5 whereas vendor driver doesn't
> 
>     This is so in all other HPT drivers (and HPT371N datasheet has the same 
> figures -- this chip is the only one supporting UDMA6 and having the default 
> DPLL clock > 50 MHz).  Note that it means that there's no actual UDMA5 since 
> the timing exactly matches that one used for UDMA4.
> 
> > (the only other mode which uses Dual ATA Clock, in both drivers, is rarely
> > used UDMA3).
> 
>     And UDMA4 with 50 MHz clock.
> 
> > Thanks to this UDMA cycle time should be equal 22.5ns instead of 30ns
> > (spec defines it at 16.8ns, ide_timings[] uses 20ns) when using 66 MHz DPLL
> > clock.  In theory everything should play nice but the data manual for HPT374
> 
>     And it does -- on other chips.

My beautiful theory failed... Oh, well... ;)

> > contains weird note that Dual ATA Clock is meant to implement ATA100 read
> > and write at different clocks (there is no more explanation to this).
> 
>     That's the thing that keeps me confused in the other datasheets too -- 
> from my interpretation of their timing figures it seemed to control 2x ATA 
> clock multipler. HPT370 datasheet just gives different timings and SCR2 values 
> for reads/writes in UDMA5 (I've disabled this mode on HPT370 from which the 
> read performance only gained -- not sure if it makes sense to restore the old 
> clock turnaround hack).
> 
> > Geller reported that the problems started after migrating from 2.6.20.7 to
> > 2.6.21.1 (the affected disks are using UDMA5) and at the same time the driver
> > switched from 33 MHz PCI to 66 MHz DPLL clock.  Also the issue is completely
> > fixed by using 50 MHz DPLL clock (UDMA5 timing for 50 MHz DPLL clock is
> > 0x12848242 so UDMA cycle time equals 20ns and is smaller than the one
> > obtained using 66 MHz DPLL clock).
> 
> 
> > It all makes me wonder whether it is really safe to use Dual ATA Clock for
> > UDMA5 and whether we should just be using "the offical" timing instead...
> 
>     Not sure. I had no problems with this on the HPT371N/302 and 371N was 
> clocked by 66 MHz DPLL from the start (its default clock is 75 MHz however).
>     I'm still holding to my hypothesis that HPT374 simply can't tolerate 66 
> MHz DPLL clock, and the UDMA5 timing figures that you've cited seem to prove that.
>     I'm going to post a patch today -- how about completely prohibiting UDMA6 
> on HPT374?

Sounds fine, in case somebody misses it we can introduce something like
hpt374_allow_66mhz_dpll module parameter...

Thanks,
Bart