This helps systems that don't actually have atkbd controllers, such as the Intel
SBX82 blade, boot without device.hints hacks.
Hardware for this fix provided by iXsystems.
PR: 94822
Submitted by: Devon H. O'Dell <devon.odell@coyotepoint.com>
MFC After: 3 days
required by arches like sparc64 (not yet implemented) and sun4v where there
are seperate IOMMU's for each PCI bus... For all other arches, it will
end up returning NULL, which makes it a no-op...
Convert a few drivers (the ones we've been working w/ on sun4v) to the
new convection... Eventually all drivers will need to replace the parent
tag of NULL, w/ bus_get_dma_tag(dev), though dev is usually different for
each driver, and will require hand inspection...
Reviewed by: scottl (earlier version)
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.
