Re: Serious issues with kqueue on sockets on CURRENT.
On Sat, 11 Jan 2003, Trish Lynch wrote:
> On Sat, 11 Jan 2003, Daniel C. Sobral wrote:
>
> > Peter, reverting the revisions below *does* fix the problem. Tim has an
> > alternative patch, though. At any rate, it seems kbyanc's solution was
> > overly simplistic. But things are broken either way, and I'm not sure
> > Tim's patch doesn't result in the kind of situation rev 1.134 tried to
> > fix, nor if his patch actually gets all cases of the bug that results
> > from 1.134.
> >
> > At any rate, I think that not receiving any event (after 1.134) is worse
> > than receiving and event claim to have more bytes than are actually
> > available (pre 1.134). It's not just Juli who have this problem.
> > AilleCat, for instance, once she heard on irc that kq had a problem,
> > tracked the problem *she* was having to the same place.
> >
>
> Yes, this is correct, some events weren't being triggered and now, with
> reverting back (with some of the current changes like the aesthetic change
> to soo_kqfilter instead of sokqfilter,) now our application that relies
> upon kqueue for scheduling runs about twice as fast
>
> Maxim gave me a patch that accomplishes exactly what I did by hand... but
> it also leaves it in a state that it was before 1.134 where there were
> some problems that were supposed to be fixed in 1.134 and after... however
> IMO its *less* broken :)
>
> Anyway, since my understanding of this is much less than anyone else I'm
> inclined to go with whatever solution actually makes the events trigger
> for us :)
>
> I'm not a kernel programmer, nor will I ever be, I just know that
> reverting uipc_socket.c did solve some major problems I was having :)
>
> -Trish
>
I'm sorry, I'm afraid I am not familiar with the issue being discussed. Is
there a PR I can reference for more information? Exactly what events aren't
being received? Being as the logic for when to return a kevent as of
uipc_socket.c:1.136 is exactly the same as before (just the data value in the
kevent is different), I can't see how any events could *not* be returned that
weren't returned before. But then again, without knowing the symptoms you are
seeing, I can't say for sure.
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Visit the BSD driver database: http://www.posi.net/freebsd/drivers/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Can't resolve hosts via dns on the command line with latest-current
On Tue, 5 Nov 2002, Giorgos Keramidas wrote:
> On 2002-11-04 18:38, Kelly Yancey <[EMAIL PROTECTED]> wrote:
> > Thanks for the info. Are you sure that you only reverted the one delta?
>
> Yes. I just recompiled the kernel from -rHEAD and started logging
> things while I connected to my dialup provider. Apparently lo0 does
> have the 127.0.0.1 address *and* the LOOPBACK flag but somehow fails.
>
> When (near the end of the following log) I back only this change out,
> the problems go away :/
>
Thanks for the great trace and your patience. I believe I found the root of
the problem. Could you please try the attached patch? I'm afraid that
if I hadn't gotten thown off this morning be my lo0 lacking a
127.0.0.1 address I probably would have found it much, much sooner
(it's pretty obvious in hindsight). At the very least, I also caught a
couple of pieces of code that are manipulating the socket buffer behind
sballoc() and sbfree()'s back so I've modified them to update the sb_cc
counter directly also.
Let me know if this fixes things for you. Thanks,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
"Democracy is a device that insures we shall be governed no better than we
deserve." -- George Bernard Shaw
Index: kern/uipc_socket.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.135
diff -u -p -r1.135 uipc_socket.c
--- kern/uipc_socket.c 2 Nov 2002 05:14:30 - 1.135
+++ kern/uipc_socket.c 5 Nov 2002 04:14:20 -
@@ -1794,7 +1794,7 @@ filt_soread(struct knote *kn, long hint)
return (1);
if (kn->kn_sfflags & NOTE_LOWAT)
return (kn->kn_data >= kn->kn_sdata);
- return (kn->kn_data >= so->so_rcv.sb_lowat);
+ return (so->so_rcv.sb_cc >= so->so_rcv.sb_lowat);
}
static void
Index: kern/uipc_socket2.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.105
diff -u -p -r1.105 uipc_socket2.c
--- kern/uipc_socket2.c 2 Nov 2002 05:14:30 - 1.105
+++ kern/uipc_socket2.c 5 Nov 2002 04:19:05 -
@@ -705,6 +705,8 @@ sbcompress(sb, m, n)
(unsigned)m->m_len);
n->m_len += m->m_len;
sb->sb_cc += m->m_len;
+ if (m->m_type != MT_DATA)
+ sb->sb_ctl += m->m_len;
m = m_free(m);
continue;
}
@@ -774,6 +776,8 @@ sbdrop(sb, len)
m->m_len -= len;
m->m_data += len;
sb->sb_cc -= len;
+ if (m->m_type != MT_DATA)
+ sb->sb_ctl -= len;
break;
}
len -= m->m_len;
Re: Can't resolve hosts via dns on the command line with latest-current
On Mon, 4 Nov 2002, David O'Brien wrote:
> On Mon, Nov 04, 2002 at 05:47:39PM -0800, Kelly Yancey wrote:
> > > A better question is why you are fixing a non-critical, over-1-year-old
> > > bug in networking code this close to the release??? Networking is our
> > > bread and butter, and changes to it can be tricky. A known non-critical
> > > bug that has existed at least since FBSD 4.2 is better than an unknown
> > > one. At this point it time, it is better to just not touch things.
> >
> > I'm not trying to fix a bug in ancient code. I'm trying to track down a
> > very specific bug that is reported to be related to a commit I made last
> > week. However, so far, I have not found how the two are related. I've just
> > been trying to keep the people who are affected by the bug in the loop while
>
> I was speaking of your commit last week to uipc_socket.c:
>
> revision 1.134
> date: 2002-11-01 21:27:59; author: kbyanc; state: Exp; lines: +1 -1
> ...
> PR: 30634
>
>
> PR 30634 is over a year old and is classified as non-critical.
>
It was important to me. I ran into the problem independently and have been
running the committed patches for 2 weeks on multiple machines. However, none
of the machines made UDP connections via lo0 so I didn't spot the bug before
commit. However, since commit I have seen 4 reports of people having trouble
resolving via localhost, 2 of which claim the backing out the commit solves
their problems. I'm actively tracking it down (as my numerous updates
throughout the day should indicate) and if I don't find the problem soon I
will revert the delta in question. This is code we use at work and I
certainly want to fix the bug if it turns out to be related to my commit.
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Can't resolve hosts via dns on the command line with latest-current
On Tue, 5 Nov 2002, Giorgos Keramidas wrote:
> On 2002-11-04 10:45, Kelly Yancey <[EMAIL PROTECTED]> wrote:
> > On Mon, 4 Nov 2002, Giorgos Keramidas wrote:
> > > True. I had been seeing problems with network connections the last
> > > days, and was already in the process of backing out changes one by one
> > > when I saw this. Reverting 1.134 fixes things here. If I put it back
> > > in, strange DNS failures start causing troubles with almost everything
> > > (including Sendmail, fetchmail, ssh).
> >
> > I've had this running on multiple machines for weeks without
> > problems. What is your resolve.conf and nsswitch.conf? Curious,
>
> I am running a local named that listens on { 127.0.0.1; }.
>
> My nsswitch.conf contains:
>
> hosts: files dns
>
> and resolv.conf is:
>
> search sea.gr freebsd.org irc.gr ceid.upatras.gr
> nameserver 127.0.0.1
>
> The curious thing is that Sendmail or ssh fail to look up hostnames,
> while running host(1) works. I don't know if this is of any help, but
> if you need more data about the local setup let me know.
>
> Thanks for looking into this,
> Giorgos.
>
Thanks for the info. Are you sure that you only reverted the one delta?
Oddly, when I do the same I still have trouble resolving via localhost (i.e.
with or without revision 1.134). I can only get DNS via localhost working
again by explicitely adding 127.0.0.1 to lo0.
If anything I suspect that something is preventing 127.0.0.1 from being
assigned to lo0 at boot (maybe my commit, but I don't see how). But again,
I'm still looking into it. :|
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Visit the BSD driver database: http://www.posi.net/freebsd/drivers/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Can't resolve hosts via dns on the command line with latest-current
On Mon, 4 Nov 2002, David O'Brien wrote:
> On Mon, Nov 04, 2002 at 10:45:42AM -0800, Kelly Yancey wrote:
> > On Mon, 4 Nov 2002, Giorgos Keramidas wrote:
> >
> > > On 2002-11-04 01:16, Hidetoshi Shimokawa <[EMAIL PROTECTED]> wrote:
> > > > I have the same problem and reverting rev. 1.134 of
> > > > /sys/kern/uipc_socket.c fixes the problem.
> > > > The change might have something wrong with a loopback interface.
> ...
> > I've had this running on multiple machines for weeks without problems. What
> > is your resolve.conf and nsswitch.conf? Curious,
>
> A better question is why you are fixing a non-critical, over-1-year-old
> bug in networking code this close to the release??? Networking is our
> bread and butter, and changes to it can be tricky. A known non-critical
> bug that has existed at least since FBSD 4.2 is better than an unknown
> one. At this point it time, it is better to just not touch things.
>
I'm not trying to fix a bug in ancient code. I'm trying to track down a
very specific bug that is reported to be related to a commit I made last
week. However, so far, I have not found how the two are related. I've just
been trying to keep the people who are affected by the bug in the loop while
I'm tracking it down.
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Can't resolve hosts via dns on the command line with latest-current
On Mon, 4 Nov 2002, Terry Lambert wrote:
> Kelly Yancey wrote:
> > It doesn't matter. It isn't just DNS lookups, mountd fails to run too
> > because it cannot connect to portmap via localhost. Oddly, in both cases
> > sendto() is returning with errno = 49 (EADDRNOTAVAIL). I've tracked it down
> > to this code in sys/netinet/ip_output.c:
> >
> > /* 127/8 must not appear on wire - RFC1122. */
> > if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET ||
> > (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) {
> > if ((ifp->if_flags & IFF_LOOPBACK) == 0) {
> > ipstat.ips_badaddr++;
> > error = EADDRNOTAVAIL;
> > goto bad;
> > }
> > }
> >
> > Which was last modified in revision 1.150 back in February. However, I
> > still don't see how adding an extra counter to the sockbuf could possibly
> > change the set of events required to get to this code, but it is certainly
> > what is causing EADDRNOTAVAIL to be returned. Needless to say, I'm still
> > researching it.
>
> Pretty clear, I should think:
>
> IF the source address is a loopback address
> OR the destination address is a loopback address
> THEN
> IF the interface does not have the IFF_LOOBACK flag
> return EADDRNOTAVAIL
>
> ...pretty clearly, the new loopback interface doe not set the flag
> IFF_LOOPBACK on the interface, as it is supposed to do.
>
> -- Terry
>
No, it turns out I'm an idiot: somehow the address on loopback got deleted
so it was trying to use my default route. So I was on a wild goose chase. :|
Oddly enough, though, once I re-added 127.0.0.1/8 to my localhost:
# cat resolv.conf
search nttmcl.com
nameserver 127.0.0.1
# ps auwwwx | grep named
root 320 0.0 0.8 2600 2160 ?? Is5:11PM 0:00.03 named
# ping www.freebsd.org
PING www.freebsd.org (216.136.204.117): 56 data bytes
64 bytes from 216.136.204.117: icmp_seq=0 ttl=50 time=16.343 ms
64 bytes from 216.136.204.117: icmp_seq=1 ttl=50 time=8.764 ms
^C
--- www.freebsd.org ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 8.764/12.553/16.343/3.789 ms
# ping www.yahoo.com
Go figure. I've said it before and I'll say it again...I'm working on it.
:|
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
"Though [the people] may acquiesce, they cannot approve what they do not
understand." --Thomas Jefferson, 1792.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Can't resolve hosts via dns on the command line with latest-current
On Mon, 4 Nov 2002, Terry Lambert wrote:
> Kelly Yancey wrote:
> > I suspect something in lib/libc/net/res_send.c is using special knowledge of
> > the contents of the socket buffer so calculate the real amount of data that
> > can be read (which this patch does automatically). I'm looking into it.
>
> ...To ensure that the read does not block, and is not issued
> until sufficient data exists.
>
> -- Terry
>
It doesn't matter. It isn't just DNS lookups, mountd fails to run too
because it cannot connect to portmap via localhost. Oddly, in both cases
sendto() is returning with errno = 49 (EADDRNOTAVAIL). I've tracked it down
to this code in sys/netinet/ip_output.c:
/* 127/8 must not appear on wire - RFC1122. */
if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET ||
(ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) {
if ((ifp->if_flags & IFF_LOOPBACK) == 0) {
ipstat.ips_badaddr++;
error = EADDRNOTAVAIL;
goto bad;
}
}
Which was last modified in revision 1.150 back in February. However, I
still don't see how adding an extra counter to the sockbuf could possibly
change the set of events required to get to this code, but it is certainly
what is causing EADDRNOTAVAIL to be returned. Needless to say, I'm still
researching it.
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
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: Can't resolve hosts via dns on the command line with latest-current
On Sun, 3 Nov 2002, Doug Barton wrote:
> On Mon, 4 Nov 2002, Hidetoshi Shimokawa wrote:
>
> > I have the same problem and reverting rev. 1.134 of
> > /sys/kern/uipc_socket.c fixes the problem.
>
> Confirmed here too, thanks for the tip. I had looked over the recent
> commits to /etc/lib/*, but none of them looked guilty.
>
> Doug
>
>
Ah, I'm able to recreate the problem now. It is odd that it only occurs on
loopback, but it doesn't appear specific to DNS. :| I'm on it. Thanks,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
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: Can't resolve hosts via dns on the command line with latest-current
On Mon, 4 Nov 2002, Hidetoshi Shimokawa wrote:
> I have the same problem and reverting rev. 1.134 of
> /sys/kern/uipc_socket.c fixes the problem.
> The change might have something wrong with a loopback interface.
>
> /\ Hidetoshi Shimokawa
> \/ [EMAIL PROTECTED]
> PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html
>
> Index: uipc_socket.c
> ===
> RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.135
> diff -u -r1.135 uipc_socket.c
> --- uipc_socket.c 2 Nov 2002 05:14:30 - 1.135
> +++ uipc_socket.c 3 Nov 2002 14:45:16 -
> @@ -1784,7 +1784,11 @@
> {
> struct socket *so = (struct socket *)kn->kn_fp->f_data;
>
> +#if 0
> kn->kn_data = so->so_rcv.sb_cc - so->so_rcv.sb_ctl;
> +#else
> + kn->kn_data = so->so_rcv.sb_cc;
> +#endif
> if (so->so_state & SS_CANTRCVMORE) {
> kn->kn_flags |= EV_EOF;
> kn->kn_fflags = so->so_error;
>
I suspect something in lib/libc/net/res_send.c is using special knowledge of
the contents of the socket buffer so calculate the real amount of data that
can be read (which this patch does automatically). I'm looking into it.
>
> At Sun, 03 Nov 2002 05:39:48 -0800,
> Doug Barton wrote:
> >
> > Howdy,
> >
> > With -current built from sources updated at around 8pm PST, I can't
> > resolve hosts on the command line if /etc/resolv.conf points to a name
> > server running on the local host. The local name server itself is
> > working fine, and I can reach any host in /etc/hosts as well.
> >
> > ktrace /sbin/ping hub.freebsd.org
> > ^C
> >
> > kdump
> >651 ktrace RET ktrace 0
> >651 ktrace CALL execve(0xbfbffb03,0xbfbff9e4,0xbfbff9f0)
> >651 ktrace NAMI "/sbin/ping"
> >
What is this supposed to demonstrate?
> > /etc/nsswitch.conf is unchanged, and contains only:
> > hosts: files dns
> >
> > It doesn't matter if /etc/resolv.conf points to 127.0.0.1, or the IP of
> > the box. As soon as I point /etc/resolv.conf at a name server on another
> > host, it works.
> >
> > My -current system from last weekend worked just fine.
> >
> > Doug
> >
Thanks. I'll let you know what I find,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
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: Can't resolve hosts via dns on the command line with latest-current
On Mon, 4 Nov 2002, Giorgos Keramidas wrote:
> On 2002-11-04 01:16, Hidetoshi Shimokawa <[EMAIL PROTECTED]> wrote:
> > I have the same problem and reverting rev. 1.134 of
> > /sys/kern/uipc_socket.c fixes the problem.
> > The change might have something wrong with a loopback interface.
>
> True. I had been seeing problems with network connections the last
> days, and was already in the process of backing out changes one by one
> when I saw this. Reverting 1.134 fixes things here. If I put it back
> in, strange DNS failures start causing troubles with almost everything
> (including Sendmail, fetchmail, ssh).
>
> Giorgos.
>
I've had this running on multiple machines for weeks without problems. What
is your resolve.conf and nsswitch.conf? Curious,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d & things...
On Mon, 10 Jul 2000, Mikel wrote: > > Kelly Yancey wrote: > > > > > How about rather then separate directories, you prefix the symlink names > > with 'S' for startup scripts and 'K' (for "kill") for shutdown scripts. Then, > > you rename rc.d to rc3.d... > > I like it. It's clean and simple, almost to the point of being elegant. But why > bother adding rc?.d if you are going to right it to handle s or k then the present > home should be fine, no? > It was a reference to how SysV organized it's rc scripts. SysV implements 'run-levels' for which there is a rcX.d for each run-level. The startup/shutdown scripts for a run-level are executed at transitions between levels. In any event, it was a poor attempt at humor on my part. Don't go down this road, read the archives to see why (search for init and runlevels). Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
teaching libutil about home directories
PR 19755 seeks to teach nologin(8) to look for .nologin files in a user's home directory. However, I feel that such knowledge is better obtained via the nologin capability in login.conf. Basically, file and program capabilities should perform tilde expansion. Libutil already does tilde-expansion for path capabilities, although the implemention would certainly be different for files/programs. The problem is that the libutil interface does not differentiate between strings, files, and programs. User-land utilities call login_getcapstr() to get capabilitiy values for any of these types. What would be needed is a separate interface, login_getcapfile, specifically for files/programs. Unfortunately, this would then require modifying all user-land utilities to use the new interface. Is this acceptable? Is so, I'll have patches together for review shortly. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d & things...
On Sat, 8 Jul 2000, Mike Meyer wrote: > > By all means, use start/stop args, but hard link the .sh files into seperate > > directories or something so that the order can be tweaked.. > > If all you want is to make sure that shutdown happens in the reverse > order of startup, that can be done by reversing the list in > rc.shutdown. But how about going a step further, and starting towards > a user-friendly configuration process? > > Instead of being globbed at init time, etc/rc.d is a repository for > things that take start/stop arguments. They are symlinked to > /etc/init.d with numeric prefixes to control order at initialization > time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) > with numeric prefixes to control order at shutdown time. > How about rather then separate directories, you prefix the symlink names with 'S' for startup scripts and 'K' (for "kill") for shutdown scripts. Then, you rename rc.d to rc3.d... Ducks and runs, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible bug in netinet6/in6_rmx.c ?
On Tue, 4 Jul 2000, Andrzej Bialecki wrote: > Yeah, something like that. The question is who is going to fix it? INET6 > issues should probably stay in sync with other BSDs and KAME, and > therefore IMHO the maintainer of inet6 code should step out and fix > it... (Hello?? :) > Hmm. Good point. > > By the way, while we are talking about sysctl, I don't suppose you would be > > willing to review/commit PR 15251? It is a fairly straightforward patch that > > I see Jonathan Bresler took it (today). > Actually, I think it was John Baldwin...too many JB's around here :) Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problem with patch(1)
Can someone please review/commit the fix in PR 19638. It fixes a bug in patch(1) that prevents -S from skipping a patch when the file to be patched does not exist. Actually, it's skip it, but it requires human intervention first. This is a problem, because one reason you might want to skip the patch is because you know the file doesn't exist and that's OK. I ran into the problem while working on a port, so the requisite human intervention is unwanted, and in this case down-right confusing. And if you find yourself with some extra free time on your hands :), there is also PR 19642 which merges many security fixes to patch(1) from OpenBSD. Thanks, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible bug in netinet6/in6_rmx.c ?
On Sun, 2 Jul 2000, Andrzej Bialecki wrote: > Hi, > > While working on adding dynamic sysctls support, I discovered something > that looks like a bug. > > For kernels that have both INET and INET6, three sysctl entries (rtexpire, > rtminexpire, rtmaxcache) are registered twice - both in netinet/in_rmx.c > and netinet6/in6_rmx.c. > > It seems they should be registered only once, within a section that is > common to INET and INET6. > > Andrzej Bialecki > I think the real problem is that the rtexpire, rtminexpire, and rtmaxcache variables are each declared static in netinet/in_rmx.c and again in netinet6/in6_in6_rmx.c. Do we really need separate learned route expiration times for ip4 and ip6? If the answer is yes, then the solution should be to move the ip6 versions under the net.inet.ip6 sysctl tree. Otherwise, as you suggest, rtexpire and friends need to be common (maybe directly under net.inet?) By the way, while we are talking about sysctl, I don't suppose you would be willing to review/commit PR 15251? It is a fairly straightforward patch that fixes a number of signed-ness bugs with sysctl as well as fix certain sysctl variables to use the correct data type (mostly an issue when ints and longs are different sizes). Thanks, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel breakage?
On Mon, 26 Jun 2000, Kelly Yancey wrote: > > On a just-supped -current I am seeing: > > make: don't know how to make ../../dev/nulldev/nulldev.c. Stop > > on kernel builds (even GENERIC). > Nevermind, pilot error :( -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel breakage?
On a just-supped -current I am seeing: make: don't know how to make ../../dev/nulldev/nulldev.c. Stop on kernel builds (even GENERIC). Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
prod for PR 15251
Please review/commit PR 15251. It addresses a number of signedness issues in the sysctl code. While originally submitted almost 7 months ago, I have updated the PR with patches against a fairly recent -current. Thank you, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
On Sat, 24 Jun 2000, Alexander Sanda wrote:
> I'am ready to try another WM and see whether the SHM problems stay or not
> (other solutions didn't exactly work, I _dramatically_ increased all the
> SHM limits in the kernel but still get tons of shm errors from imlib or
> gdk). Yet, I still see excessive shm usage in the output of ipcs (similar
> to the output reported by the original poster).
>
> BTW: It's for sure _not_ a -current issue and might have nothing to do
> with FreeBSD at all, since I'am running 4.0-STABLE on this machine, with
> Xfree 4.0 and Gnome 1.2.
>
Can you guys post the output of:
$ ipcs -bmo | awk -- '/^m/ {num++;total+=$7*$8}; END {print num,(total/4096)}'
taken while you are experiencing the problem. The first number is the total
number of shared memory segments currently active and the second should be the
total number of shared memory pages in use. Thanks,
Kelly
--
Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA
System Administrator, eGroups.com http://www.egroups.com/
Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/
Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
On Fri, 23 Jun 2000, Garance A Drosihn wrote: > At 4:00 PM -0400 6/23/00, Kelly Yancey wrote: > >On Fri, 23 Jun 2000, Shawn Halpenny wrote: > > > > > I have not had any of the problems he's describing. I have never > > > modified my shared memory settings in my kernel config either. If > > > the problem is indeed Xfree 4.0, then I guess it must be a driver > > > issue (I'm using the neomagic driver). > > > >You are running sawfish, and I'm willing to bet a not very graphics > >intensive config at that. > > Note that Chris (who posted the original message) is also running > sawmill/sawfish... (they are the same thing, right?) > Sawmill is *very* customizable. As a matter of fact, when I last tried it the default config was kind of bare. However, a lisp wizard can really jazz it up with loads of graphics, etc. So it is possible that Shawn is using a 'simpler' config and Chris is the aforementioned lisp wizard :) Sawmill/sawfish uses imlib, so if Chris is using a config with loads of graphics, it would lend credence to my theory that imlib and XF86-4.0 are interacting to create large/many shared memory segments. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
On Fri, 23 Jun 2000, Jacques A . Vidrine wrote: > On Fri, Jun 23, 2000 at 08:22:00PM +0300, Maxim Sobolev wrote: > > Hmm, where my crystal ball... Aha, I see - probably you are using > > Xfree 4.0, while your friend Xfree3.5*. It is where the problem lie > > (see below). > > Well, I use XFree86 4.0 with two displays, and GNOME 1.2, and I don't > have the kind of usage that Christopher has. > I don't think it is gnome per-se. Just switching from WindowMaker to enlightenment was enough to start my XSHM adventure. I suspect the culprit is really imlib/XF86-4.0 interaction. Gnome may contribute to the problem as it uses imlib itself, but enlightenment really gives imlib a workout. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
On Fri, 23 Jun 2000, Shawn Halpenny wrote: > > I have not had any of the problems he's describing. I have never modified > my shared memory settings in my kernel config either. If the problem is > indeed Xfree 4.0, then I guess it must be a driver issue (I'm using > the neomagic driver). > You are running sawfish, and I'm willing to bet a not very graphics intensive config at that. Try running enlightenment with the default config. The problem may not be solely attributable to XF86-4, but rather a combination of XF86-4 and imlib's aggressive use of shared memory. I suspect if you select a window manager with more eye-candy, you'll see the same results. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
On Fri, 23 Jun 2000, Christopher Masto wrote: > Unfortunately, these are my current settings: > > options SHMALL=1025 > options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" > options SHMMAXPGS=1025 > options SHMMIN=2 > options SHMMNI=256 > options SHMSEG=128 > > I can increase it more, but I think this is quite a ridiculous amount > of shared memory to be using. Something must be wrong. > I have recently seen the same thing with 4.0-STABLE and XF86-4.0. I found that I had to up both SHMSEG and SHMMAXPGS. Specifically, on each machine setting SHMSEG to 100 and SHMMAXPGS to 2048 did the trick. I think that besides using many separate shared memory segments, the segments themselves are somewhat large. Seeing as how XF86-4 is in everyone's future, is there any reason not to nip these sort of problems now and up increase the default values for SHMSEG and SHMMAXPGS? The amount of additional kernel memory required is negligable for modern systems. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current status of pcm ??
On Mon, 24 Apr 2000, Kent Hauser wrote: > > Hi all, > > I've been unable to get audio (mp3 & cdplay) to work on my desktop > with a SBLive card or on my laptop (TP 600E). I would *really* like > to have IPSec and a working audio cd player on my laptop. I this > supposed to work, or am I swimming upstream. > > Thanks all. > Kent > > Search the mailing list archives for "emu10k1" and you'll find a HOWTO for using the (experimental) emu10k1 drivers, which provide support for the SBLive card and others, with 4.0. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
> > I tend to agree with this. 650MB is way too much - perhaps the images could > be broken up according to the portion of the system (i.e., bin, sbin, > usr.bin, usr.sbin, etc, et cetera). > This is all beginning to smell a lot like a FTP install. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86-4.0 error
On Tue, 14 Mar 2000, Ted Sikora wrote: > XFree86-Bigfont extension: shmat() failed, size = 4096, errno = 24 > Any ideas on a fix. Xfree86-4.0 is solid otherwise. > There was quite some discussion about this recent on either -hackers or -current. You should be able to find it in the archives. However, as I recall the answer was to increase SHMMAXPGS in your kernel config. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CMD640 and ATA drivers
On Tue, 14 Mar 2000, Thomas Veldhouse wrote: > Are there any plans to support the buggy CMD640 interface in the future > now that 4.0-RELEASE has come and gone? I have a box that is running 3.4 > happily, and it has this interface. I really would like the chance to use > some of the 4.0 features, but I can not while support for this interface > lacks. > The old wd driver is still present in 4.0, it just isn't the default. You can build a custom kernel with it rather than the new ata drivers and you are able to get all of the other benefits of 4.0 despite your buggy CMD640 controller. But you'll have to hurry, some are looking to put wd on the chopping block ;) Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru / microuptime problem
On Mon, 13 Mar 2000, David E. Cross wrote: > I have had these problems ever since upgrading to -current about a > month ago. The kernel very regularly spews out messages like: > > Mar 13 14:23:39 gemini /kernel: calcru: negative time of -2663631 usec for pid 568 >(sshd2) > I know you've probably already tried this, but I'll say it just in case: try setting the kern.timecounter.method sysctl to 1 and see if that works around the problem. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccard.conf.sample ? Is that a great name ???
On Tue, 14 Mar 2000, Daniel C. Sobral wrote: > > You'd be right, if you were right. :-) Pccardd expects what you said, > but defaults/rc.conf configures it to read pccard.conf.sample. In other > words, what is used is the .sample file, *NOT* the customized version, > unless you change that in /etc/rc.conf[.local]. Ah, sure enough, I had overridden it myself in /etc/rc.conf to do the right thing. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccard.conf.sample ? Is that a great name ???
On Mon, 13 Mar 2000, Nicolai Petri (ML) wrote: > > Am I the only one who thinks that having a .sample file containing active > settings is a not so great ting ? > > Why not simply rename it to pccard.conf, pccard.conf.default or > default/pccard.conf > I assumed that the .sample was to emphasize the need to customize it as needed and save it as pccard.conf (where pccardd expects to find it). While not intuitive for new users, it is necissary so that upgrades can modify the pccard.conf.sample file without disturbing and localizations in pccard.conf. See manpath.config.sample for another example of this logic. It doesn't strike me as a candidate for /etc/defaults/ unless it is made to include /etc/pccard.conf if it exists and override and config entries that are duplicated (i.e. if it were truly just defaults that could be overridden). In other words, it may not be intuitive, but it fits the existing protocol. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata, DMA and the install floppies
On Thu, 9 Mar 2000, Samuel Tardieu wrote: > | What model laptop may I ask? I'm running 4.0-current since 1/11/2000 > | (last world rebuild 3/8/2000) on a Compaq Armada 7400 without incident. > > Armada V300. I sent the full details here a few days ago. > Ah, I remember seeing that. As I recall the systems were fairly similar with regards to the IDE configuration. We have the IDE controllers, same size/geometry hard drives (although I think mine is identified as IBM and yours WD...but I've read elsewhere they are in fact the same drive). The only other difference I recall was that your laptop has a different CD-ROM drive. But I'm trying to work off memory here; I can verify the similarity when I get home (where the laptop is). Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata, DMA and the install floppies
On Thu, 9 Mar 2000, Samuel Tardieu wrote: > This looks exactly like the problem I was having with my Compaq laptop, which > could run 3.4 boot disks just fine but not 4.0 kernels. I was probably too > lazy to wait until it reaches the 3 attempts, so I will try again :) > What model laptop may I ask? I'm running 4.0-current since 1/11/2000 (last world rebuild 3/8/2000) on a Compaq Armada 7400 without incident. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bad blocks
On Sun, 27 Feb 2000, kibbet wrote: > Hi all, > > Quick question, how does the new ata driver handle bad blocks? > I've been tracking -current since around Nov 99 but haven't > seen this come up. As I recall, it doesn't. The reasoning is that modern IDE drives perform bad block reassignment so if you are seeing bad block errors, then the entire reserve of blocks available for reassignment has been exhausted. In which case, things are Very Bad and you should start backing up your data ASAP. In you scenario of upgrading from the old wd driver in -stable to the new ad driver in -current, the only advisable action is to just not do a bad block scan under -stable before upgrading. The should stop the complaints from the ad driver about the old-style bad block table. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ 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, 27 Jan 2000, Garrett Wollman wrote: > > I have on a number of occasions had my laptop boot with a > non-functional keyboard. Sometimes the keyboard is just locked; other > times it generates garbage. Never managed to isolate the > circumstances in which this happened (but it didn't happen with a > kernel from last September or there-abouts). Haven't had it happen on > a desktop or server yet. > > -GAWollman I've seen this on a Compaq Armada laptop recently (-current from about 1/10/2000). It only happens when I interrupt the boot process with a key press (I cannot recall whether it was in /boot/loader or in boot2). I suspect the latter, but have not yet tracked the problem down. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pending patch to fix lack of signed sysctl values
Since the countdown is on to a new release, I'de like to take a second and nag some committers to take a look at PR kern/15251. Greg was going to take care of it for me before he got called away on business. In any event, it would good to get into 4.0 release if for no other reason than to prevent sysctl(1) from reporting ludicrious values for some system stats on long-running systems. The patches in kern/15251 add an unsigned flag to sysctl vars and updates sysctl(1) to honor that flag. This eliminates the reporting of negative stat counts when an unsigned integer was being displayed as a signed value. In the long term, there will probably be a need to make some of these stat counts larger integers (at least on i386 where longs are 32 bits and are easily overflown on long-running systems), but for now, these patches are a step in the right direction. Thanks, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sigisempty?
On 24 Jan 2000, Satoshi - Ports Wraith - Asami wrote:
> Anyway, I have committed the following patch submitted by Alexander
> Langer. It has a nice feature of working for both -current and
> -stable without any additional #ifdef's. I hope it's ok.
>
> Satoshi
> ===
> --- lib/libxview/notify/ntfy.h.orig Tue Jun 29 07:18:14 1993
> +++ lib/libxview/notify/ntfy.hMon Jan 10 15:50:53 2000
> @@ -188,7 +197,12 @@
> #define sigisempty(s) (!(((s)->__sigbits[0]) | ((s)->__sigbits[1]) \
> | ((s)->__sigbits[2]) | ((s)->__sigbits[3])))
> #else
> -#define sigisempty(s) (!(*(s)))
> +static int
> +sigisempty (sigset_t *s) {
> + sigset_t n;
> + bzero(&n, sizeof(sigset_t));
> + return (! memcmp(&n, s, sizeof(sigset_t)));
> +}
> #endif
>
> /*
>
Suggestion: use sigemptyset() rather than bzero().
Kelly
--
Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA
Analyst / E-business Development, Bell Industries http://www.bellind.com/
Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/
Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: kernel panics when initializing aic7895 controller at startup.
On Wed, 12 Jan 2000, Brad Guillory wrote: > > > I have a similar problem, in kernels build Monday and yesterday. I get > a kernel panic when while booting, I don't know how to capture the boot > messages to a file (do you) so I can not post them but this is the line > that it dies on: > See dmesg(8) or if that won't work for you (ie. you says it panics while booting) you'll need to investigate using a serial console. Good luck, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** chown&chgrp moved again
On Fri, 7 Jan 2000, David O'Brien wrote: > This is a heads up to let you know that you need to > > rm -f /sbin/chwon /bin/chgrp > > after your next `make world'. Additionally you need to install a new > /dev/MAKEDEV (mergmaster(8) will assist you in this). > > A while back I moved the install location for chown and chgrp from > /usr/sbin and /usr/bin to /sbin and /bin. This was because of > MAKEDEV(8)'s dependence on them, and thus forced /usr to be mounted for > correct operation of MAKEDEV(8). Of course that is bad since you could > easily be trying to create the device node to even mount /usr. > > This week, I have added chown-like functionality to mknod(8) and restored > chown & chgrp back to their previous locations. MAKEDEV has been > updated to use the new functionality of mknod(8). > > However, do to this moving around of chown & chgrp's install location, > you may easily have stale versions in /sbin and /bin. > > -- > -- David([EMAIL PROTECTED]) > > David, I just noticed that this note in 4.0's RELNOTES about the relocation doesn't appear applicable anymore: `chown' has moved from "/usr/sbin" to "/sbin". This is due to dependencies on it by `MAKEDEV'. Please update any scripts that have "/usr/sbin" hardcoded in them. Since `chgrp' is a link to `chown', `chgrp' has moved from "/usr/bin" to "/bin" to reside on the same partition. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
On Wed, 5 Jan 2000, Jordan K. Hubbard wrote: > And given that we've already slipped from December 15th, I think you > can treat this as a pretty hard deadline, to be further slipped only > grudgingly and in response to clear and dire need. > > 10 days, folks! Make 'em count.. :) > I don't suppose there is any chance that kern/15251 might be closed before then. It adds unsigned support to sysctl(8) so it doesn't report bogus numbers. It's just a minor detail, but it wouldn't take but a moment to fix. I'de commit it myself, but... ;) Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: maxfiles same as maxfilesperproc ??
Well, maybe a patch will get things moving. I just submitted kern/15860 with a simple patch which reduces the default maxfilesperproc to be 20 less than maxfiles. I got the mailing list reference wrong in the PR, but -hackers has it's share of similar requests :). Kelly On Sun, 2 Jan 2000, Kip Macy wrote: > I made the same comment several months ago and received a rather cool > reception. I was simply told to change it to my liking in login.conf. > > > -Kip > > On Sat, 1 Jan 2000, John W. DeBoskey wrote: > > > Hi, > > > >On a FreeBSD 4.0-19991223-SNAP system... > > > >I just ran into a situation that caused me to have to reboot > > the machine before understanding what had really happenned... > > > >The problems comes down to: > > > > kern.maxfiles: 4136 > > kern.maxfilesperproc: 4136 > > > > > >Thus, because I had a root uid server that looped chewing > > up file descriptors, it also filled up the system file table. > > > >I realize this is end-user/administrator fixable, but I'm > > not sure the default should have these be the same... > > > > Thanks, > > John > > -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Analyst / E-business Development, Bell Industries http://www.bellind.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
On Tue, 23 Nov 1999, Kelly Yancey wrote: > > I think it would be useful to identify "unsafe" functions, so that > > anyone can participate in the "eyeball" portion of the game. This means > > that we need eyeballed, identified as a (potential) problem and fixed, > > as well as some other possiblities. There is a lot of code out there, > > and it would help if we could involve the non-programmers in the search. > > > > Comments? > > > > * We need to break the auditing process into managable work units. Specifically, I think Kris was right on the money in defining the resolution to be at the function, as opposed to file, level. Individual functions can be identified as unsafe, suspect, or as scutinized and believed to be safe. Individuals are welcome to analyze an entire file, but the status should be recorded per-function. This has the added benefit that commits which change only 1 function in a file, can reset just the confidence level of the function effected, rather than the entire file. That should reduce the amount of duplicated effort since functions which have been scrutinized and deemed safe don't require the same level of scrutiny again should some other function in the file change. > > * We need to note when a commit affects code that was believed to have > previously been secure (so that it may be audited again). This is an extension of the previous point. The on-line tool (whatever form it takes) would have to track commits and reset the confidence flag for any functions that changed. It would be ideal to reset a function's confidence rating whenever it has changed, except when the change was to make it more secure. But of course, this is impractical. The compromise would probably have to be just to always reset the rating to "suspect" and let anyone who commits a security-related fix reset the rating themself. > > * We should indicate what parts of the code have been audited without > discouraging others from double-checking if they like. Continuing the previous thought: we could allow people to attach their assessment to function records in the database. So that if one reviewer "eyeballs" the code and believes it to be safe, they can say so, and it is recorded along with the current version of the file the function is in, and the date of the assessment. This gives us 4 rewards: First, that everyone can see which functions have been reviewed. Second, that if commits make a function unsafe, it would be trivial to identify the last safe version of the file and thus the function. Third, it allows multiple people to review the same function, knowing that someone else has already reviewed it. If I eyeball a function and suspect it to be unsafe, I can attach my "suspect" assessment to the function. Someone looking for functions to investigate could query all of the functions whose most recent assessment was "suspect" (or worse, "unsafe", see last point below). Finally, it requires no effort on the part of the cvs-meisters (ie. no messing with CVS tags); all auditing information is stored outside of the CVS repo. > > * We would like to be able to identify and integrate security fixes > already made by OpenBSD or NetBSD easily. The main obstacle I see here is the divergence in the code bases. Specifically, functions have slightly different names in many places, the file hierarchies are organized differently, and god-knows what else. The only way I can figure to begin to automate the process of integrating fixes from other *BSDs would be to build a mapping relationship for functions and files between their source trees and ours. That may well take as much effort as the audit itself :) I think the only reasonable way to get the fixes merged into our source is for hackers to do it by hand. That isn't to say that we couldn't provide a central place for security-conscious hackers to view security-related commits to other BSD's source trees, past and present. I suspect grepping for things like "overflow" in commit logs for the other BSDs would go a long way in separating the wheat from the chaffe. We can help people find out about potential bugs, but I just can't see how the hand-holding could extend any further. > > * We would like to flag programs as suspect/insecure when they are the > subject of bugtraq reports. The big trick here is that bugtraq reports aren't always nice enough to point us to the specific file/function that is causing the bug :). Either someone has to be responsible for manually identifying the offending files and/or functions as "unsafe" or else we have to take the same policy as with merging fixes fr
Re: FreeBSD security auditing project.
On Tue, 23 Nov 1999, Gerald Abshez wrote: > Kris Kennaway wrote: > > > > Let me throw in some ideas.. > > > > I think it would be very useful to have a database which can track > > submitted open/netbsd CVS commits (with the code diff included), > > preferably mapped to the relevant file in the freebsd tree if possible > > according to a path mapping table (i.e. /some/openbsd/path/file.c mapped > > to /equiv/freebsd.path/file.c). > > Here is my 0.02: > > I think it would be useful to identify "unsafe" functions, so that > anyone can participate in the "eyeball" portion of the game. This means > that we need eyeballed, identified as a (potential) problem and fixed, > as well as some other possiblities. There is a lot of code out there, > and it would help if we could involve the non-programmers in the search. > > Comments? > I was thinking about this on the drive home... * We need to break the auditing process into managable work units. * We need to note when a commit affects code that was believed to have previously been secure (so that it may be audited again). * We should indicate what parts of the code have been audited without discouraging others from double-checking if they like. * We would like to be able to identify and integrate security fixes already made by OpenBSD or NetBSD easily. * We would like to flag programs as suspect/insecure when they are the subject of bugtraq reports. Are there additional goals anyone else has in mind? I've got some thoughts on implementing these, but my wife is telling me it is time to go :) I'll share when I get back from the movies :) Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
On Tue, 23 Nov 1999, David O'Brien wrote: > On Tue, Nov 23, 1999 at 03:23:23PM -0500, Kelly Yancey wrote: > > I may be no security expert, > > So??? You can read C code, right? What needs to happen is a leader to > take charge and give people direction. If someone gave you a few > sequences of code to look for, you could find them right? If you were > also given a typical work around, you could apply it, right? > > Not everyone in the OpenBSD project came into this with a security > mindset. Rather it was alot of getting people rallied around the cause > and teaching them how to go about it. Before we go off 1/2 cocked, we > need to get organized. > > -- > -- David([EMAIL PROTECTED]) > Maybe I'm being modest. :) Actually I've been programming for about 10 years (surely not as long as others on this list) and taught C programming for 2 of those years. So yes, I can not only read C code, but I spew it fairly often. In any event, I suspect your comments aren't entirely directed at my quip, but rather at the sentiment. Point taken. Perhaps, I'll start taking a second-look at some of the fine BSD code I've taken for granted all these years. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
On Tue, 23 Nov 1999, Mark Murray wrote: > I am prepared to provide a (semi-)automatic tool that folks can > submit their efforts to. (Yes, this is a group effort, we all need to > get involved and donate our Copious Free Time. All the time that is > currently invested in flamewars would be better spent here, *hint* > *hint*.) The tool will be web-based and will give a good idea of > progress, so we can even turn it into a sort of competition. > Need volunteers, eh? I can be suckered in to helping in regards to building the web-based database for keeping track of the effor's progress. I may be no security expert, but I can build database-driven web sites (I should...it's my day job ;) ). Let me know what I can do to help. > > I'll get a mailing list going if this is deemed necessary. > freebsd-security? :) -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/isa isa_common.c
On Sat, 13 Nov 1999, Vladimir Kushnir wrote: > > > I've been working on a driver which would support the 'legacy' (i.e. > > > soundblaster compatible) section of the chip. This would support playback > > > but not record but its better than nothing. At this stage, I have it > > > mostly working but no sound yet (probably a mixer problem). > > > > Really? Cool! > > > > I've tried the same thing, and through a series of ugly hacks, got the SB > > Pro bits to probe and attach correctly (and if you set the SBPro version > > to 3.x or whatever the latest version is, you get a mixer device). Sadly > > I couldn't get any sound out of it (mpg123 set to 8bit mode..). > > Although, I'm not too sure how useful 8bit sound would really be. > > > > - alex > > > > Better than nothing, wouldn't it? > Could I help with it somehow? (With my, unfortunately, practically > nonexistent programmer's skill but with a hge willingness to test > anything to make my card sound :-) > As drivers start shaping up, take a second and mention them on the BSD Driver Database (http://www.posi.net/freebsd/drivers/) so others who are interested can track your progress (and maybe help out). Thanks, Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone adding "support" for Athlons.
> As the title says, is anyone working on support for Athlons, and when > can we expect it to arrive back in -stable ? > > (I can't find anything in the latest versions of sys/i386/i386/identcpu.c) > > Also, what actually needs to be done, it doesn't look difficult to add > code to recognise the cpu, what extra stuff to do may be harder, but I've > not got round to reading the specs anyway. > > (egcs development seems to have athlon support now, I've not tried it and > I've only seen patches so far by searching the mailing list) > > It would be great to find all the benefits of my shiny new hardware > (actually it's beige =( ), if indeed there are that many. (perhaps the > 3DNow stuff would give some advantages!) > > Steve Steve, could you try out the patches in PR i386/14438 and PR i386/14440 and see if your K7 is reported correctly? i386/14440 should cause it to display "Athlon" on boot; i386/14438 should cause all of the K7 feature bits to be reported. Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: An FS question perhaps... non blocking I/O.
Hmm. I guess this was added to -current; I don't actually run -current, just read the list :) poll(2) on my -stable system doesn't mention POLLEXTEND. I just checked, the poll(2) listed at http://www.freebsd.org/cgi/man.cgi?query=poll&apropos=0&sektion=0&manpath=Fr eeBSD+4.0-current&format=html as being from 4.0-current is dated Sept 7, 1996; either the man page search on the web is out of date or this is an undocumented bit? Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ "The ultimate result of shielding men from the effects of folly is to fill the world with fools." - Herbert Spencer > -Original Message- > From: Juha Nurmela [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 09, 1999 3:26 PM > To: Kelly Yancey > Subject: Re: An FS question perhaps... non blocking I/O. > > > > Hello. > > Check out poll(2) and POLLEXTEND. > Don't know anything about it, have just seen it > when looking at other things. > > Juha > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An FS question perhaps... non blocking I/O.
> Date: Thu, 9 Sep 1999 16:18:57 +0200 (MET DST) > From: Luigi Rizzo <[EMAIL PROTECTED]> > Subject: An FS question perhaps... non blocking I/O. > [ ... snip ... ] > > The app i have in mind is squid-like, which, if i understand > well, is a > single process looping around a select. If i get things > right, select() > on a file descriptor will return the read bit set if i am not at the > end of file, yet the block might not be in memory yet even if the UFS > seems to do readahead. Maybe i can turn NONBLOCK on for these > descriptors, but still would have select returning essentially useless > info as I'd need to try the read() to be sure... > [ ... snip ... ] Since you are talking about files, I presume when you say "select() on a file descriptor will return the read bit set if I am not at the end of file" you are implying the file descriptor is for a file, not a socket. Admittingly, this has nothing to do with your question directly, but I wanted to clarify something (if nothing else then for my sake): select() will not block on file descriptors referring to files. The logic being that select is only supposed to wait until the operation can occur without blocking (namely a read operation). But reads on files never block, they just return a short count, hence select() always indicates success for file descriptors for open files (and won't block on them). And, we mentioned the the last sentence, select() will always return success for reading file descriptors for open files, EOF or not, since the read would just return a short count. So again, it has nothing to do with the question of finding out whether the data for the read in already in memory, but how can you tell if you are already at EOF for a file using select(), as you describe. I was basing the above statements off of various books I have read, and have never tried select()ing a file's file descriptor for reading as I have always been told it is pointless. If there is a way to do it, I would love to hear it (I have a project that requires tail -f like functionality and I would much prefer to use select() than just checking the file size every so often like tail does). Thanks, Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ "The ultimate result of shielding men from the effects of folly is to fill the world with fools." - Herbert Spencer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
support for larger memory
Time and time again we have all seen people get bit in the rear because BSDI compatibility was broken. Broken for a good cause, mind you, because FreeBSD seemed to lose a little of that "power to serve" when it died horribly on newer servers :) So, the good news is, we can now support large memory configurations (and I recall that 4G might not be that far off). The bad news is, the fairly decent number of programs which are available for BSDI but not FreeBSD won't run on FreeBSD now. Anyway, we all know that. But what I would like to know is: how does BSDI support large memory configurations? I'm confused on how it is that the $1000+ commercial BSD derivative can't handle running on newer servers (although it is pleasing to think a $0 BSD derivative can :) ) Surely, this cannot be the case, though. So, I'm curious, why is it that we needed to break BSDI compatibility in order to support large memory configurations. It would seem that the two shouldn't be mutually exclusive. Thanks, Kelly ~kby...@posi.net~ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: ATAPI and ATAPI_STATIC with the new ATA* driver?
> > It's really frustrating if I add new drive (anywhere on the busses) and > > other drives change their numbers - it's good base for big troubles > > (infinite changing /etc/fstab and so on). > Fair enough. But in real life, you don't add a new drive "anywhere on > the busses". You know _exactly_ which controller you're attaching the > drive to, and you know whether the drive is the master or the slave. > This information is enough for you to figure out _exactly_ where in the > probing the drive will be "spotted" and numbered. > I'm not sure I understand what real-world frustrations people are having > here. Is this thread the product of reactionary criticism, or are there > real examples of situations in which there are serious disadvantages to > the way Soren has things working? > Ciao, > Sheldon. I think you are absolutely right. On all of our servers here, all running various versions of FreeBSD, we've been using SCSI drives for years, which as we all know have the same "problem" that ATA drives have now. The only difference is that with SCSI devices, a mechanism exists to wire-down device names to devices. The only real problem that exists with the new ATA driver is that it doesn't support the same wiring-down for ATA devices. I don't remember who suggested it a couple of days ago, but I thought it was a good idea: to simply extend the wiring-down scheme that we already have to support ATA devices too. He also suggested a more universal device name like drv0, drv1, drv2, etc rather than deliniating between whether the drive is ATA or SCSI...I also think that is a good idea as I don't see any good reason an application should care whether the drive is ATA or SCSI, as long as the functionality is provided does it matter how? Great job Soren, the new drivers are great (although DMA support would make them extra cool :) ) Kelly ~kby...@posi.net~ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Snapshots and Netscape
Just FYI, I don't know if anyone else has experienced this problem or if it was only with 3.0-19990128-SNAP. I found that if you use sysinstall to install a snapshot then you can't build Netscape 4..08 or 4.5 (Communicator or standalone). It dies in vreg (also when trying to start Netscape withoutt having run vreg) looking for ld.so. I cvsup'ed to 3.0-STABLE as of last night and everything worked. Kelly -- Kelly Yancey"Bill Gates is only a white Persian cat and ~kby...@freedomnet.com~ a monocle away from being the villain in a James Bond movie" - comedian Dennis Miller To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
