Re: [arch-dev-public] openssl 3.0

[Pascal]

just like Gene, thank you for all this good work and this great Linux
distribution !

Le ven. 4 nov. 2022 à 10:40, Genes Lists  a écrit :

>
> Just a note to thank you all for pushing this over the line. Obviously a
> huge effort and very big thanks!!
>
> Everything I've tested so far works just fine :
>dovecot, postfix, ldns, rust/cargo, nginx-mainline, cyrus-sasl, nsd,
>unbound, cryptsetup, stunnel and kernel signed modules.
>
> Looking forward to testing python 3.11 as well!!
>
> Thank you for all the work you do keeping things running so well.
>
> gene
>
>

(Arch)Linux source routing help

[Pascal]

hi,

where can I get help with this ?

my problem is this:

I'm on a corporate network that is filtered (proxy) and I need to run some
tests on a virtual machine that needs to have direct access to the Internet.
I set up this configuration and try to route everything that comes out of
tap0 to wlan0 and then to Internet.

   -   -
\ /
 \   /
  \ /
  +\---+   +---/---+
  |free GW |   |corporate GW   |
  |192.168.144.254 |   |10.10.10.254/24|
  +|---+   +---|---+
   \  /
+---|-|--+
|HOST  |wlan0   |  |eth0 |
|  |192.168.144.1/24|  |10.10.10.1/24|
|  ++  +-|
||  |  +-+
  |
|  |tap0 |   |
|  |192.168.11.254/24|   |
|  +|+   |
|   ||
| +-|+   |
| |VM  |eth0 |   |
| ||192.168.11.1/24  |   |
| |+-|   |
| +--+   |
++

(Arch)Linux source routing help

[Pascal]

*(sorry, the previous message is gone a bit fast)*

hi,

where can I get help for this ?

my problem is :

I'm on a corporate network that is filtered (proxy) and I need to run some
tests on a virtual machine that needs to have direct access to the Internet.
I set up this configuration and try to route everything that comes out of
tap0 to wlan0 and then to Internet.

   -   -
\ /
 \   /
  \ /
  +\---+   +---/---+
  |free GW |   |corporate GW   |
  |192.168.144.254 |   |10.10.10.254/24| 
  +|---+   +---|---+
   \  /
+---|-|--+
|HOST  |wlan0   |  |eth0 |
|  |192.168.144.1/24|   |10.10.10.1/24|

|  ++  +-|
||
|  +-+   |
|  |tap0 |   |
|  |192.168.11.254/24|    |
|  +|+   |
|   ||
| +-|+   |
| |VM  |eth0 |   |
| ||192.168.11.1/24  |   |
| |+-|   |
| +--+   |
++

here are the commands used:

# ip tuntap add tap0 mode tap user me
# ip addr add 192.168.11.254/24 dev tap0
# ip link set tap0 down
# echo 11 tap0 >> /etc/iproute2/rt_tables
# ip rule add from 192.168.11.254 lookup tap0
# ip route add default via 192.168.144.254 dev wlan0 proto dhcp src
192.168.144.1
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

I can ping 8.8.8.8 from my virtual machine but all traffic (host/corporate)
now seems to flow through wlan0 (tshark -i wlan0)...

regards, lacsaP.

Re: (Arch)Linux source routing help

[Pascal]

yes, the table parameter was missing !

# ip route add default via 192.168.144.254 dev wlan0 *table tap0*

Le mer. 9 nov. 2022 à 17:10, Felix Yan  a écrit :

> On 11/9/22 17:52, Pascal wrote
> > # ip tuntap add tap0 mode tap user me
> > # ip addr add 192.168.11.254/24 dev tap0
> > # ip link set tap0 down
> > # echo 11 tap0 >> /etc/iproute2/rt_tables
> > # ip rule add from 192.168.11.254 lookup tap0 > # ip route add default
> via 192.168.144.254 dev wlan0 proto dhcp src
> 192.168.144.1
>
> Assuming your `ip rule` is trying to apply policy routing on `from
> 192.168.11.254` only, the ip route entry added here is missing a table
> parameter.
>
> You probably want instead:
>
> # ip route add default via 192.168.144.254 dev wlan0 table tap0
>
> > # echo 1 > /proc/sys/net/ipv4/ip_forward
> > # iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERAD
> --
> Regards,
> Felix Yan
>
>

Fwd: bio_check_ro @ blk-core.c

[Pascal]

hi,

I come to you for lack of feedback (I think the Linux kernel developers
have other cats to whip :-))
would one of you have the answer or a track to follow concerning the
question below ?
the encountered compilation error is behind the forwarded email.

regards, lacsaP.

-- Forwarded message -
De : Pascal 
Date: mer. 8 mars 2023 à 14:09
Subject: bio_check_ro @ blk-core.c

hi,

I'm addressing you because you intervened (commit
<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/block/blk-core.c?h=v6.1.15&id=bdb7d420c6f6d2618d4c907cd7742c3195c425e2>)
in the function bio_check_ro @ blk-core.c @ Linux-LTS-6.1.15.
the last time I intervened on this file (@ Linux-LTS-5.10.19 for personal
use), it was to replace "return false;" by "return true;", which
theoretically should prevent the possible writing on a device locked in
read-only mode (see here
<https://github.com/vitaly-kamluk/Linux-write-blocker/tree/master/kernel>
or here <https://github.com/msuhanov/Linux-write-blocker>).
with @ Linux-LTS-6.1.15, if I insert "return true;", I now have a
compilation error.
in your opinion, is there still a need to "fix" blk-core.c to prevent
writing to a read-only locked device and if so, can you help me implement
this fix?

regards, lacsaP.
-- End forwarded message -

  SYNCinclude/config/auto.conf
  CC  arch/x86/kernel/asm-offsets.s
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  DESCEND bpf/resolve_btfids
  CC  block/bdev.o
  CC  block/fops.o
  CC  block/bio.o
  CC  block/elevator.o
  CC  block/blk-core.o
block/blk-core.c: In function 'bio_check_ro':
block/blk-core.c:496:24: error: 'return' with a value, in function
returning void [-Werror=return-type]
  496 | return true;
  |^~~~
block/blk-core.c:488:20: note: declared here
  488 | static inline void bio_check_ro(struct bio *bio)
  |^~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:250: block/blk-core.o] Error 1
make[1]: *** [scripts/Makefile.build:500: block] Error 2
make: *** [Makefile:2005: .] Error 2

Re: bio_check_ro @ blk-core.c

[Pascal]

hi Emil,

in view of your answer and after rereading my email, I realize that I was
confused in my request.
here it is, I hope, more clearly reformulated :-)

first of all, I use ArchLinux to, from time to time, compile the slightly
modified LTS kernel, and this from PKGBUILD provided by ArchLinux at some
point.

some technologies such as LVM do not take into account the read-only
applied on a block device.
see the two links provided in the previous exchanges for more details...


until now, I recompiled the kernel by applying a slight modification to the
bio_check_ro function present in the blk-core.c source file.
the last time I made this modification was on the Linux-LTS-5.10.19 kernel :
*(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v5.10.19
<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v5.10.19>)*

$ diff   -u   5.10.19.original/blk-core.c   5.10.19.me/blk-core.c
--- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100
+++ 5.10.19.me/blk-core.c 2023-03-15 13:44:02.353596114 +0100
@@ -706,7 +706,7 @@
"Trying to write to read-only block-device %s (partno %d)\n",
  bio_devname(bio, b), part->partno);
  /* Older lvm-tools actually trigger this */
- return false;
+ return true;
  }

  return false;

the compilation of the modified LTS 5.10.19 kernel went well and the
correction seems to do the job...


since this last time (2022/01), the source file blk-core.c has been
modified a lot and the bio_check_ro function is part of these modifications
:
*(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.1.15
<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.1.15>)*

$ diff   -u   5.10.19.original/blk-core.c   6.1.15.original/blk-core.c
--- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100
+++ 6.1.15.original/blk-core.c 2023-03-15 13:50:36.560271323 +0100
@@ -14,11 +14,10 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
...
@@ -681,40 +483,22 @@
 }

 late_initcall(fail_make_request_debugfs);
-
-#else /* CONFIG_FAIL_MAKE_REQUEST */
-
-static inline bool should_fail_request(struct hd_struct *part,
-   unsigned int bytes)
-{
-   return false;
-}
-
 #endif /* CONFIG_FAIL_MAKE_REQUEST */

-static inline bool bio_check_ro(struct bio *bio, struct hd_struct *part)
+static inline void bio_check_ro(struct bio *bio)
 {
-   const int op = bio_op(bio);
-
-   if (part->policy && op_is_write(op)) {
-   char b[BDEVNAME_SIZE];
-
+   if (op_is_write(bio_op(bio)) && bdev_read_only(bio->bi_bdev)) {
if (op_is_flush(bio->bi_opf) && !bio_sectors(bio))
-   return false;
-
-   WARN_ONCE(1,
-  "Trying to write to read-only block-device %s (partno %d)\n",
-   bio_devname(bio, b), part->partno);
+   return;
+   pr_warn("Trying to write to read-only block-device %pg\n",
+   bio->bi_bdev);
/* Older lvm-tools actually trigger this */
-   return false;
}
-
-   return false;
 }
...


when I introduce my little modification (see diff below) in the code,
makepkg fails to compile with the error "return with a value in function
returning void" (see makepkg below) :

$ diff   -u   6.1.15.original/blk-core.c   6.1.15.me/blk-core.c
--- 6.1.15.original/blk-core.c 2023-03-15 13:50:36.560271323 +0100
+++ 6.1.15.me/blk-core.c 2023-03-15 13:56:15.246945330 +0100
@@ -493,6 +493,7 @@
  pr_warn("Trying to write to read-only block-device %pg\n",
  bio->bi_bdev);
  /* Older lvm-tools actually trigger this */
+ return true;
  }
 }

$ makepkg
...
  CC  block/blk-core.o
block/blk-core.c: In function 'bio_check_ro':
block/blk-core.c:496:24: error: 'return' with a value, in function
returning void [-Werror=return-type]
  496 | return true;
  |^~~~
block/blk-core.c:488:20: note: declared here
  488 | static inline void bio_check_ro(struct bio *bio)
  |^~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:250: block/blk-core.o] Error 1
make[1]: *** [scripts/Makefile.build:500: block] Error 2
make: *** [Makefile:2005: .] Error 2


so, how to modify the current code of the bio_check_ro function to get the
desired result (eg. writes KO on RO blockdevice) ?
with the changes in the blk-core.c source code since version 5.10.19, is it
still necessary to tweak the bio_check_ro function to disallow technologies
that ignore the read-only block?

regards, lacsaP.

Le mer. 15 mars 2023 à 12:37, Emil Velikov  a
écrit :

> Greetings Pascal,
>
> Couple of suggestions from the peanut gallery, Take them with a heavy
> pinch of salt:
>  - Is the issue happening with upstream code from kernel.org?
>  - Consi

Re: bio_check_ro @ blk-core.c

[Pascal]

c9098c64903b56b2d3ac5248d2f34c10e63241a10a35b3  lvm.disk

the same test was performed with for example Linux Software RAID (mdadm)
and the device is not modified (as expected from being locked in read-only
mode).

in conclusion, it seems that LVM, even in recent version, does not take
into account the read-only mode...

regards, lacsaP.


Le mer. 15 mars 2023 à 16:36, Emil Velikov  a
écrit :

> Greetings Pascal,
>
> After following the links I see what's happening. Essentially:
>  - Kernel gained RO/RW correctness check - circa Jan 2018, kernel
> commit 721c7fc701c71f693307d274d2b346a1ecd4a534
>  - LVM was initially buggy but later fixed, circa Mar 2018,
>  - Kernel check got partially reverted because broken LVM is still
> used - circa Aug 2018, kernel commit
> a32e236eb93e62a0f692e79b7c3c9636689559b9
>  - People used an out of tree patch, reinstating the correctness check
>  - The function return type was dropped since it is unused - Sep 2022,
> kernel commit bdb7d420c6f6d2618d4c907cd7742c3195c425e2
>  - kernel patch no longer applies, correct behaviour cannot be enforced
>
> To unblock yourself, it will be a matter of reverting
> bdb7d420c6f6d2618d4c907cd7742c3195c425e2 and then
> a32e236eb93e62a0f692e79b7c3c9636689559b9.
>
> For the mid/long run, one should consider a proper upstream solution:
>
> Assuming I'm in your position, I would dig through the data in the
> linked commits and estimate which/how many distributions ship with
> buggy LVM. Then formulate a comprehensive cover letter, proposing a)
> reverts (if LVM is no longer used in the wild) or b) reverts && a
> (KCONFIG, sysctl, other) toggle to control the behaviour.
>
> Hope that helps,
> Emil
>
> On Wed, 15 Mar 2023 at 13:38, Pascal  wrote:
> >
> > hi Emil,
> >
> > in view of your answer and after rereading my email, I realize that I
> was confused in my request.
> > here it is, I hope, more clearly reformulated :-)
> >
> > first of all, I use ArchLinux to, from time to time, compile the
> slightly modified LTS kernel, and this from PKGBUILD provided by ArchLinux
> at some point.
> >
> > some technologies such as LVM do not take into account the read-only
> applied on a block device.
> > see the two links provided in the previous exchanges for more details...
> >
> >
> > until now, I recompiled the kernel by applying a slight modification to
> the bio_check_ro function present in the blk-core.c source file.
> > the last time I made this modification was on the Linux-LTS-5.10.19
> kernel :
> > (
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v5.10.19
> )
> >
> > $ diff   -u   5.10.19.original/blk-core.c   5.10.19.me/blk-core.c
> > --- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100
> > +++ 5.10.19.me/blk-core.c 2023-03-15 13:44:02.353596114 +0100
> > @@ -706,7 +706,7 @@
> > "Trying to write to read-only block-device %s (partno %d)\n",
> >   bio_devname(bio, b), part->partno);
> >   /* Older lvm-tools actually trigger this */
> > - return false;
> > + return true;
> >   }
> >
> >   return false;
> >
> > the compilation of the modified LTS 5.10.19 kernel went well and the
> correction seems to do the job...
> >
> >
> > since this last time (2022/01), the source file blk-core.c has been
> modified a lot and the bio_check_ro function is part of these modifications
> :
> > (
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.1.15
> )
> >
> > $ diff   -u   5.10.19.original/blk-core.c   6.1.15.original/blk-core.c
> > --- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100
> > +++ 6.1.15.original/blk-core.c 2023-03-15 13:50:36.560271323 +0100
> > @@ -14,11 +14,10 @@
> >   */
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> > -#include 
> > ...
> > @@ -681,40 +483,22 @@
> >  }
> >
> >  late_initcall(fail_make_request_debugfs);
> > -
> > -#else /* CONFIG_FAIL_MAKE_REQUEST */
> > -
> > -static inline bool should_fail_request(struct hd_struct *part,
> > -   unsigned int bytes)
> > -{
> > -   return false;
> > -}
> > -
> >  #endif /* CONFIG_FAIL_MAKE_REQUEST */
> >
> > -static inline bool bio_check_ro(struct bio *bio, struct hd_struct *part)
> > +static inline void bio_check_ro(struct bio *bio)
> >  {
> > -   const int op = bio_op(bio);
> > -
> > -   if (part->policy && op_is_write(op)) {
> > -   char b[BDE

Re: bio_check_ro @ blk-core.c

[Pascal]

0 MiB
Free  PE / Size   9 / 36.00 MiB
VG UUID   sttYAJ-VmEf-biZh-C8Uh-jUCK-orFO-WVNX6t

root@archiso ~ #  vgchange -ay test.lvm
1 logical volume(s) in volume group "test.lvm" now active

/tmp : sha256sum lvm.disk
c39d62a5e9f87dc9098c64903b56b2d3ac5248d2f34c10e63241a10a35b3  lvm.disk

root@archiso ~ # lvdisplay
--- Logical volume ---
LV Path/dev/test.lvm/lvm.test
LV Namelvm.test
VG Nametest.lvm
LV UUIDG1y4A0-LbbZ-na9w-AJrQ-jVtc-pKDo-RKgc0S
LV Write Accessread/write (activated read only)
LV Creation host, time scalpel, 2019-03-12 14:59:02 +
LV Status  available
# open 0
LV Size64.00 MiB
Current LE 16
Mirrored volumes   3
Segments   1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device   254:6

root@archiso ~ # mount /dev/test.lvm/lvm.test /mnt
mount: /mnt: WARNING: source write-protected, mounted read-only.

root@archiso ~ # ll /mnt
total 16
drwx-- 2 root root 12288 Mar 12  2019 lost+found
-rwxr-xr-x 1 root root  3155 Mar 12  2019 lvm.md

root@archiso ~ # umount /mnt

(qemu) device_del usbkey

Mar 16 10:21:07 archiso kernel: usb 2-3: USB disconnect, device number 3
Mar 16 10:21:07 archiso kernel: sd 6:0:0:0: [sda] Synchronizing SCSI
cache
Mar 16 10:21:07 archiso kernel: sd 6:0:0:0: [sda] Synchronize Cache(10)
failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Mar 16 10:21:07 archiso (udev-worker)[1276]: sda2: Process
'/usr/local/sbin/rodev /dev/sda2' failed with exit code 1.
Mar 16 10:21:07 archiso systemd-homed[268]: block device
/sys/devices/pci:00/:00:03.0/usb2/2-3/2-3:1.0/host6/target6:0:0/6:0:0:0/block/sda/sda2
has been removed.
Mar 16 10:21:07 archiso (udev-worker)[1275]: sda1: Process
'/usr/local/sbin/rodev /dev/sda1' failed with exit code 1.
Mar 16 10:21:07 archiso systemd-homed[268]: block device
/sys/devices/pci:00/:00:03.0/usb2/2-3/2-3:1.0/host6/target6:0:0/6:0:0:0/block/sda/sda1
has been removed.
Mar 16 10:21:07 archiso (udev-worker)[1277]: sda3: Process
'/usr/local/sbin/rodev /dev/sda3' failed with exit code 1.
Mar 16 10:21:07 archiso systemd-homed[268]: block device
/sys/devices/pci:00/:00:03.0/usb2/2-3/2-3:1.0/host6/target6:0:0/6:0:0:0/block/sda/sda3
has been removed.
Mar 16 10:21:07 archiso (udev-worker)[1276]: sda: Process
'/usr/local/sbin/rodev /dev/sda' failed with exit code 1.
Mar 16 10:21:07 archiso systemd-homed[268]: block device
/sys/devices/pci:00/:00:03.0/usb2/2-3/2-3:1.0/host6/target6:0:0/6:0:0:0/block/sda
has been removed.

/tmp : sha256sum lvm.disk
c39d62a5e9f87dc9098c64903b56b2d3ac5248d2f34c10e63241a10a35b3  lvm.disk

LVM, even in recent version, does not take into account the read-only
mode...

regards, lacsaP.

Le mer. 15 mars 2023 à 16:36, Emil Velikov  a
écrit :

> Greetings Pascal,
>
> After following the links I see what's happening. Essentially:
>  - Kernel gained RO/RW correctness check - circa Jan 2018, kernel
> commit 721c7fc701c71f693307d274d2b346a1ecd4a534
>  - LVM was initially buggy but later fixed, circa Mar 2018,
>  - Kernel check got partially reverted because broken LVM is still
> used - circa Aug 2018, kernel commit
> a32e236eb93e62a0f692e79b7c3c9636689559b9
>  - People used an out of tree patch, reinstating the correctness check
>  - The function return type was dropped since it is unused - Sep 2022,
> kernel commit bdb7d420c6f6d2618d4c907cd7742c3195c425e2
>  - kernel patch no longer applies, correct behaviour cannot be enforced
>
> To unblock yourself, it will be a matter of reverting
> bdb7d420c6f6d2618d4c907cd7742c3195c425e2 and then
> a32e236eb93e62a0f692e79b7c3c9636689559b9.
>
> For the mid/long run, one should consider a proper upstream solution:
>
> Assuming I'm in your position, I would dig through the data in the
> linked commits and estimate which/how many distributions ship with
> buggy LVM. Then formulate a comprehensive cover letter, proposing a)
> reverts (if LVM is no longer used in the wild) or b) reverts && a
> (KCONFIG, sysctl, other) toggle to control the behaviour.
>
> Hope that helps,
> Emil
>
> On Wed, 15 Mar 2023 at 13:38, Pascal  wrote:
> >
> > hi Emil,
> >
> > in view of your answer and after rereading my email, I realize that I
> was confused in my request.
> > here it is, I hope, more clearly reformulated :-)
> >
> > first of all, I use ArchLinux to, from time to time, compile the
> slightly modified LTS kernel, and this from PKGBUILD provided by ArchLinux
> at some point.
> >
> > some technologies such as LVM do not take into ac

Re: [arch-general] New LXQt (1.0.0) with big text size, affecting other Qt apps

[Pascal via arch-general]

hi,
I have the same with OpenBox.
I run obconf, (re)select the same fonts and sizes, save the configuration
and restart the graphical environment : OK now.
regards.

Le jeu. 11 nov. 2021 à 21:04, Uwe Sauter via arch-general <
arch-general@lists.archlinux.org> a écrit :

>
>
> Am 11.11.21 um 12:09 schrieb Joan Figueras via arch-general:
> > On 11/11/21 12:04, Archange via arch-general wrote:
> >> Le 11/11/2021 à 12:21, Javier via arch-general a écrit :
> >>> On 11/11/21 01:32, Uwe Sauter via arch-general wrote:
> 
>  I'm experiencing the same with Mate. FullHD on 24" display shows
> fonts about twice the normal size.
> 
>  The workaround I found (not reboot safe) is to open the display
> settings and force a scaling factor
>  of 100%. Scaling factor "auto" won't do any good.
> 
> >>>
> >>> Ohh, weird, since I only experience that on Qt stuff, meaning I see no
> issues on GTK stuff, but I don't use a GTK DE
> >>> neither compositor/WM, :(...  Well, I got as well as the LXQt upgrade,
> Xorg and KWin upgrades:
> >>>
> >>> xorg-server-common (1.20.13-3 -> 21.1.1-2)
> >>> xorg-server (1.20.13-3 -> 21.1.1-2)
> >>>
> >>> So perhaps a Xorg issue instead of a LXQt/KWin one?
> >>
> >> I don’t have time to investigate, but my sddm is affected too. So
> definitively not LXQt nor KWin, also my Plasma
> >> session using Kwin is not affected (I use a scaling factor of ×2 there).
> >>
> >> So I would say something plain Qt and Xorg related, maybe because Xorg
> changed the way it reports the DPI and Qt
> >> behaviour changed because of that.
> >>
> > I think it's related with this bug:
> https://bugs.archlinux.org/task/72661
> >
> > For me, in XFCE, upgrading to Xorg 21.1.1-3 fixed the issue.
> >
>
> I can confirm that updating to 21.1.1-3 make the issue disappear in
> combination with Mate.
>
>
> >
> > Cheers
> >
>

[arch-general] sound problem with chromium

[Pascal via arch-general]

hi,

I have an ArchLinux installed on a usb disk (eg. "mobile").

~ # uname -r
5.15.37-1-lts
~ # pacman -Q | egrep 'alsa|chromium|firefox|mplayer'
alsa-lib 1.2.6.1-1
alsa-topology-conf 1.2.5.1-1
alsa-ucm-conf 1.2.6.3-1
alsa-utils 1.2.6-1
chromium 101.0.4951.54-1
firefox 100.0-1
mplayer 38359-1

when it runs on my Dell Latitude E5250, Chromium works without any
difficulty to play a YouTube video for example : the sound is ok (same for
Firefox or Mplayer).

on the other hand, when it runs on my Lenovo ThinkPad X1 Carbon, Chromium
has problems with the sound (which is not the case for Firefox or Mplayer
which both produce sound).
it happens from time to time in this (hardware) environment that Chromium
produces sound and the next moment (simple stop/restart of the browser) it
fails (without anything being done in between) !
another surprising thing is that if I access a video (zunRcH4nUPI) this way
"chromium https://www.youtube.com/"; (and then click on the desired video) I
often don't get any sound while if I access it this way "chromium
https://www.youtube.com/watch?v=zunRcH4nUPI"; the sound works !

I spent a lot of time trying to understand the problem and looking for a
solution/track on the internet but, having found nothing, I throw a bottle
in the water...

regards, lacsaP.

Re: [arch-general] sound problem with chromium

[Pascal via arch-general]

I just had a look in the wiki and did not see anything special.

sof-firmware is installed.
~ # pacman -Q | grep 'sof'
sof-firmware 2.1.1-1

the problem seems to be between chromium and my lenovo.
I will test on other machines soon...


Le jeu. 5 mai 2022 à 12:36, Damjan Georgievski via arch-general <
arch-general@lists.archlinux.org> a écrit :

> > on the other hand, when it runs on my Lenovo ThinkPad X1 Carbon, Chromium
> > has problems with the sound
>
> Check the Arch wiki for the requirements of the exact model and
> generation of X1.
>
> a wild guess would be, you need to install `sof-firmware` but it's
> hard to say without more data
>
>
>
> --
> damjan
>

Re: [arch-general] sound problem with chromium

[Pascal via arch-general]

I just did a little test like this:

# user add -m test
# passwd test
# echo "chromium https://youtube.com"; > /home/test/.xinitrc

logoff and then logon (slim) as test.
a first test "bingo", it works, there is sound !
I extend the test : I close Chromium, I reconnect again immediatly and KO,
no sound.
I try again : close the browser and reopen the session as test user but
still KO.

Le jeu. 5 mai 2022 à 13:48, u34--- via arch-general <
arch-general@lists.archlinux.org> a écrit :

> Pascal via arch-general  wrote:
>
> > hi,
> >
> > I have an ArchLinux installed on a usb disk (eg. "mobile").
> >
> > ~ # uname -r
> > 5.15.37-1-lts
> > ~ # pacman -Q | egrep 'alsa|chromium|firefox|mplayer'
> > alsa-lib 1.2.6.1-1
> > alsa-topology-conf 1.2.5.1-1
> > alsa-ucm-conf 1.2.6.3-1
> > alsa-utils 1.2.6-1
> > chromium 101.0.4951.54-1
> > firefox 100.0-1
> > mplayer 38359-1
> >
> > when it runs on my Dell Latitude E5250, Chromium works without any
> > difficulty to play a YouTube video for example : the sound is ok (same
> for
> > Firefox or Mplayer).
> >
> > on the other hand, when it runs on my Lenovo ThinkPad X1 Carbon, Chromium
> > has problems with the sound (which is not the case for Firefox or Mplayer
> > which both produce sound).
> > it happens from time to time in this (hardware) environment that Chromium
> > produces sound and the next moment (simple stop/restart of the browser)
> it
> > fails (without anything being done in between) !
> > another surprising thing is that if I access a video (zunRcH4nUPI) this
> way
> > "chromium https://www.youtube.com/"; (and then click on the desired
> video) I
> > often don't get any sound while if I access it this way "chromium
> > https://www.youtube.com/watch?v=zunRcH4nUPI"; the sound works !
> >
> > I spent a lot of time trying to understand the problem and looking for a
> > solution/track on the internet but, having found nothing, I throw a
> bottle
> > in the water...
> >
> > regards, lacsaP.
>
> Can you try cutting down the environment by running chromium within a
> dedicated X server? That is, run a 2nd, or just one, Xserver, dedicated to
> chromium. Desirbly, without a desktop environment, and without a window
> manager either. Just chromium, nothing else.
>
> I find chromium very problematic, avoiding it as much as I can. Never the
> less, I do have to use it from time to time. And I do think diversity is a
> must have.
>
> --
> u34
>

Re: [arch-general] sound problem with chromium

[Pascal via arch-general]

Alsa directly : no PA or PW.

when i run Chromium from a terminal, i get these two error messages about
Alsa but they also appear when the sound is working :
[4765:4765:0504/164956.649650:ERROR:alsa_util.cc(204)] PcmOpen:
default,Device or resource busy
[4765:4765:0504/164956.649811:ERROR:alsa_util.cc(204)] PcmOpen:
plug:default,Device or resource busy

Le jeu. 5 mai 2022 à 15:46, Jesse Jaara via arch-general <
arch-general@lists.archlinux.org> a écrit :

> Are you using Alsa directly, no pulseaudio or pipewire? Something could be
> wonky with your dmix config and it's getting disabled, thus only a single
> application can have access to the sound playback at once.
>

Re: [arch-general] sound problem with chromium

[Pascal via arch-general]

I checked in my session the concurrent accesses with fuser -v /dev/snd/*
and killed the only one that was present and could interfere (volumeicon *that
was also present with Firefox and Mplayer*).

Le jeu. 5 mai 2022 à 15:50, Pascal  a écrit :

> Alsa directly : no PA or PW.
>
> when i run Chromium from a terminal, i get these two error messages about
> Alsa but they also appear when the sound is working :
> [4765:4765:0504/164956.649650:ERROR:alsa_util.cc(204)] PcmOpen:
> default,Device or resource busy
> [4765:4765:0504/164956.649811:ERROR:alsa_util.cc(204)] PcmOpen:
> plug:default,Device or resource busy
>
> Le jeu. 5 mai 2022 à 15:46, Jesse Jaara via arch-general <
> arch-general@lists.archlinux.org> a écrit :
>
>> Are you using Alsa directly, no pulseaudio or pipewire? Something could be
>> wonky with your dmix config and it's getting disabled, thus only a single
>> application can have access to the sound playback at once.
>>
>

Re: [arch-general] sound problem with chromium

[Pascal via arch-general]

hi,

neither one nor the other.
here is the return of the `aplay -l -L` command on my lenovo :
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=sofhdadsp
sof-hda-dsp,
Default Audio Device
sysdefault:CARD=sofhdadsp
sof-hda-dsp,
Default Audio Device
 Liste des périphériques matériels PLAYBACK 
carte 0 : sofhdadsp [sof-hda-dsp], périphérique 0 : HDA Analog (*) []
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : sofhdadsp [sof-hda-dsp], périphérique 1 : HDA Digital (*) []
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : sofhdadsp [sof-hda-dsp], périphérique 3 : HDMI1 (*) []
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : sofhdadsp [sof-hda-dsp], périphérique 4 : HDMI2 (*) []
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : sofhdadsp [sof-hda-dsp], périphérique 5 : HDMI3 (*) []
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0

snd_hda_intel is loaded with `options snd_hda_intel enable=0,1` to disable
HDMI output.

regards.

Le ven. 6 mai 2022 à 03:14, Neven Sajko  a écrit :

> Do you perhaps have any /etc/asound.conf or .asoundrc or similarly named
> files messing up your sound config?
>
> Additionally (another wild guess), try running aplay -l -L and report the
> output.
>
> On Thu, May 5, 2022, 16:00 Pascal via arch-general <
> arch-general@lists.archlinux.org> wrote:
>
>> I checked in my session the concurrent accesses with fuser -v /dev/snd/*
>> and killed the only one that was present and could interfere (volumeicon
>> *that
>> was also present with Firefox and Mplayer*).
>>
>> Le jeu. 5 mai 2022 à 15:50, Pascal  a écrit :
>>
>> > Alsa directly : no PA or PW.
>> >
>> > when i run Chromium from a terminal, i get these two error messages
>> about
>> > Alsa but they also appear when the sound is working :
>> > [4765:4765:0504/164956.649650:ERROR:alsa_util.cc(204)] PcmOpen:
>> > default,Device or resource busy
>> > [4765:4765:0504/164956.649811:ERROR:alsa_util.cc(204)] PcmOpen:
>> > plug:default,Device or resource busy
>> >
>> > Le jeu. 5 mai 2022 à 15:46, Jesse Jaara via arch-general <
>> > arch-general@lists.archlinux.org> a écrit :
>> >
>> >> Are you using Alsa directly, no pulseaudio or pipewire? Something
>> could be
>> >> wonky with your dmix config and it's getting disabled, thus only a
>> single
>> >> application can have access to the sound playback at once.
>> >>
>> >
>>
>

Re: [arch-general] sound problem with chromium

[Pascal via arch-general]

with or without the option, Chromium is still willing to play sound once in
a while.
what really bothers me is the randomness of the problem.

some additional information :
$ journalctl -b | grep -i _hda_
May 09 08:39:09 archlive kernel: snd_hda_intel: probe of :00:1f.3
failed with error -2
May 09 08:39:12 archlive kernel: sof-audio-pci-intel-cnl :00:1f.3:
using HDA machine driver skl_hda_dsp_generic now
May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
autoconfig for ALC285: line_outs=2 (0x14/0x17/0x0/0x0/0x0) type:speaker
May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
 speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
 hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
 mono: mono_out=0x0
May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
 inputs:
May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
 Mic=0x19
May 09 08:39:13 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC:
sink widget AIF1TX overwritten
May 09 08:39:13 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC:
source widget AIF1RX overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: sink widget hifi3 overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: sink widget hifi2 overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: sink widget hifi1 overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: source widget Codec Output Pin1 overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: sink widget Codec Input Pin1 overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: sink widget Analog Codec Playback overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: sink widget Digital Codec Playback overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: sink widget Alt Analog Codec Playback overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: source widget Analog Codec Capture overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: source widget Digital Codec Capture overwritten
May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
ASoC: source widget Alt Analog Codec Capture overwritten
May 09 08:39:13 archlive kernel: input: sof-hda-dsp Mic as
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input13
May 09 08:39:13 archlive kernel: input: sof-hda-dsp Headphone as
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input14
May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=3 as
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input15
May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=4 as
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input16
May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=5 as
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input17
May 09 14:30:25 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: didn't
find PCM for DAI Digital Codec DAI
May 09 14:30:25 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC:
error at snd_soc_dai_startup on Digital Codec DAI: -22

regards, lacsaP.

Le lun. 9 mai 2022 à 14:32, Neven Sajko  a écrit :

> Try loading snd_hda_intel without extra options. If this helps, you can
> always use the ALSA_CARD environment variable for choosing the audio device.
>

Re: [arch-general] sound problem with chromium

[Pascal via arch-general]

hi,

the problem seems to have disappeared after installation of pulseaudio-alsa
which appears to be essential to the proper functioning of Chromium.

when Chromium had "the hand" on the audio and was able to produce sound, I
could not hear the other participants talking with Jitsi while I could hear
their arrival (sound signal) and the sound test was ok (this was also the
case with Jitsi under Firefox).

to summarize, pulseaudio-alsa seems to have corrected the random sound
problem with Chromium and the second problem that appeared in the meantime
with Jitsi.
if this is the case, it could be added as a Chromium/Firefox dependency
(eg. pacman)...

regards, lacsaP.

Le lun. 9 mai 2022 à 14:56, Pascal  a écrit :

> with or without the option, Chromium is still willing to play sound once
> in a while.
> what really bothers me is the randomness of the problem.
>
> some additional information :
> $ journalctl -b | grep -i _hda_
> May 09 08:39:09 archlive kernel: snd_hda_intel: probe of :00:1f.3
> failed with error -2
> May 09 08:39:12 archlive kernel: sof-audio-pci-intel-cnl :00:1f.3:
> using HDA machine driver skl_hda_dsp_generic now
> May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
> autoconfig for ALC285: line_outs=2 (0x14/0x17/0x0/0x0/0x0) type:speaker
> May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
>  speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
> May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
>  hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
> May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
>  mono: mono_out=0x0
> May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
>  inputs:
> May 09 08:39:12 archlive kernel: snd_hda_codec_realtek ehdaudio0D0:
>  Mic=0x19
> May 09 08:39:13 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC:
> sink widget AIF1TX overwritten
> May 09 08:39:13 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC:
> source widget AIF1RX overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: sink widget hifi3 overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: sink widget hifi2 overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: sink widget hifi1 overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: source widget Codec Output Pin1 overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: sink widget Codec Input Pin1 overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: sink widget Analog Codec Playback overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: sink widget Digital Codec Playback overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: sink widget Alt Analog Codec Playback overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: source widget Analog Codec Capture overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: source widget Digital Codec Capture overwritten
> May 09 08:39:13 archlive kernel: skl_hda_dsp_generic skl_hda_dsp_generic:
> ASoC: source widget Alt Analog Codec Capture overwritten
> May 09 08:39:13 archlive kernel: input: sof-hda-dsp Mic as
> /devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input13
> May 09 08:39:13 archlive kernel: input: sof-hda-dsp Headphone as
> /devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input14
> May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=3 as
> /devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input15
> May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=4 as
> /devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input16
> May 09 08:39:13 archlive kernel: input: sof-hda-dsp HDMI/DP,pcm=5 as
> /devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input17
> May 09 14:30:25 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: didn't
> find PCM for DAI Digital Codec DAI
> May 09 14:30:25 archlive kernel: snd_hda_codec_realtek ehdaudio0D0: ASoC:
> error at snd_soc_dai_startup on Digital Codec DAI: -22
>
> regards, lacsaP.
>
> Le lun. 9 mai 2022 à 14:32, Neven Sajko  a écrit :
>
>> Try loading snd_hda_intel without extra options. If this helps, you can
>> always use the ALSA_CARD environment variable for choosing the audio device.
>>
>