Re: M4000 failing to boot Debian Sparc64
On 7/3/23 05:47, John Paul Adrian Glaubitz wrote: Hello! On Mon, 2023-07-03 at 05:28 -0400, Dennis Clarke wrote: I don't think that's true. Since it has been reported that these machines run OpenBSD, it should be a matter of reading the OpenBSD kernel sources and add the missing bits and pieces for the SPARC64 VII(+) machines to the Linux kernel. Are we certain about NetBSD or OpenBSD? I did try to install NetBSD and that failed also. I think I have my notes on that somewhere but it would be easy enough for me to try again. OpenBSD lists the M4000 as supported: https://www.openbsd.org/sparc64.html While I didn't actually mention NetBSD here, since it's not the same as OpenBSD, I checked that as well now and it currently doesn't support Fujitsu CPUs, but that's work-in-progress, same applies to sun4v, i.e. T1-T5. For sun4v, I'm actually in contact with the developer doing the work. https://wiki.netbsd.org/ports/sparc64/ I don't think that would be much as this it just some board-specific code and it wouldn't probably take an experienced kernel developer longer than a month if at all. That brings the costs down to the level of reasonable. Let me ponder that a while. Find someone on the sparclinux Linux kernel mailing list willing to do the work and create a Bountysource campaign to sponsor the work. I assume, you can get it done for maybe $5000-$10.000. Adrian Dear Sir : I just want to follow up to let you know that I am giving this idea some reasonable thought. I suspect the costs and efforts to be quite a bit higher. Merely my own experience in such a collective endeavor where the benefit is hardly measurable with such a small userbase. Having said that, I must also admit that the userbase is so minuscule for precisely the reason one would consider fixing this mess! -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC Four ( or five? ) decades in production systems.
Re: M4000 failing to boot Debian Sparc64
On 7/2/23 17:19, John Paul Adrian Glaubitz wrote: Hi Dennis! Good day to you Sir! On Sun, 2023-07-02 at 14:34 -0400, Dennis Clarke wrote: You are likely kicking a dead horse. That M4000 is similar to my M3000 and you will never ever get Linux to run there. Ever. Unless you have a few million dollars for research and development and then be able to push all the good research upstream into the Linux kernel. I don't think that's true. Since it has been reported that these machines run OpenBSD, it should be a matter of reading the OpenBSD kernel sources and add the missing bits and pieces for the SPARC64 VII(+) machines to the Linux kernel. Are we certain about NetBSD or OpenBSD? I did try to install NetBSD and that failed also. I think I have my notes on that somewhere but it would be easy enough for me to try again. I don't think that would be much as this it just some board-specific code and it wouldn't probably take an experienced kernel developer longer than a month if at all. That brings the costs down to the level of reasonable. Let me ponder that a while. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC
Re: M4000 failing to boot Debian Sparc64
On 7/2/23 06:35, Vocalía Infraestructura TIC CEEINA wrote:
Hi,
We are trying to boot Debian Sparc64 on a SPARC Enterprise M4000 server
(SPARC64 VII+), but, after selecting normal / expert / secure install mode,
we get this error message and the installer quits:
*ERROR: Last Trap: Division by Zero*
*%TL:1 %TT:28 %TPC:43056c %TnPC:430570 %TSTATE:1180001603*
*%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )*
We have tried with the following ISO images:
*debian-12.0.0-sparc64-NETINST-1.iso*, *debian-10.0-sparc64-NETINST-1.iso*
and *debian-9.0-sparc64-NETINST-1.iso*.
You are likely kicking a dead horse. That M4000 is similar to my M3000
and you will never ever get Linux to run there. Ever. Unless you have a
few million dollars for research and development and then be able to
push all the good research upstream into the Linux kernel. Sorry. The
machine is dead weight. A room heater at best. I had one of those also.
Complete with 256G of memory and the top of the line processors. Trash.
Useless.
Sadly the Fujitsu M3000 SPARC64 VII+ does bad things after we see GRUB :
(1) from the expert install option
Loading ...
ERROR: Last Trap: Division by Zero
%TL:1 %TT:28 %TPC:10abf30 %TnPC:10abf34 %TSTATE:4480001604
%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )
(2) from the default install option
Loading ...
ERROR: Last Trap: Division by Zero
%TL:1 %TT:28 %TPC:10abf30 %TnPC:10abf34 %TSTATE:4480001604
%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )
{0} ok
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
Four decades in production systems.
Re: Updated installation images for Debian Ports 2023-06-06
On 6/7/23 04:03, John Paul Adrian Glaubitz wrote: On Wed, 2023-06-07 at 03:36 -0400, Dennis Clarke wrote: One of the first things I plan on doing is a bootstrap of GCC 13.x and then also binutils ( maybe? maybe not? ) and of course a kernel. That will keep the machine thrashing for at least a week. With Gentoo I saw an update time of the machine take well over 190 hours. Awesome throughput with plenty of swap needed. You should run the GCC testsuite which really tortures the hardware. Btw, I had a quick glimpse through your video and saw that you were confused by the kernel used by the installer which is still at 6.1.x. The 6.3.x kernels are part of experimental only at the moment since Debian Bookworm is going to be released with a 6.1.x kernel which is an LTS kernel. Since debian-installer images are always built from unstable, the installer is currently stuck at kernel 6.1.x but you can install the experimental kernel using this sources.list [1] afterwards with: # apt install linux-image-sparc64-smp -t=experimental Adrian You're timing is excellent! I was just looking at : root@nix:~# cat /proc/version Linux version 6.1.0-9-sparc64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-12) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 Debian 6.1.27-1 (2023-05-08) root@nix:~# Which, yes, confused me somewhat. Regardless I will not need the SMP kernel on this old machine. I will use precisely what I see at : https://people.debian.org/~glaubitz/sources.list.experimental Then try : root@nix:~# root@nix:~# root@nix:~# apt-get update Get:1 http://ftp.ports.debian.org/debian-ports unstable InRelease [107 kB] Get:2 http://ftp.debian.org/debian unstable InRelease [195 kB] Get:3 http://ftp.debian.org/debian experimental InRelease [101 kB] Get:4 http://incoming.debian.org/debian-buildd buildd-unstable InRelease [53.7 kB] Get:5 http://ftp.ports.debian.org/debian-ports unreleased InRelease [71.8 kB] Get:6 http://incoming.debian.org/debian-buildd buildd-experimental InRelease [53.8 kB] Get:7 http://ftp.ports.debian.org/debian-ports experimental InRelease [107 kB] Get:8 http://incoming.ports.debian.org/buildd unstable InRelease [65.3 kB] Get:9 http://ftp.debian.org/debian unstable/main Sources [10.1 MB] Get:10 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 Packages [23.4 MB] Get:11 http://ftp.debian.org/debian experimental/main Sources [796 kB] Get:12 http://ftp.ports.debian.org/debian-ports unreleased/main sparc64 Packages [14.8 kB] Get:13 http://incoming.debian.org/debian-buildd buildd-unstable/main Sources [23.1 kB] Get:14 http://incoming.debian.org/debian-buildd buildd-experimental/main Sources [14.6 kB] Get:15 http://ftp.ports.debian.org/debian-ports experimental/main sparc64 Packages [1819 kB] Get:16 http://incoming.ports.debian.org/buildd unstable/main sparc64 Packages [37.2 kB] Fetched 37.0 MB in 1min 36s (384 kB/s) Reading package lists... Done root@nix:~# apt install linux-image-sparc64-smp -t=experimental Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: apparmor firmware-linux-free linux-image-6.3.0-0-sparc64 linux-image-6.3.0-0-sparc64-smp linux-image-sparc64 Suggested packages: apparmor-profiles-extra apparmor-utils linux-doc-6.3 debian-kernel-handbook fdutils The following NEW packages will be installed: apparmor firmware-linux-free linux-image-6.3.0-0-sparc64 linux-image-6.3.0-0-sparc64-smp linux-image-sparc64-smp The following packages will be upgraded: linux-image-sparc64 1 upgraded, 5 newly installed, 0 to remove and 50 not upgraded. Need to get 73.4 MB of archives. After this operation, 411 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 apparmor sparc64 3.0.8-3 [536 kB] Get:2 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 firmware-linux-free all 20200122-1 [24.2 kB] Get:3 http://ftp.ports.debian.org/debian-ports experimental/main sparc64 linux-image-6.3.0-0-sparc64 sparc64 6.3.5-1~exp1 [36.1 MB] Get:4 http://ftp.ports.debian.org/debian-ports experimental/main sparc64 linux-image-6.3.0-0-sparc64-smp sparc64 6.3.5-1~exp1 [36.7 MB] Get:5 http://ftp.ports.debian.org/debian-ports experimental/main sparc64 linux-image-sparc64 sparc64 6.3.5-1~exp1 [1412 B] Get:6 http://ftp.ports.debian.org/debian-ports experimental/main sparc64 linux-image-sparc64-smp sparc64 6.3.5-1~exp1 [1432 B] Fetched 73.4 MB in 35s (2113 kB/s) Reading changelogs... Done Preconfiguring packages ... Selecting previously unselected package apparmor. (Reading database ... 25465 files and directories currently installed.) Preparing to unpack .../0-apparmor_3.0.8-3_sparc64.deb ... Unpacking apparmor (3.0.8-3) ... Selecting previously unselected package firmware-linux-free. Preparing to unpack .../1-firmware-linux-free_20200122
Re: Updated installation images for Debian Ports 2023-06-06
On 6/7/23 03:03, John Paul Adrian Glaubitz wrote: Hi Dennis! . . . Sadly this machine seems to be nothing but a fancy brick with 64G of expensive ECC memory etc etc. I don't think the Fujitsu SPARC64 CPUs were ever officially supported by the Linux kernel, were they? Probably not going to happen in the future either. Someone pointed out to me that the problem was seen back in 2017 : https://oss.oracle.com/pipermail/linux-sparc-users/2017-October/29.html So looks like no joy with Linux ever. However my other sparcv9 machines may be perfectly fine. I will be doing tests. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC Four decades in production systems.
Re: Updated installation images for Debian Ports 2023-06-06
On 6/7/23 03:17, John Paul Adrian Glaubitz wrote: Hi! On Wed, 2023-06-07 at 03:10 -0400, Dennis Clarke wrote: Sadly the machine isa bit of a brick. Maybe NetBSD works? No idea. However a much older and smaller UltraSPARC IIi Netra seems to be working just perfect. I am doing the install now, live, streaming on YouTube. To say the least it is a slow and boring stream :) But it works ! That's good to hear. You should run some CPU-intensive code on the machine once it's installed to see how reliable the current kernel is. Also, try kernel 6.3 from experimental. Adrian One of the first things I plan on doing is a bootstrap of GCC 13.x and then also binutils ( maybe? maybe not? ) and of course a kernel. That will keep the machine thrashing for at least a week. With Gentoo I saw an update time of the machine take well over 190 hours. Awesome throughput with plenty of swap needed. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC Four decades in production systems.
Re: Updated installation images for Debian Ports 2023-06-06
On 6/7/23 03:03, John Paul Adrian Glaubitz wrote: Hi Dennis! Good day Sir ! Sadly the Fujitsu M3000 SPARC64 VII+ does bad things after we see GRUB : (...) Sadly this machine seems to be nothing but a fancy brick with 64G of expensive ECC memory etc etc. I don't think the Fujitsu SPARC64 CPUs were ever officially supported by the Linux kernel, were they? Probably not going to happen in the future either. Sadly the machine isa bit of a brick. Maybe NetBSD works? No idea. However a much older and smaller UltraSPARC IIi Netra seems to be working just perfect. I am doing the install now, live, streaming on YouTube. To say the least it is a slow and boring stream :) But it works ! -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC Four decades in production systems.
Re: Updated installation images for Debian Ports 2023-06-06
On 6/6/23 09:52, John Paul Adrian Glaubitz wrote:
Hello!
I have created updated installation images for Debian Ports.
These can be found here:
- https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/
I have already successfully tested the sparc64 installer.
Sadly the Fujitsu M3000 SPARC64 VII+ does bad things after we see GRUB :
(1) from the expert install option
Loading ...
ERROR: Last Trap: Division by Zero
%TL:1 %TT:28 %TPC:10abf30 %TnPC:10abf34 %TSTATE:4480001604
%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )
(2) from the default install option
Loading ...
ERROR: Last Trap: Division by Zero
%TL:1 %TT:28 %TPC:10abf30 %TnPC:10abf34 %TSTATE:4480001604
%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )
{0} ok
Sadly this machine seems to be nothing but a fancy brick with 64G of
expensive ECC memory etc etc.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
Four decades in production systems.
Re: Updated installation images for Debian Ports 2023-06-06
On 6/6/23 09:52, John Paul Adrian Glaubitz wrote: Hello! I have created updated installation images for Debian Ports. These can be found here: - https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/ I have already successfully tested the sparc64 installer. I am going to try the process on the Fujitsu SPARC64 M3000 unit and even stream it live on YouTube just to have witnesses see how it all goes up in flames. https://www.youtube.com/@lastmiles/streams -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC Four decades in production systems.
Re: Current kernels run stable on older SPARC systems
On 6/5/23 06:02, John Paul Adrian Glaubitz wrote: Hello! I have updated the UltraSPARC IIIi to kernel 6.3 from experimental and it has been running very stable for almost a week now despite the server being run as a CI machine for the Free Pascal Compiler. So, it seems the Linux kernel is finally usable on older SPARC systems again. I'm curious to hear if anyone can confirm this on their own machines. I shall fire up a machine and give this a test. I think that I had serious problems in the past with two different Netra class servers. In fact, I need to check if the processors are UltraSPARC II or IIi or anything close to a III or IIIi. I do have a Fujitsu SPARC64 server but that thing seems to be unable to boot/run anything other than Solaris 10 or perhaps 11.3. I should give it a test with the latest updated install images you have built. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC Four decades in production systems.
Re: Debian SID on Ultra 30
On 3/28/23 18:50, Stan Johnson wrote: "Fast Data Access MMU Miss" Power down the machine to the firmware ok prompt. You should be able to do that with : shutdown -Hh 'now' The capital " H " should just halt the linux os and leave you as the prompt. Then do this : setenv diag-switch? true setenv auto-boot? false setenv verbosity max Then do printenv and check if the diagnostics verbosity is actually set to maximum. On the old Ultra 30 it may be named something else. Then issue the golden "power-off". Unplug it from the AC power. Go get a coffee. Then power on the unit and watch all the diagnostics happen. I do not recall the specifics of the Ultra 30 but if you issue this to the forth ok prompt : sifting post You will get a list of commands related to POST status. One of tham may actually be post-results or post-status. Issue that command. If the result looks sane then "setenv diag-switch? false" and boot the system as per normal. Just my thoughts from the distant memories. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Anyone ever tried Debian on a Fujitsu/Oracle M3000 ?
On 5/16/22 04:01, John Paul Adrian Glaubitz wrote: Hi Dennis! On 5/16/22 03:58, Dennis Clarke wrote: The last update released for 11.3 is called "Oracle Solaris 11.3 Limited Support Updates (LSRU) 11.3.36.24.0" and can be found on some torrent sites. I have 11.3 but need an Oracle contract to get much of anything done. No, you don't. You download the update - which is 20 GB in size Really? An update from somewhere eh ? Paying Oracle customers don't get anything more recent either unless you have an extra LTSS support contract which costs a lot of money. Yeah .. I had that. Nope. Not any longer. I have used the 11.3 LRU update on my SPARC T5240 without any issues. Well, as I said, I have 11.3 on the M3000 brick now. For Solaris 11.4, you can just install the CBE version which has full access to update repositories for free. Does not work on anything previous to a T4. At all. Period. Will not install and detects unsupported hardware. The Lawnmower strikes again. I didn't claim otherwise. I just said that Oracle is kind enough Oh please .. words never spoken nor written before just appeared. Dennis
Re: Anyone ever tried Debian on a Fujitsu/Oracle M3000 ?
On 5/15/22 18:18, John Paul Adrian Glaubitz wrote: Hi! On 5/16/22 00:15, Chris Quayle wrote: It is a damn good machine. However it can *only* run Solaris 10 or maybe Solaris 11.3 and in both cases you need an Oracle contract. Otherwise good luck getting updates or access to the IPS repo. Never bothered about updates, but what is the IPS repo ?. Could we have a group buy for, say a V120 and share ?. Depends on the cost I' guess. The last update released for 11.3 is called "Oracle Solaris 11.3 Limited Support Updates (LSRU) 11.3.36.24.0" and can be found on some torrent sites. I have 11.3 but need an Oracle contract to get much of anything done. For Solaris 11.4, you can just install the CBE version which has full access to update repositories for free. Does not work on anything previous to a T4. At all. Period. Will not install and detects unsupported hardware. The Lawnmower strikes again. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Anyone ever tried Debian on a Fujitsu/Oracle M3000 ?
On 5/15/22 14:58, Chris Quayle wrote: On 05/15/22 15:57, Chris Newport wrote: On 15/05/2022 14:52, Dennis Clarke wrote: On 5/14/22 17:52, Rick Leir wrote: From folks who have tried? Sorry, no. If the info below is not helpful, sorry and please just delete my message. Is illumos or SmartOS an option? Info from Bryan Cantrill: http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/ Following a few links from that article to https://illumos.org/docs/about/distro/ , I see that derived systems claim to have SPARC builds: Tribblix, DilOS, and V9os. cheers -- Rick Yep .. been there and read that. Even if any of those did work at all we are going in a circle and landing back on some Solaris thing. That is not really of any value any more. It is beginning to sound a lot like Oracle sold a whack of machines to people about ten years ago and they are all dead pieces of trash and junk today. Nothing runs there any more. They should still run just fine on older versions of Solaris (8 or 10 ?) and similar aged Debian and BSD variants. Not trash, just stuck in their own time. I have customers still running Ultra 60s and a few still on ancient stuff running SunOs 4.1.4, they still run the tasks they were bought for and will be replaced with modern kit when they finally die. The killer will be the SCSI disks. Been running Solaris 10 on an M3000 for 5 or 6 years now, for the home lab server. Has a perfectly usable desktop with the addition of an XVR300 graphics card and a pcie usb card, as the usb on the M3k is not reachable from the host os. Forget the make, but just looked for a usb card with a chipset supported under the sol 10 hcl. Damn good machine and faster than any other Spparc ever run here... It is a damn good machine. However it can *only* run Solaris 10 or maybe Solaris 11.3 and in both cases you need an Oracle contract. Otherwise good luck getting updates or access to the IPS repo. As I keep saying over and over and over I wanted to run Linux on it. Solaris was taken out behind a chemical shed and killed five years ago and yes Bryan Cantrill would know the truth : http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/ Speaking as someone that was on the OpenSolaris governance board there was nothing but deathly silence right up until the Lawnmower man pulled the plug one night. No discussion. Just silence. Dennis Clarke
Re: Anyone ever tried Debian on a Fujitsu/Oracle M3000 ?
On 5/15/22 16:43, John Paul Adrian Glaubitz wrote: Hi! On 5/15/22 15:52, Dennis Clarke wrote: Yep .. been there and read that. Even if any of those did work at all we are going in a circle and landing back on some Solaris thing. That is not really of any value any more. It is beginning to sound a lot like Oracle sold a whack of machines to people about ten years ago and they are all dead pieces of trash and junk today. Nothing runs there any more. FWIW, Oracle has released a community version of Solaris called "CBE" [1] which runs on any SPARC-T4 or newer machine. So, if you want to run a current version of Solaris, you can do that with a used T4 off eBay. Adrian Yep. I have a friend that is doing that but there is no joy in it. I think the real issue for me is that the M3000 is a brick. A 64G ECC memory brick with 15k rpm SAS disks in it. Sad. -- Dennis Clarke RISC-V/SPARC^H^H^H^H^H/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Anyone ever tried Debian on a Fujitsu/Oracle M3000 ?
On 5/14/22 17:52, Rick Leir wrote: From folks who have tried? Sorry, no. If the info below is not helpful, sorry and please just delete my message. Is illumos or SmartOS an option? Info from Bryan Cantrill: http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/ Following a few links from that article to https://illumos.org/docs/about/distro/ , I see that derived systems claim to have SPARC builds: Tribblix, DilOS, and V9os. cheers -- Rick Yep .. been there and read that. Even if any of those did work at all we are going in a circle and landing back on some Solaris thing. That is not really of any value any more. It is beginning to sound a lot like Oracle sold a whack of machines to people about ten years ago and they are all dead pieces of trash and junk today. Nothing runs there any more. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Anyone ever tried Debian on a Fujitsu/Oracle M3000 ?
I haven't this kind of server, but some others Sparc64. OpenBSD and NetBSD don't run on M3000. You can test FreeBSD that supported some SPARC64, but... "UltraSPARC is a Tier 2 architecture through FreeBSD 12.x. It is no longer supported in FreeBSD 13.0 and later." Best regards, JKB The FreeBSD folks have been perfectly clear that sparc is dead to them. So no. Anyways I was curious about the Debian port. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Anyone ever tried Debian on a Fujitsu/Oracle M3000 ?
Somewhat annoyed by reality but I have to ask. [ here you need to hear a long whine noise like metal failing ] I have a Fujitsu/Oracle M3000 brick sitting in my world and near as I can tell it runs nothing other than Oracle Solaris 11.3 and will never be able to run anything else. Not even the "free to download" Oracle Solaris 11.4 because the Lawnmower killed all sparc support for all sparc hardware other than a T4 and upwards. For now anyways. [ end of high pitch whine ] Thus with 64G of ECC memory and four very expensive 15k rpm SAS disks the thing is a brick. Or is it ? Is there any reasonable way to : [A] netboot Debian [B] toss it on a scrap heap for re-cycle Would love to hear any input from folks who have tried. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
sparc64 kernel bug
Time for a better subject line. Therefore here we are.
original message
Message-ID:
Date: Mon, 4 Apr 2022 00:00:41 +0200
Subject: Re: nasty bug in /usr/sbin/grub-probe
In-Reply-To:
Resent-Date: Sun, 3 Apr 2022 22:01:00 + (UTC)
On 4/3/22 23:54, Dennis Clarke wrote:
> No, I am not. I am going with whatever is in the Makefile.
>
>
https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3
>
> So this was seen before regardless.
Please just follow my advise and use Linus' tree and don't use any LTS
kernels
which may have some changes from the latest kernels backported.
I know that cross-compiling and bisecting works 100%, so we really don't
need to
argue about this. You didn't find some hidden bug that the daily CI
hasn't caught.
The kernel developers are regularly rebuilding the kernel for most
targets with
all the various standard kernel configuration presets, so it's extremely
unlikely
that you run a kernel that won't compile due to a bug.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
- end of original message -
I don't see any reasonable way to do this other than using a cross build
on some reasonably fast AMD64 boxen. That means I will need the sparc64
binutils as well as who knows what else. Certainly a GCC cross compiler
and maybe other tools. This is not exactly something I do on any given
Sunday. However I am game to try.
I can checkout the Linux ( Linus ) tree well enough but picking a tag
where things worked? That is a blind guess at best. I would need to
compile the kernel with a limited set of modules selected and then
create the initrd and vmlinuz files to drop into /boot on the target
machine. So that means digging into initramfs-tools as well as the
snazzy usr/gen_init_cpio tool[1] with its file format goodness. None
of this stuff is well documented ( at least not at kernel.org ) where
I see pages of stuff from twenty years ago or more.
I am even wondering if I can netboot the target machine? That would
save me the hassle of creating initrd/vmlinuz files over and over with
a hacked /boot/grub/grub.cfg file. Given that I can not run update-grub
there is no other way than to manually edit the file. I may do a netboot
test just to see what happens with the netinst file from 28th March.
Dennis Clarke
[1] The cpio created and then compressed initramfs/initrd file seems
to have documentation from twenty years ago or more :
https://www.kernel.org/doc/html/latest/driver-api/early-userspace/buffer-format.html
https://www.kernel.org/doc/html/latest/driver-api/early-userspace/early_userspace_support.html
Within the Linux 5.17.1 stable tree I see this :
hades# file usr/gen_init_cpio
usr/gen_init_cpio: ELF 64-bit MSB pie executable, SPARC V9, relaxed
memory ordering, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux.so.2,
BuildID[sha1]=2279f500e2a81d6211820c85283ce73ed44471ab, for GNU/Linux
3.2.0, not stripped
hades#
hades# usr/gen_init_cpio
Usage:
usr/gen_init_cpio [-t ]
is a file containing newline separated entries that
describe the files to be included in the initramfs archive:
# a comment
file []
dir
nod
slink
pipe
sock
name of the file/dir/nod/etc in the archive
location of the file in the current filesystem
expands shell variables quoted with ${}
link target
mode/permissions of the file
user id (0=root)
group id (0=root)
device type (b=block, c=character)
major number of nod
minor number of nod
space separated list of other links to file
example:
# A simple initramfs
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
dir /root 0700 0 0
dir /sbin 0755 0 0
file /sbin/kinit /usr/src/klibc/kinit/kinit 0755 0 0
is time in seconds since Epoch that will be used
as mtime for symlinks, special files and directories. The default
is to use the current time for these entries.
hades#
Re: nasty bug in /usr/sbin/grub-probe
On 4/3/22 12:13, John Paul Adrian Glaubitz wrote:
On 4/3/22 17:19, Dennis Clarke wrote:
I am curious if you can get the linux-4.19.114 kernel to compile. For me it
just blows up with :
.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more bytes from
a region of size 0 [-Werror=stringop-overread]
648 | if (!strcmp(names + ep[ret].name_offset, name))
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc'
of size 16
78 | struct mdesc_hdrmdesc;
| ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more bytes from
a region of size 0 [-Werror=stringop-overread]
693 | if (!strcmp(names + ep->name_offset, name)) {
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc'
of size 16
78 | struct mdesc_hdrmdesc;
| ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more bytes from
a region of size 0 [-Werror=stringop-overread]
720 | if (strcmp(names + ep->name_offset, arc_type))
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object 'mdesc'
of size 16
78 | struct mdesc_hdrmdesc;
| ^
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] Error 1
make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2
Not sure what to make of that.
Well, it's up right there, you are building with -Werror enabled. You have to
disable that.
No, I am not. I am going with whatever is in the Makefile.
https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3
So this was seen before regardless.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Re: nasty bug in /usr/sbin/grub-probe
I am curious if you can get the linux-4.19.114 kernel to compile. For
me it just blows up with :
.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
648 | if (!strcmp(names + ep[ret].name_offset, name))
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
693 | if (!strcmp(names + ep->name_offset, name)) {
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
720 | if (strcmp(names + ep->name_offset, arc_type))
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdr mdesc;
| ^
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o]
Error 1
make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2
Not sure what to make of that.
Drat :
https://github.com/torvalds/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3
So something after 4.19.114 may work.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Re: nasty bug in /usr/sbin/grub-probe
On 4/3/22 10:39, Stan Johnson wrote:
Hello Adrian and Dennis,
If this problem is expected to occur on an Ultra 5 or an Ultra 30,
please let me know and I'll be happy to help with a git bisect, using a
spare 9 GB disk for the installation.
The Ultra 5 is even older. At least I think so. There were two flavours
of those bizarre PC style machines where one was a tower looking thing
called the Ultra 10 and it could have a Creator3D OpenGL hardware frame
buffer whereas the Ultra 5 was a modified weird pizza box thing. Both
are from well before the UltraSparc III existed.
Please feel free to jump in.
I am curious if you can get the linux-4.19.114 kernel to compile. For
me it just blows up with :
.
.
.
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:648:22: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
648 | if (!strcmp(names + ep[ret].name_offset, name))
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdrmdesc;
| ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:693:22: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
693 | if (!strcmp(names + ep->name_offset, name)) {
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdrmdesc;
| ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:720:21: error: 'strcmp' reading 1 or more
bytes from a region of size 0 [-Werror=stringop-overread]
720 | if (strcmp(names + ep->name_offset, arc_type))
| ^
arch/sparc/kernel/mdesc.c:78:33: note: at offset 16 into source object
'mdesc' of size 16
78 | struct mdesc_hdrmdesc;
| ^
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:304: arch/sparc/kernel/mdesc.o] Error 1
make[1]: *** [scripts/Makefile.build:544: arch/sparc/kernel] Error 2
make: *** [Makefile:1053: arch/sparc] Error 2
Not sure what to make of that.
My intuition here tells me the bug is likely in
arch/sparc/kernel/syscalls.S which changed slightly since the 4.19.114
days. Looking
previous I see no change in that source file. Regardless, this is just a
hunch without a shred of proof. Yet.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Re: nasty bug in /usr/sbin/grub-probe
On 4/3/22 07:57, John Paul Adrian Glaubitz wrote: Hello! On 4/3/22 13:42, Dennis Clarke wrote: But since you seem to have a reliable reproducer, you can start trying to bisect the kernel to find the commit that introduced this regression. That will be nearly impossible. I can not even recall when the bug first appeared or when was the last time that I could run update-grub without the machine locking up. At least two years now. Maybe three. What do you mean is impossible? Bisecting the bug or the fact that it is a kernel bug? I know very well it's a kernel bug because it does not occur when using the 4.19 kernel on any of the affected SPARCs and it does not occur on any of the newer SPARCs with a current kernel. Are you sure of 4.19 ? I see that 4.19.237 exists but I will guess the same bug exists there also. I was going to begin with 4.19.114 which was released 02-Apr-2020. A solid two years ago seems like as good a place to start as any. However building the kernel will require that I create an initrd and also update grub etc etc. I can do that manually and then bypass the "update-grub" process entirely. The SPARC T2 and T5 we are using don't have the problem at all, for example. Also this is an even older UltraSparc IIi type machine. Really I should have tossed it out long ago but the next machine I have handy is a Fujitsu M3000 unit and I thought I had heard it was impossible to get Linux on such a beast for unknown reasons. Could be myth or rumour but I thought the M3000 was somehow "special". The larger M4000 seems to be fine but those are just nasty large beasts to run in a home lab. Dragging the deep waters looking for that kernel bug will take a lot of time. Possibly even some luck. Not really. You cross-build the kernel, transfer it to the machine and see if update-grub works. Hold on. This sounds like a chicken and egg scenario. The update-grub will fail every time. I will need to do the process by hand with an edit to grub.cfg and with the files needed dropped into /boot with the few kernel modules needed in /lib/modules/foo. That should be enough to at least boot. But I can do it myself if I find the time, I have an Ultra 45 that can be used for that. Thought it would just be nice if I can get a helping hand, especially since cross-compiling and bisecting the kernel isn't really hard, it just takes time. Right. The one thing that no one can save or store or get more. Time. I have already started the process but I am starting with 4.19.114. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: nasty bug in /usr/sbin/grub-probe
On 4/2/22 03:30, John Paul Adrian Glaubitz wrote: Hello Dennis! On 4/2/22 03:34, Dennis Clarke wrote: I am not so sure about this yet until I can rebuild the required grub binaries with full debug info. For at least a year ( or more ) I have seen "really bad things"(tm) happen when I try to make a new initrd on sparc64. Generally the machine seems to pack up and go away with nary a single packet out to the world. To look into this problem I use a serial attached good old 9600 baud console and watch what happens when I try to do a make install from within the Linux source tree : (...) So therefore I think that there is a bug in /usr/sbin/grub-probe and it really kills the whole "make install" process from within the Linux kernel source tree or any other way you choose to run it. Has anyone else seen this ? This isn't a bug in GRUB but a kernel bug that affects older SPARC machines like your UltraSPARC IIIi. Unfortunately, no one has had the time yet to bisect this issue. But since you seem to have a reliable reproducer, you can start trying to bisect the kernel to find the commit that introduced this regression. That will be nearly impossible. I can not even recall when the bug first appeared or when was the last time that I could run update-grub without the machine locking up. At least two years now. Maybe three. Also this is an even older UltraSparc IIi type machine. Really I should have tossed it out long ago but the next machine I have handy is a Fujitsu M3000 unit and I thought I had heard it was impossible to get Linux on such a beast for unknown reasons. Could be myth or rumour but I thought the M3000 was somehow "special". The larger M4000 seems to be fine but those are just nasty large beasts to run in a home lab. Dragging the deep waters looking for that kernel bug will take a lot of time. Possibly even some luck. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: nasty bug in /usr/sbin/grub-probe
scsi disk tape Probing /pci@1f,0/pci@1,1 at Device 3 network Probing /pci@1f,0/pci@1 at Device 1 pci Probing /pci@1f,0/pci@1/pci@1 at Device 0 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 1 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 2 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 3 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 4 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 5 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 6 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 7 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 8 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device 9 Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device a Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device b Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device c Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device d Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device e Nothing there Probing /pci@1f,0/pci@1/pci@1 at Device f Nothing there Netra t1 (UltraSPARC-IIi 440MHz), No Keyboard OpenBoot 3.10.27 ME, 1024 MB memory installed, Serial #12731976. Ethernet address 8:0:20:c2:46:48, Host ID: 80c24648. Boot device: net File and args: Using External Transceiver - Link Up. 3a000 Server IP address: 172.16.35.58 Client IP address: 172.16.35.33 Using External Transceiver - Link Up. ramdisk-root | Well at this point the machine will try to boot the diag-device which is simply "net" and yes the machine can netboot fine. That works. I will break and stop it and then boot local linux and we get a machine with well tested ECC memory. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
nasty bug in /usr/sbin/grub-probe
d debugging using libthread_db enabled] Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1". Download failed: Function not implemented. Continuing without debug info for /lib/sparc64-linux-gnu/libpcre2-8.so.0. [16160.118042] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [grub-probe:422] [16160.213138] Modules linked in: sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E) scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E) [16160.652768] CPU: 0 PID: 422 Comm: grub-probe Tainted: GE 5.16.0-6-sparc64 #1 Debian 5.16.18-1 [16160.784374] TSTATE: 009911001602 TPC: 009555c0 TNPC: 009555c4 Y: Tainted: GE [16160.932019] TPC: [16160.982440] g0: g1: 10074848 g2: g3: 0745f218 [16161.096924] g4: f870b780 g5: 6247619b g6: f8000727 g7: 00a2db10 [16161.211402] o0: 00fa7a08 o1: f800072738ec o2: f82f63d0 o3: 0001 [16161.325882] o4: f88db6a0 o5: sp: f80007272f81 ret_pc: 009555a0 [16161.444935] RPC: [16161.495359] l0: f81b8000 l1: 00fa7800 l2: 00685d20 l3: 0006b480d616 [16161.609863] l4: 0470 l5: ff9c l6: f8000727 l7: 0067e1a0 [16161.724329] i0: f88db6a0 i1: f80004829ce0 i2: 00fa7800 i3: 00fa7a20 [16161.838808] i4: 00ec i5: 10074830 i6: f80007273031 i7: 00686958 [16161.953287] I7: [16162.004852] Call Trace: [16162.036979] [<00686958>] chrdev_open+0x98/0x1c0 [16162.105711] [<0067bef0>] do_dentry_open+0x170/0x420 [16162.179015] [<0067da08>] vfs_open+0x28/0x40 [16162.243168] [<00693500>] path_openat+0xb20/0x10e0 [16162.314185] [<006948c0>] do_filp_open+0x60/0x100 [16162.384057] [<0067dcf0>] do_sys_openat2+0x70/0x180 [16162.456217] [<0067e1e8>] sys_openat+0x48/0xc0 [16162.522657] [<00406174>] linux_sparc_syscall+0x34/0x44 [16184.112473] watchdog: BUG: soft lockup - CPU#0 stuck for 48s! [grub-probe:422] [16184.207504] Modules linked in: sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E) scsi_transport_spi(E) scsi_mod(E) scsi_common(E) sunhme(E) [16184.647054] CPU: 0 PID: 422 Comm: grub-probe Tainted: GEL 5.16.0-6-sparc64 #1 Debian 5.16.18-1 [16184.778649] TSTATE: 009911001602 TPC: 009555c0 TNPC: 009555c4 Y: Tainted: GEL [16184.926296] TPC: [16184.976713] g0: g1: 10074848 g2: g3: 0745f218 [16185.091200] g4: f870b780 g5: 6247619b g6: f8000727 g7: 00a2db10 [16185.205678] o0: 00fa7a08 o1: f800072738ec o2: f82f63d0 o3: 0001 [16185.320157] o4: f88db6a0 o5: sp: f80007272f81 ret_pc: 009555a0 [16185.439210] RPC: [16185.489632] l0: f81b8000 l1: 00fa7800 l2: 00685d20 l3: 0006b480d616 [16185.604118] l4: 0470 l5: ff9c l6: f8000727 l7: 0067e1a0 [16185.718596] i0: f88db6a0 i1: f80004829ce0 i2: 00fa7800 i3: 00fa7a20 [16185.833075] i4: 00ec i5: 10074830 i6: f80007273031 i7: 00686958 [16185.947553] I7: [16185.999117] Call Trace: [16186.031141] [<00686958>] chrdev_open+0x98/0x1c0 [16186.099874] [<0067bef0>] do_dentry_open+0x170/0x420 [16186.173178] [<0067da08>] vfs_open+0x28/0x40 [16186.237331] [<00693500>] path_openat+0xb20/0x10e0 [16186.308347] [<006948c0>] do_filp_open+0x60/0x100 [16186.378220] [<00000067dcf0>] do_sys_openat2+0x70/0x180 [16186.450380] [<0067e1e8>] sys_openat+0x48/0xc0 [16186.516820] [<00406174>] linux_sparc_syscall+0x34/0x44 So therefore I think that there is a bug in /usr/sbin/grub-probe and it really kills the whole "make install" process from within the Linux kernel source tree or any other way you choose to run it. Has anyone else seen this ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated Debian Ports installation images 2022-03-28
On 3/31/22 14:53, Joost van Baal-Ilić wrote: Hi, On Tue, Mar 29, 2022 at 04:30:52PM -0400, Dennis Clarke wrote: On 3/29/22 15:48, Thomas Schmitt wrote: Dennis Clarke wrote: # dd if=/cdrom/test/debian_20220328/debian-11.0.0-sparc64-NETINST-1.iso of=/dev/rdsk/c0t1d0s0 bs=2048 count=189529 dd: unexpected short write, wrote 1536 bytes, expected 2048 65725+0 records in 65725+0 records out So that is strange. Perhaps the iso image file is a sparse file with a hole in it. I would really like to just serve up the installer over TFTP/BootP and get the process going. Good old NFSv3 can serve everything else. At https://www.debian.org/releases/bullseye/amd64/ch04s05.en.html there is "Preparing Files for TFTP Net Booting" in the Debian GNU/Linux Installation Guide. Wouldn't that get you going? Actually it may ... I have to test that as it would be *most* convenient. However after I see the error of my ways I hooked up an external scsi disk to my old Netra and managed to dd the netinst to that just fine. So while it may be slow it is running fine thus far : hades# uname -a Linux hades 5.16.0-6-sparc64 #1 Debian 5.16.18-1 (2022-03-29) sparc64 GNU/Linux hades# cat /proc/version Linux version 5.16.0-6-sparc64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-18) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 Debian 5.16.18-1 (2022-03-29) hades# cat /proc/cmdline BOOT_IMAGE=/vmlinux-5.16.0-6-sparc64 root=UUID=dba85bc4-a7fb-42f9-938f-908031ae6ec5 ro verbose net.ifnames=0 I use the net.ifnames=0 option there to get trivial eth0 type interface names and then modify /etc/network/interfaces as needed. hades# uptime 22:43:37 up 40 min, 1 user, load average: 0.03, 0.29, 0.41 hades# So now I am going to try to compile a custom 5.17 kernel :) -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated Debian Ports installation images 2022-03-28
On 3/29/22 15:48, Thomas Schmitt wrote: Hi, Dennis Clarke wrote: # dd if=/cdrom/test/debian_20220328/debian-11.0.0-sparc64-NETINST-1.iso of=/dev/rdsk/c0t1d0s0 bs=2048 count=189529 dd: unexpected short write, wrote 1536 bytes, expected 2048 65725+0 records in 65725+0 records out So that is strange. Perhaps the iso image file is a sparse file with a hole in it. Hardly. Some automat would have to have converted the file to a be sparse one. I would rather expect "short write" to be caused by the return value of a write(2) call being less than the number of submitted bytes. (It should not happen with a healthy disk device except at the very end of its capacity.) The disk address /dev/rdsk/c0t1d0s0 looks like Solaris. So it is no wonder that i fail to find the dd message in Debian's coreutils. Maybe it works better or fails with other diagnostic messages if you use bs=512 and adjust or omit the count= argument. Have a nice day :) Trying. I did try bs=512 and yes the box was running Solaris at the time. There is no OS on the netra at all so I have to network boot from somewhere to get a workable shell prompt. It is trivial to netboot Solaris 10 onto an old netra. So I do that. Then I can run "format -e" and label the two disks in the machine as typical disks. The device path /dev/rdsk/c_etc is just the controller and the scsi id data for the drive. Nothing fancy and it generally just works. At least in the past. I have swapped out a disk already and I see the exact same error from "dd" regardless. Now I am trying more stringent methods. I would really like to just serve up the installer over TFTP/BootP and get the process going. Good old NFSv3 can serve everything else. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ps: there is no way to boot USB nor a CDROM at all.
Updated Debian Ports installation images 2022-03-28
Progress is very slow, if at all. For reasons that elude me I have been unable to dump the install image to a secondary scsi disk with dd. Every time I try I get told some bad things : # dd if=/cdrom/test/debian_20220328/debian-11.0.0-sparc64-NETINST-1.iso of=/dev/rdsk/c0t1d0s0 bs=2048 count=189529 dd: unexpected short write, wrote 1536 bytes, expected 2048 65725+0 records in 65725+0 records out # So that is strange. Perhaps the iso image file is a sparse file with a hole in it. I doubt that but I will try another method and see what happens. Really the only way I have been able to do this in the past was to dd the netinst image to a scsi disk and then boot that disk. When I get asked where the install media is within the installer I simply point to a scsi cdrom which *is* the second scsi disk. Now if I could netboot this thing .. that would be great. Network boot and serve up the netinst installer image. How cool would that be? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Booting a T5140 panics
On 11/15/21 22:19, Rich wrote: > Hi all, > So, I came into possession of a T5140, and logically decided to try > booting Debian on it. > Wish I could help. I just wanted to say WELL DONE ! I have a Netra sparc unit that seems to run Debian just fine unless I try to do update-grub where it just panics. I am going to try, next week?, to boot a Fujitsu/Oracle M4000 unit that is laying around in my life. Should be a right royal disaster but I will certainly report progress. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated Debian Ports installation images 2021-09-23
> Finally got a chance to test this more thoroughly. It turns out that > the install is failing because of my odd install method (dump the > install image on the disk, boot on it, overwrite the install media > with the install). > That is the only method I have seen work with older sparc netra gear. I just tested the SPARC64 install image and it works wonderfully. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Debian Installation on Ultra 30 (was Re: Updated Debian Ports installation images 2021-09-23)
On 9/27/21 03:56, hermann.la...@uni-heidelberg.de wrote: > Hi Stan, > > On Sat, Sep 25, 2021 at 11:34:59PM -0600, Stan Johnson wrote: >> Not knowing what the preferred size should be for a GRUB /boot >> partition, I decided to let Guided Partioning use its defaults for >> /dev/sda. As I recall, the partitioner warned that the number of >> cylinders on the disk exceeded the maximum of 65536, but the creation of >> filesystems and the rest of the installation proceeded anyway, without >> any other noticeable errors. >> >> The layout for /dev/sda is as follows: >> >> # fdisk -l /dev/sda >> Disk /dev/sda: 136.73 GiB, 146815737856 bytes, 286749488 sectors >> Disk model: ST3146807LC >> Geometry: 255 heads, 2 sectors/track, 37965 cylinders >> Units: sectors of 1 * 512 = 512 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disklabel type: sun >> >> Device Start End Sectors Size Id Type Flags >> /dev/sda1 0 1000109 1000110 488.3M 1 Boot >> /dev/sda21000110 284748299 283748190 135.3G 83 Linux native >> /dev/sda3 0 286749029 286749030 136.7G 5 Whole disk >> /dev/sda4 284748300 286749029 2000730 976.9M 82 Linux swap > > this is a sun disk partitioning scheme - not shure, if this is well supported > with grub. > >> -> Question 1: If I don't plan to install Solaris, is it safe to remove >> the "Whole disk" partition (/dev/sda3)? > > AFAIR sun disklabels allows up to 8 entries - so there is no advantage in > removing the solaris standard whole disk entry. > I have had no issues with GRUB and Sun type disk labels and "vtoc" data. Also there are four bits used to count the disk "slices" but it depends on if one is on Sparc or x86 to get all four bits. So really one may have 16 separate entries in the disk vtoc but it won't be portable across architectures. I don't even know if that was ever documented. I have not even tried that for a few decades. I am quite sure that one may have eight disk regions without issue and they may overlap one another. That results in the old "backup" slice. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Update Debian Ports installation images 2021-04-14
On 4/19/21 08:31, John Paul Adrian Glaubitz wrote: > On 4/19/21 2:13 PM, Dennis Clarke wrote: >> I have done some testing with an old Netra server and everything seems >> fine with the exception of gdb which is broken. Seems to be fixed for >> the gdb 10.2 release which is coming any day real soon now : >> >> Bug 27750 - local variables have wrong address and values on sparc64 >> https://sourceware.org/bugzilla/show_bug.cgi?id=27750 >> >> Otherwise the basics all seem fine. > > Thanks for reporting this. gdb has also has the issue that one of the tests > of the testsuite kills the whole machine [1]. > > Adrian > >> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=26170 > Seems that we have a new release : https://sourceware.org/pipermail/gdb/2021-April/049400.html So maybe it even works. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Update Debian Ports installation images 2021-04-14
On 4/14/21 5:07 PM, John Paul Adrian Glaubitz wrote: > Hello! > > I just uploaded updated Debian Ports installation images that were > created today and ship with the latest Debian unstable kernel (5.10) > and all other packages updated to their latest version in Debian > unstable. > > If you test these images, please let me know if you run into any issues. > > Adrian > >> [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-14/ > I have done some testing with an old Netra server and everything seems fine with the exception of gdb which is broken. Seems to be fixed for the gdb 10.2 release which is coming any day real soon now : Bug 27750 - local variables have wrong address and values on sparc64 https://sourceware.org/bugzilla/show_bug.cgi?id=27750 Otherwise the basics all seem fine. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup
On 3/15/21 9:38 AM, John Paul Adrian Glaubitz wrote: > Hello! > > On 3/15/21 10:34 AM, Anatoly Pugachev wrote: >>> + /usr/sbin/grub-probe --target=device / >>> + GRUB_DEVICE=/dev/sda2 >>> + /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid >>> [ 1330.951329] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! >>> [grub-probe:443] >>> [ 1331.046350] Modules linked in: drm(E) drm_panel_orientation_quirks(E) >>> i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E) >>> ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) >>> crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) st(E) >>> crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E) >>> scsi_transport_spi(E) scsi_mod(E) sunhme(E) >>> [ 1331.475596] CPU: 0 PID: 443 Comm: grub-probe Tainted: GE >>> 5.10.0-4-sparc64 #1 Debian 5.10.19-1 >>> [ 1331.606055] TSTATE: 009911001601 TPC: 00950920 TNPC: >>> 00950924 Y: Tainted: GE >>> [ 1331.753728] TPC: >>> [ 1331.804124] g0: f800065e3140 g1: 1005a830 g2: >>> g3: 0149fa90 >>> [ 1331.918504] g4: f80009bde780 g5: 604a4edc g6: >>> f8000a1ac000 g7: 0fa664c8 >>> [ 1332.032984] o0: 00f2c960 o1: f8000a1af8ec o2: >>> f80004275b50 o3: >>> [ 1332.147464] o4: o5: sp: >>> f8000a1aef81 ret_pc: 00950900 >>> [ 1332.266539] RPC: >>> [ 1332.316950] l0: 00f2c800 l1: l2: >>> 00668200 l3: 00064b73605f >>> [ 1332.431439] l4: 0002 l5: f8000a1af8f0 l6: >>> 00e1a000 l7: 0001 >>> [ 1332.545917] i0: f8000b813d90 i1: f80009bad100 i2: >>> 00f2c800 i3: 00f2c978 >>> [ 1332.660398] i4: 00ec i5: 1005a818 i6: >>> f8000a1af031 i7: 00668e38 >>> [ 1332.774892] I7: >>> [ 1332.826436] Call Trace: >>> [ 1332.858473] [<00668e38>] chrdev_open+0x98/0x1e0 >>> [ 1332.927215] [<0065e430>] do_dentry_open+0x170/0x420 >>> [ 1333.000505] [<00660068>] vfs_open+0x28/0x40 >>> [ 1333.064670] [<00674948>] path_openat+0x988/0x1100 >>> [ 1333.135679] [<006773d0>] do_filp_open+0x50/0x100 >>> [ 1333.205549] [<00660330>] do_sys_openat2+0x70/0x180 >>> [ 1333.277710] [<00660868>] sys_openat+0x48/0xc0 >>> [ 1333.344164] [<00406174>] linux_sparc_syscall+0x34/0x44 >>> ~ >>> Type 'go' to resume >>> ok >> >> >> This kernel OOPS (backtrace) should be reported to sparclinux@ , >> linux-kernel@ (lkml) and linux-fsdevel@ (vfs) linux kernel mailing >> lists. > > It should be verified that this issue is 100% reproducible using the upstream > kernel. If, yes, Dennis should bisect the problem to find which commit intro- > duced the problem. > > Anything else won't really get us any further. > yup. This will take a pile of time. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup
While digging around here I saw that update-grub will lead to a lockup every time. So I simply changed /usr/sbin/grub-mkconfig script to allow me to see everything that happens. That gets me to : /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid which falls to pieces perfectly : root@eros:~# root@eros:~# uptime 01:09:40 up 20 min, 2 users, load average: 0.07, 0.14, 0.48 root@eros:~# /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg + prefix=/usr + exec_prefix=/usr + datarootdir=/usr/share + prefix=/usr + exec_prefix=/usr + sbindir=/usr/sbin + bindir=/usr/bin + sysconfdir=/etc + PACKAGE_NAME=GRUB + PACKAGE_VERSION=2.04-16 + host_os=linux-gnu + datadir=/usr/share + [ x = x ] + pkgdatadir=/usr/share/grub + export pkgdatadir + grub_cfg= + grub_mkconfig_dir=/etc/grub.d + basename /usr/sbin/grub-mkconfig + self=grub-mkconfig + grub_probe=/usr/sbin/grub-probe + grub_file=/usr/bin/grub-file + grub_editenv=/usr/bin/grub-editenv + grub_script_check=/usr/bin/grub-script-check + export TEXTDOMAIN=grub + export TEXTDOMAINDIR=/usr/share/locale + . /usr/share/grub/grub-mkconfig_lib + prefix=/usr + exec_prefix=/usr + datarootdir=/usr/share + datadir=/usr/share + bindir=/usr/bin + sbindir=/usr/sbin + [ x/usr/share/grub = x ] + test x/usr/sbin/grub-probe = x + test x/usr/bin/grub-file = x + test x = x + grub_mkrelpath=/usr/bin/grub-mkrelpath + which gettext + : + grub_tab= + test 2 -gt 0 + option=-o + shift + argument -o /boot/grub/grub.cfg + opt=-o + shift + test 1 -eq 0 + echo /boot/grub/grub.cfg + grub_cfg=/boot/grub/grub.cfg + shift + test 0 -gt 0 + [ x = x ] + id -u + EUID=0 + [ 0 != 0 ] + set /usr/sbin/grub-probe dummy + test -f /usr/sbin/grub-probe + : + /usr/sbin/grub-probe --target=device / + GRUB_DEVICE=/dev/sda2 + /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid [ 1330.951329] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [grub-probe:443] [ 1331.046350] Modules linked in: drm(E) drm_panel_orientation_quirks(E) i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) st(E) crct10dif_generic(E) crct10dif_common(E) sym53c8xx(E) scsi_transport_spi(E) scsi_mod(E) sunhme(E) [ 1331.475596] CPU: 0 PID: 443 Comm: grub-probe Tainted: GE 5.10.0-4-sparc64 #1 Debian 5.10.19-1 [ 1331.606055] TSTATE: 009911001601 TPC: 00950920 TNPC: 00950924 Y: Tainted: GE [ 1331.753728] TPC: [ 1331.804124] g0: f800065e3140 g1: 1005a830 g2: g3: 0149fa90 [ 1331.918504] g4: f80009bde780 g5: 604a4edc g6: f8000a1ac000 g7: 0fa664c8 [ 1332.032984] o0: 00f2c960 o1: f8000a1af8ec o2: f80004275b50 o3: [ 1332.147464] o4: o5: sp: f8000a1aef81 ret_pc: 00950900 [ 1332.266539] RPC: [ 1332.316950] l0: 00f2c800 l1: l2: 00668200 l3: 00064b73605f [ 1332.431439] l4: 0002 l5: f8000a1af8f0 l6: 00e1a000 l7: 0001 [ 1332.545917] i0: f8000b813d90 i1: f80009bad100 i2: 00f2c800 i3: 00f2c978 [ 1332.660398] i4: 00ec i5: 1005a818 i6: f8000a1af031 i7: 00668e38 [ 1332.774892] I7: [ 1332.826436] Call Trace: [ 1332.858473] [<00668e38>] chrdev_open+0x98/0x1e0 [ 1332.927215] [<0065e430>] do_dentry_open+0x170/0x420 [ 1333.000505] [<00660068>] vfs_open+0x28/0x40 [ 1333.064670] [<00674948>] path_openat+0x988/0x1100 [ 1333.135679] [<006773d0>] do_filp_open+0x50/0x100 [ 1333.205549] [<00660330>] do_sys_openat2+0x70/0x180 [ 1333.277710] [<00660868>] sys_openat+0x48/0xc0 [ 1333.344164] [<00406174>] linux_sparc_syscall+0x34/0x44 ~ Type 'go' to resume ok If I could install gdb then perhaps ... maybe ... I can see what is happening here. However that will have to wait until tomorrow or so : eros# apt-get install gdb Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gdb : Depends: libpython3.8 (>= 3.8.2) but it is not installable Recommends: libc-dbg E: Unable to correct problems, you have held broken packages. eros# I would compile my own grub-probe but at the moment I can not get a compiler installed. So I will look into this tomorrow. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]
On 3/14/21 5:52 PM, John Paul Adrian Glaubitz wrote: > On 3/14/21 6:48 PM, Frank Scheiner wrote: >>> So, if, for example, you want to verify that the memory is okay, you should >>> run >>> a memtest program. >> >> ...the built-in (memory) diagnostics of Sun machines are pretty >> thorough. This is not a PC. :-) > > I doubt that the hardware runs a thorough memory test by default that > can be compared to a full memtest86 test run. > The probability that there is a memory hardware fault after the ECC memory tests done during POST would be very very low. So close to zero that I can not even begin to guess how a memory fault would slip past those ECC diagnostics. Those run for quite a while and I have never seen evidence that there was a problem. See : https://lists.debian.org/debian-sparc/2021/03/msg00026.html Regardless we are just going in circles. I don't know if this is a kernel problem or what. I only know that something goes terribly wrong and it may be a systemd related problem. I think Frank Scheiner made some suggestions and I will go and give a try at isolating the issue. > Either way, if the kernel breaks for someone, they will have to bisect the > issue. I don't have any means in bisecting a problem if I cannot reproduce > it in the first place. > I agree completely. Dennis
Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]
On 3/13/21 5:29 PM, Mike Tremaine wrote: >> On Mar 12, 2021, at 5:56 AM, >> Dennis Clarke wrote: >> >> I have seen this for a few months now. The old old netra machine will >> run just fine endlessly but if I attempt to perform a package update >> then I am always assured to see : > What kernel are you on? Let me address that *after* we look at the hardware diagnostics. The old Netra t1 105 is pretty much indestructible with the exception being that the internal battery will die. Which mine has. However this affects nothing as the machine can be left plugged in and powered on for years and the firmware variables are trivial to setup if needed. I did do a power down and then left it cold for a day or two. That is a good way to see the full hardware diagnostics when the power plug is put back in. Thus : LOMlite console Standby lom> LOM event: LOM reset lom>poweron lom> LOM event: power on ps/2 kbd check: ...00fe LOM event: Fan 1 failed LOM event: Fault LED 3Hz Checking Sun KB Done %o0 = ..0055.4001 Executing Power On SelfTest SPARCengine(tm)Ultra CP 1500 POST 1.17 ME created 03/06/00 WARRNING: NVRAM battery is either bad or just replaced! Time Stamp [hour:min:sec] 33:30:02 Init POST BSS Init System BSS Probing system keyboard : Done DMMU TLB Tags DMMU TLB Tag Access Test DMMU TLB RAM DMMU TLB RAM Access Test Ecache Tests Probe Ecache ecache_size = 0x0020 Ecache RAM Addr Test Ecache Tag Addr Test Ecache RAM Test Ecache Tag Test Invalidate Ecache Tags All CPU Basic Tests V9 Instruction Test CPU Tick and Tick Compare Reg Test CPU Soft Trap Test CPU Softint Reg and Int Test All Basic MMU Tests DMMU Primary Context Reg Test DMMU Secondary Context Reg Test DMMU TSB Reg Test DMMU Tag Access Reg Test DMMU VA Watchpoint Reg Test DMMU PA Watchpoint Reg Test IMMU TSB Reg Test IMMU Tag Access Reg Test IMMU TLB RAM Access Test IMMU TLB Tag Access Test All Basic Cache Tests Dcache RAM Test Dcache Tag Test Icache RAM Test Icache Tag Test Icache Next Test Icache Predecode Test UltraSPARC IIi MCU Control & Status Regs Init and Tests Init UltraSPARC IIi MCU Control & Status Regs CPU speed : 440 Mhz, mc1 set : 0x544cb9dd Memory Probe and Init Probe Memory INFO: All the memory Group in 10 bit column mode Group 0: 256MB Group 1: 256MB Group 2: 256MB Group 3: 256MB Malloc Post Memory Init Post Memory .. Memory Addr w/ Ecache Map PROM/STACK/NVRAM in DMMU Load Post In Memory Run POST from MEM .. loaded POST in memory Update Master Stack/Frame Pointers All FPU Basic Tests FPU Regs Test FPU State Reg Test FPU Functional Test FPU Trap Test Memory Tests Init Memory ... Memory Addr w/ Ecache Test ECC Memory Addr Test Block Memory Addr Test Block Memory Test ... ... ECC Blk Memory Test ... ... All Basic UltraSPARC IIi PBM Tests Init UltraSPARC IIi PBM PIO Decoder and BCT Test PCI Byte Enable Test UltraSPARC IIi IOMMU Regs Test UltraSPARC IIi IOMMU RAM NTA Test UltraSPARC IIi IOMMU CAM NTA Test UltraSPARC IIi IOMMU RAM Address Test UltraSPARC IIi IOMMU CAM Address Test IOMMU TLB Compare Test IOMMU TLB Flush Test PBM Control/Status Reg Test PBM Diag Reg Test UltraSPARC IIi PBM Regs Test All Advanced CPU Tests DMMU Hit/Miss Test DMMU Little Endian Test IU ASI Access Test FPU ASI Access Test Ecache Thrash Test All CPU Error Reporting Tests CPU Addr Align Trap Test DMMU Access Priv Page Test DMMU Write Protected Page Test All Advanced UltraSPARC IIi PBM Tests Init UltraSPARC IIi PBM Consist DMA Wr, IOMMU hit Ebus Test All Basic Cheerio Tests Cheerio Ebus PCI Config Space Test Cheerio Ethern
watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]
I have seen this for a few months now. The old old netra machine will run just fine endlessly but if I attempt to perform a package update then I am always assured to see : ceres# apt-get update Get:1 http://deb.debian.org/debian-ports sid InRelease [55.3 kB] Get:2 http://deb.debian.org/debian-ports sid/main sparc64 Packages [21.6 MB] Get:3 http://deb.debian.org/debian-ports sid/main all Packages [8,682 kB] Fetched 30.3 MB in 1min 24s (361 kB/s) Reading package lists... Done ceres# Then try "upgrade" and the machine drops off the network : Setting up systemd (247.3-1) ... Timeout, server 172.16.35.61 not responding. On the serial console we see : ceres# [2968669.114937] systemd[1]: systemd 247.3-1 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD -SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified) [2968669.411163] systemd[1]: Detected architecture sparc64. [2968696.703129] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1] [2968696.794780] Modules linked in: drm(E) drm_panel_orientation_quirks(E) i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E) pata_cmd64x(E) libata(E) sym53c8xx(E) scsi_transport_spi(E) scsi_mod(E) sunhme(E) [2968697.265208] CPU: 0 PID: 1 Comm: systemd Tainted: GE 5.10.0-1-sparc64 #1 Debian 5.10.5-1 [2968697.391074] TSTATE: 11001604 TPC: 0094c4f0 TNPC: 0094c4f4 Y: Tainted: GE [2968697.541033] TPC: [2968697.593712] g0: f800065a1c80 g1: 0098 g2: g3: 0002 [2968697.710488] g4: f80004197020 g5: 00e93214 g6: f80004198000 g7: 0058 [2968697.827256] o0: 00f24960 o1: f800049ab110 o2: 0004 o3: [2968697.944022] o4: o5: sp: f8000419af81 ret_pc: 0094c4c0 [2968698.065369] RPC: [2968698.118074] l0: 00f24800 l1: f800041ce021 l2: 0003e775fef2 l3: 0003e775fef2 [2968698.234848] l4: 0002 l5: f8000419b8f0 l6: 00e12000 l7: 0001 [2968698.351615] i0: f8000b791048 i1: f800049ab100 i2: 00f24800 i3: 00f24978 [2968698.468381] i4: 00eb i5: 10040818 i6: f8000419b031 i7: 00665838 [2968698.585168] I7: [2968698.638996] Call Trace: [2968698.673323] [<00665838>] chrdev_open+0x98/0x1e0 [2968698.744355] [<0065ae30>] do_dentry_open+0x170/0x420 [2968698.819928] [<0065ca68>] vfs_open+0x28/0x40 [2968698.886379] [<00671348>] path_openat+0x988/0x1100 [2968698.959682] [<00673dd0>] do_filp_open+0x50/0x100 [2968699.031837] [<0065cd30>] do_sys_openat2+0x70/0x180 [2968699.106284] [<0065d268>] sys_openat+0x48/0xc0 [2968699.175027] [<00406174>] linux_sparc_syscall+0x34/0x44 ~ Type 'go' to resume ok ~ [EOT] This is pretty consistent behavior. If someone has any ideas that would be great. I realize that the old old Netra X1 or Netra T1 is well past its prime but it does run very stable. I would love to fire up a big Oracle M4000 unit to try but I have not heard from anyone anywhere that knows if that can work at all. So for now these old netra units are all that I can test with. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: update-grub causes a system lockup
On 1/12/21 12:47 AM, John Paul Adrian Glaubitz wrote: > On 1/12/21 1:39 AM, Dennis Clarke wrote: >> >> I made a few minor edits to /etc/default/grub and then : >> >> root@ceres:~# update-grub >> [ 303.211729] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! >> [grub-probe:261] >> [ 303.306793] Modules linked in: sg(E) envctrl(E) display7seg(E) >> flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) >> crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) >> crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E) >> pata_cmd64x(E) sym53c8xx(E) libata(E) scsi_transport_spi(E) scsi_mod(E) >> sunhme(E) >> (...) >> Also this has been happening for months. > > I would suggest installing a 4.x kernel and see if that helps. I know that > 5.x kernels can be a bit unstable on certain older SPARC machines. > > If the issue goes away with an older kernel, try bisecting to find the commit > that introduced the issue. > > Either way, it's good to have something which allows to reproduce the bug. > I was thinking that the architecture may be the issue. The age I mean. So I dragged out a newer Oracle T4 unit to try. I have no idea what will happen with the newer unit and have never tried to run the installer via the new SP/console serial interface but will give it a try. Dennis
update-grub causes a system lockup
I made a few minor edits to /etc/default/grub and then : root@ceres:~# update-grub [ 303.211729] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [grub-probe:261] [ 303.306793] Modules linked in: sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E) pata_cmd64x(E) sym53c8xx(E) libata(E) scsi_transport_spi(E) scsi_mod(E) sunhme(E) [ 303.716582] CPU: 0 PID: 261 Comm: grub-probe Tainted: GE 5.10.0-1-sparc64 #1 Debian 5.10.5-1 [ 303.845889] TSTATE: 11001606 TPC: 0094c4f0 TNPC: 0094c4f4 Y: Tainted: GE [ 303.993559] TPC: [ 304.043951] g0: f800068f5ec0 g1: 0098 g2: g3: 0196df50 [ 304.158439] g4: f8000ac388a0 g5: 5ff099f6 g6: f8000b6fc000 g7: 0ef10180 [ 304.272918] o0: 00f24960 o1: f8000b6ff8ec o2: f800042833d0 o3: [ 304.387399] o4: o5: sp: f8000b6fef81 ret_pc: 0094c4c0 [ 304.506456] RPC: [ 304.556875] l0: 00f24800 l1: l2: 00664c00 l3: 000661c58e90 [ 304.671360] l4: 0002 l5: f8000b6ff8f0 l6: 00e12000 l7: 0001 [ 304.785838] i0: f8000ad93048 i1: f8000b47b600 i2: 00f24800 i3: 00f24978 [ 304.900318] i4: 00ec i5: 10076818 i6: f8000b6ff031 i7: 00665838 [ 305.014814] I7: [ 305.066356] Call Trace: [ 305.098501] [<00665838>] chrdev_open+0x98/0x1e0 [ 305.167245] [<0065ae30>] do_dentry_open+0x170/0x420 [ 305.240529] [<0065ca68>] vfs_open+0x28/0x40 [ 305.304691] [<00671348>] path_openat+0x988/0x1100 [ 305.375707] [<00673dd0>] do_filp_open+0x50/0x100 [ 305.445573] [<0065cd30>] do_sys_openat2+0x70/0x180 [ 305.517732] [<0065d268>] sys_openat+0x48/0xc0 [ 305.584186] [<00406174>] linux_sparc_syscall+0x34/0x44 ~ At this point I have to signal a break to the console. I am not yet sure exactly which binary causes this problem but I am going with a wild guess that somewhere in /usr/sbin/grub-mkconfig we end up with a show stopping fault. I am walking through it line by line and trying to find the culprit. Also this has been happening for months. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote: > On 1/9/21 1:53 AM, Dennis Clarke wrote: >> >> I think this is pretty much well known but I will report it here >> regardless. From the latest sparc64 installer images I eventually >> see grub-ieee1275 fails. >> (...) >> Jan 4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports >> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB] >> Jan 4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11 >> Jan 4 19:00:04 in-target: 503 Backend unavailable, connection >> timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB] >> Jan 4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s) >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Failed to fetch >> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb >> 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Unable to fetch some archives, maybe run >> apt-get update or try with --fix-missing? >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 grub-installer: info: Calling 'apt-install >> grub-ieee1275' failed > > I have no clue which image you used and I'm not sure what you did to end up > in a situation > where the installer would try to download the grub2 packages over the net > which are actually > on the installation ISO, so they don't have to be downloaded. > > I also just verified that by installing the latest sparc64 ISO inside an LDOM > in offline mode > and grub2 was installed without any issues with no package mirror being set > up. I am doing a re-install with the "default" installer and I choose the most trivial config options. Which is to say the partition options were whatever seems most trivial. Full disk. New partition table. Everything in one partition. The default seems to be 512MB ext2 bootable /boot and then a large slice and 1G of swap. Eventually I see a big red box : [!!] Configure the package manager apt configuration problem An attempt to configure apt to install additional packages from the media failed. Here I select "continue" and things seem to move along. Then, after a little while everything seems to just work neatly. I guess there is something oddball in the expert level menu option but we don't really test for that. OKay, this works in the easy mode option. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote: > On 1/9/21 1:53 AM, Dennis Clarke wrote: >> >> I think this is pretty much well known but I will report it here >> regardless. From the latest sparc64 installer images I eventually >> see grub-ieee1275 fails. >> (...) >> Jan 4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports >> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB] >> Jan 4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11 >> Jan 4 19:00:04 in-target: 503 Backend unavailable, connection >> timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB] >> Jan 4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s) >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Failed to fetch >> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb >> 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Unable to fetch some archives, maybe run >> apt-get update or try with --fix-missing? >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 grub-installer: info: Calling 'apt-install >> grub-ieee1275' failed > > I have no clue which image you used and I'm not sure what you did to end up > in a situation > where the installer would try to download the grub2 packages over the net > which are actually > on the installation ISO, so they don't have to be downloaded. > I used the sparc64 netinst from https://cdimage.debian.org/cdimage/ports/snapshots/2021-01-03/ and did veridy the SHA512 hash. > I also just verified that by installing the latest sparc64 ISO inside an LDOM > in offline mode > and grub2 was installed without any issues with no package mirror being set > up. > May be possibly because I always use the "expert mode" option in the installer. That allows me to setup the network without DHCP. I will try again with the default trivial installer. Dennis
grub-installer: info: Calling 'apt-install grub-ieee1275' failed
I think this is pretty much well known but I will report it here regardless. From the latest sparc64 installer images I eventually see grub-ieee1275 fails. >From the end of the syslog : Jan 4 19:00:00 in-target: The following additional packages will be installed: Jan 4 19:00:00 in-target: grub-ieee1275-bin grub2-common Jan 4 19:00:00 in-target: The following NEW packages will be installed: Jan 4 19:00:00 in-target: grub-ieee1275 grub-ieee1275-bin grub2-common Jan 4 19:00:02 in-target: 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Jan 4 19:00:02 in-target: Need to get 2031 kB of archives. Jan 4 19:00:02 in-target: After this operation, 5943 kB of additional disk space will be used. Jan 4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB] Jan 4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11 Jan 4 19:00:04 in-target: 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80] Jan 4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB] Jan 4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s) Jan 4 19:00:05 in-target: E Jan 4 19:00:05 in-target: : Jan 4 19:00:05 in-target: Failed to fetch http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80] Jan 4 19:00:05 in-target: Jan 4 19:00:05 in-target: E Jan 4 19:00:05 in-target: : Jan 4 19:00:05 in-target: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Jan 4 19:00:05 in-target: Jan 4 19:00:05 grub-installer: info: Calling 'apt-install grub-ieee1275' failed The entire log is at https://beta.genunix.com/debian_boot/sparc64/syslog_2021-01-03.txt I think, for the moment, the ppc64 installer is a higher priority. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installer images 2020-12-03
On 12/3/20 2:05 PM, John Paul Adrian Glaubitz wrote: > Hi! > > I uploaded updated Debian installer CD images today. > > These come with the latest versions of the kernel and the debian-installer > application as well as various other updates. The images can be found at > the usual location [1] as well as the debian-installer for netboot [2]. > > Known issues: > > - We still don't have support for contrib and non-free, so the images are > missing non-free firmware. It is planned that the Debian Ports FTP server > will be extended to support contrib and non-free but I don't have any > influence on that as this is up to the Debian Ports FTP maintainers. > > So far, I have tested the images on sparc64 only. Please test on the other > architectures and report back. > > Thanks, > Adrian > >> [1] https://cdimage.debian.org/cdimage/ports/snapshots/2020-12-03/ >> [2] https://cdimage.debian.org/cdimage/ports/debian-installer/2020-12-03/ > Install on sparc64 went smoothly. Initial first boot hangs at some systemd related process. I will try to get logs regarding that. I was able to boot to single user mode and then from there to bring up the server to full multi-user mode whereupon everything seems to "just work" and that includes the improved and fixed gcc : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939 Surprised that bug was in the sparc64 world since at least gcc 7.3.0. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Setting up systemd throws a fit. Actually any update does the same.
So a few weeks ago I installed a fresh copy from the cool installer images : https://lists.debian.org/debian-sparc/2020/11/msg3.html Works great but I simply can not update anything. I did try a few times and the machine seems to "vanish" off the network. So I tried via the console : ceres login: root Password: Linux ceres 5.9.0-2-sparc64 #1 Debian 5.9.6-1 (2020-11-08) sparc64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu Oct 15 22:10:23 UTC 2020 on ttyS0 ceres# ceres# apt-get update Hit:1 http://deb.debian.org/debian-ports sid InRelease Reading package lists... Done ceres# apt-get upgrade E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. ceres# dpkg --configure -a Setting up apt-utils (2.1.12) ... Setting up sntp (1:4.2.8p15+dfsg-1) ... Setting up systemd (247.1-2) ... [ 1107.427103] systemd[1]: systemd 247.1-2 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD -SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) [ 1107.719698] systemd[1]: Detected architecture sparc64. [ 1135.085892] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1] [ 1135.175251] Modules linked in: drm(E) drm_panel_orientation_quirks(E) i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E) pata_cmd64x(E) libata(E) sym53c8xx(E) scsi_transport_spi(E) sunhme(E) scsi_mod(E) [ 1135.643279] CPU: 0 PID: 1 Comm: systemd Tainted: GE 5.9.0-2-sparc64 #1 Debian 5.9.6-1 [ 1135.764572] TSTATE: 009911001604 TPC: 008f0260 TNPC: 008f0264 Y: Tainted: GE [ 1135.912246] TPC: [ 1135.962638] g0: f80038781800 g1: 10044830 g2: g3: 0002 [ 1136.077124] g4: f8003a171100 g5: 00e47214 g6: f8003a16c000 g7: 02c5 [ 1136.191602] o0: 00e3be08 o1: f80037d97a10 o2: 0004 o3: [ 1136.306081] o4: o5: sp: f8003a16ef81 ret_pc: 008f0240 [ 1136.425143] RPC: [ 1136.475560] l0: 00e3bc00 l1: f8003a1a3021 l2: 00036a85ab20 l3: 00036a85ab20 [ 1136.590045] l4: 0470 l5: ff9c l6: f8003a16c000 l7: 0064fa00 [ 1136.704523] i0: f80035194850 i1: f80037d97a00 i2: 00e3bc00 i3: 00e3be20 [ 1136.819004] i4: 00eb i5: 10044818 i6: f8003a16f031 i7: 00658c98 [ 1136.933496] I7: [ 1136.985044] Call Trace: [ 1137.017079] [<00658c98>] chrdev_open+0x98/0x1e0 [ 1137.085817] [<0064da30>] do_dentry_open+0x170/0x420 [ 1137.159113] [<0064f268>] vfs_open+0x28/0x40 [ 1137.223270] [<00664a88>] path_openat+0x988/0x1100 [ 1137.294286] [<00667530>] do_filp_open+0x50/0x100 [ 1137.364156] [<0064f510>] do_sys_openat2+0x70/0x180 [ 1137.436316] [<0064fa48>] sys_openat+0x48/0xc0 [ 1137.502769] [<00406174>] linux_sparc_syscall+0x34/0x44 ~ Type 'go' to resume ok No idea what the real problem is ... but if I can dig into it then let me know. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
sparc64 NETINST with firmware 20201116-08:10 seems to work great
Seen at : https://cdimage.debian.org/cdimage/ports/snapshots/2020-11-16/ I just did the install. Expert mode to get the super cool ssh remote install working and to be able to config the network with better precision. $ uname -a Linux ceres 5.9.0-2-sparc64 #1 Debian 5.9.6-1 (2020-11-08) sparc64 GNU/Linux Seems to be working just fine on an old Netra. In the past the update process would always create a panic due to some oddity in the grub stage of things. I have not yet tested for that. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Unrecognized magic number in media label
On 10/28/20 6:16 AM, John Paul Adrian Glaubitz wrote: > On 10/28/20 11:12 AM, Dennis Clarke wrote: >> Everything seems to just work fine. Until reboot wherein I see : >> >> Boot device: /pci@1f,0/pci@1,1/scsi@2/disk@0,0:a File and args: >> Unrecognized magic number in media label >> Can't open disk label package >> Evaluating: boot >> >> Can't open boot device >> >> ok >> >> I am guessing that my mistake was to use a gpt label on the boot disk >> and the old firmware on this test Netra machine can only grok a sun >> label. Just a guess. Let me know if this seems reasonable. > > Yes, GPT is supported on SPARC T4 and newer only. > > Normally, when you use automatic partioning, the installer should detect > whether your machine supports GPT and if not, use a Sun-based partition > layout. I may have mentioned in the past that I *always* use the expert mode text installer to get the job done. Mostly because I can walk away from the machine and run the bulk of the installation process remote over a ssh connection. That is the greatest feature in the installer ever! Certainly top of the top ten features in an otherwise slick and easy installer process. I assure you that Red Hat could learn a lot. I hate their graphical garbage installer. The other great feature of the expert mode is that I can set the ip address and not get locked into DHCP. I do have a very small DHCP subnet but that is only to deal with a few windows clients. Otherwise all hosts fall into a subnet 172.16.35.1/26 which is for lab systems. It does just work great and I even have ppc64 and ppp64le running fine. I don't do anything graphical on those hosts other than some X11 work. The sparc64 installer from 2020-10-13 works great and the only snag I hit was self inflicted with the gpt label. I knew when I did it that it was a mistake but plowed ahead anyways. I do wish there was a way to get an M3000 or even better an M4000 running as those things have actual horse power for real world work. The XSCF is not a big deal to manage on those but I suspect the firmware is the real problem once one gets a console to a hardware domain. I don't know. I have not tried on those machines in years and would like to get my M4000 up and running just to see what happens. In any case, thank you for the great work and I wanted to simply let you know that sparc64 seems to work fine for the basic stuff anyone would want. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Unrecognized magic number in media label
I was just testing the installer image at : https://cdimage.debian.org/cdimage/ports/snapshots/2020-10-13/ Everything seems to just work fine. Until reboot wherein I see : Boot device: /pci@1f,0/pci@1,1/scsi@2/disk@0,0:a File and args: Unrecognized magic number in media label Can't open disk label package Evaluating: boot Can't open boot device ok I am guessing that my mistake was to use a gpt label on the boot disk and the old firmware on this test Netra machine can only grok a sun label. Just a guess. Let me know if this seems reasonable. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
An attempt to update the kernel results in a panic
This is very repeatable and I have done this over and over to look at the output messages on the console : phobos# apt-get upgrade E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. phobos# dpkg --configure -a Setting up grub-ieee1275 (2.04-9) ... [ 4458.342137] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [grub-probe:916] [ 4458.437149] Modules linked in: drm(E) drm_panel_orientation_quirks(E) i2c_core(E) sg(E) envctrl(E) display7seg(E) flash(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) ata_generic(E) pata_cmd64x(E) libata(E) sym53c8xx(E) scsi_transport_spi(E) sunhme(E) scsi_mod(E) [ 4458.807960] CPU: 0 PID: 916 Comm: grub-probe Tainted: GE 5.5.0-2-sparc64 #1 Debian 5.5.17-1 [ 4458.936131] TSTATE: 11001605 TPC: 008804ec TNPC: 008804f0 Y: Tainted: GE [ 4459.083802] TPC: [ 4459.134194] g0: g1: 10032838 g2: g3: 03581820 [ 4459.248577] g4: f8003befd3c0 g5: 5f8bcbd1 g6: f80037ea4000 g7: 0dd33530 [ 4459.363056] o0: 00d9c458 o1: f80037ea790c o2: f8003a2559d0 o3: [ 4459.477535] o4: o5: sp: f80037ea6fa1 ret_pc: 008804c0 [ 4459.596594] RPC: [ 4459.647013] l0: 00d9c400 l1: l2: 0063a500 l3: eff8 [ 4459.761416] l4: l5: ff9c l6: f80037ea4000 l7: 00632b60 [ 4459.875884] i0: f80037f66ad8 i1: f80037eab900 i2: 00d9c400 i3: 00d9c470 [ 4459.990362] i4: 00ec i5: 10032820 i6: f80037ea7051 i7: 0063b0f8 [ 4460.104849] I7: [ 4460.156399] Call Trace: [ 4460.188433] [0063b0f8] chrdev_open+0x78/0x160 [ 4460.256043] [00631398] do_dentry_open+0x158/0x440 [ 4460.328183] [006326e8] vfs_open+0x28/0x40 [ 4460.391204] [00646658] path_openat+0x4d8/0x1420 [ 4460.461070] [006486b0] do_filp_open+0x50/0xc0 [ 4460.528650] [00632a30] do_sys_open+0x170/0x260 [ 4460.597379] [00632b80] sys_openat+0x20/0x40 [ 4460.662688] [00406154] linux_sparc_syscall+0x34/0x44 ~ Type 'go' to resume ok Not sure if there is a way to fix this or if it is already known. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Bug#965342: openjdk-15: Please update build configuration for sparc64
On 7/20/20 7:38 AM, John Paul Adrian Glaubitz wrote: > On 7/20/20 2:20 AM, Rick Leir wrote: >> But Hotspot supported the previous version of OpenJDK. Is version 15 Hotspot >> not supported because >> >> changes are known to be needed, or just because the maintainers don't have >> the time to test it on SPARC? > > Native Hotspot support for SPARC was removed by Oracle because they have > decided to pull > out of the SPARC business. As you may have heard, they let go the majority of > their > SPARC engineers in 2018. When John Fowler left, it was all over. So long as Fowler was with Sun and then with Oracle there was a chance that big sparc machines were still going to be shipped. I own a few. Sadly that business is all but dead and you can not even run the latest Solaris on a sparc server at all unless you want to buy their top of the line million dollar machines. Everything else was dropped off a cliff. It would be very cool to get Debian linux running on a M-4000 beast with 256G of memory but the fences to climb over are very high and then there are mine fields to crawl into. It is far far more fun to just go to RISC-V and do good stuff there. > > The other OpenJDK developers told me, they could have kept the SPARC port if > I had > volunteered to maintain it (as I'm also a member of OpenJDK upstream). But > that > would have been a lot of work as they are planning to make a lot of intrusive > changes > to OpenJDK in the coming years. > >> As you say it is sad. Java and SPARC are the SW/HW claims to fame of the Sun >> Corp. > That is now history, unfortunately. > So very true and so very sad. I was a big fan of the OpenSolaris project which at least gave us ZFS and some other items. However that CDDL license disaster is just a mess. A minefield mess. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
watchdog: BUG: soft lockup with most recent sparc64 installer
This looks like a kernel bug but regardless I see a lockup when I attempt to do certain operations : phobos# phobos# ls -1trb .. linux-5.7-rc2.compile.log linux-5.7-rc2.make_modules.log linux-5.7-rc2.make_modules_install.log linux-5.7-rc2.make_install.log linux-5.7-rc2 linux-5.7-rc2.make_install.log2 linux-5.7-rc2.env phobos# phobos# phobos# /usr/bin/time -p /usr/bin/nice -n +15 make install 2>&1 | \ > tee ../linux-5.7-rc2.make_install.log3 sh ./arch/sparc/boot/install.sh 5.7.0-rc2 arch/sparc/boot/zImage \ System.map "/boot" run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.7.0-rc2 /boot/vmlinuz-5.7.0-rc2 run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.7.0-rc2 /boot/vmlinuz-5.7.0-rc2 update-initramfs: Generating /boot/initrd.img-5.7.0-rc2 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 5.7.0-rc2 /boot/vmlinuz-5.7.0-rc2 [ 1319.107865] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [grub-probe:2025] [ 1319.204084] Modules linked in: sg(E) envctrl(E) display7seg(E) flash(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) ata_generic(E) pata_cmd64x(E) sym53c8xx(E) libata(E) scsi_transport_spi(E) scsi_mod(E) sunhme(E) [ 1319.516550] CPU: 0 PID: 2025 Comm: grub-probe Tainted: GE 5.5.0-2-sparc64 #1 Debian 5.5.17-1 [ 1319.645861] TSTATE: 009911001603 TPC: 008804e0 TNPC: 008804e4 Y: Tainted: GE [ 1319.793536] TPC: [ 1319.843923] g0: g1: 1000a838 g2: g3: 00c43720 [ 1319.958414] g4: f8003beb3240 g5: 0038 g6: f800343e4000 g7: 0e596bf0 [ 1320.072894] o0: 00d9c458 o1: f800343e790c o2: f8003a2559d0 o3: [ 1320.187374] o4: o5: sp: f800343e6fa1 ret_pc: 008804c0 [ 1320.306434] RPC: [ 1320.356848] l0: 00d9c400 l1: l2: 0063a500 l3: eff8 [ 1320.471339] l4: l5: ff9c l6: f800343e4000 l7: 00632b60 [ 1320.585819] i0: f800347c3018 i1: f80037c1b300 i2: 00d9c400 i3: 00d9c470 [ 1320.700299] i4: 00ec i5: 1000a820 i6: f800343e7051 i7: 0063b0f8 [ 1320.814784] I7: [ 1320.866335] Call Trace: [ 1320.898369] [0063b0f8] chrdev_open+0x78/0x160 [ 1320.965978] [00631398] do_dentry_open+0x158/0x440 [ 1321.038119] [006326e8] vfs_open+0x28/0x40 [ 1321.101142] [00646658] path_openat+0x4d8/0x1420 [ 1321.171006] [006486b0] do_filp_open+0x50/0xc0 [ 1321.238588] [00632a30] do_sys_open+0x170/0x260 [ 1321.307317] [00632b80] sys_openat+0x20/0x40 [ 1321.372626] [00406154] linux_sparc_syscall+0x34/0x44 This is completely repeatable when I try to install a new initrd image. I will try to manually hack the grub.cfg and see if I can boot the linux 5.7-rc2 initrd and other goodness. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: 2020-04-19 debian-10.0-sparc64 NETINST working fine sort of but libc6-dev ???
On 2020-04-21 14:06, John Paul Adrian Glaubitz wrote: On 4/21/20 8:01 PM, Dennis Clarke wrote: Looks like a version problem : phobos# apt-get install libc6-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libc6-dev : Depends: libc6 (= 2.30-2+sparc64) but 2.31-0+sparc64 is to be installed Depends: libc-dev-bin (= 2.30-2+sparc64) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Try: # apt install libc6-dev=2.31-0+sparc64 Adrian hr ... seems to not exist : phobos# phobos# apt install libc6-dev=2.31-0+sparc64 Reading package lists... Done Building dependency tree Reading state information... Done E: Version '2.31-0+sparc64' for 'libc6-dev' was not found phobos# Dennis
Re: 2020-04-19 debian-10.0-sparc64 NETINST working fine sort of but libc6-dev ???
On 2020-04-21 12:59, Dennis Clarke wrote: On 2020-04-21 12:29, John Paul Adrian Glaubitz wrote: On 4/21/20 5:40 PM, Dennis Clarke wrote: . . . root@phobos:~# apt-get install build-essential xauth libx11-dev autoconf bison gdb Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: build-essential : Depends: libc6-dev but it is not going to be installed or libc-dev Depends: g++ (>= 4:9.2) but it is not going to be installed E: Unable to correct problems, you have held broken packages. root@phobos:~# No, that works (see below). It's most likely your band-aid installation that causes these problems. Looks like a version problem : phobos# apt-get install libc6-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libc6-dev : Depends: libc6 (= 2.30-2+sparc64) but 2.31-0+sparc64 is to be installed Depends: libc-dev-bin (= 2.30-2+sparc64) but it is not going to be installed E: Unable to correct problems, you have held broken packages. phobos# apt-get install libc6 Reading package lists... Done Building dependency tree Reading state information... Done libc6 is already the newest version (2.31-0+sparc64). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. phobos# phobos# Dennis
Re: 2020-04-19 debian-10.0-sparc64 NETINST working fine sort of but libc6-dev ???
On 2020-04-21 13:02, Gregor Riepl wrote: Ah well, that certainly explains that. Seems deb-src does not exist either. I think you should use the regular Debian source repo. There is no "special" ports source repo. OKay, thank you. That seems to work great. Dennis
Re: 2020-04-19 debian-10.0-sparc64 NETINST working fine sort of but libc6-dev ???
On 2020-04-21 13:02, John Paul Adrian Glaubitz wrote: On 4/21/20 6:59 PM, Dennis Clarke wrote: Debian Ports has neither "contrib" nor "non-free". Ah well, that certainly explains that. Seems deb-src does not exist either. No, because the sources are available on the main archives anyway: deb-src http://ftp.debian.org/debian main contrib non-free oh. Excellent. No, that works (see below). It's most likely your band-aid installation that causes these problems. Well I did open the cover of the machine to see that there was an IDE interface in there but the cable needed seemed to be an odd width. The front of the machine has a slot for a CDROM as well as a 4mm DAT tape drive and I have neither of those. Would be great to try to boot from tape again one day. Hardly practical :) The only way that I could figure to boot the machine was to dd the netinst into a scsi disks cylinder 0 and then boot that from the firmware. When the installer asked where the installation media was I simply entered manually /dev/sdb and everything ran fine. In any case the machine seems to be running fine and I am happy that I did not need to resort to TFTP/BOOTp nonsense to get the installer working. It all just worked out of the box and with an actual CRT type old terminal attached to the ttya port there was no problem at all. Try installing "libc6-dev" alone to see what the error message is. Normally, apt will tell you what actually prevents it from installing packages. Adrian phobos# apt-get install libc6-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libc6-dev : Depends: libc6 (= 2.30-2+sparc64) but 2.31-0+sparc64 is to be installed Depends: libc-dev-bin (= 2.30-2+sparc64) but it is not going to be installed E: Unable to correct problems, you have held broken packages. phobos# Not sure what to make of that. Dennis
Re: 2020-04-19 debian-10.0-sparc64 NETINST working fine sort of but libc6-dev ???
On 2020-04-21 12:29, John Paul Adrian Glaubitz wrote: On 4/21/20 5:40 PM, Dennis Clarke wrote: root@phobos:~# cp -p /etc/apt/sources.list /etc/apt/sources.list.orig root@phobos:~# root@phobos:~# vi /etc/apt/sources.list root@phobos:~# root@phobos:~# root@phobos:~# cat /etc/apt/sources.list # deb cdrom:[Debian GNU/Linux 10.0 _Sid_ - Unofficial sparc64 NETINST 20200419-15:32]/ sid main deb http://deb.debian.org/debian-ports/ sid main non-free contrib deb-src http://deb.debian.org/debian-ports/ sid main non-free contrib Debian Ports has neither "contrib" nor "non-free". Ah well, that certainly explains that. Seems deb-src does not exist either. root@phobos:~# apt-get install build-essential xauth libx11-dev autoconf bison gdb Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: build-essential : Depends: libc6-dev but it is not going to be installed or libc-dev Depends: g++ (>= 4:9.2) but it is not going to be installed E: Unable to correct problems, you have held broken packages. root@phobos:~# No, that works (see below). It's most likely your band-aid installation that causes these problems. Well I did open the cover of the machine to see that there was an IDE interface in there but the cable needed seemed to be an odd width. The front of the machine has a slot for a CDROM as well as a 4mm DAT tape drive and I have neither of those. Would be great to try to boot from tape again one day. Hardly practical :) The only way that I could figure to boot the machine was to dd the netinst into a scsi disks cylinder 0 and then boot that from the firmware. When the installer asked where the installation media was I simply entered manually /dev/sdb and everything ran fine. In any case the machine seems to be running fine and I am happy that I did not need to resort to TFTP/BOOTp nonsense to get the installer working. It all just worked out of the box and with an actual CRT type old terminal attached to the ttya port there was no problem at all. That installer seems to be just great. Thank you so much. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
2020-04-19 debian-10.0-sparc64 NETINST working fine sort of but libc6-dev ???
s:~# Oh no. libc6-dev is a problem ?? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2020-04-19
On 4/19/20 6:30 PM, John Paul Adrian Glaubitz wrote: Hi! I just uploaded updated installation images 2020-04-19 for the following Debian Ports architectures [1]: * alpha * hppa * ia64 * m68k * powerpc * ppc64 * sparc64 These images should finally fix the installation process on Apple PowerMacs and PowerBooks compatible with GRUB, so basically every Macintosh using the New World ROM [2]. One user already reported a successful installation on his PowerMac G5 and I expect installations to work fine on 32-bit machines, i.e. G3 and G4 as well. But I'm looking forward to more feedback. Working well enough. I tossed a bit of load at it and created : enceladus$ cat /proc/version Linux version 5.7.0-rc1 (root@enceladus) (gcc version 9.3.0 (Debian 9.3.0-10), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Sun Apr 19 20:10:43 UTC 2020 enceladus$ The whole process went smooth and no surprises at all. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Information about blade 2500 and ultra 45
On 2020-03-27 13:43, John Paul Adrian Glaubitz wrote: Hi John! On 3/27/20 5:54 PM, John Kleiver Contreras García wrote: Hello, first of all, thanks for maintaining Debian on the Sparc Arch, secondly, I wish to know the current status of Debian on the aforementioned machines (blade 2500 silver and ultra 45), both of them have dual CPU's, the blade 2500 have a xvr 100 and the ultra 45 have a xvr 2500 (of which I heard that there is no drivers, so no Xorg), have someone used these machines with Debian before, I don't see any particular reason why these shouldn't work. I have an Ultra 45 myself, but I haven't installed Debian on it so far. and if there are drivers or a workaround for getting it to work with Xorg, thanks for your time and dedication If the built-in graphics card is not supported, I assume you should just be able to use a normal PCI/PCI-X graphics card. Use this image [1]. Adrian [1] https://cdimage.debian.org/cdimage/ports/2019-07-16/ Has anyone tried the much older smaller little blade netra servers like the "flapjack" Sun Microsystems Netra t1 105 ? I have a few of those laying around and with 1GB of memory they should "work". Just not sure how one gets the thing to boot install media or even the net inst image. Perhaps TFTP and BOOTP ?? Any input would be lovely. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: [BUG]: Testsuite fails on Linux sparc64 in t-cmp_d
I have not figured out yet whether the bug is a regression or not, currently bisecting. If anyone wants to reproduce it, sparc64 porterboxes are available through the gcc compile farm [1]. I am certainly interested in trying. I have never been able to get much working on my M3000 or M4000 equipment and most of my older stuff is just laying in a pile in a warehouse. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-05-09
On 5/11/19 10:05 AM, John Paul Adrian Glaubitz wrote: On 5/11/19 3:37 PM, Dennis Clarke wrote: A few folks from Oracle got back to me and let me know that they don't have Linux on sparc at all. Period. Some stupid sales rep just says to me "yes, sure, we run that !" when in fact he hasn't a damn clue. That's not correct though. Here's some proof: https://oss.oracle.com/projects/linux-sparc/ https://blogs.oracle.com/wim/oracle-linux-6-for-sparc What's true is that Oracle first poured resources into Linux on SPARC and later decided to drop it. They even ported things like Valgrind and Golang to Linux for SPARC (although the latter was initially ported to Solaris/SPARC). So there is no Linux on sparc as far as Oracle is concerned. Nobody gives a damn about Solaris anymore so I don't know what they are smoking at Oracle but it is very weird stuff to be sure. You can still download it here: http://ftp.icm.edu.pl/packages/linux-oracle-sparc/ The Oracle folks I spoke with have zero clue about it. Zero. Less than zero would be that no one even knows that they still sell sparc systems and others are just all about the database and cloud and still others are even more confused. However the company makes money. Somehow. dc
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 10:06 PM, Rick Leir wrote: Oracle Linux .. for Intel processors? Please ask him about Oracle Linux for Sparc. I would like to give it a try if they have it. Thanks -- Rick A few folks from Oracle got back to me and let me know that they don't have Linux on sparc at all. Period. Some stupid sales rep just says to me "yes, sure, we run that !" when in fact he hasn't a damn clue. So there is no Linux on sparc as far as Oracle is concerned. Nobody gives a damn about Solaris anymore so I don't know what they are smoking at Oracle but it is very weird stuff to be sure. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 4:44 PM, Meelis Roos wrote: Given that it works on a sun4u then I am guessing that a Sunblade 2000 should be perfect for this sort of thing. I know that I have one of those in the warehouse. However I think they need FCAL disks. Anyways I will give that a look see and also I hope serial console works out of the box. Yes, I should try it on some sun4u too. And probably bare hardware sun4v - all my sparcs run Linux natively. About Blade 1x00/2x00 and E280R: they use qla2xxx for root disks and last I tried this was broken in the kernel. It may be better now but older Symbios and newer MPT etc controllers would probably be a safer try if you have them available. My problem is that I have way too much sparc hardware in life and no real up to date OS to run. Sure Solaris 10 is still around and barely supported but it is horrific for performance. I was just speaking with an Oracle salesrep about the new 5GHz T8 and he assures me that Oracle has Linux running there. Oracle Linux v6 and v7 run there. He says. Well I see Oracle Linux as just a variation on the RHEL sources. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: I have to ask .. has anyone tried SPARC T7 ? SPARC S7? SPARC T8?
On 5/9/19 4:20 PM, John Paul Adrian Glaubitz wrote: On 5/9/19 10:18 PM, Dennis Clarke wrote: I had some S7-2 units in a project and was fairly impressed with what they could do. Of all things they were MySql servers and with fibre attached storage they were really impressive units. Just curious if anyone has seen or tried this sort of hardware with a Debian installer image. I only know of Oracle folk who have these machines and they told me that Debian installs just fine inside an LDOM on these machines. Ah, good to know. If I see another project with that sort of hardware then I would snag a unit for testing. I would take an S7 in a heartbeat, but they are currently too expensive. They are the lightweight T7 sort. Regardless, not competitive with Xeon. The new SPARC T8 looks to be a supercomputer monster slayer. With the older M-series gear I was running LACP over bonded 10Gbit for storage and that worked very very well. The real issue was that the price was simply over the top for trivial implementations and most managers just don't "see" the value in long term rock solid stability. The S7 units were used as backend transaction processors and MySql ran amazingly well there. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 4:02 PM, John Paul Adrian Glaubitz wrote: On 5/9/19 9:59 PM, Dennis Clarke wrote: The big blocker for me is that the M4000 needs 240V power supply. Otherwise I would run it at home. I thought you can get 240 volts in the US when using a two-phase power outlet. Well a UPS is needed also. So an APC5000 series or similar as well as the 240 volt supply. No matter how I slice it there is a bucket of money to spend to get the same performance a ninety dollar ASUS arm7 Tinkerboard can do. However 256G of memory and 16 processor cores at 2.66GHz is real hard to get anywhere else. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 3:33 PM, Meelis Roos wrote: [2] also has some further reading about this topic. Maybe you get in touch with Meelis Roos, who started a thread titled "Adding support for Fujitsu SPARC64 machines?" on the linux-sparc mailing list (see [3]) some years ago. Maybe this can be revived. [3]: https://marc.info/?l=linux-sparc=142067252101925=2 I'm actually here on this list. But no, nothing came out of my plan - because of lack of time from my side and the student going away. I still have the PP450 wired up and ready to run if power is turned on from xscf, so if there is someone else taking it on, I can offer PP450 access. M4000, PP650 and PP250 are away in storage. The big blocker for me is that the M4000 needs 240V power supply. Otherwise I would run it at home. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 3:31 PM, Frank Scheiner wrote: Hi Adrian, On 5/9/19 18:24, John Paul Adrian Glaubitz wrote: I just uploaded updated installation images 2019-05-09 for the following Debian Ports architectures: [...] * sparc64 I uploaded both CD images [1] as well as netboot images [2]. Please test those images and report back over the mailing list for the corresponding architecture. Known issues: [...] * sparc64 - Installation over a serial console is currently broken on sparc64 due to a bug in the rootskel package (can also be considered a kernel bug), see: #926539. Use any image before 2019-04-06 as workaround. Looks like this doesn't affect sun4u machines, at least this ISO worked for my v245 using the serial console without any problems. Nice work! :-D Just one odd thing: I didn't see any kernel messages when booting from the installer disc. I assumed that there might be a `quiet` in the kernel command line, but editing the GRUB menu options showed no arguments for the kernel command line at all for the "default" option, just "boot_one" IIRC. Given that it works on a sun4u then I am guessing that a Sunblade 2000 should be perfect for this sort of thing. I know that I have one of those in the warehouse. However I think they need FCAL disks. Anyways I will give that a look see and also I hope serial console works out of the box. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-05-09
It can't be that that much of an issue, because OpenBSD runs on these machines (according to [4] and my tests on serveral PRIMEPOWER 250s). And for the Linux kernel you can actually see some Linux kernel messages before the machine experiences a red state exception... [4]: http://www.openbsd.org/sparc64.html I avoid the openbsd people and try to just look to freebsd : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233579 Which actually is making good progress in the IBM Power9 world on the TALOS as well as on ye old ppc64 PowerMac units and sparc is in progress also. With ZFS everywhere. Anyways, that is well off topic. dc
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 1:52 PM, Frank Scheiner wrote: On 5/9/19 19:42, Dennis Clarke wrote: On 5/9/19 1:35 PM, Frank Scheiner wrote: Hi Dennis, On 5/9/19 18:29, Dennis Clarke wrote: On 5/9/19 12:24 PM, John Paul Adrian Glaubitz wrote: Hello! I just uploaded updated installation images 2019-05-09 for the following Debian Ports architectures: * alpha * hppa * ia64 * m68k * powerpc * ppc64 * sh4 * sparc64 I tried to breath life into an old Netra which was just too old for the task. Are you aware of any issues with the M3000 type machine? Or even M4000 ? I'm starting to wonder if my mails about ... No I am not ignoring you. I simply didn't recall over my coffee this morning. I have not looked at linux on sparc in ... nearly forever. Possibly an actual forever. There is no reason to think about it. Now I see from my hardware list on hand there is even less reason to even bother testing. Thanks for listening. Please don't mind, I was just a little upset, as I assumed my mails on this topic were just wasted. [2] also has some further reading about this topic. Maybe you get in touch with Meelis Roos, who started a thread titled "Adding support for Fujitsu SPARC64 machines?" on the linux-sparc mailing list (see [3]) some years ago. Maybe this can be revived. [2]: https://wiki.debian.org/Sparc64#Installing_the_Debian_SPARC64_Port [3]: https://marc.info/?l=linux-sparc=142067252101925=2 I appreciate your patience and perserverance. I seem to have way way too many little irons in the fire and too many machines running to recall all the bits about all of them. I don't think I am alone in that experience. In my mind an Oracle M4000 with 256G of memory and a stack of processor cores is a terrible waste. Baffles me that it can not run with even some basic sparc v9 type mode. Regardless the devices are most likely an issue also. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 1:35 PM, Frank Scheiner wrote: Hi Dennis, On 5/9/19 18:29, Dennis Clarke wrote: On 5/9/19 12:24 PM, John Paul Adrian Glaubitz wrote: Hello! I just uploaded updated installation images 2019-05-09 for the following Debian Ports architectures: * alpha * hppa * ia64 * m68k * powerpc * ppc64 * sh4 * sparc64 I tried to breath life into an old Netra which was just too old for the task. Are you aware of any issues with the M3000 type machine? Or even M4000 ? I'm starting to wonder if my mails about ... No I am not ignoring you. I simply didn't recall over my coffee this morning. I have not looked at linux on sparc in ... nearly forever. Possibly an actual forever. There is no reason to think about it. Now I see from my hardware list on hand there is even less reason to even bother testing. Thanks for listening. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 12:32 PM, John Paul Adrian Glaubitz wrote: On 5/9/19 6:29 PM, Dennis Clarke wrote: I tried to breath life into an old Netra which was just too old for the task. Are you aware of any issues with the M3000 type machine? Or even M4000 ? I have never touched any of those machines, but from what I know some of the Fujitsu machines aren't supported by the Linux kernel. Oh dear. Currently I have a machine sitting around doing a lot of nothing all day and running Solaris 10 : jupiter # jupiter # uname -a SunOS jupiter 5.10 Generic_150400-65 sun4u sparc SUNW,SPARC-Enterprise jupiter # psrinfo -pv The physical processor has 8 virtual processors (0-7) SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz) jupiter # prtconf -v | grep 'Memory' Memory size: 65536 Megabytes jupiter # Seems a waste really. Dennis
Re: Updated installation images for Debian Ports 2019-05-09
On 5/9/19 12:24 PM, John Paul Adrian Glaubitz wrote: Hello! I just uploaded updated installation images 2019-05-09 for the following Debian Ports architectures: * alpha * hppa * ia64 * m68k * powerpc * ppc64 * sh4 * sparc64 I tried to breath life into an old Netra which was just too old for the task. Are you aware of any issues with the M3000 type machine? Or even M4000 ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Will try debian-10.0-sparc64-grub-NETINST-1.iso
On 5/5/19 8:56 PM, Chris Ross wrote: On Sun, May 05, 2019 at 07:40:20PM -0400, Dennis Clarke wrote: I see https://cdimage.debian.org/cdimage/ports/grub-test/ and have fetched debian-10.0-sparc64-grub-NETINST-1.iso which may work on a very very old netra test unit. A Netra X1 in fact. However it has enough memory and a basic serial port for a console. Can I serve up this iso image via TFTP/NFS or is it better to mess around with a physical CDROM ? I don't have any answers or advice for you, but would be very interested to hear more about it. I also have old Sparc's, including (if it's still around somewhere) an X1. It would be a lovely low-power server if I could get it running a reasonable OS. Well I think any tests that I do will need to be via tftp/nfs as there is no way that I can attach an old IDE CDROM to this artifact. I was able to install Solaris 10 into it just fine. However that was via a netboot process as old as the hills. The other fine fun here is that the NVRAM is toast as is the battery. I think I should just scrap this test and move on to more modern server types like the M3000 or Netra T2 line. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Will try debian-10.0-sparc64-grub-NETINST-1.iso
I see https://cdimage.debian.org/cdimage/ports/grub-test/ and have fetched debian-10.0-sparc64-grub-NETINST-1.iso which may work on a very very old netra test unit. A Netra X1 in fact. However it has enough memory and a basic serial port for a console. Can I serve up this iso image via TFTP/NFS or is it better to mess around with a physical CDROM ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated installation images for Debian Ports 2019-04-12
>* powerpc/ppc64 > - The bootloader installation still defaults to Yaboot and > is being switched to GRUB for IBM POWER and PowerMacs, > please report any issues you find. I see GRUB installed fine and no yaboot anywhere to be seen. That is a good thing. :-) > - On some machines, the fans might produce a lot of noise, >this can be addressed by manually the windfarm kernel >modules: >+ modprobe windfarm_core Absolutely. Dennis
Re: Updated installation images for Debian Ports 2019-04-10
On 4/11/19 11:05 AM, John Paul Adrian Glaubitz wrote: Hello! I just uploaded updated installation images for the following Debian Ports architectures: Fails to install GRUB same as before. The script /usr/lib/grub-installer/mkhfs-bootstrap.sh is not an executable file ? Dennis
Re: installing NETINST 20190127
On 1/28/19 8:01 AM, John Paul Adrian Glaubitz wrote: On 1/28/19 1:52 PM, Frank Scheiner wrote: @Rick: I thought about something like this since Mark reported the bootstrap limits in OpenBIOS. It could in principle work similar to the switch between non-GPT and GPT capable SPARC hardware ([1]). I don't understand this argument. GRUB works on PowerPC Macs and is fully supported or am I missing something? I also works fine on SPARC hardware with Sun partition tables. Unless you want to install on very old SPARC hardware, there is no need to carry SILO around. Our tests have shown that GRUB works on any 64-bit SPARC hardware which means that anything going back to the mid-90ies is supported. Has anyone tried a newer Oracle Netra T4 class server? I have one ( or two ) of those in my life and could give it a whirl. Not too sure how to get it to boot over the network and I may have to resort to an actual physical DVD however. Dennis
Re: sparc 32bit userland?
On 1/27/19 2:40 PM, Jan Engelhardt wrote: On Sunday 2019-01-27 20:25, Dennis Clarke wrote: On a side note: As you also added sparc, say, is it planned to revive the 32bit sparc userland? :-) oh please .. no. Although I don't have much of a preference for 32bit sparc userland, as there is no kernel support for old SPARC gear, but anything substantial on why not, Dennis? I enjoy historical and archaeological computing as much as the other old grey beard suspender wearing UNIX geeks but it is largely just a waste of time. A curiosity to be sure. However nothing more. At least we have 32-bit ppc FreeScale and Motorola type hardware literally everywhere but I have not seen 32-bit sparc in the wild for at least a decade. Running ILP32 software on a 64-bit CPU sure seems unpopular these days... (but it's still half the memory and bandwidth nonwithstanding the beating x32 took not too long ago). I agree with a "bit less" memory. A "bit less" bandwidth? Maybe. However the overhead in a code base isn't worth the effort. Dennis
Re: sparc 32bit userland?
On 1/27/19 2:20 PM, Frank Scheiner wrote: On 1/27/19 20:11, Dennis Clarke wrote: On 1/27/19 2:08 PM, Frank Scheiner wrote: On 1/27/19 19:50, John Paul Adrian Glaubitz wrote: On 1/27/19 4:24 PM, John Paul Adrian Glaubitz wrote: Although, oddly enough, I didn't see this issue on sparc64, so it might be that I have just forgotten to add the package for powerpc after it moved from release to ports. That guess was correct, just fixed it: https://salsa.debian.org/images-team/debian-cd/commit/57cae1891492ba74901e88b4252ee69265cca402 On a side note: As you also added sparc, say, is it planned to revive the 32bit sparc userland? :-) oh please .. no. Although I don't have much of a preference for 32bit sparc userland, as there is no kernel support for old SPARC gear, but anything substantial on why not, Dennis? I enjoy historical and archaeological computing as much as the other old grey beard suspender wearing UNIX geeks but it is largely just a waste of time. A curiosity to be sure. However nothing more. At least we have 32-bit ppc FreeScale and Motorola type hardware literally everywhere but I have not seen 32-bit sparc in the wild for at least a decade. Dennis
Re: sparc 32bit userland?
On 1/27/19 2:08 PM, Frank Scheiner wrote: On 1/27/19 19:50, John Paul Adrian Glaubitz wrote: On 1/27/19 4:24 PM, John Paul Adrian Glaubitz wrote: Although, oddly enough, I didn't see this issue on sparc64, so it might be that I have just forgotten to add the package for powerpc after it moved from release to ports. That guess was correct, just fixed it: https://salsa.debian.org/images-team/debian-cd/commit/57cae1891492ba74901e88b4252ee69265cca402 On a side note: As you also added sparc, say, is it planned to revive the 32bit sparc userland? :-) oh please .. no. Dennis
Re: Any progress with grub-installer?
On 1/7/19 3:14 PM, John Paul Adrian Glaubitz wrote: On Jan 7, 2019, at 9:07 PM, Frank Scheiner wrote: On 1/7/19 16:35, John Paul Adrian Glaubitz wrote: On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote: I tried to install GRUB using a ELF boot image: root@debian:~/grub2# grub-install /dev/vdiska Installing for sparc64-ieee1275 platform. grub-install: error: the size of `/boot/grub/sparc64-ieee1275/boot.img' is not 512. root@debian:~/grub2# ls -l /boot/grub/sparc64-ieee1275/boot.img -rw-r--r-- 1 root root 816 Jan 7 18:29 /boot/grub/sparc64-ieee1275/boot.img root@debian:~/grub2# I mistakenly went with the expert installer of the latest netinst image and saw this : ┌┤ [!!] Install the GRUB boot loader on a hard disk ├┐ │ Unable to install GRUB in dummy │ │ Executing 'grub-install dummy' failed. │ │ This is a fatal error. │ So I will go with lilo or perhaps start over with the default installer which doesn't really seem to allow manual ipv4 config but may be more commonly tested. Dennis
Re: Any progress with grub-installer?
On 1/7/19 10:35 AM, John Paul Adrian Glaubitz wrote: On 1/7/19 4:31 PM, John Paul Adrian Glaubitz wrote: I tried to install GRUB using a ELF boot image: Now we just need to test this on a machine with a Sun partition table. I can drag out an old sparc for that easily. Dennis
Re: xserver problem 9.0-sparc64 netinst
On 12/4/18 6:14 AM, Gregor Riepl wrote: There were very few options for the old sun ultra5. It was to be a sun experiment into low cost PC-like dirt cheap slapped together low-end workstations. So the graphics options were bottom dollar. The ultra10 had the benefit of actual OpenGL ready hardware but that is another story. Are you talking about Creator (3D)? Exactly. I had one at home and it ran great. With Solaris 2.5.1. Otherwise I can not recall anything about it from over twenty years ago. In any case, they're not very fast and lack basic features that even the Mach64 has (like colorspace transforms for video playback), but at least they have enough VRAM for resolutions higher than 1024x768. The Ultra5 and Ultra10 were to Sun what the Porsche Cayenne was for Porsche. Bottom of the line junk you buy with pride only to discover it isn't really a Sun server and it runs like junk and dies fast and it is worthless even faster. Meanwhile the average Sun server would run for a decade just fine. Dennis
Re: xserver problem 9.0-sparc64 netinst
On 12/3/18 4:10 PM, Fred wrote: On 12/03/2018 12:29 PM, Dennis Clarke wrote: On 12/3/18 2:18 PM, Fred wrote: On 12/03/2018 10:14 AM, Phillip Stevens wrote: Mach64 (PGX24 PGX64) driver is not working. Also Radeon (XVR-100) is not working. Hi Dennis, I thought the U5 was exactly like the U10 but in a pizza box. Close enough. However this is historical computing. ... to use the Sun three button mouse on a PC. I think you can use any mouse you want or even touch screens with Debian. Dennis
Re: xserver problem 9.0-sparc64 netinst
On 12/3/18 2:18 PM, Fred wrote: On 12/03/2018 10:14 AM, Phillip Stevens wrote: Mach64 (PGX24 PGX64) driver is not working. Also Radeon (XVR-100) is not working. ... I don't know what Mach64 is. The computer is a plain U5 with 512K ram. The only card plugged in is a USB card. Should I remove the USB card? Best regards, Fred There were very few options for the old sun ultra5. It was to be a sun experiment into low cost PC-like dirt cheap slapped together low-end workstations. So the graphics options were bottom dollar. The ultra10 had the benefit of actual OpenGL ready hardware but that is another story. So the ultra5 would ship with a 3D RAGE II M64 video graphics ability. However you may also have the bone stock "SunVideo Plus" thing which I can not recall what it was. There was also a thing called the pgx32 and the pgx64. You would need to boot the machine to the firmware ok prompt and look at the device list to know for sure what you really have there. Dennis
Re: Bug#905829: mozjs52: tests fail on sparc64: numeric operations expecting NaN get undefined instead
On 08/10/2018 06:34 AM, Simon McVittie wrote: Source: mozjs52 Version: 52.9.1-1 Severity: normal User: debian-sparc@lists.debian.org Usertags: sparc64 Lots of mozjs52 tests fail on sparc64 because the test does some numeric operation that expects NaN (not a number) as result, but gets undefined back instead, for example: FAILED! Number.NEGATIVE_INFINITY % Number.NEGATIVE_INFINITY = undefined expected: NaN FAILED! VAR1 =-Infinity; VAR2=-Infinity; VAR1 %= VAR2; VAR1 = undefined expected: NaN FAILED! [reported from top level script] testfunc : Expected value 'NaN', Actual value 'undefined' Does sparc64 have an unusual binary representation of NaN and undefined or something? This seems oddly familiar to me. I seem to recall that Sun implemented the Payne and Hanek’s method for range reduction within some elementary functions. I will go look at the SUN fdlibm library source code and see what is there but floating point modulo operations should follow the specification rules here regardless of architecture. I don't think sparc is "special" in this regard. I'll dig around a bit as this feels familiar in some way. Dennis
Re: NETRA Sparc T4-1 to test with
On 08/08/2018 11:27 AM, John Paul Adrian Glaubitz wrote: On 08/08/2018 05:23 PM, Dennis Clarke wrote: pssst ... there is nothing in the silo.conf of netinst.iso for sun4v and that had me wondering. Why though? sun4v is fully backwards-compatible ... Well hey .. everything else under the sun is in there .. except sun4v. pun intended. regardless .. how the heck to netboot this thing ? There have been multiple discussions on this topic on this mailing list. Basically, you need the d-i images from the tarball here: http://ftp.ports.debian.org/debian-ports/pool-sparc64/main/d/debian-installer/ Then set up a TFTP server and let the machine boot the kernel, see: https://www.debian.org/releases/wheezy/sparc/ch05s01.html.en great .. a dance on a Tuesday under a full moon and my mothers birthday. *sigh* ;-) I'll make up a USB thumbdrive and visit the datacenter. Dennis
Re: NETRA Sparc T4-1 to test with
On 08/08/2018 11:03 AM, Jan Engelhardt wrote: On Wednesday 2018-08-08 16:55, John Paul Adrian Glaubitz wrote: On 08/08/2018 04:44 PM, Dennis Clarke wrote: Well yes .. however it is sitting inside a rack in a remote datacenter and that makes life a real drag. Sort of why I like network based install processes. Regardless, looking at /boot/silo.conf in the netinst I don't see any support for sun4v platforms and so this may be just a waste of effort. Umm, what? root@osaka:~# uname -a Linux osaka 4.17.0-1-sparc64-smp #1 SMP Debian 4.17.8-1 (2018-07-20) sparc64 GNU/Linux root@osaka:~# cat /proc/cpuinfo |grep sun type: sun4v MMU Type: Hypervisor (sun4v) root@osaka:~# What makes you think Debian doesn't run on a T4 when we've been running it on a T5 in the past and folk at Oracle even running on an M8?!?! maybe the logic that T4 compares as "less" to both T5 and M8. But psst, don't tell him it also works on T1 and T2. ;-) pssst ... there is nothing in the silo.conf of netinst.iso for sun4v and that had me wondering. regardless .. how the heck to netboot this thing ? dc
Re: NETRA Sparc T4-1 to test with
On 08/08/2018 10:14 AM, John Paul Adrian Glaubitz wrote: On 08/08/2018 04:08 PM, Dennis Clarke wrote: However it is not really clear how to do that over tftp and nfs. I have a bootp server running and can deliver some bootable image to the machine but the whole sparc64-NETINST iso probably won't fly here. Doesn't the T4 have USB ports which you could use to install the operating system from? Well yes .. however it is sitting inside a rack in a remote datacenter and that makes life a real drag. Sort of why I like network based install processes. Regardless, looking at /boot/silo.conf in the netinst I don't see any support for sun4v platforms and so this may be just a waste of effort. Moving on. Dennis
NETRA Sparc T4-1 to test with
Dear sparc64 folks : Happily I have a NETRA Sparc T4-1 here to test with : Netra SPARC T4-1, No Keyboard Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved. OpenBoot 4.38.13, 31.5000 GB memory available, Serial #106357246. Ethernet address 0:10:e0:56:e1:fe, Host ID: 8656e1fe. However it is not really clear how to do that over tftp and nfs. I have a bootp server running and can deliver some bootable image to the machine but the whole sparc64-NETINST iso probably won't fly here. So what is the minimal way to get this going ? Is there ? Dennis
Re: Latest netinst iso
02:01.1 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller (rev 61) 02:01.2 USB controller: VIA Technologies, Inc. USB 2.0 (rev 63) Best regards, Fred The above two USB lines need to go up to the lspci list. Thunderbird had trouble with pasting the large block of text and I didn't notice it had moved those lines. That looks good. Very. You can always do an attach of an xz compressed txt file and that works wonderfully well and saves a lot of space too. Dennis
Re: Latest netinst iso
On 08/07/2018 12:17 PM, Thomas Schmitt wrote: Hi, Frank Scheiner wrote: as my Ultra 10 has a CDROM drive installed instead of a DVDROM drive I was mislead to write "CDROM drive" "DVD" gives a hint of the age of the drive. Everything from this century should be driven by SCSI commands (volumes SPC, SBC, MMC). There must have been old days when cdrecord needed special "drivers" for particular CD burners (see man cdrecord, option driver=) and libcdio was founded to unify the access to CD reader models on GNU/Linux. Jörg Schilling had pretty much everything related to CDROM and DVD drives sorted out .. twenty years ago. Be sure to get the correct sources from : https://sourceforge.net/projects/schilytools/files/ see schily-2018-08-07.tar.bz2 That contains a massive pileof golden bits and tools and even XPG4 ported sources taken from the old OpenSolaris project. Dennis
What is the situation with newer sparc hardware?
There was a problem with the M3000 Fujitsu units and other than that has anyone tried a newer machine? Dennis
Re: Anyone interested in a SunFire V240?
This is not a sales maillist. Also, that machine is not worth the cost of shipping. Dennis
trying the M3000 with Fujitsu SPARC VII+ cpu
Without getting into the silly bits about tftp/rarp setup etc I can tell
you with authority that the file name fetched does NOT have the "SUN4U"
suffix.
Well I was running wireshark elsewhere and watched the whole show up
until packet 15943 :
TFTP: Opcode = 3 (data packet)
TFTP: Data block = 18365 (last block)
TFTP: [ 368 bytes of data ]
The last 62 bytes were :
336: 0001
352: 0011 0003
368: 008f 6df8
384: 01f1
400: 0001
That looks perfect and I did check the sparc64 file.
It was accepted and ack sent :
UDP: - UDP Header -
UDP:
UDP: Source port = 32768
UDP: Destination port = 33105
UDP: Length = 12
UDP: Checksum = ED95
UDP:
TFTP: - Trivial File Transfer Protocol -
TFTP:
TFTP: Opcode = 4 (acknowledgement)
TFTP: Acknowledge block = 18365
Well .. not much good happens after that :-\
{0} ok boot net loglevel=6
Boot device: /pci@0,60/pci@0/pci@1/network@0 File and args: loglevel=6
100 Mbps full duplex Link up
Requesting Internet Address for 8c:73:6e:c0:59:f8
Requesting Internet Address for 8c:73:6e:c0:59:f8
Requesting Internet Address for 8c:73:6e:c0:59:f8
Requesting Internet Address for 8c:73:6e:c0:59:f8
Requesting Internet Address for 8c:73:6e:c0:59:f8
Requesting Internet Address for 8c:73:6e:c0:59:f8
ERROR: Last Trap: Fast Data Access MMU Miss
%TL:1 %TT:68 %TPC:f000ada4 %TnPC:f000ad94 %TSTATE:6a001600
%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )
DSFSR:4280804b ( FV:1 OW:1 PR:1 E:1 TM:1 ASI:80 NC:1 BERR:1 )
DSFAR:fda61000 DSFPAR:4018006ff000 D-TAG:cf6000
I may have been wrong with the param loglevel but I was hoping to see
more than the above.
Dennis
ps: somewhat annoying in that a system reset takes 5 minutes at least.
Resetting...
POST Sequence 01 CPU Check
POST Sequence 02 Banner
LSB#00 (XSB#00-0): POST 2.17.0 (2011/11/17 10:37)
POST Sequence 03 Fatal Check
POST Sequence 04 CPU Register
POST Sequence 05 STICK
POST Sequence 06 MMU
POST Sequence 07 Memory Initialize
POST Sequence 08 Memory
POST Sequence 09 Raw UE In Cache
POST Sequence 0A Floating Point Unit
POST Sequence 0B SC
POST Sequence 0C Cacheable Instruction
POST Sequence 0D Softint
POST Sequence 0E CPU Cross Call
POST Sequence 0F CMU-CH
POST Sequence 10 PCI-CH
POST Sequence 11 Master Device
POST Sequence 12 DSCP
POST Sequence 13 SC Check Before STICK Diag
POST Sequence 14 STICK Stop
POST Sequence 15 STICK Start
POST Sequence 16 Error CPU Check
POST Sequence 17 System Configuration
POST Sequence 18 System Status Check
POST Sequence 19 System Status Check After Sync
POST Sequence 1A OpenBoot Start...
POST Sequence Complete.
SPARC Enterprise M3000 Server, using Domain console
Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved.
Copyright (c) 2012, Oracle and/or its affiliates and Fujitsu Limited.
All rights reserved.
OpenBoot 4.33.5.d, 65536 MB memory installed, Serial #BADCAFFE. :-)
Ethernet address 0:b:5d:e2:6f:f6, Host ID: 80996ff6.
Re: sparc64 debian netboot chicken and egg
On 05/14/2018 05:18 PM, John Paul Adrian Glaubitz wrote: On 05/14/2018 10:46 PM, Dennis Clarke wrote: Oh no worries. I get it that this is a moving picture and nothing is carved in stone. I just wonder if there is a way to get back to a full primary architecture with sparc64 as opposed to a lab project port. It is absolutely possible and has been a subject of discussion for years now. The main blocker is that Debian has not found any hardware sponsor for new SPARC servers. Let me see if I can reach out to some old friends. Dennis ps : Aren't the S-class systems based on a variant of the M7 CPU? yep. not supported. fairly certain of it .. but I'll check
Re: sparc64 debian netboot chicken and egg
On 05/14/2018 04:03 PM, John Paul Adrian Glaubitz wrote: On 05/14/2018 08:37 PM, Dennis Clarke wrote: Looking at https://wiki.debian.org/Sparc64#Network_booting it says : "If you already have a working installation of Debian GNU/Linux Sid for sparc64" nope. So this is chicken and egg here. This is neither official documentation nor did I write this. It's also not the ultimate answer. These instructions just describe one way of setting up GRUB for netboot. Oh no worries. I get it that this is a moving picture and nothing is carved in stone. I just wonder if there is a way to get back to a full primary architecture with sparc64 as opposed to a lab project port. Please don't assume that everything on the Debian wiki is of official character. The wiki is a product of contributors from the community and they don't necessarily know everything when writing such a document. You are very much invited to help improving this documentation though. Oh .. I will. Once I get moving ahead. I think the ppc64 side of life is working well for me and I have gcc 8.1.0 working well over there : https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg01443.html Not a bad result. OT here but I find it annoying that lately gcc 7.3.0 and gcc 8.1.0 both accept assembly input and I can specify -mcpu=970 however gcc utters this down to binutils as : /usr/local/bin/as -v -a64 -mpower4 -maltivec -maltivec -many -mregnames -mbig -o hello_gcc810_mpfr_4.0.1_p6_.o hello_gcc810_mpfr_4.0.1_p6_.s So that -mpower4 there is odd. I am curious what I will see on sparc64. ps: Oracle Linux won't install on anything that isn't a T-class unit or newer M-class gear. pita. Oracle Linux is compiled for sun4v, so lots of classical 64-bit SPARC machines are not usable. Won't work on the new S-class systems either. Any day now I expect John Fowler to walk out the door with a cheque in his hand .. no idea. Dennis
Re: 8e9800 Fast Data Access MMU Miss
On 05/14/2018 04:00 PM, Frank Scheiner wrote: On 05/14/2018 08:27 PM, Dennis Clarke wrote: But as the GRUB2 part alone is already useful for people that are familiar with the supporting service infrastructure, I just finished up this part and put it into the Debian wiki. I will add more information later if need be - I have to check the available information about network services first. The methods described on [1] work for me to network boot my UltraSPARC gear, but you need kernel and initramfs as separate files. I will go take a look at that. Perhaps even separate the NFS and TFTP services into two machines just because I can. I don't think that there is any need to worry about the RARP and IP address bits for now as that all seems to happen in three quick packets from the forth firmware on most sparc units with a "net boot" command. Note that the tftp request does not require a suffix ".SUN4U" on the filename. Ah yes, you're correct. I corrected that part just now. Not sure where I got the idea from, maybe I mixed things with older Sun systems (e.g. sun4m, sun4d, sun4c). The older gear did attach a suffix however we need to go back to the IPX and ye sparc20. I actually have a quad ross sparc20 laying about but no reason to even try. The battery died on that a long time ago and I have to edit the firmware every time I boot it. I am curious if the M3000/M4000 gear utters the same tftp request. Who knows for sure ... I don't. Easy to check. dc
regarding the M3000 issue on the wiki
It may be worth testing an M3000 unit that has a Fujitsu SPARC-VII+ processor in it. I have one : $ psrinfo -pv The physical processor has 8 virtual processors (0-7) SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz) System PROM revisions: -- OBP 4.33.5.d 2012/07/18 06:55 $ prtconf -v | grep "Memory" Memory size: 65536 Megabytes So if the cpu is the issue then it may be interesting to look at. Dennis
