Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Feb 2001 21:27:38 -0500
From:      james@targetnet.com
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   bin/25085: mlxcontrol utility fails silently if device file is missing
Message-ID:  <E14SrfO-0009j8-00@fds-301.tor3.targetnet.com>

next in thread | raw e-mail | index | archive | help

>Number:         25085
>Category:       bin
>Synopsis:       mlxcontrol utility fails silently if device file is missing
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 13 18:30:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     James FitzGibbon
>Release:        FreeBSD 4.2-STABLE-20010125-JPSNAP i386
>Organization:
Targetnet.com Inc.
>Environment:

4-STABLE box with a Mylex DAC1164P raid controller, two systems drives on
RAID.

>Description:

If /dev/mlx0 does not exist, 'mlxcontrol status' fails silently.  Because
/dev/mlx# is not created by sysinstall, a default FreeBSD install will have
device files for the disk and it's slices, but not the controller itself.

The error messages (or lack thereof) do not explain the problem easily.  I
only found it by running a ktrace on the process and watching it iteratively
try to open /dev/mlx0 through /dev/mlx63 and then exit.

>How-To-Repeat:

Install FreeBSD on a Mylex-equipped machine.  Immediately after install,
run 'mlxcontrol status'.  Now run 'mlxcontrol status mlx0'.  cd to /dev and
run './MAKEDEV mxl0'.  Repeat both of the commands.

>Fix:

- if a nonstandard piece of hardware is a viable install target, then
sysinstall and MAKEDEV should take that into account.  The mlx0 device
should probably be added to the standard devices to create upon
installation.

- mlxcontrol should perhaps test for the existence of the special file
/dev/mlx# instead of just attempting to open it and fail.  Additionally, if
the loop that tests mlx0-mlx63 expires without a successful open, a suitable
error message should be spit out.

- the points on device creation probably apply to some of the other RAID
for which drivers have recently been added: amr, ida.  There may not be a
userland control utility for either AFAIK, but the argument holds true for
anything that is in the GENERIC kernel, so...

>Release-Note:
>Audit-Trail:
>Unformatted:


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E14SrfO-0009j8-00>