Re: KSE kernel comparissons
On Sun, 26 Aug 2001, Julian Elischer wrote: Comparative times for 'make buildworld' for unmodified and KSE (milestone-2) kernels unmodified -current 2138.464u 3358.378s 1:37:39.77 93.8%842+1080k 45105+176988io 3208pf+0w modified KSE kernel 2143.716u 3363.311s 1:37:50.33 93.8%841+1081k 45435+176988io 3214pf+0w I'm very glad to see that the overhead added was not too great. (well within the margin of error I'm sure) Since it is non-negative, why would anyone want it? However, the benchmark seems to be flawed. Buildworld's system time should be only about 20% of its user time. To pessimize it by a factor of 7.5, you need to turn on lots of debugging options (which are on by default in -current). More actual code will be needed to get away from 1:1, so this is just a baseline. the next steps are for us a s a groupt to decide if this is really the way we want to go, and if so, whether we want to commit these changes to make them available for the world to work on as a base for real threading support. The alternative is to do linux-type threading with processes (peter wemm has been investigating a variant on this scheme). This is probably a no-turning-back commit. How much faster (or slower) will it be for threaded programs (for various numbers of CPUs)? I don't see how it can be faster for a single CPU (interrupt threads in the kernel show that using threads tends to pessimize both efficiency and latency for a single CPU). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. I would ask that we get some indication from the IA64/Alpha/etc folks about this *before* you commit, even if they're not ready with patches yet, it would be wise to know how long before they would be. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
It seems Julian Elischer wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. Could we have an URL to these changes, so we could see what its all about, I dont like to comment on code before I've seen it -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in libssh on -CURRENT
On Sun, Aug 26, 2001 at 10:31:59PM -0700, Andrei Popov wrote: === libssh make: don't know how to make dsa.c. Stop *** Error code 2 Something is wrong with your source..perhaps you didn't update it completely. Kris PGP signature
UFS issue in -current? Plus good news for tape users...
FreeBSD wahoo.kc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #26: Sat Aug 25 02:25:41 CDT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WAHOO i386 1). I shut down properly [shutdown -r now] about an hour ago to boot into winblowz [yeah, but it's the only thing morpheus works in]... 2). When I came up I had a message saying that I had to run fsck manualy... okay... 3). I found that /var [ad0s1f] had a mismatch between the superblock and the first alternate, and it also complained about an invalid label... As far as I know the shutdown went proper... Anyone else seeing this? /var is softupdates flagged... The good news is that Justin's scsi_sa.c patches DO WORK! Once I figured there was nothing that fsck could do for me, I did a newfs /dev/ad0s1f, then mounted it and did a restore of /var from tape. Outside of losing a day's worth of logs, I'm fine now, but the question is: why did it happen? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl5 build is poo
On Thu, 23 Aug 2001, David O'Brien wrote: On a -current Alpha box I cannot: cd /usr/src/gnu/usr.bin/perl make cleandir make cleandir make obj make depend ... === perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) miniperl:No such file or directory *** Error code 1 Why isn't miniperl in /usr/src/gnu/usr.bin/perl/Makefile ? It's because people didn't want to face the cross-compilation issues. I don't know of any reason why miniperl can't be built as a build-tool, but haven't tested this. I work around this bug by building miniperl manually and copying it to /usr/bin Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current broken in pcic_pci.c
Hi, Version 1.83 of that file breaks the GENERIC build. You probably meant to write: Index: pcic_pci.c === RCS file: /usr/ncvs/src/sys/pccard/pcic_pci.c,v retrieving revision 1.83 diff -r1.83 pcic_pci.c 262c262 if (sc-csc_intr == pcic_iw_pci || sc-func_intr == pcic_iw_pci) --- if (sc-csc_route == pcic_iw_pci || sc-func_route == pcic_iw_pci) harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Today's current has problems authenticating imap.
After a successful make world and kernel this morning, I am having a problem with ld-elf.so.1/pam/imap. Everytime someone tries to login to imap the following error is generated. Aug 27 09:20:17 aNeed2Learn /usr/libexec/ld-elf.so.1: Aug 27 09:20:17 aNeed2Learn /usr/lib/pam_nologin.so: Undefined symbol login_getclass Any ideas for a quick fix? Would the old ld-elf.so.1 work with the changes that have caused this? Thanks, ed --- The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn. --Alvin Toffler To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fxp SCB timeout problems [FIX]
Its looking great so far! In the two production machines I put it in last night, zero time outs as expected!! These are both EM machines. On my two internal ET machines, also zero problems. The machines are in 10BaseT/UTP, and 10BaseT full duplex. inphy0: i82562EM 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto and fxp0: Intel Pro/100 Ethernet port 0xdf00-0xdf3f mem 0xff6ff000-0xff6f irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:6f:f7:e0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Thank you *VERY* much for fixing this problem. ---Mike At 01:43 PM 8/26/01 -0400, Mike Tancsa wrote: I have it on two machines with this chipset and it looks good so far. After installing, dmesg shows fxp0: Intel Pro/100 Ethernet port 0xc400-0xc43f mem 0xd5001000-0xd5001fff irq 11 at device 8.0 on pci1 fxp0: *** DISABLING DYNAMIC STANDBY MODE IN EEPROM *** fxp0: New EEPROM ID: 0x49a0 fxp0: EEPROM checksum @ 0xff: 0xe441 - 0xe443 fxp0: *** PLEASE REBOOT THE SYSTEM NOW FOR CORRECT OPERATION *** fxp0: Ethernet address 00:01:80:02:d0:34 inphy0: i82562EM 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto and then one more reboot shows fxp0: Intel Pro/100 Ethernet port 0xc400-0xc43f mem 0xd5001000-0xd5001fff irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:01:80:02:d0:34 inphy0: i82562EM 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ---Mike At 10:11 AM 8/26/2001 -0500, Jonathan Lemon wrote: I believe that I have a real fix for the SCB timeout problems that have been plauging users of recent Intel fxp boards. If you have a board that uses the Intel ICH2/ICH2-M chipset (usually 815E style boards) and feel comfortable applying patches to the system, please contact me to test a fix. The patch works on two different boards here, but I would like to get some wider testing before I commit it to the tree. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message Mike Tancsa, tel +1 519 651 3400 Network Administration, [EMAIL PROTECTED] Sentex Communications www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current broken in pcic_pci.c
In message [EMAIL PROTECTED] Harti Brandt writes: : Version 1.83 of that file breaks the GENERIC build. You probably meant to : write: Just fixed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why is csh tcsh? This can be a bad thing...
On 26-Aug-01 Kris Kennaway wrote: On Sun, Aug 26, 2001 at 01:20:23PM +0200, Oliver Fromme wrote: Our csh still behaves differently like any /bin/csh on any other system that I know, and can't be easily made to behave like them. This is an assertion. Where is your supporting evidence? In his previous message that you didn't read. Geez, I'm a tcsh user myself but his point is not all that obscure. He mentioned wanting Esc to do instant filename completion. (Or history, can't remember which). Another one he referred to is clearly documented in the tcsh manpage that no one seems to read: (+) While csh(1) expands, for example, `!3d' to event 3 with the letter `d' appended to it, tcsh expands it to the last event beginning with `3d'; only completely numeric arguments are treated as event numbers. This makes it possible to recall events beginning with numbers. To expand `!3d' as in csh(1) say `!\3d'. IOW, to obtain backward compatibility, you have to change your input. That's not really all that backward compatible since the original interface is broken. I agree with Andrey that getting the tcsh maintainers to provide backwards compatibility via a command-line option (or have it triggered when it is called as csh rather than tcsh) would be the ideal solution. Kris -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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
make world broken in -current
Compiling sources cvs'ed this morning (Aug 27th), I get this error: cd /auto/roy/dist/pub/FreeBSD/CURRENT/src/usr.bin/file; make build-tools make: don't know how to make build-tools. Stop *** Error code 2 Stop in /auto/roy/dist/pub/FreeBSD/CURRENT/src. *** Error code 1 - JimP To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
In message [EMAIL PROTECTED], Julian Elischer writes: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! I say No, not yet. Not yet, because in practice nobody has been running your patches yet. Not yet, because we have seen no quantified performance impact numbers (yes, I'm trying to arrange to help you produce these but on a P5/133 things are _S_L_O_W_! Not yet, because I seriously doubt if anybody has had any time to review and reflect on the way you have gone around and done things. Not yet, because there are, as I understand it, unresolved issues with KAME. Not yet, because you are generalizing from only one platform, get at least alpha working first. So I propose: Put up your patches in a highly visible place and advertise them on -current, -arch and -smp. Once at least 5 developers have publically said I'm running these patches on my -current machine(s) and it doesn't totally hose me and at least 3 of those machines are SMP and one is non-i386 architecture, then call for last orders before commit. -- 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: md.c broken in current
From sources this morning when trying to build a kernel: (pro2)502}make cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../../dev/md/md.c ../../../dev/md/md.c: In function `mddetach': ../../../dev/md/md.c:814: `MD_PRELOAD_COMPRESSED' undeclared (first use in this function) ../../../dev/md/md.c:814: (Each undeclared identifier is reported only once ../../../dev/md/md.c:814: for each function it appears in.) *** Error code 1 OOPS, sorry, it seems that I broke it. Should be fixed in rev.1.44. Thank you for pointing out! -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE kernel comparissons
On Mon, 27 Aug 2001, Bruce Evans wrote: How much faster (or slower) will it be for threaded programs (for various numbers of CPUs)? I don't see how it can be faster for a single CPU (interrupt threads in the kernel show that using threads tends to pessimize both efficiency and latency for a single CPU). Note that we won't be able to see some of the impactmpacted until SMPng is further along, where KSE will pessimize a number of single-thread operations. For example, right now SMPng proc locking relies on certain proc structure entries being changed only by curproc, meaning that locks are held for reading only by other processes. With KSE, we'll need to actually hold real locks when acting on those curproc entries (in particular, reads) which may impose a substantial performance overhead. I would anticipate that a number of the other potential shortcuts in SMPng would be similarly impacted by KSE. However, since SMPng is very much a work in progress right now, that's not something I think we can quantify yet. This general issue does raise a lot of concerns however -- many locking assumptions in SMPng will need to be changed, and the locking will need to be much more thorough before we can move forward. Even pre-SMPng, we've had race issues relating to unexpected sleeps, this will only get more hairy (although architecturally better) with SMPng. I'm worried that throwing KSE into the mix is going to hurt a lot. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Julian Elischer writes: Can the IA64 and Alpha developers (Arm too?) look at the KSE patch set at http://www.freebsd.org/~julian/thediff This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) so that when this is checked into -current their architectures are not broken. (On teh other hand if they would rather fix up the breakage afterwards (which may be easier) then they should let me know so I can get on with committing it. Matt and I want to commit it ASAP, so we can get on with actual threading support. Peter has also indicated that he thinks that it should be done soon, so I need toknow if there will be forthcoming changes for the other architectures, or I should go ahead and commit... Please, please don't intentionally break other architectures. Esp ones that actually work, like alpha. Its basically just mechanical changes up until this point, right? You've carved up the proc struct ranamed some things, right? I'd really appreciate it if you could make the mechanical changes required to get it to the point where it at least compiles on alpha using beast.freebsd.org. At that point, the people on -alpha should be willing to test your patch and help fix any problems that come up. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Headsup! KSE Nay-sayers speak up!
On Mon, 27 Aug 2001, Garrett Wollman wrote: On Mon, 27 Aug 2001 09:34:06 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I agree. I'd like to see this stuff happen, but I think it's too disruptive a change while we still haven't yet gotten over many of the SMPng issues yet. Sorry to butt in on this conversation here, but wasn't one of the main points of 5.0 and SMPng to bring KSE's into FreeBSD? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Mon, 27 Aug 2001, Poul-Henning Kamp wrote: (phk-isms) I found Poul-Henning's comments struck a chord with me. I agree with his comments that a commit at this point would be premature, and that more review is required. In particular, it seems like his observation that we need additional eyes and hands involved, which will give us more perspective on the work. This would probably be a good opportunity for those relying on Julian to do all the work to look at what he's done, and better yet, run it :-) Before we can make the hard choice, we need more information, and not surprisingly, that's going to require some investment. I think it's definitely an investment worth making, as KSE offers a great deal of promise. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
How about this . . . Although not running a multi-processor machine, are there guinnea-pigs, like me, who run current and do not mind carrying Julians work in our kernel. As I understand there is no set time-line for SMPng integration, is there ? I would not mind running KSE, and that only on a i686 laptop. Let's call for an interest list. +1 me My main interest is getting the Java Native threads port moving forward, beco- ming rock-solid. Ciao, derweil. -- Carlo In message [EMAIL PROTECTED], Julian Elischer writes: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! I say No, not yet. Not yet, because in practice nobody has been running your patches yet. Not yet, because we have seen no quantified performance impact numbers (yes, I'm trying to arrange to help you produce these but on a P5/133 things are _S_L_O_W_! Not yet, because I seriously doubt if anybody has had any time to review and reflect on the way you have gone around and done things. Not yet, because there are, as I understand it, unresolved issues with KAME. Not yet, because you are generalizing from only one platform, get at least alpha working first. So I propose: Put up your patches in a highly visible place and advertise them on -current, -arch and -smp. Once at least 5 developers have publically said I'm running these patches on my -current machine(s) and it doesn't totally hose me and at least 3 of those machines are SMP and one is non-i386 architecture, then call for last orders before commit. -- 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 -- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia Comment: requires PGP version 2.6 or later mQENAzQOnboAAAEIALnpSTc5y2g21CIX5V9bMqxsixXpQZDyR3hGosGsPC8S0WXP xfJiXAw/Zq3sPZhmiGZWq8/QP/d69tm4ert6rGB5Vuue96beKei4iemBF1ZpTU9G 3/tLsL63GHTLDAf+jqNcp1xM5ORF+qkFqP1ForzED06ba7HPQomzD0uhPbczHr9p vLAsczg1Wm9op06m7VTgK/hEvOJZPdxu0i2mFC2KVmRJr/KLcjs4CyEt6S8cJk8F Q3vDOOvwa+j/AHkvejBYokNYbfA+5D6bbYmNl5GxsKmY/qxamEaPWy7lZ87v8J0E CwnfzxiFPlguHCAux3u388EWqGWyAqOeROtKqL0ABRG0JkNhcmxvIERhcG9yIDxk YXBvckBuZXNzaWUuaW5mLmV0aHouY2g+iQEVAwUQNA6dugKjnkTrSqi9AQH3kAf/ T7dFJl6YQbUKSwTxNX/rERk2W010j2fH1bkbgOOfEfvQ6LiIRJYmJQCgeehP8kEU V66vSPboGsjl+8wU5CdlmoPsf7xw94Dh+uI48/CKLFAu+Rq2lonQOuzSvEDGg1P0 pU4UyCdj5i+y89jS+wBNA/yG6wsEGWMVltWqB2UKSg1n3YbA8JqaO2x9JLtIzfoB J/jhl5Jl4kX8OJzX1XVlJTxYdu9PTwaTZP68EG6NNfEyCn5Fp6iSDtUrLms1pI5i 3U282bIhBgVXr19hVS2olqTUHGdgcRqFjcnrARIBKoB9stuKj1+ORqlDiLwJfvg5 6JNSM4HFutk/iftKBqYXhQ== =XYxp -END PGP PUBLIC KEY BLOCK- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
* Carlo Dapor [EMAIL PROTECTED] [010827 13:49] wrote: How about this . . . Although not running a multi-processor machine, are there guinnea-pigs, like me, who run current and do not mind carrying Julians work in our kernel. As I understand there is no set time-line for SMPng integration, is there ? I would not mind running KSE, and that only on a i686 laptop. Let's call for an interest list. +1 me My main interest is getting the Java Native threads port moving forward, beco- ming rock-solid. I'd also like to see the delta committed asap. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
One thing I forgot, sorry. If there is a considerable amount of people, i would appreciate it if we get the 'common' commits that go to current filtered through p4 in some way. I would dislike it to have to resort to editing every single delta . . . Ciao, derweil. -- Carlo How about this . . . Although not running a multi-processor machine, are there guinnea-pigs, like me, who run current and do not mind carrying Julians work in our kernel. As I understand there is no set time-line for SMPng integration, is there ? I would not mind running KSE, and that only on a i686 laptop. Let's call for an interest list. +1 me My main interest is getting the Java Native threads port moving forward, beco- ming rock-solid. Ciao, derweil. -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Headsup! KSE Nay-sayers speak up!
On 27-Aug-01 Julian Elischer wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I know that I am in the minority on this, but wanted to say it anyways. It doesn't mean I don't like the KSE work or anything like that (I've even helped out on it some), I just think we have enough work in our basket. Also, I'll point out that p4's merging abilities make tracking current relatively easy, much more so than if Julian was maintaining a separate tree with this patch and having to keep updating current and manually merge it all the time. /stump -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: KSE kernel comparissons
On Mon, 27 Aug 2001, Robert Watson wrote: On Mon, 27 Aug 2001, Bruce Evans wrote: How much faster (or slower) will it be for threaded programs (for various numbers of CPUs)? I don't see how it can be faster for a single CPU (interrupt threads in the kernel show that using threads tends to pessimize both efficiency and latency for a single CPU). Note that we won't be able to see some of the impactmpacted until SMPng is further along, where KSE will pessimize a number of single-thread operations. For example, right now SMPng proc locking relies on certain proc structure entries being changed only by curproc, meaning that locks are held for reading only by other processes. With KSE, we'll need to actually hold real locks when acting on those curproc entries (in particular, reads) which may impose a substantial performance overhead. I would anticipate that a number of the other potential shortcuts in SMPng would be similarly impacted by KSE. However, since SMPng is very much a work in progress right now, that's not something I think we can quantify yet. This general issue does raise a lot of concerns however -- many locking assumptions in SMPng will need to be changed, and the locking will need to be much more thorough before we can move forward. Even pre-SMPng, we've had race issues relating to unexpected sleeps, this will only get more hairy (although architecturally better) with SMPng. I'm worried that throwing KSE into the mix is going to hurt a lot. I'm not sure I understand completely. Our current process lock is still the same, especially since everything is single KSE'd (threaded) unless explicitly enabled. As long as we don't try to push down the process lock any further (for now) into the KSE structures, what's the difference? This will get the code into the base kernel and make those doing the locking aware of what will be needed in the future. You don't have to change process locking until you're ready to. I don't even care right now whether we can have multiple KSEs or KSE Groups. Just a single KSE is enough for us to start. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
Mike Smith wrote: I would ask that we get some indication from the IA64/Alpha/etc folks about this *before* you commit, even if they're not ready with patches yet, it would be wise to know how long before they would be. see the other email discussing exactly this -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Headsup! KSE Nay-sayers speak up!
On Mon, 27 Aug 2001, John Baldwin wrote: On 27-Aug-01 Julian Elischer wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I know that I am in the minority on this, but wanted to say it anyways. It doesn't mean I don't like the KSE work or anything like that (I've even helped out on it some), I just think we have enough work in our basket. Also, I'll point out that p4's merging abilities make tracking current relatively easy, much more so than if Julian was maintaining a separate tree with this patch and having to keep updating current and manually merge it all the time. I think waiting for 6.0-current is too long. Perhaps after 5.0-release. If we get this in 5.0, we might be able to have a usable kse threads library for 5.1 or 5.2. I've used p4 to track the CAM changes before they were in -current. It was initially easy when only the kernel was involved, but once userland was was touched I ended up having to use p4 to track everything else. At the time I didn't have enough disk space to have both a CVS src/ tree and a p4 tree. Plus it's difficult when you have more than one development system because you can't just keep one CVS repo and update all your systems from that. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
md.c broken in current
From sources this morning when trying to build a kernel: (pro2)502}make cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../../dev/md/md.c ../../../dev/md/md.c: In function `mddetach': ../../../dev/md/md.c:814: `MD_PRELOAD_COMPRESSED' undeclared (first use in this function) ../../../dev/md/md.c:814: (Each undeclared identifier is reported only once ../../../dev/md/md.c:814: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/i386/compile/pro2. (pro2)503} Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
John Baldwin wrote: On 27-Aug-01 Julian Elischer wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I know that I am in the minority on this, but wanted to say it anyways. It doesn't mean I don't like the KSE work or anything like that (I've even helped out on it some), I just think we have enough work in our basket. Also, I'll point out that p4's merging abilities make tracking current relatively easy, much more so than if Julian was maintaining a separate tree with this patch and having to keep updating current and manually merge it all the time. /stump well I expected this to some extent.. This is why I asked.. I want to get it out where it can be discussed. the same could also be said for full pre-emption and SMP-NG. It is also interestingto note that KSE isn't the only game in town. The new PTNG package looks interesting, using normal process rforking to generate a pthreads environment. (It's a rewrite, not a port of linux threads). All I have done is brought the kernel to a state where it is READY for work to break the 1:1 barrier. It is basically logically exactly the same kernel as in -current. I think it introduces far fewer logical changes than, say, the pre-emption code, or the locking code. I agree that we could wait. I don't however think we should. I'd rather have ONE broken period than two. At USENIX we agreed that if I got this done it would be committed and work could start to provide the facilities that Dan and Chris need for the Userland code to develop. Remember, that unless you turn this on, it's a very complicated NOP. What P4 does is really irrelevent because there are only 4 people using it.. (or is that 3?). It needs a distribution channel, and P4 isn't it. (at least not at the moment.) What it DOES do however is make your locking code more challenging. But that is going to have to be faced at some time -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Headsup! KSE Nay-sayers speak up!
On Mon, 27 Aug 2001 09:34:06 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I agree. I'd like to see this stuff happen, but I think it's too disruptive a change while we still haven't yet gotten over many of the SMPng issues yet. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Headsup! KSE Nay-sayers speak up!
On 27-Aug-01 Daniel Eischen wrote: On Mon, 27 Aug 2001, John Baldwin wrote: On 27-Aug-01 Julian Elischer wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I know that I am in the minority on this, but wanted to say it anyways. It doesn't mean I don't like the KSE work or anything like that (I've even helped out on it some), I just think we have enough work in our basket. Also, I'll point out that p4's merging abilities make tracking current relatively easy, much more so than if Julian was maintaining a separate tree with this patch and having to keep updating current and manually merge it all the time. I think waiting for 6.0-current is too long. Perhaps after 5.0-release. If we get this in 5.0, we might be able to have a usable kse threads library for 5.1 or 5.2. I'm predicting a short release cycle between 5.0 and 6.0 (compared to 4.0 and 5.0) because 6.0 is probably going to be much more stable than 5.x. I've used p4 to track the CAM changes before they were in -current. It was initially easy when only the kernel was involved, but once userland was was touched I ended up having to use p4 to track everything else. At the time I didn't have enough disk space to have both a CVS src/ tree and a p4 tree. Plus it's difficult when you have more than one development system because you can't just keep one CVS repo and update all your systems from that. NFS works for that (it's what I do with all my development systems, one shared kernel souce tree over NFS with various p4 kernel sys trees checked out). However, I agree adding userland into the mix will complicate things. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Headsup! KSE Nay-sayers speak up!
On 27-Aug-01 Julian Elischer wrote: John Baldwin wrote: On 27-Aug-01 Julian Elischer wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I know that I am in the minority on this, but wanted to say it anyways. It doesn't mean I don't like the KSE work or anything like that (I've even helped out on it some), I just think we have enough work in our basket. Also, I'll point out that p4's merging abilities make tracking current relatively easy, much more so than if Julian was maintaining a separate tree with this patch and having to keep updating current and manually merge it all the time. /stump well I expected this to some extent.. This is why I asked.. I want to get it out where it can be discussed. the same could also be said for full pre-emption and SMP-NG. Note that I haven't committed preemption (largely because it doesn't work on SMP and alpha yet. :-P). However, SMPng is one large change for 5.x. Not sure how many large changes we want to do at a time. All I have done is brought the kernel to a state where it is READY for work to break the 1:1 barrier. It is basically logically exactly the same kernel as in -current. I think it introduces far fewer logical changes than, say, the pre-emption code, or the locking code. I agree that we could wait. I don't however think we should. I'd rather have ONE broken period than two. At USENIX we agreed that if I got this done it would be committed and work could start to provide the facilities that Dan and Chris need for the Userland code to develop. Remember, that unless you turn this on, it's a very complicated NOP. The problem becomes that if something breaks, where do you go to look for the bug? Is it a SMPng bug? Or a KSE bug? Getting SMPng to a state where a good portion (say, at least 2 major subsystems) are out from under Giant will be the first good stress testing of the concurrency and good stress testing of SMPng. It could potentially get pretty bumpy when that happens, and having KSE add to that bumpiness may make things very complicated. I wasn't in favor of KSE's in 5.0 at Usenix, but saw that I was in an obvious minority. I'm still in the minority and realize that and don't expect my opinions here to make any difference. I just wanted to voice my concerns. What it DOES do however is make your locking code more challenging. But that is going to have to be faced at some time Yes, but I'd rather face it after we've made more progress on SMPng first. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Headsup! KSE Nay-sayers speak up!
On 27-Aug-01 Kenneth Wayne Culver wrote: On Mon, 27 Aug 2001, Garrett Wollman wrote: On Mon, 27 Aug 2001 09:34:06 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I agree. I'd like to see this stuff happen, but I think it's too disruptive a change while we still haven't yet gotten over many of the SMPng issues yet. Sorry to butt in on this conversation here, but wasn't one of the main points of 5.0 and SMPng to bring KSE's into FreeBSD? No, SMPng and KSE are two different tasks. SMPng is multithreading the kernel to allow concurrent access to the kernel. KSE is changing the kernel to support physical concurrent threads of execution within a logical process, if that makes any sense. Either one is potentially useful w/o the other, but both together will build upon each other. Ken -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Headsup! KSE Nay-sayers speak up!
At 10:39 AM -0700 8/27/01, John Baldwin wrote: On 27-Aug-01 Daniel Eischen wrote: I think waiting for 6.0-current is too long. Perhaps after 5.0-release. If we get this in 5.0, we might be able to have a usable kse threads library for 5.1 or 5.2. I'm predicting a short release cycle between 5.0 and 6.0 (compared to 4.0 and 5.0) because 6.0 is probably going to be much more stable than 5.x. 5.0 (or whatever name it will go by) is slated for November, right? And the plan was that a new 6.0-current branch wouldn't even be STARTED until sometime next year, because we'll be concentrating on the reliability of 5.x. These kernel changes have to go in before anyone can work on userland changes. My guess is that if we do not get the KSE kernel stuff into 5.0, then we probably won't get to the desired userland features until sometime WELL into 2003. Maybe that's better than the gap between 4.0 and 5.0, but I think it's too long to have these changes waiting around. At the kernel summit meeting, Julian was given a green light with the timetable of getting this set of changes done by August. Right now it is pretty late in August, but (thanks partially to help from others) that schedule has basically been kept to. It would be nice to reward that effort by getting these changes in. Having said that, let me also say: In a separate message, Poul-Henning Kamp wrote: So I propose: Put up your patches in a highly visible place and advertise them on -current, -arch and -smp. Once at least 5 developers have publically said I'm running these patches on my -current machine(s) and it doesn't totally hose me and at least 3 of those machines are SMP and one is non-i386 architecture, then call for last orders before commit. This does seem prudent to me. We should have at least a few more people running these changes before they get committed to current, and preferably on more than the i386 platform. If we are going to be serious about supporting more hardware platforms, then we have to start treating them more seriously when major changes like this come along. If we can't get some broader testing of this done in the next few weeks, then the changes should probably wait until after 5.0. All the above are just my opinions, of course. -- 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: Headsup! KSE Nay-sayers speak up!
On Mon, 27 Aug 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Julian Elischer writes: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! I say No, not yet. Not yet, because in practice nobody has been running your patches yet. Not yet, because we have seen no quantified performance impact numbers (yes, I'm trying to arrange to help you produce these but on a P5/133 things are _S_L_O_W_! Not yet, because I seriously doubt if anybody has had any time to review and reflect on the way you have gone around and done things. Not yet, because there are, as I understand it, unresolved issues with KAME. Not yet, because you are generalizing from only one platform, get at least alpha working first. So I propose: Put up your patches in a highly visible place and advertise them on -current, -arch and -smp. Already done several times... Once at least 5 developers have publically said I'm running these patches on my -current machine(s) and it doesn't totally hose me and at least 3 of those machines are SMP and one is non-i386 architecture, then call for last orders before commit. I agree.. this is first orders :-) -- 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
Junior Kernel Hacker task: Get rid of NCCD constant.
Assignment: There is no reason for the NCCD constant to exist anymore. The CCD driver already has cloning support but CCDs softc structure is statically allocated for NCCD devices. Change the CCD driver to dynamically allocate memory as needed, the MD driver can be used as example as the overall morphology of the two drivers are the same. -- 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: RE: Headsup! KSE Nay-sayers speak up!
Sheesh. Everyone is so negative! Well, I'm going to be too. I think compared to some of the other things that have been thrown into -current, the KSE stuff will be the LEAST disruptive. Don't go bashing Julian for coming up with a reasoned approach to adding them, discussing the concept at many meetings (including at USENIX), and doing all the hard work to get it done. He's done a hellof a lot more discussion and worked with people a lot more any other feature that has been thrown into -current. He doesn't deserve these kind of responses, not after all the work that's been done. He's been talking about this for 2 years. TWO years! - Just for myself, I am seriously considering just throwing the whole lot (-current, that is) away and starting over from -stable. I spent 20 hours last weekend trying to unwind even part of the VM system from Giant, and failed utterly. I'd love to see the KSE stuff in -stable, I think it might even be a better fit. I am seriously considering this because I think we made a huge mistake throwing away the spl*() mechanism in -current, as a means of getting out from under the Giant lock paradigm quickly and partitioning the problem in a manner that allows subsystems to be worked on independantly. And I don't see any way to get it back. The spl*() mechanism already partitions the major subsystems that *need* to operate concurrently: I/O, interrupts, and the network stack. We would be able to work on major subsystems independantly and we would be able to debug things much more easily. -current as it currently stands is very nearly undebuggable. I've been thinking about this for the last few months... I am still thinking about it. I haven't made a decision yet. I think if KSEs go into -current I would stick with it, but if KSEs do not go into -current I don't see much of a point, -current will have wholely gone off in a direction that I don't believe in (rather then just mostly gone off). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
The mecanincal changes in C code are pretty simple, but you really need a running machine to do them because you need to change-compile-change-compile-change-compile (etc.) It took me about 1 day to do the i386 specific things.. Having doen that is should take someone with a running alpha abut a half day to do the alpha version (now that I've done the 386) and someone with a clue about alpha assembler needs to make the same changes to the machine code. (it was probably about 10 lines of assembler changes). The bigest part is the re-arranging of the u-area and changing the code to follow that change. On Mon, 27 Aug 2001, Andrew Gallatin wrote: Julian Elischer writes: Can the IA64 and Alpha developers (Arm too?) look at the KSE patch set at http://www.freebsd.org/~julian/thediff This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) so that when this is checked into -current their architectures are not broken. (On teh other hand if they would rather fix up the breakage afterwards (which may be easier) then they should let me know so I can get on with committing it. Matt and I want to commit it ASAP, so we can get on with actual threading support. Peter has also indicated that he thinks that it should be done soon, so I need toknow if there will be forthcoming changes for the other architectures, or I should go ahead and commit... Please, please don't intentionally break other architectures. Esp ones that actually work, like alpha. Its basically just mechanical changes up until this point, right? You've carved up the proc struct ranamed some things, right? I'd really appreciate it if you could make the mechanical changes required to get it to the point where it at least compiles on alpha using beast.freebsd.org. At that point, the people on -alpha should be willing to test your patch and help fix any problems that come up. I REALLY want to have alpha (and hopefully other) ready to do at the same time. but at the same time, I'm 'carrying this' because as long as I'm not committed I have a daily merge job. And it's getting bigger as people change low level code in way s that may not be compatible with what I need. I would be happy if I could commit it in 2 weeks. I'd like some help from the other architecture people though. I've done 1.85 MB of patches and the machine dependednt parts are probably about 15K of that. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
Julian Elischer wrote: John Baldwin wrote: On 27-Aug-01 Julian Elischer wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I know that I am in the minority on this, but wanted to say it anyways. It doesn't mean I don't like the KSE work or anything like that (I've even helped out on it some), I just think we have enough work in our basket. Also, I'll point out that p4's merging abilities make tracking current relatively easy, much more so than if Julian was maintaining a separate tree with this patch and having to keep updating current and manually merge it all the time. /stump well I expected this to some extent.. This is why I asked.. I want to get it out where it can be discussed. the same could also be said for full pre-emption and SMP-NG. It is also interestingto note that KSE isn't the only game in town. The new PTNG package looks interesting, using normal process rforking to generate a pthreads environment. (It's a rewrite, not a port of linux threads). All I have done is brought the kernel to a state where it is READY for work to break the 1:1 barrier. It is basically logically exactly the same kernel as in -current. I think it introduces far fewer logical changes than, say, the pre-emption code, or the locking code. I agree that we could wait. I don't however think we should. I'd rather have ONE broken period than two. At USENIX we agreed that if I got this done it would be committed and work could start to provide the facilities that Dan and Chris need for the Userland code to develop. Remember, that unless you turn this on, it's a very complicated NOP. What P4 does is really irrelevent because there are only 4 people using it.. (or is that 3?). It needs a distribution channel, and P4 isn't it. (at least not at the moment.) What it DOES do however is make your locking code more challenging. But that is going to have to be faced at some time Count my vote as a go-for-it. I agree that waiting for 6.0 would be too long indeed. I think that having the KSE framework in the kernel for 5.0 would be a good thing, along with SMPNG... I don't think this is going to turn into another 2.0-RELEASE fiasco [No offense, David, but 2.0-R was buggier than a bum's blanket], which, I may add, was quite quckly made stable after the initial -RELEASE. My one question is: If it does turn into another 2.0-R fiasco, are you ready to put in the hours needed to put out a QUICK bugfix -RELEASE [a la 5.0.5 or whatever?]. I would still prefer a stable -RELEASE. As far as intel goes, I say go for it! jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails in libssh on -CURRENT
--- Kris Kennaway [EMAIL PROTECTED] wrote: On Sun, Aug 26, 2001 at 10:31:59PM -0700, Andrei Popov wrote: === libssh make: don't know how to make dsa.c. Stop *** Error code 2 Something is wrong with your source..perhaps you didn't update it completely. Kris maybe, but ther's no dsa.c under src/crypto/openssh on ftp mirror i am updating from -- or is it a makefile problem of not picking up the one under openssl? __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in libssh on -CURRENT
On Mon, Aug 27, 2001 at 01:16:15PM -0700, Andrei Popov wrote: maybe, but ther's no dsa.c under src/crypto/openssh on ftp mirror i am updating from -- or is it a makefile problem of not picking up the one under openssl? There's not supposed to be..it was removed 3 months ago. Kris PGP signature
Re: Headsup! KSE Nay-sayers speak up!
I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! I have one system that I've been maintaining/updating since the 2.X days and I feel it's time to nuke it and start over. +1 for a non-smp system and SMP system. That said, I think the value of having both KSE and SMPng in 5.0 is HUGE and I think there is probably a large number of people that would be willing to endure kernel panics, dumps, etc. because the value (in terms of technological accomplishment and saleability in the corporate space) would be absolutely worth the bumpy road. -CURRENT isn't worth tracking unless the dumps, bugs, etc are all going toward both SMPng and KSE. Hey, anyone running -current without a tape drive attached with a daily dump schedule is either insane, a masochist, or both. Read my post from this morning about the mysterious filesystem corruption I had this morning... Kudos to Justin Gibbs for fixing EOM detection [let's get his scsi_sa.c patches committed ASAP]!!! Thanks for the heads up! Fortunately I have a few -STABLE systems that I can dump to and that host all of my email/development. ;) I'll probably go and pick up another 40+GB HD just for the extra head-room. If there are grave concerns about having KSE and SMPng in 5.X, then why not push back the release date? The value far outweighs the extra months needed to get it finished and out the door, but what do I know, I'm just a quiet kernel by standard making an observation. -sc Good idea. Seriously, is there any reason to hold to a time line at the expense of some very important and very fundamental enhancements to FreeBSD? I suppose that's something for -core to talk about/discuss, but I bet that if a poll was put on the homepage of FreeBSD.org (hint hint) asking about this, you'd get an overwhelming response to see KSE/SMPng in 5.X. With a poll you might even pick up some more testers given the exposure (hint hint). -sc -- Sean Chittenden PGP signature
Re: Headsup! KSE Nay-sayers speak up!
Matt Dillon wrote: : and preferably on more than the i386 platform. If we are going to : be serious about supporting more hardware platforms, then we have : to start treating them more seriously when major changes like this : come along. If we can't get some broader testing of this done in : the next few weeks, then the changes should probably wait until : after 5.0. : : :I believe that I read in an earlier thread that the archetecture-specific changes are minimal, and that majority of the changes are :in high-level constructs in the kernel. Of course, I could be recalling this incorrectly, but I don't think I am... : :jim Yes, this is correct. The assembly changes are just structural indirections for things that were broken off from the proc structure. The scheduler now messes with 'threads' rather then 'processes' for the most part. That part of the diff set is involved but straight forward. Julian also add KSTACK_PAGES to allow the kernel stack to be specified in a more controlled manner. Here is an excerpt so you can see what I mean: ... - - movlP_VMSPACE(%ecx), %edx + movlTD_PROC(%ecx), %eax + movlP_VMSPACE(%eax), %edx movlPCPU(CPUID), %eax btrl%eax, VM_PMAP+PM_ACTIVE(%edx) - movlP_ADDR(%ecx),%edx + movlTD_PCB(%ecx),%edx ... See? not much too it. -Matt That's about what I thought it would be... If the other archetectures are so flaky right now under FreeBSD, then maybe some people are barking up the wrong tree when it comes to opposing KSE integration using the other archetectures as the crux of their argument. Sounds like they need to be kicking some butts to catch up with the pack! Testing should be across the board, but I don't see any reason why, if the maintainers of the other archetectures are so behind on other tasks that they can't have a seperate, later, 5.0-RELEASE for them. We shouldn't sacrifice intel functionality for timetable slippage on the other archetectures, and honestly, that's how I'm reading the arguments against... Again, I could be wrong, but... Of course, we could always end up like NetBSD, with a development cycle that makes FreeBSD's current cycle look fast, only because of support for all of the different archetectures. No offense to the NetBSD'ers out there, NetBSD is a fine OS, but my point is that FreeBSD is [or was] a different paradigm, primarily [but not exclusively] intel. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Mon, Aug 27, 2001 at 04:00:35PM -0500, Jim Bryant wrote: Matt Dillon wrote: : and preferably on more than the i386 platform. If we are going to : be serious about supporting more hardware platforms, then we have : to start treating them more seriously when major changes like this : come along. If we can't get some broader testing of this done in ... That's about what I thought it would be... If the other archetectures are so flaky right now under FreeBSD, then maybe some people are barking up the wrong tree when it comes to opposing KSE integration using the other archetectures as the crux of their argument. Sounds like they need to be kicking some butts to catch up with the pack! Testing should be across the board, but I don't see any reason why, if the maintainers of the other archetectures are so behind on other tasks that they can't have a seperate, later, 5.0-RELEASE for them. We shouldn't sacrifice intel functionality for timetable slippage on the other archetectures, and honestly, that's how I'm reading the arguments against... Again, I could be wrong, but... You are. This is a far to simplistic (and IMHO quite rude) approach to the non-x86 work that has been done over time. Of course, we could always end up like NetBSD, with a development cycle that makes FreeBSD's current cycle look fast, only because of support for all of the different archetectures. No offense to the NetBSD'ers out there, NetBSD is a fine OS, but my point is that FreeBSD is [or was] a different paradigm, primarily [but not exclusively] intel. You seem to have missed the advent of arm, sparc64, powerpc ports for FreeBSD. -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Headsup! KSE Nay-sayers speak up!
On Mon, 27 Aug 2001, Garance A Drosihn wrote: This does seem prudent to me. We should have at least a few more people running these changes before they get committed to current, and preferably on more than the i386 platform. If we are going to be serious about supporting more hardware platforms, then we have to start treating them more seriously when major changes like this come along. If we can't get some broader testing of this done in the next few weeks, then the changes should probably wait until after 5.0. I don't WANT to commit without more testing and more support for the other platforms. However I need support from the people DOING those platforms to go further. I also want more people to try the patches. So far the only problem Matt Dillon and I have seen is the re-appearance of a panic during reboot that must be something silly I've done :-) I'll be doing MFC's each day into P4, and keeping my patch set at http://www.freebsd.org/~julian/thediff up to date. (If you have cvs access you have P4 access if you'd rather do that) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE kernel comparissons
In message [EMAIL PROTECTED], Peter Wemm writes: My personal check list before committing it to -current is: - an honest shot at getting the Alpha working. Shouldn't be too hard. I'll work on this if nobody else will. - finish the userland build stuff. - carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc. - take a look at ports impact and prepare them for the landing. If you add: - Beat the shit out of it together with other developers for a couple of weeks. Then I'm all for committing it when you have checked off those boxes. Without that last item I'm against, no matter what. -- 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: RE: Headsup! KSE Nay-sayers speak up!
On Mon, 27 Aug 2001, Matt Dillon wrote: Sheesh. Everyone is so negative! Well, I'm going to be too. I think compared to some of the other things that have been thrown into -current, the KSE stuff will be the LEAST disruptive. Don't go bashing Julian for coming up with a reasoned approach to adding them, discussing the concept at many meetings (including at USENIX), and doing all the hard work to get it done. He's done a hellof a lot more discussion and worked with people a lot more any other feature that has been thrown into -current. He doesn't deserve these kind of responses, not after all the work that's been done. He's been talking about this for 2 years. TWO years! With all due respect, I was not attempting to bash Julian. I was raising two classes of concerns that seemed to merit further discussion: (1) technical concerns relating to SMPng, and (2) concerns about the release schedule for 5.0-RELEASE. Neither of these reflects on Julian's work, rather, the environment in which the work is being done, and external constraints on the work that must be considered. Julian has responded with a detailed response addressing these concerns. I think it might be more constructive to consider this discussion in those terms, and avoid concepts like bash. We know we need to make an informed decision here, which means we need to consider all the options, which may mean discussing the controversial ones. I'm not fundamentally opposed to KSE: I would like to see it in the system as much as you, and am quite aware of the potential benefits. I just want to make sure we don't go three years without a stable release to get there. If the answer to the questions is either fine, or addressible, then we're set. John has expressed a number of concerns with regards to SMPng, and I take those concerns seriously. I'm still reading Julian's response, and will no doubt respond to that later if I have any further questions :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE kernel comparissons
On Mon, 27 Aug 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Peter Wemm writes: My personal check list before committing it to -current is: - an honest shot at getting the Alpha working. Shouldn't be too hard. I'll work on this if nobody else will. - finish the userland build stuff. - carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc. - take a look at ports impact and prepare them for the landing. If you add: - Beat the shit out of it together with other developers for a couple of weeks. Then I'm all for committing it when you have checked off those boxes. I agree with this list. Without that last item I'm against, no matter what. -- 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: Headsup! KSE Nay-sayers speak up!
Garance A Drosihn wrote: At 1:49 PM -0700 8/27/01, Sean Chittenden wrote: If there are grave concerns about having KSE and SMPng in 5.X, then why not push back the release date? The value far outweighs the extra months needed to get it finished and out the door, ...etc... Good idea. Seriously, is there any reason to hold to a time line at the expense of some very important and very fundamental enhancements to FreeBSD? I suppose that's something for -core to talk about/discuss, but I bet that if a poll was put on the homepage of FreeBSD.org (hint hint) asking about this, you'd get an overwhelming response to see KSE/SMPng in 5.X. With a poll you might even pick up some more testers given the exposure (hint hint). -sc We can't just keep pushing back the release date because some very important enhancements could be made. It will ALWAYS be true that there are more very important enhancements on the horizon, and you can't keep running after those. You have to pick some point, and stick to that point, and ship at that point. As long as current is known to be in rapid flux, most I'm glad you support integration of KSE then... As I recall such threading was in the original design specs for 5.0, as released when work on 5.0 began. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE kernel comparissons
On Mon, 27 Aug 2001, Robert Watson wrote: On Mon, 27 Aug 2001, Bruce Evans wrote: How much faster (or slower) will it be for threaded programs (for various numbers of CPUs)? I don't see how it can be faster for a single CPU (interrupt threads in the kernel show that using threads tends to pessimize both efficiency and latency for a single CPU). Note that we won't be able to see some of the impactmpacted until SMPng is further along, where KSE will pessimize a number of single-thread operations. For example, right now SMPng proc locking relies on certain proc structure entries being changed only by curproc, meaning that locks are held for reading only by other processes. With KSE, we'll need to actually hold real locks when acting on those curproc entries (in particular, reads) which may impose a substantial performance overhead. I would anticipate that a number of the other potential shortcuts in SMPng would be similarly impacted by KSE. However, since SMPng is very much a work in progress right now, that's not something I think we can quantify yet. This general issue does raise a lot of concerns however -- many locking assumptions in SMPng will need to be changed, and the locking will need to be much more thorough before we can move forward. Even pre-SMPng, we've had race issues relating to unexpected sleeps, this will only get more hairy (although architecturally better) with SMPng. I'm worried that throwing KSE into the mix is going to hurt a lot. The curernt KSE kernel is the point in the development where there is only ever one thread per process. this is the point where we start adding code that doesn't assume this to replace code that does assume this. That is why this is a good place to do the commit. This kernel is logcally the same as a non-KSE one. For example, a process lock is sufficient to alter proc or thread structures, because they are always 1:1 Adding this commit does not alrter the work needed to get SMP locking pushed down to a few subsystems. What it DOES do is allow people to look at what is coming. It also means that the P4 integration taks is greatly reduced as changes to device drivers etc will probably not produce clashes, (where at the moment almost any change meens an integration run for me). If I wait to check in, then I have to check in code that starts to be logically different to what is there now. (because that is what I will be working on and keeping lockstepped with -current). Either that or I stay frozen and unable to proceed until 5.1 or 6.0 or whenever. If we check in what I have now then everyone's changes will already match and people can start to think abnout how their changes will be effected by threads. WIth a couple of weeks at this point we should be able to make this exactly as reliable as -current is now, and get the other ports also at the same state as i386. When that is doen I am quite happy to go off doing further development on a p4 branch again for a couple of months more, because the integration load will be MUCH less, and because others wil be able to see where we are going. What I'm trying to say, is that this is the right time to commit it becasue it will have minimum impact on -current and maximim impact on KSE. If we delay, the impact on -current will be much greater, because parts of the system will no-longer be assuming that the proc:thread relationship is 1:1. This stage is a mostly mecahnical edit, that can be easily verified against what is there previously. If we wait we will starrt to get changes that are NOT so easily verified. I would like to get THIS stage checked in so that editing mistakes can be weeded out now while they are trivial. That wil give me a solid base on which to do teh real LOGICAL changes. If we wait then when I commit, I will be committing both sets of changes at once. My timeline would be to get the other ports (and boris's filesystems) done in the next two weeks and have a bunch of people try it on different hardwware. In tow weeks when we've proved equivalent reliability, I'd commit. Then We start affresh with p4, working up a new set of changes. THIS set I would not base off -current but rather off JOhn's SMP/locking branch. In other words I'd be tracking HIS work rather than just -current. (he'd be doing MFC's and I'd be doing MFJ's) that means that further integration for him after this commit would be negligible.. (I need it this way because the locking is critical to the threads.) julian Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On 27-Aug-01 Jim Bryant wrote: Garance A Drosihn wrote: At 1:49 PM -0700 8/27/01, Sean Chittenden wrote: If there are grave concerns about having KSE and SMPng in 5.X, then why not push back the release date? The value far outweighs the extra months needed to get it finished and out the door, ...etc... Good idea. Seriously, is there any reason to hold to a time line at the expense of some very important and very fundamental enhancements to FreeBSD? I suppose that's something for -core to talk about/discuss, but I bet that if a poll was put on the homepage of FreeBSD.org (hint hint) asking about this, you'd get an overwhelming response to see KSE/SMPng in 5.X. With a poll you might even pick up some more testers given the exposure (hint hint). -sc We can't just keep pushing back the release date because some very important enhancements could be made. It will ALWAYS be true that there are more very important enhancements on the horizon, and you can't keep running after those. You have to pick some point, and stick to that point, and ship at that point. As long as current is known to be in rapid flux, most I'm glad you support integration of KSE then... As I recall such threading was in the original design specs for 5.0, as released when work on 5.0 began. Yes, and if we had lots more man-hours on the KSE and SMPng projects such that they were farther along now things would be different. The fact is that the planning for 5.0 may have been a bit optimistic. However, I'll try and review the KSE diff as well. The diffs themselves aren't bad, I just think that we will end up with too much complexity and room for things to break each other with the breakage hard to find since you can't pin it down as easily. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Headsup! KSE Nay-sayers speak up!
At 2:48 PM -0700 8/27/01, Julian Elischer wrote: I don't WANT to commit without more testing and more support for the other platforms. However I need support from the people DOING those platforms to go further. I also want more people to try the patches. So far the only problem Matt Dillon and I have seen is the re-appearance of a panic during reboot that must be something silly I've done :-) This sounds good. I'm hopefully just about a week away from having a little more spare time, at which point I could try -current on my dual-P3 box, and try your changes on top of that. At the moment I can't help much with any other platforms, although I would definitely be willing to help test powerPC changes (once that port is far enough along to run :-). I should admit that my interest in other architectures is more for the up-and-coming PowerPC and Sparc-64 ports, instead of the already- working port of Alpha... I'll be doing MFC's each day into P4, and keeping my patch set at http://www.freebsd.org/~julian/thediff up to date. (If you have cvs access you have P4 access if you'd rather do that) I can sense that some freebsd developers are having good luck with perforce, but for me it'd be one extra thing that I would have to figure out, and figuring out perforce isn't high on my current list of priorities... -- 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: KSE kernel comparissons
On Mon, Aug 27, 2001 at 03:09:53PM -0700, Julian Elischer wrote: On Mon, 27 Aug 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Peter Wemm writes: My personal check list before committing it to -current is: - an honest shot at getting the Alpha working. Shouldn't be too hard. I'll work on this if nobody else will. - finish the userland build stuff. - carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc. - take a look at ports impact and prepare them for the landing. If you add: - Beat the shit out of it together with other developers for a couple of weeks. Then I'm all for committing it when you have checked off those boxes. I agree with this list. I think that realistically speaking, after having looked over the diff, and after considering what was discussed here, that it would be a good time to introduce the KSE work done thus far some time soon, after said testing is done. The reason for this is that the KSE changes to date are, as Julian and some others mentionned, infrastructural changes, and not _functional_ changes. Therefore, I don't expect them to create additional logic issues (e.g. I wonder if it's KSE's semantics that are breaking this... shouldn't come up with these changes when debugging other code). Thus, I agree with Peter and Julian on this issue and will be applying the diff to both dual CPU machines I have here and testing tonight. At the same time, I do hope that the actual _functional_ changes come in a hopefully more orderly/slower manner so that it is in fact possible to track down logic problems w.r.t. KSE should they arise. On another (perhaps unrelated) note, I've noticed on the lists at least one or two -CURRENT users/testers insist on having KSE functionality but at the same time expecting to have production material in early 5.0 releases. I find this to be disturbing. While I do agree that earlier 5.0 releases should deffinately reach out to the largest userbase possible, I am concerned that some users will perhaps expect so much from the system that they will immediately go ahead and pit it against more mature SMP OSes out there and then go on to complain about everything under the Sun because brand new functionality (X) is not what I expected. The robustness and performance of the work being done now will become more and more apparent only as things progress and it should be noted that all of these nice things resulting from all the work we're presently doing will not just all magically surface when 5.0-RC1 (or whatever it's going to be called) is released. -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
At 5:02 PM -0500 8/27/01, Jim Bryant wrote: Garance A Drosihn wrote: We can't just keep pushing back the release date because some very important enhancements could be made. It will ALWAYS be true that there are more very important enhancements on the horizon, and you can't keep running after those. You have to pick some point, and stick to that point, and ship at that point. As long as current is known to be in rapid flux, most I'm glad you support integration of KSE then... As I recall such threading was in the original design specs for 5.0, as released when work on 5.0 began. I'm disappointed that you completely misunderstood what I intended to say in the above. My point is that sometimes you have to stick to a ship date because you have to stick to that date, and not because you stick to some list of features that you'd like to see. The longer you let ship-dates slip, the longer you end up without a release-quality product. I think a lot of good work has gone into the current cut at KSE support, and I certainly hope it goes in. However, there are a number of other factors to consider. The right way to get KSE in 5.0 is to help do the work which is necessary for that to happen, and not to deliberately misquote people -- as you are pretty clearly doing in the above. What I explicitly said in the above message (and which you explicitly deleted) was that KSE should wait for a later release if the remaining work is not done. If you have some other opinion, that is fine, but do not reword *my* opinion to claim that I agree completely with your opinion. Julian did a lot of good work, all he needs is a few more developers to help test that work. None of us need a thread arguing about release dates vs some goals set two years ago. I support the integration of KSE in the sense that I intend to help test it (on a dual-CPU i386) sometime in the next week. I do not support a delay of 5.0. I can not test on Alpha, as I have no Alpha machines. Anyone who wants to prove their support for KSE in 5.0 should step up and offer to do some of the testing, etc. Actions will speak louder than any (misquoted) words. -- 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: RE: Headsup! KSE Nay-sayers speak up!
:I'm not fundamentally opposed to KSE: I would like to see it in the system :as much as you, and am quite aware of the potential benefits. I just want :to make sure we don't go three years without a stable release to get :there. If the answer to the questions is either fine, or addressible, :... : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :[EMAIL PROTECTED] NAI Labs, Safeport Network Services I think if KSE goes in (in the next couple of weeks, on Julian's timeline with reasonable, but not excessive additional testing), I will personally be a much happier camper in regards to working on -current. To me it will be a real turning point for the project -- the last 'big' piece of technology we promised ourselves we would get in. And I have been and will continue to be available to help track down and work out bugs in that work, and in other work. The single biggest problem -current faces right now is in unwinding Giant. It is an even larger problem then people think, I think. Because Giant still surrounds nearly all the running code there are almost certainly dozens of bugs that will come out of the woodwork as Giant gets moved inward. Hell, maybe I shouldn't be working on the VM system at all right now... maybe I should be working on mutexing data structures in order to move Giant inward. e.g. filesystem and I/O paths. The VM code is the hardest piece, it should probably be saved for last. We are not going to truely be able to stabilize -current until Giant is mostly gone. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE kernel comparissons
Bosko Milekic wrote: On Mon, Aug 27, 2001 at 03:09:53PM -0700, Julian Elischer wrote: On Mon, 27 Aug 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Peter Wemm writes: My personal check list before committing it to -current is: - an honest shot at getting the Alpha working. Shouldn't be too hard. I'll work on this if nobody else will. - finish the userland build stuff. - carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc. - take a look at ports impact and prepare them for the landing. If you add: - Beat the shit out of it together with other developers for a couple of weeks. Then I'm all for committing it when you have checked off those boxes. I agree with this list. I think that realistically speaking, after having looked over the diff, and after considering what was discussed here, that it would be a good time to introduce the KSE work done thus far some time soon, after said testing is done. The reason for this is that the KSE changes to date are, as Julian and some others mentionned, infrastructural changes, and not _functional_ changes. Therefore, I don't expect them to create additional logic issues (e.g. I wonder if it's KSE's semantics that are breaking this... shouldn't come up with these changes when debugging other code). Thus, I agree with Peter and Julian on this issue and will be applying the diff to both dual CPU machines I have here and testing tonight. At the same time, I do hope that the actual _functional_ changes come in a hopefully more orderly/slower manner so that it is in fact possible to track down logic problems w.r.t. KSE should they arise. On another (perhaps unrelated) note, I've noticed on the lists at least one or two -CURRENT users/testers insist on having KSE functionality but at the same time expecting to have production material in early 5.0 releases. I find this to be disturbing. While I do agree that earlier 5.0 releases should deffinately reach out to the largest userbase possible, I am concerned that some users will perhaps expect so much from the system that they will immediately go ahead and pit it against more mature SMP OSes out there and then go on to complain about everything under the Sun because brand new functionality (X) is not what I expected. The robustness and performance of the work being done now will become more and more apparent only as things progress and it should be noted that all of these nice things resulting from all the work we're presently doing will not just all magically surface when 5.0-RC1 (or whatever it's going to be called) is released. As I recall, *total* functionality of the subsystems wasn't promised for 5.0-R, but the infrastructure *was* promised. I expect you are reponding to my post in the other thread... Nobody is expecting a kick-butt implementation to just spring from the head of Zeus, but the infrastructure should be in place so that a kick-butt implementation can be made from it in the time that follows. With the infrastructure in place, we can probably expect a good implementation by 5.1-R, if it doesn't get committed at this stage, Julian will be lucky to get it in by 6.0-R, and I bet all the same arguments against will come up then as well. The patches seem relatively benign, and after some basic immediate testing, they should be committed to -current. That's all I'm trying to say. My response to the other gentleman were to address his comments that FreeBSD should not even hit the goals it had set initially for 5.0. I disagree with those arguments completely. I thought that Jordan and the core team had a good, even pessimistic estimate a couple of years ago for the future of 5.0 and even 6.0 as I recall... IMHO, I would tend to say that those estimates were pessimistic even. It definitely wasn't a everything, including the kitchen sink philosophy such as they had for 2.0-R [which was also influenced by legal matters], a lot of people may still remember that release, and the mad rush to fix the newly-introduced problems afterwards, I'm certain that David Greenman and some others do :^) Expecting to see the base infrastructure in place with at least some functionality of the new infrastructure is being realistic. Expecting a *PERFECT* implementation and *FULL* functionality of the new paradigms isn't. I want to see a functional SMPng for sure, but Julian is right, now is the time for the KSE infrastructure to be committed, it's at that stage. Just clarifying my clarification here. BTW: shouldn't this be in the other thread? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current
Re: Headsup! KSE Nay-sayers speak up!
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Julian Elischer writes: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! I say No, not yet. Not yet, because in practice nobody has been running your patches yet. Not yet, because we have seen no quantified performance impact numbers (yes, I'm trying to arrange to help you produce these but on a P5/133 things are _S_L_O_W_! Not yet, because I seriously doubt if anybody has had any time to review and reflect on the way you have gone around and done things. Not yet, because there are, as I understand it, unresolved issues with KAME. Not yet, because you are generalizing from only one platform, get at least alpha working first. So I propose: Put up your patches in a highly visible place and advertise them on -current, -arch and -smp. Once at least 5 developers have publically said I'm running these patches on my -current machine(s) and it doesn't totally hose me and at least 3 of those machines are SMP and one is non-i386 architecture, then call for last orders before commit. If Julian can guarantee it won't hose me completely from the get-go, count me as a tester. The box I would be testing this on is SMP, albeit, intel. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! I have one system that I've been maintaining/updating since the 2.X days and I feel it's time to nuke it and start over. +1 for a non-smp system and SMP system. That said, I think the value of having both KSE and SMPng in 5.0 is HUGE and I think there is probably a large number of people that would be willing to endure kernel panics, dumps, etc. because the value (in terms of technological accomplishment and saleability in the corporate space) would be absolutely worth the bumpy road. -CURRENT isn't worth tracking unless the dumps, bugs, etc are all going toward both SMPng and KSE. If there are grave concerns about having KSE and SMPng in 5.X, then why not push back the release date? The value far outweighs the extra months needed to get it finished and out the door, but what do I know, I'm just a quiet kernel by standard making an observation. -sc -- Sean Chittenden PGP signature
Re: Headsup! KSE Nay-sayers speak up!
Garance A Drosihn wrote: 5.0 (or whatever name it will go by) is slated for November, right? And the plan was that a new 6.0-current branch wouldn't even be STARTED until sometime next year, because we'll be concentrating on the reliability of 5.x. These kernel changes have to go in before anyone can work on userland changes. My guess is that if we do not get the KSE kernel stuff into 5.0, then we probably won't get to the desired userland features until sometime WELL into 2003. Maybe that's better than the gap between 4.0 and 5.0, but I think it's too long to have these changes waiting around. I agree... I thought the idea of 5.0 was to kick Linux in the butt. It isn't as if they are just sitting around... FreeBSD is going to be left in the dust unless both the SMPng *AND* KSE projects are integrated into 5.0. At the kernel summit meeting, Julian was given a green light with the timetable of getting this set of changes done by August. Right now it is pretty late in August, but (thanks partially to help from others) that schedule has basically been kept to. It would be nice to reward that effort by getting these changes in. [Looks at calandar] Yup! It's August! Good work Julian! This does seem prudent to me. We should have at least a few more people running these changes before they get committed to current, and preferably on more than the i386 platform. If we are going to be serious about supporting more hardware platforms, then we have to start treating them more seriously when major changes like this come along. If we can't get some broader testing of this done in the next few weeks, then the changes should probably wait until after 5.0. I believe that I read in an earlier thread that the archetecture-specific changes are minimal, and that majority of the changes are in high-level constructs in the kernel. Of course, I could be recalling this incorrectly, but I don't think I am... jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
Sean Chittenden wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! I have one system that I've been maintaining/updating since the 2.X days and I feel it's time to nuke it and start over. +1 for a non-smp system and SMP system. That said, I think the value of having both KSE and SMPng in 5.0 is HUGE and I think there is probably a large number of people that would be willing to endure kernel panics, dumps, etc. because the value (in terms of technological accomplishment and saleability in the corporate space) would be absolutely worth the bumpy road. -CURRENT isn't worth tracking unless the dumps, bugs, etc are all going toward both SMPng and KSE. Hey, anyone running -current without a tape drive attached with a daily dump schedule is either insane, a masochist, or both. Read my post from this morning about the mysterious filesystem corruption I had this morning... Kudos to Justin Gibbs for fixing EOM detection [let's get his scsi_sa.c patches committed ASAP]!!! If there are grave concerns about having KSE and SMPng in 5.X, then why not push back the release date? The value far outweighs the extra months needed to get it finished and out the door, but what do I know, I'm just a quiet kernel by standard making an observation. -sc Good idea. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
: and preferably on more than the i386 platform. If we are going to : be serious about supporting more hardware platforms, then we have : to start treating them more seriously when major changes like this : come along. If we can't get some broader testing of this done in : the next few weeks, then the changes should probably wait until : after 5.0. : : :I believe that I read in an earlier thread that the archetecture-specific changes are :minimal, and that majority of the changes are :in high-level constructs in the kernel. Of course, I could be recalling this :incorrectly, but I don't think I am... : :jim Yes, this is correct. The assembly changes are just structural indirections for things that were broken off from the proc structure. The scheduler now messes with 'threads' rather then 'processes' for the most part. That part of the diff set is involved but straight forward. Julian also add KSTACK_PAGES to allow the kernel stack to be specified in a more controlled manner. Here is an excerpt so you can see what I mean: ... - - movlP_VMSPACE(%ecx), %edx + movlTD_PROC(%ecx), %eax + movlP_VMSPACE(%eax), %edx movlPCPU(CPUID), %eax btrl%eax, VM_PMAP+PM_ACTIVE(%edx) - movlP_ADDR(%ecx),%edx + movlTD_PCB(%ecx),%edx ... See? not much too it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE kernel comparissons
Julian Elischer wrote:
On Mon, 27 Aug 2001, Robert Watson wrote:
On Mon, 27 Aug 2001, Bruce Evans wrote:
How much faster (or slower) will it be for threaded programs (for
various numbers of CPUs)? I don't see how it can be faster for a single
CPU (interrupt threads in the kernel show that using threads tends to
pessimize both efficiency and latency for a single CPU).
Note that we won't be able to see some of the impactmpacted until SMPng is
further along, where KSE will pessimize a number of single-thread
operations. For example, right now SMPng proc locking relies on certain
proc structure entries being changed only by curproc, meaning that locks
are held for reading only by other processes. With KSE, we'll need to
actually hold real locks when acting on those curproc entries (in
particular, reads) which may impose a substantial performance overhead. I
would anticipate that a number of the other potential shortcuts in SMPng
would be similarly impacted by KSE. However, since SMPng is very much a
work in progress right now, that's not something I think we can quantify
yet.
This general issue does raise a lot of concerns however -- many locking
assumptions in SMPng will need to be changed, and the locking will need to
be much more thorough before we can move forward. Even pre-SMPng, we've
had race issues relating to unexpected sleeps, this will only get more
hairy (although architecturally better) with SMPng. I'm worried that
throwing KSE into the mix is going to hurt a lot.
The curernt KSE kernel is the point in the development
where there is only ever one thread per process.
this is the point where we start adding code that doesn't assume this
to replace code that does assume this.
That is why this is a good place to do the commit.
For what it is worth, I am in agreement with Julian. The KSE code is at
an ideal checkpoint stage, but we must not rush it and screw things up.
The main reason that I would like it to be committed soon is that it
reduces the amount of moving target that the KSE part of the work has to
track. The bulk of the current changes in the current diffs are API related
and dont really change the core structural things too much. Trying to keep
a live branch up to date *and* implement the structural changes is a tall
order. We saw what happened to the BSD/OS folks, they spent 2 or 3 days
a week catching up to the current tip of tree, and only ~2 days on actual
SMP work. If we get this checkpoint into the main tree in a timely fashion
then we get the bulk of the tree-chasing out of the way and can implement
${Your_favorite_thread_frontend} at your leisure. Heck, this stuff is
generic enough that it is required for any of the thread systems, be it
full-blown KSE, or the NetBSD style lwp/sa, or linuxthreads style things,
or whatever.
If any committers want to get involved, there is a stale p4 quickstart
guide at: http://people.freebsd.org/~peter/p4cookbook.txt. You can
check out //depot/projects/kse/sys/... and review to your hearts's content.
My personal check list before committing it to -current is:
- an honest shot at getting the Alpha working. Shouldn't be too hard.
I'll work on this if nobody else will.
- finish the userland build stuff.
- carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc.
- take a look at ports impact and prepare them for the landing.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Mon, 27 Aug 2001 15:34:14 -0500, Jim Bryant [EMAIL PROTECTED] said: FreeBSD is going to be left in the dust unless both the SMPng *AND* KSE projects are integrated into 5.0. I care about having a system that works well and does what I ask of it. What the Linux horde is doing is of little concern to me, and I suspect the same goes for a number of other long-time FreeBSDers. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE kernel comparissons
On 27-Aug-01 Jim Bryant wrote: As I recall, *total* functionality of the subsystems wasn't promised for 5.0-R, but the infrastructure *was* promised. I expect you are reponding to my post in the other thread... Grr, do you develop software? Hmm, well, no matter what you do, I'm sure we can come up with an example of having two enormous changes being made at the same time. It's painful, it's more painful than doing them one at a time. Right now the patchset is indeed benign, but trying to split up KSE's at the same time as the kernel is being ripped apart to be locked down is going to cause much frustration with things breaking due to weird combinations of things that worked fine in each other's local trees. Nobody is expecting a kick-butt implementation to just spring from the head of Zeus, but the infrastructure should be in place so that a kick-butt implementation can be made from it in the time that follows. With the infrastructure in place, we can probably expect a good implementation by 5.1-R, if it doesn't get committed at this stage, Julian will be lucky to get it in by 6.0-R, and I bet all the same arguments against will come up then as well. Why in the world would people protest putting KSE in 6.0? 5.0 is close to release here, and the idea is that SMPng will be much farther along so that the pain won't be as great if we wait until 6.0-current. My response to the other gentleman were to address his comments that FreeBSD should not even hit the goals it had set initially for 5.0. I disagree with those arguments completely. If a task takes X amount of effort, and you only have Y X amount of effort to expend, then you aren't going to achieve the task. You can't change that by decreeing that this feature adn that feature will be in FreeBSD at such and such a date because Jordan said so 2 years ago. Do you realize how long it has taken commercial OS's with several full-time _paid_ employees to achieve the same tasks we are doing in SMPng and KSE? My best guess is that SMPng won't be finished for at least 2 years, and that is not taking KSE into account. In truth, SMPng has up to this point been largely infrastructure work, and there is still infrastructure work to be done at that. Perhaps I'm being uber-paranoid about this. *sigh* -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Headsup! KSE Nay-sayers speak up!
Garance A Drosihn wrote: At 5:02 PM -0500 8/27/01, Jim Bryant wrote: Garance A Drosihn wrote: We can't just keep pushing back the release date because some very important enhancements could be made. It will ALWAYS be true that there are more very important enhancements on the horizon, and you can't keep running after those. You have to pick some point, and stick to that point, and ship at that point. As long as current is known to be in rapid flux, most I'm glad you support integration of KSE then... As I recall such threading was in the original design specs for 5.0, as released when work on 5.0 began. I'm disappointed that you completely misunderstood what I intended to say in the above. My point is that sometimes you have to stick to a ship date because you have to stick to that date, and not because you stick to some list of features that you'd like to see. The longer you let ship-dates slip, the longer you end up without a release-quality product. I to this day still think that was the reasoning behind the Thanksgiving [An American Holiday] release of 2.0-R. What a disaster! I know for a fact that MickeySoft has had this philosophy since at least Win-95.. What a disaster! Marketing people screaming about ship-dates are the prime cause of unstable software, IMHO. Software should be shipped when design goals are met, not before. Last I heard, 4.4-R is RSN... Why should there be a mad rush to release 5.0-R practically right after 4.4-R, especially if it's not yet ready for prime-time? At the rate things are going, even WITH KSE integrated, 5.0-R should be close to the currently projected release date. I forget... Wasn't the *ORIGINAL* release date for 5.0-R slated for early-2002? What happened to that? Marketing types step in? I think a lot of good work has gone into the current cut at KSE support, and I certainly hope it goes in. However, there are a number of other factors to consider. The right way to get KSE in 5.0 is to help do the work which is necessary for that to happen, and not to deliberately misquote people -- as you are pretty clearly doing in the above. What I explicitly said in the above message (and which you explicitly deleted) was that KSE should wait for a later release if the remaining work is not done. If you have some other opinion, that is fine, but do not reword *my* opinion to claim that I agree completely with your opinion. It was an asinine reply to an asinine comment, not a deliberate misquotation. Julian did a lot of good work, all he needs is a few more developers to help test that work. None of us need a thread arguing about release dates vs some goals set two years ago. Somehow I see the GOP using that same argument next year concerning the tax-scam... Medicare surplus wiped out, 9 billion into Social Security starting next week... oops, off topic... I agree with you to a point there. The design goals should be met. This isn't a commercial product, and thus I don't see that the argument that the release date should be set in stone is relevant, although it should be close to that which was originally specified. I support the integration of KSE in the sense that I intend to help test it (on a dual-CPU i386) sometime in the next week. I do not support a delay of 5.0. I can not test on Alpha, as I have no Alpha machines. Anyone who wants to prove their support for KSE in 5.0 should step up and offer to do some of the testing, etc. Actions will speak louder than any (misquoted) words. Again, I agree, except I still don't understand your dire need for a mad rush to have another Thanksgiving release a la 2.0-R. FreeBSD releases should be goal-oriented, not marketing-type oriented. 2.0-R left FreeBSD with reputation damage that took several years to clear up, I would have thought that some had learned from that stick to the release date experience. My first experience with -current sprang from that experience [for a while -current was more stable than -RELEASE, on freaking production systems]. It didn't take too long to get -RELEASE stable though, as I recall. Marketing types have a place: Selling RELEASED software and hardware... They should not be the end-all word on ship dates though. Hell, the Pentium 4 was a nice concept until... jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unknown PNP hardware
Mike Smith [EMAIL PROTECTED] wrote: It's written for 4.X, but might work for -current (you'll have to disable the checks for 4.X, at the very least). You use it like this: dmesg | scanirq It's completely obsoleted by devinfo and pciconf's '-v' flag. Sorry. 8) Cool! I didn't want to support it, anyway. ;-) -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
Jim Bryant [EMAIL PROTECTED] wrote: FreeBSD is going to be left in the dust unless both the SMPng *AND* KSE proje cts are integrated into 5.0. Is there some reason why KSE couldn't be integrated ASAP *AFTER* 5.0 is released? [ Personally, I'd like to see it in 5.0, but, with all the qualms that people seem to have, I'm curious as to why it can't be integrated immediately after 5.0 is cut? This way, Julian's MFCs are reduced, and it gives people more time to pound on KSE. ] -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Mon, Aug 27, 2001 at 10:39:23AM -0700, John Baldwin wrote: I wasn't in favor of KSE's in 5.0 at Usenix, but saw that I was in an obvious minority. I'm still in the minority and realize that and don't expect my opinions here to make any difference. I just wanted to voice my concerns. I find it distressing that you are the *only* person doing SMPng work, and people aren't giving your opinion a 10x weighting. -- -- David ([EMAIL PROTECTED]) Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Monday, 27 August 2001 at 18:43:13 -0700, David O'Brien wrote: On Mon, Aug 27, 2001 at 03:13:19PM -0500, Jim Bryant wrote: Count my vote as a go-for-it. Blah. You're vote doesn't mean jack in this. Be that as it may, this kind of message does mean something, but it's nothing positive. We've had enough nastiness in this area already. If you don't like what Jim's saying, why not just ignore him? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE kernel comparissons
Garance A Drosihn wrote: At 6:28 PM -0500 8/27/01, Jim Bryant wrote: The patches seem relatively benign, and after some basic immediate testing, they should be committed to -current. That's all I'm trying to say. Then shut up and help test it. That's what KSE needs, some people who are willing to help out with the work. So far you've been blowing a lot of smoke in these KSE threads, pretending that you support it. Most of that support has been demanding that other people do stuff, instead of any reasoned or intelligent input. Almost everyone else in this thread is at least TRYING to be professional about presenting the options, no matter what their opinion might be. All of them support KSE in the sense of wanting to see that work in FreeBSD. They also have a number of other legitimate real-world concerns. If you really supported KSE, then you would do something. Something called 'work', which Julian is very familiar with but which seems foreign to your vocabulary. Ahem... I believe I have said I'm going to be applying the patches. Did you miss that one? As far as the other's concerns, even I said it needs testing before inclusion. I have also offered to test it, is that not good enough for you, or do you just not read well? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Tue, Aug 28, 2001 at 11:47:30AM +0930, Greg Lehey wrote: Blah. You're vote doesn't mean jack in this. Be that as it may, this kind of message does mean something, but it's nothing positive. We've had enough nastiness in this area already. If you don't like what Jim's saying, why not just ignore him? Because I am also trying to make a very important point. And attempt to bring readers into some sense of reality. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
David O'Brien wrote: On Mon, Aug 27, 2001 at 03:13:19PM -0500, Jim Bryant wrote: Count my vote as a go-for-it. Blah. You're vote doesn't mean jack in this. Unless you are one actively working on the 5-CURRENT kernel (SMPng specifically), or are funding 5-CURRENT kernel development; you really don't have any right to say go for it. Don't write cheques your body can't cash. Quincy Jones's The Dude. Committing KSE now could easily get in the way of the one person doing SMPng work. Do you really want to jeopardize and slowdown that work? Actually, I'd like to see both projects proceed, but apparently what non-core contributers to FreeBSD think doesn't matter. Maybe all of the VOLUNTEER testers for -current should take your advice and go to NetBSD, OpenBSD, Linux, or open-Solaris... Maybe their opinions would be better received. As far as opinions are concerned, you have expressed yours, and I kinda hope it doesn't represent that of the entire core team. Opinions were asked for. Testers were asked for. I'm offering both. I don't think when Julian asked for opinions and testers that he was specifically asking core team members only. Julian, if this is not the case, please speak up, and accept my apology for butting in with my opinion, and my offer to take you up on your call for testers. All I did was write in support of getting some promised 5.0 items into 5.0, even offering to test them! Excuuse me! Shame on us peons for speaking our opinions! jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Mon, Aug 27, 2001 at 09:36:56PM -0500, Jim Bryant wrote: Actually, I'd like to see both projects proceed, but apparently what non-core contributers to FreeBSD think doesn't matter. It is an issue of effort and practicality. We are not talking about what should be the default window manager to give users maxium FreeBSD enjoyment. Setting up a nice GNOME or KDE default environment is about the same amount of work. And something that is orders upon orders of magnitude less time and complex than SMPng. If I expected you to send me a brand new dual AMD-Athlon machine that would be ridiculous. If I asked you to boot FreeBSD on it and send me the /var/run/dmesg.boot output and how long `make world' took, that would be reasonable. Expectations must be kept in perspective. Maybe all of the VOLUNTEER testers for -current should take your advice and go to NetBSD, OpenBSD, Linux, or open-Solaris... Maybe their opinions would be better received. I *MY* HO, if all someone does is whine w/o producing patches or good crashdumps, then *I* (only speaking for *me* here) don't mind that one bit. As far as opinions are concerned, you have expressed yours, and I kinda hope it doesn't represent that of the entire core team. Not it doesn't. That is why there was a disclaimer on my email and one on this one also. Opinions were asked for. Testers were asked for. I'm offering both. I don't think when Julian asked for opinions and testers that he was specifically asking core team members only. Julian, if this is not the case, please speak up, and accept my apology for butting in with my opinion, and my offer to take you up on your call for testers. Testing the KSE patch and saying it must go into 5.0 are two different things. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
Pleas guys, cut it out... Take a copy, run it, beat on it.. let me know if it fails.. thanks.. (p.s. I'll need to put a new patch up because -current has changed.. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On 28-Aug-01 David O'Brien wrote: On Mon, Aug 27, 2001 at 10:39:23AM -0700, John Baldwin wrote: I wasn't in favor of KSE's in 5.0 at Usenix, but saw that I was in an obvious minority. I'm still in the minority and realize that and don't expect my opinions here to make any difference. I just wanted to voice my concerns. I find it distressing that you are the *only* person doing SMPng work, and people aren't giving your opinion a 10x weighting. I'm not the only person, and I only get one vote. It's FreeBSD, not jhbBSD. :) (jhbBSD would be fearful, indeed) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Headsup! KSE Nay-sayers speak up!
This project has always been more than just its core developers, whomever they might be at any one time (and if history has shown us anything, it's that it's a constantly changing cast). This means that anyone is free to chime in with their opinion on any project decision, just as the people doing the work being commented on are free to ignore or implement those suggestions as they see fit. What we don't get to do is violently squelch the opinions of anyone we disagree with and I'm somewhat appalled that you've felt compelled to go this far in your reply - it's really totally contrary to what this project really stands for and if you don't see that, it's time you took a much-needed vacation. If you want to disagree with someone's position, you can state your disagreement directly (I think this will jeopardize and slow down the SMPng work and I strongly disagree with Jim's suggestion) without calling into question their very right to express an opinion. Nobody's given you that kind of authority and no one likely ever will since censorship and an open development atmosphere are mutually exclusive concepts. For shame, David! - Jordan From: David O'Brien [EMAIL PROTECTED] Subject: Re: Headsup! KSE Nay-sayers speak up! Date: Mon, 27 Aug 2001 18:43:13 -0700 On Mon, Aug 27, 2001 at 03:13:19PM -0500, Jim Bryant wrote: Count my vote as a go-for-it. Blah. You're vote doesn't mean jack in this. Unless you are one actively working on the 5-CURRENT kernel (SMPng specifically), or are funding 5-CURRENT kernel development; you really don't have any right to say go for it. Don't write cheques your body can't cash. Quincy Jones's The Dude. Committing KSE now could easily get in the way of the one person doing SMPng work. Do you really want to jeopardize and slowdown that work? -- -- David ([EMAIL PROTECTED]) Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. 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: Headsup! KSE Nay-sayers speak up!
At 6:59 PM -0500 8/27/01, Jim Bryant wrote: Garance A Drosihn wrote: What I explicitly said in the above message (and which you explicitly deleted) was that KSE should wait for a later release if the remaining work is not done. If you have some other opinion, that is fine, but do not reword *my* opinion to claim that I agree completely with your opinion. It was an asinine reply to an asinine comment, not a deliberate misquotation. Asinine replies seems to be a good description for everything you have said in all of these KSE threads. -- 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: KSE kernel comparissons
At 6:28 PM -0500 8/27/01, Jim Bryant wrote: The patches seem relatively benign, and after some basic immediate testing, they should be committed to -current. That's all I'm trying to say. Then shut up and help test it. That's what KSE needs, some people who are willing to help out with the work. So far you've been blowing a lot of smoke in these KSE threads, pretending that you support it. Most of that support has been demanding that other people do stuff, instead of any reasoned or intelligent input. Almost everyone else in this thread is at least TRYING to be professional about presenting the options, no matter what their opinion might be. All of them support KSE in the sense of wanting to see that work in FreeBSD. They also have a number of other legitimate real-world concerns. If you really supported KSE, then you would do something. Something called 'work', which Julian is very familiar with but which seems foreign to your vocabulary. -- 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: Ia64 and ALPHA (+arm, sparc?) kernel developers:
On Sun, Aug 26, 2001 at 10:44:04PM -0700, Julian Elischer wrote: This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) Have you even tried compiling this on beast.freebsd.org? You didn't say. Unfortuneatly the burdon is on you to make this work on the Alpha platform before you commit it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Actualy peter is most of the way through the alpha support as we speak. I wouldn't know what the alpha looks like from a architecture pov if it came and kicked me.. I did some small parts already but peter just checked in more in P4. On Mon, 27 Aug 2001, David O'Brien wrote: On Sun, Aug 26, 2001 at 10:44:04PM -0700, Julian Elischer wrote: This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) Have you even tried compiling this on beast.freebsd.org? You didn't say. Unfortuneatly the burdon is on you to make this work on the Alpha platform before you commit it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE believers should show up!
At 5:09 PM -0700 8/27/01, Darryl Okahata wrote: Is there some reason why KSE couldn't be integrated ASAP *AFTER* 5.0 is released? [ Personally, I'd like to see it in 5.0, but, with all the qualms that people seem to have, I'm curious as to why it can't be integrated immediately after 5.0 is cut? This way, Julian's MFCs are reduced, and it gives people more time to pound on KSE. ] In the interests of progress, let us assume for the moment that most of the qualms about KSE could be addressed by more testing of it, and a little more work for non-Intel platforms. Based on that assumption, anyone who is eager for KSE should realize that NOW is the time to step forward and help out with it. If we can get a reasonable amount of testing done in the next two or three weeks, then maybe we could get KSE committed for 5.0, and also get 5.0 released when we expected to release it. I think this would be the ideal outcome. If you have any energy to spare right now, let's put that energy towards the ideal outcome. But NOW is the time to help out, not in late October or November. I have changed the subject for this message, because I am hoping that a more positive subject might get a more positive result. Anyone who does think KSE is worth having for 5.0, should step up and provide Julian with the help needed to address the legitimate concerns which have been mentioned. Julian does not need people descending into a flame-war, he needs people to show up and help out. -- 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: Headsup! KSE Nay-sayers speak up!
On Mon, Aug 27, 2001 at 09:34:06AM -0700, John Baldwin wrote: Just to get this out in the public: I for one think 5.x has enough changes in it and would like for KSE to be postponed to 6.0-current and 6.0-release. I know that I am in the minority on this, but wanted to say it anyways. You have my OVERWHELMING support for this position. We still have major problems in -CURRENT and if KSE code hit the tree I only see it leading to finger pointing on who broke what. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Mon, Aug 27, 2001 at 02:48:21PM -0700, Julian Elischer wrote: I don't WANT to commit without more testing and more support for the other platforms. However I need support from the people DOING those platforms to go further. For $500-$600 I can put you on a 500MHz 21164 Alpha. I've invested $2500 from my own pocket in Alpha hardware, so others with nice Bay Area saleries can too. :-) -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Mon, Aug 27, 2001 at 03:13:19PM -0500, Jim Bryant wrote: Count my vote as a go-for-it. Blah. You're vote doesn't mean jack in this. Unless you are one actively working on the 5-CURRENT kernel (SMPng specifically), or are funding 5-CURRENT kernel development; you really don't have any right to say go for it. Don't write cheques your body can't cash. Quincy Jones's The Dude. Committing KSE now could easily get in the way of the one person doing SMPng work. Do you really want to jeopardize and slowdown that work? -- -- David ([EMAIL PROTECTED]) Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Mon, Aug 27, 2001 at 08:03:15PM -0700, John Baldwin wrote: I find it distressing that you are the *only* person doing SMPng work, and people aren't giving your opinion a 10x weighting. I'm not the only person, and I only get one vote. But you are the leading expert in SMPng, and thus any potential negative impact on the SMPng effort due to too much change at one time. It's FreeBSD, not jhbBSD. :) (jhbBSD would be fearful, indeed) Quite likely. :-) -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Julian Elischer wrote: Actualy peter is most of the way through the alpha support as we speak. I wouldn't know what the alpha looks like from a architecture pov if it came and kicked me.. I did some small parts already but peter just checked in more in P4. Latest news: The alpha made it to single user... (!). There is still a problem, but I will find that shortly. I have not yet built GENERIC, just my tuned kernel. Things like linux and osf1 compat still need doing. FWIW, the tail: ... Timecounter i8254 frequency 1193182 Hz ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed acd0: CDROM CD-540E at ata0-master PIO4 Waiting 2 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318404LW 0006 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: IBM DMVS18V 0250 Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) Mounting root from ufs:/dev/da0a Enter full pathname of shell or RETURN for /bin/sh: # ls halted CPU 0 halt code = 2 kernel stack not valid halt PC = fc553020 CPU 0 booting ... oops :-) On Mon, 27 Aug 2001, David O'Brien wrote: On Sun, Aug 26, 2001 at 10:44:04PM -0700, Julian Elischer wrote: This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) Have you even tried compiling this on beast.freebsd.org? You didn't say. Unfortuneatly the burdon is on you to make this work on the Alpha platform before you commit it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
Tha actual impact on John will be minimal at this time. It'll be greater later. On Mon, 27 Aug 2001, David O'Brien wrote: On Mon, Aug 27, 2001 at 08:03:15PM -0700, John Baldwin wrote: I find it distressing that you are the *only* person doing SMPng work, and people aren't giving your opinion a 10x weighting. I'm not the only person, and I only get one vote. But you are the leading expert in SMPng, and thus any potential negative impact on the SMPng effort due to too much change at one time. It's FreeBSD, not jhbBSD. :) (jhbBSD would be fearful, indeed) Quite likely. :-) -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in libssh on -CURRENT
--- Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, Aug 27, 2001 at 01:16:15PM -0700, Andrei Popov wrote: maybe, but ther's no dsa.c under src/crypto/openssh on ftp mirror i am updating from -- or is it a makefile problem of not picking up the one under openssl? There's not supposed to be..it was removed 3 months ago. Kris I've added src-secure and src-sys-crypto to /etc/cvsupfile.intl and the build proceded w/o error (had only src-crypto there before). __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in libssh on -CURRENT
On Mon, Aug 27, 2001 at 10:49:21PM -0700, Andrei Popov wrote: --- Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, Aug 27, 2001 at 01:16:15PM -0700, Andrei Popov wrote: maybe, but ther's no dsa.c under src/crypto/openssh on ftp mirror i am updating from -- or is it a makefile problem of not picking up the one under openssl? There's not supposed to be..it was removed 3 months ago. Kris I've added src-secure and src-sys-crypto to /etc/cvsupfile.intl and the build proceded w/o error (had only src-crypto there before). Cool, glad to hear it's resolved. Kris PGP signature
Re: fxp SCB timeout problems [FIX]
Mike Tancsa wrote: fxp0: Intel Pro/100 Ethernet port 0xc400-0xc43f mem 0xd5001000-0xd5001fff irq 11 at device 8.0 on pci1 fxp0: *** DISABLING DYNAMIC STANDBY MODE IN EEPROM *** fxp0: New EEPROM ID: 0x49a0 fxp0: EEPROM checksum @ 0xff: 0xe441 - 0xe443 fxp0: *** PLEASE REBOOT THE SYSTEM NOW FOR CORRECT OPERATION *** What exactly is Dynamic Standby Mode? What's being lost here, when it is disabled, instead of being handled as the card manufacturer expects the OS to handle it? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fxp SCB timeout problems [FIX]
At 10:52 PM 8/27/2001 -0700, Terry Lambert wrote: Mike Tancsa wrote: fxp0: Intel Pro/100 Ethernet port 0xc400-0xc43f mem 0xd5001000-0xd5001fff irq 11 at device 8.0 on pci1 fxp0: *** DISABLING DYNAMIC STANDBY MODE IN EEPROM *** fxp0: New EEPROM ID: 0x49a0 fxp0: EEPROM checksum @ 0xff: 0xe441 - 0xe443 fxp0: *** PLEASE REBOOT THE SYSTEM NOW FOR CORRECT OPERATION *** What's being lost here, when it is disabled, instead of being handled as the card manufacturer expects the OS to handle it? From my perspective, negative functionality is being lost. There is a nice comment in the source code explaining what it is... * Enable workarounds for certain chip revision deficiencies. * * Systems based on the ICH2/ICH2-M chip from Intel have a defect * where the chip can cause a PCI protocol violation if it receives * a CU_RESUME command when it is entering the IDLE state. The * workaround is to disable Dynamic Standby Mode, so the chip never * deasserts CLKRUN#, and always remains in an active state. * * See Intel 82801BA/82801BAM Specification Update, Errata #30. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Andrew Gallatin wrote: I'd really appreciate it if you could make the mechanical changes required to get it to the point where it at least compiles on alpha using beast.freebsd.org. At that point, the people on -alpha should be willing to test your patch and help fix any problems that come up. It has been pointed out that the stumbling block is ~10 lines of Akpha assembly language code that Julian is asking that someone familiar with the Alpha write. Julian is not an Alpha assembly language guru. In order to make these changes, he would have to do a lot of work, whereas someone who knew Alpha assembly language could do them very quickly. I think asking him to do this without knowledge of register save/restore and allocation plocies of the FreeBSD Alpha port is rather unfair. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
Matt Dillon wrote: Just for myself, I am seriously considering just throwing the whole lot (-current, that is) away and starting over from -stable. I spent 20 hours last weekend trying to unwind even part of the VM system from Giant, and failed utterly. I'd love to see the KSE stuff in -stable, I think it might even be a better fit. I am seriously considering this because I think we made a huge mistake throwing away the spl*() mechanism in -current, as a means of getting out from under the Giant lock paradigm quickly and partitioning the problem in a manner that allows subsystems to be worked on independantly. And I don't see any way to get it back. The spl*() mechanism already partitions the major subsystems that *need* to operate concurrently: I/O, interrupts, and the network stack. We would be able to work on major subsystems independantly and we would be able to debug things much more easily. -current as it currently stands is very nearly undebuggable. I've been thinking about this for the last few months... I am still thinking about it. I haven't made a decision yet. I think if KSEs go into -current I would stick with it, but if KSEs do not go into -current I don't see much of a point, -current will have wholely gone off in a direction that I don't believe in (rather then just mostly gone off). I'm similarly hesitant about -current; I didn't really like the SPL changes, which were capable of being converted to a lock per mask, and getting moderately parallel code rather cheaply... actually, I'm running my network stack almost totally without NETISR (see the Van Jacobsen papers), and expect to get rid of it completely in the very near future; this eliminates the real splimp induced contention remaining, making it safe to treat SPL's as masks of bit locks to hold. I'm also not too enamored about the interrupt threads idea, which I've argued before -- it has always boiled down to the fact it was available at the time, without respect to the actual merits of the approach. If I have to schedule, I'm already dead, when it comes to a receiver livelock, since I'll just be taking interrupts until I run out of mbufs, and then keep taking them forever, while dropping the packets that I no longer have mbufs for, as the clients retransmit me to death. FWIW, I've worked on several FreeBSD based embedded systems products (Whistle was sold to IBM on the basis of one of them), and have always used down rev code to ensure stability. I doubt very much if I will go to 5.0 when/if it becomes available, because the SMP code as is is not addressing anything but small numbers of CPUs, and seems to be ignoring issues that would lead to large numbers of CPUs and/or migration of processes to other nodes within a large cluster. I don't really have faith that it will run 80% faster on an 8-way system than it will on a 4-way, and I expect the lack of interrupt lock-down will make it not as sutable as a uniprocessor system for network processing when PCIX hits general release (8Mbit/S burst rate capable). Count me as another much more interested in the KSE work than the SMP work that has occurred so far (with a few exceptions, like some of the experimental code Alfred has discussed at work). I'd also like to see a port of the KSE stuff to -stable, most particularly if we are not going to see it in 5.0, but even then, it would be useful. I look at the SMPng stuff as research which has yet to prove itself, and would push that further off into the future, or just keep the HEAD as a research branch, and bring in KSE's on the 4.x BRANCH. Switching to using P4 lines Of Developement before the the SMPng started would sure have saved us a lot of pain here... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
On 28-Aug-01 Peter Wemm wrote: Julian Elischer wrote: Actualy peter is most of the way through the alpha support as we speak. I wouldn't know what the alpha looks like from a architecture pov if it came and kicked me.. I did some small parts already but peter just checked in more in P4. Latest news: The alpha made it to single user... (!). There is still a problem, but I will find that shortly. I have not yet built GENERIC, just my tuned kernel. Things like linux and osf1 compat still need doing. FWIW, the tail: ... Timecounter i8254 frequency 1193182 Hz ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed acd0: CDROM CD-540E at ata0-master PIO4 Waiting 2 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318404LW 0006 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: IBM DMVS18V 0250 Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) Mounting root from ufs:/dev/da0a Enter full pathname of shell or RETURN for /bin/sh: # ls halted CPU 0 halt code = 2 kernel stack not valid halt PC = fc553020 You overflowed your kernel stack. You can use srm to dump the memory at that address (I can't remember the stupid SRM syntax for the life of me though) and wade through it looking for kernel-text addresses to figure out the stack trace. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Headsup! KSE Nay-sayers speak up!
Like I said... Count me in... Julian Elischer wrote: Pleas guys, cut it out... Take a copy, run it, beat on it.. let me know if it fails.. thanks.. (p.s. I'll need to put a new patch up because -current has changed.. :-) jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
