RE: Time to close the list?
Seems more like someone is trying to crash the mail server by with these loopedy mail and replies from the virus programs ... :( On 02-Nov-00 Greg Black wrote: > Maybe it's time to close the list so that it only accepts > messages from subscribers. The spam was bad enough, but the > virus warnings are over the top. Sigh. > > -- > Greg Black <[EMAIL PROTECTED]> > Join the fight against spam: http://www.cauce.org/ > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message ### # # # R.N. Bezuidenhout NetSeq Firewall # # [EMAIL PROTECTED] http://www.nanoteq.co.za# # # ### -- Date: 02-Nov-00 Time: 10:40:47 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux ioctl not implemented error
Hi ...
> > > > to do?
> > >
> > > CDROMVOLREAD that you want to map to CDIOGETVOL.
That should read CDIOCGETVOL :)
> try this:
>
> Index: linux_ioctl.c
> ===
> RCS file: /home/ncvs/src/sys/i386/linux/linux_ioctl.c,v
> retrieving revision 1.47
> diff -u -u -r1.47 linux_ioctl.c
> --- linux_ioctl.c 1999/11/29 23:03:34 1.47
> +++ linux_ioctl.c 1999/12/01 23:46:22
> @@ -1273,6 +1273,11 @@
> return error;
> }
>
> +case LINUX_CDROMVOLREAD: {
> + args->arg = CDIOGETVOL;
> + return (ioctl(p, (struct ioctl_args *)args));
> +}
> +
> case LINUX_OSS_GETVERSION: {
> int version;
>
>
I've made a change that removed the complaint from vmware before Vladimar
fixed it in the kernel module. It is the implementation of LINUX_CDROMVOLREAD
to fit in with CDIOCGETVOL which has two different structures.
Marcel please review this :)
Index: linux_ioctl.c
===
RCS file: /home/freebsd-cvs/src/sys/i386/linux/linux_ioctl.c,v
retrieving revision 1.47
diff -c -r1.47 linux_ioctl.c
*** linux_ioctl.c 1999/11/29 23:03:34 1.47
--- linux_ioctl.c 1999/12/02 07:15:29
***
*** 473,478
--- 473,486
u_charcdte_datamode;
};
+ struct linux_cdrom_volctrl
+ {
+ u_char channel0;
+ u_char channel1;
+ u_char channel2;
+ u_char channel3;
+ };
+
struct linux_cdrom_subchnl
{
u_char cdsc_format;
***
*** 1232,1237
--- 1240,1261
bsd_to_linux_msf_lba(irtse.address_format,
&irtse.entry.addr, arg, sizeof(lte));
+ }
+ return error;
+ }
+
+ case LINUX_CDROMVOLREAD: {
+ struct linux_cdrom_volctrl lvol, *lvolp =
+ (struct linux_cdrom_volctrl *)args->arg;
+ struct ioc_vol bsd_vol;
+ error = fo_ioctl(fp, CDIOCGETVOL, (caddr_t)&bsd_vol, p);
+ if (!error) {
+ lvol = *lvolp;
+ lvol.channel0 = bsd_vol.vol[0];
+ lvol.channel1 = bsd_vol.vol[1];
+ lvol.channel2 = bsd_vol.vol[2];
+ lvol.channel3 = bsd_vol.vol[3];
+ copyout((caddr_t)&lvol, (caddr_t)args->arg, sizeof(lvol));
}
return error;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux ioctl not implemented error
> > + {
> > + u_char channel0;
> > + u_char channel1;
> > + u_char channel2;
> > + u_char channel3;
> > + };
> > +
> > struct linux_cdrom_subchnl
> > {
> > u_char cdsc_format;
> > ***
> > *** 1232,1237
> > --- 1240,1261
>
> FYI the kernel structures are completely identical, you don't really
> gain anything by doing this convertion. Should this be put in for
> clarity? I'm not sure.
>
Ok ... I guess it should not be a problem the FreeBSD structure is
struct ioc_vol
{
u_char vol[4]; /* one for each channel */
};
which I guess should look the same in memory than the linux one ...
The confersion is then not necessary ... ??
Reinier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux ioctl not implemented error
Hi ... > > to fit in with CDIOCGETVOL which has two different structures. > > > > Marcel please review this :) > > Please hold your horses. I have a completely rewritten linux_ioctl.c > waiting to be committed. I'm already working on the ioctl stuff with > Vladimir as to synchronize the change. As soon as Vladimir has updated > his port to use the new interface everything is committed and announced. > From that moment on I'll happily accept any patches and diffs! > > Please, send patches that specificly apply to the VMware port to > Vladimir and any patches that apply to the Linuxulator to me. That way > we have this port up and running in notime. I unfortunately don't have > time to read the mailinglists very closely, so I may have missed a > couple of patches already... > Ok ... I'm holding my horses ... my previous e-mail was just before I received this one ... please ignore it then ... Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux ioctl not implemented error
> Alfred Perlstein wrote:
> >
> > > + if (!error) {
> > > + lvol = *lvolp;
> > > + lvol.channel0 = bsd_vol.vol[0];
> > > + lvol.channel1 = bsd_vol.vol[1];
> > > + lvol.channel2 = bsd_vol.vol[2];
> > > + lvol.channel3 = bsd_vol.vol[3];
> >
> > FYI the kernel structures are completely identical, you don't really
> > gain anything by doing this convertion. Should this be put in for
> > clarity? I'm not sure.
>
> No. When it's there, you automaticly assume it's there for a reason.
> Since the structures are identical, there's no reason for the code to be
> there. Very confusing :-)
I stand corrected then :) thanx
Reinier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Preemptiveness of FreeBSD threads
Hi ... I also ran this program on a 4.0-current as of about Jan 13 2000 :) It generates the errornous output like clock work on my machine (after about 30 tries - no exception). I then though that maybe the system gets so buzy that it has difficulty on starting the threads - yes I know this should not be a problem. I added a "sleep (1);" as the FIRST instruction in the "start_my_thread" functioni (Thus it is not inside the loop). This causes the following output every time. jarrow# ./thread ^C Thread 0x00: 6524518 Thread 0x01: 6574627 Thread 0x02: 6605728 Thread 0x03: 12928447 Thread 0x04: 6327346 Thread 0x05: 6592751 Thread 0x06: 12971487 Thread 0x07: 12968330 Thread 0x08: 6567584 Thread 0x09: 6642237 Thread 0x0a: 12632004 Ok :) not the EXACT same output put you know what I mean. Interesting, if I press ctrl-c too erly I sometimes get jarrow# ./thread ^C Thread 0x00: 6469560 Thread 0x01: 6541408 Thread 0x02: 12888010 Thread 0x03: 6327606 Thread 0x04: 13160549 Thread 0x05: 6005825 Thread 0x06: 12345878 Thread 0x07: 0 Thread 0x08: 0 Thread 0x09: 0 Thread 0x0a: 12974910 It seems that letting it wait a while before entering the loop causes all the thread to get time to startup and start counting Reinier > > Yup, that does it, but it makes the program several orders of magnitude slower, > > too. Be careful about how much you use sched_yield, you're pushing the system > > into behavior that is outside its normal operating design. FreeBSD wasn't > > designed to re-run the scheduler after 2 or 3 instructions. > > In the case of libc_r, a call to sched_yield doesn't result in the system > call sched_yield. Rather, it causes the userland threads scheduler to be > run. There is still plenty of overhead, but running the kernel scheduler > isn't necessarily part of that overhead. > > Jason > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preemptiveness of FreeBSD threads
> Hi ... > > I also ran this program on a 4.0-current as of about Jan 13 2000 :) > > It generates the errornous output like clock work on my machine (after about > 30 tries - no exception). I then though that maybe the system gets so buzy > that it has difficulty on starting the threads - yes I know this should not > be a problem. > > I added a "sleep (1);" as the FIRST instruction in the "start_my_thread" > functioni (Thus it is not inside the loop). This causes the following > output every time. > Seems like I have to recall this statement - I've just removed the sleep and recompiled and now it seems to work again ... and just about everytime I've tested it ... I am now just as confused as anyone else :/ Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preemptiveness of FreeBSD threads
> My experiments with your test program do exactly what I would expect. The > longer the program is run, thu longer the program has to preempt threads, > which means that given enough time, all threads will run. If the program > is run for a short time (less than about 1.5 seconds) then some threads may > never get to run. On my system it doesn't matter how long I leave it .. the times it doesn't work ... e.g. belowe .. it even had enough time to let the varialble wrap ... jarrow# ./thread ^C Thread 0x00: 0 Thread 0x01: 0 Thread 0x02: 0 Thread 0x03: 0 Thread 0x04: 0 Thread 0x05: 0 Thread 0x06: 0 Thread 0x07: 0 Thread 0x08: 0 Thread 0x09: 0 Thread 0x0a: -1532959619 So letting it run for longer doesn't help :/ Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preemptiveness of FreeBSD threads
> >OK, with everyones help (well, waiting for the right time of day ;-)), > I > >was able to reproduce this. The initial threads last active time was > >not getting initialized to a sane value, causing negative > computations > >of the threads timeslice depending on what time of day it was. Funny > >thing was that I added this change several times, but each time I > somehow > >convinced myself that it wasn't needed. > > >Try this patch - you may have to hand apply it as my sources are not > >yet up to date with the last round of changes that Jason made. > > >Dan Eischen > >[EMAIL PROTECTED] Will this patch be patched back to RELENG_3 too ?? We have quite a few applications that use threads :) Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Reading lpt status register in NIBBLE mode
Hi ... I want to read the status register of the lpt port in NIBBLE mode. I want to do this wether there is a printer connected or not. What would be the best way to accomplish this ?? Should I use the ppi0 device with the PPIGSTATUS ioctl call, because if there is no printer connected I can't open the printer port. Or is there another device on the ppbus that I should rather use. Thanks Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What are the best gcc optimization options for Pentium 200 M
Hi .. I agree that optimizations are most of the time "futile" :) .. so is resistance :) ... ina ny case .. I like to live on the edge .. that is why I'm running 5.0-current .. and I've compiled the following things with optimizations. o The whole source tree .. including my kernel o XFree86 o KDE 1.1.2 And most of the other ports I've installed ... like vmware, kdevelop etc. to name but a few ... And again ... I know I am taking a risk .. but I've been running this system for about 6 months now ... and I haven't even seen one panic or core which is "unexplained" due to bad code generation. Just once again .. YRS I know gcc generates bad code sometime and optimizations isn't the way to go ... but it works for me .. for now :) The optimizations I'm using In /etc/make.conf CFLAGS= -O6 -mpentiumpro -march=pentiumpro -pipe -s -fexpensive-optimizations -ffast-math COPTFLAGS= -O6 -mpentiumpro -march=pentiumpro -pipe -s -fexpensive-optimizations -ffast-math And I know -O6 is an over kill ... Bye Reinier > I doubt Mandrake gets any significant performance boost from using gcc with > optimisation levels beyond -O. They just use this "super optimised" to > stand out from all other Linux crowd rather than for any practical purpose. It > has been reported several times that optimisation levels O2 ang higher are > buggy and known to generate wrong code on several occasions. This was true for > gcc 2.7.2.3 and it is still true for gcc 2.95.2. In other words, your attempt to > squeese last drop of performance from your system in this way is futile :). The > gain you will get is just not worth associated risks. > > On 08-Apr-00 Alexey N. Dokuchaev wrote: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
3-Stable: Logging to syslog fails
Hi
I have a system running a stable snap of 3.4 of round about May 31,
I have a program that does quite a bit of logging, and sometime the
following occurs:
The process would just stop (seems to block) - a bt in gdb showed
that it was stuck in open after the following sequence of calls
syslog -> vsyslog -> open
After having a look at the code it seemed that the process was unable
to connect to syslogd and then continued to open the console (I have a
console configured on a serial line 9600 baud) and it got stuck in that open.
When I connected to the console, the log message was displayed.
On further inspection I saw that during the write of log info to syslog,
messages would stop appearing in the logfile in /var/log and ONLY be
displayed in the console. If nothing was connected to the console, it
would block and wait for ever.
Is this because of some buffer which is too small somewhere ?? that can
be changed ... or is this a bug ... or normal behaviour. e.g. What causes
the program not to be able to connect to write the log info ???
the sequence it seems to follow in libc's syslog.c
in the function vsyslog
Version 1.18.2.1
/* Get connected, output the message to the local logger. */
/*
* If the send() failed, the odds are syslogd was restarted.
* Make one (only) attempt to reconnect to /dev/log.
*/
/*
* Output the message to the console; don't worry about blocking,
* if console blocks everything will. Make sure the error reported
* is the one from the syslogd failure.
*/
And now it gets stuck in here
if (LogStat & LOG_CONS &&
(fd = open(_PATH_CONSOLE, O_WRONLY, 0)) >= 0) {
thanks
Reinier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Fastforwarding
> > > > Has anyone here tried setting net.inet.ip.fastforwarding on in a high > > traffic enviroment? > > > > This setting DRASTICALLY speeds up transfers between boxes talking through > > a freebsd gateway when you are using 2 100mbit interfaces, but it seems to > > kernel panic the system after a few minutes. > > can you quantify the "drastically" ? > > luigi > This also depends on what 100mbit cards you are using ... we had problems with the Intel ether express cards when using X-over cables (yes :) Intel specs that these cards should NOT be used with X-overs) ... this caused the cards to go in some reset stage where no packets are transfered and the mbufs heap up and eventually could cause a panic. this happend when configured as abridge and doing 100mbit full-duplex transfers, we fixed this by using a switch and removing the X-overs. Also have a look at increasing the mbufs .. I don't know if the mbuf exaustion panic has been fixed .. anyone ?? Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NATD errors on 5.0
Hi ... I've started natd on my local machine to translate all packets to the ip of my public interface. If I am on my machine, and I start natd and add the divert rule, (this means I'm trying to connect from my local machine on which I am running the natd to any other machine) I can see the packet leaving my machine, ariving at the destination machine, but NO reply returned, if I ping .. everything seems ok Any ideas what is wrong ??? Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: vmware changes result in nasty bridging mess
I'm using vmware2 in a different way ... I do not have bridging enabled in the kernel. I'm using the host method although I do not have a "legal" subnet on the other side. I've ment to contact the port maintainer so he can add this to the Hints.FreeBSD file. I've configured 10.1.1.1 for the vmnet device, and 10.1.1.2 in windows. I use ipfw and natd to translate the info ... this works like a charm. I'm using the latest port of vmware and I don't see those messages, probably because I do not have BRIDGING enabled in the kernel. For thos interested .. here is the natd and ipfw rules. natd -u -a ipfw a 3 divert natd all from 10.1.1.2 to any out via vr0 ipfw a 4 divert natd all from any to in via vr0 I'm even accessing the NT servers :), browsing bla bla bla :) Regards Reinier On 02-Aug-00 Robert Watson wrote: > > bridge_in-- reading table > bridge_in-- reading table > bridge_in-- reading table > bridge_in-- reading table > bridge_in-- reading table > bridge_in-- reading table > bridge_in-- reading table > bridge_in-- reading table > bridge_in-- reading table > ... > > The vmware2 port now seems to enable bridging by default, and generate a > kernel message for every ethernet packet sent. Bridging on by default may > have nasty side effects for multi-interface machines (especially security > side effects). I haven't read the code (I admit) but I finding the > current behavior both (a) irritating (messages) and (b) worrying > (unpredicted bridging with potential side effects). > > Robert N M Watson > > [EMAIL PROTECTED] http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message ### # # # R.N. Bezuidenhout NetSeq Firewall # # [EMAIL PROTECTED] http://www.nanoteq.co.za# # # ### -- Date: 03-Aug-00 Time: 09:04:34 This message was sent by XFMail -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Patches for linprocfs and linux emulation - fix 'ls /proc' bug and ipc's
Hi all
I have an application that uses the linux procfs extensively and also linux ipcs. I found two problems in the current linux emulation.
(I hope the diff provided below will work as is since my mailing program is a bit limited :) )
1) linux_ipc.c has a pice of code commented that we can actually use now. I think the other pieces were added later and this didn't get changed. The patch is valid for RELENG_4 and HEAD. The current code will always remove only the first enry from a msg queue even if msgtyp was specified causing incorrect behaviour. It's a one line change in linux_ipc.c in src/sys/compat/linux
2) When traversing the linprocfs with i.e. ls (the linux ls in /compat/linux/bin/ls ) I noticed that some entries in the proc table is missing, compared to doing a FreeBSD ls /bin/ls. I traced the problem to a counter inconcistenct because linux reads smaller blocks at a time. This problem is only in RELENG_4 and not HEAD since the linprocfs changed a lot in HEAD. The loop skips the first 9 entries for the cpuinfo etc. in /compat/linux/proc, but on the second loop it skips the first 9 entries in the proc table and thus they do not show up in a /compat/linux/bin/ls
If someone responsible from the linux emulation can review these changes and maybe commit them, I'll appreciate it :)
Thanks
Reinier
cut cut -
*** linprocfs_vnops.c 2001/08/12 14:29:19 1.3.2.5--- linprocfs_vnops.c 2002/05/17 15:19:43** 896,902 default:! while (pcnt < i) { p = p->p_list.le_next; if (!p) goto done;--- 896,907 default:! /* Since we skip the first 9, by the time we! * get here i = 9 and we'll end up skipping ! * the first 9 procs in the list, so we! * increment pcnt by the same value! */! while ((pcnt + 9) < i) { p = p->p_list.le_next; if (!p) goto done;
- cut -- cut -- cut
*** linux_ipc.c.old Fri May 17 11:08:58 2002--- linux_ipc.c Fri May 17 11:09:29 2002** 358,364 bsd_args.msqid = args->msqid; bsd_args.msgp = args->msgp; bsd_args.msgsz = args->msgsz;! bsd_args.msgtyp = 0; /* XXX - args->msgtyp; */ bsd_args.msgflg = args->msgflg; return msgrcv(td, &bsd_args); }--- 358,364 bsd_args.msqid = args->msqid; bsd_args.msgp = args->msgp; bsd_args.msgsz = args->msgsz;! bsd_args.msgtyp = args->msgtyp; bsd_args.msgflg = args->msgflg; return msgrcv(td, &bsd_args); }
- cut cut -- cut -Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
Boot messages on console in 3.2
Hi ... I'm trying to get a 3.2-STABLE to boot via the serial console. I can get the "boot: " rompt and loader to display to the serial console, but after the 9 second delay it continues to boot but no output is generated to the screen (device probes etc.). After the boot has completed, the login prompt is displayed on the console and I can login. I just want it to display the boot information (probes ... hd ... etc.) the /boot.config file has the following option -h and that is the only line ... I have tried both -h and -P ... I have tried only -P The "show" command under loader shows that the console is set to comconsole I've also treid a kernel with "flags 0x01" to the atkbd ... but it also doesn't work and the "options COMCONSOLE" for the kernel is nolonger allowed according to config. Any ideas ? Thanx Reinier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Which device should I make with this error?
Hi :) put the following line in your kernel config file .. recompile your kernel .. boot .. and then try the make again ... pseudo-device vn1 to create the floppy ... a vertual node is used .. hope this helps ... Reinier > During a make release for 3.2-RELEASE I get the following error: > > Making the regular boot floppy. > Compressing doc files... > sh -e /usr/src/release/scripts/doFS.sh -s mfsroot /R/stage /mnt 2880 > /R/stage/m > fsfd 8000 minimum2 > vnconfig: open: Device not configured > *** Error code 1 > > Stop. > *** Error code 1 > > What does this mean and how do I fix it? > > Thanks > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Cheers Reinier > On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: > > > > I guess I forgot about the overhead. I've tested between two > > > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL > > > Switch Full Duplex and never seen anything close to the speeds. > > > > using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp > > cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. > > > > i use these machines for stressing every else we have at work. > > Hmmm, has anyone tried a full duplex test before? Since it seems > like the bottleneck is really the speed of the disks.. > > > Cheers, > Vince - vi...@mcestate.com - vi...@gaianet.net __ > Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] > GaiaNet Corporation - M & C Estate / / / / | / | __] ] > Beverly Hills, California USA 90210 / / / / / |/ / | __] ] > HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Hi .. > > 1. If you want to test the network speed ... use ttcp or something > >that generates the data and doesn't read it from disk. > > ttcp works. The only problem is when I tried it in both > directions, at once. the total becomes 11.xMbytes/sec total as opposed to > 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with "netstat -in". If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. Also check with "netstat -sn" to see if there are any other counters that increase with the full-duplex transfers. > > 2. When doing full-duplex and using fxp cards, stay away from X-over > >cables ... use a full-duplex switch etc. ... the fxp cards are not > >made to work with X-over cables (as far as I know - ala Intel spec) > >note ... only for full-duplex tests. > > Does anyone actually use X-over cables for 100Mbps Full Duplex > since 3Com said CrossOver cables are not rated for 100Mbps or something > even though it's Cat5. Actually, in the older Intel docs for the Pro100B, > it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of "device timeouts". > > We have done tests in full-duplex with non Intel cards (because we did > > not have a switch at that time :)) and with max size packets we got around > > 188.00 Mbps using the de0 driver. > > Pretty interesting. How did you do the full duplex tests? > I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that "does not exist". The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the "non existing" machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Reinier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
if_dl.h in stable causes sendmail segmentation
Hi ... I have the following situation... A machine running a 3.2-STABLE of a few weeks ago ... When the machine booted I saw that newaliases (sendmail -bi) exited with a segmentation fault. I further inspected and found that if I do a ifconfig of a interface (fxp0 or de0) newaliases is ok, but when I do an ifconfig fxp0 delete the newaliases exits on a segmentation fault. e.g. - Amnesiac# ifconfig -au de0: flags=8843 mtu 1500 inet 196.37.91.253 netmask 0xff00 broadcast 196.37.91.255 ether 00:e0:29:00:e5:19 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 Amnesiac# newaliases /etc/aliases: 19 aliases, longest 10 bytes, 190 bytes total Amnesiac# ifconfig de0 delete Amnesiac# newaliases Segmentation fault Amnesiac# ifconfig de0 up Amnesiac# newaliases /etc/aliases: 19 aliases, longest 10 bytes, 190 bytes total Amnesiac# -- I then used the kernel sources from a few weeks after the 3.2-RELEASE and compiled the kernel - now everything works ok ... no segmentation fault. I eventually traced the problem down to the following header file /usr/src/sys/net/if_dl.h If I use the old header file ... no problem ... use the latest one .. sendmail crashes (and looks like gated also does this). Here is the diff jarrow# diff -c if_dl.h ../../sys.new/net/if_dl.h *** if_dl.h Tue Jul 20 16:18:54 1999 --- ../../sys.new/net/if_dl.h Thu May 27 05:06:41 1999 *** *** 31,37 * SUCH DAMAGE. * *@(#)if_dl.h 8.1 (Berkeley) 6/10/93 ! * $Id: if_dl.h,v 1.6 1997/02/22 09:41:00 peter Exp $ */ #ifndef _NET_IF_DL_H_ --- 31,37 * SUCH DAMAGE. * *@(#)if_dl.h 8.1 (Berkeley) 6/10/93 ! * $Id: if_dl.h,v 1.6.4.1 1999/05/27 03:06:41 julian Exp $ */ #ifndef _NET_IF_DL_H_ *** *** 68,73 --- 68,75 u_char sdl_slen; /* link layer selector length */ charsdl_data[12]; /* minimum work area, can be larger; contains both if name and ll address */ + u_short sdl_rcf;/* source routing control */ + u_short sdl_route[16]; /* source routing information */ }; #define LLADDR(s) ((caddr_t)((s)->sdl_data + (s)->sdl_nlen)) -- Looks like the addition of the two last entries in the structure is the problem ?? Any ideas ?? Sendmail crashes in the routine in conf.c called "load_if_names()" where it cycles through the interfaces round line if (sa->sa.sa_len > sizeof ifr->ifr_addr) the address sa->sa seems to point so where If you want any more info .. just ask :) Thanx Reinier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dl.h in stable causes sendmail segmentation
Hi ... > In article <199907201542.raa02...@oskar.nanoteq.co.za>, > Reinier Bezuidenhout wrote: > > > I have the following situation... > ... [various userland SEGVs traced down to a change in if_dl.h] The sendmail that SEGV was compiled with the kernel that causes the crash ... I did the make release myself on a machine ... :( so it is not an updated kernel error :) Thanx Reinier > > Just a guess: it sounds like the kind of thing that would happen if > you updated your kernel without also rebuilding userland. > > John > -- > John Polstra j...@polstra.com > John D. Polstra & Co., Inc.Seattle, Washington USA > "No matter how cynical I get, I just can't keep up."-- Nora Ephron > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
newaliases and 256 tun devices
Hi ...
I previously mailed the same error ... and then I thought
it was a "miss-corrolation" between kernel sources and
userland. Since then I built a SNAP of 990726 sources
and tried the same thing and the error occured again .
Same sources used for the compile of the kernel and userlevel
binaries.
I've now traced the following down ... it has something todo
with the changes in net/if_dl.h (the entries added for
source routing and the fact that my kernel has
pseudo-device tun 255
in the config.
Setup.
PII400 / Asus P2-99 990726 SNAP / fxp and de0 cards.
When I do a "ifconfig fxp0 delete" and then a newaliases
the newaliases exits with a segmentation failt.
If I reconfig the device or up the device ... newaliases works
ok.
I then built a kernel with only 200 tun devices. Then newaliases
works everytime. It seems that gated also suffers from the same
problem in that if no device is configured it exits on signal 6
(core dumped)
Just for reference this works fine on a 2.2.7/8 FreeBSD without
any problems ...
The problem seems to be in conf.c of sendmail round line 4429
if there is 255 tun devices the for loop below only gets to
234 +/- and then doesn't check anything further and crashes
(but only if the working interface is deleted)
gdb shows that the pointer *sa points to somewhere wonderful :)
It must have something todo with the moving of this pointer
through the list ???
Was anything changed for the amount of tun devices allowed ??
for (i = 0; i < ifc.ifc_len; )
{
struct ifreq *ifr = (struct ifreq *) &ifc.ifc_buf[i];
SOCKADDR *sa = (SOCKADDR *) &ifr->ifr_addr;
struct in_addr ia;
#ifdef SIOCGIFFLAGS
struct ifreq ifrf;
#endif
char ip_addr[256];
extern char *inet_ntoa();
#ifdef BSD4_4_SOCKADDR
if (sa->sa.sa_len > sizeof ifr->ifr_addr)
i += sizeof ifr->ifr_name + sa->sa.sa_len;
else
#endif
i += sizeof *ifr;
if (tTd(0, 20))
printf("%s\n", anynet_ntoa(sa));
Thanx
Reinier
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
if.c and ifconf() possible error ?
Hi ...
When a program calls the SIOCGIFCONF ioctl and the
function ifconf in sys/net/if.c is executed, the value
that is returned in ifc.ifc_len, is that the value of
the amount of data filled in ... or can it be larger ??
Example ...
The calling process sends 1000 as the size of the buffer.
ifconf loops through the number of interfaces and sees that
there are more interfaces than can fit into this buffer. It
then fills the buffer to 960 bytes fulle and the one of
the checks fail ... should ifconf return the value
960 in ifc.ifc_len or should it return 1000 ??
The reason I ask .. it seems like it returns 1000 rather than
960 ... this causes sendmail to think that there is still
another device in the list ... it tries to read this ... and it
gets a structure with a lot of zero's (because ifconf rightly so
didn't fill it in) but the next one causes a segmentation fault
in sendmails conf.c in the function load_if_names.
This ONLY happens with sendmail and if you have more than 230 odd
onterfaces configured in your kernel AND NO interfaces are
ifconfiged e.g. all are deleted.
If you increase the value given by sendmail to the SIOCGIFCONF call
(a bigger buffer) everything works fine.
If it is the job of the ifconf function to return the correct value
in ifc.ifc_len, I've included a patch below which causes the ifconf
function to return only how much it filled into the buffer and nothing
more. It fixes the problem with sendmail (actually newaliases).
Please check the changes as I haven't tested every possible senario.
Thanx
Reinier
*** if.c.orig Thu Jul 29 14:30:11 1999
--- if.cThu Jul 29 14:34:45 1999
***
*** 814,820
register struct ifnet *ifp = ifnet.tqh_first;
register struct ifaddr *ifa;
struct ifreq ifr, *ifrp;
! int space = ifc->ifc_len, error = 0;
ifrp = ifc->ifc_req;
for (; space > sizeof (ifr) && ifp; ifp = ifp->if_link.tqe_next) {
--- 814,820
register struct ifnet *ifp = ifnet.tqh_first;
register struct ifaddr *ifa;
struct ifreq ifr, *ifrp;
! int space = ifc->ifc_len, error = 0, unused = 0;
ifrp = ifc->ifc_req;
for (; space > sizeof (ifr) && ifp; ifp = ifp->if_link.tqe_next) {
***
*** 857,862
--- 857,864
sizeof (ifr));
ifrp++;
} else {
+ /* keep the value of unused space so far */
+ unused = space;
space -= sa->sa_len - sizeof(*sa);
if (space < sizeof (ifr))
break;
***
*** 871,879
if (error)
break;
space -= sizeof (ifr);
}
}
! ifc->ifc_len -= space;
return (error);
}
--- 873,883
if (error)
break;
space -= sizeof (ifr);
+ /* reset the unused space to zero */
+ unused = 0;
}
}
! ifc->ifc_len -= space + unused;
return (error);
}
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Endless loop in libpcap 2.2.x/3.x/-current
Hi ...
We are running a system where we use the libpcap to capture
packets from an ethernet device. We've been observing a problem where
the monitor program goes into an endless loop and spins for ever.
I've compiled the program with debugging on and observed that the
call-back function is called repeatedly from the libpcap library.
I examined the library and ended up in the pcap_read function in
pcap-bpf.c
The code follows
snip - snip - snip
round line 110 in 2.2.x and in -current
--
#define bhp ((struct bpf_hdr *)bp)
ep = bp + cc;
while (bp < ep) {
register int caplen, hdrlen;
caplen = bhp->bh_caplen;
hdrlen = bhp->bh_hdrlen;
/*
* XXX A bpf_hdr matches a pcap_pkthdr.
*/
(*callback)(user, (struct pcap_pkthdr*)bp, bp + hdrlen);
bp += BPF_WORDALIGN(caplen + hdrlen);
if (++n >= cnt && cnt > 0) {
p->bp = bp;
p->cc = ep - bp;
return (n);
}
}
#undef bhp
p->cc = 0;
return (n);
--
In our case (from the debug info obtained from our program, I can see that
bhp->bh_caplen and bhp->bh_hdrlen are both zero (0).
(gdb) p *(struct bpf_hdr *)pkt
$11 = {bh_tstamp = {tv_sec = 16652, tv_usec = 0}, bh_caplen = 0,
bh_datalen = 33555200, bh_hdrlen = 0}
pkt is bp received back from libpcap.
cnt is -1 when we installed the callback function.
As can be seen ... caplen and hdrlen is then set to 0. bp is smaller
than ep because cc >0 (data was read)
It enters the while loop, set caplen, hdrlen to 0, calls the callback
function. libpcap then tries to increment bp with the BPF_WORDALIGN
macro.
From bpf.h
#define BPF_ALIGNMENT sizeof(long)
#define BPF_WORDALIGN(x) (((x)+(BPF_ALIGNMENT-1))&~(BPF_ALIGNMENT-1))
This concludes to
(gdb) p (((0)+(sizeof(long)-1))&~(sizeof(long)-1))
$12 = 0
so bp is NOT incremented and the whole process is repeated and here it
gets stuck in the loop.
I attached a possible fix for this, please review, edit as necessar and
commit :)
The patch is to -current file, put should apply to most other versions
too.
Thankyou
Reinier
Index: pcap-bpf.c
===
RCS file: /home/freebsd-cvs/src/contrib/libpcap/pcap-bpf.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 pcap-bpf.c
*** pcap-bpf.c 1998/09/15 19:28:05 1.1.1.3
--- pcap-bpf.c 1999/09/10 10:11:49
***
*** 117,122
--- 117,130
* XXX A bpf_hdr matches a pcap_pkthdr.
*/
(*callback)(user, (struct pcap_pkthdr*)bp, bp + hdrlen);
+ /*
+* If we can't increment bp, get out of the while
+* We've atleast called the callback with the data
+* we have at out disposal - NB : it might be garbage
+*/
+ if (!BPF_WORDALIGN(caplen + hdrlen)) {
+ break;
+ }
bp += BPF_WORDALIGN(caplen + hdrlen);
if (++n >= cnt && cnt > 0) {
p->bp = bp;
Boot messages on console in 3.2
Hi ... I'm trying to get a 3.2-STABLE to boot via the serial console. I can get the "boot: " rompt and loader to display to the serial console, but after the 9 second delay it continues to boot but no output is generated to the screen (device probes etc.). After the boot has completed, the login prompt is displayed on the console and I can login. I just want it to display the boot information (probes ... hd ... etc.) the /boot.config file has the following option -h and that is the only line ... I have tried both -h and -P ... I have tried only -P The "show" command under loader shows that the console is set to comconsole I've also treid a kernel with "flags 0x01" to the atkbd ... but it also doesn't work and the "options COMCONSOLE" for the kernel is nolonger allowed according to config. Any ideas ? Thanx Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Which device should I make with this error?
Hi :) put the following line in your kernel config file .. recompile your kernel .. boot .. and then try the make again ... pseudo-device vn1 to create the floppy ... a vertual node is used .. hope this helps ... Reinier > During a make release for 3.2-RELEASE I get the following error: > > Making the regular boot floppy. > Compressing doc files... > sh -e /usr/src/release/scripts/doFS.sh -s mfsroot /R/stage /mnt 2880 > /R/stage/m > fsfd 8000 minimum2 > vnconfig: open: Device not configured > *** Error code 1 > > Stop. > *** Error code 1 > > What does this mean and how do I fix it? > > Thanks > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Cheers Reinier > On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: > > > > I guess I forgot about the overhead. I've tested between two > > > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL > > > Switch Full Duplex and never seen anything close to the speeds. > > > > using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp > > cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. > > > > i use these machines for stressing every else we have at work. > > Hmmm, has anyone tried a full duplex test before? Since it seems > like the bottleneck is really the speed of the disks.. > > > Cheers, > Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ > Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] > GaiaNet Corporation - M & C Estate / / / / | / | __] ] > Beverly Hills, California USA 90210 / / / / / |/ / | __] ] > HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Hi .. > > 1. If you want to test the network speed ... use ttcp or something > >that generates the data and doesn't read it from disk. > > ttcp works. The only problem is when I tried it in both > directions, at once. the total becomes 11.xMbytes/sec total as opposed to > 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with "netstat -in". If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. Also check with "netstat -sn" to see if there are any other counters that increase with the full-duplex transfers. > > 2. When doing full-duplex and using fxp cards, stay away from X-over > >cables ... use a full-duplex switch etc. ... the fxp cards are not > >made to work with X-over cables (as far as I know - ala Intel spec) > >note ... only for full-duplex tests. > > Does anyone actually use X-over cables for 100Mbps Full Duplex > since 3Com said CrossOver cables are not rated for 100Mbps or something > even though it's Cat5. Actually, in the older Intel docs for the Pro100B, > it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of "device timeouts". > > We have done tests in full-duplex with non Intel cards (because we did > > not have a switch at that time :)) and with max size packets we got around > > 188.00 Mbps using the de0 driver. > > Pretty interesting. How did you do the full duplex tests? > I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that "does not exist". The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the "non existing" machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
if_dl.h in stable causes sendmail segmentation
Hi ... I have the following situation... A machine running a 3.2-STABLE of a few weeks ago ... When the machine booted I saw that newaliases (sendmail -bi) exited with a segmentation fault. I further inspected and found that if I do a ifconfig of a interface (fxp0 or de0) newaliases is ok, but when I do an ifconfig fxp0 delete the newaliases exits on a segmentation fault. e.g. - Amnesiac# ifconfig -au de0: flags=8843 mtu 1500 inet 196.37.91.253 netmask 0xff00 broadcast 196.37.91.255 ether 00:e0:29:00:e5:19 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 Amnesiac# newaliases /etc/aliases: 19 aliases, longest 10 bytes, 190 bytes total Amnesiac# ifconfig de0 delete Amnesiac# newaliases Segmentation fault Amnesiac# ifconfig de0 up Amnesiac# newaliases /etc/aliases: 19 aliases, longest 10 bytes, 190 bytes total Amnesiac# -- I then used the kernel sources from a few weeks after the 3.2-RELEASE and compiled the kernel - now everything works ok ... no segmentation fault. I eventually traced the problem down to the following header file /usr/src/sys/net/if_dl.h If I use the old header file ... no problem ... use the latest one .. sendmail crashes (and looks like gated also does this). Here is the diff jarrow# diff -c if_dl.h ../../sys.new/net/if_dl.h *** if_dl.h Tue Jul 20 16:18:54 1999 --- ../../sys.new/net/if_dl.h Thu May 27 05:06:41 1999 *** *** 31,37 * SUCH DAMAGE. * *@(#)if_dl.h 8.1 (Berkeley) 6/10/93 ! * $Id: if_dl.h,v 1.6 1997/02/22 09:41:00 peter Exp $ */ #ifndef _NET_IF_DL_H_ --- 31,37 * SUCH DAMAGE. * *@(#)if_dl.h 8.1 (Berkeley) 6/10/93 ! * $Id: if_dl.h,v 1.6.4.1 1999/05/27 03:06:41 julian Exp $ */ #ifndef _NET_IF_DL_H_ *** *** 68,73 --- 68,75 u_char sdl_slen; /* link layer selector length */ charsdl_data[12]; /* minimum work area, can be larger; contains both if name and ll address */ + u_short sdl_rcf;/* source routing control */ + u_short sdl_route[16]; /* source routing information */ }; #define LLADDR(s) ((caddr_t)((s)->sdl_data + (s)->sdl_nlen)) -- Looks like the addition of the two last entries in the structure is the problem ?? Any ideas ?? Sendmail crashes in the routine in conf.c called "load_if_names()" where it cycles through the interfaces round line if (sa->sa.sa_len > sizeof ifr->ifr_addr) the address sa->sa seems to point so where If you want any more info .. just ask :) Thanx Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_dl.h in stable causes sendmail segmentation
Hi ... > In article <[EMAIL PROTECTED]>, > Reinier Bezuidenhout <[EMAIL PROTECTED]> wrote: > > > I have the following situation... > ... [various userland SEGVs traced down to a change in if_dl.h] The sendmail that SEGV was compiled with the kernel that causes the crash ... I did the make release myself on a machine ... :( so it is not an updated kernel error :) Thanx Reinier > > Just a guess: it sounds like the kind of thing that would happen if > you updated your kernel without also rebuilding userland. > > John > -- > John Polstra [EMAIL PROTECTED] > John D. Polstra & Co., Inc.Seattle, Washington USA > "No matter how cynical I get, I just can't keep up."-- Nora Ephron > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
newaliases and 256 tun devices
Hi ...
I previously mailed the same error ... and then I thought
it was a "miss-corrolation" between kernel sources and
userland. Since then I built a SNAP of 990726 sources
and tried the same thing and the error occured again .
Same sources used for the compile of the kernel and userlevel
binaries.
I've now traced the following down ... it has something todo
with the changes in net/if_dl.h (the entries added for
source routing and the fact that my kernel has
pseudo-device tun 255
in the config.
Setup.
PII400 / Asus P2-99 990726 SNAP / fxp and de0 cards.
When I do a "ifconfig fxp0 delete" and then a newaliases
the newaliases exits with a segmentation failt.
If I reconfig the device or up the device ... newaliases works
ok.
I then built a kernel with only 200 tun devices. Then newaliases
works everytime. It seems that gated also suffers from the same
problem in that if no device is configured it exits on signal 6
(core dumped)
Just for reference this works fine on a 2.2.7/8 FreeBSD without
any problems ...
The problem seems to be in conf.c of sendmail round line 4429
if there is 255 tun devices the for loop below only gets to
234 +/- and then doesn't check anything further and crashes
(but only if the working interface is deleted)
gdb shows that the pointer *sa points to somewhere wonderful :)
It must have something todo with the moving of this pointer
through the list ???
Was anything changed for the amount of tun devices allowed ??
for (i = 0; i < ifc.ifc_len; )
{
struct ifreq *ifr = (struct ifreq *) &ifc.ifc_buf[i];
SOCKADDR *sa = (SOCKADDR *) &ifr->ifr_addr;
struct in_addr ia;
#ifdef SIOCGIFFLAGS
struct ifreq ifrf;
#endif
char ip_addr[256];
extern char *inet_ntoa();
#ifdef BSD4_4_SOCKADDR
if (sa->sa.sa_len > sizeof ifr->ifr_addr)
i += sizeof ifr->ifr_name + sa->sa.sa_len;
else
#endif
i += sizeof *ifr;
if (tTd(0, 20))
printf("%s\n", anynet_ntoa(sa));
Thanx
Reinier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
if.c and ifconf() possible error ?
Hi ...
When a program calls the SIOCGIFCONF ioctl and the
function ifconf in sys/net/if.c is executed, the value
that is returned in ifc.ifc_len, is that the value of
the amount of data filled in ... or can it be larger ??
Example ...
The calling process sends 1000 as the size of the buffer.
ifconf loops through the number of interfaces and sees that
there are more interfaces than can fit into this buffer. It
then fills the buffer to 960 bytes fulle and the one of
the checks fail ... should ifconf return the value
960 in ifc.ifc_len or should it return 1000 ??
The reason I ask .. it seems like it returns 1000 rather than
960 ... this causes sendmail to think that there is still
another device in the list ... it tries to read this ... and it
gets a structure with a lot of zero's (because ifconf rightly so
didn't fill it in) but the next one causes a segmentation fault
in sendmails conf.c in the function load_if_names.
This ONLY happens with sendmail and if you have more than 230 odd
onterfaces configured in your kernel AND NO interfaces are
ifconfiged e.g. all are deleted.
If you increase the value given by sendmail to the SIOCGIFCONF call
(a bigger buffer) everything works fine.
If it is the job of the ifconf function to return the correct value
in ifc.ifc_len, I've included a patch below which causes the ifconf
function to return only how much it filled into the buffer and nothing
more. It fixes the problem with sendmail (actually newaliases).
Please check the changes as I haven't tested every possible senario.
Thanx
Reinier
*** if.c.orig Thu Jul 29 14:30:11 1999
--- if.cThu Jul 29 14:34:45 1999
***
*** 814,820
register struct ifnet *ifp = ifnet.tqh_first;
register struct ifaddr *ifa;
struct ifreq ifr, *ifrp;
! int space = ifc->ifc_len, error = 0;
ifrp = ifc->ifc_req;
for (; space > sizeof (ifr) && ifp; ifp = ifp->if_link.tqe_next) {
--- 814,820
register struct ifnet *ifp = ifnet.tqh_first;
register struct ifaddr *ifa;
struct ifreq ifr, *ifrp;
! int space = ifc->ifc_len, error = 0, unused = 0;
ifrp = ifc->ifc_req;
for (; space > sizeof (ifr) && ifp; ifp = ifp->if_link.tqe_next) {
***
*** 857,862
--- 857,864
sizeof (ifr));
ifrp++;
} else {
+ /* keep the value of unused space so far */
+ unused = space;
space -= sa->sa_len - sizeof(*sa);
if (space < sizeof (ifr))
break;
***
*** 871,879
if (error)
break;
space -= sizeof (ifr);
}
}
! ifc->ifc_len -= space;
return (error);
}
--- 873,883
if (error)
break;
space -= sizeof (ifr);
+ /* reset the unused space to zero */
+ unused = 0;
}
}
! ifc->ifc_len -= space + unused;
return (error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Endless loop in libpcap 2.2.x/3.x/-current
Hi ...
We are running a system where we use the libpcap to capture
packets from an ethernet device. We've been observing a problem where
the monitor program goes into an endless loop and spins for ever.
I've compiled the program with debugging on and observed that the
call-back function is called repeatedly from the libpcap library.
I examined the library and ended up in the pcap_read function in
pcap-bpf.c
The code follows
snip - snip - snip
round line 110 in 2.2.x and in -current
--
#define bhp ((struct bpf_hdr *)bp)
ep = bp + cc;
while (bp < ep) {
register int caplen, hdrlen;
caplen = bhp->bh_caplen;
hdrlen = bhp->bh_hdrlen;
/*
* XXX A bpf_hdr matches a pcap_pkthdr.
*/
(*callback)(user, (struct pcap_pkthdr*)bp, bp + hdrlen);
bp += BPF_WORDALIGN(caplen + hdrlen);
if (++n >= cnt && cnt > 0) {
p->bp = bp;
p->cc = ep - bp;
return (n);
}
}
#undef bhp
p->cc = 0;
return (n);
--
In our case (from the debug info obtained from our program, I can see that
bhp->bh_caplen and bhp->bh_hdrlen are both zero (0).
(gdb) p *(struct bpf_hdr *)pkt
$11 = {bh_tstamp = {tv_sec = 16652, tv_usec = 0}, bh_caplen = 0,
bh_datalen = 33555200, bh_hdrlen = 0}
pkt is bp received back from libpcap.
cnt is -1 when we installed the callback function.
As can be seen ... caplen and hdrlen is then set to 0. bp is smaller
than ep because cc >0 (data was read)
It enters the while loop, set caplen, hdrlen to 0, calls the callback
function. libpcap then tries to increment bp with the BPF_WORDALIGN
macro.
>From bpf.h
#define BPF_ALIGNMENT sizeof(long)
#define BPF_WORDALIGN(x) (((x)+(BPF_ALIGNMENT-1))&~(BPF_ALIGNMENT-1))
This concludes to
(gdb) p (((0)+(sizeof(long)-1))&~(sizeof(long)-1))
$12 = 0
so bp is NOT incremented and the whole process is repeated and here it
gets stuck in the loop.
I attached a possible fix for this, please review, edit as necessar and
commit :)
The patch is to -current file, put should apply to most other versions
too.
Thankyou
Reinier
Index: pcap-bpf.c
===
RCS file: /home/freebsd-cvs/src/contrib/libpcap/pcap-bpf.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 pcap-bpf.c
*** pcap-bpf.c 1998/09/15 19:28:05 1.1.1.3
--- pcap-bpf.c 1999/09/10 10:11:49
***
*** 117,122
--- 117,130
* XXX A bpf_hdr matches a pcap_pkthdr.
*/
(*callback)(user, (struct pcap_pkthdr*)bp, bp + hdrlen);
+ /*
+* If we can't increment bp, get out of the while
+* We've atleast called the callback with the data
+* we have at out disposal - NB : it might be garbage
+*/
+ if (!BPF_WORDALIGN(caplen + hdrlen)) {
+ break;
+ }
bp += BPF_WORDALIGN(caplen + hdrlen);
if (++n >= cnt && cnt > 0) {
p->bp = bp;
pcm sound delays
Hi ... Im running 4.0-CURRENT of a few weeks ago, I've got a ESS1869 soundcard, which seems to be working reasonably well with the newpcm. What I am though experiencing is some delay in sound e.g. xgal (xgalaga) and a few other splications. The sound is not in sync with the application. When I quit/kill the application sound is sometimes still generated for quite a few second after the application has died. Anyone got any ideas what causes this and maybe how to fix it ??? Thanks Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
More libpcap problems
Hi ...
I have an application which uses libpcap ... after running for several
weeks normally .. the application coredumps .. I've traced the problem
back to libpcap which somehow reads garbage packet information (or is
given garbage). Here is a short view of the gdb ..
(gdb) p *(struct bpf_hdr *)pkt
$2 = {bh_tstamp = {tv_sec = 0, tv_usec = 0}, bh_caplen = 0,
bh_datalen = 4294922246, bh_hdrlen = 24577}
(gdb) p *pkt
$3 = {ts = {tv_sec = 0, tv_usec = 0}, caplen = 0, len = 4294922246}
(gdb)
Take a look at the bh_datalen and bh_hdrlen ... those values are
not ok. The only value which makes sense is the bh_caplen. Should
I use that to determine if I should try and examine the packet ???
I've already had to make a change to libpcap where it got stuck
in and endless loop after receiving such "bad" data. (It has been
submitted in a PR)
Thanks
Reinier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
TCP delay ack question
Hi ... We have two machines that are experiencing some interesting behaviour. The one is running a 2.1.5 FreeBSD kernel (yes old) and the other a 2.2.6-STABLE kernel (also a bit old :) ) The problem is that when transfering mail to the 2.1.5 machine it happens quite quickly, but on the 2.2.6 machine it is a lot slower. When sending from another client it is fast through both machines. After examining the packets with tcpdump, I saw that when a transfer is slow ... there are no tos flags set on the packets, when the transfer is fast .. the client sets tos 0x10 (priority) on the all the packets. I then read through TCP/IP Illustrated Vol 2 .. and came accros the TF_DELACK option which delays ACKs up to 0.5 sec with a 200ms timer interval. This seems to correlate with the slow transfers as the client would send two packets (the last with the PUSH flag set) and then the FreeBSD machine would only send the ack after 0.2 seconds. Is this correct behaviour ? The question .. Should the client always set 0x10 in the tos field ... (we don't have control over the clients) or is it possible to ignore this on the FreeBSD server (we do not yet have the sysctl option to disable the delay on acks) Thanks Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cc -pthread and libc_r question
Hi .. I've compiled a program with the -pthread compiler option on a 3.3-STABLe system ... after doing a ldd on the executable I see that both libc_r AND lic are linked .. is this correct ? Shouldn't libc_r replace libc ? Thanks Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
