Re: XFree86-4-libraries build error
Peter Schultz [EMAIL PROTECTED] writes: Amazing, the obvious. Now I get this: Hmm, I didn't get any more trouble after I fixed the pragma problem. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] 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
On Thu, 30 May 2002, Peter Wemm wrote: Julian Elischer wrote: On Thu, 30 May 2002, Jake Burkholder wrote: [..] It is much more difficult to ensure that all the register values end up the same on each return from the system call on sparc64, due to the way that register stack works. The current test program will not work at all, because setjmp, longjmp cannot be used to switch the stack in the same way. The library will not be using setjmp and longjmp in this way but instead the setcontext() call that dan wrote for the current thread library. If that works it should be enough. (I'd like to investigate your comments though... can you explain more about why it's a problem? It sure simplifies things on most architectures I've done this on.. setjmp/longjmp cannot be used to switch stacks on ia64 either, for what it's worth. This is why libc_r is disabled for ia64 (and I presume sparc64). I don't really care if setjmp doesn't work, as long as there is some assembler that can be put in the library that can switch a stack/thread. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote: Can we get rid of the NULL tests we had to put in when M_WAIT turned into M_WAITOK? No. What you see as a bad thing others (including me) see as a good thing. I _want_ to be able to say: okay, try sleeping; but I realize that sleeping for longer than some reasonable time if I'm not getting anything to begin with will probably not get me anything at any point so tell me the allocation really failed and give me the opportunity to clean up before *I* decide what I want to do. -- Terry Never solve a vast problem in a half-vast way -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On Wed, May 29, 2002 at 12:20:20AM -0700, Peter Wemm wrote: M_WAIT for mbufs (not malloc) was an alias for M_WAITOK, and M_DONTWAIT (also just for mbufs) was an alias for M_NOWAIT. You call things and either permit them to tsleep() or you do not. M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means you must not tsleep!. M_WAITOK conversely means that tsleep should be called as needed. Things like malloc still can return NULL even with M_WAITOK for non-recoverable scenarios. Exactly, with one exception: they are no longer aliases. I had renamed (after some discussion) M_WAIT and M_DONTWAIT in the mbuf code to M_TRYWAIT and M_DONTWAIT, respectively, to avoid confusion and avoid mixing the flags with the malloc() flags. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On Wed, May 29, 2002 at 01:04:00PM -0700, Terry Lambert wrote: Bosko Milekic wrote: On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote: Can we get rid of the NULL tests we had to put in when M_WAIT turned into M_WAITOK? No. What you see as a bad thing others (including me) see as a good thing. I _want_ to be able to say: okay, try sleeping; but I realize that sleeping for longer than some reasonable time if I'm not getting anything to begin with will probably not get me anything at any point so tell me the allocation really failed and give me the opportunity to clean up before *I* decide what I want to do. Up the operating system's wazoo! *We* are the programmers. *We* know better than *it* whether it's OK to sleep indefinitely or not. If *we* want the allocation to fail after *some reasonable time*, then *we will damn well set a timer to some reasonable time* to indicate that fact to the OS. If *we* do *not* damn well set a timer, then *we* damn well do not want it to fail, *we* want it to hang either *until it succeeds* or *until hell freezes over* or *until we manually enter the kernel debugger to find out why it is hanging*. Then *you* can set *your* timer to hang to infinity. *I* have provided *the* ability to do *that*: tesla# sysctl -A | grep mbuf_wait kern.ipc.mbuf_wait: 32 tesla# sysctl -w kern.ipc.mbuf_wait=0 (Now the mbuf code will behave in such a way that it will hang forever if you call with M_TRYWAIT and cannot allocate anything). However, *I* want to be able to do otherwise, because *I* don't agree with *you*. So *I* will leave my timer to whatever the hell I please and *I* will require callers to check for NULL in all cases, and handle the failure appropriately, because that's what good systems do. If for my particular chunk of code or subsystem, properly means call panic(), then so be it. But if for my particular subsystem it happens to be *SOMETHING OTHER THAN CALLING panic()*, I want to be able to catch that failure and handle it after the wait has timed out. If there is code that still uses M_TRYWAIT with the mbuf allocator and does not check for NULL (I believe there is still some of this), well, then, it will simply page fault immediately after it tries dereferencing the NULL pointer and I'll figure it right out. All these people are bitching about kludging around something by changing M_WAITOK to M_NOWAIT. The kludge is *already there* in M_WAITOK, whether you want it or not. So bitching about this kluge is meaningless: changing it back to M_WAITOK won't make the little F'er go away, it will just *hide* the kludge from people to lazy to read the code all the way down, and know *why* they have to check for a NULL return from a call that's *supposed to wait* until it's return will *not* be NULL. -- Terry -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On Tue, May 28, 2002 at 11:36:23PM -0700, Terry Lambert wrote: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Peter Wemm writes: As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if you like. ie: it is a time bomb waiting for the right low memory condition which will then explode with a 100% authentic crash or lock up. Pretend it said M_SLEEPOK instead of M_WAITOK. Uhm, I'm actually seeing the opposite behaviour as well: after I changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc sleeping... I'm with Poul on this one, Peter: M_WAITOK doesn't mean what you think it means: it's doesn't mean tsleep may be called, and M_NOWAIT doesn't mean tsleep() _won't_ be called, in practice. With the same amount of time you spent typing up this Email, you could have checked the code and seen that M_WAITOK _does_ mean that tsleep may be called and that, in effect, M_NOWAIT means that tsleep will not be called. If we have cases where tsleep is called and are M_NOWAIT, then that's not good. M_NOWAIT means: only allowed to block on a mutex. It's either incredibly badly named, or it's incredibly badly implemented -- I would argue the latter, actually, since even if it's completely orthogonal, you're screwed because it means you have two call conversion systems, without a WITNESS intersection to detect deadly embraces. 8-(. -- Terry -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] 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
Peter Wemm [EMAIL PROTECTED] writes: If you want final commit approval/objections, you really need to either include or go to developers@ instead since they're the ones dealing with actual commit process. s/developers/arch/ DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] 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
Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: If you want final commit approval/objections, you really need to either include or go to developers@ instead since they're the ones dealing with actual commit process. s/developers/arch/ I wasn't clear with this comment. As I said elsewhere when somebody else asked: == If he's looking for comments on the changes or reviews, he should go to arch@ as that isn't really current@ material. If he's looking for volunteers to pre-test it, then he should be asking for testers on current@. But he said he was asking for permission to commit it (Seeking OK to commit KSE MIII-again), so he should be talking with other committers. current@ is not particularly well tracked by committers themselves due to relatively low signal to noise. At the very least, you have to tell committers@ that you've posted about it elsewhere if you want it to be seen. == Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII-again
Peter Wemm [EMAIL PROTECTED] writes: But he said he was asking for permission to commit it (Seeking OK to commit KSE MIII-again), so he should be talking with other committers. I guess I just don't see why he needs our permission, as long as he's given us a chance to comment on the technical aspects of the patch. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
Bosko Milekic wrote: Then *you* can set *your* timer to hang to infinity. *I* have provided *the* ability to do *that*: tesla# sysctl -A | grep mbuf_wait kern.ipc.mbuf_wait: 32 tesla# sysctl -w kern.ipc.mbuf_wait=0 (Now the mbuf code will behave in such a way that it will hang forever if you call with M_TRYWAIT and cannot allocate anything). However, *I* want to be able to do otherwise, because *I* don't agree with *you*. So *I* will leave my timer to whatever the hell I please and *I* will require callers to check for NULL in all cases, and handle the failure appropriately, because that's what good systems do. If for my particular chunk of code or subsystem, properly means call panic(), then so be it. But if for my particular subsystem it happens to be *SOMETHING OTHER THAN CALLING panic()*, I want to be able to catch that failure and handle it after the wait has timed out. I'm OK with trapping conditions differently. But I think an explicit timer allows for that. I really dislike having different rules for mbuf allocation vs. other allocations. I don't like that options have changed from: o Fail rather than waiting, if you would have to wait o If you have to wait, then wait until you will not fail To: o Fail rather than waiting, if you would have to wait o If you have to wait, then wait until you will not fail, but fail if you know that waiting will do no good I don't mind the new option (which is effectively TRYWAIT), but I dislike losing the old option. I know you worked a long time on the mbuf allocator. There was, at one time, an intention to move to a new allocator architecture for everything, based on your work, where your work was advertised as a proof of concept (this advertising kept many people from complaining too loudly, at the time, since it wasn't a commitment). Then the slab allocator work came in, and while it has statistics locks and some other locks I'd rather it didn't have (since the idea was to divide up the flow to prevent needing locking, and we ended up locking anyway), it seems to fill the same ecological niche that the work based on your proof of concept work would have been filling. Personally, I use my own mbuf allocator on physical memory that was reserved at boot time, so that it has incredibly lower overhead than either the allocator before your work, the allocator after it, or the slab allocator. I don't expect that it's generally useful (most of you people are not building FreeBSD-based networking hardware, so that approach would not be useful to you, anyway). But that fact that the proof of concept was limited to an area where I didn't have to use the code at all, also contributed to my personal lack of loud objection to the code. -- Bottom line? I'd like to see one set of uniform semantics. It really disturbs me that the behaviour of a common flag changes for some code, because of a sysctl, but doesn't change for all code using the flag. I'd also like to see one set of code, if it can be negotiated between you and the SLAB allocator guy. N allocators is usually N-1 too many, IMO. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: zsh exits upon ^C after su'ing to root with zsh as its shell
Alexander Kabaev [EMAIL PROTECTED] writes: Revision 1.51 of su.c fixes the bug. No it doesn't. You're right, it doesn't work and I don't have time to go groveling through the kernel to figure out why. Please back out 1.51 and commit your own patch instead. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
what happened to softintr?
A GENERIC kernel on current fails to compile missing softintr. # beast:/sys/i386/compile/GENERIC # make -DNO_MODULES -DNO_WERROR cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/ncv/ncr53c500.c ../../../dev/ncv/ncr53c500.c: In function `ncv_world_start': ../../../dev/ncv/ncr53c500.c:503: warning: implicit declaration of function `softintr' cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/nsp/nsp.c ../../../dev/nsp/nsp.c: In function `nsp_world_start': ../../../dev/nsp/nsp.c:495: warning: implicit declaration of function `softintr' cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/stg/tmc18c30.c ../../../dev/stg/tmc18c30.c: In function `stg_world_start': ../../../dev/stg/tmc18c30.c:377: warning: implicit declaration of function `softintr' sh ../../../conf/newvers.sh GENERIC cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding vers.c linking kernel.debug ncr53c500.o: In function `ncv_world_start': ../../../dev/ncv/ncr53c500.c:503: undefined reference to `softintr' nsp.o: In function `nsp_world_start': ../../../dev/nsp/nsp.c:495: undefined reference to `softintr' tmc18c30.o: In function `stg_world_start': ../../../dev/stg/tmc18c30.c:377: undefined reference to `softintr' *** Error code 1 Stop in /usr/src/sys/i386/compile/GENERIC. # John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] 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
On Thu, May 30, 2002 at 09:14:33PM +0200, Bernd Walter wrote:
On Thu, May 30, 2002 at 09:20:57AM -0700, Julian Elischer wrote:
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.
I can do the alpha part tomorrow unless someone else already startet.
There are problems with the patchset:
../../../kern/kern_proc.c: In function `fill_kinfo_proc':
../../../kern/kern_proc.c:731: `TDS_RUN' undeclared (first use in this function)
../../../kern/kern_proc.c:731: (Each undeclared identifier is reported only once
../../../kern/kern_proc.c:731: for each function it appears in.)
../../../kern/kern_proc.c:733: `SRUN' undeclared (first use in this function)
../../../kern/kern_proc.c:734: `TDS_SLEEP' undeclared (first use in this function)
../../../kern/kern_proc.c:735: `SSLEEP' undeclared (first use in this function)
../../../kern/kern_proc.c:737: `SSTOP' undeclared (first use in this function)
../../../kern/kern_proc.c:739: `SMTX' undeclared (first use in this function)
../../../kern/kern_proc.c:741: `SWAIT' undeclared (first use in this function)
../../../kern/kern_proc.c:743: syntax error before '{' token
../../../kern/kern_proc.c:744: `SZOMB' undeclared (first use in this function)
../../../kern/kern_proc.c:745: syntax error before else
../../../kern/kern_proc.c:663: warning: unused variable `tp'
../../../kern/kern_proc.c:664: warning: unused variable `sp'
../../../kern/kern_proc.c:665: warning: unused variable `tv'
[...]
Line 731 should be TDS_RUNQ I guess.
TDS_SLEEP - where is it defined - intended to be TDS_SLP?
SRUN, SSLEEP and others:
+#ifndef _KERNEL /* Only usable by libkvm for legacy apps */
+#define SIDL 1 /* Process being created by fork. */
+#define SRUN 2 /* Currently runnable. */
+#define SSLEEP 3 /* Sleeping on an address. */
+#define SSTOP 4 /* Process debugging or suspension. */
+#define SZOMB 5 /* Awaiting collection by parent. */
+#define SWAIT 6 /* Waiting for interrupt. */
+#define SMTX 7 /* Blocked on a mutex. */
+#endif
Why are they (newly) used in kern_proc.c?
IMO they need to be changed to TDS_SLP, ...
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On Fri, May 31, 2002 at 02:02:27AM -0700, Terry Lambert wrote: [...] Bottom line? I'd like to see one set of uniform semantics. It really disturbs me that the behaviour of a common flag changes for some code, because of a sysctl, but doesn't change for all code using the flag. I'd also like to see one set of code, if it can be negotiated between you and the SLAB allocator guy. N allocators is usually N-1 too many, IMO. Yes, it was my intention to co-ordinate with JeffR and perhaps in a year from now (once UMA really stabilizes and I get the current backlog in my TODO well, out of the backlog) to take a stab at having the mbuf code use uma for allocations. This is why I delayed any further design work in mb_alloc for the moment. I agree that having fewer allocators is a Good Thing and have considered this with the Good of the Project in mind (as opposed to personal issues, ego, or whatever). :-) In any case, when the time comes to really tackle the issue, we will have to be very very careful. mb_alloc was written in such a way that mbuf allocations are optimized out and that for all common-case allocations, ONE function call is performed for the allocation, not more. I remember initially getting a very hard time from you and the lists on keeping the performance numbers up for mbuf allocations (we are known for having very fast mbuf allocation) and I also recall many nights of performance measurement and data gathering. My observation was that: 1) Getting rid of the large macros and moving to mb_alloc, even with Giant in place, slightly improved overall speed (I still have the data, actually: http://www.freebsd.org/~bmilekic/code/mb_alloc/results.html ) This is particularly the case for i386, where the negative cache effects of those large allocation/free macros was really noticable. 2) Increasing the common-case for allocations and frees to more than one single function call resulted in a noticable [albeit slight] slowdown, in the alpha in particular (unfortunately, something happened with jlemon's alpha stats so the graphs are no longer accessible). This is why I worked hard to place the allocation code in such a way to keep it at at most one function call for the common case. I'd like to maintain this assumption when/if we move to uma in the future. -- Terry Cheers, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
file://localhost/usr/share/doc/en_US.ISO8859-1/books/handbook/current
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current as guest of VMWare2
I'm running windows XP and vmware 3.1.1 with a guest os of FreeBSD 4.5 which I'm going to upgrade to -current. I couldn't find too much info on this thread. Does anyone know if vmware3 is affected by this problem when using a windows host os? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current as guest of VMWare2
On Fri, May 31, 2002 at 10:54:54AM -0500, David W. Chapman Jr. wrote: I'm running windows XP and vmware 3.1.1 with a guest os of FreeBSD 4.5 which I'm going to upgrade to -current. I couldn't find too much info on this thread. Does anyone know if vmware3 is affected by this problem when using a windows host os? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org As I mentionned several times now in this thread, I am running VMWare 3.1.1 with a host OS being Windows2000 and a guest OS, -CURRENT. I am doing this on my laptop so that I can trick -CURRENT into playing with my PCMCIA network card that is not supported but that works when used through VMWare due to VMWare emulating a LANCE type (lnc) card. Here are the issue I ran into with -CURRENT as guest, and what I've done to solve them so far: 1) Issue: -CURRENT installation boots, kernel boots, sysinstall starts, but newfs-ing on partitions is EXTREMELY slow. Solution: Don't use the VMware 'virtual disk' thing backed with a file on the host OS. Instead, create a separate partition for FreeBSD and install there. Disk access is quite a bit faster. 2) Issue: sysinstall now can newfs easily/quickly, it starts the install on / first, but eventually slows down to a crawl (the rate sinks to something ridiculous, like 0.5K/s. Solution: Haven't figured it out yet. My plan is to: (i) Re-install -CURRENT snap in the separate partition but not through VMWare (i.e. do it the normal way). (ii) Boot -CURRENT normally (iii) Rebuild kernel without cmpxchg instruction (cpu I386_CPU, or whatever the name of that option was). (iv) Boot host OS windows2000, start VMWare, and try booting the installed -CURRENT with the new cmpxchg-free kernel via VMWare. I hope this at least improves the speed situation. -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
On Thu, May 30, 2002 at 12:30:43AM -0700, Alfred Perlstein wrote: alfred 2002/05/30 00:30:43 PDT Modified files: sys/dev/ct ct_machdep.h sys/dev/ncv ncr53c500var.h sys/dev/stg tmc18c30var.h Log: Check for defined(__i386__) instead of just defined(i386) since the compiler will be updated to only define(__i386__) for ANSI cleanliness. Revision ChangesPath 1.4 +3 -3 src/sys/dev/ct/ct_machdep.h 1.7 +3 -3 src/sys/dev/ncv/ncr53c500var.h 1.6 +3 -3 src/sys/dev/stg/tmc18c30var.h On Fri, May 31, 2002 at 02:02:50PM +0200, John Hay wrote: A GENERIC kernel on current fails to compile missing softintr. # beast:/sys/i386/compile/GENERIC # make -DNO_MODULES -DNO_WERROR cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/ncv/ncr53c500.c ../../../dev/ncv/ncr53c500.c: In function `ncv_world_start': ../../../dev/ncv/ncr53c500.c:503: warning: implicit declaration of function `softintr' cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/nsp/nsp.c ../../../dev/nsp/nsp.c: In function `nsp_world_start': ../../../dev/nsp/nsp.c:495: warning: implicit declaration of function `softintr' cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding ../../../dev/stg/tmc18c30.c ../../../dev/stg/tmc18c30.c: In function `stg_world_start': ../../../dev/stg/tmc18c30.c:377: warning: implicit declaration of function `softintr' sh ../../../conf/newvers.sh GENERIC cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding vers.c linking kernel.debug ncr53c500.o: In function `ncv_world_start': ../../../dev/ncv/ncr53c500.c:503: undefined reference to `softintr' nsp.o: In function `nsp_world_start': ../../../dev/nsp/nsp.c:495: undefined reference to `softintr' tmc18c30.o: In function `stg_world_start': ../../../dev/stg/tmc18c30.c:377: undefined reference to `softintr' *** Error code 1 Stop in /usr/src/sys/i386/compile/GENERIC. # John Alfred, Your changes above broke building the GENERIC kernel. __i386__ is always defined (whether -ansi or not), and this now causes SOFT_INTR_REQUIRED() macro to use non-existing softintr(). (Well, it's defined as empty in sys/i386/isa/bs/bsif.h.) I'm not sure what would me more correct; to include the definition of softintr() from bsif.h, or to just commit the following: %%% Index: ct/ct.c === RCS file: /home/ncvs/src/sys/dev/ct/ct.c,v retrieving revision 1.5 diff -u -p -r1.5 ct.c --- ct/ct.c 20 Mar 2002 02:04:09 - 1.5 +++ ct/ct.c 31 May 2002 16:02:22 - @@ -505,7 +505,6 @@ ct_world_start(ct, fdone) scsi_low_bus_reset(slp); cthw_chip_reset(chp, NULL, ct-sc_chipclk, slp-sl_hostid); - SOFT_INTR_REQUIRED(slp); return 0; } Index: ct/ct_machdep.h === RCS file: /home/ncvs/src/sys/dev/ct/ct_machdep.h,v retrieving revision 1.4 diff -u -p -r1.4 ct_machdep.h --- ct/ct_machdep.h 30 May 2002 07:30:42 - 1.4 +++ ct/ct_machdep.h 31 May 2002 16:02:22 - @@ -208,9 +208,4 @@ ct_cmdp_write_1(chp, val) CT_BUS_WEIGHT(chp) } -#ifdefined(__i386__) -#defineSOFT_INTR_REQUIRED(slp) (softintr((slp)-sl_irq)) -#else /* !__i386__ */ -#defineSOFT_INTR_REQUIRED(slp) -#endif /* !__i386__ */ #endif /* !_CT_MACHDEP_H_ */ Index: ncv/ncr53c500.c
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
On Fri, May 31, 2002 at 09:34:10AM -0700, Alfred Perlstein wrote: * Ruslan Ermilov [EMAIL PROTECTED] [020531 09:09] wrote: Stop in /usr/src/sys/i386/compile/GENERIC. # John Alfred, Your changes above broke building the GENERIC kernel. __i386__ is always defined (whether -ansi or not), and this now causes SOFT_INTR_REQUIRED() macro to use non-existing softintr(). (Well, it's defined as empty in sys/i386/isa/bs/bsif.h.) I'm not sure what would me more correct; to include the definition of softintr() from bsif.h, or to just commit the following: I'm really fine with either. Let's wait till tomorrow for anyone to speak up, if no one does please feel free to commit whichever one you feel more comfortable with. OK. I also forgot the similar part for dev/nsp: %%% Index: nsp/nsp.c === RCS file: /home/ncvs/src/sys/dev/nsp/nsp.c,v retrieving revision 1.8 diff -u -p -r1.8 nsp.c --- nsp/nsp.c 20 Mar 2002 02:07:34 - 1.8 +++ nsp/nsp.c 31 May 2002 16:39:07 - @@ -492,7 +492,6 @@ nsp_world_start(sc, fdone) nsphw_init(sc); scsi_low_bus_reset(slp); - SOFT_INTR_REQUIRED(slp); return 0; } Index: nsp/nspvar.h === RCS file: /home/ncvs/src/sys/dev/nsp/nspvar.h,v retrieving revision 1.5 diff -u -p -r1.5 nspvar.h --- nsp/nspvar.h20 Mar 2002 02:07:36 - 1.5 +++ nsp/nspvar.h31 May 2002 16:39:07 - @@ -105,9 +105,4 @@ void nspattachsubr(struct nsp_softc *); int nspprint(void *, const char *); int nspintr(void *); -#ifdefined(i386) -#defineSOFT_INTR_REQUIRED(slp) (softintr((slp)-sl_irq)) -#else /* !i386 */ -#defineSOFT_INTR_REQUIRED(slp) -#endif /* !i386 */ #endif /* !_NSPVAR_H_ */ %%% -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg39040/pgp0.pgp Description: PGP signature
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
* Ruslan Ermilov [EMAIL PROTECTED] [020531 09:09] wrote: Stop in /usr/src/sys/i386/compile/GENERIC. # John Alfred, Your changes above broke building the GENERIC kernel. __i386__ is always defined (whether -ansi or not), and this now causes SOFT_INTR_REQUIRED() macro to use non-existing softintr(). (Well, it's defined as empty in sys/i386/isa/bs/bsif.h.) I'm not sure what would me more correct; to include the definition of softintr() from bsif.h, or to just commit the following: I'm really fine with either. Let's wait till tomorrow for anyone to speak up, if no one does please feel free to commit whichever one you feel more comfortable with. -Alfred 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
On Fri, 31 May 2002, Bernd Walter wrote: On Thu, May 30, 2002 at 09:14:33PM +0200, Bernd Walter wrote: There are problems with the patchset: fixed This is code that translates the new states to old states for single threaded processes so that 'ps' and friends can continue to report a sensible result. (I don't want to change 'ps' yet because people will probably want to skip back and forth between new and old kernels while testing) Also it needs a complete rewrite to show multiple threads when they exist. I'd rather 'patch' the current code to work and do the rewrite as a separate item. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncvncr53c500var.h src/sys/dev/stg tmc18c30var.h
In article [EMAIL PROTECTED] Alfred Perlstein [EMAIL PROTECTED] writes: Alfred, Your changes above broke building the GENERIC kernel. __i386__ is always defined (whether -ansi or not), and this now causes SOFT_INTR_REQUIRED() macro to use non-existing softintr(). (Well, it's defined as empty in sys/i386/isa/bs/bsif.h.) I'm not sure what would me more correct; to include the definition of softintr() from bsif.h, or to just commit the following: I'm really fine with either. Let's wait till tomorrow for anyone to speak up, if no one does please feel free to commit whichever one you feel more comfortable with. These drivers are shared with NetBSD/pc98. Please don't make many FreeBSD local changes. I will ask the original author about how to resolve this problem. Please wait a few days. Thanks you. --- TAKAHASHI Yoshihiro THE CENTER for INFORMATION SCIENCE, Kogakuin Univ. 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 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 arguments.
+ union kse_td_ctx {
+ struct {
+ int
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
On Sat, Jun 01, 2002 at 02:10:32AM +0900, Takahashi Yoshihiro wrote: In article [EMAIL PROTECTED] Alfred Perlstein [EMAIL PROTECTED] writes: Alfred, Your changes above broke building the GENERIC kernel. __i386__ is always defined (whether -ansi or not), and this now causes SOFT_INTR_REQUIRED() macro to use non-existing softintr(). (Well, it's defined as empty in sys/i386/isa/bs/bsif.h.) I'm not sure what would me more correct; to include the definition of softintr() from bsif.h, or to just commit the following: I'm really fine with either. Let's wait till tomorrow for anyone to speak up, if no one does please feel free to commit whichever one you feel more comfortable with. These drivers are shared with NetBSD/pc98. Please don't make many FreeBSD local changes. I will ask the original author about how to resolve this problem. Please wait a few days. It would be a good idea to move them under sys/contrib/ then. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg39045/pgp0.pgp Description: PGP signature
Re: -current as guest of VMWare2
You need to apply the patch that was posted sometime ago to -Current to run it successfully as a Guest OS under VMWare 3.x... Glenn G. On Fri, 31 May 2002 10:54:54 -0500, David W. Chapman Jr. [EMAIL PROTECTED] said: I'm running windows XP and vmware 3.1.1 with a guest os of FreeBSD 4.5 which I'm going to upgrade to -current. I couldn't find too much info on this thread. Does anyone know if vmware3 is affected by this problem when using a windows host os? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Glenn Gombert [EMAIL PROTECTED] Never trust any operating system you don't have the source code for -- http://fastmail.fm - No WWW (Wait-Wait-Wait) required 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
Dag-Erling Smorgrav wrote: Peter Wemm [EMAIL PROTECTED] writes: But he said he was asking for permission to commit it (Seeking OK to commit KSE MIII-again), so he should be talking with other committers. I guess I just don't see why he needs our permission, as long as he's given us a chance to comment on the technical aspects of the patch. I didn't say that he does need permission. But he was asking for it. See the subject: Seeking OK to commit KSE MIII-again Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current as guest of VMWare2
On Fri, May 31, 2002 at 04:09:29PM +, Glenn Gombert wrote: You need to apply the patch that was posted sometime ago to -Current to run it successfully as a Guest OS under VMWare 3.x... I tried searching the archives and couldn't find anything with VMware and a patch, just some things mentionning that VMWare has trouble with locking primitives. What does the patch do? Glenn G. -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Make $100,000 a month on eBay! 4976
Hello! Do you sell on Ebay? If so, you could be making up to $100,000 per month? This is no hype and no scam. Recieving over 1.5 billion page views per month, Ebay is the ULTIMATE venue for selling virtually anything and making huge profits with almost no effort. But you have to know what to sell and how to sell. That's where I come in. As a leading expert in internet marketing and the owner of several profitable auction-based businesses, the manual that I have written provides easy to understand and detailed instructions for maximizing your profits with selling strategies that are PROVEN WINNERS. If you've read any other books on Ebay, you know that all of them are designed for the computer idiot and the auction novice. They tell you how to register, how to list an item, how to avoid fraud, etc. This is not the information you need to make millions on Ebay. You need to learn effective SELLING STRATEGIES not read a photocopy of Ebay help files! My manual assumes that you already know your way around Ebay; you don't need any specialized computer knowledge, but you should be familiar with buying and selling on ebay auctions. I'm not going to waste your time teaching you how to register - I'm going to pass on the SECRET SELLING TECHNIQUES that I use each and every day to bring in hundreds of thousands of dollars selling my products on internet auctions. The manual comes as a complete course with the following lessons: Make a Fortune on eBay Make a Fortune on eBay is filled with page after page of vital eBay marketing information. This valuable eBook is terrific for the eBay user to get the right eBay information and have an instant edge over other more experienced eBay Sellers Advanced Selling on eBay Advanced Selling on eBay has more vital information to make their auction a success. This eBook has many topics to ensure that they get the maximum potential from their auctions. Advanced Selling on eBay goes into more detailed information than it's sister eBook Make a Fortune on eBay. 16 eBay Forms 16 eBay Forms is a must. These forms will help them track, analyze and record their auctions. It contains 16 forms with full instructions. This E-Book also contains the forms in printer friendly version, so they can print them for immediate use. Wholesale Sources Wholesale Sources is the final eBook in the eBay Marketing eCourse. It contains wholesale distributors from the United States, Mexico, Hong Kong, Taiwan, Asia and the Philippines. Armed with this eBook your customers will have over 10,000,000 wholesale products at their finger tips.. This manual is designed for individuals looking to form an online business for extra income or as a full-time job making hundreds of thousands of dollars on Ebay. Contained in the manual are WINNING STRATEGIES for selling on Ebay auctions. The manual is not designed for Ebay novices and does not teach the basics such as registering, putting an item online, buying an item, etc. This manual is designed to make Ebay users into successful and wealthy entrepreneurs! Not only will you be able to make THOUSANDS with the information in these eBooks, you will also receive FULL Resellers rights. This is not an affiliate program where you get 20 or 30%... you keep all the money generated from your eCourse sales. You can sell this eCourse as many times as you want for whatever price you choose. There is NO LIMIT on how much you can make from this incredible product! To order the eCourse click on the link below http://pheromone-labs.com/ebay.htm AOL Users click here: a href=http://pheromone-labs.com/ebay.htm; Thank you for your time and I hope to hear from you soon! James Milton President of Phoenix Marketing *** Thank you for being a part of another great offer from Phoenix Marketing. If you feel you don't belong on our opt-in list or would like to remove yourself please send an email to: [EMAIL PROTECTED] and make sure to have REMOVE in the subject line. Thank you. 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
On Fri, 31 May 2002, Jake Burkholder wrote: [aweful stuff] (always did dislike sparc) jake.. can you show me the sequecne of operations performed on the stack in a syscall before and after the jump to kernel space? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
Ruslan Ermilov wrote: On Sat, Jun 01, 2002 at 02:10:32AM +0900, Takahashi Yoshihiro wrote: These drivers are shared with NetBSD/pc98. Please don't make many FreeBSD local changes. I will ask the original author about how to resolve this problem. Please wait a few days. It would be a good idea to move them under sys/contrib/ then. Better do the same for NFS and other code shared with NetBSD, then... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current as guest of VMWare2
Here is the patch from a previous posting that fixes the problem of
running FreeBSD -Current as a Guest OS under VMWare Workstation 3.0:
Someone mentioned on a list somewhere that vmware takes forever to
emulate the cmpxchg instruction, and that using the I386_CPU version
of atomic_cmpset_int() helps a lot. I noticed a major vmware slowdown
with -current sometime in September, so I tried avoiding the
cmpxchg's and things got much faster. Below is the patch I use
(using this outside vmware on SMP hardware is a bad idea :-).
Ian
Index: atomic.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/i386/include/atomic.h,v
retrieving revision 1.21
diff -u -r1.21 atomic.h
--- atomic.h2001/10/08 20:58:24 1.21
+++ atomic.h2001/10/09 18:35:25
@@ -111,7 +111,7 @@
* Returns 0 on failure, non-zero on success
*/
-#if defined(I386_CPU)
+#if defined(I386_CPU) || 1
static __inline int
atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
{
Glenn G.
--
Glenn Gombert
[EMAIL PROTECTED]
Never trust any operating system you don't have the source code for
--
http://fastmail.fm - Get back to work
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: -current as guest of VMWare2
HAH! This patch was posted by iedowse in response to one of MY POSTS and
it does EXACTLY what I described in my previous Email, point (2).
PLZ DO NOT BRING MY HOPES UP BY STATING THAT THERE IS ANOTHER PATCH
WHICH DOES SOMETHING DIFFERENT WHEN IT FACT IT DOES WHAT I ALREADY KNOW
I SHOULD DO K PLZ THX. :-)
(I'm just fooling around, thanks for the pointer anyway. :-))
Cheers,
Bosko
On Fri, May 31, 2002 at 10:02:21PM +, Glenn Gombert wrote:
Here is the patch from a previous posting that fixes the problem of
running FreeBSD -Current as a Guest OS under VMWare Workstation 3.0:
Someone mentioned on a list somewhere that vmware takes forever to
emulate the cmpxchg instruction, and that using the I386_CPU version
of atomic_cmpset_int() helps a lot. I noticed a major vmware slowdown
with -current sometime in September, so I tried avoiding the
cmpxchg's and things got much faster. Below is the patch I use
(using this outside vmware on SMP hardware is a bad idea :-).
Ian
Index: atomic.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/i386/include/atomic.h,v
retrieving revision 1.21
diff -u -r1.21 atomic.h
--- atomic.h2001/10/08 20:58:24 1.21
+++ atomic.h2001/10/09 18:35:25
@@ -111,7 +111,7 @@
* Returns 0 on failure, non-zero on success
*/
-#if defined(I386_CPU)
+#if defined(I386_CPU) || 1
static __inline int
atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
{
Glenn G.
--
Glenn Gombert
[EMAIL PROTECTED]
Never trust any operating system you don't have the source code for
--
http://fastmail.fm - Get back to work
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Sony Vaio, LinkSys EC2T 5.0-CURRENT ...
Morning all ... After getting nowhere with the Surecom EP-428X that I picked up, I went out today and grabbed one of the Linksys EC2T, figuring it's on the list of supported devices I found, and I think I'm s close ... First, I'm running a VAIO PCG-Z505S ... I've upgraded to 5.0-CURRENT as of May 21st, mainly due to the Surecom, but figure I'll stay there for the Linksys ... If I run 'pccardd -f /etc/defaults/pccard.conf' from the command line, it comes back that its matched the card, followed by a line that states: 'driver allocation failed for Linksys(...): Inappropriate ioctl for device' According to dmesg, I have: pcic0: Ricoh RL5C475 PCI-Cardbus Bridge irq 9 at device 10.0 on pci0 pcic0: PCI Memory allocated: 0x4400 pccard0: PC Card bus (classic) on pcic0 If I pull out the card, the machine itself hangs ... and searching on Google, it talks about pccard + shared interrupts ... and on this, the internal ethernet (fxp0) is using irq 9 and the USB controller (uhci0) is using irq 9 ... I looked in the pcic man page, and found the references to hw.pcic.irq, which mine is set to 0 ... and hw.pcic.intr_path, which mine is set to 2 ... it talks about being able to switch to ISA interrupt by changing intr_path to 1, which I tried, with an .irq setting of 10 ... still hung, so that wasn't the right direction ... So, I'm pretty much at an impasse right now as to what to try next ... does anyone have an experiences with this combination and/or suggestions on what to try next ... ? Thanks ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
I have a fix for this, btw. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
In message [EMAIL PROTECTED] Alfred Perlstein writes: : I'm really fine with either. Let's wait till tomorrow for anyone to : speak up, if no one does please feel free to commit whichever one you : feel more comfortable with. Aarrgh. I just committed my workaround, which basically adds 0 to each of the tests. I did this as it is the smallest change I could think of to do the deed since these drivers are maintained outside of the tree. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
In message [EMAIL PROTECTED] Ruslan Ermilov writes: : It would be a good idea to move them under sys/contrib/ then. I'm not so sure about that. I think they are fine where they are. There are many drivers in the tree that are synced between platforms. Also, right now other than acpi, the only things under contrib/dev are binary only drivers. But I don't feel too strongly about this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncv ncr53c500var.h src/sys/dev/stg tmc18c30var.h
* Warner Losh [EMAIL PROTECTED] [020531 16:39] wrote: In message [EMAIL PROTECTED] Alfred Perlstein writes: : I'm really fine with either. Let's wait till tomorrow for anyone to : speak up, if no one does please feel free to commit whichever one you : feel more comfortable with. Aarrgh. I just committed my workaround, which basically adds 0 to each of the tests. I did this as it is the smallest change I could think of to do the deed since these drivers are maintained outside of the tree. This is fine. I don't have strong feelings about it and I'm glad to see it fixed either way. :) -- -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/ct ct_machdep.h src/sys/dev/ncvncr53c500var.h src/sys/dev/stg tmc18c30var.h
From: Warner Losh [EMAIL PROTECTED] Date: Fri, 31 May 2002 17:39:55 -0600 In message [EMAIL PROTECTED] Alfred Perlstein writes: : I'm really fine with either. Let's wait till tomorrow for anyone to : speak up, if no one does please feel free to commit whichever one you : feel more comfortable with. Aarrgh. I just committed my workaround, which basically adds 0 to each of the tests. I did this as it is the smallest change I could think of to do the deed since these drivers are maintained outside of the tree. Thank you Waner-san and Takahashi(nyan)-san. I did not notice. May be it should be #ifdef NetBSD or something. // Noriaki Mitsunaga // 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 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
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?) 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
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
Re: Seeking OK to commit KSE MIII-again
On Fri, 31 May 2002, Jake Burkholder wrote: 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. so if the software did it in the opposite order, you'd save to the kernel stack? (I doubt it but I have to ask..) 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Call for Review: allow sysinstall to tweak tri-valuesendmail_enable
Here is a patch to enable sysinstall to set 'sendmail_enable' value to
'YES', 'NO', and 'NONE'. Current sysinstall can't set this value to
'NONE'; users who do *not* want to use sendmail can't stop sendmail
via sysinstall.
Following patch creates submenu to change the sendmail_enable value.
However, I don't know who want to set this variable to 'NO'. If
selecting 'YES' and 'NONE' is enough, I'll try to make another patch.
Any comments? I want to push this feature to 4.6-RELEASE...
-- -
Makoto `MAR' Matsushita
Index: menus.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v
retrieving revision 1.343
diff -u -r1.343 menus.c
--- menus.c 20 May 2002 17:08:00 - 1.343
+++ menus.c 31 May 2002 17:49:18 -
@@ -1372,11 +1372,31 @@
{ Rwhod, This machine wants to run the rwho daemon,
dmenuVarCheck, dmenuToggleVariable, NULL, rwhod_enable=YES },
{ Sendmail, This machine wants to run the sendmail daemon,
- dmenuVarCheck, dmenuToggleVariable, NULL, sendmail_enable=YES },
+ NULL, dmenuSubmenu, NULL, MenuSendmail },
{ Sshd, This machine wants to run the ssh daemon,
dmenuVarCheck, dmenuToggleVariable, NULL, sshd_enable=YES },
{ TCP Extensions, Allow RFC1323 and RFC1644 TCP extensions?,
dmenuVarCheck, dmenuToggleVariable, NULL, tcp_extensions=YES },
+ { NULL } },
+};
+
+DMenu MenuSendmail = {
+DMENU_NORMAL_TYPE | DMENU_SELECTION_RETURNS,
+Sendmail Invocation Selection,
+There are three options for invocating sendmail at startup.\n
+Please select Yes if you want to use sendmail as your mail transfer\n
+agent. Selecting No disables sendmail to open network socket for\n
+incoming email, but still runs at startup. None disables sendmail\n
+completely at startup.,
+NULL,
+NULL,
+{
+ { Yes,Start sendmail,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=YES },
+ { No, Start sendmail, but don't listen from network,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NO },
+ { None, Don't start any sendmail processes,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NONE },
{ NULL } },
};
Index: sysinstall.h
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v
retrieving revision 1.227
diff -u -r1.227 sysinstall.h
--- sysinstall.h31 May 2002 13:38:17 - 1.227
+++ sysinstall.h31 May 2002 17:49:19 -
@@ -407,6 +407,7 @@
extern DMenu MenuSysconsScrnmap; /* System console screenmap
configuration menu */
extern DMenuMenuSysconsTtys;/* System console terminal type menu
*/
extern DMenu MenuNetworking; /* Network configuration menu
*/
+extern DMenu MenuSendmail; /* Sendmail configuration menu
+ */
extern DMenu MenuInstallCustom; /* Custom Installation menu
*/
extern DMenu MenuDistributions; /* Distribution menu
*/
extern DMenu MenuDiskDevices;/* Disk type devices
*/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Call for Review: allow sysinstall to tweak tri-value sendmail_enable
If memory serves me right, Makoto Matsushita wrote:
Following patch creates submenu to change the sendmail_enable value.
However, I don't know who want to set this variable to 'NO'. If
selecting 'YES' and 'NONE' is enough, I'll try to make another patch.
Any comments? I want to push this feature to 4.6-RELEASE...
Comments on the text only (i.e. I haven't tested the new menus)...
Bruce.
Index: menus.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v
retrieving revision 1.343
diff -u -r1.343 menus.c
--- menus.c 20 May 2002 17:08:00 - 1.343
+++ menus.c 31 May 2002 17:49:18 -
@@ -1372,11 +1372,31 @@
{ Rwhod,This machine wants to run the rwho daemon,
dmenuVarCheck, dmenuToggleVariable, NULL, rwhod_enable=YES },
{ Sendmail, This machine wants to run the sendmail daemon,
- dmenuVarCheck, dmenuToggleVariable, NULL, sendmail_enable=YES },
+ NULL, dmenuSubmenu, NULL, MenuSendmail },
{ Sshd, This machine wants to run the ssh daemon,
dmenuVarCheck, dmenuToggleVariable, NULL, sshd_enable=YES },
{ TCP Extensions, Allow RFC1323 and RFC1644 TCP extensions?,
dmenuVarCheck, dmenuToggleVariable, NULL, tcp_extensions=YES },
+ { NULL } },
+};
+
+DMenu MenuSendmail = {
+DMENU_NORMAL_TYPE | DMENU_SELECTION_RETURNS,
+Sendmail Invocation Selection,
+There are three options for invocating sendmail at startup.\n
s/invocating/invoking/
+Please select Yes if you want to use sendmail as your mail transfer\n
+agent. Selecting No disables sendmail to open network socket for\n
s/sendmail to open/sendmail's/
+incoming email, but still runs at startup. None disables sendmail\n
s/still runs at startup/still enables sendmail for outbound mail/
You will probably need to word-wrap differently after this change.
+completely at startup.,
+NULL,
+NULL,
+{
+ { Yes, Start sendmail,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=YES },
+ { No, Start sendmail, but don't listen from network
,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NO },
+ { None, Don't start any sendmail processes,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NONE },
{ NULL } },
};
Index: sysinstall.h
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v
retrieving revision 1.227
diff -u -r1.227 sysinstall.h
--- sysinstall.h 31 May 2002 13:38:17 - 1.227
+++ sysinstall.h 31 May 2002 17:49:19 -
@@ -407,6 +407,7 @@
extern DMenu MenuSysconsScrnmap; /* System console screenmap con
figuration menu */
extern DMenuMenuSysconsTtys;/* System console terminal t
ype menu*/
extern DMenu MenuNetworking; /* Network configuration menu
*/
+extern DMenu MenuSendmail; /* Sendmail configuration menu
*/
extern DMenu MenuInstallCustom; /* Custom Installation menu
*/
extern DMenu MenuDistributions; /* Distribution menu
*/
extern DMenu MenuDiskDevices;/* Disk type devices
*/
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: Call for Review: allow sysinstall to tweak tri-valuesendmail_enable
bmah Comments on the text only (i.e. I haven't tested the new menus)...
Thank you.
I've (of course) tested; making floppies and do a test that sysinstall
saves sendmail_enable line to /etc/rc.conf.
-- -
Makoto `MAR' Matsushita
Index: menus.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v
retrieving revision 1.343
diff -u -r1.343 menus.c
--- menus.c 20 May 2002 17:08:00 - 1.343
+++ menus.c 1 Jun 2002 05:20:02 -
@@ -1372,11 +1372,31 @@
{ Rwhod, This machine wants to run the rwho daemon,
dmenuVarCheck, dmenuToggleVariable, NULL, rwhod_enable=YES },
{ Sendmail, This machine wants to run the sendmail daemon,
- dmenuVarCheck, dmenuToggleVariable, NULL, sendmail_enable=YES },
+ NULL, dmenuSubmenu, NULL, MenuSendmail },
{ Sshd, This machine wants to run the ssh daemon,
dmenuVarCheck, dmenuToggleVariable, NULL, sshd_enable=YES },
{ TCP Extensions, Allow RFC1323 and RFC1644 TCP extensions?,
dmenuVarCheck, dmenuToggleVariable, NULL, tcp_extensions=YES },
+ { NULL } },
+};
+
+DMenu MenuSendmail = {
+DMENU_NORMAL_TYPE | DMENU_SELECTION_RETURNS,
+Sendmail Invocation Selection,
+There are three options for invoking sendmail at startup.\n
+Please select Yes if you want to use sendmail as your mail transfer\n
+agent. Selecting No disables sendmail's network socket for incoming\n
+email, but still enables sendmail for outbound mail. None disables\n
+sendmail completely at startup.,
+NULL,
+NULL,
+{
+ { Yes,Start sendmail,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=YES },
+ { No, Start sendmail, but don't listen from network,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NO },
+ { None, Don't start any sendmail processes,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NONE },
{ NULL } },
};
Index: sysinstall.h
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v
retrieving revision 1.227
diff -u -r1.227 sysinstall.h
--- sysinstall.h31 May 2002 13:38:17 - 1.227
+++ sysinstall.h1 Jun 2002 05:20:02 -
@@ -407,6 +407,7 @@
extern DMenu MenuSysconsScrnmap; /* System console screenmap
configuration menu */
extern DMenuMenuSysconsTtys;/* System console terminal type menu
*/
extern DMenu MenuNetworking; /* Network configuration menu
*/
+extern DMenu MenuSendmail; /* Sendmail configuration menu
+ */
extern DMenu MenuInstallCustom; /* Custom Installation menu
*/
extern DMenu MenuDistributions; /* Distribution menu
*/
extern DMenu MenuDiskDevices;/* Disk type devices
*/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
make kernel broken at dev/usb
cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -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/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -fno-builtin -mpref erred-stack-boundary=2 -ffreestanding /usr/src/sys/dev/usb/udbp.c /usr/src/sys/dev/usb/udbp.c:165: variable `ng_udbp_stat_type_info' has initializer but incomplete type /usr/src/sys/dev/usb/udbp.c:165: extra brace group at end of initializer /usr/src/sys/dev/usb/udbp.c:165: (near initialization for `ng_udbp_stat_type_info') /usr/src/sys/dev/usb/udbp.c:165: extra brace group at end of initializer /usr/src/sys/dev/usb/udbp.c:165: (near initialization for `ng_udbp_stat_type_info') /usr/src/sys/dev/usb/udbp.c:165: extra brace group at end of initializer /usr/src/sys/dev/usb/udbp.c:165: (near initialization for `ng_udbp_stat_type_info') /usr/src/sys/dev/usb/udbp.c:165: extra brace group at end of initializer /usr/src/sys/dev/usb/udbp.c:165: (near initialization for `ng_udbp_stat_type_info') /usr/src/sys/dev/usb/udbp.c:165: warning: excess elements in struct initializer /usr/src/sys/dev/usb/udbp.c:165: warning: (near initialization for `ng_udbp_stat_type_info') /usr/src/sys/dev/usb/udbp.c:165: storage size of `ng_udbp_stat_type_info' isn't known *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
