Discussion:
Creating sparc64 installation images
John Paul Adrian Glaubitz
2015-12-23 08:42:49 UTC
Permalink
Hi!

We have had some discussion in private mails and on other lists
regarding the creation of installation for sparc64.

I am currently working on creating new installation images on an
old Sun Blade 100 workstation I borrowed tomorrow following a guide
that was created by Helge Deller (CC):
https://parisc.wiki.kernel.org/index.php/How_to_create_Debian_unstable_iso_images

Helge already successfully built images for alpha and hppa [1], however
those still require a dedicated mirror where some arch-specific files
are stored, see [2].

Thus, we should try to improve on the process such that the generated
ISOs can actually be installed stand-alone (besides the mirror downloads
that the netinst image is performing).

Any further help and input is appreciated! Getting new sparc64
installation images is actually important for us since we should update
the kernels on the buildds as soon as possible since the outdated
3.2.0 kernels might be responsible for many of the segfaults we are
seeing during builds [3].

If anyone makes any progress or questions creating those images, please
post them on the list, prerably in this thread.

Cheers,
Adrian
[1] ftp://ftp.debian-ports.org/debian-cd/
[2] ftp://ftp.debian-ports.org/debian-cd/alpha/README
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765567#83
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2015-12-23 09:48:29 UTC
Permalink
but could you give us a pointer to where the netinst
image can be found, compatible hardware, what sources.list should be,
and where testers should report issues.
There are no ISO installations images for sparc64 yet that I know of.
This is why we are currently working on creating these. I was referring
to the existing installer images which Helge Deller created for the
Debian alpha and hppa ports [1].

Adrian
[1] ftp://ftp.debian-ports.org/debian-cd/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hermann Lauer
2015-12-23 09:39:22 UTC
Permalink
I don't think I can usefully help since I'm too far down the Debian
management/development learning curve (and have rather a lot of other stuff
on my plate), but could you give us a pointer to where the netinst image can
Me too - exacly the same situation at the moment.
be found, compatible hardware, what sources.list should be, and where
testers should report issues.
I have installed sparc hardware since over 10 years only via netboot images
and may try a few basic netinst tests on Enterprise class systems if that
would help.

Thanks for all the work and merry X-mas,
Hermann
--
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: ***@iwr.uni-heidelberg.de
Frans van Berckel
2015-12-23 13:03:49 UTC
Permalink
Post by Hermann Lauer
I don't think I can usefully help since I'm too far down the Debian
management/development learning curve (and have rather a lot of other stuff
on my plate), but could you give us a pointer to where the
netinst image can
Me too - exacly the same situation at the moment.
be found, compatible hardware, what sources.list should be, and where
testers should report issues.
I have installed sparc hardware since over 10 years only via
netboot images
and may try a few basic netinst tests on Enterprise class systems if that
would help.
10+ years but only using ISO, in part as a conscious decision to
reduce
the load on the Debian servers. However I got into deep water in the
Squeeze/Wheezy eras, some of which I've not really managed to
extricate
myself from.
I've got an E4500 and a Netra 20 here which I'd like to get Debian
back onto, at present they're OpenSXCE.
Post by Hermann Lauer
Thanks for all the work and merry X-mas,
Seconded :-)
My two cents. Let's look into a real solution guy's. We need a clean
and easy bootable Sparc station, with build tools to create a ISO. But
that's isn't available yet. It looks like being in a chicken or the egg
situation. So we need a environment te create one. Using a Debian tftp
boot server, cloud be a solution. The needed parts are.

* A network switch and some cat 5 cables
* A littering i386 or amd64 machine or laptop, with a Debian supported
network interface
* A USB stick, 2GB or 4GB, what's available
* A Debian minimal i386, including kernel and Grub bootloader
bootstraped to -> [usb-stick] [1]
* A dhcp, tftp, rarp and nfs server service, for letting the Sparc
station able to boot -> [usb-stick]
* Config the dhcp, tftp, rarp and nfs server [2] or [3] or [4]
* A Debian minimal Sparc64 /nfs chroot, included build tools and
kernel, no boot loader needed -> [usb-stick]

[1] https://gist.github.com/tr3buchet/6407920
[2] https://help.ubuntu.com/community/Installation/Sparc
[3] http://znark.com/tech/netbootsparc.html
[4] https://wiki.gentoo.org/wiki/Sparc/Netboot

So create a small network by patching the cat 5 cables into the switch
and computers. Next boot the laptop with the created usb-stick. And
boot the Sparc64 station by tftp network. You can tail the laptop log
files to see how the boot flows. Do some debugging getting it to run.

# boot net

Next start building the CD image, local on Sparc.

Thanks,


Frans van Berckel
John Paul Adrian Glaubitz
2015-12-23 13:11:31 UTC
Permalink
Post by Frans van Berckel
My two cents. Let's look into a real solution guy's. We need a clean
and easy bootable Sparc station, with build tools to create a ISO. But
that's isn't available yet. It looks like being in a chicken or the egg
situation.
How is that a chicken and egg solution when we have been building
sparc64 packages over the last years? We can create a bootable
sparc64 ISO image, we have all the tools we need.

All the sparc machines that people are running these days are
running a 64-bit kernel (uname -m is sparc64) and you can
simply create a sparc64 chroot on any sparcbox to build a sparc64
debian-installer and ISO images.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frans van Berckel
2015-12-23 13:31:17 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Frans van Berckel
My two cents. Let's look into a real solution guy's. We need a
clean and easy bootable Sparc station, with build tools to create a
ISO. But that's isn't available yet. It looks like being in a
chicken or the egg situation.
How is that a chicken and egg solution when we have been building
sparc64 packages over the last years? We can create a bootable
sparc64 ISO image, we have all the tools we need.
So what's the question left?
Post by John Paul Adrian Glaubitz
All the sparc machines that people are running these days are
running a 64-bit kernel (uname -m is sparc64) and you can
simply create a sparc64 chroot on any sparcbox to build a sparc64
debian-installer and ISO images.
I know, having sparc64 running.


Frans van Berckel
John Paul Adrian Glaubitz
2015-12-23 18:20:40 UTC
Permalink
Post by Frans van Berckel
Post by John Paul Adrian Glaubitz
How is that a chicken and egg solution when we have been building
sparc64 packages over the last years? We can create a bootable
sparc64 ISO image, we have all the tools we need.
So what's the question left?
As I said in my initial mail to the list, there are still some issues
in Helge's image build process that need to be resolved which arise
because we're building an ISO for an unofficial port.

For example, it gets tricky because silo and silo-installer are no
longer in the official Debian archives and therefore have to be
added manually.
Post by Frans van Berckel
Post by John Paul Adrian Glaubitz
All the sparc machines that people are running these days are
running a 64-bit kernel (uname -m is sparc64) and you can
simply create a sparc64 chroot on any sparcbox to build a sparc64
debian-installer and ISO images.
I know, having sparc64 running.
Good to know. If you see any issues, please report them. Were you able
to update your kernel, btw?

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2015-12-24 10:41:33 UTC
Permalink
As a slight aside, what's the situation with SILO booting Solaris these
days?
I have no idea but you can just try it yourself, here is the most
http://git.kernel.org/cgit/linux/kernel/git/davem/silo.git
As for the image building process, my Sun Blade 100 at work is
currently not reachable so I might have to go into the office tomorrow
and check what's wrong before leaving for the holidays so I will be
able to build the images remotely.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2015-12-24 20:27:33 UTC
Permalink
I'm not in a position to try this right now, but the last time I looked
at it- Spring 2014- it required ufsboot which is no longer shipped with
Solaris.
"The silo package installs the SILO boot loader. SILO installs in the
system's boot block. You can configure it to boot Linux for SPARC,
Oracle Solaris, and SunOS."

So it is supposed to work, apparently, according to Oracle.

Adrian
[1]
https://oss.oracle.com/linux-sparc/docs/RELEASE-NOTES-1.0-en.html#ol_chgs_sparc
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Wim Coekaerts
2015-12-24 20:34:50 UTC
Permalink
Silo works great

We are very close to finishing grub2 for sparc as well and once that's tested we are going to switch to grub2 for Linux for sparc so then we can do netboot
Post by John Paul Adrian Glaubitz
I'm not in a position to try this right now, but the last time I looked
at it- Spring 2014- it required ufsboot which is no longer shipped with
Solaris.
"The silo package installs the SILO boot loader. SILO installs in the
system's boot block. You can configure it to boot Linux for SPARC,
Oracle Solaris, and SunOS."
So it is supposed to work, apparently, according to Oracle.
Adrian
[1]
https://oss.oracle.com/linux-sparc/docs/RELEASE-NOTES-1.0-en.html#ol_chgs_sparc
--
.''`. John Paul Adrian Glaubitz
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2015-12-24 20:41:58 UTC
Permalink
Post by Wim Coekaerts
Silo works great
I have tested it on Linux only so far, but without a single issue!
Post by Wim Coekaerts
We are very close to finishing grub2 for sparc as well and once
that's tested we are going to switch to grub2 for Linux for sparc
so then we can do netboot
Wow, that's actually awesome to hear! Great work!

Oracle's efforts with Linux on sparc might really end up turning sparc64
into an official Debian port :). Just need to get a few package here and
there fix like Firefox and Thunderbird which currently fail to build
from source.

Btw, have all the changes mentioned in [1] been upstreamed? I'm
especially very interested in the changes made to gcc to enable
multiarch support because we are still having issues with that
in Debian which is why it's disabled in the Debian gcc packages
for sparc64 [2], line 18.

Adrian
Post by Wim Coekaerts
[1]
https://oss.oracle.com/linux-sparc/docs/RELEASE-NOTES-1.0-en.html#ol_chgs_sparc
Post by Wim Coekaerts
[2]
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-5/debian/patches/sparc-force-cpu.diff?view=markup
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Wim Coekaerts
2015-12-24 21:04:39 UTC
Permalink
Not all has been upstream'ed yet, but whatever hasn't been, certainly
the plan/intent to do it. I do think that most if not all of the
gcc/elf/binutils stuff has gone up though. Jose (who's on the list) can
be more specific :)
Post by John Paul Adrian Glaubitz
Post by Wim Coekaerts
Silo works great
I have tested it on Linux only so far, but without a single issue!
Post by Wim Coekaerts
We are very close to finishing grub2 for sparc as well and once
that's tested we are going to switch to grub2 for Linux for sparc
so then we can do netboot
Wow, that's actually awesome to hear! Great work!
Oracle's efforts with Linux on sparc might really end up turning sparc64
into an official Debian port :). Just need to get a few package here and
there fix like Firefox and Thunderbird which currently fail to build
from source.
Btw, have all the changes mentioned in [1] been upstreamed? I'm
especially very interested in the changes made to gcc to enable
multiarch support because we are still having issues with that
in Debian which is why it's disabled in the Debian gcc packages
for sparc64 [2], line 18.
Adrian
Post by Wim Coekaerts
[1]
https://oss.oracle.com/linux-sparc/docs/RELEASE-NOTES-1.0-en.html#ol_chgs_sparc
Post by Wim Coekaerts
[2]
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-5/debian/patches/sparc-force-cpu.diff?view=markup
Bryce
2015-12-25 12:59:02 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Wim Coekaerts
Silo works great
I have tested it on Linux only so far, but without a single issue!
Jose and I spent soooo many weeks getting that to work (mostly Jose for the
assembler stuff). Unaligned access problems galore and it's not trivial to
figure out when your in the first stages of booting and have no usable debugger
to work with.
Post by John Paul Adrian Glaubitz
Post by Wim Coekaerts
We are very close to finishing grub2 for sparc as well and once
that's tested we are going to switch to grub2 for Linux for sparc
so then we can do netboot
-groan- I'm being flogged to death already about grub2
I'd like to get grub2 to accept passing boot arguments similar to silo though.

ie {0} ok boot linux_normal nomsi ip=dhcp ks=http://x.y.z/lazy_sod.ks

rather than having to crack open the menu entry and edit it from console. It was
nice to be able to edit boot params on the fly with eeprom from inside linux and
reboot... but I'm lazy that way)
There are a few more items not fixed yet that relate to booting solaris from
grub2 but they're on the back burner as getting Linux going is the priority for
the moment (which it does do)
Post by John Paul Adrian Glaubitz
Wow, that's actually awesome to hear! Great work!
Oracle's efforts with Linux on sparc might really end up turning sparc64
into an official Debian port :). Just need to get a few package here and
Please correct me if I'm wrong, but I think the Oracle Linux is only for
virtualised guests so might have gotchas on bare metal.
you're wrong 8)
it's capable of running as baremetal. In fact that how I originally started it.
I've been driving that original baremetal box for 3 years now, so I can say that
it's reasonably robust.
There are visualization drivers fixed up/built that allow for the kernel to run
in a Solaris driven LDM environment (in fact, thats the way we usually develop
in-house since we can toss the running LDM's and recreate a new bootable
environment from scratch inside 3 minutes flat). Wim will happily flog you a
virtualization solution for a build platform though 8) -cough-
Post by John Paul Adrian Glaubitz
there fix like Firefox and Thunderbird which currently fail to build
from source.
https://github.com/OpenSXCE-org
"FireFox-43-port-for-all-OpenSolaris-distros Runs on all distros, supports
FlashPlugins (all versions) on fixed Illumos kernels Updated Nov 18, 2015"
actually it's xulrunner that is the pita. something in the xpshell is still
unaligned and causes it to fault. From my perspective, I'm being hammered to
provide a server release so the desktop space apps like firefox are low on my
priority list. Also I'm having to work with the RedHAT/Fedora src codebase so
I'm also working with older sw that needs,.. persuasion, to vaguely work.
Post by John Paul Adrian Glaubitz
Btw, have all the changes mentioned in [1] been upstreamed? I'm
especially very interested in the changes made to gcc to enable
multiarch support because we are still having issues with that
in Debian which is why it's disabled in the Debian gcc packages
for sparc64 [2], line 18.
As Wim says, that is a question more comfortably answered by Jose when the
eggnog wears off.
Mmm,.. I think I should shut up at this point before Wim smacks me around with
the toffee hammer as to the roadmap regarding L4S (linux for sparc)
John Paul Adrian Glaubitz
2015-12-25 14:34:37 UTC
Permalink
Post by Bryce
Jose and I spent soooo many weeks getting that to work (mostly Jose for the
assembler stuff). Unaligned access problems galore and it's not trivial to
figure out when your in the first stages of booting and have no usable debugger
to work with.
Heh, that's how programmers always had to do it in the old days ;-).
Glad you finally figured it out and thanks a lot for fixing all these
Post by Bryce
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730478
Post by John Paul Adrian Glaubitz
Post by Wim Coekaerts
We are very close to finishing grub2 for sparc as well and once
that's tested we are going to switch to grub2 for Linux for sparc
so then we can do netboot
-groan- I'm being flogged to death already about grub2
I'd like to get grub2 to accept passing boot arguments similar to silo though.
ie {0} ok boot linux_normal nomsi ip=dhcp ks=http://x.y.z/lazy_sod.ks
So, GRUB would actually be able to get the arguments from the OpenBoot
firmware if I understand correctly? Sounds pretty nifty!
Post by Bryce
rather than having to crack open the menu entry and edit it from console. It was
nice to be able to edit boot params on the fly with eeprom from inside linux and
reboot... but I'm lazy that way)
There are a few more items not fixed yet that relate to booting solaris from
grub2 but they're on the back burner as getting Linux going is the priority for
the moment (which it does do)
Yeah, no hurry. I am already very glad we have a working silo on
sparc64 :).
Post by Bryce
Please correct me if I'm wrong, but I think the Oracle Linux is only for
virtualised guests so might have gotchas on bare metal.
you're wrong 8)
it's capable of running as baremetal. In fact that how I originally started it.
I've been driving that original baremetal box for 3 years now, so I can say that
it's reasonably robust.
Good to hear. I also expected there would be no limitations regarding
real hardware since the binaries are in the end just sparcv9 binaries,
just the kernel might be trimmed down for virtualization with all the
unnecessary drivers removed.
Post by Bryce
There are visualization drivers fixed up/built that allow for the kernel to run
in a Solaris driven LDM environment (in fact, thats the way we usually develop
in-house since we can toss the running LDM's and recreate a new bootable
environment from scratch inside 3 minutes flat). Wim will happily flog you a
virtualization solution for a build platform though 8) -cough-
Again, great to hear. I'm very glad you guys are around on debian
Post by Bryce
Post by John Paul Adrian Glaubitz
there fix like Firefox and Thunderbird which currently fail to build
from source.
https://github.com/OpenSXCE-org
"FireFox-43-port-for-all-OpenSolaris-distros Runs on all distros, supports
FlashPlugins (all versions) on fixed Illumos kernels Updated Nov 18, 2015"
actually it's xulrunner that is the pita. something in the xpshell is still
unaligned and causes it to fault. From my perspective, I'm being hammered to
provide a server release so the desktop space apps like firefox are low on my
priority list. Also I'm having to work with the RedHAT/Fedora src codebase so
I'm also working with older sw that needs,.. persuasion, to vaguely work.
Yeah, I guess it's xulrunner as the problem affects both Firefox and
Thunderbird. From the error message it looks like there are some V8+
optimizations that fail on V9 but I'm not sure:

/«PKGBUILDDIR»/ipc/chromium/src/base/singleton.h: In static member
function 'static void Singleton<Type, Traits,
DifferentiatingType>::OnExit(void*)':
/«PKGBUILDDIR»/ipc/chromium/src/base/singleton.h:172:61: error: cannot
convert 'base::subtle::AtomicWord* {aka long int*}' to 'volatile
Atomic32* {aka volatile int*}' for argument '1' to
'base::subtle::Atomic32 base::subtle::NoBarrier_AtomicExchange(volatile
Atomic32*, base::subtle::Atomic32)'
base::subtle::NoBarrier_AtomicExchange(&instance_, 0)));
https://buildd.debian.org/status/fetch.php?pkg=iceweasel&arch=sparc64&ver=38.5.0esr-1&stamp=1450458305
Post by Bryce
Post by John Paul Adrian Glaubitz
Btw, have all the changes mentioned in [1] been upstreamed? I'm
especially very interested in the changes made to gcc to enable
multiarch support because we are still having issues with that
in Debian which is why it's disabled in the Debian gcc packages
for sparc64 [2], line 18.
As Wim says, that is a question more comfortably answered by Jose when the
eggnog wears off.
No hurries, enjoy your holidays guys!
Post by Bryce
Mmm,.. I think I should shut up at this point before Wim smacks me around with
the toffee hammer as to the roadmap regarding L4S (linux for sparc)
Haha :-). Just put Debian on SPARC on the roadmap as well and there
will be many more Linux for SPARC users in no time!

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frans van Berckel
2015-12-25 16:15:17 UTC
Permalink
<snip>
Post by John Paul Adrian Glaubitz
Post by Bryce
Please correct me if I'm wrong, but I think the Oracle Linux is
only for virtualised guests so might have gotchas on bare metal.
you're wrong 8)
it's capable of running as baremetal. In fact that how I originally started it.
I've been driving that original baremetal box for 3 years now, so I
can say that it's reasonably robust.
Good to hear. I also expected there would be no limitations regarding
real hardware since the binaries are in the end just sparcv9
binaries, just the kernel might be trimmed down for virtualization
with all the unnecessary drivers removed.
Post by Bryce
There are visualization drivers fixed up/built that allow for the
kernel to run in a Solaris driven LDM environment (in fact, thats
the way we usually develop in-house since we can toss the running
LDM's and recreate a new bootable environment from scratch inside 3
minutes flat). Wim will happily flog you a virtualization solution
for a build platform though 8) -cough-
Again, great to hear. I'm very glad you guys are around on debian
Hi Wim,

With that in mind, would it be possible to port OpenStack? Letting it
install on Linux for Sparc. Too virtualize lxd/lxc containers with the
nova-compute module? I know OpenStack is supported by Solaris, true.
But my question is about native Linux on baremetal.

Thanks,


Frans van Berckel
Wim Coekaerts
2015-12-25 17:05:33 UTC
Permalink
Re: openstack

That's on the (long) to do list. lxc by itself works great. I just built
lxc-2.0 and (as expected) runs flawlessly.

We also have the ldom host drivers (control domain) in the kernel (our
4.1 kernel) (to be upstreamed) and have been working on the ldm manager
code for linux.

This will all take a bit of time but certainly working towards full
openstack support both for containers and for ldom (for both Linux host
and guests).

I'd love to have docker as well but no golang yet and gccgo seems to
have a few issues still but, again, it will happen.

Fun stuff.
Post by Frans van Berckel
<snip>
Post by John Paul Adrian Glaubitz
Post by Bryce
Please correct me if I'm wrong, but I think the Oracle Linux is
only for virtualised guests so might have gotchas on bare metal.
you're wrong 8)
it's capable of running as baremetal. In fact that how I originally started it.
I've been driving that original baremetal box for 3 years now, so I
can say that it's reasonably robust.
Good to hear. I also expected there would be no limitations regarding
real hardware since the binaries are in the end just sparcv9
binaries, just the kernel might be trimmed down for virtualization
with all the unnecessary drivers removed.
Post by Bryce
There are visualization drivers fixed up/built that allow for the
kernel to run in a Solaris driven LDM environment (in fact, thats
the way we usually develop in-house since we can toss the running
LDM's and recreate a new bootable environment from scratch inside 3
minutes flat). Wim will happily flog you a virtualization solution
for a build platform though 8) -cough-
Again, great to hear. I'm very glad you guys are around on debian
Hi Wim,
With that in mind, would it be possible to port OpenStack? Letting it
install on Linux for Sparc. Too virtualize lxd/lxc containers with the
nova-compute module? I know OpenStack is supported by Solaris, true.
But my question is about native Linux on baremetal.
Thanks,
Frans van Berckel
Jose E. Marchesi
2015-12-27 13:45:44 UTC
Permalink
Btw, have all the changes mentioned in [1] been upstreamed? I'm
especially very interested in the changes made to gcc to enable
multiarch support because we are still having issues with that
in Debian which is why it's disabled in the Debian gcc packages
for sparc64 [2], line 18.

There is nothing to upstream regarding the toolchain multiarch support
in GCC. We have 4.4.7, 4.9.1 and svn (GCC 6) built with multilib.

Of course that assumes you already bootstraped, which is a fun activity.
If your starting point is a 64-bit glibc and a GCC with no multilib
support, you will have to do something similar to what we did:

We started with a 64-bit glibc and a GCC built with --disable-multilib,
i.e. no support for building nor running 32-bit binaries at all. Our
goal was to have:
- A 32bit glibc (runtime + devel).
- A 64bit glibc (runtime + devel)
- A multilib 64bit GCC.
- A multilib 64bit binutils.

So, the first step was to get the installed pure 64-bit GCC able to
build 32-bit binaries. I cherry-picked the following stuff from an old
Fedora 12 repository with sparcv9 (32-bit) packages (the Debian packages
/lib/ld-linux.so.2 -> /lib/ld-linux.so.2
/lib/libc-2.11.1.so -> /lib/libc-2.11.1.so
/lib/libc.so.6 -> /lib/libc.so.6 (link to above)
/usr/lib/crt1.o -> /usr/lib/crt1.o
/usr/lib/crti.o -> /usr/lib/crti.o
/usr/lib/crtn.o
/usr/lib/libc_nonshared.a -> /usr/lib/libc_nonshared.a
/usr/lib/libc.so -> /usr/lib/libc.so
/usr/lib/libphtread.so -> /usr/lib/libpthread.so
/usr/lib/libpthread_nonshared.a -> /usr/lib/libpthread_nonshared.a
/usr/include/gnu/stubs-32.h -> /usr/include/gnu/stubs-32.h
/usr/lib/libgcc_s-4.4.3-20100121.so.1 -> /usr/lib/libgcc_s-4.4.3-20100121.so.1
/usr/lib/libgcc_s.so.1 -> /usr/lib/libgcc_s.so.1
Before getting the 32-bit GCC libraries, we had to create a new
directory 32/, and modified the specs file of the installed GCC to look
for them in that directory:

*multilib:
. !m64 !m32;.:../lib64 m64 !m32;32:../lib !m64 m32;

Then we populated the directory with the Fedora 12 GCC 32-bit libraries:

/usr/lib/gcc/sparc64-redhat-linux/4.4.3/libgcc.a -> /usr/lib/gcc/sparc64-redhat-linux/4.4.7/32/libgcc.a
/usr/lib/gcc/sparc64-redhat-linux/4.4.3/crtbegin.o -> /usr/lib/gcc/sparc64-redhat-linux/4.4.7/32/crtbegin.o
/usr/lib/gcc/sparc64-redhat-linux/4.4.3/crtend.o -> /usr/lib/gcc/sparc64-redhat-linux/4.4.7/32/crtend.o
/usr/lib/gcc/sparc64-redhat-linux/4.4.3/crtbeginT.o -> /usr/lib/gcc/sparc64-redhat-linux/4.4.7/32/crtbeginT.o
/usr/lib/gcc/sparc64-redhat-linux/4.4.3/crtendS.o -> /usr/lib/gcc/sparc64-redhat-linux/4.4.7/32/crtendS.o
/usr/lib/gcc/sparc64-redhat-linux/4.4.3/crtbeginS.o -> /usr/lib/gcc/sparc64-redhat-linux/4.4.7/32/crtbeginS.o
/usr/lib/gcc/sparc64-redhat-linux/4.4.3/crtfastmath.o -> /usr/lib/gcc/sparc64-redhat-linux/4.4.7/32/crtfastmath.o

And voila. At this point gcc -m32 worked.

Now that we had a system capable of building 32-bit sparc binaries it
was time to build sparcv9 glibc packages. For that purpos we had to do
some extensive hacking in the glibc.spec file in order to convert
sparcv9 into a proper auxiliary architecture to sparc64 (note that the
RedHat sparc distro was 32bit with support for 64bit, while L4S is 64bit
with support for 32bit). This is mostly irrelevant to you, as you use
different packaging/multilib logic in Debian.

Once we had sparcv9 (32bit) glibc packages built with the installed
mutant compiler, we could build the bootstrapped GCC with enabled
multilib.

Let me know if you need help for the bootstrapping, and I will try to
help.
John Paul Adrian Glaubitz
2015-12-25 18:21:46 UTC
Permalink
Hi Wim!
Post by Wim Coekaerts
Silo works great
I am currently in the progress of building a current version of debian
installer for sparc64 and all I need now is silo.

Are all your fixes in Dave's repo on git.kernel.org [1] or do I have
to look elsewhere?

Cheers,
Adrian
Post by Wim Coekaerts
[1] http://git.kernel.org/cgit/linux/kernel/git/davem/silo.git
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Wim Coekaerts
2015-12-25 18:41:15 UTC
Permalink
I think they were sent but might not have gone in

look at
http://yum.oracle.com/repo/linux_sparc64/latest/silo-1.4.14-4.0.18.el6.src.rpm

%changelog
* Wed Mar 25 2015 Philip Copeland <***@oracle.com> 1.4.14-4.0.18
- During the package install silo is unpacked but no config file
exists leading to a error in the install log which is *cosmetic*
Mild alteration to check for the default config file

* Wed Mar 11 2015 Philip Copeland <***@oracle.com> 1.4.14-4.0.17
- force silo to rebuild the sector lists for itself after an update
without this, the .b files where occasionally moving rather than
being overwritten in place leading to failed boots (SIProgram..)

* Thu Feb 19 2015 Philip Copeland <***@oracle.com> 1.4.14-4.0.16
- We can use GPT now but we need to stop silo complaining about
label magics.
- Use git in the specfile if needed
Post by John Paul Adrian Glaubitz
Hi Wim!
Post by Wim Coekaerts
Silo works great
I am currently in the progress of building a current version of debian
installer for sparc64 and all I need now is silo.
Are all your fixes in Dave's repo on git.kernel.org [1] or do I have
to look elsewhere?
Cheers,
Adrian
Post by Wim Coekaerts
[1] http://git.kernel.org/cgit/linux/kernel/git/davem/silo.git
John Paul Adrian Glaubitz
2015-12-25 19:08:09 UTC
Permalink
Post by Wim Coekaerts
I think they were sent but might not have gone in
Hmm, ok.

So, I just started right away with silo from git and the build initially
failed with "-m32" which was still in the debian package's
configuration. I used the most recent silo package for "sparc" and
updated the source from git. Then enabled the build for "sparc64" and
Post by Wim Coekaerts
https://people.debian.org/~glaubitz/silo_1.4.14+git20141019-1.build
gcc -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing
-DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000 -fno-stack-protector -c
divdi3.S
divdi3.S: Assembler messages:
divdi3.S:105: Error: detected global register use not covered by
.register pseudo-op

Any suggestions?
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2015-12-25 20:25:03 UTC
Permalink
Post by John Paul Adrian Glaubitz
Any suggestions?
Alright, apparently, it has to be -m32. I also had to add "-mcpu=v8"
and set gcc to gcc-4.9 as well as add -I/usr/include/sparc64-linux-gnu
to CFLAGS and manually copy stubs-32.h into this directory.

Using gcc-4.9 and the manual copying of stubs-32.h were necessary
because gcc-multilib is currently half broken on Debian sparc64
and hence things like stubs-32.h and libgcc.a are missing for
gcc-5 on sparc64.

Complete changes are:

* New upstream release.
* debian/control:
- Add sparc64 to the list of architectures.
- Add libc6-dev-sparc, lib32gcc-4.9-dev and gcc-4.9 to B-D.
* debian/rules:
- Set CC to "gcc-4.9 -m32 -mcpu=v8".
* New debian/patches/sparc64-build-fixes.patch:
- Add -I/usr/include/sparc64-linux-gnu to CFLAGS.

Just uploaded silo for sparc64 to unreleased.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bryce
2015-12-25 20:51:02 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by John Paul Adrian Glaubitz
Any suggestions?
Alright, apparently, it has to be -m32. I also had to add "-mcpu=v8"
and set gcc to gcc-4.9 as well as add -I/usr/include/sparc64-linux-gnu
to CFLAGS and manually copy stubs-32.h into this directory.
Using gcc-4.9 and the manual copying of stubs-32.h were necessary
because gcc-multilib is currently half broken on Debian sparc64
and hence things like stubs-32.h and libgcc.a are missing for
gcc-5 on sparc64.
* New upstream release.
- Add sparc64 to the list of architectures.
- Add libc6-dev-sparc, lib32gcc-4.9-dev and gcc-4.9 to B-D.
- Set CC to "gcc-4.9 -m32 -mcpu=v8".
- Add -I/usr/include/sparc64-linux-gnu to CFLAGS.
Just uploaded silo for sparc64 to unreleased.
Adrian
eh wot?
I built silo as pure 64bit, but since you can't 'chainload' from 32bit silo to
64bit silo...

WAAAAAY back (and I'm not going into the politics and who to blame etc) the
decision was that we'd make a 64bit distro since, being oracle, we were
manufacturing 64bit hardware an had EOL'd all the 32bit HW. It's true that
originally at the very start I'd to create silo as a *static* 32bit binary so
that it would work on the 64bit machines without needing to drag in shared 32bit
libs, but Jose and I eventually kicked it into the realm of direct 64bit, and
that was simply because we were asked to make a pure 64bit distro (everyone
needs a 64bit 'ls' command! ha!)

So are your options here a bit twisted by the need to support 32 and 64bit at
the same time? In all honestly to prevent your sanity points going negative, I
would advise separating 32 and 64 into two ISO's, at least for now. There be
dragons to worry about during the initial boot when you start looking at more
exotic sparc HW like T5, T7 (of course you could argue what linux enthusiast
would have the finances to own one of them,..*glare at wim*...). Later on when
there is a bit less churn, you can revisit marrying the 32 and 64 onto the same
ISO image.

You'll also hit the same issue when it comes to grub2. All our work to date has
been in 64bit space so some assembly reversioning to V8 from the hand crafted
code may be needed.
John Paul Adrian Glaubitz
2015-12-25 21:06:57 UTC
Permalink
Post by Bryce
eh wot?
I built silo as pure 64bit, but since you can't 'chainload' from 32bit
silo to 64bit silo...
I tried building 64-bit natively but that failed with:

gcc -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing
-DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000 -fno-stack-protector -c
divdi3.S
divdi3.S: Assembler messages:
divdi3.S:105: Error: detected global register use not covered by
.register pseudo-op

Then I looked at http://git.kernel.org/cgit/linux/kernel/git/davem
/silo.git/tree/Rules.make and saw "CC=gcc -m32" and I assumed silo
always has to be 32 bits.

I haven't built silo before and I just assumed this has to be correct,
especially since silo has always been built on Debian with -m32 and
it always loaded a 64-bit sparc64 kernel.

If loading a 64-bit kernel from a 32-bit silo is not possible, how
did it work in Debian in the sparc port (which uses a 64-bit kernel)?

If that's not right, please let me know what's the proper way, and
please, please, please get all your silo fixes upstreamed so I can
access them easily.
Post by Bryce
So are your options here a bit twisted by the need to support 32 and
64bit at the same time?
No, I want to create a pure 64-bit sparc64 installation image.

Any help and input is *HIGHLY* appreciated!

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bryce
2015-12-25 22:09:46 UTC
Permalink
eh wot? I built silo as pure 64bit, but since you can't 'chainload' from
32bit silo to 64bit silo...
I tried building 64-bit natively but that failed with: gcc -Os -Wall -I.
-I../include -fomit-frame-pointer -fno-strict-aliasing -DSMALL_RELOC=0x280000
-DLARGE_RELOC=0x380000 -fno-stack-protector -c divdi3.S divdi3.S: Assembler
messages: divdi3.S:105: Error: detected global register use not covered by
.register pseudo-op
For a start I'll refer you to
http://docs.oracle.com/cd/E19620-01/805-6015/chap3-15/index.html

lesse,..

[***@ca-qasparc10 ~]# cd /tmp; export PKG=silo ; rm -rf /tmp/$PKG ; svn co
http://ca-svn.us.oracle.com/svn/repos/rhel4/$PKG/branches-6/el6-u5-sparc64
$PKG ; cd /tmp/$PKG
[***@ca-qasparc10 silo]# bs
Wrote: /tmp/silo/silo-1.4.14-4.0.18.el6.src.rpm
[***@ca-qasparc10 silo]# rpmbuild --recompile
/tmp/silo/silo-1.4.14-4.0.18.el6.src.rpm
...

gcc -static -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing
-DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000 -fno-stack-protector -c ffs.c
*gcc -static -Os -Wall -I. -I../include -fomit-frame-pointer
-fno-strict-aliasing -DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000
-fno-stack-protector -c divdi3.S*
gcc -static -Os -Wall -I. -I../include -fomit-frame-pointer
-fno-strict-aliasing -DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000
-fno-stack-protector -c udivdi3.S
gcc -static -Os -Wall -I. -I../include -fomit-frame-pointer
-fno-strict-aliasing -DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000
-fno-stack-protector bin2h.c -o bin2h
make[1]: Leaving directory `/root/rpmbuild/BUILD/silo-1.4.14/common'
make[1]: Entering directory `/root/rpmbuild/BUILD/silo-1.4.14/first'
gcc -static -Os -Wall -I. -I../include -fomit-frame-pointer
-fno-strict-aliasing -DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000
-fno-stack-protector -c first.S -o first.o
ld -m elf64_sparc -N -Ttext 0x4000 -o first first.o
nm first | grep -v '*ABS*' | sort > first.map
strip first
elftoaout -o first.b first

...
Wrote: /root/rpmbuild/RPMS/sparc64/silo-1.4.14-4.0.18.el6.sparc64.rpm

(Joy,.. still compiles 8) )

lets see your error message is about
divdi3.S around line 105...

I don't think we did any hacking in there, the only ref we have is

[***@ca-qasparc10 silo]# grep /divdi3.S *patch
silo-1.4.14-build-as-64bit.patch:diff -r -u silo-1.4.14/common/divdi3.S
silo-1.4.14-bias/common/divdi3.S
silo-1.4.14-build-as-64bit.patch:--- silo-1.4.14/common/divdi3.S 2012-12-06
04:09:00.000000000 +0100
silo-1.4.14-build-as-64bit.patch:+++ silo-1.4.14-bias/common/divdi3.S
2013-05-22 15:09:47.457000000 +0200

Assuming that your src looks the same, is this around where it went wrong?


97 ! Got carry from n. Subtract next step to cancel this carry.
98 bne 4b
99 addcc %o1,%o1,%o1 ! shift n1n0 and a 0-bit in lsb
100 sub %i0,%o4,%i0
101 3: xnor %o1,0,%o1
102 b .LL50
103 mov 0,%o2
104 .LL46:
*105 cmp %o4,0*
106 bne .LL85
107 mov %i0,%o2
108 mov 1,%o0
109 call .udiv,0
110 mov 0,%o1
111 mov %o0,%o4
112 mov %i0,%o2
113 .LL85:
114 mov 0,%g3
115 mov 32,%g1
116 subcc %g3,%o4,%g0
117 1: bcs 5f
118 addxcc %o2,%o2,%o2 ! shift n1n0 and a q-bit in lsb
119 sub %g3,%o4,%g3 ! this kills msb of n
John Paul Adrian Glaubitz
2015-12-25 22:23:42 UTC
Permalink
Post by Bryce
I don't think we did any hacking in there, the only ref we have is
Line 105 looks different in silo git, looks like you made some changes:
http://git.kernel.org/cgit/linux/kernel/git/davem/silo.git/tree/common/divdi3.S#n105

All my tests were performed on Dave's silo git repository. Can you diff
your source against git here?

PS: Going to be soon, it's almost midnight here :).
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bryce
2015-12-25 22:33:25 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Bryce
I don't think we did any hacking in there, the only ref we have is
http://git.kernel.org/cgit/linux/kernel/git/davem/silo.git/tree/common/divdi3.S#n105
All my tests were performed on Dave's silo git repository. Can you diff
your source against git here?
PS: Going to be soon, it's almost midnight here :).
Ah 8) (long time since I was in silo)
yeah we just added the .register directives and Jose spotted a problem where
the stack offset bias wasn't being catered for when in 64 bit builds



[***@ca-qasparc10 silo-1.4.14]# diff -u divdi3.S common/divdi3.S

--- divdi3.S 2015-12-25 14:29:13.000000000 -0800
+++ common/divdi3.S 2015-12-25 13:37:46.166753226 -0800
@@ -17,9 +17,18 @@
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */

+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+#define STACK_BIAS 2047
+#endif
+
.data
.align 8
.globl __clz_tab
+ .register %g2,#scratch
+ .register %g3,#scratch
+
__clz_tab:
.byte 0,1,2,2,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
.byte 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
@@ -36,7 +45,7 @@
.align 4
.globl __divdi3
__divdi3:
- save %sp,-104,%sp
+ save %sp,-STACK_BIAS-104,%sp
cmp %i0,0
bge .LL40
mov 0,%l4
John Paul Adrian Glaubitz
2015-12-26 19:44:15 UTC
Permalink
Post by Bryce
Ah 8) (long time since I was in silo)
yeah we just added the .register directives and Jose spotted a problem where
the stack offset bias wasn't being catered for when in 64 bit builds
(...)
Could you try to get this patch upstreamed? I will try to apply it in
the meantime.

Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2015-12-26 19:50:18 UTC
Permalink
Post by John Paul Adrian Glaubitz
Could you try to get this patch upstreamed? I will try to apply it in
the meantime.
The patch isn't complete in any case, udivid3.S has to be patched as
well:

gcc -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing
-DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000 -fno-stack-protector -c
udivdi3.S
udivdi3.S: Assembler messages:
udivdi3.S:202: Error: detected global register use not covered by
.register pseudo-op
udivdi3.S:203: Error: detected global register use not covered by
.register pseudo-op
udivdi3.S:203: Error: detected global register use not covered by
.register pseudo-op
udivdi3.S:238: Error: detected global register use not covered by
.register pseudo-op

Could you give me the complete patch to get silo compile on sparc64?

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2015-12-26 21:31:39 UTC
Permalink
Post by John Paul Adrian Glaubitz
The patch isn't complete in any case, udivid3.S has to be patched as
Ok, the full patch is actually simple, once you know what to fix.

Attaching my version.

Cheers,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bryce
2015-12-26 22:04:27 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by John Paul Adrian Glaubitz
Could you try to get this patch upstreamed? I will try to apply it in
the meantime.
The patch isn't complete in any case, udivid3.S has to be patched as
gcc -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing
-DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000 -fno-stack-protector -c
udivdi3.S
udivdi3.S:202: Error: detected global register use not covered by
.register pseudo-op
udivdi3.S:203: Error: detected global register use not covered by
.register pseudo-op
udivdi3.S:203: Error: detected global register use not covered by
.register pseudo-op
udivdi3.S:238: Error: detected global register use not covered by
.register pseudo-op
Could you give me the complete patch to get silo compile on sparc64?
Adrian
err,..it was a slew of patches
you could just grab the src we made available? As for upstream,.. Wim doesn't
pay me enough for the necessary asbestos suit. We do have one but I dunno who 's
wearing it atm. (probably Rob)

Session transcript using x86 since we don't care about compiling, we just want
the src:

[***@emerald ~]# mkdir work
[***@emerald ~]# cd work
[***@emerald work]# git clone
https://git.kernel.org/pub/scm/linux/kernel/git/davem/silo.git
Cloning into 'silo'...
remote: Counting objects: 1395, done.
remote: Total 1395 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1395/1395), 517.80 KiB | 526.00 KiB/s, done.
Resolving deltas: 100% (978/978), done.
Checking connectivity... done.
[***@emerald work]#
[***@emerald work]# wget
http://yum.oracle.com/repo/linux_sparc64/latest/silo-1.4.14-4.0.18.el6.src.rpm
--2015-12-26 21:28:52--
http://yum.oracle.com/repo/linux_sparc64/latest/silo-1.4.14-4.0.18.el6.src.rpm
Resolving yum.oracle.com (yum.oracle.com)... 213.123.252.136, 213.123.252.145
Connecting to yum.oracle.com (yum.oracle.com)|213.123.252.136|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 788058 (770K) [application/x-rpm]
Saving to: ‘silo-1.4.14-4.0.18.el6.src.rpm’

silo-1.4.14-4.0.18. 100%[=====================>] 769.59K 1020KB/s in 0.8s

2015-12-26 21:28:53 (1020 KB/s) - ‘silo-1.4.14-4.0.18.el6.src.rpm’ saved
[788058/788058]

[***@emerald work]# # there are cleaner ways of doing this
[***@emerald work]# rpmbuild --rebuild silo-1.4.14-4.0.18.el6.src.rpm
--nodeps # will FAIL but we don't care
[***@emerald work]# rpmbuild -bp --nodeps /root/rpmbuild/SPECS/silo.spec
[***@emerald work]# diff -ruN silo /root/rpmbuild/BUILD/silo-1.4.14 -x ".git*"
| tee 64bit-Oracle-Xmas.patch | wc -l
2361
[***@emerald work]# ls -l 64bit-Oracle-Xmas-patch
-rw-r--r--. 1 root root 68666 Dec 26 21:39 64bit-Oracle-Xmas.patch

Note: this is a consolidated patch! as such you loose the context of the reasons
why various patches were done. You should really look at the spec file changelog
/ individual patches, to understand our madness.

--------------------------------------------------------------------------------
John Paul Adrian Glaubitz
2015-12-26 22:18:07 UTC
Permalink
Post by Bryce
err,..it was a slew of patches
you could just grab the src we made available? As for upstream,.. Wim
doesn't pay me enough for the necessary asbestos suit. We do have one
but I dunno who 's wearing it atm. (probably Rob)
Is davem such a grumpy person that you don't dare to send him your
patches? I'm pretty sure, he'll take all the changes you made since
guys have the knowledge to do proper improvements to the code and
test it on bleeding-edge hardware.
Post by Bryce
Note: this is a consolidated patch! as such you loose the context of the
reasons why various patches were done. You should really look at the
spec file changelog / individual patches, to understand our madness.
Thanks for the patch but this is really a lot and it's almost too much
for me alone to be able to digest this. Is there any way we can get
this upstreamed? Maybe I can bribe you with some German beer or
chocolate? ;-)

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bryce
2015-12-26 22:36:43 UTC
Permalink
Is davem such a grumpy person that you don't dare to send him your patches?
I'm pretty sure, he'll take all the changes you made since guys have the
knowledge to do proper improvements to the code and test it on bleeding-edge
hardware.
No. DaveM is usually very busy getting hammered by a range of various folk
(usually kernel related) and I appreciate that everyone has their own coding
styles/practices, priorities, mannerisms that may conflict. It's something that
all the top end maintainers have to wrestle with.

There are coding style guidelines for the kernel and for some GNU projects,
however, in the struggle to get working code those are occasionally thrown out
the window. From a maintainers POV it's ugly to see several coding styles while
trying to read code. Myself, I come from a Pascal/Ada background and my coding
style and indentation/commenting and code flow reflects that.

It doesn't matter that the code does what it says on the side of the tin (and
actually works), if I submit code to a maintainer, if they end up having to
rewrite a patch to fit style guidelines, it can be irksome and if they're
handling a large stack of OTHER submitted patches from a large number of folk
they're quite likely to decide that they don't have the time to deal with it
and push back requesting a restyled patch. Keep in mind that may not just be
down to the flow of text but how you use variables eg something trivial like
x=++var; vs x=var++;

Anyway what I'm trying to say here is that I've not sanitized those patches and
I wouldn't throw them at DaveM as yet until I had (free time pending)

Phil
=--=
John Paul Adrian Glaubitz
2015-12-27 00:12:16 UTC
Permalink
Post by Bryce
Note: this is a consolidated patch! as such you loose the context of the
reasons why various patches were done. You should really look at the
spec file changelog / individual patches, to understand our madness.
The patch applies cleanly as expected but the build eventually fails
with linker errors. Looks like there are some linker flags messed
up.

This was compiled on Debian on sparc64, attaching the tail of the
log.

Any idea?

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Jose E. Marchesi
2015-12-27 13:52:07 UTC
Permalink
So, I just started right away with silo from git and the build initially
failed with "-m32" which was still in the debian package's
configuration. I used the most recent silo package for "sparc" and
updated the source from git. Then enabled the build for "sparc64" and
Post by Wim Coekaerts
https://people.debian.org/~glaubitz/silo_1.4.14+git20141019-1.build
gcc -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing
-DSMALL_RELOC=0x280000 -DLARGE_RELOC=0x380000 -fno-stack-protector -c
divdi3.S
divdi3.S: Assembler messages:
divdi3.S:105: Error: detected global register use not covered by
.register pseudo-op

Any suggestions?

Please make sure you have all the patches below applied. They not only
port the assembly from v8+ to v9, but also fix some runtime problems
with sign extensions, structure packing and others.

diff -u -r silo-1.4.14/Rules.make silo-1.4.14-foo/Rules.make
--- silo-1.4.14/Rules.make 2013-05-14 14:06:46.302000002 +0200
+++ silo-1.4.14-foo/Rules.make 2013-05-14 14:07:44.057000002 +0200
@@ -2,9 +2,9 @@
IMGVERSION=0.99
SHELL=/bin/bash
RM=rm -f
-# We want to force 32-bit builds
-CC=gcc -static -m32
-LD=ld -static -m elf32_sparc
+# We want to force 64-bit builds
+CC=gcc
+LD=ld -m elf64_sparc
AS=as
STRIP=strip
NM=nm
diff -r -u silo-1.4.14/common/jmp.S silo-1.4.14-bias/common/jmp.S
--- silo-1.4.14/common/jmp.S 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14-bias/common/jmp.S 2013-05-22 15:09:54.465000000 +0200
@@ -18,7 +18,13 @@
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA. */

-#define _SV save %sp, -0x40, %sp
+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+# define STACK_BIAS 2047
+#endif
+
+#define _SV save %sp, -STACK_BIAS-0x40, %sp
#define _RV restore
#define FLUSH_ALL_WINDOWS \
_SV; _SV; _SV; _SV; _SV; _SV; _SV; \
@@ -46,7 +52,7 @@
FLUSH_ALL_WINDOWS
ld [%o0], %o7 /* Return PC. */
ld [%o0 + 4], %fp /* Saved SP. */
- sub %fp, 64, %sp /* Allocate a register save area. */
+ sub %fp, 64+STACK_BIAS, %sp /* Allocate a register save area. */
tst %o1
be,a 1f
mov 1, %o1
diff -r -u silo-1.4.14/common/divdi3.S silo-1.4.14-bias/common/divdi3.S
--- silo-1.4.14/common/divdi3.S 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14-bias/common/divdi3.S 2013-05-22 15:09:47.457000000 +0200
@@ -17,9 +17,18 @@
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */

+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+#define STACK_BIAS 2047
+#endif
+
.data
.align 8
.globl __clz_tab
+ .register %g2,#scratch
+ .register %g3,#scratch
+
__clz_tab:
.byte 0,1,2,2,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5
.byte 6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6
@@ -36,7 +45,7 @@
.align 4
.globl __divdi3
__divdi3:
- save %sp,-104,%sp
+ save %sp,-STACK_BIAS-104,%sp
cmp %i0,0
bge .LL40
mov 0,%l4
diff -r -u silo-1.4.14/common/udivdi3.S silo-1.4.14-bias/common/udivdi3.S
--- silo-1.4.14/common/udivdi3.S 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14-bias/common/udivdi3.S 2013-05-22 15:09:36.701000000 +0200
@@ -17,11 +17,19 @@
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */

+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+# define STACK_BIAS 2047
+#endif
.text
.align 4
.globl __udivdi3
+ .register %g2,#scratch
+ .register %g3,#scratch
+
__udivdi3:
- save %sp,-104,%sp
+ save %sp,STACK_BIAS-104,%sp
mov %i3,%o3
cmp %i2,0
bne .LL40
diff -r -u silo-1.4.14/second/muldi3.S silo-1.4.14-bias/second/muldi3.S
--- silo-1.4.14/second/muldi3.S 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14-bias/second/muldi3.S 2013-05-22 14:32:12.011000000 +0200
@@ -17,11 +17,19 @@
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */

+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+# define STACK_BIAS 2047
+#endif
+
.text
.align 4
.globl __muldi3
+ .register %g2,#scratch
+ .register %g3,#scratch
__muldi3:
- save %sp, -104, %sp
+ save %sp, -STACK_BIAS-104, %sp
wr %g0, %i1, %y
sra %i3, 0x1f, %g2
and %i1, %g2, %g2
diff -r -u silo-1.4.14/second/crt0.S silo-1.4.14-bias/second/crt0.S
--- silo-1.4.14/second/crt0.S 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14-bias/second/crt0.S 2013-05-22 15:34:57.235000000 +0200
@@ -21,6 +21,12 @@
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA. */

+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+# define STACK_BIAS 2047
+#endif
+
#define COPY jmpl %o7 + (copy - _start), %l7

.text
@@ -82,7 +88,11 @@
sub %l0, 16, %l0
sethi %hi(gzminpi), %l1
add %l1, %i3, %l1
+#if __WORDSIZE == 32
st %l0, [%l1 + %lo(gzminpi)]
+#else
+ stx %l0, [%l1 + %lo(gzminpi)]
+#endif

/* Jump to relocated code */
sethi %hi(_end), %l0
@@ -121,12 +131,15 @@

! Set up a stack
setup_stack:
- save %i0,-120,%sp
-
+ save %i0,-STACK_BIAS-120,%sp
tst %i4
be 0f
sethi %hi(gzminpi+0x100000), %l0
+#if __WORDSIZE == 32
ld [%l0 + %lo(gzminpi)], %l1
+#else
+ ldx [%l0 + %lo(gzminpi)], %l1
+#endif
sethi %hi(LARGE_RELOC), %l2
1: lduh [%l1], %l3
add %l1, 2, %l1
@@ -147,7 +160,11 @@
add %l3, 16, %l3
ba 3b
stb %l3, [%l2]
+#if __WORDSIZE == 32
4: st %l1, [%l0 + %lo(gzminpi)]
+#else
+4: stx %l1, [%l0 + %lo(gzminpi)]
+#endif

! Call my_main() to start the whole thingie up

diff -u -r silo-1.4.14-orig/common/console.c silo-1.4.14/common/console.c
--- silo-1.4.14-orig/common/console.c 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14/common/console.c 2013-05-03 15:57:14.419000002 +0200
@@ -27,7 +27,7 @@
i = inc;
break;
case PROM_P1275:
- if (p1275_cmd ("read", 3, prom_stdin, &inc, 1) == 1)
+ if (p1275_cmd ("read", 3, (unsigned int) prom_stdin, &inc, 1) == 1)
i = inc;
break;
}
@@ -55,7 +55,7 @@
break;
case PROM_P1275:
outc = c;
- if (p1275_cmd ("write", 3, prom_stdout, &outc, 1) == 1)
+ if (p1275_cmd ("write", 3, (unsigned int) prom_stdout, &outc, 1) == 1)
i = 0;
break;
}
@@ -93,7 +93,7 @@
(*(romvec->pv_v2devops).v2_dev_write)(prom_stdout, s, len);
break;
case PROM_P1275:
- p1275_cmd ("write", 3, prom_stdout, s, len);
+ p1275_cmd ("write", 3, (unsigned int) prom_stdout, s, len);
break;
}
}
diff -u -r silo-1.4.14-orig/common/prom.c silo-1.4.14/common/prom.c
--- silo-1.4.14-orig/common/prom.c 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14/common/prom.c 2013-05-03 16:51:48.214000002 +0200
@@ -196,7 +196,7 @@
P1275_ARG_64B(3) | P1275_ARG_64B(4) |
P1275_ARG_64B(6) | 7,
"map",
- prom_get_mmu_ihandle(),
+ (unsigned int) prom_get_mmu_ihandle(),
mode,
size,
vaddr,
@@ -211,7 +211,7 @@
p1275_cmd("call-method",
P1275_ARG_64B(2) | P1275_ARG_64B(3) | 4,
"unmap",
- prom_get_mmu_ihandle(),
+ (unsigned int) prom_get_mmu_ihandle(),
size,
vaddr);
}
diff -u -r silo-1.4.14-orig/common/tree.c silo-1.4.14/common/tree.c
--- silo-1.4.14-orig/common/tree.c 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14/common/tree.c 2013-05-03 15:58:48.773000002 +0200
@@ -22,7 +22,7 @@
if (prom_vers != PROM_P1275)
cnode = prom_nodeops->no_child(node);
else
- cnode = p1275_cmd ("child", 1, node);
+ cnode = p1275_cmd ("child", 1, (unsigned int) node);

if (cnode == 0 || cnode == -1)
return 0;
@@ -43,7 +43,7 @@
if (prom_vers != PROM_P1275)
sibnode = prom_nodeops->no_nextnode(node);
else
- sibnode = p1275_cmd ("peer", 1, node);
+ sibnode = p1275_cmd ("peer", 1, (unsigned int) node);

if (sibnode == 0 || sibnode == -1)
return 0;
@@ -64,7 +64,7 @@
if (prom_vers != PROM_P1275)
ret = prom_nodeops->no_proplen(node, prop);
else
- ret = p1275_cmd ("getproplen", 2, node, prop);
+ ret = p1275_cmd ("getproplen", 2, (unsigned int) node, prop);
}
return ret;
}
@@ -85,7 +85,7 @@
if (prom_vers != PROM_P1275)
ret = prom_nodeops->no_getprop(node, prop, buffer);
else
- ret = p1275_cmd ("getprop", 4, node, prop, buffer, bufsize);
+ ret = p1275_cmd ("getprop", 4, (unsigned int) node, prop, buffer, bufsize);
}
return ret;
}
diff -u -r silo-1.4.14/second/file.c silo-1.4.14-hack/second/file.c
--- silo-1.4.14/second/file.c 2013-05-13 20:29:47.933000002 +0200
+++ silo-1.4.14-hack/second/file.c 2013-05-13 20:15:19.583000002 +0200
@@ -193,7 +193,7 @@
}
last_blockcnt = -1;
}
- if ((char *)filebuffer + (block_cnt + ((*blocknr) ? (blockcnt - last_blockcnt - 1) : 0)) * bs > filelimit) {
+ if ((unsigned int)filebuffer + (block_cnt + ((*blocknr) ? (blockcnt - last_blockcnt - 1) : 0)) * bs > filelimit) {
silo_fatal("Image too large to fit in destination");
return BLOCK_ABORT;
}
diff -r -u silo-1.4.14/first-isofs/crt0.S silo-1.4.14-bias/first-isofs/crt0.S
--- silo-1.4.14/first-isofs/crt0.S 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14-bias/first-isofs/crt0.S 2013-05-22 14:33:09.908000000 +0200
@@ -21,6 +21,12 @@
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA. */

+#if __WORDSIZE == 32
+# define STACK_BIAS 0
+#else
+# define STACK_BIAS 2047
+#endif
+
#define COPY jmpl %o7 + (copy - _start), %l7

.text
@@ -76,7 +82,7 @@
! Set up a stack
setup_stack:
set 0x400000, %l1
- save %l1, -64, %sp
+ save %l1, -STACK_BIAS-64, %sp

! Call cd_main() to start the whole thingie up

diff -u -r silo-1.4.14-orig/first-isofs/isofs.c silo-1.4.14/first-isofs/isofs.c
--- silo-1.4.14-orig/first-isofs/isofs.c 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14/first-isofs/isofs.c 2013-05-03 17:05:03.463000002 +0200
@@ -114,7 +114,7 @@
break;

case PROM_P1275:
- p1275_cmd("close", 1, fd);
+ p1275_cmd("close", 1, (unsigned)fd);
break;
};
}
@@ -141,7 +141,7 @@

if (seekp != offset) {
if (prom_vers == PROM_P1275) {
- if (p1275_cmd("seek", P1275_ARG_64B(2) | 3, fd, 0, offset) == -1)
+ if (p1275_cmd("seek", P1275_ARG_64B(2) | 3, (unsigned)fd, 0, offset) == -1)
return -1;
} else {
if ((*romvec->pv_v2devops.v2_dev_seek)
@@ -152,7 +152,7 @@
}

if (prom_vers == PROM_P1275)
- ret = p1275_cmd ("read", 3, fd, data, size);
+ ret = p1275_cmd ("read", 3, (unsigned)fd, data, size);
else
ret = (*romvec->pv_v2devops.v2_dev_read) (fd, data, size);

diff -u -r silo-1.4.14-orig/second/disk.c silo-1.4.14/second/disk.c
--- silo-1.4.14-orig/second/disk.c 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14/second/disk.c 2013-05-06 15:18:07.303000002 +0200
@@ -79,7 +79,7 @@

fd = p1275_cmd ("open", 1, device);
if ((unsigned)(fd + 1) > 1) {
- node = p1275_cmd ("instance-to-package", 1, fd);
+ node = p1275_cmd ("instance-to-package", 1, (unsigned)fd);
/*
* Don't use our argument due to devalias.
* Alas, flash has no device_type property.
@@ -301,7 +301,7 @@
}
if (seekp != offset) {
if (prom_vers == PROM_P1275) {
- if ((rc = p1275_cmd ("seek", P1275_ARG_64B(2) | 3, fd, 0, offset)) == -1)
+ if ((rc = p1275_cmd ("seek", P1275_ARG_64B(2) | 3, (unsigned) fd, 0, offset)) == -1)
return -1;
} else {
if ((*romvec->pv_v2devops.v2_dev_seek) (fd, (unsigned)(offset >> 32), (unsigned)offset) == -1)
@@ -311,7 +311,7 @@
}
}
if (prom_vers == PROM_P1275) {
- rc = p1275_cmd ("read", 3, fd, buff, size);
+ rc = p1275_cmd ("read", 3, (unsigned) fd, buff, size);
} else {
int i;
for (i = 0; i < 2; i++) {
@@ -355,7 +355,7 @@
case PROM_V3:
(*romvec->pv_v2devops.v2_dev_close) (fd); break;
case PROM_P1275:
- p1275_cmd ("close", 1, fd); break;
+ p1275_cmd ("close", 1, (unsigned) fd); break;
}
}
*currentdevice = 0;
diff -u -r silo-1.4.14/silo/silo.c silo-1.4.14-struct/silo/silo.c
--- silo-1.4.14/silo/silo.c 2012-12-06 04:09:00.000000000 +0100
+++ silo-1.4.14-struct/silo/silo.c 2013-05-24 14:18:26.564000002 +0200
@@ -107,14 +107,14 @@

/* This is just so that we don't have to fight with incompatible ufs_fs.h headers */
#define SILO_UFS_MAGIC 0x00011954
-struct silo_ufs_super_block {
+struct __attribute__((packed)) silo_ufs_super_block {
unsigned char xxx1[36];
unsigned int fs_fsize;
unsigned char xxx2[1332];
unsigned int fs_magic;
};

-struct sun_disklabel {
+struct __attribute__((packed)) sun_disklabel {
unsigned char info[128]; /* Informative text string */
unsigned char spare[292]; /* Boot information etc. */
unsigned short rspeed; /* Disk rotational speed */
@@ -127,9 +127,9 @@
unsigned short ntrks; /* Tracks per cylinder */
unsigned short nsect; /* Sectors per track */
unsigned char spare3[4]; /* Even more magic... */
- struct sun_partition {
- unsigned long start_cylinder;
- unsigned long num_sectors;
+ struct __attribute__((packed)) sun_partition {
+ unsigned int start_cylinder;
+ unsigned int num_sectors;
} partitions[8];
unsigned short magic; /* Magic number */
unsigned short csum; /* Label xor'd checksum */
@@ -205,7 +205,7 @@
{
struct silo_ufs_super_block ufs;
struct ext2_super_block sb; /* Super Block Info */
- struct romfs_super_block {
+ struct __attribute__((packed)) romfs_super_block {
__u32 word0;
__u32 word1;
__u32 size;
John Paul Adrian Glaubitz
2015-12-27 15:02:01 UTC
Permalink
Post by Jose E. Marchesi
Please make sure you have all the patches below applied. They not only
port the assembly from v8+ to v9, but also fix some runtime problems
with sign extensions, structure packing and others.
Builds fine, thank you. I'll upload a fixed package to Debian unreleased
later.

I'll send another mail regarding the gcc multilib issue shortly.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frans van Berckel
2015-12-27 20:52:11 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Frans van Berckel
I know, having sparc64 running.
Good to know. If you see any issues, please report them. Were you
able to update your kernel, btw?
No. I did install the 4.3.0-1, as well the 4.4.0-rc6 from experimental.
But both kernels do a Oops on the QLogic 2200 driver. And there for the
root drive isn't mounting. Ending at the initramfs prompt now. Talking
about a Sun Blade 1000 Workstation. I installed the firmware needed.

Look like the same problem seen some months a go with 4.1.x. It's nice
to know the same sparc64 partition does boot with the old 3.2.0-2 one.

Am I able to save a dmesg.txt on a usb stick? Question; what kernel
modules do I need to modprobe exactly. Because I did test some stuff
today, but wasn't able with the default initramfs getting usb mounted.

Thanks,


Frans van Berckel
Frans van Berckel
2015-12-27 21:58:29 UTC
Permalink
Post by Frans van Berckel
No. I did install the 4.3.0-1, as well the 4.4.0-rc6 from
experimental. But both kernels do a Oops on the QLogic 2200 driver.
And there for the root drive isn't mounting. Ending at the initramfs
prompt now. Talking about a Sun Blade 1000 Workstation. I installed
the firmware needed.
Look like the same problem seen some months a go with 4.1.x. It's
nice to know the same sparc64 partition does boot with the old 3.2.0
-2 one.
Am I able to save a dmesg.txt on a usb stick? Question; what kernel
modules do I need to modprobe exactly. Because I did test some stuff
today, but wasn't able with the default initramfs getting usb
mounted.
Yes, done it, because busybox has ftpput. So was able to set a ip and
'put' the output on the server.

[82.082182] ERROR(0): Cheetah error trap taken afsr[0000080000000000]
afar[000007fd00100040] TL1(0)

and later on

[82.128341] CPU: 0 PID: 86 Comm: systemd-udevd Not tainted 4.4.0-rc6
-sparc64-smp #1 Debian 4.4~rc6-1~exp1

Attaching dmesg-sparc64.txt. Including a call trace.

Thanks,

Frans van Berckel
John Paul Adrian Glaubitz
2015-12-28 12:12:23 UTC
Permalink
Hi Frans!
Post by Frans van Berckel
Yes, done it, because busybox has ftpput. So was able to set a ip and
'put' the output on the server.
You can also get all the kernel output during boot with the help of
netconsole which just requires a working network card to work and
even works with broken graphics drivers and helps when your machine
Post by Frans van Berckel
https://wiki.ubuntu.com/Kernel/Netconsole
Attaching dmesg-sparc64.txt. Including a call trace.
You should report this as a bug in the kernel bug tracker with the
component "SPARC64", see:
https://bugzilla.kernel.org/enter_bug.cgi?product=Platform%20Specific%2FHardware
Post by Frans van Berckel
https://www.kernel.org/doc/man-pages/reporting_code_bugs.html
Cheers,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Frans van Berckel
2015-12-28 12:48:54 UTC
Permalink
Post by John Paul Adrian Glaubitz
Hi Frans!
<snap>
Post by John Paul Adrian Glaubitz
Post by Frans van Berckel
Attaching dmesg-sparc64.txt. Including a call trace.
You should report this as a bug in the kernel bug tracker with the
https://bugzilla.kernel.org/enter_bug.cgi?product=Platform%20Specific
%2FHardware
Done, bug 110081 - Cheetah error trap taken afsr[0000080000000000]
afar[000007fd00100040] TL1(0)

https://bugzilla.kernel.org/show_bug.cgi?id=110081

Thanks,


Frans van Berckel

Continue reading on narkive:
Loading...