Is 386 processor still supported?

Is 386 processor still supported?

[Adam Osuchowski]

Recently, I found such piece of code in kernel 2.6.28 compiled for 386
processor:

# grep M386 .config
CONFIG_M386=y
# objdump -d vmlinux | grep -A11 '<_spin_lock>:'
c0321827 <_spin_lock>:
c0321827:	89 e2                	mov    %esp,%edx
c0321829:	81 e2 00 f0 ff ff    	and    $0xfffff000,%edx
c032182f:	ff 42 14             	incl   0x14(%edx)
c0321832:	ba 00 01 00 00       	mov    $0x100,%edx
c0321837:	f0 66 0f c1 10       	lock xadd %dx,(%eax)
c032183c:	38 f2                	cmp    %dh,%dl
c032183e:	74 06                	je     c0321846 <_spin_lock+0x1f>
c0321840:	f3 90                	pause  
c0321842:	8a 10                	mov    (%eax),%dl
c0321844:	eb f6                	jmp    c032183c <_spin_lock+0x15>
c0321846:	c3                   	ret    

But there is no xadd instruction on 386 processors. It is available on
486+ only. I have no chance to run this kernel on real 386 box, so I can't
check it in practice, but I think it will not run.

It is not compiler problem because it is explicitly written in assembly
in __raw_spin_lock() function (include/asm-x86/spinlock.h) and there is
no alternative code depending on CONFIG_M386.

Regards.

Re: Is 386 processor still supported?

[Jiri Kosina]

[ CCs added ]

On Thu, 8 Jan 2009, Adam Osuchowski wrote:

> Recently, I found such piece of code in kernel 2.6.28 compiled for 386
> processor:
> 
> # grep M386 .config
> CONFIG_M386=y
> # objdump -d vmlinux | grep -A11 '<_spin_lock>:'
> c0321827 <_spin_lock>:
> c0321827:	89 e2                	mov    %esp,%edx
> c0321829:	81 e2 00 f0 ff ff    	and    $0xfffff000,%edx
> c032182f:	ff 42 14             	incl   0x14(%edx)
> c0321832:	ba 00 01 00 00       	mov    $0x100,%edx
> c0321837:	f0 66 0f c1 10       	lock xadd %dx,(%eax)
> c032183c:	38 f2                	cmp    %dh,%dl
> c032183e:	74 06                	je     c0321846 <_spin_lock+0x1f>
> c0321840:	f3 90                	pause  
> c0321842:	8a 10                	mov    (%eax),%dl
> c0321844:	eb f6                	jmp    c032183c <_spin_lock+0x15>
> c0321846:	c3                   	ret    
> 
> But there is no xadd instruction on 386 processors. It is available on
> 486+ only. I have no chance to run this kernel on real 386 box, so I can't
> check it in practice, but I think it will not run.
> 
> It is not compiler problem because it is explicitly written in assembly
> in __raw_spin_lock() function (include/asm-x86/spinlock.h) and there is
> no alternative code depending on CONFIG_M386.

Hmm, this really looks like a bug to me. How about something like this 
(untested).


From: Jiri Kosina <jkosina@suse.cz>
Subject: x86: make spinlocks available on machines without xadd insn

Current kernel wouldn't compile on ancient x86 machines that don't support 
xadd instruction, as ticket spinlocks implementation unconditionally uses 
it.

On machines without CONFIG_X86_XADD, use old-style byte spinlock 
implementation instead.

Reported-by: Adam Osuchowski <adwol@zonk.pl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index d17c919..b3bc71b 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -236,6 +236,40 @@ static inline void __byte_spin_unlock(raw_spinlock_t *lock)
 	bl->lock = 0;
 }
 #else  /* !CONFIG_PARAVIRT */
+
+/* old x86 machines do not have xadd insns, use old-style locks for them */
+#ifndef CONFIG_X86_XADD
+static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
+{
+	return __byte_spin_is_locked(lock);
+}
+
+static inline int __raw_spin_is_contended(raw_spinlock_t *lock)
+{
+	return __byte_spin_is_contended(lock);
+}
+
+static __always_inline void __raw_spin_lock(raw_spinlock_t *lock)
+{
+	__byte_spin_lock(lock);
+}
+
+static __always_inline int __raw_spin_trylock(raw_spinlock_t *lock)
+{
+	return __byte_spin_trylock(lock);
+}
+
+static __always_inline void __raw_spin_unlock(raw_spinlock_t *lock)
+{
+	__byte_spin_unlock(lock);
+}
+
+static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
+						  unsigned long flags)
+{
+	__raw_spin_lock(lock);
+}
+#else /* CONFIG_X86_XADD */
 static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
 {
 	return __ticket_spin_is_locked(lock);
@@ -267,6 +301,7 @@ static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
 	__raw_spin_lock(lock);
 }
 
+#endif  /* CONFIG_X86_XADD */
 #endif	/* CONFIG_PARAVIRT */
 
 static inline void __raw_spin_unlock_wait(raw_spinlock_t *lock)

Re: Is 386 processor still supported?

[Cyrill Gorcunov]

[Jiri Kosina - Thu, Jan 08, 2009 at 02:05:48PM +0100]
| 
| [ CCs added ]
| 
| On Thu, 8 Jan 2009, Adam Osuchowski wrote:
| 
| > Recently, I found such piece of code in kernel 2.6.28 compiled for 386
| > processor:
| > 
| > # grep M386 .config
| > CONFIG_M386=y
| > # objdump -d vmlinux | grep -A11 '<_spin_lock>:'
| > c0321827 <_spin_lock>:
| > c0321827:	89 e2                	mov    %esp,%edx
| > c0321829:	81 e2 00 f0 ff ff    	and    $0xfffff000,%edx
| > c032182f:	ff 42 14             	incl   0x14(%edx)
| > c0321832:	ba 00 01 00 00       	mov    $0x100,%edx
| > c0321837:	f0 66 0f c1 10       	lock xadd %dx,(%eax)
| > c032183c:	38 f2                	cmp    %dh,%dl
| > c032183e:	74 06                	je     c0321846 <_spin_lock+0x1f>
| > c0321840:	f3 90                	pause  
| > c0321842:	8a 10                	mov    (%eax),%dl
| > c0321844:	eb f6                	jmp    c032183c <_spin_lock+0x15>
| > c0321846:	c3                   	ret    
| > 
| > But there is no xadd instruction on 386 processors. It is available on
| > 486+ only. I have no chance to run this kernel on real 386 box, so I can't
| > check it in practice, but I think it will not run.
| > 
| > It is not compiler problem because it is explicitly written in assembly
| > in __raw_spin_lock() function (include/asm-x86/spinlock.h) and there is
| > no alternative code depending on CONFIG_M386.
| 
| Hmm, this really looks like a bug to me. How about something like this 
| (untested).
| 
| 
| From: Jiri Kosina <jkosina@suse.cz>
| Subject: x86: make spinlocks available on machines without xadd insn
| 
| Current kernel wouldn't compile on ancient x86 machines that don't support 
| xadd instruction, as ticket spinlocks implementation unconditionally uses 
| it.
| 
| On machines without CONFIG_X86_XADD, use old-style byte spinlock 
| implementation instead.
| 
| Reported-by: Adam Osuchowski <adwol@zonk.pl>
| Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| 
| diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
| index d17c919..b3bc71b 100644
| --- a/arch/x86/include/asm/spinlock.h
| +++ b/arch/x86/include/asm/spinlock.h
| @@ -236,6 +236,40 @@ static inline void __byte_spin_unlock(raw_spinlock_t *lock)
|  	bl->lock = 0;
|  }
|  #else  /* !CONFIG_PARAVIRT */
| +
| +/* old x86 machines do not have xadd insns, use old-style locks for them */
| +#ifndef CONFIG_X86_XADD
| +static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
| +{
| +	return __byte_spin_is_locked(lock);
| +}
| +
| +static inline int __raw_spin_is_contended(raw_spinlock_t *lock)
| +{
| +	return __byte_spin_is_contended(lock);
| +}
| +
| +static __always_inline void __raw_spin_lock(raw_spinlock_t *lock)
| +{
| +	__byte_spin_lock(lock);
| +}
| +
| +static __always_inline int __raw_spin_trylock(raw_spinlock_t *lock)
| +{
| +	return __byte_spin_trylock(lock);
| +}
| +
| +static __always_inline void __raw_spin_unlock(raw_spinlock_t *lock)
| +{
| +	__byte_spin_unlock(lock);
| +}
| +
| +static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
| +						  unsigned long flags)
| +{
| +	__raw_spin_lock(lock);
| +}
| +#else /* CONFIG_X86_XADD */
|  static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
|  {
|  	return __ticket_spin_is_locked(lock);
| @@ -267,6 +301,7 @@ static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
|  	__raw_spin_lock(lock);
|  }
|  
| +#endif  /* CONFIG_X86_XADD */
|  #endif	/* CONFIG_PARAVIRT */
|  
|  static inline void __raw_spin_unlock_wait(raw_spinlock_t *lock)
| 

Jiri I could be wrong but it seems __byte_spin_lock is implemented
under CONFIG_PARAVIRT and now referred under #else  /* !CONFIG_PARAVIRT */
At least I didn'y found additional implementaion in tree.
Did I miss anything?

		- Cyrill -

Re: Is 386 processor still supported?

[Jiri Kosina]

On Thu, 8 Jan 2009, Cyrill Gorcunov wrote:

> Jiri I could be wrong but it seems __byte_spin_lock is implemented
> under CONFIG_PARAVIRT and now referred under #else  /* !CONFIG_PARAVIRT */
> At least I didn'y found additional implementaion in tree.
> Did I miss anything?

You're right, my bad. There is going to be some ifdef ugliness introduced 
by this unfortunately, but on the other hand it's pretty straightforward.



From: Jiri Kosina <jkosina@suse.cz>
Subject: x86: make spinlocks available on machines without xadd insn

Current kernel wouldn't compile on ancient x86 machines that don't support
xadd instruction, as ticket spinlocks implementation unconditionally uses
it.

On machines without CONFIG_X86_XADD, use old-style byte spinlock
implementation instead.

Reported-by: Adam Osuchowski <adwol@zonk.pl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

--- 

 arch/x86/include/asm/spinlock.h |   28 ++++++++++++++++++++++++----
 1 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index d17c919..1331333 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -172,10 +172,10 @@ static inline int __ticket_spin_is_contended(raw_spinlock_t *lock)
 	return (((tmp >> TICKET_SHIFT) - tmp) & ((1 << TICKET_SHIFT) - 1)) > 1;
 }
 
-#ifdef CONFIG_PARAVIRT
+#if defined(CONFIG_PARAVIRT) || !defined(CONFIG_X86_XADD)
 /*
  * Define virtualization-friendly old-style lock byte lock, for use in
- * pv_lock_ops if desired.
+ * pv_lock_ops or for machines not supporting xadd instruction.
  *
  * This differs from the pre-2.6.24 spinlock by always using xchgb
  * rather than decb to take the lock; this allows it to use a
@@ -235,30 +235,50 @@ static inline void __byte_spin_unlock(raw_spinlock_t *lock)
 	smp_wmb();
 	bl->lock = 0;
 }
-#else  /* !CONFIG_PARAVIRT */
+#else
 static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
 {
+#ifdef CONFIG_X86_XADD
 	return __ticket_spin_is_locked(lock);
+#else
+	return __byte_spin_is_locked(lock);
+#endif
 }
 
 static inline int __raw_spin_is_contended(raw_spinlock_t *lock)
 {
+#ifdef CONFIG_X86_XADD
 	return __ticket_spin_is_contended(lock);
+#else
+	return __byte_spin_is_contended(lock);
+#endif
 }
 
 static __always_inline void __raw_spin_lock(raw_spinlock_t *lock)
 {
+#ifdef CONFIG_X86_XADD
 	__ticket_spin_lock(lock);
+#else
+	__byte_spin_lock(lock);
+#endif
 }
 
 static __always_inline int __raw_spin_trylock(raw_spinlock_t *lock)
 {
+#ifdef CONFIG_X86_XADD
 	return __ticket_spin_trylock(lock);
+#else
+	return __byte_spin_trylock(lock);
+#endif
 }
 
 static __always_inline void __raw_spin_unlock(raw_spinlock_t *lock)
 {
+#ifdef CONFIG_X86_XADD
 	__ticket_spin_unlock(lock);
+#else
+	__byte_spin_unlock(lock);
+#endif
 }
 
 static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
@@ -267,7 +287,7 @@ static __always_inline void __raw_spin_lock_flags(raw_spinlock_t *lock,
 	__raw_spin_lock(lock);
 }
 
-#endif	/* CONFIG_PARAVIRT */
+#endif
 
 static inline void __raw_spin_unlock_wait(raw_spinlock_t *lock)
 {

Re: Is 386 processor still supported?

[Peter Zijlstra]

On Thu, 2009-01-08 at 14:05 +0100, Jiri Kosina wrote:
> [ CCs added ]
> 
> On Thu, 8 Jan 2009, Adam Osuchowski wrote:
> 
> > Recently, I found such piece of code in kernel 2.6.28 compiled for 386
> > processor:
> > 
> > # grep M386 .config
> > CONFIG_M386=y
> > # objdump -d vmlinux | grep -A11 '<_spin_lock>:'
> > c0321827 <_spin_lock>:
> > c0321827:	89 e2                	mov    %esp,%edx
> > c0321829:	81 e2 00 f0 ff ff    	and    $0xfffff000,%edx
> > c032182f:	ff 42 14             	incl   0x14(%edx)
> > c0321832:	ba 00 01 00 00       	mov    $0x100,%edx
> > c0321837:	f0 66 0f c1 10       	lock xadd %dx,(%eax)
> > c032183c:	38 f2                	cmp    %dh,%dl
> > c032183e:	74 06                	je     c0321846 <_spin_lock+0x1f>
> > c0321840:	f3 90                	pause  
> > c0321842:	8a 10                	mov    (%eax),%dl
> > c0321844:	eb f6                	jmp    c032183c <_spin_lock+0x15>
> > c0321846:	c3                   	ret    
> > 
> > But there is no xadd instruction on 386 processors. It is available on
> > 486+ only. I have no chance to run this kernel on real 386 box, so I can't
> > check it in practice, but I think it will not run.
> > 
> > It is not compiler problem because it is explicitly written in assembly
> > in __raw_spin_lock() function (include/asm-x86/spinlock.h) and there is
> > no alternative code depending on CONFIG_M386.
> 
> Hmm, this really looks like a bug to me. How about something like this 
> (untested).
> 
> 
> From: Jiri Kosina <jkosina@suse.cz>
> Subject: x86: make spinlocks available on machines without xadd insn
> 
> Current kernel wouldn't compile on ancient x86 machines that don't support 
> xadd instruction, as ticket spinlocks implementation unconditionally uses 
> it.
> 
> On machines without CONFIG_X86_XADD, use old-style byte spinlock 
> implementation instead.

afaik we don't support i386-smp and up spinlocks are trivial
preempt_disable() calls.

Re: Is 386 processor still supported?

[Jiri Kosina]

On Thu, 8 Jan 2009, Peter Zijlstra wrote:

> > Subject: x86: make spinlocks available on machines without xadd insn
> > Current kernel wouldn't compile on ancient x86 machines that don't support 
> > xadd instruction, as ticket spinlocks implementation unconditionally uses 
> > it.
> > On machines without CONFIG_X86_XADD, use old-style byte spinlock 
> > implementation instead.
> afaik we don't support i386-smp and up spinlocks are trivial
> preempt_disable() calls.

Hmm. Where in Kconfig is SMP for M386 not allowed?

-- 
Jiri Kosina
SUSE Labs

Re: Is 386 processor still supported?

[Peter Zijlstra]

On Thu, 2009-01-08 at 15:21 +0100, Jiri Kosina wrote:
> On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> 
> > > Subject: x86: make spinlocks available on machines without xadd insn
> > > Current kernel wouldn't compile on ancient x86 machines that don't support 
> > > xadd instruction, as ticket spinlocks implementation unconditionally uses 
> > > it.
> > > On machines without CONFIG_X86_XADD, use old-style byte spinlock 
> > > implementation instead.
> > afaik we don't support i386-smp and up spinlocks are trivial
> > preempt_disable() calls.
> 
> Hmm. Where in Kconfig is SMP for M386 not allowed?

Dunno, kconfig is too much of a jungle for a simple person like me ;-)

But afaik i386 (and possibly i486) don't support nearly enough for a
modern SMP system.

Alan used to have i486-smp I think, one of the very few ever made.

Re: Is 386 processor still supported?

[Alan Cox]

> > Hmm. Where in Kconfig is SMP for M386 not allowed?
> 
> Dunno, kconfig is too much of a jungle for a simple person like me ;-)
> 
> But afaik i386 (and possibly i486) don't support nearly enough for a
> modern SMP system.
> 
> Alan used to have i486-smp I think, one of the very few ever made.

The first systems that supported the Intel MP standard are 486 based with
external APIC. The prior systems used various proprietary MP interfaces
from the simple stuff in the Compaq (which Linux doesn't support as
Compaq refused to allow Thomas Radke to contribute it) to the fairly
extreme end of things with the Sequent boxes.

In addition our FPU emulation and some of our handling for x86 processors
where we have to do the WP bit in software is also not SMP safe.

So our minimal spec for SMP is probably 486DX + external Intel APIC.

In practice I doubt there is a single Intel APIC type 486 SMP box on the
planet running Linux (or quite possibly running at all)

Alan

Re: Is 386 processor still supported?

[Ingo Molnar]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > > Hmm. Where in Kconfig is SMP for M386 not allowed?
> > 
> > Dunno, kconfig is too much of a jungle for a simple person like me ;-)
> > 
> > But afaik i386 (and possibly i486) don't support nearly enough for a
> > modern SMP system.
> > 
> > Alan used to have i486-smp I think, one of the very few ever made.
> 
> The first systems that supported the Intel MP standard are 486 based 
> with external APIC. The prior systems used various proprietary MP 
> interfaces from the simple stuff in the Compaq (which Linux doesn't 
> support as Compaq refused to allow Thomas Radke to contribute it) to the 
> fairly extreme end of things with the Sequent boxes.
> 
> In addition our FPU emulation and some of our handling for x86 
> processors where we have to do the WP bit in software is also not SMP 
> safe.
> 
> So our minimal spec for SMP is probably 486DX + external Intel APIC.
> 
> In practice I doubt there is a single Intel APIC type 486 SMP box on the 
> planet running Linux (or quite possibly running at all)

yeah, that's very likely true. I think we could eliminate some of the SMP 
complications by requiring cmpxchg presence for CONFIG_SMP, agreed?

	Ingo

Re: Is 386 processor still supported?

[Maciej W. Rozycki]

On Thu, 8 Jan 2009, Ingo Molnar wrote:

> > So our minimal spec for SMP is probably 486DX + external Intel APIC.
> > 
> > In practice I doubt there is a single Intel APIC type 486 SMP box on the 
> > planet running Linux (or quite possibly running at all)
> 
> yeah, that's very likely true. I think we could eliminate some of the SMP 
> complications by requiring cmpxchg presence for CONFIG_SMP, agreed?

 I failed to track down a single 486 SMP system that would adhere to the 
MP spec.  There were and possibly still are APIC-based 486 SMP systems out 
there, but most likely they are not Intel MPS-compliant, by not providing 
the MP header at the very least.  Thus Linux would have to be ported and I 
gather the interest in doing so is epsilon.

 Myself, I could not resist trying an APIC-based 486 SMP box and possibly 
fixing issues if I found one and it was MPS-compliant, but nothing beyond 
that I would say.  Life's too short.

  Maciej

Re: Is 386 processor still supported?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Tue, 2009-01-13 01:06:55 +0000, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> 
>  Myself, I could not resist trying an APIC-based 486 SMP box and possibly 
> fixing issues if I found one and it was MPS-compliant, but nothing beyond 
> that I would say.  Life's too short.

While it is not SMP, I still have one or two working i386 (and
a compatible AMD) system around.

Back in the days where I ran them the last time, there were two
issues:

  * Debian's baseline libc is compiled to use LOCK and some other
    newish instructions that are not available on a real i386 CPU.
  * There was a patch flying around to introduce a kernel-based
    emulator for those instructions. However, this was (at that time)
    neither included in Debian's kernel, nor in the upstream sources.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:               http://www.eyrie.org/~eagle/faqs/questions.html
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Is 386 processor still supported?

[Maciej W. Rozycki]

On Thu, 15 Jan 2009, Jan-Benedict Glaw wrote:

>   * Debian's baseline libc is compiled to use LOCK and some other
>     newish instructions that are not available on a real i386 CPU.

 LOCK dates back to the 8086 -- it has to work with the i386.  What is not 
supported are the following i486 additions: CMPXCHG (amusingly enough 
early i486 steppings used a different opcode for this one; no idea if it 
is still possible to find such a CPU), XADD and BSWAP, the latter being 
fairly unimportant.

>   * There was a patch flying around to introduce a kernel-based
>     emulator for those instructions. However, this was (at that time)
>     neither included in Debian's kernel, nor in the upstream sources.

 UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
so why not include it like with LL/SC for MIPS?

  Maciej

Re: Is 386 processor still supported?

[Alan Cox]

>  UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
> so why not include it like with LL/SC for MIPS?

Why not just ship an additional libc with the right options ?

Re: Is 386 processor still supported?

[Maciej W. Rozycki]

On Thu, 15 Jan 2009, Alan Cox wrote:

> >  UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
> > so why not include it like with LL/SC for MIPS?
> 
> Why not just ship an additional libc with the right options ?

 Does not work for MIPS as glibc has no equivalent code for pre-LL/SC CPUs 
and LL/SC is always used.  For the i386 the situation seems worse yet as 
for pre-i486 CPUs a generic C implementation of compare-and-exchange is 
used guaranteeing silent thread unsafety. :(

 IMO, a kernel emulation of CMPXCHG and XADD (both are used by 
sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix, 
guaranteeing UP atomicity would be a cheap way to provide long-term i386 
userland support with little burden for both Linux and respective user 
software maintainers.  Certainly it adds some bloat to the kernel, but I 
think it is not an option that should be outright dismissed without 
consideration.

  Maciej

Re: Is 386 processor still supported?

[Ingo Molnar]

* Maciej W. Rozycki <macro@linux-mips.org> wrote:

> On Thu, 15 Jan 2009, Alan Cox wrote:
> 
> > >  UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
> > > so why not include it like with LL/SC for MIPS?
> > 
> > Why not just ship an additional libc with the right options ?
> 
>  Does not work for MIPS as glibc has no equivalent code for pre-LL/SC 
> CPUs and LL/SC is always used.  For the i386 the situation seems worse 
> yet as for pre-i486 CPUs a generic C implementation of 
> compare-and-exchange is used guaranteeing silent thread unsafety. :(
> 
>  IMO, a kernel emulation of CMPXCHG and XADD (both are used by 
> sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix, 
> guaranteeing UP atomicity would be a cheap way to provide long-term i386 
> userland support with little burden for both Linux and respective user 
> software maintainers.  Certainly it adds some bloat to the kernel, but I 
> think it is not an option that should be outright dismissed without 
> consideration.

patches are welcome ...

	Ingo

Re: Is 386 processor still supported?

[Pavel Machek]

> 
> * Maciej W. Rozycki <macro@linux-mips.org> wrote:
> 
> > On Thu, 15 Jan 2009, Alan Cox wrote:
> > 
> > > >  UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
> > > > so why not include it like with LL/SC for MIPS?
> > > 
> > > Why not just ship an additional libc with the right options ?
> > 
> >  Does not work for MIPS as glibc has no equivalent code for pre-LL/SC 
> > CPUs and LL/SC is always used.  For the i386 the situation seems worse 
> > yet as for pre-i486 CPUs a generic C implementation of 
> > compare-and-exchange is used guaranteeing silent thread unsafety. :(
> > 
> >  IMO, a kernel emulation of CMPXCHG and XADD (both are used by 
> > sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix, 
> > guaranteeing UP atomicity would be a cheap way to provide long-term i386 
> > userland support with little burden for both Linux and respective user 
> > software maintainers.  Certainly it adds some bloat to the kernel, but I 
> > think it is not an option that should be outright dismissed without 
> > consideration.
> 
> patches are welcome ...

Hehe, I guess the only long-term solution is to get shiny old 386 as a
part of Ingo's test farm ;-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Is 386 processor still supported?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On Fri, 2009-01-16 10:00:02 +0100, Pavel Machek <pavel@suse.cz> wrote:
> > patches are welcome ...
> 
> Hehe, I guess the only long-term solution is to get shiny old 386 as a
> part of Ingo's test farm ;-).

:-D  I'm currently cleaning up the flat, 'll try to dig out the old
patch tonight. Maybe I can play with it a bit on my original i386
hardware. (I've already tested it, it still powers on and boots up
that ancient debian version. Using a 20GB (right, gigabytes) HDD.)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                http://catb.org/~esr/faqs/smart-questions.html
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Is 386 processor still supported?

[Andrey Panin]

On 016, 01 16, 2009 at 10:00:02AM +0100, Pavel Machek wrote:
> > 
> > * Maciej W. Rozycki <macro@linux-mips.org> wrote:
> > 
> > > On Thu, 15 Jan 2009, Alan Cox wrote:
> > > 
> > > > >  UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
> > > > > so why not include it like with LL/SC for MIPS?
> > > > 
> > > > Why not just ship an additional libc with the right options ?
> > > 
> > >  Does not work for MIPS as glibc has no equivalent code for pre-LL/SC 
> > > CPUs and LL/SC is always used.  For the i386 the situation seems worse 
> > > yet as for pre-i486 CPUs a generic C implementation of 
> > > compare-and-exchange is used guaranteeing silent thread unsafety. :(
> > > 
> > >  IMO, a kernel emulation of CMPXCHG and XADD (both are used by 
> > > sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix, 
> > > guaranteeing UP atomicity would be a cheap way to provide long-term i386 
> > > userland support with little burden for both Linux and respective user 
> > > software maintainers.  Certainly it adds some bloat to the kernel, but I 
> > > think it is not an option that should be outright dismissed without 
> > > consideration.
> > 
> > patches are welcome ...
> 
> Hehe, I guess the only long-term solution is to get shiny old 386 as a
> part of Ingo's test farm ;-).

It's not so difficult BTW, i386EX CPUs are still used in embedded world.
Example: http://www.embeddedarm.com/products/board-detail.php?product=TS-3300
It even has ethernet and price is reasonable (for embedded board of course) :)

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Is 386 processor still supported?

[Ingo Molnar]

* Pavel Machek <pavel@suse.cz> wrote:

> > 
> > * Maciej W. Rozycki <macro@linux-mips.org> wrote:
> > 
> > > On Thu, 15 Jan 2009, Alan Cox wrote:
> > > 
> > > > >  UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
> > > > > so why not include it like with LL/SC for MIPS?
> > > > 
> > > > Why not just ship an additional libc with the right options ?
> > > 
> > >  Does not work for MIPS as glibc has no equivalent code for pre-LL/SC 
> > > CPUs and LL/SC is always used.  For the i386 the situation seems worse 
> > > yet as for pre-i486 CPUs a generic C implementation of 
> > > compare-and-exchange is used guaranteeing silent thread unsafety. :(
> > > 
> > >  IMO, a kernel emulation of CMPXCHG and XADD (both are used by 
> > > sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix, 
> > > guaranteeing UP atomicity would be a cheap way to provide long-term i386 
> > > userland support with little burden for both Linux and respective user 
> > > software maintainers.  Certainly it adds some bloat to the kernel, but I 
> > > think it is not an option that should be outright dismissed without 
> > > consideration.
> > 
> > patches are welcome ...
> 
> Hehe, I guess the only long-term solution is to get shiny old 386 as a
> part of Ingo's test farm ;-).

hehe :) Alas, Thomas has one and occasionally boots the kernel on it.

	Ingo

Re: Is 386 processor still supported?

[H. Peter Anvin]

Pavel Machek wrote:
> 
> Hehe, I guess the only long-term solution is to get shiny old 386 as a
> part of Ingo's test farm ;-).
> 									Pavel

Emulators are faster.

	-hpa

Re: Is 386 processor still supported?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On Thu, 2009-01-15 14:15:56 +0000, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Thu, 15 Jan 2009, Alan Cox wrote:
> > >  UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
> > > so why not include it like with LL/SC for MIPS?
> > 
> > Why not just ship an additional libc with the right options ?
> 
>  Does not work for MIPS as glibc has no equivalent code for pre-LL/SC CPUs 
> and LL/SC is always used.  For the i386 the situation seems worse yet as 
> for pre-i486 CPUs a generic C implementation of compare-and-exchange is 
> used guaranteeing silent thread unsafety. :(
> 
>  IMO, a kernel emulation of CMPXCHG and XADD (both are used by 
> sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix, 
> guaranteeing UP atomicity would be a cheap way to provide long-term i386 
> userland support with little burden for both Linux and respective user 
> software maintainers.  Certainly it adds some bloat to the kernel, but I 
> think it is not an option that should be outright dismissed without 
> consideration.

I just searched for the old patch, but couldn't find it ad hoc. (But
it must be somewhere, at least in the archives, I guess?)

The kernel emulator has the benefit of no overhead when not switched
on, and low-to-no overhead when not being used (i386 capable kernel on
i486 hardware).

Heck, I'd dig out my two test systems and give them a try with current
Debian unstable. Should be fun with four to eight megabytes of RAM.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of: 23:53 <@jbglaw> So, ich kletter' jetzt mal ins Bett.
the second  : 23:57 <@jever2> .oO( kletter ..., hat er noch Gitter vorm Bett, wie früher meine Kinder?)
              00:00 <@jbglaw> jever2: *patsch*
              00:01 <@jever2> *aua*, wofür, Gedanken sind frei!
              00:02 <@jbglaw> Nee, freie Gedanken, die sind seit 1984 doch aus!
              00:03 <@jever2> 1984? ich bin erst seit 1985 verheiratet!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Is 386 processor still supported?

[Bastien ROUCARIES]

On Thu, Jan 15, 2009 at 3:20 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Thu, 2009-01-15 14:15:56 +0000, Maciej W. Rozycki <macro@linux-mips.org> wrote:
>> On Thu, 15 Jan 2009, Alan Cox wrote:
>> > >  UP emulation of CMPXCHG and XADD for userland should be rather trivial,
>> > > so why not include it like with LL/SC for MIPS?
>> >
>> > Why not just ship an additional libc with the right options ?
>>
>>  Does not work for MIPS as glibc has no equivalent code for pre-LL/SC CPUs
>> and LL/SC is always used.  For the i386 the situation seems worse yet as
>> for pre-i486 CPUs a generic C implementation of compare-and-exchange is
>> used guaranteeing silent thread unsafety. :(
>>
>>  IMO, a kernel emulation of CMPXCHG and XADD (both are used by
>> sysdeps/i386/i486/bits/atomic.h in glibc) with an optional LOCK prefix,
>> guaranteeing UP atomicity would be a cheap way to provide long-term i386
>> userland support with little burden for both Linux and respective user
>> software maintainers.  Certainly it adds some bloat to the kernel, but I
>> think it is not an option that should be outright dismissed without
>> consideration.
>
> I just searched for the old patch, but couldn't find it ad hoc. (But
> it must be somewhere, at least in the archives, I guess?)

here http://thread.gmane.org/gmane.linux.kernel/205839, but should be
securized (use get_user() )

Regards

> The kernel emulator has the benefit of no overhead when not switched
> on, and low-to-no overhead when not being used (i386 capable kernel on
> i486 hardware).
>
> Heck, I'd dig out my two test systems and give them a try with current
> Debian unstable. Should be fun with four to eight megabytes of RAM.
>
> MfG, JBG
>
> --
>      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
> Signature of: 23:53 <@jbglaw> So, ich kletter' jetzt mal ins Bett.
> the second  : 23:57 <@jever2> .oO( kletter ..., hat er noch Gitter vorm Bett, wie früher meine Kinder?)
>              00:00 <@jbglaw> jever2: *patsch*
>              00:01 <@jever2> *aua*, wofür, Gedanken sind frei!
>              00:02 <@jbglaw> Nee, freie Gedanken, die sind seit 1984 doch aus!
>              00:03 <@jever2> 1984? ich bin erst seit 1985 verheiratet!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJb0Y/Hb1edYOZ4bsRAnEeAJ9JkaqmDFOGp1uPNzBe4qeSgl19dQCeI123
> c4oTq/pPCaUPcdJp3a/GsbU=
> =wHyn
> -----END PGP SIGNATURE-----
>
>

Re: Is 386 processor still supported?

[Alan Cox]

> userland support with little burden for both Linux and respective user 
> software maintainers.  Certainly it adds some bloat to the kernel, but I 
> think it is not an option that should be outright dismissed without 
> consideration.

Nobody normally builds for 386 (and you need the big FPU emulator etc too
and pay a big penalty for the lack of working WP bits) so it wouldn't be
a big penalty if you can actually find an i386 user any more ;)

Re: Is 386 processor still supported?

[Maciej W. Rozycki]

On Thu, 15 Jan 2009, Alan Cox wrote:

> > userland support with little burden for both Linux and respective user 
> > software maintainers.  Certainly it adds some bloat to the kernel, but I 
> > think it is not an option that should be outright dismissed without 
> > consideration.
> 
> Nobody normally builds for 386 (and you need the big FPU emulator etc too
> and pay a big penalty for the lack of working WP bits) so it wouldn't be
> a big penalty if you can actually find an i386 user any more ;)

 You can actually escape the FPU emulator if you have a proper computer 
(an i386/80287 combo, anyone? ;) -- we've got it right actually :) ), but 
the rest and overall I agree with you.  And I think i386-class cores can 
be still seen in some embedded applications, so there may be non-epsilon 
interest yet.

  Maciej

Re: Is 386 processor still supported?

[H. Peter Anvin]

Maciej W. Rozycki wrote:
> 
>  You can actually escape the FPU emulator if you have a proper computer 
> (an i386/80287 combo, anyone? ;) -- we've got it right actually :) ), but 
> the rest and overall I agree with you.  And I think i386-class cores can 
> be still seen in some embedded applications, so there may be non-epsilon 
> interest yet.
> 

I did run Linux way back when on a 16 MHz 80386/80387 combo.  All the 
memory was on the ISA bus, too.  It ran at a whopping 0.57 BogoMIPS, and 
we still used it as a server.

	-hpa

Re: Is 386 processor still supported?

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Thu, 2009-01-15 13:32:52 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > UP emulation of CMPXCHG and XADD for userland should be rather trivial, 
> > so why not include it like with LL/SC for MIPS?
> 
> Why not just ship an additional libc with the right options ?

Due to another historic bug, which created libcs targeted for i386
containing the locking code for i486, as I was told back when I first
showed interest for real i386 hardware.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                 Friends are relatives you make for yourself.
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Is 386 processor still supported?

[Sam Ravnborg]

On Thu, Jan 08, 2009 at 03:27:13PM +0100, Peter Zijlstra wrote:
> On Thu, 2009-01-08 at 15:21 +0100, Jiri Kosina wrote:
> > On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> > 
> > > > Subject: x86: make spinlocks available on machines without xadd insn
> > > > Current kernel wouldn't compile on ancient x86 machines that don't support 
> > > > xadd instruction, as ticket spinlocks implementation unconditionally uses 
> > > > it.
> > > > On machines without CONFIG_X86_XADD, use old-style byte spinlock 
> > > > implementation instead.
> > > afaik we don't support i386-smp and up spinlocks are trivial
> > > preempt_disable() calls.
> > 
> > Hmm. Where in Kconfig is SMP for M386 not allowed?
> 
> Dunno, kconfig is too much of a jungle for a simple person like me ;-)

Kconfig for x86 does nothing to prevent us from selecting SMP
when we have selected the 386 processor variant.

But then you need to enable the CONFIG_EXPERT(*) option to
select CPU type - which imply you know what you are doing.

(*) Named CONFIG_EMBEDDED for some reason.

	Sam

Re: Is 386 processor still supported?

[Andi Kleen]

Jiri Kosina <jkosina@suse.cz> writes:
>
> From: Jiri Kosina <jkosina@suse.cz>
> Subject: x86: make spinlocks available on machines without xadd insn
>
> Current kernel wouldn't compile on ancient x86 machines that don't support 
> xadd instruction, as ticket spinlocks implementation unconditionally uses 
> it.
>
> On machines without CONFIG_X86_XADD, use old-style byte spinlock 
> implementation instead.

The assumption was always the 386s don't run SMP.

So I think it would be better if you just made these xadds 
part of the UP patch implementation and patch them out on
UP systems similar to how it's done for LOCK prefixes. 
That would help non 386 UP systems too.
 
-Andi

-- 
ak@linux.intel.com