Messages in this thread | | | Date | Tue, 25 Aug 1998 23:24:25 +0200 (CEST) | From | Geert Uytterhoeven <> | Subject | RE: L68K: Re: IDE-Driver Update :: Testing Requested (fwd) |
| |
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
| |