Re: INTEL 845G Chipset IDE Quandry

Re: INTEL 845G Chipset IDE Quandry

[Bartlomiej Zolnierkiewicz]

> 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

FUD or FACTS ?? but a new FLAME!

[Andre Hedrick]

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.

Re: FUD or FACTS ?? but a new FLAME!

[Bartlomiej Zolnierkiewicz]

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

Re: FUD or FACTS ?? but a new FLAME!

[Alan Cox]

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

Re: FUD or FACTS ?? but a new FLAME!

[Bartlomiej Zolnierkiewicz]

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

Re: FUD or FACTS ?? but a new FLAME!

[Alan Cox]

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. 

Re: FUD or FACTS ?? but a new FLAME!

[Andre Hedrick]

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

Re: FUD or FACTS ?? but a new FLAME!

[Bartlomiej Zolnierkiewicz]

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

Re: FUD or FACTS ?? but a new FLAME!

[Andre Hedrick]

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

Re: FUD or FACTS ?? but a new FLAME!

[Martin Dalecki]

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?

Re: FUD or FACTS ?? but a new FLAME!

[Vojtech Pavlik]

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

Re: FUD or FACTS ?? but a new FLAME!

[Bartlomiej Zolnierkiewicz]

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

Re: FUD or FACTS ?? but a new FLAME!

[Martin Dalecki]

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.

Re: INTEL 845G Chipset IDE Quandry

[Martin Dalecki]

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.

Re: INTEL 845G Chipset IDE Quandry

[Andre Hedrick]

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

Re: INTEL 845G Chipset IDE Quandry

[Anthony Spinillo]

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

I just tried Andre's patch. I applied it on top of 2.4.19pre9-ac3.(Patch attached below.) It pulled me up to DMA. I tested by setting hdparm -d1 /dev/hdc
(my DVD drive) and played a DVD with Xine. It played great!

I do not have an IDE hard drive to test, since my HD is SCSI.

I will try Vojtech's patch next, and report in.

Thanks for all your help! (Andre, Vojtech, JeffN and everyone else.)

Tony


-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

[-- Attachment #2: andre.patch --]
[-- Type: application/octet-stream, Size: 3611 bytes --]

diff -urN linux-2.4.19-p9-ac3-pristine/drivers/ide/ide-pci.c
linux-2.4.19-p9-ac3/drivers/ide/ide-pci.c
--- linux-2.4.19-p9-ac3-pristine/drivers/ide/ide-pci.c	Sun Jun  2
16:49:06 2002
+++ linux-2.4.19-p9-ac3/drivers/ide/ide-pci.c	Sun Jun  2 20:52:49 2002
@@ -47,6 +47,7 @@
 #define DEVID_PIIX4U5	((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,  PCI_DEVICE_ID_INTEL_82801CA_10})
 #define DEVID_PIIX4U6	((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,  PCI_DEVICE_ID_INTEL_82801CA_11})
 #define DEVID_PIIX4U7	((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,  PCI_DEVICE_ID_INTEL_82801E_11})
+#define DEVID_PIIX4U8	((ide_pci_devid_t){PCI_VENDOR_ID_INTEL,  PCI_DEVICE_ID_INTEL_82801DB_11})
 #define DEVID_VIA_IDE	((ide_pci_devid_t){PCI_VENDOR_ID_VIA,	 PCI_DEVICE_ID_VIA_82C561})
 #define DEVID_MR_IDE	((ide_pci_devid_t){PCI_VENDOR_ID_VIA,	 PCI_DEVICE_ID_VIA_82C576_1})
 #define DEVID_VP_IDE	((ide_pci_devid_t){PCI_VENDOR_ID_VIA,	 PCI_DEVICE_ID_VIA_82C586_1})
@@ -438,6 +439,7 @@
	{DEVID_PIIX4U5, "PIIX4",	FIXUP_PIIX,	PCI_PIIX,    ATA66_PIIX,	  INIT_PIIX,	  NULL, 	  {{0x41,0x80,0x80},{0x43,0x80,0x80}},   ON_BOARD,	     0 },
	{DEVID_PIIX4U6, "PIIX4",	FIXUP_PIIX,	PCI_PIIX,    ATA66_PIIX,	  INIT_PIIX,	  NULL, 	  {{0x41,0x80,0x80},{0x43,0x80,0x80}},   ON_BOARD,	     0 },
	{DEVID_PIIX4U7, "PIIX4",	FIXUP_PIIX,	PCI_PIIX,    ATA66_PIIX,	  INIT_PIIX,	  NULL, 	  {{0x41,0x80,0x80},{0x43,0x80,0x80}},   ON_BOARD,	     0 },
+	{DEVID_PIIX4U8, "PIIX4",	FIXUP_PIIX,	PCI_PIIX,    ATA66_PIIX,	  INIT_PIIX,	  NULL, 	  {{0x41,0x80,0x80},{0x43,0x80,0x80}},   ON_BOARD,	     0 },
	{DEVID_VIA_IDE, "VIA_IDE",	NULL,		NULL,	     NULL, 	  NULL, 	  NULL, 	  {{0x00,0x00,0x00},{0x00,0x00,0x00}},   ON_BOARD,	     0 },
	{DEVID_MR_IDE,	"VP_IDE",	NULL,	       PCI_VIA82CXXX,	ATA66_VIA82CXXX,INIT_VIA82CXXX, DMA_VIA82CXXX, {{0x40,0x02,0x02}, {0x40,0x01,0x01}},	ON_BOARD,	0 },
	{DEVID_VP_IDE,	"VP_IDE",	NULL,	       PCI_VIA82CXXX,	ATA66_VIA82CXXX,INIT_VIA82CXXX, DMA_VIA82CXXX, {{0x40,0x02,0x02}, {0x40,0x01,0x01}},	ON_BOARD,	0 },
diff -urN linux-2.4.19-p9-ac3-pristine/drivers/ide/piix.c
linux-2.4.19-p9-ac3/drivers/ide/piix.c
--- linux-2.4.19-p9-ac3-pristine/drivers/ide/piix.c	Sun Jun  2
16:49:06 2002
+++ linux-2.4.19-p9-ac3/drivers/ide/piix.c	Sun Jun  2 20:36:23 2002
@@ -94,6 +94,7 @@
 		case PCI_DEVICE_ID_INTEL_82801CA_10:
 		case PCI_DEVICE_ID_INTEL_82801CA_11:
 		case PCI_DEVICE_ID_INTEL_82801E_11:
+		case PCI_DEVICE_ID_INTEL_82801DB_11:
 			p += sprintf(p, "Intel PIIX4 Ultra 100 Chipset.\n");
 			break;
 		case PCI_DEVICE_ID_INTEL_82372FB_1:
@@ -216,6 +217,7 @@
 		case PCI_DEVICE_ID_INTEL_82801CA_10:
 		case PCI_DEVICE_ID_INTEL_82801CA_11:
 		case PCI_DEVICE_ID_INTEL_82801E_11:
+		case PCI_DEVICE_ID_INTEL_82801DB_11:
 			mode |= 0x03;
 			break;
 		case PCI_DEVICE_ID_INTEL_82801AA_1:
@@ -534,6 +536,7 @@
 		case PCI_DEVICE_ID_INTEL_82801CA_10:
 		case PCI_DEVICE_ID_INTEL_82801CA_11:
 		case PCI_DEVICE_ID_INTEL_82801E_11:
+		case PCI_DEVICE_ID_INTEL_82801DB_11:
 		{
 			unsigned int extra = 0;
 			pci_read_config_dword(dev, 0x54, &extra);
diff -urN linux-2.4.19-p9-ac3-pristine/include/linux/pci_ids.h
linux-2.4.19-p9-ac3/include/linux/pci_ids.h
--- linux-2.4.19-p9-ac3-pristine/include/linux/pci_ids.h	Sun
Jun  2 16:49:17 2002
+++ linux-2.4.19-p9-ac3/include/linux/pci_ids.h Sun Jun  2 20:53:53
2002
@@ -1685,6 +1685,7 @@
 #define PCI_DEVICE_ID_INTEL_82801CA_10	0x248a
 #define PCI_DEVICE_ID_INTEL_82801CA_11	0x248b
 #define PCI_DEVICE_ID_INTEL_82801CA_12	0x248c
+#define PCI_DEVICE_ID_INTEL_82801DB_11	0x24cb
 #define PCI_DEVICE_ID_INTEL_80310	0x530d
 #define PCI_DEVICE_ID_INTEL_82810_MC1	0x7120
 #define PCI_DEVICE_ID_INTEL_82810_IG1	0x7121

Re: INTEL 845G Chipset IDE Quandry

[Anthony Spinillo]

I fired up 2519 as a test, same resource collision problem.

Tony

----- Original Message -----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: 	03 Jun 2002 02:13:45 +0100
To: Vojtech Pavlik <vojtech@suse.cz>
Subject: Re: INTEL 845G Chipset IDE Quandry


> On Sun, 2002-06-02 at 22:30, Vojtech Pavlik wrote:
> > On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
> > > Anthony Spinillo wrote:
> > > > Back to my original problem, will there be a fix before 2010? ;)
> > > 
> > > Well since you have already tyred yourself to poke at it.
> > > Well please just go ahead and atd an entry to the table
> > > at the end of piix.c which encompasses the device.
> > > Do it by copying over the next familiar one and I would
> > > be really geald if you could just test whatever this
> > > worked. If yes well please send me just the patch and
> > > I will include it.
> > 
> > Note it works with 2.5 already. We have the device there.
> 
> If you look at why it fails it fails not because it isnt in the table
> but because the PCI device has not been allocated resources properly by
> the BIOS
> 
> -
> 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/
> 
> 

-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

Re: INTEL 845G Chipset IDE Quandry

[Vojtech Pavlik]

On Mon, Jun 03, 2002 at 09:04:12AM +0800, Anthony Spinillo wrote:

> I fired up 2519 as a test, same resource collision problem.

In that case, probably only a BIOS upgrade (if there is one available)
can help.

> 
> Tony
> 
> ----- Original Message -----
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: 	03 Jun 2002 02:13:45 +0100
> To: Vojtech Pavlik <vojtech@suse.cz>
> Subject: Re: INTEL 845G Chipset IDE Quandry
> 
> 
> > On Sun, 2002-06-02 at 22:30, Vojtech Pavlik wrote:
> > > On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
> > > > Anthony Spinillo wrote:
> > > > > Back to my original problem, will there be a fix before 2010? ;)
> > > > 
> > > > Well since you have already tyred yourself to poke at it.
> > > > Well please just go ahead and atd an entry to the table
> > > > at the end of piix.c which encompasses the device.
> > > > Do it by copying over the next familiar one and I would
> > > > be really geald if you could just test whatever this
> > > > worked. If yes well please send me just the patch and
> > > > I will include it.
> > > 
> > > Note it works with 2.5 already. We have the device there.
> > 
> > If you look at why it fails it fails not because it isnt in the table
> > but because the PCI device has not been allocated resources properly by
> > the BIOS
> > 
> > -
> > 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/
> > 
> > 
> 
> -- 
> Get your free email from www.linuxmail.org 
> 
> 
> Powered by Outblaze
> -
> 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/

-- 
Vojtech Pavlik
SuSE Labs

Re: INTEL 845G Chipset IDE Quandry

[Anthony Spinillo]

Back to my original problem, will there be a fix before 2010? ;)

Tony


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.
> 
> 

-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

Re: INTEL 845G Chipset IDE Quandry

[Martin Dalecki]

Anthony Spinillo wrote:
> Back to my original problem, will there be a fix before 2010? ;)

Well since you have already tyred yourself to poke at it.
Well please just go ahead and atd an entry to the table
at the end of piix.c which encompasses the device.
Do it by copying over the next familiar one and I would
be really geald if you could just test whatever this
worked. If yes well please send me just the patch and
I will include it.

> 
> Tony
> 
> 
> 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.
>>
>>
> 
> 



-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R

Re: INTEL 845G Chipset IDE Quandry

[Vojtech Pavlik]

On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
> Anthony Spinillo wrote:
> > Back to my original problem, will there be a fix before 2010? ;)
> 
> Well since you have already tyred yourself to poke at it.
> Well please just go ahead and atd an entry to the table
> at the end of piix.c which encompasses the device.
> Do it by copying over the next familiar one and I would
> be really geald if you could just test whatever this
> worked. If yes well please send me just the patch and
> I will include it.

Note it works with 2.5 already. We have the device there.

> 
> > 
> > Tony
> > 
> > 
> > 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.
> >>
> >>
> > 
> > 
> 
> 
> 
> -- 
> - phone: +49 214 8656 283
> - job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
> - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R
> 
> -
> 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/

-- 
Vojtech Pavlik
SuSE Labs

Re: INTEL 845G Chipset IDE Quandry

[Alan Cox]

On Sun, 2002-06-02 at 22:30, Vojtech Pavlik wrote:
> On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
> > Anthony Spinillo wrote:
> > > Back to my original problem, will there be a fix before 2010? ;)
> > 
> > Well since you have already tyred yourself to poke at it.
> > Well please just go ahead and atd an entry to the table
> > at the end of piix.c which encompasses the device.
> > Do it by copying over the next familiar one and I would
> > be really geald if you could just test whatever this
> > worked. If yes well please send me just the patch and
> > I will include it.
> 
> Note it works with 2.5 already. We have the device there.

If you look at why it fails it fails not because it isnt in the table
but because the PCI device has not been allocated resources properly by
the BIOS

Re: INTEL 845G Chipset IDE Quandry

[Vojtech Pavlik]

On Mon, Jun 03, 2002 at 02:13:45AM +0100, Alan Cox wrote:
> On Sun, 2002-06-02 at 22:30, Vojtech Pavlik wrote:
> > On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
> > > Anthony Spinillo wrote:
> > > > Back to my original problem, will there be a fix before 2010? ;)
> > > 
> > > Well since you have already tyred yourself to poke at it.
> > > Well please just go ahead and atd an entry to the table
> > > at the end of piix.c which encompasses the device.
> > > Do it by copying over the next familiar one and I would
> > > be really geald if you could just test whatever this
> > > worked. If yes well please send me just the patch and
> > > I will include it.
> > 
> > Note it works with 2.5 already. We have the device there.
> 
> If you look at why it fails it fails not because it isnt in the table
> but because the PCI device has not been allocated resources properly by
> the BIOS

That's right. Well, maybe kernel 2.5 PCI code can fix that better? Maybe
not, and in that case a BIOS upgrade is probably the way to go.

-- 
Vojtech Pavlik
SuSE Labs

Re: INTEL 845G Chipset IDE Quandry

[Kjartan Maraas]

man, 2002-06-03 kl. 03:13 skrev Alan Cox:
> On Sun, 2002-06-02 at 22:30, Vojtech Pavlik wrote:
> > On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:

[SNIP]

> > Note it works with 2.5 already. We have the device there.
> 
> If you look at why it fails it fails not because it isnt in the table
> but because the PCI device has not been allocated resources properly by
> the BIOS
> 

Back when I talked to Andre about this problem it sounded to me like he
said it was a genuine bug that was fixed in the ide-convert patches.
Maybe I'm confusing two issues here...

Cheers
Kjartan

Re: INTEL 845G Chipset IDE Quandry

[Andre Hedrick]

Kjartan,

Please do not confuse them, they have a hard enough time reading.
The docs state it can only do X, but lets overclock it and do X+1.
Maybe the hardware is smart and knows which drivers are safe and sane.

Anthony, I sent you a mini-patch to add the 845G to the sane driver.
It will work, as Kjartan has stated.  His system suffered the exact same
events.

Cheers,

Andre Hedrick
LAD Storage Consulting Group


On 3 Jun 2002, Kjartan Maraas wrote:

> man, 2002-06-03 kl. 03:13 skrev Alan Cox:
> > On Sun, 2002-06-02 at 22:30, Vojtech Pavlik wrote:
> > > On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
> 
> [SNIP]
> 
> > > Note it works with 2.5 already. We have the device there.
> > 
> > If you look at why it fails it fails not because it isnt in the table
> > but because the PCI device has not been allocated resources properly by
> > the BIOS
> > 
> 
> Back when I talked to Andre about this problem it sounded to me like he
> said it was a genuine bug that was fixed in the ide-convert patches.
> Maybe I'm confusing two issues here...

Re: INTEL 845G Chipset IDE Quandry

[Martin Dalecki]

Vojtech Pavlik wrote:
> On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
> 
>>Anthony Spinillo wrote:
>>
>>>Back to my original problem, will there be a fix before 2010? ;)
>>
>>Well since you have already tyred yourself to poke at it.
>>Well please just go ahead and atd an entry to the table
>>at the end of piix.c which encompasses the device.
>>Do it by copying over the next familiar one and I would
>>be really geald if you could just test whatever this
>>worked. If yes well please send me just the patch and
>>I will include it.
> 
> 
> Note it works with 2.5 already. We have the device there.


Yes after looking it up I realized it's already there.

Re: INTEL 845G Chipset IDE Quandry

[Vojtech Pavlik]

On Mon, Jun 03, 2002 at 06:46:24AM +0200, Martin Dalecki wrote:
> Vojtech Pavlik wrote:
> > On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
> > 
> >>Anthony Spinillo wrote:
> >>
> >>>Back to my original problem, will there be a fix before 2010? ;)
> >>
> >>Well since you have already tyred yourself to poke at it.
> >>Well please just go ahead and atd an entry to the table
> >>at the end of piix.c which encompasses the device.
> >>Do it by copying over the next familiar one and I would
> >>be really geald if you could just test whatever this
> >>worked. If yes well please send me just the patch and
> >>I will include it.
> > 
> > 
> > Note it works with 2.5 already. We have the device there.
> 
> Yes after looking it up I realized it's already there.

But as Alan pointer out, in 2.4 the missing PCI ID isn't the problem -
it would work with no tuning without it, but the fact the on-board BIOS
incorrectly assigns io-ranges to the PCI device is a problem we may have
on 2.5 as well.

-- 
Vojtech Pavlik
SuSE Labs

Re: INTEL 845G Chipset IDE Quandry

[Martin Dalecki]

Vojtech Pavlik wrote:
> On Mon, Jun 03, 2002 at 06:46:24AM +0200, Martin Dalecki wrote:
> 
>>Vojtech Pavlik wrote:
>>
>>>On Sun, Jun 02, 2002 at 09:36:35PM +0200, Martin Dalecki wrote:
>>>
>>>
>>>>Anthony Spinillo wrote:
>>>>
>>>>
>>>>>Back to my original problem, will there be a fix before 2010? ;)
>>>>
>>>>Well since you have already tyred yourself to poke at it.
>>>>Well please just go ahead and atd an entry to the table
>>>>at the end of piix.c which encompasses the device.
>>>>Do it by copying over the next familiar one and I would
>>>>be really geald if you could just test whatever this
>>>>worked. If yes well please send me just the patch and
>>>>I will include it.
>>>
>>>
>>>Note it works with 2.5 already. We have the device there.
>>
>>Yes after looking it up I realized it's already there.
> 
> 
> But as Alan pointer out, in 2.4 the missing PCI ID isn't the problem -
> it would work with no tuning without it, but the fact the on-board BIOS
> incorrectly assigns io-ranges to the PCI device is a problem we may have
> on 2.5 as well.


Well I don't know that much about the ever changing PCI/ACPI support
in kernel - the only thing I could imagine
would be that we sanitize the handling of it at the generic
"chipset quirk handling" there. Right during the "bios table
scan" time... (I mean drivers/pci/quirks.c)

The following function there looks like the right tool for this
purpose:

static void __init quirk_io_region(struct pci_dev *dev, unsigned region, 
unsigned size, int nr)

Well after looking closer I'm convinced that this is
the right place... will you have a look at this plase...
I'm more then busy enbough with other things right now.

Re: INTEL 845G Chipset IDE Quandry

[Vojtech Pavlik]

On Mon, Jun 03, 2002 at 10:04:46AM +0200, Martin Dalecki wrote:

> Well I don't know that much about the ever changing PCI/ACPI support
> in kernel - the only thing I could imagine
> would be that we sanitize the handling of it at the generic
> "chipset quirk handling" there. Right during the "bios table
> scan" time... (I mean drivers/pci/quirks.c)
> 
> The following function there looks like the right tool for this
> purpose:
> 
> static void __init quirk_io_region(struct pci_dev *dev, unsigned region, 
> unsigned size, int nr)
> 
> Well after looking closer I'm convinced that this is
> the right place... will you have a look at this plase...
> I'm more then busy enbough with other things right now.

The PCI code under normal circumstances can fix the allocation problems
by itself (without any special quirks code), but in this case it simply
fails. Do you still have the original e-mail with the dmesg? I'd like to
look at that again ...

-- 
Vojtech Pavlik
SuSE Labs

Re: INTEL 845G Chipset IDE Quandry

[Martin Dalecki]

Vojtech Pavlik wrote:

> The PCI code under normal circumstances can fix the allocation problems
> by itself (without any special quirks code), but in this case it simply
> fails. Do you still have the original e-mail with the dmesg? I'd like to
> look at that again ...

No becouse It wasn't directed at me.

Re: INTEL 845G Chipset IDE Quandry

[Anthony Spinillo]

That is a relief. ;) Thanks Andre. 

Tony
> 
> 
> I need to add "24cb" to the list of hosts.
> 
> On Sat, 1 Jun 2002, Anthony Spinillo wrote:
> 
> > I am having trouble enabling DMA on a recently
> > installed motherboard. (Intel D845GBVL - 845g chipset). I am running a fresh RedHat7.3 install 
> > and have tried the stock RH kernel, and I'm up to 2.4.19-pre9. I have a CD burner and DVD drive 
> > attached which operated with DMA on an older 
> > 845 mobo. If I run hdparm -d1 /dev/hd(a or c),
> > I now get:
> > 
> > HDIO_SET_DMA failed: Operation not permitted
> > 
> > Here is a snippet from dmesg:
> > 

-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

INTEL 845G Chipset IDE Quandry

[Anthony Spinillo]

I am having trouble enabling DMA on a recently
installed motherboard. (Intel D845GBVL - 845g chipset). I am running a fresh RedHat7.3 install 
and have tried the stock RH kernel, and I'm up to 2.4.19-pre9. I have a CD burner and DVD drive 
attached which operated with DMA on an older 
845 mobo. If I run hdparm -d1 /dev/hd(a or c),
I now get:

HDIO_SET_DMA failed: Operation not permitted

Here is a snippet from dmesg:

ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
PCI_IDE: unknown IDE controller on PCI bus 00 device
f9, VID=8086, DID=24cb
PCI: Device 00:1f.1 not available because of resource
collisions
PCI_IDE: (ide_setup_pci_device:) Could not enable
device.

Here is some lspci

00:00.0 Host bridge: Intel Corp.: Unknown device 2560 (rev 01)
00:01.0 PCI bridge: Intel Corp.: Unknown device 2561 (rev 01)
00:1d.0 USB Controller: Intel Corp.: Unknown device 24c2 (rev 01)
00:1d.1 USB Controller: Intel Corp.: Unknown device 24c4 (rev 01)
00:1d.2 USB Controller: Intel Corp.: Unknown device 24c7 (rev 01)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corp.: Unknown device 24c0 (rev 01)
00:1f.1 IDE interface: Intel Corp.: Unknown device 24cb (rev 01)

I followed some recent threads, and tried fixes to similiar problems but I'm still locked out.

Aside from this glitch everything else seems to run fine. Could someone give my a hand? Am I missing something simple, is my bios borked, or do I need a patch to support the newer chipset?

Thanks,

Tony

-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

Re: INTEL 845G Chipset IDE Quandry

[Alan Cox]

On Sat, 2002-06-01 at 12:03, Anthony Spinillo wrote:
> PCI_IDE: unknown IDE controller on PCI bus 00 device
> f9, VID=8086, DID=24cb
> PCI: Device 00:1f.1 not available because of resource
> collisions
> PCI_IDE: (ide_setup_pci_device:) Could not enable
> device.

If you look with lspci -v you will find your BIOS has mismapped or
forgotten to map some of the control register space for that device.

Alan

Re: INTEL 845G Chipset IDE Quandry

[Andre Hedrick]

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.

The effect is the following.  "LINUS are you listening?"

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.
He actual has nearly the same model I was working on to use fucntion
pointers in the style of "MiniPort (tm)".  I will explain why this is
desired later.

Cheers,

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.

On 1 Jun 2002, Alan Cox wrote:

> On Sat, 2002-06-01 at 12:03, Anthony Spinillo wrote:
> > PCI_IDE: unknown IDE controller on PCI bus 00 device
> > f9, VID=8086, DID=24cb
> > PCI: Device 00:1f.1 not available because of resource
> > collisions
> > PCI_IDE: (ide_setup_pci_device:) Could not enable
> > device.
> 
> If you look with lspci -v you will find your BIOS has mismapped or
> forgotten to map some of the control register space for that device.
> 
> Alan
> 
> -
> 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/

Re: INTEL 845G Chipset IDE Quandry

[Andre Hedrick]

I need to add "24cb" to the list of hosts.

On Sat, 1 Jun 2002, Anthony Spinillo wrote:

> I am having trouble enabling DMA on a recently
> installed motherboard. (Intel D845GBVL - 845g chipset). I am running a fresh RedHat7.3 install 
> and have tried the stock RH kernel, and I'm up to 2.4.19-pre9. I have a CD burner and DVD drive 
> attached which operated with DMA on an older 
> 845 mobo. If I run hdparm -d1 /dev/hd(a or c),
> I now get:
> 
> HDIO_SET_DMA failed: Operation not permitted
> 
> Here is a snippet from dmesg:
> 
> ide: Assuming 33MHz system bus speed for PIO modes;
> override with idebus=xx
> PCI_IDE: unknown IDE controller on PCI bus 00 device
> f9, VID=8086, DID=24cb
> PCI: Device 00:1f.1 not available because of resource
> collisions
> PCI_IDE: (ide_setup_pci_device:) Could not enable
> device.
> 
> Here is some lspci
> 
> 00:00.0 Host bridge: Intel Corp.: Unknown device 2560 (rev 01)
> 00:01.0 PCI bridge: Intel Corp.: Unknown device 2561 (rev 01)
> 00:1d.0 USB Controller: Intel Corp.: Unknown device 24c2 (rev 01)
> 00:1d.1 USB Controller: Intel Corp.: Unknown device 24c4 (rev 01)
> 00:1d.2 USB Controller: Intel Corp.: Unknown device 24c7 (rev 01)
> 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 81)
> 00:1f.0 ISA bridge: Intel Corp.: Unknown device 24c0 (rev 01)
> 00:1f.1 IDE interface: Intel Corp.: Unknown device 24cb (rev 01)
> 
> I followed some recent threads, and tried fixes to similiar problems but I'm still locked out.
> 
> Aside from this glitch everything else seems to run fine. Could someone give my a hand? Am I missing something simple, is my bios borked, or do I need a patch to support the newer chipset?
> 
> Thanks,
> 
> Tony
> 
> -- 
> Get your free email from www.linuxmail.org 
> 
> 
> Powered by Outblaze
> -
> 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/
> 

Andre Hedrick
LAD Storage Consulting Group