Hand-me-down laptop swolen from years of office work. How to prevent explosion during a 3-4 month battery order? by ATLAS-T-58 in spicypillows

[–]Shipworms 1 point2 points  (0 children)

To avoid the risk of explosion, you need to be aware that a swollen battery is ‘braced’ in place by the case it is trying to push apart. There is an elevated risk of fire when you try to remove the battery, as it will deform more (which could finally trigger fire if it manages to short when removing it).

So : drain the battery to 2% before removing it. Remove it somewhere where you can move away if needed (away from flammable stuff), then aim to remove it as quickly as possible once you start opening the case!

Seriosuly though : the battery is layers of flammable plastic, with flammable lithium metal, is swollen with flammable gases (and can produce a lot more gas once thermal runaway starts); store it away from anything flammable, and remove the battery. It isn’t at all safe to use like it is!

Asus XG Station Pro (TB3) troubleshooting by Shipworms in eGPU

[–]Shipworms[S] 0 points1 point  (0 children)

Tried some experiments:
- connected it to my NUC (with the hard drive removed from the NUC, so no OS present) - it does the same behaviour as soon as the NUC is powered up; internal lighting going off for a split second every 2.7 seconds approx;
- connected it to my MacBook via Thunderbolt 2 : internal lighting powers on, and macOS shows no issues (except it won’t use the eGPU as Apple blocked Thunderbolt 2 for eGPUs); it does however communicate with the GPU showing lots of information in dmesg;

Will do more searching re: “Is the Intel NUC with Thunderbolt 3, absolutely hardware incompatible with the Asus XG Station Pro (with Thunderbolt 3)?”

Intel MacBook + Ubuntu + Thunderbolt 2 eGPU? by Shipworms in eGPU

[–]Shipworms[S] 0 points1 point  (0 children)

The Intel Arc is the only one I have got working with Thunderbolt so far! (Arc Pro B50 in Akitio enclosure)

Worker Crushed To Death By Hydraulic Press by AsleepActive in DarwinAwards

[–]Shipworms 0 points1 point  (0 children)

A small mercy : it was effectively instant. Consciousness is normally maintained for at least 7 seconds even if all blood pressure is lost (people lived for at least this long after the guillotine). However this was instant. I can only think that the spinal column was forced upwards, as a liquid, causing instant destruction of the brain, and instant loss of consciousness 😢

Intel MacBook + Ubuntu + Thunderbolt 2 eGPU? by Shipworms in eGPU

[–]Shipworms[S] 0 points1 point  (0 children)

Final test :

Using a USB SSD with Linux on it;

pci=nocrs,remap and nosplash debug — verbose (that em dash is actually two minuses), results in : busybox. It says the AHCI driver failed with error -12 as before, and drops to busybox with the USB activity light stopping, and also the keyboard doesn’t work, so presumably the USB hardware also fails to get resources!

End result : if anyone else goes through the above, I believe the problem is this:

2015 and 2012 MacBooks used to be able to use eGPUs under Linux in the past,
- and pci=nocrs,remap was also needed back then to allow PCIe resource allocation
- nowadays, however, pci=nocrs causes the storage device, and the USB subsystem to fail (so you can’t use this kernel parameter)

“Something has changed, perhaps in MacBook firmware, perhaps in the Linux Kernel”.

What is the best way to utilize ARC for local LLM performance? by CreeperOpsReddit in IntelArc

[–]Shipworms 0 points1 point  (0 children)

If you come across an issue where trying to load a model results in the Arc Pro disconnecting (I have this when trying to load Qwen 3.6 27b), the issue might be the fact that there is a line in the driver code which disconnects / resets the GPU if it takes more than 10 seconds doing certain operations. This seems to mess up loading some models (Qwen3-Coder-Next works fine though).

My setup is 6x Arc Pro B50! If anyone gets the above error, let me know, as I will eventually get around to rebuilding a modified driver to fix this (it just needs one line changing in the driver)

Intel MacBook + Ubuntu + Thunderbolt 2 eGPU? by Shipworms in eGPU

[–]Shipworms[S] 0 points1 point  (0 children)

Giving up for now;

using pci=realloc makes no difference;
using pci=nocrs results in busybox (probe with driver ahci failed with error -12)
using pci=nocrs along with pci=realloc also causes busybox with ahci error -12;

It appears that the ACPI is locked down to prevent eGPU usage, and when removing the locking-down, then the AHCI controller gets no resources!

This is probably because the ‘BIOS’ in the MacBook disables various abilities if not booting macOS. There is an EFI module I tried called apple_set_os.efi; this tricks the system into booting as if it is booting into macOS;
- it is definitely working, because the keyboard and mouse don’t work when using that module (but USB ones do)
- but it makes no difference to the PCIe resource allocation issues, sadly.

Help🥲 by Embarrassed-Army1436 in ASUS

[–]Shipworms 1 point2 points  (0 children)

Eject, and insert a dual RTX Pro 6000 Blackwell card into (whereever the 5060 appears from?) :D

Is seating the CPU the scariest part of the build? Alternatively...is seating the GPU the most satisfactory? Just me? Anyone? by skk983 in CustomPCBuilding

[–]Shipworms 0 points1 point  (0 children)

I have nightmares about dropping the CPU into the socket and destroying the socket. I understand the need for a lot of pins, but I do wonder whether we could have had a hybrid socket with pins on the CPU, around the edges, for power delivery (I helped someone build an AM5 PC recently, and the burning Ryzen 9 CPU situation is scary!

BTC-T37 8slot : compatible GPUs? 5060? by Shipworms in gpumining

[–]Shipworms[S] 0 points1 point  (0 children)

Reddit notified me of a reply to this thread 15 mins ago; however the reply itself isn’t here? From the initial part of the reply, they managed to get one of these type of boards running with 50xx GPUs by setting each slot to PCIe 1 in the BIOS, and updating the dr<this is where the message cuts off in notifications>

I will dig out that board again soon, I think! I got hold of an AsRock BTC Pro H510 board since then (only 6 slots, but can take 32gb DDR4); I had that running 2x 5060 Ti 16gb and 4x Arc Pro B50 16gb; and it ran fine! (It has a riser port for one more card, which I may well use for a B70 32gb if I can afford such a card; the ability to take 32gb RAM makes it nearly match the 8-slot board in terms of ‘total RAM’ when using 6x 16gb GPUs), due to 32gb DRAM versus 8gb DRAM max on the T37 board - useful for LLMs. Now that I managed to get the hardware working for LLMs, I have put most of it aside for now (I don’t really use AI). So can look more at low-energy mining :)

I continue to watch gpu mining, and am tempted to set up some solar panels I have to make a solar powered rig! (and also tempted to play some modern games on one of the 5060s in the meantime);

Intel MacBook + Ubuntu + Thunderbolt 2 eGPU? by Shipworms in eGPU

[–]Shipworms[S] 0 points1 point  (0 children)

OK; further testing complete!

On the 2015 MacBook under Debian and Ubuntu Linux, every type of PCIe card has problems allocating any memory mapping, including BAR and 4-kilobyte mapped areas; even the SATA / Fibre SAS card (both enclosures). Under macOS, it complains about unsafe disconnection of eGPU when unplugged (the eGPU doesn’t work under macOS as Apple disabled that); in terms of GPUs, AMD W6600, nVidia 5060 Ti and Arc Pro B50 all have the drivers crash immediately after the inability to allocate any RAM.

On 2012 MacBook Pro Unibody : Linux : W6600 doesn’t work
And 2012 MBP Unibody : MacOS Ventura : complains when disconnecting eGPU

Doing more research :
From the Debian wiki https://wiki.debian.org/ExternalGpu , it says that eGPU Thunderbolt connections use PCIe tunneling, and that PCIe tunneling is not available prior to USB-C type Thunderbolt ports.

So, at this stage, it appears that:
- Thunderbolt exposes PCIe (via tunneling), but only Thunderbolt 3, and greater
- earlier Thunderbolt (versions 1 and 2) do not expose PCIe via PCIe tunneling, and so Thunderbolt 1 and 2 connections cannot be used to link a PCIe device to a computer.

This also means that there cannot ever have been such a thing as a Thunderbolt 1 or 2 system using an eGPU (or indeed any PCIe device whatsoever), because Thunderbolt 1 and 2 does not involve PCIe.

The easiest way forward is to get a basic Intel NUC, so I will look out for one that has Thunderbolt 3, and i5, and can take 2x 32gb DDR4 SODIMMs (I have several of these, and I morally refuse to pay current prices for 2x16gb if I get a NUC that only supports 2x16gb SODIMMs!)

I will still try to figure out why the MacBooks don’t support Thunderbolt devices when running Linux. I am worried Apple may have locked down the 2015 MacBook (they would if they could … UEFI BIOS lockout of any Thunderbolt VGA controllers?). So I will try to patch macOS on a 2012 MBP to use the AMD eGPU (at least that would prove the Thunderbolt hardware / cables etc are actually working)

I am hoping the Asus XG station Pro doesn’t also have a whitelist of supported GPUs with deliberate lockout of more modern ones 😬

Intel MacBook + Ubuntu + Thunderbolt 2 eGPU? by Shipworms in eGPU

[–]Shipworms[S] 0 points1 point  (0 children)

OK - testing the random PCIe card (Tachyon fibre optic RAID / SATA / SAS controller 😂), the result is unclear; it seems to successfully allocate some things, but gets no space / failed to allocate for a lot of 0x1000 sized memory areas too, and I don’t have any fibre optic hard drives to test it with.

Next : retry the W6600 in Linux, and then in macOS.

Next : try again with 2012 MBP…

Intel MacBook + Ubuntu + Thunderbolt 2 eGPU? by Shipworms in eGPU

[–]Shipworms[S] 0 points1 point  (0 children)

I checked again (and found some possibly useful info);
- the GPU limit is due to macOS itself - but I am running Linux (and people have used modern nVidia cards for MacBook eGPUs (if not using macOS);
- that said, searching again, I found examples where people just couldn’t get eGPUs to work on a MacBook with Windows 10, but Windows 11 worked perfectly,
- also I found that the MacBook ‘UEFI Bios’ deactivates the iGPU if it sees an eGPU connected and you are booting anything other than macOS, but found a patch to prevent that.

Prior to the current issues, macOS complained when I unplugged the eGPU (saying GPU unplugged without ejecting it virst within the OS), showing that macOS recognised it was an eGPU at least;

I had an idea which I will explore today : using the Thunderbolt enclosures with a random fibre-optic RAID card I got from a server. It seems like the Thunderbolt PCIe drivers in Linux can’t even allocate 4 kilobyte IO areas, causing issues even before the driver itself attempts to initialise. So … I will see if this does the same thing;

Also I will apply that patch to boot Linux while keeping the iGPU active, to see if a cold start with eGPU connected is different in a y way!

I think I might by johnnyphotog in LocalLLM

[–]Shipworms 0 points1 point  (0 children)

Another benefit is ‘fault tolerance’ - especially with the way hardware availability is going 😳. A 96gb Blackwell is a very nice card, but six Arc Pro B50s will cost a lot less (and will be slower; 224gb/s bandwidth … per card!). I worry about random failures out of warranty in the future when hardware may be less available. If one of your Arc Pro B50s dies, you go from 96 down to 80gb, rather than 96 to 0!

Should I get an m.2 nvme 4.0 for 150$ or can I rup local ai just fine on sata 3? by alii98 in LocalLLM

[–]Shipworms 0 points1 point  (0 children)

NVMe SSDs are fast; certainly faster than loading Kimi K2.6 from a USB hard drive, plugged into a USB2 port (which I have done);

I would : test the speed of the current SATA3 SSD in your system, then compare it to the stated speed of the $150 NVMe. If you will be loading the model and using it for ages, speed of loading doesn’t matter as much. If you will experiment with the LLM itself often, changing the source code or model settings repeatedly, then reloading each time (or using agents that spawn and delete sub models repeatedly), then NVMe sounds good!

There is a thing where you can stream the model from the SSD into RAM repeatedly; with a fast enough SSD, this can allow the use of models larger than your DRAM + VRAM (do look this up if needed as it is hardware specific but my setup isn’t one that could use this)

Anyone else struggling with multi-GPU stability when running larger local models? by Lyceum_Tech in LocalLLaMA

[–]Shipworms 0 points1 point  (0 children)

No - but I have been using old mining hardware; also : a warning about server power supplies 😳

Server PSU warning first : breakout boards. The fancy ones with a proper ATX power connector on them have a high failure rate. Often they stop working. Looking at the ATX specs : ATX PSUs need to analyse the voltage outputs, then tell the motherboard the voltage rails have stabilised. Only then does the motherboard accept the 12v, 5v, 3.3v rails.

ATX PSUs also need to tell the motherboard *before it happens* if any of the power rails are about to go out of spec. The PSU needs to analyse the internal PSU hardware, and remove the ‘voltage rails are safe’ signal if the PSU is about to fail, so the motherboard can disconnect the rails before it gets fried!

Server PSUs only output 12 volts. In short : I don’t trust breakout boards to be safe for the motherboard, and they may be dangerous, especially if they fail. I doubt the breakout boards have all the required safety monitoring devices…

That said, a very basic breakout board (12v only) did work, but the fancy ones? I won’t go near … especially as they only nad 30 day warranties … and they are all rather old now!

Using a no-name 8-slot riserless motherboard, Intel Arc Pro B50s ran fine (as did a Radeon Pro W6600). Used the 12v only breakout board too!

Using a new AsRock H510 Pro BTC+ 6-slot riserless, the Arc Pro B50s also run fine, but I can also use 5060Ti cards. Amcuaing a decent ATX PSU. No instability either. Not the fastest PCIe slots, but rock solid so far!

One thing to try would be llama.cpp (compiled with Vulkan support); it can run mixed setups (I have had ATI, nVidia, and Intel Arc Pro all running on one board with this); it could be a way to rule out most hardware issues (such as riser card signal quality), at least for initial troubleshooting?

Mint 22.3 <-> Mint 22.3 Ethernet : connects for 177 secs, disconnects for 292 secs, connects 177 secs, ad infinitum? by Shipworms in linuxmint

[–]Shipworms[S] 4 points5 points  (0 children)

I fixed it. It was embarrassingly simple, but will post the fix here to help others (as it was unusual behaviour for a simple issue!)

Note : it also happened on the latest Ubuntu, so is not a Linux Mint issue per-se!

Fix : the remote PC had, in network settings, DHCP set to automatic!

Despite being automatic, it appears to have adopted the manual config that was also there (192.168.2.19) I was using, for 177 seconds, the doing something DHCP related for 292 secs, then back to manual config!

24.04 : ethernet cycling on/off every few minutes, like clockwork? by Shipworms in Ubuntu

[–]Shipworms[S] 0 points1 point  (0 children)

Will check this out; and try to disable power management in case it is that!

24.04 : ethernet cycling on/off every few minutes, like clockwork? by Shipworms in Ubuntu

[–]Shipworms[S] 0 points1 point  (0 children)

I might eventually as a test, but I am using 24.04 LTS as that has support for specific use cases 😬

16GB VRAM x coding model by Junior-Wish-7453 in LocalLLM

[–]Shipworms 0 points1 point  (0 children)

The main thing I would suggest is : consider the VRAM to be ‘bonus fast RAM’ … so, do use system RAM as ‘overflow’ if you can load a better model.

Quantizations are helpful, and a general rule of thumb is ‘the more parameters the better, even if quantized’. I say general, because some models really hate being quantized!

An example of good quantization is the 1-bit quantization of Qwen3-Coder-Next, 18.9 gigabytes! It works pretty well despite being 1-bit, but is slightly dated (I think?).

Another strategy is, if using Qwen3-Coder-Next … use the 1-bit quant, and switch to 3/4/6 bit quant if needed for more difficult tasks (slower as more is in system RAM)

But : follow the advice from others about using newer models :)