Re: natd core dumping with bus error
On Thu, Jul 04, 2002 at 09:20:38AM -0500, Richard Seaman, Jr. wrote: > On Tue, Jul 02, 2002 at 06:04:36PM -0700, Joel M. Baldwin wrote: > > > > > > Something has messed up natd. If I don't have the > > punch_fw option in the /etc/natd.conf file it eventuially > > core dumps with a bus error. I think this started JUST > > BEFORE the KSE commit. > > Yes, I've seen the same thing on a pre-KSE kernel. The error > occurs in PunchFWHole in alias_db.c in libalias. Reverting > the following commit seems to fix it (I haven't had a chance > to investigate further): > > luigi 2002/06/27 16:02:18 PDT > > Modified files: > sbin/ipfwMakefile > sys/netinet ip_dummynet.c ip_fw.h > sys/conf files > lib/libalias alias_db.c > Added files: > sbin/ipfwipfw2.c > sys/netinet ip_fw2.c > Log: > The new ipfw code. I upgraded my pre-KSE kernel and system to the latest versions of these files, and recompiled natd, ipfw, libalias, and the kernel. natd is now stable. The firewall rules appear to be working correctly as well (I started temporarily logging most packets, and the log files show that the packets are accepted/denied as indicated by the rules I gave it). -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: natd core dumping with bus error
On Mon, Jul 08, 2002 at 09:07:39AM -0700, Joel M. Baldwin wrote: > > I'll have to ditto that. > > no ppp, just natd, and sysctl stuff is set as listed below. > > Without the punch-fw directive in /etc/natd.conf, natd will core dump. > I just verified that without the directive it core dumps. The problem > still exits. It isn't an instant dump, it runs for a while. Right. Typically 30secs - 5 mins before it dumped. And when I ran natd in verbose mode, it showed quite a few packets in and out before it dumped. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: natd core dumping with bus error
On Mon, Jul 08, 2002 at 07:08:58AM -0700, David Xu wrote: > you have turned on "nat enable yes" in ppp.conf, > and but you havn't turned ip_foward on in sysctl, > so core dumped. > > David Xu Well, I'm not running ppp, and never indicated I was. I'm running natd. # sysctl -a | grep forward net.inet.ip.forwarding: 1 net.inet.ip.fastforwarding: 0 net.inet6.ip6.forwarding: 0 Everything works fine with pre "new-ipfw", and has for years. Same rules, same configuration, and with "new ipfw", core dump. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: natd core dumping with bus error
On Mon, Jul 08, 2002 at 02:26:10AM -0700, Luigi Rizzo wrote: > Could you clarify the problem ? > I believe the problem appears when you _do_ use punch_fw, > otherwise the modified code is never called. > > cheers > luigi I did not have punch_fw enabled when I encountered the problem. I created a debug version of natd (but not libalias) and saw that the bus error was in PunchFWHole. Since I didn't have a debug version of libalias, I can't tell you what line. Perhaps PunchFWHole is being called when its not supposed to be, with bad values? -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with natd, ipfw
On Sun, Jul 07, 2002 at 04:45:52PM -0500, Richard Seaman, Jr. wrote: > On Sun, Jul 07, 2002 at 11:35:46PM +0200, Szilveszter Adam wrote: > > Hello everybody, > > > > I upgraded to yesterday's -CURRENT and have made a few observations: > > > 2) and much more alarmingly: Although the new ipfw really seems to > > process the ruleset faster, some rules appear to do nothing! I > > have a "default-to-deny" setup, so theoretically this should mean that I > > should be cut off from the net if the allow rules do not work. And > > indeed, flushing all rules gives the expected behaviour. But as soon as > > I load the ruleset file (which is the same as previously and then it > > worked as expected) the fw becomes wide-open, the only rules that appear > > to work are the divert for natd, and the allow rules. But the deny rules > > do nothing, it seems that even the "catch-all" implicit deny rule at the > > bottom does nothing. Am I going insane, or is this real? > > Don't know. But, I do know that logging seemed to be messed up. My old > ruleset only logged a few rules, and after upgrading I seemed to get a > log entry for every packet. It was so overwhelming that I didn't even > try to analyze it. Since I needed natd on the machine in question, > I just reverted all the new ipfw code, and haven't spent much time at it. I just went back to the old log files, and based on a spot check, the log files do indeed record as "accepted" packets that should have been denied by the ruleset (and which are currently denied without logging using the same ruleset and the "old" ipfw). -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with natd, ipfw
On Sun, Jul 07, 2002 at 11:35:46PM +0200, Szilveszter Adam wrote: > Hello everybody, > > I upgraded to yesterday's -CURRENT and have made a few observations: > 2) and much more alarmingly: Although the new ipfw really seems to > process the ruleset faster, some rules appear to do nothing! I > have a "default-to-deny" setup, so theoretically this should mean that I > should be cut off from the net if the allow rules do not work. And > indeed, flushing all rules gives the expected behaviour. But as soon as > I load the ruleset file (which is the same as previously and then it > worked as expected) the fw becomes wide-open, the only rules that appear > to work are the divert for natd, and the allow rules. But the deny rules > do nothing, it seems that even the "catch-all" implicit deny rule at the > bottom does nothing. Am I going insane, or is this real? Don't know. But, I do know that logging seemed to be messed up. My old ruleset only logged a few rules, and after upgrading I seemed to get a log entry for every packet. It was so overwhelming that I didn't even try to analyze it. Since I needed natd on the machine in question, I just reverted all the new ipfw code, and haven't spent much time at it. > Also, I have observed that when loading the rules from the ruleset file, > ipfw prints two lines for each, one with the expected rule number and > one with all zeros. I don't know if it's significant though. > > It is like this: > > 0 deny log ip from any to any > 03600 deny log ip from any to any Yes, I saw this. However, 'ipfw l' doesn't include a 0 rule, and the rule list appears correct. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: natd core dumping with bus error
On Tue, Jul 02, 2002 at 06:04:36PM -0700, Joel M. Baldwin wrote: > > > Something has messed up natd. If I don't have the > punch_fw option in the /etc/natd.conf file it eventuially > core dumps with a bus error. I think this started JUST > BEFORE the KSE commit. Yes, I've seen the same thing on a pre-KSE kernel. The error occurs in PunchFWHole in alias_db.c in libalias. Reverting the following commit seems to fix it (I haven't had a chance to investigate further): luigi 2002/06/27 16:02:18 PDT Modified files: sbin/ipfwMakefile sys/netinet ip_dummynet.c ip_fw.h sys/conf files lib/libalias alias_db.c Added files: sbin/ipfwipfw2.c sys/netinet ip_fw2.c Log: The new ipfw code. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xmms broken by either libc_r or sound
On Wed, Jun 14, 2000 at 05:51:01PM -0700, Chris Piazza wrote: > On Wed, Jun 14, 2000 at 05:41:39PM -0700, Alfred Perlstein wrote: > > xmms is a really good test for libc_r and the sound system. > > > > xmms no longer plays back mp3s, other mp3 players are working > > fine. > > > > Any ideas? > > Yes backout recent changes to sys/dev/sound/pcm/channel.c. (a few days) > > There was a large-ish thread about this on -committers too... Before you do, it would be interesting to check whether the pcm driver is getting dma interrupts. Either try to play some sound and check vmstat -i, or add a printf to chn_wrintr in channel.c. Lots of the reportable problems with the pcm driver can be reproduced here when the driver does not get dma interrupts. However, it may be unique to my setup. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCM problems (was Re: cvs commit: src/sys/dev/sound/pcm channel.c)
Note: CC list has been trimmed, and moved to -current from -committers
as there are related comments on this issue on -current.
On Sat, Jun 10, 2000 at 07:15:58AM -0700, Jordan K. Hubbard wrote:
> I'm also finding that applications like mpg123 don't play audio
> anymore whereas that very application does with a May 15th kernel,
> that being the most recent "old" kernel I have lying around on this
> laptop. If I play a WAV file with waveplay, it works fine. That
> does tend to suggest that the speed at which you can cram data down
> the audio subsystem's throat is a factor.
>
> - Jordan
>
> > On Fri, Jun 09, 2000 at 02:11:29PM -0500, Richard Seaman, Jr. wrote:
> >
> > > > If I just cat a .au file into /dev/audio, I get about 1/4 of a second
> > > > of plan and then silence, with & without the patch.
> > >
> > > Your symptoms are different then. Don't know if the cause is the
> > > same.
> >
> > Thinking about this some more, and as a followup to my last message, here's
> > what I'm guessing is happening to you.
> >
> > You fill the device buffers very rapidly. Since chn_wrintr is not getting
> > called as dma activity occurs, the only time the dma pointers can get updated
> > and therefore indicate that the buffers aren't full is when you write to
> > the buffers -- but you can't because they're already marked full. ie.
> > you're deadlocked. The sound you hear is the dma buffers emptying, but your
> > app never knows it happened because the buffers are still marked full.
> >
> > My case is the opposite side of the problem. My app doesn't always fill the
> > buffers fast enough, and the dma pointers get corruped.
> >
> > I'd guess that those that don't have problems either a) are getting
> > dma interrupts, or b) manage to fill the buffers at a rate that is
> > neither too fast nor too slow.
I don't know if all the reported pcm problems are related. In my case
it appears that the pcm driver expects to get dma interrupts, but isn't
getting them. Don't know if thats a hardware problem that is unique
to my old Gus PnP Pro that I just recently pulled off the scrap heap
and installed. However, a number of the problems others have reported
were reproducable here.
I've been running the attached patch to channel.c in sys/dev/sound/pcm.
With this, I am able to play mp3 files with both mpq123 and RealPlayer7,
wav files with waveplay, and 'cat XXX.au > /dev/audio' works fine.
These patches don't solve the lack of dma interrupts, but appear to
work around them. If you are getting dma interrupts, you will get
a flood of "chn_wrintr" messages, and you will probably want to
disable the related printf in this case. Also, your problem in this
case is probably different than mine. Also, the "DEB(x) x" statement
will generate some debugging junk in your log files, so you might
want to comment this out if you don't want it.
I haven't tried these for recording, so I have no idea if they work
for recording. From comments Brian Somers has made, I gather this
will probably still not solve his problems.
I wonder if Cameron Grant could confirm whether the driver expects
dma interrupts in all cases?
--
Richard Seaman, Jr.email:[EMAIL PROTECTED]
5182 N. Maple Lane phone:262-367-5450
Nashotah WI 53058fax:262-367-5852
Index: channel.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v
retrieving revision 1.28
diff -u -r1.28 channel.c
--- channel.c 2000/06/06 22:30:22 1.28
+++ channel.c 2000/06/11 16:25:26
@@ -35,10 +35,10 @@
#define ISA_DMA(b) (((b)->chan >= 0 && (b)->chan != 4 && (b)->chan < 8))
#define CANCHANGE(c) (!(c)->buffer.dl)
-/*
+
#define DEB(x) x
-*/
-static void buf_clear(snd_dbuf *b, u_int32_t fmt, int length);
+
+static void buf_clear(snd_dbuf *b, u_int32_t fmt, int start, int length);
static void chn_dmaupdate(pcm_channel *c);
static void chn_wrintr(pcm_channel *c);
static void chn_rdintr(pcm_channel *c);
@@ -187,15 +187,20 @@
hwptr = chn_getptr(c);
if (c->direction == PCMDIR_PLAY) {
delta = (b->bufsize + hwptr - b->rp) % b->bufsize;
+ buf_clear(b, b->fmt, b->rp, delta);
b->rp = hwptr;
b->rl -= delta;
b->fl += delta;
-
if (b->rl < 0) {
+ b->rl = 0;
+ b->fl = b->bufsize;
+ }
+ if (b->rl < 0) {
DEB(printf("OUCH!(%d) rl %d(%d) delta %d bufsize %d h
Re: IPv6: can a link-site (or global) address be configured in rc.conf?
On Sat, Mar 11, 2000 at 02:50:28AM +0900, Yoshinobu Inoue wrote: > > I also had to adjust my ipv4 firewall rules to allow protocol > > ipv6 through. Strange that I didn't have to do that when > > doing a gif tunnel to freenet6.net. Also, what do I have to > > do to enable ip6fw? > > Wmmm, it is strange that freenet6 was OK. Just to clarify, I had to configure a hole in ipfw for freenet6.net too. I had just forgotten about it. :) -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6: can a link-site (or global) address be configured in rc.conf?
On Sat, Mar 11, 2000 at 05:22:09AM +0900, Yoshinobu Inoue wrote: > > I tried deleting the 6to4 address from an interface on the > > interior node and did a ping6, but I get no replies (I think > > you have to configure the route on your end first?). > > Yes, I have configured it, so it should work now. Yes, it does. It all looks good. PING6(56=40+8+8 bytes) c000::2a0:c9ff:feb1:23ae --> 3ffe:501:4819:2000:210:5aff:fe86:b65a 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=0 hlim=63 time=452.312 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=1 hlim=63 time=361.945 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=2 hlim=63 time=421.628 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=4 hlim=63 time=341.997 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=5 hlim=63 time=582.145 ms --- 3ffe:501:4819:2000:210:5aff:fe86:b65a ping6 statistics --- 7 packets transmitted, 5 packets received, 28% packet loss round-trip min/avg/max = 341.997/432.005/582.145 ms -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6: can a link-site (or global) address be configured in rc.conf?
On Sat, Mar 11, 2000 at 02:50:28AM +0900, Yoshinobu Inoue wrote: > By the way, I'm now very much interested in next round of > test, that non 6to4 IPv6 prefix routing via 6to4 cloud. > > Could you please assign some non 6to4 prefix inside your > environment? Ok. c000::/64 > route add -inet6 3ffe:501:4819:2000:: -prefixlen 64 2002:cbb2:8dd8::1 Did it on the router. > Then I believe I can ping to some of your non 6to4 addresses > from my non 6to4 address. Try: c000::2a0:c9ff:feb1:23ae (border router) c000::200:c0ff:fe34:41c6 (interior box) > Also, I think you can ping to my non > 6to4 addr, 3ffe:501:4819:2000:210:5aff:fe86:b65a, from your > non 6to4 address. I tried deleting the 6to4 address from an interface on the interior node and did a ping6, but I get no replies (I think you have to configure the route on your end first?). Is there a simpler way to force ping6 to use the non 6to4 address as the source? I can ping6 your non 6to4 address from my 6to4 address, see attached. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 PING6(56=40+8+8 bytes) 2002:cc5f:bb02:0:2a0:c9ff:feb1:23ae --> 3ffe:501:4819:2000:210:5aff:fe86:b65a 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=0 hlim=63 time=530.244 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=1 hlim=63 time=360.666 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=2 hlim=63 time=360.621 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=3 hlim=63 time=410.744 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=4 hlim=63 time=350.658 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=5 hlim=63 time=350.743 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=6 hlim=63 time=350.836 ms 16 bytes from 3ffe:501:4819:2000:210:5aff:fe86:b65a, icmp_seq=7 hlim=63 time=350.761 ms --- 3ffe:501:4819:2000:210:5aff:fe86:b65a ping6 statistics --- 9 packets transmitted, 8 packets received, 11% packet loss round-trip min/avg/max = 350.658/383.159/530.244 ms
Re: IPv6: can a link-site (or global) address be configured in rc.conf?
On Fri, Mar 10, 2000 at 07:35:08AM -0600, Richard Seaman, Jr. wrote: > On Fri, Mar 10, 2000 at 08:09:04PM +0900, Yoshinobu Inoue wrote: > > > 6to4 support seems to be very important for initial IPv6 > > deployment on FreeBSD4.0, so I tried small additinal patches > > to make it available. And It seems to work. > > > > Could some FreeBSD4.0 user with direct internet connectivity > > please try this patches and try to ping6 to my host's 6to4 > > address? > > The procedure is, > > For the benefit of the lists, and confirming private mail I sent, > ping6 works using the second of the patches sent (I didn't try the > first). Ok. In addition to your instructions I also configured the box as an IPv6 router (using the rc.conf switches) and used a prefix of 2002:cc5f:bb02::0/64 on the interior ethernet interface de0 with 2002:cc5f:bb02::1/16 on stf0. I'm not sure if this is quite right. Anyway, I can ping6 to 2002:cbb2:8dd8::1 from my interior ipv6 box as well as from the router box. I also configured DNS for the two boxes, assigning ipv6 addresses to test.ipv6.tar.com and ns.ipv6.tar.com. One of my DNS secondaries does not update immediately on notification, so you might not get the ipv6 resolution until it updates on schedule if you happen to query that box. However, once all the secondaries are up, i hope you can ping6 to both ns.ipv6.tar.com (router) and test.ipv6.tar.com (interior). I also had to adjust my ipv4 firewall rules to allow protocol ipv6 through. Strange that I didn't have to do that when doing a gif tunnel to freenet6.net. Also, what do I have to do to enable ip6fw? -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6: can a link-site (or global) address be configured in rc.conf?
On Fri, Mar 10, 2000 at 08:09:04PM +0900, Yoshinobu Inoue wrote: > 6to4 support seems to be very important for initial IPv6 > deployment on FreeBSD4.0, so I tried small additinal patches > to make it available. And It seems to work. > > Could some FreeBSD4.0 user with direct internet connectivity > please try this patches and try to ping6 to my host's 6to4 > address? > The procedure is, For the benefit of the lists, and confirming private mail I sent, ping6 works using the second of the patches sent (I didn't try the first). -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6: can a link-site (or global) address be configured in rc.conf?
On Mon, Mar 06, 2000 at 09:22:45AM -0800, Bob Fink wrote: > Please read, then ask any questions you may have. 6to4 is currently > supported, and there are relay routers up and running. My apologies if I sound like I need "IPv6 for Dummies". Just to clarify. You mean that 6to4 is currently supported in FreeBSD/KAME? Of course, I'm not quite sure what I mean by this. I guess, if I configure a FreeBSD/KAME host as an IPv6 router, will the router automatically do the IPv6->IPv4 encapsulation when it encounters a destination prefix of 2002::/16 and vice versa for incoming packets? Or, do I need to configure a pseudo interface somehow (gif doesn't look quite like the right thing?). Also, will FreeBSD/KAME hosts (both router and non-router hosts) somehow automatically do the proper address selection algorithm when they encounter multiple IPv6 addresses, or is that an application level requirement? Also, if I have (for example) IPv4 addresses of 204.95.187/24, I assume I can use any of the 2002:[V4ADDR]:/48 prefixes within my allocation, but for external 6to4 connectivity I should probably choose the V4ADDR of the external interface of the 6to4 router? And, finally, do some of the 6to4 relay routers that are "up and running" serve small isolated sites? I assume the best case is that one's ISP provides IPv6 connectivity in some shape or form. But, if thats not the case, I assume the main options are IPv6-IPv4 tunnel to a co-operative IPv6 site, or 6to4 with a default route to a relay router (who I assume must configure a static route back?). Or, run a more sophisticated routing protocol (BGP), but thats a little much for me, I think. Of course, if everyone configures 6to4 (or at least everyone you want to reach) then am I correct that you don't really need 6to4 "relay" routers? This is only for reaching native IPv6 sites without 6to4 addresses? Thanks. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sat, Jan 29, 2000 at 02:35:43AM +0100, Ollivier Robert wrote: > [I said about ntpd usage of sched_* functions:] > > > We should make them standard IMO. > > According to John Polstra: > > I agree. > > BTW, as the sched_* POSIX functions are now standard in GENERIC, I've decided > along with the upgrade to ntpd 4.0.99b to re-enable them. Be aware that the sched_* functions are somewhat broken. Peter Dufault had some patches that fixed them. I also had a later version of them. When Julian inquired about committing my later version, Peter indicated he was re-working the patches and communicating with bde about them. This was about 1-2 months ago. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Sat, Dec 18, 1999 at 11:20:51PM +0100, Martin Blapp wrote: > > Sorry, > > I found a rather easy workaround. Disable DMA for > the disks in the BIOS ... But I still wonder why > enable/disable ATA DMA in kernel has no effect for > this crash. Why does only the BIOS disable help ? Purely a wild guess on my part: If the BIOS is set to enable UDMA, then the bios sets both the controller and the disk for UDMA. But, the ata driver tries to set the disk to WDMA2 mode for "generic drivers". If the controller is set for UDMA and the disk for WDMA2, they might have problems communicating (the "generic driver" doesn't try to mess with the controller settings, I don't think). However, if the BIOS sets the disk and the controller to PIO, then when the ata drivers uses the "generic" treatment to set the disk to WDMA2, this works since PIO and WDMA2 have similar timings. As I said, this is purely a wild guess from someone who understands all this poorly. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Fri, Dec 17, 1999 at 02:28:29PM +0100, Soren Schmidt wrote: > Because the wd driver has a 10 secs timeout, and ata has 5 secs. > I think the easiest way to "solve" this is to increase the > timeout to 10-15 secs, as little as I want to do that... I don't really understand disk drivers, so if I'm off base, I apologize. I'm under the impression that you can query the disk to see if its in idle mode, or if not, if its in standby mode. If you leave the timeout at 5 secs, and you actually timeout, perhaps you can check the disk to see if its in standby mode, or in the process of spinning up. If so, for just this case, perhaps you can adjust the timeout to a greater value before retrying the command? Also, perhaps you want to skip printing the diagnostic if the timeout was due to standby/spinup, unless it also fails on retry? -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Fri, Dec 17, 1999 at 08:22:03AM +0100, Soren Schmidt wrote: > Yup, sounds like the problem some are seing, now I wonder why I > havn't seen it on any of the IBM disks I've access to, hmm... > > It apparantly can't be disabled, but I'll try to figure out if > I can detect when the drive is in this mode, or put it in > standby mode and back again when there is nothing else to do, > that should reset the timer... Note that the wd driver doesn't "report" any problems. Don't know if that is because the wd driver handles this differently, or because the reporting is different. The machine that reports these problems runs 7/24, and has for over a year and a half. The IBM disk has been in for quite a while (maybe 6 months or more). Only ata "reports" the problem. Note that the IBM specs say that spinup from standby to idle is 13 secs "typical" and 31 secs max for this drive. I'm assuming that what we're seeing is that the ata driver "lost contact" because the timeout is less that the time it takes to spinup from standby to idle (or to spinup from an interrupted switch from idle to standby)? -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Thu, Dec 16, 1999 at 09:25:11AM +0100, Soren Schmidt wrote: > There is this thing with the IBM's doing some headcleaning stuff once > a day/week, but I've never seen any of my IBM's do that (I got plenty > of them). I'll try to get more info on that from IBM... Check http://www.storage.ibm.com/techsup/hddtech/prodspec/djna_spw.pdf On page 99 it says: 10.12 Automatic Drive Maintenance (ADM) ADM function is equipped to maintain the reliability even in continuous usage. ADM function is to go into Standby mode automatically after detecting idle mode at intervals of 6 days. This function is always enabled regardless of Standby Timer value. The detail of Standby Timer is described in 12.6, "Idle (E3h/97h)" on page 122, and 12.32, "Standby (E2h/96h)" on page 171. The 6 days counter is reset at the following. Power on Ready Entering Standby mode by Standby Command Entering Standby mode by Standby Timer Both Soft Reset and Hard Reset do not disturb the spin down of ADM. If a command is received during spin down of ADM, the drive quits the spin down and tries to complete the command as soon as possible. In case the spin down of ADM is disturbed by a command, it is retried 12 hours later. For timeout concern, refer to 13.0, "Timeout Values" on page 185. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Thu, Dec 16, 1999 at 09:25:11AM +0100, Soren Schmidt wrote: > It seems Dave J. Boers wrote: > > > > I am still having "disc contact lost messages" regularly too. I've been > > posting about them on several occasions some time ago. I haven't been able > > to pinn it down, however. IF they occur, they occur somewhere between 9:15 > > and 9:20 a.m. OR p.m. But they don't always. This used to be 10:15, but > > that changed _some weeks after_ the change of daylight saving time. I can't > > seem to relate it to anything. It is unlikely that it's a power glitch, > > because the system has been displaying the problem with two different > > UPS's. > > > > The machine is running current current's which are regularly updated. It's > > an ABIT BP6 and the disk causing problems is a WD 7200 RPM 18,2 Gb disk > > running UDMA33. It's the only IDE disk in the system; the other disks are > > all SCSI. The system is running 24/7. Other details were posted earlier. > > There is this thing with the IBM's doing some headcleaning stuff once > a day/week, but I've never seen any of my IBM's do that (I got plenty > of them). I'll try to get more info on that from IBM... I've been running the ata driver for about a week now. Yesterday, for the first time, I got the messages posted below, and now again this morning. Note the fallback to PIO. Also note that Dec 15 is exactly 1 week from the first time I ran with the ATA drivers, thought there have been several reboots in the interim. The times are CST (-600). The machine's time is synched using ntp. Dec 15 07:00:44 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 07:00:45 test /kernel: ata0: resetting devices .. done [snip] Dec 15 19:01:02 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 19:01:02 test /kernel: ata0: resetting devices .. done Dec 15 19:01:07 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 19:01:07 test /kernel: ata0: resetting devices .. done Dec 15 19:01:07 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 19:01:07 test /kernel: ata0: resetting devices .. done Dec 15 19:01:12 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 19:01:12 test /kernel: ata0: resetting devices .. done Dec 15 19:01:12 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 19:01:12 test /kernel: ata0: resetting devices .. done Dec 15 19:01:17 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 19:01:17 test /kernel: ata0-master: ad_timeout: trying fallback to PIO mode Dec 15 19:01:17 test /kernel: ata0: resetting devices .. done Dec 15 19:01:17 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 19:01:17 test /kernel: ata0: resetting devices .. done Dec 15 19:01:22 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 15 19:01:22 test /kernel: ata0: resetting devices .. done [snip] Dec 16 07:01:24 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 16 07:01:24 test /kernel: ata0: resetting devices .. done Dec 16 07:01:29 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 16 07:01:29 test /kernel: ata0: resetting devices .. done Dec 16 07:01:34 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 16 07:01:34 test /kernel: ata0: resetting devices .. done Dec 16 07:01:39 test /kernel: ata0-master: ad_timeout: lost disk contact - resetting Dec 16 07:01:39 test /kernel: ata0: resetting devices .. done Setup: Dec 11 11:31:02 test /kernel: ata-pci0: irq 14 at device 0.1 on pci0 Dec 11 11:31:02 test /kernel: ata-pci0: Busmastering DMA supported Dec 11 11:31:02 test /kernel: ata0 at 0x01f0 irq 14 on ata-pci0 Dec 11 11:31:02 test /kernel: ata1 at 0x0170 irq 15 on ata-pci0 [snip] Dec 11 11:31:02 test /kernel: ata-isa0: already registered as ata0 Dec 11 11:31:02 test /kernel: ata-isa1: already registered as ata1 [snip] Dec 11 11:31:02 test /kernel: ad0: ATA-4 disk at ata0 as master Dec 11 11:31:02 test /kernel: ad0: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S Dec 11 11:31:02 test /kernel: ad0: 16 secs/int, 32 depth queue, UDMA33 Dec 11 11:31:02 test /kernel: ad1: ATA-3 disk at ata0 as slave Dec 11 11:31:02 test /kernel: ad1: 4884MB (10003392 sectors), 9924 cyls, 16 heads, 63 S/T, 512 B/S Dec 11 11:31:02 test /kernel: ad1: 16 secs/int, 1 depth queue, DMA Dec 11 11:31:02 test /kernel: ad2: ATA-4 disk at ata1 as master Dec 11 11:31:02 test /kernel: ad2: 10991MB (22510656 sectors), 22332 cyls, 16 heads, 63 S/T, 512 B/S Dec 11 11:31:02 test /kernel: ad2: 16 secs/int, 1 depth queue, UDMA33 -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reasonable decision-making [Re: HEADSUP: wd driver will be retired!]
On Fri, Dec 10, 1999 at 11:20:19PM -0800, Jordan K. Hubbard wrote: > my strategy on the whole affair at this point has > been to simply make marks on a tally-sheet near my keyboard, While there is now working support for SiS 5591, and thus my initial objection to removal of the wd drivers is now gone, I would still vote to retain it for some intermediate period. You can put my vote in the appropriate column of your tally. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SiS ata Driver (was Re: HEADSUP: wd driver will be retired!)
On Thu, Dec 09, 1999 at 11:28:20AM +0100, Soren Schmidt wrote: > It seems Soren Schmidt wrote: > > It seems Richard Seaman, Jr. wrote: > > > On Wed, Dec 08, 1999 at 03:02:37PM +0100, Soren Schmidt wrote: > > > > > > > OK, you asked for it, following is a patch to support the > > > > sis 5591 chipset. Remember this is done blindfolded, I > > > > have no HW to test on, but you guys do :) > > > > > > Seems to work. I'll let it run for a few days, but I'd guess it > > > is fine. > > > > Great, I have a sligthly modified version that I'd like you to test, > > but it'll have to wait until I get home to my dev box. > > Thanks for testing it out!! > > Can I have you try this patch instead, it is much simpler, and > should give the same results if I read the SiS specs right.. Tried it. Same result as the last patch. Seems to work fine. If you want the dmesg, let me know (same as last time, which I sent you). No problems over the last 2 days with the ata driver. FYI: wd vs ata on AMD 266 with SiS 5591 and IBM-DJNA-371800: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU WD512 9204 95.1 13615 68.5 5741 34.0 10051 92.2 15282 45.4 135.9 3.6 ATA 512 9446 95.2 13723 72.1 4430 25.4 10187 92.0 14836 42.9 132.0 3.5 -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Breaking DMA support for multiple chipsets? (was: HEADSUP: wd driver will be retired!)
On Thu, Dec 09, 1999 at 04:03:58PM +0100, Soren Schmidt wrote:
> It seems Greg Lehey wrote:
> > > OK, you asked for it, following is a patch to support the
> > > sis 5591 chipset. Remember this is done blindfolded, I
> > > have no HW to test on, but you guys do :)
> > >
> > > Let me know what happens...
> >
> > OK. Let's defer removing wd until we know that ata DMA works on these
> > platforms. We'll have a lot of unhappy customers otherwise, myself
> > (wearing another hat) included. If nobody else gets there first, I'll
> > look at this next week.
>
> It already being tested, and it works, but at the same tike I found
> out that the code in the old driver for the sis is schizofrenic, it
> has one way of setting things up, and another way of reporting how
> it is set :(, that way it is difficult to compare results from
> the two drivers..
I think the old wd code was broken on reporting. The reporting
was changed from the original submission, when it was committed.
See the attached message:
>From [EMAIL PROTECTED] Thu May 6 15:14:56 1999
Date: Thu, 6 May 1999 15:14:56 -0500
From: "Richard Seaman, Jr." <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Buglet in SiS support in ide_pci.c
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=tKW2IUtsqtDRztdT
X-Mailer: Mutt 0.95.4i
Status: RO
Content-Length: 1468
Lines: 44
--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
I was just installing a new drive on the machine with the
SiS 5591 chipset, and noticed strange results on the
verbose status probes.
It appears to me that the UDMA status register reported
somehow got flipped. It appears to only affect the
status report in verbose mode, and not the actual setting
of the controller.
If you would like me to commit this fix, let me know.
--
Richard Seaman, Jr. email: [EMAIL PROTECTED]
5182 N. Maple Lanephone: 414-367-5450
Chenequa WI 53058 fax: 414-367-5852
--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ide_pci.c.diff"
Index: sys/pci/ide_pci.c
===
RCS file: /home/ncvs/src/sys/pci/ide_pci.c,v
retrieving revision 1.33
diff -u -r1.33 ide_pci.c
--- ide_pci.c 1999/04/24 20:13:58 1.33
+++ ide_pci.c 1999/05/06 18:36:30
@@ -1161,8 +1161,8 @@
printf ("SiS 5591 status: %s drive %d Ultra DMA %s",
unitno < 2 ? "primary" : "secondary",
unitno & 1,
- (DATC & 0x80) ? "disabled\n" : "enabled");
- if ((DATC & 0x80) == 0)
+ (DATC & 0x80) ? "enabled" : "disabled\n");
+ if (DATC & 0x80)
printf (", %d PCICLK data out\n", ((DATC >> 5) & 0x3) + 1);
printf ("SiS 5591 status: %s drive %d postwrite %s, prefetch %s prefetch count
is %d\n",
unitno < 2 ? "primary" : "secondary",
--tKW2IUtsqtDRztdT--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
SiS ata Driver (was Re: HEADSUP: wd driver will be retired!)
On Wed, Dec 08, 1999 at 03:02:37PM +0100, Soren Schmidt wrote: > OK, you asked for it, following is a patch to support the > sis 5591 chipset. Remember this is done blindfolded, I > have no HW to test on, but you guys do :) Seems to work. I'll let it run for a few days, but I'd guess it is fine. Dec 8 17:25:02 test /kernel: pcib0: on motherboard Dec 8 17:25:02 test /kernel: pci0: on pcib0 Dec 8 17:25:02 test /kernel: ata-pci0: irq 14 at device 0.1 on pci0 Dec 8 17:25:02 test /kernel: ata-pci0: Busmastering DMA supported Dec 8 17:25:02 test /kernel: ata0 at 0x01f0 irq 14 on ata-pci0 Dec 8 17:25:02 test /kernel: ata1 at 0x0170 irq 15 on ata-pci0 Dec 8 17:25:02 test /kernel: isab0: at device 1.0 on pci0 Dec 8 17:25:02 test /kernel: isa0: on isab0 Dec 8 17:25:02 test /kernel: pci0: unknown card (vendor=0x1039, dev=0x0009) at 1.1 Dec 8 17:25:02 test /kernel: pcib2: at device 2.0 on pci0 Dec 8 17:25:02 test /kernel: pci1: on pcib2 Dec 8 17:25:02 test /kernel: vga-pci0: irq 11 at device 0.0 on pci1 Dec 8 17:25:02 test /kernel: fxp0: irq 9 at device 11.0 on pci0 Dec 8 17:25:02 test /kernel: fxp0: Ethernet address 00:a0:c9:b1:23:ae Dec 8 17:25:02 test /kernel: devclass_alloc_unit: pci1 already exists, using next available unit number Dec 8 17:25:02 test /kernel: pcib1: on motherboard Dec 8 17:25:02 test /kernel: pci2: on pcib1 Dec 8 17:25:02 test /kernel: fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 Dec 8 17:25:02 test /kernel: fdc0: FIFO enabled, 8 bytes threshold Dec 8 17:25:02 test /kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Dec 8 17:25:02 test /kernel: ata-isa0: already registered as ata0 Dec 8 17:25:02 test /kernel: ata-isa1: already registered as ata1 [snip] Dec 8 17:25:02 test /kernel: ad0: ATA-4 disk at ata0 as master Dec 8 17:25:02 test /kernel: ad0: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S Dec 8 17:25:02 test /kernel: ad0: 16 secs/int, 32 depth queue, UDMA33 Dec 8 17:25:02 test /kernel: ad1: ATA-3 disk at ata0 as slave Dec 8 17:25:02 test /kernel: ad1: 4884MB (10003392 sectors), 9924 cyls, 16 heads, 63 S/T, 512 B/S Dec 8 17:25:02 test /kernel: ad1: 16 secs/int, 1 depth queue, DMA Dec 8 17:25:02 test /kernel: ad2: ATA-4 disk at ata1 as master Dec 8 17:25:02 test /kernel: ad2: 10991MB (22510656 sectors), 22332 cyls, 16 heads, 63 S/T, 512 B/S Dec 8 17:25:02 test /kernel: ad2: 16 secs/int, 1 depth queue, UDMA33 Dec 8 17:25:02 test /kernel: Mounting root from ufs:/dev/ad0s1a -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Wed, Dec 08, 1999 at 12:55:35PM +0100, Poul-Henning Kamp wrote: > > In a few days time the wd driver will be retired from FreeBSDs > i386 architecture. > Since the ata driver does not support DMA on my chipset, at least the last time I tried (SiS 5591), it would be nice to leave the wd driver in the tree for a while, even if its not the default. Possibly there are others in the same boat? -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver as the default
On Mon, Dec 06, 1999 at 12:19:16PM +0200, Vallo Kallaste wrote: > It doesn't know about SiS 5591 PCI IDE controller, the wdc controller > knows. I'm speaking about boot messages, nothing else. Furthermore the > wdc driver sets up UDMA mode on my UDMA capable disks, ata driver > doesn't. It claims that busmastering DMA is supported and sets up WDMA2 > mode instead, I think it's normal as it currently doesn't know about > 5591. The WDMA2 isn't really that bad and otherwise I'm using ata driver > quite happily. Just FYI. The one time I tried ata with my SiS 5591 board I got PIO, no DMA at all. With wd I get UDMA. This was about 2-3 weeks ago. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Which is the truth? (sycalls and traps)
On Sun, Nov 28, 1999 at 09:46:03AM -0800, Matthew Dillon wrote: > > :Ummm Okay are you maybe saying that there is kernel spcae thread support for the > :current FreeBSD using linux threads ??? if so, is there a way, i can also get a > :thread supported system using current for some testing also ??? or it is > :genberic to your installations alone, or is threading actually in 4.0 current > :using linux threads ?? and does it support pthread_cancel ?? > : > :looking forward to a reply > > That isn't what I tested with, but yes, there is currently support for > native linux threads in the linux compatibility stuff. In order to use > the support you need to compile against a linux environment, though. > Annoying, eh? The linuxthreads "port" at http://lt.tar.com didn't compile against a linux environment, and didn't required linux compatibility. The information at that site is now outdated, but there's a pointer there to an updated port produced by Russell Carter that also doesn't require any linux compatibility stuff or linux environment either. You can play with it. It worked quite well both uniprocessor and SMP, though I understand that Russell has encountered problems under SMP recently after Marcel's signal changes in -current. There is a pthread_cancel() included. But, full pthread_cancel() functionality requires a lot of libc support that doesn't currently exist in FreeBSD libc. Therefore, if you're expecting read(), as an example, to be a canellation point (as required by POSIX specs), it won't be. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Which is the truth? (sycalls and traps)
On Sun, Nov 28, 1999 at 08:34:16AM -0800, Matthew Dillon wrote: > Well, it could be 300x but that's like comparing a cache hit to a cache > miss - in real terms a UP syscall takes, what, 1-3 uS? An SMP syscall > takes 6 uS. This on a PIII-450. Both times can be cut down to less > then 500nS with fairly simple optimizations. Unless you are doing > hundreds of thousands of context switches a second the overhead is in > the noise in real terms, and *definitely* in the noise if you tack on > a task switch in the middle of that. FYI, some measurements I did with the Linuxthreads "port" (ie. native FreeBSD kernel threads using the linux threads code) on a 266Mhz AMD processor showed the ability to do about 150,000 kernel thread context switches/sec. The threads didn't do anything other than context switch, so a "real world" context switch might be slower, and the rate varies somewhat with the number of threads. This was uniprocessor, not SMP. This suggests that kernel thread context switches, to have a measureable impact on performance at even the 1% level, have to be occurring at the rate of 1,500/sec or more. With a faster processor, and the optimizations you suggest, I'm sure you might well be talking 10,000 switches/sec to matter. I don't have any threaded apps that come close to this, but perhaps they exist. And, unless you can fix the "user thread" scheduler so it doesn't make any syscalls, its hard to see much of an advantage for user thread context switches over kernel thread context switches, from a performance standpoint. (The current user thread scheduler can actually be slower at context switches that kernel threads, because of the nubmer of syscalls it makes). -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Sat, Oct 02, 1999 at 09:45:30AM -0700, Rodney W. Grimes wrote: > > Read my lips: *NEVER* do a 'make world' until you've got a new bootable > > kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make > > world' because a new kernel doesn't workd is a major drama. > > These folks are 100% correct, some place some where we made a mistake > and are telling users to do things in the wrong order. It might have > even been myself that caused this, I just can't recall when and who > said to build the world before building the kernel. But now looking > at it in hindsight, this is plainly the wrong sequence, and we should > correct that error as soon as possible. > > When did we go wrong and start saying that users should build the world > before building a new kernel?If it was ``I'' that said it, I full > retract any such statement, I was WRONG!. It may have been said in the > patchkit days, or very early FreeBSD 1.x. Unless I'm mistaken, the FreeBSD Tutorial "Upgrading FreeBSD from source" tells you to "make world" before you make and install the kernel. I take it the tutorial is wrong? :) -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru and upages
On Mon, May 24, 1999 at 08:13:57AM +0800, Peter Wemm wrote: > I'd also like to implement a proper clone(2) ala Linux. We have most of > the infrastructure in place already, using that and comparing with NetBSD's > take on the subject should be fairly useful in the end. The main > difference between clone(2) and rfork(2) is that clone() takes a stack > argument and is more specific about certain sharing semantics. At present > these are emulated via flags added into rfork's visibility, I think it > would be cleaner to just use a proper syscall interface onto fork1() rather > than bend rfork(2) even more. The function linux_clone() in linux_misc.c could be a starting place. Making that (or a modified version of it) a FreeBSD syscall would seem to do the trick. It calls rfork() instead of fork1(), but then rfork is implemented as a call to fork1, so the only difference is the interface. Probably the only real issue you have is whether the flags you pass in are FreeBSD rfork flags, or Linux flags that get translated into their equivalent FreeBSD flags internally before you call fork1(). The linux_clone() function obviously needs to take Linux flags. But, if your goal is to have a better interface than rfork(), you don't need to limit yourself to mimicing the linux clone() syscall. However, it seems to me that there are really only three reasons to have a "clone" call. One is for linux emulation, which we already have. Another is to facilitate porting linux apps. But, linux apps normally call the glibc version of clone, which wraps the linux clone(2) syscall. Its easy enough to create a userland (eg. libc) clone() call that wraps rfork (see the Linux threads port for an example implementation). The third is to create a better syscall interface for threading/ process creation than we have with rfork. I think that if FreeBSD is going to have really good "many to many" kernel/user threads there will probably need to be one or a few new syscalls for thread creation/thread management. IMO the best choice would be to think through what these calls should look like. I haven't had time to really work this through in my own mind, though. I suspect that the linux clone(2) syscall is not the best choice for this either. If you're going to work on this, and if you think it would help you, I'd try to find some time to jot down some of my (only partly formed) thoughts on what FreeBSD thread related syscalls might be helpful. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: compiler specs for -pthread/-kthread
On Tue, Apr 13, 1999 at 03:16:01PM -0700, Kurt D. Zeilenga wrote: > To facilate auto detection of the local threading environment, > it would be nice if the -?thread options set all the necessary > compiler/linker flags. It is a common practace for such > options to specify both compilation and link options. > > I suggest the EGCS specs be adjusted to: > > -pthread => -D_THREAD_SAFE -D_UTHREADS -lc_r > -kthread => -D_THREAD_SAFE -D_KTHREADS -lpthread A little known and not well documented fact is that FreeBSD also uses _REENTRANT in its header files. Ever wondered why you couldn't find declarations for gamma_r, lgamma_r, gammaf_r, or lgammaf_r? Check math.h. :) Personally I think conditional declarations should just be eliminated from math.h, rather than tell people they might have to add -D_REENTRANT. :) > > If the LinuxThread "port" is targetted to be -kthread: > > -kthread => -D_REENRANT -D_LINUXTHREADS -lpthread In FreeBSD, you should define -D_THREAD_SAFE for linuxthreads if you want the thread safe behaviour in stdio.h. Its a libc thing, not a linuxthreads thing. Adding -D_REENTRANT to linuxthreads doesn't get you anything except the added headers in math.h (same as libc_r). > After modify the specification, the headers/libraries would > be adjusted as needed. I can easily submit diffs if desirable. Nobody has offered to commit the changes to the header files I have requested, and the PR I submitted on Jan 29 has not been acted upon. As a result, I anticipate dropping the -DLINUXTHREADS solution to the header conflict problem in favor of stuffing all the linux threads specific headers into /usr/local/include/pthread/linuxthreads where they go now, and instead of -DLINUXTHREADS, people will have to add -I/usr/local/include/pthread/linuxthreads to their compile options. (This works now too). -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: rfork()
On Mon, Mar 22, 1999 at 11:34:25AM +0800, Peter Wemm wrote: > Doing clone() in libc that calls rfork(2) and doing all the stack setup > should be pretty easy.. (Richard has done it already, yes?) Its in package at http://lt.tar.com/linuxthreads.tar.gz . If anyone wants to grab it out of there an put it into shape to commit it, be my guest. > On the other > hand, the linux emulator needs it so there's a counter-argument for making > it a proper syscall outright. Leaving the rfork(2) stuff unmolested and at > least resembling it's plan9 origins probably has some merit - adding extra > arguments would mess that up. I) clone syscall - The linux emulator needs (and has) a clone syscall: int linux_clone(int flags, void *stack) The value of an exit signal is passed in the lower 8 bits of the flags argument, the linux counterparts to the FreeBSD RF* flags are passed in the balance of the flags argument. I haven't seen or heard of a linux app that calls the clone syscall directly. I know of two "apps", linuxthreads and the linux version of WINE, that call the linux glibc version of clone (see below), which is a wrapper for the syscall. The only thing that the linux syscall does, that can't be done easily in FreeBSD using rfork and an appropriate wrapper to rfork, is pass in the exit signal. rfork does have a flag to set an exit signal of SIGUSR1, but it does not conveniently take a parameter to set it more flexibly. OTOH, the only FreeBSD app I know of that actually sets an exit signal other that the default SIGCHLD, is the linuxthreads port noted above. I'm not sure there is really a need for a "clone" syscall at this point, but if you wanted it, you could just copy the linux_clone code in linux_misc.c . You would have to decide if you want the flags parameter to take the linux flags values, or FreeBSD flags (the emulator has to take the linux values, obviously). My vote: don't bother with a syscall until there's a demonstrated need. II) clone in libc - Linux glibc has a clone call wrapper for the clone syscall, defined as: int clone (int (*fn) (void *arg), void *stack, int flags, void *arg) The stack and flags are passed directly to the clone syscall, and the fn(arg) is the user function the cloned process should execute. Its easy enough to implement this in FreeBSD as a wrapper for rfork. If you want to facilitate porting linux code, you would want the flags argument to take linux flags, which would then be translated into their FreeBSD counterparts before rfork is call. This is what the code in the linuxthreads port does, and you are welcome to commit it. The only issue here is whether people need to port linux code that calls clone directly. As noted above, the only code I know of that calls clone directly is WINE and linuxthreads. All the rest of the code uses pthread_create, which only indirectly calls clone. My vote: I haven't seen the need, but if there is one, lets do it. III) libc rfork wrapper --- It probably would be nice to have a libc rfork wrapper that grafts a stack and a user function onto the rfork'd child process. But, it should probably take FreeBSD flags, and there's no reason to call it "clone". John Dyson's thr_fork is one such implementation. Luoqi Chen posted another variation to either -hackers or -current maybe 6-9 months ago. Matt Dillon just posted yet another variation. Or, the linuxthreads port has a variation of the clone call that has the same API as the linux clone call, but takes FreeBSD flags (see clone.S). My vote: its worth doing, but not a top priority. The main issue is to decide what interface would be most convenient. Its not a top priority since the code already exists for those (rare) cases where someone really needs it. And, lets not call it "clone". -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: rfork()
On Sat, Mar 20, 1999 at 11:43:14PM -0800, Matthew Dillon wrote: > :For the suggest something, you realize that with Richard's VM_STACK code it > :should be relatively trivial to make this automatic (suggestion: add > :RFSTACK flag). > : > : Brian Feldman _ __ ___ ___ ___ > : gr...@unixhelp.org_ __ ___ | _ ) __| \ > : http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | > : FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ > > If the goal is to completely share the address space, which > RFMEM does, you can't split anything, not even the stack. It > sure would be useful if there were a standard clib call adequate > for calling rfork() and calling a function in the child w/ a new > stack. Possibilities for the clib call are noted in separate messages. The problem with adding an "RFSTACK" flag to the rfork call is that a lot of the time the caller of rfork wants to control the stack address. If you just add an "RFSTACK" flag, the system will have to pick the address. The linux clone syscall (different from the linux clone libc function) takes two additional parameters that rfork doesn't. One of those parameters is the stack TOS address, and the other is the exit signal the clone'd process should return (so "kthreads" can return different exist signals from child processes). As long as rfork doesn't take a TOS parameter as input, you will have to use an assembly language wrapper to rfork to graft the stack onto the child process. The primary reason I've seen, that the caller of rfork wants to control the TOS address, is so there is an efficient thread_self function. By marrying TLS to the stack, and using aligned/uniformly spaced stack addresses, thread_self can examine its stack, and derive the address of the TLS efficiently. Now, it would be very nice to find a better way to do the thread_self stuff. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: rfork()
On Sun, Mar 21, 1999 at 12:48:07AM -0800, Matthew Dillon wrote: > This is an example only. It takes a *BUNCH* of arcane assembly to make > it work. > > I would suggest *EXTREME* caution when using a completely cloned address > space such as RFPROC|RFMEM generate. Normal library calls cannot be made > by the child safely. Thread libraries will also not work since they > expect the pthread model. > > This is not portable. The assembly is designed for ELF libraries. The linux threads "port" at http://lt.tar.com/linuxthreads.tar.gz contains an implementation of a linux clone call using rfork. An alternative assembly language interface to rfork, originally posted to -hackers by John Dyson last summer, is attached. This was part of a larger posting of some kthread code. Check the mail archives for the complete posting by John on August 20, titled "rfork stuff", which includes an example using thr_fork. No reason I can see that thr_fork and/or "clone" couldn't be added to libc. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 .file "rf.S" #include #include "DEFS.h" #include "SYS.h" #define KERNEL #include #undef KERNEL #undef DEBUG /* *8 12 162024 28 * thr_fork(flags, stack, startrtn, startarg, userrtn, arg); * * flags: RF* flags for rfork in unistd.h. * subr: subroutine to run as a thread. * stack: top of stack for thread. * arg: argument to thread. */ .stabs "rf.S",100,0,0,Ltext0 .text Ltext0: .type CNAME(thrfork),@function .stabd 68,0,1 ENTRY(thrfork) pushl %ebp movl%esp, %ebp pushl %esi /* * Push thread info onto the new thread's stack */ movl12(%ebp), %esi / get stack addr subl$4, %esi movl28(%ebp), %eax / get user argument movl%eax, (%esi) subl$4, %esi movl24(%ebp), %eax / get user thread address movl%eax, (%esi) subl$4, %esi movl20(%ebp), %eax / get internal argument movl%eax, (%esi) subl$4, %esi movl16(%ebp), %eax / get internal subroutine movl%eax, (%esi) .stabd 68,0,2 /* * Prepare and execute rfork */ pushl 8(%ebp) pushl %esi lealSYS_rfork, %eax KERNCALL jb 2f .stabd 68,0,3 /* * Check to see if we are in the parent or child */ cmpl$0, %edx jnz 1f addl$8, %esp popl%esi movl%ebp, %esp popl%ebp ret .p2align 2 /* * If we are in the child (new thread), then * set-up the call to the internal subroutine. If it * returns, then call _exit. */ .stabd 68,0,4 1: movl%esi,%esp #ifdef DEBUG movl%esp, _stackaddr movl(%esp), %eax movl%eax, _stack movl4(%esp), %eax movl%eax,_stack+4 movl8(%esp), %eax movl%eax,_stack+8 movl12(%esp), %eax movl%eax,_stack+12 #endif popl%eax #ifdef DEBUG movl%eax,_fcn #endif call%eax addl$12, %esp /* * Exit system call */ callPIC_PLT(_exit) .stabd 68,0,5 2: addl$8, %esp popl%esi movl%ebp, %esp popl%ebp jmp PIC_PLT(HIDENAME(cerror)) .stabs "thrfork:f67",36,0,6,CNAME(thrfork) Lfe1: .sizeCNAME(thrfork),Lfe1-CNAME(thrfork) #ifdef DEBUG .data .globl _stack _stack: .long 0 .long 0 .long 0 .long 0 .long 0 .globl _stackaddr _stackaddr: .long 0 .globl _fcn _fcn: .long 0 #endif #include extern pid_t thrfork(int flags, caddr_t stack_top, void (*internal_fn)(void *, int (*)(void *), void*), void *internal_arg, int (*user_fn)(void *), void * user_arg);
SMP Threads (was: Re: SMP and SO5.0)
On Wed, Mar 03, 1999 at 06:13:43PM -0700, Russell L. Carter wrote: > > John Dyson extemporised: > > %Julian Elischer said: > %> > %> > %> On Tue, 16 Feb 1999, Luoqi Chen wrote: > %> > You may try my patch at http://www.freebsd.org/~luoqi, which would allow > %> > linux threads to run on SMP. > %> > %> I've gone through these patches and I can see that they are really needed > %> for SMP where address spaces are shared. > %> > %I agree -- a per-cpu page directory per multithreaded process is the way that > %I had implemented. Excellent!!! > % > > So I tried these out. The examples work in the linuxthreads dir but many > other things do not. For instance, > > Built debug ACE+TAO with egcs-2.91.62, March 2 -current, newest > LinuxThreads port. Uniprocessor has no errors. SMP fails, for instance: > > rcar...@mazatzal:~/ace/ACE_wrappers/tests [82] ./TSS_Test > TSS_Test in malloc(): warning: recursive call. > TSS_Test in malloc(): warning: recursive call. > Abort trap (core dumped) > rcar...@mazatzal:~/ace/ACE_wrappers/tests [83] gdb TSS_Test -core > TSS_Test.coreGDB is free software and you are welcome to distribute copies of > it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (i386-unknown-freebsd), > Copyright 1996 Free Software Foundation, Inc... > Core was generated by `TSS_Test'. > Program terminated with signal 6, Abort trap. > Reading symbols from /home/rcarter/ace/ACE_wrappers/ace/libACE.so...done. > Reading symbols from /usr/local/lib/liblthread.so.0...done. > Reading symbols from /usr/lib/libm.so.2...done. > Reading symbols from /usr/lib/libc.so.3...done. > Reading symbols from /usr/libexec/ld-elf.so.1...done. > #0 0x18243bf4 in sched_yield () > (gdb) where > #0 0x18243bf4 in sched_yield () > #1 0x181eb051 in sched_yield () at sched.c:58 > #2 0x181eac79 in _spinlock (lck=0x18281738) at spinlock.c:88 > #3 0x18278a02 in free () > #4 0x181a8765 in __builtin_delete (ptr=0x8054170) > #5 0x804ada5 in worker (c=0x64) at TSS_Test.cpp:222 > #6 0x180fc4e2 in ACE_Thread_Adapter::invoke (this=0x8051540) at OS.cpp:2075 > #7 0x180fc556 in ace_thread_adapter (args=0x8051540) at OS.cpp:2194 > #8 0x181ebe8c in pthread_start_thread (arg=0xeb5ffd04) at manager.c:160 > #9 0x181ec49d in _clone () at clone.S:1 > #10 0x in ?? () > #11 0x1805ec5c in .curbrk () > Cannot access memory at address 0xf9dc. Comments (but no solution): 1) gdb is tricky to use with threads. What you see is not always where you are. It doesn't always follow the threads very well, if at all. 2) AFAIK, there are only two reasons you should ever see the "malloc(): warning: recursive call" message. One reason is that the libc global variable __isthreaded is not set. I don't think this is the case here, since the gdb trace seems to show _spinlock being called within free(). This would not happen if __isthreaded is not set. 3) The other reason for the warning is that malloc/free have been called recursively within the same thread. AFAIK, this can only happen if malloc/free are called within a signal handler (which is an error), and one of malloc/free is interrupted by a signal. Looking briefly at the ACE TSS_Test code, I suspect that the signal handler calls free(). 4) I'm not sure what the real problem is, whether it is a bad signal handler, or more likely, the real problem is whatever generated the signal within malloc/free, and the bad signal handler is a misdirect. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Heads up: Linux Thread "port" changes.
A number of people have downloaded the linux threads "port" located at http://lt.tar.com . It has been updated today, with minor bug fixes, and a change to make it compatible with kernel patches committed yesterday to both -current and -stable. While I haven't actually tested it, I would expect problems using post-March 1 kernels with the older "port", and vice-versa. If you are experimenting with this "port", you should update the "port" when you update your kernel. *NOTE* This port has nothing to do with linux threads running in linux emulation mode. If you're only running linux apps in emulation mode you don't have to worry about this. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
On Sun, Feb 28, 1999 at 11:52:57PM +1100, Bruce Evans wrote:
[snip]
> Here is a simpler example.
>
> ---
> #include
> #include
>
> #include
> #include
>
> #define SIZE(32 * 1024 * 1024)
>
> int
> main(void)
> {
> void *p;
> char vec[SIZE / PAGE_SIZE];
>
> p = malloc(SIZE);
> if (mincore(p, SIZE, vec) != 0)
> err(1, "mincore");
> return (0);
> }
> ---
>
> mincore() locks the vmspace map, and initialises vec[] a byte at a time
> using subyte(). When vec[] is sufficiently large, it is not all in core
> initially and a page fault occurs in subyte(). The new stack growing
> code locks the vmspace map early and panics.
It appears to me the potential for deadlock exists in the old grow code
too, but is less likely.
I've attached a patch that addresses the issue, though there is a
question if this is the best solution.
With the old grow code, if the map lock is already held, one of the
following will be true
a) the grow code doesn't get executed because the va is not
in the stack region, which is equivalent to grow returning
success
b) the grow code returns success because there's no need to
grow the region because the va is aready in the mapped region.
c) the grow code returns false if the va is within the stack
region and there's no room left, which normally will result
in a SIGSEGV
d) the grow code attempts to grow the stack via vm_map_find and
will then deadlock at the vm_map_lock call
With this patch, if the map lock is already held, by always returning
success, cases a) and b) will be the same as before. For case c)
the code will attempt to continue to execute, generally calling
vm_fault, which should, I think, generate a SIGSEGV, essentially
the same result as the old code, but via a different path. Case d)
will now continue executing in a manner equivalent to the new case c).
The question is whether there is a way to do the autogrow function if
the map lock is already held.
--
Richard Seaman, Jr. email: d...@tar.com
5182 N. Maple Lanephone: 414-367-5450
Chenequa WI 53058 fax: 414-367-5850Index: vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.152
diff -c -r1.152 vm_map.c
*** vm_map.c1999/02/24 21:26:25 1.152
--- vm_map.c1999/02/28 20:41:25
***
*** 663,668
--- 663,674
int rv;
int is_procstack = 0;
+
+ #define vm_map_locked(map) lockstatus(&(map)->lock)
+
+ if (vm_map_locked(map))
+ return (KERN_SUCCESS);
+
vm_map_lock(map);
/* If addr is already in the entry range, no need to grow.*/
Re: /etc/defaults/rc.conf
On Tue, Feb 16, 1999 at 09:04:11AM -0500, Luoqi Chen wrote: > Initially I though /etc/defaults/rc.conf stored the default settings and then > we could override some of the settings in /etc/rc.conf, but after a close > look at how they are used in /etc/rc*, I am confused: > > if [ -f /etc/defaults/rc.conf ]; then > . /etc/defaults/rc.conf > elif [ -f /etc/rc.conf ]; then > . /etc/rc.conf > fi > > If I have a /etc/defaults/rc.conf, then my /etc/rc.conf won't be consulted. > So what is the purpose of /etc/defaults/rc.conf? Doesn't /etc/defaults/rc.conf pull in /etc/rc.conf ? It appears to here. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: more about yield() versus sched_yield()
On Sun, Jan 31, 1999 at 09:34:45PM +1100, John Birrell wrote: > Peter Dufault wrote: > > > I've got a synch_yield() in kern_synch and a call into it from yield() > > > in kern_thread that duplicates the yield() behavior for the non-RTPRIO, > > > non-sched_yield() condition. synch_yield() also KASSERTS > > > that p == curproc since nothing else makes sense. > > > > While we're discussing yield here's a question. > > > > The difference between yield() and sched_yield() is that yield > > unconditionally > > yields while sched_yield() won't if you are the highest priority process > > and the only process in your run queue. Does anyone know the > > reuirements on yield() and would it continue to function for us if > > it worked the same as sched_yield()? > > FWIW, the yield syscall is _not_ built into libc, so I doubt there will > be anything that actually uses it. I think you should just keep > sched_yield(). FWIW, there was sample code posted to -current by John Dyson that used the syscall yield, as well as the undocumented (and absent from libc) syscalls thr_sleep and thr_wakeup. The implication of his comments was that he used the code, or something like it, in some production application. As I indicated to you several weeks ago, I think it is possible to have a priority inversion problem in spinlocks that spin on sched_yield. The yield call, as implemented, partly addresses the issue. However, as you commented to me, it does so poorly. If the consensus is to drop or modify SYS_yield, my vote would be to give consideration to changing the call to more correctly address the priority inversion issue. Possibly a yield (pid_t pid) where the pid passed in is the pid of the thread (process) holding a lock. The system could then check the credentials of the pid to see if there is permission (eg. its a kernel thread of the same process) and if so, raise the priority of pid to that of the calling process for one time slice so pid has a chance to execute and free the lock. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: LINUX clone? sched_yield?
On Sat, Jan 30, 1999 at 03:33:26PM -0300, Paulo Fragoso wrote: > Hi, > > I'm trying to install StarOffice 5.0 in my FBSD-3.0-STABLE (26Jan1999). > When setup is running the kernel reports: > > linux_clone(303): Not enabled > Jan 30 15:05:39 foker /kernel: cmd setup.bin pid 303 tried to use > non-present sched_yield > Jan 30 15:05:53 foker last message repeated 892 times > > What's happening? You need to: 1) Upgrade your source tree to Jan 28 or later for 3.X or Jan 26 or later for 4.0 current, and "make world" and config and remake and install a new kernel, or 2) Take your existing source and add -DCOMPAT_LINUX_THREADS to CFLAGS and COPTFLAGS in /etc/make.conf and make world and remake and install your kernel. Also, you need to add the posix priority extensions to your kernel (see LINT). Or, there is also more information at http://lt.tar.com -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Locked at 100% User CPU
On Thu, Jan 28, 1999 at 04:10:26PM -0800, Matthew Dillon wrote: > :In libc_r, I don't think the code in uthread_kern.c's > :_thread_kern_select() scales at all. > : > :As the number of network connections (TCP) to my application grows, I > :believe this routine takes longer and longer and my CPU goes to 100% > :user space. > : > :Something makes me believe that this routine has an n^2 (or worse) > :problem. Seems to relate to the number of fd's to select() on. At > :about 300-400, even a P2 400Mhz gets max'd out and gets nothing done. > : > :Anybody have a feeling as to what is wrong here? > : > :-Rob > > This code looks pretty bad, all right. It looks like it is O(N^2) > in PS_SELECT_WAIT(), especially if descriptors get randomly strewn > amoungst the threads. It also looks like it is regenerating the FDS masks > on each call completely from scratch. It also looks like it is > scanning the entire thread list - both waiting and running threads, > to prioritize the next thread to run and then scanning it again > to select the thread priority, then scanning the whole list yet > again to find the one it wants to run. > > This is massively unscaleable code. Is anyone actively working on > it? The uthread code does not scale well, nor perform particularly well. I have demonstration code that suggests a 1-1 kernel threads implemention can create threads 5-20 times faster than the uthread code. It can do context switches (even without any fds open) from 2-3 times faster (just a few threads) to 15-20 times faster (~100 threads) to 200+ times faster (~1000 threads). Don't know if anyone is working on uthreads. IMO rather than trying to fix the uthread code, which would be a significant project, it would be better to convert it to a N:M kernel thread implementation. It wouldn't be all that much more work than getting the user thread code in first rate shape. But, either way I think its a fairly big project. -- Richard Seaman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Whats VM_STACK (was Re: Netscape | Mozilla)
On Wed, Jan 27, 1999 at 12:35:09PM -0500, Luke wrote: > what is this VM_STACK option? Its some new code to manage "autogrow" stacks. The existing (old) code made a process stack autogrow. But, its useful to be able to create additional autogrow memory regions to use as thread stacks in threaded programs. The additional code does this, and uses the same code to manage the process stack. Its been around for a month or so, hidden behind the VM_STACK option (ie. you had to add -DVM_STACK when compiling kernel/world). The idea was that if it works, the option would be removed and the code made permanent. For i386 machines, the "option" was made the default about 2 days ago for -current, and was made the default for 3.X today. You can still pull it out if you have problems, as its still mostly hidden behind the VM_STACK defines. -DVM_STACK is now just turned on by default. As soon as it gets more testing on alpha machines, and if it seems to continue to work elsewhere, and if there's no great objection, its likely to become permanent. mmap(2) has some more information (if your sources are very current). -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Netscape | Mozilla
On Wed, Jan 27, 1999 at 02:20:32PM -0500, Luke wrote: > I tried that one but it wants linux_lib installed on /compat and > theres > no room. Do you know if its ok to make /compat a link to somewhere else for > the > linux_lib port. [why does it install into / anyways] I have /compat symlinked to another partition. As long as its mounted before you need anything in /compat you should be fine. At least here, thats no problem, and I turn on linux in /etc/rc.conf. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-Current, netscape halts system
On Wed, Jan 27, 1999 at 11:04:22AM -0800, Parag Patel wrote: > > Just another data point. I just updated my 2xPII/300 system to > 4.0-CURRENT last night (Tues Jan 26), and I'm running Netscape 4.5 just > fine - no crashes od any odd behavior at all. VM_STACK is defined, I > have 256Mb RAM, and 256Mb swap (which is currently untouched since the > reboot) striped across 2 disks. A make -j8 buildworld also succeeded > early this morning at about 5am. Softupdates is turned on for all > disks and all partitions except /tmp which is async mfs. In private mail, Brian Feldman has indicated his problem was NOT the VM_STACK option, but was another configuration problem that he since fixed. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-Current, netscape halts system
On Wed, Jan 27, 1999 at 10:02:31AM -0600, Richard Seaman, Jr. wrote: > > If you have Netscape problems, it would be worthwhile to try removing > > -DVM_STACK from src/sys/compile/BLAH/Makefile and doing a make clean all > > install. I am pretty certain this is the cause of Netscape crashing, at > > least > > on startup... > > Anything is possible. FWIW, though, I've been running with -DVM_STACK > enabled for over a month, and I use Netscape 4.5 everyday, and never had > a problem. One other thing... -DVM_STACK has been the "default" for only about 36 hours now. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-Current, netscape halts system
On Wed, Jan 27, 1999 at 10:20:14AM -0500, Brian Feldman wrote: > On Wed, 27 Jan 1999, Sheldon Hearn wrote: > > > > I still don't think we're getting any closer to the question "Why is > > Netscape unstable on CURRENT when it worked fine for me on STABLE?" The > > problem seems to be that those who know enough to offer a useful answer > > don't seem to be seeing the instability reported. > > > > So if this thread isn't going to be dropped, the focus should probably > > be shifted to "What information should we request from people who have > > this problem?" > > > > Ciao, > > Sheldon. > > If you have Netscape problems, it would be worthwhile to try removing > -DVM_STACK from src/sys/compile/BLAH/Makefile and doing a make clean all > install. I am pretty certain this is the cause of Netscape crashing, at least > on startup... Anything is possible. FWIW, though, I've been running with -DVM_STACK enabled for over a month, and I use Netscape 4.5 everyday, and never had a problem. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: linux kld
On Tue, Jan 26, 1999 at 02:38:12PM -0500, Kenneth Wayne Culver wrote: > when my computer starts up (just finished make world 5 minutes ago) I get > the following error: > > link_elf: symbol grow undefined. > > does this mean that the linux emu is broken right now? I think it means there is a goof in some changes I sent to Julian that he committed. If you want a quick fix, try applying the attached patch, drop into the /usr/src/sys/modules/linux directory and do a make clean, make and then make install. Then execute "linux". -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 Index: sys/modules/linux/Makefile === RCS file: /home/ncvs/src/sys/modules/linux/Makefile,v retrieving revision 1.24 diff -c -r1.24 Makefile *** Makefile1998/11/12 00:37:39 1.24 --- Makefile1999/01/26 20:01:52 *** *** 9,15 OBJS= linux_locore.o MAN8= linux.8 ! CFLAGS+= -DCOMPAT_LINUX #-DDEBUG EXPORT_SYMS=_linux_mod CLEANFILES+= vnode_if.h vnode_if.c linux_genassym.o linux_genassym \ linux_assym.h opt_compat.h opt_linux.h opt_vmpage.h --- 9,15 OBJS= linux_locore.o MAN8= linux.8 ! CFLAGS+= -DCOMPAT_LINUX -DVM_STACK #-DDEBUG EXPORT_SYMS=_linux_mod CLEANFILES+= vnode_if.h vnode_if.c linux_genassym.o linux_genassym \ linux_assym.h opt_compat.h opt_linux.h opt_vmpage.h
Re: HEADS UP! (kernel thread support)
On Mon, Jan 25, 1999 at 07:09:37PM -0800, Manfred Antar wrote: > At 06:41 PM 1/25/99 -0800, Julian Elischer wrote: > >The Linuxthreads changes in the system that have been optioned out for a > >while have been enabled after testing by many people. > > > >this will require a recompile of at least PS and probably the usual > >culprits, (libkvm etc) (unless of course you've already been running with > >the support turned on.) > > > >julian > > > Does this mean I can take -DCOMPAT_LINUX_THREADS out of /etc/make.conf ? Julian also committed changes so that you can take -DVM_STACK out of /etc/make.conf too, if you had it in (i386 only). -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: IDE DMA works, I'll be a...
On Mon, Jan 25, 1999 at 05:08:19PM +1100, Bruce Evans wrote:
> >> Can you find out what chipset is in this guy? There's support for anything
> >> Intel or VIA, Promise UDMA cards, Cyrix MediaGX, and Acer Aladdin IV/V
> >> right
> >> now.
> >
> >See kern/9550. The driver *used* to support my SiS chipset, but it no
> >longer does when both master and slave drive are present since I
> >updated about a week ago. Possibly the same bug is biting Matt.
>
> The driver doesn't have any special support for SiS. It uses generic
> support in some cases, apparently including your case. Recent fixes
> made it actually initialize DMA on the correct drive, but the
> initialization in generic_dmainit() is buggy (it assumes multi-word
> DMA mode 2 but your IDE timing is apparently incompatible with this).
I also experienced breakage with a SiS chip set. The following lines of
code in generic_dmainit in ide_pci.c are the problem:
/* If we're here, then this controller is most likely not set
for UDMA, even if the drive may be. Make the drive wise
up. */
if(!wdcmd(WDDMA_MDMA2, wdinfo))
printf("generic_dmainit: could not set multiword DMA
mode!\n");
You can try the attached patch if you want. It seems to work here.
--
Richard Seamman, Jr. email: d...@tar.com
5182 N. Maple Lanephone: 414-367-5450
Chenequa WI 53058 fax: 414-367-5852
Index: ide_pci.c
===
RCS file: /home/ncvs/src/sys/pci/ide_pci.c,v
retrieving revision 1.28
diff -c -r1.28 ide_pci.c
*** ide_pci.c 1999/01/17 05:46:25 1.28
--- ide_pci.c 1999/01/20 18:06:54
***
*** 110,115
--- 110,124
static void
generic_status(struct ide_pci_cookie *cookie);
+ static int
+ sis_dmainit(structide_pci_cookie *cookie,
+ struct wdparams *wp,
+ int (*wdcmd)(int, void *),
+ void*wdinfo);
+
+ static void
+ sis_status(struct ide_pci_cookie *cookie);
+
static void
via_571_status(struct ide_pci_cookie *cookie);
***
*** 279,285
/* If we're here, then this controller is most likely not set
for UDMA, even if the drive may be. Make the drive wise
up. */
!
if(!wdcmd(WDDMA_MDMA2, wdinfo))
printf("generic_dmainit: could not set multiword DMA
mode!\n");
return 1;
--- 288,294
/* If we're here, then this controller is most likely not set
for UDMA, even if the drive may be. Make the drive wise
up. */
!
if(!wdcmd(WDDMA_MDMA2, wdinfo))
printf("generic_dmainit: could not set multiword DMA
mode!\n");
return 1;
***
*** 303,308
--- 312,527
generic_status
};
+ /* SiS 5591 */
+
+ static int
+ sis_dmainit(struct ide_pci_cookie *cookie,
+ struct wdparams *wp,
+ int(*wdcmd)(int, void *),
+ void *wdinfo)
+ {
+ int r;
+ unsigned int workword, new, mask;
+ int ctlr, unit;
+ int iobase_bm;
+ pcici_t tag;
+ int unitno;
+
+ unit = cookie->unit;
+ ctlr = cookie->ctlr;
+ iobase_bm = cookie->iobase_bm;
+ tag = cookie->tag;
+
+ unitno = ctlr * 2 + unit;
+
+ if (udma_mode(wp) >= 2) {
+ workword = pci_conf_read(tag, ctlr * 4 + 0x40);
+
+ /* These settings are a little arbitrary. They're taken from my
+* system, where the BIOS has already set the values, but where
+* we don't detect that we're initialized because the
+* BMISTA_DMA?CAP values aren't set by the BIOS.
+* 0x8000 turns on UDMA
+* 0x2000 sets UDMA cycle time to 2 PCI clocks for data out
+* 0x0300 sets DATC to 3 PCI clocks
+* 0x0001 sets DRTC to 1 PCI clock
+*/
+ if (unit) {
+ mask = 0x;
+ new = 0xa301;
+ } else {
+ mask = 0x;
+ new = 0xa301;
+ }
+
+ workword &= mask;
+ workword |= new;
+
+ pci_conf_write(tag, ctlr * 4 + 0x40, workword);
+
+ outb(iobase_bm + BMISTA_PORT,
+(inb(iobase_bm + BMISTA_PORT) | ((unit == 0) ?
BMISTA_DMA0CAP : BMISTA_DMA1CAP)));
+
+ if (bootverbose)
+ printf("SiS 5591 dmainit: %s drive %d setting ultra DMA
mode 2\n",
+ unitno < 2 ? "primary" : "secondary",
+ unitno & 1);
+ r = wdcmd(WDDMA_UDMA2, wdinfo);
+ if (!r) {
+
Re: Using LinuxThreads
On Fri, Jan 22, 1999 at 02:47:53PM -0500, Alfred Perlstein wrote: > *confused look* > > somehow even though i've been trying to follow this thread i got lost. > > questions: > 1) are 'linuxthreads' enabled by defualt now? The terminology is a little confusing. There's "linuxthreads" for those running linux apps in FreeBSD using the linux emulation modules. Then, there's a port of linuxthreads to FreeBSD which runs natively, ie. no linux emulation, and gives 1-1 kernel threading to apps that link to it. Both require some options to be turned on for kernel/world builds that are not on by default. (see http://lt.tar.com) Julian Elischer has agreed to commit the patches to remove the options and make the code change permanent, when I send him the patches. I'll send him the patches as soon as I can test them after a "make world", which I'll do as soon as the libcrypt build problems are fixed. > 2) if not then 'make world -DLINUXTHREADS' ? See above. > 3) when it's decided can someone explain how to use this stuff nativly? See http://lt.tar.com . I also have some patches for squid, glib and I'm working on gimp to compile using the FreeBSD port of linuxthreads. Others have had success in varying degress with NSPR (mozilla), ACE and others. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: -D_REENTRANT (Was: Using LinuxThreads)
On Fri, Jan 22, 1999 at 09:49:23AM -0800, Kurt D. Zeilenga wrote: > "Richard Seaman, Jr." wrote: > > _THREAD_SAFE is only used in stdio.h. Looking at what's there, it could > > be rewritten to eliminate _THREAD_SAFE entirely, at a (very slight) > > performance penalty. You'd have to check __isthreaded (could be done > > once, instead of twice, as in the code now) each time you call one > > of the functions defined within the _THREAD_SAFE switch. All > > _THREAD_SAFE does is let you avoid checking __isthreaded when you're > > not threaded. > > So, if I want to produce a library which can be safely used by both > threaded and non-threaded applications I should NOT define -D_THREAD_SAFE > such that __isthreaded is always checked by the library. I guess I was a little unclear. 1) I think you would have to rewrite a little bit of the header to use the __isthreaded test on a couple of more functions. 2) If you always define -D_THREAD_SAFE, __isthreaded will be checked whether you're threaded or not. If you're not threaded, __isthreaded should be false and you avoid the file locking code. If you're threaded, __isthreaded should be true and you get the file locking (if you're linked with a library that has actualy file locking code to override the libc file locking stub functions -- libc_r does this for you, you need something like a pthreads library linked in for libc). You could also just eliminate _THREAD_SAFE entirely by letting __isthreaded get checked on each relevant call. 3) If you're linking with FreeBSD user threads, you still have the problem that user threads needs libc_r and not libc, while everything else (no threads, or kernel threads) needs libc. The _THREAD_SAFE switch doesn't affect whether you link with libc or libc_r. As mentioned before, libc_r could be rewritten to look like a "normal" libpthread addon library, ie. it wouldn't duplicate libc, but it would require some work. 4) There are portions of libc that are only thread safe when they are compiled as part of libc_r (almost all of libc gets rolled into libc_r). This can be fixed. Indeed, I have patches that do this, but they need some testing. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: -D_REENTRANT (Was: Using LinuxThreads)
On Thu, Jan 21, 1999 at 02:00:53PM -0800, Kurt D. Zeilenga wrote: > > For kernel threading you just use libc. Whether or not libc generates > > thread safe (re-entrant) calls depends on whether its also linked with > > a library that 1) sets __isthreaded to a non-zero value, 2) has a > > _spinlock() > > implementationm, and 3) implements the functions flockfile, funlockfile, > > etc. > > There are also a few macros in header files that require _THREAD_SAFE to > > be defined to be thread safe. > > > I was hoping to be able to produce one ldap library that could be safely > linked with or without threads. However, if I must define _THREAD_SAFE > to generate code to be linked with threads then I must produce two libraries > (-lfoolib compiled with -U_THREAD_SAFE and -lfoolib_r with -D_THREAD_SAFE). _THREAD_SAFE is only used in stdio.h. Looking at what's there, it could be rewritten to eliminate _THREAD_SAFE entirely, at a (very slight) performance penalty. You'd have to check __isthreaded (could be done once, instead of twice, as in the code now) each time you call one of the functions defined within the _THREAD_SAFE switch. All _THREAD_SAFE does is let you avoid checking __isthreaded when you're not threaded. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, Jan 21, 1999 at 12:38:14PM -0600, Richard Seaman, Jr. wrote: > On Thu, Jan 21, 1999 at 06:12:29PM +0200, Jeremy Lea wrote: > > > On Tue, Jan 19, 1999 at 09:11:51AM -0600, Richard Seaman, Jr. wrote: > > > Actually, the new version, in FreeBSD "ports" form, doesn't require > > > -DLINUXTHREADS anymore, but it does require -I/usr/local/include to > > > pick up the right header, since it installs a pthread.h into > > > /usr/local/include. This conflicts with the pthread.h in /usr/include. > > > > This is nagging at me. Having two headers of the same name, but importantly > > different content is asking for touble. There needs to be a way to ensure > > that only one or the other is picked up. The best way I can think of is to > > only include the contents of the user thread pthread.h if _THREAD_SAFE is > > defined (to force people to use the right defines...) and the contents of > > kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. > > This has the added bonus of meaning that most linux apps wont have to be > > patched. > Now, on the topic of conflicting pthread.h files, I agree this is a > problem. One choice, which I originally implemented, is to fix > pthread.h so it pulls in the right data based on a swtich (eg. > if LINUXTHREADS is defined, pull in LT headers, else pull in > user threads headers). I don't like using _THREAD_SAFE for this > test, for the reason mentioned above. And I don't like using > _REENTRANT because its so widely used and it could still confure > people. > > The second choice, which is what the current version of the "port" > does, is to put the conflicting headers in different directories, > and require the application to define the order of the include > files to get the right one in. > > There are proglems either way, and I don't really prefer one > over the other. Upon further investigation, I'm not sure I agree with myself on this point anymore. I've been trying to get gimp compiled to look into the reported problem Brian Litzinger had. I notice that glib, gtk+ (both needed for gimp) and gimp itself generate include search paths that include /usr/local/include, which means that the linuxthreads pthread.h will get picked up even if the user wants the uthread version in /usr/include. Maybe having just one pthread.h that pulls in the required headers based on a switch (eg. -DLINUXTHREADS) is the way to go? -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, Jan 21, 1999 at 07:39:28PM -0700, Russell L. Carter wrote:
> d...@tar.com said:
> %libc_r could be modified so that is doesn't replace libc, but rather
> %is an addon, comparable to the kernel threaded libc case. But, it
> %would involve a bit of work.
>
> I thought so at first, but then I had to look at wait4 today and
> now I'm not so sure. At least some of libc_r is very closely
> tied to the uthread scheduler:
Sure it is. But, I don't see why that prevents the possibility of leaving
libc in place and having libc_r just be an add on (not that I'm advocating
this). Taking your example, in libc the syscall is implemented as _wait4,
and wait4 is a weak alias to _wait4. If you replaced _thread_sys_wait4
below with _wait4 instead, and put the resulting code in a library separate
from libc (eg. in a "new" libc_r) along with the uthread scheduling code
and the rest of the uthread pthread code, you could leave libc alone.
Then, when you linked with libc and libc_r together, the wait4 in libc_r
would override the weak aliased wait4 in libc. If you didn't link with
libc_r, you'd have your plain old wait4.
The bigger problem is that the uthread code needs "two layer" aliasing
in order to implement pthread cancellation.
> pid_t
> wait4(pid_t pid, int *istat, int options, struct rusage * rusage)
> {
> pid_t ret;
>
> /* Perform a non-blocking wait4 syscall: */
> while ((ret = _thread_sys_wait4(pid, istat, options | WNOHANG,
> rusage)) == 0 && (options & WNOHANG) == 0) {
> /* Reset the interrupted operation flag: */
> _thread_run->interrupted = 0;
>
> /* Schedule the next thread while this one waits: */
> _thread_kern_sched_state(PS_WAIT_WAIT, __FILE__, __LINE__);
>
> /* Check if this call was interrupted by a signal: */
> if (_thread_run->interrupted) {
> errno = EINTR;
> ret = -1;
> break;
> }
> }
> return (ret);
> }
> #endif
--
Richard Seamman, Jr. email: d...@tar.com
5182 N. Maple Lanephone: 414-367-5450
Chenequa WI 53058 fax: 414-367-5852
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, Jan 21, 1999 at 11:42:14AM -0800, Kurt D. Zeilenga wrote: > >This is nagging at me. Having two headers of the same name, but importantly > >different content is asking for touble. There needs to be a way to ensure > >that only one or the other is picked up. The best way I can think of is to > >only include the contents of the user thread pthread.h if _THREAD_SAFE is > >defined (to force people to use the right defines...) and the contents of > >kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. > >This has the added bonus of meaning that most linux apps wont have to be > >patched. > > Of course, this would only work if the contents of the two pthread.h files > were merged. I'm not sure this is a good idea. I'm not advocating any changes. But, IMO the best way to do it, if you did, wouldn't be to merge the files, but rather to re-implemnt pthread.h like: #ifdef LINUXTHREADS #include <..pointer to lt pthread.h file..> #else #include <..pointer to user thread pthread.h file..> #endif > If you did this, do NOT use -D_REENTRANT or -D_THREAD_SAFE as the conditional > to determine the content. Use -DLINUXTHREADS or something. Right. > BTW, why does FreeBSD use -D_THREAD_SAFE AND -D_REENTRANT (math.h) > while most other PThread (final) implementations use -D_REENTRANT? Don't know. Using _REENTRANT would be preferable, IMO. > > Also, the cc(1) says to use -D_THREADSAFE not -D_THREAD_SAFE. Hmm. Not on my machine. :) > Personallly, I think -DREENTRANT should be used for include all prototypes > for reentrant functions not requiring thread support (like strtok_r) and > -D_THREAD_SAFE routines only implemented in -lc_r. I think _THREAD_SAFE should be used as a switch when compiling libc/libc_r to turn on libc_r specific options, which is how it is primarily used now. _REENTRANT should be used in all libc/libc_r and system headers to turn on generic thread safe options. > If possible, functions > should be implemented in both -lc and -lc_r such that 3rd party libraries > wouldn't have to create both a -lfoolib vs. -lfoolib_r versions (unless > their _r versions requires threading). For kernel threading you just use libc. Whether or not libc generates thread safe (re-entrant) calls depends on whether its also linked with a library that 1) sets __isthreaded to a non-zero value, 2) has a _spinlock() implementationm, and 3) implements the functions flockfile, funlockfile, etc. There are also a few macros in header files that require _THREAD_SAFE to be defined to be thread safe. libc_r could be modified so that is doesn't replace libc, but rather is an addon, comparable to the kernel threaded libc case. But, it would involve a bit of work. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, Jan 21, 1999 at 11:04:38AM -0800, Julian Elischer wrote: > > > On Thu, 21 Jan 1999, Richard Seaman, Jr. wrote: > > > > And when are COMPAT_LINUX_THREADS and VM_STACK going away? > > > > I have no idea. I was hoping that at least COMPAT_LINUX_THREADS > > would go away before the branch. I don't have commit authority, > > so it isn't up to me. > > > > hmm did you send me the patches? No. You said you wanted Peter to do it. I offered to send patches upon request, but never got a request. :) > > I can certainly do it now..(given a patch set to apply) Ok. I'll send it. Do you want VM_STACK out too? > I just realised however, that if we make them go away we break > SMP right? No. I don't think the patches affect SMP one way or the other. If someone tries to run kernel threads of any kind (linuxthreads in emulation, linuxthread in FreeBSD native, any other kernel threads implementation that uses rfork with RFMEM) rfork will fail, with or without the patches (unless you apply Luoqi Chen's pmap patches). I see no reason the patches shouldn't work with SMP when rfork gets fixed, but I haven't tried it. > hmm I guess we only break it for programs that woudltry use it > which should be none if you run SMP :-) See above. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Using LinuxThreads
On Thu, Jan 21, 1999 at 06:12:29PM +0200, Jeremy Lea wrote: > On Tue, Jan 19, 1999 at 09:11:51AM -0600, Richard Seaman, Jr. wrote: > > Actually, the new version, in FreeBSD "ports" form, doesn't require > > -DLINUXTHREADS anymore, but it does require -I/usr/local/include to > > pick up the right header, since it installs a pthread.h into > > /usr/local/include. This conflicts with the pthread.h in /usr/include. > > This is nagging at me. Having two headers of the same name, but importantly > different content is asking for touble. There needs to be a way to ensure > that only one or the other is picked up. The best way I can think of is to > only include the contents of the user thread pthread.h if _THREAD_SAFE is > defined (to force people to use the right defines...) and the contents of > kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. > This has the added bonus of meaning that most linux apps wont have to be > patched. Actually, its more complicated than this. Currently, _THREAD_SAFE is a switch for turning on libc_r behaviour when compiling libc_r, but it is a switch for more general thread safe behaviour in the header files for libc and libc_r. In other words, threaded applications linking against either libc or libc_r should define _THREAD_SAFE. But, when compiling libc, _THREAD_SAFE should be turned off. Very confusing IMHO. Now, on the topic of conflicting pthread.h files, I agree this is a problem. One choice, which I originally implemented, is to fix pthread.h so it pulls in the right data based on a swtich (eg. if LINUXTHREADS is defined, pull in LT headers, else pull in user threads headers). I don't like using _THREAD_SAFE for this test, for the reason mentioned above. And I don't like using _REENTRANT because its so widely used and it could still confure people. The second choice, which is what the current version of the "port" does, is to put the conflicting headers in different directories, and require the application to define the order of the include files to get the right one in. There are proglems either way, and I don't really prefer one over the other. > To many applications have configure scripts which might find > /usr/local/lib/libpthread, but not /usr/local/include/pthread.h, or find > /usr/lib/libc_r and find /usr/local/include/pthread.h. Yes. This is a problem. But, taking glib as an example, and using glib-1.1.13 directly (not the "port", which is kind of messed up for linuxthreads), the following configure script does the right thing: $ CPPFLAGS="-D_THREAD_SAFE -I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure --with-threads=posix This isn't that bad, and I think you need to customize your configure scripts (normally) if you're using threads, anyway. > What are the plans for the import of the LinuxThreads stuff into the src > tree? Or is it going to remain a port, and the source tree position be > reserved for a future kernel threads implementation? My mind says it is to > closely tied to the OS to be a port. It can be a port. I suspect there will be more support for its possible inclusion this way. The current version at lt.tar.com is in ports form. Granted, it depends to an unusual degree (for a port) on having the src tree around. > And when are COMPAT_LINUX_THREADS and VM_STACK going away? I have no idea. I was hoping that at least COMPAT_LINUX_THREADS would go away before the branch. I don't have commit authority, so it isn't up to me. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: linuxthreads, gimp 1.1+, dies
On Tue, Jan 19, 1999 at 02:06:13PM +0200, Jeremy Lea wrote: > On Tue, Jan 19, 1999 at 02:45:39AM -0800, br...@worldcontrol.com wrote: > > Gimp (CVS) compiled with > > CFLAGS="-g -D_THREAD_SAFE -I/usr/local/include -L/usr/local/lib -O2 -m486 > > -pipe -lpthread" > > Hmm, if you're using the libpthread from lt.tar.com, and you installed it > according to the instructions, then that should read: > > > CFLAGS="-g -D_THREAD_SAFE -DLINUXTHREADS -I/usr/local/include > > --L/usr/local/lib -O2 -m486 pipe -lpthread" > > So it picks up the correct header. But I doubt you would have got it > compiled without that? Actually, the new version, in FreeBSD "ports" form, doesn't require -DLINUXTHREADS anymore, but it does require -I/usr/local/include to pick up the right header, since it installs a pthread.h into /usr/local/include. This conflicts with the pthread.h in /usr/include. > Also, are you using glib11-devel/gtk11-devel ports > linked against libpthread? By default the ports link against libc_r. Right. > Also, the linuxthreads stuff needs libc to be reentrant, from what I > understand, and Richard hasn't released (or finished) those patches yet. libc is partly re-entrant, partly not. It depends on what calls you're making. As a rule of thumb, wherever the pthread spec calls for a "_r" function (eg. readdir_r), the underlying function is not thread safe, and either the "_r" function is missing or is not threadsafe itself (eg. localtime_r exists in libc -- recent versions -- but is not thread safe). strrok_r is an exception, I think. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: linuxthreads, gimp 1.1+, dies
On Mon, Jan 18, 1999 at 06:27:18PM -0800, br...@worldcontrol.com wrote: > I running gimp -unstable (CVS 1/17/1998) and FreeBSD -current > (1/17/1998) with > > CFLAGS= -O2 -m486 -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK > COPTFLAGS= -O -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK > > and linuxthreads port from http://lt.tar.com. > > recompiled glib, gtk+ and gimp which works fine reasonably > well without threads. > > with threads > CFLAGS="-D_THREAD_SAFE -I/usr/local/include -L/usr/local/lib -O2 -m486 -pipe > -lpthread" > > Everything compiles and it runs. However, various operations crash > for example: Thanks for the report. I'll look into it, though it may be a day or two before I can get to it. One question, I assume you compiled glib and gtk+ with linuxthreads also? If so, can you send me the makefile (and any other) mods you made to do the compile? Thanks. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
