Re: gvinum: adding plex and subdisks to existing volume panic
On Thu, 22 Dec 2005, Ludo Koren wrote:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x40
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc07339c9
stack pointer = 0x10:0xe5f9e840
frame pointer = 0x10:0xe5f9e848
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (g_event)
trap number = 12
panic: page fault
Uptime: 2m32s
Dumping 1022 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336
352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656
672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976
992 1008
#0 doadump () at pcpu.h:160
160 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) add-symbol-file /usr/src/sys/modules/geom/geom_vinum/geom_vinum.ko
0xc072 a9b8
add symbol table from file /usr/src/sys/modules/geom/geom_vinum/geom_vinum.ko
at
.text_addr = 0xc072a9b8
(y or n) y
Reading symbols from /usr/src/sys/modules/geom/geom_vinum/geom_vinum.ko...done.
(kgdb) bt
#0 doadump () at pcpu.h:160
#1 0xc04eaf44 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412
#2 0xc04eb1d8 in panic (fmt=0xc060fcbc %s)
at /usr/src/sys/kern/kern_shutdown.c:568
#3 0xc05ec2f0 in trap_fatal (frame=0xe5f9e800, eva=64)
at /usr/src/sys/i386/i386/trap.c:822
#4 0xc05ec057 in trap_pfault (frame=0xe5f9e800, usermode=0, eva=64)
at /usr/src/sys/i386/i386/trap.c:737
#5 0xc05ebcb9 in trap (frame=
{tf_fs = -1040646120, tf_es = -1037893616, tf_ds = -1038024688, tf_edi =
-1038012416, tf_esi = 0, tf_ebp = -436606904, tf_isp = -436606932, tf_ebx =
-1038077952, tf_edx = 1, tf_ecx = -1066995504, tf_eax = 0, tf_trapno = 12,
tf_err = 0, tf_eip = -1066190391, tf_cs = 8, tf_eflags = 66182, tf_esp =
-1038077952, tf_ss = -1038516864}) at /usr/src/sys/i386/i386/trap.c:427
#6 0xc05dc52a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0xc1f90018 in ?? ()
#8 0xc2230010 in ?? ()
#9 0xc2210010 in ?? ()
I'm afraid that doesn't help me, either, as you can see there's no
debugging information in there (the ?? question marks should be
function calls actually).
Apparently there's a NULL pointer deref somewhere, I'll try to track it
down on my own.
Thanks,
le
--
Lukas Ertl http://homepage.univie.ac.at/l.ertl/
[EMAIL PROTECTED] http://people.freebsd.org/~le/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum: adding plex and subdisks to existing volume panic
On Wed, 21 Dec 2005, Ludo Koren wrote: When I try to do: # gvinum create gvinum.conf it ends up in immediate panic (page fault). The gvinum.conf file: It would be easier to track down this problem if you could provide the place where the panic happens or even better a backtrace. thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ [EMAIL PROTECTED] http://people.freebsd.org/~le/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum: adding plex and subdisks to existing volume panic
On Wed, 21 Dec 2005, Ludo Koren wrote: (kgdb) bt #0 0xc0618252 in doadump () #1 0xc06187dc in boot () #2 0xc0618a70 in panic () #3 0xc07c82bc in trap_fatal () #4 0xc07c8023 in trap_pfault () #5 0xc07c7c65 in trap () #6 0xc07b7bba in calltrap () #7 0xc28d0018 in ?? () #8 0xc27b0010 in ?? () Unfortunately, that doesn't help me at all, since there's no debugging info. Have a look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-kld.html. thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ [EMAIL PROTECTED] http://people.freebsd.org/~le/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 Stable reboots randomly during high load.
On 11/23/05, kama [EMAIL PROTECTED] wrote: Try adding a lot of disk IO too. I believe that the problem lays within that area. I get a load of aprox 6 on that machine. We're having approximately the same config as you have (DL380G3, Dual CPU+HTT, Diablo). Runs happily day and night, throughput is about 1.3TB of news data per day, no crashes for the last couple of months, as I recall. cheers, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 Stable reboots randomly during high load.
On 11/23/05, kama [EMAIL PROTECTED] wrote: On Wed, 23 Nov 2005, Lukas Ertl wrote: We're having approximately the same config as you have (DL380G3, Dual CPU+HTT, Diablo). Runs happily day and night, throughput is about 1.3TB of news data per day, no crashes for the last couple of months, as I recall. On 6.0? I dont get reboots with 5.4. Yes, on 6.0. I was running 5.4 before with no problems either. cheers, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why use 60 sec on da0 during boot?
On 11/9/05, Ingeborg Hellemo [EMAIL PROTECTED] wrote: Fresh new ProLiant dl380 2 CPU/dual core Fresh new FreeBSD 6.0-RELEASE During boot I arrive at da0 at ciss0 bus 0 target 0 lun 0 da0: COMPAQ RAID 1 VOLUME OK Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 34727MB (71122560 512 byte sectors: 255H 32S/T 8716C) then nothing happens for about 60 seconds and then everything proceedes as usual (starting daemons, mounting NFS-disks etc.) I see this behaviour on my DL380s, too. I don't have a fix, but a workaround: disable the floppy drive in the BIOS. cheers, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why use 60 sec on da0 during boot?
On 11/19/05, Jim Pingle [EMAIL PROTECTED] wrote: Lukas Ertl wrote: On 11/9/05, Ingeborg Hellemo [EMAIL PROTECTED] wrote: Fresh new ProLiant dl380 2 CPU/dual core Fresh new FreeBSD 6.0-RELEASE During boot I arrive at da0 at ciss0 bus 0 target 0 lun 0 da0: COMPAQ RAID 1 VOLUME OK Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 34727MB (71122560 512 byte sectors: 255H 32S/T 8716C) then nothing happens for about 60 seconds and then everything proceedes as usual (starting daemons, mounting NFS-disks etc.) I see this behaviour on my DL380s, too. I don't have a fix, but a workaround: disable the floppy drive in the BIOS. I also see this behavior, though I see it on a few systems which are all Dual CPU PIII 800MHz. They each have different SCSI or RAID controllers (one has an amr card, one has an mlx controller, and one I believe just had an ahc controller. The motherboards all have Intel serverworks chipsets. These are all fresh installs of FreeBSD 6.0 (and updated to -STABLE). It happens with GENERIC and with a lightly modified custom kernel (remove unused cpu types, add smp) In each case, during this pause the floppy light is on solid, so I'm not sure it has anything to do with the SCSI controller(s). It has nothing to do with the SCSI controller, it's all about the floppy drive. It seems like the fdc driver doesn't recognize that there's no disk in the drive and tries to access it on and on and on. As I said, disable the floppy drive in the BIOS (or even put a floppy into the drive), then the boot process goes on as usual. cheers, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 gvinum mirror problem
On Fri, 4 Nov 2005, Ben Kelly wrote: I just upgraded my RELENG_5 box to RELENG_6. This machine has two drives mirrored using gvinum. Everything was working well under 5.x, but when I booted to 6.x I noticed only one drive was receiving transactions. I see no error messages in my logs. Running 'gvinum list' produces the following strange output: Please send me the output of: sysctl -b kern.geom.confdot thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ [EMAIL PROTECTED] http://people.freebsd.org/~le/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
MySQL crashes on 6.0-RC1
Hi, I'm not sure if this should go to -stable or -current, but since 6.0-RELEASE is around the corner I guess this is the right list. Well, I'm having a fresh 6.0-RC1 on an SMP machine, and installed a plain mysql41-server from ports. Now, if I connect remotely from a machine using a plain mysql41-client, the server simply dies - no error messages, nothing, just a restart of the mysqld process (done by the safe_mysqld wrapper). Connecting from the same client to a different machine running mysql41-server on 6.0-BETA4 works fine. Anyone ever seen that? Maybe a threads issue? cheers, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MySQL crashes on 6.0-RC1
On 10/12/05, I wrote: Now, if I connect remotely from a machine using a plain mysql41-client, the server simply dies - no error messages, nothing, just a restart of the mysqld process (done by the safe_mysqld wrapper). Please ignore the noise. One of my cow-orkers had apparently configured /etc/hosts.allow, so that it would deny connections to any service on the host apart from sshd. Still doesn't explain why the mysqld process simply restarts, but now it works fine. thanks, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3 CPU not recognized
On Fri, 7 Jan 2005 12:40:57 +1100, Peter Jeremy [EMAIL PROTECTED] wrote: On Fri, 2005-Jan-07 00:20:12 +0100, Lukas Ertl wrote: Nevermind. It seems I now explicitely need cpu I686_CPU in my kernel. You should have always needed that. Interestingly, I didn't have it in the old kernel, and it worked. cheers, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
VIA C3 CPU not recognized
Hello, 5.3-STABLE refuses to recognize my VIA C3 CPU, it panics immediately after the loader with CPU class not configured Last known working kernel is from Sun Nov 7 16:27:23 CET 2004, it recognizes the CPU as CPU: VIA C3 Samuel 2 (601.37-MHz 686-class CPU) Origin = CentaurHauls Id = 0x673 Stepping = 3 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX The new kernel says it's an unknown class CPU. I haven't changed my kernel config since I built the old kernel, so maybe I have overlooked some new option for VIA CPUs, but I couldn't find a change at first glance. Any ideas? thanks, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3 CPU not recognized
On Thu, 6 Jan 2005 23:36:43 +0100, Lukas Ertl [EMAIL PROTECTED] wrote: 5.3-STABLE refuses to recognize my VIA C3 CPU, it panics immediately after the loader with CPU class not configured Nevermind. It seems I now explicitely need cpu I686_CPU in my kernel. thanks, le ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
On Mon, 20 Dec 2004, Matthias Schuendehuette wrote: Am Montag, 20. Dezember 2004 00:04 schrieb Nikolaj Hansen: [...] The whole problem is, I cannot mount any thing without doing it this way. The reason for this is, as you pointed out , that my disk setup is different than the norm: $ sudo bsdlabel da1s1 Password: # /dev/da1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 51200004.2BSD 2048 16384 32008 b: 1228535 512000 swap c: 177678270unused0 0 # raw part... h: 16027292 1740535 vinum Both sides of the mirror are made like this. This disk setup seems to me perfectly legal. Your vinum-partition has an offset of 1740535 which is != 0, that's all that I meant. Yes, this looks quite ok. But I'm still not sure what is actually happening. Can you please describe me again what the configuration looks like after you have the problem (gvinum printconfig)? Do you run the latest -STABLE? thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ [EMAIL PROTECTED] http://people.freebsd.org/~le/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.10 - 5.3 migration; what happens to vinum volumes?
On Wed, 1 Dec 2004 22:42:23 +, Ceri Davies [EMAIL PROTECTED] wrote: On Wed, Dec 01, 2004 at 11:38:38PM +0100, Lukas Ertl wrote: Your config looks sane enough that it shouldn't be a problem to switch to gvinum. Edit your fstab and put geom_vinum_load=YES into /boot/loader.conf, that's enough. Cool. I'll be taking backups anyway so I'll try it that way; do you want a bug report if it doesn't work? Yes, please. cheers, le ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.10 - 5.3 migration; what happens to vinum volumes?
On Thu, 25 Nov 2004 20:58:36 +, Ceri Davies [EMAIL PROTECTED] wrote: I have a 4.10-STABLE machine that I want to migrate to 5.3-STABLE. Most of the bases are covered, but I'm not sure what to expect for my vinum volumes. I don't have anything esoteric (see attached config), but can I just expect sed -i.bak -e 's/vinum/gvinum/' /etc/fstab to leave me with working volumes? Hi Ceri, sorry for the late reply, I don't follow stable@ directly, so if there's any vinum question, please add a cc: to [EMAIL PROTECTED] (those messages will get highlighted so I have a chance to notice them earlier). Your config looks sane enough that it shouldn't be a problem to switch to gvinum. Edit your fstab and put geom_vinum_load=YES into /boot/loader.conf, that's enough. cheers, le ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5.3-STABLE frozen on heavy network load
Hi, I'm seeing complete freezes on a 5.3-STABLE SMP (with HTT) kernel from Fri Nov 12. The machine is acting as a newsserver, thus it has heavy network and disk load. With the help of MP_WATCHDOG I was able to get a backtrace: Watchdog timer: 2 Watchdog timer: 1 Watchdog timer: 0 Watchdog firing! NMI ... going to debugger [thread 100305] Stopped at slab_zalloc+0x2c: setz%al db where slab_zalloc(c0c1fb00,2,c0c1fb00,c0c1fb00,0) at slab_zalloc+0x2c uma_zone_slab(c0c1fb00,2) at uma_zone_slab+0xd0 uma_zalloc_internal(c0c1fb00,c39b1100,2,0,c39b1100) at uma_zalloc_internal+0x4d uma_zalloc_arg(c0c1fb00,c39b1100,2) at uma_zalloc_arg+0x2f8 mb_init_pack(c39b1100,100,2) at mb_init_pack+0x1d uma_zalloc_internal(c0c1fc60,e93d2c74,2,11a8,0) at uma_zalloc_internal+0xe3 uma_zalloc_arg(c0c1fc60,e93d2c74,2) at uma_zalloc_arg+0x2f8 sosend(c391f510,0,c3f3ad80,0,0) at sosend+0x33d soo_write(c54caae4,c3f3ad80,c3858c80,0,c40897d0) at soo_write+0x62 writev(c40897d0,e93d2d14,3,c,202) at writev+0xc6 syscall(2f,2f,2f,1,1) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x1f The kgdb debug log can be found at http://people.freebsd.org/~le/debug.log. The coredump and the kernel is still available if I should send more info. Thanks, le ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3-STABLE frozen on heavy network load
On Wed, 17 Nov 2004 10:22:14 + (GMT), Robert Watson [EMAIL PROTECTED] wrote: On Wed, 17 Nov 2004, Lukas Ertl wrote: I'm seeing complete freezes on a 5.3-STABLE SMP (with HTT) kernel from Fri Nov 12. The machine is acting as a newsserver, thus it has heavy network and disk load. Do you know if the freeze happens with 5.3-RELEASE as released? No, as I went directly from some 5-CURRENT to RELENG_5. If you set 'debug.mpsafenet=0', do the freezes keep happening? What happens if you run with INVARIANTS on? I'll check that. Is the system too slow with WITNESS to run your workload? Unfortunately, yes. Could you send dmesg output? Can be found at http://people.freebsd.org/~le/newscore.dmesg. Do you have an estimate of how long it takes to go from boot to hang? Somewhere between one, two days and one, two weeks. If/when this recurs, could I get you to run the following commands in DDB, and send output: - ps - show lockedvnods - show pcpu - show pcpu X, for each valid value of X (0 ... maxcpus-1) - do trace on each thread active on a CPU - do trace on any network device driver ithread, on the netisr, and any other thread that appears to be involved in network activity OK, will do. Using the current core, could you go to frame #29, and print *td, *td-td_proc, *uio, *active_cred, and *fp. Go to frame #28 and print *so. If possible, please keep this dump around, I may also ask you to inspect *so_pcb once we know what to cast it to (given that it's a news server, could well be TCP, in which cast *(struct inpcb *)so-so_pcb, as well as the tcpcb reached through that). Can be found at http://people.freebsd.org/~le/debug2.log. Oh, one more thing that would be useful: if you compile with BREAK_TO_DEBUGGER, are you able to get into the debugger using a console break or a serial break? If so, which? I assume that because you're using MP_WATCHDOG, you can't, but it's worth asking. Right now, syscons requires Giant, so if you can get into the debugger via the serial link but not syscons, it will suggest something is spinning with Giant. Unfortunately, I don't have a serial link available. MP_WATCHDOG was my last resort to get at some info. Hope that helps, thanks, le ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum performance
On Sun, 30 Mar 2003, Dag-Erling Smørgrav wrote: Lukas Ertl [EMAIL PROTECTED] writes: I'm currently testing with prime stripe sizes, but it doesn't seem to help. I additionally added options AHC_ALLOW_MEMIO to the kernel, and it has raised write performance in the single-disk case (although I'm not happy with that one either; I expected a disk on a U160 controller to pump out more than ~65MB/s). Does the data sheet for your disk indicate that it can in fact write much faster than that? Well, the HP/Compaq webpages are full of marketing speech wrt that, but since these disks are U320 disks, they should perform better I think. The speed at which data is actually written to the media is much lower than the bus speed - the bus speed *has* to be higher to accomodate multiple devices. Ok, that's reasonable. best regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universität Wien http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
make buildworld fails
Hi, "make buildworld" constantly fails on my 4.2-STABLE machine. I cvsup'ed freshly, but the problem persists. Here is the error log: -- stage 4: make dependencies -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.00503 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 par-depend === share/info === include === include/rpcsvc === lib === lib/csu/i386-elf === lib/libcom_err === lib/libcom_err/doc === lib/libcrypt === lib/../secure/lib/libcrypt === lib/msun === lib/libmd === lib/libncurses === lib/libradius === lib/libskey === lib/libtacplus === lib/libutil === lib/compat === lib/compat/compat1x === lib/compat/compat20 === lib/compat/compat21 === lib/compat/compat22 === lib/compat/compat3x.i386 === lib/libalias === lib/libatm === lib/libc === lib/libc_r === lib/libcalendar === lib/libcam === lib/libcompat === lib/libdevstat === lib/libdisk === lib/libedit === lib/libfetch === lib/libform === lib/libftpio === lib/libgnumalloc === lib/libipsec === lib/libipx === lib/libisc === lib/libkvm === lib/libmenu === lib/libncp === lib/libnetgraph === lib/libopie === lib/libpam === lib/libpam/modules === lib/libpam/modules/pam_cleartext_pass_ok === lib/libpam/modules/pam_deny === lib/libpam/modules/pam_opie === lib/libpam/modules/pam_permit === lib/libpam/modules/pam_radius === lib/libpam/modules/pam_skey === lib/libpam/modules/pam_ssh === lib/libpam/modules/pam_tacplus === lib/libpam/modules/pam_unix === lib/libpam/libpam === lib/libpanel === lib/libpcap === lib/libposix1e === lib/libresolv === lib/librpcsvc === lib/libsmdb === lib/libsmutil === lib/libss === lib/libstand === lib/libtelnet === lib/libusb === lib/libvgl === lib/libwrap === lib/libxpg4 === lib/liby === lib/libz === bin === bin/cat rm -f .depend mkdep -f .depend -a-I/usr/obj/usr/src/i386/usr/include /usr/src/bin/cat/cat.c cd /usr/src/bin/cat; make _EXTRADEPEND echo cat: /usr/obj/usr/src/i386/usr/lib/libc.a .depend === bin/chio rm -f .depend mkdep -f .depend -a-I/usr/src/bin/chio/../../sys -I/usr/obj/usr/src/i386/usr/include /usr/src/bin/chio/chio.c cpp: Memory exhausted. mkdep: compile failed *** Error code 1 Stop in /usr/src/bin/chio. *** Error code 1 /usr/obj was deleted before "make buildworld". The last time I built world was Nov 21 (from 4.2-RELEASE to -STABLE). A friend of mine suggested that my mkdep binary might be broken. Any tips? lg, le -- Lukas Ertl eMail: [EMAIL PROTECTED] WWW-Redaktion Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID)Fax.: (+43 1) 4277-9140 der Universitt Wien To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make buildworld fails
On Tue, 23 Jan 2001, Simon Loader wrote: Lukas Ertl wrote: Hi, "make buildworld" constantly fails on my 4.2-STABLE machine. I cvsup'ed freshly, but the problem persists. Here is the error log: -I/usr/obj/usr/src/i386/usr/include /usr/src/bin/chio/chio.c cpp: Memory exhausted. How much memory is in this box ? and what is running at the time of compilation ? Sorry, I should have mentioned before: 96MB RAM, 128MB Swap. It looks ok while compiling, I tried in single user mode, too (where 96MB should be quite enough). If I try to issue the mkdep command on the shell in the chio dir it immediatly exits with the same error message. lg, le -- Lukas Ertl eMail: [EMAIL PROTECTED] WWW-Redaktion Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID)Fax.: (+43 1) 4277-9140 der Universitt Wien To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
