Re: ddb input via IPMI virtual console
But what do I gain if the real keyboard and the internal-USB keyboard emulated by IPMI's console redirection are on different USB ports?
Re: ddb input via IPMI virtual console
> ddb should be able to talk to the console keyboard (via polling) What exactly does that mean in case the console keyboard is wscins?
Re: ddb input via IPMI virtual console
> Sorry, my description wasn't clear. I did understand it. The drawback is you don't see the kernel messages (including the fact the machne paniced) on the VGA monitor. You would need to use IPMI.
Re: ddb input via IPMI virtual console
Hello. Sorry, my description wasn't clear. Since you hav an IPMI capable server, you should be able to turn serial port redirection on in the BIOS such that com1 (from NetBSD's point of view) becomes a virtual port which is accessible using the ipmitool program. You would do something like: ipmitool -H 10.10.1.3 -U ADMIN -I lanplus sol activate After you enter the password, you should be connected to the virtual serial port where you can see output or type input. Since this is a serial port as far as NetBSD is concerned, DDB should work. This is a separate session from your virtual console, so you can run it in a separate window. Change the username and IP address shown above to match your setup. To get NetBSD to use that serial port as a console, you'd do something like: cd /usr/mdec installboot -v -o speed=115200 -o console=com1 /dev/boot bootxx_ffsv -Brian On Aug 7, 11:14am, Edgar =?iso-8859-1?B?RnXf?= wrote: } Subject: Re: ddb input via IPMI virtual console } > how about using a serial console in the kernel and then using ipmitool } > to talk to DDB when/if the machine goes down? } I don't have a serial wire through the firewall. } } > but kernel messages won't go there. } It would be an awful drawback not to see the kernel messages on a physical } console. >-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=
Re: ddb input via IPMI virtual console
>> how about using a serial console in the kernel and then using >> ipmitool to talk to DDB when/if the machine goes down? > I don't have a serial wire through the firewall. You have a multiconductor cable; while it's intended for PS/2, if it has at least three conductors (which I believe PS/2 does), it can be used perfectly well as a serial line. You'll need adaptors on the ends of the cable, but they need be only passive adaptors. RS-232 is ridiculously tolerant of layer-1 issues. Unless the insulation is rated for only 6V or something, which strikes me as unlikely enough that I wouldn't even bother checking if it were me in that situation. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: ddb input via IPMI virtual console
On Tue, Aug 07, 2018 at 11:19:28AM +0200, Edgar Fuß wrote: > > Put it in the machine room, use the existing PS/2 keyboards, and... isn't > > the problem solved? > ... as I've been told, DDB isn't able to talk to USB keyboards (or did I > get that wrong?). So I would end with neither IPMI nor real console working. ddb should be able to talk to the console keyboard (via polling), but not additional keyboards. Martin
Re: ddb input via IPMI virtual console
> Since the problem is that the real keyboards are PS/2, the adapters sound > perfect. Ah, yes, that sounds like a perfect solution, but ... > Put it in the machine room, use the existing PS/2 keyboards, and... isn't > the problem solved? ... as I've been told, DDB isn't able to talk to USB keyboards (or did I get that wrong?). So I would end with neither IPMI nor real console working.
Re: ddb input via IPMI virtual console
On Tue, Aug 07, 2018 at 11:14:12AM +0200, Edgar Fuß wrote: > > how about using a serial console in the kernel and then using ipmitool > > to talk to DDB when/if the machine goes down? > I don't have a serial wire through the firewall. You configure the kernel for serial console output and use IPMI to talk to it. Martin
Re: ddb input via IPMI virtual console
> how about using a serial console in the kernel and then using ipmitool > to talk to DDB when/if the machine goes down? I don't have a serial wire through the firewall. > but kernel messages won't go there. It would be an awful drawback not to see the kernel messages on a physical console.
RE: ddb input via IPMI virtual console
>> The real keyboards are PS/2 and I can't change that because it runs >> on a wire physically passing a /real/ firewall, [...] > >(a) Is it possible to run USB over the same conductors used by the PS/2 >cable? (This is a real question; I don't know enough about layer 1 of >either to answer it.) Great question. The answer is "yes, if you're desperate". Keyboards are low-speed or full-speed USB devices, and the signaling is relatively non-critical -- especially if you find a low-speed keyboard. However: >(b) There exist devices that adapt PS/2 to USB in the >PS/2-keyboard-to-USB-host direction. Since the problem is that the real keyboards are PS/2, the adapters sound perfect. https://www.newegg.com/Mouse-Keyboard-PS2-Adapters/SubCategory/ID-3024 US$ 6 pretty reasonable. Put it in the machine room, use the existing PS/2 keyboards, and... isn't the problem solved? If you need USB as well from another source, use a hub (in the machine room). But I confess I'm not clear about that part of what you're trying to do. --Terry
Re: ddb input via IPMI virtual console
> The real keyboards are PS/2 and I can't change that because it runs > on a wire physically passing a /real/ firewall, [...] (a) Is it possible to run USB over the same conductors used by the PS/2 cable? (This is a real question; I don't know enough about layer 1 of either to answer it.) (b) There exist devices that adapt PS/2 to USB in the PS/2-keyboard-to-USB-host direction. They are not as common as the other direction (USB keyboard on PS/2 host, which I gather is usually faked rather than truly adapting between the two), but I've seen them often enough to know they exist. Perhaps one could help? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: ddb input via IPMI virtual console
hello. Since you're using IPMI, how about using a serial console in the kernel and then using ipmitool to talk to DDB when/if the machine goes down? You should be able to do this and still have a virtual VGA console, but kernel messages won't go there. This also has the advantage that you can run script(1) and capture DDB output and/or panic messages for posterity if you need them. -Brian On Aug 6, 2:27pm, Edgar =?iso-8859-1?B?RnXf?= wrote: } Subject: ddb input via IPMI virtual console } It looks like my IPMI implementation always emulates a USB keyboard on } the virtual console. The real keyboards are PS/2 and I can't change that } because it runs on a wire physically passing a /real/ firewall, e. g. } a constructive element of the building designed to confine a possible fire } in the server room. It's close to prohibitively expensive to install another } (USB) cable through that and I didn't think about it when I orderd power, } VGA and PS/2 cables to be routed through the firewall. } } Can I have ddb input multiplexed from both PS/2 and USB? >-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=
Re: ddb input via IPMI virtual console
Edgar Fuß >> Can I have ddb input multiplexed from both PS/2 and USB? >To elaborate: I have [snip] >and during normal operation, the virtual console does work as expected. >It's only when the machine panics that I can see on the virtual console what >I would see on the VGA monitor, I just can't enter ddb commands. For a USB keyboard to work with DDB you would need to have a working USB stack. If the kernel has paniced then this won't be true.
Re: ddb input via IPMI virtual console
> Can I have ddb input multiplexed from both PS/2 and USB? To elaborate: I have uhidev0 at uhub5 port 2 configuration 1 interface 0 uhidev0: Winbond Electronics Corp Hermon USB hidmouse Device, rev 1.10/0.01, addr 2, iclass 3/1 ums0 at uhidev0: 3 buttons and Z dir wsmouse0 at ums0 mux 0 uhidev1 at uhub5 port 2 configuration 1 interface 1 uhidev1: Winbond Electronics Corp Hermon USB hidmouse Device, rev 1.10/0.01, addr 2, iclass 3/1 ukbd0 at uhidev1 wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 and during normal operation, the virtual console does work as expected. It's only when the machine panics that I can see on the virtual console what I would see on the VGA monitor, I just can't enter ddb commands.
Re: ddb input via IPMI virtual console
> IPMI is a serial console. IPMI SOL is a serial console. I was talking about the graphical virtual console.
Re: ddb input via IPMI virtual console
e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes: >It looks like my IPMI implementation always emulates a USB keyboard on >the virtual console. The real keyboards are PS/2 and I can't change that >because it runs on a wire physically passing a /real/ firewall, e. g. >a constructive element of the building designed to confine a possible fire >in the server room. It's close to prohibitively expensive to install another >(USB) cable through that and I didn't think about it when I orderd power, >VGA and PS/2 cables to be routed through the firewall. IPMI is a serial console. You could just tell the kernel to use it and console and DDB will be independent of the VGA graphics. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
ddb input via IPMI virtual console
It looks like my IPMI implementation always emulates a USB keyboard on the virtual console. The real keyboards are PS/2 and I can't change that because it runs on a wire physically passing a /real/ firewall, e. g. a constructive element of the building designed to confine a possible fire in the server room. It's close to prohibitively expensive to install another (USB) cable through that and I didn't think about it when I orderd power, VGA and PS/2 cables to be routed through the firewall. Can I have ddb input multiplexed from both PS/2 and USB?
