Following the final release of Sarge, I was able to spend a day and
a half testing the behavior of netcfg with ISA boards in more detail. 
Things are a little clearer now.
        First, the behavior changes if all PCI network boards are removed
from the system.

RUN #1: If I installed only a 3C509 ISA-PNP board, and started OS
installation with

                expert netcfg/dhcp_disable=true

the "Detect network hardware" screen came up, and was followed by a "No
Ethernet card was detected" screen, which listed a large number of network
driver modules.  I selected 3c509, and configured it with a static address. 
        A look at console #2 showed that the driver loaded, the interface
came up, and routes came up to the local subnet and the default route. 
After continuing the installation through 2.4.27 kernel install and re-boot,
the interface came up automatically, and ping worked in both directions.

RUN #2: I used the 2.6.8 kernel for both the installer and
the installed system.  The results were the same.

RUN #3: I did an installation run with the 2.4.27 kernel and a non-PNP ISA
NE-2000 clone, with the jumpers set for IRQ 10 and a base address of 0x300. 
The driver wouldn't load without manually supplied parameters.  When I
selected the ne driver and answered yes to prompting for parameters, and
supplied

                irq=10 io=0x300

the driver loaded, and I was able to configure the interface with a static
address.  Pinging worked after re-boot.
        Looking at the config files, the interface was configured in
/etc/network/interfaces with a static stanza, the driver module was listed
in /etc/modules, and an options statement appeared in /etc/modutils.local
and /etc/modules.conf.  So netcfg configured all this in the conventional
manner, and didn't use the hotplug system for the ISA board.

RUN #4: I repeated the previous run with the 2.6.8 kernel and the NE=2000
clone.  Upon supplying the parameters, the driver failed to load, with the
error message

                Error while running 'modprobe -v ne irq=10 io=0x300'

        The same command worked when I issued it from the command line in
console #2.  I was able to bring up the interface then with the ifconfig and
route commands.  However, one consistent anomaly in this situation is that
the route to the local subnet wasn't listed by the route -n command, until I
also issued a route command to set up the default route.  Then all routes
were listed.
        Configuring the network appeared to work, but the interface didn't
come up after re-boot, and nothing had been written in /etc/modutils/local,
/etc/modules.conf, or /etc/modules.  It appears that something about the 2.6
kernel prevents netcfg from issuing a modprobe command with user-supplied
parameters; possibly it might be forcing modprobe to work in Safe mode.

RUN #5: I removed the NE-2000, and plugged in a 3C509 ISA-PNP board and a
3C905B PCI card.  Then I did an OS install with the 2.4.27 kernel.
        At "Detect network hardware", I hit <Esc> and got the driver
selection screen.  I selected the 3c509 module, it loaded, and I configured
the interface.  The program still wanted to load 3c59x afterward, and I let
it.
        The interface came up after re-boot.  (One truly weird thing
happened, which might be a one-time fluke.  It selected the 10Base2
transceiver, even though the board was plugged into a 10BaseT network at the
time.  There's a well-known bug in the 3c59x driver since kernel 2.4 that
disables hardware auto-detection of the active transceiver and causes it to
always select the 10BaseT transceiver, but I never saw anything like this
with any other driver before.)


SUMMARY AND RECOMMENDATIONS

        Netcfg is almost there.  A small logic correction and some better
screen messages will make it much more friendly to new users.

1.  It is not correct to bypass the module selection screen when a network
board is auto-detected.  The board the user wants to configure may not be
one of the boards that was detected.  Below the list of detected boards, the
screen should ask "Do you need to configure a network board that was not
detected?" or words to that effect.

2.  There is insufficient help for determining what to enter in the driver
options box.  This situation can apply to non-PNP ISA boards, or to PNP
boards configured by isapnp at addresses outside the default list that the
module searches for.  It may also apply when more than one ISA board uses
the same driver.  The only place to look up the proper syntax for a driver's
parameters is in the kernel docs.  For the ne driver, the doc file is
unaccountably missing from the 2.4.27 and 2.6.8 kernel docs; I had to get
the syntax from an old logbook, where I had written it after looking it up
in the 2.2 kernel docs several years ago.  Otherwise I'd have been stumped. 
Therefore, it would be highly desirable to provide separate boxes on the
screen for the IRQ, base address, and transceiver, and have netcfg construct
the proper syntax for the modprobe options.  That's what installers did 10
years ago.

3.  PCI and ISA-PNP boards can be configured easily with either kernel, but
ISA non-PNP boards (at least if driver options need to be entered manually)
can be configured only with the 2.4 kernel.  This is probably a simple
problem to fix.

4.  After the first board is configured, netcfg exits and won't allow any
more interfaces to be configured.  This is unfortunate.  Considering the
complexity of editing all the affected files, especially the diabolical
complexity and inadequate documentation of the way PCI boards are brought up
and down through the hotplug system, it would be extremely beneficial to be
able to use netcfg to configure all the network boards in the system.

5.  Some liaison with the modutils people is in order.  If /etc/modules.conf
is really to be eliminated as their man page suggests, I can't see how
non-PNP ISA boards could possibly be used with the 2.6 kernel.  Abandoning
large slices of the installed base is Not A Good Thing, and will harm
Debian's reputation.  The debian-installer team went to great effort to keep
Debian running on as wide a range of existing hardware as possible; their
accomplishments should not be wasted.

6.  It would be desirable to pass on the netcfg team's deep understanding of
which files are edited for which type of boards under which kernels to the
Debian Reference Manual.  The instructions there for configuring network
interfaces are incomplete.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to