Identifying broken applications following careless use of make -DBATCH_DELETE_OLD_FILES delete-old-libs

[Graham Perrin]

Re: 
 
I made careless use of:


cd /usr/src && make -DBATCH_DELETE_OLD_FILES delete-old-libs

– then found applications such as LibreOffice no longer working as 
expected. Resolved (I believe):


pkg remove inkscape libreoffice && pkg autoremove && pkg install 
inkscape libreoffice


Please: how can I positively identify other applications that I might 
have broken through careless deletion of old libraries?

___
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: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[John Kennedy]

On Sun, Dec 13, 2020 at 06:49:07PM +, Graham Perrin wrote:
> Not entirely moot; for 
>  the description for 
> the most recent commit refers to building on 13-CURRENT

Well, it's a port, so they'll want it to compile if nothing else.  It just
necessarily needed on 13, since it should be nearly par (if slightly behind in
some MFC-ish interval) the kernel.  Of course, when we get into 14 and 13
becomes more stable, 13-releng might be where 12 is now.

This was just a comment on a old ticket (with "latest" OS) in the -current
mailing list which is the potential edge case (13) of an edge case (need
to match kmod with kernel) where you might not need it.  I'm not saying
that it couldn't use some fixing in the medium/long term.

___
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: after update to r368166: no sound recording

[Matthias Apitz]

El día viernes, diciembre 11, 2020 a las 08:06:27a. m. +0100, Matthias Apitz 
escribió:

> FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r342378:368166M: 
> Fri Dec 11 07:46:32 CET 2020 
> guru@c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> 
> and all is fine again as it was before. Someone with more knowledge should
> have a look into a 'svn diff -r342378:368166 sys/dev/sound/pci/hda' and
> see which of the changes might break the things. 
> 

I did an analyzing of the files changed in sys/dev/sound/pci/hda between
r342378 (2018-11-02) and r368166 (2020-11-30)

I copied over all files from hda/* to a new dir hda.r368166/* and
updated (i.e. reverted) hda/* to r342378; only the 7 files below (of 10)
have changed between r342378 and r368166:

The kernel built with hda of r342378 works fine;

The work plan was now to change one file after the other to r368166
and see if the kernel still works fine, i.e. which of the 7 file(s)
is causing the regression...

i.e. I did: 

# svn up -r342378 sys/dev/sound/pci/hda
# cp sys/dev/sound/pci/hda.r368166/hdac.c sys/dev/sound/pci/hda/
# touch sys/dev/sound/pci/hda/hdac.c 
# make buildkernel -DNO_CLEAN
# make installkernel
...

 van 'x' means: was copied from hda.r368166;
[x] Index: hda/hdac.c
[x] Index: hda/hdac.h

recording with the kernel still works

[x] Index: hda/hdaa_patches.c 

recording with the kernel still works

[x] Index: hda/hdacc.c
[x] Index: hda/hda_reg.h  only cleanups of empty lines

recording with the kernel still works

[x] Index: hda/hdaa.h
[x] Index: hda/hdaa.c 

recording with the kernel stoped working

Which means the few changes in hda/hdaa.c are causing the regression:

# svn diff -r342378 hdaa.c
Index: hdaa.c
===
--- hdaa.c  (revisión: 342378)
+++ hdaa.c  (copia de trabajo)
@@ -52,7 +52,6 @@
 #define hdaa_lock(devinfo) snd_mtxlock((devinfo)->lock)
 #define hdaa_unlock(devinfo)   snd_mtxunlock((devinfo)->lock)
 #define hdaa_lockassert(devinfo) snd_mtxassert((devinfo)->lock)
-#define hdaa_lockowned(devinfo)mtx_owned((devinfo)->lock)
 
 static const struct {
const char *key;
@@ -1129,7 +1128,6 @@
((step - offset) * (size + 1)) / 4);
 }
 
-
 static int
 hdaa_sysctl_caps(SYSCTL_HANDLER_ARGS)
 {
@@ -5034,11 +5032,13 @@
pincap = w->wclass.pin.cap;
 
/* Disable everything. */
-   w->wclass.pin.ctrl &= ~(
-   HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
-   HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
-   HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
-   HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
+   if (devinfo->init_clear) {
+   w->wclass.pin.ctrl &= ~(
+   HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
+   HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
+   HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
+   HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
+   }
 
if (w->enable == 0) {
/* Pin is unused so left it disabled. */
@@ -6669,8 +6669,12 @@
devinfo, 0, hdaa_sysctl_gpo_config, "A", "GPO configuration");
SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
-   "reconfig", CTLTYPE_INT | CTLFLAG_RW,
+   "reconfig", CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_NEEDGIANT,
dev, 0, hdaa_sysctl_reconfig, "I", "Reprocess configuration");
+   SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
+   SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
+   "init_clear", CTLFLAG_RW,
+   >init_clear, 1,"Clear initial pin widget configuration");
bus_generic_attach(dev);
return (0);
 }

# svn diff -r342378 hdaa.h
Index: hdaa.h
===
--- hdaa.h  (revisión: 342378)
+++ hdaa.h  (copia de trabajo)
@@ -214,6 +214,7 @@
struct hdaa_chan*chans;
struct callout  poll_jack;
int poll_ival;
+   uint32_tinit_clear;
 };
 
 #define HDAA_CHN_RUNNING   0x0001


If one looks into a svn log of the file hdaa.c it seems that one of the two 
changes 
r358333 or r350078 must have caused the problem:

# svn log hdaa.c


r365085 | mjg | 2020-09-01 23:27:34 +0200 (mar. 01 de sept. de 2020) | 2 líneas

sound: clean up empty lines in .c and .h files


r360076 | emaste | 2020-04-18 20:25:30 +0200 (sáb. 18 de abr. de 2020) | 4 
líneas

hda: remove hda*_lockowned macros

These are not used anywhere.

Re: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[Graham Perrin]

On 13/12/2020 17:25, John Kennedy wrote:

On Sun, Dec 13, 2020 at 08:19:30AM +, Graham Perrin wrote:

Please: is there some way to include openzfs-kmod at buildkernel time?

To work around
 I habitually
remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf
before performing the build:

zfs_load="YES"
openzfs_load="NO"

Isn't openzfs-kmod on 13-CURRENT more or less moot since r36474, the OpenZFS
merge, ~2020/8/25? …


Not entirely moot; for 
 the description for 
the most recent commit refers to building on 13-CURRENT


___
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: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[John Kennedy]

On Sun, Dec 13, 2020 at 08:19:30AM +, Graham Perrin wrote:
> Please: is there some way to include openzfs-kmod at buildkernel time?
> 
> To work around 
>  I habitually 
> remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf 
> before performing the build:
> 
> zfs_load="YES"
> openzfs_load="NO"

Isn't openzfs-kmod on 13-CURRENT more or less moot since r36474, the OpenZFS
merge, ~2020/8/25?  That ticket was opened on 2019/7/28, pre-merge.

Now, I still see recent updates on openzfs-kmod port so the question might
still be relevant for non-13 or if you're just using the port for reasons or
anywhere older than 13 (12.2, etc).
___
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"

kern.cam…delay, suspend and ZFS pools on USB (was: rc.d/zpool runs before ada(4) attaches)

[Graham Perrin]

On 01/12/2020 20:23, tech-lists wrote:

On Tue, Dec 01, 2020 at 08:34:33AM -0700, Ian Lepore wrote:

On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:


You can define these in /boot/loader.conf:
#kern.cam.boot_delay="1" # Delay (in ms) of root mount for CAM
bus
#kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI

Maybe that helps.

Ronald.



Those settings control waiting before mounting root.  Harry's problem
is that root is mounted quickly, before other drives are ready for zfs.

The zpool script waits for 'disks'.  It would be nice if the cam
subsystem had something like a sysctl it set to indicate when initial
probing for disks was done, then there could be an rc.d/camprobe script
with 'PROVIDE: disks' which waits for the probing to complete.

-- Ian


kern.cam.boot_delay should still fix it because what is required is a 
delay
while the devices (all of the disks, zfs or not) get ready. Because 
root has to happen before disks/zfs. 



Where a pool is on a USB 2.0 device: might kern.cam.boot_delay, or some 
other delay, negate the need to export the pool before suspending the 
computer?


Related: 



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

(239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod

[Graham Perrin]

Please: is there some way to include openzfs-kmod at buildkernel time?

To work around 
 I habitually 
remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf 
before performing the build:


zfs_load="YES"
openzfs_load="NO"

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