artair

joined 11 months ago
[–] [email protected] 1 points 1 month ago

Nope, but I found the problem. A kernel update also came with a brand-new bug. A subsequent kernel update fixed the issue. I've been running prints overnight with no midnight disconnects for days now.

[–] [email protected] 1 points 1 month ago

The print job didn’t fail, so I’m going to write this off as a kernel bug until/unless it happens again. I’m just glad I can run long jobs again!

[–] [email protected] 1 points 1 month ago

The print job didn’t fail, so I’m going to write this off as a kernel bug until/unless it happens again. I’m just glad I can run long jobs again!

[–] [email protected] 2 points 1 month ago (1 children)

That, or this may have been a kernel bug issue. 🤣

The problem started around the time I updated both my kernel and OctoPrint to the latest version. However, there was a new kernel version available and I took the update yesterday. I connected the printer, and it stayed online overnight without any issues. Stress-testing stuff now with a long print job that should run past midnight.

We’ll see if the Dark Lord of Bugs has been exorcised when it finishes!

[–] [email protected] 1 points 1 month ago (1 children)

Checked that and the systemd timers. No dice. However, this problem started right around the time I updated my kernel package, and there was another update that I applied yesterday. I connected the printer and let it sit overnight. No midnight disconnections.

I’m running a print job now that should run past midnight. Fingers crossed that this was just some kind of transient kernel bug!

 

A new and bizarre issue has emerged on my Linux Mint server that seems specific to my Ender 3 and OctoPrint. Every night at midnight, regardless of whether a print is running or not, the USB connection to the Ender fails and restarts. (See screenshot from my Telegram OctoPrint plugin.) I’ve tried setting usb.autosuspend to -1 in GRUB, but that doesn’t seem to help.

I’m completely stumped and could use some advice. The failures are far too scheduled and predictable to be a random hardware failure. A relevant chunk of /var/log/syslog is included below for reference.

May 5 00:00:03 borgcube systemd[1]: logrotate.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Rotate log files. May 5 00:00:03 borgcube kernel: [93921.837884] usb 1-5.4: new full-speed USB device number 9 us ing xhci_hcd May 5 00:00:03 borgcube systemd[1]: man-db.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Daily man-db regeneration. May 5 00:00:03 borgcube kernel: [93922.059024] usb 1-5.4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63 May 5 00:00:03 borgcube kernel: [93922.059026] usb 1-5.4: New USB device strings: Mfr=0, Produc t=2, SerialNumber=0 May 5 00:00:03 borgcube kernel: [93922.059027] usb 1-5.4: Product: USB2.0-Serial May 5 00:00:03 borgcube kernel: [93922.066323] ch341 1-5.4:1.0: ch341-uart converter detected May 5 00:00:03 borgcube kernel: [93922.066896] usb 1-5.4: ch341-uart converter now attached to ttyUSB0 May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:03 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device May 5 00:00:03 borgcube snapd[1104]: hotplug.go:200: hotplug device add event ignored, enable e xperimental.hotplug May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:04 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device

 

A new and bizarre issue has emerged on my Linux Mint server that seems specific to my Ender 3 and OctoPrint. Every night at midnight, regardless of whether a print is running or not, the USB connection to the Ender fails and restarts. (See screenshot from my Telegram OctoPrint plugin.) I’ve tried setting usb.autosuspend to -1 in GRUB, but that doesn’t seem to help.

I’m completely stumped and could use some advice. The failures are far too scheduled and predictable to be a random hardware failure. A relevant chunk of /var/log/syslog is included below for reference.

May 5 00:00:03 borgcube systemd[1]: logrotate.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Rotate log files. May 5 00:00:03 borgcube kernel: [93921.837884] usb 1-5.4: new full-speed USB device number 9 us ing xhci_hcd May 5 00:00:03 borgcube systemd[1]: man-db.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Daily man-db regeneration. May 5 00:00:03 borgcube kernel: [93922.059024] usb 1-5.4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63 May 5 00:00:03 borgcube kernel: [93922.059026] usb 1-5.4: New USB device strings: Mfr=0, Produc t=2, SerialNumber=0 May 5 00:00:03 borgcube kernel: [93922.059027] usb 1-5.4: Product: USB2.0-Serial May 5 00:00:03 borgcube kernel: [93922.066323] ch341 1-5.4:1.0: ch341-uart converter detected May 5 00:00:03 borgcube kernel: [93922.066896] usb 1-5.4: ch341-uart converter now attached to ttyUSB0 May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:03 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device May 5 00:00:03 borgcube snapd[1104]: hotplug.go:200: hotplug device add event ignored, enable e xperimental.hotplug May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:04 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device

[–] [email protected] 1 points 5 months ago

Those are HUGE increases on the Seneschal abilities. It really validates all the criticisms about them being underpowered when the season started.

[–] [email protected] 9 points 6 months ago

Henhouse is fine, secure says local fox.

[–] [email protected] 4 points 6 months ago

Having tried it, I’m hoping I can forget Bluesky.

[–] [email protected] 40 points 7 months ago (2 children)

Not only do they still exist, but they also have a Mastodon presence.

Example: @[email protected]

[–] [email protected] 1 points 9 months ago

You’re not the hero we deserve, but you’re the hero we need.

[Salutes in English Major.]

[–] [email protected] 10 points 9 months ago

I was able to bypass the paywall using Google Search’s “cached” view of the page.

https://webcache.googleusercontent.com/search?q=cache:_Uum_1PMdaoJ:https://www.ft.com/content/f9455749-3597-481e-9812-f1c6c6116ebf&cd=9&hl=en&ct=clnk&gl=us&client=safari

As for the content, although I agree with some of the tentpoles to this article, the rest seems a bit saggy. It’s more of an op-ed piece without much more than subjective opinions. If the Financial Times wants to paywall this kind of stuff, they’d better make it worth the price. (This definitely wasn’t.)

[–] [email protected] 3 points 9 months ago (1 children)

I’m Gen X and I’ve been in Information Technology for twenty-eight years. My generation was there at the dawn of personal computing. Yes, there are less technically-savvy people in every generational group, but “older Gen Xers” might consider what you’ve said to be… hmm, what’s the right term? Oh, yes. “Bullshit stereotyping based on age” is the term I’m grasping for here.

I’m well aware of the ELF (Extremely Low-Frequency Radiation) panic. This actually started in the 1970s and rose to national prominence around the late 90s, when it was covered to death by every news outlet. And it was just as silly then as it is now. France is just being France.

And that has little or nothing to do with which generational group you call home.

view more: next ›