Re: lots of things (pcic, pccard, ep0) on irq3. Problem ?
In message <[EMAIL PROTECTED]> "Joesh Juphland" writes:
: 2. Somehow, some way, in upgrading from 4.3 to 4.4 on this laptop, I have
: developed irq conflicts - maybe 4.4 just arranges things differently.
:-) We now share interrupts for pccard.
: The end result ? ep0 works, on irq 3, and ep1 bombs out with the infamous
: "No card in database for "(null)"("(null)")
That's the real problem. We're not able to read in the CIS. Can you
send me a boot -v ?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: C++ code in the FreeBSD kernel
In message <[EMAIL PROTECTED]> Jean-Francois Dive writes: : I beleive that something to do as well is to remove the RTTI support from : the compilation ... Yes. I also think that the default turned on exceptions, which caused some issues. There were also a few headers I had to patch to make them more properly type safe for C++. Plus maybe a few things I'm forgetting. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.4 boot question
In message <006f01c15d7c$1e995e20$050a@LORENZO> "Dr. Lorenzo Iania" writes:
: pci_cfgintr_search: linked (41) to configured irq 0 at 0:2:0
I have a patch for this:
Index: pci.c
===
RCS file: /cache/ncvs/src/sys/pci/Attic/pci.c,v
retrieving revision 1.141.2.10
diff -u -r1.141.2.10 pci.c
--- pci.c 2001/08/21 17:21:13 1.141.2.10
+++ pci.c 2001/08/27 07:01:38
@@ -1610,7 +1610,8 @@
* If device doesn't have an interrupt routed, and is
* deserving of an interrupt, try to assign it one.
*/
- if ((type == SYS_RES_IRQ) && (cfg->intline == 255) &&
+ if ((type == SYS_RES_IRQ) &&
+ (cfg->intline == 255 || cfg->intline == 0) &&
(cfg->intpin != 0) && (start == 0) && (end == ~0UL)) {
cfg->intline = pci_cfgintr(pci_get_bus(child),
pci_get_slot(child), cfg->intpin);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: C++ code in the FreeBSD kernel
In message <[EMAIL PROTECTED]> Denis Serenyi writes: : Has anyone out there tried to get C++ code running in the freebsd kernel : (like as a .ko)? Yes. In fact, it used to work OK if you don't do exceptions. But there are some issues with the newer compilers I've never bothered to track down. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Panic w/ bqrelse: multiple ref .. we thought fixed a year ago
Hello Sorry to be cross posting it here BUT we did post this to questions w/o any resolution or responses. well actually we did get 1 response fr Kirk I think telling us that this should not be happening in the 4.X series. Everyone pls take a look at this, as it is certainly a strange 1. We're also starting to suspect maybe a h/w type of defect as this machine is startting to reboot itself, yep it reboots ITSELF!!, when we load it up w/ tasks that bring the CPU utilization to 95%+, (ACTUALLY ALL THESE 6 machines we use for stats apps that really hammer the CPU ) The machine's mem chip maybe? or mobo??? Pls answer to me as I'm not subscribed to this list. Prev posted in questions: We are having a big problem running FreeBSD 4.3-REL 1.4GHz AMD w/ 512MB RAM (single chip) w/ ABIT KT7A mobo w/ the VIA 133A chipset. and we are seeing "bqrelse: multiple refs" problem. The panic then the dump, syncing disks.. We thought this was fixed over a year ago in vfs_bio.c This problem occured most recently when I exit'ed a remote ssh session. The exit took several seconds, and caused me to believe something was wrong. I then logged back in, and sure enough, we had a 'sh.core' dump file (of zero size) and my running jobs had died. (The machine dumped.) Later, I could not get in at all, (of course the machine was dead at that point) and the other 6 machines doing NFS writes failed as well. NFS structure IS: This machine with this problem, call it PRIME1, NFS serves 6 other FBSD4.3 machines as clients. They ALL mount PRIME1's /mnt/public and all 6 write into this directory with their own files. SO we made this an NFS client ONLY, that's when it started rebooting itself instead of giving us the bqrelse mesg and staying at the dead console window. The NFS server is now an older slower 4.2-REL machine that doesn't do ANYTHING except serve NFS whereas this machine WAS serving NFS AND doing some intensive computing @same time, BTW all 6 of these machines w/ this stats app bring the CPU utilization to 95%+ for 12 hrs routinely. So, this morning, searching the net, we found several references (fr July 2000) to "bqrelse" but none of the references seemed to assert that the fix was such-and-such. Does a fix exist? By the way, I maintain multiple FreeBSD 4.3-REL boxes and am doing lot's of NFS activity, in addition to my occasional SSH login. I am willing to reconfig the kernel & make queue's larger, change parameters or whatever else it takes to make this work. Pls help us. __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Europe and the UK from Nov 5th through Nov 14th.
On Tue, Oct 30, 2001 at 03:18:47AM +, George Reid wrote: > On Mon, Oct 29, 2001 at 05:53:05PM -0800, Jordan Hubbard wrote: > > > If anyone's interested in meeting up with us, that's where we'll be! > > Visit Oxford! We have old stuff! Most of Europe is old stuff, some much older than Oxford. Oxford does have some top notch pubs and great beer. Josef -- Josef Grosch | Another day closer to a | FreeBSD 4.4 [EMAIL PROTECTED] | Micro$oft free world | www.bafug.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Europe and the UK from Nov 5th through Nov 14th.
On Mon, Oct 29, 2001 at 05:53:05PM -0800, Jordan Hubbard wrote: > If anyone's interested in meeting up with us, that's where we'll be! Visit Oxford! We have old stuff! -- George C A ReidTel: (08701) 200870 Ext. 26654 FreeBSD Committer/Developer [EMAIL PROTECTED] Oriel College, Oxford University[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
I will be in Europe and the UK from Nov 5th through Nov 14th.
JFYI, Brett Halle (the director of CoreOS engineering for Apple) and I will be speaking at the NLUUG's Autumn Conference in Ede, The Netherlands on November 8th and then travelling on to BSDCon Europe in Brighton, UK immediately thereafter (the 9th) and staying in the UK until November 14th. If anyone's interested in meeting up with us, that's where we'll be! - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MT-Safe wrapper around memcpy()?
Thanks! Precisely what I was looking for. I coded up the routines today and they seem to work fine. On Mon, 29 Oct 2001, Daniel Eischen wrote: > The _THREAD_SAFE macro has gone away anyways (in -current), and we > (FreeBSD) shouldn't be conditionally compiling code in libc dependent > on whether libc_r is being built or not. And I wouldn't recommend it > for user libraries either. > > Take a look at how libgcc works (src/contrib/gcc.295/gthr-posix.h). [...snip...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vnode locking state for bread()
Hi! Forgive me if i overlooked documentation and sources, but i can't find any references on subject. Could somebody shed light if i need to lock vnode or not to call bread()? Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problems with recurring SIGTRAP under gdb
SIGIO is used, but only for AIO and at this point no
aio_* calls have been made.
The loop for reading from STDIN may be a problem but I
don't see how - this same loop is used without
problems
on Linux, OSF, and Solaris (although on Linux if you
press Ctrl-C in gdb it often won't let you continue):
int
sim_getc(char *cp)
{
int r;
sk_wait_for_fd(0);
r = read(0, cp, 1);
if (r <= 0) {
dbg_printf("pccons_getchar: read
failed: %s\n", error_msg());
sk_panic("pccons_getchar: failed read
on stdin");
}
return r;
}
sk_wait_for_fd is just:
void sk_wait_for_fd(int fd)
{
int slot;
sk_Msg *msg;
if (sk_poll_one_fd(fd)>0) {
/* fd is already ready */
return;
}
slot = sk_add_poll_fd(fd);
if(slot < 0)
return;
do {
msg = sk_receive();
if((msg->type == SK_SIGNAL_MSG) &&
(msg->data.l == HARD_SIG_00010))
break;
} while (1);
sk_remove_poll_fd(slot);
}
beneath this it just uses poll
--- Ian Dowse <[EMAIL PROTECTED]> wrote:
> In message
>
<[EMAIL PROTECTED]>,
> k Macy writes:
> >Any idea why when I insert a breakpoint I get a
> >SIGTRAP
> >and can't continue any further? Is this a bug in
> the
>
> I've seen this on applications that use SIGIO on
> stdin. If this is the
> case, a workaround is to disable the SIGIO signal
> while using the
> debugger, e.g:
>
> (gdb) set $oldsigio = signal(23, (void *)1)
>
> The signal handler can be put back later with:
>
> call signal(23, (void *)$oldsigio)
>
> Ian
__
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
* Michael Sinz <[EMAIL PROTECTED]> [011029 14:07] wrote: > > This has bitten a number of support people - a server fills up and they > get a bit too loose with the "rm" command and logging stops. > > I actually somewhat understand why syslogd does not open/create the file > using the current syslog.conf syntax - it is hard to descript user/group > ownership and access rights in the syslog.conf. The thing that syslogd > does is write to the file that already exists such that the access rights > can be controlled externally to the syslogd process. > I'm jumping in having only paid cursory attention to the current thread so my apologies if this makes little sense. Why not add a flag or something to syslog or newsyslog which somehow evaluates the space available and/or creates the new files. We could switch the system defaults via src/etc/defaults to advise the use of this flag in 4.x and actually default to it in 5.x. I guess this would have to address the permissions problem, perhaps there's some way of addiding additional fields to syslog.conf? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
David O'Brien wrote: > > On Sat, Oct 27, 2001 at 12:26:22AM -0400, Mike Barcroft wrote: > > Just to clarify. This is still a POLA violation. If a log file is > > pulled out from underneath syslogd(8), one wouldn't expect it to start > > logging again, even if the file was re-created. > > I disagree, if the file was re-created. > > Actually, I find it weird and counter intuitive that syslogd will not > log to the files in the config file (/etc/syslog.conf) unless they > already exists. It really feels like we are living with a programming > bug 25 years later > > If I didn't want syslogd to log something, I would not have it in > syslog.conf. This has bitten a number of support people - a server fills up and they get a bit too loose with the "rm" command and logging stops. I actually somewhat understand why syslogd does not open/create the file using the current syslog.conf syntax - it is hard to descript user/group ownership and access rights in the syslog.conf. The thing that syslogd does is write to the file that already exists such that the access rights can be controlled externally to the syslogd process. I really hate this and wish I could change this without suddenly causing all of us old-timers to surprised. For me I see two different POLA issues: 1) For those who have already understood and used syslog for a long time - syslogd does not create a file... 2) For those who have not had much time with syslog - it is rather upsetting to have configured syslog.conf and you either HUP or reboot and yet the logging does not start. As the world of FreeBSD (and other syslog systems) increases, the ratio of people is catagory #2 vs #1 will continue to increase. (Most people do not spend much time playing with syslogd) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PATCH for review: ipfilter changes in rc.*
Darren Reed wrote: >In some email I received from Arjan de Vet, sie wrote: >> I wrote similar patches (see http://home.iae.nl/users/devet/freebsd/) >> trying to fix more or less the same bugs/problems. >> >> Maybe it's a good idea if Giorgos and I together come up with 1 'big' >> ipfilter /etc/rc.* and rc.conf.5 patch which includes the best parts of >> both our patches? > >That sounds like a good plan. OK, updated patches for stable and current are available from: http://home.iae.nl/users/devet/freebsd/ I include the README here: This is joint work with Giorgos Keramidas. Patches to fix and cleanup ipfilter/ipnat code in the /etc/rc.* framework both for -current and -stable, including an update to the rc.conf(5) manual page. Note that for stable 'ipfs' should be MFC'ed first! Overview of problems fixed: - ipmon(8) is started before loading any filter/NAT rules; - ipmon(8) and ipfs(8) do not solely depend on ipfilter_enable anymore, they now also work when only ipnat_enable is true; - the multiple occurrences of code loading the ipfilter kernel module have been removed; - the options have been removed from the _program variables in defaults/rc.conf and the comments in that file have been updated to reflect (possibly new) reality; - the rc.conf.5 manual page has been updated to reflect the changes. After this patch has been applied the following ipfilter related PRs can be closed: kern/25344 conf/26275 bin/27016 conf/31482 conf/25223 conf/25809 Darren: please wait for the comments of Doug Barton before committing, he wants to review the patch for possible rc.* style issues first. Arjan -- Arjan de Vet, Eindhoven, The Netherlands <[EMAIL PROTECTED]> URL : http://www.iae.nl/users/devet/<[EMAIL PROTECTED]> Work: http://www.madison-gurkha.com/ (Security, Open Source, Education) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Mon, Oct 29, 2001 at 09:42:19AM -0800, Terry Lambert wrote: > David O'Brien wrote: > > > > On Mon, Oct 29, 2001 at 08:35:35AM -0800, Terry Lambert wrote: > > > > No muss, no fuss. So where is the race? > > > > Mike had the only justification so far -- that of permissions of the > > > > file. > > > > > > Think multiple instances of syslogd. > > > > You are going to have to help me out a little bit more -- I can think of > > no problems with what I proposed vs. the existing way. Both have a race > > of which daemon opens the file first. > > Not if you don't use O_CREAT; then they don't. Why not? If the file exists and I start up two syslogd's, there is a race of which one open's the file first. If I start up two syslogd's and the file does not exist and then I touch the file. There will be a race if I ``kill -HUP ''. If I take care to HUP only one syslogd, move the file to the side, touch the file again and HUP the second syslogd there is no race. I can similarly take this amount of care with the way I would like syslogd to work such that there is no race. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Mon, Oct 29, 2001 at 01:16:29PM -0500, Leo Bicknell wrote: > On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote: > > The _useful_ thing to do would be to roll the newsyslog > > functionality into syslogd; however, as a .conf file that > > is expected to be distributed over NIS, I think that doing > > the syntax change is probably a bad idea... > > After seeing all the mess here, I'll make a recomendation. Perhaps > it's time to write a whole new tool that combines syslogd and > newsyslog and some other functionality all in one place, and fixes > all of the issues that have been put forth here. Since it's a new > tool, it can start from a clean slate, and needs no compatability > features. Both can be included for a suitable transition period, > and eventually syslogd could die. I've been thinking for some time about a tool that gathers log lines like syslogd, then passes them to DJB's multilog (part of the daemontools package, http://cr.yp.to/daemontools). multilog already can rotate logs, limit both the total size and each individual file's size, log various messages to various locations; it also does all of this in real time, so it is not subject to DoS's between two rotations. I'll try to get around to writing the syslogd-like message gathering thing sometime soon.. G'luck, Peter -- If this sentence were in Chinese, it would say something else. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote: > The _useful_ thing to do would be to roll the newsyslog > functionality into syslogd; however, as a .conf file that > is expected to be distributed over NIS, I think that doing > the syntax change is probably a bad idea... After seeing all the mess here, I'll make a recomendation. Perhaps it's time to write a whole new tool that combines syslogd and newsyslog and some other functionality all in one place, and fixes all of the issues that have been put forth here. Since it's a new tool, it can start from a clean slate, and needs no compatability features. Both can be included for a suitable transition period, and eventually syslogd could die. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
David O'Brien wrote: > > On Mon, Oct 29, 2001 at 08:35:35AM -0800, Terry Lambert wrote: > > > No muss, no fuss. So where is the race? > > > Mike had the only justification so far -- that of permissions of the > > > file. > > > > Think multiple instances of syslogd. > > You are going to have to help me out a little bit more -- I can think of > no problems with what I proposed vs. the existing way. Both have a race > of which daemon opens the file first. Not if you don't use O_CREAT; then they don't. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
jail's /proc
Hello, i really have no clue if i should mail this to you guys, but we've found some issue's in de jail's /proc. We were able to find information about processes running outside the jail, or running in other jails. eg. when i run sshd in the host system, and it has PID 655, i can login on the jail, and by execution "ls -l /proc/665/file" i can see what binary is running on pid 655. So any user of the jail system can see what processes you run on that server. I'm running FreeBSD 4.4-RELEASE on a i386. greetz, Pieter Danhieux Proof of concept shellscript: #!/bin/sh _COUNT=0; while [ $_COUNT -le 65000 ]; do if [ -f /proc/$_COUNT/file ]; then _USER=`/bin/ls -l /proc/$_COUNT/file | cut -d" " -f4`; _PROC=`/bin/ls -l /proc/$_COUNT/file | cut -d" " -f14`; echo "PID= $_TELLER USER= $_USERPROC= $_PROC"; fi _COUNT=`expr $_COUNT + 1`; done - [www.bsdaemon.be] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Mon, Oct 29, 2001 at 08:35:35AM -0800, Terry Lambert wrote: > > No muss, no fuss. So where is the race? > > Mike had the only justification so far -- that of permissions of the > > file. > > Think multiple instances of syslogd. You are going to have to help me out a little bit more -- I can think of no problems with what I proposed vs. the existing way. Both have a race of which daemon opens the file first. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Test Suites
Alfred Perlstein wrote: > > * Thomas S. Greenwalt <[EMAIL PROTECTED]> [011028 23:04] wrote: > > Are there any test suite packages available similiar to Visual Test from > > Rational? Not necessarily with a GUI, but the ability to build test scripts > > to test features of applications written for BSD? > > Thanks. > > There's a tool called 'expect' you can probably find in the ports. > > There's a been a couple of books about it published. Look also for "TET" and "ETET". SVVS (the System V Verification Suite, used for testing SVID compliance) uses TET. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
David O'Brien wrote: > > If it created the file itself, there would be a potential > > race issue that would remain unresolved, which is hidden by > > the seperation of the create and the subsequent signal. > > Come again? > > 1. syslogd calls open(2) with O_CREAT. At this point syslogd happily >keeps the file open and writes to it. > 2. I rename the file. As we all know, syslogd keeps writing to its open >file. > 3. syslogd is HUP'ed, goto #1. > > No muss, no fuss. So where is the race? > Mike had the only justification so far -- that of permissions of the > file. Think multiple instances of syslogd. Mike's justification was also my justification; you'd have to change the configuration file format to get the same values. If syslogd is running as someone capable of opening files in a directory also does not necessarily imply the ability to create the file (otherwise you'd be able to dismiss Mike's objection with an fstat() after the hup, followed by the create using the same properties -- so Mike's objection is more subtle than it first appears, as well). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCChips M765VMRT VIA 82C596B and Smbbus
Hi There, [posted to -questions some time back] I'm trying to get the power monitoring functions of this motherboard going and have run into some problems. I've found this doesnt seem to be supported at all in 4.4 but have found some code on http://people.freebsd.org/~nsouch/iicbus.html and attempted to patch it. Problem here with the diffs is they are out of sync with the 4.4-STABLE tree. Could anyone provide any help with getting this code either working or provide any advice on the next steps. Thanks in advance, Si. The diag info's. FreeBSD breakbeat.inner-city.org.uk 4.4-STABLE FreeBSD 4.4-STABLE #0: Tue Oct 9 19:26:34 BST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BREAKBEAT i386 FreeBSD 4.4-STABLE #0: Tue Oct 9 19:26:34 BST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BREAKBEAT Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x650 Stepping = 0 Features=0x183f9ff real memory = 184483840 (180160K bytes) avail memory = 175304704 (171196K bytes) Preloaded elf kernel "kernel" at 0xc0413000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 10 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xdf00-0xdf1f irq 9 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ichsmb0: at device 7.3 on pci0 device_probe_and_attach: ichsmb0 attach returned 6 [snipped rest] -- Simon Griffiths Systems Administrator - Clay Cross Building Society Tel:+44(0)1246 862120 - Fax: +44(0)1246 250397 -- "If you give a million monkeys root access to your systems, they sure as hell aren't going to be writing any Shakespeare..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MT-Safe wrapper around memcpy()?
On Mon, 29 Oct 2001, Lamont Granquist wrote:
> On Mon, 29 Oct 2001, Alfred Perlstein wrote:
> > * Alfred Perlstein <[EMAIL PROTECTED]> [011029 00:53] wrote:
> > > * Lamont Granquist <[EMAIL PROTECTED]> [011029 00:43] wrote:
> > > >
> > > > I'm trying to figure out the best way to write a wrapper around memcpy()
> > > > which can call fprintf() without winding up getting into a recursive
> > > > loop. The problem is that fprintf() will call memcpy() and around and
> > > > around we go.
> > > >
> > > > I can use a global variable to prevent this, but that usage isn't thread
> > > > safe. I can make it thread safe by using pthread keys, but then i have to
> > > > link in libc_r, and for non-pthreaded programs i don't want to do that.
> > > >
> > > > Anyone have any suggestions? Right now I'm almost thinking that I just
> > > > need to directly patch libc and libc_r. It might be an ugly patch though,
> > > > and I'd rather not have this patch mandate recompiling all of libc.
> > >
> > > Where do you see mem* calling printf?
> >
> > Uh, nevermind. :)
> >
> > Ok, what you want to do is use a nested flag in memcpy so you
> > don't recurse, there's some code in libc that's conditionally
> > compiled when compiling libc_r, _THREAD_SAFE or something is
> > defined, once you find that then just simply use the global
> > for non threaded programs and keys for threaded ones.
>
> you mean like localtime.c:
>
> #ifdef _THREAD_SAFE
> pthread_mutex_lock(&lcl_mutex);
> #endif
>
> and such?
The _THREAD_SAFE macro has gone away anyways (in -current), and we
(FreeBSD) shouldn't be conditionally compiling code in libc dependent
on whether libc_r is being built or not. And I wouldn't recommend it
for user libraries either.
Take a look at how libgcc works (src/contrib/gcc.295/gthr-posix.h).
In your application library, make wrapper functions for whatever
thread routines you need to use in a threaded application. Then
make weak _references_ to the actual (non-wrapped) pthread
routines. So you'd have something like:
/* File mylib_threads.c */
#pragma weak pthread_mutex_lock
#pragma weak pthread_mutex_unlock
#pragma weak pthread_key_create
#pragma weak pthread_key_delete
#pragma weak pthread_once
[add any others you might need]
#pragma weak pthread_create
static void app_is_threaded = &pthread_create;
int mylib_is_threaded(void)
{
return (app_is_threaded != NULL);
}
int mylib_pthread_mutex_lock(pthread_mutex_t *mutex)
{
if (mylib_is_threaded())
return (pthread_mutex_lock(mutex);
else
return (0);
}
...
By making the references to pthread_* weak, the linker will not
barf if libc_r isn't linked in, and all references will be NULL.
If the application is threaded (libc_r is linked in), then those
references will be resolved.
Make sure the weak pragmas are localized to the file that actually
implements the wrapper functions. You don't want them visible to
other files that directly use pthreads.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: problems with recurring SIGTRAP under gdb
In message <[EMAIL PROTECTED]>, k Macy writes: >Any idea why when I insert a breakpoint I get a >SIGTRAP >and can't continue any further? Is this a bug in the I've seen this on applications that use SIGIO on stdin. If this is the case, a workaround is to disable the SIGIO signal while using the debugger, e.g: (gdb) set $oldsigio = signal(23, (void *)1) The signal handler can be put back later with: call signal(23, (void *)$oldsigio) Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MT-Safe wrapper around memcpy()?
On Mon, 29 Oct 2001, Alfred Perlstein wrote: > * Alfred Perlstein <[EMAIL PROTECTED]> [011029 00:53] wrote: > > * Lamont Granquist <[EMAIL PROTECTED]> [011029 00:43] wrote: > > > > > > I'm trying to figure out the best way to write a wrapper around memcpy() > > > which can call fprintf() without winding up getting into a recursive > > > loop. The problem is that fprintf() will call memcpy() and around and > > > around we go. > > > > > > I can use a global variable to prevent this, but that usage isn't thread > > > safe. I can make it thread safe by using pthread keys, but then i have to > > > link in libc_r, and for non-pthreaded programs i don't want to do that. > > > > > > Anyone have any suggestions? Right now I'm almost thinking that I just > > > need to directly patch libc and libc_r. It might be an ugly patch though, > > > and I'd rather not have this patch mandate recompiling all of libc. > > > > Where do you see mem* calling printf? > > Uh, nevermind. :) > > Ok, what you want to do is use a nested flag in memcpy so you > don't recurse, there's some code in libc that's conditionally > compiled when compiling libc_r, _THREAD_SAFE or something is > defined, once you find that then just simply use the global > for non threaded programs and keys for threaded ones. you mean like localtime.c: #ifdef _THREAD_SAFE pthread_mutex_lock(&lcl_mutex); #endif and such? problem is that i could do that if i was dropping it into libc itself, but as a single .so that i want to LD_PRELOAD, i need a run-time conditional rather than a precompiler conditional. i think i may be asking for a lot... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MT-Safe wrapper around memcpy()?
On Mon, 29 Oct 2001, Alfred Perlstein wrote: > * Lamont Granquist <[EMAIL PROTECTED]> [011029 00:43] wrote: > > I'm trying to figure out the best way to write a wrapper around memcpy() > > which can call fprintf() without winding up getting into a recursive > > loop. The problem is that fprintf() will call memcpy() and around and > > around we go. > > > > I can use a global variable to prevent this, but that usage isn't thread > > safe. I can make it thread safe by using pthread keys, but then i have to > > link in libc_r, and for non-pthreaded programs i don't want to do that. > > > > Anyone have any suggestions? Right now I'm almost thinking that I just > > need to directly patch libc and libc_r. It might be an ugly patch though, > > and I'd rather not have this patch mandate recompiling all of libc. > > Where do you see mem* calling printf? that's in my wrapper around memcpy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fiskars UPS
In message <[EMAIL PROTECTED]>, Andrzej Bialecki writes: >Poul-Henning Kamp wrote: >> >> In message <[EMAIL PROTECTED]>, "Julian Stacey [EMAIL PROTECTED] >> e" writes: >> >"doc. dr. Marjan Mihelin, dipl. ing." wrote: >> >> Hello, >> >> We are using from 1993 Fiskars UPS 0.8 A UPS unit >> >> Fiskars is part of Invensys/Powercom these days. > >Together with a co-worker we reverse-engineered the protocols for ca. 6 >different types of Fiskars UPSes - all of them used different packet >formats, even different speeds and parity (!). We couldn't get any docs >from them to help us, only a lousy Win* program... Keep that in mind the >next time you go shopping for a UPS. Yeah, you can't even trust their SNMP interface to get it right :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fiskars UPS
Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, "Julian Stacey [EMAIL PROTECTED] > e" writes: > >"doc. dr. Marjan Mihelin, dipl. ing." wrote: > >> Hello, > >> We are using from 1993 Fiskars UPS 0.8 A UPS unit > > Fiskars is part of Invensys/Powercom these days. Together with a co-worker we reverse-engineered the protocols for ca. 6 different types of Fiskars UPSes - all of them used different packet formats, even different speeds and parity (!). We couldn't get any docs from them to help us, only a lousy Win* program... Keep that in mind the next time you go shopping for a UPS. -- Andrzej // // Andrzej Bialecki <[EMAIL PROTECTED]>, Chief System Architect // WebGiro AB, Sweden (http://www.webgiro.com) // // <[EMAIL PROTECTED]> FreeBSD developer (http://www.freebsd.org) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Mon, Oct 29, 2001 at 05:58:22PM +1000, Greg Black wrote: > Here's a proposal to cope with that. Add an optional sub-field > to any action field in syslog.conf that begins with a slash, > perhaps in the form `:0640:root:wheel'. FWIW, we have a format like this in inetd.conf for unix domain sockets. You can prefix sockets with :user:group:mode:. If someone impliments something like this it would probably make sense to make then the same. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Simple x86 assembler question
On 29-Oct-01 David O'Brien wrote: > On Sun, Oct 28, 2001 at 09:21:33AM -0700, John Baldwin wrote: >> Almost. The '2' there is a multiplier on (I think) %eax, so it uses >> 'ebx + 2 * eax + 0xe90' for the memory address. Either that or 'eax + >> 2 * ebx + 0xe90'. Check the gas info page for the AT&T syntax to >> figure out exactly which. (Or use nasm's diassembler which turns out >> Intel format asm.) (ports/devel/nasm, ndisasm) > > BTW, Gas now supports Intel syntax. > > * doc/c-i386.texi (i386-Arch): New section. > (i386-Syntax): Mention .intel_syntax and .att_syntax. But does objdump -d? :) -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
