Unfortunately the Ubuntu kernel is not configured for ftrace or kprobe, and I am operating this server so I am not sure if I will eventually find the time and the risk to install a self-compiled kernel 2018-03-08 11:53 GMT+01:00 Steffen Maier <maier@xxxxxxxxxxxxxxxxxx>: > > On 03/08/2018 11:34 AM, Menion wrote: >> >> I did some more test >> This log is specific from the function sd_read_capacitysd_revalidate_disk >> From what I can see, it seems that it is called only when probing >> newly attached devices >> A quick look in the code I see that it is called by sd_revalidate_disk >> This function is registered by fops for the scsi device or called >> directly by sd_probe (via sd_probe_async) >> So, assuming that there is no disconnection ad USB level (and it is >> not since I don't get any log of it), the question is: how can trigger >> a probe or call the sd_revalidate_disk? >> Can it be the filesystem? > > > echo 1 > /sys/class/scsi_device/.../device/rescan > ? > > That's what I meant with "sdev _rescan_" in my previous mail. > > Not sure what call paths lead to sd_revalidate_disk(). > >> 2018-03-08 11:10 GMT+01:00 Menion <menion@xxxxxxxxx>: >>> >>> Anyhow, I checked something that I should have checked since the >>> beginning. >>> I have stopped smartd and I still get this log, so it is something >>> else doing it, but does anyone have an idea how understand what >>> subsystem is calling again and again the read_capacity_10? > > > ftrace: kernel function trace > [https://lwn.net/Articles/365835/, https://lwn.net/Articles/366796/] > or dynamically attach a kprobe > [https://www.kernel.org/doc/Documentation/trace/kprobetrace.txt] > to see which process calls this (indirectly) > >>> 2018-03-08 10:16 GMT+01:00 Menion <menion@xxxxxxxxx>: >>>> >>>> I have tried it, but it does not work: >>>> >>>> [ 39.230095] sd 0:0:0:0: [sda] Very big device. Trying to use READ >>>> CAPACITY(16). > > >>>> [ 348.134002] sd 0:0:0:0: [sda] Very big device. Trying to use READ >>>> CAPACITY(16). > > >>>> [ 657.963478] sd 0:0:0:0: [sda] Very big device. Trying to use READ >>>> CAPACITY(16). > > >>>> 2018-03-07 18:14 GMT+01:00 Douglas Gilbert <dgilbert@xxxxxxxxxxxx>: >>>>> >>>>> On 2018-03-07 09:02 AM, Menion wrote: >>>>>> >>>>>> 2018-03-07 14:51 GMT+01:00 Steffen Maier <maier@xxxxxxxxxxxxxxxxxx>: >>>>>>> >>>>>>> On 03/07/2018 09:24 AM, Menion wrote: > > >>>>>>> but from then on, you only get it roughly once every 300 seconds, >>>>>>> i.e. 5 >>>>>>> minutes >>>>>>> >>>>>>> that's where I suspect user space as trigger, unless there is a >>>>>>> kernel >>>>>>> feature I'm not aware of doing such sdev rescans >>>>>>> >>>>>>> preventing this would be a workaround > > >>>>>> Is it possible that it is smartd? It is the only daemon that could do >>>>>> some low level access to the device (bypassing the filesystem) > > >>>>> https://github.com/mirror/smartmontools >>>>> >>>>> To check it is the revision (svn rev >= 4718) you need for this fix, >>>>> look >>>>> at the top of the ChangeLog file and look for today's date (20180307). > > >>>>> Currently smartmontools only has a quirks database (and it is large) >>>>> for ATA devices, not real or pseudo SCSI device, nor NVMe devices >>>>> (yet). >>>>> Hopefully this fix will be sufficient. >>>>> >>>>> If it does not work, please send me the details. > > >>>>>>>> /* >>>>>>>> * Many devices do not respond properly to >>>>>>>> READ_CAPACITY_16. >>>>>>>> * Tell the SCSI layer to try READ_CAPACITY_10 >>>>>>>> first. >>>>>>>> * However some USB 3.0 drive enclosures return >>>>>>>> capacity >>>>>>>> * modulo 2TB. Those must use READ_CAPACITY_16 >>>>>>>> */ >>>>>>>> if (!(us->fflags & US_FL_NEEDS_CAP16)) >>>>>>>> sdev->try_rc_10_first = 1; >>>>>>> >>>>>>> >>>>>>> if that's the cause, maybe an entry in >>>>>>> drivers/usb/storage/unusual_devs.h >>>>>>> would help, but that's really just guessing as I'm not familiar with >>>>>>> USB >>>>>> >>>>>> >>>>>> It seems that the bridge does have an entry in unusual_devs.h: >>>>>> >>>>>> /* Reported by Michael Büsch <m@xxxxxxx> */ >>>>>> UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116, >>>>>> "JMicron", >>>>>> "USB to ATA/ATAPI Bridge", >>>>>> USB_SC_DEVICE, USB_PR_DEVICE, NULL, >>>>>> US_FL_BROKEN_FUA ), >>>>>> >>>>>> VID:PID is 0x152d 0x0567, not sure what are the other two numbers, so >>>>>> I went back and used another enclosure with same USB to SATA bridge. >>>>>> The strange thing is that this other enclosure goes in UAS mode while >>>>>> the one for which I am reporting the issue goes in usb-storage mode >>>>>> because it gets somehow the quirks 0x50000000 >>>>>> Unfortunately I cannot move these 5 HDDs in the other enclosure. So do >>>>>> you think that it shall be reported to linux-usb maybe? > > > -- > Mit freundlichen Grüßen / Kind regards > Steffen Maier > > Linux on z Systems Development > > IBM Deutschland Research & Development GmbH > Vorsitzende des Aufsichtsrats: Martina Koederitz > Geschaeftsfuehrung: Dirk Wittkopp > Sitz der Gesellschaft: Boeblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 >
