[SOLVED] Re: speaker-test: no correct sound output on LFE and others speakers

[Franco Martelli]

On 30/04/24 at 14:07, Alexandre Rossi wrote:

Hi,


Basically I've the same issue described here:
https://askubuntu.com/questions/1180389/speaker-test-returns-all-6-channels-to-front-speakers

The speaker-test program is provided by the alsa-utils package. I'm using
Debian 12 Bookworm, I've no ~/.asoundrc file. My /proc/asound/cards returns:

~$ cat /proc/asound/cards
  0 [SB ]: HDA-Intel - HDA ATI SB
   HDA ATI SB at 0xfe40 irq 16
  1 [NVidia ]: HDA-Intel - HDA NVidia
   HDA NVidia at 0xfe08 irq 57

I've 5.1 speakers the LOGITECH Z906 audio system plugged to the PC via 3
jacks (left/right), (Center/Subwoofer), (Rear left/ Rear right).


I assume your cabling is right and your SB soundcard has surround out
(3 jacks as you describe it, and not mic and line out for instance). The labels
on the jacks would confirm that, so would the user manual of your motherboard or
sound card.


The issue is that speaker-test doesn't play sound to the correct speaker. If
I run:

~$ speaker-test -Dplug:surround51 -c6 -s3 -f75

The sound comes from (Center), (Front right), (Rear left) and (Rear right)
speakers instead (Front right) only.


What's bothering me is that you get sound from multiple speakers while
instructing out on only one.

The usual issues of these setups with surround analog out are:
- channel mapping issues (driver/hardware mismatch)
- software downmixing to stereo

There are other usual issues with surrount digital out but this is not
your setup.

You can have a look at [1] for software fixes on this.

[1] https://alsa.opensrc.org/SurroundSound


I solved by buying a Toslink (S/PDIF) optical cable, and using thus the 
"Surround 5.1 Digital output" and unplugging the three jacks analog 
cable. Now speaker-test works nicely:


~$ speaker-test -c6 -l1 -twav

speaker-test 1.2.8

Playback device is default
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 32 to 349525
Period size range from 10 to 116509
Using max buffer size 349524
Periods = 4
was set period_size = 87381
was set buffer_size = 349524
 0 - Front Left
 4 - Center
 1 - Front Right
 3 - Rear Right
 2 - Rear Left
 5 - LFE
Time per period = 8,720806

maybe it was a hardware issue with the DAC of my Logitech Z906, it seems 
that with the three jacks analog cable it downmix to stereo, thanks anyway.


Cheers,
--
Franco Martelli

Test

[Alex PADOLY]

Ceci est un email pour vérifier la réception des messages de la liste.

Envoyé avec la messagerie sécurisée [Proton Mail.](https://proton.me/)

Re: speaker-test: no correct sound output on LFE and others speakers

[Franco Martelli]

Hi Alexandre,

On 07/05/24 at 11:56, Alexandre Rossi wrote:


My hypothesis: speaker-test outputs directly to ALSA (kernel) but ALSA redirects
to pulseaudio (the 99-pulse.conf file) and pulseaudio Output profile is stereo.
Therefore, pulseaudio downmixes 5.1 to stereo. That would explain why only
front-left and front-right output sound.

To confirm, you can either:
- move away that 99-pulse.conf file so that speaker-test use directly and only
   ALSA
- configure pulseaudio output profile for surround5.1 (you can use command line
   $ pacmd set-card-profile 0 output:output:analog-surround-51 or
   pavucontrol (graphical)


~# systemctl stop pulseaudio
Failed to stop pulseaudio.service: Unit pulseaudio.service not loaded.


pulseaudio is usually a *user* service and socket activated (starts 
automatically
if some app wants to use it). To stop it, the following should work:
$ systemctl --user stop pulseaudio.socket  # stop the socket to prevent auto 
start
$ systemctl --user stop pulseaudio.service # stop the daemon


I moved the 99-pulse.conf file into root directory, then rebooted but 
"speaker-test" does the same result of my first post.
I think that PulseAudio is already configured for surround, see 
attachment for the output of "pacmd info" command. The two "systemctl" 
commands to stop PulseAudio worked, thank you very much it was a new 
thing for me.


I tried to boot Debian 12.5 in rescue-mode and I tested "speaker-test" 
but ditto, same result of my first post.


When I was in rescue-mode and trying to play sound in the console, this 
message appeared on the screen, I don't know whether it matters:


snd_hda_intel :00:14.2: IRQ timing workaround is activated for card 
#0. Suggest a bigger bdl_pos_adj.


It's driving me utterly bonkers, maybe a hardware issue?

Lastly I've asked for support to the alsa-user mailing-list on 
SourceForge but I got no answer at the moment.


--
Franco Martelli


pacmdInfo.txt.gz
Description: application/gzip

Re: speaker-test: no correct sound output on LFE and others speakers

[Alexandre Rossi]

Hi,

> > My understanding is that pulseaudio uses alsa for kernel interface and
> > that speaker-test uses alsa directly. So if one cannot get speaker-test
> > to sound right, it cannot work with pulseaudio. That why I suggest 
> > workarounds
> > in alsa conf (asoundrc).
> 
> I tried several configurations of ~/.asoundrc in these days but nothing
> works with "speaker-test". Well some configurations let "aplay" to use
> rear-left, rear-right, front-center speakers but "speaker-test" never sends
> sound to front-center, rear-left, rear-right and LFE with this command:
> [...]
> Just now, checking the ALSA configuration in /etc/alsa/conf.d/ I found the
> 99-pulse.conf file:
> 
> ~# cat /etc/alsa/conf.d/99-pulse.conf
> # PulseAudio alsa plugin configuration file to set the pulseaudio plugin as
> # default output for applications using alsa when pulseaudio is running.
> [...]
> 
> Does Debian use Pulseaudio daemon as default output for ALSA applications?
> Could it be a Pulseaudio misconfiguration? Should I try to uninstall it or
> how can I stop Pulseaudio? If I do "killall pulseaudio" it re-spawns
> immediately and "systemctl" doesn't work:

My hypothesis: speaker-test outputs directly to ALSA (kernel) but ALSA redirects
to pulseaudio (the 99-pulse.conf file) and pulseaudio Output profile is stereo.
Therefore, pulseaudio downmixes 5.1 to stereo. That would explain why only
front-left and front-right output sound.

To confirm, you can either:
- move away that 99-pulse.conf file so that speaker-test use directly and only
  ALSA
- configure pulseaudio output profile for surround5.1 (you can use command line
  $ pacmd set-card-profile 0 output:output:analog-surround-51 or
  pavucontrol (graphical)

> ~# systemctl stop pulseaudio
> Failed to stop pulseaudio.service: Unit pulseaudio.service not loaded.

pulseaudio is usually a *user* service and socket activated (starts 
automatically
if some app wants to use it). To stop it, the following should work:
$ systemctl --user stop pulseaudio.socket  # stop the socket to prevent auto 
start
$ systemctl --user stop pulseaudio.service # stop the daemon

Cheers,

Alex

Re: speaker-test: no correct sound output on LFE and others speakers

[Franco Martelli]

On 02/05/24 at 09:10, Alexandre Rossi wrote:

What's bothering me is that you get sound from multiple speakers while
instructing out on only one.

The usual issues of these setups with surround analog out are:
- channel mapping issues (driver/hardware mismatch)
- software downmixing to stereo

There are other usual issues with surrount digital out but this is not
your setup.

You can have a look at [1] for software fixes on this.

[1]https://alsa.opensrc.org/SurroundSound

The link you posted it shows rather outdated fixes, it talked about Jackd
daemon and surround, but I have pulseaudio daemon, maybe I've pulseaudio
daemon misconfiguration

My understanding is that pulseaudio uses alsa for kernel interface and
that speaker-test uses alsa directly. So if one cannot get speaker-test
to sound right, it cannot work with pulseaudio. That why I suggest workarounds
in alsa conf (asoundrc).


I tried several configurations of ~/.asoundrc in these days but nothing 
works with "speaker-test". Well some configurations let "aplay" to use 
rear-left, rear-right, front-center speakers but "speaker-test" never 
sends sound to front-center, rear-left, rear-right and LFE with this 
command:


~$ LC_ALL=C speaker-test -c 6 -D surround51 -t wav

speaker-test 1.2.8

Playback device is surround51
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 349504
Period size range from 32 to 174752
Using max buffer size 349504
Periods = 4
was set period_size = 174752
was set buffer_size = 349504
 0 - Front Left
 4 - Front Center
 1 - Front Right
 3 - Rear Right
 2 - Rear Left
 5 - LFE
Time per period = 21.908826
 0 - Front Left
^C 4 - Front Center
Transfer failed: Bad address

In place of "surround51" I've set the pcm.X  specified in 
~/.asoundrc trying so several configurations.
Just now, checking the ALSA configuration in /etc/alsa/conf.d/ I found 
the 99-pulse.conf file:


~# cat /etc/alsa/conf.d/99-pulse.conf
# PulseAudio alsa plugin configuration file to set the pulseaudio plugin as
# default output for applications using alsa when pulseaudio is running.
hook_func.pulse_load_if_running {
lib "libasound_module_conf_pulse.so"
func "conf_pulse_hook_load_if_running"
}

@hooks [
{
func pulse_load_if_running
files [
"/usr/share/alsa/pulse-alsa.conf"
]
errors false
}
]

Does Debian use Pulseaudio daemon as default output for ALSA 
applications? Could it be a Pulseaudio misconfiguration? Should I try to 
uninstall it or how can I stop Pulseaudio? If I do "killall pulseaudio" 
it re-spawns immediately and "systemctl" doesn't work:


~# systemctl stop pulseaudio
Failed to stop pulseaudio.service: Unit pulseaudio.service not loaded.

Any help it's very appreciated, thanks in advance.
--
Franco Martelli

Re: speaker-test: no correct sound output on LFE and others speakers

[Alexandre Rossi]

Hi,

> > > The issue is that speaker-test doesn't play sound to the correct speaker. 
> > > If
> > > I run:
> > > 
> > > ~$ speaker-test -Dplug:surround51 -c6 -s3 -f75
> > > 
> > > The sound comes from (Center), (Front right), (Rear left) and (Rear right)
> > > speakers instead (Front right) only.
> > 
> > What's bothering me is that you get sound from multiple speakers while
> > instructing out on only one.
> > 
> > The usual issues of these setups with surround analog out are:
> > - channel mapping issues (driver/hardware mismatch)
> > - software downmixing to stereo
> > 
> > There are other usual issues with surrount digital out but this is not
> > your setup.
> > 
> > You can have a look at [1] for software fixes on this.
> > 
> > [1] https://alsa.opensrc.org/SurroundSound
> 
> The link you posted it shows rather outdated fixes, it talked about Jackd
> daemon and surround, but I have pulseaudio daemon, maybe I've pulseaudio
> daemon misconfiguration

My understanding is that pulseaudio uses alsa for kernel interface and
that speaker-test uses alsa directly. So if one cannot get speaker-test
to sound right, it cannot work with pulseaudio. That why I suggest workarounds
in alsa conf (asoundrc).

Alex

Re: speaker-test: no correct sound output on LFE and others speakers

[Franco Martelli]

Hi Alexandre,

On 30/04/24 at 14:07, Alexandre Rossi wrote:

Hi,


Basically I've the same issue described here:
https://askubuntu.com/questions/1180389/speaker-test-returns-all-6-channels-to-front-speakers

The speaker-test program is provided by the alsa-utils package. I'm using
Debian 12 Bookworm, I've no ~/.asoundrc file. My /proc/asound/cards returns:

~$ cat /proc/asound/cards
  0 [SB ]: HDA-Intel - HDA ATI SB
   HDA ATI SB at 0xfe40 irq 16
  1 [NVidia ]: HDA-Intel - HDA NVidia
   HDA NVidia at 0xfe08 irq 57

I've 5.1 speakers the LOGITECH Z906 audio system plugged to the PC via 3
jacks (left/right), (Center/Subwoofer), (Rear left/ Rear right).


I assume your cabling is right and your SB soundcard has surround out
(3 jacks as you describe it, and not mic and line out for instance). The labels
on the jacks would confirm that, so would the user manual of your motherboard or
sound card.


The MoBo is an old ASUSTeK Computer Inc. M5A99X EVO (R1.0) and it has 
three jacks of different colors to connect to the Logitech Z906 case, 
there aren't labels, only colored jacks: Orange, Black and Lime there is 
also a Gray jack for "Side speakers" so the hardware support up to 
Surround 7.1 in addition it also have an optical S/PDIF out port unused.

The audio device is:

~# lspci -nnv -s 00:14.2
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
SBx00 Azalia (Intel HDA) [1002:4383] (rev 40)
Subsystem: ASUSTeK Computer Inc. SBx00 Azalia (Intel HDA) 
[1043:84fb]
Flags: bus master, slow devsel, latency 32, IRQ 16, NUMA node 
0, IOMMU group 10

Memory at fe40 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel





The issue is that speaker-test doesn't play sound to the correct speaker. If
I run:

~$ speaker-test -Dplug:surround51 -c6 -s3 -f75

The sound comes from (Center), (Front right), (Rear left) and (Rear right)
speakers instead (Front right) only.


What's bothering me is that you get sound from multiple speakers while
instructing out on only one.

The usual issues of these setups with surround analog out are:
- channel mapping issues (driver/hardware mismatch)
- software downmixing to stereo

There are other usual issues with surrount digital out but this is not
your setup.

You can have a look at [1] for software fixes on this.

[1] https://alsa.opensrc.org/SurroundSound


The link you posted it shows rather outdated fixes, it talked about 
Jackd daemon and surround, but I have pulseaudio daemon, maybe I've 
pulseaudio daemon misconfiguration, I tried what suggested here:


https://askubuntu.com/a/1304054

but unluckily  it doesn't work, this is what's enabled in 
/etc/pulse/daemon.conf:


~$ grep -v "^#\|^;\|^[[:space:]]*$" /etc/pulse/daemon.conf
remixing-produce-lfe = yes
remixing-consume-lfe = yes
lfe-crossover-freq = 80

and this is what's in the log after a reboot:

~# journalctl -b | grep pulseaudio
mag 01 14:57:28 itek systemd[1254]: Listening on pulseaudio.socket - 
Sound System.
mag 01 14:57:28 itek systemd[1254]: Starting pulseaudio.service - Sound 
Service...
mag 01 14:57:32 itek systemd[1254]: Started pulseaudio.service - Sound 
Service.
mag 01 14:57:48 itek pulseaudio[1273]: Hole in stream, cannot fast 
forward LFE filter
mag 01 14:57:48 itek pulseaudio[1273]: Hole in stream, cannot fast 
forward LFE filter
mag 01 14:57:54 itek plasmashell[1390]: org.kde.plasma.pulseaudio: No 
object for name "alsa_output.pci-_00_14.2.analog-surround-51.monitor"


any clue? Thank you very much

--
Franco Martelli

Re: speaker-test: no correct sound output on LFE and others speakers

[Alexandre Rossi]

Hi,

> Basically I've the same issue described here:
> https://askubuntu.com/questions/1180389/speaker-test-returns-all-6-channels-to-front-speakers
> 
> The speaker-test program is provided by the alsa-utils package. I'm using
> Debian 12 Bookworm, I've no ~/.asoundrc file. My /proc/asound/cards returns:
> 
> ~$ cat /proc/asound/cards
>  0 [SB ]: HDA-Intel - HDA ATI SB
>   HDA ATI SB at 0xfe40 irq 16
>  1 [NVidia ]: HDA-Intel - HDA NVidia
>   HDA NVidia at 0xfe08 irq 57
> 
> I've 5.1 speakers the LOGITECH Z906 audio system plugged to the PC via 3
> jacks (left/right), (Center/Subwoofer), (Rear left/ Rear right).

I assume your cabling is right and your SB soundcard has surround out
(3 jacks as you describe it, and not mic and line out for instance). The labels
on the jacks would confirm that, so would the user manual of your motherboard or
sound card.

> The issue is that speaker-test doesn't play sound to the correct speaker. If
> I run:
> 
> ~$ speaker-test -Dplug:surround51 -c6 -s3 -f75
> 
> The sound comes from (Center), (Front right), (Rear left) and (Rear right)
> speakers instead (Front right) only.

What's bothering me is that you get sound from multiple speakers while
instructing out on only one.

The usual issues of these setups with surround analog out are:
- channel mapping issues (driver/hardware mismatch)
- software downmixing to stereo

There are other usual issues with surrount digital out but this is not
your setup.

You can have a look at [1] for software fixes on this.

[1] https://alsa.opensrc.org/SurroundSound

Thanks,

Alex

speaker-test: no correct sound output on LFE and others speakers

[Franco Martelli]

Hi everyone,

Basically I've the same issue described here:
https://askubuntu.com/questions/1180389/speaker-test-returns-all-6-channels-to-front-speakers

The speaker-test program is provided by the alsa-utils package. I'm 
using Debian 12 Bookworm, I've no ~/.asoundrc file. My 
/proc/asound/cards returns:


~$ cat /proc/asound/cards
 0 [SB ]: HDA-Intel - HDA ATI SB
  HDA ATI SB at 0xfe40 irq 16
 1 [NVidia ]: HDA-Intel - HDA NVidia
  HDA NVidia at 0xfe08 irq 57

I've 5.1 speakers the LOGITECH Z906 audio system plugged to the PC via 3 
jacks (left/right), (Center/Subwoofer), (Rear left/ Rear right).


Clementine ¹  audio player seems it works well, but I'm unsure that the 
sound go to the correct speaker.


The issue is that speaker-test doesn't play sound to the correct 
speaker. If I run:


~$ speaker-test -Dplug:surround51 -c6 -s3 -f75

speaker-test 1.2.8

Playback device is plug:surround51
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 349504
Period size range from 32 to 174752
Using max buffer size 349504
Periods = 4
was set period_size = 174752
was set buffer_size = 349504
  - Front Right

The sound comes from (Center), (Front right), (Rear left) and (Rear 
right) speakers instead (Front right) only. If I run:


~$ speaker-test -Dplug:surround51 -c6 -s6 -f75

speaker-test 1.2.8

Playback device is plug:surround51
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 349504
Period size range from 32 to 174752
Using max buffer size 349504
Periods = 4
was set period_size = 174752
was set buffer_size = 349504
  - LFE

I've no sound from the Subwoofer. Does anybody know how can I test the 
speakers of my 3D Dolby surround system? Please help.



¹ https://packages.debian.org/bookworm/clementine
--
Franco Martelli

test

[Frank McCormick]

test

Test

[D]

Hi debian users

test of a gnuplot bug visible with Pango 1.52 (Debian/unstable)

[Vincent Lefevre]

Hi,

Since the upgrade of the Pango library to 1.52 in Debian/unstable, I'm
seeing an annoying bug in gnuplot with the wxt terminal. The issue can
be reproduced with the following command:

  echo 'set terminal wxt; plot x' | gnuplot -persist

A window appears, but it is not drawn and it cannot be deleted by
gnuplot. One can destroy it, but the gnuplot process is still running
(in background).

I can observe this bug with the FVWM window manager, with both
manual placement and immediate placement (manual placement can
make the problem worse). I don't think that this is a bug in
Pango: the commit that introduces the change of behavior does
some optimization in threading, which probably makes Pango a bit
faster, which triggers a race condition (note that conversely,
if I use ssh, even "ssh localhost", this makes the problem
disappear).

Details in my bug reports:
  https://sourceforge.net/p/gnuplot/bugs/2693/
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064982

Can anyone else reproduce this issue, in particular with other
window managers?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Can't view videos in firefox: VA-API test failed

[Max Nikulin]

On 26/01/2024 07:09, Stefan Monnier wrote:

 systemctl --user status pipewire{,-pulse} wireplumber

which shows that `wireplumber` failed to start.


I was assuming that

systemctl --user --failed
journalctl --user --boot

and as root

systemctl --failed
journalctl --boot

were first that you tried facing an issue. After replacing pulseaudio by 
pipewire, I faced some issue with systemd unit, but I have not figured 
out what have happened. Despite what Debian wiki states, no additional 
configuration was required. That is why I can not tell if recipes from 
Arch wiki are helpful.

Re: Can't view videos in firefox: VA-API test failed

[Stefan Monnier]

> The problem might be in between of
>
> lspci -vnn

Spews out a lot of stuff, the relevant part being presumably:

00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD 
Audio Controller [8086:284b] (rev 03)
Subsystem: Lenovo ThinkPad T61/R61 [17aa:20ac]
Flags: bus master, fast devsel, latency 0, IRQ 30
Memory at fe02 (64-bit, non-prefetchable) [size=16K]
Capabilities: 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

> and
>
> pactl list
> pactl list sinks

Here the sinks say just:

% pactl list cards
% pactl list sinks
Sink #33
State: SUSPENDED
Name: auto_null
Description: Dummy Output
Driver: PipeWire
Sample Specification: float32le 2ch 48000Hz
Channel Map: front-left,front-right
Owner Module: 4294967295
Mute: no
Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 
100% / 0.00 dB
balance 0.00
Base Volume: 65536 / 100% / 0.00 dB
Monitor Source: auto_null.monitor
Latency: 0 usec, configured 0 usec
Flags: DECIBEL_VOLUME LATENCY 
Properties:
node.name = "auto_null"
device.description = "Dummy Output"
audio.rate = "48000"
audio.channels = "2"
audio.position = "FL,FR"
media.class = "Audio/Sink"
factory.name = "support.null-audio-sink"
node.virtual = "true"
monitor.channel-volumes = "true"
factory.id = "17"
clock.quantum-limit = "8192"
client.id = "30"
node.driver = "true"
factory.mode = "merge"
audio.adapt.follower = ""
library.name = "audioconvert/libspa-audioconvert"
object.id = "31"
object.serial = "33"
Formats:
pcm
%

> Perhaps troubleshooting sections in wikis may tell more. There is a chance
> that lsof may find another process holding audio devices.

Hmm... this time a web search lead me to

systemctl --user status pipewire{,-pulse} wireplumber

which shows that `wireplumber` failed to start.
Thanks.  Haven't found the actual problem nor a fix, but I have
some leads.
Stay tuned, I'll be back with the results :-)


Stefan

Re: Can't view videos in firefox: VA-API test failed

[Max Nikulin]

On 24/01/2024 04:28, Stefan Monnier wrote:

But since `pactl` seems to still be useful for Pipewire, I tried
`pavucontrol` and it shows me no device from which to select in the
"Output Devices".

Now, how do I figure out why that is?


The problem might be in between of

lspci -vnn

and

pactl list
pactl list sinks

Perhaps troubleshooting sections in wikis may tell more. There is a 
chance that lsof may find another process holding audio devices.

Re: Can't view videos in firefox: VA-API test failed

[Stefan Monnier]

> But since `pactl` seems to still be useful for Pipewire, I tried
> `pavucontrol` and it shows me no device from which to select in the
> "Output Devices".

Hmm... actually, not quite: there is one output device, called "Dummy
Output".   And there is similarly just one input device listed, called
"Monitor of Dummy Input".  


Stefan

Re: Can't view videos in firefox: VA-API test failed

[Stefan Monnier]

>> Server Version: 15.0.0
>> Default Sample Specification: float32le 2ch 48000Hz
>> Default Channel Map: front-left,front-right
>> Default Sink: @DEFAULT_SINK@
>> Default Source: @DEFAULT_SOURCE@
>> Cookie: 40db:2cde
>> %
>> 
>> Not sure what the `Cookie` does and even less whether those @DEFAULT_SINK@
>> thingies are normal, tho a quick `grep` indicates at least `zsh`
>> completion for `wpctl` finds them normal:
>> 
>> /usr/share/zsh/site-functions/_wpctl:
>> 'pw-defaults:defaults:(@DEFAULT_SINK@ @DEFAULT_SOURCE@)' \
>
> I would set them explicitly and see if things get better.

I don't really know how to set them.
But since `pactl` seems to still be useful for Pipewire, I tried
`pavucontrol` and it shows me no device from which to select in the
"Output Devices".

Now, how do I figure out why that is?


Stefan

Re: Can't view videos in firefox: VA-API test failed

[Dan Ritter]

Stefan Monnier wrote: 
> Server Version: 15.0.0
> Default Sample Specification: float32le 2ch 48000Hz
> Default Channel Map: front-left,front-right
> Default Sink: @DEFAULT_SINK@
> Default Source: @DEFAULT_SOURCE@
> Cookie: 40db:2cde
> %
> 
> Not sure what the `Cookie` does and even less whether those @DEFAULT_SINK@
> thingies are normal, tho a quick `grep` indicates at least `zsh`
> completion for `wpctl` finds them normal:
> 
> /usr/share/zsh/site-functions/_wpctl:
> 'pw-defaults:defaults:(@DEFAULT_SINK@ @DEFAULT_SOURCE@)' \

I would set them explicitly and see if things get better.

-dsr-

Re: Can't view videos in firefox: VA-API test failed

[Stefan Monnier]

> OK. First diagnostic: `pactl info`.
>
> On my bookworm desktop, I get this:
>
> $ pactl info
> Server String: /run/user/1042/pulse/native
> Library Protocol Version: 35
> Server Protocol Version: 35
> Is Local: yes
> Client Index: 13692
> Tile Size: 65472
> User Name: dsr
> Host Name: spike
> Server Name: PulseAudio (on PipeWire 0.3.65)
> Server Version: 15.0.0
> Default Sample Specification: float32le 2ch 48000Hz
> Default Channel Map: front-left,front-right
> Default Sink: PulseEffects_apps
> Default Source: 
> alsa_input.usb-Blue_Microphones_Yeti_Stereo_Microphone_REV8-00.analog-stereo

% pactl info
Server String: /run/user/20848/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 138
Tile Size: 65496
User Name: monnier
Host Name: alfajor
Server Name: PulseAudio (on PipeWire 1.0.1)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: @DEFAULT_SINK@
Default Source: @DEFAULT_SOURCE@
Cookie: 40db:2cde
%

Not sure what the `Cookie` does and even less whether those @DEFAULT_SINK@
thingies are normal, tho a quick `grep` indicates at least `zsh`
completion for `wpctl` finds them normal:

/usr/share/zsh/site-functions/_wpctl:
'pw-defaults:defaults:(@DEFAULT_SINK@ @DEFAULT_SOURCE@)' \


Stefan

Re: Can't view videos in firefox: VA-API test failed

[Dan Ritter]

Stefan Monnier wrote: 
> > Does mplayer give any more interesting errors? 
> 
> Oh, I didn't notice it at first, but now that you ask, yes it does:
> after something like a timeout period it says:
> 
> AO: [pulse] Init failed: Timeout
> Failed to initialize audio driver 'pulse'
> 
> And lo and behold if I start it with `mplayer -ao none `, the
> video plays just fine (whether Theora, MPEG2, or H.264).
> 
> So maybe I was barking up the wrong tree and the problem was on the
> audio side all this time.

Well, yes and no. I think we've established that there's no
hardware support for decoding anything except MPEG2, but also
that the machine is capable of doing most decoding in software.

Sound problems are... excessive amounts of fun. 

> This machine is running Debian testing,
> which seems to have selected Pipewire for me.
> 
> % ps auxw|grep pipewire
> monnier   1810  0.0  0.1  46096  9396 ?Ssl  jan18   0:00 
> /usr/bin/pipewire
> monnier   1813  0.0  0.0  34436  6412 ?Ssl  jan18   0:00 
> /usr/bin/pipewire -c filter-chain.conf
> monnier   1818  0.0  0.1  41540 10460 ?Ssl  jan18   0:00 
> /usr/bin/pipewire-pulse
> monnier   7472  0.0  0.0   8276  2304 pts/6SN+  16:40   0:00 grep 
> pipewire

OK. First diagnostic: `pactl info`.

On my bookworm desktop, I get this:

$ pactl info
Server String: /run/user/1042/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 13692
Tile Size: 65472
User Name: dsr
Host Name: spike
Server Name: PulseAudio (on PipeWire 0.3.65)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: PulseEffects_apps
Default Source: 
alsa_input.usb-Blue_Microphones_Yeti_Stereo_Microphone_REV8-00.analog-stereo

Which says the things I expect: pulseaudio's interface is being
supplied by pipewire, it's configured for 2 channel stereo,
there's a USB microphone available and the output is being
filtered through PulseEffects (which is doing equalization for
me.)




-dsr-

Re: Can't view videos in firefox: VA-API test failed

[Max Nikulin]

On 22/01/2024 04:26, Charles Curley wrote:

You and I seem to be having similar problems.


No, you don't. Charles, your graphics adapter is supported by i965, but 
not iHD and vainfo reports a number of profiles

https://lists.debian.org/msgid-search/20240113101948.0a880f26@hawk.localdomain
Chromium oops: libva error:
 /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so Sat, 13 Jan 2024 
10:19:48 -0700


A message related to iHD is a routine attempt to load the driver.

In the case of Stefan neither iHD nor i965 support that graphics 
adapter. Perhaps mesa really has dropped it.

Re: Can't view videos in firefox: VA-API test failed

[Stefan Monnier]

> Does mplayer give any more interesting errors? 

Oh, I didn't notice it at first, but now that you ask, yes it does:
after something like a timeout period it says:

AO: [pulse] Init failed: Timeout
Failed to initialize audio driver 'pulse'

And lo and behold if I start it with `mplayer -ao none `, the
video plays just fine (whether Theora, MPEG2, or H.264).

So maybe I was barking up the wrong tree and the problem was on the
audio side all this time.  This machine is running Debian testing,
which seems to have selected Pipewire for me.

% ps auxw|grep pipewire
monnier   1810  0.0  0.1  46096  9396 ?Ssl  jan18   0:00 
/usr/bin/pipewire
monnier   1813  0.0  0.0  34436  6412 ?Ssl  jan18   0:00 
/usr/bin/pipewire -c filter-chain.conf
monnier   1818  0.0  0.1  41540 10460 ?Ssl  jan18   0:00 
/usr/bin/pipewire-pulse
monnier   7472  0.0  0.0   8276  2304 pts/6SN+  16:40   0:00 grep 
pipewire
%

IIUC `pipewire-pulse` is the daemon which should let PulseAudio client
connect to Pipewire, so I don't know why mplayer's `pulse` backend is
not happy.  I know very little about Pipewire (or GNU/Linux audio in
general for that matter), so I'd welcome help diagnosing this part as well.

I tried to use `mplayer -ao alsa ` but it ends up just sitting there,
without any output nor error after the first few information lines
(which are always the same):

% mplayer -ao alsa icfp23-explicit-refinement-types.mkv
MPlayer 1.5+svn38446-1 (Debian)do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote 
control.

Playing icfp23-explicit-refinement-types.mkv.
libavformat version 60.16.100 (external)
libavformat file format detected.
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (opus), -aid 0, -alang eng
VIDEO:  [H264]  1280x720  0bpp  30.000 fps0.0 kbps ( 0.0 kbyte/s)
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva error: /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva error: /usr/lib/i386-linux-gnu/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 60.31.102 (external)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==
Clip info:
 COMPATIBLE_BRANDS: iso6avc1mp41
 MAJOR_BRAND: dash
 MINOR_VERSION: 0
 ENCODER: Lavf60.16.100
Load subtitles in ./
==
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
[opus @ 0xf6d9bb80]Could not update timestamps for skipped samples.
AUDIO: 48000 Hz, 2 ch, floatle, 0.0 kbit/0.00% (ratio: 0->384000)
Selected audio codec: [ffopus] afm: ffmpeg (FFmpeg opus)
==

My best guess is that it's waiting for Pipewire to release the audio device?
With `ao oss`, it goes a bit further (i.e. it opens up the actual
window where the window should be played) but still ends up sitting
there waiting for something and not playing anything.


Stefan

Re: Can't view videos in firefox: VA-API test failed

[Charles Curley]

On Sat, 20 Jan 2024 18:51:17 -0500
Stefan Monnier  wrote:

> So, IIUC the problem is that the hardware video decoder drivers aren't
> found for some reason.  I checked my VA-related packages and they seem
> to be installed:
> 
> # aptitude search '\' | grep '^i'
> i A i965-va-driver - VAAPI driver for Intel G45 & HD Graphics
> family i  intel-media-va-driver - VAAPI driver for the Intel GEN8+
> Graphics family i A libvdpau-va-gl1 - VDPAU driver with OpenGL/VAAPI
> backend i A mesa-va-drivers - Mesa VA-API video acceleration drivers
> i  va-driver-all - API de Video Acceleration (VA) – métapaquet de
> pilotes i A vdpau-va-driver - VDPAU-based backend for VA API
> #
> 
> I tried to install `intel-media-va-driver-non-free` to see if that's
> the problem, but it did not make any difference.

You and I seem to be having similar problems. I suspect that it has to
do with drivers initializing properly, not our respective browsers. I
can run Firefox just fine, but not chromium.


root@jhegaala:~# pre '\'
i965-va-driver  2.4.1+dfsg1-1   amd64
intel-media-va-driver   23.1.1+dfsg1-1  amd64
libvdpau-va-gl1 0.4.2-1+b1  amd64
mesa-va-drivers 22.3.6-1+deb12u1amd64
va-driver-all   2.17.0-1amd64
root@jhegaala:~#

I seem to be missing vdpau-va-driver, but it does not seem to be
available for me (bookworm):

root@jhegaala:~# apt install vdpau-va-driver
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package vdpau-va-driver is not available, but is referred to by another
package. This may mean that the package is missing, has been obsoleted,
or is only available from another source
However the following packages replace it:
  mesa-va-drivers

E: Package 'vdpau-va-driver' has no installation candidate
root@jhegaala:~# 

I've documented what I have so far in a thread with the subject
"Chromium oops: libva error:
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so"

root@jhegaala:~# lspci -vs 2.0
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller]) Subsystem: Lenovo ThinkPad T520 Flags: bus master,
fast devsel, latency 0, IRQ 28, IOMMU group 0 Memory at f000
(64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit,
prefetchable) [size=256M] I/O ports at 6000 [size=64]
Expansion ROM at 000c [virtual] [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915

root@jhegaala:~# 


VLC also plays MP4 movies just fine. It reports:

charles@jhegaala:~/ogg$ VLC media player 3.0.20 Vetinari (revision 
3.0.20-0-g6f0d0ab126b)
[55febf968d30] [http] lua interface: Lua HTTP interface
[55febf882550] main libvlc: Running vlc with the default interface. Use 
'cvlc' to use vlc without interface.
[7f76bc0042f0] gl gl: Initialized libplacebo v4.208.0 (API v208)
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
[7f76bc0042f0] gl gl: Initialized libplacebo v4.208.0 (API v208)
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
[7f76d4c18c50] avcodec decoder: Using OpenGL/VAAPI backend for VDPAU for 
hardware decoding


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Can't view videos in firefox: VA-API test failed

[Sven Joachim]

On 2024-01-20 18:51 -0500, Stefan Monnier wrote:

> Whenever I try to view videos in Firefox in my trusty Thinkpad T61,
> Firefox just eats up the CPU but doesn't actually show the video.
>
> At startup I get the following message:
>
> [GFX1-]: vaapitest: VA-API test failed: failed to initialise VAAPI 
> connection.
>
> So, IIUC the problem is that the hardware video decoder drivers aren't
> found for some reason.  I checked my VA-related packages and they seem
> to be installed:
>
> # aptitude search '\' | grep '^i'
> i A i965-va-driver - VAAPI driver for Intel G45 & HD Graphics family
> i  intel-media-va-driver - VAAPI driver for the Intel GEN8+ Graphics 
> family
> i A libvdpau-va-gl1 - VDPAU driver with OpenGL/VAAPI backend
> i A mesa-va-drivers - Mesa VA-API video acceleration drivers
> i  va-driver-all - API de Video Acceleration (VA) – métapaquet de pilotes
> i A vdpau-va-driver - VDPAU-based backend for VA API
> #
>
> I tried to install `intel-media-va-driver-non-free` to see if that's the
> problem, but it did not make any difference.
>
> I understand that my machine is fairly old, but it used to be able to
> play youtube videos just fine without eating all my CPU time (i.e. using
> hardware video decoding from its GM965/GL960 Intel integrated graphcs).
>
> Any idea what might be going on?

It is probably due to the removal of old drivers, including i915 and
i965, in Mesa 22.0.  There is a separate branch for the old drivers
called "Mesa Amber" but unfortunately no packages have appeared in
Debian yet[1,2,3], and honestly I do not think they ever will. :-(

> Any hint how I could diagnose the problem?

Look for "swrast" in ~/.local/share/xorg/Xorg.0.log.  If it is mentioned
there, you are likely using software rendering.

Cheers,
   Sven


1. https://bugs.debian.org/1006202
2. https://lists.debian.org/debian-x/2022/06/msg00041.html
3. https://lists.debian.org/debian-x/2023/08/msg00138.html

Re: Can't view videos in firefox: VA-API test failed

[Dan Ritter]

Stefan Monnier wrote: 
> > This should be the Intel 4500 integrated gpu, which is part of
> > the i915/i965 family. It needs:
> >
> > - an intel kernel module
> 
> According to `lsmod | grep '^i'` I have `i915` loaded.  Is that the one?

Yes.

> > - X11 running the intel video driver
> 
> Interesting.  I was using the `modesetting` driver.
> So I installed `xserver-xorg-video-intel` and then put
> 
> % cat /etc/X11/xorg.conf
> Section "Device"
> Identifier  "Intel Corporation 965GM"
> Driver  "intel"
> EndSection
> % 
> 
> to force Xorg to use that `intel` driver (since apparently by default
> nowadays it tries only `vesa`, `fbdev`, and `modestting`).

Yup.

> > It will support MPEG2 accelerated decoding but not H264, H265 or
> > any of the newer codecs -- and Youtube may not be supplying old
> > codecs these days.
> 
> That might be part of the problem, indeed.
> Tho the `vainfo` failure suggests that even MPEG2 isn't working.
> 
> I tried to view an MPEG2 video with totem/xine/mplayer and that didn't
> work either (it doesn't eat up all the CPU, instead they just "sit
> there", sometimes emitting the same kind of VA errors as shown earlier).


Does mplayer give any more interesting errors? 

-dsr-

Re: Can't view videos in firefox: VA-API test failed

[Stefan Monnier]

> This should be the Intel 4500 integrated gpu, which is part of
> the i915/i965 family. It needs:
>
> - an intel kernel module

According to `lsmod | grep '^i'` I have `i915` loaded.  Is that the one?

> - X11 running the intel video driver

Interesting.  I was using the `modesetting` driver.
So I installed `xserver-xorg-video-intel` and then put

% cat /etc/X11/xorg.conf
Section "Device"
Identifier  "Intel Corporation 965GM"
Driver  "intel"
EndSection
% 

to force Xorg to use that `intel` driver (since apparently by default
nowadays it tries only `vesa`, `fbdev`, and `modestting`).

The end result appears to be the same, tho :-(
At least, all the error messages I get are the same.

> - libva-drm2
> - libva-x11-2
> - libva2
> - i965-va-driver

Check!

> It will support MPEG2 accelerated decoding but not H264, H265 or
> any of the newer codecs -- and Youtube may not be supplying old
> codecs these days.

That might be part of the problem, indeed.
Tho the `vainfo` failure suggests that even MPEG2 isn't working.

I tried to view an MPEG2 video with totem/xine/mplayer and that didn't
work either (it doesn't eat up all the CPU, instead they just "sit
there", sometimes emitting the same kind of VA errors as shown earlier).


Stefan

Re: Can't view videos in firefox: VA-API test failed

[Dan Ritter]

Stefan Monnier wrote: 
> Whenever I try to view videos in Firefox in my trusty Thinkpad T61,
> Firefox just eats up the CPU but doesn't actually show the video.
> 
> At startup I get the following message:
> 
> [GFX1-]: vaapitest: VA-API test failed: failed to initialise VAAPI 
> connection.
...
 
> I understand that my machine is fairly old, but it used to be able to
> play youtube videos just fine without eating all my CPU time (i.e. using
> hardware video decoding from its GM965/GL960 Intel integrated graphcs).
> 
> Any idea what might be going on?  Any hint how I could diagnose the problem?


This should be the Intel 4500 integrated gpu, which is part of
the i915/i965 family. It needs:

- an intel kernel module
- X11 running the intel video driver
- libva-drm2
- libva-x11-2
- libva2
- i965-va-driver

It will support MPEG2 accelerated decoding but not H264, H265 or
any of the newer codecs -- and Youtube may not be supplying old
codecs these days.

-dsr-

Re: Can't view videos in firefox: VA-API test failed

[Stefan Monnier]

Max Nikulin [2024-01-21 10:51:36] wrote:
> On 21/01/2024 06:51, Stefan Monnier wrote:
>>  [GFX1-]: vaapitest: VA-API test failed: failed to initialise VAAPI 
>> connection.
> [...]
>> Any idea what might be going on?  Any hint how I could diagnose the problem?
> I would start from comparison of "vainfo" output and related sections in
> about:support.

Thanks, I didn't know about either of those :-)
Sadly, `vainfo` doesn't tell me much more info than that it fails:

% vainfo 
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva error: /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva error: /usr/lib/i386-linux-gnu/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
%

But at least, it seems to indicate that my problems don't have to do
with Firefox.

> Internally Firefox likely uses a test like
>
> /usr/lib/firefox-esr/vaapitest -d /dev/dri/renderD128
>
> https://searchfox.org/mozilla-central/source/widget/gtk/GfxInfo.cpp#line-649

Indeed that gives me the same error message:

% /usr/lib/firefox-esr/vaapitest -d /dev/dri/renderD128
ERROR
VA-API test failed: failed to initialise VAAPI connection.
%

I can't see any "verbose" option for those so I tried `strace`:

% strace vainfo
[...]
write(2, "libva info: Found init function __vaDriverInit_1_20", 52) = 52
openat(AT_FDCWD, "/etc/igfx_user_feature_next.txt", O_RDONLY|O_LARGEFILE) = 
-1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/etc/igfx_user_feature.txt", O_RDONLY|O_LARGEFILE) = -1 
ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/dev/shm/GFX_MEDIA_TRACE", O_RDONLY|O_LARGEFILE) = -1 
ENOENT (Aucun fichier ou dossier de ce type)
getpid()= 14840
ioctl(4, DRM_IOCTL_VERSION, 0xffdde780) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde780) = 0
ioctl(4, DRM_IOCTL_VERSION, 0xffdde820) = 0
ioctl(4, DRM_IOCTL_I915_GEM_GET_APERTURE, 0xffdde7e8) = 0
geteuid32() = 20848
getuid32()  = 20848
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde820) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7e0) = 0
ioctl(4, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, 0xffdde808) = 0
ioctl(4, DRM_IOCTL_I915_QUERY, 0xffdde7f8) = 0
ioctl(4, DRM_IOCTL_I915_QUERY, 0xffdde7f8) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7a4) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7a4) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7a4) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7a4) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7a4) = -1 ENODEV (Aucun périphérique de ce type)
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7a4) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7a4) = 0
ioctl(4, DRM_IOCTL_I915_GETPARAM or DRM_IOCTL_TEGRA_CLOSE_CHANNEL, 
0xffdde7a4) = -1 ENODEV (Aucun périphérique de ce type)
ioctl(4, DRM_IOCT

Re: Can't view videos in firefox: VA-API test failed

[Max Nikulin]

On 21/01/2024 06:51, Stefan Monnier wrote:

 [GFX1-]: vaapitest: VA-API test failed: failed to initialise VAAPI 
connection.

[...]

Any idea what might be going on?  Any hint how I could diagnose the problem?


I would start from comparison of "vainfo" output and related sections in 
about:support.


ArchLinux and Debian wiki may give some troubleshooting hints
https://wiki.debian.org/Firefox#Hardware_Video_Acceleration

Internally Firefox likely uses a test like

/usr/lib/firefox-esr/vaapitest -d /dev/dri/renderD128

https://searchfox.org/mozilla-central/source/widget/gtk/GfxInfo.cpp#line-649

Can't view videos in firefox: VA-API test failed

[Stefan Monnier]

Whenever I try to view videos in Firefox in my trusty Thinkpad T61,
Firefox just eats up the CPU but doesn't actually show the video.

At startup I get the following message:

[GFX1-]: vaapitest: VA-API test failed: failed to initialise VAAPI 
connection.

So, IIUC the problem is that the hardware video decoder drivers aren't
found for some reason.  I checked my VA-related packages and they seem
to be installed:

# aptitude search '\' | grep '^i'
i A i965-va-driver - VAAPI driver for Intel G45 & HD Graphics family
i  intel-media-va-driver - VAAPI driver for the Intel GEN8+ Graphics family
i A libvdpau-va-gl1 - VDPAU driver with OpenGL/VAAPI backend
i A mesa-va-drivers - Mesa VA-API video acceleration drivers
i  va-driver-all - API de Video Acceleration (VA) – métapaquet de pilotes
i A vdpau-va-driver - VDPAU-based backend for VA API
#

I tried to install `intel-media-va-driver-non-free` to see if that's the
problem, but it did not make any difference.

I understand that my machine is fairly old, but it used to be able to
play youtube videos just fine without eating all my CPU time (i.e. using
hardware video decoding from its GM965/GL960 Intel integrated graphcs).

Any idea what might be going on?  Any hint how I could diagnose the problem?


Stefan

Re: Test

[tomas]

On Fri, Dec 22, 2023 at 05:32:04PM -0500, Jeffrey Walton wrote:

[...]

> Perhaps you should use debian-lists-test,
> <https://lists.debian.org/debian-lists-test/>.

**THANK YOU**

(I know, I'm breaking my promise of bowing out of this thread,
but this is just the kind of constructive behaviour I know and
love in this mailing list)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Test

[tomas]

On Fri, Dec 22, 2023 at 09:08:11PM +, Tixy wrote:
> On Fri, 2023-12-22 at 12:15 -0500, Pocket wrote:
> > This is a test of the emergency broadcast system
> 
> Please stop spamming the 1000 or so people subscribed to this list.

Folks: the OP might be a bit of a challenge to some of us (I
don't think they are bad intentioned; that's irrelevant here).

But all of you jumping at the occasion of such a thread and
amplificating things don't make things better, that's for
sure. Not to talk about those clamouring for some punishment
(are we in the Middle ages or what?).

You have already observed that the OP wants to have
their last word. Let 'em (sometimes) have it and let this
useless thread *die* already.

Sometimes it's just better to shut up. Even if one thinks to be
100% right [1].

Thanks (and I'll bow out of this one :-)

Cheers

[1] https://xkcd.com/386/
-- 
t


signature.asc
Description: PGP signature

Re: Test

[fjd]

On Sat, 23 Dec 2023, Vít Smolík wrote:

Should someone report the mail to the mailmasters as stated in here: 
https://www.debian.org/MailingLists/index.en.html


Or is it too small of an issue to even report?


it's teensy.

fjd

--
Davis

Verbum sat sapienti.

Re: Test

[Vít Smolík]

Vít Smolík (12023-12-23):

Yeah, it is the Code of Conduct, sorry, didn't realize that. Could there be
some SpamAssassin config that we could send to the list-masters, that would
catch theese kinds of messages?

Not without catching some legitimate questions and answers too. “Test”
is a very common word when diagnosing problems.

The best way to deal with that is to ignore the rare honest mistakes and
ban deliberate repeat offenders.

Regards,


Should someone report the mail to the mailmasters as stated in here: 
https://www.debian.org/MailingLists/index.en.html


Or is it too small of an issue to even report?

--
May the Force be with you,
Vít Smolík.



OpenPGP_0x65785543AA32C45E.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Test

[Nicolas George]

Vít Smolík (12023-12-23):
> Yeah, it is the Code of Conduct, sorry, didn't realize that. Could there be
> some SpamAssassin config that we could send to the list-masters, that would
> catch theese kinds of messages?

Not without catching some legitimate questions and answers too. “Test”
is a very common word when diagnosing problems.

The best way to deal with that is to ignore the rare honest mistakes and
ban deliberate repeat offenders.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Test

[Vít Smolík]

Vít Smolík (12023-12-23):

I think there should be added something in the rules stating that you can't
use this mailing list for testing your email client, it's pretty annoying.

It is the very first rule:

“Non-constructive or off-topic messages, along with other abuses, are
not welcome.”

And for people who pretend they did notice, it also the seventh rule:

“Do not send "test" messages to determine whether your mail client is
working.”

At this point, people should ignore that person. I could suggest sending
them answers that seem legit but will cause them to break their
computer, but that would not be nice to people stumbling upon the
archives (but probably no worse than the average Ubuntu webforum).

Regards,


Yeah, it is the Code of Conduct, sorry, didn't realize that. Could there 
be some SpamAssassin config that we could send to the list-masters, that 
would catch theese kinds of messages?


--
May the Force be with you,
Vít Smolík.



OpenPGP_0x65785543AA32C45E.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Test

[Nicolas George]

Vít Smolík (12023-12-23):
> I think there should be added something in the rules stating that you can't
> use this mailing list for testing your email client, it's pretty annoying.

It is the very first rule:

“Non-constructive or off-topic messages, along with other abuses, are
not welcome.”

And for people who pretend they did notice, it also the seventh rule:

“Do not send "test" messages to determine whether your mail client is
working.”

At this point, people should ignore that person. I could suggest sending
them answers that seem legit but will cause them to break their
computer, but that would not be nice to people stumbling upon the
archives (but probably no worse than the average Ubuntu webforum).

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Test

[Vít Smolík]

On Fri, Dec 22, 2023 at 4:37 PM Pocket  wrote:

On 12/22/23 16:08, Tixy wrote:

On Fri, 2023-12-22 at 12:15 -0500, Pocket wrote:

This is a test of the emergency broadcast system

Please stop spamming the 1000 or so people subscribed to this list.

I am not spamming this list I am trying to determine if my email setup
is working.

Perhaps you should use debian-lists-test,
<https://lists.debian.org/debian-lists-test/>.

The complete list of Debian mailing lists is available at
<https://lists.debian.org/completeindex.html>.

Jeff
I think there should be added something in the rules stating that you 
can't use this mailing list for testing your email client, it's pretty 
annoying. But, that isn't up to me.


--
May the Force be with you,
Vít Smolík.



OpenPGP_0x65785543AA32C45E.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Test

[Jeffrey Walton]

On Fri, Dec 22, 2023 at 4:37 PM Pocket  wrote:
>
> On 12/22/23 16:08, Tixy wrote:
> > On Fri, 2023-12-22 at 12:15 -0500, Pocket wrote:
> >> This is a test of the emergency broadcast system
> >
> > Please stop spamming the 1000 or so people subscribed to this list.
>
> I am not spamming this list I am trying to determine if my email setup
> is working.

Perhaps you should use debian-lists-test,
<https://lists.debian.org/debian-lists-test/>.

The complete list of Debian mailing lists is available at
<https://lists.debian.org/completeindex.html>.

Jeff

Re: Test

[Tom Furie]

Pocket  writes:

> On 12/22/23 16:08, Tixy wrote:
>> On Fri, 2023-12-22 at 12:15 -0500, Pocket wrote:
>>> This is a test of the emergency broadcast system
>> Please stop spamming the 1000 or so people subscribed to this list.
>
> I am not spamming this list I am trying to determine if my email setup
> is working.

We have no desire to be subject to your testing. Test somewhere
appropriate, not on a widespread mailing list.

Re: Test

[Pocket]

On 12/22/23 16:08, Tixy wrote:

On Fri, 2023-12-22 at 12:15 -0500, Pocket wrote:

This is a test of the emergency broadcast system


Please stop spamming the 1000 or so people subscribed to this list.



I am not spamming this list I am trying to determine if my email setup 
is working.

Re: Test

[Lee]

On Fri, Dec 22, 2023 at 4:08 PM Tixy  wrote:
>
> On Fri, 2023-12-22 at 12:15 -0500, Pocket wrote:
> > This is a test of the emergency broadcast system
>
> Please stop spamming the 1000 or so people subscribed to this list.

Would forwarding his message to commun...@debian.org and asking for a
one month suspension violate the mailing list rules?

I think no, but that might be wishful thinking..

Re: Test

[Tixy]

On Fri, 2023-12-22 at 12:15 -0500, Pocket wrote:
> This is a test of the emergency broadcast system

Please stop spamming the 1000 or so people subscribed to this list.

-- 
Tixy

Test

[Pocket]

This is a test of the emergency broadcast system

Re: Seeking an sftp location to test a problem?

[john doe]

On 10/26/23 15:47, Karen Lewellen wrote:

Because shellworld is theonly such door I know of, I need a completely
objective sftp location for testing, username  and password.


Googling around would lead you to something like [1].

[1] https://www.sftp.net/public-online-sftp-servers

--
John Doe

Seeking an sftp location to test a problem?

[Karen Lewellen]

Hi folks,
Its Karen Lewellen.
Going to ask  this question carefully.
I am having a computer built, due to a combination of experiences, DOS 
remains my main system.

However I do use sftp to reach a Linux shell service called shellworld.
Recently when I type exit, or bye, to leave sftp it reboots the computer.
The person building the new machine finds the same error, which is why 
Ineed your help.
Because shellworld is theonly such door I know of, I need a completely 
objective sftp location for testing, username  and password.
This way we discover if it is tied to my clientor shellwolrd or something 
else.

Ideas please?
Thanks,
Karen who cannot spell check this email due to computerissues

Re: HS: test après coupure du mail.

[Informatique BILLARD]

Bonjour

oui cela ne m'est pas venu à l'esprit.

Cordialement

Le 23/08/2023 à 15:57, François TOURDE a écrit :

Le 19592ième jour après Epoch,
Informatique BILLARD écrivait:


Test

François-Marie

Selon https://www.debian.org/MailingLists/#codeofconduct il faut éviter
d'envoyer ce genre de messages. Tu peux toujours t'adresser à Majordomo
pour voir l'état de ton inscription. Extrait de
https://www.debian.org/MailingLists/#subunsub :


Si vous n'êtes pas sûr d'être inscrit à l'une de nos listes de
diffusion, envoyez un message à majord...@lists.debian.org avec

which votre.adresse@electronique

dans le corps. Des informations supplémentaires sur ce service (le
dénommé "MajorSmart") sont disponibles en envoyant un autre message à
la même adresse avec

help

dans le corps du message.

Re: HS: test après coupure du mail.

[François TOURDE]

Le 19592ième jour après Epoch,
Informatique BILLARD écrivait:

> Test
>
> François-Marie

Selon https://www.debian.org/MailingLists/#codeofconduct il faut éviter
d'envoyer ce genre de messages. Tu peux toujours t'adresser à Majordomo
pour voir l'état de ton inscription. Extrait de
https://www.debian.org/MailingLists/#subunsub :

> Si vous n'êtes pas sûr d'être inscrit à l'une de nos listes de
> diffusion, envoyez un message à majord...@lists.debian.org avec
> 
> which votre.adresse@electronique
>
> dans le corps. Des informations supplémentaires sur ce service (le
> dénommé "MajorSmart") sont disponibles en envoyant un autre message à
> la même adresse avec
> 
> help
> 
> dans le corps du message.

HS: test après coupure du mail.

[Informatique BILLARD]

Test

François-Marie

Re: Test ECC memory

[Dan Ritter]

krys...@ibse.cz wrote: 
> Dan Ritter wrote:
> > The kernel announces readiness during boot with:
> > dmesg:[   18.331561] EDAC amd64: Node 0: DRAM ECC enabled.
> > 
> > and then an event looks like this:
> > Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> > kernel:[5964975.397283] [Hardware Error]: Corrected error, no
> > action required.
> > 
> > Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> > kernel:[5964975.406226] [Hardware Error]: CPU:0 (15:2:0)
> > MC4_STATUS[-|CE|MiscV|-|AddrV|-|-|CECC]: 0x9c04400040080a13
> > 
> > Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> > kernel:[5964975.418574] [Hardware Error]: Error Addr:
> > 0x001ed405ef50
> > 
> > Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> > kernel:[5964975.426919] [Hardware Error]: MC4 Error (node 0):
> > DRAM ECC error detected on the NB.
> > 
> > Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> > kernel:[5964975.437370] [Hardware Error]: cache level: L3/GEN,
> > mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)
> 
> Do you keep track of how often these errors occur?

Yes, but I'm not allowed to give much more precision than I've
already said. Rare, unless you have a failing DIMM.

-dsr-

Re: Test ECC memory

[krystof]

Dan Ritter wrote:
> The kernel announces readiness during boot with:
> dmesg:[   18.331561] EDAC amd64: Node 0: DRAM ECC enabled.
> 
> and then an event looks like this:
> Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> kernel:[5964975.397283] [Hardware Error]: Corrected error, no
> action required.
> 
> Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> kernel:[5964975.406226] [Hardware Error]: CPU:0 (15:2:0)
> MC4_STATUS[-|CE|MiscV|-|AddrV|-|-|CECC]: 0x9c04400040080a13
> 
> Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> kernel:[5964975.418574] [Hardware Error]: Error Addr:
> 0x001ed405ef50
> 
> Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> kernel:[5964975.426919] [Hardware Error]: MC4 Error (node 0):
> DRAM ECC error detected on the NB.
> 
> Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
> kernel:[5964975.437370] [Hardware Error]: cache level: L3/GEN,
> mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)

Do you keep track of how often these errors occur?

Re: Test ECC memory

[Dan Ritter]

Anssi Saari wrote: 
> Dan Ritter  writes:
> 
> > We see ECC errors irregularly and infrequently on both Intel and
> > AMD CPUs.
> 
> How/where do you see those on a Debian system? I looked into this
> briefly but didn't get anywhere.


The kernel announces readiness during boot with:
dmesg:[   18.331561] EDAC amd64: Node 0: DRAM ECC enabled.

and then an event looks like this:
Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
kernel:[5964975.397283] [Hardware Error]: Corrected error, no
action required.

Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
kernel:[5964975.406226] [Hardware Error]: CPU:0 (15:2:0)
MC4_STATUS[-|CE|MiscV|-|AddrV|-|-|CECC]: 0x9c04400040080a13

Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
kernel:[5964975.418574] [Hardware Error]: Error Addr:
0x001ed405ef50

Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
kernel:[5964975.426919] [Hardware Error]: MC4 Error (node 0):
DRAM ECC error detected on the NB.

Message from syslogd@HOSTNAME at Jan 25 15:05:51 ...
kernel:[5964975.437370] [Hardware Error]: cache level: L3/GEN,
mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)


If you see a bunch of these, you want to install edac-utils and
run it to see if you have a bad DIMM.

-dsr-

Re: Test ECC memory

[Anssi Saari]

krys...@ibse.cz writes:

> PS: Some commercial memtests should allegedly be able to inject ECC
> errors (for example the one from passmark), have anyone tried those?

I've tried Passmark's memory tester (the commercial one which includes
ECC error injection), but I've had no luck. My desktop has issues with
mouse and keyboard support in it and Grub as well, it's so bad it's
practically impossible to do anything. It's my only "modern" system with
a Ryzen 5600X and ECC RAM.

My router and file server have ECC RAM but those systems are BIOS only
and I can't boot Passmark's thing on them since it requires UEFI. I have
an oldish Intel laptop with ECC RAM also which is apparently the only
one of my computers where Passmark's thing could run. Haven't tried it
though.

Re: Test ECC memory

[Anssi Saari]

Dan Ritter  writes:

> We see ECC errors irregularly and infrequently on both Intel and
> AMD CPUs.

How/where do you see those on a Debian system? I looked into this
briefly but didn't get anywhere.

Re: Test ECC memory

[krystof]

Dne úterý 21. února 2023 1:20:50 CET, DdB napsal(a):
> Lucky me, i just looked up my hardware (Dual CPU on server MB):
> 
> > https://versus.com/en/amd-epyc-7282
> > Supports ECC memory

Yes, but it is sad that you have to search for this information somewhere else 
than on vendors website. But this is not the only thing AMD not saying to us - 
for example when using 4 dual rank DIMM, Ryzen can run them only at 2666MT/s 
intead of 3200MT/s, which is information I found only on ASRsocks websites and 
manuals. One would think that AMD will write it somewhere since memory 
controller is part of CPU, but again I have never seen it anywhere in thier 
specsheets.

Re: Test ECC memory

[DdB]

Am 20.02.2023 um 23:48 schrieb krys...@ibse.cz:
> I am sorry, it was little missleading - not that they can not support them, 
> but there is no official document that would state so. The only official 
> specsheet I saw that explicitely mentions ECC support is this one: 
> https://www.amd.com/en/products/specifications/embedded

Lucky me, i just looked up my hardware (Dual CPU on server MB):

> https://versus.com/en/amd-epyc-7282
> Supports ECC memory

I conclude: at least the hw *should* be able to ... if i manage to set
it up properly ;-)

Re: Test ECC memory

[Dan Ritter]

krys...@ibse.cz wrote: 
> Dear Debian community,
> we recently started using AMD Ryzen CPUs, ASRock Rack motherboards and 
> Kingston unbuffered ECC DIMMs for our small bussiness servers. All the 
> servers are running on ZFS for which ECC memory is recommended. So I naively 
> tried to test it actually works. I read EVERY disscussion on EVERY forum I 
> was able to find (and there is a lot of them, believe me), but I did not find 
> a satisfying answer. According to the legendary tweet from AMD (for which is 
> link in every discussion), the Ryzen CPUs should support ECC memory, but it 
> is not tested feature since they are consumer CPUs. Funny thing is, that 
> according to their spec sheets even EPYC class CPUs do not support them (only 
> CPUs with stated ECC support I found are Ryzen Embedded ones - for example 
> the V1605B in UDOO Bolt). Nevertheless system reports it works -  dmidecode, 
> lshw, kernel loads driver and EDAC MC is present in 
> /sys/devices/system/edac/mc, even memtest86+ v6.0 and above reports ECC 
> memory. In forum discussions Intel guys are saying that correctable ECC 
> errors are relatively common - stated counts vary, but I got the impression 
> that at least one in a week should appear. And our virtual hypervisor running 
> over half a year with more than 80% memory utilization has not a single one, 
> niether in sysfs nor in EUFI event log. I understand that the errror count 
> rises with height above mean sea level due to solar radiation and we are in 
> 246m altitude, but at least one error would be nice.
> The only thing I had success with was memory overclocking - I lowered timing 
> as low as possible for system to POST and when Debian was running, it 
> reported corectable errors from different memory regions (13 during 30 
> minutes). Rising memory frequency did not work. But all this was done on Asus 
> motherboard, with same memory and CPU however. When I change any memory 
> related setting on ASRock Rack motherboard, it will not POST.
> In kernel documentation is described that Intel CPUs have ability to inject 
> errors for driver testing but I did not find anything like it for AMD. Does 
> anyone know any way to test that ECC works without breaking the system 
> before? Thank you for your answers.
> 
> PS: Some commercial memtests should allegedly be able to inject ECC errors 
> (for example the one from passmark), have anyone tried those?


We see ECC errors irregularly and infrequently on both Intel and
AMD CPUs. One a week would be very concerning if we're talking
about one system, but not too concerning if we are discussing a
thousand systems.

-dsr-

Re: Test ECC memory

[krystof]

DdB wrote:
> Did you really read, that epycs cannot support ECC?
> At least i can say, that my pools did not report any faults (which ofc
> would be several layers above ecc) either in 3 years, which did help in
> falling asleep. ;-)

I am sorry, it was little missleading - not that they can not support them, but 
there is no official document that would state so. The only official specsheet 
I saw that explicitely mentions ECC support is this one: 
https://www.amd.com/en/products/specifications/embedded

Re: Test ECC memory

[gene heskett]

On 2/20/23 13:12, John Hasler wrote:

Tape the Americium-241 button out of a smoke detector to a RAM chip.


Ooooh, that would be nasty ;o(> But it ought to do the trick.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Test ECC memory

[DdB]

Am 20.02.2023 um 18:42 schrieb krys...@ibse.cz:
> Dear Debian community,
> we recently started using AMD Ryzen CPUs, ASRock Rack motherboards and 
> Kingston unbuffered ECC DIMMs for our small bussiness servers. All the 
> servers are running on ZFS for which ECC memory is recommended. So I naively 
> tried to test it actually works. I read EVERY disscussion on EVERY forum I 
> was able to find (and there is a lot of them, believe me), but I did not find 
> a satisfying answer. According to the legendary tweet from AMD (for which is 
> link in every discussion), the Ryzen CPUs should support ECC memory, but it 
> is not tested feature since they are consumer CPUs. Funny thing is, that 
> according to their spec sheets even EPYC class CPUs do not support them (only 
> CPUs with stated ECC support I found are Ryzen Embedded ones - for example 
> the V1605B in UDOO Bolt). Nevertheless system reports it works -  dmidecode, 
> lshw, kernel loads driver and EDAC MC is present in 
> /sys/devices/system/edac/mc, even memtest86+ v6.0 and above reports ECC 
> memory. In forum discussions Intel guys are saying that correctable ECC 
> errors are relatively common - stated counts vary, but I got the impression 
> that at least one in a week should appear. And our virtual hypervisor running 
> over half a year with more than 80% memory utilization has not a single one, 
> niether in sysfs nor in EUFI event log. I understand that the errror count 
> rises with height above mean sea level due to solar radiation and we are in 
> 246m altitude, but at least one error would be nice.
> The only thing I had success with was memory overclocking - I lowered timing 
> as low as possible for system to POST and when Debian was running, it 
> reported corectable errors from different memory regions (13 during 30 
> minutes). Rising memory frequency did not work. But all this was done on Asus 
> motherboard, with same memory and CPU however. When I change any memory 
> related setting on ASRock Rack motherboard, it will not POST.
> In kernel documentation is described that Intel CPUs have ability to inject 
> errors for driver testing but I did not find anything like it for AMD. Does 
> anyone know any way to test that ECC works without breaking the system 
> before? Thank you for your answers.
> 
> PS: Some commercial memtests should allegedly be able to inject ECC errors 
> (for example the one from passmark), have anyone tried those?
> 
> Best regards,
> Kryštof
> 
just saying:

i am on the same ship ... (ZFS + AMD (2 EPYCs in my case) + ECC + not
verified behavior)
Previously, i was using Intel, where i got edac to work somehow, and it
even caught some correctable errors. But since i learned, that edac went
out of business and dmidecode shall be used to get info from hardware
interrupt caused by ECC memory, i have never seen one, and as a less
than experienced debian user, i got stuck on other problems, thus forgot
to pursue this issue somehow. Now, i am very much interested in the
hints/replies you may get, in order to finally test/straighten my
infrastructure.

Did you really read, that epycs cannot support ECC?
At least i can say, that my pools did not report any faults (which ofc
would be several layers above ecc) either in 3 years, which did help in
falling asleep. ;-)

Anyone experiencing some wind in his sails while sailing along similar
paths?

... Would be welcome ...
DdB

Re: Test ECC memory

[John Hasler]

> Hi, thank you for the answer. Honestly it came to my mind I could make
> some kind of neutrino emitter, since according to most articles it is
> the main source of ECC errors,

Neutrons, not neutrinos.  The latter rarely interact with matter at
all.  A neutron source is fairly difficult to make.

> In school I was tought that a sheet of paper is enough to absorb alpha
> rays - will it penetrate a chip package?

Some will.  Attenuation of such radiation is proportional to thickness
and the level at the surface of the button, while too low to be
dangerous, is much higher than background.

A reference from https://en.wikipedia.org/wiki/ECC_memory :

https://web.archive.org/web/20131021190327/http://pdf.yuri.se/files/art/2.pdf
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Test ECC memory

[John Hasler]

Tape the Americium-241 button out of a smoke detector to a RAM chip.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Test ECC memory

[krystof]

Dear Debian community,
we recently started using AMD Ryzen CPUs, ASRock Rack motherboards and Kingston 
unbuffered ECC DIMMs for our small bussiness servers. All the servers are 
running on ZFS for which ECC memory is recommended. So I naively tried to test 
it actually works. I read EVERY disscussion on EVERY forum I was able to find 
(and there is a lot of them, believe me), but I did not find a satisfying 
answer. According to the legendary tweet from AMD (for which is link in every 
discussion), the Ryzen CPUs should support ECC memory, but it is not tested 
feature since they are consumer CPUs. Funny thing is, that according to their 
spec sheets even EPYC class CPUs do not support them (only CPUs with stated ECC 
support I found are Ryzen Embedded ones - for example the V1605B in UDOO Bolt). 
Nevertheless system reports it works -  dmidecode, lshw, kernel loads driver 
and EDAC MC is present in /sys/devices/system/edac/mc, even memtest86+ v6.0 and 
above reports ECC memory. In forum discussions Intel guys are saying that 
correctable ECC errors are relatively common - stated counts vary, but I got 
the impression that at least one in a week should appear. And our virtual 
hypervisor running over half a year with more than 80% memory utilization has 
not a single one, niether in sysfs nor in EUFI event log. I understand that the 
errror count rises with height above mean sea level due to solar radiation and 
we are in 246m altitude, but at least one error would be nice.
The only thing I had success with was memory overclocking - I lowered timing as 
low as possible for system to POST and when Debian was running, it reported 
corectable errors from different memory regions (13 during 30 minutes). Rising 
memory frequency did not work. But all this was done on Asus motherboard, with 
same memory and CPU however. When I change any memory related setting on ASRock 
Rack motherboard, it will not POST.
In kernel documentation is described that Intel CPUs have ability to inject 
errors for driver testing but I did not find anything like it for AMD. Does 
anyone know any way to test that ECC works without breaking the system before? 
Thank you for your answers.

PS: Some commercial memtests should allegedly be able to inject ECC errors (for 
example the one from passmark), have anyone tried those?

Best regards,
Kryštof

Re: Just a test

[Pierre-Elliott Bécue]

Amn  wrote on 09/11/2022 at 01:12:12+0100:

> Please disregard this email.

Alright, I'll disregard it.

-- 
PEB


signature.asc
Description: PGP signature

Re: Just a test

[Jeremy Hendricks]

I’m Jeremy, how are you?

On Tue, Nov 8, 2022 at 7:27 PM Amn  wrote:

> Please disregard this email.
>
>

Just a test

[Amn]

Please disregard this email.

Test ML

[ajh-valmer]

Essai : désolé

debian-lists-test for your test posts, was Re: Which MTA for from-based smarthost selection, local delivery and queuing?

[David Wright]

On Thu 08 Sep 2022 at 10:54:20 (-0400), rhkra...@gmail.com wrote:
> Sorry, this is a test email.  Not sure how to do it "off list" (more 
> explanation later, maybe)

There's a very underpublicised list called

  debian-lists-test

specially designed for such tests.

Cheers,
David.

test

[steef]

test (failure)

Re: test

[antoine . valmer]

On Wednesday 27 April 2022 08:54:52 Rémi Demarthe wrote:
> Le lundi 25 avril 2022 à 19:01 +0200, awache...@gmail.com a écrit :
> > On Monday 25 April 2022 17:56:36 Rémi Demarthe wrote:
> > > Le lundi 25 avril 2022 à 11:13 +0200, ajh-valmer a écrit :
> > Quel serveur de mails indique que mon mail est un spam ?
> Le mail est mis en spam côté client par évolution.
> Il ajoute les X-Spam-Flag et X-Spam-Level.

> Pour X-GND-Spam-Score et X-GND-Status, cela serait lié à un filtrage
> sieve qui si je ne m'abuse à lieu lors de la réception du serveur IMAP.
> Je n'arrive pas à comprendre pourquoi tu atteri dans les spam au regard
> des sources du message :
Oui, c'est très curieux !

> As-tu essayé les testeur de spam comme https://www.mail-tester.com/ ? :
Oui, à l'instant, il répond systématiquement que mon mail n'a pas été reçu,
SMTP l'ayant refusé, quelquesoit le smtp utilisé.

Synthèse :
1) smtp.bbox.fr , smtp.free.fr : refus immédiat,
respectivement "policy reason" et "spam detected"

2) smtp.gmail.com : mail envoyé mais pas reçu au destinataire.

3) Envoi à la ML debian avec smtp.gmail.com, 
aucun mail en retour à moi mais mail reçu sur la ML.

Re: test

[Rémi Demarthe]

Bonjour,

Le lundi 25 avril 2022 à 19:01 +0200, awache...@gmail.com a écrit :
> On Monday 25 April 2022 17:56:36 Rémi Demarthe wrote:
> > Le lundi 25 avril 2022 à 11:13 +0200, ajh-valmer a écrit :
> > > test ml
> 
> > Chez moi sur evolution le message est considéré comme spam.
> > Dans les sources :
> > X-Spam-Flag: yes
> > X-Spam-Level: ***
> > X-GND-Spam-Score: 290
> > X-GND-Status: SPAM
> > En espérant que cela puisse aider.
> 
> Oui, ça m'aide, merci.
> 
> Déjà, je n'ai pas reçu mon propre message depuis la liste,
> alors que c'est un nouveau mail créé ce matin...
> Donc à peine créé il est déjà bloqué.
> 
> Quel serveur de mails indique que mon mail est un spam ?
> 
Le mail est mis en spam côté client par évolution.
Il ajoute les X-Spam-Flag et X-Spam-Level.

Pour X-GND-Spam-Score et X-GND-Status, cela serait lié à un filtrage
sieve qui si je ne m'abuse à lieu lors de la réception du serveur IMAP.
Je n'arrive pas à comprendre pourquoi tu atteri dans les spam au regard
des sources du message.


> J'utilise smtp.bbox.fr, immédiatement je reçois ce message :
> "Le serveur a répondu : «5.7.1 Rejected for policy reason»
> Avec d'autres smtp, le destinataire ne reçoit rien,
> sinon une déclaration de spam.
> Bref, ça devient inquétiant, je ne sais quoi faire.
> Bonne soirée
> 

As-tu essayé les testeur de spam comme https://www.mail-tester.com/ ?

Bonne journée,
Crodialement,
--
Rémi Demarthe

Re: test

[Romulus 1er]

Test ok

Le lun. 25 avr. 2022 à 19:27,  a écrit :

> On Monday 25 April 2022 17:56:36 Rémi Demarthe wrote:
> > Le lundi 25 avril 2022 à 11:13 +0200, ajh-valmer a écrit :
> > > test ml
>
> > Chez moi sur evolution le message est considéré comme spam.
> > Dans les sources :
> > X-Spam-Flag: yes
> > X-Spam-Level: ***
> > X-GND-Spam-Score: 290
> > X-GND-Status: SPAM
> > En espérant que cela puisse aider.
>
> Oui, ça m'aide, merci.
>
> Déjà, je n'ai pas reçu mon propre message depuis la liste,
> alors que c'est un nouveau mail créé ce matin...
> Donc à peine créé il est déjà bloqué.
>
> Quel serveur de mails indique que mon mail est un spam ?
>
> J'utilise smtp.bbox.fr, immédiatement je reçois ce message :
> "Le serveur a répondu : «5.7.1 Rejected for policy reason»
> Avec d'autres smtp, le destinataire ne reçoit rien,
> sinon une déclaration de spam.
> Bref, ça devient inquétiant, je ne sais quoi faire.
> Bonne soirée
>
>

Re: test

[awache322]

On Monday 25 April 2022 17:56:36 Rémi Demarthe wrote:
> Le lundi 25 avril 2022 à 11:13 +0200, ajh-valmer a écrit :
> > test ml

> Chez moi sur evolution le message est considéré comme spam.
> Dans les sources :
> X-Spam-Flag: yes
> X-Spam-Level: ***
> X-GND-Spam-Score: 290
> X-GND-Status: SPAM
> En espérant que cela puisse aider.

Oui, ça m'aide, merci.

Déjà, je n'ai pas reçu mon propre message depuis la liste,
alors que c'est un nouveau mail créé ce matin...
Donc à peine créé il est déjà bloqué.

Quel serveur de mails indique que mon mail est un spam ?

J'utilise smtp.bbox.fr, immédiatement je reçois ce message :
"Le serveur a répondu : «5.7.1 Rejected for policy reason»
Avec d'autres smtp, le destinataire ne reçoit rien,
sinon une déclaration de spam.
Bref, ça devient inquétiant, je ne sais quoi faire.
Bonne soirée

Re: test

[Rémi Demarthe]

Bonjour,

Le lundi 25 avril 2022 à 11:13 +0200, ajh-valmer a écrit :
> test ml
> 

Chez moi sur evolution le message est considéré comme spam.
Dans les sources :

X-Spam-Flag: yes
X-Spam-Level: ***
X-GND-Spam-Score: 290
X-GND-Status: SPAM

En espérant que cela puisse aider.

--
Rémi Demarthe

Re: test

[ajh . valmer]

On Monday 25 April 2022 12:01:23 Fernand COSTA wrote:
> vu ;)
> Le 25/04/2022 à 11:13, ajh-valmer a écrit :
> > test ml

Merci.

Malgré mon nouveau mail ,
(l'ancien  posant problème)
je ne reçois pas le mail que j'envoie à la ML Debian en retour.

Re: test

[Fernand COSTA]

vu ;)


Le 25/04/2022 à 11:13, ajh-valmer a écrit :

test ml

test

[ajh-valmer]

test ml

Re: Test unitaire de réseau

[Olivier]

J'ai trouvé Flent, qui a l'air très (trop ?) complet et est déjà empaqueté.

[1] https://flent.org/index.html

Le lun. 7 févr. 2022 à 15:29, Pierre Couderc  a écrit :
>
> LXD peut être sympa pour cela, en regroupant plusieurs VM dans une
> machine,  même s'il passe - sous debian - par le discutable snap...
>
> On 2/7/22 14:56, Olivier wrote:
> > Bonjour,
> >
> > Il m'arrive souvent de livrer des équipements réseau (serveurs Debian,
> > routeurs, ...) dont l'assemblage doit satisfaire à des règles du type:
> > - une machine du VLAN11 doit pouvoir communiquer avec une machine du VLAN12
> > - une machine du VLAN11 doit pas pouvoir communiquer avec une machine du 
> > VLAN13
> > 
> >
> > Pour ce faire j'utilise deux ou trois PC connectés aux différents
> > équipements et je lance à la main quelques commandes du type ping,
> > iperf3, nc ou wget.
> >
> > J'aimerai mécaniser tout ce cela, à la manière des tests unitaires en
> > développement logiciel principalement pour éviter les régressions et
> > avoir une plus grande confiance.
> >
> > Plutôt qu'utiliser plusieurs machines, j'aimerai n'en utiliser qu'une
> > seule (j'imagine qu'il est plus simple de lancer les tests et lire
> > leurs résultats sur une seule machine), dotée de plusieurs interfaces
> > réseau, et de lancer un script unique lançant chaque test unitaire
> > mais s'il faut en utiliser plusieurs, j'en utiliserai plusieurs.
> >
> > Qui a déjà essayé un truc équivalent ?
> >
> > Slts
> >
>

Re: Test unitaire de réseau

[Pierre Couderc]

LXD peut être sympa pour cela, en regroupant plusieurs VM dans une 
machine,  même s'il passe - sous debian - par le discutable snap...


On 2/7/22 14:56, Olivier wrote:

Bonjour,

Il m'arrive souvent de livrer des équipements réseau (serveurs Debian,
routeurs, ...) dont l'assemblage doit satisfaire à des règles du type:
- une machine du VLAN11 doit pouvoir communiquer avec une machine du VLAN12
- une machine du VLAN11 doit pas pouvoir communiquer avec une machine du VLAN13


Pour ce faire j'utilise deux ou trois PC connectés aux différents
équipements et je lance à la main quelques commandes du type ping,
iperf3, nc ou wget.

J'aimerai mécaniser tout ce cela, à la manière des tests unitaires en
développement logiciel principalement pour éviter les régressions et
avoir une plus grande confiance.

Plutôt qu'utiliser plusieurs machines, j'aimerai n'en utiliser qu'une
seule (j'imagine qu'il est plus simple de lancer les tests et lire
leurs résultats sur une seule machine), dotée de plusieurs interfaces
réseau, et de lancer un script unique lançant chaque test unitaire
mais s'il faut en utiliser plusieurs, j'en utiliserai plusieurs.

Qui a déjà essayé un truc équivalent ?

Slts

Test unitaire de réseau

[Olivier]

Bonjour,

Il m'arrive souvent de livrer des équipements réseau (serveurs Debian,
routeurs, ...) dont l'assemblage doit satisfaire à des règles du type:
- une machine du VLAN11 doit pouvoir communiquer avec une machine du VLAN12
- une machine du VLAN11 doit pas pouvoir communiquer avec une machine du VLAN13


Pour ce faire j'utilise deux ou trois PC connectés aux différents
équipements et je lance à la main quelques commandes du type ping,
iperf3, nc ou wget.

J'aimerai mécaniser tout ce cela, à la manière des tests unitaires en
développement logiciel principalement pour éviter les régressions et
avoir une plus grande confiance.

Plutôt qu'utiliser plusieurs machines, j'aimerai n'en utiliser qu'une
seule (j'imagine qu'il est plus simple de lancer les tests et lire
leurs résultats sur une seule machine), dotée de plusieurs interfaces
réseau, et de lancer un script unique lançant chaque test unitaire
mais s'il faut en utiliser plusieurs, j'en utiliserai plusieurs.

Qui a déjà essayé un truc équivalent ?

Slts

Re: how to test and compare performance of bullseye for i386 and amd64

[a]

Sorry, last word in last mail is wrong,

it should be inconvenience, not  incontinence

Re: how to test and compare performance of bullseye for i386 and amd64

[a]

Thank David!

my mail provider blocks your reply without informing me, so i can't 
receive it on time, i get your reply by some other way


it's amazing that you get my history of getting help here,

actually i've just bought 2nd-hand pc, it's core2 Q8200, 2.33G, it's my 
fastest pc though others might think it's slow. and i'm interested in 
its performance.  my motive behind this purchase is to solve slow 
reading PDF


as to firmware complaint, i think problem is with debian, not with me, 
because other major distro (opensuse and fedora) include non-free 
firmware in their official release. but i won't switch to other distro 
for such small incontinence

Re: how to test and compare performance of bullseye for i386 and amd64

[a]

Thank Polyna-Maude Racicot-Summerside!

it's only for curiosity.

for most users, their performance have little difference

Re: how to test and compare performance of bullseye for i386 and amd64

[David Wright]

On Wed 26 Jan 2022 at 05:44:50 (-0500), Polyna-Maude Racicot-Summerside wrote:
> On 2022-01-25 19:35, David Wright wrote:
> > On Tue 25 Jan 2022 at 01:37:29 (-0500), a wrote:
> >> Thank David and Polyna-Maude!
> >>
> >> it's surprising that "The x64 binary are also somewhat larger than the
> >> i386 binaries"
> >>
> >> i compare some packages of bullseye for both arch, they happen to be
> >> contrary
> >>
> >> though difference is small and IMO has little impact on performance
> >>
> >> firefox-esr for i386: size= 58465416
> >>
> >> firefox-esr for amd64: size= 55451188
> >>
> >> gcc-10 for i386: size= 18097884
> >>
> >> gcc-10 for amd64: size=  16990272
> > 
> > Well, we've gone from ISOs containing different inventories to sizes
> > of packages. I still don't see how that affects performance.
> > 
> > All I did was to type ls -l /usr/bin for the two architectures into
> > two xterms in two viewports, and blink-compare them. Some binaries
> > were larger and some were smaller.
> > 
> > But let's try running them. I happen to have two freshly installed
> > bullseyes, and neither has run the installed FF before. Their dotfiles
> > in my home directories are close to identical, and their starting
> > pages are blank.
> > 
> > i386:
> > 
> >VSZ   RSZ %MEM  PID STAT   CMD
> > 1200184 176396 34.9   1603 Sl+firefox-esr
> > 477488 50140  9.9 1880 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc -ch>
> > 467760 34188  6.7 1821 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc -ch>
> > 455296 27436  5.4 1958 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc -ch>
> > 
> > amd64:
> > 
> >VSZ   RSZ %MEMPID STAT   CMD
> > 3082424 408156  2.5 2538 Sl+firefox-esr
> > 2446004 146664  0.9 2662 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc ->
> > 2417628 117508  0.7 2694 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc ->
> > 2403264 108072  0.6 2603 Sl+/usr/lib/firefox-esr/firefox-esr 
> > -contentproc ->
> > 
> > The difference is larger than I thought it would be. Others would
> > have to interpret the actual numbers. The main difference that
> > /I/ notice is the speed, but it would be an unfair comparison,
> > pitching 1.5GHz/512MB with 1GB encrypted swap on 2004-era rust
> > against a multi-core 2.7GHz/16GB with a 2017-era SSD (but no swap).
> > Starting times come out at 3 minutes vs perhaps one second.
> > 
> Did you ask your question in a real-world intention ? I mean based on
> something you want to implement and may have resources limitation so
> want to have the most for what you got ?
> 
> Or was it only a question for "academic" purposes ? That you wanted some
> answer and explanation without any context that you can give.

The charitable interpretation I placed on "a", aka "lou", is that
they¹ have found a 32-bit-only wireless adapter, run a 32-bit
system, and are generally unimpressed by its speed.

If you remember, reading PDFs was slow, firmware-free adapters
were hard to find, and firmware-inclusive installers were elusive,
in the eyes of the OP. So, a less charitable interpretation might
be in order.

> If it's only for curiosity then there's plenty of books to read and
> you'll find answers.

Ah, PDFs. Catch 22 here.

¹ Forgive my grammar, RMS.

Cheers,
David.

Re: how to test and compare performance of bullseye for i386 and amd64

[Polyna-Maude Racicot-Summerside]

On 2022-01-25 19:35, David Wright wrote:
> On Tue 25 Jan 2022 at 01:37:29 (-0500), a wrote:
>> Thank David and Polyna-Maude!
>>
>> it's surprising that "The x64 binary are also somewhat larger than the
>> i386 binaries"
>>
>> i compare some packages of bullseye for both arch, they happen to be
>> contrary
>>
>> though difference is small and IMO has little impact on performance
>>
>> firefox-esr for i386: size= 58465416
>>
>> firefox-esr for amd64: size= 55451188
>>
>> gcc-10 for i386: size= 18097884
>>
>> gcc-10 for amd64: size=  16990272
> 
> Well, we've gone from ISOs containing different inventories to sizes
> of packages. I still don't see how that affects performance.
> 
> All I did was to type ls -l /usr/bin for the two architectures into
> two xterms in two viewports, and blink-compare them. Some binaries
> were larger and some were smaller.
> 
> But let's try running them. I happen to have two freshly installed
> bullseyes, and neither has run the installed FF before. Their dotfiles
> in my home directories are close to identical, and their starting
> pages are blank.
> 
> i386:
> 
>VSZ   RSZ %MEM  PID STAT   CMD
> 1200184 176396 34.9   1603 Sl+firefox-esr
> 477488 50140  9.9 1880 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc -ch>
> 467760 34188  6.7 1821 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc -ch>
> 455296 27436  5.4 1958 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc -ch>
> 
> amd64:
> 
>VSZ   RSZ %MEMPID STAT   CMD
> 3082424 408156  2.5 2538 Sl+firefox-esr
> 2446004 146664  0.9 2662 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc ->
> 2417628 117508  0.7 2694 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc ->
> 2403264 108072  0.6 2603 Sl+/usr/lib/firefox-esr/firefox-esr 
> -contentproc ->
> 
> The difference is larger than I thought it would be. Others would
> have to interpret the actual numbers. The main difference that
> /I/ notice is the speed, but it would be an unfair comparison,
> pitching 1.5GHz/512MB with 1GB encrypted swap on 2004-era rust
> against a multi-core 2.7GHz/16GB with a 2017-era SSD (but no swap).
> Starting times come out at 3 minutes vs perhaps one second.
> 
Did you ask your question in a real-world intention ? I mean based on
something you want to implement and may have resources limitation so
want to have the most for what you got ?

Or was it only a question for "academic" purposes ? That you wanted some
answer and explanation without any context that you can give.

Without regards to code size or whatever, there may or may not be a
performance advantage and this depend on both the type of workload and
the system you are running under.

Regarding code size, it's also mostly dependent on some choice made
during calculation such as level of optimization and how the compiler
build the output.

So your simple question needs more real world data if you want a useful
answer.

If it's only for curiosity then there's plenty of books to read and
you'll find answers.
> Cheers,
> David.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development


OpenPGP_signature
Description: OpenPGP digital signature

Re: how to test and compare performance of bullseye for i386 and amd64

[David Wright]

On Tue 25 Jan 2022 at 01:37:29 (-0500), a wrote:
> Thank David and Polyna-Maude!
> 
> it's surprising that "The x64 binary are also somewhat larger than the
> i386 binaries"
> 
> i compare some packages of bullseye for both arch, they happen to be
> contrary
> 
> though difference is small and IMO has little impact on performance
> 
> firefox-esr for i386: size= 58465416
> 
> firefox-esr for amd64: size= 55451188
> 
> gcc-10 for i386: size= 18097884
> 
> gcc-10 for amd64: size=  16990272

Well, we've gone from ISOs containing different inventories to sizes
of packages. I still don't see how that affects performance.

All I did was to type ls -l /usr/bin for the two architectures into
two xterms in two viewports, and blink-compare them. Some binaries
were larger and some were smaller.

But let's try running them. I happen to have two freshly installed
bullseyes, and neither has run the installed FF before. Their dotfiles
in my home directories are close to identical, and their starting
pages are blank.

i386:

   VSZ   RSZ %MEM  PID STAT   CMD
1200184 176396 34.9   1603 Sl+firefox-esr
477488 50140  9.9 1880 Sl+/usr/lib/firefox-esr/firefox-esr -contentproc 
-ch>
467760 34188  6.7 1821 Sl+/usr/lib/firefox-esr/firefox-esr -contentproc 
-ch>
455296 27436  5.4 1958 Sl+/usr/lib/firefox-esr/firefox-esr -contentproc 
-ch>

amd64:

   VSZ   RSZ %MEMPID STAT   CMD
3082424 408156  2.5 2538 Sl+firefox-esr
2446004 146664  0.9 2662 Sl+/usr/lib/firefox-esr/firefox-esr 
-contentproc ->
2417628 117508  0.7 2694 Sl+/usr/lib/firefox-esr/firefox-esr 
-contentproc ->
2403264 108072  0.6 2603 Sl+/usr/lib/firefox-esr/firefox-esr 
-contentproc ->

The difference is larger than I thought it would be. Others would
have to interpret the actual numbers. The main difference that
/I/ notice is the speed, but it would be an unfair comparison,
pitching 1.5GHz/512MB with 1GB encrypted swap on 2004-era rust
against a multi-core 2.7GHz/16GB with a 2017-era SSD (but no swap).
Starting times come out at 3 minutes vs perhaps one second.

Cheers,
David.

Re: how to test and compare performance of bullseye for i386 and amd64

[Greg Wooledge]

On Tue, Jan 25, 2022 at 03:29:17PM +0100, to...@tuxteam.de wrote:
> On Tue, Jan 25, 2022 at 09:18:55AM -0500, Stefan Monnier wrote:
> > > it's surprising that "The x64 binary are also somewhat larger than the 
> > > i386
> > > binaries"
> > 
> > There is no fundamental reason why a 64bit architecture (like amd64) would
> > require more code than a 32bit architecture (like x86), but yes, on the
> > average amd64 code is a bit larger than x86.
> 
> For one, pointers are bigger. For another, ints too. So perhaps, for
> plain, straight, silly compiled C code...

I just spent a whole bunch of time writing something similar, in response
to this... and then I figured out that Stefan simply made one poor word
choice that caused the message to be extremely confusing.

I believe that what Stefan meant here is that the amd64 binary has the
same number of *instructions*.  But as you say, the instructions may be
physically longer, due to having longer operands.

So yes, amd64 compiled code tends to take up more space.  Even if it's got
the same number of instructions (which may or may not be true in all cases
-- the increased number of registers, for example, may actually decrease
the number of instructions spent moving values in and out of memory).

Re: how to test and compare performance of bullseye for i386 and amd64

[tomas]

On Tue, Jan 25, 2022 at 09:18:55AM -0500, Stefan Monnier wrote:
> > it's surprising that "The x64 binary are also somewhat larger than the i386
> > binaries"
> 
> There is no fundamental reason why a 64bit architecture (like amd64) would
> require more code than a 32bit architecture (like x86), but yes, on the
> average amd64 code is a bit larger than x86.

For one, pointers are bigger. For another, ints too. So perhaps, for
plain, straight, silly compiled C code...

>  Furthermore the static
> data that accompanies it will naturally tend to be larger since some of
> its elements will use up 64bit instead of 32bit.
> 
> For this reason, amd64 packages tend to be larger than i386 packages.

But once you talk Web browsers, which have at least one bytecode and two
JIT compilers in their fat bellies these days, all bets are up ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: how to test and compare performance of bullseye for i386 and amd64

[Andy Smith]

Hello,

On Mon, Jan 24, 2022 at 08:30:20PM -0500, a wrote:
> i've installed debian 11 for both arch on same PC, amd64 seems faster
> 
> is there some tool to demonstrate performance of PC?

Regardless of performance you should be more concerned that 32-bit
x86 parts of the Linux kernel have more bugs and receive security fixes
slower compared to amd64. For example, it took much longer for
32-bit x86 kernels to receive the same protections against the
various speculation attacks compared to amd64, in some cases it's
still not there.

Then there is the fact that increasing amounts of software simply
isn't available in 32-bit format. You might not have any with that
restriction now, but it would surely suck to want to use some in
future and not be able to without a lot of work (change your kernel
at minimum).

No one should be using 32-bit x86 today if they have the choice to
use amd64 instead.

> they say it's not possible to say which is faster without defining computing
> task

That is correct because there are many differences. amd64 has more
registers which can make code faster, but its pointers and other
data types are double the size which can affect cache hits. It
really is difficult to say without real world benchmark.

> is performance difference significant if computing task is web browsing

Modern web browsers are quite large and the 4GiB per process memory
limit with 32-bit PAE could be an issue. Otherwise, I'd guess at not
much difference.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: how to test and compare performance of bullseye for i386 and amd64

[a]

Thank David and Polyna-Maude!

it's surprising that "The x64 binary are also somewhat larger than the 
i386 binaries"


i compare some packages of bullseye for both arch, they happen to be 
contrary


though difference is small and IMO has little impact on performance

firefox-esr for i386: size= 58465416

firefox-esr for amd64: size= 55451188

gcc-10 for i386: size= 18097884

gcc-10 for amd64: size=  16990272

Re: how to test and compare performance of bullseye for i386 and amd64

[Polyna-Maude Racicot-Summerside]

On 2022-01-24 22:02, David Wright wrote:
> On Mon 24 Jan 2022 at 20:30:20 (-0500), a wrote:
>> i've installed debian 11 for both arch on same PC, amd64 seems faster
>>
>> is there some tool to demonstrate performance of PC?
>>
Yes there is standardized benchmark available. LinPack for example,
GeekBench is another one.

https://www.geekbench.com/download/


>> they say it's not possible to say which is faster without defining
>> computing task
True, AMD64 code incur some overhead.
So it will be less effective if you don't have any reason to take
advantages of the x64 architectures, for example by having less than 4
GB of RAM.

The x64 binary are also somewhat larger than the i386 binaries, they
also need more memory to run because often they will allocate 64 bit for
data "by default" on this platform.

If you are on short supply of memory, again no advantage of x64.

But this also depend on many other factors.

Because what make a difference between our PCs and high performance node
is hardware bottleneck.

So for general computing, you'll rarely exploit fully your CPU. You'll
often wait for data coming from the central memory, wait for data to be
sent out on the peripheral bus or extensions bus.

You ask a question that needs a context to be answered.

>>
>> is performance difference significant if computing task is web
>> browsing (www.debian.org)
No ! Shouldn't be, unless you have over 4 GB of RAM and would be running
many many windows/tabs/intensive web applications.

>>
>> debian-11.2.0-i386-netinst.iso is 470M while
>> debian-11.2.0-amd64-netinst.iso is 378M
>> 
>>
>> no wonder amd64 is more efficient
> 
> What exactly are you comparing here? Generally speaking, the amd64
> packages are /larger/ than the i386 ones: hardly surprising.
> 
> But the i386 ISOs have /two/ versions of many packages, the PAE
> ones and the non-PAE ones.
> 
Based solely on the size on a installation CD making affirmation
regarding benchmark is really doing a shortcut to deliver conclusion.

The question ask require more information to get a real answer.

I seriously doubt that you'll really feel difference in real life type
workload. Even using benchmark tools does not relate to real life
workload, unless you are doing physics simulation, financial analysis
regression or other math workload. In such case, you wouldn't ask such
question and already hold the answer.

> Cheers,
> David.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development


OpenPGP_signature
Description: OpenPGP digital signature

Re: how to test and compare performance of bullseye for i386 and amd64

[David Wright]

On Mon 24 Jan 2022 at 20:30:20 (-0500), a wrote:
> i've installed debian 11 for both arch on same PC, amd64 seems faster
> 
> is there some tool to demonstrate performance of PC?
> 
> they say it's not possible to say which is faster without defining
> computing task
> 
> is performance difference significant if computing task is web
> browsing (www.debian.org)
> 
> debian-11.2.0-i386-netinst.iso is 470M while
> debian-11.2.0-amd64-netinst.iso is 378M
> 
> 
> no wonder amd64 is more efficient

What exactly are you comparing here? Generally speaking, the amd64
packages are /larger/ than the i386 ones: hardly surprising.

But the i386 ISOs have /two/ versions of many packages, the PAE
ones and the non-PAE ones.

Cheers,
David.

how to test and compare performance of bullseye for i386 and amd64

[a]

i've installed debian 11 for both arch on same PC, amd64 seems faster

is there some tool to demonstrate performance of PC?

they say it's not possible to say which is faster without defining 
computing task


is performance difference significant if computing task is web browsing 
(www.debian.org)


debian-11.2.0-i386-netinst.iso is 470M while 
debian-11.2.0-amd64-netinst.iso is 378M



no wonder amd64 is more efficient

Re: Please help to test latest Debian 11 release candidate on real hardware

[Robbi Nespu]

The data also on salsa now
https://salsa.debian.org/linuxhw/TestCoverage/-/tree/main/Dist/Debian_11


--
Robbi Nespu 
D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
https://robbinespu.gitlab.io | https://mstdn.social/@robbinespu

Re: Please help to test latest Debian 11 release candidate on real hardware

[Andrey Ponomarenko]

> on 24 Jul 2021 16:27:23 -0400, Jim Popovitch  wrote
> 
>> Why isn't this on Salsa instead of a Microsoft site?
> 
> the package are dump and store at
> https://salsa.debian.org/debian/hw-probe by debian package maintainer,
> maybe the upstream author (Andrey Ponomarenko) want to centralize
> testcoverage report using same repo?
> 
> i have issued https://github.com/linuxhw/TestCoverage/issues/1 about the
> ideas of using salsa for debian testcoverage
> 
> The tool using dual license (LGPL-2.1-or-later OR BSD-4-Clause), You can
> choose between one of them but not sure about the testcoverage reports
> 
> --
> Robbi Nespu 
> D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
> https://robbinespu.gitlab.io | https://mstdn.social/@robbinespu

The report is now available in Debian Salsa: 
https://salsa.debian.org/linuxhw/TestCoverage/-/tree/main/Dist/Debian_11

The license is CC-BY-4.0.

Re: test vs. [ [was: Bash script problem]

[tomas]

On Thu, Aug 05, 2021 at 08:32:39AM -0400, Greg Wooledge wrote:
> On Thu, Aug 05, 2021 at 01:59:06PM +0200, to...@tuxteam.de wrote:
> > On Thu, Aug 05, 2021 at 07:19:11AM -0400, Greg Wooledge wrote:
> > > The external versions of test and [ need to exist for POSIX conformance,
> > > and also so that you can -exec them from find(1) or other similar
> > > programs.
> > 
> > I see. Do we still (seriously) care about POSIX (don't get me wrong: I'd
> > strongly prefer a world where we did!).
> 
> Depends on who you mean by "we".

:-)

>  There are a bunch of people who do
> care, and a bunch of people who don't.

Yes, and I see that as a problem.

> I'd say the Debian developers who package things like coreutils care,
> at least to a certain degree.  They won't go to extreme lengths to be
> POSIX compatible, but they'll mostly try to do so if it doesn't break
> anything or cause an unreasonable burden.

[...]

> I can't say which decision is the better one.

I think this "soft POSIX compliance" might kill POSIX in the long run.
Since everyone feels free to route around his/her personal pain points,
there's little collective motivation to actually /fix/ them, and it
might drift slowly into irrelevance.

Now I'm not a 100% fan of POSIX /per se/ but I see the value in
written standards. Standards processes can seem at times clumsy, but
they force people to think about interfaces and specifications.

Otherwise it's what we have now with WHATWG's HTML5 "living standard",
which will end up with "whatever Google implements". Not much better,
in my eyes, than the bad old times of Microsoft dominance.

Cheers
 - t


signature.asc
Description: Digital signature

Re: test vs. [ [was: Bash script problem]

[Greg Wooledge]

On Thu, Aug 05, 2021 at 01:59:06PM +0200, to...@tuxteam.de wrote:
> On Thu, Aug 05, 2021 at 07:19:11AM -0400, Greg Wooledge wrote:
> > The external versions of test and [ need to exist for POSIX conformance,
> > and also so that you can -exec them from find(1) or other similar
> > programs.
> 
> I see. Do we still (seriously) care about POSIX (don't get me wrong: I'd
> strongly prefer a world where we did!).

Depends on who you mean by "we".  There are a bunch of people who do
care, and a bunch of people who don't.

I'd say the Debian developers who package things like coreutils care,
at least to a certain degree.  They won't go to extreme lengths to be
POSIX compatible, but they'll mostly try to do so if it doesn't break
anything or cause an unreasonable burden.

A bigger issue is that certain packages which *should* be present for
POSIX compatibility are simply not installed by default -- specifically,
pax and ed come to mind.  I don't know who made the decision that
these packages would be "optional" instead of "standard", but it leaves
significant holes in what would otherwise be a fairly POSIX-compliant
operating system.

Then again, users who care about having POSIX-compliant systems can
simply install the extra packages they need, once they learn that they
have this option.  Maybe Debian believes that the small savings in
disk space and bandwidth outweighs the merits of being closer to POSIX
compatibility, since so few end users actually care about the latter.

I can't say which decision is the better one.

test vs. [ [was: Bash script problem]

[tomas]

On Thu, Aug 05, 2021 at 07:19:11AM -0400, Greg Wooledge wrote:
> On Thu, Aug 05, 2021 at 10:07:12AM +0200, to...@tuxteam.de wrote:
> > [1] Nowadays this is a little white lie: most shells have them
> >as builtins, but they are supposed to behave like regular
> >programs, for compat. There /is/ a /bin/test, but I can't
> >find a /bin/[ on my system anymore.
> 
> It's in /usr/bin on Debian.

Ah, there it is, thanks.

With all those young-uns shaking Unix's foundations, one never
knows ;-P

[...]

> I'm a bit surprised they're not the same program.  And also that they're
> that large.  And that different in size from each other.

Yes, that's my recollection too: [ being a symlink to test (or even both
being hardlinked together). This might betray my age...

> The external versions of test and [ need to exist for POSIX conformance,
> and also so that you can -exec them from find(1) or other similar
> programs.

I see. Do we still (seriously) care about POSIX (don't get me wrong: I'd
strongly prefer a world where we did!).

Cheers
 - t


signature.asc
Description: Digital signature

Re: Please help to test latest Debian 11 release candidate on real hardware

[David Wright]

On Thu 29 Jul 2021 at 12:54:14 (+0300), Anssi Saari wrote:
> Andrey Ponomarenko  writes:
> 
> > LiveCDs for quick testing:
> > https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/
> 
> Well, are these images bootable via Grub directly and if so then what
> parameters are needed? Making testing easy eases testing...

As the images are iso-hybrids, you should be able to boot
them from a USB stick or a CD, and in a machine that boots
via UEFI or BIOS. Grub shouldn't be involved, as iso-hybrids
use isolinux.

Do you /particlarly/ want to use Grub? If so, it's possible,
but far more involved, and is basically a workaround if you
have no CD burner /and/ can't boot the machine from USB.

Cheers,
David.

Re: Please help to test latest Debian 11 release candidate on real hardware

[Anssi Saari]

Andrey Ponomarenko  writes:

> LiveCDs for quick testing:
> https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/

Well, are these images bootable via Grub directly and if so then what
parameters are needed? Making testing easy eases testing...