was done, I believe, to work around some cards having issues in the
suspend case. I think that this helped my Sony VAIO TS505 work better
when it had certain wireless cards in it and I did a apm -z. I've not
tested suspend/resume on other laptops in a long time, so I hope this
doesn't cause greif. Please let me know if it does.
of cases where we didn't take out the lock before setting or clearing
a bit. This apparently can lead to a race at kldunload time (at least
on my Turion64 laptop, never saw it on my Sony Vaio).
EHCI spec for linking in new qTDs into an asynchronous QH. This
requires that there is a qTD marked as not active and not halted
at the start of the QH's list, and the hardware will know to re-fetch
the qTD on each pass rather than just looking at the overlay qTD:
"The host controller must be able to advance the queue from the
Fetch QH state in order to avoid all hardware/software race
conditions. This simple mechanism allows software to simply link
qTDs to the queue head and activate them, then the host controller
will always find them if/when they are reachable."
This is achieved by keeping an "inactivesqtd" entry on the QH list,
and re-using it each time as the start of the next transfer, and
allocating a new qTD to become the next inactivesqtd. Then a new
transfer can be activated by just setting its "active" flag, which
avoids all the previous messing with overlay qTD state in
ehci_set_qh_qtd().
before starting exploring (4 seconds), and extend the wait period
if new USB buses are attached while waiting.
This works around a problem seen when there is more than one EHCI
controller in the system and you kldload usb.ko after the system
has booted. The problem is that usb.ko contains 3 separate PCI
drivers which get initialised one by one (uhci, ohci, ehci), and
when each driver is initialised, all PCI buses are re-probed after
just the addition of that driver. This means that there can be a
significant delay between the attaching of a companion controller
and the subsequent EHCI attach, so it is possible for the companion
controller's USB 1.x bus to be scanned before the EHCI driver gets
a chance to check if there is really a USB 2.x device connected.
- Rename REG_DL to REG_DLL and REG_DLH.
- Always treat DLL and DLH as two separate 8-bit registers instead of one
16-bit register.
Additionally, remove the probe for the high 4 bits of IER being 0 and don't
assume we can always read/write 0 to/from those bits.
These changes allow uart(4) to drive the UARTs on the Intel XScale PXA255.
Reviewed by: marcel
- Skip PnP devices as some wedge when trying to probe them as C-NET(98)S.
This fix makes le(4) actually work with the C-NET(98)S.
Reviewed by: marius
Tested by: Watanabe Kazuhiro < CQG00620 at nifty dot ne dot jp >
Be cognizant as to whether we're running 2KLogin f/w in target mode and
do the appropriate loopid load based upon that.
Do a first cut (seems to work, at least for amd64) at 64 bit target
mode for fibre channel cards. We could probably also do it for SPI
cards, but that's not supported right now.
- Linux ioctl support, with the other Linux changes MegaCli
will run if you mount linprocfs & linsysfs then set
sysctl compat.linux.osrelease=2.6.12 or similar. This works
on i386. It should work on amd64 but not well tested yet.
StoreLib may or may not work. Remember to kldload mfi_linux.
- Add in AEN (Async Event Notification) support so we can
get messages from the firmware when something happens.
Not all messages are in defined in event detail. Use
event_log to try to figure out what happened.
- Try to implement something like SIGIO for StoreLib. Since
mrmonitor doesn't work right I can't fully test it. StoreLib
works best with the rh9 base. In theory mrmonitor isn't
needed due to native driver support of AEN :-)
Now we can configure and monitor the RAID better.
Submitted by: IronPort Systems.
full, kick the binary blob to force it to complete any pending tx
completions.
- In the watchdog routine, only reset the chip if the blob doesn't complete
any pending tx completions rather than requiring it to complete all of
the pending tx completions.
Submitted by: Nathan Whitehorn <nathanw@uchicago.edu>
MFC after: 2 weeks
lnc(4) on PC98 and i386. The ISA front-end supports the same non-PNP
network cards as lnc(4) did and additionally a couple of PNP ones.
Like lnc(4), the C-bus front-end of le(4) only supports C-NET(98)S
and is untested due to lack of such hardware, but given that's it's
based on the respective lnc(4) and not too different from the ISA
front-end it should be highly likely to work.
- Remove the descriptions of le(4), which where converted from lnc(4),
from sys/i386/conf/NOTES and sys/pc98/conf/NOTES as there's a common
one in sys/conf/NOTES.
still should return BUS_PROBE_LOW_PRIORITY instead of BUS_PROBE_DEFAULT
in order to give pcn(4) a chance to attach in case it probes after le(4).
- Rearrange the code related to RX interrupt handling so that ownership of
RX descriptors is immediately returned to the NIC after we have copied
the data of the hardware, allowing the NIC to already reuse the descriptor
while we are processing the data in ifp->if_input(). This results in a
small but measurable increase in RX throughput.
As a side-effect, this moves the workaround for the LANCE revision C bug
to am7900.c (still off by default as I doubt we will actually encounter
such an old chip in a machine running FreeBSD) and the workaround for the
bug in the VMware PCnet-PCI emulation to am79000.c, which is now also
only compiled on i386 (resulting in a small increase in RX throughput on
the other platforms).
- Change the RX interrupt handlers so that the descriptor error bits are
only check once in case there was no error instead of twice (inspired
by the NetBSD pcn(4), which additionally predicts the error branch as
false).
- Fix the debugging output of the RX and TX interrupt handlers; while
looping through the descriptors print info about the currently processed
one instead of always the previously last used one; remove pointless
printing of info about the RX descriptor bits after their values were
reset.
- Create the DMA tags used to allocate the memory for the init block,
descriptors and packet buffers with the alignment the respective NIC
actually requires rather than using PAGE_SIZE unconditionally. This might
as well fix the alignment of the memory as it seems we do not inherit
the alignment constraint from the parent DMA tag.
- For the PCI variants double the number of RX descriptors and buffers
from 8 to 16 as this minimizes the number of RX overflows im seeing with
one NIC-mainboard combination. Nevertheless move reporting of overflows
under debugging as they seem unavoidable with some crappy hardware.
- Set the software style of the PCI variants to ILACC rather than PCnet-PCI
as the former is was am79000.c actually implements. Should not make a
difference for this driver though.
- Fix the driver name part in the MODULE_DEPEND of the PCI front-end for
ether.
- Use different device descriptions for PCnet-Home and PCnet-PCI.
- Fix some 0/NULL confusion in lance_get().
- Use bus_addr_t for sc_addr and bus_size_t for sc_memsize as these are
more appropriate than u_long for these.
- Remove the unused LE_DRIVER_NAME macro.
- Add a comment describing why we are taking the LE_HTOLE* etc approach
instead of using byteorder(9) functions directly.
- Improve some comments and fix some wording.
MFC after: 2 weeks
Current code does not report link loss correctly - when link goes down,
mii_phy_tick() will notice that with up to mii_anegticks delay.
If link goes up during this delay then link flapping will be unnoticed
by driver.
2) mii_phy_add_media(): initialize sc->mii_anegticks for 10/100 media
3) Use MII_ANEGTICKS/MII_ANEGTICKS_GIGE defines instead of hardcoded values.
Approved by: glebius (mentor)
MFC after: 1 month
divisor. This allows us to set the line speed to the maximum
of 1/4 of the device clock.
o Disable the baudrate generator before programming the line
settings, including baudrate, and enable it afterwards.
was not checked at all. There is only one case when sc_clean_up()
can fail, because of wait_scrn_saver_stop(), but it doesn't hurt
to check anyway.
Reviewed by: rodrigc
Found by: Coverity Prevent
