kernel bug in 11.3-STABLE causes frequent crashes
The rest of this message was posted a little while ago to the freebsd-questions list by mistake. It was intended for freebsd-stable, so I am posting it here now after posting a brief apology on the other list. I have had to waste a great deal of time lately in recovering my system from crashes due to a kernel bug. At present, my system is FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 11:39:52 CDT 2019 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64 There are actually at least two problems, but this particular one has been causing a large portion of my forced reboots. It usually fails to produce a dump and freezes right after the panic and backtrace messages, as it did earlier tonight, but Wednesday night it did create a dump, which I am keeping in case it should prove helpful in getting the bug identified and solved. I copied the console messages to paper painstakingly by hand. They appear to be identical each time, except, of course, for the messages that a dump is produced when, indeed, it does produce one. I am omitting those fairly standard messages. Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a4b14c stack pointer = 0x0:0xfe012a60ea50 frame pointer = 0x0:0xfe012a60eae0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 28 (flowcleaner) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0x80a94707 at kdb_backtrace+0x67 #1 0x80a4fa2e at vpanic+0x17e #2 0x80a4f8a3 at panic+0x43 #3 0x80f3a4d0 at trap_pfault+0 #4 0x80f3a519 at trap_pfault+0x49 #5 0x80f39bad at trap+0x29 #6 0x80f19f33 at calltrap+0x8 #7 0x80b3bb8d at flowtable_clean_vnet+0x43d #8 0x80b3c758 at flowtable_cleaner+0xc8 #9 0x80a12ea2 at fork_exit+0x82 #10 0x80flaf4e at fork_trampoline+0xe The machine is ancient. The CPU is a QX9650 (last group of Core 2 Quads) with 8 GB of DDR3 memory. If this can be identified as a known bug and a clue provided to a patch or a safer version to upgrade to, I would be grateful. I am getting very, very tired of these crashes. The other forced reboots I will describe in a separate message, but that problem has existed since the time of 11.2-RELEASE and apparently was never investigated, much less fixed, although people began complaining on this list and possibly -questions within the first few days after the release date. Thanks in advance for any help with this problem! Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel bug in 11.3-STABLE causes frequent crashes
09.11.2019 19:45, Scott Bennett пишет: > The rest of this message was posted a little while ago to the > freebsd-questions list by mistake. It was intended for freebsd-stable, > so I am posting it here now after posting a brief apology on the other > list. > I have had to waste a great deal of time lately in recovering my > system from crashes due to a kernel bug. At present, my system is > > FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 > 11:39:52 CDT 2019 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64 > > There are actually at least two problems, but this particular one has been > causing a large portion of my forced reboots. It usually fails to produce > a dump and freezes right after the panic and backtrace messages, as it did > earlier tonight, but Wednesday night it did create a dump, which I am > keeping in case it should prove helpful in getting the bug identified and > solved. I copied the console messages to paper painstakingly by hand. > They appear to be identical each time, except, of course, for the messages > that a dump is produced when, indeed, it does produce one. I am omitting > those fairly standard messages. > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0x3b8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80a4b14c > stack pointer = 0x0:0xfe012a60ea50 > frame pointer = 0x0:0xfe012a60eae0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 28 (flowcleaner) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > #0 0x80a94707 at kdb_backtrace+0x67 > #1 0x80a4fa2e at vpanic+0x17e > #2 0x80a4f8a3 at panic+0x43 > #3 0x80f3a4d0 at trap_pfault+0 > #4 0x80f3a519 at trap_pfault+0x49 > #5 0x80f39bad at trap+0x29 > #6 0x80f19f33 at calltrap+0x8 > #7 0x80b3bb8d at flowtable_clean_vnet+0x43d > #8 0x80b3c758 at flowtable_cleaner+0xc8 > #9 0x80a12ea2 at fork_exit+0x82 > #10 0x80flaf4e at fork_trampoline+0xe > > The machine is ancient. The CPU is a QX9650 (last group of Core 2 > Quads) with 8 GB of DDR3 memory. > If this can be identified as a known bug and a clue provided to a > patch or a safer version to upgrade to, I would be grateful. I am getting > very, very tired of these crashes. > The other forced reboots I will describe in a separate message, but > that problem has existed since the time of 11.2-RELEASE and apparently was > never investigated, much less fixed, although people began complaining on > this list and possibly -questions within the first few days after the > release date. > Thanks in advance for any help with this problem! It seems you have custom kernel with options FLOWTABLE. The code it includes is known to be buggy, this options was removed from GENERIC many releases ago. Remove it from your kernel configuration, rebuild kernel and you will be fine. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel bug in 11.3-STABLE causes frequent crashes
09.11.2019 19:45, Scott Bennett wrote: > The rest of this message was posted a little while ago to the > freebsd-questions list by mistake. It was intended for freebsd-stable, > so I am posting it here now after posting a brief apology on the other > list. > I have had to waste a great deal of time lately in recovering my > system from crashes due to a kernel bug. At present, my system is > > FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 > 11:39:52 CDT 2019 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64 > > There are actually at least two problems, but this particular one has been > causing a large portion of my forced reboots. It usually fails to produce > a dump and freezes right after the panic and backtrace messages, as it did > earlier tonight, but Wednesday night it did create a dump, which I am > keeping in case it should prove helpful in getting the bug identified and > solved. I copied the console messages to paper painstakingly by hand. > They appear to be identical each time, except, of course, for the messages > that a dump is produced when, indeed, it does produce one. I am omitting > those fairly standard messages. > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0x3b8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80a4b14c > stack pointer = 0x0:0xfe012a60ea50 > frame pointer = 0x0:0xfe012a60eae0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 28 (flowcleaner) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > #0 0x80a94707 at kdb_backtrace+0x67 > #1 0x80a4fa2e at vpanic+0x17e > #2 0x80a4f8a3 at panic+0x43 > #3 0x80f3a4d0 at trap_pfault+0 > #4 0x80f3a519 at trap_pfault+0x49 > #5 0x80f39bad at trap+0x29 > #6 0x80f19f33 at calltrap+0x8 > #7 0x80b3bb8d at flowtable_clean_vnet+0x43d > #8 0x80b3c758 at flowtable_cleaner+0xc8 > #9 0x80a12ea2 at fork_exit+0x82 > #10 0x80flaf4e at fork_trampoline+0xe > > The machine is ancient. The CPU is a QX9650 (last group of Core 2 > Quads) with 8 GB of DDR3 memory. > If this can be identified as a known bug and a clue provided to a > patch or a safer version to upgrade to, I would be grateful. I am getting > very, very tired of these crashes. > The other forced reboots I will describe in a separate message, but > that problem has existed since the time of 11.2-RELEASE and apparently was > never investigated, much less fixed, although people began complaining on > this list and possibly -questions within the first few days after the > release date. > Thanks in advance for any help with this problem! It seems you have custom kernel with options FLOWTABLE. The code it includes is known to cause panics, this options was removed from GENERIC many releases ago. Remove it from your kernel configuration, rebuild kernel and you will be fine. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel bug in 11.3-STABLE causes frequent crashes
Eugene, Thank you very much for the fast reply! Eugene Grosbein wrote: > 09.11.2019 19:45, Scott Bennett ?: > > The rest of this message was posted a little while ago to the > > freebsd-questions list by mistake. It was intended for freebsd-stable, > > so I am posting it here now after posting a brief apology on the other > > list. > > I have had to waste a great deal of time lately in recovering my > > system from crashes due to a kernel bug. At present, my system is > > > > FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 > > 11:39:52 CDT 2019 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64 > > > > There are actually at least two problems, but this particular one has been > > causing a large portion of my forced reboots. It usually fails to produce > > a dump and freezes right after the panic and backtrace messages, as it did > > earlier tonight, but Wednesday night it did create a dump, which I am > > keeping in case it should prove helpful in getting the bug identified and > > solved. I copied the console messages to paper painstakingly by hand. > > They appear to be identical each time, except, of course, for the messages > > that a dump is produced when, indeed, it does produce one. I am omitting > > those fairly standard messages. > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 2; apic id = 02 > > fault virtual address = 0x3b8 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x80a4b14c > > stack pointer = 0x0:0xfe012a60ea50 > > frame pointer = 0x0:0xfe012a60eae0 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process = 28 (flowcleaner) > > trap number = 12 > > panic: page fault > > cpuid = 2 > > KDB: stack backtrace: > > #0 0x80a94707 at kdb_backtrace+0x67 > > #1 0x80a4fa2e at vpanic+0x17e > > #2 0x80a4f8a3 at panic+0x43 > > #3 0x80f3a4d0 at trap_pfault+0 > > #4 0x80f3a519 at trap_pfault+0x49 > > #5 0x80f39bad at trap+0x29 > > #6 0x80f19f33 at calltrap+0x8 > > #7 0x80b3bb8d at flowtable_clean_vnet+0x43d > > #8 0x80b3c758 at flowtable_cleaner+0xc8 > > #9 0x80a12ea2 at fork_exit+0x82 > > #10 0x80flaf4e at fork_trampoline+0xe > > > > The machine is ancient. The CPU is a QX9650 (last group of Core 2 > > Quads) with 8 GB of DDR3 memory. > > If this can be identified as a known bug and a clue provided to a > > patch or a safer version to upgrade to, I would be grateful. I am getting > > very, very tired of these crashes. > > The other forced reboots I will describe in a separate message, but > > that problem has existed since the time of 11.2-RELEASE and apparently was > > never investigated, much less fixed, although people began complaining on > > this list and possibly -questions within the first few days after the > > release date. > > Thanks in advance for any help with this problem! > > It seems you have custom kernel with options FLOWTABLE. The code it includes > is known to be buggy, this options was removed from GENERIC many releases ago. > Remove it from your kernel configuration, rebuild kernel and you will be fine. > Wonderful. I have a comment on that line, saying I added it for 8.x, so I probably found it in 8.1's GENERIC configuration file when I was preparing to upgrade from 7.3. It is interesting that it only started hitting me (hard enough to make me notice it, at least) in 11.3 and maybe a bit earlier in 11.2. Anyway, that will be easy enough to fix, but will require rolling /usr/src back to the revision I am running, which is probably also no big deal. I don't seem to be able to build it at the current source revision because 11-STABLE's buildworld began failing during the libc build two or three weeks ago. I just tried "svn update /usr/src" again, followed by "make -j6 buildworld", and it still fails with this ending. --- libc_pic.a --- ranlib -D libc_pic.a --- libc.a --- ranlib -D libc.a --- libc.so.7.full --- cc: error: unable to execute command: posix_spawn failed: Permission denied cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libc.so.7.full] Error code 1 make[4]: stopped in /usr/src/lib/libc 1 error make[4]: stopped in /usr/src/lib/libc *** [lib/libc__L] Error code 2 make[3]: stopped in /usr/src 1 error make[3]: stopped in /usr/src *** [libraries] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_libraries] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Oh, well. During the intervening weeks, I h
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Fri, Nov 08, 2019 at 02:28:17PM -0800, Doug Ambrisko wrote: > On Tue, Nov 05, 2019 at 09:44:36PM +0100, Miroslav Lachman wrote: > | Chris Ross wrote on 11/05/2019 21:19: > | > On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote: > | >> Chris Ross wrote on 11/05/2019 19:34: > | >>> Hello. I have a Cisco UCS C220-M5 with a RAID controller. It calls > itself > | >>> "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5. > | >>> Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, which > | >>> looks to be an LSI MegaRAID Tri-Mode SAS3516. It looks like this should > | >>> be supported by the mpr(4) driver, but it doesn't seem to recognize it > | >>> at boot time. > | > | mpr_load="YES" goes to /etc/loader.conf > | > | If you need to load mpr manually in boot prompt I am not sure if it > | should be: > | load mpr > | or > | load mpr.ko > | of full path > | load /boot/kernel/mpr.ko > > This should be a mrsas card and not an HBA! mrsas supports all current > UCS RAID cards ... and the next unreleased UCS system :-) You might need > the one in -current for that. I'm not sure what is in 12.1. Hi Doug! Thanks. Okay, I infer from that that the mpr driver is for HBAs that aren't raid? Grepping through the sources for 3516 found me only mpr. Looking more carefully, at mrsas while knowing specifically what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura SAS Controller". And, that code (mrsas) is about the same in stable-12 as is it in -current. Can you provide some guidance of what I need to do to get the mrsas driver to identify it when booting the install ISO? - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
On Thu, Nov 07, 2019 at 02:53:25PM -0500, Chris Ross wrote: > > > On Thu, Nov 7, 2019 at 9:46 AM Julian Elischer wrote: > > >> You could try some bisection back along the 12 branch.. > > Yeah. I was hoping for an easier path, but. I can try slogging back > through stable-12 a month or two at a time. Okay. I spent a bunch of time moving around stable-12 by date, and an ISO build from stable-12 as of 2019-10-14 works (rev 353483), and 2019-10-15 (rev 353541) does not. The svn update across that day shows: Updating '.': Ustand/efi/boot1/boot1.c Ustand/efi/include/efilib.h Ustand/efi/libefi/devpath.c Ustand/efi/libefi/efinet.c Ustand/efi/libefi/efipart.c Ustand/efi/libefi/libefi.c Ustand/efi/loader/arch/i386/efimd.c Ustand/efi/loader/efi_main.c Ustand/efi/loader/framebuffer.c Ustand/efi/loader/main.c Ustand/libsa/stand.h Ustand/libsa/zalloc.c Ustand/libsa/zalloc_defs.h Ustand/libsa/zalloc_malloc.c Ustand/libsa/zalloc_mem.h Ustand/libsa/zalloc_protos.h U . Updated to revision 353541. So, there's the commit/commits. Can someone else who knows the intra-branch process better help me determine where the original change came from, what it was meant to accomplish, then hopefully we can find out what went wrong for at least my hardware? Thanks all! - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Sat, Nov 09, 2019 at 11:38:54AM -0500, Chris Ross wrote: > On Fri, Nov 08, 2019 at 02:28:17PM -0800, Doug Ambrisko wrote: > > On Tue, Nov 05, 2019 at 09:44:36PM +0100, Miroslav Lachman wrote: > > | Chris Ross wrote on 11/05/2019 21:19: > > | > On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote: > > | >> Chris Ross wrote on 11/05/2019 19:34: > > | >>> Hello. I have a Cisco UCS C220-M5 with a RAID controller. It calls > > itself > > | >>> "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5. > > | >>> Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, > > which > > | >>> looks to be an LSI MegaRAID Tri-Mode SAS3516. It looks like this > > should > > | >>> be supported by the mpr(4) driver, but it doesn't seem to recognize it > > | >>> at boot time. > > | > > | mpr_load="YES" goes to /etc/loader.conf > > | > > | If you need to load mpr manually in boot prompt I am not sure if it > > | should be: > > | load mpr > > | or > > | load mpr.ko > > | of full path > > | load /boot/kernel/mpr.ko > > > > This should be a mrsas card and not an HBA! mrsas supports all current > > UCS RAID cards ... and the next unreleased UCS system :-) You might need > > the one in -current for that. I'm not sure what is in 12.1. > > Hi Doug! Thanks. Okay, I infer from that that the mpr driver is for > HBAs that aren't raid? Grepping through the sources for 3516 found me > only mpr. Looking more carefully, at mrsas while knowing specifically > what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura > SAS Controller". And, that code (mrsas) is about the same in stable-12 as > is it in -current. > > Can you provide some guidance of what I need to do to get the mrsas > driver to identify it when booting the install ISO? See the "PRIORITY" section of https://www.freebsd.org/cgi/man.cgi?query=mrsas&sektion=4 You can also set that tunable via the loader Regards, Gary ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
On Sat, Nov 9, 2019 at 10:42 AM Chris Ross wrote: > > On Thu, Nov 07, 2019 at 02:53:25PM -0500, Chris Ross wrote: > > > > On Thu, Nov 7, 2019 at 9:46 AM Julian Elischer > > > > wrote: > > > >> You could try some bisection back along the 12 branch.. > > > > Yeah. I was hoping for an easier path, but. I can try slogging back > > through stable-12 a month or two at a time. > > Okay. I spent a bunch of time moving around stable-12 by date, and > an ISO build from stable-12 as of 2019-10-14 works (rev 353483), and > 2019-10-15 (rev 353541) does not. > > The svn update across that day shows: > > Updating '.': > Ustand/efi/boot1/boot1.c > Ustand/efi/include/efilib.h > Ustand/efi/libefi/devpath.c > Ustand/efi/libefi/efinet.c > Ustand/efi/libefi/efipart.c > Ustand/efi/libefi/libefi.c > Ustand/efi/loader/arch/i386/efimd.c > Ustand/efi/loader/efi_main.c > Ustand/efi/loader/framebuffer.c > Ustand/efi/loader/main.c > Ustand/libsa/stand.h > Ustand/libsa/zalloc.c > Ustand/libsa/zalloc_defs.h > Ustand/libsa/zalloc_malloc.c > Ustand/libsa/zalloc_mem.h > Ustand/libsa/zalloc_protos.h > U . > Updated to revision 353541. > > So, there's the commit/commits. Can someone else who knows the intra-branch > process better help me determine where the original change came from, > what it was meant to accomplish, then hopefully we can find out what went > wrong for at least my hardware? > Hi, That helps- thanks! I'm CC'ing tsoome@, as this is basically just r353501 in that range. Can you give the latest -CURRENT snapshot boot as another data point? Thanks, Kyle Evans ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
On Sat, Nov 09, 2019 at 11:24:49AM -0600, Kyle Evans wrote: > Hi, > > That helps- thanks! I'm CC'ing tsoome@, as this is basically just > r353501 in that range. Can you give the latest -CURRENT snapshot boot > as another data point? Thanks. And yeah, happily, I was already in the process of building a -current to test. I am happy (in a way?) to report that it fails in the same way as 12.1-RELEASE and stable-12 after Oct 15. Thanks. - Chris for tsoome, the description of boot messages from the top of the thread: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=98224+0+current/freebsd-stable ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?
On Sat, Nov 09, 2019 at 04:48:10PM +, Gary Palmer wrote: > > Hi Doug! Thanks. Okay, I infer from that that the mpr driver is for > > HBAs that aren't raid? Grepping through the sources for 3516 found me > > only mpr. Looking more carefully, at mrsas while knowing specifically > > what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura > > SAS Controller". And, that code (mrsas) is about the same in stable-12 as > > is it in -current. > > > > Can you provide some guidance of what I need to do to get the mrsas > > driver to identify it when booting the install ISO? > > See the "PRIORITY" section of > > https://www.freebsd.org/cgi/man.cgi?query=mrsas&sektion=4 > > You can also set that tunable via the loader Hmm. Okay. I know I was messing with that parameter on one of these machines, I though I'd tried it on this one. But, maybe that was the older box with the HBA in it. While I try that, I have a question. I understood that tunable to be a way to get the mfi(4) driver to allow the mrsas(4) driver to be used for devices they both would recognize. But, in this case, it's clear that the mfi(4) driver has now knowledge of this device. Is that tunable being set necessary to have the mrsas(4) driver even find the devices it knows how to support that mfi(4) doesn't? If so, that's a very unfortunate situation. Because there will be a significant set of controllers, like the one I have in this system, that totally fail to present themselves when installing from the install media. Maybe this is a political issue, and I should stop thinking about it, but. Let me know if I'm understanding the technical side, that there are cards mfi(4) has no support for, but this tunable prevents mrsas(4) from attaching them? - Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
