Re: "The Matrix" screensaver, v.0.2
> Anyway, this module was meant more as a joke, but if you guys like it so > much you could vote for putting it in the tree... My vote is a resounding "Yes!". M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
Kevin Day wrote: > > A> Anyway, this module was meant more as a joke, but if you guys like it so > > > much you could vote for putting it in the tree... > > > >What do you mean "vote"? I was waiting for it to show up on my tree > >after a cvsup! > > I hate to keep bringing things like this up, or start a legal war, but this > screensaver is more than likely a copyright and/or trademark violation, and > bringing it into the source tree may not be a good idea. Yes, lots of > people may be making things like this, but it would probably be best to > distance FreeBSD itself from such a thing. MMmm... not sure... First, it is not an exact copy. Second, it has no mention of trademarked names. Third, The Matrix took it's idea from Ghost in the Shell in first place. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de.c breakage ?
Mike Smith wrote: > > > Hi, my mentor :-) > > > > phk> Am I the only one to see these ? > > > > Me too. I found it other files as well. > > It seems that adding following line is required in some source code. > > > > #include > > Argh! I knew that taking it out of sys/systm.h was a bad idea. 8( That doesn't make it a bad idea. It just makes for some code fixing. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Come on. - Where are we going? - To get what you came for. - What's that? - Me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [re]writable cdrom drive
Matthew Dillon wrote: > > :Hate to ask, do we support CD-RW? > > Yup! In fact, I recommend that you get a 5-pack of CD-RW disks > so you don't turn your CD-R's into scrap while playing with the > unit. Scrap? HA! http://students.seattleu.edu/hodeleri/Images/CDs.gif -- Eric Hodel - [EMAIL PROTECTED] - Aspiring programmer & FPS minor demi-god. Customers will come to our 'home page' in unbelievable numbers and find out everything we want them to know. --Bill Gates To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
A> Anyway, this module was meant more as a joke, but if you guys like it so > > much you could vote for putting it in the tree... > >What do you mean "vote"? I was waiting for it to show up on my tree >after a cvsup! I hate to keep bringing things like this up, or start a legal war, but this screensaver is more than likely a copyright and/or trademark violation, and bringing it into the source tree may not be a good idea. Yes, lots of people may be making things like this, but it would probably be best to distance FreeBSD itself from such a thing. Kevin (speaking as an employee of a company who's products are frequently infringed on, and have been through this exact situation before, except from the other side) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
Andrzej Bialecki wrote: > > On Sat, 21 Aug 1999, Nik Clayton wrote: > > > FWIW, there are at least two other 'matrix' implementations out there. > > One is part of xscreensaver, and is quite nice -- it's even better if you > > halve the size of the image it's using first. This has the advantage that > > the characters actually look like the ones in the film (reversed numbers > > and Japanese katana (sp?) characters). That one's (obviously) X only. > > Katakana, IIRC. You know, if I only had more spare time I could do > something with VESA graphics - X is not really needed here. > > Anyway, this module was meant more as a joke, but if you guys like it so > much you could vote for putting it in the tree... What do you mean "vote"? I was waiting for it to show up on my tree after a cvsup! -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
On Sun, 22 Aug 1999, Andrzej Bialecki wrote: > Anyway, this module was meant more as a joke, but if you guys like it so > much you could vote for putting it in the tree... It's extremely small, so why not? Got my vote. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with NFSv3 on a CURRENT/SMP system
:> I'm generating a core dump. Please note that as tara is my test machine, I use :> "INVARIANT" & "INVARIANT_SUPPORT". Should I remove them ? :> :> It seems that from my reading of the code, the panic would not had happened :> without INVARIANT. :> :It is these options that caused the panic, you either remove them from the :kernel proper, or compile the kld with them. : :-lq No mix and match, eh? I don't use kld's at all any more - at least not on the development kernel (CURRENT). Too many changes to system structures almost guarentee crashes when kld's are used. I run all my kernels with INVARIANTS and INVARIANT_SUPPORT, and all modules are built into the kernel. That works for me. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
:> Does anyone know why our NFS clients are sending a separate RPC for each :> 8K buffer? If the dirty space is contiguous across a number of buffers :> we should be able to send a *SINGLE* commit rpc to the server. That would :> greatly reduce system overhead on both the client and server when writing :... :ASAP. The last hurdle (seemingly) on my big project at work that I've been :bugging so many of you about is the fact that FreeBSD NFS client writing to :Sun NFS server is just DOG slow. I did some pretty extensive testing on :this and couldn't come up with any client option twidding that made any :difference, except increasing wsize to 16k, which got me about 10%, but it :was still very slow. This is on a -current system from around the tenth of :August. : :Doug Well, this is definitely optimization I would love to do, but first I need to know whether it's legal to combine NFSv3 commit RPCs. If there are any NFS experts out there, I'm all ears! This would get rid of half the rpc transaction traffic for sequential writes. My read of the code seems to infer that it *is* legal. There's another optimization which was submitted to me which gets rid half the stat rpcs which I haven't even had time to look at yet. These particular optimizations would not reduce aggregate network bandwidth but it would cut the cpu load on the client and server in half for operations in question. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with NFSv3 on a CURRENT/SMP system
> I'm generating a core dump. Please note that as tara is my test machine, I use > "INVARIANT" & "INVARIANT_SUPPORT". Should I remove them ? > > It seems that from my reading of the code, the panic would not had happened > without INVARIANT. > It is these options that caused the panic, you either remove them from the kernel proper, or compile the kld with them. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
slight note to patchset (was Re: NFS HEADS UP)xdr_subs.h)
I forgot to mention: It's the 'Multi-patch #1' section of the web page, the section at the top. Ignore all the stuff that comes after that - they've already been committed, as have many other things not listed. http://www.backplane.com/FreeBSD4/ -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patches available (was Re: NFS HEADS UP)
Ok, I have put up the current patch set -- for patching against CURRENT only - on my web site. http://www.backplane.com/FreeBSD4/ They contain a bit more then the NFS stuff, but it's all related to performance. It would take me too long to try to separate them out (this is what happens when things back-up, sorry!). The patches have been tested only somewhat and the one that fixes nfssrv_commit() is not 100% complete - it doesn't sync-out the file metadata yet, only the specific data blocks being requested by the commit rpc. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Weird differences in rc5 behavior on -current vs. -stable
I have a 3.2-Stable and a 4.0-Current system at home, both running rc5des. On both systems I set the priority in the rc5 options menu to '0', indicating lowest possible priority. On the -Stable system it's running at nice level '0', but it seems to be taking advantage of the idprio stuff since in general my system seems much "snappier," than when I was running 2.2.8 on the exact same machine. On the -current box rc5des shows up as nice level 20, and although it's a pretty snappy system (this is my workstation machine with a celeron 300A and lots of ram) I thought the difference to be pretty strange. The rc5des.ini files for both machines are identical (except for the random value). Also, when rc5des runs on the -current system I get this: ps -ax | grep rc5des 59048 p0 S 0:00.02 _su -m -c /usr/local/distributed.net/rc5des -quiet (c 59062 p0 RN 0:01.63 /usr/local/distributed.net/rc5des -quiet whereas on the -stable system there is no ghost su process. This is with the latest version of rc5 installed from the ports. These aren't major problems, but it's often the small things like this that indicate an area of concern elsewhere, so I thought I'd mention it. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
On Sat, 21 Aug 1999, Nik Clayton wrote: > FWIW, there are at least two other 'matrix' implementations out there. > One is part of xscreensaver, and is quite nice -- it's even better if you > halve the size of the image it's using first. This has the advantage that > the characters actually look like the ones in the film (reversed numbers > and Japanese katana (sp?) characters). That one's (obviously) X only. Katakana, IIRC. You know, if I only had more spare time I could do something with VESA graphics - X is not really needed here. Anyway, this module was meant more as a joke, but if you guys like it so much you could vote for putting it in the tree... Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with NFSv3 on a CURRENT/SMP system
:Hello, : :I just got a panic when trying to play with NFSv3. The system is a dual :PentiumPro system, running CURRENT/SMP. I use NFS as a kld. The very first thing I would do is compile NFS into the kernel and not use it as a kld. Then see if you can repeat the problem. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails in /usr/src/sys/modules/mii/..
Bill Paul wrote: > Ai! The stupid bus interface description file escaped before I > could commit it with the rest of the miibus code. Okay, I just fixed > it. Thanks for the heads up and sorry for the trouble. My turn to > wear the pointy hat again. Hey, no sweat. It is -current after all. :) Thanks for your work to improve this and the quick response. Glad I could help, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: REQ: Test /etc/rc clean-up
"Jordan K. Hubbard" wrote:
>
> > The X also protected test from the case where the expansion included a
> > string like "-x", although with most modern implementations of test (or
> > shells with test as a builtin) this is no longer a problem.
>
> And certainly not in any of these cases. :)
Right, I was just being pedantic.
> > I agree with some of your changes here, but can you explain your objection
> > to using case? My argument is that case is a builtin so it makes things
> > just a little bit cleaner, and more importantly it makes case insensitivity
> > for the options that much easier to implement which is a huge win in user
> > friendliness. For example, what happens to if [ "${pccard_ifconfig}" !=
>
> I don't disagree with any of this, but that radical a degree of change
> was simply not my intention with these diffs. :-)
Ok, good. Like I said I think cleaning it up in general is a Good Thing
(TM). There is one other element of style that it would be nice to see made
consistent, namely:
if [ blah ]; then
as opposed to the various iterations of ] ; then, then's on a seperate
line, etc. Even using case for the variables there are still going to be
some test's needed.
> If we were to commit this, I'd suggest that we do my version first
> and then have a case-ify pass done 2nd, just so we have each option
> to chose from in the CVS repository should anyone express strong
> reservations at some stage. :)
Yes, I was going to suggest the same thing. Wow... we are dangerously
close to a consensus on this. :)
Doug
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Kernel compile died.....
This is my kernel compile error and where it died e -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../dev/aha/aha.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../dev/aic7xxx/aic7xxx.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../dev/aic7xxx/93cx6.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../dev/buslogic/bt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../dev/dpt/dpt_scsi.c ../../dev/dpt/dpt_scsi.c: In function `dpt_get_conf': ../../dev/dpt/dpt_scsi.c:389: warning: cast discards `volatile' from pointer target type ../../dev/dpt/dpt_scsi.c: In function `dpt_detect_cache': ../../dev/dpt/dpt_scsi.c:496: warning: cast discards `volatile' from pointer target type ../../dev/dpt/dpt_scsi.c: In function `dpt_init': ../../dev/dpt/dpt_scsi.c:1187: warning: cast discards `volatile' from pointer target type ../../dev/dpt/dpt_scsi.c: In function `dpt_attach': ../../dev/dpt/dpt_scsi.c:1410: warning: implicit declaration of function `EVENTHANDLER_REGISTER' ../../dev/dpt/dpt_scsi.c:1410: `shutdown_final' undeclared (first use in this function) ../../dev/dpt/dpt_scsi.c:1410: (Each undeclared identifier is reported only once ../../dev/dpt/dpt_scsi.c:1410: for each function it appears in.) ../../dev/dpt/dpt_scsi.c:1411: `SHUTDOWN_PRI_DEFAULT' undeclared (first use in this function) *** Error code 1 -- E-Mail: william woods <[EMAIL PROTECTED]> Date: 21-Aug-99 Time: 18:16:14 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
I'm with you 100% I've got about 100 Bonnies of trying to optimize Linux Clients (pre and post NFSv3 patch) vs. FreeBSD server. I've gone to current so that I can watch it happen. I'm currently writing around 4.5M - 5.0M/sec vs. 10-15M/sec on my vinum stripe locally. I went through a similar thing 1.5years ago with IBM/Solaris/Irix servers that were sharing VOB's, Irix to Solaris was DOG slow and we finally conquered it wit a bunch of fiddling and patching. -Rob Doug wrote: > > Matthew Dillon wrote: > > > Does anyone know why our NFS clients are sending a separate RPC for each > > 8K buffer? If the dirty space is contiguous across a number of buffers > > we should be able to send a *SINGLE* commit rpc to the server. That would > > greatly reduce system overhead on both the client and server when writing > > a large file over NFS. This would seem to be an almost free optimization > > that would mesh extremely well with the nfsrv_commit optimizations I'm > > making right now. > > > > At the moment I can saturate a 100BaseTX with NFS writes and get > > 10 MBytes/sec to the platter on the server, but the cpu required on both > > the client and server to do that is well over 60% of a Pentium III-450. > > I'd like to put in a vote to get these NFS write optimizations in the pipe > ASAP. The last hurdle (seemingly) on my big project at work that I've been > bugging so many of you about is the fact that FreeBSD NFS client writing to > Sun NFS server is just DOG slow. I did some pretty extensive testing on > this and couldn't come up with any client option twidding that made any > difference, except increasing wsize to 16k, which got me about 10%, but it > was still very slow. This is on a -current system from around the tenth of > August. > > Matt, thanks for all your hard work on this, and believe me when I say it > couldn't come at a better time. > > Doug > > 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: "The Matrix" screensaver, v.0.2
Andrzej Bialecki wrote: > > Hi, > > Due to unexpected demand . . . Ok, I have to say that pretty much rocks. :) Any chance of making an X version of this? The guy in the cube across from mine and I are both big science fiction fans, and he would turn *cough* green with envy . . . Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails in /usr/src/sys/modules/mii/..
Of all the gin joints in all the towns in all the world, Doug had to walk into mine and say: > Cvsup'ed today, make -DNOCLEAN world failed in gcc, did a 'make includes' > and 'make world' and now it fails in: > > ===> sys/modules/mii > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > perl /usr/src/sys/modules/mii/../../kern/makedevops.pl -h > /usr/src/sys/modules/mii/../../kern/bus_if.m > make: don't know how to make > /usr/src/sys/modules/mii/../../dev/mii/miibus_if.m. Stop Ai! The stupid bus interface description file escaped before I could commit it with the rest of the miibus code. Okay, I just fixed it. Thanks for the heads up and sorry for the trouble. My turn to wear the pointy hat again. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld fails in /usr/src/sys/modules/mii/..
Cvsup'ed today, make -DNOCLEAN world failed in gcc, did a 'make includes' and 'make world' and now it fails in: ===> sys/modules/mii @ -> /usr/src/sys machine -> /usr/src/sys/i386/include perl /usr/src/sys/modules/mii/../../kern/makedevops.pl -h /usr/src/sys/modules/mii/../../kern/bus_if.m make: don't know how to make /usr/src/sys/modules/mii/../../dev/mii/miibus_if.m. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Just re-cvsup'ed and no new changes. HTH, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: REQ: Test /etc/rc clean-up
> The X also protected test from the case where the expansion included a
> string like "-x", although with most modern implementations of test (or
> shells with test as a builtin) this is no longer a problem.
And certainly not in any of these cases. :)
> I agree with some of your changes here, but can you explain your objection
> to using case? My argument is that case is a builtin so it makes things
> just a little bit cleaner, and more importantly it makes case insensitivity
> for the options that much easier to implement which is a huge win in user
> friendliness. For example, what happens to if [ "${pccard_ifconfig}" !=
I don't disagree with any of this, but that radical a degree of change
was simply not my intention with these diffs. :-) I sought only to:
1. Eliminate unnecessary X pollution.
2. Make all variable expansion consistently use ${foo}; only positional
parameters are "naked" now.
3. Fix cases where test -n is an obvious simplification of the existing
expression.
If we were to commit this, I'd suggest that we do my version first
and then have a case-ify pass done 2nd, just so we have each option
to chose from in the CVS repository should anyone express strong
reservations at some stage. :)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon wrote: > Does anyone know why our NFS clients are sending a separate RPC for each > 8K buffer? If the dirty space is contiguous across a number of buffers > we should be able to send a *SINGLE* commit rpc to the server. That would > greatly reduce system overhead on both the client and server when writing > a large file over NFS. This would seem to be an almost free optimization > that would mesh extremely well with the nfsrv_commit optimizations I'm > making right now. > > At the moment I can saturate a 100BaseTX with NFS writes and get > 10 MBytes/sec to the platter on the server, but the cpu required on both > the client and server to do that is well over 60% of a Pentium III-450. I'd like to put in a vote to get these NFS write optimizations in the pipe ASAP. The last hurdle (seemingly) on my big project at work that I've been bugging so many of you about is the fact that FreeBSD NFS client writing to Sun NFS server is just DOG slow. I did some pretty extensive testing on this and couldn't come up with any client option twidding that made any difference, except increasing wsize to 16k, which got me about 10%, but it was still very slow. This is on a -current system from around the tenth of August. Matt, thanks for all your hard work on this, and believe me when I say it couldn't come at a better time. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: REQ: Test /etc/rc clean-up
"Jordan K. Hubbard" wrote:
>
> > I gather the reason for using the X trick *and* the quotes is because there
> > might be some whitespace in there, too.
>
> Actually, that's mostly just historical legacy. When the quotes, it's
> safe even if the expansion is empty or contains whitespace.
The X also protected test from the case where the expansion included a
string like "-x", although with most modern implementations of test (or
shells with test as a builtin) this is no longer a problem.
> I got
> kinda annoyed with this last night and did the following:
I agree with some of your changes here, but can you explain your objection
to using case? My argument is that case is a builtin so it makes things
just a little bit cleaner, and more importantly it makes case insensitivity
for the options that much easier to implement which is a huge win in user
friendliness. For example, what happens to if [ "${pccard_ifconfig}" !=
"NO" ] if the user makes the flag "no"? I'd say that the fact that this is
going to go off anyway violates POLA, all "stupid user" arguments aside.
Doug
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: REQ: Test /etc/rc clean-up
> I gather the reason for using the X trick *and* the quotes is because there > might be some whitespace in there, too. Actually, that's mostly just historical legacy. When the quotes, it's safe even if the expansion is empty or contains whitespace. I got kinda annoyed with this last night and did the following: http://www.freebsd.org/~jkh/etc.diffs.fix-it-right Which I've sent to Sheldon for review but haven't heard anything back from him yet. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: REQ: Test /etc/rc clean-up
I understand that folks use X$foo becuase if $foo evaluates to -whatever then there is a *chance* that test will misunderstand. I gather the reason for using the X trick *and* the quotes is because there might be some whitespace in there, too. Given that "case" is a builtin and using "case" instead of "test" is both faster, easier to read (less clutter), and supports mixed-case easier, I prefer "case". But I went down this road before. H To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: user friendly creation of CDs (was: Re: patches for tosha?)
Hi, In my case is a lot easier to customize a simple shell script and use it. Is just that gcombust comes from linux perhaps if I keep using I can get over my hurdle 8) Have Fun Guys! > Heh. I see, you want a program that one could use without > having to know _anything_. Your right thats not what gcombust is, > but its still useful for those of us who know `something'... > > On Fri, Aug 20, 1999 at 05:02:07PM -0700, Amancio Hasty wrote: > > Yes, I tried gcombust and opted for the command line approach > > > > gcombust looks great ;however, I expect for user firiendly land > > less knobs for instance: > > > > burn iso 9660 cd > > Select files or directories > > type of CD : CD-R , CD-RW > > > > then pull the appropiate information for buffering and > > optimal speed from a database. > > Not sure a database would be enough for that, as these not only > vary for each system (hardware) but also depend on > > . the type of files to be written (big ones or many small ones) > and of course the performance of the disk/controller/fs their on > (and the net if their not local) > . current and near-future system load (for example any cronjobs > coming up that will be hammering the source disk, or network?) > > (is that all?) of course you could reduce the problems by simply > always creating an image file but then you can't write CDs once > your low on free space. > > >... Sometimes being the hacker > > of the house is not an easy task 8) > > :) Still i'd like to know of any solution you come up with... > > Regards, > -- > Juergen Lock <[EMAIL PROTECTED]> > (remove dot foo from address to reply) -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: user friendly creation of CDs (was: Re: patches for tosha?)
Heh. I see, you want a program that one could use without having to know _anything_. Your right thats not what gcombust is, but its still useful for those of us who know `something'... On Fri, Aug 20, 1999 at 05:02:07PM -0700, Amancio Hasty wrote: > Yes, I tried gcombust and opted for the command line approach > > gcombust looks great ;however, I expect for user firiendly land > less knobs for instance: > > burn iso 9660 cd > Select files or directories > type of CD : CD-R , CD-RW > > then pull the appropiate information for buffering and > optimal speed from a database. Not sure a database would be enough for that, as these not only vary for each system (hardware) but also depend on . the type of files to be written (big ones or many small ones) and of course the performance of the disk/controller/fs their on (and the net if their not local) . current and near-future system load (for example any cronjobs coming up that will be hammering the source disk, or network?) (is that all?) of course you could reduce the problems by simply always creating an image file but then you can't write CDs once your low on free space. >... Sometimes being the hacker > of the house is not an easy task 8) :) Still i'd like to know of any solution you come up with... Regards, -- Juergen Lock <[EMAIL PROTECTED]> (remove dot foo from address to reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon said: > :> Well, the issue with converting many of the macros to inline functions > :> is with the embedded goto's and references to variables defined outside > :> the macros. Converting them to functions would basically require > :> rewriting a huge chunk of NFS code. > :> > :My working kernel runs with a few strategic NFS macros being converted > :to functions, and the size improvement is about 50K or so (maybe more!!!) > : > :John > > If you want to port some of it in that part of the source tree will be > available in a month or two, depending on how quickly the other stuff in > my queue gets committed. I've got two patch sets currently under test > related to other NFS issues and a third one in the wings. > The changes are "semi-trivial", and hope that a new kernel hacker can take a crack at it. Part of my comment however true, was meant as a tease to get more kernel people involved (helping the cause.) Anything that any of us does can be done by others, and fostering a talent search is a good thing (IMO.) I am willing to provide the info, but hope that a naiscent kernel hacker comes forward... John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: REQ: Test /etc/rc clean-up
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Sheldon Hearn writes:
> : -if [ X$start_vinum = XYES ]; then
> : +if [ X"${start_vinum}" = X"YES" ]; then
>
> I never understood why you check against X"YES"? XYES always seemed
> much better than X"YES" since the latter is somewhat obscure. Both
> are identical...
The prevailing shell scripting CW is that putting the X outside the quotes
makes it more clear to a casual observer that the X is not part of the
value you are testing. Personally I agree with you, I've always thought
that "X$VAR" looks cleaner.
Doug (assuming I'm understanding your point here...)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
On Fri, Aug 20, 1999 at 08:10:51PM -0400, Keith Stevenson wrote: > On Fri, Aug 20, 1999 at 04:11:42PM -0600, Oscar Bonilla wrote: > > then xlock already includes a module for this... I'm using it on my > > laptop.. ... ahh. ... Meanwhile I've updated my xlock to xlockmore-4.14 including 'the matrix'. I'm rather disappointed. a) it crawls like a dog without legs :( (especially on my 1600x1200 screen) > I like Andrzej's module a _lot_ better than the xlock module. It looks (IMO) > more like the screen from the movie and doesn't eat all of my CPU cycles. b) I second this. -ab -- : Anti-Spam Petition: http://www.politik-digital.de/spam/: : PGP-Key:http://www.tse-online.de/~ab/public-key: : Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current Kernel build broken
> With current source tree as of 9 am pacific, I can no longer build a kernel : My mistake; should be fixed now. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de.c breakage ?
On Sat, 21 Aug 1999, Mike Smith wrote: > Argh! I knew that taking it out of sys/systm.h was a bad idea. 8( I committed the fix for this, FYI, after it tripped someone up on IRC. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
In message <[EMAIL PROTECTED]> Mike Smith writes: : If you're going to do that, take a look at the ACPI spec and implement : at least the base set of power states that it defines, since we are : going to have to live with hardware that behaves like that for some : time to come. Good idea... However, most ACPI machines have a legacy APM model, which is what the device methods support. When the ACPI stuff comes it, it will likely need to expand the methods... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
> In message <[EMAIL PROTECTED]> Mike Smith writes: > : APM is only attached to the ISA bus for crufty reasons; I'm going to > > Actually, APM is attached to NEXUS. Why pass it kernel environment > variables when it will likely be modified to grok whatever config > scheme comes from newbus? Because it's not a device, or more specifically, if it should be attached to anything, it should be attached to a 'bios' bus. The kernel environment is simply a convenient way to make it work right now, rather than waiting for the newbus parameter stuff to arrive (which will likely be carried in the environment anyway). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
> : If you need more functionality than DEVICE_SUSPEND and DEVICE_RESUME, > : then add more methods. > > That DEVICE_SUSPEND and DEVICE_RESUME methods are exactly the same > thing as we have right now with the apm code. No need to reinvent the > wheel here. It was on my list of cleanups to do after I got the > pccard stuff to the point where modems work again. If you're going to do that, take a look at the ACPI spec and implement at least the base set of power states that it defines, since we are going to have to live with hardware that behaves like that for some time to come. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
> In message <[EMAIL PROTECTED]> Mike Smith writes: > : Seriously though, I'm in the process of replacing a number of the > : ad-hoc event handler callout lists in the kernel (most notably the > : at_shutdown and apm* lists) with a generic implementation. > > Shouldn't the apm stuff use the new-bus hooks? I've migraded a couple > of uses in pccard to using that now that I have newbus node to hang > them off of... Certainly anything that's attached to a bus should be using the bus' suspend event handler, yes. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de.c breakage ?
> Hi, my mentor :-) > > phk> Am I the only one to see these ? > > Me too. I found it other files as well. > It seems that adding following line is required in some source code. > > #include Argh! I knew that taking it out of sys/systm.h was a bad idea. 8( -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
In message <[EMAIL PROTECTED]> Garrett Wollman writes: : You missed the point. The bus hierarchy has support designed-in to : pass power-management requests down the device tree. The only : functions which should be registering themselves with APM directly : are: : : 1) Old device drivers using a compatibility shim, or : : 2) Kernel code which is not a device driver. : : If you need more functionality than DEVICE_SUSPEND and DEVICE_RESUME, : then add more methods. That DEVICE_SUSPEND and DEVICE_RESUME methods are exactly the same thing as we have right now with the apm code. No need to reinvent the wheel here. It was on my list of cleanups to do after I got the pccard stuff to the point where modems work again. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
In message <[EMAIL PROTECTED]> Mike Smith writes: : APM is only attached to the ISA bus for crufty reasons; I'm going to Actually, APM is attached to NEXUS. Why pass it kernel environment variables when it will likely be modified to grok whatever config scheme comes from newbus? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
In message <[EMAIL PROTECTED]> Mike Smith writes: : > In message <[EMAIL PROTECTED]> Mike Smith writes: : > : Seriously though, I'm in the process of replacing a number of the : > : ad-hoc event handler callout lists in the kernel (most notably the : > : at_shutdown and apm* lists) with a generic implementation. : > : > Shouldn't the apm stuff use the new-bus hooks? I've migraded a couple : > of uses in pccard to using that now that I have newbus node to hang : > them off of... : : APM is only attached to the ISA bus for crufty reasons; I'm going to : take it off shortly and use the kernel environment to pass it options. No. You misunderstand me. I'm talking about the device_suspend and device_remove methods which get called for all attached devices on suspend and remove. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
> > > > "Another possibility, if you have the RAM, is to use the team(1) > > > > program (it's in the ports) to buffer the data as it goes to the burner. > > > > > > Any reason not to use ``cdrecord -fs=64m'' (or some simular size) > > > > Any reason to? I mean, I never had to go over the default cdrecord uses. > > Since the author was already suggesting the use of team(1) he obvisiously > wants a larger buffer. I was mearly asking if there was something about > team(1) better than ``cdrecord -fs=XX''. > To me in the context of cdrecord, cdrecord's option "fs" and team are about the same. Perhaps someone more familiar with cdrecord fifo.c's circular buffer algorithm and team can express a different opinion. Cheers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic with NFSv3 on a CURRENT/SMP system
Hello,
I just got a panic when trying to play with NFSv3. The system is a dual
PentiumPro system, running CURRENT/SMP. I use NFS as a kld.
The FS on keltia is exported as:
/z -alldirs -maproot=0 tara
And mounted on tara with
keltia:/z /spare rw,nfsv30 0
I tried making a directory on tara: "mkdir foo" and it succeeded. The
directory has been created on keltia:
drwxr-xr-x 2 root wheel 512 Aug 21 21:49 foo
Now, as soon as I try to go into that directory, boom!
roberto@tara:/z# cd foo
panic: zone: entry not free
mp_lock = 0001; cpuid = 0; lapic.id =
Debugger("panic")
Stopped atDebugger+0x37:movl$0,in_Debugger
db> trace
panic(c021d779,c6235e38,c01b56c4,1,c5d15d60) at panic+0xa8
zerror(1,c5d15d60,c6235ec8,c0887b80,c6235e8c) at zerror+0x3f
zalloc(c0853980) at zalloc+0x54
namei(c6235ea4,c5d15d60,c0234a04,0,80ab220) at nami+0x77
stat(c5d15d60,c6235f80,80e0c90,80e0c60,bfbfd5dc) at stat+0x44
syscall(2f,2f,2f,bfbfd5dc,80e0c60) at syscall+0x16e
Xint0x80_syscall() at Xint0x80_syscall+0x31
Current process was zsh. I found in ps (from DDB) than c5d15d60 is the "proc"
value for this process. The machine was idle (running ntpd, Postfix).
db> show registers
cs 0x8 gd_npxproc
ds 0xc6230010
es 0x802x0010
fs 0xc0250018 db_break_table+0x638
ss 0x10 gd_switchtime
eax0x12 gd_switchtime+0x2
ecx 0x1
edx 0xc026b000 cpl_lock
ebx 0xc021d779 __set_sysuninit_set_sym_M_ZONE_uninit_sys_uninit+0x8d
esp 0xc6235df8
ebp 0xc6235e00
esi 0x100 gd_prv_PADDR1+0x40
edi 0
eip 0xc01d277f Debugger+0x37
efl 0x256
I'm generating a core dump. Please note that as tara is my test machine, I use
"INVARIANT" & "INVARIANT_SUPPORT". Should I remove them ?
It seems that from my reading of the code, the panic would not had happened
without INVARIANT.
Here is the trace from kgdb:
SMP 2 cpus
IdlePTD 3354624
initial pcb at 253280
panicstr: from debugger
panic messages:
---
panic: zone: entry not free
mp_lock = 0001; cpuid = 0; lapic.id =
panic: from debugger
mp_lock = 0002; cpuid = 0; lapic.id =
boot() called on cpu#0
dumping to dev (13,196609), offset 131072
dump 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 2
2 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:291
291 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=260) at ../../kern/kern_shutdown.c:291
#1 0xc0147201 in panic (fmt=0xc0208df4 "from debugger")
at ../../kern/kern_shutdown.c:515
#2 0xc01271f5 in db_panic (addr=-1071831169, have_addr=0, count=-1,
modif=0xc6235cc4 "") at ../../ddb/db_command.c:433
#3 0xc0127194 in db_command (last_cmdp=0xc0232970, cmd_table=0xc02327d0,
aux_cmd_tablep=0xc024f904) at ../../ddb/db_command.c:333
#4 0xc012725a in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc012929b in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc01d24ca in kdb_trap (type=3, code=0, regs=0xc6235db8)
at ../../i386/i386/db_interface.c:157
#7 0xc01e571c in trap (frame={tf_fs = -1071316968, tf_es = -2144600048,
tf_ds = -970784752, tf_edi = 0, tf_esi = 256, tf_ebp = -970760704,
tf_isp = -970760732, tf_ebx = -1071523975, tf_edx = -1071206400,
tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1071831169, tf_cs = 8, tf_eflags = 598, tf_esp = -1071499293,
tf_ss = -10715891}) at ../../i386/i386/trap.c:534
#8 0xc01d277f in Debugger (msg=0xc020d8d2 "panic") at machine/cpufunc.h:64
#9 0xc01471f8 in panic (fmt=0xc021d779 "zone: entry not free")
at ../../kern/kern_shutdown.c:513
#10 0xc01b5a9f in zerror () at ../../vm/vm_zone.c:455
#11 0xc01b56c4 in zalloci (z=0xc0853980) at ../../vm/vm_zone.h:91
#12 0xc016af87 in namei (ndp=0xc6235ea4) at ../../vm/vm_zone.h:117
#13 0xc0171338 in stat (p=0xc5d15d60, uap=0xc6235f80)
at ../../kern/vfs_syscalls.c:1668
#14 0xc01e5f9a in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077946916, tf_esi = 135138400, tf_ebp = -1077946800,
tf_isp = -970760236, tf_ebx = 135138448, tf_edx = 135138400,
tf_ecx = 135138304, tf_eax = 188, tf_trapno = 12, tf_err = 2,
tf_eip = 672140844, tf_cs = 31, tf_eflags = 582, tf_esp = -1077948072,
tf_ss = 47}) at ../../i386/i386/trap.c:1056
#15 0xc01d2eb1 in Xint0x80_syscall ()
#16 0x804ba24 in ?? ()
#17 0x804b786 in ?? ()
#18 0x804b672 in ?? ()
#19 0x804b2e4 in ?? ()
#20 0x804aa4b in ?? ()
#21 0x80552be in ?? ()
#22 0x8053494 in ?? ()
#23 0x8052df3 in ?? ()
#24 0x8052a82 in ?? ()
#25 0x805f851 in ?? ()
#26 0x804a32b in ?? ()
#27 0x804a125 in ?? ()
If needed I can explore more variables.
Client (tara) is a 2x PPro/200, Intel PFX440 motherboard, 64 MB RAM. I SCSI
disk on the on-board SCSI controller (AHC-788
Re: ATA - Trouble mounting secondary master
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> So I still stick with my statement that the -current bootblocks/loader >> doesn't have the computrons needed to use the ad device (or any non >> wd/da/fd device for that matter) for anything usefull :) > >The loader is fine; the problem is just that Poul never finished fixing >the mountroot code. All the loader does is read /etc/fstab and pass in >the entry for /. It's up to the kernel to work it out from there, and >that's where it's falling down. Excuse me! I fixed boot -a, and you came rushing in and said that the boot code could use the same thing, so obviously I expected you to do that, since the boot code is your baby... I don't even know where to look for the cookies left by the bootcode... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
< said: >> [Quoting somebody unidentified, presumably Warner:] >> Shouldn't the apm stuff use the new-bus hooks? I've migraded a couple >> of uses in pccard to using that now that I have newbus node to hang >> them off of... > APM is only attached to the ISA bus for crufty reasons; I'm going to > take it off shortly and use the kernel environment to pass it options. You missed the point. The bus hierarchy has support designed-in to pass power-management requests down the device tree. The only functions which should be registering themselves with APM directly are: 1) Old device drivers using a compatibility shim, or 2) Kernel code which is not a device driver. If you need more functionality than DEVICE_SUSPEND and DEVICE_RESUME, then add more methods. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
> As David O'Brien wrote ... > > > "Another possibility, if you have the RAM, is to use the team(1) > > > program (it's in the ports) to buffer the data as it goes to the burner. > > > > Any reason not to use ``cdrecord -fs=64m'' (or some simular size) > > Any reason to? I mean, I never had to go over the default cdrecord > uses. But I only have a 2x writer and I generally create an iso image > file first. > At 2x, 300kb/sec , the default cdrecord fs's buffer size provides 13 seconds of buffering that should be enough for most cases. At higher speed the amount of prepocessing that mkisofs does starts playing a more important role however if you have created a iso image then mkisofs is not a factor. For illustrative purposes, here is a sample command execution for mkisofs piping an iso 9660 file stream to cdrecord: mkisofs -R /mount | cdrecord -blank=fast -v fs=4m speed=3 - That sample command syntax is sufficient for a "normal" cd creation someone like JKH can probably tell us if it is sufficient for creating a FreeBSD cdrom "package" distribution --- that is a resonable large filesystem structure. Cheers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
> So I still stick with my statement that the -current bootblocks/loader > doesn't have the computrons needed to use the ad device (or any non > wd/da/fd device for that matter) for anything usefull :) The loader is fine; the problem is just that Poul never finished fixing the mountroot code. All the loader does is read /etc/fstab and pass in the entry for /. It's up to the kernel to work it out from there, and that's where it's falling down. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: at_shutdown going away
> In message <[EMAIL PROTECTED]> Mike Smith writes: > : Seriously though, I'm in the process of replacing a number of the > : ad-hoc event handler callout lists in the kernel (most notably the > : at_shutdown and apm* lists) with a generic implementation. > > Shouldn't the apm stuff use the new-bus hooks? I've migraded a couple > of uses in pccard to using that now that I have newbus node to hang > them off of... APM is only attached to the ISA bus for crufty reasons; I'm going to take it off shortly and use the kernel environment to pass it options. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
> Then there is no advantage in using `team' vs. ``cdrecord -fs=XX'', right? > > -- > -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) As far as I can tell there is no difference other one component less to use and ease of use. Cheers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
> > > "Another possibility, if you have the RAM, is to use the team(1) > > > program (it's in the ports) to buffer the data as it goes to the burner. > > > > Any reason not to use ``cdrecord -fs=64m'' (or some simular size) > > Any reason to? I mean, I never had to go over the default cdrecord uses. Since the author was already suggesting the use of team(1) he obvisiously wants a larger buffer. I was mearly asking if there was something about team(1) better than ``cdrecord -fs=XX''. -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic early in boot, no dumpon
I am purposely panic()ing the system early in boot so I can get a look at some startup information... unfortunately the 'config kernel dumps on...' no longer works. how is one supposed to get crash dumps from early in the boot process? -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de.c breakage ?
Hi, my mentor :-) phk> Am I the only one to see these ? Me too. I found it other files as well. It seems that adding following line is required in some source code. #include To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
Sorry to late...
plm> Now suspend works. However still the disks keep spinning until they
plm> reach their BIOS timeout. In Linux & Windows, there is some hook when
plm> going to suspend mode that spins down the (IDE) disks. This is nice,
plm> since it is well possible that you go to suspend but do not set a disk
plm> spindown timeout.
I read linux source code closely again, I found their hack in
IDE device driver. Does anyone know this could make differences on
suspending?
>From linux/drivers/block/ide.c Version 6.18 August 16, 1998:
void ide_intr (int irq, void *dev_id, struct pt_regs *regs)
{
unsigned long flags;
ide_hwgroup_t *hwgroup = (ide_hwgroup_t *)dev_id;
ide_hwif_t *hwif;
ide_drive_t *drive;
ide_handler_t *handler;
__cli();/* local CPU only */
spin_lock_irqsave(&hwgroup->spinlock, flags);
hwif = hwgroup->hwif;
if ((handler = hwgroup->handler) == NULL || hwgroup->poll_timeout != 0) {
/*
* Not expecting an interrupt from this drive.
* That means this could be:
* (1) an interrupt from another PCI device
* sharing the same PCI INT# as us.
* or (2) a drive just entered sleep or standby mode,
* and is interrupting to let us know.
* or (3) a spurious interrupt of unknown origin.
*
* For PCI, we cannot tell the difference,
* so in that case we just ignore it and hope it goes away.
*/
#ifdef CONFIG_BLK_DEV_IDEPCI
if (IDE_PCI_DEVID_EQ(hwif->pci_devid, IDE_PCI_DEVID_NULL))
#endif /* CONFIG_BLK_DEV_IDEPCI */
{
/*
* Probably not a shared PCI interrupt,
* so we can safely try to do something about it:
*/
(void)ide_ack_intr(hwif->io_ports[IDE_STATUS_OFFSET],
hwif->io_ports[IDE_IRQ_OFFSET]);
unexpected_intr(irq, hwgroup);
}
spin_unlock_irqrestore(&hwgroup->spinlock, flags);
return;
}
... but I've seen this kind of hack in wd device driver before.
How about spin down from userland (apmd) using camcontrol(8) like tool?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
if_de.c breakage ?
Am I the only one to see these ? critter# make 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 -DKERNEL -include opt_global.h -elf ../../pci/if_de.c ../../pci/if_de.c: In function `tulip_pci_attach': ../../pci/if_de.c:5316: warning: implicit declaration of function `EVENTHANDLER_REGISTER' ../../pci/if_de.c:5316: `shutdown_post_sync' undeclared (first use in this function) ../../pci/if_de.c:5316: (Each undeclared identifier is reported only once ../../pci/if_de.c:5316: for each function it appears in.) ../../pci/if_de.c:5317: `SHUTDOWN_PRI_DEFAULT' undeclared (first use in this function) *** Error code 1 Stop. critter# -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
plm> If I use 'zzz', I have to do the known 'sleep 1; zzz' trick. This is plm> the difference. I'll commit the patch for `key release event prevent suspend' problem if no objections. Thanks a lot! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: apm problems.
Hi, sorry to late.
> > 1. Standby by PM timer in BIOS setting fails with the system activity.
>
> If by fails you mean enters standby mode, then yes the computer enters
> standby mode while the system is active, after the period of time set in
> the bios, as long as no keys have been pressed on the keyboard during
> that time.
Ah, If you want to reject the standby request from BIOS while the
system is active, then apmd would be useful. You can configure it like
this:
in /etc/apmd.conf:
apm_event PMEV_STANDBYREQ {
reject;
}
or
apm_event PMEV_STANDBYREQ {
exec "/etc/rc.standby_with_system_activity";
}
with /etc/rc.standby_with_system_activity:
#!/bin/sh
if [ some_script_to_check_system_is_active ]
then
# apmd will reject the event...
exit 1
fi
> > 2. No new process can be started after resume.
> > Is it correct?
>
> Yes, although this doesn't happen every time, sometimes everything is ok
> after a resume.
> This seems to be very repeatable following these steps.
>
> cd /usr/bin
> cp * /tmp &
> sleep 1 && apm -z (while copy is still in progress)
> [hit a key]
> any new process started freezes, nothing happens (including logins in
> getty, halt etc).
I tried these steps many times, but I couldn't see the problem.
I guess your disks are still in a SLEEP after a resume or
I/O interrupts were lost during suspend/resume or something.
Anyone suggestions?
> ata0: master: setting up WDMA2 mode on PIIX3/4 chip OK
> ad0: ATA-? disk at ata0 as master
> ad0: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S
> ad0: piomode=4, dmamode=2, udmamode=-1
> ad0: 16 secs/int, 0 depth queue, DMA mode
If your problem is related with disks, have you tried wd device driver
instead of ata?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
As David O'Brien wrote ... > > "Another possibility, if you have the RAM, is to use the team(1) > > program (it's in the ports) to buffer the data as it goes to the burner. > > Any reason not to use ``cdrecord -fs=64m'' (or some simular size) Any reason to? I mean, I never had to go over the default cdrecord uses. But I only have a 2x writer and I generally create an iso image file first. YMMV -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
:> Well, the issue with converting many of the macros to inline functions :> is with the embedded goto's and references to variables defined outside :> the macros. Converting them to functions would basically require :> rewriting a huge chunk of NFS code. :> :My working kernel runs with a few strategic NFS macros being converted :to functions, and the size improvement is about 50K or so (maybe more!!!) : :John If you want to port some of it in that part of the source tree will be available in a month or two, depending on how quickly the other stuff in my queue gets committed. I've got two patch sets currently under test related to other NFS issues and a third one in the wings. Hey, speaking of NFS ... I'm working on optimizing the commit rpc and I noticed something interesting. The commit rpc includes an offset and a length field. Does anyone know why our NFS clients are sending a separate RPC for each 8K buffer? If the dirty space is contiguous across a number of buffers we should be able to send a *SINGLE* commit rpc to the server. That would greatly reduce system overhead on both the client and server when writing a large file over NFS. This would seem to be an almost free optimization that would mesh extremely well with the nfsrv_commit optimizations I'm making right now. At the moment I can saturate a 100BaseTX with NFS writes and get 10 MBytes/sec to the platter on the server, but the cpu required on both the client and server to do that is well over 60% of a Pentium III-450. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Known MMAP() race conditions ... ?
:On Thu, 8 Jul 1999, The Hermit Hacker wrote: :> Three weeks ago, I, and a few other INN administrators, posted about :> FreeBSD -STABLE's inability to run the newest INN code, due to MMAP() race :> conditions...essentially, after X hours of run time, on a heavily loaded :> INN server, the whole thing locks up solid. :> :> At that time, Matt pop'd up and stated that he knew of *at least* 6 MMAP() :> related race conditions that he was hoping to be able to get fixed "within :> a week"...that would have been two weeks ago. : :Maybe I missed that (I'm only on -stable, not -current), but what's the :current situation concerning this issue? : :Can I dare running the newest INN on -STABLE / -CURRENT or do you still :experience these problems? : :Gerald :-- :Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ I've had fixes for CURRENT in the commit queue for a week but they haven't gone in yet. Once they get put in we will be able to backport the interesting parts to STABLE. There isn't much I can do about it without commit privs. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current Kernel build broken
With current source tree as of 9 am pacific, I can no longer build a kernel : cc -c -O2 -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_glob al.h -elf ../../dev/dpt/dpt_scsi.c ../../dev/dpt/dpt_scsi.c: In function `dpt_get_conf': ../../dev/dpt/dpt_scsi.c:389: warning: cast discards `volatile' from pointer tar get type ../../dev/dpt/dpt_scsi.c: In function `dpt_detect_cache': ../../dev/dpt/dpt_scsi.c:496: warning: cast discards `volatile' from pointer tar get type ../../dev/dpt/dpt_scsi.c: In function `dpt_init': ../../dev/dpt/dpt_scsi.c:1187: warning: cast discards `volatile' from pointer ta rget type ../../dev/dpt/dpt_scsi.c: In function `dpt_attach': ../../dev/dpt/dpt_scsi.c:1410: warning: implicit declaration of function `EVENTH ANDLER_REGISTER' ../../dev/dpt/dpt_scsi.c:1410: `shutdown_final' undeclared (first use in this fu nction) ../../dev/dpt/dpt_scsi.c:1410: (Each undeclared identifier is reported only once ../../dev/dpt/dpt_scsi.c:1410: for each function it appears in.) ../../dev/dpt/dpt_scsi.c:1411: `SHUTDOWN_PRI_DEFAULT' undeclared (first use in t his function) *** Error code 1 Stop in /usr/src/sys/compile/pro2. = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: REQ: Test /etc/rc clean-up
> However I'd REALLY like to emphasize again that if we're going to do > this the proper fix is to use case wherever possible. There are > numerous reasons for this, not the least of which are making the > variable case insensitive (and therefore more user friendly) I have to really agree with Doug here. I've seen people use "foo=yes" (vs. "foo=YES") in their rc.conf. They got frustrated when things didn't work. And in IMHO for a no good reason. > I have offered several times to do the work if it has a chance of > being committed, that offer is still good. What do you think Sheldon? -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
At 10:26 AM 8/21/99 +0100, Nik Clayton wrote: >On Fri, Aug 20, 1999 at 07:34:31PM +0200, Andrzej Bialecki wrote: > > Both versions are available at: > > > > http://www.freebsd.org/~abial/matrix_3.2.tgz > > http://www.freebsd.org/~abial/matrix_4.0.tgz >FWIW, there are at least two other 'matrix' implementations out there. >One is part of xscreensaver, and is quite nice -- it's even better if you >halve the size of the image it's using first. This has the advantage that >the characters actually look like the ones in the film (reversed numbers >and Japanese katana (sp?) characters). That one's (obviously) X only. > >The other is 'cmatrix'. A web search should turn it up. As the name >implies, this is a console version. For those of you using Windows or MacOs http://www.whatisthematrix.com/cmp/screensaver_index.html That's the 'official' screen saver. (The Windows version uses some kind of runtime ShockWave and eats nearly 100% cpu, but it looks authentic) Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
> If you have the physical memory sure however if you don't then > you will start swapping and most likely your cd recording will > fail. > > Hence my recommendation for a small size buffer. Then there is no advantage in using `team' vs. ``cdrecord -fs=XX'', right? -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ping/egcs
I'm assuming that you are using egcs-1.1.2. gcc-2.95 seems to work OK. It doesn't discard the initialization of answer like egcs-1.1.2 does. Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA module doesn't work with ATI Mach64 RagePro
Mike Smith wrote (1999/08/11): > > Yes, thanks. Information reported by 0x4F01 function about any video > > mode has set MODE_NON_VGA attribute indeed. And now I have found DOS TSR > > program for VESA support... > > Bleagh. Have you tried ignoring that attribute in our code and seeing > what happens when you select one? Yes - in vesa.c(681-683): From if ((vmode.v_modeattr & (V_MODEOPTINFO | V_MODENONVGA)) != (V_MODEOPTINFO)) continue; to if ((vmode.v_modeattr & (V_MODEOPTINFO)) != (V_MODEOPTINFO)) continue; After this change, splash_pcx with picture 640x480x8 blanks screen and OSD on monitor says "ATTN. NO SIGNAL.: CHECK INPUT SIGNAL CONNECTION OR POWER SAVE MODE HAS BEEN ENABLED". From this time displaying is dead and vidcontrol (ssh root@host "/usr/sbin/vidcontrol 80x25 < /dev/ttyv0") doesn't help, only reboot is helpful... -- Rudolf Cejka ([EMAIL PROTECTED]; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "The Matrix" screensaver, v.0.2
On Fri, Aug 20, 1999 at 07:34:31PM +0200, Andrzej Bialecki wrote: > Both versions are available at: > > http://www.freebsd.org/~abial/matrix_3.2.tgz > http://www.freebsd.org/~abial/matrix_4.0.tgz I knew I should have taken the blue pill. FWIW, there are at least two other 'matrix' implementations out there. One is part of xscreensaver, and is quite nice -- it's even better if you halve the size of the image it's using first. This has the advantage that the characters actually look like the ones in the film (reversed numbers and Japanese katana (sp?) characters). That one's (obviously) X only. The other is 'cmatrix'. A web search should turn it up. As the name implies, this is a console version. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon said: > :> global references across subroutine calls! I'll send Luoqi another email. > :> > :> In the case of the NFS stuff, the changes have been pretty well tested > :> so I think we are in the clear. > : > :On a somewhat similar note, what do you think about converting a lot > :of the NFS macros to functions, yes i know it will be difficult, but > :there is so much forced inlining it just seems like it would reduce > :the codesize signifigantly and play nicer with the CPU cache. > : > :It would also make the code a lot more readable. > : > :Worthwhile exercise? > : > :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > > Well, the issue with converting many of the macros to inline functions > is with the embedded goto's and references to variables defined outside > the macros. Converting them to functions would basically require > rewriting a huge chunk of NFS code. > My working kernel runs with a few strategic NFS macros being converted to functions, and the size improvement is about 50K or so (maybe more!!!) John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
It seems Mike Smith wrote: > > Our boot blocks/loader dont have the needed computrons to use the > > "ad" device name. However I have some patches to boot2 that allows > > to boot off an ad root device, provided you dont use the loader, and > > put the rigth boot string in boot.config. > > This should now be totally redundant as long as your /etc/fstab entry > is correct. Define "correct" then please, it doesn't work for my definition... -Current as of aug 21th... If I have this in my fstab: /dev/ad0a / ufs rw 1 1 /dev/ad0f /usrufs rw 2 2 /dev/ad0e /varufs rw 2 2 And have NO wd* entries in /dev, it says on boot: Changing root device to wd0s1a Changing root device to wd0a ... mount: /dev/ad0a on / special device does not match mounted device. Bummer! If however I have a /dev/wd0a it will mount that and show that in a mount/df command, but then it doesn't fit what it is written in /etc/fstab and that is bogus too... So I still stick with my statement that the -current bootblocks/loader doesn't have the computrons needed to use the ad device (or any non wd/da/fd device for that matter) for anything usefull :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
>If you don't have the time to trim, we don't have the time to read your Easy , Easy we are coming along fine so far so please keep the flame temperature down. If you are compelled or annoyed at the poster send him private e-mail and possibly a pointer to net - etiguette. If you do it nicely you may actually make a long term friend ... Cheers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
If you have the physical memory sure however if you don't then you will start swapping and most likely your cd recording will fail. Hence my recommendation for a small size buffer. And to the list. Please keep the comments or suggestions rolling and hopefully by early next we will have a nice "How To Burn CD " document. Cheers > > "Another possibility, if you have the RAM, is to use the team(1) > > program (it's in the ports) to buffer the data as it goes to the burner. > > Any reason not to use ``cdrecord -fs=64m'' (or some simular size) > > -- > -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Forgotten debug messages in ahc
After compiling yesterday's -current kernel, I see the following in dmesg: ... ahc0: aic7880 SBLKCTL = 0x0 SSTAT0 = 0x0 SFUNCT = 0x0 Single Channel A, SCSI Id=7, 16/255 SCBs ... Notice the "SBLKCTL"... stuff. I guess this is some forgotten debug printf left, or am I mistaken? Blaz Zupan, [EMAIL PROTECTED], http://www.herbie.amis.net Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cc -O broken in -current for Alpha KLDs
On Fri, 20 Aug 1999, Andrew Gallatin wrote: > > Doug Rabson writes: > > On Thu, 19 Aug 1999, Andrew Gallatin wrote: > > > > > > > > I do most of my development on alphas & I just turned some local code > > > into a loadable kernel module. It works fine when compiled into the > > > kernel statically, but fails miserably when loaded into an alpha > > > kernel as a module. This alpha is running -current from monday or > > > so. > > > > > > After a day or so of debugging, I decided to run > > > it on an x86 -- it ran just fine. I've narrowed the problem down to > > > one involving optimization and have extracted a simple, reproducable > > > test case. > > > > > > When the test module is loaded without optimization (CFLAGS += -g > > > -O0), it prints the following (which is correct): > > > > It looks like we aren't handling the relocations correctly. When I get a > > chance, I will try to look at it. If you want to have another look, the > > code at fault is probably in alpha/alpha/elf_machdep.c and you can get a > > list of relocations in the module with 'objdump --dynamic-reloc foo.ko'. > > Thanks for the pointer, it was right on the money. It turns out that > at the default optimization level, the objdump output looks like this: > > <...> > 00010ea8 RELATIVE *ABS* > 00010e80 GLOB_DAT Xmit_completes+0x0028 > 00010e88 GLOB_DAT Xmit_completes+0x0008 > 00010e90 GLOB_DAT Xmit_completes+0x0010 > 00010e98 GLOB_DAT Xmit_completes+0x0018 > 00010ea0 GLOB_DAT Xmit_completes > 00010e70 JMP_SLOT printf > <...> > > I've just committed a patch to alpha/alpha/elf_machdep.c which takes > into account the addends for objects of type R_ALPHA_GLOB_DAT. This > fixes my problem. Should it be MFC'ed? I think it can be MFC'ed right away. There are no dependancies on the rest of the system and its a serious problem. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
On Fri, Aug 20, 1999 at 01:04:47PM +0200, Werner Griessl wrote: Werner, like you we all got 246 line email message. You did not have to quote the *ENTIRE* thing back to us just to add 3 lines. If you don't have the time to trim, we don't have the time to read your reply. -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How To Burn CDs
> "Another possibility, if you have the RAM, is to use the team(1) > program (it's in the ports) to buffer the data as it goes to the burner. Any reason not to use ``cdrecord -fs=64m'' (or some simular size) -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb-4.17 in FreeBSD 4.0-CURRENT
> I managed to build gdb-4.17 in FreeBSD 4.0, here's how to do it: ... > Then it should all build (and perhaps work). The same hacks probably apply > to gdb-4.18 and gdb-current (but so far gdb-4.17 is the most useful version > I've seen for debugging C++). Are you saying 4.17 is better than 4.18 for debugging C++? Or are you saying you didn't know FreeBSD comes with gdb: $ which gdb gdb is hashed (/usr/bin/gdb) $ gdb --version GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. ... -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Known MMAP() race conditions ... ?
On Thu, 8 Jul 1999, The Hermit Hacker wrote: > Three weeks ago, I, and a few other INN administrators, posted about > FreeBSD -STABLE's inability to run the newest INN code, due to MMAP() race > conditions...essentially, after X hours of run time, on a heavily loaded > INN server, the whole thing locks up solid. > > At that time, Matt pop'd up and stated that he knew of *at least* 6 MMAP() > related race conditions that he was hoping to be able to get fixed "within > a week"...that would have been two weeks ago. Maybe I missed that (I'm only on -stable, not -current), but what's the current situation concerning this issue? Can I dare running the newest INN on -STABLE / -CURRENT or do you still experience these problems? Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [fwd] [fm/news] newsletter for Aug 18th 1999, 23:59
Hi Linux land does not look so pretty now days ... Playing with Sun's java jre on linux. Ran jre libgc on redhat 6.0 no problem. slackware 4.0 appears to only like jre libc Suse 6.1 does not like either jre libc nore jre libgc. So on My customer should ship an entire linux box with their product 8) Be Happy -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
