Re: What do you use for kernel debugging?
Hi Garrett, On Sun, 28 Sep 2014 18:43:45 -0700, Garrett Cooper wrote [...] When I was debugging getting ACPI to work on my netbook, here were some other things I did to get the system up and going: - Built a stripped down kernel that just contains the essential bits (CPU, filesystem, storage). - built one kernel with debug bits and one with release bits (titled them differently of course). - built networking and other components as klds and loaded them at boot. This gave me a quick turnaround time when figuring out what was broken suspend/resume wise. It might help you isolate which drivers or subsystems are causing boot issues as well (at least netbook system boot is relatively quick compared to the other systems I boot off of with gobs of ram and storage drives...). HTH! -Garrett Yes, that's gold. It might not apply to the specific case where device probe does not complete, but I'll give it a try. Give me a day or two. Thank you! BR, -- José Pérez Arauzo ___ 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
SVN r272273 breaks 'dump'
It seems that the strptime changes broke the recognition of /etc/dumpdates. Last night's level 2 dump turned into a level 0: DUMP: Date of this level 2 dump: Mon Sep 29 00:10:26 2014 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/ada0s3a (/) to standard output DUMP: mapping (Pass I) [regular files] imb signature.asc Description: OpenPGP digital signature
Re: Looping during boot-up process in FreeBSD-11 current
On 9/29/2014 at 2:15 AM José Pérez Arauzo wrote: |This encoded message has been converted to an attachment. | |Hi Mike, |It looks like we are hitting the same problem. If we find a |third person with the same issue we can fund a club. :) |Interesting to note: | 1) we both run FBSD on small netbooks which usually get | equipped with crappy ^D^D^D^D^D^D^D cheap hardware. | 2) yours seems to be an Intel-only box, mine is an AMD-only, | so the problem is not there (I mean, it's not the graphic | chip). | 3) we both have an Atheros wifi, whose driver has been updated | recently, maybe this is the issue? The notebook in question is a circa-2002 IBM Thinkpad A31p (of the workstation replacement genre of the day). If you're curious, here's more info on it: http://www.tomsguide.com/us/ibm-thinkpad-a31p,review-42.html The Atheros WiFi is a SMC PC-Card adapter. I can unplug it to see if it has any effect on the issue. I'll do that later today when the compiling finishes. :) [snip] |I will keep you posted, in the meantime you can try and | boot your pc from 271146, it works for me. Once I figure out how to do that, I'll give it a try. :) Meanwhile, make buildkernel with 270327 should finish compiling in a few hours Thanks. Mike. ___ 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: dmesg seems broken
On Sat, Sep 27, 2014 at 7:22 PM, Chris H bsd-li...@bsdforge.com wrote: Where can I get that information? Where was it sent? Why am I not allowed to view it? Sounds to me like the kernel ring buffer is now too small for all the early boot messages? OK more investigation indicates that bumping kern.msgbufsize will return the missing bits. Maybe this is what you were trying to tell me. ;) Anyway. Anyone know why was this tunable reduced? I don't experience this on RELENG_8, or 11-CURRENT. FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info expected. :( Thanks for the reply, Brandon. --Chris -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ 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 ___ 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
capsicum and netmap ?
Hi, while trying the netmap-enabled libpcap library with tcpdump, i noticed it fails to return data on a kernel with capsicum (the string capability mode sandbox enabled made me suspicious, and removing the cap_*() calls from tcpdump.c seems to make things work again). Would anyone be able to point me what should be done in the netmap kernel module to make it work with capsicum ? I am sure the cambridge folks are very interested in this :) cheers luigi ___ 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: dmesg seems broken
On 09/29/2014 10:31, Chris H wrote: On Sat, Sep 27, 2014 at 7:22 PM, Chris H bsd-li...@bsdforge.com wrote: Where can I get that information? Where was it sent? Why am I not allowed to view it? Sounds to me like the kernel ring buffer is now too small for all the early boot messages? OK more investigation indicates that bumping kern.msgbufsize will return the missing bits. Maybe this is what you were trying to tell me. ;) Anyway. Anyone know why was this tunable reduced? I don't experience this on RELENG_8, or 11-CURRENT. FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info expected. :( Thanks for the reply, Brandon. --Chris -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ 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 ___ 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 Try adding the sysctl to your loader.conf so it is set earlier I don't think the size was reduced, you may just have a lot of messages. -- Allan Jude ___ 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: Looping during boot-up process in FreeBSD-11 current
On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | = I downloaded 11-current via svn, then copied over the pre-270327 version of ata_xpt.c. make buildworld make buildkernel make installkernel reboot The looping still occurs. I haven't checked it character for character, but it the display looks to have the same or very similar information during the looping as the two pictures I posted yesterday. Thanks. Mike. btw, the Atheros WiFi card was removed, with no change in outcome. ___ 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: capsicum and netmap ?
On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote: Hi, while trying the netmap-enabled libpcap library with tcpdump, i noticed it fails to return data on a kernel with capsicum (the string capability mode sandbox enabled made me suspicious, and removing the cap_*() calls from tcpdump.c seems to make things work again). Would anyone be able to point me what should be done in the netmap kernel module to make it work with capsicum ? I am sure the cambridge folks are very interested in this :) Without knowing what modifications have been made to libpcap, it's hard to say what you need to change, but the short version is that once cap_enter is called, you must not attempt to open any file handles as that's won't work. I can't think of any other likely cause. Are all the returns of all open(), socket(), etc calls checked? In practice that means that either opening files must come earlier, or a singling mechanism needs to be added to tcpdump and libpcap to tell tcpdump not to enter capability mode when using netmap. -- Brooks pgpqvAzMhiQke.pgp Description: PGP signature
Re: capsicum and netmap ?
On Mon, Sep 29, 2014 at 05:27:09PM +, Brooks Davis wrote: On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote: Hi, while trying the netmap-enabled libpcap library with tcpdump, i noticed it fails to return data on a kernel with capsicum (the string capability mode sandbox enabled made me suspicious, and removing the cap_*() calls from tcpdump.c seems to make things work again). Would anyone be able to point me what should be done in the netmap kernel module to make it work with capsicum ? I am sure the cambridge folks are very interested in this :) Without knowing what modifications have been made to libpcap, it's hard to say what you need to change, but the short version is that once cap_enter is called, you must not attempt to open any file handles as that's won't work. I can't think of any other likely cause. Are all the returns of all open(), socket(), etc calls checked? Hi Brooks, thanks for the feedback. The change (attached, with some debugging code; it dates back to december and i am trying to upstream it into FreeBSD now) is a set of methods called to open, dispatch and inject packets. In practice that means that either opening files must come earlier, or a singling mechanism needs to be added to tcpdump and libpcap to tell tcpdump not to enter capability mode when using netmap. The nm_open() (which includes open and mmap) occurs before the cap_enter() call, and poll() works fine until we do the cap_enter()/cap_sandboxed() calls. I was wondering whether I should somewhat annotate the file descriptor (in the netmap kernel module) indicating that it is right to access it after cap_enter(). poll() returns 1 and errno=0 when polling for POLLIN on the netmap file descriptor, while it should return 0 (there is no traffic queued). I haven't investigated in detail but it almost looks like the underlying netmap_poll() in the device driver is not called. cheers luigi ___ 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: dmesg seems broken
On 09/29/2014 10:31, Chris H wrote: On Sat, Sep 27, 2014 at 7:22 PM, Chris H bsd-li...@bsdforge.com wrote: Where can I get that information? Where was it sent? Why am I not allowed to view it? Sounds to me like the kernel ring buffer is now too small for all the early boot messages? OK more investigation indicates that bumping kern.msgbufsize will return the missing bits. Maybe this is what you were trying to tell me. ;) Anyway. Anyone know why was this tunable reduced? I don't experience this on RELENG_8, or 11-CURRENT. FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info expected. :( Thanks for the reply, Brandon. --Chris -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ 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 ___ 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 Try adding the sysctl to your loader.conf so it is set earlier Thank you for the reply, Allan. I bumped kern.msgbufsize quite a bit within loader.conf. That's how I discovered that that tunable worked. But then needed to eek it down, until I found the actual top of the output -- had to bounce the box quite a few times. :P I don't think the size was reduced, you may just have a lot of messages. ODD. Because running RELENG_8, or 11-CURRENT on the same hardware, and yes, with BOOT_VERBOSE VERBOSE_LOADING. I received the entire buffer. Thanks again, Allan. --Chris -- Allan Jude ___ 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 ___ 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: dmesg seems broken
On 2014-09-29 14:22, Chris H wrote: On 09/29/2014 10:31, Chris H wrote: On Sat, Sep 27, 2014 at 7:22 PM, Chris H bsd-li...@bsdforge.com wrote: Where can I get that information? Where was it sent? Why am I not allowed to view it? Sounds to me like the kernel ring buffer is now too small for all the early boot messages? OK more investigation indicates that bumping kern.msgbufsize will return the missing bits. Maybe this is what you were trying to tell me. ;) Anyway. Anyone know why was this tunable reduced? I don't experience this on RELENG_8, or 11-CURRENT. FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info expected. :( Thanks for the reply, Brandon. --Chris -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ 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 ___ 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 Try adding the sysctl to your loader.conf so it is set earlier Thank you for the reply, Allan. I bumped kern.msgbufsize quite a bit within loader.conf. That's how I discovered that that tunable worked. But then needed to eek it down, until I found the actual top of the output -- had to bounce the box quite a few times. :P I don't think the size was reduced, you may just have a lot of messages. ODD. Because running RELENG_8, or 11-CURRENT on the same hardware, and yes, with BOOT_VERBOSE VERBOSE_LOADING. I received the entire buffer. Thanks again, Allan. --Chris -- Allan Jude Do you actually see a difference in the size of kern.msgbufsize between RELENG_8 and the RELENG_9 box that is exhibiting issues? -- Allan Jude ___ 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: dmesg seems broken
On 2014-09-29 14:22, Chris H wrote: On 09/29/2014 10:31, Chris H wrote: On Sat, Sep 27, 2014 at 7:22 PM, Chris H bsd-li...@bsdforge.com wrote: Where can I get that information? Where was it sent? Why am I not allowed to view it? Sounds to me like the kernel ring buffer is now too small for all the early boot messages? OK more investigation indicates that bumping kern.msgbufsize will return the missing bits. Maybe this is what you were trying to tell me. ;) Anyway. Anyone know why was this tunable reduced? I don't experience this on RELENG_8, or 11-CURRENT. FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info expected. :( Thanks for the reply, Brandon. --Chris -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ 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 ___ 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 Try adding the sysctl to your loader.conf so it is set earlier Thank you for the reply, Allan. I bumped kern.msgbufsize quite a bit within loader.conf. That's how I discovered that that tunable worked. But then needed to eek it down, until I found the actual top of the output -- had to bounce the box quite a few times. :P I don't think the size was reduced, you may just have a lot of messages. ODD. Because running RELENG_8, or 11-CURRENT on the same hardware, and yes, with BOOT_VERBOSE VERBOSE_LOADING. I received the entire buffer. Thanks again, Allan. --Chris -- Allan Jude Do you actually see a difference in the size of kern.msgbufsize between RELENG_8 and the RELENG_9 box that is exhibiting issues? Good question! I was afraid you'd ask me that. I was so anxious to get past this, and get all the tasks queued for this box. I entered the sysctl, and just as I hit the enter key. It hit me; I need to record the results of the value it _currently_ has -- D'OH! I'm going to be performing the same task on a nearly identical piece of hardware later this week. I'll record the value(s) (for RELENG_8, RELENG_9 11), and report back. Thanks, and sorry for having done the right thing(tm). :P --Chris -- Allan Jude ___ 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 ___ 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: capsicum and netmap ?
On Mon, Sep 29, 2014 at 08:20:08PM +0200, Luigi Rizzo wrote: On Mon, Sep 29, 2014 at 05:27:09PM +, Brooks Davis wrote: On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote: Hi, while trying the netmap-enabled libpcap library with tcpdump, i noticed it fails to return data on a kernel with capsicum (the string capability mode sandbox enabled made me suspicious, and removing the cap_*() calls from tcpdump.c seems to make things work again). Would anyone be able to point me what should be done in the netmap kernel module to make it work with capsicum ? I am sure the cambridge folks are very interested in this :) Without knowing what modifications have been made to libpcap, it's hard to say what you need to change, but the short version is that once cap_enter is called, you must not attempt to open any file handles as that's won't work. I can't think of any other likely cause. Are all the returns of all open(), socket(), etc calls checked? Hi Brooks, thanks for the feedback. The change (attached, with some debugging code; it dates back to december and i am trying to upstream it into FreeBSD now) is a set of methods called to open, dispatch and inject packets. In practice that means that either opening files must come earlier, or a singling mechanism needs to be added to tcpdump and libpcap to tell tcpdump not to enter capability mode when using netmap. The nm_open() (which includes open and mmap) occurs before the cap_enter() call, and poll() works fine until we do the cap_enter()/cap_sandboxed() calls. I was wondering whether I should somewhat annotate the file descriptor (in the netmap kernel module) indicating that it is right to access it after cap_enter(). poll() returns 1 and errno=0 when polling for POLLIN on the netmap file descriptor, while it should return 0 (there is no traffic queued). I haven't investigated in detail but it almost looks like the underlying netmap_poll() in the device driver is not called. Ah, that's it. The problem is that we're limiting the pcap file descriptors to CAP_READ. It looks like you'd need to add CAP_EVENT to that list. Look for cap_rights_init and cap_rights_limit pairs to find the right place(s) to modify. -- Brooks pgpi18qJY9oZD.pgp Description: PGP signature
Re: Looping during boot-up process in FreeBSD-11 current
On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | |Regards |Steve = Another data point. I just downloaded the image: FreeBSD-10.1-BETA3-i386-disc1 The looping occurs also with that CD. Perhaps this is not caused by a recent change? ___ 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: capsicum and netmap ?
On Mon, Sep 29, 2014 at 06:53:08PM +, Brooks Davis wrote:
On Mon, Sep 29, 2014 at 08:20:08PM +0200, Luigi Rizzo wrote:
...
The nm_open() (which includes open and mmap) occurs before the
cap_enter() call, and poll() works fine until we do the
cap_enter()/cap_sandboxed() calls.
I was wondering whether I should somewhat annotate the file descriptor
(in the netmap kernel module) indicating that it is right to access it
after cap_enter(). poll() returns 1 and errno=0
when polling for POLLIN on the netmap file descriptor,
while it should return 0 (there is no traffic queued).
I haven't investigated in detail but it almost looks like the
underlying netmap_poll() in the device driver is not called.
Ah, that's it. The problem is that we're limiting the pcap file
descriptors to CAP_READ. It looks like you'd need to add CAP_EVENT to
that list. Look for cap_rights_init and cap_rights_limit pairs to find
the right place(s) to modify.
The following works for me with the netmap file descriptor,
but I am not sure if it is too tight or too loose.
Also I don't understand why regular bpf did not need CAP_EVENT
(I presume it worked correctly or people would have complained ?)
cheers
luigi
Index: ../../contrib/tcpdump/tcpdump.c
===
--- ../../contrib/tcpdump/tcpdump.c (revision 269180)
+++ ../../contrib/tcpdump/tcpdump.c (working copy)
@@ -1486,7 +1486,7 @@
if (RFileName == NULL VFileName == NULL) {
static const unsigned long cmds[] = { BIOCGSTATS };
- cap_rights_init(rights, CAP_IOCTL, CAP_READ);
+ cap_rights_init(rights, CAP_IOCTL, CAP_READ, CAP_EVENT);
if (cap_rights_limit(pcap_fileno(pd), rights) 0
errno != ENOSYS) {
error(unable to limit pcap descriptor);
@@ -1519,7 +1519,7 @@
if (p == NULL)
error(%s, pcap_geterr(pd));
#ifdef __FreeBSD__
- cap_rights_init(rights, CAP_SEEK, CAP_WRITE);
+ cap_rights_init(rights, CAP_SEEK, CAP_WRITE, CAP_EVENT);
if (cap_rights_limit(fileno(pcap_dump_file(p)), rights) 0
errno != ENOSYS) {
error(unable to limit dump descriptor);
@@ -1662,7 +1662,7 @@
if (pd == NULL)
error(%s, ebuf);
#ifdef __FreeBSD__
- cap_rights_init(rights, CAP_READ);
+ cap_rights_init(rights, CAP_READ, CAP_EVENT);
if (cap_rights_limit(fileno(pcap_file(pd)),
rights) 0 errno != ENOSYS) {
error(unable to limit pcap
descriptor);
___
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: Looping during boot-up process in FreeBSD-11 current
On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | |Regards |Steve = Yet another data point (actually two data points). I had an older STABLE image sitting around. FreeBSD-10.0-STABLE-i386-20140712-r268571-disc1 The looping occurs also with that CD. And, finally, the looping does not occur with 10.0-RELEASE. This release seems to be able to recover from the timeouts. So that should put a time bracket on the issue, roughly the first half of 2014. ___ 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: Looping during boot-up process in FreeBSD-11 current
Hi Mike, On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote [...] So that should put a time bracket on the issue, roughly the first half of 2014. can you boot 271146? Just buildkernel and installkernel. Thank you. BR, -- José Pérez Arauzo ___ 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: Call for FreeBSD 2014Q3 (July-September) Status Reports
Reminder: the deadline for 2014Q3 status reports is just over a week away! Thanks, Ben (on behalf of monthly@) On Tue, 2 Sep 2014, Ed Maste wrote: Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is October 7, for work done in July through September. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at mont...@freebsd.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2014Q3 reports! Thanks, Ed (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-01-2014-03.html [4] http://www.freebsd.org/news/status/report-2014-04-2014-06.html ___ 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
[CFT] alc(4) QAC AR816x/AR817x ethernet controller support
Hi, I've added support for QAC AR816x/AR817x ethernet controllers. It passed my limited testing and I need more testers. You can find patches from the following URLs. http://people.freebsd.org/~yongari/alc/pci.quirk.diff and http://people.freebsd.org/~yongari/alc/alc.diff.20140930 pci.qurik.diff is to workaround silicon bug of AR816x. Without it MSI/MSIX interrupt wouldn't work. If you just want to use legacy INTx interrupt you don't have to apply it but you have to tell alc(4) not to use MSI/MSIX interrupt with tunables( hw.alc.msi.disable and hw.alc.msix_disable). alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 and E2200 controllers. It supports all hardware features except RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x controllers please test and report how the diff works for you. Thanks. ___ 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
vt_suspend / vt_resume
I think that currently vt_suspend / vt_resume are called at quite unsuitable times. For example, vt_suspend performs a vt switch which requires cooperation from an X server, but that could be problematic given that some devices may already be suspended. I believe that it is better to do what sc(4) does and use power_suspend / power_resume event handlers instead of device_suspend / device_resume methods. power_suspend event is posted when a kernel has not entered any special state yet. What do you think? -- Andriy Gapon ___ 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
