Re: USB enumeration issue
Wouldn't the bluetooth device result in a PCIE error and not a USB error though? The WiFi device shows as PCIE and it's on the same chip. Thanks for your replies by the way. Matthew On 1/23/23 8:24 PM, Jeffrey Walton wrote: On Mon, Jan 23, 2023 at 11:12 PM Matthew McAllister wrote: Also, looking at old kernel logs from back when it was working would be useful (/var/log/kernel.N.gz where N if the biggest number there is). Hopefully that will show what device is on usb 1-5 (though I believe port numbers may change over time and depend on what's plugged in). That was the perfect piece of advice. I found the exact log where the issue began: 2023-01-06T20:20:28.225698-08:00 cockpit kernel: [ 25.515977] usb 1-5: Failed to suspend device, error -110 Coincidentally, this is also exactly when the bluetooth on my motherboard stopped working. (The WiFi is on the same MT7921K chipset and still works weirdly). Can you suggest any steps other than straight-up RMA'ing the mobo? (That might fix the USB-C as well, heh.) You can sometimes turn off radios and buses in the BiOS/UEFI. But that feels like papering over the problem. As far as I know, that's the only way to turn off some radios and buses. You may find something wrong with the motherboard during a visual inspection. You can look for leaking capacitors and cracked solder joints. But there's not much you can do besides replacing a cap or reflowing solder. You will probably be more satisfied if you send the board back for repair. Or switch motherboard brands. Jeff
Re: USB enumeration issue
On Mon, Jan 23, 2023 at 11:12 PM Matthew McAllister wrote: > > > Also, looking at old kernel logs from back when it was working would be > > useful (/var/log/kernel.N.gz where N if the biggest number there is). > > Hopefully that will show what device is on usb 1-5 (though I believe port > > numbers may change over time and depend on what's plugged in). > > That was the perfect piece of advice. I found the exact log where the issue > began: > > 2023-01-06T20:20:28.225698-08:00 cockpit kernel: [ 25.515977] usb 1-5: > Failed to suspend device, error -110 > > Coincidentally, this is also exactly when the bluetooth on my motherboard > stopped working. (The WiFi is on the same MT7921K chipset and still works > weirdly). > > Can you suggest any steps other than straight-up RMA'ing the mobo? (That > might fix the USB-C as well, heh.) You can sometimes turn off radios and buses in the BiOS/UEFI. But that feels like papering over the problem. As far as I know, that's the only way to turn off some radios and buses. You may find something wrong with the motherboard during a visual inspection. You can look for leaking capacitors and cracked solder joints. But there's not much you can do besides replacing a cap or reflowing solder. You will probably be more satisfied if you send the board back for repair. Or switch motherboard brands. Jeff
Re: USB enumeration issue
Also, looking at old kernel logs from back when it was working would be useful (/var/log/kernel.N.gz where N if the biggest number there is). Hopefully that will show what device is on usb 1-5 (though I believe port numbers may change over time and depend on what's plugged in). That was the perfect piece of advice. I found the exact log where the issue began: 2023-01-06T20:20:28.225698-08:00 cockpit kernel: [ 25.515977] usb 1-5: Failed to suspend device, error -110 Coincidentally, this is also exactly when the bluetooth on my motherboard stopped working. (The WiFi is on the same MT7921K chipset and still works weirdly). Can you suggest any steps other than straight-up RMA'ing the mobo? (That might fix the USB-C as well, heh.) Matthew
Re: dell latitude 3510 - bios settings to boot debian netinst
> My Dell Inspiron E1505 shipped in 2007 with a 32-bit Core Duo > T2250 processor. In 2016, I STFW and saw that certain 64-bit Core 2 Duo > processors sometimes worked in this laptop (depending upon motherboard > hardware revision?). I bought and installed a T7400, and it works! Same here: I upgraded to Core 2 Duo a mac mini and a Thinkpad T60, both of which came with a Core Duo. There's a noticeable performance increase and a slight improvement in power consumption as well. I recently decommissioned the mac mini, but I still use my T60 as backup laptop for when my T61 breaks down (such as right now, since one of the hinges died again). The 3GB limit on the RAM is becoming problematic, tho. Stefan
Re: Broken IPv6 / IPv4 configuration, or Gmail brokenness?
On Mon, 23 Jan 2023 18:32:41 + (GMT) Tim Woodall wrote: > On Sun, 22 Jan 2023, Celejar wrote: > > > On Sun, 22 Jan 2023 16:28:55 -0500 > > Dan Ritter wrote: > > > >> Celejar wrote: > >>> Hello, > >>> > >>> My Debian Sid system, including its networking system, has been > >>> working fine for a while. Recently, Gmail has not been working properly > >>> on the system: sending (via SMTP with SSL) times out, and receiving > >>> (via POP3 and IMAP) takes abnormally long. Today I finally made some > >>> efforts to understand what's going on. Here's what I know / > >>> understand / have been able to establish: > >>> > >>> 1) My ISP provides me with only IPv4, not IPv6. > >>> > >>> 2) Trying to send email through Gmail using "smtp.gmail.com", via > >>> Sylpheed and Swaks, times out without getting anywhere. For example: > >>> > >>> $ swaks -t cele...@gmail.com -s smtp.gmail.com:587 -tls -a LOGIN > >>> Username: celejar > >>> Password: > >>> === Trying smtp.gmail.com:587... > >>> *** Error connecting to smtp.gmail.com:587: > >>> *** IO::Socket::INET6: connect: timeout > >>> > >> Your system expects to be able to use IPv4 and IPv6. Google > >> handles both. Your ISP does not. DNS returns both IPv4 A records > >> and IPv6 records for smtp.gmail.com. > >> > >> In this particular case, you should change your system > >> preference to IPv4 first. > >> > > > > Shouldn't this be included somewhere prominently in the Debian > > documentation, in the form of a Big Fat Warning that the standard > > dual-stack condiguration used by Debian can cause serious breakage if > > one's ISP doesn't support IPv6? (I'd be happy to add a warning to, say, > > https://wiki.debian.org/DebianIPv6, if I thought I understood the > > issues well enough to get it right.) > > > I think, although I'm not 100% sure as I now have fully working IPv6 > everywhere, that your problem might be that something is providing a > default route. > > If the box trying to connect to gmail knows there's no route then it > will use IPv4. If it thinks there's a route it will use it. > > At a guess, your router is sending out RA messages that say the router > is a default route and then dropping packets when you actually try to > send. > > radvdump will let you see who is broadcasting advertisements. Thank you - the plot thickens. I tried radvdump, and I was indeed receiving IPv6 advertisements. I inspected my router (an OpenWrt box) more carefully, and lo and behold, the router *thinks* that it has IPv6 connectivity: it reports that it has configured its WAN interface via DHCPv6, that it has an IPv6 prefix delegation (a /56), and that it has accordingly handed out an IPv6 address via DHCPv6 to my Debian system (which indeed shows having its network interface configured with that address). The problem is that IPv6 is not actually working at all: ping6 to IPv6 hosts, even from the router itself, get no response, and traceroute to IPv6 hosts show replies from only the first two hops, and just asterisks afterward. My ISP is notoriously cagey about the details of its (slow and incremental) IPv6 rollout. I suppose I can try customer service, but in the meantime, I just don't know whether I have a misconfiguration on the router, or whether the ISP is not actually providing working IPv6. -- Celejar
Re: Odd Wine issue with nvidia-tesla-470-driver
Disregard. I made a mistake and found the error in my ways.
Re: dell latitude 3510 - bios settings to boot debian netinst
On 1/23/23 09:40, Stefan Monnier wrote:
There is no such thing as an Intel Core* CPU that is 32bit.
Actually, the first "Core" branded CPUs ("Core Solo" and "Core Duo")
were still 32bit, back in 2006 (that was the time-window during which
AMD had already switched to 64bit CPUs and Intel still hoped it could
move people over to IA64 instead).
The Core 2 line that followed soon after (around 2006-2007) introduced
the amd64 architecture to the "Core" brand.
Stefan
My Dell Inspiron E1505 shipped in 2007 with a 32-bit Core Duo
T2250 processor. In 2016, I STFW and saw that certain 64-bit Core 2 Duo
processors sometimes worked in this laptop (depending upon motherboard
hardware revision?). I bought and installed a T7400, and it works!
David
Re: Syncing Firefox tabs without a Mozilla account
Curt writes: > You can right-click on a tab and select bookmark all tabs, which can > later be accessed and opened from the bookmarks menu or the library > button Very useful. Thank you. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: kernel errors
On 23/01/2023 15:01, Thomas Schmitt wrote: I wonder what might have caused this. But this line brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 where pior...@gmail.com tried to get this processed as bug of udev. No solution was found. That would be me. Over three years ago, on kernel 4.19. Today, kernel 5.10, Debian 11 Bullseye, and problem still exists :D However, error message has since changed, word udev is not present in the message. Old format: udev: Buffer I/O error on dev sr0, logical block 0, async page read New format: Buffer I/O error on dev sr0, logical block 0, async page read As I've removed optical drive from my desktop computer, this now happens on a laptop computer, which has not seen a CD inserted into the tray for about 6 months. There should be absolutely no errors, just one read attempt - "sorry, no medium". But dmesg is infested with read attempt errors. This particular laptop now, is with KDE, 100% clean and updated Debian stable. For those interested, filtered "sudo dmesg | grep sr0" is attached and model of the drive is below. $ lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0 VENDOR MODELSIZE hp hp_DVDRW_GUE1N 1073741312 -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄ [2.603616] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [2.675633] sr 1:0:0:0: Attached scsi CD-ROM sr0 [ 658.218324] sr 1:0:0:0: [sr0] tag#29 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 658.218328] sr 1:0:0:0: [sr0] tag#29 Sense Key : Not Ready [current] [ 658.218331] sr 1:0:0:0: [sr0] tag#29 Add. Sense: Medium not present - tray closed [ 658.218333] sr 1:0:0:0: [sr0] tag#29 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 658.218336] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 [ 658.250926] sr 1:0:0:0: [sr0] tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 658.250932] sr 1:0:0:0: [sr0] tag#14 Sense Key : Not Ready [current] [ 658.250936] sr 1:0:0:0: [sr0] tag#14 Add. Sense: Medium not present - tray closed [ 658.250939] sr 1:0:0:0: [sr0] tag#14 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 [ 658.250942] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0 [ 658.250947] Buffer I/O error on dev sr0, logical block 0, async page read [ 658.250950] Buffer I/O error on dev sr0, logical block 1, async page read [ 658.250952] Buffer I/O error on dev sr0, logical block 2, async page read [ 658.250954] Buffer I/O error on dev sr0, logical block 3, async page read [ 658.250956] Buffer I/O error on dev sr0, logical block 4, async page read [ 658.250958] Buffer I/O error on dev sr0, logical block 5, async page read [ 658.250960] Buffer I/O error on dev sr0, logical block 6, async page read [ 658.250962] Buffer I/O error on dev sr0, logical block 7, async page read [ 667.549410] sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 667.549415] sr 1:0:0:0: [sr0] tag#0 Sense Key : Not Ready [current] [ 667.549419] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Medium not present - tray closed [ 667.549422] sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 667.549425] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 [ 667.602070] sr 1:0:0:0: [sr0] tag#31 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 667.602075] sr 1:0:0:0: [sr0] tag#31 Sense Key : Not Ready [current] [ 667.602078] sr 1:0:0:0: [sr0] tag#31 Add. Sense: Medium not present - tray closed [ 667.602080] sr 1:0:0:0: [sr0] tag#31 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 [ 667.602083] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0 [ 667.602090] Buffer I/O error on dev sr0, logical block 0, async page read [ 667.602094] Buffer I/O error on dev sr0, logical block 1, async page read [ 667.602096] Buffer I/O error on dev sr0, logical block 2, async page read [ 667.602097] Buffer I/O error on dev sr0, logical block 3, async page read [ 667.602099] Buffer I/O error on dev sr0, logical block 4, async page read [ 667.602101] Buffer I/O error on dev sr0, logical block 5, async page read [ 667.602104] Buffer I/O error on dev sr0, logical block 6, async page read [ 667.602106] Buffer I/O error on dev sr0, logical block 7, async page read [ 1874.677595] sr 1:0:0:0: [sr0] tag#31 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 1874.677600] sr 1:0:0:0: [sr0] tag#31 Sense Key : Not Ready [current] [ 1874.677604] sr 1:0:0:0: [sr0] tag#31 Add. Sense: Medium not present - tray closed [ 1874.677607] sr 1:0:0:0: [sr0] tag#31 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 1874.677611] blk_update_request: I/O error, dev
Re: kernel errors
David Wright writes: > On Mon 23 Jan 2023 at 13:34:50 (+), Richmond wrote: >> It may be a coincidence but yesterday I installed some >> libguestfs-tools. Now I see errors when booting, which also appear in >> /var/log/messages: >> >> kernel: [ 9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s >> kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready >> [current] >> kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not >> present - tray closed >> kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff >> fc 00 00 02 00 >> kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer >> kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer >> kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer >> kernel: [ 9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s >> kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready >> [current] >> kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not >> present - tray closed >> kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 >> 00 00 00 02 00 >> kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer >> kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer >> >> I removed the toos, and also disabled udiskd or udisk2d: >> >> systemctl stop udisks2.service >> systemctl disable udisks2.service >> >> But the errors are still occuring. How can I stop them? >> >> Installing the tools did some strange things like regenerating the grub >> menu. > > When you've removed the packages, keep a copy of your grub.cfg for > comparison and then reconfigure grub (grub-mkconfig). See if the > messages go away. The messages didn't go away. And I tried to reconfigure swap and resume, and got more errors, so I reinstalled the system, formatting the root partition. > > Did you have something strange in your optical drive when you > installed these tools, in anticipation of using the latter on > the former? No, but I did have a usb stick plugged in, and it had ChromeOS Flex on it. In fact that appeared on the grub menu yesterday and I tried to boot ChromeOS Flex from it. That was no doubt a big mistake.
Re: laptop frozen when opening apps, debian testing with gnome
> completely frozen, need to shut down and restart. I'd check to see "how" frozen it is: e.g. try to log into it via SSH (or better yet, keep an `ssh` or `mosh` connection to it with an `atop` or `top` running inside of it, and/or `journalctl -f` so when it freezes you can immediately see if the remote connection is also frozen and what it is/was doing). Stefan
Re: Firefox and/or mate-panel freeze and lock Xorg
On Tue, 24 Jan 2023 at 01:30, Ottavio Caruso wrote: > Am 23/01/2023 um 13:19 schrieb David: > > On Mon, 23 Jan 2023 at 22:12, Ottavio Caruso > > wrote: > > Also maybe you could explicitly confirm which desktop > > environment you are using, so we're not guessing. > > You cut the first line of my message. It is MATE. Oops, so I did! It was: > Debian Bullseye with latest Mate as DM. Sorry for my error! Does the timestamp on the final message in ~/.xsession-errors correlate with the Firefox lockup? Another thought: according to the GNOME project [1], ~/.xsession-errors is deprecated and we should look in the systemd journal now [2]. That link [1] has instructions to inspect journalctl as user, but I would probably also look as root if I have that access on the machine. These are just non-targetted ideas for troubleshooting, I hope someone else has better suggestions to help you. [1] https://help.gnome.org/admin/system-admin-guide/stable/session-debug.html.en [2] Although GNOME probably considers that X Windows is deprecated too, and we should use Wayland, or something, but I'm generally a late adopter of operating system changes so I don't know anything about that :)
Re: kernel errors
On Mon 23 Jan 2023 at 13:34:50 (+), Richmond wrote: > It may be a coincidence but yesterday I installed some > libguestfs-tools. Now I see errors when booting, which also appear in > /var/log/messages: > > kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready > [current] > kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not > present - tray closed > kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff > fc 00 00 02 00 > kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer > kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer > kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer > kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=0s > kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready > [current] > kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present > - tray closed > kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 > 00 00 00 02 00 > kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer > kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer > > I removed the toos, and also disabled udiskd or udisk2d: > > systemctl stop udisks2.service > systemctl disable udisks2.service > > But the errors are still occuring. How can I stop them? > > Installing the tools did some strange things like regenerating the grub > menu. When you've removed the packages, keep a copy of your grub.cfg for comparison and then reconfigure grub (grub-mkconfig). See if the messages go away. Did you have something strange in your optical drive when you installed these tools, in anticipation of using the latter on the former? Cheers, David.
Re: laptop frozen when opening apps, debian testing with gnome
On 1/23/23 11:59, Shalom Ben-Zvii Kazaz wrote: since the latest full-upgrade three days ago on my laptop the computer gets completely frozen sometimes, yesterday got frozen few times when i tried to open zoom. today few times when i tried to open brave browser. completely frozen, need to shut down and restart. i'm running debian testing for three years on that laptop, dell xps 15, gnome desktop. what can i do,check? i'm not so experienced, usually there are no problems. Three things I'd try (for diagnostic testing): 1 - log in as a different user; does that user have the same freezing issues? 2 - log into a different Desktop Environment (Plasma, Cinnamon, etc); does that DE have the same freezing issues? 3 - On boot, choose Advanced options; does that give you the ability to boot into the last kernel you had before the upgrade? If so, select it; does that option have the same freezing issues? -- Kent West<")))>< IT Support::Client Support Abilene Christian University Westing Peacefully - http://kentwest.blogspot.com
Re: Broken IPv6 / IPv4 configuration, or Gmail brokenness?
On Sun, 22 Jan 2023, Celejar wrote: On Sun, 22 Jan 2023 16:28:55 -0500 Dan Ritter wrote: Celejar wrote: Hello, My Debian Sid system, including its networking system, has been working fine for a while. Recently, Gmail has not been working properly on the system: sending (via SMTP with SSL) times out, and receiving (via POP3 and IMAP) takes abnormally long. Today I finally made some efforts to understand what's going on. Here's what I know / understand / have been able to establish: 1) My ISP provides me with only IPv4, not IPv6. 2) Trying to send email through Gmail using "smtp.gmail.com", via Sylpheed and Swaks, times out without getting anywhere. For example: $ swaks -t cele...@gmail.com -s smtp.gmail.com:587 -tls -a LOGIN Username: celejar Password: === Trying smtp.gmail.com:587... *** Error connecting to smtp.gmail.com:587: *** IO::Socket::INET6: connect: timeout Your system expects to be able to use IPv4 and IPv6. Google handles both. Your ISP does not. DNS returns both IPv4 A records and IPv6 records for smtp.gmail.com. In this particular case, you should change your system preference to IPv4 first. Shouldn't this be included somewhere prominently in the Debian documentation, in the form of a Big Fat Warning that the standard dual-stack condiguration used by Debian can cause serious breakage if one's ISP doesn't support IPv6? (I'd be happy to add a warning to, say, https://wiki.debian.org/DebianIPv6, if I thought I understood the issues well enough to get it right.) I think, although I'm not 100% sure as I now have fully working IPv6 everywhere, that your problem might be that something is providing a default route. If the box trying to connect to gmail knows there's no route then it will use IPv4. If it thinks there's a route it will use it. At a guess, your router is sending out RA messages that say the router is a default route and then dropping packets when you actually try to send. radvdump will let you see who is broadcasting advertisements. For completeness, in case you're using radvd, the magic setting to disable the default route is AdvDefaultLifetime 0; Easy when you know but I remember many frustrations trying to work out how to disable the default route while still providing specific routes.
Re: laptop frozen when opening apps, debian testing with gnome
On Mon, Jan 23, 2023 at 1:00 PM Shalom Ben-Zvii Kazaz wrote: > > since the latest full-upgrade three days ago on my laptop the computer gets > completely frozen sometimes, yesterday got frozen few times when i tried to > open zoom. today few times when i tried to open brave browser. completely > frozen, need to shut down and restart. > i'm running debian testing for three years on that laptop, dell xps 15, gnome > desktop. > what can i do,check? i'm not so experienced, usually there are no problems. I would start with a hardware check. Is memtest available when you boot the machine? I would also be interested to know if you can test the video card. I don't know of any utilities to perform the check, however. Jeff
Re: Ctrl-C ignored after pasting a long text in an X terminal emulator
On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote: > I didn't test it for the reason I stated. I think it would be better for > OP to test it as he won't do any more damage than he has already done. Here's how you can reproduce the problem without having to worry about execution of the pasted text as commands: 1) Import some text into the paste buffer (xclip -i < somefile). 2) Open an xterm. 3) From the xterm, run "xeyes" or any other X client program, no ampersand. 4) Paste text into the xterm. 5) Try Ctrl keys. Observe that none of them work. 6) Close the xterm using the window manager controls. > I have come across occasions where ctrl-c doesn't work but ctrl-z does > however. Sure, in a terminal that's in a normal state, that happens all the time, if something is ignoring SIGINT. The entire point of this thread is that when the input buffer of the pty behind the xterm fills up, none of the signals that are generated by keyboard input in a terminal work any longer. The only resort is to close the xterm.
laptop frozen when opening apps, debian testing with gnome
Hi since the latest full-upgrade three days ago on my laptop the computer gets completely frozen sometimes, yesterday got frozen few times when i tried to open zoom. today few times when i tried to open brave browser. completely frozen, need to shut down and restart. i'm running debian testing for three years on that laptop, dell xps 15, gnome desktop. what can i do,check? i'm not so experienced, usually there are no problems.
Re: kernel errors
Sven Joachim writes: > On 2023-01-23 16:13 +, Richmond wrote: > >> I put a dvd in and mounted it. Then rebooted. I saw these messages: >> >> [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 >> [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram >> cd/rw xa/form2 cdda tray >> [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 >> >> Then removed the DVD and rebooted, back to these: >> >> [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram >> cd/rw xa/form2 cdda tray >> [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK >> driverbyte=DRIVER_SENSE cmd_age=2s >> [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] >> [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - >> tray closed >> [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 >> 00 02 00 >> [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer >> >> I am starting to consider re-installing, although everything is working, >> I don't like the look of it. Perhaps I should just re-install the >> kernel? > > This would most likely not help. Instead you should try to figure out > what process is trying to read from your empty drive, and why. > Consulting journalctl might help with that. > > Cheers, >Sven re-installing kernel didn't work. I looked in journalctl and saw this: kernel: PM: Image not found (code -22) It's looking for a resume from hibernate maybe. So then it became apparent that the kernel parameter to resume is a disk by id which looks different from the ones in /etc/fstab. I am not sure how that came about.
Re: dell latitude 3510 - bios settings to boot debian netinst
> There is no such thing as an Intel Core* CPU that is 32bit.
Actually, the first "Core" branded CPUs ("Core Solo" and "Core Duo")
were still 32bit, back in 2006 (that was the time-window during which
AMD had already switched to 64bit CPUs and Intel still hoped it could
move people over to IA64 instead).
The Core 2 line that followed soon after (around 2006-2007) introduced
the amd64 architecture to the "Core" brand.
Stefan
Re: kernel errors
Hi, Richmond wrote: > I put a dvd in and mounted it. Then rebooted. I saw these messages: > > [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 > [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram > cd/rw xa/form2 cdda tray > [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 Looks normal. > Then removed the DVD and rebooted, back to these: I wonder what happens if you simply put in and out the medium, without rebooting. It looks somewhat as if the kernel perceives a wrong medium status and size and so lures some software like blkid into trying to read the last 4 KiB before the end of the first GiB. What do you get from: lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0 I get: VENDOR MODEL SIZE HL-DT-ST BDDVDRW GGC-H20L 4700372992 (It is a known bug of Linux to report the size of the last loaded medium if the drive tray is empty. But exactly 1 GiB is a strange size for a DVD medium and rebooting should clear this misperception.) > I am starting to consider re-installing, although everything is working, > I don't like the look of it. Perhaps I should just re-install the kernel? If you do, then check whether the messages are not there after base system installation and then try to find out which further package causes those read attempts. Have a nice day :) Thomas
Re: kernel errors
On 2023-01-23 16:13 +, Richmond wrote: > I put a dvd in and mounted it. Then rebooted. I saw these messages: > > [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 > [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram > cd/rw xa/form2 cdda tray > [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 > > Then removed the DVD and rebooted, back to these: > > [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram > cd/rw xa/form2 cdda tray > [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=2s > [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] > [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray > closed > [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 > 02 00 > [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer > > I am starting to consider re-installing, although everything is working, > I don't like the look of it. Perhaps I should just re-install the > kernel? This would most likely not help. Instead you should try to figure out what process is trying to read from your empty drive, and why. Consulting journalctl might help with that. Cheers, Sven
Re: kernel errors
"Thomas Schmitt" writes: > Hi, > > Richmond wrote: >> kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s >> kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready >> [current] >> kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not >> present - tray closed >> kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff >> fc 00 00 02 00 > > Your optical drive gets asked for 2 blocks iand answers that there is no > medium recognized in the tray. The request was to read from block 0x07fffc > = 524284 = 1023.9921875 MiB = 1 GiB - 4 KiB. > This is not a usual medium capcity. So i wonder from where the caller had > that block address. > > >> kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer > > I wonder what might have caused this. But this line brings me to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 > where pior...@gmail.com tried to get this processed as bug of udev. > No solution was found. > > >> kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s >> kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready >> [current] >> kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not >> present - tray closed >> kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 >> 00 00 00 02 00 > > This read attempt wanted to get 2 blocks from block address 0. > More plausible as a wild guess, than 1 GiB - 4 KiB. > > > What happens if you give the drive a readable DVD ? > Maybe the software which issues the READ commands shows up with some more > enlightening complaint. > > > Have a nice day :) > > Thomas I put a dvd in and mounted it. Then rebooted. I saw these messages: [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 Then removed the DVD and rebooted, back to these: [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray closed [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00 [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer I am starting to consider re-installing, although everything is working, I don't like the look of it. Perhaps I should just re-install the kernel?
Odd Wine issue with nvidia-tesla-470-driver
I found an odd issue on Debian Bookworm with nvidia-tesla-470-driver installed and the i386 arch installed as a secondary arch (dpkg --add-architecture i386). When installing wine it tries to pull in nvidia-390 packages and breaks. Has anyone seen this before or is there a workaround? I suspect nvidia-tesla-470-driver doesn't have as many packages in i386 as amd64 does -or- there is a dependency in wine that doesn't expects the normal nvidia-driver and not nvidia-tesla.
Re: kernel errors
Hi, Richmond wrote: > kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready > [current] > kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not > present - tray closed > kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff > fc 00 00 02 00 Your optical drive gets asked for 2 blocks iand answers that there is no medium recognized in the tray. The request was to read from block 0x07fffc = 524284 = 1023.9921875 MiB = 1 GiB - 4 KiB. This is not a usual medium capcity. So i wonder from where the caller had that block address. > kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer I wonder what might have caused this. But this line brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 where pior...@gmail.com tried to get this processed as bug of udev. No solution was found. > kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=0s > kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready [current] > kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present > - tray closed > kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 > 00 00 00 02 00 This read attempt wanted to get 2 blocks from block address 0. More plausible as a wild guess, than 1 GiB - 4 KiB. What happens if you give the drive a readable DVD ? Maybe the software which issues the READ commands shows up with some more enlightening complaint. Have a nice day :) Thomas
Re: Firefox and/or mate-panel freeze and lock Xorg
Ottavio Caruso wrote: > Hi, > > Debian Bullseye with latest Mate as DM. > > Every now and again, something happens whenever Firefox is loaded and > the whole screen is locked. I can't open a terminal and I can't move > between workplaces (ctrl + alt + left/right). > > Then I have to switch to a virtual terminal (ctrl + alt + F2), check > "top", but there is plenty of CPU and RAM available. > > Nothing weird in either dmesg, /var/log/messages or /var/log/Xorg.0.log, > apart from: > > (EE) event0 - AT Translated Set 2 keyboard: client bug: event > processing lagging behind by 33ms, your system is too slow i've seen those in the past but i don't think they're critical. > [BTW libinput is a pain in the a. on my Thinkpad T440) > > I do: > > $ killall mate-panel # nothing happens in graphical mode > $ killall firefox # Then I restart FF but the freeze happens again > # killall Xorg # Xorg restarts, I log in and restart FF, but the same > freeze happens > # reboot # That's the only thing that fixes it. > > Where do I go from here? i run Mate and testing with the exception that i keep firefox running whichever version comed out and hits unstable. that pulls a few other things in but not many and it is ok for my purposes. some months ago i was having the same sort of experience but i was never able to figure out which it was that was causing me problems. an upgrade must have fixed it because the problem went away. the other day i had it happen again. i'd not installed the latest firefox from sid so after i restarted the system i prompty did that. when the freeze happens there is no way for me to get input of any kind, how are you getting the system to respond to you at all? for me i have to hit the switch to restart. none of the alt-windows or the restart of X keys work. songbird
Re: Ctrl-C ignored after pasting a long text in an X terminal emulator
On Mon, Jan 23, 2023 at 01:51:08PM +, Richmond wrote: > Greg Wooledge writes: > > > It doesn't work, presumably for the same reason that Ctrl-C doesn't work. > > The xterm's pty's input buffer is full, and it simply ignores all keyboard > > input from that point forward. [...] > I have come across occasions where ctrl-c doesn't work but ctrl-z does > however. This is most probably for a totally different reason that the one which seems at work here. Cheers -- t signature.asc Description: PGP signature
Re: Ctrl-C ignored after pasting a long text in an X terminal emulator
Greg Wooledge writes: > It doesn't work, presumably for the same reason that Ctrl-C doesn't work. > The xterm's pty's input buffer is full, and it simply ignores all keyboard > input from that point forward. > > (Are people not actually *testing* these things before proposing them?) I didn't test it for the reason I stated. I think it would be better for OP to test it as he won't do any more damage than he has already done. I have come across occasions where ctrl-c doesn't work but ctrl-z does however.
kernel errors
It may be a coincidence but yesterday I installed some libguestfs-tools. Now I see errors when booting, which also appear in /var/log/messages: kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready [current] kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not present - tray closed kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00 kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready [current] kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present - tray closed kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer I removed the toos, and also disabled udiskd or udisk2d: systemctl stop udisks2.service systemctl disable udisks2.service But the errors are still occuring. How can I stop them? Installing the tools did some strange things like regenerating the grub menu.
RE: Debian Bullseye 64 bits
Dans ce nouveau système, il faut créer un fichier par interface à renommer, on peut l’appeler un peu comme on veut pourvu qu’il finisse par .link, et ces fichiers sont lus dans l’ordre si on les préfixe par des nombres, un peu à la manière des fichiers de règles dans /etc/udev/rules.d/… L’ancien système utilisant udev (via la config « 70-persistent-net.rules ») ne fonctionne plus sur une Debian 11 fraîchement installée (et pas migrée d’un plus ancien système), sauf je crois si on remet « net.ifnames=0 » dans les paramètres du noyau, comme le suggère Hugues Larrive… Cdlt, Fred. -Message d'origine- De : ajh-valmer Envoyé : lundi 23 janvier 2023 12:51 À : debian-user-french@lists.debian.org Objet : Re: Debian Bullseye 64 bits On Monday 23 January 2023 08:20:04 Frédéric BOITEUX wrote: > Voici un exemple de fichier *.link, placé dans /etc/systemd/network/, > si ça peut servir d?inspiration? À noter qu?il faut regénérer l?initrd > puis redémarrer pour que cela soit effectivement pris en compte? Merci. "/etc/systemd/network/" est vide. Je vois pas comment créer un fichier, quel nom et y écrire son contenu ? Avant, je faisais ceci : Je renseignais le fichier "/etc/udev/rules.d/70-persistent-net.rules" et mes interfaces prenaient un nouveau nom parlant : eth0, wlan0 etc... Apparemment, ça semble toujours fonctionner... Bonne journée
Re: Firefox and/or mate-panel freeze and lock Xorg
On Mon, 23 Jan 2023 at 22:12, Ottavio Caruso wrote: > Every now and again, something happens whenever Firefox is loaded and > the whole screen is locked. I can't open a terminal and I can't move > between workplaces (ctrl + alt + left/right). > > Then I have to switch to a virtual terminal (ctrl + alt + F2), check > "top", but there is plenty of CPU and RAM available. > > Nothing weird in either dmesg, /var/log/messages or /var/log/Xorg.0.log, > apart from: > > (EE) event0 - AT Translated Set 2 keyboard: client bug: event > processing lagging behind by 33ms, your system is too slow > > [BTW libinput is a pain in the a. on my Thinkpad T440) > > I do: > > $ killall mate-panel # nothing happens in graphical mode > $ killall firefox # Then I restart FF but the freeze happens again > # killall Xorg # Xorg restarts, I log in and restart FF, but the same > freeze happens > # reboot # That's the only thing that fixes it. > > Where do I go from here? Hi, did you look in the ~/.xsession-errors file? Also maybe you could explicitly confirm which desktop environment you are using, so we're not guessing. Perhaps try starting firefox from a terminal so you can see if it emits any error messages when the crash happens. Maybe there are dbus logs somewhere? These are just basic suggestions, maybe others here will have better ideas. Aside: have you looked at 'htop', it has a much nicer user interface than 'top'.
Re: dell latitude 3510 - bios settings to boot debian netinst
Russell L. Harris wrote: > On Sun, Jan 22, 2023 at 05:49:30PM -0800, David Christensen wrote: > > On 1/19/23 19:43, Russell L. Harris wrote: > > > I have not figured out how to configure the BIOS of a Dell Latitude > > > 3510 to cause it to see and boot from a Debian netinst image (Debian > > > 11) written to USB flash (8Gbyte Patriot). > > For newer computers with UEFI firmware and Secure Boot, I use the > > "amd64" architecture version of the Debian Installer -- e.g.: > > > >debian-11.3.0-amd64-netinst.iso > > 1) Does this work on an Intel Pentium machine? Intel uses the name Pentium for too many incompatible things. It will work on all the Pentium-labelled chips manufactured since 2014, almost 10 years ago. It will not work on most of the prior incarnations. The Dell Latitude 3510 was sold with Intel 10th-generation Core CPUs, and all of those will work with amd64. -dsr-
Re: Debian Bullseye 64 bits
On Monday 23 January 2023 08:20:04 Frédéric BOITEUX wrote: > Voici un exemple de fichier *.link, placé dans /etc/systemd/network/, > si ça peut servir d?inspiration? À noter qu?il faut regénérer l?initrd > puis redémarrer pour que cela soit effectivement pris en compte? Merci. "/etc/systemd/network/" est vide. Je vois pas comment créer un fichier, quel nom et y écrire son contenu ? Avant, je faisais ceci : Je renseignais le fichier "/etc/udev/rules.d/70-persistent-net.rules" et mes interfaces prenaient un nouveau nom parlant : eth0, wlan0 etc... Apparemment, ça semble toujours fonctionner... Bonne journée
Re: USB enumeration issue
On Mon, 2023-01-23 at 13:54 +0500, Alexander V. Makartsev wrote: [...] > > [ 66.959391] usb 1-5: device not accepting address 5, error -71 > > [ 66.960945] usb usb1-port5: unable to enumerate USB device > > > > This occurs when *no USB cables are plugged in*. The kernel is > > stalling the entire boot process to enumerate some internal USB hub, I > > assume. > > > > My front USB-C is broken as far as I can tell, so I tried unplugging > > the header. The issue persisted. > > > > The front USB 3.0 work correctly and I couldn't get the header > > unplugged anyways, so I didn't test if that was the issue. [...] On 23.01.2023 11:40, Matthew McAllister wrote: > Start troubleshooting process by unplugging all USB devices, > He said he did that ;-) > [...] > There is one additional thing, if your "PC" is a laptop, then it is > possible there is an internal device inside that uses USB bus to > function, e.g. WiFi adapter, WWAN adapter, etc. He also said he unplugged the header for the front USB so guess that's a desktop. Another things to try is booting using an older kernel, presumably there is one still installed as Debian doesn't automatically uninstall kernels. Also, looking at old kernel logs from back when it was working would be useful (/var/log/kernel.N.gz where N if the biggest number there is). Hopefully that will show what device is on usb 1-5 (though I believe port numbers may change over time and depend on what's plugged in). -- Tixy
Re: USB enumeration issue
On 23.01.2023 11:40, Matthew McAllister wrote: Hi all, Since I upgraded packages a couple weeks ago, whenever I start my PC, I have to wait 60 seconds for the kernel to enumerate USB devices. Here's the log: [ 8.815277] usb 1-5: device descriptor read/64, error -110 [ 24.431295] usb 1-5: device descriptor read/64, error -110 [ 24.943220] usb 1-5: new high-speed USB device number 3 using xhci_hcd [ 30.319491] usb 1-5: device descriptor read/64, error -110 [ 45.935494] usb 1-5: device descriptor read/64, error -110 [ 46.044772] usb usb1-port5: attempt power cycle [ 46.523221] usb 1-5: new high-speed USB device number 4 using xhci_hcd [ 51.323562] usb 1-5: Device not responding to setup address. [ 56.331406] usb 1-5: Device not responding to setup address. [ 56.539402] usb 1-5: device not accepting address 4, error -71 [ 56.943221] usb 1-5: new high-speed USB device number 5 using xhci_hcd [ 61.743759] usb 1-5: Device not responding to setup address. [ 66.751609] usb 1-5: Device not responding to setup address. [ 66.959391] usb 1-5: device not accepting address 5, error -71 [ 66.960945] usb usb1-port5: unable to enumerate USB device This occurs when *no USB cables are plugged in*. The kernel is stalling the entire boot process to enumerate some internal USB hub, I assume. My front USB-C is broken as far as I can tell, so I tried unplugging the header. The issue persisted. The front USB 3.0 work correctly and I couldn't get the header unplugged anyways, so I didn't test if that was the issue. Any ideas what might be going on? Kernel is 6.1.4-1. Matthew Start troubleshooting process by unplugging all USB devices, doesn't matter, if it's empty USB extension cable, external USB hub, or USB thumb drive. If you did that already and don't have USB-anything plugged in and still have the same issue, then this is a hardware problem, not a software problem. If you unplugged everything and can't reproduce the issue anymore, then you have faulty USB device, which should be tested one by one, to determine which one is the culprit. There is one additional thing, if your "PC" is a laptop, then it is possible there is an internal device inside that uses USB bus to function, e.g. WiFi adapter, WWAN adapter, etc. In that case you need to open laptop to remove these devices. If your laptop is HP or Lenovo brand, you should look for publicly available Disassembly and Maintenance Manuals for your model on manufacturer's official website. -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: Efficacité de spamassassin et de postgrey
Francois Mescam a écrit : > Bonjour, > > Cela fait de nombreuses années que j'utilise spamassassin et postgrey > sur mon serveur de mail. De plus j'ai construit un système de liste > noire personnelle que j'alimente au fur et à mesure des réceptions de > mail intempestif avec les adresses du champ From et de l'enveloppe des > mails. > > Je constate actuellement que ces outils ont les performances suivantes > pour environ 800 mails par semaine : > > - spamassassin moins de 5 mails > > - postgrey en évite moins de 10 > > - ma liste noire en évite de l'ordre de 200 mais il passe avant > spamassassin, peut-être qu'en inversant l'ordre ce serait mieux > > Spamassassin est pratique à utiliser et ne génère pas de retard dans les > délivrances de mail, tout au plus il faut faire tourner un cron pour > mettre à jour ses règles en fonctions de ses propres références. > postgrey demande de temps à autre d'ajouter un domaine considéré comme > sur mais surtout il a le gros défaut de retarder les mails en > particulier ceux de validation d'une inscription sur un site d'un > domaine qui n'est pas dans les listes blanches. > > J'en suis à me demander s'il est encore utile d'utiliser ces outils > devant leur peu d'efficacité. > > Quelqu'un a-t-il des remarques à faire la-dessus ? > > Bonne journée > Bonjour, Personnellement, j'ai la configuration suivante : MX1/MX3 (les deux sur la même machine parce que les merdes tapent en premier sur le MX de poids le plus faible), Linux Debian (amd64, i7 3e génération) : - clamav - spamassassin - greylist (avec scoring SORBS/SPF/DKIM) - greeting helo - sendmail/procmail MX2, NetBSD 10 (amd64, i7 4e génération) : - greeting helo - spamassassin - clamav - greylist (même config que le MX1) - postfix (parce qu'il arrive avec le système et que j'ai eu la flemme de configurer sendmail, c'est dans ma todo list, sendmail étant tout de même bien plus performants dans des configurations pointues). Ces deux serveurs traitent plusieurs dizaines de milliers de messages par jour, quatre domaines mail différents, il y a les boîtes des utilisateurs et des listes de diffusion. Pour chaque message, il faut une dizaine de secondes de traitement lorsqu'il est accepté. Le greeting helo est à 5 s côté sendmail (1 s côté postfix, je n'ai pas cherché à le configurer). Les deux greylists sont synchronisées. Cette semaine, j'ai fait une fausse manipulation (une histoire de droits) sur le MX2 et je me suis pris des rafales de saletés toutes marquées comme spam par spamassassin parce que greylist partait en sucette lors des synchronisations des bases. Donc la greylist est efficace. spamassassin aussi puisqu'en cas de défaut du milter-greylist, spamassassin s'en charge. D'après mes stats (sur plusieurs domaines pro), greeting helo vire à lui tout seul 90% des merdes entrantes. Le ménage est ensuite fait par DKIM/SPF (stricts) puis greylist et enfin spamassassin. Clamav, aujourd'hui, ne retire pas grand'chose, mais je le laisse. Les statistiques des domaines en question indiquent de la moitié des messages entrants sont illégitimes et sont rejetés par le système avant d'arriver dans les boîtes mail des utilisateurs. Les utilisateurs, quant à eux, savent que le premier mail en provenance d'un domaine inconnu mettra entre 10 minutes et plusieurs heures en fonction de la présence ou non du serveur dans des blacklists. Sur demande, je peux whitelister un domaine ou un émetteur. Bien cordialement, JKB
