Re: lock order reversal
On 26/02/2018 07:18, Jon Brawn wrote: > Wotcha! > > So, I’ve been using FreeBSD 12-CURRENT at various svn releases for a while > now, and I get quite a few “lock order reversal” dumps. The one I’ve got on > my screen at the moment is for ufs / bufwait / ufs: > > root@brax:/usr/src/stand # lock order reversal: > 1st 0xfd0003ec17e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2602 > 2nd 0x410efa20 bufwait (bufwait) @ > /usr/src/sys/ufs/ffs/ffs_vnops.c:282 > 3rd 0xfd00b83ca7e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2602 > stack backtrace: > #0 0x003b59d4 at witness_debugger+0x64 > #1 0x0032bd34 at __lockmgr_args+0x6ac > #2 0x005c6af0 at ffs_lock+0x88 > #3 0x00679eb0 at VOP_LOCK1_APV+0xac > #4 0x00426fa8 at _vn_lock+0x64 > #5 0x00417550 at vget+0x78 > #6 0x00409fdc at vfs_hash_get+0xec > #7 0x005c2b94 at ffs_vgetf+0x44 > #8 0x005b96a8 at softdep_sync_buf+0x9f4 > #9 0x005c7834 at ffs_syncvnode+0x26c > #10 0x005a1b5c at ffs_truncate+0x6b0 > #11 0x005ce3cc at ufs_direnter+0x778 > #12 0x005d64bc at ufs_makeinode+0x4b8 > #13 0x005d2b90 at ufs_create+0x38 > #14 0x00677168 at VOP_CREATE_APV+0xac > #15 0x0042691c at vn_open_cred+0x264 > #16 0x0041fc84 at kern_openat+0x208 > #17 0x0064b59c at do_el0_sync+0x8bc > > Is there something I should be doing to help debug these? IMO, no. Please ignore LORs involving "bufwait", "filedesc structure", "syncer" unless you experience any real problem (like a lock up). -- Andriy Gapon ___ 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"
lock order reversal
Wotcha! So, I’ve been using FreeBSD 12-CURRENT at various svn releases for a while now, and I get quite a few “lock order reversal” dumps. The one I’ve got on my screen at the moment is for ufs / bufwait / ufs: root@brax:/usr/src/stand # lock order reversal: 1st 0xfd0003ec17e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2602 2nd 0x410efa20 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:282 3rd 0xfd00b83ca7e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2602 stack backtrace: #0 0x003b59d4 at witness_debugger+0x64 #1 0x0032bd34 at __lockmgr_args+0x6ac #2 0x005c6af0 at ffs_lock+0x88 #3 0x00679eb0 at VOP_LOCK1_APV+0xac #4 0x00426fa8 at _vn_lock+0x64 #5 0x00417550 at vget+0x78 #6 0x00409fdc at vfs_hash_get+0xec #7 0x005c2b94 at ffs_vgetf+0x44 #8 0x005b96a8 at softdep_sync_buf+0x9f4 #9 0x005c7834 at ffs_syncvnode+0x26c #10 0x005a1b5c at ffs_truncate+0x6b0 #11 0x005ce3cc at ufs_direnter+0x778 #12 0x005d64bc at ufs_makeinode+0x4b8 #13 0x005d2b90 at ufs_create+0x38 #14 0x00677168 at VOP_CREATE_APV+0xac #15 0x0042691c at vn_open_cred+0x264 #16 0x0041fc84 at kern_openat+0x208 #17 0x0064b59c at do_el0_sync+0x8bc Is there something I should be doing to help debug these? Jon. smime.p7s Description: S/MIME cryptographic signature
Re: iocage on current seems broken / ascii errors with iocage
On 25 February 2018 at 15:15, Alan Somers wrote: > On Sun, Feb 25, 2018 at 3:50 PM, Eitan Adler wrote: >> What should I do from here? >> > > It's a well-known problem. You need to patch your copy of py-libzfs. > Unfortunately, the patch hasn't been picked up by upstream because the port > maintainer believes it to be incorrect, but hasn't found the correct > solution yet. Thanks! I searched by email but not the iocage project. That fixed it. -- Eitan Adler ___ 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: iocage on current seems broken / ascii errors with iocage
On Sun, Feb 25, 2018 at 3:50 PM, Eitan Adler wrote:
> ∴sudo iocage activate zroot
> ∴sudo iocage list
> +-+--+---+-+-+
> | JID | NAME | STATE | RELEASE | IP4 |
> +=+==+===+=+=+
> +-+--+---+-+-+
> ∴sudo iocage create -r 11.1-RELEASE
> Fetching: 11.1-RELEASE
>
> Downloading : MANIFEST [] 100% 0Mbit/s
> Downloading : base.txz [] 100% 26.51Mbit/s
> Downloading : lib32.txz [] 100% 26.02Mbit/s
> Downloading : doc.txz [] 100% 26.12Mbit/s
> Downloading : src.txz [] 100% 26.4Mbit/ss
> ...
> 709c103b-1f43-4c3b-a5db-100d19822ccb successfully created!
> ∴sudo iocage list
> ∴zfs list
> (git:global)-[master]
> NAME USED
> AVAIL REFER MOUNTPOINT
> ...
> zroot/ROOT2.98G
> 802G88K none
> zroot/ROOT/default2.98G
> 802G 2.98G /
> ...
> zroot/iocage 1.19G
> 802G 100K /iocage
> zroot/iocage/download 260M
> 802G88K /iocage/download
> zroot/iocage/download/11.1-RELEASE 260M
> 802G 260M /iocage/download/11.1-RELEASE
> zroot/iocage/images 88K
> 802G88K /iocage/images
> zroot/iocage/jails 368K
> 802G88K /iocage/jails
> zroot/iocage/jails/709c103b-1f43-4c3b-a5db-100d19822ccb280K
> 802G92K /iocage/jails/709c103b-1f43-4c3b-a5db-100d19822ccb
> zroot/iocage/jails/709c103b-1f43-4c3b-a5db-100d19822ccb/root 188K
> 802G 961M /iocage/jails/709c103b-1f43-4c3b-a5db-100d19822ccb/root
> zroot/iocage/log88K
> 802G88K /iocage/log
> zroot/iocage/releases 961M
> 802G88K /iocage/releases
> zroot/iocage/releases/11.1-RELEASE 961M
> 802G88K /iocage/releases/11.1-RELEASE
> zroot/iocage/releases/11.1-RELEASE/root961M
> 802G 961M /iocage/releases/11.1-RELEASE/root
> zroot/iocage/templates 88K
> 802G88K /iocage/templates
> ...
> ∴sudo iocage rename 709c103b-1f43-4c3b-a5db-100d19822ccb bastion
> (git:global)-[master]
> Traceback (most recent call last):
> File "/usr/local/bin/iocage", line 10, in
> sys.exit(cli())
> File "/usr/local/lib/python3.6/site-packages/click/core.py", line
> 722, in __call__
> return self.main(*args, **kwargs)
> File "/usr/local/lib/python3.6/site-packages/click/core.py", line 697,
> in main
> rv = self.invoke(ctx)
> File "/usr/local/lib/python3.6/site-packages/click/core.py", line
> 1066, in invoke
> return _process_result(sub_ctx.command.invoke(sub_ctx))
> File "/usr/local/lib/python3.6/site-packages/click/core.py", line
> 895, in invoke
> return ctx.invoke(self.callback, **ctx.params)
> File "/usr/local/lib/python3.6/site-packages/click/core.py", line
> 535, in invoke
> return callback(*args, **kwargs)
> File "/usr/local/lib/python3.6/site-packages/iocage/cli/rename.py",
> line 39, in cli
> ioc.IOCage(exit_on_error=True, jail=jail).rename(new_name)
> File "/usr/local/lib/python3.6/site-packages/iocage/lib/iocage.py",
> line 1211, in rename
> self.set(f"host_hostuuid={new_name}", rename=True)
> File "/usr/local/lib/python3.6/site-packages/iocage/lib/iocage.py",
> line 1415, in set
> self.get(_prop)
> File "/usr/local/lib/python3.6/site-packages/iocage/lib/iocage.py",
> line 1121, in get
> exit_on_error=self.exit_on_error).json_get_value(prop)
> File "/usr/local/lib/python3.6/site-packages/iocage/lib/ioc_json.py",
> line 563, in json_get_value
> conf = self.json_load()
> File "/usr/local/lib/python3.6/site-packages/iocage/lib/ioc_json.py",
> line 226, in json_load
> if jail_dataset.mountpoint is None:
> File "libzfs.pyx", line 2311, in libzfs.ZFSDataset.mountpoint.__get__
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc0 in position
> 320: ordinal not in range(128)
>
>
> What should I do from here?
>
>
It's a well-known problem. You need to patch your copy of py-libzfs.
Unfortunately, the patch hasn't been picked up by upstream because the port
maintainer believes it to be incorrect, but hasn't found the correct
solution yet.
Here's the patch:
https://github.com/trueos/freebsd-ports/commit/00da370342012d87331eae3d74ef6784ed8172be
And here's the discussion:
https://github.com/iocage/iocage/issues/153
-Alan
___
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"
iocage on current seems broken / ascii errors with iocage
∴sudo iocage activate zroot
∴sudo iocage list
+-+--+---+-+-+
| JID | NAME | STATE | RELEASE | IP4 |
+=+==+===+=+=+
+-+--+---+-+-+
∴sudo iocage create -r 11.1-RELEASE
Fetching: 11.1-RELEASE
Downloading : MANIFEST [] 100% 0Mbit/s
Downloading : base.txz [] 100% 26.51Mbit/s
Downloading : lib32.txz [] 100% 26.02Mbit/s
Downloading : doc.txz [] 100% 26.12Mbit/s
Downloading : src.txz [] 100% 26.4Mbit/ss
...
709c103b-1f43-4c3b-a5db-100d19822ccb successfully created!
∴sudo iocage list
∴zfs list
(git:global)-[master]
NAME USED
AVAIL REFER MOUNTPOINT
...
zroot/ROOT2.98G
802G88K none
zroot/ROOT/default2.98G
802G 2.98G /
...
zroot/iocage 1.19G
802G 100K /iocage
zroot/iocage/download 260M
802G88K /iocage/download
zroot/iocage/download/11.1-RELEASE 260M
802G 260M /iocage/download/11.1-RELEASE
zroot/iocage/images 88K
802G88K /iocage/images
zroot/iocage/jails 368K
802G88K /iocage/jails
zroot/iocage/jails/709c103b-1f43-4c3b-a5db-100d19822ccb280K
802G92K /iocage/jails/709c103b-1f43-4c3b-a5db-100d19822ccb
zroot/iocage/jails/709c103b-1f43-4c3b-a5db-100d19822ccb/root 188K
802G 961M /iocage/jails/709c103b-1f43-4c3b-a5db-100d19822ccb/root
zroot/iocage/log88K
802G88K /iocage/log
zroot/iocage/releases 961M
802G88K /iocage/releases
zroot/iocage/releases/11.1-RELEASE 961M
802G88K /iocage/releases/11.1-RELEASE
zroot/iocage/releases/11.1-RELEASE/root961M
802G 961M /iocage/releases/11.1-RELEASE/root
zroot/iocage/templates 88K
802G88K /iocage/templates
...
∴sudo iocage rename 709c103b-1f43-4c3b-a5db-100d19822ccb bastion
(git:global)-[master]
Traceback (most recent call last):
File "/usr/local/bin/iocage", line 10, in
sys.exit(cli())
File "/usr/local/lib/python3.6/site-packages/click/core.py", line
722, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line
1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.6/site-packages/click/core.py", line
895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line
535, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/iocage/cli/rename.py",
line 39, in cli
ioc.IOCage(exit_on_error=True, jail=jail).rename(new_name)
File "/usr/local/lib/python3.6/site-packages/iocage/lib/iocage.py",
line 1211, in rename
self.set(f"host_hostuuid={new_name}", rename=True)
File "/usr/local/lib/python3.6/site-packages/iocage/lib/iocage.py",
line 1415, in set
self.get(_prop)
File "/usr/local/lib/python3.6/site-packages/iocage/lib/iocage.py",
line 1121, in get
exit_on_error=self.exit_on_error).json_get_value(prop)
File "/usr/local/lib/python3.6/site-packages/iocage/lib/ioc_json.py",
line 563, in json_get_value
conf = self.json_load()
File "/usr/local/lib/python3.6/site-packages/iocage/lib/ioc_json.py",
line 226, in json_load
if jail_dataset.mountpoint is None:
File "libzfs.pyx", line 2311, in libzfs.ZFSDataset.mountpoint.__get__
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc0 in position
320: ordinal not in range(128)
What should I do from here?
--
Eitan Adler
___
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"
update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
Dear all, Please CC me as I am not subscribed. On behalf of the FreeBSDDesktop team and thanks to the tireless efforts of Johannes Lundberg and Hans Petter Selasky (hselasky), I am pleased to report that the graphics/drm-next-kmod port just received an update to Linux level 4.11 KMS/DRM for amdgpu, radeon, and i915 for both recent CURRENT and 11-STABLE. We have tested this on a range of hardware ourselves: * Haswell * Broadwell * Skylake * Evergreen * Kaveri (both radeon and amgpu KMS) * Carrizo * Polaris Needless to say, the possible space of hardware this could run on is significantly larger. Hence, if you find issues and/or want to propose patches, please do so at our development github: https://github.com/FreeBSDDesktop/kms-drm We absolutely do welcome contributions! Johannes ___ 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: INTRNG
While on the subject INTRNG - does anybody know the status of handling GPIO interrupts with queue/kevent? There were some patches before INTRNG, but they require some work. Peter > On 23 Feb 2018, at 07:25, Jon Brawn wrote: > > Wotcha Gang! > > In my travels through the arm64 GENERIC config file I came across the option > ‘INTRNG’, and wondered what it was: > > INTeRrupt Next Generation? > INTeger Random Number Generator? > IN TRaiNinG? > INTerrupt Random Number Generator? > INdependent TRaiNinG? > > So, please put me out of my misery, what does INTRNG stand for, and what are > its implications when selected vs not selected? > > Cheers! > > Jon. ___ 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"
