Hi alan: 2015-05-07 2:16 GMT+08:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Thu, 7 May 2015, yoma sophian wrote: > >> > Besides, the kernel already contains a thread that calls >> > sd_check_events periodically. Why do you need to write a new one? >> I create the thread since some buggy devices needs to periodically >> polling to let it not going to disconnection. >> Would you mind to let me know which kernel thread that calls >> sd_check_events periodically? > > There is not a dedicated thread. Each block device has a workqueue > item that runs on the system_freezable_power_efficient_wq work queue. > For more information, see the "Disk events" section of block/genhd.c. > In particular, look at the disk_check_events() routine. > > For a typical USB storage device, the system will poll for media > changes by calling sd_check_events. > >> >> My questions are: >> >> a. is there any system flag such suspend/resume in scsi layer for >> >> checking before sending command to downlayer driver, such as usb. >> > >> > I don't know of any. In general, the kernel is designed so that no >> > SCSI commands will be sent while the system is in suspend or >> > hibernation, so no checking is needed. >> which flag or callback function we used to determine the system is in >> suspend or hibernation? >> udev->state? > > You don't use any flags or callbacks, and you don't determine when the > system is in suspend or hibernation. Instead you make your thread > freezable, so that it will get frozen automatically whenever the system > goes into suspend or hibernation. > After reading the kernel power document, freezing-of-tasks.txt , can I get the below conclusion: if I put my thread in freezable, it will get frozen automatically whenever the system goes in to suspend or hibernate. And automatically be waked up when all other thread finish their job? in my case, since I didn't put my own sd_check_events thread into freezable case. once the system resume, it will cause the race condition as I mentioned previously, right? if my conclusion is correct, would you mind to let me know where the kernel sequencially wake up normal then freezable threads? appreciate your kind help, -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
