Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
M4000 failing to boot Debian Sparc64
30 views
Skip to first unread message
Vocalía Infraestructura TIC CEEINA
Jul 2, 2023, 7:00:04 AM7/2/23
to
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.
Maybe this is an unknown incompatibility, or we are missing some steps when installing.
¿Any ideas on how to fix this? ¿Has anyone experienced something similar?
Thanks in advance!
Kind regards.
Frank Scheiner
Jul 2, 2023, 9:51:10 AM7/2/23
to
Hi,
On 02.07.23 12: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 )/
> /debian-10.0-sparc64-NETINST-1.iso/ and /debian-9.0-sparc64-NETINST-1.iso/.
works on e.g. SPARC64 V (tested on a PRIMEPOWER 250) is GRUB2.
AFAIK the Linux kernel only works (fully) on Sun's (Ultra)SPARC (I, II,
IIi/e, III, IIIi, IV and T)s and Fujitsu's SPARC64 X.
> ¿Any ideas on how to fix this? ¿Has anyone experienced something similar?
It would require some development effort. OpenBSD has support for those
machines, though, if that could be an alternative for you.
Cheers,
Frank
On 02.07.23 12: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:
>
> /%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/,
>
> We have tried with the following ISO images:
> /debian-10.0-sparc64-NETINST-1.iso/ and /debian-9.0-sparc64-NETINST-1.iso/.
>
> Maybe this is an unknown incompatibility, or we are missing some steps
> when installing.
No, it just does not work on those machines. E.g. the only thing that
> Maybe this is an unknown incompatibility, or we are missing some steps
> when installing.
works on e.g. SPARC64 V (tested on a PRIMEPOWER 250) is GRUB2.
AFAIK the Linux kernel only works (fully) on Sun's (Ultra)SPARC (I, II,
IIi/e, III, IIIi, IV and T)s and Fujitsu's SPARC64 X.
> ¿Any ideas on how to fix this? ¿Has anyone experienced something similar?
machines, though, if that could be an alternative for you.
Cheers,
Frank
Vocalía Infraestructura TIC CEEINA
Jul 2, 2023, 11:00:04 AM7/2/23
to
Hi Frank,
Thank you for your fast answer. I also thought when installing that it was an incompatibility problem with the processor architecture, as you stated.
However, having a look at the wiki (https://wiki.debian.org/Sparc64) it seems to me that machines with a sun4u SPARC VII+ processor should be able to run it, right? Our M4000 has a VII+ processor.
Maybe I have not fully understood the wiki or your message, therefore sorry if I'm wrong.
Best regards.
Frank Scheiner
Jul 2, 2023, 12:20:32 PM7/2/23
to
Hi,
On 02.07.23 16:35, Vocalía Infraestructura TIC CEEINA wrote:
> Hi Frank,
>
> Thank you for your fast answer. I also thought when installing that it
> was an incompatibility problem with the processor architecture, as you
> stated.
>
> However, having a look at the wiki (https://wiki.debian.org/Sparc64
> <https://wiki.debian.org/Sparc64>) it seems to me that machines with a
in the Debian Wiki? Maybe by comparing them to what was posted about a
M3000 with SPARC64 VII on [1] and SPARC64 V on [2], we can conclude if
support for SPARC64 VII+ is any better than for those other processors.
[1]:
https://oss.oracle.com/pipermail/linux-sparc-users/2017-October/000027.html
[2]: https://lists.debian.org/debian-sparc/2017/09/msg00017.html
You don't happen to have a SPARC64 X based system for testing? I think I
never saw a dmesg from such a system, too.
> Maybe I have not fully understood the wiki or your message, therefore
> sorry if I'm wrong.
I went through the history of changes and the one that adds the
information about SPARC64 processors ([3]) was done by an Alex McWhirter.
[3]: https://wiki.debian.org/Sparc64?action=diff&rev1=25&rev2=26
Checking my email archive I actually even asked him (via
alexmc...@triadic.us, though not sure if that is the correct
address) exactly about this change, but never got a reply IIRC.
Cheers,
Frank
On 02.07.23 16:35, Vocalía Infraestructura TIC CEEINA wrote:
> Hi Frank,
>
> Thank you for your fast answer. I also thought when installing that it
> was an incompatibility problem with the processor architecture, as you
> stated.
>
> However, having a look at the wiki (https://wiki.debian.org/Sparc64
> sun4u SPARC VII+ processor should be able to run it, right? Our M4000
> has a VII+ processor.
Can you post the kernel messages for your boot, so we can reference it
> has a VII+ processor.
in the Debian Wiki? Maybe by comparing them to what was posted about a
M3000 with SPARC64 VII on [1] and SPARC64 V on [2], we can conclude if
support for SPARC64 VII+ is any better than for those other processors.
[1]:
https://oss.oracle.com/pipermail/linux-sparc-users/2017-October/000027.html
[2]: https://lists.debian.org/debian-sparc/2017/09/msg00017.html
You don't happen to have a SPARC64 X based system for testing? I think I
never saw a dmesg from such a system, too.
> Maybe I have not fully understood the wiki or your message, therefore
> sorry if I'm wrong.
information about SPARC64 processors ([3]) was done by an Alex McWhirter.
[3]: https://wiki.debian.org/Sparc64?action=diff&rev1=25&rev2=26
Checking my email archive I actually even asked him (via
alexmc...@triadic.us, though not sure if that is the correct
address) exactly about this change, but never got a reply IIRC.
Cheers,
Frank
Vocalía Infraestructura TIC CEEINA
Jul 2, 2023, 12:50:04 PM7/2/23
to
Hi,
Sure. This is what we are getting when trying to install Debian 9.0 Sparc64:
---------------------------------------------------
{0} ok boot cdrom
Boot device: /pci@0,600000/pci@0/pci@8/pci@0/scsi@1/disk@3,0:f File and args:
SILO Version 1.4.14
\
Welcome to Debian GNU/Linux sid!
This is a Debian installation CDROM, built on 20180404-20:54.
Keep it once you have installed your system, as you can boot from it
to repair the system on your hard disk if that ever becomes necessary.
WARNING: You should completely back up all of your hard disks before
proceeding. The installation procedure can completely and irreversibly
erase them! If you haven't made backups yet, remove the rescue CD from
the drive and press L1-A to get back to the OpenBoot prompt.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted
by applicable law.
[ ENTER - Boot install ] [ Type "expert" - Boot into expert mode ]
[ Type "rescue" - Boot into rescue mode ]
boot:
Allocated 64 Megs of memory at 0x40000000 for kernel
Loaded kernel version 4.15.11
Loading initial ramdisk (14093161 bytes at 0x3CFFE000000 phys, 0x40C00000 virt)...
\
ERROR: Last Trap: Division by Zero
%TL:1 %TT:28 %TPC:43056c %TnPC:430570 %TSTATE:1180001603
%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )
{0} ok
---------------------------------------------------
Let me know if you need any additional details.
Unfortunately, we do not have any SPARC64 X server to perform the test. Sorry.
Regards.
Dennis Clarke
Jul 2, 2023, 2:40:03 PM7/2/23
to
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*
> 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:
>
> *%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*
>
> We have tried with the following ISO images:
> 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
%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )
(2) from the default install option
Loading ...
ERROR: Last Trap: Division by Zero
%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )
{0} ok
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
Four decades in production systems.
John Paul Adrian Glaubitz
Jul 2, 2023, 5:30:04 PM7/2/23
to
Hi Dennis!
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.
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.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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.
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.
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.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Dennis Clarke
Jul 3, 2023, 5:30:05 AM7/3/23
to
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
> 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.
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 a while.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
John Paul Adrian Glaubitz
Jul 3, 2023, 5:50:04 AM7/3/23
to
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.
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.
> 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.
and create a Bountysource campaign to sponsor the work. I assume, you can get
it done for maybe $5000-$10.000.
Dennis Clarke
Jul 5, 2023, 11:10:04 AM7/5/23
to
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.
0 new messages