> Can you try instead the changes that I just committed to -current? I
> think that the problem shows up when the controller is heavily loaded;
> your patch will keep the load on the controller down, which may mask the
> 'real' bug.
I tried your approach (that was what I described with "fiddling with DELAY").
I even went even further to clear that loop, but it didn't help. This is
what I currently still have in there from these experiments:
/* from linux: The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")
for (i = 10000, done = 0, worked = 0; (i > 0) && !done; i--) {
s = splbio();
/* is the mailbox free? */
if (sc->amr_mailbox->mb_busy == 0) {
debug("got mailbox");
sc->amr_mailbox64->mb64_segment = 0;
bcopy(&ac->ac_mailbox, sc->amr_mailbox, AMR_MBOX_CMDSIZE);
sc->amr_submit_command(sc);
done = 1;
sc->amr_workcount++;
TAILQ_INSERT_TAIL(&sc->amr_work, ac, ac_link);
/* not free, try to clean up while we wait */
} else {
debug("busy flag %x\n", sc->amr_mailbox->mb_busy);
/* don't do this in here for now, it involves talking to the
* controller to see whether there's work done, and since we
* just saw that the controller is somewhat busy, that's perhaps
* not such a good idea? */
/* worked += amr_done(sc); */
}
splx(s);
DELAY(100);
barrier();
}
/* check here for work to be done */
s = splbio();
worked += amr_done(sc);
splx(s);
This did *NOT* stop the controller from crashing. Ignore the comment above,
I'll take this amr_done call back up, but I just wanted to REALLY be sure
this loop wasn't the cause for the crash.
Markus
--
KPNQwest Switzerland Ltd
P.O. Box 9470, Zweierstrasse 35, CH-8036 Zuerich
Tel: +41-1-298-6030, Fax: +41-1-291-4642
Markus Wild, Manager Engineering, e-mail: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
