Re: suspend mode broken since one week ago
In message <87so9r3x44@muon.xs4all.nl> Peter Mutsaers writes: : Is this a bug that I should report through send-pr, is it already : known as a bug or is this an intentional change in behaviour? This is a known bug. I thought I kludged around it in apm.c in the timeframe that you mentioned. Do you have $Id: apm.c,v 1.80 1999/04/21 07:57:55 imp Exp $ or newer? Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Code Crusader 2.0.x on FreeBSD
%Hmm, I missed that. I took -lc out, but now I get this: % [...] %/usr/local/lib/liblthread.so.0: undefined reference to `_sigsuspend' %/usr/local/lib/liblthread.so.0: undefined reference to `_nanosleep' %/usr/local/lib/liblthread.so.0: undefined reference to `_fork' %/usr/local/lib/liblthread.so.0: undefined reference to `_sched_yield' %/usr/local/lib/liblthread.so.0: undefined reference to `_write' %/usr/local/lib/liblthread.so.0: undefined reference to `_close' %gmake[2]: *** [makemake] Error 1 %gmake[2]: Leaving directory `/usr/home/dave/temp/JX-1.1.22/programs/makemake' %gmake[1]: *** [install] Error 2 %gmake[1]: Leaving directory `/usr/home/dave/temp/JX-1.1.22/lib' %gmake: *** [freebsd] Error 2 % %A search on freebsd.org/search made references that sigsuspend was removed from %libc? Stranger and stranger.. because liblthread is linuxthreads, and you really want what the original ACE configuration probably specified, given the time frame, which is libc_r threads. I am converging in on getting a performance analysis done of libc_r and linuxthreads on ACE and TAO (!!) nailed down, so I don't have time to build this stuff though it looks very interesting. Please do not use any of my config files at www.pinyon.org/ace for this sort of thing. Switching amongst the thread libs is a real mess right now but I have got most of it automated. Still some glitches though. I will say for those interested that the sched.diff patch on Richard Seaman's page works as advertised, and I am just drooling at the prospect of running the full set of "real-time" priority tests on the set of described in several papers on Douglas Schmidt's site. Way cool, everybody who has worked on threads or scheduling! Thanks! Cheers, Russell % % %On Fri, 23 Apr 1999, you wrote: %> Why is it still linking with libc? %> %> Russell %> %> |g++ -o makemake makemake.o ../../include/jcore/JBroadcaster.o ../../include/jcore/JCollection.o ../../include/jcore/JContainer.o ../../include/jcore/JProbDistr.o ../../include/jcore/JOrderedSetT.o ../../include/jcore/JOrderedSetUtil.o ../../include/jcore/JString.o ../../include/jcore/JSubstitute.o ../../include/jcore/jCommandLine.o ../../include/jcore/jStreamUtil.o ../../include/jcore/jStreamUtil_UNIX.o ../../include/jcore/jFStreamUtil.o ../../include/jcore/jFStreamUtil_UNIX.o ../../include/jcore/jFileUtil.o ../../include/jcore/jFileUtil_UNIX.o ../../include/jcore/jDirUtil_UNIX.o ../../include/jcore/jUNIXUtil.o ../../include/jcore/JError.o ../../include/jcore/JStdError.o ../../include/jcore/JRTTIBase.o ../../include/jcore/JProgressDisplay.o ../../include/jcore/jMemory.o ../../include/jcore/jMath.o ../../include/jcore/jAssert.o ../../include/jcore/JAssertBase.o ../../include/jcore/jGlobals.o ../../include/jcore/JUserNotification.o ../../include/jcore/JTextUserNotificatio! n.o .! %> ./../include/jcore/JChooseSaveFil|e.o ../../include/jcore/JTextChooseSaveFile.o ../../include/jcore/JCreateProgressDisplay.o ../../include/jcore/JCreateTextPG.o ../../include/jcore/JTextProgressDisplay.o ../../include/jcore/JLatentPG.o ../../include/jcore/JProcess.o ../../include/jcore/JProcessError.o ../../include/jcore/JThisProcess.o ../../include/jcore/jProcessUtil.o ../../include/jcore/jSignal.o ../../include/jcore/JInPipeStream.o ../../include/jcore/JUNIXDirInfo.o ../../include/jcore/JUNIXDirEntry.o ../../include/jcore/Templates-JString.o ../../include/jcore/Templates-int.o ../../include/jcore/Templates-long.o ../../include/jcore/Templates-longlong.o ../../include/jcore/Templates-double.o ../../include/jcore/JPtrArray-JString.o ../../include/jcore/JRegex.o ../../include/jcore/JInterpolate.o ../../include/jcore/jHashFunctions.o ../../include/jcore/jNew.o ../../include/jcore/JMemoryManager.o ../../include/jcore/JMMTable.o ../../include/jcore/JMMArrayTable.o ../../inclu! de/j! %> ccore/JMMHashTable.o ../../include/jcore/JMMMonitor.o ../../include/|jcore/JMMErrorPrinter.o ../../include/jcore/JMMRecord.o ../../include/jcore/JArray-JMMRecord.o ../../include/jcore/JHashTable-JMMRecord.o ../../misc/regex/regcomp.o ../../misc/regex/regexec.o ../../misc/regex/regerror.o ../../misc/regex/regfree.o -L../../lib -lACE-4_6 -pthread -lstdc++ -lm -lc % To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problems with symbol sequences in recent kernels
On Saturday, 24 April 1999 at 0:10:17 +0900, Daniel C. Sobral wrote: > Greg Lehey wrote: >> >> This has worked quite nicely for some time. Since yesterday, after >> building a kernel with newbus support, I get strange messages if I >> read in the Vinum symbols before reading in the kernel symbols: > > ... > >> I debugged gdb and found that it was finding these references >> (opt_global.h) in cd9660_rrip.o, which it read after reading the Vinum >> kld symbols. If I can convince it to read the kernel symbols first, I >> don't have any trouble. I don't think that it's anything to do with >> that particular file; there must be about 30 files in a typical kernel >> build which refer to this symbol. >> >> If I don't get any response on the list, I'll put in a PR, but I >> thought there's a good chance that somebody will recognize this >> problem and be able to fix it. > > Well, I don't recognize the problem, but I committed changes to > cd9660_rrip.c after newbus got in. Could you try a kernel from > before my changes got in? Just for the files I changed would be > enough. As I mentioned, I didn't think that it has anything to do with the cd code. I've built a kernel with the old version of cd9660, and it has the same problem. Since nobody else has replied, I'll put in the promised PR. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Code Crusader 2.0.x on FreeBSD
Hmm, I missed that. I took -lc out, but now I get this: g++ -o makemake makemake.o ../../include/jcore/JBroadcaster.o ../../include/jcore/JCollectio n.o ../../include/jcore/JContainer.o ../../include/jcore/JProbDistr.o ../../include/jcore/JOr deredSetT.o ../../include/jcore/JOrderedSetUtil.o ../../include/jcore/JString.o ../../include /jcore/JSubstitute.o ../../include/jcore/jCommandLine.o ../../include/jcore/jStreamUtil.o ../ ../include/jcore/jStreamUtil_UNIX.o ../../include/jcore/jFStreamUtil.o ../../include/jcore/jF StreamUtil_UNIX.o ../../include/jcore/jFileUtil.o ../../include/jcore/jFileUtil_UNIX.o ../../ include/jcore/jDirUtil_UNIX.o ../../include/jcore/jUNIXUtil.o ../../include/jcore/JError.o .. /../include/jcore/JStdError.o ../../include/jcore/JRTTIBase.o ../../include/jcore/JProgressDi splay.o ../../include/jcore/jMemory.o ../../include/jcore/jMath.o ../../include/jcore/jAssert .o ../../include/jcore/JAssertBase.o ../../include/jcore/jGlobals.o ../../include/jcore/JUser Notification.o ../../include/jcore/JTextUserNotification.o ../../include/jcore/JChooseSaveFil e.o ../../include/jcore/JTextChooseSaveFile.o ../../include/jcore/JCreateProgressDisplay.o .. /../include/jcore/JCreateTextPG.o ../../include/jcore/JTextProgressDisplay.o ../../include/jc ore/JLatentPG.o ../../include/jcore/JProcess.o ../../include/jcore/JProcessError.o ../../incl ude/jcore/JThisProcess.o ../../include/jcore/jProcessUtil.o ../../include/jcore/jSignal.o ../ ../include/jcore/JInPipeStream.o ../../include/jcore/JUNIXDirInfo.o ../../include/jcore/JUNIX DirEntry.o ../../include/jcore/Templates-JString.o ../../include/jcore/Templates-int.o ../../ include/jcore/Templates-long.o ../../include/jcore/Templates-longlong.o ../../include/jcore/T emplates-double.o ../../include/jcore/JPtrArray-JString.o ../../include/jcore/JRegex.o ../../ include/jcore/JInterpolate.o ../../include/jcore/jHashFunctions.o ../../include/jcore/jNew.o ../../include/jcore/JMemoryManager.o ../../include/jcore/JMMTable.o ../../include/jcore/JMMAr rayTable.o ../../include/jcore/JMMHashTable.o ../../include/jcore/JMMMonitor.o ../../include/ jcore/JMMErrorPrinter.o ../../include/jcore/JMMRecord.o ../../include/jcore/JArray-JMMRecord. o ../../include/jcore/JHashTable-JMMRecord.o ../../misc/regex/regcomp.o ../../misc/regex/rege xec.o ../../misc/regex/regerror.o ../../misc/regex/regfree.o -L../../lib -lACE-4_6 -pthread -lstdc++ -lm -pthread /usr/local/lib/liblthread.so.0: undefined reference to `_sigsuspend' /usr/local/lib/liblthread.so.0: undefined reference to `_nanosleep' /usr/local/lib/liblthread.so.0: undefined reference to `_fork' /usr/local/lib/liblthread.so.0: undefined reference to `_sched_yield' /usr/local/lib/liblthread.so.0: undefined reference to `_write' /usr/local/lib/liblthread.so.0: undefined reference to `_close' gmake[2]: *** [makemake] Error 1 gmake[2]: Leaving directory `/usr/home/dave/temp/JX-1.1.22/programs/makemake' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/usr/home/dave/temp/JX-1.1.22/lib' gmake: *** [freebsd] Error 2 A search on freebsd.org/search made references that sigsuspend was removed from libc? Stranger and stranger.. On Fri, 23 Apr 1999, you wrote: > Why is it still linking with libc? > > Russell > > |g++ -o makemake makemake.o ../../include/jcore/JBroadcaster.o > ../../include/jcore/JCollection.o ../../include/jcore/JContainer.o > ../../include/jcore/JProbDistr.o ../../include/jcore/JOrderedSetT.o > ../../include/jcore/JOrderedSetUtil.o ../../include/jcore/JString.o > ../../include/jcore/JSubstitute.o ../../include/jcore/jCommandLine.o > ../../include/jcore/jStreamUtil.o ../../include/jcore/jStreamUtil_UNIX.o > ../../include/jcore/jFStreamUtil.o ../../include/jcore/jFStreamUtil_UNIX.o > ../../include/jcore/jFileUtil.o ../../include/jcore/jFileUtil_UNIX.o > ../../include/jcore/jDirUtil_UNIX.o ../../include/jcore/jUNIXUtil.o > ../../include/jcore/JError.o ../../include/jcore/JStdError.o > ../../include/jcore/JRTTIBase.o ../../include/jcore/JProgressDisplay.o > ../../include/jcore/jMemory.o ../../include/jcore/jMath.o > ../../include/jcore/jAssert.o ../../include/jcore/JAssertBase.o > ../../include/jcore/jGlobals.o ../../include/jcore/JUserNotification.o > ../../include/jcore/JTextUserNotification.o .! > ./../include/jcore/JChooseSaveFil|e.o > ../../include/jcore/JTextChooseSaveFile.o > ../../include/jcore/JCreateProgressDisplay.o > ../../include/jcore/JCreateTextPG.o > ../../include/jcore/JTextProgressDisplay.o ../../include/jcore/JLatentPG.o > ../../include/jcore/JProcess.o ../../include/jcore/JProcessError.o > ../../include/jcore/JThisProcess.o ../../include/jcore/jProcessUtil.o > ../../include/jcore/jSignal.o ../../include/jcore/JInPipeStream.o > ../../include/jcore/JUNIXDirInfo.o ../../include/jcore/JUNIXDirEntry.o > ../../include/jcore/Templates-JString.o ../../include/jcore/Templates-int.o > ../../include/jcore/Templates-long.o ../../include/jcore/Te
new-bus, pcm, and matcd (was Re: new-bus breaks both sound drivers)
> >mp3s aren't playing quite right with x11amp though, little > >skips here and there, they work fine with the old kernel. > >mpg123 seems fine, as does the sound in FXTV. > >I'll try making the world again. > > Was there ever any resolution/further inspection of this? Not as far I know; its still happening here. cmp3 (mpg123) also skips in the same way, but its much less noticeable. I've been updating and recompiling almost daily. also, is it known that the matcd driver is now non-functional? It doesn't get probed at all, but it does show up in the visual kernel config screen. Its a 2x cdrom drive that plugs into my sb16; proprietary interface, not IDE. > grep matcd /sys/i386/conf/JAKE controller matcd0 at isa? port 0x230 bio > dmesg | grep matcd > Thank you. Jake -- we are but packets in the internet of life To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New ATA driver and crash dumps
On Fri, 23 Apr 1999, Mike Smith wrote: > >Is there any way I can help in getting the atapi-fd driver to work with > > LS-120's? > > Unless it was just recently broken, it works fine (I have one). ATA has never worked with my LS-120. It's a Digital Research/Mitsubishi, and I just can't get it to work right. I get garbled data, that's just it. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ m...@smith.net.au > \\ The race is long, and in the \\ msm...@freebsd.org > \\ end it's only with yourself. \\ msm...@cdrom.com > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: new-bus breaks both sound drivers
>> Hmm, you might like to try this patch and see what happens, there is >> a missing old driver wrapper for the pcm stuff. As a result, it's not >> getting run from the isa probe. Regarding the other driver, I'm not >> sure what's going on there as the hooks appear to be present. > >Right on, that patch does it for me. > >pcm0 at port 0x220 irq 5 drq 1 flags 0x15 on isa0 >pcm0: interrupting at irq 5 > >I've got an old SB16 Value, non-pnp. > >mp3s aren't playing quite right with x11amp though, little >skips here and there, they work fine with the old kernel. >mpg123 seems fine, as does the sound in FXTV. >I'll try making the world again. Was there ever any resolution/further inspection of this? x11amp behaves similarly for me. Actually, under considerable load, it is *really* bad. Have there been any notable scheduling changes recently? I remember people were seeing overflows on their serial ports after the new-bus integration since the driver was no longer using fast interrupts or something. Could there be something similar with the pcm driver? Chris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New ATA driver and crash dumps
>Is there any way I can help in getting the atapi-fd driver to work with > LS-120's? Unless it was just recently broken, it works fine (I have one). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: USB keyboard attach function?
> The problem was not really a bios problem not sure what the guys > did to fix the boot loader probably switch to using a dos int function > to access the keyboard from the boot loader. I haven't seen anything (being disconnected), but I thought I should just slap you for being so stupid as to think that DOS had anything to do with the loader. The loader's keyboard interface code uses the BIOS, like it always has. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/i386/conf LINT GENERIC
> > > P.S.: USBDI as in, our version of it. The people from the consortium > > > kicked us out. > > > Can you elaborate on the reason that USBDI does not FreeBSD > > to be involved with the consortium? > > Money. We cannot pay the fee (>1000 US $) to join the kindergarten aka > consortium. No company was willing to pay it for us and the consortium > was not willing to waive the fee, because not-for-profit organisations > still draw a certain benefit for their community, or something along > those lines. All sounds a bit strange if you consider the fact that the > spec will be open and free-for-all eventualy. Actually, there are a combination of issues. The cost involved in being a member is one issue, another is that to remain a "member in good standing" you have to attend at least one meeting every three months (ie. travel to/around the USA), and the third is that you need to be able to negotiate and sign legal agreements on behalf of your organisation. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
suspend mode broken since one week ago
I rebuilt my kernel just after the new config stuff (nexus). Since then (but I'm not 100% sure it is related to this) my desktop computer doesn't suspend anymore. Before that, I could suspend it either by: - pressing the suspend button - zzz command (apm -z) - wait until BIOS-set time for suspend mode passes Now it won't suspend in any way anymore (which is irritating since my computer is in the living room; it must be quiet but I don't want it to reboot all the time). Is this a bug that I should report through send-pr, is it already known as a bug or is this an intentional change in behaviour? -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know p...@xs4all.nl | the Netherlands| what I'm doing. ---+-+-- Running FreeBSD-current UNIX. See http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
Sean Eric Fagan wrote: > >> Here's a thing I've missed a couple of times: I'd like to be > >> able to see the limits for a process in /proc. > > At some point, I want to add an ioctl to get various process information > (well, multiple ioctl's, I think); SysVr4 has a bunch, and that's what I'd > model it on. We've already got a good chunk of that code for ELF coredump support. They are the same data structures... Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
Anthony Kimball wrote: > > : Against that there is a general Linuxism/Kitchen-Sink feeling. > > Think of this case as a plan9-ism. I think nothing of it... My opinions wouldn't matter a tiny little bit. :-) Still, after reading the Samba reply to the Microsoft, err, Mindcraft NTvsLinus benchmark, and the comments on tuning through /proc, I have to say I'd feel disgusted to have something like that on FreeBSD. It gave a whole new meaning to the word "arcane". Still, I'm against process privacy. We ought to be able to know anything about how a process is using *our* (the system's) resources. At least until we get proper compartimentalized security, which a number of people few is very un-Unix-like. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Well, Windows works, using a loose definition of 'works'..." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
: : Against that there is a general Linuxism/Kitchen-Sink feeling. : Think of this case as a plan9-ism. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Code Crusader 2.0.x on FreeBSD
Trying to see what the success rate is with everyone who's able to get Code Crusader 2.0.x to compile on FreeBSD either on -stable or -current. I have had no luck with getting it to compile on -stable (nor -current right now). ACE compiles successfully with config-freebsd-pthread.h and platform_freebsd_pthread.GNU, makemake compiles as well, but when it got to compiling JX core and libraries and rest (including Code Crusader) it core dumps. I modified the Makefile at the root JX dir so gmake freebsd would link in config-freebsd-pthread.h and platform_freebsd_pthread.GNU, and changed the line in ACE_JX_-1.1.22/include/make/sys/FreeBSD_g++ from: J_ACE_LIBS := -L${JX_ROOT}/lib -lACE-${ACE_LIB_VERSION} to: J_ACE_LIBS := -L${JX_ROOT}/lib -lACE-${ACE_LIB_VERSION} -pthread as per man pthread's directions to pull in libc_r.a. Does anyone have any success stories they would like to share? Or suggestions on how to cure the core dumps? I've tried the config-freebsd4.h and platform_freebsd4.GNU files from http://www.Pinyon.ORG/ace/ as well as the same files [34] from Ian West who posted his suggestions on Sat, 27 Mar 1999 23:46:14. Same core dumps on making make. Attached is the log of the make process after above modifications. Davegmake[1]: Entering directory `/usr/home/dave/temp/JX-1.1.22/lib' gmake[2]: Entering directory `/usr/home/dave/temp/JX-1.1.22/ACE' gmake[3]: Entering directory `/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers/ace' test -d .shobj || mkdir .shobj eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Basic_Types.o Basic_Types.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/OS.o OS.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Sched_Params.o Sched_Params.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/ACE.o ACE.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Active_Map_Manager.o Active_Map_Manager.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Arg_Shifter.o Arg_Shifter.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/ARGV.o ARGV.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Containers.o Containers.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Dirent.o Dirent.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Dynamic.o Dynamic.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Filecache.o Filecache.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Functor.o Functor.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Get_Opt.o Get_Opt.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Hash_Map_Manager.o Hash_Map_Manager.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/High_Res_Timer.o High_Res_Timer.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Method_Request.o Method_Request.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Object_Manager.o Object_Manager.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Profile_Timer.o Profile_Timer.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shobj/Registry.o Registry.cpp eg++ -Wall -O -fno-exceptions -D__ACE_INLINE__ -frepo -DACE_HAS_GNU_REPO -I. -I/usr/home/dave/temp/JX-1.1.22/ACE/ACE_wrappers -c -fpic -o .shob
Re: nice little kernel task for somebody
>> Here's a thing I've missed a couple of times: I'd like to be >> able to see the limits for a process in /proc. At some point, I want to add an ioctl to get various process information (well, multiple ioctl's, I think); SysVr4 has a bunch, and that's what I'd model it on. >I'd like to be able to open processes file discriptors too (so >you can still get files back if all the filsystem references to >it have gone, but a process still has it open). I might have a >go at doing both - if it isn't too Linuxesque. Ugh. I don't particularly like that one. It's fairly rare, and very invasive, and gives me the willies. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Colldef fails to make
On Fri, 23 Apr 1999, steven wrote: >At first i went to 4.x-Current, during buildworld colldef fails >giving dont know how to make de_DE.ISO_8859-15 (i think.. doing from >memory) > >so i tried the latest 3.x-Current and now i get syntax error's and error >69 when in build world. Someone posted make includes seemed to help >them along so i tried that and it still barfs.. I had colldef problems yesterday using stable. They were fixed by the evening. Perhaps this fix is in current too. I would try again today. Catchya Later, | Give me UNIX or give me a typewriter. Jason Wells | http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Colldef fails to make
Currently running 3.0-Current on my dual ppro machine. I cvsup'd this version back in mid Jan and thought it was time to try again. At first i went to 4.x-Current, during buildworld colldef fails giving dont know how to make de_DE.ISO_8859-15 (i think.. doing from memory) so i tried the latest 3.x-Current and now i get syntax error's and error 69 when in build world. Someone posted make includes seemed to help them along so i tried that and it still barfs.. i think its something wrong with my system so i'm prepping for a clean install but was wondering if anyone else has seen this error? Steven S. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New IDE Drivers
It seems Rick Whitesel wrote: > Hi: > I believe the problems I started having with the new IDE drivers may > be related to the bugs in the SMP IRQ handler described by Roger Hardiman. I > am going to wait until Roger fixes the bug to see if my IDE problem > disappears. I tried the latest drivers on a non SMP motherboard and they > work fine! Hmm, I run them/develop them on a SMP system, and they still works for me, but I might have some local changes that affects this too.. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
Dom Mitchell wrote: > > As for making ps totally proc aware, I'm not totally sure that's the way > to go. I shall have to have a look through the archives though; I've a > feeling that this has been discussed before... DCS, The Archive Man, comes to your help. If you make ps procfs dependent, you won't be able to use it on core dumps. That's different from making procfs complete enough to support a ps. Against that there is a general Linuxism/Kitchen-Sink feeling. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Well, Windows works, using a loose definition of 'works'..." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problems with symbol sequences in recent kernels
Greg Lehey wrote: > > This has worked quite nicely for some time. Since yesterday, after > building a kernel with newbus support, I get strange messages if I > read in the Vinum symbols before reading in the kernel symbols: ... > I debugged gdb and found that it was finding these references > (opt_global.h) in cd9660_rrip.o, which it read after reading the Vinum > kld symbols. If I can convince it to read the kernel symbols first, I > don't have any trouble. I don't think that it's anything to do with > that particular file; there must be about 30 files in a typical kernel > build which refer to this symbol. > > If I don't get any response on the list, I'll put in a PR, but I > thought there's a good chance that somebody will recognize this > problem and be able to fix it. Well, I don't recognize the problem, but I committed changes to cd9660_rrip.c after newbus got in. Could you try a kernel from before my changes got in? Just for the files I changed would be enough. This commit added Joliet Extensions support for cd9660, and affected cd9660 fs and mount_cd9660. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "Well, Windows works, using a loose definition of 'works'..." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
Dom Mitchell writes: >On 23 April 1999, adr...@freebsd.org proclaimed: >> Dom Mitchell writes: >> >What we really need are some tools similiar to solaris' /usr/proc/bin >> >stuff. http://www.sunworld.com/swol-04-1999/swol-04-supersys.html >> >Sadly, the ability to do this lies well outside my meagre coding >> >knowledge. >> >> A few of those utilities are avaliable right now (hell, I even wrote >> a pstree command to get a process tree listing a few months ago when >> I started messing about with procfs, but its rather crude atm), along >> with pcred, pflags, pgrep, plimit with what I've just written, >> and with a little magic, pmap, ptime, and the rest of them. > >I actually find these little tools to be very useful indeed. They make >investigating rogue daemons and suchlike far easier. And pmap is >wonderful for working out how much memory something is really taking up, >in detail. > >> But we'd need to extend our procfs just a little bit to work real >> magic (like say, proc-ps / proc-top), and I'm not prepared to >> start messing around with it in a big way, but if people are interested >> in a bunch of utilities like the sun /usr/proc/bin/ utilities, >> I might go ahead and write some. > >Well, I'd certainly be very grateful! Sign me up for testing your >patches... > >As for making ps totally proc aware, I'm not totally sure that's the way >to go. I shall have to have a look through the archives though; I've a >feeling that this has been discussed before... Yup - it'd mean keeping two sets of utilities, one for procfs/sysctl interfaces, and one for kvm interfaces for coredumps. I meant that if we wanted a procfs that gave us the -flexibility- to extract stuff out of the struct proc * without kvm_getprocs() ... Adrian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
On 23 April 1999, adr...@freebsd.org proclaimed: > Dom Mitchell writes: > >What we really need are some tools similiar to solaris' /usr/proc/bin > >stuff. http://www.sunworld.com/swol-04-1999/swol-04-supersys.html > >Sadly, the ability to do this lies well outside my meagre coding > >knowledge. > > A few of those utilities are avaliable right now (hell, I even wrote > a pstree command to get a process tree listing a few months ago when > I started messing about with procfs, but its rather crude atm), along > with pcred, pflags, pgrep, plimit with what I've just written, > and with a little magic, pmap, ptime, and the rest of them. I actually find these little tools to be very useful indeed. They make investigating rogue daemons and suchlike far easier. And pmap is wonderful for working out how much memory something is really taking up, in detail. > But we'd need to extend our procfs just a little bit to work real > magic (like say, proc-ps / proc-top), and I'm not prepared to > start messing around with it in a big way, but if people are interested > in a bunch of utilities like the sun /usr/proc/bin/ utilities, > I might go ahead and write some. Well, I'd certainly be very grateful! Sign me up for testing your patches... As for making ps totally proc aware, I'm not totally sure that's the way to go. I shall have to have a look through the archives though; I've a feeling that this has been discussed before... -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator "Value of 2 may go down as well as up" -- FORTRAN programmers manual -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
Dom Mitchell writes: >On 23 April 1999, Poul-Henning Kamp proclaimed: >> No, I just want a way to figure out what login.conf have done to >> various processes... > >What we really need are some tools similiar to solaris' /usr/proc/bin >stuff. http://www.sunworld.com/swol-04-1999/swol-04-supersys.html >Sadly, the ability to do this lies well outside my meagre coding >knowledge. A few of those utilities are avaliable right now (hell, I even wrote a pstree command to get a process tree listing a few months ago when I started messing about with procfs, but its rather crude atm), along with pcred, pflags, pgrep, plimit with what I've just written, and with a little magic, pmap, ptime, and the rest of them. But we'd need to extend our procfs just a little bit to work real magic (like say, proc-ps / proc-top), and I'm not prepared to start messing around with it in a big way, but if people are interested in a bunch of utilities like the sun /usr/proc/bin/ utilities, I might go ahead and write some. Adrian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
does login.conf limitations work ?
Hi, i was wondering if the limitations that are supposed to be enforced via the login.conf mechanism do really work... In particular, i have tried (on 3.1 something, but don't think that current is much different in this respect) to enforce the daily etc. login times but the system seems to ignore them. I think /etc/login.conf is properly parsed, because if i assign a user to a class that is not defined in login.conf i get complaints, but other than that i am unable to limit login time... Any hints ? cheers luigi ---+- Luigi RIZZO . EMAIL: lu...@iet.unipi.it. Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) ---+- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
On 23 April 1999, Poul-Henning Kamp proclaimed: > No, I just want a way to figure out what login.conf have done to > various processes... What we really need are some tools similiar to solaris' /usr/proc/bin stuff. http://www.sunworld.com/swol-04-1999/swol-04-supersys.html Sadly, the ability to do this lies well outside my meagre coding knowledge. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator "Value of 2 may go down as well as up" -- FORTRAN programmers manual -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
In message <19990423123108.14692.qm...@ewok.creative.net.au>, adr...@freebsd.or G writes: >I've finished the patch. I'll test it a little more when I get back >home tonight, and then send the URL to -current for people to poke >around with. > Cool! >phk - I hope you didn't also want the process limits to be modifyable >the same way just yet :-) (but it'd be nice however... maybe later.) No, I just want a way to figure out what login.conf have done to various processes... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
Zach Heilig writes: >On Fri, Apr 23, 1999 at 05:16:33PM +0800, adr...@freebsd.org wrote: >> I don't know about that one, but the first one sounds easish. >> Since I've been messing around with procfs quite a bit lately, >> I'll spend some time later today poking around and produce a patch >> against -current . > >I don't know how to do this, but I did notice this much: (the binary does >remain accessible even after it's removed, as long as it doesn't exit). > >#include >#include >#include >#include > >int main(int argc, char **argv) { > int id; > char cmd[128]; > unlink(argv[0]); > id = getpid(); > printf("pid == %d\n", id); > sprintf(cmd, "ls -l /proc/%d", id); > system(cmd); > exit(0); >} > >$ cc foo.c >$ ./a.out >pid == 78597 >total 4 >-r--r--r-- 1 zach wheel 0 Apr 23 07:00 cmdline >--w--- 1 zach wheel 0 Apr 23 07:00 ctl >-r--r--r-- 1 zach wheel76 Apr 23 07:00 etype >-rwxrwxr-x 0 zach wheel 3637 Apr 23 07:00 file >-rw--- 1 zach wheel 176 Apr 23 07:00 fpregs >-r--r--r-- 1 zach wheel76 Apr 23 07:00 map >-rw-r- 1 zach kmem 0 Apr 23 07:00 mem >--w--- 1 zach wheel 0 Apr 23 07:00 note >--w--- 1 zach wheel 0 Apr 23 07:00 notepg >-rw--- 1 zach wheel76 Apr 23 07:00 regs >-r--r--r-- 1 zach wheel 0 Apr 23 07:00 status >$ > >[note the '0' links for the binary] > Which is right though, isn't it? I've finished the patch. I'll test it a little more when I get back home tonight, and then send the URL to -current for people to poke around with. phk - I hope you didn't also want the process limits to be modifyable the same way just yet :-) (but it'd be nice however... maybe later.) Adrian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
On Fri, Apr 23, 1999 at 05:16:33PM +0800, adr...@freebsd.org wrote: > I don't know about that one, but the first one sounds easish. > Since I've been messing around with procfs quite a bit lately, > I'll spend some time later today poking around and produce a patch > against -current . I don't know how to do this, but I did notice this much: (the binary does remain accessible even after it's removed, as long as it doesn't exit). #include #include #include #include int main(int argc, char **argv) { int id; char cmd[128]; unlink(argv[0]); id = getpid(); printf("pid == %d\n", id); sprintf(cmd, "ls -l /proc/%d", id); system(cmd); exit(0); } $ cc foo.c $ ./a.out pid == 78597 total 4 -r--r--r-- 1 zach wheel 0 Apr 23 07:00 cmdline --w--- 1 zach wheel 0 Apr 23 07:00 ctl -r--r--r-- 1 zach wheel76 Apr 23 07:00 etype -rwxrwxr-x 0 zach wheel 3637 Apr 23 07:00 file -rw--- 1 zach wheel 176 Apr 23 07:00 fpregs -r--r--r-- 1 zach wheel76 Apr 23 07:00 map -rw-r- 1 zach kmem 0 Apr 23 07:00 mem --w--- 1 zach wheel 0 Apr 23 07:00 note --w--- 1 zach wheel 0 Apr 23 07:00 notepg -rw--- 1 zach wheel76 Apr 23 07:00 regs -r--r--r-- 1 zach wheel 0 Apr 23 07:00 status $ [note the '0' links for the binary] -- Zach Heilig To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
New IDE Drivers
Hi: I believe the problems I started having with the new IDE drivers may be related to the bugs in the SMP IRQ handler described by Roger Hardiman. I am going to wait until Roger fixes the bug to see if my IDE problem disappears. I tried the latest drivers on a non SMP motherboard and they work fine! Rick Whitesel To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel build from a non-/usr/src/sys directory failing?
Mikhail Teterin writes: >adr...@freebsd.org once stated: > >=I just went to config a kernel on a -current system supped yesterday, >=with the source sitting in my home directory,and suddenly .. >= >=adr...@java:/usr/home/adrian/work/procfs/sys/compile/JAVA$ make depend >=make: don't know how to make ../../../include/stddef.h. Stop >=adr...@java:/usr/home/adrian/work/procfs/sys/compile/JAVA$ >= >=Now, I could swear to god this used to work.. any ideas? > >Look for stale .depend file(s)... > > -mi Ignore my temporary insanity ladies and gentlemen, suffice to say the coffee machine is percolating as we speak. Adrian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
kernel build from a non-/usr/src/sys directory failing?
I just went to config a kernel on a -current system supped yesterday, with the source sitting in my home directory,and suddenly .. adr...@java:/usr/home/adrian/work/procfs/sys/compile/JAVA$ make depend make: don't know how to make ../../../include/stddef.h. Stop adr...@java:/usr/home/adrian/work/procfs/sys/compile/JAVA$ Now, I could swear to god this used to work.. any ideas? Adrian -- Adrian Chadd To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nice little kernel task for somebody
David Malone writes: >> Here's a thing I've missed a couple of times: I'd like to be >> able to see the limits for a process in /proc. > >I'd like to be able to open processes file discriptors too (so >you can still get files back if all the filsystem references to >it have gone, but a process still has it open). I might have a >go at doing both - if it isn't too Linuxesque. I don't know about that one, but the first one sounds easish. Since I've been messing around with procfs quite a bit lately, I'll spend some time later today poking around and produce a patch against -current . Adrian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lnc0: broke for us between 3.1 and 4.0?
> And does this all mean that if I want my kernel source tree to be > consistent more often than not (and any errors be fixed as soon as > possible), I'd be better off switching from -stable to -current? Yes and no. Stable will give you a broken tree less often. But people in Current have a habit of fixing things first in Current :-) The ideal combination: Running stable and keeping track of current, backporting whatever you think is of use to you. Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lnc0: broke for us between 3.1 and 4.0?
p...@originative.co.uk writes: > > From: Richard Tobin [mailto:rich...@cogsci.ed.ac.uk] > > Is this fix going into stable? (I'm a little surprised that such a > > change was considered appropriate for the stable branch in the first > > place.) > > I didn't think the memory allocation change was in stable but I may merge > the lnc changes back into -stable anyway since it's a cleaner way of doing > things. > > I've got some other lnc problems to fix first though. Will this take very long? Because my "stable" source tree has not produced a working kernel for me for several weeks because of this. And does this all mean that if I want my kernel source tree to be consistent more often than not (and any errors be fixed as soon as possible), I'd be better off switching from -stable to -current? -- Frode Vatvedt Fjeld To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message