Re: Retiring the sparc32 port
andrew holway wrote: just thinkin, I don't think a sparc32 chip has been released in more than 12 years. Surely these cannot be energy efficient machines ;) And LEON processor ? A sparc V8 that can be written in a FPGA ? It runs with Linux. Berkeley university has a work in progress on a super computer that uses sparc32 too. JKB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Retiring the sparc32 port
On Sun, Jul 15, 2007 at 07:39:31PM -0400, Robert Reif wrote: just thinkin, I don't think a sparc32 chip has been released in more than 12 years. Surely these cannot be energy efficient machines ;) Aren't the Sun Rays which are still shipping using microSparc IIep chips? The clients themselves? Has anyone actually tried to boot anything else on them other than their own integrated OS? I imagine it would require a fair bit of hacking, having to disassemble them? And one would still have to reimplement the server side of things and/or the protocol they use to communicate. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Retiring the sparc32 port
I think that this seems like a very sensible way forward. The idea of letting Sparc64 evolve without worrying about sparc (32) is a good one. I think having a specific sparc (32) port is the way forward. Thanks, Chris. On 16/07/07, David Arnold [EMAIL PROTECTED] wrote: --Steven == Steven Ringwald [EMAIL PROTECTED] writes: Steven I joined the sparc32 list with the intention of Steven contributing. My surprise, and disappointment, is because Steven the first message that I saw regarding the architecture is Steven that it is going to be retired. i'm not familiar with how Debian does these things, but here's an idea of what i'd like to see happen: - SPARC32 support for lenny is formally stated to be dropped, pending for 6 months. this is *kinda* a replay of the last 4 months, but with an additional level of formality - those who wish to contribute to the SPARC64 port can thus use the v9 code generation options, etc - those who care about continued support for SPARC32 need to form a community, learn/build the required skills to maintain the critical components, being at least gcc and the Linux kernel. i imagine this will require some wiki space, a separate mailing list, and (critically) some reasonablly capable hardware for build daemons. - in 6 months, we review the situation: if the kernel and GCC/SPARC32 have attracted a sufficiently capable and committed (time-wise) team, and suitable hardware is available, we petition for the dropped, pending status to be revoked. i think at that point we'd require a separate SPARC32 platform. i'm not sure how that would be viewed by the wider Debian community, which i'd imagine is wary of additional platforms. alternatively, the SPARC32 port could operate on a semi-official basis, much like the x86-64 port did prior to etch? i don't think it's fair that those in favour of continuing SPARC32 support hold back the SPARC64 effort. those of us who care about SPARC32 need a chance to get organised, and take over the maintenance of the key components required. thoughts? d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New Wikipedia Sparc (32) entry.
All, I have copied this as widely as I could, although I realise that I may get bounced with the older addresses (Suse-sparc). I have been reading the messages that are currently circulating regarding the possible demise of sparc (32) Debian. Whilst I am not in a position to help with coding etc, I do like to use GNU/Linux on 32 bit Sun hardware. For this reason, I would not like to see support dropped. Enough has been said about this already, on the debian-sparc listhttp://lists.debian.org/debian-sparc/. One thing that did seem to recur on the lists, was the lack of knowledge of other GNU/Linux distros that supported the sparc (32) platform. In order to address this perceived gap in knowledge, I have created a (bare-bones) pagehttp://en.wikipedia.org/wiki/Sparc32_linux_distributionsat Wikipedia. This page is not intended to give information for sparc64, just sparc. The page will obviously need populating, so if anybody has any ideas, then do what wikis are designed for and feel free to edit it. Cheers, Chris.
Re: Retiring the sparc32 port
BERTRAND Joël wrote: andrew holway wrote: just thinkin, I don't think a sparc32 chip has been released in more than 12 years. Surely these cannot be energy efficient machines ;) And LEON processor ? A sparc V8 that can be written in a FPGA ? It runs with Linux. Berkeley university has a work in progress on a super computer that uses sparc32 too. Why does a Linux distribution need the latest bleeding edge kernel ? With no new hardware to support it should be easy to put together a distribution with the last known good kernel and the latest applications. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Retiring the sparc32 port
Chris Newport wrote: BERTRAND Joël wrote: andrew holway wrote: just thinkin, I don't think a sparc32 chip has been released in more than 12 years. Surely these cannot be energy efficient machines ;) And LEON processor ? A sparc V8 that can be written in a FPGA ? It runs with Linux. Berkeley university has a work in progress on a super computer that uses sparc32 too. Why does a Linux distribution need the latest bleeding edge kernel ? With no new hardware to support it should be easy to put together a distribution with the last known good kernel and the latest applications. The main trouble is there is no good kernel since 2.2 release. I use a lot of sparc32 hardware and : - 2.4 randomly crashes with watchdog reset OBP message (on all SS20 I use) ; - 2.6 is more stable, but only UP. SMP spinlock are broken (and I'm looking for volunteers to help me) ; - HyperSPARC support is broken or not usable (I have tried to boot a 2.4.32 with 4*RT626...) on 2.4 _and_ 2.6. That being said, if we work on a distribution with the last known good kernel, we can immediatly drop this distribution. To be alive, kernel has to be alive ! JKB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Retiring the sparc32 port
Chris Newport wrote: And LEON processor ? A sparc V8 that can be written in a FPGA ? It runs with Linux. Berkeley university has a work in progress on a super computer that uses sparc32 too. Why does a Linux distribution need the latest bleeding edge kernel ? With no new hardware to support it should be easy to put together a distribution with the last known good kernel and the latest applications. If Gaisler Research want to ensure that the kernel is maintained (and tested) for v8 processors then they had better raise their head above the parapet, fast. I notice that the SnapGear distro they use has both 2.0 and 2.6 kernels (2.6.21 as of today), if they want 2.6 to survive on this platform then they'd better say. Now as far as Sun is concerned... I had it put to me that Sun were unable to support open-source projects targeted at hardware older than the T1, because of their contractual relationship with SPARC International. Now that might have been oxdroppings, but the fact remains that if SPARC International have any interest in preserving v8 then they need to say so. All of these- Gaisler, CyberGuard, SPARC International- are commercial players, and can reasonably be expected to have at least some interest in preserving the v8. If they want to succeed in that then they need to make some sort of commitment to offset Sun, who by now are quite unequivocal about wanting to sell new hardware rather than helping people exploit what they already have or can afford to tinker with. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Retiring the sparc32 port
BERTRAND Joël wrote: Berkeley university has a work in progress on a super computer that uses sparc32 too. Interesting- do have a URL for that? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Retiring the sparc32 port
Mark Morgan Lloyd wrote: BERTRAND Joël wrote: Berkeley university has a work in progress on a super computer that uses sparc32 too. Interesting- do have a URL for that? No. Only this mail : I have a feeling that the broken sparc32 SMP is related to the CPU-specific SMP code, rather than the whole sparc32 port. We have added SMP support for the leon3 (V8) processor to linux-2.6.18.1, and are happily running systems with 8 CPUs in hardware and up to 16 CPUs in simulation. This is done using cache snooping to synchronize processors, i.e. we do NOT flush or disable data caches to keep the system running. I would therefore appreciate if the sparc32 SMP code was left in the kernel, and not removed because it does not work on legacy Sun systems. Leon3/SMP will be used in several projects (and products), including the UC Berkeley RAMP massively parallel computer system. We will make an effort to sync our leon3 port to the latest kernel version (2.6.21 ?), and try (again) to submit the patches for review and inclusion in the mainstream kernel. Jiri Gaisler. Gaisler Research. Regards, JKB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Retiring the sparc32 port
BERTRAND Joël wrote: Berkeley university has a work in progress on a super computer that uses sparc32 too. Interesting- do have a URL for that? No. Only this mail : I have a feeling that the broken sparc32 SMP is related to the CPU-specific SMP code, rather than the whole sparc32 port. Etc. Thanks, very interesting. My own experience with sun4d and (late) 2.4 suggests that some versions of gcc might work better than others, but I don't have methodical notes. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Retiring the sparc32 port
My own experience with sun4d and (late) 2.4 suggests that some versions of gcc might work better than others, but I don't have methodical notes. Sun4d SMP has never worked. I spent many hours trying to figure out why, and never managed to achieve a stable system. In the end I concluded that the only viable strategy was to go back to the 2.3.x release where sun4d/smp was first included, fix some bugs, and then sync the evolving sun4m specific code into sun4d one step at a time. This is unfortunately what happens when a minority interest system is allowed to bitrot for so many years. Part of the problem is the lack of Sun4d systems in the hands of kernel developers. AFAIK Sun4m/SMP and Sun4c are currently in a reasonable state and should not be difficult to keep going. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
invalid mac address
hi all, I put a Linksys PCI network card in my Sunblade 150, running etch. [EMAIL PROTECTED]:~$ uname -a Linux horatius 2.6.18-4-sparc64 #1 Mon Mar 26 11:16:07 UTC 2007 sparc64 GNU/Linux When restarting the network i get this output: SIOCADDRT: Network is unreachable Failed to bring up eth1. done. Does this mean this card/all pci cards are not supported on sparc64? nics not working is a killer for me - i want this to act as a proxy/server system for my network. Below is ifcofig and my interfaces file. PS, is not having lspci expected? horatius:~/horatius# ifconfig eth0 Link encap:Ethernet HWaddr 00:03:BA:2D:33:EC inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::203:baff:fe2d:33ec/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3217 errors:0 dropped:0 overruns:0 frame:0 TX packets:2147 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:311274 (303.9 KiB) TX bytes:400582 (391.1 KiB) Interrupt:10 Base address:0xd000 eth1 Link encap:UNSPEC HWaddr 00-03-BA-FF-FE-2D-33-EC-00-00-00-00-00-00-00-00 inet addr:172.17.42.17 Bcast:172.17.42.31 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:1 dropped:1 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) horatius:~/horatius# horatius:~/horatius# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # Eth0 = public # Eth1 = local # Eth2 = airstream # The loopback network interface auto lo iface lo inet loopback # The primary network interface (onboard, hostile network) auto eth0 iface eth0 inet dhcp # allow-hotplug eth0 # iface eth0 inet static # network 192.168.0.0 # gateway 192.168.0.1 # address 192.168.0.2 # netmask 255.255.255.0 # hostname horatius # Secondary network interface (pci, local connection) auto eth1 # iface eth1 inet dhcp # allow-hotplug eth1 iface eth1 inet static # allow-hotplug eth1 network 172.17.42.16 gateway 192.168.0.1 address 172.17.42.17 netmask 255.255.255.240 hostname horatius # Secondary network interface (pci, airstream connection) # auto eth2 # iface eth2 inet dhcp # allow-hotplug eth2 # iface eth2 inet static # network 10.0.0.0 # gateway 10.0.0.1 # address 10.0.0.2 # netmask 255.255.255.0 # hostname airstream-littlehampton -- Karl Goetz [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Possibly building OpenAFS 64-bit for sparc
(I am not subscribed to debian-sparc, but I am subscribed to debian-devel. If you don't cc debian-devel, please cc me.) Hello folks, OpenAFS (a distributed file system client and server with a fairly old code base) has userspace client programs and servers that use its internal lightweight threading library. Upstream is working slowly on converting this to pthreads for Linux, but we're not quite there yet. In the meantime, it needs to either know rather too much about the internals of glibc data structures (which broke as of glibc 2.3) or it needs to have getcontext/setcontext functions. As of the upgrade to glibc 2.3, we've switched the OpenAFS packages for all platforms over to using getcontext/setcontext. The problem is that these functions are not implemented for 32-bit SPARC, which means that the client no longer works for Debian's sparc architecture. This is a fairly long-standing bug against glibc (Bug#295173) and it seems unlikely to me that anyone wants to implement and maintain this code for 32-bit SPARC. I've verified that building the OpenAFS userspace programs 64-bit instead of 32-bit results in working binaries. So, I'm looking for guidance at this point. It seems like my alternatives (other than convincing someone to implement these functions for 32-bit SPARC) are to either drop the SPARC architecture for OpenAFS or to build the OpenAFS packages 64-bit on SPARC, which I believe is against the normal intention of the sparc architecture. However, with the proposed dropping of the 32-bit sparc kernel, perhaps building programs with these sorts of technical requirements for the 64-bit environment is a reasonable thing to do? I welcome any advice. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possibly building OpenAFS 64-bit for sparc
Russ Allbery [EMAIL PROTECTED] writes: In the meantime, it needs to either know rather too much about the internals of glibc data structures (which broke as of glibc 2.3) or it needs to have getcontext/setcontext functions. As of the upgrade to glibc 2.3, we've switched the OpenAFS packages for all platforms over to using getcontext/setcontext. Bleh, sorry. The breakpoint was glibc 2.4, not 2.3. That was otherwise going to be very confusing, given how old glibc 2.3 is. I misread a in the code as =. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
