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 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
