Re: About pmap_mapdev() pmap_unmapdev()
Hi Konstantin,
I tested your patch. It was no problem.
Thank you for your kind correspondence.
Regards,
Kohji Okuno
On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote:
Hi, Konstantin,
At the end of the mail is commit candidate. I did not even compiled this.
Can you test and report back, please ?
Could you check the following?
(1) should use kernel_pmap-pm_stats.resident_count
^^^
I'm sorry. My patch was wrong.
As well as mine.
(2) should use pmap_resident_count_inc() in amd64.
Correct.
I will test, later.
In addtion, I have one question.
In current and 10-stable, is vm_map_delete() called by kva_free()?
No, kva_free() only releases the vmem backing, leaving the page
tables intact. This is why I only did the stable/9 patch.
If vm_map_delete() is called, this fix is needed in current and
10-stable, I think.
Updated patch below.
Index: amd64/amd64/pmap.c
===
--- amd64/amd64/pmap.c(revision 272506)
+++ amd64/amd64/pmap.c(working copy)
@@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
pa = trunc_page(pa);
for (tmpsize = 0; tmpsize size; tmpsize += PAGE_SIZE)
pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode);
+ PMAP_LOCK(kernel_pmap);
+ pmap_resident_count_inc(kernel_pmap, OFF_TO_IDX(size));
+ PMAP_UNLOCK(kernel_pmap);
pmap_invalidate_range(kernel_pmap, va, va + tmpsize);
pmap_invalidate_cache_range(va, va + tmpsize);
return ((void *)(va + offset));
Index: i386/i386/pmap.c
===
--- i386/i386/pmap.c (revision 272506)
+++ i386/i386/pmap.c (working copy)
@@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in
size = roundup(offset + size, PAGE_SIZE);
pa = pa PG_FRAME;
- if (pa KERNLOAD pa + size = KERNLOAD)
+ if (pa KERNLOAD pa + size = KERNLOAD) {
va = KERNBASE + pa;
- else
+ } else {
va = kmem_alloc_nofault(kernel_map, size);
+ PMAP_LOCK(kernel_pmap);
+ kernel_pmap-pm_stats.resident_count += OFF_TO_IDX(size);
+ PMAP_UNLOCK(kernel_pmap);
+ }
if (!va)
panic(pmap_mapdev: Couldn't alloc kernel virtual memory);
___
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: pkg/ports system terribly messed up?
Am 02.10.2014 um 04:40 schrieb Chuck Burns: On Wednesday, October 01, 2014 7:48:08 AM Rainer Hurling wrote: Am 01.10.2014 um 05:44 schrieb Chuck Burns: On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote: Hello. I just made the last update of the ports yesterday (I use portmaster -da performing this task) and obviously or superficially everything went all right. snip It's portmaster actually. While it -usually- works great, I've noticed that occassionally it loops like that. kill the script, upgrade the port that is looping. Because it seems that I have the same problem as Oliver: What script you are talking about? That usually fixes it. portmaster is just a (not-so-)simple shell script. Kill portmaster (CTRL-C a few times) then build the offending port with make make deinstall reinstall clean Thanks for your answer. I tried it, but unfortunately, this does not change my problems with using portmaster for updating ports. ___ 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: pkg/ports system terribly messed up?
Am 01.10.2014 um 22:17 schrieb NGie Cooper: On Mon, Sep 29, 2014 at 11:13 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Hello. I just made the last update of the ports yesterday (I use portmaster -da performing this task) and obviously or superficially everything went all right. I'm running on the boxes in question most recent CURRENT. On one system, a subsequent start of updating ports starts to freak out when updateing lang/gcc: it loops over and over on some ports already updated, especially devel/binutils, but the port looping on isn't specific and varies. On every CURRENT box I tried this morning to update the ports again, I find this frsutrating message (depends on installation, but it seems in principal the same, only the affected ports in dependency chain varies): Are you using portmaster? If so, it might be fallout from r272282. Cheers, Yup, after defining setenv PORTSDIR /usr/ports my problems, described on my mail in this thread from 30th September, completely went away. Thanks for this hint. It helps a lot! Regards, Rainer Hurling ___ 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: NFS installworld failures
In article 54320e76.3010...@pinyon.org, rcar...@pinyon.org writes: Am I the only one attempting to maintain a local cluster using a buildworld server and mounting /usr/src/ and /usr/obj/ via NFS? Nope. I intermittently run into installworld failures, usually in sys/boot/i386 but occasionally e.g. cddl/lib where the install targets are apparently out of date, and want to be rebuilt, which doesn't work with a read-only mount. I've seen errors like this on 9.3, and was somewhat concerned about 9.3's NFS implementation as a result. Never on 9.1 or 9.2. (Sorry, I don't have any 10.0 systems yet -- we'll go to 10.1 after Christmas.) I am wondering if it's at all related to my issue with bonnie++ failing when run over NFS on a 9.3 client. (I haven't tracked this down yet.) Is this a reasonable thing to expect to work, or maybe not? It's supposed to work. -GAWollman ___ 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: i915 driver update testing
On Fri, Oct 03, 2014 at 08:02:59PM +0300, Konstantin Belousov wrote: K Please find at the K https://kib.kiev.ua/kib/drm/i915.1.patch K a patch which provides some updates to the i915 driver. At large, this K is import of the batch of Linux commits, and as such, it is interesting K mostly as attempt to restart the race to get us more up to date Linux code K imported. It might provide some bug fixes, most likely for IvyBridge. K Interesting from the development PoV is the update of the GEM i/o ioctl K code path to mimic Linux code structure. K K I am asking _only_ for reports of regressions with the patch applied, K comparing with the code which is currently in HEAD. I will not debug K any existing bugs, my goal right now is to commit this update, which is K needed for further work. I.e., only when you get an issue with the patch K applied, but cannot reproduce the problem without the patch, please K prepare a bug report. Thinkpad X1 Carbon: screen black after X starts. -- Totus tuus, Glebius. ___ 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 Alexander, On Sun, 05 Oct 2014 01:57:13 +0400, Alexander V. Chernikov wrote On 01.10.2014 02:02, Mike. wrote: On 9/30/2014 at 7:25 PM José Pérez Arauzo wrote: |[snip] |Try the 271146, |[snip] = This might be related with r271207. Can you try r271206 (or any recent HEAD with reverted r271207) ? Yes, it actually boots with head and ahci.[c|h] from r271206, so we can safely assume r271207 (the dev-ch change) is not working on some hardware. Mike, can you please confirm, just to be sure? Now, in case Mike (or anyone with the same problem) confirms, what can we do to have it fixed? 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: Need help debugging yacc test failure in CURRENT
On Thu, Oct 2, 2014 at 2:23 AM, Craig Rodrigues rodr...@freebsd.org wrote: Hi, I have managed to eliminate all the test failures from /usr/tests in CURRENT except for one failure. See: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/8/testReport/ I can reproduce the failure by doing the following: mkdir /tmp/x cd /tmp/x /usr/tests/usr.bin/yacc/yacc_tests usr.bin.yacc.yacc_tests.main I then get a core file: /tmp/x/test/yacc.core Thomas E. Dickey submitted a patch which fixes the test. I committed the patch: http://lists.freebsd.org/pipermail/svn-src-all/2014-October/092553.html -- Craig ___ 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: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]
Am Sun, 5 Oct 2014 15:20:20 -0700 Mark Johnston ma...@freebsd.org schrieb: On Sun, Oct 05, 2014 at 11:18:55AM +0200, O. Hartmann wrote: Am Sun, 5 Oct 2014 05:36:57 +0400 Arseny Nasokin eir...@gmail.com schrieb: Mark, Thank you for patch, I encounter same error and this patch works for me. ✪ -- Eir Nym On 5 October 2014 04:43, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/14 15:58, Mark Johnston wrote: On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote: On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: Recent sources (Revision: 272529) fail to compile: [...] cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- --- libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for I'm confused by this message. Are you building with -DNO_CLEAN? Do you have anything in make.conf or src.conf, especially anything that's changed since libctf was rebuilt? You might try rebuilding libctf with $ cd /usr/src $ make -C cddl/lib/libctf clean all but I'm not sure why ld is ignoring the existing libctf.so. The failure is coming while building the lib32 compat libraries. Are we not currently building a lib32 libctf.so? No, we do. One thing I've noticed is that cddl/lib is built after lib/ when compiling 32-bit libs, whereas cddl/lib is built first when building natively. Sorry, that's not even true. I misread a part of Makefile.inc1. I'm still not able to reproduce the problem, but it seems that the patch here is appropriate: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff Oliver, could you give this a try? Even poudriere can't get past this one. Sorry, it was incomplete. It's been updated: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff ___ 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 After some minor corrections to the patch (the patched original sources seem not to match most recent CURRENT sources as of revision 272562), buildworld works again as expected. Thank you very much. Committed as r272576. Sorry for the breakage. The patch was generated from my git tree, which didn't contain r272484, so the patch wouldn't apply to svn cleanly. I'll be sure to check that next time. :( Thanks, -Mark ___ 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 ... everything is shiny here ... Oliver signature.asc Description: PGP signature
Re: NFS installworld failures
On Sun, 2014-10-05 at 20:37 -0700, Russell L. Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am I the only one attempting to maintain a local cluster using a buildworld server and mounting /usr/src/ and /usr/obj/ via NFS? I intermittently run into installworld failures, usually in sys/boot/i386 but occasionally e.g. cddl/lib where the install targets are apparently out of date, and want to be rebuilt, which doesn't work with a read-only mount. Is this a reasonable thing to expect to work, or maybe not? Every system in the cluster has got ntpd functioning correctly. Here's today's 2nd blocker: === cddl/lib/drti (install) /usr/bin/cc -O2 -pipe - -I/usr/src/cddl/lib/drti/../../../sys/cddl/compat/opensolaris - -I/usr/src/cddl/lib/drti/../../../cddl/compat/opensolaris/include - -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/head - -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libctf/common -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/lib/drti/../../../sys/cddl/contrib/opensolaris/uts/common -DPIC -fpic -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-unknown-pragmas -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c -o drti.o error: unable to open output file 'drti.o': '' Best regards, Russell -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUMg52AAoJEFnLrGVSDFaEwrgP+wReSDvMhWBH25l3aOkYJbpx CXl0x/a4eSSS38UOa46KIUTFnx68XKElqUFi8eHRcSXe0L0pCNq1UQw5Qrp5Uaj0 d5GaKpkm3IP/IZtTzIbh60N2oc8einYXHWP5LsDx3Au4b4y0p2CX7ApQr61H7n5G 6E8XJ8lSrS13NBI0RvWAVY54+DzuLeoubvpJqMoodb01YToY/e3HHn/K5gbmF/x8 JK5tsW1XvGsRFxT/NLDKumuaf0JQLrRHD9DjiKTELAvtLdg7k4G4yf0BmobojUrB E1RajK8HppmyP0S2UvZMisMfEZ3radl0PKPbk/cCLMLWC1kiLWyZ70OSZ/537umY 94fF0irY0TmnsHENpQmtDB7OwPFb80bn9ztuEo54PI8j2rnSuvB4FNkHNTuTtkAi JY7V3cu2yjVbuqw7ailutc5We7jEurS+5Gi72KEL9pLs22WFtmtHfAgrZuRE4Ror RudQpszK4TIljNgh9tF3g4nMMiabKwHq4Ws2BqrZ3wJCl8tgLdetR/hGHR325dTL CnLp8YdoU6gbfbTBWqQrnmV02VMOinK+ZAAy7ATufQhy9tVIwai1gz27ou4tkkmb i0vDqv+jQoP7S6/4LfGkBJQ53X1O4L+zRYJ53YCfoH7kM4g4tNbvCDBYYG/EFU3+ 2EDMkHl04WIJvg1VcaT1 =N1ME -END PGP SIGNATURE- It was mentioned in another reply, but maybe overlooked... the contents of /etc/make.conf and /etc/src.conf must be identical between the systems where you do buildworld and installworld. For example, if you buildworld using WITHOUT_CTF and installworld without using that same setting, it will try to build the missing pieces at install time. -- Ian ___ 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: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support
Dnia 2014-10-06, o godz. 11:32:13 Yonghyeon PYUN pyu...@gmail.com napisał(a): On Fri, Oct 03, 2014 at 09:29:46PM +0200, Dariusz Wierzbicki wrote: Dnia 2014-10-02, o godz. 14:07:30 Yonghyeon PYUN pyu...@gmail.com napisał(a): On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote: On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote: 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. http://people.freebsd.org/~yongari/alc/pci.quirk.diff http://people.freebsd.org/~yongari/alc/alc.diff.20141001 Patch updated to address link establishment issue. http://people.freebsd.org/~yongari/alc/alc.diff.20141002 Patch updated again to correct wrong lock assertion. Hi ! Thanks for your work ! Are your patches only for current ? I tried on 10 stable. No, it should be applied to stable/10 as well. I intentionally didn't include additional diff for MAC statistics which will not work on stable/10 and stable/9 due to if_inc_counter changes made in HEAD. I tried to apply the diff again against stable/10 and it succeeded with minor fuzz and offset differences. Thanks for your answer. I tried again and I succeeded. I used --ignore-whitespace option with patch command and the alc.diff applied successfully. My system: dw@dw:~ % uname -a FreeBSD dw 10.1-RC1 FreeBSD 10.1-RC1 #1 r272477M: Fri Oct 3 20:48:05 CEST 2014 dw@dw:/usr/obj/usr/src/sys/DW amd64 [...] I applied that part manually. Compiled and rebooted system. dmesg | grep alc : alc0: could not disable Rx/Tx MAC(0x4000cb20)! alc0: reset timeout(0x4000cb20)! alc0: could not disable Rx/Tx MAC(0x4000cb20)! ^ I'm more worried about MAC reset and master reset timeout shown below. The MAC reset timeout makes me wonder how this can happen since driver just checks bit 0 and bit 1, the low nibble of the register value can't be 0. alc0: link state changed to UP alc0: could not disable Rx/Tx MAC(0x4000cb20)! alc0: Qualcomm Atheros AR8161 Gigabit Ethernet port 0xd000-0xd07f mem 0xf720-0xf723 irq 18 at device 0.0 on pci3 alc0: reset timeout(0x4000cd00)! I think this also can't happen since driver checks bit[0-3], the low byte should be non-zero when the timeout triggers. alc0: 11776 Tx FIFO, 12032 Rx FIFO miibus0: MII bus on alc0 alc0: Ethernet address: 74:d4:35:91:32:04 [...] If you need other data or more testing, let me know. Do you have any local changes in alc(4)? As I said, the diff could be applied to stable/10 without any manual modification. Thanks for testing! You were right. I had a minor local change in if_alc.c file. Now everything seems to work: dw@dw:~ % dmesg | grep alc Preloaded elf obj module /boot/kernel/if_alc.ko at 0x81bd6b38. alc0: Atheros AR8161 PCIe Gigabit Ethernet port 0xd000-0xd07f mem 0xf720-0xf723 irq 18 at device 0.0 on pci3 alc0: PCI device revision : 0x0010 alc0: Chip id/revision : 0xc002 alc0: AR816x revision : 0x2 alc0: 11776 Tx FIFO, 12032 Rx FIFO alc0: Read request size : 512 bytes. alc0: TLP payload size : 128 bytes. alc0: MSIX count : 16 alc0: MSI count : 16 alc0: attempting to allocate 1 MSI-X vectors (16 supported) alc0: using IRQ 268 for MSI-X alc0: Using 1 MSIX message(s). miibus0: MII bus on alc0 alc0: bpf attached alc0: Ethernet address: 74:d4:35:91:32:04 alc0: link state changed to UP alc0: Atheros AR8161 PCIe Gigabit Ethernet port 0xd000-0xd07f mem 0xf720-0xf723 irq 18 at device 0.0 on pci3 alc0: 11776 Tx FIFO, 12032 Rx FIFO alc0: Using 1 MSIX message(s). miibus0: MII bus on alc0 alc0: Ethernet address: 74:d4:35:91:32:04 alc0: link state changed to UP Thanks again for the patches and for your work ! Darek ___ 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] nscd
On Monday, September 29, 2014 11:40:52 PM David Shane Holden wrote:
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.
Cute. This codebase likes to use memcpy() way too much for simple assignments
Which can lead to bugs like this. It also likes to do this:
size = strlen(name) + 1;
foo = calloc(size, 1);
assert(foo != NULL);
strlcpy(foo, name, size); // or memcpy()
instead of the simpler:
foo = strdup(name);
assert(foo != NULL);
I have a patch to remove various memcpy's trying to copy structures as well as
un-expand several of the strdup() calls if you'd care to test it. These
changes didn't cover any other memcpy() misuse.
Index: cachelib.c
===
--- cachelib.c (revision 272657)
+++ cachelib.c (working copy)
@@ -485,7 +485,7 @@
assert(retval != NULL);
assert(params != NULL);
- memcpy(retval-params, params, sizeof(struct cache_params));
+ retval-params = *params;
retval-entries = calloc(1,
sizeof(*retval-entries) * INITIAL_ENTRIES_CAPACITY);
@@ -522,7 +522,6 @@
struct cache_entry_params const *params)
{
int policies_size;
- size_t entry_name_size;
struct cache_common_entry_ *new_common_entry;
struct cache_mp_entry_ *new_mp_entry;
@@ -552,7 +551,6 @@
the_cache-entries = new_entries;
}
- entry_name_size = strlen(params-entry_name) + 1;
switch (params-entry_type)
{
case CET_COMMON:
@@ -560,16 +558,12 @@
sizeof(*new_common_entry));
assert(new_common_entry != NULL);
- memcpy(new_common_entry-common_params, params,
- sizeof(struct common_cache_entry_params));
- new_common_entry-params =
- (struct cache_entry_params *)new_common_entry-common_params;
+ new_common_entry-common_params.cep = *params;
+ new_common_entry-params = new_common_entry-common_params.cep;
- new_common_entry-common_params.cep.entry_name = calloc(1,
- entry_name_size);
+ new_common_entry-common_params.cep.entry_name =
+ strdup(params-entry_name);
assert(new_common_entry-common_params.cep.entry_name != NULL);
- strlcpy(new_common_entry-common_params.cep.entry_name,
- params-entry_name, entry_name_size);
new_common_entry-name =
new_common_entry-common_params.cep.entry_name;
@@ -614,16 +608,12 @@
sizeof(*new_mp_entry));
assert(new_mp_entry != NULL);
- memcpy(new_mp_entry-mp_params, params,
- sizeof(struct mp_cache_entry_params));
- new_mp_entry-params =
- (struct cache_entry_params *)new_mp_entry-mp_params;
+ new_mp_entry-mp_params.cep = *params;
+ new_mp_entry-params = new_mp_entry-mp_params.cep;
- new_mp_entry-mp_params.cep.entry_name = calloc(1,
- entry_name_size);
+ new_mp_entry-mp_params.cep.entry_name =
+ strdup(params-entry_name);
assert(new_mp_entry-mp_params.cep.entry_name != NULL);
- strlcpy(new_mp_entry-mp_params.cep.entry_name,
params-entry_name,
- entry_name_size);
new_mp_entry-name = new_mp_entry-mp_params.cep.entry_name;
Re: NFS installworld failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ian, On 10/06/14 08:29, Ian Lepore wrote: On Sun, 2014-10-05 at 20:37 -0700, Russell L. Carter wrote: [...] I intermittently run into installworld failures, usually in sys/boot/i386 but occasionally e.g. cddl/lib where the install targets are apparently out of date, and want to be rebuilt, which doesn't work with a read-only mount. [...] It was mentioned in another reply, but maybe overlooked... the contents of /etc/make.conf and /etc/src.conf must be identical between the systems where you do buildworld and installworld. For example, if you buildworld using WITHOUT_CTF and installworld without using that same setting, it will try to build the missing pieces at install time. Ah, the make.confs differ between client and server. Ok, fix that, rm /usr/obj/usr, make -j6 buildworld buildkernel on the server. make installworld on the client: === cddl/lib/drti (install) - --- drti.o --- /usr/bin/cc -O2 -pipe - -I/usr/src/cddl/lib/drti/../../../sys/cddl/compat/opensolaris - -I/usr/src/cddl/lib/drti/../../../cddl/compat/opensolaris/include - -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/head - -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libctf/common -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/lib/drti/../../../sys/cddl/contrib/opensolaris/uts/common -DPIC -fpic -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-unknown-pragmas -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c -o drti.o error: unable to open output file 'drti.o': '' 1 error generated. Ok, make installworld on the server, which succeeds. This is reinstalling r272576M. Try again to make installworld on the client, in case the server installworld perturbed the build; same failure. Ok, kill off /usr/obj/usr again, and I restrict the buildworld to one thread, which is interminable, but whatever. make installworld then succeeds on the client. (ntpd is functioning as it should on both client and server) As I mentioned in another message, this sort of thing happened all the time in June, then for a couple of months the NFS installs were solid, and now they are flaky again. BR, Russell (The server filesystems are error-free zfs, as is the client) -- Ian -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUMw3sAAoJEFnLrGVSDFaErSoP/jt2rd0bvTrw/XOiv5clA9ZL MDTZwK0srB93ygOr5ctihc3sjhtSKe57I+bm3hpiPpUBj4Y+epOdRFAZnEG5LECq qDLi7rWGFsnrUKhBPkmFz4YzZbXlSAqBbmqQ2VbUP921Wu1bD09+0ETPWZyJV6Bb c2+L+Gl+LclE7/cksECMYgUqFdzwsR5zi4xpKkhXmQ1CCrbZMRTfMWJDQkl77KW6 V4ZgE53jtZg1qHSMXit9ay1u+pkhrytDFPBtqM8h2ukUifiH6xP+utNfq7O3pLXk xk/N9OhPCDd/SjofyH0SSSA5l7ka/0NEfxBimTfAoOMZp/3r8T8NS1x/iPgoAw3k 2rad74BlmrlSCwAQVNe5UMDJO2BZEbJ9a90js7naAWA6NG72Wi1s8HUA5JECVTfg Kx+tkm7+SSiC7myCNU1/lGTBdAHf0ZJ9I37Y3gFYK299Ayr+lqqRcxp4ujE4FhXS WSX9DLlctGfaFf0PCtywMuWT8+5F7vMqoFhlTTBlCGbfjMu0ZkB/hiJT0ksKcjOs uasflmxewbffGqykp7XWQa8SUNcFIUj2lBgPqQRLf2I+3kBbtHe6nZW1p53/anVL l+T78Gpp9wQxuVrKyJGZ0UbKYRaxqWnT3EL515oCU9W5g9pCFnqpaS541SWxDIGX dpby6I9gcik+Xi4/kJSG =4yse -END PGP SIGNATURE- ___ 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: i915 driver update testing
On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. ___ 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: i915 driver update testing
On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote: On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. Great, thank you. Please also do, from the frame 12, p *dev ___ 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
