r344398 Import ACPICA 20190215: breaks bhyve
Hi, most likely r344398[1] commit breaks bhyve with the following errors: Subtable Type : 02 Error6302 - Flag value is too large ^ (Maximum 1 bit) 58: [0002] Flags (decoded below) : 0005 Error6302 - Flag value is too large ^ (Maximum 2 bit) 66: [0004] Interrupt : 0009 Error6302 - Flag value is too large ^ (Maximum 2 bit) Assertion failed: (error == 0), function main, file /usr/src/usr.sbin/bhyve/bhyverun.c, line 1190. Can anyone else confirm this? Howto reproduce: fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/FreeBSD-10.3-RELEASE-amd64-bootonly.iso sh /usr/share/examples/bhyve/vmrun.sh -c 1 -m 1024M -i -I FreeBSD-10.3-RELEASE-amd64-bootonly.iso guestname __ [1] - https://svnweb.freebsd.org/base?view=revision&revision=r344398 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r344398 Import ACPICA 20190215: breaks bhyve
On Thu, Feb 21, 2019 at 8:15 PM Conrad Meyer wrote: > Would you mind filing a PR to track this investigation? Done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235922 Thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freebsd-current@freebsd.org
Hi, This commit https://svnweb.freebsd.org/base?view=revision&revision=r320472 breaks column(1) (and can affect something else this way ). Try to execute sample from man r320472: ( printf "PERM LINKS OWNER GROUP SIZE MONTH DAY " ; printf "HH:MM/YEAR NAME\n" ; ls -l | sed 1d ) | column -t column: line too long ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
segfault from php/freebsd/dtrace
Hi maillist,
I try to use dtrace + php/dtrace on the freebsd. In certain cases ive get
Segmentation fault and don't understand what of subsystem has a problem.
For this purpose:
1) have PHP with DTrace probes, for example:
svn co https://svn.php.net/repository/php/php-src/trunk php-trunk
php-trunk/buildconf ( needs bison && re2c )
php-trunk/configure --enable-dtrace
( then bulds as usual)
2) have FreeBSD with world/kernel Dtrace support
3) Run php for providing dtrace/php probes
% php
4) Execute dtrace with PHP probes, for example, watch the errors:
% dtrace -s /dev/stdin
#pragma D option quiet
php*:::error
{
printf("Error: %s in line %d (%s)\n", copyinstr(arg0), arg2,
copyinstr(arg1));
}
^D
4) Run PHP with some error, for example:
% php -E "thisisit"
^D
Result:
Dtrace ouput (this is ok):
Error: syntax error, unexpected end of file in line 1 (Command line end code)
% php -E "thisisit"
Segmentation fault (core dumped)
% gdb -c ./php.core /usr/local/bin/php
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols
found)...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libelf.so.1
Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols
found)...done.
Loaded symbols for /usr/local/lib/libxml2.so.5
Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols
found)...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0008021c6a37 in strlen () from /lib/libc.so.7
[New Thread 802807400 (LWP 100326/php)]
(gdb) file
No executable file now.
/usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c:484: internal-error:
fbsd_thread_new_objfile: Assertion `proc_handle.pid == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
/usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c:484: internal-error:
fbsd_thread_new_objfile: Assertion `proc_handle.pid == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
(gdb) bt
#0 0x0008021c6a37 in ?? () from /lib/libc.so.7
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/dwarf2-
frame.c:613: internal-error: dwarf2_frame_cache: Assertion `fde != NULL'
failed.
Backtrace for php.core:
fbsd-strace# gdb -c ./php.core /usr/local/bin/php
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols
found)...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libelf.so.1
Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading sym
segfault from php/freebsd/dtrace
Hi maillist,
I try to use dtrace + php/dtrace on the freebsd. In certain cases ive get
Segmentation fault and don't understand what of subsystem has a problem.
For this purpose:
1) have PHP with DTrace probes, for example:
svn co https://svn.php.net/repository/php/php-src/trunk php-trunk
php-trunk/buildconf ( needs bison && re2c )
php-trunk/configure --enable-dtrace
( then bulds as usual)
2) have FreeBSD with world/kernel Dtrace support
3) Run php for providing dtrace/php probes
% php
4) Execute dtrace with PHP probes, for example, watch the errors:
% dtrace -s /dev/stdin
#pragma D option quiet
php*:::error
{
printf("Error: %s in line %d (%s)\n", copyinstr(arg0), arg2,
copyinstr(arg1));
}
^D
4) Run PHP with some error, for example:
% php -E "thisisit"
^D
Result:
Dtrace ouput (this is ok):
Error: syntax error, unexpected end of file in line 1 (Command line end code)
% php -E "thisisit"
Segmentation fault (core dumped)
% gdb -c ./php.core /usr/local/bin/php
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols
found)...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libelf.so.1
Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols
found)...done.
Loaded symbols for /usr/local/lib/libxml2.so.5
Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols
found)...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0008021c6a37 in strlen () from /lib/libc.so.7
[New Thread 802807400 (LWP 100326/php)]
(gdb) file
No executable file now.
/usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c:484: internal-error:
fbsd_thread_new_objfile: Assertion `proc_handle.pid == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
/usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c:484: internal-error:
fbsd_thread_new_objfile: Assertion `proc_handle.pid == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
(gdb) bt
#0 0x0008021c6a37 in ?? () from /lib/libc.so.7
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/dwarf2-
frame.c:613: internal-error: dwarf2_frame_cache: Assertion `fde != NULL'
failed.
Backtrace for php.core:
fbsd-strace# gdb -c ./php.core /usr/local/bin/php
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols
found)...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libelf.so.1
Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading sym
Re: segfault from php/freebsd/dtrace
On Saturday 31 December 2011 23:25:51 Ryan Stone wrote:
> On Thu, Dec 29, 2011 at 12:37 PM, Oleg Ginzburg wrote:
> > Hi maillist,
> >
> > I try to use dtrace + php/dtrace on the freebsd. In certain cases ive get
> > Segmentation fault and don't understand what of subsystem has a problem.
>
> Yes, Userland DTrace is unfortunately still very experimental at this
> point. I've got a list of at least 10 outstanding bugs that I hope to
> start addressing early in the new year.
>
> In your case, dtrace(1) and/or libproc does not clean up after itself
> properly in the case of an error.
I can assume that it is:
--//Cut of /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c//--
if (fbsd_thread_active)
{
gdb_assert (proc_handle.pid == 0); << Here is 484 string mentioned
by backtrace <<
fbsd_thread_active = 0;
}
---
related with the first process php which I start for providing php dtrace
probes. Thanks to this process other code passes through php/dtrace and this
process doesn't stop.
Last action by backtrace is:
#0 0x0008021c6a37 in strlen () from /lib/libc.so.7
Unfortunately at the expense of DEBUG symbols, process have a bit more memory,
so this problem isn't present and i couldn't see value of variables in this
place and whence it is caused.
> I'm not entirely sure what is
> causing the segfault in php, though. Which version are you running?
> The output of uname -a would be helpful.
At the moment of test (on December, 23th) it there was last version 9-
RELENG/amd64 from SVN
%uname -a:
FreeBSD fbsd-strace.my.domain 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Fri
Dec 23 16:56:09 MSK 2011 r...@t.my.domain:/usr/obj/usr/src/sys/G-DTRACE
amd64
Kernel config:
%cat /sys/amd64/conf/G-DTRACE
include GENERIC
ident G-DTRACE
options KDTRACE_HOOKS# all architectures - enable general DTrace hooks
options DDB_CTF # all architectures - kernel ELF linker loads CTF
data
options KDTRACE_FRAME# amd64 - ensure frames are compiled in
makeoptions WITH_CTF=1
#nomakeoptions DEBUG
#nooptions COMPAT_FREEBSD4 # Compatible with FreeBSD4
#nooptions COMPAT_FREEBSD5 # Compatible with FreeBSD5
#nooptions COMPAT_FREEBSD6 # Compatible with FreeBSD6
#nooptions COMPAT_FREEBSD7 # Compatible with FreeBSD7
%cat /etc/make.conf
WITH_CTF=1
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: make_dev_credv when lindev module is loaded on the recent revision
Hi,
Current problem has arisen in the last four days in FreeBSD head.
When load lindev modules began to emerge follow panic:
Unread portion of the kernel message buffer:
panic: make_dev_credv: bad si_name (error=17, si_name=full)
cpuid = 1
Uptime: 30s
Dumping 431 out of 8045 MB:..4%..12%..23%..34%..41%..52%..64%..71%..82%..93%
Reading symbols from /boot/kernel/libalias.ko.symbols...done.
Loaded symbols for /boot/kernel/libalias.ko.symbols
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
Reading symbols from /boot/kernel/linsysfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linsysfs.ko.symbols
Reading symbols from /boot/kernel/if_bridge.ko.symbols...done.
Loaded symbols for /boot/kernel/if_bridge.ko.symbols
Reading symbols from /boot/kernel/bridgestp.ko.symbols...done.
Loaded symbols for /boot/kernel/bridgestp.ko.symbols
Reading symbols from /boot/kernel/if_tap.ko.symbols...done.
Loaded symbols for /boot/kernel/if_tap.ko.symbols
Reading symbols from /boot/kernel/vmm.ko.symbols...done.
Loaded symbols for /boot/kernel/vmm.ko.symbols
Reading symbols from /boot/kernel/aio.ko.symbols...done.
Loaded symbols for /boot/kernel/aio.ko.symbols
Reading symbols from /boot/kernel/cc_htcp.ko.symbols...done.
Loaded symbols for /boot/kernel/cc_htcp.ko.symbols
Reading symbols from /boot/modules/cuse4bsd.ko...done.
Loaded symbols for /boot/modules/cuse4bsd.ko
Reading symbols from /boot/kernel/crypto.ko.symbols...done.
Loaded symbols for /boot/kernel/crypto.ko.symbols
Reading symbols from /boot/kernel/cryptodev.ko.symbols...done.
Loaded symbols for /boot/kernel/cryptodev.ko.symbols
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/kernel/sem.ko.symbols...done.
Loaded symbols for /boot/kernel/sem.ko.symbols
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/kernel/accf_data.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_data.ko.symbols
Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_http.ko.symbols
Reading symbols from /boot/kernel/cpuctl.ko.symbols...done.
Loaded symbols for /boot/kernel/cpuctl.ko.symbols
Reading symbols from /boot/kernel/uhid.ko.symbols...done.
Loaded symbols for /boot/kernel/uhid.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
Reading symbols from /boot/modules/vboxnetflt.ko...done.
Loaded symbols for /boot/modules/vboxnetflt.ko
Reading symbols from /boot/kernel/netgraph.ko.symbols...done.
Loaded symbols for /boot/kernel/netgraph.ko.symbols
Reading symbols from /boot/kernel/ng_ether.ko.symbols...done.
Loaded symbols for /boot/kernel/ng_ether.ko.symbols
Reading symbols from /boot/modules/vboxnetadp.ko...done.
Loaded symbols for /boot/modules/vboxnetadp.ko
Reading symbols from /boot/kernel/pf.ko.symbols...done.
Loaded symbols for /boot/kernel/pf.ko.symbols
Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
Loaded symbols for /boot/kernel/nullfs.ko.symbols
Reading symbols from /boot/kernel/fdescfs.ko.symbols...done.
Loaded symbols for /boot/kernel/fdescfs.ko.symbols
Reading symbols from /boot/kernel/lindev.ko.symbols...done.
Loaded symbols for /boot/kernel/lindev.ko.symbols
#0 doadump (textdump=) at pcpu.h:219
219 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0 doadump (textdump=) at pcpu.h:219
#1 0x80944db8 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:449
#2 0x80945237 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:756
#3 0x808e4e8d in make_dev_credv (flags=,
dres=, devsw=, unit=,
cr=,
uid=, mode=) at
/usr/src/sys/kern/kern_conf.c:763
#4 0x808e4aa7 in make_dev (devsw=0x0, unit=0, uid=0, gid=, mode=, fmt=) at
/usr/src/sys/kern/kern_conf.c:820
#5 0x8265b083 in lindev_modevent_full (mod=,
type=, data=)
at /usr/src/sys/modules/lindev/../../dev/lindev/full.c:83
#6 0x80927ae2 in module_register_init (arg=0x8265b2b0) at
/usr/src/sys/kern/kern_module.c:123
#7 0x8091b364 in linker_load_module (kldname=,
modname=0xf80005b46400 "lindev", parent=0x0, verinfo=0x0,
lfpp=0xfe02325a6940)
at /usr/src/sys/kern/kern_linker.c:225
#8 0x8091cdef in kern_kldload (td=, file=, fileid=0xfe02325a6984) at
/usr/src/sys/kern/kern_linker.c:1030
#9 0x8091cf2b in sys_kldload (td=0xf80008729920, uap=) at /usr/src/sys/kern/kern_linker.c:1056
#10 0x80d9ecab in amd64_syscall (td=0xf80008729920, traced=0) at
subr_syscall.c:133
#11 0x80d8113b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:390
#12 0x00080088e9ea in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) list
troubles with 9.0 beta2 installer
Hi Some trouble in FreeBSD 9.0-beta2 Installer: a) Infinity loop of Dialog in Network Configuration stage when static IP selected without default gw: How to reproduce: Would you like to configure IPv4 for this interface - (set Y) Would you like to use DHCP to configure this interface - (set N) IP Address: (set 10.0.0.1 for example) Subnet Mask: (set 255.255.255.0 for example) Default Router: (leave blank) - After this, installer teleport to select interfaces dialog silenty b) Installer helpless where GPT table is broken: How to reproduce: 1) Install fresh system by default (GPT table) 2) Reboot in liveCD mode and overwrite last bytes (where GPT have backup). For exampe by gmirror label: gmirror label -v -b round-robin data ada0 3) Reboot with the installer and try install system by default to get a lot of windows without options: "Error: Operation not permitted. table ada0 is corrupt" "Error: Device busy" "Operation not permtted" "File exists. geom 'ada0'" this situation require LiveCD shell with "gpt recover" command ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VNET jail and dhclient
in reply to https://lists.freebsd.org/pipermail/freebsd-jail/2017-October/003444.html comment: it looks like it's a regression in FreeBSD 12/Current, because in FreeBSD 11 dhclient works fine: -- jail1:/root@[15:16] # dhclient eth0 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 DHCPOFFER from 192.168.10.1 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from 192.168.10.1 bound to 192.168.8.8 -- renewal in 900 seconds. jail1:/root@[15:16] # uname -a FreeBSD jail1.my.domain 11.0-RELEASE-p12 FreeBSD 11.0-RELEASE-p12 #0 r324489: Tue Oct 10 14:57:58 MSK 2017 r...@f10.my.domain:/usr/obj/usr/jails/src/src_11.0/src/sys/VIMAGE amd64 -- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VNET jail and dhclient
Hello!
On Tue, Oct 10, 2017 at 8:24 PM, Kristof Provost wrote:
> On 9 Oct 2017, at 9:25, Goran Mekić wrote:
> > Hello,
> >
> > TLDR: I can setup static IP or use dhcpcd to get address, but not
> dhclient.
> >
> > Let me elaborate. I run 12-CURRENT on my laptop and use CBSD as jail
> manager (I don't think it matters).
> >
> What version of CURRENT are you using?
>
> > # dhclient eth0
> > chroot
> > exiting.
> >
> > This is what I found with truss: https://gist.github.com/anonymous/
> 36a4e2bf1760198971934ff609a7d0de#file-gistfile1-txt-L227-L228. Selected
> lines are what I think is the problem. Offending line in the code is
> probably https://svnweb.freebsd.org/base/head/sbin/dhclient/
> dhclient.c?revision=317915&view=markup#l507. With that asumption, Oleg,
> CBSD author, noticed that the following "patch" works:
> >
> Is there any chance you don’t have /var/empty in your jail?
>
> I do this to create a simple vnet jail:
> sudo jail -c name=alcatraz persist vnet vnet.interface=epair0b
> (in the jail) dhclient epair0b
>
> And see:
> …
> fsync(0x9) = 0 (0x0)
> close(8) = 0 (0x0)
> socket(PF_ROUTE,SOCK_RAW,0) = 8 (0x8)
> shutdown(8,SHUT_WR) = 0 (0x0)
> cap_rights_limit(8,{ CAP_READ,CAP_EVENT }) = 0 (0x0)
> chroot("/var/empty") = 0 (0x0)
> chdir("/") = 0 (0x0)
> setgroups(0x1,0x800e2c1e4) = 0 (0x0)
> …
>
> I also see the DCHP request packets on the other end of the epair
> interface.
>
> Regards,
> Kristof
>
What is your FreeBSD version? This problem reproduced on FreeBSD 12 only.
/var/empty is exist and trivial test:
#include
#include
int main()
{
printf("%d\n",chroot("/var/empty");
}
works successfully.
I think I found something, but I do not understand why this is only
observed in jail and with commit change this.
The problem about which the Goran wrote can be fixed with:
# diff -ruN dhclient.c-orig dhclient.c
--- dhclient.c-orig 2017-10-10 23:51:52.451361000 +
+++ dhclient.c 2017-10-10 23:54:55.803404000 +
@@ -479,6 +479,7 @@
fork_privchld(pipe_fd[0], pipe_fd[1]);
+ pidfile_close(pidfile);
close(ifi->ufdesc);
ifi->ufdesc = -1;
close(ifi->wfdesc);
From pidfile(3) man page:
The pidfile_close() function closes a pidfile. It should be used after
daemon fork()s to start a child process.
chroot(2) in dhclient return NOPERM (via global errno). it seems to be
related to open descriptor outside the chroot.
I'm not sure if this fd leak (due to pidfile_remove at the end of
dhclient), nevertheless closing pid fd in my jail/FreeBSD12 before chroot
solve dhclient issue.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
emulators/virtualbox-kmod: turn on VIMAGE by default for FreeBSD 12+
Hello,
With this change:
https://svnweb.freebsd.org/base?view=revision&revision=324810 I think
should also set VIMAGE options by default in emulators/virtualbox-kmod port
for FreeBSD 12+ via
.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1200051
or by separated meta port ( FLAVOR can help?) :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215336
Without this change we will get panic on FreeBSD 12 + virtualbox-kmod on
boot.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r328032 broke service
Looks like https://svnweb.freebsd.org/base?view=revi sion&revision=r328032 breaks any other arguments except '-j' for service(8) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fatal trap 12: if_io_tqg_11: ~main-n248851-0d55bc8eb2a:
Hi,
One of my regularly updated hosts on the 14-CURRENT started to reboot
constantly when initializing the network stack (both IPv4/V6 stacks are
active), current rev: ( 22997b755013bdde60119fdc781769192ab7e1e0 Sat Aug 7
21:25:36 2021 +0100 )
crash info:
--
...
<118>Starting devd.
<118>Starting Network: igb1.
<118>igb1: flags=8822 metric 0 mtu 1500
<118>
options=4e507bb
<118> ether b4:96:91:95:97:ed
Fatal trap 12: page fault while in kernel mode
cpuid = 11; apic id = 0b
fault virtual address = 0x128
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80c1effd
stack pointer = 0x28:0xfe01159efeb0
frame pointer = 0x28:0xfe01159efeb0
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 = 0 (if_io_tqg_11)
trap number = 12
panic: page fault
cpuid = 11
time = 1629661329
Uptime: 1m14s
Dumping 2158 out of 65309
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/jails/src/src_14/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb)
(kgdb) list *0x80c1effd
0x80c1effd is in __rw_rlock_int
(/usr/jails/src/src_14/src/sys/kern/kern_rwlock.c:679).
674 KASSERT(rw_wowner(rw) != td,
675 ("rw_rlock: wlock already held for %s @ %s:%d",
676 rw->lock_object.lo_name, file, line));
677 WITNESS_CHECKORDER(&rw->lock_object, LOP_NEWORDER, file,
line, NULL);
678
679 v = RW_READ_VALUE(rw);
680 if (__predict_false(LOCKSTAT_PROFILE_ENABLED(rw__acquire) ||
681 !__rw_rlock_try(rw, td, &v, true LOCK_FILE_LINE_ARG)))
682 __rw_rlock_hard(rw, td, v LOCK_FILE_LINE_ARG);
683 else
--
I haven’t looked at the details so far, perhaps you have comments on the
latest changes. Latest revision that works successfully: n246318-163153c2a08
( the host is updated approximately once a week )
Re: Fatal trap 12: if_io_tqg_11: ~main-n248851-0d55bc8eb2a:
Please ignore this. updating to the latest revision fixed the problem.
On Sun, Aug 22, 2021 at 11:12 PM Oleg Ginzburg wrote:
> Hi,
>
> One of my regularly updated hosts on the 14-CURRENT started to reboot
> constantly when initializing the network stack (both IPv4/V6 stacks are
> active), current rev: ( 22997b755013bdde60119fdc781769192ab7e1e0 Sat Aug 7
> 21:25:36 2021 +0100 )
>
> crash info:
> --
> ...
> <118>Starting devd.
> <118>Starting Network: igb1.
> <118>igb1: flags=8822 metric 0 mtu 1500
> <118>
>
> options=4e507bb
>
> <118> ether b4:96:91:95:97:ed
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 11; apic id = 0b
> fault virtual address = 0x128
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x80c1effd
> stack pointer = 0x28:0xfe01159efeb0
> frame pointer = 0x28:0xfe01159efeb0
> 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 = 0 (if_io_tqg_11)
> trap number = 12
> panic: page fault
> cpuid = 11
> time = 1629661329
> Uptime: 1m14s
> Dumping 2158 out of 65309
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>
> __curthread () at /usr/jails/src/src_14/src/sys/amd64/include/pcpu_aux.h:55
>
> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(
> struct pcpu,
> (kgdb)
>
> (kgdb) list *0x80c1effd
> 0x80c1effd is in __rw_rlock_int
> (/usr/jails/src/src_14/src/sys/kern/kern_rwlock.c:679).
> 674 KASSERT(rw_wowner(rw) != td,
> 675 ("rw_rlock: wlock already held for %s @ %s:%d",
> 676 rw->lock_object.lo_name, file, line));
> 677 WITNESS_CHECKORDER(&rw->lock_object, LOP_NEWORDER, file,
> line, NULL);
> 678
> 679 v = RW_READ_VALUE(rw);
> 680 if (__predict_false(LOCKSTAT_PROFILE_ENABLED(rw__acquire)
> ||
> 681 !__rw_rlock_try(rw, td, &v, true LOCK_FILE_LINE_ARG)))
> 682 __rw_rlock_hard(rw, td, v LOCK_FILE_LINE_ARG);
> 683 else
>
>
> --
>
>
> I haven’t looked at the details so far, perhaps you have comments on the
> latest changes. Latest revision that works successfully: n246318-163153c2a08
> ( the host is updated approximately once a week )
>
>
>
