Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: my bug list
Message-ID: <1993Mar30.003656.2601@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <DERAADT.93Mar11154207@newt.fsa.ca> <1993Mar15.223046.10278@fcom.cc.utah.edu> <DERAADT.93Mar25200858@newt.fsa.ca>
Date: Tue, 30 Mar 93 00:36:56 GMT
Lines: 142
In article <DERAADT.93Mar25200858@newt.fsa.ca> deraadt@fsa.ca (Theo de Raadt) writes:
>In article <1993Mar15.223046.10278@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>> I think you'll find that the majority of the problem here is the PC bus
>> architecture being device-indeterminate. THere is no mechanism whereby I
>> can ask a device "what are you?". This is distictly different from most
>> of the bus architectures out there today (like VME/BI/QBUS/FutureBus/SBUS/
>> etc.).
>
>
>This is NOT the problem that was being talked about. I'd suggest that you
>back and read the original articles in question before you post anything
>more on the topic.
>
>The ISA bus should get reset. If it is reset, then the WD8013 probe will
>work. This has nothing to do with the ROM matching code.
You can't do a device/slot reset on an ISA bus. In order to cause a real
reset, you have to drop out of protected mode and hit the keyboard soft
reset code. This is not necessarily possible on all ISA machines due to
the way one has to drop out of protected mode generally causes a reset --
and the BIOS is relied upon (incorrectly, for your machine) to issue a
bus reset as part of this.
Yes, it's possible to work around, in three ways:
1) The bad way (a change to the probe routine).
2) The elegant way (a change to the device interface).
3) The best way (use the EISA bus instead of the ISA bus).
Soloution 3 depends on Hellmuth Michaelis fix using an interface to reset
the EISA bus which is not available in the ISA bus. The following is an
excerpt from Message-ID: <2066@hcshh.hcs.de> in comp.os.386bsd.bugs:
] I have installed it on a EISA machine with a 1742 and yesterday on a ISA
] machine using a 1542 and both Machines show the same behaviour:
] after a reboot, no bootdrive is found by the bios, i have to press reset,
] after that the scsi drives are identified and all is ok - otherwise
] the driver performs very well, without any other problems.
]
] The EISA machine runs for a long time now, first with a copy from Julian,
] then upgraded with the latest patchkit drivers. Because of the above mentioned
] behaviour, i modified the cpu reset code in /sys/i386/i386/vm_machdep.c to
] issue a EISA bus reset, after that, the machine does a cold boot and
] recognizes the 1742 well after coming out of the reset now. I thought it
] was an EISA speciality, and didn't care much more.
Obviously, this won't work for you unless you get a machine with, if not a
decent, then at least a better-than-ISA bus.
>My WD8013 card probes on a cold boot.
>It does not probe on a warm boot.
>
>Obviously, that's because the probe routine is not causing an interrupt
>from the card. That's because the probe routine tries to cause an
>interrupt, but unfortunately, the card has not been reset, so it ignores
>the particular probe sequence.
Soloution 1 is the expedient suggested by you and several others. The
problem is that it relies on the assumption that a device of the type being
probed exists. This is a fallacy, since it means I can *NOT* have multiple
devices on the same interrupt, only one of which gets attached as a result
of a successful probe. You are using the IRQ as a device discriminator,
and this is invalid, since it blows out the ability to distribute kernels
which whill run on multiple hardware configurations. This is true because
you must attach the intterupt before the probe is complete for the probe
to succeed. This is rats ass bogus.
Soloution 2 depends on modifying every device driver to include a "shutdown"
routine. This is necessary anyway for taking the UART's out of FIFO mode
when using Chris' new com drivers, since the BIOS initialization routine
is too stupid to initialize the hardware from *any* potential state to a
known state; again, since the reset is done by the main processor and not
the bus as a result of it's architecture, this can't be done in a com-card
specific fashion, and thus can not be directly supported in the BIOS reset
code anyway (an ISA deficiency).
The second soloution has a failure mode in the event of a panic, since a
panic does not constitute a normal soft-shutdown.
The second soloution, or something like it, will be necessary to support
the unloading of loadable drivers in future versions of 386BSD in any case,
since we can not rely on a soft or hard reset in the event of a reload of
a previously loaded driver.
>It IS possible to probe that card! Linux does it, Xenix does it, *ETC*.
>If 386BSD does not, THEN IT IS BUSTED.
One of these supports soloution 2; the other makes assumptions about what
hardware is present rather than relying on a probe to provide an accurate
ardware inventory.
You might as well make the argument that 386BSD is "BUSTED" because it runs
in protected mode and can therefore not support the BIOS calls that allow
Diamond SpeedStar hardware to be used in high resoloution modes usable in
DOS; after all:
"It IS possible to use HiRes modes on that card! AutoCAD does it,
MS-Windows does it, *ETC*. If 386BSD does not, THEN IT IS BUSTED."
This is clearly an invalid argument.
>> If you think you can figure out a way to do a real hardware inventory on a
>> PC, tell us about it -- or make the million yourself. 8-).
>
>This has absolutely diddly squat to do with a hardware inventory. VMEbus
>on a Sun does not have a hardware inventory list either. Somehow it
>works just fine in sun3 and sun4 machines, eh?
I disagree. If the probe did not depend on the interrupt and/or the card
being in a known state (as would be the case if the inventory were present
and stateless), a single device/slot reset would be possible without
assuming the probe would succeed. This would be roughly equivalent to
what is done in Ultrix on a VME bus (sorry, but I don't have a Sun with
a VME bus to allow me to provide you with your example).
I have held off posting the second soloution because it requires modifying
every device driver, if only to provide a null routine, it requires the
modification of the device driver interface, and it really belongs in a
release rather than in a patch which some people may or may not choose
to apply (since it effects all unwritten future drivers as well). My code
for this is also heavily modified, since I am not using a static device
table in my kernel any more (necessary to allow an expandable device list
without altering major number when intermediate devices are deleted).
This whole issue has been beaten to death well in the past; perhaps it's
time to reopen the issue with the pending 0.1.5 release; I have been
waiting for 0.2, which I believe has soloution 2 already implemented.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------