Bug 191135 - [hptrr] probe hptrr INQUIRY CDB: 12 00 00 00 24 00 CAM status: Invalid Target ID Error 22
Summary: [hptrr] probe hptrr INQUIRY CDB: 12 00 00 00 24 00 CAM status: Invalid Target...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Warner Losh
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-17 20:58 UTC by conzales_demon
Modified: 2025-05-11 12:16 UTC (History)
3 users (show)

See Also:
linimon: mfc-stable14?
linimon: mfc-stable13?


Attachments
original file and modified version 'hptrr_osm_bsd.c' FreeBSD10-RELEASE (19.69 KB, application/x-zip-compressed)
2014-06-17 20:58 UTC, conzales_demon
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description conzales_demon 2014-06-17 20:58:40 UTC
Created attachment 143880 [details]
original file and modified version 'hptrr_osm_bsd.c' FreeBSD10-RELEASE

I'm not a programmer so if this is a messy bug report: "Don't shoot the messenger!" ;)
===========================================================================
'probe hptrr INQUIRY CDB: 12 00 00 00 24 00 CAM status: Invalid Target ID Error 22'

The message above scrolls endlessly on the terminal during booting after POST. The problem doesn't only exist with the 'hptrr' driver but other 'scsi/cam' drivers as well (twa -- 3ware). More info on 'twa' here: https://groups.google.com/forum/#!msg/fa.freebsd.stable/BbK2Q9SFca0/VimqyyD1a2oJ

Please do a diff on the two files I sent with this report as it was the solution for me. I don't get the message anymore and everthing works fine. The solution is not mine, I only applied it to the hptrr-driver. Since I'm not a programmer I can not predict if the changes bring any problems with stability or reliability (data corruption etc.)

So it would be great if somebody with storage driver knowledge could look at the solution. The few lines changed were recommended by somebody with the same problem only with a different CAM-driver. If can find the original message and posted solution (that i copied) I'll post it here.

This problem started after I installed FreeBSD 9.2-RELEASE, 10-RELEASE still has it. I believe 8.4-RELEASE didn't have this problem.
Comment 1 conzales_demon 2014-06-17 21:15:55 UTC
Update
==================================================
I believe I got the fix from here (hpt27 driver):
https://www.mail-archive.com/freebsd-stable@freebsd.org/msg124458.html
Comment 2 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:38:21 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
Comment 3 Warner Losh freebsd_committer freebsd_triage 2025-02-05 01:31:03 UTC
diff --git a/sys/dev/hptrr/hptrr_osm_bsd.c b/sys/dev/hptrr/hptrr_osm_bsd.c
index 42866c1d4297..78a051d54cf8 100644
--- a/sys/dev/hptrr/hptrr_osm_bsd.c
+++ b/sys/dev/hptrr/hptrr_osm_bsd.c
@@ -463,7 +463,7 @@ static void os_cmddone(PCOMMAND pCmd)
                ccb->ccb_h.status = CAM_BUSY;
                break;
        default:
-           ccb->ccb_h.status = CAM_SCSI_STATUS_ERROR;
+         ccb->ccb_h.status = CAM_AUTOSENSE_FAIL;
                break;
        }

@@ -557,7 +557,7 @@ static void hpt_scsi_io(PVBUS_EXT vbus_ext, union ccb *ccb)
                ccb->ccb_h.target_id >= osm_max_targets ||
                (ccb->ccb_h.flags & CAM_CDB_PHYS))
        {
-           ccb->ccb_h.status = CAM_TID_INVALID;
+         ccb->ccb_h.status = CAM_SEL_TIMEOUT;
                xpt_done(ccb);
                return;
        }

is the diff. I'm torn on committing it. This driver is super hard to test, has binary elements and likely should be deleted in FreeBSD 15. So the above compiles, and was also reported by jmg as working based on a tip from Scott Long, which is a fairly decent provenance. But it's 10 years old now and nobody has been complaining in the mean time. I came down on the side of committing it, but no MFC unless we delete this driver.
Comment 4 commit-hook freebsd_committer freebsd_triage 2025-02-05 01:38:38 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=f52154a2044a4d1f324952af05542f93fdf0a088

commit f52154a2044a4d1f324952af05542f93fdf0a088
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2025-02-05 01:31:25 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2025-02-05 01:38:02 +0000

    hptrr: Better error recovery

    This bug and https://www.mail-archive.com/freebsd-stable@freebsd.org/msg124458.html
    both have this fix. It turns unknown errors into an autosense failure, which causes
    us to grab the sense buffer manually. It also sets a condition that we use to retry
    timed out commands that jmg reports as being helpful.

    I'm torn on committing it. The code seems fine in terms of fixing
    things. But this is a 10-year-old bug with few other bugs and a short CC
    list for a driver that might go away in 15 anyway. I'm going to commit
    and close the bug, and MFC it in a week, unless someone complains (which
    seems unliekly, given the age of this hardware, I susepct most of it is
    out of service).

    Suggested by: jmg, Scott Long
    PR: 191135
    MFC After: 1 week
    Reviewed by: imp

 sys/dev/hptrr/hptrr_osm_bsd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2025-02-14 16:55:40 UTC
^Triage: assign to committer, set flags for possible MFCs (just close if not).
Comment 6 commit-hook freebsd_committer freebsd_triage 2025-02-19 00:19:48 UTC
A commit in branch stable/14 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=417e57b4764ae29e3fbcb7e17466fa6c55fa95a1

commit 417e57b4764ae29e3fbcb7e17466fa6c55fa95a1
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2025-02-05 01:31:25 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2025-02-18 23:59:44 +0000

    hptrr: Better error recovery

    This bug and https://www.mail-archive.com/freebsd-stable@freebsd.org/msg124458.html
    both have this fix. It turns unknown errors into an autosense failure, which causes
    us to grab the sense buffer manually. It also sets a condition that we use to retry
    timed out commands that jmg reports as being helpful.

    I'm torn on committing it. The code seems fine in terms of fixing
    things. But this is a 10-year-old bug with few other bugs and a short CC
    list for a driver that might go away in 15 anyway. I'm going to commit
    and close the bug, and MFC it in a week, unless someone complains (which
    seems unliekly, given the age of this hardware, I susepct most of it is
    out of service).

    Suggested by: jmg, Scott Long
    PR: 191135
    MFC After: 1 week
    Reviewed by: imp

    (cherry picked from commit f52154a2044a4d1f324952af05542f93fdf0a088)

 sys/dev/hptrr/hptrr_osm_bsd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)