History log of /freebsd/sys/cam/cam_periph.c (Results 26 – 50 of 412)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 710a519e 05-Nov-2021 Warner Losh <imp@FreeBSD.org>

cam_periph: fix bug in camperiphunitnext logic

If we assigned just a lun as a wired unit (something that camperiphunit
will accept), we failed to properly skip over that unit when computing a
next u

cam_periph: fix bug in camperiphunitnext logic

If we assigned just a lun as a wired unit (something that camperiphunit
will accept), we failed to properly skip over that unit when computing a
next unit number. Add lun so the code matches the comments that we have
to skip all the same criteria that camperiphunit uses to select wired
units for a driver.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D32682

show more ...


# bee0133f 05-Nov-2021 Warner Losh <imp@FreeBSD.org>

cam_periph: switch from negative logic to positive logic

When scanning the resources that are wired for this driver, skip any
that whose number doesn't match newunit. They aren't relevant. Switch to

cam_periph: switch from negative logic to positive logic

When scanning the resources that are wired for this driver, skip any
that whose number doesn't match newunit. They aren't relevant. Switch to
positive logic to break out of the loop (and thus go to the next unit)
if we find either a target resource or an at resource. This makes the
code easier to read and modify.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D32681

show more ...


# 00f79c97 05-Nov-2021 Warner Losh <imp@FreeBSD.org>

cam_periph: Remove vestigial "scbus" comparison

The code in camperiphunit rejects "scbus" as an 'at' location that would
allow any other wiring to use that unit number. Yet in
camperiphunitnext, if

cam_periph: Remove vestigial "scbus" comparison

The code in camperiphunit rejects "scbus" as an 'at' location that would
allow any other wiring to use that unit number. Yet in
camperiphunitnext, if we have a no target and the 'at' location of
'scbus' it would be excluded on the basis that it's a wiring
cadidate. This is improper and appears to be a hold-over of the
pre-hints / pre-newbus config system, so remove it.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D32680

show more ...


# dbfe5dd3 03-Nov-2021 Warner Losh <imp@FreeBSD.org>

cam_periph: style change

wrap a long line at 80 columns

Sponsored by: Netflix
Reviewed by: chs
Differential Revision: https://reviews.freebsd.org/D32679


# 13aa56fc 06-Jul-2021 Edward Tomasz Napierala <trasz@FreeBSD.org>

cam(4): preserve alloc_flags when copying CCBs

Before UMA CCBs, all CCBs were of the same size, and could
be trivially copied using bcopy(9). Now we have to preserve
alloc_flags, otherwise we might

cam(4): preserve alloc_flags when copying CCBs

Before UMA CCBs, all CCBs were of the same size, and could
be trivially copied using bcopy(9). Now we have to preserve
alloc_flags, otherwise we might end up attempting to free
stack-allocated CCB to UMA; we also need to take CCB size
into account.

This fixes kernel panic which would occur when trying to access
a stopped (as in, SCSI START STOP, also "ctladm stop") SCSI device.

Reported By: Gary Jennejohn <gljennjohn@gmail.com>
Tested By: Gary Jennejohn <gljennjohn@gmail.com>
Reviewed By: imp
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D31054

show more ...


Revision tags: release/13.0.0
# 076686fe 30-Mar-2021 Edward Tomasz Napierala <trasz@FreeBSD.org>

cam: make sure to clear CCBs allocated on the stack

This is required for small CCBs support, where we need to track
whether the CCB was allocated from an UMA zone or not. There are
no (intended) fu

cam: make sure to clear CCBs allocated on the stack

This is required for small CCBs support, where we need to track
whether the CCB was allocated from an UMA zone or not. There are
no (intended) functional changes with the current source.

Reviewed By: imp
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D29484

show more ...


# 447b3557 11-Feb-2021 John Baldwin <jhb@FreeBSD.org>

cam: Permit non-pollable sims.

Some CAM sim drivers do not support polling (notably iscsi(4)).
Rather than using a no-op poll routine that always times out requests,
permit a SIM to set a NULL poll

cam: Permit non-pollable sims.

Some CAM sim drivers do not support polling (notably iscsi(4)).
Rather than using a no-op poll routine that always times out requests,
permit a SIM to set a NULL poll callback. cam_periph_runccb() will
fail polled requests non-pollable sims immediately as if they had
timed out.

Reviewed by: scottl, mav (earlier version)
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Chelsio
Differential Revision: https://reviews.freebsd.org/D28453

show more ...


# 9093e27c 29-Nov-2020 Alexander Motin <mav@FreeBSD.org>

Remove alignment requirements for KVA buffer mapping.

After r368124 vmapbuf() should happily map misaligned maxphys-sized buffers
thanks to extra page added to pbuf_zone.


# cd853791 28-Nov-2020 Konstantin Belousov <kib@FreeBSD.org>

Make MAXPHYS tunable. Bump MAXPHYS to 1M.

Replace MAXPHYS by runtime variable maxphys. It is initialized from
MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.

Make b_pag

Make MAXPHYS tunable. Bump MAXPHYS to 1M.

Replace MAXPHYS by runtime variable maxphys. It is initialized from
MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.

Make b_pages[] array in struct buf flexible. Size b_pages[] for buffer
cache buffers exactly to atop(maxbcachebuf) (currently it is sized to
atop(MAXPHYS)), and b_pages[] for pbufs is sized to atop(maxphys) + 1.
The +1 for pbufs allow several pbuf consumers, among them vmapbuf(),
to use unaligned buffers still sized to maxphys, esp. when such
buffers come from userspace (*). Overall, we save significant amount
of otherwise wasted memory in b_pages[] for buffer cache buffers,
while bumping MAXPHYS to desired high value.

Eliminate all direct uses of the MAXPHYS constant in kernel and driver
sources, except a place which initialize maxphys. Some random (and
arguably weird) uses of MAXPHYS, e.g. in linuxolator, are converted
straight. Some drivers, which use MAXPHYS to size embeded structures,
get private MAXPHYS-like constant; their convertion is out of scope
for this work.

Changes to cam/, dev/ahci, dev/ata, dev/mpr, dev/mpt, dev/mvs,
dev/siis, where either submitted by, or based on changes by mav.

Suggested by: mav (*)
Reviewed by: imp, mav, imp, mckusick, scottl (intermediate versions)
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D27225

show more ...


Revision tags: release/12.2.0
# 44ca4575 21-Oct-2020 Brooks Davis <brooks@FreeBSD.org>

vmapbuf: don't smuggle address or length in buf

Instead, add arguments to vmapbuf. Since this argument is
always a pointer use a type of void * and cast to vm_offset_t in
vmapbuf. (In CheriBSD we'

vmapbuf: don't smuggle address or length in buf

Instead, add arguments to vmapbuf. Since this argument is
always a pointer use a type of void * and cast to vm_offset_t in
vmapbuf. (In CheriBSD we've altered vm_fault_quick_hold_pages to
take a pointer and check its bounds.)

In no other situtation does b_data contain a user pointer and vmapbuf
replaces b_data with the actual mapping.

Suggested by: jhb
Reviewed by: imp, jhb
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D26784

show more ...


# 27dcd3d9 02-Sep-2020 Mateusz Guzik <mjg@FreeBSD.org>

cam: clean up empty lines in .c and .h files


# e2515283 27-Aug-2020 Glen Barber <gjb@FreeBSD.org>

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)


# 773e541e 21-Aug-2020 Warner Losh <imp@FreeBSD.org>

Use devctl.h instead of bus.h to reduce newbus pollution.

There's no need for these parts of the kernel to know about newbus,
so narrow what is included to devctl.h for device_notify_*.

Suggested b

Use devctl.h instead of bus.h to reduce newbus pollution.

There's no need for these parts of the kernel to know about newbus,
so narrow what is included to devctl.h for device_notify_*.

Suggested by: kib@

show more ...


Revision tags: release/11.4.0
# 450a2e2a 13-Apr-2020 Warner Losh <imp@FreeBSD.org>

Remove stale comment

There's no useracc here, and even if there was it shouldn't be here. vmapbuf is
sufficient and as the comment says, useracc is racy.


# 81490eda 14-Mar-2020 Warner Losh <imp@FreeBSD.org>

Add comment about how the deferred callback for AC_FOUND_DEVICE we
generate for a race where a device goes away, we start to tear down
the periph state for the device, and then the device suddently
r

Add comment about how the deferred callback for AC_FOUND_DEVICE we
generate for a race where a device goes away, we start to tear down
the periph state for the device, and then the device suddently
reappears. The key that makes it work is removal of periph from the
drv list before calling the deferred callback.

Hat tip to: mav@

show more ...


# 2ac6b71f 07-Mar-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r358712 through r358730.


# 6fda2c54 07-Mar-2020 Warner Losh <imp@FreeBSD.org>

Reword a comment to describe what's actually going on. We can call invalidate
several times potentially. We just don't do anything on the second and
subsequent calls.


# b33a8b38 16-Feb-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r357966 through r357999.


# 3750f5ff 15-Feb-2020 Warner Losh <imp@FreeBSD.org>

The KASSERT is too strict: revert r357897

It's valid for a periph to be removed with outstanding transactions on the
device. In CAM, multiple periphs attach to a single device. There's no interlock

The KASSERT is too strict: revert r357897

It's valid for a periph to be removed with outstanding transactions on the
device. In CAM, multiple periphs attach to a single device. There's no interlock
to prevent one of these going away while other periphs have outstanding CCBs and
it's not an error either. Remove this overly agressive KASSERT to prevent
false-positive panics when devices depart.

show more ...


# 74dc6beb 14-Feb-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r357855 through r357920.


# 2100c6d0 14-Feb-2020 Warner Losh <imp@FreeBSD.org>

Add a KASSERT that there's no outstanding CCBs when we call camperiphfree. We
know that if there are any outstanding CCBs, then when they dereference the path
that's freed at the bottom of camperiphf

Add a KASSERT that there's no outstanding CCBs when we call camperiphfree. We
know that if there are any outstanding CCBs, then when they dereference the path
that's freed at the bottom of camperiphfree there will be some flavor of
panic. This moves that eventual panic to a traceback of when we free the last
reference on the device, which is earlier but may not be early enough.

show more ...


# c389a786 23-Dec-2019 Alexander Motin <mav@FreeBSD.org>

Make pass(4) handle misaligned buffers of MAXPHYS size.

Since we are already using malloc()+copyin()/copyout() for smaller data
blocks, and since new asynchronous API does it always, I see no reason

Make pass(4) handle misaligned buffers of MAXPHYS size.

Since we are already using malloc()+copyin()/copyout() for smaller data
blocks, and since new asynchronous API does it always, I see no reason
to keep this ugly artificial size/alignment limitation in old API.

Tape applications suffer enough from the MAXPHYS limitations by itself,
and additional alignment requirement, often halving effectively usable
block size, does not help.

It would be good to use unmapped I/O here instead, but it require some
HBA drivers polishing first to support non-BIO unmapped buffers.

MFC after: 2 weeks
Sponsored by: iXsystems, Inc.

show more ...


# bae3729b 22-Nov-2019 Alexander Motin <mav@FreeBSD.org>

Do not retry long ready waits if previous gave nothing.

I have some disks reporting "Logical unit is in process of becoming ready"
for about half an hour before finally reporting failure. During th

Do not retry long ready waits if previous gave nothing.

I have some disks reporting "Logical unit is in process of becoming ready"
for about half an hour before finally reporting failure. During that time
CAM waits for the readiness during ~2 minutes for each request, that makes
system boot take very long time.

This change reduces wait times for the following requests to ~1 second if
previously long wait for that device has timed out.

MFC after: 2 weeks
Sponsored by: iXsystems, Inc.

show more ...


Revision tags: release/12.1.0
# 61c1328e 13-Sep-2019 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r352105 through r352307.


# 07f7e4c8 11-Sep-2019 Alexander Motin <mav@FreeBSD.org>

Fix assumptions of only one device per SES slot.

It is typical to have one, but no longer true for multi-actuator HDDs
with separate LUN for each actuator.

MFC after: 4 days
Sponsored by: iXsystems

Fix assumptions of only one device per SES slot.

It is typical to have one, but no longer true for multi-actuator HDDs
with separate LUN for each actuator.

MFC after: 4 days
Sponsored by: iXsystems, Inc.

show more ...


12345678910>>...17