Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Tue, Dec 04, 2001 at 10:04:57PM +1100, Mark Hannon wrote:
Hi Chris,
This is exactly what I was seeing! (I finally twigged when I did a
low level backup of a filesystem and then noticed that my level 9
backup was the same length as the night before )
Thanks, Mark
Crist J . Clark wrote:
I did some more checking on how dump(8) works. If you dump to an
existing file, the file can never get smaller. That is, the file is
not truncated. I'll look at whether there is a good reason for this.
Is this actually what you were describing?
I don't really see a reason why dump(8) needs to work that way. Here
is an untested patch that should change that behavior.
Index: src/sbin/dump/tape.c
===
RCS file: /export/ncvs/src/sbin/dump/tape.c,v
retrieving revision 1.12.2.1
diff -u -r1.12.2.1 tape.c
--- src/sbin/dump/tape.c1 Aug 2001 06:29:35 - 1.12.2.1
+++ src/sbin/dump/tape.c4 Dec 2001 11:24:12 -
@@ -609,10 +609,10 @@
}
#ifdef RDUMP
while ((tapefd = (host ? rmtopen(tape, 2) :
- pipeout ? 1 : open(tape, O_WRONLY|O_CREAT, 0666))) 0)
+ pipeout ? 1 : open(tape, O_WRONLY | O_CREAT | O_TRUNC, 0666)))
+ 0)
#else
while ((tapefd = (pipeout ? 1 :
- open(tape, O_WRONLY|O_CREAT, 0666))) 0)
+ open(tape, O_WRONLY | O_CREAT| O_TRUNC, 0666))) 0)
#endif
{
msg(Cannot open output \%s\.\n, tape);
Is there any reason we don't want to truncate the file? Does O_TRUNC
not work well of the file is a tape device or something?
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: TCP Performance Graphs
On Fri, Nov 30, 2001 at 12:58:39PM -0500, Leo Bicknell wrote: Since the topic has come up again, I'll provide some graphs, and go back to my suggestion to see if it gets some traction this time around. http://www.ufp.org/~bicknell/fbsdtcp.png This graph shows the theoretical maximum performance of FreeBSD's TCP stack (assuming a network with ample free bandwidth, no router buffering, no dropped packets, etc). The red curve is with the existing (16k) window. I've used a scale of 0 to 100ms RTT, as I think that's the range you should find in the contentional US in the real world. Obviously higher values would be needed to make transoceanic hops, satellite hops, or other cases work. Question, what is RTT? The subject seems interesting but without the background... :) -- Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com FreeBSD Developer - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
MFC exlock+truncate bug^Wpatch
[ CC: [EMAIL PROTECTED] because of silence in -hackers ] Hello, Any chances to MFC these changes before 4.5? The bug is very annoying. | mckusick2000/07/03 20:34:11 PDT | | Modified files: |sys/dev/ccd ccd.c |sys/dev/vn vn.c |sys/kern kern_acct.c kern_ktrace.c kern_linker.c | kern_sig.c link_aout.c link_elf.c | vfs_syscalls.c vfs_vnops.c |sys/sys vnode.h |sys/ufs/ufs ufs_extattr.c ufs_quota.c | Log: | | Move the truncation code out of vn_open and into the open system | call after the acquisition of any advisory locks. This fix corrects | a case in which a process tries to open a file with a non-blocking | exclusive lock. Even if it fails to get the lock it would still | truncate the file even though its open failed. With this change, | the truncation is done only after the lock is successfully acquired. | | Obtained from: BSD/OS TIA, - -maxim -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Tue, Dec 04, 2001 at 03:35:38AM -0800, Crist J . Clark wrote:
On Tue, Dec 04, 2001 at 10:04:57PM +1100, Mark Hannon wrote:
Hi Chris,
This is exactly what I was seeing! (I finally twigged when I did a
low level backup of a filesystem and then noticed that my level 9
backup was the same length as the night before )
Thanks, Mark
Crist J . Clark wrote:
I did some more checking on how dump(8) works. If you dump to an
existing file, the file can never get smaller. That is, the file is
not truncated. I'll look at whether there is a good reason for this.
Is this actually what you were describing?
I don't really see a reason why dump(8) needs to work that way. Here
is an untested patch that should change that behavior.
Index: src/sbin/dump/tape.c
===
RCS file: /export/ncvs/src/sbin/dump/tape.c,v
retrieving revision 1.12.2.1
diff -u -r1.12.2.1 tape.c
--- src/sbin/dump/tape.c 1 Aug 2001 06:29:35 - 1.12.2.1
+++ src/sbin/dump/tape.c 4 Dec 2001 11:24:12 -
@@ -609,10 +609,10 @@
}
#ifdef RDUMP
while ((tapefd = (host ? rmtopen(tape, 2) :
- pipeout ? 1 : open(tape, O_WRONLY|O_CREAT, 0666))) 0)
+ pipeout ? 1 : open(tape, O_WRONLY | O_CREAT | O_TRUNC, 0666)))
0)
#else
while ((tapefd = (pipeout ? 1 :
- open(tape, O_WRONLY|O_CREAT, 0666))) 0)
+ open(tape, O_WRONLY | O_CREAT| O_TRUNC, 0666))) 0)
#endif
{
msg(Cannot open output \%s\.\n, tape);
Is there any reason we don't want to truncate the file? Does O_TRUNC
not work well of the file is a tape device or something?
I don't expect O_TRUNK to work on devices such tapes and disks.
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
block devices
Quick question, I was trolling around the FreeBSD kernel source and the dev directory and noticed there is no bdevsw structure and no block driver files. Is everything implemented in terms of character devices now? Looks like all the support for block devices is contained in the cdevsw struct. Thanks in advance! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
In message [EMAIL PROTECTED], Bernd Walter writes: Is there any reason we don't want to truncate the file? Does O_TRUNC not work well of the file is a tape device or something? I don't expect O_TRUNK to work on devices such tapes and disks. Well, it won't achieve anything on tapes or disk devices, but it should be completely harmless to add the O_TRUNC flag. The current behaviour is likely to be unexpected and cause confusion so it might as well be changed. I'll commit this later unless someone can think of a good reason not to. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
YPBIND fouling up portmapper under stable?
I updated my stable sources on Sunday and noticed that neither my NIS server (FreeBSD) or my FreeBSD NIS clients can run ypbind without causing portmap to wedge up. After ypbind is run, doing a rpcinfo -p on the local machine hangs, and any other attempt to register services with the portmapper fails. On the other hand, Linux NIS clients continue to be able to ypbind to the server with problems. Frustrating. Has anyone else seen this problem? Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: block devices
On Tue, Dec 04, 2001 at 08:08:34AM -0500, Dragon Fire wrote: I was trolling around the FreeBSD kernel source and the dev directory and noticed there is no bdevsw structure and no block driver files. Is everything implemented in terms of character devices now? Looks like all the support for block devices is contained in the cdevsw struct. Since no userland programs ever really had a good excuse for accessing block devices they have been retired from /dev. Block devices still exist, but are only accessable within the kernel. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
swap drives HighPoint HPT370
Does anyone know how to setup hot swap for this controller if you are using mirroring. atapci1: HighPoint HPT370 ATA100 controller port 0xc800-0xc8ff,0xc400-0xc403,0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb807 irq 10 at device 14.0 on pci0. I called up highpoint-tech and they didn't know about freebsd's ability to do this. Also does anyone know, if i power down, and switch one of the drives, if the controller will automatically update the other drive. I should probably call them up about this, but if anyone had any experience that would be good. Sorry about the bad english, i was in a rush -- Alex Newman [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
??: wctype.h
If you can provide sample code to verify the correctness of an implementation then i may be able to integrate it from netbsd. To my sorrow I don't know enough about wide-char. I need this functions for porting some programm. But if you send me a code I promise to find out about wide-char and test it. Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCP Performance Graphs
On Tue, Dec 04, 2001 at 12:48:45PM +0100, Nicolas Souchu wrote: Question, what is RTT? The subject seems interesting but without the background... :) Round Trip Time. The time it takes for a segment to travel to the destination, be processed, and an ack returned. -- 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: block devices
In message 005501c17cc4$c770d7a0$037d6041@gandalf, Dragon Fire writes: Quick question, I was trolling around the FreeBSD kernel source and the dev directory and noticed there is no bdevsw structure and no block driver files. Is everything implemented in terms of character devices now? Looks like all the support for block devices is contained in the cdevsw struct. quick answer: yes. :-) -- 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
random + large IRQ's + SMP
It appears there was a bug documented in http://lists.openresources.com/FreeBSD/freebsd-smp/msg00503.html where FreeBSD wouldn't allow IRQ's greater than 16, which SMP machines can have. I suddenly have several machines on 4.2-RELEASE showing this problem. What I need to know is when this was fixed (assuming it was). I tried to look through i386/i386/mem.c, per the messages to find the fix, but somewhere between when that message was posted and now random (and a few other things) were ripped out of there and scattered across several machine independant files. If someone knows when it was fixed, or could just point me to the right file to hunt in it would be a huge help. -- 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
Can TCP changes be put in RELENG_4?
I know that only security fixes are supposed to go in RELENG_4, but the recent changes in the TCP stuff seem important enough that perhaps they could be put in RELENG_4 for those of us who run productions servers on -RELEASE ? -- Jim Durham To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
I know that only security fixes are supposed to go in RELENG_4, but You mean RELENG_4_4 I assume. RELENG_4 gets a lot more than just security fixes. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
: :In message [EMAIL PROTECTED], Bernd Walter writes: : Is there any reason we don't want to truncate the file? Does O_TRUNC : not work well of the file is a tape device or something? : :I don't expect O_TRUNK to work on devices such tapes and disks. : :Well, it won't achieve anything on tapes or disk devices, but it :should be completely harmless to add the O_TRUNC flag. The current :behaviour is likely to be unexpected and cause confusion so it :might as well be changed. I'll commit this later unless someone :can think of a good reason not to. : :Ian Woa! That sounds like a bad idea to me. If you want to do it right then open(), fstat(), and only if the stat says it is a regular file do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored by us, but it's not a valid flag to pass to a tape device and we shouldn't do it. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCPIP cksum offload on FreeBSD 4.2
Hi, I'm using the Netgear GA620 Gig ethernet NIC with Tigon II chip. Do you know if it is possible to increase the buffer size for standard sized ethernet frames from 512 buffers to say, 1024? I assume I'd have to modify the firmware and the host driver to accomodate these buffers. I dont plan to use Jumbo frames at all, and I can reduce the buffers allocated for them if necessary. Thanks, -Srinivas From: [EMAIL PROTECTED] (Bill Paul) To: [EMAIL PROTECTED] (Kenneth D. Merry) CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: TCPIP cksum offload on FreeBSD 4.2 Date: Sat, 29 Sep 2001 17:02:58 -0700 (PDT) On the other hand, the Tigon III is capable of 960 megabits -- about the wire rate limit -- with normal size packets, if you implement software interrupt coelescing (which doesn't help, unless you crank the load up to close to wire speed and/or do more of the stack processing at interrupt time). I've been able to get 906Mbps between two Dell PowerEdge 2550 servers with built-in BCM5700/Tigon III chipsets with a stock FreeBSD kernel and the bge driver. Having downloadable firmware is actually a huge advantage. You can do things with the Tigon II that just aren't possible with any other chip, either because they don't have downloadable firmware, or because the vendor won't release firmware source. This is a problem with the Broadcom Tigon III boards, and to some extent with the Tigon II. Basically it looks like the firmware for the Tigon II is very hard to get now that 3Com has control of it, and I don't think Broadcom will release the Tigon III firmware. (Assuming it is a firmware-based chip.) I still have a copy of the last release of the Tigon II firmware and the development environment (which is what I used to generate the firmware image included with FreeBSD). As for the Tigon III, there is a default firmware image included in the EEPROM on the card, which is auto-loaded when the chip powers up. It is possible for a driver to load a custom image into the NIC's memory which will override the auto-loaded one, and it's also possible to load a new image into the EEPROM, however this requires an additional manual on top of the BCM5700 driver developer's guide as well as the firmware development kit, which you can only get from Broadcom/3Com/whatever under NDA. These custom images are called value-add firmware which are used to provide features like TCP segmentation, which you can't do with the default firmware image. Note that the BCM5700/Tigon III only has a limited amount of on-board RAM (256KB, I think). You're supposed to be able to attach up to 16MB of static SRAM to the BCM5700. The BCM5701 doesn't support external SSRAM at all, which I find a little confusing. -Bill _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
Matthew Dillon wrote: | :In message [EMAIL PROTECTED], Bernd Walter writes: | : Is there any reason we don't want to truncate the file? Does O_TRUNC | : not work well of the file is a tape device or something? | : | :I don't expect O_TRUNK to work on devices such tapes and disks. | : | :Well, it won't achieve anything on tapes or disk devices, but it | :should be completely harmless to add the O_TRUNC flag. The current | :behaviour is likely to be unexpected and cause confusion so it | :might as well be changed. I'll commit this later unless someone | :can think of a good reason not to. | : | :Ian | | Woa! That sounds like a bad idea to me. If you want to do it right | then open(), fstat(), and only if the stat says it is a regular file | do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored | by us, but it's not a valid flag to pass to a tape device and we shouldn't | do it. I haven't used any of them for a while, but there are certainly Unix systems that treat O_TRUNC as a signal to rewind a tape device before writing to it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Tuesday 04 December 2001 12:17 pm, Jordan Hubbard wrote: I know that only security fixes are supposed to go in RELENG_4, but You mean RELENG_4_4 I assume. RELENG_4 gets a lot more than just security fixes. - Jordan Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my question... Can we have the patches in REGENG_4_4?. I put them in by hand and they looked like they were OK, but I haven't compiled a kernel yet. -Jim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
In message [EMAIL PROTECTED], Matthew Dillon wri tes: Woa! That sounds like a bad idea to me. If you want to do it right then open(), fstat(), and only if the stat says it is a regular file do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored by us, but it's not a valid flag to pass to a tape device and we shouldn't do it. Yeah, I guess checking the file type first makes more sense. I tend to use shell `' redirects a lot when accessing tape devices. They unconditionally add O_TRUNC, so I know I'd be very surprised if there were side-effects! However for dump I agree that it's best not to make such assumptions. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Tuesday 04 December 2001 03:40 pm, Jim Durham wrote: On Tuesday 04 December 2001 12:17 pm, Jordan Hubbard wrote: I know that only security fixes are supposed to go in RELENG_4, but You mean RELENG_4_4 I assume. RELENG_4 gets a lot more than just security fixes. - Jordan Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my question... Can we have the patches in REGENG_4_4?. I put them in by hand and they looked like they were OK, but I haven't compiled a kernel yet. -Jim OK... ONE MORE TIME 8-) RELENG_4_4 not REGENG as above... sigh.. (I'm going over in the corner now) -Jim -- Jim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Instant Success-Increased Sales leads guaranteed...
Proven Sales Formula! Successfull entrepreneurs around the world use our products. Is your website tired/run down? Need a Health check for your dot com? Not sure about commitment? Get a free health check At Trafficwow.net. Not only do we help you make a Success of building your profit. We tell you the Web secret that is making your competitor more money than you. Want to know more http://www.trafficwow.net/healthcheck Trafficwow makes web sites burst with targeted sales traffic. Just order your package and we do the rest. Guarenteed traffic or your money back. We have sent over 63 Million people to sites like your this month alone. Want to know more http://www.trafficwow.net/faq_wow.htm ~~~ Want to Buy? Simply visit http://www.trafficwow.net ~~~ Become a Winner with http://www.Trafficwow.net ~ Free Web Site Health Check with every package! Trafficwow will asses your web site and forward you an advice report. Be warned!! If it is no good. WE WILL TELL YOU!! Visit http://www.Trafficwow.net *** We Are Fully Compliant to Senate bill1618,Title 3, section 301. http://www.senate.gov/~murkowski/commercialmail/S771index.html This message is sent in compliance of the new e-mail bill: Section 301.per section 301, paragraph (a)(2)(c) of S 1618. http://www.senate.gov/#murkowshki/commerciale-mail?s77index.html Further Transmission to you by the sender of this e-mail may be stopped at no cost to you by sending a reply e-mail it to [EMAIL PROTECTED] with the word REMOVE in the subject line. *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
FreeBSD might not have been slower that Linux in the real world ...
Hi, As you might have seen, there was a problem in the FreeBSD code that Matt Dillon fixed recently. This problem involved the flag TCP_NODELAY not being propogated across an accept() call. This resulted in tbench runs turning in very poor performance under FreeBSD compared with Linux. However, in the real world, ie in Samba, this might not have been a problem at all. I believe, but will not be able to check for a little while now, that Samba was doing the setsockopt() call after the accept() call, and indeed, after the fork() call when a new smbd is fork'd to handle the new connection. Since TCP_NODELAY is the default, Samba under FreeBSD was probably always getting the benefit of that 68Mb/s that it seems possible to get using the SMB protocol on a 100Mb/s link. However, it is good that FreeBSD also gets good numbers under the benchmarks. -- Richard Sharpe, [EMAIL PROTECTED], LPIC-1 www.samba.org, www.ethereal.com, SAMS Teach Yourself Samba in 24 Hours, Special Edition, Using Samba To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: block devices
David Malone wrote: On Tue, Dec 04, 2001 at 08:08:34AM -0500, Dragon Fire wrote: I was trolling around the FreeBSD kernel source and the dev directory and noticed there is no bdevsw structure and no block driver files. Is everything implemented in terms of character devices now? Looks like all the support for block devices is contained in the cdevsw struct. Since no userland programs ever really had a good excuse for accessing block devices they have been retired from /dev. Block devices still exist, but are only accessable within the kernel. Actually, I found a third reason for block devices (apart from the Apple UDF FS and disk initialization) the other day: to permit reading of QIC-11 and QIC-24 tapes produeces on NCR Tower-XP, NCR Tower-32, and Sun-3 equipment. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection
On Mon, Dec 03, 2001 at 09:48:19PM -0500, James Housley wrote: : Greg Lane wrote: : I have a problem with PPPoE over Telstra ADSL (Australia). A full : description of the problem can be found in freebsd-questions : (see [EMAIL PROTECTED] dated Nov 30) : with the subject: : I can reliably make my DSL connection work on three different machines : using four different network cards (ed, de, vr, rl) with source dated : Jul 30 12:01am, and reliably break it with anything after : Jul 31 12:01am. : : I had a similar problem, but haven't been able to fully track it down. I did file a :PR http://www.freebsd.org/cgi/query-pr.cgi?pr=32040 . A LCP log of both versions was : requested. Also if you read the new man page there is set mtu max x and set mru :max x options, the I might have mistyped when I tried. Hmm. I run Telstra ADSL on my 386sx with 4.4-STABLE and an SMC8013 Ethernet. My /etc/ppp/ppp.conf is as follows (cut and paste), with stuff editted for sanity, and dialup things removed: | default: | set server stuff | nat enable yes | nat same_ports yes | nat use_sockets yes | nat port tcp stuff | nat port udp stuff | | bigpond: | # unit 0 | set device PPPoE:ed1 | set ifaddr 144.137.110.0/0 172.31.18.24/0 255.255.255.0 0.0.0.0 | set authname stuff@bigpond | set authkey stuff | set mtu 1492 | set mru 1492 | set dial | set login | set log Phase Chat Connect tun command LQM | enable lqr My ppp was most recently compiled about a week ago, and my kernel on Monday. -- Christopher Vance To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum ofdumped files
While on the topic of 'dump', note that there's also the patch in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/32414 which fixes a problem where dump will include information that should not be included (due to the nodump flag being set). This too would result in dump files larger than they should be... The PR includes a patch which is meant to fix this problem. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
marking disks
I'm building a cluster where the nodes will boot using PXE, but they have disks on them which will be used for things like scratch space, swap, crash dumps, etc. Once of the issues I'm facing is that I'd like to be able to detect if the disks have been partioned to the latest standard on boot and rebuild them if they haven't. I'd like this to be able to work with Linux if necessicary, but for now the systems will run FreeBSD. What I'd been thinking was that I could write a magic string over the beginning of the MBR since I'm never going to try and boot these disks. That would let me detect uninitalized drives as well as out of date partitioning schemes. Are there any problems to look out for with this solution? Does anyone know of a better one? Thanks, Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg29573/pgp0.pgp Description: PGP signature
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Tue, Dec 04, 2001 at 07:37:04PM -0500, Garance A Drosihn wrote: While on the topic of 'dump', note that there's also the patch in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/32414 which fixes a problem where dump will include information that should not be included (due to the nodump flag being set). This too would result in dump files larger than they should be... The PR includes a patch which is meant to fix this problem. Yeah, I've been looking at these two together. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
offtopic: assembly
Hi, i am freebsd user since 3.1-release, I am reading Peter Abel book about assembly and i have the following doubt: I want to understand Why each byte (8 bit of data and 1 bit of parity) has one bit of parity? What is parity for? Why the processor needs to know if certain byte in memory is par or impar (i dont know how to say it in english..). Please, give me a *wide* explaination, that's the part of the book i dont get it. The memory is divided in 'bytes', each one with an address starting, right?, so, when an instruction needs to check a byte, the processor looks its parity, right? If so, What for? why? what is the idea? what makes the difference from 'par' to 'no par'?, usually, why an instruction needs to check a byte? What part of the program do the requested byte belongs (Code, data, stack)? Thank you very much. p.s. Anyone know a site like linux's www.linuxassembly.org? I want to know the freebsd developer's resources on web ( i am not lucky to buy books online and my bookstores arent unix-focused:)), i want to understand freebsd internals! __ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: TCPIP cksum offload on FreeBSD 4.2
Hi, I'm using the Netgear GA620 Gig ethernet NIC with Tigon II chip. Do you know if it is possible to increase the buffer size for standard sized ethernet frames from 512 buffers to say, 1024? I assume I'd have to modify the firmware and the host driver to accomodate these buffers. I dont plan to use Jumbo frames at all, and I can reduce the buffers allocated for them if necessary. You would need to change the firmware in order to increase the size of any of the RX rings. All of the Tigon II manuals and a snapshot of my firmware development tree is at the following URL: http://www.freebsd.org/~wpaul/Alteon Note that I'm not sure how this will affect the layout of data structures in the NIC's on-board SRAM. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SMB driver for 4.2 SMP kernel (healthd, lmmon, etc.)
Hi, I'm not able to work the SMB driver (used by healthd, lmmon, etc.) on an Intel x86 FreeBSD 4.2 SMP system for getting system statistics such as the CPU temps, voltages, fan rpm's etc. With a FreeBSD 4.2 single cpu kernel, all of these utilities work fine using the underlying SMB driver (/dev/smb0 device). However, with an SMP kernel I get a device not configured error message when doing ioctl on this device. To reproduce the problem compile and run the findSMB.c code by itself in the healthd package. Does anyone know how to fix this problem with using SMB driver on an SMP kernel? Thanks, -Srinivas _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Wed, Dec 05, 2001 at 06:02:49AM +1000, Greg Black wrote: Matthew Dillon wrote: | :In message [EMAIL PROTECTED], Bernd Walter writes: | : Is there any reason we don't want to truncate the file? Does O_TRUNC | : not work well of the file is a tape device or something? | : | :I don't expect O_TRUNK to work on devices such tapes and disks. | : | :Well, it won't achieve anything on tapes or disk devices, but it | :should be completely harmless to add the O_TRUNC flag. The current | :behaviour is likely to be unexpected and cause confusion so it | :might as well be changed. I'll commit this later unless someone | :can think of a good reason not to. | : | :Ian | | Woa! That sounds like a bad idea to me. If you want to do it right | then open(), fstat(), and only if the stat says it is a regular file | do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored | by us, but it's not a valid flag to pass to a tape device and we shouldn't | do it. I haven't used any of them for a while, but there are certainly Unix systems that treat O_TRUNC as a signal to rewind a tape device before writing to it. So? Who cares? This is FreeBSD's dump(8) and FreeBSD's write(2). There is no reason to worry about portability of FreeBSD's dump(8) in how write(2) flags work. If our write(2) does the right thing with O_TRUNC and tape devices, there is no reason not to let it do the right thing on its own. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
Crist J . Clark wrote: | On Wed, Dec 05, 2001 at 06:02:49AM +1000, Greg Black wrote: | Matthew Dillon wrote: | | | :In message [EMAIL PROTECTED], Bernd Walter writes: | | : Is there any reason we don't want to truncate the file? Does O_TRUNC | | : not work well of the file is a tape device or something? | | : | | :I don't expect O_TRUNK to work on devices such tapes and disks. | | : | | :Well, it won't achieve anything on tapes or disk devices, but it | | :should be completely harmless to add the O_TRUNC flag. The current | | :behaviour is likely to be unexpected and cause confusion so it | | :might as well be changed. I'll commit this later unless someone | | :can think of a good reason not to. | | : | | :Ian | | | | Woa! That sounds like a bad idea to me. If you want to do it right | | then open(), fstat(), and only if the stat says it is a regular file | | do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored | | by us, but it's not a valid flag to pass to a tape device and we shouldn't | | do it. | | I haven't used any of them for a while, but there are certainly | Unix systems that treat O_TRUNC as a signal to rewind a tape | device before writing to it. | | So? Who cares? This is FreeBSD's dump(8) and FreeBSD's write(2). There | is no reason to worry about portability of FreeBSD's dump(8) in how | write(2) flags work. If our write(2) does the right thing with | O_TRUNC and tape devices, there is no reason not to let it do the | right thing on its own. That's a rather strange attitude. All I was suggesting that, from the once-respected POLA, it would be less surprising to people who might have experience of other systems if FreeBSD did not make its own arrangements without some good reason. There's no need for responses like: So? Who cares? -- if there's some reason not to consider other people, by all means explain it; but be polite while you're at it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Wed, Dec 05, 2001 at 05:10:49PM +1000, Greg Black wrote: Crist J . Clark wrote: | On Wed, Dec 05, 2001 at 06:02:49AM +1000, Greg Black wrote: | Matthew Dillon wrote: | | | :In message [EMAIL PROTECTED], Bernd Walter writes: | | : Is there any reason we don't want to truncate the file? Does O_TRUNC | | : not work well of the file is a tape device or something? | | : | | :I don't expect O_TRUNK to work on devices such tapes and disks. | | : | | :Well, it won't achieve anything on tapes or disk devices, but it | | :should be completely harmless to add the O_TRUNC flag. The current | | :behaviour is likely to be unexpected and cause confusion so it | | :might as well be changed. I'll commit this later unless someone | | :can think of a good reason not to. | | : | | :Ian | | | | Woa! That sounds like a bad idea to me. If you want to do it right | | then open(), fstat(), and only if the stat says it is a regular file | | do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored | | by us, but it's not a valid flag to pass to a tape device and we shouldn't | | do it. | | I haven't used any of them for a while, but there are certainly | Unix systems that treat O_TRUNC as a signal to rewind a tape | device before writing to it. | | So? Who cares? This is FreeBSD's dump(8) and FreeBSD's write(2). There | is no reason to worry about portability of FreeBSD's dump(8) in how | write(2) flags work. If our write(2) does the right thing with | O_TRUNC and tape devices, there is no reason not to let it do the | right thing on its own. That's a rather strange attitude. All I was suggesting that, from the once-respected POLA, it would be less surprising to people who might have experience of other systems if FreeBSD did not make its own arrangements without some good reason. From what Ian said elsewhere in this thread, the O_TRUNC already does not act strange on a tape device. I don't see any new POLA issues if adding O_TRUNC to the write call doesn't change how dump(8) has been working on tapes for FreeBSD for these n years now. The only POLA issue I see is the current behavior that regular files are _not_ truncated, which was the start of the thread and the issue in the PR. There's no need for responses like: So? Who cares? -- if there's some reason not to consider other people, by all means explain it; but be polite while you're at it. I don't see who would care if FreeBSD's dump(8) might have some funny reactions on UNIX-like systems where O_TRUNC has a different behavior on tape devices. I don't think the Project is overly concerned about porting FreeBSD's dump(8) to other OSes. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Possible libc_r pthread bug
Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [011130 16:17] wrote: On Fri, 30 Nov 2001, Louis-Philippe Gagnon wrote: If at first you don't succeed... I've encountered a problem using pthread_cancel, pthread_join and pthread_setcanceltype, I'm hoping someone can shed some light. (in a nutshell : pthread_setcanceltype doesn't seem to work in FreeBSD 4.4) (posted to -current and -hackers; if there's a more appropriate mailing list for this, please let me know) I recently encountered a situation where, after calling pthread_cancel to cancel a thread, the call to pthread_join hangs indefinitely. I quickly figured out that it was because the thread being cancelled was never reaching a cancellation point (in fact it was an infinite loop with no function calls at all). Sure enough, adding a pthread_testcancel() in the loop allowed pthread_join to return. However this solution isn't acceptable for my requirements. please test the following patch: There are already cancellation tests when resuming threads whose contexts are not saved as a result of a signal interrupt (ctxtype != CTX_UC). You shouldn't test for cancellation when ctxtype == CTX_UC because you are running on the scheduler stack, not the threads stack. You also have a bug in the way you changed the check for cancellation flags. There only clean way to fix this is to add a return frame to the interrupted context so that it can check for cancellation (and other things) before returning to the threads interrupted context. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Possible libc_r pthread bug
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote: There are already cancellation tests when resuming threads whose contexts are not saved as a result of a signal interrupt (ctxtype != CTX_UC). You shouldn't test for cancellation when ctxtype == CTX_UC because you are running on the scheduler stack, not the threads stack. That makes sense, but why? You also have a bug in the way you changed the check for cancellation flags. What? There only clean way to fix this is to add a return frame to the interrupted context so that it can check for cancellation (and other things) before returning to the threads interrupted context. No way to work around this? Shouldn't the thread exit library know which stack exactly to clean up even in the context of a signal handler? -- -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: Possible libc_r pthread bug
* Alfred Perlstein [EMAIL PROTECTED] [011204 11:45] wrote:
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote:
There are already cancellation tests when resuming threads
whose contexts are not saved as a result of a signal interrupt
(ctxtype != CTX_UC). You shouldn't test for cancellation when
ctxtype == CTX_UC because you are running on the scheduler
stack, not the threads stack.
That makes sense, but why?
You also have a bug in the
way you changed the check for cancellation flags.
What?
There only clean way to fix this is to add a return frame
to the interrupted context so that it can check for cancellation
(and other things) before returning to the threads interrupted
context.
No way to work around this? Shouldn't the thread exit library
know which stack exactly to clean up even in the context of a
signal handler?
Are you sure this is 100% needed?
Here's a recap of that patch, are you saying that the problem
is that the thread will use the current sp if it exits rather
than some value stashed away in the private pthread struct?
Also, I think my tests for cancellation are correct. Although
I sort of think the PTHREAD_AT_CANCEL_POINT test should be
removed because the code will catch this when it leaves the
cancellation point.
Index: uthread_kern.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.39
diff -u -r1.39 uthread_kern.c
--- uthread_kern.c 7 Oct 2001 02:34:43 - 1.39
+++ uthread_kern.c 4 Dec 2001 17:58:31 -
@@ -180,7 +180,7 @@
struct pthread *curthread = _get_curthread();
pthread_t pthread, pthread_h;
unsigned intcurrent_tick;
- int add_to_prioq;
+ int add_to_prioq, cfl;
/* If the currently running thread is a user thread, save it: */
if ((curthread-flags PTHREAD_FLAGS_PRIVATE) == 0)
@@ -604,6 +604,15 @@
*/
_thread_kern_in_sched = 0;
+ /*
+* test for async cancel:
+*/
+ cfl = curthread-cancelflags;
+
+ cfl = (PTHREAD_CANCEL_ASYNCHRONOUS|
+ PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
+ pthread_testcancel();
#if NOT_YET
_setcontext(curthread-ctx.uc);
#else
@@ -1078,6 +1087,8 @@
curthread-sig_defer_count--;
}
else if (curthread-sig_defer_count == 1) {
+ int cfl;
+
/* Reenable signals: */
curthread-sig_defer_count = 0;
@@ -1091,8 +1102,9 @@
* Check for asynchronous cancellation before delivering any
* pending signals:
*/
- if (((curthread-cancelflags PTHREAD_AT_CANCEL_POINT) == 0)
- ((curthread-cancelflags PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
+ cfl = curthread-cancelflags;
+ cfl = (PTHREAD_CANCEL_ASYNCHRONOUS|PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
pthread_testcancel();
/*
--
-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: Possible libc_r pthread bug
Alfred Perlstein wrote: * Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote: There are already cancellation tests when resuming threads whose contexts are not saved as a result of a signal interrupt (ctxtype != CTX_UC). You shouldn't test for cancellation when ctxtype == CTX_UC because you are running on the scheduler stack, not the threads stack. That makes sense, but why? Because when a thread gets cancelled, pthread_exit gets called which then calls the scheduler again. It is also possible to get interrupted during this process and the threads context (which is operating on the scheduler stack) could get saved. The scheduler could get entered again, and if the thread gets resumed, it'll longjmp to the saved context which is the scheduler stack (and which was just trashed by entering the scheduler again). It is too confusing to try to handle conditions like this, and the threads library doesn't need to get any more confusing ;-) Once the scheduler is entered, no pthread routines should be called and the scheduler should not be recursively entered. The only way out of the scheduler should be a longjmp or sigreturn to a saved threads context. You also have a bug in the way you changed the check for cancellation flags. What? When a thread is at a cancellation point, you want to let the cancellable routine handle the cancel. The check as coded before avoided calling pthread_testcancel() when at a cancellation point. I think you check for either PTHREAD_AT_CANCEL_POINT or PTHREAD_CANCEL_ASYNCHRONOUS being set when you really want ((flags PTHREAD_AT_CANCEL_POINT) == 0) ((flags PTHREAD_CANCEL_ASYNCHRONOUS) != 0)) There only clean way to fix this is to add a return frame to the interrupted context so that it can check for cancellation (and other things) before returning to the threads interrupted context. No way to work around this? Shouldn't the thread exit library know which stack exactly to clean up even in the context of a signal handler? It assumes that you're running on the current threads stack. I don't view this particular bug as a big problem. It is a somewhat perverse program that has a CPU bound thread that never gets to any sort of blocking condition and yet still wants to be cancelled. The submitter of the problem doesn't even want to upgrade to get a fix. It can be worked around easily enough by checking for cancellation or by using pthread_kill to send a signal to the thread and have the signal handler exit the thread or longjmp back to the thread at a place that can exit and cleanup. There is already a minor race condition in trying to resume a thread that was interrupted by a signal. Adding some code to munge the stack of an interrupted context so that it calls a wrapper function would solve both problems. The signal handling code already does this to install a signal handler wrapper on a threads stack. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Possible libc_r pthread bug
* Daniel Eischen [EMAIL PROTECTED] [011204 12:32] wrote:
Alfred Perlstein wrote:
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote:
There are already cancellation tests when resuming threads
whose contexts are not saved as a result of a signal interrupt
(ctxtype != CTX_UC). You shouldn't test for cancellation when
ctxtype == CTX_UC because you are running on the scheduler
stack, not the threads stack.
That makes sense, but why?
Because when a thread gets cancelled, pthread_exit gets called
which then calls the scheduler again. It is also possible to
get interrupted during this process and the threads context
(which is operating on the scheduler stack) could get saved.
The scheduler could get entered again, and if the thread
gets resumed, it'll longjmp to the saved context which is the
scheduler stack (and which was just trashed by entering the
scheduler again).
It is too confusing to try to handle conditions like this, and
the threads library doesn't need to get any more confusing ;-)
Once the scheduler is entered, no pthread routines should
be called and the scheduler should not be recursively
entered. The only way out of the scheduler should be a
longjmp or sigreturn to a saved threads context.
Ok, for the sake of beating a clue into me...
in uthread_kern.c:_thread_kern_sched
/* Save the state of the current thread: */
if (_setjmp(curthread-ctx.jb) == 0) {
/* Flag the jump buffer was the last state saved: */
curthread-ctxtype = CTX_JB_NOSIG;
curthread-longjmp_val = 1;
} else {
DBG_MSG(Returned from ___longjmp, thread %p\n,
curthread);
/*
* This point is reached when a longjmp() is called
* to restore the state of a thread.
*
* This is the normal way out of the scheduler.
*/
_thread_kern_in_sched = 0;
if (curthread-sig_defer_count == 0) {
if (((curthread-cancelflags
PTHREAD_AT_CANCEL_POINT) == 0)
((curthread-cancelflags
PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
/*
* Cancellations override signals.
*
* Stick a cancellation point at the
* start of each async-cancellable
* thread's resumption.
*
* We allow threads woken at cancel
* points to do their own checks.
*/
pthread_testcancel();
}
Why isn't this working, shouldn't it be doing the right thing?
What if curthread-sig_defer_count wasn't tested?
Maybe this should be a test against curthread-sig_defer_count = 1?
I'll play with this some more when I get back to my box at home,
it just seems bizarro to me.
--
-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: Possible libc_r pthread bug
Alfred Perlstein wrote:
* Daniel Eischen [EMAIL PROTECTED] [011204 12:32] wrote:
Alfred Perlstein wrote:
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote:
There are already cancellation tests when resuming threads
whose contexts are not saved as a result of a signal interrupt
(ctxtype != CTX_UC). You shouldn't test for cancellation when
ctxtype == CTX_UC because you are running on the scheduler
stack, not the threads stack.
That makes sense, but why?
Because when a thread gets cancelled, pthread_exit gets called
which then calls the scheduler again. It is also possible to
get interrupted during this process and the threads context
(which is operating on the scheduler stack) could get saved.
The scheduler could get entered again, and if the thread
gets resumed, it'll longjmp to the saved context which is the
scheduler stack (and which was just trashed by entering the
scheduler again).
It is too confusing to try to handle conditions like this, and
the threads library doesn't need to get any more confusing ;-)
Once the scheduler is entered, no pthread routines should
be called and the scheduler should not be recursively
entered. The only way out of the scheduler should be a
longjmp or sigreturn to a saved threads context.
Ok, for the sake of beating a clue into me...
in uthread_kern.c:_thread_kern_sched
/* Save the state of the current thread: */
if (_setjmp(curthread-ctx.jb) == 0) {
/* Flag the jump buffer was the last state saved: */
curthread-ctxtype = CTX_JB_NOSIG;
curthread-longjmp_val = 1;
} else {
DBG_MSG(Returned from ___longjmp, thread %p\n,
curthread);
/*
* This point is reached when a longjmp() is called
* to restore the state of a thread.
*
* This is the normal way out of the scheduler.
*/
_thread_kern_in_sched = 0;
if (curthread-sig_defer_count == 0) {
if (((curthread-cancelflags
PTHREAD_AT_CANCEL_POINT) == 0)
((curthread-cancelflags
PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
/*
* Cancellations override signals.
*
* Stick a cancellation point at the
* start of each async-cancellable
* thread's resumption.
*
* We allow threads woken at cancel
* points to do their own checks.
*/
pthread_testcancel();
}
Why isn't this working, shouldn't it be doing the right thing?
What if curthread-sig_defer_count wasn't tested?
Maybe this should be a test against curthread-sig_defer_count = 1?
Because this is the normal way into the scheduler -- when a thread
hits a blocking condition or yields. A signal interrupting a thread
does not go through this section. The interrupted threads context is
argument 3 of the signal handler, and this context gets stored in
curthread-ctx.uc. This is the crux of the problem. When you resume
this context, you are not in the thread scheduling code and so you
can't check for cancellation. I'm suggesting that the proper way
to handle this is to munge this interrupted context (a ucontext_t)
so that it first returns to a small wrapper function that can
check for cancellation (and clear the in scheduler flag which
is the other problem I mentioned) before returning to the interrupted
context.
There is another way to handle this, but it is more complicated
although probably better than the above method. This would involve
changing the signal handling code to not use an alternate signal
stack, so an interrupted thread could do something like:
void
sighandler(int sig, siginfo_t *info, ucontext_t *ucp)
{
...
{
ucontext_t uc;
/* Save interrupted context on stack: */
uc = *ucp;
uc.uc_sigmask = _process_sigmask;
/* Enter the scheduler: */
_thread_kern_sched(NULL);
/*
* After return from the scheduler, the
* in scheduler flag
Re: Possible libc_r pthread bug
* Daniel Eischen [EMAIL PROTECTED] [011130 16:17] wrote:
On Fri, 30 Nov 2001, Louis-Philippe Gagnon wrote:
If at first you don't succeed...
I've encountered a problem using pthread_cancel, pthread_join and
pthread_setcanceltype, I'm hoping someone can shed some light.
(in a nutshell : pthread_setcanceltype doesn't seem to work in FreeBSD 4.4)
(posted to -current and -hackers; if there's a more appropriate mailing list
for this, please let me know)
I recently encountered a situation where, after calling pthread_cancel to
cancel a thread, the call to pthread_join hangs indefinitely. I quickly figured
out that it was because the thread being cancelled was never reaching a
cancellation point (in fact it was an infinite loop with no function calls at
all).
Sure enough, adding a pthread_testcancel() in the loop allowed
pthread_join to return. However this solution isn't acceptable for my requirements.
please test the following patch:
Index: uthread/uthread_kern.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.39
diff -u -r1.39 uthread_kern.c
--- uthread/uthread_kern.c 7 Oct 2001 02:34:43 - 1.39
+++ uthread/uthread_kern.c 4 Dec 2001 08:22:22 -
@@ -579,6 +579,18 @@
curthread);
}
/*
+* If the currently running thread is a user thread,
+* test for async cancel:
+*/
+ if ((curthread-flags PTHREAD_FLAGS_PRIVATE) == 0) {
+ int cfl = curthread-cancelflags;
+
+ cfl = (PTHREAD_CANCEL_ASYNCHRONOUS|
+ PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
+ pthread_testcancel();
+ }
+ /*
* Continue the thread at its current frame:
*/
switch(curthread-ctxtype) {
@@ -1078,6 +1090,8 @@
curthread-sig_defer_count--;
}
else if (curthread-sig_defer_count == 1) {
+ int cfl;
+
/* Reenable signals: */
curthread-sig_defer_count = 0;
@@ -1091,8 +1105,9 @@
* Check for asynchronous cancellation before delivering any
* pending signals:
*/
- if (((curthread-cancelflags PTHREAD_AT_CANCEL_POINT) == 0)
- ((curthread-cancelflags PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
+ cfl = curthread-cancelflags;
+ cfl = (PTHREAD_CANCEL_ASYNCHRONOUS|PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
pthread_testcancel();
/*
--
-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
