Subject: RE: Intel Ether Express 16
To: 'Herb Peyerl' <>
From: John A. Maier <>
List: netbsd-bugs
Date: 02/14/1996 11:02:35
The problems with messages like the above are:

a) if every driver had "informative" messages like that, then when=20
booting, it's very likely that the autoconfig would scroll off the=20
screen way too fast making diagnosis of other problems more difficult.

I understand the issue of information scrolling off the screen too fast, =
this could easily be solved by displaying the error message then a =
"Press <space> to continue..." message or something along these lines.  =
If you think that is a bad idea, consider a user, like me, that couldn't =
get his Exp16 to work, I had no idea what was going on.  After looking =
at the code I was rather irritating to find out the card was being =
detected but the code was bailing out because of a simple configuration =

Have a flag you that can be set via a command line parameter at the boot =
loader, i.e. netbsd -diag.  If a person, writing a device driver, wants =
to add diagnostic information, they can put in an if statement, hinging =
on this flag.  I do, however realize that kernel size is rather =
important, and enough debug messages can make a kernel larger than =
needed.  Thus an option could be added to the config file for size =

	printf("ie: Your card is dead!\n");
	printf("ie: Press any key to continue.\n");

Additionally, a mode like this would be very nice for cases where I want =
to single step the kernel while loading, just so I have time to read the =
screen and write down what's going on.  The author or porter of the =
autodetection code would just put one of these messages before the =
	printf("ie: Press any key to continue.\n");
return 1; /* everything is okay */

b) Since pretty much every "useful" driver is included in a GENERIC
kernel for installation purposes, those sorts of messages make it=20
very difficult for an installation program to parse and easily determine
the hardware configuration of the machine.

Place the error messages in a particular format and the result messages =
in another.

The "right thing" to do IMO is to more explicitly tell people how to =
the card in the INSTALL notes...=20

It's so easy for us, as propeller heads to say this.  Let's face it, the =
EXP 16 never made it into the INSTALL notes and a short debug message, =
as I propose, would have, at least, pointed me in the right direction.

My solution may not be perfect, but it's a step in the right direction, =
in regards to usability.

What is UNIX's biggest complaint? (not everyone at once)  It's next to =
unusable by a rank UNIX novice, even when you have the manual(s) in =
front of you and you're a DOS or VMS wizz(closest things to UNIX, I =

I don't want UNIX to become DOS by any stretch of the imagination, but =
at least I can hit the F8 and single step the boot process to tell =
what's wrong, to "...scroll off the screen way too fast making diagnosis =
of other problems more difficult" isn't a problem.

Also, if a 16K mapping works and it can be determined by the config that =

said mapping works, then you could send in patches to at least enable =
mapping...  It's very difficult to glean any useful information out of
pasted source-code... Patches are much easier to work with.

Agreed, this was a bad move on my part.  The NetBSD box I'm working on =
was down so I just too a copy of the if_ie.c I had on this machine and =
hand rewrote it, so it has bugs.  Also, in regards to the 16K buffer it =
works, but no thanks to a return 0; I remarked out while debugging.  =
There seems to be a solution though, I just need to look at it.

Also, who ever worked on the EXP 16 driver, I have a question, why =
16Kbyte buffers wont work for you.


*       John A. Maier          * Research and Development                =
* E-mail: * Datastorm Technologies Inc.             =
*                              * Procomm Plus for Windows and DOS        =
*                              * (314) 443-3283                          =