Re: Hardware Console Redirection

2006-11-03 Thread Herb Peyerl


On 3-Nov-06, at 11:13 AM, Brian A. Seklecki wrote:



With the Real Weasel, you could connect on demand and force a screen
refresh/redraw and it would grab the current VGA framebuffer and re- 
write to the TTY.


I invented the Weasel and even I use it in Serial passthrough mode.   
The VGA display is nifty and all, but as a sysadmin, I want more than  
25 lines of display history.


(for those who don't know, serial passthrough, when set to auto,  
causes the weasel to either use its VGA framebuffer or its PCI Uart  
as the source for data to be sent to its serial port; switching  
automatically depending on where the last write occurred by the host  
CPU).



Disclaimer: I no longer have any association with any company or  
individuals who may or may not be dealing in new or used PC Weasels.




___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Hardware Console Redirection

2006-11-03 Thread Tom Judge

Brian A. Seklecki wrote:


Right, and the Dell PE uses "com 2", or "com1" (when properly counting 
from 0), ah la 0x2F8 which is logically connected to a serial port on 
the DRAC5 via the daughterboard connection.



The drac [345] Cards actually hook into or present a new vga adapter to
the system (this can be seen as an ati chipset on the drac 4 pci addin
cards) They also present a soft keyboard an mouse to the system via a
set of usb devices.   If you also use the bios console redirection the
bios is sent to the configured serial port.

FreeBSD fully supports the dell drac [345] cards (at least RELENG_6 does
which i guess means 7 does), I have a largs number of these cards
working perfectly in production.

Using the drac web interface you can send the system a scroll lock and
scroll back the system console as if you where using the physical
console. So there is no need to be conected all of the time.

On a side note it is advisable to put (device kbdmux) into your kernel
if you want to use both the physical console and the drac console
access, otherwise the usb devices provided by the drac disable the
physical keyboard.

If you have DRAC cards in you dell systems I would recomend the console
access in them over serial port redirection as it is much simpler to setup.

Tom



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Hardware Console Redirection

2006-11-03 Thread Brian A. Seklecki

redirection) and use "consdev com0". (Unless you used the bios console
direction at > 9600 bps)


Right, and the Dell PE uses "com 2", or "com1" (when properly counting 
from 0), ah la 0x2F8 which is logically connected to a serial port on the 
DRAC5 via the daughterboard connection.


And that's where Dell, Intel, and Phoenix went totally wrong.

Another big problem with mixing hard and soft serial console redirection 
(at least with FreeBSD) is that kernel panic/trap message output doesn't 
always make it to the serial console (such as UVM faults), where with VGA 
console you almost always get the message.


This killed us several times with FBSD 5.3 and some NFS bugs.

Plus when you're doing serial console redirection, your console server has 
to be configured to be connected 100% of the time and log output to a 
file.  If you get a panic and need to connect on-demand, you'll have 
missed that message to the buffer otherwise.


With the Real Weasel, you could connect on demand and force a screen
refresh/redraw and it would grab the current VGA framebuffer and re-write 
to the TTY.


---

The only macro keys you get with Dell are:

Press the spacebar to pause...

KEY MAPPING FOR CONSOLE REDIRECTION:

Use the <0> key sequence for 
Use the  key sequence for 
Use the <@> key sequence for 

Use the  key sequence for 
Use the  key sequence for 
Use the  key sequence for 
Use the  key sequence for 

Use the  key sequence for , where x is any 
letter

key, and X is the upper case of that key

Use the  key sequence for 

~BAS
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Hardware Console Redirection

2006-11-01 Thread Martin Husemann
On Wed, Nov 01, 2006 at 01:05:04AM -0500, Brian A. Seklecki wrote:
> In either case, forget about sysinst/sysinstall to install off of stock
> install media.

I'm not sure why - just stop the bootloader (still in bios console
redirection) and use "consdev com0". (Unless you used the bios console
direction at > 9600 bps)

Martin
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Hardware Console Redirection

2006-10-31 Thread Brian A. Seklecki
> Why is that a problem?  The BIOS doesn't use the console once
> the kernel has booted.

Because it becomes a burden always having to customize your
install/upgrade media/kernels/bootblocks to use redirection. 

Dell knew that; that's why they made the DRAC4 with a virtual VNC-based
console redirection.  Then the bungled it with the DRAC5 when they
re-wrote it to depend on ActiveX.

Also because the hardware vendors could follow the PC Weasel model and
not utilize a serial port visible to the OS.

With NetBSD its just one or two flags to installboot(8) to change the
options, with the only exception being that we seem to lack the ability
to set the com console _speed_ when in *interactive* mode at boot(8) ;
of course it can be set from the installboot(8) flags.

With FreeBSD, you have to jump through a ring of fire to get it to work
right.  You've got three stages of bootblocks to recompile/configure. 
boot.config.  device.hints. etc. etc.  Then the kernel has to be told
in-src, recompiled.  Then the getty.

In either case, forget about sysinst/sysinstall to install off of stock
install media.  All very possible with the Weasel.

You alway have to consider the the 3:30 AM incident where you're
fumbling though a stack of CD-Rs for a Fixit or Live CD and you have to
wonder if you re-mastered the disc with a boot image containing your
custom serial enabled kernel with the right baud and com port (as you
can see below).

> What serial console semantics do the bootblocks get wrong?

None.  I'm just suggesting that for simplicity it would be nice not to
have to make them aware.

> What sort of reset do you need?  I don't really understand the
> question, I'm afraid.  

Reset my attitude I guess >:}  I'm pining for the days of sparc systems
and a unified serial console server.

When TLS says: "Of course; it is a BIOS feature, and NetBSD does not use
the BIOS for console I/O.", I tend to think of Sun how writing to the
OBP firmware console is not dissimilar from the NetBSD kernel output.

It would be nice to think x86 has caught up over the last 15 years.

Anyway, for the record:

The old PC Weasel Console Redirection:

Phoenix BIOS:
http://digitalfreaks.org/~lavalamp/cp/displayimage.php?album=16&pos=23

NetBSD 2.0 Sysinst:
http://digitalfreaks.org/~lavalamp/cp/displayimage.php?album=16&pos=24

Bios Summary:
http://digitalfreaks.org/~lavalamp/cp/displayimage.php?album=16&pos=22

---

Dell PE750 Console Redirection:
http://digitalfreaks.org/~lavalamp/cp/displayimage.php?album=16&pos=21

Compare where DRAC VNC (IE6 only) VGA redirected console output
continues and the DRAC5 virtual "COM2" serial redirection halts:

http://digitalfreaks.org/~lavalamp/cp/displayimage.php?album=16&pos=27
http://digitalfreaks.org/~lavalamp/cp/displayimage.php?album=16&pos=25
vs.:
http://digitalfreaks.org/~lavalamp/cp/displayimage.php?album=16&pos=29


Dell PE2950 Settings (BIOS nicely drawn via Serial/ANSI):
http://digitalfreaks.org/~lavalamp/cp/displayimage.php?album=16&pos=28


~BAS


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Hardware Console Redirection

2006-10-31 Thread Andrew Reilly
On Tue, Oct 31, 2006 at 06:18:22PM -0500, Brian A. Seklecki wrote:
> I have noticed that the "Phoenix BIOS" console redirection feature on both 
> discontinues to operate once the kernel has booted (however, the 1st/2nd 
> stage boot loaders work fine).

Why is that a problem?  The BIOS doesn't use the console once
the kernel has booted.

> The advantage of native, hardware level BIOS -> VGA emulated console 
> redirection is that, much like Sun/MacPPC or any OPF/PROM aware platform 
> (Soekris), the OS/Bootblocks need not be aware of the serial console 
> semantics; -- only of a benign VGA console.

What serial console semantics do the bootblocks get wrong?

> Is there some routine in the *BSD kernel console code that performs an 
> operation, perhaps a reset, on the serial ports, that wouldn't happen in 
> DOS?

What sort of reset do you need?  I don't really understand the
question, I'm afraid.  Do you mean a hardware reset of the
serial port, or using the serial port to have the effect of
Ctl-Alt-Delete (NMI) from a PC keyboard?

> In the case of the Axiom device, the console is redirected to the BIOS 
> level "com0" 0x3f8.  In the case of the PowerEdge, the redirection is to a 
> "virtual com1" which is attached to the DRAC5 LOM card.
> 
> I tried the FreeBSD loader(8) hint.sio.1.flags="0x40" to attempt to have 
> the kernel ignore the device without success.

You can build a kernel that explicitly doesn't have a driver
that will look at a particular serial port, I think (by making
it explicit which ports it *does* look at), but I don't
understand how that would help: you'd have a serial port that
would be used by the BIOS, but would do nothing once the main OS
was booted.

Cheers,

-- 
Andrew
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"