User Details
- User Since
- May 9 2018, 1:01 AM (366 w, 2 d)
Fri, May 9
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().
Wed, Apr 23
Thu, Apr 17
Apr 14 2025
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 11 2025
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 10 2025
I tried building with the new patch and found more problems:
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 9 2025
fix a bug I introduced when changing the calculation of cpi->maxio.
Apr 5 2025
fixed the typo in the subject and review title
Mar 28 2025
Mar 24 2025
I was going to do this this morning but you beat me to it. sorry for the noise.
Mar 19 2025
Feb 26 2025
removed unnecessary roundup() and fixed some PAGE_SIZE vs MPI3MR_4K_PGSZ confusion.
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 21 2025
May 2 2024
Mar 20 2024
Feb 24 2024
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 23 2024
Feb 22 2024
Feb 21 2024
Updated diff for latest review comments.
Feb 13 2024
Jan 29 2024
move the code copied from cpucontrol to a new file so that we can share it between the kernel and cpucontrol.
Jan 20 2024
Jan 19 2024
Jan 10 2024
I added the handling you requested for the loader blob containing all of the amd ucode files concatenated together.
updated patch with requested changes
Jan 4 2024
Jan 2 2024
Oct 13 2023
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 12 2023
Aug 10 2023
Aug 8 2023
Jun 4 2023
May 30 2023
May 11 2023
May 8 2023
May 3 2023
Mar 29 2023
Mar 27 2023
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.
Dec 12 2022
Dec 6 2022
Nov 1 2022
Oct 11 2022
Sep 13 2022
Sep 8 2022
Jun 23 2022
I was waiting for the UFS fixes to land.
Jun 22 2022
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.
May 9 2022
Apr 28 2022
This makes sense to me.
Apr 11 2022
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 8 2022
Apr 7 2022
made requested changes.
Apr 6 2022
Feb 28 2022
Feb 24 2022
Feb 23 2022
It would be good to go ahead and resolve the XXX comments that are currently being added by the patch.
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().