a problem we've seen around here is that parallels
and vmware fusion will hang after 9load prints
"entry: 0x$address". our intel 5400 motherboard
also does this when no serial is connected.

it turns out that all three of these setups have
the same problem. consdrain() loops until all
the output has been stuffed down the serial port.
however, in these setups the first character sent
to the serial port sets up->txbusy and consdrain loops
forever trying to output the next character.

my solution was to note the number of characters
drained between calls to uartdrain and break out
of the loop if no progress is made. i also reduced
the amount of time allowed to push 1 character out
to 500ms. even for 128baud, this ought to be enough.

i attached a diff since the 9load i'm using has drifted
a bit from the distributed version.

- erik

----

diffy fns.h 8250.c console.c
diff /n/dump/2008/0721/sys/src/boot/pc/fns.h fns.h
126c126
< void uartdrain(void);
---
> int uartdrain(void);

260a261,262
> int i8250txchars;
>

273a276,277
> if(i < 100)
> i8250txchars++;

298c302
< void
---
> int

302a307
> static int last;

305a311,314
> /* very poor hack. don't wait forever if we never tx anything */
> if(i8250txchars == last)
> return -1;
> last = i8250txchars;

308c317
< for(timeo = 0; timeo < 10000 && up->txbusy; timeo++)
---
> for(timeo = 0; timeo < 500 && up->txbusy; timeo++)

diff /n/dump/2008/0721/sys/src/boot/pc/console.c console.c
64d63
<
66c65,66
< uartdrain();
---
> if(uartdrain() == -1)
> break;