CURRENT is broken on 32 bit architectures for kernels with KTR enabled (r244445)
Hello, Current. cc -c -O2 -pipe -fno-strict-aliasing -march=geode -std=c99 -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/data/src/sys -I/data/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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror /data/src/sys/i386/i386/trap.c cc1: warnings being treated as errors In file included from /data/src/sys/i386/i386/trap.c:1136: /data/src/sys/i386/i386/../../kern/subr_syscall.c: In function 'syscallenter': /data/src/sys/i386/i386/../../kern/subr_syscall.c:80: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /data/src/sys/i386/i386/../../kern/subr_syscall.c:154: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] It was introduced by r25, as it added new code (KTR_START4 and KTR_STOP4) at lines 80 and 154. -- // Black Lion AKA Lev Serebryakov ___ 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: clang Failed assertion after the clang 3.2 RELEASE import
On 2012-12-26 00:13, Sam Fourman Jr. wrote: for whatever reason, I get a Failed assertion error if I add a user to the wheel group... but if I do not add to the wheel group all is fine.. : /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:698: Failed assertion: "((uintptr_t)ptr - ((uintptr_t)run + (uintptr_t)bin_info->reg0_offset)) % bin_info->reg_interval == 0" This is a bug in pw(8), introduced in r242349. It tries to reallocf(3) a pointer which is in the middle of a block malloc'd in getgrent, somewhere. How this can have ever worked properly is beyond me. :-) In any case, for now, it is probably easiest to downgrade usr.sbin/pw to r242348, and rebuild pw. Valgrind says the following: ==22014== Memcheck, a memory error detector ==22014== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==22014== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==22014== Command: /usr/obj/usr/src/usr.sbin/pw/pw useradd tester666 -G wheel -s /bin/tcsh -m -d /home/tester666 ==22014== ==22014== Invalid free() / delete / delete[] / realloc() ==22014==at 0x35367: realloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==22014==by 0x17BD26: reallocf (reallocf.c:37) ==22014==by 0x804DD22: pw_user (pw_user.c:761) ==22014==by 0x804A91A: main (pw.c:230) ==22014== Address 0x800534 is 20 bytes inside a block of size 1,024 alloc'd ==22014==at 0x346BB: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==22014==by 0x141C3C: ??? (getgrent.c:689) ==22014==by 0x141C01: getgrnam (getgrent.c:745) ==22014==by 0x804C268: pw_user (pw_user.c:251) ==22014==by 0x804A91A: main (pw.c:230) ==22014== ==22014== Invalid free() / delete / delete[] / realloc() ==22014==at 0x34DA7: free (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==22014==by 0x17BD40: reallocf (reallocf.c:46) ==22014==by 0x804DD22: pw_user (pw_user.c:761) ==22014==by 0x804A91A: main (pw.c:230) ==22014== Address 0x800534 is 20 bytes inside a block of size 1,024 alloc'd ==22014==at 0x346BB: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==22014==by 0x141C3C: ??? (getgrent.c:689) ==22014==by 0x141C01: getgrnam (getgrent.c:745) ==22014==by 0x804C268: pw_user (pw_user.c:251) ==22014==by 0x804A91A: main (pw.c:230) ==22014== ==22014== Invalid write of size 4 ==22014==at 0x804DD2C: pw_user (pw_user.c:764) ==22014==by 0x804A91A: main (pw.c:230) ==22014== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22014== ==22014== ==22014== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==22014== Access not within mapped region at address 0x8 ==22014==at 0x804DD2C: pw_user (pw_user.c:764) ==22014==by 0x804A91A: main (pw.c:230) ==22014== If you believe this happened as a result of a stack ==22014== overflow in your program's main thread (unlikely but ==22014== possible), you can try to increase the size of the ==22014== main thread stack using the --main-stacksize= flag. ==22014== The main thread stack size used in this run was 16777216. ==22014== ==22014== HEAP SUMMARY: ==22014== in use at exit: 41,052 bytes in 57 blocks ==22014== total heap usage: 351 allocs, 295 frees, 526,854 bytes allocated ==22014== ==22014== LEAK SUMMARY: ==22014==definitely lost: 23 bytes in 2 blocks ==22014==indirectly lost: 16 bytes in 1 blocks ==22014== possibly lost: 0 bytes in 0 blocks ==22014==still reachable: 41,013 bytes in 54 blocks ==22014== suppressed: 0 bytes in 0 blocks ==22014== Rerun with --leak-check=full to see details of leaked memory ==22014== ==22014== For counts of detected and suppressed errors, rerun with: -v ==22014== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 1) ___ 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: [RFC/RFT] calloutng
On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: > Experiments with dummynet shown ineffective support for very short > tick-based callouts. New version fixes that, allowing to get as many > tick-based callout events as hz value permits, while still be able to > aggregate events and generating minimum of interrupts. > > Also this version modifies system load average calculation to fix some > cases existing in HEAD and 9 branches, that could be fixed with new > direct callout functionality. > > http://people.freebsd.org/~mav/calloutng_12_17.patch > > With several important changes made last time I am going to delay commit > to HEAD for another week to do more testing. Comments and new test cases > are welcome. Thanks for staying tuned and commenting. FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a try on sparc64 and it at least survives a buildworld there. However, with the patched kernels, buildworld times seem to increase slightly but reproducible by 1-2% (I only did four runs but typically buildworld times are rather stable and don't vary more than a minute for the same kernel and source here). Is this an expected trade-off (system time as such doesn't seem to increase)? Is there anything specific to test? Marius ___ 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: cpufreq not working as module on i386/amd64
I was cleaning up hard drive and found these old logs. Anyway I added some printf() and saw the process failed at device_find_child(..., "acpi_perf", ...) of est_acpi_info() i.e. it cannot find acpi_perf device. devinfo did confirmed the absence of acpi_perf. Comparing the dmesgs revealed the main difference: IST (i-state?) OEM tables in SSDT seems not loaded if cpufreq was not compiled into kernel, as it shows below. Before I diving into the ACPI part, can anyone familiar with how ACPI works shed me some light? ->8->8->8- % diff -bu cpufreq-nb.log cpufreq-no.log ... @@ -158,17 +158,11 @@ acpi0: Power Button (fixed) cpu0: Processor \\_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 -ACPI: SSDT 0xbfd8dc98 00223 (v01 PmRef Cpu0Ist 3000 INTL 20051117) -ACPI: Dynamic OEM Table Load: -ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 3000 INTL 20051117) ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 3001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00537 (v01 PmRef Cpu0Cst 3001 INTL 20051117) cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 cpu1: on acpi0 -ACPI: SSDT 0xbfd8ce18 001CF (v01 PmRefApIst 3000 INTL 20051117) -ACPI: Dynamic OEM Table Load: -ACPI: SSDT 0 001CF (v01 PmRefApIst 3000 INTL 20051117) ACPI: SSDT 0xbfd8df18 0008D (v01 PmRefApCst 3000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0008D (v01 PmRefApCst 3000 INTL 20051117 On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best wrote: > On Sat Jan 29 11, Jia-Shiun Li wrote: >> Hi all, >> >> I found that cpufreq driver failed to attach when compiled as module >> and loaded, but it works fine when compiled into kernel. I am >> wondering if this is due to some kind of limitation, or can be fixed? > > that's rather odd. for me neither the module nor the kernel code works, since > my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium mobile > cpus seem to be supported. > > maybe you can add some printf's to est.c:est_get_info() to identify at which > point error gets set. also you might want to make > > "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr); > > non-conditional. maybe the output differy in kernel/module mode. > > cheers. > alex > >> >> Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop >> (amd64). Both got the same result. dmesg of T4200 attached. >> >> kldload module: >> ->8->8->8- >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >> device_attach: est0 attach returned 6 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >> -8<-8<-8<- >> (repeated 6 times, kldload retries?) >> >> compiled into kernel: >> ->8->8->8- >> ... >> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 >> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >> isa_probe_children: probing PnP devices >> coretemp0: on cpu0 >> coretemp0: Setting TjMax=104 >> p4tcc0: on cpu0 >> est0: on cpu0 >> coretemp1: on cpu1 >> coretemp1: Setting TjMax=104 >> p4tcc1: on cpu1 >> est1: on cpu1 >> Device configuration finished. >> procfs registered >> ... >> -8<-8<-8<- >> >> Jia-Shiun. > > > -- > a13x ___ 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"
