HEADS UP: I386_CPU
I've requested a change for UPDATING: The kerrnel option I386_CPU is now mutually exclusive with the other cpu types. If you have an i386 system, be sure that it only had this line. Remove it for all other configurations. Note that this does not remove i386 support. The actual commit message follows: Modified files: sys/i386/confNOTES sys/i386/i386identcpu.c machdep.c pmap.c support.s sys/pc98/confGENERIC sys/pc98/i386machdep.c Log: Stop doing runtime checking on i386 cpus for cpu class. The cpu is slow enough as it is, without having to constantly check that it really is an i386 still. It was possible to compile out the conditionals for faster cpus by leaving out 'I386_CPU', but it was not possible to unconditionally compile for the i386. You got the runtime checking whether you wanted it or not. This change makes I386_CPU mutually exclusive with the other cpu types, and tidies things up a little in the process. Reviewed by: alfred, markm, phk, benno, jlemon, jhb, jake, grog, msmith, jasone, dcs, des (and a bunch more people who encouraged it) Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
Get your own free Internet access at http://www.xsinet.co.za/ Internet communications are not secure and therefore the XSInet does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of XSInet. The XSInet e-mail facility may not be used for the distribution of chain letters or offensive e-mail. XSInet hereby distances itself from and accepts no liability for the unauthorized use of its e-mail facility or the sending of e-mail communications for other than strictly business purposes. Every possible precaution has been taken to ensure that this message is virus free, however XSInet cannot be held responsible for any virus infection occurring as a result of this e-mail message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Mon, 15 Jan 2001, John Baldwin wrote: > On 14-Jan-01 Peter Jeremy wrote: > > And for BDE's benefit - atomic.h is broken for IA32's with 64-bit > > longs. (I believe that can be fixed for Pentiums and above using > > CMPXCHG8B, but I can't test the code). > > The i386 with 64-bit longs doesn't boot from what I hear. Also, long in > machine/types.h is 32-bits long. I don't think we need to bother with 64-bit > longs. Adding 64-bit atomic ops will be expensive on <= 486. It has booted fine for several years. I last built it on 8 Oct 2000. I haven't committed all the bits so it probably doesn't even build in -current. Erm, long isn't in machine/types.h. In , only the long limits in and a few bogus typedefs depend on the size of a long. I bother with 64-bit longs whether I need to or not :-). They get used on i386's mainly in old code and interfaces that don't use typedefs. Hopefully 64-bit scalars will never need to be accessed atomically. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
Wont this make installing using sysinstall a bit hard? I know the generic kernel includes all the CPU lines, so that all cpu's are recognized... so are you going to just take this line out of the generic kernel, and have a special kern.flp disk with a generic kernel that only has the i386 support in it? = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Tue, 16 Jan 2001, Peter Wemm wrote: > I've requested a change for UPDATING: > > The kerrnel option I386_CPU is now mutually exclusive with the > other cpu types. If you have an i386 system, be sure that it > only had this line. Remove it for all other configurations. > > Note that this does not remove i386 support. The actual commit message > follows: > > Modified files: > sys/i386/confNOTES > sys/i386/i386identcpu.c machdep.c pmap.c support.s > sys/pc98/confGENERIC > sys/pc98/i386machdep.c > Log: > Stop doing runtime checking on i386 cpus for cpu class. The cpu is > slow enough as it is, without having to constantly check that it really > is an i386 still. It was possible to compile out the conditionals for > faster cpus by leaving out 'I386_CPU', but it was not possible to > unconditionally compile for the i386. You got the runtime checking whether > you wanted it or not. This change makes I386_CPU mutually exclusive with > the other cpu types, and tidies things up a little in the process. > > Reviewed by: alfred, markm, phk, benno, jlemon, jhb, jake, grog, msmith, > jasone, dcs, des (and a bunch more people who encouraged it) > > Cheers, > -Peter > > > > 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: HEADS UP: I386_CPU
On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote: > Wont this make installing using sysinstall a bit hard? I know the generic > kernel includes all the CPU lines, so that all cpu's are recognized... so > are you going to just take this line out of the generic kernel, and have a > special kern.flp disk with a generic kernel that only has the i386 support > in it? I don't think it's worth the effort. By the time 5.0-RELEASE goes out, the 386 will have been around for over 10 years (actually I think it has already reached that point and gone beyond). There are not likely to be many more installs of FreeBSD on 386's, let alone 5.x installs. People who *really* want to install 5.x on a 386 can generate their own kernel and such. -- wca PGP signature
Re: HEADS UP: I386_CPU
Will Andrews <[EMAIL PROTECTED]> writes: > I don't think it's worth the effort. By the time 5.0-RELEASE goes out, > the 386 will have been around for over 10 years (actually I think it has > already reached that point and gone beyond). It's already more than 15 years old - Intel introduced the 80386 in 1985, and Compaq started shipping 80386-based systems (to IBM's dismay) in 1986. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
OK, but it makes sense to me that for certain applications, it makes sense to utilize the old hardware since it is still readily available and cheap. In particular, why not install FreeBSD on i386 for use in routers? In many cases there is a negligible performance advantage from using faster CPU's. Sure, we can build our own kernels for such applications, but if there is an i386 kernel available, it's a plus for FreeBSD in my opinion. Otherwise I would be inclined to try to put together a "distribution" of FreeBSD optimized for low-end systems. But I suspect PicoBSD already fits that requirement. On Tue, 16 Jan 2001, Will Andrews wrote: > On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote: > > Wont this make installing using sysinstall a bit hard? I know the generic > > kernel includes all the CPU lines, so that all cpu's are recognized... so > > are you going to just take this line out of the generic kernel, and have a > > special kern.flp disk with a generic kernel that only has the i386 support > > in it? > > I don't think it's worth the effort. By the time 5.0-RELEASE goes out, > the 386 will have been around for over 10 years (actually I think it has > already reached that point and gone beyond). There are not likely to be > many more installs of FreeBSD on 386's, let alone 5.x installs. > > People who *really* want to install 5.x on a 386 can generate their own > kernel and such. > > -- > wca > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
OH ok, just curious how that was going to work. = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Tue, 16 Jan 2001, Will Andrews wrote: > On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote: > > Wont this make installing using sysinstall a bit hard? I know the generic > > kernel includes all the CPU lines, so that all cpu's are recognized... so > > are you going to just take this line out of the generic kernel, and have a > > special kern.flp disk with a generic kernel that only has the i386 support > > in it? > > I don't think it's worth the effort. By the time 5.0-RELEASE goes out, > the 386 will have been around for over 10 years (actually I think it has > already reached that point and gone beyond). There are not likely to be > many more installs of FreeBSD on 386's, let alone 5.x installs. > > People who *really* want to install 5.x on a 386 can generate their own > kernel and such. > > -- > wca > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
error while upgrading from 4.1.1 to 4.2 in buildworld
below is the last lines of code in the complier on my box while doing a clean upgrade from 4.1.1 that was installed just days ago. cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DTARGET_NAME=\"i386-unknown-freebsd\" -DIN_GCC -I/usr/obj/usr/src/i386/usr/include -c ../cc_tools/insn-attrtab.c -o insn-attrtab.o cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DTARGET_NAME=\"i386-unknown-freebsd\" -DIN_GCC -I/usr/obj/usr/src/i386/usr/include -c ../cc_tools/insn-emit.c -o insn-emit.o cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DTARGET_NAME=\"i386-unknown-freebsd\" -DIN_GCC -I/usr/obj/usr/src/i386/usr/include -c ../cc_tools/insn-extract.c -o insn-extract.o cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DTARGET_NAME=\"i386-unknown-freebsd\" -DIN_GCC -I/usr/obj/usr/src/i386/usr/include -c ../cc_tools/insn-opinit.c -o insn-opinit.o cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DTARGET_NAME=\"i386-unknown-freebsd\" -DIN_GCC -I/usr/obj/usr/src/i386/usr/include -c ../cc_tools/insn-output.c -o insn-output.o {standard input}: Assembler messages: {standard input}:5945: Error: Rest of line ignored. First ignored character valued 0xb. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. =~=~=~=~=~=~=~=~=~=~=~=~=~=~= Christopher A. Manjoine Webmaster Vice-President for Research The University of Iowa 2 Gilmore Hall Iowa City, IA 52242 Voice: 319-335-3019 Fax: 319-335-2130 Email: [EMAIL PROTECTED] =~=~=~=~=~=~=~=~=~=~=~=~=~=~= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CVSup/buildworld failure
Tuesday, 16 Jan. 2001, about 7am or so, received the following error message(s) from buildworld, after performing a CVSup sometime during the previous day (mid-day or so), while tracking FreeBSD 5.0-CURRENT (output slightly reformatted to correct lines where just one or two characters wouldn't fit on a previous line): - Text Import Begin - ===> sys/boot/i386/btx ===> sys/boot/i386/btx/btx (cd /usr/src/sys/boot/i386/btx/btx; m4 btx.s) | as --defsym BTX_FLAGS=0x0 -o btx.o m4: not found ld -N -e start -Ttext 0x9000 -o btx.out btx.o /usr/obj/usr/src/i386/usr/libexec/elf/ld: warning: cannot find entry symbol start; defaulting to 9000 objcopy -S -O binary btx.out btx ===> sys/boot/i386/btx/btxldr (cd /usr/src/sys/boot/i386/btx/btxldr; m4 -DLOADER_ADDRESS=0x20 btxldr.s ) | as -o btxldr.o m4: not found ld -N -e start -Ttext 0x20 -o btxldr.out btxldr.o /usr/obj/usr/src/i386/usr/libexec/elf/ld: warning: cannot find entry symbol start; defaulting to 0020 objcopy -S -O binary btxldr.out btxldr ===> sys/boot/i386/btx/lib as -elf -o btxcsu.o /usr/src/sys/boot/i386/btx/lib/btxcsu.s as -elf -o btxsys.o /usr/src/sys/boot/i386/btx/lib/btxsys.s as -elf -o btxv86.o /usr/src/sys/boot/i386/btx/lib/btxv86.s ld -elf -i -o crt0.o btxcsu.o btxsys.o btxv86.o ===> sys/boot/i386/boot2 as --defsym FLAGS=0x80 /usr/src/sys/boot/i386/boot2/boot1.s -o boot1.o ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 2>/dev/null cc -elf -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Os -fno-builtin -fforce-addr -fdata-sections -malign-f nctions=0 -malign-jumps=0 -malign-loops=0 -mrtd -mpreferred-stack-boundary=2 -Wall -Waggregate-return -Wbad-f nction-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshado -Wstrict-prototypes -Wwrite-strings -mpreferred-stack-boundary=2 -I/usr/obj/usr/src/i386/usr/include -c /usr src/sys/boot/i386/boot2/boot2.c as --defsym SIOPRT=0x3f8 --defsym SIOFMT=0x3 --defsym SIOSPD=9600 /usr/src/sys/boot/i386/boot2/sio.s -o sioo ld -nostdlib -static -N -Ttext 0x1000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x1000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld: /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx: Not a BTX kernel *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 - Text Import End - Error Codes continued for a few more directory levels before they stopped. I have not been able to buildworld for the last week or so, each time receiving a different kind of error message (and each time after CVSup'ing the latest source). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Dag-Erling Smorgrav writes: > Julian Elischer <[EMAIL PROTECTED]> writes: > > > Something is terribly broken with ng_ether at the moment. It lacks a > > > MODULE_VERSION line. > > is this required for something to be a depency? > > Yes. > > > Where is it documented? > > It's not, AFAIK. UTSL (like the rest of us) I don't think Julian is at fault here. At some point in the past, MODULE_VERSION wasn't required. Whoever committed the checkin that made suddenly made MODULE_VERSION required should have added it to all affected files, or at least there should have been a HEADS UP, but I don't recall seeing one. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
In message <[EMAIL PROTECTED]> Peter Wemm writes: : I've requested a change for UPDATING: It is in my queue... I have a few other entries I need to dust off. I'll try to do that today. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Archie Cobbs <[EMAIL PROTECTED]> writes: > At some point in the past, MODULE_VERSION wasn't required. Whoever > committed the checkin that made suddenly made MODULE_VERSION required > should have added it to all affected files, or at least there should > have been a HEADS UP, but I don't recall seeing one. If I recall correctly, it was Mike, and the commit message was fairly explicit. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[CFR] number of processes forked since boot
Hi, I received the patch to add counter for fork() set from Paul. I've tested it on my -CURRENT and -STABLE boxes, and it seems fine for me. So, I post his patch for review. Thanks, Paul. fork.patch.gz Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/
Re: sysinstall.8 Breaking buildworld
In message <[EMAIL PROTECTED]> "David O'Brien" writes: : But disklabel/fdisk can't even accept MB's as a unit. Until they grow : the functionality of the NetBSD and OpenBSD versions of them, sysinstall : is really the only tolerable disk label manipulation tool our users have. : This includes those with a bummed /usr that needs to install a new disk : to get it back. I have patches in my tree from someone to do this the last time this issue came up. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] number of processes forked since boot
* Hajimu UMEMOTO <[EMAIL PROTECTED]> [010116 10:33] wrote: > Hi, > > I received the patch to add counter for fork() set from Paul. I've > tested it on my -CURRENT and -STABLE boxes, and it seems fine for me. > So, I post his patch for review. > > Thanks, Paul. I like this a lot. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
Bruce Evans wrote: > > On Mon, 15 Jan 2001, John Baldwin wrote: > > > On 14-Jan-01 Peter Jeremy wrote: > > > And for BDE's benefit - atomic.h is broken for IA32's with 64-bit > > > longs. (I believe that can be fixed for Pentiums and above using > > > CMPXCHG8B, but I can't test the code). > > > > The i386 with 64-bit longs doesn't boot from what I hear. Also, long in > > machine/types.h is 32-bits long. I don't think we need to bother with 64-bit > > longs. Adding 64-bit atomic ops will be expensive on <= 486. > > It has booted fine for several years. I last built it on 8 Oct 2000. I > haven't committed all the bits so it probably doesn't even build in -current. > > Erm, long isn't in machine/types.h. In , only the long limits in > and a few bogus typedefs depend on the size of a long. > > I bother with 64-bit longs whether I need to or not :-). They get used on > i386's mainly in old code and interfaces that don't use typedefs. > Hopefully 64-bit scalars will never need to be accessed atomically. Too late. Many statistics in interfaces (i.e. bytes transmitted) are already 64 bit words. > > Bruce > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
confidential business relationship
FROM:DR.UBA JEGA. SATELLITE TEL.871-761--31. SATELLITE FAX.871-761--32. ATTN:PRESIDENT/CEO. STRICTLY CONFIDENTIAL & URGENT BUSINESS PROPOSAL. RE:TRANSFER OF U$21,500.000{TWENTY ONE MILLION FIVE HUNDRED THOUSAND US DOLLARS ONLY. I AM A MEMBER OF THE FEDERAL GOVERNMENT OF NIGERIA NATIONAL PETROLEUM CORPORATION(NNPC) SOMETIME AGO, A CONTRACT WAS AWARDED TO A FOREIGN FIRM IN THE PTF BY MY COMMITTEE. THIS CONTRACT WAS OVER INVOICED TO THE TUNE OF US$21.5M US DOLLARS. THIS WAS DONE DELIBRATELY. THE OVER- INVOICING WAS A DEAL BY MY COMMITTEE TO BENEFIT FROM THE PROJECT. WE NOW WANT TO TRANSFER THIS MONEY WHICH IS IN A SUSPENSE ACCOUNT WITH PTF INTO ANY OVERSEA ACCOUNT WHICH WE EXPECT YOU TO PROVIDE FOR US. SHARE: 60% WILL BE FOR MY PARTNERS AND ME. 30% OF THE MONEY WILL BE YOURS FOR PROVIDING THE ACCOUNT WHERE WE SHALL REMIT THE MONEY. 10% HAS BEEN MAPPED OUT FROM THE TOTAL SUM TO COVER ANY EXPENSES THAT MAY BE INCURRED BY US DURING THE COURSE OF THIS TRANSFER, BOTH LOCAL AND INTERNATIONAL EXPENSES. IT MAY INTEREST YOU TO KNOW THAT SIMILAR TRANSACTION WAS CARRIED OUT WITH ONE MR. PATRICE MILLER, PRESIDENT OF CRANE INTERNATIONAL TRADING CORP. OF 153 EAST 57TH ST; 28TH FLOOR, NY10022, TELEPHONE: 212-3087788 AND TELEX:6731689. THE DEAL WAS CONCLUDED AND ALL COVERING DOCUMENTS WERE FOWARDED TO MR. MILLER TO AUTHENTICATE THE CLAIM. ONCE THE FUNDS WERE TRANSFERRED, MR. MILLER PRESENTED HIS BANK WITH ALL THE LEGAL DOCUMENTS AND REMITTED THE WHOLE FUNDS TO ANOTHER BANK ACCOUNT AND DISAPPEARED COMPLETELY. MY COLLEAGUES WERE SHATTERED, SINCE SUCH OPPORTUNITIES ARE NOT EASY TO COME BY. AT THIS JUNCTURE, I WOULD LIKE TO LET YOU KNOW THAT IF YOU ARE INTERESTED IN ASSISTING US IN THIS DEAL, WE WOULD REQUIRE THE FOLLOWING INFORMATION FROM YOU, WHICH WOULD ENABLE US MAKE FORMAL APPLICATION TO THE VARIOUS MINISTRIES\PARASTATAL FOR THE RELEASE AND ONWARD TRANSFER OF THE MONEY TO YOUR ACCOUNT. THE INFORMATION WE REQUIRE ARE: YOUR NAME, COMPANY`S NAME, ADDRESS , TELEFAX NUMBER. YOUR BANK NAME ,ADDRESS, TELEFAX NUMBER. YOUR BANK ACCOUNT NUMBER AND BENEFICIARY NAME. WE HAVE STRONG RELIABLE CONNECTIONS AT THE CENTRAL BANK OF NIGERIA AND OTHER GOVERNMENT PARASTATALS TO ASSIST US IN THE DEAL, AND WHEN IT IS FINALLY CONCLUDED WE SHALL USE SAME CONTACTS TO WITHDRAW ALL DOCUMENTS USED TO AVOID ANY TRACE TO YOU OR US. IT MIGHT ALSO INTEREST YOU TO KNOW THAT WE ARE ORDINARY CIVIL SERVANTS WHO DO NOT WANT TO MISS THIS OPPORTUNITY, SINCE WE WANT THIS MONEY TRANSFERRED BEFORE THE NEWLY DEMOCRATICALLY ELECTED GOVERNMENT STARTS PROBING THE ACTIVITIES OF ALL PREVIOUS MILITARY GOVERNMENTS. PLEASE CONTACT ME THROUGH MY ABOVE TEL\FAX NUMBER WHETHER OR NOT YOU ARE INTRESTED IN THIS DEAL. IF YOU ARE NOT IT WILL ENABLE ME SCOUT FOR ANOTHER FOREIGN PARTNER TO ASSIST US. BUT IF YOU ARE INTRESTED PLEASE SEND THE REQUIRED INFORMATION IMMEDIATELY SO THAT WE CAN SWING INTO ACTION, SINCE TIME IS NOT ON OUR PART. I WAIT IN ANTICIPATION OF YOUR FULLEST CO-COPERATION. YOURS FAITHFULLY, DR.UBA JEGA. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Dag-Erling Smorgrav writes: > > At some point in the past, MODULE_VERSION wasn't required. Whoever > > committed the checkin that made suddenly made MODULE_VERSION required > > should have added it to all affected files, or at least there should > > have been a HEADS UP, but I don't recall seeing one. > > If I recall correctly, it was Mike, and the commit message was fairly > explicit. It seems like fairly explicit commit message wasn't sufficient then. Whatever.. developers should pay more attention and committers should be more explicit. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
modified ich sound driver for current?
Mixer stuff was modified couple days ago. Does anyone have working ich driver? I got original driver from http://www.katsurajima.seya.yokohama.jp/ich/index.en.html but now this site is dead. Does author (Katsurajima Naoto) of this driver read FreeBSD mailing lists? Could someone include this driver to current so it get updated? -- SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: [EMAIL PROTECTED]+358 9 52556252 fax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup/buildworld failure
-current with sources as of 1 a.m. PST 1/16/01 built okay for me, and runs fine. Annelise On Tue, 16 Jan 2001, Nate Dannenberg wrote: > > Tuesday, 16 Jan. 2001, about 7am or so, received the following error > message(s) from buildworld, after performing a CVSup sometime during the > previous day (mid-day or so), while tracking FreeBSD 5.0-CURRENT (output > slightly reformatted to correct lines where just one or two characters > wouldn't fit on a previous line): > > - Text Import Begin - > ===> sys/boot/i386/btx > ===> sys/boot/i386/btx/btx > (cd /usr/src/sys/boot/i386/btx/btx; m4 btx.s) | as --defsym BTX_FLAGS=0x0 -o btx.o > m4: not found > ld -N -e start -Ttext 0x9000 -o btx.out btx.o > /usr/obj/usr/src/i386/usr/libexec/elf/ld: warning: cannot find entry symbol start; >defaulting to 9000 > objcopy -S -O binary btx.out btx > ===> sys/boot/i386/btx/btxldr > (cd /usr/src/sys/boot/i386/btx/btxldr; m4 -DLOADER_ADDRESS=0x20 btxldr.s ) | as > -o btxldr.o > m4: not found > ld -N -e start -Ttext 0x20 -o btxldr.out btxldr.o > /usr/obj/usr/src/i386/usr/libexec/elf/ld: warning: cannot find entry symbol start; >defaulting to 0020 > objcopy -S -O binary btxldr.out btxldr > ===> sys/boot/i386/btx/lib > as -elf -o btxcsu.o /usr/src/sys/boot/i386/btx/lib/btxcsu.s > as -elf -o btxsys.o /usr/src/sys/boot/i386/btx/lib/btxsys.s > as -elf -o btxv86.o /usr/src/sys/boot/i386/btx/lib/btxv86.s > ld -elf -i -o crt0.o btxcsu.o btxsys.o btxv86.o > ===> sys/boot/i386/boot2 > as --defsym FLAGS=0x80 /usr/src/sys/boot/i386/boot2/boot1.s -o boot1.o > ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o > objcopy -S -O binary boot1.out boot1 > dd if=/dev/zero of=boot2.ldr bs=512 count=1 2>/dev/null > cc -elf -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Os -fno-builtin >-fforce-addr -fdata-sections -malign-f > nctions=0 -malign-jumps=0 -malign-loops=0 -mrtd -mpreferred-stack-boundary=2 >-Wall -Waggregate-return -Wbad-f > nction-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes >-Wnested-externs -Wpointer-arith -Wshado > -Wstrict-prototypes -Wwrite-strings -mpreferred-stack-boundary=2 >-I/usr/obj/usr/src/i386/usr/include -c /usr > src/sys/boot/i386/boot2/boot2.c > as --defsym SIOPRT=0x3f8 --defsym SIOFMT=0x3 --defsym SIOSPD=9600 >/usr/src/sys/boot/i386/boot2/sio.s -o sioo > ld -nostdlib -static -N -Ttext 0x1000 -o boot2.out > /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot.o sio.o > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x1000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l >boot2.ldr -o > boot2.ld -P 1 > boot2.bin > btxld: /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx: Not a BTX kernel > *** Error code 1 > > Stop in /usr/src/sys/boot/i386/boot2. > *** Error code 1 > - Text Import End - > > Error Codes continued for a few more directory levels before they stopped. > I have not been able to buildworld for the last week or so, each time > receiving a different kind of error message (and each time after CVSup'ing > the latest source). > > > > 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: [CFR] number of processes forked since boot
On Wed, 17 Jan 2001, Hajimu UMEMOTO wrote: > I received the patch to add counter for fork() set from Paul. I've > tested it on my -CURRENT and -STABLE boxes, and it seems fine for me. > So, I post his patch for review. I do have a change (I knew I forgot something.) This is exactly the same patch, but counts kernel thread forks to boot. I've tested it on -CURRENT and seems fine for me as well. -Paul. fork_kthreads.patch.gz
Re: modified ich sound driver for current?
> Mixer stuff was modified couple days ago. Does anyone have working > ich driver? I got original driver from more than that, a couple of weeks would be closer. > http://www.katsurajima.seya.yokohama.jp/ich/index.en.html but now this > site is dead. Does author (Katsurajima Naoto) of this driver read > FreeBSD mailing lists? Could someone include this driver to current > so it get updated? i'm not happy with some of the things the driver does, so until i can modify it i won't commit it. this necessitates having hardware to test with, which i should be getting in the near future. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: modified ich sound driver for current?
Howdy, I modified the mentioned driver when newpcm got kobjified and submitted the patches back to the author. I didn't get a reply. I haven't synced up my laptop to current since about the new year, so I don't know if it works with any changes made. Rather than send the patch to the list, I'll e-mail it to anyone that asks. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Tomi > Vainio - Sun > Finland - > Sent: Wednesday, 17 January 2001 8:56 > To: [EMAIL PROTECTED] > Subject: modified ich sound driver for current? > > > Mixer stuff was modified couple days ago. Does anyone have working > ich driver? I got original driver from > http://www.katsurajima.seya.yokohama.jp/ich/index.en.html but now this > site is dead. Does author (Katsurajima Naoto) of this driver read > FreeBSD mailing lists? Could someone include this driver to current > so it get updated? > > -- > SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 > ESPOO, Finland > Tomi Vainio (System Support Engineer) +358 9 52556300 hotline > email: [EMAIL PROTECTED]+358 9 52556252 fax > > > 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
Scam warning, was Re: confidential business relationship
I hope I don't offend anyones intelligence... This is a typical Nigerian 4-1-9 scam. To read more, just do a search on google: http://www.google.com/search?q=nigeria+scam+4+1+9 Leif - Original Message - From: "jega uba" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 16, 2001 10:24 PM Subject: confidential business relationship > FROM:DR.UBA JEGA. > SATELLITE TEL.871-761--31. > SATELLITE FAX.871-761--32. > > ATTN:PRESIDENT/CEO. > > STRICTLY CONFIDENTIAL & URGENT BUSINESS PROPOSAL. > > RE:TRANSFER OF U$21,500.000{TWENTY ONE MILLION FIVE > HUNDRED THOUSAND US DOLLARS ONLY. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
* Archie Cobbs <[EMAIL PROTECTED]> [010116 13:39] wrote: > Dag-Erling Smorgrav writes: > > > At some point in the past, MODULE_VERSION wasn't required. Whoever > > > committed the checkin that made suddenly made MODULE_VERSION required > > > should have added it to all affected files, or at least there should > > > have been a HEADS UP, but I don't recall seeing one. > > > > If I recall correctly, it was Mike, and the commit message was fairly > > explicit. > > It seems like fairly explicit commit message wasn't sufficient then. > Whatever.. developers should pay more attention and committers should > be more explicit. ~ % man 9 module No entry for module in section 9 of the manual ~ % man 9 MODULE No entry for MODULE in section 9 of the manual ~ % man 9 MODULE_VERSION No entry for MODULE_VERSION in section 9 of the manual ? This ought to be documented. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
I'm sorry guys, I haven't been really "up-to-date" on this thread, but I was wondering: can config be made to define I386_CPU 0 if any other cpus are defined (or the inverse behavior)? (Maybe this was already done?) In the sysinstall case, I think it's safe to just exclude all other processors and use the slower I386_CPU kernel. Since the GENERIC kernel config file may contain all of the different CPU types, the config hack may ensure that we're excluding I386_CPU code. Cheers, Bosko. Warner wrote: > In message <[EMAIL PROTECTED]> Peter Wemm writes: > : I've requested a change for UPDATING: > > It is in my queue... I have a few other entries I need to dust off. > I'll try to do that today. > > Warner > > > 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: Atomic breakage?
On Tue, 16 Jan 2001, Julian Elischer wrote: > Bruce Evans wrote: > > I bother with 64-bit longs whether I need to or not :-). They get used on > > i386's mainly in old code and interfaces that don't use typedefs. > > Hopefully 64-bit scalars will never need to be accessed atomically. > > Too late. > > Many statistics in interfaces (i.e. bytes transmitted) are already 64 bit > words. These don't use atomic operations (hint: no 64-bit atomic operations are implemented on i386's). If they need to be atomic, then they must use locks. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
* Bruce Evans <[EMAIL PROTECTED]> [010116 19:03] wrote: > On Tue, 16 Jan 2001, Julian Elischer wrote: > > > Bruce Evans wrote: > > > I bother with 64-bit longs whether I need to or not :-). They get used on > > > i386's mainly in old code and interfaces that don't use typedefs. > > > Hopefully 64-bit scalars will never need to be accessed atomically. > > > > Too late. > > > > Many statistics in interfaces (i.e. bytes transmitted) are already 64 bit > > words. > > These don't use atomic operations (hint: no 64-bit atomic operations are > implemented on i386's). If they need to be atomic, then they must use > locks. Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'? add longword, add longword with carry? I know it would be pretty ugly, but it should work, no? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 2001-Jan-16 19:10:10 -0800, Alfred Perlstein <[EMAIL PROTECTED]> wrote: >* Bruce Evans <[EMAIL PROTECTED]> [010116 19:03] wrote: >> These don't use atomic operations (hint: no 64-bit atomic operations are >> implemented on i386's). If they need to be atomic, then they must use >> locks. > >Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'? >add longword, add longword with carry? I know it would be pretty >ugly, but it should work, no? It's not an atomic update because each longword is being updated independently: A reader can access the object between the low word and high word being updated and see an inconsistent result. If you don't need to support multiple bus masters, then the best you can achieve is: "di; addl; adcl; ei" - you don't need the lock prefixes. To support multiple masters, you need proper locks. Since SMP isn't supported on the 80386, as long as you don't to DMA to/from 64-bit objects you can get away with the "di; addl; adcl; ei" sequence. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Thanks to everyone
Hi all I managed to compile my kernel and include the pcm device with no hang-ups. Thanks for all the responses I got from all of you ! I just refreshed my source tree with the latest STABLE and recompiled it without all the stuff I don't need but including my pcm device --- and it WORKED Now I can play MP3's while coding :) Thanks all Adriaan --- I would change the world, but God would never give me the source code.
Re: modified ich sound driver for current?
Cameron Grant writes: > > i'm not happy with some of the things the driver does, so until i can modify > it i won't commit it. this necessitates having hardware to test with, which > i should be getting in the near future. > Nice to know that someone is even thinking about what to do with this driver. Chris Knight writes: > > I modified the mentioned driver when newpcm got kobjified and submitted the > patches back to the author. I didn't get a reply. I haven't synced up my > laptop to current since about the new year, so I don't know if it works with > any changes made. Rather than send the patch to the list, I'll e-mail it to > anyone that asks. > Your modification worked just fine and my laptop is back in business. Tomppa -- SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: [EMAIL PROTECTED]+358 9 52556252 fax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message