Re: device.hints(5) typo fix
On Tue, 19 Oct 2010, 18:58-0700, Garrett Cooper wrote: Something trivial I noticed while browsing device.hints(5) today. If someone could commit the typo fix, it would be much appreciated. Fixed. Thanks! -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: an alternative to powerpoint
On Tue, 13 Jul 2010, 16:17+0300, Peter Pentchev wrote: On Tue, Jul 13, 2010 at 06:15:14AM +0200, Luigi Rizzo wrote: Maybe you all love powerpoint for presentations, but sometimes one just needs to put together a few slides, perhaps a few bullets or images grabbed around the net, so i was wondering how hard would it be to do something that accepts a plain text file as input (without a ton of formatting) and lets you do a decent slide show, and supports editing the slides on the fly within the browser. Well, it's not too hard: http://info.iet.unipi.it/~luigi/sttp/ just 400 lines of javascript and 100 lines of css, plus your human-readable text. Nice work indeed! Just as an aside, though - are you aware of Eric Meyer's S5, also available in your friendly neighbourhood Ports Collection as textproc/s5? :) But yours does look a bit simpler to enter text in, although I myself am quite used to typing HTML. + misc/magicpoint. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Simulating bad network conditions
On Wed, 18 Feb 2009, 08:34-, xorquew...@googlemail.com wrote: Hello. I want to verify that a program I'm developing works correctly in poor network conditions (high latency, random packet loss, etc). I seem to remember reading something once about somebody simulating these conditions with PF but can't remember where. Anybody got any ideas about how I could go about doing this? ipfw(8) prob + dummynet(8). -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
On Fri, 16 Jan 2009, 00:44-0800, Garrett Cooper wrote: On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper yanef...@gmail.com wrote: Hi amd64 and Hackers, Uh, I'm really confused why 1) this error (errno = ENOMEM) would occur when I have more than enough free memory (both on x86 and amd64) and 2) why strerror would segfault in the call to errx in the attached sourcefile on amd64 only. Not initializing len causes the second output sample (errno = 14, which is EFAULT). Any ideas? - size_t len; + size_t len = 4; -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /var/log/messages logs appear in the output of sysctl -a
On Wed, 7 Jan 2009, 13:14+0100, Gary Jennejohn wrote: On Wed, 7 Jan 2009 13:30:20 +0200 Eitan Shefi eit...@mellanox.co.il wrote: I am testing a NIC driver. I found it's logs and /var/log/messages logs in the output of sysctl -a: I run sysctl -a | less, and there I find: kern.devstat.version: 6 kern.devstat.generation: 137 kern.devstat.numdevs: 1 kern.kobj_methodcount: 143 kern.log_wakeups_per_second: 5 kern.msgbuf_clear: 0 kern.msgbuf: ound file system checks in 60 seconds. 118 mtnic0: FW version:2.6.0 mtnic0: Board ID: mtnic0: Using 1 tx rings for port:1 [4096] mtnic0: Using 4 rx rings for port:1 [1024] mtnic0: Using 1 tx rings for port:2 [4096] mtnic0: Using 4 rx rings for port:2 [1024] mtnic0: Initializing MSIX mtnic0: Enabling MSI-X (11 vectors) mtnic0: Board ID:MT_0BD0110004 mtnic0: [ITHREAD] mtnic0: Activating port:1 mtnic0: Ethernet address: 00:02:c9:03:35:20 mtnic0: Activating port:2 mtnic1: Ethernet address: 00:02:c9:03:35:21 mtnic0: [ITHREAD] mtnic0: [ITHREAD] mtnic0: mtnic0: mtnic0: mtnic0: Port 1 - link up mtnic0: [ITHREAD] mtnic0: [ITHREAD] mtnic0: [ITHREAD] Limiting icmp ping response from 300 to 200 packets/sec Limiting icmp ping response from 300 to 200 packets/sec Limiting icmp ping response from 1497 to 200 packets/sec Limiting icmp ping response from 1500 to 200 packets/sec Limiting icmp ping response from 1498 to 200 packets/sec Limiting icmp ping response from 1500 to 200 packets/sec Any idea how can such logs apear in sysctl -a ? If you were viewing this as root on the console then you were simply seeing kernel output interleaved with the output from sysctl. This is just an output from sysctl kern.msgbuf. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IPv6 CVS
On Tue, 5 Aug 2008, 19:52+1000, Tim Clewlow wrote: Hi all, Does anyone know if there are any IPv6 CVS servers for FreeBSD? (As in receiving the STABLE and ports branches) I currently use cvs.freebsd.org but it dosent have an record. Ta Peg dig cvsup4.freebsd.org cvs != cvsup. Speaking of cvsup -- cvsup4.ru.freebsd.org has an ipv6 address as well. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch for ping6 -o
On Thu, 15 Nov 2007, 12:01-, Dima Dorfman wrote: The ping(8) utility has an -o switch that tells it to exit after receiving the first reply. This is useful, but ping6(8) doesn't have it. Simple patch attached. Comments/reviews/whatnots? I'll commit to HEAD in a few days if I don't hear any objections. You forgot to update usage(). -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 1000+ day uptime 5.3-RELEASE box
On Mon, 12 Nov 2007, 04:08-0600, Kevin Day wrote: We installed a 5.3-RELEASE box back in 2004, and it's been running pretty hard ever since with no crashes, reboots or anything. We're about to finally take it down to upgrade the OS soon - are there any stats anyone wants to see before we do? I know in the past there have been some I wonder if that code path ever happened musings that maybe I can answer. The system is running lighttpd/php/mysql on a pretty busy website non-stop during that period. Pasted below are some stats that I thought someone might want to see, even if it's just searching the archives later. I have no idea which of these counters have wrapped around. The netstat -m counters definitely don't look right. Email me in the next few days if you want to see something I haven't yet pasted: ts1# uptime 9:35AM up 1076 days, 19 hrs, 1 user, load averages: 0.43, 0.35, 0.31 4.x is way better :-) $ uptime 6:06PM up 1725 days, 23:07, 1 user, load averages: 0.31, 0.30, 0.26 $ uname -r 4.4-RC [ we need to redirect this thread to -chat :-) ] -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: indefinite wait buffer patch
On Fri, 2 Nov 2007, 12:59-0500, Mark Tinguely wrote:
Since eyeballs are in swap_page.c - is the putpages panic string mislabeled:
swap_pager_putpages(vm_object_t object, vm_page_t *m, int count,
boolean_t sync, int *rtvals)
{
int i;
int n = 0;
if (count m[0]-object != object) {
panic(swap_pager_getpages: object mismatch %p/%p,
putpages
Just fixed. Thanks.
--
Maxim Konovalov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
tunefs.8 oddity
Hello, after spending a half an hour trying to help a friend of mine to turn soft updates on the root filesystem on I'd like to revert a part of rev. 1.21 just because it makes life of an average sysadmin easier: Index: tunefs.8 === RCS file: /home/ncvs/src/sbin/tunefs/tunefs.8,v retrieving revision 1.37 diff -u -p -r1.37 tunefs.8 --- tunefs.831 Oct 2006 21:52:28 - 1.37 +++ tunefs.820 Jul 2007 14:57:30 - @@ -165,6 +165,8 @@ utility appeared in .Bx 4.2 . .Sh BUGS This utility should work on active file systems. +To change the root filesystem, the system must be rebooted +after the filesystem is tuned. .\ Take this out and a Unix Daemon will dog your steps from now until .\ the time_t's wrap around. .Pp %%% Any objections? -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tunefs.8 oddity
On Fri, 20 Jul 2007, 23:21+0800, Xin LI wrote: Maxim Konovalov wrote: Hello, after spending a half an hour trying to help a friend of mine to turn soft updates on the root filesystem on I'd like to revert a part of rev. 1.21 just because it makes life of an average sysadmin easier: Index: tunefs.8 === RCS file: /home/ncvs/src/sbin/tunefs/tunefs.8,v retrieving revision 1.37 diff -u -p -r1.37 tunefs.8 --- tunefs.831 Oct 2006 21:52:28 - 1.37 +++ tunefs.820 Jul 2007 14:57:30 - @@ -165,6 +165,8 @@ utility appeared in .Bx 4.2 . .Sh BUGS This utility should work on active file systems. +To change the root filesystem, the system must be rebooted +after the filesystem is tuned. .\ Take this out and a Unix Daemon will dog your steps from now until .\ the time_t's wrap around. .Pp %%% Any chance that we resolve the bug instead of documenting it? :-) Personally, I have no energy/time for that. It was documented for ages, it is still documented in other BSDs. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPEK/TouchChip Biometric Device problem
On Tue, 26 Jun 2007, 15:40-0300, Patrick Tracanelli wrote: Maxim Konovalov wrote: On Fri, 22 Jun 2007, 17:42-0300, Patrick Tracanelli wrote: Hello all, I have used the mentioned devices on FreeBSD 5.4 in the past, and they worked just fine, but now I get problems with the same device, on top of 6.2-STABLE and also 7.0-CURRENT. [...] Just for the record: the above mentioned device works fine on lenovo x60s and 6.2-STABLE. Is it 0?0483 vendor and 0?2016 device? Which revision? Can you please send the relevant output from usbdevs -v and the ugen device from /var/run/dmesg.boot? port 2 addr 2: full speed, power 100 mA, config 1, Biometric Coprocessor(0x2016), STMicroelectronics(0x0483), rev 0.01 Controller /dev/usb4: ugen0: STMicroelectronics Biometric Coprocessor, rev 1.00/0.01, addr 2 -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPEK/TouchChip Biometric Device problem
On Fri, 22 Jun 2007, 17:42-0300, Patrick Tracanelli wrote: Hello all, I have used the mentioned devices on FreeBSD 5.4 in the past, and they worked just fine, but now I get problems with the same device, on top of 6.2-STABLE and also 7.0-CURRENT. [...] Just for the record: the above mentioned device works fine on lenovo x60s and 6.2-STABLE. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPEK/TouchChip Biometric Device problem
[...] Exactly the same. Did you do anything different from using securyt/bioapi, securiy/bsp_upektfmess and security/pam_bsdbioapi and creating birdb.conf? No, I didn't. It works out of the box. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: module for kernel
On Sun, 20 May 2007, 15:59+0330, Mohsen Pahlevanzadeh wrote: Dear all, When you wanna write a module for linux kernel,you have 2 function: init_module() cleanup_module() But now i need to write a little module for FreeBSD kernel.Please guide me. Check /usr/share/examples/kld/ . -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Zombie Jails - why don't they disappear?
On Thu, 22 Feb 2007, 01:21+0800, LI Xin wrote: Josef Karthauser wrote: I've got zombie jails on a freebsd 6.x box (currently 6.2). There are no processes running under any of them, but they still appear on the jail list: server# jls JID IP Address Hostname Path 2 xxx.xxx.1.234host1.domain /data/jails/host1 1 xxx.xxx.1.235host2.domain /data/jails/host2 I'm flumoxed as to why they're still there. There aren't any processes running in them: server# ps -auxww | grep J Any ideas why they are still hanging around in the jail list? Sockets (stuck in a state which can not be released immediately?) or other resources? I really think that this is a bug, though. It was discussed millon times already and there is at least one open PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/group limits (REAL limits)
On Tue, 6 Feb 2007, 22:56-0600, Eric Anderson wrote: On one of my boxes where I have a decent amount of (less than 50) users in a few groups, I finally hit the limit. Not 1024 bytes though (that I know of). When that happens though, it is sooner than expected, and tools (like 'id') seg fault (and core dump). I have a sample group, and it appears to be hitting the byte limit. If I add a single additional character to the group, it will break things. It appears to be a combination of multiple groups. Can someone with some experience in this area comment? I can send the group file itself if needed. This box is 6.2-PRERELEASE from about mid-September. I have also seen some issues on amd64, which I went through some debugging with Konstantin Belousov back in November (cc'ed). Make sure you have rev. 1.32.8.3 of lib/libc/gen/getgrent.c. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to stop a jail
On Fri, 1 Dec 2006, 10:43-, Steven Hartland wrote: We've got a jail here which we cant stop with either killall jexec or jkill all return success but jls still reports the jail as running. The machines running several other jails which I cant restart at this time so I ended up starting the jail again jls now reports: jls JID IP Address Hostname Path 9 10.10.0.5 jail6/usr/local/jails/jail6 7 10.10.0.5 jail6/usr/local/jails/jail6 6 10.10.0.4 jail5/usr/local/jails/jail5 5 10.10.0.39jail4/usr/local/jails/jail4 3 10.10.0.6 jail3/usr/local/jails/jail3 2 10.10.0.8 jail2/usr/local/jails/jail2 1 10.10.0.7 jail1/usr/local/jails/jail1 Host machine is running FreeBSD-6.1-P10 Any ideas some sort of kernel data corruption? Known bug, discussed several times. IIRC leaked struct ucred. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: style(9)-like guide for man pages
On Mon, 21 Aug 2006, 18:50+0200, Max Laier wrote: On Monday 21 August 2006 18:26, Kostik Belousov wrote: is there style(9)-like guide for writing FreeBSD man pages ? man mdoc aka GROFF_MDOC(7) is the closest one I can think of. + /usr/share/examples/mdoc/ -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A bug in semctl()
On Wed, 26 Jul 2006, 15:50+0800, юНип╫э wrote:
In file kern/sysv_sem.c:
554 __semctl(td, uap)
555 struct thread *td;
556 struct __semctl_args *uap;
557 {
558 int semid = uap-semid; here 1
559 int semnum = uap-semnum;
560 int cmd = uap-cmd;
561 u_short *array;
562 union semun *arg = uap-arg;
563 union semun real_arg;
564 struct ucred *cred = td-td_ucred;
565 int i, rval, error;
566 struct semid_ds sbuf;
567 struct semid_kernel *semakptr;
568 struct mtx *sema_mtxp;
569 u_short usval, count;
570
571 DPRINTF((call to semctl(%d, %d, %d, 0x%x)\n,
572 semid, semnum, cmd, arg));
573 if (!jail_sysvipc_allowed jailed(td-td_ucred))
574 return (ENOSYS);
575
576 array = NULL;
577
578 switch(cmd) {
579 case SEM_STAT:
580 if (semid 0 || semid = seminfo.semmni) here 2
581 return (EINVAL);
582 if ((error = copyin(arg, real_arg, sizeof(real_arg))) !=
0)
583 return (error);
584 semakptr = sema[semid];here 3
From line 558 to line 578, there must be a mechism to convert the
sem_id to the internal sema array index. In fact, it was missing,
which make the semctl syscall not work well.
What version of the file do you read? We have a different code in
HEAD.
--
Maxim Konovalov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help? 6.1-S: Fatal trap 12: page fault while in kernel mode
On Fri, 16 Jun 2006, 08:45-0700, David Wolfskill wrote: On Thu, Jun 15, 2006 at 04:22:40PM -0700, David Wolfskill wrote: I had one of these [kernel panics] a couple of weeks ago or so... ...[upgrade to -STABLE as of 15 June; repeat panic]... The message to which I'm replying (posted to -stable) has the particulars about the panic in question, and the machine in question is still sitting at the DDB prompt, if anyone wishes to work with me on that. But the reason for this message is to report that I upgraded the other test machines -- identical confguration: 2x3 GHz Xeons w/ 4 GB RAM; kernel config is called SMP_PAE_DDB for a fairly good reason -- to today's -CURRENT, then started the same test that cause -STABLE to crash burn within a couple of minutes. That was 30 minutes ago; the test is still running on FreeBSD localhost 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Fri Jun 16 07:28:18 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP_PAE_DDB i386 As I commented in email to some colleagues, color me surprised. I've suggested to the vendor (the program under test on the box is from a vendor, built under for FreeBSD 5.x; I'm using the misc/compat5x port) that they consider trying this themselves, and perhaps also take advantage of John Birrell's work to date on the FreeBSD port of DTrace. I'm still not too keen to run a production workload on a -CURRENT platform. I don't know if whatever is causing -CURRENT to keep running while -STABLE dies is an MFC candidate, but it seems to me that identifying the salient change(s) would be helpful in figuring that out. Any suggestions for how to go about doing that? trace in ddb would be good start. Do you really need PAE? -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fdisk partition / disklabel recovery (help!)
[...] Is there any additional ways I can find the partitioning scheme, or find the bsdlabel's on the disk? Does anyone know of a command line (dd+some tools/perl/etc) way to find the bsdlabels? ports/sysutils/scan_ffs/ src/tools/tools/find-sb/ Once the bsdlabels are found, then what? Restore it, bsdlabel -e. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: porting NetBSD fsdb enhancements to FreeBSD
On Tue, 23 May 2006, 00:19+0400, Maxim Konovalov wrote: Hi Matt, On Fri, 28 Oct 2005, 00:59-0400, Matt Emmerton wrote: Recently I've had to do some low-level surgery on some disks that have gone bad in order to recover some of the data. This has required me to zero out blocks on disk, patch up the affected files, and pull the data off the disks. I was toying around the with fsdb tool, but couldn't figure out a way to map blocks to inodes (although the 'blocks' command does the mapping in the other direction quite nicely.) Poking around I found that someone has added this functionality (via a findblk command) to NetBSD's fsdb (back in 2003!), which I have grafted onto a 4.x box here with relative ease. NetBSD Mailing List Posting: http://groups.google.com/group/mailing.netbsd.tech.userlevel/browse_thread/thread/18acceb04cf5aadb/2a891d67edf9279%232a891d67edf9279?sa=Xoi=groupsrstart=0num=3) NetBSD CVS: http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/fsdb/fsdb.c.diff?r1=1.24r2=1.25f=h Is this something that folks would like to see on FreeBSD? I've got RELENG_5_4 and RELENG_6_0 boxes here in my office so I can whip up the patches and do some testing in short order. I think it is a useful functionality. Here is a patch based on NetBSD code for HEAD, should work for RELENG_5 and RELENG_6 also. [ patch skipped ] For the record: I committed this code to HEAD. Here is another cookie for fsdb(8): show and set inode birth time. http://people.freebsd.org/~maxim/diff/fsdb-btime.diff -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: truncate tool - must be root?
On Tue, 30 May 2006, 10:59-0500, Eric Anderson wrote: Is it expected that truncate(8) must be used by a superuser? If so, then the man page should probably mention it. If not, then it's broken :) Works for me: $ truncate -s 100g 100g $ ls -l 100g -rw-r--r-- 1 maxim maxim 107374182400 May 30 20:11 100g $ id uid=1001(maxim) gid=1001(maxim) groups=1001(maxim), 0(wheel), 5(operator), 68(dialer) -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1 crash data (was: Re: no core file handler recognizes format)
On Sun, 28 May 2006, 13:30-0700, Avleen Vig wrote: On Mon, May 15, 2006 at 10:58:02AM -0700, Avleen Vig wrote: On Sat, May 13, 2006 at 11:40:33AM +0400, Stanislav Sedov wrote: Rebuild your kernel with INVARIANTS enabled and debug info. It will provide more information in case the crash happens again. Ok, I finally got a core file with the crash :-) Where's what some of kgdb tells me. All I can tell, is that the bug happened somewhere around trying to set a TOS value for an outbound network packet? Help please? [...] As I already said the issue is known. Please send the backtrace as a followup to kern/97095. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: porting NetBSD fsdb enhancements to FreeBSD
++) {
+ /*
+* Does the block we are looking for belongs to the
+* indirect blocks?
+*/
+ if (is_ufs2 ?
+ compare_blk64(wantedblk64, curinode-dp2.di_ib[i]) :
+ compare_blk32(wantedblk32, curinode-dp1.di_ib[i]))
+ if (founddatablk(is_ufs2 ? curinode-dp2.di_ib[i] :
+ curinode-dp1.di_ib[i]))
+ goto end;
+ /*
+* Search through indirect, double and triple indirect
+* data blocks.
+*/
+ if (is_ufs2 ? (curinode-dp2.di_ib[i] != 0) :
+ (curinode-dp1.di_ib[i] != 0))
+ if (is_ufs2 ?
+ find_indirblks64(curinode-dp2.di_ib[i], i,
+ wantedblk64) :
+ find_indirblks32(curinode-dp1.di_ib[i], i,
+ wantedblk32))
+ goto end;
+ }
+ }
+}
+end:
+curinum = ocurrent;
+curinode = ginode(curinum);
+return 0;
+}
+
+static int
+compare_blk32(uint32_t *wantedblk, uint32_t curblk)
+{
+int i;
+
+for (i = 0; i wantedblksize; i++) {
+ if (wantedblk[i] != 0 wantedblk[i] == curblk) {
+ wantedblk[i] = 0;
+ return 1;
+ }
+}
+return 0;
+}
+
+static int
+compare_blk64(uint64_t *wantedblk, uint64_t curblk)
+{
+int i;
+
+for (i = 0; i wantedblksize; i++) {
+ if (wantedblk[i] != 0 wantedblk[i] == curblk) {
+ wantedblk[i] = 0;
+ return 1;
+ }
+}
+return 0;
+}
+
+static int
+founddatablk(uint64_t blk)
+{
+
+printf(%llu: data block of inode %d\n,
+ (unsigned long long)fsbtodb(sblock, blk), curinum);
+findblk_numtofind--;
+if (findblk_numtofind == 0)
+ return 1;
+return 0;
+}
+
+static int
+find_blks32(uint32_t *buf, int size, uint32_t *wantedblk)
+{
+int blk;
+for (blk = 0; blk size; blk++) {
+ if (buf[blk] == 0)
+ continue;
+ if (compare_blk32(wantedblk, buf[blk])) {
+ if (founddatablk(buf[blk]))
+ return 1;
+ }
+}
+return 0;
+}
+
+static int
+find_indirblks32(uint32_t blk, int ind_level, uint32_t *wantedblk)
+{
+#define MAXNINDIR (MAXBSIZE / sizeof(uint32_t))
+uint32_t idblk[MAXNINDIR];
+int i;
+
+bread(fsreadfd, (char *)idblk, fsbtodb(sblock, blk),
(int)sblock.fs_bsize);
+if (ind_level = 0) {
+ if (find_blks32(idblk, sblock.fs_bsize / sizeof(uint32_t), wantedblk))
+ return 1;
+} else {
+ ind_level--;
+ for (i = 0; i sblock.fs_bsize / sizeof(uint32_t); i++) {
+ if (compare_blk32(wantedblk, idblk[i])) {
+ if (founddatablk(idblk[i]))
+ return 1;
+ }
+ if (idblk[i] != 0)
+ if (find_indirblks32(idblk[i], ind_level, wantedblk))
+ return 1;
+ }
+}
+#undef MAXNINDIR
+return 0;
+}
+
+static int
+find_blks64(uint64_t *buf, int size, uint64_t *wantedblk)
+{
+int blk;
+for (blk = 0; blk size; blk++) {
+ if (buf[blk] == 0)
+ continue;
+ if (compare_blk64(wantedblk, buf[blk])) {
+ if (founddatablk(buf[blk]))
+ return 1;
+ }
+}
+return 0;
+}
+
+static int
+find_indirblks64(uint64_t blk, int ind_level, uint64_t *wantedblk)
+{
+#define MAXNINDIR (MAXBSIZE / sizeof(uint64_t))
+uint64_t idblk[MAXNINDIR];
+int i;
+
+bread(fsreadfd, (char *)idblk, fsbtodb(sblock, blk),
(int)sblock.fs_bsize);
+if (ind_level = 0) {
+ if (find_blks64(idblk, sblock.fs_bsize / sizeof(uint64_t), wantedblk))
+ return 1;
+} else {
+ ind_level--;
+ for (i = 0; i sblock.fs_bsize / sizeof(uint64_t); i++) {
+ if (compare_blk64(wantedblk, idblk[i])) {
+ if (founddatablk(idblk[i]))
+ return 1;
+ }
+ if (idblk[i] != 0)
+ if (find_indirblks64(idblk[i], ind_level, wantedblk))
+ return 1;
+ }
+}
+#undef MAXNINDIR
+return 0;
+}
+
int findino(struct inodesc *idesc); /* from fsck */
static int dolookup(char *name);
%%%
--
Maxim Konovalov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_6 network stack locking problems? (Was: no core file handler recognizes format)
On Fri, 12 May 2006, 18:40-0700, Avleen Vig wrote:
On Sat, May 13, 2006 at 02:39:19AM +0400, Stanislav Sedov wrote:
You should use kgdb rather the gdb. GDB doesn't recognizes kernel
dumps format by default.
Ah thank you!
Here's the information I found.
Any help that anyone can provide will go into a nice little crash
debugging for beginners document which I've started working on :-)
Ok kgdb tells me:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x58
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc06005aa
stack pointer = 0x28:0xd6c13ad0
frame pointer = 0x28:0xd6c13b00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 25911 (python)
trap number = 12
panic: page fault
Uptime: 14h49m8s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
The few lines before trap() was called look like this:
#5 0xc071a38d in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi = 0, tf_ebp =
-691979520, tf_isp = -691979588, tf_ebx = -691979136, tf_edx = -691978864,
tf_ecx = 0, tf_eax = 8, tf_trapno = 12, tf_err = 2, tf_eip = -1067448918,
tf_cs = 32, tf_eflags = 66183, tf_esp = -691979136, tf_ss = -691979544})
at /usr/src/sys/i386/i386/trap.c:434
#6 0xc070814a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc06005aa in ip_ctloutput (so=0x8, sopt=0xd6c13c80)
at /usr/src/sys/netinet/ip_output.c:1210
Yes, it is known issue, see kern/97095. Perhaps kern/96413 is related
too. I'm trying to get inpcb locking logic at the moment. We need
Robert Watson attention :-)
--
Maxim Konovalov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Adding a ``user'' mount option
Hi Joe, On Mon, 3 Apr 2006, 01:32-0400, Joe Marcus Clarke wrote: I know we have vfs.usermount, but this is not always sufficient since the user has to own the mount point in question. What I propose is to add a ``user'' mount option ? la Linux. This would make mount and umount setuid root, but would allow much more flexibility when it comes to removable media and desktop systems. Personally I have no problems with vfs.usermount and removal medias on FreeBSD-based desktops but a new suid binary in the system just scare me. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslogd not draining
On Mon, 27 Mar 2006, 12:38-0500, Michael W. Lucas wrote: On Mon, Mar 27, 2006 at 06:18:50PM +0200, Borja Marcos wrote: I've got a machine running syslogd, DNS, DHCP, flow-capture, and other assorted UDP-loving programs. Occasionally, they all stop working. The machine has been up for a couple of hours now, and I see: ns1/etc;netstat -s | grep full Warning: sysctl(net.inet6.ip6.rip6stats): No such file or directory 122066 dropped due to full socket buffers ns1/etc; I've doubled kern.ipc.maxsockbuf a couple of times now, and yet it still happens. That's not enough. You need to teach syslogd to use this new value. After some help from questions@, I'm pretty sure that the culprit is syslogd. udp4 0 0 *.67 *.* udp4 43414 0 *.514 *.* udp4 0 0 *.49661*.* Are you using a serial console? I had similar problems in the past due to the serial port flow control. I've disabled syslog to the console, writing instead to /var/log/console.log. Moments after doing that, the problem reoccured. Thanks, Borja, but no success. :-( Any other suggestions, folks? What's the incoming udp datagrams rate? netstat -sp udp | grep 'datagrams received'; sleep 10; \ netstat -sp udp | grep 'datagrams received' How much cpu time does syslogd use? -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslogd not draining
[] ns1/etc;netstat -s | grep full Warning: sysctl(net.inet6.ip6.rip6stats): No such file or directory 122066 dropped due to full socket buffers ns1/etc; I've doubled kern.ipc.maxsockbuf a couple of times now, and yet it still happens. That's not enough. You need to teach syslogd to use this new value. I don't see this in syslogd(8); I presume it require source hacking? Yes. [...] netstat -sp udp | grep 'datagrams received'; sleep 10; \ netstat -sp udp | grep 'datagrams received' 158169 dropped due to full socket buffers 2467251 datagrams received sleeping... 158903 dropped due to full socket buffers 2468299 datagrams received ~100 datagrams per second, not a lot. Perhaps they are huge. How much cpu time does syslogd use? Not much. ps -ax | grep syslog gives: 4317 ?? Ss 0:01.60 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log Try to remove a log socket for named and restart syslogd. Process has been running for about five minutes at that point. Another point that might be of interest: ns1/etc;rc.d/syslogd restart Stopping syslogd. Waiting for PIDS: 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317, 4317 Starting syslogd. What's the /var filesystem type? Something like gmirror? diff -u /etc/syslog.conf /usr/src/etc/syslog.conf? -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslogd not draining
[...] ~100 datagrams per second, not a lot. Perhaps they are huge. Not that I've noticed. It's syslogd, DHCP, DNS, and flow-capture from a variety of devices, all generally small packets. I know nothing about your netflow setup but it can generate a huge amount of udp traffic. Check 'pkts' and 'lost' fields in /var/log/flow-capture. How much cpu time does syslogd use? Not much. ps -ax | grep syslog gives: 4317 ?? Ss 0:01.60 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log Try to remove a log socket for named and restart syslogd. Removed the named socket and restarted. We'll see what happens. [...] Can you check there is nothing from syslogd on the serial console? -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad block - file mapping
On Sat, 18 Feb 2006, 10:21-0700, M. Warner Losh wrote: I have a hard disk that's been in service a long time. I recently installed the SMART monitoring tools. On occasion, I get reports of LBAs it can't read. I'd like to map the LBA to an actual file in the file system, if possible. Does anybody have any tools that can help me with this? I know I need to get a new disk. In the mean time, I need to cope with these errors in a sane manner... May http://tinyurl.com/c7dr4 help? -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: typo src/sys/coda/coda_vfsops.c revision 1.60??
On Mon, 9 Jan 2006, 18:57+0100, Hugo Meiland wrote: Hi, I was just browsing the coda code in the head cvs, src/sys/coda/coda_vfsops.c revision 1.60 and came along the following defines : #define MARK_ENTRY(op) (coda_vfsopstats[op].entries++) #define MARK_INT_SAT(op) (coda_vfsopstats[op].sat_intrn++) #define MARK_INT_FAIL(op) (coda_vfsopstats[op].unsat_intrn++) #define MRAK_INT_GEN(op) (coda_vfsopstats[op].gen_intrn++) Is that last MARK/MRAK a possible typo?? Fixed. Thanks! btw it is called later on as MARK_INT_GEN It is not used in coda_vfsops.c so it was harmless. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SENDMAIL_MC making world
On Sat, 8 Oct 2005, 17:47+0400, Yar Tikhiy wrote:
All,
I'd like to set SENDMAIL_MC in my /etc/make.conf files conditionally
so that it is not set when I'm making {build,install}world. I
upgrade several machines over NFS from a single build server, and
of course installworld breaks if SENDMAIL_MC differs from what was
set during buildworld. At the same time, I'd like to have SENDMAIL_MC
set for the rest of the time on the machines because `hostname` is
not a suitable way to construct the .mc names on them due to local
setup peculiarities. Any ideas how to achieve this effect?
It is possible to override make.conf location via __MAKE_CONF variable
and use different make.conf at the build,installworld stages.
Perhaps that suits your needs.
--
Maxim Konovalov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ancient FreeBSD releases online
On Sun, 3 Jul 2005, 11:05+0200, Poul-Henning Kamp wrote: ftp://phk.freebsd.dk ./386BSD/cd1.iso [...] The server is a Soekris NET4801 and it's primary task is my email, so if this gets abused it'll disappear again. Mirrors welcome. We have some here: http|ftp|rsync://ftp.mtu.ru/pub/FreeBSD-Archive/i386/ And I steal missed bits from you. Thanks! -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw causing panic 4.11-RELEASE-p4
On Mon, 2 May 2005, 13:20+0300, Imri Zvik wrote: Hi, I was playing around with ipfw, and when I tried something like: /sbin/ipfw disable firewall /sbin/ipfw flush sysctl net.inet.ip.fw.dyn_buckets=600 applying some rules /sbin/ipfw enable firewall The machine paniced: Mine doesn't: shy# uname -a FreeBSD shy.macomnet.ru 4.11-STABLE FreeBSD 4.11-STABLE #0: Thu Apr 21 05:48:09 MSD 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 shy# /sbin/ipfw disable firewall shy# /sbin/ipfw flush sysctl net.inet.ip.fw.dyn_buckets=600 Are you sure? [yn] y Flushed all rules. net.inet.ip.fw.dyn_buckets: 256 - 600 shy# ipfw add 1 allow all from any to any 1 allow ip from any to any shy# /sbin/ipfw enable firewall Could you show your rules? -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfw causing panic 4.11-RELEASE-p4
On Tue, 3 May 2005, 17:49+0300, Imri Zvik wrote: I forgot to mention I was using ipfw1. When I upgraded to ipfw2 it didn't happen again. [...] Mine doesn't: shy# uname -a FreeBSD shy.macomnet.ru 4.11-STABLE FreeBSD 4.11-STABLE #0: Thu Apr 21 05:48:09 MSD 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 shy# /sbin/ipfw disable firewall shy# /sbin/ipfw flush sysctl net.inet.ip.fw.dyn_buckets=600 Are you sure? [yn] y Flushed all rules. net.inet.ip.fw.dyn_buckets: 256 - 600 shy# ipfw add 1 allow all from any to any 1 allow ip from any to any shy# /sbin/ipfw enable firewall Could you show your rules? That's ipfw1. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make world /jail - error
On Tue, 12 Apr 2005, 10:22+0200, Martin Zibert wrote: Greetings.. I have a box running FreeBSD 5.3-RELEASE-p5 - today i was trying to set up a jail, but i got this error: IIRC it's famous http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/77610 and several others. Try a workaround there or upgrade to RELENG_5 or RELENG_5_4. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_reass() - possibly incorrect goto
On Thu, 24 Mar 2005, 04:46-0600, Mike Silbersack wrote: On Wed, 23 Mar 2005, Maxim Konovalov wrote: On Tue, 22 Mar 2005, 12:08-0800, [EMAIL PROTECTED] wrote: Hi hackers, I am looking at the ip_reass() routine. In case of the 1st fragment we create the reassembly queue. After the queue has been inserted in the hash bucket, the if () code does a goto inserted. Should this be changed to goto done instead? Any code that is executed for the 1st fragment, like frag per packet limiting and complete reassembly are not valid. Am I mistaken? Yep, it seems you are right. The second micro optimization - drop the fragment early if maxfragsperpacket == 0. Andre, Mike, what do you think? Looks good to me. Please tell us if you come up with any more optimizations for the reassembly code, Vijay. [...] Committed to HEAD. Thanks, Vijay! -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_reass() - possibly incorrect goto
On Tue, 22 Mar 2005, 12:08-0800, [EMAIL PROTECTED] wrote:
Hi hackers, I am looking at the ip_reass() routine. In case of the
1st fragment we create the reassembly queue. After the queue has
been inserted in the hash bucket, the if () code does a goto
inserted. Should this be changed to goto done instead? Any code
that is executed for the 1st fragment, like frag per packet limiting
and complete reassembly are not valid. Am I mistaken?
Yep, it seems you are right. The second micro optimization - drop the
fragment early if maxfragsperpacket == 0.
Andre, Mike, what do you think?
Index: ip_input.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.299
diff -u -r1.299 ip_input.c
--- ip_input.c 16 Mar 2005 05:27:19 - 1.299
+++ ip_input.c 23 Mar 2005 13:12:00 -
@@ -801,8 +801,8 @@
u_int8_t ecn, ecn0;
u_short hash;
- /* If maxnipq is 0, never accept fragments. */
- if (maxnipq == 0) {
+ /* If maxnipq or maxfragsperpacket are 0, never accept fragments. */
+ if (maxnipq == 0 || maxfragsperpacket == 0) {
ipstat.ips_fragments++;
ipstat.ips_fragdropped++;
m_freem(m);
@@ -918,7 +918,7 @@
fp-ipq_dst = ip-ip_dst;
fp-ipq_frags = m;
m-m_nextpkt = NULL;
- goto inserted;
+ goto done;
} else {
fp-ipq_nfrags++;
#ifdef MAC
@@ -998,8 +998,6 @@
m_freem(q);
}
-inserted:
-
/*
* Check for complete reassembly and perform frag per packet
* limiting.
%%%
--
Maxim Konovalov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: occasional ECONNREFUSED when connect()ing.
On Sat, 19 Feb 2005, 04:51+0300, Deomid Ryabkov wrote: Peter Jeremy wrote: On Fri, 2005-Feb-18 16:18:41 +0300, Deomid Ryabkov wrote: I have a strange case of occasional refused connect()'s. The system is running 4.10-STABLE. ... The question is - why do connections get refused at all? I can think of no valid reasons... FWIW, I can't either. The client is single-threaded so it's difficult to see why this should occur. Unfortunately, I don't have ready access to a 4.x system with perl 5.8 but I don't see the problem with FreeBSD 5.3. problem solved by upgrading system to 4.11-STABLE. the problem is specific to 4.10: it does NOT show up on any of 3 systems running FreeBSD 4.9-STABLE #4: Mon Nov 10 18:47:10 MSK 2003 it DOES, however, show up on every one of 3 other systems, running FreeBSD 4.10-STABLE #10: Wed Aug 4 18:42:45 MSD 2004 and, as i said, it seems to have had been fixed somewhere before FreeBSD 4.11-STABLE #12: Sun Jan 23 14:09:07 MSK 2005 i don't feel like diving deep into the issue here... thanks everyone :) [Haven't read your code] Try to turn net.inet.ip.portrange.randomized off. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How many developers?
On Thu, 10 Feb 2005, 14:53+0100, Ivan Voras wrote:
For statistical purposes, where can I get information such as the number of
developers (with commit bit?) active on the FreeBSD project?
cvs co -p CVSROOT-src/access CVSROOT-doc/access CVSROOT-ports/access \
2/dev/null | grep -v ^# | awk '{print $1}' | sort -u | wc -l
--
Maxim Konovalov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PPPoEd fork flood patch
On Thu, 3 Feb 2005, 10:48+0300, [EMAIL PROTECTED] wrote: Patch for pppoed, what allows you to configure minimum delay between connections to pppoed, and prevent flood attacks. Just apply this patch and recompile pppoed with CONN_LIMIT defined. Use '-c' command line arg to set delay (in seconds) between connections. Tested on 4.10,5.3 with Mustdie XP as client. Where is the patch? :-) -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd problem: Cannot detect Hard Disk (SATA) RELENG_4
On Mon, 24 Jan 2005, 15:48-0800, Julian Elischer wrote: Doug Ambrisko wrote: Julian Elischer writes: | Doug, could you comit your patchsets to RELENG_4? I could but have not been given an okay from RE. Theoreticallty you do not need RE's permission at the moment. (though it would be nice) First, let -stable people test the patch. Heads-up in -stable is our usual practise. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network trunkin
On Sun, 9 Jan 2005, 23:35+1030, Daniel O'Connor wrote: On Sun, 9 Jan 2005 22:48, Avleen Vig wrote: On Sun, Jan 09, 2005 at 02:48:18AM -0800, Matt wrote: Does anyone know if FreeBSD supports trunking? By that I mean spreading network traffic over multiple interfaces to achieve a higher aggregate I believe you can, with VLANs. Not sure about otherwise. I though there was a netgraph channel bonding node, but I can't remember it's name :( ng_fec(4) -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: network trunkin
On Sun, 9 Jan 2005, 12:24-0800, Avleen Vig wrote: I though there was a netgraph channel bonding node, but I can't remember it's name :( ng_fec(4) Is that a 5.x-ism? The man page, yes. $ locate ng_fec | grep ^/usr/src /usr/src/sys/netgraph/ng_fec.c /usr/src/sys/netgraph/ng_fec.h $ uname -r 4.10-STABLE -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 IPFW bug
On Wed, 15 Dec 2004, 17:00+0500, Dmitry A. Bondareff wrote: Hello hackers! Today I upgraded my 5.2.1-p11 box up to 5.3-p2. My firewall rules includes like this: ... /sbin/ipfw add tee 1 ip from 1.2.3.4 to 4.3.2.1 ... On 5.2.1-FreeBSD it's works fine. But FreeBSD 5.3 halted each time!!! It's not clear what do you mean by halted here? Does the server freeze of what? If it continues the rule processing this is not a bug, see Andre's explanation. If the server freezes - this is a bug and we need a kernel backtrace and/or the kernel core dump. Or clear how-to-repeat receipt. After changed tee 1 to allow now works all fine. Is this bug ?? -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: finding alternate superblocks in ffs
[...] Any idea what I can do now? I wrote a little program that opens /dev/ad2s1e [...] I'm not sure whether my approach is correct. src/tools/tools/find-sb ls -d /usr/ports/sysutils/*ffs* Anyway, the blocks I find with that method aren't recognized as superblocks either. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ping(8) 64BTT friendly patch
Here is a patch stolen from OpenBSD via NetBSD (rev. 1.75 ping/ping.c)
which does two things:
- stores timestamp in network byte order;
- removes an assumption that sizeof(struct timeval) == 8 (it's not
true on sparc64).
Any comments?
Index: ping.c
===
RCS file: /home/ncvs/src/sbin/ping/ping.c,v
retrieving revision 1.105
diff -u -r1.105 ping.c
--- ping.c 14 Aug 2004 17:46:10 - 1.105
+++ ping.c 28 Sep 2004 14:51:04 -
@@ -92,7 +92,7 @@
#include unistd.h
#defineINADDR_LEN ((int)sizeof(in_addr_t))
-#defineTIMEVAL_LEN ((int)sizeof(struct timeval))
+#defineTIMEVAL_LEN ((int)sizeof(struct tv32))
#defineMASK_LEN(ICMP_MASKLEN - ICMP_MINLEN)
#defineTS_LEN (ICMP_TSLEN - ICMP_MINLEN)
#defineDEFDATALEN 56 /* default data length */
@@ -110,6 +110,11 @@
#defineCLR(bit)(A(bit) = (~B(bit)))
#defineTST(bit)(A(bit) B(bit))
+struct tv32 {
+ int32_t tv32_sec;
+ int32_t tv32_usec;
+};
+
/* various options */
int options;
#defineF_FLOOD 0x0001
@@ -838,6 +843,7 @@
pinger(void)
{
struct timeval now;
+ struct tv32 tv32;
struct ip *ip;
struct icmp *icp;
int cc, i;
@@ -856,13 +862,15 @@
if ((options F_TIME) || timing) {
(void)gettimeofday(now, NULL);
+ tv32.tv32_sec = htonl(now.tv_sec);
+ tv32.tv32_usec = htonl(now.tv_usec);
if (options F_TIME)
icp-icmp_otime = htonl((now.tv_sec % (24*60*60))
* 1000 + now.tv_usec / 1000);
if (timing)
- bcopy((void *)now,
+ bcopy((void *)tv32,
(void *)outpack[ICMP_MINLEN + phdr_len],
- sizeof(struct timeval));
+ sizeof(tv32));
}
cc = ICMP_MINLEN + phdr_len + datalen;
@@ -942,6 +950,7 @@
triptime = 0.0;
if (timing) {
struct timeval tv1;
+ struct tv32 tv32;
#ifndef icmp_data
tp = icp-icmp_ip;
#else
@@ -951,7 +960,9 @@
if (cc - ICMP_MINLEN - phdr_len = sizeof(tv1)) {
/* Copy to avoid alignment problems: */
- memcpy(tv1, tp, sizeof(tv1));
+ memcpy(tv32, tp, sizeof(tv32));
+ tv1.tv_sec = ntohl(tv32.tv32_sec);
+ tv1.tv_usec = ntohl(tv32.tv32_usec);
tvsub(tv, tv1);
triptime = ((double)tv-tv_sec) * 1000.0 +
((double)tv-tv_usec) / 1000.0;
%%%
--
Maxim Konovalov
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 586Core
[ Excessive crosspost ] On Mon, 13 Sep 2004, 01:20-0600, [EMAIL PROTECTED] wrote: Good localtime() I'm starting some small project, and I need to decide what hardware will fit its needs. I'm looking for a small single-board computer that should have minimum: 2 serial ports (RS232 [RS232 | USB(preferable)]), 8-bit databus, FLASH disk, RTC, 486 CPU performance, low power consumption; should be able to run FreeBSD. PCB size does not matter much. One of the applications I plan to run on it is 'gnokii'. I've found this: 'http://www.compulab.co.il/586core.htm', and I'd appreciate to get some opinions on this product. Is anyone using it? How well does it work with FreeBSD (or *BSD)? How well FBSD works with its USB controller (ScanLogic SL811HST)? Maybe someone can suggest a better and possibly less expensive alternative? http://soekris.com/ ? -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFIREWALL_VERBOSE stopped logging?
On Tue, 7 Sep 2004, 08:32-0600, Ryan Sommers wrote: I'm trying to figure out why my firewall has stopped logging to /var/log/security. The last entry was from Aug 17 and there has been at least one restart and a few hundred thousand packets denied. FreeBSD * 5.2.1-RELEASE-p8 FreeBSD 5.2.1-RELEASE-p8 #1: Thu Jul 1 18:24:26 CDT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MOLEMAN i386 ([EMAIL PROTECTED]):~:#ipfw list | tail -2 03000 deny log tcp from any to any in via xl0 setup 65535 deny ip from any to any ([EMAIL PROTECTED]):~:#sysctl net.inet.ip.fw net.inet.ip.fw.enable: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.debug: 1 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.verbose_limit: 0 (truncated) ([EMAIL PROTECTED]):~:#grep security /etc/syslog.conf security.* /var/log/security What am I missing? Previous ipfw rules, 'ipfw sh' instead of 'ipfw list' and a tail of the /var/log/security :-) -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: off by one bounds
Hi Ted, On Fri, 20 Aug 2004, 12:36-0700, Ted Unangst wrote: errors in freebsd 4.10 found by Coverity's analysis. [...] ip_icmp.c:ip_next_mtu, i == sizeof, dir = 0 This one is not a bug really. If i == sizeof then mtutab[i] == 0 and we return 0 at the line 818. Or I miss something? -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: off by one bounds
On Sat, 21 Aug 2004, 05:00-0400, Skip Ford wrote: Maxim Konovalov wrote: On Fri, 20 Aug 2004, 12:36-0700, Ted Unangst wrote: errors in freebsd 4.10 found by Coverity's analysis. ip_icmp.c:ip_next_mtu, i == sizeof, dir = 0 If i == sizeof then mtutab[i] == 0 If i == sizeof then mtutab[i] is out of bounds, off by one. There is no mtutab[sizeof mtutab / sizeof mtutab[0]]. This isn't specific to RELENG_4 Ah, yes, sorry. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: off by one bounds
On Sat, 21 Aug 2004, 13:19+0400, Maxim Konovalov wrote: On Sat, 21 Aug 2004, 05:00-0400, Skip Ford wrote: Maxim Konovalov wrote: On Fri, 20 Aug 2004, 12:36-0700, Ted Unangst wrote: errors in freebsd 4.10 found by Coverity's analysis. ip_icmp.c:ip_next_mtu, i == sizeof, dir = 0 If i == sizeof then mtutab[i] == 0 If i == sizeof then mtutab[i] is out of bounds, off by one. There is no mtutab[sizeof mtutab / sizeof mtutab[0]]. This isn't specific to RELENG_4 After the second thought I still think it is not a error. mtu is always = than the minimal value in mtutab[] that is why i is always less than (sizeof mtutab) / sizeof mtutab[0]). What do you think? -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Zero copy Socket
On Wed, 18 Aug 2004, 01:30-0700, Dennis George wrote: Hi all, Is there any limitations in using zero copy socket I mean... do the sender has to follow any specific protocol (like the packet payload should be page alligned or so.) ??? Have you read zero_copy(9) man page? For sending data, there are no special requirements or capabilities that the sending NIC must have. The data written to the socket, though, must be at least a page in size and page aligned in order to be mapped into the kernel. If it does not meet the page size and alignment constraints, it will be copied into the kernel, as is normally the case with socket I/O. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: handbook submissions
On Wed, 24 Mar 2004, 18:44+0100, Harti Brandt wrote: Hi, what is the correct address to send handbook submissions (in text form, I'm not an SGML guru) to, so that they get picked up? I've send a submission several months ago to one of our committers, but he seems to be more involved with DF-BSD nowadays. [EMAIL PROTECTED] -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel options
On Sun, 29 Feb 2004, 11:36+0200, Danny Braniss wrote: hi, is there a way of knowing with which kernel-options a particular kernel was compiled with (appart form the obvious config file)? Yes, if you use 'options INCLUDE_CONFIG_FILE'. See /sys/conf/NOTES for details. -- Maxim Konovalov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic in /proc
On Sat, 31 Jan 2004, 00:24-0800, Joel Ray Holveck wrote: Here's a way to panic FreeBSD 5.2, as any user: dd if=/proc/curproc/map iseek=0x8000 bs=4096 of=/dev/null count=1 I briefly examined the core. It appears that pseudofs is trying to malloc an sbuf big enough to hold everything up to the 128 MB mark that we requested, which it intends to get procfs to fill. Of course, the malloc fails, and the kernel panics. Please fill a PR. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Update: PR bin/60636
On Mon, 29 Dec 2003, 01:27-0600, William Grim wrote: Hey there. I emailed that PR into the FreeBSD team the other day. I didn't remove a line that said unix, because the above lines said comments and anything between and would be removed. It put [EMAIL PROTECTED] as my email, and now I'm getting all sorts of spam to that mail box (all dealing with that stupid ass Last chance to update MS and shit). Sorry for the cussing, but this is frustrating since that's used strictly for system administration; can you change the email address to [EMAIL PROTECTED] Thanks. PS : Just tell me who to forward this email too to get this resolved if this is not the appropriate place. Done. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: On-line judgment kernel module
On Thu, 9 Oct 2003, 07:46+0300, earthman wrote: I want to create on-line judge for acm like olympiads. So I have to execute some code that came in source from outside(www). Thus security problem is my main problem. The idea is to deny all syscalls for specific process p. This is possible even without rewriting kernel by kernel module. You need SPY: http://people.freebsd.org/~abial/ -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.8-stable kernel panic
On Sun, 14 Sep 2003, 23:05-0500, Mike Silbersack wrote: On Sun, 14 Sep 2003 [EMAIL PROTECTED] wrote: Hello, It's been almost a month now since I posted the original message on the list and I'm wondering about the progress on resolving this problem. I still can reproduce the panics after cvs-supping to RELENG_4 ~ 23:00 EDT today. Thanks much. Ooops, I forgot to follow up on this. Ok, a few questions: 1. Can you compile INVARIANTS and INVARIANT_SUPPORT into your kernel? That might help us track down the problem. 2. What does your network setup look like? Are you using divert sockets, is there ppp in action, etc. I believe that I tried out your script at the time, and I couldn't find it to cause any problems on my system. rwatson has fixed this panic in rev. 1.115 in -current: revision 1.115 date: 2003/08/26 14:11:48; author: rwatson; state: Exp; lines: +2 -0 M_PREPEND() with an argument of M_TRYWAIT can fail, meaning the returned mbuf can be NULL. Check for NULL in rip_output() when prepending an IP header. This prevents mbuf exhaustion from causing a local kernel panic when sending raw IP packets. PR: kern/55886 Reported by:Pawel Malachowski [EMAIL PROTECTED] MFC after: 3 days and haven't MFCed it yet. Here is a patch for -stable: Index: sys/netinet/raw_ip.c === RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.64.2.17 diff -u -r1.64.2.17 raw_ip.c --- sys/netinet/raw_ip.c9 Sep 2003 19:09:22 - 1.64.2.17 +++ sys/netinet/raw_ip.c15 Sep 2003 04:21:59 - @@ -257,6 +257,8 @@ return(EMSGSIZE); } M_PREPEND(m, sizeof(struct ip), M_WAIT); + if (m == NULL) + return(ENOBUFS); ip = mtod(m, struct ip *); ip-ip_tos = inp-inp_ip_tos; ip-ip_off = 0; %%% -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nmbclusters and nmbufs
-questions material indeed. On Tue, 19 Aug 2003, 11:53+0400, Varshavchick Alexander wrote: Hi, Can anybody advise please if I want to increase nmbclusters option in kernel, can I just type sysctl kern.ipc.nmbclusters=16384 without rebooting the server, or is the only way to set the NMBCLUSTERS option in kernel, install the new kernel and reboot? And secondly, also I need to increase nmbufs kernel option, but there seems to be no such option in LINT, what should I tweak? sysctl kern.ipc.nmbufs=32768 without rebooting or kern.ipc.nmbufs=32768 in /boot/loader.conf and reboot? You need to put kern.ipc.nmbclusters=xxx kern.ipc.nmbufs=yyy to /boot/loader.conf and reboot. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is ATAPI DMA disabled by default ?
On Thu, 14 Aug 2003, 01:45+0300, Alexander Serkov wrote: I use 5.1-current and have found that by default FreeBSD disables ATAPI's support for DMA transfers and thus uses CPU hungry PIO modes. It even makes sysctl used to change this read-only. I had changed the default value of atapi_dma to 1 in dev/ata/atapi-all.c to 1 and it worked fine for me. Hint: put hw.ata.atapi_dma=1 in /boot/loader.conf. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TODO list?
On Sat, 28 Jun 2003, 19:29-0400, Zak Johnson wrote: On 2003-06-28 20:27+0400, Maxim Konovalov wrote: for instance? misc/25851 I am not familiar with sysinstall code, sorry. bin/32433 Fixed in -current. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TODO list?
On Sat, 28 Jun 2003, 14:10-0400, Joseph Holland King wrote: On Sat, Jun 28, 2003 at 08:27:25PM +0400, Maxim Konovalov had the gall to say: On Sat, 28 Jun 2003, 10:10-0400, Joseph Holland King wrote: heh, i must say that without a commit bit its almost impossible to get any of the pr's closed, even ones that are five years old with a fix attached. for instance? this had a fix to begin with, and has a new fix now: Re: kern/23173: read hangs in linux emulation http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/23173 Assigned to maintainer. two people have claimed that this should be closed: Re: i386/20495: 4.1-STABLE and 4.1-RELEASE: keyboard doesn't work after booting http://www.FreeBSD.org/cgi/query-pr.cgi?pr=i386/20495 Closed. this one had a patch orginally but suspended and never submitted: Re: bin/2938: Add -b, -l, and -f options to du(1) http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/2938 Closed. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ftpd (option -h not working)
On Sat, 21 Jun 2003, 20:27+0200, Socketd wrote: Hi all When FreeBSD 4.8 was released I reported this bug, but now in 5.1 releaed it is still there. Since http://www.freebsd.org/send-pr.html is down I'll try reporting the bug here (again). When using ftpd, you have the -h option to prevent the server from giving any info about itself. This works fino regarding the greeting message and when typing stat, but with syst is still gives info to the user. Will someone please forward this message to the maintainer of ftpd (can't find any mail is the source files)? http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/50690 -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: netstat -s output
On Fri, 6 Jun 2003, 11:19+0200, Bogdan TARU wrote: Hi hackers, I have tried to find out the amount of traffic that one box sent (from the last reboot), and netstat -s seemed like a good choice. But netstat -s seems to generate incorrect results: tcp: 1730547260 packets sent 1325234728 data packets (1119813018 bytes) 28496801 data packets (151887376 bytes) retransmitted This box generated a lot more than ~12Gb of tcp traffic since the last reboot. And I have not messed up with interfaces (up, down, whatever) OR with netstat -z in all this time. Any idea what could be wrong? Are the counters resetted sometimes, or they wrap sometimes, or...? They wrap at 2^32. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about divert in ipfw2 on 5.0 release
Hello, On 13:10+0300, Feb 28, 2003, denb wrote: I write program simular to natd, witch receives packets at divert port X. Question: On ipfw1 (FreeBSD 4.7) this rules work excellent: ipfw add divert X from any to any Y ipfw add divert X from any Y to any We're diverting all received and sended packets (from\to port Y) to divert port X. But these rules are not working together with ipfw2 (5.0 Release). Each single rule works fine, but when i combine them together only first of them triggers. The order doesn't matter. What am I doing wrong? Can't reproduce: # ipfw add 1 divert tcp from any to any 1973 1 divert tcp from any to any dst-port 1973 # ipfw add 2 divert tcp from any 1973 to any 2 divert tcp from any 1973 to any # nc localhost 1973 # nc -p 1973 localhost 21 # ipfw show 1 2 1 1 60 divert tcp from any to any dst-port 1973 2 1 60 divert tcp from any 1973 to any What am I doing wrong? :-) -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
[ Trim -questions ] On 16:21+0300, Dec 19, 2002, Varshavchick Alexander wrote: There seems to be archive posts already on the subject, the most informative of them is here: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1093170+1102546+/usr/local/www/db/text/2001/freebsd-stable/20010923.freebsd-stable Did this issue got solved somehow? More specifically, how the size of the FFS node malloc area can be increased? Sounds like kern/32672. Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Thu, 19 Dec 2002, Varshavchick Alexander wrote: Date: Thu, 19 Dec 2002 13:29:18 +0300 (MSK) From: Varshavchick Alexander [EMAIL PROTECTED] To: Dmitry Morozovsky [EMAIL PROTECTED] Cc: David Schultz [EMAIL PROTECTED], Terry Lambert [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: maxusers and random system freezes Hi, Despite the increased KVA space (2G now) and the perfect patch of the pthreads mechanism made by David, the server's lock-ups persist. Comparing this server's vmstat output with some other's which doesn't have the similar problem, I noticed that the FFS node value seems to be abnormally high - 75113K from 102400K possible. What becomes with the system if this value bumps even closer to the limit, and how it can be put into place? And more of it: which other parameters must be examined first? If I'll send the output of vmstat -z and vmstat -m will you look at it please? Thanks a lot, regards Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Mon, 9 Dec 2002, Dmitry Morozovsky wrote: Date: Mon, 9 Dec 2002 22:32:04 +0300 (MSK) From: Dmitry Morozovsky [EMAIL PROTECTED] To: Varshavchick Alexander [EMAIL PROTECTED] Cc: David Schultz [EMAIL PROTECTED], Terry Lambert [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: maxusers and random system freezes On Mon, 9 Dec 2002, Varshavchick Alexander wrote: VA the server went to a swap, because it occurs practically instantly, and VA this state goes for hours. The system is lacking some resources, or may be VA a bug somewhere, can you give any hints to it? Hmm, what about logging vmstat/pstat/netstat -m/sysctl vm ? Possibly to remote machine via remote syslog? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: maxusers and random system freezes
On 16:51+0300, Dec 19, 2002, Varshavchick Alexander wrote: On Thu, 19 Dec 2002, Maxim Konovalov wrote: [...] [ Trim -questions ] On 16:21+0300, Dec 19, 2002, Varshavchick Alexander wrote: There seems to be archive posts already on the subject, the most informative of them is here: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1093170+1102546+/usr/local/www/db/text/2001/freebsd-stable/20010923.freebsd-stable Did this issue got solved somehow? More specifically, how the size of the FFS node malloc area can be increased? Sounds like kern/32672. Yes it does, but the problem seems to remain in 4.5-STABLE, how can it be patched? * State-Changed-From-To: open-closed This is believed to be fixed in -stable (and thus for the upcoming 4.5 release). The problem was that the vnode/inode reclamation system depends on the VM system running out of memory and having to free vnodes/inodes up. Machines with large amounts of ram, however, will often run the malloc bucket for vnodes or inodes out before they run out of memory. Our solution is to enforce the kern.maxvnodes limit by proactively reclaiming vnodes/inodes when the limit is reached, even if there is still lots of free memory. * Can you point me to a code performing it, if it's fixed in the latest release? We should CC: Matt Dillon, dillon@. Could you please summarize all information and send a complete bug report to -hackers? [...] -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: jail: hide df output
On 15:29+0300, Nov 25, 2002, Alexandr Kovalenko wrote: Hello, I'm trying to find place in kernel which is used by df to show mountpoints and free space on them to change it in way that jailed user: - cannot view any host-os mounted filesystems; - can view in df output only his /jail/jailXX/ unionfs mount where data taken from quota data. Any help would be appreciated. http://www.freebsd.org/cgi/query-pr.cgi?pr=26740 -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UFS Disk partitions
On 12:54+0300, Nov 11, 2002, Bri wrote: Does anyone have any information regarding recovering diskpartitions as the machine crash in heavy I/O to that disk i've lost being able to fsck the drive and of course be able to mount it which means I'm quite lost in the way of how to recover the data. Any help apprieciated Take a look at src/tools/tools/find-sb/ and OpenBSD's scan_ffs: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/scan_ffs/?cvsroot=openbsd -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim;macomnet.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pthreads on 4.7-RELEASE
On 14:34+0300, Nov 7, 2002, Mathieu Arnold wrote:
Hi
I'm having a bit of difficulties with pthreads, lets explain :
$ cat test.c
#include pthread.h
Shouldn't it be pthread.h?
void * test (void* t) {
while (1) {
printf(pouet);
Use printf(pouet\n) of fflush stdout.
sleep(1);
}
}
main () {
pthread_t th;
if (pthread_create(th, NULL, test, NULL)) {
perror(pthread_create);
exit(1);
}
if (pthread_detach(th)) {
perror(pthread_detach);
exit(2);
}
exit(0);
Shouldn't it be pthread_exit(0) here? Your main thread can exits just
before th gets a chance to run.
}
$ gcc -pthread -D_REENTRANT -D_THREAD_SAFE test.c -o test
$ ./test
pthread_create: Cannot allocate memory
Anyway, can't reproduce:
$ gcc -pthread -D_REENTRANT -D_THREAD_SAFE t.c -o t
$ ./t
$ uname -a
FreeBSD spe151.testdrive.hp.com 4.7-RELEASE FreeBSD 4.7-RELEASE #0:
Thu Oct 10 15:54:32 EDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386
$
I must be doing something stupid, but I cannot really find what...
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:maxim;macomnet.ru
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
cdcontrol(1) speed command
Hello,
Here is a patch for cdcontrol(1) to allow set maximum CD drive speed.
It comes from kern/35512. Are there any comments/objections?
Index: cdcontrol.1
===
RCS file: /home/ncvs/src/usr.sbin/cdcontrol/cdcontrol.1,v
retrieving revision 1.32
diff -u -r1.32 cdcontrol.1
--- cdcontrol.1 15 Jul 2001 08:01:46 - 1.32
+++ cdcontrol.1 27 Mar 2002 10:57:34 -
@@ -154,6 +154,9 @@
Set minute-second-frame ioctl mode (default).
.It Cm set Ar lba
Set LBA ioctl mode.
+.It Cm speed Ar s
+Set the highest speed that the drive should use. This command is currently
+only supported on ATAPI drives.
.It Cm quit
Quit the program.
.El
Index: cdcontrol.c
===
RCS file: /home/ncvs/src/usr.sbin/cdcontrol/cdcontrol.c,v
retrieving revision 1.37
diff -u -r1.37 cdcontrol.c
--- cdcontrol.c 18 Feb 2002 20:35:27 - 1.37
+++ cdcontrol.c 27 Mar 2002 10:58:12 -
@@ -24,6 +24,7 @@
#endif /* not lint */
#include sys/cdio.h
+#include sys/cdrio.h
#include sys/file.h
#include sys/ioctl.h
#include sys/param.h
@@ -32,6 +33,7 @@
#include err.h
#include errno.h
#include histedit.h
+#include limits.h
#include paths.h
#include stdio.h
#include stdlib.h
@@ -73,6 +75,7 @@
#define CMD_CDID 15
#define CMD_NEXT 16
#define CMD_PREVIOUS 17
+#define CMD_SPEED 18
#define STATUS_AUDIO 0x1
#define STATUS_MEDIA 0x2
#define STATUS_VOLUME 0x4
@@ -105,6 +108,7 @@
{ CMD_VOLUME, volume, 1,
l r | left | right | mute | mono | stereo },
{ CMD_CDID,cdid, 2, },
+{ CMD_SPEED, speed,2, speed },
{ 0, NULL, 0, NULL }
};
@@ -277,7 +281,9 @@
int run (int cmd, char *arg)
{
+ long speed;
int l, r, rc;
+ char *ep;
switch (cmd) {
@@ -424,6 +430,19 @@
}
return setvol (l, r);
+
+ case CMD_SPEED:
+ if (fd 0 ! open_cd ())
+ return (0);
+
+ errno = 0;
+ speed = strtol(arg, ep, 0);
+ if (*ep || ep == arg || speed 0 || speed INT_MAX ||
+ errno != 0) {
+ warnx(invalid command arguments %s, arg);
+ return (0);
+ }
+ return ioctl(fd, CDRIOCREADSPEED, speed);
default:
case CMD_HELP:
%%%
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: finding out boot device
On 20:34+0400, Apr 1, 2002, Dmitry Konyshev wrote: Hello hackers, Could anyone please tell me if there's any way to find out which device the system booted from in a user application. The loader sets loaddev and currdev vars, but I see no way to transfer them to the user environment. In recent -current we have sysctl machdep.guessed_bootdev. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: chowning problem or somthing...
On 18:23-, Mar 12, 2002, Bri wrote: %pwd /usr/home %chown testuser4:staff testuser4/ %ls -l | grep testuser4 drwxr-xr-x 2 testuser3 staff 512 Feb 21 15:06 testuser4 %whoami root %uname -r 4.5-RELEASE %grep ^testuser /etc/passwd // Notice how its still owned as testuser3 when I chowned it as testuser4 should own testuser4's directory maybe it does but the ls command isn't displaying it properly I'm not sure is not really a problem to me but its weird. It could be also something to do with me having testuser and testuser2 + 3 4 in the same directory. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Patches to fix MD5 auth in routed
Oleg, On 11:28+0300, Mar 11, 2002, Oleg Sharoiko wrote: Hello! The MD5 authentication of ripv2 packets calculated by routed is (for the moment) incompatible with MD5 authentication calculated by cisco and zebra routers. Routed skips two fields while running MD5_Update. Due to this routed can not talk to cisco and cisco can not talk to routed. The patches bellow will fix the problem. Could someone please review them and commit if they're ok or send me comments if not. I've posted two messages on freebsd-net, but nobody replied so I'm posting here. I really need cisco and routed to communicate with auth enabled and thus I'm ready to spent some time on fixing this part of routed in a way acceptable for the FreeBSD community. Thanks in advance I am going to take a look at your patches. Could you please fill a PR meantime? http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kqueue example code - suggestions?
On 10:33-0600, Mar 6, 2002, Conrad Sabatier wrote: Could anyone suggest a package I might look at to get an example of real world kqueue() processing that would be not too difficult to digest? I'm interested in converting an existing package from using poll() to kqueue(). /usr/src/usr.bin/tail/forward.c -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Default mail.local permission
On 14:26+0500, Feb 19, 2002, Dmitry A. Bondareff wrote: Hi hackers! Help me to understand next situation: # cd /usr/src # make buildworld # make installworld # make kernel /etc/rc.conf: sendmail_enable=YES After successfully install I see the next problem: Feb 19 00:00:01 xxx mail.local: lockmailbox /var/mail/other failed; error code 75 Feb 19 00:00:01 xxx sendmail[23806]: g1FIVkB32458: to=[EMAIL PROTECTED], delay=3+00 :28:15, xdelay=00:00:30, mailer=local, pri=12729484, dsn=4.0.0, stat=Deferred: local m ailer (/usr/libexec/mail.local) exited with EX_TEMPFAIL # ls -l /usr/libexec/mail.local -r-xr-xr-x 1 root wheel 20456 Feb 15 15:10 /usr/libexec/mail.local # chmod u+s /usr/libexec/mail.local # ll -l /usr/libexec/mail.local -r-sr-xr-x 1 root wheel 20456 Feb 15 15:10 /usr/libexec/mail.local After this manipulations all works fine. Why so problems? Why 1555 is not default permission ? more /usr/src/UPDATING 20001020: ... More details can be found at http://people.freebsd.org/~imp/UPDATING/sendmail-20001010 ... Regards, Dmitry. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: a daemon C skeleton
On 11:52+0300, Feb 15, 2002, Magdalinin Kirill wrote: Hello, can anyone, please, point out a C skeleton for FreeBSD daemon. Take a look at src/lib/libc/gen/daemon.c, man 3 daemon HTH, -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: chflags schg problem
On 15:03+0500, Feb 15, 2002, Dmitry A. Bondareff wrote: Hello hackers! What it is mean: Dial# rm kernel override r-xr-xr-x root/wheel schg for kernel? y rm: kernel: Operation not permitted Dial# chflags noschg /kernel chflags: /kernel: Operation not permitted please show sysctl kern.securelevel. man 8 init may shed a light. Regards, Dmitry. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: lsof and listening processes on 4.5
Hello, [...] How can it be that it doesn't show the ports on which inetd is listening? How can this info be retrieved on 4.5 at all, are there some other ways for doing it? sockstat(1)? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: lsof and listening processes on 4.5
On 15:13+0300, Feb 11, 2002, Varshavchick Alexander wrote: Of cause, I recompiled lsof for 4.5. But now it seems to be more likely a some general problem with the system, because the command sockstat -4 -l doesn't print anything either. What can it be...? Please show # sysctl kern.ps_showallprocs Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Mon, 11 Feb 2002, Edwin Groothuis wrote: Date: Mon, 11 Feb 2002 23:07:46 +1100 From: Edwin Groothuis [EMAIL PROTECTED] To: Varshavchick Alexander [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: lsof and listening processes on 4.5 On Mon, Feb 11, 2002 at 01:00:01PM +0300, Varshavchick Alexander wrote: Yes, I'm sure inetd is listening on them. Both ftp and telnet are responing from the server, and besides, /etc/inetd.conf is left untouched after the upgrade from FreeBSD 4.3. You did recompile it for 4.5, didn't you? lsof is very picky about that. Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org [EMAIL PROTECTED] | Interested in MUDs? Visit Fatal Dimensions: --+ http://www.FatalDimensions.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how to count number of user process?
On 10:11+0300, Feb 4, 2002, Magdalinin Kirill wrote: Hello, can anyone give an idea of C code on how to quickly count the number of processes for a given user? I want to patch Apache in order to prevent it from forking new process over user's maxproc limit (while running suexec). Should I look at ps(1) source code or there are some other examples? take a look at src/usr.bin/killall/killall.c thanks, Kirill Magdalinin [EMAIL PROTECTED] _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IP options (was: Processing IP options reveals IPSTEALH router)
Hi, Yar,
On 19:12+0300, Dec 21, 2001, Yar Tikhiy wrote:
On Thu, Dec 20, 2001 at 01:24:48AM +0300, Maxim Konovalov wrote:
Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following:
if a source-routed IP packet reachs the end of its route, but its
destination address doesn't match a current host/router, whether
the packet should be discarded, sent forth through usual routing
or accepted as destined for this host? FreeBSD will route such a
packet as usual.
Stevens, TCP Ill. vII, p.257 says:
If the destination address of the packet does not match one of the
local addresses and the option is a strict source routing
(IPOPT_SSRR), an ICMP source route failure error is sent. If a local
address isn't listed in the route, the previous system sent the packet
to the wrong host. This isn't an error for a loose source route
(IPOPT_LSRR); it means IP must forward the packet toward the
destionation.
That is what ip_input does near the line 1193.
Oops, it appeared that I misunderstood the way the source route
record worked. FreeBSD does it right, except for a host (ipforwarding=0)
replying with error ICMP on some source route attempts.
What about the following small change?
--- /usr/src/sys/netinet.orig/ip_input.c Fri Dec 7 00:54:48 2001
+++ netinet/ip_input.cFri Dec 21 19:08:56 2001
@@ -1212,13 +1212,13 @@
ia = (struct in_ifaddr *)
ifa_ifwithaddr((struct sockaddr *)ipaddr);
if (ia == 0) {
+ if (!ip_dosourceroute)
+ goto nosourcerouting;
Nice catch.
if (opt == IPOPT_SSRR) {
type = ICMP_UNREACH;
code = ICMP_UNREACH_SRCFAIL;
goto bad;
}
- if (!ip_dosourceroute)
- goto nosourcerouting;
/*
* Loose routing, and not at next destination
* yet; nothing to do except forward.
@@ -1231,18 +1231,19 @@
* End of source route. Should be for us.
*/
if (!ip_acceptsourceroute)
- goto nosourcerouting;
+ goto logandsendicmp;
save_rte(cp, ip-ip_src);
break;
}
if (!ip_dosourceroute) {
+nosourcerouting:
I do not agree here. As far as I understand when we recieve a SSRR
packet and there are no our addresses in the source routing addresses
list we have to send ICPM_UNREACH to the sender regardless of
net.inet.ip.forwarding.
if (ipforwarding) {
char buf[16]; /* aaa.bbb.ccc.ddd\0 */
/*
* Acting as a router, so generate ICMP
*/
-nosourcerouting:
+logandsendicmp:
strcpy(buf, inet_ntoa(ip-ip_dst));
log(LOG_WARNING,
attempted source route from %s to %s\n,
Btw, there are many compares like
cnt IPOPT_OLEN + sizeof(*cp)
in ip_doiptions(). IMHO more strict to compare agains IPOPT_MIN
because multibyte ip options length cannot be less then four bytes. Am
I wrong?
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
Hello, On 18:51+0300, Dec 21, 2001, Yar Tikhiy wrote: On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: As for source routing, I believe a stealthy router should just drop such packets as though it were a host. Of course, source-routed packets destined for the router itself should be accepted. So there are three IPSTEALTH cases: 1/ the dst address is not ours, net.inet.ip.sourceroute=0, net.inet.ip.forwarding=1: process ip options by ip_dooptions(). 2/ the dst address is ours: process ip options by ip_dooptions(), 3/ in other cases do not process ip options. I made a patch that adds the stealthy IP options feature. Honestly, now I'm afraid it's much ado about nothing, given how clumsy solution is needed for such a small problem. Even the way of ignoring IP options completely when doing IPSTEALTH looks way better... IMHO it is not a good idea to forward a packet with possible incorrect ip options. The patch looks OK for me. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
Hello Yar, On 18:19+0300, Dec 19, 2001, Yar Tikhiy wrote: Hi there, I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? Are there any reasons for a router not to decrement IP TTL besides trying to stay invisible to a third party? imho there are not. I've asked because ru's net.inet.ip.decttl means do not decrement TTL but not hide the fact of the routing. As for source routing, I believe a stealthy router should just drop such packets as though it were a host. Of course, source-routed packets destined for the router itself should be accepted. So there are three IPSTEALTH cases: 1/ the dst address is not ours, net.inet.ip.sourceroute=0, net.inet.ip.forwarding=1: process ip options by ip_dooptions(). 2/ the dst address is ours: process ip options by ip_dooptions(), 3/ in other cases do not process ip options. By the way, is it correct to forward the packet with incorrect ip options? Now we do not. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IP options (was: Processing IP options reveals IPSTEALH router)
Morning, On 00:35+0300, Dec 20, 2001, Yar Tikhiy wrote: On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: By the way, is it correct to forward the packet with incorrect ip options? Now we do not. No RFC seems to specify that particularly. However, RFC 1812 reads in general: (1) A router MUST verify the IP header, as described in section [5.2.2], before performing any actions based on the contents of the header. This allows the router to detect and discard bad packets before the expenditure of other resources. Meanwhile more IP option issues came to my attention... Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: if a source-routed IP packet reachs the end of its route, but its destination address doesn't match a current host/router, whether the packet should be discarded, sent forth through usual routing or accepted as destined for this host? FreeBSD will route such a packet as usual. Stevens, TCP Ill. vII, p.257 says: If the destination address of the packet does not match one of the local addresses and the option is a strict source routing (IPOPT_SSRR), an ICMP source route failure error is sent. If a local address isn't listed in the route, the previous system sent the packet to the wrong host. This isn't an error for a loose source route (IPOPT_LSRR); it means IP must forward the packet toward the destionation. That is what ip_input does near the line 1193. Then, a FreeBSD host (net.inet.ip.forwarding=0) will respond with Source Route Failed ICMPs to source-routed IP packets if source route processing is prohibited using net.inet.ip.sourceroute or net.inet.ip.accept_sourceroute. To my mind, it may be deduced from RFC 1122 that a host must stay silent in this case... -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
MFC exlock+truncate bug^Wpatch
[ CC: [EMAIL PROTECTED] because of silence in -hackers ] Hello, Any chances to MFC these changes before 4.5? The bug is very annoying. | mckusick2000/07/03 20:34:11 PDT | | Modified files: |sys/dev/ccd ccd.c |sys/dev/vn vn.c |sys/kern kern_acct.c kern_ktrace.c kern_linker.c | kern_sig.c link_aout.c link_elf.c | vfs_syscalls.c vfs_vnops.c |sys/sys vnode.h |sys/ufs/ufs ufs_extattr.c ufs_quota.c | Log: | | Move the truncation code out of vn_open and into the open system | call after the acquisition of any advisory locks. This fix corrects | a case in which a process tries to open a file with a non-blocking | exclusive lock. Even if it fails to get the lock it would still | truncate the file even though its open failed. With this change, | the truncation is done only after the lock is successfully acquired. | | Obtained from: BSD/OS TIA, - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[PATCH]: missing references in pthread.3
Hello, Could someone review and commit the following patch: Index: pthread.3 === RCS file: /home/ncvs/src/share/man/man3/pthread.3,v retrieving revision 1.20 diff -u -r1.20 pthread.3 --- pthread.3 1 Oct 2001 16:09:20 - 1.20 +++ pthread.3 2 Dec 2001 12:13:47 - @@ -73,6 +73,11 @@ Creates a new thread of execution. .It Xo .Ft int +.Fn pthread_cancel pthread_t thread +.Xc +Cancels execution of a thread. +.It Xo +.Ft int .Fn pthread_detach pthread_t thread .Xc Marks a thread for deletion. @@ -93,9 +98,9 @@ Causes the calling thread to wait for the termination of the specified thread. .It Xo .Ft int -.Fn pthread_cancel pthread_t thread +.Fn pthread_kill pthread_t thread int sig .Xc -Cancels execution of a thread. +Delivers a signal to a specified thread. .It Xo .Ft int .Fn pthread_once pthread_once_t *once_control void (*init_routine)(void) @@ -106,6 +111,26 @@ .Fn pthread_self void .Xc Returns the thread ID of the calling thread. +.It Xo +.Ft int +.Fn pthread_setcancelstate int state int *oldstate +.Xc +Sets the current thread's cancelability state. +.It Xo +.Ft int +.Fn pthread_setcanceltype int type int *oldtype +.Xc +Sets the current thread's cancelability type. +.It Xo +.Ft void +.Fn pthread_testcancel void +.Xc +Creates a cancellation point in the calling thread. +.It Xo +.Ft void +.Fn pthread_yield void +.Xc +Allows the scheduler to run another thread instead of the current one. .El .Sh ATTRIBUTE OBJECT ROUTINES .Bl -tag -width Er @@ -415,6 +440,7 @@ .Xr pthread_getspecific 3 , .Xr pthread_join 3 , .Xr pthread_key_delete 3 , +.Xr pthread_kill 3 , .Xr pthread_mutex_destroy 3 , .Xr pthread_mutex_init 3 , .Xr pthread_mutex_lock 3 , @@ -431,7 +457,10 @@ .Xr pthread_rwlock_unlock 3 , .Xr pthread_rwlock_wrlock 3 , .Xr pthread_self 3 , -.Xr pthread_setspecific 3 +.Xr pthread_setspecific 3 , +.Xr pthread_setcancelstate 3 , +.Xr pthread_setcanceltype 3 , +.Xr pthread_testcancel 3 .Sh STANDARDS The functions in .Fa libc_r -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
MFC exlock+truncate bug^Wpatch
Hello, Any chances to MFC these changes before 4.5? The bug is very annoying. | mckusick2000/07/03 20:34:11 PDT | | Modified files: |sys/dev/ccd ccd.c |sys/dev/vn vn.c |sys/kern kern_acct.c kern_ktrace.c kern_linker.c | kern_sig.c link_aout.c link_elf.c | vfs_syscalls.c vfs_vnops.c |sys/sys vnode.h |sys/ufs/ufs ufs_extattr.c ufs_quota.c | Log: | | Move the truncation code out of vn_open and into the open system | call after the acquisition of any advisory locks. This fix corrects | a case in which a process tries to open a file with a non-blocking | exclusive lock. Even if it fails to get the lock it would still | truncate the file even though its open failed. With this change, | the truncation is done only after the lock is successfully acquired. | | Obtained from: BSD/OS TIA, - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)
Hello,
Thank you Terry for your answer, I got your meaning. IMHO we can
safely commit my patch meanwhile:
http://news1.macomnet.ru/~maxim/p/kern_lockf.c.diff
Committers? :-)
On Fri, 16 Nov 2001, Terry Lambert wrote:
Maxim Konovalov wrote:
Alfred, John, thanks you very much for your answers. I expected
something similar. Btw are there any smart ways to find out does
underlying FS support inode concept or not? Yes, I know about
vnode.v_tag, but comparing it with VT_UFS/VT_NFS/VT_MFS etc does not
look OK for me.
In theory, vnodes are supposed to be opaque types, with no backing
object exposure.
The real problem here is that the lock list should not be hung
off the inode at all, it should be hung off the vnode, and the
underlying FS objects not referenced (as you noted, there's a
two for one object reference locking problem in the current
code). You still need to go to the backing FS, though, since
you need to proxy NFS client locks to remote objects, etc.. IF
you look at ufs_advlock(), you can see the problem:
ufs_advlock(ap)
struct vop_advlock_args /* {
struct vnode *a_vp;
caddr_t a_id;
int a_op;
struct flock *a_fl;
int a_flags;
} */ *ap;
{
register struct inode *ip = VTOI(ap-a_vp);
return (lf_advlock(ap, (ip-i_lockf), ip-i_size));
}
... the vp lock has to imply an ip lock, at least for the i_lockf
list head, which is procedurally exposed.
A better fix would be to move the lock list into the vnode, and
then call the VOP_ADVLOCK() and assert the lock only if the VFS
VOP_ADVLOCK() returned true.
This really can't be done safely, since you need to addert locally
before remotely, but then you need to delay the local coelesce, or
you can screw up if the local succeeds and the remote fails, or
vice versa.
So the true fix has to include delayed coelescing of the local lock
assertion.
That's true anyway, since the NFSv4 specification demands that the
locks not be coelesced at all, for an implementation to be compliant.
-- Terry
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)
Hello,
On Thu, 15 Nov 2001, Alfred Perlstein wrote:
Yes I saw this, I have no idea what 'JH' stands for either that's why
I left it as is.
The problem is that VTOI is ufs specific, this fix will break
LOCKF_DEBUG for all other FS's other than UFS because it casts
the vnode-data ptr to struct inode *.
So your fix is broken.
Alfred, John, thanks you very much for your answers. I expected
something similar. Btw are there any smart ways to find out does
underlying FS support inode concept or not? Yes, I know about
vnode.v_tag, but comparing it with VT_UFS/VT_NFS/VT_MFS etc does not
look OK for me.
Please just fix lf_print to not deref the inode ptr in the struct.
Here it is. I put you comment, Alfred, above lf_inode assignment.
Index: kern_lockf.c
===
RCS file: /vol0/cvs/ncvs/src/sys/kern/kern_lockf.c,v
retrieving revision 1.38
diff -u -r1.38 kern_lockf.c
--- kern_lockf.c2001/09/12 08:37:44 1.38
+++ kern_lockf.c2001/11/16 11:49:42
@@ -163,7 +163,13 @@
lock-lf_start = start;
lock-lf_end = end;
lock-lf_id = ap-a_id;
-/* lock-lf_inode = ip; */ /* XXX JH */
+ /*
+* XXX The problem is that VTOI is ufs specific, so it will
+* break LOCKF_DEBUG for all other FS's other than UFS because
+* it casts the vnode-data ptr to struct inode *.
+*/
+/* lock-lf_inode = VTOI(ap-a_vp); */
+ lock-lf_inode = (struct inode *)0;
lock-lf_type = fl-l_type;
lock-lf_head = head;
lock-lf_next = (struct lockf *)0;
@@ -768,15 +774,22 @@
printf(proc %ld, (long)((struct proc *)lock-lf_id)-p_pid);
else
printf(id %p, (void *)lock-lf_id);
- /* XXX no %qd in kernel. Truncate. */
- printf( in ino %lu on dev %d, %d, %s, start %ld, end %ld,
- (u_long)lock-lf_inode-i_number,
- major(lock-lf_inode-i_dev),
- minor(lock-lf_inode-i_dev),
- lock-lf_type == F_RDLCK ? shared :
- lock-lf_type == F_WRLCK ? exclusive :
- lock-lf_type == F_UNLCK ? unlock :
- unknown, (long)lock-lf_start, (long)lock-lf_end);
+ if (lock-lf_inode != (struct inode *)0)
+ /* XXX no %qd in kernel. Truncate. */
+ printf( in ino %lu on dev %d, %d, %s, start %ld, end %ld,
+ (u_long)lock-lf_inode-i_number,
+ major(lock-lf_inode-i_dev),
+ minor(lock-lf_inode-i_dev),
+ lock-lf_type == F_RDLCK ? shared :
+ lock-lf_type == F_WRLCK ? exclusive :
+ lock-lf_type == F_UNLCK ? unlock :
+ unknown, (long)lock-lf_start, (long)lock-lf_end);
+ else
+ printf( %s, start %ld, end %ld,
+ lock-lf_type == F_RDLCK ? shared :
+ lock-lf_type == F_WRLCK ? exclusive :
+ lock-lf_type == F_UNLCK ? unlock :
+ unknown, (long)lock-lf_start, (long)lock-lf_end);
if (!TAILQ_EMPTY(lock-lf_blkhd))
printf( block %p\n, (void *)TAILQ_FIRST(lock-lf_blkhd));
else
@@ -789,6 +802,9 @@
struct lockf *lock;
{
register struct lockf *lf, *blk;
+
+ if (lock-lf_inode == (struct inode *)0)
+ return;
printf(%s: Lock list for ino %lu on dev %d, %d:\n,
tag, (u_long)lock-lf_inode-i_number,
-Alfred
tested on -stable.
- -maxim
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)
[ forward to -hackers because of silence in -current ]
-- Forwarded message --
Date: Thu, 8 Nov 2001 17:35:17 +0300 (MSK)
From: Maxim Konovalov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: has 'options LOCKF_DEBUG' ever worked? (w/ patch)
Hello,
Seems 'options LOCKF_DEBUG' does not work at all.
How to repeat:
echo 'options LOCKF_DEBUG' KERNELCONF,
recompile the kernel, install it, reboot,
# sysctl -w debug.lockf_debug=1
$ lockf -k /etc/passwd sleep 1
.. and got the panic:
Script started on Wed Nov 7 14:03:14 2001
miss# gdb -k /usr/obj/usr/src/sys/MISS/kernel.debug vmcore.4
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD 3858432
initial pcb at 303b40
panicstr: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1d
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018f581
stack pointer = 0x10:0xc66ebb40
frame pointer = 0x10:0xc66ebb50
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 416 (lockf)
trap number = 12
panic: page fault
syncing disks... panic: bdwrite: buffer is not busy
Uptime: 6m54s
dumping to dev ad0s1b, offset 393600
dump ata0: resetting devices .. done
63 62 61 [CTRL-C to abort] 60 59 [CTRL-C to abort] 58 [CTRL-C to abort] 57 [CTRL-C to
abort] 56 [CTRL-C to abort] 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37
36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
6 5 4 3 2 1 0
---
#0 0xc0197d7e in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
476 }
(kgdb) bt
#0 0xc0197d7e in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
#1 0xc0df244c in ?? ()
#2 0xc0197b6b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:334
#3 0xc0197f9d in panic (fmt=0xc0299721 bdwrite: buffer is not busy)
at /usr/src/sys/kern/kern_shutdown.c:632
#4 0xc01c93e3 in bdwrite (bp=0xc213a91c) at /usr/src/sys/kern/vfs_bio.c:841
#5 0xc02286ad in ffs_update (vp=0xc65cb380, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:119
#6 0xc023539a in ffs_fsync (ap=0xc66eb9f4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:292
#7 0xc02339aa in ffs_sync (mp=0xc0de5e00, waitfor=2, cred=0xc05ade00,
td=0xc031a8e4) at vnode_if.h:441
#8 0xc01d59c5 in sync (td=0xc031a8e4, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:662
#9 0xc0197770 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:244
#10 0xc0197f9d in panic (fmt=0xc02b129e %s)
at /usr/src/sys/kern/kern_shutdown.c:632
#11 0xc02747e3 in trap_fatal (frame=0xc66ebb00, eva=29)
at /usr/src/sys/i386/i386/trap.c:939
#12 0xc0274525 in trap_pfault (frame=0xc66ebb00, usermode=0, eva=29)
at /usr/src/sys/i386/i386/trap.c:851
#13 0xc0273f37 in trap (frame={tf_fs = -1071841256, tf_es = -965869552,
tf_ds = 16, tf_edi = 0, tf_esi = 0, tf_ebp = -965821616,
tf_isp = -965821652, tf_ebx = -1058144640, tf_edx = -1071033256,
tf_ecx = -1069469696, tf_eax = 1, tf_trapno = 12, tf_err = 0,
tf_eip = -1072106111, tf_cs = 8, tf_eflags = 66118,
tf_esp = -1071033241, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:403
#14 0xc0266488 in alltraps_with_regs_pushed ()
#15 0xc018ea2a in lf_setlock (lock=0xc0edfe80)
at /usr/src/sys/kern/kern_lockf.c:211
#16 0xc018e9c3 in lf_advlock (ap=0xc66ebc04, head=0xc0edd93c, size=0)
at /usr/src/sys/kern/kern_lockf.c:176
#17 0xc023d30e in ufs_advlock (ap=0xc66ebc04)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2190
#18 0xc023d7f9 in ufs_vnoperate (ap=0xc66ebc04)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2658
#19 0xc01d64e3 in open (td=0xc6691e04, uap=0xc66ebd20) at vnode_if.h:843
#20 0xc0274c64 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1, tf_esi = -1077938004, tf_ebp = -1077938176,
tf_isp = -965821068, tf_ebx = -1077937786, tf_edx = -1077938012,
tf_ecx = 672100864, tf_eax = 5, tf_trapno = 12, tf_err = 2,
tf_eip = 671764168, tf_cs = 31, tf_eflags = 663, tf_esp = -1077938220,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1127
#21 0xc02664bd in syscall_with_err_pushed ()
#22 0x8048ae2 in ?? ()
#23 0x80488f1 in ?? ()
(kgdb) quit p quit
miss# exit
exit
Script done on Wed Nov 7 14:04:38 2001
It panics because of if_inode is not initiliazed:
/sys/kern/kern_lockf.c:1.25:153
/* lock-lf_inode = ip; */ /* XXX JH */
I have no idea what ``JH'' means, the comment appeared in 1.10.
The patch against kern_lockf.c:1.38
Index
Re: MFC request (was Re: symlink(2) [Was: Re: tcsh.cat])
On Tue, 4 Sep 2001, Eugene L. Vorokov wrote: I comitted a fix to -current two months ago. It's still in my -stable tree... if Jordan gives the O.K., I will MFC it to -stable. -Matt Erm, sorry, but what does MFC mean here ? I see this term used a lot and I can even guess what it stands for, but I may get it incorrectly ... Merged From Current. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Thu, 26 Jul 2001, Soren Kristensen wrote: Hi, Thanks for the responses, the long delay was because that I didn't have reverse lookup for the 192.168.x.x private IP's in my DNS setup, I just thought it was related with the arp problem Things seem to work fine now, but I still get a lot of those: Jul 26 00:43:48 test256m /kernel: arp: 192.168.1.4 is on sis0 but got reply from 00:a0:cc:a0:d4:07 on sis1 Anybody know how to turn them off ? sysctl net.link.ether.inet.log_arp_wrong_iface ? Btw, the reason that I want to use multiple interface on the same net, is so I can do manufacturing test on my net4501 boxes from a win98 computer with just one network interface Regards, Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Thu, 26 Jul 2001, Eugene L. Vorokov wrote: Anybody know how to turn them off ? sysctl net.link.ether.inet.log_arp_wrong_iface ? vel@bugz:/home/vel # sysctl net.link.ether.inet.log_arp_wrong_iface sysctl: unknown oid 'net.link.ether.inet.log_arp_wrong_iface' Huh ? $ rlog -r1.74 if_ether.c ... description: revision 1.74 date: 2001/01/06 00:45:08; author: alfred; state: Exp; lines: +8 -1 provide a sysctl 'net.link.ether.inet.log_arp_wrong_iface' to allow one to supress logging when ARP replies arrive on the wrong interface: /kernel: arp: 1.2.3.4 is on dc0 but got reply from 00:00:c5:79:d0:0c on dc1 the default is to log just to give notice about possibly incorrectly configured networks. Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
vinum striping quiestion
Hello, I've got a question about vinum. There are two scsi disks with vinum stripe. Here is a vinum config: drive a device /dev/da2s1e drive b device /dev/da3s1e volume vinum0 plex name vinum0.p0 org striped 1024s vol vinum0 sd name vinum0.p0.s0 drive a plex vinum0.p0 len 34791424s driveoffset 265s plexoffset 0s sd name vinum0.p0.s1 drive b plex vinum0.p0 len 34791424s driveoffset 265s plexoffset 1024s # uname -sr FreeBSD 4.1-STABLE There are not any other fs on these disks. The problem is - when I run iozone (iozone 4096 /logs/io0.tmp) I get a very strange result: # iostat -d da1 da3 10 da1 da3 KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 4.50 107 0.47 0.00 0 0.00 4.51 98 0.43 0.00 0 0.00 4.50 116 0.51 0.00 0 0.00 4.49 117 0.52 0.00 0 0.00 4.50 111 0.49 0.00 0 0.00 You see, there is not activity on da3. Are there any explanations? Thanks, maxim - -- Maxim Konovalov, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
