Problems with symbol sequences in recent kernels
I've just had a strange experience. I have some gdb macros which I use for debugging Vinum. One, ps, gives me a ps-like listing: (kgdb) ps Check your .gdbinit, it contains a y command pidprocaddr uid ppid pgrp flag stat comm wchan 1544 c68a5100 c6df30000 1534 1544 004006 2 Vinum 1534 c68a57e0 c6ddb0000 1524 1534 004086 3 bash wait c68a57e0 1524 c68a5c00 c6dc9000 1004 1516 1524 004086 3 bash wait c68a5c00 Another macro helps me load symbols from a kld: Without: (kgdb) bt #0 Debugger (msg=0xc11696a0 vinum debug) at ../../i386/i386/db_interface.c:318 #1 0xc1163585 in ?? () #2 0xc01826ea in spec_ioctl (ap=0xc6df4e1c) at ../../miscfs/specfs/spec_vnops.c:440 With: (kgdb) bt #0 Debugger (msg=0xc11696a0 vinum debug) at ../../i386/i386/db_interface.c:318 #1 0xc1163585 in vinumioctl (dev=0x40001901, cmd=0xc008464b, data=0xc6df4ee0 , flag=0x3, p=0xc68a5100) at /src/PANIC/src/sys/modules/Vinum/../../dev/Vinum/vinumioctl.c:96 #2 0xc01826ea in spec_ioctl (ap=0xc6df4e1c) at ../../miscfs/specfs/spec_vnops.c:440 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: (kgdb) bt #0 Debugger (msg=0xc11696a0 vinum debug) at ../../i386/i386/db_interface.c:318 #1 0xc1163585 in vinumioctl (dev=0x40001901, cmd=0xc008464b, data=0xc6df4ee0 , flag=0x3, p=0xc68a5100) at /src/PANIC/src/sys/modules/Vinum/../../dev/Vinum/vinumioctl.c:96 During symbol reading, repeated header file opt_global.h not previously seen, at symtab pos 23. During symbol reading, Invalid symbol data: type number (2,2) out of range at symtab pos 25.. #2 0xc01826ea in spec_ioctl (ap=0xc6df4e1c) at ../../miscfs/specfs/spec_vnops.c:440 The following stack frames also look strange: #5 0xc017ccdd in vn_ioctl (fp=error type, com=incomplete type, data=incomplete type, p=error type) at vnode_if.h:395 #6 0xc015c5f7 in ioctl (p=0xc68a5100, uap=0xc6df4f94) at ../../kern/sys_generic.c:564 #7 0xc021e916 in syscall (frame=error type) at ../../i386/i386/trap.c:1071 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. 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: solid NFS patch #6 avail for -current - need testers files)
Brian Feldman wrote: I just wish april would go away, very, very fast... Here's a challenge to help you get by the rest of the days, figure out how to write my name, in its original form I was given at birth :-) Hmm... is it cheating to use Hiragana? (^_^) Being a chinese name (I think -- not a japanese one, for sure), I don't think it will help. Besides, you can't spell an L in hiragana. :-) My own take is (japanese characters -- sorry, no chinese input) 陳 for Chen. For Luoqi, japanese shift-jis/euc-jp just won't do. Well, I cheated, anyway... -- 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
Cross patches
I've had a bunch of requests for what I'm using to cross build. I've put up the cross compilation development patches that I have done so far at http://www.village.org/villagers/imp/freebsd-cross-1.patch.gz for anybody to give a test spin. There are no directions, but if you do a make buildworld TARGET=i386 TARGET_ARCH=i386 on an alpha, you should get a complete i386 world that can be installed on a i386 machine. It is critically important that you include both the TARGET and TARGET_ARCH on the command line, otherwise this won't work. They patch the two files that I needed to patch to get the cross building stuff working. However, note that so far I've not gotten past building the libraries on mips, due to kernel include files I've not written/imported yet, so I don't know how far it will make it. I release these patches in the hopes they are useful. I don't know if this is the direction that FreeBSD wants to take wrt cross building binaries or not. It is certainly a good learning experience. I also don't know if our tools are up to the task of generating working alpha code on a i386 box. I got all kinds of warnings when I tried to do that which lead me to believe that the answer was no (things like shifts 32 bits). Please let me know what you think of these patches. If you have updates to them, please let me know. I'd have to characterize them as a rapid prototyping learning experience at the moment. However, every time I tried to do something more elegant I ran into boatloads of problems. Warner 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
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: 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
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 adr...@freebsd.org 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
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: 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 sys/types.h
#include stdio.h
#include stdlib.h
#include unistd.h
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 z...@uffdaonline.net
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 sys/types.h
#include stdio.h
#include stdlib.h
#include unistd.h
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
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
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
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
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
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, 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: 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 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: 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
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: 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
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
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
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
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
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
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: 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
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
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
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: 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/Templates-longlong.o
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: % [...] %/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: 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
