marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | "Does XXX work yet?": https://alx.sh/fs | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-alt #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<amw>
For some reason my 6.4 kernel worked but in 6.5 efifb driver has grabs the memory first and then simpledrm tries to grab it again later and fails and results in NO FB device available at all...
<amw>
If anyone has a better place or way to report this issue I'm all ears - thanks
Armlin has quit [Remote host closed the connection]
Armlin has joined #asahi
capta1nt0ad has joined #asahi
Armlin has quit [Ping timeout: 480 seconds]
Armlin has joined #asahi
john-cabaj1 has joined #asahi
john-cabaj has quit [Read error: Connection reset by peer]
john-cabaj1 is now known as john-cabaj
Armlin has quit [Ping timeout: 480 seconds]
Armlin has joined #asahi
john-cabaj has quit [Quit: john-cabaj]
john-cabaj has joined #asahi
<janneg>
amw: simpledrm can't use aperture_remove_conflicting_devices since that might remove the the aperture from the hw specific device driver depending on probe order
<amw>
ok - but it works for me - so perhaps someone who understands this has a better fix...?
<janneg>
not sure what we can do to resolve the conflict between simpledrm and efifb
<janneg>
use the dcp driver
<janneg>
a better workaround would be either not to compile the efifb driver or block its loading
Armlin has quit [Ping timeout: 480 seconds]
<amw>
janneg: Those all seem like patching over the issue not really addressing it properly - but perhaps that's too hard. Thnks
<janneg>
how is using the proper display driver papering over the issue? both efifb and simpledrm are good enough for their purpose: displaying something until the real display driver can be loaded
kunev has quit [Ping timeout: 480 seconds]
Armlin has joined #asahi
<janneg>
solving usage priority issues between efifb and simpledrm seems mostly a non-problem for startup
<PaulFertser>
RPi users mostly complained about lack of WPA3 because they're using some odd distros (like armbian) which ship broadcom firmware not from the linux-firmware repository, and it just lacks sae support altogether. Also, it wasn't obvious at all that only iwd supported that part of the API.
<marcan>
*shrug*
<marcan>
maybe Cypress or someone from rPi should actually reply to my emails then
<marcan>
I already send my tree to the rPi folks and asked whether it breaks anything and haven't gotten any reports of breakage yet
<marcan>
maybe the Cypress firmware *also* supports the WSEC protocol that Broadcom uses
<PaulFertser>
Someone from rpi replied on that github ticket asking for more details, I provided everything I knew.
<marcan>
unless someone tests *my* patch and confirms it *actively* breaks Cypress devices with upstream kernel, there's nothing I need to do here
holiday has joined #asahi
<PaulFertser>
My point is that the old codepath also works but that doesn't matter if the new one is no worse.
<marcan>
if it also works with Cypress then it is correct
<marcan>
if it doesn't then someone better engage in the ML, because so far nobody involved with Cypress chips actively has
<PaulFertser>
Yeah, right, you shouldn't care more than the rpi foundation themselves.
<PaulFertser>
I'm just saying the old codepath actually works.
<marcan>
I mean I figured it would work with *some* firmware *somewhere*, otherwise it wouldn't exist :p
<marcan>
but it sure doesn't seem to work for everyone in the lovely mess that is rPi distros...
<PaulFertser>
Because they're shipping odd firmware versions instead of sticking to whatever is in the Linux git firmware tree.
<PaulFertser>
They just lack the -sae- function.
capta1nt0ad has joined #asahi
<marcan>
it would be helpful to, you know, get direct word from Cypress as to what happened here and how they ended up with that weird prop instead of the upstream Broadcom implementation
<marcan>
but so far, crickets
<marcan>
they've ignored all my emails
<marcan>
and it doesn't seem anyone cares, so it's probably a good idea to *actively* break some people and see if anyone notices
<PaulFertser>
We all know that.
<marcan>
otherwise we're just doing their job for them and walking on eggshells
<PaulFertser>
Your exchange on the mailing list was pretty convincing and apparently upstream wireless subsystem maintainers agreed it's the way forward.
<PaulFertser>
BTW, is firmware you extract from macOS compiled with -sae- , what's result of command similar to strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | tail -n 2 ?
<PaulFertser>
This lacks the feature list though, something like 43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.221 ...
<marcan>
yeah I think they don't do that for apple
<PaulFertser>
The API to get the feature list should still work, brcmf_feat_firmware_capabilities() would print it on probe if debug is enabled.
<marcan>
yes I'm pretty sure it would show up
<marcan>
too lazy to reboot with debug right now :p
<PaulFertser>
Apple asked them to be generous with the features, that's plenty of them :)
<marcan>
including the custom apple ones (awdl)
<PaulFertser>
BTW, with this offload SAE works but the corresponding AKM is never reported in "Supported Ciphers" section of "iw list".
<PaulFertser>
I also do not know if anyone tried it with Fast Transition enabled (it's yet another AKM).
dgb has quit [Ping timeout: 480 seconds]
dgb has joined #asahi
<marcan>
there's so much broken in that driver...
<PaulFertser>
The firmware also indicates support for OWE, that's nice.
<sven>
fwiw, the Apple Bluetooth firmware lies in the supported capabilities hci reply because xnu just completely ignores that anyway
<PaulFertser>
So /that/ was the reason you needed that quirk. Heh.
<sven>
yup :(
<sven>
I later realized that it just claims to support everything
<sven>
so far we only hit two things it lied about but it would not surprise me if we end up with a few more
holiday has quit [Ping timeout: 480 seconds]
Dementor3 has joined #asahi
Dementor has quit [Ping timeout: 480 seconds]
Dementor has joined #asahi
Dementor3 has quit [Ping timeout: 480 seconds]
dgb1 has joined #asahi
zumi has quit [Remote host closed the connection]
zumi has joined #asahi
dgb has quit [Ping timeout: 480 seconds]
dgb1 is now known as dgb
capta1nt0ad has quit [Ping timeout: 480 seconds]
<Emantor>
Cypress/Infineon seem to have no intrest whatsoever in upstreaming support for their wifi/bt chipsets. I have a Laird LWB5+ here where wifi using USB requires a clm blob to work and the downstream BT driver does some additional pokes to get BT to work…
<rkr11>
hey, is it possible to access network cards from grub? Trying to make setup to network boot linux from grub over http, but net_ls_cards returns empty in grub. Loading modules `efinet` and `net` does not help, so I was wondering if its not supported by current drivers/modules and is known
dgb has quit [Remote host closed the connection]
dgb has joined #asahi
Zeroine has quit []
Zeroine has joined #asahi
<janneg>
rkr11: usb ethernet adapters (with u-boot drivers) supposedly work. Not sure if u-boot has drivers for the brooadcom (1GB) or aquantia (10GB) chipsets. if it has those need firmware
<janneg>
wlan is powered off at boot (could be changed) but I don't think u-boot has drivers or wlan support
rkr11 has quit [Remote host closed the connection]
zumi_ has joined #asahi
zumi has quit [Ping timeout: 480 seconds]
zumi_ is now known as zumi
mkurz_ has quit [Ping timeout: 480 seconds]
levixxxx has joined #asahi
john-cabaj has quit [Remote host closed the connection]
john-cabaj has joined #asahi
levixxxx has quit []
levixxxx has joined #asahi
levixxxx has quit []
<marcan>
nor firmware
john-cabaj has quit [Remote host closed the connection]
<rkr11>
marcan: is it possible to maybe custom-build u-boot with that firmware to make wlan work?
<marcan>
u-boot absolutely does not have a brcmfmac driver
<marcan>
forget about it
<marcan>
we also aren't going to provision wifi firmware for u-boot like we do for aspeed
<marcan>
if you want to netboot the only practical options that could be supported are wired ethernet (internal or usb)
<marcan>
there is no wlan stack in u-boot at all as far as I know
<marcan>
and dare I say there should never be
<ar>
there's wlan stack in edk2, but that's a bit cursed
<marcan>
yes, I was about to say, down that path lies edk2
<marcan>
we are using u-boot and not edk2 for a reason
Szadek636 has joined #asahi
<marcan>
(mostly for our own sanity)
<rkr11>
marcan: yep, I wanna use wired ethernet (internal)
<marcan>
oh but you said wlan?
<marcan>
wlan = wireless lan
<rkr11>
yep, totally my bad, sorry! need lan
<marcan>
what device?
<rkr11>
m1 mac mini, my problem is wired ethernet is not detected currently in grub, no cards are visible basically
<PaulFertser>
Some other practical way might be to boot Linux+initramfs as first payload, and kexec from that.
<rkr11>
have yet to try if it will detect usb ethernet dongle tomorrow
<marcan>
PaulFertser: no, kexec is not supported and never will be
<marcan>
there is no way to reinitialize firmware
<marcan>
this is a platform limitation
Moprius has quit [Quit: bye]
<PaulFertser>
OK, that makes this platform special.
<marcan>
it took you this long to figure that out? :p
<ar>
marcan: "reinitialize firmware", as in the things that happen before m1n1, or in/after?
<marcan>
rkr11: as far as I can tell u-boot does not currently have drivers for any of the ethernet chipsets apple uses, no
<marcan>
ar: before m1n1
<marcan>
there is no way to fully reset any of the coprocessors to its boot state, because its boot state is loaded by iBoot
<PaulFertser>
Not able to kexec feels considerably more special than I could expect, yes :)
Szadek63 has quit [Ping timeout: 480 seconds]
<ar>
marcan: and adding a code path (triggered by a cmdline arg?) "expect these things to be already configured" would be too fragile, right?
<marcan>
I mean you might be able to once we have PSCI, just forget about GPU, video encoder, touchpad/keyboard (on M2+), and a few other things if the first kernel loaded any of those drivers
<marcan>
we already do a hideous handoff hack for the keyboard in u-boot and I'm not particularly keen on also implementing that for kexec
<marcan>
GPU is a lost cause
<rkr11>
marcan: thank you, that does save me lots of time digging into it. Gonna test the dongle way for now and see if it works for my use case. Thanks again!
<marcan>
ar: "being configured" = sharing memory with the kernel
<ar>
oh
<marcan>
handing that off is insanity
<ar>
yeah, doesn't sound like something that could be handled with kexec in a reasonable way
<marcan>
this is why apple reboots after the boot picker, they *can't* do it any other way
<marcan>
you could implement kexec by setting some environment/file flags and putting the new kernel/initramfs somewhere in the ESP and rebooting with a flag that tells u-boot to load that instead
Axenntio has joined #asahi
<marcan>
apple style ;)
<ar>
another, more realistic probably, approach would be to load a generic kernel+initrd, but instead of kexec-ing, it would pivot_root + init reexec (which is a common thing initrds do already). but that limits you to only netbooting different linux distros
<marcan>
and then you have a problem with modules
<ar>
right
<marcan>
(and kernel configs etc, like fedora uses selinux on by default)
<ChaosPrincess>
isnt kexec on it's way out on consumer hw anyway?
<ChaosPrincess>
the whole thing is incompatible with secure boot, and x86 oems are pushing that
<marcan>
does it even work properly for full consumer hw use cases anyway?
<ChaosPrincess>
not really
<marcan>
like I have an AMD machine with a Radeon and it absolutely doesn't know how to reset that upstream
<marcan>
I have to load an out of tree module to get vfio passthrough to work more than once
<marcan>
no way kexec works with that
<ChaosPrincess>
i have a nv card in my x86 box, can't kexec that sanely either
<marcan>
kexec always felt like a hack that is only useful for very restricted bootloader-type use cases and for kernel panic dumping purposes, not as a general-purpose thing
<ChaosPrincess>
you can easily kexec vms :P
<marcan>
oh sure :p
<marcan>
but that's also useless
<marcan>
since half the reason to kexec is speed
<marcan>
and VMs boot fast :p
<ar>
i don't remember ever getting kexec working on anything but VMs and *some* server hardware
<ar>
on x86
<ChaosPrincess>
i actually have a reason-ish to kexec vms, but i only need this due to some really stupid workarounds for a certain hypervisor
<PaulFertser>
RHEL has kexec-based dumping on panics enabled by default.
<ar>
ChaosPrincess: whose name starts with "V" and ends with "mware"? ;)
<ChaosPrincess>
might be that :P
<ar>
one usecase I have for kexec, is replacing distros in vm instances with things that a given vm provider doesn't officially support
<ar>
but that's also flaky
<marcan>
PaulFertser: that one is plausible because the NVMe controller is one of two things that are designed to be handed off, though it will probably still need some horrible code to make it work when the first kernel *panicked*.
<marcan>
(the other one being DCP)
<marcan>
(well okay and SMC I guess)
<ChaosPrincess>
make pstore over nvram, dump panic data into pstore :P
<marcan>
but as a strict panic dumper kexec thing only, with a special kernel with all the other drivers disabled
<marcan>
ChaosPrincess: I think macos actually dumps it into one of the extra nvme namespaces
<ChaosPrincess>
it is a neat trick when you control the platform
qyliss has joined #asahi
Axenntio has quit [Quit: Axenntio]
Axenntio has joined #asahi
Axenntio has quit []
rkr11 has quit [Remote host closed the connection]
<sven>
i'm still not sure how they do that dump since iirc that namespace is read-only with our driver. probably needs some special commands
sefidel has quit [Remote host closed the connection]
sefidel has joined #asahi
holiday has joined #asahi
nicolas17 has joined #asahi
SalimTerryLi has quit [Read error: No route to host]
SalimTerryLi has joined #asahi
SalimTerryLi has quit [Remote host closed the connection]
SalimTerryLi has joined #asahi
holiday has quit [Quit: WeeChat 4.1.1]
holiday has joined #asahi
holiday has quit [Quit: WeeChat 4.1.1]
john-cabaj has quit [Remote host closed the connection]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #asahi
john-cabaj has joined #asahi
joshheyse has joined #asahi
john-cabaj has quit [Ping timeout: 480 seconds]
delsol has joined #asahi
lucyllewy has joined #asahi
Chai-T-Rex has quit [Quit: Chai-T-Rex]
<nicolas17>
looks like all all M3 Macs ship with macOS 13.5 22G2074, and all M3 Pro/Max models ship with 14.1 23B2073
<nicolas17>
if anyone gets a machine I'd like a filesystem dump >.>
<nicolas17>
and let me know if you get (or hear of) anything different, such as any M3 coming with 14.1 (which build?), or any Mac at all coming with 13.5 22G2080 (it exists but we don't know where)
ciiur^ has quit [Remote host closed the connection]
Rgn has joined #asahi
Rgn has quit [Quit: Page closed]
mkurz_ has quit [Ping timeout: 480 seconds]
fossdd_ is now known as fossdd
<kidplayer666>
That sounds weird
<kidplayer666>
Kinda random as they got launched at the same time?
<kidplayer666>
Maybe they started manufacturing the more popular normal models before the pro ones?
<delsol>
kidplayer666: seems reasonable.
<kidplayer666>
Still odd
<kidplayer666>
Cause if I’m not mistaken this process should’ve started a while ago
<delsol>
especially since rumors were suggesting possibly only M3 released, but discuss/introduce M3Pro, M3Max... shipping at later date (likely after holidays)
<kidplayer666>
So all should have old software
<kidplayer666>
Ahh
<kidplayer666>
Maybe that’s it
<kidplayer666>
Huh last minute change?
<kidplayer666>
Maybe they cancelled 13” at last minute?
<delsol>
kidplayer666: I think its possible that yields on M3Pro/M3Max were shit, and expected to take far longer to get in qty needed.....
<kidplayer666>
So it wouldn’t make sense to debut the m3 exclusively on the IMAC?
<kidplayer666>
Fair enough
<delsol>
other questions is whats the QTY?
<kidplayer666>
Quantity?
<delsol>
people bitching about pro being 6p6e instead of 8p4e... but the ramifications are far far bigger.
<delsol>
before EVERY single M1Pro/M2Pro that they shipped... was a crippled M1Max/M2Max that they cut off half of the GPU.
<kidplayer666>
The problem is more
<kidplayer666>
That they now kinda hide a bit more the reduction in p/ e cores
<delsol>
if you need to sell 100k M2, 20k M2Pro and 15k M2Max.....
<delsol>
thats more than 50% of the M2Max dies you are cutting 40% off of...
<delsol>
and the people bitching about memory bandwidth are fools.
<delsol>
M2Max may have 400GB/s of theoretical memory bandwidth... but real world from memory to cores.... is only about 225GB/s
<kidplayer666>
Most certainly
<kidplayer666>
Unless you’re a 4060 ti owner :P
<delsol>
Sapphire Rapids with its 8 channel DDR5 controller... and socket TDP of 380w.... only gets real world 250GB/s from memory to cores.
<kidplayer666>
In which case I understand the trauma
<delsol>
and whats worse, is to get the 250GB/s from memory to cores on sapphire rapids... you need 32 or more cores.
<nicolas17>
kidplayer666: yeah it seems like M3 was intended to launch earlier and for whatever reason didn't?
<kidplayer666>
But it doesn’t include a GPU
<kidplayer666>
Which is way more bandwidth dependent
<delsol>
kidplayer666: yes and no.
<kidplayer666>
nicholas17: yeah, kinda odd
<kidplayer666>
The simple answer is waiting for actual reviews
<kidplayer666>
Instead of whatever crap Apple might be spweing
<delsol>
kidplayer666: thats the other gotcha.... the previous setup GPU wasn't able to use all the memory bandwidth either.
<kidplayer666>
I remember on the M2 pro or something release
<kidplayer666>
How Apple claimed 6x better performance
<kidplayer666>
On rendering
<ChaosPrincess>
delsol: the bitching about pro not having 8+4 is that people who mostly care about cpu perf above all else, and the gpu is "meh whatever" now have to buy the max
<kidplayer666>
(Cause they had a project that took advantage of those extra few gigs of ram)
<delsol>
ChaosPrincess: other than how many workloads are going to be actually more performant on 8p4e vs 6p6e?
<kidplayer666>
delsol: if the theoretical limit is lower, the proper limit is probably lower too
<delsol>
and how much die space do you want to spend on it....
<ChaosPrincess>
delsol: all of my workloads, and throw all the die at it, tia
<delsol>
ChaosPrincess: then you don't want an M3Pro or M3Max...
<delsol>
you want an M3-ShortIntelStockToday.... 4 M3-Max dies bolted to an IOdie with another couple memory channels for those huge memory footprint workloads, along with a pile of PCIe lanes....
<ChaosPrincess>
well, yes, i want a threadripper, but guess how that line was going the previous years
<delsol>
in all seriousness, most apple workloads wouldn't benefit much from an -Extreme 4x die setup.....
<delsol>
but if linux was better supported on it, plenty of big linux server workloads would run fucking amazeballs on it, and justify the 10k/15k/20k pricetag such a machine would demand.
<ChaosPrincess>
"Apple workloads" sounds like cope from the "macs are for video only" crowd :P
<delsol>
lol, no
<delsol>
See also Ampere Altra benchmarks....
<ChaosPrincess>
Shit singlecore, ancient arm cores
<kidplayer666>
If Apple wants to be taken seriously then it does have to cater to those power users
<delsol>
single threaded blows chunks, but if you are doing a metric fuckload of separate VM's that don't need single threaded..... throughput is huge for the price.
<kidplayer666>
I’m kinda curious about windows on arm
<kidplayer666>
Cause Qualcomm deal is expiring soon
<delsol>
kidplayer666: Amdahl's law basically says that those workloads are few and far between.
<kidplayer666>
And mediatek has been closer and closer to Qualcomm in the mobile space
<kidplayer666>
So I expect on a laptop chip that is slightly less power constrained a bunch of competition
<kidplayer666>
Especially cause NVIDIA might be thinking about it too
<delsol>
and at the clockspeeds apple is now pushing on M3 cores... if the cores are as powerful as expected, plenty of "big xeon" workloads would likely be faster on an M3-Max than the xeon.
<delsol>
because the big xeons don't clock for crap, chug power, and even four times as many cores doesn't make a difference if 10-15% of your workload execution time is single threaded and your single threaded performance is 20% lower.....
<delsol>
See also: no consumer 5000 series threadripper..... because at the pricepoint the Threadripper Pro was plenty beefy to handle most of the single-workload setups as fast if not faster than a Dual EPYC....
<delsol>
(memory bandwidth and cache is also a large consumer of power.... and for a laptop chip, it makes a reasonable difference in potential battery life)
billak has joined #asahi
<ar>
even the AM4 5950x was quite popular as a server chip, despite having "only" 16 cores
<ar>
and the 3950X before that too
ChaiTRex has joined #asahi
<delsol>
Yes, on non-bandwidth limited workloads.
<kidplayer666>
Now there is 7000 series tho for threadripper
<delsol>
single threaded performance increases of higher clocks made up the difference....
<kidplayer666>
How long it’ll last, it’s anyone’s guess
<delsol>
But look at the 7000 series....
<delsol>
take a goood look at the clock speeds. ;)
<kidplayer666>
It really feels like
<kidplayer666>
We finally got out of the 2010s boredom
<kidplayer666>
Intel is getting kicked in the nuts, but slowly trying to respond
<kidplayer666>
Apple made their own chips, for crying out loud
<kidplayer666>
Windows has launched a new version
<kidplayer666>
Despite promising 10 was the last one
<kidplayer666>
Windows 12 rumours exist!
<delsol>
kidplayer666: you see people that have run the dev builds of windows for ARM on M1/M2?
<kidplayer666>
On a vm?
<kidplayer666>
I heard it kicks qualcomms chips in the nuts
<kidplayer666>
Beats their best chips by a fair margin on a gm
ydalton has joined #asahi
<ydalton>
kidplayer666: yes, the m1/m2 are the most powerful consumer level arm chips available
<kidplayer666>
So far
<kidplayer666>
Cause m3 is coming soon lol
<delsol>
non-GPU stuff appears to blow the pants off of windows on x86 laptops....
<kidplayer666>
Exactly
<delsol>
but look at what it was doing.....
<kidplayer666>
But Qualcomm x elite may be interesting
<delsol>
look at benchmarks of random tasks..... M2 at 3.4ghz was competing with intel P cores at 5.5ghz.
<kidplayer666>
And there’s rumours mediatek may partner with NVIDIA for graphics
<delsol>
kidplayer666: I don't think so. I think its the flipside.... NVIDIA is going to just build their own arm shit with the own GPU.
<delsol>
(and potentially license a bunch of the rest of the SoC stuff from mediatek)
<kidplayer666>
That’s also possible
<ydalton>
"non-GPU"? i'm pretty sure agx is more powerful than integrated graphics on intel
<kidplayer666>
They probably don’t need to licence anything
<kidplayer666>
ydalton: Not on a vm
<delsol>
it already is, see also Nvidia Grace/Grace-Hopper
<kidplayer666>
Just a matter of remembering first surface was NVIDIA powered
<kidplayer666>
And so is the switch
<ydalton>
kidplayer666: what do you mean not on a vm
<kidplayer666>
ydalton: not sure how well the GPU runs through the vm
<ydalton>
i thought you meant in general
<delsol>
ydalton: windows GPU drivers to run as a VM on M2-Ultra even.... not so great.
<delsol>
because you're emulating a GPU with CPU....
<kidplayer666>
Fun
<delsol>
basically an emulated Matrox G200e
<kidplayer666>
Sheesh…
<delsol>
hey, don't fuck with the G200e, G200e is a great GPU for all sorts of shit.
<delsol>
several of my hackintosh's had G200e's
<kidplayer666>
You could always brute force your way by having many cpu cores
<ydalton>
how does the hypervisor framework work though? cuz i know you can gpu accelerate with that
<delsol>
not really, that would take EPIC/VLIW style architecture.
<delsol>
ydalton: still need drivers.
<kidplayer666>
ydalton: your first project :P
<ydalton>
am not interested in windows
<delsol>
you can take a Geforce 4090 back to 1997, plug it into a PCI to PCIe bridge chip and put it on your overclocked dual socket celeron machine... and it still aint gonna do shit.
<kidplayer666>
Hehe
<kidplayer666>
Sounds like a fun project
<delsol>
kidplayer666: no, a fun project was an ALR Revolution 6x6... with 6 pentium pro's (3 socket 8's per CPU daughterboard...)
<ydalton>
something for ltt
<delsol>
with 6 socket 370 to socket 8 adapters.....
<delsol>
and six P2's, P3's or celerons.....
<ydalton>
i'm too young to remember any of those except the celeron
* delsol
actually worked on one with a buddy in college. We only ever got 4 CPU's operational with the adapters....
<kidplayer666>
I’m too young to remember any of that
<ydalton>
i heard rumours the m2 was supposed to be what m3 is now
<delsol>
so what was your era of experimenting with shit to see what you could accomplish?
<delsol>
I'm basically backwards in this channel..... did most of my stuff on mac, later OSX.... and did a shitload of hackintoshing for a while....
<ydalton>
dunno, the closest thing was getting gpu passthrough working on my desktop
<delsol>
in ESXi or Proxmox?
<ydalton>
just libvirt/kvm
<delsol>
ahhh
<ydalton>
kinda got me into the linux space after seeing mutahar demonstrating it
<delsol>
I had plans of using Proxmox to finally solve a goal that I've been trying to solve for like 20 years....
<delsol>
Multi-headed Multi-seat......... one computer to rule them all, with dual monitors in this room, that room, and the other room..... 3 sets of keyboard and mice... and be able to log in and out, and take home directory/environment/etc with you from one room to another.
<ydalton>
can't you do that in linux anyways?
<ydalton>
well you'
<delsol>
not really.....
<ydalton>
you'd need quite long cables to connect from one room to the other
<delsol>
you can have 1 machine act as 3..... with 3 separate VM's....
<ydalton>
no
<ydalton>
multi seat setups
<ydalton>
multiple monitors and sets of keyboard and mice with linux
<delsol>
Yes.... but they don't work right.
<delsol>
but you can't lot out of kitchen, log into bedroom and get your environment back.
<ydalton>
what do you mean your environment back?
<delsol>
not fully log out rather, but kick to screensaver login......
<delsol>
and then re-connect to running session on other seat.
<delsol>
watching video side by side IRC. pause, go to loginwindow...... move to different room that is on loginwindow, log back in, have IRC windows still connected and video ready to hit play again.
<delsol>
About the closest thing that truly exists as a real solution was Sun Microsystems "hoteling" system..... where every desktop/cubicle had a machine, a phone, and a smartcard reader.
<delsol>
Insert your smartcard, and it logs you in as you, with your (over network home environment), forwards YOUR phone extension to the phone on the desk, and marks your position on their own internal user-tracking map thingy.
<delsol>
but that still required you to save and close all of your applications.....
<delsol>
to re-open them on a different instance later.
<ydalton>
i see
<delsol>
(Citrix also almost does it.)
ydalton has left #asahi [ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.0.92)]
<delsol>
the way to do it with Proxmox that I was planning on doing was to basically use one instance to trigger webserver to pause my VM, unconfigure its passthrough, and then on login, trigger webserver to reconfigure device passthrough for new seat (new USB bus, new GPU, new displays) and resume the VM.
<delsol>
but there are some GPU considerations and gotchas there.....
dgb has quit [Remote host closed the connection]
dgb has joined #asahi
<delsol>
(Namely GPU state and GPU memory are lost on switch..... and while Nvidia has some special tools to deal with that with Grid enabled GPU's.... AMD's GPU's don't have the whole toolset you truly need to make it seamless.... and grid enabled GPU's weren't in my budget or supported in all the OS's I wanted....
zumi_ has joined #asahi
zumi has quit [Ping timeout: 480 seconds]
zumi_ is now known as zumi
delsol has quit [Remote host closed the connection]
<kidplayer666>
what were "all the OS'S you wanted?
<dbm5>
refreshing to find a group using IRC instead of discord
<kidplayer666>
Fair
<kidplayer666>
We gotta do discord but OpenSource and not sucking
<kidplayer666>
Just fix the entire matrix protocol :P
<nicolas17>
lmao it's a legal holiday in the US?
<ChaosPrincess>
there are legal holidays over there?
atipls has joined #asahi
<nicolas17>
ok not a holiday
<nicolas17>
"The 2023 United States elections are scheduled to be held, in large part, on Tuesday, November 7, 2023. The off-year election includes gubernatorial and state legislative elections in a few states, as well as numerous citizen initiatives, mayoral races, and a variety of other local offices on the ballot."
<ChaosPrincess>
yep, that is happening, and a certain state has a "do we backslide further into authoritarianism" on the ballot
<nicolas17>
why the heck did Apple release new hardware today and then not leave anyone to fix the trash fire in the update servers
ydalton has joined #asahi
<ydalton>
well, it's not much of a holiday if ya still gotta go out and vote :P
<opticron>
The USA does not get holidays on voting days, just FYI. You generally have to take off work to do it or go outside of work hours.
<ydalton>
it's not mandatory to vote there is it?
<jn>
i guess it would be too democratic to simply vote on sundays
c10l has joined #asahi
<kidplayer666>
yep
<kidplayer666>
here in portugal its always on a sunday
<opticron>
ydalton, no, it's not mandatory
<nicolas17>
ok Apple released 13.6.2 and 14.1.1 and fixed the mess
<ydalton>
nicolas17: the ProMotion bug and recoveryOS not being updated bug?
<nicolas17>
ydalton: no, the "M3 Macs ship with 13.5 and can't be updated" bug
<nicolas17>
no idea if they did anything with ProMotion
<nicolas17>
ydalton: actually I think they may have fixed ProMotion
<nicolas17>
because 13.6.2 is *only* for "MacBook Pro (2021 and later) and iMac (2023)"
<ydalton>
would marcan receive official confirmation from apple?
ydalton has left #asahi [ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.0.92)]
<nicolas17>
hopefully
<cy8aer>
Silly in the early days of linux I waited for a month when a new kernel was published before I installed it. Today you need to wait for something like new macOS versions for a month before install it.
<nicolas17>
ydalton: confirmed!
<nicolas17>
marcan: they fixed the ProMotion issue!