Upgrading 11.2 -> 12.0 on EC2
Hello, I’m looking for advice on doing a release upgrade of a running instance. It looks like the normal procedure using freebsd-update requires a reboot between invocations of the install command, but after the first reboot, most of the userland is non-functional, including most importantly sshd. Is it safe to run the install commands back to back without rebooting? Or is the only safe procedure to build a new instance from scratch for each release? Cheers, -Brian ___ 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"
FreeBSD Potential Business Leads
Hi, Hope this email finds you well. Would you be interested in acquiring our recently verified data of FreeBSD Users List? Each Contact Includes: Names, Title, Email, Phone, Company Name, Company URL and Company physical address, SIC Code, Industry, Company Size (Revenue and Employee). We also have related technology users like: Google Sheets, Nagios, PeopleSoft, Fonts.com, Wufoo, Marketo and many more. Please let me know and share your thoughts, if you are interested so that I will get back to you with the counts, sample and pricing in detail. Note: If you sign up before CHRISTMAS Day, we can provide a discount of 30% on the list purchase. Regards, Melissa Smith Sr. Lead Generation To delist from this mailing list reply with subject line "Remove" ___ 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: sporadic core dumps in 12.0-RELEASE
On Tue, Dec 18, 2018 at 07:34:33AM -0800, Chuck Tuffli wrote:
> Hi
>
> When running 12.0-RELEASE in bhyve, nvmecontrol will core dump sporadically
> in rtld. This is repeatable, but doesn't happen every time. Peeking at
> rlock_acquire(), the function checks for a NULL lockstate and then
> dereferences the lock. The backtrace (below) suggests the lock is NULL but
> the lockstate pointer is not. Does anyone know if this is expected, weird,
> etc.?
This is very weird. If you look at the frame #1, you would see that
rlock_acquire() is called for the rtld_bind_lock, which should point
to rtld_locks[0].
>
> root@freebsd:~ # uname -a
> FreeBSD freebsd 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64
> root@freebsd:~ # /usr/libexec/gdb -q /sbin/nvmecontrol nvmecontrol.core
> Core was generated by `nvmecontrol identify nvme0'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libc.so.7...Reading symbols from
> /usr/lib/debug//lib/libc.so.7.debug...done.
> done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...Reading symbols from
> /usr/lib/debug//libexec/ld-e
> lf.so.1.debug...done.
> done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0 rlock_acquire (lock=0x0, lockstate=0x7fffd9b8)
> at /usr/src/libexec/rtld-elf/rtld_lock.c:203
> 203 /usr/src/libexec/rtld-elf/rtld_lock.c: No such file or directory.
> in /usr/src/libexec/rtld-elf/rtld_lock.c
> (gdb) bt
> #0 rlock_acquire (lock=0x0, lockstate=0x7fffd9b8)
> at /usr/src/libexec/rtld-elf/rtld_lock.c:203
> #1 0x00080021a2fd in _rtld_bind (obj=0x800236000, reloff=528)
> at /usr/src/libexec/rtld-elf/rtld.c:790
> #2 0x00080021704d in _rtld_bind_start ()
> at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121
> #3 0x002087de in identify_ctrlr (argc=2, argv=0x7fffebd0)
> at /usr/src/sbin/nvmecontrol/identify.c:183
> #4 0x002086e0 in identify (argc=2, argv=0x7fffebd0)
> at /usr/src/sbin/nvmecontrol/identify.c:292
> #5 0x00207935 in main (argc=, argv= optimized out>)
> at /usr/src/sbin/nvmecontrol/nvmecontrol.c:89
> #6 0x0020711b in _start (ap=, cleanup= optimized out>)
> at /usr/src/lib/csu/amd64/crt1.c:76
> #7 0x000800236000 in ?? ()
> #8 0x in ?? ()
> Current language: auto; currently minimal
> (gdb) p *lockstate
> $1 = {lockstate = 0, env = 0x7fffd9c0}
> (gdb)
>
> --chuck
> ___
> 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"
___
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"
sporadic core dumps in 12.0-RELEASE
Hi
When running 12.0-RELEASE in bhyve, nvmecontrol will core dump sporadically
in rtld. This is repeatable, but doesn't happen every time. Peeking at
rlock_acquire(), the function checks for a NULL lockstate and then
dereferences the lock. The backtrace (below) suggests the lock is NULL but
the lockstate pointer is not. Does anyone know if this is expected, weird,
etc.?
root@freebsd:~ # uname -a
FreeBSD freebsd 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64
root@freebsd:~ # /usr/libexec/gdb -q /sbin/nvmecontrol nvmecontrol.core
Core was generated by `nvmecontrol identify nvme0'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.7...Reading symbols from
/usr/lib/debug//lib/libc.so.7.debug...done.
done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...Reading symbols from
/usr/lib/debug//libexec/ld-e
lf.so.1.debug...done.
done.
Loaded symbols for /libexec/ld-elf.so.1
#0 rlock_acquire (lock=0x0, lockstate=0x7fffd9b8)
at /usr/src/libexec/rtld-elf/rtld_lock.c:203
203 /usr/src/libexec/rtld-elf/rtld_lock.c: No such file or directory.
in /usr/src/libexec/rtld-elf/rtld_lock.c
(gdb) bt
#0 rlock_acquire (lock=0x0, lockstate=0x7fffd9b8)
at /usr/src/libexec/rtld-elf/rtld_lock.c:203
#1 0x00080021a2fd in _rtld_bind (obj=0x800236000, reloff=528)
at /usr/src/libexec/rtld-elf/rtld.c:790
#2 0x00080021704d in _rtld_bind_start ()
at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121
#3 0x002087de in identify_ctrlr (argc=2, argv=0x7fffebd0)
at /usr/src/sbin/nvmecontrol/identify.c:183
#4 0x002086e0 in identify (argc=2, argv=0x7fffebd0)
at /usr/src/sbin/nvmecontrol/identify.c:292
#5 0x00207935 in main (argc=, argv=)
at /usr/src/sbin/nvmecontrol/nvmecontrol.c:89
#6 0x0020711b in _start (ap=, cleanup=)
at /usr/src/lib/csu/amd64/crt1.c:76
#7 0x000800236000 in ?? ()
#8 0x in ?? ()
Current language: auto; currently minimal
(gdb) p *lockstate
$1 = {lockstate = 0, env = 0x7fffd9c0}
(gdb)
--chuck
___
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"
Unix Users Records
Hi, I'm curious to know if you would be interested in a records of Unix Users for your sales and marketing campaigns. Each Contact Contains: LinkedIn Profile, Company Name, Contact name, Title, Address, Phone, Fax, City, State, Zip codes, Country, Industry, Employee size, Revenue size, Sic Code, Website and verified email address. We are rolling out an exclusive 'Holiday special' along with Q-4 discounts for first time customers. Let me know if you are interested and I will get back to you with the counts, pricing structure and a samples file for your review. Note: We can also customize the list for any specific Technology Users based on your criteria. Best Regards, Caroline Parks Manager-Demand Generation To opt out, please reply with Leave Out in the Subject Line. ___ 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: mps and LSI SAS2308: controller resets on 12.0 - IOC Fault 0x40000d04, Resetting
On 12/18/2018 4:05 AM, Jan Martin Mikkelsen wrote: >> On 17 Dec 2018, at 20:14, Mike Tancsa wrote: >> >> On 12/17/2018 10:52 AM, Mark Martinec wrote: >>> Anyone else seen problems with mps driver and LSI SAS2308 controller? >>> >>> (btw, on another machine the mps driver with LSI SAS2004 is working >>> just fine under 12.0) >> >> Sort of ran into this as well, but with the mfi driver. The same card in >> *some* machines would boot just fine, but in others, it would hang at >> boot time. Not sure if its related or not >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231432 >> >> I was able to get a MegaRAID SAS-3 3108 [Invader] card working by >> forcing it to use the mrsas driver instead of the mfi. However, my >> 9240s fail with the mfi and they will not work with the mrsas >> > Interesting. I have a machine with a 9240 and a 9261 that I have just > upgraded to 12.0 from 10.2 and is working fine with the mfi driver. > > However, the standard machine build procedure here includes: > > hw.mfi.msi=“1” > > in /boot/loader.conf. This was added to our build procedure back in 2011 to > deal with the 9261 not working on FreeBSD 9.0. > > I wonder if using MSI interrupts would help with your problem? Hmmm, that seems to be the default on 11 and 12 % sysctl -A hw.mfi.msi hw.mfi.msi: 1 -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ 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: Address Collision using i386 4G/4G Memory Split
On 18.12.18 11:32, Konstantin Belousov wrote: > On Tue, Dec 18, 2018 at 11:22:53AM +0100, Alexander Lochmann wrote: >> Some context: We are doing VM-based tracing in the FreeBSD kernel. For that, we observe parts of the kernel memory (allocations, accesses,...). Before 12.0 we simply knew that kernel addresses that we logged were unique. Moreover, when a memory access to a region of interest happened we knew that could only be kernel memory. We know have to ensure that we only record memory accesses that happen within the kernel. Our approach is to record the kernels value for the CR3 register, and record memory accesses if the CR3 registers holds the aforementioned value. >>> You must use CPL to see if the current operation mode is user or kernel. >>> If user, nothing should be done (this would avoid vm86). If kernel, you >>> need to compare current %cr3 with IdlePTD (IdlePTDP for PAE case). >>> >> Thanks for the advice! We'll include that in our toolchain. >> Do you use PLs other than 0(=kernel) and 3(=user)? > No, only 0 and 3. But be careful with vm86 (I am not sure how your VM > reports it to your instrumentation). > Ok. Thx! - Alex -- Technische Universität Dortmund Alexander LochmannPGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax:+49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al signature.asc Description: OpenPGP digital signature
Re: Address Collision using i386 4G/4G Memory Split
On Tue, Dec 18, 2018 at 11:22:53AM +0100, Alexander Lochmann wrote: > > >> Some context: We are doing VM-based tracing in the FreeBSD kernel. For > >> that, we observe parts of the kernel memory (allocations, accesses,...). > >> Before 12.0 we simply knew that kernel addresses that we logged were > >> unique. Moreover, when a memory access to a region of interest happened > >> we knew that could only be kernel memory. > >> We know have to ensure that we only record memory accesses that happen > >> within the kernel. > >> Our approach is to record the kernels value for the CR3 register, and > >> record memory accesses if the CR3 registers holds the aforementioned value. > > You must use CPL to see if the current operation mode is user or kernel. > > If user, nothing should be done (this would avoid vm86). If kernel, you > > need to compare current %cr3 with IdlePTD (IdlePTDP for PAE case). > > > Thanks for the advice! We'll include that in our toolchain. > Do you use PLs other than 0(=kernel) and 3(=user)? No, only 0 and 3. But be careful with vm86 (I am not sure how your VM reports it to your instrumentation). ___ 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: Address Collision using i386 4G/4G Memory Split
>> Some context: We are doing VM-based tracing in the FreeBSD kernel. For >> that, we observe parts of the kernel memory (allocations, accesses,...). >> Before 12.0 we simply knew that kernel addresses that we logged were >> unique. Moreover, when a memory access to a region of interest happened >> we knew that could only be kernel memory. >> We know have to ensure that we only record memory accesses that happen >> within the kernel. >> Our approach is to record the kernels value for the CR3 register, and >> record memory accesses if the CR3 registers holds the aforementioned value. > You must use CPL to see if the current operation mode is user or kernel. > If user, nothing should be done (this would avoid vm86). If kernel, you > need to compare current %cr3 with IdlePTD (IdlePTDP for PAE case). > Thanks for the advice! We'll include that in our toolchain. Do you use PLs other than 0(=kernel) and 3(=user)? - Alex -- Technische Universität Dortmund Alexander LochmannPGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax:+49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al signature.asc Description: OpenPGP digital signature
Re: Address Collision using i386 4G/4G Memory Split
On Tue, Dec 18, 2018 at 10:16:35AM +0100, Alexander Lochmann wrote:
> Am 18.12.18 um 06:27 schrieb Konstantin Belousov:
> > On Mon, Dec 17, 2018 at 02:51:48PM +0100, Alexander Lochmann wrote:
> >> Hi folks!
> >>
> >> According to git commit e3089a (https://reviews.freebsd.org/D1463)
> >> FreeBSD 12.0 i386 uses separate address spaces for kernel and user
> >> space. So basically two memory areas, one in each space, can have the
> >> same address.
> >> Is this possible with FreeBSD 12.0? Is this likely to happen?
> > The feature was added to HEAD during this summer, before stable/12 was
> > branched.
> Mhmkay. But how likely is it that two memory areas will get the same
> address?
It is possible.
> Does the kernel, for example, start in the high memory region and the
> user space starts in the mid region?
No, kernel now does not relocate itself, it is running with PA == VA
for text and data segment. Look at the kernel binary to see the
addresses.
> This would reduce the likelihood of two memory areas starting at the
> same virtual address.
I do not see why this would be even slightly needed.
>
> Some context: We are doing VM-based tracing in the FreeBSD kernel. For
> that, we observe parts of the kernel memory (allocations, accesses,...).
> Before 12.0 we simply knew that kernel addresses that we logged were
> unique. Moreover, when a memory access to a region of interest happened
> we knew that could only be kernel memory.
> We know have to ensure that we only record memory accesses that happen
> within the kernel.
> Our approach is to record the kernels value for the CR3 register, and
> record memory accesses if the CR3 registers holds the aforementioned value.
You must use CPL to see if the current operation mode is user or kernel.
If user, nothing should be done (this would avoid vm86). If kernel, you
need to compare current %cr3 with IdlePTD (IdlePTDP for PAE case).
There are moments where kernel is executing on the user page tables.
This happens on kernel entry/exit, and sometimes on copyout(9).
>
> >
> >>
> >> On my opinion, this is also very expensive in terms of performance.
> >> Any copy{in,out} has to flush the TLB.
> >> (http://fxr.watson.org/fxr/source/i386/i386/copyout_fast.s#L91)
> >> Why are you still using this 4G/4G approach?
> > Because it is needed for i386 to self-host, in modern world 1G KVA
> > is too small, and because it provides Meltdown mitigation.
> >
>
> --
> Technische Universität Dortmund
> Alexander LochmannPGP key: 0xBC3EF6FD
> Otto-Hahn-Str. 16 phone: +49.231.7556141
> D-44227 Dortmund fax:+49.231.7556116
> http://ess.cs.tu-dortmund.de/Staff/al
>
___
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: Address Collision using i386 4G/4G Memory Split
Am 18.12.18 um 06:27 schrieb Konstantin Belousov:
> On Mon, Dec 17, 2018 at 02:51:48PM +0100, Alexander Lochmann wrote:
>> Hi folks!
>>
>> According to git commit e3089a (https://reviews.freebsd.org/D1463)
>> FreeBSD 12.0 i386 uses separate address spaces for kernel and user
>> space. So basically two memory areas, one in each space, can have the
>> same address.
>> Is this possible with FreeBSD 12.0? Is this likely to happen?
> The feature was added to HEAD during this summer, before stable/12 was
> branched.
Mhmkay. But how likely is it that two memory areas will get the same
address?
Does the kernel, for example, start in the high memory region and the
user space starts in the mid region?
This would reduce the likelihood of two memory areas starting at the
same virtual address.
Some context: We are doing VM-based tracing in the FreeBSD kernel. For
that, we observe parts of the kernel memory (allocations, accesses,...).
Before 12.0 we simply knew that kernel addresses that we logged were
unique. Moreover, when a memory access to a region of interest happened
we knew that could only be kernel memory.
We know have to ensure that we only record memory accesses that happen
within the kernel.
Our approach is to record the kernels value for the CR3 register, and
record memory accesses if the CR3 registers holds the aforementioned value.
>
>>
>> On my opinion, this is also very expensive in terms of performance.
>> Any copy{in,out} has to flush the TLB.
>> (http://fxr.watson.org/fxr/source/i386/i386/copyout_fast.s#L91)
>> Why are you still using this 4G/4G approach?
> Because it is needed for i386 to self-host, in modern world 1G KVA
> is too small, and because it provides Meltdown mitigation.
>
--
Technische Universität Dortmund
Alexander LochmannPGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16 phone: +49.231.7556141
D-44227 Dortmund fax:+49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al
signature.asc
Description: OpenPGP digital signature
Re: mps and LSI SAS2308: controller resets on 12.0 - IOC Fault 0x40000d04, Resetting
> On 17 Dec 2018, at 20:14, Mike Tancsa wrote: > > On 12/17/2018 10:52 AM, Mark Martinec wrote: >> Anyone else seen problems with mps driver and LSI SAS2308 controller? >> >> (btw, on another machine the mps driver with LSI SAS2004 is working >> just fine under 12.0) > > > Sort of ran into this as well, but with the mfi driver. The same card in > *some* machines would boot just fine, but in others, it would hang at > boot time. Not sure if its related or not > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231432 > > I was able to get a MegaRAID SAS-3 3108 [Invader] card working by > forcing it to use the mrsas driver instead of the mfi. However, my > 9240s fail with the mfi and they will not work with the mrsas > Interesting. I have a machine with a 9240 and a 9261 that I have just upgraded to 12.0 from 10.2 and is working fine with the mfi driver. However, the standard machine build procedure here includes: hw.mfi.msi=“1” in /boot/loader.conf. This was added to our build procedure back in 2011 to deal with the 9261 not working on FreeBSD 9.0. I wonder if using MSI interrupts would help with your problem? Regards, Jan M. ___ 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: Address Collision using i386 4G/4G Memory Split
On Tue, Dec 18, 2018 at 08:34:25AM +, Brooks Davis wrote: > On Mon, Dec 17, 2018 at 03:58:05PM -0500, Kurt Lidl wrote: > > Alexander Lochmann writes: > > > According to git commit e3089a (https://reviews.freebsd.org/D1463) > > > FreeBSD 12.0 i386 uses separate address spaces for kernel and user > > > space. So basically two memory areas, one in each space, can have the > > > same address. > > > Is this possible with FreeBSD 12.0? Is this likely to happen? > > > > If the userspace program and the kernel address happen to overlap, the > > system will deal with it. There's not anything to worry about. As to > > whether or not it's likely to happen -- I'm not sure about that. I > > expect the default stack and heap space locations for a fresh process > > have changed due to this change, but it should not matter. > > 4/4 does potentially alter the failure modes of buggy code that tries to > read directly from userspace addresses. For example, correct calls to > the sysctls fixed in r342125 may panic prior to the fix because the > addresses in question aren't mapped in kernel space. They might also > fail or behave bizarrely if the page is mapped and the value from the > kernel page is used. I believe that SMAP on amd64 is The solution to find such cases, now. And it indeed catched several real cases, e.g. pci(4), acpi_call and vbox from ports, besides the mentioned commit.. ___ 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: Address Collision using i386 4G/4G Memory Split
On Mon, Dec 17, 2018 at 03:58:05PM -0500, Kurt Lidl wrote: > Alexander Lochmann writes: > > According to git commit e3089a (https://reviews.freebsd.org/D1463) > > FreeBSD 12.0 i386 uses separate address spaces for kernel and user > > space. So basically two memory areas, one in each space, can have the > > same address. > > Is this possible with FreeBSD 12.0? Is this likely to happen? > > If the userspace program and the kernel address happen to overlap, the > system will deal with it. There's not anything to worry about. As to > whether or not it's likely to happen -- I'm not sure about that. I > expect the default stack and heap space locations for a fresh process > have changed due to this change, but it should not matter. 4/4 does potentially alter the failure modes of buggy code that tries to read directly from userspace addresses. For example, correct calls to the sysctls fixed in r342125 may panic prior to the fix because the addresses in question aren't mapped in kernel space. They might also fail or behave bizarrely if the page is mapped and the value from the kernel page is used. -- Brooks signature.asc Description: PGP signature
