register. This really shouldn't be using pci_enable_io() directly as
bus_alloc_resource() does it already, but the cached copy of the
command word needs to be correct so the enable/disable mwi functions
work properly.
- Use pci bus accessors to read revision ID and subvendor IDs.
Reviewed by: jvogel
LCDs to blink in the V_DISPLAY_ON case, at least in combination with
some 13W3-VGA-adaptors (what's exactly going on is unclear though,
as it happens when all of H-sync, V-sync and video output are enabled
and not touching the sync bits from the preset fixes it). Thus
creator_blank_display() now is reduced to turning the video output
on/off.
Although that DPMS code did what the XFree86/Xorg sunffb(4x) does,
it was questionable in the first place, as both implementations
also turn(ed) off the video output on standby and suspend, thus most
likely causing the monitor to turn off instead of entering standby
or suspend as intended (at least my monitors don't).
Reported and tested by: Patrick Reich
MFC after: 3 days
Following issues should be resolved:
- random watchdog timeouts (caused by concurrent phy access)
- some link state issues
- non working TX if media type was set explicitly
PR: kern/98738
Approved by: glebius (mentor)
MFC after: 2 weeks
conditions. The cause of missing Tx completion interrupts comes from
Tx interrupt moderation mechanism(delayed interrupts) or chipset bug.
If Tx interrupt moderation mechanism is the cause of false watchdog
timeout error we should have to fix all device drivers that have Tx
interrupt moderation capability. We may need more investigation
for this issue. Anyway, the fix is the same for both cases.
This should fix occasional watchdog timeout errors seen on a few
systems.
Reported by: -net, Patrick M. Hausen < hausen AT punkt DOT de >
Tested by: Patrick M. Hausen < hausen AT punkt DOT de >
misc. control registers correctly and it is inconsistent with north bridge.
In fact, there are too many broken BIOS implementations out there and we
cannot fix every possible combination but at least it is consistent with
what we advertise with ioctl(2).
it ended up defaulting to ISP_ROLE_NONE. My testing hadn't caught it
because I was deliberatly setting role via ioctl.
Thanks to user Toni for lending me an alpha to test this on.
MFC after: 0 days
Reported by: Nick Withers < nick AT nickwithers DOT com >
Tested by: Nick Withers < nick AT nickwithers DOT com >
No objection from: ariff
MFC after: 1 week
i386 (I don't know) but on amd64 at hand here, it paniced early at
boot.
(I'm pretty sure that PAGE_SIZE here was miscopied from another place
during porting, where in OpenBSD bus_dmamem_alloc() is used, but there
PAGE_SIZE means completely different thing.)
options field in register 10 will be deterministic, not random.
Correct the number of input bits for EXECUTE_FIRMWARE 0..1 to
0..2- the 2322 and 24XX cards use mailbox register 2 to specify
whether the f/w being executed is freshly loaded or not.
Correct the number of input bits for {READ,WRITE}_RAM_WORD_EXTENDED
so that register 8 gets picked up.
Fix the indexing and offset for the 2322 f/w download so that it
correctly puts the different code segments where they belong.
Move VERIFY_CHECKSUM to be the 'else' clause to 2322 f/w downloads-
the EXECUTE_FIRMWARE command for 2322 and 24XX cards will tell you
if the f/w checksum is incorrect and VERIFY_CHECKSUM only works for
RISC SRAM address < 64K so you can only do a VERIFY_CHECKSUM on the
first of the 3 f/w segments for the 2322.
Shorten the delay for the continuation mailbox commands- 1ms is
ridiculous (100us is more likely).
All of the more or less is really only for the 2322/6322 cards.
Previously em(4) requeued the failed mbuf chains from
bus_dmamap_load_mbuf_sg(9) failure to resend it later. However,
bus_dmamap_load_mbuf_sg(9) may never complete its request as the
fragmented frames can have more than EM_MAX_SCATTER segments.
To handle the above EFBIG case, defragment the frame with m_defrag(9)
and free the mbuf chain if it can't deframent the chain due to
resource shortage.
Reviewed by glebius (with improvements)
o Create one more spare DMA map for Rx handler to recover from
bus_dmamap_load_mbuf_sg(9) failure.
o Make sure to update status bit in Rx descriptors even if we failed
to allocate a new buffer. Previously it resulted in stuck condition
and em_handle_rxtx task took up all available CPU cycles.
o Don't blindly unload DMA map. Reuse loaded DMA map if received
packet has errors. This would speed up Rx processing a bit under
heavy load as it does not need to reload DMA map in case of error.
(bus_dmamap_load_mbuf_sg(9) is the most expensive call in driver
context.)
o Update if_iqdrops counter if it can't allocate a mbuf cluster.
With this change it's now possible to see queue dropped packets
with netstat(1).
o Update mbuf_cluster_failed counter if fixup code failed to
allocate mbuf header.
o Return ENOBUFS instead of ENOMEM in case of Rx fixup failure.
o Make adapter->lmp NULL in case of Rx fixup failure. Strictly
specking it's not necessary for correct operation but it makes
the intention clear.
o Remove now unused dropped_pkts member in softc.
With these changes em(4) should survive mbuf cluster allocation
failure on Rx path.
Reviewed by: pdeuskar, glebius (with improvements)
MCLBYTES - ETHER_ALIGN. Previously it applied the alignment fixup code
for oversized frames which would result in reduced performance on
strict alignment archs.
o when turning off the socket for a 16-bit card, write 0 to INTR register
rather than just tying to just clear the rest bit. this seems to fix
card insert detection after an eject on TI bridges (ricoh bridges work
either way, apparently). This is a MFp4.
o Cope better with TOPIC95 bridges on powerup. According to NetBSD driver,
these bridges don't set POWER_STATE, so cope accordingly in our power
code. They also need a little extra time to settle, so do that as well.
o It appears that we need to turn on/off one of the clocks to the card
when we power up/down that socket on a TOPIC97, also from NetBSD.
o TOPIC97 bridges need to specifically enable LV card support. Unconditionally
do this in the hopes that all laptops that have these chips support LV
voltages (they should, since they are required for CardBus).
o TOPIC register name regularization. Registers specific to models of TOPIC
are now called out as such.
# I need a machine with a TOPIC95 for testing.
space that enables low voltage operation (and maybe other stuff).
Enable the bits in this register so low voltage 16-bit cards may work.
Existance noticed in NetBSD driver.
