http://www.fun-club.net
ù³¿Åøò¶g 18Ë¢¨fè ù}jAK©ù©aJüÓÌgGb`GAL`ÏÔlÈC y¨300¼zøòy¶'ÈÜ'Gb`z Ê^tOrA³¿ÅwèZÖ}ù© ù´ØrfIùsû^±s! yÆENO1Ìiµ¦}jAbNz ³¿Åêx©Äù© ¢ù±ÆA Úùvhttp://www.fun-club.net aJt@Nu ùËI`ç¢ù ùyHzùy¶zùùùùùùùùù To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vm_zeropage priority problems.
On Thu, 20 Dec 2001, John Baldwin wrote: On 20-Dec-01 Luigi Rizzo wrote: On Thu, Dec 20, 2001 at 12:16:03PM -0800, John Baldwin wrote: However, kthreads should tsleep() with their current priority, not PPAUSE. current meaning pri_level or pri_native ? What if one tries to tsleep() while holding a lock and so its pri_level is raised ? pri_level. Calling tsleep() while holding a lock is a bug though. :) Unless you are calling msleep() with a lock that will be released. In the device polling code i did a tsleep on the original pri_level, but maybe pri_native is good enough. pri_level is more correct. I think pri_native is just an implementation detail which shouldn't be used or visible to threads. It used used by the priority propagation mechanism to hold the original pri_level. Threads should just use their original priority (or a different one if they want to temporarily change thier priority). Even pri_level probably shouldn't be used or visible to threads. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm_zeropage priority problems.
On Sat, Dec 22, 2001 at 12:46:40AM +1100, Bruce Evans wrote: I think pri_native is just an implementation detail which shouldn't be used or visible to threads. It used used by the priority propagation mechanism to hold the original pri_level. Threads should just use their original priority (or a different one if they want to temporarily change thier priority). Even pri_level probably shouldn't be used or visible to threads. the original priority should be somewhere and accessible, either directly or through some function. Otherwise how do we know what to pass to tsleep() ? In any case I wonder if this is a bug new in -current; -stable uses three separate data structures for realtime, user and idle tasks so even specifying the wrong priority in tsleep should not cause crossing classes there. -current has only one array, hence the chance of doing the wrong thing. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FYI: Panic at in_pcbremlists()
I got a panic with today's current. I don't know I can reproduce this panic or not... Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0214186 stack pointer = 0x10:0xe519cc88 frame pointer = 0x10:0xe519cc8c 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 = 13 (swi6: tty:sio clock) kernel: type 12 trap, code=0 Stopped at in_pcbremlists+0x82:movl%eax,0x4(%edx) db Context switches not allowed in the debugger. db trace in_pcbremlists(e9fb11e0,e9fb11e0,0,e9fb12a0,e9fb11e0) at in_pcbremlists+0x82 in_pcbdetach(e9fb11e0,6,e9fb12a0,c0225f0c,e9fb12a0) at in_pcbdetach+0x35 tcp_close(e9fb12a0,e519ccf8,c01c4246,e9fb12a0,c386c2c0) at tcp_close+0x236 tcp_timer_2msl(e9fb12a0) at tcp_timer_2msl+0x52 softclock(0) at softclock+0x136 ithread_loop(c386d180,e519cd48,c386d180,c01aeef0,0) at ithread_loop+0x12e fork_exit(c01aeef0,c386d180,e519cd48) at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm_zeropage priority problems.
On Fri, 21 Dec 2001, Luigi Rizzo wrote: On Sat, Dec 22, 2001 at 12:46:40AM +1100, Bruce Evans wrote: I think pri_native is just an implementation detail which shouldn't be used or visible to threads. It used used by the priority propagation mechanism to hold the original pri_level. Threads should just use their original priority (or a different one if they want to temporarily change thier priority). Even pri_level probably shouldn't be used or visible to threads. the original priority should be somewhere and accessible, either directly or through some function. Otherwise how do we know what to pass to tsleep() ? It's whatever the thread set itself. There is no good way of setting this either (vm_pagezero() and poll_idle() hack it into td-td_ksegrp-kg_pri). Userland would use rtprio(2) instead. Unfortunately, this gives priorities in different units than the ones for tsleep(). In any case I wonder if this is a bug new in -current; -stable uses three separate data structures for realtime, user and idle tasks so even specifying the wrong priority in tsleep should not cause crossing classes there. -current has only one array, hence the chance of doing the wrong thing. The 3 classes are a design bug in -stable. Crossing classes is sometimes right and 3 classes mainly make it harder and force triplication of code. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic on 12/20/01 current
Hi, I have just managed to repetedly panic -CURRENT... How you ask? I'll tell you :-D The short story is Run a linux version of XFree86, here's the long story: first, I got the linux version of XFree86, along with all it's driver modules (compliled under linux of course). Then in /usr/compat/linux/dev, I created tty entries using mknod (mknod tty0 c 12 0, etc.. for each tty up to 5) then I did this: /usr/compat/linux/usr/X11R6/bin/XFree86 the XFree86 said error switching terminal's or something similar, and immediately after that, FreeBSD panics with the following: Fatal trap 12 while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8: 0xc0204f57 stack pointer = 0x10:0xf94dfaf8 frame pointer = 0x10:0xf94dfb14 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 = 262 (XFree86) kernel: type 12 trap, code = 0 I didn't write all the argument adresses down because my computer was stuck beeping at me... just one constant beeep until I restart the computer so I wanted to reboot it as fast as possible, if these are needed, I can go back and get them. They all appeared valid anyway (none of them were NULL) db trace scioctl + 0xa33 spec_ioctl + 0x26 ufs_vnoperatespec + 0x15 vn_ioctl + 0x10f ioctl + 0x288 linux_ioctl_console + 0x209 linux_ioctl + 0x54 That's basically the end, there was more but I think this is all that's relevant... Anyway, If anyone reproduces this or fixes this or even reads this and has more questions, please let me know. Thanks. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FYI: Panic at in_pcbremlists()
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
I got a panic with today's current. I don't know I can reproduce this
panic or not...
This probably is in:
1015if (LIST_FIRST(phd-phd_pcblist) == NULL) {
1016LIST_REMOVE(phd, phd_hash);
1017free(phd, M_PCB);
but without the structure pointers, there isn't much to debug.
Is there a crash dump available?
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FYI: Panic at in_pcbremlists()
At Fri, 21 Dec 2001 10:06:38 -0600 (CST),
Jonathan Lemon wrote:
I got a panic with today's current. I don't know I can reproduce this
panic or not...
This probably is in:
1015if (LIST_FIRST(phd-phd_pcblist) == NULL) {
1016LIST_REMOVE(phd, phd_hash);
1017free(phd, M_PCB);
but without the structure pointers, there isn't much to debug.
Is there a crash dump available?
Yes, I have. But this machine have 2GB memory and dump is 2GB, too.
So it is difficult to send dump. If you can instruct how I should do,
I'll follow you.
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: vm_zeropage priority problems.
On 21-Dec-01 Bruce Evans wrote: On Fri, 21 Dec 2001, Luigi Rizzo wrote: On Sat, Dec 22, 2001 at 12:46:40AM +1100, Bruce Evans wrote: I think pri_native is just an implementation detail which shouldn't be used or visible to threads. It used used by the priority propagation mechanism to hold the original pri_level. Threads should just use their original priority (or a different one if they want to temporarily change thier priority). Even pri_level probably shouldn't be used or visible to threads. the original priority should be somewhere and accessible, either directly or through some function. Otherwise how do we know what to pass to tsleep() ? It's whatever the thread set itself. There is no good way of setting this either (vm_pagezero() and poll_idle() hack it into td-td_ksegrp-kg_pri). Userland would use rtprio(2) instead. Unfortunately, this gives priorities in different units than the ones for tsleep(). pri_level is the current priority of the thread. The actual priority level is going to move back into the thread and out of the KSE group so that tsleep and priority propagation work properly, but pri_native, pri_user, and nice will stay in the KSE group. The normal priorities for tsleep() are just a subset of the priorities available to a thread. Thus, they are using the same unit, but perhaps a wider range. In any case I wonder if this is a bug new in -current; -stable uses three separate data structures for realtime, user and idle tasks so even specifying the wrong priority in tsleep should not cause crossing classes there. -current has only one array, hence the chance of doing the wrong thing. The 3 classes are a design bug in -stable. Crossing classes is sometimes right and 3 classes mainly make it harder and force triplication of code. Agreed. In current we basically have one large priority array. At the top (low priorities) are realtime kernel priorities including interrupt thread priorities. Below those are other top-half kernel priorities including the normal sleep priorities. Below that are real-time user priorities, followed by time sharing user priorities, and finally idle user priorities. Possibly real-time user priorities should move up into the real-time kernel range, and it should be noted that the idle priorites are for idle kernel threads, not just user threads (so sys/priority.h may need a bit of updating). This is a simpler model esp. when you consider a thread of one priority class blocking on a lock held by a thread of a lower priority class as you only have to update pri_level for priority propagation rather than comparing classes and having to manage that extra gunk. -- 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
/usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp
Hi, Some binaries, especially from the ports tree on my system just failed to start, bringing the message: /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp Could somebody give me a hint what I'm missing here. Since I couldn't start cvsup, my system ist somewhat out of sync. (freebsd-current). regards, Jean Louis Ntakpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol__stdoutp
On Fri, 21 Dec 2001, Jean Louis Ntakpe wrote: Some binaries, especially from the ports tree on my system just failed to start, bringing the message: /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp Could somebody give me a hint what I'm missing here. /usr/src/UPDATING is your friend. Hint: echo COMPAT4X=yes /etc/make.conf; make world Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp
On Fri, Dec 21, 2001 at 11:53:49AM -0800, Doug White wrote: On Fri, 21 Dec 2001, Jean Louis Ntakpe wrote: Some binaries, especially from the ports tree on my system just failed to start, bringing the message: /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp Could somebody give me a hint what I'm missing here. /usr/src/UPDATING is your friend. Hint: echo COMPAT4X=yes /etc/make.conf; make world Actually, there's not enough context in src/UPDATING to find these entries. Warner, could you please add __stdoutp to the 20010919 entry, and a hint to put COMPAT4X=true to /etc/make.conf to the 20010924 entry? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
KSE changes available
The latest round of KSE changes are available from
http://www.freebsd.org/~julian/thediff
These changes represent a work in progress.
Basically the state is:
GENERIC compiles
(I don't know yet if it runs but I doubt it.)
The following changes have been made:
The 'thread' structure is no longer a built-in part of the proc structure.
There is an infrastructure to independently crfeate and reap threads.
The infrastructure is used to create and destroy the 'usual' single thread
associated with each process. It should eventually be used to create more
threads per process..
The 'state' variable associated with the process has been raped and
now each thread, and process and KSE has it's own state.
This last part is the bit that is broken because a LOT of the kernel
doesn't expect the state of a thread to be spread across several
structures.
For example:
switch (p-p_stat) {
case SRUN:
...
case SSTOP:
..
has to be completely rewritten because
SRUN is a per-thread property
and is accessed as:
FOREACH_THREAD_IN_PROC(p, td) {
switch(td-td_state) {
case TDS_RUNNING:
case TDS_RUNQ:
case TDS_SLP:
...
}
...
}
wheras STOP is still a per-process state.
obviously any code that tries to assume the same scope for these tow
states will break violently in the new code.
I have replaced some of the logic where there seems to be a simple answer,
but there are plenty of places where the answer is not clear.
Such places include signal delivery,
selection of process (thread?) to deliver a signal to,
collection of scheduling statistics,
handling FORK run by one of several threads,
handling EXIT run by one of several threads,
handling when the user types ^Z and suspends the process.
If anyone is feeling adventurous they can stat with the code that is there
and start fixing things :-)
send me patches but let me know ahead of time what you will be doing
so we don't duplicate, and so I can send you notes on where I'm going in
that part..
I'll be working on the scheduler for the next few days I think.
Note: if ((p-p_flag P_KSES) == 0) a process should act exactly as it
does now.. :-)
REGARDS JULIAN
(bloody capslock key)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: spam
I can only hope that our illustrious congress has grown as tired of spam as I have and will fix the law to simply ban it. -Matt That would help, (most SPAM I receive even in Germany is from USA), but spammers would move offshore from USA still target us, just as most German language spamming is now from countries outside Germany, so presumably German language spammers pay foreign intermediaries or subsidiaries to spam. Hostile counter attacks could supplement laws filtering ... - I got a panic stricken international phone call from a UK spammer near where I used to live, after I mailed threatened to report him to local police /or launch net attacks on his facilities. - Anyone know of PD sourced tools indexes that automate co-ordination of hostile counter attacks on identified spammers ? PS Maybe if we were to regularly automatically scramble all email addresses in our web searchable mail archives ? just inserting ._ErAsE_ThIs_. in every email address would protect us from easy harvesting by simple spammer robots. Julian J.StaceyMunich Unix (FreeBSD, Linux etc) Independent Consultant Reduce costs to secure jobs: Use free software: http://bim.bsn.com/~jhs/free/ Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
subscribe -- We got a thousand points of light, For the homeless man We got a kinder gentler machine gun hand - Neil Young To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Forward: if_fxp.c typo?
Hmm, -current has same problem. It should fix in -current... ---BeginMessage--- Hi all, fxp_stop() of the latest fxp driver do SOFTWARE_RESET when called. Shouldn't this be SELECTIVE_RESET? As I'm not familiar with fxp, would someone check and commit it to the repositry? The current code clears all the hardware mc filters already set, as a result, the box can't receive any multicast packets (this is a serious problem especially when using ipv6). --- Keiichi SHIMA IIJ Research Laboratory [EMAIL PROTECTED] KAME Project [EMAIL PROTECTED] --- orig/if_fxp.c Thu Nov 8 18:30:10 2001 +++ if_fxp.cThu Nov 22 17:22:38 2001 @@ -1429,7 +1429,7 @@ * Issue software reset, which also unloads the microcode. */ sc-flags = ~FXP_FLAG_UCODE; - CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SOFTWARE_RESET); + CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET); DELAY(50); /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message ---End Message--- ---BeginMessage--- I noticed this fixes my problem, but I don't know this patch is logically correct or not. I think we should commit this before 4.5-RELEASE if this is correct way. Can someone comment this? At Thu, 22 Nov 2001 08:47:09 + (UTC), Keiichi SHIMA / $BEg7D0l(B wrote: fxp_stop() of the latest fxp driver do SOFTWARE_RESET when called. Shouldn't this be SELECTIVE_RESET? As I'm not familiar with fxp, would someone check and commit it to the repositry? The current code clears all the hardware mc filters already set, as a result, the box can't receive any multicast packets (this is a serious problem especially when using ipv6). ... --- orig/if_fxp.c Thu Nov 8 18:30:10 2001 +++ if_fxp.c Thu Nov 22 17:22:38 2001 @@ -1429,7 +1429,7 @@ * Issue software reset, which also unloads the microcode. */ sc-flags = ~FXP_FLAG_UCODE; - CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SOFTWARE_RESET); + CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET); DELAY(50); /* -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message ---End Message---
Yet another panic at pgfind()
This is yesterday's -current. Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x114 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b6c40 stack pointer = 0x10:0xf1947cd8 frame pointer = 0x10:0xf1947cd8 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 = 76144 (cron) kernel: type 12 trap, code=0 Stopped at pgfind+0x1c:cmpl%ecx,0x14(%eax) db Context switches not allowed in the debugger. db trace pgfind(12970) at pgfind+0x1c setsid(f10ab604,f1947d20,8058000,8051060,805514a) at setsid+0x3f syscall(2f,2f,2f,805514a,8051060) at syscall+0x257 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (147, FreeBSD ELF, setsid), eip = 0x280b5a43, esp =0xbfbff700, ebp = 0xbfbffcac --- -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
MULTI_DRIVER_MODULE
Does anybody have an example of how to call MULTI_DRIVER_MODULE? It looks broken to me, but I could of course be wrong... Thanks. -- Chad David[EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MULTI_DRIVER_MODULE
Chad David wrote: Does anybody have an example of how to call MULTI_DRIVER_MODULE? It looks broken to me, but I could of course be wrong... I would not recommend using it. Just use several DRIVER_MODULE declarations as required. In fact, I think I might remove it since nothing uses it yet. 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MULTI_DRIVER_MODULE
On Fri, Dec 21, 2001 at 09:55:37PM -0800, Peter Wemm wrote: Chad David wrote: Does anybody have an example of how to call MULTI_DRIVER_MODULE? It looks broken to me, but I could of course be wrong... I would not recommend using it. Just use several DRIVER_MODULE declarations as required. In fact, I think I might remove it since nothing uses it yet. Actually, my use of it is to verify the correctness of the man page, which I have been unable to do. If you are going to remove it then I will just remove the reference to it all together. I'll watch for the commit :). Thanks. -- Chad David[EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vm_zeropage priority problems.
On Fri, 21 Dec 2001, Luigi Rizzo wrote:
Don't know how interesting this can be, but i am writing
(no plans to commit it, unless people find it interesting)
some code to implement a weight-based instead of priority-based
scheduler. The code is basically the WF2Q+ scheme which is
already part of dummynet, adapted to processes.
It is quite compact, and i think i can make it reasonably
compatible with the old scheme, i.e. a sysctl var can be
used to switch between one and the other with reasonably
little overhead.
This would help removing the ugly property that priority-based
have, which is that one process can starve the rest of the system.
Only broken priority-based schedulers have that property. One of
my incomplete fixes uses weights:
Index: kern_synch.c
===
RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.167
diff -u -2 -r1.167 kern_synch.c
--- kern_synch.c18 Dec 2001 00:27:17 - 1.167
+++ kern_synch.c19 Dec 2001 16:01:26 -
@@ -936,18 +1058,18 @@
struct thread *td;
{
- struct kse *ke = td-td_kse;
- struct ksegrp *kg = td-td_ksegrp;
+ struct ksegrp *kg;
- if (td) {
- ke-ke_cpticks++;
- kg-kg_estcpu = ESTCPULIM(kg-kg_estcpu + 1);
- if ((kg-kg_estcpu % INVERSE_ESTCPU_WEIGHT) == 0) {
- resetpriority(td-td_ksegrp);
- if (kg-kg_pri.pri_level = PUSER)
- kg-kg_pri.pri_level = kg-kg_pri.pri_user;
- }
- } else {
+ if (td == NULL)
panic(schedclock);
- }
+ td-td_kse-ke_cpticks++;
+ kg = td-td_ksegrp;
+#ifdef NEW_SCHED
+ kg-kg_estcpu += niceweights[kg-kg_nice - PRIO_MIN];
+#else
+ kg-kg_estcpu++;
+#endif
+ resetpriority(kg);
+ if (kg-kg_pri.pri_level = PUSER)
+ kg-kg_pri.pri_level = kg-kg_pri.pri_user;
}
Most of the changes here are to fix style bugs. In the NEW_SCHED case,
the relative weights for each priority are determined by the niceweights[]
table. kg-kg_estcpu is limited only by INT_MAX and priorities are
assigned according to relative values of kg-kg_estcpu (code for this is
not shown). The NEW_SCHED case has not been tried since before SMPng
broke scheduling some more by compressing the priority ranges.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
MEXTFREE
MEXTFREE results in a call to _mext_free() which is only defined within subr_mbuf.c, and is not static. Should the prototype be moved into sys/mbuf.h, or should MEXTFREE be moved into subr_mbuf.c, or is it ok like this? Thanks. -- Chad David[EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
