Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d
Le dim. 20 déc. 2020 à 09:54, Julian Calaby a écrit : > If I want to run them, assuming the hardware still works, I need to > netboot them as I cannot find working, compatible HDDs for them as > everything has switched to SATA or SAS. SCSI2SD (<http://www.codesrc.com/mediawiki/index.php/SCSI2SD>) are a bit expensive, but solve that problem (I own both a V5 and a V6, both work well in my SPARCstations, tried sun4c and sun4m). As it takes micro-sd cards, it's quite easy to keep multiple OSes on hand. > Then there's the issue of finding a monitor as they're not > electrically compatible with VGA Huh? There is Sun's 13W3-to-vga adapters and cables, and many monitors will sync to Sun's frequency (though not the most recent LCDs whose analog circuitry is pathetic compared to old-school CRTs). Some framebuffers will output 1280x1024 (rarer than for 1152x900), and some can be coerced to do almost anything with some Forth knowledge (see e.g. <https://github.com/rdolbeau/SunTurboGX>, again blowing my own horn here sorry...). > (...) booting one up for fun is simply impractical An SCSI2SD and either a null-modem serial cable or a Sun keyboard/13w3 cable/17"LCD combo and you're good to go. You might need another unix-like box to netboot the system. > I believe that Gentoo is architecture-neutral enough that it'd work, > but I believe that you'll have to compile everything - there'll be no > pre-built anything for sparc32 Trying gentoo is on my todo list... has been for a long time :-( > and as it's fairly slow hardware by > today's standards, that's going to take a long time, however you could > probably use distcc and cross-compilers to speed it up. Isn't that what Qemu is for ? :-) I've managed to recompile LLVM and clang in NetBSD 9 for my SS20, one by cross-compiling (LLVM requires too much memory), the other in QEmu. Unfortunately, Qemu doesn't yet support mt-tcg (multithreaded emulation) for sparc so single-core only - still faster than the HW, mostly because of incomparably faster I/O. > If there were more people using it or more testing, or more distros > supporting it - not just (theoretically?) working on it - then I'd be > fighting to keep it. I wish I had some arguments for that point... I will just re-mention Qemu, as it makes testing quite easy and reasonably not-too-slow. Cordially, -- Romain Dolbeau
Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d
Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg a écrit : > Another said that it would be a shame to sunset sun4m and sun4d because > there are so many machines around, and netbsd is also active on the > sparc32 area. Yes, those were plentiful back in the day and there's still quite a few around. > The second mail also re-reminded me of an interesting project > implementing SPARC V8 and the sun4m platform in VHDL. There's also new hardware being developed for SBus systems :-) <https://github.com/rdolbeau/SBusFPGA> (disclaimer: work-in-progress and shameless self-promotion here!). If there's still a distribution willing to build for Sparc v8, then I believe the kernel should try to keep support of the relevant machine architectures if at all possible... Cordially, -- Romain Dolbeau
Re: Does '5.7.6-1' work on USIIIi for you? (was: Re: sparc64 kernel crashes, & using SAS/SATA drives instead of SCA/FC-AL)
Le lun. 13 juil. 2020 à 09:27, John Paul Adrian Glaubitz a écrit : > Please, do thorough tests in the future before claiming a bug has been fixed. That's the weird thing, I would have thought >10 hours of parallel compile was a 'thorough' test... Apparently not :-( And I did not claim the bug was fixed; I merely requested further tests to see if it was: > (..)try the current kernel and see if it fixes the problem? And if it > doesn't, (...) Clearly, it doesn't for everyone :-( Cordially, -- Romain Dolbeau
Re: Does '5.7.6-1' work on USIIIi for you? (was: Re: sparc64 kernel crashes, & using SAS/SATA drives instead of SCA/FC-AL)
Le lun. 13 juil. 2020 à 09:01, John Paul Adrian Glaubitz a écrit : > I switched one of the buildds which has an UltraSPARC IIIi to kernel 5.7.6 and > got this: Looks like the crash I had, as far as I can remember. Any idea about the workload at the time? Is there a lot of parallelism in the build system, could the memory have been saturated somehow? On my side I was running at -j3 to force a bit of context switching (SB has dual CPU), but there's 8 GIB in there and I don't think I got close to the limit... Cordially, -- Romain Dolbeau
Re: Does '5.7.6-1' work on USIIIi for you? (was: Re: sparc64 kernel crashes, & using SAS/SATA drives instead of SCA/FC-AL)
Le dim. 12 juil. 2020 à 14:38, John Paul Adrian Glaubitz a écrit : > Sounds good. I will give it a try. Thanks to Connor's message about Firefox, I discovered snapshot.debian.org and could install the 5.6 that I couldn't find before. But I couldn't get it to crash with my GCC rebuild script, I gave up near the end of stage 1 (so it had compiled, checked and installed binutils/gmp/mpfr/mpc/isl). Then I went back to 5.7 and tried again from the console, thinking maybe the crash had to do with that. Again, no crash. I really don't understand; I had two crashes before but cannot induce one now... Le dim. 12 juil. 2020 à 15:27, Gregor Riepl a écrit : > From what I can gather on the net, the GPU on this card is a 3DLabs Wildcat I believe so; thanks for the links. I only mentioned the lack of X as it could be a factor in the crashes. If I really wanted to run X11 there in Linux (it should work on Solaris), I have a spare XVR-100 to swap in that should be OK. Cordially, -- Romain Dolbeau
Does '5.7.6-1' work on USIIIi for you? (was: Re: sparc64 kernel crashes, & using SAS/SATA drives instead of SCA/FC-AL)
Le jeu. 9 juil. 2020 à 13:26, Romain Dolbeau a écrit : > So - has anyone made any progress on this or are we still in need of a > bisect? If the latest, is there any known way to quickly cause a crash > to ensure if a tested kernel is good/bad? I wanted to give a go at bisecting, so first I recovered a 4.17 package in the archive on my T5120 to have something that should work as backup - and in so doing, removed the Debian kernels I had... maybe that was a mistake, as I could have been running 5.6 at the time, I'm not sure. After failing to deliberately crash my home-cross-compiled vanilla 5.2 on the Sun Blade 2500 Red, I installed the current kernel in Sid: linux-image-5.7.0-1-sparc64-smp 5.7.6-1 And managed to do a full rebuild of GCC 10.1 (starting with recent binutils/gmp/mpfr/mpc/isl before a complete 3-stage bootstrap), and in parallel do a git checkout of Linux, some package installation and a configure/rebuild of ZFS. Took almost a day (with a shutdown/reboot the middle of stage 2), no crash in sight, though I tried via SSH only (the XVR-600 isn't supported in X). The machine has been rock-solid so far (running from a SAS drive on a flashed 1068)... For those with crashes - could you try the current kernel and see if it fixes the problem? And if it doesn't, what kind of workload do you have when the kernel crashes? I've seen the crashes myself but can't reproduce them anymore and I don't have the archive of the 5.6 I might have been running at the time... Cordially, -- Romain Dolbeau
sparc64 kernel crashes, & using SAS/SATA drives instead of SCA/FC-AL
Hello, I've just recently got myself a SunBlade 2500 Red, and while Debian Sparc64 installed perfectly from the May image (thanks!), I'm being bitten by repeated crashes of the kernel. Presumably, the same bug that was reported in april-may by Miroslav (<https://lists.debian.org/debian-sparc/2020/03/msg00026.html>) So - has anyone made any progress on this or are we still in need of a bisect? If the latest, is there any known way to quickly cause a crash to ensure if a tested kernel is good/bad? And related to something Meelis said (<https://lists.debian.org/debian-sparc/2020/04/msg1.html>): > I might want to install Linux on E420R but do not have FC-AL disks with me. I have found a reasonable cheap way to work around such issues for Suns with an available 3.3V PCI[-X] or PCIe slot, by flashing a x86 LSI 1064/1068 (PCI) or 1068e (PCIe) device with the ROM file available from a Sun patch. See in the rescue mailing list here <http://www.sunhelp.org/pipermail/rescue/2020-July/142249.html> for details. As far as I can tell, any flashable card from eBay should enable you to boot from a SAS or even SATA (I only tried SAS so far) drive instead of the less-easy-to-find SCA or FC-AL drive that came standard. Cordially, -- Romain Dolbeau
Re: Updated installation images 2019-01-21
Le lun. 21 janv. 2019 à 13:03, John Paul Adrian Glaubitz a écrit : > I don't know of any issue with debootstrap, what was the problem? Mid-november, there was an issue with 'isc-dhcp-client' - and you mentioned that the missing 'cruft' support was the issue back then, seems it's a recurring problem as you just mentioned it again :-) I'll need to try again when I find the time. Thanks & cordially, -- Romain Dolbeau
Re: Updated installation images 2019-01-21
Le lun. 21 janv. 2019 à 12:48, John Paul Adrian Glaubitz a écrit : > I have created updated installation images for Debian Ports, > please find the updated images below and test them [1]. Thanks again for all the good work. Does that mean that deboostrap should work again, or are the two means of installing unrelated? (haven't had time to play with my T5120 since debootstrap was failing). Cordially, -- Romain Dolbeau
Re: missing packages for debootstrap ?
Le sam. 17 nov. 2018 à 12:14, John Paul Adrian Glaubitz a écrit : > The source package isc-dhcp-client currently fails to build from source > in Debian unstable [1]. On Debian Ports, this can result in packages to > become temporarily uninstallable due to the fact that the Debian Ports > FTP infrastructure doesn't support a feature called "cruft". OK thank you for the explanation. I guess isc-dhcp-client should be fixed soon, as that seems to affect pretty much all architectures Cordially, -- Romain Dolbeau
missing packages for debootstrap ?
Hello, I'm trying to debootstrap a new installation on my T5120 (with some more ZFS on some new drives). However, deboostrap is failing because there's no "libdns-export1102" and "libisc-export169" available, which are required for "isc-dhcp-client". Indeed the current Debian webpage has this last one in sparc64 - showing the dependencies: <https://packages.debian.org/sid/isc-dhcp-client> but the two dependencies aren't available on sparc64: <https://packages.debian.org/sid/libdns-export1102> <https://packages.debian.org/sid/libisc-export169> My current working install has them installed but unavailable: dolbeau@t5120:~$ apt-show-versions -a -p libisc-export169 libisc-export169:sparc64 1:9.11.4.P2+dfsg-3 install ok installed No unstable version libisc-export169:sparc64 1:9.11.4.P2+dfsg-3 installed: No available version in archive dolbeau@t5120:~$ apt-show-versions -a -p libdns-export1102 libdns-export1102:sparc64 1:9.11.4.P2+dfsg-3 install ok installed No unstable version libdns-export1102:sparc64 1:9.11.4.P2+dfsg-3 installed: No available version in archive In my /var/cache, the packages are from late September. Cordially, -- Romain Dolbeau
Re: Where can I find the ldm command
Le mer. 31 oct. 2018 à 15:03, Stefan Johansson a écrit : > I have just managed to install Debian sparc64 on my t5120. > Where can I find the ldm command to manage ldoms? I don't think you can manage ldoms from Debian. I suspect 'ldm' is only available in Solaris and in some recent versions of Oracle Linux... and those recent versions of Oracle Linux do not support the T5120 (only T4 and later IIRC). You should be able to download & install S11 for the T5120, I had no issue doing it a few months back, if you really want to use ldoms. Cordially, -- Romain Dolbeau
Re: ZFS root w/ debian sparc64 (was: Re: Installed kernel crash on T5120)
Le lun. 3 sept. 2018 à 20:34, Chris Ross a écrit : > :-( I'm sorry to hear about this. I'd been happy to think that if I backed > off of worrying about a mirrored /boot, and just used a RAID1 as you did, So far I don't even use RAID1 - ZFS is on a single disk, with /dev/sdd1 as the boot partition (ext2) and /dev/sdd2 as the root pool. I'd like to move to a mirrored /boot (using std linux mdraid) + mirrored zpool, but I don't want to destroy my non-ZFS install, as the ZFS install isn't very stable (yet). I've managed to boot ZFS again the beast, at last. The name of the pool was no longer in grub.cfg, some packages had been removed at one point (zfs-dkms among them, so no more module), the console=ttyS0 mask some messages (but allows for a prompt later...),and probably some other stuff that I forgot. Removal of packages might be related to the availability of spl-dkms in sid (but not zfs-dkms), which was incompatible with my version. Not sure what was the original cause of the problem, as I dist-upgraded the install to today's version before trying (and succeeding) to boot again. And more good news - the motherboard I got for cheap on ebay from Germany works fine, so now I have 8 cores @ 1.4 GHz instead of 4 @ 1.2 GHz :-) Cordially, -- Romain Dolbeau
ZFS root w/ debian sparc64 (was: Re: Installed kernel crash on T5120)
2018-07-20 23:52 GMT+02:00 Romain Dolbeau : > I don't think I did anything special beyond > slightly fixing the grub.cfg by adding the pool name... Last week-end (25/26 august), I dist-upgraded my ZFS root install... unfortunately, I haven't been able to boot it since :-( I got an upgraded kernel (4.17.0-3), but even trying the previous know-to-work 4.17.0-1 doesn't work. The kernel loads, but nothing happens once the ZFS module is loaded: # (...) [ 32.208115] sda: sda1 sda3 [ 32.208622] sdb: sdb1 sdb3 [ 32.213559] sdd: sdd1 sdd2 sdd3 [ 32.214986] sd 1:0:0:0: [sda] Attached SCSI disk [ 32.215291] sd 1:0:1:0: [sdb] Attached SCSI disk [ 32.218789] sdc: sdc1 sdc2 sdc3 sdc4 [ 32.221383] sd 1:0:3:0: [sdd] Attached SCSI disk [ 32.226143] sd 1:0:2:0: [sdc] Attached SCSI disk [ 32.732787] spl: loading out-of-tree module taints kernel. [ 32.739636] SPL: Loaded module v0.7.9-3 [ 32.740222] znvpair: module license 'CDDL' taints kernel. [ 32.740355] Disabling lock debugging due to kernel taint [ 34.986408] ZFS: Loaded module v0.7.9-3, ZFS pool version 5000, ZFS filesystem version 5 # ZFS is on sdd2. The initrd were rebuilt at the time of upgrade, dunno if it matters. I have tried upgrading since then (I still can mount the ZFS root from a previous, non-upgraded, non-ZFS install on sdc), but it doesn't help. Any suggestion or idea welcome... BTW, did anyone else succeeded in having ZFS root on sparc64? Cordially, -- Romain Dolbeau
Re: Testing Firefox 62 on sparc64
2018-08-09 14:50 GMT+02:00 John Paul Adrian Glaubitz
:
> Did you install the debug package so we can see where it actually
> crashes in ProcessExecutableMemory.cpp?
With 62.0~b16-1 on my t5120 (tunneled X11 - dunno if it changes the
behavior), running with the dbgsym package under gdb:
#
Thread 1 "firefox" received signal SIGBUS, Bus error.
HashIIDPtrKey (key=0x80010a425aec )
at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:26
26 /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:
No such file or directory.
(gdb)
(gdb) bt
#0 HashIIDPtrKey (key=0x80010a425aec )
at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.cpp:26
#1 0x80010690aed4 in PLDHashTable::ComputeKeyHash (
aKey=0x80010a425aec ,
this=0x7440140)
at /build/firefox-qTMIsZ/firefox-62.0~b16/xpcom/ds/PLDHashTable.cpp:586
#2 PLDHashTable::Add (this=0x7440140,
aKey=0x80010a425aec )
at /build/firefox-qTMIsZ/firefox-62.0~b16/xpcom/ds/PLDHashTable.cpp:586
#3 0x80010701a140 in IID2NativeInterfaceMap::Add
(iface=0x74abfa0, this=0x7440140)
at /build/firefox-qTMIsZ/firefox-62.0~b16/js/xpconnect/src/XPCMaps.h:245
(...)
#
>From the source package, the relevant source bit would be:
#
static PLDHashNumber
HashIIDPtrKey(const void* key)
{
return HashGeneric(*((uintptr_t*)key));
}
#
Line 26 being the return.
#
(gdb) disassemble
Dump of assembler code for function HashIIDPtrKey(void const*):
=> 0x800106fe206c <+0>: ldx [ %o0 ], %g3
0x800106fe2070 <+4>: add %g3, %g3, %g2
0x800106fe2074 <+8>: srlx %g3, 0x20, %g4
0x800106fe2078 <+12>:add %g2, %g3, %g1
(...)
(gdb) print (uintptr_t*)key
$9 = (uintptr_t *) 0x80010a425aec
#
So, yet another function that doesn't bother to check for alignment,
it seems... that pointer is aligned on 4 bytes, but not 8.
Cordially,
--
Romain Dolbeau
Re: Sid on ultra1 status
2018-08-14 19:32 GMT+02:00 John Paul Adrian Glaubitz : > Are you booting with a serial console? If yes, try adding "console=ttyS0" > or whatever is your serial device. Although that *should* be added > automatically. No, unfortunately I don't have serial-capable hardware (or cable) were the machine lives at the moment. I boot graphically - type 5 kbd & mouse, 17" 1280x1024 LCD on the FFB2+ (Creator 3D serie 2). At the stage where the systems hangs, linux has already switched the console AFAICT. I can interact with the shells spawned by BOOT_DEBUG=3 with no issue (well, the first two before the hang). Cordially, -- Romain Dolbeau
Re: Sid on ultra1 status
2018-08-14 18:11 GMT+02:00 Romain Dolbeau :
> Does it mean that when grub 'search' for the /boot UUID, it gets the
> wrong device entry ? (missing @sd1,0)
There's definitely a bug somewhere, as 'ls' in the grub command line
also generates the errors and hang...
However - when loading, 'grub' sets the $root variable to something
similar, starting with ieee1275 and featuring some escapes.
So if I don't set 'root' at all - grub looks in its own partition, and
everything seems to work fine...
The entry that actually works (minus the root UUID):
#
menuentry 'SIMPLE Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option 'gnulinux-simple' {
load_video
echo 'insmod gzio'
insmod gzio
echo 'insmod part_sun'
insmod part_sun
echo 'insmod ext2'
insmod ext2
echo 'set root'
set root='ieee1275//sbus@1f\,0/SUNW\,fas@e\,880/sd@1\,0,sun1'
echo'Loading Linux 4.17.0-1-sparc64 ...'
linux /vmlinuz-4.17.0-1-sparc64 root=UUID=X-X-X-X-X ro
echo'Loading initial ramdisk ...'
initrd /initrd.img-4.17.0-1-sparc64
}
#
So it's the dev name prefixed by ieee1275/, '\' before all ',', and
',sun1' to indicate the partition (no \ on this comma)...
2018-08-14 19:08 GMT+02:00 Gregor Riepl :
> I believe this is 'normal', I got the same with two different video adapters.
> (Creator3D and Mach64)
OK, so it's not the source for the messed up 'search' and 'ls', we can suppose.
> I don't think I can help you, but I did have lots of floppy drive problems on
> my system, so I simply unhooked it. Might be that the Linux floppy driver is
> currently broken, or a hardware problem.
There's a floppy slot but no actual drive in there. 'search' has
--no-floppy by default...
Weird that it tries, but that just may be the same bug twice: grub
uses a wrong dev entry?
Cordially,
--
Romain Dolbeau
Re: Sid on ultra1 status
> 1) when grub starts, after "GRUB Loading kernel", I have two error lines: > # > error: out of memory. > error: no suitable video mode found. > # > then I get the menu just fine anyway. > 2) after selecting the Debian entry from the menu I get: > # > Recalibrate failed. The floppy drive is either missing, improperly > connected, or defective. > error: unable to open /sbus/@1f,0/SUNW,fdtwo@f,140. > # > and then nothing. > Sometimes I get a second error, but mentioning a path to a hard drive > - "/sbus/SUNW,fas@e,880/sd", with the final @0,0 (or @1,0) > missing. I'm not able to reproduce this second error at the moment, > don't know why. I patched the grub.cfg to remove some conditionals and 'echo' every command. As far I can tell, the 'search' command is failing. I did get the 2nd error message: # Invalid SCSI target number fff9afc8 error: unable to open /sbus/SUNW,fas@e,880/sd. # Does it mean that when grub 'search' for the /boot UUID, it gets the wrong device entry ? (missing @sd1,0) Cordially, -- Romain Dolbeau
Sid on ultra1 status
Hello, Quicl status update on running current Sid on my Ultra 1 200E (w/ 1 GiB of RAM and an horizontal FFB2+ in the UPA slot). Upgrading my old install to what was available august 11, including kernel 4.6, went just fine. The machine boots with Silo, and everything is fine. Trying to install from the 2018-05-18 image doesn't work. The system hangs after displaying "starting syslogd, klogd". I tried BOOT_DEBUG=3, the first two shells are fine - and it seems the disks are seen on the ESP SCSI. Immediately after the second shell, the syslogd/klogd line, and then nothing. So I used multistrap again to do another install on a second drive and try grub2. Booted from the Silo on the first drive, the new install works fine (with kernel 4.17, though it seems to hand on reboot). However, I can't get grub2 to boot it :-( 1) when grub starts, after "GRUB Loading kernel", I have two error lines: # error: out of memory. error: no suitable video mode found. # then I get the menu just fine anyway. 2) after selecting the Debian entry from the menu I get: # Recalibrate failed. The floppy drive is either missing, improperly connected, or defective. error: unable to open /sbus/@1f,0/SUNW,fdtwo@f,140. # and then nothing. Sometimes I get a second error, but mentioning a path to a hard drive - "/sbus/SUNW,fas@e,880/sd", with the final @0,0 (or @1,0) missing. I'm not able to reproduce this second error at the moment, don't know why. This is the same kernel & initrd as with Silo - so it is known to work on this machine... Cordially, -- Romain Dolbeau -- Romain Dolbeau
Re: sunffb revival
2018-07-26 22:03 GMT+02:00 Gregor Riepl : > I'm not sure how UPA works exactly, but I don't think it matters what bus > architecture the machine is based on. Indeed, after building your package, it works just fine on my U1:-) I get the same occasional display corruption as I got with my previous hackish FFB driver, but those could be the userland badly interacting with the big-endian system... (I'm running WindowMaker & xterm). Thanks & cordially, -- Romain Dolbeau
Re: sunffb revival
2018-07-24 23:34 GMT+02:00 Gregor Riepl : > Perhaps this is useful to someone? I'll try as soon as I can on my Ultra 1. I had a working driver some time ago (<https://lists.debian.org/debian-sparc/2016/03/msg5.html>), but not the Debian way. I assume the driver should work on SBus machine as well as PCI machine, as it's UPA-based in both cases ? Thanks everyone for all the great work :-) If only I had the space for a T3 or a M4000... Cordially, -- Romain Dolbeau
Re: Installed kernel crash on T5120
2018-07-20 23:22 GMT+02:00 Chris Ross : > Interesting. What tool is showing that? fdisk, force of habits... > I have been using parted, which > shows (for my first ZFS disk): > > Number Start EndSize File system Flags > 1 0.00B 502MB 502MB ext2 boot > 2 502MB 147GB 146GB zfs > > So, other than the different format, I notice: > 1) I show ZFS where your sdd2 shows "Unassigned" I used fdisk and originally set the partition *ID* to unassigned as fdisk didn't suggest ZFS. ZFS doesn't seem to care. Parted shows a filesystem, not an id (I think). fdisk shows the id, not the filesystem. > 2) You have a 'c' whole disk partition, and I don't. I wonder if that's >important? Suns have wanted a full disk partition since the beginning. Sun labels tend to always have them, just in case. Not sure if they are used by anything in Linux (I doubt it, it's probably just an artifact of SunOS behavior). > 3) You have an "Id" field [in your tools output] that I don't. partition Id used to be useful, not sure if anything in the kernel cares anymore. fdisk still offers to set them and still display them - as said above, I put unassigned by lack of choices. Don't think it matters much. > Thanks. There are a few differences compared to mine, notably that the > "search" lines in your menuentry have a UUID of all 9's, Oups sorry red herring - out of habits I always anonymize such files. In my installation, the UUID are real values, and I sed'ed them to all-9. > And I have hd0/ahci0 vs your hd3/ahci3, but that is expected. I > also see that I'm due a kernel update (my grub.cfg still lists 4.16.0-2), > but since I'm not getting a kernel loaded at all, that's not my problem. I had to update the kernel as the 4.16 installed by the installer didn't have any matching headers to compile ZFS that I could find. 4.17 worked just fine on ext4, and works just fine with ZFS as well, and it had headers. > Yeah. This is about the same as what I've tried, but I'm not even able > to have grub load from the disk in my case. I've been thinking about > booting back to "reinstall the whole thing from CD", since my original > install was many months ago, but haven't done that yet. Except for holding the klibc stuff to a working version, you should be able to just dist-upgrade I suppose. I did in my case to make sure I would have matching install between ext4 and ZFS during dbootstrap, so I could reuse the same ZFS/SPL modules without any compatibility issue. As for grub - except for the fact my /boot is much smaller (I matched the size of the ext4 auto-created partition to the sector), I can't help. My first attempt failed - not valid. After trying again, it started working and I just had to fix the various issues in configuration and versions mentioned in a previous mail. I don't think I did anything special beyond slightly fixing the grub.cfg by adding the pool name... Good luck & cordially, -- Romain Dolbeau
Re: Installed kernel crash on T5120
2018-07-19 23:51 GMT+02:00 Chris Ross : > Can you confirm the version of grub that you've used to grub-install onto > your disk, t5120:~$ dpkg -l '*grub*' | grep ^ii ii grub-common 2.02+dfsg1-4 sparc64 GRand Unified Bootloader (common files) ii grub-ieee1275 2.02+dfsg1-4 sparc64 GRand Unified Bootloader, version 2 (Open Firmware version) ii grub-ieee1275-bin 2.02+dfsg1-4 sparc64 GRand Unified Bootloader, version 2 (Open Firmware binaries) ii grub2-common 2.02+dfsg1-4 sparc64 GRand Unified Bootloader (common files for version 2) > and show me how your disk is labeled/partitioned? Device Start End Sectors Size Id Type Flags /dev/sdd1 0192779192780 94.1M 1 Boot /dev/sdd2 192780 286707979 286515200 136.6G 0 Unassigned /dev/sdd3 0 286728119 286728120 136.7G 5 Whole disk Pool on sdd2, of course. > Maybe mail me > your grub.cfg off-list, so I can see how that compares to the one I'm trying > to squeeze into the one on my ext disk. Available on <http://www.dolbeau.name/dolbeau/files/grub.cfg> > (Side question, can it break things to boot grub and it's config off of one > /boot, then load root and have it configured to load a different /boot?) I don't think so but I'm not an expert. BTW, when I installed the system, I had the sdd1 /boot mounted on /mnt/boot (ZFS root on /mnt). After doing "grub-mkconfig -o /boot/grub/grub.cfg" (in chroot) the pool name was missing in grub.cfg, only the dataset name was there. I added the pool name by hand. Then "grub-install --force --skip-fs-probe /dev/sdd1" (also in chroot). Don't remember anything special beyond that ... and a bit of elbow grease :-) (several reboots to add the network interface configuration, the console, right klibc, ...). Cordially & good luck, -- Romain Dolbeau
Re: Installed kernel crash on T5120
2018-07-18 16:57 GMT+02:00 John Paul Adrian Glaubitz : > Some essential packages like glibc will shortly disrupt the functionality > of debootstrap. It resumes working once the FTP servers are in sync > again. What was weird is that debootstrap kept trying for a -9, while I could see and download the -10... something must have been cached somewhere I didn't find. > I'm sorry, but sometimes things are out of my control. We just need > more hands. No proble-m just a warning to other to be careful and always double-check that kind of stuff before upgrading. Fortunately, I hadn't upgraded those packages on my ext4 install. > Did you enable the console on the command line? Try adding "console=ttyS0" > or whatever the name of the serial console on your SPARC machine is. That hadn't been needed in ext4, and I had no network so I assumed it was something else... But assumption is the mother of all f*ck-ups :-) Turns out I had forgotten to propagate the network config from the ext4 install this time, and yes I needed the console parameter :-) I have mutiuser on the ZFS Root install now :-) Cordially & thanks for your help, -- Romain Dolbeau
Re: Installed kernel crash on T5120
2018-07-18 7:34 GMT+02:00 Romain Dolbeau : > That's where I am a right now. I'll try to rebuild Debian ZFS in the chroot > instead of the installed Debian next... Ended up doing 'mkdir' of the missing directory during build, solved the problem. Then the new ZFS, being older, didn't import the pool... so I recreated the pool from scratch. debootstrap would then fails, trying to download some packages upgraded during the night... after a while and multiple attempts it worked. Dunno why. So redo everything, but for some reason grube-probe doesn't see ZFS anymore. And the pool name is missing in grub.cfg, I can fix that by hand. Still can't boot, as the klibc stuff has been updated from -12+sparc64 to -13, getting me back to square one. Still had the -12+sparc64 in the ext4 install, so downgrade by hand and bypass that problem. At this stage (and probably some stuff I forgot), the new install will boot single user :-) But multi-user hangs during start-up after: # () [ OK ] Reached target Network is Online. Starting LSB: exim Mail Transport Agent... [ OK ] Started Permit User Sessions. [ OK ] Started Getty on tty1. [ OK ] Reached target Login Prompts. [ OK ] Started LSB: exim Mail Transport Agent. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [ OK ] Started Update UTMP about System Runlevel Changes. # A few minutes later, I also got: # [ 318.639989] random: crng init done [ 318.640079] random: 7 urandom warning(s) missed due to ratelimiting # So I guess the kernel still alive ... (no ping though, and non-responsive console). Cordially, -- Romain Dolbeau
Re: Installed kernel crash on T5120
2018-07-18 4:29 GMT+02:00 Chris Ross : > Interesting to note, thank you. If you have a full build of zfs from source, you can try "zfs/cmd/raidz_test/raidz_test -B". > I wonder why > my grub-install onto my sda1 isn't working, and yours onto your sdd1 is. Barely so far. After a couple of trials (and adding the boot partition to fstab, among other things), I got to the point where I get the grub menu & grub load the kernel... then it blows up because "/etc/zfs/zfs-functions" is missing. That file is in the Debian packages (zfsutils-linux I think), but is not installed by the packages created by 'make deb' from git... so I tried rebuilding the Debian sources with "debuild', but that blows up with an error about missing "usr/lib/dracut" in "debian/tmp"... That's where I am a right now. I'll try to rebuild Debian ZFS in the chroot instead of the installed Debian next... Cordially, -- Romain Dolbeau
Re: Installed kernel crash on T5120
2018-07-17 5:08 GMT+02:00 Chris Ross : > I hope that you are able to make progress and that > I can learn from it as well. :-) Well I have ZFS up and running from Git - it has become surprisingly easy over the years. BTW, from the archive, I see you were intent on RAIDZ. I love RAIDZ, but after running the raidz benchmark, I strongly advise against anything but mirrors on a T5120 :-( The parity algorithms are really slow on that CPU. And looking at the VIS(1+2) instruction set, I doubt they can be significantly accelerated (VIS is old and lacks the required 8 bits operations, it doesn't even get any kind of shifts before VIS3). Unless we can somehow leverage the cryptographic stuff (the Modular Arithmetic Unit, MUA) ? But I don't see any documentation beyond "go through the Solaris driver" :-( Anyway for the new Debian I'm combining this page <https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS> and this ML with this: sudo debootstrap --no-check-gpg sid /mnt http://ftp.ports.debian.org/debian-ports /mnt is where the ZFS root is mounted (didn't do anywhere near as many FS as the wiki suggests). ZFS is on /dev/sdd2, with /dev/sdd1 a "boot partition" similar to the one debian-installer added on /dev/sdc, as it is apparently required. Cordially, -- Romain Dolbeau
Re: Installed kernel crash on T5120
2018-07-16 20:50 GMT+02:00 John Paul Adrian Glaubitz : > If you have 2.0.4-12 and not 2.0.4-12+sparc64, your klibc is broken. You > can either boot into rescue mode, then chroot into the installed system > and dist-upgrade the machine and then run update-initramfs -k all -u or > reinstall the machine. That was it. I had upgraded the system, but not done the "update-initramfs -k all -u" bit. After doing that in rescue mode, it booted just fine. Thanks :-) > I guess that would be possible if we switch the installation media to use > GRUB instead of SILO as its bootloaders. But this is still an item on my > evergrowing TODO list. Not a critical item, but it's a lot easier to find a USB stick than a blank CD media and a working reader nowadays. Next step - ZFS followed by trying to deboostrap a new install in a ZFS root :-) Thanks for your help & cordially, -- Romain Dolbeau
Installed kernel crash on T5120
Hello all, Trying to install Sid sparc64 on a T5120. I have a cdrom with the 2018-05-18 ISO from <https://cdimage.debian.org/cdimage/ports/10.0/sparc64/iso-cd/>. I'm installing on the third hard drive (first two are a mirrored ZFS pool for Solaris). It worked just fine installing to the whole disk in a big partition (ZFS support is missing, I presume it's a known issue, so I let the installer pick a partition scheme and figured I'd try ZFS root in the fourth disk at a later date). I picked sdc as the target for grub when asked (sda & sdb are Solaris, didn't want to mess with them). However, the system wouldn't boot on the fresh install - PROM said 'not bootable'. So I booted in rescue mode and loaded a shell in /dev/sdc2, then tried installing grub by hand with: grub-install --force --skip-fs-probe /dev/sdc1 (as suggested in <https://github.com/esnowberg/grub2-sparc/wiki>). Now grub loads fine, I see the grub menu, pick the default choice, and this happen: # Loading Linux 4.16.0-1-sparc64-smp ... Segmentation fault /dev/sdc2: clean, 38180/6938624 files, 827057/27744254 blocks Segmentation fault [ 32.916580] run-init[1]: segfault at 38 ip 800106cc (rpc 00100500) sp 07feffb02eb1 error 1 in klibc-gioU2Ql6Bpp06841ZXKfdH4dunE.so[8000+14000] [ 32.917090] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [ 32.917090] [ 32.917242] CPU: 7 PID: 1 Comm: run-init Not tainted 4.16.0-1-sparc64-smp #1 Debian 4.16.5-1 [ 32.917365] Call Trace: [ 32.917443] [0046b8a8] panic+0xe8/0x2a0 [ 32.917520] [00471010] do_exit+0xb50/0xb60 [ 32.917594] [004710cc] do_group_exit+0x2c/0xe0 [ 32.917651] [0047d194] get_signal+0x3b4/0x660 [ 32.917710] [0042dbbc] do_signal+0x3c/0x480 [ 32.917831] [0042e850] do_notify_resume+0x50/0xa0 [ 32.918110] [00404b44] __handle_signal+0xc/0x2c [ 32.919181] Press Stop-A (L1-A) from sun keyboard or send break [ 32.919181] twice on console to return to the boot prom [ 32.919398] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [ 32.919398] # I probably messed up somewhere, just can't figure out where... any help appreciated. Already tried upgrading, but no newer kernel is available. Related question - Solaris installs fine from a USB stick on this beast, is there already support for an USB installer in Debian Sparc64? (I've run out of blank media - don't use them that much anymore...). Thanks in advance & cordially, -- Romain Dolbeau
Re: Test atomic operations on SPARC 32-bit
2017-12-10 2:19 GMT+01:00 Petr Vorel : > I test it (in my github fork of) LTP project [1], but unfortunately some > tests which heavy > test it fails. With a large number of threads, the test-and-test-and-set option will significantly cut down the coherency traffic between caches. It's a much better solution than a pure test-and-test. > The tests just get slightly fewer incrementation than it should get (6373821 > instead of 640). > > The implementation in github is for SPARC32, but I adjusted the code to test > it on SPARC64 > and (of course) it behaves the same. > > Any idea what can be wrong? Are you testing on true v8 hardware or on v9 ? On v9 (and v8+) you might be running in RMO (Relaxed Memory Order), in which case you probably need some extra "membar" to force the update of the variable [1]. By default, the code probably only work for PSO and TSO modes (the only two that exist in v8) if adding a "membar #MemIssue" before and after the update of the variable solve the problem, then memory ordering is the culprit. (this forces way too strong an ordering, but is useful for a test). "membar" is v9/v8+ only. If you're on true v8 HW - darn. PSO still could be the problem. try with "stbar" surrounding the variable update. "stbar" is a bit weaker that some variants of "membar", but is in v8. You might want to take a look on how much ordering instructions the kernel uses, after all :-( Low-level parallelism is hard :-) Cordially, Romain [1] e.g. <http://www.oracle.com/technetwork/server-storage/solaris10/index-142944.html>, <https://cr.yp.to/2005-590/sparcv9.pdf> -- Romain Dolbeau
Re: Test atomic operations on SPARC 32-bit
2017-12-09 0:45 GMT+01:00 Petr Vorel : > Nice, thanks a lot! I might use kernel implementation, but this is handy. > (...) > I need threads only, no shmem... The lib was designed to support GCC 4.8 (IIRC) and some C++11 threading on S7 and S8. If that's what you need (except for the Solaris bit), it should be directly usable. > It looks to me that this is used in kernel (if I understand the code > correctly). Didn't realize the Linux kernel was already doing something about it. I don't know any distribution that still run (let alone support) on v7/v8, so I never thought of looking at the kernel. Debian only goes up to Debian 5. Re-compiling a recent GCC on a dual SM51 is an exercise in patience nowadays :-) Cordially, -- Romain Dolbeau
Re: Test atomic operations on SPARC 32-bit
2017-12-08 22:32 GMT+01:00 Petr Vorel : > I'm trying to implement __sync_add_and_fetch(), as according to buildroot > investigation > [1] it's not available on SPARC 32-bit As mentioned by someone else, v7 and v8 do not have them as hardware instruction. They were introduced in v9 and its 32 bits sibling, v8+. You can emulate them in many ways, including with a trivial global lock using the existing test-and-set instruction. I did that a while ago for some recompilation in S7 and S8: <http://www.dolbeau.name/dolbeau/files/libsparcatomic-0.3.0.tgz> Beware that it's not a universal solution. 1) The lock variable is defined in the library, so it's not shared between processes. Atomic won't work between processes in shared memory such as SysV shmem, only for threads. Going multi-process transparently (w/o changing the function signature) is non-trivial. 2) The lock variable is one big contention point that will slow things down, by forcing mutual exclusion for all atomic accesses including those to different variables. In theory it could be replaced by an array of variables (in different cache lines) using some sort of hash function based on the address of the protected variable. If that matters... use v8+ hardware instead would be my advice :-) v7 and v8 are not suitable for modern parallelism. Cordially, -- Romain Dolbeau
Re: Sun Blade 100 dead?
2017-04-07 18:41 GMT+02:00 transmail : > Maybe i don't get it, but if we stop the clock, then we must set the time at > every boot? Yes, but SunOS and Solaris both kick-start the clock at boot. And with NTP you don't really need to set the clock, the system does it for you. > Why the clock should be stopped then? Long-term storage. if you know you're not going to use the system for a while, you can shut down the clock so that the Nvram battery last longer. Cordially, -- Romain Dolbeau
Re: Sun Blade 100 dead?
2017-04-07 17:52 GMT+02:00 Mark Morgan Lloyd : > Any half-decent system designer provides a way to shut the clock down > on one of these chips, at which point the battery lasts more or less > indefinitely. I certainly did when I was putting them into custom hardware. > Huh? The Sun Nvram/Hostid FAQ (unfortunately it seems Squirrel has vanished :-(, my version is here: <http://www.dolbeau.name/dolbeau/files/sun-nvram-hostid.faq.html> ) includes instructions on how to stop the clock on 3/80 and sun4c, and those instructions can be adapted to at least sun4m and Ultra 1 (base address & map-page stuff). They probably can be used on a Blade 100 as well. Cordially, -- Romain Dolbeau
Re: Sparc64 - installation on various machines
>> Ultra 2: failed - no CDROM driver found > Ultra 2: same as the ultra 450, scsi cdrom correct? Back in February, on my Ultra 1, I couldn't install from CDROM either. After bootstrapping the system from a 32 bits install, I only needed the sun_esp module in the initrd for everything to work fine with kernel 4.3 (modulo X11 on the FFB, I posted a patch). I assumed that the installer had the same issue. I recently installed kernel 4.6, seemed to work fine as well (I didn't stress-test the system, but I could log in X11 with WindowMaker as the window manager). BTW, awesome job with the port, thanks to all those involved for the efforts :-) Cordially, -- Romain Dolbeau
Re: How-to: get FFB support in X11 on Debian/sparc64 (was: Re: Framebuffer support in Debian)
2016-03-06 10:00 GMT+01:00 Romain Dolbeau : > 3) apply the attached patch to the /dist directory to fix some minor compilation issues Updated patch with an API change to EnableDisableFBAccess. Crdially, -- Romain Dolbeau ffb.1.patch Description: Binary data
Re: booting qemu sparc gives black window
2016-05-18 13:06 GMT+02:00 Mark Cave-Ayland : > The short version is that the QEMU NVRAM format is different from that > of a real SS-5 machine (and indeed QEMU doesn't support NVRAM > persistence for that interface yet) It's quite easy to fix this if you're willing to patch qemu. IIRC: After starting with the SS5 PROM file, reset the (virtual) nvram like you would do on a real SS5 with a failed nvram battery. Then from the qemu monitor, dump the physical memory for the nvram (now with a 'valid' content) in a file. Then just patch qemu to load the data from that file after the nvram is initialized (file hw/sparc/sun4m.c, function nvram_init()). It also saves a lot of time when you give qemu the full 256 MiB of memory, since with a valid nvram the PROM won't check all of the memory. Cordially, -- Romain Dolbeau
How-to: get FFB support in X11 on Debian/sparc64 (was: Re: Framebuffer support in Debian)
2016-02-14 19:04 GMT+01:00 Romain Dolbeau : > * But there is ongoing work from the great folks over at NetBSD to port some of those drivers to the EXA infrastructure, see e.g.: > <https://mail-index.netbsd.org/port-sparc64/2015/11/27/msg002478.html> I finally got around trying the NetBSD code on Debian/sparc64, and got a working 24 bit display :-) Here's the brief recipe: 1) install all the X11 devel packages 2) checkout the NetBSD version of the sunffb driver: # cvs -d "anon...@anoncvs.netbsd.org:/cvsroot" checkout -rHEAD xsrc/external/mit/xf86-video-sunffb/dist # 3) apply the attached patch to the /dist directory to fix some minor compilation issues 4) ./configure & make 5) copy the binary to the X11 drivers directory: # sudo cp src/.libs/sunffb_drv.so /usr/lib/xorg/modules/drivers/ # Then in the xorg.conf file, the device section should look something like: # Section "Device" Identifier"Generic Video Card" Driver "sunffb" BusId"SBUS:/SUNW,ffb@1e,0" Option "AccelMethod" "EXA" EndSection # For reasons unknown, startx as a regular user doesn't find the device, but startx as root & xdm both work fine (including login as a regular user in xdm). They don't even require the BusId line. Cordially, -- Romain Dolbeau ffb.patch Description: Binary data
Framebuffer support in Debian (FFB, ...) (was: Re: Debian on ultra 1)
2016-02-13 17:09 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > I don't know whether that graphics hardware is still supported, > but you can just try. Short version: so far no luck but hopes for the future Long version: My understanding of the situation w.r.t. older framebuffer support in Xorg is: * Many devices (including FFB/AFB, a.k.a. Creator, Creator 3D, Elite M3, ...) works in Wheezy using the dedicated driver in a dedicated package, e.g. xserver-xorg-video-sunffb [my FFB works fine in Wheezy] * Those packages do not yet exist in the current sparc64 port * Compiling them from the older source (1.2.1) in wheezy will not work (they won't even compile), as they are all (? at least FFB) using the XAA acceleration infrastructure, which has been dropped in recent Xorg in favour of EXA * I was able to compile a newer version (1.2.2) of the driver from Xorg with the Debian-packaged X server, but the binary still tried to load an XAA module so would not work * But there is ongoing work from the great folks over at NetBSD to port some of those drivers to the EXA infrastructure, see e.g.: <https://mail-index.netbsd.org/port-sparc64/2015/11/27/msg002478.html> Cordially, -- Romain Dolbeau
Re: Debian on ultra 1 (was: Re: Debian on qemu-system-sparc64)
2016-02-13 16:56 GMT+01:00 Romain Dolbeau : > Can't figure out what's wrong (I did add sun_esp to /etc/modules and > rebuilt the initrd, but no luck). > For the record, with sun_esp in /etc/initramfs-tools/modules (+initrd rebuild), it works just fine. Cordially, -- Romain Dolbeau
Re: Debian on ultra 1 (was: Re: Debian on qemu-system-sparc64)
2016-02-13 17:35 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > Did you try loading the module? I don't know how. Unlike the fully installed system, the installer doesn't give me a shell. The screen just goes black and the machine seems to do nothing. I'll give it another go, now that I have a working installation (which is the take-away message I think - once installed, it works fine and it's great :-) > Using which driver? It might just be using some generic FB driver. Dedicated, I think (I hacked the EDID from my display directly in the deidcated kernel driver to get the proper resolution, since the cable didn't let the EDID through) ; I then got the 24-bits color display in X, so it's not PROM-only. ... should be this one: < http://netbsd.gw.com/cgi-bin/man-cgi?sparc64/ffb+4+NetBSD-7.0> > Did you try a serial console then? If your laptop doesn't have > a serial, try one of these USB-RS232 adapters, these work fine. I wanted to, but I no longer have a system with a serial port, and adapter or a (null-modem) serial cable there. It's been a while since I needed those, they're buried in an attic someplace else :-( Cordially, -- Romain Dolbeau
Re: Debian on ultra 1 (was: Re: Debian on qemu-system-sparc64)
2016-02-13 17:09 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > However, there > were weird problems later because the PROM battery was dead. Can > you make sure this battery is working properly? I forgot to answer that bit; the NVRAM is almost new (installed a brand new chip a few months ago). Cordially, -- Romain Dolbeau
Re: Debian on ultra 1 (was: Re: Debian on qemu-system-sparc64)
2016-02-13 17:09 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > Well, no. The installer works fine on my SunBlade 100 The SB100 is IDE; U1 is SCSI and uses the sun_esp module. Perhaps the problem is just the module is not loaded, since few systems (if any) would use it beyond the U1 and U2. > I don't know whether that graphics hardware is still supported, > but you can just try. I mean, the Ultra 1 is pretty old so it > most likely needs some work in the kernel and X.org to get the > bugs on this machine ironed out. X works fine in NetBSD, up to and including the Sun-unsupported 1920x1080@60Hz. You need a kernel hack to get that resolution though, but anything supported in the PROM is OotB. But yes, it seems that the current Xorg in Sid doesn't support the FFB anymore. They also exist as PCI devices, so I'm a bit surprised. It was standard-issue 'good' video for most of the Ultra workstations (the Elite3D a.k.a AFB taking the high-end and TurboGX a.k.a. cgsix the entry-level). Also since the Ultra 1 is younger than me, it's not old :-) > Any chance for you to just burn a CD and try an installation > from CD? That was my first attempt and it failed with a black screen, as described in my first message. Going through Lenny/sparc was an attempt at circumventing the problem in the cdrom :-) Cordially, -- Romain Dolbeau
Re: Debian on ultra 1 (was: Re: Debian on qemu-system-sparc64)
2016-02-12 15:56 GMT+01:00 Romain Dolbeau : > Then - nothing. It just sits there. Doesn't sound like it's using the disk or cd. It might not find either, from my subsequent experiment. I decided I didn't need no cdrom installer, and went back to lenny's network installer. Installed lenny in a small partition, upgraded to squeeze then wheezy, so far so good. Then used 'multistrap' to install Sid on a different, larger partition; then used chroot to add the various packages needed (kernel and so on) for self-hosting. After some trials-and-error, I have a booting, self-hosted Sid/Sparc64 :-) However - I have an issue where the kernel 4.3.0 doesn't find the disks. Silo works fine, but it seems the driver is not loaded. So it drops me in the initramfs shell, I modprobe sun_esp, then everything works fine. Can't figure out what's wrong (I did add sun_esp to /etc/modules and rebuilt the initrd, but no luck). Perhaps the same issue is affecting the installer? Anyway great job everyone - install is a bit rough, but so far everything is good. Next step, getting X to work on the FFB... Cordially, -- Romain Dolbeau
Re: Sparc64 tftpboot.img
2016-02-13 13:07 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > Try: > > https://people.debian.org/~glaubitz/netboot/ On my U1, I get a 'fast data access MMU miss" straight after loading "boot.img". Same network setup just installed find with the "boot.img" from lenny (which I'm upgrading to wheezy to try a chroot-like install of sparc64 on a partition). Cordially, -- Romain Dolbeau
Debian on ultra 1 (was: Re: Debian on qemu-system-sparc64)
2016-01-26 0:12 GMT+01:00 Romain Dolbeau : > Now I need to find a cd-r to burn, to try and install on my Ultra 1E if I can find the time. Just tried it, unfortunately so far no luck. I have the 20160802-16:21 image on a CD-R that boots SILO just fine, then load the kernel & initial ramdisk, then gets to "loading system daemons: ..." Then the screen goes black with a blinking underline cursor at the bottom left for a short while. Then the blinking cursor disappears. Then - nothing. It just sits there. Doesn't sound like it's using the disk or cd. Ultra 1/200E Creator 1 GB RAM Creator 3D series 2 horizontal (not the original Creator series 1) Unused TGX in the top SBus slot SUN36G disk in the bottom slot Plextor 32x CD-ROM set to 512 bytes/sector ... and I have no more serial port near it to try a serial console :-( Any suggestion welcome. Cordially, -- Romain Dolbeau
Re: Debian on qemu-system-sparc64
2016-01-25 14:51 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > It would also be interesting to know whether you could get networking > on qemu-sparc64 because recently I never managed to do that. > It seems the default machine is missing a network device, so no network by default, but that's easy to fix on the command-line: just add a network device. I just installed the ISO image in qemu on a zvol using (here the nework device is of type 'pcnet'): # qemu-system-sparc64 -machine sun4u -smp 1 -m 1024 \ -drive file=/path/to/the/vm/disk/image,id=rootdisk,if=none,format=raw -device ide-hd,drive=rootdisk \ -drive file=/path/to/debian-9.0-sparc64-NETINST-1.iso,id=datacd,if=none,format=raw -device ide-cd,drive=datacd \ -device pcnet,vlan=0 -net user,hostfwd=tcp::10023-:22 \ -nographic # The bit in -net allows to do "ssh -p 10023 user@localhost" to connect to the VM once SSH is started. It's all bog-standard, slow, non-virtio devices, but it does the job. Now I need to find a cd-r to burn, to try and install on my Ultra 1E if I can find the time. Probably won't be fast :-) Cordially, -- Romain Dolbeau
Re: Pre-compiled ghc binaries for sparc64?
2015-12-03 10:59 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > I'm cross-posting this to debian-sparc@l.d.o., maybe someone else here > has an idea how to build ghc for sparc64 without having to mess around > with cross-compilers on an amd64 host. > Apparently you don't need a cross-compiler: <https://wiki.haskell.org/GHC:FAQ#How_do_I_port_GHC_to_platform_X.3F> I quote: "Both ways require you to bootstrap from intermediate HC files: these are the stylised C files generated by GHC when it compiles Haskell source. Basically the idea is to take the HC files for GHC itself to the target machine and compile them with gcc to get a working GHC, and go from there." So basically, hack a working compiler and then rebuild the package cleanly... Cordially, -- Romain Dolbeau
Re: elfutils and libgc FTBFS
2015-11-20 11:37 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > I'm not sure whether I understand the difference. Are those different > compiler options? > Yes. From <http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html >, "The -fPIC choice always works, but may produce larger code than -fpic". Presumably a different way of relocating, more amenable to large amount of code. Cordially, -- Romain Dolbeau
Re: elfutils and libgc FTBFS
2015-11-20 10:50 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > > [1] > > https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=sparc64&ver=0.163-5.1&stamp=1447504203 force -fPIC instead of -fpic? > > [2] > > https://buildd.debian.org/status/fetch.php?pkg=libgc&arch=sparc64&ver=1%3A7.4.2-7&stamp=1447500449 > > Probably missing support. There is a sparc_mach_dep.S in the source archive, but comments in it suggest it is for Solaris. Cordially, -- Romain Dolbeau
Re: Resurrecting Debian on SPARC
2015-11-19 16:35 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > > What's the proper fix then? Preferably one that works on sparc (v8+) > as well. Just the 'mc_' :-) At least if it works with REG_O6, which I suspect it should since userland should load the glibc header rather than the kernel header (... I think). And it should work with v8+ as well (v8+ is v9 in 32 bits mode, fundamentally. So it has the new instructions like CAS, the new CCR registers, ...). %o6 has been %sp since v7, IIRC (i.e. the Stack Pointer is in Output register 6, so is available to the callee in %i6, Input register 6, as the Frame Pointer %fp). SPARC register windows are cool when you get to know them :-) Cordially, -- Romain Dolbeau
Re: Resurrecting Debian on SPARC
2015-11-19 16:21 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > > > So perhaps: > > #define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) > > ucp)->uc_mcontext.mc_gregs[MC_O6] > > I'll give that a shot. > It seems the glibc-2.21 header (sysdeps/unix/sysv/linux/sparc/sys/ucontext.h) defines REG_O6 as well, so that bit of the fix might not be necessary. It does use mc_gregs like 3.16. Cordially, -- Romain Dolbeau
Re: Resurrecting Debian on SPARC
2015-11-19 16:05 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > > https://buildd.debian.org/status/fetch.php?pkg=libsigsegv&arch=sparc64&ver=2.10-4&stamp=1447500379 > If you have any idea on how to fix this issue, I would be more than > happy to integrate your patch :). Armchair quarterbacking here, but from my old copy of linux 3.16, the registers from the windows are named mc_gregs not gregs. The definition of "ucontext_t" is in "linux-source-3.16/arch/sparc/include/uapi/asm/uctx.h". It's also not REG_O6 but MC_O6 apparently. So perhaps: #define SIGSEGV_FAULT_STACKPOINTER ((ucontext_t *) ucp)->uc_mcontext.mc_gregs[MC_O6] Cordially, -- Romain Dolbeau
Re: Resurrecting Debian on SPARC
2015-11-13 12:55 GMT+01:00 John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de>: > My intention to revive "sparc" is because it uses the V8 instruction > set as opposed to the V9 instruction set used by "sparc64". V8 > supports more software (e.g., JavaScript JIT is not supported on > V9) and more older hardware. > Commonly accessible C8 CPUs are MicroSPARC, SuperSPARC and HyperSPARC (of course there's a zillion other implementations like LEON, but those are not 'commonly' available). That's 20 years old 32 bits hardware. I love them (currently trying to rebuild some recent software on Solaris 7 and 8 in v7 and v8 on my SS20s :-), but do you really think a recent Linux would work (let alone "work well") on those? Even NetBSD has trouble on such old hardware. Also, a *lot* of software wants multithreading nowadays, and will require some form of synchronization (including ICU for Unicode, and other unlikely places). V8 doesn't have Compare-And-Swap, only Swap and Test-And-Set, like v7. It's possible to emulate CAS, but it requires an extra memory byte for the lock, which is non-trivial to do properly in the multi-process case (inefficient multi-thread is trivial). GCC doesn't supply such emulation, so lots of software will fail because symbols like __sync_fetch_and_add_4 are missing (C++11 atomic uses those nowaadays). Don't take me wrong - I would *love* to be able to update my SS5-110MHz running Debian 4 to a newer Debian. I'm just not sure whether it's worth the hassle compared to say, trying to improve NetBSD or OpenBSD... Cordially, -- Romain Dolbeau
Re: Retiring the sparc32 port
Michelle Konzack wrote: On the other side, I will leafe in short France and then i will have NO access to Electricity except a bunch (~42) of photovoltaik panels of 75W and a 4kW Bio-Fuel-Generator A 1500Mhz Via C7 (x86 32 bits), a GiB of RAM, a pair of 2.5" hard drives and a slim DVD-burner will happily work with less than 60W, and will run circles around UltraSPARC I and II cpus, let alone SuperSPARC. And will allow for USB, IEEE1394, and other recent stuff to be plugged in. (Anyone know of a VME USB card for my 4/330 ? :-) As an added bonus, AES encryption (ssl, ssh, etc.) will come for almost free, it's implemented in hardware. If you want HW RAID1 instead of SW, an old 3ware PCI RAID1 card for PATA should still fit inside 80W, 100W top. BTW, maybe this part of the discussion should be moved out of debian-sparc now ? It has strayed far from the topic for the list. -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation problems SPARCstation 5
Ryle Goehausen wrote: Naturally of course, after installing I go to reboot. I thought that maybe there was some pecularity with the install relating to the X-Windows system or however video is being displayed, because I know my video chip is 24-bit and it should be using the XSun24 X server, but I don't know how to select or configure that. Are you sure of that ? SS5 come with no on-board video ; they do have a dedicated slot for a 24 bit card, but they're often found with a regular (T)GX, which is a SBUS 8 bit card. I have no idea how to boot up with that parameter, and I was thinking of trying to reinstall and typing that in before I booted up off the CDROM, but now when I try to boot off the CDROM it just automatically takes me to my hard drive installation. The magic combination of key is called 'stop-A' ; the stop key is the top-left key of the leftmost block of keys (just below the big lonely help key). The 'A' key is ususally not a problem to find ;-) It will halt whatever the system is doing and drop you into the openboot monitor (if you've never used a Sun before, it's basically a really, really, really advanced bios). From that point you can type system commands, such as 'boot cdrom' or 'boot disk' ; there's plenty of resources on the net explaining the openboot. A good place to start is <http://www.sunhelp.org/>. It should allow you to boot the cdrom with whatever options you need. The one point of interest on a SS5 is whether its CPU is a 170 Mhz TurboSPARC (which is a crappy CPU not well supported) or a flavor of MicroSPARC II (between 70 and 110 Mhz, and resonably well supported). /proc/cpuinfo will tell you that if you can get to a linux command-line. Anyway, it won't be a fast computer... Good luck ! -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SS20: SMP trouble...
Marco Gaiarin wrote: I've swapped this SM50 with another SM50 module (again, different part number but also different ``look'': no TI logo on heatsink, ...), and the other got two identical (same part number) SM50, and their SS20 work flawlessy... check your parts number on <http://mbus.sunhelp.org/> *some* level of mixing are acceptable, some are not ; the rough guideline is, you can't mix major revisions of CPU and/or cache controller. Lots of gory details are available on <http://mbus.sunhelp.org/misc/genconf.htm> HTH -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: saving sparc for etch requalification
Chris Newport wrote: The Ecache problems only affected 400MHz Ultrasparc II modules as used in Enterprise systems. 300 MHz modules were not affected. UltrasparcIIi modules as used in the Ultra 5/10 were not affected. Ours were U10, and they definitely had L2 cache problems, and modules were replaced by Sun, no questions asked. I think they were 300 Mhz, but I'm not 100 % sure of that. Anyway, the problem was pretty obvious as the monitor would display the error directly to the console ... -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: saving sparc for etch requalification
Aurelien Jarno wrote: vorlon said the instability appears after a few days, with buildd running and eating 100% of the CPU. If the instability affects a 300 Mhz UII module (typically in an U10 or an U5), then it might very well be faulty hardware. A lot of modules fitting that description suffered serious cache problems ; the symptoms were transient uncorrectable failure in the L2 cache, resulting in a kernel panic. At my old labs, we had 6 of those delivered in one bunch, and we had to replace at least 5 or 6 modules (at least one machine had the module replaced twice). -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SparcStation 5 reinstall
Mats Hellman wrote: My problem is that I no longer have a monitor for it. So I was wondering if anyone knows a way to get into the install system over SSH or if it’s possible to have it redo everything from within the existing installation. Your best bet is probably to unplug the keyboard/mouse, and use a dumb terminal hooked to serial port A ; you can also use a common null modem cable between serial port A and another machine serial port running a terminal software such as minicom. good luck, -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software RAID on SPARC
Joost De Cock wrote: I'm trying to get Debian on a Sun Enterprise 250 (250) server. I'm using the sarge installer from CD and that seems to lack support for software RAID (MD) (the option is there, but I've read somewhere it doesn't work, and that's what it seems like when I try). I've been googling, and searching this mailinglist, and I've found lots of bits and pieces of usefull info but I just can't seem to nail it. I've got 2 SCSI disks, and I want a mirrored install on them (raid1). I've jumped plenty of hoops, and I currently have the raid disks visible when I fire up the installer, but he can't mount them. I'm just wondering if anyone can point me to some detailed instructions on how to get this working. I did found some, but I think I'm going to need some more help. The main problem is that you can't put RAID partitions at cylinder 0, or they would destroy the sun disklabel. Anything used for RAID must start at cylinder 1 or later. If you can partition the drive in a different box, you can simply put a disklabel and the RAID partition, and then boot from the installer and setup RAID. In theory, it should work... In practice, for my SS5, I installed on non-RAID partition (/ and swap), with space reserved for RAID, and moved the filesystems I wanted to preserve to the LVM-on-RAID afterwards. (main disk was 9 GiB, and secondary was 4 GiB so I only mirrored the datas, I still boot on a regular /) -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUN Enterprise 3000
Frank F. Waarsenburg wrote: /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880 /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/st /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/sd SUNW,fas is the faster version of the esp (whose name is an acronym, but I can't remember it). it *should* work with the regular esp driver. the same driver is used for all SCSI busses from the SPARCstation 1 to the SBUS-based ultras. Now, you need to check whether the esp module is loaded ; start the installation process, and when the system claim there is no disk, use alt+F2 to go to the second console, type return as required, and then do an 'lsmod'. If no esp is loaded, try loading it with 'modprobe esp'. Then check for the module 'mod_sd' the same way. If we both modules the installer refuse to see any disk, there's a problem with either the installer or the hardware. Please keep us informed of the results, -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUN Enterprise 3000
Frank F. Waarsenburg wrote: After a couple of days experimenting I came to the point that it loads a boot image through RARP/TFTP (2.6 kernel version). Now I'm stuck at the message "No partitionable media were found". The system had 2 4.2G SUN drives: no partitionable media found. So I thought the disks were messed up, and replaced them with a single COMPAQ 36G disk that I had. Same error, no partitionable media. But a probe-scsi shows both the SUN disks when they are in the system, and the COMPAQ. According to what I read on the internet, this was a bug?? Anyone that knows a workaround for this? What does the device-tree looks like ? (show-devs in the console should display it) From the device name of the SCSI bus it should be possible to determine which module you need, and then you can check wether it's loaded properly by the kernel. -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Enterprise 4000 setup
Bryan Schmidt <[EMAIL PROTECTED]> wrote: > I am trying to setup an Enterprise 4000 server with 4 (166Mhz) CPU's and > 1Gb memory but I cannot even get the setup kernel to start. I do "boot > cdrom" and get the following error. > > Allocated 8 megs of memory at 0x4000 for kernel > Loading kernel version 2.4.27 > Loading initial ramdisk (3041649 bytes at 0x470 phys, 0x40C > virt)... > Remapping kernel... Illegal instruction Could be anything, from unsupported to faulty hardware. I'd give a shot at shuffling memory around, to see if one or more stick are faulty. Also, try a complete HW check in the prom (there used to be a 'test-all' command in the openboot console, maybe it's available on the E4000 ?) good luck, -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUN Enterprise 3000
> Yes, I could. But that does not solve the problem. If the scsi drivers are > not available within Debian, it is never going to recognize the disks - as > is the case already. And will complain that there is no device to write > to. So, any help is appreciated. During netboot (don't know about cdrom boot), SCSI drivers are not present in the loaded image, but are loaded afterward from the http source (or ftp source, or whatever). This is the case for the extremely common esp driver (used on almost all sun4c and sun4m machine, and some sun4u). Maybe the SCSI driver you need would also be available in this manner, even if it's not present in the default kernel on cdrom. -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUN Enterprise 3000
Frank F. Waarsenburg <[EMAIL PROTECTED]> wrote: > recently I bought a SUN Enterprise 3000, with only a serial interface for > console connections. I tried both the RedHat ZOOT (quite old) and the > debian 31r0a distributions, but both terminate with the same problem: > unable to mount the CDRom (where it just booted from...) Looks like the > scsi interface is not recognized. Any suggestions how to continue from > here? (other than getting Solaris10) You can try to netboot. On Sun hardware it's fairly easy, in particular if you have another Debian system on the local network, as debian packages everything required. You only need to configure the bootp server (it's in the doc) and the tftp server (it's in the doc too). good luck, -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
Tom Vier <[EMAIL PROTECTED]> wrote: > It'd be easier just to install netbsd. It doesn't have all the features of > linux, but it's not bad. It has tons of apps in pkgsrc and you can get > binaries, too. As I said, I already run NetBSD on my old hardware (including a 4/330 :-), but i would like to be able to use the Debian userspace for apt-get... I love 'make world' in theory, but in practice it's kind of unuseable on really old hardware. -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
Chris Waters <[EMAIL PROTECTED]> wrote: > But the Debian NetBSD project is using GNU usersland, which should > include glibc, unless I'm greatly confused (which is certainly not out > of the question). So if glibc is a problem I don't know which libc is used by the Debian NetBSD people. But as the libc is userland software, it should be possible to compile it to v7 and v8 and have two packages, and rewrite the assembler bit that use the mult instructions for the v7 version. I assume the v8-only libc was done for performance reasons rather than an actual problem with implementing it on v7 hardware. But I may be wrong... Splitting the port between sparc32-v7, sparc32-v8 and sparc-v9 would permit multiple libc, with or without a kernel change, and with backward availability of packages if the kernel is similar enough. A question on the Debian dependency system: can it handle inter-archs dependency ? i.e. is it already feasible (in theory) to split an arch in two or more, and have dependency "fall back" from say v8 to v7 if a package is not in v8, like it does with unstable/testing/stable ? -- Romain Dolbeau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
Eric Jorgensen <[EMAIL PROTECTED]> wrote: >The real question is whether there are any sparc v8 cpus that don't > support umul. If there aren't, we should fix the libc6 deb and alter the > documentation. My understanding of the V8 spec is that all integer multiplications are mandatory for compliance. The presence of the multiplications is one of the difference with V7, as stated in appendix G of the V8 manual. -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
Eric Jorgensen <[EMAIL PROTECTED]> wrote: >The RT601 they're referring to is actually a Sparc v7 chip, and as such > is not supported by Sarge in the first place. It's also only found on the SM100 modules, which are only supported by Sun in the 670MP and similar VME beasts, but not in any other MBus machine. Anyone using a SM100 in a SS10 or SS20 (or, worse, in a SS1000 or SS2000) is asking for trouble in a painfully slow way. >I have sincere doubts whether there are more than a handfull of > supported configurations that actually need this fix, if any at all. I don't think support for SM100 should be any concern to aynone, except for historical interest - in which case SunOS 4.1.4 will do SMP reasonably well on them. Anyone else should scrounge better, faster, more reliable SMBus modules (except maybe the SM20 or SM30, which are nearly as crappy as the SM100, but *are* v8 compliant). All other sun4m machines have v8 compliant CPUs, AFAICR. -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
mag <[EMAIL PROTECTED]> wrote: > I am free software fundamentalist, so using BSD licenced code is only > marginally acceptable for me. And some will argue that the GPL, by prohibiting some forms of use, is more restrictive and therefore less free than the BSD. Which would turn this discussion into a genuine flamefest we all already have seen a thousand times, so let's stop it before it get out of hands, shall we ? :-) > Also, I think this solution have greater support burden than the linux > kernel way, where only some packages need special attention, one of them > is the kernel which I am used to custom-build anyway. You would need to > maintain buildd, cope with bugs in the all the user space related to > bsdisms, maintain special packages, etc. The point is, most of the work is already under way in the Debian NetBSD port on i386 and alpha. They're far from finished yet, but they probably have encountered (ans hopefully solved) most of the problems in packages closely related to the kernel. Also, if no one is able to keep the linux kernel running on sparc32, the manpower to port to a different kernel may still be available, as it requires a different set of skills. Anyway, it was just an idea to provoque discussion ; It'd probably better for everyone if the sparc32 port could be made to last for the next fifty years or so :-) > I hope the above did not flame;) The flicker of a lighter in the first paragraph, maybe ;-) -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
Hendrik Sattler <[EMAIL PROTECTED]> wrote: > As a side-note: does NetBSD support SMP on sun4m? This is the main issue > for me. It's supposed to, on both SuperSPARC and HyperSPARC; I haven't tried it myself, as I don't have a SMP sun4m. -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
An (flamebait ?) idea to preserve debian on sparc32...
Hello all, I know I'm going to get flamed but here I go anyway... Right now it seems the sparc32 port is in trouble, due primarily to the kernel having support problem. It can be summed up by : 1) The 2.4 kernel has trouble on some 4m hardware, and 2.6 is almost non-working ; 2) userland (mostly glibc) doesn't work on v7 hardware (all sun4 and sun4c arch, plus the SM100 modules on sun4m). So my idea is: why not go over to a kernel and libc that actually support all of the above ? Namely, the NetBSD kernel... Debian already has started support for NetBSD on i386 and alpha ; why not try and add both sparc32/v7 and sparc32/v8 (the second being able to re-use most of the first userland) to that list ? The regular sparc port would become a pure v9 port, w/o the need to support legacy HW, and people running Debian on sparc32 would be able to continue to do so. Of course some will say "why don't you run NetBSD then ?", which I do on my sun4 / sun4c (and even sun3 and sun3x :-) hardware, but I prefer apt-get and friends for my userland, as I'm sure others do. So, what do the sparc32 people think ? -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sarge may be last Debian release for 32 bit sparc systems
Blars Blarson wrote: > In my opinion, we should drop support of all 32-bit sparc systems from > Etch due to lack of people willing to spend the time to support them. This > doesn't mean that we should delibaratly break things for them, but that > the interest in continuing to support them is below what is needed to keep > them as a viable part of Debian. I have a SS5/110 w/ 96 MiB and a regular TGX that just got Sarge installed on it, and it works beautifully. That's my only sun4m, I mostly own sun4c hardware (and a few sun3 / sun3x / sun4, but I have no hope for Debian there). How much effort is needed to keep the sparc32 port alive, at least on sun4m ? There seems to be a lot of people with working hardware... As many others, I lack time and skills to be really helpful, but I'm willing to do my little bit to preserve the port if I can... -- Romain Dolbeau <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SS5/170 hanging with 2.2.14 kernel
> I get no opps, but the machine will not respond to anything including
> Stop-A. Did anything significant change between .13 & .14 for
> sparc32? Is there anything I should enable to help provide kernel
> dumps?
Not responding to Stop-A is unusual. But there's an easy way on
the SS5/170 : the TurboSPARC chip is buggy, and there's a code
sequence that lock up the CPU... and gcc _can_ generate
thay code sequence ! It happens on Solaris, anyway...
try compiling:
#
int
main(int argc, char** argv)
{
white(1)
;
}
#
use gcc -O1 (or -O2, can't remember), and lockup your SS5/170... :-(
_maybe_ that's what you are seeing, if it happens only on the 5/170.
HTH
--
DOLBEAU Romain | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann| je l'ai imaginee d'un bout a l'autre
[EMAIL PROTECTED]| -- Boris Vian
