Re: port-mac68k/37611: macs with cuda adb don't boot -current

[Martin Husemann <martin%duskware.de@localhost>]

The following reply was made to PR port-mac68k/37611; it has been noted by 
GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: Scott Reynolds <scottr%NetBSD.org@localhost>
Cc: gnats-bugs%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
 
        movl #1,%a2@
 
 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.
 
 
 Martin