lkml.org 
[lkml]   [1998]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: L68K: Re: IDE-Driver Update :: Testing Requested (fwd)
---------- Forwarded message ----------
Date: Tue, 25 Aug 1998 18:21:12 +0200 (CEST)
From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
To: Michael Schmitz <SCHMITZ@LCBVAX.CCHEM.BERKELEY.EDU>
Cc: linux-m68k@lists.linux-m68k.org
Subject: RE: L68K: Re: IDE-Driver Update :: Testing Requested

On Tue, 25 Aug 1998, Michael Schmitz wrote:
> >[ Moving the discussion to linux-kernel.
>
> Forgot to CC: there.

Deliberately?

> >> >| ******hdb: irq timeout: status=0xd0 { Busy }
> >> >| ide0: reset: success
> >> >| hdb: irq timeout: status=0xd0* { Busy }
> >> ^
> >> How is this possible ?? Interrupt from IDE while in timeout processing?
> >>[...]
> >> Seems like it's getting the interrupt right after the timeout is reported in
> >> two out of three times.
> >>[...]
> >> Dunno - for which disk was the interrupt (print 'a' or 'b' there)?
> >
> >Changed. On IDE interrupt, I now print
> >
> > 'X' if hwgroup->drive == NULL
> > 'A' for hda
> > 'B' for hdb
> > '!' for other drive (should not happen)
> >
> >[...]
> >Added `U' for unexpected interrupt. `R' if !drive_is_ready().
> >
> >In set_handler(), I now print `x', `a', `b' or `?' to indicate for which drive
> >the request was started.
> >
> >Now I get:
> >
> >| aAaAaAaAbBbBbBbBbBbBbBbBbBbBbBbBbBbBbBbBbBaAbBbBbBaAbBbBbBbBbBbBbBaAaAaAaA
> >| bBbBbBbBbBaAaAaAaAaAaAaAaAbhdb: irq timeout: status=0xd0 { Busy }
> >| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> >| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> >| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> >| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> >| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> >| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
>
> What's happening here? Polling for reset to complete? Why is set_handler() called
> that often? But that may be normal - it's just so different from the pattern before
> (aA or bB, never X or other unexpected things)

The reset code installs a handler with a 50 ms time out. It is restarted until
the drive responds or until 30 seconds are passed.

> >| bbbbbbbbbbbbbbbbbbbbbbide0: reset: success
> >| bhdb: irq timeout: status=0xd0BU { Busy }
> >| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
> >
> >So the request times out on hdb, which is indeed the active drive. But the
> >message `hdb: irq timeout' appears immediately after the `b' from the last
> >request, while the timeout should be 10 seconds (10*HZ).
>
> And the interrupt comes in in the timeout handler, again (and it's the right
> interrupt). Happens in the majority of cases, probably, and there's nothing wrong
> with the interrupts.

Yes, it's the correct interrupt.

> >Add more debugging code, to remember when the last request was posted. I don't
> >have the log here (forgot to save it after reboot[*]), but here are the facts:
> >
> > - at jiffies = 18779, set_handler() calls add_timer() with an expiration
> > time of 19779 (i.e. jiffies+10*HZ)
> > - ide_timer_expiry() is called at jiffies = 18779 (i.e. immediately), while
> > hwgroup->timer.expires still contains 19779 (i.e. future)
> >
> >So ide_timer_expiry() is called before the timer expires.
>
> Seems that's the problem - the timer is broken. I can imagine that the scheduling
> clock falls behind in the stretch of PIO transfers just before, but the clock isn't
> going to advance by 1000 ticks. So the only explanation seems a race in the timer
> code itself.
>
> >Could it be m68k related?
>
> Maybe - what's the interrupt priority of timer and IDE on other machines?

I don't know. On Amiga, IDE is level 2. The timer uses CIA B timer A, which is
level 6.

Greetings,

Geert

--
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.028 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site