devkit-disks-probe-ata-smart just calls sk_disk_open() and sk_disk_smart_is_available(), so something in those will most probably trigger the problem. It's not clear to me yet whether libatasmart does an invalid operation, or whether a valid operation triggers a kernel bug, so I keep both tasks open for now. The weird thing is that the calls actually succeed and it detects the SMART capability just fine.
sk_disk_smart_is_available() just checks a bit in a struct, and does not actually do any calls. All the magic is done by sk_disk_open(). What would be required now is someone going through devkit-disks-probe-ata-smart and sk_disk_open() with gdb singlestepping and find out which particular call/ioctl causes the USB resets.
What by and large happens is:
- readonly open() of the device
- fstat() and checks if it's a block device
- BLKGETSIZE64 ioctl
- some calls to libudev to get vendor, product, and bus type properties from sysfs
- some SK_ATA_COMMAND_IDENTIFY_DEVICE ATA commands
- call SK_SMART_COMMAND_ENABLE_OPERATIONS to enable smart if available
Anyone on this bug who understands gdb and can reproduce the problem?
devkit- disks-probe- ata-smart just calls sk_disk_open() and sk_disk_ smart_is_ available( ), so something in those will most probably trigger the problem. It's not clear to me yet whether libatasmart does an invalid operation, or whether a valid operation triggers a kernel bug, so I keep both tasks open for now. The weird thing is that the calls actually succeed and it detects the SMART capability just fine.
sk_disk_ smart_is_ available( ) just checks a bit in a struct, and does not actually do any calls. All the magic is done by sk_disk_open(). What would be required now is someone going through devkit- disks-probe- ata-smart and sk_disk_open() with gdb singlestepping and find out which particular call/ioctl causes the USB resets.
What by and large happens is:
- readonly open() of the device COMMAND_ IDENTIFY_ DEVICE ATA commands COMMAND_ ENABLE_ OPERATIONS to enable smart if available
- fstat() and checks if it's a block device
- BLKGETSIZE64 ioctl
- some calls to libudev to get vendor, product, and bus type properties from sysfs
- some SK_ATA_
- call SK_SMART_
Anyone on this bug who understands gdb and can reproduce the problem?