Re: Latest currents 'hang' on biord? [ Appears only on my system? :( ]
>> Any current's more recent than about a month ago on my main system seem to >> 'hang' on biord whenever they access the IDE drives... > My test / compile box : Pentium III 450 MHZ with 8 gig ide disk drive > does not hang at all . FreeBSD-current is about a week old. Same here; K6-233 with 2 4 gig IDE drives, no problems at all. I'm even using vinum. Since you're running current, you might try Soren's new ATA driver, its documented in LINT; I've been using it for several months with no problems. fwiw I booted the install disk today, it has the old wd driver, and that accessed my drives fine as well. -- we are but packets in the internet of life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a couple of warnings
> asus p2b-ds, dual P2/350s, 128mb > current as of 99.08.13 evening > > dmesg has a few things which worry me. but the hauppauge/brootree works > fine with mbone tools and fxtv. > > WARNING: "bktr" is usurping "bktr"'s cdevsw[]<<<* > WARNING: "iic" is usurping "iic"'s cdevsw[] <<<* As is understand it, these are just advisory and can be safely ignored; I get the same messages. -- we are but packets in the internet of life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-RC Broken driver?: matcd
> On Mon, Feb 14, 2000 at 02:39:09PM -0700, Doug Russell wrote: > > > Does anyone have a Panasonic 526/563 CD-ROM drive working under 4.0-C? I > > have not had one working for may weeks, however, I wasn't sure if it was a > > hardware problem here, or something. 3.4 still finds them, so I beleive > > it is something with the move to newbus or driver compatibility shims. > > I'll ask the silly question first, did you add it back into your kernel? > > I removed it from GENERIC "many weeks" ago. I think this driver is a casualty of newbus; mine stopped being probed last year when the conversion was made. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sshd in current....no config files in /etc/ssh
> ThanksI used that "i" option and it worked...well, almost. I have the files
> I need in /etc/ssh but when I start sshd I get this now.
>
> error: Could not load host key: /etc/ssh/ssh_host_key: No such file or
> directory
If you want to track current you must use mergemaster.
This is probably because you haven't updated rc.network...
case ${sshd_enable} in
[Yy][Ee][Ss])
if [ ! -f /etc/ssh/ssh_host_key ]; then
echo ' creating ssh host key';
/usr/bin/ssh-keygen -N "" -f /etc/ssh/ssh_host_key
fi
;;
esac
My host key was generated automatically when I rebooted and I was
quite impressed.
Just type 'mergemaster' as root. It's interactive and doesn't overwrite
anything automatically.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
java too? (was Re: Perl still broken in 4.0-CURRENT)
> I found the problem and the fix for the perl breakage that was > caused by my recent changes to the dynamic linker. I'm doing a make > world now, just to make sure I haven't broken something new. I'll > commit the fix later this evening, unless the make world reveals new > problems. (I don't think it will.) > I think that java is still broken by this. It seg faults immediately with the current rtld, even when run with no arguments: > java Segmentation fault (core dumped) > but works fine when I revert to august 25th rtld. -- we are but packets in the internet of life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newpcm and sb driver
Regarding all the trouble people have been having getting their cards detected with newpcm, I had to make a change to my kernel config for it to find my soundblaster 16, non-pnp. this does not detect my card: device pcm0 at isa? port ? irq 5 drq 1 flags 0x15 this does: device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x15 pcm0: at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 Hope this helps... -- we are but packets in the internet of life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mii_load in loader.conf
Can we have an entry for mii.ko in /boot/defaults/loader.conf? ## ### Networking drivers # ## mii_load="NO" ax_load="NO"# ASIX Electronics AX88140A fxp_load="NO" # Intel EtherExpress PRO/100B (82557, 82558) ... -- we are but packets in the internet of life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sb16 not found with newpcm
> pcm0: at port 0x220-0x22f irq 5 drq 1 flags 0x15 on > isa0 > > If dmesg from sb0 would help I could get it.. Anything else I could help > with in making "device pcm0" work without params? or is that pnp only? Yes, that is for pnp-only. -- we are but packets in the internet of life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SOLVED (partly): Re: Can't start vinum with new kernels
> I found out what was causing "Can't get device list: Cannot allocate > memory".. libdevstat mismatch. > > Now I'm getting a panic, but hopefully I'll have a decent backtrace > out of it soon. I ran into to that too and thought I was screwed, but vinum read worked. I built the new kernel rebuilt modules rebuilt /sbin/vinum rebooted...Can't get device list: Cannot allocate memory...single user mode vinum read /dev/wd0 /dev/wd1 exit then promptly rebuilt the world, and everything was fine. the panic could be from old /sbin/vinum with new kernel and/or vinum.ko, I'd suggest rebuilding that too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
> On Tue, 25 Apr 2000, Boris Popov wrote: > > > simple_lock* functions has breakage too. They defined as macros > > for non-SMP case and as functions for SMP. > > This currently apparently affects the following modules: > > ccd > cd9660 > msdosfs > nfs > ntfs > nwfs > vinum > > All of these functions reference simple_lock() if it is not defined away. > > Bruce Has anyone thought about using kobj(9) for this? For example, it should be possible to make simple_lock and lockmgr locks safe for use from modules by introducing a lock_if.h, which has abstract version of all the lock routines. A class would be compiled with null implementations for UP, or the 'lock'ed implementations for SMP. The old functions would call through an instance of that class, automagically finding the right method. Eventually this could be a runtime abstraction, with both up and smp classes compiled into the kernel, and objects initialized with the right method table at boot time. I have diffs in the works if anyone is interested. Jake. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
...snip... > > Its nice to see someone actually using kobj so soon. There is a possible > performance problem though - kobj method calls are roughly 20% slower than > direct function calls. Having said that, this isn't that slow - I timed a > method call to a two argument function at ~40ns on a 300MHz PII. > > I could improve this for some applications (including this one) by > providing a mechanism for an application to cache the function pointer > returned by the method lookup. Yes, this sounds interesting. I can see that there are provisions for a cache in the code, and I can see from the sysctls that hits and misses are happening, but I can't see where the function pointers are entered into the cache. Is this enabled by default? It also might be possible to have default implementations that do "less than nothing", a special value could be entered in the cache that indicates don't call through the function pointer at all. I don't know how an inline cache lookup would compare to an empty function call, but it might be a win when the locks are supposed to do nothing. Anyway, I've made a patch that uses Boris's suggestion of providing functions with empty bodies. I worry about optimizing for the static UP kernel because of introducing more SMP and KLD_MODULE ifdefs, possibly it should just be a function call in all cases. http://io.yi.org/lock.diff I will send-pr it if no one has any comments. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
> jake2000/05/23 13:41:02 PDT > Log: > Change the way that the queue(3) structures are declared; don't assume that > the type argument to *_HEAD and *_ENTRY is a struct. > > Suggested by: phk > Reviewed by:phk > Approved by:mdodd > HEADS UP Possible action required! Some drivers use headers from the installed system during the kernel build, and a make world, or at least make includes, is necessary before a new kernel can be built. LINT is affected by this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
>
> Is anyone else having trouble compiling the libpam things, because of
> this? I couldn't compile a kernel because of the the assembler changes,
> so I went to do a buildworld, and now I can't get thru a buildworld. I
> tried the suggestion above (do a make includes) but that didn't seem to do
> the trick. Here's about the first 5 of the 30 (or so) errors I see:
>
I've just built a fresh world here; if you use the cvs-crypto from
internat, it may be broken. I submitted a patch to Mark Murray which
should fix it, here it is again just in case:
Index: crypto/openssh/pam_ssh/pam_ssh.c
===
RCS file: /home/ncvs/src/crypto/openssh/pam_ssh/pam_ssh.c,v
retrieving revision 1.4
diff -u -r1.4 pam_ssh.c
--- crypto/openssh/pam_ssh/pam_ssh.c2000/03/29 08:24:37 1.4
+++ crypto/openssh/pam_ssh/pam_ssh.c2000/05/22 18:14:51
@@ -86,11 +86,11 @@
* environ at an array of one element equal to NULL).
*/
-SLIST_HEAD(env_head, env_entry);
+SLIST_HEAD(env_head, struct env_entry);
struct env_entry {
char*ee_env;
- SLIST_ENTRY(env_entry) ee_entries;
+ SLIST_ENTRY(struct env_entry)ee_entries;
};
typedef struct env {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mp
> > Garrett Wollman writes: > > > > I've just built a fresh world here; if you use the cvs-crypto from > > > > internat, it may be broken. I submitted a patch to Mark Murray which > > > > should fix it, here it is again just in case: > > > > > > I still think (and am going on record) that this is a REALLY, REALLY > > > BAD idea. > > > > So.. what's the decision? Is this going to be backed out or not? > > I'd like to know before doing the next update & make world.. > > We've had our 24 hours, and the responses I've seen so far have been > universally negative. I'm going to ask Jake to back this out. Ok, I will back this out tomorrow at 6:00 pm PDT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
> In message <[EMAIL PROTECTED]>, Mike Smith writes: > >> >I objected to a recent commit hiding the fact that this is > >> >"(elm)->field.sle_next". Anyway, curelm must be a pointer to a struct. > >> >Not just any struct; the struct must contain a "field" declared using > >> >SLIST_ENTRY(). > >> > >> It could be an union or class as well... > > > >It would not be very useful if it were a union; the class issue is valid > >(although you could trivially use a struct contained within a class and a > >parent reference) but definitely not a good enough argument to support > >the massive breakage this otherwise entails. > > I have yet to see any signs of "massive breakage". Please just let it rest. I don't think Mike's comments are out of line; this was massive breakage regardless of wether world built or not. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build error due to dependency on /usr/include?
> Hi all,
>
> I got following kernel build error.
> When I run 'make includes', the error has gone away.
>
> Why does kernel build process depend on installed system files,
> such as /usr/include?
It shouldn't.
This seems to be primarily aic7xxx, although judging from the output
of 'find /usr/include -amin 20 -print' after building LINT, there
are more things that reach into /usr/include.
This fixes it for including things from /usr/include/sys at least:
cvs diff: Diffing .
Index: Makefile
===
RCS file: /home/ncvs/src/sys/dev/aic7xxx/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile1999/08/28 00:41:22 1.6
+++ Makefile2000/05/27 09:21:05
@@ -19,7 +19,7 @@
DEPENDFILE=
.endif
-CFLAGS+= -I/usr/include -I.
+CFLAGS+= -I${MAKESRCPATH}/../.. -I.
NOMAN= noman
.ifdef DEBUG
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vm_zeropage priority problems.
Apparently, On Sat, Dec 22, 2001 at 06:48:26PM +1100,
Bruce Evans said words to the effect of;
> 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.c 18 Dec 2001 00:27:17 - 1.167
> +++ kern_synch.c 19 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;
> }
I'm curious why you removed the ESTCPULIM and INVERSE_ESTCPU_WEIGHT
calculations even in the OLD_SCHED case. Do these turn out to have
no effect in general?
>
> 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.
It is relatively easy to uncompress the priority ranges if that is
desirable. What range is best?
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
Apparently, On Wed, Feb 06, 2002 at 06:17:38PM -0500, Andrew Gallatin said words to the effect of; > > Andrew Gallatin writes: > > > > Since thread0 is no longer a pointer, this looks suspicious in locore.s: > > > > /* > > * Switch to proc0's PCB. > > */ > > ldq t0,thread0 /* get phys addr of pcb */ > > ldq a0,TD_MD_PCBPADDR(t0) > > SWITCH_CONTEXT > > Yeah.. that's it. I hacked around it by taking thread0's address in > machdep.c, shoving it into a global and using that global in locore.s > The resulting kernel booted. > > What's the "right" way to do this? I think you want lda, its used to load an address constant in support.s: lda t0, fusufault /* trap faults */ Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
Apparently, On Wed, Feb 06, 2002 at 12:01:44PM -0800, Julian Elischer said words to the effect of; > > for the set of patches at: > http://www.freebsd.org/~julian/adiff > > these patches SHOULD NOT EFFECT your system except to do some > slight re-aranging of stuff in the kernel. > > THe aim is to get this committed to 'clarify' the upcoming > KSE commit in http://www.freebsd.org/~julian/thediff > > which includes adiff as a subset. > > when adiff is committed thediff will become a lot easier for people to > read and check. I'd like to get adiff in relatively soon. This seems to work fine on sparc64. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Non 386 testers REALLY NEEDED
Apparently, On Wed, Feb 06, 2002 at 06:17:38PM -0500, Andrew Gallatin said words to the effect of; > > Andrew Gallatin writes: > > > > Since thread0 is no longer a pointer, this looks suspicious in locore.s: > > > > /* > > * Switch to proc0's PCB. > > */ > > ldq t0,thread0 /* get phys addr of pcb */ > > ldq a0,TD_MD_PCBPADDR(t0) > > SWITCH_CONTEXT > > Yeah.. that's it. I hacked around it by taking thread0's address in > machdep.c, shoving it into a global and using that global in locore.s > The resulting kernel booted. > > What's the "right" way to do this? I think you want lda, its used to load an address constant in support.s: lda t0, fusufault /* trap faults */ Jake 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: Non 386 testers REALLY NEEDED
Apparently, On Wed, Feb 06, 2002 at 12:01:44PM -0800, Julian Elischer said words to the effect of; > > for the set of patches at: > http://www.freebsd.org/~julian/adiff > > these patches SHOULD NOT EFFECT your system except to do some > slight re-aranging of stuff in the kernel. > > THe aim is to get this committed to 'clarify' the upcoming > KSE commit in http://www.freebsd.org/~julian/thediff > > which includes adiff as a subset. > > when adiff is committed thediff will become a lot easier for people to > read and check. I'd like to get adiff in relatively soon. This seems to work fine on sparc64. Jake 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: Patch to improve mutex collision performance
Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; > > :I request that you give say a 3 day review period for this. > :I know JHB still has limited email access (no DSL yet). > :This may be something he should review. I second this request. > > Sigh. Are you intending to ask me to have JHB review every single change > I make to -current? For changes to the mutex code, yes. > Because if you are the answer is: "Are you out of > your mind?". Sigh. > > I'm fairly sure JHB does not have a patch to address this but, please, > be my guest and check P4. Actually he does. Maybe you should have checked p4 first yourself. What John's patch does is spin while the lock owner is running on another cpu. Spinning while there are no other processes on the run queues as well makes sense but you'll also be doing a lot of acquires and releases of sched_lock. The only thing that jumped out at me looking at the patch is that critnest cannot be 0 here because the sched_lock is held; holding a spin lock implies being in a critical section. I need to think about this more and would like you to wait until John has a chance to look at it as well. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
Apparently, On Mon, Feb 18, 2002 at 12:43:18PM -0800, Matthew Dillon said words to the effect of; > :What John's patch does is spin while the lock owner is running on another cpu. > :Spinning while there are no other processes on the run queues as well makes sense > :but you'll also be doing a lot of acquires and releases of sched_lock. > : > :The only thing that jumped out at me looking at the patch is that critnest cannot > :be 0 here because the sched_lock is held; holding a spin lock implies being in a > :critical section. I need to think about this more and would like you to wait until > :John has a chance to look at it as well. > : > :Jake > > Sure thing. Thanks. > Ah, critnest... you are right. I should be checking for > critnest > 1. I think you should just leave it alone, don't check critnest at all. critnest != 1 is illegal because you can't acquire a sleep lock while in an enclosing critical section. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: changes to rc.diskless*
Apparently, On Thu, Feb 21, 2002 at 08:00:51PM -0800,
David O'Brien said words to the effect of;
> The existing very bazaar and local policy in rc.diskless1 is Just Wrong;
> and looks like no other Unix diskless configuration I've ever seen. I
> plan on committing this patch to negate this.
Yay!
>
> The use of an MFS /var should also be settable. Otherwise installing
> ports(packages) is just a total PITA.
>
>
> Index: rc.diskless2
> ===
> RCS file: /home/ncvs/src/etc/rc.diskless2,v
> retrieving revision 1.15
> diff -u -r1.15 rc.diskless2
> --- rc.diskless2 26 Dec 2001 17:18:39 - 1.15
> +++ rc.diskless2 22 Feb 2002 03:56:18 -
> @@ -56,7 +56,7 @@
> fi
>
> echo "+++ mount_md of /var"
> -mount_md ${varsize:=65536} /var 1
> +mount_md ${varsize:=32m} /var 1
One problem with making the mds so big is that it uses type malloc
which afaict uses malloc(9) to get the backing store. This was the
point of the M_SHORTWAIT patch posted a while ago, if you ask for too
much with M_WAITOK you might go to sleep and never be woken up. It
might be better to use type vnode with file or swap based backing
store. sparc64 machines tend to have more ram than older pcs that
this might also be used on :)
my $0.02.
Jake
>
> echo "+++ populate /var using /etc/mtree/BSD.var.dist"
> /usr/sbin/mtree -deU -f /etc/mtree/BSD.var.dist -p /var
> @@ -83,7 +83,7 @@
> # so if /var/tmp == /tmp, then you don't get a vi.recover.
> #
> if [ ! -h /tmp ]; then
> - mount_md ${tmpsize:=20480} /tmp 2
> + mount_md ${tmpsize:=64m} /tmp 2
> chmod 01777 /tmp
> fi
>
>
> 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: Panic in today current
> Julian Elischer wrote: > > > > Pete Carah wrote: > > > > > > I got a panic today on a fresh kernel... > > > > > > Compiled with netgraph but non of the netgraph modules. > > > > > > Immediately after the memory probe, a message about sequencers 0-15, > > > then: > > > Panic: spinlock ng_worklist not in order list > > The problem is probably that you put them inside of an ifdef SMP. The ifdef is there for locks that only exist for SMP. Move them after the #endif, like: /* * leaf locks */ #ifdef SMP #ifdef __i386__ "ap boot", "imen", #endif "smp rendezvous", #endif "ng_node", "ng_worklist", NULL To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler panic
> On Sun, Feb 25, 2001 at 10:29:42PM -0800, Kris Kennaway wrote: > > This is on a UP system. > > Had another one of these, under the same conditions. Both times I was > running more(1) on a stdin stream which was generated by a "find | > grep | more" operation, and I suspended the process with ^Z, > triggering the panic. Perhaps this will help in tracking down the > root cause. I'm pretty sure I know what this is; I'll work up a patch tonight. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern init_main.c kern_fork.c kern_mutex.c
> jake2001/02/26 15:27:35 PST > > Modified files: > sys/kern init_main.c kern_fork.c kern_mutex.c > Log: > Initialize native priority to PRI_MAX. It was usually 0 which made a > process's priority go through the roof when it released a (contested) > mutex. Only set the native priority in mtx_lock if hasn't already > been set. > > Reviewed by:jhb > > Revision ChangesPath > 1.161 +2 -1 src/sys/kern/init_main.c > 1.102 +2 -1 src/sys/kern/kern_fork.c > 1.53 +3 -12 src/sys/kern/kern_mutex.c > This should fix the problems with syncing the disks at shutdown. What happened was the sync-ors priority would get set to 0, which didn't allow any interrupt threads to run. Usually this didn't matter because the priority gets lowered when returning to user mode. But, of course, shutting down implies never returning to userland. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: d.net client + today's kernel
> Hello, > > a distributed.net client (ports/misc/dnetc) being run on -current with > today's kernel just hangs my box. the system _dramatically_ slows > down and stops to respond on any external events (keyboard, network, > etc). > > d.net client is a daemon, that uses cpu idle (and only idle) time to do some > background mathematical calculations (www.distributed.net). it seems that with > latest kernel snapshots a dnet client takes highest priority instead > of lowest one. > Sorry, this should be fixed. I'm running it now and it seems fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: d.net client + today's kernel
> On Tue, 27 Feb 2001, Jake Burkholder wrote: > > > > a distributed.net client (ports/misc/dnetc) being run on -current with > > > today's kernel just hangs my box. the system _dramatically_ slows > > > down and stops to respond on any external events (keyboard, network, > > > etc). > > Sorry, this should be fixed. I'm running it now and it seems fine. > > what's the date of your kernel? > 2001/02/27 18:53:44 PST Any time after that should be good. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler panic
> > On Sun, Feb 25, 2001 at 10:29:42PM -0800, Kris Kennaway wrote:
> > > This is on a UP system.
> >
> > Had another one of these, under the same conditions. Both times I was
> > running more(1) on a stdin stream which was generated by a "find |
> > grep | more" operation, and I suspended the process with ^Z,
> > triggering the panic. Perhaps this will help in tracking down the
> > root cause.
>
> I'm pretty sure I know what this is; I'll work up a patch tonight.
>
Sorry this is taking so long. Its turned out to be a little more
complex to fix properly than I originally thought. We're going to
have to change the way one of the fields of struct proc (p_pptr)
is locked. The problem is that a process is getting preempted
when its not SRUN, which should be protected by the scheduler
lock so that the preemption can't occur.
This is the best workaround I can think of:
Index: kern/kern_intr.c
===
RCS file: /home/ncvs/src/sys/kern/kern_intr.c,v
retrieving revision 1.47
diff -u -r1.47 kern_intr.c
--- kern/kern_intr.c2001/02/28 02:53:43 1.47
+++ kern/kern_intr.c2001/03/02 02:28:08
@@ -366,7 +366,7 @@
*/
ithread->it_need = 1;
mtx_lock_spin(&sched_lock);
- if (p->p_stat == SWAIT) {
+ if (p->p_stat == SWAIT && curproc->p_stat == SRUN) {
CTR1(KTR_INTR, __func__ ": setrunqueue %d", p->p_pid);
p->p_stat = SRUN;
setrunqueue(p);
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler panic
replying to myself again
>
> This is the best workaround I can think of:
>
> Index: kern/kern_intr.c
> ===
> RCS file: /home/ncvs/src/sys/kern/kern_intr.c,v
> retrieving revision 1.47
> diff -u -r1.47 kern_intr.c
> --- kern/kern_intr.c2001/02/28 02:53:43 1.47
> +++ kern/kern_intr.c2001/03/02 02:28:08
> @@ -366,7 +366,7 @@
> */
> ithread->it_need = 1;
> mtx_lock_spin(&sched_lock);
> - if (p->p_stat == SWAIT) {
> + if (p->p_stat == SWAIT && curproc->p_stat == SRUN) {
> CTR1(KTR_INTR, __func__ ": setrunqueue %d", p->p_pid);
> p->p_stat = SRUN;
> setrunqueue(p);
Heh. Sorry this is wrong, the test for SRUN should be in the
same if statement as the do_switch, one further in. This
will completetly miss interrupts if the race is ever hit...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: random as module needs work
>
> I built a kernel without the random device and tried to use the
> module. I loaded it from the bootloader and the machine panic'ed on boot:
>
> Mounting root from ufs:/dev/da0a
> da0 at sym0 bus 0 target 0 lun 0
> da0: Fixed Direct Access SCSI-2 device
> da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled
> da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
> Entropy harvesti
> fatal kernel trap:
>
> trap entry = 0x2 (memory management fault)
> a0 = 0xe8c77a27c5265710
> a1 = 0x1
> a2 = 0x0
> pc = 0xfc42f824
> ra = 0xfc42f830
> curproc= 0xfe00058c24e0
> pid = 34, comm = sysctl
>
> Stopped at name2oid+0x104: ldq a1,0x28(s1) <0xe8c77a27c5265710>
>
> name2oid() at name2oid+0x104
> sysctl_sysctl_name2oid() at sysctl_sysctl_name2oid+0xd0
> sysctl_root() at sysctl_root+0x16c
> userland_sysctl() at userland_sysctl+0x1c0
> __sysctl() at __sysctl+0xa4
> syscall() at syscall+0x638
> XentSys1() at XentSys1+0x10
> db> reboot
Don't know what's happening here.
>
> Gdb says:
>
> (gdb) l* 0xfc42f824
> 0xfc42f824 is in name2oid (../../kern/kern_sysctl.c:621).
> 616 *p = '\0';
> 617
> 618 oidp = SLIST_FIRST(lsp);
> 619
> 620 while (oidp && *len < CTL_MAXNAME) {
> 621 if (strcmp(name, oidp->oid_name)) {
> 622 oidp = SLIST_NEXT(oidp, oid_link);
> 623 continue;
> 624 }
> 625 *oid++ = oidp->oid_number;
>
>
> When I boot into single user mode and try to load the module after boot, this
>happens:
> Enter full pathname of shell or RETURN for /bin/sh:
> # kldload random
> panic: cpu_fork: curproc
>
> syncing disks...
> done
> Uptime: 27s
I'm fairly certain this is an invalid assertion:
#ifdef DIAGNOSTIC
if (p1 != curproc)
panic("cpu_fork: curproc");
...
kthread_create forks the new thread on behalf of proc0,
error = fork1(&proc0, ...
but if you loaded the module from single user mode then curproc
is most likely going to initproc and not &proc0. Basically this
doesn't allow an arbitrary process to create a kernel thread.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Interesting backtrace...
> On 19 Mar 2001, Dag-Erling Smorgrav wrote: > > > Bruce Evans <[EMAIL PROTECTED]> writes: > > > K6-2's aren't really i586's and i586_bzero should never be used for > > > them (generic bzero is faster), > > > > Wrong. I fixed machdep.c to compute and print the bandwidth correctly: > > Wrong yourself. The fpu is too slow to use for copying for everything > except original Pentiums. The bandwidth test is just done to avoid hard- > configuring this knowledge. > If this is the case, is there much point in keeping the fpu register bcopy and bzero at all? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: {id,rt}prio broken (at syscall level?)
> Hi, > > -current from yesterday: > ---snip--- > (45) root@ttyp0 # idprio 31 /bin/sleep 10 > idprio: idprio: Invalid argument > > (46) root@ttyp0 # rtprio 31 /bin/sleep 10 > rtprio: rtprio: Invalid argument > ---snip--- > > isdnd is also affected (if you use its rtprio keyword in isdnd.rc). Thanks, this should be fixed now. A break; was forgotten in some recent proc locking changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mutex blocking queues..
> Why does the mutex not link blocked processes though the > sleep queue linked list entry? Why does it use the run queue entry? Because in some cases its necessary for a process to acquire mutexes while its on the sleep queue. If they used the same linkage the queues would get corrupted. > In KSEs the sleep queue and run queue enties go into different > sub structures and ahve different types so this breaks... > do I need to do something sleazy or can I just link them together using the > equivalemt of the p_slpq entry? It seems to me that whatever gets placed on the run queues should also be what goes on the mutex queues. > > -- > ++ __ _ __ > | __--_|\ Julian Elischer | \ U \/ / hard at work in > | / \ [EMAIL PROTECTED] +-->x USA\ a very strange > | ( OZ)\___ ___ | country ! > +- X_.---._/presently in San Francisco \_/ \\ > v > > 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
heads up: sizeof proc changed
As usual, you'll have to recompile all libkvm using programs. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/mutex.h - compilation errors
> > I cvsuped src , built world and tried to compile a new kernel. > Presently compilation fails with error in ASM line 601 in ../../sys/mutex.h. > > Any ideas? > > (that code seems to be used by i4b sppp routines) This should be fixed, or at least worked around for a while. Re-cvsup and try again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/mutex.h - compilation errors
> On Fri, Dec 08, 2000 at 03:37:46AM -0800, Jake Burkholder wrote: > > > > > > I cvsuped src , built world and tried to compile a new kernel. > > > Presently compilation fails with error in ASM line 601 in ../../sys/mutex.h. > > > > > > Any ideas? > > > > > > (that code seems to be used by i4b sppp routines) > > > > This should be fixed, or at least worked around for a while. > > Re-cvsup and try again. > > Easier said than done with a broken isdn link (due to a system running an > old kernel with new system binaries :) oh joy :) > > Could you tell me which files were related to that fix? mutex.h itself doesn't > seem to be upgraded since Dec 1, so it may be some other essential > header files? Yeah, its pretty simple. We're having trouble with gcc generating bad code for inline asm in the mutexes, the fix is to use the un-optimized c versions of the mutex routines for now. This should get things compiling again: === RCS file: /home/ncvs/src/sys/i386/include/mutex.h,v retrieving revision 1.15 retrieving revision 1.16 diff -u -p -r1.15 -r1.16 --- src/sys/i386/include/mutex.h2000/12/07 02:23:16 1.15 +++ src/sys/i386/include/mutex.h2000/12/08 05:03:34 1.16 @@ -26,7 +26,7 @@ * SUCH DAMAGE. * * from BSDI $Id: mutex.h,v 2.7.2.35 2000/04/27 03:10:26 cp Exp $ - * $FreeBSD: src/sys/i386/include/mutex.h,v 1.15 2000/12/07 02:23:16 jhb Exp $ + * $FreeBSD: src/sys/i386/include/mutex.h,v 1.16 2000/12/08 05:03:34 jhb Exp $ */ #ifndef _MACHINE_MUTEX_H_ @@ -69,7 +69,8 @@ extern char STR_SIEN[]; #define_V(x) __STRING(x) -#ifndef I386_CPU +#if 0 +/* #ifndef I386_CPU */ /* * For 486 and newer processors. > > > -- > Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Heads Up Re: cvs commit: src/sys/alpha/include globals.h src/sys/conf files.i386 src/sys/i386/i386 locore.s globals.s src/sys/i386/include asnames.h globals.h src/sys/ia64/include globals.h
> jake2001/01/11 06:46:26 PST > > Modified files: > sys/alpha/includeglobals.h > sys/conf files.i386 > sys/i386/i386locore.s > sys/i386/include asnames.h globals.h > sys/ia64/include globals.h > Removed files: > sys/i386/i386globals.s > Log: > - Remove compatibility macros for accessing per-cpu variables. > __FreeBSD_version 500015 can be used to detect their disappearance. > - Move the symbols for SMP_prvspace and lapic from globals.s to > locore.s. > - Remove globals.s with extreme prejudice. > > Revision ChangesPath > 1.6 +1 -14 src/sys/alpha/include/globals.h > 1.345 +1 -2 src/sys/conf/files.i386 > 1.140 +12 -1 src/sys/i386/i386/locore.s > 1.50 +1 -44 src/sys/i386/include/asnames.h > 1.16 +1 -25 src/sys/i386/include/globals.h > 1.5 +1 -13 src/sys/ia64/include/globals.h > > If you have not rebuilt your modules in the past few days you must do so now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new gensetdefs breaks booting
> Bruce Evans wrote: > > > > The new gensetdefs gives unbootable kernels on i386's. They hang before > > printing anything. > > I verified that the output of gensetdefs.pl is identical to that of > gensetdefs(1). Does the kernel boot if gensetdefs(1) is used? > Its not identical here, gensetdefs.pl uses .quad for the size of the linker set (?), which should be .long for x86. Also, I'm not sure if the calculation for pointer size is correct, all the numbers seemed 3 times too big in setdefs.h. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wierd behaviour [UPDATE]
> Update to my previous mail: > > trying a PRE_SMPNG kernel doesn't change anything, it still displays > nothing. I've also updated my /boot/loader and bootblocks. > > Still no idea? Are you running a stripped down kernel? or generic? There's a problem with kernels that are too large not booting. If you bypass /boot/loader and load the kernel directly it should boot; then take everything you don't need out of the kernel config and build a new kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
> Running a kernel I got with this:
>
> >
> > cvs co -D"2001-01-30" src/sys
> >
>
> /ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
>
> I get:
>
> panic: malloc(M_WAITOK) in interrupt context
> Debugger("panic")
> Stopped at Debugger+0x45: pushl %ebx
> db> trace
> Debugger(c02119a3) at Debugger+0x45
> panic()
> malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
> exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
> kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
> ithd_loop(0,c6623fa8) at ithd_loop+0x56
> fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
> fork_trampoline() at fork_trampoline+0x8
> db> witness_list
> "Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
>
Make sure you have intr_machdep.c version 1.47.
revision 1.47
date: 2001/01/28 17:20:11
> --
> Actually, Microsoft is sort of a mixture between the Borg and the Ferengi.
>
>
> 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 Panic from Yesterday's CVSup
> On Wed, Feb 07, 2001 at 02:20:43PM -0800, John Baldwin wrote:
> >
> > On 07-Feb-01 Andrea Campi wrote:
> > > Running a kernel I got with this:
> > >
> > >>
> > >> cvs co -D"2001-01-30" src/sys
> > >>
> > >
> > > /ithread.c/1.10/Mon Dec 4 21:15:14 2000//D2001.01.29.23.00.00
> > >
> > > I get:
> > >
> > > panic: malloc(M_WAITOK) in interrupt context
> > > Debugger("panic")
> > > Stopped at Debugger+0x45: pushl %ebx
> > > db> trace
> > > Debugger(c02119a3) at Debugger+0x45
> > > panic()
> > > malloc(48,c0238100,0,c65feb80,0) at malloc+0x2a
> > > exit1(c65feb80,0,0,c6623f78,c01fc852) at exit1+0x1b1
> > > kthread_suspend(0,c0279a40,0,c022d1ec,a2) at kthread_suspend
> > > ithd_loop(0,c6623fa8) at ithd_loop+0x56
> > > fork_exit(c01fc7fc,0,c6623fa8) at fork_exit+0x8
> > > fork_trampoline() at fork_trampoline+0x8
> > > db> witness_list
> > > "Giant" (0xc0279a40) locked at ../../i386/isa/ithread.c:162
> >
> > Erm, ithd_loop() doesn't call kthread_suspend(). *sigh*. Something
> > else is rather messed up here I'm afraid.
>
> So I thought... also, kthread_suspend() doesn't call exit1(), does it?
>
>
> No matter what, ithd_loop() calls kthread_exit() which calls exit1()
> which happily MALLOC's with M_WAITOK...
> Something is messed up, indeed, but it seems to be a case of WISIWYG instead
> of what I mean... ;-)
>
>
> Also, I think this issue has been there longer but it might have been masked
> by me not having INVARIANTS defined at times (am I correct to read the code as
> not panicing #ifndef INVARIANTS?). So I am going back before this revision:
>
> revision 1.78
> date: 2001/01/21 19:25:07; author: jake; state: Exp; lines: +3 -2
> Make intr_nesting_level per-process, rather than per-cpu. Setup
> interrupt threads to run with it always >= 1, so that malloc can
> detect M_WAITOK from "interrupt" context. This is also necessary
> in order to context switch from sched_ithd() directly.
>
This is why you're getting the panic in exit1(), but I thought I fixed
this in intr_machdep.c version 1.47.
revision 1.47
date: 2001/01/28 17:20:11; author: jake; state: Exp; lines: +2 -1
Clear intr_nesting_level when an interrupt thread has no more
handlers and wants to exit, so it doesn't panic in exit1()
which malloc()s with M_WAITOK.
Reported by:Bob Bishop <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Current SMP Kernel panics
> > Should it become: > > #ifdef SMP > mtx_lock_spin(&sched_lock); > need_resched(); > forward_roundrobin(); > mtx_unlock_spin(&sched_lock); > #else > > ? > > I cannot test it yet, need to reanimate my testbox first. You need to handle the UP case as well :) Also, I don't think that sched_lock should be held across forward_roundrobin(). But, my box still hangs with the assertion satisifed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_synch.c
> jake2001/02/10 11:07:32 PST > > Modified files: > sys/kern kern_synch.c > Log: > Acquire sched_lock around need_resched() in roundrobin() to satisfy > assertions that it is held. Since roundrobin() is a timeout there's > no possible way that it could be called with sched_lock held. > > Revision ChangesPath > 1.126 +5 -9 src/sys/kern/kern_synch.c > > This fixes the tripped assertion in need_resched(), but -current still hangs on boot. We're working on it :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/i386/i386 trap.c
> jake2001/02/10 12:33:35 PST > > Modified files: > sys/alpha/alpha trap.c > sys/i386/i386trap.c > Log: > Clear the reschedule flag after finding it set in userret(). This > used to be in cpu_switch(), but I don't see any difference between > doing it here. > > Revision ChangesPath > 1.45 +2 -1 src/sys/alpha/alpha/trap.c > 1.174 +2 -1 src/sys/i386/i386/trap.c > > This fixes -current on my machines (i386 UP and SMP). Should be in the clear now. asmodia has seen a lock reversal between the process lock and uidinfo lock, but I can't reproduce it. You probably want to remove the kernel option WITNESS_DDB if you have it it enabled. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
> jake2001/02/11 16:20:08 PST > > Modified files: > sys/alpha/alpha trap.c > sys/dev/acpica/Osd OsdSchedule.c > sys/i386/i386genassym.c swtch.s trap.c > sys/ia64/ia64trap.c > sys/kern init_main.c kern_condvar.c kern_idle.c > kern_intr.c kern_mib.c kern_mutex.c > kern_proc.c kern_resource.c kern_sig.c > kern_subr.c kern_switch.c kern_synch.c > sys/posix4 ksched.c > sys/sys ktr.h param.h proc.h rtprio.h systm.h > tty.h user.h > sys/ufs/ffs ffs_snapshot.c > sys/vm vm_glue.c vm_meter.c > Added files: > sys/sys priority.h runq.h > Log: > Implement a unified run queue and adjust priority levels accordingly. ... As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. As always, make world is your friend. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
> On Sun, Jan 28, 2001 at 01:27:04AM -0800, Julian Elischer wrote: > > > This is the single most flagrant lack of cooperation I have experienced > > > while working with the FreeBSD Project. I'm truly dumbfounded. > > > > It's not a lack of co-operation.. it's a lack of communication. I didn't > > see an any lists that anyone was doing this yet and thought I'd get > > the ball rolling to promote discussion.. I'm dumfounded to discover that you've > > done work here already as I thought I'd have heard of it. > > We've been waiting on JHB's (and others) locking changes on the proc > structure because those will do nothing but make conflicts in the patches > jasone has already. > > Has JHB made all the proc changes he was going to? Probably not entirely, but enough. I think you guys should go ahead. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Apparently, On Wed, Jan 08, 2003 at 11:25:12PM +, Mike Barcroft said words to the effect of; > Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html > > -- > >>> 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 >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include > -- > >>> stage 4: building libraries > -- > >>> stage 4: make dependencies > -- > >>> stage 4: building everything.. > -- > >>> Kernel build for GENERIC started on Wed Jan 8 22:16:49 GMT 2003 > -- > ===> vx > touch: >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms: > No such file or directory > *** Error code 1 FWIW, I can't reproduce this locally, it must be a problem with the tinderbox. I haven't seen Mike around lately, hopefully he can see what's going on soon. Sorry for the spam. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superblock layout hosed on LP64 systems [was: Re: HEADS UP: VFS changes breaks GPT]
Apparently, On Thu, Jan 09, 2003 at 03:29:43PM -0800, Marcel Moolenaar said words to the effect of; > On Thu, Jan 09, 2003 at 01:12:30AM -0800, Marcel Moolenaar wrote: > > > > GPT based systems are unable to mount the root file system. I > > haven't had the time to dig into this, but we must be making > > assumptions we previously didn't make. In any case ia64 is > > hosed. More to come... > > Ok, after digging a bit I noticed that the super block layout > has changed in a way that makes it incompatible with previous > super blocks. It appears to be the alignment of fs_uuid on > revision 1.36 of sys/ufs/ffs/fs.h. > > Previously: > Sizeof superblock=1376 > Offset of magic=1372 > > Now: > Sizeof superblock=1384 > Offset of magic=1380 It might be worth putting in some CTASSERTs to verify that the size of the superblock and/or offsets of important fields don't change. This would give 64 bit people a heads up before they try to boot a broken kernel, and would make compiling a kernel on one of the reference boxes more useful for people who don't have a 64 bit machine for runtime testing. Jake > > This typically results in not being able to fsck the file system > with a post-change fsck on a pre-change kernel and not being able > to mount the file system with a post-change kernel. > > The following patch fixes the problem (and fixes the misuse of > uuid for something that is not universally unique): > > Index: fs.h > === > RCS file: /home/ncvs/src/sys/ufs/ffs/fs.h,v > retrieving revision 1.36 > diff -u -r1.36 fs.h > --- fs.h 8 Jan 2003 22:53:54 - 1.36 > +++ fs.h 9 Jan 2003 23:23:28 - > @@ -117,7 +117,7 @@ > * in fs_fsmnt. MAXMNTLEN defines the amount of space allocated in > * the super block for this name. > */ > -#define MAXMNTLEN472 > +#define MAXMNTLEN468 > > /* > * The volume name for this filesystem is maintained in fs_volname. > @@ -311,7 +311,8 @@ > int8_t fs_old_flags; /* old FS_ flags */ > u_char fs_fsmnt[MAXMNTLEN]; /* name mounted on */ > u_char fs_volname[MAXVOLLEN]; /* volume name */ > - u_int64_t fs_uuid; /* system-wide unique uid */ > + u_int64_t fs_swuid; /* system-wide unique id */ > + int32_t fs_pad; > /* these fields retain the current block allocation info */ > int32_t fs_cgrotor;/* last cg searched */ > void*fs_ocsp[NOCSPTRS]; /* padding; was list of fs_cs buffers */ > > -- > Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] > > 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: fpsetmask on sparc64
Apparently, On Sat, Jan 11, 2003 at 07:16:26PM -0800, Kris Kennaway said words to the effect of; > fpsetmask is not defined in or > on sparc64 (it is on i386): > > /usr/include/machine/floatingpoint.h:#definefpsetmask(m)((fp_except_t) \ > /usr/include/ieeefp.h:extern fp_except_t fpsetmask(fp_except_t); > /usr/include/floatingpoint.h:#definefpsetmask(m)((fp_except_t) > > This appears to cause the following port failures/warnings: > > amphetamine-0.8.10.log:src/Main.cpp:79: `fpsetmask' undeclared (first use this >function) > glasteroids-1.0.log:Glasteroids.cxx:82: `fpsetmask' undeclared (first use this >function) > lame-devel-3.89b.log:util.c:883: warning: implicit declaration of function >`fpsetmask' > smalltalk-2.0.8.log:lex.c:814: warning: implicit declaration of function `fpsetmask' > xmrm-2.0_2.log:morphvec.cc:439: `fpsetmask' undeclared (first use this function) > > Is this an omission, or are the ports wrong? FWIW, the alpha headers are basically identical to the sparc64 ones. There may be missing ifdefs in the ports or the makefiles. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fpsetmask on sparc64
Apparently, On Sun, Jan 12, 2003 at 12:25:20AM -0800, Terry Lambert said words to the effect of; > Jake Burkholder wrote: > > > Is this an omission, or are the ports wrong? > > > > FWIW, the alpha headers are basically identical to the sparc64 ones. > > There may be missing ifdefs in the ports or the makefiles. > > Isn't that really a lame excuse? Shouldn't > > #ifdef __FreeBSD__ > > be enough to make code compile on all FreeBSD platforms? I don't know, why don't you try it. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fpsetmask on sparc64
Apparently, On Sun, Jan 12, 2003 at 05:09:37AM -0800, Terry Lambert said words to the effect of; > Jake Burkholder wrote: > > > Isn't that really a lame excuse? Shouldn't > > > > > > #ifdef __FreeBSD__ > > > > > > be enough to make code compile on all FreeBSD platforms? > > > > I don't know, why don't you try it. > > I understand the snide reply. My point was that if FreeBSD had My point is that you could help by actually doing something. Your repeated long emails DO NOT HELP. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vm panic
Apparently, On Thu, Jan 23, 2003 at 11:45:13AM +0800,
David Xu said words to the effect of;
> panic: lockmgr: locking against myself
> Debugger("panic")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db>trace
> Debugger(c0381630,c03e4ee0,c037fd14,da447c28,1) at Debugger+0x54
> panic(c037fd14,0,c037fc88,eb,1fb) at panic+0xab
> lockmgr(c138e85c,2,0,c3c150e0,c3c1514) at lockmgr+0x512
> _vm_map_lock_read(c138e280,c039bc27,896,238d3c,527) at _vm_map_lock_read+0x5a
> vm_map_check_protection(c138e80,826400,826500,2,c03b1980) at
>vm_map_check_protection+0x31
> useracc(8264fc4,8,2,1,c038b1f) at useracc+0x7d
> nanosleep(c3c150e0,da447d10,c039f3e,407,2) at nonosleep+0x53
> syscall(bfbf002f,804002f,826002f,bfbffbe0,804a420) at syscall+0x28e
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x280b0853, esp = 0x8264fb8, ebp
>= 0x8264fd4
>
> At the time, I am running ksetest, a kse based threaded program.
> Is the vm still not safe to run threaded program?
>
> David Xu
>
Don't know if this is the problem or not but the lockmgr code uses the
pid as the lock cookie, so it can't distinguish 2 threads from the same
process acquiring a lock.
I noticed that netbsd has fixed this for lwps.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: What is the difference between p_ucred and td_ucred?
Apparently, On Mon, Feb 03, 2003 at 09:08:41AM -0500, Ilmar S. Habibulin said words to the effect of; > > Why not to use only credits for proc and make td_ucred macro like > td_proc->p_ucred? Or it has some meaning that i do not understand? td_ucred is a read only reference to p_ucred, so you can access it without needing any locks. Its potentially updated on each kernel entry. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: question on profiling code
Apparently, On Mon, Feb 17, 2003 at 05:35:09PM +1100, Bruce Evans said words to the effect of; > On Sun, 16 Feb 2003, Julian Elischer wrote: > > > In addupc_intr, if the increment cannot be done immediatly, the addres > > to increment the count for is stored and the increment is done later at > > ast or userret() time... > > Note that "cannot be done immediatly" is "always except on sparc64's" > under FreeBSD, since incrementing the counter immediately is only > implemented on sparc64's. > > > is there any reason that the address of the PC needs to be stored? > > why is the address from the frame at that time not useable? > > > > is it because the PC in the return frame may be hacked up for signals? > > That's was good a reason as any. I think the next return to user mode > is to the signal handler's context (if there is a signal to be handled). > It would be wrong to use the signal handler's pc. Also, ast() doesn't > have access to the frame, and there is no macro like CLKF_PC() for > general frames. This probably doesn't matter much, since signals are > rare and the hitting on the signal handler's pc would be perfectly > correct if the profiling interrupt occurred an instant later. There are macros for accessing trapframes, like the ones for clockframe, TRAPF_PC etc. > > Now there is a stronger reason: clock interrupt handling is "fast", > so it normally returns to user mode without going near ast(), and the > counter is not updated until the next non-fast interrupt or syscall. In freebsd "fast" interrupts do handle asts, on i386 they return through doreti (you may consider this a bug and have removed it in your version). I see no reason not to just use the pc in the trapframe passed to ast, even in the case of signals they won't be posted until after addupc_task is called. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: question on profiling code
>
> Can you explain how fuswintr() and suswintr() work on sparc64's? They
> seem to cause traps if the user counter is not mapped, and I can't see
> where the traps are handled. ia64/trap.c has a comment about where these
> traps are handled, but has dummies for fuswintr() and suswintr() so the
> traps never occur. Depending on traps in fast interrupt handlers is
> a bug IMO. It extends the scope of the fast interrupt handler to the
> trap handler, and it is difficult to limit this scope and verify the
> locking for it.
Ok. Sparc64 uses "lazy trap handling", similar to how I saw you'd done
in your sys.dif. The functions that access user space are delimited by
labels, and in trap and trap_pfault we check to see if the pc is inside
of the labels. fuswintr and suswintr and bracketed by fs_nofault_intr_begin
and fs_nofault_intr_end, which trap_pfault checks for specifically before
doing much of anything:
if (ctx != TLB_CTX_KERNEL) {
if ((tf->tf_tstate & TSTATE_PRIV) != 0 &&
(tf->tf_tpc >= (u_long)fs_nofault_intr_begin &&
tf->tf_tpc <= (u_long)fs_nofault_intr_end)) {
tf->tf_tpc = (u_long)fs_fault;
tf->tf_tnpc = tf->tf_tpc + 4;
return (0);
}
... handle fault
ctx != TLB_CTX_KERNEL is akin to va < VM_MAXUSER_ADDRESS (the address spaces
overlap on sparc64 so we can only rely on tlb context numbers). Note that
the range bracketed by the fs_nofault_intr_* is included in the fs_nofault
range, which handles alignment or data access exception faults.
It does take some special care in trap() and trap_pfault() not to access
important data, or acquire any locks before this test. Non-trivial
interrupts are still masked here, which buys us something. Probably the
vmspace pointer should not be counted on in this context, but I don't think
it will ever be invalid for the current process, especially since the original
interrupt occured in usermode.
The only locking that's required that I can see is that PS_PROFIL not be
set when the profiling buffer is invalid. But all that will happen is that
attempts to update the profiling buffer will be ignored. Technically the
process should get a signal but addupc_task doesn't check the return value
of copyin/out (oops).
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch for the nVidia driver and -CURRENT
Apparently, On Tue, Feb 25, 2003 at 10:49:16PM +0100,
Maxime Henrion said words to the effect of;
> Morten Rodal wrote:
> > On Tue, Feb 25, 2003 at 07:28:09PM +0100, Maxime Henrion wrote:
> > [snip a lot of the patch]
> > > @@ -1431,7 +1442,8 @@
> > > SLIST_FOREACH(at, &sc->alloc_list, list) {
> > > if (offset >= at->address &&
> > > offset < at->address + at->size)
> > > -return atop(vtophys(offset));
> > > +*paddr = vtophys(offset);
> > > +return 0;
> > > }
> > >
> > > return -1;
> >
> > Should the function return 0 even if the if (offset..) fails? I have
> > no clue about the nvidia kernel driver (or kernel stuff at all) but it
> > seems to me that the only way the function can return -1 is if the
> > list is empty.
>
> And this is consistant with what the code was doing before. This change
> is not a functional change, it's just a necessary update due to API
> changes.
I think he's referring to missing braces around the if which was changed
from 1 statement to 2.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Floppyless release build of sparc64
Apparently, On Wed, Jul 23, 2003 at 09:16:43AM +0300,
Ruslan Ermilov said words to the effect of;
> A similar change would be in order for sparc64. Patch is
> attached, please review. The net effect is that we save
> huge CPU times in release.9 and do not create the useless
> boot.flp floppy image (the sparc64/mkisoimages.sh script
> doesn't need it).
boot.flp is actually useful on sparc64 because you can dd it to a disk
from solaris and then boot off it to install. I'm happy with having
the option of not building it if it saves time but please make it an
option.
Jake
>
> On Tue, Jul 22, 2003 at 10:53:53PM -0700, Ruslan Ermilov wrote:
> > ru 2003/07/22 22:53:53 PDT
> >
> > FreeBSD src repository
> >
> > Modified files:
> > release Makefile
> > Log:
> > Do not define BIGBOOTSIZE and the friends for amd64; it serves
> > no useful purpose other than wasting CPU time in "make release"
> > creating useless boot.flp.
> >
> > Desired by: peter
> >
> > Revision ChangesPath
> > 1.789 +0 -3 src/release/Makefile
>
>
> Cheers,
> --
> Ruslan ErmilovSysadmin and DBA,
> [EMAIL PROTECTED] Sunbay Software Ltd,
> [EMAIL PROTECTED] FreeBSD committer
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/release/Makefile,v
> retrieving revision 1.790
> diff -u -r1.790 Makefile
> --- Makefile 23 Jul 2003 06:00:56 - 1.790
> +++ Makefile 23 Jul 2003 06:09:41 -
> @@ -202,11 +202,8 @@
> BIGBOOTLABEL=minimum2
> .elif ${TARGET_ARCH} == "sparc64"
> DISKLABEL= sunlabel
> -BIGBOOTSIZE= 4096
> MFSSIZE= 4096
> -BOOTINODE= 8192
> MFSINODE=8192
> -BIGBOOTLABEL=auto
> MFSLABEL=auto
> .elif ${TARGET_ARCH} == "ia64"
> BIGBOOTLABEL=efi
> Index: sparc64/dokern.sh
> ===
> RCS file: sparc64/dokern.sh
> diff -N sparc64/dokern.sh
> --- sparc64/dokern.sh 13 Oct 2002 18:36:06 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,6 +0,0 @@
> -#!/bin/sh
> -#
> -# $FreeBSD: src/release/sparc64/dokern.sh,v 1.1 2002/10/13 18:36:06 jake Exp $
> -#
> -
> -sed -e 's/ident.*GENERIC/ident BOOTMFS/g'
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dereferencing type-punned pointer will break strict-aliasingrules
Apparently, On Mon, Jul 28, 2003 at 03:59:00AM +0200,
Thomas Moestl said words to the effect of;
> On Mon, 2003/07/28 at 09:30:08 +0900, Jun Kuriyama wrote:
> >
> > Is this caused by -oS option?
> >
> > - in making BOOTMFS in make release
> > cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
> > -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev
> > -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter
> > -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL
> > -include opt_global.h -fno-common -finline-limit=15000 -mno-align-long-strings
> > -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/geom/geom_dev.c
> > /usr/src/sys/geom/geom_dev.c: In function `g_dev_open':
> > /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will
> > break strict-aliasing rules
> > [...]
>
> Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
> workaround. The problem is caused by the i386 PCPU_GET/PCPU_SET
> implementation:
>
> #define __PCPU_GET(name) ({ \
> __pcpu_type(name) __result; \
> \
> [...]
> } else if (sizeof(__result) == 4) { \
> u_int __i; \
> __asm __volatile("movl %%fs:%1,%0" \
> : "=r" (__i)\
> : "m" (*(u_int *)(__pcpu_offset(name; \
> __result = *(__pcpu_type(name) *)&__i; \
> [...]
>
> In this case, the PCPU_GET is used to retrieve curthread, causing
> sizeof(__result) to be 4, so the cast at the end of the code snippet
> is from a u_int * to struct thread *, and __i is accessed through the
> casted pointer, which violates the C99 aliasing rules.
> An alternative is to type-pun via a union, which is also a bit ugly,
> but explicitly allowed by C99. Patch attached (but only superficially
> tested).
>
> - Thomas
>
...
Using a union sounds fine to me.
Jake
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: pmap_remove_all: illegal for unmanaged/fake page 0x9d2000
On Thursday 02 October 2003 14:54, Chris Jackman wrote: > Sun E250, running world/kernel from September 18th. > While running a make buildworld, I get : > > panic: pmap_remove_all: illegal for unmanaged/fake page 0x9d2000 Update and build a new kernel. This has been fixed. Jake ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new-bus breaks both sound drivers
> Hmm, you might like to try this patch and see what happens, there is > a missing old driver wrapper for the pcm stuff. As a result, it's not > getting run from the isa probe. Regarding the other driver, I'm not > sure what's going on there as the hooks appear to be present. Right on, that patch does it for me. pcm0 at port 0x220 irq 5 drq 1 flags 0x15 on isa0 pcm0: interrupting at irq 5 I've got an old SB16 Value, non-pnp. mp3s aren't playing quite right with x11amp though, little skips here and there, they work fine with the old kernel. mpg123 seems fine, as does the sound in FXTV. I'll try making the world again. IPFW works for me...but I'm loading the KLD. my panasonic cdrom is no longer probed, it uses the matcd driver. doesn't show up in dmesg at all, but it does in the visual kernel config thing. It's so old, I'm not surprised :) great work! Jake -- we are but packets in the internet of life To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
new-bus, pcm, and matcd (was Re: new-bus breaks both sound drivers)
> >mp3s aren't playing quite right with x11amp though, little > >skips here and there, they work fine with the old kernel. > >mpg123 seems fine, as does the sound in FXTV. > >I'll try making the world again. > > Was there ever any resolution/further inspection of this? Not as far I know; its still happening here. cmp3 (mpg123) also skips in the same way, but its much less noticeable. I've been updating and recompiling almost daily. also, is it known that the matcd driver is now non-functional? It doesn't get probed at all, but it does show up in the visual kernel config screen. Its a 2x cdrom drive that plugs into my sb16; proprietary interface, not IDE. > grep matcd /sys/i386/conf/JAKE controller matcd0 at isa? port 0x230 bio > dmesg | grep matcd > Thank you. Jake -- we are but packets in the internet of life To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
config nit
Hi, I just noticed that after all the dequote stuff went into config (great work!) options NO_F00F_HACK still needs quotes. Its interpreted as NO_F0F_HACK without them; to be expected I guess. This should probably be reflected in LINT. Thanks, Jake -- we are but packets in the internet of life To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Some interrupt bogons still around.
> > my stock SB16 + freebsd+x11amp hasn't worked right since newbus. > > sound skips quite a bit. > > > I noticed the same thing. /usr/ports/audio/gqmpeg is a nice player which uses mpg123 as the backend; it plays fine. I think it may have just have something to do with x11amp, which should probably be considered a bogon itself. All other sources of sound work fine, like fxtv. (I have the same sound card as you; pcm driver.) Jake -- Linux - Zealotry taken over the Edge To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Updated if_* attach/detach patches
Apparently, On Wed, Mar 19, 2003 at 10:37:43AM -0800, Nate Lawson said words to the effect of; > I have updated my patches for: > dc pcn rl sf sis sk ste ti tl vr wb xl > They have been compile tested but I only have an rl card so I'd appreciate > feedback. > > Patches are at: > http://www.root.org/~nate/freebsd/if_pci/ > > Clean up locking and resource management for pci/if_* > > - pcn: add missing bzero of softc > - wb: add missing bzero of softc > - xl: add missing bzero of softc FWIW, the softc is allocated with M_ZERO, and probably lots of drivers depend on this already. It might be better to just remove all bzero-ing of the softc. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PAE and large ram support.
Hi, If you haven't read on cvs-src, just recently I've committed support for PAE and more than 4G of ram on x86 to -current. Basically what this does is allows physical memory above 4G to be used normally by the kernel and userland. Except in certain circumstances no distinction is made between memory above and below 4G, it all just becomes part of the general page pool. This does not increase the amount of virtual address space, just the amount of physical memory you can use. We'd like this feature to be solid for 5.1-RELEASE, so I'm hoping there are people out there with systems with more than 4G of ram that are willing to test it. Its been tested pretty extensively with 6G of ram, I'd be very interested to hear from anyone with substantially more than that. There are a couple caveats to be aware of: 1. Not all device drivers will work properly, the hardware must either support 64 bit PCI addressing, or the driver must use busdma, which will use bounce buffers for DMA to memory not accessible by the hardware. I've committed a PAE kernel config (/sys/i386/conf/PAE) which excludes drivers that are known to totally not work, or which have not been tested. In short, the list of "certified" drivers at this time is: - aac - ahc - ahd - ata - em - fxp - xl plus all the normal stuff which doesn't use DMA. The aac, ahc, ahd and em drivers will use 64 bit pci addressing, no bounce buffering will occur. The others will use bounce buffers for DMA to memory above 4G; performance is not likely to be that hot, but it will work. 2. You must not load kernel modules into a PAE kernel. In particular, many machines with large amounts of memory are recent designs and require acpi, which is normally loaded as a kernel module. You must compile it statically into the kernel with 'device acpi', this is included in the PAE kernel config. 3. The auto-tuning that the kernel does starts to fall apart pretty fast with lots of memory. With 6G the maximum number of vnodes gets set higher than the kernel address space can support, so you may want to limit it to around 100,000 with the kern.maxvnodes sysctl. There are probably other things that are allocated based on physical memory size only and which don't scale past 4G. We need people with varying memory configurations to try it to know what else needs to be tuned. I'm not sure I can trump Peter, but in any case I've put up the dmesg from my test machine: http://people.freebsd.org/~jake/tip.pae. The hardware was provided by FreeBSD Systems, www.freebsdsystems.com. Thanks, Jake ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i386 trap code
Apparently, On Fri, Jul 05, 2002 at 05:43:26PM -0700, Julian Elischer said words to the effect of; > > Looking at i386/exception.s > one sees: [...] > > Now: > > would it not make a lot of sense to put doreti immediatly after > calltrap: in the same file > so that one could follow the entire picture without having to bounce back > and forth between two files? I'd say so, yeah. Its probably there because it used to be alongside splz and unmasked pending isa interrupts. > > (also gets rid of the jmp in the common case) System calls are probably the common case. But I'd suggest just put it after the trap code at the end of the file and leave the jump. Its super aligned so there would probably be a bunch of nops to plow through anyway. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wierd routing Problems
Apparently, On Fri, Aug 02, 2002 at 12:02:28AM +0200, Sten said words to the effect of; > > I am currently running Current on an u60 > and it seems to be running quite nicely minus > some gotchas and not yet working ports. > Thanks for the hard work. > > I do however have one pretty strange problem. > Some apps cant seem to route properly, aka they > cant reach remote hosts because routing lookups bork. > > The box has a ipv4 default gateway, propper subnetmask, > I tried kernels without ipv6 ( didnt help ). The problem > only shows up with certain apps. I haven't noticed much out of the ordinary, but I don't use the programs you mention. I would suspect this is a 64bit and/or endian-ness problem somewhere; someone mentioned a while ago that ncftp doesn't work on alpha either. Jake > > Par expample ntpd from system : > newpeer: 62.250.7.101->213.196.8.44 mode 3 vers 4 poll 6 10 flags 1 1 ttl > 0 key > peer_clear: at 0 assoc ID 0 > key_expire: at 0 > newpeer: 127.0.0.1->127.127.1.0 mode 3 vers 4 poll 6 6 flags 21 1 ttl 0 > key > report_event: system event 'event_restart' (0x01) status 'sync_alarm, > sync_unspec, 1 event, event_unspec' (0xc010) > auth_agekeys: at 1 keys 1 expired 0 > key_expire: at 1 > key_expire: at 1 > expire_all: at 1 > key expire: at 1 next 65536 > transmit: at 10 62.250.7.101->213.196.8.44 mode 3 > refclock_transmit: at 11 127.127.1.0 > refclock_receive: at 11 127.127.1.0 > peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, > event_reach' (0x8014) > refclock_sample: n 1 offset 0.00 disp 0.01 jitter 0.00 > > Versus ntpd on stable : > > newpeer: 213.196.8.44->194.109.6.65 mode 3 vers 4 poll 6 10 flags 1 1 ttl > 0 key > transmit: at 4 213.196.8.44->193.79.237.14 mode 3 > receive: at 4 213.196.8.44<-193.79.237.14 mode 4 code 1 > peer 193.79.237.14 event 'event_reach' (0x84) status 'unreach, conf, 1 > event, event_reach' (0x8014) > clock_filter: n 1 off 0.005574 del 0.010882 dsp 7.937531 jit 0.61, age 0 > > ( looks like the transmit: routing wanders of into the woods :) > > > Ncftp2/3 seem to bork in a somewhat similar way : > > Hi. No need to log in; I'm an anonymous ftp server. > Logged in to ftp.openwall.com. > ncftp / > ls > List failed. > ncftp / > quit > Could not bind the data socket: Can't assign requested address > > > I was wondering if this a known problem, feel free to slap > me with a large trout if this is a local config problem. > Thanks in advance for any help. > > -- > Sten Spans > > "What does one do with ones money, >when there is no more empty rackspace ?" > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-sparc" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aout support broken in gcc3
Apparently, On Mon, Sep 02, 2002 at 02:24:08PM +1000,
Bruce Evans said words to the effect of;
> aout support is still required for a few things (mainly for compiling
> some boot blocks), but is broken in gcc3 for at least compile-time
Which boot blocks?
> assignments to long longs and shifts of long longs by a non-constant
> amount:
>
> %%%
> $ cat z.c
> long long x = 0;
> int y;
>
> foo()
> {
> x = x << y;
> }
> $ cc -O -S -aout z.c
> $ cat z.s
> .file "z.c"
> .globl _x
> .data
> .p2align 3
> .type _x,@object
> .size _x,8
> _x:
> .quad 0
> .text
> .p2align 2,0x90
> .globl _foo
> .type _foo,@function
> _foo:
> pushl %ebp
> movl%esp, %ebp
> movb_y, %cl
> movl_x, %eax
> movl_x+4, %edx
> shldl %eax, %edx
> sall%cl, %eax
> testl $32, %ecx
> je L2
> movl%eax, %edx
> movl$0, %eax
> L2:
> movl%eax, _x
> movl%edx, _x+4
> leave
> ret
> Lfe1:
> .size _foo,Lfe1-_foo
> .comm_y,4
> .ident "GCC: (GNU) 3.1 [FreeBSD] 20020509 (prerelease)"
> %%%
>
> The above assembler output has two syntax errors:
> - ".quad 0". .quad is not supported by the old aout assembler.
> - "shldl %eax, %edx". The old aout assembler only accepts the correct
> syntax of "shldl %cl,%eax,%edx". Note that gcc doesn't elide the
> similarly implicit %cl register for the sall instruction.
>
> Bruce
>
>
> 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: sparc64 tinderbox failure
Apparently, On Mon, Sep 02, 2002 at 08:21:12PM -0700, Peter Wemm said words to the effect of; > Alexander Kabaev wrote: > > On Mon, 2 Sep 2002 19:51:59 GMT > > Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: > > > > > ===> gnu/usr.bin/cc/cc1plus > > > method.o: In function `use_thunk': > > > method.o(.text+0x90c): undefined reference to `sparc_output_mi_thunk' > > > > Is this gcc 3.1 trying to build 3.2 or gcc 3.2 trying to build itself? > > Buildworld completes fine on panther, the only FreeBSD sparc64 machine I > > have access to. > > This has got to be a local problem, perhaps where src/contrib/sparc/sparc.c > is out of sync on the builder machine. This builds fine on > panther.freebsd.org. Yeah, I just finished a native world here and have cross built several since the compiler upgrade. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lightweight interrupt threads
Apparently, On Tue, Oct 01, 2002 at 01:46:50AM -0400, Robert Watson said words to the effect of; > Dunno who it was, but my understanding is that we already actually use > lightweight interrupt threads on sparc64, so you might want to peruse > there and look at the approach taken. :-) You might have been talking to Not yet :) Its in my perforce tree still; still some issues to resolve. I remember Bosko mentioning this though (kse loaning). Jake > Bosko (possibly at USENIX ATC), as he was maintaining an i386 lightweight > interrupt thread implementation (although I think it got fairly hosed over > time due to a lot of changes in the main tree). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories > > On Mon, 30 Sep 2002, Julian Elischer wrote: > > > > > I was talking to someone about lightweight interrupt threads > > and interactions with KSEs and specifically about > > KSE borrowing.. > > > > Believe it or not, I can't remember who it was.. > > if it was you, let me know :-) > > > > Julian > > > > > > > > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Longer term fix for sigreturn ABI breaking
Apparently, On Tue, Oct 01, 2002 at 11:12:02AM -0400, Daniel Eischen said words to the effect of; > On Mon, 30 Sep 2002, Peter Wemm wrote: > > > Daniel Eischen wrote: > > > At the end is a potentially longer term fix for the ABI > > > breakage that was introduced when the i386 mcontext_t > > > was changed/enlarged. > > > > > - ret = set_fpcontext(td, &ucp->uc_mcontext); > > > - if (ret != 0) > > > - return (ret); > > > + /* > > > + * Intentionally ignore the error to keep binary > > > + * compatibility with applications that fiddle with > > > + * the FPU save area in the context. The kernel > > > + * now saves the FPU state in the context, but it > > > + * gets corrupted by those applications that try > > > + * to work around the kernel NOT saving it. > > > + */ > > > + (void)set_fpcontext(td, &ucp->uc_mcontext); > > > > Maybe we could have something like this instead? > > > > ret = set_fpcontext(td, &ucp->uc_mcontext); > > #if !defined(COMPAT_FREEBSD4) && !defined(COMPAT_43) > > if (ret != 0) > > return (ret); > > #endif > > > > ie: ignore the error only if we have to be compatable. > > Sure that's totally doable. It might not be enough to just > call set_fpcontext() and ignore the error. Thinking a bit > more about it, the mc_len, mc_fpformat, and mc_ownedfp fields > now occupy the first couple of slots where fpregs[] used to be. > The format of an fnsave() stores the control, status and tag > words in these slots. There are 32-bits of storage allocated > for each of these, but the fnsave (according to what I > see in npx.h), only uses the lower 16 bits. It might be > possible to save a control word or status word that turn > out to be valid for mc_fpformat or mc_ownedfp (0, 1, or 2). > In this case we'd think the FP context was valid, and try > to restore it (it would be trashed). > > I think if we put some magic in the upper 16 bits of > mc_ownedfp, mc_fpformat, then we could prevent this. > > > Longer term, I was thining that we could/should do what sparc64 does, ie: > > libc provides the trampoline and it can then call the correct sigreturn > > syscall. That means we add a new sigreturn syscall each time we > > significantly break the sigreturn ABI (as in this case) and applications > > will be able to use the correct one. Paired with a new sigaction syscall > > which would specify the "new" context format we can then be future proof. > > Sounds good. If we added a new sigaction and sigreturn now, we can > still do the same thing, without having the trampoline in libc. > I thought the point of having the trampoline in libc would prevent > having to create new syscalls... The point is that the signal trampoline automatically uses the new or old system calls because its linked with libc. Otherwise you need a different signal trampoline in the kernel for each version of sigreturn, and some way to determine the right one. The 0x01ds16 hack only works for so long. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Ugly PATCH] Again: panic kmem_malloc()
Apparently, On Sat, Oct 19, 2002 at 12:19:57AM +0200, Ben Stuyts said words to the effect of; > Terry, > > At 23:07 18/10/2002, you wrote: > >Ben Stuyts wrote: > > > Furthermore, this might be interesting: the last vmstat -m log > > > before the panic. Maybe someone can check if these values are reasonable? > > > The system has 64 MB memory and has been up for about 24 hrs with almost no > > > load. > > >sem344456 5390K 5390K 344456 16,1024,4096 > > > >Almost 5.3M of unswappable physical memory dedicated to semaphores > >seems like a bit much. > > Yes, and it increases continuously, for example when I fetch new mail (over > pop) from my windows pc. The pc stores this again on a network drive, so > both qpopper and smbd are involved. For example, vmstat -m says: > semop() leaks memory. An important free() was removed by alfred in rev 1.55. Try this. Jake Index: sysv_sem.c === RCS file: /home/ncvs/src/sys/kern/sysv_sem.c,v retrieving revision 1.55 diff -u -r1.55 sysv_sem.c --- sysv_sem.c 13 Aug 2002 08:47:17 - 1.55 +++ sysv_sem.c 19 Oct 2002 01:20:35 - @@ -1128,6 +1128,8 @@ td->td_retval[0] = 0; done2: mtx_unlock(sema_mtxp); + if (sops) + free(sops, M_SEM); return (error); } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Apparently, On Thu, Oct 24, 2002 at 04:19:09PM -0400, Andrew Gallatin said words to the effect of; > > Mike Barcroft writes: > > >>> stage 4: building everything.. > > -- > > ===> usr.sbin/pkg_install/info > > cc1: warnings being treated as errors > > /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c: In function `show_size': > > /tinderbox/sparc64/src/usr.sbin/pkg_install/info/show.c:239: warning: passing arg >1 of `getbsize' from incompatible pointer type > > *** Error code 1 > > > > > I fixed this an hour or 2 ago when I hit it on my alpha. > > How long does a sparc64 buildworld take on reasonably priced hardware? > Where resonable means <= $1000 USD, used OK. You can get a dual 300mhz ultra 60 on ebay for $900-1000 USD. Mine does a make -j 8 buildworld in just over 2 hours with some strategic stuff turned off in make.conf (profiled libs, objective c, fortran). Thu Oct 24 15:10:18 GMT 2002 7546.53 real 10633.14 user 1818.80 sys Search for "sun ultra" on ebay; I got mine from paladintech. Ultra 10s are cheaper but more PC class, my 300mhz does a full buildworld in about 5 hours last time I timed it. Ultra 2 is probably the best value, but we don't support the builtin scsi controller yet. You can also get various new machines on sun.com for around $1000 USD, IIRC a 500mhz blade 100 does a buildworld in around 2-3 hours. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Apparently, On Tue, Oct 29, 2002 at 08:55:03AM -0500, Andrew Gallatin said words to the effect of; > > David O'Brien writes: > > On Thu, Oct 24, 2002 at 06:39:15PM -0400, Jake Burkholder wrote: > > > You can also get various new machines on sun.com for around $1000 USD, > > > IIRC a 500mhz blade 100 does a buildworld in around 2-3 hours. > > > > A $1000 (new) 500 MHz blade running GENERIC (minus WITNESS) builds world > > in a little under 3 hours. > > Or just a little slower than my 4 year old 500MHz 21264 (<$1000 used) > alpha. Darn. I was hoping a reasonbly priced sparc64 would be fast > enough that getting one would allow me to find LP64 problems quicker > due to a faster buildworld cycle. It's really frustrating to get 2+ > hours into a buildworld and have it die because of a problem in > usr.sbin > > I guess we'll need to wait for x86-64 for that. Cross build on a fast x86 box... My 1.2ghz athlon running -stable builds a sparc64 world in about half an hour. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Apparently, On Tue, Nov 05, 2002 at 12:54:54PM +0600, Max Khon said words to the effect of; > hi, there! > > On Mon, Nov 04, 2002 at 01:57:35PM -0800, David O'Brien wrote: > > > > another 2.4M for /rescue. That makes it less > > > impressive. I don't find the duplication appealing, either. > > > (Why not just put the /rescue versions directly > > > into /bin and /sbin? That would be smaller still, > > > > Because that would nullify one of the big reasons for making /bin and > > /sbin shared -- so one can dlopen(3). We can't, for instance, get a > > proper nsswitch implementation until we make /bin and /sbin dynamic. > > > > Before someone says you can dlopen() from static binaries in order to > > implement nsswitch, please provide the patch proving it. Our best > > FreeBSD minds don't think it can be done properly and sanely. > > I have the patch. Currently it is made against RELENG_4 and I have a couple > of questions about alpha (however it works on alpha too with a few hacks). > Unfortunately, jdp does not have enough time to review it and I have > lack of time to port it to -current (that would not be that hard but > since sparc64 is now Tier-1 platform the patch should be ported to > sparc64 too but I do not have sparc64 hardware and access to > panther is very slow from my home). > > What is the right place to post the patch and test program > demonstrating dlopen for statically linked programs? Put it up somehere on the web or email it to the list. I'd be interested in looking at it. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
Apparently, On Tue, Nov 05, 2002 at 01:21:42PM +0600, Max Khon said words to the effect of; > hi, there! > > On Tue, Nov 05, 2002 at 02:18:23AM -0500, Jake Burkholder wrote: > > > > > Before someone says you can dlopen() from static binaries in order to > > > > implement nsswitch, please provide the patch proving it. Our best > > > > FreeBSD minds don't think it can be done properly and sanely. > > > > > > I have the patch. Currently it is made against RELENG_4 and I have a couple > > > of questions about alpha (however it works on alpha too with a few hacks). > > > Unfortunately, jdp does not have enough time to review it and I have > > > lack of time to port it to -current (that would not be that hard but > > > since sparc64 is now Tier-1 platform the patch should be ported to > > > sparc64 too but I do not have sparc64 hardware and access to > > > panther is very slow from my home). > > > > > > What is the right place to post the patch and test program > > > demonstrating dlopen for statically linked programs? > > > > Put it up somehere on the web or email it to the list. I'd > > be interested in looking at it. > > Ok, I put the patch and test program to > http://people.freebsd.org/~fjoe/libdl.tar.bz2. > > Patches are made against RELENG_4 (and all tests were done on RELENG_4) > but it will not be that hard to port everything to -CURRENT. > This is just a proof-of-concept work-in-progress. > > The plan is to add this stuff (rtld sources with -DLIBDL) to libc.a > so statically linked programe will have dlopen/dlsym etc. > > Problems with current patches are: > - I do not know what to do on alpha with _GOT_END_ and > _GLOBAL_OFFSET_TABLE_ symbols. I had to use ld.so.script > to solve missing _GOT_END_ problem and ifdef out _GLOBAL_OFFSET_TABLE_ > usage from alpha/reloc.c for second problem. An advice from alpha rtld > guru will be very useful > - gdb support for shared objects dlopened from statically linked > program is broken > - rtld_exit() is not called on exit so fini functions are not > called on exit > - probably more stuff could be #ifdef'ed out from rtld when it is compiled > with -DLIBDL > - xmalloc and friends names in rtld sources probably should be prepended > with an underscore to prevent name clashes (if this stuff will be included > in libc.a) > > Any comments, suggestions, patches will be very appreciated. I think there are more problems than you realize. They are very hard to fix. You've basically hacked rtld to bits. All the ifdefs make it hard to read and maintain. This statically links rtld into any static binary that wants to use dlopen. What was that about saving space on the root partition? -rwxr-xr-x 1 jake wheel 143177 Nov 5 11:57 hello This is more than twice as big as a normal static binary which just calls printf on my system. ~90K bloat just for dlopen. I don't see that you've dealt with getting the linker to generate the tables that rtld needs; an _DYNAMIC section, a dynsym table, a dynstr table etc. These are needed in order to look up symbols in the statically linked binary itself. Getting the linker to do this is not overly difficult, we do it for the kernel, but it bloats the static binaries more. It also creates a special case in the makefiles, unless we do this for all static binaries, which would cause a lot of bloat. As a result of the above, how do you deal with multiple implementations of library services being present? For example a statically linked binary calls malloc, so it has a copy of malloc linked into it. It tries to dlopen a library which also calls malloc. Which copy of malloc does the library use? How does it locate the malloc that's linked into the static binary without the dynamic tables? What happens when the application tries to free a pointer allocated by the library, or vice versa? When David said we didn't think it could be done properly or sanely, we meant it. It must work exactly like it would in a dynamic binary. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libc size
> > You've basically hacked rtld to bits. All the ifdefs make it hard
> > to read and maintain.
>
> There number of #ifdef's is not large (for me) to make rtld unmaintainable.
> If this is inappropriate for you there are two obvious ways to solve it:
> - refactor rtld-elf and move common parts of libdl (or whatever) and
> rtld-elf to separate files
> - unifdef rtld-elf and put libdl sources separately
>
> The reasons I implemented this as a patch for rtld-elf are:
> - I did not want to create two almost identical pieces of code
> - I wanted to make these patches as obvious as they can be.
> This is just a proof-of-concept work.
Understood, but I think that either solution is not great. We either
wedge libdl into rtld or we have 2 copies of large amounts of rtld.
>
> > This statically links rtld into any static binary that wants to use
> > dlopen. What was that about saving space on the root partition?
>
> I didn't tell you or anyone else that this work is done towards
> saving space in /. The question was about nsswitch and (in particular)
> dlopen in statically linked programs.
Ok.
> > It also creates a special case in the makefiles, unless
> > we do this for all static binaries, which would cause a lot of bloat.
>
> Are you talking about STATICOBJS and SHOBJS? This is how libpam is built
> right now. You have different sets object files in shared and static
> versions of libpam. Please take a look at src/lib/libpam/libpam/Makefile
> and corresponding /usr/share/mk bits.
What I was referring to is a trick to force the linker to generate
a dynamic binary with all the usual elf dynamic tables, but which is
actually statically linked.
eg:
> cat test.c
int
main(void)
{
printf("hello world\n");
}
> cc -static -Wl,-r -o test test.c
> touch hack.c
> cc -shared -o hack.So hack.c
> ld -o test1 test /home/jake/hack.So
> ./test1
hello world
>
Conceivably this would allow dlopen to work on the main program, and is
what we do to allow the kernel to link klds against itself. But you
also need to do something about the .interp section that gets put in,
and the .dynamic, .dynsym and .dynstr sections aren't free.
>
> > As a result of the above, how do you deal with multiple implementations
> > of library services being present? For example a statically linked
> > binary calls malloc, so it has a copy of malloc linked into it. It tries
> > to dlopen a library which also calls malloc. Which copy of malloc does
> > the library use? How does it locate the malloc that's linked into the
> > static binary without the dynamic tables?
>
> A part of answer is above (about ld not knowing which symbols
> shared object will want). The real solution is to link
> shared libraries with all objects they will need (including libc).
> This is how things are implemented in other systems.
> As a result library will use malloc from libc that will be
> loaded as a dependency (and this is demonstrated in the example I posted).
>
> > What happens when the application
> > tries to free a pointer allocated by the library, or vice versa?
>
> This is not possible for obvious reasons.
> On Linux you will get SEGFAULT (for the same obvious reasons).
> Yes, this is a limitation.
>
> > When David said we didn't think it could be done properly or sanely, we
> > meant it. It must work exactly like it would in a dynamic binary.
>
> You can't get exact behaviour. But this behaviour is sufficient
> for PAM and NSS. Maybe there are some other (less important) uses for
> this stuff.
What I'm suggesting is that for libdl to be a viable alternative to
making the binaries in / dynamic so that pam works, it has to work
better. Preferably as good as in dynamic binaries, and without the
foot shooting potential that having 2 copies of malloc or other things
loaded entail. Yes, a simple implementation may work for PAM, but
using full blown dynamic linking is architecturally much cleaner and
I think that this outweighs the disadvantages.
>
> Sorry for being too emotional, but none of your questions make sense.
> I highly appreciate your work on sparc64 but seems that
> you were in bad mood when typing an answer.
Very bad, sorry. :)
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Apparently, On Sun, Nov 17, 2002 at 12:23:20PM -0800, Julian Elischer said words to the effect of; > > > On Sun, 17 Nov 2002, Mike Barcroft wrote: > > -- > > >>> Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002 > > -- > > ===> ipfilter > > /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create': > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first >use in this function) > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is >reported only once > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears >in.) > > > ok mea culpa.. > > what is there in SPARC that should be used instead..? mp_ncpus is defined in sys/smp.h which is not included kern_thread.c I don't see why this builds on any platform. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [REPORT] Upgrade from 4.0-RELEASE to 5.0-CURRENT
Apparently, On Sun, Dec 01, 2002 at 01:15:00PM -0200, Daniel C. Sobral said words to the effect of; > There I go reply to all... > > IIRC, we never supported upgrade to 4.0 or 4.1 from anybut but the > *latest* version in the 3.x series. I sure hope we adopt the same policy > here. Agree, I don't see any use in supporting upgrades without going through 4.x-STABLE first. Jake > > Ruslan Ermilov wrote: > > > > [ > > current@ Cc:'ed because it'll be useful to a number of upgraders. > > dougb@ Cc:'ed to be aware of possible mergemaster(8) problems. > > imp@ Cc:'ed to be aware of incorrect UPDATING instruction. > > peter@ Cc:'ed to LOL about foot-shooting with anti-foot-shooting. > > re@ Cc:'ed to consider approving the attached patches. > > ] > > > > Hi! > > > > Following is the report from my attempt to upgrade 4.0-RELEASE > > system to 5.0-CURRENT. First, I'd like to say that I succedded > > in it: > > > > FreeBSD 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Mon Mar 20 22:50:22 GMT 2000 >[EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386 > > FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Dec 1 13:52:37 GMT 2002 >ru@:/usr/obj/ru/mnt/usr/src/sys/GENERIC i386 > > > > 4.0-RELEASE system was installed on a spare disk by newfs'ing the > > `a' partition and extracting the `bin' distribution on top of it > > from the 4.0-RELEASE 1st CD, thanks again to Charlie Brewster > > <[EMAIL PROTECTED]> for sending me one. > > > > The /etc/make.conf's contents was a mere NOPROFILE=YES. > > > > Buildworld was attempted under a non-root account. The installed > > make(1) did not pass the regression tests, and this required a patch > > to src/Makefile (attach #1) to survive; the patch allows one to > > build and use the new make(1) under non-root, without the need to > > overwrite /usr/bin/make. (This patch, with Warner's suggestion > > incorporated, is currently considered by re@ for approval.) > > > > Other than that, both buildworld and buildkernel of the GENERIC > > kernel went just fine. > > > > The next step was to install the new kernel and modules, as outlined > > in UPDATING. > > > > As a prerequisite step (following the instructions from UPDATING) > > I've created the /boot/device.hints file, and attempted to > > installkernel. This failed with ``You must activate /boot/device.hints > > in loader.conf.'' from kern.post.mk because 4.0 does not have > > /boot/defaults/loader.conf. (Rather than creating it by hands, I > > took another approach, see below.) > > > > As was documented in rev. 1.219 of UPDATING, after installing a > > kernel (which I did not yet succeded in), it is highly recommended > > to install new loader(8), and generally, upgrade /boot. > > > > WARNING! The relevant instruction from UPDATING, > > > > cd src/sys/boot ; make install > > > > will NOT work as is on most of old systems -- if run as is, make(1) > > will use stuff from /usr/share/mk which may be incompatible with > > sys/boot/ makefiles. Adding the -m `pwd`/../../share/mk did not > > help either because now make(1) was attempting to run 4.0's install(1) > > which does not understand the new -b option (INSTALLFLAGS=-b in > > sys/boot/i386/loader/Makefile), in particular. Another problem > > with 4.0 install(1) is that it removes source files by default, > > while new versions of install(1) (4.3-STABLE and onwards) copy it > > by default, so if you attempted to run it as is, it will wipe out > > some already built stuff from /usr/obj, making the next installworld > > attempt to fail. > > > > To overcome this, I needed to use the installworld environment [with > > an up-to-date src/share/mk/ and install(1)] to install sys/boot/. > > Fortunately, we have the SUBDIR_OVERRIDE knob in Makefile.inc1 that > > was helpful here. > > > > So, my next attempt was to run, from src/, the following command: > > > > make installworld SUBDIR_OVERRIDE=sys/boot > > > > This would upgrade /boot, and (as part of the upgrade) install > > /boot/defaults/loader.conf that is needed for installkernel to > > proceed (see above). Unfortunately, this has failed to pass the > > `installcheck' anti-foot-shooting check from Makefile.inc1, which > > installworld depends on: > > > > 1. smmsp user was missing from /etc/passwd and /etc/group > > 2. installed 4.0 kernel did not have the sigaction(2) syscall > > > > I've attempted to overcome 1) as suggested by UPDATING, by running > > the ``mergemaster -p'' (from src/usr.sbin/mergemaster/). This did > > not work well because mergemaster(8) attempted to use stat(1) which > > is not present in 4.0. OK, it was trivial (in my case) to update > > /etc/master.passwd and /etc/group by hands and run ``pwd_mkdb -p > > /etc/master.passwd'' afterwards. > > > > I couldn't overcome 2) for obvious reason -- I was in the middle > > of attempting to install a new kernel! Isn't this itself a sort > > of foot-shooting? :-) > > > > The solution was to make the `installche
Re: UMA panic under load
Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500, Brian F. Feldman said words to the effect of; > John Baldwin <[EMAIL PROTECTED]> wrote: > > > > On 12-Dec-2002 Kris Kennaway wrote: > > > I got this on an alpha tonight. It was under heavy load at the time > > > (18 simultaneous package builds had just been spawned on the machine). > > > Any ideas? > > > > > > Slab at 0xfc00042d3fb8, freei 2 = 0. > > > panic: Duplicate free of item 0xfc00042d22e0 from zone >0xfc0007d31800(VMSPACE) > > > > > > db_print_backtrace() at db_print_backtrace+0x18 > > > panic() at panic+0x104 > > > uma_dbg_free() at uma_dbg_free+0x170 > > > uma_zfree_arg() at uma_zfree_arg+0x150 > > > vmspace_free() at vmspace_free+0xe4 > > > swapout_procs() at swapout_procs+0x428 > > > vm_daemon() at vm_daemon+0x74 > > > fork_exit() at fork_exit+0xe0 > > > exception_return() at exception_return > > > --- root of call graph --- > > > panic > > > Stopped at Debugger+0x34: zapnot v0,#0xf,v0 > > > db> > > > > I have seen this on a couple of different arch's I think. A vmspace > > shouldn't be free'd here, it's refcount should not be that low. > > I wonder if something is free'ing the vmspace w/o dropping the refcount? > > The problem appears to be that swapout_procs() is swapping out a process > that is in the process of exiting (in exit1()) and having already > relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be > preventing the swapout). It's clearly not correct for a process in exit1() > to be swapped out, and the vmspace _needs_ to be decremented in the correct > place or resources are NEVER freed when the race is lost. P_WEXIT is set, so the process won't get swapped out. The problem is that the vmspace refcnt is 0 when swapout_procs is called, since it was decremented in exit1. The refcnt is incremented before p_flag is tested for P_WEXIT, the swapout is skipped because its found to be set, and then vmspace_free is called which decrements the refcnt to 0 and prematurely frees the vmspace. Decrementing the refcnt in exit1 breaks the normal refernce count semantics because the vmspace is not being freed then. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Apparently, On Fri, Dec 20, 2002 at 03:26:36AM +, Mike Barcroft said words to the effect of; > -- > >>> 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 >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include > -- > >>> stage 4: building libraries > -- > >>> stage 4: make dependencies > -- > >>> stage 4: building everything.. > -- > ===> sys/boot/sparc64/loader > In file included from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15: > machine/asm.h:105:1: warning: "__FBSDID" redefined > In file included from machine/asm.h:46, > from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15: > /tinderbox/sparc64/src/sys/sys/cdefs.h:239:1: warning: this is the location of the >previous definition > /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: `zipfs_fsops' undeclared >here (not in a function) > /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: initializer element is >not constant > /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: (near initialization for >`file_system[2]') > *** Error code 1 > Fixed, my apologies. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: First (easy) td_ucred patch
Apparently, On Fri, Feb 22, 2002 at 11:38:07PM -0500, John Baldwin said words to the effect of; > I'm currently testing the following patch whcih is a subset of the td_ucred > changes. It involves no API changes, but only contains 2 basic changes: > > 1) We still need Giant when doing the crhold() to set td_ucred in >cred_update_thread(). This is an old bug that is my fault. I knew that >PROC_LOCK was sufficient yet which was my reason for not using td_ucred. >However, we could still be derferencing a stale p_ucred and doing very bad >things, so this needs to be fixed until p_ucred is fully protected by the >PROC_LOCK. This also means that td_ucred is now safe to use. As such: > > 2) All the "easy" p->p_ucred -> td->td_ucred changes that don't involve the >changes to API's such as suser() and p_canfoo(). The next patch in this >series will most likely be the suser() API change. > > http://www.FreeBSD.org/~jhb/patches/ucred.patch The UGAR changes in sysv_sem.c to not leak Giant are most unreleated and should probably be committed separately. I wonder who introduced the leaks in the first place. Other than that I don't see anything wrong with this. Commit it. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc_bucket() idea (was Re: How to fix malloc.)
Apparently, On Sat, Feb 23, 2002 at 02:43:35PM -0800, Matthew Dillon said words to the effect of; > This is approximately what I am thinking. Note that this gives us the > flexibility to create a larger infrastructure around the bucket cache, > such as implement per-cpu caches and so on and so forth. What I have > here is the minimal implementation. > > -Matt Jeff Roberson (jeff@) has been working on a slab allocator that goes a long way to making malloc(), free() and the zone allocator not require giant. I've reviewed what he's got so far and it looks pretty damn good to me, I'll see about getting him to post it. He's working on adding the per-cpu queues now. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: First (easy) td_ucred patch
Apparently, On Sat, Feb 23, 2002 at 11:21:24AM -0800, Julian Elischer said words to the effect of; > > > On Fri, 22 Feb 2002, John Baldwin wrote: > > > > > http://www.FreeBSD.org/~jhb/patches/ucred.patch > > > the structural rewriting in kern_proc.c should be done as a separate > commit. (though I agree it should be done) > > the structural rewriting in kern/sysv_*.c > could be done as a separate commit as well. > (I agree it is worth doing) > > I'll let you get away with unp_listen() :-) I'd like to point out that in all cases that you mention, the original structure before the "giant pushdown" is being restored. A lot of structural rewriting occured in those commits. It was not done separately. I don't recall if the patches were posted for review, I certainly never saw them. This strikes me as a double standard. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assembly revamp, please review!
Apparently, On Sun, Feb 24, 2002 at 11:12:22AM -0800,
Matthew Dillon said words to the effect of;
> NOTES:
>
> I would like to thank Bruce for supplying the sample code that allowed
> me to do this in a day instead of several days.
>
> * debug.critical_mode sysctl. This will not be in the final commit,
> nor will any of the code that tests the variable. The final commit
> will use code as if the critical_mode were '1'.
>
> The default is 1, which means to use the new streamlined
> interrupt and cpu_critical_enter/exit() code. Setting it to 0
> will revert to the old hard-interrupt-disablement operation. You
> can change the mode at any time.
>
> * Additional cpu_critical_enter/exit() calls around icu_lock. Since
> critical_enter() no longer disables interrupts, special care must
> be taken when dealing with the icu_lock spin mutex because it is
> the one thing the interrupt code needs to be able to defer the
> interrupt.
>
> * MACHINE_CRITICAL_ENTER define. This exists to maintain compatibility
> with other architectures. i386 defines this to cause fork_exit to
> use the new API and to allow the i386 MD code to supply the
> critical_enter() and critical_exit() procedures rather then
> kern_switch.c
>
> I would much prefer it if the other architectures were brought around
> to use this new mechanism. The old mechanism makes assumptions
> in regards to hard disablement that is no longer correct for i386.
For sparc64 we basically already have this in hardware. There is both
an interrupt enable (IE) bit and a soft interrupt priority. Hardware
interrupts are masked by the IE bit. In all cases they just queue the
interrupt packet that is sent by the hardware in a per-cpu interrupt
queue and post a soft interrupt. The critical_* stuff only masks soft
interrupts; hard interrupts are rarely masked. The queueing is written
in assmebler and runs outside of the kernel so it is fast. Traps in
general are fast because they don't touch memory until the trapframe
is written out, so I don't see much point in changing this do the masking
in software and avoid the soft interrupt.
In regards to the patch I think that making critical_enter/exit MD in
certain cases is a mistake. cpu_critical_enter/exit are already MD
and it looks you could hide this behind them with some minor changes.
Like in the critical_enter case, make cpu_critical_enter take a thread
as its argument. It could be a null macro in the i386 case, which would
optimize out the test.
if (td->td_critnest == 0)
cpu_critical_enter(td);
td->td_critnest++;
Likewise with cpu_critical_exit, make it take the thread as its argument.
If (td->td_critnest == 1) {
td->td_critnest = 0;
cpu_critical_exit(td);
} else
td->td_critnest--;
(This is equivalent to if (--td->td_critnest == 0), its a matter of taste.)
The fork case is a little different, hmm. I'd have to think about it more.
An md function/macro would probably suffice.
I notice the you are using cpu_critical_exit for the purpose of disabling
interrupts only, like cli, sti. I think that you should use api that tmm
wrote for sparc64 for this so that it can do more. i386 does not really
have cli/sti equivalents otherwise.
s = intr_disable() disables interrupts and returns the old state.
intr_restore(s) restores the state s.
I don't really like this change in general because it complicates things
more than I'd like, but I also don't have a bearing on how expensive cli/sti
are. It would seem to me that it just takes a few more clock cycles, which
isn't that important. I understand that it increases latency for the fast
part of the interrupt handler, but they are not able to run in critical
sections anyway due to the software masking.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assembly revamp, please review!
Apparently, On Sun, Feb 24, 2002 at 09:03:53PM -0800,
Matthew Dillon said words to the effect of;
> :...
> :interrupts; hard interrupts are rarely masked. The queueing is written
> :in assmebler and runs outside of the kernel so it is fast. Traps in
> :general are fast because they don't touch memory until the trapframe
> :is written out, so I don't see much point in changing this do the masking
> :in software and avoid the soft interrupt.
>
> I have no idea what you are talking about Jake. Could you supply
> some context?
Sorry, maybe I got ahead of myself. I was responding to your suggestion
that other architectures should pick up this design. This does not make
sense for sparc64.
>
> :In regards to the patch I think that making critical_enter/exit MD in
> :certain cases is a mistake. cpu_critical_enter/exit are already MD
> :and it looks you could hide this behind them with some minor changes.
> :
> :Like in the critical_enter case, make cpu_critical_enter take a thread
> :as its argument. It could be a null macro in the i386 case, which would
> :optimize out the test.
> :
> :if (td->td_critnest == 0)
> : cpu_critical_enter(td);
> :td->td_critnest++;
> :
> :Likewise with cpu_critical_exit, make it take the thread as its argument.
> :
> :If (td->td_critnest == 1) {
> : td->td_critnest = 0;
> : cpu_critical_exit(td);
> :} else
> : td->td_critnest--;
> :(This is equivalent to if (--td->td_critnest == 0), its a matter of taste.)
>
> I'm afraid I have to strongly disagree. I believe that
> critical_enter()/exit is *ALREADY* being severely misused in current.
> For example, fork_exit() makes assumptions about the underlying hardware
> in order to initialize td_critnest and the scheduler mutex safely. This
> is just plain broken. fork_exit() should not make any such assumptions.
> It is the clear responsibility of either the trampoline code or
> cpu_fork() to properly set up td_critnest. One can make an argument
> that the sched_lock fixup is in fork_exit()'s domain but you cannot
> make the argument that the initialization of critnest (and any associated
> hardware state) is MI. It just isn't.
>
> Additionally, critical_enter()/exit themselves are certainly much
> more MD then MI. It makes little sense to abstract out an MI interface
> that forces unnecessary overhead when all you have to do is define an
> MD API that has a few MI requirements, like td_critnest being a critical
> nesting count that the MI code can count on. But as MI code the existing
> critical_enter()/exit impose additional MD fields and do not give the
> MD code the option of not using them (except in a degenerate fashion).
> Specifically, the use of the td_savecrit field is under the partial
> contorl of the MI code when it shouldn't be, not just in fork_exit()
> but also in critical_enter() and critical_exit() themselves.
>
> The existing critical_enter/exit code is far too abstracted for its
> low-level purpose and I *WILL* be moving them into MD sections of the
> system where they belong. These are really MD routines, not MI routines.
Fine. As long as their functionality with respect to MI code does not
change I don't care.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assem
Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500, Robert Watson said words to the effect of; > > On Thu, 7 Mar 2002, Warner Losh wrote: > > > In message <[EMAIL PROTECTED]> Julian >Elischer writes: > > : > > : > > : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: > > : > > > : > Then do the right things so it will. > > : > > : Unfortunatly that has been proven to not work. > > : > > : after reverting the change and silently waiting for a week > > : 1/ no person bothered to review it. > > : 2/ people assumed the patch had gone away. > > > > Ummm, There are reviews in the archives that object to the API as it > > relates to optimization and those objections haven't been sanely > > answered with anything more constructive than "BS". > > The primary objections I've seen from Jake, and he posted them as part of > the earlier thread prior to the commit, was that the API changes proposed > by Matt don't make sense for the sparc64 implementation, uni-processor or > multi-processor, and that while these changes might be appropriate for > i386, he wanted to see the APIs set up in such a way that the differences > in architectures were hidden in the MD code. This suggests working some > more on the API before moving on, and my reading of earlier posts in the > thread from John was that that was what he had in mind also. Yes. What I would like and what I mentioned before is for this to be hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter would be a null macro for i386, which would turn critical_enter into just an increment, as Matt wanted. cpu_critical_exit would do all the magic of unpending interrupts. The reason for this is that I would like to see critical_exit handled any pending preemptions for a thread. We do not yet know exactly how this will work so I would like this to be done in MI code to start with. The code must not make assumptions that are not valid on all platforms. This is easiest if they use the same code. This is not about duplication of code in several MD files. Bruce also had some comments which were shrugged off, I thought they were important. Specifically, please do not make unnecessary changes to the assembler code. Macros do not need to be defined before they are used, I believe this was the justification for some of the reordering in apic_vector.s which makes the patch confusing. Please do not tab out the "; \" at the end of the lines in the INTR and FAST_INTR macros in icu_vector.s. This just makes unnecessary diffs. The PUSH_DUMMY macro must push a reasonable eip value, in addition to the code segment, so that profiling and stack traces work right. If you have not already, please make sure that a trace from inside an interrupt handler that was unpended looks somewhat normal. Please also make sure that kgdb is able to decode the frame properly. It assumes that the eip of the frame will be near certain kernel symbols in order to determine what kind of frame it is. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assem
Apparently, On Thu, Mar 07, 2002 at 07:04:49PM -0800, Matthew Dillon said words to the effect of; > :Yes. What I would like and what I mentioned before is for this to be > :hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter > :would be a null macro for i386, which would turn critical_enter into > :just an increment, as Matt wanted. cpu_critical_exit would do all the > :magic of unpending interrupts. The reason for this is that I would > :like to see critical_exit handled any pending preemptions for a thread. > :We do not yet know exactly how this will work so I would like this to be > :done in MI code to start with. The code must not make assumptions that are > :not valid on all platforms. This is easiest if they use the same code. > :This is not about duplication of code in several MD files. > > We can't, because the MI code makes some rather blatent assumptions > in regards to cpu_critical_enter and exit. Take the witness code, > for example. So we cannot safely null-out those macros. In fact, > the MI code also makes some rather blatent assumptions in regards > to critical_enter() and exit which I have also had to clean up > (and which will need considerably more cleanup). I agree that the use of cpu_critical_enter/exit could use cleaning up. Can you give an example of where critical_enter is used improperly? You mean in fork_exit? Your changes to cpu_switch solve that problem with critical_exit almost unchanged. The savecrit stuff should really just be made MD. If cpu_critical_exit was changed to take the thread as its argument as I suggested before this would be easy. Specifically I think that all of the current uses of cpu_critical_enter exit outside of critical_enter exit are bugs. The use in ktr is bogus because the increment of ktr_idx is done atomically. I don't know why this was there in the first place. I think that witness is an example of where we need a different specifically defined to be hard interrupt disable api. This is why I suggested the intr_disable/intr_restore api, which should only be used in MD code and in dire circumstances otherwise, of which this case qualifies. The code in ast is just structured wrong. I think that before the loop was in assembler outside of the routine itself, so that it didn't make so many assumptions about interrupt disablement. doreti which calls it should look like this: loop: cli; if (there is an ast we can handle) goto ast; iret; ast: sti; call ast; goto loop; In which case ast doesn't need to loop or use critical sections at all. All of the MD code I could find I think should use a different api for hard interrupt disablement. They are all very MD and need this specifically, which cpu_critical_enter need not necessarily do. With these changes I don't see why the critical_enter/exit functions can't or shouldn't remain MI. > > These assumptions include, just as an example: The witness code > calling cpu_critical_enter()/exit without holding td_critnest count, > and Peter's now withdrawn code which explicitly released the cpu > critical section while holding a non-zero td_critnest count. In > otherwords, really aweful hacks. So we can't just NULL out those > inlines. > > Trying to keep critical_enter()/critical_exit() MI and > cpu_critical_enter()/cpu_critical_exit() MD and separated doesn't > make much sense to me, because frankly critical_enter() and > critical_exit() are tiny little routines (and will remain tiny even > after SWI and preemption is added) and I can't think of any reason > to force higher complexity in the routines due to the separation. > > In short, critical_enter()/critical_exit() are TIGHTLY INTEGRATED > with cpu_critical_enter/exit despite your attempt to make > critical_enter/exit MI. What my patch does is accept as true the > fact that the two sets of routines are, in fact, tightly integrated, > and then implements them in a more sensible way (or, more to the > point, allows each architecture to implement them in the proper > manner as befits the architecture). I do not agree that having cpu_critical_enter separate in any way hinders an architecture's ability to implement critical_enter properly. The MI code that calls it expects it to do certain things, one of them is to call cpu_critical_enter and cpu_critical_exit exactly once for each non-nested critical_enter exit pair. Wether or not this actually disables interrupts is up to the MD code. > > The API's are still MI, but the implementation is MD. > > :Bruce also had some comments which were shrugged off, I thought they > :were important. Specifically, please do not make unnecessary changes > :to the assembler code. Macros do not need to be defined before they > :are used, I believe this was the justification for some of the reordering
Re: Patch for critical_enter()/critical_exit() & interrupt assem
Apparently, On Fri, Mar 08, 2002 at 01:23:01AM -0800, Matthew Dillon said words to the effect of; > > :I agree that the use of cpu_critical_enter/exit could use cleaning up. > :Can you give an example of where critical_enter is used improperly? > :You mean in fork_exit? Your changes to cpu_switch solve that problem > :with critical_exit almost unchanged. The savecrit stuff should really > :just be made MD. If cpu_critical_exit was changed to take the thread > :as its argument as I suggested before this would be easy. > > fork_exit() is a good example. The existing code explicitly > initializes td->td_critnest to 1 and then sets td->td_savecrit > to CRITICAL_FORK: > > td->td_critnest = 1; > td->td_savecrit = CRITICAL_FORK; > > It then proceeds to unlock the sched_lock spin lock. > > This code only works because interrupts are hard-disabled in the > fork trampoline code. In otherwords, the code assumes that > cpu_critical_enter() and cpu_critical_exit() play with hard interrupt > disablement. If interrupts were enabled there would be two severe > race conditions in the code: The first upon entering fork_exit > prior to ke_oncpu being set, and the second when td->td_critnest is set > to 1 prior to td_savecrit being set to CRITICAL_FORK. > > > The current ast() code is another example. This code calls > cpu_critical_enter() and cpu_critical_exit() without bothering to bump > the critical nesting count (i.e. bypasses critical_enter() and > critical_exit()). > > > Peter's hack to fix IPI deadlocks (no longer in -current) is a > third example. He enters a critical section using critical_enter() > and then calls cpu_critical_exit() while still holding td_critnest = 1, > which breaks even a conservative reading of the API :-) > > -- > > There are also a huge number of places where cpu_critical_*() is > used specifically in the I386 code for interrupt disablement. I am > happy to clean it up, but not until after the multiple stages of > my current patch set are in the tree because there are just too many > places that have to be modified for me to feel comfortable doing both > at once. Nor do I believe it makes sense to clean up cpu_critical_*() > just to try to keep critical_*() in MI code (see below two sections). > > > :Specifically I think that all of the current uses of cpu_critical_enter > :exit outside of critical_enter exit are bugs. The use in ktr is bogus because > > Certainly in MI code, I agree. These cases can be attacked incrementally. > fork_exit() will be fixed completely by my patches since it has to be > for my code to work properly. I was planning on leaving ast() alone > for the moment (because I am not planning on making cpu_critical_enter() > a NOP any time soon). I would be willing to work on this after my > patch is staged in (carrot and stick). Ok. > > :there in the first place. I think that witness is an example of where > :we need a different specifically defined to be hard interrupt disable api. > :This is why I suggested the intr_disable/intr_restore api, which should only > :be used in MD code and in dire circumstances otherwise, of which this case > :qualifies. The code in ast is just structured wrong. I think that before > :the loop was in assembler outside of the routine itself, so that it didn't > > Witness is a special case allright. I don't know if I agree with > extending a hard interrupt disablement API out to MI code though. I agree that it should be avoided. John would know better why exactly this is needed and he may have already fixed it. > > :make so many assumptions about interrupt disablement. doreti which calls > :it should look like this: > : > :loop: > : cli; > : if (there is an ast we can handle) > : goto ast; > : iret; > :ast: > : sti; > : call ast; > : goto loop; > : > :In which case ast doesn't need to loop or use critical sections at all. > :All of the MD code I could find I think should use a different api for > :hard interrupt disablement. They are all very MD and need this specifically, > :which cpu_critical_enter need not necessarily do. > > I would agree with this methodology. > > :With these changes I don't see why the critical_enter/exit functions can't > :or shouldn't remain MI. > > Cleaning up cpu_critical_enter()/exit would require a huge number of > changes that I am not prepared to do right now, not only in i386, but > in all architectures using cpu_critical_enter() and cpu_critical_exit() > - alpha, i386 (many places), and ia64, not to mention ast(), fork_exit(), > witness, subr_trap.c, and ktr.c. I suppose the routines could simply > be renamed in the MD sections but the MI sections are going to be > harder to fix. > > It doesn't make much sense to me to spend so
Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
Apparently, On Fri, Mar 08, 2002 at 05:33:28PM -0500, Garance A Drosihn said words to the effect of; > >On Fri, 8 Mar 2002, Murray Stokely wrote: > > >As discussed at BSDCon, the release engineers are committed > > > to releasing a relatively stable snapshot of FreeBSD -CURRENT > > > on or around April 1, 2002. > > Will this release include some kind of bootable-install support > for any new hardware platforms, such as sparc64? (this snapshot > is meant to be available as some kind of CD-package, right?) Yes, absolutely. I'm really excited that the sparc64 port is ready to be part of this. It will probably not be a regaular freebsd release, there will be (already is) a bootable iso that has all the tools needed to install a distribution from a tarball quickly and easily (the cd boots multi user). There will be a self hosted toolchain which can be used to build a custom kernel. This can also be used to build userland and ports natively, but make buildworld may not work. I will be cutting another iso this weekend which fixes a couple problems with the first one. Anyone who has a sparc64 machine is invited to subscribe to the freebsd-sparc mailing list and be testers for the first semi-official fresbsd/sparc64 release. . Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )
Apparently, On Fri, Mar 08, 2002 at 04:12:47PM -0800, Terry Lambert said words to the effect of; > Jake Burkholder wrote: > > > Will this release include some kind of bootable-install support > > > for any new hardware platforms, such as sparc64? (this snapshot > > > is meant to be available as some kind of CD-package, right?) > > > > Yes, absolutely. > > Wow. > > This is really impressive. > > I thought it wasn't going to be available until the preview > just before the final release! > > Good work! Make Robert update his notes... Thanks. Alot of this actually happened since the meeting ;) Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lock warning...
Apparently, On Sun, Mar 17, 2002 at 09:17:22AM -0800, Alfred Perlstein said words to the effect of; > * Robert Watson <[EMAIL PROTECTED]> [020317 09:08] wrote: > > > > On Sun, 17 Mar 2002, Alfred Perlstein wrote: > > > > > * Munehiro Matsuda <[EMAIL PROTECTED]> [020317 06:36] wrote: > > > > > > > > PS. I got another message that happend when I ^C'ed a buildworld earlier, > > > > with same kernel. May be it should go to Alfred Perlstein? > > > > > > > > lock order reversal > > > > 1st 0xc198eec0 pipe mutex @ ../../../kern/sys_pipe.c:779 > > > > 2nd 0xc0367fe0 Giant @ ../../../i386/i386/trap.c:716 > > > > > > I think there's a place where the pipe can fault on an address while > > > copying, I'll take a look at this. > > > > Are there any assertions that should be in place for copyin/copyout > > requring fault handling? It sounds like somewhere we need to assert that > > Giant is held... > > No, you need to assert that no other mutex other than Giant is held. > > It would be nice... :) You can do this like at the bottom of syscall and trap, with witness_list(). It'll even print out what the other locks are and where they were acquired. But yeah, if you're going to access pageable memory in kernel mode you pretty much have to have no other locks held. Good work on pipe locking btw. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: comparing executables
Apparently, On Wed, Apr 03, 2002 at 10:01:36PM +0200, Poul-Henning Kamp said words to the effect of; > In message <[EMAIL PROTECTED]>, Ju > lian Elischer writes: > > > > > >On Wed, 3 Apr 2002, Poul-Henning Kamp wrote: > > > >> > >> >How can I find out which binaries have changed? > >> >they are all different according to cksum so I assume > >> >that there is a timestamp or something in them. > >> >Is there a way to compare only the text segments? > >> > >> You can do wonders with objdump(1) and diff. > > > >hmmm ok.. > >what about libraries? > > .a you take apart with ar(1), .so you're stuck as far as my knowledge > goes. objdump works on both of these, the addresses won't be resolved though. > > -- > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT and P-IV problems
Apparently, On Sun, May 05, 2002 at 10:44:44AM +1000,
Bruce Evans said words to the effect of;
> On Sat, 4 May 2002, David O'Brien wrote:
>
> > On Sat, May 04, 2002 at 09:26:33PM +0100, Brian Somers wrote:
> > > Try disabling -pipe when building the compiler. This seems to make
> > > things more stable here (CFLAGS=-O in /etc/make.conf) - as if
> > > building the kernel with -pipe sometimes produces a kernel that
> > > subsequently murders the compiler with sig11/sig4 all the time.
> >
> > If so, then we have a bug in our pipe ('|', not 'gcc -pipe')
> > implimentation.
>
> I have seen signs of a generic pipe bug in vi: vi's i/o buffer for
> pipes is sometimes invalid (kern/sys_pipe.c:pipe_build_write_buffer()
> gets an error faulting it in). This doesn't usually cause signals;
> it just confuses vi.
Can you try backing out rev 1.104 of kern/sys_pipe.c?
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII-again
apparently, On Thu, May 30, 2002 at 09:20:57AM -0700,
Julian Elischer said words to the effect of;
>
>
> ok, but does anyone other than john (who has commented) have any comments
> about the logic and work in the change?
>
> I'm working on his comments but comments by others would sure be
> appreciated..
> especially if they actually comment on what I'm trying to do..
>
> If I can get the changes for the other architectures done,
> I'd like to commit this weekend. HOPEFULLY it shouldn't
> affect normal operations but of course the testing done by two people
> can't hope to equal that which will be done in teh first 24 hours
> once it's committed :-)
>
> once again:
>
> the diffs are at:
> http://people.freebsd.org/~peter/kse.diff
> and
> http://people.freebsd.org/~julian/thediff
> and the diffs I need for other architectures are versions of:
>
> sys/i386/i386/genassym.c (small)
> sys/i386/i386/machdep.c (1 line)
> sys/i386/i386/swtch.s (a few lines)
> sys/i386/i386/trap.c (small)
> sys/i386/i386/vm_machdep.c (largly new functions, we could stub them)
> sys/i386/include/kse.h (new file)
> sys/i386/linux/linux_machdep.c (one line)
>
> Largely these need to be written by someone who is intimately aquainted
> with the register set of the machine in question and knows
> what registers need to be saved to restore a user context correctly.
>
> Index: bin/ksetest/Makefile
> ===
> Index: bin/ksetest/kse_asm.S
> ===
> Index: bin/ksetest/kse_threads_test.c
> ===
I don't know if you intended to commit this test program as well.
Please do not.
> Index: sys/i386/i386/trap.c
> ===
> @@ -942,6 +948,23 @@
> td->td_frame = &frame;
> if (td->td_ucred != p->p_ucred)
> cred_update_thread(td);
> + if (p->p_flag & P_KSES) {
> + /*
> + * If we are doing a syscall in a KSE environment,
> + * note where our mailbox is. There is always the
> + * possibility that we could do this lazily (in sleep()),
> + * but for now do it every time.
> + */
> + error = copyin((caddr_t)td->td_kse->ke_mailbox +
> + offsetof(struct kse_mailbox, current_thread),
> + &td->td_mailbox, sizeof(void *));
> + if (error || td->td_mailbox == NULL) {
> + td->td_mailbox = NULL; /* single thread it.. */
> + td->td_flags &= ~TDF_UNBOUND;
> + } else {
> + td->td_flags |= TDF_UNBOUND;
> + }
> + }
> params = (caddr_t)frame.tf_esp + sizeof(int);
The places where you access user space to setup the linkage for the
UTS should use fuword and suword instead of copyin and copyout, its
faster and it makes the code clearer.
> Index: sys/i386/i386/vm_machdep.c
> ===
> --- sys/i386/i386/vm_machdep.c2002/05/29 07:21:58 #21
> +++ sys/i386/i386/vm_machdep.c2002/05/29 07:21:58
> @@ -283,6 +293,145 @@
> }
>
> void
> +cpu_thread_setup(struct thread *td)
> +{
> +
> + td->td_pcb =
> + (struct pcb *)(td->td_kstack + KSTACK_PAGES * PAGE_SIZE) - 1;
> + td->td_frame = (struct trapframe *)((caddr_t)td->td_pcb - 16) - 1;
> +}
> +
> +struct md_store {
> + struct pcb mds_pcb;
> + struct trapframe mds_frame;
> +};
> +
> +void
> +cpu_save_upcall(struct thread *td, struct kse *newkse)
> +{
> +
> + /* Point the pcb to the top of the stack. */
> + newkse->ke_mdstorage = malloc(sizeof(struct md_store), M_TEMP,
> + M_WAITOK);
> + /* Note: use of M_WAITOK means it won't fail. */
> + newkse->ke_pcb =
> + &(((struct md_store *)(newkse->ke_mdstorage))->mds_pcb);
> + newkse->ke_frame =
> + &(((struct md_store *)(newkse->ke_mdstorage))->mds_frame);
> +
> + /* Copy the upcall pcb. Kernel mode & fp regs are here. */
> + bcopy(td->td_pcb, newkse->ke_pcb, sizeof(struct pcb));
> +
> + /* This copies most of the user mode register values. */
> + bcopy(td->td_frame, newkse->ke_frame, sizeof(struct trapframe));
> +}
ke_frame, ke_pcb and ke_mdstorage should all be in a machine dependent
struct mdkse, like mdproc. The fact that the storage is large enough
to warrant using malloc is machine dependent, so it should not be a
pointer. I would be inclined to just embed a trapframe.
The pcb should not be needed at all here; all of the meaningful kernel
mode register values are set below. Capturing the whole execution
context at the time of the kse_new call (floating point registers,
debug registers) may be expensive and I don't think is worth doing.
The whole trick of a system
Re: Seeking OK to commit KSE MIII-again
Apparently, On Thu, May 30, 2002 at 06:56:30PM -0700,
Julian Elischer said words to the effect of;
> > > + /* Note: use of M_WAITOK means it won't fail. */
> > > + newkse->ke_pcb =
> > > + &(((struct md_store *)(newkse->ke_mdstorage))->mds_pcb);
> > > + newkse->ke_frame =
> > > + &(((struct md_store *)(newkse->ke_mdstorage))->mds_frame);
> > > +
> > > + /* Copy the upcall pcb. Kernel mode & fp regs are here. */
> > > + bcopy(td->td_pcb, newkse->ke_pcb, sizeof(struct pcb));
> > > +
> > > + /* This copies most of the user mode register values. */
> > > + bcopy(td->td_frame, newkse->ke_frame, sizeof(struct trapframe));
> > > +}
> >
> > ke_frame, ke_pcb and ke_mdstorage should all be in a machine dependent
> > struct mdkse, like mdproc. The fact that the storage is large enough
> > to warrant using malloc is machine dependent, so it should not be a
> > pointer. I would be inclined to just embed a trapframe.
>
> e... ke_mdstorage is just a pointer to the mdstorage
> as are the others.. I don't want to include an md structure into
> the KSE.. it's big enough as it is.. Every process has a KSE
> but only KSE-mode processes have the extra mdstorage area.
>
> Do you feel strongly about this?
I do. The point is that if its a struct you can do what ever you want;
just put the pointers in it.
struct mdkse {
void *md_store;
struct trapframe *md_frame;
struct pcb *md_pcb;
};
I think that the upcall state should not need to be more than 3 or 4
pointers saved in the kernel, with no extra malloced stuff.
>
> >
> > The pcb should not be needed at all here; all of the meaningful kernel
> > mode register values are set below. Capturing the whole execution
> > context at the time of the kse_new call (floating point registers,
> > debug registers) may be expensive and I don't think is worth doing.
>
> Yes I started out with the PCB there but as I went I found I was needing
> less and less of it. I even have a comment to that effect somewhere..
> At this stage I still have it only because I wanted to make sure that
> I had good defaults for anything that I wasn't sure about..
Well, the defaults are documented in the hardware documentation for
a given platform... Saving the whole pcb is not always practical,
it may be huge.
>
> Also I haven't figured out what to do about FP registers
> and I may want to stuff them there at some stage...
> (not sure yet)
>
> >
> > The whole trick of a system call that returns multiple times is
> > dubious. The fact that it works at all is machine dependent; for
> > sparc64 it needs wierd hacks in the kernel like is done for vfork.
> > It would be better to just register an upcall stack and entry point
> > with the kernel, like how signals work. This would make mdkse even
> > smaller.
>
> It's effectively the same thing..
> except it allows the function to have persistent state in all it's
> local variables and arguments. Which is REALLY useful in the UTS.
> As for hacks.. we have the code in vfork, no?
> :-)
> (actually the code actually uses fork_return() to do the returns so if
> your hack is in there we get it for free.)
The hack is in cpu_fork. The problem is that in order to save the call
safe registers, on entry to the kernel the kernel pushes a frame onto the
_user_ stack. This saves the call safe registers that are active at the
time of the call to the kse_new asm stub in libc. When the system call
returns the frame is popped off again and the registers are restored
(again by the kernel, not the user code). However, the stack space used
to save the frame is now below the stack pointer, and will be clobbered by
interrupts, page faults, or function calls. So the next time the kse_new
call returns, the frame that was saved on the original call has been
overwritten by normal stack usage, and the call safe registers at the
time of the orignal call have been clobbered (the memory that they were
saved in that is).
Some background: obviously the kernel has to be really careful when storing
to the user stack on entry to the kernel. If that part of the stack is not
mapped, or if the stack pointer is corrupted, it can trigger a page fault or
an alignment fault. These are detected very early (before calling C code,
because we haven't even switched to the kernel stack yet), and the register
window is written to the pcb, which will be copied out again on return from
the kernel so everything looks normal.
What we do for vfork is copy the frame from the user stack into the parent's
pcb, and arrange for it to be copied out when the child exits, restoring the
volatile part of the stack. This means that we need a pcb to save the frame
in, as well as the trapframe. The pcb is huge on sparc64, as much as 5K to
6K, depending on the number of windows supported by the cpu. So we'd have
to copy almost a full page of memory for every upcall, whereas if they use
a signal style trampoline, all you need is a stack and pc, and some arg
Re: Seeking OK to commit KSE MIII-again
Apparently, On Fri, May 31, 2002 at 01:45:50PM -0700, Julian Elischer said words to the effect of; > > > On Fri, 31 May 2002, Jake Burkholder wrote: > > [aweful stuff] > (always did dislike sparc) Whatever. It's the most fun architecture I've found to program for. > > jake.. > can you show me the sequecne of operations performed on the stack > in a syscall before and after the jump to kernel space? > The system call stubs in libc are leaf functions; basically just a trap instruction followed by a return. They do not touch the stack at all, or change the stack pointer. One of the first few instructions on entry to the kernel is a save, which rotates the register window and logically saves the call-safe registers onto the user stack (the outs become the ins, and the kernel gets new ins and locals, with the old ones being saved to the user stack once a flush is performed or they get spilled out). Here is a reference: http://www.sparc.com/standards/v9.ps.Z Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seeking OK to commit KSE MIII-again
Apparently, On Fri, May 31, 2002 at 05:49:59PM -0700, Julian Elischer said words to the effect of; > interesting but not exactly brief.. :-) > > > On Fri, 31 May 2002, Jake Burkholder wrote: > > > > > The system call stubs in libc are leaf functions; basically just a > > trap instruction followed by a return. They do not touch the stack > > at all, or change the stack pointer. One of the first few instructions > > on entry to the kernel is a save, which rotates the register window > > and logically saves the call-safe registers onto the user stack > > (the outs become the ins, and the kernel gets new ins and locals, > > with the old ones being saved to the user stack once a flush is > > performed or they get spilled out). > > the question is "when does it switch to the kernel stack?" > (and back?) This is not done by the hardware. Its done by the trap code after the save is executed. > > > > > > Here is a reference: http://www.sparc.com/standards/v9.ps.Z > > downloaded... 300+ pages.. hmm. > > > > > > Jake > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
