Re: ipfilter and ipfstat
On Tue, Jan 25, 2000 at 09:23:23PM -0800, Kris Kennaway wrote: > On Tue, 25 Jan 2000, the Webslave wrote: > > > > Okay, so I finally decided to take the plunge and check out ipfilter. ipf > > > seemed to load my ruleset with no problems, but ipfstat dies with: > > > > > > ioctl(SIOCGETFS): Invalid argument > > > > And what would that ruleset be? > > > > # Default to deny > block in log on tun0 from any to any [snip] I have tested your ruleset in my ipf/ipfstat version. The one I have comes from the 4.0-2124-CURRENT snapshot, since I haven't had the time to cvsup/make-world since. The results of the tests are shown below, and as you can see ipfstat reports the rules correctly. hades# ipf -FA hades# cd /tmp hades# ipf -f ipf.conf hades# ipfstat -nio @1 pass out quick on tun0 proto tcp/udp from any to any keep state @2 pass out quick on tun0 proto icmp from any to any keep state @3 pass out quick on lo0 from any to any @1 block in log on tun0 from any to any @2 block in quick on tun0 from 192.168.0.0/16 to any @3 block in quick on tun0 from 172.16.0.0/12 to any @4 block in quick on tun0 from 10.0.0.0/8 to any @5 block in quick on tun0 from 127.0.0.0/8 to any @6 pass in quick on tun0 proto tcp from any to any port = 12345 flags S/FSRPAU keep state keep frags @7 pass in quick on tun0 proto udp from any to any port = 31337 keep state @8 pass in quick on lo0 from any to any hades# ipf -FA hades# ipf -f /etc/ipf.conf What version of ipfilter/ipfstat are you using? I don't now if cvsup'ing your sources to a more recent version might help at all, but I don't see a problem with these rules and ipfstat... I'm sorry if that is not of any help to you, but I can't seem to find anything wrong here :/ -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > "Don't let your schooling interfere with your education." [Mark Twain] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems installing FreeBSD 4.0 20000125-CURRENT
On Thu, Jan 27, 2000 at 06:53:51PM -0800, Mike Smith wrote: > > The only argument for having a dysfunctional hostname of the variety you > describe is vanity, which is not a valid engineering constraint. Or that you're behind a dialup connection that dynamically assigns IPs. -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > "Don't let your schooling interfere with your education." [Mark Twain] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "rm -rf" behavior on readonly nfs
On Sun, Jan 30, 2000 at 09:06:33AM +0900, Jun Kuriyama wrote:
>
> I found difference between "rm -rf" for non-exist file on readonly nfs
> and usual non-writable directory.
>
> In this example, /usr/src is readonly nfs mounted and /usr/bin is
> normal filesystem but not writable. And file "a" is not exist.
>
> -
> % rm /usr/bin/a
> rm: /usr/bin/a: No such file or directory
> % rm -f /usr/bin/a
> % rm -rf /usr/bin/a
> % rm /usr/src/a
> rm: /usr/src/a: No such file or directory
> % rm -f /usr/src/a
> % rm -rf /usr/src/a
> rm: /usr/src/a: Read-only file system
> %
> -
>
> For "-f" option, last behavior is expected one, or not?
This happens on either NFS-mounted or real directories. It think that since
the manual of rm(1) says:
-f Attempt to remove the files without prompting for confirma-
tion, regardless of the file's permissions. If the file does
not exist, do not display a diagnostic message or modify the
exit status to reflect an error.
it ought to print nothing in such a case. Let me know if the small patch
shown below helps in correcting this. I can't check this cause I got bitten
by getflags() in(s)anity last night when I cvsup'ed.
The diff -u output is:
%%% patch begins here %%%
--- /usr/src/bin/rm/rm.cSat Jan 29 01:14:23 2000
+++ rm.cSun Jan 30 09:32:18 2000
@@ -196,7 +196,9 @@
}
continue;
case FTS_ERR:
- errx(1, "%s: %s", p->fts_path, strerror(p->fts_errno));
+ if (!fflag)
+ errx(1, "%s: %s", p->fts_path,
+strerror(p->fts_errno));
case FTS_NS:
/*
* FTS_NS: assume that if can't stat the file, it
%%% patch ends here %%%
--
Giorgos Keramidas, < keramida @ ceid . upatras . gr >
"Don't let your schooling interfere with your education." [Mark Twain]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: IP-Filter w/FreeBSD-current
Cy Schubert - ITSD Open Systems Group <[EMAIL PROTECTED]> writes: > With the impending release of FreeBSD-4.0, is anyone on this list using > IP-Filter on FreeBSD-current? I'm planning to install -current > w/IP-Filter on a testbed and would like to know of there are any > gotchas or if it even runs on FreeBSD-current. I've been using ipfilter with -current since 24 Jan 2000, and this night I'm running my buildworld with cvsup'ed sources. With user PPP on tun0 and kernel PPP on ppp0 there seem to be no problems, so far. If something comes up after tonight's build, I'll let you know. -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > For my public PGP key: finger [EMAIL PROTECTED] PGP fingerprint, phone and address in the headers of this message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP-Filter w/FreeBSD-current
[Cc'ed to freebsd-current : I earnestly hope you don't mind Arjan] On Tue, Feb 01, 2000 at 10:25:46PM +0100, Arjan de Vet wrote: > > I'm current using a -current of Jan 22. > > >With user PPP on tun0 and kernel PPP on ppp0 there seem to be no > >problems, so far. If something comes up after tonight's build, I'll let > >you know. > > I just described in another mail to this thread the symptoms I am seeing > with tun0 and ipfilter. It would be interesting to see whether you could > reproduce the symptoms. I saw your mail Arjan. This is what made me try tun0 with ipfilter, since I'm normally using kernel ppp. Ok, I'm still using the "world" I built today from sources cvsup'ed last night (Jan 31 2000). I tried to change the rules to use tun0 instead of ppp0, and fired up user-ppp manually a few minutes ago. The rules I use with ipfilter start with: % cat /etc/ipf.conf # The rule groups: pass in on ppp0 all head 10 pass out on ppp0 all head 20 pass in all ... The only change I had to make to test tun0 was to change ppp0 in the two first head-lines to tun0. Trying to reproduce what you saw Arjan, I loaded the rules with `ipf -FA ; ipf -f ipf.conf' before I started user-ppp. The rules were just there, waiting. Dialed in and waited a few minutes to see if anything weird happens. In the meantime, fetchmail woke up and fetched a few mail without a problem. I visited a few web pages to see if it breaks while I'm surfing... The rules are still loaded now that I'm writing. The output of ipfstat (minus some uninteresting rules for filtering 127.0.0.0/8 coming from tun0, etc) looks like: # ipfstat -hnio | grep -v ^0 139 @1 pass out on tun0 from any to any head 20 83 @1 pass in on tun0 from any to any head 10 385 @2 pass in from any to any I'm using ppp0 all the time, I just wanted to see if anything strange happens when switching to tun0. Since it seems to work for me, what is it that you have observed Arjan? The rules never get hit? The rules get hit, but they do not work as expected? -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > For my public PGP key: finger [EMAIL PROTECTED] PGP fingerprint, phone and address in the headers of this message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top and ps as of today...
On Tue, Feb 08, 2000 at 01:16:14PM -0600, Raul Zighelboim wrote: > ps: > root@rodia> ps > PID TT STAT TIME COMMAND > 311 p1 IN+0:00.05 su (M-@^A) I've seen ps(1) output similar to this when my kernel and `world' versions were not compiled from the same sources. A build/installworld solved this for me. -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > For my public PGP key: finger [EMAIL PROTECTED] PGP fingerprint, phone and address in the headers of this message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dummy ethernet interface.
Is there some way to ifconfig up a dummy ethernet interface, one that will work like the loopback one (lo0) on FreeBSD? I'm playing around with a local caching named on a machine that has only lo0 and a ppp0 interface, and bind always replies with 'for authoritative replies ... blah blah' when I use host. I remember that having localhost.my.domain set to 127.0.0.1 and the reverse, but my (fictitious) hades.hell.gr -> 10.0.0.1 seemed to solve this problem on linux. I looked through the LINT file in my sources [cvsuped: 7 Jan 2000], but could not find anything like that. Is there such a thing, or the time has come for me to start playing around with my kernel and ethernet drivers? A pseudo-ethernet device seems like a nice reason to start panicing my home PC, but I don't want to repeat other people's work if possible ;) -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > For my public PGP key: finger [EMAIL PROTECTED] PGP fingerprint, phone and address in the headers of this message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dummy ethernet interface.
On Fri, Feb 11, 2000 at 03:24:15PM +0100, Alexander Leidinger wrote:
> On 10 Feb, Archie Cobbs wrote:
>
> > If you want an interface that discards everthing, you can create
> > a netgraph interface ("ngctl mkpeer iface foo inet") and leave it
> > unconnected.
>
> Or just add "pseude-device disc" to your kernel.
I know, I tried adding disc0, and lo1. But it seems that the *real*
problem with my named answering that he's not authoritative for his own
domains is elsewhere.
Thanks everyone for replying. I have found in the mean time that disc0
can be used for an interface that discards packets, and that one can
have as many loopback interfaces as needed [although I suspect that one
would suffice most of the time].
--
Giorgos Keramidas, < keramida @ ceid . upatras . gr >
For my public PGP key: finger [EMAIL PROTECTED]
PGP fingerprint, phone and address in the headers of this message.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 release candidate issues
On Tue, Feb 15, 2000 at 04:10:59PM -0800, Doug Barton wrote: > On Tue, 15 Feb 2000, Kazutaka YOKOTA wrote: > > > `options XSERVER' is for vt0 only. sc0 doesn't need it to run the X > > server. > > Could you add appropriate comments to this effect in GENERIC and > LINT? I have always been confused by this, and IMO the placement in the > file is not sufficient to make it clear. For instance: > > -#options XSERVER # support for X server > +#options XSERVER # support for X server on a vt > console Nice thing. I think this will stop a lot of questions on their source. Some new users believed that running XF86Config was unnecessary after they added this to their kernel. Without the wrapping, thank you. -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > For my public PGP key: finger [EMAIL PROTECTED] PGP fingerprint, phone and address in the headers of this message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAX_UID ?
On Sun, Mar 12, 2000 at 05:59:09AM +, Paul Richards wrote: > > Are expressions like ((uid_t)0-1) portable/safe ? Maybe that's a better > way of approaching this. To get the all-1's number, maybe it's better to use ((uid_t)~0), but that is a rather controversial topic anyway. - Giorgos Keramidas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAX_UID ?
On Sun, Mar 12, 2000 at 05:51:17PM -0800, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > > On Sun, Mar 12, 2000 at 05:59:09AM +, Paul Richards wrote: > > > > > > Are expressions like ((uid_t)0-1) portable/safe ? Maybe that's a better > > > way of approaching this. > > > > To get the all-1's number, maybe it's better to use ((uid_t)~0), but > > that is a rather controversial topic anyway. > > That works, but on machines like the Alpha where longs are bigger > than ints it only works by virtue of sign extension. Our existing > headers seem to prefer ((uid_t)0-1). That's what is used in the > i386's . My bummer, I thought the definition was the same in /sys/sys/types.h and in /usr/include/sys/types.h -- and there I could see: % cd /sys ; grep uid sys/* | grep type sys/conf.h:typedef void devfs_create_t __P((dev_t dev, uid_t uid... sys/types.h:typedef u_int32_t uid_t; /* user id */ % cd /usr/include ; grep uid sys/* | grep type sys/conf.h:typedef void devfs_create_t __P((dev_t dev, uid_t uid... sys/types.h:typedef u_int32_t uid_t; /* user id */ and I mistakenly assumed that both x86 and alpha's use uid_t's of 32 bits. What did I miss? - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buffer troubles, and machine hangs?
On Sun, Mar 12, 2000 at 03:13:20PM -0500, Howard Leadmon wrote: > > Hello, > > I am getting the following errors out of FreeBSD 4.0-CURRENT trying to > run an IRC server, and was wondering if anyone had any ideas or recommended > tunables I should set?? > > > Mar 9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for >[@163.152.216.46]:No buffer space available > Mar 9 22:32:03 u /usr/ircd/undernet/ircd[154]: Unable to create auth socket for >[@208.164.193.201]:No buffer space available > Mar 9 22:33:00 u syslogd: sendto: No buffer space available You can probably get away with increasing NMBCLUSTERS. > I have actually been fighting a problem with this machine locking up, > and requiring a hard reset, and this is the only type errors I am > actually seeing in the messages file. But lockups are certainly not a good thing, IMHO. If you can debug the kernel, and see where it locks up, perhaps someone with more knowledge of the kernel internals than me will be able to help you sort this out. - Giorgos Keramidas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAX_UID ?
On Mon, Mar 13, 2000 at 05:28:47PM +1100, Bruce Evans wrote: ... > > I would prefer standard maxof() and minof() interfaces that work on > any arithmetic type. These can almost be written in portable C, at > least in C89 where types are restricted to char, signed char, ..., > long double: > > #define isfloat(type) ((type)0.5 != 0) > #define issigned(type)((type)-1 < 0) > #define isschar(type) (!isfloat(type) && issigned(type) && sizeof(type) == 1) > #define isuchar(type) (!isfloat(type) && !issigned(type) && sizeof(type) == 1) > ... > #define maxof(type) ((type)(isschar(type) ? SCHAR_MAX : > isuchar(type) ? UCHAR_MAX ...)) This is marvellous in it's simplicity of interface. Yet, using sizeof(char) and assuming that it's going to be 1, strikes me like a dangerous thing to do. I have never heard of machines where this isn't true, but I seem to recall that the comp.lang.c FAQ mentions this somewhere. I'll look it up tomorrow, since it's getting too late.. - Giorgos Keramidas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Not actually (Was Re: crash in atkbd_isa_intr() )
On Wed, Mar 22, 2000 at 01:52:46PM -0800, Mike Smith wrote: > > > > The kernel apparently stopped in atkbd_isa_intr(). > > No, that's where it went when you hit alt-ctrl-esc. Yes, I did, to get into the debugger. Now I wonder, if there is some other bug that I need to chase around, how should I proceed? Hitting alt-ctrl-esc makes the atkbd_* routines take over, and I don't get a chance to see why the system freezes :/ > This is just you breaking into the debugger, followed by what looks > like a 'panic' command. It *is* a panic command, but it seems that apart from cvsup'ing my sources tonight to their older revision (march 16) and rebuilding kernel+world, I don't have much more information for the crash. Be back to you with more info, after I roll back my sources to some older date and see which is the first version that makes my system stop coldly. - Giorgos Keramidas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Not actually (Was Re: crash in atkbd_isa_intr() )
On Wed, Mar 22, 2000 at 02:08:42PM -0800, Mike Smith wrote: > > > Yes, I did, to get into the debugger. Now I wonder, if there is > > some other bug that I need to chase around, how should I proceed? > > You can try looking at the stack further above the atkbd interrupt, > since that's where it was running when it took the interrupt. If > there's nothing there, then it was running in userspace and you might > want to try the 'ps' command. There is no frame above #12, which means that the problem is probably not in atkbd_isa_intr() after all, but I can not the system to respond after it stops. I'll try and run `ps' in ddd and see if I can get the output written down somewhere. In the mean time, I've recompiled a freshly cvsup'ed kernel, booted it, and now I'm trying to build my world -- since it seems that compiling the kernel and/or `world' triggers the funny condition I'm running into. If that does not give me a working kernel/world, I might as well start looking for hardware related problems, memory being the most likely culprit for such kind of behavior. - Giorgos Keramidas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problem solved. (was: Re: Not actually)
On Thu, Mar 23, 2000 at 01:33:11AM +0200, Giorgos Keramidas wrote: > > In the mean time, I've recompiled a freshly cvsup'ed kernel, booted it, > and now I'm trying to build my world -- since it seems that compiling > the kernel and/or `world' triggers the funny condition I'm running into. I rebuilt kernel with sources cvsup'ed early this morning [Friday], this time enabling INVARIANTS. I built my world and installed it fine, so I think that whatever it was, it's gone now. Seems I was cvsup'ing while changes were being done on the repository. - Giorgos Keramidas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/dev/acd0 related crash?
I built from sources cvsup'ed about 24 hours ago, my kernel and world,
this afternoon. After enabling INVARIANTS and INVARIANT_SUPPORT, I
booted and tried a lot of things. Nothing seemed to make the new kernel
I had (and it's own modules + world) go crazy ;)
However, when I tried to run cdcontrol on my ATAPI cdrom, the kernel
paniced and instantly rebooted. The related kgdb output for the crash
dump is attached.
My kernel version is:
FreeBSD hades.hell.gr 5.0-CURRENT FreeBSD 5.0-CURRENT #0:
Thu Mar 23 04:43:04 EET 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/HADES i386
Seems that it crashed in acdopen(). My version of atapi-cd.c is 1.52.
- Giorgos Keramidas
# gdb -k kernel.debug /var/crash/vmcore.6
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 2973696
initial pcb at 263ca0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01c8c78
stack pointer = 0x10:0xc55add88
frame pointer = 0x10:0xc55add94
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 299 (cdcontrol)
interrupt mask = none
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01c8c78
stack pointer = 0x10:0xc55add88
frame pointer = 0x10:0xc55add94
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 299 (cdcontrol)
interrupt mask = none
panic: from debugger
panic: from debugger
Uptime: 7m59s
dumping to dev #ad/0x20001, offset 65536
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc01367a5 in panic (fmt=0xc0222e0f "page fault")
at ../../kern/kern_shutdown.c:554
#2 0xc01ed71a in trap_fatal (frame=0xc55f3d48, eva=0)
at ../../i386/i386/trap.c:924
#3 0xc01ed3cd in trap_pfault (frame=0xc55f3d48, usermode=0, eva=0)
at ../../i386/i386/trap.c:817
#4 0xc01ecf53 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 1,
tf_esi = -1057903872, tf_ebp = -983614060, tf_isp = -983614092,
tf_ebx = -1057896448, tf_edx = 1, tf_ecx = -983626240, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1071864696, tf_cs = 8,
tf_eflags = 66118, tf_esp = -983330496, tf_ss = -1057903872})
at ../../i386/i386/trap.c:423
#5 0xc01ca488 in acdopen (dev=0xc0f1ab00, flags=1, fmt=8192, p=0xc55f0e00)
at ../../dev/ata/atapi-cd.c:497
#6 0xc016cd6d in spec_open (ap=0xc55f3e10)
at ../../miscfs/specfs/spec_vnops.c:191
#7 0xc016cc6d in spec_vnoperate (ap=0xc55f3e10)
at ../../miscfs/specfs/spec_vnops.c:117
#8 0xc01a2b21 in ufs_vnoperatespec (ap=0xc55f3e10)
at ../../ufs/ufs/ufs_vnops.c:2301
#9 0xc016773b in vn_open (ndp=0xc55f3edc, fmode=1, cmode=1197)
at vnode_if.h:189
#10 0xc01636d1 in open (p=0xc55f0e00, uap=0xc55f3f80)
at ../../kern/vfs_syscalls.c:994
#11 0xc01ed952 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 1, tf_esi = -1, tf_ebp = -1077937768, tf_isp = -983613484,
tf_ebx = -1077938792, tf_edx = 10, tf_ecx = -1077938928, tf_eax = 5,
tf_trapno = 12, tf_err = 2, tf_eip = 672262868, tf_cs = 31,
tf_eflags = 647, tf_esp = -1077938836, tf_ss = 47})
at ../../i386/i386/trap.c:1073
#12 0xc01e1846 in Xint0x80_syscall ()
#13 0x80491ea in ?? ()
#14 0x8048e9d in ?? ()
#15 0x8048b6d in ?? ()
(kgdb) f 11
#11 0xc01ed952 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 1, tf_esi = -1, tf_ebp = -1077937768, tf_isp = -983613484,
tf_ebx = -1077938792, tf_edx = 10, tf_ecx = -1077938928, tf_eax = 5,
tf_trapno = 12, tf_err = 2, tf_eip = 672262868, tf_cs = 31,
tf_eflags = 647, tf_esp = -1077938836, tf_ss = 47})
at ../../i386/i386/trap.c:1073
1073error = (*callp->sy_call)(p, args);
(kgdb) list 1000
995 if (rv != KERN_SUCCESS)
996 return 1;
997
998 return (0);
999 }
10
crash in atkbd_isa_intr()
I CVSup'ed 5.0 sources yesterday, and built my kernel this afternoon.
The kernel built find, and I booted with the new kernel. The uname
output is:
FreeBSD hades.hell.gr 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 22
17:04:49 EET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/HADES i386
When I tried to 'make buildworld' though, the kernel froze while
compiling openssl. I thought it might be openssl triggering a bug in
gcc, for a while, and tried building world a couple of times, but the
system froze in different places; the kgdb information is shown below.
The kernel apparently stopped in atkbd_isa_intr(). I don't know if it
has any relation to the processing of interrupts, but after the system
freezes, and I boot, the hard disk seems to do some form of hard reset,
as if it was stopped for power-saving or something...
I'll try CVSup'ing once more today, and see if the new kernel stops
frozen too, but since this does not happen with the kernel I've kept as
my /kernel.safe (compiled from sources cvsup'ed on march 16), uhm,
I don't know.. is there something strange going on with atkbd?
I've seen commits on March 18th from Kazukata Yokota for the files:
sys/isa atkbd_isa.c atkbdc_isa.c
sys/dev/kbd atkbd.c atkbdc.c atkbdcreg.h atkbdreg.h
sys/i386/isa/pcvtpcvt_hdr.h
but has anyone else been having problems with these?
Attachments are:
#0 dmesg output of first boot after crash
#1 kgdb output for `where' and `list'
- Giorgos Keramidas
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Wed Mar 22 17:04:49 EET 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/HADES
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P54C (132.63-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52c Stepping = 12
Features=0x1bf
real memory = 33554432 (32768K bytes)
config> q
avail memory = 29831168 (29132K bytes)
Preloaded elf kernel "kernel" at 0xc02bf000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02bf09c.
Intel Pentium detected, installing workaround for F00F bug
VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c1bfa (c0001bfa)
VESA: S3 Incorporated. 86C325
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
isab0: at device 7.0 on pci0
isa0: on isab0
atapci0: port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: at 11.0 irq 11
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: irq 1 on atkbdc0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
lpt0: on ppbus0
lpt0: Interrupt-driven port
plip0: on ppbus0
sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5
on isa0
sbc0: setting card to irq 5, drq 1, 5
pcm0: on sbc0
unknown0: at port 0x168-0x16f,0x36e-0x36f irq 10 on
isa0
unknown1: at port 0x100 on isa0
unknown2: at port 0x200-0x207 on isa0
IP packet filtering initialized, divert enabled, rule-based forwarding enabled,
default to deny, logging limited to 100 packets/entry by default
DUMMYNET initialized (000106)
ad0: 6149MB [13328/15/63] at ata0-master using WDMA2
acd0: CDROM at ata1-master using WDMA2
Mounting root from ufs:/dev/ad0s1a
WARNING: / was not properly dismounted
hades# cd /sys/compile/HADES
/usr/src/sys/compile/HADES
hades# gdb -k kernel.debug /var/crash/vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 2953216
initial pcb at 25ea80
panicstr: from debugger
panic messages:
---
panic: from debugger
syncing disks...
done
Uptime: 57m27s
dumping to dev #ad/0x20001, offset 65536
dump ata0: resetting devices .. done
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc0136195 in panic (fmt=0xc02004b4 "from d
periodic daily output (passwd diffs)
When I changed my passwords from DES to MD5, I noticed this little thing with periodic daily output. Backup passwd and group files: passwd diffs: 1,2c1,2 < root:(password):0:0::0:0:Superuser:/root:/bin/csh < toor:(password):0:0::0:0:Bourne-again Superuser:/root:/usr/local/bin/bash --- > root:(password):0:0::0:0:Superuser:/root:/bin/csh > toor:(password):0:0::0:0:Bourne-again Superuser:/root:/usr/local/bin/bash At first glimpse, everything seems identical.. so, where is the difference? I realized that I had changed ONLY the password, and this was shown in the diffs in this strange way--since the password is clipped from the output of diff. Is this done on purpose, to show who has changed their password, or is it a side-effect of the way things are done until now, and we should attempt to change it some time? -- Giorgos Keramidas, < keramida @ ceid . upatras . gr> See the headers of this message for my public key fingeprint. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcvt console driver?
I cvsup'ed and compiled my kernel with the options shown below in my config file. device isa0 device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? irq 12 device vga0at isa? port ? # The pcvt console driver (vt220 compatible). device vt0 at isa? options XSERVER # support for running an X server on vt options FAT_CURSOR # start with block cursor # PCVT options documented in pcvt(4). options PCVT_CTRL_ALT_DEL options PCVT_FREEBSD=211 options PCVT_META_ESC options PCVT_NSCREENS=5 options PCVT_PRETTYSCRNS options PCVT_SCREENSAVER I wanted to give a test to pcvt driver, just for fun (and for profit, if it seemed better than syscons). Is pcvt working, at all? Or I should avoid using it? << This is with revision 1.64 of /sys/i386/isa/pcvt/pcvt_drv.c >> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. \ -I../../../include -D_KERNEL -include opt_global.h -elf \ -mpreferred-stack-boundary=2 ../../i386/isa/pcvt/pcvt_drv.c ../../i386/isa/pcvt/pcvt_drv.c:108: warning: `struct isa_device' declared inside parameter list ../../i386/isa/pcvt/pcvt_drv.c:108: warning: its scope is only this definition or declaration, which is probably not what you want. ../../i386/isa/pcvt/pcvt_drv.c:109: warning: `struct isa_device' declared inside parameter list ../../i386/isa/pcvt/pcvt_drv.c:111: variable `vtdriver' has initializer but incomplete type ../../i386/isa/pcvt/pcvt_drv.c:112: warning: excess elements in struct initializer ../../i386/isa/pcvt/pcvt_drv.c:112: warning: (near initialization for `vtdriver') ../../i386/isa/pcvt/pcvt_drv.c:112: warning: excess elements in struct initializer ../../i386/isa/pcvt/pcvt_drv.c:112: warning: (near initialization for `vtdriver') ../../i386/isa/pcvt/pcvt_drv.c:112: warning: excess elements in struct initializer ../../i386/isa/pcvt/pcvt_drv.c:112: warning: (near initialization for `vtdriver') ../../i386/isa/pcvt/pcvt_drv.c:112: warning: excess elements in struct initializer ../../i386/isa/pcvt/pcvt_drv.c:112: warning: (near initialization for `vtdriver') ../../i386/isa/pcvt/pcvt_drv.c:119: warning: `struct isa_device' declared inside parameter list ../../i386/isa/pcvt/pcvt_drv.c:120: conflicting types for `pcprobe' ../../i386/isa/pcvt/pcvt_drv.c:108: previous declaration of `pcprobe' ../../i386/isa/pcvt/pcvt_drv.c: In function `pcprobe': ../../i386/isa/pcvt/pcvt_drv.c:127: dereferencing pointer to incomplete type ../../i386/isa/pcvt/pcvt_drv.c: At top level: ../../i386/isa/pcvt/pcvt_drv.c:142: warning: `struct isa_device' declared inside parameter list ../../i386/isa/pcvt/pcvt_drv.c:143: conflicting types for `pcattach' ../../i386/isa/pcvt/pcvt_drv.c:109: previous declaration of `pcattach' ../../i386/isa/pcvt/pcvt_drv.c: In function `pcattach': ../../i386/isa/pcvt/pcvt_drv.c:149: dereferencing pointer to incomplete type ../../i386/isa/pcvt/pcvt_drv.c:151: dereferencing pointer to incomplete type ../../i386/isa/pcvt/pcvt_drv.c:214: dereferencing pointer to incomplete type *** Error code 1 - Giorgos Keramidas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl 5.6.0?
> From: "Alexander N. Kabaev" <[EMAIL PROTECTED]> > > I am perfectly aware of the way OpenBSD builds contrib software. I am just > making a point that they have found perl 5.6.0 is stable enough to be > included into their OS. Well, knowing the way they build their contrib stuff, one would expect that if some of the stuff fails in ways more subtle than "build time failures", they would not notice it until kind of late anyway. I don't want to make myself sound like an OpenBSD enemy here. I do appreciate their work, and their efforts to have the latest software release available. I'm just addicted to the way FreeBSD sticks to a working version until another is proven to work better :) Ciao. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syslogd: Too many '/' in "/dev//console"
From: Chris Wicklein <[EMAIL PROTECTED]> Subject: Re: syslogd: Too many '/' in "/dev//console" Date: Mon, Sep 03, 2001 at 10:09:45PM -0500 I really try to avoid `me too' messages, but.. > On Monday, September 3, 2001, at 03:42 PM, [EMAIL PROTECTED] wrote: > > > Between last weekend and this weekend, something changed in syslogd > > seems to have resulted in this boot-time error. The syslogd.c deltas > > from 1.82 -> 1.83 look suspect since the handling of relevant variables > > has changed. > > Sorry for the double post -- to reproduce this problem it's necessary to > run syslogd with the -s switch -- either no -s or -s -s fails to > generate this error. I was chatting with Chris on IRC, and tried to start syslogd with -s. The bug does not seem to appear in my syslogd, which was compiled when I did my last buildworld on Aug 25, 2001. I'm looking at the diffs from Aug 25, so if I come up with sth by running syslogd with -d, by tomorrow I'll have spotted this in more detail - probably replying with the patch to fix it too. Off to buildworld and bed, 'nite all. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syslogd: Too many '/' in "/dev//console"
From: Giorgos Keramidas <[EMAIL PROTECTED]>
Subject: Re: syslogd: Too many '/' in "/dev//console"
Date: Tue, Sep 04, 2001 at 06:39:36AM +0300
> I'm looking at the diffs from Aug 25, so if I come up with sth by
> running syslogd with -d, by tomorrow I'll have spotted this in more
> detail - probably replying with the patch to fix it too. Off to
> buildworld and bed, 'nite all.
Running "syslogd -d -s -s" and checking out my usr.sbin/syslogd
sources from various dates, I tracked this bug down to changes made
between Aug 31 2001 and Sep 1 2001.
In my /etc/syslog.conf I changed /dev/console to /dev/ttyvb so that
all messages are redirected to /dev/ttyvb (where I would easily spot
them, and do not clutter my active console).
Here's the output of two builds of syslogd with sources from the dates
mentioned:
hades!root:[/usr/src/usr.sbin/syslogd]# cvs up -A -P -d -q -D 'Aug 31 2001'
hades!root:[/usr/src/usr.sbin/syslogd]# make
hades!root:[/usr/src/usr.sbin/syslogd]# make install
hades!root:[/usr/src/usr.sbin/syslogd]# syslogd -d -s -s
off & running
init
cfline("*.* /var/log/messages", f,
"*", "*")
cfline("*.* /dev/ttyvb", f, "*", "*")
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 X FILE: /var/log/messages
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 X TTY: /dev/ttyvb
logmsg: pri 56, flags 4, from hades, msg syslogd: restart
Logging to FILE /var/log/messages
Logging to TTY /dev/ttyvb
syslogd: restarted
^Csyslogd: exiting on signal 2
syslogd: exiting on signal 2
logmsg: pri 53, flags 4, from hades, msg syslogd: exiting on signal 2
Logging to FILE /var/log/messages
Logging to TTY /dev/ttyvb
So, the sources of Aug 31 seem to run perfectly fine. Trying the same
with the sources of Sep 1, I get the interesting output shown below:
hades!root:[/usr/src/usr.sbin/syslogd]# cvs up -A -P -d -q -D 'Sep 1 2001'
hades!root:[/usr/src/usr.sbin/syslogd]# make
hades!root:[/usr/src/usr.sbin/syslogd]# make install
hades!root:[/usr/src/usr.sbin/syslogd]# syslogd -d -s -s
off & running
init
cfline("*.* /var/log/messages", f,
"*", "*")
cfline("*.* /dev/ttyvb", f, "*", "*")
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 X FILE: /var/log/messages
8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 X TTY: /dev//ttyvb
logmsg: pri 56, flags 4, from hades, msg syslogd: restart
Logging to FILE /var/log/messages
Logging to TTY /dev//ttyvb
syslogd: Too many '/' in "/dev//ttyvb"
logmsg: pri 53, flags 4, from hades, msg syslogd: Too many '/' in "/dev//ttyvb"
Logging to FILE /var/log/messages
Logging to UNUSED
syslogd: restarted
The following patch seems to have fixed the bug for me.
-giorgos
[-- start of patch --]
Index: syslogd.c
===
RCS file: /home/ncvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.84
diff -u -r1.84 syslogd.c
--- syslogd.c 1 Sep 2001 08:42:49 - 1.84
+++ syslogd.c 4 Sep 2001 19:04:25 -
@@ -1664,7 +1664,7 @@
f->f_type = F_CONSOLE;
else
f->f_type = F_TTY;
- (void)strlcpy(f->f_un.f_fname, p + sizeof(_PATH_DEV - 1),
+ (void)strlcpy(f->f_un.f_fname, p + sizeof _PATH_DEV - 1,
sizeof(f->f_un.f_fname));
} else {
(void)strlcpy(f->f_un.f_fname, p, sizeof(f->f_un.f_fname));
[-- end of patch --]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: syslogd: Too many '/' in "/dev//console"
From: Mike Heffner <[EMAIL PROTECTED]> Subject: Re: syslogd: Too many '/' in "/dev//console" Date: Tue, Sep 04, 2001 at 07:55:33PM -0400 > > On 04-Sep-2001 Giorgos Keramidas wrote: > | > | The following patch seems to have fixed the bug for me. > | > > Yea, Kris said he was going to fix it. This must be some undefined behavior > because I tested the change in a test program and the two sizeofs were giving > me the same result..strange ;) I want to test this without leaving "sizeof _PATH_DEV" surrounded by spaces, with sizeof() explicitly using parentheses. I'm not sure where the undefined behavior is triggered, but this is a very likely point, and the source of syslogd.c is just full of this. I have it fixed now in my local CVS tree. Hopefully Kris will commit something to fix it soon :-) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new feature for /etc/security
On Mon, Sep 03, 2001 at 10:35:22AM -0500, Damieon Stark wrote: > Greetings all, > > In my local source tree, I have a small modification to /etc/security > which I thought would be good to get in the base tree. The attached .diff > allows /etc/security to keep a record of all non-device related files located > in /dev. Many blackhat utilities, and practices include using the /dev > directory as a location to create sniffer logs, suid binaries, and other evil. > By keeping a database similar to /var/log/setuid.today, administrators can be > notified of any changes to /dev. The diff is against -current, however the > functionality is unchanged between -stable and -current. Isn't this blackhat practice rendered useless with DEVFS ? Of course someone who's been hacked cannot rely on DEVFS being mounted before anything accessed the 'hidden in /dev stuff'. /me just wondering -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix fails to start
From: Hellmuth Michaelis <[EMAIL PROTECTED]> Subject: postfix fails to start Date: Thu, Sep 06, 2001 at 09:46:15PM +0200 > Hmm .. > > thought i should update my current machine 2 hours ago, cvs´d a tree, made > and installed it. Reboot. Got: > > Sep 6 21:33:48 bert postfix[15838]: fatal: could not find any active network >interfaces ifconfig output please ? -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: anonymous-ftp cracked
From: P. U. (Uli) Kruppa <[EMAIL PROTECTED]> Subject: anonymous-ftp cracked Date: Wed, Sep 12, 2001 at 05:52:23PM +0200 > I am running -CURRENT (ok - though I do not know anything > about computers) Why are you running -CURRENT? Users that are running -CURRENT are expected to be able to track relatively simple problems like this one, without asking tons of questions. And this is not a problem of -CURRENT but of ftpd setup :-/ > and just found about about 624 MB trash in > my /var/ftp - this is my anonymous-ftp -directory. > It was disposed in a sub-directory > ../incoming/tagged/byDj-krok . You have not been cracked. Somebody just uses your writable /incoming directory to store their data. Since they *do* have write access in there, this is a legitimate use of your FTP server. > What can I do (besides deleting this stuff)? Do not allow write access in /var/ftp/incoming ? Another common thing done in writable incoming/ directories is to create a file of fixed size, say 100 Mb, and use vnconfig to mount this file as the incoming/ directory of an FTP server. Then there's only about 100 Mb of space available in your incoming/ and nobody can store tons of data in there, wasting your disk space until disks are full. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel won't build - atomic.c/atomic.h errors...
Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Sat, 10 Nov 2001, John Baldwin wrote:
> > On 08-Nov-01 Bruce Evans wrote:
> > > The i386 still uses archaic constraints for some
> > > input-output operands ("0" for the first operand). These never worked
> > > right and if fact don't actually work for compiling this file without
> > > optimization.
> >
> > Hmm, would you prefer this diff then, I've had it floating around for a while
> > now but wasn't sure it was right:
>
> Yes, it is right provided all the operand renumbering is right. I suppose
> it can't be checked simply by comparing all objects, because it sometimes
> changes the register allocation?
>
> There are a couple more "0"s in atomic_cmpset_int(), and many more in other
> files (even in cpufunc.h).
Actually there are only 14 files that make use of "0" .. "9".
% find ./sys -type f | xargs grep -l ':[[:space:]]*"[0-9]"'
./sys/alpha/include/alpha_cpu.h
./sys/contrib/dev/acpica/acgcc.h
./sys/gnu/ext2fs/i386-bitops.h
./sys/gnu/i386/fpemul/fpu_entry.c
./sys/i386/i386/identcpu.c
./sys/i386/i386/in_cksum.c
./sys/i386/i386/math_emulate.c
./sys/i386/include/atomic.h
./sys/i386/include/cpufunc.h
./sys/i386/include/endian.h
./sys/i386/include/in_cksum.h
./sys/sparc64/include/in_cksum.h
./sys/sparc64/sparc64/in_cksum.c
./sys/gnu/i386/fpemul/fpu_entry.c & ./sys/i386/i386/math_emulate.c
were quite easy to change. I'm not using math emulation, but the
changes to these two were almost trivial and I already mailed jhb a
hopefully correct diff. It's also online at
http://people.freebsd.org/~keramida/diff/diff.063.kern
For the rest of the i386 files, it'll take the rest of my Sunday
afternoon and a buildworld or two, I guess. I can't make any sparc64
or alpha changes though.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Test tweak for F00F bug..
On Tue, Oct 23, 2001 at 10:57:18AM -0700, John Baldwin wrote: > Anyone running -current on a true Pentium with the F00F bug that can verify > that this simple cleanup patch works? > > http://www.freebsd.org/~jhb/patches/f00f.patch I can. Running it on p5/133 right now. CPU: Pentium/P54C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf ... Intel Pentium detected, installing workaround for F00F bug Building world, now. Just give me another 8-10 hours to let my buildworld/installworld finish normally. Apart from crafting my own gas(1) test to make sure this works, anything particular I should look more carefully for? -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: It's baaack... -- ("make: don't know how to make copies. Stop")
On Tue, Oct 23, 2001 at 08:43:29PM +0100, Mark Murray wrote:
>
> Actually, it is possible for there to be no copies: target in
> src/share/examples/. The copies: (actually copies::)
> target is built up in a .for loop that may be empty.
>
> The fix is a dummy copies:: target.
I've tested the following patch, and it works like a charm.
At least, it let me build and install world with a clean /usr/obj :-)
hades!sysop:[/usr/src/share/examples]# cvs -q dif -2cl | more
Index: Makefile
===
RCS file: /home/ncvs/src/share/examples/Makefile,v
retrieving revision 1.29
diff -2 -c -r1.29 Makefile
*** Makefile20 Oct 2001 04:18:13 - 1.29
--- Makefile22 Oct 2001 01:29:03 -
***
*** 22,25
--- 22,29
beforeinstall: etc-examples ${SHARED}
+ copies::
+
+ symlinks::
+
.for dir in ${DIRS}
FILES!= find -L ${dir} \( -name CVS -prune \) -o -type f -print
-giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: daily run output & passwd diff
On 2001-11-13 15:31:02, Crist J. Clark wrote: > > echo "$host passwd diffs:" > - diff $bak/master.passwd.bak /etc/master.passwd |\ > - sed 's/^\([<>] [^#][^:]*\):[^:]*:/\1:(password):/' > + diff -I '^#' $bak/master.passwd.bak /etc/master.passwd |\ > + sed 's/^\([<>] [^:]*\):[^:]*:/\1:(password):/' > mv $bak/master.passwd.bak $bak/master.passwd.bak2 > cp -p /etc/master.passwd $bak/master.passwd.bak || rc=3 > fi This version looks great. I'm not sure if you need to ignore lines that have whitespace before the initial '#' character, but this one is already good enough :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCHES for Kris Kennaway to commit
Terry Lambert <[EMAIL PROTECTED]> wrote: > Steve Kargl wrote: > > > > man send-pr > > Yeah; I'd prefer it if "send-pr" ran under Windows, or of > FreeBSD would support WinModems. What fails to work for you in the Web Interface at http://www.FreeBSD.org/send-pr.html ? -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCHES for Kris Kennaway to commit
Jason <[EMAIL PROTECTED]> wrote: > > The web interface doesn't allow for patches to be attached. > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27653 [ Synopsis: Updates to send-pr.html to support MIME ] Don't use attachments. MIME is evil. Copy/paste the patch in the report. There are people out there that do not have MIME-aware MUA's and you'll break the nice query-pr command that developers can use in freefall to read the entire text of a PR. freefall% query-pr -F 27653 | more If you use base64/quoted-printable or some other exotic encoding of the attached patch, the above command will be pretty useless. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about -current
On 2002-01-21 09:22:08, [EMAIL PROTECTED] wrote:
> 5) In -current would it be possible to have a few command line
> switches added to certain userland utilities? I noticed -h made it
> into `ls` now, but `cp` still doesn't have -a or -x which I used to
> use all the time in Linux. I know -a isn't a big deal but - x was
> definitely nice from time to time.
What does the -a or -x option do for the ls(1) command of Linux?
Perhaps equivalent options do already exist in FreeBSD ls(1).
> `date` having a --date option to tell you when a specified date is
> in Linux is also very nice. Just some thoughts.
If I haven't misunderstood you on this, FreeBSD's date(1) can already
do what you want, although I have to admit that it works a bit
differently than Linux's date(1).
I've recently used date(1) -j and -f options to convert arbitrary
dates to the local timezone in a script I wrote to print the
modification date of problem reports. You might want to check the
scripts at:
http://people.FreeBSD.org/~keramida/pr/feedback/
for samples of using date(1) to convert between timezones and date
representations. A small example that will probably help you
understand how this is done (combined with the description of the -j
and -f options in the date(1) manual page) is shown below:
hades!charon:[/home/charon]% date '+%s => %T %Z'
1011645430 => 22:37:10 EET
hades!charon:[/home/charon]% TZ=UTC date -j -f '%s' 1011645328 '+%s => %T %Z'
1011645328 => 20:35:28 GMT
Cheers,
--
Giorgos Keramidas . . . . . . . . . keramida@{ceid.upatras.gr,freebsd.org}
FreeBSD Documentation Project . . . http://www.freebsd.org/docproj/
FreeBSD: The power to serve . . . . http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Latest binutils import breaks Alpha cross compiles
On 2002-01-30 23:22, Terry Lambert wrote: > Peter Wemm wrote: > > I dont suppose you actually thought to go and have a look and see what the > > problem is yourself, rather than assigning the work to somebody else? > > Nope, sorry. > > I hear the latest binutils break Alpha cross compilation. My > fix is to back out the changes locally, and not use them. > > Basically, instead of fixing the brokeness, I chose to not > break the fixedness. This still *is* -CURRENT, right? If it doesn't break, once in a while, how will new things be tested by the -CURRENT userbase? Instead of whining about "you broke it, and haven't fixed it" it would be a far better thing to contribute patches that fix the brokenness. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bremfree related panic
I rebuilt my -CURRENT workstation last night. There still seems to be a
minor problem though. While I was running XFree 3.x (a rather old build,
compiled from ports):
$ pkg_info | grep XFree
XFree86-3.3.6_9 X11R6.3/XFree86 core distribution
there was the following panic. At the same time the disk was heavily
spinning, as I was updating my local NetBSD mirror with CVSup, and periodic
was running it's daily stuff. Does this look like a problem with X to you
all, or should I look for other causes? I am thinking of X giving me these
troubles, only because of frame #13 which is in an address that cannot be
printed by gdb. Any ideas?
(The bremfree panic is the second panic in the row, so it's probably a
whole different problem in itself.)
Script started on Fri Feb 8 05:55:22 2002
[toor@hades /var/crash]# gdb -k /usr/obj/usr/src/sys/CHARON/kernel.debug vmcore.1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 2629
in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 935
in fill_symbuf
IdlePTD at phsyical address 0x003d1000
initial pcb at physical address 0x00329bc0
panicstr: bremfree: bp 0xc2161734 not locked
panic messages:
---
panic: msleep
syncing disks... panic: bremfree: bp 0xc2166e4c not locked
Uptime: 2d15h0m41s
dumping to dev ad0s3b, offset 1966080
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37
36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
6 5 4 3 2 1
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
504 if (!dodump)
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
#1 0xc01b8ec4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:336
#2 0xc01b9361 in panic (fmt=0xc02b5da2 "bremfree: bp %p not locked") at
/usr/src/sys/kern/kern_shutdown.c:646
#3 0xc01e7ecf in bremfree (bp=0xc2161734) at /usr/src/sys/kern/vfs_bio.c:545
#4 0xc0196359 in spec_fsync (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:407
#5 0xc0195e51 in spec_vnoperate (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#6 0xc024d449 in ffs_sync (mp=0xc0e00200, waitfor=2, cred=0xc05bee00,
td=0xc02f9604) at vnode_if.h:441
#7 0xc01f4c42 in sync (td=0xc02f9604, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:669
#8 0xc01b8b46 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:245
#9 0xc01b9361 in panic (fmt=0xc02cb2fe "%s") at
/usr/src/sys/kern/kern_shutdown.c:646
#10 0xc0289d78 in trap_fatal (frame=0xc03d5fa8, eva=791205) at
/usr/src/sys/i386/i386/trap.c:842
#11 0xc0289aad in trap_pfault (frame=0xc03d5fa8, usermode=0, eva=791205) at
/usr/src/sys/i386/i386/trap.c:756
#12 0xc02895ef in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 51676,
tf_esi = 1816, tf_ebp = 264, tf_isp = -1069719596,
tf_ebx = 264, tf_edx = 980, tf_ecx = 6930, tf_eax = 0, tf_trapno = 12, tf_err
= 4, tf_eip = 4773, tf_cs = 49152,
tf_eflags = 721478, tf_esp = 4000, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:426
#13 0x12a5 in ?? ()
Cannot access memory at address 0x108.
(kgdb) list /usr/src/sys/kern/vfs_bio.c:545
540 int old_qindex = bp->b_qindex;
541
542 GIANT_REQUIRED;
543
544 if (bp->b_qindex != QUEUE_NONE) {
545 KASSERT(BUF_REFCNT(bp) == 1, ("bremfree: bp %p not
locked",bp));
546 TAILQ_REMOVE(&bufqueues[bp->b_qindex], bp, b_freelist);
547 bp->b_qindex = QUEUE_NONE;
548 } else {
549 if (BUF_REFCNT(bp) <= 1)
(kgdb) list /usr/src/sys/i386/i386/trap.c:426
421
422 KASSERT(cold || td->td_ucred != NULL,
423 ("kernel trap doesn't have ucred"));
424 switch (type) {
425 case T_PAGEFLT: /* page fault */
426 (void) trap_pfault(&frame, FALSE, eva);
427 goto out;
428
429 case T_DNA:
430 #ifdef DEV_NPX
(kgdb) q
[toor@hades /var/crash]# exit
Script done on Fri Feb 8 05:56:52 2002
Here's the dmesg output too:
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved
Re: Binutils fixed in -current?
On 2002-02-08 06:57, Alfred Perlstein wrote:
> * Andrea Campi <[EMAIL PROTECTED]> [020208 03:51] wrote:
> > On Wed, Feb 06, 2002 at 12:35:39PM -0800, Alfred Perlstein wrote:
> > > * David W. Chapman Jr. <[EMAIL PROTECTED]> [020206 12:33] wrote:
> > > > Does anyone know if the problem with kde and other programs not
> > > > working with the new binutils not working have been fixed yet?
> > >
> > > I find that mozilla 0.9.8 dies with pure virtual called or something
> > > to that effect, however I don't have a super recent world, I'm compiling
> > > one now and will let you know if it at least fixes that for me.
> >
> > FYI, I also get this on 4.5-STABLE.
>
> If you do a pkg_deletew of mozilla and then nuke /usr/X11R6/lib/mozilla
> then reinstall it the problem should go away.
Just my $0.02:
A reinstall of the port fixed the problems I was having with the
www/linux-netscape47-communicator port after a buildworld at Jan 7.
Probably unrelated to the mozilla problems, but I thought I'd mention in
case someone else sees netscape start, and dump core before even displaying
the main window in X11.
--
Giorgos Keramidas . . . . . . . . . keramida@{ceid.upatras.gr,freebsd.org}
FreeBSD Documentation Project . . . http://www.freebsd.org/docproj/
FreeBSD: The power to serve . . . . http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
bremfree related panic
I rebuilt my -CURRENT workstation last night. There still seems to be a
minor problem though. While I was running XFree 3.x (a rather old build,
compiled from ports):
$ pkg_info | grep XFree
XFree86-3.3.6_9 X11R6.3/XFree86 core distribution
there was the following panic. At the same time the disk was heavily
spinning, as I was updating my local NetBSD mirror with CVSup, and periodic
was running it's daily stuff. Does this look like a problem with X to you
all, or should I look for other causes? I am thinking of X giving me these
troubles, only because of frame #13 which is in an address that cannot be
printed by gdb. Any ideas?
(The bremfree panic is the second panic in the row, so it's probably a
whole different problem in itself.)
Script started on Fri Feb 8 05:55:22 2002
[toor@hades /var/crash]# gdb -k /usr/obj/usr/src/sys/CHARON/kernel.debug vmcore.1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 2629
in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 935
in fill_symbuf
IdlePTD at phsyical address 0x003d1000
initial pcb at physical address 0x00329bc0
panicstr: bremfree: bp 0xc2161734 not locked
panic messages:
---
panic: msleep
syncing disks... panic: bremfree: bp 0xc2166e4c not locked
Uptime: 2d15h0m41s
dumping to dev ad0s3b, offset 1966080
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37
36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
6 5 4 3 2 1
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
504 if (!dodump)
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
#1 0xc01b8ec4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:336
#2 0xc01b9361 in panic (fmt=0xc02b5da2 "bremfree: bp %p not locked") at
/usr/src/sys/kern/kern_shutdown.c:646
#3 0xc01e7ecf in bremfree (bp=0xc2161734) at /usr/src/sys/kern/vfs_bio.c:545
#4 0xc0196359 in spec_fsync (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:407
#5 0xc0195e51 in spec_vnoperate (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#6 0xc024d449 in ffs_sync (mp=0xc0e00200, waitfor=2, cred=0xc05bee00,
td=0xc02f9604) at vnode_if.h:441
#7 0xc01f4c42 in sync (td=0xc02f9604, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:669
#8 0xc01b8b46 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:245
#9 0xc01b9361 in panic (fmt=0xc02cb2fe "%s") at
/usr/src/sys/kern/kern_shutdown.c:646
#10 0xc0289d78 in trap_fatal (frame=0xc03d5fa8, eva=791205) at
/usr/src/sys/i386/i386/trap.c:842
#11 0xc0289aad in trap_pfault (frame=0xc03d5fa8, usermode=0, eva=791205) at
/usr/src/sys/i386/i386/trap.c:756
#12 0xc02895ef in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 51676,
tf_esi = 1816, tf_ebp = 264, tf_isp = -1069719596,
tf_ebx = 264, tf_edx = 980, tf_ecx = 6930, tf_eax = 0, tf_trapno = 12, tf_err
= 4, tf_eip = 4773, tf_cs = 49152,
tf_eflags = 721478, tf_esp = 4000, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:426
#13 0x12a5 in ?? ()
Cannot access memory at address 0x108.
(kgdb) list /usr/src/sys/kern/vfs_bio.c:545
540 int old_qindex = bp->b_qindex;
541
542 GIANT_REQUIRED;
543
544 if (bp->b_qindex != QUEUE_NONE) {
545 KASSERT(BUF_REFCNT(bp) == 1, ("bremfree: bp %p not
locked",bp));
546 TAILQ_REMOVE(&bufqueues[bp->b_qindex], bp, b_freelist);
547 bp->b_qindex = QUEUE_NONE;
548 } else {
549 if (BUF_REFCNT(bp) <= 1)
(kgdb) list /usr/src/sys/i386/i386/trap.c:426
421
422 KASSERT(cold || td->td_ucred != NULL,
423 ("kernel trap doesn't have ucred"));
424 switch (type) {
425 case T_PAGEFLT: /* page fault */
426 (void) trap_pfault(&frame, FALSE, eva);
427 goto out;
428
429 case T_DNA:
430 #ifdef DEV_NPX
(kgdb) q
[toor@hades /var/crash]# exit
Script done on Fri Feb 8 05:56:52 2002
Here's the dmesg output too:
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved
Re: Binutils fixed in -current?
On 2002-02-08 06:57, Alfred Perlstein wrote:
> * Andrea Campi <[EMAIL PROTECTED]> [020208 03:51] wrote:
> > On Wed, Feb 06, 2002 at 12:35:39PM -0800, Alfred Perlstein wrote:
> > > * David W. Chapman Jr. <[EMAIL PROTECTED]> [020206 12:33] wrote:
> > > > Does anyone know if the problem with kde and other programs not
> > > > working with the new binutils not working have been fixed yet?
> > >
> > > I find that mozilla 0.9.8 dies with pure virtual called or something
> > > to that effect, however I don't have a super recent world, I'm compiling
> > > one now and will let you know if it at least fixes that for me.
> >
> > FYI, I also get this on 4.5-STABLE.
>
> If you do a pkg_deletew of mozilla and then nuke /usr/X11R6/lib/mozilla
> then reinstall it the problem should go away.
Just my $0.02:
A reinstall of the port fixed the problems I was having with the
www/linux-netscape47-communicator port after a buildworld at Jan 7.
Probably unrelated to the mozilla problems, but I thought I'd mention in
case someone else sees netscape start, and dump core before even displaying
the main window in X11.
--
Giorgos Keramidas . . . . . . . . . keramida@{ceid.upatras.gr,freebsd.org}
FreeBSD Documentation Project . . . http://www.freebsd.org/docproj/
FreeBSD: The power to serve . . . . http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
convert libgmp to a port?
I was looking at PR/9233 from Dec 1998 the other day, and I saw that the version of libgmp thats included in the base-system seems to be very outdated (version 2.x in our tree, while version 3.x is available at the homepage of libgmp). After discussing this with [EMAIL PROTECTED] about it through mail, I started looking through the sources to see where libgmp is used. It may be a false impression of mine, but in the -STABLE sources that I checked, I didn't seem to find anyone in the base-system `using' libgmp. I tried grepping through the entire /usr/src to find one place except for contrib/libgmp that seems to be using functions from libgmp (I was looking for functions that matched "\
Re: convert libgmp to a port?
On Sat, Jun 16, 2001 at 11:38:45PM -0700, Peter Wemm wrote: > It should not be too hard to have build a lightweight 'libbignum' that > is extracted from the openssl sources and make that available in the base > system. It would not be hard to convert the lib*mp consumers to use the > libbignum (libbn, -lbn ?) and then we can get rid of it. > > telnet* should never have used libmp in the first place, it should have > used libcrypto/bignum. chkey/newkey/keyserv are using libmp for > diffie-helmann key exchange. (just large integer multiplication). It > should be really easy to convert those three. Since there are a few things that are using libgmp (and I missed them in my quick search through the sources), no I would not prefer removing libgmp and making a new, probably buggier, libbignum that will replace our current libgmp. If we do need some of the functionality of libgmp in the base-system, then we really should import some newer version of libgmp, instead of trying to make our own new library. I dont really like reinventing wheels :) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: convert libgmp to a port?
On Sun, Jun 17, 2001 at 01:51:56PM -0700, Kris Kennaway wrote: > libbn is already part of OpenSSH; it's a trivial matter to make it > into a standalone library. In other words, we already include two > functionally equivalent bignum libraries in FreeBSD, so one of them > should go. I couldn't agree more :) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock order reversal
Yet another... Jun 20 19:47:08 hades /boot/kernel/kernel: lock order reversal Jun 20 19:47:08 hades /boot/kernel/kernel: 1st 0xc04d91a0 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007 Jun 20 19:47:08 hades /boot/kernel/kernel: 2nd 0xc3f86b6c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016 The revision of the referenced file is: /usr/src/sys/ufs/ffs/ffs_vfsops.c: $FreeBSD: src/sys/ufs/ffs/ffs_vfsops.c,v 1.155 2001/05/29 21:21:49 phk Exp $ -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
funny strlen defines in sys/alpha/alpha/alpha-gdbstub.c
Close to the top of sys/alpha/alpha/alpha-gdbstub.c i found out this,
as i was randomly browsing the kernel sources today:
1 /* $FreeBSD: src/sys/alpha/alpha/alpha-gdbstub.c,v 1.11 2001/03/28 01:54:05
jhb Exp $ */
...
130 #define strlen gdb_strlen
131 #define strcpy gdb_strcpy
...
133 static int
134 strlen (const char *s)
135 {
...
143 static char *
144 strcpy (char *dst, const char *src)
145 {
...
wondering what happens when this file is fed to the preprocessor, it
seems that all occurences of strlen() and strcpy() are replaced with
gdb_strlen() and gdb_strcpy() in this file.
Is it really necessary to do this funny thing with the #defines? I
mean, why not replace the calls with gdb_XXX() ourselves and be done
with it? After all it only occurs in a handful of places, and the
functions are static.
% fgrep strlen alpha-gdbstub.c | wc -l
8
% fgrep strcpy alpha-gdbstub.c | wc -l
11
As I dont have an Alpha around, I can't actually test the attached
patch, but I'm looking forward to your comments.
-giorgos
Index: alpha/alpha/alpha-gdbstub.c
===
RCS file: /home/ncvs/src/sys/alpha/alpha/alpha-gdbstub.c,v
retrieving revision 1.11
diff -c -u -r1.11 alpha-gdbstub.c
--- alpha/alpha/alpha-gdbstub.c 2001/03/28 01:54:05 1.11
+++ alpha/alpha/alpha-gdbstub.c 2001/07/02 08:25:34
@@ -119,19 +119,8 @@
/* at least NUMREGBYTES*2 are needed for register packets */
#define BUFMAX 1500
-/* Create private copies of common functions used by the stub. This prevents
- nasty interactions between app code and the stub (for instance if user steps
- into strlen, etc..) */
-/* XXX this is fairly bogus. strlen() and strcpy() should be reentrant,
- and are reentrant under FreeBSD. In any case, our versions should not
- be named the same as the standard versions, so that the address `strlen'
- is unambiguous... */
-
-#define strlen gdb_strlen
-#define strcpy gdb_strcpy
-
static int
-strlen (const char *s)
+gdb_strlen (const char *s)
{
const char *s1 = s;
@@ -141,7 +130,7 @@
}
static char *
-strcpy (char *dst, const char *src)
+gdb_strcpy (char *dst, const char *src)
{
char *retval = dst;
@@ -230,7 +219,7 @@
/* remove sequence chars from buffer */
- count = strlen (buffer);
+ count = gdb_strlen (buffer);
for (i=3; i <= count; i++)
buffer[i-3] = buffer[i];
}
@@ -239,7 +228,7 @@
}
while (checksum != xmitcsum);
- if (strlen(buffer) >= BUFMAX)
+ if (gdb_strlen(buffer) >= BUFMAX)
panic("kgdb: buffer overflow");
}
@@ -252,7 +241,7 @@
int count;
unsigned char ch;
- if (strlen(buffer) >= BUFMAX)
+ if (gdb_strlen(buffer) >= BUFMAX)
panic("kgdb: buffer overflow");
/* $#. */
@@ -655,7 +644,7 @@
case 'G': /* set the value of the CPU registers - return OK */
hex2mem (&remcomInBuffer[1], (vm_offset_t)®isters, NUMREGBYTES);
- strcpy (remcomOutBuffer, "OK");
+ gdb_strcpy (remcomOutBuffer, "OK");
break;
case 'P': /* Set the value of one register */
@@ -669,10 +658,10 @@
&& regno < NUM_REGS)
{
hex2mem (ptr, (vm_offset_t)®isters + regno * 8, 8);
- strcpy(remcomOutBuffer,"OK");
+ gdb_strcpy(remcomOutBuffer,"OK");
}
else
- strcpy (remcomOutBuffer, "P01");
+ gdb_strcpy (remcomOutBuffer, "P01");
break;
}
case 'm': /* mAA..AA, Read bytes at address AA..AA */
@@ -685,11 +674,11 @@
&& hexToInt (&ptr, &length))
{
if (mem2hex((vm_offset_t) addr, remcomOutBuffer, length) == NULL)
- strcpy (remcomOutBuffer, "E03");
+ gdb_strcpy (remcomOutBuffer, "E03");
break;
}
else
- strcpy (remcomOutBuffer, "E01");
+ gdb_strcpy (remcomOutBuffer, "E01");
break;
case 'M': /* MAA..AA,: Write bytes at address AA.AA return OK */
@@ -704,12 +693,12 @@
&& *(ptr++) == ':')
{
if (hex2mem(ptr, (vm_offset_t) addr, length) == NULL)
- strcpy (remcomOutBuffer, "E03");
+ gdb_strcpy (remcomOutBuffer, "E03");
else
- strcpy (remcomOutBuffer, "OK");
+ gdb_strcpy (remcomOutBuffer, "OK");
}
else
- strcpy (remcomOutBuffer, "E02");
+ gdb_strcpy (remcomOutBuffer, "E02");
break;
/* cAA..AAContinue at address AA..AA(optional) */
Re: funny strlen defines in sys/alpha/alpha/alpha-gdbstub.c
On Tue, Jul 03, 2001 at 09:04:23AM +1000, Peter Jeremy wrote:
> Alternatively, given the XXX comment, why not delete the local copies
> of str{cpy,len}() and just usr the library versions? The original
> reason appears to be to avoid the possibility that str{cpy,len}() are
> not re-entrant. The FreeBSD ones _are_ re-entrant and it doesn't seem
> likely that we will re-write them not to be re-entrant.
I don't have an alpha around to test any of these changes.
If someone can test a kernel with these functions removed, and/or
replaced by gdb_xxx equivalents, and says that it works for them, its
ok with me.
What you suggest about reentrancy seems OK though :-)
-giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cannot print to remote printer
Anton Berezin <[EMAIL PROTECTED]> writes:
> On Thu, Jul 12, 2001 at 08:45:55AM +0200, Joerg Wunsch wrote:
> > Anton Berezin <[EMAIL PROTECTED]> wrote:
> >
> > > if (fork() == 0) {
> > > - signal(SIGCHLD, SIG_IGN);
> > > + signal(SIGCHLD, SIG_DFL);
> >
> > This is unportable.
>
> > If you want automatic zombie reaping, better don't use the simplified
> > signal(3) handling, but instead spell it out as sigaction(2) using the
> > SA_NOCLDWAIT flag. The above won't even give you a warning on systems
> > that don't implement automatic zombie reaping, while with sicaction,
> > you'll get a compile-time error for SA_NOCLDWAIT not being defined.
>
> Umm, I don't understand. I do not want automatic zombie reaping, I want
> exactly the opposite, and my patch does just that.
I might be wrong in many ways, but...
is it then mandatory that you `reset' SIGCHLD to SIG_DFL ?
Why not leave it in it's default state, and make this patch:
- signal(SIGCHLD, SIG_IGN);
without adding any lines?
I'm in a wild rush, and I don't have the time to actually look at the code or
test it. I will, soon, though...
-giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cannot print to remote printer
From: Terry Lambert <[EMAIL PROTECTED]> Subject: Re: cannot print to remote printer Date: Fri, Jul 13, 2001 at 10:48:53AM -0700 > Garrett Wollman wrote: > > > The new POSIX draft, at least, sanctions the automatic reset of > > SIGCHLD to SIG_DFL upon exec(). > > How does the "NOHUP" program continue to function in > light of this reset demand? I'm not sure about POSIX, but the manpage of nohup does not mention SIGCHLD. The only signals I see mentioned in revision 1.8 of nohup.1 are SIGHUP and SIGQUIT. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: picking a DB (Re: nvi maintainer?)
Keith Bostic <[EMAIL PROTECTED]> writes: > Nvi needs some of the features of Berkeley DB 3.X (transactional > logging) in order to fix long-standing bugs in the application. > > Regards, > --keith Is DB 3.x the only workaround for these bugs? -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Userbase of -current
From: Tom Fischer <[EMAIL PROTECTED]> Subject: Re: Userbase of -current Date: Mon, Jul 23, 2001 at 07:19:25PM +0200 > Add a data point for me using -current on my laptop in order to take > advantage of cardbus support (thanks Warner!). We really should have those Slashdot people run a poll or sth :P Count me too. 5 runs nicely on my aging Pentium box at home. It's still very nice to be able to check the documentation parts of the tree against the latest -CURRENT sources. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias
From: Crist J. Clark <[EMAIL PROTECTED]> Subject: Re: Copyright Contradiction in libalias Date: Tue, Aug 21, 2001 at 11:40:20AM -0700 > On Tue, Aug 21, 2001 at 08:14:59AM -0500, Thomas T. Veldhouse wrote: > > > So, if Microsoft > > decides they want your software without the existing license (public domain) > > you can relicense it to them for a fee under whatever terms you want, and > > they must deal with you on it because of the copyright that you hold. > > No, they don't have to deal with you. MS can license code in the > public domain however they like. They need not consult you at all. But can someone that did not know about the `public domain' state of the program accuse you, tha author, later on that you 'cheated' on him, if you do ask for money when they come to you and ask that they `buy' the source? I am not a lawyer, and I am probably mistaken here, but if someone wants to pay me for a program, even if the program has been released by me to the public domain, I think I will not refuse their money. Of course, being the stupid^W ethical guy I am, I will note that the program is public domain, and if they still want to buy it, then I won't refuse selling it. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias
From: Warner Losh <[EMAIL PROTECTED]> Subject: Re: Copyright Contradiction in libalias Date: Wed, Aug 22, 2001 at 12:24:56AM -0600 > In message <[EMAIL PROTECTED]> Nate Williams writes: > : > > : > Once it's in the Public Domain you have abandoned your claim to copyright. > : > : On that released version, yes. But, not on subsuquent versions. I > : still maintain my rights to do with the code as I please. > > Then you are creating a new work, based on the public domain work that > went before it. Yes, and no. Distributing the exact same sources (with an extra copyright part) that says somebody should not copy and distribute it, as if it were in the public domain, a few weeks after is probably fraud. Arguments like "but I put extra work in this second distribution, since I made this nifty packaging with bright colours and the CDROM contains those awesome .jpeg images of my new keyboard" will probably sound a bit funny. The truth is that this is getting hairy. If you release something in the public domain, and then add value to it by changing a few things here and there, this is clearly a 'derivative' work. You do have the right to put any license you want on the derivative, of course - just like everyone else can put their own license on their own derivative works. So you are essentially very right ;-) -giorgos [ Isn't this thread by now more fit to -chat? ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Copyright Contradiction in libalias
From: Crist J. Clark <[EMAIL PROTECTED]> Subject: Re: Copyright Contradiction in libalias Date: Tue, Aug 21, 2001 at 04:29:13PM -0700 > On Tue, Aug 21, 2001 at 04:46:07PM -0600, Nate Williams wrote: > > > However, I can't retroactively take away the rights of anyone who has > > gotten my 'public domain' software. > > You can't do anything. You have no more rights to the software than > anyone else does (except the ability to say you wrote it). Even that (the ability to say you wrote it) might be difficult under certain circumstances. For instance, assuming that you release something to the public domain, and you suspect that someone's brand new and shining binary release of something that behaves like your own code is based on it, there is no clear way of determining whether the claim 'it was me who originally wrote this' is true or false. The recent thread about networking code in Windows and BSD implementation of the IP family of protocols is a good example of such a case :) > > Back to the original question, Charles Mott is the original author of > > said code, and he can release his software under any license he so > > pleases. > > So can FreeBSD with or without his consent since it is public domain > software. Yep. True. The only problem is that if Charles Mott makes changes at a later date to his codebase, changes cannot be merged to the FreeBSD version without permission from him, even if the patches apply cleanly and break nothing that FreeBSD uses. Any future changes that Charles Mott makes to versions that are not explicitly declared by him to be public domain software, have to be rewritten from scratch by FreeBSD folk. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: diskcheckd is poo
From: Mike Smith <[EMAIL PROTECTED]> Subject: Re: diskcheckd is poo Date: Fri, Aug 24, 2001 at 04:14:24PM -0700 > If we want a surface scrubber, we ought to have a "real" one; it's > also very, very bad in the laptop context (since it keeps waking your > disks up). > > If we're going to keep it, it should be turned off by default at any rate. Lots of people have already jumped in and noted that they have this turned off by default. I guess a 'me too' is probably kind of lame in this case, but yes, I also have it disabled. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/defaults/rc.conf
On Mon, Nov 06, 2000 at 06:18:38PM -0500, Chris Faulhaber wrote:
>
> You forgot the patch(es) to the port(s) this would affect (e.g. xinetd).
> The affected ports would need their ${PREFIX}/etc/rc.d files removed
> (otherwise you would start them twice) along with a message letting the
> installer know how to start it properly.
As a first attempt to do this the proper way, I'm thinking of adding
an option like USE_SYSTEM_ETC in the xinetd port, that will inhibit
installing of the rc.d script, and print a note at the end that tells
the installer to change inetd_program in /etc/rc.conf.
Any objections to this?
- giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /etc/defaults/rc.conf
On Tue, Nov 07, 2000 at 09:30:48AM +, Konstantin Chuguev wrote: > > If xinetd has a startup script, why don't you just set inetd_enable="NO" and let > the /usr/local/etc/rc.d/xinetd.sh start normally? You need to edit no /etc/rc.* > files (except for rc.conf.local, obviously). The original idea was to allow other programs to be used instead of the default inetd, by tweaking /etc/rc.conf appropriately. For instance, one could say: inetd_enable="YES" inetd_program="/usr/local/sbin/xinetd" inetd_flags="-reuse" and change his internet-superserver program to something else. I am not sure if this is something that a lot of people would consider a desired feature, but I was trying to see if it can be done (see the request that started this thread). - giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/defaults/rc.conf
On Mon, Nov 06, 2000 at 03:37:01PM -0500, Forrest Aldrich wrote:
> It would be useful to have back the program specification variable for
> inetd. Currently we have:
>
> inetd_enable="YES" # Run the network daemon dispatcher (or NO).
> inetd_flags="-wW" # Optional flags to inetd
>
> and the /etc/rc.* files assume the use of the stock inetd. Where some
> people choose to use alternative inetd-like programs such as xinetd.
[...]
Nice idea! And the fix is simple. The included patch will correct it :-)
[ do we really need to cross-post this? ]
- giorgos
diff -r -u etc.orig/defaults/rc.conf etc/defaults/rc.conf
--- etc.orig/defaults/rc.conf Tue Nov 7 00:59:39 2000
+++ etc/defaults/rc.confTue Nov 7 00:58:40 2000
@@ -89,6 +89,7 @@
syslogd_enable="YES" # Run syslog daemon (or NO).
syslogd_flags="-s" # Flags to syslogd (if enabled).
inetd_enable="YES" # Run the network daemon dispatcher (or NO).
+inetd_program="inetd" # path to inetd, if you don't want stock inetd
inetd_flags="-wW" # Optional flags to inetd
#
# named. It may be possible to run named in a sandbox, man security for
diff -r -u etc.orig/rc etc/rc
--- etc.orig/rc Tue Nov 7 00:59:29 2000
+++ etc/rc Tue Nov 7 00:55:27 2000
@@ -395,7 +395,10 @@
[Nn][Oo])
;;
*)
- echo -n ' inetd'; inetd ${inetd_flags}
+ if [ -x ${inetd_program:-/usr/sbin/inetd} ]; then
+ echo -n ' inetd';
+ ${inetd_program:-/usr/sbin/inetd} ${inetd_flags}
+ fi
;;
esac
Re: "panic: ffs_blkfree" in recent JPSNAP
On 2002-12-22 03:13, Andrew Boothman <[EMAIL PROTECTED]> wrote: > My 5.0-CURRENT-20021215-JPSNAP system is reliably panic-ing and > dropping into the debugger a few minutes after booting. > > I was in the process of trying to boot 5.0-RC2's installation > floppies, and the boot failed due to a faulty floppy. So I told the > loader to boot from my root partition on my HDD instead. This > produced some error messages about filesystems not being properly > dismounted (not sure if that is true...), but booted anyway. Now, > every boot from the HDD produces the panics. Try booting from your hard disk in single user mode and manually running fsck on all your filesystems. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem upgrading to -current
On 2002-12-22 17:19, walt <[EMAIL PROTECTED]> wrote: >Martin Hasenbein wrote: >> I've tried to upgrade to -current a few minutes ago. Before >> upgrading I had FreeBSD 4.7-RELEASE-p2 >> >> After a "make buildworld / make buildkernel /make installkernel" >> and rebooting, I still have FreeBSD 4.7-RELEASE-p2 > > Sounds like you are rebooting with the old kernel in the / directory > instead of the new kernel which is now in the /boot/kernel > directory. > > If you interrupt the boot loader by hitting SPACE, you can then type > 'unload' and then 'load /boot/kernel/kernel' then 'boot' which will > boot the new kernel. > > I've never done the upgrade path, so I'm not sure how you are > supposed to avoid this problem. Maybe you are doing things in the > wrong sequence or skipping steps? By editing /boot/loader.conf before rebooting and changing `bootfile' to the new location of the kernel: bootfile="/boot/kernel/kernel" you can instruct the loader to load the new kernel by default. Perhaps we should add this to the instructions of UPDATING for upgrades of 4.X to 5.X :-/ - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious issues with kqueue on sockets on CURRENT.
On 2003-01-11 00:42, Tim Robbins <[EMAIL PROTECTED]> wrote: > >From what I can tell, mbufs with m_type == MT_HEADER can store data > as well as those with m_type == MT_DATA. This patch corrects the > tests in sbcompress(), sbdrop(), sballoc() and sbfree() so that data > stored in MT_HEADER mbufs is not included in sb_ctl. I'd appreciate > comments from people who have a good understanding of this code. > > Index: sys/kern/uipc_socket2.c > === > RCS file: /x/freebsd/src/sys/kern/uipc_socket2.c,v > retrieving revision 1.106 > diff -u -r1.106 uipc_socket2.c > --- sys/kern/uipc_socket2.c 5 Nov 2002 18:52:25 - 1.106 > +++ sys/kern/uipc_socket2.c 10 Jan 2003 13:33:11 - > @@ -705,7 +705,8 @@ > (unsigned)m->m_len); > n->m_len += m->m_len; > sb->sb_cc += m->m_len; > - if (m->m_type != MT_DATA) /* XXX: Probably don't need.*/ > + if (m->m_type != MT_DATA && m->m_type != MT_HEADER) > + /* XXX: Probably don't need.*/ > sb->sb_ctl += m->m_len; Hmmm, what if the mbuf has m_type == MT_HEADER but also includes data that should be counted in sb_ctl? Or is that impossible? - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Slightly OT: Reasons to upgrade?
On 2002-12-31 09:40, Joe Laughlin <[EMAIL PROTECTED]> wrote: > Currently, I'm running STABLE on my machine, which serves as both a > desktop and a server. It seems to work great and everything. Does > everything I need it to do. > > Is there any compelling reason for me to upgrade to 5.0 next year? I've > read over the list of anticipated new features and there's nothing there > that seems needed for me. There is no "push" to upgrade. I know a couple of people here who still use FreeBSD 3.X versions regularly, because they feel more comfortable with it and have applications that they cannot easily migrate to 4.X. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken at libkvm
On 2003-01-12 20:14, [EMAIL PROTECTED] (Joe Laughlin) wrote: > walt wrote: > >cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c > >/usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o > >/usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': > >/usr/src/lib/libkvm/kvm_proc.c:376: structure has no member named > >`ke_pctcpu' > > Myself and two others have seen this as well. I'm building world trying to track the commit that broke things now. It looks like the following commit could be the one that broke things: src/sys/kern/sched_4bsd.c,v revision 1.8 date: 2003/01/12 19:04:49; author: jeff; state: Exp; lines: +30 -15 - Move ke_pctcpu and ke_cpticks into the scheduler specific datastructure. This will prevent access through mechanisms other than the published interfaces. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Date problem in ps after cvsup this morning
On 2003-01-15 09:32, [EMAIL PROTECTED] (Michael Ray) wrote: > timmy# date > Wed Jan 15 10:27:24 CST 2003 > timmy# uname -a > FreeBSD timmy.test.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Jan 15 > 09:15:45 CST 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC_SMP i386 > timmy# ps -aux > USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 11 99.0 0.0 0 12 ?? RL 31Dec69 5:55.16 (idle: cpu1) > root 12 98.6 0.0 0 12 ?? RL 31Dec69 5:55.12 (idle: cpu0) > root 1 0.0 0.1 708 396 ?? ILs 31Dec69 0:00.03 /sbin/init -- > root 13 0.0 0.0 0 12 ?? WL 31Dec69 0:01.75 (swi6: tty:sio clock) > root 15 0.0 0.0 0 12 ?? WL 31Dec69 0:00.01 (swi1: net) > root 2 0.0 0.0 0 12 ?? DL 31Dec69 0:00.09 That seems to be an older bug than today (Jan 25 2003). I have just reverted my /usr/src to "2003/01/12 18:00:00 UTC" and the bug was already there :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
On 2003-01-17 16:24, Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Fri, Jan 17, 2003 at 04:16:14PM -0800, Dag-Erling Smorgrav wrote: > > ===> vinum > > "Makefile", line 4437: warning: duplicate script for target "geom_bsd.o" [...] > > /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver i [...] > > /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': > > /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...] > > /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver i [...] > > /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is b [...] > > cc1: warnings being treated as errors > > /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': > > /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit [...] > > *** Error code 1 > > Am I the only one who thinks that the error message truncation makes > it difficult to see the error? I'm not a kernel hacker, so I might be a bit confused by this because of my lack of kernel foo, but it *is* a bit difficult to read. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some 5.0 oddities
On 2003-01-18 13:12, Andy Farkas <[EMAIL PROTECTED]> wrote: > > Some of observations of 5.0-RELEASE: > > 1/ Everytime I ssh to the box there are 4 connection attempts to UDP > port 53 from itself. ie: > > Jan 18 12:45:17 team2 kernel: Connection attempt to UDP 172.22.2.12:53 >from 172.22.2.12:49205 > Jan 18 12:45:17 team2 kernel: Connection attempt to UDP 172.22.2.12:53 >from 172.22.2.12:49206 > Jan 18 12:45:17 team2 kernel: Connection attempt to UDP 172.22.2.12:53 >from 172.22.2.12:49207 > Jan 18 12:45:17 team2 kernel: Connection attempt to UDP 172.22.2.12:53 >from 172.22.2.12:49208 > > I have log_in_vain="1" and /etc/resolv.conf points to 172.22.2.1 only. Is there any case 172.22.2.1 redirects DNS queries back to 172.22.2.22 for some subdomain that it believes 172.22.2.22 is more fit to reply for? What is the setup of 172.22.2.1? > 2/ The console doesn't "wake up" if its in screensaver mode (I use > warp_saver.ko) when messages are sent to it (like the ones above). This is a result of th following sysctl: hw.syscons.saver.keybonly: 1 It defaults to 1 so you will have to edit your /etc/sysctl.conf and set it to zero to enable the old behavior of syscons. > 3/ 'ps ul' repeats columns: PID, VSZ, RSS, TT, STAT, TIME, COMMAND > (hmm, this also happens on 4.7) I'm not sure about this one. It seems to me that "ps l" prints a lot of the information that "ps u" would print already. The repetition is most likely a ps bug though. > 4/ You can't interrupt the BTX loader anymore. Used to be able to > get the ':' prompt before the kernel loaded. I regularly interrupt my loader at any stage. Can you elaborate a bit on this one? > 5/ disklabel doesn't work: [...] ENOCLUE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some 5.0 oddities
[ Please don't strip off attributions. ] On 2003-01-18 15:33, Andy Farkas <[EMAIL PROTECTED]> wrote: > Giorgos Keramidas wrote: > > Andy Farkas wrote: > > > 5/ disklabel doesn't work: [...] > > > > ENOCLUE. As David Schultz pointed out the above part of my reply is too terse. One might think that I am saying that Andy doesn't know what he's writing about. What this *really* means is that I didn't understand his problem and/or don't know how to solve it. But I see in the rest of the thread that others have more "clues" :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-RC3 working great, but NOTES incomplete?
On 2003-01-18 21:32, Craig R <[EMAIL PROTECTED]> wrote: > I got 5.0-RC3 working great on my box today, but when I went to make > a custom kernel and read NOTES I noticed that it makes no mention of > IPFIREWALL and friends. Is this intentional? Yes, it is intentional. > craig@boss:~$ grep IPFIREWALL /sys/i386/conf/NOTES > craig@boss:~$ > > Nothing shows up. What's the scoop? NOTES have been split in ``machine independent'' and ``machine dependent'' parts. You're looking only at the MD part: $ grep 'IPFIREWALL[[:space:]]*#' /sys/conf/NOTES options IPFIREWALL #firewall $ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current- and BSD related stupid question
On 2003-01-21 02:48, Harald Schmalzbauer <[EMAIL PROTECTED]> wrote: > Hello all, > > first, I'm no programmer (perhaps this explains my obviously stupid > question) > > With 4.x I had a /etc/make.conf where I could force gcc to optimize for my > CPU with -march. > > This file (/etc/defaults/make.conf) vanished, but I can see something > similar now without any rule set. This file has been moved to /usr/share/examples/etc/make.conf some time ago. Look there and in the make.conf(5) manpage for the following variables: NO_CPU_CFLAGS NO_CPU_COPTFLAGS > Just for interest; I don't have any problems but there are quiet a > few things under 5.0 which are completely new to me and I'd like to > keep in touch with this great OS. Feel free to ask. Most of the changes from 4.X to 5.X are also listed in the release notes of 5.0-RELEASE. You can always look there first for anything interesting, then browse the docs at http://docs.freebsd.org/, then search the mailing list archives in groups.google.com, and then (of course) you can always post questions to freebsd-questions. HTH, Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mdconfig -l broken after /sys/dev/md/md.c rev 1.77
mdconfig -l stopped working in -current after revision 1.76 of md.c. I just reverted src/sys/dev/md/md.c to revision 1.76 and removed M_WAITOK to let me build a kernel with that version of md.c. Now mdconfig correctly lists the open md devices. I'm not sure if I understand how disks work, but it seems that mdconfig -l uses kern.disks to list the currently configured md devices. kern.disks seems to depend on disk_create() being called, and the current version of md.c doesn't call disk_create() when GEOM is enabled. I'm afraid I don't know how to fix this, but I hope someone more acquainted with kernel code and disks in general can do it(?) - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
On 2003-01-29 21:55, Steve Kargl <[EMAIL PROTECTED]> wrote: > On Thu, Jan 30, 2003 at 12:47:13AM -0500, Garance A Drosihn wrote: > > At 8:59 PM -0800 1/29/03, Steve Kargl wrote: > > >You don't need a special file to indicate what version of > > >FreeBSD you have. uname -r tells you. > > > > Actually, one thing I don't know is how this would work when it > > comes to RELENG_4 vs RELENG_4_0 (since I don't run RELENG_4_0). > > What does uname show for the security branches? Just wondering. > > I don't run 4.x, so I do know. ;-) > > I suspect on a 4.x system, you'll get "4.x-" where is > either FreeBSD or STABLE. 4.7-RELEASE-p1 4.7-RELEASE-p2 ... You can find the relevant script in /usr/src/sys/conf/newvers.sh - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dump -L and privilege
On 2003-01-30 15:52, Garrett Wollman <[EMAIL PROTECTED]> wrote: > < >said: > > The other alternative would be to > > create a setuid-to-root program that would take a snapshot and > > chown it to the user that does dumps. > > I think this would actually be a useful feature for more than just > dumps. I might want to allow some users (say, those in group > `operator') to be able to create snapshots on their own, without > allowing arbitrary mounting privileges. Do normal permissions apply for the files included in a snapshot? It would be horrible from a security standpoint if any user could use a setuid program to snapshot filesystems, mount the snapshot to places of their own, and read random files from the mounted snapshot. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dump -L and privilege
On 2003-01-30 17:16, Kirk McKusick <[EMAIL PROTECTED]> wrote: > If the snapshot is mounted, then the same filesystem permissions > are enforced as would be enforced for the mounted disk except > that the mount must be done read-only, so nothing in the snapshot > can be moved, deleted, or changed. Thanks! That's what I thought would be the case, but I thought I'd ask to make sure. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
On 2003-01-30 21:38, David Schultz <[EMAIL PROTECTED]> wrote: > Thus spake Mike Makonnen <[EMAIL PROTECTED]>: > > Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on > > the repository remotely, so you don't need to have the files checked out localy. > > That's a pretty good solution, and I use those occasionally. It > would be a perfect solution if there were an 'rupdate', so I don't > have to (cd /tmp; cvs co src/file/i/want.c) > && cp /tmp/src/file/i/want.c /where/i/want/it > && rm -rf /tmp/src > all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Style fixups for proc.h
On 2003-02-01 19:31, Garrett Wollman <[EMAIL PROTECTED]> wrote: > < said: > > I can't see what actual error is avoided by this warning. > > My personal opinion, which is different from what style(9) recommends, > is that parameter names should be omitted for all functions, EXCEPT > those with ambiguous parameter types. This is what I am almost inclined to agree with too. But then, headers are one of the sources of information for newbie programmers too. I have learned a lot of stuff by reading headers and not having names in any prototype would arguably make it harder to use the prototypes of functions in headers to learn things :-/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: printf....!
On 2003-02-08 16:23, David Leimbach <[EMAIL PROTECTED]> wrote: > Dave > On Saturday, February 8, 2003, at 04:12 PM, Auge Mike wrote: > >Hi all, > > > >I was trying to know how "printf" works in FreeBSD... I hvae > >reached to this point : > > > >#define _write(fd, s, n) \ > > __syscall(SYS_write, (int)(fd), (const void *)(s), (size_t)(n)) > > Isn't it ultimately interrupt 08 on the PC with an index in the EAX > register for the write "subroutine"? Interrupt 0x80. > I am pretty sure that's correct. I might have the interrupt value > wrong though. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPFilter
On 2003-02-09 20:07, Coercitas Temet'Nosce <[EMAIL PROTECTED]> wrote: > Pardon my poor knowledge about IPFW 2 but if I remember well, IPFW > wasn't a SPI Firewall, which is what I need. Btw, previous Kernel > allows us to fine tune its building for IPF and now, it simply > gone...was really wondering where those features are. What sort of fine tuning are you talking about? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel error on latest cvs src's
On 2003-02-13 18:31, Matt <[EMAIL PROTECTED]> wrote: > Trying a buildworld/buildkernel of today's latest cvs code and the > buildworld has compiled fine but the kernel is giving the error below. [...] > cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested- > externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline - > Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ - > I@/dev -I@/../include -fno-common -mno-align-long-strings -mpreferred-stack- > boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict- > prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual - > fformat-extensions -ansi -c /usr/src/sys/pci/agp_i810.c > /usr/src/sys/pci/agp_i810.c: In function `agp_i810_match': > /usr/src/sys/pci/agp_i810.c:112: `AGP_I85X_CAPID' undeclared (first use in this >function) Revert sys/pci/agp_i810.c to revision 1.16 and it will all build fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UDP connect() behavior in 5.0-CURRENT
The second volume of ``TCP/IP Illustrated'' by Stevens says that
already connected UDP sockets return EISCONN on any following
connect() attempts. Exercise 23.8 of the same book mentions that an
interesting exception are connect() calls to address 0.0.0.0, which
still return an EISCONN error, but also have the side-effect of
leaving the socket disassociated from a UDP pcb, allowing subsequent
connect() attempts to work.
Trying to reproduce the EISCONN error by running the attached program,
I couldn't. It seems that connect() returns ECONNREFUSED when it is
run on already connected sockets. If you run the program as it is
shown below, it works fine, connecting to localhost:53 and then
exiting. If you undef the #if 0 ... #endif part, it should fail with
EISCONN, but it fails with ECONNREFUSED instead :-(
= conn.c =
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MY_PROTO"udp"
int
main(void)
{
struct sockaddr_in addr;
struct protoent *pe;
struct servent *se;
int sd;
/*
* Create a UDP socket.
*/
pe = getprotobyname(MY_PROTO);
if (pe == NULL)
errx(1, "getprotobyname(%s): unknown protocol", MY_PROTO);
if ((sd = socket(PF_INET, SOCK_DGRAM, pe->p_proto)) == -1)
err(1, "socket");
/*
* When the ifdef'ed part below is uncommented, the error of the
* second connect() attempt is not EISCONN, but ECONNREFUSED, which
* is wrong.
*/
#if 0
/*
* First, connect to the UDP discard service of localhost and send at
* least one packet to it.
*/
printf("-!- Connecting to localhost:discard/%s\n", MY_PROTO);
fflush(stdout);
se = getservbyname("discard", MY_PROTO);
if (se == NULL)
errx(1, "getservbyname[discard/%s]: unknown service", MY_PROTO);
bzero((char *)&addr, sizeof(struct sockaddr_in));
addr.sin_family = PF_INET;
addr.sin_addr.s_addr = htonl(0x7f01); /* localhost */
addr.sin_port = htons(se->s_port);
if (connect(sd, (struct sockaddr *)&addr, sizeof(addr)) == -1)
err(1, "connect[%s/%s]", se->s_name, pe->p_name);
printf("-!- Sending some stuff to localhost:%s/%s\n", se->s_name,
pe->p_name);
fflush(stdout);
if (write(sd, (char *)&addr, sizeof(addr)) == -1)
err(1, "write/%s", se->s_name);
#endif
/*
* Now attempt to connect to localhost:domain (DNS).
* This should fail on connect().
*/
printf("-!- Connecting to localhost:domain/%s\n", pe->p_name);
fflush(stdout);
se = getservbyname("domain", MY_PROTO);
if (se == NULL)
errx(1, "getservbyname[domain/%s]: unknown service",
pe->p_name);
bzero((char *)&addr, sizeof(struct sockaddr_in));
addr.sin_family = PF_INET;
addr.sin_addr.s_addr = htonl(0x7f01); /* localhost */
addr.sin_port = htons(se->s_port);
if (connect(sd, (struct sockaddr *)&addr, sizeof(addr)) == -1)
err(1, "connect[%s/%s]: error %d:", se->s_name, pe->p_name,
errno);
close(sd);
return (0);
}
= end of conn.c =
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Clock disabled during DDB
On 2003-02-16 18:05, Kris Kennaway <[EMAIL PROTECTED]> wrote: > Is it an expected feature that the system clock is not updated when > the system is sitting in DDB? I just had 8 machines sitting in DDB > for about 20 minutes at boot (because of that &^@%&^ sysctl LOR), > and ntpd refused to time-sync them when I continued, because the > clock had fallen too far behind: I think I'm not the best possible person to answer this, but I recall reading posts that mentioned interrupts being disabled while in DDB. Since the system time is updated by an interrupt, it falls behind if you leave a machine in DDB for too long. Someone with more system time foo correct me if I'm wrong, please. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devastating 5.0R crash
On 2003-02-17 11:47, "Paul A. Mayer" <[EMAIL PROTECTED]> wrote: > There were some ATA complaints, (don't recall exactly what though it > was clear that there were read errors), when attempting to boot the > system off the HD. Were they "fsbn" errors? The disk that caused the following in my /var/log a few months back, died shortly after: : Nov 17 16:59:57 aeglos kernel: ad0: hard error cmd=read fsbn 11850492 of :5925246-5925249 : Nov 17 16:59:57 aeglos kernel: ad0: hard error cmd=read fsbn 11850492 of :5925246-5925249 : Nov 17 16:59:57 aeglos kernel: ad0: hard error cmd=read fsbn 5925247 so you might want to investigate the integrity of the hard disk :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPFW/socheckuid() patch
On 2003-02-18 00:02, Wiktor Niesiobedzki <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 17, 2003 at 11:47:32PM +0100, Wiktor Niesiobedzki wrote:
> There is an obvious mistake in patch (or change in ip_fw2.c should
> be considered).
> [...]
> --- sys/kern/uipc_socket.c 2003/02/17 22:37:58 1.144
> +++ sys/kern/uipc_socket.c 2003/02/17 22:56:41
> @@ -1846,8 +1846,8 @@
> {
>
> if (so == NULL)
> - return (EPERM);
> - if (so->so_cred->cr_uid == uid)
> return (0);
> - return (EPERM);
> + if (so->so_cred->cr_uid == uid)
> + return (1);
> + return (0);
> }
The rest of the uipc_socket.c functions (socreate, sobind, solisten,
soclose, soabort, ...) that return int's use zero as a "success"
value, and return errno based errors otherwise. I'm thinking if the
error is ipfw2's fault and should be fixed there. It seems slightly
preferable to me.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...
On 2003-02-19 09:14, [EMAIL PROTECTED] wrote:
> The attached patch will print a backtrace if any calls to malloc
> fail to have either M_WAITOK or M_NOWAIT. [...]
> --- kern/kern_malloc.c19 Feb 2003 05:47:25 - 1.116
> +++ kern/kern_malloc.c19 Feb 2003 07:55:19 -
> @@ -167,11 +167,21 @@
> #endif
> register struct malloc_type *ksp = type;
>
> + indx = flags & (M_WAITOK | M_NOWAIT);
> + if (indx == M_NOWAIT) {
> + /* OK */
> + } else if (indx == M_WAITOK) {
> + /* OK */
> + } else {
Or, a simpler version:
/* Either M_NOWAIT or M_WAITOK must be set. */
if (indx != M_NOWAIT && indx != M_WAITOK) {
printf("Missing M_WAITOK flag\n");
backtrace();
flags |= M_WAITOK;
}
:=)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
network stalls in top of the tree current
I've been seeing huge delays and a major drop of performance in network performace in recent -current kernels. I was wondering, has anyone else seen something similar or should I just look at other things? A typical example of what I see the past 2-3 days is: [EMAIL PROTECTED]:40]/home/giorgos$ fetchmail -a -K fetchmail: No mail for keramida at igloo.linux.gr 22 messages for keramida at diogenis.ceid.upatras.gr (85546 octets). reading message [EMAIL PROTECTED]:1 of 22 (8987 octets) flushed reading message [EMAIL PROTECTED]:2 of 22 (3230 octets) ... flushed reading message [EMAIL PROTECTED]:3 of 22 (2615 octets) .fetchmail: timeout after 60 seconds. fetchmail: socket error while fetching from diogenis.ceid.upatras.gr fetchmail: Query status=2 (SOCKET) It used to take just 2-3 seconds to get a message with fetchmail, and now it times out so often that sometimes I have to use scp to copy my mail at home. Similarly long delays often happen with scp too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP connections timing out "real fast"
On 2003-02-22 11:47, Robert Watson <[EMAIL PROTECTED]> wrote: > Maybe I'm just too impatient, but it strikes me that I used to get more > time before TCP gave up during a brief outage. FWIW, I'm seeing delays in interactive sessions, and lots of timeouts for `fetchmail -v' runs. I just started rebuilding a kernel with: % cd /usr/src/sys % cvs up -APd -D '2003-02-17 08:00 UTC' to see if I can track down the change that caused this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
BOOT2_UFS=UFS1_ONLY works for today's current
Just in case anyone tries to build today's current and sees it fail because of boot2, you can always set BOOT2_UFS=UFS1_ONLY or BOOT2_UFS=UFS2_ONLY in your make.conf and rebuild. Note that you should have at least one alternative boot method (floppy or CDROM) if you happen to accidentally use UFS1_ONLY on a ufs version-2 system or vice versa. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SSH (TCP?) lag
On 2003-02-22 20:05, Andre Guibert de Bruet <[EMAIL PROTECTED]> wrote: > > I noticed the same thing... then > > > > try sysctl net.inet.tcp.delayed_ack=0 > > > > fixed the issue > > That worked. Shouldn't this sysctl be turned off by default? Nah. Not really. Delaying acks can save quite a lot of of bandwidth for bulk data transfers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SSH (TCP?) lag
On 2003-02-22 22:49, Andre Guibert de Bruet <[EMAIL PROTECTED]> wrote: > I find myself waiting up to two seconds for data to flush to the terminal > on a 28 line 'ls -l'. net.inet.tcp.delayed_ack doesn't appear to cause > this behavior on 4.7-stable. Did we inadvertently break the 100ms clause > with the latest TCP patches? Jonathan Lemon has already posted a message that says he knows there is a bug in the recent changes. He's looking into it. To make things work without delays you should (temporarily) enable net.inet.tcp.delayed_ack=0. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: potential for foot-shooting with KLD's
On 2003-03-02 17:34, Michal Mertl <[EMAIL PROTECTED]> wrote: > Imagine you decided to go with modular kernel. You comment out 'device > random' in your kernel-config and place 'random_load="YES"' in > /boot/loader.conf. When you reboot and don't rebuild the kernel first, you > have your machine unbootable - at least in case you previously had acpi in > your kernel and acpi doesn't work without OS supplied dsdt (as in my > case) or you need acpi as a module or any other module. > > The way out is to boot from install CDROM, have fixit floppy, mount the > old root and remove the random.ko module. Which is pretty inconvenient, > when you don't have the medias handy. > > The problem is that I can't ask loader not to load some module. It doesn't > understand 'unset XX_load'. It doesn't work to say 'set XX_load="NO"' > either. The only way I found to make it not load the modules is to 'load > /boot/kernel/kernel;set module_path="";boot'. Unfortunately it doesn't > help me either because I need to load special acpi_dsdt.aml which isn't > then loaded either. How about `unset XX_load' ? - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: potential for foot-shooting with KLD's
On 2003-03-02 17:34, Michal Mertl <[EMAIL PROTECTED]> wrote: : Imagine you decided to go with modular kernel. You comment out 'device : random' in your kernel-config and place 'random_load="YES"' in : /boot/loader.conf. When you reboot and don't rebuild the kernel first, you : have your machine unbootable - at least in case you previously had acpi in : your kernel and acpi doesn't work without OS supplied dsdt (as in my : case) or you need acpi as a module or any other module. : : The way out is to boot from install CDROM, have fixit floppy, mount the : old root and remove the random.ko module. Which is pretty inconvenient, : when you don't have the medias handy. : : The problem is that I can't ask loader not to load some module. It doesn't : understand 'unset XX_load'. It doesn't work to say 'set XX_load="NO"' : either. The only way I found to make it not load the modules is to 'load : /boot/kernel/kernel;set module_path="";boot'. Unfortunately it doesn't : help me either because I need to load special acpi_dsdt.aml which isn't : then loaded either. On 2003-03-03 17:19:05, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: : : How about `unset XX_load' ? : : - Giorgos On 2003-03-04 00:41, Michal Mertl <[EMAIL PROTECTED]> wrote: : > How about `unset XX_load' ? : : It works only for acpi. I just tried editing my /boot/loader.conf to make sure you haven't hit upon a bug. I added this line: ipfw_load="YES" and rebooted. The loader loaded both /boot/kernel/kernel and ipfw.ko as you'd expect. I then used the `unload' command and loaded only my kernel afterwards: OK unload OK load /boot/kernel/kernel OK boot -s Voila! Only my kernel and acpi.ko were loaded. Then, without editing my /boot/loader.conf I rebooted and inteerrupted the loader after ipfw.ko and the kernel were loaded. I disabled ACPI with: OK unset acpi_load OK boot -s Only the kernel and ipfw.ko were loaded. Then, I tried yet another way of disabling ipfw.ko at load time, and set ipfw_load to "NO" in my loader.conf. Only the kernel and acpi.ko were loaded. What is it that troubles you? I'm not sure I can reproduce it. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent sendmail import
On 2003-03-04 12:43, Matt <[EMAIL PROTECTED]> wrote: > > Try to do following commands: > > # cd /etc/mail > > # touch *.mc > > # make cf > > # make restart > > > > then telnet localhost 25 > > Yes this sorted it. "ESMTP Sendmail 8.12.8/8.12.8". The first version number is the version of your Sendmail executable. The second is the version of your sendmail.cf file. They don't always need to be the same, although it's not a bad idea to update the cf file too after upgrades. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Tricky subversion import, what to do?
On Sun, 7 Nov 2010 14:53:29 +0100, Ulrich Spörlein wrote:
> Hello,
>
> this is about importing unifdef 2.4, which has no significant code
> changes, but that's not the point. The wiki is of no help for this
> particular case.
>
> We have no exclusive vendor branch for unifdef, instead it has been
> converted to svn under vendor/CSRG/dist/usr.bin/unifdef/ and some
> parts of its history (eg. r1591) are copied from there:
>
>A /head/usr.bin/unifdef/Makefile (from
> /vendor/CSRG/dist/usr.bin/unifdef/Makefile:1590)
>A /head/usr.bin/unifdef/unifdef.1 (from
> /vendor/CSRG/dist/usr.bin/unifdef/unifdef.1:1590)
>A /head/usr.bin/unifdef/unifdef.c (from
> /vendor/CSRG/dist/usr.bin/unifdef/unifdef.c:1590)
>
> So, my first instinct would be to
>
> $ svn mv $FSVN/vendor/CSRG/dist/usr.bin/unifdef $FSVN/vendor/unifdef/dist
> (put all files (or just the necessary subset?) of unifdef-2.4 in
> vendor/unifdef/dist)
> $ svn ci
> $ svn cp $FSVN/vendor/unifdef/dist $FSVN/vendor/unifdef/2.4
> $ svn cp $FSVN/vendor/unifdef/dist/unifdef.{c,1} $FSVN/head/contrib/unifdef/
> $ svn rm head/usr.bin/unifdef/unifdef.{c,1}
> (but this part loses the actual history on head, as it was never
> committed to the vendor branch)
> (update usr.bin/unidef/Makefile to point to contrib/unifdef)
> $ svn ci
>
> But then again, the first steps could also be:
> $ svn cp head/usr.bin/unifdef vendor/unifdef/dist; svn ci
> $ svn cp vendor/unifdef/dist vendor/unifdef/2.3; svn ci
>
> This seems more reasonable to me, but I'm not sure what the policy is on
> "old stuff" under vendor/
I think it all depends on how "valuable" the merge history from
/vendor/CSRG/dist/usr.bin/unifdef to /vendor/unifdef/dist is. IMO it
isn't, because we won't be merging from the CSRG code anymore.
So I'd prefer the second option.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shared lib issue in /usr/obj?
On Thu, 09 Dec 2010 07:38:38 -0500, Etienne Robillard wrote: > Hi > > $ sudo rm -rf /usr/obj/* > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libc.so.7: Operation > not permitted > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libcrypt.so.5: > Operation not permitted > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/libthr.so.3: > Operation not permitted > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/librt.so.1: > Operation not permitted > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32: Directory not empty > rm: /usr/obj/usr/local/freebsd8/src/lib32/usr: Directory not empty > rm: /usr/obj/usr/local/freebsd8/src/lib32: Directory not empty > rm: /usr/obj/usr/local/freebsd8/src: Directory not empty > rm: /usr/obj/usr/local/freebsd8: Directory not empty > rm: /usr/obj/usr/local: Directory not empty > rm: /usr/obj/usr: Directory not empty > $ uname -a > FreeBSD marina 8.1-STABLE FreeBSD 8.1-STABLE #1: Sun Nov 21 00:48:28 EST > 2010 root@:/usbj/usr/local/freebsd8/src/sys/GENERIC.ndebug amd64 > > Is this a corrupted obj directory ? If so, why should theses libs have > the schg flag enabled? > $ sudo ls -lao /usr/obj/usr/local/freebsd8/src/lib32/usr/lib32/ > total 2520 > drwxr-xr-x 2 root wheel - 12288 Dec 9 07:24 . > drwxr-xr-x 3 root wheel -512 Dec 9 07:25 .. > -r--r--r-- 1 root wheel schg 1128116 Nov 21 02:15 libc.so.7 > -r--r--r-- 1 root wheel schg 32060 Nov 21 02:18 libcrypt.so.5 > -r--r--r-- 1 root wheel schg 16444 Nov 21 02:27 librt.so.1 > -r--r--r-- 1 root wheel schg 76668 Nov 21 02:19 libthr.so.3 They are installed with "make install" and when you run "make install" with PRECIOUSLIB defined, bsd.lib.mk adds this to SHINSTALLFLAGS: .if defined(PRECIOUSLIB) .if !defined(NO_FSCHG) SHLINSTALLFLAGS+= -fschg .endif SHLINSTALLFLAGS+= -S .endif The Makefiles that set PRECIOUSLIB today are: keram...@bokos:/usr/src$ grep -r 'PRECIOUSLIB.*=' * lib/libc/Makefile:PRECIOUSLIB= lib/libcrypt/Makefile:PRECIOUSLIB= lib/libkse/Makefile:PRECIOUSLIB= lib/librt/Makefile:PRECIOUSLIB= lib/libthr/Makefile:PRECIOUSLIB= keram...@bokos:/usr/src$ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shared lib issue in /usr/obj?
On Thu, 9 Dec 2010 15:15:02 +0200, Kostik Belousov wrote:
> On Thu, Dec 09, 2010 at 01:57:16PM +0100, Giorgos Keramidas wrote:
>> They are installed with "make install" and when you run "make install"
>> with PRECIOUSLIB defined, bsd.lib.mk adds this to SHINSTALLFLAGS:
>>
>> .if defined(PRECIOUSLIB)
>> .if !defined(NO_FSCHG)
>> SHLINSTALLFLAGS+= -fschg
>> .endif
>> SHLINSTALLFLAGS+= -S
>> .endif
>>
>> The Makefiles that set PRECIOUSLIB today are:
>>
>> keram...@bokos:/usr/src$ grep -r 'PRECIOUSLIB.*=' *
>> lib/libc/Makefile:PRECIOUSLIB=
>> lib/libcrypt/Makefile:PRECIOUSLIB=
>> lib/libkse/Makefile:PRECIOUSLIB=
>> lib/librt/Makefile:PRECIOUSLIB=
>> lib/libthr/Makefile:PRECIOUSLIB=
>> keram...@bokos:/usr/src$
>
> Would be nice if lib32 installation into the obj/ area somehow
> eliminated the setting of schg flag. There is no reason to have schg
> set on files in obj.
Yes, that's a good idea.
I don't have root access to an amd64 system to test this now, but I
think all we need to change is:
%%%
$ hg diff .
diff -r e52d3f3de04d Makefile.inc1
--- a/Makefile.inc1 Thu Dec 09 12:35:12 2010 +0100
+++ b/Makefile.inc1 Thu Dec 09 14:50:06 2010 +0100
@@ -318,7 +318,8 @@ LIB32WMAKEENV+= MAKEOBJDIRPREFIX=${OBJTR
CXX="${CXX} ${LIB32FLAGS}" \
OBJC="${OBJC} ${LIB32FLAGS}" \
LIBDIR=/usr/lib32 \
- SHLIBDIR=/usr/lib32
+ SHLIBDIR=/usr/lib32 \
+ NO_FSCHG=''
LIB32WMAKE=${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \
-DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \
$
%%%
This should strip the -fschg option from lib32's installation commands.
pgproqk5eGSn7.pgp
Description: PGP signature
Re: shared lib issue in /usr/obj?
On Thu, 9 Dec 2010 10:01:32 -0500, John Baldwin wrote:
>> I don't have root access to an amd64 system to test this now, but I
>> think all we need to change is:
>>
>> %%%
>> $ hg diff .
>> diff -r e52d3f3de04d Makefile.inc1
>> --- a/Makefile.inc1 Thu Dec 09 12:35:12 2010 +0100
>> +++ b/Makefile.inc1 Thu Dec 09 14:50:06 2010 +0100
>> @@ -318,7 +318,8 @@ LIB32WMAKEENV+= MAKEOBJDIRPREFIX=${OBJTR
>> CXX="${CXX} ${LIB32FLAGS}" \
>> OBJC="${OBJC} ${LIB32FLAGS}" \
>> LIBDIR=/usr/lib32 \
>> - SHLIBDIR=/usr/lib32
>> + SHLIBDIR=/usr/lib32 \
>> + NO_FSCHG=''
>>
>> LIB32WMAKE=${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \
>> -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \
>> $
>> %%%
>>
>> This should strip the -fschg option from lib32's installation commands.
>
> Does that affect the installed versions of the libraries in
> /usr/lib32? Those should probably have schg set.
I think it does. I'll have to rethink a bit about the best way to avoid
schg for lib32 but only during buildworld.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Buildworld failure
On Wed, 22 Dec 2010 19:29:39 -0500, Derek Tattersall wrote: > I blew away /usr/src and /usr/obj and re-cvsuped this morning. I > attempted to buildworld, only to have the process die in the mkdep step. > > CC='clang' mkdep -f .depend -a > -I/usr/src/cddl/usr.bin/ctfmerge/../../../sys/cddl/compat/opensolaris > -I/usr/src/cddl/usr.bin/ctfmerge/../../../cddl/compat/opensolaris/include [...] > -DNEED_SOLARIS_BOOLEAN -I/usr/obj/usr/src/tmp/legacy/usr/include [...] > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/util.c > In file included from > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/barrier.c:46: > /usr/src/cddl/usr.bin/ctfmerge/../../../cddl/contrib/opensolaris/tools/ctf/cvt/barrier.h:39:10: > fatal error: 'semaphore.h' file not found > #include > ^ > 1 error generated. > mkdep: compile failed Which branch is this? When was it last updated? I see that you are using CC='clang', so my guess is you are building CURRENT, right? If that's the case, can you try: - building without CC='clang', to see if the breakage is clang's fault - if that fails, resync your CURRENT source and retry NOTE: I did build a snapshot from /head at -r 216642 last afternoon and it worked fine with the default CC. So if something broke *after* that revision try bisecting from -r 216642 to the version you built, to see if there's something that broke the build in-between. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Buildworld failure
On Thu, 23 Dec 2010 08:05:16 -0500, Derek Tattersall wrote: >> NOTE: I did build a snapshot from /head at -r 216642 last afternoon and >> it worked fine with the default CC. So if something broke *after* that >> revision try bisecting from -r 216642 to the version you built, to see >> if there's something that broke the build in-between. > > This is using CURRENT, cvsup'ed Wednesday. The same failure occurs > with clang and with gcc. I note that there have been several changes > in the recent past in the obsolete files list regarding semaphore.h. > I will try again, blowing away both /usr/src and /usr/obj and see if > that has any effect. Bisection will have to wait until next week. It may be related to a stale /usr/obj tree. My daily build finished earlier from svn rev 216678, but I *did* wipe my /usr/obj tree and build a GENERIC kernel & userland from a new checkout of src/. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on amd64/amd64
On Mon, 24 Jan 2011 19:19:46 +0100, "Simon L. B. Nielsen" wrote: >On 24 Jan 2011, at 06:16, Peter Jeremy wrote: >> in which case syncing directly off the SVN master would seem a better >> approach. > > Better yes, but that's not a simple configuration change like switching > to using cvsup-master is, and unfortunately I have plenty of more > interesting projects than changing tinderbox code :-). The current tinderbox *can* check out sources from svn. It may be pointed to the http://svn.freebsd.org/base/ webdav source and it should work fine (for some value of 'should' and 'fine'). Verifying that this still works correctly is still a bit of work though, but it's a medium-to-small project for someone with tinderbox foo. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] removing broken includes
On Fri, 4 Feb 2011 20:19:48 +, Alexander Best wrote:
>On Fri Feb 4 11, John Baldwin wrote:
>>On Thursday, February 03, 2011 5:12:57 pm Alexander Best wrote:
>>> hi everybody,
>>> i've started to check the source for broken includes, such as the one fixed
>>> in
>>> r218189. so far i've run through arch=amd64 and found only two broken
>>> includes,
>>> which should be fixed by the attached patch. the commands i'm using are:
>>
>> The sys/conf/files fix should definitely go in.
>
> as a side note: while checking the tinderbox output i saw a few gas related
> warnings, which complained about VCS IDs being spammed to object files.
Maybe it's intentional for these objects to _have_ the VCS id in them,
like some of the "@(#)" strings that are passed down to the ELF binary.
This sort of object data is often used to determine what bits have gone
into the binary, so we should check if they are intentional before
ifdef'ing them all out.
% Index: sbin/routed/rtquery/rtquery.c
% ===
% --- sbin/routed/rtquery/rtquery.c (revision 218217)
% +++ sbin/routed/rtquery/rtquery.c (working copy)
% @@ -49,6 +49,7 @@
% #include
% #endif
%
% +#if 0
% #define UNUSED __attribute__((unused))
% #ifndef __RCSID
% #define __RCSID(_s) static const char rcsid[] UNUSED = _s
% @@ -67,6 +68,7 @@
% __RCSID("$Revision: 2.26 $");
% #ident "$Revision: 2.26 $"
% #endif
% +#endif
We can avoid this by building rtquery.c with -D NO__RCSID. See below
for the same trick about lukemftpd...
% #ifndef sgi
% #define _HAVE_SIN_LEN
% Index: contrib/lukemftp/src/main.c
% ===
% --- contrib/lukemftp/src/main.c (revision 218217)
% +++ contrib/lukemftp/src/main.c (working copy)
% @@ -96,8 +96,10 @@
%
% #include
% #ifndef lint
% +#if 0
% __COPYRIGHT("@(#) Copyright (c) 1985, 1989, 1993, 1994\n\
% The Regents of the University of California. All rights
reserved.\n");
% +#endif
% #endif /* not lint */
This looks 'harmless' to include in the resulting binary, but maybe we
should just define NO_COPYRIGHT while building lukemftp? This will
disable the spamming of the object code with the static string and we
don't have to modify vendor code at all.
So, how about this instead?
% diff -r bd0305f6cb2b libexec/lukemftpd/Makefile
% --- a/libexec/lukemftpd/MakefileSat Feb 05 02:39:55 2011 +0100
% +++ b/libexec/lukemftpd/MakefileSat Feb 05 22:28:12 2011 +0100
% @@ -13,6 +13,7 @@ SRCS= cmds.c conf.c ftpd.c ftpcmd.y pope
% SRCS+= strsuftoll.c
%
% WFORMAT= 0
% +CFLAGS+= -DNO_COPYRIGHT
%
% .if ${MK_INET6_SUPPORT} != "no"
% CFLAGS+= -DINET6
> also i noticed a lot of these warnings:
>
> usr/subversion-src/lib/libc/i386/string/memcpy.S:7: Warning: ignoring
> incorrect section type for .note.GNU-stack
>
> i think i've seen some recent commits dealing with that new section.
That looks like something more useful to fix now, rather than later.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 5.1 stability
On 2003-10-15 11:01, Martin Minkus <[EMAIL PROTECTED]> wrote: > Keep up the good work people! :) > Martin. > > diablo:~> uname -a > FreeBSD diablo.diskiller.net 5.1-CURRENT FreeBSD 5.1-CURRENT #5: Thu Jun > 12 20:19:23 CST 2003 > [EMAIL PROTECTED]:/junk/src/sys/i386/compile/DIABLO i386 > diablo:~> uptime > 10:21AM up 101 days, 17:12, 1 user, load averages: 0.33, 0.58, 0.44 > diablo:~> date > Wed Oct 15 10:21:40 CST 2003 > diablo:~> Heh, nice uptime. Upgrading to a more recent -CURRENT shouldn't be too hard too. Last night before, after a long absense from home, I upgraded a 5.1 installation from Jun 15 to the latest -CURRENT. Everything was smooth and worked fine -- both during and after the installation :) Me thanks the developers too. - Giorgos ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SYSCTL_XXX(9) manual page deficiency
On Wed, 21 Apr 2010 13:10:23 -0700, Maxim Sobolev wrote: > Hi, > > According to the manual page for the SYSCTL_XXX(9) family of > functions, in order to use them one needs to include sys/types.h and > sys/sysctl.h. However, if you do just that the code doesn't compile > due to missing DATA_SET() macros, which is defined in > sys/linker_set.h. My question is whether or not sysctl.h should > include sys/linker_set.h or manual page to be extended to also > suggests that this include is required to use those functions? linker_set.h is a relatively small header that defines only a minimal amount of macros in the public namespace. Some of these symbols are a bit generic, e.g. SET_BEGIN, SET_END, SET_ENTRY, SET_FOREACH and SET_ITEM might conflict with symbol names from other code. On the other hand, the XXX_SET() code is only visible at the end of the SYSCTL_XXX() macros only for kernel code, and it has been there for a *very* long time: since phk committed revision 11863 in 1995. If there ever was a consumer of the kernel API of sysctl.h who had problems with the generic XXX_SET() macros in linker_set.h we'd probably know by now. IMO adding linker_set.h to sysctl.h is fine. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Running all regression tests
> It seems the p5-Test-Harness may be too simple for our > requirements. Has anyone looked into using NetBSD's ATF > (http://www.netbsd.org/~jmmv/atf/) in FreeBSD? I am not sure if it makes sense to import ATF into the *base* system, but it sure looks like a nice ports/ addition. The work of writing the actual test code is then going to be a bit of extra work on top of that, but we can start doing it in small "mini-project chunks". I already have a few tests that I would love to convert to something more modular like ATF: : keram...@kobe:/hg/bsd/src$ hg qseries -s | fgrep regression : regression-chmod: Add a few regression tests for chmod(1) : regression-stdtime: Add a regression suite for libc/stdtime functions : keram...@kobe:/hg/bsd/src$ If anyone is already working on an ATF package/port, I'm very interested to help. pgpC3a5C5aDmX.pgp Description: PGP signature
