Re: Re: Whatever happened to CTM?
On 2001-03-19 17:01 -0800, Ulf Zimmermann [EMAIL PROTECTED] wrote: I have been hosting the machine which ran ctm, unfortunatly my provider cut me off and I just got some access back, but not for the location the ctm machine is located at. Ummm, that's bad ... I had been hoping that CTM deltas might just start turning up at the well known places again, anytime soon ... At this time I do not know yet when it will have access again. There are many sites that rely on CTM for one reason or the other. At work, I can't get CVSUP through the firwall, and thus it is no option at all. Just an idea: How about a CVSUP via HTTPS server (just as a means to tunnel CVSUP through a HTTPS proxy ...) ? Most probably a CVSUP daemon bound to port 443 would do (there are programs that tunnel arbitrary data through a HTTPS proxy, though I admit this is cheating ;-) Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trap in vm_fault
[EMAIL PROTECTED] writes: Trying to mount a music cd might cause the atapi code to try to read 9408 bytes into a 8192 bytes long buffer. That's not it. There was a music CD in the drive, but no attempt was made to mount it - I wasn't even there when it crashed. DES -- Dag-Erling Smrgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT breakage in usr.sbin/amd/mk-amd-map
On Wed, Mar 21, 2001 at 03:13:42PM +1100, Bruce Evans wrote:
[...]
Only the amd ones are broken. The bug is in ../Makefile.inc. It spams
${SRCS} with some nfs headers. This breaks bsd.prog.mk's automatic
setting of ${SRCS} from ${PROG}. SRCS should be under the control of
individual Makefiles except for the default in bsd.prog.mk.
This bug also causes bogus setting and building of nfs headers in amd
subdirs that don't have any C sources and/or don't need any nfs headers,
e.g. in the scripts subdir.
Fixed now, sorry.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch /bin/ls again, for mb supporting.
On Tue, Mar 20, 2001 at 18:13:20 +, thinker wrote:
+ sz = mbtowc(c, p, dc);
+ if (isprint(c)) {
As MINOURA correctly notes, you can't use isprint() with wchar_t type
(isprint() is for runes and single chars only, but runes are not widely
accepted standard). You need to use iswprint(), see
http://www.opengroup.org/onlinepubs/007908799/xsh/iswprint.html
It means you need to implement wctype.h and isw*() family _before_ any ls
modifications. Of course they can be easily implemented via existen runes,
so consider runes as internal interface.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Request for review [Re: /bin/ls patch round #2]
On Wed, Mar 21, 2001 at 12:58:05 +0900, MINOURA Makoto wrote: | In [EMAIL PROTECTED] | Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] wrote: Which is still something which needs to be done yes. Hmmm, I didn't know that... FreeBSD lacks iswprint() etc... It's..., it's ok, Michael is right, there's no way to do that w/o adding some functions to libc. Ideally we have to implement isw*() family though, of course. I fully agree. wctype.h and isw*() must be implemented first instead of hacking or using private interface (like runes) in userland program. It will be easy to implement them over existen ctype mechanism masking runes with wchar_t. Any takers? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Whatever happened to CTM?
On Tuesday, 20th March 2001, Ulf Zimmermann wrote: On Mon, Mar 19, 2001 at 04:53:33PM -0800, John Baldwin wrote: On 20-Mar-01 Michael C . Wu wrote: For all connections greater than 9600baud modems, we recommend using CVSup to get src-all and ports-all updated. At the worst case, be able to CVSup a ports-all collection within an hour, with heavy packet loss and low bandwidth. i.e. CTM sucks, don't use it. :) On the contrary, I prefer CTM over CVSup, even on a fast connection (which I don't currently have). On a slow or intermittent connection, CTM beats CVSup by a large margin. cvsup is not available via e-mail for those who may only have e-mail access for one reason or another. Firewalls make CTM style delivery essential. (No, Stefan, I don't like your tunneling idea. :-) I have been hosting the machine which ran ctm, And many thanks indeed for your service! unfortunatly my provider cut me off and I just got some access back, but not for the location the ctm machine is located at. At this time I do not know yet when it will have access again. Surely FreeBSD Inc (or whatever it is that owns the freebsd.org machines) could spring for a box. Assuming Ulf is still keen, it shouldn't be too hard for him to remote administer it. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Whatever happened to CTM?
Just an idea: How about a CVSUP via HTTPS server (just as a means to tunnel CVSUP through a HTTPS proxy ...) ? Most probably a CVSUP daemon bound to port 443 would do (there are programs that tunnel arbitrary data through a HTTPS proxy, though I admit this is cheating ;-) You should be able to do it with SSH (assuming that you can get out with ssh!) $ ssh -v -l yourname otherhost.example.com -L5559:cvsup.example.com:5559 Then doing a cvsup with the server set to 127.0.0.1 will work. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
World broken in fsdb by fsck_ffs changes.
=== sbin/fsdb cc -O -pipe -march=pentiumpro -I/src/src/sbin/fsdb/../fsck_ffs -I/usr/obj/src/src/i386/usr/include -c /src/src/sbin/fsdb/fsdb.c cc -O -pipe -march=pentiumpro -I/src/src/sbin/fsdb/../fsck_ffs -I/usr/obj/src/src/i386/usr/include -c /src/src/sbin/fsdb/fsdbutil.c /src/src/sbin/fsdb/../fsck_ffs/fsck.h:201: storage size of `cmd' isn't known *** Error code 1 Stop in /src/src/sbin/fsdb. *** Error code 1 -- 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
World breaks in sbin/fsdb [PATCH]
cvs diff: Diffing . Index: fsdbutil.c === RCS file: /home/ncvs/src/sbin/fsdb/fsdbutil.c,v retrieving revision 1.10 diff -u -2 -r1.10 fsdbutil.c --- fsdbutil.c 2000/05/01 20:01:16 1.10 +++ fsdbutil.c 2001/03/21 13:42:01 @@ -35,4 +35,5 @@ #include sys/types.h +#include sys/param.h #include ctype.h #include err.h @@ -43,4 +44,5 @@ #include ufs/ufs/dinode.h +#include ufs/ffs/fs.h #include "fsdb.h" -- 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
No Subject
subscribe freebsd-current subscribe cvs-all -- Pascal Filipovicz --- IUT 'A' Nancy-Verdun - S.C.I. 2ter, bd Charlemagne CS 5227 54000 Nancy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc driver: aic7892 no longer supported
Looks like I've got a similar problem only its aic7880/wide I've got a Dell optiplex 450 with an Adaptec 2940uw controller which can boot but can't "mountroot". Perhaps something happend recently that makes it difficult to get "largish" chuncks of contiguous memory? You'll have to instrument the driver to find out where the attach is failing. Start by going into aic7xxx.c:ahc_init() and adding a printf to all of the early returns. If that doesn't catch it, do the same for aic7xxx_pci.c:aic7xxx_config(). In aic7xxx_pci.c:ahc_pci_config() the call to ahc_pci_map_int(ahc) is failing. bus_alloc_resource() appears to need more time than I have right now so that will have to wait till tonight :-) It does look like a more fundamental problem below the scsi driver is involved. Thanks Justin. Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP **
portmap is dead, long live rpcbind! This means you'll need to update /etc/hosts.allow probably like revision 1.12 where I did a s/protmap/rpcbind/g. And now that I have your attention... Anyone want to add the tirpc stuff to our newsflash? What about Kirk's background fsck? What about the BABUG meeting on Thursday? There's gonna be a film crew from IBM-Linux there and a tutorial on netbooting. http://www.bafug.net/meetings/NextMeetingBerk.html -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvsup/cvsupfile question
Darn, Using cvsup to catch up to changes for 4.2-Stable, we ended up with 4.3-Beta. We used cvsup Nov-December, with (I thought) the attached cvsup file, to keep 4.2-Stable current. We ran cvsup yesterday. After `buildworld`, `buildkernel`, `uname` says: FreeBSD [host] 4.3-BETA FreeBSD 4.3-BETA #0: Wed Mar 21 previous build `uname` says: FreeBSD [host] 4.2-STABLE FreeBSD 4.2-STABLE #1: Wed Dec 6 Where'd we go wrong? Can it be put right? If it is best to reload, what is [a, the] correct cvsupfile configuration? /etc/cvsupfile: *default host=cvsup7.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default tag=RELENG_4 *default delete use-rel-suffix src-all src-crypto src-secure *default tag=. - thanks, hurf Hurf Sheldon Dir. Research Systems Program of Computer Graphics 580 Rhodes Hall, Hoy Rd. Cornell University Ithaca, N.Y. 14853 voice:607 255 6713 fax:607 255 0806 email: [EMAIL PROTECTED] http://www.graphics.cornell.edu/~hurf/
Re: Whatever happened to CTM?
On Wed, Mar 21, 2001 at 09:44:00PM +1000, Stephen McKay wrote: On Tuesday, 20th March 2001, Ulf Zimmermann wrote: On Mon, Mar 19, 2001 at 04:53:33PM -0800, John Baldwin wrote: On 20-Mar-01 Michael C . Wu wrote: For all connections greater than 9600baud modems, we recommend using CVSup to get src-all and ports-all updated. At the worst case, be able to CVSup a ports-all collection within an hour, with heavy packet loss and low bandwidth. i.e. CTM sucks, don't use it. :) On the contrary, I prefer CTM over CVSup, even on a fast connection (which I don't currently have). On a slow or intermittent connection, CTM beats CVSup by a large margin. cvsup is not available via e-mail for those who may only have e-mail access for one reason or another. Firewalls make CTM style delivery essential. (No, Stefan, I don't like your tunneling idea. :-) I have been hosting the machine which ran ctm, And many thanks indeed for your service! unfortunatly my provider cut me off and I just got some access back, but not for the location the ctm machine is located at. At this time I do not know yet when it will have access again. Surely FreeBSD Inc (or whatever it is that owns the freebsd.org machines) could spring for a box. Assuming Ulf is still keen, it shouldn't be too hard for him to remote administer it. Stephen. I am only the owner of the box on which ctm runs and had provided the connectivity. It was maintained by someone else. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Whatever happened to CTM?
On a positive note, both Pachell and Covad agree the localloop for my new DSL is ready, so I hope to see a covad person with router in the next few days, which would mean I should be up and running again soon. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP ** portmap daemon renamed to rpcbind
The Portmapper binary has been renamed from `portmap' to `rpcbind'. The name change was taken care of in /etc/defaults/rc.conf and in the auto-dependacy code in /etc/rc. HOWEVER, you may need to edit your /etc/hosts.allow and make the name change there. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup/cvsupfile question
Hurf Sheldon wrote: Using cvsup to catch up to changes for 4.2-Stable, we ended up with 4.3-Beta. This is perfectly alright. The -BETA just means that we are approaching 4.3-RELEASE after which it is called 4.3-STABLE and so on. It is the same code: .. - 4.2-RELEASE - 4.2-STABLE - 4.3-BETA - 4.3-RELEASE - 4.3-STABLE -.. This is a FAQ that really belongs on -questions (reply-to set). Cheers. -- Hroi Sigurdsson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup/cvsupfile question
Using cvsup to catch up to changes for 4.2-Stable, we ended up with 4.3-Beta. We used cvsup Nov-December, with (I thought) the attached cvsup file, to keep 4.2-Stable current. We ran cvsup yesterday. After `buildworld`, `buildkernel`, `uname` says: FreeBSD [host] 4.3-BETA FreeBSD 4.3-BETA #0: Wed Mar 21 previous build `uname` says: FreeBSD [host] 4.2-STABLE FreeBSD 4.2-STABLE #1: Wed Dec 6 Where'd we go wrong? Nowhere. Can it be put right? It is right. This "BETA" (not to be confused with an unstable commercial "beta") is simply "STABLE" with a tag on it to indicate that it is going through the release engineering process to become 4.3-RELEASE (and then 4.3-STABLE). You have something that is stable, and is just close to the next release. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review [Re: /bin/ls patch round #2]
"Andrey A. Chernov" [EMAIL PROTECTED] writes: I fully agree. wctype.h and isw*() must be implemented first instead of hacking or using private interface (like runes) in userland program. It will be easy to implement them over existen ctype mechanism masking runes with wchar_t. Any takers? If we're not going to bring in CITRUS, I'd prefer to see runes junked as an unnecessary layer of abstraction. Doing so would break backwards compatibility for locales, but I think we're going to end up doing that eventually anyway. -- I've always wanted to be a dilettante, but I've never quite been ready to make the commitment. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: World breaks in sbin/fsdb [PATCH]
On 21-Mar-01 Ollivier Robert wrote: cvs diff: Diffing . Index: fsdbutil.c === RCS file: /home/ncvs/src/sbin/fsdb/fsdbutil.c,v retrieving revision 1.10 diff -u -2 -r1.10 fsdbutil.c --- fsdbutil.c 2000/05/01 20:01:16 1.10 +++ fsdbutil.c 2001/03/21 13:42:01 @@ -35,4 +35,5 @@ #include sys/types.h +#include sys/param.h #include ctype.h #include err.h @@ -43,4 +44,5 @@ #include ufs/ufs/dinode.h +#include ufs/ffs/fs.h #include "fsdb.h" -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED] FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001 If it fixes it, please commit. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: Request for review [Re: /bin/ls patch round #2]
On 21 Mar 2001 13:02:41 +0900, [EMAIL PROTECTED] (MINOURA Makoto) said: Sorry I'm not sure but rune API is slightly different between 4.4BSD and Plan9, isn't it? Nobody runs Plan 9, whereas hundreds of thousands of machines run *BSD. Sources of the standard commands are often used as a living textbook to other programmers. They should be as `good' as possible, and in my opinion `good' includes `standard-complient'. You would have to exclude most of the programs in 4.4BSD by that definition. There is a reason why interfaces like err(3) and daemon(3) are included in the standard C library, and the style guide strongly recommends their usage. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review [Re: /bin/ls patch round #2]
On Wed, Mar 21, 2001 at 16:19:10 -0500, Garrett Wollman wrote: You would have to exclude most of the programs in 4.4BSD by that definition. There is a reason why interfaces like err(3) and daemon(3) are included in the standard C library, and the style guide strongly recommends their usage. This particular case is different from what you say. There is no strict POSIX/ISO C equivalent of functionality you describe, but in case we discuss it exist. I.e. when two implementations does the same thing, POSIX/ISO C variant is preferred. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review [Re: /bin/ls patch round #2]
On Thu, 22 Mar 2001 00:26:09 +0300, "Andrey A. Chernov" [EMAIL PROTECTED] said: This particular case is different from what you say. There is no strict POSIX/ISO C equivalent of functionality you describe, Certainly there is. The daemon(3) function is implemented entirely on top of POSIX interfaces: fork(), setsid(), chdir(), open(), dup2(), and close(). It is supplied because many programs which attempt to do this from scratch get it wrong. Similarly, err(3) could be entirely implemented in terms of ISO C primitives: vfprintf(), strerror(), and exit(). The style guide recommends its use because err() is a simpler interface, thus harder to get wrong than rolling one's own. strsep(3) is another similar example. I.e. when two implementations does the same thing, POSIX/ISO C variant is preferred. Erm, no -- the superior version is preferred. (Something of a tautology.) FreeBSD has never been about slavish adherence to standards; while we prefer to follow relevant standards, if the standards are broken we do our own thing, and that goes doubly so for the way we code the standard utilities. That doesn't mean we shouldn't implement wctype.h et al, but it does mean that we should use whichever facilities are cleanest, and easiest to code for and maintain, rather than those which are specifically blessed by an ISO working group. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review [Re: /bin/ls patch round #2]
On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote: On Thu, 22 Mar 2001 00:26:09 +0300, "Andrey A. Chernov" [EMAIL PROTECTED] said: This particular case is different from what you say. There is no strict POSIX/ISO C equivalent of functionality you describe, Certainly there is. The daemon(3) function is implemented entirely on top of POSIX interfaces: fork(), setsid(), chdir(), open(), dup2(), and close(). It is supplied because many programs which attempt to do this from scratch get it wrong. Similarly, err(3) could be entirely implemented in terms of ISO C primitives: vfprintf(), strerror(), and exit(). The style guide recommends its use because err() is a simpler interface, thus harder to get wrong than rolling one's own. strsep(3) is another similar example. I mean _strict_ equivalent in more strict sense, i.e. the same amount of calls needed, the same interface complexity, the same capabilities, etc. I.e. when two implementations does the same thing, POSIX/ISO C variant is preferred. Erm, no -- the superior version is preferred. (Something of a Since I mean _strict_ equivalent, there can't be superior version by definition, because it makes equivalent no strict. In case we discuss equivalent is strict. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review [Re: /bin/ls patch round #2]
On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote: the way we code the standard utilities. That doesn't mean we shouldn't implement wctype.h et al, but it does mean that we should use whichever facilities are cleanest, and easiest to code for and maintain, rather than those which are specifically blessed by an ISO working group. In general wc*() functions provide more flexibility than runes, but in case we discuss there is no difference. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
boom in a syscalll
Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc019d7fa stack pointer = 0x10:0xc8f45ea4 frame pointer = 0x10:0xc8f45eb0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 331 (bash) kernel: type 12 trap, code=0 CPU0 stopping CPUs: 0x0002... stopped. Stopped at propagate_priority+0x6e:cmpl0x14(%esi),%ebx db t propagate_priority(c8b4c100) at propagate_priority+0x6e _mtx_lock_sleep(c0355400,0,c02e14f8,1f2) at _mtx_lock_sleep+0x1e0 msleep(c8b4c100,0,15c,c02df6bc,0) at msleep+0x5f3 wait1(c8b4c100,c8f45f80,0,c8f45fa0,c02b3dc1) at wait1+0x8ad wait4(c8b4c100,c8f45f80,2814e9d4,80a3660,2) at wait4+0x10 syscall(2f,2f,2f,2,80a3660) at syscall+0x421 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
generate 100000 Hits Free!!
Get 100,000 Hits A Month - Free!! Join The Special Report Network Now and Easily Generate 100,000 Hot Leads a Month for Anything You Sell Check this site out http://www.special-report-network.net/specialreports.cgi/NM52240
RE: boom in a syscalll
On 21-Mar-01 Matthew Jacob wrote: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x14 NULL pointer deref.. fault code = supervisor read, page not present instruction pointer = 0x8:0xc019d7fa stack pointer = 0x10:0xc8f45ea4 frame pointer = 0x10:0xc8f45eb0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 331 (bash) kernel: type 12 trap, code=0 CPU0 stopping CPUs: 0x0002... stopped. Stopped at propagate_priority+0x6e:cmpl0x14(%esi),%ebx db t propagate_priority(c8b4c100) at propagate_priority+0x6e (kgdb) l *propagate_priority+0x6e 0xc019fdce is in propagate_priority (../../kern/kern_mutex.c:201). 201 MPASS(p-p_magic == P_MAGIC); Well, err, maybe this line, considering none of the rest of my line numbers match up I doubt it is this one. :( Could you pull up kgdb on your kernel.debug and find out which line this died in? It could either be that p is NULL (which could be an unintialized mutex that a mtx_lock later blocked on.) In fact, this is quite likely just using a mutex that hasn't been init'd. Might want to add in some code to try to display the description of a mutex if p == NULL (though it is probably invalid, too.) Another take might be to add assertions to the start of mtx_lock_flags() and mtx_lock_spin_flags() that panic if mtx_lock == 0. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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
*HEADSUP* /etc/netconfig
Afer installworld in CURRENT, you'll have to run mergemaster ( or install /etc/netconfig ) manually if you run any rpc-services. Else you'll see strange errors like this: - can't get net id for host/nfs: servname not supported for ai_socktype - Protocol not supported - rpcbind on server: RPC: Unknown host This should also go into the UPDATING section. Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review [Re: /bin/ls patch round #2]
On Wed, Mar 21, 2001 at 03:29:52PM -0500, Don Croyle scribbled: | "Andrey A. Chernov" [EMAIL PROTECTED] writes: | | I fully agree. wctype.h and isw*() must be implemented first instead of | hacking or using private interface (like runes) in userland program. | It will be easy to implement them over existen ctype mechanism masking | runes with wchar_t. Any takers? | | If we're not going to bring in CITRUS, I'd prefer to see runes junked We(I) will. | as an unnecessary layer of abstraction. Doing so would break | backwards compatibility for locales, but I think we're going to end up | doing that eventually anyway. -- +---+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
even more boom...
panic: getnewvnode: free vnode isn't
cpuid = 1; lapic.id = 0c00
Debugger("panic")
CPU1 stopping CPUs: 0x0001... stopped.
Stopped at Debugger+0x45: pushl %ebx
db t
Debugger(c02e1241) at Debugger+0x45
panic(c02e5958,4,c1003800,c0ff5f00,c8f78620) at panic+0xd0
getnewvnode(1,c0ff1000,c0e9e000,c8f86c04,e8) at getnewvnode+0xb2
ffs_vget(c0ff1000,ae604,c8f86c50,c8f86db0,c034fc80) at ffs_vget+0x165
ffs_valloc(c8b54360,81a4,c10c6000,c8f86c50,c8f86db0) at ffs_valloc+0x93
ufs_makeinode(81a4,c8b54360,c8f86e9c,c8f86eb0) at ufs_makeinode+0x5a
ufs_create(c8f86db0,c8f86e24,c01e328b,c8f86db0,c8f86f80) at ufs_create+0x28
ufs_vnoperate(c8f86db0,c8f86f80,0,3,602) at ufs_vnoperate+0x15
vn_open(c8f86e88,c8f86e54,1a4,c8f78620,4) at vn_open+0x173
open(c8f78620,c8f86f80,280f2e38,bfbfe488,bfbfe4e8) at open+0xd6
syscall(2f,2f,2f,bfbfe4e8,bfbfe488) at syscall+0x421
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
It's not my day... And in order to help John on the previous, I need to run
kgdb... which is awkward
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP **
Alfred Perlstein writes: | What about the BABUG meeting on Thursday? There's gonna be a film | crew from IBM-Linux there and a tutorial on netbooting. | | http://www.bafug.net/meetings/NextMeetingBerk.html Including netbooting of an Airport base station? run Etherboot or Airport? E ROM segment 0x8000 length 0x40EA reloc 0x9800 Boot from (N)etwork or from (L)ocal? N Etherboot/32 version 4.6.12 (GPL) for [NE2100] Probing...[NE2100] PCnet/ISA+ 79C961A base 0x0300, DMA 5, addr 00:30:65:3A:59:5F Searching for server (DHCP)... Me: 192.168.2.194, Server: 192.168.2.254, Gateway 192.168.2.254 Loading /tftpboot/kernel.bsd (ELF/FreeBSD)0680- Copyright (c) 1992-2001 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 4.3-BETA #9: Wed Mar 21 15:41:11 PST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/AIRPORT Timecounter "i8254" frequency 1193182 Hz CPU: AMD Unknown (486-class CPU) Origin = "AuthenticAMD" Id = 0x4a4 Stepping = 4 Features=0x0 real memory = 4194304 (4096K bytes) avail memory = 1998848 (1952K bytes) Preloaded elf kernel "kernel" at 0xc025bb00. npx0: math processor on motherboard npx0: 387 emulator isa0: ISA bus on motherboard pcic0: Intel i82365 at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0 sio0: type 16550A, console lnc0 at port 0x300-0x317 iomem 0xd-0xd irq 10 on isa0 lnc0: PCnet-ISA II address 00:30:65:3a:59:5f lnc0: driver is using old-style compatability shims RTC BIOS diagnostic error e4clock_battery,ROM_cksum,config_unit,invalid_time pccard: card inserted, slot 0 Sending DHCP Discover packet from interface lnc0 (00:30:65:3a:59:5f) Received DHCP Offer packet on lnc0 from 192.168.2.254 (accepted) (no root path) Sending DHCP Request packet from interface lnc0 (00:30:65:3a:59:5f) Received DHCP Ack packet on lnc0 from 192.168.2.254 (accepted) (got root path) lnc0 at 192.168.2.194 server 192.168.2.254 boot file /tftpboot/kernel.bsd router 192.168.2.254 rootfs 192.168.2.254:/usr/home/ambrisko/netboot swapfs 192.168.2.254:/usr/work/netboot Adjusted interface lnc0 md_lookup_swap: Swap size is 262144 KB Mounting root from nfs: NFS ROOT: 192.168.2.254:/usr/home/ambrisko/netboot NFS SWAP: 192.168.2.254:/usr/work/ij3/netboot wi0: WaveLAN/IEEE 802.11 at port 0x240-0x27f irq 5 slot 0 on pccard0 wi0: Ethernet address: 00:02:2d:09:4b:f2 pccardd[40]: Assigning I/O window 0, start 0x240, size 0x40 flags 0x5 pccardd[40]: Assign wi0, io 0x240-0x27f, mem 0x0, 0 bytes, irq 5, flags 0 pccardd[40]: wi0: Lucent Technologies (WaveLAN/IEEE) inserted. dhclient: New IP Address(wi0): 207.76.207.134 dhclient: New Subnet Mask (wi0): 255.255.255.0 dhclient: New Broadcast Address(wi0): 207.76.207.255 dhclient: New Routers: 207.76.207.254 pccardd[40]: pccardd started login: ROOT LOGIN (root) ON ttyp0 FROM crab login: ROOT LOGIN (root) ON ttyp1 FROM 207.76.207.135 Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breaks in sbin/fsdb [PATCH]
On Wed, 21 Mar 2001, Ollivier Robert wrote: cvs diff: Diffing . Index: fsdbutil.c === RCS file: /home/ncvs/src/sbin/fsdb/fsdbutil.c,v retrieving revision 1.10 diff -u -2 -r1.10 fsdbutil.c --- fsdbutil.c 2000/05/01 20:01:16 1.10 +++ fsdbutil.c 2001/03/21 13:42:01 @@ -35,4 +35,5 @@ #include sys/types.h +#include sys/param.h #include ctype.h #include err.h @@ -43,4 +44,5 @@ #include ufs/ufs/dinode.h +#include ufs/ffs/fs.h #include "fsdb.h" Index: style.9 === RCS file: /home/ncvs/src/share/man/man9/style.9,v retrieving revision 1.45 diff -c -2 -r1.45 style.9 *** style.9 2001/02/21 20:43:55 1.45 --- style.9 2001/03/22 02:38:45 *** *** 52,58 .Ed .Pp ! Kernel include files (i.e. sys/*.h) come first; normally, you'll need sys/types.h ! OR sys/param.h, but not both! sys/types.h includes sys/cdefs.h, and it's okay to depend on that. .Bd -literal --- 52,58 .Ed .Pp ! Kernel include files (i.e. sys/*.h) come first; NORMALLY, YOU'LL NEED sys/types.h ! OR sys/param.h, BUT NOT BOTH!! sys/types.h includes sys/cdefs.h, and it's okay to depend on that. .Bd -literal Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 22:26:11 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 21:20] wrote: On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 15:21] wrote: On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Er, too late. :) On a devfs system here's what you'll see: ls -lR /dev/vinum/ total 0 crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol /dev/vinum/plex: total 0 crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 /dev/vinum/sd: total 0 crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 /dev/vinum/vol: total 0 crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 I'd like to keep it this way, it just makes sense. No, that's a gratuitous change. All the docco talks about keeping the volumes in the main directory. That's why people are having trouble. Yes, it looks more uniform, but the objects aren't uniform. Since both you and Poul refused to fix the code I choose how I thought it should be. Can you explain why: Yes, it looks more uniform, but the objects aren't uniform. It just doesn't make sense to me to mix these device nodes in with the control/Control/controld nodes. Understood. But I don't like the very long device names. Also, why not have a /dev/vinum/ctl/ directory for those nodes? I can go along with that. They're almost completely invisible anyway. We could even call it /dev/vinum/.ctl. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interesting backtrace...
On Wed, 21 Mar 2001, David Malone wrote:
On Mon, Mar 19, 2001 at 02:47:34PM +1100, Bruce Evans wrote:
npx.c already has one "fix" for the overflow problem. The problem
is may be that clocks don't work early any more.
It must be that microtime() doesn't work early any more.
I checked that microtime() doesn't work for more than 10 msec if it
uses the i8254. When it doesn't work for that long, the bandwidth
test breaks down for bzero() bandwidths smaller than 100 MB/sec. Such
bandwidths are normal for Intel i586's. E.g., my P5/133 has a
generic_bzero() bandwidth of 87e6 bytes/sec and an i586_bzero()
bandwidth of 174e6 bytes/sec. This is in userland with a slightly
improved i586_bzero() (39 cycles instead of 41 for the inner loop
IIRC) and with slightly improved page coloring, and a buffer size of
1MB (same as in the bandwidth test). So, the test always breaks down
for my P5/133 if microtime() uses the i8254. OTOH, my K6-1/233 has
bandwidths of 135e6 and 127e6 bytes/sec, respectively, so the test
never breaks down for it.
I did a quick check, and it does seem that i586_bzero can be faster
on the k6-2. I found it was about twice as fast for large buffers.
This was timed in userland using the TSC. With a slightly simplified
version of i586_bzero (I removed all the kernel specific stuff and
had it always save the floating point state on the stack). A graph
is at:
This is surprising.
http://www.maths.tcd.ie/~dwmalone/comp/bzero-band.ps
The graph seems to peak at about 160kB/s, which seems plausable.
160kB/sec is implausible :-). 160MB/sec is plausible. Half that
is hard to understand. Why is it slower than my K6-1? Ah, I
partly understand. My K6-1 has an L2 cache size of 1MB, so the
1MB buffer size is really too small for it if write allocation
is enabled. P5's don't have write allocation, so the buffer size
for them is not critical. All K6's have write allocation IIRC.
With a buffer size of 2MB, the bandwidths for my K6-1/233 are
84e6 and 80e6 bytes/sec, respectively. So 80MB/sec is plausible
and 160MB/sec is fast (it's equivalent to 320MB/sec without
write allocation).
These complications show how hard it is to write a single bandwidth
test that works for all i586's. I think the next step (after fixing
the i586 functions) should be to reduce the buffer size signicantly
and not worry about cache effects. Cache effects benefit generic_bzero()
in the bandwidth test but they probably benefit it in normal use too.
The code is at:
http://www.maths.tcd.ie/~dwmalone/comp/-time.S
http://www.maths.tcd.ie/~dwmalone/comp/-time.c
(It's crude, but seemed to produce moderately OK results. You get
ocasional dips in the bandwidth due to using the tcs for timing.
I only tried sizes which were a power of two, aswell...)
I wrote not-so-crude read/write/copy/checksum userland benchmarks to
test this stuff when I helped implement the i586-optimized routines.
Here is the write benchmark. Compile it with 'cc -aout'.
---
#include sys/types.h
#include sys/time.h
#include sys/resource.h
#include machine/cpufunc.h
#include stdlib.h
#include stdio.h
#include string.h
#include unistd.h
typedef void func_t(void *buf, size_t len);
struct func
{
func_t *fn;
char *name;
char *description;
};
static func_t zero0, zero1, zero2, zero3, zero4, zero5, zero6, zero7;
static func_t zero8, zero9, zeroA, zeroB, zeroC, zeroD;
static void usage(void);
static char const *progname;
static struct func funcs[] =
{
zero0, "zero0", "stosl",
zero1, "zero1", "unroll 16",
zero2, "zero2", "unroll 16 preallocate",
zero3, "zero3", "unroll 32",
zero4, "zero4", "unroll 32 preallocate",
zero5, "zero5", "unroll 64",
zero6, "zero6", "unroll 64 preallocate",
zero7, "zero7", "fstl",
zero8, "zero8", "movl",
zero9, "zero9", "unroll 8",
zeroA, "zeroA", "generic_bzero",
zeroB, "zeroB", "i486_bzero",
zeroC, "zeroC", "i586_bzero",
zeroD, "zeroD", "i686_pagezero",
bzero, "zeroE", "bzero (stosl)",
};
#define NFUNC (sizeof funcs / sizeof funcs[0])
int main(int argc, char **argv)
{
unsigned char *buf;
int ch;
int funcn;
int funcnspecified;
int i586;
size_t len;
size_t max;
int precache;
int quiet;
size_t thrashbufsize;
unsigned long long tot;
progname = argv[0];
funcnspecified = -1;
i586 = 0;
len = 4096;
precache = 0;
quiet = 0;
tot = 1;
while ((ch = getopt(argc, argv, "5f:l:pqt:")) != EOF)
{
switch (ch)
{
case '5':
i586 = 1;
break;
case 'f':
funcnspecified = strtoul(optarg, (char **) NULL, 0);
if (funcnspecified 0 || funcnspecified = NFUNC)
usage();
break;
case 'l':
len = strtoul(optarg, (char **) NULL, 0);
break;
case 'p':
precache = 1;
break;
case 'q':
Re: Whatever happened to CTM?
On Wed, 21 Mar 2001, Stephen McKay wrote: On Tuesday, 20th March 2001, Ulf Zimmermann wrote: On Mon, Mar 19, 2001 at 04:53:33PM -0800, John Baldwin wrote: On 20-Mar-01 Michael C . Wu wrote: For all connections greater than 9600baud modems, we recommend using CVSup to get src-all and ports-all updated. At the worst case, be able to CVSup a ports-all collection within an hour, with heavy packet loss and low bandwidth. i.e. CTM sucks, don't use it. :) On the contrary, I prefer CTM over CVSup, even on a fast connection (which I don't currently have). On a slow or intermittent connection, CTM beats CVSup by a large margin. I'm not sure about that. CTM may be faster, but it works less automatically, especially when it breaks, and it breaks often, at both the server and client levels (mainly downtime problems for the server and disk-full problems for the client. I used to use it until the server broke one time too many last year. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FOLLOWUP: RE: boom in a syscalll
Followup- updated kernel, rebuilt, and the same thing that triggered this before (^Z in vi) happened again, but this time with a different traceback: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc019d9f2 stack pointer = 0x10:0xc7fc5f30 frame pointer = 0x10:0xc7fc5f3c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 19 (irq2: fxp0 isp1) kernel: type 12 trap, code=0 CPU0 stopping CPUs: 0x0002... stopped. Stopped at propagate_priority+0x6e:cmpl0x14(%esi),%ebx db t propagate_priority(c7ba8740) at propagate_priority+0x6e _mtx_lock_sleep(c0355c20,0,c02dfeb4,1f7) at _mtx_lock_sleep+0x1e0 ithread_loop(c0e7d580,c7fc5fa8) at ithread_loop+0x102 fork_exit(c01980ec,c0e7d580,c7fc5fa8) at fork_exit+0x70 fork_trampoline() at fork_trampoline+0x8 This is an SMP... Sorry about not being able to get kgdb going right now... I'm in crunch mode... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
