On Sat, Aug 29, 2020 at 09:24:30AM +0200, Martin Kepplinger wrote: > On 27.08.20 22:29, Alan Stern wrote: > > Instead, look at sd_resume(). That routine calls __scsi_execute() > > indirectly through sd_start_stop_device(), and the only reason it does > > this is because the sdkp->device->manage_start_stop flag is set. You > > ought to be able to clear this flag in sysfs, by writing to > > /sys/block/sda/device/scsi_disk/*/manage_start_stop. If you do this > > before allowing the card reader to go into runtime suspend, does it then > > resume okay? > > manage_start_stop in sysfs is 0 here. Hmmm. I'm wondering about something you wrote back in June (https://marc.info/?l=linux-scsi&m=159345778431615&w=2): blk_queue_enter() always - especially when sd is runtime suspended and I try to mount as above - sets success to be true for me, so never continues down to bkl_pm_request_resume(). All I see is "PM: Removing info for No Bus:sda1". blk_queue_enter() would always set success to be true because pm (derived from the BLK_MQ_REQ_PREEMPT flag) is true. But why was the BLK_MQ_REQ_PREEMPT flag set? In other words, where was blk_queue_enter() called from? Can you get a stack trace (i.e., call dump_stack()) at exactly this point, that is, when pm is true and q->rpm_status is RPM_SUSPENDED? Or do you already know the answer? Alan Stern
