Linux-USB Archive on lore.kernel.org
 help / color / Atom feed
* reeze while write on external usb 3.0 hard disk [Bug 204095]
@ 2019-08-17  9:54 Piergiorgio Sartor
  2019-08-19 14:14 ` Alan Stern
  0 siblings, 1 reply; 6+ messages in thread
From: Piergiorgio Sartor @ 2019-08-17  9:54 UTC (permalink / raw)
  To: linux-usb

Hi all,

bug 204095 from bugzilla.kernel.org was closed,
but apparently something is left unfixed.

Ref.: https://bugzilla.kernel.org/show_bug.cgi?id=204095

Below the two last entries I did about the topic:

--- --- ---

I've Fedora 30 and there was an update, from kernel 5.1.20
to 5.2.5, and now I've the logs full of:

ehci-pci 0000:00:13.2: swiotlb buffer is full (sz: 327680 bytes), total 32768 (slots), used 97 (slots)

Or similarly:

ehci-pci 0000:00:13.2: swiotlb buffer is full (sz: 315392 bytes), total 32768 (slots), used 103 (slots)

This happens whenever I access an external USB3.0 drive
connected to a USB2.0 port, I'm not sure if this makes
any difference.

It is enough something like "hdparm -t /dev/sdX" to trigger
the above (and cause a lock-up of the command and 100% CPU
load for "usb-storage").
Nevertheless, it seems that the first access, likely few bytes
read, is successful since the device is recognize by the file
manager.
Anything else, (large) file copy causes the issue.

Could it be the same bug? That is the fix for 5.2.5 does not
fix it completely?

--- --- ---

Some more comments.

I tested a different PC, this does not show any problem, neither
with the "old" 5.1.20 nor with the new 5.2.5 kernel.

Second, the original PC still have problems, here below the log
output at the moment of the "crash" due to "hdparm -t /dev/sdX":

[   47.212609] xhci_hcd 0000:02:00.0: swiotlb buffer is full (sz: 421888 bytes), total 32768 (slots), used 1 (slots)
[   47.212620] xhci_hcd 0000:02:00.0: overflow 0x0000000383a19000+421888 of DMA mask ffffffff bus mask 0
[   47.212646] WARNING: CPU: 0 PID: 454 at kernel/dma/direct.c:43 report_addr+0x33/0x60
[   47.212649] Modules linked in: fuse cfg80211 rfkill nf_log_ipv4 nf_log_common ipt_REJECT nf_reject_ipv4 xt_state xt_conntrack xt_owner xt_LOG iptable_filter nf_conntrack_ftp xt_CT nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw hwmon_vid sunrpc dm_crypt dm_cache_smq nvidia_drm(POE) dm_cache nvidia_modeset(POE) dm_persistent_data dm_bio_prison libcrc32c nvidia_uvm(OE) amd64_edac_mod edac_mce_amd kvm_amd ccp kvm snd_hda_codec_hdmi irqbypass joydev crct10dif_pclmul nvidia(POE) crc32_pclmul ghash_clmulni_intel snd_hda_codec_via snd_hda_codec_generic ledtrig_audio snd_hda_intel drm_kms_helper wmi_bmof snd_hda_codec fam15h_power k10temp snd_hda_core sp5100_tco snd_hwdep i2c_piix4 snd_seq snd_seq_device drm snd_pcm snd_timer ipmi_devintf snd ipmi_msghandler asus_atk0110 soundcore pcc_cpufreq acpi_cpufreq vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc ip_tables firewire_sbp2 raid1 raid10 crc32c_intel firewire_ohci firewire_core serio_raw crc_itu_t r8169 wmi uas
[   47.212719]  usb_storage hid_logitech ff_memless ecryptfs
[   47.212734] CPU: 0 PID: 454 Comm: usb-storage Tainted: P           OE     5.2.6-200.fc30.x86_64 #1
[   47.212738] Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2101    12/02/2014
[   47.212744] RIP: 0010:report_addr+0x33/0x60
[   47.212750] Code: 48 8b 87 28 02 00 00 48 89 34 24 48 85 c0 74 2d 4c 8b 00 b8 fe ff ff ff 49 39 c0 76 14 80 3d a3 ae 41 01 00 0f 84 a9 06 00 00 <0f> 0b 48 83 c4 08 c3 48 83 bf 38 02 00 00 00 74 ef eb e0 80 3d 84
[   47.212754] RSP: 0018:ffffa85941bffbc8 EFLAGS: 00010246
[   47.212758] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000
[   47.212762] RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffff9a45af617900
[   47.212765] RBP: ffff9a45accc00b0 R08: ffffa85941bff92d R09: 00000000000003a3
[   47.212769] R10: ffffffffb6bece08 R11: ffffa85941bff92d R12: 0000000000067000
[   47.212772] R13: 0000000000000002 R14: 0000000000000000 R15: ffff9a45a40502b0
[   47.212777] FS:  0000000000000000(0000) GS:ffff9a45af600000(0000) knlGS:0000000000000000
[   47.212780] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   47.212784] CR2: 000055b215f34c50 CR3: 00000003d622e000 CR4: 00000000000406f0
[   47.212787] Call Trace:
[   47.212797]  dma_direct_map_page+0xdf/0xf0
[   47.212803]  dma_direct_map_sg+0x67/0xb0
[   47.212811]  usb_hcd_map_urb_for_dma+0x343/0x530
[   47.212817]  usb_hcd_submit_urb+0x9a/0xbb0
[   47.212824]  ? schedule_timeout+0x209/0x300
[   47.212829]  ? usb_hcd_submit_urb+0xbf/0xbb0
[   47.212835]  ? __switch_to_asm+0x40/0x70
[   47.212840]  ? __switch_to_asm+0x34/0x70
[   47.212845]  ? _cond_resched+0x15/0x30
[   47.212852]  ? __kmalloc+0x16c/0x210
[   47.212857]  ? _cond_resched+0x15/0x30
[   47.212863]  ? usb_alloc_urb+0x35/0x60
[   47.212867]  usb_sg_wait+0x7e/0x150
[   47.212879]  usb_stor_bulk_transfer_sglist.part.0+0x64/0xb0 [usb_storage]
[   47.212886]  usb_stor_bulk_srb+0x49/0x80 [usb_storage]
[   47.212893]  usb_stor_Bulk_transport+0x163/0x3e0 [usb_storage]
[   47.212898]  ? schedule+0x33/0x90
[   47.212905]  usb_stor_invoke_transport+0x3a/0x500 [usb_storage]
[   47.212910]  ? wait_for_completion_interruptible+0x156/0x1a0
[   47.212915]  ? wake_up_q+0x60/0x60
[   47.212922]  usb_stor_control_thread+0x183/0x280 [usb_storage]
[   47.212928]  kthread+0xfb/0x130
[   47.212934]  ? usb_stor_disconnect+0xb0/0xb0 [usb_storage]
[   47.212938]  ? kthread_park+0x80/0x80
[   47.212943]  ret_from_fork+0x22/0x40
[   47.212948] ---[ end trace 848c6eec31ed7f76 ]---

--- --- ---

More information.

With kernel 5.2.8 (still from Fedora) the problem appears,
but not any more with "hdparm -t /dev/sdX".
It is required or to copy large files, or something like
"dd if=/dev/sdX of=/dev/null bs=1M".

Sometime, with small blocks (bs=4k, for example), it seems
better, but I'll have to test more.

Finally, no difference between USB3.0 or USB2.0 in any
combination of devices.

On other PCs, all with Intel HW, I could not experience
the issue, yet.

If you need more information, please let me know, I'll
try to support as much a I can.

Thanks,

bye,

-- 

piergiorgio

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reeze while write on external usb 3.0 hard disk [Bug 204095]
  2019-08-17  9:54 reeze while write on external usb 3.0 hard disk [Bug 204095] Piergiorgio Sartor
@ 2019-08-19 14:14 ` Alan Stern
  2019-08-20  7:23   ` Christoph Hellwig
  0 siblings, 1 reply; 6+ messages in thread
From: Alan Stern @ 2019-08-19 14:14 UTC (permalink / raw)
  To: Piergiorgio Sartor, Jens Axboe, Christoph Hellwig
  Cc: USB list, linux-block, Kernel development list

Let's bring this to the attention of some more people.

It looks like the bug that was supposed to be fixed by commit
d74ffae8b8dd ("usb-storage: Add a limitation for
blk_queue_max_hw_sectors()"), which is part of 5.2.5, but apparently
the bug still occurs.

Alan Stern

On Sat, 17 Aug 2019, Piergiorgio Sartor wrote:

> Hi all,
> 
> bug 204095 from bugzilla.kernel.org was closed,
> but apparently something is left unfixed.
> 
> Ref.: https://bugzilla.kernel.org/show_bug.cgi?id=204095
> 
> Below the two last entries I did about the topic:
> 
> --- --- ---
> 
> I've Fedora 30 and there was an update, from kernel 5.1.20
> to 5.2.5, and now I've the logs full of:
> 
> ehci-pci 0000:00:13.2: swiotlb buffer is full (sz: 327680 bytes), total 32768 (slots), used 97 (slots)
> 
> Or similarly:
> 
> ehci-pci 0000:00:13.2: swiotlb buffer is full (sz: 315392 bytes), total 32768 (slots), used 103 (slots)
> 
> This happens whenever I access an external USB3.0 drive
> connected to a USB2.0 port, I'm not sure if this makes
> any difference.
> 
> It is enough something like "hdparm -t /dev/sdX" to trigger
> the above (and cause a lock-up of the command and 100% CPU
> load for "usb-storage").
> Nevertheless, it seems that the first access, likely few bytes
> read, is successful since the device is recognize by the file
> manager.
> Anything else, (large) file copy causes the issue.
> 
> Could it be the same bug? That is the fix for 5.2.5 does not
> fix it completely?
> 
> --- --- ---
> 
> Some more comments.
> 
> I tested a different PC, this does not show any problem, neither
> with the "old" 5.1.20 nor with the new 5.2.5 kernel.
> 
> Second, the original PC still have problems, here below the log
> output at the moment of the "crash" due to "hdparm -t /dev/sdX":
> 
> [   47.212609] xhci_hcd 0000:02:00.0: swiotlb buffer is full (sz: 421888 bytes), total 32768 (slots), used 1 (slots)
> [   47.212620] xhci_hcd 0000:02:00.0: overflow 0x0000000383a19000+421888 of DMA mask ffffffff bus mask 0
> [   47.212646] WARNING: CPU: 0 PID: 454 at kernel/dma/direct.c:43 report_addr+0x33/0x60
> [   47.212649] Modules linked in: fuse cfg80211 rfkill nf_log_ipv4 nf_log_common ipt_REJECT nf_reject_ipv4 xt_state xt_conntrack xt_owner xt_LOG iptable_filter nf_conntrack_ftp xt_CT nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw hwmon_vid sunrpc dm_crypt dm_cache_smq nvidia_drm(POE) dm_cache nvidia_modeset(POE) dm_persistent_data dm_bio_prison libcrc32c nvidia_uvm(OE) amd64_edac_mod edac_mce_amd kvm_amd ccp kvm snd_hda_codec_hdmi irqbypass joydev crct10dif_pclmul nvidia(POE) crc32_pclmul ghash_clmulni_intel snd_hda_codec_via snd_hda_codec_generic ledtrig_audio snd_hda_intel drm_kms_helper wmi_bmof snd_hda_codec fam15h_power k10temp snd_hda_core sp5100_tco snd_hwdep i2c_piix4 snd_seq snd_seq_device drm snd_pcm snd_timer ipmi_devintf snd ipmi_msghandler asus_atk0110 soundcore pcc_cpufreq acpi_cpufreq vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc ip_tables firewire_sbp2 raid1 raid10 crc32c_intel firewire_ohci firewire_core serio_raw crc_itu_t r8169 wmi uas
> [   47.212719]  usb_storage hid_logitech ff_memless ecryptfs
> [   47.212734] CPU: 0 PID: 454 Comm: usb-storage Tainted: P           OE     5.2.6-200.fc30.x86_64 #1
> [   47.212738] Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2101    12/02/2014
> [   47.212744] RIP: 0010:report_addr+0x33/0x60
> [   47.212750] Code: 48 8b 87 28 02 00 00 48 89 34 24 48 85 c0 74 2d 4c 8b 00 b8 fe ff ff ff 49 39 c0 76 14 80 3d a3 ae 41 01 00 0f 84 a9 06 00 00 <0f> 0b 48 83 c4 08 c3 48 83 bf 38 02 00 00 00 74 ef eb e0 80 3d 84
> [   47.212754] RSP: 0018:ffffa85941bffbc8 EFLAGS: 00010246
> [   47.212758] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000
> [   47.212762] RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffff9a45af617900
> [   47.212765] RBP: ffff9a45accc00b0 R08: ffffa85941bff92d R09: 00000000000003a3
> [   47.212769] R10: ffffffffb6bece08 R11: ffffa85941bff92d R12: 0000000000067000
> [   47.212772] R13: 0000000000000002 R14: 0000000000000000 R15: ffff9a45a40502b0
> [   47.212777] FS:  0000000000000000(0000) GS:ffff9a45af600000(0000) knlGS:0000000000000000
> [   47.212780] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   47.212784] CR2: 000055b215f34c50 CR3: 00000003d622e000 CR4: 00000000000406f0
> [   47.212787] Call Trace:
> [   47.212797]  dma_direct_map_page+0xdf/0xf0
> [   47.212803]  dma_direct_map_sg+0x67/0xb0
> [   47.212811]  usb_hcd_map_urb_for_dma+0x343/0x530
> [   47.212817]  usb_hcd_submit_urb+0x9a/0xbb0
> [   47.212824]  ? schedule_timeout+0x209/0x300
> [   47.212829]  ? usb_hcd_submit_urb+0xbf/0xbb0
> [   47.212835]  ? __switch_to_asm+0x40/0x70
> [   47.212840]  ? __switch_to_asm+0x34/0x70
> [   47.212845]  ? _cond_resched+0x15/0x30
> [   47.212852]  ? __kmalloc+0x16c/0x210
> [   47.212857]  ? _cond_resched+0x15/0x30
> [   47.212863]  ? usb_alloc_urb+0x35/0x60
> [   47.212867]  usb_sg_wait+0x7e/0x150
> [   47.212879]  usb_stor_bulk_transfer_sglist.part.0+0x64/0xb0 [usb_storage]
> [   47.212886]  usb_stor_bulk_srb+0x49/0x80 [usb_storage]
> [   47.212893]  usb_stor_Bulk_transport+0x163/0x3e0 [usb_storage]
> [   47.212898]  ? schedule+0x33/0x90
> [   47.212905]  usb_stor_invoke_transport+0x3a/0x500 [usb_storage]
> [   47.212910]  ? wait_for_completion_interruptible+0x156/0x1a0
> [   47.212915]  ? wake_up_q+0x60/0x60
> [   47.212922]  usb_stor_control_thread+0x183/0x280 [usb_storage]
> [   47.212928]  kthread+0xfb/0x130
> [   47.212934]  ? usb_stor_disconnect+0xb0/0xb0 [usb_storage]
> [   47.212938]  ? kthread_park+0x80/0x80
> [   47.212943]  ret_from_fork+0x22/0x40
> [   47.212948] ---[ end trace 848c6eec31ed7f76 ]---
> 
> --- --- ---
> 
> More information.
> 
> With kernel 5.2.8 (still from Fedora) the problem appears,
> but not any more with "hdparm -t /dev/sdX".
> It is required or to copy large files, or something like
> "dd if=/dev/sdX of=/dev/null bs=1M".
> 
> Sometime, with small blocks (bs=4k, for example), it seems
> better, but I'll have to test more.
> 
> Finally, no difference between USB3.0 or USB2.0 in any
> combination of devices.
> 
> On other PCs, all with Intel HW, I could not experience
> the issue, yet.
> 
> If you need more information, please let me know, I'll
> try to support as much a I can.
> 
> Thanks,
> 
> bye,


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reeze while write on external usb 3.0 hard disk [Bug 204095]
  2019-08-19 14:14 ` Alan Stern
@ 2019-08-20  7:23   ` Christoph Hellwig
  2019-08-20 16:37     ` Piergiorgio Sartor
  0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2019-08-20  7:23 UTC (permalink / raw)
  To: Alan Stern
  Cc: Piergiorgio Sartor, Jens Axboe, Christoph Hellwig, USB list,
	linux-block, Kernel development list

On Mon, Aug 19, 2019 at 10:14:25AM -0400, Alan Stern wrote:
> Let's bring this to the attention of some more people.
> 
> It looks like the bug that was supposed to be fixed by commit
> d74ffae8b8dd ("usb-storage: Add a limitation for
> blk_queue_max_hw_sectors()"), which is part of 5.2.5, but apparently
> the bug still occurs.

Piergiorgio,

can you dump the content of max_hw_sectors_kb file for your USB storage
device and send that to this thread?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reeze while write on external usb 3.0 hard disk [Bug 204095]
  2019-08-20  7:23   ` Christoph Hellwig
@ 2019-08-20 16:37     ` Piergiorgio Sartor
  2019-08-26 17:38       ` Piergiorgio Sartor
  0 siblings, 1 reply; 6+ messages in thread
From: Piergiorgio Sartor @ 2019-08-20 16:37 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Alan Stern, Piergiorgio Sartor, Jens Axboe, USB list,
	linux-block, Kernel development list

On Tue, Aug 20, 2019 at 09:23:26AM +0200, Christoph Hellwig wrote:
> On Mon, Aug 19, 2019 at 10:14:25AM -0400, Alan Stern wrote:
> > Let's bring this to the attention of some more people.
> > 
> > It looks like the bug that was supposed to be fixed by commit
> > d74ffae8b8dd ("usb-storage: Add a limitation for
> > blk_queue_max_hw_sectors()"), which is part of 5.2.5, but apparently
> > the bug still occurs.
> 
> Piergiorgio,
> 
> can you dump the content of max_hw_sectors_kb file for your USB storage
> device and send that to this thread?

Hi all,

for both kernels, 5.1.20 (working) and 5.2.8 (not working),
the content of /sys/dev/x:y/queue/max_hw_sectors_kb is 512
for USB storage devices (2.0 and 3.0).

This is for the PC showing the issue.

In an other PC, which does not show the issus at the moment,
the values are 120, for USB2.0, and 256, for USB3.0.

bye,

-- 

piergiorgio

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reeze while write on external usb 3.0 hard disk [Bug 204095]
  2019-08-20 16:37     ` Piergiorgio Sartor
@ 2019-08-26 17:38       ` Piergiorgio Sartor
  2019-08-29 14:08         ` Christoph Hellwig
  0 siblings, 1 reply; 6+ messages in thread
From: Piergiorgio Sartor @ 2019-08-26 17:38 UTC (permalink / raw)
  To: Piergiorgio Sartor
  Cc: Christoph Hellwig, Alan Stern, Jens Axboe, USB list, linux-block,
	Kernel development list

On Tue, Aug 20, 2019 at 06:37:22PM +0200, Piergiorgio Sartor wrote:
> On Tue, Aug 20, 2019 at 09:23:26AM +0200, Christoph Hellwig wrote:
> > On Mon, Aug 19, 2019 at 10:14:25AM -0400, Alan Stern wrote:
> > > Let's bring this to the attention of some more people.
> > > 
> > > It looks like the bug that was supposed to be fixed by commit
> > > d74ffae8b8dd ("usb-storage: Add a limitation for
> > > blk_queue_max_hw_sectors()"), which is part of 5.2.5, but apparently
> > > the bug still occurs.
> > 
> > Piergiorgio,
> > 
> > can you dump the content of max_hw_sectors_kb file for your USB storage
> > device and send that to this thread?
> 
> Hi all,
> 
> for both kernels, 5.1.20 (working) and 5.2.8 (not working),
> the content of /sys/dev/x:y/queue/max_hw_sectors_kb is 512
> for USB storage devices (2.0 and 3.0).
> 
> This is for the PC showing the issue.
> 
> In an other PC, which does not show the issus at the moment,
> the values are 120, for USB2.0, and 256, for USB3.0.

Hi again,

any news on this?

Is there anything I can do to help?

Should I report this somewhere else too?

Currently this is quite a huge problem for me,
since the only working external storage is an
old 1394 HDD...

Thanks,

bye,

-- 

piergiorgio

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: reeze while write on external usb 3.0 hard disk [Bug 204095]
  2019-08-26 17:38       ` Piergiorgio Sartor
@ 2019-08-29 14:08         ` Christoph Hellwig
  0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2019-08-29 14:08 UTC (permalink / raw)
  To: Piergiorgio Sartor
  Cc: Christoph Hellwig, Alan Stern, Jens Axboe, USB list, linux-block,
	Kernel development list

On Mon, Aug 26, 2019 at 07:38:33PM +0200, Piergiorgio Sartor wrote:
> any news on this?

Sorry, I've been dropping the ball here, and I'm a little puzzled
on what is going on.  Including on why we are bounce buffering for
xhci at all.  What kind of system (CPU / mainboard) is this?

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-17  9:54 reeze while write on external usb 3.0 hard disk [Bug 204095] Piergiorgio Sartor
2019-08-19 14:14 ` Alan Stern
2019-08-20  7:23   ` Christoph Hellwig
2019-08-20 16:37     ` Piergiorgio Sartor
2019-08-26 17:38       ` Piergiorgio Sartor
2019-08-29 14:08         ` Christoph Hellwig

Linux-USB Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-usb/0 linux-usb/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-usb linux-usb/ https://lore.kernel.org/linux-usb \
		linux-usb@vger.kernel.org linux-usb@archiver.kernel.org
	public-inbox-index linux-usb


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-usb


AGPL code for this site: git clone https://public-inbox.org/ public-inbox