Re: turning off malloc's AJ by default
In message <[EMAIL PROTECTED]>, "David O'Brien" writes: >The RE's are wanting to ship 5.0 DP#1 w/this patch applied. >If having 'AJ' by default is deemed not useful (by being removed from the >DP), it sounds like we should just turn it off. > >Unless there is strong objection, I plan on committing this. I firmly belive that only things which ship as FreeBSD-%d.%d-RELEASE should have the AJ options turned off. We want both our own code and 3rd party code to find the bugs in a DP release rather than in a RELEASE. Put a prominent notice in the release note, put a pointer to the recent libz scare if you feel like, and say that since this is about trying out and testing, we have set these options to help people flush out bugs. The steady trickle of emails I receive about things exposed by AJ is a clear indication that we need it on as much as possible. -- 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
Re: turning off malloc's AJ by default
On Sat, Mar 23, 2002 at 06:40:21PM -0800, Steve Kargl wrote: > Surely, you're joking. No wonder it's a PITA > to convince a 3rd party vendor to release a > FreeBSD product. Please don't misinterpret David's words. 3rd party apps are not our *primary* concern, FreeBSD is. And note that in this thread we are talking about turning the default off. This does not stop someone from turning AJ back on and using them to debug/fix a program. :-) Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
On Sat, Mar 23, 2002 at 06:40:21PM -0800, Steve Kargl wrote: > On Sat, Mar 23, 2002 at 04:34:57PM -0800, [EMAIL PROTECTED] wrote: > > > As FreeBSD developers, 3rd party code cannot > > be our primary concern. > > Surely, you're joking. No wonder it's a PITA > to convince a 3rd party vendor to release a > FreeBSD product. No I am not joking. I do not see what my statement in the context of `AJ' implies I do not care about 3rd party applications running on FreeBSD. However, a debugging option that at this point only finds bugs in 3rd party applications that exist on Linux, Solaris, etc.. also is not suffient reason to continue to penalize all FreeBSD users. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
On Sat, Mar 23, 2002 at 04:34:57PM -0800, [EMAIL PROTECTED] wrote: > As FreeBSD developers, 3rd party code cannot > be our primary concern. > Surely, you're joking. No wonder it's a PITA to convince a 3rd party vendor to release a FreeBSD product. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
On Sat, Mar 23, 2002 at 04:09:27PM -0800, Matthew Dillon wrote: > If I remember correctly, it was the plan all along that releases would > not have AJ turned on by default. > > The real question is: should the patch stay in after the release is > rolled? Has the AJ default outlived its usefulness in general? > Well, I just reported a problem to NAG (www.nag.com) with their Fortran 95 compiler. The bug was found by phkmalloc and the AJ setting. NAG fixed the bug within 3 days and supplied a new binary. BTW, this is the only native Fortran 95 compiler for FreeBSD. I told NAG's tech support about the AJ feature and it appears NAG found at least one other bug with this set. I think AJ should be left set in the DP releases with a prominent note in the RELNOTES about the possible performance impact. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
On 2002-03-23 17:10, Matthew Dillon wrote:
> Well, 'current' has spoken I guess! :-)
>
> :From: [EMAIL PROTECTED]
> :To: "M. Warner Losh" <[EMAIL PROTECTED]>
Damn, I knew we shouldn't make current too smart.
Now we'll have to find names for 5.0-RELEASE like 'Wintermute' etc.
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
Well, 'current' has spoken I guess! :-) -Matt Matthew Dillon <[EMAIL PROTECTED]> :From: [EMAIL PROTECTED] :To: "M. Warner Losh" <[EMAIL PROTECTED]> :Cc: [EMAIL PROTECTED] :Subject: Re: turning off malloc's AJ by default :Message-ID: <[EMAIL PROTECTED]> :Reply-To: [EMAIL PROTECTED] :References: <[EMAIL PROTECTED]> :<[EMAIL PROTECTED]> : :[ WARNING, From: let to the list to deal with ignorant MUA's ] : :On Sat, Mar 23, 2002 at 05:23:35PM -0700, M. Warner Losh wrote: :> "David O'Brien" <[EMAIL PROTECTED]> writes: :> : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. :> : If having 'AJ' by default is deemed not useful (by being removed from the :> : DP), it sounds like we should just turn it off. :> : :> : Unless there is strong objection, I plan on committing this. :> :> I think we should keep AJ enabled until at least DP2. It has found :> bugs in the past, and I suspect that a lot of new code is going in :> between now and then. : :Robert Watson feels that AJ caught bugs early on, but now only catches :buts in 3rd party programs. As FreeBSD developers, 3rd party code cannot :be our primary concern. : :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: turning off malloc's AJ by default
At 4:34 PM -0800 3/23/02, David wrote: >On Sat, Mar 23, 2002 at 05:23:35PM -0700, M. Warner Losh wrote: > > > > I think we should keep AJ enabled until at least DP2. It has > > found bugs in the past, and I suspect that a lot of new code > > is going in between now and then. > >Robert Watson feels that AJ caught bugs early on, but now only >catches buts in 3rd party programs. As FreeBSD developers, >3rd party code cannot be our primary concern. The recent bug I fixed in login processing (the LOGIN-FAILURES message) was a problem which was made obvious due to the J. I wouldn't mind if the A was turned off, but the J still seems useful to me. (disclaimer: I used to work on an operating system which *always* did something similar to J...) -- 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
Re: turning off malloc's AJ by default
In message: <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: : [ WARNING, From: let to the list to deal with ignorant MUA's ] Or MUA's that don't meet your expectations. : On Sat, Mar 23, 2002 at 05:23:35PM -0700, M. Warner Losh wrote: : > "David O'Brien" <[EMAIL PROTECTED]> writes: : > : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. : > : If having 'AJ' by default is deemed not useful (by being removed from the : > : DP), it sounds like we should just turn it off. : > : : > : Unless there is strong objection, I plan on committing this. : > : > I think we should keep AJ enabled until at least DP2. It has found : > bugs in the past, and I suspect that a lot of new code is going in : > between now and then. : : Robert Watson feels that AJ caught bugs early on, but now only catches : buts in 3rd party programs. As FreeBSD developers, 3rd party code cannot : be our primary concern. With trustedbsd stuff coming in, and other userland things being imported from time to time, I think that it will still be useful for a time. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
[ WARNING, From: let to the list to deal with ignorant MUA's ] On Sat, Mar 23, 2002 at 05:23:35PM -0700, M. Warner Losh wrote: > "David O'Brien" <[EMAIL PROTECTED]> writes: > : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. > : If having 'AJ' by default is deemed not useful (by being removed from the > : DP), it sounds like we should just turn it off. > : > : Unless there is strong objection, I plan on committing this. > > I think we should keep AJ enabled until at least DP2. It has found > bugs in the past, and I suspect that a lot of new code is going in > between now and then. Robert Watson feels that AJ caught bugs early on, but now only catches buts in 3rd party programs. As FreeBSD developers, 3rd party code cannot be our primary concern. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
In message: <[EMAIL PROTECTED]> "David O'Brien" <[EMAIL PROTECTED]> writes: : The RE's are wanting to ship 5.0 DP#1 w/this patch applied. : If having 'AJ' by default is deemed not useful (by being removed from the : DP), it sounds like we should just turn it off. : : Unless there is strong objection, I plan on committing this. I think we should keep AJ enabled until at least DP2. It has found bugs in the past, and I suspect that a lot of new code is going in between now and then. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
If I remember correctly, it was the plan all along that releases would not have AJ turned on by default. The real question is: should the patch stay in after the release is rolled? Has the AJ default outlived its usefulness in general? -Matt Matthew Dillon <[EMAIL PROTECTED]> :The RE's are wanting to ship 5.0 DP#1 w/this patch applied. :If having 'AJ' by default is deemed not useful (by being removed from the :DP), it sounds like we should just turn it off. : :Unless there is strong objection, I plan on committing this. : :Index: malloc.c :=== :RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.c,v :retrieving revision 1.66 :diff -u -u -1 -r1.66 malloc.c :--- malloc.c 22 Mar 2002 21:53:10 - 1.66 :+++ malloc.c 23 Mar 2002 23:52:40 - :@@ -223,3 +223,3 @@ : /* Abort(), user doesn't handle problems. */ :-static int malloc_abort = 1; :+static int malloc_abort; : :@@ -244,3 +244,3 @@ : /* junk fill ? */ :-static int malloc_junk = 1; :+static int malloc_junk; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VMWare2 seems broken in recent -current
I've just upgraded my i386-current box from about March 13 to a snapshot from late last night. Now when I run vmware, the vmware program dies with: VMware Workstation PANIC: BUG F(571):1607 bugNr=2302 when I try to "Power on" some virtual machine. When I got in today, I cvsup'ed again, removed all of /usr/obj/usr/src, and did another buildworld/installworld. I'm still getting the same error. I also rebuilt the vmware2 port, in case it was some includes-library change. Unfortunately I am in today because I have a major deadline for something on Tuesday (something which I need vmware to do the testing, of course...), so I do not have the time to do some binary-search of buildworlds to figure out what the exact culprit is. (in my case, I can just reboot into the march-13th snapshot of the system, so this issue isn't an immediate problem for me) But I thought I'd mention it in case someone else is about to do a buildworld and would need vmware2 working after it. -- 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
turning off malloc's AJ by default
The RE's are wanting to ship 5.0 DP#1 w/this patch applied. If having 'AJ' by default is deemed not useful (by being removed from the DP), it sounds like we should just turn it off. Unless there is strong objection, I plan on committing this. Index: malloc.c === RCS file: /home/ncvs/src/lib/libc/stdlib/malloc.c,v retrieving revision 1.66 diff -u -u -1 -r1.66 malloc.c --- malloc.c22 Mar 2002 21:53:10 - 1.66 +++ malloc.c23 Mar 2002 23:52:40 - @@ -223,3 +223,3 @@ /* Abort(), user doesn't handle problems. */ -static int malloc_abort = 1; +static int malloc_abort; @@ -244,3 +244,3 @@ /* junk fill ? */ -static int malloc_junk = 1; +static int malloc_junk; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build breaks in bktr_i2c.c
At 2:54 PM -0600 3/23/02, Jim Bryant wrote: >last cvsup, less than an hour ago. > > I started with an empty obj-tree, and I ended up with an error from make being unable to make smbus.h In my case, I just reversed the change which made version 1.3 of: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/bktr/bktr/Makefile although I haven't really checked to see if that was the right fix... -- 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
Re: uma panic
On Sat, Mar 23, 2002 at 09:23:33AM -0800, David O'Brien wrote: > On Sat, Mar 23, 2002 at 12:41:58AM -0800, Kris Kennaway wrote: > > I upgraded the bento package building cluster to a more recent > > -current to try and get packages building again (every other snapshot > > Could you run the actual DP#1 code? This would make sure the packages > match the snapshot, and more so be a test if its readiness. I would have, except at the time DP#1 still included greenvm, so it would have been a complete waste of time. I'll switch over to that at some point soon since it's apparently now been backed out. Kris msg36489/pgp0.pgp Description: PGP signature
Re: kernel build breaks in bktr_i2c.c
just built a -current GENERIC with a patch below. Do not know is it correct or not though. Index: Makefile === RCS file: /home/ncvs/src/sys/modules/bktr/bktr/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- Makefile23 Mar 2002 15:48:32 - 1.3 +++ Makefile23 Mar 2002 22:00:45 - @@ -6,7 +6,7 @@ KMOD= bktr SRCS= bktr_core.c bktr_os.c bktr_audio.c bktr_tuner.c bktr_card.c \ - bktr.h opt_devfs.h opt_bktr.h smbus.h bus_if.h device_if.h \ + bktr.h opt_devfs.h opt_bktr.h bus_if.h device_if.h \ pci_if.h vnode_if.h CLEANFILES= bktr.h %%% -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please fix port compilation problems
Le 23 Mar 02 à 1:20:20 +, Kris Kennaway écrivait : > Please let me know if you think there's something wrong with an error > log; i.e. you think the port should actually compile and something > went wrong on bento. There are two "depend object" errors with imp & imp-devel. They should be fixed by PR ports/35739 & ports/35740. Regards, -- Th. Thomas. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel build breaks in bktr_i2c.c
last cvsup, less than an hour ago. cc -c -O -g -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundary=2 -Werror ../../../dev/bktr/bktr_i2c.c ../../../dev/bktr/bktr_i2c.c: In function `bt848_i2c_attach': ../../../dev/bktr/bktr_i2c.c:87: structure has no member named `i2c_sc' ../../../dev/bktr/bktr_i2c.c:92: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:93: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:101: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:103: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c: In function `bt848_i2c_detach': ../../../dev/bktr/bktr_i2c.c:113: structure has no member named `i2c_sc' ../../../dev/bktr/bktr_i2c.c:119: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:119: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:122: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:122: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c: In function `bti2c_smb_callback': ../../../dev/bktr/bktr_i2c.c:132: structure has no member named `i2c_sc' ../../../dev/bktr/bktr_i2c.c:141: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:142: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:149: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:150: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c: In function `bti2c_iic_callback': ../../../dev/bktr/bktr_i2c.c:165: structure has no member named `i2c_sc' ../../../dev/bktr/bktr_i2c.c:174: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:175: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:182: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:183: dereferencing pointer to incomplete type *** Error code 1 Stop in /usr/src/sys/i386/compile/WAHOO.UNIPROCESSOR. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - "Religious fundamentalism is the biggest threat to international security that exists today." United Nations Secretary General B.B.Ghali, 1995 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCcard whine issued during "halt -p" processing
On Sat, 23 Mar 2002, Andrew R. Reiter wrote: :On Sat, 23 Mar 2002, M. Warner Losh wrote: : ::I wouldn't worry about the messages. They are debugging printfs that ::should really be beind boot verbose or something similar. : :Are there enough debug printfs that would warrant a sysctl tunable for :debug messages? Erm, ignore this question; just cscope'd bootverbose and realized I didn't read the second sentence of your message. Andrew -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCcard whine issued during "halt -p" processing
In message: <[EMAIL PROTECTED]> "Andrew R. Reiter" <[EMAIL PROTECTED]> writes: : On Sat, 23 Mar 2002, M. Warner Losh wrote: : : :I wouldn't worry about the messages. They are debugging printfs that : :should really be beind boot verbose or something similar. : : Are there enough debug printfs that would warrant a sysctl tunable for : debug messages? hw.cardbus.debug: 0 hw.cardbus.cis_debug: 0 hw.pccard.debug: 0 hw.pccard.cis_debug: 0 hw.cbb.debug: 0 Yes :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCcard whine issued during "halt -p" processing
On Sat, 23 Mar 2002, M. Warner Losh wrote: :I wouldn't worry about the messages. They are debugging printfs that :should really be beind boot verbose or something similar. Are there enough debug printfs that would warrant a sysctl tunable for debug messages? Andrew : :Thanks for the info, however. : :Warner : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with "unsubscribe freebsd-current" in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCcard whine issued during "halt -p" processing
I wouldn't worry about the messages. They are debugging printfs that should really be beind boot verbose or something similar. Thanks for the info, however. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCcard whine issued during "halt -p" processing
Afetr building, booting, and doing some reality checks with today's
-CURRENT on my laptop, I issued the command sequence
sudo boot0cfg -s 1 ad0 && sudo halt -p
in order to prepare it to (default to) boot from slice 1 (which has
today's -STABLE on it) and power the machine off (the latter in order
to be able to use a NIC in a PCCard form factor under -STABLE after
having run a NEWCARD-based -CURRENT).
Historically, sometimes this has worked (as in, the machine powers off
OK by itself); other times it spits out a message
The operating system has halted.
Please press any key to reboot.
at which point the "key" that I press is the power switch. :-}
This time, however, what I saw (hand-transcribed) is:
syncing disks... 2 2
done
Uptime: 3m34s
pccbb1: bad Vcc request. ctrl=0x0, status=0x3719
pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44]
The operating system has halted.
Please press any key to reboot.
and the pccbb*-related messages struck me as something I wasn't really
expecting.
In looking through the sources, the "bad Vcc request" message comes from
src/sys/dev/pccbb/pccbb.c:1129; the version of that file that I have is:
$FreeBSD: src/sys/dev/pccbb/pccbb.c,v 1.41 2002/02/20 16:20:27 imp Exp $
but since it hasn't been updated in a while, I don't see how that would
make a significant contribution to determining what happened (bearing in
mind that I'm tracking -CURRENT daily).
I see that Warner had a commit Wed, 20 Mar 2002 11:02:08 -0800 (PST) to
src/sys/pccard/{pccard.c,pcic.c} with the relevant-seeming comment
"Better power code and better power diagnostics" -- but I didn't see the
message Thursday or Friday (when I did the same procedure).
I don't see any problems ascribable to whatever triggered the message,
but I thought I'd mention it in case it indicates a problem
Cheers,
david
--
David H. Wolfskill [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
can't build world on alpha
Anyone have any ideas? I'm trying to build the latest -current (from cvs) on an alpha running 4.3-RELEASE, using 'make buildworld'. -Matt Matthew Dillon <[EMAIL PROTECTED]> cc -O -pipe -mcpu=ev4 -D_open=open -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/FreeBSD/FreeBSD-current/src/alpha/usr\" -DHAIFA -I/usr/obj/FreeBSD/FreeBSD-current/src/alpha/FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../cc_tools -I/FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../cc_tools -I/FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../contrib/gcc.295 -I/FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../contrib/gcc.295/config -c /FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../lib/libc/stdio/mktemp.c -o mktemp.o /FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../lib/libc/stdio/mktemp.c:38: syntax error before string constant /FreeBSD/FreeBSD-current/src/gnu/usr.bin/cc/cc_fbsd/../../../../lib/libc/stdio/mktemp.c:38: warning: data definition has no type or storage class *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uma panic
Kris Kennaway <[EMAIL PROTECTED]> writes: > I upgraded the bento package building cluster to a more recent > -current to try and get packages building again (every other snapshot > I've tried for the last week has either been broken or does not > build). One of the client machines panicked after about an hour under > load: Please add 'kern.sync_on_panic=0' to /etc/sysctl.conf (assuming all your filesystems are either synchronous or soft-updated). It won't stop the panics, but at least you'll avoid the second panic, which may make the first panic easier to debug. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange log message about "bad file descriptor"
On Sat, Mar 23, 2002 at 10:11:25AM -0800, Gregory Neil Shapiro wrote: > sgk> Cvsup was run this morning (23 Mar 02) at 0623 PST. > sgk> After the standard "make" sequence and installation > sgk> of a new kernel. The following appears during the > sgk> boot process (apologies for long lines). > > sgk> Mar 23 09:04:30 12-230-81-20 sm-queue[181]: NOQUEUE: SYSERR(root): fill_fd: >before readcf: fd 1 not open: Bad file descriptor > > This is almost certainly caused by this commit: > > Revision 1.304, Fri Mar 22 23:45:13 2002 UTC by obrien > Branch: MAIN > CVS Tags: HEAD > Changes since 1.303: +5 -5 lines > > Sendmail can be slow to startup. > So start it in the background to speed up booting. > > Apparently, during bootup the tty isn't available to processes started in > the background. The best thing to do is back out this commit. In the mean > time, the warnings can be ignored. Yes, I came to the same conclusion after David Wolfskill pointed out that this is probably related to sendmail. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange log message about "bad file descriptor"
sgk> Cvsup was run this morning (23 Mar 02) at 0623 PST. sgk> After the standard "make" sequence and installation sgk> of a new kernel. The following appears during the sgk> boot process (apologies for long lines). sgk> Mar 23 09:04:30 12-230-81-20 sm-queue[181]: NOQUEUE: SYSERR(root): fill_fd: before readcf: fd 1 not open: Bad file descriptor This is almost certainly caused by this commit: Revision 1.304, Fri Mar 22 23:45:13 2002 UTC by obrien Branch: MAIN CVS Tags: HEAD Changes since 1.303: +5 -5 lines Sendmail can be slow to startup. So start it in the background to speed up booting. Apparently, during bootup the tty isn't available to processes started in the background. The best thing to do is back out this commit. In the mean time, the warnings can be ignored. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
is 'device ether' mandatory now?
Hello, After this commit 'device ether' is mandatory if ever there is no any ethernet or token-ring devices. | luigi 2002/02/18 14:50:13 PST | | Modified files: |sys/net if.c | Log: | When the local link address is changed, send out gratuitous ARPs | to notify other nodes about the address change. Otherwise, they | might try and keep using the old address until their arp table | entry times out and the address is refreshed. | | Maybe this ought to be done for INET6 addresses as well but i have | no idea how to do it. It should be pretty straightforward though. | | MFC-after: 10 days | | Revision ChangesPath | 1.128 +11 -0 src/sys/net/if.c -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uma panic
On Sat, Mar 23, 2002 at 12:41:58AM -0800, Kris Kennaway wrote: > I upgraded the bento package building cluster to a more recent > -current to try and get packages building again (every other snapshot Could you run the actual DP#1 code? This would make sure the packages match the snapshot, and more so be a test if its readiness. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
strange log message about "bad file descriptor"
Cvsup was run this morning (23 Mar 02) at 0623 PST. After the standard "make" sequence and installation of a new kernel. The following appears during the boot process (apologies for long lines). Mar 23 09:04:30 12-230-81-20 sm-queue[181]: NOQUEUE: SYSERR(root): fill_fd: before readcf: fd 1 not open: Bad file descriptor Mar 23 09:04:30 12-230-81-20 sm-msp-queue[183]: NOQUEUE: SYSERR(root): fill_fd: before readcf: fd 1 not open: Bad file descriptor Mar 23 09:04:30 12-230-81-20 sm-queue[181]: NOQUEUE: SYSERR(root): fill_fd: before readcf: fd 2 not open: Bad file descriptor Mar 23 09:04:30 12-230-81-20 sm-msp-queue[183]: NOQUEUE: SYSERR(root): fill_fd: before readcf: fd 2 not open: Bad file descriptor -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uma panic
I think I've run into this pre-UMA, so suspect it's not a UMA panic. I
could be wrong.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Sat, 23 Mar 2002, Kris Kennaway wrote:
> I upgraded the bento package building cluster to a more recent
> -current to try and get packages building again (every other snapshot
> I've tried for the last week has either been broken or does not
> build). One of the client machines panicked after about an hour under
> load:
>
> The kernel and coredump are available for further debugging if needed.
>
> Kris
>
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x1c
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc0204d43
> stack pointer = 0x10:0xcdc39c60
> frame pointer = 0x10:0xcdc39c6c
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = 12 (swi6: tty:sio clock)
> trap number = 12
> panic: page fault
>
> syncing disks... panic: bdwrite: buffer is not busy
> Uptime: 1h0m1s
>
> dumping to dev ad0b, offset 1575424
> dump ata0: resetting devices .. done
> 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234
>233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217
> 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196
>195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179
> 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158
>157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141
> 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120
>119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103
> 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76
>75 74 73 72 71 70 69 68 67 66 65 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
> ---
> #0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:505
> 505 /local0/scratch/usr/src/sys/kern/kern_shutdown.c: No such file or directory.
> (kgdb) bt
> #0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:505
> #1 0xc020d180 in boot (howto=260) at
>/local0/scratch/usr/src/sys/kern/kern_shutdown.c:337
> #2 0xc020d61f in panic (fmt=0xc0378461 "bdwrite: buffer is not busy") at
>/local0/scratch/usr/src/sys/kern/kern_shutdown.c:647
> #3 0xc0242d88 in bdwrite (bp=0xc7741d18) at
>/local0/scratch/usr/src/sys/kern/vfs_bio.c:928
> #4 0xc02dc1ba in ffs_update (vp=0xcf1761b8, waitfor=0) at
>/local0/scratch/usr/src/sys/ufs/ffs/ffs_inode.c:120
> #5 0xc02e9806 in ffs_fsync (ap=0xcdc39b1c) at
>/local0/scratch/usr/src/sys/ufs/ffs/ffs_vnops.c:284
> #6 0xc02e7d8a in ffs_sync (mp=0xceb73000, waitfor=2, cred=0xc7691980,
>td=0xc03b4820) at vnode_if.h:441
> #7 0xc025030d in sync (td=0xc03b4820, uap=0x0) at
>/local0/scratch/usr/src/sys/kern/vfs_syscalls.c:674
> #8 0xc020cdcc in boot (howto=256) at
>/local0/scratch/usr/src/sys/kern/kern_shutdown.c:246
> #9 0xc020d61f in panic (fmt=0xc039681e "%s") at
>/local0/scratch/usr/src/sys/kern/kern_shutdown.c:647
> #10 0xc0334bd4 in trap_fatal (frame=0xcdc39c20, eva=28) at
>/local0/scratch/usr/src/sys/i386/i386/trap.c:841
> #11 0xc03348fd in trap_pfault (frame=0xcdc39c20, usermode=0, eva=28) at
>/local0/scratch/usr/src/sys/i386/i386/trap.c:755
> #12 0xc0334387 in trap (frame={tf_fs = -841940968, tf_es = 16, tf_ds = -842858480,
>tf_edi = 36, tf_esi = 0, tf_ebp = -842818452, tf_isp = -842818484,
> tf_ebx = -841047808, tf_edx = -841047712, tf_ecx = -841047806, tf_eax =
>-841048064, tf_trapno = 12, tf_err = 0, tf_eip = -1071624893, tf_cs = 8,
> tf_eflags = 65538, tf_esp = -853281024, tf_ss = -949504404}) at
>/local0/scratch/usr/src/sys/i386/i386/trap.c:426
> #13 0xc0204d43 in propagate_priority (td=0xcd23f700) at
>/local0/scratch/usr/src/sys/kern/kern_mutex.c:161
> #14 0xc02050c3 in _mtx_lock_sleep (m=0xc767b66c, opts=0, file=0x0, line=0) at
>/local0/scratch/usr/src/sys/kern/kern_mutex.c:389
> #15 0xc02ff746 in zone_timeout (zone=0xc767b5a0) at
>/local0/scratch/usr/src/sys/vm/uma_core.c:232
> #16 0xc030070f in zone_foreach (zfunc=0xc02ff6c8 ) at
>/local0/scratch/usr/src/sys/vm/uma_core.c:1021
> #17 0xc02ff6a5 in uma_timeout (unused=0x0) at
>/local0/scratch/usr/src/sys/vm/uma_core.c:193
> #18 0xc02174af in softclock (dummy=0x0) at
>/local0/scratch/usr/src/sys/kern/kern_timeout.c:187
> #19 0xc01fe2b0 in ithread_loop (arg=0xcd261c80) at
>/local0/scratch/usr/src/sys/kern/kern_intr.c:533
> #20 0xc01fd506 in fork_exit (callout=0xc01fe114 , arg=0xcd261c80,
>frame=0xcdc3
witness panic on Alpha
Fri Mar 22 19:06:37 CET 2002 FreeBSD/alpha (ds10.wbnet) (ttyd0) login: syslogd: /var/log/auth.log: No such file or directory syslogd: /var/log/auth.log: No such file or directory Mar 22 21:55:23 ds10 kernel: pid 27885 (telnetd), uid 0: exited on signal 11 (co re dumped) Mar 22 21:55:30 ds10 kernel: pid 28342 (telnetd), uid 0: exited on signal 11 (co re dumped) syslogd: /var/log/auth.log: No such file or directory syslogd: /var/log/auth.log: No such file or directory panic: blockable sleep lock (sleep mutex) vnode_free_list @ /usr/src/sys/kern/vf s_subr.c:2678 panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> db> tb No such command db> bt No such command db> st Stopped at Debugger+0x38: call_pal osf1_swpipl db> stack No such command db> trace Debugger() at Debugger+0x3c panic() at panic+0x100 witness_lock() at witness_lock+0xb4 _mtx_lock_flags() at _mtx_lock_flags+0xd8 vfree() at vfree+0x30 vm_page_free_toq() at vm_page_free_toq+0x200 vm_page_free() at vm_page_free+0x2c vm_page_alloc() at vm_page_alloc+0x1ac pmap_growkernel() at pmap_growkernel+0x3e8 vm_map_findspace() at vm_map_findspace+0x144 kmem_alloc() at kmem_alloc+0x9c _zget() at _zget+0x244 zalloc() at zalloc+0x78 getnewvnode() at getnewvnode+0x470 ffs_vget() at ffs_vget+0x168 ufs_lookup() at ufs_lookup+0xf78 ufs_vnoperate() at ufs_vnoperate+0x2c vfs_cache_lookup() at vfs_cache_lookup+0x3cc ufs_vnoperate() at ufs_vnoperate+0x2c lookup() at lookup+0x4d0 namei() at namei+0x308 lstat() at lstat+0x50 syscall() at syscall+0x318 XentSys() at XentSys+0x64 --- syscall (190, FreeBSD ELF, lstat) --- --- user mode --- db> -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please fix port compilation problems
On Sat, Mar 23, 2002 at 01:03:01AM -0800, Kris Kennaway wrote: > Hi all, > > With the 5.0 Developer Preview snapshot just around the corner it's > very important that we get as many ports building as possible. There > are a *lot* of easily fixed compilation errors under 5.0 (for example, > over a hundred ports are still broken because of ). In > total there are several hundred ports which compile under 4.x but fail > to compile under 5.0 (I don't have an exact total because I've had > lots of problems getting a full 5.0 package run to complete, due to > instability problems with 5.0, as well as miscellaneous problems with > the cluster). > > Anyone with some spare time please visit > > http://bento.freebsd.org/errorlogs/5-latest/ > > and identify and fix some ports! Please let me know if you think there's something wrong with an error log; i.e. you think the port should actually compile and something went wrong on bento. I should also note that this is a CVS tree from about a week ago (I gave up on it because greenvm was causing massive instability), so if the problem has been fixed already then don't worry about it. I'll run another build immediately after this one finishes. Kris msg36471/pgp0.pgp Description: PGP signature
Please fix port compilation problems
Hi all, With the 5.0 Developer Preview snapshot just around the corner it's very important that we get as many ports building as possible. There are a *lot* of easily fixed compilation errors under 5.0 (for example, over a hundred ports are still broken because of ). In total there are several hundred ports which compile under 4.x but fail to compile under 5.0 (I don't have an exact total because I've had lots of problems getting a full 5.0 package run to complete, due to instability problems with 5.0, as well as miscellaneous problems with the cluster). Anyone with some spare time please visit http://bento.freebsd.org/errorlogs/5-latest/ and identify and fix some ports! Kris msg36470/pgp0.pgp Description: PGP signature
uma panic
I upgraded the bento package building cluster to a more recent
-current to try and get packages building again (every other snapshot
I've tried for the last week has either been broken or does not
build). One of the client machines panicked after about an hour under
load:
The kernel and coredump are available for further debugging if needed.
Kris
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0204d43
stack pointer = 0x10:0xcdc39c60
frame pointer = 0x10:0xcdc39c6c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 12 (swi6: tty:sio clock)
trap number = 12
panic: page fault
syncing disks... panic: bdwrite: buffer is not busy
Uptime: 1h0m1s
dumping to dev ad0b, offset 1575424
dump ata0: resetting devices .. done
254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234
233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217
216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196
195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179
178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158
157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141
140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120
119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103
102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75
74 73 72 71 70 69 68 67 66 65 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
---
#0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:505
505 /local0/scratch/usr/src/sys/kern/kern_shutdown.c: No such file or directory.
(kgdb) bt
#0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:505
#1 0xc020d180 in boot (howto=260) at
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:337
#2 0xc020d61f in panic (fmt=0xc0378461 "bdwrite: buffer is not busy") at
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:647
#3 0xc0242d88 in bdwrite (bp=0xc7741d18) at
/local0/scratch/usr/src/sys/kern/vfs_bio.c:928
#4 0xc02dc1ba in ffs_update (vp=0xcf1761b8, waitfor=0) at
/local0/scratch/usr/src/sys/ufs/ffs/ffs_inode.c:120
#5 0xc02e9806 in ffs_fsync (ap=0xcdc39b1c) at
/local0/scratch/usr/src/sys/ufs/ffs/ffs_vnops.c:284
#6 0xc02e7d8a in ffs_sync (mp=0xceb73000, waitfor=2, cred=0xc7691980, td=0xc03b4820)
at vnode_if.h:441
#7 0xc025030d in sync (td=0xc03b4820, uap=0x0) at
/local0/scratch/usr/src/sys/kern/vfs_syscalls.c:674
#8 0xc020cdcc in boot (howto=256) at
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:246
#9 0xc020d61f in panic (fmt=0xc039681e "%s") at
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:647
#10 0xc0334bd4 in trap_fatal (frame=0xcdc39c20, eva=28) at
/local0/scratch/usr/src/sys/i386/i386/trap.c:841
#11 0xc03348fd in trap_pfault (frame=0xcdc39c20, usermode=0, eva=28) at
/local0/scratch/usr/src/sys/i386/i386/trap.c:755
#12 0xc0334387 in trap (frame={tf_fs = -841940968, tf_es = 16, tf_ds = -842858480,
tf_edi = 36, tf_esi = 0, tf_ebp = -842818452, tf_isp = -842818484,
tf_ebx = -841047808, tf_edx = -841047712, tf_ecx = -841047806, tf_eax =
-841048064, tf_trapno = 12, tf_err = 0, tf_eip = -1071624893, tf_cs = 8,
tf_eflags = 65538, tf_esp = -853281024, tf_ss = -949504404}) at
/local0/scratch/usr/src/sys/i386/i386/trap.c:426
#13 0xc0204d43 in propagate_priority (td=0xcd23f700) at
/local0/scratch/usr/src/sys/kern/kern_mutex.c:161
#14 0xc02050c3 in _mtx_lock_sleep (m=0xc767b66c, opts=0, file=0x0, line=0) at
/local0/scratch/usr/src/sys/kern/kern_mutex.c:389
#15 0xc02ff746 in zone_timeout (zone=0xc767b5a0) at
/local0/scratch/usr/src/sys/vm/uma_core.c:232
#16 0xc030070f in zone_foreach (zfunc=0xc02ff6c8 ) at
/local0/scratch/usr/src/sys/vm/uma_core.c:1021
#17 0xc02ff6a5 in uma_timeout (unused=0x0) at
/local0/scratch/usr/src/sys/vm/uma_core.c:193
#18 0xc02174af in softclock (dummy=0x0) at
/local0/scratch/usr/src/sys/kern/kern_timeout.c:187
#19 0xc01fe2b0 in ithread_loop (arg=0xcd261c80) at
/local0/scratch/usr/src/sys/kern/kern_intr.c:533
#20 0xc01fd506 in fork_exit (callout=0xc01fe114 , arg=0xcd261c80,
frame=0xcdc39d48) at /local0/scratch/usr/src/sys/kern/kern_fork.c:796
(kgdb)
msg36469/pgp0.pgp
Description: PGP signature
Re: SMP ffs_mountfs() broken?
Of course that should be an A7M266D... (its friday, my brain is fried and i think i need to take a sauna...) On Fri, 22 Mar 2002, Lamont Granquist wrote: > GENERIC works, so this looks like an SMP problem. > > Its happening right after the CPU initializes. This is probably the first > SMP code the machine runs? Is hardware incompatibility a good guess? I > would have expected that if someone broke ffs_mountfs() that someone else > would have noticed by now... > > Oh, I forgot to say in my previous message that my motherboard is a > Asus K7M266D. It runs 4.5-STABLE with SMP turned on fine, but only with > MP spec 1.1 and not 1.4. There's a BIOS upgrade which is supposed to fix > Linux + MP spec 1.4 issues which might fix 1.4 for FreeBSD as well. It > could fix this as well maybe? > > On Fri, 22 Mar 2002, Lamont Granquist wrote: > > I'll try to see if this was due to the cvsup or due to SMP. I've got a UP > > kernel from a few weeks ago that works fine. > > > > 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: SMP ffs_mountfs() broken?
Which mobo/chipset ?
* Lamont Granquist <[EMAIL PROTECTED]> [020323 02:14]:
>
> I just cvsupped about an hour ago, built world and built a kernel that was
> GENERIC with 486/586 turned off and SMP and IOAPIC turned on. It crashed
> while trying to mount root. Apologies for mistakes in the following since
> I don't have a serial console and had to write it down:
>
>
> Mounting root from ufs:/dev/ad0s1a
> SMP AP CPU #1 Launched!
> kernel trap 12 with interrupts diabled
> panic: blockable sleep lock (sleep mutex) Giant @ ../../../i386/i386/trap.c:706
> cpuid = 1; lapic.id = 0100
> Debugger("panic")
> Stopped at Debugger+0x41: xorl %eax, %eax
>
> trace showed the watchdog trap and then:
>
> _mtx_lock_sleep
> _mtx_lock_flags
> vn_lock
> spec_open
> ffs_mountfs
> ffs_mount
> ufs_mountroot_try
> ufs_mountroot
> start_init
> fork_exit
> fork_trampoline
>
> (sorry for eliminating all the args and such, but that's a lot of hex
> numbers to write down by hand -- if anyone requests i'll see what i can do
> about getting it off the serial port..)
>
> I've never had this machine successfully running 5.0 with SMP, this was my
> first attempt. My machine is:
>
> 2 x 1.4GHz K7 MP1600+
> 512MB crucial ECC
> Adaptec 39160
> Seagate 36GB drive (not used for my 5.0 box)
> 13GB IBM UDMA66 drive (5.0 is installed on this)
> Geforce2/MX
> Soundblaster
>
> I'll try to see if this was due to the cvsup or due to SMP. I've got a UP
> kernel from a few weeks ago that works fine.
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
__ ___ __
/ //_(_)__ _http://www.kingsqueak.org _/ /__
/ ,< / / _ \/ _ `(_-
