ppp and the recent -CURRENT
I may have missed in the recent traffic on this list, but with the system svcup'ed on
11-Oct I am running into some problems with things network-related. In particular I
get:
WARNING: Driver mistake: repeat make_dev("net/xl0")
when I bring up a ppp link (with -nat and -auto parameters)
Then I get
8:42:13pm # Oct 12 20:42:38 vogon ppp[4248]: tun0: Warning: 192.168.0.0/24: Chan
ge route failed: errno: Invalid argument
with a subsequent
Oct 13 07:21:06 vogon /boot/kernel/kernel: arplookup 192.168.0.2 failed: could n
ot allocate llinfo
The setup is like this:
192.168.0.1 is a FreeBSD-CURRENT box acting as a gateway on the local network (home)
192.168.0.2 is a WinNT machine that is one of the clients on the same network
Before the last cvsup none of these warnnings were creaping up. That's non-critical
(everything works), yet litters logs and I generally can't seem to figure out what may
be the cause of this all...
Thanks...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
> If you mean what I mean, that guy was Polish, and that stuff still sits in > the tree: Yeah, that was it, sorry - I'm always getting Germany and Poland mixed up! No, not really, please don't hit! ;) That's cool - I should look at this. A perfect excuse to pick up forth again, I think. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
On Fri, 12 Oct 2001, Jordan Hubbard wrote: > Cool! Committed to -current. Of course, this should really be rolled > into the loader so that the sequence is more like this: > > > Would you like to load any additional kernel modules (y/n)? y > Please insert modules floppy and press return: > doing loads on any selected> > Please insert mfsroot floppy and press return: > > > > That way there's no need for a deviceRescan() and the user doesn't > have to remember to invoke the Load KLD menu item before selecting an > Installation type. I remember some german(?) guy even writing a bunch > of FICL primitives for doing those sorts of UIs. I wonder what ever > happened to that stuff? If you mean what I mean, that guy was Polish, and that stuff still sits in the tree: src/boot/i386/libi386/vidconsole.c (look for TERM_EMU) src/share/examples/bootforth/frames.4th It is even enabled by default. -- Andrzej // // Andrzej Bialecki <[EMAIL PROTECTED]>, Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // // <[EMAIL PROTECTED]> FreeBSD developer (http://www.freebsd.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
In message <[EMAIL PROTECTED]> Jordan Hubbard writes: : Cool! Committed to -current. Of course, this should really be rolled : into the loader so that the sequence is more like this: I actually like matsushita-san's patches too. Gives us more default devices.. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern.flp blown out again
Cool! Committed to -current. Of course, this should really be rolled into the loader so that the sequence is more like this: Would you like to load any additional kernel modules (y/n)? y Please insert modules floppy and press return: Please insert mfsroot floppy and press return: That way there's no need for a deviceRescan() and the user doesn't have to remember to invoke the Load KLD menu item before selecting an Installation type. I remember some german(?) guy even writing a bunch of FICL primitives for doing those sorts of UIs. I wonder what ever happened to that stuff? - Jordan > > On 13-Sep-2001 Jordan Hubbard wrote: > > Cool, can I see it? > > Sure.. > http://www.gsoft.com.au/~doconnor/sysinstall-kld.diff > > Mmm dynamic libdialog menus :) > > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Semantic change in su with pam
Hi,
just noticed a slight semantic change while using su:
Before pam, you can disable the wheel check if this group is empty.
Now this isn't possible any more.
I know I just could comment out pam_wheel from /etc/pam.conf but what
about the following solution:
Adding another flag for pam_wheel, which reintroduces the old syntax.
It is quite simple and straightforward (see attached patch).
Any comments?
Daniel
Index: pam_wheel.c
===
RCS file: /data/cvs/src/lib/libpam/modules/pam_wheel/pam_wheel.c,v
retrieving revision 1.5
diff -u -r1.5 pam_wheel.c
--- pam_wheel.c 26 Aug 2001 18:09:00 - 1.5
+++ pam_wheel.c 12 Oct 2001 21:41:05 -
@@ -42,7 +42,7 @@
#include
enum { PAM_OPT_DENY=PAM_OPT_STD_MAX, PAM_OPT_GROUP, PAM_OPT_TRUST,
- PAM_OPT_AUTH_AS_SELF, PAM_OPT_NOROOT_OK };
+ PAM_OPT_AUTH_AS_SELF, PAM_OPT_NOROOT_OK, PAM_OPT_NULL_IGN };
static struct opttab other_options[] = {
{ "deny", PAM_OPT_DENY },
@@ -50,6 +50,7 @@
{ "trust", PAM_OPT_TRUST },
{ "auth_as_self", PAM_OPT_AUTH_AS_SELF },
{ "noroot_ok", PAM_OPT_NOROOT_OK },
+ { "null_ignore",PAM_OPT_NULL_IGN },
{ NULL, 0 }
};
@@ -127,6 +128,8 @@
if (pam_test_option(&options, PAM_OPT_DENY, NULL))
PAM_RETURN(PAM_IGNORE);
else {
+ if(pam_test_option(&options, PAM_OPT_NULL_IGN, NULL))
+ PAM_RETURN(PAM_IGNORE);
PAM_VERBOSE_ERROR("Permission denied");
PAM_RETURN(PAM_AUTH_ERR);
}
Re: Best way to get a system on current?
On Fri, Oct 12, 2001 at 11:16:18AM -0700, David O'Brien wrote: > On Fri, Oct 12, 2001 at 11:15:34AM -0500, Bob Willcox wrote: > > I am interested in what is the best way to get a test system running > > current? I have tried both upgrading from 4.4-stable (ran into kernel > > build problems) > > It would be nice to see the problems you experienced. One is supose to > be able to update from 4.4-stable to 5-CURRENT. Do you still have the > error output (and the exact sequence of commands that produced it)? No, unfortunately the output is long gone (lost in the subsequent attempt to install the 5.0-current snapshot). I'm planning on recreating the snapshot install failure (or getting it right this time and having the install work:-). If I still can't install the snapshot, I will resort to installing 4.4 and trying the upgrade again. I do remember that it was in the "make buildkernel" step that I had the problem (the make buildworld was successful). A compile failed due to what looked like it was using the wrong header files (from /usr/include/sys). If this should recur, I will save the output. Note that I may have used the old 4.4 kernel config file for this though. Next time I plan on using the GENERIC config file. Thanks, Bob -- Bob Willcox Putt's Law: [EMAIL PROTECTED]Technology is dominated by two types of people: Austin, TXThose who understand what they do not manage. Those who manage what they do not understand. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Best way to get a system on current?
On Fri, Oct 12, 2001 at 11:15:34AM -0500, Bob Willcox wrote: > I am interested in what is the best way to get a test system running > current? I have tried both upgrading from 4.4-stable (ran into kernel > build problems) It would be nice to see the problems you experienced. One is supose to be able to update from 4.4-stable to 5-CURRENT. Do you still have the error output (and the exact sequence of commands that produced it)? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Release notes reorg
The release notes for -CURRENT are a real mess. The current ordering rule is something like "chronological ordering of items within a section, but keep related items together". I've just begun converting the release notes (one section at a time) to an alphabetical sorting (on manpage references, filenames, or application names, with a few exceptions). With this, we'll stand a greater chance of people actually being able to find all the release notes relating to a particular command, API, or whatever. I just committed a change for the "Userland" section...the rest will follow, one at a time, over the next few weeks. If you happen to be in the mood for committing release notes to a section, take a quick look to see what the current state of that section is. Note that 4.4-STABLE's release notes already have the alphabetical ordering, which I imposed after the post-4.4-RELEASE truncation of the file. Bruce. msg32475/pgp0.pgp Description: PGP signature
Re: Best way to get a system on current?
On Fri, Oct 12, 2001 at 09:20:35AM -0700, David Wolfskill wrote: > Might help if you provided a pointer to the problems you had in the > "upgrade from -STABLE" case. For that matter, a bit more detail on the > "install failed to mount the filesystems" for the "install from -CURRENT > snapshot" case would be of interest, as well. > > In my case, I just followed the instructions in /usr/src/UPDATING, and > it worked (once I fabricated a replacement kernel config file). Unfortunately, the actual specifics on what failed on the upgrade attempt were lost on the attempted snapshot install. However from memory, the problem was that the kernel build failed (the make buildworld was successful). It appeared that the "make buildkernel" was using header files from the current system, rather than the /usr/src/sys tree, when building, but I'm not certain. Note that, now that I think somemore about it, I may have _not_ have created a new kernel config file. (I usually do, but don't recall doing it this time.) Consequently, I may have been trying to use the 4.4 kernel file that I had for this system. I really wouldn't expect that to work. If that's the case, I can start all over again with this approach (install 4.4 and upgrade). As for the snapshot install, since it's errors were only written to the screen I have to work from memory here as well. I believe the first complaint had to do with the filesystems to be mounted (/mnt/usr, for example) not specified in fstab. Since all of the mounts to /mnt failed, the system fails pretty soon apparently running out of space in /. Thanks, Bob > > Cheers, > david > -- > David H. Wolfskill[EMAIL PROTECTED] > As a computing professional, I believe it would be unethical for me to > advise, recommend, or support the use (save possibly for personal > amusement) of any product that is or depends on any Microsoft product. -- Bob Willcox Putt's Law: [EMAIL PROTECTED]Technology is dominated by two types of people: Austin, TXThose who understand what they do not manage. Those who manage what they do not understand. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Best way to get a system on current?
Hi All, I am interested in what is the best way to get a test system running current? I have tried both upgrading from 4.4-stable (ran into kernel build problems) and installing from the 5.0-20011011-CURRENT snapshot (install failed to mount the filesystems). I decided that I would query the net-wisdom prior to investigating either of these approached any further, though. BTW, before y'all (note, I live in Texas) beat me up for not reading the freebsd-current mailing list, I would like to point out that I have read it but didn't found anything apparent that addresses this (and that's not to say that it's not there, just that I didn't find it...pointers to any oversight on my part are welcomed). Any suggestions?? Thanks, Bob -- Bob Willcox Putt's Law: [EMAIL PROTECTED]Technology is dominated by two types of people: Austin, TXThose who understand what they do not manage. Those who manage what they do not understand. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Some interrupt coalescing tests
On Fri, 12 Oct 2001, Alfred Perlstein wrote: > > The network is 100mbps, switched. To simulate load, I used a syn flooder > > aimed at an unused port. icmp/rst response limiting was enabled. > > Actually, you might want to leave that on, it will generate more load. I considered leaving it on, but I'm not sure if that would be constructive or not. The primary problem with doing that is related to my test setup - as we see from the stable -> current attack, my current box couldn't take the interrupt load of that many incoming packets, which would slow down the outgoing packets. If I had a better test setup, I'd like to try that. > > Before: ~46000 ints/sec, 57-63% processor usage due to interrupts. > > After: ~38000 ints/sec, 50-60% processor usage due to interrupts. > > > > In both cases, the box felt responsive. > > You need to get real hardware to run these tests, obviously you aren't > saturating your line. I would suspect a better test would be to see > how many pps you get can at the point where cpu utlization reaches > 100%. Basically start at a base of 60,000pps, and see how many more > it takes to drive them both to 100%. > > Even your limited tests show a mean improvement of something like > 10%. > > 10% isn't earth shattering, but it is a signifigant improvement. Yes, there is some improvement, but I'm not sure that the actual effect is worthwhile. Even with the 10% decrease, you're still going to kill the box if the interrupt count goes much higher. If you can setup a 4.4+this patch test of some sort with varying loads to see the effect, maybe we could characterize the effect of the patch more. With my setup, I don't think I can really take this testing any further. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strike three, you're out
Bruce Evans <[EMAIL PROTECTED]> writes: > On 12 Oct 2001, Dag-Erling Smorgrav wrote: > > Remove UCONSOLE from kernel config. This has been discussed to death > > several times on the lists. > That only prevents non-root from triggering the bug. True. The only thing I know of that uses TIOCCONS apart from sysinstall is xconsole, but now that I think of it, xconsole does run as root if you use xdm. I guess the best way to avoid triggering this panic is to remove the UCONSOLE option from the kernel *and* comment out the xconsole line from /etc/X11/xdm/Xsetup_0. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strike three, you're out
On 12 Oct 2001, Dag-Erling Smorgrav wrote: > Doug Barton <[EMAIL PROTECTED]> writes: > > Reported on 9/30: > > panic: blockable sleep lock (sx) allproc @ > > /usr/local/src/sys/kern/kern_proc.c:212 > > > > According to BDE, "This is a well-know bug in printf(9). The TIOCCONS > > ioctl always gave non-deterministic crashes. Now it gives determinstic > > panics when > > pintf() is called while sched_lock is held." That's the only discussion > > about it, no fixes, no suggestions. > > Remove UCONSOLE from kernel config. This has been discussed to death > several times on the lists. That only prevents non-root from triggering the bug. What an evil option. It has always been enabled in GENERIC although it has always implemented panics and security holes. It has always been enabled in LINT/NOTES although it is a negative option. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMWare2 permission problems on -current as of Sep 26 [FIXED]
Robert,
the problem wan't with access(2) but with preceding setresuid(2)
calls. There was a false widening conversion taking place in
linux_uid16.c.
Various setXXid() calls allow the caller to set several ids at once,
or leave them unchanged by specifying the magic parameter -1.
Unfortunately uid_t and gid_t are unsigned, so this is asking for
trouble in itself. The problem came to light when someone decided
that linux really passed only 16 bits of information for the ids, and
thus the passed-in ids had to be widened (unsignedly) to 32 bits for
BSD kernel land. The C compiler happily widened an unsigned 16 bit
value of -1 to an unsiged 32 bit value of +65535 which wan't magic any
more.
I've inserted proper casts, see the attached diff, and now VMware
works again. I'd appreciate if you could commit the patch, or
anything equivalent.
Now that VMware works I still have trouble with ORACLE. I'll probably
csvup to today's -current before I start working (as I get time, no
promises) on that one.
--
Regards,
Georg.
At Tue, 9 Oct 2001 00:16:17 -0400 (EDT),
Robert Watson wrote:
>
> [...]
> An interesting experiment might be to write a short program invoking
> access(2) with the same arguments, compiled under both ABIs, and then
> experimented with and without setuid-root. A glance at the linux_access()
> implementation looks right to me, but maybe there's something going on
> relating to preserving real/saved uids/gids and the process credential.
> Or alternatively, maybe your .Xauthority file isn't readable :-)
> [...]
--- sys/compat/linux/linux_uid16.c.gwk Wed Sep 12 10:36:57 2001
+++ sys/compat/linux/linux_uid16.c Thu Oct 11 23:35:53 2001
@@ -42,6 +42,13 @@
DUMMY(getresuid16);
DUMMY(getresgid16);
+/* Linux uid_t and gid_t have different sizes than BSD variants.
+ * Use XXX_TOBSD(x) macros to convert so that the "magic" values
+ * of -1 are preserved correctly.
+ */
+#define GID_TOBSD(x) ((x) == (l_gid16_t) -1 ? -1 : (x))
+#define UID_TOBSD(x) ((x) == (l_uid16_t) -1 ? -1 : (x))
+
int
linux_chown16(struct thread *td, struct linux_chown16_args *args)
{
@@ -249,8 +256,8 @@
{
struct setregid_args bsd;
- bsd.rgid = args->rgid;
- bsd.egid = args->egid;
+ bsd.rgid = GID_TOBSD(args->rgid);
+ bsd.egid = GID_TOBSD(args->egid);
return (setregid(td, &bsd));
}
@@ -259,8 +266,8 @@
{
struct setreuid_args bsd;
- bsd.ruid = args->ruid;
- bsd.euid = args->euid;
+ bsd.ruid = UID_TOBSD(args->ruid);
+ bsd.euid = UID_TOBSD(args->euid);
return (setreuid(td, &bsd));
}
@@ -269,9 +276,9 @@
{
struct setresgid_args bsd;
- bsd.rgid = args->rgid;
- bsd.egid = args->egid;
- bsd.sgid = args->sgid;
+ bsd.rgid = GID_TOBSD(args->rgid);
+ bsd.egid = GID_TOBSD(args->egid);
+ bsd.sgid = GID_TOBSD(args->sgid);
return (setresgid(td, &bsd));
}
@@ -280,8 +287,8 @@
{
struct setresuid_args bsd;
- bsd.ruid = args->ruid;
- bsd.euid = args->euid;
- bsd.suid = args->suid;
+ bsd.ruid = UID_TOBSD(args->ruid);
+ bsd.euid = UID_TOBSD(args->euid);
+ bsd.suid = UID_TOBSD(args->suid);
return (setresuid(td, &bsd));
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: my dc now doesn't work
On Thu, 11 Oct 2001, Jonathan Lemon wrote: > >$FreeBSD: src/sys/pci/if_dc.c,v 1.56 2001/09/29 19:28:31 jlemon Exp $ > > Can you back out this last change to if_dc, and see if that fixes the > problem that you're having? Yes, v1.55 of if_dc.c make my NIC back again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Some interrupt coalescing tests
* Mike Silbersack <[EMAIL PROTECTED]> [011012 01:30] wrote: > > Well, I've been watching everyone argue about the value of interrupt > coalescing in the net drivers, so I decided to port terry's patch to 4.4 & > -current to see what the results are. The patch included applies cleanly > to 4.4's if_dc, and will apply to -current with a one line change. > Whitespace is horrible, I copied and pasted the original patch, used patch > -l, etc. > > The test setup I used was as follows: > Duron 600, PNIC, running -current > Celeron 450, ADMtek tulip-clone, running -stable > > The network is 100mbps, switched. To simulate load, I used a syn flooder > aimed at an unused port. icmp/rst response limiting was enabled. Actually, you might want to leave that on, it will generate more load. > > With the -current box attacking the -stable box, I was able to notice a > slight drop in interrupts/second with the patch applied. The number of > packets was ~57000/second. > > Before: ~46000 ints/sec, 57-63% processor usage due to interrupts. > After: ~38000 ints/sec, 50-60% processor usage due to interrupts. > > In both cases, the box felt responsive. You need to get real hardware to run these tests, obviously you aren't saturating your line. I would suspect a better test would be to see how many pps you get can at the point where cpu utlization reaches 100%. Basically start at a base of 60,000pps, and see how many more it takes to drive them both to 100%. Even your limited tests show a mean improvement of something like 10%. 10% isn't earth shattering, but it is a signifigant improvement. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
