Use MADT to match ACPI Processor objects to CPUs. MADT and DSDT/SSDTs may
list CPUs in different orders, especially for disabled logical cores. Now
we match ACPI IDs from the MADT with Processor objects, strictly order CPUs
accordingly, and ignore disabled cores. This prevents us from executing
methods for other CPUs, e. g., _PSS for disabled logical core, which may not
exist. Unfortunately, it is known that there are a few systems with buggy
BIOSes that do not have unique ACPI IDs for MADT and Processor objects. To
work around these problems, 'debug.acpi.cpu_unordered' tunable is added.
Set this to a non-zero value to restore the old behavior.
Many thanks to jhb for pointing me to the right direction and the manual
page change.
Reported by: Harris, James R (james dot r dot harris at intel dot com)
Tested by: Harris, James R (james dot r dot harris at intel dot com)
Reviewed by: jhb
MFC after: 1 month
list CPUs in different orders, especially for disabled logical cores. Now
we match ACPI IDs from the MADT with Processor objects, strictly order CPUs
accordingly, and ignore disabled cores. This prevents us from executing
methods for other CPUs, e. g., _PSS for disabled logical core, which may not
exist. Unfortunately, it is known that there are a few systems with buggy
BIOSes that do not have unique ACPI IDs for MADT and Processor objects. To
work around these problems
ThunderBolt cannot read sector >= 2^32 or 2^21
with supplied patch.
Second the bigger change, fix RAID operation on ThunderBolt base
card such as physically removing a disk from a RAID and replacing
it. The current situation is the RAID firmware effectively hangs
waiting for an acknowledgement from the driver. This is due to
the firmware support of the driver actually accessing the RAID
from under the firmware. This is an interesting feature that
the FreeBSD driver does not use. However, when the firmare
detects the driver has attached it then expects the driver will
synchronize LD's with the firmware. If the driver does not sync.
then the management part of the firmware will hang waiting for
it so a pulled driver will listed as still there.
The fix for this problem isn't extremely difficult. However,
figuring out why some of the code was the way it was and then
redoing it was involved. Not have a spec. made it harder to
try to figure out. The existing driver would send a
MFI_DCMD_LD_MAP_GET_INFO command in write mode to acknowledge
a LD state change. In read mode it gets the RAID map from the
firmware. The FreeBSD driver doesn't do that currently. It
could be added in the future with the appropriate structures.
To simplify things, get the current LD state and then build
the MFI_DCMD_LD_MAP_GET_INFO/write command so that it sends
an acknowledgement for each LD. The map would probably state
which LD's changed so then the driver could probably just
acknowledge the LD's that changed versus all. This doesn't seem
to be a problem. When a MFI_DCMD_LD_MAP_GET_INFO/write command
is sent to the firmware, it will complete later when a change
to the LD's happen. So it is very much like an AEN command
returning when something happened. When the
MFI_DCMD_LD_MAP_GET_INFO/write command completes, we refire the
sync'ing of the LD state. This needs to be done in as an event
so that MFI_DCMD_LD_GET_LIST can wait for that command to
complete before issuing the MFI_DCMD_LD_MAP_GET_INFO/write.
The prior code didn't use the call-back function and tried
to intercept the MFI_DCMD_LD_MAP_GET_INFO/write command when
processing an interrupt. This added a bunch of code complexity
to the interrupt handler. Using the call-back that is done
for other commands got rid of this need. So the interrupt
handler is greatly simplified. It seems that even commands
that shouldn't be acknowledged end up in the interrupt handler.
To deal with this, code was added to check to see if a command
is in the busy queue or not. This might have contributed to the
interrupt storm happening without MSI enabled on these cards.
Note that MFI_DCMD_LD_MAP_GET_INFO/read returns right away.
It would be interesting to see what other complexity could
be removed from the ThunderBolt driver that really isn't
needed in our mode of operation. Letting the RAID firmware
do all of the I/O to disks is a lot faster since it can
use its caches. It greatly simplifies what the driver has
to do and potential bugs if the driver and firmware are
not in sync.
Simplify the aen_abort/cm_map_abort and put it in the softc
versus in the command structure.
This should get merged to 9 before the driver is merged to
8.
PR: 167226
Submitted by: Petr Lampa
MFC after: 3 days
- Use isync/lwsync unconditionally for acquire/release. Use of isync
guarantees a complete memory barrier, which is important for serialization
of bus space accesses with mutexes on multi-processor systems.
- Go back to using sync as the I/O memory barrier, which solves the same
problem as above with respect to mutex release using lwsync, while not
penalizing non-I/O operations like a return to sync on the atomic release
operations would.
- Place an acquisition barrier around thread lock acquisition in
cpu_switchin().
This seems to break at least my test board here (AR71xx + AR8316 switch
PHY). Since I do have a whole sleuth of "normal" PHY boards (with
an AR71xx on a normal PHY port), I'll do some further testing with those
to determine whether this is a general issue, or whether it's limited
to the behaviour of the "fake" dedicated PHY port mode on these atheros
switches.
intr_bind() on x86.
This has been requested by jhb and I strongly disagree with this,
but as long as he is the x86 and interrupt subsystem maintainer I will
follow his directives.
The disagreement cames from what we should really consider as a
public KPI. IMHO, if we really need a selection between the kernel
functions, we may need an explicit protection like _KERNEL_KPI, which
defines which subset of the kernel function might really be considered
as part of the KPI (for thirdy part modules) and which not.
As long as we don't have this mechanism I just consider any possible
function as usable by thirdy part code, thus intr_bind() included.
MFC after: 1 week
is running on other cpu, the CALLOUT_PENDING flag is temporarily
cleared. Then, callout_stop() on this, in fact active, callout fails
because CALLOUT_PENDING is not set, and callout_stop() returns 0.
Now, in sleepq_check_timeout(), the failed callout_stop() causes the
sleepq code to execute mi_switch() without even setting the wmesg,
since the switch-out is supposed to be transient. In fact, the thread
is put off the CPU for full timeout interval, instead of being put on
runq immediately. Until timeout fires, the process is unkillable for
obvious reasons.
Fix this by marking the migrating callouts with CALLOUT_DFRMIGRATION
flag. The flag is cleared by callout_stop_safe() when the function
detects a migration, besides returning the success. The softclock()
rechecks the flag for migrating callout and cancels its execution if
the flag was cleared meantime.
PR: misc/166340
Reported, debugging traces provided and tested by:
Christian Esken <christian.esken trivago com>
Reviewed by: avg, jhb
MFC after: 1 week
Cleaner solution (e.g. adding another header) should be done here.
Original log:
Move several enums and structures required for L2 filtering from ip_fw_private.h to ip_fw.h.
Remove ipfw/ip_fw_private.h header from non-ipfw code.
Requested by: luigi
Approved by: kib(mentor)
Lagg(4) restricts the type of packet that may be sent directly to a child
port, to avoid undesired output from accidental misconfiguration.
Previously only ETHERTYPE_PAE was permitted.
BPF writes to a lagg(4) child port are presumably intentional, so just
allow them, while still blocking other packets that should take the
aggregation path.
PR: kern/138620
Approved by: thompsa@
another process is in open() or stat() for the device node, then
close() from the owning process does not result in cdevsw close
method call. This fixes the pemanent "Device busy" seen.
Changed the sndstat_lock from mutex to sx. This allows to extend
the region covered by the lock, to include the uiomove() call in
sndstat_read() and bufptr increment. This fixes the "panic:
sbuf_put_byte called with finished or corrupt sbuf" seen.
In collaboration with: kib
MFC after: 1 week
code and which had only stub implementations or no implementation on all
platforms. Makes gxemul compile.
Hinted by: rwatson
MFC after: 3 weeks
X-MFC by: rwatson:
if the accounting log file is atomically replaced with a new file
(such as during log rotation).
- Simplify accounting log rotation a bit. There is no need to re-run
accton(8) after renaming the new log file to it's real name.
PR: kern/167321
Tested by: Jeremy Chadwick
1) Always implement missing bus space methods using a panic() stub rather
than a NULL pointer. This appeared not to trip up any existing device
drivers, but due to the nature of the devices I'm supporting locally,
I'm making use of some of the more obscure busspace methods, and
panic() is a preferred failure mode. For example, do this for the
setregion methods.
2) Hook up several existing busspace method implementations that were
provided in the file, but not actually present in the methods
structure. Especially, single-byte bus I/O routines. This should
allow bugs to be fixed in the Atheros 802.11 driver.
There are still some remaining unimplemented methods that would be
desirable to implement -- especially, 64-bit I/O calls that would
observably accelerate device performance on FPGA-based soft CPU cores
that are typically clocked an order of magnitude slower than
conventional hard core CPUs, but that remains for another day.
MFC after: 3 weeks
Discussed with: jmallett, scottl
Sponsored by: DARPA, AFRL
entirely of one machdep file lifted from the MALTA port, as well as
a low-level console and tty driver for the gxemul debugging console
device (the emulators stdio). As with many low-level embedded and
hypervisor console devices, it is polled only, so we drive TTY I/O
from a callout; we are perhaps a bit too aware of the MIPS physical
maps in order to attach the console before newbus comes to life.
The sample kernel configuration depends on an MD-based root file
system, which is not provided. However, any 64-bit, big-endian
userspace image (such as one generated for MALTA) should work.
This will hopefully be supplemented by additional device drivers for
gxemul-specific hardware simulations from Juli Mallett. We have
found oldtestmips quite useful for testing and improving aspects of
the MIPS port, so it's worth supporting better in FreeBSD.
Requested by: theraven, jmallett
Sponsored by: DARPA, AFRL
MFC after: 3 weeks
* Flesh out the PLL configuration fetch function, which will return the PLL
configuration based on the unit number and speed.
* Remove the PLL speed config logic from the AR71xx/AR91xx chip PLL config
function - pass in a 'pll' value instead.
* Modify arge_set_pll() to:
+ fetch the PLL configuration
+ write the PLL configuration
+ update the MII speed configuration.
This will allow if_arge to override the PLL configuration as required.
Obtained from: Linux/Atheros/OpenWRT
* Add a new method to set the MII mode - GMII, RGMII, RMII, MII.
+ arge0 supports all four (two for non-Gige interfaces.)
+ arge1 only supports two (one for non-gige interfaces.)
* Set the MII clock speed when changing the MAC PLL speed.
+ Needed for AR91xx and AR71xx; not needed for AR724x.
Tested:
* AR71xx only, I'll do AR913x testing tonight and fix whichever issues
creep up.
TODO:
* Implement the missing AR7242 arge0 PLL configuration, but don't
adjust the MII speed accordingly.
* .. the AR7240/AR7241 don't require this, so make sure it's not set
accidentally.
Bugs (not fixed here):
* Statically configured arge speeds are still broken - investigate why
that is on the AP96 board. Autonegotiate is working fine, but there
still seems to be an occasionally heavy packet loss issue.
Obtained from: Linux/Atheros/OpenWRT
- Align the RX buffers on the cache line size, otherwise the requirement
of partial cache line flushes on every are pretty much guaranteed. [1]
- Make the code setting the RX timeout match its comment (apparently,
start and stop bits were missed in the previous calculation). [1]
- Cover the busdma operations in at91_usart_bus_{ipend,transmit}() with
the hardware mutex, too, so these don't race against each other.
- In at91_usart_bus_ipend(), reduce duplication in the code dealing with
TX interrupts.
- In at91_usart_bus_ipend(), turn the code dealing with RX interrupts
into an else-if cascade in order reduce its complexity and to improve
its run-time behavior.
- In at91_usart_bus_ipend(), add missing BUS_DMASYNC_PREREAD calls on
the RX buffer map before handing things over to the hardware again. [1]
- In at91_usart_bus_getsig(), used a variable of sufficient width for
storing the contents of USART_CSR.
- Use KOBJMETHOD_END.
- Remove an unused header.
Submitted by: Ian Lepore [1]
Reviewed by: Ian Lepore
MFC after: 1 week
V100, the firmware is known to be broken and not allowing to simultaneously
open disk devices, causing attempts to boot from a mirror or RAIDZ to cause
a crash. This will be worked around later. The firmwares of newer sun4u models
don't seem to exhibit this problem though.
Steps for ZFS booting:
1. create VTOC8 label
# gpart create -s vtoc8 da0
2. add partitions, f.e.:
# gpart add -t freebsd-zfs -s 60g da0
# gpart add -t freebsd-swap da0
resulting in something like:
# gpart show
=> 0 143331930 da0 VTOC8 (68G)
0 125821080 1 freebsd-zfs (60G)
125821080 17510850 2 freebsd-swap (8.4G)
3. create zpool
# zpool create bunker da0a
or for mirror/RAIDZ (after preparing additional disks as in steps 1. + 2.):
# zpool create bunker mirror da0a da1a
# zpool create bunker raidz da0a da1a da2a ...
4. set bootfs
# zpool set bootfs=bunker bunker
5. install zfsboot
# zpool export bunker
# gpart bootcode -p /boot/zfsboot da0
6. write zfsloader to the ZFS Boot Block (so far, there's no dedicated tool
for this, so dd(1) has to be used for this purpose)
When using mirror/RAIDZ, step 4. and the dd(1) invocation should be repeated
for the additional disks in order to be able to boot from another disk in
case of failure.
# sysctl kern.geom.debugflags=0x10
# dd if=/boot/zfsloader of=/dev/da0a bs=512 oseek=1024 conv=notrunc
# zpool import bunker
7. install system on ZFS filesystem
Don't forget to set 'zfs_load="YES"' and vfs.root.mountfrom="zfs:bunker" in
loader.conf as well as 'zfs_enable="YES"'in rc.conf.
8. copy zpool.cache to the ZFS filesystem
cp -p /boot/zfs/zpool.cache /bunker/boot/zfs/zpool.cache
9. set mountpoint
# zfs set mountpoint=/ bunker
10. Now, given that aliases for all disks in the zpool exists (check with
the `devalias` command on the boot monitor prompt) and disk0 corresponds
to da0 (likewise for additional disks), the system can be booted from the
ZFS with:
{1} ok boot disk0
PR: 165025
Submitted by: Gavin Mu
* Modified hwmp_recv_preq:
o cleaned up code, removed rootmac variable because preq->origaddr
is the root when we recevie a Proactive PREQ;
o Modified so that a PREP in response of a Proactive PREQ is unicast,
a PREP is ALWAYS unicast;
* Modified hwmp_recv_prep:
o Before we mark a route to be valid we should remove the discovery
flag and then mark it valid in such a way we wont lose the isgate flag;
Approved by: adrian
