This message is from the T13 list server.
> Why not do the obvious inside the error handler?
>
> Inc. the icrc_error counter regardless and retry. Then once you have
> reached your icrc_error max threshold count, jump and do an immediate
> operation to down grade the transfer rate via set-features
> and reprogram
> the timings of the host and then return out of the
> icrc-handler and retry.
>
> Mind you that one needs to be assured that this is the only
> error involve
> or you get in a jam and can lock the host.
The biggest reasons are max I/O delay time and predictability.
(not in anyway saying your solution won't work, or is a poor
solution, just listing the benefits to mine (to which I'm sure
there are some down sides)
Maximum total I/O delay time:
By the time you have expired the max threshold count the first
time, you have a large number of retries. Depending on the HDD,
each of those retries may cause a media access (i.e. a slip rev,
11 - 8.3 ms) for each access. Then to multiply that by 6 UDMA
modes.... you are getting into some large numbers that may exceed
the I/O command timeout.
Predictability of maximum I/O delay:
By saying you will only do one downgrade before doing a PIO
you have a shorter more predictable I/O delay. Otherwise you
could be anywhere from 1 retry to 6 UDMA modes times max threshold
for each UDMA mode.... Very high variance.
Set_features in I/O handler:
Definitely agree with doing the set_feature in the I/O handler
(don't have to worry about having to get another application
involved that does not interrupt a pending I/O).
The only down side, is changing the timing chipset registers for
one channel while another cycle is operating on the 2nd channel.
(Everyone is supporting independent channels, right -:)
Jeff
Jeff Wolford Email: [EMAIL PROTECTED]
Senior Storage Architect
Storage Interface and Tools - PC Storage Group
Voice: (281) 514-9465, Pager: (800) 973-5739
Compaq Computer Corporation
>
> Regard,
>
> Andre Hedrick
> CEO/President, LAD Storage Consulting Group
> Linux ATA Development
> Linux Disk Certification Project
>
> On Tue, 18 Dec 2001, Wolford, Jeff wrote:
>
> > This message is from the T13 list server.
> >
> >
> > Hale,
> >
> > So while I agree that if you are getting CRC errors
> > you are having BIG problems, the fact remains that you
> > will have much more setup and hold time under
> > PIO Mode [0], so you still have some possibility of
> > writing the data to the drive. This is why I say don't
> > stop at PIO Mode [4], as you don't get additional setup/hold
> > but yet loose the iCRC.
> >
> > I DO NOT agree with BLUE SCREEN.
> >
> > The system can have LOTS of other data in the file system
> > cache that could be written to other drives, or are different
> > patterns, that can and should be written to a drive.
> >
> > I DO agree that you should very NOTICEABLY notify the
> > user that you are getting MAJOR CRC errors.
> >
> > Jeff
> >
> > > -----Original Message-----
> > > From: Hale Landis [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, December 14, 2001 7:18 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [t13] UDMA 'recovery procedure'
> > >
> > >
> > > This message is from the T13 list server.
> > >
> > >
> > > On Fri, 14 Dec 2001 15:28:11 -0800, Eschmann, Michael K wrote:
> > > >[...] MWDMA is a bad choice, as is
> > > >SWDMA too because it has no CRC checking and lots of people
> > > have poor MWDMA
> > > >implementations and many do not have SWDMA.
> > > >But why would you go all the way to PIO-0? Wouldn't it be
> > > prudent to go
> > > >from PIO-4, then step down to 0?
> > >
> > > If you have stepped down to U-DMA mode 0 and you are still getting
> > > excessive ICRC errors then maybe it is time to "blue
> screen" and tell
> > > the human to fix their hardware. Under no conditions would I
> > > recommend stepping down even more to MW DMA or any PIO in
> this case.
> > > Just how many undetected data corruption errors can your OS or
> > > application programs live with???
> > >
> > >
> > > *** Hale Landis *** [EMAIL PROTECTED] ***
> > > *** Niwot, CO USA *** www.ata-atapi.com ***
> > >
> > >
> > > Subscribe/Unsubscribe instructions can be found at www.t13.org.
> > >
> > Subscribe/Unsubscribe instructions can be found at www.t13.org.
> >
>
>
Subscribe/Unsubscribe instructions can be found at www.t13.org.
