Re: Any ideas why we can't even boot a i386 ?
On Sun, 2 Mar 2003, Terry Lambert wrote: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Sun, 2 Mar 2003, Bruce Evans wrote: On Fri, 28 Feb 2003, Poul-Henning Kamp wrote: My main concern would be if the chips have the necessary umphf to actually do a real-world job once they're done running all the overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly expensive. Actually, the lack of cmpxchg8 only makes locking more expensive. It's I.e., strictly more expensive, but not much more. Bruce, it is not a matter of the relative expensiveness of the various implementations of locking primitives, its a matter of the cummulative weight of all the locks we add to the system. Of course. A 400% pessimization of locking primitive turns into more like a 100% pessimization of locking non-primitives (at the level of mtx_lock()). Since the kernel spends only a few percent of its time (1% say) of its time in non-i386 locking non-primitives, pessimizing these non-primitives by 100% costs 1%. Since the system spends only a few percent of its time in the kernel (10% say), pessimizing the non-primitives costs a whole 0.1%. (0.1% is getting near the resolution of my benchmarkmethod (run makeworld on a fairly idle machine after rebooting).) Bruce's make world benchmark gave coverage of the cumulative weight, in support of his point. Indeed. Actual testing showed costs of 3.2% (kernel) and 0.3% (real). I made up the percentages of 1% and 0.1% by reducing these a bit (I386_CPU pessimizes more than locking, but the exact percentages aren't very interesting since they are so small). Of course there are loads that use more locks than makeworld (mainly networking with tinygrams I think -- this is why no one except networking people and benchmarkers even notice that -current is much worse than RELENG_4 (slowness from debugging options is irrelevant)). I wrote: To get the system to run I had to unbreak panicifcpuunsupported() so that it doesn't gratuitously reject Athlons (CPUs that are upward compatible should not be rejected), and had to replace pmap.o by the non-386 version since the 386 version caused strange errors. It's not clear why the 386 version doesn't work -- the only internal difference in pmap.c is that the 386 version uses invltlb() and other versions use invlpg(). Using invlpg() would probably make things more than 0.3% slower. Selecting the best inv*() was the main optimization that we dropped when 386 support was made incompatible with support for later CPUs. Configuring DISABLE_PG_G fixed the problem with pmap. invlpg() apparently doesn't work with global pages, but I386_CPU doesn't stop global pages being configured. world with my kernel configured for I486_CPU through I686_CPU %%% 1532 MHz AthlonXP 1600 256MB 2 ATA drives async mounted /usr/obj (src on separate drive) -- elf make world completed on Sun Mar 2 16:30:55 EST 2003 (started Sun Mar 2 15:53:15 EST 2003) -- 2260.31 real 1729.55 user 326.24 sys 40208 maximum resident set size 2248 average shared memory size 1762 average unshared data size 127 average unshared stack size 14959205 page reclaims 25630 page faults 0 swaps 43481 block input operations 3963 block output operations 0 messages sent 0 messages received 5 signals received 313523 voluntary context switches 607085 involuntary context switches %%% world with my kernel configured for I386_CPU except for pmap.o %%% 1532 MHz AthlonXP 1600 256MB 2 ATA drives async mounted /usr/obj (src on separate drive) -- elf make world completed on Mon Mar 3 03:00:45 EST 2003 (started Mon Mar 3 02:22:57 EST 2003) -- 2267.98 real 1730.21 user 336.73 sys 40208 maximum resident set size 2245 average shared memory size 1756 average unshared data size 127 average unshared stack size 14958931 page reclaims 26265 page faults 0 swaps 44148 block input operations 3898 block output operations 0 messages sent 0 messages received 6 signals received 313986 voluntary context switches 598687 involuntary context switches %%% As might be expected, using invlpg() and not using global pages costs more than pessimizing locking primitives. It costs an additional 1.6% (real) and 5.9% (sys): world with my kernel configured for I386_CPU and DISABLE_PG_G %%% 1532 MHz AthlonXP 1600 256MB 2 ATA drives async mounted /usr/obj (src on separate drive)
Re: Any ideas why we can't even boot a i386 ?
On 28-Feb-2003 Terry Lambert wrote: John Baldwin wrote: Or you can use PXE at your provisioning center and have the BIOS setup to boot from the hard disk first, which will fail for the initial boot and fall back to PXE. Then once the box is installed you ship it to its destination. This is a possibility; however, there are a number of system failure scenarios that make this undesirable. Specifically, it's desirable to support the idea of a fallback boot (e.g. nextboot) for a partially functional system, to downgrade it automatically, and make it at least something other than a doorstop on which one has to pay international shipping. In your scenario, there's no possible reupgrade method. We perform upgrades in the field using a different transport. In the case of major problems it is possible to ship a new drive out to a system. We just launched a closed-box appliance yesterday. Actually, it's going live to actual customers in about an hour and a half, but I digress. :) You should shout it to the world... at least post a press release to -advocacy! The real press release is coming from my company's PR department. Not sure of an ETA though. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Sun, 2 Mar 2003, Bruce Evans wrote: On Fri, 28 Feb 2003, Poul-Henning Kamp wrote: My main concern would be if the chips have the necessary umphf to actually do a real-world job once they're done running all the overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly expensive. Actually, the lack of cmpxchg8 only makes locking more expensive. It's I.e., strictly more expensive, but not much more. [cycle types for Athlon1600 running 386 code] Here are whorldstone benchmarks for an Athlon. The 386 version was a whole 0.3% slower for real time (3.2% slower for system time). To get the system to run I had to unbreak panicifcpuunsupported() so that it doesn't gratuitously reject Athlons (CPUs that are upward compatible should not be rejected), and had to replace pmap.o by the non-386 version since the 386 version caused strange errors. It's not clear why the 386 version doesn't work -- the only internal difference in pmap.c is that the 386 version uses invltlb() and other versions use invlpg(). Using invlpg() would probably make things more than 0.3% slower. Selecting the best inv*() was the main optimization that we dropped when 386 support was made incompatible with support for later CPUs. world with my kernel configured for I486_CPU through I686_CPU %%% 1532 MHz AthlonXP 1600 256MB 2 ATA drives async mounted /usr/obj (src on separate drive) -- elf make world completed on Sun Mar 2 16:30:55 EST 2003 (started Sun Mar 2 15:53:15 EST 2003) -- 2260.31 real 1729.55 user 326.24 sys 40208 maximum resident set size 2248 average shared memory size 1762 average unshared data size 127 average unshared stack size 14959205 page reclaims 25630 page faults 0 swaps 43481 block input operations 3963 block output operations 0 messages sent 0 messages received 5 signals received 313523 voluntary context switches 607085 involuntary context switches %%% world with my kernel configured for I386_CPU except for pmap.o %%% 1532 MHz AthlonXP 1600 256MB 2 ATA drives async mounted /usr/obj (src on separate drive) -- elf make world completed on Mon Mar 3 03:00:45 EST 2003 (started Mon Mar 3 02:22:57 EST 2003) -- 2267.98 real 1730.21 user 336.73 sys 40208 maximum resident set size 2245 average shared memory size 1756 average unshared data size 127 average unshared stack size 14958931 page reclaims 26265 page faults 0 swaps 44148 block input operations 3898 block output operations 0 messages sent 0 messages received 6 signals received 313986 voluntary context switches 598687 involuntary context switches %%% Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message [EMAIL PROTECTED], Bruce Evans writes: On Sun, 2 Mar 2003, Bruce Evans wrote: On Fri, 28 Feb 2003, Poul-Henning Kamp wrote: My main concern would be if the chips have the necessary umphf to actually do a real-world job once they're done running all the overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly expensive. Actually, the lack of cmpxchg8 only makes locking more expensive. It's I.e., strictly more expensive, but not much more. Bruce, it is not a matter of the relative expensiveness of the various implementations of locking primitives, its a matter of the cummulative weight of all the locks we add to the system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Sun, 2 Mar 2003, Bruce Evans wrote: On Fri, 28 Feb 2003, Poul-Henning Kamp wrote: My main concern would be if the chips have the necessary umphf to actually do a real-world job once they're done running all the overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly expensive. Actually, the lack of cmpxchg8 only makes locking more expensive. It's I.e., strictly more expensive, but not much more. Bruce, it is not a matter of the relative expensiveness of the various implementations of locking primitives, its a matter of the cummulative weight of all the locks we add to the system. Bruce's make world benchmark gave coverage of the cumulative weight, in support of his point. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
Hi, At 21:06 28/2/03, M. Warner Losh wrote: [...] We have some a few embedded systems coming back from the field soon and I plan on trying some tests on them (they are amd 386, so might not be good for you). [etc] IIRC AMD had a mask deal with Intel for the 386, so should be OK. -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Fri, 28 Feb 2003, Poul-Henning Kamp wrote: My main concern would be if the chips have the necessary umphf to actually do a real-world job once they're done running all the overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly expensive. Actually, the lack of cmpxchg8 only makes locking more expensive. It's hard to say how long cmpxchg8 would take on i386's if i386's had it, but it involves memory accesses which i386's are especially poor at, so I guess it would take about 2/3 as long as the main extra instructions that we use in the CPU_I386 case (pushfl: 4 cycles; cli: 3 cycles; popfl: 5 cycles). Actual testing on an Athlon1600XP in userland for the core of mtx_lock_*() + mtx_unlock_*(), namely atomic_cmpset_acq_ptr() + atomic_cmpset_rel_ptr(), run in a loop (cycle counts include loop overhead): 10 cycles in the !CPU_i386 case 42 cycles in the CPU_I386 case 36 cycles in the CPU_I386 case with cli removed 12 cycles in the CPU_I386 case with cli removed and popfl changed to addl $4,%%esp 9 cycles in the CPU_I386 case with pushfl, cli and popfl removed So the i386 code is almost the same speed on AthlonXP's in user mode except for the expensive cli and popfl instructions. However, these instructions aren't so relatively expensive on plain i386's; i386's are just generally slow and their privileged instructions aren't much slower than their integer instructions. The relative slowdown for the full mtx_*lock*() functions would be smaller since these functions do more. mtx_unlock_spin() uses atomic_store_rel_ptr() so it doesn't go near cmpxchg8 or cli and the above times the acquire/release times are almost twice as small as above. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
Bob Bishop wrote: At 21:06 28/2/03, M. Warner Losh wrote: [...] We have some a few embedded systems coming back from the field soon and I plan on trying some tests on them (they are amd 386, so might not be good for you). [etc] IIRC AMD had a mask deal with Intel for the 386, so should be OK. Are you sure that AMD did not use the IBM Blue Lightening core? I'm pretty sure that there are a huge number of embedded controllers that used the Intel 386GX macrocell, though... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
Blue Lightning was an i486 core in a i386SX/DX compatible package (usually SX). AMD's i386DX's predate Blue Lightning by about 5 years. Adam - Original Message - From: Terry Lambert [EMAIL PROTECTED] To: Bob Bishop [EMAIL PROTECTED] Cc: M. Warner Losh [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 01, 2003 10:57 AM Subject: Re: Any ideas why we can't even boot a i386 ? Bob Bishop wrote: At 21:06 28/2/03, M. Warner Losh wrote: [...] We have some a few embedded systems coming back from the field soon and I plan on trying some tests on them (they are amd 386, so might not be good for you). [etc] IIRC AMD had a mask deal with Intel for the 386, so should be OK. Are you sure that AMD did not use the IBM Blue Lightening core? I'm pretty sure that there are a huge number of embedded controllers that used the Intel 386GX macrocell, though... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On 28-Feb-2003 Garance A Drosihn wrote: At 3:55 PM -0800 2/27/03, Marcel Moolenaar wrote: On Thu, Feb 27, 2003, Garance A Drosihn wrote: ... JMB wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. Well, doesn't that suggest that it would be GOOD if the release process itself had to build a GENERIC_I386 kernel? It's never good to add to your release cycle something you don't build/validate during development. Releases are painful enough that you don't want to turn them into testbeds. If it's not worth testing during development, it's not worth releasing... Okay, that also makes good sense. But if that is true, then maybe we should officially tell our users that they *must* stay with the 4.x-series if they are running 386 hardware. I do think that the project has plenty of work with 5.x-series, particularly as we try to add sparc64, ppc, and maybe more hardware platforms. We do have a lot to test already, and there is no sense pretending to support i386 when we don't have the resources or the inclination to really test it. I think we're hitting that grey area where we do not really support i386, but for pride's sake we don't quite want to admit that 5.x will not support it. I personally think that we should not support the 80386 in 5.x. However when that has been brought up before there were a lot of theoretical objections. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On 28-Feb-2003 Terry Lambert wrote: David Schultz wrote: Thus spake Terry Lambert [EMAIL PROTECTED]: John Baldwin wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People who build embedded devices that need to be supported in the field, and want to worry about their software, and not the platform it runs on, don't use -current, FWIW. Moot point. People who build embedded devices have separate, usually modern, machines for building their kernels. They also outsource their hardware, and have to provide a golden master CDROM. Yep, and they can easily build a custom CD to do that. Where I work we have a custom CD that includes a set of sysinstall configuration scripts, etc. Likewise, when you have a room full of appliance boxes that are rack-mounted, and have serial consoles, no CDROM, no floppy, or other removable media, the normal way you use to install an image is to boot up the current image, copy over the sysinstall from an already installed bootstrap system with a CDROM drive, and then NFS mount the CDROM, and run the sysinstall from the serial console, and lie and tell it the thing was mounted locally. Or you can use PXE at your provisioning center and have the BIOS setup to boot from the hard disk first, which will fail for the initial boot and fall back to PXE. Then once the box is installed you ship it to its destination. If you've never built a closed-box appliance, then you are probably not familiar with the operational differences you have to live with, compared to something like Yahoo or RackSpace, etc.. We just launched a closed-box appliance yesterday. Actually, it's going live to actual customers in about an hour and a half, but I digress. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message [EMAIL PROTECTED], John Baldwin writes: I personally think that we should not support the 80386 in 5.x. However when that has been brought up before there were a lot of theoretical objections. Well, unless somebody actually manages to put a -current on an i386 and run the tests I suggested in a couple of weeks, then I think those theoretical objections stand very weakly in the light of proven reality :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
John Baldwin wrote: Or you can use PXE at your provisioning center and have the BIOS setup to boot from the hard disk first, which will fail for the initial boot and fall back to PXE. Then once the box is installed you ship it to its destination. This is a possibility; however, there are a number of system failure scenarios that make this undesirable. Specifically, it's desirable to support the idea of a fallback boot (e.g. nextboot) for a partially functional system, to downgrade it automatically, and make it at least something other than a doorstop on which one has to pay international shipping. In your scenario, there's no possible reupgrade method. I understand that FreeBSD doesn't have a built-in graceful fallback mechanism, and that appliance vendors have had to, traditionally, roll their own, but, for example, the Whistle InterJet had a fairly marvelous fallback mechanism, which did work really well, as long as you didn't try to do version insertion (that's a middle management problem, not a technical one). We just launched a closed-box appliance yesterday. Actually, it's going live to actual customers in about an hour and a half, but I digress. :) You should shout it to the world... at least post a press release to -advocacy! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Fri Feb 28, 2003 at 04:42:14PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], John Baldwin writes: I personally think that we should not support the 80386 in 5.x. However when that has been brought up before there were a lot of theoretical objections. Well, unless somebody actually manages to put a -current on an i386 and run the tests I suggested in a couple of weeks, then I think those theoretical objections stand very weakly in the light of proven reality :-) Anyways, nothing keeps a old hardware freak (like me) to take over the maintainership of 386-related stuff, if he wants to. Thing is, no one stepped forward at this time, so I guess this settles the future of the 386. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], John Baldwin writes: : : I personally think that we should not support the 80386 in 5.x. : However when that has been brought up before there were a lot of : theoretical objections. : : Well, unless somebody actually manages to put a -current on an i386 : and run the tests I suggested in a couple of weeks, then I think : those theoretical objections stand very weakly in the light of : proven reality :-) Two weeks notice is too short to put something to the sword. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message [EMAIL PROTECTED], M. Warner Losh writes: In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], John Baldwin writes: : : I personally think that we should not support the 80386 in 5.x. : However when that has been brought up before there were a lot of : theoretical objections. : : Well, unless somebody actually manages to put a -current on an i386 : and run the tests I suggested in a couple of weeks, then I think : those theoretical objections stand very weakly in the light of : proven reality :-) Two weeks notice is too short to put something to the sword. I'm not suggesting we should. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], M. Warner Losh writes: : In message: [EMAIL PROTECTED] : Poul-Henning Kamp [EMAIL PROTECTED] writes: : : In message [EMAIL PROTECTED], John Baldwin writes: : : : : I personally think that we should not support the 80386 in 5.x. : : However when that has been brought up before there were a lot of : : theoretical objections. : : : : Well, unless somebody actually manages to put a -current on an i386 : : and run the tests I suggested in a couple of weeks, then I think : : those theoretical objections stand very weakly in the light of : : proven reality :-) : : Two weeks notice is too short to put something to the sword. : : I'm not suggesting we should. Just making sure. We have some a few embedded systems coming back from the field soon and I plan on trying some tests on them (they are amd 386, so might not be good for you). Also, 386-core based chips are still in production (or have been in the last year). It has only been very recently that the embedded chips have transitioned to 486. Calling them, as others have, 10 years obsolete is a bit of an overstatement... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message [EMAIL PROTECTED], M. Warner Losh writes: Also, 386-core based chips are still in production (or have been in the last year). It has only been very recently that the embedded chips have transitioned to 486. Calling them, as others have, 10 years obsolete is a bit of an overstatement... My main concern would be if the chips have the necessary umphf to actually do a real-world job once they're done running all the overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly expensive. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Fri, 28 Feb 2003 14:06:13 -0700 (MST), M. Warner Losh [EMAIL PROTECTED] said: Also, 386-core based chips are still in production (or have been in the last year). It has only been very recently that the embedded chips have transitioned to 486. Calling them, as others have, 10 years obsolete is a bit of an overstatement... There is lots of obsolete technology that's still in production somewhere. It is no less trailing-edge for remaining available. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Any ideas why we can't even boot a i386 ?
--- Forwarded Message Return-Path: [EMAIL PROTECTED] Date: Thu, 27 Feb 2003 05:19:48 -0500 (EST) From: Geoffrey [EMAIL PROTECTED] To: Poul-Henning Kamp [EMAIL PROTECTED] Subject: Re: Volunteer with genuine i386 cpu lots of time wanted. In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: `][!RL*!!,$i!`[=! X-Spam-Status: No, hits=0.00 required=0.90 On Wed, 26 Feb 2003, Poul-Henning Kamp wrote: Is there anybody out there who can try to run a straight -current on a _real_ i386 class CPU ? Ie, not a i486, not a Cyrix, not an AMD but a genuine Intel i386DX (SX would be but too suicidal to be informative). Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: int=0006 err= efl=00010086 eip=c0211a71 eax=0004 ebx=c0389154 ecx= edx=c036dc60 esi=c0389238 edi=c0389148 ebp=c082dd5c esp=c082dd5c cs=0008 ds=0010 es=0010 fs=0018 gs=0010 ss=0010 cs:eip=0f b1 15 1a 20 37 c0 0f-94 c0 0f bb c0 85 c0 74 02 c9 c3 6a 00 6a 00 6a 00 6a-00 68 00 20 37 c0 a8 1a ss:esp=94 dd 82 c0 de 0b 00 c0-00 00 00 00 00 00 00 00 00 00 00 77 00 c0 91-38 c0 00 00 00 00 00 00 BTX halted hmmm .. you think it doesn't like my hardware? I could try installing something previous (like 4.7) and cvsupping if you are interested. Please let me know - I'm game for this and it is a pleasant break from wrangling world weary sun3s back into some semblance of service. Thankyou. --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
* De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-02-27 ] [ Subjecte: Any ideas why we can't even boot a i386 ? ] Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: Was this normal release? I thought I recalled a convo resulting in the decision that 386 would require special release bits? -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, Feb 27, 2003 at 04:27:06AM -0600, Juli Mallett wrote: Was this normal release? I thought I recalled a convo resulting in the decision that 386 would require special release bits? -- Juli Mallett [EMAIL PROTECTED] - AIM: BSDFlata -- IRC: juli on EFnetThe 386 CPU is already gone from GENERIC in -current # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.376 2003/02/13 22:24:43 obrien Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC maxusers0 -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, 27 Feb 2003, Juli Mallett wrote: * De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-02-27 ] [ Subjecte: Any ideas why we can't even boot a i386 ? ] Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: Was this normal release? I thought I recalled a convo resulting in the decision that 386 would require special release bits? Yes, it was from release floppies written a couple of weeks ago. In fairness, it might not like my scsi host adapter (Adaptec 1542CF). Or there may be an issue with the size of the drive (HP C2490 - 2 GB). The bios only supports one controller so fitting enough IDE drives for src, obj, usr and swap wasn't an option. Sorry. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message [EMAIL PROTECTED], Geoffrey writes: On Thu, 27 Feb 2003, Juli Mallett wrote: * De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-02-27 ] [ Subjecte: Any ideas why we can't even boot a i386 ? ] Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: Was this normal release? I thought I recalled a convo resulting in the decision that 386 would require special release bits? Yes, it was from release floppies written a couple of weeks ago. In fairness, it might not like my scsi host adapter (Adaptec 1542CF). Or there may be an issue with the size of the drive (HP C2490 - 2 GB). The bios only supports one controller so fitting enough IDE drives for src, obj, usr and swap wasn't an option. You need to recompile a kernel where you explicitly add support for the i386 cpu. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
Just out of curiosity, is your agenda to convince everyone to nix 386 support altogether or to fix 386 support? I'm not against either, although I consider the latter goal to be a bit silly. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message [EMAIL PROTECTED], David Schultz writes: Just out of curiosity, is your agenda to convince everyone to nix 386 support altogether or to fix 386 support? I'm not against either, although I consider the latter goal to be a bit silly. My agenda is to find some data either in support of or disproving a theory I have about a timing related issue. I realize that we may instead end up with some entirely different data which proves that we should not carry 386[sd]x support forward in RELENG_5. If so I can live with that, I'll have to find another way to find my datapoints then. I also don't think we should even think about redecorating this particular bikeshed at this time. If two weeks from now nobody has managed to get -current on a genuine 386[sd]x CPU, then we have a new data point which might merit discussion. Right we would just have the usual arm-chair generals and pundits pounding their pulpits. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
I believe i386 compatible code was disabled in the kernel because it was hindering the performance of more advanced Intel based architectures. Supposedly you can build it back in but that would either require building a release yourself or finding someone who already built the i386 version. Might be nice to have two x86 ISO versions for releases in that case so people don't feel screwed :). Dave On Thursday, February 27, 2003, at 04:24 AM, Poul-Henning Kamp wrote: --- Forwarded Message Return-Path: [EMAIL PROTECTED] Date: Thu, 27 Feb 2003 05:19:48 -0500 (EST) From: Geoffrey [EMAIL PROTECTED] To: Poul-Henning Kamp [EMAIL PROTECTED] Subject: Re: Volunteer with genuine i386 cpu lots of time wanted. In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: `][!RL*!!,$i!`[=! X-Spam-Status: No, hits=0.00 required=0.90 On Wed, 26 Feb 2003, Poul-Henning Kamp wrote: Is there anybody out there who can try to run a straight -current on a _real_ i386 class CPU ? Ie, not a i486, not a Cyrix, not an AMD but a genuine Intel i386DX (SX would be but too suicidal to be informative). Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: int=0006 err= efl=00010086 eip=c0211a71 eax=0004 ebx=c0389154 ecx= edx=c036dc60 esi=c0389238 edi=c0389148 ebp=c082dd5c esp=c082dd5c cs=0008 ds=0010 es=0010 fs=0018 gs=0010 ss=0010 cs:eip=0f b1 15 1a 20 37 c0 0f-94 c0 0f bb c0 85 c0 74 02 c9 c3 6a 00 6a 00 6a 00 6a-00 68 00 20 37 c0 a8 1a ss:esp=94 dd 82 c0 de 0b 00 c0-00 00 00 00 00 00 00 00 00 00 00 77 00 c0 91-38 c0 00 00 00 00 00 00 BTX halted hmmm .. you think it doesn't like my hardware? I could try installing something previous (like 4.7) and cvsupping if you are interested. Please let me know - I'm game for this and it is a pleasant break from wrangling world weary sun3s back into some semblance of service. Thankyou. --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, Feb 27, 2003 at 05:35:13AM -0500, Geoffrey wrote: On Thu, 27 Feb 2003, Juli Mallett wrote: * De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-02-27 ] [ Subjecte: Any ideas why we can't even boot a i386 ? ] Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: Was this normal release? I thought I recalled a convo resulting in the decision that 386 would require special release bits? Yes, it was from release floppies written a couple of weeks ago. In fairness, it might not like my scsi host adapter (Adaptec 1542CF). Or there may be an issue with the size of the drive (HP C2490 - 2 GB). The bios only supports one controller so fitting enough IDE drives for src, obj, usr and swap wasn't an option. : RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v : Working file: GENERIC : head: 1.376 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 508; selected revisions: 1 : description: : : revision 1.296 : date: 2001/01/14 10:11:10; author: jhb; state: Exp; lines: +2 -2 : Remove I386_CPU from GENERIC. Support for the 386 seriously pessimizes : performance on other x86 processors. Custom kernels can still be built : that will run on the 386. : = Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: Any ideas why we can't even boot a i386 ?
On Thu, Feb 27, 2003 at 01:27:55PM +0200, Ruslan Ermilov wrote: On Thu, Feb 27, 2003 at 05:35:13AM -0500, Geoffrey wrote: On Thu, 27 Feb 2003, Juli Mallett wrote: * De: Poul-Henning Kamp [EMAIL PROTECTED] [ Data: 2003-02-27 ] [ Subjecte: Any ideas why we can't even boot a i386 ? ] Yup. 386dx - 33Mhz. Results below: Loaded kern.flp, mfsroot.flp, prompted for boot, then core dumped as follows: Was this normal release? I thought I recalled a convo resulting in the decision that 386 would require special release bits? Yes, it was from release floppies written a couple of weeks ago. In fairness, it might not like my scsi host adapter (Adaptec 1542CF). Or there may be an issue with the size of the drive (HP C2490 - 2 GB). The bios only supports one controller so fitting enough IDE drives for src, obj, usr and swap wasn't an option. : RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v : Working file: GENERIC : head: 1.376 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 508; selected revisions: 1 : description: : : revision 1.296 : date: 2001/01/14 10:11:10; author: jhb; state: Exp; lines: +2 -2 : Remove I386_CPU from GENERIC. Support for the 386 seriously pessimizes : performance on other x86 processors. Custom kernels can still be built : that will run on the 386. : = Also in src/UPDATING: : 20010116: : The kernel option I386_CPU is now mutually exclusive with the : other cpu types. If you have an i386 system, be sure that it : only had this line. Remove it for all other configurations. Also in FreeBSD/i386 5.0-RELEASE Release Notes: : 2.1.1 Processor/Motherboard Support : [...] :Support for the 80386 processor has been removed from the GENERIC :kernel, as this code seriously pessimizes performance on other :IA32 processors. The I386_CPU kernel option to support the 80386 :processor is now mutually exclusive with support for other IA32 :processors; this should slightly improve performance on the 80386 :due to the elimination of runtime processor type checks. Custom :kernels that will run on the 80386 can still be built by changing :the CPU options in the kernel configuration file to only include :I386_CPU. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: Any ideas why we can't even boot a i386 ?
At 1:27 PM +0200 2/27/03, Ruslan Ermilov wrote: : RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v : Working file: GENERIC : description: : : revision 1.296 : date: 2001/01/14 10:11:10; author: jhb; state: Exp; lines: +2 -2 : : Remove I386_CPU from GENERIC. Support for the 386 seriously : pessimizes performance on other x86 processors. Custom kernels : can still be built that will run on the 386. While there was good reason for removing i386 from GENERIC, that does mean that someone just wanting to try freebsd on a i386 may very well give up before realizing that it does (hopefully!) work. For official release CDs, should we also provide a GENERIC_I386 kernel, so the person can get up-and-running without having to first build a new kernel? Or will they just run into other problems once they get past the kernel, due to everything else in the system being compiled for i486 newer? I think we (developers) get a little too used to having multiple machines around, and assume that everyone who might want to test freebsd will have some hardware that works for the GENERIC kernel, and which they can use to first do a buildkernel for the hardware they really want to test freebsd on. I'm thinking maybe the 5.x release CD's should include: GENERIC GENERIC +SMP GENERIC +VMWARE-friendly settings GENERIC for i386 Would that add too much extra work for a 5.x release? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
Garance A Drosihn wrote: At 1:27 PM +0200 2/27/03, Ruslan Ermilov wrote: : RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v : Working file: GENERIC : description: : : revision 1.296 : date: 2001/01/14 10:11:10; author: jhb; state: Exp; lines: +2 -2 : : Remove I386_CPU from GENERIC. Support for the 386 seriously : pessimizes performance on other x86 processors. Custom kernels : can still be built that will run on the 386. While there was good reason for removing i386 from GENERIC, that does mean that someone just wanting to try freebsd on a i386 may very well give up before realizing that it does (hopefully!) work. For official release CDs, should we also provide a GENERIC_I386 kernel, so the person can get up-and-running without having to first build a new kernel? Or will they just run into other problems once they get past the kernel, due to everything else in the system being compiled for i486 newer? I think we (developers) get a little too used to having multiple machines around, and assume that everyone who might want to test freebsd will have some hardware that works for the GENERIC kernel, and which they can use to first do a buildkernel for the hardware they really want to test freebsd on. I'm thinking maybe the 5.x release CD's should include: GENERIC GENERIC +SMP GENERIC +VMWARE-friendly settings GENERIC for i386 Would that add too much extra work for a 5.x release? I'd be happy to add this kind of stuff to 5.x, but the real hurdle is doing the work to make it happen. It would be nice to be able to select the kernel that you want from the bootloader of the CD, though this probably isn't terribly important. I doubt that many i386-vintage systems understand non-emulated El Torito, so you'd have to roll install floppies also. Another idea for a 'custom GENERIC' is a 'low memory/i386' version that removes all of the PCI devices and other things not likely to run or exist on an i386. Anyways, patches are welcome! Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, 27 Feb 2003, Garance A Drosihn wrote: I'm thinking maybe the 5.x release CD's should include: GENERIC GENERIC +SMP GENERIC +VMWARE-friendly settings GENERIC for i386 GENERIC OLDCARD -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On 27-Feb-2003 Garance A Drosihn wrote: At 1:27 PM +0200 2/27/03, Ruslan Ermilov wrote: : RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v : Working file: GENERIC : description: : : revision 1.296 : date: 2001/01/14 10:11:10; author: jhb; state: Exp; lines: +2 -2 : : Remove I386_CPU from GENERIC. Support for the 386 seriously : pessimizes performance on other x86 processors. Custom kernels : can still be built that will run on the 386. While there was good reason for removing i386 from GENERIC, that does mean that someone just wanting to try freebsd on a i386 may very well give up before realizing that it does (hopefully!) work. For official release CDs, should we also provide a GENERIC_I386 kernel, so the person can get up-and-running without having to first build a new kernel? Or will they just run into other problems once they get past the kernel, due to everything else in the system being compiled for i486 newer? I think we (developers) get a little too used to having multiple machines around, and assume that everyone who might want to test freebsd will have some hardware that works for the GENERIC kernel, and which they can use to first do a buildkernel for the hardware they really want to test freebsd on. I'm thinking maybe the 5.x release CD's should include: GENERIC GENERIC +SMP I plan to make SMP kernels work on a UP machine like they do on all of our other platforms thus obsoleting the need for this. GENERIC +VMWARE-friendly settings This might be useful. GENERIC for i386 I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People wouldn't have noticed if phk@ hadn't asked for a volunteer either. I386_CPU kernel compiles have been broken in the past for rather long periods of time before being noticed as well. Would that add too much extra work for a 5.x release? You have access to the source, go for it. :) With cdboot, all you need to do is create a /boot/vmware/ directory with kernel (and maybe modules) in the ISO image and the user can break into the loader and type 'boot vmware' to boot it. src/release/* awaits your tested patches. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
At 4:04 PM -0500 2/27/03, John Baldwin wrote: On 27-Feb-2003 Garance A Drosihn wrote: I'm thinking maybe the 5.x release CD's should include: GENERIC GENERIC +SMP I plan to make SMP kernels work on a UP machine like they do on all of our other platforms thus obsoleting the need for this. Ooo. This will be highly appreciated for my collection of SMP boxes! GENERIC +VMWARE-friendly settings This might be useful. GENERIC for i386 I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People wouldn't have noticed if phk@ hadn't asked for a volunteer either. I386_CPU kernel compiles have been broken in the past for rather long periods of time before being noticed as well. Well, doesn't that suggest that it would be GOOD if the release process itself had to build a GENERIC_I386 kernel? Would that add too much extra work for a 5.x release? You have access to the source, go for it. :) With cdboot, all you need to do is create a /boot/vmware/ directory with kernel (and maybe modules) in the ISO image and the user can break into the loader and type 'boot vmware' to boot it. src/release/* awaits your tested patches. Hmm. Well, right now I'm busy trying to make newsyslog more admin-friendly, but I'll keep this pointer in mind. Thanks. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
John Baldwin wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People who build embedded devices that need to be supported in the field, and want to worry about their software, and not the platform it runs on, don't use -current, FWIW. In fact, no one is likely going to, until it goes -stable. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On 27-Feb-2003 Garance A Drosihn wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People wouldn't have noticed if phk@ hadn't asked for a volunteer either. I386_CPU kernel compiles have been broken in the past for rather long periods of time before being noticed as well. Well, doesn't that suggest that it would be GOOD if the release process itself had to build a GENERIC_I386 kernel? It points out that no one uses I386 kernels. Is it more valuable to have GENERIC_I386 or KDE on disc 1? If it came down to that I would pick KDE. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On 27-Feb-2003 Terry Lambert wrote: John Baldwin wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People who build embedded devices that need to be supported in the field, and want to worry about their software, and not the platform it runs on, don't use -current, FWIW. In fact, no one is likely going to, until it goes -stable. We sure are using -stable where I work. :) Granted, we aren't using 80386's either. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
Thus spake Terry Lambert [EMAIL PROTECTED]: John Baldwin wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People who build embedded devices that need to be supported in the field, and want to worry about their software, and not the platform it runs on, don't use -current, FWIW. Moot point. People who build embedded devices have separate, usually modern, machines for building their kernels. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, Feb 27, 2003 at 05:29:53PM -0500, Garance A Drosihn wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People wouldn't have noticed if phk@ hadn't asked for a volunteer either. I386_CPU kernel compiles have been broken in the past for rather long periods of time before being noticed as well. Well, doesn't that suggest that it would be GOOD if the release process itself had to build a GENERIC_I386 kernel? It's never good to add to your release cycle something you don't build/validate during development. Releases are painful enough that you don't want to turn them into testbeds. If it's not worth testing during development, it's not worth releasing... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
David Schultz wrote: Thus spake Terry Lambert [EMAIL PROTECTED]: John Baldwin wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People who build embedded devices that need to be supported in the field, and want to worry about their software, and not the platform it runs on, don't use -current, FWIW. Moot point. People who build embedded devices have separate, usually modern, machines for building their kernels. They also outsource their hardware, and have to provide a golden master CDROM. Internally, they also tend to want a build environment that is the same as the environment on their target platform, which they then use for cross-building on those separate, usually modern, machines. What that boils down to is that you build a CDROM as if you were going to install on the target machine with a CDROM drive, even if the thing doesn't have a CDROM drive. Likewise, when you have a room full of appliance boxes that are rack-mounted, and have serial consoles, no CDROM, no floppy, or other removable media, the normal way you use to install an image is to boot up the current image, copy over the sysinstall from an already installed bootstrap system with a CDROM drive, and then NFS mount the CDROM, and run the sysinstall from the serial console, and lie and tell it the thing was mounted locally. This isn't like a build-out at an ISP or hosting company, where you can PXE everything because you're never going to ship anything to a customer site, so it's OK if some machine reboots, gets your boot server, and installs a new image (a disaster, if it happened to a closed box shipped to a customer site!). If you've never built a closed-box appliance, then you are probably not familiar with the operational differences you have to live with, compared to something like Yahoo or RackSpace, etc.. BTW: I would say the vast majority of FreeBSD installations are in open-box places like Yahoo, RackSpace, etc., where the boxes are all cloned out from a template, and never leave the premises or end up under the physical control of an end user. BUT... I would say that the *second-most* numerous set of FreeBSD installs is in closed-box systems from companies like Whistle, IBM, ClickArray, NetScaler, etc., who are building appliances (makes me wonder how many Soekris boxes are out there running FreeBSD). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
drosih GENERIC +VMWARE-friendly settings It'll be unneeded for further VMware releases. At least, very recent 5-current runs quite fine on my VMware 4 beta. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, 27 Feb 2003, Garance A Drosihn wrote: At 4:04 PM -0500 2/27/03, John Baldwin wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. People wouldn't have noticed if phk@ hadn't asked for a volunteer either. I386_CPU kernel compiles have been broken in the past for rather long periods of time before being noticed as well. Well, doesn't that suggest that it would be GOOD if the release process itself had to build a GENERIC_I386 kernel? Pardon my butting in here but I thought the point of the exercise was to see if it could be done, and if not, where and why did it fail. The itty bit that including I386 in the kernel made it a pig on pentiums makes sense to drop that support. For posterity sake, including support seems a fun bit, but that is it. 386en are for the most part doorstops (although I'm aware of a few running 4.x in production environments doing routing). The manufacture date on my cpu is 1985. Hunh? There has been a great deal of sweat and grovelling over what to include in floppy boot disks to do ftp installs. To make it include support for vintage hardware would blow out the number of boot floppies to what? Maybe five? Then we have to consider the number of volunteer hours to make it happen? Then the increased labour load of those that take responsibility for those who make it happen(tm). Bloat seems to be coming from all sides on this one. Sorry. It can be a tight ship, or a leaky boat from stressed internals. I don't like the latter but am more than happy to participate as long as it is a manageable exercise. I hope we consider it thus as long as any work remains (relatively) trivial (and my apologies to those who have already expended too much on this exercise - phk himself comes to mind). I'm going ahead with trying to cvsup and build from source anyway just because I think this is a fun exercise. 4.7 seemed fine but pkg_add didn't appear to work so grabbed the entire ports tree today and for the past six hours have been building cvsup-without-gui (in fairness. it wasn't pkg_add, but the index file was seen as corrupted by the machine - so it sat there stymied - I believe there has been a post to stabel regarding this today). What I see as concerns if FreeBSD really wants to do this include resurrecting the config utility from 4.x. Even if 5.0 booted from floppy, I was betting it wouldn't find my ISA nic (a de220 that won't use 0x280 for IO though it uses ed for the driver). Installing 4.7 and cvsupping made more sense, but I was willing to give it a spin. Then we have dropped support due to how including 386 kernel support made it a pig with pentiums. Then the ongoing debates on what support to and what not to include in floppies because we want to (try) to keep the number of floppies down. Then we have to consider the amount of memory available on 386en to unpack the above (I hope I'm shining here with 32 MB - a very high number for that vintage hw - all on perfectly matched sticks - my experience is this a a rarity). Then we have to consider the number of functioning 386 boards whose bios survived y2k rollover and of those, how many haven't toasted. More and more, this seems like a NetBSD niche. That said, I don't like ipf and NetBSD doesn't do ipfw. I'd prefer to skip the cultural debate thankyou. Also, I'm on current-, stable-, cvs-all and the security lists. No need to include me on the to: line. Thankyou all for your interest and appreciation in making this the world's finest (IMHO) operating system. Please, let's keep it that way before chasing bragging rights to tedia like what it will boot on outside the core market (and I would be happy to see the heart of that core restricted to hw built since the 386 should porting 386 be non-trivial). I'm going ahead with testing anyway and am happy to share my experience. Thakyou all. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
At 3:55 PM -0800 2/27/03, Marcel Moolenaar wrote: On Thu, Feb 27, 2003, Garance A Drosihn wrote: ... JMB wrote: I doubt the usefulness of this. i386 kernels were just accidentally broken for almost a month and a half without anyone noticing. Well, doesn't that suggest that it would be GOOD if the release process itself had to build a GENERIC_I386 kernel? It's never good to add to your release cycle something you don't build/validate during development. Releases are painful enough that you don't want to turn them into testbeds. If it's not worth testing during development, it's not worth releasing... Okay, that also makes good sense. But if that is true, then maybe we should officially tell our users that they *must* stay with the 4.x-series if they are running 386 hardware. I do think that the project has plenty of work with 5.x-series, particularly as we try to add sparc64, ppc, and maybe more hardware platforms. We do have a lot to test already, and there is no sense pretending to support i386 when we don't have the resources or the inclination to really test it. I think we're hitting that grey area where we do not really support i386, but for pride's sake we don't quite want to admit that 5.x will not support it. Perhaps we should start calling it freebsd/i486 instead of i386. I am not quite sure how my comments sound here, so let me just say that I do not mean to be sarcastic in any way. I'm just saying that for the benefit of freebsd's users, we probably need to make a clear statement that 5.x is not appropriate for true 80386 chips. We do have every intention of keeping 4.x actively improving for at least another year, and I think the 386-embedded users would be happier if they stay with that and did not waste time trying 5.x. I also imagine that developers will be happier applying important fixes to 4.x (for the 386 users), than fielding complaints on 5.x about how the kernel broke for 386-ers. That's just my 2 cents though. Any decision that makes sense to kernel developers and release engineers is fine by me. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
At 9:38 PM -0500 2003/02/27, Garance A Drosihn wrote: It's never good to add to your release cycle something you don't build/validate during development. Releases are painful enough that you don't want to turn them into testbeds. If it's not worth testing during development, it's not worth releasing... Okay, that also makes good sense. But if that is true, then maybe we should officially tell our users that they *must* stay with the 4.x-series if they are running 386 hardware. I do think that the project has plenty of work with 5.x-series, particularly as we try to add sparc64, ppc, and maybe more hardware platforms. I disagree. We should tell them that 5.x may technically run on i386 systems, but that it is optimized for i486 and above, and that if they want to get it to run on i386 machines there is a significant amount of additional work that they would need to go through in order to make it happen. We can go so far as to tell them that using 5.x on i386 hardware is unsupported, and if they have any problems they shouldn't bother reporting them to us. However, I would encourage people to do further testing of 5.x on i386 systems and try to keep it working, and I would be very disappointed if anyone made any proclamations that people *MUST* stick with 4.x (or earlier) if they're using i386 systems. If you're going to go that route, then make sure to actually remove all the i386 code from 5.x so that it simply is no longer possible to make it work at all. Actually, this might be a good exercise anyway, to help teach us just what parts can be disentangled and what parts would need to be watched more closely. But don't tell people that they *MUST* stick with 4.x on i386, unless you physically remove all the i386 code from the 5.x tree. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, Feb 27, 2003 at 09:38:18PM -0500, Garance A Drosihn wrote: Okay, that also makes good sense. But if that is true, then maybe we should officially tell our users that they *must* stay with the 4.x-series if they are running 386 hardware. Something like that, yes. I think the important part is setting expectations right. People should not expect 5.x to run on 80386, so that casual users don't waste their time. People who really know what they are doing can probably get it to work and I think that fixes, within reason, are acceptable as well... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, 27 Feb 2003, John Baldwin wrote: It points out that no one uses I386 kernels. Is it more valuable to have GENERIC_I386 or KDE on disc 1? If it came down to that I would pick KDE. This is getting silly. As much respect as I have for you, KDE is not and shouldn't be part of this OS. Should Gnome be on the first disc too then? What about Windowmaker or fvwm? I was evidently under the mistaken impression this was about nuts and bolts. If we are to focus on window dressing, we are definitely hozed. Cheers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, 27 Feb 2003 23:09:56 -0500 (EST), Geoffrey [EMAIL PROTECTED] said: I was evidently under the mistaken impression this was about nuts and bolts. If we are to focus on window dressing, we are definitely hozed. We focus on what's actually useful to the plurality of users. Support for a processor that was functionally obsolete ten years ago is not it. (If you want NetBSD, you know where to find it.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Thu, Feb 27, 2003 at 11:14:46PM -0500, Garrett Wollman wrote: On Thu, 27 Feb 2003 23:09:56 -0500 (EST), Geoffrey [EMAIL PROTECTED] said: I was evidently under the mistaken impression this was about nuts and bolts. If we are to focus on window dressing, we are definitely hozed. We focus on what's actually useful to the plurality of users. Support for a processor that was functionally obsolete ten years ago is not it. (If you want NetBSD, you know where to find it.) Amen. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message: [EMAIL PROTECTED] Garance A Drosihn [EMAIL PROTECTED] writes: : I'm thinking maybe the 5.x release CD's should include: : GENERIC : GENERIC +SMP : GENERIC +VMWARE-friendly settings : GENERIC for i386 : : Would that add too much extra work for a 5.x release? Not to start *that* bikeshed again, but even if you had a GENERIC for i386, sysinstall is too pigdogish to have any hope of running on the memory that one finds on a real 386. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any ideas why we can't even boot a i386 ?
In message: [EMAIL PROTECTED] Matthew N. Dodd [EMAIL PROTECTED] writes: : On Thu, 27 Feb 2003, Garance A Drosihn wrote: : I'm thinking maybe the 5.x release CD's should include: : GENERIC : GENERIC +SMP : GENERIC +VMWARE-friendly settings : GENERIC for i386 : : GENERIC OLDCARD No. We should get the stupid newcard author to finish up pcic for newcard. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
