Page MenuHomeFreeBSD

chs (Chuck Silvers)
User

Projects

User Details

User Since
May 9 2018, 1:01 AM (366 w, 2 d)

Recent Activity

Fri, May 9

chs added a comment to D50134: mpi3mr: Add atomic decrement-if-not-zero helper.

this is fine as far as it goes, but the other places that already do "mpi3mr_atomic_dec(&tgtdev->block_io)" should also be converted to use the new mpi3mr_atomic_dec_if_not_zero().

Fri, May 9, 5:43 PM

Wed, Apr 23

chs committed rGf2605f67a13e: mpi3mr: configure larger max I/O size if the HBA firmware supports it (authored by chs).
mpi3mr: configure larger max I/O size if the HBA firmware supports it
Wed, Apr 23, 11:12 PM
chs closed D49090: mpi3mr: configure larger max I/O size if the HBA firmware supports it.
Wed, Apr 23, 11:12 PM

Thu, Apr 17

chs added a comment to D49749: mpi3mr: Block I/Os While Task Management is in Progress.
In D49749#1135942, @chs wrote:

Ok, I didn't realize that "task management" always meant "target reset" here. Not waiting for in-progress commands makes sense in this context. Could you add a comment to the code explaining this?

Another thing that I noticed while looking at this patch was that all the other places that decrement block_io do it in this style:

if (mpi3mr_atomic_read(&tgtdev->block_io) > 0)
        mpi3mr_atomic_dec(&tgtdev->block_io);

[ckp] Agreed, we need to check the block_io > 0 before decrementing block_io, otherwise if other thread has already decremented then the counter may go negative. I will add new patch for that. Thank you.

whereas this one you've added does not check the current value before decrementing.  is there some reason why this new instance doesn't follow the pattern of the others?

note that the pattern of the others also seems wrong... the check of the current value is not atomic with the decrement, so it looks like one thread could check the value and see that it is not zero, another thread could execute one of the paths that sets the current value to zero, and then the first thread could proceed to decrement the value and cause the value to become -1.  is there something that prevents this scenario from occurring?

[ckp] I didnt get how two thread can access the atomic variable? Is this because the v (variable) is non atomic? but atomic_subtract_int() api should take care of atomicity right? if not then please let us know any other way of making the variable and operation atomic. do we need to use this atomic_fetchadd_int() API to achieve atomicity?

#define mpi3mr_atomic_dec(v) atomic_subtract_int(&(v)->val, 1)

Thu, Apr 17, 6:43 PM

Apr 14 2025

chs added a comment to D49749: mpi3mr: Block I/Os While Task Management is in Progress.

Ok, I didn't realize that "task management" always meant "target reset" here. Not waiting for in-progress commands makes sense in this context. Could you add a comment to the code explaining this?

Apr 14 2025, 3:22 PM

Apr 11 2025

chs added a comment to D49749: mpi3mr: Block I/Os While Task Management is in Progress.

This change blocks new I/Os from being submitted while a task management command is in progress, but wouldn't you need to also wait for any in-progress I/Os to complete before submitting the task management command? I think you would need to wait for those if your goal is to avoid having the firmware processing I/O commands and task management commands together (which is what this change appears to be trying to do).

Apr 11 2025, 9:11 PM

Apr 10 2025

chs accepted D49754: mpi3mr V3 : Add mpi3mr Driver to sys/conf/files and GENERIC file for Kernel Inclusion.
Apr 10 2025, 11:37 PM
chs added a comment to D49754: mpi3mr V3 : Add mpi3mr Driver to sys/conf/files and GENERIC file for Kernel Inclusion.

I tried building with the new patch and found more problems:

Apr 10 2025, 5:18 PM
chs added a comment to D49754: mpi3mr V3 : Add mpi3mr Driver to sys/conf/files and GENERIC file for Kernel Inclusion.

in addition the changes you have here already, you'll also need to add the same line that you added to sys/conf/NOTES to sys/amd64/conf/GENERIC and sys/i386/conf/GENERIC.

Apr 10 2025, 3:52 PM

Apr 9 2025

chs updated the diff for D49090: mpi3mr: configure larger max I/O size if the HBA firmware supports it.

fix a bug I introduced when changing the calculation of cpi->maxio.

Apr 9 2025, 8:16 PM

Apr 5 2025

chs committed rG1ac6ea8a0251: kerberos5, libcom_err, others: append to LDFLAGS instead of replacing (authored by chs).
kerberos5, libcom_err, others: append to LDFLAGS instead of replacing
Apr 5 2025, 9:21 PM
chs closed D49548: kerberos5, libcom_err, others: append to LDFLAGS instead of replacing.
Apr 5 2025, 9:21 PM
chs updated the diff for D49548: kerberos5, libcom_err, others: append to LDFLAGS instead of replacing.

fixed the typo in the subject and review title

Apr 5 2025, 9:18 PM
chs retitled D49548: kerberos5, libcom_err, others: append to LDFLAGS instead of replacing from kerberos5, libcom_err, others: append to LFLAGS instead of replacing to kerberos5, libcom_err, others: append to LDFLAGS instead of replacing.
Apr 5 2025, 9:17 PM

Mar 28 2025

chs requested review of D49548: kerberos5, libcom_err, others: append to LDFLAGS instead of replacing.
Mar 28 2025, 1:15 AM

Mar 24 2025

chs accepted D49485: Remove unnecessary includes of src.opts.mk.

I was going to do this this morning but you beat me to it. sorry for the noise.

Mar 24 2025, 4:03 PM

Mar 19 2025

chs committed rG91d8ee3579ef: i386/loader: force 4k linker max page size (authored by chs).
i386/loader: force 4k linker max page size
Mar 19 2025, 8:24 PM
chs committed rGa335a52eedfd: bsnmpd: append to LDFLAGS rather than replacing it (authored by chs).
bsnmpd: append to LDFLAGS rather than replacing it
Mar 19 2025, 8:23 PM
chs committed rGdb466e475446: trim: add missing include of src.opts.mk, remove unneeded LDFLAGS (authored by chs).
trim: add missing include of src.opts.mk, remove unneeded LDFLAGS
Mar 19 2025, 8:23 PM
chs committed rG623be660fcc9: beep: add missing include of src.opts.mk, use LIBADD instead of LDFLAGS (authored by chs).
beep: add missing include of src.opts.mk, use LIBADD instead of LDFLAGS
Mar 19 2025, 8:23 PM

Feb 26 2025

chs updated the diff for D49090: mpi3mr: configure larger max I/O size if the HBA firmware supports it.

removed unnecessary roundup() and fixed some PAGE_SIZE vs MPI3MR_4K_PGSZ confusion.

Feb 26 2025, 5:20 PM
chs added a comment to D49090: mpi3mr: configure larger max I/O size if the HBA firmware supports it.

This patch had also tried to resolve some confusion between the OS PAGE_SIZE and the driver's MPI3MR_4K_PGSZ, but I got some cases wrong. I'll fix those in the next version of the patch as well.

Feb 26 2025, 5:13 PM

Feb 21 2025

chs added reviewers for D49090: mpi3mr: configure larger max I/O size if the HBA firmware supports it: chandrakanth.patil_broadcom.com, sumit.saxena_broadcom.com, imp.
Feb 21 2025, 12:38 AM
chs requested review of D49090: mpi3mr: configure larger max I/O size if the HBA firmware supports it.
Feb 21 2025, 12:35 AM

May 2 2024

chs accepted D45055: tests/sendfile: test operation on unix/stream socket.
May 2 2024, 5:37 PM
chs accepted D45054: tests/sendfile: factor out tcp_socketpair().
May 2 2024, 5:33 PM

Mar 20 2024

chs committed rG083608e4669e: UFS: panic rather than forcibly unmount the root fs (authored by chs).
UFS: panic rather than forcibly unmount the root fs
Mar 20 2024, 9:25 PM

Feb 24 2024

chs added a comment to D44049: sysutils/cpu-microcode-amd: Update to 2024-01-16 snapshot.

There are some console messages printed by the early loading code, but these happen before the regular kernel printf code is initialized, so you can only see them if you enable "options EARLY_PRINTF" in your kernel config and also use "options UART_NS8250_EARLY_PORT=0x3f8" to set which serial port the early printf output should go to. (eg. the 0x3f8 in this example is com1). you also need to boot with "-v" to enable "bootverbose" messages for the ucode early load activity to be printed.

Feb 24 2024, 7:59 PM
chs added inline comments to D44048: sysutils/cpu-microcode-rc: Update pkg-descr and pkg-message.
Feb 24 2024, 7:42 PM

Feb 23 2024

chs closed D44025: sysutils/cpu-microcode*: support early loading of AMD ucode.
Feb 23 2024, 5:29 PM
chs committed R11:8972ab311c75: sysutils/cpu-microcode*: support early loading of AMD ucode (authored by chs).
sysutils/cpu-microcode*: support early loading of AMD ucode
Feb 23 2024, 5:29 PM

Feb 22 2024

chs requested review of D44025: sysutils/cpu-microcode*: support early loading of AMD ucode.
Feb 22 2024, 6:46 PM
chs committed rG34467bd762a7: x86/ucode: add support for early loading of CPU ucode on AMD. (authored by chs).
x86/ucode: add support for early loading of CPU ucode on AMD.
Feb 22 2024, 6:08 PM
chs closed D43318: x86/ucode: add support for early loading of CPU ucode on AMD..
Feb 22 2024, 6:08 PM

Feb 21 2024

chs updated the diff for D43318: x86/ucode: add support for early loading of CPU ucode on AMD..

Updated diff for latest review comments.

Feb 21 2024, 7:00 PM
chs added inline comments to D43318: x86/ucode: add support for early loading of CPU ucode on AMD..
Feb 21 2024, 7:00 PM

Feb 13 2024

chs committed rGfd24a63a38d0: x86/ucode: add const where appropriate (authored by chs).
x86/ucode: add const where appropriate
Feb 13 2024, 4:19 PM
chs closed D43865: x86/ucode: add const where appropriate.
Feb 13 2024, 4:19 PM
chs requested review of D43865: x86/ucode: add const where appropriate.
Feb 13 2024, 4:13 PM

Jan 29 2024

chs updated the diff for D43318: x86/ucode: add support for early loading of CPU ucode on AMD..

move the code copied from cpucontrol to a new file so that we can share it between the kernel and cpucontrol.

Jan 29 2024, 9:09 PM
chs added inline comments to D43318: x86/ucode: add support for early loading of CPU ucode on AMD..
Jan 29 2024, 9:08 PM

Jan 20 2024

chs committed rG2f2da21740b4: mpi3mr: add missing terminator entry to mpi3mr_identifiers array (authored by chs).
mpi3mr: add missing terminator entry to mpi3mr_identifiers array
Jan 20 2024, 12:03 AM
chs closed D43519: mpi3mr: add missing terminator entry to mpi3mr_identifiers array.
Jan 20 2024, 12:03 AM

Jan 19 2024

chs added reviewers for D43519: mpi3mr: add missing terminator entry to mpi3mr_identifiers array: chandrakanth.patil_broadcom.com, sumit.saxena_broadcom.com.
Jan 19 2024, 11:58 PM
chs requested review of D43519: mpi3mr: add missing terminator entry to mpi3mr_identifiers array.
Jan 19 2024, 11:55 PM

Jan 10 2024

chs added a comment to D43318: x86/ucode: add support for early loading of CPU ucode on AMD..

I added the handling you requested for the loader blob containing all of the amd ucode files concatenated together.

Jan 10 2024, 7:37 PM
chs updated the diff for D43318: x86/ucode: add support for early loading of CPU ucode on AMD..

updated patch with requested changes

Jan 10 2024, 7:36 PM

Jan 4 2024

chs requested review of D43318: x86/ucode: add support for early loading of CPU ucode on AMD..
Jan 4 2024, 7:30 PM

Jan 2 2024

chs accepted D43261: Minor improvements for vtruncbuf().
Jan 2 2024, 9:48 PM

Oct 13 2023

chs committed rGc545a7b2c7db: prf: add setting of msgbuftrigger in paths where it is missing (authored by chs).
prf: add setting of msgbuftrigger in paths where it is missing
Oct 13 2023, 10:03 PM
chs closed D42173: prf: add setting of msgbuftrigger in paths where it is missing.
Oct 13 2023, 10:03 PM
chs added a comment to D42173: prf: add setting of msgbuftrigger in paths where it is missing.

I agree, this msgbuftrigger thing is rather loosey-goosey. I'm just trying to have all the msgbuf paths achieve a consistent level of loosey-gooseyness.

Oct 13 2023, 9:59 PM

Oct 12 2023

chs requested review of D42173: prf: add setting of msgbuftrigger in paths where it is missing.
Oct 12 2023, 6:45 PM

Aug 10 2023

chs committed rG60a41168d195: UFS: panic rather than forcibly unmount the root fs (authored by chs).
UFS: panic rather than forcibly unmount the root fs
Aug 10 2023, 5:05 PM
chs closed D41387: UFS: panic rather than forcibly unmount the root fs.
Aug 10 2023, 5:05 PM

Aug 8 2023

chs added reviewers for D41387: UFS: panic rather than forcibly unmount the root fs: karels, mckusick.
Aug 8 2023, 7:20 PM
chs requested review of D41387: UFS: panic rather than forcibly unmount the root fs.
Aug 8 2023, 7:18 PM

Jun 4 2023

chs committed rG89bd147dbf8e: ffs: restore backward compatibility of newfs and makefs with older binaries (authored by chs).
ffs: restore backward compatibility of newfs and makefs with older binaries
Jun 4 2023, 5:20 PM

May 30 2023

chs committed rGd464a7698de8: ffs: restore backward compatibility of newfs and makefs with older binaries (authored by chs).
ffs: restore backward compatibility of newfs and makefs with older binaries
May 30 2023, 2:28 AM

May 11 2023

chs closed D40054: fbt/x86: update FBT_AFRAMES to match the trap handlers.
May 11 2023, 5:56 PM
chs committed rG90951695207f: fbt/x86: update FBT_AFRAMES to match the trap handlers (authored by chs).
fbt/x86: update FBT_AFRAMES to match the trap handlers
May 11 2023, 5:56 PM
chs added a reviewer for D40054: fbt/x86: update FBT_AFRAMES to match the trap handlers: markj.
May 11 2023, 1:45 AM
chs updated the summary of D40054: fbt/x86: update FBT_AFRAMES to match the trap handlers.
May 11 2023, 1:44 AM
chs requested review of D40054: fbt/x86: update FBT_AFRAMES to match the trap handlers.
May 11 2023, 1:41 AM

May 8 2023

chs committed rGdb1a4d9c4569: fsck_ffs: fix the previous change that skipped pass 5 in some cases (authored by chs).
fsck_ffs: fix the previous change that skipped pass 5 in some cases
May 8 2023, 6:34 PM

May 3 2023

chs committed rG406475581246: fsck_ffs: fix the previous change that skipped pass 5 in some cases (authored by chs).
fsck_ffs: fix the previous change that skipped pass 5 in some cases
May 3 2023, 8:33 PM

Mar 29 2023

chs added a comment to D39246: Improvement in UFS/FFS directory placement when doing mkdir(2).

You have a very valid point. I addressed this by having just a single message come out when running with -p (preen mode). When encountering a filesystem with no depths it prints `UPDATING FILESYSTEM TO TRACK DIRECTORY DEPTH'' then updates all the directory depths. When running in interactive mode and -y mode it asks once `UPDATE FILESYSTEM TO TRACK DIRECTORY DEPTH?'' then just does it. No further reporting happens in either case.

Mar 29 2023, 11:53 PM

Mar 27 2023

chs added a comment to D39246: Improvement in UFS/FFS directory placement when doing mkdir(2).

The concern I have with this change is about user interface. With this patch, if someone renames a directory that is the root of a subtree containing other directories and then unmounts the file system cleanly, fsck will report that the file system is now corrupted because all of the dirdepth values for directories in that subtree are wrong. In fact, every existing file system will immediately be reported as corrupted the first time that the new fsck is run. There are millions of people in the world who know what the fsck output for a clean and uncorrupted UFS file system looks like, and that clean fsck output is very easy to recognize because it's very short and always the same (modulo the line with the last-mounted-on path and the line at the end with the block/inode usage and fragmentation summary). After this patch, fsck can produce millions of lines of output for file systems that aren't really corrupted but rather are merely not optimal, and it will no longer be so simple to tell if a file system is corrupted or not by looking at the fsck output.

Mar 27 2023, 7:50 PM

Dec 12 2022

chs committed rG9dda00df7e8f: restore: fix restore of NFS4 ACLs (authored by chs).
restore: fix restore of NFS4 ACLs
Dec 12 2022, 4:21 PM
chs closed D37618: restore: fix restore of NFS4 ACLs.
Dec 12 2022, 4:20 PM

Dec 6 2022

chs retitled D37618: restore: fix restore of NFS4 ACLs from Changing the mode bits on a file with an NFS4 ACL results in the NFS4 ACL being replaced by one matching the new mode bits being set, so when restoring a file with an NFS4 ACL, set the owner/group/mode first and then set the NFS4 ACL, so that... to restore: fix restore of NFS4 ACLs.
Dec 6 2022, 10:26 PM
chs requested review of D37618: restore: fix restore of NFS4 ACLs.
Dec 6 2022, 10:24 PM

Nov 1 2022

chs committed rGf0f3e3e961d3: ipmi: use a queue for kcs driver requests when possible (authored by chs).
ipmi: use a queue for kcs driver requests when possible
Nov 1 2022, 5:55 PM
chs closed D36555: ipmi: use a queue for kcs driver requests when possible.
Nov 1 2022, 5:55 PM

Oct 11 2022

chs added inline comments to D36555: ipmi: use a queue for kcs driver requests when possible.
Oct 11 2022, 10:47 PM

Sep 13 2022

chs requested review of D36555: ipmi: use a queue for kcs driver requests when possible.
Sep 13 2022, 11:23 PM

Sep 8 2022

chs accepted D36474: Handle out-of-bounds file timestamps in ls(1) and find(1).
Sep 8 2022, 7:26 PM

Jun 23 2022

chs added a comment to D34793: Add experimental 16k PAGE_SIZE support on arm64.

I was waiting for the UFS fixes to land.

Jun 23 2022, 2:22 AM

Jun 22 2022

chs committed rGf1b4324b81a5: ffs: fix vn_read_from_obj() usage for PAGE_SIZE > block size (authored by chs).
ffs: fix vn_read_from_obj() usage for PAGE_SIZE > block size
Jun 22 2022, 9:58 PM
chs closed D34836: ffs: fix vn_read_from_obj() usage for PAGE_SIZE > block size.
Jun 22 2022, 9:58 PM
chs updated the diff for D34836: ffs: fix vn_read_from_obj() usage for PAGE_SIZE > block size.

Updated the diff based on review comments.
The suggestion was to only enable vn_read_from_obj() if the fs fragment size is larger than the page size, but it's actually fine to use vn_read_from_obj() as long as the fs block size is greater than or equal to the page size, so I made the check that way.

Jun 22 2022, 1:29 AM
chs committed rG5bd21cbbd1df: vfs: fix vfs_bio_clrbuf() for PAGE_SIZE > block size (authored by chs).
vfs: fix vfs_bio_clrbuf() for PAGE_SIZE > block size
Jun 22 2022, 1:00 AM
chs closed D34837: vfs: fix vfs_bio_clrbuf() for PAGE_SIZE > block size.
Jun 22 2022, 1:00 AM
chs committed rG82817f26f8ec: ffs: fix vn_io_fault_pgmove() offset for PAGE_SIZE > block size (authored by chs).
ffs: fix vn_io_fault_pgmove() offset for PAGE_SIZE > block size
Jun 22 2022, 12:56 AM
chs closed D34835: ffs: fix vn_io_fault_pgmove() offset for PAGE_SIZE > block size.
Jun 22 2022, 12:56 AM

May 9 2022

chs accepted D35149: ffs_use_bwrite: make the superblock snapshot more consistent.
May 9 2022, 3:57 PM

Apr 28 2022

chs accepted D35093: cam_periph: Return ENXIO when peripheral is invalidated.

This makes sense to me.

Apr 28 2022, 9:01 PM

Apr 11 2022

chs added a comment to D34836: ffs: fix vn_read_from_obj() usage for PAGE_SIZE > block size.

No, in this example of 16k pages and 4k blocks, the first page would contain the first 4 blocks, the second page would contain the next 4 blocks, etc, so mmap'ing the file works as you would expect.

Apr 11 2022, 7:08 PM

Apr 8 2022

chs closed D34806: ffs: wait for trims earlier during unmount to avoid panic.
Apr 8 2022, 5:24 PM
chs committed rG3dc5f8e19d8c: ffs: wait for trims earlier during unmount to avoid panic (authored by chs).
ffs: wait for trims earlier during unmount to avoid panic
Apr 8 2022, 5:24 PM

Apr 7 2022

chs updated the diff for D34806: ffs: wait for trims earlier during unmount to avoid panic.

made requested changes.

Apr 7 2022, 10:26 PM
chs requested review of D34837: vfs: fix vfs_bio_clrbuf() for PAGE_SIZE > block size.
Apr 7 2022, 8:15 PM
chs requested review of D34836: ffs: fix vn_read_from_obj() usage for PAGE_SIZE > block size.
Apr 7 2022, 8:15 PM
chs requested review of D34835: ffs: fix vn_io_fault_pgmove() offset for PAGE_SIZE > block size.
Apr 7 2022, 8:15 PM

Apr 6 2022

chs requested review of D34806: ffs: wait for trims earlier during unmount to avoid panic.
Apr 6 2022, 5:54 PM

Feb 28 2022

chs accepted D32697: Create a union GEOM module.
Feb 28 2022, 6:07 PM
chs accepted D34259: Report I/O stats from the CAM_IOSCHED_DYNAMIC extension.
Feb 28 2022, 5:43 PM

Feb 24 2022

chs accepted D34365: cam: add hw.cam.iosched.read_bias.
Feb 24 2022, 12:50 AM

Feb 23 2022

chs added a comment to D34259: Report I/O stats from the CAM_IOSCHED_DYNAMIC extension.

It would be good to go ahead and resolve the XXX comments that are currently being added by the patch.

Feb 23 2022, 11:54 PM
chs added a comment to D34351: cam iosched: Allow read bias to be 0.

I would characterize this change as: redefine "read_bias==0" from the current meaning of "prefer writes" to instead mean "no read-vs-write bias".
This patch looks correct in implementing that new meaning, though it would be nice if it didn't involve essentially duplicating the code of cam_iosched_get_write() in cam_iosched_next_bio().

Feb 23 2022, 9:17 PM