Re: r359627 is panicked with 'softdep_setup_blkfree: not free'

[Kirk McKusick]

> Date: Wed, 08 Apr 2020 09:53:04 +0900 (JST)
> To: freebsd-current@freebsd.org
> Subject: Re: r359627 is panicked with 'softdep_setup_blkfree: not free'
> From: Masachika ISHIZUKA 
> 
> >I'm using r359627M. (r359627 with mount_udf2).
> >It is panicked with 'softdep_setup_blkfree: not free'.
> > 
> > Recently I've started observing issues like this too. For example, today
> 
>   As it was good working on r359197M, I'm booted old kernel(r359197M).
> % uname -UKa
> FreeBSD carrot.ish.org 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r359197M: Sun Mar 
> 22 12:34:40 JST 2020 
> ishiz...@okra.ish.org:/usr/altlocal/freebsd-current/obj/usr/altlocal/freebsd-current/src/amd64.amd64/sys/GENERIC
>   amd64 1300084 1300088
> 
>   Although it is mismatch with kernel version and userland version,
> it's good working.
>   I'll use this old kernel for a while.
> -- 
> Masachika ISHIZUKA

Could you please try this workaround to see if it clears your panic:

*** sys/ufs/ffs/ffs_inode.c Wed Apr  8 21:57:31 2020
--- sys/ufs/ffs/ffs_inode.c.new Wed Apr  8 22:33:36 2020
***
*** 244,249 
--- 244,250 
needextclean = 0;
softdeptrunc = 0;
journaltrunc = DOINGSUJ(vp);
+   journaltrunc = 0;
if (journaltrunc == 0 && DOINGSOFTDEP(vp) && length == 0)
softdeptrunc = !softdep_slowdown(vp);
extblocks = 0;

Thanks,

Kirk McKusick
___
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"

PORTS_MODULES if you built head between r359681 - r359690

[David Wolfskill]

TL;DR: You may want to take evasive action, such as manually copying
the r359690 (or later) from src/share/mk/bsd.sys.mk to
/usr/share/mk/bsd.sys.mk before attempting to make use of the
PORTS_MODULES specificsation if the current version of
/usr/share/mk/bsd.sys.mk is from r359681.

Details & rationale:
I track head daily on my laptop, which uses x11/nvidia-driver, so I
have:

PORTS_MODULES=x11/nvidia-driver

in /etc/src.conf -- and that has served well for years.

Yesterday, I had updated head from r359656 to r359686 without incident
(as far as I could tell at the time).

Today, during the attempt to update from r359686 to r359724 -- which
had worked on my headless "build machine" -- failed during the attempt
to rebuild nividia.ko, whining:

make[6]: "/usr/share/mk/bsd.sys.mk" line 219: Malformed conditional 
(${MK_CLANG_BOOTSTRAP} == "no" && ${COMPILER_RESOURCE_DIR} != "unknown" &&  
!defined(BOOTSTRAPPING))
make[6]: Fatal errors encountered -- cannot continue
make[6]: stopped in 
/common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-440.64/doc
*** Error code 1


Once I finally(!) had a chance to look at the commits between r359686
and r359724, I found r359690 ... and looking at the whine, I note
that the path for share/mk/bsd.sys.mk starts with /usr -- which,
of course, had not yet been updated, since this was part of "make
buildkernel," and "make installworld" comes rather later in the sequence
(ref src/UPDATING).

Once I realized the above, I made the r359690 changes in
/usr/share/mk/bsd.sys.mk, then re-ran the build/install, which worked
without issue.

Peace and good health,
david
--
David H. Wolfskill  da...@catwhisker.org
"The most basic duty of government is to defend the lives of its own
citizens.  Any government that fails to do so is a government unworthy
to lead." -- Donald Trump, to the RNC, 2016

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: buildkernel failure because ctfconvert not installed

[John Baldwin]

On 4/7/20 11:32 PM, Gary Jennejohn wrote:
> Has anyone else seen this error?
> 
> I tried to build a kernel yesterday, but the build failed while compiling
> modules because ctfconvert was not found.
> 
> I've had WITH_CTF=no in my src.conf for years, so neither ctfconvert nor
> ctfmerge were installed.
> 
> OK, I'll just go to the source dirctories and build and install.
> 
> Nope.  I got this error:
>   make: exec(ctfconvert) failed (No such file or directory)
> and the build failed.
> 
> WTF?  ctfconvert requires ctfconvert to build?  That makes no sense and is
> a real chicken-and-egg problem if I've ever seen one.
> 
> I ended up creating /usr/bin/ctf{convert,merge} shell scripts which simply
> did exit 0.  That allowed me to finally compile and install the utilities.
> 
> Now I'm forced to have WITH_CTF=yes in my src.conf.  No big deal.
> 
> Still, it seems like the change to the make infrastructure which assumed
> that cft{convert,merge} are always installed was rather premature.

The change is that GENERIC has 'makeoptions WITH_CTF=yes'.  If you build a
kernel without that, you shouldn't need to have ctfconvert installed.  This
does mean you need to use a custom kernel instead of GENERIC.

-- 
John Baldwin
___
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"

Firefox 75.0_1,1 tabs crashing or mis-rendering at some www.gov.uk pages

[Graham Perrin]

Most noticeable today at . Screenshots 
available on request.


AFAICT the same types of problem with 75.0_1,1 on both r357746 and r359628.

___
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"

buildkernel failure because ctfconvert not installed

[Gary Jennejohn]

Has anyone else seen this error?

I tried to build a kernel yesterday, but the build failed while compiling
modules because ctfconvert was not found.

I've had WITH_CTF=no in my src.conf for years, so neither ctfconvert nor
ctfmerge were installed.

OK, I'll just go to the source dirctories and build and install.

Nope.  I got this error:
make: exec(ctfconvert) failed (No such file or directory)
and the build failed.

WTF?  ctfconvert requires ctfconvert to build?  That makes no sense and is
a real chicken-and-egg problem if I've ever seen one.

I ended up creating /usr/bin/ctf{convert,merge} shell scripts which simply
did exit 0.  That allowed me to finally compile and install the utilities.

Now I'm forced to have WITH_CTF=yes in my src.conf.  No big deal.

Still, it seems like the change to the make infrastructure which assumed
that cft{convert,merge} are always installed was rather premature.

-- 
Gary Jennejohn
___
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"