Problem compiling
Hi, My box hangs up solid when recompiling my kernel to add pcm driver. I got the latest src tree though cvsup and I followed the standard procedure to recompile my new kernel to include pcm I can do a /usr/sbin/config MYNEWKERNEL Then in /usr/src/sys/compile/MYNEWKERNEL I can do make depend -- works fine, but as soon as I do make, it hangs after 3 miniutes of compiling WHAT IS WRONG or is there a bug in the latest source ( to do with pcm ) I have a sound blaster live and I really need to get it working in FreeBSD Can anyone please help Adriaan Erasmus -
Re: Crash dumps during initialisation
I think we might be talking at cross-purposes here. What does the kernel do if it panics before the /etc/rc script is run ? (i.e. before the dumpon command is issued ). I can't believe that it reads /etc/rc.conf and locates the dump_dev entry to determine where it should put the crash dump. In 4.4BSD one could specify: config kernel root on device swap on device dump on device but this no longer exists in FreeBSD ? Is this right, and why ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crash dumps during initialisation
"Newton, Harry" wrote: I think we might be talking at cross-purposes here. What does the kernel do if it panics before the /etc/rc script is run ? (i.e. before the dumpon command is issued ). I can't believe that it reads /etc/rc.conf and locates the dump_dev entry to determine where it should put the crash dump. In 4.4BSD one could specify: config kernel root on device swap on device dump on device but this no longer exists in FreeBSD ? Is this right, and why ? We are missing some infrastructure to get this to work really early in the boot sequence - how early do you need? It should be possible to come up with some tweaks so that we can dump right after the device that we want to dump to has probed its disk label to get the partition sizes etc. Exactly when this happens is something I am not yet sure of. With some tweaks it should be moderately easy to get dumps enabled at the point where boot -v says "Creating DISK xxx" and your dump device is shown.. at least for drivers that use the minidisk layer. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
We are exporting quality Hanger for cloth, pants
Dear Sir or Madam, Happy New Year! Here we send all the best wish to you. Trend Hanger, as a professional hanger manufacturer in China specializes in producing and designing various kinds of non-slip coated and chrome-plated metal frame clothes hangers. The company has been in the business for almost 10 years now. With experienced staff and workers, we always provide our customers from all over the world with good service, excellent quality and competitively-priced products. Today, people care a lot about environmental protection, and more and more people would choose to use low-waste materials, impressive and well-designed products. We are proud to say ours are among them. For this reason, during the past several years our selling records are quite well, and now the business is growing even faster than before--simply because our series of products are proven to be reliable and worthwhile in our consumers' eyes. Furthermore, we always observe a strict quality control system all throughout our production process. Each product must be carefully examined and tested in each stage so as to ensure excellent quality and nice packing order for our customers. If you are interested in our products, please do not hesitate to contact us. We are anxious to establish long-term, equal and mutual beneficial business relationship with you. Best wishes, Trend Hanger Manufacturer Contact Person: Mr Steve, Phoenix Sales Manager Zhen An Industrial Zone, Foshan City, Guangdong Province, China 528000 Tel: (86 757) 3982666 Fax: (86 757) 2282667 Email: [EMAIL PROTECTED] http://www.bosunnet.com/trendhanger/index/contacts.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
We are exporting quality Hanger for cloth, pants
Dear Sir or Madam, Happy New Year! Here we send all the best wish to you. Trend Hanger, as a professional hanger manufacturer in China specializes in producing and designing various kinds of non-slip coated and chrome-plated metal frame clothes hangers. The company has been in the business for almost 10 years now. With experienced staff and workers, we always provide our customers from all over the world with good service, excellent quality and competitively-priced products. Today, people care a lot about environmental protection, and more and more people would choose to use low-waste materials, impressive and well-designed products. We are proud to say ours are among them. For this reason, during the past several years our selling records are quite well, and now the business is growing even faster than before--simply because our series of products are proven to be reliable and worthwhile in our consumers' eyes. Furthermore, we always observe a strict quality control system all throughout our production process. Each product must be carefully examined and tested in each stage so as to ensure excellent quality and nice packing order for our customers. If you are interested in our products, please do not hesitate to contact us. We are anxious to establish long-term, equal and mutual beneficial business relationship with you. Best wishes, Trend Hanger Manufacturer Contact Person: Mr Steve, Phoenix Sales Manager Zhen An Industrial Zone, Foshan City, Guangdong Province, China 528000 Tel: (86 757) 3982666 Fax: (86 757) 2282667 Email: [EMAIL PROTECTED] http://www.bosunnet.com/trendhanger/index/contacts.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Anybody else seeing a broken /dev/lpt with SMP on -current?
On Fri, 12 Jan 2001, John Baldwin wrote:
On 13-Jan-01 Jordan Hubbard wrote:
I've actually been seeing this for about 2 months now but only just
now got motivated enough to enable crashdumps and get some information
on what happens whenver I try to use the printer attached to my (sadly :)
-current SMP box:
IdlePTD 3682304
initial pcb at 2e70e0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x8640
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc8dc8676
stack pointer = 0x10:0xc8280f88
frame pointer = 0x10:0xc8280f9c
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 = 12322 (irq7: lpt0)
trap number = 12
panic: page fault
cpuid = 0; lapic.id =
boot() called on cpu#0
If anybody wants a fuller traceback then I'll compile up a kernel with
debugging symbols, but it's going to be pretty sparse anyway since it
basically only shows the trap() from the page fault and the subsequent
panic.
All the other traces show the kerenl having returned to an address that is
beyongd the end of the kernel (which causes the page fault) meaning that the
stack is fubar'd, so the trace isn't meaningful anyways. :( Knowing how and
why the lpd interrupt handler trashes the stack is the useful info, and with
teh stack already trashed, I don't know of an easy way to figure that out.
Suggestions welcome.
This may be cause by the lpt driver (ab)using BUS_SETUP_INTR() on every
write(). The interrupt system can't handle this. I noticed the following
symptoms:
- stray irq7's from when the driver interrupt isn't attached (BUS_SETUP_INTR()
for ppbus first tears down any previously set up handler).
- under UP, a slow memory leak from not freeing ih_name in inthand_remove().
Fixed in the enclosed patch.
- under SMP with 1 cpu, panics in various places due to the process table
filling up with undead ithreads. Worked around in the enclosed patch.
This bug should go away almost automatically when interrupt handling
actually works. Use something like "dd if=/dev/zero of=/dev/lpt0 bs=1"
to see this bug. Use a small value for kern.maxproc to see it quickly.
- "cp /dev/zero /dev/lpt0 " caused about 50% interrupt overhead. Under
UP, interactive response was not noticeably affected, but under SMP with
1 cpu, echoing of keystrokes in /bin/sh in single user mode took a few
hundred msec.
Index: dev/ppbus/lpt.c
===
RCS file: /home/ncvs/src/sys/dev/ppbus/lpt.c,v
retrieving revision 1.20
diff -c -2 -r1.20 lpt.c
*** dev/ppbus/lpt.c 2000/12/07 22:33:12 1.20
--- dev/ppbus/lpt.c 2001/01/15 02:44:40
***
*** 70,73
--- 70,76
#include sys/conf.h
#include sys/kernel.h
+ #include sys/mutex.h
+ #include sys/proc.h
+ #include sys/resourcevar.h
#include sys/uio.h
#include sys/syslog.h
***
*** 759,762
--- 762,797
device_printf(lptdev, "handler registration failed, polled
mode.\n");
sc-sc_irq = ~LP_USE_IRQ;
+ }
+
+ /*
+* XXX setting up interrupts is a very expensive operation and
+* shouldn't be done here. Despite its name, BUS_SETUP_INTR()
+* for this bus both sets up and tears down interrupts (it
+* first tears down any already-setup interrupt). This
+* involves exiting from any existing ithread and starting a
+* new one. The exit is done lazily, and at least under SMP,
+* writing tinygrams resulted in ithreads being created faster
+* than they were destroyed, resulting in assorted panics
+* depending on where the resource exhaustion was detected.
+*
+* Yield so that the ithreads get a chance to exit.
+*
+* XXX following grot cloned from uio_yield().
+*/
+ {
+ struct proc *p;
+ int s;
+
+ p = curproc;
+ s = splhigh();
+ mtx_enter(sched_lock, MTX_SPIN);
+ DROP_GIANT_NOSWITCH();
+ p-p_priority = p-p_usrpri;
+ setrunqueue(p);
+ p-p_stats-p_ru.ru_nivcsw++;
+ mi_switch();
+ mtx_exit(sched_lock, MTX_SPIN);
+ PICKUP_GIANT();
+ splx(s);
}
}
Index: i386/isa/intr_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/isa/intr_machdep.c,v
retrieving
Darn Soundblaster Live :(
I still have problems compiling my kernel. All I want to do is add a pcm device I have a Soundblaster Live and I must add a pcm device in my new kernel config file. Every time I make the thing hangs up. I never had this problem b4 and I think its has something to do with my CPU choice in my config file so here is the million dollar question. If I have a Celeron 400 which CPU type should I choose i586 or i686 HELP !!! Adriaan Erasmus --====-- I would change the world, but God would never give me the source code.
Re: Darn Soundblaster Live :(
try enabling both and seeing if that fixes it?
On Mon, 15 Jan 2001, Adriaan Erasmus wrote:
I still have problems compiling my kernel.
All I want to do is add a pcm device
I have a Soundblaster Live and I must add a pcm device in my new kernel config file.
Every time I make the thing hangs up. I never had this problem b4 and I think its
has something to do with my CPU choice in my config file so here is the million
dollar question.
If I have a Celeron 400 which CPU type should I choose
i586 or i686
HELP !!!
Adriaan Erasmus
--====--
I would change the world,
but God would never give
me the source code.
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: latest buildkernel
On Sun, 14 Jan 2001, Kris Kennaway wrote: On Sun, Jan 14, 2001 at 08:50:06PM -0500, Dibble wrote: How would i go about fixing this? Actually build a 5.0 userland, not a 4.x one as you seem to have :-) Make sure you are following the upgrade instructions precisely, located in /usr/src/UPDATING. Kris I am still getting an error, but a different one. I am following the directions exactly from /etc/UPDATING. When I make buildkernel, I get: = agp make: don't know how to make @/pci/pcivar.h. Stop ***Error code 2 Stop in /usr/src/sys/modules ***Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC ***Error code 1 Stop in /usr/src ***Error code 1 Stop in /usr/src ### Jeff Lee [EMAIL PROTECTED] Public Key: http://www.prism.gatech.edu/~gte384v/pubkey.acs To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Buildworld failure as of 01-15-2001 @ 8:30 CST
I just installed the FreeBSD 5.0-20010107-CURRENT snapshot and have cvsup'd to the latest source (as of subject). Buildworld fails as below: -- stage 4: populating /usr/obj/usr/src/i386/usr/include -- 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/li b:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexe c PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 DESTDIR=/usr/obj/usr/s rc/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:/bi n:/u sr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks includes cd /usr/src/include;make -B all install creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys /conf/newvers.sh;echo "$COPYRIGHT" osreldate.h; echo \#'undef __FreeBSD_version' osreldate.h; echo \#'define __FreeBS D_version' $RELDATE osreldate.h === rpcsvc rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h rpcgen: cannot find any C preprocessor (cpp) *** Error code 1 Stop in /usr/src/include/rpcsvc. *** Error code 1 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Tom Veldhouse [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel source
Hi, As you have noticed, I am a fairly new FreeBSD user, I am a Linux Guru though but BSD is more powerfull and I tend to use just BSD in the future. I will post a lot of msg's in the future but I have one question. Where can I find a kernel source tree that will work with my Sound Blaster Live Sound Card. I run FreeBSD 4.1.1-STABLE and its kernel source doesn't support the pcm driver ?!? I did upgrade to the latest CURRENT but that just hangs my machine ( another ?!? ) I am confused - what is the problem with BSD or is it me ? Adriaan Erasmus - I would change the world, but God would never give me the source code.
Re: console freeze
John Baldwin [EMAIL PROTECTED] wrote: } } On 12-Dec-00 Nicolas Souchu wrote: } Hi there, } } I did browse the lists but found nothing about my problem. } Compiling GENERIC of 5.0 works correctly but once I remove } most of uneeded hardware, the console/kbd freeze. } } I join the MACHINE file and the output. } } I even tried to change the graphic card to a PCI S3, same. } } I can get the getty on the serial line, so I tried vidcontrol -i } on it. It reports stupid info. } } Is there something I can try? } } You haven't setup device hints. You can either statically compile them into } your kernel or copy GENERIC.hints to /boot/device.hints and edit it } appropriately. Has there been any resolution to this? I've been having this problem ever since the SMPng stuff went into the tree. I have no success in getting my splash screen to work anymore or in changing video modes with vidcontrol. The splash_bmp KLD always reports the following: module_register_init: MOD_LOAD (splash_bmp, c037f824, 0) error 2 I have done a careful comparison of GENERIC.hints and the /boot/device.hints that I made back when it became a requirement. I've searched the archives and come up empty. I also read cvs-all faithfully, and while I have gotten backed up on mail due to a short vacation here and there, I haven't seen any related commits. What have I missed in keeping up to date? -Patrick Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel source
* Adriaan Erasmus [EMAIL PROTECTED] [010115 07:17] wrote: Hi, I will post a lot of msg's in the future but I have one question. Where can I find a kernel source tree that will work with my Sound Blaster Live Sound Card. I run FreeBSD 4.1.1-STABLE and its kernel source doesn't support the pcm driver ?!? I did upgrade to the latest CURRENT but that just hangs my machine ( another ?!? ) ok, oops. -CURRENT isn't really for BSD newbies, what you wanted to do was upgrade to the latest -STABLE: http://www.freebsd.org/handbook/cutting-edge.html (read the entire chapter) I am confused - what is the problem with BSD or is it me ? Well it's sorta BSD's fault for being a pain with -CURRENT, but it's your fault for running -CURRENT without having the necessary kernel-foo to do so at the moment. :) best of luck, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld failure as of 01-15-2001 @ 8:30 CST
On Mon, Jan 15, 2001 at 08:37:43AM -0600, Thomas T. Veldhouse wrote:
I just installed the FreeBSD 5.0-20010107-CURRENT snapshot and have cvsup'd
to the latest source (as of subject). Buildworld fails as below:
Do not manually do anything to get around this yet.
Please apply and try this patch. Report here, if it works or not.
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.179
diff -u -r1.179 Makefile.inc1
--- Makefile.inc1 2000/12/03 20:29:31 1.179
+++ Makefile.inc1 2001/01/15 17:39:37
@@ -564,7 +564,7 @@
build-tools:
.for _tool in bin/csh bin/sh ${_games} gnu/usr.bin/cc/cc_tools ${_fortran} \
-${_libroken4} ${_libkrb5} lib/libncurses ${_share}
+usr.bin/rpcgen ${_libroken4} ${_libkrb5} lib/libncurses ${_share}
cd ${.CURDIR}/${_tool}; ${MAKE} build-tools
.endfor
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
number of processes forked since boot
Hi,
I wish to obtain number of processes forked since boot from userland.
So, I made a patch to intend to commit.
Any comment?
Index: lib/libc/gen/sysctl.3
diff -u lib/libc/gen/sysctl.3.orig lib/libc/gen/sysctl.3
--- lib/libc/gen/sysctl.3.orig Fri Jan 12 02:39:22 2001
+++ lib/libc/gen/sysctl.3 Tue Jan 16 02:13:19 2001
@@ -294,6 +294,7 @@
.It "KERN\_UPDATEINTERVAL integer no"
.It "KERN\_VERSION string no"
.It "KERN\_VNODE struct vnodeno"
+.It "KERN\_NFORKS integer no"
.El
.Pp
.Bl -tag -width 6n
@@ -445,6 +446,8 @@
.Va struct vnode *
followed by the vnode itself
.Va struct vnode .
+.It Li KERN_NFORKS
+Number of processes forked.
.El
.Ss CTL_MACHDEP
The set of variables defined is architecture dependent.
Index: sbin/sysctl/sysctl.8
diff -u sbin/sysctl/sysctl.8.orig sbin/sysctl/sysctl.8
--- sbin/sysctl/sysctl.8.orig Fri Jan 12 02:42:23 2001
+++ sbin/sysctl/sysctl.8Tue Jan 16 02:13:19 2001
@@ -145,6 +145,7 @@
.It "kern.bootfile string yes
.It "kern.corefile string yes
.It "kern.logsigexit integer yes
+.It "kern.nforks integer no
.It "vm.loadavgstruct no
.It "hw.machinestring no
.It "hw.model string no
Index: sys/kern/kern_fork.c
diff -u sys/kern/kern_fork.c.orig sys/kern/kern_fork.c
--- sys/kern/kern_fork.c.orig Fri Jan 12 02:46:53 2001
+++ sys/kern/kern_fork.cTue Jan 16 02:30:26 2001
@@ -146,6 +146,9 @@
intnprocs = 1; /* process 0 */
static int nextpid = 0;
+static unsigned int nforks = 0;
+SYSCTL_UINT(_kern, KERN_NFORKS, nforks, CTLFLAG_RD, nforks, 0, "");
+
/*
* Random component to nextpid generation. We mix in a random factor to make
* it a little harder to predict. We sanity check the modulus value to avoid
@@ -277,6 +280,8 @@
}
newproc-p_vmspace = NULL;
+
+ nforks++;
/*
* Find an unused process ID. We remember a range of unused IDs
Index: sys/sys/sysctl.h
diff -u sys/sys/sysctl.h.orig sys/sys/sysctl.h
--- sys/sys/sysctl.h.orig Fri Jan 12 02:48:41 2001
+++ sys/sys/sysctl.hTue Jan 16 02:13:19 2001
@@ -328,7 +328,8 @@
#defineKERN_PS_STRINGS 32 /* int: address of PS_STRINGS */
#defineKERN_USRSTACK 33 /* int: address of USRSTACK */
#defineKERN_LOGSIGEXIT 34 /* int: do we log sigexit procs? */
-#define KERN_MAXID 35 /* number of valid kern ids */
+#define KERN_NFORKS35 /* uint: number of forked */
+#define KERN_MAXID 36 /* number of valid kern ids */
#define CTL_KERN_NAMES { \
{ 0, 0 }, \
@@ -366,6 +367,7 @@
{ "ps_strings", CTLTYPE_INT }, \
{ "usrstack", CTLTYPE_INT }, \
{ "logsigexit", CTLTYPE_INT }, \
+ { "nforks", CTLTYPE_UINT }, \
}
/*
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Darn Soundblaster Live :(
Every time I make the thing hangs up. I never had this problem b4 and I think its has something to do with my CPU choice in my config file so here is the million dollar question. From when is your current -current install? (no pun intended) I seem to recall people not being able to build anything without hangs not too long ago. Try installing 4.2 from binary distributions over your -current, and then CVSup and build a brand spanking new -current. If I have a Celeron 400 which CPU type should I choose i586 or i686 CPU_I686 586 is Pentium, 686 is Pentium Pro, and Pentium II and up (Celeron started with having a P2 core with less cache IIRC) DocWilco
Re: Buildworld failure as of 01-15-2001 @ 8:30 CST
Sorry, I still get the same error.
=== include/rpcsvc
rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/klm_prot.x -o klm_prot.h
rpcgen: cannot find any C preprocessor (cpp)
*** Error code 1
Stop in /usr/src/include/rpcsvc.
*** Error code 1
Stop in /usr/src/include.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
Tom Veldhouse
[EMAIL PROTECTED]
- Original Message -
From: "David O'Brien" [EMAIL PROTECTED]
To: "Thomas T. Veldhouse" [EMAIL PROTECTED]
Cc: "FreeBSD-Current, " [EMAIL PROTECTED]
Sent: Monday, January 15, 2001 11:40 AM
Subject: Re: Buildworld failure as of 01-15-2001 @ 8:30 CST
On Mon, Jan 15, 2001 at 08:37:43AM -0600, Thomas T. Veldhouse wrote:
I just installed the FreeBSD 5.0-20010107-CURRENT snapshot and have
cvsup'd
to the latest source (as of subject). Buildworld fails as below:
Do not manually do anything to get around this yet.
Please apply and try this patch. Report here, if it works or not.
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.179
diff -u -r1.179 Makefile.inc1
--- Makefile.inc1 2000/12/03 20:29:31 1.179
+++ Makefile.inc1 2001/01/15 17:39:37
@@ -564,7 +564,7 @@
build-tools:
.for _tool in bin/csh bin/sh ${_games} gnu/usr.bin/cc/cc_tools
${_fortran} \
-${_libroken4} ${_libkrb5} lib/libncurses ${_share}
+usr.bin/rpcgen ${_libroken4} ${_libkrb5} lib/libncurses ${_share}
cd ${.CURDIR}/${_tool}; ${MAKE} build-tools
.endfor
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: number of processes forked since boot
Hi,
On Mon, 15 Jan 2001 10:06:18 -0800
Alfred Perlstein [EMAIL PROTECTED] said:
bright * Hajimu UMEMOTO [EMAIL PROTECTED] [010115 10:00] wrote:
Hi,
I wish to obtain number of processes forked since boot from userland.
So, I made a patch to intend to commit.
Any comment?
bright Why not just use a dynamic sysctl for this?
I think dynamic sysctl is useful for dynamic context. But, here is
just static and it seems there is no advantage. Isn't it?
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld failure as of 01-15-2001 @ 8:30 CST
I must have left some relics around or something. I am getting a different
error:
cd /usr/src/usr.bin/rpcgen; make build-tools
make: don't know how to make build-tools. Stop
*** Error code 2
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
It appears that the patch didn't apply well. I looked at it manually and
could not find anything wrong with it.
Tom Veldhouse
[EMAIL PROTECTED]
- Original Message -
From: "David O'Brien" [EMAIL PROTECTED]
To: "Thomas T. Veldhouse" [EMAIL PROTECTED]
Cc: "FreeBSD-Current, " [EMAIL PROTECTED]
Sent: Monday, January 15, 2001 11:40 AM
Subject: Re: Buildworld failure as of 01-15-2001 @ 8:30 CST
On Mon, Jan 15, 2001 at 08:37:43AM -0600, Thomas T. Veldhouse wrote:
I just installed the FreeBSD 5.0-20010107-CURRENT snapshot and have
cvsup'd
to the latest source (as of subject). Buildworld fails as below:
Do not manually do anything to get around this yet.
Please apply and try this patch. Report here, if it works or not.
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.179
diff -u -r1.179 Makefile.inc1
--- Makefile.inc1 2000/12/03 20:29:31 1.179
+++ Makefile.inc1 2001/01/15 17:39:37
@@ -564,7 +564,7 @@
build-tools:
.for _tool in bin/csh bin/sh ${_games} gnu/usr.bin/cc/cc_tools
${_fortran} \
-${_libroken4} ${_libkrb5} lib/libncurses ${_share}
+usr.bin/rpcgen ${_libroken4} ${_libkrb5} lib/libncurses ${_share}
cd ${.CURDIR}/${_tool}; ${MAKE} build-tools
.endfor
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: number of processes forked since boot
I wish to obtain number of processes forked since boot from userland. I think dynamic sysctl is useful for dynamic context. But, here is just static and it seems there is no advantage. Isn't it? That sounds to me like a wholly dynamic thing. I mean the amount of forks since boot can rise in time right? Or am I losing my mind? =) DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anybody else seeing a broken /dev/lpt with SMP on -current?
Hi Bruce, I applied the patch to dev/ppbus/lpt.c and sys/i386/isa/intr_machdep.c. Before the patch, I got the lpt failure almost immediately. df | lpr df | lpr df | lpr lpt .cshrc would normally do it. After the patch, it took lots more activity. I did the above a half-dozen times, successfully, and then: foreach i ( 1 2 3 4 5 6 7 8 9 a b c ) df | lpr end printf "\f" | lpr and, this failed. I had 4 sets of df on the page left to be ejected in the printer. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: number of processes forked since boot
On Tue, 16 Jan 2001, Hajimu UMEMOTO wrote: bright * Hajimu UMEMOTO [EMAIL PROTECTED] [010115 10:00] wrote: I wish to obtain number of processes forked since boot from userland. So, I made a patch to intend to commit. Any comment? I like the idea, but this belongs in vmeter with context switches, page faults, etc, doesn't it? This is how OpenBSD does it, anyway. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VXA tape drive
I checked in current with little luck. Does -current support VXA-1 tape drives by Ecrix. The site claims that freebsd does, but the only response by someone that has one says that it won't successfully backup. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VXA tape drive
Well, details would be nice. I checked in current with little luck. Does -current support VXA-1 tape drives by Ecrix. The site claims that freebsd does, but the only response by someone that has one says that it won't successfully backup. 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: VXA tape drive
I've been using one under 4.2-STABLE, for some time, without problems. On 15-Jan-01 David W. Chapman Jr. wrote: I checked in current with little luck. Does -current support VXA-1 tape drives by Ecrix. The site claims that freebsd does, but the only response by someone that has one says that it won't successfully backup. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VXA tape drive
On Mon, Jan 15, 2001 at 12:49:29PM -0600, David W. Chapman Jr. thus spoke: I checked in current with little luck. Does -current support VXA-1 tape drives by Ecrix. The site claims that freebsd does, but the only response by someone that has one says that it won't successfully backup. It really should work. I talked with the Ecrix people awhile back and the drive is essentially just a DAT drive. What makes it different is internally it is writing short packet across the width of the tape, and using multiple heads. The reason is that if you don't send data to a tape fast enough it will back up, stop and restart. Ecrix calls this 'back-hitching' but I remember it from the old days called 'shoe shining'. So they slow down the tape as it travels across the heads. This changed the anlge of the helical stripes. This would make the tape unreadable in a device which expects the data to be readable across the width of the tape. By using 'packets' they put several blocks of data across the width, and if a head can read the first packet, but the angle of the helix is such that the next one is not readable, the next head will pick this up. Quite an interesting approach to enable the tape to never stop and maximize the data throughput. What kind of errors are you having? Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fw: SCSI Tape Drive support
I haven't any problems yet, just finding out who has used it, but Mr. Wayne informed me that he had problems as enclosed below so I started to ask. I have already been talking to Matthew Jacob about this and have heard from someone else that they got it working successfully so I think we can consider this thread closed if nobody has any further comments. - Original Message - From: "Michael R. Wayne" [EMAIL PROTECTED] To: "David W. Chapman Jr." [EMAIL PROTECTED] Sent: Monday, January 15, 2001 12:20 PM Subject: Re: SCSI Tape Drive support On Sun, Jan 14, 2001 at 02:46:45PM -0600, David W. Chapman Jr. wrote: Does anyone know if FreeBSD supports VXA 33/66gig tape drives by Ecrix? Well, yes no. I can talk to it and run dumps partway but always get errors partway through. Tech support was not very helpful. Gave up on the project for now. /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: number of processes forked since boot
On Mon, 15 Jan 2001 19:46:32 +0100 (CET)
Paul Herman [EMAIL PROTECTED] said:
pherman On Tue, 16 Jan 2001, Hajimu UMEMOTO wrote:
bright * Hajimu UMEMOTO [EMAIL PROTECTED] [010115 10:00] wrote:
I wish to obtain number of processes forked since boot from userland.
So, I made a patch to intend to commit.
Any comment?
pherman I like the idea, but this belongs in vmeter with context switches,
pherman page faults, etc, doesn't it? This is how OpenBSD does it, anyway.
I see.
You mean accessing uvmexp.forks via sysctl.
Does it solved by just moving nforks into vm_meter.c?
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld failure as of 01-15-2001 @ 8:30 CST
On Mon, Jan 15, 2001 at 12:36:34PM -0600, Thomas T. Veldhouse wrote: I must have left some relics around or something. I am getting a different error: No, I goofed. I'm getting my current test box back into shape so I can build a world before making stupid suggestions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Anybody else seeing a broken /dev/lpt with SMP on -current?
On 14-Jan-01 Garance A Drosihn wrote: At 6:55 PM -0800 1/12/01, John Baldwin wrote: On 13-Jan-01 Jordan Hubbard wrote: If anybody wants a fuller traceback then I'll compile up a kernel with debugging symbols, but it's going to be pretty sparse anyway since it basically only shows the trap() from the page fault and the subsequent panic. All the other traces show the kernel having returned to an address that is beyond the end of the kernel (which causes the page fault) meaning that the stack is fubar'd, so the trace isn't meaningful anyways. :( Knowing how and why the lpd interrupt handler trashes the stack is the useful info, and with the stack already trashed, I don't know of an easy way to figure that out. Do you really mean the "lpd interrupt handler", or do you mean the "lpt interrupt handler"? Does this problem only happen when lpd is sending data thru /dev/lpt? lpt interrupt handler, yes. -- 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: Atomic breakage?
On 14-Jan-01 Peter Jeremy wrote: On 2001-Jan-14 23:02:28 +0200, Mark Murray [EMAIL PROTECTED] wrote: Hi John There seems to be same breakage in the atomic stuff: link_elf: symbol atomic_load_acq_int undefined KLD file random.ko - could not finalize loading I back out the latest commit to sys/i386/include/atomic.h, and things work a bit better (on my laptop). Basically, the problem is that some of the recent commits have broken the interface between sys/i386/include/atomic.h and sys/i386/i386/atomic.c The latter file builds non-inlined versions of the atomic functions defined in atomic.h. This means that atomic.h must be laid out in a suitable manner so that the non-inlined functions are built by atomic.c. (Modules use explicit function calls, rather than inlined atomic functions to remove the need to have distinct UP and SMP versions.) The layout of atomic.h should look like: #ifdef KLD_MODULE #defines expanding to prototypes. #else #defines expanding to inline function definitions #endif List of atomic functions (invoking above macros) Due to incompatibilities between __asm in different versions of gcc, several different versions of various macros (and expansions) are necessary. The old asm should probably die for one thing. The problem is that over time, atomic.h has been expanded and things have gotten a bit confused. Mark's reported breakage is a result of the new atomic_cmpset_int(). This has been defined in the !KLD_MODULE section (but only for new versions of gcc - which should be OK since it'll never be used in conjunction with the old gcc) and a suitable prototype has been inserted in the KLD_MODULE section. The problem is that a pile of #defines have been incorrectly put in this section, rather than outside the KLD_MODULE section. This means that modules are left with dangling references to these functions. Actually, the problem is that I changed atomic_load and atomic_store to be functions for modules instead of inlines because they are now different for I386_CPU. It seems that static versions aren't being compiled of these functions. I'll fix it in a second. atomic_cmpset_* are fine, however. And for BDE's benefit - atomic.h is broken for IA32's with 64-bit longs. (I believe that can be fixed for Pentiums and above using CMPXCHG8B, but I can't test the code). The i386 with 64-bit longs doesn't boot from what I hear. Also, long in machine/types.h is 32-bits long. I don't think we need to bother with 64-bit longs. Adding 64-bit atomic ops will be expensive on = 486. -- 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: Soundblaster 64 PCI
This is the same problem I am having with a Soundblaster 16 PCI on
4.2-STABLE. I found a work around for it. It appears that there is
something that is being un-initialized by the FreeBSD es1371 driver that
other OS's do set. I have built a linux boot floppy, boot it, modprobe
the linux es1371 driver, and than reboot into FreeBSD and the problem is
gone. And until I power off the machine, the card works fine.
I have brought this up several times on the freebsd-multimedia list, but
have gone un-noticed each time.
Anyway, I have found a lame work around, until it is fixed properly.
Greg
* The Hermit Hacker ([EMAIL PROTECTED]) [010114 21:33]:
yup, just confirmed ... it does it with splay as well ...
On Sun, 14 Jan 2001, The Hermit Hacker wrote:
On Sun, 14 Jan 2001, Cameron Grant wrote:
If this is a known problem, I'll stop for now and watch out for fixes.
If it's not the expected behaviour from the PCM driver though, can
anyone advise?
Okay, just checked and it appears tha htis is the same error that I'm
seeing on mine, as reported yesterday ... not sure if its known or not,
but its not "just you" ...
are either of you using esound or xmms? if so, i know the cause of this and
it will be fixed shortly, once my primary development box recovers from
killing its cpu.
if not, i'll try to reproduce this.
for me, I tried using splay ... but, not sure how old my compile was, so
am just installing a new copy and will report back ...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
Greg Rumple
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: number of processes forked since boot
On Tue, 16 Jan 2001, Hajimu UMEMOTO wrote: On Mon, 15 Jan 2001 19:46:32 +0100 (CET) Paul Herman [EMAIL PROTECTED] said: pherman I like the idea, but this belongs in vmeter with context switches, pherman page faults, etc, doesn't it? This is how OpenBSD does it, anyway. I see. You mean accessing uvmexp.forks via sysctl. Does it solved by just moving nforks into vm_meter.c? Yes, that's my read from the source. What I also like about it is that it counts [vr]forks to boot, plus vmpages affected by the fork. After I first saw this in OBSD I was really motivated to do just what you've done for FreeBSD, but never got around to it. If you like, I'll see if I can't come up with something similar. Shouldn't be too hard. I'll try that tonight. The hardest part would be finding a spot on the systat(1) display to put it. :-) -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: number of processes forked since boot
On Mon, 15 Jan 2001 21:07:08 +0100 (CET)
Paul Herman [EMAIL PROTECTED] said:
pherman Yes, that's my read from the source. What I also like about it is
pherman that it counts [vr]forks to boot, plus vmpages affected by the fork.
pherman After I first saw this in OBSD I was really motivated to do just what
pherman you've done for FreeBSD, but never got around to it.
I just moved nforks into vm_meter.c Here is a patch:
Index: sys/kern/kern_fork.c
diff -u sys/kern/kern_fork.c.orig sys/kern/kern_fork.c
--- sys/kern/kern_fork.c.orig Fri Jan 12 02:46:53 2001
+++ sys/kern/kern_fork.cTue Jan 16 04:53:18 2001
@@ -145,6 +145,7 @@
intnprocs = 1; /* process 0 */
static int nextpid = 0;
+extern unsigned int nforks;
/*
* Random component to nextpid generation. We mix in a random factor to make
@@ -277,6 +278,8 @@
}
newproc-p_vmspace = NULL;
+
+ nforks++;
/*
* Find an unused process ID. We remember a range of unused IDs
Index: sys/vm/vm_meter.c
diff -u sys/vm/vm_meter.c.orig sys/vm/vm_meter.c
--- sys/vm/vm_meter.c.orig Fri Jan 12 02:48:48 2001
+++ sys/vm/vm_meter.c Tue Jan 16 04:51:49 2001
@@ -126,6 +126,10 @@
SYSCTL_UINT(_vm, OID_AUTO, v_free_severe,
CTLFLAG_RW, cnt.v_free_severe, 0, "");
+unsigned int nforks = 0;
+SYSCTL_UINT(_vm, OID_AUTO, nforks, CTLFLAG_RD, nforks, 0,
+ "number of fork()s since boot");
+
SYSCTL_STRUCT(_vm, VM_LOADAVG, loadavg, CTLFLAG_RD,
averunnable, loadavg, "Machine loadaverage history");
pherman If you like, I'll see if I can't come up with something
pherman similar. Shouldn't be too hard. I'll try that tonight.
Please do it.
pherman The hardest part would be finding a spot on the systat(1) display to
pherman put it. :-)
Exactly.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/i386/conf GENERIC
On 2001-Jan-15 00:08:12 -0800, Peter Wemm [EMAIL PROTECTED] wrote: The patch below does this: http://people.freebsd.org/~peter/i386_cleanup.diff ... To be clear: THIS DOES NOT REMOVE i386 SUPPORT! It will actually slightly improve i386 runtime speed by removing the useless conditional tests. IMHO, this is the right approach. I don't see any reason to rip out the (working) 386 code. If it rots due to lack of interest in future, then it can be stripped out. Note that the patch doesn't currently handle the PC98. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soundblaster 64 PCI
I probably have the same card as you, I just went out and bought a soundblaster 16PCI because my new motherboard doesn't have any ISA slots. Unfortunately, the card is detected and does play sound, but it is soo distorted you can't really recognize anything. I was just wondering if you hard this distortion problem as well, I haven't seen anything on the lists about it until now. Thanks, Andrew On Mon, 15 Jan 2001, Greg Rumple wrote: This is the same problem I am having with a Soundblaster 16 PCI on 4.2-STABLE. I found a work around for it. It appears that there is something that is being un-initialized by the FreeBSD es1371 driver that other OS's do set. I have built a linux boot floppy, boot it, modprobe the linux es1371 driver, and than reboot into FreeBSD and the problem is gone. And until I power off the machine, the card works fine. I have brought this up several times on the freebsd-multimedia list, but have gone un-noticed each time. Anyway, I have found a lame work around, until it is fixed properly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I take that back.... Re: sio serial console in -current?
On Mon, 15 Jan 2001, Matthew Jacob wrote: FWIW, serial now is happy again. I guess the planets realigned. Nope- it just happens more fitfully. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soundblaster 64 PCI
i have the same problem with sounbblaster 16 pci. wondering if there will be a fix any time soon? On Mon, 15 Jan 2001, Greg Rumple wrote: This is the same problem I am having with a Soundblaster 16 PCI on 4.2-STABLE. I found a work around for it. It appears that there is something that is being un-initialized by the FreeBSD es1371 driver that other OS's do set. I have built a linux boot floppy, boot it, modprobe the linux es1371 driver, and than reboot into FreeBSD and the problem is gone. And until I power off the machine, the card works fine. I have brought this up several times on the freebsd-multimedia list, but have gone un-noticed each time. Anyway, I have found a lame work around, until it is fixed properly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: number of processes forked since boot
On Tue, 16 Jan 2001, Hajimu UMEMOTO wrote: Hi, I wish to obtain number of processes forked since boot from userland. So, I made a patch to intend to commit. Any comment? Index: sys/kern/kern_fork.c diff -u sys/kern/kern_fork.c.orig sys/kern/kern_fork.c --- sys/kern/kern_fork.c.orig Fri Jan 12 02:46:53 2001 +++ sys/kern/kern_fork.c Tue Jan 16 02:30:26 2001 @@ -146,6 +146,9 @@ int nprocs = 1; /* process 0 */ static int nextpid = 0; +static unsigned int nforks = 0; +SYSCTL_UINT(_kern, KERN_NFORKS, nforks, CTLFLAG_RD, nforks, 0, ""); If any, I think this should be long, otherwise on machines like web servers the counter will overflow in a short time. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: number of processes forked since boot
On 2001-Jan-15 23:24:22 +0100, Andrzej Bialecki [EMAIL PROTECTED] wrote: On Tue, 16 Jan 2001, Hajimu UMEMOTO wrote: ... +static unsigned int nforks = 0; +SYSCTL_UINT(_kern, KERN_NFORKS, nforks, CTLFLAG_RD, nforks, 0, ""); If any, I think this should be long, otherwise on machines like web servers the counter will overflow in a short time. On an i386, "long" and "int" are both 32 bits, hence "long" has a lower maximum count than "unsigned int". "unsigned long" might be a better choice (to give a greater range on the Alpha). In any case, at 1000 forks/sec, a 32-bit counter will still take nearly 50 days to wrap. Lots of other counters will have wrapped by this time. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VXA tape drive
On Mon, Jan 15, 2001 at 01:31:47PM -0600, David W. Chapman Jr. thus spoke: thanks for the background, quite interesting. You're welcome. I'm currently writing a series of articles for the tape newbie that a friend coaxed me into. I've finished electrons, magnets, head design and QIC tape. Rotary heads are next. Don't know where I'll go from there. www.aplawrence.com. Go to Unix articles and you'll see them listed on the top right side of the page as I recall. If you are into audio tape - I wrote an article a jillion years ago that has widely propagated. goto www.bilver.com [note that it is not the same as this address] and go down to aligning your professional tape recoder. I was an audio recording engineer before computers came to dominate my life. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make buildkernel broken
=== wi make: don't know how to make /usr/src/sys/modules/wi/../../i386/isa/if_wi.c. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 -- Pascal Hofstee daeron @ shadowmere . student . utwente . nl begin LOVE-LETTER-FOR-YOU.TXT.vbs I'm a signature virus. Please copy me and help me spread. end To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: make buildkernel broken
On 15-Jan-01 Pascal Hofstee wrote: === wi make: don't know how to make /usr/src/sys/modules/wi/../../i386/isa/if_wi.c. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 Did you do a make depend? This was fixed a while ago. -- 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: make buildkernel broken
Hello, === wi make: don't know how to make /usr/src/sys/modules/wi/../../i386/isa/if_wi.c. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 I had same problem. Do you have /usr/src/sys/modules/wi/.depend ? If so, remove it and try make buildkernel again. koya To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OOPS.. (Re: MFC? src/sys/i386/conf/GENERIC and sound support)
I was thinking about that. Of course my skills limit me to the idea :-P Well, maybe if it would load automatically on first open.. :) We need some stub loader technology... - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
