Re: ] Sandisk Ultra Fit USB 3.0 thumb drive overheating way more than same USB does in Windows
On Fr, 2018-08-03 at 16:15 +0100, Mustafa A wrote: > The drive (128GB USB 3.0) > https://www.sandisk.co.uk/home/usb-flash/ultra-fit-usb overheats to the point > where the metal part would burn someone if they held it for more than a > second. > > The overheating only happens on this brand of USB drives, other USB 3.0 > drives have been fine. > The overheating only happens with Linux 4.15.0-29 (the default Kubuntu 18.04 > kernel), it's fine when transferring files in Windows (tried with 8.1). > The overheating happens even when files aren't transferring, even when the > drive is idle. Please try enabling autosuspend for this device. Power management for storage devices is by default off because some devices with removable media fail horribly with it. If this helps we could try to get a rule for such drives into udev. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Mon, Aug 6, 2018 at 12:09 AM, Alan Stern wrote: > On Sat, 4 Aug 2018, Muni Sekhar wrote: > >> On Fri, Aug 3, 2018 at 1:15 AM, Alan Stern wrote: >> > On Thu, 2 Aug 2018, Muni Sekhar wrote: >> > >> >> I see that CONFIG_PM_RUNTIME & CONFIG_USB_SUSPEND are not enabled. Is >> >> that fine? >> > >> > The CONFIG_PM_RUNTIME and CONFIG_USB_SUSPEND symbols are no longer >> > used. >> > >> >> The device is using btusb driver. Does unloading the driver helps? >> > >> > It should. >> > >> >> I ran ‘lsof’ and and I see that the USB device was being held open by >> >> fwupd, not sure what is ‘fwupd’? >> > >> > It is a firmware update daemon. >> > >> >> # sudo lsof +D /dev/bus/usb >> >> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system >> >> /run/user/1000/gvfs >> >> Output information may be incomplete. >> >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> >> fwupd 1631 root 49u CHR 189,67 0t0 547 /dev/bus/usb/001/068 >> >> >> >> >> >> So I killed that process(fwupd), but still device is not going to SUSPEND >> >> mode. >> >> >> >> # sudo lsof +D /dev/bus/usb >> >> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system >> >> /run/user/1000/gvfs >> >> Output information may be incomplete. >> >> >> >> >> >> # cat /sys/bus/usb/devices/1-1.3/power/runtime_status >> >> active >> > >> > Well, keeping the device might or might not prevent it from being >> > suspended. It all depends on how the driver is written. But if you >> > unload the driver then the device certainly ought to go into runtime >> > suspend. >> Unloading the driver and killing the 'fwupd' daemon resulted that >> device to go into runtime suspend. Here I noticed that both the >> operations(i.e. rmmod btusb & kill -9 ) are mandatory to >> device to go into runtime suspend. I'd like to understand how the >> driver & daemon are preventing the device to go into suspend mode, can >> you please explain me on this? > > I do not know the details, and I am completely unfamiliar with both > btusb and fwupd (and the entire Bluetooth subsystem, for that matter). > So all I can do is give a general explanation. > > When a program like fwupd holds a device open, normally it also > prevents the driver from being unloaded. Is it really possible to > rmmod btusb without first killing fwupd? Thank you very much for this clarification Alan. Yes it is possible to rmmod btusb without first killing fwupd. # lsmod | grep btusb btusb 45056 0 btrtl 16384 1 btusb btbcm 16384 1 btusb btintel16384 1 btusb bluetooth 520192 10 bnep,btbcm,btrtl,btusb,btintel # ps -ax | grep fwupd 1900 ?Sl 0:00 /usr/lib/x86_64-linux-gnu/fwupd/fwupd 3806 pts/2S+ 0:00 grep --color=auto fwupd # modprobe -r btusb # ps -ax | grep fwupd 1900 ?Sl 0:00 /usr/lib/x86_64-linux-gnu/fwupd/fwupd 3819 pts/2S+ 0:00 grep --color=auto fwupd # lsmod | grep btusb > > In any case, when a driver uses a device, it tells the runtime PM core > that it needs the device to be at full power. This will prevent the > device from going into runtime suspend (and will wake it up if it is > already suspended). When the driver is finished using the device, it > tells the runtime PM core that the device may be suspended again. > > The question now becomes: when do these messages to the runtime PM core > get sent? Some drivers send them when the device is opened and closed; > some drivers send them when a command is issued to the device and when > the reply is received, and some drivers send them only when they are > loaded and unloaded. I don't know how btusb behaves. > > Alan Stern > -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Sa, 2018-08-04 at 23:10 +0530, Muni Sekhar wrote: > > Unloading the driver and killing the 'fwupd' daemon resulted that > device to go into runtime suspend. Here I noticed that both the > operations(i.e. rmmod btusb & kill -9 ) are mandatory to > device to go into runtime suspend. I'd like to understand how the > driver & daemon are preventing the device to go into suspend mode, can > you please explain me on this? Hi, btusb has support for autosuspend. 1. Please check whether your device supports remote wake up and isn't quirky 2. Try a 'hciconfig hciX down' (with X for your number HTH Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dynamic suspend
On Mon, Aug 6, 2018 at 2:59 PM, Oliver Neukum wrote: > On Sa, 2018-08-04 at 23:10 +0530, Muni Sekhar wrote: >> >> Unloading the driver and killing the 'fwupd' daemon resulted that >> device to go into runtime suspend. Here I noticed that both the >> operations(i.e. rmmod btusb & kill -9 ) are mandatory to >> device to go into runtime suspend. I'd like to understand how the >> driver & daemon are preventing the device to go into suspend mode, can >> you please explain me on this? > > Hi, > > btusb has support for autosuspend. > > 1. Please check whether your device supports remote wake up and isn't > quirky Right now my device does not support remote wakeup, need firmware support for this. Once I receive the firmware then i'll give a try. > 2. Try a 'hciconfig hciX down' (with X for your number > > HTH > Oliver > -- Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wrong device idProduct?
On Mon, Jul 30, 2018 at 1:24 PM Alan Stern wrote: > > On Mon, 30 Jul 2018, Nick Desaulniers wrote: > > > Hello, > > Today my usb keyboard stopped working: > > > > [513672.838235] usbhid 3-10.1:1.0: couldn't find an input interrupt endpoint > > > > I happen to have two models of the same keyboard (Das Keyboard > > Ultimate 4C), from the working one: > > [ 37.865738] usb 1-1.1: New USB device found, idVendor=24f0, > > idProduct=0142 > > and the broken one: > > [513672.837646] usb 3-10.1: New USB device found, idVendor=24f0, > > idProduct= > > > > This causes the product to be misidentified. Is something wrong with > > the keyboard that's causing it to misreport the idProduct? > > Probably it lost some of its firmware. Is it possible to ask Linux to remount this device with a new idProduct? -- Thanks, ~Nick Desaulniers -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wrong device idProduct?
On Mon, 6 Aug 2018, Nick Desaulniers wrote: > On Mon, Jul 30, 2018 at 1:24 PM Alan Stern wrote: > > > > On Mon, 30 Jul 2018, Nick Desaulniers wrote: > > > > > Hello, > > > Today my usb keyboard stopped working: > > > > > > [513672.838235] usbhid 3-10.1:1.0: couldn't find an input interrupt > > > endpoint > > > > > > I happen to have two models of the same keyboard (Das Keyboard > > > Ultimate 4C), from the working one: > > > [ 37.865738] usb 1-1.1: New USB device found, idVendor=24f0, > > > idProduct=0142 > > > and the broken one: > > > [513672.837646] usb 3-10.1: New USB device found, idVendor=24f0, > > > idProduct= > > > > > > This causes the product to be misidentified. Is something wrong with > > > the keyboard that's causing it to misreport the idProduct? > > > > Probably it lost some of its firmware. > > Is it possible to ask Linux to remount this device with a new idProduct? It's not possible to change the idProduct value. It is possible to try to use the keyboard in spite of the wrong idProduct. In fact, that's what your computer tried to do. But it didn't work, as you can see from the "couldn't find an input interrupt endpoint" error message in the log Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wrong device idProduct?
On Mon, Aug 6, 2018 at 11:27 AM Alan Stern wrote: > > On Mon, 6 Aug 2018, Nick Desaulniers wrote: > > > On Mon, Jul 30, 2018 at 1:24 PM Alan Stern > > wrote: > > > > > > On Mon, 30 Jul 2018, Nick Desaulniers wrote: > > > > > > > Hello, > > > > Today my usb keyboard stopped working: > > > > > > > > [513672.838235] usbhid 3-10.1:1.0: couldn't find an input interrupt > > > > endpoint > > > > > > > > I happen to have two models of the same keyboard (Das Keyboard > > > > Ultimate 4C), from the working one: > > > > [ 37.865738] usb 1-1.1: New USB device found, idVendor=24f0, > > > > idProduct=0142 > > > > and the broken one: > > > > [513672.837646] usb 3-10.1: New USB device found, idVendor=24f0, > > > > idProduct= > > > > > > > > This causes the product to be misidentified. Is something wrong with > > > > the keyboard that's causing it to misreport the idProduct? > > > > > > Probably it lost some of its firmware. > > > > Is it possible to ask Linux to remount this device with a new idProduct? > > It's not possible to change the idProduct value. > > It is possible to try to use the keyboard in spite of the wrong > idProduct. In fact, that's what your computer tried to do. But it > didn't work, as you can see from the "couldn't find an input interrupt > endpoint" error message in the log There's nothing for handling quirks? Surely not all devices are so well behaved. Worst case I guess I could modify whatever maps idProducts to drivers in *my* kernel and use that? -- Thanks, ~Nick Desaulniers -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wrong device idProduct?
On Mon, Aug 06, 2018 at 11:31:11AM -0700, Nick Desaulniers wrote: > On Mon, Aug 6, 2018 at 11:27 AM Alan Stern wrote: > > > > On Mon, 6 Aug 2018, Nick Desaulniers wrote: > > > > > On Mon, Jul 30, 2018 at 1:24 PM Alan Stern > > > wrote: > > > > > > > > On Mon, 30 Jul 2018, Nick Desaulniers wrote: > > > > > > > > > Hello, > > > > > Today my usb keyboard stopped working: > > > > > > > > > > [513672.838235] usbhid 3-10.1:1.0: couldn't find an input interrupt > > > > > endpoint > > > > > > > > > > I happen to have two models of the same keyboard (Das Keyboard > > > > > Ultimate 4C), from the working one: > > > > > [ 37.865738] usb 1-1.1: New USB device found, idVendor=24f0, > > > > > idProduct=0142 > > > > > and the broken one: > > > > > [513672.837646] usb 3-10.1: New USB device found, idVendor=24f0, > > > > > idProduct= > > > > > > > > > > This causes the product to be misidentified. Is something wrong with > > > > > the keyboard that's causing it to misreport the idProduct? > > > > > > > > Probably it lost some of its firmware. > > > > > > Is it possible to ask Linux to remount this device with a new idProduct? > > > > It's not possible to change the idProduct value. > > > > It is possible to try to use the keyboard in spite of the wrong > > idProduct. In fact, that's what your computer tried to do. But it > > didn't work, as you can see from the "couldn't find an input interrupt > > endpoint" error message in the log > > There's nothing for handling quirks? Surely not all devices are so > well behaved. Worst case I guess I could modify whatever maps > idProducts to drivers in *my* kernel and use that? No, your firmware is really broken and it is not responding with a full USB descriptor, it is messed up, there's nothing that any operating system can do about it, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wrong device idProduct?
On Mon, 6 Aug 2018, Nick Desaulniers wrote: > On Mon, Aug 6, 2018 at 11:27 AM Alan Stern wrote: > > > > On Mon, 6 Aug 2018, Nick Desaulniers wrote: > > > > > On Mon, Jul 30, 2018 at 1:24 PM Alan Stern > > > wrote: > > > > > > > > On Mon, 30 Jul 2018, Nick Desaulniers wrote: > > > > > > > > > Hello, > > > > > Today my usb keyboard stopped working: > > > > > > > > > > [513672.838235] usbhid 3-10.1:1.0: couldn't find an input interrupt > > > > > endpoint > > > > > > > > > > I happen to have two models of the same keyboard (Das Keyboard > > > > > Ultimate 4C), from the working one: > > > > > [ 37.865738] usb 1-1.1: New USB device found, idVendor=24f0, > > > > > idProduct=0142 > > > > > and the broken one: > > > > > [513672.837646] usb 3-10.1: New USB device found, idVendor=24f0, > > > > > idProduct= > > > > > > > > > > This causes the product to be misidentified. Is something wrong with > > > > > the keyboard that's causing it to misreport the idProduct? > > > > > > > > Probably it lost some of its firmware. > > > > > > Is it possible to ask Linux to remount this device with a new idProduct? > > > > It's not possible to change the idProduct value. > > > > It is possible to try to use the keyboard in spite of the wrong > > idProduct. In fact, that's what your computer tried to do. But it > > didn't work, as you can see from the "couldn't find an input interrupt > > endpoint" error message in the log > > There's nothing for handling quirks? Surely not all devices are so > well behaved. Worst case I guess I could modify whatever maps > idProducts to drivers in *my* kernel and use that? No quirk will fix a broken device. Every HID (Human Interface Device, such as keyboards) device is required to have an interrupt endpoint. Without that, there's no way for the computer to use it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wrong device idProduct?
Ok, thanks for taking a look. On Mon, Aug 6, 2018 at 12:18 PM Alan Stern wrote: > > On Mon, 6 Aug 2018, Nick Desaulniers wrote: > > > On Mon, Aug 6, 2018 at 11:27 AM Alan Stern > > wrote: > > > > > > On Mon, 6 Aug 2018, Nick Desaulniers wrote: > > > > > > > On Mon, Jul 30, 2018 at 1:24 PM Alan Stern > > > > wrote: > > > > > > > > > > On Mon, 30 Jul 2018, Nick Desaulniers wrote: > > > > > > > > > > > Hello, > > > > > > Today my usb keyboard stopped working: > > > > > > > > > > > > [513672.838235] usbhid 3-10.1:1.0: couldn't find an input interrupt > > > > > > endpoint > > > > > > > > > > > > I happen to have two models of the same keyboard (Das Keyboard > > > > > > Ultimate 4C), from the working one: > > > > > > [ 37.865738] usb 1-1.1: New USB device found, idVendor=24f0, > > > > > > idProduct=0142 > > > > > > and the broken one: > > > > > > [513672.837646] usb 3-10.1: New USB device found, idVendor=24f0, > > > > > > idProduct= > > > > > > > > > > > > This causes the product to be misidentified. Is something wrong > > > > > > with > > > > > > the keyboard that's causing it to misreport the idProduct? > > > > > > > > > > Probably it lost some of its firmware. > > > > > > > > Is it possible to ask Linux to remount this device with a new idProduct? > > > > > > It's not possible to change the idProduct value. > > > > > > It is possible to try to use the keyboard in spite of the wrong > > > idProduct. In fact, that's what your computer tried to do. But it > > > didn't work, as you can see from the "couldn't find an input interrupt > > > endpoint" error message in the log > > > > There's nothing for handling quirks? Surely not all devices are so > > well behaved. Worst case I guess I could modify whatever maps > > idProducts to drivers in *my* kernel and use that? > > No quirk will fix a broken device. Every HID (Human Interface Device, > such as keyboards) device is required to have an interrupt endpoint. > Without that, there's no way for the computer to use it. > > Alan Stern > > -- Thanks, ~Nick Desaulniers -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
