Re: GRUB doesn't install
Le sam. 25 juil. 2020 à 20:48, Mark Cave-Ayland a écrit : > -prom-env 'boot-device=hd:,\\BootX' Nope; however going for the full paths (both device from syslog and file from looking in the partition - turns out it mirrors OSX's bootloader) like this: -prom-env 'boot-device=/pci@f200/mac-io@c/ata-3@2/@0:2,\System\Library\CoreServices\BootX' loaded grub, so it's on the drive. At that point there's no grub.cfg, so you just get the command-line. Instead of figuring out how to load the kernel, I just re-booted the VM with -kernel/-initrd/-append, then re-installed grub (it re-failed with the same error, of course), then did a manual update-grub to get the grub.cfg. After that, using the '-prom-env' above allowed me to boot the VM directly. There were some errors/warnings from the firmware it seems, but I eventually got a login prompt. Out of curiosity, I installed a newer kernel (the CD installer used 5.6, I added 5.7), install was flawless including the update of grub.cfg, and the VM rebooted directly on 5.7. So it seems if qemu let 'nvsetenv' do its thing, the installer would have no issue (at least with this particular firmware/qemu combination). Cordially, -- Romain Dolbeau
Re: GRUB doesn't install
Le sam. 25 juil. 2020 à 11:55, Mark Cave-Ayland a écrit : > First thing to ask is does your newly created vm-ppc HD image boot when you > change > the "-boot" parameter to "-boot c"? Nope, couldn't get it to boot with just 'c' or the parameters I listed (... after removing the '-cdrom XXX' parameter, otherwise it boots the installer). Cordially, -- Romain Dolbeau
Re: GRUB doesn't install
Le mer. 22 juil. 2020 à 18:01, John Paul Adrian Glaubitz a écrit : > Use scp. Or 'cp' to /target, and then mount /target from the VM host. Attached is the syslog from attempting to install in a QEMU VM (similar to David's); GRUB fails to install for me as well. This is with Mark's OpenBIOS. Self-compiler qemu 4.2.0 started with: $QEMU/bin/qemu-system-ppc \ -monitor stdio \ -M mac99 -machine accel=tcg -m 1G \ -cdrom ./debian-10.0.0-powerpc-NETINST-1.iso \ -hda /dev/zvol/x10drldatapool/vm-ppc \ -boot order=dc,menu=on \ -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user \ -rtc base=localtime \ -bios openbios-ppc-grubfix \ -vnc :1 Hope this helps. Cordially, -- Romain Dolbeau syslog.gz Description: application/gzip
Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4
Le mer. 15 juil. 2020 à 12:46, Romain Dolbeau a écrit : > You need to locate a SIL3112 (or in a pinch, SIL3114 can do) based PCI > SATA card and flash it with a Fcode BIOS Apparently, there is an ongoing effort to create a new firmware for the family of chips, which should make G4 users' life easier :-) <http://macos9lives.com/smforum/index.php/topic,5534.0.html> Cordially, -- Romain Dolbeau
Re: Looking for a PCI (not PCIe) card for (non-raid) SATA that is compatible with PowerMac G4
Le mer. 15 juil. 2020 à 12:27, Rick Thomas a écrit : > I have an old PowerMac G4 "Silver" (PowerMac3,4 533 MHz) running Debian > Jessie, that I'd like to put a couple of SATA disks into. That's a desire shared by many people, unfortunately with few good answers. You need to locate a SIL3112 (or in a pinch, SIL3114 can do) based PCI SATA card and flash it with a Fcode BIOS that was originally designed for a mac-oriented card. Details and links (of questionable legitimacy as the Fcode is probably still copyrighted) can be found on some Mac forums - or at least in their archives. I have a SIL3114 booting 10.5 in a G4 FW800. I've successfully made a PCIe LSI1068e boot from a SAS drive in a PCIe G5, and a similar procedure should work for PCI-X LSI1068/1064 in a PCI-X G5 (see <http://www.sunhelp.org/pipermail/rescue/2020-July/142265.html> and <http://www.sunhelp.org/pipermail/rescue/2020-July/142249.html>). However, those PCI-X cards are 3.3V only. Unless you can locate a 5V PCI[-X] card with a LSI1064/1068, it won't help in a G4 as its PCI slots are 5V only. I have _never_ seen a 5V LSI1064/1068 (and I've looked for my G4s!), so the SIL311[24] way is the only credible solution that I know of :-( Cordially, -- Romain Dolbeau
Re: Bug#826796: Request for a new: linux-image-powerpc64-4K
Le ven. 5 juin 2020 à 09:41, Linux User #330250 a écrit : > Because: why not use btrfs on a 64-Bit PowerPC, right? Well, ZFS works fine on PPC64 (and PPC!) and 'someone' even contributed AltiVec acceleration for the RAID-Z algorithms :-) [in all fairness, I haven't tried ZFS Root on PPC64, only on x68-64 & SPARC64]. On the subject of page size - 64 KiB makes a lot more sense than 4 KiB when you have gigabytes of memory. The fact that x86-64 is stuck with the page size of a 80386 with 4 MiB of RAM doesn't mean everyone should be... And 64 KiB should gain traction on modern hardware, as it's the default in e.g. RedHat for Arm64 (why RISC-V thinks 4 KiB is OK for everyone I'll never understand, it's fine for small embedded but not larger systems). The PowerPC 970 only has 1024 entries in it's TLB IIRC, it's probably quite useful to be able to map 64 MiB instead of 4 MiB without TLB reloads... Broken software that can't work with non-4 KiB page size should be fixed rather than forcing everyone to stay on the 80's idea of memory usage. Most G5 owners probably maxed-out memory as it's dirt cheap nowadays (I know I have the full 16 GiB), and those CPUs need all the help they can get. That being said - I'm not the one doing the work and it's probably time-consuming to fix support for old hardware (which may or may not be even capable to deal with it in the first place), so if the only way to get proper support for old GPUs is to go back to 4 KiB page size, so be it. I'd appreciate it if we kept both variant rather than a full revert, though (if only for testing support isn't broken as it was for a while last year). Cordially, -- Romain Dolbeau
Re: I was surprised to see Oops: Exception in kernel
Le dim. 19 avr. 2020 à 19:08, Dennis Clarke a écrit : > I have a dedicated Intel i7 based machine Mine being Xeon the frequency are likely lower, and the storage is spinning rust (a ZFS mirrored pool on a couple of old SAS drive). So you should be at least as fast, if not perceptively faster... > > I'm not sure you can get MTTCG doing PPC64LE-on-PPC64BE.. > Ha .. no way. No. Well, I gave it a go just in case :-), and the VM dies very quickly (don't even see a kernel message) with the host kernel (5.4) complaining of "user access to kernel address". Both with a home-compiled QEMU 4.1 & Debian's 4.2, using a clone of the PPC64EL filesystem (ZFS send/recv). I don't see more than 100% load from QEMU, but it's not conclusive as I'm not sure the kernel gets a chance to spin up the other cores... Cordially, -- Romain Dolbeau
Re: I was surprised to see Oops: Exception in kernel
Le ven. 17 avr. 2020 à 02:30, Dennis Clarke a écrit : > I have no idea how that works. Normally it's the default, quoting the doc: "The default is to enable multi-threading where both the back-end and front-ends support it and no incompatible TCG features have been enabled (e.g. icount/replay)." > I see terrible horrific performance You need some pretty fast host cores to get an interactively usable emulated host. My home test system is a dual E5-2690v4... > ppc64@styx:~$ ./ppc64le.sh Is your host PPC64 as the username implies? I assume it's not PPC64LE otherwise you'd run KVM rather than TCG, so PPC64BE ... I'm not sure you can get MTTCG doing PPC64LE-on-PPC64BE... and most PPC64BE systems are old and not particularly fast, emulating PPC64LE on them isn't going to be fast :-( Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le ven. 17 avr. 2020 à 11:26, Jeffrey Walton a écrit : > If no one offers SSH access I'm going to try to let Adrian plays with my Quad, but if you have a different/older models the ability to try/port on it as well might be valuable nonetheless. Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
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: dolbeau@powermacg5:~/powerpc-utils$ sudo ./scripts/ofpathname sda /ht@0,f200/pci@9/k2-sata-root@c/@0 The first added line on your patch compares the variable 'fc' to 'sata', but if I echo $fc, it actually contains 'k2-sata-root' on my system - so plug_id is never set (confirmed by looking at the output of bash -x). If I compare to 'k2-sata-root' instead, plug_id stays empty for the first two times it's set, then the last one fallback to -1, naturally. Looking at the setting of plug_id, it's looking for some 'host' in two places where I don't have any (for sda): ls: cannot access '/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata2/host1/target1:0:0/1:0:0:0/*/host*': No such file or directory ls: cannot access '/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata2/host1/target1:0:0/1:0:0:0/host*': No such file or directory It's only the final 'host*' part that is missing, the directory itself exists: dolbeau@powermacg5:~/powerpc-utils$ ls /sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata2/host1/target1:0:0/1:0:0:0/ blacklist eh_timeout inquiry power scsi_levelvpd_pg80 block evt_capacity_change_reportediocounterbits queue_depth state vpd_pg83 bsg evt_inquiry_change_reported iodone_cnt queue_typesubsystem wwid delete evt_lun_change_reported ioerr_cnt rescantimeout device_blocked evt_media_changeiorequest_cnt rev type device_busy evt_mode_parameter_change_reported modalias scsi_device uevent dh_stateevt_soft_threshold_reached model scsi_disk unload_heads driver generic ncq_prio_enable scsi_generic vendor Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le ven. 17 avr. 2020 à 10:17, John Paul Adrian Glaubitz a écrit : > Can you edit Yaboot's ofpath script and set DEBUG=1, then run "ofpath" on both > /dev/sda1 and /dev/sdb1? First on the drives just in case, then on the partitions as requested: # dolbeau@powermacg5:~$ sudo ./ofpath.debug /dev/sda SYS_DEVICE=/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata2/host1/target1:0:0/1:0:0:0 SCSI_DEVICE=1:0:0:0 HOST_ID=1 BUS_ID=0 DEVICE_ID=0 LUN_ID=0 PLUG_ID=0 IEEE1394_ID= SCSI_NAME=k2-sata-root SCSI_DRIVER=sata_svw SYS_PATH=/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0 OF_PATH=/ht@0,f200/pci@9/k2-sata-root@c PART= LUNX= /ht@0,f200/pci@9/k2-sata-root@c/@0/@0 dolbeau@powermacg5:~$ sudo ./ofpath.debug /dev/sdb SYS_DEVICE=/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata3/host2/target2:0:0/2:0:0:0 SCSI_DEVICE=2:0:0:0 HOST_ID=2 BUS_ID=0 DEVICE_ID=0 LUN_ID=0 PLUG_ID=1 IEEE1394_ID= SCSI_NAME=k2-sata-root SCSI_DRIVER=sata_svw SYS_PATH=/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0 OF_PATH=/ht@0,f200/pci@9/k2-sata-root@c PART= LUNX= /ht@0,f200/pci@9/k2-sata-root@c/@1/@0 # dolbeau@powermacg5:~$ sudo ./ofpath.debug /dev/sda1 SYS_DEVICE=/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata2/host1/target1:0:0/1:0:0:0 SCSI_DEVICE=1:0:0:0 HOST_ID=1 BUS_ID=0 DEVICE_ID=0 LUN_ID=0 PLUG_ID=0 IEEE1394_ID= SCSI_NAME=k2-sata-root SCSI_DRIVER=sata_svw SYS_PATH=/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0 OF_PATH=/ht@0,f200/pci@9/k2-sata-root@c PART=:1 LUNX= /ht@0,f200/pci@9/k2-sata-root@c/@0/@0:1 dolbeau@powermacg5:~$ sudo ./ofpath.debug /dev/sdb1 SYS_DEVICE=/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata3/host2/target2:0:0/2:0:0:0 SCSI_DEVICE=2:0:0:0 HOST_ID=2 BUS_ID=0 DEVICE_ID=0 LUN_ID=0 PLUG_ID=1 IEEE1394_ID= SCSI_NAME=k2-sata-root SCSI_DRIVER=sata_svw SYS_PATH=/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0 OF_PATH=/ht@0,f200/pci@9/k2-sata-root@c PART=:1 LUNX= /ht@0,f200/pci@9/k2-sata-root@c/@1/@0:1 # Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le ven. 17 avr. 2020 à 09:27, John Paul Adrian Glaubitz a écrit : > Or maybe the plug ID is identical to the LUN in this case? Maybe 'lssci' can help with your question? dolbeau@powermacg5:~$ lsscsi -tv [0:0:0:0]cd/dvd ata:/dev/sr0 dir: /sys/bus/scsi/devices/0:0:0:0 [/sys/devices/pci0001:00/0001:00:09.0/0001:03:0d.0/ata1/host0/target0:0:0/0:0:0:0] [1:0:0:0]disksata:ATA MAXTOR STM3250310AS 6RY691D9 /dev/sda dir: /sys/bus/scsi/devices/1:0:0:0 [/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata2/host1/target1:0:0/1:0:0:0] [2:0:0:0]disksata:ATA MAXTOR STM3250310AS 6RY5MRVX /dev/sdb dir: /sys/bus/scsi/devices/2:0:0:0 [/sys/devices/pci0001:00/0001:00:09.0/0001:03:0c.0/ata3/host2/target2:0:0/2:0:0:0] Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le jeu. 16 avr. 2020 à 21:31, John Paul Adrian Glaubitz
a écrit :
> > And if my reading of OF 'dev / ls' is correct, the disks should be:
> > /ht@0,f200/pci@9/k2-sata-root@c/k2-sata@0/disk@0
> > /ht@0,f200/pci@9/k2-sata-root@c/k2-sata@1/disk@0
> What does ofpath say?
Still says:
dolbeau@powermacg5:~$ sudo /usr/sbin/ofpath /dev/sda
/ht@0,f200/pci@9/k2-sata-root@c/@0/@0
dolbeau@powermacg5:~$ sudo /usr/sbin/ofpath /dev/sdb
/ht@0,f200/pci@9/k2-sata-root@c/@1/@0
> As far as I know, Apple's OF implementation expects "@0" instead of
> "disk@0". And I have no idea where the "k2-sata@N" component comes
> from.
This is just the values from the OF console itself ('dev / ls'), not
necessarily what is needed as a booting path.
The same path is in /sys:
dolbeau@powermacg5:~$ ls -l
/sys/firmware/devicetree/base/ht@0\,f200/pci@9/k2-sata-root@c/k2-sata@*/*|grep
disk
/sys/firmware/devicetree/base/ht@0,f200/pci@9/k2-sata-root@c/k2-sata@0/disk@0:
/sys/firmware/devicetree/base/ht@0,f200/pci@9/k2-sata-root@c/k2-sata@1/disk@0:
Apparently on this machine, the 'scsi' bit (that appears in Michael's
G5 output) has been replaced by a 'k2-sata' bit.
It seems to be misunderstood by the script, as it's where the
difference between sda and sdb should appear...
Cordially,
--
Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le jeu. 16 avr. 2020 à 20:38, Romain Dolbeau a écrit : > In case tracing the script a bit could be helpful, I attach the log > from tuning 'sudo bash -x ~/powerpc-utils/scripts/ofpathname /dev/sda > 2>&1 | tee /tmp/log'. And if my reading of OF 'dev / ls' is correct, the disks should be: /ht@0,f200/pci@9/k2-sata-root@c/k2-sata@0/disk@0 /ht@0,f200/pci@9/k2-sata-root@c/k2-sata@1/disk@0 Although 'devalias' dispenses with the '@' components for /ht and /k2-sata-root, it just says hd /ht/pci@9/k2-sata-root/k2-sata@0/disk@0 Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le jeu. 16 avr. 2020 à 20:09, John Paul Adrian Glaubitz a écrit : > Ok, so on the G4 FW800, you should see "ofpath" and "ofpathname" showing > _different_ OF paths. Which I do, so that's OK. > Can you now try the patched version from my Github repo on your G5? First, the mystery was solved by the almighty command 'ls', turns out it's not exactly a patch: dolbeau@powermacg5:~$ ls -l /usr/sbin/ofpath* -rwxr-xr-x 1 root root 24392 Apr 14 2019 /usr/sbin/ofpath lrwxrwxrwx 1 root root16 Jan 26 10:49 /usr/sbin/ofpathname -> /usr/sbin/ofpath -rwxr-xr-x 1 root root 40016 Feb 10 2019 /usr/sbin/ofpathname-ibm No idea why that happened, unless I did some weird things trying to get 'grub' to work, and then promptly forgot about it... Anyway - here's the result with your branch, the only difference I see is that 'scsi' & 'sd' are gone: # dolbeau@powermacg5:~/powerpc-utils$ git status On branch mac-support Your branch is up to date with 'origin/mac-support'. nothing to commit, working tree clean dolbeau@powermacg5:~/powerpc-utils$ sudo ~/powerpc-utils/scripts/ofpathname /dev/sda /ht@0,f200/pci@9/k2-sata-root@c/@0/@0 dolbeau@powermacg5:~/powerpc-utils$ sudo ~/powerpc-utils/scripts/ofpathname /dev/sdb /ht@0,f200/pci@9/k2-sata-root@c/@0/@0 # In case tracing the script a bit could be helpful, I attach the log from tuning 'sudo bash -x ~/powerpc-utils/scripts/ofpathname /dev/sda 2>&1 | tee /tmp/log'. Cordially, -- Romain Dolbeau log Description: Binary data
Re: ofpath vs ofpathname vs grub-ofpathname
Le jeu. 16 avr. 2020 à 19:53, Romain Dolbeau a écrit : > > which is why I suspect the ofpathname script on the G4 FW800 machine has > > been > > patched. > Apparently, it _has_ been patched on the G5 I checked, it's vanilla on the G4 FW800. Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le jeu. 16 avr. 2020 à 19:38, John Paul Adrian Glaubitz a écrit : > Basically, your G4 FW800 the ofpathname script outputs the correct path > and it also doesn't expect the error message as on your G5 I'm not sure I follow - the error message appears on the G4FW800, not on the G5? > which is why I suspect the ofpathname script on the G4 FW800 machine has been > patched. Apparently, it _has_ been patched on the G5. I just 'apt-get download' the powerpc-ibm-utils package, extracted it, and compared the md5sum... they differ, with a huge diff! And I have no idea what patched it if that's not what I should get from 'ports'. Sorry for the noise, any idea where that patch could come from? Anyway, the original script is still on the machine as '/usr/sbin/ofpathname-ibm' (md5su matches), and this one might produce what you expect, let's try: dolbeau@powermacg5:~$ sudo /usr/sbin/ofpathname-ibm /dev/sda /usr/sbin/ofpathname-ibm: line 812: warning: command substitution: ignored null byte in input /ht@0,f200/pci@9/k2-sata-root@c/scsi@0/sd@0,0 dolbeau@powermacg5:~$ sudo /usr/sbin/ofpathname-ibm /dev/sdb /usr/sbin/ofpathname-ibm: line 812: warning: command substitution: ignored null byte in input /ht@0,f200/pci@9/k2-sata-root@c/scsi@0/sd@0,0 Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le jeu. 16 avr. 2020 à 19:18, John Paul Adrian Glaubitz a écrit : > Huh? Where is that ofpathname from? Unless you have a patched version, > it shouldn't be printing the SCSI with just an "@". dolbeau@powermacg5:~$ dpkg -S /usr/sbin/ofpathname powerpc-ibm-utils: /usr/sbin/ofpathname dolbeau@powermacg5:~$ dpkg -S /usr/sbin/ofpath yaboot: /usr/sbin/ofpath dolbeau@powermacg5:~$ dpkg -l powerpc-ibm-utils | grep ^ii ii powerpc-ibm-utils 1.3.2-1.1ppc64utilities for maintenance of IBM PowerPC platforms dolbeau@powermacg5:~$ dpkg -l yaboot | grep ^ii ii yaboot 1.3.17-4+ports1 ppc64Yet Another Bootloader I didn't change anything to either command. This should be a standard Debian Ports PPC64 (PPC32 for the G4), probably up-to-date to last January or something like that (I must confess I don't use them everyday ;-) ). Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
> Le jeu. 16 avr. 2020 à 17:23, John Paul Adrian Glaubitz > a écrit : > > 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? On my PowerMac G4 FW800 ; this one has a flashed SIL3114 that's identified as a SIL3112, but IIRC the SATA disk doesn't appear in Linux (it has OSX on it). dolbeau@powermacg4fw800:~$ sudo ofpathname /dev/sda /usr/sbin/ofpathname: line 812: warning: command substitution: ignored null byte in input /pci@f400/ata-6@d/scsi@0/sd@0,0 dolbeau@powermacg4fw800:~$ sudo ofpath /dev/sda /pci@f400/ata-6@d/@0 dolbeau@powermacg4fw800:~$ sudo ofpathname /dev/sdb /usr/sbin/ofpathname: line 812: warning: command substitution: ignored null byte in input /pci@f200/mac-io@17/ata-4@1f000/scsi@0/sd@0,0 dolbeau@powermacg4fw800:~$ sudo ofpath /dev/sdb /pci@f200/mac-io@17/ata-4@1f000/@0 and I'll answer for this one before answering for the G5: dolbeau@powermacg4fw800:~$ dpkg -S /usr/sbin/ofpathname powerpc-ibm-utils: /usr/sbin/ofpathname dolbeau@powermacg4fw800:~$ dpkg -S /usr/sbin/ofpath yaboot: /usr/sbin/ofpath dolbeau@powermacg4fw800:~$ dpkg -l powerpc-ibm-utils | grep ^ii ii powerpc-ibm-utils 1.3.2-1.1powerpc utilities for maintenance of IBM PowerPC platforms dolbeau@powermacg4fw800:~$ dpkg -l yaboot | grep ^ii ii yaboot 1.3.17-4+ports1 powerpc Yet Another Bootloader Cordially, -- Romain Dolbeau
Re: ofpath vs ofpathname vs grub-ofpathname
Le jeu. 16 avr. 2020 à 17:23, John Paul Adrian Glaubitz a écrit : > 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? On my G5 Quad: dolbeau@powermacg5:~$ sudo ofpathname /dev/sda /ht@0,f200/pci@9/k2-sata-root@c/@0/@0 dolbeau@powermacg5:~$ sudo ofpath /dev/sda /ht@0,f200/pci@9/k2-sata-root@c/@0/@0 dolbeau@powermacg5:~$ sudo ofpathname /dev/sdb /ht@0,f200/pci@9/k2-sata-root@c/@1/@0 dolbeau@powermacg5:~$ sudo ofpath /dev/sdb /ht@0,f200/pci@9/k2-sata-root@c/@1/@0 Cordially, -- Romain Dolbeau
Re: I was surprised to see Oops: Exception in kernel
Le jeu. 16 avr. 2020 à 01:07, Dennis Clarke a écrit : > With luck I can run multiple POWER9 cpus and get better performance Multithreaded TCG works fine, so yes '-smp 12' does give me better performance for multi-threaded/multi-programmed workload in the VM (e.g., compiling). > I may give Debian a > try with RISC-V also but that is the opposite end of the scale for > stability. I haven't tried either of those OS, but there's a Fedora port to RISC-V that is rock-solid for me on Qemu 4.1. The only limitation is I haven't be able to convince the firmware/bootloader to initialize more than 8 cores. I'll probably switch to Debian at some point, but it's a work VM so I need something reasonably reliable. Cordially, -- Romain Dolbeau
Re: I was surprised to see Oops: Exception in kernel
Le mer. 15 avr. 2020 à 15:08, Dennis Clarke a écrit : > This is inside a qemu ppc64 instance wherein attempting to use POWER9 > or the POWER8 cpu types. Seems to result in a kernel panic repeatedly : I have a QEMU PPC64EL image running Debian Buster, and it has been rock-solid for my usage (I checked my AltiVec code for ZFS was working on little-endian system in there, along with some AltiVec crypto - all my PPC hardware is big-endian). I'm running 4.19.0-6 from Buster, but from the command-line in the host filesystem, not from inside the image. I'm also using a newer QEMU (4.1, I've had issue with SSH'ing into the machine with 4.2), machine & CPU definitions: /usr/local/qemu-4.1.0/bin/qemu-system-ppc64 \ -machine pseries-4.1 -cpu power9 -smp 12 -m 12G \ -drive file=/dev/x10drldatapool/vm-ppc64el,format=raw \ -monitor stdio -vnc :2 \ -kernel vmlinux-4.19.0-6-powerpc64le \ -append "root=/dev/qemuppc64el-vg/root" \ -initrd initrd.img-4.19.0-6-powerpc64le \ -device virtio-net-pci,netdev=usernet -netdev user,id=usernet,hostfwd=tcp::10002-:22 Just dist-upgrade'd it from ~10.1 to the 10.3 of today, and didn't have any issue... Maybe the newer kernels are the problem, did you try standard Buster ? (PPC64EL is officially supported by Debian, unlike the big-endian versions which are ports). Cordially, -- Romain Dolbeau
Re: 64-bit subtract from vector unsigned int
Le mer. 8 avr. 2020 à 11:56, Jeffrey Walton a écrit : > 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. They don't feel that fast anymore... Even a Raspberry Pi 3 will run circle around my dual-1.25 GHz G4 (not that much faster per-core, but there's 4 of them), and even more so for the single G4. And a Rpi4 is even faster per-core. And while the PATA interface is faster than the SD card of the Pi, it's not that great for I/O either. And they don't have that much memory, either. The G5 is a whole different beast (I have a quad, complete with the full complement f 16 GiB of ECC RAM, just because I can). > 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). Interesting. Maybe you could share your implementations in the Supercop benchmark? (<http://bench.cr.yp.to/supercop.html>, there's some help in "How to submit new software:"). Are you interested in just those algorithms or crypto in general? I have an AltiVec implementation of Chacha20 in there that can probably be beaten if you feel up to the challenge ;-) (unfortunately, no published results on G4 or recent one on G5 as Supercop takes forever to run, and I've already blown a power supply on my G5 so I'm reluctant to let it run for extended period of time). Cordially, -- Romain Dolbeau
Re: 64-bit subtract from vector unsigned int
Le mar. 7 avr. 2020 à 14:35, Lennart Sorensen a écrit : > 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. You remember correctly, and also G5 (PowerPC 970) are 64-bits natively and will happily run a 64 bits kernel (and even userland) in Linux (including Debian), so this is for G4 (PowerPC 74xx) only (and G5 running OSX, or NetBSD which doesn't have a 64-bit kernel / userland yet). [this is for PowerMacs - some newer, embedded, 32 bits powerpc also have AltiVec, although the one in the AmigaOne X5000 doesn't]. Cordially, -- Romain Dolbeau
Re: Debian Install on G5
Le mar. 14 janv. 2020 à 13:52, Alexandre Bencz a écrit : > Which version is possible to install on the G5 Dual? > I tried several versions yesterday and all gave error when installing GRUB, > the error was: "GRUB Dummy Failed > Another thing ... how to boot the Radeon GPU? There's an issue in current 5.x kernls in Debian for (some) G5, the fix was submitted upstream but is probably not yet integrated. 4.x (and older) kernels should be fine. I've never actually gotten Grub to work on either G4 or G5, but I didn't try very hard. - I'm happy with 'yaboot', which is what the Debian 8 installer uses by default I believe. You could try installing Debian 8 (from 'archive') and then upgrading to the current port, sticking with yaboot (at least at first) - and avoiding 5.x kernels. That worked for me on a G4 last week. Alternatively, you could download the 'Fienix Open Firmware G5 Image', uncompress it, 'dd' it to your G5 hard drive on another linux machine (wiping the drive from everything else, I have two drives in my G5, one OS per drive), and then cross-(up|down)grade to Debian ports. Fienix used to have a newer 4.x than Debian, usable as a stop-gap until Debian's 5.x are fixed. As for the Radeon GPU, if it works in OF/OSX, it should work in Linux as well I would assume (mine has a NVidia GPU, works OK with the 'nouveau' driver). Cordially & good luck, -- Romain Dolbeau
Patch for '5.3.7 64-bits kernel doesn't boot on G5 Quad' found (was: Re: PPC64: G5 & 4k/64k page size)
Hello all, Great news: Aneesh sent me a patch that solves the problem on my G5 Quad :-) I don't know whether he considers it a 'workaround' or if it's the 'proper' patch for upstream, so beware. It's a one-liner so I attach it to this message: those affected can test it as well to confirm if that indeed solves the problem for them as well. If it is the 'proper' patch, I expect it should get into upstream pretty quickly. Then Debian should be able to trivially backport it to their PPC64 kernel, and the G5 will still be a great machine in 2020! Thanks everyone for your help in tracking down the bug & to Aneesh for finding a fix :-) Cordially, -- Romain Dolbeau diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h index 15b75005bc34..516db8a2e6ca 100644 --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h @@ -601,7 +601,7 @@ extern void slb_set_size(u16 size); */ #define MAX_USER_CONTEXT ((ASM_CONST(1) << CONTEXT_BITS) - 2) #define MIN_USER_CONTEXT (MAX_KERNEL_CTX_CNT + MAX_VMALLOC_CTX_CNT + \ - MAX_IO_CTX_CNT + MAX_VMEMMAP_CTX_CNT) + MAX_IO_CTX_CNT + MAX_VMEMMAP_CTX_CNT + 1) /* * For platforms that support on 65bit VA we limit the context bits */
Re: PPC64: G5 & 4k/64k page size
Le mar. 7 janv. 2020 à 16:27, Bertrand a écrit : > I've tested the 5.5-rc package with the link you gave hereafter. When > you said "working kernel", did you mean it would not crash ? It doesn't > for me. I can boot successfully. Yes, unlike the default Debian build, this one has 4 KiB page size. It's not a solution, but it's a workaround for those affected by the bug and perhaps a clue to the issue. As your machine is booting regular 5.3 as well and seems not affected by the bug, can you share some details about it? (exact model, number of cores, ...). > The only weirdness I could notice is that my swap space wasn't mounted. No surprise, I think the on-disk format for the swap space hardwire the page size. There's even a '-p' option to 'mkswap' to specify a page size when creating the swap space. Cordially, -- Romain Dolbeau
Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)
Le lun. 6 janv. 2020 à 19:54, Lennart Sorensen a écrit : > Is it possible this has to do with nouveau and not supporting 64K page > size on older nvidia chips? Interesting idea (and I have a 6600 aka NV43 in there, indeed) but I don't think so, as a) 'nouveau' works in 4.19 with 64 KiB pages b) using "module_blacklist=nouveau" doesn't help, I just tried c) my original 'bisect' was probably using 'nouveau' when the kernel was booting, so at least some 5.x w/o the offending commit and 64 KiB pages is fine d) to my untrained eye, the crash happens _before_ nouveau is loaded (it seems to me I'm still on the OpenFirmware framebuffer, font change occurs later). Unfortunately I don't have a PCIe OpenFirmware ATI card to test the theory further. (... well I _do_ have a Sun XVR-300 ... technically it fits the bill ... ) Cordially, -- Romain Dolbeau
Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)
Le dim. 5 janv. 2020 à 16:06, Bertrand Dekoninck a écrit : > I can now test on powermac 7,3 (with an ATI card) > How can I build a deb package of this kernel ? Or is there a package to > download somewhere ? I usually cross-compile on x86-64 from upstream sources. On a Debian Buster with the powerpc tools installed, it's just: # make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- oldconfig && nice -19 make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- -j56 bindeb-pkg # (alter the -j56 for your own build system). For the dependency, as far as I remember I only needed "gcc-powerpc64-linux-gnu" and dependencies. My '.config' is Debian's 5.3 plus default values for changes - with the exception of 4 KiB pages. I've also uploaded the working kernel with 4 KiB pages DEB here: <http://dl.free.fr/otB1KMEMR>, as it might be easier for a quick test. Cordially, -- Romain Dolbeau
Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)
Le lun. 6 janv. 2020 à 15:06, Aneesh Kumar K.V a écrit : > Can you try this change. Applied, recompiled with 64 KiB pages, still crashes. The backtrace seems more readable this time (and wasn't overwritten by something else), bad photo here: <http://www.dolbeau.name/dolbeau/files/Photo0033.jpg> Cordially, -- Romain Dolbeau
Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)
Le sam. 21 déc. 2019 à 05:31, Aneesh Kumar K.V a écrit : > I don't have direct access to this system, I have asked if we can get a run > with 64K. OK, thanks! Do you know which model it is? It seems to be working on some systems, but we don't have enough samples to figure out why at this time, I think. > Meanwhile is there a way to find out what caused MachineCheck? more > details on this? I was checking the manual and I don't see any > restrictions w.r.t effective address. We now have very high EA with 64K > page size. Sorry, no idea, completely out of my depth here. I can try some kernel (build, runtime) options and/or patch, but someone will have to tell me what to try, as I have no ideas. Cordially & Happy New Year! -- Romain Dolbeau
PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)
Le jeu. 12 déc. 2019 à 22:40, Andreas Schwab a écrit : > I'm using 4K pages, in case that matters Yes it does matter, as it seems to be the difference between "working" and "not working" :-) Thank you for the config & pointing out the culprit! With your config, my machine boots (though it's missing some features as the config seems quite tuned). Moving from 64k pages to 4k pages on 'my' config (essentially, Debian's 5.3 with default values for changes since), my machine boots as well & everything seems to work fine. So question to Aneesh - did you try 64k pages on your G5, or only 4k? In the second case, could you try with 64k to see if you can reproduce the crash? To Jeroen - is your iMac booting with 4k or 64k pages? Same question for the crashing G5, though I assume the answer is going to be 64k there. Thanks & cordially, -- Romain Dolbeau
Re: Call for report - G5/PPC970 status
Le jeu. 12 déc. 2019 à 19:20, Andreas Schwab a écrit : > My PowerMac7,3 (DP 2.0GHz) can boot 5.5-rc1 without issues. This is weird, as except for the frequency it should be the same system as Jeroen's crashing G5! Can you share your kernel config, compiler version, and other details? Perhaps even the binary... Thanks & cordially, -- Romain Dolbeau
Re: Call for report - G5/PPC970 status
Le jeu. 12 déc. 2019 à 09:08, John Paul Adrian Glaubitz a écrit : > I suggest booting the machine with a netconsole to get a dump of the crash > over the network, see [1]. I added netconsole (not as a module, directly in the kernel), but I get nothing on my receiver 'nc'. I don't see the network interface identified anywhere prior to the crash, which could explains it (I might also have misconfigured the command-line...). The crash is probably too early. I also tried compiling w/o SMP to see if that changed anything, but the kernel won't compile: first the ppc_watchdog seems to rely on a SMP symbol, and once I disabled it, the MM subsystem was missing some 'numa' symbols. Cordially, -- Romain Dolbeau
Re: Call for report - G5/PPC970 status
Le jeu. 12 déc. 2019 à 08:32, jjhdiederen a écrit : > PowerMac 7,3 G5 2.5 DP PCI-X Mid-2004 is affected with this bug. The > machine freezes at boot due to the new ppc64 kernel. Thanks for the reports! So it's not all G5, but it's across generations - the iMac is PCIe. Perhaps multiprocessors? Could you share the screen/log of the crash? For my G5 with 5.5rc1 I have one, but the photo is terrible: <http://www.dolbeau.name/dolbeau/files/Photo0031.jpg> Timestamps overlap, as after the 'crash' (backtrace) there was more messages from the (S)ATA subsystem. Cordially, -- Romain Dolbeau
Call for report - G5/PPC970 status (was: Re: Found the commit for: 5.3.7 64-bits kernel doesn't boot on G5 Quad [regression])
Le mer. 11 déc. 2019 à 03:20, Aneesh Kumar K.V a écrit : > The PowerMac system we have internally was not able to recreate this. To narrow down the issue - is that a PCI/PCI-X (7,3 [1]) or PCIe G5 (11,2 [1]) ? Single, dual or quad ? Same question to anyone else with a G5 / PPC970 - what is it and does it boot recent PPC64 Linux kernel ? Christian from the original report has a quad, like me (so powermac11,2). There was also a report of a powermac7.3 working in the original discussion, single or dual unspecified. So this might be a Quad thing, or a more general 11,2 thing... > At this point, I am not sure what would cause the Machine check with > that patch series because we have not changed the VA bits in that patch. Any test I could run that would help you tracking the bug ? Cordially, Romain [1] <https://en.wikipedia.org/wiki/Power_Mac_G5#Product_revision_history> -- Romain Dolbeau
Re: Found the commit for: 5.3.7 64-bits kernel doesn't boot on G5 Quad [regression]
Hello, Le sam. 16 nov. 2019 à 17:34, Romain Dolbeau a écrit : > So it seems to me that 0034d395f89d9c092bb15adbabdca5283e258b41 > introduced the bug that crashes the PowerMac G5 There's been some commits in that subsystem, so I tried again; as of 6794862a16ef41f753abd75c03a152836e4c8028, the kernel still crashes when trying to boot my PowerMac G5. Cordially, -- Romain Dolbeau
Re: regarding 2019-07-16 ppc64 debian sid installer : does grub work there ?
> ... requires the help of "boot hd:,\install\yaboot" or some similar > hack to get going ? I didn't try that installer. Both my PowerMacs are using yaboot, I haven't tried grub/ieee1275. yaboot works well and is well documented, so it should be okay either way. > I wanted to see if the most recent linux kernel sources are actually slightly > broken > on the old ppc64 IBM970 chips in the G5 type units. If by 'G5 type units' you mean powermacs, then yes. When I tracked down my bug, I did check the newest kernel at the time, and the bug was still here :-( If you mean another type of machine using ppc970, I'd like to know the result as well. Cordially, -- Romain Dolbeau
Found the commit for: 5.3.7 64-bits kernel doesn't boot on G5 Quad
Le dim. 10 nov. 2019 à 11:45, Romain Dolbeau a écrit : > Any suggestion, advice, or patch to try welcome :-) >From my bisect, I figured that 0034d395f89d9c092bb15adbabdca5283e258b41 was the likely culprit, but that the bug was masked by the printk() issues that were fixed later: commit 2ac5a3bf7042a1c4abbcce1b6f0ec61e5d3786c2 mentions "Report on Power: Kernel crashes very early during boot". Once that was merged, the current bug appears instead of the early crash. So what I did was: 1) checkout 0034d395f89d9c092bb15adbabdca5283e258b41 2) merge printk-for-5.2 & printk-for-5.2-fixes from pmladek/printk, hoping to remove the printk issue ; there was only fairly trivial conflicts -> the resulting kernel displays the same bug as Debian's and vanilla 5.3 and HEAD, which is what I hoped for. However, the merges did pick up quite a few commits, so I then: 3) did a revert of only 0034d395f89d9c092bb15adbabdca5283e258b41 ; that did not cause conflicts (on HEAD, this causes a lot of conflicts I don't know how to resolve). -> the resulting kernel works fine ! :-) So it seems to me that 0034d395f89d9c092bb15adbabdca5283e258b41 introduced the bug that crashes the PowerMac G5 (as/could anyone tried/try on some other PPC970-based system, like a JS20 ? to see if it's PowerMac-specific or not). If anyone has an idea on how to fix this, that would be very welcome, as I'm way out of my depth in the PPC64 MMU code. Cordially, -- Romain Dolbeau
Re: 5.3.7 64-bits kernel doesn't boot on G5 Quad
Hello, Following my bug report on debian-powerpc and the following, I'm adding linuxppc-dev to my answer. Le jeu. 7 nov. 2019 à 11:09, Mathieu Malaterre a écrit : > On Thu, Nov 7, 2019 at 9:34 AM John Paul Adrian Glaubitz > > The answer here would be git bisect [1]. I would first start downloading > > the current kernel source tarball for 5.3.7 from upstream and build the > > kernel with "make localmodconfig" to see whether it's an upstream or Debian > > problem. > I suspect this is upstream and even before 5.3.7. The original report > by Christian has been discussed on linuxpcc-dev: > <https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg155248.html> Thanks to you guys I was able to cross-build a kernel (native would have been way to slow) and try to bisect the bug. However, I ended up in another buggy behavior that may or may not be related :-( I tried to localize the bug(s) as best I could. I attach to this the result of 'git bisect log' to see if someone can figure out what's going on. Some of the commits were hand-picked to avoid doing too many 'skip' configurations with the bug described below. As I marked this: *bad*: seems to behave the same as the Debian kernel or git HEAD, that is, crash as reported (or very similar to, at least) by Christian. *good*: either a full boot, or occasionally the kernel dropped me into initramfs complaining about versioning of some symbols - I figured it went far enough so it did not have the bug. The last one in the file is a full boot as I remember it. *skip*: most of them involves hanging just after cpus start (i.e. including 3 messages about kick-up for the extra cpu and one about bringing up being done, then nothing further). Those covers a lot of commits :-( (I used <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git> and my build command was "make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- oldconfig && make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- -j56 bindeb-pkg", using default values for oldconfig, starting with the config file from Debian at the beginning, cross-gcc is 8.3 from buster, tested on a G5 Quad). Any suggestion, advice, or patch to try welcome :-) Thanks in advance& cordially, -- Romain Dolbeau ppc64_bisect.log.gz Description: GNU Zip compressed data
5.3.7 64-bits kernel doesn't boot on G5 Quad
Hello, The current linux-image package (5.3.7-1) in debian-ports won't boot on my G5 Quad (dual 970MP). I'm currently running the powerpc ports (32 bits userland), not ppc64, but I assume it makes no difference for the 64 bits kernel. I have the same error as previously reported for 5.2.7 in: <https://lists.debian.org/debian-powerpc/2019/08/msg4.html> Kernel packages: # powermacg5:~$ dpkg -l linux-image-* (...) ii linux-image-4.19.0-5-powerpc64 4.19.37-5 powerpc Linux 4.19 for 64-bit PowerPC ii linux-image-4.9.0-0.bpo.6-powerpc64 4.9.88-1+deb9u1~bpo8+1 powerpc Linux 4.9 for 64-bit PowerPC ii linux-image-5.3.0-1-powerpc64 5.3.7-1powerpc Linux 5.3 for 64-bit PowerPC # linux-image-4.9.0-0.bpo.6-powerpc64 is from jessie-backports, linux-image-4.19.0-5-powerpc64 is from the Fienix repository (can't find a Debian build for ppc64 between 4.9 and 5.3). Both works perfectly on the G5. Any suggestion on how to identify/fix the bug ? Thanks in advance & cordially, -- Romain Dolbeau
