Pi 4B problem

I think - not sure - memory rusty - some of the minicomoputers were big endian as well.

This seems to be a case of unadulterated wombat turds

- *nix ext2/3/4 type systems do not benefit from garbage collection

- SSDs do nor benefit from garbage collection as seek times are essentially zero

- garbage collection has no effect on available disk space

- fstrim, whilst beneficial in theory, is probably redundant as SSD lifetimes in terms of write cycles already exceed that of spinning rust. It is certainly *not* mandatory.

In short if you want to increase SSD lifetime from 20 years to 21 years, use FSTRIM. :-)

I suspect not. In any case a number (most) early mainframes except IBM (?) used memory organised as words rather than bytes and AFAIK all word- addressed systems were bigendian.

Somebody else can speak for IBM, but I *think* they all used byte addressing, little endian arithmetic and EBCDIC .

It oldest machine I used was an Elliott 503, built using discrete transistors. I/O was via 8 track paper tape and a lineprinter. It was a scientific machine, with 8K of 39 bit words implemented in ferrite core memory. It did floating point calculations a little bit faster than integer ones. Each word could hold 2 19 bit instructions and if the B digit (bit 19, the centre bit) was set, the first instruction could modify the second instruction. Several programs could be loaded at once but only one ran at a time: the user-provided program was run by the operator via a 75 word control program and typewriter, had full control. It treated other programs in memory as co-resident function libraries and i/o handlers for the tape reader/punches and the lineprinter. IIRC there was no linker: the Algol 60 compiler left your program in a 32 kWord ferrite code backing store: if there were no compilation errors it was automatically loaded into main memory and run. A lot of the later mainframes such as ICL 2900/3900 were far more software-defined:

Burroughs B series were microcoded and used different microcode interpreters depending on the language a program was written in, with wach program runnin in its own virtual machine.

ICL 1900 series memory, and so also its accumulators, were 24 bit words. Characters were ISO coded 6 bits, packed 4 per word. Each program had its own address space and there was no stack.

ICL 2900/3900 series architecture was software defined. VME/B, the 2900 OS, ran each user application in a separate virtual machine whose architecture was software defined. COBOL programs used byte oriented addressing, bytes were EBCDIC coded 8 bits, a stack was used for function calls, register lengths were software definable. Each VM implemented rings of protection to protect code at different lower levels in the VM from interference: user-level code could call functions at a lower level but not modify anything at the lower level, and of course programs could only communicate with those in other VMs via OS-level system calls. Last, but not least, the machine could run George 3 and VME/B programs simultaneously. The only sign this was happening was that the operators had two control consoles - one for each OS. I don't know for surem but strongly suspect that George 3 was actually running in its own VME/B defined virtual machine which contained microcode that emulated 1900 hardware.

I was told, on an ICL-run course, that the microcode used to run VME/B in an OCP (Order Code Processor) in a 2966 mid-range mainframe was executed by a single 2MHz 6809 MPU.

You may have also heard of the ICL 2903. This was a desk-size box, capable of running on an office environment, was contained the hardware of a 2900 disk file controller running microcode that emulated a 1900 mainframe: it would not surprise me if this was the exact same microcode used under VME/B to run a copy of George 3 on a 2966.

I believe that IBM AS/400 (now called i-Series) used s similar software structure to ICL's VME/B. This would would make sense since both VME/B and OS/400 were developed at about the same time and both could draw in the ideas behind the earlier MULTICs OS.

I've also done a lot of work on AS/400 systems and noticed that there wewre a lot of similarities between the way that VME/B and OS/400 did things and organised disk space, etc. which also points to the likelihood that MULTICS was a common ancestor.

ls

PDP-11 and VAX were LE.

BE.

There were a lot more minicomputer makers than DEC..

Prior to the development of LSI CPUs, in the ECL TTL and CMOS eras, you could build a CPU and architecture any way you wanted.

But the PDP-10 was BE as was early SPARC, MIPS could go either way. A lot of the minis were based on 68K, MIPS or SPARC so yes there would have been a number of big endian minis around - especially during the era of samey unix boxes with a QIC tape on the front and bunch of serial ports on the back.

Th> First things to try when it's frozen: Th> Th> - press Ctrl-Alt-F1 (and other F keys, see if you can get to a console Th> where you can login) Th> Th> - if not, can you ping it over the network? (if plugged into ethernet, Th> your router should tell you the IP) Th> Th> It's possible it's just the GUI that's crashed, rather than a hard Th> lockup.

This is good advice, on *any* Linux machine.

Th> You can also try downclocking it via config.txt. Open config.txt on the Th> first partition on the SD card/SSD (from another machine) and add: Th> Th> arm_freq=600 Th> gpu_freq=400 Th> Th> That will slow down the processor, perhaps enough to get in and run the Th> script. You may need to play around with the numbers (in MHz) as I'm Th> just guessing and I don't know what's accepted.

I think those numbers would work. But, the more important issue is making the device useable.

Th> Possibly worth checking your power supply - maybe Ubuntu takes more Th> current?

I don't think this is possible. It shouldn't matter which OS is installed, the CPU uses a certain maximum.

Th> > I am "assuming" here that 8Gb Ram is more than enough for it !

A good assumption. Lubuntu, or Xubuntu, can run fine with only 1 GB of RAM. And older versions of Ubuntu (I don't like their version of Gnome) worked just fine with 4 GB.

Th> Another possible thing to try is this: Th>

I wonder about this. Normally, on a Pi, the "shift" key is reserved on boot, for NOOBS or PINN. Perhaps, after that, this would work?

McDoob SysOp, PiBBS pibbs.sytes.net

VC> Hello All! VC> VC> So an update: VC> VC> I gave up at least for the moment on the ubuntu distro and installed VC> using the same tool Bullseye X64 direct to the SSD M.2 device using a VC> usb3 plugged cable and booted it (all today) after I was wide awake. VC> VC> Needless to say it is working fine for a Debian Pi distro but I do not VC> like the VC> basic Gui interface and would like to use KDE or Gnome (if I have to), VC> how ever VC> there is not a procedure the install one of them without picking each VC> element for say KDE and that would be a accident waiting to happen. VC> VC> Why the devil don't they offer a change of gui system instead of the VC> very basic VC> one they use ?

PiOS specifically chose a UI that definitely works on *any* Pi. Can you blame them? However, it is still a Debian-based system. I don't see why you couldn't 'sudo apt-get install' any other UI, like kde or gnome.

VC> Yes, I know I am getting older but was hoping I am not that senile yet !

That remains to be proven! (o_-)

VC> When I get a chance or have to shut the system down I will install the VC> SD card on the offchance the boot sequence will see the card and load VC> from it. Failing that I will disconnect the USB link and try it - VC> perhaps try that method first :)

I am confused. I was under the impression that your Pi was locking up *after* the boot process. Meaning, it has already started loading from your USB device, and locked up while trying to load Ubuntu...

McDoob SysOp, PiBBS pibbs.sytes.net

AD> I think every Pi 4 user looking to try things out needs at least two SD AD> cards: AD> AD> 1. One card for "Raspberry Pi OS 32-bit (Bullseye) with desktop and AD> recommended software". AD> AD> 2. One card for the other OS.

This is very good advice!

Always have one card with a working OS. Then, even if you totally destroy the other one, you'll still have some way of working with the Pi.

McDoob SysOp, PiBBS pibbs.sytes.net

VC> Hello All! VC> VC> One thing I have noticed with the M.2 SSD is that when running VC> sudo fstrim -av it exits with the implied not finding a SSD so I have to VC> guess that the WD M.2 SSD is not being treated as a SSD and that is a VC> worry if there is no garbage collection taking place.

To be clear, any modern SSD performs its own garbage collection. You shouldn't have to use fstrim.

VC> I may try contacting WD (assuning they have a tech support dept) and see VC> if they can shed any light on this as PiHut does not seem to have that VC> level of technical support in-house like wise Argon who do not respond VC> to emails. VC> VC> I am using a Argon One M.2 case which includes a board to install a M.2 VC> SSD in that is liked to the Pi via a USB bridge double plug.

That USB bridge is basically the same as any that would be used in any external SSD device. I really think you're worrying about a non-issue. Concentrate on your first problem: getting the damned thing to boot!

McDoob SysOp, PiBBS pibbs.sytes.net

VC> Running fstrim is a required process if you are running with a SSD at VC> least in two primary Linux based systems that have it as a boot drive VC> otherwise failing to do so will make the SSD run out of disk space when VC> the only fault is that it VC> has not run Garbage collection to clean up the unused clusters.

No, sir! This was a problem, for certain, in the early days of SSDs. But, as I've mentioned, modern SSDs perform their own garbage collection!

VC> Only drawback to using SSD's under *nix. Windows does it automatically VC> some how but for *nix you have to specify fstrim to run once every 24 VC> hours for lightly used systems and 12 hourly for heavier load systems - VC> it might need to be more often if using them in a busy server.

Please refer to my first comment.

VC> Now I have had a quick look at the SD card in use and it has Ubuntu VC> Desktop 21.10 so I will continue using Bullseye and give up on it. VC> There is a wee list of issues with the Pi in the release notes (for VC> 21.10) but they do not mention these noticed issues.

Honestly, I don't see why you didn't just use PiOS from the start. You can install KDE, or Gnome, or even Cinnamon from there. Not to mention that PiOS and Ubuntu are *both* Debian-based. What exactly were you trying to achieve?

VC> I will look in on the Debian website for their release notes for v11 and VC> see what the procedure is to upgrade the distro to use KDE or failing VC> that Gnome, however that does not mean they will work with a Pi in a VC> reasonable manner - suck it and see, I guess.

"sudo apt install kde-desktop"? Or maybe "sudo apt install gnome-desktop"? I'm not certain that this would work, because the necessary packages may not be on the official Pi repos. But, it's not hard to add ppa's...

McDoob SysOp, PiBBS pibbs.sytes.net

VC> No, it locked up (no clock updating) after I loaded Terminal but looking VC> yesterday it is just terminal that does nothing after loading - no keyed VC> input, VC> cannot select anything from the menu bar etc. VC> VC> I did a system update from the gui and after a minute where it shows the VC> progress bar at around 2cm's worth it just - well shows no progress even VC> after an hour with just occasional hit on the access light which is very VC> hard to see - must be the smallest led available anywhere in the world :) VC> It really is a pin prick size which you can see at night with the room VC> light off - just. Well it is made to a price - a low one :)

Hahaha! I feel you, there! (^_^)

But, you might need to blame your Argon enclosure for that. The bog-standard Pi4 enclosure doesn't interfere with the LEDs.

As others have mentioned, you should try to SSH (or VNC) into your Pi, and make sure it's actually stalled, rather than just not responding to desktop.

To be clear, I've never tried to install Ubuntu on a Pi. I know a bit about Ubuntu, and a bit about the Pi, but I've never tried to combine the two.

I'm very interested in this, because I want to buy the Argon enclosure for my own Pi4. I am certain that your problem has nothing to do with Argon, though. I think your problem is with Ubuntu, or at least with Ubuntu on a Pi.

McDoob SysOp, PiBBS pibbs.sytes.net

Hello druck!

Monday February 28 2022 09:58, you wrote to me:

Yes I am more than aware of such hence the comment!

My Pi is using the 64 bit operational properties which is why I specified X64 and this is NOT exclusive to Intel, Amd, Zilog, IBM etc.

Vincent

Hello Shaun!

Monday February 28 2022 12:17, you wrote to me:

VC>> When I get a chance or have to shut the system down I will VC>> install the SD card on the offchance the boot sequence will see VC>> the card and load from it. Failing that I will disconnect the USB VC>> link and try it - perhaps try that method first :)

No, it locked up (no clock updating) after I loaded Terminal but looking yesterday it is just terminal that does nothing after loading - no keyed input, cannot select anything from the menu bar etc.

I did a system update from the gui and after a minute where it shows the progress bar at around 2cm's worth it just - well shows no progress even after an hour with just occasional hit on the access light which is very hard to see

- must be the smallest led available anywhere in the world :) It really is a pin prick size which you can see at night with the room light off - just. Well it is made to a price - a low one :)

Vincent

AMD is not ARM, so it wont work on a Pi

---druck

Er Druck - he said it *didn't* work on an AMD so it probably is ARM.

On Mon, 28 Feb 2022 16:08:55 +1200, snipped-for-privacy@f1.n.z2.fidonet.org (Vincent Coen) declaimed the following:

To most of the readership, X## is an implicit reference to Intel (old iAPX nomenclature)/AMD processors.

arm64 is the architecture used by newer Macs built on Apple Silicon, shipped in late 2020 and beyond. """

Generalized 64 bit would be a simple "64-bit". ARM specific would be, as shown above, "arm64".

So far the first three links from Google show the X-notation IS specific to Intel/AMD, and a different notation is used for ARM chips. There are easily five more links making the same distinction (and one discussing the difference between ARM64 and AARCH64 -- mostly coming down to which compiler back-end was used <G>).

It’s more complicated than that. A physical page can be marked garbage when the corresponding logical page is overwritten. But a logical page that a filesystem stops using without overwriting (e.g. when deleting a file) still appears to be in use to the controller, at until such as time as the filesystem uses it for something else. fstrim or the discard option supply the missing information.

Whether it’s worthwhile probably depends on access patterns.