Bug 264282 / Unable to boot from GELI encrypted UFS in 13.1 and -CURRENT

2022-06-10 Thread Yamagi
possible patch and a prebuild loader binaries with the patch applied. The later can be used to recover unbootable systems. Regards Yamagi 0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282 Booting -- Homepage: https://www.yamagi.org Github: https://github.com/yamagi GPG

Re: 13.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

2021-03-17 Thread Yamagi Burmeister
.freebsd.org/~mjg/maxvnodes.diff > > Once you boot, tweak maxvnodes: > sysctl kern.maxvnodes=1049226 > > Run poudriere. Once it finishes, inspect sysctl vfs.highest_numvnodes > > On 3/17/21, Yamagi wrote: > > Hi Mateusz, > > the sysctl output after about 10 minutes

Re: 13.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

2021-03-17 Thread Yamagi
Hi Mateusz, the sysctl output after about 10 minutes into the problem is attached. In case that its stripped by Mailman a copy can be found here: https://deponie.yamagi.org/temp/sysctl_vlruwk.txt.xz Regards, Yamagi On Wed, 17 Mar 2021 15:57:59 +0100 Mateusz Guzik wrote: > Can you reproduce

13.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

2021-03-17 Thread Yamagi
fork_exit+0x80 fork_trampoline+0xe Since vnlru is accumulating CPU time it looks like it's doing at least something. As an educated guess I would say that vn_alloc_hard() is waiting a long time or even forever to allocate new vnodes. I can provide more information, I just need to know what.

Re: Boot hang on ryzen based notebook

2019-04-03 Thread Yamagi Burmeister
IOS / UEFI. -- Homepage: https://www.yamagi.org Github: https://github.com/yamagi GPG: 0x1D502515 pgpjDjC0Hh6Ow.pgp Description: PGP signature

Re: Binary packages for LibreOffice 3.5 or 3.4

2012-05-07 Thread Yamagi Burmeister
> I'd like to ask whether there are sites were binary packages could be > downloaded from and are there any experiences with installing them on > either 9-STABLE or 10-CURRENT? We (BSDForen.de) have unofficial packages build by the community at http://wiki.bsdforen.de/anwendungen/libreoffice_aus_i

Re: Enhancing the user experience with tcsh

2012-02-10 Thread Yamagi Burmeister
On Thu, 9 Feb 2012 19:52:58 -0500 Eitan Adler wrote: > In conf/160689 (http://www.freebsd.org/cgi/query-pr.cgi?pr=160689) > there has been some discussion about changing the default cshrc file. > > I'd like to commit something like the following based on Chris's patch > at the end of the thread.

Re: FS hang when creating snapshots on a UFS SU+J setup

2012-01-11 Thread Yamagi Burmeister
e taking the snapshot this looks like some kind of race condition or something like that. Some more information from an older debug session can be found at: http://deponie.yamagi.org/freebsd/debug/snapshots_panic/ On Tue, 10 Jan 2012 10:30:13 -0800 Kirk McKusick wrote: > > Date: Mon, 9 J

Re: FS hang when creating snapshots on a UFS SU+J setup

2012-01-09 Thread Yamagi Burmeister
g and / or fixing this problem. Thank you, Yamagi On Mon, 2 Jan 2012 23:27:57 -0600 Bryce Edwards wrote: > I have a RELENG_9 machine that hangs when a snapshot is created on the > root fs (UFS, with SU+J).  More accurately, all the processes show a > state of "suspfs" (with ^

Re: FS hang when creating snapshots on a UFS SU+J setup

2012-01-03 Thread Yamagi Burmeister
Hi, I've seen this too (and other problems with SU+J and snapshots) and was able to reproduce it fairly easy. I wrote a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=163310 Never received any feedback until now... On Mon, 2 Jan 2012 23:27:57 -0600 Bryce Edwards wrote: > I have a RELENG_9 ma

Re: [maybe spam] Re: running old binaries on -current

2011-12-05 Thread Yamagi Burmeister
On Sun, 04 Dec 2011 13:56:11 -0800 Julian Elischer wrote: > On 12/4/11 12:30 PM, Yamagi Burmeister wrote: > > On Sun, 4 Dec 2011 22:25:19 +0200 > > Kostik Belousov wrote: > > > >> Try to set sysctl security.bsd.map_at_zero to 1. > > I didn't even think o

Re: running old binaries on -current

2011-12-04 Thread Yamagi Burmeister
On Sun, 4 Dec 2011 22:25:19 +0200 Kostik Belousov wrote: > Try to set sysctl security.bsd.map_at_zero to 1. I didn't even think of that. It helped, thanks :) -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB pgpZ0f86AZ7Fv.pgp Description: PGP signature

Re: running old binaries on -current

2011-12-04 Thread Yamagi Burmeister
paged pure executable % ./sh Abort The ktrace / kdump: 1065 ktrace RET ktrace 0 1065 ktrace CALL execve(0xbfbfee1b,0xbfbfecf8,0xbfbfed00) 1065 ktrace NAMI "./sh" I've uploaded the binary to: http://deponie.yamagi.org/freebsd/tmp/sh_freebsd1 Thanks, Yamagi -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB pgpFSW9yOmz7a.pgp Description: PGP signature

Re: /home and /usr/home not created by bsdinstall

2011-09-01 Thread Yamagi Burmeister
On Thu, 01 Sep 2011 11:45:17 +0200 Lars Engels wrote: > this was already reported and will be fixed in BETA2. The cause was a > bug in > pw(8). Ah okay, I didn't know that. Sorry for the noise :) -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB pgpu0SOirAb4a.p

/home and /usr/home not created by bsdinstall

2011-09-01 Thread Yamagi Burmeister
herefor I'm suggesting that bsdinstall creates /usr/home and the /home symlink in any case, regardless if users are added or not. Ciao, Yamagi -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB pgpWl2uJC43pu.pgp Description: PGP signature

Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up

2011-08-29 Thread Yamagi Burmeister
On Mon, 29 Aug 2011 20:12:54 +0800 Adrian Chadd wrote: > Hi, > > http://forums.nvidia.com/index.php?showtopic=38242 Post 18 > > This indicates the driver supports CUDA somehow. What's missing is a > FreeBSD runtime. > > Can someone please do some legwork with this and see if it's possible > to

Reproducible panic with TRIM and ufs snapshots

2011-06-21 Thread Yamagi Burmeister
Hi, I encountered a panic in the 2011/05 snapshot of 9-current. Snapshot creation an UFS filesystem with or without SU+J leads to panic: % mdconfig -a -t malloc -s 128m % newfs -U -O2 -t /dev/md0 % mount /dev/md0 /mnt % mksnap_ffs /mnt /mnt/foo => panic My system is: fbsd-vbox# uname -a F

PATCH: Potential ressource leak in sys/dev/fb/vesa.c

2010-07-01 Thread Yamagi Burmeister
Hello, while tracking down a bug in vesa.c which caused a crash a friend of mine noticed a potential ressource leak in vesa.c. In line 841 the execution is aborted via return (1); without freeing the already allocated resources. the attached patch changes the line to "goto fail;" which seems more