From owner-freebsd-hardware  Sat May  9 04:20:13 1998
Return-Path: <owner-freebsd-hardware@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id EAA04624
          for freebsd-hardware-outgoing; Sat, 9 May 1998 04:20:13 -0700 (PDT)
          (envelope-from owner-freebsd-hardware@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA04619
          for <freebsd-hardware@FreeBSD.ORG>; Sat, 9 May 1998 04:20:05 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id VAA30393;
	Sat, 9 May 1998 21:15:56 +1000
Date: Sat, 9 May 1998 21:15:56 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199805091115.VAA30393@godzilla.zeta.org.au>
To: freebsd-hardware@FreeBSD.ORG, gavin@itworks.com.au
Subject: Re: Serial port problems
Sender: owner-freebsd-hardware@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>I've just acquired 2 servers to run 2.2.6-RELEASE on. They are both using
>Iwill P55XUB motherboards. The book that came with the motherboard says
>that the onboard serial ports are NS16C550 compatible.

It apparently misspells `incompatible' :-).  There have been several
reports that serial ports on Iwills don't work under FreeBSD.

>If I boot up using a serial console I get the boot messages coming through
>loud and clear (so the serial port was probed and is working), but the

This doesn't follow.  The boot messages are printed by an independent part
of the driver that doesn't probe the ports or use interrupts.

>kernel panic as soon as is probes for the serial ports. The last message
>before the cu session closed is 
>  Probing for devices ocu: Got hangup signal
>
>which is the probing of the ISA bus message.
>
>If I cu again and enter cont into ddb I get
>
>Fatal trap 12: page fault while in kernel mode
>fault virtual address   = 0x4
>fault code              = supervisor read, page not present
>instruction pointer     = 0x8:0xf01c37ee
>stack pointer           = 0x10:0xefbfff80
>frame pointer           = 0x10:0xefbfff80
>code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, def32 1, gran 1
>processor eflags        = interrupt enabled, resume, IOPL = 0
>current process         = 0 ()
>interrupt mask          =
>kernel: type 12 trap, code=0
>Stopped at      _cninit_finish+0x26:    movl    0x4(%edx),%eax

The panic is caused by a null pointer bug (cdevsw[SIO_MAJOR] = 0, and
cninit_finish() doesn't check).  It shows that all sio probes failed,
but we already know that.

The hangup is more interesting.  The console output routines attempt to
switch the h/w state so that you can debug sio probes using sio output,
but switching the DTR state back off might cause avoidable hangups, so
DTR is left on.

To debug the probes, you have to start earlier.  Boot with -d and put
a breakpoint at sioprobe() and look around.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message