RE: L68K: Re: IDE-Driver Update :: Testing Requested (fwd)

Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
Tue, 25 Aug 1998 23:24:25 +0200 (CEST)


These missed the CC to linux-kernel.

---------- Forwarded message ----------
Date: Tue, 25 Aug 1998 9:10:31 -0700 (PDT)
From: Michael Schmitz <SCHMITZ@LCBVAX.CCHEM.BERKELEY.EDU>
To: Geert.Uytterhoeven@cs.kuleuven.ac.be
Cc: linux-m68k@lists.linux-m68k.org
Subject: RE: L68K: Re: IDE-Driver Update :: Testing Requested

Hi,

>[ Moving the discussion to linux-kernel.

Forgot to CC: there.

>> >| ******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)

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

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

Michael

-
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