Use the correct number of handles for multihandle returns.
Very, very, rarely on some SMP systems we've seen an 'unstable' type
in the response queue. I dunno whether or not it's a bug in our
handling, or whether there's a cache incoherency issue, but
try to guard against it.
MFC after: 2 weeks
in mddestroy() to properly free already allocated memory.
This fixes a panic when we want to create too big memory backed device
with preallocate memory (-o reserve).
- Remove redundant { }.
MFC after: 1 week
address, nor do we need the alignment requirements, so eliminate them.
This likely means that we can now collapse some of the entries as we
have no need of them anymore (they match other entries and were there
only to get the right attr memory offset of the enet addr).
cards work. These changes depend on the expanded funce parsing that
just was committed to pccard_cis.c. In NetBSD the ethernet address
was read out of attr memory directly. We rely on the kernel pccard
parser to pulll this information out of what appears to be an obsolete
funce with the information in it.
# I'm still getting the no rx interrupt sometimes with some hub/switches
# for reasons unknown... But usually only one and only when dhclient
# runs.
as type 0, rather than the usualy type 4. Assume that this format is
from an old standard and go with it. The Fujitsu FMV-186A and Silicom
Ethernet cards I have both have tuples with this format, and they are
both pretty old cards.
# if somebody knows for sure, please let me know.
aware of any fe based cards that do anything except network (well,
maybe the fujitsu scsi/lan card, but I've only seen two of those on
ebay in the last 3 years).
virtual COM port. This makes the use of the Dell OpenManage tools on FreeBSD
considerably easier, and is based on Chuck Cranor's original patch for 4.6.
Reviewed by: imp
Tested by: dpk at dpk dot net
MFC after: 1 week
o rework pll setup code to follow h/w specification
o add hint.hifn.X.pllconfig to specify reference clock setup
requirements; default is pci66 which means the clock is
derived from the PCI bus clock and the card resides in a
66MHz slot
Tested on 7955 and 7956 cards; support for 7954 cards not enabled
since we have no cards to test against.
In collaboration with Poul-Henning Kamp.
Reviewed by: phk
MFC after: 1 week
Rather than have a twisty maze of special case allocations, move
instead to a data driven allocation. This should be the most robust
way to cope with the resource problems that the multiplicity of ways
of encoding 5 registers that have the misfortune of not being a power
of 2 nor contiguous.
Also, make it less impossible that pccard will work. I've not been able
to get my libretto floppy working, but it now fails later than before.
phk and I had similar ideas on this during the 5.3 release cycle, but
it wasn't until recently that I could test more than one allocation
scenario.
MFC After: 1 month (5.4 if possible, 5.5 if not)
producers rather than consumers as new-bus resources only handle consumed
resources. We already do this for the other ACPI resource types that
support the producer/consumer attribute.
object (/) rather than the pci bus object when walking the _PRT to force
attach devices. We already look up relative to the root object when doing
interrupt routing.
Suggested by: njl
For such devices, we require _PRS to exist and we warn if any of the
resources in _PRS are not IRQ resources (since we'll have no way of knowing
which of those resources to use without a working _CRS). When it does
come time to set resources, we build up a resource buffer from scratch
as we do for devices with _CRS that only have IRQ resources.
- Fix a bug with setting extended IRQ resources where we set the IRQ value
in the wrong resource structure meaning that whichever IRQ was listed in
_PRS was used instead. This might fix some weird issues on certain boxes
where IRQs > 16 don't seem to work when using ACPI.
- Fix a bug with how we walked the resource buffer after _SRS to call
config_intr() in that the 'end' variable was not properly updated, so we
could either terminate the loop early or loop after the end of the
buffer.
Tested by: pjd
o increase the max per-frame tx descriptor count and the number of tx
buffers for forthcoming fast frame support
o correct the max scatter/gather count; it cannot be larger than the
max(tx,rx,beacon) descriptor counts
