SV 125 PS2 to Sun converter issue (keyboard not detected)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

SV 125 PS2 to Sun converter issue (keyboard not detected)

Mike Malopolski
Greetings to all, this is my first post to the OpenBSD mailing lists.

I have used OpenBSD for many years with great success.  I looked in the
man pages and years of message archives for this, but didn't see
anything about this subject.

I am using a Starview PS2 to Sun converter (SV 125), here is a link:
http://www.newegg.com/Product/Product.aspx?Item=N82E16817707030

I have installed 4.8-RELEASE onto a Sun Ultra 80 (sparc64), it works
great with the Sun keyboard / mouse.  However, when a PS2 keyboard /
mouse is plugged in, the keyboard is not detected.  My ultimate goal
is to hook this machine up to a PS2 KVM.

I have put two dmesg outputs at the bottom of this message, one with
the Sun keyboard / mouse, the other with a PS2 keyboard / mouse hooked
up with the SV 125.  I apologize for the over 72 character limit on the
dmesg output, but I figured that it was better not to edit them.

Hopefully someone can point me in the right direction to fix this, I
am guessing someone else has used one of these before.

Thanks in advance for the help.

Here is the dmesg output (with the Sun keyboard / mouse):
-----------------------------------------------------------------------
console is keyboard/display
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2010 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.8 (GENERIC.MP) #93: Mon Aug 16 09:28:24 MDT 2010
    [hidden email]:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 4294967296 (4096MB)
avail mem = 4215848960 (4020MB)
mainbus0 at root: Sun Ultra 80 UPA/PCI (2 X UltraSPARC-II 450MHz)
cpu0 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 450.031 MHz
cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 4096K
external (64 b/l)
cpu1 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 450.031 MHz
cpu1: physical 16K instruction (32 b/l), 16K data (32 b/l), 4096K
external (64 b/l)
psycho0 at mainbus0 addr 0xfffb4000: SUNW,psycho, impl 0, version 4, ign 7c0
psycho0: bus range 0-0, PCI bus 0
psycho0: dvma map fe000000-ffffffff, STC0 enabled
pci0 at psycho0
ebus0 at pci0 dev 1 function 0 "Sun PCIO EBus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
72c000-72c003, 72f000-72f003
power0 at ebus0 addr 724000-724003 ivec 0x25
"SUNW,pll" at ebus0 addr 504000-504002 not configured
uperf0 at ebus0 addr 500000-500007: model SUNW,sc-qp (0/1) ports 9
sab0 at ebus0 addr 400000-40007f ivec 0x2b: rev 3.2
sabtty0 at sab0 port 0
sabtty1 at sab0 port 1
comkbd0 at ebus0 addr 3083f8-3083ff ivec 0x29: layout 34
wskbd0 at comkbd0: console keyboard
comms0 at ebus0 addr 3062f8-3062ff ivec 0x2a
wsmouse0 at comms0 mux 0
lpt0 at ebus0 addr 3043bc-3043cb, 300398-300399, 700000-70000f ivec 0x22: polled
"fdthree" at ebus0 addr 3023f0-3023f7, 706000-70600f, 720000-720003
ivec 0x27 not configured
clock1 at ebus0 addr 0-1fff: mk48t59
"flashprom" at ebus0 addr 0-fffff not configured
audioce0 at ebus0 addr 200000-2000ff, 702000-70200f, 704000-70400f,
722000-722003 ivec 0x23 ivec 0x24: nvaddrs 0
audio0 at audioce0
hme0 at pci0 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7e1, address
08:00:20:e9:43:3d
luphy0 at hme0 phy 1: LU6612 10/100 PHY, rev. 1
siop0 at pci0 dev 3 function 0 "Symbios Logic 53c875" rev 0x14: ivec
0x7e0, using 4K of on-board RAM
scsibus0 at siop0: 16 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <FUJITSU, MAP3735NC, 5605> SCSI3 0/direct fixed
sd0: 70007MB, 512 bytes/sec, 143374650 sec total
st0 at scsibus0 targ 4 lun 0: <HP, C1537A, L007> SCSI2 1/sequential removable
cd0 at scsibus0 targ 6 lun 0: <TOSHIBA, DVD-ROM SD-M1401, 1009> SCSI2
5/cdrom removable
siop1 at pci0 dev 3 function 1 "Symbios Logic 53c875" rev 0x14: ivec
0x7e6, using 4K of on-board RAM
scsibus1 at siop1: 16 targets, initiator 7
psycho1 at mainbus0 addr 0xfffc6000: SUNW,psycho, impl 0, version 4, ign 7c0
psycho1: bus range 128-128, PCI bus 128
psycho1: dvma map fe000000-ffffffff, STC0 enabled, STC1 enabled
pci1 at psycho1
ifb0 at pci1 dev 1 function 0 "Intergraph Expert3D" rev 0x64
ifb0: Expert3D (SUNW,370-3987), 1280x1024
wsdisplay0 at ifb0 mux 1: console (std, sun emulation), using wskbd0
"counter-timer" at mainbus0 addr 0xfff9fc00 not configured
softraid0 at root
siop0: target 0 now using tagged 16 bit 20.0 MHz 16 REQ/ACK offset xfers
bootpath: /pci@1f,4000/scsi@3,0/disk@0,0
root on sd0a swap on sd0b dump on sd0b
-----------------------------------------------------------------------

Here is the dmesg output (with the PS2 keyboard / mouse on SV 125):
-----------------------------------------------------------------------
console is keyboard/display
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2010 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.8 (GENERIC.MP) #93: Mon Aug 16 09:28:24 MDT 2010
    [hidden email]:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 4294967296 (4096MB)
avail mem = 4215848960 (4020MB)
mainbus0 at root: Sun Ultra 80 UPA/PCI (2 X UltraSPARC-II 450MHz)
cpu0 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 450.026 MHz
cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 4096K
external (64 b/l)
cpu1 at mainbus0: SUNW,UltraSPARC-II (rev 10.0) @ 450.026 MHz
cpu1: physical 16K instruction (32 b/l), 16K data (32 b/l), 4096K
external (64 b/l)
psycho0 at mainbus0 addr 0xfffb4000: SUNW,psycho, impl 0, version 4, ign 7c0
psycho0: bus range 0-0, PCI bus 0
psycho0: dvma map fe000000-ffffffff, STC0 enabled
pci0 at psycho0
ebus0 at pci0 dev 1 function 0 "Sun PCIO EBus2" rev 0x01
auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
72c000-72c003, 72f000-72f003
power0 at ebus0 addr 724000-724003 ivec 0x25
"SUNW,pll" at ebus0 addr 504000-504002 not configured
uperf0 at ebus0 addr 500000-500007: model SUNW,sc-qp (0/1) ports 9
sab0 at ebus0 addr 400000-40007f ivec 0x2b: rev 3.2
sabtty0 at sab0 port 0
sabtty1 at sab0 port 1
comkbd0 at ebus0 addr 3083f8-3083ff ivec 0x29: no keyboard
comms0 at ebus0 addr 3062f8-3062ff ivec 0x2a
wsmouse0 at comms0 mux 0
lpt0 at ebus0 addr 3043bc-3043cb, 300398-300399, 700000-70000f ivec 0x22: polled
"fdthree" at ebus0 addr 3023f0-3023f7, 706000-70600f, 720000-720003
ivec 0x27 not configured
clock1 at ebus0 addr 0-1fff: mk48t59
"flashprom" at ebus0 addr 0-fffff not configured
audioce0 at ebus0 addr 200000-2000ff, 702000-70200f, 704000-70400f,
722000-722003 ivec 0x23 ivec 0x24: nvaddrs 0
audio0 at audioce0
hme0 at pci0 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7e1, address
08:00:20:e9:43:3d
luphy0 at hme0 phy 1: LU6612 10/100 PHY, rev. 1
siop0 at pci0 dev 3 function 0 "Symbios Logic 53c875" rev 0x14: ivec
0x7e0, using 4K of on-board RAM
scsibus0 at siop0: 16 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <FUJITSU, MAP3735NC, 5605> SCSI3 0/direct fixed
sd0: 70007MB, 512 bytes/sec, 143374650 sec total
st0 at scsibus0 targ 4 lun 0: <HP, C1537A, L007> SCSI2 1/sequential removable
cd0 at scsibus0 targ 6 lun 0: <TOSHIBA, DVD-ROM SD-M1401, 1009> SCSI2
5/cdrom removable
siop1 at pci0 dev 3 function 1 "Symbios Logic 53c875" rev 0x14: ivec
0x7e6, using 4K of on-board RAM
scsibus1 at siop1: 16 targets, initiator 7
psycho1 at mainbus0 addr 0xfffc6000: SUNW,psycho, impl 0, version 4, ign 7c0
psycho1: bus range 128-128, PCI bus 128
psycho1: dvma map fe000000-ffffffff, STC0 enabled, STC1 enabled
pci1 at psycho1
ifb0 at pci1 dev 1 function 0 "Intergraph Expert3D" rev 0x64
ifb0: Expert3D (SUNW,370-3987), 1280x1024
wsdisplay0 at ifb0 mux 1: console (std, sun emulation)
"counter-timer" at mainbus0 addr 0xfff9fc00 not configured
softraid0 at root
siop0: target 0 now using tagged 16 bit 20.0 MHz 16 REQ/ACK offset xfers
bootpath: /pci@1f,4000/scsi@3,0/disk@0,0
root on sd0a swap on sd0b dump on sd0b
-----------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: SV 125 PS2 to Sun converter issue (keyboard not detected)

Theo de Raadt
> I am using a Starview PS2 to Sun converter (SV 125), here is a link:
> http://www.newegg.com/Product/Product.aspx?Item=N82E16817707030
>
> I have installed 4.8-RELEASE onto a Sun Ultra 80 (sparc64), it works
> great with the Sun keyboard / mouse.  However, when a PS2 keyboard /
> mouse is plugged in, the keyboard is not detected.  My ultimate goal
> is to hook this machine up to a PS2 KVM.

I have used various kinds of these in the past, some with success and
some not.  The real issue is that some KVM's confuse the converter
and something goes wrong.

This one doesn't have a seperate power feed, right?  Those suck power
off the keyboard and video connectors.  Well, the black one I have
sucks it off both...

I don't think we are doing anything very wrong, except perhaps it is
timing related...

Reply | Threaded
Open this post in threaded view
|

Re: SV 125 PS2 to Sun converter issue (keyboard not detected)

Mike Malopolski
You are correct in the fact that this particular one (SV 125) is not
powered separately.  It works fine in Solaris as well as at the "Forth"
{ok} prompt.

I have not hooked it up to a KVM yet, at this point, I am testing it
with a normal PS2 keyboard and mouse.  I have tried multiple keyboards.

It should be noted as well that when I use the machine with the PS2
keyboard that I cannot enter any text, but when I shut it down remotely
I can then see text that I tried to enter with the PS2 keyboard at the
"Forth" {ok} prompt.

If anyone happens to remember which combinations (machine & converter)
have worked, please let me know.

Thanks for the help so far.

On Fri, Mar 11, 2011 at 10:42 AM, Theo de Raadt <[hidden email]>
wrote:

>> I am using a Starview PS2 to Sun converter (SV 125), here is a link:
>> http://www.newegg.com/Product/Product.aspx?Item=N82E16817707030
>>
>> I have installed 4.8-RELEASE onto a Sun Ultra 80 (sparc64), it works
>> great with the Sun keyboard / mouse.  However, when a PS2 keyboard /
>> mouse is plugged in, the keyboard is not detected.  My ultimate goal
>> is to hook this machine up to a PS2 KVM.
>
> I have used various kinds of these in the past, some with success and
> some not.  The real issue is that some KVM's confuse the converter
> and something goes wrong.
>
> This one doesn't have a seperate power feed, right?  Those suck power
> off the keyboard and video connectors.  Well, the black one I have
> sucks it off both...
>
> I don't think we are doing anything very wrong, except perhaps it is
> timing related...

Reply | Threaded
Open this post in threaded view
|

Re: SV 125 PS2 to Sun converter issue (keyboard not detected)

Miod Vallat
> You are correct in the fact that this particular one (SV 125) is not
> powered separately.  It works fine in Solaris as well as at the "Forth"
> {ok} prompt.
>
> I have not hooked it up to a KVM yet, at this point, I am testing it
> with a normal PS2 keyboard and mouse.  I have tried multiple keyboards.
>
> It should be noted as well that when I use the machine with the PS2
> keyboard that I cannot enter any text, but when I shut it down remotely
> I can then see text that I tried to enter with the PS2 keyboard at the
> "Forth" {ok} prompt.
>
> If anyone happens to remember which combinations (machine & converter)
> have worked, please let me know.

I have been playing with the official Sun PS/2 adaptor brick in the
past, without any issues (can't tell you the Sun partnumber at the
moment, that device is still packed somewhere in a box).

If the OpenBSD kernel reports there is no keyboard, it is likely that
the adaptor does not correctly handle a Sun keyboard reset sequence (or
with relaxed timing). You might want to tinker in
sys/arch/sparc64/dev/comkbd_ebus.c comkbd_init() to figure out what
causes the code to consider the reset sequence did not get acknowledged
properly.

Miod

Reply | Threaded
Open this post in threaded view
|

Re: SV 125 PS2 to Sun converter issue (keyboard not detected)

Mike Malopolski
Miod,

Following the suggestion you gave, I looked at the comkbd_init()
function in sys/arch/sparc64/dev/comkbd_ebus.c, it seemed that in
order for the "no keyboard" statement to be printed that code tried and
failed the keyboard reset sequence five times.  The sequence itself
looked to attempt to send the reset command, check 1000 times (waiting
1 millisecond [1000 microseconds] between) to see if the keyboard was
in the reset state.  Next, it checked if the keyboard was "ready",
using similar logic.  Finally, it sent the layout request and waited
using similar logic.

Using your assumption that the keyboard was not handling the
reset sequence (or being slow about it), I increased the delay period
from 1 millisecond (1000 microseconds) to 3 milliseconds (3000
microseconds) for each of the three portions of the comkbd_init()
function (each call to DELAY() in comkbd_init() function).

Rebuilt the kernel, and gave it a try.  I am happy to report that I
have booted the computer three times with the SV 125 converter (and a
PS2 keyboard hooked up), and each time it was properly handled and
worked well.

Next step (later in the week) I will hook it up to the PS2 KVM and
get X running (I will report results)

Not sure if that would be a proper fix to include in the source code,
I will let the proper people decide that.  I can provide a patch file
if anyone is interested or someone can easily follow what I did above.

Thank you very much for the information.

On Sat, Mar 12, 2011 at 5:33 PM, Miod Vallat <[hidden email]> wrote:

>> You are correct in the fact that this particular one (SV 125) is not
>> powered separately.  It works fine in Solaris as well as at the "Forth"
>> {ok} prompt.
>>
>> I have not hooked it up to a KVM yet, at this point, I am testing it
>> with a normal PS2 keyboard and mouse.  I have tried multiple keyboards.
>>
>> It should be noted as well that when I use the machine with the PS2
>> keyboard that I cannot enter any text, but when I shut it down remotely
>> I can then see text that I tried to enter with the PS2 keyboard at the
>> "Forth" {ok} prompt.
>>
>> If anyone happens to remember which combinations (machine & converter)
>> have worked, please let me know.
>
> I have been playing with the official Sun PS/2 adaptor brick in the
> past, without any issues (can't tell you the Sun partnumber at the
> moment, that device is still packed somewhere in a box).
>
> If the OpenBSD kernel reports there is no keyboard, it is likely that
> the adaptor does not correctly handle a Sun keyboard reset sequence (or
> with relaxed timing). You might want to tinker in
> sys/arch/sparc64/dev/comkbd_ebus.c comkbd_init() to figure out what
> causes the code to consider the reset sequence did not get acknowledged
> properly.
>
> Miod

Reply | Threaded
Open this post in threaded view
|

Re: SV 125 PS2 to Sun converter issue (keyboard not detected)

Miod Vallat
> function in sys/arch/sparc64/dev/comkbd_ebus.c, it seemed that in
> order for the "no keyboard" statement to be printed that code tried and
> failed the keyboard reset sequence five times.

That's right.

> Using your assumption that the keyboard was not handling the
> reset sequence (or being slow about it), I increased the delay period
> from 1 millisecond (1000 microseconds) to 3 milliseconds (3000
> microseconds) for each of the three portions of the comkbd_init()
> function (each call to DELAY() in comkbd_init() function).
>
> Rebuilt the kernel, and gave it a try.  I am happy to report that I
> have booted the computer three times with the SV 125 converter (and a
> PS2 keyboard hooked up), and each time it was properly handled and
> worked well.

Now that's good news! But turning the `ltries = 1000' to `ltries = 3000'
will cause a systems with no keyboard to wait 15 seconds, instead of 5
seconds, at boot time, and this will be horribly annoying (the existing
5 seconds are barely tolerable).

Could you print the value of `ltries' after each of the three loops
exits? This would give us a rough estimate of the real time it takes for
your converter to reply. I'd expect the first loop to take some time,
and the last two to be quick.

We could then change the first
        ltries = 1000;
statement to something like
        ltries = tries >= 4 ? 2500 : 1000;
to only increase the `missing keyboard' delay from 5 to 8 seconds (with
these values, hopefully these can be lowered even more).

Miod

Reply | Threaded
Open this post in threaded view
|

Re: SV 125 PS2 to Sun converter issue (keyboard not detected)

Mike Malopolski
Miod,

I spent a few hours today debugging different loops and timings, some
interesting results:

When I got the SV 125 device working yesterday, I did not change the
ltries variable in the loops, but instead I increased the value sent
into the DELAY() function from 1000 to 3000.  However, if no keyboard
was present, it would still wait 15 seconds (which was your point this
morning), which is way too long for serial users.

Today I changed the value sent to DELAY() back to 1000 in the loops,
and increased the ltries variable from 1000 to 3000 (and added printout
of its value after each while loop).  The first two loops (the one that
waits for the SKEY_STATE_RESET state and the one that waits for the
SKEY_STATE_GETKEY state) always complete within the 1000 tries.  If a
delay is not in place before the SKEY_CMD_LAYOUT is sent, the SV 125
must not respond properly, because the third loop does not get anything
other then -1 in 1000 tries.  The biggest indicator of this was that if
I had the printf() for the ltries inside the condition that executes
the break, it delayed the execution long enough for the keyboard to
always work.  If I stored the ltries value in a temporary variable and
printed out all three of them after the loops, then the keyboard would
not be recognized.

After all of that, I added a 3000 microsecond delay right before the
SKBD_CMD_LAYOUT request because I assumed that the reason it worked
yesterday was due to the longer delay (as opposed to the number of
tries).  That worked, the SV 125 converter works correctly with that
modification.

The best part about that is if no keyboard is present, it will not
increase the time it takes to boot (even if it did it would be .003 of
a second * 5 for total of .015 of a second), but works with the SV 125.

Again, I am not sure if this is something that anyone other then me
would want, so if anyone is interested I included a unified diff output
at the bottom of this message.

Thanks for everyone's help.

Regards,

Mike.

--- comkbd_ebus.c.orig  Sat Mar 12 23:49:38 2011
+++ comkbd_ebus.c Sun Mar 13 19:22:21 2011
@@ -483,6 +483,7 @@
      if (ltries == 0)
         continue;

+      DELAY(3000);

      /* Send layout request */
      comkbd_putc(sc, SKBD_CMD_LAYOUT);

Reply | Threaded
Open this post in threaded view
|

Re: SV 125 PS2 to Sun converter issue (keyboard not detected)

Mike Malopolski
I got around to testing the converter with a PS2 KVM, works same as
with normal keyboard and mouse.

Thanks,

Mike.

On Sun, Mar 13, 2011 at 8:08 PM, Mike Malopolski <[hidden email]> wrote:

> Miod,
>
> I spent a few hours today debugging different loops and timings, some
> interesting results:
>
> When I got the SV 125 device working yesterday, I did not change the
> ltries variable in the loops, but instead I increased the value sent
> into the DELAY() function from 1000 to 3000.  However, if no keyboard
> was present, it would still wait 15 seconds (which was your point this
> morning), which is way too long for serial users.
>
> Today I changed the value sent to DELAY() back to 1000 in the loops,
> and increased the ltries variable from 1000 to 3000 (and added printout
> of its value after each while loop).  The first two loops (the one that
> waits for the SKEY_STATE_RESET state and the one that waits for the
> SKEY_STATE_GETKEY state) always complete within the 1000 tries.  If a
> delay is not in place before the SKEY_CMD_LAYOUT is sent, the SV 125
> must not respond properly, because the third loop does not get anything
> other then -1 in 1000 tries.  The biggest indicator of this was that if
> I had the printf() for the ltries inside the condition that executes
> the break, it delayed the execution long enough for the keyboard to
> always work.  If I stored the ltries value in a temporary variable and
> printed out all three of them after the loops, then the keyboard would
> not be recognized.
>
> After all of that, I added a 3000 microsecond delay right before the
> SKBD_CMD_LAYOUT request because I assumed that the reason it worked
> yesterday was due to the longer delay (as opposed to the number of
> tries).  That worked, the SV 125 converter works correctly with that
> modification.
>
> The best part about that is if no keyboard is present, it will not
> increase the time it takes to boot (even if it did it would be .003 of
> a second * 5 for total of .015 of a second), but works with the SV 125.
>
> Again, I am not sure if this is something that anyone other then me
> would want, so if anyone is interested I included a unified diff output
> at the bottom of this message.
>
> Thanks for everyone's help.
>
> Regards,
>
> Mike.
>
> --- comkbd_ebus.c.orig  Sat Mar 12 23:49:38 2011
> +++ comkbd_ebus.c Sun Mar 13 19:22:21 2011
> @@ -483,6 +483,7 @@
>      if (ltries == 0)
>         continue;
>
> +      DELAY(3000);
>
>      /* Send layout request */
>      comkbd_putc(sc, SKBD_CMD_LAYOUT);

Reply | Threaded
Open this post in threaded view
|

Re: SV 125 PS2 to Sun converter issue (keyboard not detected)

Miod Vallat
In reply to this post by Mike Malopolski
> I spent a few hours today debugging different loops and timings, some
> interesting results:

[...]

> After all of that, I added a 3000 microsecond delay right before the
> SKBD_CMD_LAYOUT request because I assumed that the reason it worked
> yesterday was due to the longer delay (as opposed to the number of
> tries).  That worked, the SV 125 converter works correctly with that
> modification.

Excellent.

I took the liberty to increase this delay to 5 millisecond and add it to
all instances of Sun keyboard attachment.

Thanks for your help in fixing this!

Miod