On Sat, 27 Mar 2010 21:25:25 -0700
STEPHEN JONES, W0TTY s...@cirr.com wrote:
I've also looked using the new boot.cfg file and also installboot,
but there does
not see to be a well documented method for setting up serial console
support.
$ l /usr/mdec/mbr_com0_9600
-r--r--r-- 1 root
s...@cirr.com said:
The issue I have is that if I use 'consdev com0' at the boot prompt,
should I not be able to redirect console output to the serial port on
a PC for any kernel regardless of whether as long as their is driver
support for 'com'?
Generally yes, but two cases come to mind
On Mar 28, 2010, at 6:11 AM, Matthias Drochner wrote:
s...@cirr.com said:
The issue I have is that if I use 'consdev com0' at the boot prompt,
should I not be able to redirect console output to the serial port on
a PC for any kernel regardless of whether as long as their is
driver
On Sat, Mar 27, 2010 at 09:25:25PM -0700, STEPHEN JONES, W0TTY wrote:
Is it possible to force a serial console for the install kernel
available in
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-5.0.2/*/binary/kernel/netbsd-
INSTALL.gz ?
At the boot prompt defining consdev does not seem to have
On Mar 28, 2010, at 8:25 AM, Thor Lancelot Simon wrote:
On Sat, Mar 27, 2010 at 09:25:25PM -0700, STEPHEN JONES, W0TTY wrote:
optionsCONSDEVNAME=\com\,CONADDR=0x2f8,CONSPEED=9600
Are you sure you want 2f8? On typical PCs the serial ports start
at 3f8
and 2f8 is the second one,
On Sun, 28 Mar 2010, STEPHEN JONES, W0TTY wrote:
If your system has serial BIOS, it is probably hiding the first
serial port from the bootblocks so they don't automatically detect
it. This is a change you need to make to the bootblocks -- not
the kernel. Try installboot (possibly with -e
Hello. You're correct. Any kernel that has serial support in it,
i.e. device com* at something, will be able to use any of those serial
devices as console assuming the bios sets the device up at boot time, and
you can tell the boot loader to use that device as a serial console. I use
On Fri, Mar 26, 2010 at 10:24:02AM +0900, Masao Uebayashi wrote:
(Honestly, I see benefit to not convincing you; objection only from
dholland@ sounds more convincing to me than no objections.)
Um. I'm sorry you think that. I guess there is no point continuing
this discussion, then. Or much of
On Fri, Mar 26, 2010 at 01:45:51PM +, Andrew Doran wrote:
I'm speaking of low level kernel code and driver drivers, areas that to
date you have had relatively little involvement in.
That's not entirely true, but fair enough.
I will however consider discussing the points you raise
Mateusz,
Now that NetBSD has dtrace (FBT) for the kernel, have you thought
about how you might use write mode in dtrace to simulate failure?
Is there value in introducing specific dtrace probes (once we have
SDT probes) to support fuzzing?
Are further changes required, such as allowing longer
10 matches
Mail list logo
