a module. Also modified the code to work on FreeBSD/alpha and added
device vr0 to the alpha GENERIC config.
While I was in the neighborhood, I noticed that I was still using
#define NFPX 1 in all of the Makefiles that I'd copied from the fxp
module. I don't really use #define Nfoo X so it didn't matter, but
I decided to customize this correctly anyway.
Isn't really that useful.
chip0: <PCI to Other bridge (vendor=10e0 device=8849)> at device 0.0 on pci0
is more in keeping with the spirit of the rest of the code.
Previous behavior with regard to truely unknown bridges unchanged.
"<Anti-Bill> Tell you what: you have commit privs now. You do it."
reset command.
I observed some anomalous behavior while testing a 3c905C with a
Dell PowerEdge 4300/500 dual PIII 500Mhz system. The NIC would seem
to work correctly most of the time but would sometimes fail to receive
certain packets, in particular NFS create requests. I could mount
an NFS filesystem from the PowerEdge and do an ls on it, but trying
to do a "touch foo" would hang. Monitoring traffic from another host
revealed that the client was properly sending an NFS create request
but the server was not receiving it. It *did* receive it when I
ran the same test with an Intel fxp card.
I don't understand the exact mechanics of this strange behavior, but
resetting the receiver and transmitter seems to get rid of it. I used
to perform an RX and TX reset in xl_init(), but stopped doing it there
because on 3c905B and later cards this causes the autoneg session to
restart, which would lead to the NIC waiting a long time before exchanging
traffic after being brought up the first time. Apparently the receiver
and transmitter resets should be performed at least once when initializing
the card.
Hopefully this will cure problems that people have been having with the
3c905C -- this was the only strange behavior that I have observed with
the 3c905C so far which does not appear with the 3c905B or 3c905.
- device_print_child() either lets the BUS_PRINT_CHILD
method produce the entire device announcement message or
it prints "foo0: not found\n"
Alter sys/kern/subr_bus.c:bus_generic_print_child() to take on
the previous behavior of device_print_child() (printing the
"foo0: <FooDevice 1.1>" bit of the announce message.)
Provide bus_print_child_header() and bus_print_child_footer()
to actually print the output for bus_generic_print_child().
These functions should be used whenever possible (unless you can
just use bus_generic_print_child())
The BUS_PRINT_CHILD method now returns int instead of void.
Modify everything else that defines or uses a BUS_PRINT_CHILD
method to comply with the above changes.
- Devices are 'on' a bus, not 'at' it.
- If a custom BUS_PRINT_CHILD method does the same thing
as bus_generic_print_child(), use bus_generic_print_child()
- Use device_get_nameunit() instead of both
device_get_name() and device_get_unit()
- All BUS_PRINT_CHILD methods return the number of
characters output.
Reviewed by: dfr, peter
equivalent to SYS_RES_MEMORY for x86 but for alpha, the rman_get_virtual()
address of the resource is initialised to point into either dense-mapped
or bwx-mapped space respectively, allowing direct memory pointers to be
used to device memory.
Reviewed by: Andrew Gallatin <gallatin@cs.duke.edu>
This function is called for each device for which no driver
was found.
Output is similar to the eisa_probe_nomatch() function but with the
added benefit of displaying the assigned IRQ (since PCI gives us
this information up front.)
Output is like so:
pci0: unknown card CPQ0508 (vendor=0x0e11, dev=0x0508) at 11.0 irq 9
pci0: unknown card DFZ0508 (vendor=0x10da, dev=0x0508) at 11.0 irq 9
pci0: unknown card DBL0508 (vendor=0x104c, dev=0x0508) at 11.0 irq 9
pci0: unknown card DDM0011 (vendor=0x108d, dev=0x0011) at 11.0 irq 9
I'm not happy with the 3 lines of macro cruft that got added but
I consider it a temporary annoyance as those bits will be moved to
some place where PCI, EISA and ISAPNP code will be able to use them.
(Not surprisingly, this message is longer than the code in question.)
Reviewed by: peter, dfr
a PCI memory mapped region, rman_get_bushandle() returns what happens
to be a kernel virtual address pointing to the base of the PCI shared
memory window. However this is not the behavior on all platforms:
the only thing you should do with the bushandle is pass it to the
bus_spare_read()/bus_space_write() routines. If you actually do want
the kernel virtual address of the base of the PCI memory window, you
need to use rman_get_virtual().
The problem is that at the moment, rman_get_virtual() returns a physical
address, which is bad. In order to get the kernel virtual address we
need, we have to play with it a little.
Presumeably this behavior will be changed, but in the meantime the
Tigon driver won't work. So for the moment, I'm adding a kludge to
make things happy on the alpha: the correct kernel virtual address
is calculated from the value returned by rman_get_virtual(). This
should be removed once rman_get_virtual() starts doing the right
thing.
This should make the Tigon actuall work on the alpha now.
ethernet controllers based on the AIC-6915 "Starfire" controller chip.
There are single port, dual port and quad port cards, plus one 100baseFX
card. All are 64-bit PCI devices, except one single port model.
The Starfire would be a very nice chip were it not for the fact that
receive buffers have to be longword aligned. This requires buffer
copying in order to achieve proper payload alignment on the alpha.
Payload alignment is enforced on both the alpha and x86 platforms.
The Starfire has several different DMA descriptor formats and transfer
mechanisms. This driver uses frame descriptors for transmission which
can address up to 14 packet fragments, and a single fragment descriptor
for receive. It also uses the producer/consumer model and completion
queues for both transmit and receive. The transmit ring has 128
descriptors and the receive ring has 256.
This driver supports both FreeBSD/i386 and FreeBSD/alpha, and uses newbus
so that it can be compiled as a loadable kernel module. Support for BPF
and hardware multicast filtering is included.
critical mbuf fields to sane values. Simplify the use of ETHER_ALIGN to
enforce payload alignment, and turn it on on the x86 as well as alpha
since it helps with NFS which wants the payload to be longword aligned
even though the hardware doesn't require it.
This fixes a problem with the ti driver causing an unaligned access trap
on the Alpha due to m_adj() sometimes not setting the alignment correctly
because of incomplete mbuf initialization.
the driver_t declaration should be "skc" not "sk". Technically, "skc"
is the parent PCI device (the SysKonnect GEnesis controller) and "sk0"
and "sk1" are the network interfaces that get attached to it.
been booted works too -- very neat. However I don't want the system to
stop for 5 seconds when the MII autoprobe is triggered in the xl and
tl drivers since that's lame. Instead, only use the hard delay when
we've been cold booted. If not, use the timeout mechanism instead.
(The SysKonnect driver doesn't use the same autonegotiation scheme, so
no change is required there.)
Also includes a workaround fro an apparent chip bug
where UDMA mode 2 can overpower the UDMA engine enough that it will
hog the PCI bus to the exclusion of the processor.
into a loadable module, and all of the platform dependencies are gone
(except for the alpha_XXX_dmamap() thing, which is another issue -- I
still don't know how to use the busdma stuff with a network driver).
Also increase the delay in xl_reset(); testing on a 486/66 with a 3c905C
shows that reading the EEPROM fails immediately after a reset. Waiting
a little longer after the reset completes seems to fix it.
interrupts that were scheduled. Testing shows it didn't really do very much
and it makes the code a little more complicated (which is never a good thing).
Also fix the rambuffer offset initialization for the 512K/64K SRAM case
(512K total using 64K chips). It should be 0. The only case with a
non-standard rambuffer offset address is 1024K/64K according to the
SysKonnect manual. (My card has the 1024/64 configuration and I don't know
which card uses the 512/64 configuration, if any, so I'm not sure that
this was really a problem for anyone.)
