Re: Automatic reboot on kernel crash in Debian 12 - how?

[Max Nikulin]

On 16/04/2024 16:17, Michael Kjörling wrote:

I have a handful of Debian 12 systems that I want to configure such
that they reboot automatically in case of a problem.

[...]

That leaves kernel-level issues.


I have not tried it, but I have seen some systemd options related to 
configuration of hardware watchdog: systemd.directives(7) and 
systemd-system.conf(5)

Re: Automatic reboot on kernel crash in Debian 12 - how?

[Franco Martelli]

On 16/04/24 at 11:17, Michael Kjörling wrote:

Do I need to set some more settings to ensure that the system will
automatically reboot on a panic? If so, what?


Hi,

In the Linux kernel source are available two options to reboot on panic:

config BOOTPARAM_SOFTLOCKUP_PANIC
bool "Panic (Reboot) On Soft Lockups"
depends on SOFTLOCKUP_DETECTOR
help
  Say Y here to enable the kernel to panic on "soft lockups",
  which are bugs that cause the kernel to loop in kernel
  mode for more than 20 seconds (configurable using the 
watchdog_thresh

  sysctl), without giving other tasks a chance to run.

  The panic can be used in combination with panic_timeout,
  to cause the system to reboot automatically after a
  lockup has been detected. This feature is useful for
  high-availability systems that have uptime guarantees and
  where a lockup must be resolved ASAP.

  Say N if unsure.

and:

config BOOTPARAM_HARDLOCKUP_PANIC
bool "Panic (Reboot) On Hard Lockups"
depends on HARDLOCKUP_DETECTOR
help
  Say Y here to enable the kernel to panic on "hard lockups",
  which are bugs that cause the kernel to loop in kernel
  mode with interrupts disabled for more than 10 seconds 
(configurable

  using the watchdog_thresh sysctl).

  Say N if unsure.

from Documentation/admin-guide/kernel-parameters.txt you can set it as 
kernel parameter or via sysctls:


softlockup_panic=
[KNL] Should the soft-lockup detector generate 
panics.

Format: 0 | 1

A value of 1 instructs the soft-lockup detector
to panic the machine when a soft-lockup occurs. 
It is
also controlled by the kernel.softlockup_panic 
sysctl

and CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC, which is the
respective build-time switch to that functionality.

and the same for "kernel.hardlockup_panic" that it seems it hasn't an 
help entry in the documentation file, I found it here:



nmi_watchdog=   [KNL,BUGS=X86] Debugging features for SMP kernels
Format: [panic,][nopanic,][num]
Valid num: 0 or 1
0 - turn hardlockup detector in nmi_watchdog off
1 - turn hardlockup detector in nmi_watchdog on
When panic is specified, panic when an NMI watchdog
timeout occurs (or 'nopanic' to not panic on an NMI
watchdog, if CONFIG_BOOTPARAM_HARDLOCKUP_PANIC 
is set)

To disable both hard and soft lockup detectors,
please see 'nowatchdog'.
This is useful when you use a panic=... timeout and
need the box quickly up again.

These settings can be accessed at runtime via
the nmi_watchdog and hardlockup_panic sysctls.

To learn more I suggest to install the "linux-source-6.1" package and 
investigate the "Watchdog" option, it is under "Device Drivers".
The BOOTPARAM_SOFTLOCKUP_PANIC and BOOTPARAM_HARDLOCKUP_PANIC options 
are under "Kernel hacking" → "Debug Oops, Lockups and Hangs".


Cheers
--
Franco Martelli

Re: Automatic reboot on kernel crash in Debian 12 - how?

[Michael Kjörling]

On 16 Apr 2024 11:42 +0200, from geo...@nsup.org (Nicolas George):
>> Are you saying that the settings themselves are reasonable for the
>> purpose, and that this particular crash just happened to be such a one
>> that no software running on the system in question can reasonably help
>> with that scenario?
> 
> No, unfortunately I do not have the gift of divination, it would be
> convenient. I am saying that you cannot use software to protect yourself
> entirely from software bugs.

Well, naturally. But if there is some setting which I _could_ set that
would get me closer to my desired state, I would still like to know
which one and perhaps even what might be an appropriate value for it.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Automatic reboot on kernel crash in Debian 12 - how?

[Nicolas George]

Michael Kjörling (12024-04-16):
> Are you saying that the settings themselves are reasonable for the
> purpose, and that this particular crash just happened to be such a one
> that no software running on the system in question can reasonably help
> with that scenario?

No, unfortunately I do not have the gift of divination, it would be
convenient. I am saying that you cannot use software to protect yourself
entirely from software bugs.

> This happened on a VM that I can't directly influence the hardware
> configuration of (a commercially provided VPS), but I should be able
> to jury-rig something using the provider's API if necessary.

You probably can. But first check if your VM has an emulated hardware
watchdog.

Regards,

-- 
  Nicolas George

Re: Automatic reboot on kernel crash in Debian 12 - how?

[Michael Kjörling]

On 16 Apr 2024 11:22 +0200, from geo...@nsup.org (Nicolas George):
>> Do I need to set some more settings to ensure that the system will
>> automatically reboot on a panic? If so, what?
> 
> If the crash was bad enough to freeze the kernel before it could
> trigger the reboot, there is nothing the software can do.
> 
> You need a hardware watchdog.

Are you saying that the settings themselves are reasonable for the
purpose, and that this particular crash just happened to be such a one
that no software running on the system in question can reasonably help
with that scenario?

This happened on a VM that I can't directly influence the hardware
configuration of (a commercially provided VPS), but I should be able
to jury-rig something using the provider's API if necessary.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Automatic reboot on kernel crash in Debian 12 - how?

[Nicolas George]

Michael Kjörling (12024-04-16):
> However, this morning I woke up to one of those systems showing a
> kernel crash dump and being frozen. Unfortunately the first part of
> the crash dump had scrolled past so I couldn't tell what class of
> problem caused the crash.
> 
> Do I need to set some more settings to ensure that the system will
> automatically reboot on a panic? If so, what?

If the crash was bad enough to freeze the kernel before it could
trigger the reboot, there is nothing the software can do.

You need a hardware watchdog. If your motherboard has one, just install
and enable the corresponding daemon, and check it works by SIGSTOPing
it.

If your motherboard does not have one, you can probably DIY one from a
RPi or an Arduino.

Regards,

-- 
  Nicolas George

Automatic reboot on kernel crash in Debian 12 - how?

[Michael Kjörling]

I have a handful of Debian 12 systems that I want to configure such
that they reboot automatically in case of a problem. I have set them
up with userspace scripts (executed through cron) to reboot if
something goes wrong there; that appears to work as expected if I
induce an issue that those scripts check for. That leaves kernel-level
issues.

To try to configure this, I have created a file
/etc/sysctl.d/local.conf (owned by root:root, mode 0644).

# cat /etc/sysctl.d/local.conf
kernel.panic = 120
kernel.panic_on_oops = 1
kernel.panic_on_stackoverflow = 1
kernel.panic_on_io_nmi = 1
#

With the exception of panic_on_stackoverflow, as far as I can tell
these are in effect after a reboot:

#  sysctl kernel.panic kernel.panic_on_oops kernel.panic_on_stackoverflow 
kernel.panic_on_io_nmi
kernel.panic = 120
kernel.panic_on_oops = 1
sysctl: cannot stat /proc/sys/kernel/panic_on_stackoverflow: No such file or 
directory
kernel.panic_on_io_nmi = 1
#

However, this morning I woke up to one of those systems showing a
kernel crash dump and being frozen. Unfortunately the first part of
the crash dump had scrolled past so I couldn't tell what class of
problem caused the crash.

Do I need to set some more settings to ensure that the system will
automatically reboot on a panic? If so, what?

I know that best is to not crash; this is _in case of_.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: problèmes de copie sur un montage smb, crash kernel

[testeur]

Salut,

Merci Erwann pour le retour.

Ça tombe bien, c'est un syno également qui fait le service de fichiers 
en SMB.
Je viens d'activer le service en NFS pour tester... et, là, la copie ne 
plante pas (deb démarré avec le noyau *6.1.0-17*).


Donc, il y a quelquechose qui ne se passe pas bien entre le SMB de syno 
et le noyau*6.1.0-17*, car avec le noyau *6.1.0-10* pas de soucis.


Apriori tester de ton côté le SMB, amènera certainement un "crash 
kernel" je pense.


Par contre sur le syno, la version de samba est (un peu ancienne) :

Version 4.15.9
Synology Build 42934, Jul  5 2023 16:31:41

ce qui peut peut-être expliquer le problème (?)

T


On 03/02/2024 13:08, Erwann Le Bras wrote:


bonjour

Pas de pb constaté pour ma part. Peut-être que le fautif serait le 
serveur?


Pour ma part :

erwann@inspiron:~$ uname -a
Linux inspiron *6.1.0-17-amd64* #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 
(2023-12-30) x86_64 GNU/Linux

erwann@inspiron:~$ grep synology /etc/fstab
#synology:/volume1/pub        /mnt/pub        nfs 
nofail,soft,timeo=5,intr,rsize=8192,wsize=8192,users,atime,rw,dev,exec,suid 
0    0
synology:/volume1/pub        /mnt/pub        nfs 
nofail,rsize=8192,wsize=8192,timeo=14    0    0
#synology:/volume1/backup    /mnt/backup nfs 
nofail,rsize=8192,wsize=8192,timeo=14,intr  0 0
synology:/volume1/backup    /mnt/backup        nfs 
nofail,soft,timeo=5,intr,rsize=8192,wsize=8192,users,atime,rw,dev,exec,suid 
0    0
#synology:/volume1/backup    /mnt/backup        nfs 
nofail,rsize=8192,wsize=8192,timeo=14    0    0


Les copies fonctionnent sans problème.

Dans mon cas, le serveur NFS est un NAS Synology DS216se

Je ne me souviens plus pourquoi j'ai des options différentes pour les 
deux points de montage.


Erwann

Le 02/02/2024 à 21:28, testeur a écrit :

J'ai tenté les trois options de montage mais pas mieux.
Le log du crash noyau est quasi identique.

Ça semble venir du noyau 6.1.0-17.

Car avec le noyau 6.1.0-10, pas de problèmes

Je vais rester sur le noyau précédent...

Cdlt

On 01/02/2024 10:11, Michel Verdier wrote:

Le 31 janvier 2024 testeur a écrit :


voici les droits du montage :

├─/mnt/xxx /etc/autoxxx.smb autofs 
rw,relatime,fd=12,pgrp=1561,timeout=30,minproto=5,maxproto=5,indirect,pipe_ino=22915

│ └─/mnt/xxx/conf
//xx.xx.xx.xx/xxx/conf cifs
rw,relatime,vers=3.1.1,cache=strict,username=xxx,uid=1000,noforceuid,gid=1000,noforcegid,addr=xx.xx.xx.xx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1 

Tu peux peut-être essayer avec cache=none et hard (au lieu de soft) 
pour

voir si tu obtiens plus d'infos. Tu peux aussi jouer avec echo_interval
si ton réseau ou ton serveur distant est lent. Je ne me souviens plus
pour autofs mais son timeout ne devrait-il pas être plus élevé que 
celui

de cifs ?

Re: problèmes de copie sur un montage smb, crash kernel

[Erwann Le Bras]

bonjour

Pas de pb constaté pour ma part. Peut-être que le fautif serait le serveur?

Pour ma part :

erwann@inspiron:~$ uname -a
Linux inspiron *6.1.0-17-amd64* #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 
(2023-12-30) x86_64 GNU/Linux

erwann@inspiron:~$ grep synology /etc/fstab
#synology:/volume1/pub        /mnt/pub        nfs 
nofail,soft,timeo=5,intr,rsize=8192,wsize=8192,users,atime,rw,dev,exec,suid 
0    0
synology:/volume1/pub        /mnt/pub        nfs 
nofail,rsize=8192,wsize=8192,timeo=14    0    0
#synology:/volume1/backup    /mnt/backup nfs 
nofail,rsize=8192,wsize=8192,timeo=14,intr  0   0
synology:/volume1/backup    /mnt/backup        nfs 
nofail,soft,timeo=5,intr,rsize=8192,wsize=8192,users,atime,rw,dev,exec,suid 
0    0
#synology:/volume1/backup    /mnt/backup        nfs 
nofail,rsize=8192,wsize=8192,timeo=14    0    0


Les copies fonctionnent sans problème.

Dans mon cas, le serveur NFS est un NAS Synology DS216se

Je ne me souviens plus pourquoi j'ai des options différentes pour les 
deux points de montage.


Erwann

Le 02/02/2024 à 21:28, testeur a écrit :

J'ai tenté les trois options de montage mais pas mieux.
Le log du crash noyau est quasi identique.

Ça semble venir du noyau 6.1.0-17.

Car avec le noyau 6.1.0-10, pas de problèmes

Je vais rester sur le noyau précédent...

Cdlt

On 01/02/2024 10:11, Michel Verdier wrote:

Le 31 janvier 2024 testeur a écrit :


voici les droits du montage :

├─/mnt/xxx /etc/autoxxx.smb autofs 
rw,relatime,fd=12,pgrp=1561,timeout=30,minproto=5,maxproto=5,indirect,pipe_ino=22915

│ └─/mnt/xxx/conf
//xx.xx.xx.xx/xxx/conf cifs
rw,relatime,vers=3.1.1,cache=strict,username=xxx,uid=1000,noforceuid,gid=1000,noforcegid,addr=xx.xx.xx.xx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1 


Tu peux peut-être essayer avec cache=none et hard (au lieu de soft) pour
voir si tu obtiens plus d'infos. Tu peux aussi jouer avec echo_interval
si ton réseau ou ton serveur distant est lent. Je ne me souviens plus
pour autofs mais son timeout ne devrait-il pas être plus élevé que celui
de cifs ?

Re: problèmes de copie sur un montage smb, crash kernel

[testeur]

J'ai tenté les trois options de montage mais pas mieux.
Le log du crash noyau est quasi identique.

Ça semble venir du noyau 6.1.0-17.

Car avec le noyau 6.1.0-10, pas de problèmes

Je vais rester sur le noyau précédent...

Cdlt

On 01/02/2024 10:11, Michel Verdier wrote:

Le 31 janvier 2024 testeur a écrit :


voici les droits du montage :

├─/mnt/xxx  /etc/autoxxx.smb
 autofs  
rw,relatime,fd=12,pgrp=1561,timeout=30,minproto=5,maxproto=5,indirect,pipe_ino=22915
│ └─/mnt/xxx/conf
//xx.xx.xx.xx/xxx/conf cifs
rw,relatime,vers=3.1.1,cache=strict,username=xxx,uid=1000,noforceuid,gid=1000,noforcegid,addr=xx.xx.xx.xx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1

Tu peux peut-être essayer avec cache=none et hard (au lieu de soft) pour
voir si tu obtiens plus d'infos. Tu peux aussi jouer avec echo_interval
si ton réseau ou ton serveur distant est lent. Je ne me souviens plus
pour autofs mais son timeout ne devrait-il pas être plus élevé que celui
de cifs ?

Re: problèmes de copie sur un montage smb, crash kernel

[Michel Verdier]

Le 31 janvier 2024 testeur a écrit :

> voici les droits du montage :
>
> ├─/mnt/xxx  /etc/autoxxx.smb  
>autofs  
> rw,relatime,fd=12,pgrp=1561,timeout=30,minproto=5,maxproto=5,indirect,pipe_ino=22915
> │ └─/mnt/xxx/conf
> //xx.xx.xx.xx/xxx/conf cifs
> rw,relatime,vers=3.1.1,cache=strict,username=xxx,uid=1000,noforceuid,gid=1000,noforcegid,addr=xx.xx.xx.xx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1

Tu peux peut-être essayer avec cache=none et hard (au lieu de soft) pour
voir si tu obtiens plus d'infos. Tu peux aussi jouer avec echo_interval
si ton réseau ou ton serveur distant est lent. Je ne me souviens plus
pour autofs mais son timeout ne devrait-il pas être plus élevé que celui
de cifs ?

problèmes de copie sur un montage smb, crash kernel

[testeur]

Bonjour,
J'ai un problème pour faire une copie simple de fichiers (cp hosts 
hosts.txt) au sein d'un partage SMB (monté par autofs). ça m'indique 
"Processus arrêté", puis après un nouvel essai ça reste bloqué/freezé, 
je n'ai plus la main sur la console (ctl+C, D, Z n'ont aucune action). 
Quand je créé un fichier, pas de souci, quand j'édite un fichier pas de 
souci, le seul problème est de copier. La suppression ni le 
renommage/déplacement n'est problématique. le processus est indiqué 
ainsi : xxx 25304 24752 0 21:35 pts/2 00:00:00 cp hosts hosts.txt le 
kill du processus ne fonctionne pas. Les droits sur les fichiers : 
-rwxr-xr-x 1 xxx yyy 0 31 janv. 21:34 hosts.txt -rwxr-xr-x 1 xxx yyy 0 
28 janv. 18:13 hosts voici les droits du montage : ├─/mnt/xxx 
/etc/autoxxx.smb autofs 
rw,relatime,fd=12,pgrp=1561,timeout=30,minproto=5,maxproto=5,indirect,pipe_ino=22915 
│ └─/mnt/xxx/conf //xx.xx.xx.xx/xxx/conf cifs 
rw,relatime,vers=3.1.1,cache=strict,username=xxx,uid=1000,noforceuid,gid=1000,noforcegid,addr=xx.xx.xx.xx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1 
le noyau actuel de debian 12 : Linux vfpm 6.1.0-17-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux


Dans syslog, j'obtiens des erreurs au niveau du kernel.

2024-01-29T21:20:24.524146+01:00 vfpm kernel: [ 7967.200355] BUG: kernel 
NULL pointer dereference, address: 
2024-01-29T21:20:24.524163+01:00 vfpm kernel: [ 7967.200364] #PF: 
supervisor read access in kernel mode
2024-01-29T21:20:24.524167+01:00 vfpm kernel: [ 7967.200367] #PF: 
error_code(0x) - not-present page

2024-01-29T21:20:24.524167+01:00 vfpm kernel: [ 7967.200370] PGD 0 P4D 0
2024-01-29T21:20:24.524168+01:00 vfpm kernel: [ 7967.200374] Oops:  
[#1] PREEMPT SMP PTI
2024-01-29T21:20:24.524169+01:00 vfpm kernel: [ 7967.200378] CPU: 7 PID: 
9346 Comm: cp Tainted: P  IOE  6.1.0-17-amd64 #1  Debian 
6.1.69-1
2024-01-29T21:20:24.524170+01:00 vfpm kernel: [ 7967.200383] Hardware 
name: Hewlett-Packard HP Z400 Workstation/0B4Ch, BIOS 786G3 v03.15 
10/29/2010
2024-01-29T21:20:24.524171+01:00 vfpm kernel: [ 7967.200385] RIP: 
0010:cifs_flush_folio+0x3f/0x100 [cifs]
2024-01-29T21:20:24.524172+01:00 vfpm kernel: [ 7967.200471] Code: d2 41 
54 49 89 cc 31 c9 55 48 89 f5 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 e8 
8d 8a 49 c8 48 3d 00 f0 ff ff 0f 87 a5 00 00 00 <48> 8b 10 48 89 c3 b8 
00 10 00 00 f7 c2 00 00 01 00 74 07 0f b6 4b
2024-01-29T21:20:24.524173+01:00 vfpm kernel: [ 7967.200475] RSP: 
0018:a454888d7c98 EFLAGS: 00010207
2024-01-29T21:20:24.524175+01:00 vfpm kernel: [ 7967.200478] RAX: 
 RBX:  RCX: 
2024-01-29T21:20:24.524188+01:00 vfpm kernel: [ 7967.200481] RDX: 
 RSI:  RDI: 98c949229840
2024-01-29T21:20:24.524190+01:00 vfpm kernel: [ 7967.200483] RBP: 
 R08: 0001 R09: 
2024-01-29T21:20:24.524191+01:00 vfpm kernel: [ 7967.200485] R10: 
 R11:  R12: a454888d7d08
2024-01-29T21:20:24.524192+01:00 vfpm kernel: [ 7967.200487] R13: 
a454888d7d00 R14: 98ca472d3228 R15: 0001
2024-01-29T21:20:24.524193+01:00 vfpm kernel: [ 7967.200490] FS: 
7f69d9003500() GS:98cad7bc() knlGS:
2024-01-29T21:20:24.524194+01:00 vfpm kernel: [ 7967.200493] CS: 0010 
DS:  ES:  CR0: 80050033
2024-01-29T21:20:24.524195+01:00 vfpm kernel: [ 7967.200496] CR2: 
 CR3: 000104be6000 CR4: 06e0

2024-01-29T21:20:24.524196+01:00 vfpm kernel: [ 7967.200498] Call Trace:
2024-01-29T21:20:24.524197+01:00 vfpm kernel: [ 7967.200502] 
2024-01-29T21:20:24.524198+01:00 vfpm kernel: [ 7967.200506]  ? 
__die_body.cold+0x1a/0x1f
2024-01-29T21:20:24.524200+01:00 vfpm kernel: [ 7967.200515]  ? 
page_fault_oops+0xd2/0x2b0
2024-01-29T21:20:24.524201+01:00 vfpm kernel: [ 7967.200524]  ? 
exc_page_fault+0x70/0x170
2024-01-29T21:20:24.524202+01:00 vfpm kernel: [ 7967.200531]  ? 
asm_exc_page_fault+0x22/0x30
2024-01-29T21:20:24.524202+01:00 vfpm kernel: [ 7967.200541]  ? 
cifs_flush_folio+0x3f/0x100 [cifs]
2024-01-29T21:20:24.524203+01:00 vfpm kernel: [ 7967.200607]  ? 
cifs_flush_folio+0x33/0x100 [cifs]
2024-01-29T21:20:24.524204+01:00 vfpm kernel: [ 7967.200662] 
cifs_remap_file_range+0x16d/0x680 [cifs]
2024-01-29T21:20:24.524205+01:00 vfpm kernel: [ 7967.200743] 
do_clone_file_range+0xe9/0x230
2024-01-29T21:20:24.524206+01:00 vfpm kernel: [ 7967.200751] 
vfs_clone_file_range+0x37/0x140
2024-01-29T21:20:24.524207+01:00 vfpm kernel: [ 7967.200756] 
ioctl_file_clone+0x49/0xb0
2024-01-29T21:20:24.524208+01:00 vfpm kernel: [ 7967.200763] 
do_vfs_ioctl+0x77/0x910
2024-01-29T21:20:24.524208+01:00 vfpm kernel: [ 7967.200769] 
__x64_sys_ioctl+0x6e/0xd0
2024-01-29T21:20:24.524209+01:00 vfpm kernel: [ 7967.200775] 

Re: Isolated Web Co Session crash Firefox-ESR

[tomas]

On Wed, Dec 06, 2023 at 09:27:06PM +0700, Max Nikulin wrote:
> On 06/12/2023 12:04, to...@tuxteam.de wrote:
> > On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:
> > > 
> > > sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> > > 
> > > Sadly it looks like I'll need to do this daily,
> > 
> > See /etc/sysctl.conf and /etc/sysctl.conf.d if you want to make such things
> > persistent.
> 
> This particular one can not be made persistent. Writing to this file causes
> kernel action.

D'oh, thanks. Sorry for the confusion.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Isolated Web Co Session crash Firefox-ESR

[Max Nikulin]

On 06/12/2023 01:42, jeremy ardley wrote:

I have discovered a magic bullet for solving running out of memory

sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Sadly it looks like I'll need to do this daily, simply for using Debian 
Bookworm with a variety of web browsers


Magic does not work. From my point of view, the scope of such command is 
benchmarking of cold start in some applications. It ensures that all 
files are read from disk, not taken from RAM caches.


The command certainly may change numbers presented by free(1) or top(1). 
Actually if it can increase amount of free memory then applications 
should not starve from insufficient RAM. Kernel should drop some caches 
in response to memory allocation request.


Probable negative consequence is that some files will be read again.

You mentioned that you have no swap on this machine (I remember, 
actually swap exists). Does it mean that you followed some guide trying 
to optimize system performance e.g. to minimize SSD wearing?


I suspect that changing some kernel tunables may degrade cache 
performance. I would try to start from clean state. Unfortunately my 
experience with such optimizing is negligible.

Re: Isolated Web Co Session crash Firefox-ESR

[Max Nikulin]

On 06/12/2023 12:04, to...@tuxteam.de wrote:

On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:


sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Sadly it looks like I'll need to do this daily,


See /etc/sysctl.conf and /etc/sysctl.conf.d if you want to make such things
persistent.


This particular one can not be made persistent. Writing to this file 
causes kernel action.


https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html#drop-caches

However I am in doubt if it may be useful for the issue with browsers.

Re: Isolated Web Co Session crash Firefox-ESR

[debian-user]

Karl Vogel  wrote:
> On Wed, Dec 06, 2023 at 06:04:36AM +0100, to...@tuxteam.de wrote:
> > On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:
> >   
> > > I have discovered a magic bullet for solving running out of memory
> > >   sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> > > Sadly it looks like I'll need to do this daily,  
> > 
> > It's the browsers eating your memory. That's what they do.  
> 
>   I've had problems with Firefox eating my swap on both Linux and
> FreeBSD. My fix has been to run the swap2ram script below hourly.

TBF FF has stopped eating memory & swap since it updated to 115.5.0 ESR

Re: Isolated Web Co Session crash Firefox-ESR

[Karl Vogel]

On Wed, Dec 06, 2023 at 06:04:36AM +0100, to...@tuxteam.de wrote:
> On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:
> 
> > I have discovered a magic bullet for solving running out of memory
> >   sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> > Sadly it looks like I'll need to do this daily,
> 
> It's the browsers eating your memory. That's what they do.

  I've had problems with Firefox eating my swap on both Linux and FreeBSD.
  My fix has been to run the swap2ram script below hourly.

-- 
Karl Vogel  I don't speak for anyone but myself

Constipational carry.
  --NY Post 28 Nov "Suspect found hiding handgun in his rectum" comment #4

# --
#!/bin/ksh
# /dev/null
case "$?" in
0) ;;
*) die "You must be root to $action this." ;;
esac
}

# Make sure we have permission and a safe tempfile.
needroot
systype=$(uname -s | tr A-Z a-z)

tmp=$(mktemp -q "/tmp/$tag.XX")
case "$?" in
0)  test -f "$tmp" || die "$tmp: tempfile not created" ;;
*)  die "$tmp: mktemp failed" ;;
esac

# Real work starts here.  Check for OS-specific instructions.
case "$systype" in
freebsd)
( swapoff -a && swapon -a ) >> $tmp 2>&1
;;

linux)
mem=$(free  | awk '/Mem:/ {print $4}')
swap=$(free | awk '/Swap:/ {print $3}')

if test "$mem" -lt "$swap"; then
logmsg "not enough RAM to recover swap, nothing done"
else
( swapoff -a && swapon -a ) >> $tmp 2>&1
fi
;;
esac

# Cleanup.
test -s "$tmp" && logfile $tmp
rm $tmp
exit 0

Re: Isolated Web Co Session crash Firefox-ESR

[tomas]

On Wed, Dec 06, 2023 at 02:42:32AM +0800, jeremy ardley wrote:

[...]

> I have discovered a magic bullet for solving running out of memory
> 
> sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> 
> Sadly it looks like I'll need to do this daily,

See /etc/sysctl.conf and /etc/sysctl.conf.d if you want to make such things
persistent.

> simply for using Debian Bookworm with a variety of web browsers

You got that order of things backwards. It's the browsers eating your
memory. That's what they do.

Ad industry always comes up with ways to use up your resources.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 4/12/23 10:26, Max Nikulin wrote:

On 03/12/2023 13:33, jeremy ardley wrote:

On 3/12/23 13:59, Phil Wyett wrote:

What type of content is generally being viewed/used in firefox?


A lot of video and otherwise news and search and GPT4

---

I am curious if this creature may provide a summary on user-space OOM 
killers. I have never tried them, but I expect that they may be more 
intelligent than the kernel-space one. I have seen mentions of the 
following ones: earlyoom, nohang, oomd.


Do you have AI browser extensions that may load huge models in respect 
to memory footprint?


When the system starts to become sluggish, have you looked at the 
firefox 'Task Manager' under tools to see if anything stands out?


Previously I have seen the Isolated Web Co processes maxing CPU and 
the CPU fans starting to roar. Nothing unusual in content at the time 
and if I kill all ESR related processes it quiets down and I can 
resume the closed windows and tabs at much reduced CPU


It is just a process that is responsible for some web pages. 
JavaScript loaded for particular sites may leak. Videos may consume 
RAM as well. I would not rely too much on ability of an application to 
recover after killing of its specific processes. From my point of view 
it is better to restart Firefox in such cases.


Perhaps it is possible to find a particular site that causes issues, 
but you need to inspect system namely when it is becoming sluggish.


Firefox has the about:processes and about:performance tools. They may 
be accessed from the about:about list.


Try to sort top(1) output by memory ("M" key), try df(1) to check 
tmpfs usage for the case that enough temporary video files are stored 
there.


I believed that 32G of RAM is still above that "average" users have, 
so it should be enough. Other suggestions surprised me that 0.5G of 
swap may significantly change anything since it is less than 2% of RAM.



I have discovered a magic bullet for solving running out of memory

sudo sync; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Sadly it looks like I'll need to do this daily, simply for using Debian 
Bookworm with a variety of web browsers

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 4/12/23 10:49, Max Nikulin wrote:

On 04/12/2023 09:39, jeremy ardley wrote:

I think I've found a potential culprit using about:processes

https://openai.com 110% CPU


I would try it in chromium. Some sites relies on optimizations 
implemented in its JavaScript engine.


My observation is that Firefox may be CPU hungry due to "loading" 
animations (CSS and others). Curiously it may happen namely when JS is 
disabled since otherwise animated placeholders are replaced by 
dynamically loaded content that is still.


I have also been monitoring global memory use. The last entry below 
is after I closed the openai tab


I have not used atop, but a colleague recommended it. This tool may 
write logs.




I installed atop and moved the openai page to Google Chrome.

Free memory reported by atop hovers around 10G and doesn't seem to vary 
much over the past day.


I put a query into gpt4

Can Chrony serve as LAN's master?

Chrome CPU varied between 35% and 65% for the duration of the query of 
about 15 to 20 seconds. This is surprising as I thought openai GPT was 
implemented as an API call with minimal browser involvement.

Re: Isolated Web Co Session crash Firefox-ESR

[Max Nikulin]

On 04/12/2023 09:39, jeremy ardley wrote:

I think I've found a potential culprit using about:processes

https://openai.com 110% CPU


I would try it in chromium. Some sites relies on optimizations 
implemented in its JavaScript engine.


My observation is that Firefox may be CPU hungry due to "loading" 
animations (CSS and others). Curiously it may happen namely when JS is 
disabled since otherwise animated placeholders are replaced by 
dynamically loaded content that is still.


I have also been monitoring global memory use. The last entry below is 
after I closed the openai tab


I have not used atop, but a colleague recommended it. This tool may 
write logs.

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 4/12/23 10:26, Max Nikulin wrote:
 > I am curious if this creature may provide a summary on user-space OOM 
> killers. I have never tried them, but I expect that they may be more 
> intelligent than the kernel-space one. I have seen mentions of the > 
following ones: earlyoom, nohang, oomd.


I think I've found a potential culprit using about:processes

https://openai.com 110% CPU

(That's GPT4)

Firefox at this time is running around 1GB memory

The super high CPU for openai is certainly a whole bunch of javascript. 
I closed that tab and the CPU load dropped to normal. Reloading the 
openai website and CPU oscillated between 1% and 20% till it settled 
around 1%


I have also been monitoring global memory use. The last entry below is 
after I closed the openai tab


root@client:~# date; free -m
Mon 04 Dec 2023 09:14:29 AWST
   total    used    free  shared buff/cache   
available

Mem:   32023   12400   10521 426 10136   19622
Swap:    976   8 968
root@client:~# date; free -m
Mon 04 Dec 2023 10:04:56 AWST
   total    used    free  shared buff/cache   
available

Mem:   32023   12913    9959 437 10197   19110
Swap:    976   8 968
root@client:~# date; free -m
Mon 04 Dec 2023 10:28:19 AWST
   total    used    free  shared buff/cache   
available

Mem:   32023   13113    9732 419 10206   18910
Swap:    976   8 968
root@client:~# date; free -m
Mon 04 Dec 2023 10:32:58 AWST
   total    used    free  shared buff/cache   
available

Mem:   32023   12545   10297 428 10217   19478
Swap:    976   8 968

This does not explain the OOM problem, but it seems memory is slowly 
being consumed at a rate where in 24 hours I'll start seeing problems again.

Re: Isolated Web Co Session crash Firefox-ESR

[Max Nikulin]

On 03/12/2023 13:33, jeremy ardley wrote:

On 3/12/23 13:59, Phil Wyett wrote:

What type of content is generally being viewed/used in firefox?


A lot of video and otherwise news and search and GPT4

---

I am curious if this creature may provide a summary on user-space OOM 
killers. I have never tried them, but I expect that they may be more 
intelligent than the kernel-space one. I have seen mentions of the 
following ones: earlyoom, nohang, oomd.


Do you have AI browser extensions that may load huge models in respect 
to memory footprint?


When the system starts to become sluggish, have you looked at the 
firefox 'Task Manager' under tools to see if anything stands out?


Previously I have seen the Isolated Web Co processes maxing CPU and the 
CPU fans starting to roar. Nothing unusual in content at the time and if 
I kill all ESR related processes it quiets down and I can resume the 
closed windows and tabs at much reduced CPU


It is just a process that is responsible for some web pages. JavaScript 
loaded for particular sites may leak. Videos may consume RAM as well. I 
would not rely too much on ability of an application to recover after 
killing of its specific processes. From my point of view it is better to 
restart Firefox in such cases.


Perhaps it is possible to find a particular site that causes issues, but 
you need to inspect system namely when it is becoming sluggish.


Firefox has the about:processes and about:performance tools. They may be 
accessed from the about:about list.


Try to sort top(1) output by memory ("M" key), try df(1) to check tmpfs 
usage for the case that enough temporary video files are stored there.


I believed that 32G of RAM is still above that "average" users have, so 
it should be enough. Other suggestions surprised me that 0.5G of swap 
may significantly change anything since it is less than 2% of RAM.

Re: Isolated Web Co Session crash Firefox-ESR

[Tom Dial]

On 12/3/23 01:00, jeremy ardley wrote:

On 3/12/23 15:37, Phil Wyett wrote:

Not to regurgitating info here, I will add a link below that will instruct how 
to adjust or disable oom-killer in a sensible manner if you wish to experiment 
(your choice and being cautious :-)) if it is in fact the oom-killer algorithm 
that is the main cause of your issue.



The top output provided earlier seems to show nearly a gigabyte of swap, a tiny 
part of it used. You are right, though, that adding swap will not improve 
matters for long.

A small amount of swap probably is a good idea to take care of occasional 
memory overcommitment. But on an interactive system, swap thrashing that may 
happen with a (or several) greedy enough processes will kill performance for 
everything that matters, and if one or more of them is leaking memory, adding 
swap (or even more memory) will only delay the collapse.

As a reference point Isolated Web Co is an occasional annoyance here on 
machines with well over 64G memory. I kill it without mercy when it appears to 
be causing swap.

Regards,
Tom Dial




The issue is not so much Isolated Web Co being terminated, but my entire Mate 
session being terminated.

I wouldn't have too much problem if OOM-killer hit Firefox. I have done it 
myself when things got slow.

However, I can't see any valid reason for the Mate session to be assassinated? 
Or at least be inevitable collateral damage.

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 4/12/23 06:08, Michael Kjörling wrote:
The reason for the system slowing down seems to me to likely be that 
once the system comes under memory pressure (quite possibly due to an 
increase in anonymous pages), it must evict something, and only 
non-anonymous (that is, backed) pages can be evicted safely. So most 
likely the allocator starts evicting program code, because that can be 
read back from storage later, or other forms of cache, in order to 
keep room for the anonymous pages which it cannot evict. The next time 
that code is needed, it must go all the way to the (horribly slow by 
comparison) storage, instead of originally just writing out to swap 
some anonymous pages which haven't been used in comparatively forever, 
like a tmpfs that someone mentioned, or data for inactive web browser 
tabs or documents you aren't doing anything active with.



It turns out I actually do have a modest swap though I don't recall 
enabling it. It doesn't seem to be used anway.


Given  that, the system after 24 hours of typical use is nowhere near 
using up most of the memory.


I expect that the web browsers keep an eye on available memory and do 
most of their memory management/caching  in a 'fixed' allocation as well 
as the memory marked buff/cache


Here is the status just now

root@client:~# free -m
   totalusedfree  shared  buff/cache   available
Mem:   320239654   14053 3369261   22369
Swap:976   8 968

Re: Isolated Web Co Session crash Firefox-ESR

[Michael Kjörling]

On 3 Dec 2023 14:33 +0800, from jeremy.ard...@gmail.com (jeremy ardley):
>> You have swap and it is enabled?
> 
> No Swap. I prefer not on SSD

Why not?

You are definitely putting the VM allocator in a much more difficult
spot than necessary by not providing any swap space.

If I read what you provided in a different message in this thread
correctly, over half of your RAM at that particular time was being
used for anonymous pages; that is, data which has no backing on other
storage, and therefore cannot be evicted from virtual memory. Combine
this with the fact that you have no swap, and all that data _must_ be
kept in RAM because that's all there is. Combine _that_ with running
several rather memory-hungry processes (several web browsers plus
LibreOffice) _and_ the Linux default of allowing memory
overcommitting, and I'm not all that surprised that you're apparently
hitting the OOM killer from time to time.

The reason for the system slowing down seems to me to likely be that
once the system comes under memory pressure (quite possibly due to an
increase in anonymous pages), it must evict something, and only
non-anonymous (that is, backed) pages can be evicted safely. So most
likely the allocator starts evicting program code, because that can be
read back from storage later, or other forms of cache, in order to
keep room for the anonymous pages which it cannot evict. The next time
that code is needed, it must go all the way to the (horribly slow by
comparison) storage, instead of originally just writing out to swap
some anonymous pages which haven't been used in comparatively forever,
like a tmpfs that someone mentioned, or data for inactive web browser
tabs or documents you aren't doing anything active with.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Isolated Web Co Session crash Firefox-ESR

[Reco]

Hi.

On Sun, Dec 03, 2023 at 12:58:47PM +0800, jeremy ardley wrote:
> I noticed my Firefox -esr browser becoming progressively more sluggish. Then 
> suddenly I was back to the system login screen
> 
> This is not the first time this has happened although previously when it 
> started getting sluggish I killed all Firefox related process
> 
> System logs show the start of the event.
> 
> 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] Isolated Web 
> Co invoked oom-killer: 
> gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, 
> oom_score_adj=100

Tail of that particular trace always shows top memory consumers at the
very moment oom-killer was invoked.
Skipping that information can and will lead to guessing.


And in this particular case:

> inactive_anon:29781756kB
> anon_thp: 17088512kB

Do you have any relatively large filesystem, such as /tmp, mounted as
tmpfs? Any tmpfs contents are not accounted by free(1) or top(1), but
using large tmpfs with small swap can lead to funny results to say the
least.

Reco

Re: Isolated Web Co Session crash Firefox-ESR

[Jeffrey Walton]

On Sun, Dec 3, 2023 at 6:21 AM jeremy ardley  wrote:
>
> On 3/12/23 13:59, Phil Wyett wrote:
> > Your system RAM total is?
>
> 32G

You might also want to try compressed memory, like zram.

> > You have swap and it is enabled?
>
> No Swap. I prefer not on SSD

In this configuration, you may want to set `vm.overcommit_memory = 2`
since there is no page file. I don't think it will make the OOM go
away, but it will set a policy more in line with what you are doing.
(It may move the OOM from some random program to the browser, since
the browser is grabbing large amounts of memory).

But I would use a swap file, and set `vm.swappiness = 1`. That tells
the OS to do just about everything except use the swap file. I use
this for all my dev boards with SDcards. The swap file is needed
because the dev boards often lack resources, like having 512 MB of
RAM. (In my case, I need to run a C++ compiler, so I have to have a
swap file or accept the Denial of Service and not get my work done).

Jeff

Re: Isolated Web Co Session crash Firefox-ESR

[Phil Wyett]

On Sun, 2023-12-03 at 16:00 +0800, jeremy ardley wrote:
> 
> On 3/12/23 15:37, Phil Wyett wrote:
> > Not to regurgitating info here, I will add a link below that will 
> > instruct how to adjust or disable oom-killer in a sensible manner if 
> > you wish to experiment (your choice and being cautious :-)) if it is 
> > in fact the oom-killer algorithm that is the main cause of your issue.
> 
> 
> The issue is not so much Isolated Web Co being terminated, but my entire 
> Mate session being terminated.
> 
> I wouldn't have too much problem if OOM-killer hit Firefox. I have done 
> it myself when things got slow.
> 
> However, I can't see any valid reason for the Mate session to be 
> assassinated? Or at least be inevitable collateral damage.
> 

Hi,

Not being deeply familiar with the oom-killer heuristics, I could not offer 
reasoning why 'mate' is
killed. These heuristics by default kill the most memory hogging processes in 
theory and the
consequences of this on other processes I cannot comment on.

There is one setting you may wish look at and consider.

Reading:

https://docs.kernel.org/admin-guide/sysctl/vm.html

I see the following:

https://docs.kernel.org/admin-guide/sysctl/vm.html?highlight=laptop#oom-kill-allocating-task

Setting this to '1' may trigger a strategy that does not put 'mate' in the 
firing line as it changes
the target for killing to the process call that triggers the out of memory 
condition. I am sure if
my reading of this setting is wrong, someone will correct.

This would be done of course at your own risk after doing the research yourself.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org



signature.asc
Description: This is a digitally signed message part

Re: Isolated Web Co Session crash Firefox-ESR

[Phil Wyett]

On Sun, 2023-12-03 at 14:59 +0800, jeremy ardley wrote:
> 
> On 3/12/23 14:46, Phil Wyett wrote:
> > The first thing I would do before any other is to enable swap and see 
> > what benefits that brings. I have no production laptop or desktop 
> > (laptop with 32G being daily driver with NVME (root) and an SSD (home) 
> > drive inside) that does not have swap. I have 8G of swap on my laptop 
> > and it does get used by the system, but only in low amounts. Others 
> > may have other strategies here, but this is where I would start.
> 
> 
> I don't think it is actually a lack of memory. What I do see is all the 
> web browsers are up there on CPU along with nvidia-modeset.
> 
> Putting in swap may delay the time things start going awry but the cause 
> won't be lack of memory
> 
> top CPU
> 
> top - 14:55:15 up 44 days, 41 min,  1 user,  load average: 0.19, 0.19, 0.19
> Tasks: 386 total,   1 running, 385 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.6 us,  0.2 sy,  0.0 ni, 99.1 id,  0.1 wa,  0.0 hi, 0.0 si,  
> 0.0 st
> MiB Mem :  32023.4 total,  19201.2 free,   7118.7 used,   6564.6 buff/cache
> MiB Swap:    977.0 total,    968.1 free,  8.9 used.  24904.6 avail Mem
> 
>  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> 3433245 jeremy    20   0 2584752 210788 100352 S   4.3   0.6 0:25.77 
> Isolated Web Co
> 3423627 jeremy    20   0 1140.1g 326428 130228 S   2.6   1.0 6:12.36 chrome
> 3423253 jeremy    20   0   32.9g 387804 299712 S   1.0   1.2 2:25.86 chrome
>  723 root  20   0   0  0  0 S   0.7   0.0 269:07.26 
> nvidia-modeset/kthread_q
> 3432484 jeremy    20   0 3689468 688004 243920 S   0.7   2.1 1:01.72 
> firefox-esr
> 3433214 root  20   0   11880   5348   3196 R   0.7   0.0 0:03.16 top
> 3422887 jeremy    20   0  697716  55924  40800 S   0.3   0.2 0:07.98 
> mate-terminal
> 3423206 jeremy    20   0   32.8g 434756 252740 S   0.3   1.3 1:32.29 chrome
> 3423254 jeremy    20   0   32.4g 129252 101388 S   0.3   0.4 0:28.83 chrome
> 3428534 jeremy    20   0   32.6g 480104 145044 S   0.3   1.5 2:43.60 
> chromium
> 3428658 jeremy    20   0 1134.0g 212384 117084 S   0.3   0.6 7:09.41 
> chromium
>    1 root  20   0  168800  10412   6324 S   0.0   0.0 0:45.56 
> systemd
>    2 root  20   0   0  0  0 S   0.0   0.0 0:01.82 
> kthreadd
>    3 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> rcu_gp
>    4 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> rcu_par_gp
>    5 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> slub_flushwq
>    6 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 netns
>    8 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> kworker/0:0H-events_highpri
> 
> 
> top memory
> 
> top - 14:58:34 up 44 days, 45 min,  1 user,  load average: 0.27, 0.23, 0.20
> Tasks: 384 total,   3 running, 381 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.8 us,  0.4 sy,  0.0 ni, 98.7 id,  0.1 wa,  0.0 hi, 0.1 si,  
> 0.0 st
> MiB Mem :  32023.4 total,  19055.2 free,   7260.6 used,   6570.2 buff/cache
> MiB Swap:    977.0 total,    968.1 free,  8.9 used.  24762.8 avail Mem
> 
>  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> 3422963 jeremy    20   0 4032104 979264 208004 S   0.0   3.0 5:20.33 
> thunderbird
> 3432484 jeremy    20   0 3679780 711916 250108 S   1.3   2.2 1:13.98 
> firefox-esr
> 3428534 jeremy    20   0   32.6g 480364 144980 R   1.7   1.5 2:46.34 
> chromium
> 3423206 jeremy    20   0   32.8g 434600 252740 S   0.0   1.3 1:32.66 chrome
> 3422183 root  20   0   25.0g 419692 139016 S   0.3   1.3 0:47.61 Xorg
> 3423253 jeremy    20   0   32.9g 387540 299712 S   1.3   1.2 2:28.33 chrome
>     1750 jeremy    20   0 1163816 380224   9776 S   0.0   1.2 3:53.92 
> goa-daemon
> 3423627 jeremy    20   0 1140.1g 326700 130228 S   3.6   1.0 6:19.81 chrome
> 3422581 jeremy    20   0 7293420 311912  78012 S   0.3   1.0 0:40.50 
> dropbox
> 3423600 jeremy    20   0 1134.1g 294804 128548 S   0.0   0.9 0:46.53 chrome
> 3428484 jeremy    20   0   32.7g 266044 192084 S   0.3   0.8 0:38.63 
> chromium
>     2320 jeremy    20   0 1752388 244220  12876 S   0.0   0.7 7:20.61 
> evolution-calen
> 3433245 jeremy    20   0 2584752 212408 100480 S   0.0   0.6 0:32.45 
> Isolated Web Co
>     1664 jeremy 9 -11  240828 203652   5716 S   0.0   0.6 7,25 
> pipewire-pulse
> 3433581 jeremy    20   0 296 201664  98504 S   0.7   0.6 0:03.09 
> Isolated Web Co
> 3428658 jeremy    20   0 1134.0g 200140 117084 R   4.3   0.6 7:18.18 
> chromium
> 3432583 jeremy    20   0   18.7g 191500 108380 S   0.3   0.6 0:10.79 
> WebExtensions
> 3433289 jeremy    20   0 2549968 181504  97876 S   0.0   0.6 0:03.47 
> Isolated Web Co
> 3422461 jeremy    20   0 1385296 158252  94932 S   0.0   0.5 0:20.50 
> nextcloud
> 3428536 jeremy    20   0   32.4g 152468 132780 S   0.3   0.5 0:19.69 
> chromium
> 3432350 jeremy    20   0 1134.0g 

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 3/12/23 15:37, Phil Wyett wrote:
Not to regurgitating info here, I will add a link below that will 
instruct how to adjust or disable oom-killer in a sensible manner if 
you wish to experiment (your choice and being cautious :-)) if it is 
in fact the oom-killer algorithm that is the main cause of your issue.



The issue is not so much Isolated Web Co being terminated, but my entire 
Mate session being terminated.


I wouldn't have too much problem if OOM-killer hit Firefox. I have done 
it myself when things got slow.


However, I can't see any valid reason for the Mate session to be 
assassinated? Or at least be inevitable collateral damage.

Re: Isolated Web Co Session crash Firefox-ESR

[David Christensen]

On 12/2/23 20:58, jeremy ardley wrote:
I noticed my Firefox -esr browser becoming progressively more 
sluggish. Then suddenly I was back to the system login screen


This is not the first time this has happened although previously
when it started getting sluggish I killed all Firefox related
process

System logs show the start of the event.

2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] 
Isolated Web Co invoked oom-killer: 
gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), 
order=0, oom_score_adj=100



On 12/2/23 22:33, jeremy ardley wrote:


On 3/12/23 13:59, Phil Wyett wrote:

Your system RAM total is?


32G



You have swap and it is enabled?


No Swap. I prefer not on SSD



What Desktop Environment (DE) are you using - GNOME, KDE etc.?


Mate with multiple panels.


How many apps would you normally be running on the system at once?



3 x web browsers Firefox - multiple windows,  Chrome one window, 
Chromium one window


Intermittently mate terminals and LibreOffice applications



How many extensions have you installed/running in firefox?



Several. All the usual blockers plus bypass paywalls clean and Multi
 Account Containers


How many tabs would you normally have open?



In firefox, perhaps 20 over two windows



What type of content is generally being viewed/used in firefox?



A lot of video and otherwise news and search and GPT4


When the system starts to become sluggish, have you looked at the 
firefox 'Task Manager' under tools to see if anything stands out?



Previously I have seen the Isolated Web Co processes maxing CPU and 
the CPU fans starting to roar. Nothing unusual in content at the

time and if I kill all ESR related processes it quiets down and I
can resume the closed windows and tabs at much reduced CPU

It's obvious the main culprit is Firefox-ESR and the Isolated Web Co
 processes. What triggers it other than elapsed time I have no idea



On 12/2/23 22:59, jeremy ardley wrote:

I don't think it is actually a lack of memory. What I do see is all
the web browsers are up there on CPU along with nvidia-modeset.

Putting in swap may delay the time things start going awry but the
cause won't be lack of memory


I tried running a Debian desktop without swap and encountered the same 
symptom -- crashed desktop and return to login screen.  The solution was 
two-fold:


1.  Provision 1 GB of swap.

2.  Add Xfce panel widgets so that I can see what is going on.


Between the two, I usually have enough time to kill problem apps before 
a crash.



And, more memory would not hurt.


David

Re: Isolated Web Co Session crash Firefox-ESR

[Phil Wyett]

On Sun, 2023-12-03 at 14:59 +0800, jeremy ardley wrote:
> 
> On 3/12/23 14:46, Phil Wyett wrote:
> > The first thing I would do before any other is to enable swap and see 
> > what benefits that brings. I have no production laptop or desktop 
> > (laptop with 32G being daily driver with NVME (root) and an SSD (home) 
> > drive inside) that does not have swap. I have 8G of swap on my laptop 
> > and it does get used by the system, but only in low amounts. Others 
> > may have other strategies here, but this is where I would start.
> 
> 
> I don't think it is actually a lack of memory. What I do see is all the 
> web browsers are up there on CPU along with nvidia-modeset.
> 
> Putting in swap may delay the time things start going awry but the cause 
> won't be lack of memory
> 
> top CPU
> 
> top - 14:55:15 up 44 days, 41 min,  1 user,  load average: 0.19, 0.19, 0.19
> Tasks: 386 total,   1 running, 385 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.6 us,  0.2 sy,  0.0 ni, 99.1 id,  0.1 wa,  0.0 hi, 0.0 si,  
> 0.0 st
> MiB Mem :  32023.4 total,  19201.2 free,   7118.7 used,   6564.6 buff/cache
> MiB Swap:    977.0 total,    968.1 free,  8.9 used.  24904.6 avail Mem
> 
>  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> 3433245 jeremy    20   0 2584752 210788 100352 S   4.3   0.6 0:25.77 
> Isolated Web Co
> 3423627 jeremy    20   0 1140.1g 326428 130228 S   2.6   1.0 6:12.36 chrome
> 3423253 jeremy    20   0   32.9g 387804 299712 S   1.0   1.2 2:25.86 chrome
>  723 root  20   0   0  0  0 S   0.7   0.0 269:07.26 
> nvidia-modeset/kthread_q
> 3432484 jeremy    20   0 3689468 688004 243920 S   0.7   2.1 1:01.72 
> firefox-esr
> 3433214 root  20   0   11880   5348   3196 R   0.7   0.0 0:03.16 top
> 3422887 jeremy    20   0  697716  55924  40800 S   0.3   0.2 0:07.98 
> mate-terminal
> 3423206 jeremy    20   0   32.8g 434756 252740 S   0.3   1.3 1:32.29 chrome
> 3423254 jeremy    20   0   32.4g 129252 101388 S   0.3   0.4 0:28.83 chrome
> 3428534 jeremy    20   0   32.6g 480104 145044 S   0.3   1.5 2:43.60 
> chromium
> 3428658 jeremy    20   0 1134.0g 212384 117084 S   0.3   0.6 7:09.41 
> chromium
>    1 root  20   0  168800  10412   6324 S   0.0   0.0 0:45.56 
> systemd
>    2 root  20   0   0  0  0 S   0.0   0.0 0:01.82 
> kthreadd
>    3 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> rcu_gp
>    4 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> rcu_par_gp
>    5 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> slub_flushwq
>    6 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 netns
>    8 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> kworker/0:0H-events_highpri
> 
> 
> top memory
> 
> top - 14:58:34 up 44 days, 45 min,  1 user,  load average: 0.27, 0.23, 0.20
> Tasks: 384 total,   3 running, 381 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.8 us,  0.4 sy,  0.0 ni, 98.7 id,  0.1 wa,  0.0 hi, 0.1 si,  
> 0.0 st
> MiB Mem :  32023.4 total,  19055.2 free,   7260.6 used,   6570.2 buff/cache
> MiB Swap:    977.0 total,    968.1 free,  8.9 used.  24762.8 avail Mem
> 
>  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> 3422963 jeremy    20   0 4032104 979264 208004 S   0.0   3.0 5:20.33 
> thunderbird
> 3432484 jeremy    20   0 3679780 711916 250108 S   1.3   2.2 1:13.98 
> firefox-esr
> 3428534 jeremy    20   0   32.6g 480364 144980 R   1.7   1.5 2:46.34 
> chromium
> 3423206 jeremy    20   0   32.8g 434600 252740 S   0.0   1.3 1:32.66 chrome
> 3422183 root  20   0   25.0g 419692 139016 S   0.3   1.3 0:47.61 Xorg
> 3423253 jeremy    20   0   32.9g 387540 299712 S   1.3   1.2 2:28.33 chrome
>     1750 jeremy    20   0 1163816 380224   9776 S   0.0   1.2 3:53.92 
> goa-daemon
> 3423627 jeremy    20   0 1140.1g 326700 130228 S   3.6   1.0 6:19.81 chrome
> 3422581 jeremy    20   0 7293420 311912  78012 S   0.3   1.0 0:40.50 
> dropbox
> 3423600 jeremy    20   0 1134.1g 294804 128548 S   0.0   0.9 0:46.53 chrome
> 3428484 jeremy    20   0   32.7g 266044 192084 S   0.3   0.8 0:38.63 
> chromium
>     2320 jeremy    20   0 1752388 244220  12876 S   0.0   0.7 7:20.61 
> evolution-calen
> 3433245 jeremy    20   0 2584752 212408 100480 S   0.0   0.6 0:32.45 
> Isolated Web Co
>     1664 jeremy 9 -11  240828 203652   5716 S   0.0   0.6 7,25 
> pipewire-pulse
> 3433581 jeremy    20   0 296 201664  98504 S   0.7   0.6 0:03.09 
> Isolated Web Co
> 3428658 jeremy    20   0 1134.0g 200140 117084 R   4.3   0.6 7:18.18 
> chromium
> 3432583 jeremy    20   0   18.7g 191500 108380 S   0.3   0.6 0:10.79 
> WebExtensions
> 3433289 jeremy    20   0 2549968 181504  97876 S   0.0   0.6 0:03.47 
> Isolated Web Co
> 3422461 jeremy    20   0 1385296 158252  94932 S   0.0   0.5 0:20.50 
> nextcloud
> 3428536 jeremy    20   0   32.4g 152468 132780 S   0.3   0.5 0:19.69 
> chromium
> 3432350 jeremy    20   0 1134.0g 

Re: Isolated Web Co Session crash Firefox-ESR

[Tom Furie]

jeremy ardley  writes:

> I don't think it is actually a lack of memory. What I do see is all
> the web browsers are up there on CPU along with nvidia-modeset.

What do you consider to be "up there"? 4.3% (your highest CPU usage in
this output) hardly seems to qualify as something to be concerned
about. nvidia-modeset is consuming a whopping 0.7% CPU.

I assume these numbers are while the system is operating normally and
not when it starts to struggle. Why do you think heavy CPU load would
cause the OOM killer to activate? Some precesses just don't appreciate
having no swap available.

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 3/12/23 14:46, Phil Wyett wrote:
The first thing I would do before any other is to enable swap and see 
what benefits that brings. I have no production laptop or desktop 
(laptop with 32G being daily driver with NVME (root) and an SSD (home) 
drive inside) that does not have swap. I have 8G of swap on my laptop 
and it does get used by the system, but only in low amounts. Others 
may have other strategies here, but this is where I would start.



I don't think it is actually a lack of memory. What I do see is all the 
web browsers are up there on CPU along with nvidia-modeset.


Putting in swap may delay the time things start going awry but the cause 
won't be lack of memory


top CPU

top - 14:55:15 up 44 days, 41 min,  1 user,  load average: 0.19, 0.19, 0.19
Tasks: 386 total,   1 running, 385 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.6 us,  0.2 sy,  0.0 ni, 99.1 id,  0.1 wa,  0.0 hi, 0.0 si,  
0.0 st

MiB Mem :  32023.4 total,  19201.2 free,   7118.7 used,   6564.6 buff/cache
MiB Swap:    977.0 total,    968.1 free,  8.9 used.  24904.6 avail Mem

    PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
3433245 jeremy    20   0 2584752 210788 100352 S   4.3   0.6 0:25.77 
Isolated Web Co

3423627 jeremy    20   0 1140.1g 326428 130228 S   2.6   1.0 6:12.36 chrome
3423253 jeremy    20   0   32.9g 387804 299712 S   1.0   1.2 2:25.86 chrome
    723 root  20   0   0  0  0 S   0.7   0.0 269:07.26 
nvidia-modeset/kthread_q
3432484 jeremy    20   0 3689468 688004 243920 S   0.7   2.1 1:01.72 
firefox-esr

3433214 root  20   0   11880   5348   3196 R   0.7   0.0 0:03.16 top
3422887 jeremy    20   0  697716  55924  40800 S   0.3   0.2 0:07.98 
mate-terminal

3423206 jeremy    20   0   32.8g 434756 252740 S   0.3   1.3 1:32.29 chrome
3423254 jeremy    20   0   32.4g 129252 101388 S   0.3   0.4 0:28.83 chrome
3428534 jeremy    20   0   32.6g 480104 145044 S   0.3   1.5 2:43.60 
chromium
3428658 jeremy    20   0 1134.0g 212384 117084 S   0.3   0.6 7:09.41 
chromium
  1 root  20   0  168800  10412   6324 S   0.0   0.0 0:45.56 
systemd
  2 root  20   0   0  0  0 S   0.0   0.0 0:01.82 
kthreadd
  3 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
rcu_gp
  4 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
rcu_par_gp
  5 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
slub_flushwq

  6 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 netns
  8 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
kworker/0:0H-events_highpri



top memory

top - 14:58:34 up 44 days, 45 min,  1 user,  load average: 0.27, 0.23, 0.20
Tasks: 384 total,   3 running, 381 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.8 us,  0.4 sy,  0.0 ni, 98.7 id,  0.1 wa,  0.0 hi, 0.1 si,  
0.0 st

MiB Mem :  32023.4 total,  19055.2 free,   7260.6 used,   6570.2 buff/cache
MiB Swap:    977.0 total,    968.1 free,  8.9 used.  24762.8 avail Mem

    PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
3422963 jeremy    20   0 4032104 979264 208004 S   0.0   3.0 5:20.33 
thunderbird
3432484 jeremy    20   0 3679780 711916 250108 S   1.3   2.2 1:13.98 
firefox-esr
3428534 jeremy    20   0   32.6g 480364 144980 R   1.7   1.5 2:46.34 
chromium

3423206 jeremy    20   0   32.8g 434600 252740 S   0.0   1.3 1:32.66 chrome
3422183 root  20   0   25.0g 419692 139016 S   0.3   1.3 0:47.61 Xorg
3423253 jeremy    20   0   32.9g 387540 299712 S   1.3   1.2 2:28.33 chrome
   1750 jeremy    20   0 1163816 380224   9776 S   0.0   1.2 3:53.92 
goa-daemon

3423627 jeremy    20   0 1140.1g 326700 130228 S   3.6   1.0 6:19.81 chrome
3422581 jeremy    20   0 7293420 311912  78012 S   0.3   1.0 0:40.50 
dropbox

3423600 jeremy    20   0 1134.1g 294804 128548 S   0.0   0.9 0:46.53 chrome
3428484 jeremy    20   0   32.7g 266044 192084 S   0.3   0.8 0:38.63 
chromium
   2320 jeremy    20   0 1752388 244220  12876 S   0.0   0.7 7:20.61 
evolution-calen
3433245 jeremy    20   0 2584752 212408 100480 S   0.0   0.6 0:32.45 
Isolated Web Co
   1664 jeremy 9 -11  240828 203652   5716 S   0.0   0.6 7,25 
pipewire-pulse
3433581 jeremy    20   0 296 201664  98504 S   0.7   0.6 0:03.09 
Isolated Web Co
3428658 jeremy    20   0 1134.0g 200140 117084 R   4.3   0.6 7:18.18 
chromium
3432583 jeremy    20   0   18.7g 191500 108380 S   0.3   0.6 0:10.79 
WebExtensions
3433289 jeremy    20   0 2549968 181504  97876 S   0.0   0.6 0:03.47 
Isolated Web Co
3422461 jeremy    20   0 1385296 158252  94932 S   0.0   0.5 0:20.50 
nextcloud
3428536 jeremy    20   0   32.4g 152468 132780 S   0.3   0.5 0:19.69 
chromium

3432350 jeremy    20   0 1134.0g 143620 103132 S   0.0   0.4 0:01.76 chrome
3423380 jeremy    20   0 1132.0g 141860 100880 S   0.0   0.4 0:03.64 chrome
3423715 jeremy    20   0 1132.0g 137276 102264 S   0.0   0.4 0:02.83 chrome
3432598 jeremy    20   0 2477752 135292  98484 S   0.0   0.4 0:02.16 

Re: Isolated Web Co Session crash Firefox-ESR

[Phil Wyett]

On Sun, 2023-12-03 at 14:33 +0800, jeremy ardley wrote:
> 
> On 3/12/23 13:59, Phil Wyett wrote:
> > Your system RAM total is?
> 
> 32G
> 
> 
> > You have swap and it is enabled?
> 
> No Swap. I prefer not on SSD
> 
> 
> 

Hi,

The first thing I would do before any other is to enable swap and see what 
benefits that brings.

I have no production laptop or desktop (laptop with 32G being daily driver with 
NVME (root) and an
SSD (home) drive inside) that does not have swap. I have 8G of swap on my 
laptop and it does get
used by the system, but only in low amounts.

Others may have other strategies here, but this is where I would start.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org



signature.asc
Description: This is a digitally signed message part

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 3/12/23 13:59, Phil Wyett wrote:

Your system RAM total is?


32G



You have swap and it is enabled?


No Swap. I prefer not on SSD



What Desktop Environment (DE) are you using - GNOME, KDE etc.?


Mate with multiple panels.

How many apps would you normally be running on the system at once? 



3 x web browsers Firefox - multiple windows,  Chrome one window, 
Chromium one window


Intermittently mate terminals and LibreOffice applications



How many extensions have you installed/running in firefox?



Several. All the usual blockers plus bypass paywalls clean and Multi 
Account Containers



How many tabs would you normally have open?



In firefox, perhaps 20 over two windows



What type of content is generally being viewed/used in firefox?



A lot of video and otherwise news and search and GPT4


When the system starts to become sluggish, have you looked at the 
firefox 'Task Manager' under tools to see if anything stands out?



Previously I have seen the Isolated Web Co processes maxing CPU and the 
CPU fans starting to roar. Nothing unusual in content at the time and if 
I kill all ESR related processes it quiets down and I can resume the 
closed windows and tabs at much reduced CPU


It's obvious the main culprit is Firefox-ESR and the Isolated Web Co 
processes. What triggers it other than elapsed time I have no idea

Re: Isolated Web Co Session crash Firefox-ESR

[Phil Wyett]

On Sun, 2023-12-03 at 12:58 +0800, jeremy ardley wrote:
> I noticed my Firefox -esr browser becoming progressively more sluggish. 
> Then suddenly I was back to the system login screen
> 
> This is not the first time this has happened although previously when it 
> started getting sluggish I killed all Firefox related process
> 
> System logs show the start of the event.
> 
> 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] 
> Isolated Web Co invoked oom-killer: 
> gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, 
> oom_score_adj=100
> 2023-12-03T11:35:03.335962+08:00 client kernel: [3792101.257078] CPU: 8 
> PID: 3410924 Comm: Isolated Web Co Tainted: P OE  6.1.0-13-amd64 #1  
> Debian 6.1.55-1
> 2023-12-03T11:35:03.335964+08:00 client kernel: [3792101.257081] 
> Hardware name: System manufacturer System Product Name/PRIME B450M-A, 
> BIOS 0219 06/08/2018
> 2023-12-03T11:35:03.335965+08:00 client kernel: [3792101.257082] Call Trace:
> 2023-12-03T11:35:03.335966+08:00 client kernel: [3792101.257085] 
> 2023-12-03T11:35:03.335967+08:00 client kernel: [3792101.257088] 
> dump_stack_lvl+0x44/0x5c
> 2023-12-03T11:35:03.335968+08:00 client kernel: [3792101.257094] 
> dump_header+0x4a/0x211
> 2023-12-03T11:35:03.335978+08:00 client kernel: [3792101.257097] 
> oom_kill_process.cold+0xb/0x10
> 2023-12-03T11:35:03.335979+08:00 client kernel: [3792101.257100] 
> out_of_memory+0x1fd/0x4c0
> 2023-12-03T11:35:03.335980+08:00 client kernel: [3792101.257104] 
> __alloc_pages_slowpath.constprop.0+0xc73/0xdc0
> 2023-12-03T11:35:03.335981+08:00 client kernel: [3792101.257108] 
> __alloc_pages+0x305/0x330
> 2023-12-03T11:35:03.335982+08:00 client kernel: [3792101.257111] 
> __folio_alloc+0x17/0x50
> 2023-12-03T11:35:03.335983+08:00 client kernel: [3792101.257113] ? 
> policy_node+0x51/0x70
> 2023-12-03T11:35:03.335984+08:00 client kernel: [3792101.257116] 
> vma_alloc_folio+0x9c/0x370
> 2023-12-03T11:35:03.335984+08:00 client kernel: [3792101.257119] 
> __handle_mm_fault+0x92f/0xfa0
> 2023-12-03T11:35:03.335985+08:00 client kernel: [3792101.257123] 
> handle_mm_fault+0xdb/0x2d0
> 2023-12-03T11:35:03.335986+08:00 client kernel: [3792101.257126] 
> do_user_addr_fault+0x19c/0x570
> 2023-12-03T11:35:03.335986+08:00 client kernel: [3792101.257129] 
> exc_page_fault+0x70/0x170
> 2023-12-03T11:35:03.335987+08:00 client kernel: [3792101.257132] 
> asm_exc_page_fault+0x22/0x30
> 2023-12-03T11:35:03.335987+08:00 client kernel: [3792101.257136] RIP: 
> 0033:0x7fcb86b0dd3a
> 2023-12-03T11:35:03.335988+08:00 client kernel: [3792101.257139] Code: 
> 48 89 fb 48 83 ec 18 e8 b4 de ff ff 48 85 c0 74 42 48 89 c5 48 8b 43 48 
> 48 3b 43 50 0f 84 5e 01 00 00 48 8d 50 08 48 89 53 48 <48> 89 28 4c 8b 
> bb 88 00 00 00 4d 85 ff 74 16 41 80 7f 19 00 4d 8b
> 2023-12-03T11:35:03.335989+08:00 client kernel: [3792101.257140] RSP: 
> 002b:7ffc85877cd0 EFLAGS: 00010283
> 2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257142] RAX: 
> 7fcb0a3b7000 RBX: 7fcb45f33000 RCX: 05937a1b
> 2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257144] RDX: 
> 7fcb0a3b7008 RSI: 7fcb85941410 RDI: 
> 2023-12-03T11:35:03.335991+08:00 client kernel: [3792101.257145] RBP: 
> 7fcb3ebaea08 R08: 7fcb3ebaea08 R09: 008fc63b
> 2023-12-03T11:35:03.335992+08:00 client kernel: [3792101.257146] R10: 
>  R11: 0008 R12: 0558afa25450
> 2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257147] R13: 
> 7ffc85877d20 R14:  R15: 148e1958de08
> 2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257150] 
> 2023-12-03T11:35:03.335994+08:00 client kernel: [3792101.257151] Mem-Info:
> 2023-12-03T11:35:03.335994+08:00 client kernel: [3792101.257152] 
> active_anon:202973 inactive_anon:7445439 isolated_anon:0
> 2023-12-03T11:35:03.335998+08:00 client kernel: [3792101.257152] 
> active_file:816 inactive_file:3360 isolated_file:0
> 2023-12-03T11:35:03.335999+08:00 client kernel: [3792101.257152] 
> unevictable:2092 dirty:0 writeback:0
> 2023-12-03T11:35:03.336000+08:00 client kernel: [3792101.257152] 
> slab_reclaimable:180435 slab_unreclaimable:80961
> 2023-12-03T11:35:03.336001+08:00 client kernel: [3792101.257152] 
> mapped:215565 shmem:310212 pagetables:40361
> 2023-12-03T11:35:03.336001+08:00 client kernel: [3792101.257152] 
> sec_pagetables:0 bounce:0
> 2023-12-03T11:35:03.336002+08:00 client kernel: [3792101.257152] 
> kernel_misc_reclaimable:0
> 2023-12-03T11:35:03.336004+08:00 client kernel: [3792101.257152] 
> free:81539 free_pcp:87 free_cma:0
> 2023-12-03T11:35:03.336004+08:00 client kernel: [3792101.257156] Node 0 
> active_anon:811892kB inactive_anon:29781756kB active_file:3264kB 
> inactive_file:13440kB unevictable:8368kB isolated(anon):0kB 
> isolated(file):0kB mapped:862260kB dirty:0kB writeback:0kB 
> shmem:1240848kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 17088512kB 
> writeback_tmp:0kB 

Re: Isolated Web Co Session crash Firefox-ESR

[Tom Furie]

jeremy ardley  writes:

> I noticed my Firefox -esr browser becoming progressively more
> sluggish. Then suddenly I was back to the system login screen
>
> This is not the first time this has happened although previously when
> it started getting sluggish I killed all Firefox related process
>
> System logs show the start of the event.
>
> 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070]
> Isolated Web Co invoked oom-killer:
  ^^

You're out of memory, the system started killing processes to keep
itself alive. It tends not be particularly "smart" about what to kill.

Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

I noticed my Firefox -esr browser becoming progressively more sluggish. 
Then suddenly I was back to the system login screen


This is not the first time this has happened although previously when it 
started getting sluggish I killed all Firefox related process


System logs show the start of the event.

2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] 
Isolated Web Co invoked oom-killer: 
gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, 
oom_score_adj=100
2023-12-03T11:35:03.335962+08:00 client kernel: [3792101.257078] CPU: 8 
PID: 3410924 Comm: Isolated Web Co Tainted: P OE  6.1.0-13-amd64 #1  
Debian 6.1.55-1
2023-12-03T11:35:03.335964+08:00 client kernel: [3792101.257081] 
Hardware name: System manufacturer System Product Name/PRIME B450M-A, 
BIOS 0219 06/08/2018

2023-12-03T11:35:03.335965+08:00 client kernel: [3792101.257082] Call Trace:
2023-12-03T11:35:03.335966+08:00 client kernel: [3792101.257085] 
2023-12-03T11:35:03.335967+08:00 client kernel: [3792101.257088] 
dump_stack_lvl+0x44/0x5c
2023-12-03T11:35:03.335968+08:00 client kernel: [3792101.257094] 
dump_header+0x4a/0x211
2023-12-03T11:35:03.335978+08:00 client kernel: [3792101.257097] 
oom_kill_process.cold+0xb/0x10
2023-12-03T11:35:03.335979+08:00 client kernel: [3792101.257100] 
out_of_memory+0x1fd/0x4c0
2023-12-03T11:35:03.335980+08:00 client kernel: [3792101.257104] 
__alloc_pages_slowpath.constprop.0+0xc73/0xdc0
2023-12-03T11:35:03.335981+08:00 client kernel: [3792101.257108] 
__alloc_pages+0x305/0x330
2023-12-03T11:35:03.335982+08:00 client kernel: [3792101.257111] 
__folio_alloc+0x17/0x50
2023-12-03T11:35:03.335983+08:00 client kernel: [3792101.257113] ? 
policy_node+0x51/0x70
2023-12-03T11:35:03.335984+08:00 client kernel: [3792101.257116] 
vma_alloc_folio+0x9c/0x370
2023-12-03T11:35:03.335984+08:00 client kernel: [3792101.257119] 
__handle_mm_fault+0x92f/0xfa0
2023-12-03T11:35:03.335985+08:00 client kernel: [3792101.257123] 
handle_mm_fault+0xdb/0x2d0
2023-12-03T11:35:03.335986+08:00 client kernel: [3792101.257126] 
do_user_addr_fault+0x19c/0x570
2023-12-03T11:35:03.335986+08:00 client kernel: [3792101.257129] 
exc_page_fault+0x70/0x170
2023-12-03T11:35:03.335987+08:00 client kernel: [3792101.257132] 
asm_exc_page_fault+0x22/0x30
2023-12-03T11:35:03.335987+08:00 client kernel: [3792101.257136] RIP: 
0033:0x7fcb86b0dd3a
2023-12-03T11:35:03.335988+08:00 client kernel: [3792101.257139] Code: 
48 89 fb 48 83 ec 18 e8 b4 de ff ff 48 85 c0 74 42 48 89 c5 48 8b 43 48 
48 3b 43 50 0f 84 5e 01 00 00 48 8d 50 08 48 89 53 48 <48> 89 28 4c 8b 
bb 88 00 00 00 4d 85 ff 74 16 41 80 7f 19 00 4d 8b
2023-12-03T11:35:03.335989+08:00 client kernel: [3792101.257140] RSP: 
002b:7ffc85877cd0 EFLAGS: 00010283
2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257142] RAX: 
7fcb0a3b7000 RBX: 7fcb45f33000 RCX: 05937a1b
2023-12-03T11:35:03.335990+08:00 client kernel: [3792101.257144] RDX: 
7fcb0a3b7008 RSI: 7fcb85941410 RDI: 
2023-12-03T11:35:03.335991+08:00 client kernel: [3792101.257145] RBP: 
7fcb3ebaea08 R08: 7fcb3ebaea08 R09: 008fc63b
2023-12-03T11:35:03.335992+08:00 client kernel: [3792101.257146] R10: 
 R11: 0008 R12: 0558afa25450
2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257147] R13: 
7ffc85877d20 R14:  R15: 148e1958de08

2023-12-03T11:35:03.335993+08:00 client kernel: [3792101.257150] 
2023-12-03T11:35:03.335994+08:00 client kernel: [3792101.257151] Mem-Info:
2023-12-03T11:35:03.335994+08:00 client kernel: [3792101.257152] 
active_anon:202973 inactive_anon:7445439 isolated_anon:0
2023-12-03T11:35:03.335998+08:00 client kernel: [3792101.257152] 
active_file:816 inactive_file:3360 isolated_file:0
2023-12-03T11:35:03.335999+08:00 client kernel: [3792101.257152] 
unevictable:2092 dirty:0 writeback:0
2023-12-03T11:35:03.336000+08:00 client kernel: [3792101.257152] 
slab_reclaimable:180435 slab_unreclaimable:80961
2023-12-03T11:35:03.336001+08:00 client kernel: [3792101.257152] 
mapped:215565 shmem:310212 pagetables:40361
2023-12-03T11:35:03.336001+08:00 client kernel: [3792101.257152] 
sec_pagetables:0 bounce:0
2023-12-03T11:35:03.336002+08:00 client kernel: [3792101.257152] 
kernel_misc_reclaimable:0
2023-12-03T11:35:03.336004+08:00 client kernel: [3792101.257152] 
free:81539 free_pcp:87 free_cma:0
2023-12-03T11:35:03.336004+08:00 client kernel: [3792101.257156] Node 0 
active_anon:811892kB inactive_anon:29781756kB active_file:3264kB 
inactive_file:13440kB unevictable:8368kB isolated(anon):0kB 
isolated(file):0kB mapped:862260kB dirty:0kB writeback:0kB 
shmem:1240848kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 17088512kB 
writeback_tmp:0kB kernel_stack:39

Re: unexplained crash on Ubuntu 20.04 system

[Michael Kjörling]

On 18 Nov 2023 01:36 -0500, from noloa...@gmail.com (Jeffrey Walton):
> On Fri, Nov 17, 2023 at 7:11 PM Adam Weremczuk  
> wrote:
>> Yesterday SSH on my desktop PC running Ubuntu 20.04 became unresponsive.
> 
> [...] You should probably ask on the ubuntu-users list. [...]

I agree. While Ubuntu is based on Debian, it's far enough removed
these days that the differences can have a rather large impact,
especially for someone who doesn't have hands-on access to the system
and who is trying to determine the cause of a problem; so it makes
sense to start out somewhere with people most familiar with the
distribution you're having issues with. In this case that's Ubuntu;
the argument would be the same were it, say, Mint, Slackware, SuSE or
RHEL.

Which is not to say that whatever the problem is couldn't _also_ have
happened on a Debian system. Just that it didn't in this particular
instance.

If/when you do find out what happened, do however consider posting a
summary here.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: unexplained crash

[Jeffrey Walton]

On Fri, Nov 17, 2023 at 7:11 PM Adam Weremczuk  wrote:
>
> Yesterday SSH on my desktop PC running Ubuntu 20.04 became unresponsive.
>
> The machine was responding to ping and "telnet 22" was briefly
> connecting before connection closed.
>
> The graphical login prompt was visible, but when I tried to log in, it
> threw me to the text console. No login prompt on any virtual consoles
> and Ctrl-Alt-Del did nothing.
>
> There is no information logged in wtmp, kern.log and dmesg. Nothing
> interesting in auth.log
>
> The last 40 lines from syslog look as below:
>
> Nov 16 17:04:23 ubu20 systemd[1]: session-5089.scope: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1]: Stopping User Manager for UID 0...
> Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Main User Target.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Basic System.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Paths.
> Nov 16 17:04:33 ubu20 systemd[1259208]: ubuntu-report.path: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped Pending report trigger
> for Ubuntu Report.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Sockets.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Timers.
> Nov 16 17:04:33 ubu20 systemd[1259208]: dbus.socket: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Closed D-Bus User Message Bus
> Socket.
> Nov 16 17:04:33 ubu20 systemd[1259208]: dirmngr.socket: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG network certificate
> management daemon.
> Nov 16 17:04:33 ubu20 systemd[1259208]: gpg-agent-browser.socket: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG cryptographic agent
> and passphrase cache (access for web browsers).
> Nov 16 17:04:33 ubu20 systemd[1259208]: gpg-agent-extra.socket: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG cryptographic agent
> and passphrase cache (restricted).
> Nov 16 17:04:33 ubu20 systemd[1259208]: gpg-agent-ssh.socket: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG cryptographic agent
> (ssh-agent emulation).
> Nov 16 17:04:33 ubu20 systemd[1259208]: gpg-agent.socket: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG cryptographic agent
> and passphrase cache.
> Nov 16 17:04:33 ubu20 systemd[1259208]: pk-debconf-helper.socket: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Closed debconf communication socket.
> Nov 16 17:04:33 ubu20 systemd[1259208]: snapd.session-agent.socket:
> Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Closed REST API socket for snapd
> user session agent.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Reached target Shutdown.
> Nov 16 17:04:33 ubu20 systemd[1259208]: systemd-exit.service: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Finished Exit the Session.
> Nov 16 17:04:33 ubu20 systemd[1259208]: Reached target Exit the Session.
> Nov 16 17:04:33 ubu20 systemd[1]: user@0.service: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1]: Stopped User Manager for UID 0.
> Nov 16 17:04:33 ubu20 systemd[1]: Stopping User Runtime Directory
> /run/user/0...
> Nov 16 17:04:33 ubu20 systemd[2567]: run-user-0.mount: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1294]: run-user-0.mount: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1]: run-user-0.mount: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1]: user-runtime-dir@0.service: Succeeded.
> Nov 16 17:04:33 ubu20 systemd[1]: Stopped User Runtime Directory
> /run/user/0.
> Nov 16 17:04:33 ubu20 systemd[1]: Removed slice User Slice of UID 0.
>
> Does anybody have an idea what could have happened?

Whenever I see Snap, I get suspicious. You should probably ask on the
ubuntu-users list. The list has a person that answers Snap questions.
.

You should also show the SSH connection log for the client and server.
I think that's 'ssh -vvv' for the client, and 'journalctl -u ssh' for
the server.

Jeff

Re: unexplained crash

[David Wright]

On Sat 18 Nov 2023 at 07:06:49 (+0100), to...@tuxteam.de wrote:
> On Fri, Nov 17, 2023 at 07:17:08PM +, Adam Weremczuk wrote:
> > Yesterday SSH on my desktop PC running Ubuntu 20.04 became unresponsive.
> > 
> > The machine was responding to ping and "telnet 22" was briefly connecting
> > before connection closed.
> 
> Guessing from the context, you tried to ssh into your desktop and
> something went wrong ("became unresponsive"). What /exactly/ did
> your ssh client say?
> 
> I'd guess along the lines of "connection closed by foreign host",
> which would mean the ssh daemon is listening on the other side
> but closes the connection shortly after establishing it.
> 
> You can gather a bit more of info by adding one (or more) -v options
> to your ssh client invocation.
> 
> > The graphical login prompt was visible, but when I tried to log in, it threw
> > me to the text console. No login prompt on any virtual consoles and
> > Ctrl-Alt-Del did nothing.



> > 
> > There is no information logged in wtmp, kern.log and dmesg. Nothing
> > interesting in auth.log
> > 
> > The last 40 lines from syslog look as below:
> 
> [...]
> 
> I'm not a systemd expert by a long shot, so I'll have to leave
> this to others, but my first impression of the log is that of
> a system shutting down (which is kind of strange).

They did say they tried Ctrl-Alt-Del. That shuts down (and reboots)
on my systems.

Cheers,
David.

Re: unexplained crash

[tomas]

On Fri, Nov 17, 2023 at 07:17:08PM +, Adam Weremczuk wrote:
> Hello,
> 
> Yesterday SSH on my desktop PC running Ubuntu 20.04 became unresponsive.
> 
> The machine was responding to ping and "telnet 22" was briefly connecting
> before connection closed.

Guessing from the context, you tried to ssh into your desktop and
something went wrong ("became unresponsive"). What /exactly/ did
your ssh client say?

I'd guess along the lines of "connection closed by foreign host",
which would mean the ssh daemon is listening on the other side
but closes the connection shortly after establishing it.

You can gather a bit more of info by adding one (or more) -v options
to your ssh client invocation.

> The graphical login prompt was visible, but when I tried to log in, it threw
> me to the text console. No login prompt on any virtual consoles and
> Ctrl-Alt-Del did nothing.
> 
> There is no information logged in wtmp, kern.log and dmesg. Nothing
> interesting in auth.log
> 
> The last 40 lines from syslog look as below:

[...]

I'm not a systemd expert by a long shot, so I'll have to leave
this to others, but my first impression of the log is that of
a system shutting down (which is kind of strange).

Perhaps you've had a file system (or underlying drive media)
error and your root FS is mounted read only?

I understand that you managed to log into a console: what does
"mount" say?

Cheers
-- 
t


signature.asc
Description: PGP signature

unexplained crash

[Adam Weremczuk]

Hello,

Yesterday SSH on my desktop PC running Ubuntu 20.04 became unresponsive.

The machine was responding to ping and "telnet 22" was briefly 
connecting before connection closed.


The graphical login prompt was visible, but when I tried to log in, it 
threw me to the text console. No login prompt on any virtual consoles 
and Ctrl-Alt-Del did nothing.


There is no information logged in wtmp, kern.log and dmesg. Nothing 
interesting in auth.log


The last 40 lines from syslog look as below:

Nov 16 17:04:23 ubu20 systemd[1]: session-5089.scope: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1]: Stopping User Manager for UID 0...
Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Main User Target.
Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Basic System.
Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Paths.
Nov 16 17:04:33 ubu20 systemd[1259208]: ubuntu-report.path: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped Pending report trigger 
for Ubuntu Report.

Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Sockets.
Nov 16 17:04:33 ubu20 systemd[1259208]: Stopped target Timers.
Nov 16 17:04:33 ubu20 systemd[1259208]: dbus.socket: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Closed D-Bus User Message Bus 
Socket.

Nov 16 17:04:33 ubu20 systemd[1259208]: dirmngr.socket: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG network certificate 
management daemon.

Nov 16 17:04:33 ubu20 systemd[1259208]: gpg-agent-browser.socket: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG cryptographic agent 
and passphrase cache (access for web browsers).

Nov 16 17:04:33 ubu20 systemd[1259208]: gpg-agent-extra.socket: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG cryptographic agent 
and passphrase cache (restricted).

Nov 16 17:04:33 ubu20 systemd[1259208]: gpg-agent-ssh.socket: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG cryptographic agent 
(ssh-agent emulation).

Nov 16 17:04:33 ubu20 systemd[1259208]: gpg-agent.socket: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Closed GnuPG cryptographic agent 
and passphrase cache.

Nov 16 17:04:33 ubu20 systemd[1259208]: pk-debconf-helper.socket: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Closed debconf communication socket.
Nov 16 17:04:33 ubu20 systemd[1259208]: snapd.session-agent.socket: 
Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Closed REST API socket for snapd 
user session agent.

Nov 16 17:04:33 ubu20 systemd[1259208]: Reached target Shutdown.
Nov 16 17:04:33 ubu20 systemd[1259208]: systemd-exit.service: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1259208]: Finished Exit the Session.
Nov 16 17:04:33 ubu20 systemd[1259208]: Reached target Exit the Session.
Nov 16 17:04:33 ubu20 systemd[1]: user@0.service: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1]: Stopped User Manager for UID 0.
Nov 16 17:04:33 ubu20 systemd[1]: Stopping User Runtime Directory 
/run/user/0...

Nov 16 17:04:33 ubu20 systemd[2567]: run-user-0.mount: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1294]: run-user-0.mount: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1]: run-user-0.mount: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1]: user-runtime-dir@0.service: Succeeded.
Nov 16 17:04:33 ubu20 systemd[1]: Stopped User Runtime Directory 
/run/user/0.

Nov 16 17:04:33 ubu20 systemd[1]: Removed slice User Slice of UID 0.

Does anybody have an idea what could have happened?

Regards,
Adam

Re: crash probablement lié à amdgpu

[NoSpam]

Bonjour

Le 27/09/2023 à 13:03, LECOQ Vincent a écrit :
[...]
Depuis mon dernier apt full-upgrade hier, je constate un crash assez 
rapide de ma session gnome wayland.

[...]
Linux b550 6.5.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1 
(2023-09-13) x86_64 GNU/Linux

oktail@b550:~$ cat /etc/debian_version
trixie/sid


[...]

Les plaisirs de SID :) Ouvrir un ticket de bug est la solution et 
revenir aux versions antérieurs des paquets concernés.

crash probablement lié à amdgpu

[LECOQ Vincent]

Bonjour,

J'ai jeté un oeil (rapide, trop?) aux bugs ouverts sans trouver, donc je
rapporte ma petite misère.
Depuis mon dernier apt full-upgrade hier, je constate un crash assez rapide
de ma session gnome wayland.
mon dmesg indique alors:
[ 4765.695352] [ cut here ]
[ 4765.695354] WARNING: CPU: 2 PID: 721753 at
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:615 amdgpu_irq_put+0x46/0x70
[amdgpu]
[ 4765.695512] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq
rpcsec_gss_krb5 auth_rpcgss nf_tables nfnetlink nfsv4 dns_resolver nfs
lockd grace fscache netfs qrtr cmac algif_hash algif_skcipher af_alg bnep
sunrpc binfmt_misc nls_ascii nls_cp437 intel_rapl_msr vfat
intel_rapl_common fat edac_mce_amd mt7921e btusb mt7921_common btrtl btbcm
kvm_amd mt76_connac_lib btintel btmtk mt76 bluetooth kvm mac80211
sha3_generic jitterentropy_rng irqbypass uvcvideo drbg videobuf2_vmalloc
libarc4 ghash_clmulni_intel uvc videobuf2_memops snd_hda_codec_hdmi
ansi_cprng videobuf2_v4l2 sha512_ssse3 snd_hda_intel ecdh_generic
sha512_generic snd_usb_audio videodev snd_intel_dspcfg ecc cfg80211
snd_intel_sdw_acpi snd_usbmidi_lib snd_hda_codec snd_rawmidi
videobuf2_common snd_seq_device aesni_intel snd_hda_core crypto_simd mc
cryptd snd_pci_acp6x snd_hwdep snd_pci_acp5x snd_pcm rfkill
snd_rn_pci_acp3x rapl wmi_bmof snd_timer snd_acp_config snd_soc_acpi snd
pcspkr sp5100_tco k10temp ccp watchdog snd_pci_acp3x soundcore joydev sg
[ 4765.695578]  evdev msr parport_pc ppdev lp parport fuse loop efi_pstore
configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs
blake2b_generic efivarfs raid10 raid456 async_raid6_recov async_memcpy
async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1
raid0 multipath linear md_mod hid_cmedia amdgpu hid_generic amdxcp
drm_buddy gpu_sched i2c_algo_bit drm_suballoc_helper usbhid uas
drm_display_helper hid usb_storage sd_mod cec rc_core dm_mod drm_ttm_helper
ttm ahci drm_kms_helper libahci nvme xhci_pci xhci_hcd nvme_core libata drm
t10_pi usbcore scsi_mod igc crc32_pclmul crc64_rocksoft crc32c_intel crc64
crc_t10dif crct10dif_generic crct10dif_pclmul i2c_piix4 crct10dif_common
usb_common scsi_common video wmi gpio_amdpt gpio_generic button
[ 4765.695636] CPU: 2 PID: 721753 Comm: kworker/u64:2 Tainted: GW
   6.5.0-1-amd64 #1  Debian 6.5.3-1
[ 4765.695639] Hardware name: BESSTAR TECH LIMITED B550/B550, BIOS 5.17
03/31/2022
[ 4765.695640] Workqueue: amdgpu-reset-dev drm_sched_job_timedout
[gpu_sched]
[ 4765.695646] RIP: 0010:amdgpu_irq_put+0x46/0x70 [amdgpu]
[ 4765.695796] Code: c0 74 33 48 8b 4e 10 48 83 39 00 74 29 89 d1 48 8d 04
88 8b 08 85 c9 74 11 f0 ff 08 74 07 31 c0 e9 cf 5d 1d c4 e9 5a fd ff ff
<0f> 0b b8 ea ff ff ff e9 be 5d 1d c4 b8 ea ff ff ff e9 b4 5d 1d c4
[ 4765.695798] RSP: 0018:bc5f85a17c80 EFLAGS: 00010246
[ 4765.695800] RAX: 9642e26b1370 RBX: 96420e88 RCX:

[ 4765.695801] RDX:  RSI: 96420e8a78a8 RDI:
96420e88
[ 4765.695802] RBP: 96420e88 R08: eb8d0e5d R09:
eb8d0e5cc001
[ 4765.695803] R10: 0002 R11:  R12:
1050
[ 4765.695804] R13: 96420e8c1218 R14: 964358662000 R15:

[ 4765.695806] FS:  () GS:9650de28()
knlGS:
[ 4765.695807] CS:  0010 DS:  ES:  CR0: 80050033
[ 4765.695808] CR2: 7f6a18805760 CR3: 00010c2ae000 CR4:
00750ee0
[ 4765.695810] PKRU: 5554
[ 4765.695810] Call Trace:
[ 4765.695813]  
[ 4765.695815]  ? amdgpu_irq_put+0x46/0x70 [amdgpu]
[ 4765.695963]  ? __warn+0x81/0x130
[ 4765.695970]  ? amdgpu_irq_put+0x46/0x70 [amdgpu]
[ 4765.696108]  ? report_bug+0x191/0x1c0
[ 4765.696112]  ? handle_bug+0x3c/0x80
[ 4765.696116]  ? exc_invalid_op+0x17/0x70
[ 4765.696118]  ? asm_exc_invalid_op+0x1a/0x20
[ 4765.696123]  ? amdgpu_irq_put+0x46/0x70 [amdgpu]
[ 4765.696250]  gfx_v9_0_hw_fini+0x35/0x710 [amdgpu]
[ 4765.696380]  amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
[ 4765.696497]  ? amdgpu_device_ip_suspend_phase1+0x6f/0xe0 [amdgpu]
[ 4765.696614]  amdgpu_device_ip_suspend+0x36/0x70 [amdgpu]
[ 4765.696731]  amdgpu_device_pre_asic_reset+0xd3/0x2a0 [amdgpu]
[ 4765.696849]  amdgpu_device_gpu_recover+0x4c6/0xd70 [amdgpu]
[ 4765.696968]  amdgpu_job_timedout+0x186/0x270 [amdgpu]
[ 4765.697112]  ? srso_alias_return_thunk+0x5/0x7f
[ 4765.697118]  drm_sched_job_timedout+0x7a/0x110 [gpu_sched]
[ 4765.697124]  process_one_work+0x1e1/0x3f0
[ 4765.697128]  worker_thread+0x51/0x390
[ 4765.697130]  ? _raw_spin_lock_irqsave+0x27/0x60
[ 4765.697133]  ? __pfx_worker_thread+0x10/0x10
[ 4765.697134]  kthread+0xf7/0x130
[ 4765.697137]  ? __pfx_kthread+0x10/0x10
[ 4765.697140]  ret_from_fork+0x34/0x50
[ 4765.697143]  ? __pfx_kthread+0x10/0x10
[ 4765.697146]  ret_from_fork_asm+0x1b/0x30
[ 4765.697152]  
[ 4765.697153] ---[ end trace  ]---
[ 4765.697161] [ cut here ]

L'écran clign

[regle] Re: [testing] crash firefox 114.0-1

[Gaëtan Perrier]

Le jeudi 22 juin 2023 à 22:33 +0200, Gaëtan Perrier a écrit :
> Bonjour,
> 
> Depuis ce soir suite aux mises à jours de testing du jour, firefox crash au
> démarrage même en --safe-mode.
> 
> ~$ firefox --safe-mode 
> ExceptionHandler::GenerateDump cloned child
> ExceptionHandler::WaitForContinueSignal waiting for continue signal...
> 16491
> ExceptionHandler::SendContinueSignalToChild sent continue signal to child
> Exiting due to channel error.
> Exiting due to channel error.
> ~$ Failed to open curl lib from binary, use libcurl.so instead
> ~$ 
> 
> Est-ce de même pour vous ?
> 
> Gaêtan

Bonjour,

Ce matin ça refonctionne ...

Gaëtan


signature.asc
Description: This is a digitally signed message part

[testing] crash firefox 114.0-1

[Gaëtan Perrier]

Bonjour,

Depuis ce soir suite aux mises à jours de testing du jour, firefox crash au
démarrage même en --safe-mode.

~$ firefox --safe-mode 
ExceptionHandler::GenerateDump cloned child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
16491
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
~$ Failed to open curl lib from binary, use libcurl.so instead
~$ 

Est-ce de même pour vous ?

Gaêtan


signature.asc
Description: This is a digitally signed message part

Re: [SOLVED] Re: crash with wine and nvidia-driver

[Hans]

Am Samstag, 15. Oktober 2022, 20:37:41 CEST schrieb piorunz:
Hi Piotr,

tried before as you suggested: deleting all configs of wine without success.

I also tried wine7.0 from winehq, but this did not work and wanted to 
deinstall many of my applications, like digicam or similar.

Hope, that debian will update wine soon to version 7, but maybe they will 
never do on debian/stable. Maybe in the next release

Happy gaming and best regards

Hans
> On 15/10/2022 18:18, Hans wrote:
> > Am Samstag, 15. Oktober 2022, 15:08:40 CEST schrieb piorunz:
> > Hi Piotr,
> > 
> > sadly this did not work. However, I got a solution:
> > 
> > I purged all wine packages from debian, then reinstalled wine, but only
> > minimalistic, say, all necessary packages.
> > 
> > I spared all suggested packages - and it worked now. No crash any more and
> > "primusrun glxgears -info" is now running.
> 
> Great! But maybe it was wine configuration files, you seem to be using
> only default profile ~/.wine, and maybe files there (Windows
> installation so to speak) got corrupted. So not reinstallation necessary.
> I suggest to delete/move/manipulate default profile ~/.wine next time,
> to save time. And ultimately, you can start using Lutris to manage your
> Wine profiles or do it manually by using shortcut for example:
> WINEPREFIX=/home/path... wine something.exe
> 
> And lastly if you serious about gaming then latest Wine is good option,
> not using Wine 5 from Debian stable but latest and greatest Wine 7.
> I am gaming on wine-staging (v7.18 at the moment) and it's great.
> https://wiki.winehq.org/Debian
> 
> --
> With kindest regards, Piotr.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄

Re: [SOLVED] Re: crash with wine and nvidia-driver

[piorunz]

On 15/10/2022 18:18, Hans wrote:

Am Samstag, 15. Oktober 2022, 15:08:40 CEST schrieb piorunz:
Hi Piotr,

sadly this did not work. However, I got a solution:

I purged all wine packages from debian, then reinstalled wine, but only
minimalistic, say, all necessary packages.

I spared all suggested packages - and it worked now. No crash any more and
"primusrun glxgears -info" is now running.


Great! But maybe it was wine configuration files, you seem to be using
only default profile ~/.wine, and maybe files there (Windows
installation so to speak) got corrupted. So not reinstallation necessary.
I suggest to delete/move/manipulate default profile ~/.wine next time,
to save time. And ultimately, you can start using Lutris to manage your
Wine profiles or do it manually by using shortcut for example:
WINEPREFIX=/home/path... wine something.exe

And lastly if you serious about gaming then latest Wine is good option,
not using Wine 5 from Debian stable but latest and greatest Wine 7.
I am gaming on wine-staging (v7.18 at the moment) and it's great.
https://wiki.winehq.org/Debian

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

[SOLVED] Re: crash with wine and nvidia-driver

[Hans]

Am Samstag, 15. Oktober 2022, 15:08:40 CEST schrieb piorunz:
Hi Piotr,

sadly this did not work. However, I got a solution:

I purged all wine packages from debian, then reinstalled wine, but only 
minimalistic, say, all necessary packages.

I spared all suggested packages - and it worked now. No crash any more and 
"primusrun glxgears -info" is now running. 

Additionally also the games prior not working with nvidia legacy driver are 
working now, too.

It looks for me, some additional package forced the crash, but I can nor say, 
which one. It is no need, to look at, because wine in debian/stable is rather 
old (it is version 5, whilst the actual version is now version 7). I suppose, 
debian will update this package soon, as even for debian/stable version 5 is 
too old IMHO.

Thank you all for any help.

Best regards

Hans

> On 13/10/2022 17:43, Hans wrote:
> > As I am not believing, this is related to the game (as ALL games are
> > crashing), I believe, it is related to a systematical error in the
> > relationship between wine and nvidia-driver.
> 
> To verify this hypothesis, run for example:
> primusrun wine notepad.exe
> primusrun winecfg
> 
> See if that opens.
> 
> --
> With kindest regards, Piotr.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄

Re: crash with wine and nvidia-driver

[piorunz]

On 13/10/2022 17:43, Hans wrote:

As I am not believing, this is related to the game (as ALL games are
crashing), I believe, it is related to a systematical error in the
relationship between wine and nvidia-driver.


To verify this hypothesis, run for example:
primusrun wine notepad.exe
primusrun winecfg

See if that opens.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

running outdated software (was: crash with wine and nvidia-driver)

[DdB]

Am 13.10.2022 um 18:43 schrieb Hans:
> Hi folks,
> 
> maybe someone got into the same problem as me and can help.

Well, i cannot help. Sorry

But i am very used to running outdated software, as i am living the old
recipe to "never change a working system". The only thing, that i am
doing is to separate different configurations into virtual machines,
where i still am able to run Windows XP (as an example). Intentionally i
am accepting to fall back in time, if the alternatove is to deal with
buggy software or combinations thereof.

Only recently, i discovered, that one of my long-living problems that
had me stay with a 6 year old software combination is no longer present
in a more recent software stack. In order to find out such changes, i
HAVE TO check the functionality of more recent releases from time to
time, which - in order to ensure proper isolation from my main system -
requires a second bootable copy of the main OS.

Long story short: I suggest you create alternatives in order to check
more recent software. Because not only your situation tennds to evolve
into a more and more unique corner case, but also you lose touch to the
cutting edge of developers, who would not be interested to fix past
problems, as there is practically no merit in doing so.

Another example of mine: I did stay with firefox-esr from 2 years ago,
in order of being able to use plugins, that had not yet been transformed
to the new mozilla doctrine. But after some time, i found another
combination of plugins fulfilling my needs just as well as the old ones
did, so i decided to jump to a more recent version of the fox. It is not
such a bright idea to be stubborn and sticking to the older versions,
among ther reasons: because i would have turned onto the only one
(world-wide) using that specific software stack, thus having a unique
fingerprint and killing anonymity...

I suggest not clinging to your specific software combo too frenetically.

But i am sharing your sort of trouble more or less regularly and thus
feel with you.

best of luck, DdB

> As I am not believing, this is related to the game (as ALL games are 
> crashing), I believe, it is related to a systematical error in the 
> relationship between wine and nvidia-driver.

My own experiences with wine were not all that pleasant. Nowadays, i try
to avoid it as best as i can, nuked all the places, where i had
integrated it into my regular system usage.

> (...) 
> So, I hope, someone might got into the same issue, too, and could fix it.
> 
> Any help is welcome.
> 
> Thank you very much!
> 
> Best regards
> 
> Hans

crash with wine and nvidia-driver

[Hans]

Hi folks,

maybe someone got into the same problem as me and can help.

I am using a laptop with a graphic chip in the intel-cpu and an extern graphic 
card from NVidia. The nvidia chip is an NVS4200M and running with kernel 
module *legacy-340xx*

Yes, I know, NVidia and also Debian says, it shall be *-legacy-390xx-*, but 
390xx will not run. 

340xx is well running, and "primusrun glxgears -info" is telling, the kernel 
is loaded and it is the nvidia kernel/module.

But that should not be our problem.

My issue is, that starting ANY wine application (like a game or something 
else) using "primusrun wine bla.exe" is turning ito a segfault.

As I am not believing, this is related to the game (as ALL games are 
crashing), I believe, it is related to a systematical error in the 
relationship between wine and nvidia-driver.

Please note: Running all these applications without primusrun or optirun, so 
using the internal graphic chip, everything is running, but slow.

I read in many forums, but whenever thisissue appears, the writers are always 
pointing to a special game or application, but (maybe) did not recognize, this 
is a general issue.

The system running here is debian/stable and I know, the wine version is 
rather old (version 5, the actual one is version 7.x), but I personally 
believe, this should not amtter, as the nvidia driver 340xx is old, too.

Note beside: 390xx and 340xx can not be build any more, as the kernel-header-
files or the compiler had changed since 5.10.12,  some files are missing. 
There is already a bugreport related to this by me.
(Luckily I have a package as backup available).

I do not know, where to look any more and how to discover, what is happening. 
Tried starting using strace, but this did not show me any usefull output.

So, I hope, someone might got into the same issue, too, and could fix it.

Any help is welcome.

Thank you very much!

Best regards

Hans

Nautilus crash

[Polyna-Maude Racicot-Summerside]

Hi,
Anyone is having problem with Nautilus crashing on launch using Buster ?
Thanks

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

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

On Thursday, 2 June 2022 11:02:10 EDT David Wright wrote:
> On Wed 01 Jun 2022 at 19:30:37 (-0400), gene heskett wrote:
> > On Wednesday, 1 June 2022 16:34:01 EDT David Wright wrote:
> > > On Wed 01 Jun 2022 at 01:23:08 (-0400), gene heskett wrote:
> > > > On Wednesday, 1 June 2022 00:58:32 EDT David Wright wrote:
> > > > > On Wed 01 Jun 2022 at 00:26:27 (-0400), gene heskett wrote:
> > > > > > On Tuesday, 31 May 2022 16:25:01 EDT Andrew M.A. Cater wrote:
> > > > > > > On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett 
wrote:
> > > > > > I now know where the seriel convertors are so I can unplug
> > > > > > them
> > > > > > so I
> > > > > > could reinstall for about the 25th time if someone could tell
> > > > > > me
> > > > > > how
> > > > > > to skip formatting my raid10 /home partition, othewise I am
> > > > > > stuck
> > > > > > building a working system to do my daily stuff from nothing.
> > > > > > 
> > > > > > The installer blindly goes ahead and formats it every time,
> > > > > > losing 6
> > > > > > months of work in OpenSCAD and thats pure bs IMNSHO. I'm
> > > > > > halfway
> > > > > > thru
> > > > > > building another raid10 I can hide from the installer,
> > > > > > needing
> > > > > > two
> > > > > > more terabyte samsung ssd's and a slot for aother controller
> > > > > > which I
> > > > > > can free up by temporarily pulling my firewire card that runs
> > > > > > my
> > > > > > movie camera with kino.
> > > > > 
> > > > > I don't understand. You have /home on a separate partition(s),
> > > > > yes?
> > > > > Then why do you tell the installer anything about it/them?
> > > > > Just make sure that if you select it/them, they look like this:
> > > > > 
> > > > > [ … ]
> > > > > 
> > > > > 
> > > > > You don't need a /home *partition* to install Debian. Just let
> > > > > it
> > > > > create a /home/gene on the root filesystem, populated with the
> > > > > contents of /etc/skel/, as per usual. When it's done, then as
> > > > > root,
> > > > > set up your real home directory (or "assemble" it, or whatever
> > > > > you
> > > > > do) and use the /home directory that the installer created as
> > > > > mount
> > > > > point.
> > > > 
> > > > I've tried to do that David, several times. But the net installer
> > > > just
> > > > keeps looping back to that until I use it, which formats it.
> > > 
> > > Because that statement is /so/ vague, I'll have to read /something/
> > > into it. By "until I use it", do you mean that you have to use the
> > > Partitioner Disks step, as seen here, before you can Install the
> > > Base System?
> > 
> > yes, it will not proceed w/o it.
> > 
> > > │  Detect disks   │
> > > │  Partition disks│
> > > │  Install the base system│
> 
> ISTR your having problems driving the partitioner back in 2015.
> You need that partitioning step at the very least in order to indicate
> on which partition to install the base system. But that doesn't mean
> you have to format any of the partitions. That's why there's an option:
> "Format the partition:  no, keep existing data"
> 
> Obviously, it would complicate configuring a system if you actually
> went ahead with installing the root filesystem onto a partition that
> still contained a load of old files from some previous installation.
> 
> So I'd be interested to see the screen display at the point where you
> tell it to "Finish partitioning and write changes to disk". That's
> at the bottom of the screen that displays all the partitions, that
> looks vaguely like this:
> 
>   ┌┤ [!!] Partition disks
> ├─┐ │ 
>│ │ This is an overview of your
> currently configured partitions and mount   │ │ points. Select a
> partition to modify its settings (file system, mount   │ │ point,
> etc.), a free space to create partitions, or a device to │ │
> initialize its partition table.   
>  │ │  
>   │ │  Configure iSCSI volumes
>↑   │ │
> ▒   │ │  Encrypted volume (sda5_crypt) - 31.4 GB Linux
> device-mapper (cryp  ▒   │ │  > #1 31.4 GBf  ext4 
> / ▒   │ │  SCSI1 (0,0,0) (sda) - 500.1 GB ATA
> ST350AA ▒   │ │  > 1.0 MB  
> FREE SPACE  ▒   │ │  > #1  3.1 MB 
>   K  biosgrubBIOS boot pa▒   │ │  > #2   
> 520.1 MBF  ext2BullBoot  /boot ▒   │ │  >
> #3524.3 MB   ext2Linux swap  ▒   │ │ 
> > #4 31.5 GB   ext4Viva-A  ▒  
> │ │  > #5 31.5 GBK  crypto  Viva-B(sda5_crypt)
>  ▒   │ │  > #6436.1 GB  

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

On Thursday, 2 June 2022 10:39:33 EDT gene heskett wrote:
> On Thursday, 2 June 2022 04:08:45 EDT Anssi Saari wrote:
> > gene heskett  writes:
> > > Do I have to reset those perms everytime I'm forced to reboot,
> > > which
> > > is usually in 5 to 10 days. Or is there someplace in
> > > /lib/udev/rules.d where I can fix this until the next udev update?
> > 
> > It seems almost certain the permissions for /dev/ttyUSB* won't stick,
> > unless you fix them with udev rules (or some other means but udev's
> > the tool for the job in my opinion).
> > 
> > Do you really want to set all ttyUSB* to 777? Not 666 or 660 for
> > example? The usual way is to apply a udev rule to a specific USB
> > product and vendor ID which you can get from lsusb. But to change
> > permissions on device files I think you can do
> > 
> > KERNEL=="ttyUSB*", MODE="0777"
> > 
> > in a udev rule file.
> 
> /dev/ttyUSB* seems to only apply to seriel adapters, which I have two
> of. One driving a cm11a interface to talk to C10 stuff, and one
> driving a ups.
> 
> Thank you Anssi. Take care and stay well.
> 
> Cheers, Gene Heskett.


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

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

On Thursday, 2 June 2022 10:39:33 EDT gene heskett wrote:
> On Thursday, 2 June 2022 04:08:45 EDT Anssi Saari wrote:
> > gene heskett  writes:
> > > Do I have to reset those perms everytime I'm forced to reboot,
> > > which
> > > is usually in 5 to 10 days. Or is there someplace in
> > > /lib/udev/rules.d where I can fix this until the next udev update?
> > 
> > It seems almost certain the permissions for /dev/ttyUSB* won't stick,
> > unless you fix them with udev rules (or some other means but udev's
> > the tool for the job in my opinion).
> > 
> > Do you really want to set all ttyUSB* to 777? Not 666 or 660 for
> > example? The usual way is to apply a udev rule to a specific USB
> > product and vendor ID which you can get from lsusb. But to change
> > permissions on device files I think you can do
> > 
> > KERNEL=="ttyUSB*", MODE="0777"
> > 
> > in a udev rule file.
> 
> /dev/ttyUSB* seems to only apply to seriel adapters, which I have two
> of. One driving a cm11a interface to talk to C10 stuff, and one
> driving a ups.

Darn typus, that s/b X10 above, not C10. Short/fat ancient finger 
syndrome.

> Thank you Anssi. Take care and stay well.
> 
> Cheers, Gene Heskett.


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

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[David Wright]

On Wed 01 Jun 2022 at 19:30:37 (-0400), gene heskett wrote:
> On Wednesday, 1 June 2022 16:34:01 EDT David Wright wrote:
> > On Wed 01 Jun 2022 at 01:23:08 (-0400), gene heskett wrote:
> > > On Wednesday, 1 June 2022 00:58:32 EDT David Wright wrote:
> > > > On Wed 01 Jun 2022 at 00:26:27 (-0400), gene heskett wrote:
> > > > > On Tuesday, 31 May 2022 16:25:01 EDT Andrew M.A. Cater wrote:
> > > > > > On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett wrote:
> > > > > I now know where the seriel convertors are so I can unplug them
> > > > > so I
> > > > > could reinstall for about the 25th time if someone could tell me
> > > > > how
> > > > > to skip formatting my raid10 /home partition, othewise I am stuck
> > > > > building a working system to do my daily stuff from nothing.
> > > > > 
> > > > > The installer blindly goes ahead and formats it every time,
> > > > > losing 6
> > > > > months of work in OpenSCAD and thats pure bs IMNSHO. I'm halfway
> > > > > thru
> > > > > building another raid10 I can hide from the installer, needing
> > > > > two
> > > > > more terabyte samsung ssd's and a slot for aother controller
> > > > > which I
> > > > > can free up by temporarily pulling my firewire card that runs my
> > > > > movie camera with kino.
> > > > 
> > > > I don't understand. You have /home on a separate partition(s), yes?
> > > > Then why do you tell the installer anything about it/them?
> > > > Just make sure that if you select it/them, they look like this:
> > > > 
> > > > [ … ]
> > > > 
> > > > 
> > > > You don't need a /home *partition* to install Debian. Just let it
> > > > create a /home/gene on the root filesystem, populated with the
> > > > contents of /etc/skel/, as per usual. When it's done, then as root,
> > > > set up your real home directory (or "assemble" it, or whatever you
> > > > do) and use the /home directory that the installer created as mount
> > > > point.
> > > 
> > > I've tried to do that David, several times. But the net installer
> > > just
> > > keeps looping back to that until I use it, which formats it.
> > 
> > Because that statement is /so/ vague, I'll have to read /something/
> > into it. By "until I use it", do you mean that you have to use the
> > Partitioner Disks step, as seen here, before you can Install the
> > Base System?
> > 
> yes, it will not proceed w/o it.
> 
> > │  Detect disks   │
> > │  Partition disks│
> > │  Install the base system│

ISTR your having problems driving the partitioner back in 2015.
You need that partitioning step at the very least in order to indicate
on which partition to install the base system. But that doesn't mean
you have to format any of the partitions. That's why there's an option:
  "Format the partition:  no, keep existing data"

Obviously, it would complicate configuring a system if you actually
went ahead with installing the root filesystem onto a partition that
still contained a load of old files from some previous installation.

So I'd be interested to see the screen display at the point where you
tell it to "Finish partitioning and write changes to disk". That's
at the bottom of the screen that displays all the partitions, that
looks vaguely like this:

  ┌┤ [!!] Partition disks ├─┐   
  │ │   
  │ This is an overview of your currently configured partitions and mount   │   
  │ points. Select a partition to modify its settings (file system, mount   │   
  │ point, etc.), a free space to create partitions, or a device to │   
  │ initialize its partition table. │   
  │ │   
  │  Configure iSCSI volumes↑   │   
  │ ▒   │   
  │  Encrypted volume (sda5_crypt) - 31.4 GB Linux device-mapper (cryp  ▒   │   
  │  > #1 31.4 GBf  ext4  / ▒   │   
  │  SCSI1 (0,0,0) (sda) - 500.1 GB ATA ST350AA ▒   │   
  │  > 1.0 MB   FREE SPACE  ▒   │   
  │  > #1  3.1 MBK  biosgrubBIOS boot pa▒   │   
  │  > #2520.1 MBF  ext2BullBoot  /boot ▒   │   
  │  > #3524.3 MB   ext2Linux swap  ▒   │   
  │  > #4 31.5 GB   ext4Viva-A  ▒   │   
  │  > #5 31.5 GBK  crypto  Viva-B(sda5_crypt)  ▒   │   
  │  > #6436.1 GB   Viva-Home   ▒   │   
  │  > 7.7 kB   FREE SPACE  ▒   │   
  │  SCSI7 (0,0,0) (sdb) - 1.0 GB Multiple Card Reader  ▒   │   
  │

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

On Thursday, 2 June 2022 04:08:45 EDT Anssi Saari wrote:
> gene heskett  writes:
> > Do I have to reset those perms everytime I'm forced to reboot, which
> > is usually in 5 to 10 days. Or is there someplace in
> > /lib/udev/rules.d where I can fix this until the next udev update?
> 
> It seems almost certain the permissions for /dev/ttyUSB* won't stick,
> unless you fix them with udev rules (or some other means but udev's the
> tool for the job in my opinion).
> 
> Do you really want to set all ttyUSB* to 777? Not 666 or 660 for
> example? The usual way is to apply a udev rule to a specific USB
> product and vendor ID which you can get from lsusb. But to change
> permissions on device files I think you can do
> 
> KERNEL=="ttyUSB*", MODE="0777"
> 
> in a udev rule file.

/dev/ttyUSB* seems to only apply to seriel adapters, which I have two of. 
One driving a cm11a interface to talk to C10 stuff, and one driving a 
ups.

Thank you Anssi. Take care and stay well.

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

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[Anssi Saari]

gene heskett  writes:

> Do I have to reset those perms everytime I'm forced to reboot, which is 
> usually in 5 to 10 days. Or is there someplace in /lib/udev/rules.d where 
> I can fix this until the next udev update?

It seems almost certain the permissions for /dev/ttyUSB* won't stick,
unless you fix them with udev rules (or some other means but udev's the
tool for the job in my opinion).

Do you really want to set all ttyUSB* to 777? Not 666 or 660 for
example? The usual way is to apply a udev rule to a specific USB product
and vendor ID which you can get from lsusb. But to change permissions on
device files I think you can do

KERNEL=="ttyUSB*", MODE="0777"

in a udev rule file.

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

On Wednesday, 1 June 2022 16:34:01 EDT David Wright wrote:
> On Wed 01 Jun 2022 at 01:23:08 (-0400), gene heskett wrote:
> > On Wednesday, 1 June 2022 00:58:32 EDT David Wright wrote:
> > > On Wed 01 Jun 2022 at 00:26:27 (-0400), gene heskett wrote:
> > > > On Tuesday, 31 May 2022 16:25:01 EDT Andrew M.A. Cater wrote:
> > > > > On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett wrote:
> > > > I now know where the seriel convertors are so I can unplug them
> > > > so I
> > > > could reinstall for about the 25th time if someone could tell me
> > > > how
> > > > to skip formatting my raid10 /home partition, othewise I am stuck
> > > > building a working system to do my daily stuff from nothing.
> > > > 
> > > > The installer blindly goes ahead and formats it every time,
> > > > losing 6
> > > > months of work in OpenSCAD and thats pure bs IMNSHO. I'm halfway
> > > > thru
> > > > building another raid10 I can hide from the installer, needing
> > > > two
> > > > more terabyte samsung ssd's and a slot for aother controller
> > > > which I
> > > > can free up by temporarily pulling my firewire card that runs my
> > > > movie camera with kino.
> > > 
> > > I don't understand. You have /home on a separate partition(s), yes?
> > > Then why do you tell the installer anything about it/them?
> > > Just make sure that if you select it/them, they look like this:
> > > 
> > > [ … ]
> > > 
> > > 
> > > You don't need a /home *partition* to install Debian. Just let it
> > > create a /home/gene on the root filesystem, populated with the
> > > contents of /etc/skel/, as per usual. When it's done, then as root,
> > > set up your real home directory (or "assemble" it, or whatever you
> > > do) and use the /home directory that the installer created as mount
> > > point.
> > 
> > I've tried to do that David, several times. But the net installer
> > just
> > keeps looping back to that until I use it, which formats it.
> 
> Because that statement is /so/ vague, I'll have to read /something/
> into it. By "until I use it", do you mean that you have to use the
> Partitioner Disks step, as seen here, before you can Install the
> Base System?
> 
> │  Detect disks   │
> │  Partition disks│
> │  Install the base system│
> 
> Cheers,
> David.
> 
> .
Tell me how long this will work:

I reset the perms on /dev/ttyUSB* to 777
retarted heyu, got some config errors that made sense, fixed those and 
its working.
Then I started nut-server and client, getting more errors that made 
sense, fixed those and its working.

Do I have to reset those perms everytime I'm forced to reboot, which is 
usually in 5 to 10 days. Or is there someplace in /lib/udev/rules.d where 
I can fix this until the next udev update?

Thanks David. Take care & stay well.

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

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

On Wednesday, 1 June 2022 16:34:01 EDT David Wright wrote:
> On Wed 01 Jun 2022 at 01:23:08 (-0400), gene heskett wrote:
> > On Wednesday, 1 June 2022 00:58:32 EDT David Wright wrote:
> > > On Wed 01 Jun 2022 at 00:26:27 (-0400), gene heskett wrote:
> > > > On Tuesday, 31 May 2022 16:25:01 EDT Andrew M.A. Cater wrote:
> > > > > On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett wrote:
> > > > I now know where the seriel convertors are so I can unplug them
> > > > so I
> > > > could reinstall for about the 25th time if someone could tell me
> > > > how
> > > > to skip formatting my raid10 /home partition, othewise I am stuck
> > > > building a working system to do my daily stuff from nothing.
> > > > 
> > > > The installer blindly goes ahead and formats it every time,
> > > > losing 6
> > > > months of work in OpenSCAD and thats pure bs IMNSHO. I'm halfway
> > > > thru
> > > > building another raid10 I can hide from the installer, needing
> > > > two
> > > > more terabyte samsung ssd's and a slot for aother controller
> > > > which I
> > > > can free up by temporarily pulling my firewire card that runs my
> > > > movie camera with kino.
> > > 
> > > I don't understand. You have /home on a separate partition(s), yes?
> > > Then why do you tell the installer anything about it/them?
> > > Just make sure that if you select it/them, they look like this:
> > > 
> > > [ … ]
> > > 
> > > 
> > > You don't need a /home *partition* to install Debian. Just let it
> > > create a /home/gene on the root filesystem, populated with the
> > > contents of /etc/skel/, as per usual. When it's done, then as root,
> > > set up your real home directory (or "assemble" it, or whatever you
> > > do) and use the /home directory that the installer created as mount
> > > point.
> > 
> > I've tried to do that David, several times. But the net installer
> > just
> > keeps looping back to that until I use it, which formats it.
> 
> Because that statement is /so/ vague, I'll have to read /something/
> into it. By "until I use it", do you mean that you have to use the
> Partitioner Disks step, as seen here, before you can Install the
> Base System?
> 
yes, it will not proceed w/o it.

> │  Detect disks   │
> │  Partition disks│
> │  Install the base system│
> 
> Cheers,
> David.
> 
> .


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

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[David Wright]

On Wed 01 Jun 2022 at 01:23:08 (-0400), gene heskett wrote:
> On Wednesday, 1 June 2022 00:58:32 EDT David Wright wrote:
> > On Wed 01 Jun 2022 at 00:26:27 (-0400), gene heskett wrote:
> > > On Tuesday, 31 May 2022 16:25:01 EDT Andrew M.A. Cater wrote:
> > > > On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett wrote:
> > > I now know where the seriel convertors are so I can unplug them so I
> > > could reinstall for about the 25th time if someone could tell me how
> > > to skip formatting my raid10 /home partition, othewise I am stuck
> > > building a working system to do my daily stuff from nothing.
> > > 
> > > The installer blindly goes ahead and formats it every time, losing 6
> > > months of work in OpenSCAD and thats pure bs IMNSHO. I'm halfway thru
> > > building another raid10 I can hide from the installer, needing two
> > > more terabyte samsung ssd's and a slot for aother controller which I
> > > can free up by temporarily pulling my firewire card that runs my
> > > movie camera with kino.
> > 
> > I don't understand. You have /home on a separate partition(s), yes?
> > Then why do you tell the installer anything about it/them?
> > Just make sure that if you select it/them, they look like this:
> > 
> > [ … ]
> > 
> > 
> > You don't need a /home *partition* to install Debian. Just let it
> > create a /home/gene on the root filesystem, populated with the
> > contents of /etc/skel/, as per usual. When it's done, then as root,
> > set up your real home directory (or "assemble" it, or whatever you
> > do) and use the /home directory that the installer created as mount
> > point.
> > 
> I've tried to do that David, several times. But the net installer just 
> keeps looping back to that until I use it, which formats it.

Because that statement is /so/ vague, I'll have to read /something/
into it. By "until I use it", do you mean that you have to use the
Partitioner Disks step, as seen here, before you can Install the
Base System?

│  Detect disks   │
│  Partition disks│
│  Install the base system│

Cheers,
David.

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

On Wednesday, 1 June 2022 00:58:32 EDT David Wright wrote:
> On Wed 01 Jun 2022 at 00:26:27 (-0400), gene heskett wrote:
> > On Tuesday, 31 May 2022 16:25:01 EDT Andrew M.A. Cater wrote:
> > > On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett wrote:
> > I now know where the seriel convertors are so I can unplug them so I
> > could reinstall for about the 25th time if someone could tell me how
> > to skip formatting my raid10 /home partition, othewise I am stuck
> > building a working system to do my daily stuff from nothing.
> > 
> > The installer blindly goes ahead and formats it every time, losing 6
> > months of work in OpenSCAD and thats pure bs IMNSHO. I'm halfway thru
> > building another raid10 I can hide from the installer, needing two
> > more terabyte samsung ssd's and a slot for aother controller which I
> > can free up by temporarily pulling my firewire card that runs my
> > movie camera with kino.
> 
> I don't understand. You have /home on a separate partition(s), yes?
> Then why do you tell the installer anything about it/them?
> Just make sure that if you select it/them, they look like this:
> 
> 
> 
>   ┌┤ [!!] Partition disks
> ├─┐ │ 
>│ │ You are editing partition #1 of
> SCSI1 (0,0,0) (sda). This partition │ │ is formatted with the Ext4
> journaling file system.  │ │  
>   │ │ Partition
> settings: │ │ 
>│ │
>   Use as: do not use   ←←← LEAVE THIS 
>  │ │  
>   │ │   Bootable flag:  off   
>│ │
> │ │   Resize the partition (currently
> 200.0 GB) │ │   Erase data on this
> partition  │ │   Delete the
> partition  │ │   Done
> setting up the partition    PRESS THIS   │ │  
>   │ │  Back>   │ │   
>  │
> └─
> ┘
> 
> 
> You don't need a /home *partition* to install Debian. Just let it
> create a /home/gene on the root filesystem, populated with the
> contents of /etc/skel/, as per usual. When it's done, then as root,
> set up your real home directory (or "assemble" it, or whatever you
> do) and use the /home directory that the installer created as mount
> point.
> 
> Cheers,
> David.
> 
> .
I've tried to do that David, several times. But the net installer just 
keeps looping back to that until I use it, which formats it.

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

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[David Wright]

On Wed 01 Jun 2022 at 00:26:27 (-0400), gene heskett wrote:
> On Tuesday, 31 May 2022 16:25:01 EDT Andrew M.A. Cater wrote:
> > On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett wrote:

> I now know where the seriel convertors are so I can unplug them so I 
> could reinstall for about the 25th time if someone could tell me how to 
> skip formatting my raid10 /home partition, othewise I am stuck building a 
> working system to do my daily stuff from nothing.
> 
> The installer blindly goes ahead and formats it every time, losing 6 
> months of work in OpenSCAD and thats pure bs IMNSHO. I'm halfway thru 
> building another raid10 I can hide from the installer, needing two more 
> terabyte samsung ssd's and a slot for aother controller which I can free 
> up by temporarily pulling my firewire card that runs my movie camera with 
> kino.

I don't understand. You have /home on a separate partition(s), yes?
Then why do you tell the installer anything about it/them?
Just make sure that if you select it/them, they look like this:



  ┌┤ [!!] Partition disks ├─┐   
  │ │   
  │ You are editing partition #1 of SCSI1 (0,0,0) (sda). This partition │   
  │ is formatted with the Ext4 journaling file system.  │   
  │ │   
  │ Partition settings: │   
  │ │   
  │   Use as: do not use   ←←← LEAVE THIS   │   
  │ │   
  │   Bootable flag:  off   │   
  │ │   
  │   Resize the partition (currently 200.0 GB) │   
  │   Erase data on this partition  │   
  │   Delete the partition  │   
  │   Done setting up the partition    PRESS THIS   │   
  │ │   
  ││   
  │ │   
  └─┘   


You don't need a /home *partition* to install Debian. Just let it
create a /home/gene on the root filesystem, populated with the
contents of /etc/skel/, as per usual. When it's done, then as root,
set up your real home directory (or "assemble" it, or whatever you
do) and use the /home directory that the installer created as mount point.

Cheers,
David.

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

On Tuesday, 31 May 2022 16:25:01 EDT Andrew M.A. Cater wrote:
> On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett wrote:
> > See subject, mouse, keyboard, usb printers working, but /dev/ttyUSB*
> > is not,
> > 
> > "sudo lsusb -v|grep -C3 Couldn -" reports most devices can't be
> > opened.> 
> >  Example:
> > gene@coyote:/etc/nut$ sudo lsusb -v|grep -c3 Couldn -
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get device qualifier: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get device qualifier: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get device qualifier: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get device qualifier: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > can't get device qualifier: Resource temporarily unavailable
> > can't get debug descriptor: Resource temporarily unavailable
> > 
> > I am uptodate a/o yesterday with debian 11. And nothing was offered
> > just now.
> > 
> > Whats changed in the last 10 days?
> > 
> > And where do I start, nut and heyu are both spamming the log. And
> > something is beeping at me at 5 minute intervals.
> 
> Hi Gene,
> 
> We've had something similar to this previously when you were talking
> about USB->TTY converters for driving your CNC machinery and you were
> complaining about accessibility software for blind users being
> installed.
> 
> Pull the leads. Reboot. Insert the leads - check to see whether the
> leads ar recognised. Reboot again. Divide and conquer until you find
> the problematic lead or component. Treat it like troubleshooting a
> troublesome TV transmitter or broadcast system niggle.
> 
> The simpler you can make your system while troubleshooting, the easier
> you (and the rest of us) may find the whack-a-mole process of trying
> to nail down what the actual issue is.
> 
> The more you can tell us what _EXACTLY_ you are doing, what you see,
> what errors come up and what you have done to try and fix them, the
> easier we'll all find it to come up with suggestions or actual answers
> for you.
> 
> There are a bunch of the usual suspects who will attempt to help: we
> can't jump on a plane or a bus to see what your screen says and help
> you debug. The more you can give us to go on, the easier it will be
> all round.
> 
> All the very best to you, as ever,
> 
There are no man pages for nut for starters. So you wind up browseing in 
/usr/share/doc/nut with a browser. But while those docs point at 
troubleshooting aids, the link to the aid is a 404 for konqueror. Thats 
really really helpful, NOT!

I went thru dmesg looking to see where it may have been detected, cvame 
up blank. unplugged the ups for ten secs and plugged it back in and it 
was then detected as /dem/hidraw4 or hiddev4. Put that in ups.conf, no 
permissions. perms are root:dialout. Add nut to dialout in /etc/group.

I can't get heyu to stay up long enough to see who its running as but 
again its no permissions at its normal /dev/ttyUSB0. The ups used to be 
/dev/ttyUSB1. The lsusb -v output is full of no permissions errors that 
do not go away if I sudo it.

The newest files in /lib/udev/rules.d is in february, and I've rebooted 
many times since then bcuz uptimes are in the 5 to maybe 11 days range.

Please give me back the stability even buster had, better yet wheezy, 
there it was not uncommon to get uptimes from power failure to power 
failure.  And I do better than that on an rpi4b running buster, thats 
uptime until I screw something up as it has a small, ultracheap 
cyberpower 650 usp on it and the only time it gets rebooted is when I 
switch to a bullseye card to see if I can build linuxcnc from a git clone 
that a cron script keeps up to date with linuxcnc master of the rpi4. But 
linuxcnc has not yet learned how to use the newer python 3.10 in 
bullseye. So that fails.  So I finally sent another rpi4 user building a 
bigger mill, converting a 1980 vintage cinci mill, a pair of cards with 
my 4.19.71-preempt-rt kernel in place of the raspi kernel. bullseye runs 
just peachy on that kernel and the tarball I made to install it on the pi 
is 28 megabytes, 

Re: had another crash, reboot usb failed, powerdown reboot usb failed

[Andrew M.A. Cater]

On Tue, May 31, 2022 at 03:25:59AM -0400, gene heskett wrote:
> See subject, mouse, keyboard, usb printers working, but /dev/ttyUSB* is 
> not, 
> 
> "sudo lsusb -v|grep -C3 Couldn -" reports most devices can't be opened.
>  Example:
> gene@coyote:/etc/nut$ sudo lsusb -v|grep -c3 Couldn -
> can't get debug descriptor: Resource temporarily unavailable
> can't get device qualifier: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get device qualifier: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get device qualifier: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get device qualifier: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> can't get device qualifier: Resource temporarily unavailable
> can't get debug descriptor: Resource temporarily unavailable
> 
> I am uptodate a/o yesterday with debian 11. And nothing was offered just 
> now.
> 
> Whats changed in the last 10 days?
> 
> And where do I start, nut and heyu are both spamming the log. And 
> something is beeping at me at 5 minute intervals.
> 

Hi Gene,

We've had something similar to this previously when you were talking about
USB->TTY converters for driving your CNC machinery and you were complaining
about accessibility software for blind users being installed.

Pull the leads. Reboot. Insert the leads - check to see whether the leads
ar recognised. Reboot again. Divide and conquer until you find the problematic
lead or component. Treat it like troubleshooting a troublesome TV transmitter
or broadcast system niggle.

The simpler you can make your system while troubleshooting, the easier you
(and the rest of us) may find the whack-a-mole process of trying to 
nail down what the actual issue is.

The more you can tell us what _EXACTLY_ you are doing, what you see, what
errors come up and what you have done to try and fix them, the easier we'll
all find it to come up with suggestions or actual answers for you.

There are a bunch of the usual suspects who will attempt to help: we can't
jump on a plane or a bus to see what your screen says and help you debug.
The more you can give us to go on, the easier it will be all round.

All the very best to you, as ever,

Andy Cater 



> Thanks all;
> 
> 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
> 
> 
> 

had another crash, reboot usb failed, powerdown reboot usb failed

[gene heskett]

See subject, mouse, keyboard, usb printers working, but /dev/ttyUSB* is 
not, 

"sudo lsusb -v|grep -C3 Couldn -" reports most devices can't be opened.
 Example:
gene@coyote:/etc/nut$ sudo lsusb -v|grep -c3 Couldn -
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable

I am uptodate a/o yesterday with debian 11. And nothing was offered just 
now.

Whats changed in the last 10 days?

And where do I start, nut and heyu are both spamming the log. And 
something is beeping at me at 5 minute intervals.

Thanks all;

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

Re: Crash on starting cheese

[Christian Britz]

Hello Armin,

did it work before?

Might not be related, but I had the following experience with Cheese: I
somehow managed to select an invalid resolution for my cam, which also
made Cheese crash IIRC. The solution was to reset it's resolution
settings with the dconf-editor.

You can always report a bug to the package maintainers, see
http://bugs.debian.org.

Regards,
Christian


On 2022-03-02 10:38 UTC+0100, akallab...@posteo.net wrote:
> Hi,
> 
> 
> I´ve just experienced the following crash on starting cheese on my 
> installation.
> 
> Since I´m not sure where to report the but I´m asking on this list for help.
> 
> 
> Camera device is:
> 
> Bus 001 Device 007: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera
> 
> 
> Here a stack trace:
> 
> [?2004h[?2004l[?2004h(gdb) bt
> #0  [33m__GI_raise[m (sig=sig@entry=6) at 
> [32m../sysdeps/unix/sysv/linux/raise.c[m:50
> #1  [34m0x76e82537[m in [33m__GI_abort[m () at [32mabort.c[m:79
> #2  [34m0x7fff94b472cd[m in 
> [33mlibcamera::LogMessage::~LogMessage()[m () at 
> [32m/lib/x86_64-linux-gnu/libcamera.so.0[m
> #3  [34m0x7fff94b3e371[m in 
> [33mlibcamera::IPAManager::IPAManager()[m () at 
> [32m/lib/x86_64-linux-gnu/libcamera.so.0[m
> #4  [34m0x7fff94b13d73[m in 
> [33mlibcamera::CameraManager::Private::Private(libcamera::CameraManager*)[m 
> () at [32m/lib/x86_64-linux-gnu/libcamera.so.0[m
> #5  [34m0x7fff94b1470c[m in 
> [33mlibcamera::CameraManager::CameraManager()[m () at 
> [32m/lib/x86_64-linux-gnu/libcamera.so.0[m
> #6  [34m0x7fff94c0bc4d[m in  () at 
> [32m/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibcamera.so[m
> #7  [34m0x7708c34e[m in [33mgst_element_change_state[m () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #8  [34m0x7708ca8d[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #9  [34m0x7706995c[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #10 [34m0x7708c34e[m in [33mgst_element_change_state[m () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #11 [34m0x7708ca8d[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #12 [34m0x7fff94bee56f[m in  () at 
> [32m/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so[m
> #13 [34m0x7fff94bf06a3[m in  () at 
> [32m/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so[m
> #14 [34m0x7fff94be18c5[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgstbasecamerabinsrc-1.0.so.0[m
> #15 [34m0x7fff94beee08[m in  () at 
> [32m/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so[m
> #16 [34m0x7708c34e[m in [33mgst_element_change_state[m () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #17 [34m0x7708ca8d[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #18 [34m0x7706995c[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #19 [34m0x770b5909[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #20 [34m0x7708c34e[m in [33mgst_element_change_state[m () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #21 [34m0x7708ca8d[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
> #22 [34m0x77f78d6d[m in [33mcheese_camera_play[m () at 
> [32m/lib/x86_64-linux-gnu/libcheese.so.8[m
> #23 [34m0x55560536[m in  ()
> #24 [34m0x55560770[m in  ()
> #25 [34m0x774302ee[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
> #26 [34m0x77448a48[m in [33mg_signal_emit_valist[m () at 
> [32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
> #27 [34m0x77448c3f[m in [33mg_signal_emit[m () at 
> [32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
> #28 [34m0xf087[m in  ()
> #29 [34m0x774f7c15[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgio-2.0.so.0[m
> #30 [34m0x774302ee[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
> #31 [34m0x77447df9[m in [33mg_signal_emit_valist[m () at 
> [32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
> #32 [34m0x77448c3f[m in [33mg_signal_emit[m () at 
> [32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
> #33 [34m0x77552aa3[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgio-2.0.so.0[m
> #34 [34m0x77555329[m in  () at 
> [32m/lib/x86_64-linux-gnu/libgio-2.0.so.0[m
> #35 [34m0x775554ae[m in [33mg_application_run[m () at 
> [32m/lib/x86_64-linux-gnu/libgio-2.0.so.0[m
> #36 [34m0x55561a53[m in  ()
> #37 [34m0x76e83d0a[m in [33m__libc_start_main[m 
> (main=0xea60, argc=1, argv=0x7fffdda8, init=, 
> fini=, rtld_fini=, 
> stack_end=0x7fffdd98) at [32m
> ../csu/libc-start.c[m:308
> #38 [34m0xea9a[m in  ()
> 
> 
> regards
> 
> Armin
> 

-- 
http://www.cb-fraggle.de

Crash on starting cheese

[akallabeth]

Hi,


I´ve just experienced the following crash on starting cheese on my 
installation.


Since I´m not sure where to report the but I´m asking on this list for help.


Camera device is:

Bus 001 Device 007: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera


Here a stack trace:

[?2004h[?2004l[?2004h(gdb) bt
#0  [33m__GI_raise[m (sig=sig@entry=6) at 
[32m../sysdeps/unix/sysv/linux/raise.c[m:50

#1  [34m0x76e82537[m in [33m__GI_abort[m () at [32mabort.c[m:79
#2  [34m0x7fff94b472cd[m in 
[33mlibcamera::LogMessage::~LogMessage()[m () at 
[32m/lib/x86_64-linux-gnu/libcamera.so.0[m
#3  [34m0x7fff94b3e371[m in 
[33mlibcamera::IPAManager::IPAManager()[m () at 
[32m/lib/x86_64-linux-gnu/libcamera.so.0[m
#4  [34m0x7fff94b13d73[m in 
[33mlibcamera::CameraManager::Private::Private(libcamera::CameraManager*)[m 
() at [32m/lib/x86_64-linux-gnu/libcamera.so.0[m
#5  [34m0x7fff94b1470c[m in 
[33mlibcamera::CameraManager::CameraManager()[m () at 
[32m/lib/x86_64-linux-gnu/libcamera.so.0[m
#6  [34m0x7fff94c0bc4d[m in  () at 
[32m/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibcamera.so[m
#7  [34m0x7708c34e[m in [33mgst_element_change_state[m () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#8  [34m0x7708ca8d[m in  () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#9  [34m0x7706995c[m in  () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#10 [34m0x7708c34e[m in [33mgst_element_change_state[m () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#11 [34m0x7708ca8d[m in  () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#12 [34m0x7fff94bee56f[m in  () at 
[32m/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so[m
#13 [34m0x7fff94bf06a3[m in  () at 
[32m/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so[m
#14 [34m0x7fff94be18c5[m in  () at 
[32m/lib/x86_64-linux-gnu/libgstbasecamerabinsrc-1.0.so.0[m
#15 [34m0x7fff94beee08[m in  () at 
[32m/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcamerabin.so[m
#16 [34m0x7708c34e[m in [33mgst_element_change_state[m () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#17 [34m0x7708ca8d[m in  () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#18 [34m0x7706995c[m in  () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#19 [34m0x770b5909[m in  () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#20 [34m0x7708c34e[m in [33mgst_element_change_state[m () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#21 [34m0x7708ca8d[m in  () at 
[32m/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0[m
#22 [34m0x77f78d6d[m in [33mcheese_camera_play[m () at 
[32m/lib/x86_64-linux-gnu/libcheese.so.8[m

#23 [34m0x55560536[m in  ()
#24 [34m0x55560770[m in  ()
#25 [34m0x774302ee[m in  () at 
[32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
#26 [34m0x77448a48[m in [33mg_signal_emit_valist[m () at 
[32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
#27 [34m0x77448c3f[m in [33mg_signal_emit[m () at 
[32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m

#28 [34m0xf087[m in  ()
#29 [34m0x774f7c15[m in  () at 
[32m/lib/x86_64-linux-gnu/libgio-2.0.so.0[m
#30 [34m0x774302ee[m in  () at 
[32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
#31 [34m0x77447df9[m in [33mg_signal_emit_valist[m () at 
[32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
#32 [34m0x77448c3f[m in [33mg_signal_emit[m () at 
[32m/lib/x86_64-linux-gnu/libgobject-2.0.so.0[m
#33 [34m0x77552aa3[m in  () at 
[32m/lib/x86_64-linux-gnu/libgio-2.0.so.0[m
#34 [34m0x77555329[m in  () at 
[32m/lib/x86_64-linux-gnu/libgio-2.0.so.0[m
#35 [34m0x775554ae[m in [33mg_application_run[m () at 
[32m/lib/x86_64-linux-gnu/libgio-2.0.so.0[m

#36 [34m0x55561a53[m in  ()
#37 [34m0x76e83d0a[m in [33m__libc_start_main[m 
(main=0xea60, argc=1, argv=0x7fffdda8, init=, 
fini=, rtld_fini=, 
stack_end=0x7fffdd98) at [32m

../csu/libc-start.c[m:308
#38 [34m0xea9a[m in  ()


regards

Armin

Subject: sync sync, was Re: Problem with crash post-install

[Charlie Gibbs]

On Fri Jul 30 10:11:24 2021 "Thomas Schmitt"  wrote:

> to...@tuxteam.de wrote:
>
>>> While I've read about issuing sync *twice* with the explanation
>>> that sysadmins are a supersticious bunch
>
> Polyna-Maude Racicot-Summerside wrote:
>
>> I'm really asking why do it 3 time.
>> In case it came back to the prompt *before* finishing to do it's job
>
> I dimly remember that it was part of the shutdown procedure of one
> of the earliest Unix machines which i met. IBM RT, Apollo DN3000, > > 
> microVAX ... ?

> The shutdown spell was something like
>
>  sync ; sync ; halt
>
> Googling "sync halt" leads me to an interesting theory at
>  https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
>
> According to section "That sync; sync; sync Thing..." two bugs of
> early systems' sync existed (one explored by the blog's author,
> one as rumor):
>
> 1: The sync system call returned without waiting.
>Workaround:
>Keep the human operator busy while the machine is still not done
>with flushing buffers. E.g. prescribe to type three lines of
>"sync" before typing "halt".
>
> 2: Only the first sync call returned early, whereas the second sync
>properly blocked until flushing was done.
>That seems to be the origin of my memory.

I fed "multiple sync commands" into DuckDuckGo, and got the
following hit, which is even nicer:

https://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync

Basically, the act of typing three sync commands, each on a
separate line (as opposed to "sync ; sync ; sync"), gives the
system enough time for the first sync command to do its thing.

Or, as Tony Orlando once sang:

Sync three times on the console if you want me.
Close all the pipes if the answer is no.

Just remember, things could be worse - and if Microsoft
is involved, they usually are.  I first noticed a "feature"
in Windows 95 which persists to this day: requests to delete
a file are queued, and done when Windows gets around to it.
This means that if your program issues an unlink(), the
file might still be there when the call returns.  Thus,
the old trick of updating a file by copying it to a work
file while making changes, deleting the original file, and
renaming the work file to the original file's name runs the
risk of failure if the deletion doesn't take effect before
the rename, which will then fail.  It doesn't happen often,
but if you have a program that's run daily by a couple of
thousand users, even a .01% chance of failure means that
your support staff will get several anguished calls a week
from customers who have lost critical files.  (It happens
with batch files too.)

--
/~\  Charlie Gibbs  |  Microsoft is a dictatorship.
\ /|  Apple is a cult.
 X   I'm really at ac.dekanfrus |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

Re: Problem with crash post-install [ was: Update or reinstall ]

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-29 3:13 p.m., David Wright wrote:

> 
> I realise that we're not all receiving posts from Gunnar, but do we
> actually know what the "update problem" is?
> 
> I recall:
> https://lists.debian.org/debian-user/2021/07/msg01003.html
> Is this the origin of the system under discussion?
> 
> Or is this?
> https://lists.debian.org/debian-user/2021/07/msg00945.html
> 
> Then we have:
> https://lists.debian.org/debian-user/2021/07/msg01167.html
> Do we know what is meant by "crashing"?
> 
> In between, we have snippets on Grub, bash, busybox, keyboards,
> root partition flags, and more; none of it in a coherent thread.
> Quite honestly, I don't know where syncing the filesystem comes in.
> Why not just touch wood.
> 
> Cheers,
> David.
> 
> The sync filesystem comes for a suggestion.
Sync before update and after update.
3 sync in all so I don't remember what was the 3rd one.

But yes, it's quite messy all of this !

And like you mentioned, we don't even know if it's a Debian or what type.

When I read something like this...

On 2021-07-28 3:16 p.m., Gunnar Gervin wrote:
> It is a Toshiba 160 gb hd in a 14 years old Macbook i386 ❤️/x86 32 b
> booting from Bios not uefi. I'll give full report in 1-2 weeks, after
> put in VM in it, faster internet to it to handle VM.
> And built websites with it.
> Geg

*I get really confused...*

And when you post

In all of Gunnar's posts, I think I have only seen one report of actual
output posted, and I have no idea what the origin of that was, viz:

  # UNCONFIGURED FSTAB FOR BASE SYSTEM
  overlay / overlay rw 0 0
  tmpfs /tmp tmpfs nosuid,nodev 0 0
  /dev/sda1 /mnt/sda1 EXT2 nosuid,nodev,nofail,x-gvfs-show 0 0
  /dev/sda3 /mnt/sda3 EXT2
nosuid,nodev,nofail,x-gvfs-show,noauto,x-udisks-auth 0 0
  /dev/sda2 none swap sw,x-udisks-auth,noauto 0 0

*It doesn't help much ! And you ain't to blame...*
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Problem with crash post-install [ was: Update or reinstall ]

[David Wright]

On Thu 29 Jul 2021 at 18:09:51 (+0200), Marco Möller wrote:
> On 29.07.21 12:52, Polyna-Maude Racicot-Summerside wrote:
> > I'm really asking why do it 3 time.
> > In case it came back to the prompt *before* finishing to do it's job ?
> > (...)
> Misunderstanding: I wanted to suggest to run a "sudo sync" (1) before
> and (2) after the update and (3) before the system shutdown, in order
> to exclude that data wasn't fully written to disk at possible critical
> moments. This in total are three different situations when I suggest
> to run the sync command, and in all this three different situations it
> shall be run, thus running it three times (in total three times, not
> triple repeated in one of the situations).

It doesn't actually matter in the first two cases whether the data has
been written to the device itself, as the filesystem access methods
won't allow you to read from the device, but you will receive the
up to date buffer contents instead.

> By the way, running it as "sudo" is not harming and makes sure that
> everything is written to disk without having to know if the sync
> command would behave different with and without the sudo.

You're presupposing that everyone is using the same superuser access
method. Many people will merely get the response:

$ sudo sync
Sorry, user foo is not allowed to execute '/usr/bin/sync' as root on bar.
$ 

> The point
> is, you want to debug a situation, you want to find out why an update
> is failing so severely and not reported to fail like this elsewhere,
> and sudo will not harm for this purpose while not using sudo could
> have left doubts if really all is written to disk - pragmatically
> focusing on problem solving without maybe producing more problems and
> without loosing time to construct a most elegant version of problem
> solving. Just get the problem solved!
> I am curious to read if the "sudo sync" runs solved the update problem.

I realise that we're not all receiving posts from Gunnar, but do we
actually know what the "update problem" is?

I recall:
https://lists.debian.org/debian-user/2021/07/msg01003.html
Is this the origin of the system under discussion?

Or is this?
https://lists.debian.org/debian-user/2021/07/msg00945.html

Then we have:
https://lists.debian.org/debian-user/2021/07/msg01167.html
Do we know what is meant by "crashing"?

In between, we have snippets on Grub, bash, busybox, keyboards,
root partition flags, and more; none of it in a coherent thread.
Quite honestly, I don't know where syncing the filesystem comes in.
Why not just touch wood.

Cheers,
David.

Re: sync sync, was Re: Problem with crash post-install

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-29 7:35 a.m., Thomas Schmitt wrote:
> Hi,
> 
> to...@tuxteam.de wrote:
>>> While I've read about issuing sync *twice* with the explanation
>>> that sysadmins are a supersticious bunch
> 
> Polyna-Maude Racicot-Summerside wrote:
>> I'm really asking why do it 3 time.
>> In case it came back to the prompt *before* finishing to do it's job ?
> 
> I dimly remember that it was part of the shutdown procedure of one of
> the earliest Unix machines which i met. IBM RT, Apollo DN3000, microVAX ... ?
> The shutdown spell was something like
> 
Sorry, I'm too young for IBM RT, HP Apollo DN3000 or any type of VAX
(except in a emulator).
>   sync ; sync ; halt
> 
> Googling "sync halt" leads me to an interesting theory at
>   https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
> 
> According to section "That sync; sync; sync Thing..." two bugs of early
> systems' sync existed (one explored by the blog's author, one as rumor):
> 
> 1: The sync system call returned without waiting.
>Workaround:
>Keep the human operator busy while the machine is still not done with
>flushing buffers. E.g. prescribe to type three lines of "sync" before
>typing "halt".
> 
> 2: Only the first sync call returned early, whereas the second sync
>properly blocked until flushing was done.
>That seems to be the origin of my memory.
> 
> 
Thanks for this bit of history :)
> Have a nice day :)
> 
> Thomas
> 

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: Problem with crash post-install [ was: Update or reinstall ]

[Marco Möller]

On 29.07.21 12:52, Polyna-Maude Racicot-Summerside wrote:

Hi,

On 2021-07-29 6:48 a.m., to...@tuxteam.de wrote:

On Thu, Jul 29, 2021 at 12:29:16PM +0200, Marco Möller wrote:


On 29.07.21 10:25, Polyna-Maude Racicot-Summerside wrote:

Hi,
(...)
Gunnar  ( Gunnar Gervin  ) is having problem with
his laptop.
The system crashes post-update.

He need to do clean install every time.
And this is probably time consuming for him.

If other user has some hints...



[...] three times run a "sudo sync" [...]


While I've read about issuing sync *twice* with the explanation
that sysadmins are a supersticious bunch [1], the sudo is most
definitely unnecessary.

I think the running twice is also a bit of a too much extra.

I'm really asking why do it 3 time.
In case it came back to the prompt *before* finishing to do it's job ?
(...)
Misunderstanding: I wanted to suggest to run a "sudo sync" (1) before 
and (2) after the update and (3) before the system shutdown, in order to 
exclude that data wasn't fully written to disk at possible critical 
moments. This in total are three different situations when I suggest to 
run the sync command, and in all this three different situations it 
shall be run, thus running it three times (in total three times, not 
triple repeated in one of the situations).
By the way, running it as "sudo" is not harming and makes sure that 
everything is written to disk without having to know if the sync command 
would behave different with and without the sudo. The point is, you want 
to debug a situation, you want to find out why an update is failing so 
severely and not reported to fail like this elsewhere, and sudo will not 
harm for this purpose while not using sudo could have left doubts if 
really all is written to disk - pragmatically focusing on problem 
solving without maybe producing more problems and without loosing time 
to construct a most elegant version of problem solving. Just get the 
problem solved!

I am curious to read if the "sudo sync" runs solved the update problem.
Good Luck! Marco.

Re: Problem with crash post-install [ was: Update or reinstall ]

[songbird]

Dan Ritter wrote:
...
> There are situations in which it can take much longer than a few
> seconds. They require a large amount of data to write and a slow
> storage mechanism.
>
> Specific example: recursive copying of music files to my USB-2
> attached music player, which has an actual write speed of about
> 20 MB per second. The cp -r or rsync of a few gigabytes can
> return well before the data is actually written.

  i have a pretty large io buffer so when i copy some big files
and then sync it may take as long as 30 or more seconds even 
with a decent SSD.


  songbird

Re: Problem with crash post-install [ was: Update or reinstall ]

[Dan Ritter]

Greg Wooledge wrote: 
>  which says:
> 
>   On Linux, sync is only guaranteed to schedule the dirty blocks for
>   writing; it can actually take a short time before all the blocks are
>   finally written. The reboot(8) and halt(8) commands take this into
>   account by sleeping for a few seconds after calling sync(2).

There are situations in which it can take much longer than a few
seconds. They require a large amount of data to write and a slow
storage mechanism.

Specific example: recursive copying of music files to my USB-2
attached music player, which has an actual write speed of about
20 MB per second. The cp -r or rsync of a few gigabytes can
return well before the data is actually written.

-dsr-

Re: Problem with crash post-install [ was: Update or reinstall ]

[Greg Wooledge]

On Thu, Jul 29, 2021 at 06:52:37AM -0400, Polyna-Maude Racicot-Summerside wrote:
> As far as I know, sync doesn't work in the background !

On many systems, it does.  I can't even find a clear statement in the
bullseye sync(1) man page of whether it does or not.

The bullseye sync(1) comes from GNU coreutils 8.32.

Googling turns up a different sync(8) page,
 which says:

  On Linux, sync is only guaranteed to schedule the dirty blocks for
  writing; it can actually take a short time before all the blocks are
  finally written. The reboot(8) and halt(8) commands take this into
  account by sleeping for a few seconds after calling sync(2).

That man page claims to be from fileutils-4.0.

On bullseye, sync(2) says:

   According to the standard specification  (e.g.,  POSIX.1-2001),  sync()
   schedules the writes, but may return before the actual writing is done.
   However Linux waits for I/O completions, and thus  sync()  or  syncfs()
   provide the same guarantees as fsync() called on every file in the sys‐
   tem or filesystem respectively.

So, even on Linux systems, it would appear the behavior has varied
over time.  On non-Linux systems, I would expect a high probability
that the sync(8) or sync(1) command returns immediately, without
waiting for the synchronization to complete.

sync sync, was Re: Problem with crash post-install

[Thomas Schmitt]

Hi,

to...@tuxteam.de wrote:
> > While I've read about issuing sync *twice* with the explanation
> > that sysadmins are a supersticious bunch

Polyna-Maude Racicot-Summerside wrote:
> I'm really asking why do it 3 time.
> In case it came back to the prompt *before* finishing to do it's job ?

I dimly remember that it was part of the shutdown procedure of one of
the earliest Unix machines which i met. IBM RT, Apollo DN3000, microVAX ... ?
The shutdown spell was something like

  sync ; sync ; halt

Googling "sync halt" leads me to an interesting theory at
  https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html

According to section "That sync; sync; sync Thing..." two bugs of early
systems' sync existed (one explored by the blog's author, one as rumor):

1: The sync system call returned without waiting.
   Workaround:
   Keep the human operator busy while the machine is still not done with
   flushing buffers. E.g. prescribe to type three lines of "sync" before
   typing "halt".

2: Only the first sync call returned early, whereas the second sync
   properly blocked until flushing was done.
   That seems to be the origin of my memory.


Have a nice day :)

Thomas

Re: Problem with crash post-install [ was: Update or reinstall ]

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-29 6:48 a.m., to...@tuxteam.de wrote:
> On Thu, Jul 29, 2021 at 12:29:16PM +0200, Marco Möller wrote:
>>
>> On 29.07.21 10:25, Polyna-Maude Racicot-Summerside wrote:
>>> Hi,
>>> (...)
>>> Gunnar  ( Gunnar Gervin  ) is having problem with
>>> his laptop.
>>> The system crashes post-update.
>>>
>>> He need to do clean install every time.
>>> And this is probably time consuming for him.
>>>
>>> If other user has some hints...
> 
>> [...] three times run a "sudo sync" [...]
> 
> While I've read about issuing sync *twice* with the explanation
> that sysadmins are a supersticious bunch [1], the sudo is most
> definitely unnecessary.
I think the running twice is also a bit of a too much extra.

I'm really asking why do it 3 time.
In case it came back to the prompt *before* finishing to do it's job ?

As far as I know, sync doesn't work in the background !
> 
> The important part is actually /waiting/ for sync to "come back".
> Then you can assume that pending writes are committed.
> 
That's a fact
> Cheers
> [1] A dash of superstition might even be beneficial in that
>kind of job.
>  - t
> 
This reassure me that I ain't the only one who find it a bit frivolous
to run sync 3 time in a row. This is not like making love, where there's
much pleasure to do so once after another.

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: Problem with crash post-install [ was: Update or reinstall ]

[tomas]

On Thu, Jul 29, 2021 at 12:29:16PM +0200, Marco Möller wrote:
> 
> On 29.07.21 10:25, Polyna-Maude Racicot-Summerside wrote:
> >Hi,
> >(...)
> >Gunnar  ( Gunnar Gervin  ) is having problem with
> >his laptop.
> >The system crashes post-update.
> >
> >He need to do clean install every time.
> >And this is probably time consuming for him.
> >
> >If other user has some hints...

> [...] three times run a "sudo sync" [...]

While I've read about issuing sync *twice* with the explanation
that sysadmins are a supersticious bunch [1], the sudo is most
definitely unnecessary.

The important part is actually /waiting/ for sync to "come back".
Then you can assume that pending writes are committed.

Cheers
[1] A dash of superstition might even be beneficial in that
   kind of job.
 - t


signature.asc
Description: Digital signature

Re: Problem with crash post-install [ was: Update or reinstall ]

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-29 6:29 a.m., Marco Möller wrote:
> 
> On 29.07.21 10:25, Polyna-Maude Racicot-Summerside wrote:
>> Hi,
>> (...)
>> Gunnar  ( Gunnar Gervin  ) is having problem with
>> his laptop.
>> The system crashes post-update.
>>
>> He need to do clean install every time.
>> And this is probably time consuming for him.
>>
>> If other user has some hints...
> 
> Without having all the mail thread available and not being able to see
> what suggestions and tests have already been done, my first idea and
> suggestion would be to care to three times run a "sudo sync" (1) before
> and (2) after the update and (3) before the system shutdown, in order to
> exclude that data wasn't fully written to disk at possible critical
> moments. If this would help, then investigations could accordingly
> continue to concentrate on related configurations.
> Good Luck! Marco.
> 
There's no other mail thread related to this...
Only the original user (Gunnar) who said to me that I shall do clean
install on updates because his system crashes if he tries to updates.

So I told him that this was painstaking and time consuming, that backups
are indeed a good thing but that you shouldn't need to reinstall every
time you update.

So I've suggested him that he post the system configuration onto the
mailing system so we may help him out (fellow user on the list).

Now considering the way he described his computer installation, I
believe it may be much more complex to solve whatever problem it is than
trying to go take a trip to the planet Mars, no, wait, Jupiter would be
closer to the efforts needed.

In his description he mentions waiting for a better Internet connection
so his virtual machine will run faster or something alike that I don't
quite understand.

So maybe he's running under a VM.
Also, said to be running a Macbook with a BIOS and that is totally
strange to myself...

So the best thing to do (I believe) would be...

I'd start by asking him to use hwinfo... and send a dump.

Steps :
Install package hwinfo
Run hwinfo --all --log laptop.log
Copy the content of laptop.log into your message.
You can use gedit or geany to open the file.

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

cc: Gunnar Gervin



OpenPGP_signature
Description: OpenPGP digital signature

Re: Problem with crash post-install [ was: Update or reinstall ]

[Marco Möller]

On 29.07.21 10:25, Polyna-Maude Racicot-Summerside wrote:

Hi,
(...)
Gunnar  ( Gunnar Gervin  ) is having problem with
his laptop.
The system crashes post-update.

He need to do clean install every time.
And this is probably time consuming for him.

If other user has some hints...


Without having all the mail thread available and not being able to see 
what suggestions and tests have already been done, my first idea and 
suggestion would be to care to three times run a "sudo sync" (1) before 
and (2) after the update and (3) before the system shutdown, in order to 
exclude that data wasn't fully written to disk at possible critical 
moments. If this would help, then investigations could accordingly 
continue to concentrate on related configurations.

Good Luck! Marco.

Problem with crash post-install [ was: Update or reinstall ]

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-29 3:25 a.m., Gunnar Gervin wrote:
> The *link* is your request of it.
> Geg
> 
> On Thu, 29 Jul 2021, 00:25 Polyna-Maude Racicot-Summerside,
> mailto:deb...@polynamaude.com>> wrote:
> 
> Hi,
> 
> On 2021-07-28 3:16 p.m., Gunnar Gervin wrote:
> > It is a Toshiba 160 gb hd in a 14 years old Macbook i386 ❤️/x86 32 b
> > booting from Bios not uefi. I'll give full report in 1-2 weeks, after
> > put in VM in it, faster internet to it to handle VM.
> > And built websites with it.
> > Geg
> 
Gunnar  ( Gunnar Gervin  ) is having problem with
his laptop.
The system crashes post-update.

He need to do clean install every time.
And this is probably time consuming for him.

If other user has some hints...

> What's the link between installing a VM and the description of your
> laptop ?
> 
> Also, Macbook in x86 booting from BIOS ?
> 
> Macbook use either UEFI for the Intel ones or OpenBoot for the older
> ones.
> 
> No such thing as a BIOS on a MacBook.
> 
> Sorry but your message is everything except easy to understand.
> 
> If you are installing Linux in a VM on your laptop then you should also
> describe what type of VM you are using and the specifications. Your
> Friend Linux should have taught you this. Also, he should teach you that
> a faster internet won't make your VM faster.
> 
> Maybe you could either answer a message or include in this one, what
> reason are you writing this ?
> 
> As it may sound obvious for yourself, it's not necessarily for others.
> Plus it's not much of use for someone who'd like into to the archive
> looking for answer.
> 
> If I do get a idea of why you are writing this here, it's not the case
> for other people around.
> 
> Same apply for your message regarding Pine laptop.
> 
> Because now those two message are like a bottle in the ocean, not linked
> to anything.
> 
> -- 
> Polyna-Maude R.-Summerside
> -Be smart, Be wise, Support opensource development
> 

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: Gimp Crash debug

[Camaleón]

El 2020-12-21 a las 15:03 -0300, S P escribió:

(...)

> > fatal error: Excepción de coma flotante
> 
> Stack trace:
> ```
> /lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397)[0x7fc21a756e27]
> gimp-2.10(+0xd14a0)[0x5640ac7c04a0]
> gimp-2.10(+0xd18d8)[0x5640ac7c08d8]
> gimp-2.10(+0xd2037)[0x5640ac7c1037]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x3413c12730)[0x7fc219a5e730]
> gimp-2.10(+0x44397f)[0x5640acb3297f]
> gimp-2.10(+0x443c28)[0x5640acb32c28]
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7fc219c42dd8]
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4e1c8)[0x7fc219c431c8]
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7fc219c434c2]
> gimp-2.10(gimp_plug_in_manager_call_run+0x5ff)[0x5640aca67cef]
> gimp-2.10(+0x37182e)[0x5640aca6082e]
> gimp-2.10(gimp_procedure_execute+0x219)[0x5640aca540c9]
> gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1f9)[0x5640aca4d609]
> gimp-2.10(gimp_pdb_execute_procedure_by_name+0x3cb)[0x5640aca4dacb]
> gimp-2.10(file_open_image+0x34a)[0x5640acb4ca2a]
> gimp-2.10(file_open_with_proc_and_display+0x2a5)[0x5640acb4d975]
> gimp-2.10(file_open_from_command_line+0x1ad)[0x5640acb4e1cd]
> gimp-2.10(app_run+0x2ec)[0x5640ac7bfc4c]
> gimp-2.10(main+0x395)[0x5640ac7bf5b5]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fc2198ad09b]
> gimp-2.10(_start+0x2a)[0x5640ac7bf73a]

GIMP crash with floating point exception on image save.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948380

Saludos,

-- 
Camaleón 

Gimp Crash debug

[S P]

```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-13)

using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.58.3 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Excepción de coma flotante

Stack trace:
```
/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397)[0x7fc21a756e27]
gimp-2.10(+0xd14a0)[0x5640ac7c04a0]
gimp-2.10(+0xd18d8)[0x5640ac7c08d8]
gimp-2.10(+0xd2037)[0x5640ac7c1037]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x3413c12730)[0x7fc219a5e730]
gimp-2.10(+0x44397f)[0x5640acb3297f]
gimp-2.10(+0x443c28)[0x5640acb32c28]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7fc219c42dd8]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4e1c8)[0x7fc219c431c8]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7fc219c434c2]
gimp-2.10(gimp_plug_in_manager_call_run+0x5ff)[0x5640aca67cef]
gimp-2.10(+0x37182e)[0x5640aca6082e]
gimp-2.10(gimp_procedure_execute+0x219)[0x5640aca540c9]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1f9)[0x5640aca4d609]
gimp-2.10(gimp_pdb_execute_procedure_by_name+0x3cb)[0x5640aca4dacb]
gimp-2.10(file_open_image+0x34a)[0x5640acb4ca2a]
gimp-2.10(file_open_with_proc_and_display+0x2a5)[0x5640acb4d975]
gimp-2.10(file_open_from_command_line+0x1ad)[0x5640acb4e1cd]
gimp-2.10(app_run+0x2ec)[0x5640ac7bfc4c]
gimp-2.10(main+0x395)[0x5640ac7bf5b5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fc2198ad09b]
gimp-2.10(_start+0x2a)[0x5640ac7bf73a]

```

RE: Sid random crash with no clue in log files

[Leandro neto]

 
Hi guys sorry form any inconvenience I would like to report what i am thinking a severe security vulnerability that affects all Debian based distros. it was on python 3 files  i am sending a link to every malign list that i am subscribed. IAM NOT A PROFESSIONAL. FELL FREE TO REMOTE ACCESS MY MACHINES ANYTIME. if i am wrong my apology. but i think on my little knowledge certain has something in there. There is a lot of files on the link. I am trying to upload the raw files. but every distro brakes. it shows 140.7 tbTB!!! yes 104000 gbt that fits on a flash drive of 32gb is is very difficult to me to use interment. am being hunting down. so this is my last try. contact only by phone number. because the monitored and listen everything mine.  is like a movie but is true.+552122366155 +552121796156 sorry but i don't know to tell this to anyone. because they don't believe.
link with the photos this is the link for linux distros  https://photos.app.goo.gl/oHRP5Z8JEoT9Q4GN9

link for the other systems osx windows andorid... 

https://photos.app.goo.gl/BsBCuYtVtE4VwGUC9
 
this is the link of the windows apple etc...

best regards leandro leme neto



De: to...@tuxteam.de
Enviada: 2020/10/28 14:00:50
Para: debian-user@lists.debian.org
Assunto:  Re: Sid random crash with no clue in log files

On Wed, Oct 28, 2020 at 04:09:33PM +0100, Sébastien Kalt wrote:
> Hello,
>
> I'm having random crashes on my ASUS PN50 mini PC : sometimes it's while
> copying large files through network, sometimes when watching a youtube
> video, sometimes juste using LibreOffice, or going nothing ...
>
> I can't manage to have a pattern for thoses craches. Today it craches 4
> times, the last week it didn't crash.
>
> I encoded a video with 100 % CPU charge during one hour and it didn't crash.
>
> When I look at the log files, I see nothing : syslog, messages, daemon.log,
> kern.log, Xorg.0.log.old, dmesg
>
> When it crashes, the system seems to be not responding, I can move the
> mouse, but it doesn't click, and then the screen becomes blank. I need to
> shut down the mini PC pushing the power button for a long time.
>
> When I restart it, I don't see anything during the reboot (well, it's quite
> fast, so I might miss something).
>
> Do you have any suggestions to find what might be causing this ?

If the mouse still moves, I'd look first into software. Try to log
into your machine either with a Linux console (CTRL-ALT+F1 or some
other function key) or via ssh, as linux fan suggests.

Try to locate some central gui program which might be misbehaving
and kill it (gnome-panel or some such).

If it were a hardware problem, the machine would most probably
freeze completely or at least show non-repeatable symptoms.

Cheers
- t

Re: Sid random crash with no clue in log files

[tomas]

On Wed, Oct 28, 2020 at 04:09:33PM +0100, Sébastien Kalt wrote:
> Hello,
> 
> I'm having random crashes on my ASUS PN50 mini PC : sometimes it's while
> copying large files through network, sometimes when watching a youtube
> video, sometimes juste using LibreOffice, or going nothing ...
> 
> I can't manage to have a pattern for thoses craches. Today it craches 4
> times, the last week it didn't crash.
> 
> I encoded a video with 100 % CPU charge during one hour and it didn't crash.
> 
> When I look at the log files, I see nothing : syslog, messages, daemon.log,
> kern.log, Xorg.0.log.old, dmesg
> 
> When it crashes, the system seems to be not responding, I can move the
> mouse, but it doesn't click, and then the screen becomes blank. I need to
> shut down the mini PC pushing the power button for a long time.
> 
> When I restart it, I don't see anything during the reboot (well, it's quite
> fast, so I might miss something).
> 
> Do you have any suggestions to find what might be causing this ?

If the mouse still moves, I'd look first into software. Try to log
into your machine either with a Linux console (CTRL-ALT+F1 or some
other function key) or via ssh, as linux fan suggests.

Try to locate some central gui program which might be misbehaving
and kill it (gnome-panel or some such).

If it were a hardware problem, the machine would most probably
freeze completely or at least show non-repeatable symptoms.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Sid random crash with no clue in log files

[Charles Curley]

On Wed, 28 Oct 2020 16:09:33 +0100
Sébastien Kalt  wrote:

> I'm having random crashes on my ASUS PN50 mini PC : sometimes it's
> while copying large files through network, sometimes when watching a
> youtube video, sometimes juste using LibreOffice, or going nothing ...

> Do you have any suggestions to find what might be causing this ?

I suspect something, likely RAM, isn't properly seated. I would: remove
and re-seat any socketed ICs, and any daughter boards. Replug all
cables.

Install and run memtest86 for several hours.

If you have played with hardware settings in the BIOS, set them back to
factory values.

-- 
Does anybody read signatures any more?

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

Re: Sid random crash with no clue in log files

[Linux-Fan]

Sébastien Kalt writes:


Hello,

I'm having random crashes on my ASUS PN50 mini PC : sometimes it's while  


[...]

When it crashes, the system seems to be not responding, I can move the mouse,  
but it doesn't click, and then the screen becomes blank. I need to shut down  
the mini PC pushing the power button for a long time.


[...]

Hello,

common things to test in case of random crashes are hardware-related issues  
like cooling (CPU temperatures?), power supply and RAM (memtest86+).


Another thing to debug is: While the system is in the described crash state,  
you can still move the mouse -- this means some software on the system  
remains running despite not being accessible through GUI. An interesting  
step could be to attempt a login through SSH (install openssh-server if not  
already there to enable SSH access). From that SSH login you might be able  
to call a tool like `htop` to check the state of the system and stop any  
rouge processes etc.


I used to have similar types of crashes (the screen never went black, but  
the mouse cursor would move with any further inputs like klicks and key  
presses ignored) on a system with VirtualBox and the NVidia proprietary GPU  
driver (must have been Debian 7 or 8 IIRC). If either VirtualBox or NVidia  
graphics driver were uninstalled, it would never crash that way... In any  
case, logging in through SSH, I could see that the Xorg process was at 100%  
CPU. Killing it caused the screen to go black. Attempting to re-start would  
fail in some way, but afterwards a login from the local system would again  
be possible and the hard reset could be avoided...


HTH
Linux-Fan

öö


pgpIWNhCGmk3b.pgp
Description: PGP signature

Sid random crash with no clue in log files

[Sébastien Kalt]

Hello,

I'm having random crashes on my ASUS PN50 mini PC : sometimes it's while
copying large files through network, sometimes when watching a youtube
video, sometimes juste using LibreOffice, or going nothing ...

I can't manage to have a pattern for thoses craches. Today it craches 4
times, the last week it didn't crash.

I encoded a video with 100 % CPU charge during one hour and it didn't crash.

When I look at the log files, I see nothing : syslog, messages, daemon.log,
kern.log, Xorg.0.log.old, dmesg

When it crashes, the system seems to be not responding, I can move the
mouse, but it doesn't click, and then the screen becomes blank. I need to
shut down the mini PC pushing the power button for a long time.

When I restart it, I don't see anything during the reboot (well, it's quite
fast, so I might miss something).

Do you have any suggestions to find what might be causing this ?

Regards,

Sébastien

Re: GIMP Crash

[황병희]

Ryan Young  writes:

> Here is the bug info
>
> ```
> GNU Image Manipulation Program version 2.10.8

In that case, if you are in Debian, you would be send bug report.
So that the maintainer can be know what problem is.

https://www.debian.org/Bugs/Reporting

Actually, you must add contain keywords "Package" and "Version" ;;;

Sincerely, Byung-Hee

-- 
^고맙습니다 _白衣從軍_ 감사합니다_^))//

GIMP Crash

[Ryan Young]

Here is the bug info

```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-13)

using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.58.3 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 16588 - Thread 16588 #

[New LWP 16589]
[New LWP 16590]
[New LWP 16592]
[New LWP 16593]
[New LWP 16605]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffd5bc55ed0, fd=16) at
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame
* 1Thread 0x7a5aacd05e00 (LWP 16588) "gimp-2.10"   __libc_read
(nbytes=256, buf=0x7ffd5bc55ed0, fd=16) at
../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7a5aab4ad700 (LWP 16589) "gmain"   0x7a5aae982819
in __GI___poll (fds=0x581ef2edf1c0, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  3Thread 0x7a5aaa957700 (LWP 16590) "gdbus"   0x7a5aae982819
in __GI___poll (fds=0x581ef2eb76a0, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  4Thread 0x7a5a97ac8700 (LWP 16592) "async"   syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7a5a972c7700 (LWP 16593) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7a5a95e51700 (LWP 16605) "swap writer" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 6 (Thread 0x7a5a95e51700 (LWP 16605)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1  0x7a5aaec97f9f in g_cond_wait () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x7a5aaf3310cd in ?? () from
/usr/lib/x86_64-linux-gnu/libgegl-0.4.so.0
No symbol table info available.
#3  0x7a5aaec76415 in ?? () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x7a5aaea5efa3 in start_thread (arg=) at
pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {134529480464128,
4780554623439464532, 140726143112750, 140726143112751, 134529480464128,
96889976575168, -5268408010271233964, -5268459145313916844}, mask_was_saved
= 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup =
0x0, canceltype = 0}}}
not_first_call = 
#5  0x7a5aae98d4cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

Thread 5 (Thread 0x7a5a972c7700 (LWP 16593)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1  0x7a5aaec97f9f in g_cond_wait () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x581ef15b6423 in ?? ()
No symbol table info available.
#3  0x7a5aaec76415 in ?? () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x7a5aaea5efa3 in start_thread (arg=) at
pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {134529501918976,
4780554623439464532, 140726143118094, 140726143118095, 134529501918976,
96889925393344, -5268403142999545772, -5268459145313916844}, mask_was_saved
= 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup =
0x0, canceltype = 0}}}

Re: [crash] Evolution sous testing

[Haricophile]

Le Sat, 18 Apr 2020 11:14:39 +0200,
Jean-Marc  a écrit :

> Et pour info, pour le moment, il y a pas mal de paquets migrés vers Gnome
> 3.36. C'est peut-être une source possible de soucis.

A mon humble avis, supprimer le "peut-être" de la phrase, les versions de
gnome et les compatibilités c'est une grande aventure...

Re: [crash] Evolution sous testing

[Jean-Marc]

Fri, 17 Apr 2020 23:48:02 +0200
Frederic Zulian  écrivait :

> Bonjour,

salut Frédéric,

> Je tente de sortir de ma dépendance à l'écosystème Google en commençant par
> les mails avec Evolution.
> L'installation et la configuration se sont déroulées sans problème.

Okay.

> Désormais lorsque je lance Evolution j'ai le message d'erreur suivant :
> 
> (evolution:3800818): GLib-GIO-WARNING **: 23:38:10.432: Your application
> did not unregister from D-Bus before destruction. Consider using
> g_application_run().

Le message semble n'être qu'un avertissement.
Que se passe-t-il après ?
Evolution te montre un message et se ferme/s'arrête ?

Perso, je viens de démarrer Evolution sans soucis.
J'ai un avertissement similaire pour evolution-alarm mais sans conséquence.

Et pour info, pour le moment, il y a pas mal de paquets migrés vers Gnome 3.36.
C'est peut-être une source possible de soucis.

> [...]
> Une idée ?

Commencer par essayer d'avoir plus d'infos.  Debian Testing est parfois 
difficile de par son instabilité.

Voir s'il existe un bug déjà rapporté (cf. 
http://www.mail-archive.com/debian-bugs-dist%40lists.debian.org/).

Se renseigner sur les canaux IRC de Debian (cf. https://wiki.debian.org/fr/IRC 
- canal #debian-next).
C'est anglophone sur les canaux généraux, #debian-fr est francophone.
Attention, il faut être patient parfois.  Cela va dépendre des personnes 
disponibles.


> Frédéric ZULIAN

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpVGFGUuk7BG.pgp
Description: PGP signature

Re: [crash] Evolution sous testing

[elguero eric]

apparemment il y a un problème avec la librairie GLib.
Peut-être installer la dernière version de GLib
et recompiler?

e.e.






Le vendredi 17 avril 2020 à 23:48:35 UTC+2, Frederic Zulian  
a écrit : 





Bonjour,

Je tente de sortir de ma dépendance à l'écosystème Google en commençant par les 
mails avec Evolution.  
L'installation et la configuration se sont déroulées sans problème.

Désormais lorsque je lance Evolution j'ai le message d'erreur suivant :

(evolution:3800818): GLib-GIO-WARNING **: 23:38:10.432: Your application did 
not unregister from D-Bus before destruction. Consider using 
g_application_run().

J'ai tenté de faire quelques recherches avec QWANT mais je me retrouve toujours 
avec des réponses faisant références à Microsoft ou Apple

Une idée ? 

Frédéric ZULIAN
--
Pour la santé de votre ordinateur, préférez les logiciels libres.
https://www.april.org/

[crash] Evolution sous testing

[Frederic Zulian]

Bonjour,

Je tente de sortir de ma dépendance à l'écosystème Google en commençant par
les mails avec Evolution.
L'installation et la configuration se sont déroulées sans problème.

Désormais lorsque je lance Evolution j'ai le message d'erreur suivant :

(evolution:3800818): GLib-GIO-WARNING **: 23:38:10.432: Your application
did not unregister from D-Bus before destruction. Consider using
g_application_run().

J'ai tenté de faire quelques recherches avec QWANT mais je me retrouve
toujours avec des réponses faisant références à Microsoft ou Apple

Une idée ?

Frédéric ZULIAN
--
Pour la santé de votre ordinateur, préférez les logiciels libres.
https://www.april.org/

Re: [resolu] Re: [testing] crash gdm

[Jean-Marc]

Fri, 17 Apr 2020 01:39:12 +0200
Gaëtan Perrier  écrivait :

salut Gaëtan,

> Bonsoir,
> 
> Les paquets manquant viennent d'arriver dans testing.

Vu ce matin dans un petit
apt policy gnome-shell

Plus de soucis pour faire un full-upgrade.

> A+
> 
> Gaëtan


Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpKq0vwudUBT.pgp
Description: PGP signature