kde troubles (was: tbird troubles)
On 2024-04-15, gene heskett wrote: > 32 gigs of memory. But the constraint is a 30-45 second delay in opening a new > write path to nv storage. This totally disables digikam's ability to import digikam is a kde application, so you need the kde stuff at least for it. I use it too, have less memory, and still have no delay problems.
Automatic reboot on kernel crash in Debian 12 - how?
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: Automatic reboot on kernel crash in Debian 12 - how?
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
Re: Automatic reboot on kernel crash in Debian 12 - how?
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?
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?
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: e1000e driver Network Card Detected Hardware Unit Hang
> It has been known to happen that drivers implement workarounds for issues > in the hardware itself, so that hardware bugs do not get tripped (or are > tripped less often). 🙂 You make it sound like it's a rare occurrence, but it's actually quite common. Most of it is discrete so you'll rarely be exposed to it, but `grep bugs /proc/cpuinfo` is one of the places where you can see it being somewhat documented. Stefan
Re: e1000e driver Network Card Detected Hardware Unit Hang
On Tue, Apr 16, 2024 at 09:05:29AM -0400, Stefan Monnier wrote: > > It has been known to happen that drivers implement workarounds for issues > > in the hardware itself, so that hardware bugs do not get tripped (or are > > tripped less often). > > 🙂 > > You make it sound like it's a rare occurrence, but it's actually > quite common. Most of it is discrete so you'll rarely be exposed to it, > but `grep bugs /proc/cpuinfo` is one of the places where you can see it > being somewhat documented. One might argue that a driver's whole raison d'être /is/ to work around hardware bugs. But then, perhaps I'm a cynic ;-) Cheers -- t signature.asc Description: PGP signature
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-16, Max Nikulin wrote: > > If you do not trust Gmail as a web application, use a mail application > that supports IMAP. Gmail supports IMAP since more or less forever. >>> >>> AIUI the OP's problem was not when reading mail, but with mail >>> submission of attachments. >> >> And in what way does that affect a true statement and a phraseology that >> clearly implies an nonexistent incompatibility? > > I am completely lost. Mail messages (with attachments) may be submitted It would've been clearer to have advised using another mail application, period, if the OP didn't trust Gmail. But the manner in which you phrased your advice implied that Gmail was a "web application" that didn't support IMAP, which is false, so I piped up (or is it in?) in my admittedly somewhat oblique (to the matter at hand) manner. But no harm, no foul, and all is well. The only real mystery is how Tomas resisted getting yet another lick in against Gmail and Google, et al. --
Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick
On 2024-04-16, John Crawley wrote: > > If you do not trust Gmail as a web application, use a mail application > that supports IMAP. > Gmail supports IMAP since more or less forever. >>> >>> AIUI the OP's problem was not when reading mail, but with mail >>> submission of attachments. >> >> And in what way does that affect a true statement and a phraseology that >> clearly implies an nonexistent incompatibility? > > Loosen the interpretation of Max Nikulin's statement slightly: > "If you do not trust Gmail as a web application, use any mail application > that supports IMAP" > and it makes sense. > I've just loosened it.
Yet another lick at Gmail and Google [was: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick]
On Tue, Apr 16, 2024 at 01:39:34PM -, Curt wrote: [...] > It would've been clearer to have advised using another mail application, > period [...] > But no harm, no foul, and all is well. The only real mystery is how > Tomas resisted getting yet another lick in against Gmail and Google, et > al. Because it'd been off-topic, just as your little oblique stab here is ;-D Cheers -- t signature.asc Description: PGP signature
Re: tbird troubles
On 2024-04-15, gene heskett wrote: > For the last 2 or 3 reboots, when launching t-bird, I get 2 copies of > the gui stacked on top of each other. I can move them separately to 2 > separate workspaces, and both appear to work for some definition of > working, but quitting one actually quits both. > Have you tried *closing* one of the two windows, *quitting* the remaining one, and then restarting your bird?
Re: tbird troubles
On Tue, Apr 16, 2024 at 02:21:27PM -, Curt wrote: > Have you tried *closing* one of the two windows, *quitting* the > remaining one, and then restarting your bird? In his original message, he claimed that closing one window makes the other one also close. I asked *how* he was closing them, and he said that he gets the same result whether he uses the WM's close button, or the application's Exit menu choice.
Re: tbird troubles
On 2024-04-16 at 10:28, Greg Wooledge wrote: > On Tue, Apr 16, 2024 at 02:21:27PM -, Curt wrote: > >> Have you tried *closing* one of the two windows, *quitting* the >> remaining one, and then restarting your bird? > > In his original message, he claimed that closing one window makes > the other one also close. > > I asked *how* he was closing them, and he said that he gets the same > result whether he uses the WM's close button, or the application's > Exit menu choice. From what I saw in a Bugzilla bug report (which I think was linked to in this thread?) about a similar behavior (dating back a good number of years, and closed as - more or less - "not meaningfully fixable" or the like), neither of those is what is needed. What needs to happen, according to that analysis, is to close one of the windows not by File -> Exit or File -> Quit, but by File -> Close. (In my - severely obsolete - Thunderbird version, it's near the top of the File menu, and has the associated keyboard shortcut Ctrl+W.) Reportedly, after doing that, if you then quit the program entirely (by any of the other available methods), when you re-launch it it will come up with only one window. The situation appears to be triggered by doing one of the UI actions that causes Thunderbird to open a new "main" window - which can happen by accident, e.g. by trying to detach a tab from the main Thunderbird window (which apparently doesn't open a new window with just that tab, but rather opens an entire new main Thunderbird window with the contents of that tab active). That in turn can (I would expect) be done accidentally by trying to drag a tab to a new position in the tab bar, but unintentionally dropping it at a place which is instead treated as outside of the window. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: tbird troubles
On 2024-04-16, Greg Wooledge wrote: > On Tue, Apr 16, 2024 at 02:21:27PM -, Curt wrote: >> Have you tried *closing* one of the two windows, *quitting* the >> remaining one, and then restarting your bird? > > In his original message, he claimed that closing one window makes the > other one also close. > > I asked *how* he was closing them, and he said that he gets the same > result whether he uses the WM's close button, or the application's Exit > menu choice. > > I see. An Internet enquiry into the multiple-window problem produces many hits, some of them over a decade old. The most recent I've found (Dec 2023), advises simply creating another profile and copying the old one over to the new one. https://forum.manjaro.org/t/thunderbird-two-windows-workaround/154069
Re: tbird troubles
On 2024-04-16, The Wanderer wrote: > > What needs to happen, according to that analysis, is to close one of the > windows not by File -> Exit or File -> Quit, but by File -> Close. (In > my - severely obsolete - Thunderbird version, it's near the top of the > File menu, and has the associated keyboard shortcut Ctrl+W.) > Yes, that's the "solution" I attempted to describe.
Re: tbird troubles
On Tue, Apr 16, 2024 at 10:39:42AM -0400, The Wanderer wrote: > On 2024-04-16 at 10:28, Greg Wooledge wrote: > > > On Tue, Apr 16, 2024 at 02:21:27PM -, Curt wrote: > > > >> Have you tried *closing* one of the two windows, *quitting* the > >> remaining one, and then restarting your bird? > > > > In his original message, he claimed that closing one window makes > > the other one also close. > > > > I asked *how* he was closing them, and he said that he gets the same > > result whether he uses the WM's close button, or the application's > > Exit menu choice. > > From what I saw in a Bugzilla bug report [...] Thanks for actually reading the links for us -- I was too deep in some ugly PHP code to do it myself ATM. Makes sense, TB seems to remember its window configuration [1] when closing, like its cousin but seems to remember "I had *two* windows last time around", quite unlike its cousin. Cheers [1] Can't they just let the window manager do its job? -- t signature.asc Description: PGP signature
Re: tbird troubles
On 4/16/24 10:22, Curt wrote: On 2024-04-15, gene heskett wrote: For the last 2 or 3 reboots, when launching t-bird, I get 2 copies of the gui stacked on top of each other. I can move them separately to 2 separate workspaces, and both appear to work for some definition of working, but quitting one actually quits both. Have you tried *closing* one of the two windows, *quitting* the remaining one, and then restarting your bird? . From scratch, including a text entry in a shell. Cheers, Gene Heskett, CET. -- "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: tbird troubles
On 4/16/24 10:46, The Wanderer wrote: On 2024-04-16 at 10:28, Greg Wooledge wrote: On Tue, Apr 16, 2024 at 02:21:27PM -, Curt wrote: Have you tried *closing* one of the two windows, *quitting* the remaining one, and then restarting your bird? In his original message, he claimed that closing one window makes the other one also close. I asked *how* he was closing them, and he said that he gets the same result whether he uses the WM's close button, or the application's Exit menu choice. From what I saw in a Bugzilla bug report (which I think was linked to in this thread?) about a similar behavior (dating back a good number of years, and closed as - more or less - "not meaningfully fixable" or the like), neither of those is what is needed. What needs to happen, according to that analysis, is to close one of the windows not by File -> Exit or File -> Quit, but by File -> Close. (In my - severely obsolete - Thunderbird version, it's near the top of the File menu, and has the associated keyboard shortcut Ctrl+W.) Reportedly, after doing that, if you then quit the program entirely (by any of the other available methods), when you re-launch it it will come up with only one window. Thank you, that fixed it! The situation appears to be triggered by doing one of the UI actions that causes Thunderbird to open a new "main" window - which can happen by accident, e.g. by trying to detach a tab from the main Thunderbird window (which apparently doesn't open a new window with just that tab, but rather opens an entire new main Thunderbird window with the contents of that tab active). That in turn can (I would expect) be done accidentally by trying to drag a tab to a new position in the tab bar, but unintentionally dropping it at a place which is instead treated as outside of the window. Cheers, Gene Heskett, CET. -- "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: Automatic reboot on kernel crash in Debian 12 - how?
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?
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: e1000e driver Network Card Detected Hardware Unit Hang
In days of yore (Tue, 16 Apr 2024), Jamie thus quoth: > Look this is a kernel bug and Debian needs to > fix this! Don't give me any of this crap about upstream > this is a bug with the Debian Kernel! Pay attention, because I am now in Support Mode as a former Principal Technical Account Manager for Red Hat. No, this is not necessarily a kernel bug. It can be a hardware bug and it is plausible it can not be solved with a driver work-around. You are hitting a problem and you want someone else to fix it for you. The answer may simply be that you need to replace the NIC with something else. FWIW, I have these Intel NICs in my two NUCs and they are functioning fine. With Debian 12.5 and the latest updates. $ lspci -v -s 00:1f.6 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection I219-V (rev 21) DeviceName: LAN Subsystem: Intel Corporation Ethernet Connection I219-V Flags: bus master, fast devsel, latency 0, IRQ 123, IOMMU group 7 Memory at df10 (32-bit, non-prefetchable) [size=128K] Capabilities: Kernel driver in use: e1000e Kernel modules: e1000e The revision of the NIC may determine whether you have *hardware* problems or not. > This needs to be fixed! Quick answer: replace the NIC. And do some groundwork to determine if the NIC you replace it with has issues you should be aware of or not. > I have already tried disabling the offloads and it does > not work. The specific offloads seemed to be the CRC related ones. # ethtool -k eno1 Features for eno1: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: off [fixed] tx-checksum-ip-generic: on tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] Note: when you disable these, throughput can drop sharply. The other setting suggested was to hike the TX ringbuffer. # ethtool -g eno1 Ring parameters for eno1: Pre-set maximums: RX: 4096 RX Mini:n/a RX Jumbo: n/a TX: 4096 Current hardware settings: RX: 256 RX Mini:n/a RX Jumbo: n/a TX: 256 RX Buf Len: n/a CQE Size: n/a TX Push:off TCP data split: n/a # ethtool -G eno1 tx 2048 rx 2048 # ethtool -g eno1 Ring parameters for eno1: Pre-set maximums: RX: 4096 RX Mini:n/a RX Jumbo: n/a TX: 4096 Current hardware settings: RX: 2048 RX Mini:n/a RX Jumbo: n/a TX: 2048 RX Buf Len: n/a CQE Size: n/a TX Push:off TCP data split: n/a The reason the ringbuffers are important is that the kernel and the OS can construct packets faster in bursts than the NIC can handle, so the OS can queue up packets in the ringbuffer and the NIC can asynchronously pick the packets from the buffer and send them across the wire. If the ringbuffers are set too small, they will overflow and you will get overflow errors. # ethtool -S eno1 NIC statistics: rx_packets: 24463 tx_packets: 6358 rx_bytes: 3093199 tx_bytes: 669733 rx_broadcast: 8044 tx_broadcast: 9 rx_multicast: 10434 tx_multicast: 2510 rx_errors: 0 tx_errors: 0 tx_dropped: 0 If buffers are set too small, this increases multicast: 10434 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 0 tx_tcp_seg_failed: 0 rx_flow_control_xon: 9 rx_flow_control_xoff: 9 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_csum_offload_good: 8539 If you have issues with checksum rx_csum_offload_errors: 0 offload, check these rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 rx_hwtstamp_cleared: 0 uncorr_ecc_errors: 0 corr_ecc_errors: 0 tx_hwtstamp_timeouts: 0 tx_hwtstamp_skipped: 0 > It isn't the cable either I have tried different cables it > still happens! This is an issue with the Kernel module for > the e1000e NIC card. Excellent data-point, you have ruled out whether the cable is faulty or not. But your assumption that this is the kernel module that is broken is still faulty. Provably, I am running the same type of NIC (albeit a different revision) with the same driver and I do not observe any issues. Thus, leveraging Occam's Razor, it follows that scrutinising your particular NIC
is security.debian.org broken
have a look at https://security.debian.org/debian-security/dists/bookworm-security/updates/ is it broken or just me
Re: is security.debian.org broken
In days of yore (Wed, 17 Apr 2024), fxkl4...@protonmail.com thus quoth: > have a look at > > https://security.debian.org/debian-security/dists/bookworm-security/updates/ > > is it broken or just me > w.f.m. from here (Sweden). -- Kind regards, /S
Re: is security.debian.org broken
Am 17.04.2024 um 05:26:57 Uhr schrieb fxkl4...@protonmail.com: > is it broken or just me Works here. Please give more details and run sudo traceroute -T -p 80 security.debian.org -6 -- Gruß Marco Send unsolicited bulk mail to 1713324417mu...@cartoonies.org
opinion - apt-mirror or aptly
i intend to create a local mirror for debian armhf it seems apt-mirror and aptly are the applications most used is one easier, more reliable, ...
Re: is security.debian.org broken
On Wed, Apr 17, 2024 at 05:26:57AM +, fxkl4...@protonmail.com wrote: > have a look at > > https://security.debian.org/debian-security/dists/bookworm-security/updates/ > > is it broken or just me Works here, too. Folks -- "broken" is a very short problem description. A bit more detail is always helpful :) I know it's sometimes difficult, but trying doesn't hurt. Cheers -- t signature.asc Description: PGP signature
Re: opinion - apt-mirror or aptly
On Wed, Apr 17, 2024 at 05:49:29AM +, fxkl4...@protonmail.com wrote: > i intend to create a local mirror for debian armhf > it seems apt-mirror and aptly are the applications most used > is one easier, more reliable, ... Has it to be a mirror, or would a cache do? I'm asking, because a cache is easier to set up, *and* much easier to use. What are your aims? Cheers -- t signature.asc Description: PGP signature
