While investigating the serial console problem on the v445 (see my
previous mail), I noticed that Linux has an additional checks for
detecting the broken st16550 chips that don't have a working FIFO. It
has a comment that specifically mentions the "Motorola 8xxx DUART" as
being falsely detected as
On the Sun Fire V445, I'm seeing garbage on the serial line when:
1) The machine gets to the very end of the boot sequence just before
it prints:
OpenBSD/sparc64 (v445.openbsd.org) (console)
login:
2) When I reboot the machine.
In the latter case in fact I get only garbage until I rese
Is there any actual reason for these restrictions ?
I can understanding preventing stuff if it breaks, but I don't think
it does ?
Index: sio.c
===
RCS file: /home/openbsd/cvs/src/lib/libsndio/sio.c,v
retrieving revision 1.10
diff -u
Here's the diff. It's a bit longer than expected, because I took the
opportunity to expand a bit on the error-reporting engine.
The actual "new error" is the bit in var.c.
The rest:
- makes the engine record the current "parse location" while expanding
commands in a gnode.
- tests fatal_errors be
On 08/18/12 13:48, Kenneth R Westerback wrote:
On Sat, Aug 18, 2012 at 12:29:51PM +0200, Marc Espie wrote:
Our make currently "misbehaves" and doesn't treat this as a problem.
A=a
a:
echo ${A
there are several possibilities.
1/ do like gmake and treat this as an actual error.
2/ keep
On 19 August 2012 08:52, wrote:
> Dear all,
>
> I am using openbsd 5.1 i386 arch. While installing openbsd5.1 i get these
> error message.
>
> acpi0 at bios0:rev2uvm_fault (0xd07ea4,.)
> fatal page_fault (6) in supervisor mode
> trap type 6 code 0eipd02ef7ba cs 8 eflage 10006
