Re: Performing dist-upgrade on powerpc and ppc64

[Jeffrey Walton]

On Tue, Apr 16, 2024 at 1:14 PM Riccardo Mottola 
wrote:

> Hi Adrian,
>
> so you suggest to use powerful scripts.
> Ok, got dget (from devscripts) and sbuild.
> Added my user do sbuild group.
>
> John Paul Adrian Glaubitz wrote:
> > You can fetch the source from here:
> >
> > $ dget -uhttp://
> snapshot.debian.org/archive/debian/20220801T085926Z/pool/main/p/python2.7/python2.7_2.7.18-13.2.dsc
> >
> > Then build the package with sbuild:
> >
> > $ sbuild -d sid --arch-all --arch=powerpc python2.7_2.7.18-13.2.dsc
> >
>
> So sbuild complaints I need a chroot environment. I guess that helps
> with build-dependencies only being temporary installed for the build, as
> opposite to use dpkg-buildpackage directly?
>
> How can I best chreate the chroot, best would be it using by local apt
> cache perhaps, I'm unsure.
>
> Take in account this is on an iBook G4, so not a server with big space.
>
> I think I need the correct setup for sbuild-createchroot ? What
> parameters do you suggest or used on your local system?
>
> I am skimming through a debian guide [1] and perhaps Using
> /var/cache/apt/archives/ as package cache is a good idea?
>
> [1]
>
> https://wiki.debian.org/sbuild#Automatic_setup_using_sbuild-debian-developer-setup


In the old days, you could setup a chroot for PowerPC using the following.
I think it still works, but I recall something about using qemu-debootstrap
nowadays.

qemu-debootstrap --arch=powerpc --keyring
/usr/share/keyrings/debian-ports-archive-keyring.gpg \
  --variant=buildd --exclude=debfoster unstable debian-powerpc
http://ftp.ports.debian.org/debian-ports

The Debian host can use any flavor of Debian. I usually use Stable for the
host.

The Debian chroot guest must use Unstable. Once you create the chroot
guest, open the guest's /etc/apt/sources.list and change it to Unstable.

Jeff

Re: LibreOffice crash - rijndael.c: No such file or directory

[Jeffrey Walton]

On Thu, Feb 29, 2024 at 7:07 PM Casey C  wrote:
>
> Hello,
>
> All versions of LibreOffice that I've tested after 7.3.5 appear to have
> a bug which causes the application to crash when attempting to open a
> previously saved document.
>
> When running via gdb, the application ends with the following output:
>
> "Thread 1 "soffice.bin" received signal SIGILL, Illegal instruction.
> rijndael_encryptCBC (cx=0x53a8a80, output=0x53a88c0 "\005:�\230",
> outputLen=, maxOutputLen=,
> input=0x52cb860 "password-check\002\002\005,�d",
> inputLen=)
> at rijndael.c:780
> 780 rijndael.c: No such file or directory.
> (gdb)"
>
> Has anyone else experienced this issue? Is there a missing depends?

SIGILL is probably due to in-core AES crypto instruction from POWER8
and above. It sounds like the call to rijndael_encryptCBC is _not_
being guarded with a runtime check. Instead of falling back to a
software-only implementation, it sounds like POWER8 AES instructions
are being used unconditionally.

In the past, the problem was due to building the package with
-mcpu=power8 or similar. It happens to a lot of packages.

Jeff

Re: Test failures on ppc64el for camelot-py

[Jeffrey Walton]

On Wed, Feb 14, 2024 at 5:35 AM Elena ``of Valhalla''
 wrote:
>
> I'm the maintainer of camelot-py and when I enabled autopkgtests for the
> package I've had a failure on ppc64el
>
> https://ci.debian.net/packages/c/camelot-py/testing/ppc64el/42972030/
>
> all other architectures pass, and I have no experience on ppc64el, so I
> don't know what could be causing this: do you have any hint on things I
> could look out for?
>
> I've opened a bug to keep track of the issue, and I'm also going to
> report it on the upstream bugtracker, in case they would also have
> useful hints to find a solution.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063891
>
> If I can't find a proper solution I guess I will just disable the
> autopkgtests on ppc64el, but if anybody can help me in finding a proper
> solution I'd be grateful.

One of the first things to do is, sign up for a GCC Compile Farm
account,  and
. It is free for free and open source
software developers. See "Request an Account" in the menu bar at
.

The CFarm provides plenty of PowerPC machines to test on:
. cfarm29 provides ppc64le.
Once your account is approved, SSH into the machine with 'ssh
cfarm29.cfarm.net'.

You should also consider testing on cfarm110, which is big-endian.

Another notable is cfarm119. It is also big-endian, but it runs AIX.

Jeff

Re: Debian 12 on iMac G5

[Jeffrey Walton]

On Sun, Feb 4, 2024 at 3:33 PM Claudia Neumann
 wrote:
>
> Hi John, hi Frederico,
>
> I tried debian-12.0.0-ppc64-NETINST-1.iso from 31.1.2024.
>
> The Mac G5 stops with
>
> smp_core99_probe
>
> smp_core99_bringup_done
>
> I tried with
>
> radeon.modeset=1 video=offb:off nomodeset
>
> radeon.agpmode=-1 radeon.modeset=1 video=offb:off nomodeset
>
> in grub. No better.
>
> Now I have the problem, that I don't get the DVD out of the drive. With my 
> try of debian-11.0.0-ppc64-NETINST-1.iso from 14.5.2023 I partitioned the 
> hard drive. So there is no bootable kernel on the hard drive.
>
> Can I boot from USB?

I don't think you can boot from USB on G5's. Or I was not able to boot
from a USB thumb drive when I installed Debian on my PowerMac G5. The
Open Firmware would not allow it. I had to burn the CD or DVD.

Jeff

Re: cmake ftbfs on ppc64el (and ppc64)

[Jeffrey Walton]

On Thu, Jan 11, 2024 at 1:16 PM John Paul Adrian Glaubitz
 wrote:
>
> the bug is definitely still present and I'm therefore not sure whether
> downgrading the priority to normal is justified.
>
> On ppc64, cmake still crashes regularly when configuring the LLVM build
> for example [1]:
>
> -- Looking for pow in m - found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Looking for backtrace in execinfo
> Segmentation fault
>
> I have performed a local LLVM test build and obtained a backtrace with gdb
> which also indicates a crash in libuv:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x in ?? ()
> [Current thread is 1 (Thread 0x7fff811f6e60 (LWP 2635470))]
> (gdb) bt
> #0  0x in ?? ()
> #1  
> #2  0x7fff82eee784 in __GI_epoll_pwait (epfd=4, events=0x7fffd3808cc8, 
> maxevents=1024, timeout=-1, set=0x0) at 
> ../sysdeps/unix/sysv/linux/epoll_pwait.c:40
> #3  0x7fff83545238 in uv__io_poll (loop=0x10015e8edd0, timeout=-1) at 
> ./src/unix/linux.c:1365
> #4  0x7fff8352aa84 in uv_run (loop=0x10015e8edd0, mode=UV_RUN_ONCE) at 
> ./src/unix/core.c:447
> #5  0x000132669d8c in cmExecuteProcessCommand (args=..., status=...) at 
> ./Source/cmExecuteProcessCommand.cxx:358
> #6  0x000132561d38 in InvokeBuiltinCommand (status=..., args=..., 
> command=@0x133045248: 0x1326682b0 
>  std::char_traits,
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, 
> cmExecutionStatus&)>)
> at ./Source/cmState.cxx:420
> #7  operator() (status=..., args=..., __closure=) at 
> ./Source/cmState.cxx:430
> #8  std::__invoke_impl BuiltinCommand)::&, 
> cmExecutionStatus&)>&, const
> std::vector >&, 
> cmExecutionStatus&> (__f=...) at /usr/include/c++/13/bits/invoke.h:61
> #9  std::__invoke_r BuiltinCommand)::&, 
> cmExecutionStatus&)>&, const std::vector std::allocator >&, cmExecutionStatus&> (__fn=...) at 
> /usr/include/c++/13/bits/invoke.h:114
> #10 std::_Function_handler std::allocator >&, cmExecutionStatus&), 
> cmState::AddBuiltinCommand(const std::string&,
> BuiltinCommand):: std::allocator >&, cmExecutionStatus&)> 
> >::_M_invoke(const std::_Any_data &, const std::vector std::allocator > &, cmExecutionStatus &) (__functor=..., 
> __args#0=..., __args#1=...) at /usr/include/c++/13/bits/std_function.h:290
>
> This bug has also been reported for openSUSE [2] and Simon Lees at SUSE said 
> he
> would be looking into it. In case he comes up with a solution, I will report 
> it
> here.
>
> > [1] 
> > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-17=ppc64=1%3A17.0.6-4%2Bb2=1704985815=0
> > [2] https://bugzilla.suse.com/show_bug.cgi?id=1218365

It may be a good idea to give the CMake folks the first chance at the
fix. It does not look like it has been reported to them:
. Searching with
'ppc' and 'llvm' tags returned 0 hits:
.
(Maybe I missed it in their bug tracker).

Jeff

Re: RM: icinga2 [armel mips64el ppc64el riscv64] -- ROM; FTBFS

[Jeffrey Walton]

On Tue, Jan 2, 2024 at 11:44 PM Sebastiaan Couwenberg
 wrote:
>
> On 1/3/24 00:02, Aurelien Jarno wrote:
> > On 2023-12-22 15:43, Bas Couwenberg wrote:
> >> Please remove icinga2 from armel, mips64el, ppc64el, riscv64 where it 
> >> FTBFS to unblock testing migration.
> >
> > What is the reasoning behind the removal, especially for riscv64 which
> > built successfully?
>
> armel:
>
>   /<>/lib/base/application.hpp:148:33: error: static
> assertion failed
>
>
> https://buildd.debian.org/status/fetch.php?pkg=icinga2=armel=2.14.1-1=1703225119=0
>
> mips64el:
>
>   152 - base-methods_pluginnotificationtask/truncate_long_output (Failed)
>
>
> https://buildd.debian.org/status/fetch.php?pkg=icinga2=mips64el=2.14.1-1=1704107092=0
>
> ppc64el:
>
>   152 - base-methods_pluginnotificationtask/truncate_long_output (Failed)
>
>
> https://buildd.debian.org/status/fetch.php?pkg=icinga2=ppc64el=2.14.1-1=1703225525=0
>
> riscv64:
>
>   /usr/bin/ld: /usr/lib/riscv64-linux-gnu/libboost_coroutine.so.1.83.0:
> undefined reference to `jump_fcontext'
> /usr/bin/ld: /usr/lib/riscv64-linux-gnu/libboost_coroutine.so.1.83.0:
> undefined reference to `make_fcontext'
>
>
> https://buildd.debian.org/status/fetch.php?pkg=icinga2=riscv64=2.14.1-1=1703250691=0
>
> https://buildd.debian.org/status/fetch.php?pkg=icinga2=riscv64=2.14.1-1=1703201911=0
>
> Only the third try built successfully.
>
> > Have you asked the porters for help before asking for the removal?
>
> Obviously not, as you would have seen that request. I assumed you have
> better things to do during Christmas season. This RM bug unblocked
> testing migration without involving even more people.
>
> The Debian servers on these architectures are likely the only users of
> the icinga2 package so it would be good to get the package to build
> there again, but it is not a priority for me. Upstream is unpleasant to
> work with and requires a CLA which I refuse to spend my time on, so
> beware of that if you intend to patch icinga2 to fix the FTBFS issues.

Also see .

Re: What are the current available browser options for debian-ppc64?

[Jeffrey Walton]

On Mon, Nov 20, 2023 at 1:56 PM Ken Cunningham
 wrote:
>
> On 2023-11-20, at 2:06 AM, John Paul Adrian Glaubitz wrote:
>
> >> On Nov 20, 2023, at 10:56 AM, Jeroen Diederen  
> >> wrote:
> >>
> >> Firefox does not work.
> >
> > Did you try the latest version 119?
> >
> > If there is a patch which fixes the crash on big-endian targets, we could 
> > include it in the Debian package or I could try to get it merged upstream.
> >
> The one I have installed is:
>
> firefox/unstable,now 119.0.1-1 ppc64
>
> and it has a segmentation fault when you launch it.

Out of curiosity... would that happen to be a G4 or a non-Altivec machine?

Jeff

Re: unbreaking LibreOffices tests on at least release architectures

[Jeffrey Walton]

On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard  wrote:
>
> Am 22.07.23 um 14:02 schrieb Andreas Schwab:
> > On Jun 18 2023, Rene Engelhard wrote:
> >
> >> For riscv64 I already pointed that out in the thread starting at
> >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
> >> other architectures there is the mail now. riscv64 is different because
> >> the failures are even more big than any other down below and it's actually
> >> a new architecture anyway.
> > Libreoffice is actually basically working on riscv64.
>
> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile
> says, though)

Be careful of -Os. I test one of my C++ libraries with it in the
library's test suite. Based on unexplained crashes with -Os, I believe
GCC produces bad code with -Os on occasion.

I do not recommend using -Os in production based on my experience.

Jeff

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

[Jeffrey Walton]

On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox  wrote:
>
> On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > Then we should delete the HFS/HFS+ filesystems.  They're orphaned in
> > > MAINTAINERS and if distros are going to do such a damnfool thing,
> > > then we must stop them.
> >
> > Both HFS and HFS+ work perfectly fine. And if distributions or users are so
> > sensitive about security, it's up to them to blacklist individual features
> > in the kernel.
> >
> > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years
> > and I don't think it's justified to introduce such a hard compatibility
> > breakage just because some people are worried about theoretical evil
> > maid attacks.
> >
> > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac
> > and I don't think it's okay to break all these systems running Linux.
>
> If they're so popular, then it should be no trouble to find somebody
> to volunteer to maintain those filesystems.  Except they've been
> marked as orphaned since 2011 and effectively were orphaned several
> years before that (the last contribution I see from Roman Zippel is
> in 2008, and his last contribution to hfs was in 2006).

One data point may help.. I've been running Linux on an old PowerMac
and an old Intel MacBook since about 2014 or 2015 or so. I have needed
the HFS/HFS+ filesystem support for about 9 years now (including that
"blessed" support for the Apple Boot partition).

There's never been a problem with Linux and the Apple filesystems.
Maybe it speaks to the maturity/stability of the code that already
exists. The code does not need a lot of attention nowadays.

Maybe the orphaned status is the wrong metric to use to determine
removal. Maybe a better metric would be installation base. I.e., how
many users use the filesystem.

Jeff

Re: strlcpy and strlcat added to glibc 2.38

[Jeffrey Walton]

On Tue, Jul 18, 2023 at 4:16 AM John Paul Adrian Glaubitz
 wrote:
>
> Some of you may remember the discussion we had regarding the »hfs« package
> and the efforts to port it to Linux [1]. One of the issues with the package 
> was
> the use of strlcpy and strlcat which have so been unsupported by glibc.

I think you can thank Ulrich Drepper for that
(https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00053.html):

> this patch implements the string functions strlcat and
> strlcpy for gnu libc.

This is horribly inefficient BSD crap.  Using these function only
leads to other errors.  Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).

And the irony... glibc makes regular appearances on BugTraq for its
mishandling of C strings.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=glibc .

> Luckily, this has changed now and support for both has been added to glibc [2]
> meaning the Linux port of the »hfs« package has become slightly easier ;-).

Glad to hear it.

> FWIW, I will resume working on the »hfs« package later this week as my 
> vacation
> starts tomorrow.

Rub it in :)

> > [1] https://lists.debian.org/debian-powerpc/2023/05/msg00094.html
> > [2] 
> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=454a20c8756c9c1d55419153255fc7692b3d2199

Jeff

Re: Please help reporting upstream bugs

[Jeffrey Walton]

On Sat, Jun 24, 2023 at 5:10 AM John Paul Adrian Glaubitz
 wrote:
>
> There are still many packages in Debian that fail to build from source on 
> PowerPC
> targets, both 32-bit and 64-bit big-endian PowerPC, so I thought it might be 
> a good
> idea to ask the community for help reporting these bugs upstream.
>
> The list of affected packages can be found by following these two links for 
> powerpc
> and ppc64, respectively:
>
> > https://buildd.debian.org/status/architecture.php?a=powerpc=sid
> > https://buildd.debian.org/status/architecture.php?a=ppc64=sid
>
> Look for "Build-Attempted" section and click any of the package names to get 
> to the
> package's build result overview. Then click onto "Build-Attempted" link in 
> the "Status"
> column to obtain the build log of a package that failed to build from source 
> (FTBFS),
> hold the "Ctrl" key to open the build log in a new browser tab.

The list is large. Does Debian have a page of packages (which FTBFS)
it would like fixed based on a priority?

> [...]

Jeff

Re: unbreaking LibreOffices tests on at least release architectures

[Jeffrey Walton]

On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard  wrote:
>
> Am 20.06.23 um 00:03 schrieb Jeffrey Walton:
> >
> > You can usually uncover them by building the package with CFLAGS=" ...
> > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
> > ". The UBsan sanitizer operates on real data. There are no false
> > positives.
>
> I'd personally assume this isn't UB since upstream builds with UBsan for
> testing (admittedly not on mipsel, though). But once can investigate here...

Yeah, there's a caveat: you have to have complete self tests. If the
project lacks complete self tests, then you may not uncover the bug.

You can run the program in production with a sanitizer build. It may
uncover cases that were lacking in the test cases.

And it's unfortunate some arches lack Asan and UBsan support. They are
such powerful tools. Sometimes you can tease-out the UB on a different
arch. Sometimes you can't.

Jeff

Re: unbreaking LibreOffices tests on at least release architectures

[Jeffrey Walton]

On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard  wrote:
>
> Hi,
>
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
> > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
> >> ...
> >> I won't be of much help here unfortunately, except
> >> maybe testing patches, but then again there's porterboxes
> >> ...
> > You are the only one who could realistically debug many of these.
> >
> > E.g. on armel it says:
> >Fatal exception: Signal 6
> >Stack:
> >/<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4]
> >/<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534]
> >
> > /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0]
> >/lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c]
> >/lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360]
> >Aborted (core dumped)
> >
> > Fixing something like this would involve generating a backtrace,
> > and then you are likely the only person in Debian who could tell
> > what is actually going on there.
>
> Not really.
>
> > There are likely also build or debug tricks you know that a porter would
> > not know.
>
> True, I can help with those if needed.
>
> (As I already pointed out for zelenka, though it's basically setting
> some variables in rules)
>
> > Debugging something like this is only feasible with reasonable effort if
> > a porter who knows the port with its caveats debugs it together with a
> > package maintainer who knows the internals of the package.
>
> I didn't say I was not helping, I said I am of no help if it comes to
> actually fix it if it involves architecture knowledge.
>
> [...]
>
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep fixing them
> if I report them.
> > The pragmatic option would be to run only a smoketest for build success
> > on architectures not tested by upstream.
>
> And have Format->Character in Impress crash with Bus error like on
> mipsel? That doesn't sound too good for basic quality.
>
> There is a "smoketest" but it does just basic start. open, close stuff.
> Not even basic usage.

Related, bus errors are usually due to unaligned data accesses.
Programmers casting from one type to another when when they shouldn't,
like:

typedef unsigned char byte;
...
byte buffer[32];

readBuffer(buffer);
double d = *(double *)buffer;

That is undefined behavior because a byte buffer is a byte buffer, and
it is not a double. That can result in a bus error on some platforms.
You may get lucky and the byte buffer may be aligned for double. Or it
may not be.

In contrast, this would be Ok because the byte buffer is really a double object:

typedef unsigned char byte;
...
double d;
byte* buffer = (bytes*)

readBuffer(buffer);
double dd = *(double *)buffer;

You can usually uncover them by building the package with CFLAGS=" ...
-fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
". The UBsan sanitizer operates on real data. There are no false
positives.

You don't need to be a porter to build and run with sanitizers.
However, you do need an arch-specific machine. Or possibly a Debian
chroot.

Jeff

Re: Radeon 9600 graphics on an eMac (powermac6,4)

[Jeffrey Walton]

On Sun, Jun 11, 2023 at 3:56 PM Maite Gamper  wrote:
>
> Hello,
> I've just installed the debian 12 port on my eMac.
> After the radeon_drm driver does the modesetting, the screen turns
> black with the drm showing some errors (I ran dmesg over ssh):
>
> [6.804973] radeon :00:10.0: Invalid PCI ROM header signature:
> expecting 0xaa55, got 0x
> [6.804997] radeon :00:10.0: Invalid PCI ROM header signature:
> expecting 0xaa55, got 0x
> [6.805007] [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a
> BIOS ROM
>
> xorg and lightdm both seem to start without a problem.
> I've installed the firmware-linux package including the non-free firmware.
> I also had this problem with openBSD and another linux distribution I
> had tried
> previously. Is there a way to get video working on that computer?
>
> I attached the dmesg output below.
> I'm new to the list, please tell me if I did something wrong.
> [ ... ]

I think you should be loading radeonfb, but I don't see it mentioned
in your dmesg output. Also see
https://wiki.debian.org/DeviceDatabase/PCI?highlight=(9600) .

I can't help with the G3 problem, but here's what I found with a G5...

I found the easiest path was to replace the stock NVIDIA GeForce FX
5200 card with a Radeon 1900 card on my G5. I was not able to get
Debian to work with the NVIDIA card on the G5.

I seem to recall Apple used a special Radeon 1900, and not a standard
one. I bought the Apple compatible Radeon X1900 GT from eBay.

Here are the drivers loaded for my G5, in case it helps.

$ grep -i -E 'radeon|video|drm|display|gpu' /proc/modules
amdgpu 9374033 0 - Live 0x
radeon 2298068 3 - Live 0x
drm_buddy 11845 1 amdgpu, Live 0x
gpu_sched 41023 1 amdgpu, Live 0x
i2c_algo_bit 9361 2 amdgpu,radeon, Live 0x
drm_display_helper 147756 2 amdgpu,radeon, Live 0x
drm_ttm_helper 4100 2 amdgpu,radeon, Live 0x
ttm 83004 3 amdgpu,radeon,drm_ttm_helper, Live 0x
drm_kms_helper 181723 3 amdgpu,radeon,drm_display_helper, Live
0x
drm 567853 11 
amdgpu,radeon,drm_buddy,gpu_sched,drm_display_helper,drm_ttm_helper,ttm,drm_kms_helper,
Live 0x
drm_panel_orientation_quirks 1620 1 drm, Live 0x

Jeff

Re: IBM RS/6000's available

[Jeffrey Walton]

On Thu, Jun 8, 2023 at 4:09 PM Jeffrey Walton  wrote:
>
> Hi Everyone,
>
> The RS/6000's came up recently in another thread. I have a couple of
> them sitting in my basement. They are RS/6000 servers. They were used
> as firewalls at a state agency back around the early 2000's. They have
> network cards but no accessories, like a mouse or keyboard.
>
> The machines are looking for a good home. If you are interested in one
> of them, then please let me know. I'll ship it to you at no cost. I'm
> in the US. European folks will have to pay the VAT.

All of the machines have been claimed. Thanks for providing homes to them.

Jeff

IBM RS/6000's available

[Jeffrey Walton]

Hi Everyone,

The RS/6000's came up recently in another thread. I have a couple of
them sitting in my basement. They are RS/6000 servers. They were used
as firewalls at a state agency back around the early 2000's. They have
network cards but no accessories, like a mouse or keyboard.

The machines are looking for a good home. If you are interested in one
of them, then please let me know. I'll ship it to you at no cost. I'm
in the US. European folks will have to pay the VAT.

Jeff

Re: Are G3/ no altivec cpu still usable on Debian?

[Jeffrey Walton]

On Sun, Jun 4, 2023 at 11:10 PM Paul Wise  wrote:
>
> On Sun, 2023-06-04 at 06:51 -0400, Jeffrey Walton wrote:
>
> > Altivec detection on Linux is relatively easy nowadays using
> > getauxval(). From
> ...
> > instead of using a query via getauxval(), OpenSSL does a runtime probe
> > by executing an Altivec instruction. If a SIGILL is encountered, then
> > Altivec is false.
>
> These are all obsoleted by GCC function multi-versioning where possible
> and a manual ifunc that uses the __builtin_cpu_supports builtin
> function where not possible.
>
> https://wiki.debian.org/InstructionSelection
>
> The comment about GCC support for PowerPC being spotty is probably
> incorrect, it would be great if that could be verified though.

Crypto++ and OpenSSL support back to GCC 3. Function multiversioning
and ifunc's are not available back that far.

For modern versions of GCC, GCC is still broken for C++ templates.
This does not work. It will not compile.

__attribute__ ((target ("default")))
template 
int foo ()
{
  // The default version of foo.
  return ...;
}

__attribute__ ((target ("sse4.2")))
template 
int foo ()
{
  // foo version for SSE4.2
  return ...;
}

__attribute__ ((target ("avx2")))
template 
int foo ()
{
  // foo version for AVX2
  return ...;
}

And there's no measurable difference in performance if you do this at
runtime versus ifunc's (and friends):

bool has_altivec = DetectAltivec();
if (has_altivec) {
// SIMD impl using Altivec
} else {
// C/C++ impl
}

Jeff

Re: Collaborating on the HFS code

[Jeffrey Walton]

On Sun, Jun 4, 2023 at 5:20 AM John Paul Adrian Glaubitz
 wrote:
>  [...]
>
> There is currently one limitation with the HFS patch as it doesn't allow 
> setting
> a custom volume name and hard-wires it to "untitled" [4]. This is because the
> original code uses an Apple-specifc function to convert UTF-8 into Mac 
> encoding [5],
> if someone has a suggestion how to implement this encoding conversion on 
> Linux, I
> would be happy to integrate this change into the (current) »hfsprogs« package 
> as
> this would fix an open bug [6].

Apple has a modified iconv, if I recall correctly. It is modified for
their filesystem, and it properly handles filenames on OS X. I don't
know about MacOS 9, however.

An open source port of Apple iconv with utf-8 support is available at
https://github.com/fumiyas/libiconv-utf8mac .

Jeff

Re: Are G3/ no altivec cpu still usable on Debian?

[Jeffrey Walton]

On Sun, Jun 4, 2023 at 6:15 AM Lorenzo  wrote:
>
> On Sat, 03 Jun 2023 12:14:47 +0200
> John Paul Adrian Glaubitz  wrote:
>
> > Hello!
> >
> > On Sat, 2023-06-03 at 11:29 +0200, Lorenzo wrote:
> > > There is a bug in mplayer [1] that could be fixed by building a
> > > variant of mplayer without altivec, however I can't tell if such
> > > bug can still be triggered nowadays. The ppc port is gone right?
> > > Are cpus without altivec still usable on one of Debian's powerpc
> > > ports?
> >
> > No, Debian for 32-bit PowerPC is still maintained as an unofficial
> > port:
> >
> > > https://cdimage.debian.org/cdimage/ports/snapshots/2023-05-28/debian-12.0.0-powerpc-NETINST-1.iso
> >
> > As for Altivec support in mplayer: Have you tried the latest version?
> > It might be possible there is proper runtime detection these days.
>
> According to mplayer upstream [1] "AltiVec runtime detection never
> worked reliably" and "the way it was detected in libavcodec was an
> unacceptable hack".. that was in back in 2007, I'll check if upstream
> still consider runtime detection unfeasible.
>
> [...]
>
> [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448105

Altivec detection on Linux is relatively easy nowadays using
getauxval(). From
https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L1210 :

inline bool CPU_QueryAltivec()
{
#if defined(__linux__) && defined(PPC_FEATURE_HAS_ALTIVEC)
if ((getauxval(AT_HWCAP) & PPC_FEATURE_HAS_ALTIVEC) != 0)
return true;
#elif defined(_AIX)
if (__power_6_andup() != 0)
return true;
#elif ...
#endif
return false;
}

Botan uses similar runtime detection via getauxval() at
https://github.com/randombit/botan/blob/master/src/lib/utils/cpuid/cpuid_ppc.cpp.

OpenSSL performs runtime probes in
https://github.com/openssl/openssl/blob/master/crypto/ppccap.c. But
instead of using a query via getauxval(), OpenSSL does a runtime probe
by executing an Altivec instruction. If a SIGILL is encountered, then
Altivec is false.

The tricky machines are Apple running MacOS 9 and OS X. You have to be
careful of runtime probes and SIGILLs. On Apple machines, memory
corruption happens with runtime CPU probes.

Jeff

Re: Fork of current version of »hfs« package

[Jeffrey Walton]

On Tue, May 30, 2023 at 11:12 PM Lennart Sorensen
 wrote:
>
> On Tue, May 30, 2023 at 09:24:42PM -0400, Jeffrey Walton wrote:
> > Blocks are like C++ lamda's. ObjC folks like to use them to ensure
> > cleanup in a function, like releasing a handle or free'ing memory.
>
> Funny how the high level description of them couldn't even bother so
> explain that.  That does make some sense.

Yeah, I remember NSBlock from ObjC programming back in the day. Then
blocks started showing up on other platforms due to Clang providing
them. For example, Asterisk PBX software uses them to tame their
memory leaks. Asterisk used to leak like a sieve. Asterisk only builds
with Clang because of them.

Jeff

Re: Fork of current version of »hfs« package

[Jeffrey Walton]

On Tue, May 30, 2023 at 4:40 PM Lennart Sorensen
 wrote:
>
> On Tue, May 30, 2023 at 01:24:15PM +0200, John Paul Adrian Glaubitz wrote:
> >
> > I have started working on an updated »hfsprogs« packages based on the
> > split-out version of the HFS(+) code in the »hfs« package. For this,
> > I have forked Apple's original »hfs« package on Github [1].
> >
> > Feel free to start contributing. It's currently work-in-progress as
> > »fsck_hfs« does not compile yet and the code needs further clean-up
> > which I will be doing later this week.
> >
> > > [1] https://github.com/glaubitz/hfs/tree/linux
>
> I had a poke at it, dealt with a couple of compile issues, then
> encountered Blocks and went WTF did Apple invent here?  I don't even
> understand the description of their proprietary extension to C/C++/ObjC.

Blocks are like C++ lamda's. ObjC folks like to use them to ensure
cleanup in a function, like releasing a handle or free'ing memory.

> I had never seen code with ^ prefixed to things in this way and since I
> don't understand what Blocks are supposed to accomplish I have no idea
> how to remove them from the code.

Jeff

Re: illegal instruction on atan2

[Jeffrey Walton]

On Mon, May 22, 2023 at 12:20 PM Alexandre Bencz  wrote:
>
> I did some analysis here... I identified exactly where the error is
> occurring:
>
> gdb --args ./bin/latLngToCell --resolution 10 --latitude 40.689167
> --longitude -74.04
> GNU gdb (Debian 13.1-3) 13.1
> Copyright (C) 2023 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "powerpc64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
>  .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./bin/latLngToCell...
> (gdb) run
> Starting program: /home/bencz/h3/build/bin/latLngToCell --resolution 10
> --latitude 40.689167 --longitude -74.04
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/powerpc64-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGILL, Illegal instruction.
> __cos (x=0.7101599340438236) at ../sysdeps/ieee754/dbl-64/s_sin.c:272
> 272 ../sysdeps/ieee754/dbl-64/s_sin.c: No such file or directory.
> (gdb) bt full
> #0  __cos (x=0.7101599340438236) at ../sysdeps/ieee754/dbl-64/s_sin.c:272
>  y = 
>  a = 6.9533558075373792e-310
>  da = 6.953355807549632e-310
>  u = 
>  k = 
>  m = 
>  n = 
>  retval = 0
>  ctx = 
> #1  0x000100013554 in _geoToVec3d (geo=0x7fffeb80,
> v=0x7fffe878) at /home/bencz/h3/src/h3lib/lib/vec3d.c:51
>  r = 0
> #2  0x0001bdc4 in _geoToClosestFace (g=0x7fffeb80,
> face=0x7fffeac8, sqd=0x7fffe970) at
> /home/bencz/h3/src/h3lib/lib/faceijk.c:938
>  v3d = {x = 2.1995190125098354e-106, y =
> 6.9533491603584174e-310, z = 0}
> #3  0x0001bb44 in _geoToHex2d (g=0x7fffeb80, res=10,
> face=0x7fffeac8, v=0x7fffea20) at
> /home/bencz/h3/src/h3lib/lib/faceijk.c:392
>  sqd = 0
>  r = 0
>  theta = 0
> #4  0x0001bacc in _geoToFaceIjk (g=0x7fffeb80, res=10,
> h=0x7fffeac8) at /home/bencz/h3/src/h3lib/lib/faceijk.c:374
>  v = {x = 0, y = 0}
> #5  0x0001825c in latLngToCell (g=0x7fffeb80, res=10,
> out=0x7fffeb78) at /home/bencz/h3/src/h3lib/lib/h3Index.c:784
>  fijk = {face = 32767, coord = {i = -5424, j = 32767, k = -5200}}
> #6  0x00014428 in doCoords (lat=40.6891668,
> lng=-74.039, res=10) at
> /home/bencz/h3/src/apps/filters/latLngToCell.c:51
>  g = {lat = 0.7101599340438236, lng = -1.2923193406085602}
>  h = 4295059370
>  e = 0
> #7  0x00014704 in main (argc=7, argv=0x7328) at
> /home/bencz/h3/src/apps/filters/latLngToCell.c:102
>  res = 10
>  lat = 40.6891668
>  lng = -74.039
>  helpArg = {names = {0x1000166b8 "-h", 0x1000166bb "--help"},
> required = false, scanFormat = 0x0, valueName = 0x0, value = 0x0, found
> = false, helpText = 0x1000166c2 "Show this help message."}
>  resArg = {names = {0x1000166da "-r", 0x1000166dd
> "--resolution"}, required = true, scanFormat = 0x1000166ea "%d",
> valueName = 0x1000166ed "res", value = 0x7fffee74, found = true,
> helpText = 0x1000166f1 "Resolution, 0-15 inclusive."}
>  latArg = {names = {0x10001670d "--lat", 0x100016713
> "--latitude"}, required = false, scanFormat = 0x10001682b "%lf",
> valueName = 0x10001670f "lat", value = 0x7fffee68, found = true,
>helpText = 0x10001671e "Latitude in degrees. If not
> specified, \"latitude longitude\" pairs will be read from standard input."}
>  lngArg = {names = {0x100016782 "--lng", 0x100016788
> "--longitude"}, required = false, scanFormat = 0x10001682b "%lf",
> valueName = 0x100016784 "lng", value = 0x7fffee60, found = true,
> helpText = 0x100016794 "Longitude in degrees."}
>  args = {0x7fffee20, 0x7fffede0, 0x7fffeda0,
> 0x7fffed60}
>  numArgs = 4
>  helpText = 0x1000167aa "Convert degrees latitude/longitude
> coordinates to H3 indexes."
>
>
> When I execute the command layout asm, it shows this line:
>
>  > 0x77ed8fec <__cos+28>mffscrni f0,0

mffscrni is POWER9.

Maybe https://www.mail-archive.com/qemu-devel@nongnu.org/msg959063.html
is related?

Jeff

Re: Installer doesn't find the mirrors

[Jeffrey Walton]

On Sun, Apr 9, 2023 at 6:38 PM Ken Cunningham
 wrote:
>
> Your issue is in French, but it looks like the one I recently faced as well 
> if I am reading it correctly.
>
> I fixed it using the information on this page:
>
> https://unix.stackexchange.com/questions/75807/no-public-key-available-on-apt-get-update

Ugh, Debian has chronic problems in key management for ports. I've got
half a dozen to a dozen Chroot's for testing that have been broken for
months.

I really wish they would fix them and stop this madness.

Jeff

Fwd: Hoping to donate/sell a Talos II motherboard

[Jeffrey Walton]

FYI...

-- Forwarded message -
From: Jeffrey Walton 
Date: Tue, Feb 28, 2023 at 8:03 PM
Subject: Re: Hoping to donate/sell a Talos II motherboard
To: 
Cc: , ,
, 

On Tue, Feb 28, 2023 at 7:46 PM  wrote:
>
> My friend has a spare Talos II motherboard that is currently sitting in his 
> house
> in Indiana USA collecting dust.
>
> https://www.raptorcs.com/TALOSII/
>
> I have convinced him to donate/sell it to an open source project or developer.
>
> I reached out to Richard Stallman, and he agreed to take the board.  I am 
> certain that the
> FSF would put it to good use.  My friend and I have not yet decided, to whom 
> we will give
> the motherboard.  Is it possible that I could give it to someone or project, 
> such that all
> parties here would benefit?
>
> Is there any project or developer here that would be willing to take this 
> motherboard and create
> virtual machines that other projects could have access to?
>
> Thoughts?

I trimmed some of the non-relevant lists.

The Talos workstations are PowerPC based. There are users on
debian-powerpc who would put it to good use.
https://lists.debian.org/debian-powerpc/ .

And I am envious of your friend. I've got a Talos on my wishlist for a
daily driver.

Jeff

Fwd: new archive section: non-free-firmware

[Jeffrey Walton]

FYI...

-- Forwarded message -
From: Sven Joachim 
Date: Sat, Jan 28, 2023 at 12:09 PM
Subject: new archive section: non-free-firmware
To: 

Some news for you who are running unstable or testing/bookworm and have
firmware packages installed from non-free (most users who do not run
Debian in a VM probably have): these firmware packages are being moved
to a new section non-free-firmware, and you should update your
sources.list(5) entries to include that section to keep them up to date.

In unstable this is already happening, and aptitude just informed me
that two installed firmware-* packages have become obsolete, i.e. are no
longer available from non-free.  In bookworm, non-free-firmware is
currently still empty, but that will change in the coming days and weeks.

To use the new section, edit sources.list like this:

before:
deb http://deb.debian.org/debian/ unstable main contrib non-free

after:
deb http://deb.debian.org/debian/ unstable main contrib non-free
non-free-firmware

and similar for testing or bookworm instead of unstable.

If you have aptitude installed[1], the following command gives you a
list of installed packages from non-free:

$ aptitude search -F %p --disable-columns '~i~snon-free

If that list only includes packages matching "firmware", you can remove
non-free from your sources.list once the transition of firmware packages
to the new section is complete.

For more information why this was done, read
https://www.debian.org/vote/2022/vote_003.

Cheers,
   Sven


1. If somebody knows a similar command in apt, please post it.

Re: [PATCH 2/3] drmgr/common_pci: Prefer strlen() to check for valid string length

[Jeffrey Walton]

Hi Adrian,

On Mon, Dec 26, 2022 at 4:55 AM John Paul Adrian Glaubitz
 wrote:
>
> This fixes the following warning when building with gcc-12 that is
> the result of ofdt_path being a fixed-sized array which means that
> (char *)ofdt_path never be NULL:
>
> src/drmgr/common_pci.c: In function 'devspec_check_node':
> src/drmgr/common_pci.c:465:29: error: the comparison will always evaluate as 
> 'false' for the address of 'ofdt_path' will never be NULL [-Werror=address]
>   465 | if (node->ofdt_path == NULL)
>   | ^~
> In file included from src/drmgr/drpci.h:25,
>  from src/drmgr/rtas_calls.h:25,
>  from src/drmgr/dr.h:30,
>  from src/drmgr/common_pci.c:31:
> src/drmgr/ofdt.h:78:25: note: 'ofdt_path' declared here
>78 | charofdt_path[DR_PATH_MAX];
>   |
>
> Signed-off-by: John Paul Adrian Glaubitz 
> ---
>  src/drmgr/common_pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/drmgr/common_pci.c b/src/drmgr/common_pci.c
> index cbd48c9..c6dcfdf 100644
> --- a/src/drmgr/common_pci.c
> +++ b/src/drmgr/common_pci.c
> @@ -462,7 +462,7 @@ devspec_check_node(struct dr_node *node, char *sysfs_path,
>
> *found = 0;
>
> -   if (node->ofdt_path == NULL)
> +   if (!strlen(node->ofdt_path))
> return 0;
>
> if (! strcmp(full_of_path, node->ofdt_path)) {
> --
> 2.30.2

Do you need strlen? It looks like you only care that the path is
non-empty. You may be able to save on the call to strlen, and instead,
check the first char of the string. So maybe something like:

> -   if (node->ofdt_path == NULL)
> +   if (! node->ofdt_path[0])
> return 0;

My apologies if I am mis-parsing things.

Jeff

Need for manual link to libatomic on powerpc?

[Jeffrey Walton]

Hi Everyone,

I'm trying to track down a Crypto++ 8/GCC 12 bug at [1,2]. Our Debian
maintainer, who is helping with testing, mentioned we were missing
libatomic during link when using santiziers on powerpc and hppa.[3,4]
That kind of caught me off-guard.

On Fedora (but not Debian in the past), we needed to install gcc, g++,
libasan, libubsan and friends. Libraries for Asan and Ubsan are
separate installs on Fedora (but not Debian). However, once installed,
the compiler driver added the necessary libs (like libubsan and
libatomic) when it encountered an option like -fsanitize=undefined.

My question is, are libasan, libubsan and friends a separate install
for Debian on powerpc and hppa?

If not, does anyone know why libatomic might not be added by the
compiler driver when needed on Debian powerpc?

Thanks in advance.

[1] https://github.com/weidai11/cryptopp/issues/1134
[2] https://github.com/weidai11/cryptopp/issues/1141
[3] https://github.com/weidai11/cryptopp/issues/1141#issuecomment-1224051475
[4] https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B=sid

Re: missing rebuild of dovecote-imapd-dbgsym?

[Jeffrey Walton]

On Tue, Aug 23, 2022 at 4:04 AM Simon Josefsson  wrote:
>
> Paul Wise  writes:
>
> > On Mon, 2022-08-22 at 07:10 +0200, Simon Josefsson wrote:
> >
> >> Are debug symbols on powerpc for the recent dovecot security advisory
> >> missing, or am I doing something wrong?
> > ...
> >>  dovecot-imapd-dbgsym : Depends: dovecot-imapd (= 
> >> 1:2.3.13+dfsg1-2+deb11u1) but 1:2.3.13+dfsg1-2 is to be installed
> >
> > As far as I know powerpc isn't supported for Debian stable nor the
> > Debian security updates archive.
>
> Interesting -- where can I read about that?  The release notes says that
> ppc64el is an officially supported architecture for Debian 11:
>
> https://www.debian.org/releases/bullseye/ppc64el/release-notes/ch-whats-new.en.html#idm120

ppc64el is listed as an official port at https://www.debian.org/ports/
. But that page has never been quite accurate .

For example, amd64 and arm64 are listed as official ports but they are
not a port per se. You use http://ftp.debian.org/debian and
debian-archive-keyring. You do not use something port-ified, like
http://ftp.ports.debian.org/debian-ports and
debian-ports-archive-keyring.gpg .

Jeff

Re: Apple PowerPC G5 7,2 No GUI NVIDIA FX 5200

[Jeffrey Walton]

On Mon, May 23, 2022 at 1:31 PM  wrote:
>
>  ...
> There was an official Apple Radeon X1900 G5 edition which was PCIe.
> I've also read that people have used a Windows PC to flash Mac
> firmware onto a PC X1950 PCIe card and this card may be more easily
> available/cheaper.
>
> If the OPs machine is PCI-X there are more X1900 options but I've no
> idea how well the Radeon cards work with Linux.

Based on my experience with my G5, I was able to use a non-Apple
Raedon card and things worked fine. I did not need to flash ROMs or
jump through other hoops.

For completeness, I picked up a Radeon X1900 GT from eBay. I took out
the existing NVIDIA card and installed the Raedon card. Upon boot I
had a UI.

Jeff

Re: Apple PowerPC G5 7,2 No GUI NVIDIA FX 5200

[Jeffrey Walton]

On Fri, May 20, 2022 at 3:54 PM Guido R. Rolón A.  wrote:
>
> Hi all this is my first time here and my first time with an Apple Machine
>
> My setup is a
> Apple PowerMac7,2 5.1.5f2 BootROM built on 09/21/04 at 11:58:53
> 5.1.5 - Power Macintosh G5 (Omega, June 2003)
> Model No.: A1047 EMC No.: 1969
> Serial NO: YM337XX
> Ethernet ID: 000A9597FAE2
> CPU 1.6GYHZ 970
> RAM 4096MB 333
> DISK 160GB HD
> DVD-R/CDRW
> NVIDIA GF5200 Ultra
> 56K Modem
>
> I have managed to install Debian Linux 11 
> (debian-11.0.0-ppc64-NETINST-1.iso), CD-ROM Install
> With no errors during installation.
> First problem, blank screen after first boot,
> Access with ssh to this machine and edited /etc/default/grub
> GRUB_CMDLINE_LINUX_DEFAULT="text quiet nomodeset"
> Then
> update-grub2
> and finally
> reboot
> i can access console, text mode
> NO GUI,
>
> Tried X -configure
> and
> X,
> No screen detected

This may help: https://wiki.debian.org/NvidiaGraphicsDrivers

When I had problems with the NVIDIA card, I took the NVIDIA card out,
and installed a Radeon card instead.

Jeff

Re: netinst ppc64 2022-03-24 fails to install GRUB boot loader

[Jeffrey Walton]

On Sun, Mar 27, 2022 at 6:15 PM Dennis Clarke  wrote:
>
>
> I just the normal process of booting the netinst DVD image and used
> the default NOT-expert menu option. I see the usual message :
>
> Unable to install GRUB in /dev/sda3
>  Executing 'grub-install /dev/sda3' failed.
>
>  This is a fatal error.
>
> I used netcat to fetch the syslog and partman files from /var/log
> and attach them here.
>
> Looks like the HFS boot partition was never formatted :
>
> Mar 27 21:57:35 grub-installer: info: Installing grub on '/dev/sda3'
> Mar 27 21:57:35 grub-installer: info: grub-install does not support
> --no-floppy
> Mar 27 21:57:35 grub-installer: info: Running chroot /target
> grub-install  --macppc-directory=/boot/grub --no-nvram --force
> Mar 27 21:57:35 grub-installer: Installing for powerpc-ieee1275 platform.
> Mar 27 21:57:36 grub-installer: grub-install: error: filesystem on
> /boot/grub is neither HFS nor HFS+.
> Mar 27 21:57:36 grub-installer: error: Running 'grub-install
> --macppc-directory=/boot/grub --no-nvram --force failed.
> .
> .
> .
> Mar 27 21:59:13 main-mMar 27 21:57:35 grub-installer: info: Installing
> grub on '/dev/sda3'
> Mar 27 21:57:35 grub-installer: info: grub-install does not support
> --no-floppy
> Mar 27 21:57:35 grub-installer: info: Running chroot /target
> grub-install  --macppc-directory=/boot/grub --no-nvram --force
> Mar 27 21:57:35 grub-installer: Installing for powerpc-ieee1275 platform.
> Mar 27 21:57:36 grub-installer: grub-install: error: filesystem on
> /boot/grub is neither HFS nor HFS+.
> Mar 27 21:57:36 grub-installer: error: Running 'grub-install
> --macppc-directory=/boot/grub -Mar 27 21:57:35 grub-installer: info:
> Installing grub on '/dev/sda3'
> Mar 27 21:57:35 grub-installer: info: grub-install does not support
> --no-floppy
> Mar 27 21:57:35 grub-installer: info: Running chroot /target
> grub-install  --macppc-directory=/boot/grub --no-nvram --force
> Mar 27 21:57:35 grub-installer: Installing for powerpc-ieee1275 platform.
> Mar 27 21:57:36 grub-installer: grub-install: error: filesystem on
> /boot/grub is neither HFS nor HFS+.
> Mar 27 21:57:36 grub-installer: error: Running 'grub-install
> --macppc-directory=/boot/grub --no-nvram --force failed.
> .
> .
> .
> Mar 27 21:57:35 grub-installer: info: grub-install does not support
> --no-floppy
> Mar 27 21:57:35 grub-installer: info: Running chroot /target
> grub-install  --macppc-directory=/boot/grub --no-nvram --force
> Mar 27 21:57:35 grub-installer: Installing for powerpc-ieee1275 platform.
> Mar 27 21:57:36 grub-installer: grub-install: error: filesystem on
> /boot/grub is neither HFS nor HFS+.
> Mar 27 21:57:36 grub-installer: error: Running 'grub-install
> --macppc-directory=/boot/grub --no-nvram --force failed.
> .
> .
> .
> Mar 27 21:59:13 main-menu[292]: (process:646):   Volume group "sda" not
> found
> Mar 27 21:59:13 main-menu[292]: (process:646):   Cannot process volume
> group sda
> Mar 27 21:59:13 main-menu[292]: (process:646): dpkg-divert: warning:
> diverting file '/sbin/start-stop-daemon' from an Essential package with
> rename is dangerous, use --no-rename
> Mar 27 21:59:13 main-menu[292]: (process:646): dpkg-divert: warning:
> diverting file '/sbin/start-stop-daemon' from an Essential package with
> rename is dangerous, use --no-rename
> Mar 27 21:59:13 main-menu[292]: WARNING **: Configuring 'grub-installer'
> failed with error code 1
> Mar 27 21:59:13 main-menu[292]: WARNING **: Menu item 'grub-installer'
> failed.
> se --no-rename
>
> Not sure what to make of that.

https://www.youtube.com/watch?v=g-Ugfqj1ank

Use the 32-bit version of grubfix32.sh, even on the 64-bit install.
Use /dev/sda2 instead of /dev/sda3 when fixing grub.

Jeff

Re: yaboot installation media

[Jeffrey Walton]

On Sun, Mar 27, 2022 at 4:15 PM Sam Imberman  wrote:
>
> Hi,
> I'm actually having more or less the same problem with my Powerbook G4 
> Aluminum.
> I am using the image from 
> https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-18/non-free/ , 
> which I burnt on a USB stick with "dd 
> if=./debian-11.0.0-powerpc-NETINST-1.iso of=/dev/sdg bs=1M"
> When I boot the machine while holding "option", the USB stick is not found.

I don't know about the G4's, but I know about the G5's. You cannot
boot a G5 from USB. You have to burn a CD and boot from the CD.

Jeff

Re: yaboot installation media

[Jeffrey Walton]

On Thu, Mar 24, 2022 at 8:28 PM Ben Westover
> We're using grub-ieee1275, IEEE-1275 being the specification for Open
> Firmware. There is no issue getting GRUB to run on my G3, and most
> others are having success on their machines, but my G4 just refuses to
> recognize GRUB in any way, only yaboot.

It's kind of odd that things are working for you on G3's, and others
have things working on G5's.

Maybe you should try to reset the nvram? From the OF prompt, I believe
the commands are reset-nvram and reset-all.

Jeff

Re: Updated Debian Ports installation images

[Jeffrey Walton]

On Sun, Mar 20, 2022 at 12:55 PM John Paul Adrian Glaubitz
 wrote:
>
> > On Mar 20, 2022, at 5:01 PM, Jeffrey Walton  wrote:
> >
> > On Sun, Mar 20, 2022 at 11:40 AM Ken Cunningham
> >  wrote:
>
> > If the webmaster would provide the actual instructions (or the ISO
> > README would provide it), then we could perform an install.
>
> Haven’t you posted to this list before and used the Debian Ports images in 
> the past or am I confusing you with someone else?

Yes. I offered to write the documentation. I need someone to provide
the procedure.

> Anyway, the documentation is outdated when you use the Debian Ports ISO 
> images.

Yeah, the Debian Ports have a lot of problems.

Debian webmasters leave a lot to be desired.

Jeff

Re: Updated Debian Ports installation images

[Jeffrey Walton]

On Sun, Mar 20, 2022 at 11:40 AM Ken Cunningham
 wrote:
>
> Jeff, the debian installation process moved to GRUB a while back.
>
> I still think the monthly install/setup FAQ would be a good plan, by the way. 
>  There was a flurry of interest for a short while.

Yeah, maybe this should be pushed on the Debian webmasters.

https://www.debian.org/ports/powerpc/inst/install doesn't provide
instructions but says to use a NewWorldMac. Clicking the NewWorldMac
link takes us to https://www.debian.org/ports/powerpc/inst/pmac. There
are no instructions but there is a link that says "please study the
fine Installation Manual." Clicking the link results in Page Not
Found.

If the webmaster would provide the actual instructions (or the ISO
README would provide it), then we could perform an install.

Jeff

Re: Updated Debian Ports installation images

[Jeffrey Walton]

On Sun, Mar 20, 2022 at 9:07 AM John Paul Adrian Glaubitz
 wrote:
>
>
>
> > On Mar 20, 2022, at 1:53 PM, Jeffrey Walton  wrote:
> >
> > Unfortunately, we still can't boot a PowerMac. Yaboot does load, but
> > it results in Unknown or corrupt filesystem.
>
> I do not quite understand the connection to Yaboot. The current images use 
> GRUB, both for booting the installer and the installed system.
>
> Yaboot is unmaintained upstream, so it’s unlikely it will be able to work 
> with modern ext4 systems in the foreseeable future.
>
> If you insist on using Yaboot, you will have to use ext2 or ext3.

I don't insist on it. The instructions tell us to use it. The only
instructions I am aware of is the one where we do 'boot
cd:,/install/yaboot'.

If the instructions have changed, can you please tell us where the
updated instructions are located?

The README on the ISO has an Installing section, but there are no instructions.

Jeff

Re: Updated Debian Ports installation images

[Jeffrey Walton]

On Fri, Mar 18, 2022 at 1:59 PM John Paul Adrian Glaubitz
 wrote:
>
> I have created the first set of installation images in 2022, these are
> available at the usual location in [1].
>
> The ISO image for sparc64 has been verified to work correctly, I don't
> know about the other architectures, however.
>
> I have also created the first images which include non-free firmware packages
> but these are completely untested and firmware installation might not work
> correctly as DEP-11 information is not available on the Debian Ports mirrors.
>
> The non-free images can be found here [2].

Unfortunately, we still can't boot a PowerMac. Yaboot does load, but
it results in Unknown or corrupt filesystem.

Thanks for the try.

Jeff

Re: Updated Debian Ports installation images

[Jeffrey Walton]

On Fri, Mar 18, 2022 at 1:59 PM John Paul Adrian Glaubitz
 wrote:
>
> I have created the first set of installation images in 2022, these are
> available at the usual location in [1].
>
> The ISO image for sparc64 has been verified to work correctly, I don't
> know about the other architectures, however.
>
> I have also created the first images which include non-free firmware packages
> but these are completely untested and firmware installation might not work
> correctly as DEP-11 information is not available on the Debian Ports mirrors.
>
> The non-free images can be found here [2].

Hi Adrian.

Forgive my ignorance. Wget requests testing of a patch on a 32-bit
big-endian machine.

Can a PowerMac G5 run a 32-bit image? Are they like Intel x86_64?

Jeff

Re: Request for a once-montly PowerPC for Apple Systems FAQ?

[Jeffrey Walton]

On Mon, Jan 31, 2022 at 11:09 AM Ken Cunningham
 wrote:
>
> Thanks.
>
> I’m in great shape, everything running fairly well on my machines.
>
> But most people have no idea even what boot iso to use, it seems, from the 
> 1,200 questions over and over and over about it on the Linux on PowerPC Macs 
> facebook group (and the 1,199 wrong answers :> ).
>
> Perhaps someone with writing skills and interest might be interested, in time.

I'd be happy to help with writing. I enjoy writing docs for some reason.

I think the problem is, Debian does not have a good strategy for
dissemination of long term information for PowerPC. They have a wiki
but there's little information about PowerPC. Instead, Debian places
the long term information on static web pages that are woefully out of
date. No one can edit the web pages except Debian admins, and they
don't do it. (I tried to get them to update it a couple of years ago.
It went nowhere).

A FAQ might be a good first step to triage the problem.

But as Adrian points out, the people with the access and the knowledge
don't have time to tend to it. That problem begs a crowd source
solution like a wiki. But then we are back to the problem of using
static web pages instead of a wiki.

Information management is hard.

Jeff

Re: Bug#1003847: binutils breaks glibc autopkgtest on ppc64el: unrecognized opcode: `vspltisb' (and others)

[Jeffrey Walton]

On Wed, Jan 19, 2022 at 4:08 PM John Paul Adrian Glaubitz
 wrote:
>
> Unfortunately, glibc no longer builds with this change on powerpc and ppc64
> and kernel builds still fails on both targets:
>
> > https://buildd.debian.org/status/fetch.php?pkg=glibc=powerpc=2.33-3=1642542048=0
> > https://buildd.debian.org/status/fetch.php?pkg=glibc=ppc64=2.33-3=1642542055=0
>
> > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=5.15.15-1=1642579068=0
> > https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64=5.15.15-1=1642578946=0

This seems to be related to the ones stamped 1642542048 and 1642542055
(the first two):
https://patchwork.sourceware.org/project/glibc/patch/20210925202746.819385-1...@us.ibm.com/

Re: LLVM Linker

[Jeffrey Walton]

On Sat, Oct 16, 2021 at 4:43 PM John Paul Adrian Glaubitz
 wrote:
>
> On 10/16/21 16:09, Elimar Riesebieter wrote:
> > does somebody knows why lld isn't available for powerpc?
>
> It's not available because we're currently not building LLVM for powerpc and
> ppc64, see:

According to https://lld.llvm.org, PowerPC and PowerPC64 are supported arches:

It supports various CPUs/ABIs including AArch64, AMDGPU, ARM, Hexagon,
MIPS 32/64 big/little-endian, PowerPC, PowerPC64, RISC-V, SPARC V9,
x86-32 and x86-64. Among these, AArch64, ARM (>= v6), PowerPC,
PowerPC64, x86-32 and x86-64 have production quality. MIPS seems
decent too.

It may be time to give lld a whirl.

libcxx and libcxxabi may be a different story, however.

Jeff

Re: LLVM Linker

[Jeffrey Walton]

> > If you want to use a different linker, then set the variable LD to that 
> > linker.
>
> I believe this is what LLVM=1 does. Start a compile with LVM=1 set
> ld.lld, which is part of ldd package, isn't found.

You might try -fuse-ld=lld. From https://lld.llvm.org/:

If you don’t want to change the system setting,
you can use clang’s -fuse-ld option. In this way,
you want to set -fuse-ld=lld to LDFLAGS when
building your programs.

Jeff

Re: LLVM Linker

[Jeffrey Walton]

On Sat, Oct 16, 2021 at 10:16 AM Elimar Riesebieter  wrote:
>
> does somebody knows why lld isn't available for powerpc?

I don't have an answer to this. Maybe the LLVM folks have not provided
it? Maybe it is available, but not on-path?

(LLVM has some sharp edges on PowerPC. I ran into a fair amount of
trouble in the past, when I was building LLVM/Compiler-Rt/libc++ for
PPC).

> compile a kernel with
> 'make LLVM=1 HOSTCC=/usr/bin/clang-13 HOSTCXX=/usr/bin/clang++-13 
> CC=/usr/bin/clang-13'
> where LLVM=1 points to the llvm linker. Without LLVM-1 it seems to use the 
> binutils.

I believe it depends on the builtin makefile rules and what the author
of the makefile is doing.

You can check the builtin makefile rules with '-p' option:

$ make -p | grep -E 'LD|LINK'
...
LINK.m = $(OBJC) $(OBJCFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)
LINK.p = $(PC) $(PFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LD = ld
LINK.r = $(FC) $(FFLAGS) $(RFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.C = $(LINK.cc)
LINK.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_MACH)
LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.s = $(CC) $(ASFLAGS) $(LDFLAGS) $(TARGET_MACH)
LINK.cpp = $(LINK.cc)
...

If you want to use a different linker, then set the variable LD to that linker.

Jeff

Re: Poll: Is anyone using nouveau driver on ppc64 system?

[Jeffrey Walton]

On Thu, Oct 7, 2021 at 5:41 PM Tom Grzybowski  wrote:
>
> I have a related question:  instead of us breaking what is working by 
> updating the kernel regularly, why don't we find a good working kernel 
> version and move on only when we can match that in terms of functionality?   
> Is there some "requirement" to always feature the latest kernel?

Regarding the "find a good working kernel", it may be a good idea to
invest in a LTS kernel. Currently that is 5.4 and 5.10. 5.4 is
supported until December 2025, 5.10 is supported until December 2026.

Jeff

Re: GRUB installation fails on latest ISO

[Jeffrey Walton]

On Sun, Sep 19, 2021 at 3:45 AM John Paul Adrian Glaubitz
 wrote:
>
> On 9/19/21 03:11, Jeffrey Walton wrote:
> > Have you considered running a repo with the fixes that Debian does not
> > pick up or provide in a timely manner?
>
> We already do that and we have been doing this for a long time.
> ...
> > Adding a repo to sources.list or apt.conf.d is really easy. Once a
> > user is aware they need to do it, there should be no more problems due
> > to packages and availability.
>
> This discussion is concerned about udeb packages for debian-installer. You
> can add these packages through a repository to your system.

Oh, my bad. I was not aware this was the current state of affairs.

It is not documented at https://www.debian.org/ports/powerpc/,
https://www.debian.org/releases/stable/ppc64el/,
https://www.debian.org/ports/powerpc/inst/pmac, etc.

Maybe it would be a good idea to clearly state it somewhere. A
prescriptive recipe would be most helpful. A prescriptive recipe
provides the exact steps someone should perform.

Jeff

Re: GRUB installation fails on latest ISO

[Jeffrey Walton]

On Sat, Sep 18, 2021 at 6:54 PM John Paul Adrian Glaubitz
 wrote:
>
> On 9/19/21 00:24, Alex McKeever wrote:
> > I just tried installing the latest version of Debian Ports on my iMac G3
> > and well it fails to install GRUB. Falling back to April’s installation
> > media (which I have on hand) that doesn’t have this problem that has 
> > seemingly
> > cropped up again with the latest batch of images.
>
> Yes, that image doesn't work. The previous image does work, however.
>
> The reason why the current image doesn't work is because it does not contain a
> manually build debian-installer package which is currently necessary because
> the hfsprogs-udeb [1] package has not been accepted into unstable yet.
>
> So, please use the powerpc and ppc64 images from [2].
>
> > [1] https://ftp-master.debian.org/new/hfsprogs_540.1.linux3-5.html
> > [2] https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/

Have you considered running a repo with the fixes that Debian does not
pick up or provide in a timely manner?

There's little sense waiting for Debian since Debian is the barrier in
the process. If Debian did not want to be a barrier, then they would
have done something by now. It probably won't change anytime soon.

A repo run by you to work around Debian's issues seems like a perfect
fix. You are active in the development and you are aware of the open
issues that need to be worked around.

A repo run by you would probably reduce mailing list messages since
things would start to "just work", which is what most users want.

Adding a repo to sources.list or apt.conf.d is really easy. Once a
user is aware they need to do it, there should be no more problems due
to packages and availability.

Jeff

Re: Altivec in baseline for ppc64?

[Jeffrey Walton]

> On Fri, Jul 16, 2021 at 12:09 PM John Paul Adrian Glaubitz
>  wrote:
> >
> > On 7/16/21 12:59 PM, Jeffrey Walton wrote:
> > > Does it have to be one or the other? Can't you have both?
> >
> > Well, you could have runtime detection like certain multimedia codes and 
> > OpenSSL use but
> > most packages don't do that.
>
> this is the "sane" way to do it.  unfortunately, the EABIv2, which
> *explicitly* states, "SIMD is mandatory" is resulting in an inexorable
> creep of submissions from IBM developers (to libc6 and other
> libraries)

I never really took notice that IBM captured the projects. But with
your lens it sounds about right.

("Captured", as in regulatory capture as seen in the US. Regulatory
capture is where private industry gets so cozy with government and
regulators that industry writes their own rules and gov is just an
extension of a few dominant players).

> with Quad and 8 1.5+ ghz on the roadmap over the next 3 years,
> Libre-SOC's processor is *not* intended for just "embedded" uses.
> we've simply made it abundantly clear that Hell Will Freeze Over
> before we add a suicidal *700* SIMD instructions to what is supposed
> to be a RISC design.

Forgive my ignorance... Once traces of companies like NXP and IBM are
removed, and Altivec is removed, what is left? Are some pieces of the
ISA going to be (re)used? Or is the ISA being built from scratch? Is
it even PowerPC anymore? Is it just a RISC machine?

(PowerPC scatter/gather is quite lame, even in the latest ISA 3.0B, so
I'm not sure there's much good stuff to reuse).

Anyway, I'm excited to see a SIMD alternative that could become
mainstream. I really look forward to the new hardware making it to
market.

Jeff

Re: Altivec in baseline for ppc64?

[Jeffrey Walton]

On Fri, Jul 16, 2021 at 2:59 AM John Paul Adrian Glaubitz
 wrote:
>
> On 7/15/21 5:49 PM, Christian Zigotzky wrote:
> > I disagree too because the performance of software with AltiVec support 
> > isn't as
> > high as expected. I tested it a lot because we have AltiVec and Non-Altivec 
> > machines
> > here. We changed to Non-AltiVec compiled software a while ago.
>
> It depends on the workload, of course. Anything that does SIMD like matrix 
> multiplications
> in multimedia or scientific computing will, of course, profit from enabling 
> AltiVec.
>
> No one claimed that AltiVec, MMX or SSE will just improve everything.

+1

I've found a few algorithms that were profitable on ARM and x86, but
not profitable with Altivec. The LEA algorithm comes to mind:
https://github.com/weidai11/cryptopp/blob/master/lea_simd.cpp#L46.
Altivec runs about 5x slower than C++.

> > We and the MintPPC team had some problems with the VLC media player on our 
> > Non-AltiVec
> > machines a year ago because it is only available in an AltiVec version.
> > The MintPPC team had to recompile it. [1]
> > We also had to recompile the version 3.0.12 of VLC because of the AltiVec 
> > dependency again. [2]
>
> I would argue that there are far more users with PowerMacs which all support 
> AltiVecs than
> with obscure embedded machines. As I said, some packages like nss2 already 
> enabled AltiVec
> by default.

Does it have to be one or the other? Can't you have both?

Jeff

Re: Altivec in baseline for ppc64?

[Jeffrey Walton]

On Tue, Jul 13, 2021 at 2:20 PM Sébastien Villemot  wrote:
>
> Le mardi 13 juillet 2021 à 20:06 +0200, Mathieu Malaterre a écrit :
> > On Tue, Jul 13, 2021 at 7:21 PM Sébastien Villemot  
> > wrote:
> > > Le mardi 13 juillet 2021 à 18:56 +0200, Mathieu Malaterre a écrit :
> > > >
> > > > On Tue, Jul 13, 2021 at 2:04 PM Sébastien Villemot 
> > > >  wrote:
> > > > >
> > > > > The wiki page that synthesizes architecture specificities indicates
> > > > > that Altivec is included in the baseline for the ppc64 port:
> > > > > https://wiki.debian.org/ArchitectureSpecificsMemo#ppc64
> > > > >
> > > > > However my understanding is that this port supports any powerpc64 CPU,
> > > > > including some that don’t have Altivec (e.g. POWER4 or POWER5). This 
> > > > > is
> > > > > also what the main wiki page for PPC64 says:
> > > > > https://wiki.debian.org/PPC64
> > > > >
> > > > > Can someone please clarify the situation?
> > > > >
> > > > > (I’m asking because I’m the maintainer of the openblas package, and
> > > > > knowing whether Altivec is available or not, and more generally what 
> > > > > is
> > > > > in the baseline, is essential for proper packaging).
> > > >
> > > > I do not believe that you can do much as a packager. You cannot assume
> > > > anything on the target arch. You need to do the same thing as ffmpeg
> > > > is doing for avx2/sse4 on amd64, you need to do runtime detection. So
> > > > unless upstream is doing something very clever you cannot compile blas
> > > > using any of the fancy altivec instructions :(
> > > >
> > > > The man page for ld.so mentions something about optimized libraries
> > > > (search for "/usr/lib/sse2/"), but this is currently not in use in
> > > > Debian (AFAIK).
> > >
> > > Actually OpenBLAS has its own runtime detection mechanism, which is
> > > used to select the best linear algebra kernel for the current CPU
> > > (those kernels are mainly written in assembly, and take advantage of
> > > available ISA extensions). This mechanism is used on several archs,
> > > including ppc64el (so at runtime, OpenBLAS chooses between a POWER8 and
> > > a POWER9 kernel; there is even a POWER10 kernel already available).
> > >
> > > However, I cannot enable this mechanism on ppc64 and powerpc, because
> > > the runtime detection only works for POWER6 and above, and my
> > > understanding is that for these two ports the baseline is lower. Hence
> > > on these two archs, only one kernel is included in the package binaries
> > > (currently POWER4 for ppc64 and PPCG4 for powerpc). For optimal
> > > performance, users should recompile OpenBLAS locally (as indicated in
> > > the package description and in README.Debian).
> >
> > There are plenty of people on this mailing list that could test/verify
> > that. Is there a quick way to check that your openblas package is
> > compiled correctly for ppc32 and ppc64 (like a verbose mode) ? Did you
> > do any experiment on perotto.debian.net ?
>
> perotto.debian.net is POWER8, so it’s clearly well above the baseline.
> The package runs fine there, but that does not tell anything about
> baseline violation.
>
> Verifying that the package compiled fine and passed its testsuite on
> build daemons does not give any information about baseline violation
> either, because buildds are probably above the baseline as well. FYI,
> the most recent build logs are there:
> https://buildd.debian.org/status/package.php?p=openblas=experimental
> (there is a problem with powerpc in experimental; but the version in
> sid compiled).
>
> If nobody has the relevant knowledge, then the only option is to test
> the package on the oldest possible hardware. The easiest way to test it
> is to recompile it locally (since this will exercise the testsuite).

I can provide SSH access to a PowerMac G5 with Altivec. That should
test the delineation between Altivec and PWR{5-10}.

If OpenBLAS needs to do 64-bit math, then I have the routines cribbed
away that performs 64-bit addition and subtraction using 32x4 vectors.
The routines have to handle carry/borrow themselves. My experience
with Crypto++ and algos like ChaCha20 demonstrate it is profitable.

Send over your SSH public key/authorized_keys, if interested.

Jeff

OT: Right to Repair Executive Order in US

[Jeffrey Walton]

Hi Everyone,

This just came down the pipe for folks in the US:
https://www.theverge.com/2021/7/9/22569869/biden-executive-order-right-to-repair-isps-net-neutrality.
The Executive Order squarely targets tech.

Also see Steve Lehto's analysis
https://www.youtube.com/watch?v=6qyYEvcS5-8. Lehto is a Michigan
attorney who specializes in consumer protection. He is very easy to
understand.

Jeff

OT: Huge Right to Repair Win for Consumers

[Jeffrey Walton]

Hi Everyone,

This is not as off-topic as it may seem. In the US, the FTC just
issued a report that favors consumers. The report and its
recommendations may provide a means to pierce the veil of closed
platforms, like closed-sourced firmware. It also looks like the
Magnuson-Moss Warranty Act will finally get some teeth and
enforcement.

Also see Steve Lehto's commentary at
https://www.youtube.com/watch?v=LdMzWX9p17Q . It is a really good
analysis, and you should listen to it if you have some time. (Lehto is
an attorney who specializes in auto repair and lemon laws).

I guess the next step is to see how lobbyists in the US attempt to
corrupt and influence politicians to purchase changes in legislation.

Jeff

Re: Updated installer images 2021-04-16 

[Jeffrey Walton]

On Sat, Apr 17, 2021 at 2:48 AM Rick Thomas  wrote:
>
> On Fri, Apr 16, 2021, at 5:30 AM, John Paul Adrian Glaubitz wrote:
> > On 4/16/21 1:57 PM, Johannes Brakensiek wrote:
> > > ...
> > > Ok, good to know. Then I suppose the Mac’s firmware just won’t detect it 
> > > if it’s copied to a USB stick?
> >
> > It could be that the blessing gets lost when putting it onto a USB disk.
> >
> > I verified that when burnt to a CD, the image will show up in 
> > menu with
> > an icon (which we can switch to a Debian swirl maybe later). But I
> > don't know about
> > OpenFirmware at the moment to know how to reproduce this behavior with
> > a USB stick.
>
> I vaguely remember having read somewhere that the "boot with option key" on 
> PowerPC machines does not examine USB disks for bootable partitions.  It does 
> know about Firewire disks, and ATA/SATA disks, but just not USB disks.

This is likely correct. I experienced the same issue when trying to
boot from USB.

I just burned a plain old bootable CD and things worked fine.

(In the past with the images from January or February).

Jeff

Re: [PATCH, v2] ofpathname: Move definition of SYS_PATH from l2of_vs() to l2of_scsi()

[Jeffrey Walton]

On Mon, Mar 29, 2021 at 6:42 PM Tyrel Datwyler  wrote:
>
> On 2/8/21 4:10 PM, John Paul Adrian Glaubitz wrote:
> > SYS_PATH, which is required to calculate the plug ID of a SCSI/SATA
> > host in l2of_scsi(), is actually never set in this function but in
> > l2of_vd() where it is not used at all. Thus, move the definition of
> > SYS_PATH from l2of_vd() to l2of_scsi() to fix the calculation of the
> > plug ID in l2of_scsi().
> >
> > Fixes: 3fb2c44e22 ("ofpathname: Add support for the plug ID of a SCSI/SATA 
> > host")
> > Signed-off-by: John Paul Adrian Glaubitz 
> > ---
> > v2:
> > - improve phrasing in commit message
>
> Applied to powerpc-utils/next branch.
>
> https://github.com/ibm-power-utilities/powerpc-utils/commit/67e974dbb8e4462c69c9c0e3a3b0c3a7219a2d45

Thanks Adrian and Tyrel.

I really look forward to Debian's next PowerPC image.

Jeff

Re: VLC on G5 crash : illegal instruction

[Jeffrey Walton]

On Sun, Mar 14, 2021 at 2:57 PM Riccardo Mottola
 wrote:
>
> On 3/8/21 9:49 AM, John Paul Adrian Glaubitz wrote:
> > We certainly shouldn't disable the whole JIT over a single instruction but 
> > rather
> > check whether this instruction can be guarded on older POWER systems.
> >
> > But we need to find out first which instruction triggers the SIGILL.
>
> Indeed, it crashes inside JIT, here the stacktrace:
>
> #0  0x7fffe9c5fa30 in ?? ()
> #1  0x702c406c in jit_machine_stack_exec
> (arguments=arguments@entry=0x7fffeb9a51d8,
>  executable_func=0x7fffe9c5fd00) at src/pcre2_jit_match.c:57
> #2  0x702f3a38 in pcre2_jit_match_16 (code=0x7fffec4392a0,
> subject=0x100165218,
>  length=, start_offset=,
> options=,
>  match_data=0x7fffec3cd180, mcontext=) at
> src/pcre2_jit_match.c:168
> #3  0x702f52b8 in pcre2_match_16 (code=0x7fffec4392a0,
> subject=0x100165218, length=37,
>  start_offset=0, options=0, match_data=0x7fffec3cd180,
> mcontext=0x1001782c0) at src/pcre2_match.c:6345
> #4  0x70ad0240 in ?? () from
> /usr/lib/powerpc64-linux-gnu/libQt5Core.so.5
> #5  0x70ad5a0c in ?? () from
> /usr/lib/powerpc64-linux-gnu/libQt5Core.so.5
> #6  0x70ad5ffc in .QRegularExpression::match(QString const&,
> int, QRegularExpression::MatchType,
> QFlags) const () from
> /usr/lib/powerpc64-linux-gnu/libQt5Core.so.5
> #7  0x71ee41fc in ?? () from
> /usr/lib/powerpc64-linux-gnu/libQt5Widgets.so.5
> #8  0x71ee4fec in ?? () from
> /usr/lib/powerpc64-linux-gnu/libQt5Widgets.so.5
> #9  0x71eeb6cc in ?? () from
> /usr/lib/powerpc64-linux-gnu/libQt5Widgets.so.5
> #10 0x70ce1618 in .QMetaCallEvent::placeMetaCall(QObject*) ()
> from /usr/lib/powerpc64-linux-gnu/libQt5Core.so.5
> #11 0x70ce7eec in .QObject::event(QEvent*) () from
> /usr/lib/powerpc64-linux-gnu/libQt5Core.so.5
> #12 0x71eed8d8 in .QFileSystemModel::event(QEvent*) ()
> from /usr/lib/powerpc64-linux-gnu/libQt5Widgets.so.5
> #13 0x71beb5f4 in .QApplicationPrivate::notify_helper(QObject*,
> QEvent*) ()
> from /usr/lib/powerpc64-linux-gnu/libQt5Widgets.so.5
> #14 0x71bf5c24 in .QApplication::notify(QObject*, QEvent*) ()
> from /usr/lib/powerpc64-linux-gnu/libQt5Widgets.so.5
> #15 0x70ca26bc in .QCoreApplication::notifyInternal2(QObject*,
> QEvent*) ()
> from /usr/lib/powerpc64-linux-gnu/libQt5Core.so.5
> #16 0x70ca2a54 in .QCoreApplication::sendEvent(QObject*, QEvent*) ()
> from /usr/lib/powerpc64-linux-gnu/libQt5Core.so.5
> #17 0x70ca6e64 in
> .QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
> from /usr/lib/powerpc64-linux-gnu/libQt5Core.so.5
>
> (gdb) p local_stack
> $1 = {top = 0x7fffeb9a5158 "", end = 0x7fffeb9a5158 "", start =
> 0x7fffeb99d158 "",
>min_start = 0x7fffeb99d158 ""}
>
> (gdb) p *arguments
> $3 = {stack = 0x7fffeb99d138, str = 0x100165218, begin = 0x100165218,
> end = 0x100165262,
>match_data = 0x7fffec3cd180, startchar_ptr = 0x100165218, mark_ptr =
> 0x0, callout = 0x0,
>callout_data = 0x0, offset_limit = 18446744073709551615, limit_match
> = 1000, oveccount = 2,
>options =

You probably need to go to frame 1 ('f 1' under gdb) and disassemble
('disass .' or 'disass' followed by a bunch of pages). That will show
the offending instruction.

Jeff

Re: VLC on G5 crash : illegal instruction

[Jeffrey Walton]

On Sun, Mar 7, 2021 at 2:10 PM Luke Kenneth Casson Leighton
 wrote:
>
> On Sunday, March 7, 2021, Riccardo Mottola  
> wrote:.
>>
>> the issue is most probably in libpcre2 or Qt5Core
>>
>> #0  0x7fffe9c5fa30 in ?? ()
>> #1  0x702c406c in ?? () from 
>> /usr/lib/powerpc64-linux-gnu/libpcre2-16.so.0
>
> https://vcs.pcre.org/pcre2/code/trunk/src/sljit/sljitNativePPC_common.c?revision=1268=markup
>
> *splutter* but... but... wow! that's amazing.  pcre2 contains a JIT assembly 
> compiler simply for the purposes of generating highly optimised regular 
> expression parsing.
>
> holy cow :)
>
> chances are then that an instruction was added which is assumed to exist in 
> OpenPOWER v3.0 but is not present in v2.06 (etc)
>
> a cursory scan shows no evidence of the use of VSX there.

If needed... I believe it is possible to disable PCRE2's JIT at configure time.

Jeff

Re: Donations

[Jeffrey Walton]

On Fri, Mar 5, 2021 at 5:42 AM David VANTYGHEM
 wrote:
>
> Hello,
>
> I received a first donation, thank you. Don't forgot to add your name when 
> you make a donation, or blank if you want to remain anonymous. I will send 
> the list of donors to Adrian.
>
> https://www.paypal.com/pools/c/88pAczImZt

Good news. The donations are up to €100.00. (Thanks KS).

Could you let us know if that is enough, or do you need more?

Jeff

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Jeffrey Walton]

On Mon, Mar 1, 2021 at 3:39 AM Gabriel Paubert  wrote:
>
> On Sun, Feb 28, 2021 at 11:52:12PM +, Luke Kenneth Casson Leighton wrote:
> > On Monday, March 1, 2021, Riccardo Mottola 
> > wrote:
> > ...
> > Tulio Magno Quites Machado Filho is currently working on glibc6 patches
> > which reverse these erroneous assumptions, replacing them with "#ifdef VSX"
> > thus allowing people to compile code that does not rely on SIMD.
>
> Beware that VSX is not Altivec. Altivec was called VMX by IBM and
> VSX is a superset of Altivec (IIRC).

Based on my experience with Botan and Crypto++... VSX is available
with POWER7 and -mvsx compiler option. VSX is part of POWER8 core and
does not need a compiler option.

VSX is a lot like Intel tic/toc features. VSX allows a 64-bit vector
loads and stores, but it does not provide operations on 64-bit
vectors. You have to use POWER8 to get the 64-bit add (addudm),
subtract (subudm), etc.

So a POWER7+VSX 64-bit add might look like:

typedef __vector unsigned intuint32x4_p;
typedef __vector unsigned long long uint64x2_p;

# Load 64-bit vector from uint64_t[2]
uint64x2_p a = vec_ld(...);
uint64x2_p b = vec_ld(...);

# But still perform the 32-bit add
uint64x2_p c = (uint64x2_p )VecAdd64((uint32x4_p)a, (uint32x4_p)b);

And:

uint32x4_p
VecAdd64(const uint32x4_p vec1, const uint32x4_p vec2)
{
// The carry mask selects carry's for elements 1 and 3 and sets
// remaining elements to 0. The result is then shifted so the
// carried values are added to elements 0 and 2.
#if defined(MYLIB_BIG_ENDIAN)
const uint32x4_p zero = {0, 0, 0, 0};
const uint32x4_p mask = {0, 1, 0, 1};
#else
const uint32x4_p zero = {0, 0, 0, 0};
const uint32x4_p mask = {1, 0, 1, 0};
#endif

uint32x4_p cy = vec_addc(vec1, vec2);
uint32x4_p res = vec_add(vec1, vec2);
cy = vec_and(mask, cy);
cy = vec_sld (cy, zero, 4);
return vec_add(res, cy);
}

 A POWER8 add looks as expected:

uint64x2_p
VecAdd64(const uint64x2_p vec1, const uint64x2_p vec2)
{
return vec_add(a, b);
}

Even with the crippled 64-bit add using 32-bit elements, some
algorithms, like Bernstein's ChaCha, runs about 2.5x faster than over
the scalar unit.

Jeff

Re: iMac G3 r128 - failed to load module "r128"

[Jeffrey Walton]

On Sat, Feb 27, 2021 at 7:55 AM John Paul Adrian Glaubitz
 wrote:
>
> Hello Jeffrey!
>
> On 2/27/21 1:37 PM, Jeffrey Walton wrote:
> >> If anyone knows about some particular fixes that are required for the 
> >> drivers - such
> >> as for the eMac - it would be nice if we could assemble a list of these 
> >> fixes so they
> >> can be integrated into the Debian packages later. The fixes should, of 
> >> course, get
> >> upstreamed whereever possible.
> >
> > I hit this problem about two weeks ago after installing Debian 8.1 on
> > a PowerMac G5: 
> > https://unix.stackexchange.com/questions/19722/debian-ppc-on-powermac-g5-boots-to-blank-screen.
> >
> > I did not try to troubleshoot it because I had no screen and no SSH.
> > The machine was effectively unaccessible to me. If SSH would have
> > worked out of the box, then I could have gotten in and tried some
> > things.
>
> SSH can be enabled from the installer by choosing the "SSH Server" option
> in taskel during installation.
>
> > Maybe one lesson to learn is, provide a working SSH after an
> > installation. I don't recall if the installer had a step for enabling
> > SSH.
>
> It does.

Ack, thanks.

The in does not work in practice.

> > After the Debian 8.1 problem I tried to move on to your FEB 02 2021 build.
>
> You won't be able to install on a PowerMac at the moment. I will have to fix
> GRUB installation first which I will continue to work on next week during
> my vacation.

Yeah, I'm just waiting for the next upload when you have the time.

Jeff

Re: iMac G3 r128 - failed to load module "r128"

[Jeffrey Walton]

Hi Adrian,

On Sat, Feb 27, 2021 at 6:33 AM John Paul Adrian Glaubitz
 wrote:
>
> On 5/23/20 9:52 PM, John Paul Adrian Glaubitz wrote:
> > On 5/23/20 9:48 PM, Jeroen Diederen wrote:
> >> I installed Debian Sid on an old iMac G3 500 with an ATI Rage 128 card. I 
> >> cannot
> >> get X working. In the /var/log/Xorg.0.log I can see that r128 module fails 
> >> to load.
> >> I can not find the xserver-org-video-r128 package. Can someone shed a 
> >> light ?
> >
> > The driver was removed from the package repository [1], I will re-add them 
> > soonish.
>
> Good news on this issue: Adrian Bunk has kindly stepped up and is working on 
> re-adding
> the legacy driver packages to the Debian archive [1]. So users will be able 
> to use
> X on the affected machines in the near future again.
>
> If anyone knows about some particular fixes that are required for the drivers 
> - such
> as for the eMac - it would be nice if we could assemble a list of these fixes 
> so they
> can be integrated into the Debian packages later. The fixes should, of 
> course, get
> upstreamed whereever possible.

I hit this problem about two weeks ago after installing Debian 8.1 on
a PowerMac G5: 
https://unix.stackexchange.com/questions/19722/debian-ppc-on-powermac-g5-boots-to-blank-screen.

I did not try to troubleshoot it because I had no screen and no SSH.
The machine was effectively unaccessible to me. If SSH would have
worked out of the box, then I could have gotten in and tried some
things.

Maybe one lesson to learn is, provide a working SSH after an
installation. I don't recall if the installer had a step for enabling
SSH. If it does not, then there should be an option to ensure SSH is
installed and working on the first boot (unless the user does not want
SSH).

After the Debian 8.1 problem I tried to move on to your FEB 02 2021 build.

Jeff

Re: Help with yaboot configuration

[Jeffrey Walton]

On Fri, Feb 19, 2021 at 2:12 AM Bob McGowan  wrote:
>
> Hello,
>
> I have a B G3 which I have upgraded to 1G RAM.  It also has an Adaptec
> SCSI controller I added to use with a 32G LVD SCSI disk.  It also has
> the original SCSI 9G SCSI disk on which I've been able to install OSX
> 10.4.2, initially.
>
> It has since upgraded to 10.4.11, if that is useful to know.
>
> I have booted both Ubuntu and Debian Linux from CD and installed both,
> at different times, on the 32G disk.  Currently I have Ubuntu 14.4
> installed.
>
> The problem is that the Adaptec controller is not recognized by
> OpenFirmware and so the system cannot boot directly to it.
>
> I was working with NetBSD 9 for a while and with the proper setup, I
> could load the kernel from the known 9G disk and have it set root to the
> second drive.
>
> I would like to do the same or similar with Linux but have so far not
> been able to figure out how to do this.
>
> I have probably copied more to the 9G disk than really needed but even
> so, it fails.  I have recreated the contents of /boot on the OSX disk,
> including symlinks.  I start from OF with the command:
>
>  boot  /pci@8000/pci-bridge@d/scsi@4/@0:6,/yaboot
>
> This generates an error about invalid partition type and a boot prompt.
> I then try, at yaboot's boot prompt:
>
>  /pci@8000/pci-bridge@d/scsi@4/@0:6,/boot/vmlinux root=/dev/sda3
>
> The kernel prints a bunch of normal type lines, then panics because it
> can't find the root device.  It also reports a list of partitions it can
> find.  The only disks are the ram disk (partitions 0-15) and sr0.
>
> This looks like it is missing drivers for the SCSI cards, but the CD
> kernel had no problems and I thought the kernel placed on sda3 would
> have them also.  That kernel is what I copied to the 9G disk.
>
> Any suggestions on how to do this correctly?

In case you have not seen the pages, here's Debian's page on
PowerMacs: https://www.debian.org/ports/powerpc/inst/pmac.

There may be some firmware available, but I don't know how to load it
during installation with one of the current ISOs. I ran into that
trouble last week. Also see https://wiki.debian.org/Firmware and
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/.

Jeff

Re: Some details on the bootloader installation for PowerMacs

[Jeffrey Walton]

On Sat, Feb 13, 2021 at 7:05 PM John Paul Adrian Glaubitz
 wrote:
>
> On 2/6/21 7:25 PM, John Paul Adrian Glaubitz wrote:
> > On 2/5/21 9:21 PM, John Paul Adrian Glaubitz wrote:
> >> The next step will be adding a hfsprogs-udeb package which allows the 
> >> hfsprogs
> >> package to be used directly by debian-installer. Every filesystem supported
> >> by debian-installer, i.e. that can be chosen to format a partition during 
> >> installation,
> >> has such a udeb package.
> >
> > I have a preliminary hfsprogs-udeb package now:
>
> Just uploaded that one to unstable after cleaning everything up and
> verifying it works correctly [1].
>
> > I will work on partman-hfs next.
>
> That needs a little more work but should be within the next days.

Awesome, great work.

Jeff

Move Debian PowerPC web pages to the Debian wiki

[Jeffrey Walton]

Hi Everyone/Adrian,

I'm looking at pages like https://www.debian.org/ports/powerpc/ and
https://www.debian.org/ports/powerpc/inst/pmac. I believe the pages
are under control of the Debian webmasters. I think the pages should
be moved to a wiki so the community can maintain them.

The biggest reason for a wiki-based page is community updates. New
information can be added to pages as it becomes available. The
community can add the content so maintainers don't have to spend time
writing docs.

Wiki's also have a confounding property (to me) that they converge on
the right answer over time even though experts are _not_ curating the
content. There's supposed to be an IEEE or journal paper that explains
the phenomenon, but I've never read it. (I don't know the title and I
have not been able to locate it).

Wikis provide exceptional dissemination of long term,
less-frequently-changing information due in part to search engine
indexing. Search engines provide indexing of wikis, and the indexing
is superior to other mediums, like mailing lists. Search engines
usually return wiki content as a top search result. The quality search
results reduces mailing list messages and reduces work for maintainers
since they don't have to answer [the same] questions time and time
again.

On the other hand, mailing lists are great for break/fix, like
immediate problems on installing Debian 10 on a PowerMac. As soon as a
problem is encountered it can be addressed interactively. Once the
break/fix has been resolved, new information can be added to the wiki
for long term dissemination.

The biggest detraction for webmaster-controlled content is outdated
content. It's fairly obvious the Debian webmasters are not following
threads on the PowerPC list, and they are not updating content.
Because of the outdated content, users will constantly encounter
problems and constantly generate ailing list messages.

A lot of people don't like wikis, like the Apache folks.
Unfortunately, the Apache folks who forgo wiki's don't know how to
manage information in the modern era. Wikis are great for
dissemination of long term information, like how to install Debian on
PowerPC or how to install Debian on a PowerMac.

Folks like Apache are harming their own projects because they lack
expertise in managing information and personal dislikes. Don't be like
Apache.

Jeff

Re: Workaround for installing Debian onto PowerMacs (2020-02-02 image)

[Jeffrey Walton]

On Tue, Feb 9, 2021 at 4:51 AM Jeffrey Walton  wrote:
>
> On Tue, Feb 9, 2021 at 2:41 AM John Paul Adrian Glaubitz
>  wrote:
> >
> > > On Feb 9, 2021, at 8:37 AM, Jeffrey Walton  wrote:
> > >
> > > On Tue, Feb 9, 2021 at 2:21 AM John Paul Adrian Glaubitz
> > >  wrote:
> > >>
> > >>>> On Feb 9, 2021, at 8:07 AM, Jeffrey Walton  wrote:
> > >>>
> > >>> After install the machine reboots automatically. We are not given an
> > >>> opportunity to stop the reboot.
> > >>> In fact, we are not even told a reboot
> > >>> is going to happen.
> > >>
> > >> That’s not true. The last screen does exactly that. It asks you whether 
> > >> you are ready to reboot.
> > >>
> > >>> Maybe the installer needs a step that confirms the
> > >>> reboot with a Yes/No prompt?
> > >>
> > >> It already does that.
> > >
> > > I'm probably being too pendactice from the UX point of view.
> > >
> > > (1) The last screen says a reboot is needed. The prompt is 
> > > or .
> > >
> > > (2) The last screen does not say a reboot will be performed, and does
> > > not offer a choice to not reboot.
> > >
> > > When I was faced with (1), I selected  thinking I could drop
> > > into a shell and perform the extra steps.
> > >
> > > (3) The last screen should say something like, "A reboot is required.
> > > Reboot Now?   ".
> > >
> > > If the message and prompt is changed to (3), then the message will
> > > more closely follow the existing behavior. It will improve the UX
> > > experience.
> >
> > Well, I‘m not concerned with this part of debian-installer which is 
> > maintained by multiple people.
> >
> > If you would like to get that changed, the debian-boot mailing list is your 
> > friend.
> >
> > I‘m not in charge with all of debian-installer.
>
> Thanks. The issue was raised at
> https://lists.debian.org/debian-powerpc/2021/02/msg00011.html.
>
> It looks like the debian-installer folks are getting ready to provide
> a new release of the installer
> (https://www.debian.org/devel/debian-installer/). Hopefully they will
> take the feedback and address the issue before the next release of the
> installer.

My bad, here's the URL:
https://lists.debian.org/debian-boot/2021/02/msg00109.html.

Jeff

Re: Workaround for installing Debian onto PowerMacs (2020-02-02 image)

[Jeffrey Walton]

On Tue, Feb 9, 2021 at 2:41 AM John Paul Adrian Glaubitz
 wrote:
>
> > On Feb 9, 2021, at 8:37 AM, Jeffrey Walton  wrote:
> >
> > On Tue, Feb 9, 2021 at 2:21 AM John Paul Adrian Glaubitz
> >  wrote:
> >>
> >>>> On Feb 9, 2021, at 8:07 AM, Jeffrey Walton  wrote:
> >>>
> >>> After install the machine reboots automatically. We are not given an
> >>> opportunity to stop the reboot.
> >>> In fact, we are not even told a reboot
> >>> is going to happen.
> >>
> >> That’s not true. The last screen does exactly that. It asks you whether 
> >> you are ready to reboot.
> >>
> >>> Maybe the installer needs a step that confirms the
> >>> reboot with a Yes/No prompt?
> >>
> >> It already does that.
> >
> > I'm probably being too pendactice from the UX point of view.
> >
> > (1) The last screen says a reboot is needed. The prompt is 
> > or .
> >
> > (2) The last screen does not say a reboot will be performed, and does
> > not offer a choice to not reboot.
> >
> > When I was faced with (1), I selected  thinking I could drop
> > into a shell and perform the extra steps.
> >
> > (3) The last screen should say something like, "A reboot is required.
> > Reboot Now?   ".
> >
> > If the message and prompt is changed to (3), then the message will
> > more closely follow the existing behavior. It will improve the UX
> > experience.
>
> Well, I‘m not concerned with this part of debian-installer which is 
> maintained by multiple people.
>
> If you would like to get that changed, the debian-boot mailing list is your 
> friend.
>
> I‘m not in charge with all of debian-installer.

Thanks. The issue was raised at
https://lists.debian.org/debian-powerpc/2021/02/msg00011.html.

It looks like the debian-installer folks are getting ready to provide
a new release of the installer
(https://www.debian.org/devel/debian-installer/). Hopefully they will
take the feedback and address the issue before the next release of the
installer.

Jeff

Re: Workaround for installing Debian onto PowerMacs (2020-02-02 image)

[Jeffrey Walton]

On Tue, Feb 9, 2021 at 2:21 AM John Paul Adrian Glaubitz
 wrote:
>
> > On Feb 9, 2021, at 8:07 AM, Jeffrey Walton  wrote:
> >
> > After install the machine reboots automatically. We are not given an
> > opportunity to stop the reboot.
> > In fact, we are not even told a reboot
> > is going to happen.
>
> That’s not true. The last screen does exactly that. It asks you whether you 
> are ready to reboot.
>
> > Maybe the installer needs a step that confirms the
> > reboot with a Yes/No prompt?
>
> It already does that.

I'm probably being too pendactice from the UX point of view.

(1) The last screen says a reboot is needed. The prompt is 
or .

(2) The last screen does not say a reboot will be performed, and does
not offer a choice to not reboot.

When I was faced with (1), I selected  thinking I could drop
into a shell and perform the extra steps.

(3) The last screen should say something like, "A reboot is required.
Reboot Now?   ".

If the message and prompt is changed to (3), then the message will
more closely follow the existing behavior. It will improve the UX
experience.

Jeff

Re: Workaround for installing Debian onto PowerMacs (2020-02-02 image)

[Jeffrey Walton]

On Tue, Feb 2, 2021 at 7:23 AM John Paul Adrian Glaubitz
 wrote:
>
> Hello!
>
> For anyone wanting to install a current Debian unstable snapshot onto their
> PowerMacs, I'm going to write down a short guide how to make sure GRUB
> gets installed properly (in case the installation fails).
>
> Use either the powerpc or ppc64 image depending on your machine type:
>
> > https://cdimage.debian.org/cdimage/ports/snapshots/2021-02-02/
>
> Install normally. After GRUB has been installed and the installation has
> finished, don't reboot the machine yet.
>
> Switch to another console and enter the following commands:
>
> # mount -o bind /dev/ /target/dev/
> # mount -o bind /proc/ /target/proc/
> # mount -o bind /sys/ /target/sys/
>
> # chroot /target/
> # bash
> # grub-install --macppc-directory=/boot/grub
> # export boot_device=$(nvram --print-config=boot-device)
> # nvsetenv boot-device ${boot_device%%BootX}\\grub
>
> # exit
> # exit
> # umount /target/dev
> # umount /target/proc
> # umount /target/sys
> # exit
>
> Then switch back to the installer console.

A small problem...

After install the machine reboots automatically. We are not given an
opportunity to stop the reboot. In fact, we are not even told a reboot
is going to happen. Maybe the installer needs a step that confirms the
reboot with a Yes/No prompt?

The issue is aggravated by OpenFirmware behavior. Each command I issue
at the OF prompt results in a "corrupt disk" message. I can't even
eject the cd. OF tries to load the OS for each command I issue.

Jeff

Re: Package libnss3_3.60-1_ppc64.deb requires Power-7 hardware

[Jeffrey Walton]

On Sat, Jan 16, 2021 at 6:17 PM Carsten Jacobi
 wrote:
>
> For all who still want to run Debian 64bit on a G5, the newest
> libnss3-Package breaks some prominent applications like firefox or
> thunderbird on that machine.
>
> The reason is that in one makefile the compiler options "-mcrypto" and
> "-mvsx" were turned. Hence, there are Power-7 instructions now in
> libfreeblpriv3.so:

Crypto extensions are ISA 2.07, which is POWER8.

VSX is supposedly optional on ISA 2.06 with POWER7, but I don't think
IBM shipped a machine without both. If you are working on POWER7, then
VSX extensions are available.

The odd thing about VSX (I found)... VSX provides loads and stores for
vectors with 64-bit elements, but the operation on them - like vec_add
and vec_sub - did not come until POWER8.

Jeff

Fwd: [platform-testers] [b...@redhat.com: parted-3.3.52 released [alpha]]

[Jeffrey Walton]

FYI... I believe parted one of the programs giving trouble.

Jeff

-- Forwarded message -
From: Brian C. Lane 
Date: Mon, Jan 11, 2021 at 8:58 PM
Subject: [platform-testers] [b...@redhat.com: parted-3.3.52 released [alpha]]
To: 

I just found out about this list, sorry for the lateness of this
announcement. I'm hoping to do a new build this week sometime.

Brian

- Forwarded message from "Brian C. Lane"  -

Date: Mon, 14 Dec 2020 11:51:56 -0800
From: "Brian C. Lane" 
To: parted-de...@lists.alioth.debian.org
Subject: parted-3.3.52 released [alpha]

I've built a 3.3.52 alpha, this will become the stable 3.4 release in a
few weeks if nothing critical is found. I'll be on vacation for a bit, I
may not do this until mid-January.

Here are the compressed sources and a GPG detached signature[*]:
  http://alpha.gnu.org/gnu/parted/parted-3.3.52.tar.xz
  http://alpha.gnu.org/gnu/parted/parted-3.3.52.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify parted-3.3.52.tar.xz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 117E8C168EFE3A7F

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.16.1
  Gettext 0.21
  Gnulib v0.1-4130-g8183682cc
  Gperf 3.1

NEWS

* Noteworthy changes in release 3.3.52 (2020-12-14) [alpha]

** New Features

  Add a new partition type flag, chromeos_kernel, for use with ChromeOS
  machines. This is a GPT-only flag and sets the type GUID to
  FE3A2A5D-4F32-41A7-B725-ACCC3285A309.

  Add a new partition flag for Linux Boot Loader Specification /boot
  partitions. The bls_boot flag will set the msdos partition type to 0xea
  and the GPT partition type GUID to bc13c2ff-59e6-4262-a352-b275fd6f7172.

--
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

- End forwarded message -

--
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

Re: More debug infos - was: Re: iMac G5 "windfarm"

[Jeffrey Walton]

On Sun, Jan 3, 2021 at 6:40 PM John Paul Adrian Glaubitz
 wrote:
>
> On 1/3/21 10:30 PM, John Paul Adrian Glaubitz wrote:
> > FWIW, the source code is here:
> >
> >> https://salsa.debian.org/installer-team/partman-base/-/blob/master/parted_server.c
> >
> > If anyone has any clever idea, please let me know.
> >
> > And if someone wants to debug the issue with the hanging partionier 
> > themselves,
> > check out the log in /var/log/partman on a second terminal while the 
> > partionier
> > is running.
> >
> > As one can see, it just stops after /lib/init.d/30_parted and I'm afraid, I 
> > have
> > absolutely no idea why. There is no crash, no error, nothing.

One question... Are the binaries being built with LTO?

LTO can cause a lot of problems. See, for example,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396.

In another project I am involved with, LTO has to be disabled because
of inline assembly. GCC cannot optimize it properly. Also see
https://github.com/weidai11/cryptopp/issues/993.

Jeff

Jeff

Re: iMac G5 "windfarm"

[Jeffrey Walton]

On Sun, Jan 3, 2021 at 4:30 PM John Paul Adrian Glaubitz
 wrote:
>
> On 1/3/21 10:25 PM, John Paul Adrian Glaubitz wrote:
> > The stuff is open source, if anyone is interested in getting this fixed, 
> > please
> > start reading the code and help me.
>
> FWIW, the source code is here:
>
> > https://salsa.debian.org/installer-team/partman-base/-/blob/master/parted_server.c
>
> If anyone has any clever idea, please let me know.

Looking at iscan_line ... The function assumes a Linux end-of-line:

void
iscan_line(char **str, int expect_leading_newline)
{
int c;
*str = NULL;

c = fgetc(infifo);
if (c == EOF)
return;
if (c == '\n' && expect_leading_newline) {
c = fgetc(infifo);
if (c == EOF)
return;
}
while (c != EOF && c != '\n') {
if (isspace((unsigned char) c))
c = fgetc(infifo);
else {
ungetc(c, infifo);
break;
}
}

if (c == EOF || c == '\n')
*str = calloc(1, 1);
else
iscanf("%m[^\n]", str);
}

The first thing I would do is, make it robust in case an Apple tool
has modified a file. Maybe something like:

/* Existing */
if (c == EOF)
return;

/* New */
else if (c == '\r') {
/* silently swallow CR */
c = fgetc(infifo);
if (c != '\n') {
/* CR only. Make it look like a LF */
fungetc(c, infifo);
c = '\n';
}
}

/* Existing */
if (c == '\n' && expect_leading_newline) {
c = fgetc(infifo);
if (c == EOF)
return;
}

It looks like the while loop may need a touch-up, too.

Jeff

POWER8, GCC 10.2.1 and SIGILL

[Jeffrey Walton]

Hi Everyone,

I'm working on an issue with László Böszörményi, who is our Debian
package maintainer. We have it narrowed down to Debian, GCC 10.2.1 and
POWER8. Also https://github.com/weidai11/cryptopp/issues/986 and
https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B=ppc64el=8.3.0-1=1608488187=0.

It appears GCC 10.2.1 is having trouble restarting a signal handler
after a signal has fired. Here is the code with the cruft trimmed (and
error checking trimmed)
(https://github.com/weidai11/cryptopp/blob/master/ppc_power9.cpp#L42):

bool CPU_ProbePower9()
{
volatile int result = true;
volatile SigHandler oldHandler = signal(SIGILL, SigIllHandler);
volatile sigset_t oldMask = sigprocmask(0, NULLPTR, (sigset_t*));

if (setjmp(s_jmpSIGILL))
result = false;
else
{
// This is "darn r3, 0".
#if CRYPTOPP_BIG_ENDIAN
__asm__ __volatile__ (".byte 0x7c, 0x60, 0x05, 0xe6  \n" : : : "r3");
#else
__asm__ __volatile__ (".byte 0xe6, 0x05, 0x60, 0x7c  \n" : : : "r3");
#endif
result = true;
}

sigprocmask(SIG_SETMASK, (sigset_t*), NULLPTR);
signal(SIGILL, oldHandler);
return result;
}

On POWER8, the darn insn causes a SIGILL. That is expected, and we
have a handler installed for it (the static jump buff called
s_jmpSIGILL).

However, when we re-enter at setjmp() to set the feature flag to
false, the code SIGILL's on the assignment 'result = false;'

The code has worked well for years (and decades in some instances).

I found a few reports in GCC Bugzilla but they are antique.
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__=POWER8%20setjmp%20SIGILL_id=287518=Importance_format=specific.

Is anyone aware of problems with Debian POWER8 , GCC 10.2.1 and use of setjmp?

Thanks in advance.

Re: Updated installer images 2020-12-02

[Jeffrey Walton]

On Sat, Dec 5, 2020 at 6:36 PM Dennis Clarke  wrote:
> ...
> get to a shell with strange
> "busybox" wherein the "ls" command does not support the letter "b" or
> the letter "p" option.

That's par for the course with Busybox. It can be anemic at times. For
example, chmod mode only takes letters like a+x, and not digits like
0755.

Jeff

Re: Updated installer images 2020-12-02

[Jeffrey Walton]

On Sat, Dec 5, 2020 at 4:15 AM John Paul Adrian Glaubitz
 wrote:
>
> Your blank screen may have a different cause such as such as missing
> firmware for your graphics card which is a result of Debian Ports
> currently not having access to contrib and non-free during
> installation - something I can't influence but that's supposed to
> be fixed in the future.

I think it is interesting (in a morbid sort of way) that a Debian
maintainer is not allowed access to the port to fix things.

What is the problem? Who is putting barriers in your way?

Jeff

Re: Installing Jessie on PowerMac G4 (32 bit) -- expired key

[Jeffrey Walton]

On Tue, Jun 23, 2020 at 2:30 AM Jeroen Diederen  wrote:
>
> You might also want to try this:
> https://linux-audit.com/how-to-solve-an-expired-key-keyexpired-with-apt/
> https://futurestud.io/tutorials/fix-ubuntu-debian-apt-get-keyexpired-the-following-signatures-were-invalid
> https://www.reddit.com/r/debian/comments/g9is3p/debian_8_jessie_keyexpired_drive_my_crazy/

Off-topic, this is just plain wrong: "This is a good thing, to warn us
that we should be checking the repository. With an expired key, the
solution is simple: we need to download an updated key."

A signature applied during a valid key period is still good. For those
following a key rotation scheme, no new signatures should occur after
the key expires.

But in the big Security Engineering picture, what we've found in
practice is, key continuity is better then key rotation. As long as
the key does not change unexpectedly, then the key is good.

Peter Gutmann covers all of this stuff in his book Engineering
Security (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). I
wish the maintainers of Apt would read it and stop wasting our time
with these keys due to broken policies.

Jeff

Re: 64-bit subtract from vector unsigned int

[Jeffrey Walton]

On Tue, Apr 7, 2020 at 7:51 AM Jeffrey Walton  wrote:
>
> On Tue, Apr 7, 2020 at 5:51 AM Jeffrey Walton  wrote:
> >
> > Hi Everyone,
> >
> > I'm porting a 64-bit algorithm to 32-bit PowerPC (an old PowerMac).
> > The algorithm is simple when 64-bit is available, but it gets a little
> > ugly under 32-bit.
> > ...
> >
> > Here's what an "add with carry" looks like. The addc simply adds the
> > carry into the result after transposing the carry bits from columns 1
> > and 3 to columns 0 and 2.
> >
> > typedef __vector unsigned char uint8x16_p;
> > typedef __vector unsigned int uint32x4_p;
> > ...
> >
> > inline uint32x4_p VecAdd64(const uint32x4_p& vec1, const uint32x4_p& vec2)
> > {
> > // 64-bit elements available at POWER7 with VSX, but addudm requires 
> > POWER8
> > #if defined(_ARCH_PWR8)
> > return (uint32x4_p)vec_add((uint64x2_p)vec1, (uint64x2_p)vec2);
> > #else
> > const uint8x16_p cmask = {4,5,6,7, 16,16,16,16, 12,13,14,15, 
> > 16,16,16,16};
> > const uint32x4_p zero = {0, 0, 0, 0};
> >
> > uint32x4_p cy = vec_addc(vec1, vec2);
> > cy = vec_perm(cy, zero, cmask);
> > return vec_add(vec_add(vec1, vec2), cy);
> > #endif
> > }
>
> I think I found it... The compliment of the carry was throwing me off.
> Subtract with borrow needs an extra vec_andc to un-compliment the
> borrow:
>
> const uint8x16_p bmask = {4,5,6,7, 16,16,16,16, 12,13,14,15, 16,16,16,16};
> const uint32x4_p amask = {1, 1, 1, 1};
> const uint32x4_p zero = {0, 0, 0, 0};
>
> uint32x4_p bw = vec_subc(vec1, vec2);
> bw = vec_andc(amask, bw);
> bw = vec_perm(bw, zero, bmask);
>return vec_sub(vec_sub(vec1, vec2), bw);

Sorry to dig up an old thread... I've been working with Steven Munroe,
who is a retired IBM engineer and maintainer of pveclib
(https://github.com/munroesj52/pveclib). Munroe recommended avoid the
load and permute, and use a shift instead.

Here is an updated VecSub64 routine.

typedef __vector unsigned int uint32x4_p ;
...

#if defined(__BIG_ENDIAN__)
const uint32x4_p zero = {0, 0, 0, 0};
const uint32x4_p mask = {0, 1, 0, 1};
#else
const uint32x4_p zero = {0, 0, 0, 0};
const uint32x4_p mask = {1, 0, 1, 0};
#endif

uint32x4_p bw = vec_subc(vec1, vec2);
uint32x4_p res = vec_sub(vec1, vec2);
bw = vec_andc(mask, bw);
bw = vec_sld (bw, zero, 4);
return vec_sub(res, bw);

Jeff

Broken link on install page

[Jeffrey Walton]

Hi Everyone,

The "Debian GNU/Linux PowerPC PowerMac Page",
https://www.debian.org/ports/powerpc/inst/pmac says to visit the fine
manual for the detailed instructions. The link is
https://www.debian.org/releases/stable/powerpc/, but the page is
missing.

Would someone know where the page is now located?

Thanks in advance.

Re: Lombard booting Debian Ports 2020-04-19 (was Re: Updated installation images for Debian Ports 2020-04-19)

[Jeffrey Walton]

On Mon, Apr 20, 2020 at 11:23 AM John Paul Adrian Glaubitz
 wrote:
>
> ...
> >> ...
> >> If you want to verify that the updated version shows the paths correctly,
> >> you have to checkout the script from git and run it from there:
> >>
> >> # https://github.com/glaubitz/powerpc-utils.git
> >> # git checkout mac-support
> >> # ./scripts/ofpathname /dev/sda
> >> # ./scripts/ofpathname /dev/sda1
> >> ...
> > root@lombard:/test/scripts# ./ofpathname --version
> > ofpathname: Version 0.5
> > Written by: Nathan Fontenot 
> >
> > root@lombard:/test/scripts# ./ofpathname /dev/sda
> > /pci@8000/mac-io@10/ata-3@2/scsi@0/sd@0,0
> > root@lombard:/test/scripts# ./ofpathname /dev/sda1
> > /pci@8000/mac-io@10/ata-3@2/scsi@0/sd@0,0
>
> I think you forgot to the "mac-support" branch as the OF path
> string is missing the partition suffix.

This seems to be a recurring theme.

Maybe Master should check for OS X, and tell the user to switch to the
mac-support branch.

The change will probably save some time/messages during testing. At
minimum it will stop wasting your time in repeating yourself. (I'm not
throwing stones; I'll probably make the same mistake myself).

Jeff

Re: iMac G3 support in Sid, Impossible?

[Jeffrey Walton]

On Sat, Apr 18, 2020 at 4:56 PM Alex McKeever
 wrote:
>
> The problem I have now is X fails to configure and I’m unable to find an up 
> to date configuration file for this machine.

After unpacking X, update their confg.guess and config.sub. See
https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html.
You can use the same process for other packages, like X.

Otherwise, you may need to post the relevant parts of config.log.

Jeff

Re: ofpath vs ofpathname vs grub-ofpathname

[Jeffrey Walton]

On Fri, Apr 17, 2020 at 5:03 AM John Paul Adrian Glaubitz
 wrote:
>
> On 4/17/20 10:51 AM, Romain Dolbeau wrote:
> > Le ven. 17 avr. 2020 à 10:37, John Paul Adrian Glaubitz
> >  a écrit :
> >> I have come up with this patch, can you test it on the mac-support branch?
> >
> > No cigars:
> >
> > ...
>
> Well, I don't have access to a G5 because no one grants me access to one so
> I have to write this code blind-folded.
>
> Guess, I'll have to wait then until someone has mercy and grants me access
> or they'll send me a patch themselves.
>
> Continuing this way is not efficient.

If no one offers SSH access, then I can order a drive for my PowerMac,
and then install Linux on the new drive. The old drive with OS X will
be removed.

It will take a couple of days, though.

Let me know if you want it.

Jeff

Re: ofpath vs ofpathname vs grub-ofpathname

[Jeffrey Walton]

> Anyone can provide me with access to a G5 for testing? I just want check the
> device paths output by my patched "ofpathname".

Yes. Send your SSH public keys/authorized_keys to noloader, gmail account.

On Thu, Apr 16, 2020 at 11:23 AM John Paul Adrian Glaubitz
 wrote:
>
> I have finally found some time to work on this issue again.
>
> First things first, I have reviewed the messages in this thread and compared
> it with the source code and the knowledge about the hardware I have.
>
> I have concluded that the following changes are necessary in ofpathname:
>
>  1) ofpathname needs to gain support for partition IDs in OF paths; something
> that is currently only supported for the function l2of_nvme() but not
> for l2of_ide() and l2of_scsi().
>
>  2) On PATA systems like the PowerBook G4, the OF path is constructed as:
>
> /$BUS/$DRIVER/@$DEVID:$PART
>
>  3) On SATA systems like the PowerMac G5, the OF path includes the plug ID:
>
> /$BUS/$DRIVER/@$PLUGID/@$DEVID:$PART
>
>  4) On systems with Firewire disks, we need to include the node ID on the
> Firewire bus plus the constant for the driver called "sbp-2":
>
> /$BUS/$DRIVER/$IEEE1394_NODEID/sbp-2/@$DEVID:$PART
>
> 1) through 3) are fairly easy to implement, 4) needs some scripting-fu.
>
> I will work on the first three now.
>
> Anyone can provide me with access to a G5 for testing? I just want check the
> device paths output by my patched "ofpathname".
>
> Alternatively, can someone run the ofpathname command from the powerpc-utils
> package on different physical disks, e.g. sda1 and sdb1 and do the same with
> the ofpath command?

Re: Debian on a PowerMac G5 installers broken for 2019-04-11 and 2019-11-24

[Jeffrey Walton]

On Mon, Apr 13, 2020 at 3:01 AM John Paul Adrian Glaubitz
 wrote:
>
> ...
> What frustrates me is that even though there are so many testing and using
> these images, apparently no one is willing to help me. Especially since
> porting the various quirks from Yaboot's ofpath [1] over to ofpathname
> from the powerpc-utils package [2] isn't rocket science. Just a lot of
> tedious stupid typing and testing work.

John, I have a PowerMac G5 and would be happy to help with testing.

If you can provide a bootable ISO with diagnostics, I am happy to run
it and report back. Something like a GRUB dry run that spits out its
errors.

Jeff

Re: 64-bit subtract from vector unsigned int

[Jeffrey Walton]

On Wed, Apr 8, 2020 at 7:31 AM Mathieu Malaterre  wrote:
>
> Jeffrey,
>
> On Wed, Apr 8, 2020 at 11:56 AM Jeffrey Walton  wrote:
> >
> > On Tue, Apr 7, 2020 at 8:27 AM Lennart Sorensen
> >  wrote:
> > >
> > > On Tue, Apr 07, 2020 at 05:51:54AM -0400, Jeffrey Walton wrote:
> > > > Hi Everyone,
> > > >
> > > > I'm porting a 64-bit algorithm to 32-bit PowerPC (an old PowerMac).
> > > > The algorithm is simple when 64-bit is available, but it gets a little
> > > > ugly under 32-bit.
> > > >
> > > > PowerPC has a "Vector Subtract Carryout Unsigned Word" (vsubcuw),
> > > > https://www.nxp.com/docs/en/reference-manual/ALTIVECPEM.pdf. The
> > > > altivec intrinsics are vec_vsubcuw and vec_subc.
> > > >
> > > > The problem is, I don't know how to use it. I've been experimenting
> > > > with it but I don't see the use (yet).
> > > >
> > > > How does one use vsubcuw to implement a subtract with borrow?
> > >
> > > Does your 32 bit powerpc have altivec?  A lot do not.  It is certainly
> > > not a universal feature.  As far as I remember, G4 and G5 powermacs have
> > > it, but nothing older.
> >
> > Yes, this is an old PowerMac G4 with Power4. It has a Altivec unit,
> > but it is only 32-bit. Add, subtract, shift and rotate (and friends)
> > on 64-bit values are missing.
> >
> > As old as the hardware is (circa 2000), that old PowerPC chip
> > outperforms some modern hardware, like Atoms, Celerons and low-end ARM
> > cpu's in modern gadgets.
> >
> > Testing some algorithms, like Simon-128 and Speck-128, show a need for
> > Altivec. For example, Integer-based Speck-128 was running at about 70
> > cpb. Altivec-based Speck-128 dropped to 10 cpb even with me doing all
> > the 64-bit fixups. (Speck-128 runs around 2.5 cpb when the native
> > hardware supports 64-bit operations, like on Power8).
>
> [Somewhat off-topic here.]
>
> Did you ever tried crc32 with altivec ? crc32 with altivec in the
> kernel is only for ppc64.

No. I think the CRC32 support comes from Power8 and in-core crypto
using polynomial multiplies. Here's the fellow who has the reference
implementation and tutorial:
https://github.com/antonblanchard/crc32-vpmsum.

I don't use CRC32 much. I do have GCM mode using polynomial multiples
(along with Power8 AES). It runs around 1.3 cpb.

Jeff

Re: 64-bit subtract from vector unsigned int

[Jeffrey Walton]

On Tue, Apr 7, 2020 at 8:27 AM Lennart Sorensen
 wrote:
>
> On Tue, Apr 07, 2020 at 05:51:54AM -0400, Jeffrey Walton wrote:
> > Hi Everyone,
> >
> > I'm porting a 64-bit algorithm to 32-bit PowerPC (an old PowerMac).
> > The algorithm is simple when 64-bit is available, but it gets a little
> > ugly under 32-bit.
> >
> > PowerPC has a "Vector Subtract Carryout Unsigned Word" (vsubcuw),
> > https://www.nxp.com/docs/en/reference-manual/ALTIVECPEM.pdf. The
> > altivec intrinsics are vec_vsubcuw and vec_subc.
> >
> > The problem is, I don't know how to use it. I've been experimenting
> > with it but I don't see the use (yet).
> >
> > How does one use vsubcuw to implement a subtract with borrow?
>
> Does your 32 bit powerpc have altivec?  A lot do not.  It is certainly
> not a universal feature.  As far as I remember, G4 and G5 powermacs have
> it, but nothing older.

Yes, this is an old PowerMac G4 with Power4. It has a Altivec unit,
but it is only 32-bit. Add, subtract, shift and rotate (and friends)
on 64-bit values are missing.

As old as the hardware is (circa 2000), that old PowerPC chip
outperforms some modern hardware, like Atoms, Celerons and low-end ARM
cpu's in modern gadgets.

Testing some algorithms, like Simon-128 and Speck-128, show a need for
Altivec. For example, Integer-based Speck-128 was running at about 70
cpb. Altivec-based Speck-128 dropped to 10 cpb even with me doing all
the 64-bit fixups. (Speck-128 runs around 2.5 cpb when the native
hardware supports 64-bit operations, like on Power8).

Jeff

Re: 64-bit subtract from vector unsigned int

[Jeffrey Walton]

On Tue, Apr 7, 2020 at 5:51 AM Jeffrey Walton  wrote:
>
> Hi Everyone,
>
> I'm porting a 64-bit algorithm to 32-bit PowerPC (an old PowerMac).
> The algorithm is simple when 64-bit is available, but it gets a little
> ugly under 32-bit.
> ...
>
> Here's what an "add with carry" looks like. The addc simply adds the
> carry into the result after transposing the carry bits from columns 1
> and 3 to columns 0 and 2.
>
> typedef __vector unsigned char uint8x16_p;
> typedef __vector unsigned int uint32x4_p;
> ...
>
> inline uint32x4_p VecAdd64(const uint32x4_p& vec1, const uint32x4_p& vec2)
> {
> // 64-bit elements available at POWER7 with VSX, but addudm requires 
> POWER8
> #if defined(_ARCH_PWR8)
> return (uint32x4_p)vec_add((uint64x2_p)vec1, (uint64x2_p)vec2);
> #else
> const uint8x16_p cmask = {4,5,6,7, 16,16,16,16, 12,13,14,15, 16,16,16,16};
> const uint32x4_p zero = {0, 0, 0, 0};
>
> uint32x4_p cy = vec_addc(vec1, vec2);
> cy = vec_perm(cy, zero, cmask);
> return vec_add(vec_add(vec1, vec2), cy);
> #endif
> }

I think I found it... The compliment of the carry was throwing me off.
Subtract with borrow needs an extra vec_andc to un-compliment the
borrow:

const uint8x16_p bmask = {4,5,6,7, 16,16,16,16, 12,13,14,15, 16,16,16,16};
const uint32x4_p amask = {1, 1, 1, 1};
const uint32x4_p zero = {0, 0, 0, 0};

uint32x4_p bw = vec_subc(vec1, vec2);
bw = vec_andc(amask, bw);
bw = vec_perm(bw, zero, bmask);
   return vec_sub(vec_sub(vec1, vec2), bw);

Jeff

64-bit subtract from vector unsigned int

[Jeffrey Walton]

Hi Everyone,

I'm porting a 64-bit algorithm to 32-bit PowerPC (an old PowerMac).
The algorithm is simple when 64-bit is available, but it gets a little
ugly under 32-bit.

PowerPC has a "Vector Subtract Carryout Unsigned Word" (vsubcuw),
https://www.nxp.com/docs/en/reference-manual/ALTIVECPEM.pdf. The
altivec intrinsics are vec_vsubcuw and vec_subc.

The problem is, I don't know how to use it. I've been experimenting
with it but I don't see the use (yet).

How does one use vsubcuw to implement a subtract with borrow?

Thanks in advance.

==

Here's what an "add with carry" looks like. The addc simply adds the
carry into the result after transposing the carry bits from columns 1
and 3 to columns 0 and 2.

typedef __vector unsigned char uint8x16_p;
typedef __vector unsigned int uint32x4_p;
...

inline uint32x4_p VecAdd64(const uint32x4_p& vec1, const uint32x4_p& vec2)
{
// 64-bit elements available at POWER7 with VSX, but addudm requires POWER8
#if defined(_ARCH_PWR8)
return (uint32x4_p)vec_add((uint64x2_p)vec1, (uint64x2_p)vec2);
#else
const uint8x16_p cmask = {4,5,6,7, 16,16,16,16, 12,13,14,15, 16,16,16,16};
const uint32x4_p zero = {0, 0, 0, 0};

uint32x4_p cy = vec_addc(vec1, vec2);
cy = vec_perm(cy, zero, cmask);
return vec_add(vec_add(vec1, vec2), cy);
#endif
}

==

Here's what I have for subtract with borrow in terms of addition.
There are 4 loads and then 9 instructions. I know it is too
inefficient.

const uint32x4_p mask = {0x, 0x, 0x, 0x};
const uint8x16_p cmask = {4,5,6,7, 16,16,16,16, 12,13,14,15, 16,16,16,16};
const uint32x4_p zero = {0, 0, 0, 0};
const uint32x4_p  one = {0, 1, 0, 1};

// one's compliment, still need to add 1
uint32x4_p comp = vec_andc(mask, vec2);

uint32x4_p cy = vec_addc(one, comp);
cy = vec_perm(cy, zero, cmask);
comp = vec_add(vec_add(one, comp), cy);

cy = vec_addc(vec1, comp);
cy = vec_perm(cy, zero, cmask);
return vec_add(vec_add(vec1, comp), cy);