Re: Bug#111581: [bcollins@debian.org: Bug#111581: what to do about umul instructions and old SPARC boxen]
On Tue, Aug 20, 2002 at 07:40:37PM +0200, Dagfinn Ilmari Manns?ker wrote: > Philip Blundell <[EMAIL PROTECTED]> writes: > > >>cpu : Cypress/ROSS CY7C601 > > > > I think that is indeed a SPARCv7 chip. Looks like the "sun4m implies > > sparcv8" rule is not entirely hard and fast. > > One thing to check: if you have openpromfs mounted you could see what > /proc/openprom/<[EMAIL PROTECTED]>/sparc-version says. It should tell what > SPARC version the CPU really implements (or claims to implement). > > I apologize if this has already been checked, but I couldn't see any > evidence of it neither in the BTS nor the list archive. According to http://www.sparc.com/chips.shtml, it is indeed a v7. It seems though that it claims to be v8. -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: Bug#111581: [bcollins@debian.org: Bug#111581: what to do about umul instructions and old SPARC boxen]
Philip Blundell <[EMAIL PROTECTED]> writes: >>cpu : Cypress/ROSS CY7C601 > > I think that is indeed a SPARCv7 chip. Looks like the "sun4m implies > sparcv8" rule is not entirely hard and fast. One thing to check: if you have openpromfs mounted you could see what /proc/openprom/<[EMAIL PROTECTED]>/sparc-version says. It should tell what SPARC version the CPU really implements (or claims to implement). I apologize if this has already been checked, but I couldn't see any evidence of it neither in the BTS nor the list archive. > Globally enabling kernel emulation of umul for sun4m shouldn't do any > harm, so that seems like the best approach. Or, if one wanted to be > really careful, the kernel does know the exact cpu model so the > emulation could be enabled only for those Cypress parts. If compiled-in the kernel could possibly check the above entry in OpenProm to decide and fall back to something safe if it's not. -- ilmari
[yoush@cs.msu.su: Bug#111581: [bcollins@debian.org: Bug#111581: what to do about umul instructions and old SPARC boxen]]
Just bringing more folks into the discussion, and ensuring this
strangeness will be archived in the lists.
- Forwarded message from "Nikita V. Youshchenko" <[EMAIL PROTECTED]> -
From: "Nikita V. Youshchenko" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Bug#111581: [EMAIL PROTECTED]: Bug#111581: what to do about umul
instructions and old SPARC boxen]
Date: Tue, 20 Aug 2002 12:15:10 +0400
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Status: No, hits=-8.4 required=4.0
tests=SENT_BY_BTS,IN_REP_TO,FORGED_RCVD_FOUND
version=2.31
>
> I just ran the program on my SPARC LX, which is a single sun4m system.
> It executed just fine. It's running woody, and running a custom 2.2.20
> kernel (stock source).
>
> It could still be a kernel problem. Perhaps it is detecting a math
> co-processor that doesn't have proper capabilities? Maybe his Math
> co-processor is just broken?
Hmm...
The system in question used to work last 5 years without major problems,
so I don't think it has hardware problems.
But it does think that umul is illegal.
Is it possible to ask kernel what capabilities it detected? E.g. by adding
some printk() somewhere?
[EMAIL PROTECTED]:~> cat main.c
int main()
{
asm volatile ( "umul %o0, %o1, %o0" );
return 0;
}
[EMAIL PROTECTED]:~> ./main
Illegal instruction
[EMAIL PROTECTED]:~> cat /proc/cpuinfo
cpu : Cypress/ROSS CY7C601
fpu : Cypress CY7C602 FPU
promlib : Version 3 Revision 2
prom: 2.5
type: sun4m
ncpus probed: 2
ncpus active: 2
Cpu0Bogo: 39.83
Cpu1Bogo: 39.93
MMU type: ROSS Cypress-605(MP)
invall : 75
invmm : 6264
invrnge : 20697
invpg : 67634
contexts: 4096
CPU0: online
CPU1: online
[EMAIL PROTECTED]:~> uname -a
Linux snuppy 2.2.20 #1 SMP Fri Nov 16 16:15:32 EST 2001 sparc unknown
[EMAIL PROTECTED]:~>
- End forwarded message -
--
G. Branden Robinson|Religion is regarded by the common
Debian GNU/Linux |people as true, by the wise as
[EMAIL PROTECTED] |false, and by the rulers as useful.
http://people.debian.org/~branden/ |-- Lucius Annaeus Seneca
pgpAMFxv1yYDM.pgp
Description: PGP signature
Re: Bug#111581: [bcollins@debian.org: Bug#111581: what to do about umul instructions and old SPARC boxen]
> >cpu : Cypress/ROSS CY7C601 > > I think that is indeed a SPARCv7 chip. Looks like the "sun4m implies > sparcv8" rule is not entirely hard and fast. > > Globally enabling kernel emulation of umul for sun4m shouldn't do any > harm, so that seems like the best approach. Or, if one wanted to be > really careful, the kernel does know the exact cpu model so the > emulation could be enabled only for those Cypress parts. Maybe, kernel should test for [us]mul in the illegal instruction trap handler, and if detected emulate those instructions, increase instruction counter and return from the trap ?
Re: Bug#111581: [bcollins@debian.org: Bug#111581: what to do about umul instructions and old SPARC boxen]
>cpu : Cypress/ROSS CY7C601 I think that is indeed a SPARCv7 chip. Looks like the "sun4m implies sparcv8" rule is not entirely hard and fast. Globally enabling kernel emulation of umul for sun4m shouldn't do any harm, so that seems like the best approach. Or, if one wanted to be really careful, the kernel does know the exact cpu model so the emulation could be enabled only for those Cypress parts. p.
Re: what to do about umul instructions and old SPARC boxen
On Mon, Aug 19, 2002 at 01:21:35AM -0500, Branden Robinson wrote: > Can you guys look at the bug logs of #111581 and advise me? > I just ran the program on my SPARC LX, which is a single sun4m system. It executed just fine. It's running woody, and running a custom 2.2.20 kernel (stock source). It could still be a kernel problem. Perhaps it is detecting a math co-processor that doesn't have proper capabilities? Maybe his Math co-processor is just broken? My LX is a TI MicroSPARC. -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: what to do about umul instructions and old SPARC boxen
On Mon, Aug 19, 2002 at 01:21:35AM -0500, Branden Robinson wrote: > Can you guys look at the bug logs of #111581 and advise me? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=111581&repeatmerged=yes > > I need to know if this is indeed a kernel bug, and/or if there is > anything that can be done with the XFree86 packages to prevent this that > wouldn't be very unpleasant. > > The current thesis is that compiling XFree86 on a modern SPARC processor > causes "umul" instructions in the object code, which older SPARC > processors don't recognize. Not sure if this would be a kernel bug, or a GCC bug. I'll look into it. -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
what to do about umul instructions and old SPARC boxen
Can you guys look at the bug logs of #111581 and advise me? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=111581&repeatmerged=yes I need to know if this is indeed a kernel bug, and/or if there is anything that can be done with the XFree86 packages to prevent this that wouldn't be very unpleasant. The current thesis is that compiling XFree86 on a modern SPARC processor causes "umul" instructions in the object code, which older SPARC processors don't recognize. -- G. Branden Robinson| Human beings rarely imagine a god Debian GNU/Linux | that behaves any better than a [EMAIL PROTECTED] | spoiled child. http://people.debian.org/~branden/ | -- Robert Heinlein pgpcbbb1rkiST.pgp Description: PGP signature
