Re: Possible deadlock on IO / page fault
Thank you, Kostya and Mark! I will update to head. :) On Tue, Sep 29, 2020 at 4:32 PM Mark Johnston wrote: > On Tue, Sep 29, 2020 at 04:20:26PM +0300, Konstantin Belousov wrote: > > On Tue, Sep 29, 2020 at 02:59:43PM +0300, Michael Zhilin wrote: > > > Hi, > > > > > > I'm using FreeBSD 13-CURRENT (pre-ZoF, r359724) on my laptop with > installed > > > Gnome. Sometimes > > > (once a week/month) gnome hangs and the system may be still responsible > > > (may be not). > > > This week it happened again and I've gathered information via > ddb/textdump > > > and rebooted laptop. > > > > > > gnome-shell is trying to get exclusive lock on some directory > according to > > > information > > > from "show alllocks" and "bt": > > > > > > [...] > > > Tracing command evolution pid 4536 tid 101436 td 0xfe00bf484c00 > > > sched_switch() at sched_switch+0x5b2/frame 0xfe00bfd446e0 > > > mi_switch() at mi_switch+0x155/frame 0xfe00bfd44700 > > > sleepq_switch() at sleepq_switch+0x11a/frame 0xfe00bfd44740 > > > _cv_wait() at _cv_wait+0x15a/frame 0xfe00bfd447a0 > > > rangelock_enter() at rangelock_enter+0x306/frame 0xfe00bfd447f0 > > This call to rangelock_enter() looks suspicious. This is a call to ZFS > > own rangelocks, not our rangelocks. Still, if write took rangelock on > the > > same range, we get a deadlock due to LoR between rangelock and page busy. > > This was fixed by r361287. In particular zfs_getpages() will no longer > block on the ZFS range lock, exactly because of this deadlock. So I > would suggest updating to that revision or later. > > > > zfs_freebsd_getpages() at zfs_freebsd_getpages+0x14f/frame > > > 0xfe00bfd448a0 > > > vnode_pager_getpages() at vnode_pager_getpages+0x37/frame > > > 0xfe00bfd448e0 > > > vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame > 0xfe00bfd44930 > > > vm_fault() at vm_fault+0x780/frame 0xfe00bfd44a40 > > > vm_fault_trap() at vm_fault_trap+0x6e/frame 0xfe00bfd44a80 > > > trap_pfault() at trap_pfault+0x1ee/frame 0xfe00bfd44ae0 > > > trap() at trap+0x44c/frame 0xfe00bfd44bf0 > > > calltrap() at calltrap+0x8/frame 0xfe00bfd44bf0 > > > --- trap 0xc, rip = 0x80a55de3f, rsp = 0x7fffcc60, rbp = > > > 0x7fffcc60 --- > ___ 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"
Possible deadlock on IO / page fault
Hi, I'm using FreeBSD 13-CURRENT (pre-ZoF, r359724) on my laptop with installed Gnome. Sometimes (once a week/month) gnome hangs and the system may be still responsible (may be not). This week it happened again and I've gathered information via ddb/textdump and rebooted laptop. gnome-shell is trying to get exclusive lock on some directory according to information from "show alllocks" and "bt": Process 2355 (gnome-shell) thread 0xfe00b03d4700 (100483) exclusive lockmgr zfs (zfs) r = 0 (0xf802112fe808) locked @ /usr/src/sys/kern/vfs_subr.c:2930 Tracing command gnome-shell pid 2355 tid 100483 td 0xfe00b03d4700 sched_switch() at sched_switch+0x5b2/frame 0xfe00aeff7220 mi_switch() at mi_switch+0x155/frame 0xfe00aeff7240 sleepq_switch() at sleepq_switch+0x11a/frame 0xfe00aeff7280 sleeplk() at sleeplk+0x106/frame 0xfe00aeff72e0 lockmgr_xlock_hard() at lockmgr_xlock_hard+0x21f/frame 0xfe00aeff7380 _vn_lock() at _vn_lock+0x54/frame 0xfe00aeff73e0 zfs_lookup() at zfs_lookup+0x5f7/frame 0xfe00aeff74c0 zfs_freebsd_cachedlookup() at zfs_freebsd_cachedlookup+0x8e/frame 0xfe00aeff7600 vfs_cache_lookup() at vfs_cache_lookup+0xa8/frame 0xfe00aeff7650 lookup() at lookup+0x5e1/frame 0xfe00aeff76f0 namei() at namei+0x524/frame 0xfe00aeff77e0 vn_open_cred() at vn_open_cred+0x10b/frame 0xfe00aeff7930 kern_openat() at kern_openat+0x1fa/frame 0xfe00aeff7aa0 filemon_wrapper_openat() at filemon_wrapper_openat+0x15/frame 0xfe00aeff7ad0 amd64_syscall() at amd64_syscall+0x140/frame 0xfe00aeff7bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00aeff7bf0 --- syscall (499, FreeBSD ELF64, filemon_wrapper_openat), rip = 0x80148dbca, rsp = 0x7fffe248, rbp = 0x7fffe2c0 --- Line vfs_subr.c:2930 mentioned by lockmgr is part of vget_finish. I've found blocked stack with shared lock request: Tracing command gsd-color pid 2422 tid 100784 td 0xfe00b08e0700 sched_switch() at sched_switch+0x5b2/frame 0xfe00b07084f0 mi_switch() at mi_switch+0x155/frame 0xfe00b0708510 sleepq_switch() at sleepq_switch+0x11a/frame 0xfe00b0708550 sleeplk() at sleeplk+0x106/frame 0xfe00b07085b0 lockmgr_slock_hard() at lockmgr_slock_hard+0x1ce/frame 0xfe00b0708640 _vn_lock() at _vn_lock+0x54/frame 0xfe00b07086a0 vget_finish() at vget_finish+0x42/frame 0xfe00b07086d0 cache_lookup() at cache_lookup+0x57c/frame 0xfe00b0708790 vfs_cache_lookup() at vfs_cache_lookup+0x7d/frame 0xfe00b07087e0 lookup() at lookup+0x5e1/frame 0xfe00b0708880 namei() at namei+0x524/frame 0xfe00b0708970 kern_accessat() at kern_accessat+0x106/frame 0xfe00b0708ad0 amd64_syscall() at amd64_syscall+0x140/frame 0xfe00b0708bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00b0708bf0 --- syscall (33, FreeBSD ELF64, sys_access), rip = 0x800fd0eba, rsp = 0x7fffe268, rbp = 0x7fffe380 --- All other locked threads look more interesting. Thread 100747 is trying to write into file and waiting for page, but thread 101436 is trying to handle page fault and waiting for a shared lock of locked_range due to present writer. I suppose it's deadlock caused all troubles. Tracing command dconf-service pid 2384 tid 100747 td 0xfe00b08cc000 sched_switch() at sched_switch+0x5b2/frame 0xfe00b0d762e0 mi_switch() at mi_switch+0x155/frame 0xfe00b0d76300 sleepq_switch() at sleepq_switch+0x11a/frame 0xfe00b0d76340 _vm_page_busy_sleep() at _vm_page_busy_sleep+0x110/frame 0xfe00b0d76390 vm_page_acquire_unlocked() at vm_page_acquire_unlocked+0x177/frame 0xfe00b0d763f0 vm_page_grab_valid_unlocked() at vm_page_grab_valid_unlocked+0x51/frame 0xfe00b0d76430 zfs_freebsd_write() at zfs_freebsd_write+0x9b6/frame 0xfe00b0d76640 VOP_WRITE_APV() at VOP_WRITE_APV+0xa7/frame 0xfe00b0d76750 vn_write() at vn_write+0x2a4/frame 0xfe00b0d767d0 vn_io_fault_doio() at vn_io_fault_doio+0x43/frame 0xfe00b0d76830 vn_io_fault1() at vn_io_fault1+0x16c/frame 0xfe00b0d76980 vn_io_fault() at vn_io_fault+0x182/frame 0xfe00b0d769f0 dofilewrite() at dofilewrite+0x81/frame 0xfe00b0d76a40 kern_pwritev() at kern_pwritev+0x62/frame 0xfe00b0d76a80 sys_pwrite() at sys_pwrite+0x8a/frame 0xfe00b0d76ad0 amd64_syscall() at amd64_syscall+0x140/frame 0xfe00b0d76bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00b0d76bf0 --- syscall (476, FreeBSD ELF64, sys_pwrite), rip = 0x8007428ca, rsp = 0x7fffdf08, rbp = 0x7fffdf20 --- Tracing command evolution pid 4536 tid 101436 td 0xfe00bf484c00 sched_switch() at sched_switch+0x5b2/frame 0xfe00bfd446e0 mi_switch() at mi_switch+0x155/frame 0xfe00bfd44700 sleepq_switch() at sleepq_switch+0x11a/frame 0xfe00bfd4474
Re: jails, ZFS, deprecated jail variables and poudriere problems
Hi, I have no tried (but it's in progress) this article: http://zero-knowledge.org/post/126/ Hope it will help (for me too). Thanks! On Tue, Aug 27, 2019 at 11:25 AM O. Hartmann wrote: > Hello list, > > trying to setup a poudriere jail on recent CURRENT and have some severe > trouble. > > We have a single ZFS pool (raidz), call it pool00 and this pool00 conatins > a > ZFS dataset pool00/poudriere which we want to exclusively attach to a jail. > pool00/poudriere contains a complete clone of a former, now decomissioned > machine and is usable by the host bearing the jails. The jail, named > poudriere, > has these config parameters set in /etc/jail.conf as recommended: > > enforce_statfs= "0"; > > allow.raw_sockets= "1"; > > allow.mount="1"; > allow.mount.zfs="1"; > allow.mount.devfs= "1"; > allow.mount.fdescfs="1"; > allow.mount.procfs= "1"; > allow.mount.nullfs= "1"; > allow.mount.fusefs= "1"; > > Here I find the first confusing observation. I can't interact with the > dataset > and its content within the jail. I've set the "jailed" property of > pool00/poudriere via "zfs set jailed=on pool00/poudriere" and I also have > to > attach the jailed dataset manually via "zfs jail poudriere > pool00/poudriere" to > the (running) jail. But within the jail, listing ZFS's mountpoints reveal: > > NAMEUSED AVAIL REFER MOUNTPOINT > pool00 124G 8.62T 34.9K /pool00 > pool00/poudriere 34.9K 8.62T 34.9K /pool/poudriere > > but nothing below /pool/poudriere is visible to the jail. Being confused I > tried to check the appropriate security variables and found a set of sysctl > OIDs, which seem to have no documentation entry, like > > security.jail.param.allow.mount.zfs: 0 > and a counterpart > security.jail.mount_zfs_allowed: 1 > > Checking the description of security.jail.mount_zfs_allowed tells me that > this > OID is deprecated: > > security.jail.mount_zfs_allowed: Jail may mount the zfs file system > (deprecated) > > So, we tried to set > > param.allow.mount.zfs=1 > > via /etc/jail.conf for the propper jail, but this results in an error. I > can't > find anything in jail(8) about these new ".param." OIDs, so maybe my > trouble is > rooting in here. > > Is there a howto for the novices on howto setup a jail with ZFS > capabilities > needed for poudriere with ZFS? > > Thank you in advance, > > oh > > > ___ > 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel panic in wireless-related sysctl walk
I'm not lucky to reproduce it even if i use iwn and "sysctl net.wlan.0.rate_stats" Problem is related to 802.11n, but all my networks are 11g. BR On Thu, Jan 10, 2019 at 6:53 PM Michael Zhilin wrote: > Hi, > > Is it possible to print out any local variables of frame #8? > > Thx! > > On Thu, Jan 10, 2019 at 6:31 PM Michael Butler > wrote: > >> With 'device iwn' and all the related wireless bits compiled into a >> custom kernel for a laptop, executing 'sysctl -a' yields a kernel panic >> of the form .. >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x8 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0x809bf22c >> stack pointer = 0x28:0xfe0097fb7660 >> frame pointer = 0x28:0xfe0097fb7670 >> 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 = 11053 (sysctl) >> trap number = 12 >> panic: page fault >> cpuid = 1 >> time = 1547129798 >> Uptime: 3d10h27m14s >> Dumping 3840 out of 16258 >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >> >> [ .. ] >> >> (kgdb) #0 doadump (textdump=) at pcpu.h:230 >> #1 0x808704eb in kern_reboot (howto=260) >> at /usr/src/sys/kern/kern_shutdown.c:451 >> #2 0x80870920 in vpanic (fmt=, >> ap=) at /usr/src/sys/kern/kern_shutdown.c:877 >> #3 0x80870753 in panic (fmt=) >> at /usr/src/sys/kern/kern_shutdown.c:804 >> #4 0x80c63b5b in trap_fatal (frame=0xfe0097fb75a0, eva=8) >> at /usr/src/sys/amd64/amd64/trap.c:929 >> #5 0x80c63f10 in trap_pfault (frame=0xfe0097fb75a0, >> usermode=0) >> at /usr/src/sys/amd64/amd64/trap.c:839 >> #6 0x80c632be in trap (frame=0xfe0097fb75a0) >> at /usr/src/sys/amd64/amd64/trap.c:441 >> #7 0x80c40535 in calltrap () >> at /usr/src/sys/amd64/amd64/exception.S:232 >> #8 0x809bf22c in amrr_node_stats (ni=0xfe008cf83000, >> s=0xfe0097fb76f0) at /usr/src/sys/net80211/ieee80211_amrr.c:464 >> #9 0x809ef9f4 in ieee80211_ratectl_sysctl_stats_node_iter ( >> arg=0xfe0097fb76f0, ni=0xfe008cf83000) at >> ieee80211_ratectl.h:170 >> #10 0x809e42b0 in ieee80211_iterate_nodes_vap ( >> nt=, vap=, >> f=0x809ef9b0 , >> arg=0xfe0097fb76f0) at /usr/src/sys/net80211/ieee80211_node.c:2558 >> #11 0x809ef941 in ieee80211_ratectl_sysctl_stats ( >> oidp=, arg1=, >> arg2=, req=) >> at /usr/src/sys/net80211/ieee80211_ratectl.c:99 >> #12 0x8087f8ab in sysctl_root_handler_locked >> (oid=0xf80016697d00, >> arg1=0xf80007bef000, arg2=0, req=0xfe0097fb7840, >> tracker=0xfe0097fb77b8) at /usr/src/sys/kern/kern_sysctl.c:166 >> #13 0x8087ef4f in sysctl_root (arg1=0xf80007bef000, arg2=0, >> req=0xfe0097fb7840) at /usr/src/sys/kern/kern_sysctl.c:2080 >> #14 0x8087f5ca in userland_sysctl (td=0xf80007d96000, >> name=0xfe0097fb7900, namelen=4, old=, >> oldlenp=, inkernel=, >> new=0x0, >> newlen=0, retval=0xfe0097fb7968, flags=0) >> at /usr/src/sys/kern/kern_sysctl.c:2175 >> #15 0x8087f40f in sys___sysctl (td=0xf80007d96000, >> uap=0xf80007d963c0) at /usr/src/sys/kern/kern_sysctl.c:2110 >> #16 0x80c64742 in amd64_syscall (td=0xf80007d96000, traced=0) >> at subr_syscall.c:135 >> #17 0x80c40e1d in fast_syscall_common () >> at /usr/src/sys/amd64/amd64/exception.S:504 >> >> What other data should I capture to assist in identifying and resolving >> this? >> >> imb >> ___ >> 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kernel panic in wireless-related sysctl walk
Hi, Is it possible to print out any local variables of frame #8? Thx! On Thu, Jan 10, 2019 at 6:31 PM Michael Butler wrote: > With 'device iwn' and all the related wireless bits compiled into a > custom kernel for a laptop, executing 'sysctl -a' yields a kernel panic > of the form .. > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x809bf22c > stack pointer = 0x28:0xfe0097fb7660 > frame pointer = 0x28:0xfe0097fb7670 > 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 = 11053 (sysctl) > trap number = 12 > panic: page fault > cpuid = 1 > time = 1547129798 > Uptime: 3d10h27m14s > Dumping 3840 out of 16258 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > [ .. ] > > (kgdb) #0 doadump (textdump=) at pcpu.h:230 > #1 0x808704eb in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:451 > #2 0x80870920 in vpanic (fmt=, > ap=) at /usr/src/sys/kern/kern_shutdown.c:877 > #3 0x80870753 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:804 > #4 0x80c63b5b in trap_fatal (frame=0xfe0097fb75a0, eva=8) > at /usr/src/sys/amd64/amd64/trap.c:929 > #5 0x80c63f10 in trap_pfault (frame=0xfe0097fb75a0, > usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:839 > #6 0x80c632be in trap (frame=0xfe0097fb75a0) > at /usr/src/sys/amd64/amd64/trap.c:441 > #7 0x80c40535 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:232 > #8 0x809bf22c in amrr_node_stats (ni=0xfe008cf83000, > s=0xfe0097fb76f0) at /usr/src/sys/net80211/ieee80211_amrr.c:464 > #9 0x809ef9f4 in ieee80211_ratectl_sysctl_stats_node_iter ( > arg=0xfe0097fb76f0, ni=0xfe008cf83000) at > ieee80211_ratectl.h:170 > #10 0x809e42b0 in ieee80211_iterate_nodes_vap ( > nt=, vap=, > f=0x809ef9b0 , > arg=0xfe0097fb76f0) at /usr/src/sys/net80211/ieee80211_node.c:2558 > #11 0x809ef941 in ieee80211_ratectl_sysctl_stats ( > oidp=, arg1=, > arg2=, req=) > at /usr/src/sys/net80211/ieee80211_ratectl.c:99 > #12 0x8087f8ab in sysctl_root_handler_locked > (oid=0xf80016697d00, > arg1=0xf80007bef000, arg2=0, req=0xfe0097fb7840, > tracker=0xfe0097fb77b8) at /usr/src/sys/kern/kern_sysctl.c:166 > #13 0x8087ef4f in sysctl_root (arg1=0xf80007bef000, arg2=0, > req=0xfe0097fb7840) at /usr/src/sys/kern/kern_sysctl.c:2080 > #14 0x8087f5ca in userland_sysctl (td=0xf80007d96000, > name=0xfe0097fb7900, namelen=4, old=, > oldlenp=, inkernel=, new=0x0, > newlen=0, retval=0xfe0097fb7968, flags=0) > at /usr/src/sys/kern/kern_sysctl.c:2175 > #15 0x8087f40f in sys___sysctl (td=0xf80007d96000, > uap=0xf80007d963c0) at /usr/src/sys/kern/kern_sysctl.c:2110 > #16 0x80c64742 in amd64_syscall (td=0xf80007d96000, traced=0) > at subr_syscall.c:135 > #17 0x80c40e1d in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:504 > > What other data should I capture to assist in identifying and resolving > this? > > imb > ___ > 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vnet & firewalls in 12.0
Hi Ernie, On Thu, Oct 18, 2018 at 9:36 PM Ernie Luzar wrote: > Wanting to get a head start on using 12.0 and vnet jails with in jail > firewall. > > 1. Will Vimage be compiled as a module in the 12.0 kernel and be > included in the base system release? > I suppose it's part of GENERIC kernel configuration > 1.a. Has the boot time console log message about vimage being "highly > experimental" been removed? > I don't see in dmesg such notification. 12-ALPHA3 > 2. Has the pf firewall been fixed so it can now run in a vnet jail or > multiple vnet jails with out concern for which firewall is running on > the host? > > 2.a. Is each vnet/pf log only viewable from it's vnet jail console? > > 2.b. Will pf/kernel module auto load on first call from a vnet jail? > > 2.c. Does vnet/pf NAT work? > > 3. Does the ipfw firewall still have the 11.x release mandatory > requirements that the host must also be running ipfw for the vnet jailed > ipfw to work? > > 3.a. Are all vnet/ipfw log messages still intermixed with the host's > ipfw log messages? > > 3.b. Does vnet/ipfw NAT work? > I use NAT via netgraph+ipfw. it works fine (why not?). I'm patching "jng" to add "nat" feature. > 4. Has any work been done to ipf (ipfilter) so it will function when > used in a vnet jail? > ___ > 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[mips32] build is broken due to lack of .cfi-sections support in gcc 4.2.1
Hi, I've got compilation error for mips32 build by gcc 4.2.1 (freebsd-wifi-build): [halloween:/repo/onion/src/libexec/rtld-elf]$ make /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S: Assembler messages: /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S:35: Error: unknown pseudo-op: `.cfi_sections' *** Error code 1 Stop. make[2]: stopped in /repo/onion/src/libexec/rtld-elf [halloween:/repo/onion/src/libexec/rtld-elf]$ cc -isystem /repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp/usr/include -L/repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp/usr/lib -B/repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp/usr/lib --sysroot=/repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp -B/repo/onion/obj/mipsel/repo/onion/src/mips.mipsel/tmp/usr/bin -O -pipe -G0 -EL -mabi=32 -msoft-float -march=mips32 -Wall -DFREEBSD_ELF -DIN_RTLD -ffreestanding -I/repo/onion/src/lib/csu/common -I/repo/onion/src/libexec/rtld-elf/mips -I/repo/onion/src/libexec/rtld-elf -fpic -DPIC -g -MD -MF.depend.rtld_start.o -MTrtld_start.o -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S -o rtld_start.o /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S: Assembler messages: /repo/onion/src/libexec/rtld-elf/mips/rtld_start.S:35: Error: unknown pseudo-op: `.cfi_sections' [halloween:/repo/onion/src/libexec/rtld-elf]$ cc -v Using built-in specs. Target: mipsel-undermydesk-freebsd Configured with: FreeBSD/mipsel system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] The section info for call frame information has been added in revision 325624 by jhb@. This impacts several MIPS32 builds by freebsd-wifi-build (broadcom, may be atheros). Is my gcc toolchain old? switch to clang? 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"
Re: lldb unusable for regular user
Hi Volodya,
It works for me:
[mizhka@gidrarium ~/temp/20170919]$ cc -O0 -g test.c -o test
[mizhka@gidrarium ~/temp/20170919]$ ./test
PID: 12293
(failed reverse-i-search)`': ^C
[mizhka@gidrarium ~/temp/20170919]$ ./test
PID: 12294
load: 0.68 cmd: test 12294 [nanslp] 1.39r 0.00u 0.00s 0% 2316k
load: 0.68 cmd: test 12294 [nanslp] 3.57r 0.00u 0.00s 0% 2316k
load: 0.68 cmd: test 12294 [nanslp] 3.88r 0.00u 0.00s 0% 2316k
load: 0.68 cmd: test 12294 [nanslp] 4.18r 0.00u 0.00s 0% 2316k
load: 0.71 cmd: test 12294 [nanslp] 8.57r 0.00u 0.00s 0% 2316k
load: 0.71 cmd: test 12294 [nanslp] 9.33r 0.00u 0.00s 0% 2316k
load: 0.71 cmd: test 12294 [nanslp] 9.83r 0.00u 0.00s 0% 2316k
[mizhka@gidrarium ~/temp/20170919]$ lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 12300 launching
Process 12300 launched: './test' (x86_64)
PID: 12300
Process 12300 exited with status = 0 (0x)
(lldb) exit
[mizhka@gidrarium ~/temp/20170919]$ uname -a
FreeBSD gidrarium 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r321414: Mon Jul 24
21:41:54 MSK 2017 mizhka@gidrarium:/usr/obj/usr/src/sys/GENERIC amd64
[mizhka@gidrarium ~/temp/20170919]$ type lldb
lldb is hashed (/usr/bin/lldb)
[mizhka@gidrarium ~/temp/20170919]$ /usr/bin/lldb -v
lldb version 5.0.0
clang revision 308421
But I have r321414 with small patch: https://reviews.freebsd.org/D11738
Today/tomorrow I'll update to latest revision.
Hope this information will be useful for you to identify root cause.
Thanks!
On Mon, Sep 18, 2017 at 2:41 PM, Vladimir Zakharov
wrote:
> Hello!
>
> lldb coredumps for regular user, but works for root.
>
> > uname -a
> FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r323675: Sun Sep 17
> 21:14:33 MSK 2017 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG
> amd64
> > cat test.c
> #include
> #include
>
> int main()
> {
> printf("PID: %d\n", getpid());
> sleep(10);
> return 0;
> }
> > cc -O0 -g test.c -o test
> > lldb ./test
> (lldb) target create "./test"
> Current executable set to './test' (x86_64).
> (lldb) run
> Process 37758 launching
> Process 37758 launched: './test' (x86_64)
> Segmentation fault (core dumped)
> Exit 139
> > sudo lldb ./test
> (lldb) target create "./test"
> Current executable set to './test' (x86_64).
> (lldb) run
> Process 37776 launching
> Process 37776 launched: './test' (x86_64)
> PID: 37776
> Process 37776 exited with status = 0 (0x)
> (lldb)
>
>
> Postmortem by gdb:
> > gdb ./test test.core
> ...
> [New LWP 101456]
> Core was generated by `./test'.
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> #0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
> /usr/src/lib/csu/amd64/crt1.c:50
> 50 {
> (gdb) bt
> #0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
> /usr/src/lib/csu/amd64/crt1.c:50
> (gdb) f
> #0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
> /usr/src/lib/csu/amd64/crt1.c:50
> 50 {
>
> > gdb `which lldb` lldb.core
> ...
> Reading symbols from /usr/bin/lldb...Reading symbols from
> /usr/lib/debug//usr/bin/lldb.debug...done.
> done.
> [New LWP 101610]
> [New LWP 100968]
> [New LWP 100126]
> [New LWP 101631]
> [New LWP 101637]
> [New LWP 101662]
> [New LWP 101672]
> [New LWP 100337]
> [New LWP 101593]
> Core was generated by `lldb ./test'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
> context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
> 60 ./md-unwind-support.h: No such file or directory.
> [Current thread is 1 (LWP 101610)]
> (gdb) f
> #0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
> context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
> 60 in ./md-unwind-support.h
> (gdb) bt
> #0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
> context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
> #1 uw_frame_state_for (context=context@entry=0x7fffddff6e20,
> fs=fs@entry=0x7fffddff6b70)
> at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
> #2 0x000804f6cffb in _Unwind_ForcedUnwind_Phase2
> (exc=exc@entry=0x806b23230,
> context=context@entry=0x7fffddff6e20) at /wrkdirs/usr/ports/lang/gcc6/
> work/gcc-6.4.0/libgcc/unwind.inc:155
> #3 0x000804f6d334 in _Unwind_ForcedUnwind (exc=0x806b23230,
> stop=0x804631760 , stop_argument=) at
> /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
> #4 0x0008046315c3 in _Unwind_ForcedUnwind (ex=,
> stop_func=0xe, stop_arg=0x806b23000) at /usr/src/lib/libthr/thread/
> thr_exit.c:106
> #5 thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172
> #6 _pthread_exit_mask (status=, mask=) at
> /usr/src/lib/libthr/thread/thr_exit.c:254
> #7 0x0008046313eb in _pthread_exit (status=0x806b23000) at
> /usr/src/lib/libthr/thread/thr_exit.c:206
> #8 0x000804623c0d in thread_start (curthread=0x806b23000) at
> /usr/src/lib/libthr/t
Re: [libelftc] internal library or not?
Thank you, David! __cxa_demangle works fine [1] :) Best regards, Michael. [1] https://github.com/z0nt/pstack/pull/2/commits/8f45f92c63d385cd523d67f6ccbc436c7669f9d3 On Tue, Aug 1, 2017 at 6:22 PM, David Chisnall wrote: > On 1 Aug 2017, at 12:36, Michael Zhilin wrote: > > > > Hi Ed, freebsd-current, > > > > I want to add C++ demangling into sysutils/pstack. In man pages I've > found > > eltfc_demangle, exact what I need. This function belongs to libelftc. > "make > > installworld" installs man pages and include files, but there is no > > installed library. As results compilation error is occuried. > > Is pstack written in C++ or linking anything that is? If so, you will get > __cxa_demangle[1] provided by the C++ ABI library (libcxxrt on FreeBSD, > which currently uses the libelftc implementation, though might switch > soon). If not, adding -lcxxrt will provide it. > > David > > [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#demangler ___ 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: [pkg base][pormaster] Origin for base packages = "base"
Hi Ilya, I saw same issue yesterday. I suppose it's easy to fix postmaster, but pkgbase is still experimental. Best regards, Michael 14 авг. 2017 г. 2:57 ПП пользователь "Ilya A. Arkhipov" написал: > Hi there, > > After upgrade my system(r322368) to pkg-base system(have 780 packages for > world and kernel) I got next issue: > [11:53am] root:/root # portmaster -a > ===>>> Gathering distinfo list for installed ports > > ===>>> Starting check of installed ports for available updates > > > ===>>> Is /usr/ports/base/Makefile missing? > ===>>> Aborting update > > [11:53am] root:/root # cat /usr/ports/base/Makefile > # $FreeBSD: head/base/Makefile 425903 2016-11-11 18:51:42Z bapt $ > > # Never add SUBDIRS here as the ports should not be connected to the > build > # > .include > > > Looks like it related with Origin in base ports: > > pkg info -f FreeBSD-kernel-microkernel-12.0.s20170811101514 > FreeBSD-kernel-microkernel-12.0.s20170811101514 > Name : FreeBSD-kernel-microkernel > Version: 12.0.s20170811101514 > Installed on : Fri Aug 11 18:00:03 2017 MSK > Origin : base <=== > Categories : base > Licenses : BSD2CLAUSE > Maintainer : r...@freebsd.org > WWW: https://www.FreeBSD.org > Comment: FreeBSD MICROKERNEL kernel > Annotations: > repo_type : binary > repository : FreeBSD-base > Flat size : 115MiB > Description: > FreeBSD MICROKERNEL kernel > > > portmaster do a: > port_ver=`pm_make -V PKGNAME` > [ -z "$port_ver" ] && fail "Is $pd/$origin/Makefile > missing?" > and sure it will empty for $origin = base. > > For me I did: > 1767 >---if [ "$origin" = "base" ]; then > 1768 >--->---: > > Anybody have the same issue? > > -- > With Best Regards, > Ilya A. Arkhipov > ___ > 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[libelftc] internal library or not?
Hi Ed, freebsd-current, I want to add C++ demangling into sysutils/pstack. In man pages I've found eltfc_demangle, exact what I need. This function belongs to libelftc. "make installworld" installs man pages and include files, but there is no installed library. As results compilation error is occuried. In Makefile I've noticied line "INTERNALLIB=" which avoids installation of ".a" file. Commenting it allows to compile program, but I wonder what is correct way to use elftc_demangle. Is elftoolchain internal and can't be used by ports as all (i.e. man pages and include file to be removed from world installation)? Thank you in advance, Michael. ___ 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: ino64, java and intellij products problem
Hi, It may by worth to check other java monsters, but I see no problem with Eclipse and SQL Developer with ino64. Thanks! 1 июн. 2017 г. 6:29 ДП пользователь "Konstantin Belousov" < kostik...@gmail.com> написал: > On Wed, May 31, 2017 at 11:53:39PM +0300, Boris Samorodov wrote: > > Hi All, > > > > Seems that after ino64 transition some java programs stopped > > to fully function. I.e. java/intellij (IntellJ IDEA and Co) > > starts but does not show any files. > > > > I'm not sure if it's a java or IntelliJ problem. Any help to > > diagnose the culprit is welcome. > > Is it after full rebuild of all ports for post-ino64, or with all ports > built on pre-ino64 ? (Mixes are not supported and not supposed to work). > > Check java programs for JNI calls which return struct stat or struct > dirent to java code, and java code which knows the layout. It is, e.g., > the problem with Firefox and its javascript, but there the recompilation > seems to work. > ___ > 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)
Kurt, No more than idea: kldstat contains rtwn-rtl8192cfwU, but no rtwn-rtl8192cfwU_B. Do you have compiled rtwn-rtl8192cfwU_B.ko in /boot/kernel? Best regards, Michael On Sat, Oct 22, 2016 at 5:19 PM, Kurt Jaeger wrote: > Hi! > > > On -current rtwn has been attached to same chip. > > I've rebuild to > > FreeBSD udog.opsec.eu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r307767: Sat > Oct 22 15:31:03 CEST 2016 p...@udog.opsec.eu:/usr/obj/usr/src/sys/GENERIC > amd64 > > and still: > > none2@pci0:3:0:0: class=0x028000 card=0x819510ec chip=0x817610ec > rev=0x01 hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8188CE 802.11b/g/n WiFi Adapter' > class = network > bar [10] = type I/O Port, range 32, base 0x5000, size 256, enabled > bar [18] = type Memory, range 64, base 0xf240, size 16384, > enabled > > Any ideas ? > > -- > p...@opsec.eu+49 171 3101372 4 years to > go ! > ___ 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"
[panic] ng_uncallout with NULL callout argument
Hi,
I've switched from 10 to head recently. Most of functionalities works
fine except few panics.
The most frequent panic happens when I unplug ethernet cable with
active PPTP VPN connection.
uname -a:
FreeBSD gidrarium 12.0-CURRENT FreeBSD 12.0-CURRENT #1: Sat Jul 9
17:28:38 MSK 2016
jenkins@gidrarium:/builds/FreeBSD-src-head/obj/builds/FreeBSD-src-head/sys/GENERIC
amd64
Test case:
- use wired ethernet connection
- establish PPTP connection using mpd5
- unplug ethernet cable (=> panic)
db> bt
Tracing pid 902 tid 100675 td 0xf800169a1000
ng_uncallout() at ng_uncallout+0x3d/frame 0xfe04530b3580
ng_pptpgre_disconnect() at ng_pptpgre_disconnect+0xbb/frame 0xf*
ng_destroy_hook() at ng_destroy_hook+0xlfe/frame 8xfe84538b35d8
ng_ranode() at ng_ranode+0x75/frame 0xfe04538b3618
ng_apply_item() at ng_apply_itea+0x4ca/frame 0xfeB4538b36a8
ng_snd_item() at ng_snd_itea+0x3a9/frame 0xfeB4538b36e0
ngc_send() at ngc_send+0x21b/frame 0xfe04530b3790
sosend_generic() at sosend_generic+0x436/frame 0xfe04538b3850
kern_sendit() at kern_sendit+0x21b/frame Bxfe04538b390B
sendit() at sendit+0x19f/frame 0xfeB4530b3950
sys_sendto() at sys_sendto+0x4d/frame 0xfe04530b39a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe04530b3ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfeB4530b3abB
--- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80253906a, rsp -
0x7fffdfffd72B, rbp - 0x7fffdfffd770
Panic happens due to missing check if item (c->c_arg) is NULL in ng_uncallout:
item = c->c_arg;
/* Do an extra check */
if ((rval > 0) && (c->c_func == &ng_callout_trampoline) &&
(NGI_NODE(item) == node)) { /* NGI_NODE dereferences item,
but it may be NULL */
I suppose that actual root cause may be in upper stack (PPTP?).
Link to bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211031
Best regards,
Michael
___
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: panic: bogus refcnt 0 on lle 0xfffff80121a13a00
Hi, I have same issue everyday on my laptop. It happens randomly and I suppose due to network issues. I want to test D4507. I've tried to apply patch, it's successful except one chunk: |Index: sys/netinet6/nd6.c |=== |--- sys/netinet6/nd6.c |+++ sys/netinet6/nd6.c -- Patching file sys/netinet6/nd6.c using Plan A... Hunk #1 succeeded at 520 (offset 31 lines). Hunk #2 failed at 739. Hunk #3 succeeded at 1357 with fuzz 1 (offset 19 lines). Hunk #4 succeeded at 1446 with fuzz 2 (offset 32 lines). 1 out of 4 hunks failed--saving rejects to sys/netinet6/nd6.c.rej done Hans, Could you please check patch? Thanks! On Tue, Jul 12, 2016 at 11:55 AM, Hans Petter Selasky wrote: > On 07/12/16 10:37, Peter Holm wrote: > >> Exiting from single-user mode triggers this: >> >> ifa_maintain_loopback_route: deletion failed for interface igb0: 3 >> panic: bogus refcnt 0 on lle 0xf80121a13a00 >> cpuid = 9 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe1048c63470 >> vpanic() at vpanic+0x182/frame 0xfe1048c634f0 >> kassert_panic() at kassert_panic+0x126/frame 0xfe1048c63560 >> llentry_free() at llentry_free+0x136/frame 0xfe1048c63590 >> in_lltable_free_entry() at in_lltable_free_entry+0xb0/frame >> 0xfe1048c635c0 >> htable_prefix_free() at htable_prefix_free+0xce/frame 0xfe1048c63620 >> lltable_prefix_free() at lltable_prefix_free+0x5d/frame 0xfe1048c63660 >> in_scrubprefix() at in_scrubprefix+0x290/frame 0xfe1048c63700 >> in_difaddr_ioctl() at in_difaddr_ioctl+0x285/frame 0xfe1048c63750 >> in_control() at in_control+0x96/frame 0xfe1048c637d0 >> ifioctl() at ifioctl+0xda1/frame 0xfe1048c63860 >> kern_ioctl() at kern_ioctl+0x246/frame 0xfe1048c638c0 >> sys_ioctl() at sys_ioctl+0x171/frame 0xfe1048c639a0 >> amd64_syscall() at amd64_syscall+0x2f6/frame 0xfe1048c63ab0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1048c63ab0 >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fd2eba, rsp = >> 0x7fffe468, rbp = 0x7fffe4b0 - >> >> Details @ https://people.freebsd.org/~pho/stress/log/bogus_refcnt.txt >> >> > FYI: > https://reviews.freebsd.org/D4605 > > Might be related. > > --HPS > > ___ > 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 mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
