User Details
- User Since
- Jun 4 2014, 7:07 AM (245 w, 3 d)
Dec 31 2018
Dec 24 2018
Dec 21 2018
Dec 20 2018
Can you do the same for mpr?
Also, can you add the same changes for mpr?
One small thing to consider is whether to create a new typedef for cm_timeout_handler, even if it's the same implementation is mps_command_callback_t for now. The reason is that we might want to evolve this into a different function call signature for the timeout handler. This might be useful for mps_scsiio_timeout().
Dec 9 2018
Switch to using an atomic swap for grabbing and clearing the reply
descriptor. This also undoes the unneeded churn from the last
revision. It makes the driver reliant on there being 64bit atomics,
which means that it won't work on powerpc anymore. C'est la vie!
I'm marking this as accepted despite my individual comments.
Nov 13 2018
Sep 6 2018
Aug 14 2018
But CAM right now isn't great about knowing we're in 'shutdown' mode where error recovery might not be a good idea (but it might... It's unclear to me that we can say never here). In the mean time, doing the polling I think is a good 'make it better w/o letting the perfect be the enemy of the better' compromise.
Aug 13 2018
I think that this is going in the right direction. The SSU/shutdown code in mpr/mps is still not great, IMHO. There's a completion handler for the SSU CCB that could take care of decrementing the SSU_refcount, but instead every I/O is checked for the SSU state in the normal command completion path, and the refcount decrement happens there. The cost of checking every I/O for the uncommon shutdown case is probably in the noise right now, but if we ever want these drivers to do millions of IOPS, it'll need to be addressed. Also, error recovery is going to be highly problematic. Protocol-level recovery is non-existent because the completion handler doesn't call cam_periph_error(), but transport-level error recovery (for things like timeouts) will likely still be called from the driver. Do we want error recovery to be triggered during a system shutdown, possibly triggering extra delays? If an error does happen, does ignoring it make the device problematic the next time the system starts up? If we want the driver to ignore transport level error recovery, how should that be flagged?
Jun 26 2018
May 14 2018
May 1 2018
Apr 15 2018
Mar 25 2018
Mar 12 2018
Feb 21 2018
Feb 18 2018
Feb 11 2018
Feb 8 2018
Unfortunately, there are some big drawbacks to this approach. The larger you make the chain frame pool, the more pressure you put on the contigmalloc allocator. This is usually (though not always!) not a problem at boot, but would be a big problem with loading the driver as a module after boot. I agree with the desire to make the chain frame pool be self-tuning, but I think that to do it the right way, the pool must be allocated in multiple smaller segments of no more than 2MB each (i.e. 16384 frames). It should also handle potential allocation failures. Without this, I feel that your approach will be too fragile.
Feb 6 2018
Feb 5 2018
Good find on this. I've seen queue-full conditions in the past but hadn't tracked down the causes; I think this is it.
Feb 4 2018
Jan 27 2018
Jan 26 2018
Jan 25 2018
I think you forgot to add the implementation for CAM_PERIPH_PRINT(). Mine looks like this in cam_periph.h:
Something in this patch is causing my system to spontaneously reboot late in the boot process. No panic, and the messages on the screen disappear too quickly (and are erased in the serial console by the BIOS splash screen).
Jan 23 2018
Jan 19 2018
Looks good to me. I'm OK with removing scsi_low and all related code for FreeBSD 12.
I came across it during some other clean-up work.
Jan 11 2018
Jan 10 2018
Jan 9 2018
Dec 6 2017
Nov 29 2017
Nov 20 2017
Nov 17 2017
Nov 15 2017
Nov 13 2017
Nov 10 2017
Oct 26 2017
Oct 24 2017
Oct 1 2017
Sep 29 2017
Sep 24 2017
Sep 23 2017
Sep 22 2017
Sep 18 2017
Sep 15 2017
Sep 11 2017
Sep 10 2017
Sep 9 2017
Sep 8 2017
Sep 6 2017
Aug 29 2017
Aug 27 2017
Resolved in r322943