For unknown devices the output will now be
pci0: unknown card (vendor=0x109e, dev=0x0878) at 14.1 irq 19
instead of
pci0: unknown card DD^0878 (vendor=0x109e, dev=0x0878) at 14.1 irq 19
Before this change, the code used to take the PCI vendor id and translate it
into a three letter ASCII name.
For PnP devices, the vendor id _does_ map to a nice ASCII name
(eg Creative Labs PnP ID maps to "CTL", ESS PnP ID maps to "ESS")
But there is no such mapping for PCI devices, as can be seen by the
example above where the Brooktree PCI vendor ID maps to "DD^"
The PCI Special Interest Group confirmed they do not have any mappings
from vendor ID to ASCII.
of the number of times a particular type has been used. It's rather easy
to overflow. One site I'm looking at seems to do it in a matter of days.
On the Alpha this is a no-op since 'long' is 64 bit already. The sole
user of this interface seems to be vmstat -m and friends which will need
a recompile. The overheads of using a 64 bit int should be pretty light
as the kernel just does "calls++" type operations and that's it.
This is a conservative change. It does the same thing in weird
cases like the old one. For example, 'sleep abcd' still sleeps
for zero seconds. `sleep 10.a' and `sleep 10.05aa' do the best
and not abort (ie: 10.a == 10 seconds, 10.05a == 10.05 seconds).
Turn on the 'new' if_ep driver which supports:
ISA 3c509
MCA 3c529
EISA 3c579
PCCARD 3c589
I think all we're missing is support for the VME bus and S-100 bus
Etherlink III cards.
The new code has been tested by a number of people and all the important
bits work. I've not been able to test the EISA code but will do so once
my hardware arrives. Since I've changed nothing in the EISA code I suspect
it will perform the same manner as before.
Future changes involve whacking the ISA and PCCARD front ends to use
newbus and to convert the driver to bus_space and make it use ifmedia.
This is the first working network driver that supports MCA bus devices btw.
Enjoy.
(behind the built-in ppb on hose 1) to be found:
When testing the adaptec controller on alpha, I realized I misread the xp1000
documentation and the way I'm calculating the bus number for PCI
config space accesses on the tsunami is wrong. I had thought that a bus
behind a ppb should be numbered as the nth bus in that hose, but it
actually needs to be the nth global bus within the system. The bus number
for the primary bus on a hose must always remain 0 when calculating config
space addresses.
and/or when using the card.
o Convert the driver to using bus_space. This allows alphas with
fxp's to boot, rather than panic'ing because rman_get_virtual()
doesn't really return a virtual address on alphas.
o Fix an alpha unaligned access error caused by some misfeature of
gcc/egcs: if link_addr & rbd_addr in the fxp_rfa struct are 32 bit
quantities, egcs will assume they are naturally aligned. So it will do
a ldl & some shifty/masky to twiddle 16 bit values in fxp_lwcopy().
However, if they are 16-bit aligned, the ldl will actually be done on
a 16-bit aligned value & we will panic with an unaligned access
error... Changing their definition to an array of chars seems to fix
this. I obtained this from NetBSD.
I've tested this on both i386 & alpha.
a 2940UW. The dp264 (and ds20, I think) have an AIC7895 on board so it
is important the ahc driver be in GENERIC so that FreeBSD can install on
these boxes.
around meant that the higher level close routine never gets called.
(phk is on the road; this is a quick fix to get things working and may need
more polish)
doscmd heavily depends on struct sigcontext which luckily is mostly passed
between functions as usion regcontext_t. By redefining union regcontext_t in
terms of mcontext_t almost all bases are covered.
It also seems to me that doscmd was in a transitional state. The redundant
definitions made it difficult to get a clear overview and could easily cause
oversight. To make sure my changes were ok, I went as far as to complete the
transition. It was not exactly necessary, but I expect to have to come back
here some more ("whistle" if I'm wrong :-).
error for a directory. I have made this change after a great deal of
review although I cannot be absolutely sure that this meets the spec.
The issue devolves into whether changes in an underlying (UFS) directory
can cause NFS directory blocks to be renumbered. My read of the code
indicates that NFS directory blocks will not be renumbered, which means
that the cookies should still remain valid after a change is made to
the underlying directory. This being the case, a cookie error should
not be returned when a change is made to the underlying directory and,
instead, the NFS client should rely on mtime detection to invalidate and
reload the directory.
The use of mtime is problematic in of itself, due to insufficient
resolution, which is why I believe the original conservative error
handling was done. Still, there have been dozens of bug reports by
people needing solaris<->FreeBSD interoperability and these have to
be accomodated.
