[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-mac68k/37611: macs with cuda adb don't boot -current
The following reply was made to PR port-mac68k/37611; it has been noted by
From: Martin Husemann <martin%duskware.de@localhost>
To: Scott Reynolds <scottr%NetBSD.org@localhost>
Subject: Re: port-mac68k/37611: macs with cuda adb don't boot -current
Date: Tue, 1 Apr 2008 14:13:09 +0200
On Tue, Apr 01, 2008 at 12:44:22AM -0500, Scott Reynolds wrote:
> The completion routine is called at interrupt time with the a2
> register set to the completion data buffer.
See below for why this does not currently work. Minor nit: shouldn't
it do a
instead? We pass an int pointer, and after the command is done the flag
value is 0x00010000 ;-)
> There is another case in adb_op_sync() similar to the one you see in
> adb_read_date_time(). The adb_op_sync() version times out, though.
Ok, I copied over the timeout code, and now it only warns loud if something
goes wrong, but does not hang the whole kernel any more. Way more conveninent
while debugging the root cause.
I traced where this all fails: we end up in adb_pass_up(), comprout and
compdata are still correct. We then defer to the softint handler - but since
the caller is busy waiting, we have no chance to ever run that handler before
we timeout. Setting adb_polling=1 during this call makes it work early in
boot, but unfortunately later hangs the whole kernel when running ntpdate
(can't even break into ddb) - so I guess that does something very bad to the
adb bus (which I otherwise do not use, I have serial console).
Maybe adb commands should have a per command flag that indicates we are
polling for the result, in addition to the global flag? Or I just did
something wrong when playing with the global flag.
Main Index |
Thread Index |