Find Out ANYTHING About ANYONE!!!
THIS NEW AMAZING SOFTWARE TOOL HELPS YOU FIND OUT ALMOST ANYTHING ABOUT ANYONE - CLICK ON URL BELOW TO VISIT OUR WEBSITE http://www.canadianwebs.com/hf/syurown/ ** Find out almost EVERYTHING you ever wanted to know about: Your friends Your family Your enemies Your employees Yourself - Is Someone Using Your Identity? Even your boss! DID YOU KNOW you can search for ANYONE, ANYTIME, ANYWHERE, right on the Internet.. This mammoth COLLECTION of Internet investigative tools & research sites will provide you with NEARLY 400 GIGANTIC SEARCH RESOURCES to locate information on: People you trust Screen new tenants or roommates Housekeepers Current or past employment People you work with License plate number with name and address Unlisted phone numbers Long lost friends A new or old LOVE INTEREST You can even VERIFY your own CREDIT REPORTS so you can correct WRONG information These are only a few things you can do, There is no limit to the power of this information tool!! CLICK ON URL BELOW TO VISIT OUR WEBSITE http://www.canadianwebs.com/hf/syurown/ ** To be removed from our mailing list, click below mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: today's -current xl0 wigs out
Well getting rid of the leftover splimp() didn't clear up the problem. Maybe we need to move the mtx_init and XL_LOCK up to where the splimp() was. Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: today's -current xl0 wigs out
Mark Hittinger writes: > Upon an 'ifconfig xl0' the kernel hangs. If I don't ifconfig xl0 I can > still use pppd ok. Well, you're not alone. I note that the same code works fine in my machine with an fxp.
re: today's -current xl0 wigs out
In if_xl.c at the very beginning of xl_attach() it looks like there is a leftover splimp(). Bill seems to have replaced all the others with a LOCK macro. Further down in xl_attach there is a LOCK macro so maybe we just have to remove that leftover splimp(). Trying that now. Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
> > >
> > > I thought you could get that information with sched_get_priority_min()
> > > and sched_get_priority_max(). Is that not the case?
> >
> > Not really. Those return the kernels POSIX priority range for
> > processes.
>
> Hmm, that's not how I interpret the POSIX spec. Here are some
> excerpts from section 13.2, "Scheduling Policies". That's in the
> chapter which describes all of the sched_XXX() functions.
>
> This model discusses only processor scheduling for runnable
> threads ...
>
> There is, conceptually, one thread list for each priority. Any
> runnable thread may be on any thread list. Multiple scheduling
> policies shall be provided. Each nonempty thread list is
> ordered, contains a head as one end of its order, and a tail as
> the other. The purpose of a scheduling policy is to define the
> allowable operations on this set of lists.
>
> Each process shall be controlled by an associated scheduling
> policy and priority. These parameters may be specified by
> explicit application execution of the sched_setscheduler() or
> sched_setparam() functions.
>
> Each thread shall be controlled by an associated scheduling
> policy and priority. These parameters may be specified by
> explicit application execution of the pthread_setschedparam()
> function.
So far I read this as saying the sched_XXX functions operate
on processes, whereas the pthread_{set|get}schedparam
functions operate on threads.
>
> And then in the discussion of the SCHED_FIFO scheduling policy in
> section 13.2.1, it says:
>
> (4) When a running thread calls the sched_setparam() function,
> the priority of the process specified in the function call is
> modified to the priority specified by the param argument.
> If the thread whose priority has been modified is a running
> thread or is runnable, runnable thread [sic] it then becomes
> the tail of the thread list for its new priority.
This contradicts itself and is where I think it is unclear. Where
does it state that the _threads_ priority is modified? It only
says that the process priority is modified. When it goes on to
say "If the thread whose priority has been modified...", it's
assuming something that was never stated as a requirement.
> (5) When a running thread calls the pthread_setschedparam()
> function, the thread specified in the function call is
> modified to the specified policy and the priority specified by
> the param argument.
The above is a clearly stated requirement. If they had meant for
the threads priority to be changed by sched_setparam(), then it
should have been stated just as it has been above (5).
> (6) If a thread whose policy or priority has been modified is
> a running thread or is runnable, runnable thread [sic] it then
> becomes the tail of the thread list for its new priority.
Unless it holds a priority protection or inheritence mutex, in
which case it gets added to the head of the thread list for its
new priority. This case is often forgotten (see 13.6.1.2).
> ...
>
> For this policy, valid priorities shall be within the range
> returned by the function sched_get_priority_max() and
> sched_get_priority_min() when SCHED_FIFO is provided as the
> parameter.
>
> So it seems clear that the same range of priorities shall apply to
> individual threads as well as to processes. (SCHED_RR is similar in
> these respects.)
For SCHED_FIFO and SCHED_RR, we don't have a problem because both
the threads library and kernel now agree that the range is 0..31.
SCHED_OTHER is a problem because the threads library treats
SCHED_OTHER as SCHED_RR with range 0..31. The kernel treats
SCHED_OTHER traditionally with range -20..20.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
today's -current xl0 wigs out
Upon an 'ifconfig xl0' the kernel hangs. If I don't ifconfig xl0 I can still use pppd ok. pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: at 7.3 pci0: at 10.0 irq 11 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0x6400-0x643f irq 10 at device 12.0 on pci0 xl0: Ethernet address: 00:60:08:15:f9:49 miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto FYI Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
system lockups in -current - during boot.
I'm getting hard lockups booting a -current kernel supped about 6 hours ago. If I try to boot multiuser, I get a message about the ethernet interface being configured, and then nothing. If I boot single user, it comes up fine, and I can configure the NIC. The system then locks up maybe 10 seconds later, doing nothing but tapping return every so often. I don't get enough response to start a debugger in either case. The best data I can contribute is a dmesg from the same hardware booting -stable. Suggestions? Pointers? Fixes? Oct 14 23:27:24 eve /kernel: AMD Features=0x8800 Oct 14 23:27:24 eve /kernel: real memory = 67043328 (65472K bytes) Oct 14 23:27:24 eve /kernel: avail memory = 62480384 (61016K bytes) Oct 14 23:27:24 eve /kernel: Preloaded elf kernel "kernel" at 0xc02d3000. Oct 14 23:27:24 eve /kernel: K6-family MTRR support enabled (2 registers) Oct 14 23:27:24 eve /kernel: npx0: on motherboard Oct 14 23:27:24 eve /kernel: npx0: INT 16 interface Oct 14 23:27:24 eve /kernel: pcib0: on motherboard Oct 14 23:27:24 eve /kernel: pci0: on pcib0 Oct 14 23:27:24 eve /kernel: pcib2: at device 1.0 on pci0 Oct 14 23:27:24 eve /kernel: pci1: on pcib2 Oct 14 23:27:24 eve /kernel: pci1: at 0.0 irq 11 Oct 14 23:27:24 eve /kernel: isab0: at device 7.0 on pci0 Oct 14 23:27:24 eve /kernel: isa0: on isab0 Oct 14 23:27:24 eve /kernel: atapci0: port 0xe000-0xe00f at device 7.1 on pci0 Oct 14 23:27:24 eve /kernel: ata0: at 0x1f0 irq 14 on atapci0 Oct 14 23:27:24 eve /kernel: ata1: at 0x170 irq 15 on atapci0 Oct 14 23:27:24 eve /kernel: uhci0: port 0xe400-0xe41f irq 10 at device 7.2 on pci0 Oct 14 23:27:24 eve /kernel: usb0: on uhci0 Oct 14 23:27:24 eve /kernel: usb0: USB revision 1.0 Oct 14 23:27:24 eve /kernel: uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Oct 14 23:27:24 eve /kernel: uhub0: 2 ports with 2 removable, self powered Oct 14 23:27:24 eve /kernel: ugen0: Diamond Multimedia Systems, Inc. SupraExpress 56e USB V.90, rev 1.00/1.00, addr 2 Oct 14 23:27:24 eve /kernel: xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe800-0xe87f mem 0xeb00-0xeb7f irq 5 at device 10.0 on pci0 Oct 14 23:27:24 eve /kernel: xl0: Ethernet address: 00:50:04:84:ac:f1 Oct 14 23:27:24 eve /kernel: miibus0: on xl0 Oct 14 23:27:24 eve /kernel: xlphy0: <3Com internal media interface> on miibus0 Oct 14 23:27:24 eve /kernel: xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Oct 14 23:27:24 eve /kernel: pci0: (vendor=0x1274, dev=0x5000) at 12.0 irq 5 Oct 14 23:27:24 eve /kernel: pcib1: on motherboard Oct 14 23:27:24 eve /kernel: pci2: on pcib1 Oct 14 23:27:24 eve /kernel: fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 Oct 14 23:27:24 eve /kernel: fdc0: FIFO enabled, 8 bytes threshold Oct 14 23:27:24 eve /kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Oct 14 23:27:24 eve /kernel: atkbdc0: at port 0x60,0x64 on isa0 Oct 14 23:27:24 eve /kernel: atkbd0: flags 0x1 irq 1 on atkbdc0 Oct 14 23:27:24 eve /kernel: kbd0 at atkbd0 Oct 14 23:27:24 eve /kernel: psm0: irq 12 on atkbdc0 Oct 14 23:27:24 eve /kernel: psm0: model Generic PS/2 mouse, device ID 0 Oct 14 23:27:24 eve /kernel: vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Oct 14 23:27:24 eve /kernel: sc0: at flags 0x100 on isa0 Oct 14 23:27:24 eve /kernel: sc0: VGA <16 virtual consoles, flags=0x300> Oct 14 23:27:24 eve /kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Oct 14 23:27:24 eve /kernel: sio0: type 16550A Oct 14 23:27:24 eve /kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Oct 14 23:27:24 eve /kernel: sio1: type 16550A Oct 14 23:27:24 eve /kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Oct 14 23:27:24 eve /kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Oct 14 23:27:24 eve /kernel: ppc0: FIFO with 16/16/16 bytes threshold Oct 14 23:27:24 eve /kernel: lpt0: on ppbus0 Oct 14 23:27:24 eve /kernel: lpt0: Interrupt-driven port Oct 14 23:27:24 eve /kernel: ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable Oct 14 23:27:24 eve /kernel: ad0: 9765MB [19841/16/63] at ata0-master using UDMA33 Oct 14 23:27:24 eve /kernel: ata1-master: DMA limited to UDMA33, non-ATA66 compliant cable Oct 14 23:27:24 eve /kernel: ad2: 19541MB [39704/16/63] at ata1-master using UDMA33 Oct 14 23:27:24 eve /kernel: acd0: CDROM at ata1-slave using PIO4 Oct 14 23:27:24 eve /kernel: Mounting root from ufs:/dev/ad0s2a Oct 14 23:27:24 eve /kernel: IP packet filtering initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled Oct 14 18:27:33 eve login: ROOT LOGIN (root) ON ttyv0 Oct 14 18:28:13 eve su: mwm to root on /dev/ttyp0 Oct 14 21:25:13 eve /kernel: WARNING: R/W mount of /usr denied. Filesystem is not clean - run fsck Oct 14 21:34:22 eve shutdown: reboot by mwm: Oct 14 21:34:25 eve syslogd: exiting on signal 15 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
At Sat, 14 Oct 2000 13:57:07 -0700 (PDT), Matthew Jacob <[EMAIL PROTECTED]> wrote: > > I had asked for a 3rd floppy earlier that we could put f/w images and other > drivers on. Now that we have a mostly loadable system, it strikes me that this > would be an excellent time to trim down the GENERIC to the common denominator > per-platform and then have compressed driver images available on a 3rd floppy > if people need them. It's a nice idea, but this means that boot.flp can exceed 2.88MB limit. As far as I know, the maximum size of boot image of El-Torito bootable CD-ROM is 2.88MB. When I install from CD-ROM, I have to enable ATAPI or SCSI drivers first, and then load Network dirvers and so on. When I install from the net, I have to enable Ethernet, PLIP or PPP drivers first, and then load ATAPI or SCSI drivers and so on. Currently, sysinstall supports two types of install media: local media and remote media. Boot.flp should be capable of loading drivers from the install media. Local media installation: Disk1-1: kernel, atapi + scsi drivers Disk2: sysinstall and utilities Disk3: driver disk Remote media installation: Disk1-2: kernel, network drivers Disk2: sysinstall and utilities Disk3: driver disk I think that disk 2 and 3 can be shared by them. Sysinstall have to ask user about installation media first, and then get compressed *.ko modules from the installation media. P.S.: Japanese/Korean boot.flp for 4.1.1 will be available in a few days (test version is available at http://people.freebsd.org/~hosokawa/boot-ja/), and I believe that it can be ported to -current easily, but it needs pty support in the Disk1 currently -- --- Tatsumi Hosokawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/i386/include endian.h
In article <[EMAIL PROTECTED]> you wrote: > brian 2000/10/14 17:45:19 PDT > > Modified files: > sys/i386/include endian.h > Log: > Redefine __word_swap_long, __byte_swap_long and __byte_swap_word > as inline functions, renaming them to __uint16_swap_uint32, > __uint8_swap_uint32 and __uint8_swap_uint16. > > Doing it properly suggested by: msmith > Reviewed by: msmith > > Revision ChangesPath > 1.19 +33 -36src/sys/i386/include/endian.h After this commit 'make buildworld' breaks in 'src/lib/msun/src'. I can 'make all' in the 'src/lib/msun' directory after the next patch: Index: math_private.h === RCS file: /scratch/CVS/src/lib/msun/src/math_private.h,v retrieving revision 1.6 diff -b -u -r1.6 math_private.h --- math_private.h 1999/08/28 00:06:43 1.6 +++ math_private.h 2000/10/15 02:52:59 @@ -17,8 +17,8 @@ #ifndef _MATH_PRIVATE_H_ #define _MATH_PRIVATE_H_ -#include #include +#include /* The original fdlibm code used statements like: n0 = ((*(int*)&one)>>29)^1; * index of high word * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
> > > > The problem with such an approach is that it's not very user-friendly > > > to first-time installers who have no idea how to drive the loader. > > > > Most of the relevant modules can actually be tried by sysinstall. In the > > CD case we can just put them on the CDROM. I'd be inclined to look for > > somewhere that you can fit ~110k and put nfs.ko.gz there. 8) > > I was thinking about making sure that drivers that would get you to your > install media would be what you'd load- nothing else. This would include > network drivers... That'd work; we could offload a lot of storage drivers (CAM, RAID, etc are all loadable...) -- ... 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: Our kernel just got too big again. :)
> The problem with such an approach is that it's not very user-friendly > to first-time installers who have no idea how to drive the loader. Most of the relevant modules can actually be tried by sysinstall. In the CD case we can just put them on the CDROM. I'd be inclined to look for somewhere that you can fit ~110k and put nfs.ko.gz there. 8) -- ... 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: Our kernel just got too big again. :)
> > The problem with such an approach is that it's not very user-friendly > > to first-time installers who have no idea how to drive the loader. > > Most of the relevant modules can actually be tried by sysinstall. In the > CD case we can just put them on the CDROM. I'd be inclined to look for > somewhere that you can fit ~110k and put nfs.ko.gz there. 8) I was thinking about making sure that drivers that would get you to your install media would be what you'd load- nothing else. This would include network drivers... > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcmcia and ed
In message <[EMAIL PROTECTED]> Alexander Langer writes: : Thus spake Warner Losh ([EMAIL PROTECTED]): : : > The module name should be if_ed. I'll go fix it. : : Did you do this already? : : And if so, where? No. I haven't. I just spend a fair amount of time wonking on a current -current kernel to get any ed card to work. looks like interrupts just aren't happening at all :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
> > Hmm?... my forth is poor, but I don't believe that's the issue. If I > > understand how the floppies currently work is that it's just like our normal > > boot loader- we start coming up. If you want to load other drivers or modules > > (like ispfw), you hit the 'other than Enter' to stop the loading progress, > > switch floppies and load ispfw, davicom ethernet, a splash screen with > > jordan's face, whatever...then you type 'boot'- then the normal mfsroot flopp > > The problem with such an approach is that it's not very user-friendly > to first-time installers who have no idea how to drive the loader. > Let's not forget the linux installation floppy saga and all the > confusion it's caused people just in trying to figure out which > floppies to use. That would be where the forth hackery comes in - an > additional set of menu options which make it a no-brainer to insert the > kernel module floppy. Okay. It's your thuktun, as Niven would write > > > you're sure this doesn't work. If you're email to -current was "only answers > > with patches against -current will be heard", you really should have said so. > > No, that wasn't the point of my email. My email was originally > intended to solicit suggestions about options to remove from the > kernel so that the *existing* mechanism would go back to working > again. Adding a 3rd floppy to the mix is an option which has occurred > to all of us at one time or another and even been a topic for fierce > debate in the FreeBSD mailing lists. I would have preferred not to go > there in this thread. :) Okay. I have no suggestions as to what to remove then. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
> Hmm?... my forth is poor, but I don't believe that's the issue. If I > understand how the floppies currently work is that it's just like our normal > boot loader- we start coming up. If you want to load other drivers or modules > (like ispfw), you hit the 'other than Enter' to stop the loading progress, > switch floppies and load ispfw, davicom ethernet, a splash screen with > jordan's face, whatever...then you type 'boot'- then the normal mfsroot flopp The problem with such an approach is that it's not very user-friendly to first-time installers who have no idea how to drive the loader. Let's not forget the linux installation floppy saga and all the confusion it's caused people just in trying to figure out which floppies to use. That would be where the forth hackery comes in - an additional set of menu options which make it a no-brainer to insert the kernel module floppy. > you're sure this doesn't work. If you're email to -current was "only answers > with patches against -current will be heard", you really should have said so. No, that wasn't the point of my email. My email was originally intended to solicit suggestions about options to remove from the kernel so that the *existing* mechanism would go back to working again. Adding a 3rd floppy to the mix is an option which has occurred to all of us at one time or another and even been a topic for fierce debate in the FreeBSD mailing lists. I would have preferred not to go there in this thread. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removing global from tree
On 14-Oct-00 Gerhard Sittig wrote: > On Sat, Oct 14, 2000 at 11:16 -0700, John Baldwin wrote: >> >> On 14-Oct-00 Gerhard Sittig wrote: >> > >> > Up to now I always thought "the Attic" is something CVS >> > itself takes care of when "cvs rm"ing files. What's that >> > special thing needing manual intervention or special >> > attention you've been talking about lately? Is it for >> > performance reasons or for the warm fuzzy feelings of having >> > "not too rotten a repo"? >> >> It is where CVS puts files when you cvs rm them. You just have >> to do the actual cvs rm/cvs ci. David was cautious because if >> he had to back the change out, he didn't want to have to try to >> cvs add all of the files back in. > > Isn't it true that all the "log", "diff", "up -r" and such > commands still work in the expected way? That's the reason for > having "the Attic", I thought. Not to remove the repo file when > the working file expires, but to keep the history and to restore > any previous revision thereof when requested. Backing out an > rm'ed file should be as difficult as doing the sequence I just > tested to make sure: Yes. The trick is getting the list of files you just deleted, esp. when you are taking out several directories of stuff. David's point was to not make the task overly difficult, but instead to simply do teh Makefile change first, to make the change easier to revert if necessary, as it would then only require one edit and commit, rather than having to generate a list of files to re-add and commit as well. Geez, he knows how CVS works, he was just trying to save some time. -- 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: removing global from tree
On Sat, Oct 14, 2000 at 10:32:11PM +0200, Gerhard Sittig wrote: > Backing out an rm'ed file should be as difficult as doing the sequence > I just tested to make sure: > > F=toberemoved.txt Coming up with the "F" list can be more than just ``ls -R /home/ncvs/src/contrib/global'' as older versions of global might have had files that weren't part of the the last version. Thus I'd have had to keep the commit message (or go find it in the archive, which would be some effort), to get the real list of files to revive. > F=toberemoved.txt # the name is misleading now :) > cvs log $F > REV=1.2 # the one before removal > cvs up -p -r$REV $F > $F > cvs add $F > cvs ci -m "revived file $F" > # and everything could be like before ... As you've just shown, this can be a real PITA. > But I feel that David wants to know this, too. Huh? Do what?? I fully understand how to remove, add, and revive files in the repo. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
> On Sat, Oct 14, 2000 at 01:54:39PM -0700, Jordan Hubbard wrote: > We've blown out the kern.flp image. Time for me to chop something > out again, unless there are any other suggestions. :| Mind if I commit this patch? Index: dokern.sh === RCS file: /home/ncvs/src/release/scripts/dokern.sh,v retrieving revision 1.35 diff -u -r1.35 dokern.sh --- dokern.sh 2000/09/29 03:24:03 1.35 +++ dokern.sh 2000/10/14 22:55:45 @@ -72,7 +72,15 @@ -e '/SOFTUPDATES/d' \ -e '/MFS/d' \ -e '/NFS_ROOT/d' \ + -e '/ncr/d' \ -e '/atapist/d' \ + -e '/lpt/d' \ + -e '/ppi/d' \ + -e '/vpo/d' \ + -e '/ugen/d' \ + -e '/uhid/d' \ + -e '/ulpt/d' \ + -e '/urio/d' \ -e '/maxusers/d' \ -e 's/ident.*GENERIC/ident BOOTMFS/g' @@ -115,6 +123,7 @@ -e '/ulpt/d' \ -e '/umass/d' \ -e '/ums/d' \ + -e '/urio/d' \ -e '/aue/d' \ -e '/cue/d' \ -e '/kue/d' \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
> I had asked for a 3rd floppy earlier that we could put f/w images and other That sounds nice in theory, but somebody needs to write the code which deals with floppy switching and module loading before this is anything but yet another request. How's your forth? :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removing global from tree
Gerhard Sittig wrote: > On Sat, Oct 14, 2000 at 11:16 -0700, John Baldwin wrote: > > > > On 14-Oct-00 Gerhard Sittig wrote: > > > > > > Up to now I always thought "the Attic" is something CVS > > > itself takes care of when "cvs rm"ing files. What's that > > > special thing needing manual intervention or special > > > attention you've been talking about lately? Is it for > > > performance reasons or for the warm fuzzy feelings of having > > > "not too rotten a repo"? > > > > It is where CVS puts files when you cvs rm them. You just have > > to do the actual cvs rm/cvs ci. David was cautious because if > > he had to back the change out, he didn't want to have to try to > > cvs add all of the files back in. > > Isn't it true that all the "log", "diff", "up -r" and such > commands still work in the expected way? That's the reason for > having "the Attic", I thought. Not to remove the repo file when > the working file expires, but to keep the history and to restore > any previous revision thereof when requested. Backing out an > rm'ed file should be as difficult as doing the sequence I just > tested to make sure: > If I understands cvs docs, the problem isn't with individual files. Cvs doesn't handle the removal and restoration of directories very well. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
On Sat, Oct 14, 2000 at 01:54:39PM -0700, Jordan Hubbard wrote: > We've blown out the kern.flp image. Time for me to chop something > out again, unless there are any other suggestions. :| Things the Alpha has already diked out: ncr SYS* (not just SYSVMSG) lpt \ ppi / should not be needed for PLIP installs vpo (should it get turned on again) ugen uhid ulpt urio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
> > I had asked for a 3rd floppy earlier that we could put f/w images and other > > That sounds nice in theory, but somebody needs to write the code which > deals with floppy switching and module loading before this is anything > but yet another request. How's your forth? :) Hmm?... my forth is poor, but I don't believe that's the issue. If I understand how the floppies currently work is that it's just like our normal boot loader- we start coming up. If you want to load other drivers or modules (like ispfw), you hit the 'other than Enter' to stop the loading progress, switch floppies and load ispfw, davicom ethernet, a splash screen with jordan's face, whatever...then you type 'boot'- then the normal mfsroot floppy handoff works. The loader for i386 uses bios services to read a DOS filesystem on a floppy or the C , D, E and so on drive, right? This wasn't 'just another request'- although you hearing it from me might make you think so. You asked "what should we do?". I responded with something which I believe might 'just work' if you make 3rd floppy. I'll take a couple of minutes to go try it if I can find what I did with my 4.1 floppies unless you're sure this doesn't work. If you're email to -current was "only answers with patches against -current will be heard", you really should have said so. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
I had asked for a 3rd floppy earlier that we could put f/w images and other drivers on. Now that we have a mostly loadable system, it strikes me that this would be an excellent time to trim down the GENERIC to the common denominator per-platform and then have compressed driver images available on a 3rd floppy if people need them. > We've blown out the kern.flp image. Time for me to chop something > out again, unless there are any other suggestions. :| > > - Jordan > --- Forwarded Message > > Return-Path: [EMAIL PROTECTED] > Delivery-Date: Sat Oct 14 06:50:52 2000 > Return-Path: <[EMAIL PROTECTED]> > Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) > by winston.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9EDopA52343 > for <[EMAIL PROTECTED]>; Sat, 14 Oct 2000 06:50:52 -0700 (PDT) > (envelope-from [EMAIL PROTECTED]) > Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) > by mx1.FreeBSD.org (Postfix) with ESMTP id C733C6E2504 > for <[EMAIL PROTECTED]>; Sat, 14 Oct 2000 06:50:55 -0700 (PDT) > Received: by hub.freebsd.org (Postfix) > id B4E3237B66C; Sat, 14 Oct 2000 06:50:55 -0700 (PDT) > Delivered-To: [EMAIL PROTECTED] > Received: from usw2.freebsd.org (usw2.freebsd.org [209.180.6.226]) > by hub.freebsd.org (Postfix) with ESMTP id 6B36537B502 > for <[EMAIL PROTECTED]>; Sat, 14 Oct 2000 06:50:55 -0700 (PDT) > Received: (from root@localhost) > by usw2.freebsd.org (8.11.1/8.11.0) id e9EDosg03413 > for [EMAIL PROTECTED]; Sat, 14 Oct 2000 08:50:54 -0500 (CDT) > (envelope-from root) > Date: Sat, 14 Oct 2000 08:50:54 -0500 (CDT) > From: USW2 Root <[EMAIL PROTECTED]> > Message-Id: <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: -current build report for Sat Oct 14 02:07:34 CDT 2000 > > Doing nightly build attempt for 5.0-20001014-CURRENT at Sat Oct 14 02:07:34 CDT 2000 > Updating source tree... > Making release... > Release build of 5.0-20001014-CURRENT was an abject failure. > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../isa/atkbd_isa.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../isa/atkbdc_isa.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../isa/fd.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../isa/ppc.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../isa/psm.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../isa/sio.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../isa/syscons_isa.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../isa/vga_isa.c > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi >-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf >-mpreferred-stack-boundary=2 ../../kern/subr_diskmbr.c > cc -c -O -Wall -Wredundant-dec
Our kernel just got too big again. :)
We've blown out the kern.flp image. Time for me to chop something out again, unless there are any other suggestions. :| - Jordan --- Forwarded Message Return-Path: [EMAIL PROTECTED] Delivery-Date: Sat Oct 14 06:50:52 2000 Return-Path: <[EMAIL PROTECTED]> Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by winston.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9EDopA52343 for <[EMAIL PROTECTED]>; Sat, 14 Oct 2000 06:50:52 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C733C6E2504 for <[EMAIL PROTECTED]>; Sat, 14 Oct 2000 06:50:55 -0700 (PDT) Received: by hub.freebsd.org (Postfix) id B4E3237B66C; Sat, 14 Oct 2000 06:50:55 -0700 (PDT) Delivered-To: [EMAIL PROTECTED] Received: from usw2.freebsd.org (usw2.freebsd.org [209.180.6.226]) by hub.freebsd.org (Postfix) with ESMTP id 6B36537B502 for <[EMAIL PROTECTED]>; Sat, 14 Oct 2000 06:50:55 -0700 (PDT) Received: (from root@localhost) by usw2.freebsd.org (8.11.1/8.11.0) id e9EDosg03413 for [EMAIL PROTECTED]; Sat, 14 Oct 2000 08:50:54 -0500 (CDT) (envelope-from root) Date: Sat, 14 Oct 2000 08:50:54 -0500 (CDT) From: USW2 Root <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: -current build report for Sat Oct 14 02:07:34 CDT 2000 Doing nightly build attempt for 5.0-20001014-CURRENT at Sat Oct 14 02:07:34 CDT 2000 Updating source tree... Making release... Release build of 5.0-20001014-CURRENT was an abject failure. cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../isa/atkbd_isa.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../isa/atkbdc_isa.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../isa/fd.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../isa/ppc.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../isa/psm.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../isa/sio.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../isa/syscons_isa.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../isa/vga_isa.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../kern/subr_diskmbr.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../libkern/divdi3.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../libkern/moddi3.c cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-protot
Re: removing global from tree
On Sat, Oct 14, 2000 at 11:16 -0700, John Baldwin wrote: > > On 14-Oct-00 Gerhard Sittig wrote: > > > > Up to now I always thought "the Attic" is something CVS > > itself takes care of when "cvs rm"ing files. What's that > > special thing needing manual intervention or special > > attention you've been talking about lately? Is it for > > performance reasons or for the warm fuzzy feelings of having > > "not too rotten a repo"? > > It is where CVS puts files when you cvs rm them. You just have > to do the actual cvs rm/cvs ci. David was cautious because if > he had to back the change out, he didn't want to have to try to > cvs add all of the files back in. Isn't it true that all the "log", "diff", "up -r" and such commands still work in the expected way? That's the reason for having "the Attic", I thought. Not to remove the repo file when the working file expires, but to keep the history and to restore any previous revision thereof when requested. Backing out an rm'ed file should be as difficult as doing the sequence I just tested to make sure: F=toberemoved.txt touch $F cvs add $F cvs ci -m "touched only" # creation time (birth, still a lot to learn) $EDITOR $F cvs ci -m "filled with real content" # that's when it's needed and existent rm $F cvs rm $F cvs ci -m "removed the file" # that's when it died # time passes, nobody misses the gone file, but then ... F=toberemoved.txt # the name is misleading now :) cvs log $F REV=1.2 # the one before removal cvs up -p -r$REV $F > $F cvs add $F cvs ci -m "revived file $F" # and everything could be like before ... The "cvs log $F" snippet even gives hope for the repo according to "there could be too much bloat". Have a look at the changed lines count, obviously only state changes: - revision 1.4 date: 2000/10/14 20:10:15; author: sittig; state: Exp; lines: +0 -0 revived it revision 1.3 date: 2000/10/14 20:08:33; author: sittig; state: dead; lines: +0 -0 removed it revision 1.2 date: 2000/10/14 20:08:00; author: sittig; state: Exp; lines: +49 -0 filled with rc.conf revision 1.1 date: 2000/10/14 20:07:24; author: sittig; state: Exp; touched - I understand that this thread is OT here. But I feel that David wants to know this, too. And maybe others. So I would like to renew my question "Why does anyone feel the need to care about cvs' internals if not for knowing better?". This must be some very special requirement why anyone feels like fiddling manually with it. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs-cur snapshots have stopped again.
Could someone please restart them? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
In article <[EMAIL PROTECTED]>, Daniel Eischen <[EMAIL PROTECTED]> wrote: > On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote: > > In article <[EMAIL PROTECTED]>, > > Daniel Eischen <[EMAIL PROTECTED]> wrote: > > > The range of valid priorities has also changed, perhaps > > > requiring a library version bump. The range of valid priorities > > > is not visible outside of the threads library. The only > > > way it can be determined is through trial and error, so > > > it _shouldn't_ be an issue. > > > > I thought you could get that information with sched_get_priority_min() > > and sched_get_priority_max(). Is that not the case? > > Not really. Those return the kernels POSIX priority range for > processes. Hmm, that's not how I interpret the POSIX spec. Here are some excerpts from section 13.2, "Scheduling Policies". That's in the chapter which describes all of the sched_XXX() functions. This model discusses only processor scheduling for runnable threads ... There is, conceptually, one thread list for each priority. Any runnable thread may be on any thread list. Multiple scheduling policies shall be provided. Each nonempty thread list is ordered, contains a head as one end of its order, and a tail as the other. The purpose of a scheduling policy is to define the allowable operations on this set of lists. Each process shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit application execution of the sched_setscheduler() or sched_setparam() functions. Each thread shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit application execution of the pthread_setschedparam() function. And then in the discussion of the SCHED_FIFO scheduling policy in section 13.2.1, it says: (4) When a running thread calls the sched_setparam() function, the priority of the process specified in the function call is modified to the priority specified by the param argument. If the thread whose priority has been modified is a running thread or is runnable, runnable thread [sic] it then becomes the tail of the thread list for its new priority. (5) When a running thread calls the pthread_setschedparam() function, the thread specified in the function call is modified to the specified policy and the priority specified by the param argument. (6) If a thread whose policy or priority has been modified is a running thread or is runnable, runnable thread [sic] it then becomes the tail of the thread list for its new priority. ... For this policy, valid priorities shall be within the range returned by the function sched_get_priority_max() and sched_get_priority_min() when SCHED_FIFO is provided as the parameter. So it seems clear that the same range of priorities shall apply to individual threads as well as to processes. (SCHED_RR is similar in these respects.) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sendmail related changes
Gregory Neil Shapiro wrote: > leifn> Is there a way to make make world use my own sendmail.mc? > > There will be soon. I hope to have it in place before or during BSDcon. Yes, there has been one for ages. Add: "SENDMAIL_CF= myfile.cf" to /etc/make.conf, and the sendmail makefiles will build it from myfile.mc and install it as part of every buildworld. 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: removing global from tree
On 14-Oct-00 Gerhard Sittig wrote: > On Sat, Oct 14, 2000 at 05:35 -0700, David O'Brien wrote: >> >> I didn't put it in the Attic when I disconnected it from the >> build in case someone came forward screaming about removing it. >> I figured it was much easier to back out a Makefile commit than >> get things from the Attic back to being alive. I had actually >> forgotten about it as no one did come forward. > > Up to now I always thought "the Attic" is something CVS itself > takes care of when "cvs rm"ing files. What's that special thing > needing manual intervention or special attention you've been > talking about lately? Is it for performance reasons or for the > warm fuzzy feelings of having "not too rotten a repo"? It is where CVS puts files when you cvs rm them. You just have to do the actual cvs rm/cvs ci. David was cautious because if he had to back the change out, he didn't want to have to try to cvs add all of the files back in. -- 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: removing global from tree
On Sat, Oct 14, 2000 at 05:35 -0700, David O'Brien wrote: > > I didn't put it in the Attic when I disconnected it from the > build in case someone came forward screaming about removing it. > I figured it was much easier to back out a Makefile commit than > get things from the Attic back to being alive. I had actually > forgotten about it as no one did come forward. Up to now I always thought "the Attic" is something CVS itself takes care of when "cvs rm"ing files. What's that special thing needing manual intervention or special attention you've been talking about lately? Is it for performance reasons or for the warm fuzzy feelings of having "not too rotten a repo"? Sorry for being OT. Of course I welcome pointers to existing documentation and FAQs, too. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problems and suggestions (CURRENT)
Sometime between October 6 and yesterday (I haven't verified with today's sources), make installkernel dies with a usage message for the install command. buildworld and buildkernel go through ok. I believe the issue is in the order the arguments are called, and if I knew which .mk file told this, I'd provide a patch. 'boot -s' appears to have stopped working as well during the same time period. NFS portmapper dies on startup. This also happened during the same time period. The last has to do with the 'ed' driver and the latest Netgear PCMCIA FA410TX card. I have a program to write the speed info to the EPROM and am wondering if/when it will be included in the kernel. -- Hasan Diwan [[EMAIL PROTECTED]] :) Rensselaer Polytechnic Institute Computer Science Department http://www.pobox.com/~hdiwan PGP signature
Re: HEADS UP: sendmail related changes
On Sat, 14 Oct 2000, Gregory Neil Shapiro wrote: >leifn> Is there a way to make make world use my own sendmail.mc? > >There will be soon. I hope to have it in place before or during BSDcon. At one time there was a make.conf knob for it, is that not still around? -- Brandon D. Valentine <[EMAIL PROTECTED]> "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Daniel Eischen <[EMAIL PROTECTED]> wrote:
> > The range of valid priorities has also changed, perhaps
> > requiring a library version bump. The range of valid priorities
> > is not visible outside of the threads library. The only
> > way it can be determined is through trial and error, so
> > it _shouldn't_ be an issue.
>
> I thought you could get that information with sched_get_priority_min()
> and sched_get_priority_max(). Is that not the case?
Not really. Those return the kernels POSIX priority range for
processes. I am unsure as to how to deal with those in the
threads library; do we want to wrap those system calls and
return thread priority ranges?
The kernels range for SCHED_OTHER is -20 .. 20, and 0 .. 31
for SCHED_FIFO and SCHED_RR. The threads library priority
range changed from 0 .. 126 to 0 .. 31 (for all scheduling
classes). Anyone using sched_get_priority_{min|max} for
_thread_ priority ranges would have problems if the scheduling
class was SCHED_OTHER, but wouldn't see any difference
for SCHED_FIFO or SCHED_RR.
Still, I know this change breaks at least one port; lang/gnat
uses the full range of priorities, only because it was my
port and I knew the priority range of the threads library.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: removing global from tree
On Fri, Oct 13, 2000 at 10:01:59AM -0700, Steve Kargl wrote: > In revision 1.148 of src/usr.bin/Makefile, the hook for building > global was removed. This was 3.5 month ago. Is it time to move > src/contrib/global and src/usr.bin/global into the attic? Wow, that is still there. I forgot about it. I'll take care of this weekend. On Sat, Oct 14, 2000 at 03:03:57AM -0700, [EMAIL PROTECTED] wrote: > Yes, it should have been done at the time it was removed from the > Makefile. I didn't put it in the Attic when I disconnected it from the build in case someone came forward screaming about removing it. I figured it was much easier to back out a Makefile commit than get things from the Attic back to being alive. I had actually forgotten about it as no one did come forward. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot partition?
On Fri, Oct 13, 2000 at 12:39 -0500, Mike Meyer wrote: > > [ ... separate /boot partition ... ] > > Since you implied a question... > > This is a standard setup for Linux, so Linux people dealing with > problems with the root file system try and make it work in -stable > (with no luck). The best example would be to make /boot one file > system so you can get vinum loaded and running, then have everything > else on a vinum disk. This minimizes the set of things you don't have > on vinum. Since you bring the Linux analogy in ... There's a mechanism used by some Linux distros (strictly speaking: available to all Linux users, but rarely used by default) to have a ramdisk with the kernel and essential drivers. This ramdisk can be handled by many boot managers and the effect is that - you don't need all the drivers you need for booting in the kernel itself -- they can be modules, too - you can have all your fses in software raid configuration and yet survive the boot stage, since the boot kernel won't have a need to touch and handle the raid configuration But I feel that a separate /boot partition will never work when you can't reach the / fs -- where are you going to mount the /boot fs? The idea is always that you have to bring in everything you need to get over the initial steps. Without vinum drivers and setup tools you cannot access vinum volumes. And when the tools live on a vinum volume themselves, you're trapped. That's when you need a separate "selfcontained" mechanism -- like a mfs or ramdisk thing. BTW: One of the most commonly seen failures is to compile a new kernel and not updating the ramdisk needed for booting ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules again non-shareable?
On Fri, Oct 13, 2000 at 08:38:34PM -0700, Matthew Jacob wrote: > would that nullfs worked! It does, modulo remaining bugs which Boris hasnt yet fixed. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
In article <[EMAIL PROTECTED]>, Daniel Eischen <[EMAIL PROTECTED]> wrote: > > I've just committed some changes to the threads library > and would appreciate feedback from anyone running threaded > applications. They include fixes that -stable could really > use. > > This commit also implements zero system call thread context > switching in the threads library. Switching between threads > is now much faster than before this change. This sounds like great stuff! > The range of valid priorities has also changed, perhaps > requiring a library version bump. The range of valid priorities > is not visible outside of the threads library. The only > way it can be determined is through trial and error, so > it _shouldn't_ be an issue. I thought you could get that information with sched_get_priority_min() and sched_get_priority_max(). Is that not the case? John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removing global from tree
In article <[EMAIL PROTECTED]>, Steve Kargl <[EMAIL PROTECTED]> wrote: > In revision 1.148 of src/usr.bin/Makefile, the hook for building > global was removed. This was 3.5 month ago. Is it time to move > src/contrib/global and src/usr.bin/global into the attic? Yes, it should have been done at the time it was removed from the Makefile. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sendmail related changes
leifn> Is there a way to make make world use my own sendmail.mc? There will be soon. I hope to have it in place before or during BSDcon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sendmail related changes
On Tue, 10 Oct 2000, Gregory Neil Shapiro wrote: > The following changes have been made in -CURRENT: > > 1. mail.local(8) is no longer installed as a set-user-id binary. > >If you are using a /etc/mail/sendmail.cf from the default sendmail.cf >included with FreeBSD any time after 3.1.0, you are fine. If you are >using a hand-configured sendmail.cf and mail.local for delivery, check >to make sure the F=S flag is set on the Mlocal line. Those with .mc >files who need to add the flag can do so by adding the following line to >their your .mc file and regenerating the sendmail.cf file: Is there a way to make make world use my own sendmail.mc? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcmcia and ed
Thus spake Warner Losh ([EMAIL PROTECTED]): > The module name should be if_ed. I'll go fix it. Did you do this already? And if so, where? I'd love to know. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
