| Website | https://val.packett.cool |
| Nerdy Linktree | https://keyoxide.org/aspe:val.packett.cool:DV7YKMH5QMHF5ZVU5UUSIXXXMI |
| Pronouns | she|they |
| Pronombres | ella|elle |
| Cuenta alt (en argentino) | https://rebel.ar/@val |
| Pixelfed | https://luzeed.org/@valpackett |
https://gitlab.com/qemu-project/qemu/-/issues/2574
kernel's cursed? kvm's cursed? hardware's cursed?
the debian rocm team using full PCIe passthrough was getting a "VM crashes with EFAULT when accessing GPU memory"… and i'm seeing the same symptom with two different non-passthru setups (qemu+gfxstream and crosvm+native-context) on an integrated gpu?!
courtesy of @davidgerard, Proton is now the only privacy vendor I know of that vibe codes its apps:
> In the single most damning thing I can say about Proton in 2025, the Proton GitHub repository has a “cursorrules” file. They’re vibe-coding their public systems. Much secure!
I am once again begging anyone who will listen to get off of Proton as soon as reasonably possible, and to avoid their new (terrible) apps in any case. https://circumstances.run/@davidgerard/114961415946154957
Proton’s Lumo AI chatbot: not end-to-end encrypted, not open source https://pivot-to-ai.com/2025/08/02/protons-lumo-ai-chatbot-not-end-to-end-encrypted-not-open-source/ - text https://pivottoai.libsyn.com/20250802-protons-lumo-ai-chatbot-not-end-to-end-not-open-source - podcast https://www.youtube.com/watch?v=HDPZbUPUFyk&list=UU9rJrMVgcXTfa8xuMnbhAEA - video
Now we're cookin'.
(This is still very slow cookin' because SD LOL, but in the traditional "high" speed mode the top number was 20 MB/s.)
"hm, let me finally investigate that UHS SD card issue"
"is there anything about the modes in the other dt- OHHH"
This thread has taken too much of my time & energy, and I'm shifting that to elsewhere. I've preserved the thread here: https://ghostarchive.org/archive/JfGbx
Feel free to stop reblogging. I still would like to see pixelfed actually publish the vulnerability report on GitHub, and fix the issue with followings on pixelfed being out of sync with remote accounts due to this bug, but whatever.
hey, if you're at #why2025 and you (somehow) have something you want to send to me in particular, I have a local friend who went over there who can take things for me! You'll get a sticker from our hacklab in return!
Anyone wanna get rid of a spotify car thing, rabbit r1, or some other embedded Linux/Android junk like that? :3
I am very glad that I spent my weekend watching dinosaurs with my sweetie
but also
I would be less stressed if I had spent more of that time doing meal prep and chores 😅
Now we're cookin'.
(This is still very slow cookin' because SD LOL, but in the traditional "high" speed mode the top number was 20 MB/s.)
@valpackett hm could it be ur missing a BAM node in ur dts?
for msm8960, Sam helped me figure out that single byte write to the sd card/emmc were fine, just big writes would cause it to fail
https://github.com/torvalds/linux/commit/5ee449c75f49c9a6b0cbff7848f922183e7888c1
this finally solved the problem for me
@Logical_Error bam hasn't been used for sdhc for quiiiite a while xD By sdm845 there were only cryptobam and slimbam; in current socs only cryptobam is left it seems.
This is not about writes; this is actually about reads, specifically in SDR104 mode (well maybe other UHS modes but not HS); and seemingly specifically early reads (like reading GPT/FS headers). And it wasn't seen on reference platforms, only on production laptops. Actually I should test adding delays on probe xD
[object Object]
Emelia 👸🏻
a len ur len could smell like
LogicalErzor