Re: 8.2 + apache == a LOT of sigprocmask
Hi.
I was trying to understand a cause for this problem, and made an ugly hack:
diff -u ./rtld_lock.c.orig ./rtld_lock.c
--- ./rtld_lock.c.orig 2011-11-15 07:56:14.0 +
+++ ./rtld_lock.c 2011-11-15 07:54:42.0 +
@@ -118,7 +118,7 @@
sigset_t tmp_oldsigmask;
for ( ; ; ) {
- sigprocmask(SIG_BLOCK, &fullsigmask, &tmp_oldsigmask);
+// sigprocmask(SIG_BLOCK, &fullsigmask, &tmp_oldsigmask);
if (atomic_cmpset_acq_int(&l->lock, 0, WAFLAG))
break;
sigprocmask(SIG_SETMASK, &tmp_oldsigmask, NULL);
@@ -135,7 +135,7 @@
atomic_add_rel_int(&l->lock, -RC_INCR);
else {
atomic_add_rel_int(&l->lock, -WAFLAG);
- sigprocmask(SIG_SETMASK, &oldsigmask, NULL);
+// sigprocmask(SIG_SETMASK, &oldsigmask, NULL);
}
}
this reduced number of syscalls, but I am not sure about stability and
correctness of this hack.
And performance problems of apache remained (this hack only gave 5-10%
increase of performance).
Also I found problem in longjmp syscalls. In FreeBSD we are doing this
syscalls from gen/setjmp.S without condition check,
for example in Linux we are doing it only if stack has been saved.
Linux code:
if (env[0].__mask_was_saved)
/* Restore the saved signal mask. */
(void) __sigprocmask (SIG_SETMASK, &env[0].__saved_mask,
(sigset_t *) NULL);
After all that I was trying to compare perfomance of return from fork()
in Linux and FreeBSD (see
http://lists.freebsd.org/pipermail/freebsd-hackers/2011-October/036705.html)
and fork() in FreeBSD was slower.
I am not trying to start a holy war, but I really need to increase
performance of our hosting in FreeBSD.
On 15.11.2011 01:59, Doug Barton wrote:
On 11/14/2011 12:56, John Baldwin wrote:
On Monday, November 14, 2011 3:31:43 pm Doug Barton wrote:
Trying to track down a load problem we're seeing on 8.2-RELEASE-p4 i386
in a busy web hosting environment I came across the following post:
http://lists.freebsd.org/pipermail/freebsd-questions/2011-
October/234520.html
That basically describes what we're seeing as well, including the
"doesn't happen on Linux" part.
Does anyone have any ideas about this?
With incredibly similar stuff running on 7.x we didn't see this problem,
so it seems to be something new in 8.
I suspect it has to do with some of the changes to rtld such that it now
always blocks signals while resolving symbols (or something along those
lines IIRC). It makes throwing exceptions slow as well.
The calls to sigprocmask() in rtld seem to be doing what you suggest
here, but they involve setting and restoring the mask. In my followup
post I pasted what we're seeing, which is different, and much more
voluminous. For example, 13,500 calls in 30 seconds from a single apache
worker process.
Although this does seem to explain why our test cases have more calls
when compiled with C++ than they do when compiled with C. :)
Thanks for the response in any case.
Doug
--
С уважением,
Daniil Cherednik
.masterhost
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2 + apache == a LOT of sigprocmask
Hi.
I was trying to understand a cause for this problem, and made an ugly hack:
diff -u ./rtld_lock.c.orig ./rtld_lock.c
--- ./rtld_lock.c.orig 2011-11-15 07:56:14.0 +
+++ ./rtld_lock.c 2011-11-15 07:54:42.0 +
@@ -118,7 +118,7 @@
sigset_t tmp_oldsigmask;
for ( ; ; ) {
- sigprocmask(SIG_BLOCK, &fullsigmask, &tmp_oldsigmask);
+// sigprocmask(SIG_BLOCK, &fullsigmask, &tmp_oldsigmask);
if (atomic_cmpset_acq_int(&l->lock, 0, WAFLAG))
break;
sigprocmask(SIG_SETMASK, &tmp_oldsigmask, NULL);
@@ -135,7 +135,7 @@
atomic_add_rel_int(&l->lock, -RC_INCR);
else {
atomic_add_rel_int(&l->lock, -WAFLAG);
- sigprocmask(SIG_SETMASK, &oldsigmask, NULL);
+// sigprocmask(SIG_SETMASK, &oldsigmask, NULL);
}
}
this reduced number of syscalls, but I am not sure about stability and
correctness of this hack.
And performance problems of apache remained (this hack only gave 5-10%
increase of performance).
Also I found problem in longjmp syscalls. In FreeBSD we are doing this
syscalls from gen/setjmp.S without condition check,
for example in Linux we are doing it only if stack has been saved.
Linux code:
if (env[0].__mask_was_saved)
/* Restore the saved signal mask. */
(void) __sigprocmask (SIG_SETMASK, &env[0].__saved_mask,
(sigset_t *) NULL);
After all that I was trying to compare perfomance of return from fork()
in Linux and FreeBSD (see
http://lists.freebsd.org/pipermail/freebsd-hackers/2011-October/036705.html)
and fork() in FreeBSD was slower.
I am not trying to start a holy war, but I really need to increase
performance of our hosting in FreeBSD.
On 15.11.2011 01:59, Doug Barton wrote:
On 11/14/2011 12:56, John Baldwin wrote:
On Monday, November 14, 2011 3:31:43 pm Doug Barton wrote:
Trying to track down a load problem we're seeing on 8.2-RELEASE-p4 i386
in a busy web hosting environment I came across the following post:
http://lists.freebsd.org/pipermail/freebsd-questions/2011-
October/234520.html
That basically describes what we're seeing as well, including the
"doesn't happen on Linux" part.
Does anyone have any ideas about this?
With incredibly similar stuff running on 7.x we didn't see this problem,
so it seems to be something new in 8.
I suspect it has to do with some of the changes to rtld such that it now
always blocks signals while resolving symbols (or something along those
lines IIRC). It makes throwing exceptions slow as well.
The calls to sigprocmask() in rtld seem to be doing what you suggest
here, but they involve setting and restoring the mask. In my followup
post I pasted what we're seeing, which is different, and much more
voluminous. For example, 13,500 calls in 30 seconds from a single apache
worker process.
Although this does seem to explain why our test cases have more calls
when compiled with C++ than they do when compiled with C. :)
Thanks for the response in any case.
Doug
--
С уважением,
Daniil Cherednik
.masterhost
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2 + apache == a LOT of sigprocmask
Daniil Cherednik wrote: After all that I was trying to compare perfomance of return from fork() in Linux and FreeBSD (see http://lists.freebsd.org/pipermail/freebsd-hackers/2011-October/036705.html) and fork() in FreeBSD was slower. our fork() differs from linux fork() in handling parent and child memory pages, and ours is generally slower, that's why sphinxsearch (prior to 1.1 with its prefork model) was unusable on FreeBSD under moderate and heavy load, too many forks %) -- SY, Marat
Re: 8.2 + apache == a LOT of sigprocmask
On Mon, Nov 14, 2011 at 12:51:35PM -0800, Doug Barton wrote: > On 11/14/2011 12:31, Doug Barton wrote: > > Trying to track down a load problem we're seeing on 8.2-RELEASE-p4 i386 > > in a busy web hosting environment I came across the following post: > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234520.html > > > > That basically describes what we're seeing as well, including the > > "doesn't happen on Linux" part. > > > > Does anyone have any ideas about this? > > > > With incredibly similar stuff running on 7.x we didn't see this problem, > > so it seems to be something new in 8. > > Just took a closer look at our ktrace, and actually our pattern is > slightly different than the one in that post. In ours the second option > is null, but the third is set: > > 74195 httpd0.17 RET sigprocmask 0 > 74195 httpd0.13 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) > 74195 httpd0.09 RET sigprocmask 0 > 74195 httpd0.13 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) > 74195 httpd0.09 RET sigprocmask 0 > 74195 httpd0.12 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) > > But repeated hundreds of times in a row. The calls cannot come from rtld, they are generated by some setjmp() invocation. If signal-safety is not needed, sigsetjmp() should be used instead. Quick grep of the apache httpd source shows a single setjmp() in their copy of pcre. No idea is it to safe to change setjmp() into sigsetjmp(?, 0). pgp1NaxV3yHCF.pgp Description: PGP signature
Re: 8.2 + apache == a LOT of sigprocmask
On Tue, Nov 15, 2011 at 11:07:45AM +0200, Kostik Belousov wrote: > On Mon, Nov 14, 2011 at 12:51:35PM -0800, Doug Barton wrote: > > On 11/14/2011 12:31, Doug Barton wrote: > > > Trying to track down a load problem we're seeing on 8.2-RELEASE-p4 i386 > > > in a busy web hosting environment I came across the following post: > > > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234520.html > > > > > > That basically describes what we're seeing as well, including the > > > "doesn't happen on Linux" part. > > > > > > Does anyone have any ideas about this? > > > > > > With incredibly similar stuff running on 7.x we didn't see this problem, > > > so it seems to be something new in 8. > > > > Just took a closer look at our ktrace, and actually our pattern is > > slightly different than the one in that post. In ours the second option > > is null, but the third is set: > > > > 74195 httpd0.17 RET sigprocmask 0 > > 74195 httpd0.13 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) > > 74195 httpd0.09 RET sigprocmask 0 > > 74195 httpd0.13 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) > > 74195 httpd0.09 RET sigprocmask 0 > > 74195 httpd0.12 CALL sigprocmask(SIG_BLOCK,0,0xbfbf89d4) > > > > But repeated hundreds of times in a row. > > The calls cannot come from rtld, they are generated by some setjmp() > invocation. If signal-safety is not needed, sigsetjmp() should be used > instead. > > Quick grep of the apache httpd source shows a single setjmp() in their > copy of pcre. No idea is it to safe to change setjmp() into sigsetjmp(?, 0). I hate cross-posting, but: adding freebsd-apache@ to the list. Some of the Apache folks (not just port committers) may have some insight to Kostik's findings. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: question on netstat statistics.
On 15/11/2011 01:46, Jeremy Chadwick wrote: > On Mon, Nov 14, 2011 at 07:56:07PM -0500, Glen Barber wrote: >> Jeremy Chadwick wrote: >> >> [...] >> >>> I don't particularly care what the man page says, I just know what >>> works. :-) >> If there is something in the man page that is not precise, I personally >> am interested in any inconsistencies with reality so they can be fixed. >> Even given your detailed explanation, I'm still not 100% clear on what, >> if anything, is incorrect in the manual. > FWIW, neither am I. The OP seems to be basing his argument syntaxes > based on what's in the man page, so if something is vague, confusing, > or inaccurate, he will need to state clearly what it is that's an > anomaly. > > My comment was more along the lines of: "if it's wrong in the man page, > I'm really not that concerned" (e.g. file a PR and be done with it). > I'm still trying to work out exactly what it is the OP wants > statistics-wise on a per-interface basis. I'm left thinking he wants > "netstat -s" output per-interface, but that's not going to happen. > You are correct, my reading of the manpage suggested that per interface stats should be available. netstat -i | -I interface -s [-f protocol_family | -p protocol] [-M core] [-N system] Display per-interface statistics for each network protocol, for a particular protocol_family, or for a single protocol. As that was incorrect then I do consider the manpage to need updating. I'll file a PR but I wasnt sure if this was correct behavior or not. Thanks, Vince ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2 + apache == a LOT of sigprocmask
- Original Message - From: "Daniil Cherednik" I am not trying to start a holy war, but I really need to increase performance of our hosting in FreeBSD. Is there something you need from apache that means you cant use nginx for instead? nginx + php-fpm is much higher performing, we switch a year ago and would never go back. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2 + apache == a LOT of sigprocmask
We know about it. But unfortunately we can`t use php-fpm or other fcgi solution. We must use .htaccess with php directive. On 15.11.2011 15:34, Steven Hartland wrote: - Original Message - From: "Daniil Cherednik" I am not trying to start a holy war, but I really need to increase performance of our hosting in FreeBSD. Is there something you need from apache that means you cant use nginx for instead? nginx + php-fpm is much higher performing, we switch a year ago and would never go back. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. -- С уважением, Daniil Cherednik .masterhost ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfi timeouts
On Monday, November 14, 2011 7:27:18 pm Jan Mikkelsen wrote: > Hi, > > Sorry about being unclear. They all failed in the same way. > > So, these combinations have continuous timeout errors and fail to completely > boot: > > Plain 9.0-RC1 > > 9-stable with 1.62 of mfi.c > > 9-stable with www.freebsd.org/~jhb/patches/mfi.patch, pci_alloc_msi > instead of pci_alloc_msix and hw.mfi.msix=0 > > This boots, but gets "mfi0: Cannot allocate interrupt" and there are no > /dev/mfi* devices: > > 9-stable with www.freebsd.org/~jhb/patches/mfi.patch and hw.mfi.msix=1 > > This seems to work, but I have not put any load on it yet: > > 9-stable with www.freebsd.org/~jhb/patches/mfi.patch, pci_alloc_msi > instead of pci_alloc_msix and hw.mfi.msix=1 Ok, so MSI interrupts seem to work for you. > > I see you have a new patch, www.freebsd.org/~jhb/patches/mfi_msi.patch. This > patch doesn't seem to include the dummy read from your earlier patch, or the one in 1.62 of mfi.c. I assume I need to apply the 1.62 mfi.c diff to by 9-stable sources as well. Is that correct? You can just apply this patch, no need to backport the fix in 1.62 as that fix should not be needed if you are using MSI. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: question on netstat statistics.
On 15/11/2011 00:56, Glen Barber wrote: > Hi, > > Jeremy Chadwick wrote: > > [...] > >> I don't particularly care what the man page says, I just know what >> works. :-) >> > > If there is something in the man page that is not precise, I personally > am interested in any inconsistencies with reality so they can be fixed. > Even given your detailed explanation, I'm still not 100% clear on what, > if anything, is incorrect in the manual. Hi Glen, Filed as as misc/162587, sorry i did start using category docs and class docs, but I timed out the original web form and forgot to change from defaults while copying and pasting to the new page. Serves me right for using the web form. Regards, Vince > > Regards, > > Glen > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: question on netstat statistics.
Hi Vincent, On Tue, Nov 15, 2011 at 04:25:18PM +, Vincent Hoffman wrote: > On 15/11/2011 00:56, Glen Barber wrote: > > Hi, > > > > Jeremy Chadwick wrote: > > > > [...] > > > >> I don't particularly care what the man page says, I just know what > >> works. :-) > >> > > > > If there is something in the man page that is not precise, I personally > > am interested in any inconsistencies with reality so they can be fixed. > > Even given your detailed explanation, I'm still not 100% clear on what, > > if anything, is incorrect in the manual. > Hi Glen, > Filed as as misc/162587, sorry i did start using category > docs and class docs, but I timed out the original web form and forgot to > change from defaults while copying and pasting to the new page. Serves > me right for using the web form. > Thanks for pointing me to the PR. I've assigned it to myself, and will look into this. Glen -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project pgpL4DZTOvhxn.pgp Description: PGP signature
SIOCGIFADDR broken on 9.0-RC1?
Hello list,
more insights since my last post. Here is a small code to trigger the bug (end
of email).
When you run it on 9.0-RC1, it gets an alias address instead of the main inet
address:
% ./get-ip re0
inet: 192.168.2.10
# Main address being 192.168.1.148
On 8.2-RELEASE, all goes well:
% ./get-ip re0
inet: PUBLIC_IP4
Is something broken, or a behaviour has changed since 8.2-RELEASE?
Best regards,
--8<--
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
int fd;
struct ifreq ifr;
const struct sockaddr_in *sa;
fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0) {
perror("socket");
exit(-1);
}
memset(&ifr, 0, sizeof(struct ifreq));
strlcpy(ifr.ifr_name, argv[1], sizeof(ifr.ifr_name));
if (ioctl(fd, SIOCGIFADDR, &ifr) == 0) {
sa = (const struct sockaddr_in *) &ifr.ifr_addr;
printf("inet: %s\n", inet_ntoa(sa->sin_addr));
}
else {
perror("ioctl");
exit(-1);
}
exit(0);
}
--8<--
--
^ ___ ___ http://www.GomoR.org/ <-+
| / __ |__/Senior Security Engineer |
| \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]---|
+--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Possible to build 9-stable kernel on 8.2?
Is it possible to do a buildkernel of 9-stable (r227536) on a stock 8.2 system? Most of it seems to work, but the linker fails towards the end with ... MAKE=make sh /usr/home/ctuffli/dev/releng_9/src/sys/conf/newvers.sh GENERIC /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/home/ctuffli/dev/releng_9/src/sys -I/usr/home/ctuffli/dev/releng_9/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug ld:/usr/home/ctuffli/dev/releng_9/src/sys/conf/ldscript.amd64:9: syntax error *** Error code 1 Stop in /usr/home/ctuffli/dev/releng_9/obj/usr/home/ctuffli/dev/releng_9/src/sys/GENERIC. *** Error code 1 Stop in /usr/home/ctuffli/dev/releng_9/src. *** Error code 1 Stop in /usr/home/ctuffli/dev/releng_9/src. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SIOCGIFADDR broken on 9.0-RC1?
On 2011-11-15 18:10:01 (+0100), GR wrote:
> more insights since my last post. Here is a small code to trigger the bug
> (end of email).
> When you run it on 9.0-RC1, it gets an alias address instead of the main inet
> address:
>
> % ./get-ip re0
> inet: 192.168.2.10
> # Main address being 192.168.1.148
>
> On 8.2-RELEASE, all goes well:
> % ./get-ip re0
> inet: PUBLIC_IP4
>
> Is something broken, or a behaviour has changed since 8.2-RELEASE?
>
I think the relevant bit of the code is found in sys/netinet/in.c.
If your ioctl doesn't specify an IP address we end up in this bit:
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
iap = ifatoia(ifa);
if (iap->ia_addr.sin_family == AF_INET) {
if (td != NULL &&
prison_check_ip4(td->td_ucred,
&iap->ia_addr.sin_addr) != 0)
continue;
ia = iap;
break;
}
}
The 'ia' pointer is later used to return the IP address.
In other words: it returns the first address on the interface
of type IF_INET (which isn't assigned to a jail).
I think the order of the addresses is not fixed, or rather it depends on
the order in which you assign addresses. In the handling of SIOCSIFADDR
new addresses are just appended:
TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link);
I don't believe this has changed since 8.0. Is it possible something
changed in the network initialisation, leading to the addresses being
assigned in a different order?
Eagerly awaiting to be told I'm wrong,
Kristof
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SIOCGIFADDR broken on 9.0-RC1?
On (15/11/2011 18:10), GR wrote:
> Hello list,
>
> more insights since my last post. Here is a small code to trigger the bug
> (end of email).
> When you run it on 9.0-RC1, it gets an alias address instead of the main inet
> address:
>
> % ./get-ip re0
> inet: 192.168.2.10
> # Main address being 192.168.1.148
>
> On 8.2-RELEASE, all goes well:
> % ./get-ip re0
> inet: PUBLIC_IP4
>
> Is something broken, or a behaviour has changed since 8.2-RELEASE?
Your test case looks ok and works as expexted for me on 10-CURRENT, both
without aliases and after adding alias to interface. Perhaps it's the way
you add aliases (libdnet ?).
I've used:
ifconfing em0 alias OTHERIP
Thanks,
Gleb.
>
> Best regards,
>
>
> --8<--
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int
> main(int argc, char *argv[])
> {
>int fd;
>struct ifreq ifr;
>const struct sockaddr_in *sa;
>
>fd = socket(AF_INET, SOCK_DGRAM, 0);
>if (fd < 0) {
> perror("socket");
> exit(-1);
>}
>
>memset(&ifr, 0, sizeof(struct ifreq));
>strlcpy(ifr.ifr_name, argv[1], sizeof(ifr.ifr_name));
>
>if (ioctl(fd, SIOCGIFADDR, &ifr) == 0) {
> sa = (const struct sockaddr_in *) &ifr.ifr_addr;
> printf("inet: %s\n", inet_ntoa(sa->sin_addr));
>}
>else {
> perror("ioctl");
> exit(-1);
>}
>
>exit(0);
> }
> --8<--
>
> --
> ^ ___ ___ http://www.GomoR.org/ <-+
> | / __ |__/Senior Security Engineer |
> | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]---|
> +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+
>
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SIOCGIFADDR broken on 9.0-RC1?
>From "Kristof Provost" : [..] > The 'ia' pointer is later used to return the IP address. > > In other words: it returns the first address on the interface > of type IF_INET (which isn't assigned to a jail). > > I think the order of the addresses is not fixed, or rather it depends > on > the order in which you assign addresses. In the handling of > SIOCSIFADDR > new addresses are just appended: > > TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); > > I don't believe this has changed since 8.0. Is it possible something > changed in the network initialisation, leading to the addresses being > assigned in a different order? > > Eagerly awaiting to be told I'm wrong, > Kristof Thanks Kristof. It appears you are right, the order of assignement is important. I configured my interface using DHCP, and added aliases (all in /etc/rc.conf). But on the 8.2-RELEASE, I used static configuration. So, I switched to static assignement and it changes the behaviour (and "fixes" the "bug"). My guess is that during the time waiting for the DHCP offer, all aliases are already configured on the network interface, and the IP address given by DHCP is added at the end of the tail. Is that a wanted behaviour? I find it dangerous (i.e. not exactly what a user is expecting). Note: my aliases are attributed to jails. Regards, -- ^ ___ ___ http://www.GomoR.org/ <-+ | / __ |__/Senior Security Engineer | | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]---| +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SIOCGIFADDR broken on 9.0-RC1?
On Tue, Nov 15, 2011 at 11:35:37PM +0100, GR wrote: > >From "Kristof Provost" : > [..] > > The 'ia' pointer is later used to return the IP address. > > > > In other words: it returns the first address on the interface > > of type IF_INET (which isn't assigned to a jail). > > > > I think the order of the addresses is not fixed, or rather it depends > > on > > the order in which you assign addresses. In the handling of > > SIOCSIFADDR > > new addresses are just appended: > > > > TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); > > > > I don't believe this has changed since 8.0. Is it possible something > > changed in the network initialisation, leading to the addresses being > > assigned in a different order? > > > > Eagerly awaiting to be told I'm wrong, > > Kristof > > Thanks Kristof. It appears you are right, the order of assignement is > important. > I configured my interface using DHCP, and added aliases (all in /etc/rc.conf). > But on the 8.2-RELEASE, I used static configuration. > > So, I switched to static assignement and it changes the behaviour (and > "fixes" the "bug"). > My guess is that during the time waiting for the DHCP offer, all aliases are > already configured on the network interface, and the IP address given by DHCP > is added at the end of the tail. > > Is that a wanted behaviour? I find it dangerous (i.e. not exactly what a user > is expecting). > > Note: my aliases are attributed to jails. I would recommend adding synchronous_dhclient="yes" to /etc/rc.conf. This will cause dhclient (the DHCP client) to wait until it gets an answer + IP back from the DHCP server before continuing with the rc.d scripts. The default is "no". -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: Possible to build 9-stable kernel on 8.2?
Hi, On Tue, Nov 15, 2011 at 11:45:02AM -0800, Chuck Tuffli wrote: > Is it possible to do a buildkernel of 9-stable (r227536) on a stock > 8.2 system? Most of it seems to work, but the linker fails towards the > end with > > ... > MAKE=make sh /usr/home/ctuffli/dev/releng_9/src/sys/conf/newvers.sh GENERIC > /usr/local/bin/svnversion > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -nostdinc -I. > -I/usr/home/ctuffli/dev/releng_9/src/sys > -I/usr/home/ctuffli/dev/releng_9/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-omit-frame-pointer -mno-sse > -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror vers.c > linking kernel.debug > ld:/usr/home/ctuffli/dev/releng_9/src/sys/conf/ldscript.amd64:9: syntax error > *** Error code 1 > > Stop in > /usr/home/ctuffli/dev/releng_9/obj/usr/home/ctuffli/dev/releng_9/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/home/ctuffli/dev/releng_9/src. > *** Error code 1 > > Stop in /usr/home/ctuffli/dev/releng_9/src. You'll need to do 'buildworld' first. Regards, Glen -- Glen Barber ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Possible to build 9-stable kernel on 8.2?
On Tue, Nov 15, 2011 at 07:29:44PM -0500, Glen Barber wrote: > Hi, > > On Tue, Nov 15, 2011 at 11:45:02AM -0800, Chuck Tuffli wrote: > > Is it possible to do a buildkernel of 9-stable (r227536) on a stock > > 8.2 system? Most of it seems to work, but the linker fails towards the > > end with > > > > ... > > MAKE=make sh /usr/home/ctuffli/dev/releng_9/src/sys/conf/newvers.sh GENERIC > > /usr/local/bin/svnversion > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g > > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > > -fdiagnostics-show-option -nostdinc -I. > > -I/usr/home/ctuffli/dev/releng_9/src/sys > > -I/usr/home/ctuffli/dev/releng_9/src/sys/contrib/altq -D_KERNEL > > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > > -finline-limit=8000 --param inline-unit-growth=100 --param > > large-function-growth=1000 -fno-omit-frame-pointer -mno-sse > > -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > > -Werror vers.c > > linking kernel.debug > > ld:/usr/home/ctuffli/dev/releng_9/src/sys/conf/ldscript.amd64:9: syntax > > error > > *** Error code 1 > > > > Stop in > > /usr/home/ctuffli/dev/releng_9/obj/usr/home/ctuffli/dev/releng_9/src/sys/GENERIC. > > *** Error code 1 > > > > Stop in /usr/home/ctuffli/dev/releng_9/src. > > *** Error code 1 > > > > Stop in /usr/home/ctuffli/dev/releng_9/src. > > You'll need to do 'buildworld' first. Not to mention, one should always do buildworld first. The absolute correct procedure is outlined in /usr/src/Makefile: # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # [steps 3. & 4. can be combined by using the "kernel" target] # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster'(you may wish to use -i, along with -U or -F). # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) People (not you Glen :-) ) need to realise that doing buildworld actually builds the necessary "build toolchain" used for the buildkernel portion (the results are in /usr/obj). Failure to do that results in the buildkernel bits using the already-installed-on-the-system compiler/build toolchain (e.g. the stuff in /usr), which may not be compatible with the version of the kernel source you're trying to build. Hope this makes sense to readers. Two "extra steps" which I do: - Before step 1, I do rm -fr /usr/obj/* - Before step 7, I do rm -fr /usr/share/man/* Step 1 is a precaution, and step 7 ensures that no old/leftover compressed man pages (from old versions of software) are retained. If needed/asked, Doug Barton can talk a bit more about the latter. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: Possible to build 9-stable kernel on 8.2?
On 15 November 2011 23:45, Chuck Tuffli wrote: > Is it possible to do a buildkernel of 9-stable (r227536) on a stock > 8.2 system? Most of it seems to work, but the linker fails towards the > end with > > ... > MAKE=make sh /usr/home/ctuffli/dev/releng_9/src/sys/conf/newvers.sh GENERIC > /usr/local/bin/svnversion > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -nostdinc -I. > -I/usr/home/ctuffli/dev/releng_9/src/sys > -I/usr/home/ctuffli/dev/releng_9/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-omit-frame-pointer -mno-sse > -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror vers.c > linking kernel.debug > ld:/usr/home/ctuffli/dev/releng_9/src/sys/conf/ldscript.amd64:9: syntax error > *** Error code 1 > > Stop in > /usr/home/ctuffli/dev/releng_9/obj/usr/home/ctuffli/dev/releng_9/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/home/ctuffli/dev/releng_9/src. > *** Error code 1 > > Stop in /usr/home/ctuffli/dev/releng_9/src. IIRC 8.x has sufficiently old binutils (ld is part of them) that doesn't understand opcodes and suchlike constructs used in 9.x based on top of newer biinutils. And you are trying to build 9.x using binutils from 8.x. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ATA/Cdrom(?) panic
Hey, we have seen this or a very similar panic for about 1 year now once in a while and I think I reported it before; this is FreeBSD as guest on vmware. Seems it was a double panic this time. Could someone please see what's going on there?It was on 8.x-STABLE in the past and this is 8.2-RELEASE-p4. Thanks /bz acd0: WARNING - READ_TOC taskqueue timeout - completing request directly Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x1f4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc08a1e9f stack pointer = 0x28:0xe6ad5b9c Fatal trap 12: page fault while in kernel mode frame pointer = 0x28:0xe6ad5bb4 cpuid = 2; code segment= base 0x0, limit 0xf, type 0x1bapic id = 02 = DPL 0, pres 1, def32 1, gran 1 fault virtual address = 0x1f4 processor eflags= fault code = supervisor read, page not presentinterrupt enabled, instruction pointer = 0x20:0xc08a1e9fresume, stack pointer = 0x28:0xe8e9e808IOPL = 0 frame pointer = 0x28:0xe8e9e820 current process = code segment= base 0x0, limit 0xf, type 0x1b12 (swi6: task queue) = DPL 0, pres 1, def32 1, gran 1 trap number = 12 processor eflags= interrupt enabled, panic: page faultresume, cpuid = 4IOPL = 0 current process = KDB: stack backtrace:25162 (bsnmpd) trap number = 12#0 0xc08e0d07 at kdb_backtrace+0x47 #1 0xc08b1dc7 at panic+0x117 #2 0xc0be4b53 at trap_fatal+0x323 #3 0xc0be4dd0 at trap_pfault+0x270 #4 0xc0be5315 at trap+0x465 #5 0xc0bcbecc at calltrap+0x6 #6 0xc08b0d86 at _sema_post+0x46 #7 0xc056fa47 at ata_completed+0x727 #8 0xc08eb97a at taskqueue_run_locked+0xca #9 0xc08ebc8a at taskqueue_run+0xaa #10 0xc08ebd53 at taskqueue_swi_run+0x13 #11 0xc088903b at intr_event_execute_handlers+0x13b #12 0xc088a75b at ithread_loop+0x6b #13 0xc0886d51 at fork_exit+0x91 #14 0xc0bcbf44 at fork_trampoline+0x8 Uptime: 5d20h1m56s (gdb) l *ata_completed+0x727 489 (request->callback)(request); 490 else 491 sema_post(&request->done); 492 493 /* only call ata_start if channel is present */ 494 if (ch) 495 ata_start(ch->dev); 496 } 497 498 void -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SIOCGIFADDR broken on 9.0-RC1?
Am 15.11.2011 um 23:35 schrieb GR: > So, I switched to static assignement and it changes the behaviour (and > "fixes" the "bug"). > My guess is that during the time waiting for the DHCP offer, all aliases are > already configured on the network interface, and the IP address given by DHCP > is added at the end of the tail. > > Is that a wanted behaviour? I find it dangerous (i.e. not exactly what a user > is expecting). A bit of background, as best I understand it and remember from Stevens: Interfaces in BSD do not have a notion of "primary" and "additional" addresses; interfaces just have any number of addresses associated with them. There's no inherent ordering in this list (except for how the current implementation seems to keep them in the order they were configured). To be able to associate proper routes with interface addresses, the recommendation for multiple IPv4 addresses on an Ethernet interface is to have one of them have the proper netmask for the network, and configure the remainder with a netmask of 255.255.255.255. But that's solely for the benefit of the routing table; the interface itself doesn't really care. Reading the rc.conf man page could give you the impression that there are primary and alias addresses, but the networking code doesn't really work like that. The new ipv4_addrs_ syntax exposes the actual behavior in a more direct way. Jeremy gave you a hint on how to fix your immediate problem, but the real answer is that the program needs to be fixed that makes assumptions about meaning attached to the first configured IPv4 address. HTH, Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
