Re: BUF_LOCK() related panic..
In message <[EMAIL PROTECTED]>, Peter Wemm writes: >Speaking of SMP and simple locks, I'd like to turn on the debugging >simplelocks that keep a reference count and check before switching to make >sure that a process doesn't sleep holding a lock. This is a pretty >fundamental sanity check and would have found the LK_INTERLOCK problem >above before it got committed. Absolutely, I also have seen some indications that checking spl levels (#ifdef DIAGNOSTIC) might be warranted. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interesting new warnings in boot msgs from -current kernel
Non fatal, but should be fixed by the respective owners. cdevsw_add() is getting called multiple times. >WARNING: "streams" is usurping "streams"'s cdevsw[] >^^^ >WARNING: "snd" is usurping "snd"'s cdevsw[] >^^^ >WARNING: "snd" is usurping "snd"'s cdevsw[] >^^^ >WARNING: "snd" is usurping "snd"'s cdevsw[] >^^^^^^^ >WARNING: "snd" is usurping "snd"'s cdevsw[] >^^^ -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
Somebody should study the abilities of the on-cpu APIC for this for pentium ff. machines. In message <[EMAIL PROTECTED]>, Bruce Evans writes: >>dfr> If I understand this correctly, you are suggesting that we program timer0 >>dfr> so that we only take interrupts when a finetimer is due to fire? If so, >>dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me >>dfr> uneasy, even though most would return without doing any work. > >6000+ interrupts/sec is not many, unless it is done all the time. A >486/33 can handle about 5 (16000 for pcaudio + 3 * 11520 for sio's). > >>There is one problem in this method. acquire_timer0() is only implemented >>for i386. We would need to write something equivalent for alpha... > >This is a serious problem. acquire_timer0() is currently disabled even >for i386's when the i8254 is used for timecounting. This is not hard >to fix (the hooks into clkintr() work even better with timecounters >since it is not necessary to resynchronise clock interrupts after a >state change), but an i8254 interrupt frequency of 16000 Hz is too fast >to be used routinely if the i8254 is being used for timecounting (even >if the CPU can keep up with the interrupts, the overflow heuristics in >i8254_get_timecount() may break down). Other systems may have even >more limitations on the timecounters. > >Bruce > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dev_t and system accounting
In message <[EMAIL PROTECTED]>, "D. Rock" writes:
>Hi,
>
>the new dev_t stuff in the kernel keeps system accounting showing up
>the tty properly. After taking a look at the fix for the swap device,
>I propose the following equivalent fix:
Looks good, could you try this version for me ?
Index: sys/acct.h
===
RCS file: /home/ncvs/src/sys/sys/acct.h,v
retrieving revision 1.9
diff -u -r1.9 acct.h
--- acct.h 1998/02/01 20:08:35 1.9
+++ acct.h 1999/07/09 21:27:49
@@ -49,6 +49,12 @@
*/
typedef u_int16_t comp_t;
+#ifdef KERNEL
+#define __dev_t udev_t
+#else
+#define __dev_t dev_t
+#endif
+
#define AC_COMM_LEN 16
struct acct {
char ac_comm[AC_COMM_LEN]; /* command name */
@@ -60,7 +66,7 @@
gid_t ac_gid; /* group id */
u_int16_t ac_mem; /* average memory usage */
comp_tac_io;/* count of IO blocks */
- dev_t ac_tty; /* controlling tty */
+ __dev_t ac_tty; /* controlling tty */
#defineAFORK 0x01/* forked but not exec'ed */
#defineASU 0x02/* used super-user permissions */
@@ -69,6 +75,7 @@
#defineAXSIG 0x10/* killed by a signal */
u_int8_t ac_flag; /* accounting flags */
};
+#undef __dev_t
/*
* 1/AHZ is the granularity of the data encoded in the comp_t fields.
Index: kern/kern_acct.c
===
RCS file: /home/ncvs/src/sys/kern/kern_acct.c,v
retrieving revision 1.20
diff -u -r1.20 kern_acct.c
--- kern_acct.c 1999/04/27 11:15:53 1.20
+++ kern_acct.c 1999/07/09 21:26:44
@@ -221,9 +221,9 @@
/* (7) The terminal from which the process was started */
if ((p->p_flag & P_CONTROLT) && p->p_pgrp->pg_session->s_ttyp)
- acct.ac_tty = p->p_pgrp->pg_session->s_ttyp->t_dev;
+ acct.ac_tty = dev2udev(p->p_pgrp->pg_session->s_ttyp->t_dev);
else
- acct.ac_tty = NODEV;
+ acct.ac_tty = NOUDEV;
/* (8) The boolean flags that tell how the process terminated, etc. */
acct.ac_flag = p->p_acflag;
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")
>p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, >and probably wouldn't be noticed on an SMP system either because the >write-allocation overhead is already pretty bad. But I haven't tested >it. it's actually quite expensive in terms of bus bandwidth because a lot of things have to be synchronized and stalled... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")
In message <[EMAIL PROTECTED]>, John-Mark Gurney writes: >Matthew Dillon scribbled this message on Jul 12: >> p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, >> and probably wouldn't be noticed on an SMP system either because the >> write-allocation overhead is already pretty bad. But I haven't tested >> it. > >actually, I'm not so sure, it guarantees that NO other bus operation >will succeed while this is happening... what happens if a pci bus >mastering card makes a modification to this value? sure, it normally >won't happen, but it can... and w/o the lock prefix, this CAN happen >from what I understand of the architecture... it locks EVERYTHING. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using float emulator on a system with FPU?
In message <[EMAIL PROTECTED]>, "Bria >> I suggested about half a year ago that we should officially desupport >> non-FPU configurations in 4.0. Unfortunately, my resolution was >> soundly defeated. > >Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient >CPU doesn't have an FPU? And we're talking about the i386 family here... A lot of 386 machines are being built into places where people will never know they are. We should not kill that market. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
please test (linux emulation)
I have no idea how to excercise this piece of code, if somebody
could verify that it still DTRT I would be most grateful.
Poul-Henning
Index: linux_file.c
===
RCS file: /home/ncvs/src/sys/i386/linux/linux_file.c,v
retrieving revision 1.26
diff -u -r1.26 linux_file.c
--- linux_file.c1999/05/11 19:54:19 1.26
+++ linux_file.c1999/07/17 20:18:42
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -199,7 +200,6 @@
struct filedesc *fdp;
struct file *fp;
struct vnode *vp;
-struct vattr va;
long pgid;
struct pgrp *pgrp;
struct tty *tp, *(*d_tty) __P((dev_t));
@@ -304,10 +304,7 @@
vp = (struct vnode *)fp->f_data;
if (vp->v_type != VCHR)
return EINVAL;
- if ((error = VOP_GETATTR(vp, &va, p->p_ucred, p)))
- return error;
-
- dev = udev2dev(va.va_rdev, 0); /* XXX vp->v_rdev ? */
+ dev = vp->v_rdev;
d_tty = devsw(dev)->d_devtotty;
if (!d_tty || (!(tp = (*d_tty)(dev
return EINVAL;
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PLIP is still broken :(
This is actually a deficiency in the ppbus stuff, there is no telling what SPL level the subdriver wants to use, so the interrupt should actually be released back to the system when no subdrivers are open and be grabbed the way the subdriver wants it once it aquires the bus. The ZIP driver would probably want splcam/splbio, the pps wants splabsolutelynobody() (and FAST_IRQ) and plip wants splnet(). In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes: >Maxim Sobolev <[EMAIL PROTECTED]> writes: >> Some time ago I >> had rised this question and Bruce Evans told that this problem arise >> because of switch to newbus. > >You misunderstood what Bruce wrote. PLIP has always been broken. It >used to be possible to hack around the brokenness by setting the >interrupt mask to net instead of tty. With newbus, this hack is no >longer possible (it was never correct anyway; it broke printing). > >The problem with PLIP is that it tries to do splnet stuff in at >spltty. If you force the parallell port driver to run at splnet, PLIP >works but you get panics when you print because it tries to do spltty >stuff at splnet. > >SLIP and PPPD do black magic with interrupt masks so spltty and splnet >become essentially equivalen (or so I understand). They do this >because they have the exact same problems as PLIP - they need to do >splnet stuff at spltty. > >DES >-- >Dag-Erling Smorgrav - [EMAIL PROTECTED] > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message <[EMAIL PROTECTED]>, "Steven G. Kar
gl" writes:
>
>During the boot process I see
> dumpon: crash dumps to /dev/da0s1b (4, 131073)
> checking for core dump...savecore: can't find device 13/131073
>It seems that the the major device number is reset from 4 to 13.
>troutmask:kargl[225] swapinfo
>Device 1K-blocks UsedAvail Capacity Type
>/dev/#B13:0x200015118720 511872 0%Interleaved
Yes, all dev_t's which make it out of the kernel have cmajor
numbers now.
Try this change to savecore:
/ddname = find_dev/s/BLK/CHR/
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message <[EMAIL PROTECTED]>, Dav id Scheidt writes: >On Tue, 20 Jul 1999, Matthew Dillon wrote: > >> >> * make sure your swap partition is large enough to hold the crash >> dump. If you have 256MB of ram, your swap partition must be >> at least 256MB in size. > >Is there any reason that savecore(8) can't write compressed crashdumps? >(Other than no one haveing ever written the the code, of course.) In >other words, if I wrote this would it get committed? I'm pretty sure it would. I think the lack of libz has prevented it in the past. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message <[EMAIL PROTECTED]>, "Bria n F. Feldman" writes: >> /ddname = find_dev/s/BLK/CHR/ > >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed >a workaround, and now it works. There's no easy way around this, except >possibly making kern.dumpdev a string (makes quite a bit of sense there...) Indeed. a dev_t should never be exported as such from the kernel anymore, in particular not for bdevs. dumps and swap are the two offenders left. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message <[EMAIL PROTECTED]>, "Bria n F. Feldman" writes: >On Tue, 20 Jul 1999, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, "Bria >> n F. Feldman" writes: >> >> >> /ddname = find_dev/s/BLK/CHR/ >> > >> >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed >> >a workaround, and now it works. There's no easy way around this, except >> >possibly making kern.dumpdev a string (makes quite a bit of sense there...) >> >> Indeed. a dev_t should never be exported as such from the kernel >> anymore, in particular not for bdevs. dumps and swap are the two >> offenders left. > >Should I commit a similar workaround for the swap code too? Quite >simple to do... Please so, but I would appreciate if you would do me the favour of hiding the guts of this monstrosity in kern/kern_conf.c in a function called dev2budev() ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Arg! MFS broken
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: > >I'm getting really annoyed with this dev_t stuff. I wish you people >would have tested a bit more before committing it all. s/you people/Poul-Henning/ Well, I tested as best I could. I don't have the luxury of large test facilities nor boundless time, but I'm doing things as well as I can. >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. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rootfs clean flag/mount problem
Have you rebuilt your fsck after the last commit ? In message <[EMAIL PROTECTED]>, Jos Backus writes: >After booting single-user after a crash: > ># mount >wd0s1a on / (local, read-only) ># fsck -p >/dev/rwd0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS >/dev/rwd0s1a: clean, 12881 free (409 frags, 1559 blocks, 1.3% fragmentation) ># mount -u / >WARNING: R/W mount of / denied. Filesystem is not clean - run fsck >mount: Operation not permitted ># > >Just exiting the shell doesn't work; a reboot is needed to go multi-user. > >-- >Jos Backus _/ _/_/_/ "Reliability means never > _/ _/ _/ having to say you're sorry." > _/ _/_/_/ -- D. J. Bernstein > _/ _/ _/_/ >[EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer; > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rootfs clean flag/mount problem
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >>> Have you rebuilt your fsck after the last commit ? >> >>It turns out fsck was last built on Tuesday morning. I just >>rebuilt/reinstalled it and everything appears peachy again. > >I suppose current fsck's don't work with old kernels. This >is more annoying than ps not working. You suppose wrong. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for Alpha/AXP
Yes, looks right. In message <[EMAIL PROTECTED]>, "Gary Palmer" writes: > >Does this look right? Without this patch, my AXP was memory faulting >every time it booted, in the dev2udev routine. > >Thanks > > >Index: alpha/alpha/cons.c >=== >RCS file: /home/ncvs/src/sys/alpha/alpha/cons.c,v >retrieving revision 1.11 >diff -u -r1.11 cons.c >--- cons.c 1999/06/22 14:13:16 1.11 >+++ cons.c 1999/07/24 07:18:25 >@@ -88,9 +88,8 @@ > }; > > static dev_t cn_dev_t; /* seems to be never really used */ >-static udev_t cn_udev_t; > SYSCTL_OPAQUE(_machdep, CPU_CONSDEV, consdev, CTLFLAG_RD, >- &cn_udev_t, sizeof cn_udev_t, "T,dev_t", ""); >+ &cn_dev_t, sizeof cn_dev_t, "T,dev_t", ""); > > static int cn_mute; > >@@ -185,7 +184,6 @@ >cdp->d_open = cnopen; >cn_tp = (*cdp->d_devtotty)(cn_tab->cn_dev); >cn_dev_t = cn_tp->t_dev; >- cn_udev_t = dev2udev(cn_dev_t); > } > > static void >@@ -206,7 +204,6 @@ >cn_phys_open = NULL; >cn_tp = NULL; >cn_dev_t = 0; >- cn_udev_t = dev2udev(cn_dev_t); > } > > /* > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Arg! MFS broken
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... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PLIP is still broken :(
In message <[EMAIL PROTECTED]>, Nicolas Souchu writes: >Moreover, in the ppbus model, the ppc_intr() function is _always_ >the registered interrupt handler and it dispatches the interrupt >depending on the device driver which currently owns the bus when >the interrupt occurs. This is also something that should be changed since we are to modify things anyway, it introduces un-needed delays (and jitter) in the interrupt delivery. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall network performance
In message <[EMAIL PROTECTED]>, "Jordan K. Hubbard" writes: >> I was wondering what to attribute this better performance to. Could >> this be due to the new network driver / newbus integration? > >The CVS metadata was removed, reducing the inode count per port significantly. >This results in faster extraction time and hence "faster" downloads, assuming >that extraction time is the bottleneck (which it is for all but the 28K and >below downloaders). We should look into distributing ports as a Makefile and a tar-ball with the rest of the files. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: softdep_flushfiles: looping
In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes: >David Scheidt <[EMAIL PROTECTED]> writes: >> Six weeks, and no computer more sophisticated than the SCUBA one, are what >> I remembered. Someone remind me what a vacation is again? > >des@flood ~% whatis vacation >vacation(1) - return ``I am not here'' indication > >Apparently, it means he's not there. You got that wrong: It said he's not *here*, so unless he has disappeared there is a very good chance that he is *there*, wherever that is. Probably out in the big coloured room somewhere... Can we please stop this thread now ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sitting inside, looking out...
some time to spare, you'll pass the muster, no worries. And don't despair: we generally appoint a "mentor" for all new committers. The mentor is responsible for helping the new committer "learn the ropes", and generally help them get cross the threshold without getting eaten by the lions. And I hope it is all worth it for the committers, because you are certainly the biggest asset we have in the project. I'm sorry that there isn't much but the title and the rather limited fame we can offer you in return. NOTE: If somebody can find a sponsor for it, I would really like to offer an "official FreeBSD Committer sweat-shirt" to each and every single committer. Luxury cars, free vacations and suitcases filled with cash would also do. 3. The GNATS database, who handles it ? --- Simple: You do. Even if you are not a committer, you can help out: Find a PR, try to reproduce the problem if you can, then try to fix it if you can. If the PR contains a patch, try it out. And at the end, send a follow up to the PR with your results. A PR with a complex patch has much better chances of getting committed if the PR has a couple of follow-ups which say "works for me" than if it just sits there. 4. mac68k as a new platform ? - We have been contacted by Grant Stockly <[EMAIL PROTECTED]>, who informed us that he has a almost finished port of FreeBSD to the mac68k platform. [In general I would advice that people drop the core team a note early in such an undertaking. It would be a pity if somebody else was doing the same thing and you couldn't work together just because you didn't know about each other]. The core team is very keen for more platforms, but a certain level of interest and support from users and developers is needed before we will add a platform as an official part of FreeBSD, so now is the time for those of you who have an interest in the mac68k or 68k support in general, to rally around Grant and work with him on this. Our postmaster will happily create a mailing list if you want it. That's all for now folks... Poul-Henning PS: See you all at the FreeBSD-con in October! http://www.freebsdcon.org/ -- 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!
junior-hacker task: "prepdisk"
It seems that our new boot blocks doesn't like the taste of disks
prepared according to the meagre information we have in the handbook.
The following script seems to DTRT for me, and should really be
either integrated into a "fdisk -A" flag or maybe as a stand alone
script. Either way: manpage & handbook needs updated too.
It will not make it to the top of my todo list in this geological
period, so if somebody wants to pick up here I think a lot of people
will come to appreciate it...
Poul-Henning
#!/bin/sh
dev=fla0
grep "$dev.*sectors" /var/run/dmesg | tr -d '(:)' | awk '
{
v = $3
c = $5
h = $7
s = $9
ss = c * h * s - s
print "#",$0 > "_"
print "g c"c" h"h" s"s > "_"
print "p 1 165",s,ss > "_"
print "a 1" > "_"
print "#",$0 > "__"
print "type: ESDI" > "__"
print "disk:", $1 > "__"
print "label:" > "__"
print "flags:" > "__"
print "bytes/sector: 512" > "__"
print "sectors/track:", s > "__"
print "tracks/cylinder:", h > "__"
print "sectors/cylinder:", s * h > "__"
print "cylinders:", c > "__"
print "sectors/unit:", ss > "__"
print "rpm: 3600" > "__"
print "interleave: 1" > "__"
print "trackskew: 0" > "__"
print "cylinderskew: 0" > "__"
print "headswitch: 0 # milliseconds" > "__"
print "track-to-track seek: 0 # milliseconds" > "__"
print "drivedata: 0 " > "__"
print "8 partitions:" > "__"
print "#size offsetfstype [fsize bsize bps/cpg]" > "__"
print "a:",ss,"0 4.2BSD 512 4096 " > "__"
print "c:",ss,"0 unused 0 0" > "__"
}
'
fdisk -f _ -i -v $dev
disklabel -BrR ${dev} __
newfs /dev/r${dev}a
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: junior-hacker task: "prepdisk"
In message <[EMAIL PROTECTED]>, Nik Clayton writes: >On Sun, Aug 01, 1999 at 04:19:52PM +0200, Poul-Henning Kamp wrote: >> The following script seems to DTRT for me, and should really be >> either integrated into a "fdisk -A" flag or maybe as a stand alone >> script. Either way: manpage & handbook needs updated too. > >What, specifically, is wrong with them? Well, the suggested example in the handbook doesn't work for a boot disk, and if options or commands are added a manpage should be too :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: junior-hacker task: "prepdisk"
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >All of the above only work for the easy case where the whole disk is >being labelled. In general, the disk size must be reduced to the slice >size before applying a label to a slice. And that is the problem, it seems that "dangerously dedicated" doesn't boot anymore... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall network performance
In message <[EMAIL PROTECTED]>, Warner Losh writes: >In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: >: > Jordan exists. >: >: Don't go there. This whole existance-of-perl-scripts thingy is >: dangerous territory. > >I've met jordan's cats, does that count :-) Only if you can prove that it was Jordans and not Schroedingers :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: junior-hacker task: "prepdisk"
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> In message <[EMAIL PROTECTED]>, Bruce Evans writes: >> >> >All of the above only work for the easy case where the whole disk is >> >being labelled. In general, the disk size must be reduced to the slice >> >size before applying a label to a slice. >> >> And that is the problem, it seems that "dangerously dedicated" doesn't >> boot anymore... > >It never did, on many hardware variants. Use "truly dedicated" >instead, which should still work fine. My semantics may be wrong on these two: what I'm talking about is what is in handbook chapter 8 "Using command line utilities " gives you a disk which doesn't boot. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: junior-hacker task: "prepdisk"
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> My semantics may be wrong on these two: what I'm talking about is >> what is in handbook chapter 8 "Using command line utilities " gives >> you a disk which doesn't boot. > >Ok; of those two examples, the first should give you a truly dedicated >disk. (You can only generate a "dangerously dedicated" disk with >sysinstall.) > >What fails? Can you be more specific? How recent are your boot1/boot2 >blocks? I would be inclined to dd at least 8k over the front of the >disk myself, but I don't think that's relevant in your case. Disk error #1 while trying to load boot/loader. I think the bios in this case trust the 5 in the length field of the mbr. We really need commandline tools that can do this... And without too much magic please... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: junior-hacker task: "prepdisk"
In message <[EMAIL PROTECTED]>, Robert Nordier writes: >> >What fails? Can you be more specific? How recent are your boot1/boot2 >> >blocks? I would be inclined to dd at least 8k over the front of the >> >disk myself, but I don't think that's relevant in your case. >> >> Disk error #1 while trying to load boot/loader. I think the bios >> in this case trust the 5 in the length field of the mbr. > >Any better luck after enabling "LBA access" in boot1 as a build >option (added back a few weeks ago), or does the BIOS not support >this? > >BTW: Is this a genuine hard drive, or some form of disk-on-a-chip? >I seem to recall the BIOS geometry in some cases uses a small number >of sectors per track, which may push part of the 'a' partition >beyond the 1023 CHS limit. I've seen this on both flash disks and real disks. The flash disks have geometries which put them firmly inside 1023 cyls: fla0 maddr 0xd msize 8192 on isa fla0: fla0: 39.1MB (80144 sectors), 1001 cyls, 16 heads, 5 S/T, 512 B/S fla1 maddr 0xd2000 msize 8192 on isa fla1: fla1: 70.5MB (144320 sectors), 1002 cyls, 16 heads, 9 S/T, 512 B/S fla2 maddr 0xd4000 msize 8192 on isa fla2: fla2: 39.1MB (80144 sectors), 1001 cyls, 16 heads, 5 S/T, 512 B/S fla3 maddr 0xd6000 msize 8192 on isa fla3: fla3: 141.0MB (288832 sectors), 1002 cyls, 16 heads, 18 S/T, 512 B/S fla4 maddr 0xd8000 msize 8192 on isa fla4: fla4: 7.8MB (15920 sectors), 995 cyls, 16 heads, 1 S/T, 512 B/S So cyl 1024 should not even enter in the equation... My real beef here is not with the boot failure but with the fact that our command line tools stink when I bring in a new blank disk... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sitting inside, looking out...
In message <[EMAIL PROTECTED]>, Nik Clayton writes: >Just for completeness; Yeah, sorry for leaving you gang out , but I didn't want to make it too long, the important thing was to get the three main kinds down, doc committers are pretty much the same story as the other two "limited scope" types. >At least, that's my take on it. > >> NOTE: If somebody can find a sponsor for it, I would really >> like to offer an "official FreeBSD Committer sweat-shirt" >> to each and every single committer. Luxury cars, free >> vacations and suitcases filled with cash would also do. > >How about the FreeBSD Project coming up with the >artwork, and then 'licensing' it to each user group? For it to have significance for the committers, it should be done in such a manner that only the committers get their hands on them. >Hmm. "I submitted a PR to FreeBSD, and all I got was this lousy t-shirt." Now, there's an idea :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: junior-hacker task: "prepdisk"
In message <[EMAIL PROTECTED]>, Warner Losh writes: >In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes: >: It seems that our new boot blocks doesn't like the taste of disks >: prepared according to the meagre information we have in the handbook. > >How does this script differ from 'disklabel -w wd0 auto'? It does do >the fdisk stuff (your script, not the disklabel command). It differs in that you can boot from the disk afterwards with my script, you cant with disklabel -w wd0 auto. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: junior-hacker task: "prepdisk"
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >>>: It seems that our new boot blocks doesn't like the taste of disks >>>: prepared according to the meagre information we have in the handbook. >>> >>>How does this script differ from 'disklabel -w wd0 auto'? It does do >>>the fdisk stuff (your script, not the disklabel command). >> >>It differs in that you can boot from the disk afterwards with my script, >>you cant with disklabel -w wd0 auto. > >That may be because you forgot to supply the -r or -B args to disklabel, >[...] No it is because the fool BIOS belives the 5 in the MBR. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
In message <[EMAIL PROTECTED]>, Garrett Wollman writes: >< >said: > >> You've got to be kidding. That makes them totally useless for server >> operation -- at some random time every week, down goes your server for a >> few minutes. :( > >Ye gets what ye pays for if you want a reliable server, use SCSI. Fair to say in this case, IBM goes out of their way to explain that *DESK*star is NOT for servers. For a server you want ULTRAstar disks. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEV_MODULE doesn't support dynamic major numbers any longer?
In message <[EMAIL PROTECTED]>, Assar Westerlund writes: >It seems to be the case that the possibility of specifying a major >number of NOMAJ in DEV_MODULE has vanished. The cmaj and bmaj in DEV_MODULE are only used for ordering the drivers, and otherwise with no significance. You should store your majors in your cdevsw structure. I don't particular like the concept of DEV_MODULE registrating the cdevsw by magic. >cdevsw_add() doesn't have any code for handling NOMAJ any longer. >(The only mention I can find of NOMAJ in a -current kernel tree from >19990811 are these: >which makes me wonder how the promcons works...). Fine, see above. >Is this intentional that there isn't there any support for dynamically >assigning major device numbers or is it an accident that I should go >and rectify? The previous code was a hack and inflicted problems. The right solution, (until DEVFS of course) is to add two new functions: alloc_cmaj() and alloc_bmaj() and use those. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with 4.0 keyboard input!
In message <000401bee65b$b6fd0440$0264a8c0@.demon.nl>, "Ron Klinkien" writes: >>I get the bktr device usurping its own cdevsw[] as well - I was >>told it was "most likely" benign, so I've been waiting for >>others' comments. > >I have looked in the source code, but what does usurping means? >My English is not that good ;) It means "to take or assume and hold (something) by force or without right". Usually used about power in subsaharan our south american countries. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel hacker tasks seek interested hackers
Well, autumn and winter is on us pretty soon. At least on my lattitude that means hot tea inside warm and cosy houses while the elements do their best to make life misserable for anything still left on the outside. Here are some tasks which could put an evening or more to productive and educational use for interested kernel hackers. They may also make a nice assignment for CS classes. 1. [easy] The SLIP device/interface could use the same makeover as tun, bpf and pty has received. (see also #5) 2. [easy] The PPP device/interface ditto. (see also #5) 3. [easy] The snp/snoop device/interface ditto. 4. [not quite easy] The CCD device ditto. Earn brownie points: Make ccdconfig use sysctl instead of libkvm to read back configuration. 5. [unknown] The I4B devices ditto. Contact [EMAIL PROTECTED] before starting on this one. 6. [medium] The TUN, SLIP and PPP interfaces should probably clean up all the way including a if_detach on last close. Earn brownie points: Do The Right Thing for SNMP. 7. [medium] The current naming for ptys doesn't scale that well. Changing it to ttyp%d / pty%d would probably be a good idea in the long run, but the ramifications are relatively widespread (think: "ports") 8. [pretty easy] Track the API documented in draft-mogul-pps-api-*.txt and implement it in FreeBSD. 9. [all winter] Write a proper DEVFS based on the new dev_t, which handles chroot/jail partitions and clone devices and has interface to a "devd" daemon which can DTRT when devices come and go. Have at it, and send patches with send-pr... Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message <[EMAIL PROTECTED]>, Narvi writes: > >On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: > >[snip] > >> >> 7. [medium] The current naming for ptys doesn't scale that >> well. Changing it to ttyp%d / pty%d would probably be a >> good idea in the long run, but the ramifications are >> relatively widespread (think: "ports") >> > >Which while being scaleable in one direction (you can have things like >/dev/pty1234567890) as it is essentialy open ended, on the other hand: > > a) pty/tty names are now variable length > b) the name length advances quite quickly as we add more ptys > c) it is a totaly new "look and feel" > >So why not instead: I think that is needlessly complicated. I think tty%05d would solve all but the third of your objections, and quite frankly the "we've never done that before" argument works badly with me. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message <[EMAIL PROTECTED]>, Narvi writes: >> I think that is needlessly complicated. > >It's a direct extension to the present tty naming scheme. That doesn't automatically imply that it is a good idea :-) >> I think tty%05d would solve all but the third of your objections, > >The first was more a question of radix, implying that 10 might be too low. You know, then make it tty%012d and pretty much everybody on this planet should be happy, right ? >IMHO base-32 has many good qualities to itself. It makes retaining the >policy of creating ptys in increments of 32 easy, the name space does not >grow as fast (pty allows for more ptys than pty%06d) and it is not >much different from the naming system. There is no "policy of creating ptys in increments of 32" that I know of. /dev/MAKEDEV does it that way, but it is neither a policy nor desirable in my mind. I would far rather have it like tun, bpf and other sane pseudodevices: sh MAKEDEV pty200 # Make me 200 ptys. >> and quite frankly the "we've never done that before" argument >> works badly with me. > >It's more the argument of "why do it *significantly* differently from >others?" Run that by me again: what is it ptys are called under Solaris, HPUX, AIX, generic SVR4 etc etc ? I think your suggestion belongs in the Obfuscated Sysadm Contest, not in FreeBSD. I'm also pretty convinced based on your past performances that you intend to argue this point until cows evolve into birds, so expect no more emails from me on this subject. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes: >Hi, > >There're a couple of variables in the Linuxulator that can be put under >sysctl. These include the kernel version and the OSS version, among >probably others. > >The question is simply were in the MIB to put them? >1) under "kern.linux" >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! 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
In message <[EMAIL PROTECTED]>, "Brian F. Feldman" writes: >On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: > >> >The question is simply were in the MIB to put them? >>... >> >3) under "linux" >> >> I vote for 3. > >I suppose, but wouldn't the proper place be under machdep? I agree that >a linux top-level MIB would be easiest to remember. We may have to emulate linux on other platforms as well... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
In message <[EMAIL PROTECTED]>, Greg Lehey writes: >On Sunday, 15 August 1999 at 12:27:57 +0200, Poul-Henning Kamp wrote: >> >> Well, autumn and winter is on us pretty soon. At least on my >> lattitude that means hot tea inside warm and cosy houses while the >> elements do their best to make life misserable for anything still >> left on the outside. >> >> Here are some tasks which could put an evening or more to >> productive and educational use for interested kernel hackers. >> >> They may also make a nice assignment for CS classes. >> >> 1. [easy] The SLIP device/interface could use the same >> makeover as tun, bpf and pty has received. (see also #5) > >Care to explain (read: document) the makeover? That would make this >and the following tasks even simpler. Please examine the most recent commit to tun, bpf or pty. That is much easier than me explaining it. >> 7. [medium] The current naming for ptys doesn't scale that >> well. Changing it to ttyp%d / pty%d would probably be a >> good idea in the long run, but the ramifications are >> relatively widespread (think: "ports") > >Is there any reason not to have both names, at least for the first 256 >devices? Size of /dev directory maybe ? I dunno, who ever implements this can do it however they like... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> > 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? >Given that "ABI" is a bit obscure, kern.compat is the only sensible >choice. I think that is too obscure considering the exposure this will get. It doesn't really matter much what we feel about it, linux will be a native and 100% normal binary format for us, if we try to marginalize it we loose in perception. We have things to make us posix compatible at the top level already, I don't see why the linux stuff should live under the top level too. And as father of sysctl, I think this discussion needs to come to a close rather than waste more bandwidth, so unless Mike can convince us why "Adding anything at the top level would be a terrible mistake" I think the conclusion is "linux.*" Last call Mike ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> I think that is too obscure considering the exposure this will get. > >What "exposure"? It's a backend to a tuning interface for our ABI >compatibility... We will be judged on how well we run linux more than many other sane factors in the future. >>From the perspective of an integrated namespace, we've already made the >wrong moves insofar as vm.* should be kern.vm.*, vfs.* should be >kern.vfs.*, etc. Either the entire kernel namespace should have a >presumed leading kern. (and the existing kern.* nodes need to move) or >we should relocate stuff to reflect a more ubuquitous naming >arrangement. You know, all your argument here supports is that the "kern" toplevel tree is a mistake :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Q: Extending the sysctl MIB for Linuxulator variables
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> In case anyone cares I'd like to put in a vote for compat.linux. >> >From the design standpoint this balances the needs of prominence and clean >> top level name space nicely. > >And in case it's not clear from the exposition in my message to Poul, I >would find this most agreeable too. Cool! Concensus, (I thought "compat" was on the black list with "emulation" ?) Now everybody shut up and code! -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current broken?
I saw that yesterday, and fixed it by: cd /usr/src make includes cd /sys/i386/conf config -r CRITTER cd ../../compile/CRITTER make depend make In message <[EMAIL PROTECTED]>, Christopher Masto writes: >Yesterday and today, after a cvsup and kernel build, I get a panic >very early in the boot on my laptop. What's left on the screen is a >general protection fault in kernel mode, and an attempt to trace just >causes another panic. Tomorrow I will put a serial cable on it and >get some details, but I'm guessing that this comes from the recent >BUF_STRATEGY stuff, possibly breaking in the wd driver (which might >be why there hasn't been a report yet if most everyone is using ata). > >I'm stuck with wd for the moment (pccard compact flash stuff), so if >that's it and it hasn't been repaired by then, I'll dig into it. >-- >Christopher Masto Senior Network Monkey NetMonger Communications >[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net > >Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PnP probe croaks in boot...
Mike, the PnP probe you added panics my HP800CT during boot. With -v it prints (typed from barely legible notes:) PnPbios: Found PnPBiosdata 0xc00ff000 PnPbios: Entry e8000:33e1 rev 1.0 PnPbios: eventflag at e801b OEM ID 1826744e and then panics with a pagefault at EIP: %058:0x343e, fault address 0x100e. Adding some debugging showed me that this happens on the very first call to bios16_call(). The funny thing is, this happens after a cold boot (hard reset), and goes on until I have booted my /kernel.good (from before your change) just once. After that, and until next hard reset a -current kernel boots just fine. Smells like som unitialized data or something to me... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug with malloc_options
The two lines were intended to be used inside a function, and I'm sure they'll work there... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic at boot with -CURRENT (last 2-3 days)
See my earlier post today, it is due to the PnP probe. If you boot a kernel which is older than Mikes commit, you can boot the new kernel after a soft reboot... Poul-Henning In message <[EMAIL PROTECTED]>, Thomas Stromberg writes: >Background: >--- >Work recently assigned me a Gateway GP7-500 (PIII-500mhz, 96M RAM) to >replace my older 333mhz PII that's been running FreeBSD 3.2.. Of course, >as my testing machine, I wanted to run FreeBSD 4.0-CURRENT on it, and >installed the 19990806 snapshot without a problem, and then cvsupped it >to -CURRENT. > >Problem: > >This was on 17AUG, my kernel panic'd, I just assumed I left something >out, but then I saw that GENERIC panic'd as well, and has panic'd since >17AUG, and continues to do so with the -CURRENT snapshot of an hour >ago. However, GENERIC from 19990806 works just fine. I decided that >after 3 days of kernel panics that it's a real problem and not just some >little -CURRENT breakage. > >I decided yesterday that maybe I need to make world first, so I did. No >dice there. And an hour ago, I also rm -Rf'd /usr/src, cvsupped to >-CURRENT, made world again, and attempted to rebuild the kernel. > >Boot Sequence: >-- >If you want to see dmesg.boot from the 4.0-19990806-CURRENT snapshot, >it's at http://haloblack.org/misc/dmesg.boot > >FreeBSD 4.0-CURRENT #0: thu Aug 19 12:44:12 EDT 1999 > [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC+DDB >Timecounter "i8254" frequency 1193182 Hz >CPU: Pentium III (498.67-MHz 686-class CPU) > Origin = "Genuine Intel" Id = 0x672 Stepping = 2 > Features = blah blah blah >real memory = 100663296 (98304K bytes) >config> di lnc0 >config> di le0 >.. >.. >config> q >avail memory = 93708288 (91512K bytes) > > >Fatal trap 9: general protection fault while in kernel mode >instruction pointer= 0x58:0xbc28 >stack pointer = 0x10:0xed4 >frame pointer = 0x10:0xf20 >code segment = base 0xc00f, limit 0x, type 0x1b > = DPL 0, pres 1, def32 0, gran 0 >processor eflags = interrupt enabled, resume, IOPL = 0 >current process= Idle >interrupt mask = net tty bio cam >kernel: type 9 trap, code=0 >Stopped at 0xbc28: > > > > > >-- >Med vanlig halsingar, > > > thomas stromberg [TRS40/SM0VVW]: smtp([EMAIL PROTECTED]) > systems guru / asst. is manager: http(www.afterthought.org) > research triangle consultants, inc : pots(919.380.9771 x3210) > http://www.rtci.com: fax(919.380.1727) > FreeBSD: The Power to Serve! : icq(17468041) > BeOS Developer ID: 18330 : efnet(Mithra) >-------- >: "if you do nothing enough, something's bound to happen.." : > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with vnconfig -s labels ...
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes: >> > 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. Try to revert the BUF_STRATEGY() patch, if that fixes it vn is broken. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with vnconfig -s labels ...
In message <[EMAIL PROTECTED]>, John Birrell writes: >The problem is that disklabel executes code in subr_diskslice.c which >does: > >dev1 = dkmodslice(dkmodpart(dev, RAW_PART), slice); > >The 'dev' structure has s_drv1 set correctly, but the 'dev1' entry >has s_drv1 NULL. When vnstrategy() is called using dev1, >vn = bp->b_dev->s_drv1 is NULL when it shouldn't be. The first time >vn is referenced... fall down go boom. Bingo, thats it. >but I'm still looking for the place >where the dev1 entry is supposed to be initialised. In dkmodslice() (and friends). -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with vnconfig -s labels ...
In message <[EMAIL PROTECTED]>, John Birrell writes: >On Sat, Aug 21, 1999 at 07:30:46AM +0200, Poul-Henning Kamp wrote: >> >but I'm still looking for the place >> >where the dev1 entry is supposed to be initialised. >> >> In dkmodslice() (and friends). > >Hmmm, I know this is your code, but are you sure? 8-). My understanding of >dkmodslice() and friends is that they manipulate dev_t entries, but don't >actually initialise them. Since the subr_diskslice code takes a dev_t >and goes off and accesses the raw partition entry, my guess is that >vnopen() should check if the raw entry has been initialised, and if >not do it, just like it does for the one you open. That could be done too. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with vnconfig -s labels ...
In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>>Hmmm, I know this is your code, but are you sure? 8-). My understanding of
>>dkmodslice() and friends is that they manipulate dev_t entries, but don't
>>actually initialise them. Since the subr_diskslice code takes a dev_t
>
>dkmodslice() once just manipulated bits in dev_t scalars. Now that dev_t
>is a pointer, dkmodslice() has to create something for the pointer to
>point to. That something needs to be fully initialised and not created
>more than once. The initialisation is apparently incomplete. Multiple
>creation is avoided by searching the list of previously created entries.
>
>Now I understand why my memory is filling up with unused dev_t
>entries :-). subr_diskslice churns through a not insignificant part
>of the per-drive minor number space (32 slices * 8 partitions * {raw,
>buffered}), using dkmodslice to create new dev_t's.
yes, this is the remaining sticky issue, and the only cure I know for
this and for the DEVFS issue is to relayer the slice/label processing
out of the device driver entirely. This is now almost possible to do.
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
if_de.c breakage ?
Am I the only one to see these ? critter# make cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../pci/if_de.c ../../pci/if_de.c: In function `tulip_pci_attach': ../../pci/if_de.c:5316: warning: implicit declaration of function `EVENTHANDLER_REGISTER' ../../pci/if_de.c:5316: `shutdown_post_sync' undeclared (first use in this function) ../../pci/if_de.c:5316: (Each undeclared identifier is reported only once ../../pci/if_de.c:5316: for each function it appears in.) ../../pci/if_de.c:5317: `SHUTDOWN_PRI_DEFAULT' undeclared (first use in this function) *** Error code 1 Stop. critter# -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> So I still stick with my statement that the -current bootblocks/loader >> doesn't have the computrons needed to use the ad device (or any non >> wd/da/fd device for that matter) for anything usefull :) > >The loader is fine; the problem is just that Poul never finished fixing >the mountroot code. All the loader does is read /etc/fstab and pass in >the entry for /. It's up to the kernel to work it out from there, and >that's where it's falling down. Excuse me! I fixed boot -a, and you came rushing in and said that the boot code could use the same thing, so obviously I expected you to do that, since the boot code is your baby... I don't even know where to look for the cookies left by the bootcode... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: > >It's a bug, one that I've brought up with Kirk. The problem is that the >structures used internally by softupdates are not condusive to doing a >hard-sync. I gues sync needs to set a flag which makes the sync'er go through all buckets with no delay and then wake the sync'ing process afterwards... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >:>structures used internally by softupdates are not condusive to doing a >:>hard-sync. >: >:I gues sync needs to set a flag which makes the sync'er go through all >:buckets with no delay and then wake the sync'ing process afterwards... >: >:-- >:Poul-Henning Kamp FreeBSD coreteam member > >It won't help. What needs to happen is for the VOP_FSYNC in ffs to >figure out buffer<->buffer dependancies But the buffer to buffer dependencies are already recorded in the sequence on the "sync-wheel" which the syncer daemon runs through, isn't it ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sync(8) doesn't have any effect on softupdates-enabled filesystem
So what do we do when we halt or reboot ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >This is not a port, its part of the RELEASE! > >Its several YEARS old, and doesn't work right - you get lots of STEP changes >instead of what you SHOULD get, which is a slew on the system clock. Remember to get the kernel code involved. To do this: create a driftfile containing "0 1\n" start xntpd That will help. The new ntpd is in -CURRENT. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes:
>On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
>>
>> >This is not a port, its part of the RELEASE!
>> >
>> >Its several YEARS old, and doesn't work right - you get lots of STEP changes
>> >instead of what you SHOULD get, which is a slew on the system clock.
>>
>> Remember to get the kernel code involved. To do this:
>>
>> create a driftfile containing "0 1\n"
>> start xntpd
>>
>> That will help.
>
>No it won't. I've been running xntpd for oh, four or five years now on
>various things. Yes, the drift file is there (and has been). Still got the
>step time messages.
Uhm, Karl, please try to calm down, OK ?
I didn't talk about having a driftfile, I talked about using the kernel
PLL: ("Remember to get the kernel code involved.")
With xntpd the kernel-pll is very optional, in fact only the source tells
you that the magic secret second field in your driftfile controls if
the kernel-PLL should be used or not.
Anyway, ntpd4 is in CURRENT...
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, John Polstra writes: >In article <[EMAIL PROTECTED]>, >Karl Denninger <[EMAIL PROTECTED]> wrote: >> >> It looks like ntpd (the new one) works correctly; I grabbed the latest >> from the official site last night and by this morning the dispersion >> and offsets were stable. > >BTW, you might want to add these lines (from LINT) to your kernel >config if you haven't already: > ># ># POSIX P1003.1B > ># Real time extensions added int the 1993 Posix ># P1003_1B: Infrastructure ># _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING ># _KPOSIX_VERSION: Version kernel is built for > >options "P1003_1B" >options "_KPOSIX_PRIORITY_SCHEDULING" >options "_KPOSIX_VERSION=199309L" > >Current versions of ntpd use these features if they're available. I >think "_KPOSIX_VERSION=199309L" is the default, so that one probably >isn't strictly necessary. I seriously doubt using these will do anything for NTPDs performance. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >> >options "P1003_1B" >> >options "_KPOSIX_PRIORITY_SCHEDULING" >> >options "_KPOSIX_VERSION=199309L" >> > >> >Current versions of ntpd use these features if they're available. I >> >think "_KPOSIX_VERSION=199309L" is the default, so that one probably >> >isn't strictly necessary. >> >> I seriously doubt using these will do anything for NTPDs performance. > >It won't, but it will stop ntpd from bitching in the syslog about them being >missing :-) Hm, I actually thought I managed to get somebody to solve that somehow, maybe I didn't quite succeed :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >Yes, and my driftfile had that parameter in there. Uhm, Poul, remember I've >been at this for just a LITTLE while. Xntpd is something I had deployed >back in my *Sun* days (back when FreeBSD was, well, non-existent) Karl, remember who was there too ? :-) >> Anyway, ntpd4 is in CURRENT... > >Now it is. > >And it works correctly too. In general yes, but not if you use the hardpps() with a refclock, it works better after I fixed a couple of almost-mutually-canceling sign-bugs, but the parameters of the hardpps() PLL relative to the FLL are wrong. >Thanks anyway, even with the attitude. Many happy returns :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
:
>Does it help in the 3.4-stable version to set the second value in ntpdrift
>to 1?
Yes, although I have never checked all the boundary conditions
to make sure the kernel-pll is stable over the entire envelope.
I'm doing that for the NTPv4/nanokernel combo, and I'm resolving
the problems I find with Dave Mills.
>And why has the manual page never been updated, it is clearly wrong
>when it talks about the contents of driftfile! :-(
I updated neither the manpage nor the code because of the above.
>> Anyway, ntpd4 is in CURRENT...
>
>Well... that won't help the 20 or so boxes here doing this all the
>time:
>Jan 1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
>Jan 1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
(-0.217546 - 0.207523) / (14 + 5 * 60 + 6) = -.001328340
Your clock is too sick, (or our calibration of it is hosed), no
version of {X}NTP will touch a clock which is outside +/- 500ppm.
Could you try to measure the 14.31818... MHz base frequency and
the 32768 kHz wristwatch xtal as well (I know you're RadioActive,
so I pressume you have a counter ?)
If they're both OK, then we have a code problem...
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >> >> Anyway, ntpd4 is in CURRENT... >> > >> >Now it is. >> > >> >And it works correctly too. >> >> In general yes, but not if you use the hardpps() with a refclock, >> it works better after I fixed a couple of almost-mutually-canceling >> sign-bugs, but the parameters of the hardpps() PLL relative to the >> FLL are wrong. > >You're still a bunch of revs back - the current is either "h" or "i", and it >has a bunch of fixes (including one here, I think) No, the NTP distribution doesn't contain the kernel code, it only interfaces to it. I'm sure Ollivier will upgrade us every so often now :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes:
>> >Well... that won't help the 20 or so boxes here doing this all the
>> >time:
>> >Jan 1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
>> >Jan 1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
>>
>> (-0.217546 - 0.207523) / (14 + 5 * 60 + 6) = -.001328340
>>
>> Your clock is too sick, (or our calibration of it is hosed), no
>> version of {X}NTP will touch a clock which is outside +/- 500ppm.
>>
>> Could you try to measure the 14.31818... MHz base frequency and
>> the 32768 kHz wristwatch xtal as well (I know you're RadioActive,
>> so I pressume you have a counter ?)
>>
>> If they're both OK, then we have a code problem...
>
>You have a code problem ;-)
If you have access to a frequency counter, could you try to make the
same measurements please ?
Do you have any refclocks we can use to measure against ?
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
>BTW, speaking of which, does anyone know of a reasonably-cheap GPS receiver >that (1) has an external-able antenna that will work with somewhere between >50 and 100 feet of lead, and (2) has the appropriate pps outputs and such >so it can be used for this? I will (as always) recommend the Motorola Oncore UT+. If you buy it from syngergy-gps it comes mounted in their nice box and the cable has the PPS on DCD and is ready to plug into a serial port. I paid $605.73 for the one I'm delivering to the Danish Internet eXchange point, that included antenna and 15m of cable. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Ollivier Robert writes: >According to Poul-Henning Kamp: >> I'm sure Ollivier will upgrade us every so often now :-) > >'98i' looks like a nice release candidate and will probably become 4.1.0 >soon. I'll update us to that level of course. > >Still no feature freeze for 4.0 BTW? Feature freeze is in effect I think, but minor upgrades and bugfixes are not only allowed, they're mandatory :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >On Sun, Jan 02, 2000 at 04:55:44PM +0100, Poul-Henning Kamp wrote: >> >> >BTW, speaking of which, does anyone know of a reasonably-cheap GPS receiver >> >that (1) has an external-able antenna that will work with somewhere between >> >50 and 100 feet of lead, and (2) has the appropriate pps outputs and such >> >so it can be used for this? >> >> I will (as always) recommend the Motorola Oncore UT+. If you buy it >> from syngergy-gps it comes mounted in their nice box and the cable >> has the PPS on DCD and is ready to plug into a serial port. I paid >> $605.73 for the one I'm delivering to the Danish Internet eXchange >> point, that included antenna and 15m of cable. > >That's EXPENSIVE. > >Common handheld GPS units with NEMA outputs on them are well under $200 >these days! Common handheld GPS units are pointless as NTP refclocks because they lack (a decent) PPS output. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >Why spend twice what Mr. Schwartz seems to want to charge? > >For the Motorola name? Sorry, the Batwing Menace to employee's rights was >long ago placed on my "do not buy, do not recommend, actively boycott" list. Well, suit your own political manifests as you will, but the Motorola unit is the best time receiver you can buy for humane amounts of money. You can see some of my measurements at http://phk.freebsd.dk -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >On Sun, Jan 02, 2000 at 11:17:00PM +0100, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Karl Denninger writes: >> >> >Why spend twice what Mr. Schwartz seems to want to charge? >> >> Well, suit your own political manifests as you will, but the Motorola >> unit is the best time receiver you can buy for humane amounts of money. >> >> You can see some of my measurements at http://phk.freebsd.dk > >Yeah, so what? > >Your system can't resolve events to that degree of accuracy, so the ability >of the receiver to deliver them is irrelavent. Karl, In fact I *do* have a computer that can resolve events to +/- 10nsec (http://gps.freebsd.dk) so I need it. In fact that machine is probably one of the best NTP servers in the entire world right now. >More geek nonsense - about what I expected. Call it "geek nonsense" if you want to. Warner is employed by the company that builds the stuff which figures out what time it is for NIST and although my professional affiliation isn't anywhere near that level, I can claim to be the first person to truly split the microsecond with a standard UNIX box. Listen, it is really too bad that you didn't get that pony for X-mas, and I can understand you why you are disappointed about it, but when do you plan to stop being grumpy about it ? :-) If you intend to keep up this "sour grapes" attitude, despite all the helpful answers you have gotten so far, you should consider stopping before you have worn out your welcome. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >On Sun, Jan 02, 2000 at 03:32:00PM -0700, Warner Losh wrote: >> In message <[EMAIL PROTECTED]> Karl Denninger writes: >> : Why spend twice what Mr. Schwartz seems to want to charge? >> >> Because we need a PPS that is < 10nS from the true start of second for >> our application? 1uS is really really bad for the timing geeks in the >> audience. >> >> Warner > >And on what hardware do you think you can obtain 10ns resolution RELIABLY >at the software level in the Unix environment and under FreeBSD? > >Answer: NONE! > >The actual usable resolution of a timing source is determined by the >maximum slop in ANY part of the complete system. > >I challenge you to get actual REPEATABLE 10ns results while a multi-tasking >anything is running on the recipient of that data. What rides on this challenge ? What is the prize ? I would use some cash, and this will be like picking cherries... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: > >Yes, you have HARDWARE timers that do that. > >So what? I have a commercially available PCI card which costs about the same as a good diskdrive... >I'm talking about TIME SERVERS on UNIX machines. > >You know, ntpd and friends? Yes, that. Yes, exactly. Suggest you poke gps.freebsd.dk a bit and see what performance it shows. >I'm simply not interested in [...] Karl, I'm simply not interested in continuing to listen to your belly aching. Unless you all of sudden develop something constructive to say, you will see this as my last reply. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rlogin from 3.X to 4.0 problem...
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes: >With the 991229 shapshot, from a FreeBSD 3.3 or 3.4 machine: > > > rlogin bsd4 > assword:hey this is great! > >why is the initial 'P' missing, and the password echoed ? Bug in /etc/pam.conf I belive markm is on the case. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
In message <[EMAIL PROTECTED]>, Steve Ames writes:
>> On the other hand, there are *plenty* of things already in 4.0 that really
>> need to get out there and get a workout by a larger audience.
>> Delaying *them* is a big mistake.
>
>*shudder* I really, really dislike the idea of -RELEASE actually being a
>wide beta so that some code can get a workout.
Who said anything about -RELEASE being a beta ? Some parts of a release
will always be new, but the majority of it is the same code we released
as 3.X, 2.X and even 1.X.
We need for people to stop thinking of FreeBSD as commercial software
which comes in "natural number" style enumerable packets.
FreeBSD style is "real number", it is a continuously evolving
quantity which every now and then passes a natural number on the
way to infinity.
We can now spot a milestone called 4.0 and that's very nice, but we
are not going to stop, because the road goes on past 4.0.
I'm sorry you you can't have ${insert pet feature here} in 4.0 if
it is not ready yet. That's too bad, check in later.
In the meantime please enjoy:
NTFS filesytem
Netware support
Jail facility
Tons of new device drivers
Netgraph
etc, etc
Isn't that just that very incomplete list worth a release ?
FreeBSD-4.0 because now the time is right!
Poul-Henning
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: So, tell me again why we can't read audio CDs in SCSI drives?
In message <[EMAIL PROTECTED]>, Matthe w Jacob writes: > >Hmm! Better hold the 4.0 Code Freeze until this sorts out! "No" -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes:
>> One of the things I would do to optimize ipfw is:
>> - instead of keeping one list with all the rules, split the list (the
>> internal one) by interface and by direction (one list for ed1 incoming,
>> one list for ed1 outgoing, etc.).
>
>one skipto rule is enough to switch between two rulesets depending
>on direction, so this is not really worthwhile.
>I agree that having a `switch' type of rule for selecting interfaces
>would be a reasonable gain of efficiency (but then again.. how
>many interfaces is one using!)
I still think we should split the current "one huge list of rules"
into several lists:
Two lists per interface:
one list of rules for inbound packets
one list of rules for outbound packets
Two lists for the IP stack:
one list of rules for incoming packets
one list of rules for outgoing packets
One list for forwarding of packets.
in theory one could also:
Two lists for the UDP stack:
one list of rules for incoming packets
one list of rules for outgoing packets
Two lists for the TCP stack:
one list of rules for incoming packets
one list of rules for outgoing packets
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes: >> I still think we should split the current "one huge list of rules" >> into several lists: > >> Two lists per interface: >> one list of rules for inbound packets >> one list of rules for outbound packets >> >> Two lists for the IP stack: >> one list of rules for incoming packets >> one list of rules for outgoing packets >> >> One list for forwarding of packets. > >aren't these three classes combined in some H-shaped way ? Could be, the forwarding branch could be a good place to hook up natd(8) for instance... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
:
>handle packets as they traverse ip_forward? I know Poul's or someone
>elses drawing of the H style firewall could be implemented if we had
>a way to apply rules as they traverse the ip_forward code and an easy
>way to expand your scheme to include that would be to add something
>like ``via fwd, in via fwd, out via fwd''. Note that I _think_ but
>am not certain that NAT tapping/injection occurs in ip_forward so this
>could be of benefit to those doing NAT.
I think the general syntax would be if you could say "for one of my
own IP#" that would be very powerful:
add allow tcp from any to me 22
add deny tcp from any to not me 22
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes: >> I think the general syntax would be if you could say "for one of my >> own IP#" that would be very powerful: >> >> add allow tcp from any to me 22 >> add deny tcp from any to not me 22 > >the 'me' thing is relatively simple to implement, it suffices to scan >the list of IP associated with all interfaces. Can be time-consuming. But less so that having one ipfw rule for each interface :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: load spike strangeness
In message <[EMAIL PROTECTED]>, "FreeBSD" writes: >> As Sherlock Holmes once said: ``It is always unpleasant dealing with >> an alias.'' > >Mr. Holmes was a fictional character written in a time where there wasn't an >internet. It's my belief that if he were real, and in our day and age, he >would also take care in revealing to the mass public his true identity. I think you are not only obnoxius, you are also dead wrong. Sherlock Holmes was *by principle* against anononymity. Anyway, into the mail-filter you go... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
In message <[EMAIL PROTECTED] >, Christian Carstensen writes: >On Mon, 10 Jan 2000, Joao Pedras wrote: > >> What I have in common with Christian is that it hangs >> during high usage, as I mentioned in my first post (e.g. >> compiling something, buildworld). > >this is funny: >the system operates well, even when on heavy load (especially disk load), >until i want a little more 8). I have a make world hanging here: 0 19914 19902 169 -2 0 1276 932 getblk D+p10:00.09 yacc -d -o c-parse.c c-parse.y -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current hangs in make world (softupdates on ccd on ata)
Make world hangs reliably for me right now: + |... |/* starting time is 16:18:8 */ |/* ending time is 16:18:8 */ |ln -sf gxx-hash.h hash.h |echo '#include "cp/cp-tree.def"'> gencheck.h |echo '#include "objc/objc-tree.def"'>> gencheck.h |sed -e "/^ifobjc$/,/^end ifobjc$/d" -e "/^ifc$/d" -e "/^end ifc$/d" |/syv/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c-parse.in > c-parse.y |yacc -d -o c-parse.c c-parse.y + 0 19921 1 83 -2 0 1276 932 getblk D p00:00.09 yacc -d -o c-parse.c c-parse.y This is a softupdates filesystem on a ccd on ata... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing... update to 1.45 of ffs_softdep.c
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >I would like to know if the person reporting the getblk lockup (I think >it was Poul) sees that problem solved with the vinum fix that Alfred >posted in regards to or whether we still have an open issue. I don't use vinum and -current as cvsup'ed right now has the problem. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing... update to 1.45 of ffs_softdep.c
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >If so, if either you or Poul could backoff to the wd driver and see >if the problem continues, I would appreciate it. I disabled softupdates and the problem went away. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
boot messages for pci devices...
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 ? 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. Or maybe we should always make the resource allocations bootverbose stuff now ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: boot messages for pci devices...
In message <[EMAIL PROTECTED]>, Matthew Jacob writes: > > >> On Wed, Jan 19, 2000 at 12:28:09AM +0100, Poul-Henning Kamp wrote: >> > fxp0: port 0xc400-0xc43f mem >0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0 >> >> Agreed. For a PCI card all I want to know is what it is, and what IRQ it >> was assigned. A single line should be suffient. > >Do you even need to know what IRQ it was assigned? It seems to me that IRQ, >like IO-PORT, is only needed if you're either interested in such stuff or to >catch conflicts (both are under bootverbose) The IRQ is useful to me at least, since the ISA/PCI irq distribution is rather hackish and non-trivial to get right at times. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still getting 'R/W mount of / denied ...' after valid fsck
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>I am still getting 'R/W mount of / denied' failures when rebooting a
>crashed -current machine. It thinks / is dirty but the fsck on it ran
>just fine. If I immediately /sbin/reboot again the machine comes up
>normally.
fsck fails to remount and fails to tell that, so despite the fact
that the fs on the disk is clean the kernel doesn't get told.
I belive Paul Saab is working on some improvements to fsck which
will help this...
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS /usr/src and /usr/obj?
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >I'm wondering how one can do a buildworld on a machine, and then NFS >mount /usr/src and /usr/obj on a client machine and do an installworld >of the freshly built sources? I've been looking in the archives without >much success, and haven't figured it out by reading the makefiles yet. >Can anyone shed some light on this? I've done it in the past, but not recently. Consider the alternative of mounting the destination on the compilehost and make install DESTDIR=/mnt -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS /usr/src and /usr/obj?
In message <[EMAIL PROTECTED]>, Leif Neland writes: > > >On Wed, 26 Jan 2000, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, >[EMAIL PROTECTED] writes: >> >I'm wondering how one can do a buildworld on a machine, and then NFS >> >mount /usr/src and /usr/obj on a client machine and do an installworld >> >of the freshly built sources? I've been looking in the archives without >> >much success, and haven't figured it out by reading the makefiles yet. >> >Can anyone shed some light on this? >> >> I've done it in the past, but not recently. >> >> Consider the alternative of mounting the destination on the compilehost >> and make install DESTDIR=/mnt >> > >A: What's the advantage? That your server mounts the clients, not the other way around (security etc) >B: What do I mount? The root of the destination? All relevant filesystems of the destination, ie: /, /var, /usr -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installworld broken???
You need to manually recompile and install your "install" command. It's source-dir is called "xinstall" btw. Poul-Henning In message <[EMAIL PROTECTED]>, bush doctor writes: >I'm seeing the following failure on my -current box with sources cvsupped last >night about 11:30 est. > >===> bin/ps >install -C -c -s -o root -g wheel -m 555 ps /bin >install -C -c -o root -g wheel -m 444 ps.1.gz /usr/share/man/man1 >===> bin/pwd >install -C -c -s -o root -g wheel -m 555 pwd /bin >install -C -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1 >===> bin/rcp >install -C -c -s -o root -g wheel -m 4555 -fschg rcp /bin >/usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" >*** Error code 1 > >Stop in /usr/src/bin/rcp. >*** Error code 1 > >Stop in /usr/src/bin. >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. > >#;^) >-- >So ya want ta hear da roots? >bush doctor <[EMAIL PROTECTED]> > Of course I run FreeBSD!! > http://www.freebsd.org/ > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious problems installing -CURRENT (was: UPDATING)
In message <[EMAIL PROTECTED]>, Peter Jeremy writes: >On 2000-Feb-03 20:11:57 +1100, Bruce Evans <[EMAIL PROTECTED]> wrote: >> ntp is >>doing well if it falls back to another method after the syscalls fail. > >ntpd iterates (at runtime) through all the possible scheduling >mechanisms that were enabled at compile time, until one works. These >are (in order) SetPriorityClass() (LoseNT only), sched_setscheduler(), >rtprio(), nice(), setpriority(). If all these fail, it will log a >message that it couldn't improve it's priority - in which case it will >still function, but probably won't be as accurate. (ntpd is probably >a special case, in that the P1003.1b functions aren't essential to it, >they just improve its operation). Actually none of this seems to have much effect on it's performance since we timestamp packets in the kernel on input and the chances of being preempted between constructing the output packet and sending it is epsilon. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with openssl in 4.0rc and ports/security/openssh
In message <[EMAIL PROTECTED]>, "Jordan K. Hubbard" writes: >> Are there any plan to distribute USA_RESIDENT=NO version of >> des binary distribution? > >I have no current plans to build such a thing and am USA_RESIDENT >myself so it would be a questionable thing from a legal standpoint, I >think. I can hardly wait until September when the RSA patent expires! :) Could somebody send a short overview of the "crypto in FreeBSD" situation ? I bet there are more people than me who have lost track of what is in, what is out and what USA_RESIDENT changes... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: timed/adjtime() on -current
In message <[EMAIL PROTECTED]>, Ben Smithurs t writes: >[sorry about the crosspost - I'm not sure if this is me being a dumbass, >or something wrong with adjtime() on current. adjtime() certainly >behaves as I expect it to on stable.] You're right, I used the wrong sign last I mucked about with this, I'll fix this. Anyway: Don't used timed, use ntpd. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssh uses /etc (bad)
In message <[EMAIL PROTECTED]>, Ollivier Robert write s: >I just saw that openssh (thanks Mark!) is using /etc/ for its configuration >file. As the author of the "--with-etcdir" option of SSH (back in '96) and >for the sake of consistency, I'd like to create a /etc/ssh directory and >move everything there. yes -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Streamlining FreeBSD installations across many machines
In message <[EMAIL PROTECTED]>, Forrest Aldrich writes : >Perhaps this would be of interest in CURRENT issues: > > >We have several servers that we plan on deploying across the US. Their >purpose in life is network status and monitoring. The hardware profiles >are exactly the same... > >Currently, we're using DD to mirror a disk image onto a new installation, >and them nanually tweaking all the necessary configurations. It's >tedious, and is going to get hellish with the amount we plan on deploying. There was actually a good deal of interest in this at FreeBSDcon'99, and I belive we managed to bully^H^H^H^H^H^Hpersuade Wes Peters to take an active role in coordinating efforts in this area ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bad blocks
In message <[EMAIL PROTECTED]>, kibbet writes: >This message is in MIME format >--_=XFMail.1.3.p0.FreeBSD:000227023903:2009=_ >Content-Type: text/plain; charset=us-ascii > >Hi all, > >Quick question, how does the new ata driver handle bad blocks? >I've been tracking -current since around Nov 99 but haven't >seen this come up. It doesn't. The drives have to handle bad blocks now. If you have a drive where bad144 remapping is enabled, try to find out if any sectors have been remapped, if not you can simply turn off bad144. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UDF/DVD support
In message <[EMAIL PROTECTED]>, Soren Schmidt writes: >It seems Julian Elischer wrote: >> I have been hired to add UDF/DVD-R support to FreeBSD >> I will be spending the next few weeks basically doing research >> but would like to hear from anyone who is already working in these >> areas. >> >> This may impact un the following areas: >> SCSI subsystem >> ATA subsystem >> Filesystems >> Raw/Block(sic) device interface >> Encryption/security stuff. > >Concentrate on the UDF stuff, all the rest is there, or will be shortly. Yes I agree, and please put the UDF filesystem under sys/fs/udf, we're trying to get a bit more clean top-level /sys -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repost of procfs crashes in -CURRENT (no html)..
The real solution is to make killall(1)s funtionality part of kill(1) and avoid reading /proc so that we don't even have to mount /proc. Poul-Henning In message <[EMAIL PROTECTED]>, Thomas Stromberg writes: >3 users. One with X running , and two users running breakwidgets >, which make use of a minimized version of the >"killall" perl script which reads procfs. > >This crash appears to be the old one where when two processes read procfs >simultaneously, ugly things can happen. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssl in -current
In message <[EMAIL PROTECTED]>, "Jordan K. Hubbard" writes: >Hmmm. I'm beginning to wonder if openssl shouldn't just be backed-out >at this point. The situation with RSA makes this far more problematic >than I think anyone first thought, and I've seen a lot of breakage so >far for what appears to be comparatively little gain over what we had >before with the ports collection version. > >- Jordan I agree. It's not that hard to install a port. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org (FTP)
In message <[EMAIL PROTECTED]>, Kevin Day writes: > >Here's what I see: > ># ftp current.freebsd.org >Connected to usw2.freebsd.org. >220 usw2.freebsd.org FTP server (Version wu-2.6.0(1) Tue Jan 25 00:05:38 CST 2000) >ready. >Name (current.freebsd.org:toasty): ftp >331 Guest login ok, send your complete e-mail address as password. >Password: >530 Login incorrect. >ftp: Login failed. That usually means that Jordan has left the country and isn't reachable for at least a week... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
