current repeateble crash in 2 places
today current crash with loaded mpd5 1st place: ipwf_chk ipfw_check_hook pfil_run_hooks ip_output tcp_output repeated tcp_mtudisc~20 times tcp_ctlinput icmp_input ip_input swi_net intr_event_execute_handlers 2nd place flowtable_lookup flowteble_lookup_mbuf ip_output tcp_output ~ repeated tcp_mtudisc20 times tcp_ctlinput icmp_input ip_input netisr_dispatch_src ng_iface_rcvdata ng_apply_itemrepeated ng_snd_item 3 ng_pppoe_rcvdata_ether times ng_apply_item ng_snd_item ether_demux ether_input em_rxeof em_msix_rx inthr_event_execute_handlers ithread_loop ___ 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
Can't buildworld since Clang update
Hello,
I can't buildworld with Clang since the last update.
%uname -a
FreeBSD zozo.afpicl.lan 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218908M:
Mon Feb 21 09:56:35 CET 2011
r...@zozo.afpicl.lan:/usr/obj/usr/src/sys/CORE amd64
%clang -v
FreeBSD clang version 2.9 (trunk 126079) 20110220
Target: x86_64-undermydesk-freebsd9.0
Thread model: posix
%cat /etc/src.conf
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
%head /etc/make.conf
CPUTYPE?=core2
KERNCONF=CORE
CFLAGS=-O2 -pipe -march=native
NO_CPU_CFLAGS=yes
COPTFLAGS=-O2 -pipe -march=native
NO_CPU_COPTFLAGS=yes
BOOTWAIT=0
WITHOUT_PROFILE=yes
# make buildworld
[...]
=== lib/libz (obj,depend,all,install)
[...]
clang -O2 -pipe -march=native -DHAS_snprintf -DHAS_vsnprintf
-I/usr/src/lib/libz -DASMV -DNO_UNDERLINE -DSYMBOL_VERSIONING
-std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
-Wa,--noexecstack -c /usr/src/lib/libz/contrib/gcc_gvmat64/gvmat64.S
/tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now
.intel_syntax noprefix
^
/tmp/cc-VUyvc6.s:12:9: error: unknown use of instruction mnemonic
without a size suffix
mov [(rsp + 40 - 96)],rbx
^
/tmp/cc-VUyvc6.s:13:9: error: unknown use of instruction mnemonic
without a size suffix
mov [(rsp + 48 - 96)],rbp
^
/tmp/cc-VUyvc6.s:16:9: error: unknown use of instruction mnemonic
without a size suffix
mov rcx,rdi
^
/tmp/cc-VUyvc6.s:18:9: error: unknown use of instruction mnemonic
without a size suffix
mov r8d,esi
^
/tmp/cc-VUyvc6.s:21:9: error: unknown use of instruction mnemonic
without a size suffix
mov [(rsp + 56 - 96)],r12
^
/tmp/cc-VUyvc6.s:22:9: error: unknown use of instruction mnemonic
without a size suffix
mov [(rsp + 64 - 96)],r13
^
/tmp/cc-VUyvc6.s:23:9: error: unknown use of instruction mnemonic
without a size suffix
mov [(rsp + 72 - 96)],r14
^
/tmp/cc-VUyvc6.s:24:9: error: unknown use of instruction mnemonic
without a size suffix
mov [(rsp + 80 - 96)],r15
^
/tmp/cc-VUyvc6.s:26:9: error: unknown use of instruction mnemonic
without a size suffix
mov edi, [ rcx + 168]
^
/tmp/cc-VUyvc6.s:27:9: error: unknown use of instruction mnemonic
without a size suffix
mov esi, [ rcx + 188]
^
/tmp/cc-VUyvc6.s:28:9: error: unknown use of instruction mnemonic
without a size suffix
mov eax, [ rcx + 76]
^
/tmp/cc-VUyvc6.s:29:9: error: unknown use of instruction mnemonic
without a size suffix
mov ebx, [ rcx + 172]
^
/tmp/cc-VUyvc6.s:30:9: error: unknown use of instruction mnemonic
without a size suffix
cmp edi, esi
^
/tmp/cc-VUyvc6.s:32:9: error: unknown use of instruction mnemonic
without a size suffix
shr ebx, 2
^
/tmp/cc-VUyvc6.s:40:9: error: ambiguous instructions require an
explicit suffix (could be 'decb', 'decw', 'decl', or 'decq')
dec ebx
^
/tmp/cc-VUyvc6.s:41:9: error: unknown use of instruction mnemonic
without a size suffix
shl ebx, 16
^
/tmp/cc-VUyvc6.s:42:9: error: unknown use of instruction mnemonic
without a size suffix
or ebx, eax
^
/tmp/cc-VUyvc6.s:49:9: error: unknown use of instruction mnemonic
without a size suffix
mov eax, [ rcx + 192]
^
/tmp/cc-VUyvc6.s:50:9: error: unknown use of instruction mnemonic
without a size suffix
mov [(rsp + 8 - 96)], ebx
^
/tmp/cc-VUyvc6.s:51:9: error: unknown use of instruction mnemonic
without a size suffix
mov r10d, [ rcx + 164]
^
/tmp/cc-VUyvc6.s:52:9: error: unknown use of instruction mnemonic
without a size suffix
cmp r10d, eax
^
/tmp/cc-VUyvc6.s:53:9: error: unknown use of instruction mnemonic
without a size suffix
cmovnl r10d, eax
^
/tmp/cc-VUyvc6.s:54:9: error: unknown use of instruction mnemonic
without a size suffix
mov [(rsp + 16 - 96)],r10d
^
/tmp/cc-VUyvc6.s:59:9: error: unknown use of instruction mnemonic
without a size suffix
mov r10, [ rcx + 80]
^
/tmp/cc-VUyvc6.s:60:9: error: unknown use of instruction mnemonic
without a size suffix
mov ebp, [ rcx + 156]
^
/tmp/cc-VUyvc6.s:61:9: error: unknown use of instruction mnemonic
without a size suffix
lea r13, [r10 + rbp]
^
/tmp/cc-VUyvc6.s:66:10: error: unknown use of instruction mnemonic
without a size suffix
mov r9,r13
^
/tmp/cc-VUyvc6.s:67:10: error: ambiguous instructions require an
explicit suffix (could be 'negb', 'negw', 'negl', or 'negq')
neg r13
^
/tmp/cc-VUyvc6.s:68:10: error: unknown use of instruction mnemonic
without a size suffix
and r13,3
^
/tmp/cc-VUyvc6.s:74:9: error: unknown use of instruction mnemonic
without
Re: Can't buildworld since Clang update
On 2011-02-21 11:33, Olivier Smedts wrote:
I can't buildworld with Clang since the last update.
...
%cat /etc/src.conf
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Try putting these lines in /etc/make.conf instead. Unfortunately, due
to the way src.conf is read, it isn't usable for the few cases we need
to disable clang's integrated assembler, using the '-no-integrated-as'
option.
/tmp/cc-VUyvc6.s:6:1: warning: ignoring directive for now
.intel_syntax noprefix
^
In this case, you hit the one and only instance of the '.intel_syntax'
directive in the tree; this directive is not yet supported by clang's
integrated assembler.
___
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: Error building world after last clang update
On Mon, Feb 21, 2011 at 12:34 PM, Renato Botelho rbga...@gmail.com wrote:
I was trying to upgrade my 9.0-CURRENT amd64 after clang
was updated, but i got following error:
=== sys/boot/i386/cdboot (all)
=== sys/boot/i386/gptboot (all)
=== sys/boot/i386/kgzldr (all)
=== sys/boot/i386/libi386 (all)
clang -O2 -pipe -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600
-DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU
-Dalloca=__builtin_alloca
-I/usr/src/sys/boot/i386/libi386/../../common
-I/usr/src/sys/boot/i386/libi386/../btx/lib
-I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include
-I/usr/src/sys/boot/i386/libi386/../../.. -I.
-I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/
-ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99
-c /usr/src/sys/boot/i386/libi386/amd64_tramp.S
clang: warning: argument unused during compilation:
'-mpreferred-stack-boundary=2'
/tmp/cc-ohEeiE.s:35:9: error: .code32 not supported yet
.code32
^
/tmp/cc-ohEeiE.s:69:9: error: .code64 not supported yet
.code64
^
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
[1] 94534 exit 2 nice -n 15 make -j1 buildworld buildkernel
My /etc/src.conf has:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Any hints?
I read the answer for a problem like this and followed
the suggestion of add clang config lines on /etc/make.conf.
It worked fine, it's building again now.
--
Renato Botelho
___
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
Error building world after last clang update
I was trying to upgrade my 9.0-CURRENT amd64 after clang
was updated, but i got following error:
=== sys/boot/i386/cdboot (all)
=== sys/boot/i386/gptboot (all)
=== sys/boot/i386/kgzldr (all)
=== sys/boot/i386/libi386 (all)
clang -O2 -pipe -DLOADER_NFS_SUPPORT -DCOMPORT=0x3f8 -DCOMSPEED=9600
-DSMBIOS_SERIAL_NUMBERS -DLOADER_GPT_SUPPORT -DTERM_EMU
-Dalloca=__builtin_alloca
-I/usr/src/sys/boot/i386/libi386/../../common
-I/usr/src/sys/boot/i386/libi386/../btx/lib
-I/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica/include
-I/usr/src/sys/boot/i386/libi386/../../.. -I.
-I/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/
-ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99
-c /usr/src/sys/boot/i386/libi386/amd64_tramp.S
clang: warning: argument unused during compilation:
'-mpreferred-stack-boundary=2'
/tmp/cc-ohEeiE.s:35:9: error: .code32 not supported yet
.code32
^
/tmp/cc-ohEeiE.s:69:9: error: .code64 not supported yet
.code64
^
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
[1]94534 exit 2 nice -n 15 make -j1 buildworld buildkernel
My /etc/src.conf has:
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
Any hints?
--
Renato Botelho
___
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
Process timing issue
Hello,
While investigating a timing issue with one of our program, we found out
something weird: We've written a small test program that just calls
clock_gettime() a lot of times and checks that the time difference
between calls makes sense. In the end, it seems it doesn't always do.
Calling twice in a row clock_gettime() takes usually less than 1ms. But
with an average load, about 1 time in 20, more than 10ms are spent
between both calls for no apparent reason. According to our tests, when
it happens, the time between both calls can go from few milliseconds to
many seconds (our best score so far is 10 seconds :). Same goes for
gettimeofday().
To reproduce this issue, we use the small test program joined to this
mail and openssl speed test commands (usually 'openssl speed -elapsed
dsa2048'). It only appears if one of these openssl speed test run on the
same core than our test progam, so we have to start as many openssl
instances as there are cores on the test computer.
For instance:
- FreeBSD 7.3 + Core 2 duo
- FreeBSD 7.4/STABLE + Core 2 duo
- FreeBSD 8.1 + Core 2 duo
- FreeBSD 8.2-RC3 + Core 2 duo (clean setup)
- FreeBSD 9.0/CURRENT + Core 2 duo (clean setup, checked out last Friday)
On all these setups, with 2 instances of openssl speed tests, on
average, for 200*2 calls to clock_gettime(), we got about 10 pauses
of between 100 and 300ms
- FreeBSD 8.2-RC1 + Xeon W3680 (6 cores):
With 12 instances of openssl speed tests, for 1000*2 calls to
clock_gettime(), we got pauses of between 300ms and 10s.
- FreeBSD 6.3 + VIA C3:
With 1 instance of openssl, we got pauses of between 70ms and 300ms
- FreeBSD 7.3 + VIA C7:
With 1 instance of openssl, we got pauses of between 150ms and 1s
(Note: this computer may be slightly more loaded then the previous one)
For comparison purpose, we also tried on 2 Linux systems:
- Linux 2.6.32.15 (Via nano, with a bunch of services running on it):
- 1 openssl speed tests + 200 iterations: max 10ms
- 10 openssl speed tests + 200 iterations: max 44ms
- Linux 2.6 (Core i7):
- 10 openssl speed tests + 200: max 1ms
We tried setting the test program to the highest priority possible
(rtprio(REALTIME, RTP_PRIO_MAX)) and it doesn't seem to change a thing.
Does anyone know if there is a reason for this behavior ? Is there
something that can be done to improve things ?
#include sys/limits.h
#include stdio.h
#include stdint.h
#include stdlib.h
#include unistd.h
#include time.h
#include err.h
#include sysexits.h
int main(int argc, char *argv[])
{
struct timespec pre, cur;
useconds_t d, dmin, dmax, dsum;
int dweird = 0;
int i, loop;
if (argc != 2) {
fprintf(stderr, timecheck loop\n);
return EXIT_FAILURE;
}
loop = atoi(argv[1]);
dmax = dsum = 0;
dmin = UINT_MAX;
fprintf(stdout, looping %d times...\n, loop);
for (i = 0; i loop; i++) {
if (clock_gettime(CLOCK_MONOTONIC, pre) 0)
err(EX_OSERR, NULL);
if (clock_gettime(CLOCK_MONOTONIC, cur) 0)
err(EX_OSERR, NULL);
d = (cur.tv_sec - pre.tv_sec) * 100;
d = d + (cur.tv_nsec / 1000) - (pre.tv_nsec / 1000);
dsum += d;
if (d dmin)
dmin = d;
if (d dmax)
dmax = d;
if (d 10*1000) /* 10 ms */
dweird++;
cur = pre;
}
fprintf(stdout, dmin = %dus\ndmax = %dus\ndmean = %dus\ndweird =
%d\n,
dmin, dmax, dsum / loop, dweird);
return 0;
}
Re: CFR: importing openresolv
Hi,
On Sun, 20 Feb 2011 18:21:18 + (UTC)
Bjoern A. Zeeb b...@freebsd.org said:
bz Do you have an updated patch for 3.4.1 or 3.3.6? I'd like to help to
bz you get it in for 9.0-R. I wouldn't even mind if some ports would
bz conflict with it for a while not making the situation any worse than
bz it is these days.
I didn't notice that openresolv was updated. I'll soon make a new
diff for 3.4.1.
hrs@ noticed that ppp(8) and uhsoctl(8) in our base tree touch
/etc/resolv.conf. We need to change them to use resovlconf(8).
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
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: CFR: importing openresolv
Hi,
On Tue, 22 Feb 2011 01:50:17 +0900
Hajimu UMEMOTO u...@freebsd.org said:
bz Do you have an updated patch for 3.4.1 or 3.3.6? I'd like to help to
bz you get it in for 9.0-R. I wouldn't even mind if some ports would
bz conflict with it for a while not making the situation any worse than
bz it is these days.
ume I didn't notice that openresolv was updated. I'll soon make a new
ume diff for 3.4.1.
ume hrs@ noticed that ppp(8) and uhsoctl(8) in our base tree touch
ume /etc/resolv.conf. We need to change them to use resovlconf(8).
I've updated a patch for 3.4.1:
http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20110222.diff.gz
If you have the previous patch applied, make sure to remove
src/contrib/openresolv and src/sbin/resolvconf before applying new
one.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
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: Openoffice doesn't work with kernel+world built with Clang
On Wed, Nov 3, 2010 at 1:05 PM, Renato Botelho rbga...@gmail.com wrote:
On Wed, Nov 3, 2010 at 12:44 PM, Ed Schouten e...@80386.nl wrote:
* Renato Botelho rbga...@gmail.com, 20101103 15:36:
On Wed, Nov 3, 2010 at 11:44 AM, Ed Schouten e...@80386.nl wrote:
Garga!
* Renato Botelho rbga...@gmail.com, 20101103 13:36:
For now i solve my problem adding this to /etc/src.conf
.if ${.CURDIR} == /usr/src/gnu/lib/libgcc
CC=cc
CXX=c++
.endif
This way libgcc_s.so is built using gcc instead of clang and the problem
is gone. I just wonder other problems we can find since simething on
libgcc_s.so is broken when built with clang.
Would it be hard to figure out which exact object file causes this?
Hi Ed,
I've submitted a ktrace result of openoffice execution [1], i just
saw it got a SIGBUS at some point, but debug openoffice doesn't
seem to be a trivial task.
I don't know if we can build OO with debug symbols to make it
easier to debug. If you know what i can do to help debugging,
just let me know and i can provide any information.
Well, I mean, can you build some of libgcc's object files with Clang and
others with GCC? Hint: Just build everything with GCC. Afterwards, go
into the object directory, rm some of the .o files and make CC=clang.
Since OOo is a C++ application, I suspect the unwind-related object
files to be the culprit.
Bingo! When I build everything but unwind-dw2.o with clang it works.
This is the object that is causing the problem.
FYI, after upgrade it today to r218915, and remove the hack to
build libgcc with gcc instead of clang, the problem is gone. Now
my world + kernel are both 100% built with clang and i can start
openoffice as well.
--
Renato Botelho
___
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: Process timing issue
On Feb 21, 2011, at 8:24 AM, Jerome Flesch wrote: While investigating a timing issue with one of our program, we found out something weird: We've written a small test program that just calls clock_gettime() a lot of times and checks that the time difference between calls makes sense. In the end, it seems it doesn't always do. Calling twice in a row clock_gettime() takes usually less than 1ms. But with an average load, about 1 time in 20, more than 10ms are spent between both calls for no apparent reason. According to our tests, when it happens, the time between both calls can go from few milliseconds to many seconds (our best score so far is 10 seconds :). Same goes for gettimeofday(). A scheduler quantum of 10ms (or HZ=100) is a common granularity; probably some other process got the CPU and your timer process didn't run until the next or some later scheduler tick. If you are maxing out the available CPU by running many openssl speed tasks, then this behavior is more-or-less expected. We tried setting the test program to the highest priority possible (rtprio(REALTIME, RTP_PRIO_MAX)) and it doesn't seem to change a thing. Does anyone know if there is a reason for this behavior ? Is there something that can be done to improve things ? FreeBSD doesn't offer hard realtime guarantees, and it values maximizing throughput for all tasks more than it does providing absolute minimum latency even for something wanting RT. There has been some discussion in the past about making RT tasks with very high priority less pre-emptible by lower priority tasks by removing or reducing the priority lowering that occurs when a task gets allocated CPU time. What problem are you trying to solve where continuous CPU load and minimum latency realtime are both required? Regards, -- -Chuck ___ 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: About panic: bufwrite: buffer is not busy???
On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote:
On 2/20/2011 9:33 AM, Andrey Smagin wrote:
On week -current I have same problem, my box paniced every 2-15 min. I
resolve problem by next steps - unplug network connectors from 2 intel em
(82574L) cards. I think last time that mpd5 related panic, but mpd5 work
with another re interface interated on MB. I think it may be em related
panic, or em+mpd5.
The latest panic I saw didnt have anything to do with em. Are you sure
your crashes are because of the nic drive ?
The latest I saw was on Friday.
# kgdb /usr/obj/usr/src/sys/router/kernel.debug vmcore.11
(kgdb) bt
#0 doadump () at pcpu.h:231
#1 0xc04a51f9 in db_fncall (dummy1=1, dummy2=0, dummy3=-106856,
dummy4=0xc6b9696c ) at /usr/src/sys/ddb/db_command.c:548
#2 0xc04a55f1 in db_command (last_cmdp=0xc096f73c, cmd_table=0x0,
dopager=1) at /usr/src/sys/ddb/db_command.c:445
#3 0xc04a574a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#4 0xc04a764d in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
#5 0xc068ba7e in kdb_trap (type=12, code=0, tf=0xc6b96b94) at
/usr/src/sys/kern/subr_kdb.c:546
#6 0xc088056f in trap_fatal (frame=0xc6b96b94, eva=52) at
/usr/src/sys/i386/i386/trap.c:937
#7 0xc0880830 in trap_pfault (frame=0xc6b96b94, usermode=0, eva=52) at
/usr/src/sys/i386/i386/trap.c:859
#8 0xc0880d4a in trap (frame=0xc6b96b94) at
/usr/src/sys/i386/i386/trap.c:532
#9 0xc086716c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248
#11 0xc0654ec9 in crcopy (dest=0xce3ee800, src=0xce3ee600) at
/usr/src/sys/kern/kern_prot.c:1873
#12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at
/usr/src/sys/kern/kern_prot.c:1950
#13 0xc0656d7f in seteuid (td=0xc9196b80, uap=0xc6b96cec) at
/usr/src/sys/kern/kern_prot.c:615
#14 0xc06985ff in syscallenter (td=0xc9196b80, sa=0xc6b96ce4) at
/usr/src/sys/kern/subr_trap.c:315
#15 0xc0880884 in syscall (frame=0xc6b96d28) at
/usr/src/sys/i386/i386/trap.c:1061
#16 0xc08671d1 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:264
#17 0x0033 in ?? ()
(kgdb) frame 10
#10 0xc0657a16 in uihold (uip=0x0) at /usr/src/sys/kern/kern_resource.c:1248
1248{
(kgdb) list
1243 * Place another refcount on a uidinfo struct.
1244 */
1245void
1246uihold(uip)
1247struct uidinfo *uip;
1248{
1249
1250refcount_acquire(uip-ui_ref);
1251}
1252
(kgdb) p *uip
Cannot access memory at address 0x0
(kgdb) p uip
$1 = (struct uidinfo *) 0x0
(kgdb)
Is this reproducable ?
What system version is it ?
Could you, please, go to frame 12 and show the output of p *p,
p *(p-p_ucred) ?
pgpqIxtvc9MgK.pgp
Description: PGP signature
Re: Dell 370 bluetooth minicard
Hello, On a Dell E6400 the bluetooth wireless minicard (Dell 370 = BCM2046B1 if i am right) does not attach to any driver. Is this ship supported by the btbcmfw driver? Any comment would be helpfull. did you try to load ng_ubt(4) driver? also freebsd-bluetooth@ is probably more appropriate for those type of questions. thanks max ___ 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: About panic: bufwrite: buffer is not busy???
On 2/21/2011 4:10 PM, Kostik Belousov wrote:
Is this reproducable ?
The box seems to have a number of bugs it has been triggering.
g...@freebsd.org's netgraph patch, seems to have fixed one of them. Max seems
to have fixed two others. This one, I am not sure. I can re-enable memguard to
randomly sample again, which is what seemed to have caught / triggered it.
What system version is it ?
8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #11: Thu Feb 17 i386, 4G of RAM
Could you, please, go to frame 12 and show the output of p *p,
p *(p-p_ucred) ?
(kgdb) frame 12
#12 0xc0654fd1 in crcopysafe (p=0xc90cc810, cr=0xce3ee800) at
/usr/src/sys/kern/kern_prot.c:1950
1950crcopy(cr, oldcred);
(kgdb) list
1945PROC_UNLOCK(p);
1946crextend(cr, groups);
1947PROC_LOCK(p);
1948oldcred = p-p_ucred;
1949}
1950crcopy(cr, oldcred);
1951
1952return (oldcred);
1953}
1954
(kgdb) p *(p-p_ucred)
$1 = {cr_ref = 3373030400, cr_uid = 3460374784, cr_ruid = 3231313392, cr_svuid
= 7196, cr_ngroups = 0, cr_rgid = 503415038, cr_svgid = 0, cr_uidinfo = 0x0,
cr_ruidinfo = 0x0,
cr_prison = 0x0, cr_pspare = 0x, cr_flags = 4294967295, cr_pspare2 =
{0x0, 0x0}, cr_label = 0x, cr_audit = {ai_auid = 0, ai_mask =
{am_success = 0,
am_failure = 1298034100}, ai_termid = {at_port = 3, at_type = 1, at_addr
= {0, 64, 0, 0}}, ai_asid = 0, ai_flags = 0}, cr_groups = 0xc9e37900,
cr_agroups = 16}
(kgdb) p *p
$2 = {p_list = {le_next = 0xc93ed560, le_prev = 0xc9187ac0}, p_threads =
{tqh_first = 0xc9196b80, tqh_last = 0xc9196b88}, p_slock = {lock_object = {
lo_name = 0xc08efca2 process slock, lo_flags = 720896, lo_data = 0,
lo_witness = 0x0}, mtx_lock = 4}, p_ucred = 0xce3ee600, p_fd = 0xc9559100,
p_fdtol = 0x0,
p_stats = 0xc90cd600, p_limit = 0xc912d600, p_limco = {c_links = {sle =
{sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg =
0x0, c_func = 0,
c_lock = 0xc90cc898, c_flags = 0, c_cpu = 0}, p_sigacts = 0xc911f000,
p_flag = 268435713, p_state = PRS_NORMAL, p_pid = 565, p_hash = {le_next = 0x0,
le_prev = 0xc8d148d4},
p_pglist = {le_next = 0x0, le_prev = 0xc90c85c8}, p_pptr = 0xc8d2b000,
p_sibling = {le_next = 0xc93ed560, le_prev = 0xc9187b3c}, p_children =
{lh_first = 0x0}, p_mtx = {
lock_object = {lo_name = 0xc08efc95 process lock, lo_flags = 21168128,
lo_data = 0, lo_witness = 0x0}, mtx_lock = 3373886336}, p_ksi = 0xc908f9b0,
p_sigqueue = {
sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}},
sq_list = {tqh_first = 0x0, tqh_last = 0xc90cc8d0}, sq_proc = 0xc90cc810,
sq_flags = 1},
p_oppid = 0, p_vmspace = 0xc93f0e80, p_swtick = 6600, p_realtimer =
{it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec =
0}}, p_ru = {ru_utime = {
tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss
= 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0,
ru_nswap = 0,
ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals =
0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 109046064880,
rux_uticks = 1368,
rux_sticks = 5393, rux_iticks = 0, rux_uu = 10366008, rux_su = 40860399,
rux_tu = 51225136}, p_crux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0,
rux_iticks = 0,
rux_uu = 0, rux_su = 0, rux_tu = 0}, p_profthreads = 0, p_exitthreads = 0,
p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0xc95bf96c,
p_lock = 0,
p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0,
p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo =
0x0, p_aioinfo = 0x0,
p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0,
p_pendingcnt = 0, p_itimers = 0x0, p_magic = 3203398350, p_osrel = 802500,
p_comm = zebra, '\0' repeats 14 times, p_pgrp = 0xc90c85c0, p_sysent =
0xc095c800, p_args = 0xc90c8440, p_cpulimit = 9223372036854775807, p_nice = 0
'\0', p_fibnum = 0,
p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xc062a990
knlist_mtx_lock, kl_unlock = 0xc062a940 knlist_mtx_unlock,
kl_assert_locked = 0xc06275f0 knlist_mtx_assert_locked,
kl_assert_unlocked = 0xc0627600 knlist_mtx_assert_unlocked, kl_lockarg =
0xc90cc898}, p_numthreads = 1, p_md = {
md_ldt = 0x0}, p_itcallout = {c_links = {sle = {sle_next = 0x0}, tqe =
{tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock
= 0x0, c_flags = 16,
c_cpu = 0}, p_acflag = 1, p_peers = 0x0, p_leader = 0xc90cc810, p_emuldata
= 0x0, p_label = 0x0, p_sched = 0xc90ccac0, p_ktr = {stqh_first = 0x0,
stqh_last = 0xc90ccaa0},
p_mqnotifier = {lh_first = 0x0}, p_dtrace = 0x0, p_pwait = {cv_description =
0xc08f00ef ppwait, cv_waiters = 0}, p_dbgwait = {cv_description = 0xc08f00f6
dbgwait,
cv_waiters = 0}}
(kgdb)
--
---
Mike
Stack overflow before kernel load..
Hi, Any ideas why the bootloader prints a 'error: stack overflow' message and request user confirmation to load the kernel manually? $ uname -a FreeBSD marina.localdomain 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #1: Wed Feb 16 03:38:23 EST 2011 root@:/usr/local/freebsd8/src/sys/amd64/compile/GENERIC.ndebug amd64 Thanks, Etienne ___ 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: FreeBSD Installer Roadmap
On Saturday, February 19, 2011 02:44:42 am Bruce Cran wrote: On Saturday 19 February 2011 03:04:39 Devin Teske wrote: There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). I think bsdinstall as it currently is is simple enough that there shouldn't be any compatibility issues: it uses gpart for partitioning, runs tools like tzsetup to configure settings etc. so there's far less to go wrong than sysinstall's custom code which for example could crash on the probing devices screen. pc-sysinstall has been used as the PC-BSD installer for quite a while now, and has done a lot of installs on a lot of different hardware platforms. I'll wager that the compatibility of the shell command gpart is a better bet than the stick your thumbs in you ears and yell nananana while you scribble 1's and 0's to a disk and voila, there's a disklabel approach that sysinstall uses. That being said, sysinstall holds FreeBSD back in a lot of ways, using GPT labeling, installing to ZFS, or gmirror, using geli, all require you to boot to a shell and do an install by hand. I'm sure more people can chime in to limitations in sysinstall than I can think of off the top of my head. So my question is: Given that everyone involved is very conscious of locking out FreeBSD from hardware platforms due to installer compatibility, wouldn't a better use of your time be investing in the future and ensuring that it works on legacy platforms as opposed to putting sysinstall on life support when it already has some fairly serious missing functionality, that is only likely to become more of an issue in the future? -- Thanks, Josh Paetzel signature.asc Description: This is a digitally signed message part.
Re: FreeBSD Installer Roadmap
On Mon, 2011-02-21 at 16:12 -0600, Josh Paetzel wrote: pc-sysinstall has been used as the PC-BSD installer for quite a while now, and has done a lot of installs on a lot of different hardware platforms. I'll wager that the compatibility of the shell command gpart is a better bet than the stick your thumbs in you ears and yell nananana while you scribble 1's and 0's to a disk and voila, there's a disklabel approach that sysinstall uses. I wish that was true: unfortunately I tried and failed to create a ZFS installation with pc-sysinstall, and I get a few worrying error messages even with UFS while it repartitions the disk - people have been reporting it creating unbootable systems. gpart might be more compatible, but I don't think parsing the output of tools like as fdisk, diskinfo and dmesg is. The concerns about GPT, ZFS, gmirror etc. in sysinstall could all be resolved in a couple of days by ripping out the existing partitioning code and replacing it with ae@'s new version of sade from /user/ae/usr.sbin/sade . However since the future is pc-sysinstall I've now shifted my work to improving the Qt front-end. -- Bruce Cran ___ 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: FreeBSD Installer Roadmap
On Mon, 2011-02-21 at 16:12 -0600, Josh Paetzel wrote: pc-sysinstall has been used as the PC-BSD installer for quite a while now, and has done a lot of installs on a lot of different hardware platforms. I'll wager that the compatibility of the shell command gpart is a better bet than the stick your thumbs in you ears and yell nananana while you scribble 1's and 0's to a disk and voila, there's a disklabel approach that sysinstall uses. I wish that was true: unfortunately I tried and failed to create a ZFS installation with pc-sysinstall, and I get a few worrying error messages even with UFS while it repartitions the disk - people have been reporting it creating unbootable systems. gpart might be more compatible, but I don't think parsing the output of tools like as fdisk, diskinfo and dmesg is. The concerns about GPT, ZFS, gmirror etc. in sysinstall could all be resolved in a couple of days by ripping out the existing partitioning code and replacing it with ae@'s new version of sade from /user/ae/usr.sbin/sade . However since the future is pc-sysinstall I've now shifted my work to improving the Qt front-end. -- Bruce Cran ___ 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: FreeBSD Installer Roadmap
On Feb 21, 2011, at 2:12 PM, Josh Paetzel wrote: On Saturday, February 19, 2011 02:44:42 am Bruce Cran wrote: On Saturday 19 February 2011 03:04:39 Devin Teske wrote: There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). I think bsdinstall as it currently is is simple enough that there shouldn't be any compatibility issues: it uses gpart for partitioning, runs tools like tzsetup to configure settings etc. so there's far less to go wrong than sysinstall's custom code which for example could crash on the probing devices screen. pc-sysinstall has been used as the PC-BSD installer for quite a while now, and has done a lot of installs on a lot of different hardware platforms. I'll wager that the compatibility of the shell command gpart is a better bet than the stick your thumbs in you ears and yell nananana while you scribble 1's and 0's to a disk and voila, there's a disklabel approach that sysinstall uses. This is a common affront that can be assuaged simply by perusing sysinstall's code. Unfortunately, I may be truly-alone in my opinion that sysinstall is elegantly simple (but then again, I also have an innate understanding of why each/every line of code exists; bourne in-truth from a decadal melange of knowledge when it comes to ancient architectures -- that and I routinely read the 15+ years of commit logs for fun). In reality, the _only_ thing, in my honest opinion, that sysinstall fails-at is its embracement of new technologies such as GPT, ZFS, and geli (just to name a few; all of which you mention below). However, this is not the position that I am (or we are, as a business collective) coming from. From the position at which we stand, sysinstall is not [yet] deficient and despite your claims, neither does it resort to black-magic scribbl[ing] 1's and 0's to a disk and voila, there's a disklabel (by comparison standards, might one be able to say -- if taking the same naive tone -- that gpart scribble[s] 1's and 0's and voila, there's a [partition table]; the only distinction being perhaps your own bias of MBR versus GPT which if you conversely understood the limitations of MBR then you might not have such qualms against disklabels). Just as it was stated by another in this thread that a system with 1,000+ days uptime may not be a good candidate for upgrade (entirely on the basis that such a system in its current state has proved its meddle), we make an argument along the same lines for the install process -- because sysinstall has served us *so exquisitely well* over the years (its meddle being proven) we are reluctant to blindly accept the new kid on the block without rigorous recension (note: in comparison by age, any technology is young when compared to sysinstall). That being said, sysinstall holds FreeBSD back in a lot of ways, using GPT labeling, installing to ZFS, or gmirror, using geli, all require you to boot to a shell and do an install by hand. I'm sure more people can chime in to limitations in sysinstall than I can think of off the top of my head. You are absolutely correct in highlighting the most prominent short-comings of sysinstall, but alas if you don't need those features then completely swapping out your installer for a new one begins to make less sense than sticking with what has served (and will continue to serve) you well. The long and the short of this is, we don't use GPT, we don't (and wouldn't) use ZFS as a root partition scheme, and have no use for geli on the root disk (though may venture into using geli as a PCI solution -- pcisecuritystandards.org -- on secondary media mounted at boot-time). Philosophically, innovation is bourne of necessity -- and we don't need any of the things that bsdinstall brings us ... so the only thing that bsdinstall represents is more work for me in migrating thousands upon thousands of lines of code to the new installer, vetting every aspect of the new installer in the process (note that we utilize sysinstall in ways that others could only dream of -- something you'll be able to see for yourself when I get back from Hong Kong to The States and start publishing our/my work). That being said, if we _did_ need the features that are provided by bsdinstall versus what is
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-02-22 05:21:04 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2011-02-22 05:21:04 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2011-02-22 05:21:04 - cleaning the object tree
TB --- 2011-02-22 05:21:20 - cvsupping the source tree
TB --- 2011-02-22 05:21:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/powerpc64/powerpc/supfile
TB --- 2011-02-22 05:21:54 - building world
TB --- 2011-02-22 05:21:54 - MAKEOBJDIRPREFIX=/obj
TB --- 2011-02-22 05:21:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2011-02-22 05:21:54 - TARGET=powerpc
TB --- 2011-02-22 05:21:54 - TARGET_ARCH=powerpc64
TB --- 2011-02-22 05:21:54 - TZ=UTC
TB --- 2011-02-22 05:21:54 - __MAKE_CONF=/dev/null
TB --- 2011-02-22 05:21:54 - cd /src
TB --- 2011-02-22 05:21:54 - /usr/bin/make -B buildworld
World build started on Tue Feb 22 05:21:55 UTC 2011
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
[...]
{standard input}:58: Error: unsupported relocation against r1
{standard input}:59: Error: unsupported relocation against f1
{standard input}:59: Error: unsupported relocation against r1
{standard input}:60: Error: unsupported relocation against r1
{standard input}:60: Error: unsupported relocation against r1
{standard input}:61: Error: unsupported relocation against r2
{standard input}:61: Error: unsupported relocation against r1
{standard input}:62: Error: unsupported relocation against r2
*** Error code 1
Stop in /src/lib/clang/libllvmpowerpccodegen.
*** Error code 1
Stop in /src/lib/clang.
*** Error code 1
Stop in /src/lib.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2011-02-22 06:36:45 - WARNING: /usr/bin/make returned exit code 1
TB --- 2011-02-22 06:36:45 - ERROR: failed to build world
TB --- 2011-02-22 06:36:45 - 3753.97 user 545.79 system 4541.04 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full
___
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: FreeBSD Installer Roadmap
On Monday, February 21, 2011 08:38:03 pm Devin Teske wrote:
Really, the crux of the issue is that our organization is **just now**
migrating off of FreeBSD-4 (yes, it's true... there are over 1,000
FreeBSD-4.11 machines running in production at this very moment spanning
the entire United States, parts of India, and parts of the Indo-pacific
rim). Worse? We just added yet-another 200+ to those ranks in the past 2
months.
My hat is off to you sir... as I envy your position that you can be so
free-moving. We are encumbered by entrenched methods and do not have the
luxury of trying new things for the sake of change (case in-point, since
bsdinstall brings nothing new to the table that we rely upon, it truly
would be change for the sake of change in our organization).
Fin de dialectics.
--
Cheers,
Devin Teske
Maintaining sysinstall for 4.x is indeed a NOOP, since features aren't being
added to it, and the featureset that sysinstall supports is pretty much in
line with the featureset in 4...no ZFS, no geom_*, etc etc etc.
On the other hand, maintaining sysinstall for the next N years of new FreeBSD
releases seems hard, when it's already missing features compared to what
FreeBSD supports, and that's likely to continue to grow.
I totally agree that for internal use, migrating thousands of lines of code
makes no sense whatsoever, especially if sysinstall meets your needs and you
don't care about the functionality it doesn't have. Exporting that to the
community seems to be a questionable use of resources.
I'm no stranger to large deployments. With my ${WORK} hat on we can install a
thousand FreeBSD systems in a week. In my 16+ years of involvement with
FreeBSD I've written three automated installers...quite frankly, ditching
sysinstall for that happened really fast.
I do admit to being a tad curious where you find systems that can run FreeBSD
4 at this point. A single socket intel shows up as 8 or 12 CPUs these days,
more than enough to tie 4.x into knots. Add in disk controllers, NICs, ACPI
(modern systems use that for nearly everything it seems) and suddenly an
installer seems the least of the concerns.
I suppose my last question is along the lines of, If adding geom_mirror
support to sysinstall was easy, why has it been 6+ years since gmirror made
it's appearance in FreeBSD and you still can't create or install to a gmirror
with sysinstall?
--
Thanks,
Josh Paetzel
signature.asc
Description: This is a digitally signed message part.
