aboutsummaryrefslogtreecommitdiff
path: root/sys/cam
Commit message (Collapse)AuthorAgeFilesLines
* cam/scsi: Restore scsi_start_stop() and add scsi_start_stop_pc()Jaeyoon Choi32 hours4-3/+38
| | | | | | | | | | Revert the argument change that broke libcam in 8c35de49 and move power_condition support to scsi_start_stop_pc(). Reported by: imp Reviewed By: #cam, imp (mentor) Sponsored by: Samsung Electronics Differential Revision: https://reviews.freebsd.org/D54822
* cam: When inq data isn't valid, pass NULLWarner Losh2026-01-081-10/+8
| | | | | | | | | When the device isn't there, we don't have valid inq data. Pass NULL in this case. All the routines that receive this test against NULL already. Sponsored by: Netflix Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D54470
* cam: Add probes for xpt actionsWarner Losh2026-01-081-1/+21
| | | | | | | | | | | | | | cam::xpt:action(union ccb *) cam::xpt:done((union ccb *) cam::xpt:async-cb(void *cbarg, uint32_t async_code, struct cam_path *path, void *async_arg); Called when xpt_action(), xpt_done*() and the xpt async callbacks are called. Sponsored by: Netflix Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D54469
* cam: Start adding dtrace provider 'cam'Warner Losh2026-01-082-0/+19
| | | | | | | | | Start to provide robust tracing in cam now that clang has broken my fbt-based dtrace scripts a couple of times. Sponsored by: Netflix Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D54468
* cam: Minor comment cleanupWarner Losh2026-01-031-7/+8
| | | | | | | Some minor comment cleanup, add a comment about an unused value, etc. No functional change. Sponsored by: Netflix
* scsi: Make all da error messages greppableWarner Losh2025-12-281-49/+40
| | | | | | | | | | Don't split the error messages across lines. We used to do that ages ago, but have relaxed style(9) to encourage the opposite so all error messages can be grepped. This constantly slows me down when I'm helping others find issues, so start here by splitting according to normal style(9) rules with a relaxed line length of 90. Sponsored by: Netflix
* mmc(4): Fix a typo in a device debug messageGordon Bergling2025-12-131-1/+1
| | | | | | - s/reseting/resetting/ MFC after: 5 days
* cam: Also reduce timeout for wlun probingWarner Losh2025-12-121-1/+1
| | | | | | | | | | | wlun probing was added after my initial work on this and was overlooked in merging forward. Add the timeout here too, for the same reasons as for REPORT LUNS. This doesn't change the default. Fixes: 8ac7a3801c6a cam: Reduce overly long timeout values for initial device probing Sponsored by: Netflix Reviewed by: jaeyoon Differential Revision: https://reviews.freebsd.org/D54184
* cam: Reduce overly long timeout values for initial device probingWarner Losh2025-12-111-6/+22
| | | | | | | | | | | | | | | | | | | | | | | Currently, we have very long timeouts for the initial probing commands. However, these are not appropriate for modern (post 2010) SCSI disks. Sandards since SPC3 state that these commands should not wait for media access. Since we retry them several times during the initial bus scan, these delays can delay the boot by minutes (5 minutes per errant disk in our expereince). These delays don't help and only hurt, so reduce the TESTUNITREADY, INQUIRY and MODESENSE commands (during the initial probe). Provide sysctl/tuneables to change the time for these and also the REPORTLUNS commands for people that might need to adjust them for devices that violate this belief but none-the-less work with longer timeouts. kern.cam.tur_timeout (default was 60s, now 1s) kern.cam.inquiry_timeout (default was 60s, now 1s) kern.cam.reportluns_timeout (default is 60s) kern.cam.modesense_timeout (default was 60s, now 1s) This can be partially merged: the sysctls can, but the new defaults likely shouldn't. Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D52427
* nvme: Only attach to storage NVMe devicesWarner Losh2025-12-101-1/+1
| | | | | | Only attach CAM to the nvme storage devices. Sponsored by: Netflix
* cam: decode and print direct accecss block device sense dataWarner Losh2025-12-102-2/+68
| | | | | | | A more efficient way to include multiple bits of data in a sense decriptor was defined in SBC4 in 2020. Decode and print it. Sponsored by: Netflix
* cam: Expand the parts of the sense buffer we reportWarner Losh2025-12-103-6/+212
| | | | | | Decode the descriptors we put into devd. Sponsored by: Netflix
* cam: set reladr in scsi_read_capacity_16Warner Losh2025-12-051-2/+2
| | | | | | | | The reladr field wasn't being set, so pmi and reladr args were nops. That's OK, because they are passed as 0 in the one place in the tree we use this. Sponsored by: Netflix
* cam/scsi: Add power condition support to START STOP UNITJaeyoon Choi2025-12-014-2/+8
| | | | | | | | | This patch adds a power_condition parameter to the scsi_start_stop() function and sets the power condition via SSU. Reviewed by: imp (mentor) Sponsored by: Samsung Electronic Differential Revision: https://reviews.freebsd.org/D53922
* cam/scsi: Support well known logical unitJaeyoon Choi2025-12-015-83/+161
| | | | | | | | | This patch adds an additional state to probe well-known logical units before probing normal logical units. Reviewed by: imp (mentor) Sponsored by: Samsung Electronics Differential Revision: https://reviews.freebsd.org/D53920
* nda: fix setting of unmappedio flagChuck Silvers2025-11-251-5/+4
| | | | | | | | | | | | | | The upstream refactoring of ndaregister() to split out ndasetgeom() accidentally used an uninitialed variable to decide whether or not to set DISKFLAG_UNMAPPED_BIO. Fix this by moving that portion of ndasetgeom() back up to ndaregister(). The check for PIM_UNMAPPED is not really needed because nvme devices always have that set, so it cannot change in the other path that ndasetgeom() is now called. Reviewed by: imp Fixes: dffd882d12d2a71aca464f48209ec9ae6f393b15 Sponsored by: Netflix MFC After: 1 minute
* nda: React to namespace change eventsWanpeng Qian2025-11-182-9/+22
| | | | | | | | | | | Register for AC_GETDEV_CHANGED. When we receive a namespace notification, we only create a new device if it was unconfigured. If it was configured, generate this async event. Rely on the fact that we reconstruct namespace to just get the data from the identify data and call disk_resised. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D33032
* nvme: Refactor geom setting to function.Wanpeng Qian2025-11-181-16/+31
| | | | | | | | Refactor setting of geometry for the disk to its own function. No functional changes. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D33032
* cam: Add a number of asserts to catch bad transactionsWarner Losh2025-11-062-0/+93
| | | | | | | | | | | Ensure that we're in the right state / priority for each of the states in the driver. These asserts assured that a prior patch that I committed to fix a priority leak worked when a drive departed (and bounced back too!). These have been running in our production since I committed the change and haven't trigged. Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D53259
* sbuf_delete() after sbuf_finish() & add SBUF_INCLUDENULDavid E. O'Brien2025-10-311-3/+5
| | | | | Reviewed by: adrian, imp Differential Revision: https://reviews.freebsd.org/D53254
* cam: Fix three typos in kernel messagesGordon Bergling2025-10-293-3/+3
| | | | | | | | - s/maximun/maximum/ - s/queing/queueing/ - s/exhausing/exhausting/ MFC after: 1 week
* cam: Bump deprecated sysctl removal to 16Ed Maste2025-10-262-4/+4
| | | | | | | | The descriptions for these unmapped_io and rotating sysctls indicated that they're deprecated and being removed for FreeBSD 15.0. That did not happen, so update to FreeBSD 16 instead. Sponsored by: The FreeBSD Foundation
* knotes: kqueue: handle copy for trivial filtersKonstantin Belousov2025-10-182-1/+3
| | | | | | | | Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D52045
* style(9): white space after ; and around binary operatorsDavid E. O'Brien2025-10-162-4/+4
| | | | | | | in for() loops. Also, use 'while', where only the conditional test of 'for' was used. Reviewed by: sjg
* scsi: Use proper prototype for SYSINIT functionsZhenlei Huang2025-10-131-2/+2
| | | | MFC after: 1 week
* Revert "cam/iosched: Initialize max_lat"Warner Losh2025-10-071-1/+0
| | | | | | | | | This reverts commit ce89c8f47a91f76b2fdeb1fdb504fd637ce93047. There's other parts to this, and GENERIC doesn't include iosched so I missed that. Back out while I gather them together. Sponsored by: Netflix
* cam/iosched: Initialize max_latWarner Losh2025-10-071-0/+1
| | | | Sponsored by: Netflix
* power: Add stype parameter in power_suspend/resume eventhandlersAymeric Wibo2025-10-062-6/+8
| | | | | | | | | | Add enum sleep_type stype parameter in power_suspend/resume event handlers, as with the introduction of s2idle there are more than one type of suspend. Reviewed by: bz Approved by: bz Sponsored by: The FreeBSD Foundation
* cam(3): Fix a common typo in source code commentsGordon Bergling2025-08-252-4/+4
| | | | | | - s/tranferred/transferred/ MFC after: 3 days
* cam: Enforce real priorities in xpt_action for queued ccbs.Warner Losh2025-07-221-0/+9
| | | | | | | | | | All queued CCBs should be created with a real priority (one that's not CAM_PRIORITY_NONE). Recently, I introduced a bug that revealed a latent MMC bug where it would stop enumerating due to a bad priority. Add an assert to catch that (the other bug in mmc_da that it found has been fixed). Sponsored by: Netflix
* mmc_da: Queued CCBs need a priority other than CAM_PRIORITY_NONEWarner Losh2025-07-221-1/+1
| | | | | | | | | | | | Queued CCBs usually are queued at CAM_PRIORITY_NORMAL, unless they are doing error recovery, or device enumeration of some kind. They should never be queued at CAM_PRIORITY_NONE, which should only be used for CCBs that are immediate. For sdda_start_init_task(), we allocate a ccb, initialize it then use it to talk to the SD/MMC card to query it, negotiate the speed and lane sizes, etc. Most of these commands are queued, so use the normal priority. Sponsored by: Netflix
* cam/mmc: Remove stray xpt_path_inqWarner Losh2025-07-221-1/+0
| | | | | | | | | | | | | | | | | | Turns out, we don't use the results of xpt_path_inq here at all. And it also causes problems. Since it calls xpt_cam_inq to do this useless XPT_PATH_INQ, it loses the original priority we had for the CCB. This priority should be CAM_PRIORITY_XPT, but was oringially set to CAM_PRIORITY_NORMAL. This worked to enumerate the device because no normal priority CCBs were queued by anything doing the enumeration. However, when I changed xpt_path_inq to use the more proper PRIORITY_NONE, it exposed this bug because queued CCBs with PRIORITY_NONE sometimes won't run. This caused the probe device to stop after its first operation. Removing the xpt_path_inq means we no longer step on the important fields we get from xpt_schedule, allowing probing to work correctly. Noticed by: bz@ Sponsored by: Netflix
* cam/xpt: style(9) no longer recommends blank linesWarner Losh2025-07-101-2/+0
| | | | | | | | The new xpt_gdev_type() function shouldn't have had a blank line. It was copied from xpt_path_inq(). Remove it from both. Noticed by: jhb Sponsored by: Netflix
* cam: Fail the disk if READ CAPACITY returns 4/2 asc/ascqWarner Losh2025-07-101-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HGST disks that are sick are returning 44/0 for START UNIT (which we ignore) and then 4/2 on READ CAPACITY. START UNIT should be enough for READ CAPACITY to succeed or UNIT ATTENTION. However, we get NOT_READ + 4/2 back. I've seen this on several models of HGST drives. Invalidate the peripheral when we detect this condition. This is likely the least bad thing we can do: It removes access to daX, but leaves passY so logs may be extracted (if awkwardly). Removing daX access removes the disk device that causes problems to geom outlined below. Although the timeout is 5s for READ_CAPACITY, we wait the full 30s for READ_CAPACITY_16. This causes us to stall booting as we start to taste as soon as we release the final hold... but the tasting means g_wait_idle() takes now takes over 5 minutes to clear since we do this for all the opens. Even using a timeout of 3s instead of 30s leads to boot times of almost 5 minutes in these cases, so there are other, downstream operations that are taking a while, so it's not just a matter of adjusting the timeout. Failing the periph early solves the bulk of this problem (the tasting related delays). What the HBA does is HBA specific and some have firmwares that are also confused by this when they enumerate or discover the drive, leading to long (but still shorter than 5 minute) delays. This patch won't solve that aspect of startup delays with sick disks. Perhaps we should fail the periph when START UNIT fails with the same codes we check in the read capacity path. I'm reluctant to do such a global change since it's in cam_periph, and there seems no good way to flag that we want this behavior. It's also a bit magical when it runs (some drive report 44/0 always, and some just report it on START UNIT, and these HGST drive fall into the latter category). Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D51218
* cam: Add xpt_gdev_type() and use it instead of many copies of sameWarner Losh2025-07-1011-64/+29
| | | | | | | | | | | | | | Add a convenience wrapper to XPT_GDEV_TYPE in the same way we have one for XPT_PATH_INQ. The changes from PRIORITY_NORMAL to PRIORITY_NONE are intentional because this isn't a queued CCB. Please note: we have several places still that construct a XPT_GDEV_TYPE message by overwriting a CCB that happens to be laying around. I've not used this method, by and large, in those places since I didn't want to risk upsetting allocation flags that might be present (since we use a specail allocator for some CCB types in *_da.c). Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D51216
* cam: Use less stack spaceWarner Losh2025-07-101-15/+19
| | | | | | | | Use less stack space by using the specific type of ccb to do the callback. Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D51215
* cam/mmc: style(9) pass: put { starting functions on its own lineWarner Losh2025-07-081-8/+16
| | | | Sponsored by: Netflix
* cam: Use bool for doneWarner Losh2025-07-071-5/+5
| | | | | | | | 'done' is a bool, so declare it like one. Sponsored by: Netflix Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D51171
* cam: Create free_scan_info helper functionWarner Losh2025-07-071-8/+13
| | | | | | | | | | | We free the scsi bug scan info in 4 places. 1 was wrong until I fixed a bug there in a recent commit. Introduce a helper function that will free the cpi always (it must always be valid since we set it right after allocation). Sponsored by: Netflix Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D51170
* cam: In scsi_scan_bus, fix an error caseWarner Losh2025-07-071-1/+1
| | | | | | | | | | | | | | | | | If we can't allocate the new path when loopoing over the target range, then we have to free the scan_info->cpi CCB, not the work_ccb. This was accidentally correct for the first iteration (because work_ccb == scan_info->cpi), but incorrect after that since we'll be freeing the CCB for XPT_SCAN_LUN for the prior LUN we kicked off. Reorder the free so we free it before we free scan_info so the pointer is still valid. I do not have a test case for this since it requires that we fail in the second or later iteration of the loop due to low memory, and only fuzzing would catch that. Sponsored by: Netflix Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D51169
* cam/mmc: Use xpt_path_inq instead of hand-rollded equivalentWarner Losh2025-07-071-4/+1
| | | | | | | | | | | There's no reason to inline xpt_path_inq here. While there was a mismatch between this use (CAM_PRIORITY_NONE) and the old xpt_path_inq code (which used CAM_PRIORITY_NORMAL), xpt_path_inq has been corrected to use _NONE since this is a non-queued command. Sponsored by: Netflix Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D51168
* xpt_path_inq: Use CAM_PRIORITY_NONEWarner Losh2025-07-071-1/+1
| | | | | | | | | | XPT_PATH_INQ is not a queued request. Therefore, the priority information is not relevant, and so should be marked with CAM_PRIORITY_NONE. Sponsored by: Netflix Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D51167
* cam/xpt: improve comment on xpt_path_inqWarner Losh2025-07-071-2/+2
| | | | | | | | | | | | Fix a comment about bzero maybe unnecessary. It can sometimes be redunant, but a common usage pattern puts the ccb_pathinq structure on the stack since it's small and for that scenario, it's required. It's reundant for the few places the ccb is allocated, and in those cases it does no harm. Sponsored by: Netflix Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D51166
* cam/scsi: Use xpt_path_inq() instead of hand-rolled expansionWarner Losh2025-07-071-20/+5
| | | | | | | | | | | | Use xpt_path_inq() for all XPT_PATH_INQ requests. They all should be CAM_PRIORITY_NONE since XPT_PATH_INQ is an unqueued command, so the minor changes here from _NORMAL to _NONE don't matter. And the one place we preseve the priority doesn't matter either: It's an allocated CCB, true, but it only ever stores the CPI from XPT_PATH_INQ. Sponsored by: Netflix Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D51121
* mmc_da: garbage-collect sdda_get_max_dataAndriy Gapon2025-07-041-21/+0
| | | | | | | | | | | | | The function is unused since 5aedb8b1d4a6. For information, in MMC CAM both XPT_GET_TRAN_SETTINGS and XPT_PATH_INQ obtain data using MMC_SIM_GET_TRAN_SETTINGS. So, "overlapping" information like ccb_trans_settings_mmc::host_max_data and ccb_pathinq::maxio is derived from the same source. That's why sdda_get_max_data was redundant. Reported by: bz MFC after: 5 days
* mmc_da: fix garbage in disk->d_attachmentAndriy Gapon2025-06-272-4/+2
| | | | | | | | | | | | | | | | | | | | The garbage resulted from reading the value from a ccb which was originally populated by XPT_PATH_INQ operation but then overwritten by XPT_GET_TRAN_SETTINGS operation. The problem could probably be fixed by re-ordering the XPT_GET_TRAN_SETTINGS operation, but it seems like the operation was redundant. Besides, the ccb is declared not as union ccb but as struct ccb_pathinq, so using it for XPT_GET_TRAN_SETTINGS was questionable. I opted for replacing a call to sdda_get_max_data (which uses XPT_GET_TRAN_SETTINGS internally) with using maxio provided by the XPT_PATH_INQ operation. This also required fixing mmc_cam_sim_default_action as controllers return maximum I/O size in sectors, but maxio value should be in bytes. MFC after: 2 weeks
* mmc_xpt: use strlcpy instead of strncpyAndriy Gapon2025-06-271-3/+3
| | | | | | A better practice in general. MFC after: 1 week
* cam_fill_mmcio: initialize cmd.error sub-fieldAndriy Gapon2025-06-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | For me, this fixes a problem with using eMMC storage in MMCCAM configuration with dwmmc driver (on Rock64). The problem appeared after commit 07da3bb5d56c85 "mmc: support for SPI bus type". The problem was caused by the said commit changing the layout of struct mmc_ios which is embedded into struct ccb_trans_settings_mmc with the latter being embedded into struct ccb_trans_settings, a member of union ccb. The layout mattered for two reasons: 1. dwmmc sets cmd.error only in case of an error; 2. mmc_da's sdda_start_init uses the same ccb for different transaction types without explicitly clearing the object between transactions. As a result, cmd.error could start out with a non-zero value and dwmmc would keep that value which would then be interpreted as a failure. Such a failure happened in mmc_set_timing resulting in incorrect timing settings and subsequent complete failure to communicate with the eMMC module. Reviewed by: pkelsey MFC after: 2 weeks
* pass: Update comments about scsi and devstatWarner Losh2025-06-191-3/+8
| | | | | | | | | scsi is the only transport to do tag_action, so is the only one that needs that support in devstat. Make a note of that. nvme and ata do support some ordering, but that's done in the [an]da driver for each of these devices and not for passthru commands and not via these tags. Sponsored by: Netflix
* pass: Use pointer to ccb header rather than longer constructWarner Losh2025-06-191-22/+26
| | | | | | | | | | | | | | | | | Take a pointer to the ccb header in a few places where it's not ambiguous (eg we have multiple ccbs in the routine). The code is a little shorter this way. In places we had mulitple ccbs, I refrained from doing this since that's more complex to manage. This also means that we're making a stronger guarantee to the compiler we're only accessing this part of the ccb, which reduces a few warnings from gcc with picky settings we normally disable for CAM). This makes the driver slightly less SCSI specific where csio was used to do this needlessly. There's no functional change. Sponsored by: Netflix
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-27 14:12:12 +0000