Re: sysinstall compilation issue
--- On Fri, 8/8/08, Oliver Fromme <[EMAIL PROTECTED]> wrote:
> From: Oliver Fromme <[EMAIL PROTECTED]>
> Subject: Re: sysinstall compilation issue
> To: freebsd-stable@FreeBSD.ORG, [EMAIL PROTECTED]
> Date: Friday, August 8, 2008, 9:36 PM
> Unga <[EMAIL PROTECTED]> wrote:
> > This is i386 RELENG_7.
> >
> > Following section of the
> /usr/src/usr.sbin/sysinstall/Makefile does not generate C
> code properly:
> >
> > makedevs.c: Makefile rtermcap
> > echo '#include '
> > makedevs.c
> > ${RTERMCAP} ansi | \
> > file2c 'const char termcap_ansi[]
> = {' ',0};' \
> > > > makedevs.c
> >
> > At compile time, above expands to:
> >
> TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src
> ./rtermcap ansi | file2c 'const char termcap_ansi[] =
> {' ',0};' >> makedevs.c
> >
> > Which generates C code as follows:
> > const char termcap_ansi[] = {
> >
> > ,0};
> >
> > That is, it generates 3 lines, which results a
> compilation error.
> >
> > I presume, intended generated code should be:
> > const char termcap_ansi[] = {' ',0};
> >
> > Am I right?
>
> No, it should generate an array containung a dump of
> the "ansi" termcap entry. Please see the
> file2c(1)
> manpage.
>
> > What is wrong at my end?
> >
> > Note, I linked the rtermcap with ncursesw libraries,
> can that be the cause? Any ideas?
>
> Yes, that's the cause. Why did you do that?
>
> FreeBSD's ncurses port contains a patch so the
> tgetent()
> function (which is used by rtermcap) returns the actual
> termcap entry in the buffer. The original ncurses code
> (which is terminfo based) doesn't do that.
>
> When you linked rtermcap with the wrong library, you
> restored the original behaviour of tgetent(), so the
> output of rtermcap was empty, so file2c produced invalid
> source.
>
Sorry for my late reply on this. I was not well during weekend, an eye ache due
to over work :(
Here is the situation at my end, no matter whether I link with ncurses widec
libs or non-widec libs, its still return the same code as above I mentioned.
Possible causes can be:
1. The way I compile and install ncurses is not correct.
2. OR some essential files required are missing
3. OR there can be an other option
I used truss as follows:
TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src truss -o
truss.log -f ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};'
>> makedevs.c
The last few lines of truss.log shows:
9310: stat("/usr/share/misc/terminfo.db",{mode=-rw-r--r-- ,inode=22613331,size=
3170304,blksize=4096}) = 0 (0x0)
9310: open("/usr/share/misc/terminfo.db",O_RDONLY,0644) = 4 (0x4)
9310: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0)
9310: read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104)
9310: __sysctl(0xbfbfd574,0x2,0xbfbfd570,0xbfbfd57c,0x0,0x0) = 0 (0x0)
9310: lseek(4,0x132000,SEEK_SET)= 1253376 (0x132000)
9310: read(4,"\^^\0\M-|\^O\M-T\^O\M-K\^O\M-*"...,4096) = 4096 (0x1000)
9310: lseek(4,0x26b000,SEEK_SET)= 2535424 (0x26b000)
9310: read(4,"\n\0\M-Y\^O\^O\n\0\n\r\^D\^E\^D"...,4096) = 4096 (0x1000)
9310: close(4) = 0 (0x0)
9310: ioctl(2,TIOCGETA,0xbfbfdba4) = 0 (0x0)
9310: ioctl(2,TIOCGETA,0x81020d8) = 0 (0x0)
9310: ioctl(2,TIOCGETA,0xbfbfdb64) = 0 (0x0)
9310: ioctl(2,TIOCGWINSZ,0xbfbfdbc4)= 0 (0x0)
9310: fstat(1,{mode=p- ,inode=0,size=0,blksize=4096}) = 0 (0x0)
9310: process exit, rval = 0
Note, above log has no entry to open
/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src.
So what can be the issue, ncurses has not been patched correctly or some
essential files missing? If you guys think that ncurses has not been patched
correctly, then I'll open another thread to discuss that.
Best Regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
neighbor discovery problem
Hi, Since I added IPv6 to my network, and started really using it, I'm seeing some strange things happening. For instance, I'm on machine 2a01:678:1:443::443, and I do : $ traceroute6 -n 2a01:678:100:2:: traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from 2a01:678:1:443::443, 64 hops max, 12 byte packets 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A 2a01:678:1:443:: is it's default gateway, and is also directly connected to 2a01:678:100:2::, but it does not seem to be able to contact it. If I log onto the gateway, and I : $ ping6 -c 1 2a01:678:100:2:: PING6(56=40+8+8 bytes) 2a01:678:100:: --> 2a01:678:100:2:: 16 bytes from 2a01:678:100:2::, icmp_seq=0 hlim=64 time=1.146 ms --- 2a01:678:100:2:: ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.146/1.146/1.146/0.000 ms It works, and now, I can : $ traceroute6 -n 2a01:678:100:2:: traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from 2a01:678:1:443::443, 64 hops max, 12 byte packets 1 2a01:678:1:443:: 0.647 ms 0.671 ms 0.417 ms 2 2a01:678:100:2:: 0.852 ms 0.790 ms 0.669 ms Maybe I'm doing something wrong, but, well, I can't seem to find ou what. 2a01:678:1:443::443 is a 7.0 2a01:678:1:443::is a 6.2 2a01:678:100:2::is a 6.0 Those are not up to date to the latest thing you can get, but they're production machines, and I'm not really willing to upgrade them unless I really need to :-) -- Mathieu Arnold pgp4DzemEQu4t.pgp Description: PGP signature
Re: neighbor discovery problem
On Tue, Aug 12, 2008 at 09:45:48AM +0200, Mathieu Arnold wrote: > Since I added IPv6 to my network, and started really using it, I'm seeing > some strange things happening. > > For instance, I'm on machine 2a01:678:1:443::443, and I do : > > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > > 2a01:678:1:443:: is it's default gateway, and is also directly connected to > 2a01:678:100:2::, but it does not seem to be able to contact it. > > If I log onto the gateway, and I : > > $ ping6 -c 1 2a01:678:100:2:: > PING6(56=40+8+8 bytes) 2a01:678:100:: --> 2a01:678:100:2:: > 16 bytes from 2a01:678:100:2::, icmp_seq=0 hlim=64 time=1.146 ms > > --- 2a01:678:100:2:: ping6 statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 1.146/1.146/1.146/0.000 ms > > It works, and now, I can : > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.647 ms 0.671 ms 0.417 ms > 2 2a01:678:100:2:: 0.852 ms 0.790 ms 0.669 ms > > Maybe I'm doing something wrong, but, well, I can't seem to find ou what. > > 2a01:678:1:443::443 is a 7.0 > 2a01:678:1:443::is a 6.2 > 2a01:678:100:2::is a 6.0 > > Those are not up to date to the latest thing you can get, but they're > production machines, and I'm not really willing to upgrade them unless I > really need to :-) Important note: I know absolutely nothing about IPv6. Do you have ACLs on any of these machines? !A in traceroute commonly means there's an ACL blocking said packets: !A (communication with destination network administratively prohibited) A ping from the other host might cause a stateful firewall to begin allowing said traffic to/from the machine which previously wasn't working. If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend posting your problem to the freebsd-pf list instead. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.)
2008/8/11 John Baldwin <[EMAIL PROTECTED]>:
> On Monday 11 August 2008 12:35:17 pm pluknet wrote:
>> 2008/8/11 John Baldwin <[EMAIL PROTECTED]>:
>> > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote:
>> >> Hi John,
>> >>
>> >> I now figured out the "who", the "why" still eludes me.
>> >>
>> >> So, after your MFC of ichss.c on June 27th the device now attaches at my
>> >> laptop. It didn't before, so it could cause no trouble.
>> >>
>> >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has
>> >> been started (if I kill powerd early enough, it seems pretty stable).
>> >>
>> >> I'm now running a kernel from 2008-08-08 with
>> >> hint.ichss.0.disabled="1"
>> >
>> > Ok. Can you get a crashdump from a crash?
>> >
>>
>> ehm,. I am not Ulrich Spoerlein, but I can help with this issue.
>>
>> my crashdump from kgdb and some debug info.
>> (ouch, I forgot to include it in my prev. mail
>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html )
>>
>> wbr,
>> pluknet
>>
>> Unread portion of the kernel message buffer:
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> fault virtual address = 0x38
>> fault code = supervisor read, page not present
>> instruction pointer = 0x20:0xc056cf46
>> stack pointer = 0x28:0xe6592ac8
>> frame pointer = 0x28:0xe6592ac8
>> 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 = 2507 (powerd)
>> Physical memory: 1014 MB
>> Dumping 120 MB: 105 89 73 57 41 25 9
>>
>> #0 doadump () at pcpu.h:195
>> 195 pcpu.h: No such file or directory.
>> in pcpu.h
>> (kgdb) bt
>> #0 doadump () at pcpu.h:195
>> #1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0,
>> dummy4=0xe6592860 "0╛йц") at /media/src-7/sys/ddb/db_command.c:516
>> #2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0,
> dopager=1)
>> at /media/src-7/sys/ddb/db_command.c:413
>> #3 0xc0459655 in db_command_loop ()
> at /media/src-7/sys/ddb/db_command.c:466
>> #4 0xc045b17c in db_trap (type=12, code=0)
>> at /media/src-7/sys/ddb/db_main.c:228
>> #5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88)
>> at /media/src-7/sys/kern/subr_kdb.c:524
>> #6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56)
>> at /media/src-7/sys/i386/i386/trap.c:890
>> #7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56)
>> at /media/src-7/sys/i386/i386/trap.c:812
>> #8 0xc0746d36 in trap (frame=0xe6592a88)
>> at /media/src-7/sys/i386/i386/trap.c:490
>> #9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:139
>> #10 0xc056cf46 in device_is_attached (dev=0x0)
>> at /media/src-7/sys/kern/subr_bus.c:2228
>> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4,
>> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332
>> #12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00,
>> arg2=0, req=0xe6592ba4) at cpufreq_if.h:32
>> ---Type to continue, or q to quit---
>> #13 0xc0554b67 in sysctl_root (oidp=Variable "oidp" is not available.
>> )
>> at /media/src-7/sys/kern/kern_sysctl.c:1306
>> #14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14,
> namelen=4,
>> old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4,
>> retval=0xe6592c10, flags=0) at /media/src-7/sys/kern/kern_sysctl.c:1401
>> #15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc)
>> at /media/src-7/sys/kern/kern_sysctl.c:1336
>> #16 0xc07466d5 in syscall (frame=0xe6592d38)
>> at /media/src-7/sys/i386/i386/trap.c:1035
>> #17 0xc072fdb0 in Xint0x80_syscall ()
>> at /media/src-7/sys/i386/i386/exception.s:196
>> #18 0x0033 in ?? ()
>> Previous frame inner to this frame (corrupt stack?)
>> (kgdb) f 11
>> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4,
>> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332
>> 332 if (!device_is_attached(set->dev)) {
>> (kgdb) list
>> 327 }
>> 328
>> 329 /* Next, set any/all relative frequencies via their drivers.
> */
>> 330 for (i = 0; i < level->rel_count; i++) {
>> 331 set = &level->rel_set[i];
>> 332 if (!device_is_attached(set->dev)) {
>> 333 error = ENXIO;
>> 334 goto out;
>> 335 }
>> 336
>> (kgdb) p level.rel_count
>> $1 = 1986356271
>> (kgdb) p i
>> $2 = 0
>> (kgdb) p level.rel_set
>> $3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0,
>> 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0,
> 0,
>> 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec =
> {0,
>> 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec =
> {
>> 0, 0, 0,
Re: umtxn and Apache 2.2
On Aug 12, 2008, at 12:12 AM, Ivan Voras wrote: Borja Marcos wrote: Hello, I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 with mpm/worker and threads support, and PHP 5.2.6. Everything works like a charm, but I see that Apache is leaking processes that get stuck in umtxn state. I run Apache 2.2 with worker MPM but without mod_php (I use PHP as FastCGI) on many servers and I don't have such problems. Maybe it's PHP's fault? (I agree you need a trace with debugging symbols). May me my fault. It's a system that I didn't use to administrate. I upgraded it from 6.2-REL to 7-STABLE in place, and recompiled packages. But there was a lot of litter. I'm just wondering if that could be a problem. Just in case I've done a thorough cleanup, recompiled needed ports, and included debugging support in Apache. Let's see what happens. And please accept my apologies if this has been a silly false alarm :) Thank you very much, Borja. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
On Mon, 11 Aug 2008, Mike Tancsa wrote: At 05:21 PM 8/8/2008, Robert Watson wrote: http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff These incude the inpcb/inpcbinfo read/write locking changes (although not yet for raw/divert sockets). Any testing, especially with heavy UDP loads, would be much appreciated -- this are fairly complex changes, and also quite a complex MFC. So far so good with the patches. I am running them on a busy sendmail server that also does a lot of DNS locally for itself and a number of other boxes. Excellent news. I have a couple of other reviews and hopefully some more testing coming in, and will commit in a few days if all continues to go well. An updated version of the patch is here: http://www.watson.org/~robert/freebsd/netperf/20080811-7stable-rwlock-inpcb.diff There are no changes from previous versions, but I was asked to regenerate the patch with function names, so have done so. Anyone out there running name servers, NFS over UDP, and other UDP workloads: your testing of this patch prior to commit would be much appreciated. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umtxn and Apache 2.2
On Tue, Aug 12, 2008 at 12:17:05PM +0200, Borja Marcos wrote: > > On Aug 12, 2008, at 12:12 AM, Ivan Voras wrote: > >> Borja Marcos wrote: >>> Hello, >>> I'm running a server with FreeBSD 7-STABLE as of August 8, Apache >>> 2.2 with mpm/worker and threads support, and PHP 5.2.6. >>> Everything works like a charm, but I see that Apache is leaking >>> processes that get stuck in umtxn state. >> >> I run Apache 2.2 with worker MPM but without mod_php (I use PHP as >> FastCGI) on many servers and I don't have such problems. Maybe it's >> PHP's fault? (I agree you need a trace with debugging symbols). > > May me my fault. It's a system that I didn't use to administrate. I > upgraded it from 6.2-REL to 7-STABLE in place, and recompiled packages. > But there was a lot of litter. I'm just wondering if that could be a > problem. > > Just in case I've done a thorough cleanup, recompiled needed ports, and > included debugging support in Apache. Let's see what happens. > > And please accept my apologies if this has been a silly false alarm :) Please be sure to report back with the outcome (in a few days, or whenever suits you) -- I've seen a report of similar oddities (threads locking up) on the suPHP mailing list, when using Apache with the worker MPM. No one stated what state the process is in (re: umtxn), so I'm not sure if it's the same issue as what you've seen. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lagg(4) and failover
Hi Folks, I'm using lagg(4) on some of our servers and I'm just wondering how the failover is implemented. The manpage isn't quite clear: failover Sends and receives traffic only through the master port. If the master port becomes unavailable, the next active port is used. The first interface added is the master port; any interfaces added after that are used as failover devices. What is meant by "becomes unavailable"? Is it just the physical link which needs to become unavailable to trigger a failover? I do wonder, because there might be other faults where the link is still active, but the port is unusable. Think of a wrong vlan on the switch itself. When using bonding under Linux (yeah, I know, the configuration sucks ;) ), I can configure the device to check for arp respones of it's default gateway. If arp to the default gw becomes unavailable, bonding fails over to the next interface and tries it luck over there. With that kind of configuration, I could cover a misconfigured switch port and still have failover. Long Story short: How is failover in lagg(4) implemented? Thanks for any hints :) Or should I ask the OpenBSD boys, since lagg(4) seems to be a port of trunk(4)?? :) best regards, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lagg(4) and failover
On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > I'm using lagg(4) on some of our servers and I'm just wondering how the > failover is implemented. > The manpage isn't quite clear: > > failover Sends and receives traffic only through the master port. > If > the master port becomes unavailable, the next active port > is > used. The first interface added is the master port; any > interfaces added after that are used as failover devices. > > What is meant by "becomes unavailable"? Is it just the physical link which > needs to become unavailable to trigger a failover? Yes. It seems you need lacp protocol described later in the manual. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ath driver causes kernel panic (page fault) on 7.0-STABLE during use
Hi, On Wed, Jul 23, 2008 at 21:37, Edward Ruggeri <[EMAIL PROTECTED]> wrote: > I recently purchased a Lenovo ThinkPad with a ThinkPad 11a/b/g > Wireless LAN Mini Express Adapter (based on the AR5212 chipset). I > got kernel panics while using the wireless card under 7-STABLE Do you still have this problem or did you find a workaround? Does it look something like this? : http://www.freebsd.org/cgi/query-pr.cgi?pr=126475 I upgraded my notebook from 6.3 to 7-STABLE on the weekend and get reproducible kernel panics ~2 sec of using the ath network card. Riggs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
> Since I added IPv6 to my network, and started really using it, I'm seeing > some strange things happening. > > For instance, I'm on machine 2a01:678:1:443::443, and I do : > > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > > 2a01:678:1:443:: is it's default gateway, and is also directly connected to > 2a01:678:100:2::, but it does not seem to be able to contact it. What are your prefix lengths on the various interfaces, and does 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you can show us the config on the interfaces of the three machines then we might be able to get a better idea. I am imagining how you have these three boxes connected in my head, but nothing beats an explanation plus the config :-) > Maybe I'm doing something wrong, but, well, I can't seem to find ou what. > > 2a01:678:1:443::443 is a 7.0 > 2a01:678:1:443::is a 6.2 > 2a01:678:100:2::is a 6.0 I've used all of those with IPv6 and they work fine, it's most likely a small config problem. I had a lot of frustrations with IPv6 when I started using it - though now it is working I wouldn't be without it. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lagg(4) and failover
On Tue, 12 Aug 2008 18:55:52 +0800, Eugene Grosbein <[EMAIL PROTECTED]> wrote: > On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > >> I'm using lagg(4) on some of our servers and I'm just wondering how the >> failover is implemented. >> The manpage isn't quite clear: >> >> failover Sends and receives traffic only through the master > port. >> If >> the master port becomes unavailable, the next active > port >> is >> used. The first interface added is the master port; > any >> interfaces added after that are used as failover > devices. >> >> What is meant by "becomes unavailable"? Is it just the physical link > which >> needs to become unavailable to trigger a failover? > > Yes. It seems you need lacp protocol described later in the manual. > Thanks for your answer. However, IMO lacp doesn't solve that problem. lacp is used for link aggregation, not failover. If I'm wrong over there, I should have a read about lacp... should do that anyway, I guess. The manpage states "In the event of changes in physical connectivity...". Again, does that mean, the link needs to be physically unavailable? If so, it'll be the same behaviour as in failover mode and doesn't solve my problem of a misconfigured switch... Cheers, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
+-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : | Important note: I know absolutely nothing about IPv6. | | Do you have ACLs on any of these machines? !A in traceroute commonly | means there's an ACL blocking said packets: | | !A (communication with destination network administratively prohibited) | | A ping from the other host might cause a stateful firewall to begin | allowing said traffic to/from the machine which previously wasn't | working. | | If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend | posting your problem to the freebsd-pf list instead. Hum, no, I've verified it already, there is pf enabled on the gateway, which is also a firewall, but only on the external interface which does not come in play here. -- Mathieu Arnold pgpRJlh29vC4Q.pgp Description: PGP signature
Re: lagg(4) and failover
On 2008-Aug-12 18:55:52 +0800, Eugene Grosbein <[EMAIL PROTECTED]> wrote: >On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > >> I'm using lagg(4) on some of our servers and I'm just wondering how the >> failover is implemented. As far as I can tell, not especially well :-(. It doesn't seem to detect much short of layer 1 failure. In particular, shutting down the switch port will not trigger a failover. >> The manpage isn't quite clear: >> >> failover Sends and receives traffic only through the master port. >> If >> the master port becomes unavailable, the next active port >> is >> used. The first interface added is the master port; any >> interfaces added after that are used as failover devices. >> >> What is meant by "becomes unavailable"? Is it just the physical link which >> needs to become unavailable to trigger a failover? It seems to be, >Yes. It seems you need lacp protocol described later in the manual. Actually, lacp and failover are used differently: lacp is primarily used to increase the bandwidth between the host and the switch whilst failover is used for redundancy. With lacp, all the physical interfaces must be connected to a single switch. With failover, the physical interfaces will normally be connected to different switches (so a failure in one switch will not cause the loss of all connectivity. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpGk05yQX4JR.pgp Description: PGP signature
Re: lagg(4) and failover
> However, IMO lacp doesn't solve that problem. lacp is used for link > aggregation, not failover. It does both - if one of the links becomes unavailable then it will stop using it. We use this for failover and it works fine, the only caveat being that your LACP device at the far end needs to look like a single phsyical device (the nicer Cisco switches do this quite happily) > The manpage states "In the event of changes in physical connectivity...". > Again, does that mean, the link needs to be physically unavailable? If so, > it'll be the same behaviour as in failover mode and doesn't solve my > problem of a misconfigured switch... lagg is to handle failover at the physical layer for when one of your ether ports fails, or someone unplugs a cable. If I understand you correctly you are looking for something at the next layer up, to handle a problem where the ports work fine, but are not going to their expected destinations. lagg won't do this. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
On Tue, Aug 12, 2008 at 01:17:27PM +0200, Mathieu Arnold wrote: > +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : > | Important note: I know absolutely nothing about IPv6. > | > | Do you have ACLs on any of these machines? !A in traceroute commonly > | means there's an ACL blocking said packets: > | > | !A (communication with destination network administratively prohibited) > | > | A ping from the other host might cause a stateful firewall to begin > | allowing said traffic to/from the machine which previously wasn't > | working. > | > | If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend > | posting your problem to the freebsd-pf list instead. > > Hum, no, I've verified it already, there is pf enabled on the gateway, which > is also a firewall, but only on the external interface which does not come in > play here. That depends. Are you using "set skip" on non-external interfaces, or are you using pass rules to explicitly pass all traffic? Sorry if it sounds like I'm doubting you, but !A really looks like an ACL thing. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
+-le 12.08.2008 13:17:27 +0200, Mathieu Arnold a dit : | +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : || Important note: I know absolutely nothing about IPv6. || || Do you have ACLs on any of these machines? !A in traceroute commonly || means there's an ACL blocking said packets: || || !A (communication with destination network administratively prohibited) || || A ping from the other host might cause a stateful firewall to begin || allowing said traffic to/from the machine which previously wasn't || working. || || If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend || posting your problem to the freebsd-pf list instead. | | Hum, no, I've verified it already, there is pf enabled on the gateway, which | is also a firewall, but only on the external interface which does not come | in play here. There's a pass and not a skip, but all my block rules have log, and no packets show up in pflog, which tends to make me believe that, well, it's not a firewall problem. -- Mathieu Arnold pgpzbCYquQM0m.pgp Description: PGP signature
Re: neighbor discovery problem
+-le 12.08.2008 12:02:42 +0100, Pete French a dit : |> Since I added IPv6 to my network, and started really using it, I'm seeing |> some strange things happening. |> |> For instance, I'm on machine 2a01:678:1:443::443, and I do : |> |> $ traceroute6 -n 2a01:678:100:2:: |> traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from |> 2a01:678:1:443::443, 64 hops max, 12 byte packets |> 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms |> 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A |> |> 2a01:678:1:443:: is it's default gateway, and is also directly connected to |> 2a01:678:100:2::, but it does not seem to be able to contact it. | | What are your prefix lengths on the various interfaces, and does | 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you | can show us the config on the interfaces of the three machines then | we might be able to get a better idea. I am imagining how you have these | three boxes connected in my head, but nothing beats an explanation plus | the config :-) Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both have the "same" gateway, that is, the same box, which has : inet6 2a01:678:1:443:: prefixlen 64 inet6 2a01:678:100:: prefixlen 48 The problem I'm seeing is that before I ping the machine from the gateway, all ndp -a says about this machine is : 2a01:678:100:2:: (incomplete) em0 1sI 3 when I ping it from the first host, I see : 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, 2a01:678:100:2:: to 2a01:678:100:2::, length 104 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > ff02::1:ffe1:c05f: ICMP6, neighbor solicitation, who has fe80::2b0:d0ff:fee1:c05f, length 32 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is fe80::2b0:d0ff:fee1:c05f, length 32 and when I ping it from the gateway, I see : 2a01:678:100:25:: > 2a01:678:100::: ICMP6, neighbor solicitation, who has 2a01:678:100::, length 32 2a01:678:100:: > 2a01:678:100:25::: ICMP6, neighbor advertisement, tgt is 2a01:678:100::, length 24 2a01:678:100:: > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 2a01:678:100:2:: > 2a01:678:100::: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 And I don't understand why there's a difference, and why when the packets don't come from the gateway, the neighbor solicitation goes up wrong and does not work. |> Maybe I'm doing something wrong, but, well, I can't seem to find ou what. |> |> 2a01:678:1:443::443 is a 7.0 |> 2a01:678:1:443::is a 6.2 |> 2a01:678:100:2::is a 6.0 | | I've used all of those with IPv6 and they work fine, it's most likely | a small config problem. I had a lot of frustrations with IPv6 when I | started using it - though now it is working I wouldn't be without it. Well, I'm certain it must be some stupid configuration problem, but, well, I can't seem to find it :-) -- Mathieu Arnold pgprcESzoGv2f.pgp Description: PGP signature
Re: neighbor discovery problem
On Tue, Aug 12, 2008 at 01:34:35PM +0200, Mathieu Arnold wrote: > > > +-le 12.08.2008 13:17:27 +0200, Mathieu Arnold a dit : > | +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : > || Important note: I know absolutely nothing about IPv6. > || > || Do you have ACLs on any of these machines? !A in traceroute commonly > || means there's an ACL blocking said packets: > || > || !A (communication with destination network administratively prohibited) > || > || A ping from the other host might cause a stateful firewall to begin > || allowing said traffic to/from the machine which previously wasn't > || working. > || > || If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend > || posting your problem to the freebsd-pf list instead. > | > | Hum, no, I've verified it already, there is pf enabled on the gateway, which > | is also a firewall, but only on the external interface which does not come > | in play here. > > There's a pass and not a skip, but all my block rules have log, and no > packets show up in pflog, which tends to make me believe that, well, it's not > a firewall problem. A pass on RELENG_7 will still cause state to be kept (keep state is implicit on RELENG_7). Do you see state mismatches? pfctl -s info. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lagg(4) and failover
> As far as I can tell, not especially well :-(. It doesn't seem to detect > much short of layer 1 failure. In particular, shutting down the switch > port will not trigger a failover. Are you using bce devices as your phsyical interfaces ? Take a look at the thread from last week about ifconfig - with the patch posted a port shutdown now *does* trigger a failover quite happily. If you are using e devices then I suggest you try it. > With lacp, all the physical interfaces must be connected to a single > switch. With failover, the physical interfaces will normally be > connected to different switches (so a failure in one switch will not > cause the loss of all connectivity. This is true - with the caveat that certain pairs of switches can be made to appear as a single phsyical device for the purposes of LACP, in which case it works fine for failover. We have two farms here - an old one using a pair of Cisco 3560s and a new one using a pair of 3750-Es. The 3750s will act as a single device and we use LACP on the machines connected to those, but the 3560s appear as a pair of devices, so for those we use failover mode. LACP failover always worked fine, and with the bce patch from last week the normal failover now also works. Nore that you can enable LACP on the 3560,s and it does appear to negotiate and work, but the switches keep changing their idea of which port to use every few seconds. So the connection works, but with high rates of packet loss as a few go missing every time the switch pair flip-flops. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
+-le 12.08.2008 04:31:23 -0700, Jeremy Chadwick a dit : | Sorry if it sounds like I'm doubting you, but !A really looks like an | ACL thing. Oh, and in traceroute(8), !A is "!A (communication with destination network administratively prohibited", which is just right from your point of view, but, in traceroute6(8), !A is "Destination Unreachable - Address Unreachable" Though, in traceroute6(8), !P is "Destination Unreachable - Administratively Prohibited" whereas in traceroute(8), !P is "protocol unreachable" Yes, I know, much much confusing :-) -- Mathieu Arnold pgpe5L4wgM5i1.pgp Description: PGP signature
Re: lagg(4) and failover
Hi Pete, On Tue, 12 Aug 2008 12:30:12 +0100, Pete French <[EMAIL PROTECTED]> wrote: >> However, IMO lacp doesn't solve that problem. lacp is used for link >> aggregation, not failover. > > It does both - if one of the links becomes unavailable then it will > stop using it. We use this for failover and it works fine, the only > caveat being that your LACP device at the far end needs to look like > a single phsyical device (the nicer Cisco switches do this quite happily) > thanks for that info. >> The manpage states "In the event of changes in physical > connectivity...". >> Again, does that mean, the link needs to be physically unavailable? If > so, >> it'll be the same behaviour as in failover mode and doesn't solve my >> problem of a misconfigured switch... > > lagg is to handle failover at the physical layer for when one of your > ether ports fails, or someone unplugs a cable. If I understand you > correctly you are looking for something at the next layer up, to handle > a problem where the ports work fine, but are not going to their expected > destinations. lagg won't do this. > Thats unfortunate... bonding in Linux is capable of doing this and solaris too. Well then. At least everythings clear now. And in the end, clarifing things was the reason for that mail thread :) Cheers, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
+-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : | A pass on RELENG_7 will still cause state to be kept (keep state is | implicit on RELENG_7). the gateway is a 6.2 ;-) | Do you see state mismatches? pfctl -s info. There are some, but, hum searches40881638069911471.5/s state-mismatch 86554670.2/s the box has been up more than 400 days, and the number has not been going up while I was trying my things. I bet it goes up when something goes wrong in my network, which happens :-) -- Mathieu Arnold pgpYYcQyQTvQX.pgp Description: PGP signature
Re: em(4) on FreeBSD is sometimes annoying
> For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 > and neither install has this problem. I can cold boot it with the NIC > unplugged, plug in a cable, I get a link light and ifconfig em0 goes to > active, dhclient em0 gets an IP successfully. > Did you try to run /etc/rc.d/netif start after you've booted your laptop unplugged? Try to do that, THEN connect the cable. The problem appears ONLY in this situation. And it's quite common, because you often use your laptop with wireless network and suddenly you decide to connect it to wired network without having to switch the laptop off. My NIC is in such a state that I am forced to switch it off, or else I don't get link signal. I don't think it's a BIOS firmware problem (I have tried every update). I can remember that Linux had this issues, too a while ago. It works there now, but FreeBSD is still the same. Please read the steps how I cause this situation. It appears ONLY when you do it like I described it. I've seen that people first boot with plugged in cable and start to play with dhclient. Both is wrong. Correct steps to reproduce is: You have to start with unhooked interface AND the line ifconfig_re0="DHCP" in /etc/rc.conf. Then wait until you can login and try to attach the cable. -- Martin ___ EINE FÜR ALLE: die kostenlose WEB.DE-Plattform für Freunde und Deine Homepage mit eigenem Namen. Jetzt starten! http://unddu.de/[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
> Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both > have the "same" gateway, that is, the same box, which has : > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 O.K., that should work. My best advice here is to do what I did - which is to disable 'pf' entirely and see if it works then. When it does you know the IPv6 config is correct and can then work out which rule in 'pf' is stopping it working when enabled. Sorry, but I van't think of anything else right now, and I guess that may not be an option on a production machine. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lagg(4) and failover
On Tuesday 12 August 2008 13:43:29 Marian Hettwer wrote: > Hi Pete, > > On Tue, 12 Aug 2008 12:30:12 +0100, Pete French > > <[EMAIL PROTECTED]> wrote: > >> However, IMO lacp doesn't solve that problem. lacp is used for link > >> aggregation, not failover. > > > > It does both - if one of the links becomes unavailable then it will > > stop using it. We use this for failover and it works fine, the only > > caveat being that your LACP device at the far end needs to look like > > a single phsyical device (the nicer Cisco switches do this quite happily) > > thanks for that info. > > >> The manpage states "In the event of changes in physical > > > > connectivity...". > > > >> Again, does that mean, the link needs to be physically unavailable? If > > > > so, > > > >> it'll be the same behaviour as in failover mode and doesn't solve my > >> problem of a misconfigured switch... > > > > lagg is to handle failover at the physical layer for when one of your > > ether ports fails, or someone unplugs a cable. If I understand you > > correctly you are looking for something at the next layer up, to handle > > a problem where the ports work fine, but are not going to their expected > > destinations. lagg won't do this. > > Thats unfortunate... > bonding in Linux is capable of doing this and solaris too. > Well then. At least everythings clear now. And in the end, clarifing things > was the reason for that mail thread :) You are looking for net/ifstated -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
+-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : | A pass on RELENG_7 will still cause state to be kept (keep state is | implicit on RELENG_7). I've just tried doing pfctl -d, and not help, I *really* don't believe that it's a pf problem ;-) -- Mathieu Arnold pgp0e94czU8F1.pgp Description: PGP signature
Re: lagg(4) and failover
On 2008-Aug-12 13:43:29 +0200, Marian Hettwer <[EMAIL PROTECTED]> wrote: >> lagg is to handle failover at the physical layer for when one of your >> ether ports fails, or someone unplugs a cable. If I understand you >> >Thats unfortunate... I tend to agree. >bonding in Linux is capable of doing this and solaris too. It shouldn't be too difficult to create something that behaves functionally similarly to Slowaris ipmpd (and with marginally more effort, you could create something that could be configured to behave sensibly). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgph5IlfzxY1r.pgp Description: PGP signature
Re: neighbor discovery problem
On Tue, Aug 12, 2008 at 02:01:45PM +0200, Mathieu Arnold wrote: > +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : > | A pass on RELENG_7 will still cause state to be kept (keep state is > | implicit on RELENG_7). > > I've just tried doing pfctl -d, and not help, I *really* don't believe that > it's a pf problem ;-) Cool -- just covering all the bases! :-) P.S. -- The high number of state-mismatches you have may be the result of PR 125261, which has been fixed (in RELENG_7 and HEAD). It's unrelated to your issue, but I thought I'd mention it anyways. http://www.freebsd.org/cgi/query-pr.cgi?pr=125261 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
+-le 12.08.2008 12:50:35 +0100, Pete French a dit : |> Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both |> have the "same" gateway, that is, the same box, which has : |> inet6 2a01:678:1:443:: prefixlen 64 |> inet6 2a01:678:100:: prefixlen 48 | | O.K., that should work. My best advice here is to do what I did - which is | to disable 'pf' entirely and see if it works then. When it does you know | the IPv6 config is correct and can then work out which rule in 'pf' is | stopping it working when enabled. Sorry, but I van't think of anything else | right now, and I guess that may not be an option on a production machine. Well, stopping the firewall a few seconds can't do really bad things, and, well, pfctl -d, wait a bit, try again, still no luck... The network is pretty simple, gateway : em0: flags=8843 mtu 1500 options=b inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 inet6 2a01:678:1:443:: prefixlen 64 inet6 2a01:678:100:: prefixlen 48 first machine : bridge0: flags=8843 metric 0 mtu 1500 inet6 fe80::2d0:dead:beef:cafe%bridge0 prefixlen 64 scopeid 0x4 inet6 2a01:678:1:443::443 prefixlen 64 destination machine : fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::2b0:d0ff:fee1:c05f%fxp0 prefixlen 64 scopeid 0x1 inet6 2a01:678:100:2:: prefixlen 48 All three ports on a switch. I don't believe it's a problem in if_bridge(4) because it's the same if I try from outside my network. -- Mathieu Arnold pgpsPPJRM7sTR.pgp Description: PGP signature
Re: lagg(4) and failover
Hi Max, On Tue, 12 Aug 2008 14:00:18 +0200, Max Laier <[EMAIL PROTECTED]> wrote: >> Thats unfortunate... >> bonding in Linux is capable of doing this and solaris too. >> Well then. At least everythings clear now. And in the end, clarifing > things >> was the reason for that mail thread :) > > You are looking for net/ifstated > at a first glance into pkg-descr. Yeah, seems like I'm looking for ifstated. Thanks for the heads up :-) Cheers, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
+-le 12.08.2008 05:10:05 -0700, Jeremy Chadwick a dit : | On Tue, Aug 12, 2008 at 02:01:45PM +0200, Mathieu Arnold wrote: |> +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : |> | A pass on RELENG_7 will still cause state to be kept (keep state is |> | implicit on RELENG_7). |> |> I've just tried doing pfctl -d, and not help, I *really* don't believe that |> it's a pf problem ;-) | | Cool -- just covering all the bases! :-) Well, could have been, I'm getting crazy with this problem. | P.S. -- The high number of state-mismatches you have may be the result | of PR 125261, which has been fixed (in RELENG_7 and HEAD). It's | unrelated to your issue, but I thought I'd mention it anyways. | | http://www.freebsd.org/cgi/query-pr.cgi?pr=125261 I have plans to upgrade the gateway to RELENG_7, but, I'm supposed to be on vacation right now, so, it'll wait until I get back. -- Mathieu Arnold pgp1AgQWR8Dwo.pgp Description: PGP signature
Re: lagg(4) and failover
Hi Peter, On Tue, 12 Aug 2008 22:03:07 +1000, Peter Jeremy <[EMAIL PROTECTED]> wrote: > On 2008-Aug-12 13:43:29 +0200, Marian Hettwer <[EMAIL PROTECTED]> wrote: >>> lagg is to handle failover at the physical layer for when one of your >>> ether ports fails, or someone unplugs a cable. If I understand you >>> >>Thats unfortunate... > > I tend to agree. > >>bonding in Linux is capable of doing this and solaris too. > > It shouldn't be too difficult to create something that behaves > functionally similarly to Slowaris ipmpd (and with marginally more > effort, you could create something that could be configured to behave > sensibly). > har har. Yeah, you're right. But as Max pointed out, theres net/ifstated. I'll have a look into that tiny daemon :) Cheers, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
> The network is pretty simple, > > gateway : > em0: flags=8843 mtu 1500 > options=b > inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 Hmmm, are machine numbers of all zeroes legal in IPv6 ? I would configure those as '2a01:678:1:443::1' and '2a01:678:100::1' if I were you. All zeroes as a machine number is certainly a no-no in IPv4, and I wouldn't use it in IPv6 either. I have no idea if it's actually a problem, but it gives me a bad feeling -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ath driver causes kernel panic (page fault) on 7.0-STABLE during use
On Tue, Aug 12, 2008 at 5:34 AM, Thomas Zander <[EMAIL PROTECTED]> wrote: > Hi, > > On Wed, Jul 23, 2008 at 21:37, Edward Ruggeri <[EMAIL PROTECTED]> wrote: > >> I recently purchased a Lenovo ThinkPad with a ThinkPad 11a/b/g >> Wireless LAN Mini Express Adapter (based on the AR5212 chipset). I >> got kernel panics while using the wireless card under 7-STABLE > > Do you still have this problem or did you find a workaround? > Does it look something like this? : > http://www.freebsd.org/cgi/query-pr.cgi?pr=126475 > > I upgraded my notebook from 6.3 to 7-STABLE on the weekend and get > reproducible kernel panics ~2 sec of using the ath network card. I never really got an answer about this bug. I'm sorry someone else has it. The bug went away when I updated world and rebuilt the kernel maybe two weeks ago. There didn't seem to be a recent change to the ath driver at the time, so maybe it was something outside it that caused the problem. It's hard to say... I am no longer on the freebsd-stable list, so if there's anything else I can do, please feel free to write me directly. Sincerely, -- Ned Ruggeri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
On Tuesday 12 August 2008 13:35:33 Mathieu Arnold wrote: > +-le 12.08.2008 12:02:42 +0100, Pete French a dit : > |> Since I added IPv6 to my network, and started really using it, I'm > |> seeing some strange things happening. > |> > |> For instance, I'm on machine 2a01:678:1:443::443, and I do : > |> > |> $ traceroute6 -n 2a01:678:100:2:: > |> traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > |> 2a01:678:1:443::443, 64 hops max, 12 byte packets > |> 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > |> 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > |> > |> 2a01:678:1:443:: is it's default gateway, and is also directly connected > |> to 2a01:678:100:2::, but it does not seem to be able to contact it. > | > | What are your prefix lengths on the various interfaces, and does > | 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you > | can show us the config on the interfaces of the three machines then > | we might be able to get a better idea. I am imagining how you have these > | three boxes connected in my head, but nothing beats an explanation plus > | the config :-) > > Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both > have the "same" gateway, that is, the same box, which has : > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 > > The problem I'm seeing is that before I ping the machine from the gateway, > all ndp -a says about this machine is : > > 2a01:678:100:2:: (incomplete) em0 1sI > 3 > > when I ping it from the first host, I see : > > 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length > 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, > who has 2a01:678:100:2::, length 32 > fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, ^--^ There is your problem. You have all three hosts connected to the same broadcast domain? Disable redirects or separate the domains using VLAN or similar - otherwise the gateway will get smart and try to avoid work. > 2a01:678:100:2:: to 2a01:678:100:2::, length 104 > fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor > advertisement, tgt is 2a01:678:100:2::, length 32 > fe80::207:e9ff:fe0e:dead > ff02::1:ffe1:c05f: ICMP6, neighbor solicitation, > who has fe80::2b0:d0ff:fee1:c05f, length 32 > fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor > advertisement, tgt is fe80::2b0:d0ff:fee1:c05f, length 32 > > and when I ping it from the gateway, I see : > > 2a01:678:100:25:: > 2a01:678:100::: ICMP6, neighbor solicitation, who has > 2a01:678:100::, length 32 > 2a01:678:100:: > 2a01:678:100:25::: ICMP6, neighbor advertisement, tgt is > 2a01:678:100::, length 24 > 2a01:678:100:: > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has > 2a01:678:100:2::, length 32 > 2a01:678:100:2:: > 2a01:678:100::: ICMP6, neighbor advertisement, tgt is > 2a01:678:100:2::, length 32 > > And I don't understand why there's a difference, and why when the packets > don't come from the gateway, the neighbor solicitation goes up wrong and > does not work. > > |> Maybe I'm doing something wrong, but, well, I can't seem to find ou > |> what. > |> > |> 2a01:678:1:443::443 is a 7.0 > |> 2a01:678:1:443::is a 6.2 > |> 2a01:678:100:2::is a 6.0 > | > | I've used all of those with IPv6 and they work fine, it's most likely > | a small config problem. I had a lot of frustrations with IPv6 when I > | started using it - though now it is working I wouldn't be without it. > > Well, I'm certain it must be some stupid configuration problem, but, well, > I can't seem to find it :-) -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neighbor discovery problem
+-le 12.08.2008 13:26:00 +0100, Pete French a dit : |> The network is pretty simple, |> |> gateway : |> em0: flags=8843 mtu 1500 |> options=b |> inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 |> inet6 2a01:678:1:443:: prefixlen 64 |> inet6 2a01:678:100:: prefixlen 48 | | Hmmm, are machine numbers of all zeroes legal in IPv6 ? I would | configure those as '2a01:678:1:443::1' and '2a01:678:100::1' if | I were you. All zeroes as a machine number is certainly a no-no in | IPv4, and I wouldn't use it in IPv6 either. I have no idea if it's | actually a problem, but it gives me a bad feeling Well, hum, I'm pretty sure there's no network and broadcast addresses in IPv6. Routing works, ping works, only neighbor discovery does strange things, from time to time. I'm a bit reluctant to change all that the eve of my going on vacation. I just discovered that I can't ping6 ff02::1%em0 on the gateway, well, I can, there are answers comming back, but, hum, they don't seem to sink in, and ping6 don't say anything. I'll investigate. -- Mathieu Arnold pgpkJ4mjdQXIE.pgp Description: PGP signature
Re: kernel panic
On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote:
> On Monday 11 August 2008 23:04:30 John Baldwin wrote:
> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote:
> > > Hi,
> > >
> > > I am a kgdb newbie, so please be patient.
> > > I suspect (just based on the fact that this is the 4th time I edit text
> >
> > files on my NTFS partition through ntfs-3g, using Emacs, and getting
> > frequent I/O error messages inside Emacs, and then a kernel panic) that
> > this is a ntfs-3g related problem.
> >
> > > If you ask me exactly how to reproduce it, I sorry, I can tell you
> > > exactly
> >
> > (but see the kgdb output below).
> >
> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530
> > >
> > > Just a suggestion for a patch (without knowing the functionality
> >
> > of /usr/src/sys/kern/vfs_bio.c):
> > > The line where the kernel panics:
> > > /usr/src/sys/kern/vfs_bio.c:
> > > --
> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
> > > ...
> > > --
> > >
> > > Comparing to another file, which does error checking before calling
> >
> > VM_OBJECT_LOCK:
> > > /usr/src/sys/kern/vfs_aio.c:
> > > --
> > > if (vp->v_object != NULL) {
> > > VM_OBJECT_LOCK(vp->v_object);
> > > ...
> > > --
> > >
> > > Perhaps the kernel panic could be avoided with the following patch?
> > > /usr/src/sys/kern/vfs_bio.c (suggested patch):
> > > --
> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) {
> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
> > > ...
> > > --
> > >
> > > Please let me know if you need more information.
> > >
> > > Regards,
> > > Johan Kuuse
> > >
> > > ---
> > > kgdb kernel.debug
> > > /var/crash/vmcore.1
> > > [GDB will not be able to debug user-mode threads:
> > > /usr/lib/libthread_db.so:
> >
> > Undefined symbol "ps_pglobal_lookup"]
> >
> > > GNU gdb 6.1.1 [FreeBSD]
> > > Copyright 2004 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-marcel-freebsd".
> > >
> > > Unread portion of the kernel message buffer:
> > >
> > >
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 0; apic id = 00
> > > fault virtual address = 0x34
> > > fault code = supervisor read, page not present
> > > instruction pointer = 0x20:0xc07b6de4
> > > stack pointer = 0x28:0xe79de7c8
> > > frame pointer = 0x28:0xe79de7e8
> > > 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 = 1214 (opera)
> > > trap number = 12
> > > panic: page fault
> > > cpuid = 0
> > > Uptime: 5h20m30s
> > > Physical memory: 2035 MB
> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11
> > >
> > > #0 doadump () at pcpu.h:195
> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> > > (kgdb) list *0xc07b6de4
> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530).
> > > 1525vfs_vmio_release(struct buf *bp)
> > > 1526{
> > > 1527int i;
> > > 1528vm_page_t m;
> > > 1529
> > > 1530VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
> > > 1531vm_page_lock_queues();
> > > 1532for (i = 0; i < bp->b_npages; i++) {
> > > 1533m = bp->b_pages[i];
> > > 1534bp->b_pages[i] = NULL;
> > > (kgdb) bt
> > > #0 doadump () at pcpu.h:195
> > > #1 0xc0754457 in boot (howto=260) at
> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic
> > > (fmt=Variable "fmt" is not available.
> > > ) at /usr/src/sys/kern/kern_shutdown.c:563
> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52)
> >
> > at /usr/src/sys/i386/i386/trap.c:899
> >
> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52)
> >
> > at /usr/src/sys/i386/i386/trap.c:812
> >
> > > #5 0xc0a49c8c in trap (frame=0xe79de788)
> >
> > at /usr/src/sys/i386/i386/trap.c:490
> >
> > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c)
> >
> > at /usr/src/sys/kern/vfs_bio.c:1530
> >
> > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable
> > > "size" is
> >
> > not available.
> >
> > > ) at /usr/src/sys/kern/vfs_bio.c:1847
> > > #9 0xc07ba118 in getblk (vp=0xc
Re: neighbor discovery problem
+-le 12.08.2008 14:53:00 +0200, Mathieu Arnold a dit : | I'll investigate. Ok, I rebooted the gateway, and now, it works just as it should... Maybe once upon a time, I did something strange, which borked everything... Anyway, thanks all :-) -- Mathieu Arnold pgpFAKhbnBRan.pgp Description: PGP signature
Re: neighbor discovery problem
+-le 12.08.2008 14:53:24 +0200, Max Laier a dit : |> 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length |> 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, |> who has 2a01:678:100:2::, length 32 |> fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, | ^--^ | | There is your problem. You have all three hosts connected to the same | broadcast domain? Disable redirects or separate the domains using VLAN or | similar - otherwise the gateway will get smart and try to avoid work. Hum, yes, the same domain, but it must not have been the problem, now, it works, and I still have : fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, 2a01:678:100:2:: to 2a01:678:100:2::, length 104 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 but it works. -- Mathieu Arnold pgpKeAREtE5Hl.pgp Description: PGP signature
Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.)
On Tuesday 12 August 2008 04:36:29 am pluknet wrote:
> 2008/8/11 John Baldwin <[EMAIL PROTECTED]>:
> > On Monday 11 August 2008 12:35:17 pm pluknet wrote:
> >> 2008/8/11 John Baldwin <[EMAIL PROTECTED]>:
> >> > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote:
> >> >> Hi John,
> >> >>
> >> >> I now figured out the "who", the "why" still eludes me.
> >> >>
> >> >> So, after your MFC of ichss.c on June 27th the device now attaches at
my
> >> >> laptop. It didn't before, so it could cause no trouble.
> >> >>
> >> >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has
> >> >> been started (if I kill powerd early enough, it seems pretty stable).
> >> >>
> >> >> I'm now running a kernel from 2008-08-08 with
> >> >> hint.ichss.0.disabled="1"
> >> >
> >> > Ok. Can you get a crashdump from a crash?
> >> >
> >>
> >> ehm,. I am not Ulrich Spoerlein, but I can help with this issue.
> >>
> >> my crashdump from kgdb and some debug info.
> >> (ouch, I forgot to include it in my prev. mail
> >>
http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html )
> >>
> >> wbr,
> >> pluknet
> >>
> >> Unread portion of the kernel message buffer:
> >>
> >>
> >> Fatal trap 12: page fault while in kernel mode
> >> fault virtual address = 0x38
> >> fault code = supervisor read, page not present
> >> instruction pointer = 0x20:0xc056cf46
> >> stack pointer = 0x28:0xe6592ac8
> >> frame pointer = 0x28:0xe6592ac8
> >> 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 = 2507 (powerd)
> >> Physical memory: 1014 MB
> >> Dumping 120 MB: 105 89 73 57 41 25 9
> >>
> >> #0 doadump () at pcpu.h:195
> >> 195 pcpu.h: No such file or directory.
> >> in pcpu.h
> >> (kgdb) bt
> >> #0 doadump () at pcpu.h:195
> >> #1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0,
> >> dummy4=0xe6592860 "0╛йц") at /media/src-7/sys/ddb/db_command.c:516
> >> #2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0,
> > dopager=1)
> >> at /media/src-7/sys/ddb/db_command.c:413
> >> #3 0xc0459655 in db_command_loop ()
> > at /media/src-7/sys/ddb/db_command.c:466
> >> #4 0xc045b17c in db_trap (type=12, code=0)
> >> at /media/src-7/sys/ddb/db_main.c:228
> >> #5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88)
> >> at /media/src-7/sys/kern/subr_kdb.c:524
> >> #6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56)
> >> at /media/src-7/sys/i386/i386/trap.c:890
> >> #7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56)
> >> at /media/src-7/sys/i386/i386/trap.c:812
> >> #8 0xc0746d36 in trap (frame=0xe6592a88)
> >> at /media/src-7/sys/i386/i386/trap.c:490
> >> #9 0xc072fd4b in calltrap ()
at /media/src-7/sys/i386/i386/exception.s:139
> >> #10 0xc056cf46 in device_is_attached (dev=0x0)
> >> at /media/src-7/sys/kern/subr_bus.c:2228
> >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4,
> >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332
> >> #12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00,
> >> arg2=0, req=0xe6592ba4) at cpufreq_if.h:32
> >> ---Type to continue, or q to quit---
> >> #13 0xc0554b67 in sysctl_root (oidp=Variable "oidp" is not available.
> >> )
> >> at /media/src-7/sys/kern/kern_sysctl.c:1306
> >> #14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14,
> > namelen=4,
> >> old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4,
> >> retval=0xe6592c10, flags=0)
at /media/src-7/sys/kern/kern_sysctl.c:1401
> >> #15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc)
> >> at /media/src-7/sys/kern/kern_sysctl.c:1336
> >> #16 0xc07466d5 in syscall (frame=0xe6592d38)
> >> at /media/src-7/sys/i386/i386/trap.c:1035
> >> #17 0xc072fdb0 in Xint0x80_syscall ()
> >> at /media/src-7/sys/i386/i386/exception.s:196
> >> #18 0x0033 in ?? ()
> >> Previous frame inner to this frame (corrupt stack?)
> >> (kgdb) f 11
> >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4,
> >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332
> >> 332 if (!device_is_attached(set->dev)) {
> >> (kgdb) list
> >> 327 }
> >> 328
> >> 329 /* Next, set any/all relative frequencies via their
drivers.
> > */
> >> 330 for (i = 0; i < level->rel_count; i++) {
> >> 331 set = &level->rel_set[i];
> >> 332 if (!device_is_attached(set->dev)) {
> >> 333 error = ENXIO;
> >> 334 goto out;
> >> 335 }
> >> 336
> >> (kgdb) p level.rel_count
> >> $1 = 1986356271
> >> (kgdb) p i
> >> $2 = 0
> >> (kgdb) p level.rel_set
> >> $3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spe
Re: lagg(4) and failover
On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > Hi Folks, > > I'm using lagg(4) on some of our servers and I'm just wondering how the > failover is implemented. > The manpage isn't quite clear: > > failover Sends and receives traffic only through the master port. > If > the master port becomes unavailable, the next active port > is > used. The first interface added is the master port; any > interfaces added after that are used as failover devices. > > What is meant by "becomes unavailable"? Is it just the physical link which > needs to become unavailable to trigger a failover? > > I do wonder, because there might be other faults where the link is still > active, but the port is unusable. Think of a wrong vlan on the switch > itself. > > When using bonding under Linux (yeah, I know, the configuration sucks ;) ), > I can configure the device to check for arp respones of it's default > gateway. If arp to the default gw becomes unavailable, bonding fails over > to the next interface and tries it luck over there. > With that kind of configuration, I could cover a misconfigured switch port > and still have failover. > > Long Story short: How is failover in lagg(4) implemented? It is simply performed on the physical link state, nothing more. Adding smarter methods of detecting the link such as what Linux does are very welcome. You may want to also look at LACP mode where heatbeat frames are exchanged with the peer. Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lagg(4) and failover
On Tue, Aug 12, 2008 at 09:24:30PM +1000, Peter Jeremy wrote: > On 2008-Aug-12 18:55:52 +0800, Eugene Grosbein <[EMAIL PROTECTED]> wrote: > >On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > > > >> I'm using lagg(4) on some of our servers and I'm just wondering how the > >> failover is implemented. > > As far as I can tell, not especially well :-(. It doesn't seem to detect > much short of layer 1 failure. In particular, shutting down the switch > port will not trigger a failover. > > >> The manpage isn't quite clear: > >> > >> failover Sends and receives traffic only through the master port. > >> If > >> the master port becomes unavailable, the next active port > >> is > >> used. The first interface added is the master port; any > >> interfaces added after that are used as failover devices. > >> > >> What is meant by "becomes unavailable"? Is it just the physical link which > >> needs to become unavailable to trigger a failover? > > It seems to be, > > >Yes. It seems you need lacp protocol described later in the manual. > > Actually, lacp and failover are used differently: lacp is primarily > used to increase the bandwidth between the host and the switch whilst > failover is used for redundancy. > > With lacp, all the physical interfaces must be connected to a single > switch. With failover, the physical interfaces will normally be > connected to different switches (so a failure in one switch will not > cause the loss of all connectivity. Actually you can use lacp in failover mode by connecting interfaces to different switches. It will only bundle an aggregation to one switch at a time but if that becomes unavailable then it will automatically choose the next switch. Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
command not found: problem with dash in filenames
NOTICE: when I run purepw it is located and runned, but when I run pure-pw (NOTICE: dash in name) I get: Command not found kes# env |grep PATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin kes# env | grep PATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin kes# ls -l /usr/local/bin/pure* -r-xr-xr-x 1 root wheel 24052 12 авг 06:24 /usr/local/bin/pure-pw -r-xr-xr-x 1 root wheel 4432 12 авг 06:24 /usr/local/bin/pure-pwconvert -r-xr-xr-x 1 root wheel 6016 12 авг 06:24 /usr/local/bin/pure-statsdecode kes# pure-pw pure-pw: Command not found kes# /usr/local/bin/pure-pw Usage : pure-pw useradd [-f ] -u [-g ] -D/-d [-c ] [-t ] [-T ] . kes# cp pure-pw purepw kes# purepw Usage : pure-pw useradd [-f ] -u [-g ] -D/-d [-c ] [-t ] [-T ] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic
> On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote:
>> On Monday 11 August 2008 23:04:30 John Baldwin wrote:
>> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote:
>> > > Hi,
>> > >
>> > > I am a kgdb newbie, so please be patient.
>> > > I suspect (just based on the fact that this is the 4th time I edit text
>> >
>> > files on my NTFS partition through ntfs-3g, using Emacs, and getting
>> > frequent I/O error messages inside Emacs, and then a kernel panic) that
>> > this is a ntfs-3g related problem.
>> >
>> > > If you ask me exactly how to reproduce it, I sorry, I can tell you
>> > > exactly
>> >
>> > (but see the kgdb output below).
>> >
>> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530
>> > >
>> > > Just a suggestion for a patch (without knowing the functionality
>> >
>> > of /usr/src/sys/kern/vfs_bio.c):
>> > > The line where the kernel panics:
>> > > /usr/src/sys/kern/vfs_bio.c:
>> > > --
>> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
>> > > ...
>> > > --
>> > >
>> > > Comparing to another file, which does error checking before calling
>> >
>> > VM_OBJECT_LOCK:
>> > > /usr/src/sys/kern/vfs_aio.c:
>> > > --
>> > > if (vp->v_object != NULL) {
>> > > VM_OBJECT_LOCK(vp->v_object);
>> > > ...
>> > > --
>> > >
>> > > Perhaps the kernel panic could be avoided with the following patch?
>> > > /usr/src/sys/kern/vfs_bio.c (suggested patch):
>> > > --
>> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) {
>> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
>> > > ...
>> > > --
>> > >
>> > > Please let me know if you need more information.
>> > >
>> > > Regards,
>> > > Johan Kuuse
>> > >
>> > > ---
>> > > kgdb kernel.debug
>> > > /var/crash/vmcore.1
>> > > [GDB will not be able to debug user-mode threads:
>> > > /usr/lib/libthread_db.so:
>> >
>> > Undefined symbol "ps_pglobal_lookup"]
>> >
>> > > GNU gdb 6.1.1 [FreeBSD]
>> > > Copyright 2004 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-marcel-freebsd".
>> > >
>> > > Unread portion of the kernel message buffer:
>> > >
>> > >
>> > > Fatal trap 12: page fault while in kernel mode
>> > > cpuid = 0; apic id = 00
>> > > fault virtual address = 0x34
>> > > fault code = supervisor read, page not present
>> > > instruction pointer = 0x20:0xc07b6de4
>> > > stack pointer = 0x28:0xe79de7c8
>> > > frame pointer = 0x28:0xe79de7e8
>> > > 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 = 1214 (opera)
>> > > trap number = 12
>> > > panic: page fault
>> > > cpuid = 0
>> > > Uptime: 5h20m30s
>> > > Physical memory: 2035 MB
>> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11
>> > >
>> > > #0 doadump () at pcpu.h:195
>> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
>> > > (kgdb) list *0xc07b6de4
>> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530).
>> > > 1525vfs_vmio_release(struct buf *bp)
>> > > 1526{
>> > > 1527int i;
>> > > 1528vm_page_t m;
>> > > 1529
>> > > 1530VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
>> > > 1531vm_page_lock_queues();
>> > > 1532for (i = 0; i < bp->b_npages; i++) {
>> > > 1533m = bp->b_pages[i];
>> > > 1534bp->b_pages[i] = NULL;
>> > > (kgdb) bt
>> > > #0 doadump () at pcpu.h:195
>> > > #1 0xc0754457 in boot (howto=260) at
>> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic
>> > > (fmt=Variable "fmt" is not available.
>> > > ) at /usr/src/sys/kern/kern_shutdown.c:563
>> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52)
>> >
>> > at /usr/src/sys/i386/i386/trap.c:899
>> >
>> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52)
>> >
>> > at /usr/src/sys/i386/i386/trap.c:812
>> >
>> > > #5 0xc0a49c8c in trap (frame=0xe79de788)
>> >
>> > at /usr/src/sys/i386/i386/trap.c:490
>> >
>> > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
>> > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c)
>> >
>> > at /usr/src/sys/kern/vfs_bio.c:1530
>> >
>> > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Va
Re: kernel panic
On Tuesday 12 August 2008 02:23:30 pm Johan Kuuse wrote:
> > On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote:
> >> On Monday 11 August 2008 23:04:30 John Baldwin wrote:
> >> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote:
> >> > > Hi,
> >> > >
> >> > > I am a kgdb newbie, so please be patient.
> >> > > I suspect (just based on the fact that this is the 4th time I edit
text
> >> >
> >> > files on my NTFS partition through ntfs-3g, using Emacs, and getting
> >> > frequent I/O error messages inside Emacs, and then a kernel panic) that
> >> > this is a ntfs-3g related problem.
> >> >
> >> > > If you ask me exactly how to reproduce it, I sorry, I can tell you
> >> > > exactly
> >> >
> >> > (but see the kgdb output below).
> >> >
> >> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530
> >> > >
> >> > > Just a suggestion for a patch (without knowing the functionality
> >> >
> >> > of /usr/src/sys/kern/vfs_bio.c):
> >> > > The line where the kernel panics:
> >> > > /usr/src/sys/kern/vfs_bio.c:
> >> > > --
> >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
> >> > > ...
> >> > > --
> >> > >
> >> > > Comparing to another file, which does error checking before calling
> >> >
> >> > VM_OBJECT_LOCK:
> >> > > /usr/src/sys/kern/vfs_aio.c:
> >> > > --
> >> > > if (vp->v_object != NULL) {
> >> > > VM_OBJECT_LOCK(vp->v_object);
> >> > > ...
> >> > > --
> >> > >
> >> > > Perhaps the kernel panic could be avoided with the following patch?
> >> > > /usr/src/sys/kern/vfs_bio.c (suggested patch):
> >> > > --
> >> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) {
> >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
> >> > > ...
> >> > > --
> >> > >
> >> > > Please let me know if you need more information.
> >> > >
> >> > > Regards,
> >> > > Johan Kuuse
> >> > >
> >> >
> ---
> >> > > kgdb kernel.debug
> >> > > /var/crash/vmcore.1
> >> > > [GDB will not be able to debug user-mode threads:
> >> > > /usr/lib/libthread_db.so:
> >> >
> >> > Undefined symbol "ps_pglobal_lookup"]
> >> >
> >> > > GNU gdb 6.1.1 [FreeBSD]
> >> > > Copyright 2004 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-marcel-freebsd".
> >> > >
> >> > > Unread portion of the kernel message buffer:
> >> > >
> >> > >
> >> > > Fatal trap 12: page fault while in kernel mode
> >> > > cpuid = 0; apic id = 00
> >> > > fault virtual address = 0x34
> >> > > fault code = supervisor read, page not present
> >> > > instruction pointer = 0x20:0xc07b6de4
> >> > > stack pointer = 0x28:0xe79de7c8
> >> > > frame pointer = 0x28:0xe79de7e8
> >> > > 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 = 1214 (opera)
> >> > > trap number = 12
> >> > > panic: page fault
> >> > > cpuid = 0
> >> > > Uptime: 5h20m30s
> >> > > Physical memory: 2035 MB
> >> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11
> >> > >
> >> > > #0 doadump () at pcpu.h:195
> >> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> >> > > (kgdb) list *0xc07b6de4
> >> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530).
> >> > > 1525vfs_vmio_release(struct buf *bp)
> >> > > 1526{
> >> > > 1527int i;
> >> > > 1528vm_page_t m;
> >> > > 1529
> >> > > 1530VM_OBJECT_LOCK(bp->b_bufobj->bo_object);
> >> > > 1531vm_page_lock_queues();
> >> > > 1532for (i = 0; i < bp->b_npages; i++) {
> >> > > 1533m = bp->b_pages[i];
> >> > > 1534bp->b_pages[i] = NULL;
> >> > > (kgdb) bt
> >> > > #0 doadump () at pcpu.h:195
> >> > > #1 0xc0754457 in boot (howto=260) at
> >> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic
> >> > > (fmt=Variable "fmt" is not available.
> >> > > ) at /usr/src/sys/kern/kern_shutdown.c:563
> >> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52)
> >> >
> >> > at /usr/src/sys/i386/i386/trap.c:899
> >> >
> >> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52)
> >> >
> >> > at /usr/src/sys/i386/i386/trap.c:812
> >> >
> >> > > #5 0xc0a49c8c in trap (frame=0xe79de788)
> >
Re: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+
On Tue, Aug 12, 2008 at 1:04 AM, Daniel O'Connor <[EMAIL PROTECTED]> wrote: > Hi, > I have a 6.3 (RELENG_6 a bit past 6.3 actually) system which hangs when > I try and reboot (or shutdown). It has a Supermicro C2SBA+, 2ware > 9650SE and Core2Duo CPU. > > It shuts down as normal except after printing the uptime it hangs solid. > Numlock does nothing (during the shutdown process & disk sync it > toggles OK). The disks are synced OK (comes up clean when I press the > reset switch) > > Waiting (max 60 seconds) for system process 'vnlru' to stop...done > Waiting (max 60 seconds) for system process 'bufdaemon' to stop...done > Waiting (max 60 seconds) for system process 'syncer' to stop... > Syncing disks, vnodes remaining...6 5 2 3 0 1 0 0 0 done > All buffers ynced. > Swap device da0s1b removed. > Uptime: 1m52s > > > I have tried setting hw.acpi.disable_on_reboot and hw.acpi.handle_reboot > to no effect. > > I have attached a verbose dmesg. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C can you try with debug.acpi.disabled="cpu timer" ? or booting with acpi disabled -Manjunath ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: command not found: problem with dash in filenames
On Tue, Aug 12, 2008 at 10:00:02PM +0400, KES wrote: > NOTICE: > when I run purepw it is located and runned, but > when I run pure-pw (NOTICE: dash in name) I get: Command not found Did you by any chance just install this binary? Have you tried running 'rehash' and trying again? Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgpIZPuvaqK8t.pgp Description: PGP signature
Re: Hardware monitoring for Intel Atom D945GCLF.
Jeremy Chadwick pisze: On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: I don't need an API, but this kind of statement makes Intel sound like they're not willing to disclose the SMBus offsets for monitoring. I might have to look at lm-sensors from Linux, but that code is very difficult to follow. I'm not sure if Intel gives this sort of information out publicly, but I sure hope so. There's a web page mentioning this board (note: entirely Japanese) -- http://iktaka.dyndns.org/node/11 The bottom part of the page states that Linux's lm_sensors 3.0.2 can successfully monitor temperatures, voltages, and fan RPMs on that board, very likely via SMBus. Ideally I should be able to track down technical details by looking at that code. I'd feel much more comfortable asking Intel and having them provide necessary registers and offsets, though; I prefer to avoid reverse-engineering things if possible (less mistakes). Thanks for the reply. Looks like there is no tool for FreeBSD which supports ICH7 currently. mbmon has support for ICH6, but I'm not sure is it still alive. What about your project, are you planing to release it to the public in nearest future? Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ ebutusov(at)gmail(dot)com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hardware monitoring for Intel Atom D945GCLF.
On Tue, Aug 12, 2008 at 10:38:11PM +0200, Eugene Butusov wrote: > Jeremy Chadwick pisze: >> On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: >>> I don't need an API, but this kind of statement makes Intel sound like >>> they're not willing to disclose the SMBus offsets for monitoring. I >>> might have to look at lm-sensors from Linux, but that code is very >>> difficult to follow. I'm not sure if Intel gives this sort of >>> information out publicly, but I sure hope so. >> >> There's a web page mentioning this board (note: entirely Japanese) -- >> >> http://iktaka.dyndns.org/node/11 >> >> The bottom part of the page states that Linux's lm_sensors 3.0.2 can >> successfully monitor temperatures, voltages, and fan RPMs on that board, >> very likely via SMBus. >> >> Ideally I should be able to track down technical details by looking at >> that code. I'd feel much more comfortable asking Intel and having them >> provide necessary registers and offsets, though; I prefer to avoid >> reverse-engineering things if possible (less mistakes). >> > > Thanks for the reply. Looks like there is no tool for FreeBSD which > supports ICH7 currently. mbmon has support for ICH6, but I'm not sure is > it still alive. You have to understand, it's hard for a program to say it "supports a chipset" unless that specific chipset is doing the H/W monitoring. For example, lots of Supermicro boards use Winbond H/W monitoring ICs, but you can interface with the chip via SMBus. The chipsets on those boards are Intel ICHx (ICH7 through 9), but the ICHx doesn't do the monitoring. I'm not sure the ICHx chips can actually do monitoring natively; I haven't looked at the specifications. If they do, that may be what mbmon is talking about -- otherwise, it might just be a vague description that more or less says "works with Intel ICHx chipsets that support SMBus". Hard to explain really... > What about your project, are you planing to release it to the public > in nearest future? Once I get a couple more Supermicro boards added, yep. The code is rock solid at this point in time[1], but there's still a lot to be done before I consider it worthy of public release. Remaining items on my TODO list for bsdhwmon: * Poke individuals testing software for further updates (many have been quiet since the last tarball) * Write manpage * Update README, and INSTALL (if necessary) * Update Makefile to be FreeBSD ports-friendly, and general cleanup * Make a FreeBSD port for the software These are things I myself have to do. I'm sorry I don't have an ETR for you -- I really wish I did. [1]: No crashes/segfaults, and compiles cleanly with -Werror -Wall -Wunused -Waggregate-return -Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wdisabled-optimization -Wfloat-equal -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wunreachable-code -Wwrite-strings I'm one of those "warnings should be taken seriously" individuals. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: Re: command not found: problem with dash in filenames
- Forwarded message from KES <[EMAIL PROTECTED]> - > From: KES <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Tue, 12 Aug 2008 23:40:08 +0400 > Subject: Re: command not found: problem with dash in filenames > > > > 12.08.08, 22:25, "Jeremy Chadwick" <[EMAIL PROTECTED]>: > > > On Tue, Aug 12, 2008 at 10:00:02PM +0400, KES wrote: > > > NOTICE: > > > when I run purepw it is located and runned, but > > > when I run pure-pw (NOTICE: dash in name) I get: Command not found > > > kes# env |grep PATH > > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > > kes# env | grep PATH > > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > > kes# ls -l /usr/local/bin/pure* > > > -r-xr-xr-x 1 root wheel 24052 12 ??? 06:24 /usr/local/bin/pure-pw > > > -r-xr-xr-x 1 root wheel 4432 12 ??? 06:24 > > > /usr/local/bin/pure-pwconvert > > > -r-xr-xr-x 1 root wheel 6016 12 ??? 06:24 > > > /usr/local/bin/pure-statsdecode > > > kes# pure-pw > > > pure-pw: Command not found > > > kes# /usr/local/bin/pure-pw > > > > > > Usage : > > > > > > pure-pw useradd [-f ] -u [-g ] > > > -D/-d [-c ] > > > [-t ] [-T ] > > > . > > > kes# cp pure-pw purepw > > > kes# purepw > > > > > > Usage : > > > > > > pure-pw useradd [-f ] -u [-g ] > > > -D/-d [-c ] > > > [-t ] [-T ] > > > > > Looks like you're using csh/tcsh. Try using "rehash" and see if it > > fixes the problem for you. > > thank you very mach > problem was resolved > - End forwarded message - Individual replied to me off-list; "refresh" was indeed the answer. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall compilation issue
--- On Tue, 8/12/08, Unga <[EMAIL PROTECTED]> wrote:
> From: Unga <[EMAIL PROTECTED]>
> Subject: Re: sysinstall compilation issue
> To: freebsd-stable@FreeBSD.ORG
> Cc: [EMAIL PROTECTED]
> Date: Tuesday, August 12, 2008, 3:28 PM
> --- On Fri, 8/8/08, Oliver Fromme
> <[EMAIL PROTECTED]> wrote:
>
> > From: Oliver Fromme <[EMAIL PROTECTED]>
> > Subject: Re: sysinstall compilation issue
> > To: freebsd-stable@FreeBSD.ORG, [EMAIL PROTECTED]
> > Date: Friday, August 8, 2008, 9:36 PM
> > Unga <[EMAIL PROTECTED]> wrote:
> > > This is i386 RELENG_7.
> > >
> > > Following section of the
> > /usr/src/usr.sbin/sysinstall/Makefile does not
> generate C
> > code properly:
> > >
> > > makedevs.c: Makefile rtermcap
> > > echo '#include
> '
> > > makedevs.c
> > > ${RTERMCAP} ansi | \
> > > file2c 'const char
> termcap_ansi[]
> > = {' ',0};' \
> > > > > makedevs.c
> > >
> > > At compile time, above expands to:
> > >
> >
> TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src
> > ./rtermcap ansi | file2c 'const char
> termcap_ansi[] =
> > {' ',0};' >> makedevs.c
> > >
> > > Which generates C code as follows:
> > > const char termcap_ansi[] = {
> > >
> > > ,0};
> > >
> > > That is, it generates 3 lines, which results a
> > compilation error.
> > >
> > > I presume, intended generated code should be:
> > > const char termcap_ansi[] = {' ',0};
> > >
> > > Am I right?
> >
> > No, it should generate an array containung a dump of
> > the "ansi" termcap entry. Please see the
> > file2c(1)
> > manpage.
> >
> > > What is wrong at my end?
> > >
> > > Note, I linked the rtermcap with ncursesw
> libraries,
> > can that be the cause? Any ideas?
> >
> > Yes, that's the cause. Why did you do that?
> >
> > FreeBSD's ncurses port contains a patch so the
> > tgetent()
> > function (which is used by rtermcap) returns the
> actual
> > termcap entry in the buffer. The original ncurses
> code
> > (which is terminfo based) doesn't do that.
> >
> > When you linked rtermcap with the wrong library, you
> > restored the original behaviour of tgetent(), so the
> > output of rtermcap was empty, so file2c produced
> invalid
> > source.
> >
>
> Sorry for my late reply on this. I was not well during
> weekend, an eye ache due to over work :(
>
> Here is the situation at my end, no matter whether I link
> with ncurses widec libs or non-widec libs, its still return
> the same code as above I mentioned.
>
> Possible causes can be:
> 1. The way I compile and install ncurses is not correct.
> 2. OR some essential files required are missing
> 3. OR there can be an other option
>
> I used truss as follows:
> TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src
> truss -o truss.log -f ./rtermcap ansi | file2c 'const
> char termcap_ansi[] = {' ',0};' >>
> makedevs.c
>
> The last few lines of truss.log shows:
> 9310:
> stat("/usr/share/misc/terminfo.db",{mode=-rw-r--r--
> ,inode=22613331,size=
> 3170304,blksize=4096}) = 0 (0x0)
> 9310:
> open("/usr/share/misc/terminfo.db",O_RDONLY,0644)
> = 4 (0x4)
> 9310: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0)
> 9310:
> read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260)
> = 260 (0x104)
> 9310:
> __sysctl(0xbfbfd574,0x2,0xbfbfd570,0xbfbfd57c,0x0,0x0) = 0
> (0x0)
> 9310: lseek(4,0x132000,SEEK_SET)= 1253376
> (0x132000)
> 9310:
> read(4,"\^^\0\M-|\^O\M-T\^O\M-K\^O\M-*"...,4096)
> = 4096 (0x1000)
> 9310: lseek(4,0x26b000,SEEK_SET)= 2535424
> (0x26b000)
> 9310:
> read(4,"\n\0\M-Y\^O\^O\n\0\n\r\^D\^E\^D"...,4096)
> = 4096 (0x1000)
> 9310: close(4) = 0 (0x0)
> 9310: ioctl(2,TIOCGETA,0xbfbfdba4) = 0 (0x0)
> 9310: ioctl(2,TIOCGETA,0x81020d8) = 0 (0x0)
> 9310: ioctl(2,TIOCGETA,0xbfbfdb64) = 0 (0x0)
> 9310: ioctl(2,TIOCGWINSZ,0xbfbfdbc4)= 0 (0x0)
> 9310: fstat(1,{mode=p-
> ,inode=0,size=0,blksize=4096}) = 0 (0x0)
> 9310: process exit, rval = 0
>
> Note, above log has no entry to open
> /usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src.
>
> So what can be the issue, ncurses has not been patched
> correctly or some essential files missing? If you guys think
> that ncurses has not been patched correctly, then I'll
> open another thread to discuss that.
>
There is another update. I have tested it with ncurses and ncurses-devel ports.
It seems they don't work as the ncurses in the base system.
The test is as follows:
cc -o rtermcap /usr/src/usr.sbin/sysinstall/rtermcap.c
/usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib/libncurses.so.5.6
/usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib/libtinfo.so.5.6
export
LD_LIBRARY_PATH=/usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib
cp -v mypath/terminfo.db /usr/local/share/misc/
TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap
ansi | file2c 'const char
