Re: Browsing over IPv6
Me <--ethernet, MTU1500, native IPv6--> mattapan <-| | World <-- v6 in v4 tunnel, gif0, MTU1280---| (mattapan is my FreeBSD 8.2-STABLE router, "Me" is running 9.0-STABLE.) If I run "route change -inet6 :: -mtu 1280" on "Me," everything starts working again. Should this be necessary?-- George ICMP6 control packets aren't blocked? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Browsing over IPv6
On 07/10/12 21:53, George Mitchell wrote: On 07/02/12 16:29, Doug Barton wrote: On 07/02/2012 04:12, George Mitchell wrote: I've been using IPv6 for quite a few years without problems and I've had no difficulty browsing Many more sites are actually putting, or have put, IPv6 into production since the latest world IPv6 day last month. Some growing pains are inevitable. Doug This problem may be here in FreeBSD. Here's my setup: Me <--ethernet, MTU1500, native IPv6--> mattapan <-| | World <-- v6 in v4 tunnel, gif0, MTU1280---| (mattapan is my FreeBSD 8.2-STABLE router, "Me" is running 9.0-STABLE.) If I run "route change -inet6 :: -mtu 1280" on "Me," everything starts working again. Should this be necessary?-- George It turns out I can change /etc/rc.conf from: ipv6_defaultrouter="2001:418:3fd::fd" to: ipv6_defaultrouter="2001:418:3fd::fd -mtu 1280" and "fix" the problem.-- George ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Browsing over IPv6
On 07/02/12 16:29, Doug Barton wrote: On 07/02/2012 04:12, George Mitchell wrote: I've been using IPv6 for quite a few years without problems and I've had no difficulty browsing Many more sites are actually putting, or have put, IPv6 into production since the latest world IPv6 day last month. Some growing pains are inevitable. Doug This problem may be here in FreeBSD. Here's my setup: Me <--ethernet, MTU1500, native IPv6--> mattapan <-| | World <-- v6 in v4 tunnel, gif0, MTU1280---| (mattapan is my FreeBSD 8.2-STABLE router, "Me" is running 9.0-STABLE.) If I run "route change -inet6 :: -mtu 1280" on "Me," everything starts working again. Should this be necessary?-- George ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtraceall.ko with old nfsclient
on 10/07/2012 21:57 Fabian Keil said the following: > I do not use a completely NFS-free kernel, but I don't build any > NFS-related modules. Trying to load an unpatched dtraceall results in: > > Jul 9 21:58:48 r500 sudo: fk : TTY=pts/16 ; PWD=/home/fk ; USER=root > ; COMMAND=/sbin/kldload dtraceall Jul 9 21:58:48 r500 kernel: [8922] KLD > dtnfsclient.ko: depends on oldnfs - not available or version mismatch Jul > 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type Jul > 9 21:58:48 r500 kernel: [8922] KLD dtraceall.ko: depends on dtnfsclient - > not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] > linker_load_file: Unsupported file type > > My assumption was that your patch and the "#elif defined (NFSCLIENT)" would > fix that, and indeed it does, but I later on realized that I actually do > have NFSCL in the kernel: > > fk@r500 /usr/src $sysctl kern.conftxt | grep NFS options NFS_ROOT options > NFSLOCKD options NFSD options NFSCL > > My impression is that the patch is missing an opt_nfs.h inclusion combined > with the Makefile voodoo to create the file. > > The dtraceall module already has an opt_compat.h, even though the Makefile > logic to create it seems a bit dubious to me. It blindly assumes that > COMPAT_FREEBSD32 is available on amd64. Not sure if I got correctly what the (perceived) problem actually is, but I have this to say: the proper way of building a module is either via buildkernel (MODULES_OVERRIDE, etc) or by using KERNBUILDDIR for "independent" module build if the module has any dependency on kernel options in effect. This could be a little bit sad (for third-party module providers), but this seems to be true. Sometimes Makefile-s fake kernel options for truly independent module build (no KERNBUILDDIR) to provide the widest and/or safest feature set. But this has to be done very carefully to ensure that module<->kernel*s* compatibility actually occurs. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtraceall.ko with old nfsclient
Sean Bruno wrote: > On Tue, 2012-07-10 at 06:41 -0700, Fabian Keil wrote: > > > > > > --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > > 2011-11-02 23:46:55.0 > > > > > > +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > > 2011-11-02 23:46:55.0 > > > > @@ -66,8 +66,11 @@ > > > > MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > > > > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > > > > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > > > > +#if defined (NFSCL) > > > > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > > > > +#else /* defined (NFSCLIENT) */ > > > > Any objections to changing this to > > #elif defined (NFSCLIENT) > > ? > > No objections here. I suspect that this is the more correct thing > regardless. I mean, it keeps the nfs dtrace objects loading in the > event someone is running a non-nfs kernel... right? I do not use a completely NFS-free kernel, but I don't build any NFS-related modules. Trying to load an unpatched dtraceall results in: Jul 9 21:58:48 r500 sudo: fk : TTY=pts/16 ; PWD=/home/fk ; USER=root ; COMMAND=/sbin/kldload dtraceall Jul 9 21:58:48 r500 kernel: [8922] KLD dtnfsclient.ko: depends on oldnfs - not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type Jul 9 21:58:48 r500 kernel: [8922] KLD dtraceall.ko: depends on dtnfsclient - not available or version mismatch Jul 9 21:58:48 r500 kernel: [8922] linker_load_file: Unsupported file type My assumption was that your patch and the "#elif defined (NFSCLIENT)" would fix that, and indeed it does, but I later on realized that I actually do have NFSCL in the kernel: fk@r500 /usr/src $sysctl kern.conftxt | grep NFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL My impression is that the patch is missing an opt_nfs.h inclusion combined with the Makefile voodoo to create the file. The dtraceall module already has an opt_compat.h, even though the Makefile logic to create it seems a bit dubious to me. It blindly assumes that COMPAT_FREEBSD32 is available on amd64. Fabian signature.asc Description: PGP signature
Re: kernel: abra-kadabra
interspersed. in kernel config Increasing that value [to 1k, 2k, etc] will help at the cost of changed to 4K thanks some more memory usage, but it won't fix the problem. The issue should be less prominent in 9.x+. HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel: abra-kadabra
Regarding your HTTPd dying, I've also experienced signal 11 quits when I was using apache and PHP as a module. yes they are rare and just apache serving process dies, not master process. All works fine but i am concerned about security... Oh well i wasn't the one that chose PHP, it is needed to run already written program... And any error would not hit any more than WWW server, but still i am quite concerned ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtraceall.ko with old nfsclient
On Tue, 2012-07-10 at 06:41 -0700, Fabian Keil wrote: > > > > --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > 2011-11-02 23:46:55.0 > > > > +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > > 2011-11-02 23:46:55.0 > > > @@ -66,8 +66,11 @@ > > > MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > > > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > > > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > > > +#if defined (NFSCL) > > > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > > > +#else /* defined (NFSCLIENT) */ > > Any objections to changing this to > #elif defined (NFSCLIENT) > ? No objections here. I suspect that this is the more correct thing regardless. I mean, it keeps the nfs dtrace objects loading in the event someone is running a non-nfs kernel... right? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound
On 7/10/2012 4:27 AM, Mark Blackman wrote: > On 10 Jul 2012, at 08:12, Doug Barton wrote: > >> On 07/09/2012 14:47, Mark Blackman wrote: >>> I never use '-t' with dig. drill *told* me I should use '-t' >>> then completely failed to acknowledge I had done so. >> >> Have you reported this bug? > > Nope, you? I'm not the one bothered by it. :) -- Change is hard. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel: abra-kadabra
On Tue, Jul 10, 2012 at 7:36 AM, Wojciech Puchar wrote: > > > On Tue, 10 Jul 2012, Damien Fleuriot wrote: > >> >> On 10 Jul 2012, at 12:10, Wojciech Puchar >> wrote: >> >>> this is what i've got from kernel (same visible after dmesg of course) >>> >>> >>> Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 >>> ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die >>> txoiedtn eo dn sosini ggnsnaalilg n1a1l >>> Jul 9 08:56:53 .. kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> Jul 9 08:56:53 ... kernel: <<66>>11 >>> Jul 9 08:56:53 ... kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> >>> everything before and after seems usual. >>> >>> when reading every second letter it SEEMS to make more sense but still >>> not much. >>> >>> What it is? >>> >> >> You're seeing several messages at jumbled together, or your message and >> other parts of the buffer. >> >> Either way, you can see the word "signal" there ;) >> > i think it was httpd (probably PHP trash) crashed with sig11 but want to be > sure. > > httpd rarely do crash... Strange i have ports rather up to date and no KNOWN > vulnerabilities are according to portaudit output. > > how can i prevent mixing kernel messages? > > i have > > options PRINTF_BUFR_SIZE=256# Prevent printf output being > interspersed. > > in kernel config Increasing that value [to 1k, 2k, etc] will help at the cost of some more memory usage, but it won't fix the problem. The issue should be less prominent in 9.x+. HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
On Tue, Jul 10, 2012 at 06:02:50PM +0300, Volodymyr Kostyrko wrote:
> Konstantin Belousov wrote:
> >>So you mean this is just my false assumption that EOF _should_ occur on
> >>stdin? And it actually occurs only if source is a process which can send
> >>EOF?
> >
> >'Source' cannot be a process. Read filter on pipes can return EV_EOF.
> >Read filter on vnodes (read: regular files) does not return EV_EOF,
> >except in situation that is created by manual intervention of
> >administrator.
>
> This keeps me puzzled. How then I can tell that file at stdin is already
> at EOF? You mean I should treat stdin like normal vnode-backed file?
>
> off_t pos = 0, endpos;
>
> lseek(fileno(stdin), 0, SEEK_END);
> endpos = ftell(stdin);
> lseek(fileno(stdin), 0, SEEK_SET);
>
> ... and then later check it with:
>
> if(endpos != -1) {
> pos += kev.data;
> if(pos >= endpos) {
> printf("end reached\n");
> return(0);
> }
> }
>
> Is this a correct way to detect EOF? I'm letting besides that I should
> also detect vnode changes and update max file size accordingly.
>
> >It should have been clear from my previous response.
>
> Please excuse me, I'm a bit new to this things...
Why do you use kqueue there at all ? Just read from stdin, and decide
that you hit EOF when read returned 0 bytes.
If insisting on using kqueue, which may be ligitimate if you process
other sources besides stdin, you should first investigate the nature of
the fd 0 using fstat, and then use appropriate code for regular file,
pipe and probably socket (e.g. for the case if code allows to run under
inetd(8)).
pgpWnxHYAl6uD.pgp
Description: PGP signature
Re: kernel: abra-kadabra
On 7/10/12 4:36 PM, Wojciech Puchar wrote: > > > On Tue, 10 Jul 2012, Damien Fleuriot wrote: > >> >> On 10 Jul 2012, at 12:10, Wojciech Puchar >> wrote: >> >>> this is what i've got from kernel (same visible after dmesg of course) >>> >>> >>> Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 >>> ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex >>> die txoiedtn eo dn sosini ggnsnaalilg n1a1l >>> Jul 9 08:56:53 .. kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> Jul 9 08:56:53 ... kernel: <<66>>11 >>> Jul 9 08:56:53 ... kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> >>> everything before and after seems usual. >>> >>> when reading every second letter it SEEMS to make more sense but >>> still not much. >>> >>> What it is? >>> >> >> You're seeing several messages at jumbled together, or your message >> and other parts of the buffer. >> >> Either way, you can see the word "signal" there ;) >> > i think it was httpd (probably PHP trash) crashed with sig11 but want to > be sure. > > httpd rarely do crash... Strange i have ports rather up to date and no > KNOWN vulnerabilities are according to portaudit output. > > how can i prevent mixing kernel messages? > > i have > > options PRINTF_BUFR_SIZE=256# Prevent printf output being > interspersed. > > in kernel config Regarding the mixing of kernel messages I'm afraid I won't be able to help with that. Regarding your HTTPd dying, I've also experienced signal 11 quits when I was using apache and PHP as a module. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kqueue timer timeout period
Hi, I have a question about the kqueue timer timeout period ... what's data supposed to be? I thought it was supposed to be the period in milliseconds, but I seem to off by one. For example, if I set date (the timeout period) to 20 milliseconds, I often wait 21 milliseconds which is very undesirable for my application. -- Paul Albrecht ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
Konstantin Belousov wrote:
So you mean this is just my false assumption that EOF _should_ occur on
stdin? And it actually occurs only if source is a process which can send
EOF?
'Source' cannot be a process. Read filter on pipes can return EV_EOF.
Read filter on vnodes (read: regular files) does not return EV_EOF,
except in situation that is created by manual intervention of
administrator.
This keeps me puzzled. How then I can tell that file at stdin is already
at EOF? You mean I should treat stdin like normal vnode-backed file?
off_t pos = 0, endpos;
lseek(fileno(stdin), 0, SEEK_END);
endpos = ftell(stdin);
lseek(fileno(stdin), 0, SEEK_SET);
... and then later check it with:
if(endpos != -1) {
pos += kev.data;
if(pos >= endpos) {
printf("end reached\n");
return(0);
}
}
Is this a correct way to detect EOF? I'm letting besides that I should
also detect vnode changes and update max file size accordingly.
It should have been clear from my previous response.
Please excuse me, I'm a bit new to this things...
--
Sphinx of black quartz judge my vow.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Clang, EFI and bad offsets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In the process of the EFI on intel work, I ran across a strange issue. The procedure for creating loader.efi goes something like this: 1) compile to ELF object files 2) generate an ELF executable with -Bsymbolic and a custom linker script that puts everything starting at 0x1000, and also appends some kind of data to the end of symbols (you can find this in sys/boot/i386/efi) 3) use objcopy to convert to PE format (BFD is ia32-efi-app) However, using clang for any of this seems to result in bad jump offsets being generated, which will cause the resulting program to fail. I haven't done a thorough investigation of the issues yet, but I wanted to bring it up to see if anyone has seen something similar, or has any insights. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJP/AsiAAoJENSCzbQ+koZ72N8QAL8zA/0MaHXkLpwTlNiEOZ5m a+73QS2O/uVw/Tsfge/yEcrJdXjGT0YmfmvTEKQPVSmMiZRf8KbG4FQYBKgWTHlO I/Thkw2JRj0iJOlhgp7VyOFpcLHyEdWDsst1D4Y5332j9dEa+JkIqtVTjwefSBbY OcoRkQ9Zznu3vF98BKmn1JTxdKASPMrELs5HMQ3GZop6/FMV8+SBdTFst/gvO1Wg Loe6S2IDMkcaXGYNSBrdqjkJY06wg2oSivlb44/DsSRzQSfKTkSBZ2i3r+LIUv13 cu0XFejjLd2mSPUkSgPGMwTu+PuScGY8Xe8kskJPl+F9NFzxeEdCUbYbpv8HoTJG 3xCXSun5CbkPwfSIfprUS59mAN7sBqWIOzeI5HDeboZv0WL1+7PfUJB27nAINg/D 3MocooMAZHrqsCADlsdgKrodvGp0ccG0vwrfsajho+/69JhNzRbOgllGp2Meqwfy npVBToxVrs7LtcYXkBsyshN3I9GBIjjtR+Ryn5KLCG7xJTvLP0XuYrn4XcNNXjBI ewMRCgUgdlhoS1vPItnmDkYPiIrb5SgowJSZ6Nzd/es7pTdLzRKYXkWzlTNwqY3z TtJLhzebrjfHDArvL2kHvIempyGda+ED4k4W0Ubr8Owzd1WJhRGEhgwVAeJ0hFnO CJOy14wJK32mVr2KFEjG =y2ee -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel: abra-kadabra
On Tue, 10 Jul 2012, Damien Fleuriot wrote: On 10 Jul 2012, at 12:10, Wojciech Puchar wrote: this is what i've got from kernel (same visible after dmesg of course) Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die txoiedtn eo dn sosini ggnsnaalilg n1a1l Jul 9 08:56:53 .. kernel: 1 Jul 9 08:56:53 ... kernel: Jul 9 08:56:53 ... kernel: <<66>>11 Jul 9 08:56:53 ... kernel: 1 Jul 9 08:56:53 ... kernel: everything before and after seems usual. when reading every second letter it SEEMS to make more sense but still not much. What it is? You're seeing several messages at jumbled together, or your message and other parts of the buffer. Either way, you can see the word "signal" there ;) i think it was httpd (probably PHP trash) crashed with sig11 but want to be sure. httpd rarely do crash... Strange i have ports rather up to date and no KNOWN vulnerabilities are according to portaudit output. how can i prevent mixing kernel messages? i have options PRINTF_BUFR_SIZE=256# Prevent printf output being interspersed. in kernel config ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
On Tue, Jul 10, 2012 at 05:19:05PM +0300, Volodymyr Kostyrko wrote:
> Konstantin Belousov wrote:
> >>This PR is rather old. I just had submitted new test case, now in plain c.
> >>
> >>It doesn't work exactly like python version, but the result is the same:
> >>
> >>>clang test.c
> >>>cat test.c | ./a.out
> >>-1 916 0 0 0
> >>-1 0 32768 0 0
> >>>./a.out< test.c
> >>-1 916 0 0 0
> >><- and here we have a complete hang in [kqread].
> >
> >And what is your expectation ?
> >
> >The vnode filter never returns EOF when current file position at the end
> >of file. It is documented that read filter returns when file offset if not
> >at the end of file, thats all. In fact, EV_EOF is returned on forced
> >unmount.
> >I do not see a bug in kqueue.
> >
> >On the other hand, your C code has at least two things that I cannot
> >understand. First, EV_EOF is output flag, it makes absolutely no sense
> >to set it in command.Second, it is mistery for me what do you check with
> > if (kev.flags>> 15 == 1) {
> >test.
>
> EV_EOF on line 19 actually slipped by my fault, original source omits
> that one. It doesn't change anything.
Yes.
>
> EV_EOF = 1 << 15 = 32768. And it _is_ returned when file is feed with
> the pipe.
>
> So you mean this is just my false assumption that EOF _should_ occur on
> stdin? And it actually occurs only if source is a process which can send
> EOF?
'Source' cannot be a process. Read filter on pipes can return EV_EOF.
Read filter on vnodes (read: regular files) does not return EV_EOF,
except in situation that is created by manual intervention of
administrator.
It should have been clear from my previous response.
pgpyDIRkWE4ZD.pgp
Description: PGP signature
Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
Konstantin Belousov wrote:
This PR is rather old. I just had submitted new test case, now in plain c.
It doesn't work exactly like python version, but the result is the same:
clang test.c
cat test.c | ./a.out
-1 916 0 0 0
-1 0 32768 0 0
./a.out< test.c
-1 916 0 0 0
<- and here we have a complete hang in [kqread].
And what is your expectation ?
The vnode filter never returns EOF when current file position at the end
of file. It is documented that read filter returns when file offset if not
at the end of file, thats all. In fact, EV_EOF is returned on forced unmount.
I do not see a bug in kqueue.
On the other hand, your C code has at least two things that I cannot
understand. First, EV_EOF is output flag, it makes absolutely no sense
to set it in command.Second, it is mistery for me what do you check with
if (kev.flags>> 15 == 1) {
test.
EV_EOF on line 19 actually slipped by my fault, original source omits
that one. It doesn't change anything.
EV_EOF = 1 << 15 = 32768. And it _is_ returned when file is feed with
the pipe.
So you mean this is just my false assumption that EOF _should_ occur on
stdin? And it actually occurs only if source is a process which can send
EOF?
--
Sphinx of black quartz judge my vow.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
On Tue, Jul 10, 2012 at 03:16:45PM +0300, Volodymyr Kostyrko wrote:
> Hi all.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149857
>
> This PR is rather old. I just had submitted new test case, now in plain c.
>
> It doesn't work exactly like python version, but the result is the same:
>
> > clang test.c
> > cat test.c | ./a.out
> -1 916 0 0 0
> -1 0 32768 0 0
> > ./a.out < test.c
> -1 916 0 0 0
> <- and here we have a complete hang in [kqread].
And what is your expectation ?
The vnode filter never returns EOF when current file position at the end
of file. It is documented that read filter returns when file offset if not
at the end of file, thats all. In fact, EV_EOF is returned on forced unmount.
I do not see a bug in kqueue.
On the other hand, your C code has at least two things that I cannot
understand. First, EV_EOF is output flag, it makes absolutely no sense
to set it in command. Second, it is mistery for me what do you check with
if (kev.flags >> 15 == 1) {
test.
pgpaBMYJ8WkYS.pgp
Description: PGP signature
Re: dtraceall.ko with old nfsclient
Andriy Gapon wrote: > on 09/07/2012 22:49 Sean Bruno said the following: > > Ran into some symbol errors with the dtraceall module when using the > > *old* nfs client. > > > > I think that this is more or less the right thing to do, but I'm not > > sure. > > > > --- //depot/yahoo/ybsd_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > 2011-11-02 23:46:55.0 > > +++ /home/seanbru/dtrace_9/src/sys/modules/dtrace/dtraceall/dtraceall.c > > 2011-11-02 23:46:55.0 > > @@ -66,8 +66,11 @@ > > MODULE_DEPEND(dtraceall, opensolaris, 1, 1, 1); > > MODULE_DEPEND(dtraceall, dtrace, 1, 1, 1); > > MODULE_DEPEND(dtraceall, dtmalloc, 1, 1, 1); > > +#if defined (NFSCL) > > MODULE_DEPEND(dtraceall, dtnfscl, 1, 1, 1); > > +#else /* defined (NFSCLIENT) */ Any objections to changing this to #elif defined (NFSCLIENT) ? > > MODULE_DEPEND(dtraceall, dtnfsclient, 1, 1, 1); > > +#endif > > #if defined(__amd64__) || defined(__i386__) > > MODULE_DEPEND(dtraceall, fbt, 1, 1, 1); > > MODULE_DEPEND(dtraceall, fasttrap, 1, 1, 1); > > Just to add some noise to the signal - my personal opinion is that nfs support > doesn't have to be in dtraceall. Maybe in something "all-er" :-) I have no opinion on whether or not dtraceall should depend on nfs modules if they are available, but I would prefer it if the dependency was optional. I do not use any nfs modules and the hard-coded dependency made dtraceall useless for me in the past. Unlike Sean I worked around it with a shell function and was too lazy to investigate the cause, though. Fabian signature.asc Description: PGP signature
Re: kernel: abra-kadabra
On 10 Jul 2012, at 12:10, Wojciech Puchar wrote: > this is what i've got from kernel (same visible after dmesg of course) > > > Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 ((hh6ttt6p2d4 > )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die txoiedtn eo dn > sosini ggnsnaalilg n1a1l > Jul 9 08:56:53 .. kernel: 1 > Jul 9 08:56:53 ... kernel: > Jul 9 08:56:53 ... kernel: <<66>>11 > Jul 9 08:56:53 ... kernel: 1 > Jul 9 08:56:53 ... kernel: > > everything before and after seems usual. > > when reading every second letter it SEEMS to make more sense but still not > much. > > What it is? > You're seeing several messages at jumbled together, or your message and other parts of the buffer. Either way, you can see the word "signal" there ;)___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kern/149857: [kqueue] kqueue not reporting EOF under certain circumstances
Hi all. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149857 This PR is rather old. I just had submitted new test case, now in plain c. It doesn't work exactly like python version, but the result is the same: > clang test.c > cat test.c | ./a.out -1 916 0 0 0 -1 0 32768 0 0 > ./a.out < test.c -1 916 0 0 0 <- and here we have a complete hang in [kqread]. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound
On 10 Jul 2012, at 08:12, Doug Barton wrote: > On 07/09/2012 14:47, Mark Blackman wrote: >> I never use '-t' with dig. drill *told* me I should use '-t' >> then completely failed to acknowledge I had done so. > > Have you reported this bug? Nope, you? - Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On Tue, Jul 10, 2012 at 12:18 AM, Doug Barton wrote: >> But I think you are wrong about this one aspect of your >> proposed change. To discover that "dig" is suddenly not in the base >> FreeBSD system any more some day would be just about the worst >> violation of the Principle of Least Astonishment for me in many >> years. > > All flippancy aside, I understand what you're saying here. The problem > is that we can't keep BIND in the base. Given that, we need to look at > how best to handle the transition. This is essentially what I was trying to get at :-) The proposed solution of `dig` and `host` returning "These tools can be installed through the bind-utils port, or you can use `drill`" I think would be sufficient. Having them simply disappear would be terrible, but stubs would make this possibly the least painful thing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kernel: abra-kadabra
this is what i've got from kernel (same visible after dmesg of course) Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die txoiedtn eo dn sosini ggnsnaalilg n1a1l Jul 9 08:56:53 .. kernel: 1 Jul 9 08:56:53 ... kernel: Jul 9 08:56:53 ... kernel: <<66>>11 Jul 9 08:56:53 ... kernel: 1 Jul 9 08:56:53 ... kernel: everything before and after seems usual. when reading every second letter it SEEMS to make more sense but still not much. What it is? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound 9.1 code freeze?)
On 07/10/2012 00:28, Mike Meyer wrote: > I suspect that dnsmasq is a lot better tool for that job than BIND I think "better" is in the eye of the beholder, particularly whether or not the "O" is either small or well-staffed enough to pre-enter hostnames into the zone files. That said, dnsmasq is a great tool, especially if you're relying on DDNS. OTOH, as anyone can see from the named.conf in the base, I believe rather strongly that a large'ish network should take responsibility for being authoritative for 1918 stuff (et al) so that they don't go out over the network. You can still do that with other solutions, but this is one area where the fact that BIND can do both is a feature. Doug -- Change is hard. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound 9.1 code freeze?)
On Tue, 10 Jul 2012 00:12:16 -0700 Doug Barton wrote: > On 07/09/2012 19:46, Peter Jeremy wrote: > > As I see it, FreeBSD systems fall roughly into 3 categories: > > 1) Client systems that need to lookup external DNS servers only. > > 2) SOHO systems that primarily do external lookups but need to > >be internally authoritative about their local network. > > 3) Systems that are primarily DNS servers. > > > > I think the majority of the remaining unease in this thread comes from > > people who administer systems in the second category. I (and I expect > > lots of other people) use bind for this solely because it is in the > > base system, not because it is the best tool for the job. > > Well that's yet another reason to take it out of the base so that people > can analyze this critically. :) > > Seriously though, "install BIND from ports" is still a good answer to > this use case. I'd argue that BIND 9.[89] is actually the best tool for > the purpose you outlined, but there's no reason you couldn't use a > combination of unbound and nsd. It would just be different than what > people are used to. I suspect that dnsmasq is a lot better tool for that job than BIND, but see below. Unless you've got a really messy SOHO network, anyway. It's simpler to configure, and includes an integrated DHCP server so hosts that get their IP addresses via DHCP show show up in the dns server. I know bind and at least one DHCP server can be setup to do that, but I never could get it to work properly. dnsmasq did it the first time years ago, and I've never looked back. These days, I'm using it on a DDWRT router. I would have suggested it for the base system, but 1) it's still a bit more than case 1 needs, and 2) it's GPL'ed. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 07/09/2012 16:45, George Mitchell wrote: > On 07/09/12 17:01, Doug Barton wrote: >> On 07/09/2012 06:45, Mark Blackman wrote: >> >>> Indeed, 'dig' and 'host' must be present and working as expected >>> in a minimally installed system. >> >> So if you don't like the versions that get imported, install bind-tools >> from ports. >> >> Doug >> > Doug, you are one of the people whose writings on the FreeBSD lists I > most respect. Thank you for the kind words. :) > But I think you are wrong about this one aspect of your > proposed change. To discover that "dig" is suddenly not in the base > FreeBSD system any more some day would be just about the worst > violation of the Principle of Least Astonishment for me in many > years. All flippancy aside, I understand what you're saying here. The problem is that we can't keep BIND in the base. Given that, we need to look at how best to handle the transition. Doug -- Change is hard. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/09/2012 19:56, Peter Jeremy wrote: > On 2012-Jul-10 00:40:07 +0200, Dag-Erling Smørgrav > wrote: >> They are sufficiently similar that writing a wrapper that >> supports a significant subset of dig's command-line option and >> uses drill as a backend shouldn't take more than an afternoon for >> a reasonably experienced programmer. > > I would further suggest that where a dig(1) option isn't emulated, > the fallback error message should refer the user to drill(1). IMO we don't need a wrapper for drill. For most people, just substituting 'drill' for 'dig' is enough. For more complex stuff people really need to learn the new tool, or install bind-tools. >> As for nslookup... it's been deprecated for a decade. > > But old fogies might still use it. Can I suggest that something > along the lines of the the following be installed as > /usr/bin/nslookup: > > #!/bin/sh echo "nslookup is no longer supported. Please see > drill(1) or host(1)" >&2 exit 1 You have no idea how long I've wanted to do that. :) - -- Change is hard. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+9bHAAoJEFzGhvEaGryEd9YIAL/A71XjQUC2aXZV36m4nFJ6 sGqfpeVcP/AjaF67wld1WukcrKxqqjmIQATlUna3m6L5t0exNGy4y3Udqmr5eOeo U6p/qYyJ2xkaPz+GnmcO6ygi4uWa0CwzbH5/jfprRSrCQuk7PZzRC0FvNsqqQcyc PtwEBmxTHzURSE6CaB19EuYKYQe+hLecSZlwVlipG4IaEmqmczpdjHnE1EHWiGCU 2uIEkJRradqXknAUTxfomAfM8ARiK2AQGT3TKRJuG8ApcF2CpoJkCaFKn73yxvn8 DQ3ENpSKkkRn8n7t/a9rOUQ0gbl9GP3dXpX/1Kw0dlq21LsGn5aOIy+yvOUw3bw= =Yrv4 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound
On 07/09/2012 14:47, Mark Blackman wrote: > I never use '-t' with dig. drill *told* me I should use '-t' > then completely failed to acknowledge I had done so. Have you reported this bug? -- Change is hard. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound 9.1 code freeze?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/09/2012 19:46, Peter Jeremy wrote: > Firstly, I should note that I'm not against removing bind from base. Thanks for clarifying. > I'm merely saying that users are going to need some guidance during > the transition. I've never argued against that. I think you misunderstood my flippant comment below. > On 2012-Jul-09 13:52:15 -0700, Doug Barton wrote: >> On 07/09/2012 13:47, Peter Jeremy wrote: >>> On 2012-Jul-09 14:15:13 +0200, in freebsd-security, "Andrej (Andy) >>> Brodnik" wrote: Excuse my ignorance - but is there a how-to paper on transition from bind to unbound for SOHO? >> >> You don't need to transition if you don't want to. Just install BIND >>from the ports. > > IMHO, this is a copout. If the default response to anyone asking a > question about transitioning is "install bind" then we might as well > leave bind in the base system. 3 things to keep in mind in response. 1. We cannot keep BIND in the base system. 2. As above, I didn't say we shouldn't have a transition guide. I said we don't need one. That may not seem like an important distinction, but it is. :) 3. People really don't have to transition if they don't want to. All 3 of these are important points, but 1 and 3 are critical for people to understand if they are going to participate in this discussion. > As I see it, FreeBSD systems fall roughly into 3 categories: > 1) Client systems that need to lookup external DNS servers only. > 2) SOHO systems that primarily do external lookups but need to >be internally authoritative about their local network. > 3) Systems that are primarily DNS servers. > > The third category is clearly a "use ports" case - there's no need > for the base system to include all the tools necessary to build one > of the root nameservers. > > The base system _must_ handle the first category - and I'll accept > advice from dougb@ & des@ that unbound is a good choice for this. The > issues people seem to have with the change here are the user tools > to interface with DNS - currently dig(1), host(1) and nslookup(1) - > and des@ has now adequately covered this. I think your analysis above is basically correct. > I think the majority of the remaining unease in this thread comes from > people who administer systems in the second category. I (and I expect > lots of other people) use bind for this solely because it is in the > base system, not because it is the best tool for the job. Well that's yet another reason to take it out of the base so that people can analyze this critically. :) Seriously though, "install BIND from ports" is still a good answer to this use case. I'd argue that BIND 9.[89] is actually the best tool for the purpose you outlined, but there's no reason you couldn't use a combination of unbound and nsd. It would just be different than what people are used to. >>> In particular, if unbound has no authoritative server capabilities, >>> what suggestions are there for handling the private hosts in a SOHO >>> environment? >> >> Stub and/or forward zones. The unbound docs have more information. > > But unfortunately no tutorial guides. https://unbound.net/documentation/index.html > Having looked at the online > copy of unbound.conf(5), it appears that unbound _does_ have some > limited server capabilities - this wasn't clear in the original > proposal. It's not immediately clear to me whether it's adequate for > my purposes and, if it isn't, what I should use. You're still stuck on "If it's in the base, it's the thing I have to use, so the fact that I don't know how to use it is causing me stress." Get over that, and realize that you can continue to use all the same stuff you already have, if you install BIND from ports. :) Doug - -- Change is hard. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP+9XPAAoJEFzGhvEaGryENVkH/jWir7h8xI9CmdpMuXdMRZZT ulfoUs8KFt1BAwWvIQsXS1kwH+coe6i0rMd9ir9QCXgs9CqllJ8NhTcaY+OqxudA YcUWdzYIX6szfrgnocwxlZWIz2Xou63T3cRFdBQ9hzLDA7KzlJxgreTtLrEf3Fvg V1qv0ZigI3X50UtelOilROe/xqZLHwgOlUWpX6vuvYJhlw5s///Oe+13ZSQkqTa7 Roa9bz3r2PKaHSw3hTjKIuVDiCwJQMbx26IXmYf5SPIlJaBG28/LBGVFcxETMPPf c+fc1JYjDp2wZ1yBUmJ3gljtl7mGmGV40KF9WCie6dKrTSMgRGAvuTn+EMXD3rs= =RRzj -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
