the MIF Configuration Register PHY_Select, there is no use in pretending
we could talk to both at the MII interface layer.
If both PHY are reported to be present, prefer the external one.
Remember this selection and enforce it in hme_mii_{read,write}reg.
This fixes problems with one of the dual hmes in Netra T1s.
From OpenBSD.
various orders depending how the upper level driver is flushing it's queue's.
This prevents the deadlocks I was seeing before with >8k writes.
XXX: Still not completely there as > 64k copies trigger bugs and the page
table support still needs to be written to break those down.
FreeBSD, with cleanup/KNF by me.
Note: These chipsets are not well supported by the i810 driver in
NetBSD's in-tree xsrc (based on XFree86 4.2.1 at this time). However,
the driver works perfectly using bleeding-edge XFree86-current on my
Omnibook's i830MG with these agp changes.
accept ranges as well as single addresses. Still need to go through any key
areas and remove the malloc's and replace these with some sort of pooling
instead.
The driver puts the adapter in promisc mode to receive multicast addresses.
At last set the IFF_PROMISC flag so that the upper layer filters frames
that are not for us.
Sure, the real fix would be to get multicast filters working ...
least 1us. Documentation I've found for the simple (SPP) parallel port
mode says that data should be stable 500ns before STROBE, STROBE should
be pulsed for no less than 500ns, and that data should be stable another
500ns after STROBE has been de-asserted.
Makes lpt@ebus on my Sun Ultra5 work with my HP DeskJet 712C, at least in
polled mode. Thanks to Martin for astutely noting it was probably a bug
with STROBE being pulsed too quickly.
1. Reduce debugging level to sane levels
2. Fix bugs in alloc_data_map related to allocing whole bytes of bitmap at
a time.
At this point the driver is functional. It talks to a local drive here and
can label/newfs. Performance is...lacking at the moment as its chewing cpu
heavily (probably due to the number of memcpy's) and will be the next area
attacked.
support up to the max ohci descriptor segments. Then attempt to fill it in
via a load. Use the number of segments filled in as the basis for figuring
out how many descriptors to supply to the ohci DMA engine.
XXX: Still needs to account for requests which because of splits may overflow
the 6 dma descriptors available today. For now this fixes cases where a
single 512 byte write was getting split into 2 dma segments from 1 incoming
iov request
The definitions were not the same between the scsi_messages file and this
definition so simply removing it here and letting the other one be used
results in incorrect behavior (regardless of whether it made the code
compile....)
jmc