Managers,
I want to thank Dr. Tom Blinn & John J. Francini for their responses
to my question (see the end of this message). Once again this list
comes through.
First, I want to make it clear that we had booted "genvmunix" single-
user mode & run "doconfig" with no options after removing the XMI
components when the problem occurred. I knew that this would result
in the removal of the last "xmi" entries in the configuration file,
which is why I stated it this way in my original question.
It turned out that our problem was a bug with the kernel build
process caused by the removal of all of the XMI components (including
the plug-in units (PIU)& the cable that connected the XMI PIU to the
I/O module) & the stale "xmi.h" file from previous kernel builds.
The solution was provided by a suggestion from Dr. Tom Blinn to clean
out the kernel build directory (/usr/sys/HOSTNAME) before running
"doconfig". Once I did this the kernel built successfully.
Once the kernel was built I checked the "xmi.h" file in
/usr/sys/HOSTNAME & found that the "#define NTIOP 0" line was no
longer there. This line conflicting with the "#define NTIOP 1" line
in "pci.h" was what was causing the problem. I would venture to
guess that the kernel build process was finding this file & updating
this line to reflect the removal of the XMI instead of building it
from scratch. Once this file was removed, the process rebuilt it
without this line. While investigating the problem, I had checked
this file on other machines without XMI components & found that this
file contained only the "#define NXMI 0" line. That is why I knew
what the problem was, just not how to fix it.
While composing the above I noticed that my original question had an
error. The contents of the "xmi.h" file when running "doconfig"
after the removal of the XMI entries in the configuration file was as
follows:
#define NTIOP 0
#define NXMI 0
By the way, I noticed that there are files in the /usr/sys/HOSTNAME
directory for each type of BUS supported by DU (pci.h, xmi.h, fbus.h,
etc). Looking at the contents of some of the files in this directory
was very interesting.
I have placed these details in this summary hoping it may help
someone else in the future if they find it while searching the
archives & to share what I have learned while investigating this
problem.
The following response from Tom Blinn when I thanked him for
providing the solution sheds some light on this problem & the kernel
build process:
> You're more than welcome. The kernel configuration process is a messy
> one and sometimes there can be stale data left behind from an old
> config that was done in the same working directory that can confuse a
> new (modified) config. When we do the kernel development work, we
> ALWAYS (well, at least in the production builds) start with a clean
> slate, that is, no working directories, and create everything "on the
> fly". So problems like what you saw (due to stale data in the working
> directory for the configuration process) never get found and fixed in
> the development environment.
>
> There is a bug here -- removing the XMI entries from the config file
> and then just rebuilding in the same directory SHOULD have worked --
> the doconfig that got run SHOULD have cleaned out all the old files
> and the config program and other things that write all those header
> files should NOT have been confused by any stale information from the
> old configuration. But it would be hard to fix it, and since there is
> an easy workaround (once you know about it), it's not likely to get a
> lot of attention as something to get fixed in the future. In fact,
> this whole area is so complicated that trying to fix one bug might
> introduce others.
>
> I'll see about getting a comment added to the documentation, perhaps
> in the reference page for "doconfig", about cleaning out the
> configuration space if there are problems building an "edited"
> configuration.
>
The original question is below:
> We upgraded a DEC 7000 to an AS 8400 last fall. We have since been
> gradually removing the XMI SCSI adapters & replacing them with PCI.
> We removed the last one this past weekend, but when we attempted to
> run "doconfig" to build the kernel after removing the last entries for
> XMI from the configuration file the build failed with the following:
>
> =====================================================================
>
> cc: Warning: ./pci.h, line 2: The redefinition of the macro "NTIOP"
> conflicts with a current definition because the replacement lists
> differ. The redefinition is now in effect.
>
> #define NTIOP 1
> --------------^
> objZ: No such file or directory - lsb_data.o
> *** Exit 1
>
> =====================================================================
>
> I have tracked down the problem to the following header files in
> /sys/HOSTNAME: pci.h & xmi.h. The following is the contents of these
> files when XMI is in the configuration file:
>
> xmi.h
>
> #define NTIOP 1
> #define NXMI 1
>
> pci.h
>
> #define NPCI 1
> #define NTIOP 1
>
> Once we remove the xmi entries from the configuration file the
> contents of the xmi.h file are as follows:
>
> #define NTIOP 0
> #define NXMI 1
>
> This is what causes the problem, but I don't know what to do about it.
>
> Our current method of getting around this problem is to leave the
> uneeded xmi entries in the configuration file.
>
> I have logged a call with CSC, but thought I would see if any of you
> knew the answer while I am waiting for a response.
[=================================
[ Randy Rodgers
[ rrodgers_at_ci.ft-wayne.in.us
[ Senior Systems Programmer
[ Allen County/City of Fort Wayne
[ Information Systems
[ (219)427-5727
[=================================
Received on Wed Jul 28 1999 - 15:36:39 NZST