Re: panic: bdwrite: buffer is not busy
On Sun, 10 Feb 2002, Mikhail Teterin wrote: On 10 Feb, Bruce Evans wrote: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Fdisk I don't really need, but attempting to newfs the floppy caused the same panic :-\ And mounting the already formatted floppy leads to invalid argument. Could we have this fixed soon, please? The inability to access a floppy is a great setback for my local FreeBSD advocacy efforts :-) Newfs'ing /dev/fd0 (instead of /dev/fd0[a-c]) should work better. Not using devfs might work too. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
first time only: cd /usr/src/gnu/usr.bin/binutils cvs -qR up -D '1/27/2002 11:55 UTC' cd /usr/src/contrib/binutils cvs -qR up -D '1/27/2002 11:55 UTC' I thought this sounded like a great idea, but it gives me In file included from /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-i386.c:2159: elf32-target.h:605: `bfd_elf32_bfd_merge_sections' undeclared here (not in a function) elf32-target.h:605: initializer element is not constant elf32-target.h:605: (near initialization for `bfd_elf32_i386_vec._bfd_merge_sections') -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
Never mind. My bad. -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM Error
Yesterday I tried to use SWAT for the first time since the PAM configs were moved from /etc/pam.conf and I'm getting the following error: Feb 6 22:54:05 galaxy swat: PAM _pam_init_handlers: could not open /etc/pam.conf What do I need to do to fix this? Recompile the app. I'm guessing it is linked statically, so is not picking up the latest libpam. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
BSDCON activities 2night?
Anyone making the usual plans or should I just look for the terminal room? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM Error
On Mon, Feb 11, 2002 at 12:04:53PM +, [EMAIL PROTECTED] wrote: Yesterday I tried to use SWAT for the first time since the PAM configs were moved from /etc/pam.conf and I'm getting the following error: Feb 6 22:54:05 galaxy swat: PAM _pam_init_handlers: could not open /etc/pam.conf What do I need to do to fix this? Recompile the app. I'm guessing it is linked statically, so is not picking up the latest libpam. Though that sounds logical to me too, I've had the same errors pop up using a self-compiled 'cups'. I haven't had time to try to chase what's going on. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred holding patch, BDE version
Julian Elischer wrote: This makes little sense to me. Maybe I'm missing something, but by virtue of ownership we don't have to worry about the ucred's refcount on entry into the kernel because it is the owner and no one else is allowed to change our privledges besideds ourselves via set[ug]id(). multiple threads can do it.. The proclock is needed to get the reference, guarding against other threads, and giant is needed fo rnot to free it because if it reaches a refcount of 0 it needs to call free(). (which john assures me needs Giant at this time). We could avoid the proclock with judicious use of an atomic refcount incrementing method. When Giant goes away it won't be so bad but it will STILL be quicker to not drop it across userland. The multiple threads argument is bogus, since the calls to [gs]et[ug]id() are on a per process, not a per thread basis. An argument which *may* not be bogus (I am unconvinced) is that creds are immutable once instanced, and that the calls to [gs]et[ug]id() instance a new cred and replace, rather than changing an existing cred (this logically follows from credential inheritance, or the first set call would change the cred used by init and all other processes). Personally, I still do not understand the need to have a cred reference per thread, the only thing that makes any sense about that is to optimize the degenerate case of a daemon that makes calls as another ID, on behalf of a lot of users (or, sequentially, at least, different users). One example of such a program would be SAMBA (but *not* NFS, due to access semantics on objects based on path component access exclusion by credential not being an effective mechanism for NFS file handles). I think that you would need to have [gs]et[ug]id() be on a per thread basis for this to be an efficiency, and I think trying to do this pessimizes everything else. My gut tells me that creds should be per process, and that the references to them should be taken sparingly, and then only if a need can be justified, rather than just in case some day. Kirk at one time called vnodes the structure that ate the kernel; he was wrong: it was creds. Perhaps this dicsussion is enough impetus to justify revisiting the atomic_t type definitions, which would be useful as reference counted hold/release mechanisms that would obviate the need for locks here? This would at least let you defer getting rid of the per thread cred instances until later. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: ucred holding patch, BDE version
On 11-Feb-02 Julian Elischer wrote: here is the BDE version ready to commit. Extended to other architectures. Bruce, John, comments? As I was adding a prototype to ucred.h I stripped the __Ps of the others in that section (in the spirit of change it when editing it anyhow Hmm, acquire_ucred (don't really like that name, maybe thread_updatecred(td) which can use td_proc to get the proc) probably should be declared in sys/proc.h. Well, maybe not, sys/ucred.h is probably fine. But it's implementation should then be in kern_prot.c along with all the other ucred related functions. :) Also, please make the comment above the function into a complete sentence and capitalize appropriately, etc. as per style(9) just to be pedantic. I guess removing __P() as you go is ok if that spirit is what the -arch thread is desired. Personally I thought it should be the other way around just like we don't mix whitespace commits with code commits to avoid obfuscating function changes with style changes. IMO, just commit to ucred.h blowing away __P() first, then commit your functional changes with the rest. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred holding patch, BDE version
On 11-Feb-02 Alfred Perlstein wrote: * Julian Elischer [EMAIL PROTECTED] [020211 15:00] wrote: In the current world, when the thread enters userland, it does: lock giant crfree() (which includes mutexes) unlock giant This isn't needed afaik. Yes, calling free() without Giant is about as good as calling fdrop() without Giant Alfred. :) if there are ASTs it does this once again for each AST waiting as well. And on the way into the system it does: lock process crhold() (which includes mutex ops) unlock process This isn't needed, at least afaik. Not strictly for the comparison as Julian and Terry pointed out since the race can occur anyway (i.e., you don't need the lock to see if p_ucred changed), however, if you are actually doing a crhold(), you want to make sure p_ucred isn't stale, so you need the proc lock. so if there is a single AST (not uncommon) it does on a system call, 4 to 6 locks and 4 to 6 unlocks just to get a reference on the ucred it already had a reference on. By not freeing it when going to userland, and checking if it is the right one when returning to the kernel, we replace that with a pointer comparison (well maybe 2) 99.999% of the time. John still wants to free it if INVARIANTS is on so he canh trap on inapropriate access. I'm not sure it's needed but am willing to do so.. This makes little sense to me. Maybe I'm missing something, but by virtue of ownership we don't have to worry about the ucred's refcount on entry into the kernel because it is the owner and no one else is allowed to change our privledges besideds ourselves via set[ug]id(). Umm, do you understand the entire thread ucred reference at all? What if you have two threads on two different CPU's from teh same process and one changes your ucred out from under you while you are handlign a syscall? The idea here is to ensure that a thread has a consistent ucred for an entire user trap or syscall to avoid races involving credentials. Therefore the additional hold on entry is completely useless no matter what and with that the release on exit is also useless. No, you just haven't been keeping up. I added td_ucred at least a month or so ago and it was discussed on -arch before it went in. I have a big honking patch to test when I get back from BSDCon that changes the kernel to use td_ucred almost everywhere instead of p_ucred so that we actualyl use the per-thread ucred (which will be needed before we can stop being a 1:1:1:1 system) and also means credential ops such as suser(), and p_can* don't need locks for the current thread. (p_can* still need locks for the target process). -Alfred -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred holding patch, BDE version
On 12-Feb-02 Julian Elischer wrote: The proclock is needed to get the reference, guarding against other threads, and giant is needed fo rnot to free it because if it reaches a refcount of 0 it needs to call free(). (which john assures me needs Giant at this time). We could avoid the proclock with judicious use of an atomic refcount incrementing method. _No_! The proc lock is protecting p_ucred, it can't go away! What _can_ go away is the per-ucred mutex to protect the refcount if we ever revive the refcount API. When Giant goes away it won't be so bad but it will STILL be quicker to not drop it across userland. Yes. Actually, calling free() can still be rather expensive even when Giant is gone. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred holding patch, BDE version
On 12-Feb-02 Terry Lambert wrote: Julian Elischer wrote: This makes little sense to me. Maybe I'm missing something, but by virtue of ownership we don't have to worry about the ucred's refcount on entry into the kernel because it is the owner and no one else is allowed to change our privledges besideds ourselves via set[ug]id(). multiple threads can do it.. The proclock is needed to get the reference, guarding against other threads, and giant is needed fo rnot to free it because if it reaches a refcount of 0 it needs to call free(). (which john assures me needs Giant at this time). We could avoid the proclock with judicious use of an atomic refcount incrementing method. When Giant goes away it won't be so bad but it will STILL be quicker to not drop it across userland. The multiple threads argument is bogus, since the calls to [gs]et[ug]id() are on a per process, not a per thread basis. Thread 1 makes a syscall that blocks. Say it blocks in one of 3 VOP's all of which need a credential. Thread 2 changes the credentials of the process. Thread 1 now resumes assuming that say a VADMIN or VACCESS suceeded with the old cred that may not be valid any longer and performs VOP's with the now newer credential (which it may even read a stale value of w/o a lock thus using some random memory for the creds) to do its other VOP's which may now fail weirdly. The idea of per-thread ucred references is so that a thread will have the same credentials for the lifetime of a syscall so that the entire syscall is self consistent. It also means that except for when we update the ucred reference, we don't need locks to access thread credentials since the thread references are to read-only credentials. We discussed this on -arch _months_ ago and everyone agreed with it then. Perhaps this dicsussion is enough impetus to justify revisiting the atomic_t type definitions, which would be useful as reference counted hold/release mechanisms that would obviate the need for locks here? This would at least let you defer getting rid of the per thread cred instances until later. All having the refcount_t and other refcount_* functions would do is let us get rid of the per-ucred mutex (actually a pool mutex, so the overhead per ucred is just a pointer right now). It wouln't change the fact that we need a lock to make sure p_ucred is up to date before we read a value we need to depend on or actually use. -- Terry -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: ucred holding patch, BDE version
On Mon, 11 Feb 2002, John Baldwin wrote: On 11-Feb-02 Julian Elischer wrote: here is the BDE version ready to commit. Extended to other architectures. Bruce, John, comments? As I was adding a prototype to ucred.h I stripped the __Ps of the others in that section (in the spirit of change it when editing it anyhow Hmm, acquire_ucred (don't really like that name, maybe thread_updatecred(td) which can use td_proc to get the proc) probably should be declared in sys/proc.h. Well, maybe not, sys/ucred.h is probably fine. But it's implementation should then be in kern_prot.c along with all the other ucred related functions. :) I guess so. The name requires changing anyhow as it was pointed out to me that Bruce mis-spelled acquire and I didn't notice. Also, please make the comment above the function into a complete sentence and capitalize appropriately, etc. as per style(9) just to be pedantic. I guess removing __P() as you go is ok if that spirit is what the -arch thread is desired. Personally I thought it should be the other way around just like we don't mix whitespace commits with code commits to avoid obfuscating function changes with style changes. IMO, just commit to ucred.h blowing away __P() first, then commit your functional changes with the rest. hmmm I am completely confused as to which way we ended up deciding then.. :-) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ucred holding patch, BDE version
On Mon, 11 Feb 2002, Terry Lambert wrote: Julian Elischer wrote: This makes little sense to me. Maybe I'm missing something, but by virtue of ownership we don't have to worry about the ucred's refcount on entry into the kernel because it is the owner and no one else is allowed to change our privledges besideds ourselves via set[ug]id(). multiple threads can do it.. The proclock is needed to get the reference, guarding against other threads, and giant is needed fo rnot to free it because if it reaches a refcount of 0 it needs to call free(). (which john assures me needs Giant at this time). We could avoid the proclock with judicious use of an atomic refcount incrementing method. When Giant goes away it won't be so bad but it will STILL be quicker to not drop it across userland. The multiple threads argument is bogus, since the calls to [gs]et[ug]id() are on a per process, not a per thread basis. there is no such thing as a per process syscall. Two threads can always do the same syscall at the same time. there needs to be a proc-lock to stop it from becoming chaotic in there. In actual fact, since you cannot alter a cred but only replace that which the process points to it's not quite that bad, but you need to either lock it or have atomic reference-counting that can handle the possibility that the cred could have bee decremented to 0 by another thread just before you checked it. An argument which *may* not be bogus (I am unconvinced) is that creds are immutable once instanced, and that the calls to [gs]et[ug]id() instance a new cred and replace, rather than changing an existing cred (this logically follows from credential inheritance, or the first set call would change the cred used by init and all other processes). Personally, I still do not understand the need to have a cred reference per thread, the only thing that makes any sense about that is to optimize the degenerate case of a daemon that makes calls as another ID, on behalf of a lot of users (or, sequentially, at least, different users). One example of such a program would be SAMBA (but *not* NFS, due to access semantics on objects based on path component access exclusion by credential not being an effective mechanism for NFS file handles). the cred that is in force at the time that the syscall STARTS is used for the full syscall otherwise you could have one cred used for the first part of a syscall and a completely differnet one used for the secnd part of a syscall. I think that you would need to have [gs]et[ug]id() be on a per thread basis for this to be an efficiency, and I think trying to do this pessimizes everything else. My gut tells me that creds should be per process, and that the references to them should be taken sparingly, and then only if a need can be justified, rather than just in case some day. creads can only be changed per process but the threads only pick up the change on next syscall startup. Kirk at one time called vnodes the structure that ate the kernel; he was wrong: it was creds. I believe it was Mike Karels. Perhaps this dicsussion is enough impetus to justify revisiting the atomic_t type definitions, which would be useful as reference counted hold/release mechanisms that would obviate the need for locks here? This would at least let you defer getting rid of the per thread cred instances until later. I've made that point before and I believe that jhb has said he would like such primatives. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Binutils fixed in -current?
Does anyone know if the problem with kde and other programs not working with the new binutils not working have been fixed yet? -- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Binutils fixed in -current?
I read recently on this list that the problem with the -current binutils on Alphas had been fixed, did this also fix the problem on i386 which caused ports such as imlib, imlib2 and gnomelibs to behave weirdly as many of their binaries would segfault during configuring/linking/executing? I only ask because I would like to stop having to update my -current tree and then having to copy an old binutils over it so that things will work. Any information is appreciated. Jordan 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
* Julian Elischer [EMAIL PROTECTED] [020206 12:20] wrote: 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. I commend you on your wait for testers, but I find that after a couple of days of waiting for them to appear and give decent feedback usually just committing the code will bring out a horde of involentary testers which actually gets the code stabilized. This is current, we're allowed some breakage. Cross your I's and dot your T's first though. :-) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Performance of -current vs -stable
At 12:10 AM -0500 2/6/02, Garance A Drosihn wrote: One simple test I tried was that I have a copy of the freebsd cvs repository in /usr/cvs/free, on it's own partition. Each system has it's own /usr/src, of course. I cvsup'ed /usr/cvs/free, and then did a time cvs status /dev/null in each /usr/src, on each system. The popular vote fingered the WITNESS option as the culprit for the significant slowdown I noticed in -current. I compiled a kernel which did nothing but turn that off, and here is an updated chart of my simple-minded benchmark: On current On currentOn stable +witness NO witness (no witness) -- -- -- real7m 43.392s 5m 9.443s 4m 53.100sin the /usr/src user0m 11.692s 0m 11.223s 0m 4.203s for current sys 3m 4.601s 0m 17.353s 0m 2.248s real6m 40.322s 1m 57.438s 2m 39.361sin the /usr/src user0m 10.531s 0m 9.474s 0m 6.653s for stable sys 4m 28.863s 0m 12.527s 0m 9.480s So, things are quite reasonable for my purposes if I turn off the WITNESS kernel option, and leave all the other debugging stuff active. reminder: The above is obviously not a scientific benchmark! It was just something adequate enough to show a rough idea of the performance I was feeling. Thanks for the pointers. Now I'll try recompiling the rest of the ports I have on my -stable system, and see if I can't keep my office machine running in -current instead of -stable... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [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
Lock order reversals, login-related, maybe...
Are the following lock order reversals something that I should mention when I encounter them, in general? On the other hand, this is from an older -current, built 25.Jan, before which I don't see these messages, while after installworld/reboot, I see them, except I haven't normally booted into -current other than after -stable wedges/panics and I want to background-fsck all filesystems. Actually, it looks like once I did, so this, which immediately follows my alternate-r00t-login, is unrelated to the background fsck, but it always follows my login. If that made any sense. Jan 30 08:34:56 dastardly login: ROOT LOGIN (t00r) ON ttyv7 Jan 30 08:34:57 dastardly kernel: lock order reversal Jan 30 08:34:57 dastardly kernel: 1st 0xc188b634 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Jan 30 08:34:57 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 Feb 1 14:13:36 dastardly login: ROOT LOGIN (t00r) ON ttyv3 Feb 1 14:13:37 dastardly kernel: lock order reversal Feb 1 14:13:37 dastardly kernel: 1st 0xc187e734 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Feb 1 14:13:37 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 Feb 1 14:22:24 dastardly login: ROOT LOGIN (t00r) ON ttyv7 Feb 1 14:22:25 dastardly kernel: lock order reversal Feb 1 14:22:25 dastardly kernel: 1st 0xc1880034 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Feb 1 14:22:25 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 [etc] I'll assume that since this is two weeks old, it's been noted already, but in general, I wonder if I should report such occurrences, in a more timely manner... thanks barry bouwsma 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
See Real Babes (0384CuMg3-126YqKc6577@20)
--=_NextPart_000_00C4_03E14D8D.A0707E67 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc2l6ZT0i MiI+PHU+PGI+V0FSTklORzwvYj48L3U+OiBUaGUgZm9sbG93aW5nIG1hdGVy aWFsIGlzIG9mIGFuIGV4dHJlbWUNCmFkdWx0IG5hdHVyZS4gSWYgeW91IGFy ZTxicj4NCm9mZmVuZGVkIGJ5IGV4cGxpY2l0IGFkdWx0IG1hdGVyaWFsIG9y IGFyZSB1bmRlciB0aGUgYWdlIG9mIDE4LCZuYnNwOyBkZWxldGUNCnRoaXMg ZW1haWwgbm93PC9mb250Pjxmb250IHNpemU9IjEiPi48L2ZvbnQ+DQo8cD4N CjxhIGltZyBTUkM9ImcwMS5qcGciIEJPUkRFUj0iMCIgaGVpZ2h0PSIxMDUi IHdpZHRoPSIxNDAiIGhyZWY9Imh0dHA6Ly93d3cuZnJlZXdlYmhvc3Q0dS5j b20vc2V4eTA4L2luZGV4b3MuaHRtIj4NCjxpbWcgU1JDPSJodHRwOi8vd3d3 OS5raW5naG9zdC5jb20vdGVlbi90bTMxNDUwLzIzLmpwZyIgQk9SREVSPTAg aGVpZ2h0PTEwNSB3aWR0aD0xNDA+DQo8aW1nIFNSQz0iaHR0cDovL3d3dzku a2luZ2hvc3QuY29tL3RlZW4vdG0zMTQ1MC9idXR0MS5qcGciIEJPUkRFUj0w IGhlaWdodD0xMDUgd2lkdGg9MTQwPg0KPGltZyBTUkM9Imh0dHA6Ly93d3c5 Lmtpbmdob3N0LmNvbS90ZWVuL3RtMzE0NTAvc2hlMS5qcGciIEJPUkRFUj0w IGhlaWdodD0xMDUgd2lkdGg9MTQwPg0KDQo8L2E+PC9wPg0KPHA+PGEgaW1n IFNSQz0iZzAxLmpwZyIgQk9SREVSPSIwIiBoZWlnaHQ9IjEwNSIgd2lkdGg9 IjE0MCIgaHJlZj0iaHR0cDovL3d3dy5mcmVld2ViaG9zdDR1LmNvbS9zZXh5 MDgvaW5kZXhvcy5odG0iPg0KPHU+VEhFIDxmb250IGNvbG9yPSIjRkYwMDAw Ij48Yj5IT1QtRVNUPC9iPjwvZm9udD4mbmJzcDsmbmJzcDsgKipYWFgqKiZu YnNwOw0KVEVFTiBIQVJEQ09SRSA8YnI+DQpBQ1RJT04gT04gVEhFIE5FVCBU T0RBWSEhPC91PjwvYT48L3A+DQo8cD48YSBpbWcgU1JDPSJnMDEuanBnIiBC T1JERVI9IjAiIGhlaWdodD0iMTA1IiB3aWR0aD0iMTQwIiBocmVmPSJodHRw Oi8vd3d3LmZyZWV3ZWJob3N0NHUuY29tL3NleHkwOC9pbmRleG9zLmh0bSI+ DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpD TElDSyBIRVJFIEZPUiBJTlNUQU5UIEFDQ0VTUzxicj4NCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjwvYT48L3A+DQo8cD48dT48Yj5C ZXN0IGNvbnRlbnQgYXJvdW5kPC9iPjwvdT4gLSA8YnI+DQpDVU1TSE9UIEZh bnRhc2llczxicj4NCkFTUyBGYW50YXNpZXM8YnI+DQpTTVVUIEZhbnRhc2ll czxicj4NCkxFU0JJQU4gRmFudGFzaWVzPGJyPg0KT1JJRU5UQUwgRmFudGFz aWVzIEdBTE9SRTwvcD4NCjxwPjx1PlNQRUNJQUwgQk9OVVMgRk9SIFRSSUFM IE1FTUJFUlNISVA8YnI+DQo8L3U+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxmb250IHNpemU9IjQiPiEhITkgYnJhbmQgbmV3IGNlbGViIG1vdmllcyEh ITwvZm9udD48L3A+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0 dHA6Ly93d3cuZnJlZXdlYmhvc3Q0dS5jb20vc2V4eTA4L2luZGV4b3MuaHRt Ij5DTElDSw0KSEVSRSBGT1IgSU5TVEFOVCBBQ0NFU1M8L2E+PGJyPg0KKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciZuYnNwOzxi cj4NCmFuZCB3aXNoIHRvIGJlIHJlbW92ZWQgcGxlYXNlIDxhIGhyZWY9Im1h aWx0bzp0bTMxMDQ1NkB5YWhvby5jb20iPmNsaWNrDQpoZXJlPC9hPiBhbmQg cHV0Jm5ic3A7PGJyPg0KJnF1b3Q7R0VUIE1FIE9GRiZxdW90OyBpbiB0aGUg c3ViamVjdCBsaW5lPC9wPg0KPHA+Jm5ic3A7PC9wPg0KPC9ib2R5Pg0KPC9o dG1sPg0KDQpbMDM4NEA0XQ0K To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-security in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ThinkPad X22 PC-Card slot problem
Next_Part(Wed_Feb__6_23:02:07_2002_731)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I recently installed -current to ThinkPad X22. Though it seems that X22's PC-Card slots work fine with -stable, in -current when probing PCICs I got following message, pcic0: Ricoh RL5C476 PCI-CardBus Bridge mem 0x5000-0x5fff irq 11 at device 3.0 on pci2 pcib2: device pcic0 requested unsupported memory range 0x5000-0x5fff (decoding 0xc020-0xcfff, 0xe800-0xf00f) pcib2: device pcic0 requested decoded memory range 0x5000-0x5fff after this, pcic returns error but some how it is attached and when I install a PC-Card, the machine freezes. The address range above (0x5000-0x5fff) is same one that I see with -stable. When PCI_ALLOW_UNSUPPORTED_IO_RANGE is defined in sys/dev/pci/pci_pci.c, pcic does not return error, the machine does not freeze, but when a PC-Card is inserted I get the message, pccard: card inserted, slot 0 pcic0: reset 1 int is 10 stat is 5f pcic0: reset 2 int is 70 stat is 5f pcic0: reset 3 int is 70 stat is 7f pcic0: Event mask 0x9 pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f pcib2: device pccard0 requested decoded I/O range 0x4000-0x25f : and the card does not attached. The complete dmesg with boot -v is attached. Any ideas ? // Noriaki Mitsunaga // Next_Part(Wed_Feb__6_23:02:07_2002_731)-- Content-Type: Application/Octet-Stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dmesg.X22-current.gz H4sICCZVXzwCA2RtZXNnLlgyMi1jdXJyZW50AOw8/W/buJI/13/FoHfvkOzZDkl92rcpnuOk ra9Nk4vTfQssHgJZomK92JJWktu4f/3NkJKsOLbjZFssHrBFqlDiDOeDM8MZisowSZdZdDst 4MA/BN7riY5gTMD1VMLbTMqT8SlcZsm/pF90W8M1YKfXxqvL1NVQV1tdXXVVvT2urkJdFUzP bL2i4a/krYyLHJIQCrz9HEdfZJZHxZKeDL1ZFCZZHHldGMxmoMjmkMlcZl9k0G1VzFld1hl+ vro6+3QN/8F5H64XyLmcAFiAt4bd5z343/E1kFgtwH9ZkhR/L1LGuzLrevO8K+PbbpJ7d15n 0fX87r/S/tEiz47yzD/Kl/lRZLj2kZ/M02gmj96dfTq7Gg1bl5mcJV4gA5CzEO5kFssZvD6a 4NhH+q789Rq8Ati9zyxLMsa6a5jzJFjM5Bqm56dR9y55gDoxUf+olEnmFVF8C/4s8e8O8kPo drtwPR7qB31weo5hMm704P23NkSusMyqi/OewR0HO1rDjx9uPo/PbkbUfzMcfBydXA2uRxef IE4KyFPpR2GELHZgkRO1QIbeYlZAmMnfFzL2l63raC79ZBEXMoPXisxrWHVrWq5o0kIm96CU zALwKzmTGOaymCbBQ3I40gNiSma0MVORu/zch0u0rGgxh9FodNRow68yiY+GciYzHPoA8bqG 1Tl//w1s1+74My/PAfEP0U4u0OKiGI7h9TsZL6JYjpA2ziaMAnzI7u0JBxgXMk2J62PgiPNW esUCTfSY3RuuEfbC8Oe3l5/bv5yftU/P2pfjszZy3j4fX7UvB2ft8+FZe/ir2x6fXbbPr6/w 4Tt6OGgPzy9+QYhrwjDs9vn5r+23vyLSeHz2ppVJb4ZKmSfZEpCsyQSzDcNmcGD0hG2yDzBZ FjI/bF1Ol3nkr4D96SImg+m32D0aIuP4H7WubnoyDMM22KbDbVcPAAfcciH1bmksArJcq8Lg Tmg7CsPo2cIUPdOskHq2g6ZXonlfvKimfwyGawnhuox4dWz0x5rXSZTkhujDW5zhAE5GF2ND wBg9PfIlnEYZRh8aYirRb7LKK1joGC6rcc/iQlFh92HgSKRBENQ6BAw1X6gH4KOM1VylfkR4 aCjDkaIHUqGroRHLYf+NYrqylcapBtSsXcaXGjzwCq/JiGQr0IqTkNTc97jBKw54twn2BWlC OPNuaSBzYrYuMA5mevw8uo21MUFIlPuteDGb9eFn+oXuSJppwze04/IGLcOLg2SOICQKRmrI k0VGHTgB+LSchv+C0dHFm1blFBjbgYwP8kWaJlmBevAmMxmQhm6SVMYH/LD/CqOUBA5eEGSg oA7QIvzQPYQoRxW4ypq42UDySiyu3cFl+h8hVu1DBe6Ht/5UYnh6peXAWfpNOeIxswnqn/Db NMiOqYG0SEESDqLg2LAcy2Wufdj6rOLGf16OrqAg3nGNMdV0Rqi8eooCOWGtOL1npAqvmEKa Jb7M8yR7AxRmEhp6knhZUEKNcEHhNkQUckLPly2KyoQ9OjmnZeT6ssNP8fcjdOocDC9HHYaO 0YeffvoJzrIsyfpwrmIZyHvpL1RwC9E/ZNCGwdnNp4vrm7NfR+PrPx2/lDNNvqIxThZFgYCo +imaFwKDh0qFMLrHZqjjHanyNvPmc5oHmvRZ92G8Jm4eBGycvJ5lWhSuvwe3NwVSy2huhNmZ RAWoe5p7o6spYYh/oy0X3Zoxt6N+TWjqlLh6GD9d0CC4ArxZ6ym+UQfN8Rwj6rcklusQsyhQ uAk536xi/mMUwPhrVPjTdXitWEIZz6RM4UTdr0NRnCKY90ledChWTbIouJW1LOiDHbqGKzxE odmrov9kgZ7UejX30t84+2cfimUqAfMwjBa32MC8bOLlEoLSKdsYeb5JEJjBVZFAxZ/Om1cY roIkU85MaR66K61z6IY4GLpugHeYYb1SBHGYWVLQ73AR+8RA5dMdxjpEBp2aWCEkvJuHargn adnbafFNtMx1WnxFS+lE1DoxH+lErZJurROw9tSJMF3R4JM/5FP0HjHqd5ixVSmIjjEIs4xj D/O57PdjzvdlXbyEdXMP1vl+rLOa9clzWTdfwrqzB+viuaz7NetPkDfdFXlzjbzBnmudT8nq b5fV2OgKfJeFPQwPmyeF8bCeFGM1KRrXfALXCM0KV6zjuk/RdbbT9Z+i62yl+7QR2jVdc38j 9PaYmJX/cJoYwtlthKXrC8val3f3JQ5k7MG70XQg6/m+/5SZcX8VcdGj1EIXRPkzjI27fj2C vT7CUyqw9lCBVavA3OVXL1aBMP+oCsRqKQfnuSqw91CBXavAee4KoBOUn1U2s8jrjEfnOqoy 47r7QcKDyVxZIGARRTg0TAUNkGO2GQceFjg4JuWUZZGnOxeTJAsiLKhk2d3oxHIIR/apwin/ YabBKEu5N7DGXQGWBVQDlioLrsJMRzXD8AFCmslQYuqHmXKJxO5lmWchgnTCGoGvZWz86YxN rmVszjNDssEeGNmWkMwf4VYil7jc3hFeEFJUhmX6Vq9hWEwbFt+aKRq7M8UNSZGqWGhHCQRU 9WwOpwxOOZwKODUA/EWWUdV9ykqtPzBDNXNVB7pLOvOWbfjl3aBpfgzN7yDGsjuj/UrsKDya 4sPWYqoNW20UgStcxoeDo+HgHA5Gw/fGIXwen4Cv64MZYuJtZ7CqSlxlFNzlIQkEnDdoil7D 5hf55AVkEFsxWKITEM1FToUVbUsspgt6rkf9/B61QvukgE/boDfGekdMzR+BsyO6tPWOAK+Q BWiVY8EzxZsMHeaLrshz2utU84NmQnzwZ0pw0lCU0IoyNiuKNxX1AjKloniJvlFR/I8oij9L UQIlUFQObmUss8hf57uhGFMrxtqsGLFSjB734JP8qiU4VUCjoEyj9b4Kyr8H8VJdogTfqC6i 1Rj5RVoTe2uNvFjsXEEMtraEiM1LiGh0PlpC3FXnpiXE1EHerVYEsX0JEfUSEq5WBI2wcQlx 6yUkZKxGEGtLiFhfQh6HcuvhEsLFrlDOKaPUoZyZzULcc3UoF1WOsKn6cNZDudhZ3z4vlO8h KP+BgvLnCjr5YYKSMfGGoHxfQS1LPF6c1wV9UDuzDn9yx8LfR9CdIj7Oe8LnGK2waxEN19lQ
MODULES_WITH_WORLD=true means no modules?
Is it just me, or... I've changed my /etc/make.conf from the default, to be MODULES_WITH_WORLD=true # do not build modules when building kernel since I find myself often building new kernels (plus identical modules) without updating the rest of the source, taking extra time. I just finished the buildworld/kernel/install jig, and I've got a fistful of modules built in /usr/obj/5.0-CURRENT/usr/src/sys/modules but after both installkernel and installworld, I've got an empty /boot/modules, and the only inhabitant of /boot/kernel/ is kernel. /boot/kernel.old/ is where I can find old modules, from when I built things the default way (build a new kernel, modules too) Either the modules aren't getting installed, or some other thing I've changed in /etc/make.conf (like the /usr/obj/5.0-CURRENT prefix) has hosed the modules install process. Is someone else using `MODULES_WITH_WORLD=true' successfully? If so, I'll boot back into -current and see if I can check it out... thanks barry bouwsma 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
Promise/ATA-Raid making panic in -CURRENT?
Hi! I checked and compiled the recent -CURRENT tree, buildworld and buildkernel goes all fine. When booting it seems to crash on initialization of my Promise controller and get bad ivar request (4). I stripped all possible drivers out of the kernelconfig, except for the ata driver, and it still crashes. I then see a couple of pci0: sumdevice (no driver attached), and when it should come to my Promise, BAM! Anyone can tell me how I can disable the ata-raid/Promise driver to test? Thx /tso __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com 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
Performance of -current vs -stable
With 4.5-release out the door, I thought I'd start trying to use 5.0-current on my main freebsd machine instead of 4.x-stable. I figure at some point we (as developers) have got to try to migrate to that release as much as possible. I had been doing some stuff with 5.0-current at home. That seemed a bit slow, but I didn't think too much of it as the home machine is a single-CPU Duron-based machine (600 Mhz). while the machine at work is a dual-CPU Pentium-3 machine (650 MHz). The office machine also has more RAM, so obviously the home machine would be slower. But switching to current on the office machine is also considerably slower. I wasn't expecting faster, but I'm wondering if other people are also seeing it as much slower, or if I've just got some other odd problem hitting me. One simple test I tried was that I have a copy of the freebsd cvs repository in /usr/cvs/free, on it's own partition. Each system has it's own /usr/src, of course. I cvsup'ed /usr/cvs/free, and then did a time cvs status /dev/null in each /usr/src, on each system. (that command is just for this timing test, I usually do more useful commands at that point!). On current On stable -- -- real7m 43.392s 4m 53.100sin /usr/src for current user0m 11.692s 0m 4.203s sys 3m 4.601s 0m 2.248s real6m 40.322s 2m 39.361sin /usr/src for stable user0m 10.531s 0m 6.653s sys 4m 28.863s 0m 9.480s I realize this example isn't terribly detailed, but it seems to match what I feel when doing any major work on current. I'm used to a 'make -j5 buildworld' taking between 42 and 45 minutes for stable on my office machine, but the few times I've rebuilt -current, it's taking more like three and a half hours. That is quite a hit. This current system was initially installed in late-december, doing a full system-install (booting off a CD, newfs'ing the partitions, etc). So, it should have picked up all the recent filesystem improvements (dirprefs, etc) when laying out the files, and even if that wasn't true this test is done using the exact same directories as source destination for the stable vs current tests. Could it be due to the DDB, INVARIANTS WITNESS options in the kernel? If it is that's fine with me, I'm just wondering where that magnitude of a slowdown would be coming from. Anything else I should check? I realize there's about a million differences between the two branches, and there might also be something about my machine's setup which is a major culprit here. I'm just looking for a basic idea of what other people have been seeing for performance when they run current. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [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: Promise/ATA-Raid making panic in -CURRENT?
The bad ivar request (4) message does *not* come from the ATA driver, you must have something else that is ruining your day... Does it boot if you take out the promise board ? I was in a hurry yesterday and let the kernel compile w/o the ata driver while being under the shower. Without the ata driver it does boot. Just wanted to let you know. I'll take the Promise out when I got some more time (latest friday evening). /tso __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com 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
Lock order reversal on shutdown
In noticed this lock order reversal while shutting down the system to single-user in order to make installworld of my cvsup of today. I then tried again with the new world and the l.o.r. was still there. lock order reversal 1st 0xc0409dc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc4141e34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 -- Michael Nottebrock 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: gcc3.x issues
* Joe Kelsey [EMAIL PROTECTED] [020207 09:36] wrote: David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. Actually David routinely requests assistance and would like to offload some if not all of the gcc maintainance, the problem he's having is finding people capable and willing to do the work rather than people that just want to draft emails complaining about his current work. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. By stating that he would consider patches he's already given you the go-ahead to do the work, if it's up to par with the project's guidlines there should be minimal fuss with integration. Thanks for your helpful and pleasant comments David. Yeah, whatever, don't we all feel better now? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org down?
This is a different problem. The stable.freebsd.org machine, on which all the really big NFS storage lives, failed to come back up from a reboot last night and I'm trying to get it restarted now. The terminal server also appears to be sick or I'd be able to intervene remotely. :( - Jordan I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? Hmm... galtvalion % ftp current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version 6.00LS) ready. Name (current.freebsd.org:matusita): ftp 331 Guest login ok, send your email address as password. Password: 550 Can't set guest privileges. ftp: Login failed. ftp ^D 221 Goodbye. galtvalion % ftp stable.freebsd.org ftp: connect: Connection refused galtvalion % Both snapshots machine are not available for services... anybody knows what's going on? -- - Makoto `MAR' Matsushita 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: MODULES_WITH_WORLD=true means no modules?
MODULES_WITH_WORLD=true # do not build modules when building kernel ^^^ ...you need to read the option you enabled? Never mind, I figured out what happened, and will happen again in the future, since this doesn't quite `optimize' things as I'd like I had actually started writing to ask why /boot/kernel.old hadn't been updated with my previous /boot/kernel, but then I figured it out. Since I had done two `installkernel's, I was using the kernel image in /boot/kernel.old/ from the first installkernel, and a test is made, so that if I'm using it, it doesn't get deleted. Instead, what happened was that the existing /boot/kernel contents were nuked. This had been populated by kernel modules by the installworld step that I did following the first installkernel. So, when the above option is enabled, normally your previous contents of /boot/kernel/ are moved to replace /boot/kernel.old/ by `installkernel' and the new contents of /boot/kernel/ are no more than kernel alone -- look ma, no modules! In order to get /boot/kernel/ populated with modules, either one needs to installworld again, or use one of the targets to install only modules, I guess. Actually, on this machine, a complete installworld probably takes less time than the present way to build a fresh kernel and set of modules as the `buildkernel' step, which I had hoped would be sped up. What I had perhaps been thinking (if you could claim that I was in fact thinking at all) was that the modules would be installed into a location by `installworld' that would be independent of any `build/installkernel's that would follow -- such as /boot/modules, which appears in the sysctl kern.module_path under -current. That way one could build new kernels from the same source, adding or removing devices, only needing to update the modules as part of the installworld when the source gets changed. At least, that was my goal in enabling this /etc/make.conf option, to speed up the buildkernel/installkernel process by skipping module rebuilding any time I swap in a different ethernet or sound card or find a new spiffy kernel option to try out. That's it in a nutshell. FWIW, booting the new kernel just built a few hours ago gives the following: | CPU: Pentium/P54C (75.00-MHz 586-class CPU) | Origin = GenuineIntel Id = 0x524 Stepping = 4 | Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 = WARNING: Driver mistake: make_dev(perfmon) called before SI_SUB_DRIVERS | real memory = 41943040 (40960K bytes) Once again, I fling off a message before engaging brane barry bouwsma 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: ThinkPad X22 PC-Card slot problem
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : From: M. Warner Losh [EMAIL PROTECTED] : Date: Wed, 06 Feb 2002 19:33:32 -0700 (MST) : Hmmm. This looks ugly. :-( I can't boot with acpi enabled on my Dell : Inspiron 8000. I can boot with apm enabled. There are issues with : routing interrupts accross PCI PCI bridges at the moment when the : slots on the other side of the bridge are in the PIR table. : : It turned out that this was not a intterupt routing problem. By : disabling the memory/port range checks in sys/dev/pci/pci_pci.c solved : the problem (below is the patch). pci_pci.c claims that both the : memory adderss for pcic and the PC-Cards are not supported but I could : use the addresses. Yes. This is the ISA problem. The checks are there to make sure we don't assign addresses that aren't decoded by the bridge. However, the bridge does decode ISA addresses. I need to check into which ISA stuff a little better before making a fix. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Performance of -current vs -stable
On Thu, Feb 07, 2002 at 10:15:02AM +0100, Cejka Rudolf wrote: Garance A Drosihn wrote (2002/02/06): Anything else I should check? I realize there's about a million differences between the two branches, and there might also be something about my machine's setup which is a major culprit here. I'm just looking for a basic idea of what other people have been seeing for performance when they run current. There is another common source of confusion: If anybody has IDE disks, write-caching is enabled by default in -stable, but disabled in -current. I don't think that is true anymore. -stable has WC enabled as well. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands 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
ACPI error Method execution failed, AE_AML_REGION_LIMIT
Hi! I updated my notebook from -stable to -current some days ago and get this message ~ every second: ACPI-0294: *** Error: Method execution failed, AE_AML_REGION_LIMIT Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Wed Feb 6 23:42:40 CET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/DEIMOS5 Preloaded elf kernel /boot/kernel/kernel at 0xc0442000. Preloaded userconfig_script /boot/kernel.conf at 0xc04420a8. Preloaded elf module /boot/kernel/acpi.ko at 0xc04420f8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 847427426 Hz CPU: Pentium III/Pentium III Xeon/Celeron (847.43-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 129957888 (126912K bytes) avail memory = 122019840 (119160K bytes) Pentium Pro MTRR support enabled Using $PIR table, 3 entries at 0xc00f76b0 npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMIINT AMIINT10 on motherboard ACPI-0294: *** Error: Method execution failed, AE_AML_REGION_LIMIT Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x5008-0x500b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 atapci0: SiS 5591 ATA66 controller port 0xffa0-0xffaf,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 irq 0 at device 0.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 sis0: SiS 900 10/100BaseTX port 0xd000-0xd0ff mem 0xffdc-0xffdc0fff irq 11 at device 1.1 on pci0 sis0: Ethernet address: 00:a0:cc:c5:62:c5 miibus0: MII bus on sis0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ohci0: SiS 5571 USB controller mem 0xffdd-0xffdd0fff irq 9 at device 1.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SiS 5571 USB controller on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: SiS 5571 USB controller mem 0xffde-0xffde0fff irq 9 at device 1.3 on pci0 usb1: OHCI version 1.0, legacy support usb1: SiS 5571 USB controller on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcm0: SiS 7018 port 0xd400-0xd4ff mem 0xffdf-0xffdf0fff irq 10 at device 1.4 on pci0 pci0: simple comms at device 1.6 (no driver attached) pcib1: PCI-PCI bridge at device 2.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcic0: O2micro 6812/6872 PCI-Cardbus Bridge at device 3.0 on pci0 pcic0: PCI Memory allocated: 0x4400 pcic0: Polling mode pcic0: Warning: O2micro OZ68xx chips may not work pccard0: PC Card bus (classic) on pcic0 acpi_cmbat0: Control method Battery on acpi0 acpi_acad0: AC adapter on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 acpi_button1: Power Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 acpi_ec0: embedded controller port 0x66,0x62 on acpi0 fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A fdc0: direction bit not set fdc0: cmd 3 failed at out byte 1 of 3 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it pcic: pcic0 already exists; skipping it sio: sio0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0: Option ROM at iomem 0xc-0xcbfff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 IP Filter: v3.4.20 initialized. Default = pass all, Logging = enabled acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ACPI-0294: *** Error: Method execution failed, AE_AML_REGION_LIMIT ACPI-0294: *** Error: Method execution failed, AE_AML_REGION_LIMIT ad0: 14403MB FUJITSU MHM2150AT [29264/16/63] at ata0-master UDMA66 acd0: DVD-ROM TOSHIBA DVD-ROM SD-C2502 at ata1-master PIO4 Mounting root from ufs:/dev/ad0s2a ACPI-0294: *** Error: Method execution failed, AE_AML_REGION_LIMIT ... The system is a Gericom Webboy notebook with a SiS630 chipset. Playing around with the BIOS parameters seems not to
/dev/rtc not configured message when starting VMWare2 on -current
Hi, since many weeks I get /dev/rtc: device not configured in -current when I start VMWare2. The VMWare2 port works fine otherwise. Yes, rtc-2001.09.16.1 is installed, and the module is loaded during startup. -- Regards, Georg. 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: Making bootable recovery CD using cdboot/loader fails
On 05-Feb-02 Michael Reifenberger wrote: On Mon, 4 Feb 2002, John Baldwin wrote: Date: Mon, 04 Feb 2002 18:47:25 -0500 (EST) From: John Baldwin [EMAIL PROTECTED] To: Michael Reifenberger [EMAIL PROTECTED] Cc: FreeBSD-Current [EMAIL PROTECTED] Subject: RE: Making bootable recovery CD using cdboot/loader fails ... and let mkisofs create its own boot.catalog. If you do that instead of creating one yourself does it work any better? If not, then you can revert the revisions that turned off all the debugging output, hook up a serial console on COM1, and prepare to be spammed with lots of debug output. :) Doesnt matter who creates boot.catalog. Same Sysmptom. But its not cdboot which freezes. Its the loader after showing: ... loader Revision... (root@nihil, ...) ... And then a few rotating -\|/ (serching or loading loader.conf, kernel, ?) Then silence. Hmm. Is your loader completely up to date? Does it have a BIOS CD device cd0 in the output prior to that line? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Performance of -current vs -stable
On Thu, 7 Feb 2002 19:08:07 +0100 Wilko Bulte [EMAIL PROTECTED] wrote: On Thu, Feb 07, 2002 at 10:15:02AM +0100, Cejka Rudolf wrote: I'm just looking for a basic idea of what other people have been seeing for performance when they run current. There is another common source of confusion: If anybody has IDE disks, write-caching is enabled by default in -stable, but disabled in -current. I don't think that is true anymore. -stable has WC enabled as well. -STABLE has it enabled indeed, but -CURRENT does not (afaik). Read what he said. :-) -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands 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: current.freebsd.org down?
--ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 07, 2002 at 04:44:36PM +0100, Miguel Mendez wrote: Hi, =20 I know this is probably offtopic but is there any problem with=20 current.freebsd.org at the moment? I've been unable to log in for almost = an=20 hour, the ftp daemon is up, it just doesn't allow me in and I was about t= o=20 load -CURRENT on my laptop. =20 Any idea? =20 It does seem to be having problems. In the interim, you can use snapshots.jp.freebsd.org... --=20 Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: FreeBSD: The Power To Serve iEYEARECAAYFAjxiobgACgkQObaG4P6BelBAbwCghAdvjcqlbhuCigI5Rg0Lqtdr wpMAoJN3+ZpCDt7VAldOzVB3YX+nnpCY =cqXV -END PGP SIGNATURE- --ZPt4rx8FFjLCG7dd-- 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: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 10:35:41AM -0800, David O'Brien wrote: On Thu, Feb 07, 2002 at 07:29:57PM +0100, Wilko Bulte wrote: - is GCC3 also better on Alpha as far as correctness of the generated code goes? Or is that what you mean by bad optimised code ? We shall see. OK. 8-) - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than on x86. Do you have any idea how gcc3 does in this respect? 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. Thanks. So it is the code generator itself, I always thought it would be the optimiser that needs more time to do a decent job on a RISC. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands 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: gcc3.x issues
On Thu, Feb 07, 2002 at 01:30:22PM -0500, Nat Lanza wrote: Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. Yes there is. Earlier on in the thread I would have used your language. But at this point we are deep in a thread in which I've explained the issues and many people don't seem to be listening. Thus you get the language showing my frustration. Sorry I'm only human. 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
I've committed both the kernel diff and a libkvm diff that seems to work for me here. can you check it with the new -current again ? On Wed, 6 Feb 2002, Andrew Gallatin wrote: Jake Burkholder writes: 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 */ Bingo! Thanks.. I haven't done any alpha assembler in nearly a year.. Julian -- you need to add this to your diff: Index: alpha/alpha/locore.s === RCS file: /home/ncvs/src/sys/alpha/alpha/locore.s,v retrieving revision 1.20 diff -u -r1.20 locore.s --- alpha/alpha/locore.s 11 Dec 2001 23:33:38 - 1.20 +++ alpha/alpha/locore.s 7 Feb 2002 01:05:10 - @@ -119,7 +119,7 @@ /* * Switch to proc0's PCB. */ - ldq t0,thread0 /* get phys addr of pcb */ + lda t0,thread0 ldq a0,TD_MD_PCBPADDR(t0) SWITCH_CONTEXT Buildworld fails in libkvm with the first diff... I assume you're aware of this? /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:263: structure has no member named `p_thread' /usr/src/lib/libkvm/kvm_proc.c:264: structure has no member named `p_thread' ... I'm no seeing a hang when sync'ing disks, but this might just be a -current'ism. Cheers, Drew 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: /dev/rtc not configured message when starting VMWare2 on -current
Re: Re: /dev/rtc not configured message when starting VMWare2 on -current
In article [EMAIL PROTECTED],
Munehiro Matsuda [EMAIL PROTECTED] wrote:
I have a hack^Wpatch that should fix your problem.
I think you need to prevent returning the value of uninitialized
variable (``error'') when no error should be returned.
How about following patch? (just added error = 0; line)
Index: rtc.c
===
RCS file: /export/cvsup/cvs/ports/emulators/rtc/files/rtc.c,v
retrieving revision 1.6
diff -u -r1.6 rtc.c
--- rtc.c 16 Sep 2001 07:05:18 - 1.6
+++ rtc.c 9 Feb 2002 17:54:44 -
@@ -266,10 +266,32 @@
{
int error;
+#if __FreeBSD_version = 500023
+dev_t dev;
+struct rtc_softc *sc;
+
+ if (rtc_sc!=NULL)
+ return (EINVAL);
+
+ dev = make_dev(rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0644, DEVICE_NAME);
+ if (dev==NULL)
+ return (EINVAL);
+
+ MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
+ if (sc==NULL)
+ return (EINVAL);
+
+ bzero(sc, sizeof(*sc));
+ rtc_sc = sc;
+ dev-si_drv1 = sc; /* Link together */
+ sc-dev = dev;
+ error = 0;
+#else
error = cdevsw_add(rtc_cdevsw);
if (error)
return error;
+#endif
return error;
}
--
$B$5$M$r(B (SANETO Takanori) // [$BqL#(B] $BK\6H$r$9$k$3$H(B //
$B!(B //Bonjour Chapeau //
URL:mailto:[EMAIL PROTECTED] // [$BK\6H(B] $BqL#$KAv$k$3$H(B //
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: gcc3.x issues
On Thu, Feb 07, 2002 at 09:40:31AM -0800, Joe Kelsey wrote: David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. No it is not. If you were a committer you would get the same answer from me. You are expecting me (or someone else) to go to a lot of trouble to do something. Yet it seems you have not investigated how much work it would take. So this is the typical: I don't see the need for this and do not want to do the work needed to do this. However, you are free to do the desired work yourself and also show everyone else it can be done (and maybe easily done). It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. I have given answers in other emails. Now it is your turn. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. Helpful? I do not think so -- because doing that is VERY MUCH NOT SUPPORTED, nor something we really want people doing because many of know all the pairals(sp?) that will come of it. This is not only a FreeBSD-thing. Linux systems do not support you taking any random C compiler (or even GCC) and compiling a working Linux kernel with it. If you have a need for a compiler different than the one bundled with your Linux distribution, you are expected to install it in /usr/local (or your favorite non-/usr/bin place). David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Thanks for your helpful and pleasant comments David. And people wonder why I hate maintaining FreeBSD's GCC and have dropped maintenance of it. (and why many committers are feeling very burnt out by users right now) My current GCC 3.1 work is purely because it is needed for work I am interested in doing -- porting to sparc64, StrongARM, and AMD x86-64. After I am done with the GCC 3.1 work I am doing, you are more than welcomed to become a committer and maintain GCC for us all. Or you can pay me a reasonable salary and then I'll do your every GCC wish. -- -- David ([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: Where to find docs on newbus vs. cardbus vs. newcard
In message: [EMAIL PROTECTED] Miguel Mendez [EMAIL PROTECTED] writes: : So, in your opinion, how hard would it be to MFC from a recent -CURRENT : to 4.5-RELEASE? More or less importing the stuff and little fixing or is : a major rewrite of some part needed? Because as it seems that no one is : going to do it any time soon I've put it in my TODO list, along with : other stuff and was just wondering if it's relativitely easy or too much : for a junior kernel hacker. It isn't a huge effort conceptutally, but there is a lot of infrastructure that CardBus depends on that isn't in -stable or only partially MFC'd. If someone wanted to start cranking on it, they could get it done in a few weeks worth of work. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Not committing WARNS settings...
John Hay [EMAIL PROTECTED] writes: Let me hijack this a little. How many of you WARNS= adding people consider different compile/code paths than the one your machine exercise? For instance the one make release will exercise? The WARNS=1 in libexec/Makefile.inc breaks make release because telnetd is then compiled, but it isn't warning free. This is a good reason why non-zero WARNS should only be set in leaf Makefiles. IMO, this is a good reason to not have WARNS contain -Werror at this time. NO_WERROR is a good way to fix this (again IMO). I see a great need to let warnings hang out, and in an ideal world I see an need for (new) warnings to break things. I see no need for warnings to hold back a project as important as GCC3, and NO_WERROR is the cleanest solution. I do not expect others to agree with (or like) this. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn 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
On Wed, Feb 06, 2002 at 06:54:22PM -0800, Terry Lambert wrote: Julian Elischer wrote: how about a port that uses the installed sources together with some uploaded parts to 'reconstitute' gcj as if it had been compiled wit the rest of the system. FreeBSD does a fairly evil thing: it takes the compiler source code post-config instead of pre-config. I do not know what this means. I import [into contrib/] the bits before 'configure' has been run. I put various bits output by 'configure' in the build directory (ie, where the bmake Makefile is). It's really an incredibly bad idea to import *after* a config instead of before. What peice of software have we done this to? -- -- David ([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: Performance of -current vs -stable
On 6 Feb, Garance A Drosihn wrote: Anything else I should check? I realize there's about a million differences between the two branches, and there might also be something about my machine's setup which is a major culprit here. I'm just looking for a basic idea of what other people have been seeing for performance when they run current. # ll /etc/malloc.conf lrwx-- 1 root wheel 2B Aug 18 21:47 /etc/malloc.conf@ - aj Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 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: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: The bad ivar request (4) message does *not*?come from the ATA driver, you must have something else that is ruining your day... Does it boot if you take out the promise board ? I was in a hurry yesterday and let the kernel compile w/o the ata driver while being under the shower. Without the ata driver it does boot. Just wanted to let you know. I'll take the Promise out when I got some more time (latest friday evening). Hmm, I need alot more info the, board chipset, what exact Promise controller etc etc, and of cause the usual dmesg -Søren 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: How about gcj? (Re: Not committing WARNS settings...)
On Wed, Feb 06, 2002 at 01:05:16PM -0500, Mikhail Teterin wrote: Uh, NO! It is not needed by the base system. We really do not want to turn on all the support libs, etc.. that would be needed with this. There is a reason the gcc30 port takes 25 minutes to compile on a fast 1.2 GHz Athlon. That's the thing. gcc30 port, essentially, installs a copy of the compiler already available as part of the base. No it doesn't. 3.0.3 is a very different compiler from 2.95.3. But the base is missing gcj (the port does too for now), so one would be forced to add the port. And the base system does not NEED a java compiler. Can we have those installed, at least, to ease the work of the future porter? Nope. 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: Support for atapi cdrw as scsi in -current?
Garrett Wollman wrote: On Sat, 02 Feb 2002 20:10:20 +, [EMAIL PROTECTED] said: I noticed a patch on freebsd-scsi a while back that added a not very complete form of atapi as scsi support to the freebsd kernel. Are there plans to complete this and add it to -current sometime before -current turns into 5.0-RELEASE? Thanks for any information. I've been using it somewhat actively in the past week or so in -current. The patch as it exists needs a few changes to fit in current -current. $ camcontrol devlist TDK CDRW241040B 57S4 at scbus0 target 0 lun 0 (cd0,pass0) LITEON CD-ROM LTN526D YSR5 at scbus0 target 1 lun 0 (cd1,pass1) I don't think that ATAPICAM works well enough to use it entirely in place of the atapi-cd driver; for example, I get the following errors: atapicam0: READ_DISK_INFO - ILLEGAL REQUEST asc=0x20 ascq=0x00 error=0x04 atapicam0: READ_TOC - ILLEGAL REQUEST asc=0x24 ascq=0x00 error=0x04 However, it works well-enough to run cdrdao, which is what mattered to me, for both reading and writing on both of the afore-mentioned ATAPI devices. -GAWollman Is there a place where I can find this updated patch which will work for me in the current -current? Thanks. Jordan 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: Performance of -current vs -stable
At Wed, 06 Feb 2002 23:33:14 -0500 (EST), John Baldwin wrote: [...] I guess. Note that you can use a loader tunable 'debug.witness_watch' to turn witness off from the loader. If it's set to 0 witness won't be used even if it's compiled into the kernel (just a general FYI, witness(4) documents this as well). Nice feature, thanks for the hint. I can't find it documented in witness(4), however: hunter# grep -i watch /usr/src/share/man/man4/witness.4 hunter# CVSup is from Feb 6. -- Regards, Georg. 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
World breakage (lib/libroken)
Is this the problem on my local environment only? === libroken awk -f /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.h.in make-roken.c awk: /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk:18: warning: escape sequence `\#' treated as plain `#' cc -O -mpentiumpro -pipe -march=pentiumpro -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I/usr/obj/usr/src/kerberos5/lib/libroken -Wall -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../include -DHAVE_CONFIG_H -DINET6 -I/usr/obj/usr/src/i386/usr/include make-roken.c -o make-roken /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot find -lc *** Error code 1 Stop in /usr/src/kerberos5/lib/libroken. *** Error code 1 -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VMware Workstation 3.0 For FreeBSD
Does anyone know if there is an active effort to port VMware Workstation 3.0 for Linux to run under FreeBSD ?? Version 2 of Workstation is no longer avaiable it seems... Thanks, Glenn G. Glenn Gombert [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
Proxim Farallon usb ethernet support
Hi I just got the FARALLON PN796 (Proxim) usb ethernet
adapter working with my current thought I should post the
2 lines i needed to add to make it working to the
mailing list
/usr/src/sys/dev/usb
in file if_aue.c
Static struct aue_type aue_devs[] = {
{ USB_VENDOR_ADMTEK,USB_PRODUCT_ADMTEK_PEGASUS, 0 },
{ USB_VENDOR_ADMTEK, USB_PRODUCT_ADMTEK_FARALLON_PN796, PII},
{ USB_VENDOR_BILLIONTON,USB_PRODUCT_BILLIONTON_USB100,0 },
{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUATX1, 0 },
{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUATX5, 0 },
{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUA2TX5,PII },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DSB650, LSYS },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DSB650TX, LSYS },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DSB650TX_PNA, 0 },
{ USB_VENDOR_SMC, USB_PRODUCT_SMC_2202USB, 0 },
{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB100TX, LSYS },
{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB10TA, LSYS },
{ USB_VENDOR_LINKSYS, USB_PRODUCT_LINKSYS_USB10TX2, LSYS },
{ USB_VENDOR_COREGA,USB_PRODUCT_COREGA_FETHER_USB_TX, 0 },
{ USB_VENDOR_KINGSTON, USB_PRODUCT_KINGSTON_KNU101TX,0 },
{ USB_VENDOR_ABOCOM,USB_PRODUCT_DLINK_DSB650TX_PNA, 0 },
{ USB_VENDOR_IODATA,USB_PRODUCT_IODATA_USBETTX, 0 },
{ USB_VENDOR_ACCTON,USB_PRODUCT_ACCTON_USB320_EC, 0 },
{ 0, 0, 0 }
};
I just added the FARALLON line in this structure
in file usbdevs
/* ADMtek products */
product ADMTEK PEGASUS 0x0986 AN986 USB Ethernet adapter
product ADMTEK FARALLON_PN796 0x8511 NetLine 10/100 USB Ethernet Adapter (ADMtek
chipset AN986) by proxim
here i have just added the FARALLON line again which is i believe line #382
the line no. shouldnt matter tho.
Thats it
I realise that i should post a diff but i made the changes directly in these
files and will need to get the unchanged version from the cvs again to
produce a diff and its not too much change.
can someone please commit this change to the main source tree
also if someone is using this right out of this posting to get the adapter
working please dont forget to do
(after adding these 2 lines in the required files)
prompt# cd /usr/src/sys/dev/usb
prompt# make -f Makefile.usbdevs all
(before remaking and reinstalling the kernel)
Have fun
Saurabh Gupta
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
new page cache for linux
Just thought I'd bring your attention to the new radix tree page cache in use by linux - I dont know what freebsd do at the moment, but it looks like it will improve scalability (you guys might want to use the idea). Anyway, heres the link: http://lwn.net/2002/0207/kernel.php3 -- It's not reality or how you perceive things that's important, it's what you're taking for it. 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: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 12:39:35AM -0500, Mikhail Teterin wrote: I believe, what I see. And that is, FreeBSD includes both -- gdb and gcc, but only one libbfd, thankfully. And I want to be able to use that same libbfd for my own development and for porting of other compilers and tools. GCC does not use bfd -- it does not need to as GCC spits out ASM code, not machine code. Arguing that Binutils and GDB uses the same bfd is a more valid argument. I would like to point out there have been some minor issues with using the bfd from Binutils 2.11.2 with the old GDB 4.x. GCC and GDB does both use libiberty. You will notice that GCC uses its own copy (the files are piled into the src/contrib/gcc directory with the rest of the GCC code). And GDB uses a different copy. This IS the problem I'm trying to solve. WHY do you want to cause this problem of non-matching bits? So they'll be matched and fixed, leading to a better world 8-) I don't know how many times I've said this and why you aren't listening. THEY CANNOT BE MATCHED. Go ask the FSF developers. They will tell you the same thing -- that is why each package's CVS repo maintains its own copy. The FSF developers will tell you using the copy of libiberty is NOT SUPPORTED by them. Evidently, this does not prevent the FreeBSD project from using the same libbfd for its gdb and gcc. Even though, the presense of both Again, see above. This is how little you know of the problem. GCC DOES NOT USE ANY BFD CODE. /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a and /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a is somewhat mistifying to me, but I'm sure they are built from the same source. *SIGH* This also shows how little you know of the make buildworld process. Before you start suggesting the things you have, you really need to start treating ``make buildworld'' as something other than a black box. ``make buildworld'' compiles two copies of some things because of bootstrapping [and cross compiling] issues. No I want to drop Alpha because no one cares about it and not just the compiler, but much more often kernel, WARNS, and other changes break the Alpha. Alright, so you do find it nightmarish. *sigh* NO! Stop putting words in my mouth. I find it extremely ANNOYING. nightmarish != annoying That is NOT a problem. That is just some mis-founded goal with no basis of purpose. Well, than nothing is a problem. Which problem is FreeBSD's very existence trying to solve, huh? Sure some things are a problem. GCC 2.95 generates bad optimized code on the Alpha. Upgrading to 3.1 will fix [some of] this. We cannot do a make buildworld of -CURRENT code on a 4.1 system because of our addition of __FBSDID(). We cannot support 4 GB RAM in any machine (Peter Wemm is working on this); and people need to be able to. Those are real problems. FEH!! You are going to patch the nightmare (yes I will use that term to describe this) autoconf and autoMake bits that come with the GNU tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY THE ORIGINAL AUTHOR INTENDED THEM TO BE. Yes, I very well might. Or, may be, I'll introduce Makefiles of my own -- Something already done for the C compiler and all the other GNU tools in the base, BTW. Submit tested patches and we'll talk farther. But I've seen you have only thought about this off the top of your head with no investigation into the issues. -- -- David ([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: PAM Error
On Mon, Feb 11, 2002 at 12:04:53PM +, [EMAIL PROTECTED] wrote: Yesterday I tried to use SWAT for the first time since the PAM configs were moved from /etc/pam.conf and I'm getting the following error: Feb 6 22:54:05 galaxy swat: PAM _pam_init_handlers: could not open /etc/pam.conf What do I need to do to fix this? Recompile the app. I'm guessing it is linked statically, so is not picking up the latest libpam. Though that sounds logical to me too, I've had the same errors pop up using a self-compiled 'cups'. I haven't had time to try to chase what's going on. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Alfred Perlstein wrote: Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. A lot of us are punch-drunk with the upcoming BSDCon next week, too. The flipness of the comments aside (don't hold people's personalities against them, Joe), doing a patch would be a way to handle this. I offered to help with the structural stuff, but not write the patch itself, since I'm not really a great follower of -current, and patches not against current are frequently ignored by committers because they don't represent the latest, greatest thing. I still haven't figured out how to hande the dichotomy of most volunteer work occurring in -current, while most commercial work on FreeBSD occurs in the last RELEASE, or, to a lesser extent, -stable. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. It's not a trivial problem to fix, either. It's tangled up in the make release process, which is two measures of intent down the road from the question that Joe asked. I volunteered structural help (which would probably be mostly just explaqining the status quo, so that anyone writing the code could avoid breakage), and David volunteered to do reviews of the resulting patches, which is tantamount to volunteering to commit them, so long as they aren't incredibly offensive. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. I don't think Joe is debating; I think he wants to have a meta-discussion about what the problem space looks like, before submitting patches that light up his little corner, and dark up everything else. Every time these tools issues come up, it really boils down to the GNU build process sucking pretty hard, not being very seperable, and, in general, expecting to be installed in isolation as an add on, rather than as an integral part of a larger whole. You really can't hold David responsible for that, it's a vendor problem that doesn't look to be solved any time soon. USL is the same way: they have some incredibly smart stuff, but interacting with them is like sharing a prison cell with a 500 pound man named Bubba, even if you are their employee. Maybe especially if you are their employee... guards have to see Bubba every day of their career, while short timers have the promise that their Bubba days will soon be over. 8-). It's also not obvious that the DESTDIR phenomenon exists with compilers from ports, until you get going and it bites you on the arse. David is the compiler maintainer, so it's second nature to him to turn around and smack problems as they are preparing to bite. 8-). The rest of us end up with rather more tender backsides... 8-) 8-). I don't think that this is going to be resolved right before BSDCon, when everyone is feeling incredible time pressure, and those who aren't are having the stress rubbed off onto them by the others. I also don't think that this is a shallow problem that's subject to easy dismissal. But if it's a choice between have some, everything works, and have all, some works, the everything works wins hands down. -- Terry 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: new page cache for linux
Nero wrote: Just thought I'd bring your attention to the new radix tree page cache in use by linux - I dont know what freebsd do at the moment, but it looks like it will improve scalability (you guys might want to use the idea). Anyway, heres the link: http://lwn.net/2002/0207/kernel.php3 You should look at how FreeBSD already handles this problem. Note also that as physical memory approaches real memory in size, the sparseness of the mapping goes to zero. -- Terry 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: How about gcj? (Re: Not committing WARNS settings...)
David O'Brien wrote: 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. I don't think this is definative. I think the problem is that the GCC code for the code generation on these platforms is not beaten on very heavily by people who care about it. We see the same effect in FreeBSD from time to time, when the Alpha build is broken for one reason or another by a supposedly platform independent change which is really an x86-ism. I suspect code generation for these platforms will be slow, but that code generation for the 64 bit Intel and AMD processors will be a lot faster. The Alpha stuff is also hampered by the instruction reordering, which is another pass, but that doesn't fully account for the slowness of the code (IMO). Probably, it could be made much faster by someone who cared about it, and who has a profile in hand. Personally, I was happy with my 1 MHz 6502, so as far as I see it, everything runs blazingly fast, even though modern programmers fail on cycle squezing by multiple orders of magnitude most times. 8-). -- Terry 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
Julian Elischer writes: I've committed both the kernel diff and a libkvm diff that seems to work for me here. can you check it with the new -current again ? World breakage on alpha: usr/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c: In function `set_proc_cmd': /usr/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c:393: structure has no member named `p_thread' *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/gdb. *** Error code 1 The following diff fixes it, but isn't likely to be correct. How should kvm be finding the pcb based on the process? Drew Index: kvm-fbsd.c === RCS file: /home/ncvs/src/gnu/usr.bin/binutils/gdb/alpha/kvm-fbsd.c,v retrieving revision 1.6 diff -u -r1.6 kvm-fbsd.c --- kvm-fbsd.c 13 Oct 2001 04:38:46 - 1.6 +++ kvm-fbsd.c 8 Feb 2002 01:39:32 - @@ -390,7 +390,7 @@ addr = (CORE_ADDR)parse_and_eval_address(arg); /* Read the PCB address in proc structure. */ - addr += (int) ((struct proc *)0)-p_thread.td_pcb; + addr += (int) ((struct proc *)0)-p_xxthread.td_pcb; if (kvread(addr, val)) error(cannot read pcb ptr); 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: Not committing WARNS settings...
All David has to do is set WARNS=0 or NO_WERROR=1 in bsd.sys.mk or /etc/defaults/make.conf temporarily when he tests and commits the changeover, and he'll sidestep all the problems. There's no need to impose restrictions on the activities of other committers. It's really not a big deal, IMO. Kris Let me hijack this a little. How many of you WARNS= adding people consider different compile/code paths than the one your machine exercise? For instance the one make release will exercise? The WARNS=1 in libexec/Makefile.inc breaks make release because telnetd is then compiled, but it isn't warning free. John -- John Hay -- [EMAIL PROTECTED] / [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: ucred for threads
Julian Elischer wrote:
In the KSE code I have:
in trap(), and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
THis is actually not dependent on KSE (though I originally needed it
for KSE I have since decided that it would be a good idea anyhow).
Do those who deal in ucreds (probably jhb and Robert W)
agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
patches a bit more :-)
You can't have a process with a thread without a ucred, right?
If so, then the idea is sound, but the code is broken.
In the case that they are not equal, you free it, null
the pointer, and don't allocate a replacement.
What is the default state of td-td_ucred?
In theory, it should be initialized on creation, and then
left initialized (you are effectively lazy binding the cred
references).
Since the reference count is positive in both cases, an
unlocked pointer comparison is fine. In the case where
there is a race on a credential change in the unlocked
value, that race exists in the calling code, anyway. The
failure case in a change for-to instead of to-from is
also safe, since the pointers will be inequal during the
update, the lock will be held during the update, so the
subsequent release and regrab with the increment never
dropping below 1.
If that's the case, then the code should be:
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
}
td-td_ucred = crhold(p-p_ucred);
PROC_UNLOCK(p);
}
Is a thread lock required? I think it's guaranteed to
be non-reentrant, so the answer should be no...
-- Terry
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: MODULES_WITH_WORLD=true means no modules?
On Thu, Feb 07, 2002 at 09:57:47PM +0100, BOUWSMA Beery wrote: Maybe... I've changed my /etc/make.conf from the default, to be MODULES_WITH_WORLD=true # do not build modules when building kernel ^^^ ...you need to read the option you enabled? since I find myself often building new kernels (plus identical modules) without updating the rest of the source, taking extra time. Regards. -- wca 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: MODULES_WITH_WORLD=true means no modules?
BOUWSMA Beery [EMAIL PROTECTED] writes: In order to get /boot/kernel/ populated with modules, either one needs to installworld again, or use one of the targets to install only modules, I guess. The recommended build sequence is: # make buildworld # make buildkernel # make installkernel # make installworld DES -- Dag-Erling Smorgrav - [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: ucred for threads
On Thu, 7 Feb 2002, Terry Lambert wrote:
Julian Elischer wrote:
In the KSE code I have:
in trap(), and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
THis is actually not dependent on KSE (though I originally needed it
for KSE I have since decided that it would be a good idea anyhow).
Do those who deal in ucreds (probably jhb and Robert W)
agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
patches a bit more :-)
You can't have a process with a thread without a ucred, right?
yes.. well in booting yuo can have a null ucred. ( I know,s
I've hit it), but in general you are correct.
If so, then the idea is sound, but the code is broken.
In the case that they are not equal, you free it, null
the pointer, and don't allocate a replacement.
ummm yes I do, assuming that there is one to allocate...
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
What is the default state of td-td_ucred?
on creation, NULL followed very rapidly with being set to
p-p_ucred. (via crhold)
In theory, it should be initialized on creation, and then
left initialized (you are effectively lazy binding the cred
references).
yes..
Since the reference count is positive in both cases, an
unlocked pointer comparison is fine. In the case where
there is a race on a credential change in the unlocked
value, that race exists in the calling code, anyway. The
failure case in a change for-to instead of to-from is
also safe, since the pointers will be inequal during the
update, the lock will be held during the update, so the
subsequent release and regrab with the increment never
dropping below 1.
If that's the case, then the code should be:
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
}
without the if it crashes in boot sometimes.
(this may not be true right now but was during my testing of
the KSE kernel)
td-td_ucred = crhold(p-p_ucred);
PROC_UNLOCK(p);
}
Is a thread lock required? I think it's guaranteed to
be non-reentrant, so the answer should be no...
-- Terry
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: Binutils fixed in -current?
first time only: cd /usr/src/gnu/usr.bin/binutils cvs -qR up -D '1/27/2002 11:55 UTC' cd /usr/src/contrib/binutils cvs -qR up -D '1/27/2002 11:55 UTC' I thought this sounded like a great idea, but it gives me In file included from /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf32-i386.c:2159: elf32-target.h:605: `bfd_elf32_bfd_merge_sections' undeclared here (not in a function) elf32-target.h:605: initializer element is not constant elf32-target.h:605: (near initialization for `bfd_elf32_i386_vec._bfd_merge_sections') -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin 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: Where to find docs on newbus vs. cardbus vs. newcard
In message: [EMAIL PROTECTED]
j mckitrick [EMAIL PROTECTED] writes:
: | CardBus:
: | PCMCIA standard for PCI cards in the PC Card form factor.
:
: I was pretty close on this as well. These are specifically 32-bit
: cards, correct?
Yes.
: | dev/{pccard,pcic,exca,cardbus,pccbb}/*. I'm in the process of fixing
: | bugs in this code base as well as removing redundant code and
: | expanding support for more bridges and client devieces. This is what
: | I've been calling NEWCARD.
:
: Ah, this was the part I got mixed up. I thought Newcard was already up
: and running with the last iteration of changes you made (remember me and
: ToPIC on Toshiba? ;-) I thought this was already in -stable.
NEWCARD is up and running, but has issues for some cards, bridges and
lacks some useful features.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, 2002-02-07 at 12:59, Alfred Perlstein wrote: These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. --nat 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: ucred for threads
Julian Elischer wrote:
yes.. well in booting yuo can have a null ucred. ( I know,s
I've hit it), but in general you are correct.
[ ... ]
What is the default state of td-td_ucred?
on creation, NULL followed very rapidly with being set to
p-p_ucred. (via crhold)
Non-problem, then.
If that's the case, then the code should be:
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
}
without the if it crashes in boot sometimes.
(this may not be true right now but was during my testing of
the KSE kernel)
The place to fix this is by setting up a default reference to
a root/boot ucred, I think, for use by the initial process
template.
What are the consequences, if any, of me having removed the
setting the thing to NULL, during boot? I guess that it
would leave the thread cred uninitialized. Obviously, the
problem with your crash is in the crhold( NULL). 8-).
It seems to me that the test would leave threads with NULL
ucreds around as well, and just complicate things later.
Is there a reason you can't set up an initial ucred?
-- Terry
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: ucred for threads
Terry I don't have time to work on it now, but if you would like to take a
-current system
and apply the threading KSE diffs from my web page,
then maybe you can investigate whether I really ned the if clause or
not..
I don't have time now to go back to it for a while
On Thu, 7 Feb 2002, Terry Lambert wrote:
Julian Elischer wrote:
yes.. well in booting yuo can have a null ucred. ( I know,s
I've hit it), but in general you are correct.
[ ... ]
What is the default state of td-td_ucred?
on creation, NULL followed very rapidly with being set to
p-p_ucred. (via crhold)
Non-problem, then.
If that's the case, then the code should be:
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
}
without the if it crashes in boot sometimes.
(this may not be true right now but was during my testing of
the KSE kernel)
The place to fix this is by setting up a default reference to
a root/boot ucred, I think, for use by the initial process
template.
What are the consequences, if any, of me having removed the
setting the thing to NULL, during boot? I guess that it
would leave the thread cred uninitialized. Obviously, the
problem with your crash is in the crhold( NULL). 8-).
It seems to me that the test would leave threads with NULL
ucreds around as well, and just complicate things later.
Is there a reason you can't set up an initial ucred?
-- Terry
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: gcc3.x issues
On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: So what? When I install gcc on a non-native platform (such as HP-UX or Solaris), Again, WHAT IS THE PROBLEM you are trying to solve? Just laziness of not being willing to type ``pkg_add -r gcc30'' or ``pkg_add -r gcc31''? Because it installs in non-default places. It creates duplicates of gcc, all libraries and is a potential source of error and confusion over what is the *real* supported compiler. Uh, sorry, pkg_add -r gcc30 will install the software in _exactaly_ the same place as you would get GCC on one of your non-native platforms. You will also get a duplicate C compiler (besides acc [HPUX], or cc [Solaris]). So why does all this bother you on FreeBSD and not those platforms? -- -- David ([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: anon ftp access at current
No, the NFS server it depends on is down. Still working on getting it back up. I am trying to install one of the -current snapshots, but current.freebsd.org doesn't seem to want to let me log in as anonymous (some problem saying it cannot set guest access). Has the procedure changed to get -current? thanks -j 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
time breakage.
phk, is this you? c++ -g -O -pipe -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/include -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc -o new.o In file included from /usr/include/sys/stat.h:50, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include/posix.h:22, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc:24: /usr/include/sys/time.h: In function `void timespec2bintime(timespec *, bintime *)': /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned /usr/include/sys/time.h: In function `void timeval2bintime(timeval *, bintime *)': /usr/include/sys/time.h:153: integer constant out of range /usr/include/sys/time.h:153: warning: decimal integer constant is so large that it is unsigned *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/libs/libgroff. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/libs. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 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: Support for atapi cdrw as scsi in -current?
On Thu, Feb 07, 2002 at 12:38 +0100, S=F8ren Schmidt wrote: =20 [ snipped ATAPI - SCSI conversion ] =20 Doesn't burncd work for you on -current ? Well, since you asked about it ... :) Back in June I told you about the progress meter bogus values in burncd and provided a patch in a private message ([EMAIL PROTECTED]) to you. After some silence I opened PR bin/30893 ([PATCH] burncd(8) progress meter) in September. This one got closed in December with a Fixed, but done differently than this patch. comment. Since I haven't seen any such fix and it was not fixed some time after your closing the PR I followed up to it in January, asking you to reopen PR bin/30893 or to apply its fix or to fix the problem in another way. The bug (talking about a few million percent completion of the job, while one hundred should suffice) is still there. Can you have one more look at http://www.freebsd.org/cgi/query-pr.cgi?pr=3D30893 please? Especially the simple and straight fix in its opening. This shouldn't take eight months to wait for or doing hard fights to get it fixed ... :( (I know you were busy back then changing jobs and moving, but the later closing wasn't appropriate without a fix.) virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s get gpg key [EMAIL PROTECTED] --=20 If you don't understand or are scared by any of the above ask your parents or an adult to help you. 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: possible world breakage warning..
On Thu, 7 Feb 2002, Julian Elischer wrote:
there may be greakage in gdb due th the commit today..
I'm waiting for my buildworld to get sround to it so I can test my fix..
julian
the fix I am looking at testing is:
Index: i386/kvm-fbsd.c
===
RCS file: /usr/home/cvs/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c,v
retrieving revision 1.33
diff -u -r1.33 kvm-fbsd.c
--- i386/kvm-fbsd.c 2001/12/12 21:15:30 1.33
+++ i386/kvm-fbsd.c 2002/02/08 02:36:43
@@ -387,9 +387,12 @@
int regno;
{
struct pcb *pcbaddr;
+ struct thread *td;
/* find the pcb for the current process */
- if (cur_proc == NULL || kvread (cur_proc-p_thread.td_pcb,
pcbaddr)) /* XXXKSE */
+ if (cur_proc == NULL ||
+ kvread (TAILQ_FIRST(cur_proc-p_threads), td) || /* XXXKSE */
+ kvread (td-td_pcb, pcbaddr)) /* XXXKSE */
error (cannot read u area ptr for proc at %#x, cur_proc);
if (read_pcb (core_kd, (CORE_ADDR)pcbaddr) 0)
error (cannot read pcb at %#x, pcbaddr);
in the gdb sources but haven't managed to test it yet.
due to other breakages..
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
Minor things: swi_net: unregistered isr number
If this might be of interest: kernel built 07.feb at boot time... | Doing initial network setup: hostname. * swi_net: unregistered isr number: 18. | xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 | options=3rxcsum,txcsum [...] This is (probably) the dhclient being run at this time, maybe. Should I be bothered by the following? unknown: IBM Enhanced (101/102-key) KC can't assign resources unknown: Microsoft PS/2 Mouse can't assign resources unknown: 16550 compatible COM device can't assign resources unknown: 16550 compatible COM device can't assign resources unknown: LPT printer port can't assign resources unknown: Floppy Controller can't assign resources this is after all of these have been detected and assigned (sio0, sio1, etc) ata3: Generic ESDI/IDE/ATA controller at port 0x36e-0x36f,0x168-0x16f irq 10 o n isa0 Where did that come from, and why don't I know about it? I know about: ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 and -stable makes no claim I have a third ata controller... machine is ancient digital venturis 575 pc thanks barry bouwsma 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
possible world breakage warning..
there may be greakage in gdb due th the commit today.. I'm waiting for my buildworld to get sround to it so I can test my fix.. 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
Re: UPDATED: For Review: sendmail 8.12.2 import into -CURRENT
On Sun, Feb 10, 2002 at 12:13:05 -0800, Gregory Neil Shapiro wrote:
http://people.freebsd.org/~gshapiro/CURRENT-8.12.2
--- lib/libmilter/Makefile~orig Sun Jan 20 13:58:03 2002
+++ lib/libmilter/Makefile Sun Jan 20 13:05:02 2002
@@ -0,0 +1,28 @@
+# $FreeBSD$
+
+MAINTAINER=[EMAIL PROTECTED]
+
+SENDMAIL_DIR=${.CURDIR}/../../contrib/sendmail
+.PATH: ${SENDMAIL_DIR}/libmilter ${SENDMAIL_DIR}/libsm
+
+CFLAGS+=-I${SENDMAIL_DIR}/src -I${SENDMAIL_DIR}/include -I.
+CFLAGS+=-DNETINET6 -DNOT_SENDMAIL -Dsm_snprintf=snprintf
+CFLAGS+=-pthread
^^
Why you add -pthread? IMHO it is needed only on program building 'ld'
phase and not in library building. See libc_r/Makefile
--
Andrey A. Chernov
http://ache.pp.ru/
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
/dev/rtc not configured message when starting VMWare2 on -current
Hi, since many weeks I get /dev/rtc: device not configured in -current when I start VMWare2. The VMWare2 port works fine otherwise. Yes, rtc-2001.09.16.1 is installed, and the module is loaded during startup. -- Regards, Georg. 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: Max size of a process in FreeBSD.
Doug White [EMAIL PROTECTED] writes: It's limited to MAXDSIZ (max data size). Not quite - the size of the data segment is limited to the value of 'limits -d', which starts out at DFLDSIZ and cannot be larger than MAXDSIZ. Likewise, the size of the stack is limited to the value of 'limits -s', which cannot be larger that MAXSSIZ. I don't think there's a limit on text size (other than total address space minus kernel address space), but a very large text segment will obviously limit the size of the data and stack segments. You can raise this up to 2GB or so, but you will eventually hit the KVM boundary. I don't recall what the KVM limit is right now, I thought it was 2GB but I think it was reduced recently ... The kernel address space used to be 256 MB in 3.x, but was bumped to 1 GB before 4.0-RELEASE. See FAQ list entry 17.15. DES -- Dag-Erling Smorgrav - [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: current.freebsd.org down?
On Thu, Feb 07, 2002 at 04:44:36PM +0100, Miguel Mendez wrote: I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? I've been unable to log in for almost an hour, the ftp daemon is up, it just doesn't allow me in and I was about to load -CURRENT on my laptop. Jordan announced recently that Qwest is upgrading the hardware and that there would be intermittent problems with the server for a certain period (a few days as I recall). Regards -- wca 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
[no subject]
list 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: How about gcj? (Re: Not committing WARNS settings...)
On Thu, Feb 07, 2002 at 07:29:57PM +0100, Wilko Bulte wrote: - is GCC3 also better on Alpha as far as correctness of the generated code goes? Or is that what you mean by bad optimised code ? We shall see. - The gcc 2.95 compiler is quite a bit slower (it appears) on Alpha than on x86. Do you have any idea how gcc3 does in this respect? 3.1 will also be slower on the Alpha. It is really an issue of the code generator. Generating x86 code on an Alpha is faster than generating [native] Alpha code. The Alpha code generator is slow. It may be that all 64 bit or RISC GCC code generation is slow -- we will see soon for the sparc64. 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: MODULES_WITH_WORLD=true means no modules?
On Thu, Feb 07, 2002 at 09:57:47PM +0100, BOUWSMA Beery wrote: I've changed my /etc/make.conf from the default, to be MODULES_WITH_WORLD=true # do not build modules when building kernel since I find myself often building new kernels (plus identical modules) without updating the rest of the source, taking extra time. You might find these targets more useful than the above: make kernel make install-kernel make reinstall-modules 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: ucred for threads
John Baldwin wrote: No, an unlocked compare is _not_ ok. What if the p_ucred pointer was changed on some other processor by another thread from this processor? I saw your response to Julian... I understand the concern, but I think it's unfounded. Let me explain. Without a lock you don't have a guarantee that that other processor's writes are visible to you. We really don't want to be using stale credentials for syscalls given the past history of race conditions involving credentials. If in the future it is deemed that getting a stale cred is an acceptable race, then this can be optimized then, but for now we had better get it right. There's stale and there's Stale. I thnk stale is OK. Here's how I see it: If there's a race between changing and using a cred in kernel space, it can only come about because of a similar race in user space. This means that if I change from cred A to cred B, there's no difference in the closure between losing the race in the kernel (and getting a stale value) and losing the race in user space (and getting a stale value). Basically, if it's an issue, then user level primitives have to be used to protect the request for the credential change. Maybe a picture would be better: Threads Creds 1 2 A B case i: setuid x--x create x case ii: setuid create x - user race lost x--x case iii: setuid x--x create x - stale FreeBSD doesn't run on just the i386 anymore, we have Alpha, ia64, and sparc64 SMP machines to deal with as well. I understand; I'm very noisy about this point myself, e.g. the recent binutils breakage that made Alpha not build at all. However, I'm not convinced that it's possible to have the kernel race be present, without a corresponding user race, which means protecting against case iii doe nothing for you, if you can still get the inversion from case ii. If, on the other hand, you have user space synchornization that guards against case ii, then the fact that the synchornization operates across the same barrier as the credential change call means that the you also protect against case iii. Are there any obvious cases that I'm just not seeing here where a case iii is possible without a case ii? -- Terry 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: time breakage.
On Fri, 8 Feb 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: phk, is this you? /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned Yes, that was me, seems like I did my buildworld test in the wrong source tree here. Thanks to peter for fixing this, and sorry for the trouble! not out of the woods yet... I'm not sure but make world still breaks for me with: off/new.cc -o new.o In file included from /usr/include/sys/stat.h:50, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include/posix.h:22, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc:24: /usr/include/sys/time.h: In function `void timespec2bintime(timespec *, bintime *)': /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned /usr/include/sys/time.h: In function `void timeval2bintime(timeval *, bintime *)': /usr/include/sys/time.h:153: integer constant out of range /usr/include/sys/time.h:153: warning: decimal integer constant is so large that it is unsigned *** Error code 1 I'm doing a make includes and will try again as it could be that it is erroneously looking in /usr/include instead of at the sources. -- 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: ThinkPad X22 PC-Card slot problem
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : From: Takanori Watanabe [EMAIL PROTECTED] : Date: Wed, 06 Feb 2002 23:16:21 +0900 : I recently installed -current to ThinkPad X22. Though it seems that : X22's PC-Card slots work fine with -stable, in -current when probing : PCICs I got following message, : : : How about disabling ACPI? If this works, it is because ACPI PCI interrupt : routing problem. : : No, disabling ACPI does not change the situation. Hmmm. This looks ugly. :-( I can't boot with acpi enabled on my Dell Inspiron 8000. I can boot with apm enabled. There are issues with routing interrupts accross PCI PCI bridges at the moment when the slots on the other side of the bridge are in the PIR table. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: time breakage.
for what it's worth, doing a make includes before the make buildworld seems to have got me going again. On Fri, 8 Feb 2002, Julian Elischer wrote: On Fri, 8 Feb 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: phk, is this you? /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned Yes, that was me, seems like I did my buildworld test in the wrong source tree here. Thanks to peter for fixing this, and sorry for the trouble! not out of the woods yet... I'm not sure but make world still breaks for me with: off/new.cc -o new.o In file included from /usr/include/sys/stat.h:50, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include/posix.h:22, from /usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/new.cc:24: /usr/include/sys/time.h: In function `void timespec2bintime(timespec *, bintime *)': /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned /usr/include/sys/time.h: In function `void timeval2bintime(timeval *, bintime *)': /usr/include/sys/time.h:153: integer constant out of range /usr/include/sys/time.h:153: warning: decimal integer constant is so large that it is unsigned *** Error code 1 I'm doing a make includes and will try again as it could be that it is erroneously looking in /usr/include instead of at the sources. -- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
I finally pulled the Promise out and it boots. Since I need it for some Windows apps on the same box I put it back in and commented some lines in ata driver regarding the detection of Promise Fasttrak controllers and it boots now w/o detecting it. This is strange, the error message you got is *not* from the ATA driver, and putting a TX2 in a system here work just fine, I'm out of ideas Well, maybe some other system/PCI code has been changed and doesn't work so well with the detection code in ata-raid.c? This would be my first guess, but I am no big programmer and I'm even less aware how it kernel internas work. To be exact, I commented stuff in ata-raid.c, ata-dma.c and ata-pci.c (everything related to device ID 0x4d68105a). And I made ar_probe to return 1 immediately. Like this I can leave the Promise in w/o getting that error. It happens on GENERIC and the configured kernel. PS booting verbose doesn't throw any usable info at all. PS2 my TX2 has BIOS 2.00 build 2 located in PCI slot 5. The mobo chipset is a VIA 694XDP. I hope this info helps. /tso __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com 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: Promise/ATA-Raid making panic in -CURRENT?
Here's the box: Asus CUV4X-D mainboard, VIA 694X, dual-capable 2x P3-933, 768MB PC133 RAM in 3 DIMM(s) Two IBM IC35L 60.1GB disks on first IDE Pioneer DVD-A05SZ on second IDE Two IBM IC35L 60.1GB on Promise Fasttrak TX2 (PDC20268/70) in RAID0 How do I dump the dmesg when it crashs into the debugger? With a current kernel from before you found it failed ? No, first time I compiled a -CURRENT. I finally pulled the Promise out and it boots. Since I need it for some Windows apps on the same box I put it back in and commented some lines in ata driver regarding the detection of Promise Fasttrak controllers and it boots now w/o detecting it. The -CURRENT kernel runs fine so far. /tso __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com 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: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: I finally pulled the Promise out and it boots. Since I need it for some Windows apps on the same box I put it back in and commented some lines in ata driver regarding the detection of Promise Fasttrak controllers and it boots now w/o detecting it. This is strange, the error message you got is *not* from the ATA driver, and putting a TX2 in a system here work just fine, I'm out of ideas -Søren 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: /dev/rtc not configured message when starting VMWare2 on
From: Georg-W Koltermann [EMAIL PROTECTED]
Date: Thu, 07 Feb 2002 11:04:22 +0100
::Hi,
::
::since many weeks I get /dev/rtc: device not configured in -current
::when I start VMWare2. The VMWare2 port works fine otherwise.
::
::Yes, rtc-2001.09.16.1 is installed, and the module is loaded during
::startup.
Hi,
I have a hack^Wpatch that should fix your problem.
Hope this helps,
Haro
=--
_ _Munehiro (haro) Matsuda
-|- /_\ |_|_| Business Incubation Dept., Kubota Corp.
/|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome
Chuo-ku Tokyo 103-8310, Japan
Tel: +81-3-3245-3318 Fax: +81-3-3245-3315
Email: [EMAIL PROTECTED]
--- ports/emulators/rtc/files/rtc.c.ctm Tue Dec 11 02:20:24 2001
+++ ports/emulators/rtc/files/rtc.c Sat Feb 9 00:23:10 2002
@@ -266,9 +266,30 @@
{
int error;
+#if __FreeBSD_version = 500023
+dev_t dev;
+struct rtc_softc *sc;
+
+ if (rtc_sc!=NULL)
+ return (EINVAL);
+
+ dev = make_dev(rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0644, DEVICE_NAME);
+ if (dev==NULL)
+ return (EINVAL);
+
+ MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
+ if (sc==NULL)
+ return (EINVAL);
+
+ bzero(sc, sizeof(*sc));
+ rtc_sc = sc;
+ dev-si_drv1 = sc; /* Link together */
+ sc-dev = dev;
+#else
error = cdevsw_add(rtc_cdevsw);
if (error)
return error;
+#endif
return error;
}
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: ucred for threads
On 08-Feb-02 Julian Elischer wrote:
As part of the KSe stuff I ended up changing ht ebehaviour of threads with
respect to their ucreds. Previously, they freed their ucred reference when
they entered user space and picked them up again when they re-entered the
kernel. It there was an AST then they re-loaded teh already freed ucred to
perform the AST. (and then freed it again, (For each AST).
Since each 'get' and free required a lock and unlock of the proc
structure, this meant that there were at least 2 locks and 2 unlocks, and
possibly many more, for the average kernel entry/exit pair.
Since the chance that the ucred on the next entry is not the same as the
thread already had on it's last kernel exit, is almiost negligible,
it makes sence to hold the ucred acress the user period an dsimply check
it agains the process's ucred on th enext entry.
In the KSE code I have:
in trap(), and syscall()
if (td-td_ucred != p-p_ucred) {
PROC_LOCK(p);
if (td-td_ucred) {
crfree(td-td_ucred);
td-td_ucred = NULL;
}
if (p-p_ucred != NULL) {
td-td_ucred = crhold(p-p_ucred);
}
PROC_UNLOCK(p);
}
THis is actually not dependent on KSE (though I originally needed it
for KSE I have since decided that it would be a good idea anyhow).
Do those who deal in ucreds (probably jhb and Robert W)
agree or disagree.. (if so I'll happily commit it as it shrinks the KSE
patches a bit more :-)
This code is not safe on SMP non-i386 machines (i.e. ia64, sparc64, alpha, and
possibly p3 and later i386's) because the p_ucred value you read could easily
be a stale value, thus rendering the test invalid. You need the lock for the
compare. Conceptually minimizing the crfree's isn't bad I guess. However, the
td_ucred pointer should nto be read if the thread is not in the kernel, and
having it set to NULL when we leave the kernel provides a conveninet way of
ensuring this doesn't happen since we will panic if we do.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Unconnected files problem
I have (finally) found and fixed this problem. You need to get version 1.107 or later of /sys/ufs/ffs/ffs_softdep.c (2002/02/07). Kirk McKusick =-=-=-=-=-= Date: Tue, 28 Aug 2001 14:02:24 +0200 From: Ollivier Robert [EMAIL PROTECTED] To: FreeBSD Current Users' list [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Unconnected files problem I have a script that generates index for all my mail messages (using glimpse). Sometimes, the disk is full because it has some rather big temporary files (and I have a lot of mail). It seems that we may have a softupdate-related (that's a guess from me) problem because some of these temporaty files end up as unconnected to any directory but link count is still one and they still takes space. The last time fsck ran on the filesystem, it gave me back more than 6 (!!) fragments (cf the following: -=-=- Aug 23 12:21:38 caerdonn root: /dev/da0s1g: Reclaimed: 0 directories, 22 files, 60424 fragments Aug 23 12:21:38 caerdonn root: /dev/da0s1g: 10295 files, 387087 used, 73408 free (1048 frags, 9045 blocks, 0.2% fragmentation) -=-=- lsof doesn't show them so they're not open by any process. The mtime of the files are exactly when the glimpseindex command is run. We know that SU has some issues when a filesystem is full but this is quite a problem because as you can see below, I'm losing a lot of space till the next reboot... UNREF FILE I=1081 OWNER=roberto MODE=100600 SIZE=523 MTIME=Aug 28 00:46 2001 CLEAR? no UNREF FILE I=18498 OWNER=roberto MODE=100600 SIZE=230665 MTIME=Aug 26 08:05 2001 RECONNECT? no CLEAR? no UNREF FILE I=18508 OWNER=roberto MODE=100600 SIZE=11225707 MTIME=Aug 23 20:02 2001 RECONNECT? no CLEAR? no UNREF FILE I=18530 OWNER=roberto MODE=100600 SIZE=28322748 MTIME=Aug 24 20:09 2001 RECONNECT? no CLEAR? no UNREF FILE I=18573 OWNER=roberto MODE=100600 SIZE=28326193 MTIME=Aug 25 20:09 2001 RECONNECT? no CLEAR? no UNREF FILE I=18575 OWNER=roberto MODE=100600 SIZE=18684173 MTIME=Aug 24 20:08 2001 RECONNECT? no CLEAR? no UNREF FILE I=19204 OWNER=roberto MODE=100600 SIZE=13771800 MTIME=Aug 26 08:05 2001 RECONNECT? no CLEAR? no UNREF FILE I=19353 OWNER=roberto MODE=100600 SIZE=18679309 MTIME=Aug 25 20:08 2001 RECONNECT? no CLEAR? no ** Phase 5 - Check Cyl groups 10223 files, 446324 used, 74595 free (1019 frags, 9197 blocks, 0.2% fragmentation) fsdb (inum: 2) inode 19353 current inode: regular file I=19353 MODE=100600 SIZE=18679309 MTIME=Aug 25 20:08:18 2001 [0 nsec] CTIME=Aug 25 20:08:18 2001 [0 nsec] ATIME=Aug 25 20:08:11 2001 [0 nsec] OWNER=roberto GRP=staff LINKCNT=1 FLAGS=0 BLKCNT=8ec0 GEN=4c2a6c10 -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED] FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001 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: Binutils fixed in -current?
Never mind. My bad. -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin 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: ucred for threads
Julian Elischer wrote: Terry I don't have time to work on it now, but if you would like to take a -current system and apply the threading KSE diffs from my web page, then maybe you can investigate whether I really ned the if clause or not.. I don't have time now to go back to it for a while I normally don't do -current, but I'm in the process of pulling together a tree right now. If I find time after the tasks I need to get done (i.e. real work), then I'll look at setting up an initial ucred, since it's really bogus to put if tests all over creation because initialization didn't end up normalizing things. -- Terry 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
bremfree related panic
I rebuilt my -CURRENT workstation last night. There still seems to be a
minor problem though. While I was running XFree 3.x (a rather old build,
compiled from ports):
$ pkg_info | grep XFree
XFree86-3.3.6_9 X11R6.3/XFree86 core distribution
there was the following panic. At the same time the disk was heavily
spinning, as I was updating my local NetBSD mirror with CVSup, and periodic
was running it's daily stuff. Does this look like a problem with X to you
all, or should I look for other causes? I am thinking of X giving me these
troubles, only because of frame #13 which is in an address that cannot be
printed by gdb. Any ideas?
(The bremfree panic is the second panic in the row, so it's probably a
whole different problem in itself.)
Script started on Fri Feb 8 05:55:22 2002
[toor@hades /var/crash]# gdb -k /usr/obj/usr/src/sys/CHARON/kernel.debug vmcore.1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 2629
in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c line 935
in fill_symbuf
IdlePTD at phsyical address 0x003d1000
initial pcb at physical address 0x00329bc0
panicstr: bremfree: bp 0xc2161734 not locked
panic messages:
---
panic: msleep
syncing disks... panic: bremfree: bp 0xc2166e4c not locked
Uptime: 2d15h0m41s
dumping to dev ad0s3b, offset 1966080
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37
36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
6 5 4 3 2 1
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
504 if (!dodump)
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:504
#1 0xc01b8ec4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:336
#2 0xc01b9361 in panic (fmt=0xc02b5da2 bremfree: bp %p not locked) at
/usr/src/sys/kern/kern_shutdown.c:646
#3 0xc01e7ecf in bremfree (bp=0xc2161734) at /usr/src/sys/kern/vfs_bio.c:545
#4 0xc0196359 in spec_fsync (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:407
#5 0xc0195e51 in spec_vnoperate (ap=0xc03d5e98) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#6 0xc024d449 in ffs_sync (mp=0xc0e00200, waitfor=2, cred=0xc05bee00,
td=0xc02f9604) at vnode_if.h:441
#7 0xc01f4c42 in sync (td=0xc02f9604, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:669
#8 0xc01b8b46 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:245
#9 0xc01b9361 in panic (fmt=0xc02cb2fe %s) at
/usr/src/sys/kern/kern_shutdown.c:646
#10 0xc0289d78 in trap_fatal (frame=0xc03d5fa8, eva=791205) at
/usr/src/sys/i386/i386/trap.c:842
#11 0xc0289aad in trap_pfault (frame=0xc03d5fa8, usermode=0, eva=791205) at
/usr/src/sys/i386/i386/trap.c:756
#12 0xc02895ef in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 51676,
tf_esi = 1816, tf_ebp = 264, tf_isp = -1069719596,
tf_ebx = 264, tf_edx = 980, tf_ecx = 6930, tf_eax = 0, tf_trapno = 12, tf_err
= 4, tf_eip = 4773, tf_cs = 49152,
tf_eflags = 721478, tf_esp = 4000, tf_ss = 0}) at
/usr/src/sys/i386/i386/trap.c:426
#13 0x12a5 in ?? ()
Cannot access memory at address 0x108.
(kgdb) list /usr/src/sys/kern/vfs_bio.c:545
540 int old_qindex = bp-b_qindex;
541
542 GIANT_REQUIRED;
543
544 if (bp-b_qindex != QUEUE_NONE) {
545 KASSERT(BUF_REFCNT(bp) == 1, (bremfree: bp %p not
locked,bp));
546 TAILQ_REMOVE(bufqueues[bp-b_qindex], bp, b_freelist);
547 bp-b_qindex = QUEUE_NONE;
548 } else {
549 if (BUF_REFCNT(bp) = 1)
(kgdb) list /usr/src/sys/i386/i386/trap.c:426
421
422 KASSERT(cold || td-td_ucred != NULL,
423 (kernel trap doesn't have ucred));
424 switch (type) {
425 case T_PAGEFLT: /* page fault */
426 (void) trap_pfault(frame, FALSE, eva);
427 goto out;
428
429 case T_DNA:
430 #ifdef DEV_NPX
(kgdb) q
[toor@hades /var/crash]# exit
Script done on Fri Feb 8 05:56:52 2002
Here's the dmesg output too:
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD
Ethernet tunnel device
Hi I am running FreeBSD current and barely got vmware working on it. Now I have another problem which I cant resolve. If I close down the vmware program and restart I get an error that vmnet(1,2,3,0 whatever) device is busy and can not be used. using /usr/local/etc/rc.d/vmware.sh stop and then start again didnt help either. running ifconfig gave me the following output (for vmnet2 which i was and intend to use again) vmnet2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.254.1 netmask 0xff00 broadcast 192.168.254.255 inet6 fe80::2bd:fff:fe0f:2%vmnet2 prefixlen 64 scopeid 0x8 ether 00:bd:0f:0f:00:02 Opened by PID 698 clearly the device is opened by the previous instance of the program and is not closed. deleting the devices and recreating them didnt help any (using devfs which comes stock in current - 5.0) strangely even after deleting these devices from /dev ifconfig still lists them !! may be its because of devfs ... but there ought to be someway. trying to destroy the device using ifconfig gives an error too which (i believe) it should because destroy is not for ethernet tunnel device if I am not wrong. but there are no options to destroy the ethernet tunnel device in ifconfig Should there be? I cant think anymore ... would appreciate input from you guys . Any input. Please dont shy about telling me that I am going the wrong ally thanks a bunch Saurabh Gupta 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: time breakage.
In message [EMAIL PROTECTED], Ju lian Elischer writes: phk, is this you? /usr/include/sys/time.h:137: integer constant out of range /usr/include/sys/time.h:137: warning: decimal integer constant is so large that it is unsigned Yes, that was me, seems like I did my buildworld test in the wrong source tree here. Thanks to peter for fixing this, and sorry for the trouble! -- 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: Ethernet tunnel device
--lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2002 at 03:23:36AM -0800, whoever wrote: clearly the device is opened by the previous=20 instance of the program and is not closed.=20 deleting the devices and recreating them didnt help any (using devfs which comes stock in current - 5.0) strangely even after deleting these devices from /dev ifconfig still lists them !! may be its because of devfs ... but there ought to be someway. There is no notification of last delete in devfs so deleting a node doesn't do anyway. trying to destroy the device using ifconfig gives an error too which (i believe) it should because destroy is not for ethernet tunnel device if I am not wrong. =20 but there are no options to destroy the ethernet tunnel device in ifconfig Should there be? Yes, I think we should add support for network device cloning and consider removing support for devfs cloning since it doesn't behave very logicaly. It's not there now, though it wouldn't be very hard to add. I cant think anymore ... would appreciate input from you=20 guys . Any input. Please dont shy about telling me that I am going the wrong ally It sounds like there's some sort of a bug in the close code. You are sure the previous instance is really gone, right? If it is, that's another issue. -- Brooks --=20 Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aCYnXY6L6fI4GtQRAsrzAJsGBJKje2qLcu4yYKaizVbp2gk3NQCeIzrr 4NSEbRRRJm4BTeaLT9KpV60= =F2rR -END PGP SIGNATURE- --lrZ03NoBR/3+SXJZ-- 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: Where to find docs on newbus vs. cardbus vs. newcard
Thanks, Warner!
On Mon, Feb 11, 2002 at 09:37:08AM -0700, M. Warner Losh wrote:
| NEWBUS:
| The current way of doing FreeBSD device configuration. This
| is approximately sys/kern/subr_bus.c, bus_if.m and device_if.m.
That part is pretty clear.
| CardBus:
| PCMCIA standard for PCI cards in the PC Card form factor.
I was pretty close on this as well. These are specifically 32-bit
cards, correct?
| dev/{pccard,pcic,exca,cardbus,pccbb}/*. I'm in the process of fixing
| bugs in this code base as well as removing redundant code and
| expanding support for more bridges and client devieces. This is what
| I've been calling NEWCARD.
Ah, this was the part I got mixed up. I thought Newcard was already up
and running with the last iteration of changes you made (remember me and
ToPIC on Toshiba? ;-) I thought this was already in -stable.
jm
--
My other computer is your windows box.
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: Performance of -current vs -stable
On 07-Feb-02 Georg-W Koltermann wrote: At Wed, 06 Feb 2002 23:33:14 -0500 (EST), John Baldwin wrote: [...] I guess. Note that you can use a loader tunable 'debug.witness_watch' to turn witness off from the loader. If it's set to 0 witness won't be used even if it's compiled into the kernel (just a general FYI, witness(4) documents this as well). Nice feature, thanks for the hint. I can't find it documented in witness(4), however: hunter# grep -i watch /usr/src/share/man/man4/witness.4 hunter# CVSup is from Feb 6. Hmm, doh. I document the other loader tunables and sysctls, just not debug.witness_watch. If someone with some mdoc fu and spare time wants to add a para noting that debug.witness_watch can be set to 0 as a loader tunable to turn off witness and that the read-only sysctl debug.witness_watch can be used at runtime to see if witness is enabled or not. -- Regards, Georg. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
