Re: [PATCH] nscd
On 09/30/14 04:17, Eggert, Lars wrote: When I start nscd -n -s -t and then run top in another shell, top takes ~10 seconds to start up every time; if nscd did its thing, repeat invocations should be much faster. nscd doesn't seem to see any activity either, based on its log: The -t switch will only work after you change the #ifdef in debug.h to define the trace routines, and even then it doesn't give you too much information other than what methods are called. nscd could really use some debug logging but that's a whole other issue. As for why it's not working in your setup I can't say. Have you tried testing with getent to see which database is taking so long, and is that 10 seconds before or after the patch? By default nscd is suppose to timeout after 8 seconds so there might be something else going on in nscd which you're being affected by which is now being exposed. What I do know is when the timeout value is unusually large (in this case due to the bad memcpy) the kevent timer registered at the end of nscd.c:process_socket_event() doesn't seem to be honored. My guess is inside the kernel it's setting it to 0 if it exceeds some threshold so it immediately gets triggered. It's basically shooting itself in the head right when a connection to the socket is made. You can test this by running 'socat UNIX-CONNECT:/var/run/nscd -'. You'll notice that it instantly disconnects without the patch, then 8 seconds with it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] nscd
So, I've noticed nscd hasn't worked right for awhile now. Since I
upgraded to 10.0 it never seemed to cache properly but I never bothered
to really dig into it until recently and here's what I've found. In my
environment I have nsswitch set to use caching and LDAP as such:
group: files cache ldap
passwd: files cache ldap
The LDAP part works fine, but caching didn't on 10.0 for some reason.
On my 9.2 machines it works as expected though. What I've found is in
usr.sbin/nscd/query.c
struct query_state *
init_query_state(int sockfd, size_t kevent_watermark, uid_t euid, gid_t
egid)
{
...
memcpy(retval-timeout, s_configuration-query_timeout,
sizeof(struct timeval));
...
}
s_configuration-query_timeout is an 'int' which is being memcpy'd into
a 'struct timeval' causing it to grab other parts of the s_configuration
struct along with the query_timeout value and polluting retval-timeout.
In this case it appears to be grabbing s_configuration-threads_num and
shoving that into timeout.tv_sec along with the query_timeout. This ends
up confusing nscd later on (instead of being 8 it ends up being set to
34359738376) and breaks it's ability to cache. I've attached a patch to
set the retval-timeout properly and gets nscd working again. I'm
guessing gcc was handling this differently from clang which is why it
wasn't a problem before 10.0.
diff --git a/usr.sbin/nscd/query.c b/usr.sbin/nscd/query.c
index c233e19..abd8fab 100644
--- a/usr.sbin/nscd/query.c
+++ b/usr.sbin/nscd/query.c
@@ -1253,8 +1253,8 @@ init_query_state(int sockfd, size_t kevent_watermark, uid_t euid, gid_t egid)
retval-read_func = query_socket_read;
get_time_func(retval-creation_time);
- memcpy(retval-timeout, s_configuration-query_timeout,
- sizeof(struct timeval));
+ retval-timeout.tv_usec = 0;
+ retval-timeout.tv_sec = s_configuration-query_timeout;
TRACE_OUT(init_query_state);
return (retval);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] PCI bus number management
On 02/06/14 14:37, John Baldwin wrote: I have a patch to teach the PCI bus code and PCI-PCI bridge driver to manage PCI bus numbers. The approach is somewhat similar to how NEW_PCIB manages I/O windows for briges. Each bridge creates an rman to manage the bus numbers for all buses and bridges that live below it. Each bus allocates a bus resource from its parent bridge, and child bridges allocate their ranges from their parent devices. At the top of the PCI tree, the Host-PCI bridges allocate their respective bus ranges from their PCI domain/segment. There isn't really a device node for PCI domains, so I created a helper API that basically auto- creates a PCI bus rman for each domain on first use and then sub-allocates from that for Host-PCI bridges. The current patch (with some extra debugging) is at http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. If you are really, really brave, try booting with 'hw.pci.clear_bars=1', 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop survives with all those set) Note that the patch only enables bus number management on amd64 and i386. I believe ia64 just needs to define PCI_RES_BUS for this to work since it mandates ACPI. Porting this to other platforms requires handling PCI_RES_BUS rseources for Host-PCI bridges in bus_alloc_resource(), bus_adjust_resource(), and bus_release_resource(). Setting all 3 on an Atom D510MO works fine. On a Lenovo W520 though hw.pci.clear_bars=1 causes a lockup during boot. The last few lines with a normal boot are: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pcib0: decoding 5 range 0-0xfe pci0: ACPI PCI bus on pcib0 secbus=1, subbus=1 pci0:0:1:0: allocated initial secbus range While a verbose boot produces: pcib0: allocated type 3 (0xc400-0xc7ff) for rid 10 of pci:0:0:26:0 pcib0: matched entry for 0x26.INTA pcib0: slot 26 INTA hardwired to IRQ 26 And it ends there. Setting the other 2 are fine though. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
