Re: SB AWE64 not recognised anymore
Hello! On Sun, May 28, 2000 at 02:06:03AM +0200, Ollivier Robert wrote: > I just upgraded my home machine from 4.0-R to 5.0-CURRENT and have found > something odd. I have an ISA PnP SB AWE64 in the machine and it is not seen by > the system at all. Are you using the pcm driver or the old voxware drivers? I have the same card and it has been always working for me with pcm both on 4.0 and now -CURRENT. Using it right now:-) The only remaining issue this far has been that when the Linux RealPlayer starts playing a clip, it will always start-stop-start in the beginning and after doing this exactly once, it will play for about 2 secs and then start replaying a short snippet faster and faster for about 4 secs not more, after this is done, playing works as it should. Which is annoying but since I only use RealPlayer to listen to live radio, I simply do not turn on the volume in the first 5-6 secs after which normally all is correct again. Must stress that this *only* happens with RealPlayer for Linux, but *not* with mp3 playback or anything else. These symptoms were not present under 4.0. So it can be just as well linuxulator related... > I found this in dmesg: > > isab0: at device 7.0 on pci0 > isa0: on isab0 > ... > isa0: unexpected small tag 14 This is no problems. Was also present under 4.0-STABLE for me. I do not know what it means though. > ... > unknown: can't assign resources > > Any idea why ? The 'small tag' error worries me... > > Messages from older boot: > > sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 >on isa0 > sbc0: setting card to irq 5, drq 1, 5 > pcm0: on sbc0 So you are using pcm then... Well I only have device pcm device sbc in my kernel config and no PNPBIOS option. (PnP OS set to "no" in the BIOS) Despite this, yesterday's kernel prints all sorts of "unknownX " lines which I only saw this far with people who had "options PNPBIOS" in their kernels. But it doesn't bother me much... I know that the SB 64 PnP ISA exports so many possible PnP configs that it may confuse the kernel. (I have no other PnP devices so I am easy here.) The lines that matter come after that:-) sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: on sbc0 and here we go. What does 'cat /dev/sndstat' say on your system? Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
On Sat, May 27, 2000 at 12:38:36PM -0700, Doug Barton wrote: > > Try setting the nice value for rc5 to something lower than 20, but > higher than the highest (lowest) value running on your system. There was > a bug with the scheduler in the past that items run at nice 20 were > actually getting more cpu than they were supposed to. I remember the scheduler bug you're talking about. My system feels much the same as it did during 4.0-CURRENT when that bug was active. I had a collection of wrapper scripts for CPU intensive programs that suspended rc5des, ran the program, then reenabled it again. Should have held on to them, I guess. > If this change > fixes things for you, please report it asap, since my understanding is > that this problem is rather elusive and annoying. No, it didn't work, unfortunately. To test it, I renice'd rc5des to a couple of different values while encoding an MP3. When niced at: +10 rc5des chewed ~40-45% CPU +15 rc5des chewed ~35-40% CPU +20 rc5des chewed ~25-30% CPU If there's any other information I can provide, just let me know. -jake -- Jacob A. Hart <[EMAIL PROTECTED]> Powered by: FreeBSD 5.0-CURRENT #9: Fri May 26 07:39:27 EST 2000 I believe the technical term is "Oops!" PGP signature
Re: Kernel making problems
In message <[EMAIL PROTECTED]> Jaye Mathisen writes: : Wasn't there just a big to-do wrt to 4.0 (then -current), about the right : way to do things is to install a new kernel, then build the world? Yes. That was needed for a while since the new binaries produced code the olkd kernel couldn't execute. : I seem to remember Rod championing this method. (Had something to do with : some syscall interface changing). Yup. However, with the changes to binutils and also the kernel .s files, we have no choice. You'll need at least the binutils. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel making problems
Wasn't there just a big to-do wrt to 4.0 (then -current), about the right way to do things is to install a new kernel, then build the world? I seem to remember Rod championing this method. (Had something to do with some syscall interface changing). On Sat, 27 May 2000, Warner Losh wrote: > In message <[EMAIL PROTECTED]> John >Baldwin writes: > : You need to build and install a new world before a new kernel. It looks > : like this needs to go into src/UPDATING. > > Done. Others have suggested this as well. > > Warner > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel making problems
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> "David O'Brien" writes: > : On Sat, May 27, 2000 at 11:09:00AM -0400, John Baldwin wrote: > : > You need to build and install a new world before a new kernel. It looks > : > like this needs to go into src/UPDATING. > : > : Actually just the following will also fix the problem: > : > : cd /usr/src/gnu/usr.bin/binutils > : make obj > : make depend > : make all install > > I thought about that, but wasn't sure that the new binutils would work > with all versions of -current that we support upgrading. > > There's also other issues that need a make install because of the > bsd.kmod.mk. > > Warner > actually, it seems that the "make includes" resolved my problem. Usually, i'll make buildworld, crank out a new kernel, then make installworld. I did make buildworld; make installworld, THEN made a new kernel and it seems to be running fine now. Thanks guys! -Otter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel making problems
In message <[EMAIL PROTECTED]> "David O'Brien" writes: : On Sat, May 27, 2000 at 11:09:00AM -0400, John Baldwin wrote: : > You need to build and install a new world before a new kernel. It looks : > like this needs to go into src/UPDATING. : : Actually just the following will also fix the problem: : : cd /usr/src/gnu/usr.bin/binutils : make obj : make depend : make all install I thought about that, but wasn't sure that the new binutils would work with all versions of -current that we support upgrading. There's also other issues that need a make install because of the bsd.kmod.mk. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SB AWE64 not recognised anymore
I just upgraded my home machine from 4.0-R to 5.0-CURRENT and have found something odd. I have an ISA PnP SB AWE64 in the machine and it is not seen by the system at all. I found this in dmesg: isab0: at device 7.0 on pci0 isa0: on isab0 ... isa0: unexpected small tag 14 ... unknown: can't assign resources Any idea why ? The 'small tag' error worries me... Messages from older boot: sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: on sbc0 pnpconfig still sees the card: Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID CTL00e4 (0xe4008c0e), Serial Number 0x128bf1e3 PnP Version 1.0, Vendor Version 16 Device Description: Creative SB AWE64 PnP *** Small Vendor Tag Detected Logical Device ID: CTL0045 0x45008c0e #0 Device Description: Audio TAG Start DF Good Configuration IRQ: 5 - only one type (true/edge) DMA: channel(s) 1 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 5 16-bit, not a bus master, , count by word, Compatibility mode I/O Range 0x220 .. 0x220, alignment 0x1, len 0x10 [16-bit addr] I/O Range 0x330 .. 0x330, alignment 0x1, len 0x2 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x1, len 0x4 [16-bit addr] TAG Start DF ... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #78: Sun Feb 27 15:32:39 CET 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel making problems
On Sat, May 27, 2000 at 11:09:00AM -0400, John Baldwin wrote: > You need to build and install a new world before a new kernel. It looks > like this needs to go into src/UPDATING. Actually just the following will also fix the problem: cd /usr/src/gnu/usr.bin/binutils make obj make depend make all install -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Internal compiler error: program ld got fatal signal 10
Bob Martin wrote: > > with "unsubscribe freebsd-current" in the body of the message > If you are using an older K6 with more than 32mb of ram, this will > happen from time to time of it's own accord. I have never taken the time > to find out why, but if you search the archives, you will find that it > happens quite a bit. > SMP Pentium Pro with 256 MB of memory, and only scsi hardware. Note, ld is getting a signal 10 (SIGBUS) not signal 11 (SIGSEGV), which is the typical crappy hardware signal. Also, I can build the world as long as I use sources older that 23 May 00. This leads me to believe that the new binutils are having some problems. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel making problems
In message <[EMAIL PROTECTED]> John Baldwin writes: : You need to build and install a new world before a new kernel. It looks : like this needs to go into src/UPDATING. Done. Others have suggested this as well. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel compile fails in: ../../dev/vx/if_vx_pci.c
On Fri, 26 May 2000, Warner Losh wrote: > In message <[EMAIL PROTECTED]> The Hermit >Hacker writes: > : make depend went through no probs, but a make fails at: > > You may have overlooked this entry in UPDATING: > > 2319: > The ISA and PCI compatability shims have been connected to the > options COMPAT_OLDISA and COMPAT_OLDPCI. If you are using old > style PCI or ISA drivers (i.e. tx, voxware, etc.) you must > include the appropriate option in your kernel config. Drivers > using the shims should be updated or they won't ship with > 5.0-RELEASE, targeted for 2001. Yup, did overlook it :( Thanks ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Internal compiler error: program ld got fatal signal 10
Steve Kargl wrote: > > First, the error message: > > cc -fpic -DPIC -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF >-I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libmd/i386/rmd160.S -o rmd160.So > building shared library libmd.so.2 > cc: Internal compiler error: program ld got fatal signal 10 > *** Error code 1 > > Stop in /usr/src/lib/libmd. > *** Error code 1 > > Now, the details. I started on Monday trying to update > a 15 March 00 -current to current -current. I get the > above error message with a source tree after > > *default date=2000.05.23.00.00.00 > > as specified in my cvsup supfile. The system builds fine > for all earlier dates that I've tried. I have used the > following three CFLAGS as set in /etc/make.conf > > CFLAGS= > CFLAGS=-O -pipe > CFLAGS=-O2 -pipe > > and the above error occurs. > > Any and all suggestions are welcomed, but it appears to be > a problem with the new binutils. > > -- > Steve > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message If you are using an older K6 with more than 32mb of ram, this will happen from time to time of it's own accord. I have never taken the time to find out why, but if you search the archives, you will find that it happens quite a bit. Bob -- "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
subscribe freebsd-current subscribe cvs-all To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Internal compiler error: program ld got fatal signal 10
First, the error message: cc -fpic -DPIC -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libmd/i386/rmd160.S -o rmd160.So building shared library libmd.so.2 cc: Internal compiler error: program ld got fatal signal 10 *** Error code 1 Stop in /usr/src/lib/libmd. *** Error code 1 Now, the details. I started on Monday trying to update a 15 March 00 -current to current -current. I get the above error message with a source tree after *default date=2000.05.23.00.00.00 as specified in my cvsup supfile. The system builds fine for all earlier dates that I've tried. I have used the following three CFLAGS as set in /etc/make.conf CFLAGS= CFLAGS=-O -pipe CFLAGS=-O2 -pipe and the above error occurs. Any and all suggestions are welcomed, but it appears to be a problem with the new binutils. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
"Jacob A. Hart" wrote: > > On Fri, May 26, 2000 at 04:01:05PM +0200, Sheldon Hearn wrote: > > > > > > On Fri, 26 May 2000 13:19:49 +1000, "Jacob A. Hart" wrote: > > > > > For the past couple of weeks I've noticed rc5des isn't playing friendly with > > > the other processes on my system. When running a CPU intensive task (such > > > as a buildworld, MP3 encoder, or xmame) rc5des hogs around 20-30% CPU even > > > though, by default, it is niced at +20. > > > > As a datapoint, I have a one week old (2000-05-18) CURRENT box that runs > > setiathome all day every day. When builds kick in, setiathome gets > > relagated to the single-digit percentiles in top's display of CPU users. > > This is only true when serious building is happening; those aspects of > > the build that I can imagine are more I/O than CPU intensive give > > setiathome a fighting chance. Try setting the nice value for rc5 to something lower than 20, but higher than the highest (lowest) value running on your system. There was a bug with the scheduler in the past that items run at nice 20 were actually getting more cpu than they were supposed to. If this change fixes things for you, please report it asap, since my understanding is that this problem is rather elusive and annoying. Thanks, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build error due to dependency on /usr/include?
On Sat, 27 May 2000, Jake Burkholder wrote: > > I got following kernel build error. > > When I run 'make includes', the error has gone away. `make includes' tends to cause errors like this. It updates /usr/include to match the sources. This may make /usr/include inconsistent with /usr/lib. > > Why does kernel build process depend on installed system files, > > such as /usr/include? > > It shouldn't. Most parts of it shouldn't, but utilities should be compiled with the installed headers that match the installed libraries. > This seems to be primarily aic7xxx, although judging from the output aicasm seems to be buill correctly, but it would be better for its Makefile to not add -I/usr/include to CFLAGS, so that the default is used. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build error due to dependency on /usr/include?
> Hi all, > > I got following kernel build error. > When I run 'make includes', the error has gone away. > > Why does kernel build process depend on installed system files, > such as /usr/include? It shouldn't. This seems to be primarily aic7xxx, although judging from the output of 'find /usr/include -amin 20 -print' after building LINT, there are more things that reach into /usr/include. This fixes it for including things from /usr/include/sys at least: cvs diff: Diffing . Index: Makefile === RCS file: /home/ncvs/src/sys/dev/aic7xxx/Makefile,v retrieving revision 1.6 diff -u -r1.6 Makefile --- Makefile1999/08/28 00:41:22 1.6 +++ Makefile2000/05/27 09:21:05 @@ -19,7 +19,7 @@ DEPENDFILE= .endif -CFLAGS+= -I/usr/include -I. +CFLAGS+= -I${MAKESRCPATH}/../.. -I. NOMAN= noman .ifdef DEBUG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel making problems
On 27-May-00 Otter wrote: > Matthew Hunt wrote: >> >> On Thu, May 25, 2000 at 10:58:41PM -0400, Otter wrote: >> >> > cc -ffast-math -pipe -march=pentiumpro -O3 -I/usr/include -I. -c >> > aicasm_gram.c >> > In file included from ../../dev/aic7xxx/aicasm_gram.y:40: >> > ../../dev/aic7xxx/aicasm.h:44: syntax error before `struct' >> > ../../dev/aic7xxx/aicasm.h:53: syntax error before `struct' >> >> I had the same problem. It looks like the following procedure >> fixes it: >> >> Make sure your source tree is up to date. >> cd /usr/src >> make includes >> >> Do the config/make depend/make bit again. >> >> Matt > > ok. that seems to have cured the problem in "make depend", but now i'm > finding a different problem in "make": > > cc -c -x assembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi > -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include > opt_global.h -elf -mpreferred-stack-boundary=2 > ../../i386/i386/bioscall.s > /tmp/ccd70154.s: Assembler messages: > /tmp/ccd70154.s:796: Error: operands given don't match any known 386 > instruction > /tmp/ccd70154.s:861: Error: operands given don't match any known 386 > instruction > *** Error code 1 > > Stop in /usr/src/sys/compile/kashmir. > > Any ideas? I don't have a clue. Does anyone have a spare clue I could > use to get this kernel made? TIA. > -Otter You need to build and install a new world before a new kernel. It looks like this needs to go into src/UPDATING. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/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: Kernel making problems
Matthew Hunt wrote: > > On Thu, May 25, 2000 at 10:58:41PM -0400, Otter wrote: > > > cc -ffast-math -pipe -march=pentiumpro -O3 -I/usr/include -I. -c > > aicasm_gram.c > > In file included from ../../dev/aic7xxx/aicasm_gram.y:40: > > ../../dev/aic7xxx/aicasm.h:44: syntax error before `struct' > > ../../dev/aic7xxx/aicasm.h:53: syntax error before `struct' > > I had the same problem. It looks like the following procedure > fixes it: > > Make sure your source tree is up to date. > cd /usr/src > make includes > > Do the config/make depend/make bit again. > > Matt ok. that seems to have cured the problem in "make depend", but now i'm finding a different problem in "make": cc -c -x assembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/bioscall.s /tmp/ccd70154.s: Assembler messages: /tmp/ccd70154.s:796: Error: operands given don't match any known 386 instruction /tmp/ccd70154.s:861: Error: operands given don't match any known 386 instruction *** Error code 1 Stop in /usr/src/sys/compile/kashmir. Any ideas? I don't have a clue. Does anyone have a spare clue I could use to get this kernel made? TIA. -Otter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: GDB 5.0 is released!
On Fri, 26 May 2000, David O'Brien wrote: > > > > GDB 5.0 is released! > > Do you have any forecasts as to when we will see this baby in the -current? > > Its priority is behind GCC 2.96 Incidentally David, I have some patches which make a pre-release gdb 5.0 work for FreeBSD which I was going to give you since you have the right paperwork for submitting stuff to FSF. With those patches, a simple port would be easy and might make importing it to -current a bit easier. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
On Fri, May 26, 2000 at 04:01:05PM +0200, Sheldon Hearn wrote: > > > On Fri, 26 May 2000 13:19:49 +1000, "Jacob A. Hart" wrote: > > > For the past couple of weeks I've noticed rc5des isn't playing friendly with > > the other processes on my system. When running a CPU intensive task (such > > as a buildworld, MP3 encoder, or xmame) rc5des hogs around 20-30% CPU even > > though, by default, it is niced at +20. > > As a datapoint, I have a one week old (2000-05-18) CURRENT box that runs > setiathome all day every day. When builds kick in, setiathome gets > relagated to the single-digit percentiles in top's display of CPU users. > This is only true when serious building is happening; those aspects of > the build that I can imagine are more I/O than CPU intensive give > setiathome a fighting chance. Yep. That makes sense. What puzzles me, though, is the behaviour for processes that aren't I/O bound. Here are two top snapshots taken while encoding an MP3 stream directly from a .wav file on disk. In both cases, the processes were given ample time to "stabilize" (ie. were left running for about two minutes before the snapshot was taken). Kernel from 26th May: last pid: 23929; load averages: 1.66, 0.85, 0.44up 1+09:10:34 17:01:31 35 processes: 3 running, 32 sleeping CPU states: 69.6% user, 28.4% nice, 0.8% system, 1.2% interrupt, 0.0% idle Mem: 65M Active, 33M Inact, 20M Wired, 4480K Cache, 22M Buf, 772K Free Swap: 256M Total, 256M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 23929 root 79 0 7656K 2024K RUN 0:59 67.56% 66.55% lame 174 root 81 20 952K 436K RUN320:40 30.27% 30.27% rc5des Kernel from 29th April: last pid: 235; load averages: 1.93, 1.02, 0.45up 0+00:06:00 17:09:10 26 processes: 3 running, 23 sleeping CPU states: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 12M Active, 49M Inact, 16M Wired, 12K Cache, 22M Buf, 47M Free Swap: 256M Total, 256M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 235 root 62 0 7684K 2260K RUN 2:15 98.44% 98.34% lame 174 root 68 20 952K 584K RUN 2:57 0.00% 0.00% rc5des Check out that rc5des process -- hogging (on average) about 30% CPU in the first case! My system feels noticibly sluggish too. The rc5des process interferes with just about everything (xmame, for example, is unplayable unless I disable it). I think I'll stick with the April 29th kernel for now ;-) -jake -- Jacob A. Hart <[EMAIL PROTECTED]> Powered by: FreeBSD 5.0-CURRENT #4: Sat Apr 29 07:29:02 EST 2000 Loose bits sink chips. PGP signature