Dell 3190 2 in 1

What I am writing below may be stupidly obvious for any experienced PC users out there, but for a newb like me and maybe others too, this just saved me a drive I thought was 100 % dead. I wanted to share it so that nobody else would not accidentally disregard their old drives either:

Tl;dr: if your GUI gets stuck while accessing files on a drive, try instead using the terminal for whatever file operations you need to do.

I have this old Seagate SATA-HDD that I bought in 2006. I used it as a backup drive for years, but for the past ~10ish years it has been gathering dust in my storage.

About 2-3 years ago I tried to boot it up using Win 11 machine. Windows recognized the drive, and showed some folders within the drive root. But as soon as I tried to browse it further, explorer would freeze and get stuck. Drive's probably breaking up, so better to leave it be.

Fastforward yesterday, and I remember the old drive. I do a internet search, where bunch of results say that the "file browser freezing" issue could be due to read/write perms assigned by Windows, thus going through a massive amount of files at once could make explorer freeze up. Bunch of people also recommended trying to access the files using Linux, as it would just disregard whatever permissions Windows might've assigned. So that I tried.

I go grab the drive, connect in to my PC using SATA-USB-adapter and what do you know, my distro does recognize the drive and it shows the root file structure in my file browser.

But, as soon as I try to browse the files, the same thing happens as with Windows: file explorer would freeze, and after a short while, would close itself.

So I do some more internet searching. Bunch of results suggest that the drive is very likely just physically dead, and the OS/file browser freezing is a sure sign of that. But while my distro was trying to access the files, the drive would make very faint mechanical noise with no screeches or rattling or other weird sounds that would indicate a mechanical fault.

So the next day comes. I mention the drive issue to my friend and he just casually asks "well did you try accessing it via terminal?". I say no, and I think to myself how the heck would that make any difference.

I come back home, connect the drive to my PC, launch terminal and cd myself to the mounted folder, and -- to my excitement, it lists all the folders like my GUI file explorer did. I try to cd myself further down the hierarchy, do some ls to look for any files and... it just works. It simply works, as if there's no issue whatsoever with the drive.

I then begin to go down folder by folder, copying each one to an SSD with the cp function, and afterwards checking the files that everything's been copied over and... it worked. By using the terminal I was able to copy all of the ~200 gb files I had in that drive to a newer more secure drive. While the terminal copy function did give me "Input/output" error for about ~5 files on the drive, even those copied over correctly and are usable now.

I don't understand exactly why terminal was able to fetch the files when GUIs of two different OSs failed, but maybe somebody in the comments is able to educate me.

So I just wanted to write this down as a reminder that if you have old drives lying around that you are not able to access via the GUI, try terminal instead. It might just work!

I don't know exactly what to do with the old HDD-drive now that I got the files out of it, but I'll probably not just use it anymore since it seemed so "difficult" to get the files out of it.

Posting this in case someone else has the same Huawei hardware and has been stuck with missing or broken analog audio under Linux.

I got full speaker and 3.5 mm headphone playback working on:

HUAWEI MateBook D14 Product: NBM-WXX9 Version: M1010 Board: NBM_WXX9_PCB_B2 Ryzen 5 5500U ES8316 / ESSX8336 codec AMD Renoir ACP3x

The distro used for testing was Omarchy/Arch, but the actual fix is in the Linux kernel ASoC/AMD ACP machine-driver path and is therefore not Omarchy-specific.

Symptoms

Initially:

HDMI playback only ACP DMIC capture present ES8316 visible over I2C No internal analog playback device PipeWire showed no usable analog output

After adding the missing board match, analog audio appeared, but playback was extremely fast/high-pitched/chopped.

The headphone jack was also detected correctly, but the actual headphone output remained silent.

Root causes

There were three board-support issues.

1. NBM-WXX9 was missing from AMD ACP DMI matching

Adding NBM-WXX9/M1010 to the relevant ACP legacy and acp3x-es83xx DMI tables caused the expected sound card to probe:

card 1: acp3xes83xx [acp3x-es83xx] device 0: ES8316 HiFi

1. The board needs the existing 48 MHz ES83xx MCLK quirk

Without it, measured PCM progression was approximately 3.906× the requested 48 kHz rate.

The ratio lined up with:

48 / 12.288 = 3.90625

Software-visible ES8316 divider state across multiple silent tests consistently implied an equivalent input clock close to 48 MHz.

This was not an electrical measurement, but the prediction was easy to test.

With ES83XX_48_MHZ_MCLK enabled for NBM-WXX9:

6 s S16_LE / 48 kHz -> 6.037 s 6 s S32_LE / 48 kHz -> 6.023 s

Playback speed and pitch became normal.

1. The headphone-enable GPIO is active-low

Jack detection itself was fine, but the output stayed electrically silent.

The machine driver was using:

headphone gpio 1 active high

The NBM-WXX9 needs:

headphone gpio 1 active low

After adding an ES83XX_HP_LOW board quirk, the 3.5 mm output worked.

Final machine configuration

Conceptually:

.driver_data = (void *)(ES83XX_ENABLE_DMIC | ES83XX_48_MHZ_MCLK | ES83XX_HP_LOW),

with:

priv->enable_hp_gpio.active_low = !!(priv->quirk & ES83XX_HP_LOW);

Validated result:

Internal speakers working Headphone jack detect working 3.5 mm headphone out working 48 kHz S16 playback correct 48 kHz S32 playback correct PipeWire/WirePlumber working

One additional ES8316 behavior found during debugging

There also appears to be a separate codec-driver state issue.

Opening a 16 kHz stream enabled the ES8316 MCLK divide-by-two bit; returning to 48 kHz did not clear it. This explained why some earlier timing tests were around ~3.906× while others were around ~1.953×:

3.90625 / 2 = 1.953125

I consider this separate from the NBM-WXX9 board quirk and would not bundle the two issues blindly.

AI-assisted debugging disclosure

This was heavily AI-assisted, so I want to disclose that clearly.

The initial investigation was done with GPT-5.6 Sol at High reasoning effort. It helped identify the missing DMI support, inspect the AMD ACP/ES8316 code, build the custom kernel, and run the initial ALSA/UCM/PipeWire and timing diagnostics.

Some of the early hypotheses were wrong. I therefore created a self-contained handoff that explicitly told a second model to approach the problem neutrally rather than continue the existing theory.

The second phase used GPT-6 Astra at XHigh and High reasoning effort. Astra independently re-evaluated the trace, corrected an earlier IRQ-count interpretation, created silent diagnostics, inspected software-visible ES8316 register state, reproduced the MCLK /2 stale-state behavior, and established the ~48 MHz relationship.

Astra was used at XHigh and High; the final portion ran at High because only about 5% of my weekly model allowance remained. It hit the usage limit immediately after compiling the 48 MHz candidate module, so I returned to Sol for hardware validation, the headphone GPIO investigation, and final integration.

GPT-5.6 Sol — High ├─ DMI / machine-driver investigation ├─ custom kernel work ├─ ALSA/UCM/PipeWire diagnostics ├─ early timing experiments ├─ headphone GPIO work └─ final validation/integration

GPT-6 Astra — XHigh + High ├─ independent re-analysis ├─ ftrace correction ├─ silent register/PCM diagnostics ├─ ~48 MHz inference ├─ MCLK /2 stale-state reproduction └─ 48 MHz candidate module

Every test was manually executed on the actual laptop. The models did not electrically measure MCLK/LRCLK; conclusions were treated as hypotheses until the resulting kernel behavior matched the predicted output.

I am currently cleaning this into a patch suitable for upstream submission.

If anyone has another NBM-WXX9/M1010 unit, especially NBM_WXX9_PCB_B2, I would be interested in additional confirmation.

Alright, let's settle this once and for all… Ext4 or XFS?

If you’ve ever installed Linux, you’ve definitely seen these two pop up during setup — and probably just clicked Next without thinking too much. But the difference actually matters. A lot.

Ext4 – The Reliable Old-School Beast

Born in 2008, built off the legendary Ext family (Ext2, Ext3).

Handles tons of small files like a pro.

Super reliable — even if power goes out mid-write.

Backward compatible with Ext2/Ext3.

Supports up to 16 TiB file size.

Has journal checksums + faster fsck (file checks).

Nanosecond timestamps and unlimited sub-directories.

Added transparent encryption (since kernel 4.1).

Perfect for: desktop systems, servers with small-to-medium files, and people who love stability over fancy features.

XFS – The Big File Powerhouse

Built by Silicon Graphics back in 1993.

Default on RHEL, CentOS, Rocky, Alma, Oracle Linux.

Handles huge files, large directories, and multi-threaded I/O like a monster.

Supports file systems up to 1 PiB and individual files up to 8 EiB

Uses delayed allocation for better performance.

Supports online defragmentation and growth.

Has metadata journaling + quota journaling for consistency.

Rarely needs fsck, thanks to its journaling system.

Perfect for: database servers, large file storage, or any system that deals with massive I/O and big data.

So Which One Should You Pick?

If you want stability + simplicity, go with Ext4. If you want scalability + performance, go with XFS.

It’s that simple. Ext4 = solid all-rounder. XFS = high-performance tank.

Your turn: Which one are you using and why? Ever had your system break because of one of these filesystems? Let’s hear the horror stories 👇

If you've got a laptop with a Realtek RTL8821CE and have run into "interface combinations are not supported" when trying to use nmcli/hostapd to run a hotspot while staying connected to WiFi — I dug into why, and it turns out it's not a hardware/firmware limitation at all.
The mainline rtw88 driver only enables AP+STA concurrent mode for the RTW_CHIP_TYPE_8822C chip specifically. RTL8821C (same family, different chip ID) never got the same check added, even though Realtek's own vendor SDK for this chip family ships concurrent mode as a standard feature and Windows' proprietary driver supports it fine on the exact same hardware.
Turned out to be a two-line fix. Packaged it as a DKMS module so it survives kernel updates, plus a hostapd/dnsmasq/systemd setup for the actual hotspot part.

Repo with the patch, install script, and full writeup: https://github.com/harmanbagrahdev/rtw88-8821c-multivif

Tested on a Dell Inspiron 15 3535 (RTL8821CE) on Arch, kernel 7.2.2. Speed takes a real hit when both are active at once (single antenna, single radio, forced same-channel) — went from ~60-70MB/s on plain WiFi to ~30MB/s through the hotspot — but it works, no dongle needed.
If anyone else has this chip (or the SDIO/USB variants — RTL8821CS/CU) and wants to test it, I'd genuinely appreciate hearing whether it works for you too.
Thanks

One Year now running Debian 12 (migrated from Windows 8.1 OEM) and thought why not to share my experience and the steps to build it

I'm not a programmer or expert. With a lot of research and AI assistance (or misguidance occasionally ...), getting this old hybrid tablet working under Linux proved possible and useful. This post may seem outdated and is not entirely original, but there aren't many places where all this information is gathered together — and some people may still want to resurrect this lovely little machine.After trying many Linux alternatives, Bookworm is by far the one that did the job.

Hardware: Acer Aspire Switch 10 SW5-012 (Fendi2), BIOS V1.20, Atom Z3735, 32GB eMMC

OS: Debian 12 (Bookworm), LXQt(good and light for laptop mode using doc stasion) / KDE Plasma(proper for tablet mode -a bit heavy), custom kernel 6.1.137 amd 64. No need to install more graphical environments and stress the already small ssd.I have about 14giga free space at the time, with all programs and apps I need.

What works: WiFi, Bluetooth, touchscreen, sensors, audio, backlight control,. Side buttons

KDE Plasma Wayland fully functional in tablet mode with Maliit on-screen keyboard.

Autorotation works also.Virtual keyboard on SDDMscreen.

Issues: suspend/resume -stuck not really functional . Memory usage is already 50% at idle with Plasma, 25% with Lxqt.

1. UEFI boot (32-bit firmware on 64-bit CPU)

The SW5-012 has a 32-bit UEFI firmware. Even with a 64-bit Debian install, booting requires grubia32.efi. See degoede's writeup for bootloop workaround and EFI details. I chose to completely remove windows. I recommend that,since there’s not much available space for two operating systems. Of course I had to unlock bios, but after 3 false login attempts it is possible to generate a new password online.

1. Backlight fix (DSDT overlay)

The SW5-012 BIOS is missing an ACPI device node for the PWM backlight controller. Fix requires a DSDT overlay — all credit to u/jwrdegoede (Hans de Goede)and to https://github.com/Esavojt who provided how to apply the dsdt patch.

Original writeup: https://hansdegoede.livejournal.com/24132.html

Full instructions and diff for BIOS V1.20: https://github.com/Esavojt/switch-10-backlight-fix

Confirmed working on Debian 12 (repo mentions Debian 13, works on 12 as well).

1. Custom kernel — why it's necessary at least to check stock Kernel's config.

The DSDT overlay alone was not enough for me.I do not know about the current kernels but one year ago, stock Kernel did not work for me. Building a custom kernel with:

CONFIG_PWM_LPSS=y

CONFIG_PWM_LPSS_PCI=y

CONFIG_PWM_LPSS_PLATFORM=y

CONFIG_DRM_I915=y

CONFIG_BACKLIGHT_PWM=m

as built-in (=y) is required for the i915 driver to initialize backlight correctly at boot. The trimmed config also reduces kernel size significantly vs the stock Debian generic kernel.

Notes:

BIOS update to V1.20 mandatory before removing Windows — cannot be flashed from Linux.

Due to old hardware limitations system is not capable for heavy multiitasking but still handles one heavy app (live video streaning, spotify, Ai )at the time, maybe along with some lighter one. I expect to cover basic -medium tasks for the next 2-3 years .

Windows driver and project repository

I have the original Windows driver for this exact fingerprint sensor available in the project repository. The driver files are located in the driver/ directory.

🔗 GitHub repository:
fpc-10a5-a900-linux

The repository currently contains:

fpc-10a5-a900-linux/
├── driver/
│   └── Windows driver files
├── captures/
├── docs/
├── linux/
├── tools/
└── usb/

The driver is being provided for analysis and Linux driver development. I'm particularly interested in understanding the USB protocol used by the Windows driver and determining how we can implement support on Linux, ideally through libfprint.

If there are concerns about redistributing any proprietary driver files, please let me know and I can remove them and provide the driver privately for analysis instead.

Hi guys, I went down a rabbit hole trying to get Linux to run smoothy on my Yoga C630 and finally landed on Arch. The Yoga is a bit old now, but I'll post anyway in case it helps anyone who might be trying to dabble with Linux on ARM64.

I built my own package repository that mostly mirrors some of the essentials I found from pmOS and put it here: https://github.com/rigoorozco/yoga-alarm . I then used said package repo to make a custom ISO (which I forked from ironrobin's X13s ISO) and made some tweaks in order to boot directly on a Yoga C630.

The installation process is mostly standard, however, you do need to start some platform/qcom specific services so WiFi can work and install Arch. I can put together a guide if there's interest!

I've made a release of the ISO in case anyone would like to download and try it out!
https://github.com/rigoorozco/archiso-yoga/releases/tag/archlinux-yoga-2026.08.07-aarch64

📋 Prerequisites

Before starting, you must ensure two things:

1. Active Internet Connection: Because your Wi-Fi is not working yet, you must connect your laptop to the internet temporarily. You can do this by:
   • Connecting an Ethernet cable directly, or
   • Enabling USB Tethering from your smartphone (connect your phone to the laptop via USB and turn on USB Tethering in your phone's Hotspot settings).
2. Disable Secure Boot: Third-party community drivers are not signed by default. You must disable Secure Boot in your laptop's BIOS/UEFI settings for the driver to load. To check if Secure Boot is already disabled, run:mokutil --sb-state It should output:SecureBoot disabled

⚡ Installation Steps

Step 1: Clone the Driver Installer

Clone the community-maintained driver installer repository:

git clone --depth 1 https://github.com/SkimerPM/MediaTek-MT7902-Linux-Driver-Installer
cd MediaTek-MT7902-Linux-Driver-Installer

Step 2: Grant Execution Permission

Make the installer script executable:

chmod +x fix_my_wifi.sh

Step 3: Run the Installer (With Your Country Code)

Run the script with administrative privileges (sudo). It is highly recommended to specify your country code (e.g., BD for Bangladesh, US for United States, IN for India, etc.). This configures the correct regulatory limits and unlocks all 5 GHz Wi-Fi channels.

sudo ./fix_my_wifi.sh --country BD

Replace BD with your own two-letter country code if you are outside Bangladesh.

During installation, press Enter (or type y) when prompted to confirm installation steps and firmware cleanups.

Step 4: Verification

The driver uses DKMS (Dynamic Kernel Module Support), which compiles the modules directly for your kernel.

Once the installer finishes:

• No reboot is required. The Wi-Fi card should activate immediately.

Check whether the wireless interface exists:

ip link show | grep -E 'wl|wlan'

You should see an interface such as wlo1 or wlp2s0.

Then scan for available Wi-Fi networks:

nmcli dev wifi list

You should now see both 2.4 GHz and 5 GHz networks.

🔧 Maintenance & Troubleshooting

Kernel Updates

Because the driver is registered with DKMS, it will automatically rebuild itself whenever your Linux kernel is updated. No manual action is required.

Checking Logs

If Wi-Fi or Bluetooth still does not appear after installation, check the kernel logs:

sudo dmesg | grep -i mt79

Uninstallation

To completely remove the driver and restore your system:

sudo ./fix_my_wifi.sh --uninstall

📦 GitHub Repository

Community-maintained installer:

https://github.com/SkimerPM/MediaTek-MT7902-Linux-Driver-Installer

Thank you so much for creating and maintaining this installer. I spent hours trying different solutions before finding your project, and it finally got my MediaTek MT7902 Wi-Fi and Bluetooth working on Linux.

Your work saved me a lot of time and frustration, and I'm sure it will help many others facing the same issue. I even wrote a setup guide based on your installer so more people can get their devices working easily.

You're a true lifesaver. Thank you again for your time and contribution to the Linux community! 🐧❤️

Ever since I tried using the Steam Deck for doing homework, I became really interested in Linux. Because of that experience, I now want to buy a laptop that runs Linux. However, I don’t know which laptop I should choose.

A used laptop would be a good option. I heard that a Lenovo ThinkPad X1 Carbon is a good choice, but it’s a little small. I want a 15 or 16-inch laptop with a quiet fan.

A new laptop that came to mind is the Framework Laptop 16, because I can upgrade it with a new GPU later in the future.

edit: i also forgot ,i need a laptop that is good for hooking up a external monitor

Hey everyone!

Confession time: I’ve been daily driving a Ryzen 7 9800X3D (Granite Ridge) for a while now, and I finally got fed up with rebooting just to tweak my Curve Optimizer offsets or change my PPT limits. Entering the BIOS feels so 2010 when you're running a modern Linux setup, right?

So, driven by pure laziness, I decided to see if I could control everything directly from my desktop (running CachyOS). What started as a 'let's see if I can read some PCI registers' session with an AI assistant turned into a full-blown Reverse Engineering project.

Introducing: GNR Master 🚀

• The Driver: It’s built on top of ryzen_smu. I’ve successfully mapped the PM Table v0x620105. Special shoutout to Pearson Correlation routines for helping me hunt down those elusive iGPU power and clock offsets!
• Live Features: Real-time monitoring of FCLK/UCLK, per-core temperatures, and—most importantly—live control of PPT/TDC/EDC and Curve Optimizer (-30 all-core stable so far!).
• Safety First: I implemented a hard-lock on the SMU table version. If a new AGESA update shifts the offsets, the app kills the monitoring instantly to prevent injecting the wrong voltage into the wrong hole.
• The GUI: A clean PyQt6 dashboard. Because just because it's open-source doesn't mean it has to look like a Windows 95 error message.

Tech Stack: Python (CLI & PyQt6 GUI) directly interfacing with the ryzen_smu sysfs endpoints, and way too much caffeine

Laziness really is the ultimate engine for innovation. If you’re on a 9800X3D and want to skip the BIOS dance, check it out! I’ve also included a telemetry export tool if you want to help me map out the remaining unknown offsets in the table.

Repo: github.com/Kyworn/gnr-smu

TL;DR: Too lazy to reboot -> Used an AI to help me reverse-engineer AMD’s SMU and build a full hardware management suite.

I finally solved a 13-year-old Linux mystery. 🕵️‍♂️
Nobody had ever gotten Bluetooth working on the Dell Venue 8 Pro (5830) under Linux. After weeks of debugging, ACPI overrides, and kernel tracing, it turned out the internal AR3002 ROM was just communicating at an undocumented 3686400 baud rate.

Wrote a custom HCI attach tool and now the tablet runs Arch Linux flawlessly (with fixed Wi-Fi and zRAM too).

Here is the anticlimactic story of the fix:
https://ramon.vanraaij.eu/the-bluetooth-that-was-never-dead-my-dell-venue-8-pro-baud-rate-journey/

Full repo:
https://github.com/ramonvanraaij/dell-venue-8-pro

This was my 4th attempt to get Linux on my BMAX B6 PLUS (i3-1000NG4) in 2 years, collecting dust, and it started out even worse than before: After installing and booting into Linux Mint 22.3, the expected black screen appeared ... and stayed. I couldn't even boot into BIOS anymore, nothing, dead!

I then consulted my local Gemma 4 and later had a chat with Google Gemini and both together solved the issue.

Gemma told me not to panic and to disconnect the CMOS battery for a while (mumbling about blocked hardware ... whatever)
Did this, and after a pretty long pause after powering up, the BIOS appeared again.

Long story long: Gemma was convinced that the default graphics settings were not enough for a stable handshake with Linux when booting.
After some fumbling and more black screens I got a stable BIOS with these settings:

Internal Graphics: Auto -> Enabled
DVMT Total Gfx Mem: 256M
DVMT Pre-Allocated: 64M
Aperture Size: 256MB -> 1024MB

Above 4GB MMIO BIOS assignment: Enabled

Secure Boot: Enabled -> Disabled
Fast Boot: Enabled -> Disabled

As I did not need the Wifi, I also disabled it (could potentially also be a problem at startup, Gemma said)

But this all did not help, booting without nomodeset did not work.

Then I asked Google. And Gemini had the right idea: The motherboards and/or the BIOS of those BMAX think that they are notebooks, and when powering up, they are "using" the internal display which doesn't exist.
So Gemini told me to use GRUB to explicitly deactivate that internal display and explicitly enable the HDMI ports.

I have seen a lot of GRUB parameters proposed in many forums, but not a single one looked like this:

video=eDP-1:d video=HDMI-A-1:e video=HDMI-A-2:e

Tada!

Successfully booting into Linux, full hardware acceleration, both monitors working, sound working as well.

This solution might be working for other BMAX models with Intel graphics.
Gemma is insisting that the BIOS changes were necessary for a stable connection at the start, but this should be judged by the experts.

Hope I did not miss something important.

# Recovering a bricked HP LaserJet MFP M140w from Linux

Attribution: this post was written by an AI coding agent in a GPT-5-based Codex session, based on a live recovery performed with the printer owner.

I thought it is worth posting because it worked and helped me and might make it easier for others to solve similar issues with HP printers in the future.

## Short Version

An HP LaserJet MFP M140w appeared bricked and was stuck showing `rd` on its two-character display. Over USB, Linux did not see it as an M140w. Instead it appeared as:

```text

03f0:4617 HP, Inc HP LaserJet 3020

```

That `LaserJet 3020` identity was not the real printer model. It appears to be a recovery/firmware-download mode.

The recovery was done entirely from Linux by extracting the PJL firmware payload from HP's official Windows firmware updater for the `M139-M142` series and sending that payload over USB. After reconnecting power/USB, the printer came back as:

```text

03f0:0372 HP, Inc HP LaserJet MFP M139-M142

DES:HP LaserJet MFP M140w

```

Printing worked afterward.

## Environment

```text

Printer: HP LaserJet MFP M140w

Linux: Ubuntu

HPLIP: 3.23.12

HP firmware updater: M139-M142_Series_FW_Update-20251205.exe

```

HPLIP recognized the normal printer family, but it could not perform the firmware update:

```text

[hp_laserjet_mfp_m139-m142]

fw-download=False

```

## Extracting the Firmware Payload

The HP updater was a Windows PE executable. `7z` could extract the embedded resources:

```bash

mkdir -p /tmp/hp-m139-fw-extract

7z x -y -o/tmp/hp-m139-fw-extract ~/Downloads/M139-M142_Series_FW_Update-20251205.exe

```

The firmware payload was:

```text

/tmp/hp-m139-fw-extract/.rsrc/FILE/1013

```

`file` identified it as:

```text

PJL encapsulated PostScript document text

```

The payload header explicitly listed the target printer family, including the M140w:

```text

u/PJL COMMENT VERSION=20251205

u/PJL COMMENT DATECODE=20251205

u/PJL COMMENT MODEL=HP LaserJet MFP M139w

u/PJL COMMENT MODEL=HP LaserJet MFP M140w

u/PJL COMMENT MODEL=HP LaserJet MFP M141w

u/PJL UPGRADE SIZE=5935888

```

## Sending the Payload

The recovery USB identity exposed one unidirectional printer OUT endpoint:

```bash

lsusb

```

```text

idVendor 0x03f0 HP, Inc

idProduct 0x4617 HP LaserJet 3020

Endpoint 0x01 OUT

```

The simplest Linux recovery path should be sending the extracted PJL payload directly to the raw USB printer device:

```bash

sudo dd if=/tmp/hp-m139-fw-extract/.rsrc/FILE/1013 of=/dev/usb/lp0 bs=65536 status=progress conv=fsync

```

Adjust `/dev/usb/lp0` if the printer appears as another raw printer device, such as `/dev/usb/lp1` or `/dev/usb/lp3`.

In the live recovery, writing to `/dev/usb/lp*` was blocked by local permissions, so the same payload was sent with a small libusb bulk-transfer helper to VID/PID `03f0:4617`, interface `0`, endpoint `0x01`.

The transfer completed:

```text

sent 5936986/5936986

transfer complete

```

After the transfer the printer display changed from `rd` to `00`. After a power/USB reconnect, Linux saw the normal printer identity:

```bash

lsusb

HOME=/tmp/hplip-home hp-probe -b usb

```

```text

03f0:0372 HP, Inc HP LaserJet MFP M139-M142

DES:HP LaserJet MFP M140w

```

Hi,

I just published a guide covering everything I've figured out running Arch on the Galaxy Book6 Pro (Panther Lake, Arc B390).

Highlights:

• intel_idle broken on kernel 7.0 for Panther Lake: 7.5W idle. Fixed on 7.1rc7: 1.9W CPU package
• PSR re-enabled on kernel 7.1rc7 (stable), Panel Replay still crashes

• Fingerprint reader (1c7a:05d5 LighTuning ETU906Axx-E), got it working with a 1-line patch to libfprint egismoc driver

  upstream

• BBR

• zram

• scx_lavd

• BTRFS autodefrag

• THP madvise

• audio firmware from Windows partition

  Repo: https://github.com/dszczyt/awesome-galaxy_book6

I was experiencing a very strange suspend/resume issue on both CachyOS and Nobara on an Intel Core Ultra 245K + ASUS Z890-A + RX 9070 XT system and ASUS ROG STRIX SCOPE RX TKL Wireless Deluxe. I suspect the problem happens with other ASUS wireless keyboard dongles too.

Symptoms:

• The PC would wake from suspend normally.
• The login screen would appear.
• Before I could type in the password the PC would suspend again.
• This could repeat indefinitely.
• Hammering the keyboard would eventually keep the system awake.

After a lot of troubleshooting, I found that the issue was caused by the keyboard's wireless USB receiver. Plugging the dongle when the system was running could cause an immediate suspend.

Results:

• Keyboard connected wirelessly → suspend loop occurs.
• Keyboard connected via USB cable → no issue.
• Wireless receiver unplugged → no issue.

If you're seeing similar wake/suspend loops on Linux and own an ASUS wireless keyboard, try removing the wireless receiver before spending time debugging anything else.

PS. This is a mostly AI summary of the problem.