Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 2 Jun 2002 08:11:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 2 Jun 2002 08:11:46 -0400 Received: from mion.elka.pw.edu.pl ([194.29.160.35]:51352 "EHLO mion.elka.pw.edu.pl") by vger.kernel.org with ESMTP id ; Sun, 2 Jun 2002 08:11:43 -0400 Date: Sun, 2 Jun 2002 14:11:28 +0200 (MET DST) From: Bartlomiej Zolnierkiewicz To: Andre Hedrick cc: Subject: Re: FUD or FACTS ?? but a new FLAME! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 1 Jun 2002, Andre Hedrick wrote: > > On Sun, 2 Jun 2002, Bartlomiej Zolnierkiewicz wrote: > > > Only in piix driver (Intel & Efar) and user have to explicitly compile > > support for it, it have nothing to do with kernel version and everything > > with driver version. > > And you forgot about the removal of the bad drive lists. > > > > The effect is the following. "LINUS are you listening?" > > ^^^^^^^^^^^^^^^^^^^^^^^^ > > Andre, you forgot to cc Linus ;) > > I don't bother, he will not listen. > > > > Maybe now people will understand why 2.5 is falling apart and it is not > > > Martin's fault. He is just getting bad information and bad patches. > > > > Poor Marcin, he is so misinformed by bad people trying to spoil ATA stuff. > > Well yes, I have waited to see who could solve the double timer and double > handler issue since I never got to include the correct solution before it > was ripped out of my hands. The was a nice big private flamewar where > much of the lot in 2.5 made claims they could read and code to state > diagrams. OOPS where is the code? The error still exists, but not in 2.4. > > At this point I have two solutions and trying to determine which is the > best. The current one works, but have observed random extra interrupt on > traces. Now the second model is not tested but in practice would not need > the check for possible handler race which causes the fore mentioned. > > I guess I should now resubmit another patch, since the 2.5.7 was DOA, to > fix the transport layer problem. However unless there is an in-process > flag for walking BIO's it will only make the communication correct. It > will still violate the nature of the state diagrams proper. It is a > development kernel, and who cares if it blows your data on an error. > This happens because at the time, there was not a usable means to protect > the BIOS walked during the operations of the hardware atomic segment. > > So any BIOS/BH's traversed are at risk of there is a media error or any > other error event. Yes, broken multi-PIO. > > > He actual has nearly the same model I was working on to use fucntion > > > > It is really funny... but some people read code and know facts... > > And some of us do not publish all there work because it needs to be a > complete solution as not to damage peoples data. > > > > pointers in the style of "MiniPort (tm)". I will explain why this is > > > desired later. > > > > in Q4 I guess > > Nah, in Q3 with Serial ATA which requires a much more dynamic driver. > > > What a nice FUD. > > What is this major design flaw? Experimental (on demand) code in piix > > This is typical style from the PIO5 issue in the past to expanding the VIA > variable clockbase cruft to hardware which can only operate in 33 or 66 > reference baseclock. Any other chipsets which do specific things with > timing ... ie HPT366/37X, CMD/SiI680, PDC20262 and above with PLL timers > to setup and properly phase. > > So now you have multiple cases where the hardware does things total different > then the cruft added to them, and the "working toser code of mine" deleted. > > So now pick up the pieces. > > switch (amd_clock) { > case 33000: amd_clock = 33333; break; > case 37000: amd_clock = 37500; break; > case 41000: amd_clock = 41666; break; > } > > Please somebody tell me where in the AMD hardware spec it allow the base > clock to be anything but 33MHz ? So instead of preventing people from > forcing the driver into bogus modes in the past, it now promotes > stupidity. So what should we do in case of overclocked PCI bus? Get overclocked ATA or try to mess with timings? > switch (piix_clock) { > case 33000: piix_clock = 33333; break; > case 37000: piix_clock = 37500; break; > case 41000: piix_clock = 41666; break; > } > > Also repeat for INTEL ... > Oh and exclude the point about clock as 66 or 100 cause the option is not > here even. Since the registers referred to are for internal silicon > triggers which have a base origin of 33 .... sheesh why to I bother! > > Look it still exists even after explaining many times of trying to make > the point! > > /* > * $Id: ata-timing.c,v 2.0 2002/03/12 15:48:43 vojtech Exp $ > * > * Copyright (c) 1999-2001 Vojtech Pavlik > * > * This program is free software; you can redistribute it and/or modify it > > { XFER_SW_DMA_1, 90, 0, 0, 0, 240, 240, 480, 0 }, > { XFER_SW_DMA_0, 120, 0, 0, 0, 480, 480, 960, 0 }, > > { XFER_PIO_5, 20, 50, 30, 100, 50, 30, 100, 0 }, > { XFER_PIO_4, 25, 70, 25, 120, 70, 25, 120, 0 }, > > NICE > > /* EIDE PIO modes */ > if ((map & XFER_EPIO) && (id->field_valid & 2)) { > if ((best = (drive->id->eide_pio_modes & 4) ? XFER_PIO_5 : > (drive->id->eide_pio_modes & 2) ? XFER_PIO_4 : > (drive->id->eide_pio_modes & 1) ? XFER_PIO_3 : 0)) > return best; > } > > > For some reason I can not find XFER_PIO_5 any where in the standard. > So where did the value come from? > Do I have a test for (drive->id->eide_pio_modes & 4), yes. > The difference is I know to never permit XFER_PIO_5 ever being set. > > BETTER > > /* Lenghten active & recovery time so that cycle time is correct. > */ > > if (t->act8b + t->rec8b < t->cyc8b) { > t->act8b += (t->cyc8b - (t->act8b + t->rec8b)) / 2; > t->rec8b = t->cyc8b - t->act8b; > } > > if (t->active + t->recover < t->cycle) { > t->active += (t->cycle - (t->active + t->recover)) / 2; > t->recover = t->cycle - t->active; > } It is legal according to ATA spec. So all hosts are broken in this respect? > Instead of using the fixed and bounded PIO timing values as set forward by > the OEM Chip makers, who know best how their product works. 2.5 now has > this charming piece of crap which admits to dorking up the command block > transfer timing execution. OUCH. So they are generally broken? If so why there are even registers for setting timings, they could have done tables in hardware? > Now recall me being called a LIAR by PINHEAD. > > If the drivers baseclock gets fubar'd, thus the PIO taskfile or ata > command block execution (how to talk to the hardware), the driver will > begin to corrupt events. > > PINHEAD, look it happened and you were not even watching. > Your blind hatered of me being correct again has come back to visit. > > BEST! > > /* > * PIO 0-5, MWDMA 0-2 and UDMA 0-6 timings (in nanoseconds). These were taken > * from ATA/ATAPI-6 standard, rev 0a, except for PIO 5, which is a nonstandard > * extension and UDMA6, which is currently supported only by Maxtor drives. > */ > > I wish somebody would inform Maxtor so it can be made public. > On monday I will call one of my contacts there who writes the > diskware/firmware, I am sure he will need a good laugh at the beginning of > the week. Why, I cant get it. > > driver? Or you no longer being ATA maintainer? > > No check the file. > > > Ok, I really wanted to be quiet, but this time it is too much... > > sorry for bad words/irony but that is how things look like... > > I wish you had because, you will soon find out how right I am at the > hardware transport layer. > > > Some people (me included) are putting much effort in cleaning/improving > > all this mess, and you keep spreading FUD and discrediting them. > > Well I have admitted in the past and will again, my coding style sucks. > Now given the choice between ugly code which is technically correct, or > elegantly written to be technically wrong. > > The latter will not provide usable reports to fix it, while the former > will allow one to make it elegant. I will try to make the best of the two worlds. > Sincerely, > > Andre Hedrick > LAD Storage Consulting Group > > PS "PINHEAD" is the endearing term generally used to refer to Torvalds, by > may of the mainsteam developers. Anyway, thanks for input Andre... -- Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/