Re: Running multiple instances of pflogd
> Am 02.06.2022 um 22:42 schrieb Pantelis Roditis :
>
> Hi everyone,
>
> I recently started running multiple pflogd instances and noticed that
> /etc/rc.d/pflogd killed/restarted every running instance.
> The same happened from newsyslog rotations as well.
I think the issue is more general. It applies whenever multiple instances of
any service are needed.
I have a similar issue with php_fpm which I am using in multiple PHP versions
and with different settings (chroot(2) for httpd(8) or without chroot(2) for
Apache httpd).
I some cases the fix may be a more specific pexp. However this depends, as you
have noted, on what parameters the executable is called with and whether they
are sufficient to differentiate between the running service instances.
In general running multiple instances of the same service does not seem to be
supported out of the box by OpenBSD and specifically by the rc(8)
infrastructure. It can be made to work in some cases but it feels kind of like
a hack.
>
> After suggestions by brynet, sthen and ajacoutot (thank you guys)
> I updated pexp to use a combination of `[running]` and `daemon_flags`
>
> pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}“
I used a similar solution for php_fpm, differentiating on the names of the
different config files used for the alternate versions of the service (which
are specified using rcctl set flags ….
An alternate solution would require duplicating the binaries under different
names. But that becomes a maintenance nightmare when there are updates. Note:
Symlinks don’t work for this. And using hard links may also have issues if the
inode changes when updating.
>
> However, the default pflogd does not start with any flags set, so in
> order to make this work I had to either set the flags for pflogd
>
> rcctl set pflogd flags -s 160 -i pflog0 -f /var/log/pflog
>
> or add something like this to /etc/rc.d/pflogd
>
> : ${daemon_flags:="-s 160 -i pflog0 -f /var/log/pflog"}
> pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"
>
> It was suggested by stehn that a diff may worth submitting, but i dont
> know which of the two options is preferred, if any
>
> In the first case we have to set flags for pflogd which no other base
> daemon does at the moment, other than maybe amd_master?
>
> In the second case we set default flags inside the rc script and this
> introduces an unnecessary dependency to update this script whenever the
> default flags or their order changes.
>
> These changes are only needed for when someone needs to run more than
> one instance of pflogd, in which case they will have to copy the
> default /etc/rc.d/pflogd and/or modify it anyways (e.g. for the interface
> name in rc_pre).
Right! So the choices are:
1) Leave /etc/rc.d/ as is, and only run modified duplicates.
2) Modify /etc/rc.d/ to ensure a unique pexp when dealing with
multiple instances, but you still need to create modified duplicates for the
additional instances.
My choice would be (1). It does not change the things installed by the base
system or from packages. Whenever something is updated, manual checks and
potentially adjustments may be required anyway. Seems a bit cleaner that way.
Less dependencies on the defaults.
Note: For the general case you also need to watch out for configured (or
compiled-in) resources, such as sockets, network ports, log files, config
files, etc.
>
> The diff for the script follows, suggestions/ideas are more than welcome
>
> diff --git etc/rc.d/pflogd etc/rc.d/pflogd
> index 963616775..620d2daef 100644
> --- etc/rc.d/pflogd
> +++ etc/rc.d/pflogd
> @@ -6,7 +6,9 @@ daemon="/sbin/pflogd"
>
> . /etc/rc.d/rc.subr
>
> -pexp="pflogd: \[priv\]"
> +: ${daemon_flags:="-s 160 -i pflog0 -f /var/log/pflog"}
> +
> +pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"
>
> rc_pre() {
>
>if pfctl -si | grep -q Enabled; then
That would be similar to option (2) which I would not prefer.
Just my 2¢…
Mike
Running multiple instances of pflogd
Hi everyone,
I recently started running multiple pflogd instances and noticed that
/etc/rc.d/pflogd killed/restarted every running instance.
The same happened from newsyslog rotations as well.
After suggestions by brynet, sthen and ajacoutot (thank you guys)
I updated pexp to use a combination of `[running]` and `daemon_flags`
pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"
However, the default pflogd does not start with any flags set, so in
order to make this work I had to either set the flags for pflogd
rcctl set pflogd flags -s 160 -i pflog0 -f /var/log/pflog
or add something like this to /etc/rc.d/pflogd
: ${daemon_flags:="-s 160 -i pflog0 -f /var/log/pflog"}
pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"
It was suggested by stehn that a diff may worth submitting, but i dont
know which of the two options is preferred, if any
In the first case we have to set flags for pflogd which no other base
daemon does at the moment, other than maybe amd_master?
In the second case we set default flags inside the rc script and this
introduces an unnecessary dependency to update this script whenever the
default flags or their order changes.
These changes are only needed for when someone needs to run more than
one instance of pflogd, in which case they will have to copy the
default /etc/rc.d/pflogd and/or modify it anyways (e.g. for the interface
name in rc_pre).
The diff for the script follows, suggestions/ideas are more than welcome
diff --git etc/rc.d/pflogd etc/rc.d/pflogd
index 963616775..620d2daef 100644
--- etc/rc.d/pflogd
+++ etc/rc.d/pflogd
@@ -6,7 +6,9 @@ daemon="/sbin/pflogd"
. /etc/rc.d/rc.subr
-pexp="pflogd: \[priv\]"
+: ${daemon_flags:="-s 160 -i pflog0 -f /var/log/pflog"}
+
+pexp="pflogd: \[running\]${daemon_flags:+ ${daemon_flags}}"
rc_pre() {
if pfctl -si | grep -q Enabled; then
[no subject]
-- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: iwm driver not working on starlabs starlite iv laptop
On Wed, Jun 01, 2022 at 12:32:45AM +0100, Chris Narkiewicz wrote:
> > Can you please apply this patch, boot the resulting kernel, and
> > show me the new line that now appears in dmesg? It will show us
> > the antenna configuration of your device.
>
> So I applied the patch and this is the result:
>
> iwm0: hw rev 0x310, fw ver 46.4e1ceb39.0, address 20:1e:88:77:66:72
> iwm0: valid Tx antenna masks: phycfg: 0x3 nvm: 0x1
>
> I hope it leads somewhere. Thank you.
Let's try this patch. Does it help?
diff 98c04410ecc965030a8aa6f07102b14a69145a48
54780b8cb6da1f75e7566af8b6117d93126a96b1
blob - 6de80bd303e3c03a8f4eb2533f54f65d4deebdd3
blob + 8b411c541a334905e8c6ba883bd8cabff15e999d
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -331,6 +331,9 @@ int iwm_nvm_read_chunk(struct iwm_softc *, uint16_t, u
uint8_t *, uint16_t *);
intiwm_nvm_read_section(struct iwm_softc *, uint16_t, uint8_t *,
uint16_t *, size_t);
+uint8_tiwm_fw_valid_tx_ant(struct iwm_softc *);
+uint8_tiwm_fw_valid_rx_ant(struct iwm_softc *);
+intiwm_valid_siso_ant_rate_mask(struct iwm_softc *);
void iwm_init_channel_map(struct iwm_softc *, const uint16_t * const,
const uint8_t *nvm_channels, int nchan);
intiwm_mimo_enabled(struct iwm_softc *);
@@ -3038,6 +3041,23 @@ iwm_fw_valid_rx_ant(struct iwm_softc *sc)
return rx_ant;
}
+int
+iwm_valid_siso_ant_rate_mask(struct iwm_softc *sc)
+{
+ uint8_t valid_tx_ant = iwm_fw_valid_tx_ant(sc);
+
+ /*
+* According to the Linux driver, antenna B should be preferred
+* on 9k devices since it is not shared with bluetooth. However,
+* there are 9k devices which do not support antenna B at all.
+*/
+ if (sc->sc_device_family == IWM_DEVICE_FAMILY_9000 &&
+ (valid_tx_ant & IWM_ANT_B))
+ return IWM_RATE_MCS_ANT_B_MSK;
+
+ return IWM_RATE_MCS_ANT_A_MSK;
+}
+
void
iwm_init_channel_map(struct iwm_softc *sc, const uint16_t * const nvm_ch_flags,
const uint8_t *nvm_channels, int nchan)
@@ -6628,10 +6648,8 @@ iwm_tx_fill_cmd(struct iwm_softc *sc, struct iwm_node
if ((ni->ni_flags & IEEE80211_NODE_VHT) == 0 &&
iwm_is_mimo_ht_plcp(rinfo->ht_plcp))
rate_flags = IWM_RATE_MCS_ANT_AB_MSK;
- else if (sc->sc_device_family == IWM_DEVICE_FAMILY_9000)
- rate_flags = IWM_RATE_MCS_ANT_B_MSK;
else
- rate_flags = IWM_RATE_MCS_ANT_A_MSK;
+ rate_flags = iwm_valid_siso_ant_rate_mask(sc);
if (IWM_RIDX_IS_CCK(ridx))
rate_flags |= IWM_RATE_MCS_CCK_MSK;
if ((ni->ni_flags & IEEE80211_NODE_HT) &&
@@ -9248,13 +9266,8 @@ iwm_set_rate_table_vht(struct iwm_node *in, struct iwm
IWM_RATE_VHT_MCS_NSS_MSK;
if (ni->ni_vht_ss > 1)
tab |= IWM_RATE_MCS_ANT_AB_MSK;
- else {
- if (sc->sc_device_family ==
- IWM_DEVICE_FAMILY_9000)
- tab |= IWM_RATE_MCS_ANT_B_MSK;
- else
- tab |= IWM_RATE_MCS_ANT_A_MSK;
- }
+ else
+ tab |= iwm_valid_siso_ant_rate_mask(sc);
/*
* First two Tx attempts may use 80MHz/40MHz/SGI.
@@ -9294,10 +9307,7 @@ iwm_set_rate_table_vht(struct iwm_node *in, struct iwm
} else {
/* Fill the rest with the lowest possible rate. */
tab = iwm_rates[ridx_min].plcp;
- if (sc->sc_device_family == IWM_DEVICE_FAMILY_9000)
- tab |= IWM_RATE_MCS_ANT_B_MSK;
- else
- tab |= IWM_RATE_MCS_ANT_A_MSK;
+ tab |= iwm_valid_siso_ant_rate_mask(sc);
if (ni->ni_vht_ss > 1 && lqcmd->mimo_delim == 0)
lqcmd->mimo_delim = i;
}
@@ -9378,10 +9388,8 @@ iwm_set_rate_table(struct iwm_node *in, struct iwm_lq_
if (iwm_is_mimo_ht_plcp(ht_plcp))
tab |= IWM_RATE_MCS_ANT_AB_MSK;
- else if (sc->sc_device_family == IWM_DEVICE_FAMILY_9000)
- tab |= IWM_RATE_MCS_ANT_B_MSK;
else
- tab |= IWM_RATE_MCS_ANT_A_MSK;
+ tab |= iwm_valid_siso_ant_rate_mask(sc);
if (IWM_RIDX_IS_CCK(ridx))
tab |= IWM_RATE_MCS_CCK_MSK;
@@ -9395,10 +9403,7 @@ iwm_set_rate_table(struct iwm_node *in, struct iwm_lq_
tab = iwm_rates[ridx_min].plcp;
if (IWM_RIDX_IS_CCK(ridx_min))
tab |= IWM_RATE_MCS_CCK_MSK;
- if (sc->sc_device_family =
