User reporting problems on 1 gb ram system...

[morrownr]

Below is a report I pulled over from the driver that is currently public. I am kind of thinking we should rewrite the installer code to check total ram and if it is < 1.5 gb, use 1 core instead of nproc. Ideas?

Struggle to build on Pi 4 B (1GB)

When running install-driver on Raspberry Pi 4 model B with 1GB RAM running 64-bit Raspberry Pi OS 11, compilation is incredibly slow and may fail (with a SIGKILL). This is reproducible. When used previously with same hardware running 32-bit Raspberry Pi OS 10, the problem didn't occur.

Appears to be because the "-j5" make flag causes all available RAM to be used and the device to start swapping. A simple workaround is to edit dkms.conf, replacing -j$(nproc) by -j1 (which actually makes it faster and complete successfully).

Is there some way the install script could automatically reduce the number of simultaneous jobs in this scenario?

P.S. Thanks for supporting these adapters. I have 8821cu (as client with BrosTrend AC650 AC5L) and 88x2bu (as AP with BrosTrend AC1200 AC3L) working well on the same Pi 4, used as firewall/gateway.

[colincdean]

With further testing using this version, I've got a little more detail on the effect of the "-j" values when building on Pi 4 with 1GB RAM:

• -j4 or -j5: runs out of memory
• -j3: just about enough memory, builds in ~6 minutes
• -j2: reasonable headroom, builds in ~6 minutes
• -j1: builds in ~10 minutes

I've also now acquired a 2nd Pi 4, but with 2GB RAM. Otherwise identical:

• -j4: builds comfortably in ~4 minutes.

On this basis, it might be sensible for the install script to drop to -j2 on models with < 1GB RAM.

[morrownr]

Hi Colin,

I was wondering where you have been.

Jibun reported a similar issue earlier in testing. I think he was using a single core Pi with limited memory so there is definitely an issue here with limited memory systems.

I have been researching and pondering this issue. There is likely a simple solution I have not found yet. What complicates things a little is that the installer supports two types of installations. With dkms and without dkms.

It may be that reducing or limiting gcc memory usage is a better solution. If anyone happens to read this and have suggestions, that would be great.

Nick

[morrownr]

@colincdean @Jibun-no-Kage

A short time ago I merged a fix I called "low mem systems". It is intended to address the issue Colin brought up. I may not help with the issue Jibun brought up but will move testing on Jibun's low mem systems, we might be able to find solutions to his problems as well.

As the saying goes: Even the best plan does not survive contact with the enemy.

I really need some solid testing on systems with 1, 2, 4 and more cores and systems that are low mem (1gb or less) to see what I have messed up. Please test as many systems as you can.

Credit goes to @alkisg for the idea. If this blows up, blame me because I took his good idea and probably made a mess of it so... if it works, he gets the credit, if it blows up, blame me.

Nick

[Jibun-no-Kage]

I should have some time this Sunday to do some more serious testing.

[colincdean]

I can probably find time to test on my 1GB RAM Pi 4 at the weekend.

[morrownr]

@colincdean @Jibun-no-Kage

As a start to testing this feature, I installed the driver on my RasPi3B that has 1 gb of RAM. This setup should basically be close to what you were working with Colin. It was successful:

: install-driver.sh v20230111
: aarch64 (ARCH)
: 982560 (SMEM)
: 2/4 (SPROC)
: 5.15.84-v8+ (KVER)
: gcc (Debian 10.2.1-6) 10.2.1 20210110
: dkms:2.8
Installing 8821cu.conf to /etc/modprobe.d
The dkms installation routines are in use.
Copying source files to /usr/src/rtl8821cu-5.12.0.4

Creating symlink /var/lib/dkms/rtl8821cu/5.12.0.4/source ->
                 /usr/src/rtl8821cu-5.12.0.4

DKMS: add completed.
The driver was added to dkms successfully.

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
'make' -j2...................................................................................................................................................................................
cleaning build area...

DKMS: build completed.
The driver was built by dkms successfully.

8821cu.ko.xz:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.15.84-v8+/updates/dkms/

depmod......

DKMS: install completed.
The driver was installed by dkms successfully.
Do you want to edit the driver options file now? [y/N] y
Do you want to reboot now? (recommended) [y/N] 

Note the line that says : 2/4 (SPROC). That tells us that 2 of the 4 available cores are in use, which is what we wanted.

The logic used is all cores will be used unless < 1.4 gb of RAM is detected and in that case, if more than 1 core is available, 2 cores is set.

As you have time, let me know your results.

I am in the process of doing some light remodeling before moving into our new house and my availability may be somewhat limited over the next 7-10 days.

Nick

[Jibun-no-Kage]

Yeah, my schedule has gone nuts, I will have time to do some testing Sunday as planned, but beyond that, I don't know in detail. I just discovered a major issue and will need to focus on it the next few weeks, I fear. Nick if you need or want details, ping me privately.

[morrownr]

@Jibun-no-Kage

Good luck with the problem. Remember to update the driver before testing.

All,

New merge to fix is bug in the low mem code went in Friday night. Things looked good but I forgot to consider the main reason we use dkms--that it will automatically recompile when a new kernel is installed. That was not working. I think it is working and I know this is a pain in the ass to test. If you have an Ubuntu based system, I can post a short checklist to make it easy to install a new kernel. You need to install this driver to probably 5.15 and then install something like 6.1.5 and see if dkms is working correctly. Fun times.

Nick

[colincdean]

I pulled and rebuilt a couple of hours ago on Pi 4 1GB. Scripts successfully detected limited memory and ran make with -j2 (build took 7 mins).

However, then upgrading kernel from 5.1.76 to 5.1.84 via apt-get dist-upgrade did NOT recompile.

[morrownr]

However, then upgrading kernel from 5.1.76 to 5.1.84 via apt-get dist-upgrade did NOT recompile.

@colincdean

I detected this issue yesterday and put a fix in late last night. Can I get you to git pull and figure out a way to test again?

[Jibun-no-Kage]

Did you try using rpi-source? I don't know what the deal is, but it seems like 50% of the time now the timing of the headers with the published kernel updates are NOT consistent, either missing or still pending repo refresh. I reported this to the Pi foundation kernel team, and got basically an excuse that it was just a timing issue. Well I follow the following logic:

Once is an exception or anomaly, Twice is a pattern, and Thrice is a PROBLEM. Over 2022 alone I have seen this issue at least 3 or 4 times. So they have a PROBLEM either consistency of execution or worse.

[morrownr]

@Jibun-no-Kage

I guess I may have misinterpreted what Colin was saying. I had tested yesterday on a x86_64 system and the automatic recompilation was not working so I had to make a change to the code that I had added. I then tested and it appeared to be working. If Colin downloaded fresh today and he is seeing issues and it is on a RasPi using RasPiOS, then you may be spot on because there is a PROBLEM with kernel headers arriving at the same time on the RasPiOS and it causes problems that end up being reported here as a problem with the driver. The drivers here get blamed for everything... world hunger, wars, etc.

Colin, can we get you to clarify did NOT recompile.? Some info about what distro and hardware you are using would help also.

Nick

[Jibun-no-Kage]

Or maybe I associated a Pi OS support issue as comparable in error? As you may recall there were a few times I had to use rpi-source to get the correct headers installed since they were missing for the published kernel in at times, but in others I was a bit ahead of the curve loading a kernel that was published via rpi-update but the official repo was lagging.

[colincdean]

I'm running Raspberry Pi OS (i.e. Debian) 64-bit on Raspberry Pi 4 model B with 1GB RAM.

When I started testing today (doing a pull after @morrownr's DKMS fix) my kernel version was 5.15.76-v8+, and I built the driver without problems. As apt-get update was showing me 5.15.84-v8+ as available, I updated using apt. This did also install matching kernel headers.

Sorry, maybe I wasn't clear: by did NOT recompile I meant the DKMS rebuild of the driver was not triggered by the apt-get update - there were no visible errors - the rebuild just didn't happen.

Unfortunately, my schedule this week means I'll be unable to do any more testing for a bit.

[morrownr]

I meant the DKMS rebuild of the driver was not triggered by the apt-get update - there were no visible errors - the rebuild just didn't happen.

I wonder what could cause the rebuild not to be triggered? I mean, heck, that is the primary reason for using dkms.

Unfortunately, my schedule this week means I'll be unable to do any more testing for a bit.

Copy all. We'll see you when you return.

Nick

[M0les]

Possibly unrelated. I'm developing on a Dell Wyse 3040 thin client with Fedora 37 server. This has a 2 core, 4 thread Atom x5-Z8350 @1.44GHz. It has 2G ram hardwired (The maximum for the CPU) and 8G of EMMC storage. I've never tried to test a kernel update with the driver installed before and today a new kernel package came out, so I gave it a run. (6.1.6-200-fc37?) . I'm not sure how DKMS does its magic, but the transaction log ran to:

...
  Cleanup          : glibc-gconv-extra-2.36-8.fc37.x86_64
  Running scriptlet: glibc-gconv-extra-2.36-8.fc37.x86_64
  Cleanup          : glibc-common-2.36-8.fc37.x86_64
  Running scriptlet: kernel-core-6.1.6-200.fc37.x86_64

Then the SSH connection stopped responding and the console got really slow to respond to keypresses. After several minutes it failed-out stating "Killed". After that it seemed not to boot properly any more. Anyway I tried another 3040 (this time with XCFE installed) and got similar results (Didn't see "killed", but my SSH session was closed), but it seems to still be going. I'll try adding 4G of external swap and disabling the compressed ram swap to see if anything changes.

[M0les]

... I'll try adding 4G of external swap and disabling the compressed ram swap to see if anything changes.

Nope! This one's dead too. I'll try re-imaging them.

[morrownr]

Miles,

Make sure you pull the latest from this repo when testing. There was an error in the dkms-make.sh file that I fixed recently. What you are describing happens without the fix.

Nick

[morrownr]

Miles,

I just completed a couple of hours of testing on the current contents of this repo and on a local repo with the 88x2bu that I have modified with the same supporting scripts. I upgraded the kernel from 6.1.6 to 6.1.7 and watched. Automatic compiles worked as they should. I also tried command line dkms build and it worked as it should. As far as I can tell, the issue you experienced has been fixed. Let me know if you see otherwise.

Now it is time to add edlin to the repo so as to keep Jibun happy.

Okay, that is a joke but we get a lot of entainment out of Jibun.

Now I am off to try to break something.

Nick

[Jibun-no-Kage]

LOL.

[morrownr]

Jibun,

Just had to see if you were awake. This low mem path, while not much code, took some thought and, of course, I did not get it right the first time... but hopefully do now. I'm sure you and some of the others can find other issues with it but that is why we are here... we break things and we fix things...

[Jibun-no-Kage]

Yup, I plan to do some serious testing this afternoon or early tomorrow. So will post any surprises I find.

[morrownr]

We'll hear from you on Friday, maybe. That single core, 500 MHz, 256 MB RAM Pi you have is going to take a while to compile.

[M0les]

FTR, I just rebuilt one of my Fedora 37 Dell 3040 test machines and building from commit 41b038f40ff85f32838fa172be8f8601ed31fd70 with kernel 6.1.6-200.fc37.x86_64 takes a bit under 5m and seems to work so far.

[Jibun-no-Kage]

This is repost to correct issue thread.

HA HA! The compile on 256 MB Pi only took 8,940 seconds! So there! Now testing. Updates to follow.

Memory just before install-driver script run... # free total used free shared buff/cache available Mem: 180512 43916 59152 844 77444 87020 Swap: 102396 256 102140

# lsusb Bus 001 Device 009: ID 09ae:0002 Tripp Lite Any Device (see discussion) Bus 001 Device 011: ID 0bda:a811 Realtek Semiconductor Corp. RTL8811AU 802.11a/b/g/n/ac WLAN Adapter Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9512 Microchip Technology, Inc. (formerly SMSC) SMC9512/9514 USB Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# lsusb Bus 001 Device 009: ID 09ae:0002 Tripp Lite Any Device (see discussion) Bus 001 Device 012: ID 0bda:c811 Realtek Semiconductor Corp. 802.11ac NIC Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9512 Microchip Technology, Inc. (formerly SMSC) SMC9512/9514 USB Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# ls -l total 192 -rw-r--r-- 1 root root 5883 Jan 17 15:51 8821cu.conf drwxr-xr-x 7 root root 4096 Jan 17 15:51 core -rw-r--r-- 1 root root 183 Jan 17 15:51 dkms.conf -rwxr-xr-x 1 root root 508 Jan 17 15:51 dkms-make.sh drwxr-xr-x 3 root root 4096 Jan 17 15:51 docs -rwxr-xr-x 1 root root 1225 Jan 17 15:51 edit-options.sh drwxr-xr-x 9 root root 4096 Jan 17 15:51 hal -rw-r--r-- 1 root root 2060 Jan 17 15:51 halmac.mk drwxr-xr-x 5 root root 12288 Jan 17 15:51 include -rwxr-xr-x 1 root root 11098 Jan 17 15:51 install-driver.sh -rw-r--r-- 1 root root 104 Jan 17 15:51 Kconfig -rw-r--r-- 1 root root 656 Jan 17 15:51 LICENSE -rw-r--r-- 1 root root 75897 Jan 17 15:51 Makefile drwxr-xr-x 3 root root 4096 Jan 17 15:51 os_dep drwxr-xr-x 2 root root 4096 Jan 17 15:51 platform -rw-r--r-- 1 root root 23989 Jan 17 15:51 README.md -rwxr-xr-x 1 root root 4051 Jan 17 15:51 remove-driver.sh -rw-r--r-- 1 root root 1309 Jan 17 15:51 rtl8821c.mk -rwxr-xr-x 1 root root 638 Jan 17 15:51 save-log.sh -rw-r--r-- 1 root root 1085 Jan 17 15:51 supported-device-IDs

# apt install dkms bc git build-essential raspberrypi-kernel-headers network-manager iw [...] Unpacking raspberrypi-kernel-headers (1:1.20220830-1) ... [...]

# uname -a Linux pink 5.15.61+ #1579 Fri Aug 26 11:08:59 BST 2022 armv6l GNU/Linux

[ Start Time... 1/18/2023, 13:30]

# ./install-driver.sh : --------------------------- : install-driver.sh v20230116 : armv6l (ARCH) : 180512 (SMEM) : 1/1 (sproc/nproc) : 5.15.61+ (KVER) : gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110 : dkms:2.8 : --------------------------- Installing 8821cu.conf to /etc/modprobe.d The dkms installation routines are in use. Copying source files to /usr/src/rtl8821cu-5.12.0.4

Creating symlink /var/lib/dkms/rtl8821cu/5.12.0.4/source -> /usr/src/rtl8821cu-5.12.0.4

DKMS: add completed. The driver was added to dkms successfully.

Kernel preparation unnecessary for this kernel. Skipping...

Building module: cleaning build area... ./dkms-make.sh....

[ Left To Make Lunch.... ] [ ...Checked On DKMS Build Progress... ] [ Let the Dachshunds Out... ] [ ...Checked On DKMS Build Progress... ] [ Watch A Couple Of Adtrain's Basement Videos On Youtube... ] [ Ate Said Lunch...] [ ...Checked On DKMS Build Progress... ] [ Watched the Dachshund Chase Amazon Delivery Person, Fast For A Human.... ] [ ...Checked On DKMS Build Progress... ] [ Took A Nap... ] [ ...Checked On DKMS Build Progress... ] [ Watched the Dust Settle On My Desk... ] [ ...Checked On DKMS Build Progress... ] [ Search HBO, NetFlix, Etc. For Something To Watch... ] [ ...Checked On DKMS Build Progress... ] [ Watched An Adam Savage Tested Youtube Video.... ] [ ...Checked On DKMS Build Progress... ] [ Stood On Weight Scale... Maybe SHould Lose The 10 Pounds I Gained Over The Holidays? ] [ ...Checked On DKMS Build Progress... ] [ Worked On The Outline To My Book... ] [ ...Checked On DKMS Build Progress... ] [ Thought About Some Day Purchasing A Lottery Ticket... ] [ ...Checked On DKMS Build Progress... ] [ Practiced My Hiragana Writing... ] [ ...Checked On DKMS Build Progress... ] [ Worked On My Gimbal Control Platform... ] [ ...Checked On DKMS Build Progress... ] [ Pondered The Nature Of The Universe...] [ ...Checked On DKMS Build Progress... ] [ Played Fetch With Indie... ] [ ...Checked On DKMS Build Progress... ] [ Scratched Nikki Ears...] [ ...Checked On DKMS Build Progress... ] [ Step Into The Tardius...]

cleaning build area...

DKMS: build completed. The driver was built by dkms successfully.

[ 15:49]

8821cu.ko.xz: Running module version sanity check.

Original module
    No original module exists within this kernel
Installation
    Installing to /lib/modules/5.15.61+/updates/dkms/

depmod.................

DKMS: install completed. The driver was installed by dkms successfully. Do you want to edit the driver options file now? [y/N] y Do you want to reboot now? (recommended) [y/N] y

# cat /proc/meminfo MemTotal: 180512 kB MemFree: 39248 kB MemAvailable: 77352 kB Buffers: 21888 kB Cached: 55312 kB SwapCached: 176 kB Active: 31896 kB Inactive: 61556 kB Active(anon): 828 kB Inactive(anon): 16188 kB Active(file): 31068 kB Inactive(file): 45368 kB Unevictable: 12 kB Mlocked: 12 kB SwapTotal: 102396 kB SwapFree: 101884 kB Dirty: 128 kB Writeback: 0 kB AnonPages: 16104 kB Mapped: 36012 kB Shmem: 764 kB KReclaimable: 13448 kB Slab: 23688 kB SReclaimable: 13448 kB SUnreclaim: 10240 kB KernelStack: 736 kB PageTables: 964 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 192652 kB Committed_AS: 205496 kB VmallocTotal: 835584 kB VmallocUsed: 6284 kB VmallocChunk: 0 kB Percpu: 64 kB CmaTotal: 65536 kB CmaFree: 10028 kB

Compile Time Results... = 0 days 2 hours 29 minutes 0 seconds = 0.103472 days = 2.48333 hours = 149 minutes = 8,940 seconds

# cat /sys/firmware/devicetree/base/model Raspberry Pi Model B Rev 1

[Jibun-no-Kage]

Using network manager, can scan networks, associate to 2.4 and 5.0. So basic testing done. I will do a bit more tonight and tomorrow. I will do a speed/throughput test, but since I have older equipment, I am not going to get much compare to what others can. But for me, sufficient, I have IoT, microcontrollers and such, so I really don't need volume over wireless. I don't stream over wireless.

[Jibun-no-Kage]

Oh.... my bad, I did post to the wrong thread. Sorry about that. But just to reply to your comment above. I triggered an OS update, and the the DKMS seemed to work fine since the OS update included a kernel update, I happen to have 3 drivers integrated to DKMS, our current target, 8821AU and 8188EU. I need to review the logs to confirm, but it looked like during the update, DKMS built all three.

I will do the remove and re-install as well.

[Jibun-no-Kage]

Manual non-DKMS install worked as well.

# lsmod | grep 8821cu 8821cu 2666496 0 cfg80211 782336 1 8821cu

# nmcli dev DEVICE TYPE STATE CONNECTION enx[redacted] ethernet connected Wired connection 1 wlx[redacted] wifi connected [redacted] p2p-dev-wlx[redacted] wifi-p2p disconnected -- lo loopback unmanaged --

[morrownr]

I triggered an OS update, and the the DKMS seemed to work fine since the OS update included a kernel update, I happen to have 3 drivers integrated to DKMS, our current target, 8821AU and 8188EU. I need to review the logs to confirm, but it looked like during the update, DKMS built all three.

Excellent.

Manual non-DKMS install worked as well.

Good.

Hopefully we are close to having nothing left to do other than dotting the i's and crossing the t's at this point.

[alkisg]

Today I got feedback from someone using my own "adjust compilation processes based on total RAM" make.sh script. He was the first one I saw that got OOM on a device with 2 GB RAM. It got me thinking, maybe we should be looking at awk '/MemAvailable:/ { print $2 }' /proc/meminfo ...instead of looking at MemTotal. E.g. if a user has a browser with 40 tabs open, along with gimp and libreoffice, the total RAM won't matter as much as the available RAM.

If it happens again, I'll try to measure how much RAM is needed for "N" processes on 32bit and how much on 64bit systems, and propose a code modification based on that. And maybe show a message to the user, "detected only 300 MB free RAM, using 1 compilation process, next time free up some RAM if you want compilation to happen faster!" :smile:

[morrownr]

If it happens again, I'll try to measure how much RAM is needed for "N" processes on 32bit and how much on 64bit systems, and propose a code modification based on that.

There may not be a perfect solution, just one that does a good job most of the time when otherwise there could be a problem. I've been at this for a while and the 5 Realtek drivers I have up are very heavily used. Colin's report is the first time I have had a OOM report so from my perspective, this is very rare. However, taking reasonable steps will likely help going forward. If you come up with a better solution, I'm all for it but it has to be something we can test.

Nick

[Jibun-no-Kage]

Maybe another point, most of the time I don't use a UI on Pi devices. It was not until I got a 2GB Pi 4 I seriously leveraged a UI on a Pi. I did do major early testing with a Pi 4 with 2GB, 4GB and 8GB using the default Pi OS UI. As I recall no 1GB Pi 4 right. The middle of the road... I would say most Pi users that use a UI, would not abuse it per se? Meaning they know the limitations of the device? Are students, or makers? Students would tend follow the course recommendations, makers should be a bit on the ball of that a Pi can/cannot do. It is the others, that we would expect the high degree of variability, would it not? Suggest RED BLINKING LETTERS.... "YOU ARE ABOUT TO COMPILE CODE... SHUTDOWN ALL APPLICATIONS NOW." After all, Windows installation engines make this demand all the time... so why not us?

[morrownr]

As I recall no 1GB Pi 4 right.

It was a 1 GB RasPi4B that started this issue. They exist.

I would say most Pi users that use a UI, would not abuse it per se? Meaning they know the limitations of the device?

Hey, even Canonical does not know the limitations of Pi's. I burned an sd with Ubuntu for RasPi4B when it was released. It took about 20 of use for me to decide to reburn the sd with something usable.

Suggest RED BLINKING LETTERS.... "YOU ARE ABOUT TO COMPILE CODE... SHUTDOWN ALL APPLICATIONS NOW." After all, Windows installation engines make this demand all the time... so why not us?

I smell a PR about to be born.

[colincdean]

Back from my week of radio silence, great progress on both the issues I had raised!

Yes, 1GB Pi 4 definitely exists (I can see one on my desk). I would suggest stick with basing build parameters on total RAM, not available. I think it will deliver more reproducible behaviour. My experience with this device is that Raspberry Pi OS 11 64-bit chews up more memory than version 10 32-bit, but I generally build with full graphical UI (especially as if I'm updating the kernel or the 8821cu or 88x2bu driver I prefer not to use SSH or a dumb console). Figures I have reported previously were with UI running, and the fixes added have worked for me.

[Jibun-no-Kage]

I will have to check and see if I have a 1GB Pi4. I thought the only Pi I did not have was the Pi Zero 2. But maybe not.

[morrownr]

Colin,

Since you are back, let me run the logic for this fix by you:

Check total system memory. If less than 1.4 GB, if processors > 1, then processors = 2.

That seems simplistic but simplistic may be what we need. I did some thinking about systems that could still be in use as this is not just a RasPi thing. If anyone has better logic, let me know.

88x2bu driver

Most of the work here will end up in the 88x2bu driver as well. In fact, I have already merged some of the lower risk work we have done here.

OS 11 64-bit chews up more memory than version 10 32-bit

gcc 12 chews up even more so I was probably going to be seeing more of this as time passes and Alkis idea about taking a look at free memory may be valid and he is going to explore that,

What I did was add the following statement to Step 8 (install-driver.sh):

Note: It is recommended that you terminate running apps so as to provide the maximum amount of RAM to the compilation process.

If anyone sees a better way to put it, please speak up... and yes, Jibun, I know that nobody reads the docs until they report an issue and are told to read the docs. Such is life...

Nick

[colincdean]

Nick,

Check total system memory. If less than 1.4 GB, if processors > 1, then processors = 2.

Yep, that would be perfect, based on my experiments with "-j" I reported a couple of weeks ago. For my devices MemTotal is a better measure than MemAvailable, because on my other Pi 4, with 2 GB RAM, I have:

cat /proc/meminfo 
MemTotal:        1893624 kB
MemFree:          319108 kB
MemAvailable:    1311720 kB
Buffers:          162056 kB
Cached:           865720 kB

yet it still builds happily with "-j4", although MemAvailable is < 1.4 GB. However, if @alkisg thinks we should be more conservative, I won't object, as "-j2" would probably only add ~ 2 mins to build time, which is not an issue for me.

Most of the work here will end up in the 88x2bu driver as well.

That's just what I was hoping you'd say.

Colin

[Jibun-no-Kage]

No flashing red letter? Well.... I guess.... that.... is... ok.... [sniff]

[alkisg]

@colincdean, no, not "more conservative", we wouldn't check for MemAvailable < 1.4 GB then, but for something like MemAvailable < 700 MB. E.g. suppose that the first compliation process needs 250 MB, and each additional one needs another 150 MB, then 700 MB MemAvailable would be enough for 4 compilation processes.

I suspect this would be less prone to OOMs than checking MemTotal, but let's wait for more OOM issues to be reported before invensting time in such an implementation. Actually, discovering the appropriate RAM numbers per process mentioned above and testing will take most of that time!

[Jibun-no-Kage]

There is also the question population distribution... How many 'systems' will be so resource constrained? That fraction of the population should not be the tail that wags the dog. Of the issues result, this, one would hope would not be a major priority. True, we will not know this until we have issue distribution/population data over time, but I suspect there will be other issues that Nick will need to focus on, or others in turn. Whereas those of us with applicable experience or historical knowledge should be able to assist with the lessor issues, or the bone-headed issues... I am guilty of a few of those to be sure.... like misreading [cough] the documentation.

[morrownr]

@colincdean

< However, if @alkisg thinks we should be more conservative, I won't object, as "-j2" would probably only add ~ 2 mins to build time, which is not an issue for me.

I think @alkisg is thinking longer term. Unless someone finds a problem, I think what we have now for the low mem problem is good enough. It is fixing the problem as reported.

Next month Jibun will show up with a Pi5B that has 256 MB of RAM running gcc 13 and will wonder what the problem is but we can handle that when it is a problem. <g>

[Jibun-no-Kage]

I clicked cancel on the Rock Pi I was ordering.... Dang It. Did you know it can run RUST from boot? LMAO.

[morrownr]

I clicked cancel on the Rock Pi I was ordering.... Dang It. Did you know it can run RUST from boot? LMAO.

Be every careful ordering Rock Pi boards. Late last year company contacted me for a consult. They were thinking about carrying some Rock boards to sell. It was a retailer. They sent me a Rock 4se. I did an eval and made a recommendation. The hardware is not too bad but the official distro for the boards comes with kernel 4.4. I shit you not. They seemed to have no concept that anyone would ever want to run a usb wifi adapter on them. The company is not selling the Rock boards. It would have been a support nightmare. I still have the board. I run Armbian on it. Armbian is pretty good but my point it, be careful what you buy when it comes to non-Raspi little boards.

[Jibun-no-Kage]

@morrownr

Yes... we discussed this before... that is why I said Rock Pi... I knew it would push a button, but wow, it did twice now! And... of course your are correct, even though they have one model that is interesting, the support for the Rock Pi is severely limited.

[morrownr]

@Jibun-no-Kage

I knew it would push a button

Okay, you win this round but beware...

Which Rock Pi do you find interesting?

[Jibun-no-Kage]

It is the 5 that I noticed first, but I was really looking for a Pi Zero replacement or alternate. I found a cool variant for the Pi Zero, that actually has a RISC processor. Been a long time since I played with a RISC chip.

https://blog.adafruit.com/2022/08/05/raspberry-pi-zero-vs-risc-v-mangopi-mq-pro-piday-raspberry_pi-bretweber/

[Jibun-no-Kage]

Of course this is completely off topic... But this is cool too... https://liliputing.com/sifive-hifive-pro-p550-dev-board-coming-this-summer-with-intel-horse-creek-risc-v-chip/

[Jibun-no-Kage]

Still off topic... but this is interesting.... They are working on getting the WiFi drivers working....

Check out the "Ox64 SBC (Pine64)" board. Runs Linux OS not a firmware image, like Picos, ESPs, etc.

[morrownr]

They are working on getting the WiFi drivers working....

I wouldn't know anything about that. He he.

Everybody has good ideas... and then reality sets in.