>Number:         37611
>Category:       port-mac68k
>Synopsis:       macs with cuda adb don't boot -current
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-mac68k-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 25 12:45:01 +0000 2007
>Originator:     martin@duskware.de
>Release:        NetBSD 4.99.45
>Organization:
>Environment:
System: NetBSD mac-beth.duskware.de 4.99.45 NetBSD 4.99.45 (MAC-BETH) #14: Tue Dec 25 13:12:03 CET 2007 martin@night-porter.duskware.de:/usr/src/sys/arch/mac68k/compile/MAC-BETH mac68k
Architecture: m68k
Machine: mac68k
>Description:

Trying to boot -current hangs in adb_read_date_time().
I suspect it hangs in this loop:

        case ADB_HW_IISI:
                output[0] = 0x02;       /* 2 byte message */
                output[1] = 0x01;       /* to pram/rtc device */
                output[2] = 0x03;       /* read date/time */
                result = send_adb_IIsi((u_char *)output, (u_char *)output,
                    (void *)adb_op_comprout, __UNVOLATILE(&flag), (int)0);
                if (result != 0)        /* exit if not sent */
                        return -1;
 
--->>>          while (0 == flag)       /* wait for result */
                        ;
 
                *curtime = (long)(*(long *)(output + 1));

but either ddb is lying to me or I'm overlooking something, as it says the
hang is a bit earlier (which does not make sense).

>How-To-Repeat:
Just boot -current on a machine with cuda?

>Fix:
The patch below avoids the problem, but there is more to cleanup.

Index: adb_direct.c
===================================================================
RCS file: /cvsroot/src/sys/arch/mac68k/dev/adb_direct.c,v
retrieving revision 1.60
diff -c -u -p -r1.60 adb_direct.c
cvs diff: conflicting specifications of output style
--- adb_direct.c        3 Dec 2007 15:33:52 -0000       1.60
+++ adb_direct.c        25 Dec 2007 12:33:22 -0000
@@ -2720,6 +2720,8 @@ adb_read_date_time(unsigned long *curtim
        int result;
        volatile int flag = 0;
 
+       return -1;
+
        switch (adbHardware) {
        case ADB_HW_II:
                return -1;

First using "volatile int flag" and then passing __UNVOLATILE(&flag) around
looks like a poor man's condvar to me. Second the code plays tricks behind
the compilers back:

void 
adb_op_comprout(void)
{
        __asm("movw     #1,%a2@                 | update flag value");
}

(this is the code that sets flag to 1)