[Bug 165318] [cam] [usb] Western Digital Passport no longer "removable"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165318 Warner Losh changed: What|Removed |Added Resolution|--- |Overcome By Events Status|Open|Closed CC||i...@freebsd.org --- Comment #12 from Warner Losh --- I'm sorry that this PR did not get addressed in a timely fashion. By now, the version that it was created against is long out of support. We just report what the enclosure reports. We used to report all USB devices as removable, if I'm reading the old umass code. We're not going to change this at this point since we've had 6 major releases with this behavior. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 181954] [cam] CAM report issue when attaching usb hdd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181954 Warner Losh changed: What|Removed |Added Resolution|--- |Not Enough Information Status|Open|Closed CC||i...@freebsd.org --- Comment #3 from Warner Losh --- This is too vague to be actionable. We've also enhanced the errors reported significantly since this was filed. Since this release is out of support, I'm going to close it with my apologies for the project being so tardy in following up on it. Errors on an Inquiry command are rare. Most likely the new autoquirk code will make this work, but it's hard to know from the light info that was provided. If it's still a problem, please file a new problem. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 165740] [cam] SCSI code must drain callbacks before free
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165740 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org --- Comment #6 from Warner Losh --- This is still the case in cam_xpt.c. Generally, it looks like callout_stop() is used where callout_drain likely needs to be done. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 166621] [cam] "CAM status: Unconditionally Re-queue Request" not handled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166621 Warner Losh changed: What|Removed |Added Status|Open|Closed CC||i...@freebsd.org Resolution|--- |Not A Bug --- Comment #2 from Warner Losh --- OK. It is a bug, but the bug is in smartd. Either it should allow CAM to do the re-tries, or it should implement its own error recovery. Also, this was filed against a release that's out of support. I also use this at work in production on LSI HBAs on thousands of machines with tens of thousands disks and we don't see this. If it's still an issue, please open a bug with upstream. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 170288] camcontrol(8) inquiry command does not provide information for ata(4) harddisks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=170288 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org Status|Open|Closed Resolution|--- |Not A Bug --- Comment #3 from Warner Losh --- camcontrol identify should be used instead. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 191135] [hptrr] probe hptrr INQUIRY CDB: 12 00 00 00 24 00 CAM status: Invalid Target ID Error 22
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191135 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f52154a2044a4d1f324952af05542f93fdf0a088 commit f52154a2044a4d1f324952af05542f93fdf0a088 Author: Warner Losh AuthorDate: 2025-02-05 01:31:25 + Commit: Warner Losh CommitDate: 2025-02-05 01:38:02 + 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(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 191135] [hptrr] probe hptrr INQUIRY CDB: 12 00 00 00 24 00 CAM status: Invalid Target ID Error 22
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191135
Warner Losh changed:
What|Removed |Added
CC||i...@freebsd.org
--- Comment #3 from Warner Losh ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 243209] man page for mq_open fails to specify all conditions that may cause an [EINVAL] error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243209 Mark Linimon changed: What|Removed |Added Keywords|patch | --- Comment #4 from Mark Linimon --- ^Triage: while this PR refers to a Phabricator patch, it does not actually have a patch in and of itself. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284563] Holes in struct rtld_utrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284563
--- Comment #2 from Paul Floyd ---
(In reply to Konstantin Belousov from comment #1)
You're right, I was too quick looking at the struct. Here is the pahole output
struct utrace_rtld {
char sig[4]; /* 0 4 */
intevent;/* 4 4 */
void * handle; /* 8 8 */
void * mapbase; /*16 8 */
size_t mapsize; /*24 8 */
intrefcnt; /*32 4 */
char name[1024]; /*36 1024 */
/* size: 1064, cachelines: 17, members: 7 */
/* padding: 4 */
/* last cacheline: 40 bytes */
};
so there is just the 4 bytes of padding at the end that is uninitialized and
was triggering errors. The i386 ld.so is OK since everything is a multiple of
4.
I've already fixed this in Valgrind. I don't know whether MSAN has a similar
issue.
Zeroing the entire 1064 bytes would also fix the problem for sure.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 232347] CAM: MODE SELECT failed with SK=5h/INVALID FIELD IN PARAMETER LIST]: Input/output error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232347 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org --- Comment #2 from Warner Losh --- Has this happened on FreeBSD 13 or newer? Also, I think that the INVALID FIELD is either a bug in dvd+rw-tools or the drive has lost its mind. Normally we filter these things, but this is a READ command I think that's generated by dvd+rw-tools. If this is the case, the version doesn't matter. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284563] Holes in struct rtld_utrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284563
Bug ID: 284563
Summary: Holes in struct rtld_utrace
Product: Base System
Version: 14.2-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: b...@freebsd.org
Reporter: pjfl...@wanadoo.fr
The definition of struct rtld_utrace is
struct utrace_rtld {
char sig[RTLD_UTRACE_SIG_SZ];
int event;
/* 4 byte hole */
void *handle;
void *mapbase; /* Used for 'parent' and 'init/fini' */
size_t mapsize;
int refcnt; /* Used for 'mode' */
/* 4 byte hole */
char name[MAXPATHLEN];
};
And the interface for utrace is
335 AUE_NULLSTD|CAPENABLED {
int utrace(
_In_reads_bytes_(len) const void *addr,
size_t len
);
}
I don't know what other uses of utrace exise, but rtld ld_utrace_log does not
memset utrace_rtld to 0 before filling the fields, leaving the holes
uninitialized.
This poses a problem for Valgrind memcheck testing the syscall parameters. At
present it just uses the pointer and length to indicate memory that will be
read in the syscall (abd should be initialized). I can fix this in Valgrind by
using struct utrace_rtld.
I think that a better fix would be on the FreeBSD side by putting the 'event'
and 'refcnt' fields together. Would that be possible without breaking backwards
compatibility?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 284539] shutdown panic after 0078df5f0258: panic: vm_phys_free_pages: unexpected pool param 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284539 Ed Maste changed: What|Removed |Added Summary|shutdown panic after|shutdown panic after |0078df5f0258: panic:|0078df5f0258: panic: |vm_phys_free_pages: |vm_phys_free_pages: |unexpected pool param |unexpected pool param 0 |0https://cirrus-ci.com/task | |/5507293774610432?logs=test | |#L418 | -- You are receiving this mail because: You are the assignee for the bug.
[Bug 251844] Controlling screen brightness (i2c, ddc, ...)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251844 ykla changed: What|Removed |Added CC||ykla...@gmail.com --- Comment #6 from ykla --- What's about it now? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 284563] Holes in struct rtld_utrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284563 --- Comment #1 from Konstantin Belousov --- The name[] member does not need alignment. Regardless, would clearing the whole structure memory helps Valgrind? https://reviews.freebsd.org/D48854 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 212156] Problem with camperiphunit() interpretation of device hints
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212156 Warner Losh changed: What|Removed |Added Status|New |Closed CC||i...@freebsd.org Resolution|--- |Not A Bug --- Comment #1 from Warner Losh --- We match against a number of different things. LUN is optional, and is inferred to be 0. we can match against sn as well now. We have wired hints that just have 'at' and 'target', and others with just 'sn'. There's even a few with only 'at' and no target (for nvme wiring). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 215568] [cam] 'camcontrol rescan all' broken: CAMIOCOMMAND ioctl failed: Invalid argument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215568 Warner Losh changed: What|Removed |Added Resolution|--- |FIXED CC||i...@freebsd.org Status|New |Closed --- Comment #2 from Warner Losh --- This was long ago fixed, so just closing as fixed. -- You are receiving this mail because: You are the assignee for the bug.
