Unfortunately we can't check range collisions for UNMAP commands alike
to writes, because they include multiple ranges, which are also passed
in data block, not in CDB. As result, UNMAP commands have to be treated
as colliding with any other command accessing the media.
From the other side all UNMAPs are equal (we don't support ANCHOR flag),
so we can execute several UNMAPs same time.
This code was heavily broken few months ago during CAM locking changes.
Fixing it would require almost complete rewrite. Since there are no
known devices on market using this interface younger then ~15 years, and
they are CD, not even DVD, I don't see much reason to rewrite it.
This change does not mean those devices won't work. They will just work
slower due to inefficient disks load/unload schedule if several LUNs
accessed same time.
Discussed with: ken@
Silence on: scsi@, hardware@
MFC after: 1 week
motherboard. PHY hardware used for the controller responded at
all possible addresses which in turn resulted in having 32 PHYs
for the controller. If driver detects "MSI K9N6PGM2-V2 (MS-7309)"
motherboard, tell miibus(4) PHY is located at 0.
Tested by: Chris H
binmisc code to be build on amd64/i386 for the kernel.
Update NOTES with some indication of what this code is used for.
Pointed out by jhb@ ... thanks!
Submitted by: jhb@
0xff. Some guests may attempt to read from this port to identify
psuedo-PNP ISA devices. (The ie(4) driver in FreeBSD/i386 is one
example.)
Reviewed by: grehan
This patch adds support for three new SCSI commands: UNMAP, WRITE SAME(10)
and WRITE SAME(16). WRITE SAME commands support both normal write mode
and UNMAP flag. To properly report UNMAP capabilities this patch also adds
support for reporting two new VPD pages: Block limits and Logical Block
Provisioning.
UNMAP support can be enabled per-LUN by adding "-o unmap=on" to `ctladm
create` command line or "option unmap on" to lun sections of /etc/ctl.conf.
At this moment UNMAP supported for ramdisks and device-backed block LUNs.
It was tested to work great with ZFS ZVOLs. For file-backed LUNs UNMAP
support is unfortunately missing due to absence of respective VFS KPI.
Reviewed by: ken
MFC after: 1 month
Sponsored by: iXsystems, Inc
execution to a emumation program via parsing of ELF header information.
With this kernel module and userland tool, poudriere is able to build
ports packages via the QEMU userland tools (or another emulator program)
in a different architecture chroot, e.g. TARGET=mips TARGET_ARCH=mips
I'm not connecting this to GENERIC for obvious reasons, but this should
allow the kernel module to be built by default and enable the building
of the userland tool (which automatically loads the kernel module).
Submitted by: sson@
Reviewed by: jhb@
o Unmute terminal when done with driver replacement.
o Move init fonts to early point.
o Minor cleanup.
MFC after: 6 days
X-MFC-with: r264244 r264242
Sponsored by: The FreeBSD Foundation
{MIO,SER}5xxxx chips instead of treating all of them as PUC_PORT_2S.
Among others, this fixes the hang seen when trying to probe the none-
existent second UART on an actually 1-port chip.
Obtained from: NetBSD (BAR layouts)
MFC after: 3 days
Sponsored by: Bally Wulff Games & Entertainment GmbH
tracked BAW actually is.
The net80211 code that completes a BAR will set tid->txa_start (the
BAW start) to whatever value was called when sending the BAR.
Now, in case there's bugs in my driver code that cause the BAW
to slip along, we should make sure that the new BAW we start
at is actually what we currently have it at, not what we've sent.
This totally breaks the specification and so this stays a printf().
If it happens then I need to know and fix it.
Whilst here, add some debugging updates:
* add TID logging to places where it's useful;
* use SEQNO().
match how it's used.
This is another bug that led to aggregate traffic hanging because
the BAW tracking stopped being accurate. In this instance, a filtered
frame that exceeded retries would return a non-error, which would
mean the caller would never remove it from the BAW. But it wouldn't
be added to the filtered list, so it would be lost forever. There'd
thus be a hole in the BAW that would never get transmitted and
this leads to a traffic hang.
Tested:
* Routerstation Pro, AR9220 AP
we did suspend it.
The whole suspend/resume TID queue thing is supposed to be a matched
reference count - a subsystem (eg addba negotiation, BAR transmission,
filtered frames, etc) is supposed to call pause() once and then resume()
once.
ath_tx_tid_filt_comp_complete() is called upon the completion of any
filtered frame, regardless of whether the driver had aleady seen
a filtered frame and called pause().
So only call resume() if tid->isfiltered = 1, which indicates that
we had called pause() once.
This fixes a seemingly whacked and different problem - traffic hangs.
What was actually going on:
* There'd be some marginal link with crappy behaviour, causing filtered
frames and BAR TXing to occur;
* A BAR TX would occur, setting the new BAW (block-ack window) to seqno n;
* .. and pause() would be called, blocking further transmission;
* A filtered frame completion would occur from the hardware, but with
tid->isfiltered = 0 which indiciates we haven't actually marked
the queue yet as filtered;
* ath_tx_tid_filt_comp_complete() would call resume(), continuing
transmission;
* Some frames would be queued to the hardware, since the TID is now no
longer paused;
* .. and if some make it out and ACked successfully, the new BAW
may be seqno n+1 or more;
* .. then the BAR TX completes and sets the new seqno back to n.
At this point the BAW tracking would be loopy because the BAW
start was modified but the BAW ring buffer wasn't updated in lock
step.
Tested:
* Routerstation Pro + AR9220 AP
that are being done by the OS.
For now this'll match up with the "wakeups"; although I'll dig deeper into
this to see if we can determine which sleep state the CPU managed to get
into. Most things I've seen these days only expose up to C2 or C3 via
ACPI even though the CPU goes all the way down to C6 or C7.
