Re: Question about cvsup...
On Sun, Nov 18, 2007 at 04:56:08PM -0800, Darren Reed wrote: > Nearly every time I run cvsup from the command line (as root), > I see large amounts of output like this for every file: > > SetAttrs src/contrib/amd/fsinfo/wr_fstab.c,v > > Is cvsup actually doing anything? > Have I done something wrong in my config? > (I run in with "cvsup -l lockfile -g -L 1 ncvs-supfile") Maybe there is a umask difference between your interactive env and your cron env. I use this line in my cvsup config file to make sure the file permissions are the way I want them: *default umask=002 John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will FreeBSD ever see native IPv6 ??
Are you just teasing or are you serious? I searched through their site (again), but except for being mentioned in their TODO for the past few months, I can't find anything that indicates that they or anyone else is working on it. They may be, but it isn't visible anywhere where I have looked. It would be nice if there was some place to follow their progress, because I'm also one of the people that would like to see IPv6 integrated into FreeBSD. John -- John Hay -- john@mikom.csir.co.za > > FreeBSD will have native IPV6 within a matter of weeks at this stage.. > the code is being readied as we speak. see www.kame.net . 3 sets of > developers for FreeBSD IPV6 have merged their efforts and the result of > this should be available by the end of summer (Northern). (which isn't > far away now..) > > On Wed, 21 Jul 1999, David O'Brien wrote: > > > So is FreeBSD *EVER* going to see native IPv6 ?? > > I attended a talk by a group of Intrusion Detection researchers. They > > were basing their research on FreeBSD because they needed divert > > sockets and found FreeBSD worked perfectly for this in this respect. > > However, once they needed IPv6 and IPsec guess what happened??? They > > moved to Linux and now have such a time investment in their custom kernel > > hacks FreeBSD will never be an option for them again. > > > > NetBSD and OpenBSD get more and more coverage from IPv6/IPsec > > capabilities every day. FreeBSD has lost considerable ground if we want > > to be a platform of choice for network and security researchers. > > > > Now ever LSOF has IPv6 support for NetBSD and OpenBSD... To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: svn commit: r193635 - head/etc
On Thu, Jun 18, 2009 at 09:58:01PM -0700, Doug Barton wrote: > Dag-Erling Sm??rgrav wrote: > > Doug Barton writes: > >> Dag-Erling Sm??rgrav writes: > >>> Great, now mergemaster blew away my ntp.conf and installed this one > >>> instead. Apparently, it thinks AUTO_UPGRADE means it's fine to > >>> overwrite an existing file with a new one... > >> Yes, that's exactly what the option means. The problem comes in > >> because it's a new file, which means that there is no record of it in > >> the mtree file, so it does not show up as "changed." > > > > Hmm, I'm not sure I follow, since I'm not familiar with the innards of > > mergemaster, > > The -U option works by comparing the installed files to the mtree file > created from the unmodified source files. If the file is listed as > having been changed, the -U option ignores it. If not, it > auto-installs it. Is it not possible to change the logic of -U a little. Only auto install if it is in mtree and has not changed. So if it has changed or is not in mtree, skip the auto install. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Howto setup multiboot with GPT?
On Mon, Aug 17, 2009 at 09:32:54AM -0400, John Baldwin wrote: > On Friday 14 August 2009 5:07:49 pm Andrey V. Elsukov wrote: > > Hi, > > > > I have installed 8.0-BETA2 amd64 on ZFS root with GPT. I made addition > > partition and > > made new ZFS pool, builded and installed i386 world and kernel to this > > pool. > > So, is there some way to select from which partition i want to boot? > > Not currently unless you hardcode a specific partition in /boot.config. (You > may need a patch from jhay@ to fix the parsing of that file though.) I > believe someone (can't recall who) has some changes in a p4 branch to extend > gptboot to support a fancier interface with a menu of possible partitions, > etc. My patch is only for gptboot (ufs partitions). From what I looked at gptzfsboot, it only looks at the first pool. You can boot from different filesystems inside a pool though. You can set that with zpool set bootfs=pool/dataset John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How can I force boot from alternate drive with boot.config?
On Mon, Feb 08, 2010 at 10:25:54AM -0600, Peter Steele wrote: > I've asked this on the -questions list but haven't had any feedback. I have a > system configured with multiple identical drives each loaded with FreeBSD. > When I was using MBR partitioning, I could create a boot.config to force the > system to boot from a specific drive. For example, if I wanted to boot from > the second drive, I'd create a boot.config with: > > > > 1:ad(1,a)/boot/loader > > > > We've switched to GPT partitioning and I can't seem to find a way to do this > same trick. The boot loader only seems to recognize MBR partitions when it > comes to this feature. I looked at the boot.c source code and there doesn't > seem to be anything specifically related to GPT partitioning. I cannot for > example say something like: > > > > 1:ad(1,p3)/boot/loader > > > > where p3 is the root partition in my GPT partitioned drives. So I'm puzzled: > If I have a two drive system with BSD loaded on both drives and the drives > are configured with GPT partitions, how can I force the system to boot from > the second drive using boot.config? > I use: ad(0p3)/boot/loader John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How can I force boot from alternate drive with boot.config?
On Mon, Feb 08, 2010 at 12:13:20PM -0600, Peter Steele wrote: > > I use: ad(0p3)/boot/loader > > So, more precisely, if I wanted to boot from drive 1, I'd use this? > > 1:ad(1p3)/boot/loader Yes, unless there are more bugs hiding. :-) I fixed a few in August last year. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Advice on deriving accurate time values from the kernel?
If you only want to timestamp events and not generate the event, you can use microtime() or nanotime(). On a 400MHz PII non-SMP you should get 2.5 ns resolution with nanotime(). On a normal kernel with kern.timecounter.method at the default of 0, the get... versions give you time at the last tick or even worse, so they are no good for that. John -- John Hay -- john@mikom.csir.co.za > Hi, > > I am in the process of developing a device driver for the purpose of > stepper motor control. The timing of each pulse is determined by > external timing hardware on an I/O board, which will fire an interrupt > after the time requested. Using this method, I am able to generate > streams of pulses at approximately 5000Hz on a Pentium II 400MHz system. > > Everything seems to be working well, but I'd really like to gather some > accurate timing data in order to derive some statistics to from the > system. Intuition tells me I'll need a clock with a tick rate of at > least 2 Hz to derive this. > > So, is such a thing available in the kernel? I've searched through > various mailing list archives and have found reference to the "HZ" > option to the kernel, which works to a point. However, it is not ideal > as setting HZ to high values generates far too much kernel overhead. > Also being considered is additional external timing hardware, but this > is something I'd rather avoid for many reasons. > > What I am after is not a "timer" as such - all I need to do is derive a > time value at an initial time, and a subsequent value at a later time. > I've used "getmicrouptime", but this appears dependent on the "Hz" > option, and as such is of limited use. > > I've just had some input from a colleauge who has suggested using the > Pentium profiling registers, which we are currently investigating... > > Any advice gratefully received, > > -- > Jennifer Clark > http://telepresence.dmem.strath.ac.uk > http://www.crmjewellery.co.uk > http://www.furniturenet.co.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What are 'compatibility shims" ?
> When using 4.3-BETA cvsupped 23/mar and > config'ed > > options NETGRAPH > > and added the sr and sppp drivers for the frame relay > link we are establishing. > > Dmesg gives me this line > > src0: dirver is using old-style compatibility shims > > > What are these shims? It is just the older driver interface. Don't worry it still works just fine. If you are using NETGRAPH in the kernel, you don't need to have sppp in the kernel, it won't be used. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: My project wish-list for the next 12 months
> > > > 1. Keyboard multiplexer. > > I actually fail to stop thinking about a complete syscons and pcvt > replacement. You know, the one and only console implementation that > makes all others obsolete. Big plans, little time, yada yada yada... It would be nice if one would still be able to use the keyboards separately too, even if you have to recompile the kernel for that. One nice usage would be on HP's quad kiosk machine. It is a single processor box with 4 x screen, keyboard and mouse, and then 4 people can use it. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mergemaster improvement (auto-update for not modified files)
On Tue, May 03, 2005 at 01:27:09PM +0400, Denis Peplin wrote: > > The mergemaster with this is test patch (attached) > can auto-update files that was not modified. > > It do this by compairing each file with it's CVS > copy. If file was not modified, it can be rewritten. > > This dramatically redices amount of files that require > admin's attention. > > There is one major problem here: > This can be done in single-user mode only if your > have local CVS repository, because if local CVS is > not exist, anoncvs is used. > > Possible solutions: What about mergemaster storing a copy of the original somewhere on disk for usage next time? Then the first run may still be slow, but following runs will be able to use it. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mergemaster improvement (auto-update for not modified files)
> > > > > > The technical reasons are very simple. If a new system call is > > > created, and programs use that new system call, then if you do an > > > installworld before you boot the kernel, that can result in binaries > > > not working. This has happened with important ones like /bin/sh in > > > the past. In addition, if you aren't running single user, many > > > different races exist in the installation process that can result in > > > bad behavior. There are also potential problems with symbols in > > > there's a large jump between the revisions being updated. > > > > > > Usually you can get away with it, but if you want to be safe, you must > > > do the install in single user. Usually, however, has lead in the past > > > to problems, which is why the project recommendations are > > > conservative. > > > > > > > A auto-scripted install directly run from rc.d in single-user mode would > > cover > > both requirements - I seem to recall that Solaris had something like it at > > a > > point. Somewhat along the lines of nextboot would be nice. > > How do you know where to get the sources from? What environment to > build them from? > > However, if you could cover those issues, I'd love to see a script to > deal. Maybe you could implement something that would be robust enough > for the project to recommend... What I do sometimes is to (in multiuser mode) make a copy of /etc to say /etc.new, the run mergmaster and stop it after it created /var/tmp/temproot and then rename the etc inside it also to etc.new and then run mergemaster -r. Then go to single user mode and rename /etc.new to /etc and reboot. This still does have all the work, but it does minimize the downtime in single user mode. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mergemaster improvement (auto-update for not modified files)
On Sat, May 14, 2005 at 08:49:17AM +0930, Daniel O'Connor wrote: > Matthew D. Fuller wrote: > >One thing that I'm pretty sure has been brought up before would be > >that, for those of us who keep a local CVS repo mirror, it's easy and > >pretty cheap to check out even arbitrary revs to compare to what's > >currently there (and if you wanted to be REALLY overly-smart, you > >could even try automagically merging local changes ;) > > etcmerge can already do this :) Maybe, but last time I tried to use it, I got the feeling that it was missing a front end. If its cleverness could be married to the ease of use of mergemaster, we would have a winner. IMVHO John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ntpd and cmos clock update
> : > : That's why I always thought that ntpd did not work in FreeBSD 5.x! > : > > : > ntpd works perfectly on FreebSD 5.x > : > : I think he refers to the fact that after a reboot, the time has to be > : adjusted by n seconds, so obviously the time that FreeBSD thought it > : was just before the reboot was just as far off... hence ntpd wasn't > : working... > > When ntpd is running, ntpd sets the time. The TODR is just something > that gets things kinda close for ntpd to actually do its work. Of > course, since all my 5.x experience is done on machines that get the > time from GPS and the local time doesn't matter at all, I might not > have noticed something like that. What happens is something like this: The machine boots and ntpd starts and maybe step the time and the tod clock is also set. If you reboot at this stage the tod clock is normally close enough that ntpd does not need to step, but if the machine runs for a long time, ntpd will keep FreeBSD time correct but the tod clock will slowly drift away. Then if you reboot or recover from a power failure, ntpd has to step the time again. If the tod clock could be synced periodically, the step on startup can mostly be avoided. I would also like something like this, maybe with a switch to enable/ disable it. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhcp boot was: Re: diskless workstation
> > the dhcp.xxx stuff is easy, the problem is that the DHCP options are not > > enough, so im trying to look into defining a FBSDclass ala PXEClient, and > > supplying stuff like usr-ip/usr-path swap-ip/swap-path or whatever. > > You don't need those; you can get them out of /etc/fstab. In particular, > the whole idea of passing the NFS swap details in at this stage is just > *totally* bogus. How do you specify nfs swap in the fstab file? I have been trying the way diskless(8) says and a few permutations thereof, but so far without luck. I get the feeling that swapon don't know how to handle nfs swap. What I have tried was: 10.1.2.3:/export/myclient/swap none swap sw,nfsmntpt=/swap 10.1.2.3:/export/myclient/swap none swap sw 10.1.2.3:/export/myclient/swap none nfs sw But each time I get this message: swapon: 10.1.2.3:/export/myclient/swap: No such file or directory John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dhcp boot was: Re: diskless workstation
> John Hay writes: > | > > the dhcp.xxx stuff is easy, the problem is that the DHCP options are not > | > > enough, so im trying to look into defining a FBSDclass ala PXEClient, and > | > > supplying stuff like usr-ip/usr-path swap-ip/swap-path or whatever. > | > > | > You don't need those; you can get them out of /etc/fstab. In particular, > | > the whole idea of passing the NFS swap details in at this stage is just > | > *totally* bogus. > | > | How do you specify nfs swap in the fstab file? I have been trying the > > You don't, it is done via the bootp or dhcp record option 128 for example > option option-128 "192.168.2.254:/usr/work/netboot"; > You then have to make the swap file in that directory of format > swap. > Use dd to create the file by copying /dev/zero for the size you want. > > Note during boot up the kernel will tell you what it is using for > swap via this request. The option-128 confuse the pxeboot program. If I put option root-path "/export/diskless"; option option-128 "10.1.2.3:/export/shark"; in the dhcpd.conf file, pxeboot tries to mount /export/sharkM-^[^B-iÿ as the root filesystem. Removing the option-128 line at least get me to boot albeit without swap. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dhcp boot was: Re: diskless workstation
> | > You don't, it is done via the bootp or dhcp record option 128 for example > | > option option-128 "192.168.2.254:/usr/work/netboot"; > | > You then have to make the swap file in that directory of format > | > swap. > | > Use dd to create the file by copying /dev/zero for the size you want. > | > > | > Note during boot up the kernel will tell you what it is using for > | > swap via this request. > | > | The option-128 confuse the pxeboot program. If I put > | > | option root-path "/export/diskless"; > | option option-128 "10.1.2.3:/export/shark"; > | > | in the dhcpd.conf file, pxeboot tries to mount /export/sharkM-^[^B-i? > | as the root filesystem. Removing the option-128 line at least get me to > | boot albeit without swap. > > Root path should have the IP address of the server such as: >option root-path "192.168.2.254:/usr/home/ambrisko/netboot"; > > Then in boot messages you should see: > rootfs is 192.168.2.254:/usr/home/ambrisko/netboot > swapfs is 192.168.2.254:/usr/work/netboot > Yes, you are right. Putting the ip number in the root-path cures the pxeboot failure. But is still only configure the NFS ROOT according to the kernel's output. I had a look at the pxe code in /sys/boot/i386/libi386/pxe.c where pxeboot is built from and in /sys/i386/i386/autoconf.c which is the kernel side and it looks like they don't do anything about swap. There is a /* XXX set up swap? */ placeholder though. :-) John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dhcp boot was: Re: diskless workstation
> In message <[EMAIL PROTECTED]>, Doug Ambrisko writes: > >| to the kernel's output. I had a look at the pxe code in > >| /sys/boot/i386/libi386/pxe.c where pxeboot is built from and in > >| /sys/i386/i386/autoconf.c which is the kernel side and it looks like > >| they don't do anything about swap. There is a /* XXX set up swap? */ > >| placeholder though. :-) > > > >Yep looks like you're right, I just tried it on 4.2-BETA it worked in > >4.1.1. Swap is now broken ... sigh this is going to be a problem. I > >guess the only thing you might be able to do in the interim is to do a > >vnconfig of a file and then mount that as swap. I think the vnconfig > >man pages describes this. Hopefully it works over NFS. > > The diskless setup we use here is based on a compiled-in MFS root > rather than an NFS root, so we couldn't use the bootp code to enable > NFS swap. Our solution was a modification to swapon() to enable > direct swapping to NFS regular files. > > This results in the same swaponvp() call that the bootp code would > use (at the time we implemented this, swapping over NFS via vnconfig > was extremely unreliable; I think things are much better now). Thanks for the patch. I was able to make a swapfile with vnconfig on -stable, but on -current I just get a device not configured error. Your patch work just fine on -current. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: React to ICMP administratively prohibited ?
> > I'm currently looking at how various operating systems react to a 'ICMP > administratively prohibited'. > > My motivation is setup's where access to the primary mailserver is > blocked by filters (usually to block open relay's), and all mail has to > go via the backup MX, a example from a customer of ours. > > jesper@freesbee$ host -t mx nemo.dyndns.dk > nemo.dyndns.dk mail is handled (pri=10) by nemo.dyndns.dk > nemo.dyndns.dk mail is handled (pri=20) by backup-mx.post.tele.dk > > Here we block access to tcp/25 on nemo.dyndns.dk (a ADSL users), but > provide a backup MX for him to use, but when a mailserver wants to send > mail to him, they will experience a timeout before sending the mail to > backup-mx.post.tele.dk, which can send the mail onwards to > nemo.dyndns.dk. You can also solve the problem another way. You can remove the MX for the customer machine, so that your backup-mx is the prefered MX for his mail. Then on backup-mx you can add a mailertable entry to direct the mail to his machine. Something like: nemo.dyndns.dk smtp:[nemo.dyndns.dk] The square brackets are needed to tell sendmail not to do MX lookups again. Or if you don't want to use mailertables, you can set the confTRY_NULL_MX_LIST variable to true. This way you don't have to worry how someone else's machine is going to handle those icmp packets. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Support for Syba pci multi i/o card?
Does anyone know of patches or something to support these cards? The cards that I have is by Syba Tech and is a 4 x serial and 2 x parallel port pci card. It has 2 winbond W83877TF 2 x serial + 1 x parallel port "superio" chips and some pci glue. The card has 0x400 bytes of io space, as big as the isa io area. Also from what I understand they all share one interrupt. FreeBSD probes it like this: found-> vendor=0x1592, dev=0x0781, revid=0x92 bus=0, slot=8, func=0 class=07-81-15, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=15 map[10]: type 4, range 32, base 6000, size 10, enabled If there aren't any patches I might look at adding support for it. Probably only the serial ports, because that is what I need. I would like some advice on how to do it though. I had a look at the sio driver and it has support for a few pci cards, but it looks like they are single serial port cards and not dual or quad. So how should I go about getting the sio probe and attach to do more than one serial port per pci card? John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
> > > > (Hurm Wintendo outperforming unix???!?? Something's > > improper about this, and it ought to be fixed... :-) > > Comments? Other OS numbers: more recent > > FreeBSD versions? Solaris? Tru64? Optimization > > patches? Can those OO MSDN lobotomies actually > > be good things? Hurm... The Italian gauntlet has > > been thrown down --dr :-) > > > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm > > I'm looking at this, FreeBSD seems to better on all accounts except > writing the packets to disk. > > Can any of the winpcap people explain exactly how they measured > the disk performance? > ... > Honestly, it really looks like the fault lies with the way tcpdump > writes to disk and not with FreeBSD. What I couldn't figure out from the url was if they were using dma for the disk. Maybe they were using it on Windows and not on FreeBSD? (On FreeBSD 3 you have to enable it with flags in the kernel config file.) Also they don't say if they have changed the debug.bpf_bufsize sysctl from its default smallish 4096 bytes. Those 2 things can make a huge difference. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Mon, Jan 12, 2004 at 11:00:34AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Mark Linimon writes: > > >But, in the real world of software engineering, He Who Breaketh It, > >Must Fixeth It. > > If we are talking paid jobs, yes, then you can make rules like that > because with the salary you control resource allocation and > prioritization. > ... > In a free software project, you can take any rule like that an put > it anywhere you like, in any font, size and color of your choice > and it still wont work. I don't think it is totally true. If a free software project have enough power to give and revoke commit bits and to make rules... They can have a rule like this: No committer may commit an API change in the kernel without also fixing the places that depend on it. The only exception is if he can get a majority vote that a certain section is not being used anymore and may be axed. Then if a developer comes with an API change, he must like it enough to do the work needed for it or motivate to the majority why a certain part have to be axed But then it is the group that decide and not him anymore. :-) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arbitrary serial speeds
Don't the stuff I committed to current do what you guys want? I'm planning to MFC it, but haven't asked Bruce yet. I'll need it before I MFC the puc driver. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] > I had changes to do this > BDE refused to commit them. > > > On Thu, 28 Feb 2002, Luuk van Dijk wrote: > > > This is a multi-part message in MIME format. > > --17932B47B695003DFEDACE26 > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > > > L.S. > > > > for a project in which I communicate with embedded controllers in cars I > > need to read and write serial data at weird speeds of 5 and 10400 baud. > > > > the beauty of the freebsd interface to the serial ports is that the > > speed > > can be specified as an integer, i.e. not neccesarily as some predefined > > constant > > like B9600, but in src/sys/isa/sio.c the supplied value is looked up in > > a table, > > so using an arbitrary baudrate like 5 will return EINVAL. > > > > (On linux there is an ugly way to set these weird baud rates by setting > > the > > baudrate to 38400, and using a special syscall to tell the kernel to use > > some other divisor of 115200 to generate the uart speed. needless to > > say, I prefer > > the hygiene commonly observed in bsd's api's) > > > > an easy way would be to add my special baudrates to the table > > 'comspeedtab' > > that maps speed to divisor, but it is even more flexible to calculate > > the divisor > > on the spot, with the same macro COMBRD() as used in the initializer of > > 'comspeedtab'; > > note that this macro will automatically round to the next higher > > baudrate that is > > a divisor of 115200. > > > > The attached patch contains the neccesary changes. It works well for > > me, > > but who knows what I broke > > > > As far as I can tell, this renders the comspeedtab table, as well as the > > routine ttspeedtab in kern/tty.c superfluous, but as I'm not sure I > > haven't > > included their removal in the patch. > > > > Whoever maintains isa/sio.c, feel free to use this. I'd be very happy > > if > > in future versions of FreeBSD I could use baudrates of 5 and 10400 > > (actually the > > latter is rounded to 10475 == 115200/11, but that's good enough for me), > > without > > recompiling. > > > > Regards, > > Luuk van Dijk > > > > ___ > > Mind over Matter lvd at mndmttr.nl > > The Netherlandstel +31 6 224 97 227 > > ___ > > --17932B47B695003DFEDACE26 > > Content-Type: text/plain; charset=us-ascii; > > name="freebsd-src-sys-isa-sio-arbitrary-speed.patch" > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline; > > filename="freebsd-src-sys-isa-sio-arbitrary-speed.patch" > > > > --- isa.org/sio.c Wed Feb 6 23:58:00 2002 > > +++ isa/sio.c Thu Feb 7 00:08:25 2002 > > @@ -2153,7 +2153,7 @@ > > t->c_ispeed = t->c_ospeed; > > > > /* check requested parameters */ > > - divisor = ttspeedtab(t->c_ospeed, comspeedtab); > > + divisor = (t->c_ospeed) ? COMBRD(t->c_ospeed) : 0; /* was >ttspeedtab(t->c_ospeed, comspeedtab); lvd */ > > if (divisor < 0 || (divisor > 0 && t->c_ispeed != t->c_ospeed)) > > return (EINVAL); > > > > @@ -2794,7 +2794,7 @@ > > * data input register. This also reduces the effects of the > > * UMC8669F bug. > > */ > > - divisor = ttspeedtab(speed, comspeedtab); > > + divisor = (speed) ? COMBRD(speed) : 0; /* was ttspeedtab(speed, comspeedtab); >lvd */ > > dlbl = divisor & 0xFF; > > if (sp->dlbl != dlbl) > > outb(iobase + com_dlbl, dlbl); > > > > --17932B47B695003DFEDACE26-- > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Decision PCCOM Serial Card
> Hi,
> Has anyone got FreeBSD to recognise one of these?
> I've tried modifying sio.c by adding this at line 598..
> { 0x0004, "PCCOM Serial", 0x18 },
>
> But no luck.. Booting -v produces no diagnostics
> pciconf -l for this card produces ->
> none0@pci0:11:0:class=0x070002 card=0x chip=0x0004 rev=0x02
>hdr=0x00
>
> The card has a PLX 9051 and 2 16750's on it. The Linux driver for it
> looks pretty basic - it is a patch to serial.c which doesn't appear to
> actually do much apart from working out how many ports the card has and
> what sort of UART it possesses. (via PCI config regs).
>
> Anyone else had any luck with these?
You might have more luck getting the puc driver to work with this card.
It is more flexable and meant for these kind of cards.
You will still need to figure out how the serial ports are organised on
the card though. Things like, does each serial port have its own BAR, or
are both inside one BAR and what the offset is where the ports start.
You might be able to figure that out from the linux patch though.
Once you figure those things out, you just add it to pucdata.c, build
a kernel with the puc device and off you go. :-)
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Decision PCCOM Serial Card
> > You might have more luck getting the puc driver to work with this card. > > It is more flexable and meant for these kind of cards. > > > You will still need to figure out how the serial ports are organised on > > the card though. Things like, does each serial port have its own BAR, or > > are both inside one BAR and what the offset is where the ports start. > > You might be able to figure that out from the linux patch though. > > Once you figure those things out, you just add it to pucdata.c, build > > a kernel with the puc device and off you go. :-) > > Hmm.. well I get this far -> > puc0: port 0xc400-0xc4ff,0xc000-0xc07f mem 0xd8002000-0xd800207f >irq 9 at device 11.0 on pci0 > puc: name: PCCOM Serial port > could not get resource Hmmm. The puc driver won't work with a mem mapped BAR. The sio driver won't like it, so I never tried to make the puc driver able to do mem mapped devices. Hopefully, one of the other BARs (the IO ones) will contain the serial ports. > > Probably just guessed the BAR address wrong I suppose. Can't you get the BAR info from the linux driver? > I made the PUC driver a module, but once I load it and it tried to > attach and errored out I now get.. > mdtest# kldunload puc > kldunload: can't unload file: Device not configured I never tried to make it into a module because I weren't sure what the interaction with the sio driver would be. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
microtime trustworthiness during booting?
Hi, >From what stage during the boot process can I trust that microtime() will give me incrementing time? The reason I ask is that I see microtime() jump backwards consistently during the ich_calibrate() function in the ich sound driver. The values look basically the same every time. Something like this: t1 2 sec 389291 usec t2 0 sec 32061 usec The interesting thing is that on another identical machine it doesn't happen and the calibrate routine works correctly. The only difference is that that machine use a GENERIC kernel and mine have a kernel with apm removed so that I can use the TSC as timecounter. Can it be that there is some kind of glitch somewhere when the TSC take over as timecounter? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 802.11: WaveLAN/Orinoco Cards
> Martin Minkus wrote: > > But it's a standard WaveLAN/Orinico card, which is what the wi driver is > > intended for? > > > > I never had to worry about any of this when I had the old white/bronze > > 2mbit wavelan cards, but with silver and gold cards, its been nothing > > but fun and games > > I suppose I can understand wanting to control the data rate > manually because you can, rather than just being happy it > works at the highest data rate... > > The only thing I could suggest would be to contact the driver > author directly and/or sign an NDA and get the programming > docs yourself. I'm pretty sure Julian could answer yes/no > questions about the card speed setttings. > Nothing as drastic as that. It is/was a bug and has been fixed: revision 1.100 date: 2002/04/14 23:18:40; author: brooks; state: Exp; lines: +15 -0 Fix tx-rate setting for Lucent cards. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [CFR] max-child-per-ip restriction for inetd
> Hi, > > I wish to add max-child-per-ip option to inetd. This enables us to > restrict maximum number of simultaneous invocations of each service > from a single IP address. The proposed patch can be found from: > > http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-5c.diff (for 5-CURRENT) > http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-4s.diff (for 4-STABLE) Both the patches needs a colon (:) after the s on the getopt() line, otherwise you just get a nasty coredump if you try to use the "-s num" commandline option. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Just a wild idea
> > > > > > I've been playing with jails for over 2 years now. I really like > > > them but we often use them to run a process as root with reduced > > > power only to get access to TCP and UDP ports below 1024. > > > > > > For many applications however, for example lpd, named, sendmail, > > > tac_plus and others, it would be more than good enough to run that > > > program as a normal, non-root user provided there is a way to bind > > > to that single low TCP and/or UDP port that the program needs access > > > to. > > better to have a definition of what are restricted ports for each jail > than to redefine what root is > > (1024 numbers is only 32 words of bitmask) Sometimes I think the below 1024 check is outdated. What about a flag to switch the below 1024 check totally off? How much do we really loose? The two most common setups are probably a single user desktop and a server box doing something like mail, web or dns. On the desktop switching the below 1024 check off only gain the user (who is also root) something, he needs to su less. In a server environment, access to the box is normally controlled in anycase, so the people who have access to the box, normally also are the ones that have the root password or whatever is needed to (re)start those services. The only place where I think the check might still be usefull, is on a general shell login box. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Advice on deriving accurate time values from the kernel?
If you only want to timestamp events and not generate the event, you can use microtime() or nanotime(). On a 400MHz PII non-SMP you should get 2.5 ns resolution with nanotime(). On a normal kernel with kern.timecounter.method at the default of 0, the get... versions give you time at the last tick or even worse, so they are no good for that. John -- John Hay -- [EMAIL PROTECTED] > Hi, > > I am in the process of developing a device driver for the purpose of > stepper motor control. The timing of each pulse is determined by > external timing hardware on an I/O board, which will fire an interrupt > after the time requested. Using this method, I am able to generate > streams of pulses at approximately 5000Hz on a Pentium II 400MHz system. > > Everything seems to be working well, but I'd really like to gather some > accurate timing data in order to derive some statistics to from the > system. Intuition tells me I'll need a clock with a tick rate of at > least 2 Hz to derive this. > > So, is such a thing available in the kernel? I've searched through > various mailing list archives and have found reference to the "HZ" > option to the kernel, which works to a point. However, it is not ideal > as setting HZ to high values generates far too much kernel overhead. > Also being considered is additional external timing hardware, but this > is something I'd rather avoid for many reasons. > > What I am after is not a "timer" as such - all I need to do is derive a > time value at an initial time, and a subsequent value at a later time. > I've used "getmicrouptime", but this appears dependent on the "Hz" > option, and as such is of limited use. > > I've just had some input from a colleauge who has suggested using the > Pentium profiling registers, which we are currently investigating... > > Any advice gratefully received, > > -- > Jennifer Clark > http://telepresence.dmem.strath.ac.uk > http://www.crmjewellery.co.uk > http://www.furniturenet.co.uk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
Are you just teasing or are you serious? I searched through their site (again), but except for being mentioned in their TODO for the past few months, I can't find anything that indicates that they or anyone else is working on it. They may be, but it isn't visible anywhere where I have looked. It would be nice if there was some place to follow their progress, because I'm also one of the people that would like to see IPv6 integrated into FreeBSD. John -- John Hay -- [EMAIL PROTECTED] > > FreeBSD will have native IPV6 within a matter of weeks at this stage.. > the code is being readied as we speak. see www.kame.net . 3 sets of > developers for FreeBSD IPV6 have merged their efforts and the result of > this should be available by the end of summer (Northern). (which isn't > far away now..) > > On Wed, 21 Jul 1999, David O'Brien wrote: > > > So is FreeBSD *EVER* going to see native IPv6 ?? > > I attended a talk by a group of Intrusion Detection researchers. They > > were basing their research on FreeBSD because they needed divert > > sockets and found FreeBSD worked perfectly for this in this respect. > > However, once they needed IPv6 and IPsec guess what happened??? They > > moved to Linux and now have such a time investment in their custom kernel > > hacks FreeBSD will never be an option for them again. > > > > NetBSD and OpenBSD get more and more coverage from IPv6/IPsec > > capabilities every day. FreeBSD has lost considerable ground if we want > > to be a platform of choice for network and security researchers. > > > > Now ever LSOF has IPv6 support for NetBSD and OpenBSD... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple routes to the same destination
> > > > > As said by the 4.4 BSD book (page 423), 4.4 BSD does not support multiple > > > routes to the same destination (identical key and mask). Does the radix > > > tree code in FreeBSD - 4.0 has the same limitation? I am wondering if > > > there is already a solution for this? > > > > How would the routing code use multiple routes? You'd need additional > > rules to determine how to use them (e.g. round-robin for load > > balancing). IIRC there was some patches around a long time ago to do this kind of thing. > > Or assign them a weight. When the link goes down, the routes attached to > this interface decrease in weight by NN. If there is any other route to > the same destination with greater weight, the packets are sent that way > instead. But can't gated do this? (Or any other routing daemon for that matter.) You don't need kernel support to do this. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A bug in the sppp driver?
Are you busy with a leased line driver or a dialup/isdn kind of driver? I have been busy fixing sppp to work properly with leased line drivers again, but am not finished with it yet. :-/ Hopefully I won't break the isdn handling at the same time. > While trying to use the sppp, I came across this situation and I think it's > a bug: > When you trying to establish connection from one peer (local) to another > (remote), you sent a CONF_REQ message to the remote peer. The remote peer > should answer with a CONF_ACK message. In the code of the sppp driver > (net/if_spppsubr.c, lines 1321 - 1357) you can see that the remote peer > send's a CONF_ACK message to the local peer > (in the line: rv = (cp->RCR)(sp, h, len);) but doesn't change it state to > STATE_ACK_SENT (as I think it should do) . Further more, you can see that > after a few lines, there are these strange lines: > case STATE_ACK_SENT: > case STATE_REQ_SENT: >sppp_cp_change_state(cp, sp, rv? > STATE_ACK_SENT: STATE_REQ_SENT); >break; My patch for this part looks like this, carefull I have just cut and paste it, so the tabs got lost: - @@ -1298,6 +1299,16 @@ /* fall through... */ case STATE_ACK_SENT: case STATE_REQ_SENT: + /* +* sppp_cp_change_state() have the side effect of +* restarting the timeouts. We want to avoid that +* if the state don't change, otherwise we won't +* ever timeout and resend a configuration request +* that got lost. +*/ + if (sp->state[cp->protoidx] == (rv ? STATE_ACK_SENT: + STATE_REQ_SENT)) + break; sppp_cp_change_state(cp, sp, rv? STATE_ACK_SENT: STATE_REQ_SENT); break; > > Question: if you are in the STATE_ACK_SENT why change the state to the same > one according to the value of rv? Because the state transition table on page 13 of rfc1661 says that if you are in "Ack-Sent" and receive a +RCR, you send a sca and stay in the same state? > > As I understand, the state should be changed according to the value of rv, > but it should be done right after the call to cp->RCR. The it is implemented > now, the state won't be changed. Like it is, it does work under ideal (no packet loss) conditions. My patch is just for the case where a scr packet got lost. > > (I have a lot of problems with this driver and any help will be > appreciative) There are two other "big" problems that I know of. If the line is down long enough, sppp will give up and go in a illegal state. It should just keep on trying to establish the link again. I have a fix that I'm testing for this. The loopback handling are broken. It just go in a transmit frenzy. I have tried the solution in gnats 11238, but I'm not happy with it, because it stops sppp when loopback is detected, which is also not what I want. But appart from these and a few minor problems sppp is working just fine here. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A bug in the sppp driver?
>
> My problem is that when you get the first CONF_REQ message, the driver's
> state is INITIAL.
> The call to the RCR function return with the value 1 but, no one changes the
> state to STATE_ACK_SENT. I think the fix should be like this (line 1274):
>
>
> rv = (cp->RCR)(sp, h, len);
>
> /* Daniel - fix */
> if (rv && sp->state[cp->protoidx] == STATE_INITIAL)
>sppp_cp_change_state(cp, sp, STATE_ACK_SENT);
>
> sp->rst_counter[cp->protoidx] = sp->lcp.max_configure;
> /* End of fix */
>
> switch (sp->state[cp->protoidx]) {
> case STATE_OPENED:
>...
I think you are trying to bypass things. Look at rfc1661 on page 6 and
12-13. If you are in state initial, you are not supposed to react to
anything except Up, Open and Close events.
Have a look at the other drivers like ar(4), cx(4) and sr(4) to see
how they use it. Also remember that they need an ifconfig to get
started. That help them trough a lot of the states. Ifconfig will
have the effect of giving an Up and then an Open event, which will
take sppp from the Initial(0) state to Closed(2) and then to
Req-Sent(6).
John
--
John Hay -- [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Release build
> Last week the releases built fine, now i get the following error : > --- > cd /usr/src/kerberosIV/lib/libsl ; make install > DESTDIR=/R/stage/trees/krb SHARED=copies > ===> lib/libacl > cd /usr/src/kerberosIV/lib/libacl ; make install > DESTDIR=/R/stage/trees/krb SHARED=copies > install -C -o root -g wheel -m 444 > /usr/src/kerberosIV/lib/libacl/../../../crypto/kerberosIV/lib/acl/acl.h > /R/stage/trees/krb/usr/include > install: mkstemp: /R/stage/trees/krb/usr/INS@3565 for > /R/stage/trees/krb/usr/include: No such file or directory > *** Error code 71 > > Does anybody know why ( i know that the directory /R/stage/trees/krb/ > does not exist , but the directory /R/stage/trees/krb4/ do exist ) ?? You are using an old /usr/src/release/Makefile? John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Class C hack instead of ifconfig aliases
> > What do you mean by "bind a class C"? Make an interface so it will > > respond to incoming requests for 10.1.2.x? ewww, yuck! > > Is it any less elegant than having in_localaddr() trawling through each item > on the address list? Perhaps 1024 items if you've got a large vweb server? > That's also pretty inelegant. > > I seem to remember someone producing some patches for this on bsdi a couple > of years ago. > I think somebody sent patches to do it a while back. I think it might be in GNATS. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should jail treat ip-number?
> > > >I have some concern about jail, and would like to discuss them. > > > >Currentlly jail set an ip-number and let prisoned processes > >only to bind it. > >My concerns are, > > > >(1)When IPv6 is added to the system, more general id would be > > desirable. > > I agree, *IF* IPv6 ever becomes a reality, we will look at this. So when will you consider that it became a reality? :-) Or am I just dreaming that some operating systems and routers ship with IPv6 and that IANA, ARIN, APNIC and RIPE are dishing out IPv6 addresses and that we are in the process of getting Kame integrated into FreeBSD? :-) John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should jail treat ip-number?
> >> >My concerns are, > >> > > >> >(1)When IPv6 is added to the system, more general id would be > >> > desirable. > >> > >> I agree, *IF* IPv6 ever becomes a reality, we will look at this. > > > >So when will you consider that it became a reality? :-) Or am I just > >dreaming that some operating systems and routers ship with IPv6 and > >that IANA, ARIN, APNIC and RIPE are dishing out IPv6 addresses and > >that we are in the process of getting Kame integrated into FreeBSD? :-) > > Once I have 50% or more of my users using IPv6 I'll consider it a > reality. hehehe, but your users will not move to IPv6, because they will say: "We are used to being able to use jail on IPv4 and you say we must wait until there is more than 50% of us using IPv6 before we will get jail for IPv6?". :-) And we can substitute whatever functionality for jail. If we want people to even think of moving to IPv6 we will have to make as much of FreeBSD's functionality work on there as possible. > > So far IPv6 has gotten no futher than OSI ever did. I think I was lucky to have mostly been screened from OSI, so I can't really compare them. IPv6 seem quitealive to me though. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Crypto in the kernel: where & how?
> > What is the plan (if any) for including crypto stuff in the kernel? > > As time goes on this will be more and more needed, eg. for IPSec > > and other VPN applications. > > The KAME/IPv6 guys have already brought this up; the agreement was > that... > > > It would be nice if we had a /usr/src/sys/crypt directory, plus whatever > > export-controlled firewalling silliness is necessary. > > ...a sys/crypt/ directory should hold their DES code. :-) ^ Shouldn't this be crypto ? That is what I see if I look on internat in the /usr/local/etc/cvsup/sup directory. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: desire for ftp.internat.freebsd.org mirror
> On Thu, Apr 06, 2000 at 12:05:48PM -0700, David O'Brien wrote: > > On Thu, Apr 06, 2000 at 02:16:15PM +0200, Jesper Skriver wrote: > > > > >elsewhere) is an abomination. Isn't there *anyone* with an permanate FTP > > > > >server that could officially mirror the crypto bits from > > > > >ftp.internat.freebsd.org? > > > > > > If the amount of data is not huge, we can put it on ftp.dk.FreeBSD.org > > > > I have no idea how big the collection is -- I could just finally login, > > but an ``ls'' timed out. > > I found out that not using passive mode works. Oops, that was my fault. Somewhere in all the wu-ftpd upgrades the ports that the CSIR firewall allowed and what wu-ftpd tried to use for passive ftp got out of sync. Should be fixed now. At the moment our (the CSIR's) internet link is VERY saturated during working hours (we are in SA so GMT+2). If you can try after hours, you should have better luck. The people responsible for our network are playing with a PacketShaper from Packeteer to see if that will help, but at the moment it seems that ftp response is worse than ever. I'm trying to work with them to see if we can get it better. BTW. Wes Peters' idea of a boat is way cheaper than what we pay for our 1Mbit/s link here. :-) John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: desire for ftp.internat.freebsd.org mirror
> > > > I could do this. What arre the setup concerns? > > > nearly none, it runs chrooted... > > cd /usr/ports/net/rsync && make install clean > man rsync > man rsyncd.conf > > easy going... > Why not just use cvsup? It is already installed and running on internat and the firewall is already configured to allow it through. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: desire for ftp.internat.freebsd.org mirror
> > > Why not just use cvsup? It is already installed and running on internat > > and the firewall is already configured to allow it through. > > The question was about mirroring the FTP site, i.e. all of the binary > packages and stuff which are also there. > I understood it is for the ftp area. You just define a collection or collections (if you want to break it up) for it and off you go. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0 - Isa devices not being probed
> In message <[EMAIL PROTECTED]> Dennis writes: > : My 4.0 system doesnt probe ISA devices on my system. > : > : Whats the trick? Is there a config requirement with old-style drivers? > > They probe great for me. what, specifically, isn't probing? He is probably talking about their own driver. In that case you have to add it to /sys/i386/isa/isa_compat.* or bite the bullet and new-busify it. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
