Re: VMware Workstation 3.0 For FreeBSD
> Does anyone know if there is an active effort to port VMware Workstation > 3.0 for Linux to run under FreeBSD ?? Version 2 of Workstation is no longer > avaiable it seems... It is still available, in the Support/Archive section of their website. I'd love to know if someone plans to port 3.0 though, because it offers a lot of added functionality... Best regards, Andrzej // -------- // Andrzej Bialecki <[EMAIL PROTECTED]>, Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // // <[EMAIL PROTECTED]> FreeBSD developer (http://www.freebsd.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On Fri, 12 Oct 2001, Jordan Hubbard wrote: > Cool! Committed to -current. Of course, this should really be rolled > into the loader so that the sequence is more like this: > > > Would you like to load any additional kernel modules (y/n)? y > Please insert modules floppy and press return: > doing loads on any selected> > Please insert mfsroot floppy and press return: > > > > That way there's no need for a deviceRescan() and the user doesn't > have to remember to invoke the Load KLD menu item before selecting an > Installation type. I remember some german(?) guy even writing a bunch > of FICL primitives for doing those sorts of UIs. I wonder what ever > happened to that stuff? If you mean what I mean, that guy was Polish, and that stuff still sits in the tree: src/boot/i386/libi386/vidconsole.c (look for TERM_EMU) src/share/examples/bootforth/frames.4th It is even enabled by default. -- Andrzej // -------- // Andrzej Bialecki <[EMAIL PROTECTED]>, Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // // <[EMAIL PROTECTED]> FreeBSD developer (http://www.freebsd.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: just moved to current, mouse is jerky
Raymond Kohler wrote:
>
> - Original Message -
> From: "Donald J. Maddox" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 30, 2001 12:10 AM
> Subject: Re: just moved to current, mouse is jerky
>
> > Try not using /dev/{u}random (don't load random.ko at boot). The random
> > device uses mouse interrupts to harvest entropy, and it can cause some
> > real jerkiness in the mouse. Of course, if you need to use something
> > that really NEEDS good randomness, like SSH, then not loading random.ko
> > is not really an option :(
>
> Actually, I'm not loading Yarrow in the first place. That's why I think this
> is weird.
> (That and the fact that the last time I tried current, just after the
> 4.0-RELEASE was
> split off, this was already happening.) It only happens on this box and
> apparently
> nobody else sees this exact problem (the last time I asked about it, back
> then,
> nobody answered it). I'm going to try it as a serial mouse and see what
> happens.
Are you running a fresh current? It happened to me about 2-3 weeks ago -
exactly the same symptoms, but then last Friday I did a 'make world' and
the problem disappeared. I'm running Inspiron 5000, using internal
track-pad (/dev/psm0, ps/2 mouse), no fancy modules settings, just plain
-current - whether this loads random.ko I have no idea ATM.
--
Andrzej
//
// Andrzej Bialecki <[EMAIL PROTECTED]>, Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
//
// <[EMAIL PROTECTED]> FreeBSD developer (http://www.freebsd.org)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Broken procfs/status, related to kthreads
On Mon, 5 Feb 2001, Bruce Evans wrote: > On Sun, 4 Feb 2001, Andrzej Bialecki wrote: > > > According to procfs(5), the status line contains several well-defined > > fields separated by spaces. However, the kernel thread names look like > > 'swi5: task queue' and 'swi1: net', which results in variable number of > > space-separated fields. As a consequence, some software that parses this > > line gives incorrect results. > > I think procfs never actually implemented this. Program names may > have spaces in them too. Of course, the line is too hard to parse if > the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX > prevent the command name being the contents of another process's > status line :-). Ok, then how should this be fixed? We could escape the space characters with something: swi5:$task$queue 14 0 0 0 -1,-1 noflags 981365276,40 0,0 0,0 nochan 0 0 0,0 - and for command name 'my$prog': my$$prog 334 1 332 0 -1,-1 noflags 981361691,37404 0,0 0,5748 select 0 0 0,0 - or similar... The commands with $ in them are much less likely than the names with spaces, which on -current are guaranteed to occur. 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
Broken procfs/status, related to kthreads
Hi, Whoever made procfs aware of kernel threads broke also the /proc/%pid/status line. Or, maybe it's a by-product of showing kthreads in the proc table... According to procfs(5), the status line contains several well-defined fields separated by spaces. However, the kernel thread names look like 'swi5: task queue' and 'swi1: net', which results in variable number of space-separated fields. As a consequence, some software that parses this line gives incorrect results. I noticed this while trying to fix mysterious coredumps in src/release/picobsd/tinyware/aps (which is obsolete anyway, but it should work). 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: number of processes forked since boot
On Tue, 16 Jan 2001, Hajimu UMEMOTO wrote: > Hi, > > I wish to obtain number of processes forked since boot from userland. > So, I made a patch to intend to commit. > Any comment? > Index: sys/kern/kern_fork.c > diff -u sys/kern/kern_fork.c.orig sys/kern/kern_fork.c > --- sys/kern/kern_fork.c.orig Fri Jan 12 02:46:53 2001 > +++ sys/kern/kern_fork.c Tue Jan 16 02:30:26 2001 > @@ -146,6 +146,9 @@ > int nprocs = 1; /* process 0 */ > static int nextpid = 0; > > +static unsigned int nforks = 0; > +SYSCTL_UINT(_kern, KERN_NFORKS, nforks, CTLFLAG_RD, &nforks, 0, ""); If any, I think this should be long, otherwise on machines like web servers the counter will overflow in a short time. 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: Head's up: Yarrow-style periodic entropy saving
On Thu, 11 Jan 2001, Doug Barton wrote: > For the sake of those who don't follow commit messages (shame on you!), > here's your fair warning regarding this change. This is the promised update > that periodically (every 3 minutes by default) saves 2k of randomness to a > set of rotating files stored by default in /.entropy. That location was > chosen so that it could be loaded as early as possible in the boot process. On / ? that's quite inconvenient for systems running with read-only root FS... 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: securelevel and sysctl
On Wed, 10 Jan 2001, Tomasz Paszkowski wrote: > > I'am working on module, which catches __sysctl system call, and on > securelevel grater than 3, refuse any changes of sysctl oids. Are there any You might want to take a look at SPY module (http://people.freebsd.org/~abial/spy). > problems, which might happen after blocking sysctl oids change ? > AFAIR there is no such application running in user Space,which requires > ability to change sysctl oids,is there ? Several oids are changed on system startup. Others are accessed read-only to provide system information. > Secondly I'was thinking about oids,which are needed for user space aplications > to work. I figured out,that vi use some (I didn't check which one) oid on > startup, so is there a list of oids used by user space applications ? Well, it depends on what the user applications want to access, doesn't it :-). Theoretically, this list could be all oids. Practically, it depends on the user applications that are installed... 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: fxp driver not reset after Windows reboot?
On Sat, 16 Dec 2000, Jonathan M. Bresler wrote: > > Andrzej, > > did you receive a response regarding your email the Pro 10/100B/100+ Ethernet> being unresponsive after running windows? > i seem to have the same problem. Yes and no. The answer provided by dg (I think) was that Win powered it down, and our apm doesn't know how to restore it. But no fix was forthcoming, as far as my knowledge goes.. For me, it helps when I power-cycle - soft reboot sometimes helps as well. 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: fxp driver not reset after Windows reboot?
On Sun, 10 Dec 2000, Mark Huizer wrote: > Hello, > > On my VAIO laptop, I have trouble rebooting directly from Windows to > FreeBSD (luckily enough I don't run Windows that often :-) > I tried to look at the driver code, but it looks to me like it is doing > resets when attaching the fxp driver, but somehow, Windows has left it > in the state where it isn't recognized properly. > fxp0: port 0xfcc0-0xfcff mem >0xfed0-0xfedf,0xfecff000-0xfecf irq 9 at device 11.0 on pci0 > fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps I have exactly the same symptoms. The card is in a docking station for Dell Inspiron 5000. Looks like it's sort of standard behaviour nowadays... 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
AcrobatReader4 crashes
Hi, On recent -current (as of yesterday), linux acroread4 no longer works properly. The main window comes up, but then either it crashes immediately, displays copy of the background or a messed-up fragments of document contents (menus still work), and after a couple of seconds crashes anyway with 'Exited with error code: 0x400e0009'. There is no coredump, however. The system is -current after full make world. The modules are in sync with the kernel. Good old Windows way (reinstall the app) doesn't help either. Anyone seeing something similar? 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: "make release" breakage - dokern.sh patch 2
On Tue, 24 Oct 2000, Jordan Hubbard wrote: > Believe me, if we were to put out a serious call to kill NFS from the > installation boot images, you'd very quickly hear from all of those > people and they would be screaming. We need to exhaust all other > possibilities before we even contemplate that option. IMHO the battle to keep the floppies from overflowing is already lost. Each time it's like cutting out your limbs to fit into tight clothes. What I think we need is to find new clothes, so to speak, i.e. some other way of organizing the content on the floppies. If we don't do it, we will keep loosing. E.g. we could move some of the drivers to the mfsroot.flp as KLDs, and either autoload them later (i.e. not from the bootloader, but using kldload), or have some options in the menu for loading. This way at least we will avoid overflowing kern.flp. 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: etc/rc.d & things...
On 10 Jul 2000, Cyrille Lefevre wrote: > > and my favorite substitute proposal: > > > > http://www.roguetrader.com/~brandon/sas/. > > effectively, the last one is interresting. a major problem w/ this one is the > use of "perl" which is not available a boot time since it is located in /usr. If we find out that it's very interesting, it should be implemented as part of init(8). (hint: init is NOT Perl based ;-) 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: etc/rc.d & things...
On Tue, 11 Jul 2000, Daniel C. Sobral wrote: > Andrzej Bialecki wrote: > > > > > and my favorite substitute proposal: > > > > > > http://www.roguetrader.com/~brandon/sas/. > > > > I really like the ideas in the last one. The pages were not updated for > > some time - do you know if the author still works on it? > > No clue. At the time he decided to have a take on it, I traded many > messages with him about it. I know he had part of it working, and could > boot with it. After that, though, I never heard from him again. > > Like you, I really like his proposal. Hmm... Soon I will have some free time (holidays and stuff..). I'll take a look at it. It looks too good to be wasted. 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: etc/rc.d & things...
On Mon, 10 Jul 2000, Daniel C. Sobral wrote: > This has been talked to death. Look at these: > > http://www.freebsd.org/~dfr/devices.html > http://www.freebsd.org/~eivind/newrc.html > > and my favorite substitute proposal: > > http://www.roguetrader.com/~brandon/sas/. I really like the ideas in the last one. The pages were not updated for some time - do you know if the author still works on it? 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: Possible bug in netinet6/in6_rmx.c ?
On Fri, 7 Jul 2000, Jonathan M. Bresler wrote: > > > > > By the way, while we are talking about sysctl, I don't suppose you would be > > > willing to review/commit PR 15251? It is a fairly straightforward patch that > > > > I see Jonathan Bresler took it (today). > > > > wow dude! put me on the spot or something! > > jmb ^^^ Ok, so it was jhb, not jmb... Just one letter difference ;-) 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: Possible bug in netinet6/in6_rmx.c ?
On Sun, 2 Jul 2000, Kelly Yancey wrote: > On Sun, 2 Jul 2000, Andrzej Bialecki wrote: > > > Hi, > > > > While working on adding dynamic sysctls support, I discovered something > > that looks like a bug. > > > > For kernels that have both INET and INET6, three sysctl entries (rtexpire, > > rtminexpire, rtmaxcache) are registered twice - both in netinet/in_rmx.c > > and netinet6/in6_rmx.c. > > > > It seems they should be registered only once, within a section that is > > common to INET and INET6. > > > > Andrzej Bialecki > > > > I think the real problem is that the rtexpire, rtminexpire, and rtmaxcache > variables are each declared static in netinet/in_rmx.c and again in > netinet6/in6_in6_rmx.c. Do we really need separate learned route expiration > times for ip4 and ip6? If the answer is yes, then the solution should be to > move the ip6 versions under the net.inet.ip6 sysctl tree. > Otherwise, as you suggest, rtexpire and friends need to be common (maybe > directly under net.inet?) Yeah, something like that. The question is who is going to fix it? INET6 issues should probably stay in sync with other BSDs and KAME, and therefore IMHO the maintainer of inet6 code should step out and fix it... (Hello?? :) > By the way, while we are talking about sysctl, I don't suppose you would be > willing to review/commit PR 15251? It is a fairly straightforward patch that I see Jonathan Bresler took it (today). 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: cvs commit: ports/textproc/libxml2 Makefile ports/textproc/libxml2/files md5 ports/textproc/libxml2/pkg PLIST
On Sun, 2 Jul 2000, Garrett Wollman wrote:
> < said:
>
> > Bring libxml2 2.1.1 into the fold after a repo-copy. This will
> > eventually replace libxml for GNOME.
>
> About a month ago, I was looking for a reasonable XML library with an
> eye towards bringing one into the tree (to be used for config files
> which have grown too complicated in syntax, like {,new}syslog.conf).
> I didn't find one which met the desired criteria of:
>
> - Reasonably small
>
> - Provides a reasonable tree-based interface for C programs (i.e.,
> not DOM or anything that looks remotely like it)
>
> - Comes under a BSD-compatible license
>
> Does anyone know of such a library?
Hmm.. Expat (ports/textproc/expat)? There is also a 'lite' version
available. It provides SAX interface (which I personally like the
most). Mozilla license.
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
Possible bug in netinet6/in6_rmx.c ?
Hi, While working on adding dynamic sysctls support, I discovered something that looks like a bug. For kernels that have both INET and INET6, three sysctl entries (rtexpire, rtminexpire, rtmaxcache) are registered twice - both in netinet/in_rmx.c and netinet6/in6_rmx.c. It seems they should be registered only once, within a section that is common to INET and INET6. 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: XML driver config file to replace LINT
On Wed, 28 Jun 2000, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Thomas M. Sommers" writes: > : Warner Losh wrote: > : > > : > Any reason that the .c/.h files of the drivers couldn't be used to > : > generate this information? > : > : Or perhaps the other way around. > > No. I'm saying that the .c and .h files (likely .h) are the source to > the driver and driver maintanier are 1000% more likely to keep those > up to date than they are xxx.xml. Right now, with modules, you can > easily not have to worry about any config issues outside of those > files. Forcing a doc file just to get docs and breaking this is > undesirable. Expanding what the driver writers are already doing > a little seems like a smarter move. Hmmm.. What if we define a set of macros that are required in order to properly register the driver, but at the same time contain fields like "descr", "syntax"... Something similar to sysctl descriptions.. Oops, perhaps not the best example... ;-) 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: HEADS UP!: config changes...
On Wed, 21 Jun 2000, Daniel C. Sobral wrote: > Andrzej Bialecki wrote: > > > > This thread is long, so maybe I missed something.. Can we have the *.hints > > file loadable as a module of some special type (like kernel.conf), and > > searched for during configuration like userconfig did? > > Funny you got no reply. At last some merciful soul.. Thank you! :-) > > This is not necessary. If you copy said file to /boot/device.hints, it > will be read automatically as a loader .conf file and set environment > variables that will be read automatically by the kernel. > > If you wish to use alternate configurations without tweaking > device.hints, you can do > > loader_conf_files="xyzzy" > > And xyzzy will be read. Since device.hints is read right after > /boot/defaults/loader.conf, anything later will override it's values. That's fine. However, this practically makes using /boot/loader mandatory. I still wonder if having some in-kernel interpreter wouldn't give us more choice, with exactly the same functionality. Of course, it would have to be run before any probing starts... 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: HEADS UP!: config changes...
On Fri, 16 Jun 2000, Peter Wemm wrote: > Chia-liang Kao wrote: > > Hi, > > > > Is there anyway to put the device.hint stuff into kernel nevertheless? > > My diskless box fetches the kernel would know nothing about things reside > > in device.hint. > > That is what the hints directive is for. > > you could create a file "diskless.hints" and add the line to your config > file: > hints "/wherever/diskless.hints" > and the contents of that file would be statically compiled in. You can still > override them at boot time if you wish, but the basic set will be there. > > This is what GENERIC does right now. It compiles GENERIC.hints straight in. > (see hints.c in compile/YOURKERNEL) This thread is long, so maybe I missed something.. Can we have the *.hints file loadable as a module of some special type (like kernel.conf), and searched for during configuration like userconfig did? 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: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility
On Tue, 25 Apr 2000, Jim Bloom wrote: > The RCS info stored in the binaries is insufficient for this purpose. There is > no record of the versions of all included files. Changes to constants and/or > macros would not be identifiable. Yes, you're right, I'm afraid. This could theoretically be solved by adding an ELF section at the build stage, containing the RCS versions from files reported by 'make depend'. But at this point the things get ugly and complicated very quickly... :-( The simple approach could be as follows: start with the official version of the RELEASE (which takes care of having one common version, with known MD5 cksums). The patchkits would contain only the whole files, not diffs. The patch installer would have to examine the target files before doing anything, and if the MD5 checksums (relative to the last patchkit) don't match - present a choice, in a way similar to mergemaster. This way, we can push the responsibility for tracking dependencies to the user... :-/ 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: SMP changes and breaking kld object module compatibility
On Wed, 26 Apr 2000, Daniel O'Connor wrote: > Try buildworld on one machine and installworld on all of your production > boxes.. installworld only takes 10-20 minutes to run on my crappy IDE > disks. Yes, that's what I'm doing now - so far the best method. But still requires having N+1 boxes (which is not a concern for me, but for someone having e.g. 2 boxes in production this represents 1/3 increment), plus topology allowing for using NFS mounts. 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: FreeBSD build status
On Tue, 25 Apr 2000, Poul-Henning Kamp wrote: > > === > SUMMARY > === [27kB long list of errors deleted..] I thought that the final conclusion was to have some other mailing list for this type of messages... ? 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: SMP changes and breaking kld object module compatibility
On Tue, 25 Apr 2000, Paul Richards wrote: > branch. Most commercial users are not developers, and have no interest > in anything relating to development. Professional sysadmins are > conservative creatures, they expect professional quality code to play by > the rules of the industry and those rules are widely accepted as meaning > that stable branches do no undergo ABI changes. Such changes are > reserved for major upgrades because of the consequences and risks > involved. On a similar note: I think one of serious drawbacks of FreeBSD's model for updating and bugfixing the stable branch is 'make world'. It's very inefficient and cumbersome way to do this on production machines. STABLE is stable enough for us to be able to prepare binary patches, which can be applied to a system in some (known) version. Especially security fixes, which are usually limited to specific programs. With such system present I'd be completely satisfied (as a production manager, not as a developer) if I could start with, let's say, 3.4-RELEASE, and then apply binary patches one by one to track STABLE. Instead of putting the machine out-of-service for a couple of hours, it would be 10 minutes. Also, no need to keep the sources around. Of course, implementing such a system requires careful versioning of each file in the standard system, but I think it's possible - just having the MD5 checksums around, for each consecutive patch, should do for start. Don't get me wrong - I love to see what's under the hood, analyze the sources etc. But it's not what is expected in a production environment, (IMHO of course :). 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: Installworld to /some/where/...
On Wed, 5 Apr 2000, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Andrzej >Bialecki writes: > : The reason I'm asking is that I'm looking for a method to easily > : clone/upgrade a bunch of servers without having to do 'make world' on all > : of them. I'm not satisfied either with using dd - the machines are not > : identical, there are some bits and pieces of config specific to each > : machine. So far the best method was to do a make world, but it becomes > : more and more a nuisance and waste of time... > > Two things. One, you could use DESTDIR to install the stuff, but it > won't create a bootable disk. This + mergemaster is a good option to > update an existing disk. > > The other option is do mount /usr/obj on the target machines and do an > make installworld. This usually takes me about 20 minutes or so, > which is much faster than any hardware-hacking I'd need to do to get a > disk from one machine to another. That's exactly what I was looking for. Thank you. Thanks to all who replied! 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
Installworld to /some/where/...
Hi, Is it possible to do an installworld not to / of existing system, but to, say, subdirs somewhere, which could be mountpoints for another disk? Something like: /mnt/installdir/ /mnt/installdir/compat /mnt/installdir/etc /mnt/installdir/usr /mnt/installdir/var /mnt/installdir/ The reason I'm asking is that I'm looking for a method to easily clone/upgrade a bunch of servers without having to do 'make world' on all of them. I'm not satisfied either with using dd - the machines are not identical, there are some bits and pieces of config specific to each machine. So far the best method was to do a make world, but it becomes more and more a nuisance and waste of time... 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: Sysctl for CAM SCSI quirks?
On Mon, 3 Apr 2000, Matthew Jacob wrote: > > These aren't available at boot time when you need them, are they? You will need probably the ability to create sysctls on the fly, which is still on my drawing board. If you can live with creating just completely separate subtrees (no overlap) this code is ready to use. Let me know if you want it. 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: Dynamic sysctls - patches for review
On Sun, 26 Mar 2000, Doug Rabson wrote: > On Sun, 26 Mar 2000, Andrzej Bialecki wrote: > > Well, somehow the idea of overlapping subtrees sounds nice and useful > > IMHO. Any suggestions how to solve these issues? > > > > One possible way to do it would be to keep some ID of the oid's > > creator. Then, for nodes they would be deleted when the refcnt goes to 0 > > (no matter who created them), but for terminals the deletion would succeed > > only for the owners. Also, if you create a subtree not from the root of > > dynamic tree, the refcnt++ would propagate up the tree as well, and > > similarly refcnt-- would propagate on deletion. > > This is a reasonable solution. Another would be for dynamic sysctl users > to use a 'context' object to record all their edits to the tree which > would allow the edits to be backed out without relying on a tree-delete > operation. Could you explain it further? Do you mean something like a transaction log? But this wouldn't work - the operations on the tree can be interdependent between users. 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: Dynamic sysctls - patches for review
On Sun, 26 Mar 2000, Doug Rabson wrote:
> On Fri, 24 Mar 2000, Andrzej Bialecki wrote:
>
> > Hi,
> >
> > Inspired by PR kern/16928 I implemented completely dynamic
> > creation/deletion of sysctl trees at runtime. The patches (relative to
> > -current) can be found at:
> >
> > http://www.freebsd.org/~abial/dyn_sysctl.tgz
> >
> > Included is an example of KLD that creates some subtrees when loaded, and
> > deletes them before unloading.
> >
> > I'd appreciate some feedback. Thanks!
>
> This stuff looks very useful. I have done this kind of thing 'by hand' in
> the past but this should make life quite a bit easier. I think the only
> thing in the patch which I would want to change is to rename
> sysctl_deltree() to sysctl_delete_tree() to be more consistent with the
> naming of other functions.
No problem with me.
> How much has this been tested? I wonder if the code in
> sysctl_deltree() which iterates over the children is correct. Surely the
> SLIST_REMOVE called by the child will screw up the SLIST_FOREACH iterator
Hmmm. Strange - it should be, since it dereferences just freed
pointer... but it worked for me. (8-*
> of the parent. In this kind of situation, I often write things
> differently:
>
> while ((p = SLIST_FIRST(SYSCTL_CHILDREN(oidp)) != NULL) {
> sysctl_deltree(p);
> }
>
> This will make sure that the parent does not access memory after it has
> been freed.
Yes, it looks much better to do that. Well, I tested the code creating a
couple of subtrees, either from root or from one of existing
categories. The code "worked for me", but it's not a proof that it does
the correct thing, obviously...
Also, Jonathan Lemon suggested that the dynamic oids should have a
reference number, so that multiple modules could create partially
overlapping trees, like:
kern.one.two.module1
kern.one.two.module2
kern.one.three.module3
The problem with that approach, however, is that you no longer can delete
a tree - you would need to have a way to delete a path in the tree. When I
started adding the reference count, I faced a problem when module1 deleted
not only kern.one.two.module1, but kern.one.two.module2 as well, because
it kept a reference to the root of custom tree (one), and then called
sysctl_deltree, which of course decremented refcnt in one.two, but deleted
both module1 and module2, as they both had a refcnt=1 :-( This left a
dangling kern.one.two node without any children, and with refcnt=1 (that
of module2).
Another problem is when a module3 just checks for existence of kern.one,
and if it exists, it will not try to create it (thus incrementing refcnt),
but proceed to creating *.three.module3. The refcnt in kern.one will not
be incremented, and when the other two modules will start deleting the
tree, the kern.one will be removed, although the module3 still uses it.
Well, somehow the idea of overlapping subtrees sounds nice and useful
IMHO. Any suggestions how to solve these issues?
One possible way to do it would be to keep some ID of the oid's
creator. Then, for nodes they would be deleted when the refcnt goes to 0
(no matter who created them), but for terminals the deletion would succeed
only for the owners. Also, if you create a subtree not from the root of
dynamic tree, the refcnt++ would propagate up the tree as well, and
similarly refcnt-- would propagate on deletion.
Any comments on that?
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
Dynamic sysctls - patches for review
Hi, Inspired by PR kern/16928 I implemented completely dynamic creation/deletion of sysctl trees at runtime. The patches (relative to -current) can be found at: http://www.freebsd.org/~abial/dyn_sysctl.tgz Included is an example of KLD that creates some subtrees when loaded, and deletes them before unloading. I'd appreciate some feedback. Thanks! 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: make installworld broken???
On Sun, 30 Jan 2000, John Polstra wrote: > > > It's source-dir is called "xinstall" btw. > > Why is the source called "xinstall"? > > To avoid colliding with the standard make target "install". If we > had utilities named "all", "depend", and "clean" we'd have to do the > same thing for them. Mhmmm... Isn't this something that .PHONY target is supposed to handle? 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: boot messages for pci devices...
On Wed, 19 Jan 2000, David Scheidt wrote: > On Wed, 19 Jan 2000, Andrzej Bialecki wrote: > > > > > I did some hacks a while ago on a tool which could be called "devinfo". It > > simply traversed the dev/bus tree and displayed tons of info about each > > node. > > > > Perhaps something like that could be useful instead of full-blown FS? > > > This is something like HP-UX's ioscan(1M)? This would be very handy, even > it only gave info on the hardware the kernel knows about, as opposed to > actually rescanning the busses. No, the code that I wrote doesn't do re-scan. It simply displays the bus info in formatted way. I would have to dust it off and rewrite it in order for it to be usable... Or I can send you the code "as is" and you can finish it. :-) 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: boot messages for pci devices...
On Tue, 18 Jan 2000, Matthew N. Dodd wrote: > On Wed, 19 Jan 2000, Poul-Henning Kamp wrote: > > fxp0: port 0xc400-0xc43f mem >0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0 > > > > Is this level of verbosity really helping anybody ? > > Its consistant, but I need to unify all the resource printing stuff since > theres about 5 different ways that are being used to print the stuff right > now. I'll do this after 4.0R. > > > I thought we printed out the port/mem stuff for ISA because it is > > usually jumpered by the admin, but for dynamic allocation > > busses/devices I think this should be "bootverbose" material. > > Humm... Thats possible. There was talk a while ago about making multiple > levels of verbosity in the bootup messages. I'll explore this when I fix > the line wrapping issues. > > It would really be nice if we could have busfs; this would make it much > easier to allow access to this sort of information. I did some hacks a while ago on a tool which could be called "devinfo". It simply traversed the dev/bus tree and displayed tons of info about each node. Perhaps something like that could be useful instead of full-blown FS? 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: SUBMIT: compat.linux.pathmunge
On Tue, 28 Dec 1999, Doug White wrote: > Hello fellow hackers, > > I've written up a short patch to add a sysctl to control the appending of > /compat/linux/ to path requests in Linux mode. We had to get ADSM's Linux > client working on FreeBSD so we could do backups of our systems. Luckily > it comes statically linked so all was needed was this sysctl and some > creative redirections (there's a bug in the termio ioctl() emulation > still...) to get it working. Funny... I was in the process of doing almost exactly the same changes. Initially, I've done this fo /tmp and /var only, because some software was creating lock files _and_ IPC keys using (obviously) normal /tmp and /var/tmp, and they ended up having very different values, which somehow confused it... Anyway, the solution I would suggest is to have more granularity instead of all-or-nothing. I'd suggest a linked list of paths, set up by compat.linux.pathmunge.paths, and the other sysctl to turn on the checking. If the *paths sysctl is empty, it's equivalent to your functionality. Comments? :-) 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: Toshiba 2100CDS ata hangs and internal modem
On Wed, 22 Dec 1999, Eric J. Haug wrote: > Hi All, > This laptop has a couple of problems with FreeBSD-CURRENT > of about 1999/12/22 12:00 UTC. > The system hangs with the disk drive light on. > The output of boot -vc captured from the serial port follows. > current of about 1999/12/11 works in PIO mode. > > The machine has a built-in modem that appears to be on the pci bus. > The sio1 probes fail. > If the modem is on the pci bus, what would it take to get it going? > sio0: irq maps: 0x41 0x51 0x51 0x51 > sio0 at port 0x3f8-0x3ff irq 4 drq 0 flags 0x30 on isa0 > sio0: type 16550A, console > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: irq maps: 0x41 0x41 0x41 0x41 > sio1: probe failed test(s): 0 1 2 4 Tough luck. It looks lik a Winmodem - the probe message is very much like on my Portege 7020. Just forget it... 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: sysinstall: is it really at the end of its lifecycle?
On Wed, 15 Dec 1999, Adam Strohl wrote: > On Tue, 14 Dec 1999, Jordan K. Hubbard wrote: > > > VESA syscons, either using libvgl and an array of crude widgets or > > something like MGR and its widget set, has long been on the wish-list > > but I didn't even include it in my summary since it's still very much > > a pipe-dream. :-) > > Hmm, this has been a fantasy of mine, as well. I was hoping to assist > with the syscons code enough so that we could get a simple primative API > down for drawing graphics on the screen, but my job seems to be taking up > any time I'd have to do that now, hopefully that will change :P > > However, the syscons cleanup is proceeding anyway from what I've seen on > the list. > > As long as we have basic graphics drawing, we'd be able to impliment our > own widgets, if need be. I don't know how big the requirements for libvgl > are, or how much spare space on that second floppy we have, though. As I said, I know of two examples of more or less complete GUIs, which are either ported to libvgl or can be fairly easily ported. Both of them take about 100kB. 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: sysinstall: is it really at the end of its lifecycle?
On Tue, 14 Dec 1999, Jordan K. Hubbard wrote: > Something we also have to stay aware of in this discussion is the fact > that even if most hackers could give a fig for graphical installers > and consider them to be an unneeded bit of hand-holding, it would > still be nice to have a framework which stuff could drop into and be > accessed via a command line or turbovision type of interface. We're > not talking about writing multiple installers for each type of UI, > after all, since that would be an unreasonable duplication of labor. > We're talking about one installation/configuration code base which can > use either X or text mode interfaces at the user's discretion, so > both "camps" get what they want. I should perhaps mention here that there are windowing GUIs out there which are not X11. I know of two: W (almost dead, but quite sufficient), and Microwindows (very new, still quite limited, but under active development). Both use either VGA or VESA graphics. Both are very small (around 100kB). 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
MAKEDEV (Re: Speaking of moving files (Re: make world broken buildingfortunes ) )
On Mon, 13 Dec 1999, Bill Fumerola wrote: > On Mon, 13 Dec 1999, Louis A. Mamakos wrote: > > > So how about /usr/sbin/chown -> /sbin/chown so that MAKEDEV works with > > just the root file system mounted? > > As one who just got his ass bitten by this, I would vote yes. On a related subject: don't you think it's high time to end up this madness with MAKEDEV being a shell script, and reimplement it in C? Today, MAKEDEV uses about 10 external programs, it's inflexible and complicated, but the task it's doing could be relatively easily ported to C plus config file. Have you ever tried to use it in nonstandad location, or on a minimal system? The end result is usually an unpleasant surprise... 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: syscons extension: "propellers"
On Tue, 14 Dec 1999, Donn Miller wrote: > Oliver Fromme wrote: > > > Actually, I was thinking about that myself. But the problem > > is that the code is very closely integrated into the existing > > syscons code (with a lot of #ifdef's, of course). > > I think another way (instead of ifdefs) would be to provide some > hooks into syscons, so that the "propellers" code can be loaded > or unloaded via kldload/unload. Another way to customize various strings, colors and variables could be via sysctl. It's easy e.g. to set up the "propeller" string via sysctl. 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: Modules and sysctl tree
On Thu, 9 Dec 1999, Archie Cobbs wrote: > Andrzej Bialecki writes: > > I'd like to know whether we reached some conclusions concerning the naming > > of sysctl variables created (or related to) KLDs. I know that Linux > > emulator creates "compat.linux". I don't know if any other module creates > > sysctls (well, except my SPY module.. :-). > > > > So, what is the current thinking? Should we use > > > > modules.my_module.whatever, or > > > > kld.my_kld.whatever, or > > > > just sprinkle the new sysctls randomly over the tree, according to their > > functions, e.g. > > > > kern.my_module_kern_hook > > net.inet.my_module_inet_hook > > ... > > I think the latter. In 'theory' there should be no discernable > difference between functionality from a KLD vs. the same functionality > compiled directly into the kernel. Yes, assuming that the same functionality CAN be compiled in statically. IMHO the kernel modularity is a laudable goal, and if it works well, there are only few cases when you would want to make a monolithic kernel. IMHO, of course :-) > KLD's are just a linking mechanism, and shouldn't have any more > significance than that from a usability perspective. Hah. If it were so simple... Let's take the example of a module foo, which provides unique features of bar and baz. They are unrelated to any already existing category. Where they should be hooked up? kernel? machdep? Then these categories will become a messy, amorphic trashcans. Also, it will be difficult to see which sysctls will disappear when the module is unloaded. Also, if we say that modules should register their sysctls in easily discernible place in the tree, we set up a good example for third party vendors, who otherwise will sprinkle their own sysctls all over the tree... You can probably see from the above what is my preference.. ;-) More or less, my question is: how the sysctl tree will look like when _most_ of the kernel will be in modules? 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
Modules and sysctl tree
Hi, I'd like to know whether we reached some conclusions concerning the naming of sysctl variables created (or related to) KLDs. I know that Linux emulator creates "compat.linux". I don't know if any other module creates sysctls (well, except my SPY module.. :-). So, what is the current thinking? Should we use modules.my_module.whatever, or kld.my_kld.whatever, or just sprinkle the new sysctls randomly over the tree, according to their functions, e.g. kern.my_module_kern_hook net.inet.my_module_inet_hook ... Also, it seems that you cannot create new sysctls (leaves and nodes) at runtime, i.e. after the module has been loaded. 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: why 'The legacy aout build' was removed from current ?
On Thu, 9 Dec 1999, Marcel Moolenaar wrote: > Andrzej Bialecki wrote: > > > > On Thu, 9 Dec 1999, Marcel Moolenaar wrote: > > > > > > Please see Netscape plugin port (ports/www/flashplugin) to find > > > > out why we still have to need a.out support. > > > > > > The port has nothing to do with building a legacy a.out world and > > > consequently works fine (yes, I tested it :-) > > > > Not really. You have to have a.out crt0.o and friends to be able to link > > it. You probably have some old versions around in your system, but they > > are not built by "world" target. Hence, they are not a part of binary > > distrib. > > Yes, I have c++rt0.o in /usr/lib/aout. If I didn't have it, I would be > given directions on how to get it (from the port): > > 1. extract /usr/src/lib (distribution files: src/slib.??) > 2. cd /usr/src/lib/csu/i386 > 3. make depend > 4. make OBJFORMAT=aout clean all install True. But this adds a dependency for this port on the src/lib tree. I was thinking about average people that have binary distribution + kernel sources. They are screwed. 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: why 'The legacy aout build' was removed from current ?
On Thu, 9 Dec 1999, Marcel Moolenaar wrote: > > Please see Netscape plugin port (ports/www/flashplugin) to find > > out why we still have to need a.out support. > > The port has nothing to do with building a legacy a.out world and > consequently works fine (yes, I tested it :-) Not really. You have to have a.out crt0.o and friends to be able to link it. You probably have some old versions around in your system, but they are not built by "world" target. Hence, they are not a part of binary distrib. 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
ANNOUNCE: SPY-0.1 - syscalls monitor
Hi, SPY allows you to monitor and/or selectively block syscalls on your system. It could be used either as a safety monitoring device, policy enforcement, or debugging tool. You can download the sources (NOTE: -current only) from: http://www.freebsd.org/~abial/spy-0.1.tgz Excerpt of README follows: - This kernel module allows you to selectivly monitor and/or disable execution of system calls (syscalls) on your system, and log detailed info to syslog service. It's sometimes desirable to monitor selected syscalls for security reasons, or for debugging. For example, many security holes are related to setuid/setgid programs. You can monitor and log all attempts to use these syscalls. You can also disable certain syscalls altogether, if you really know what you're doing... Already existing tools (like ktrace(1) or truss(1)) can provide much more detailed information, but they are more fit to tracing single processes or process groups, and not setting overall system policy (speaking of which: this module is an example of very primitive auditing and policy enforcing device). Features Using SPY module you can set up your system to: * log detailed info on execution of any selected syscall. In case of a few most important ones, there are specific handlers to log also the arguments of the syscall in understandable format. They are as follows: execve, set*id, chdir, open, link, unlink, chmod, chown, mkdir, rmdir (You are welcome to add others :-) Any syscall can be monitored, but in general case its arguments cannot be interpreted. * set kind of information to be logged. You can restrict logging on a per syscall basis, with the following constraints (OR-ed): - uid or gid - superuser only - all users except superuser - combination of the above You can also adjust level of logging on a per syscall basis. There are three levels available: - basic: logs minimum information sufficient to identify the syscall and process owner - arg: logs also the arguments of the syscall, if possible - full: logs all information available. * disable selected syscalls, which prevents specified categories of users to use them at all, and any such attempt is logged. By default the SPY module logs attempts to use execve syscall by root owned processes, and setuid/setgid by any user owned process. Default mode for other syscalls, used when you add them to monitoring, is to log all uses with all arguments. ----- 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: libvgl - status and perspectives
On Mon, 8 Nov 1999, Soren Schmidt wrote: > It seems Andrzej Bialecki wrote: > > > > > > Oops, sos and I have developed a new version of libsvgl which can > > > handle VESA modes in addition to the standard VGA graphics modes. > > > But I haven't committed it to the source tree yet (yes, I should have > > > done so weeks ago ;-( > > > > > > Anyway, if you are interested, I can send you a copy for testing. > > > > Yes, sort of... You see, with libvgl I ended up implementing most of the > > events abstraction myself - libvgl seriously lacks this (among others). > > So, of course new VESA modes are very interesting, but what would be > > really cool is more general framework for graphical terminal handling. > > Hmm, libvgl was originally only thought as a way to do simple graphics > on the console, nothing more. What exactly is it you need ?? Things like mouse/key events and queues thereof, filled/patterned shapes and lines, draw modes (even BGI drivers could do that!) are the most important that come to mind... "Events" for me means that I can call an API which will deliver pending information about keypresses, mouse movemnts and buttons, without writing that select/read/ioctl/enqueue/compress hassle you have to do now each time you want to see if something happened. > (And I'm not suggesting that I have the time to do it :) ) Me neither... :-) I'm just in complaining mode, I guess... > > > >But this brings more general question regarding console graphics library. > > > >As it is today, libvgl is almost useless due to very limited set of > > > >functions. There were discussions whether to port SVGAlib or GGI. Do you > > > >know if someone is working/planning to work on it? > > > > Do you know something about this? > > I think you all know my feelings about svgalib so I wont comment on that > one. I havn't been following the GGI project lately so I dont know what > they have achived, but last time I looked it had a lng way to go to > be minimally usefull, and their kernel stuff was, well, not something I'd > put into our kernel > Anyhow, I think we have what can be currently done resonably in the kernel > its just a matter of how you should interface to it. Remember that VESA Any docs for e.g.the fb device? I know,you can always UTSL, but it takes more time. OBTW. there is an error in mouse(4) manpage. The ioctl is called MOUSE_GETSTATUS, not MOUSE_GETSTATE as the manpage claims. 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: libvgl - status and perspectives
On Mon, 8 Nov 1999, Kazutaka YOKOTA wrote: > > >Today I noticed accidentally that either libvgl is broken, or the demo > >program does something wrong - the mouse cursor doesn't move. > > Oops, sos and I have developed a new version of libsvgl which can > handle VESA modes in addition to the standard VGA graphics modes. > But I haven't committed it to the source tree yet (yes, I should have > done so weeks ago ;-( > > Anyway, if you are interested, I can send you a copy for testing. Yes, sort of... You see, with libvgl I ended up implementing most of the events abstraction myself - libvgl seriously lacks this (among others). So, of course new VESA modes are very interesting, but what would be really cool is more general framework for graphical terminal handling. > >But this brings more general question regarding console graphics library. > >As it is today, libvgl is almost useless due to very limited set of > >functions. There were discussions whether to port SVGAlib or GGI. Do you > >know if someone is working/planning to work on it? Do you know something about this? 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: Small HEADS UP!
On Thu, 21 Oct 1999, Julian Elischer wrote: > > i.e. only for those with small heads.. > > I just checked in a relatively large set of new files and a few patches. > The are the 'Netgraph' link layer networking infrastructure. > They SHOULDN'T cause problems if not compiled in, but > > As I write a "make world" is proceding but has not finished yet. Excellent! At last! Thank you and Whistle for making this code available! 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: lconfig cores [ was: staroffice ]
On Sat, 9 Oct 1999, Randy Bush wrote: > # /compat/linux/sbin/ldconfig > Segmentation fault (core dumped) > > could it be that i need more compat libs than 22? Usually when you're missing some lib, the program wouldn't start at all. It could be that you have some incompatible version of the libs, though... but overall it looks to me like screwed up installation of linux_base port. Try the standard IT solution: reinstall linux_base. 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: staroffice
On Fri, 8 Oct 1999, Randy Bush wrote: > anyone successful installing staroffice 5.1? > > is <http://lt.tar.com/so50.out> still the best hint? The new Sun's version works for me out of the box. The only glitch during setup was that I had to unzip the setup.zip and ldconfig the libraries therein. 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: 2xPIIIx450 results & NFS results
On Sun, 19 Sep 1999, Adam Strohl wrote: > OK, Upgraded my Asus P2B-D machien from BIOS version 1008 to 1010, the > problem disappeared. Popped back to my old 1008 BIOS, problem came back. > > Looks like there was some wierd issue that got resolved in 1009 or 1010. Good! Thanks for the info. Now we have a solution. 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: 2xPIIIx450 results & NFS results
On Sat, 18 Sep 1999, Jaye Mathisen wrote: > > Yes, it definitely seems ASUS related... I dropped back to uni processor > ASUS boards, and it's fine. didn't need the SMP anyway, just wanted to > play with it some more. Now, here's the difference - I don't play, I NEED SMP, and the machines in question are going to production soon... So, for me this is a real problem. 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: 2xPIIIx450 results & NFS results
On Fri, 17 Sep 1999, Rodney W. Grimes wrote: > > :> I/O, and then closing it. > > : > > :4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision > > :1008.A, running `systat -vm 1' gives the normal display but without any > > :numbers filled in, then switches over to an empty screen that says: > > :... > > > > Whenever systat or top do weird things it probably means you > > need to recompile libkvm. > > This is not a libkvm problem on my box, these are fresh make worlds > on 3.3-RC as of 2 days ago. It only appears to occur when running SMP, The problem seems to occur reliably on ASUS boards - perhaps a coincidence, but I have several machines here which behave this way. And yes, libkvm is in perfect sync with the rest of the system (3.3-RC) 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: Setting MAC address - a plea to authorities
On Tue, 14 Sep 1999, David J. Clark wrote: > Could you forward me said code ? You are not the first person who asks me this question, so I take a liberty of CC:'ing this to the list. The said code is located at: http://www.freebsd.org/~wpaul/mac.tar.gz and consists of a KLD module implementing the new functionality, and a small program (which eventually should be a part of ifconfig, I suppose) that you can use to set MAC address. If I understand correctly, only minority of ethernet cards supports this. I tested it with Intel Etherexpress 100B (fxp driver) and it works. BTW. Thank you, Bill, for this software! 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
Setting MAC address - a plea to authorities
Hi, Thanks to someone's help I found the code that Bill Paul wrote to set the MAC address on the ethernet card. In short, I find it very useful and an excellent addition when building FreeBSD HA solutions. I've heard there was some controversy about how these types of things should be done and where, but the fact is that as for now it's the only way to do it (that actually works and is here). Can we please have these issues resolved so that this functionality can be added to the base system? Thanks a lot! 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: Latest kernel flop
On Wed, 8 Sep 1999, Kenneth Culver wrote: > Not only does the sio device give me trouble, since I don't use it I took > it out, and rebuilt the kernel. Immediately upon reboot, I got a kernel > panic. It went like this: > > Copyright (c) 1992-1999 The FreeBSD Project. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > > Then it panics. > > What's going on here? It probably didn't like the latest changes in BSD license... (just kidding ;-) 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: multipatch #6 available
On Sat, 28 Aug 1999, Matthew Dillon wrote: > * Adds a new feature to VN - swap space pre-reservation, > in addition to the two features already added (zeroing > and file creation/truncation). Sounds great to me. I really hope you also update the manpage for vn(4) and vnconfig - I begin to feel lost with all the options here... 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: "The Matrix" screensaver, v.0.2
On Wed, 25 Aug 1999, Jordan K. Hubbard wrote: > I'm sorry you got so beaten up over this one. All due respect to the > contributors aside, I think we have too many old women around here, > all shrieking and holding up their skirts at the rumor of a mouse > somewhere in the building. :) As I said, I'm done with the subject. it's on my web page on freefall. Anyone wishing to do something with it can grab it and do whatever he wants (within terms of BSD license). 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: "The Matrix" screensaver, v.0.2
On Mon, 23 Aug 1999, Mike Smith wrote: > Just make it a port, for crap's sake, and distribute it from Poland. > By the time WB's American lawyers work out where you are on the map, > the statute of limitations will have expired and you'll be fine. > > But it's not going into the tree, no. I think Kevin's point and the > experiences we had with Hasbro should already have convinced people of > that much. I'm tired of this. It has priority number -infinity on my list. Do with it what you want - the code is there. I won"t put 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: "The Matrix" screensaver, v.0.2
On Mon, 23 Aug 1999, Daniel C. Sobral wrote: > Kevin Day wrote: > > > ... > > If this is distributed as a fan based thing, the worst they'd likely do is > > say "Take it down.". If this is on thousands of FreeBSD cd's, it could > > become a financial problem if they want to take it far enough. > > > > This is just my opinion though, and not to be used as legal advice for > > anyone. I just don't want FreeBSD to become a ball of intellectual property > > infringements. :) > > Let me retract the Ghost in the Shell statement. I just checked, and > my memory played tricks on me. It was a different letter effect. :-) > > Andrzej, can you somehow turn it into a parody? If you can make it > into a parody, then it's legal. I can't think of any... What could be funny in such primitive effect anyway? Besides, I'm not that sure I want to spend more time on that. Feel free to hack it, guys, if you like it - it's BSD license, you know... 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: "The Matrix" screensaver, v.0.2
On Sun, 22 Aug 1999, Kevin Day wrote: [trademark violation warning] Ok, maybe you have a point - I dont know, I'm not a lawyer. But with this line of reasoning they could claim that anything using falling letters effect on your screen partly violates they trademarked special effect, which is silly. What can we do, then? Why don't we ask them politely if it's ok? 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: "The Matrix" screensaver, v.0.2
On Sat, 21 Aug 1999, 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. You can trademark the title "The Matrix", but you can't trademark a common word "matrix". That's the only word I use for the name of the module. As Daniel mentioned, they even can't claim that it's their idea. So I think I can pretty safely import it. 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: "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: "The Matrix" screensaver, v.0.2
On Fri, 20 Aug 1999, Nick Hibma wrote: > > oh THAT screen... > > > > quite a giggle.. > > Have you seen the source ... very neat and short. Pitty that it consumes > 2% intr time. Oh, there is still much room for improvement here... if there is any interest, that is. :-) 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: "The Matrix" screensaver, v.0.2
On Fri, 20 Aug 1999, Julian Elischer wrote: > oh THAT screen... > > quite a giggle.. c'mon, you didn't expect me to put an intro scene from the movie, did you? Yeah, that's something - MPEG screensaver... only a few GB. I need to think about it. 8-)) 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: "The Matrix" screensaver
On Fri, 20 Aug 1999, Doug White wrote: > On Fri, 20 Aug 1999, Andrzej Bialecki wrote: > > > Hi, > > > > This is my poor attempt at reproducing the screens on the movie... Sure, > > there is much room for improvement, and the whole thing would look cool in > > VESA, if someone has more spare time... > > > > http://www.freebsd.org/~abial/matrix.tgz > > Hey, where'd it go? See my next announcement on -current. Or, see my page. 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: "The Matrix" screensaver, v.0.2
On Fri, 20 Aug 1999, Sheldon Hearn wrote: > > > On Fri, 20 Aug 1999 19:34:31 +0200, Andrzej Bialecki wrote: > > > Due to unexpected demand (I did it mostly as a distraction from real > > work), I backported this screensaver to 3.2-RELEASE (don't know about > > STABLE), and corrected some inconsistencies. I added also binary versions > > to the archives. > > You really do get around, huh? From maintaining the bloat-free PicoBSD > to contributing the ultrabloat candidate of the year. ;-) Yes, I admit - it's useless. That's why I wrote it... :) 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: problem with vnconfig -s labels ...
On Fri, 20 Aug 1999, Luigi Rizzo wrote: > > > can someone investigate this ? the code seems to work fine on 3.x > > > > Someone also sent me a report on that, so it's a real problem. I have a > > traceback, but without debugging symbols. > > it's so easy to reproduce that i hope the vm/vn gurus will not require > too much effort to find the bug. > > in the meantime, what you suggest (for picobsd builds that is) ? > use a real floppy ? Yes, I think... but this gonna be slow, man! 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
"The Matrix" screensaver, v.0.2
Hi, Due to unexpected demand (I did it mostly as a distraction from real work), I backported this screensaver to 3.2-RELEASE (don't know about STABLE), and corrected some inconsistencies. I added also binary versions to the archives. Both versions are available at: http://www.freebsd.org/~abial/matrix_3.2.tgz http://www.freebsd.org/~abial/matrix_4.0.tgz Have fun... 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: problem with vnconfig -s labels ...
On Fri, 20 Aug 1999, Luigi Rizzo wrote: > Hi, > > trying to build picobsd on 19990816snap of -current, i am consistently > hitting a problem, which is totally reproducible from the command line. > The following sequence > > vnconfig -s labels -c /dev/rvn0 fs.PICOBSD > disklabel -rw /dev/rvn0 fd1440 > > causes a panic with a page fault accessing a low address (presumably > through a null pointer) in vnstrategy. > > fs.PICOBSD is a file filled with 0's with dd if=/dev/zero... > and the problem appears to occur independently from the size of the > file. > > can someone investigate this ? the code seems to work fine on 3.x Someone also sent me a report on that, so it's a real problem. I have a traceback, but without debugging symbols. 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: "The Matrix" screensaver
On Fri, 20 Aug 1999, Nick Hibma wrote: > > What a ridiculous idea! I love it! Hehe.. Now they can run it on their cluster. :-) > > Hi, > > > > This is my poor attempt at reproducing the screens on the movie... Sure, > > there is much room for improvement, and the whole thing would look cool in > > VESA, if someone has more spare time... > > > > http://www.freebsd.org/~abial/matrix.tgz > > > > Unpack it in /sys/modules/syscons. > > > > 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 > > > > > > -- > e-Mail: [EMAIL PROTECTED] > > 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
"The Matrix" screensaver
Hi, This is my poor attempt at reproducing the screens on the movie... Sure, there is much room for improvement, and the whole thing would look cool in VESA, if someone has more spare time... http://www.freebsd.org/~abial/matrix.tgz Unpack it in /sys/modules/syscons. 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: Q: Extending the sysctl MIB for Linuxulator variables
On Mon, 16 Aug 1999, Mike Smith wrote: > > > Yes, this is very true. But I think we are fooling ourselves if we > > > believe linux emulation will not become 'standard' in the near future. > > > Then we'll kick ourselves for giving the sysctl's convoluted names :-) > > > > Yeah... Then, the next in line after "linux" are: ibcs2 and svr4 and > > whatever comes next. Can you live with them as main sysctl categories? > > Adding anything at the top level would be a terrible mistake. > > Given that "ABI" is a bit obscure, kern.compat is the only sensible > choice. One one hand you're right (it is a compatibility stub) but OTOH it is also a kernel module... ;-) Perhaps modules like this will want to have their stuff in BOTH places, i.e. in kernel.compat and in kernel.modules, depending what the given sysctl does. 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: Q: Extending the sysctl MIB for Linuxulator variables
On Mon, 16 Aug 1999, Matthew Dillon wrote: > > : > :On Sun, 15 Aug 1999, Matthew Dillon wrote: > : > :> :>2) under "kern.emu.linux" > :> :>3) under "linux" > :> : > :> :I vote for 3. > :> : > :> :-- > :> :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! > :> > :> Ditto. Linux emulation is going to become increasingly important, > :> burying deep would just make everyone's life more difficult. > : > :Well, it's also a module, so perhaps we should create the whole subtree > :for modules (as was already discussed several times..) > : > :Andrzej Bialecki > > Yes, this is very true. But I think we are fooling ourselves if we > believe linux emulation will not become 'standard' in the near future. > Then we'll kick ourselves for giving the sysctl's convoluted names :-) Yeah... Then, the next in line after "linux" are: ibcs2 and svr4 and whatever comes next. Can you live with them as main sysctl categories? 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: Q: Extending the sysctl MIB for Linuxulator variables
On Sun, 15 Aug 1999, Matthew Dillon wrote: > :>2) under "kern.emu.linux" > :>3) under "linux" > : > :I vote for 3. > : > :-- > :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! > > Ditto. Linux emulation is going to become increasingly important, > burying deep would just make everyone's life more difficult. Well, it's also a module, so perhaps we should create the whole subtree for modules (as was already discussed several times..) 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 plus advice needed
On Sat, 31 Jul 1999, Jeroen Ruigrok/Asmodai wrote: > > No, just options DDB. > This bt was obtained after doing gdb -k kernel.0 vmcore.0 > I still have the DDB trace on paper which I can type in if needed/wanted. > > > What you do with the results depends a lot on what you find. On the > > whole, I wouldn't think it worth the pain of debugging without > > symbols. > > No it isn't... Another handful tricks of the trade: * if you still have exactly the same source tree and config file, recompile the kernel with -g to obtain the version with debugging symbols * if you managed to crash it once, you perhaps can do it again, but this time having the debugging kernel handy * if you can't for the life of you get the crash dump to examine what went wrong, do remember of remote GDB option under DDB - that is, if you have another machine with the same sources and kenel. But if the problem is repeatable you can prepare it beforehand... Remote GDB works miracles then. 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: Arg! MFS broken
On Sat, 24 Jul 1999, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Andrze > j Bialecki writes: > >On Sat, 24 Jul 1999, Mark Huizer wrote: > > > >> > > >> > >MFS is badly broken when used in a diskless configuration. I am trying > >> > >to track it all down but it is very, very frustrating. > >> > > > >> > >Also BOOTP seems to be broken -- rootdev is not being setup any more > >> > >and I can't figure out which commit broke it. > >> > > >> > I'm sorry, I don't have either in my arsenal currently. > >> I found that trying to build a PicoBSD floppy was a sure way of crashing > >> my current box :-( Perhaps that is a nice testing environment? > > > >Then you should investigate this further, because it looks like some bug > >in vn(4) code - picobsd build doesn't do anything unusual except that... > > I built a release (which also uses vn(4)) yesterday, so to some extent > of the concept vn(4) works. I'm very interested in a traceback of > this panic... If interrupted at (in)appropriate place, picobsd build process can leave vn(4) configured but left without underlying file. I shoudl probably test various scenarios here, like: * vn configured, remove file, unconfig vn * vn configured, mounted, unconfigure vn etc, etc.. vn(4) should be foolproof , at least it shouldn't panic the system. But you're right, we need a trace first... 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: Arg! MFS broken
On Sat, 24 Jul 1999, Mark Huizer wrote: > > > > >MFS is badly broken when used in a diskless configuration. I am trying > > >to track it all down but it is very, very frustrating. > > > > > >Also BOOTP seems to be broken -- rootdev is not being setup any more > > >and I can't figure out which commit broke it. > > > > I'm sorry, I don't have either in my arsenal currently. > I found that trying to build a PicoBSD floppy was a sure way of crashing > my current box :-( Perhaps that is a nice testing environment? Then you should investigate this further, because it looks like some bug in vn(4) code - picobsd build doesn't do anything unusual except that... 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: is dumpon/savecore broken?
On Wed, 21 Jul 1999, Matthew D. Fuller wrote: > On Thu, Jul 22, 1999 at 02:19:37AM +0200, a little birdie told me > that Andrzej Bialecki remarked > > On Tue, 20 Jul 1999, Matthew Dillon wrote: > > > > > > You can do it manually from /etc/rc. If it doesn't even get that far, > > > you used to be able to specify it in the kernel config but I do not know > > > if that is possible any more. > > > > I remember doing this once or twice from DDB - writing appropriate values > > to _dumpdev, as they appeared on running system. > > > > Of course, the system can be in such state that this could equally well > > do more harm than good... :-/ > > But lemme guess... > This won't work with a system that panics before it gets around to > probing the harddrives... > > This is one of my present problems :( Then use remote GDB - it works miracles, I can tell you, it's just like debugging any other user space program. See the section in the handbook on that. 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: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Matthew Dillon wrote: > > :And how do you create dumps from a kernel that hasn't finished booting > :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel > :config does not seem to do the job. > : > :Nick > > You can do it manually from /etc/rc. If it doesn't even get that far, > you used to be able to specify it in the kernel config but I do not know > if that is possible any more. I remember doing this once or twice from DDB - writing appropriate values to _dumpdev, as they appeared on running system. Of course, the system can be in such state that this could equally well do more harm than good... :-/ 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
Panic in vm_page_free_toq (Re: Panic in vm_page_zero_idle)
On Wed, 30 Jun 1999, Peter Wemm wrote:
> Andrzej Bialecki wrote:
> > Hi,
> >
> > Sources are from yesterday, machine is Toshiba Portege 7020CT. During make
> > -j24 buildworld machine dies with the following panic mesage (notice
> > absence of register dump):
> >
> > kernel: type 12 trap, code=0
> > Stopped at vm_page_zero_idle+0xc9: movl %eax,0x4(%edx)
> >
> > db> tr
> > vm_page_zero_idle(e,66a,2,183f9ff,756e6547) at vm_page_zero_idle+0xc9
> > idle_loop() at idle_loop+0x2d
>
> That's because there is no process context at this point, and nowhere the
> registers are saved for the idle ``context''.
>
> Trap 12 is a page fault. Do a 'show registers' to see what's up. I
> would like to know what %edx is.
>
> It's trapping here:
> m = vm_page_list_find(PQ_FREE, free_rover, FALSE);
> if (m != NULL && (m->flags & PG_ZERO) == 0) {
> --(*vm_page_queues[m->queue].lcnt);
> TAILQ_REMOVE(vm_page_queues[m->queue].pl, m, pageq);
> ^^^
> m->queue = PQ_NONE;
> splx(s);
>
> Specifically, vm_page_queues[m->queue].pl is invalid or the tailq corrupt
> or something evil along those lines. Or, m->queue is bogus and causing
> an out of bounds array lookup. Hmm, do a show registers and record %eax
> at this point too.
I could only use gdb, and I didn't have kernel.debug. I went some frames
up to reach the vm_page_zero_idle, and did "info registers". Both %eax and
%edx were 0x0.
But this time I was (a little bit) wiser. Here's another panic - this time
I got the core file and a kernel with symbols, and I did what I could with
gdb, but finally ran out of ideas... ;-)
Additionally, the core file is on a laptop, and I have only modem
connection at the moment, but I will be able to put it om freefall (or
wherever) at the end of next week.
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/
Script started on Sun Jul 4 20:54:36 1999
# gdb -k /sys/compile/TUNE/kernel.debug vmcore.2
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 2822144
initial pcb at 240680
panicstr: vm_page_free: freeing free page
panic messages:
---
panic: vm_page_free: freeing free page
syncing disks... done
dumping to dev (0,196609), offset 131328
dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108
107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82
81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 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 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:289
289 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:289
#1 0xc0135851 in panic (fmt=0xc020ece0 "vm_page_free: freeing free page")
at ../../kern/kern_shutdown.c:452
#2 0xc01a7f3d in vm_page_free_toq (m=0xc045f3e0) at ../../vm/vm_page.c:1095
#3 0xc01a5e39 in vm_object_terminate (object=0xc6b40bd0)
at ../../vm/vm_page.h:500
#4 0xc01a5d55 in vm_object_deallocate (object=0xc6b40bd0)
at ../../vm/vm_object.c:382
#5 0xc01a3263 in vm_map_entry_delete (map=0xc6880740, entry=0xc6cb6f78)
at ../../vm/vm_map.c:1680
#6 0xc01a3421 in vm_map_delete (map=0xc6880740, start=0, end=3217022976)
at ../../vm/vm_map.c:1783
#7 0xc01a34a5 in vm_map_remove (map=0xc6880740, start=0, end=3217022976)
at ../../vm/vm_map.c:1808
#8 0xc012f310 in exit1 (p=0xc6d1ad60, rv=11) at ../../kern/kern_exit.c:220
#9 0xc0136bfe in sigexit (p=0xc6d1ad60, signum=11)
at ../../kern/kern_sig.c:1251
#10 0xc0136a41 in postsig (signum=11) at ../../kern/kern_sig.c:1157
#11 0xc01d0b7e in trap (frame={tf_fs = 47, tf_es = -1063190481,
tf_ds = -1078001617, tf_edi = 0, tf_esi = 671533121,
tf_ebp = -1077945512, tf_isp = -958808108, tf_ebx = 671531312,
Panic in vm_page_zero_idle
Hi, Sources are from yesterday, machine is Toshiba Portege 7020CT. During make -j24 buildworld machine dies with the following panic mesage (notice absence of register dump): kernel: type 12 trap, code=0 Stopped at vm_page_zero_idle+0xc9: movl %eax,0x4(%edx) db> tr vm_page_zero_idle(e,66a,2,183f9ff,756e6547) at vm_page_zero_idle+0xc9 idle_loop() at idle_loop+0x2d I can reproduce it at will, if someone's interested in more detailed report. 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: somebody has broken sysctlbyname() in -current
On Wed, 12 May 1999, Stefan Bethke wrote: > Any pointer on Forth literature/web pages would be appreciated, especially > if it's not the ANSI standard (I've looked at it, and it is that: a > standard, not a reference manual or a tutorial). My Forth knowledge is > rather rusty, I realised... last time I remember I was sitting in front of > my Apple II clone about 15 years ago. "Real-Time Forth" could be good for beginners... It's on the web somewhere. Andrzej Bialecki // 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: somebody has broken sysctlbyname() in -current
On Sat, 8 May 1999, Peter Wemm wrote: > It's interesting that the ANSI emulation in loader(8) is good enough to do > full-screen displays. It still seems to make sense to move userconfig-like > functionality into the pre-kernel stages including moving config(8)'s hints > to a loaded and parsed file. Forth, bah.. :-] Heh... To tell you the truth, that was my initial dream which prompted me to start writing it. It could be done now, really... Andrzej Bialecki // 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: somebody has broken sysctlbyname() in -current
On Sat, 8 May 1999, Peter Wemm wrote:
> "Jordan K. Hubbard" wrote:
> > > sysctlbyname("machdep.uc_devlist", buf, &len, NULL, NULL);
> >
> > Sorry for the vague first bug report; I hadn't collected a reasonable
> > crashdump yet. It's in sysctl_machdep_uc_devlist(), specifically
> > where it copies id->id_driver->name into a temporary stack variable.
> > First time through, this thing's NULL and *boom* we're gone. I'm
> > looking into it.
>
> Should be fixed as of a few minutes ago in userconfig.c:
>
> revision 1.140
> date: 1999/05/07 16:54:50; author: peter; state: Exp; lines: +34 -2
> Yet another kludge to maintain the isa_device illusion, this time malloc
> an isa_driver and name pointer so the uc_devlist sysctl can get to it.
>
Neither you nor I seem to be happy with the fix. When I added this sysctl,
I only wanted to somehow get to the list of changes from UserConfig
without poking around through kmem. Now, when the changes in the way
devices are registered are introduced, we can think of something else
which could be better suited. For now the only programs that need it are
kget and sysinstall. (i.e. it's still easy to change, if we know what we
want.. :-)
Andrzej Bialecki
// 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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: New ATA drivers problem? (Was: New kernels won't boot)
(trimmed spaghetti CC: list...) On Fri, 30 Apr 1999, Soren Schmidt wrote: > Unfortunately they dont tell me much :( > > I'll have to rearrange some disks here and try to make some new installs > see if I can get the problem to appear then.. Is there any info I can dig out for you? Some useful printfs here and there? Andrzej Bialecki // 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New ATA drivers problem? (Was: New kernels won't boot)
On Thu, 29 Apr 1999, Soren Schmidt wrote: > It seems Brian Feldman wrote: > > >Ever going to help with my atapi-fd problems? I found examples of the > >corruptions, including lots of NULLs... > > Well, so long as I cannot get my hands on the problem, its real hard > to solve it. I'm trying to get ahold of the same LS120 drive here > but so far I havn't found any, in fact LS120 drives are extremely > rare over here... As I said before, I can make some tests, but unfortunately my machine doesn't want to mount disks at all with the new ATA code... Please take a look at the message I sent about a week ago. Andrzej Bialecki // 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
New ATA hangs my machine
Hi, I'd love to play with the new IDE drivers, especially that I got an LS-120 drive, but... I can't mount my filesystems with it. I'm using today's sources (kernel config file attached), and it fsck's them just ok, and then just hangs. Keyboard works, though. If I boot with -v, it reports: ad0: invalid primary partition table: no magic and of course it just sits there... The issue is, however, that old kernel booted just fine. I attached relevant parts of dmesg with old drivers, and disklabel and fdisk output. Any clues? Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ pci0: on pcib0 chip0: at device 0.0 on pci0 isab0: at device 7.0 on pci0 isa0: on isab0 ide_pci0: at device 7.1 on pci0 intel_piix_status: primary master sample = 3, master recovery = 1 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary slave sample = 3, slave recovery = 1 intel_piix_status: primary slave fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled ide_pci: busmaster 0 status: 04 from port: 9002 intel_piix_status: secondary master sample = 3, master recovery = 1 intel_piix_status: secondary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: secondary slave sample = 3, slave recovery = 1 intel_piix_status: secondary slave fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled ide_pci: busmaster 1 status: 04 from port: 900a fdc0: interrupting at irq 6 fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 intel_piix_dmainit: setting multiword DMA mode 2 wd0: wdsetmode() setting transfer mode to 22 intel_piix_status: primary master sample = 3, master recovery = 1 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0003, dmamword = 0407, apio = 0003, udma = intel_piix_dmainit: setting multiword DMA mode 2 wd1: wdsetmode() setting transfer mode to 22 intel_piix_status: primary slave sample = 3, slave recovery = 1 intel_piix_status: primary slave fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled wdc0: unit 1 (wd1): , DMA, 32-bit, multi-block-16 wd1: 4110MB (8418816 sectors), 14848 cyls, 9 heads, 63 S/T, 512 B/S wd1: ATA INQUIRE valid = 0007, dmamword = 0407, apio = 0003, udma = 0007 wdc0: interrupting at irq 14 wdc1 at port 0x170-0x177 irq 15 flags 0x80ff80ff on isa0 wdc1: unit 0 (atapi): , removable, dma, iordy wdc1: ATAPI Floppies not configured wdc1: unit 1 (atapi): , removable, accel, dma, iordis wcd0: drive speed 171 - 5500KB/sec, 128KB cache wcd0: supported read types: CD-R, CD-RW, CD-DA, packet track wcd0: Audio: play, 255 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: no/blank disc inside, unlocked, lock protected wdc1: interrupting at irq 15 atkbdc0: at port 0x60 on isa0 atkbd0: on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d atkbd0: interrupting at irq 1 psm0: current command byte:0065 kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status: psm0: failed to reset the aux device. vga0: on isa0 [...] BIOS Geometries: 0: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. changing root device to wd1s1a wd1s1: type 0xa5, start 63, end = 6291431, size 6291369 wd1s1: C/H/S end 391/158/63 (3926663) != end 6291431: invalid wd1s2: type 0xa5, start 6291432, end = 8
Re: does login.conf limitations work ?
On Sat, 24 Apr 1999, Stephane Legrand wrote: > > That's also my impression. I glipmsed the whole source tree and I couldn't > > find any place where the limits are enforced. BTW. what entity should > > enforce login time limits? Kernel? Some user-space daemon? > > > > To report a login.conf success, i've used on a 2.2.8 system the > "cputime" ressource limit. I set it to zero and that worked very > well. So may be only some limits are implemented ? You're right, this part works. However, I was talking about login time (which is how long can user be logged on to the system), which isn't checked anywhere. Andrzej Bialecki // 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: does login.conf limitations work ?
On Fri, 23 Apr 1999, Luigi Rizzo wrote: > Hi, > > i was wondering if the limitations that are supposed to be enforced via > the login.conf mechanism do really work... > > In particular, i have tried (on 3.1 something, but don't think that > current is much different in this respect) to enforce the daily etc. > login times but the system seems to ignore them. > > I think /etc/login.conf is properly parsed, because if i assign a user > to a class that is not defined in login.conf i get complaints, but > other than that i am unable to limit login time... > > Any hints ? That's also my impression. I glipmsed the whole source tree and I couldn't find any place where the limits are enforced. BTW. what entity should enforce login time limits? Kernel? Some user-space daemon? Andrzej Bialecki // 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: egcs knob and objective C
On Wed, 31 Mar 1999, Steve Kargl wrote: > Is there a simple knob to turn to get the egcs compiler by > default? I'm willing to help test egcs for the transition > from gcc+2.7.x. > > I've looked through the Makefiles and the /usr/src/gnu directory, > but I can't seem to locate a knob to turn for the egcs compiler > (unless I need to mangle the .PATH variable). > > And, at the risk of being flamed, I noticed (after all these years) > that we build some for Objective C stuff. Is this actually required > within the base distribution? Also, I seem to recall that we already have another copy of libiberty (under gdb). Do we really need to have both of them? Andrzej Bialecki // 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to add a new bootdevice to the new boot code ???
On Wed, 17 Mar 1999, Robert Nordier wrote: > Incidentally, while I'm in there and thinking about it, I'd quite > like to fix the boot code to boot from LS-120 drives at the same > time. So if anyone has one of these, and wouldn't mind spending > some time running a few bits of test code, I'd appreciate it. I can do that when I'm back in Poland (i.e. after Cebit). Andrzej Bialecki // 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new loader.rc stuff
On Sat, 13 Mar 1999, Chuck Robey wrote:
> > load kernel
> > load -t userconfig_script /kernel.config
> >
> > and then putting your pnp configuration line on /kernel.config (if
> > it is not there already).
>
> This is good info for current, right? And I don't need to worry about
> "userconfig_script"? What's load -t do (I don't need a man page, but at
> least a few words on the -t, please).
'-t' does basically two things. First of all, it selects right loading
procedure, e.g. just suck it in instead of interpreting it as an ELF
binary. The other thing is that it attaches a magic label to this piece of
code, so that later from within the kernel you can do
preload_search_by_type("my_lovely_magic_string") and it will return a
pointer to the right data, be it an executable code or a text or a
graphics image.
>
> The pnp line will be the only thing in /kernel.config, that's normal?
Yes. Since you're running -current, you should be able to use kget(8) as a
dset replacement to generate /kernel.config for you, based on the changes
in UserConfig.
Andrzej Bialecki
// 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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: paranoid patches
On Thu, 18 Feb 1999, Lyndon Nerenberg wrote: > > > Basically, it is a patch into libkvm and w, that will allow a user (with > > > the exception to the super user, naturally) to only view processes or > > > information belonging to him/herself. > > > The only problem with this is setuid binaries. The processes may have > > been started by me (top, etc..), but this wouldn't allow me to monitor > > the process once it's started. > > And, anything that can read /dev/[k]mem is free to bypass libkvm and just > grovel around in the kernel memory space, anyway. Not only that - you would need to disable other holes as well, which has been done on purpose. Think of /procfs and sysctl kern.proc..something. Andrzej Bialecki ++---++ - ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+---+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kvm question
On Sun, 24 Jan 1999, Mike Smith wrote: > > < > said: > > > > > Peter pointed out that having the sysctl's as symbols was a nice > > > advantage of the current system. How important is this? > > > > I don't think it's important at all. (Then again, I liked the old > > system.) > > > > > If we were willing to give this up, then the SYSCTL() macro could > > > just expand to a SYSINIT() that called sysctl_add_subtree() (or > > > whatever you want to call it) upon loading. > > > > Seems reasonable to me. The only problem with this is likely to be > > OID_AUTO, which I happen to think is bogus anyway. It is vital that > > we maintain the ability to reference sysctl entities by compile-time > > constant integers, so as not to break backwards compatibility with > > other 4.4 systems and the Stevens books. > > Backwards compatibility is one thing, but new nodes should be named, > not numbered. OID_AUTO is bogus because it perpetuates the numbering > of nodes. ...that is, IFF we're going to keep the number/name pairs as OIDs, and not only the numbers, which seems more appropriate... Andrzej Bialecki ++---++ - ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+---+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kvm_getswapinfo() function added to libkvm. top, pstat, systat updated
On Fri, 22 Jan 1999, Matthew Dillon wrote: > A new function, kvm_getswapinfo(), has been added to libkvm. > > pstat, systat, and top have been updated to use the new function. Have you considered using sysctl(3) for this instead? If yes, could you explain why the libkvm seemed better to you? (I'm asking because with libkvm you need to use /dev/kmem _and_ you need to access symbol table - this doesn't work with stripped kernels). Andrzej Bialecki ++---++ - ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+---+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: boot.flp versions
On Fri, 22 Jan 1999, Jordan K. Hubbard wrote: > OK, in retrospect, turning off swapping was a mistake. I should have > thought about this a bit more before blindly accepting the suggestion > from Andrzej. ;) Fixed. Oh well.. It made sense for me, I just thought it might help to save some space. It was only a few bytes anyway, and we're short of a couple of kBs now, so it's irrelevant... Andrzej Bialecki ++---++ - ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+---+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! New swapper and VM changes being committed to -4.x tonight.
On Thu, 21 Jan 1999, Warner Losh wrote: > In message > Andrzej Bialecki writes: > : I'm more than willing to test it in low memory conditions.. :-) I have > : that special 386SX/4MB RAM machine in the corner to test things like > : picobsd memory requirements... > > So how well does this work? I have a 4MB machine that I'd like to run > FreeBSD on, including X on a low res screen... Hmmm.. Did I mention that I just left for a week to another country? Probably not :) I'll do the testing when I'm back. Andrzej Bialecki ++---++ - ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+---+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Heads up! New swapper and VM changes being committed to -4.x tonight.
On Wed, 20 Jan 1999, Matthew Dillon wrote: > The new swapper and a bunch of VM stuff I've been sitting > on is going to be committed into the new -current tree tonight. I'm more than willing to test it in low memory conditions.. :-) I have that special 386SX/4MB RAM machine in the corner to test things like picobsd memory requirements... Andrzej Bialecki ++---++ - ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+---+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
