Please review this patch. It might be deprecated anyway and it seems to make it easier to trigger some new kernel bugs: https://forums.gentoo.org/viewtopic-p-8256512.html#8256512 Or please at least add a menuconfig option, so the user can easily evaluate the necessity/usefulness of the patch for it's own system: for one, the patch was originally created for enclosures with two SATA ports and mentions issues with the second drive, however this patch also applies to enclosures with a single SATA port. Original patch notes: https://bugzilla.redhat.com/show_bug.cgi?id=1315013
Can you please do a change to your gentoo-sources kernel, compile, boot and let me know if this fixes your issue? File: drivers/usb/storage/unusual_uas.h Can you change line 98 from this: US_FL_NO_REPORT_OPCODES | US_FL_IGNORE_UAS), to this: US_FL_NO_REPORT_OPCODES),
(In reply to Mike Pagano from comment #1) > Can you please do a change to your gentoo-sources kernel, compile, boot and > let me know if this fixes your issue? > > File: > > drivers/usb/storage/unusual_uas.h > > Can you change line 98 from this: > > US_FL_NO_REPORT_OPCODES | US_FL_IGNORE_UAS), > > to this: > > US_FL_NO_REPORT_OPCODES), Yes, this is indeed the line which disables UAS on these enclosures. Sorry for the false bug report (this is not Gentoo related). By the way, max_hw_sectors_kb changed from 1024 to 512 (probably not an issue), bfq-mq now defaults to nr_requests=12 (it was 2 without UAS if I recall) but manually changing it to 64 (the auto default for all my SATA devices hanging on the ICH) still causes kernel warnings (and it's early to tell but usually unpredictable bad I/O performance follows). But that's probably an upstream bug as well (introduced in Linux 4.18). [ 1099.948443] WARNING: CPU: 1 PID: 99 at lib/sbitmap.c:406 __sbitmap_queue_get_shallow+0x84/0xb0 [ 1099.948451] CPU: 1 PID: 99 Comm: kworker/1:2 Not tainted 4.18.5-gentoo #5 [ 1099.948453] Hardware name: Gigabyte Technology Co., Ltd. X150M-PRO ECC/X150M-PRO ECC-CF, BIOS F22e 01/11/2018 [ 1099.948461] Workqueue: events_freezable_power_ disk_events_workfn [ 1099.948468] RIP: 0010:__sbitmap_queue_get_shallow+0x84/0xb0 [ 1099.948470] Code: 11 48 83 c4 08 5b 5d 41 5c c3 48 8b 53 18 65 c7 02 00 00 00 00 48 83 c4 08 5b 5d 41 5c c3 31 ed 45 85 e4 75 09 65 89 28 eb 9b <0f> 0b eb 88 89 74 24 04 e8 ef 26 fb ff 31 d2 41 f7 f4 8b 74 24 04 [ 1099.948550] RSP: 0018:ffffb60fc037fc20 EFLAGS: 00010282 [ 1099.948554] RAX: ffff91dd92264c00 RBX: ffff91dd92264c10 RCX: ffff91dd92264c10 [ 1099.948557] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff91dd92264c10 [ 1099.948560] RBP: ffffb60fc037fd00 R08: 0000000000000000 R09: 0000000000000000 [ 1099.948562] R10: 8080808080808080 R11: 0000000000000018 R12: ffff91de5491bc00 [ 1099.948565] R13: ffff91dd92264c10 R14: 0000000000000000 R15: 0000000000000001 [ 1099.948569] FS: 0000000000000000(0000) GS:ffff91de5ed00000(0000) knlGS:0000000000000000 [ 1099.948572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1099.948575] CR2: 000055d168f442a8 CR3: 00000001c560a006 CR4: 00000000002606e0 [ 1099.948577] Call Trace: [ 1099.948585] blk_mq_get_tag+0x24b/0x280 [ 1099.948593] ? __wake_up_common_lock+0xb0/0xb0 [ 1099.948598] blk_mq_get_request+0x30f/0x3c0 [ 1099.948602] blk_mq_alloc_request+0x78/0xd0 [ 1099.948607] blk_get_request+0x41/0x1c0 [ 1099.948614] scsi_execute+0x3e/0x240 [ 1099.948621] scsi_test_unit_ready+0x59/0xd0 [ 1099.948628] sd_check_events+0x10b/0x150 [ 1099.948634] disk_check_events+0x61/0x140 [ 1099.948640] ? __switch_to_asm+0x40/0x70 [ 1099.948646] process_one_work+0x1d1/0x310 [ 1099.948652] worker_thread+0x28/0x3c0 [ 1099.948657] kthread+0x105/0x120 [ 1099.948662] ? process_one_work+0x310/0x310 [ 1099.948666] ? __kthread_bind_mask+0x60/0x60 [ 1099.948671] ret_from_fork+0x35/0x40 [ 1099.948675] ---[ end trace 2271dd27a5af9582 ]---
Ok, sticking to the original issue, if I modify that patch, does this fix that?
(In reply to Mike Pagano from comment #3) > Ok, sticking to the original issue, if I modify that patch, does this fix > that? No, this entire bug report is invalid. I was mistaken when I originally suspected the gentoo patchset was involved. It's not (and on top of that, the UAS/MS mode doesn't make a difference anyway). This is some mainline kernel bug (probably in the bfq-mq scheduler code). I change the status to resolved/invalid. Sorry for the trouble.
