Re: slapd dumping core with today's current.
On Wed, 18 Sep 2002, Julian Elischer wrote:
threads is broken right now..
due to a miscommunicatin,. the kernel and the threads library have
a disagreement regarding something..
Unfortunatly the person to slap up over this is offline for aday or
so..
please be patient for a day or so (we hope).
I think it's because libc_r has been disconnected from the
build:
revision 1.143
date: 2002/09/17 07:32:36; author: peter; state: Exp; lines: +1 -1
Add i386 to the list of architectures that libc_r is broken on. This
effectively removes pppctl from the build for now. It only compiles on
alpha now (now ironic).
And the i386 mcontext_t is now bigger because we account for the
newer SSE (?) format FP register sets. Older libc_r's used ucontext_t's
that were smaller and manually save and restore FP state into
areas of ucontext_t which mc_len and mc_fpformat now occupy.
The kernel uses these to validate a context and returns an
error if these fields aren't valid.
The fix is to remove the two calls to FP_SAVE_UC and FP_RESTORE_UC
in libc_r/uthread/uthread_kern.c. And to also hook libc_r back
into the build (src/lib/Makefile).
Libc_r patch included (which my mailer will probably mangle).
--
Dan Eischen
Index: pthread_private.h
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/pthread_private.h,v
retrieving revision 1.73
diff -u -r1.73 pthread_private.h
--- pthread_private.h 29 Aug 2002 23:06:06 - 1.73
+++ pthread_private.h 19 Sep 2002 06:53:57 -
@@ -75,16 +75,6 @@
#defineSET_STACK_JB(jb, stk) (jb)[0]._jb[2] = (int)(stk)
#defineSET_STACK_SJB(sjb, stk) (sjb)[0]._sjb[2] = (int)(stk)
#defineSET_STACK_UC(ucp, stk) (ucp)-uc_mcontext.mc_esp = (int)(stk)
-#defineFP_SAVE_UC(ucp) do {\
- char*fdata; \
- fdata = (char *) (ucp)-uc_mcontext.mc_fpregs; \
- __asm__(fnsave %0: :m(*fdata)); \
-} while (0)
-#defineFP_RESTORE_UC(ucp) do {\
- char*fdata; \
- fdata = (char *) (ucp)-uc_mcontext.mc_fpregs; \
- __asm__(frstor %0: :m(*fdata)); \
-} while (0)
#define SET_RETURN_ADDR_JB(jb, ra) (jb)[0]._jb[0] = (int)(ra)
#elif defined(__alpha__)
#include machine/reg.h
@@ -94,8 +84,6 @@
#defineSET_STACK_JB(jb, stk) (jb)[0]._jb[R_SP + 4] = (long)(stk)
#defineSET_STACK_SJB(sjb, stk) (sjb)[0]._sjb[R_SP + 4] = (long)(stk)
#defineSET_STACK_UC(ucp, stk) (ucp)-uc_mcontext.mc_regs[R_SP] = (unsigned
long)(stk)
-#defineFP_SAVE_UC(ucp)
-#defineFP_RESTORE_UC(ucp)
#define SET_RETURN_ADDR_JB(jb, ra) do {\
(jb)[0]._jb[2] = (long)(ra);\
(jb)[0]._jb[R_RA + 4] = (long)(ra); \
Index: uthread_kern.c
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.42
diff -u -r1.42 uthread_kern.c
--- uthread_kern.c 29 Aug 2002 00:44:11 - 1.42
+++ uthread_kern.c 19 Sep 2002 06:53:55 -
@@ -113,8 +113,6 @@
/* Check if this function was called from the signal handler: */
if (ucp != NULL) {
- /* XXX - Save FP registers? */
- FP_SAVE_UC(ucp);
called_from_handler = 1;
DBG_MSG(Entering scheduler due to signal\n);
}
@@ -156,9 +154,6 @@
if (ucp == NULL)
return;
else {
- /* XXX - Restore FP registers? */
- FP_RESTORE_UC(ucp);
-
/*
* Set the process signal mask in the context; it
* could have changed by the handler.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
boot -c ?
I need a little bit of help/advise. I am trying to install -CURRENT on a toshiba 3005-s304. for -release or stable, I needed to turn off eisa probing before I could boot/install. I did this by going into boot -c and then entering eisa 0. boot -c on DP1, and the latest snapshots doesnt seem to do anything, I have been unable to find any info regarding a change to the command or what other switches it supports. Thanks in advance.. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Daniel Eischen wrote:
On Wed, 18 Sep 2002, Julian Elischer wrote:
threads is broken right now..
due to a miscommunicatin,. the kernel and the threads library have
a disagreement regarding something..
Unfortunatly the person to slap up over this is offline for aday or
so..
please be patient for a day or so (we hope).
I think it's because libc_r has been disconnected from the
build:
revision 1.143
date: 2002/09/17 07:32:36; author: peter; state: Exp; lines: +1 -1
Add i386 to the list of architectures that libc_r is broken on. This
effectively removes pppctl from the build for now. It only compiles on
alpha now (now ironic).
And the i386 mcontext_t is now bigger because we account for the
newer SSE (?) format FP register sets. Older libc_r's used ucontext_t's
that were smaller and manually save and restore FP state into
areas of ucontext_t which mc_len and mc_fpformat now occupy.
so does that code still exist?
The kernel uses these to validate a context and returns an
error if these fields aren't valid.
so, we need to change the kernel too right?
The fix is to remove the two calls to FP_SAVE_UC and FP_RESTORE_UC
in libc_r/uthread/uthread_kern.c. And to also hook libc_r back
into the build (src/lib/Makefile).
If we remove the calls, is the original code still present?
or did that get removed?
Libc_r patch included (which my mailer will probably mangle).
--
Dan Eischen
Index: pthread_private.h
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/pthread_private.h,v
retrieving revision 1.73
diff -u -r1.73 pthread_private.h
--- pthread_private.h 29 Aug 2002 23:06:06 - 1.73
+++ pthread_private.h 19 Sep 2002 06:53:57 -
@@ -75,16 +75,6 @@
#define SET_STACK_JB(jb, stk) (jb)[0]._jb[2] = (int)(stk)
#define SET_STACK_SJB(sjb, stk) (sjb)[0]._sjb[2] = (int)(stk)
#define SET_STACK_UC(ucp, stk) (ucp)-uc_mcontext.mc_esp = (int)(stk)
-#define FP_SAVE_UC(ucp) do {\
- char*fdata; \
- fdata = (char *) (ucp)-uc_mcontext.mc_fpregs; \
- __asm__(fnsave %0: :m(*fdata)); \
-} while (0)
-#define FP_RESTORE_UC(ucp) do {\
- char*fdata; \
- fdata = (char *) (ucp)-uc_mcontext.mc_fpregs; \
- __asm__(frstor %0: :m(*fdata)); \
-} while (0)
#define SET_RETURN_ADDR_JB(jb, ra) (jb)[0]._jb[0] = (int)(ra)
#elifdefined(__alpha__)
#include machine/reg.h
@@ -94,8 +84,6 @@
#define SET_STACK_JB(jb, stk) (jb)[0]._jb[R_SP + 4] = (long)(stk)
#define SET_STACK_SJB(sjb, stk) (sjb)[0]._sjb[R_SP + 4] = (long)(stk)
#define SET_STACK_UC(ucp, stk) (ucp)-uc_mcontext.mc_regs[R_SP] = (unsigned
long)(stk)
-#define FP_SAVE_UC(ucp)
-#define FP_RESTORE_UC(ucp)
#define SET_RETURN_ADDR_JB(jb, ra) do { \
(jb)[0]._jb[2] = (long)(ra);\
(jb)[0]._jb[R_RA + 4] = (long)(ra); \
Index: uthread_kern.c
===
RCS file: /opt/d/CVS/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.42
diff -u -r1.42 uthread_kern.c
--- uthread_kern.c29 Aug 2002 00:44:11 - 1.42
+++ uthread_kern.c19 Sep 2002 06:53:55 -
@@ -113,8 +113,6 @@
/* Check if this function was called from the signal handler: */
if (ucp != NULL) {
- /* XXX - Save FP registers? */
- FP_SAVE_UC(ucp);
called_from_handler = 1;
DBG_MSG(Entering scheduler due to signal\n);
}
@@ -156,9 +154,6 @@
if (ucp == NULL)
return;
else {
- /* XXX - Restore FP registers? */
- FP_RESTORE_UC(ucp);
-
/*
* Set the process signal mask in the context; it
* could have changed by the handler.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Julian Elischer wrote: On Thu, 19 Sep 2002, Daniel Eischen wrote: On Wed, 18 Sep 2002, Julian Elischer wrote: threads is broken right now.. due to a miscommunicatin,. the kernel and the threads library have a disagreement regarding something.. Unfortunatly the person to slap up over this is offline for aday or so.. please be patient for a day or so (we hope). I think it's because libc_r has been disconnected from the build: revision 1.143 date: 2002/09/17 07:32:36; author: peter; state: Exp; lines: +1 -1 Add i386 to the list of architectures that libc_r is broken on. This effectively removes pppctl from the build for now. It only compiles on alpha now (now ironic). And the i386 mcontext_t is now bigger because we account for the newer SSE (?) format FP register sets. Older libc_r's used ucontext_t's that were smaller and manually save and restore FP state into areas of ucontext_t which mc_len and mc_fpformat now occupy. so does that code still exist? Because libc_r is still disconnected from the build, the older library is still left in place. This library messes with a ucontext (a sigcontext sent to userland from the kernel via a signal handler) that corrupts it (invalidates it) so that when it returns to the kernel from the signal frame (sigreturn), the kernel returns an error or doesn't restore the FP state (see sigreturn() in machdep.c; it calls set_fpcontext() which checks mc_fpformat). A freshly built libc_r with the patches I sent should not mess with any FP state in a ucontext and should avoid the problem. It doesn't have to save and restore the FP state anymore because the i386 code now correctly saves and restores the FP state when sending a signal. Or at least that's the intent of the new code. The kernel uses these to validate a context and returns an error if these fields aren't valid. so, we need to change the kernel too right? No, the kernel is doing the right thing; it's just that the old userland library isn't yet seeing a ucontext in the same way the kernel is. The fix is to remove the two calls to FP_SAVE_UC and FP_RESTORE_UC in libc_r/uthread/uthread_kern.c. And to also hook libc_r back into the build (src/lib/Makefile). If we remove the calls, is the original code still present? or did that get removed? Removing the calls should make it build again, and hooking it back into the build/install process will update the old libc_r so that it works with a new kernel. Threads won't work totally right with the new library and an old kernel because the FP state won't be saved/restored by either the kernel or the library. Is this what you meant? -- Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel crash at boot time
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0227c89
stack pointer = 0x10:0xcd3029c4
frame pointer = 0x10:0xcd3029c4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 182 (route)
panic: from debugger
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01f0819 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01f0a48 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc0142692 in db_panic () at ../../../ddb/db_command.c:449
#4 0xc0142612 in db_command (last_cmdp=0xc0373820, cmd_table=0xc03299a8,
aux_cmd_tablep=0x104,
aux_cmd_tablep_end=0xc0f04840) at ../../../ddb/db_command.c:345
#5 0xc0142726 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc014538a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#7 0xc02fb2f2 in kdb_trap (type=12, code=0, regs=0xcd302984) at
../../../i386/i386/db_interface.c:160
#8 0xc030b982 in trap_fatal (frame=0xcd302984, eva=0) at ../../../i386/i386/trap.c:837
#9 0xc030b692 in trap_pfault (frame=0xcd302984, usermode=0, eva=16) at
../../../i386/i386/trap.c:756
#10 0xc030b20d in trap (frame=
{tf_fs = -1070333928, tf_es = 16, tf_ds = -1057947632, tf_edi = -1057927680,
tf_esi = -1032651796, tf_ebp = -852481596, tf_isp = -852481616, tf_ebx = 238, tf_edx =
0, tf_ecx = -852481576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071481719,
tf_cs = 8, tf_eflags = 66054, tf_esp = -852481560, tf_ss = -1071466855}) at
../../../i386/i386/trap.c:444
#11 0xc02fca38 in calltrap () at {standard input}:98
#12 0xc022b699 in sbappendaddr (sb=0xc272fbec, asa=0xc038c9f8, m0=0xc0f14e00,
control=0x0)
at ../../../kern/uipc_socket2.c:624
#13 0xc025de6f in raw_input (m0=0xc0f14e00, proto=0xc038ca18, src=0xc038c9f8,
dst=0xc038c9e8)
at ../../../net/raw_usrreq.c:116
#14 0xc026032b in rt_missmsg (type=0, rtinfo=0xcd302a58, flags=132101, error=0) at
../../../net/rtsock.c:735
#15 0xc025e3eb in rtalloc1 (dst=0xc272c900, report=1, ignflags=0) at
../../../net/route.c:196
#16 0xc025f228 in rt_setgate (rt0=0xc2729500, dst=0xc272c9dc, gate=0xc272c9ec) at
../../../net/route.c:998
#17 0xc025ec45 in rtrequest1 (req=1, info=0xcd302b44, ret_nrt=0xcd302b3c) at
../../../net/route.c:659
#18 0xc025f9d6 in route_output (m=0xc0f14d00, so=0xc272fba0) at
../../../net/rtsock.c:344
#19 0xc025e0cd in raw_usend (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0,
td=0xc0f04840) at ../../../net/raw_usrreq.c:260
#20 0xc025f745 in rts_send (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0, td=0x0) at
../../../net/rtsock.c:239
#21 0xc0228fe3 in sosend (so=0xc272fba0, addr=0x0, uio=0xcd302c7c, top=0xc0f14d00,
control=0x0, flags=0, td=0xc0f04840)
at ../../../kern/uipc_socket.c:707
#22 0xc0219300 in soo_write (fp=0x0, uio=0xcd302c7c, active_cred=0xc0f01200, flags=0,
td=0xc0f04840)
at ../../../kern/sys_socket.c:89
#23 0xc0213455 in dofilewrite (td=0xc0f04840, fp=0xc26b1d5c, fd=0, buf=0x80aa300,
nbyte=0, offset=0, flags=0) at file.h:214
#24 0xc0213299 in write (td=0xc0f04840, uap=0xcd302d10) at
../../../kern/sys_generic.c:332
#25 0xc030bcee in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134914908, tf_esi = 128, tf_ebp =
-1077936872, tf_isp = -852480652, tf_ebx = 134914944, tf_edx = 134915680, tf_ecx = 0,
tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 134526191, tf_cs = 31, tf_eflags =
662, tf_esp = -1077936916, tf_ss = 47}) at ../../../i386/i386/trap.c:1046
#26 0xc02fca8d in Xint0x80_syscall () at {standard input}:140
note that when kernel ran into DDB, the fault instruction was at m_length+9,
but core dump did not record the fact.
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Daniel Eischen wrote: Ok so I reconnected the libc_r and fixed it to compile. I'm a littel uncomfortable because the new kernel behaviour means that 4.x statically compiled threaded binaries will not work right because we've changed the kernel ABI in an incompatible way.. We need to discuss this carefully when mini gets back to see if there is a way out.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel crash at boot time
On 19 Sep, David Xu wrote:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0227c89
stack pointer = 0x10:0xcd3029c4
frame pointer = 0x10:0xcd3029c4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 182 (route)
panic: from debugger
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01f0819 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01f0a48 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc0142692 in db_panic () at ../../../ddb/db_command.c:449
#4 0xc0142612 in db_command (last_cmdp=0xc0373820, cmd_table=0xc03299a8,
aux_cmd_tablep=0x104,
aux_cmd_tablep_end=0xc0f04840) at ../../../ddb/db_command.c:345
#5 0xc0142726 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc014538a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#7 0xc02fb2f2 in kdb_trap (type=12, code=0, regs=0xcd302984) at
../../../i386/i386/db_interface.c:160
#8 0xc030b982 in trap_fatal (frame=0xcd302984, eva=0) at
../../../i386/i386/trap.c:837
#9 0xc030b692 in trap_pfault (frame=0xcd302984, usermode=0, eva=16) at
../../../i386/i386/trap.c:756
#10 0xc030b20d in trap (frame=
{tf_fs = -1070333928, tf_es = 16, tf_ds = -1057947632, tf_edi = -1057927680,
tf_esi = -1032651796, tf_ebp = -852481596, tf_isp = -852481616, tf_ebx = 238, tf_edx
= 0, tf_ecx = -852481576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1071481719, tf_cs = 8, tf_eflags = 66054, tf_esp = -852481560, tf_ss = -1071466855})
at ../../../i386/i386/trap.c:444
#11 0xc02fca38 in calltrap () at {standard input}:98
#12 0xc022b699 in sbappendaddr (sb=0xc272fbec, asa=0xc038c9f8, m0=0xc0f14e00,
control=0x0)
at ../../../kern/uipc_socket2.c:624
#13 0xc025de6f in raw_input (m0=0xc0f14e00, proto=0xc038ca18, src=0xc038c9f8,
dst=0xc038c9e8)
at ../../../net/raw_usrreq.c:116
#14 0xc026032b in rt_missmsg (type=0, rtinfo=0xcd302a58, flags=132101, error=0) at
../../../net/rtsock.c:735
#15 0xc025e3eb in rtalloc1 (dst=0xc272c900, report=1, ignflags=0) at
../../../net/route.c:196
#16 0xc025f228 in rt_setgate (rt0=0xc2729500, dst=0xc272c9dc, gate=0xc272c9ec) at
../../../net/route.c:998
#17 0xc025ec45 in rtrequest1 (req=1, info=0xcd302b44, ret_nrt=0xcd302b3c) at
../../../net/route.c:659
#18 0xc025f9d6 in route_output (m=0xc0f14d00, so=0xc272fba0) at
../../../net/rtsock.c:344
#19 0xc025e0cd in raw_usend (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0,
td=0xc0f04840) at ../../../net/raw_usrreq.c:260
#20 0xc025f745 in rts_send (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0, td=0x0) at
../../../net/rtsock.c:239
#21 0xc0228fe3 in sosend (so=0xc272fba0, addr=0x0, uio=0xcd302c7c, top=0xc0f14d00,
control=0x0, flags=0, td=0xc0f04840)
at ../../../kern/uipc_socket.c:707
#22 0xc0219300 in soo_write (fp=0x0, uio=0xcd302c7c, active_cred=0xc0f01200,
flags=0, td=0xc0f04840)
at ../../../kern/sys_socket.c:89
#23 0xc0213455 in dofilewrite (td=0xc0f04840, fp=0xc26b1d5c, fd=0, buf=0x80aa300,
nbyte=0, offset=0, flags=0) at file.h:214
#24 0xc0213299 in write (td=0xc0f04840, uap=0xcd302d10) at
../../../kern/sys_generic.c:332
#25 0xc030bcee in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134914908, tf_esi = 128, tf_ebp
= -1077936872, tf_isp = -852480652, tf_ebx = 134914944, tf_edx = 134915680, tf_ecx =
0, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 134526191, tf_cs = 31, tf_eflags
= 662, tf_esp = -1077936916, tf_ss = 47}) at ../../../i386/i386/trap.c:1046
#26 0xc02fca8d in Xint0x80_syscall () at {standard input}:140
note that when kernel ran into DDB, the fault instruction was at m_length+9,
but core dump did not record the fact.
David Xu
It crashed real fast for me as well. Try the following patch. There's
a thread on the committers list calling for the bogus commit to be
backed out.
Index: sys/kern/uipc_mbuf.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.104
diff -u -r1.104 uipc_mbuf.c
--- sys/kern/uipc_mbuf.c19 Sep 2002 03:18:44 - 1.104
+++ sys/kern/uipc_mbuf.c19 Sep 2002 07:59:17 -
@@ -727,9 +727,6 @@
struct mbuf *m;
u_int len;
- if ((m0-m_flags M_PKTHDR) != 0)
- return (m0-m_pkthdr.len);
-
len = 0;
for (m = m0; m != NULL; m = m-m_next) {
len += m-m_len;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel crash at boot time
try now
On Thu, 19 Sep 2002, David Xu wrote:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0227c89
stack pointer = 0x10:0xcd3029c4
frame pointer = 0x10:0xcd3029c4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 182 (route)
panic: from debugger
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01f0819 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01f0a48 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc0142692 in db_panic () at ../../../ddb/db_command.c:449
#4 0xc0142612 in db_command (last_cmdp=0xc0373820, cmd_table=0xc03299a8,
aux_cmd_tablep=0x104,
aux_cmd_tablep_end=0xc0f04840) at ../../../ddb/db_command.c:345
#5 0xc0142726 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc014538a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#7 0xc02fb2f2 in kdb_trap (type=12, code=0, regs=0xcd302984) at
../../../i386/i386/db_interface.c:160
#8 0xc030b982 in trap_fatal (frame=0xcd302984, eva=0) at
../../../i386/i386/trap.c:837
#9 0xc030b692 in trap_pfault (frame=0xcd302984, usermode=0, eva=16) at
../../../i386/i386/trap.c:756
#10 0xc030b20d in trap (frame=
{tf_fs = -1070333928, tf_es = 16, tf_ds = -1057947632, tf_edi = -1057927680,
tf_esi = -1032651796, tf_ebp = -852481596, tf_isp = -852481616, tf_ebx = 238, tf_edx
= 0, tf_ecx = -852481576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1071481719, tf_cs = 8, tf_eflags = 66054, tf_esp = -852481560, tf_ss = -1071466855})
at ../../../i386/i386/trap.c:444
#11 0xc02fca38 in calltrap () at {standard input}:98
#12 0xc022b699 in sbappendaddr (sb=0xc272fbec, asa=0xc038c9f8, m0=0xc0f14e00,
control=0x0)
at ../../../kern/uipc_socket2.c:624
#13 0xc025de6f in raw_input (m0=0xc0f14e00, proto=0xc038ca18, src=0xc038c9f8,
dst=0xc038c9e8)
at ../../../net/raw_usrreq.c:116
#14 0xc026032b in rt_missmsg (type=0, rtinfo=0xcd302a58, flags=132101, error=0) at
../../../net/rtsock.c:735
#15 0xc025e3eb in rtalloc1 (dst=0xc272c900, report=1, ignflags=0) at
../../../net/route.c:196
#16 0xc025f228 in rt_setgate (rt0=0xc2729500, dst=0xc272c9dc, gate=0xc272c9ec) at
../../../net/route.c:998
#17 0xc025ec45 in rtrequest1 (req=1, info=0xcd302b44, ret_nrt=0xcd302b3c) at
../../../net/route.c:659
#18 0xc025f9d6 in route_output (m=0xc0f14d00, so=0xc272fba0) at
../../../net/rtsock.c:344
#19 0xc025e0cd in raw_usend (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0,
td=0xc0f04840) at ../../../net/raw_usrreq.c:260
#20 0xc025f745 in rts_send (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0, td=0x0) at
../../../net/rtsock.c:239
#21 0xc0228fe3 in sosend (so=0xc272fba0, addr=0x0, uio=0xcd302c7c, top=0xc0f14d00,
control=0x0, flags=0, td=0xc0f04840)
at ../../../kern/uipc_socket.c:707
#22 0xc0219300 in soo_write (fp=0x0, uio=0xcd302c7c, active_cred=0xc0f01200,
flags=0, td=0xc0f04840)
at ../../../kern/sys_socket.c:89
#23 0xc0213455 in dofilewrite (td=0xc0f04840, fp=0xc26b1d5c, fd=0, buf=0x80aa300,
nbyte=0, offset=0, flags=0) at file.h:214
#24 0xc0213299 in write (td=0xc0f04840, uap=0xcd302d10) at
../../../kern/sys_generic.c:332
#25 0xc030bcee in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134914908, tf_esi = 128, tf_ebp
= -1077936872, tf_isp = -852480652, tf_ebx = 134914944, tf_edx = 134915680, tf_ecx =
0, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 134526191, tf_cs = 31, tf_eflags
= 662, tf_esp = -1077936916, tf_ss = 47}) at ../../../i386/i386/trap.c:1046
#26 0xc02fca8d in Xint0x80_syscall () at {standard input}:140
note that when kernel ran into DDB, the fault instruction was at m_length+9,
but core dump did not record the fact.
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel crash at boot time
On Thu, 19 Sep 2002, Don Lewis wrote:
- if ((m0-m_flags M_PKTHDR) != 0)
- return (m0-m_pkthdr.len);
-
len = 0;
for (m = m0; m != NULL; m = m-m_next) {
len += m-m_len;
already done
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel crash at boot time
Thanks, it works again. :) - Original Message - From: Julian Elischer [EMAIL PROTECTED] To: David Xu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:35 PM Subject: Re: kernel crash at boot time try now On Thu, 19 Sep 2002, David Xu wrote: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0227c89 stack pointer = 0x10:0xcd3029c4 frame pointer = 0x10:0xcd3029c4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 182 (route) panic: from debugger To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download (solved I think)
Hi all, With help of http://www.memtest86.com/memtest86-3.0.iso I've tracked it down to three 3 ! bad DRAMS. Sorry about all this. Still unsolved is the options PSE options PG_G stuff with Ram that passes all tests. Corruption there still happens. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken IPv4 in IPv6 on -current?
On Wed, Sep 18, 2002 at 08:05:29PM -0400, Trish Lynch wrote: FreeBSD femme.sapphite.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Mon Sep 9 10:23:22 EDT 2002 [EMAIL PROTECTED]:/admins/obj/admins/src/sys/FEMME i386 its pretty bizarre It's disabled by default: [238]cicely8 sysctl net.inet6.ip6.v6only net.inet6.ip6.v6only: 1 The prefered way to handle IPv6 as well as IPv4 connects you should listen to both addresses. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Sep 19 03:10:34 PDT 2002 -- Kernel build for GENERIC completed on Thu Sep 19 03:36:48 PDT 2002 -- Kernel build for LINT started on Thu Sep 19 03:36:49 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/coda/coda_namecache.c: In function `coda_nc_enter': /h/des/src/sys/coda/coda_namecache.c:245: warning: cast from pointer to integer of different size /h/des/src/sys/coda/coda_namecache.c:263: warning: cast from pointer to integer of different size /h/des/src/sys/coda/coda_namecache.c: In function `coda_nc_lookup': /h/des/src/sys/coda/coda_namecache.c:322: warning: cast from pointer to integer of different size /h/des/src/sys/coda/coda_namecache.c: In function `coda_nc_zapfile': /h/des/src/sys/coda/coda_namecache.c:520: warning: cast from pointer to integer of different size /h/des/src/sys/coda/coda_namecache.c: In function `coda_nc_purge_user': /h/des/src/sys/coda/coda_namecache.c:568: warning: cast from pointer to integer of different size *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel crash at boot time
Can you try with rev. 1.101 of sys/kern/uipc_mbuf.c please ? The
1.102... is wrong and could easily cause this.
Poul-Henning
In message 01be01c25fb1$8b92a990$ef01a8c0@davidwnt, David Xu writes:
#11 0xc02fca38 in calltrap () at {standard input}:98
#12 0xc022b699 in sbappendaddr (sb=0xc272fbec, asa=0xc038c9f8, m0=0xc0f14e00,
control=0x0)
at ../../../kern/uipc_socket2.c:624
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Crashdumps available for download (solved I think)
On Thu, Sep 19, 2002 at 11:16:10AM +0200, Martin Blapp wrote: Hi all, With help of http://www.memtest86.com/memtest86-3.0.iso I've tracked it down to three 3 ! bad DRAMS. D-RAM is bad per definition. There's a reason why good machines always use ECC. It's just a matter how likely errors are. Well - your RAM is obviously not good enough. It's awfull how much crap there still is on the market. Windows users typically don't think of hardware if the box crashes... Sorry about all this. It was absolutely not your fault. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Code factoring in /etc/periodic/security firewall checks
Le 2002-09-18, Thomas Quinot écrivait : http://www.cuivre.fr.eu.org/~thomas/periodic-fw.diff I have prepared an updated version of the patch that also includes 100.chksetuid, 200.chkmounts and 700.kernelmsg in the factoring. http://www.cuivre.fr.eu.org/~thomas/periodic-security/ -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Threads working again [19 Sep]
With today's cvsup and a make libraries all my threaded apps are working again, thanks. My kernel and world are from yesterday (18 Sep). I see that the kernel and many other things have been updated since yesterday but I've not yet rebuilt the system except for the libraries. Just thought I'd mention that in case something breaks during the next build ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't compile kernel?
Hi. On Wed, Sep 18, 2002 at 01:15:40PM -0500, Steve Ames wrote: New datapoint: If I compile the kernel in the old fashion (config SB; cd ../compile/SB; make depend all install) then the kernel compiles and installs fine. However I get the error below when doing a 'make kernel' from /usr/src. Also even after rebooting onto the new kernel bind9 and mysql-server are still exiting on signal6. I'm also getting cpp0 crashing while building new kernel. My world is from 2002-09-01(UTC) source. It looks similar to yours, except that: - cpp0 exits with signal 11, not signal 6. - I'm building my kernel in the old fashion with a slight modification $ config -d /usr/obj/kernel /path/to/CONFIGFILE \ cd /usr/obj/kernel make depend make but cpp0 still crashes at the first stage of 'make depend'. Thoughts? Anything I can provide to help narror this down further? Now I'm wondering where I can build a cpp0 with debug symbols enabled so that I can post the backtrace... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Julian Elischer wrote: On Thu, 19 Sep 2002, Daniel Eischen wrote: Ok so I reconnected the libc_r and fixed it to compile. I'm a littel uncomfortable because the new kernel behaviour means that 4.x statically compiled threaded binaries will not work right because we've changed the kernel ABI in an incompatible way.. We need to discuss this carefully when mini gets back to see if there is a way out.. I brought this up with bde before. My suggestion was to create another sigreturn(), so we'd have osigreturn(), osigreturn2(), and [new] sigreturn(). He didn't like this. I think we'd need another sendsig() too. When mini adds setcontext() as a system call, this can make sigreturn() obsolete. The signal trampoline can call setcontext() instead of sigreturn() and sigreturn() can handle the old format... We still need a different sendsig() though. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
Quoting Julian Elischer [EMAIL PROTECTED]: | threads is broken right now.. | due to a miscommunicatin,. the kernel and the threads library have | a disagreement regarding something.. | Unfortunatly the person to slap up over this is offline for aday or | so.. | please be patient for a day or so (we hope). No problem. Thanks a lot, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
Quoting Wesley Morgan [EMAIL PROTECTED]: | Boot from a kernel from a day or two ago and you should be fine. Unless | you build every day, your kernel.old/kernel should be in agreement with | libc_r I do build everyday and Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't compile kernel?
On Thu, Sep 19, 2002 at 10:15:48PM +0900, I wrote: On Wed, Sep 18, 2002 at 01:15:40PM -0500, Steve Ames wrote: New datapoint: If I compile the kernel in the old fashion (config SB; cd ../compile/SB; make depend all install) then the kernel compiles and installs fine. However I get the error below when doing a 'make kernel' from /usr/src. Also even after rebooting onto the new kernel bind9 and mysql-server are still exiting on signal6. I'm also getting cpp0 crashing while building new kernel. My world is from 2002-09-01(UTC) source. It looks similar to yours, except that: - cpp0 exits with signal 11, not signal 6. - I'm building my kernel in the old fashion with a slight modification $ config -d /usr/obj/kernel /path/to/CONFIGFILE \ cd /usr/obj/kernel make depend make but cpp0 still crashes at the first stage of 'make depend'. Thoughts? Anything I can provide to help narror this down further? Now I'm wondering where I can build a cpp0 with debug symbols enabled so that I can post the backtrace... By the way, I've tracked down the first .c file that causes cpp0 to sig11. It's /usr/src/sys/netkey/keysock.c,rev 1.16(my source tree is placed under /home/usr.src and symlinked from /usr). $ MKDEP_CPP=cc -E CC=cc mkdep -a -f .newdep -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/home/usr.src/sys -I/home/usr.src/sys/dev -I/home/usr.src/sys/contrib/dev/acpica -I/home/usr.src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding /home/usr.src/sys/netkey/keysock.c But if I remove '-march=pentiumpro', cpp0 doesn't crash. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel won't boot - ACPI Problem ?
Hi Folks, I was unable to boot the kernel for sometime, so I tried doing an unset acpi_load and the kernel booted fine. The kernel would hang after reaching Timecounter as show below. --- Sep 13 18:20:09 calvin kernel: unknown: PNP0501 can't assign resources (port) Sep 13 18:20:09 calvin kernel: unknown: PNP0401 can't assign resources (port) Sep 13 18:20:09 calvin kernel: unknown: PNP0c02 can't assign resources (port) Sep 13 18:20:09 calvin kernel: Timecounters tick every 10.000 msec --- My System Info --- Sep 13 18:20:09 calvin kernel: Timecounter i8254 frequency 1193182 Hz Sep 13 18:20:09 calvin kernel: Timecounter TSC frequency 996769445 Hz Sep 13 18:20:09 calvin kernel: CPU: Pentium III/Pentium III Xeon/Celeron (996.77-MHz 686-class CPU) Sep 13 18:20:09 calvin kernel: Origin = GenuineIntel Id = 0x68a Stepping = 10 Sep 13 18:20:09 calvin kernel: Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Sep 13 18:20:09 calvin kernel: real memory = 267255808 (260992K bytes) Sep 13 18:20:09 calvin kernel: avail memory = 253181952 (247248K bytes) --- uname - 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Sep 19 17:11:41 IST 2002 root@calvin:/usr/obj/usr/src/sys/GENERIC i386 My Kernel boots fine, if I disable acpi. Is there something wrong with ACPI and kernel right now ? Is there a fix to this ? i.e. apart from disabling acpi. TIA Regards Sid -- What is worth doing is worth the trouble of asking somebody to do. Sid Carter - http://symonds.net/~sidcarter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- === secure/lib/libssl make: don't know how to make openssl/ssl.h. Stop *** Error code 2 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: boot -c ?
elitetek boot -c on DP1, and the latest snapshots doesnt seem to do elitetek anything, I have been unable to find any info regarding a elitetek change to the command or what other switches it supports. Userconfig was gone away in 5-current. Tweak /boot/device.hints instead, or set appropriate variable with loader(8) prompt. Tweaking hints.* via loader(8) is not yet implemented (actually patch is available, but not yet committed and/or reviewed.) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ALTQ status?
does anyone know the status of the ALTQ merge? I checked the webpage (http://www.rofug.ro/projects/freebsd-altq/), and it was last updated on August 25th, but 5.0 (and especially its feature freeze) is creeping up quickly, and there's no mention of ALTQ in the -current release notes (http://people.freebsd.org/~bmah/relnotes/CURRENT/relnotes-i386.html). I don't have a machine to run -current on, so I don't have the source code; and I couldn't find anything about ALTQ in the mailing list archives. anyone have a line on this? thanks, chris --- Chris Doherty chris [at] randomcamel.net I think, said Christopher Robin, that we ought to eat all our provisions now, so we won't have so much to carry. -- A. A. Milne --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
xmms
Is anyone else still having issues with xmms? i get a segfault and core dump when i try to run int on -CURRENT with the new source. Just wondering, it looks like the same error that noatun was giving for a while, when i looked in the list archives, maybe there was a patch sorry if i missed that. Thanks Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld failure in openssl?
I'm trying to upgrade a ~March -current machine to a more modern version. Buildworld is dying like this: stage 4: building libraries -- .. === secure/lib/libssl mkdir -p openssl sh /usr/src/tools/install.sh -C -m 444 /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/dso/dso.h openssl mkdir -p openssl sh /usr/src/tools/install.sh -C -m 444 /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/conf/conf_api.h openssl make: don't know how to make openssl/ssl.h. Stop *** Error code 2 I've gone so far as to rm -rf my source tree and re-check it out. Nothing in UPDATING jumps out at me. Does anybody have any ideas? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in openssl?
On Thu, Sep 19, 2002 at 04:11:00PM -0400, Andrew Gallatin wrote: I'm trying to upgrade a ~March -current machine to a more modern version. Buildworld is dying like this: I think ru fixed this earlier this morning. I don't know why it suddenly broke, because no-one's touched openssl in a while. Kris msg43080/pgp0.pgp Description: PGP signature
Re: buildworld failure in openssl?
Nope, but i see that here. DES reported it too, but we get some many 'tinderbox failures' from him that some people might just ignore them =) On Thu, 19 Sep 2002, Andrew Gallatin wrote: I'm trying to upgrade a ~March -current machine to a more modern version. Buildworld is dying like this: stage 4: building libraries -- .. === secure/lib/libssl mkdir -p openssl sh /usr/src/tools/install.sh -C -m 444 /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/dso/dso.h openssl mkdir -p openssl sh /usr/src/tools/install.sh -C -m 444 /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/conf/conf_api.h openssl make: don't know how to make openssl/ssl.h. Stop *** Error code 2 I've gone so far as to rm -rf my source tree and re-check it out. Nothing in UPDATING jumps out at me. Does anybody have any ideas? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in openssl?
It seems Kris Kennaway wrote: On Thu, Sep 19, 2002 at 04:11:00PM -0400, Andrew Gallatin wrote: I'm trying to upgrade a ~March -current machine to a more modern version. Buildworld is dying like this: I think ru fixed this earlier this morning. I don't know why it suddenly broke, because no-one's touched openssl in a while. Nope, it still fails on a fresh cvsup -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: xmms
On 19-Sep-2002 BSDNerds Lists wrote: Is anyone else still having issues with xmms? i get a segfault and core dump when i try to run int on -CURRENT with the new source. Just wondering, it looks like the same error that noatun was giving for a while, when i looked in the list archives, maybe there was a patch sorry if i missed that. Thanks Which version? 1.2.7 is working fine for me on -current about a week old. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- === secure/lib/libssl make: don't know how to make openssl/ssl.h. Stop *** Error code 2 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in openssl?
On Thu, Sep 19, 2002 at 10:38:57PM +0200, Soeren Schmidt wrote: It seems Kris Kennaway wrote: On Thu, Sep 19, 2002 at 04:11:00PM -0400, Andrew Gallatin wrote: I'm trying to upgrade a ~March -current machine to a more modern version. Buildworld is dying like this: I think ru fixed this earlier this morning. I don't know why it suddenly broke, because no-one's touched openssl in a while. Nope, it still fails on a fresh cvsup Okay, it sounds like a better explanation is it was working fine until ru broke it :-) Kris msg43085/pgp0.pgp Description: PGP signature
Request for review testing of VFS locking patch
I have a patch available at http://www.chesapeake.net/~jroberson/vfssmp.diff that locks the majority of the vnode fields. The namecache locking has been omitted from this patch. The locking has been specified in vnode.h and all interlock, syncer, and vn lock usage has been verified. Any places that are unlocked now should be marked with mp_fixme's. This patch touches every filesystem. I have tested with several but I would appreciate more extensive testing especially if you use one of the lesser used filesystems (ie non ufs). Please test with WITNESS and DEBUG_VFS_LOCKS enabled. If you find that it drops into the debugger please get a back trace and then do the following: w vfs_badlock_panic 0 w vfs_badlock_print 0 w vfs_badlock_mutex 0 Currently I know that sendfile() and the UFS snapshot code fail assertions. There are many diffs that just switch from explicit mtx ops to using the new VI_*LOCK macros. I did this only in places where I actually reviewed the code. The remaining direct v_interlock accesses serve as indicators of behavior that needs to be further verified. I also have not verified usage of the mntvnode mtx or the freelist mutex etc. There may be racees there. I did, however, fixup the broken vflush() mntvnode race. Once this has been commited I will be free to lock the rest of the vnode and then move on to other filesystem related datastructures. My goal is to have the high level VFS and at least some filesystems SMP safe for 5.0. Any feedback is welcome. Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in openssl?
Kris Kennaway writes: suddenly broke, because no-one's touched openssl in a while. That's why I thought it was local.. Of course, the very next message I got after sending my query was DES's tinderbox failure ;) Thanks for the info. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure in openssl?
I get the same on a more recent build. siksika# make buildworld ... mkdir -p openssl sh /usr/src/tools/install.sh -C -m 444 /usr/src/secure/lib/libssl/../../../crypto/openssl/crypto/conf/conf_api.h openssl make: don't know how to make openssl/ssl.h. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. siksika# uname -a FreeBSD siksika.nic-naa.net 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Wed Sep 18 18:44:52 EDT 2002 [EMAIL PROTECTED]:/usr/obj/config/SIKSIKA-SMP i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dc(4) patch
A while ago I started having problems with a dc(4) cardbus card that
I hadn't had before. Lots of failures to force tx and rx to idle
state resulting in the card eventually hanging under load and
basically being worthless until I ejected it and reinserted it.
ifconfig up/down, etc. didn't help. So I bought a new dc(4) cardbus
card and it had the same problems. First card:
dc0: Abocom FE2500 10/100BaseTX port 0x1100-0x11ff mem 0x88002000-0x880023ff irq 11
at device 0.0
on cardbus0
(really a LinkSys PCMP100 or some such) Second card:
dc0: Accton EN2242 MiniPCI 10/100BaseTX port 0x1100-0x11ff mem 0x88002000-0x880023ff
irq 11 at
device 0.0 on cardbus0
(really a SpeedStream SS1012). The patch below fixed the hangs
on both cards:
--- if_dc.c 4 Sep 2002 18:14:17 - 1.77
+++ if_dc.c 19 Sep 2002 20:57:03 -
@@ -1366,7 +1370,8 @@
for (i = 0; i DC_TIMEOUT; i++) {
isr = CSR_READ_4(sc, DC_ISR);
if (isr DC_ISR_TX_IDLE
- (isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED)
+ ((isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED ||
+(isr DC_ISR_RX_STATE) == DC_RXSTATE_WAIT))
break;
DELAY(10);
}
The automatic TX underrun recovery stuff didn't make a bit of difference
for the SpeedStream card FWIW. Also, unlike one of the PR's which claimed
that the SpeedStream SS1020 (PCI adapter rather than cardbus card), the
dc(4) driver read the right MAC address just fine w/o the need for any
changes.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
Hi John, See the patch I've submitted last week or previous week. Topic was uncomitted dc0 PR's. I had a patch for this there. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: xmms
Yeah its all brand new, i disreguarded it at first and thought it may have had something to do with the gcc patch i used on the cp-lang.cpp file to get kde to compile. So ounce i saw that the new pre-release source went final I cvsuped ports and src, and recompiled and tried again. it compiles file, just won't run. uname -a FreeBSD peaches 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Sep 18 23:06:03 PDT 2002 tr0n@peaches:/usr/obj/usr/src/sys/PEACHES i386 xmms -v xmms 1.2.7 pkg_info | grep xmms xmms-esound-1.2.7_2 X Multimedia System --- An audio player with a Winamp GUI xmms Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) Abort (core dumped) On Thu, 2002-09-19 at 13:41, John Baldwin wrote: On 19-Sep-2002 BSDNerds Lists wrote: Is anyone else still having issues with xmms? i get a segfault and core dump when i try to run int on -CURRENT with the new source. Just wondering, it looks like the same error that noatun was giving for a while, when i looked in the list archives, maybe there was a patch sorry if i missed that. Thanks Which version? 1.2.7 is working fine for me on -current about a week old. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
Hi John, Your patch looks correct ! Thanks to finding this out. Can you commit this or do you wait for McKay ? Or should I ;-) ? Ps: the automatic TX underrun recovery still needs to be comitted. Without it no cvsup survives here. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On 19-Sep-2002 Martin Blapp wrote: Hi John, See the patch I've submitted last week or previous week. Topic was uncomitted dc0 PR's. I had a patch for this there. IIRC, yours completely disabled the check. It would seem to make good sense to still try to force the card idle before dinking with DC_NETCFG, but to allow that some cards may be reporting a status of WAIT instead of STOPPED when the receiver is idle. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On Thu, 19 Sep 2002, John Baldwin wrote:
A while ago I started having problems with a dc(4) cardbus card that
I hadn't had before. Lots of failures to force tx and rx to idle
state resulting in the card eventually hanging under load and
basically being worthless until I ejected it and reinserted it.
ifconfig up/down, etc. didn't help. So I bought a new dc(4) cardbus
card and it had the same problems. First card:
dc0: Abocom FE2500 10/100BaseTX port 0x1100-0x11ff mem 0x88002000-0x880023ff irq
11 at device 0.0
on cardbus0
(really a LinkSys PCMP100 or some such)
Second card:
dc0: Accton EN2242 MiniPCI 10/100BaseTX port 0x1100-0x11ff mem
0x88002000-0x880023ff irq 11 at
device 0.0 on cardbus0
(really a SpeedStream SS1012). The patch below fixed the hangs
on both cards:
--- if_dc.c 4 Sep 2002 18:14:17 - 1.77
+++ if_dc.c 19 Sep 2002 20:57:03 -
@@ -1366,7 +1370,8 @@
for (i = 0; i DC_TIMEOUT; i++) {
isr = CSR_READ_4(sc, DC_ISR);
if (isr DC_ISR_TX_IDLE
- (isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED)
+ ((isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED ||
+(isr DC_ISR_RX_STATE) == DC_RXSTATE_WAIT))
break;
DELAY(10);
}
The automatic TX underrun recovery stuff didn't make a bit of difference
for the SpeedStream card FWIW. Also, unlike one of the PR's which claimed
that the SpeedStream SS1020 (PCI adapter rather than cardbus card), the
dc(4) driver read the right MAC address just fine w/o the need for any
changes.
I think the first card is a LinkSys PCMP200 and not the PCMP100
since the 100 is a 16bit PCMCIA and runs as a ed1 adapter in 4.6.2-RELEASE
but doesn't get recognized at all under -current. I've tried both the
LinkSys PCMP200 v2.0/PCMPC200 v2.0 and the NetGear FA511 Cardbus NICs but
they don't get recognize under -current either. The SpeedStream SS1012
card is identical to the SMC Networks SMC8036TX card which is $US10
cheaper and comes with a lifetime warranty versus the SpeedStream 1 year
warranty. However, I noticed that using either the SS1012 or the
SMC8036TX which I am doing now is that there seems to be a lot of errors.
root@bigbang [3:36pm][/usr/home/vince] netstat -s
tcp:
505575 packets sent
120454 data packets (143749591 bytes)
76 data packets (34453 bytes) retransmitted
6 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
276069 ack-only packets (1497 delayed)
0 URG only packets
0 window probe packets
106651 window update packets
2325 control packets
678552 packets received
67126 acks (for 143703608 bytes)
623 duplicate acks
0 acks for unsent data
612664 packets (686204656 bytes) received in-sequence
67 completely duplicate packets (48111 bytes)
0 old duplicate packets
19 packets with some dup. data (3318 bytes duped)
1262 out-of-order packets (1474923 bytes)
0 packets (0 bytes) of data after window
0 window probes
367 window update packets
8 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
1823 connection requests
307 connection accepts
6 bad connection attempts
0 listen queue overflows
557 connections established (including accepts)
2305 connections closed (including 51 drops)
38 connections updated cached RTT on close
38 connections updated cached RTT variance on close
13 connections updated cached ssthresh on close
1564 embryonic connections dropped
66488 segments updated rtt (of 65063 attempts)
66 retransmit timeouts
1 connection dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
23 keepalive timeouts
23 keepalive probes sent
0 connections dropped by keepalive
45309 correct ACK header predictions
606682 correct data packet header predictions
309 syncache entries added
0 retransmitted
2 dupsyn
0 dropped
307 completed
0 bucket overflow
0 cache overflow
2 reset
0 stale
0 aborted
0 badack
0 unreach
0 zone failures
0 cookies sent
0 cookies
mozilla busted?
% mozilla Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file /dell/imp/p4/newcard/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) Ideas? I'm using mozilla 1.0_2,1 according to the directory in /var/db/pkg. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel crash at boot time
On Thursday 19 September 2002 17:03, Poul-Henning Kamp wrote:
Can you try with rev. 1.101 of sys/kern/uipc_mbuf.c please ? The
1.102... is wrong and could easily cause this.
Poul-Henning
In message 01be01c25fb1$8b92a990$ef01a8c0@davidwnt, David Xu writes:
#11 0xc02fca38 in calltrap () at {standard input}:98
#12 0xc022b699 in sbappendaddr (sb=0xc272fbec, asa=0xc038c9f8,
m0=0xc0f14e00, control=0x0) at ../../../kern/uipc_socket2.c:624
rev. 1.101 works fine.
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
On Fri, 2002-09-20 at 10:34, M. Warner Losh wrote: % mozilla Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file /dell/imp/p4/newcard/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) Ideas? I'm using mozilla 1.0_2,1 according to the directory in /var/db/pkg. I think mini broke threads recently. Been fixed even more recently too. I believe you can work around it by booting an older kernel.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
Is it statically linked? On Thu, 19 Sep 2002, M. Warner Losh wrote: % mozilla Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file /dell/imp/p4/newcard/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) Ideas? I'm using mozilla 1.0_2,1 according to the directory in /var/db/pkg. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- === secure/lib/libssl make: don't know how to make openssl/ssl.h. Stop *** Error code 2 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : Is it statically linked? Yup. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
On Thu, 2002-09-19 at 23:22, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : Is it statically linked? Yup. You'll need to rebuild against the new libc_r, then. Joe Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
In message: [EMAIL PROTECTED] Joe Marcus Clarke [EMAIL PROTECTED] writes: : On Thu, 2002-09-19 at 23:22, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Julian Elischer [EMAIL PROTECTED] writes: : : Is it statically linked? : : Yup. : : You'll need to rebuild against the new libc_r, then. Yuck. I'd rather nail jello to a tree than try to update a port that complicated. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
On Thu, 2002-09-19 at 23:38, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Joe Marcus Clarke [EMAIL PROTECTED] writes: : On Thu, 2002-09-19 at 23:22, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Julian Elischer [EMAIL PROTECTED] writes: : : Is it statically linked? : : Yup. : : You'll need to rebuild against the new libc_r, then. Yuck. I'd rather nail jello to a tree than try to update a port that complicated. If it makes you feel better, I just ran a compile on my -CURRENT machine, and it went fine. Both mozilla and mozilla-devel should build out of the treewith or without jello. Joe Warner -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ssl.h world breakage... fix coming??
On Thu, Sep 19, 2002 at 11:48:06PM -0400, Wesley Morgan wrote: This has been mentioned several times now... Surely the fix is trivial :) Is anything in the works? I expect ru will fix it when he wakes up. In the meantime you can just back out his changes. Kris msg43104/pgp0.pgp Description: PGP signature
Re: mozilla busted?
In message: [EMAIL PROTECTED] Joe Marcus Clarke [EMAIL PROTECTED] writes: : On Thu, 2002-09-19 at 23:38, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Joe Marcus Clarke [EMAIL PROTECTED] writes: : : On Thu, 2002-09-19 at 23:22, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : : Julian Elischer [EMAIL PROTECTED] writes: : : : Is it statically linked? : : : : Yup. : : : : You'll need to rebuild against the new libc_r, then. : : Yuck. I'd rather nail jello to a tree than try to update a port that : complicated. : : If it makes you feel better, I just ran a compile on my -CURRENT : machine, and it went fine. Both mozilla and mozilla-devel should build : out of the treewith or without jello. Do you know if this breaks libc_r.so.4.0 too? I'm thinking of just grabbing the build from Mozilla.org... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
On Thu, 19 Sep 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Joe Marcus Clarke [EMAIL PROTECTED] writes: : On Thu, 2002-09-19 at 23:38, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Joe Marcus Clarke [EMAIL PROTECTED] writes: : : On Thu, 2002-09-19 at 23:22, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : : Julian Elischer [EMAIL PROTECTED] writes: : : : Is it statically linked? : : : : Yup. : : : : You'll need to rebuild against the new libc_r, then. : : Yuck. I'd rather nail jello to a tree than try to update a port that : complicated. : : If it makes you feel better, I just ran a compile on my -CURRENT : machine, and it went fine. Both mozilla and mozilla-devel should build : out of the treewith or without jello. Do you know if this breaks libc_r.so.4.0 too? I'm thinking of just grabbing the build from Mozilla.org... I think it does since it's a kernel ABI breakage in ucontext_t's and sigreturn(). I think we either need to reformat the ucontext_t in some way that is compatible with the old format, or make a new sigreturn() using the current one for compatibility. It's a shame 'cause it's only broken for i386, not the other archs. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
In message: [EMAIL PROTECTED] Daniel Eischen [EMAIL PROTECTED] writes: : On Thu, 19 Sep 2002, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Joe Marcus Clarke [EMAIL PROTECTED] writes: : : On Thu, 2002-09-19 at 23:38, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : : Joe Marcus Clarke [EMAIL PROTECTED] writes: : : : On Thu, 2002-09-19 at 23:22, M. Warner Losh wrote: : : : In message: :[EMAIL PROTECTED] : : : Julian Elischer [EMAIL PROTECTED] writes: : : : : Is it statically linked? : : : : : : Yup. : : : : : : You'll need to rebuild against the new libc_r, then. : : : : Yuck. I'd rather nail jello to a tree than try to update a port that : : complicated. : : : : If it makes you feel better, I just ran a compile on my -CURRENT : : machine, and it went fine. Both mozilla and mozilla-devel should build : : out of the treewith or without jello. : : Do you know if this breaks libc_r.so.4.0 too? I'm thinking of just : grabbing the build from Mozilla.org... : : I think it does since it's a kernel ABI breakage in ucontext_t's : and sigreturn(). I think we either need to reformat the ucontext_t : in some way that is compatible with the old format, or make a : new sigreturn() using the current one for compatibility. It's : a shame 'cause it's only broken for i386, not the other archs. I think that would be an excellent idea. I think that there are enough libc_r applications for 4.x that we need to retain binary compatibility at this level. Otherwise we're going to be raked over the coals. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bpf and xl0: lock order reversal?
Hi, I recently did a tcpdump on my xl0 interface (Etherlink XL) on my -current setup. This message showed up in the console: lock order reversal 1st 0xc0553780 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:378 2nd 0xc129dbd4 xl0 (network driver) @ /usr/src/sys/pci/if_xl.c:2905 What does this mean? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ssl.h world breakage... fix coming??
This has been mentioned several times now... Surely the fix is trivial :) Is anything in the works? -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
On Fri, Sep 20, 2002 at 10:49:55AM +0930, Daniel O'Connor wrote: On Fri, 2002-09-20 at 10:34, M. Warner Losh wrote: % mozilla Fatal error '_pq_insert_head: prioq not protected!' at line 185 in file /dell/imp/p4/newcard/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 22) Ideas? I'm using mozilla 1.0_2,1 according to the directory in /var/db/pkg. I think mini broke threads recently. Been fixed even more recently too. I believe you can work around it by booting an older kernel.. ... or fresh cvsup cd /usr/src/lib/libc_r/ make make install no reboot and mozilla and dillo started to work again. Ants To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
I think (but I'm not sure) that jon introduced a binary incompatibility in his last commit. BDE could probably give more info. (I know zip about the FP stuff) people with dynamically linked things with the matching libc_r probably are ok. We are working for a resolution On Thu, 19 Sep 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : Is it statically linked? Yup. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla busted?
In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : We are working for a resolution Cool. Glad to see it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Daniel Eischen wrote: On Thu, 19 Sep 2002, Julian Elischer wrote: On Thu, 19 Sep 2002, Daniel Eischen wrote: Ok so I reconnected the libc_r and fixed it to compile. I'm a littel uncomfortable because the new kernel behaviour means that 4.x statically compiled threaded binaries will not work right because we've changed the kernel ABI in an incompatible way.. We need to discuss this carefully when mini gets back to see if there is a way out.. I brought this up with bde before. My suggestion was to create another sigreturn(), so we'd have osigreturn(), osigreturn2(), and [new] sigreturn(). He didn't like this. I think we'd need another sendsig() too. When mini adds setcontext() as a system call, this can make sigreturn() obsolete. The signal trampoline can call setcontext() instead of sigreturn() and sigreturn() can handle the old format... We still need a different sendsig() though. Unfortunately, we didn't get expansion of the i386 mcontext_t to make room for SSE, into 4.0, and the problem has been mostly ignored since then. Looks like it is a large problem. The things we might have to do to keep compatibile with old applications are similar to the things that might be necessary for efficiency. sendsig() and sigreturn() spend a lot of time copying out and in large amounts of state that are never really used, especially by old applications that cannot know about the new state. Optimizations would involve not copying it all, and compatibilty would also involve not even leaving space for copying it all. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
Bruce Evans wrote: Unfortunately, we didn't get expansion of the i386 mcontext_t to make room for SSE, into 4.0, and the problem has been mostly ignored since then. Looks like it is a large problem. Any chance of avoiding this in the future by adding an extensible, but known to be suboptimal if used extension field, so that these kind of changes can be made without having to change anything important to the point of incompatability? That type of thing would let the problem be fixed in an ugly way, but at least it would be fixed, without balancing things on a knife's edge of incompatability vs. non-working code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Terry Lambert wrote: Bruce Evans wrote: Unfortunately, we didn't get expansion of the i386 mcontext_t to make room for SSE, into 4.0, and the problem has been mostly ignored since then. Looks like it is a large problem. Any chance of avoiding this in the future by adding an extensible, but known to be suboptimal if used extension field, so that these kind of changes can be made without having to change anything important to the point of incompatability? That type of thing would let the problem be fixed in an ugly way, but at least it would be fixed, without balancing things on a knife's edge of incompatability vs. non-working code. That's kind of the point of adding the fields that we did (mc_len, mc_fpformat). They can be used to help validate the contents and to allow extensions. We also have some spare slots, but the last incarnation of ucontext_t also had spare slots and it wasn't nearly enough for what we now need. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: page fault while in kernel mode, cam related ?
uhm, i just got another one. i guess the hd is broken and also managed to cause the previous panic. Can you do a: cd /usr/src/sys/i386/compile/MYKERNEL gdb -k kernel.debug l *(ahc_dump_card_state+0x692) and give me the output. Thanks, Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
Daniel Eischen wrote:
That's kind of the point of adding the fields that we did
(mc_len, mc_fpformat). They can be used to help validate
the contents and to allow extensions. We also have some
spare slots, but the last incarnation of ucontext_t also
had spare slots and it wasn't nearly enough for what we
now need.
I was thinking more along the lines of:
struct extend {
struct extend *next; /* Next extension in list */
int32_t id; /* extension ID */
charcrap[1];/* extension specific data */
};
And then adding:
struct extend *extensions;
Yeah, if it's non-NULL, it means a linear list traversal to find
relevent extensions, but that's better than non-working.
String-to-id translation is a seperate function, and can also use
a linear list traversal to find the string, get an ID back, and
then subsequqnetly use the ID. Yeah, it's an extra contents
dereference, but it's better than non-working.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: page fault while in kernel mode, cam related ?
On Thu, Sep 19, 2002 at 04:31:26PM -0600, Justin T. Gibbs wrote: uhm, i just got another one. i guess the hd is broken and also managed to cause the previous panic. Can you do a: cd /usr/src/sys/i386/compile/MYKERNEL gdb -k kernel.debug l *(ahc_dump_card_state+0x692) and give me the output. I'm sorry but i replaced the hd and as it survided the buildworld discarded the old one. I still have the compile-directory of the kernel the old hd began to fail under but that's all. Would the output still be usefull ? If yes old kernel (-current as of Sep 2) or new kernel (-current as of yesterday) ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: page fault while in kernel mode, cam related ?
Can you do a: cd /usr/src/sys/i386/compile/MYKERNEL gdb -k kernel.debug l *(ahc_dump_card_state+0x692) and give me the output. I'm sorry but i replaced the hd and as it survided the buildworld discarded the old one. I still have the compile-directory of the kernel the old hd began to fail under but that's all. Would the output still be usefull ? Yes. If yes old kernel (-current as of Sep 2) or new kernel (-current as of yesterday) ? The kernel from when the failure occurred would be best, but even a more recent kernel should give similar results. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: slapd dumping core with today's current.
On Thu, 19 Sep 2002, Terry Lambert wrote:
Daniel Eischen wrote:
That's kind of the point of adding the fields that we did
(mc_len, mc_fpformat). They can be used to help validate
the contents and to allow extensions. We also have some
spare slots, but the last incarnation of ucontext_t also
had spare slots and it wasn't nearly enough for what we
now need.
I was thinking more along the lines of:
struct extend {
struct extend *next; /* Next extension in list */
int32_t id; /* extension ID */
charcrap[1];/* extension specific data */
};
And then adding:
struct extend *extensions;
Yeah, if it's non-NULL, it means a linear list traversal to find
relevent extensions, but that's better than non-working.
String-to-id translation is a seperate function, and can also use
a linear list traversal to find the string, get an ID back, and
then subsequqnetly use the ID. Yeah, it's an extra contents
dereference, but it's better than non-working.
Some of the extensions need to be understood by userland, so I think you
don't want it that complicated. Setting up userland pointers in the kernel
is hard enough without having to keep it backwards compatible. The kernel
would also have to worry about userland clobbering the pointers before it
follows them in sigreturn().
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
