Re: Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
Eric Jorgensen wrote: >I also question the wisdom of requiring an initrd to boot with the > sun4cdm kernel image. I am not aware of any sun4cdm machines (other than > the javastations) that have a storage medium other than scsi that are > supported by linux, and very few that have a scsi controller other than > esp. And even then, there's only the pti scsi driver available. > >Above and beyond that, between sunlance and hme i don't think it would > make the kernel much bigger at all to cover the vast majority of built-in > ethernet devices. Agreed, I think that not putting SCSI drivers in the kernel for systems which are so SCSI-oriented is simply perverse and it's all very well saying that the initrd image can be loaded as a loopback device but this is nothing but hassle when the initial /dev is empty. There are going to be people using SPARCstations as an easy entry into the Sun architecture for quite some while- people using machines thrown out of the company's drawing office, who don't know where to buy kit cheaply. Since SPARC is now left "flying the flag" for non-x86 architectures I don't think that making life difficult for people running this sort of kit is productive. -- 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: 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
On Wed, 27 Jul 2005 18:13:30 +0200 [EMAIL PROTECTED] (Romain Dolbeau) wrote: > >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. Right, so, what I'm wondering is if we're requiring a backported kernel upgrade before upgrading a sun4m machine to sarge because there's an outside chance they might be using a cpu that we don't support in sarge but incidentally needs a kernel fix for current libc. 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. I also question the wisdom of requiring an initrd to boot with the sun4cdm kernel image. I am not aware of any sun4cdm machines (other than the javastations) that have a storage medium other than scsi that are supported by linux, and very few that have a scsi controller other than esp. And even then, there's only the pti scsi driver available. Above and beyond that, between sunlance and hme i don't think it would make the kernel much bigger at all to cover the vast majority of built-in ethernet devices. -- 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: Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
On Tue, 26 Jul 2005 01:53:14 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Tuesday 26 July 2005 01:45, Eric Jorgensen wrote: > > This means that an extremely small number of machines are affected. > > Those are not particularly common boxes. It should be possible to > > detect via /proc/cpuinfo if the 601 is installed. > > Nope. You skipped a para: > "Technically only some sun4m chips are affected, but as glibc can't > reliably detect whether a system is affected it will refuse to be > upgraded on any 32bit SPARC system before a fixed kernel is installed." 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 the same chip they used in the SS2. I have sincere doubts whether there are more than a handfull of supported configurations that actually need this fix, if any at all. -- 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
On Tuesday 26 July 2005 01:45, Eric Jorgensen wrote: > This means that an extremely small number of machines are affected. > Those are not particularly common boxes. It should be possible to > detect via /proc/cpuinfo if the 601 is installed. Nope. You skipped a para: "Technically only some sun4m chips are affected, but as glibc can't reliably detect whether a system is affected it will refuse to be upgraded on any 32bit SPARC system before a fixed kernel is installed." So, the choice was made _not_ to try to detect between different sun4m processors and the kernel upgrade section _does_ apply to you. pgpIepCaUbXTF.pgp Description: PGP signature
Re: Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
On Tue, 26 Jul 2005 01:40:48 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Tuesday 26 July 2005 01:31, Eric Jorgensen wrote: > >Yes, since i have an RT626 i don't really meet the "if and only if" > > clause on needing to upgrade the kernel first. > > Hmmm? > > RT626 = SS20 = sun4m ? > (/me is not very familiar with Sparc models...) > > "sun4m CPUs are still supported but you need to install a newer kernel > version first before upgrading the system. This is necessary because > newer versions of glibc use assembler instructions not available on > certain machines, so you need a updated kernel first that emulates the > missing instructions." > > That means you qualify for the "if and only if" in 4.3.1, right? Nope, keep reading. "For those interested in the gory details: some of the sun4m chips, produced by Cypress/ROSS, don't implement the umul instruction (RT601/CY7C601, same chip, only different names). They were used in the early SPARCserver 6xxMP models. Later models used chips manufactured by TI. Currently we don't know if these are also affected." This means that an extremely small number of machines are affected. Those are not particularly common boxes. It should be possible to detect via /proc/cpuinfo if the 601 is installed. -- 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
On Tuesday 26 July 2005 01:31, Eric Jorgensen wrote: >Yes, since i have an RT626 i don't really meet the "if and only if" > clause on needing to upgrade the kernel first. Hmmm? RT626 = SS20 = sun4m ? (/me is not very familiar with Sparc models...) "sun4m CPUs are still supported but you need to install a newer kernel version first before upgrading the system. This is necessary because newer versions of glibc use assembler instructions not available on certain machines, so you need a updated kernel first that emulates the missing instructions." That means you qualify for the "if and only if" in 4.3.1, right? pgpJIG5ztQQZW.pgp Description: PGP signature
Re: Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
On Tue, 26 Jul 2005 01:23:40 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Tuesday 26 July 2005 01:21, Eric Jorgensen wrote: > >After uncovering just how interestingly munged up this system is, i > > decided to attempt a dist-upgrade to sarge. In case there was some > > confusion, dist-upgrade to woody was years ago. > > > >All seemed to be going well until aptitude flatly refused to install > > the new libc until i had a kernel newer than 2.4.21. > > You could of course have tried reading the Release Notes which contain > extensive instructions for dealing with that... Yes, since i have an RT626 i don't really meet the "if and only if" clause on needing to upgrade the kernel first. Be nice if there was an elif after that. -- 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
On Tuesday 26 July 2005 01:21, Eric Jorgensen wrote: >After uncovering just how interestingly munged up this system is, i > decided to attempt a dist-upgrade to sarge. In case there was some > confusion, dist-upgrade to woody was years ago. > >All seemed to be going well until aptitude flatly refused to install > the new libc until i had a kernel newer than 2.4.21. You could of course have tried reading the Release Notes which contain extensive instructions for dealing with that... pgpvS0qXJV2DO.pgp Description: PGP signature
