Re: linux-3.7.1: kmemleak reports in comm usb-storage?
On Wed, 16 Jan 2013, Martin Mokrejs wrote: A corresponding diff of dmesg output is attached. Note that the first kmemleak in there happened just without any prior fiddling with a USB drive. For about two days I haven't connected a drive. However, usb-storage might be in a wrong shape since several days when it happened for the first time. Did you want me to reboot? ;-) I did not. Sarah, I looked through the xhci-hcd driver. There does appear to be a leak in xhci-ring.c:handle_tx_event(). The routine looks like this: /* Leave the TD around for the reset endpoint function * to use(but only if it's not a control endpoint, * since we already queued the Set TR dequeue pointer * command for stalled control endpoints). */ if (usb_endpoint_xfer_control(urb-ep-desc) || (trb_comp_code != COMP_STALL trb_comp_code != COMP_BABBLE)) xhci_urb_free_priv(xhci, urb_priv); ... /* EHCI, UHCI, and OHCI always unconditionally set the * urb-status of an isochronous endpoint to 0. */ if (usb_pipetype(urb-pipe) == PIPE_ISOCHRONOUS) status = 0; usb_hcd_giveback_urb(bus_to_hcd(urb-dev-bus), urb, status); If the condition on the first if statement fails, urb_priv won't be deallocated. It needs something like if (...) xhci_urb_free_priv(xhci, urb_priv); + else + kfree(urb_priv); Martin, can you tell if adding these two lines fixes the problem? Also, the comment is wrong. urb-status is not set to 0 unconditionally for isochonrous endpoints in [eou]hcd-hcd. If any of the iso packets gets a nonzero status then urb-status is set to one of those values, not to 0. 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: linux-3.7.1: kmemleak reports in comm usb-storage?
On Wed, 16 Jan 2013, Sarah Sharp wrote: Sarah, I looked through the xhci-hcd driver. There does appear to be a leak in xhci-ring.c:handle_tx_event(). Thanks for catching that. The routine looks like this: /* Leave the TD around for the reset endpoint function * to use(but only if it's not a control endpoint, * since we already queued the Set TR dequeue pointer * command for stalled control endpoints). */ if (usb_endpoint_xfer_control(urb-ep-desc) || (trb_comp_code != COMP_STALL trb_comp_code != COMP_BABBLE)) xhci_urb_free_priv(xhci, urb_priv); ... /* EHCI, UHCI, and OHCI always unconditionally set the * urb-status of an isochronous endpoint to 0. */ if (usb_pipetype(urb-pipe) == PIPE_ISOCHRONOUS) status = 0; usb_hcd_giveback_urb(bus_to_hcd(urb-dev-bus), urb, status); If the condition on the first if statement fails, urb_priv won't be deallocated. It needs something like if (...) xhci_urb_free_priv(xhci, urb_priv); + else + kfree(urb_priv); Ok, so you're proposing freeing the urb_priv, but leaving the TD allocated for the Set TR dequeue functions to use? Yes, that looks like the right solution, feel free to submit a patch. Okay, if Martin confirms the diagnosis. Martin, can you tell if adding these two lines fixes the problem? Also, the comment is wrong. urb-status is not set to 0 unconditionally for isochonrous endpoints in [eou]hcd-hcd. If any of the iso packets gets a nonzero status then urb-status is set to one of those values, not to 0. My mistake -- these drivers _do_ return 0 status for all isochronous URBs. However, ehci-hcd and uhci-hcd set urb-error_count to the number of packets getting an error, whereas ohci-hcd and xhci-hcd don't. Fixing ohci-hcd will be very easy. 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: linux-3.7.1: kmemleak reports in comm usb-storage?
Sarah Sharp wrote: On Wed, Jan 16, 2013 at 12:22:59PM -0500, Alan Stern wrote: On Wed, 16 Jan 2013, Martin Mokrejs wrote: A corresponding diff of dmesg output is attached. Note that the first kmemleak in there happened just without any prior fiddling with a USB drive. For about two days I haven't connected a drive. However, usb-storage might be in a wrong shape since several days when it happened for the first time. Did you want me to reboot? ;-) I did not. Sarah, I looked through the xhci-hcd driver. There does appear to be a leak in xhci-ring.c:handle_tx_event(). Thanks for catching that. The routine looks like this: /* Leave the TD around for the reset endpoint function * to use(but only if it's not a control endpoint, * since we already queued the Set TR dequeue pointer * command for stalled control endpoints). */ if (usb_endpoint_xfer_control(urb-ep-desc) || (trb_comp_code != COMP_STALL trb_comp_code != COMP_BABBLE)) xhci_urb_free_priv(xhci, urb_priv); ... /* EHCI, UHCI, and OHCI always unconditionally set the * urb-status of an isochronous endpoint to 0. */ if (usb_pipetype(urb-pipe) == PIPE_ISOCHRONOUS) status = 0; usb_hcd_giveback_urb(bus_to_hcd(urb-dev-bus), urb, status); If the condition on the first if statement fails, urb_priv won't be deallocated. It needs something like if (...) xhci_urb_free_priv(xhci, urb_priv); +else +kfree(urb_priv); Ok, so you're proposing freeing the urb_priv, but leaving the TD allocated for the Set TR dequeue functions to use? Yes, that looks like the right solution, feel free to submit a patch. Martin, can you tell if adding these two lines fixes the problem? Hi Alan, yes, the following change has helped. I managed to get twice the error -71 message (one case is shown here) Jan 16 23:07:56 vostro kernel: usb 3-1.2: Device not responding to set address. Jan 16 23:07:56 vostro kernel: usb 3-1.2: Device not responding to set address. Jan 16 23:07:56 vostro kernel: usb 3-1.2: device not accepting address 17, error -71 Jan 16 23:07:56 vostro kernel: hub 3-1:1.0: unable to enumerate USB device on port 2 but the kmemleak did not report anything after next unplug of the disk anymore. --- linux-3.7.1/drivers/usb/host/xhci-ring.c.ori2013-01-16 22:51:25.0 +0100 +++ linux-3.7.1/drivers/usb/host/xhci-ring.c2013-01-16 22:53:03.0 +0100 @@ -2580,6 +2580,8 @@ (trb_comp_code != COMP_STALL trb_comp_code != COMP_BABBLE)) xhci_urb_free_priv(xhci, urb_priv); + else + kfree(urb_priv); usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb-dev-bus), urb); if ((urb-actual_length != urb-transfer_buffer_length Thanks, Martin P.S.: The other kmemleak is still in there but is probably not your business: ;-) # cat /sys/kernel/debug/kmemleak unreferenced object 0x88040b60a578 (size 256): comm swapper/0, pid 1, jiffies 4294937575 (age 688.030s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .N.. ff ff ff ff ff ff ff ff 38 3f 5d 82 ff ff ff ff 8?]. backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [81302bd5] kzalloc.constprop.14+0xe/0x10 [81303036] device_private_init+0x14/0x63 [81305110] dev_set_drvdata+0x19/0x2f [815c1ed4] i801_probe+0x5e/0x451 [81280fb3] local_pci_probe+0x5b/0xa2 [81282074] pci_device_probe+0xc8/0xf7 [813056cd] driver_probe_device+0xa9/0x1c1 [8130583f] __driver_attach+0x5a/0x7e [81303f7a] bus_for_each_dev+0x57/0x83 [81305276] driver_attach+0x19/0x1b [81304e48] bus_add_driver+0xa8/0x1fa [81305cb1] driver_register+0x8c/0x106 [81281c6d] __pci_register_driver+0x5a/0x5e -- 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: linux-3.7.1: kmemleak reports in comm usb-storage?
Alan Stern wrote: On Sun, 13 Jan 2013, Martin Mokrejs wrote: Don't worry about what kmemleak says when the drives are plugged in. See what it says when all the USB drives are unplugged. That's what matters. Now it is the only one drive connected. If I disconnect it kmemleak won't change like it did not today for many hours when all the drives were unplugged. I thought you want me to plug it in back and unplug several times. ;) I did want you to plug it in and unplug it several times. But pay attention only to what kmemleak says when the drive is unplugged. I did not retry yet but I got the same kmemleak reported again. And, after quitting my seamonkey I realized system is uncovering another kmemleak. So, I am, attaching a diff to a previous stage. I can assure you that those new lines are not related to any new USB device being plugged in or out meanwhile. So, did I answer your question now? I can't tell. I don't really understand what you are doing. I think you wanted to say: cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.0 # plugin USB drive cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.1 # unplug the drive cp -p /sys/kernel/debug/kmemleak /tmp/kmemleak.2 And if kmemleak.1 and kmemleak.2 differ then report, otherwise not. I haven't realized the kmemleak being different when the drive was just plugged in, the new items always popped up just after unplug. My uncertainty was whether there is some delay in updating the file, and whether I can be sure it is up-to-date, always. I think those new items attached show yet another system path so I hope it will help you. Those about tty could be related to the fact that i tried to do # less /sys/kernel/debug/kmemleak and it somehow blocked. cancel;ling that and using cat command was not much helpful. After some seconds it got through and gave me the output but less would have probably succeeded as well. Please let me know whether I should report the kmemleaks elsewhere. Martin --- /tmp/kmemleak 2013-01-12 19:34:43.0 +0100 +++ /sys/kernel/debug/kmemleak 2013-01-09 21:19:19.800324883 +0100 @@ -1,5 +1,5 @@ unreferenced object 0x88040b1c5230 (size 256): - comm swapper/0, pid 1, jiffies 4294937570 (age 256523.410s) + comm swapper/0, pid 1, jiffies 4294937570 (age 540111.170s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .N.. ff ff ff ff ff ff ff ff 38 3f 5d 82 ff ff ff ff 8?]. @@ -21,7 +21,7 @@ [81305cb1] driver_register+0x8c/0x106 [81281c6d] __pci_register_driver+0x5a/0x5e unreferenced object 0x88034b2fe578 (size 16): - comm usb-storage, pid 5508, jiffies 4302958885 (age 176310.350s) + comm usb-storage, pid 5508, jiffies 4302958885 (age 459898.040s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: @@ -42,7 +42,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fee10 (size 16): - comm usb-storage, pid 5508, jiffies 4302958885 (age 176310.350s) + comm usb-storage, pid 5508, jiffies 4302958885 (age 459898.040s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: @@ -63,7 +63,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe488 (size 16): - comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s) + comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.040s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: @@ -84,7 +84,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe528 (size 16): - comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s) + comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff ..m. backtrace: @@ -105,7 +105,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe4b0 (size 16): - comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.360s) + comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff ..m. backtrace: @@ -126,7 +126,7 @@ [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe460 (size 16): - comm usb-storage, pid 5508, jiffies 4302958886 (age 176310.380s) + comm usb-storage, pid 5508, jiffies 4302958886 (age 459898.060s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 c8 1e 6d d2 03 88 ff ff ..m. backtrace: @@ -147,7 +147,7
Re: linux-3.7.1: kmemleak reports in comm usb-storage?
Martin Mokrejs wrote: Alan Stern wrote: On Sun, 13 Jan 2013, Martin Mokrejs wrote: Don't worry about what kmemleak says when the drives are plugged in. See what it says when all the USB drives are unplugged. That's what matters. Now it is the only one drive connected. If I disconnect it kmemleak won't change like it did not today for many hours when all the drives were unplugged. I thought you want me to plug it in back and unplug several times. ;) I did want you to plug it in and unplug it several times. But pay attention only to what kmemleak says when the drive is unplugged. I did not retry yet but I got the same kmemleak reported again. And, after quitting my seamonkey I realized system is uncovering another kmemleak. So, I am, attaching a diff to a previous stage. I can assure you that those new lines are not related to any new USB device being plugged in or out meanwhile. A corresponding diff of dmesg output is attached. Note that the first kmemleak in there happened just without any prior fiddling with a USB drive. For about two days I haven't connected a drive. However, usb-storage might be in a wrong shape since several days when it happened for the first time. Did you want me to reboot? ;-) I did not. Martin --- /tmp/dmesg.new 2013-01-12 20:18:14.0 +0100 +++ /tmp/dmesg.22013-01-16 02:33:34.0 +0100 @@ -1933,3 +1933,100 @@ [257099.029790] hub 3-1:1.0: port 1, status 0100, change 0001, 12 Mb/s [257099.181584] hub 3-1:1.0: debounce: port 1: total 100ms stable 100ms status 0x100 [257855.985369] kmemleak: 14 new suspected memory leaks (see /sys/kernel/debug/kmemleak) +[267293.258370] usb usb2: usb auto-resume +[267293.258376] ehci_hcd :00:1d.0: resume root hub +[267293.295290] hub 2-0:1.0: hub_resume +[267293.295328] hub 2-0:1.0: port 1: status 0507 change +[267293.295422] usb 2-1: usb auto-resume +[267293.296110] hub 2-0:1.0: state 7 ports 2 chg evt +[267293.335231] ehci_hcd :00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT +[267293.355095] usb 2-1: finish resume +[267293.355346] hub 2-1:1.0: hub_resume +[267293.356336] ehci_hcd :00:1d.0: reused qh 88040aceac78 schedule +[267293.356339] usb 2-1: link qh256-0001/88040aceac78 start 1 [1/0 us] +[267293.356967] hub 2-1:1.0: state 7 ports 8 chg evt +[267295.711589] hub 2-1:1.0: hub_suspend +[267295.711597] usb 2-1: unlink qh256-0001/88040aceac78 start 1 [1/0 us] +[267295.732900] usb 2-1: usb auto-suspend, wakeup 1 +[267297.748460] hub 2-0:1.0: hub_suspend +[267297.748470] usb usb2: bus auto-suspend, wakeup 1 +[267297.748472] ehci_hcd :00:1d.0: suspend root hub +[267310.610920] usb usb2: usb auto-resume +[267310.610925] ehci_hcd :00:1d.0: resume root hub +[267310.649159] hub 2-0:1.0: hub_resume +[267310.649199] hub 2-0:1.0: port 1: status 0507 change +[267310.649278] usb 2-1: usb auto-resume +[267310.650700] hub 2-0:1.0: state 7 ports 2 chg evt +[267310.689142] ehci_hcd :00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT +[267310.709046] usb 2-1: finish resume +[267310.709247] hub 2-1:1.0: hub_resume +[267310.710248] ehci_hcd :00:1d.0: reused qh 88040aceac78 schedule +[267310.710250] usb 2-1: link qh256-0001/88040aceac78 start 1 [1/0 us] +[267310.710270] hub 2-1:1.0: state 7 ports 8 chg evt +[267312.706389] hub 2-1:1.0: hub_suspend +[267312.706398] usb 2-1: unlink qh256-0001/88040aceac78 start 1 [1/0 us] +[267312.726266] usb 2-1: usb auto-suspend, wakeup 1 +[267314.742955] hub 2-0:1.0: hub_suspend +[267314.742964] usb usb2: bus auto-suspend, wakeup 1 +[267314.742966] ehci_hcd :00:1d.0: suspend root hub +[270107.716006] [sched_delayed] sched: RT throttling activated +[272687.284828] traps: python2.7[23538] general protection ip:7fe8be5a5f08 sp:7fff3c479b10 error:0 in libpython2.7.so.1.0[7fe8be495000+173000] +[273262.853094] hub 4-1:1.0: state 7 ports 4 chg evt 0002 +[273262.878070] hub 4-1:1.0: port 1, status 02a0, change 0041, 5.0 Gb/s +[273262.878075] usb 4-1.1: USB disconnect, device number 6 +[273262.878077] usb 4-1.1: unregistering device +[273262.878078] usb 4-1.1: unregistering interface 4-1.1:1.0 +[273262.884593] usb 4-1.1: usb_disable_device nuking all URBs +[273262.884653] usb 4-1.1: Successful Endpoint Configure command +[273263.056046] hub 4-1:1.0: debounce: port 1: total 100ms stable 100ms status 0x2a0 +[273263.056062] usb 4-1: remote wakeup needed for autosuspend +[277337.650821] kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) +[279422.737427] r8169 :05:00.0 eth0: link down +[306258.609520] r8169 :05:00.0 eth0: link up +[306276.021745] r8169 :05:00.0 eth0: link down +[306303.361392] r8169 :05:00.0 eth0: link up +[306310.846349] r8169 :05:00.0 eth0: link down +[306313.082271] r8169 :05:00.0 eth0: link up +[311084.323583] r8169 :05:00.0 eth0: link down +[311084.323593]
Re: linux-3.7.1: kmemleak reports in comm usb-storage?
On Sun, 13 Jan 2013, Martin Mokrejs wrote: Don't worry about what kmemleak says when the drives are plugged in. See what it says when all the USB drives are unplugged. That's what matters. Now it is the only one drive connected. If I disconnect it kmemleak won't change like it did not today for many hours when all the drives were unplugged. I thought you want me to plug it in back and unplug several times. ;) I did want you to plug it in and unplug it several times. But pay attention only to what kmemleak says when the drive is unplugged. So, did I answer your question now? I can't tell. I don't really understand what you are doing. 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: linux-3.7.1: kmemleak reports in comm usb-storage?
On Sat, 12 Jan 2013, Martin Mokrejs wrote: Alan Stern wrote: On Fri, 11 Jan 2013, Martin Mokrejs wrote: Hi, I am not sure how should I interpret this but I am attaching the whole kmemleak file I have after # w 23:02:23 up 2 days, 2:43, 16 users, load average: 2.17, 1.85, 1.51 [cut] I have several SATA drives connected over USB 2 and 3 (and mounted) but am not accessing them. Whether or not the drives are being accessed probably doesn't matter much. The mere fact that they are connected can make a difference. Does kmemleak report the same problems after the drives are unplugged? Does the number of leaked memory regions increase if you plug in and unplug a drive repeatedly? I just plugged in one drive, unconnected, a re-connected back again. Right after that the kmemleak file did not show any changes but that is probably updated by a background process? But, after some minutes, here the are few more! I am attaching the diff showing the timestamps. Please note that the number increased once while do physical (dis)connections happened meanwhile (unless that can be explained by the time lag of the background scanning before it reports the problem): [81036.084077] kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [139512.014429] kmemleak: 11 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Don't worry about what kmemleak says when the drives are plugged in. See what it says when all the USB drives are unplugged. That's what matters. 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: linux-3.7.1: kmemleak reports in comm usb-storage?
Alan Stern wrote: On Sat, 12 Jan 2013, Martin Mokrejs wrote: Alan Stern wrote: On Fri, 11 Jan 2013, Martin Mokrejs wrote: Hi, I am not sure how should I interpret this but I am attaching the whole kmemleak file I have after # w 23:02:23 up 2 days, 2:43, 16 users, load average: 2.17, 1.85, 1.51 [cut] I have several SATA drives connected over USB 2 and 3 (and mounted) but am not accessing them. Whether or not the drives are being accessed probably doesn't matter much. The mere fact that they are connected can make a difference. Does kmemleak report the same problems after the drives are unplugged? Does the number of leaked memory regions increase if you plug in and unplug a drive repeatedly? I just plugged in one drive, unconnected, a re-connected back again. Right after that the kmemleak file did not show any changes but that is probably updated by a background process? But, after some minutes, here the are few more! I am attaching the diff showing the timestamps. Please note that the number increased once while do physical (dis)connections happened meanwhile (unless that can be explained by the time lag of the background scanning before it reports the problem): [81036.084077] kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [139512.014429] kmemleak: 11 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Don't worry about what kmemleak says when the drives are plugged in. See what it says when all the USB drives are unplugged. That's what matters. Now it is the only one drive connected. If I disconnect it kmemleak won't change like it did not today for many hours when all the drives were unplugged. I thought you want me to plug it in back and unplug several times. ;) So, did I answer your question now? M. -- 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
linux-3.7.1: kmemleak reports in comm usb-storage?
Hi, I am not sure how should I interpret this but I am attaching the whole kmemleak file I have after # w 23:02:23 up 2 days, 2:43, 16 users, load average: 2.17, 1.85, 1.51 [cut] I have several SATA drives connected over USB 2 and 3 (and mounted) but am not accessing them. Maybe there is even a way to check whether the ext3/4 filesystem was modified since the mount time? Maybe it does not matter to you anyways. Picking just one of the reports, the whole file is attached to this email. unreferenced object 0x8803d9328528 (size 16): comm usb-storage, pid 5611, jiffies 4302959774 (age 102275.730s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 80 75 2c 5f 03 88 ff ff .u,_ backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [8138f418] kzalloc+0xf/0x11 [81391c6c] xhci_urb_enqueue+0xc1/0x3af [81373d82] usb_hcd_submit_urb+0x60b/0x6d2 [81374bf7] usb_submit_urb+0x3dd/0x3f3 [8139cb64] usb_stor_msg_common+0xb0/0x144 [8139ceb6] usb_stor_bulk_transfer_buf+0x57/0x99 [8139d224] usb_stor_Bulk_transport+0x151/0x2a0 [8139da01] usb_stor_invoke_transport+0x162/0x455 [8139ca29] usb_stor_transparent_scsi_command+0x9/0xb [8139eb62] usb_stor_control_thread+0x151/0x233 [8108fde6] kthread+0xac/0xb4 [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x Please let me know if you need more info, like lsusb or whatever. Martin unreferenced object 0x88040b1c5230 (size 256): comm swapper/0, pid 1, jiffies 4294937570 (age 182492.630s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .N.. ff ff ff ff ff ff ff ff 38 3f 5d 82 ff ff ff ff 8?]. backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [81302bd5] kzalloc.constprop.14+0xe/0x10 [81303036] device_private_init+0x14/0x63 [81305110] dev_set_drvdata+0x19/0x2f [815c1ed4] i801_probe+0x5e/0x451 [81280fb3] local_pci_probe+0x5b/0xa2 [81282074] pci_device_probe+0xc8/0xf7 [813056cd] driver_probe_device+0xa9/0x1c1 [8130583f] __driver_attach+0x5a/0x7e [81303f7a] bus_for_each_dev+0x57/0x83 [81305276] driver_attach+0x19/0x1b [81304e48] bus_add_driver+0xa8/0x1fa [81305cb1] driver_register+0x8c/0x106 [81281c6d] __pci_register_driver+0x5a/0x5e unreferenced object 0x88034b2fe578 (size 16): comm usb-storage, pid 5508, jiffies 4302958885 (age 102279.640s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [8138f418] kzalloc+0xf/0x11 [81391c6c] xhci_urb_enqueue+0xc1/0x3af [81373d82] usb_hcd_submit_urb+0x60b/0x6d2 [81374bf7] usb_submit_urb+0x3dd/0x3f3 [8139cb64] usb_stor_msg_common+0xb0/0x144 [8139ceb6] usb_stor_bulk_transfer_buf+0x57/0x99 [8139d224] usb_stor_Bulk_transport+0x151/0x2a0 [8139d8d5] usb_stor_invoke_transport+0x36/0x455 [8139ca29] usb_stor_transparent_scsi_command+0x9/0xb [8139eb62] usb_stor_control_thread+0x151/0x233 [8108fde6] kthread+0xac/0xb4 [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fee10 (size 16): comm usb-storage, pid 5508, jiffies 4302958885 (age 102279.640s) hex dump (first 16 bytes): 01 00 00 00 01 00 00 00 58 1b 6d d2 03 88 ff ff X.m. backtrace: [815b1dbd] kmemleak_alloc+0x21/0x3e [81110536] slab_post_alloc_hook+0x28/0x2a [81112a6e] __kmalloc+0xf2/0x104 [8138f418] kzalloc+0xf/0x11 [81391c6c] xhci_urb_enqueue+0xc1/0x3af [81373d82] usb_hcd_submit_urb+0x60b/0x6d2 [81374bf7] usb_submit_urb+0x3dd/0x3f3 [8139cb64] usb_stor_msg_common+0xb0/0x144 [8139ceb6] usb_stor_bulk_transfer_buf+0x57/0x99 [8139d224] usb_stor_Bulk_transport+0x151/0x2a0 [8139d8d5] usb_stor_invoke_transport+0x36/0x455 [8139ca29] usb_stor_transparent_scsi_command+0x9/0xb [8139eb62] usb_stor_control_thread+0x151/0x233 [8108fde6] kthread+0xac/0xb4 [815da6ac] ret_from_fork+0x7c/0xb0 [] 0x unreferenced object 0x88034b2fe488 (size 16): comm usb-storage, pid 5508, jiffies 4302958886 (age 102279.660s) hex dump (first 16 bytes): 01 00
