Debian installer for ppc64 and related packages are broken by crashing binaries
: illegal instruction (4) at
3fff99a42000 nip 3fff99a42000 lr 3fff99a43234 code 1
Mar 12 01:52:32 kernel: mktemp[8673]: code:
Mar 12 01:52:32 kernel: mktemp[8673]: code:
<7f454c46> 02020100
Mar 12 01:52:32 in-target: Illegal instruction
Mar 12 01:52:53 kernel: apt-get[8831]: illegal instruction (4) at
3fffb2b02000 nip 3fffb2b02000 lr 3fffb2b03234 code 1
Mar 12 01:52:53 kernel: apt-get[8831]: code:
Mar 12 01:52:53 kernel: apt-get[8831]: code:
<7f454c46> 02020100
Mar 12 01:59:26 kernel: chpasswd[12408]: illegal instruction (4) at
3fff8b3d2000 nip 3fff8b3d2000 lr 3fff8b3d3234 code 1
Mar 12 01:59:26 kernel: chpasswd[12408]: code:
Mar 12 01:59:26 kernel: chpasswd[12408]: code:
<7f454c46> 02020100
Mar 12 01:59:26 finish-install: Illegal instruction
Mar 12 02:10:44 kernel: apt-cache[12629]: illegal instruction (4) at
3fffb34a2000 nip 3fffb34a2000 lr 3fffb34a3234 code 1
Mar 12 02:10:44 kernel: apt-cache[12629]: code:
Mar 12 02:10:44 kernel: apt-cache[12629]: code:
<7f454c46> 02020100
-- My regards, Damien Stewart.
Re: Updated installation images for Debian Ports (2025-03-16)
On 26/3/25 5:47 pm, John Paul Adrian Glaubitz wrote: Yesterday I had the idea to modify the problematic patch [1] so that it applies on ppc64el only but not on powerpc and ppc64. This should at least fix the console problem. Adrian [1]https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/patches/bugfix/powerpc/fbdev-offb-Update-expected-device-name.patch?ref_type=heads So, I've been reading about this patch, trying to find out the purpose of changing the property name. I'm wondering why fbdev offb code is failing to find the display, as all changes look they are within offb. So, IIUC, the kernel fbdev module is expecting "|of-display.0"| from modern OF compatible firmware but Apple OF is providing |"||of-display"|. Am I on track or off? -- My regards, Damien Stewart.
Re: Updated installation images for Debian Ports (2025-03-16)
On 27/3/25 12:59 am, John Paul Adrian Glaubitz wrote: Not just Apple OpenFirmware, but also PowerKVM. When you try to install Debian on a ppc64el KVM instance you won't get a console output either. An engineer from IBM wanted to look into it, but it took him forever to reproduce the problem and it also seemed that he wasn't really interested in fixing this problem. Okay, I can understand for Apple, but I expected a PowerKVM instance to be more prevalent. So it seems as if no one needs to install Debian into a new KVM right now? I assume that we will just have to wait until Trixie has been released and people start reporting this issue when they are switching to Trixie. I have no clue why I'm not being able to convince anyone to fix this problem even though it's clearly a bug. I've noticed changes to standards causing issues, such as the change requiring child nodes in device trees to have size properties, which I got caught up in. For what is worth, the patch that Debian's kernel package is currently carrying was even rejected upstream because of the very problem it had with hard-wiring the name in such an incompatible way. Would be good if this solved itself by being rejected then. But I wonder if it the prom init code needs changing to account for it if the problem persists? I was reading some particular code that avoids closing OF handles as it causes trouble on some Apple models when Quiescing. Looks like prom_init.c is popular for all these fixup patches. -- My regards, Damien Stewart.
Re: Debian installer for ppc64 and related packages are broken by crashing binaries
Hello.
I suspect that this is a library problem, as more than systemd is
affected, and the bottom 16 bit of the lr are suspiciously similar --
this is one library that is mapped into different processes at
different addresses (but with at least page granularity).
When doing a chroot to the installed partition it was functional but I
found using apt or other tools in the list crashed. When booting it
directly it immediately crashed on systemd and could go no further.
Yes, these are normal as far as I know. Installer packages are never
manually chosen (so the Description isn't needed) and are installed
from a consistent set (so the Architecture isn't needed). The
Pre-Depends errors are likely from the debootstrap run -- in principle
a Pre-Depends on an Essential package should be treated like a Depends
here, but this is one of these problems that aren't really worth solving.
I expected that to be the case. To the untrained eye it may look a bit
sloppy all these issues installing packages and seeming errors popping
up. But it is a complicated process that's constantly evolving with each
update of the install process.
Mar 11 17:13:54 kernel: journalctl[8546]: illegal instruction (4)
at 3fff95032000 nip 3fff95032000 lr 3fff95033234 code 1 Mar 11
17:13:54 kernel: journalctl[8546]: code:
Mar 11
17:13:54 kernel: journalctl[8546]: code:
<7f454c46> 02020100
Mar 11 17:13:54 in-target: Illegal instruction
That's an ELF header -- the program counter is at the beginning of a
mapped binary, not at the beginning of the code contained in it. My
suspicion is that someone makes an assumption that function pointers
are the same size as normal pointers. The C library generally does
this right, but there are various plugins loaded from there like NSS
and PAM modules.
Simon
You're right. I just realised the "7f" was the leading byte in the ELF
header. Like an obvious riddle with an answer hidden in plain sight. I
can't get used to lower hex produced by C format. But the X's around
don't help either. I read something about hiding machine code in crash
dumps for security so thought it may crossed out for that reason. So
this makes me think if a conflict in ABI is involved? Like a mismatch
between function descriptor and function pointer.
Further tests suggest a kernel conflict. I tested booting it with a long
term kernel 5.10.235 and it was able to boot. I was unable to login as
it rejected my password so possibly the password setup from installer
corrupted. But I am able to chroot to it and fix that as well as update
and install packages.
-- My regards, Damien Stewart.
Re: https://fienixppc.blogspot.com
Hi. Yes, I have it installed been using it the last few years. Unfortunately, the Fienix repo is presently broken so no software can be updated or installed. Trying to fix it with Debian repos temporarily usually ruins it so be good when the repo is working again. :-) -- My regards, Damien Stewart. Green Valley Decorators.
Re: Updated installation images for Debian Ports (2025-03-16)
On 28/3/25 4:51 pm, John Paul Adrian Glaubitz wrote: This bug was introduced in Debian Trixie which is not released yet. I assume that most users won't install their POWER servers with Debian Testing. No and since they would use a supported arch, ppc64LE, my emphasis on the LE, they don't need too. When I read of ppc64le or ppc64el as it's put, I interpret that with my own play on letters, ppc64intel. ;-) The patch is being reverted in Debian's kernel package now. Yes, I just read that before. Thanks for info. -- My regards, Damien Stewart.
Re: Trying to crack the Firefox crashing issue
e that's defacto standard endian now days. Or something like that. Could be a bug in the LLVM PowerPC backend. Try building with GCC instead. Having read the latest about GCC compile still crashing reveals there is still some issue. Not exactly in the same spot. But soon after that streqci call. -- My regards, Damien Stewart.
Re: Trying to crack the Firefox crashing issue
On 9/5/25 7:12 pm, Ed Robbins wrote:
Hello! Nice digging
Thanks!
On Fri, 9 May 2025 at 08:03, Damien Stewart wrote:
The source:
static int FASTCALL
streqci(const char *s1, const char *s2) {
for (;;) {
char c1 = *s1++;
char c2 = *s2++;
if (ASCII_a <= c1 && c1 <= ASCII_z)
c1 += ASCII_A - ASCII_a;
if (ASCII_a <= c2 && c2 <= ASCII_z)
/* The following line will never get executed. streqci() is
* only called from two places, both of which guarantee to put
* upper-case strings into s2.
*/
c2 += ASCII_A - ASCII_a; /* LCOV_EXCL_LINE */
if (c1 != c2)
return 0;
if (! c1)
break;
}
return 1;
}
I am not sure how rlbox sandboxing works, but looking at this code
from a cross platform perspective, I'd say the use of char is suspect,
because it may or may not be signed depending on platform, and then a
comparison is being performed on it. The first thing I'd do is change
it to:
unsigned char c1 = (unsigned char)*s1++;
unsigned char c2 = (unsigned char)*s2++;
It does assume 7-bit ASCII by the looks of it. Going by the rest of the
code it only uses 7-bit strings. It's rather pedantic as it defines it's
own ASCII character set rather than rely on C strings. :-)
I'd also remove FASTCALL because I don't know how that will behave
with rlbox or ppc in general.
According to this it should be blanked out on PPC/non-x86.
https://github.com/libexpat/libexpat/blob/master/expat/lib/internal.h
It might be a good idea to also check the rest of expat for similar issues too?
Good luck!
Ed
It might. It might be the entry down a rabbit hole as well. :-D
--
My regards,
Damien Stewart.
Re: Trying to crack the Firefox crashing issue
On 9/5/25 7:28 pm, Reimar Döffinger wrote: I don't think you are quite on the right track. w2c_rlbox_streqci has 3 arguments, not 2 like the source you quote, so that will make it real hard to match those up. It does only have 2, but it is an original C source. What it does with it I don't know, if it doesn't second source it from elsewhere. It looks to me like some kind of ABI is involved that uses an instance to call off or for data, similar to an OOP call. I've seen this before where functions were called off a jump table, which confused the register layout with an extra pointer passed. The nops are almost certainly there to align the loop start with the icache line size (making it start at +16). That's interesting. Does it cause a bad penalty on ppc64 if unaligned? The strange r4 r5 sub is probably to have a single loop increment variable, but I expect that will be really hard to understand without finding the exact matching code and what that 3rd argument is about. That is besides that the bug could be very, very far away from the crash location, so not sure you are anywhere close to the issue (but I don't have any better suggestion). I've noticed another discrepancy. Leading up to it the instance is first parameter. But when it calls w2c_rlbox_streqci it has instance last! Even optimised out it should still be in same spot unless it rearranged registers for more confusion to suit itself. I'm interested in step debugging through it. If I can get over the way gdb is CLI based. I find a command interface isn't suited for step debugging and makes it awkward. If anyone uses it directly for real debugging. -- My regards, Damien Stewart.
Re: Trying to crack the Firefox crashing issue
On 9/5/25 9:00 pm, John Paul Adrian Glaubitz wrote: https://github.com/oracle/solaris-userland/tree/master/components/desktop/firefox/patches There is a very high possibility that there is a proper fix among these patches. I did a search for "big" in those patches. But couldn't get a sharable link. In any case you found the good ones. -- My regards, Damien Stewart.
Re: Bug#1105090: firefox: Please build with gcc and g++ on ppc64
On 11/5/25 8:34 am, John Paul Adrian Glaubitz wrote: Source: firefox Version: 138.0.1-1 Severity: normal Tags: patch User: debian-pp...@lists.debian.org Usertags: ppc64 X-Debbugs-Cc: debian-powerpc@lists.debian.org Hi, the firefox package fails to build on ppc64 since it tries to use lld which does not support PowerPC ELF v1: Is that a big issue? I got the impression Debian PPC64 was ABI2 only? It's just that when I found my new Debian install crashing it came down to an ABI issue. As soon as I used an ABI2 kernel my problems went away. System, apt and all other binaries started working. When I checked the vmlinux 6.12.17-powerpc64 kernel from Debian GNU/Linux 12.0.0 "Sid" - Unofficial ppc64 NETINST 20250316 on the net installer it was ABI2. -- My regards, Damien Stewart.
Re: Firefox 133 test package for ppc64
On 11/5/25 6:46 am, John Paul Adrian Glaubitz wrote: Success:https://people.debian.org/~glaubitz/firefox-ppc64.png Package uploaded to unreleased. Will be installable in a few hours. Looks great! Thanks for the build. I'll be installing it soon. Would missing out on WASM cause much of a slowdown? I forgot to mention it and it would be known, but developers of TenFourFox, ArticFox and SeaLion would know about these issues. I don't know how they solved them but I do know TFF has a bit of ASM optimizations for endian issues. -- My regards, Damien Stewart.
Re: Trying to crack the Firefox crashing issue
On 10/5/25 12:46 am, Ken Cunningham wrote: chatgpt has opinions. I put in my original run and backtrace from Nov 2023, and chatgpt had the following to say: The other night I was wonder if AI could assist in tracking down the issue. Given WASM used to work AFAIK, perhaps some AI assisted bisecting is in order. Thread 1 "firefox" received signal SIGSEGV, Segmentation fault. i32_load8_u (addr=2014643200, mem=) at rlbox.wasm.c:146 Though I didn't see i32_load8_u come up in my trace it does show up if I single step to the crash. == The backtrace you've posted shows a **segmentation fault** (`SIGSEGV`) happening in Firefox when running under GDB on a PowerPC64 Linux system. The crash occurs in code generated by RLBox, specifically in `i32_load8_u` within `rlbox.wasm.c`, which appears to be part of a **WebAssembly sandboxed execution environment**. Here's a breakdown: A breakdown in markdown. :-D ### Key Observations: * **Faulting function**: `i32_load8_u (addr=2014643200)` — the address accessed is very large and likely invalid. * **Sandbox**: RLBox is being used — this is a sandboxing framework to isolate parts of code, such as XML parsers or other libraries, via WebAssembly. * **Fault path**: Interesting it mentions XML here. * `w2c_rlbox_getEncodingIndex` → `w2c_rlbox_MOZ_XmlInitEncodingNS_0` → `w2c_rlbox_prologInitProcessor` → eventually called via `nsExpatDriver::ParseChunk` * This indicates the crash is happening during XML parsing inside the sandbox, possibly parsing a stylesheet (`global.css` is mentioned in the XML). ### Possible Causes: 1. **Invalid pointer dereference** inside the sandbox — RLBox is trying to access memory at an address it shouldn't. 2. **Improper input data or parser state**, especially related to XML or encoding parsing. 3. **Compiler bug or undefined behavior** in sandboxed code generation. 4. **Architecture-specific issue** (PowerPC64) — most testing happens on x86/x86\_64, so bugs may surface on less common platforms. ### What You Can Do: 1. **Check if the address `2014643200` makes sense** in your sandbox — it's very high and likely an invalid offset into the RLBox memory. 2. **Enable RLBox debugging**: It's exactly an invalid offset. Confirmed by the crash itself. The EA is out of range. * Build Firefox with `--enable-debug` and set RLBox-related environment variables like: ```bash MOZ_RLBOX_SANDBOXED=1 MOZ_RLBOX_VERBOSE=1 ``` * This might produce logs that indicate why the memory is invalid. 3. **Verify XML input**: Try to locate and examine the file or network resource being parsed — malformed or unexpected input could cause faults. 4. **Update Firefox**: Ensure you’re running the latest version of Firefox and all dependencies. 5. **File a bug**: * This may be a platform-specific bug. Mozilla tracks RLBox bugs [on Bugzilla](https://bugzilla.mozilla.org/). Include architecture (PowerPC64), the RLBox call path, and the faulty address. Good luck! GPT :-D Would you like help inspecting the specific value at `addr=2014643200` or guidance on how to reproduce the crash more minimally? Yes. Swap it around. :-) -- My regards, Damien Stewart.
Trying to crack the Firefox crashing issue
Hi guys.
So I this is really a follow up to the "What are the current available
browser options for debian-ppc64?" thread where it there was a technical
discussion on why Firefox was crashing which ended up being rather
anti-climatic. But I wanted to check myself since I'm aware the last few
years all Firefox does is crash on load. At the time PPC was last
officially supported on Jessie, Firefox was becoming unstable then. It
loaded and worked but would easily crash and exit. Now it's much worse.
So unlike most of the PPC people out there I don't have a quad G5 power
horse. I do have a rather rare X1000 with a PASemi PA6T. Only dual but
64 bit and does the job. I soon found out running Firefox under GDB
needs over 6GB RAM and I only had 4GB with HDD swap space. I rarely need
swap on PPC, unlike my laptop. But I had some spare backup RAM and
decided to max it out. After wrestling with DDR2 RAM slots I managed to
get it working. A 64 bit PowerPC machine with 8GB RAM and Debian 64
installed on SSD. Okay I've broken the 32 bit barrier and now I'm
talking. :-D
My results to summarise it are that it is the same crash. Different day,
same code. That streqci() function again. This time in firefox_138.0.1.
But here's some info I picked up that may help to close in on it. With a
running commentary. :-)
damien@ubuntu:~$ gdb firefox.real
GNU gdb (Debian 16.3-1) 16.3
...
Reading symbols from firefox.real...
Reading symbols from
/usr/lib/debug/.build-id/fd/6adabdb8b6655f970f65deffcea09f8d7dac41.debug...
(gdb) run
Starting program: /usr/bin/firefox.real
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/powerpc64-linux-gnu/libthread_db.so.1".
... A minute or two filling up 6GB of RAM...
Thread 1 "firefox.real" received signal SIGSEGV, Segmentation fault.
w2c_rlbox_streqci (var_p0=var_p0@entry=262000, var_p1=2016478208,
instance=) at rlbox.wasm.c:55615
warning: 55615 rlbox.wasm.c: No such file or directory
As you can see different day, same code. Same function but without that
i32_load8_u. I don't like the look of that instance. Why is instance
optimized out? The frame is omitted.
Back trace...
(gdb) bt
#0 w2c_rlbox_streqci (var_p0=var_p0@entry=262000, var_p1=2016478208,
instance=) at rlbox.wasm.c:55615
#1 0x3fffe8e1e268 in w2c_rlbox_getEncodingIndex (
instance=, var_p0=) at rlbox.wasm.c:55548
#2 w2c_rlbox_getEncodingIndex (instance=0x3fffda90f000, var_p0=262000)
at rlbox.wasm.c:55531
#3 w2c_rlbox_MOZ_XmlInitEncodingNS_0 (instance=0x3fffda90f000,
var_p0=325428,
var_p1=325424, var_p2=262000) at rlbox.wasm.c:57164
#4 0x3fffe8e4ce1c in w2c_rlbox_initializeEncoding (
instance=instance@entry=0x3fffda90f000, var_p0=var_p0@entry=325280)
at rlbox.wasm.c:37816
The hit...
(gdb) disas
Dump of assembler code for function w2c_rlbox_streqci:
0x3fffe8e1e150 <+0>: ld r3,0(r3)
0x3fffe8e1e154 <+4>: subf r4,r5,r4
0x3fffe8e1e158 <+8>: nop
0x3fffe8e1e15c <+12>: nop
=> 0x3fffe8e1e160 <+16>: lbzx r9,r3,r5
0x3fffe8e1e164 <+20>: add r10,r4,r5
0x3fffe8e1e168 <+24>: clrlwi r9,r9,24
0x3fffe8e1e16c <+28>: clrldi r10,r10,32
0x3fffe8e1e170 <+32>: lbzx r10,r3,r10
Why is there nop? Does it mean ori? PPC doesn't have nop. Why doesn't
gdb list the machine code as standard? Supposed to be a debugger. This
code looks sus.
Registers...
(gdb) info r
r0 0x3fffe8e4ce1c 70368356519452
r1 0x3fffbe90 70368744160912
r2 0x3413c500 70368544146688
r3 0x3ffb 70347269341184
r4 0x87d2fb70 18446744071693335408
r5 0x78310400 2016478208
Ok so it doesn't like r9 = [r3 + r5]. What's wrong with 3FFB78310400?
Apart from r5 being a large 32 bit integer.
I had apt sourced the source but gdb couldn't see it so needed to so
some digging...
damien@ubuntu:~/Applications/firefox-debug/firefox-138.0.1$ grep -ir
"streqci" .
./parser/expat/expat/lib/xmltok.c:streqci(const char *s1, const char *s2) {
./parser/expat/expat/lib/xmltok.c: /* The following line will never
get executed. streqci() is
./parser/expat/expat/lib/xmltok.c: if (streqci(name, encodingNames[i]))
./parser/expat/expat/lib/xmltok_ns.c: if (streqci(buf, KW_UTF_16) &&
enc->minBytesPerChar == 2)
The source:
static int FASTCALL
streqci(const char *s1, const char *s2) {
for (;;) {
char c1 = *s1++;
char c2 = *s2++;
if (ASCII_a <= c1 && c1 <= ASCII_z)
c1 += ASCII_A - ASCII_a;
if (ASCII_a <= c2 && c2 <= ASCII_z)
/* The following line will never get executed. streqci() is
* only called from two places, both of which guarantee to put
* upper-case strings into s2.
*/
c2 += ASCII_A - ASCII_a; /* LCOV_EXCL_LINE */
if (c1 != c2)
return 0;
if (! c1)
break;
}
return 1;
}
This code a
Re: Trying to crack the Firefox crashing issue
On 12/5/25 1:49 am, John Paul Adrian Glaubitz wrote: Since you’re already working on this issue, please take the time to file an upstream bug report. I just need to find the right place to file it. Did some research on WASM today and found it is designed for LE only. I've also found some bug reports that bring up issues related to BE and it always comes back to not supported and road blocked. So if I don't want to file YABEI (yet another big endian issue) that gets an immediate won't fix. I just need to find the right place place and/or way to describe it to be accepted. And if you come up with a patch, please forward it upstream. I don’t have the time and nerves to work on this issue. I could see why. At this point in the game, making use of compiler attributes like GCC to mark scalar byte order are looking good, even if it would look like a hack. But, since code these days relies on CPU specific byte order and clean portable code is a relic of the past, such compiler dependent features are looking good to me. -- My regards, Damien Stewart.
Re: Trying to crack the Firefox crashing issue
On 9/5/25 8:17 pm, Ed Robbins wrote: I think it's because w2c_rlbox_streqci is an "rlbox" sandboxed version of the expat streqci function (https://rlbox.dev). It's transformed somewhere and not necessarily even compiled by gcc. I don't know how this web stuff, wasm, rlbox etc works, the toolchain is a total mystery to me... I'm not even sure if new C source is generated or if sandboxed functions are generated at compile time skipping C entirely. But it does look as though there's a fair chance the source code presented is what is eventually transformed into the asm code presented. However the bug could equally be in the toolchain somewhere... It would be the sandboxed version. I stepped through the code and a source comes up for a sandbox within a hpp source file. Right before it calls into the hidden or internal rlbox code it calls rlbox.wasm.c implying some sort of C source conjured up in between. -- My regards, Damien Stewart.
Re: Trying to crack the Firefox crashing issue
On 11/5/25 1:20 am, Damien Stewart wrote: Comparing with var_p0=var_p0@entry=262000 and var_p1=2016478208 p1 looks corrupted. There could some possibility of endian corruption. I reversed it and got $41578 or 267640 which is within range of 262000 in p0. Why p0 looks fine only p1 doesn't I don't know. Being register based means PPC has less chance of endian errors if registers are used to pass parameters. So if a code block could pass all generic data in registers, process it natively, then return result in registers, there would be less chance of endian errors. I've also read originally WASM was endian agnostic or processed in the native endian of host CPU, and was designed that way, but later they decided to change it to be non portable and hack it to be little endian only because that's defacto standard endian now days. Or something like that. Quoting myself here. I got it! I've got evidence it's endian corruption. :-) I tried reversing 2016478208 bytes and it worked! My numbers were off from above, which I suspected were, but the right one works. So this 2016478208 or $78310400 reverses to 274808 or $43178. I figured out what command to set a register and plugged it into r5. It performed the load! It's the static const char *const encodingNames[] array that's messed up. Or in reality the pointer offset reference. However it's coded it in. It's grabbed it from a data array off r30 at some point prior and going by the numbers stored the offsets are already corrupt. So whatever code is setting the box offset for that string has managed to byte swap it. This would easily run deep. What ever codes those offsets, it could be anywhere, with some being fine and others like this one being backwards. The source string reference being corrupted: https://salsa.debian.org/search?search=KW_ISO_8859_1&nav_source=navbar&project_id=21123&group_id=2641&search_code=true&repository_ref=release%2Fmaster I took a screen shot but not sure of the rules about attachments. -- My regards, Damien Stewart.
Re: Firefox 133 test package for ppc64
On 12/5/25 10:48 am, Ken Cunningham wrote: Some feedback for others who might try this... I started off by upgrading to firefox 138, which is the current default when you install or upgrade firefox, on my DualG5 with 3.5G Ram. It opened, but there was no content in the windows, and none of the firefox menus would respond after a long time. I can confirm this on my system. Which is has an R7 250 in it and because of that lacks hardware 3d and 2d by the looks of it, so I need to rely on fbdev. Firefox works a lot better by not crashing on startup. It opens up a window but only has borders as inside content is blank. I also see it ignoring menus. But the menu does pop up with the right side widget. Once of the checkmarks turned on but the menu bar would not. It would not quit. I had to kill it with kill. I didn't notice any unusually high cpu usage when I ran top to check. From CLI it did not print any messages. But I could Ctrl-C it to quit. It's way better than Epiphany, which I thought was once a humble and trusted browser, but one that now totally takes down my machine with a black screen of death. However, I got that loading by disabling GLX in my xorg config, but it complained that it couldn't load pages. So Firefox may rely GLX as well, since it's so huge, and could just as easily do a takedown. However, I do have another issue related to my GPU of choice, as my dmesg is full of GPU lock up errors. System Monitor and Nautilus are also faulty. From research this happens in the x86 world as well and no solution was found. Apart from the GPU being faulty and needing replacement. But, the latest Debain with xorg, is the only Linux install that has these issues. So xorg has some issue. Possibly another endianism. I expected LXDE to be better but it may be better to test MATE by the looks of it. I had installed this and others. Just need to switch to it which isn't as easy when you can't chose on login and wrestle with apt. :-) -- My regards, Damien Stewart.
Re: Firefox 133 test package for ppc64
On 12/5/25 11:37 pm, John Paul Adrian Glaubitz wrote: You may try to disable GPU acceleration. However, there doesn't seem to be a command line parameter for that. So, the easiest way would be to SSH into your ppc64 machine and run firefox with "firefox -no-remote". For example: $ ssh -X -C debian-ppc64 $ firefox -no-remote Then go into the settings menu to disable it, see [1]. Thanks. From my last testing of resetting profile I'll see if I need it. I tend to log in from a serial most of the time if I need too since I have an iBook constantly sitting by with a null modem link plugged in. -- My regards, Damien Stewart.
Re: Firefox 133 test package for ppc64
On 13/5/25 6:08 am, Ken Cunningham wrote: It's challenging to debug firefox. I have 3.5G of RAM, and I added an 8G swapfile, and with that firefox will run under gdb but it takes 15-18 minutes for firefox to start. It uses a lot of swapfile. That's a long time. When I first tested it under gdb I found my HDD thrashing because I had left an old swap partition active. Or actually the installer would have picked it up. I setup an SSD that I've dedicated to Linux installs but didn't add a swap partition too. Do you run it from SSD? I did add swap to my SSD but managed to install 8GB to my machine so I could load it into pure memory. That reduces it to around 2 minutes load time. Should time it. Then when you start interacting with is (eg ask it to open a website) it does a hard crash and locks up the system, with no opportunity to backtrace. Turns out gdb logging is off by default -- I'll turn that on and see if I can capture anything before it downs the system. Do you have any way of attaching a terminal? My system has a serial port so it's easy enough for me to do it the "old fashioned" way over serial cable with a "console=ttyS0" added to my kernel command line. Don't know if a G5 Mac USB supports but I found USB2/3 has a debug feature that's pretty much a modern drop in replacement for a serial port link. Just needs activating in kernel and the right USB cable. So kinda like the old way as you need a modern USB null modem cable now. :-) -- My regards, Damien Stewart.
Re: Firefox 133 test package for ppc64
On 12/5/25 11:18 pm, Ken Cunningham wrote: I can choose the desktop manager on login. There’s a menu of the installed ones to choose from. I’m using lightdm, I recall. Retested last night and found it is there hiding in the top menu. I think I'm just used to the Ubuntu themed lightdm where it's more obvious where you can pick desktop. However, I couldn't get it work. I've installed Cinnamon, MATE and somehow Wayland is there as well. My last test was Cinnamon software renderer, a solid choice. Nope, all options booted into LXDE. Need to scrape the logs. It's not as bad as the Ubuntu Bionic PPC I managed to get going where I did something to break the desktop and it just loops around on the login screen. -- My regards, Damien Stewart.
Re: Firefox 133 test package for ppc64
On 15/5/25 3:10 am, Ken Cunningham wrote: > At present, not from an SSD. It has been working OK until these challenges. > > I guess it's about time to repurpose one of my other SSDs to this system. I'll find one of the older, slower ones from the junk box that I took out of another system during an upgrade, and hopefully it will be compatible. > > Otherwise this is not going to be pleasant. I've got a 1TB Samsung HDD that's been in service over ten years now and still going strong. But I was gifted an SSD, just a 480GB. So thought I would put it to use as a dedicated Linux HDD and moved most of my Linux volumes over. > So far I have not got into debugging remotely from another system like that. I'm not sure what method would work best for my Apple Dual G5 PowerMac 7,1 (I recall it's a 7,1 -- hopefully that is right). I know these systems can do that, I read about kernel debugging in MacOS using two machines. I think those instructions were with an ethernet cable, but that is MacOS there. There's a few options Linux supports on the command line. Ethernet would be common. But also relies on a working TCP stack or minimal Ethernet driver. Which is why it's good to have serial around. Simple interface that only needs a simple hardware banging driver. :-) In the meantime it looks like I've found where the little endian offsets are coming from. So in a convoluted process to secure code inside a VM, it compiles C to web assembly, which then transcodes it back into C again affer being wrapped inside the RLBox routines to manage it, and then finally compiles the result into a binary. The code that compiles assembly is endian aware and looks like it codes the assembly stream to be little endian when compiled on a big endian CPU. But it does in an awkward way. The original code uses memcpy() even if it should be sufficient and faster to just store scala data directly. But in big endian it does a memcpy(), then copies to a temp array, byte swaps the array and copies the array! Terrible! They just should have written a reverse byte copy and avoid the mess. In any case since the assembly is little endian the byte code is technically correct. The problem then is in the RLBox wrapper as the native code generated is not byte swapping in the final C generated. It's likely removing the swaps from web compiler would actually fix it to work. Perhaps enough to work on big endian. But because it complicates the process by using web assembly as a middleman means such a solution wouldn't be technically correct. Though the fault would end up in the RLBox transcoder not byte swapping when reading scala data offsets it uses to generate C code. -- My regards, Damien Stewart.
Update on rlbox wasm sandbox crashes
;t pretty. Yet I manged to find
every byte out of place and fix to be portable. So now, I can see that
disabling the sandboxing is for now likely the best fix, because if it
worked the code would be even slower. But, the compromise is here is
more security, so getting it working down the track is a good idea
regardless and even for an "exotic endian" platform. In the mean time,
I'll continue digging, now it's becoming clearer where to point the
finger. And what I can use as an MVE.
Links:
https://github.com/PLSysSec/rlbox
https://github.com/PLSysSec/rlbox_wasm2c_sandbox
https://github.com/PLSysSec/rlbox-book
The wasm2c [excuse for a] man page example:
https://manpages.debian.org/bookworm/wabt/wasm2c.1.en.html
That quirky macro:
static inline void load_data(void* dest, const void* src, size_t n) {
if (!n) {
return;
}
size_t i = 0;
u8* dest_chars = dest;
wasm_rt_memcpy(dest, src, n);
for (i = 0; i < (n >> 1); i++) {
u8 cursor = dest_chars[i];
dest_chars[i] = dest_chars[n - i - 1];
dest_chars[n - i - 1] = cursor;
}
}
--
My regards,
Damien Stewart.
Re: u-boot
On 9/7/25 9:08 pm, David VANTYGHEM wrote: Hello, Is https://u-boot.org/about/ an interesting alternative to GRUB? I'm familiar with U-Boot. The description as a boot loader can be confusing, because it runs as the firmware. So U-Boot does the same as OpenFirmware does. It lives in a boot ROM and boot straps the machine. But it can act as both firmware and boot loader since it can also boot media directly. I wasn't aware of it being used as a middle man boot loader and a brief search revealed it can be. But it would likely be too much work to give an alternate to both GRUB and yaboot. Another possibility is using the Mac method with a bootable volume you can chose from the GUI boot menu. But I'm not aware of anyone coding a way for Linux to do that. Although I had expected it to be used before I found how PPC Linux boots on a Mac. -- My regards, Damien Stewart.
Re: u-boot
On 9/7/25 11:32 pm, John Paul Adrian Glaubitz wrote: I don't think so as u-boot is harder to use and also requires explicit support for every hardware in question. And since u-boot doesn't support Open Firmware/ieee1275, you won't be able to use it on standard PowerMac hardware. It does have the device tree support now. But that really only helps a developer. Less so an end user. -- My regards, Damien Stewart.
Re: Update on rlbox wasm sandbox crashes
On 10/7/25 6:34 pm, John Ogness wrote: Hi Damien, Thanks for providing these insights! Happy to share. :-) It seems to me that this is where the big-endian/browser community should be focussing its efforts: wasm2c generating portable code. John Ogness After testing it I agree. It really is a multi layered approach to isolation with it being compiled to a virtual binary, decompiled into C and then wrapped in another software layer before being compiled again. The issue here being the virtual binary in the middle designed for an opposite endian. On that note, last night I confirmed my suspicions were correct. I found an issue with a data table related to some stdout handle. It stores stdout as some offset which acts an address in the isolated memory space that points to this table. Later it reads from the table at that offset and because the table is opposite endian the values are all backwards. I just confirmed on x64 from same routine that a $0500 is meant to be a $05. I don't know why it insists on writing tables as bytes as if trying to hide data. But if it just included the scalar data as a normal array or struct, with the value it is supposed to have, it would avoid all this endian hacking and would work normally. :-? Given the macro reverses the same table, I wonder of they meant to convert the table to host endian, but made an amusing blunder of swapping the whole table instead of each scalar? So either the table needs to be fully converted with knowledge of each scalar size. Or table reference routines need to swap on the spot. That's what I'm thinking. If the endian issues are isolated to this table and wasm2c knows what's in it this will be a lot easier to fix. :-) -- My regards, Damien Stewart.
Re: Firefox 133 test package for ppc64
On 7/7/25 6:37 am, James Madgwick wrote: For what it's worth, I've just installed 138 and initially a window appeared but I couldn't interact with any menus or do anything. But after removing .mozilla I was able to get it working. Based on this, it seems clearing that directory is required. That's what I found as well. I recall I found a way to reset profile and then it worked. The only obvious flaw is a random looking blue rectangle appearing over tabs. If you are patient speedtest.net can actually work. What I don't understand is why the profile needs removing or resetting since I installed it on a fairly fresh Debian install with a default FireFox installed. But, given the FireFox I had before crashed on startup, may have corrupted the default profile. Also, as a bonus, if you still have an older Linux like Ubuntu Xenial you still like using you can run the latest FireFox! :-P It's not too hard. So all you need to do is mount your modern Debian Linux or compatible. Do a chroot to it from terminal. And run firefox as your user from sudo or logging in. Doesn't need any settings for X and amazingly opens up a window right on your desktop. One caveat is downloads will go to the mounted volume. But if you have a shared home setup it will make it easier. It's possible it could be automated with a nice desktop icon and script or even package, but I was to lazy to do that yet. :-D -- My regards, Damien Stewart.
Re: Firefox 133 test package for ppc64
On 24/7/25 12:21 pm, Cedar Maxwell wrote: I found Luakit (in the repo) works very well. It plays YouTube better on my iBook G4 than Firefox does on my PowerMac G5. Yet it has only been mentioned twice ever in this mailing list. Thanks for the hint. I'd never heard of this Luakit before. I don't quite understand embedding Lua into it. It's just that I imagine a browser running interpretive scripts would slow it down. Even though that's been happening for years now. -- My regards, Damien Stewart.
