On Fri, 2024-04-19 at 14:28 -0500, michael.christie@xxxxxxxxxx wrote: > On 4/18/24 1:10 PM, Laurence Oberman wrote: > > Resend of this patch as V2 against Martin's tree. > > Changes: Removed initialization of global variable > > storage_quiet_discovery > > > > This new parameter storage_quiet_discovery defaults to 0 and > > behavior is > > unchanged. If its set to 1 on the kernel line then sd_printk and > > sdev_printk are disabled for printing. The default logging can be > > re-enabled any time after boot using /etc/sysctl.conf by setting > > dev.scsi.storage_quiet_discovery = 0. > > systctl -w dev.scsi.storage_quiet_discovery=0 will also change it > > immediately back to logging. i > > Users can leave it set to 1 on the kernel line and 0 in the conf > > file > > so it changes back to default after rc.sysinit. > > This solves the tough problem of systems with 1000's of > > storage LUNS consuming a system and preventing it from booting due > > to > > NMI's and timeouts due to udev triggers. > > > > I didn't see v1 so maybe this was already asked. Why can you use the > existing SCSI_LOG infrastructure for this? > > For example, are the printks that are causing you problems specific > calls that are not already covered by SCSI_LOG, like the sdev_printk > in > scsi_probe_lun? Do we just want to have those covered by a new > SCSI_LOG > value like SCSI_LOG_DISCOVERY? > > > Mike and Bart, Thank you I think I looked at this some years back and customers wanted an off during boot but then on workflow. I sent the patch a few years back but the problem has not gone away so I resent. Back Monday after review of your suggestions. Regards Laurence
