Re: genuine cpu I386_CPU kernel support
Julian Elischer wrote: I think a 386 can assume non-SMP in which case that can be simulated just fine :-) it also simplifies a lot of the other breakages.. #if (CPU == 80386) && defined(SMP) #error "can't have smp on a 386" #endif Paging Terry Lambert...Terry Lambert, to the hackers lounge please. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
> I honestly can't see why you would want to waste your time like this, > but it's yours to waste I suppose. (Even a notorious packrat like me > has gotten rid of hardware from that era.) > > mcl Hmm, So that's you & jhb warning me off. Well I do have a ToDo list that's a mile long, so maybe I'd best take your advice :-) Thanks all though, for the informed kernel/ assembler comment we've been reading. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On Wed, Sep 23, 2009 at 05:54:34PM +0200, Julian H. Stacey wrote: > 4.11 fell out of security support some while back, but > http://www.freebsd.org/security/index.html > only lists what's still in, not what fell out when. Then see http://people.freebsd.org/~linimon/schedule/milestones.html. (Yes, I know the data for 7.2 and 8.0 are stale.) 4.11 support was extended again and again but ended 01/31/2007. Towards the end it was consuming a lot of people's time to support it, since everything newer had changed dramatically. > Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of > BSD to 386. Would be nice if we could still keep that first platform > walking, even if speed can't be called running ;-) The same comment applies. Everything has changed dramatically. > Maybe I'll get time to chase down all that came before > http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 I honestly can't see why you would want to waste your time like this, but it's yours to waste I suppose. (Even a notorious packrat like me has gotten rid of hardware from that era.) mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On Wed, 23 Sep 2009, John Baldwin wrote: On Wednesday 23 September 2009 1:21:59 pm Julian Elischer wrote: John Baldwin wrote: Other things added since then assume at least a 486. Not having cmpxchg is a bit of a killer. I think a 386 can assume non-SMP in which case that can be simulated just fine :-) it also simplifies a lot of the other breakages.. #if (CPU == 80386) && defined(SMP) #error "can't have smp on a 386" #endif No, it actually does not. The in-kernel version of cmpset for 386 was to disable interrupts while doing a cmp and jmp around a mov (even 386's have preemption, so you do have to disable interrupts). You can't do that in userland (cli is a privileged instruction), which probably mandates doing a cmpxchg emulator in the kernel for userland code. That and disabling interrupts is actually far less efficient than spl() for a UP 80386 machine. I suspect newer kernels will run slower on an 80386 than 4.x. Another issue that I know affected Linux is that the 386 would allow kernel code (CPL 0) to write to a page that was marked read-only. The 486 and later would generate a page fault. Linux takes advantage of the 486 behavior to avoid having to do explicit access checks when copying to user space, though AFAIK it checks the CPU at boot time to decide if this can be done. I haven't checked whether FreeBSD uses this feature, but it would be another thing to watch out for. -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On Wednesday 23 September 2009 1:21:59 pm Julian Elischer wrote: > John Baldwin wrote: > > On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote: > >> Rui Paulo wrote: > >>> On 22 Sep 2009, at 19:03, Nate Eldredge wrote: > >>> > On Tue, 22 Sep 2009, John Baldwin wrote: > > > My comment is to just use 4.x (seriously). A true 386 is going to > > be quite > > slow and the overhead of many things added that work well on newer > > processors > > is going to be very painful on a 386 (probably on a 486 as well). > > 4.x runs > > fine on a 386 and should support all the hardware you can stick > > into a > > machine with an 80386 CPU. > Unless, of course, you plan to put it on a network. I doubt that > 4.x is up to date with respect to security patches. > >>> I don't know if they were all applied on 4.x, but I think at least the > >>> older ones are. > >> 4.11 fell out of security support some while back, but > >>http://www.freebsd.org/security/index.html > >> only lists what's still in, not what fell out when. > >> > >> Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of > >> BSD to 386. Would be nice if we could still keep that first platform > >> walking, even if speed can't be called running ;-) > >> > >> Maybe I'll get time to chase down all that came before > >>http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 > > > > Other things added since then assume at least a 486. Not having cmpxchg is > > a > > bit of a killer. > > I think a 386 can assume non-SMP in which case that can be simulated > just fine :-) > it also simplifies a lot of the other breakages.. > > #if (CPU == 80386) && defined(SMP) > #error "can't have smp on a 386" > #endif No, it actually does not. The in-kernel version of cmpset for 386 was to disable interrupts while doing a cmp and jmp around a mov (even 386's have preemption, so you do have to disable interrupts). You can't do that in userland (cli is a privileged instruction), which probably mandates doing a cmpxchg emulator in the kernel for userland code. That and disabling interrupts is actually far less efficient than spl() for a UP 80386 machine. I suspect newer kernels will run slower on an 80386 than 4.x. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
John Baldwin wrote: On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote: Rui Paulo wrote: On 22 Sep 2009, at 19:03, Nate Eldredge wrote: On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. I don't know if they were all applied on 4.x, but I think at least the older ones are. 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of BSD to 386. Would be nice if we could still keep that first platform walking, even if speed can't be called running ;-) Maybe I'll get time to chase down all that came before http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 Other things added since then assume at least a 486. Not having cmpxchg is a bit of a killer. I think a 386 can assume non-SMP in which case that can be simulated just fine :-) it also simplifies a lot of the other breakages.. #if (CPU == 80386) && defined(SMP) #error "can't have smp on a 386" #endif The umtx stuff used by libthr assumes it can do a cmpxchg in userland for example. One idea kicked around many years ago was catching the illegal instruction faults for userland and emulating cmpxchg, but that would be a good bit of work. FreeBSD now also makes liberal use of 'xadd' for reference counts (see refcount_*()) so you would need to support that on a 386 as well. There may be other places that I'm not aware of that have similar assumptions. FWIW, I would probably not be in favor of putting any patches into the tree if you do manage to get it all working. I suspect the userbase of FreeBSD/80386 is even smaller than FreeBSD/alpha or FreeBSD/sparc64 and 80386 support would add a lot of ugly #ifdef's for miniscule gain. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote: > Rui Paulo wrote: > > On 22 Sep 2009, at 19:03, Nate Eldredge wrote: > > > > > On Tue, 22 Sep 2009, John Baldwin wrote: > > > > > >> My comment is to just use 4.x (seriously). A true 386 is going to > > >> be quite > > >> slow and the overhead of many things added that work well on newer > > >> processors > > >> is going to be very painful on a 386 (probably on a 486 as well). > > >> 4.x runs > > >> fine on a 386 and should support all the hardware you can stick > > >> into a > > >> machine with an 80386 CPU. > > > > > > Unless, of course, you plan to put it on a network. I doubt that > > > 4.x is up to date with respect to security patches. > > > > I don't know if they were all applied on 4.x, but I think at least the > > older ones are. > > 4.11 fell out of security support some while back, but > http://www.freebsd.org/security/index.html > only lists what's still in, not what fell out when. > > Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of > BSD to 386. Would be nice if we could still keep that first platform > walking, even if speed can't be called running ;-) > > Maybe I'll get time to chase down all that came before > http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 Other things added since then assume at least a 486. Not having cmpxchg is a bit of a killer. The umtx stuff used by libthr assumes it can do a cmpxchg in userland for example. One idea kicked around many years ago was catching the illegal instruction faults for userland and emulating cmpxchg, but that would be a good bit of work. FreeBSD now also makes liberal use of 'xadd' for reference counts (see refcount_*()) so you would need to support that on a 386 as well. There may be other places that I'm not aware of that have similar assumptions. FWIW, I would probably not be in favor of putting any patches into the tree if you do manage to get it all working. I suspect the userbase of FreeBSD/80386 is even smaller than FreeBSD/alpha or FreeBSD/sparc64 and 80386 support would add a lot of ugly #ifdef's for miniscule gain. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On 23 Sep 2009, at 16:54, Julian H. Stacey wrote: 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Right, but IIRC there were some folks patch 4-STABLE after the security officer dropped it. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
Rui Paulo wrote: > On 22 Sep 2009, at 19:03, Nate Eldredge wrote: > > > On Tue, 22 Sep 2009, John Baldwin wrote: > > > >> My comment is to just use 4.x (seriously). A true 386 is going to > >> be quite > >> slow and the overhead of many things added that work well on newer > >> processors > >> is going to be very painful on a 386 (probably on a 486 as well). > >> 4.x runs > >> fine on a 386 and should support all the hardware you can stick > >> into a > >> machine with an 80386 CPU. > > > > Unless, of course, you plan to put it on a network. I doubt that > > 4.x is up to date with respect to security patches. > > I don't know if they were all applied on 4.x, but I think at least the > older ones are. 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of BSD to 386. Would be nice if we could still keep that first platform walking, even if speed can't be called running ;-) Maybe I'll get time to chase down all that came before http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On 22 Sep 2009, at 19:03, Nate Eldredge wrote: On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. I don't know if they were all applied on 4.x, but I think at least the older ones are. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On Monday 21 September 2009 8:03:43 am Julian H. Stacey wrote: > Hi, > Reference: > > From: Alexey Shuvaev > > Date: Fri, 18 Sep 2009 14:56:59 +0200 > > Message-id: <20090918125659.ga88...@wep4035.physik.uni-wuerzburg.de> > > Alexey Shuvaev wrote: > > On Fri, Sep 18, 2009 at 12:09:46AM +0200, Julian H. Stacey wrote: > > > Hi hackers, > > > I'm trying to get my Genuine 386 running 7.2. It currently runs 4.11. > > > 386 was first base of FreeBSD, a shame to lose it. > > > So far I've hacked diffs as below + the normal > > > /etc/make.conf CFLAGS += -march=i386 > > > cross compiled all bins libs etc & > > > setenv DESTDIR /usr/7.2 i > > > cd /usr/src/etc l make distrib-dirs > > > cd .. ; make install > > > But manually unloading 4.11 kernel & loading 7.2 kernel & booting > > > doesnt yet boot far enough to encourage me to move bins yet, > > > I think I need to do a bit more kernel before that ? > > > This is what I gave so far. Input welcome. > > > > > > [snip] > > > > > Have you already looked at svn r137784 (and possibly some later commits)? > > http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 > > > > 0.02$, > > Alexey. > > Thanks Alexey, No I hadn't seen that. I had just a quick look so far. > I'll look more to see what tio change to compile my 80386 kernel. > PS I cc'd jhb@ who seems to be the one who removed 80386. > Maybe he has a patch set or comment. My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
Hi, Reference: > From: Alexey Shuvaev > Date: Fri, 18 Sep 2009 14:56:59 +0200 > Message-id: <20090918125659.ga88...@wep4035.physik.uni-wuerzburg.de> Alexey Shuvaev wrote: > On Fri, Sep 18, 2009 at 12:09:46AM +0200, Julian H. Stacey wrote: > > Hi hackers, > > I'm trying to get my Genuine 386 running 7.2. It currently runs 4.11. > > 386 was first base of FreeBSD, a shame to lose it. > > So far I've hacked diffs as below + the normal > > /etc/make.conf CFLAGS += -march=i386 > > cross compiled all bins libs etc & > > setenv DESTDIR /usr/7.2 i > > cd /usr/src/etc l make distrib-dirs > > cd .. ; make install > > But manually unloading 4.11 kernel & loading 7.2 kernel & booting > > doesnt yet boot far enough to encourage me to move bins yet, > > I think I need to do a bit more kernel before that ? > > This is what I gave so far. Input welcome. > > > > [snip] > > > Have you already looked at svn r137784 (and possibly some later commits)? > http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 > > 0.02$, > Alexey. Thanks Alexey, No I hadn't seen that. I had just a quick look so far. I'll look more to see what tio change to compile my 80386 kernel. PS I cc'd jhb@ who seems to be the one who removed 80386. Maybe he has a patch set or comment. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: genuine cpu I386_CPU kernel support
On Fri, Sep 18, 2009 at 12:09:46AM +0200, Julian H. Stacey wrote: > Hi hackers, > I'm trying to get my Genuine 386 running 7.2. It currently runs 4.11. > 386 was first base of FreeBSD, a shame to lose it. > So far I've hacked diffs as below + the normal > /etc/make.conf CFLAGS += -march=i386 > cross compiled all bins libs etc & > setenv DESTDIR /usr/7.2 i > cd /usr/src/etc l make distrib-dirs > cd .. ; make install > But manually unloading 4.11 kernel & loading 7.2 kernel & booting > doesnt yet boot far enough to encourage me to move bins yet, > I think I need to do a bit more kernel before that ? > This is what I gave so far. Input welcome. > > [snip] > Have you already looked at svn r137784 (and possibly some later commits)? http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 0.02$, Alexey. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
genuine cpu I386_CPU kernel support
Hi hackers,
I'm trying to get my Genuine 386 running 7.2. It currently runs 4.11.
386 was first base of FreeBSD, a shame to lose it.
So far I've hacked diffs as below + the normal
/etc/make.conf CFLAGS += -march=i386
cross compiled all bins libs etc &
setenv DESTDIR /usr/7.2 i
cd /usr/src/etc l make distrib-dirs
cd .. ; make install
But manually unloading 4.11 kernel & loading 7.2 kernel & booting
doesnt yet boot far enough to encourage me to move bins yet,
I think I need to do a bit more kernel before that ?
This is what I gave so far. Input welcome.
*** /pri/freebsd/releases/7.2-RELEASE/src/sys/./conf/options.i386 Wed Apr
15 05:14:26 2009
--- /usr/src/sys/./conf/options.i386Thu Sep 17 10:53:11 2009
***
*** 71,76
--- 71,78
NO_MEMORY_HOLEopt_cpu.h
# The CPU type affects the endian conversion functions all over the kernel.
+ // j...@berklix added I386_CPU
+ I386_CPU opt_global.h
I486_CPU opt_global.h
I586_CPU opt_global.h
I686_CPU opt_global.h
***
/pri/freebsd/releases/7.2-RELEASE/src/sys/./crypto/blowfish/arch/i386/bf_enc.S
Wed Apr 15 05:14:26 2009
--- /usr/src/sys/./crypto/blowfish/arch/i386/bf_enc.S Thu Sep 17 10:54:51 2009
***
*** 10,16
* XXX Should use CPP symbols defined as a result of
* XXX `cc -mcpu=pentiumpro'.
*/
! #if defined(I486_CPU) || defined(I586_CPU)
#include "bf_enc_586.S"
#else
#include "bf_enc_686.S"
--- 10,17
* XXX Should use CPP symbols defined as a result of
* XXX `cc -mcpu=pentiumpro'.
*/
! // j...@berklix added I386_CPU
! #if defined(I386_CPU) || defined(I486_CPU) || defined(I586_CPU)
#include "bf_enc_586.S"
#else
#include "bf_enc_686.S"
*** /pri/freebsd/releases/7.2-RELEASE/src/sys/./i386/conf/GENERIC Wed Apr
15 05:14:26 2009
--- /usr/src/sys/./i386/conf/GENERICThu Sep 17 10:56:26 2009
***
*** 18,23
--- 18,24
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.17.2.1 2009/04/15 03:14:26
kensmith Exp $
+ cpu I386_CPU# j...@berklix added I386_CPU
cpu I486_CPU
cpu I586_CPU
cpu I686_CPU
*** /pri/freebsd/releases/7.2-RELEASE/src/sys/./i386/i386/identcpu.cWed Apr
15 05:14:26 2009
--- /usr/src/sys/./i386/i386/identcpu.c Thu Sep 17 11:05:05 2009
***
*** 622,627
--- 622,628
break;
case CPUCLASS_386:
printf("386");
+ // j...@berklix do we need to add code ?
break;
#if defined(I486_CPU)
case CPUCLASS_486:
***
*** 909,915
{
#if !defined(lint)
! #if !defined(I486_CPU) && !defined(I586_CPU) && !defined(I686_CPU)
#error This kernel is not configured for one of the supported CPUs
#endif
#else /* lint */
--- 910,917
{
#if !defined(lint)
! // j...@berklix added I386_CPU
! #if !defined(I386_CPU) && !defined(I486_CPU) && !defined(I586_CPU) &&
!defined(I686_CPU)
#error This kernel is not configured for one of the supported CPUs
#endif
#else /* lint */
***
*** 920,926
--- 922,930
*/
switch (cpu_class) {
case CPUCLASS_286: /* a 286 should not make it this far, anyway */
+ #if !defined(I386_CPU)// j...@berklix added I386_CPU
case CPUCLASS_386:
+ #endif // j...@berklix added I386_CPU
#if !defined(I486_CPU)
case CPUCLASS_486:
#endif
Cheers,
Julian
--
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Mail ASCII plain text not HTML & Base64. http://asciiribbon.org
Virused Microsoft PCs cause spam. http://berklix.com/free/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
