[Bug 229087] 11.2-RC3 Weird keyboard behaviour
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229087 Andriy Gapon changed: What|Removed |Added Status|New |Closed Resolution|--- |Not A Bug -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 163461] [vfs] vfs.zfs.arc_max/vfs.zfs.arc_meta_limit defaults aren't wise
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163461 Shane changed: What|Removed |Added CC||free...@shaneware.biz --- Comment #3 from Shane --- Rather than start a new report I will jump into this old one. Currently arc_max is set to the larger of (5/8 of kmem_size) or (kmem_size minus 1G) - for a system with 8G of ram 5/8 is 5G with kmem size minus 1G about 6GB While that sounds ok, we also have max_wired which seems to default to 5G (I see that on an 8G and 16G setup) the issue results from arc being wired but not included in the max_wired count, that means an 8G system allows 10G to get wired! a 16GB system allows 20GB to be wired! When a system has more than 70% of physical ram wired, it gets exteremely slow and over 80% wired gives a very high chance of needing a hard reset. At the minimum we need to consider max_wired in the arc_max calculation. I do believe the arc_max default should be even smaller to be better suited to more common setups that run processes that use ram, a sysadmin starting a file server that wants to use most of the ram for cache should know how to set this as desired, the other 80-90% of users shouldn't have to adjust a setting that is suited to the smaller use case. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 Bug ID: 229106 Summary: intr_event_handle is unsafe with respect to interrupt handler list Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: a...@freebsd.org Created attachment 194354 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=194354&action=edit code changes to greately increase likelihood of the race I must state upfront that I discovered the issue through code review and I had to make special arrangements to provoke the problem. The core of the issue is that intr_event_handle iterates the list of handlers, ie_handlers, without any protection whatsoever. Also, removal and installation of a filter-only handler does not make any attempt to synchronize with with intr_event_handle. As such, it is possible (although very improbable) that intr_event_handle may iterate into an element just before it is removed and derefence its pointer to a next element after the former element is freed and the pointer is overwritten. This problem is only for a shared interrupts. When an interrupt is not shared, then it should be disabled before its handler is torn down. Here is a stack trace of the crash: fault virtual address = 0x fault code = supervisor read data, page not present instruction pointer = 0x20:0x80b64ff0 stack pointer = 0x28:0xfe434970 frame pointer = 0x28:0xfe4349b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu2) trap number = 12 panic: page fault cpuid = 2 time = 1529319165 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe434630 vpanic() at vpanic+0x1a3/frame 0xfe434690 panic() at panic+0x43/frame 0xfe4346f0 trap_fatal() at trap_fatal+0x35f/frame 0xfe434740 trap_pfault() at trap_pfault+0x62/frame 0xfe434790 trap() at trap+0x2ba/frame 0xfe4348a0 calltrap() at calltrap+0x8/frame 0xfe4348a0 --- trap 0xc, rip = 0x80b64ff0, rsp = 0xfe434970, rbp = 0xfe4349b0 --- intr_event_handle() at intr_event_handle+0xa0/frame 0xfe4349b0 intr_execute_handlers() at intr_execute_handlers+0x58/frame 0xfe4349e0 lapic_handle_intr() at lapic_handle_intr+0x6d/frame 0xfe434a20 Xapic_isr1() at Xapic_isr1+0xd0/frame 0xfe434a20 --- interrupt, rip = 0x80bd3b49, rsp = 0xfe434af0, rbp = 0xfe434bb0 --- sched_idletd() at sched_idletd+0x4a9/frame 0xfe434bb0 fork_exit() at fork_exit+0x84/frame 0xfe434bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe434bf0 This is what I did to get the crash. 1. Found hardware with shared interrupts. Specifically, I had three USB OHCI controllers sharing PCI IRQ 18. 2. Modified the ohci driver, so that it installed a dummy filter instead of its ithread handler. This made the driver non-functional, of course. 3. Modified IO-APIC code, so that it kept re-raising the interrupt thus increasing the chances of getting the race within a reasonable time frame. 4. Re-compiled kern_intr.c with QUEUE_MACRO_DEBUG_TRASH to make the race more probable by immediately corrupting a removed handler. 5. Triggered the interrupt storm for IRQ 18. 6. Ran a continuous loop of devctl detach followed by devctl attach for ohci driver instances sharing the interrupt. All the code modifications are in the attachment. The devctl command line was: while true ; do devctl detach ohci3 && devctl attach pci0:0:19:1 ; devctl detach ohci4 && devctl attach pci0:0:20:5 ; done The rate of interrupts was about 570K per second: 569k ohci2 ohci The stack trace in kgdb: (kgdb) bt #0 __curthread () at ./machine/pcpu.h:231 #1 doadump (textdump=1) at /usr/devel/svn/head/sys/kern/kern_shutdown.c:366 #2 0x80ba33e2 in kern_reboot (howto=260) at /usr/devel/svn/head/sys/kern/kern_shutdown.c:446 #3 0x80ba39c3 in vpanic (fmt=, ap=0xfe4346d0) at /usr/devel/svn/head/sys/kern/kern_shutdown.c:863 #4 0x80ba3a13 in panic (fmt=) at /usr/devel/svn/head/sys/kern/kern_shutdown.c:790 #5 0x8107c6ff in trap_fatal (frame=0xfe4348b0, eva=18446744073709551615) at /usr/devel/svn/head/sys/amd64/amd64/trap.c:892 #6 0x8107c772 in trap_pfault (frame=0xfe4348b0, usermode=) at /usr/devel/svn/head/sys/amd64/amd64/trap.c:728 #7 0x8107bd7a in trap (frame=0xfe4348b0) at /usr/devel/svn/head/sys/amd64/amd64/trap.c:427 #8 #9 intr_event_handle (ie=0xf80003349300, frame=0xfe434a30) at /usr/devel/
[Bug 229107] linprocfs: implement /dev/tty/drivers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229107
Bug ID: 229107
Summary: linprocfs: implement /dev/tty/drivers
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: ema...@freebsd.org
On Gentoo "Linux (none) 4.14.33-v8-0a76b56e61cf+ #1 SMP PREEMPT Wed Apr 11
11:36:25 BST 2018 aarch64 GNU/Linux" on RPi 3B+ /proc/tty/drivers contains:
/dev/tty /dev/tty5 0 system:/dev/tty
/dev/console /dev/console5 1 system:console
/dev/ptmx/dev/ptmx 5 2 system
/dev/vc/0/dev/vc/0 4 0 system:vtmaster
ttyAMA /dev/ttyAMA 204 64-77 serial
ttyprintk/dev/ttyprintk 5 3 console
pty_slave/dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
unknown /dev/tty4 1-63 console
This seems to be accessed by some common startup code - e.g., invoking bin/ps
reads from /proc/tty/drivers.
strace on Linus shows:
openat(AT_FDCWD, "/proc/tty/drivers", O_RDONLY) = 6
read(6, "/dev/tty /dev/tty "..., ) = 521
close(6)= 0
newfstatat(AT_FDCWD, "/dev/pts0", 0x7ff7270018, 0) = -1 ENOENT (No such file or
directory)
newfstatat(AT_FDCWD, "/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
0), ...}, 0) = 0
openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=26244, ...}) = 0
mmap(NULL, 26244, PROT_READ, MAP_SHARED, 6, 0) = 0x7f90e6a000
close(6)= 0
newfstatat(AT_FDCWD, "/proc/946", {st_mode=S_IFDIR|0555, st_size=0, ...}, 0) =
0
openat(AT_FDCWD, "/proc/946/stat", O_RDONLY) = 6
read(6, "946 (kworker/3:2) I 2 0 0 0 -1 6"..., 1024) = 160
close(6)= 0
...
Linux bin/ps under arm64 Linuxulator:
649 ps CALL linux_openat(0xff9c,0x40164a78,0,0)
649 ps NAMI "/compat/linux/proc/tty/drivers"
649 ps NAMI "/proc/tty/drivers"
649 ps RET linux_openat -1 errno -2 No such file or directory
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229107] linprocfs: implement /dev/tty/drivers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229107 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|emulat...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 213501] Screen blank after sleep/resume
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213501 --- Comment #7 from John Baldwin --- (In reply to Andriy Gapon from comment #6) Yes, X with VESA will most likely not work aside from an older BIOS. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #1 from John Baldwin --- This is an old race. I have a very old p4 branch that dedicates a spin lock to protecting the list of handlers (and then uses that as the thread_lock of idle interrupt threads so that the number of spin locks taken for an interrupt remains the same) that fixes this. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #2 from Andriy Gapon --- Yes, it's an old one. I think that using a spinlock is perfectly fine. I also have a work-in-progress that tries to solve the problem with some atomic magic so that intr_event_handle is completely wait / spin free (if the interrupt thread does not need to run, of course). I guess that a difference between those two approaches would be negligible. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 Conrad Meyer changed: What|Removed |Added CC||c...@freebsd.org --- Comment #3 from Conrad Meyer --- Just FYI for next time, if you're making code changes, fail_point(9) can make this kind of scenario much easier to hit. In particular, you can expand races by adding in an empty KFAIL_POINT_CODE() and then inducing a delay with sysctl my.failpoint="50%delay(1000)" (i.e., DELAY(1000) 50% of times we hit that failpoint; the 50% can help avoid excessive foot-shooting). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #4 from Conrad Meyer --- Is this list a good candidate for epoch(9)-based reclamation? :-) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #5 from John Baldwin --- I suspect you cannot use epoch(9) in primary interrupt context (e.g. filters) just as you can't use regular mutexes there. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #6 from Andriy Gapon --- But a similar approach might work. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #7 from Conrad Meyer --- Where does epoch(9) take a regular mtx? I may just be missing it, but I see only spin mutexes. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229120] [acpi_ibm] [patch] Add support for newer Thinkpad models with id LEN0268
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229120 Bug ID: 229120 Summary: [acpi_ibm] [patch] Add support for newer Thinkpad models with id LEN0268 Product: Base System Version: 11.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: ali...@gmail.com Created attachment 194370 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=194370&action=edit Support newer thinkpads with LEN0268 id The attached patch adds support for newer Thinkpad models. The patch has been tested on a Thinkpad T480, but should work on other models as well. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229120] [acpi_ibm] [patch] Add support for newer Thinkpad models with id LEN0268
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229120 Mark Linimon changed: What|Removed |Added Keywords||patch Assignee|b...@freebsd.org|a...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 228755] libvgl under syscons causes system reboot (via SDL 1.2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228755 Mahmoud Al-Qudsi changed: What|Removed |Added Keywords||crash, panic Hardware|Any |i386 Status|New |Closed Severity|Affects Only Me |Affects Many People Resolution|--- |FIXED --- Comment #2 from Mahmoud Al-Qudsi --- Verified fixed. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 190281] netstat -s -i only shows ip6 statistics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190281
Marie Helene Kvello-Aune changed:
What|Removed |Added
CC||mariehelen...@gmail.com
--- Comment #3 from Marie Helene Kvello-Aune ---
I decided to look at this today, and to my surprise, I found that netstat
doesn't implement per-interface statistics for IPv4 at all.
In usr.bin/netstat/main.c, line 105-106:
{ N_RIPCBINFO, N_IPSTAT, 1, protopr,
ip_stats, NULL, "ip", 1, IPPROTO_RAW },
The 6th argument is supposed to be the function which prints per-interface
statistics.
The equivelant lines for IPv6 (line 141-142):
{ N_RIPCBINFO, N_IP6STAT, 1, protopr,
ip6_stats,ip6_ifstats,"ip6", 1, IPPROTO_RAW },
ip6_stats and ip6_ifstats are implemented in usr.bin/netstat/inet6.c.
ip_stats (but no ip_ifstats) is implemented in usr.bin/netstat/inet.c.
tl;dr: someone has to implement functions to print the IPv4 information as
well.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 190281] netstat -s -i only shows ip6 statistics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190281 --- Comment #4 from Marie Helene Kvello-Aune --- ... And I just realized I didn't see the comment by Eitan Adler before starting to dig into this. Oops. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #8 from Andriy Gapon --- (In reply to Conrad Meyer from comment #7) I don't know epoch(9) / ck_epoch implementation details, but given the constraints[*] of interrupt handling, I think that it could be an overkill. I mean, it probably has some overhead that's avoidable. And for that latency sensitive code it could matter. [*] The interrupt handler list can be iterated only by a single thread / context at a time. Also, we reduce modifications to a single thread at a time using a mutex. Performance of adding and removing interrupt handlers is not critical. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #9 from Conrad Meyer --- (In reply to Andriy Gapon from comment #8) Yes, performance of add/remove doesn't matter. But performance of intr_event_handle() matters very much, and adding a contested spin lock to it seems like a bad idea. I suppose it only needs to be taken for shared interrupts, not MSI, so maybe the impact is not so bad. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #10 from John Baldwin --- To be clear, we are not talking about adding a spin mutex. We are talking about replacing the existing sched_lock mutex used to schedule the ithread anyway with a dedicated spin mutex that protects the list of handlers and can be used as the THREAD_LOCK when scheduling the ithread since ithreads are changed in this patch to set td_lock to the new mutex when they are idle. You can't get away from the mutex to call sched_add(), but this lets you change what lock is now used for that in essence. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #11 from Conrad Meyer --- Sure. It'd still be a single global spin lock, right? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #12 from John Baldwin --- No, it is kind of per-IRQ, not global. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 229106] intr_event_handle is unsafe with respect to interrupt handler list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229106 --- Comment #13 from Conrad Meyer --- Oh, that's much better. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 203349] [META] FreeBSD Foundation sponsored project dependencies for FreeBSD 11.x
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203349 Bug 203349 depends on bug 223806, which changed state. Bug 223806 Summary: java/openjdk8: [PATCH] arm64 package builds do not allow enough time for build to complete https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223806 What|Removed |Added Status|New |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 211713] NVME controller failure: resetting (Samsung SM961 SSD Drives)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713 Ali Abdallah changed: What|Removed |Added CC||ali...@gmail.com --- Comment #62 from Ali Abdallah --- Same problem on FreeBSD 11.2-RC3 on a Thinkpad T480. After resuming from suspend the system is not usable for 10-30 seconds, showing the following messages nvme0: Resetting controller due to a timeout. nvme0: Resetting controller due to a timeout. nvme0: resetting controller nvme0: Resetting controller due to a timeout. nvme0: aborting outstanding i/o nvme0: WRITE sqid:1 cid:124 nsid:1 lba:302574390 len:72 . . -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
