> Alan,
>
> This is one of the versions of INTEL which has extra bandwidth if you
> want
> wanted to the async IO. Meaning the device could be set faster than the
> host when reading from the host. However when writing to the host the
> device "must" be set to match. The buffer is not capable of safely
> handling the extra push.
>
> So in 2.4 we will properly time the host, unlike 2.5 which has elected
> to overdrive the hardware.
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.
> The effect is the following. "LINUS are you listening?"
^^^^^^^^^^^^^^^^^^^^^^^^
Andre, you forgot to cc Linus ;)
> Ultra DMA 100 uses 4 data clocks to transfer "X" amount of data.
> Ultra DMA 133 uses 3 data clocks to transfer "X" amount of data.
>
> So if a bad host trys to push the limits, it ends up missing a data
> strobe and the DATA goes away quietly without warning. NICE!
>
> 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.
Bad patches? Who is the bad guy making the bad patches?
Let me guess, it is Vojtech removing others people copyrighted "sick
timing tables". Or maybe it is Jens doing at least TCQ?
Or maybe it is me... etc.
> 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...
> pointers in the style of "MiniPort (tm)". I will explain why this is
> desired later.
in Q4 I guess
> Cheers,
Greets...
> Andre Hedrick
> LAD Storage Consulting Group
>
> PS AntonA, my promise to you to inform Linus of one of the major design
> flaws of 2.5 is now met.
What a nice FUD.
What is this major design flaw? Experimental (on demand) code in piix
driver? Or you no longer being ATA maintainer?
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...
Some people (me included) are putting much effort in cleaning/improving
all this mess, and you keep spreading FUD and discrediting them.
--
Bartlomiej
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.
> > 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.
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;
}
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.
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.
> 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.
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.
Bartlomiej Zolnierkiewicz wrote:
>>Alan,
>>
>>This is one of the versions of INTEL which has extra bandwidth if you
>>want
>>wanted to the async IO. Meaning the device could be set faster than the
>>host when reading from the host. However when writing to the host the
>>device "must" be set to match. The buffer is not capable of safely
>>handling the extra push.
>>
>>So in 2.4 we will properly time the host, unlike 2.5 which has elected
>>to overdrive the hardware.
>
>
> 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.
>
>
>>The effect is the following. "LINUS are you listening?"
>
> ^^^^^^^^^^^^^^^^^^^^^^^^
> Andre, you forgot to cc Linus ;)
>
>
>>Ultra DMA 100 uses 4 data clocks to transfer "X" amount of data.
>>Ultra DMA 133 uses 3 data clocks to transfer "X" amount of data.
>>
>>So if a bad host trys to push the limits, it ends up missing a data
>>strobe and the DATA goes away quietly without warning. NICE!
>>
>>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.
>
> Bad patches? Who is the bad guy making the bad patches?
> Let me guess, it is Vojtech removing others people copyrighted "sick
> timing tables". Or maybe it is Jens doing at least TCQ?
> Or maybe it is me... etc.
>
>
>>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...
>
>
>>pointers in the style of "MiniPort (tm)". I will explain why this is
>>desired later.
>
>
> in Q4 I guess
Of year 2010 - remember learning proper C will take him time.
Becouse I never ever saw any code contributed by him
despite the fact that I'm still open for patches, as
I have told him upon request.
Once exception was a broken patch which even didn't
compile and couldn't solve the problem it was
proclaiming to solve.
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
On Sun, 2002-06-02 at 13:11, Bartlomiej Zolnierkiewicz wrote:
> So what should we do in case of overclocked PCI bus?
> Get overclocked ATA or try to mess with timings?
You cannot overclock the AMD on chipset IDE or the intel on chipset IDE.
It doesn't actually matter what you do the system is going to be way out
of wack. These are chipset bridges rather than card people ram into
weird bits of hardware.
The VIA stuff and the Promise it makes some sense to try because they
may be shoved in boxes with a 25MHz PCI clock, or in a few cases a
horribly broke 37.5/41Mhz bus from the early chipsets that had 'idiot
only' 75/83Mhz FSB options
On 2 Jun 2002, Alan Cox wrote:
> On Sun, 2002-06-02 at 13:11, Bartlomiej Zolnierkiewicz wrote:
> > So what should we do in case of overclocked PCI bus?
> > Get overclocked ATA or try to mess with timings?
>
> You cannot overclock the AMD on chipset IDE or the intel on chipset IDE.
> It doesn't actually matter what you do the system is going to be way out
> of wack. These are chipset bridges rather than card people ram into
> weird bits of hardware.
Please explain further, so in general AMD, Intel must not be overclocked?
Beacause if they are they are screwed (not only IDE)...?
> The VIA stuff and the Promise it makes some sense to try because they
> may be shoved in boxes with a 25MHz PCI clock, or in a few cases a
> horribly broke 37.5/41Mhz bus from the early chipsets that had 'idiot
> only' 75/83Mhz FSB options
--
Bartlomiej
On Sun, 2002-06-02 at 15:25, Bartlomiej Zolnierkiewicz wrote:
> Please explain further, so in general AMD, Intel must not be overclocked?
> Beacause if they are they are screwed (not only IDE)...?
You can start with the fact that they are not engineered to run at other
speeds. In addition these are the base chipset for machines, they aren't
add in cards that are stuck onto existing broken socket 7 systems with
75/83.33Mhz FSB.
They are specced for 33Mhz only.
On Sun, 2 Jun 2002, Bartlomiej Zolnierkiewicz wrote:
> > So any BIOS/BH's traversed are at risk of there is a media error or any
> > other error event.
>
> Yes, broken multi-PIO.
Worse than broken, there is not an acceptable interface to honor the
hardware and protect the data, and meet the requirement of the development
kernel.
So I can make it technically correct and operate clean.
I can not promise driver level protection of the data above.
This very issue breaks the requirement of the state diagram for data
transfers.
Offline I will walk you throught the process and requirements.
I am tired of explaining it to people who can not and will not understand
the issue. Even though I have spent time on may occassions with several
people to explain, they all claim to understand yet none prove it.
For some reason, I trust you get the points and see the magnitude of the
problem. The issue can you explain it to the rest who you will have to
deal with, because I am done.
So you now it is up to you to fix it, I will answer your questions.
> So what should we do in case of overclocked PCI bus?
Same as in the past, do not support overclocking.
> Get overclocked ATA or try to mess with timings?
Forest Gump, "Stupid is as Stupid does" best answer.
> It is legal according to ATA spec.
For the HOST hardware not for the HOST drivers.
One of the issues in the spec, is the lack of separation of layers.
The spec is two layers not three, and described but the effects on each
end of the cable/ribbon. Additionally the spec is a one sided set of
rules of how to talk to a device (disk,atapi,etc). Much like how one has
to address Torvalds. Talk to a device the wrong way, the operation is
aborted with an error. Talk to Torvalds the wrong way, you get aborted.
But the SPEC and Torvalds are mutual dictators and react the same way.
> So all hosts are broken in this respect?
This one does not parse well, so I will ask you to clarify it.
However let me define HOST first.
HOST == Interface + Driver.
On the hardware side of the HOST, those values describe are for the
manufactures to make the hardware. They intern provide tables and rules
for setting the hardware to match discretely to the capablitites of the
devices attached.
Additionally any sane driver would pre-determine the values to be
programmed to insure the communications are proper. I have a preference
to obtain these values from the vender and then compare on paper before
publishing. If there is a problem, one would go back the vender of the
hardware and verify the differences.
> > 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?
Upon completion of POST it is observed and reported all drives default
their fast io mode. The origin of the host tuning code happened when most
interfaces were ATA-2 and the drives were ATA-3. Few people recall the
issues, but they happened like this.
PIIX3 limited to Mult-Word DMA 2 and an Ultra-33 drive attached.
Instant deadlock upon writing to the interface. The host would wait for
data which was already sent but missed. The system never booted.
> > Now recall me being called a LIAR by PINHEAD.
I realized a mistake was made here, and should not have stepped into the
sandbox to throw sand. This was wrong of me to drop to name calling.
I just wish other people were big enough to admit when they are wrong.
I hold little hope of ever seeing an apology from the otherside.
> > 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.
Would you please re-ask the question because I missed it.
> > 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.
You are my hope in it working, and if I had a choice you would be
Maintainer in 2.5!
> Anyway, thanks for input Andre...
Hey, I own you the thanks for trying to understand and your ablitity to
follow the points.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
I apology for flames Andre, after some thinking I came to
conclusion that if speaking hardware you are generally right.
I hope we can together resolve transport layer issues in 2.5.
Regards
--
Bartlomiej
On Sun, 2 Jun 2002, Bartlomiej Zolnierkiewicz wrote:
>
> I apology for flames Andre, after some thinking I came to
> conclusion that if speaking hardware you are generally right.
>
> I hope we can together resolve transport layer issues in 2.5.
Bartlomiej,
Thanks, and we worked well in the past togather, and there has never been
a communication problem with you.
Lets hope so, and please change the maintainer file to your name.
As you were in mind in the past to replace me when I burned out.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Sun, 2 Jun 2002, Bartlomiej Zolnierkiewicz wrote:
> >
> > I apology for flames Andre, after some thinking I came to
> > conclusion that if speaking hardware you are generally right.
> >
> > I hope we can together resolve transport layer issues in 2.5.
>
> Bartlomiej,
>
> Thanks, and we worked well in the past togather, and there has never
> been a communication problem with you.
>
> Lets hope so, and please change the maintainer file to your name.
> As you were in mind in the past to replace me when I burned out.
Thanks, but you are doing just fine for 2.4 and Martin for 2.5.
--
Bartlomiej
Andre Hedrick wrote:
> On Sun, 2 Jun 2002, Bartlomiej Zolnierkiewicz wrote:
>
>
>>I apology for flames Andre, after some thinking I came to
>>conclusion that if speaking hardware you are generally right.
>>
>>I hope we can together resolve transport layer issues in 2.5.
>
>
> Bartlomiej,
>
> Thanks, and we worked well in the past togather, and there has never been
> a communication problem with you.
>
> Lets hope so, and please change the maintainer file to your name.
> As you were in mind in the past to replace me when I burned out.
O co chodzi? Po prostu powinno si? przenie?? dwa typy host chip?w
intela do kategori - "mo?e dzia?a jak chcesz to spr?buj":
Ulf Axelsson to wszystko dawno ju? rozwi?za?:
Hi Martin!
(Note: This mail (and myself) is intentionally _NOT_ intended to go anywhere
near linux-kernel and the regular flame fests. I'm as anonymous as one can
be ;-)
I have been reading the stuff about the difference between ATA/100 and
ATA/133 talking about clock cycles, buffer sizes, transmission directions
and what not and were quite unable to understand what the point was until I
looked at the public Intel ICH4 spec (the one available to us mortals
without connections :-)
ftp://download.intel.com/design/chipsets/manuals/29860002.pdf
Intel do state that the ICH4/82801DB supports only ATA/100 not ATA/133.
Looking through some reviews on the net on the 845E/G they do say the same
thing.
In the light of that perhaps the code in drivers/ide/piix.c stating that the
ICH4 does ATA/133 is a bit optimistic and should be moved to the "try it if
you want to " CONFIG_BLK_DEV_PIIX_TRY133 option.
Of course Vojtek might have better info that says otherwise.
<<<CUTOUT>>>
static struct piix_ide_chip {
unsigned short id;
unsigned char flags;
} piix_ide_chips[] = {
{ PCI_DEVICE_ID_INTEL_82801DB_9, PIIX_UDMA_133 |
PIIX_PINGPONG },
^^^^^^^^^^^^^
/* Intel 82801DB ICH4 */
{ PCI_DEVICE_ID_INTEL_82801CA_11, PIIX_UDMA_100 |
PIIX_PINGPONG },
/* Intel 82801CA ICH3/ICH3-S */
{ PCI_DEVICE_ID_INTEL_82801CA_10, PIIX_UDMA_100 |
PIIX_PINGPONG },
/* Intel 82801CAM ICH3-M */
{ PCI_DEVICE_ID_INTEL_82801E_9, PIIX_UDMA_100 |
PIIX_PINGPONG },
<<<CUTOUT>>>
Things would be easier if "you know who" could just say that according to
public specs the ICH4 does not support ATA/133 instead of all that technical
talk......
Regards,
Ulf
PS. It would be kind if you could tell me where the source to the new
ide-info version you talked about can be found?
On Sun, 2 Jun 2002, Martin Dalecki wrote:
> Of year 2010 - remember learning proper C will take him time.
> Becouse I never ever saw any code contributed by him
> despite the fact that I'm still open for patches, as
> I have told him upon request.
> Once exception was a broken patch which even didn't
> compile and couldn't solve the problem it was
> proclaiming to solve.
There is a difference. I can pay a code monkey to write clean code.
Can you pay somebody to make the driver work?
Obviously you still can not read state diagrams even after I invited you
to IRC and walked you through the documents and explaining how there are
different events described in each. I then explain the difference of how
there are two ways to enter each one.
Then you tell me you have a grand idea for a unified interrupt handler,
which guesses what the operation to be completed by reading the command
register. But it is only command on a write, it is status on a read,
since an interrupt happened the command opcode is gone. NICE.
Then you toss out the next one. Gee, I can stall device interrupts to the
interface if a toggle the eIEN line on and off. Now where you planning to
do this between DMA interrupts if you had more than one PRD? I never
dreamed of such a brilliant idea, but you forgot one thing. NO touching
the taskfile registers until you stop DMAing. Either abort the
transaction of deadlock the interface.
Now I will go learn proper C, and you have all the time you need to try
get the data-transport layer right.
As for that patch I sent you, it works but you did not try. See after I
sent it to you on a short test compile, I ran tests on it the next day.
Lastly, I started to make a new one, but since there is no way to
determine what the entry mode of the driver upon command block execution.
Regards ...
Andre Hedrick
LAD Storage Consulting Group
On Mon, Jun 03, 2002 at 07:36:35AM +0200, Martin Dalecki wrote:
> I have been reading the stuff about the difference between ATA/100 and
> ATA/133 talking about clock cycles, buffer sizes, transmission directions
> and what not and were quite unable to understand what the point was until I
> looked at the public Intel ICH4 spec (the one available to us mortals
> without connections :-)
>
> ftp://download.intel.com/design/chipsets/manuals/29860002.pdf
Thanks for the pointer, I was unable to find it when I was assing ICH4
support - and most board-maker sites at that time advertised ATA-133.
> Intel do state that the ICH4/82801DB supports only ATA/100 not ATA/133.
> Looking through some reviews on the net on the 845E/G they do say the same
> thing.
Actually, it doesn't support ATA-100 correctly either. It has a 133MHz
base clock, and for ATA-100 uses a 3 clock cycle. 133MHz/3*2byte = 88.6 MB/sec.
So the maximum documented speed on ICH chips is 88.6 write, and 100.0
read - because there the drive dictates the speed.
> In the light of that perhaps the code in drivers/ide/piix.c stating that the
> ICH4 does ATA/133 is a bit optimistic and should be moved to the "try it if
> you want to " CONFIG_BLK_DEV_PIIX_TRY133 option.
Agreed. Martin, please do that. Also, please change the Config.in
comment to something like "Enable undocumented ATA-133 on ICH chips",
or somehting alike..
> Of course Vojtek might have better info that says otherwise.
No, I don't. ICH4 was designed to have ATA-133 capability, Intel
probably downgraded that in the spec because of some problems.
--
Vojtech Pavlik
SuSE Labs
On Mon, 3 Jun 2002, Martin Dalecki wrote:
> Andre Hedrick wrote:
> > On Sun, 2 Jun 2002, Bartlomiej Zolnierkiewicz wrote:
> >
> >
> >>I apology for flames Andre, after some thinking I came to
> >>conclusion that if speaking hardware you are generally right.
> >>
> >>I hope we can together resolve transport layer issues in 2.5.
> >
> >
> > Bartlomiej,
> >
> > Thanks, and we worked well in the past togather, and there has never been
> > a communication problem with you.
> >
> > Lets hope so, and please change the maintainer file to your name.
> > As you were in mind in the past to replace me when I burned out.
>
> O co chodzi? Po prostu powinno si? przenie?? dwa typy host chip?w
> intela do kategori - "mo?e dzia?a jak chcesz to spr?buj":
Chodzi o to, zeby wreszcie rozwiazac niektore problemy z 2.5 n.p.
multi PIO...
>
> Ulf Axelsson to wszystko dawno ju? rozwi?za?:
>
> Hi Martin!
>
> (Note: This mail (and myself) is intentionally _NOT_ intended to go anywhere
> near linux-kernel and the regular flame fests. I'm as anonymous as one can
> be ;-)
No longer ;-) Perpare for flames ;)
>
> I have been reading the stuff about the difference between ATA/100 and
> ATA/133 talking about clock cycles, buffer sizes, transmission directions
> and what not and were quite unable to understand what the point was until I
> looked at the public Intel ICH4 spec (the one available to us mortals
> without connections :-)
>
> ftp://download.intel.com/design/chipsets/manuals/29860002.pdf
>
> Intel do state that the ICH4/82801DB supports only ATA/100 not ATA/133.
> Looking through some reviews on the net on the 845E/G they do say the same
> thing.
>
> In the light of that perhaps the code in drivers/ide/piix.c stating that the
> ICH4 does ATA/133 is a bit optimistic and should be moved to the "try it if
> you want to " CONFIG_BLK_DEV_PIIX_TRY133 option.
>
> Of course Vojtek might have better info that says otherwise.
>
> <<<CUTOUT>>>
> static struct piix_ide_chip {
> unsigned short id;
> unsigned char flags;
> } piix_ide_chips[] = {
> { PCI_DEVICE_ID_INTEL_82801DB_9, PIIX_UDMA_133 |
> PIIX_PINGPONG },
> ^^^^^^^^^^^^^
>
> /* Intel 82801DB ICH4 */
> { PCI_DEVICE_ID_INTEL_82801CA_11, PIIX_UDMA_100 |
> PIIX_PINGPONG },
> /* Intel 82801CA ICH3/ICH3-S */
> { PCI_DEVICE_ID_INTEL_82801CA_10, PIIX_UDMA_100 |
> PIIX_PINGPONG },
> /* Intel 82801CAM ICH3-M */
> { PCI_DEVICE_ID_INTEL_82801E_9, PIIX_UDMA_100 |
> PIIX_PINGPONG },
> <<<CUTOUT>>>
>
> Things would be easier if "you know who" could just say that according to
> public specs the ICH4 does not support ATA/133 instead of all that technical
> talk......
>
So, we should change it...
...and simple idea how to deal with overclocking IDE chipsets
-> try best we can but put some nice fat warning to user that
he will probably get screwed due to running chipset out of
specification...
> Regards,
> Ulf
>
> PS. It would be kind if you could tell me where the source to the new
> ide-info version you talked about can be found?
http://home.elka.pw.edu.pl/~bzolnier/atapci
Bartlomiej Zolnierkiewicz wrote:
>>Things would be easier if "you know who" could just say that according to
>>public specs the ICH4 does not support ATA/133 instead of all that technical
>>talk......
>>
>
>
> So, we should change it...
>
> ...and simple idea how to deal with overclocking IDE chipsets
> -> try best we can but put some nice fat warning to user that
> he will probably get screwed due to running chipset out of
> specification...
Done - expect it in the next patch.