already done it.
>
> --
>
> John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
hope this won't increase per-thread memory requirement, I would like
to create more t
I found the problem two weeks ago, but I can not find a better way to
avoid userret() to be called twice. so I keep silence. :(
David Xu
Gartner: Apache is vulnerable, we recommend switching back to IIS to protect yourselves
- Original Message -
From: "Julian Elischer&quo
I'll work out a patch to see if my idea works.
David Xu
--- John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On 08-Jul-2002 David Xu wrote:
> > I want to set an flag bit CALLOUT_PROCESSING in callout.c_flags,
> > before softclock() releases callout_lock and start reques
callout_stop thread, of course, if
callout_stop is being called in softclock() thread, it should avoid
waiting, it is easy to detect.
David Xu
- Original Message -
From: "John Baldwin" <[EMAIL PROTECTED]>
To: "David Xu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PRO
Here, if I "enable nat yes" in /etc/ppp/ppp.conf and forget to turn
net.inet.ip.forwarding on, ppp will core dump in several minutes.
David Xu
--- "Richard Seaman, Jr." <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 08, 2002 at 07:08:58AM -0700, David Xu wrote:
> >
--- John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On 07-Jul-2002 Jonathan Lemon wrote:
> > On Sat, Jul 06, 2002 at 11:59:50PM -0700, David Xu wrote:
> >> Jonthan,
> >>
> >> I just use DOS program as an example, for any program, if it wants to go
>
you have turned on "nat enable yes" in ppp.conf,
and but you havn't turned ip_foward on in sysctl,
so core dumped.
David Xu
- Original Message -
From: "Richard Seaman, Jr." <[EMAIL PROTECTED]>
To: "Luigi Rizzo" <[EMAIL PROTECTED]>
Cc:
;
> Excuse me while I go outside and shoot myself.
>
> Cheers,
> -Peter
> --
> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> "All of this is for nothing if we don't go to the stars" - JMS/B5
sorry for a bit OT, but why are pmap_mapdev and pmap_unm
the trap
as it is running vm86_intcall(), but it is not true and make a mess.
David Xu
--- Jonathan Lemon <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 06, 2002 at 05:15:26AM -0700, David Xu wrote:
> >
> > I don't know how DOS emulating program works, but if
--- David Schultz <[EMAIL PROTECTED]> wrote:
> Thus spake David Xu <[EMAIL PROTECTED]>:
> > I don't know if FreeBSD can run DOS program, if it can, then one CPU
> running
> > DOS program can confuse another CPU which is running BIOS code because of
> this
> Jonathan
I don't know if FreeBSD can run DOS program, if it can, then one CPU running
DOS program can confuse another CPU which is running BIOS code because of this
global flags.
my current patch does not remove vm86_lock, it is still there, my orginal
s in_vm86call crazy global variable?
it prevents two CPUs to trap into VM86 model :(
if you have interest in fixing this problem, please have a look at PR :
http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/38223
I have also fixed the problem that VM86 call is preempted by interrupt
threads and causes
s in_vm86call crazy global variable?
it prevents two CPUs to trap into VM86 model :(
if you have interest in fixing this problem, please have a look at PR :
http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/38223
I have also fixed the problem that VM86 call is preempted by interrupt
threads and causes
);
sig = cursig(td);
if (thread_suspend_check(1)) {
- sig = EINTR;
- rval = EINTR;
+ sig = SIGSTOP;
}
mtx_lock_spin(&sched_lock);
PROC_UNLOCK(p);
-Davi
home, I must send
it from yahoo. :(
-David Xu
- Original Message -
From: "Bruce Evans" <[EMAIL PROTECTED]>
To: "David Xu" <[EMAIL PROTECTED]>
Cc: "Julian Elischer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, July 04, 2
- Original Message -
From: "Julian Elischer" <[EMAIL PROTECTED]>
To: "David Xu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
>
>
> On Thu, 4 Jul 2002, David Xu
mi_switch() and
modify td_flags is also unacceptable, this SMP race should be resolved in
kern_timeout.c.
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Andrew Gallatin fixed the problem in kern_sig.c, check it out:
gallatin2002/07/02 19:55:48 PDT
Modified files:
sys/kern kern_sig.c
Log:
Hold the sched lock across call to forward_signal() in tdsignal() to
keep SMP systems from panic'ing when ^C'ing an app
sugge
bug is because cv_timedwait() detects timeout callout is running,
but it does not correctly wait callout to complete, so panic.
BTW, the bug seems also exists in msleep() and endtsleep(), please
fix it!
-David Xu
--- David Xu <[EMAIL PROTECTED]> wrote:
&g
in NgRecvData ()
#10 0x0804d1a5 in NgRecvData ()
#11 0x0806d7e7 in NgRecvData ()
#12 0x0806d700 in NgRecvData ()
#13 0x0804b5c9 in NgRecvData ()
(gdb) quit
-David Xu
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworld
cv_timedwait_end(), sentence "if (td->td_flags & TDF_TIMEOUT) {...}"
is to check this race condition.
-David Xu
- Original Message -
From: "Matthew Dillon" <[EMAIL PROTECTED]>
To: "Julian Elischer" <[EMAIL PROTECTED]>
Cc: "Steve Kargl&quo
long time ago, I posted a PR reported that VM86 and VESA combination is
unstable
under CURRENT source, the PR is
http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/38223
The patch is synchronized with current source, here it is:
http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz
- David Xu
Current source in ipfw was broken:
cc -O -pipe -DIPFIREWALL -D_KERNEL -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include
-fno-common -g
it complains that thread has some non-sleepable lock held.
it seems process lock can not be held when calling uma_zalloc_arg() which calls
WITNESS_SLEEP(1, NULL) to check if there is non-sleepable lock held.
David Xu
- Original Message -
From: "Julian Elischer" <[EM
Thank you very much.
After I sent previous question to you, I was still thinking the mail.
and last night when I went to bed, I suddenly found that I was wrong,
choosethread() selects a highest priority thread from queue, if it is
the lastest assigned thread, there is of course no more thread as
Sorry for this OT, I found a point in kern_switch.c, when choosethread() runs,
you reset kg_last_assigned to NULL, I suspect it is incorrect, should it be:
--- kern_switch.c.orig Sun Jun 2 14:52:24 2002
+++ kern_switch.c Sun Jun 2 14:53:28 2002
@@ -67,7 +67,9 @@
Yesterday 'cvs update' and 'make world' causes BTX halted:
int=000e err=0002 efl=00010002 eip=c02cdeec
eax=0001 ebx=003b9c00 ecx=01ff edx=10fc
esi=003b9001 edi=003c1000 ebp= esp=c03bcd99
cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010
cs:eip=10 44 17 fe 14 80 58 8
#x27;p4newuser'
> command on freefall is what is run to activate it. If we want a majordomo
> [EMAIL PROTECTED] mailing list (or something like that, as an analog to
> [EMAIL PROTECTED]), I can have that set up as well.
>
Sorry for a bit OT, is Perforce a free software? if it
I persist with adding "cc", because it does not hurt anything.
--
David Xu
John Baldwin wrote:
>On 13-Dec-01 Bruce Evans wrote:
>
>>>--- i386/i386/identcpu.c 30 Nov 2001 11:57:23 - 1.96
>>>+++ i386/i386/identcpu.c 6 Dec 2001 07:58:25 -
&
happens in booting time.
--
David Xu
Emiel Kollof wrote:
>>From my dmesg:
>pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC
>
>What does that mean? Is it a bug?
>(dmesg attached)
>
>
>-
r files.
Any plan to MFC? I am interesting to see it in 4.3-RELEASE.
--
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Hello Julian,
Friday, March 16, 2001, 12:18:15 PM, you wrote:
JE> David Xu wrote:
>>
>>I wonder status of KSE, I am dreaming rewrite our application
>> server using kqueue+pthread(KSE), current, we use poll()+pthread
>> because pthread does not
I wonder status of KSE, I am dreaming rewrite our application
server using kqueue+pthread(KSE), current, we use poll()+pthread
because pthread does not work with kqueue at present.
--
Best regards,
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-cu
101 - 133 of 133 matches
Mail list logo
