incomplete in that the PRT routing was not aware of link programming.
Fix this by doing all routing through the link devices. The new algorithm
for setting up links is:
1. Read _CRS to get current setting. If invalid (not in _PRS), then set
to 0.
2. Attempt to call _DIS on the link. If successful, mark the link as not
routed. Otherwise, assume it still is.
Then when a routing request occurs:
3. Update weights for all IRQs
4. Attempt to route the initial IRQ if valid
5. If that fails, walk through the sorted list, attempting to route IRQs.
6. Configure the trigger/polarity based on _PRS.
Other changes:
* Add acpi_pci_find_prt() to look up the PRT entry for a given device and
acpi_pci_link_route() to select/route the best IRQ for it.
* Remove duplicated code in acpi_pcib_route_interrupt() that picked the
first IRQ from _PRS.
* Remove unneeded arguments from acpi_pcib_resume() and friends.
* Ignore _STA on link devices but report if it seems strange.
* Add a prt_source handle to the PRT structure since the ACPI struct
ACPI_PCI_ROUTING_TABLE uses a fixed-size entry for it. We'll need to
dynamically size this object if we want to use it the same way ACPI-CA
does. Null-terminate the source.
Tested by: Luo Hong <luohong99_at_mails.tsinghua.edu.cn>,
Jeffrey Katcher <jmkatcher_at_yahoo.com>
Info from: jhb, Len Brown (Intel)
if_start routines cannot currently be entered without Giant. When
the kernel is running with debug.mpsafenet != 0, this will defer
if_start execution to a task queue thread holding Giant, which may
introduce additional latency, but avoid incorrect execution.
Suggested by: dfr
full, avoiding the cost of mutex operations if it is. We re-test
once the mutex is acquired to make sure it's still true before doing
the -modify-write part of the read-modify-write. Note that due to
the maximum fifo depth being pretty deep, this is unlikely to improve
harvesting performance yet.
Approved by: markm
chipsets, based on Linux's via-agp.c. On boot, the system selects which AGP
version to use based on the inserted card. If v2 was chosen, the chipset
needs to be programmed with the v2 registers still. Also included in kern/69953
are changes to make the programming of the v3 registers match linux, but that
will be left out until the need to do so is confirmed (want specs or a tester).
PR: kern/69953
Submitted by: Oleg Sharoiko <os@rsu.ru>
Tested by: Oleg Sharoiko <os@rsu.ru>, Geoff Speicher <geoff@speicher.org>
(full version from PR)
o Change the motion calculation to result in
a more reasonable speed of motion
This should fix the 'aiming' problems people have reported. It also
mitigates (but doesn't completely solve) the 'stalling' problems at
very low speeds.
Tested by: many subscribers to -current
Approved by: njl
o Catch 'taps' as button presses
o One finger sends button1, two fingers send button3,
three fingers send button2 (double-click)
Tested by: many subscribers to -current
Approved by: njl
o Handle the 'up/down' buttons some touchpads have as
a z-axis (scrollwheel) as recommended by the specs
o Report the buttons as button4 and button5 instead
of button2 and button4, button2 can be emulated by
pressing button1 and button3 simultaneously. This
allows one to use the two extra buttons for other
purposes if one so desires.
Tested by: many subscribers to -current
Approved by: njl
o Clean up whitespace and comments in the
enable_synaptics() probing function
o Only use (and rely on) the extended capability
bits when we are told they actually exist
o Partly ignore the (possibly dated?) part of the
specification about the mode byte so that we
can support 'guest devices' too.
Tested by: many subscribers to -current
Approved by: njl
was being unconditionally dereferenced but was NULL for PIO requests.
Check the request flags for a DMA transaction before dereferencing.
Reported by: ceri
Tested by: Radek Kozlowski <radek -at- raadradd.com>
with it that need to be understood better before they can be resolved.
This takes time and time is already in short supply.
Reported & tested by: glebius@
message if they are incorrect. Also, remove the hack of allowing the
initial irq setting to not be in _PRS. As before, the old behavior can be
regained by defining ACPI_OLD_PCI_LINK.
want a splash screen.
There seems to be some confusion in the syscons code as to the meaning of
the SC_KERNEL_CONSOLE flag. Its absence is sometimes interpreted to mean
"I am not the system console", and sometimes to mean "I am not the only
VGA console" (see the font loading code for an example of the latter).
Someone with better syscons fu than myself should take a closer look.
following behavior:
* Link devices return invalid status (_STA) values. The results are very
unreliable -- sometimes never present. Just ignore the status and pick
the best configuration from _PRS.
* Link devices return invalid current settings (_CRS). Even after setting
the link value, many systems still return a different setting for _CRS.
When setting an IRQ, don't bother to check _CRS to see if we succeeded.
Note that we still check _CRS before routing and this should be addressed
as well.
Since this is a sensitive area, leave the old behavior accessible via
uncommenting the define for ACPI_OLD_PCI_LINK at the top of the file. Once
this has been thoroughly tested, this option and the code it covers will
be removed.
Thanks to Len Brown at Intel for informing us of these issues as he worked
around them in Linux.
Since HME doesn't compensate the checksum for UDP datagram which
can yield to 0x0, UDP transmit checksum offload is disabled by
default. The UDP Transmit checksum offload can be reactivated
by setting special link option link0 with ifconfig(8).
Approved by: jake (mentor)
Reviewed by: tmm
Tested by: Herve Boulouis <amon@sockar.homeip.net>
by a transaction performing a driver handled message sequence (an
scb with the MK_MESSAGE flag set).
SCBs that perform host managed messaging must always be
at the head of their per-target selection queue so that
the firmware knows to manually assert ATN if the current
negotiation agreement is packetized. In the past we
guaranteed this by queuing these SCBs separarately in
the execution queue. This exposes the system to potential
command reordering in two cases:
1) Another SCB for the same ITL nexus is queued that does
not have the MK_MESSAGE flag set. This SCB will be
queued to the per-target list which can be serviced
before the MK_MESSAGE scb that preceeded it.
2) If the target cannot accept all of the commands in the
per-target selection queue in one selection, the remainder
is queued to the tail of the selection queues so as to
effect round-robin scheduling. This could allow the
MK_MESSAGE scb to be sent to the target before the
requeued commands.
This commit changes the firmware policy to defer queuing
MK_MESSAGE SCBs into the selection queues until this can
be done without affecting order. This means that the
target's selection queue is either empty, or the last
SCB on the execution queue is also a MK_MESSAGE SCB.
During any wait, the firmware halts the download of new
SCBs so only a single "holding location" is required.
Luckily, MK_MESSAGE SCBs are rare and typically occur only
during CAM's bus probe where only one command is outstanding
at a time. However, during some recovery scenarios, the
reordering *could* occur.
aic79xx.c:
Update ahd_search_qinfifo() and helper routines to
search for pending MK_MESSAGE scbs and properly
restitch the execution queue if either the MK_MESSAGE
SCB is being aborted, or the MK_MESSAGE SCB can be
queued due to the execution queue draining due to
aborts.
Enable LQOBUSFREE status to assert an interrupt.
This should be redundant since a BUSFREE interrupt
should always occur along with an LQOBUSFREE event,
but on the Rev A, this doesn't seem to be guaranteed.
When a PPR request is rejected when a previously
existing packetized agreement is in place, assume
that the target has been reset without our knowledge
and revert to async/narrow transfers. This corrects
two issues: the stale ENATNO setting that was used
to send the PPR is cleared so the firmware is not
confused by a future packetized selection with
ATN asserted but no MK_MESSAGE flag in the SCB and
it speeds up recovery by aborting any pending
packetized transactions that by definition are now
dead.
When re-queueing SCBs after a failed negotiation
attempt, ensure command ordering by freezing the
device queue first.
Traverse the list of pending SCBs rather than the
whole SCB array on the controller when pushing
MK_MESSAGE flag changes out to the controller.
The original code was optimized for the aic7xxx
controllers where there are fewer controller slots
then pending SCBs and the firmware picks SCB
slots. For the U320 controller, the hope is
that we have fewer pending SCBs then the 512
slots on the controller.
Enhance some diagnostics.
Factor out some common code.
aic79xx.h:
Add prototype for new ahd_done_with_status() that is
used to factor out some commone code.
aic79xx.reg:
Add definisions for the pending MK_MESSAGE SCB.
aic79xx.seq:
Defer MK_MESSAGE SCB queing to the execution queue
so as to preserve command ordering. Re-arrange some
of the selection processing code so the above change
had no performance impact on the common code path.
Close a few critical section holes.
When entering a non-packetized phase, manually enable
busfree interrupts, since the controller hardware
does not do this automatically.
aic79xx_inline.h:
Enhance logging for queued SCBs.
aic79xx_osm.c:
Add new a new DDB ahd command, ahd_dump, which
invokes the ahd_dump_card_state() routine on the
unit specified with the ahd_sunit DDB command.
aic79xx_pci.c:
Turn on the BUSFREEREV bug for the Rev B. controller.
This is required to close the busfree during non-packetized
phase hole.
into single-user mode (as seen on sparc64 and PPC). Problems were due
to a minor oversight in the changes committed in revision 1.25.
Submitted by: grehan
Tested by: gad & yongari
