Messages in this thread | | | Date | Tue, 25 Aug 1998 23:24:38 +0200 (CEST) | From | Geert Uytterhoeven <> | Subject | RE: 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
| |