limits of ucom / uplcom functionality; vmware serial mucking

[Charles Owens]

Hi folks... long time no post.

I'm trying to make use of ucom as I would a normal sio port and am 
having only partial success.  Hopefully someone here can help me 
understand what's really going on.

Overview:

    * Goal:  use ucom0 with vmware2
          o (I can do this with an sio(4) port just fine using /dev/cuaa#)
    * Problem:  vmware fails (with error message) when guest attempts to
      open port

    * Hardware
          o Bafo BF-810 USB-Serial adapter...
                + Detected (properly, I believe) via uplcom(4):

uplcom0: Prolific Technology PL2303 Serial adapter (ATEN/IOGEAR UC232A), rev 1.10/2.02, addr 2

          o For testing:  Null serial cable between COM1 (ttyd0) and
            BF-810 adapter's DB9 port
    * Software
          o FreeBSD 4.7
          o getty as dummy test target
          o tip / vmware2 (from ports) as local serial app

Experiments:

   1. getty running on ttyd0, tip to ucom0
          * SUCCESS (can login just fine)
   2. getty running on ucom0, tip to cuaa0
          * FAILURE -- Repeated on-the-fly adjustment of ucom0 baud rate
            allows brief spurts of functionality.  Rate changed from
            9600 bps to 19200 and then back using stty(1):

stty -f /dev/ucom0 speed {RATE}

   3. getty running on ttyd0, vmware guest using ucom0 as its COM1
          * FAILURE -- upon launch of virtual machine vmware spits out
            error message:  "Failed to configure physical device ucom0:
            Invalid argument \nFailed to connect serial0..."

    * Again, this set up has been proven to work just fine:
          o serial cable server COM1 to some other serial device (eg:
            console port on another server)
          o vmware guest using cuaa0 as its COM1

The obvious questions: 

    * Why won't vmware open ucom0?
    * Am I doing something wrong or is it related to the basic nature of
      ucom and/or uplcom?  If the latter, is there a workaround?
    * Is it likely that some other USB-Serial adapter would work
      differently (better)?  (this would suggest that the problem is not
      due to issues with ucom(4) itself).
    * Is this the best list for posting this question?

Musings:

    * I am thinking that this problem may relate to ucom(4) not really
      providing full sio(4)-like (I think this is the case anyhow)
      functionality.  The ucom(4) man page says it  behaves like
      tty(4).... am I doomed just right off the bat because of this?
    * I am not sure how the port should best be configured.   There
      appears to be nothing like sio(4)'s initial-state and lock-state
      devices.  I've been able to config ucom0 with stty(1), but only
      while it is open by an application.  All config changes are lost
      as soon as the application closes the port.
    * I thought perhaps that there might be some support for callout /
      callin /dev entries, similar to sio(4).  Digging in
      /sys/dev/usb/ucomvar.h revealed:
          o

#define UCOM_CALLOUT_MASK       0x80

#define UCOMUNIT_MASK           0x3ff7f
#define UCOMDIALOUT_MASK        0x80000
#define UCOMCALLUNIT_MASK       0x40000

          o The device file minor number is by default

UCOM_CALLOUT_MASK + unit_number

          o I tried creating device files with minor numbers of both
            0x80000 and 0x80080 but attempt to open produce the error
            message "device not configured."


So ... that's that story.   Any and all help is greatly appreciated.

Thanks much,

-- 
-------------------------------------------------------------------------
  Charles N. Owens                                Email: owensc at enc.edu
                                             http://www.enc.edu/~owensc
  Senior Technology Officer
  Information Technology Services              Eastern Nazarene College
-------------------------------------------------------------------------