iso target in release/Makefile
H. I'm not sure why this reinvents a lot of the wheel in the already existing iso.1 target. Could you explain its purpose a little better as well as why you didn't simply conditionalize the iso.1 target in some way if it didn't currently suit? As it is, we have two targets now and that doesn't make much sense, to say nothing of the asthetics. Thanks. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libss termination
Mark Murray [EMAIL PROTECTED] wrote: MM MM As far as I can tell, there's nothing in the tree which uses libss any MM longer, and hasnt been for quite some time. Is there any reason to MM keep it? MM MM Nope. MM Right. Kill it. Usr.bin/mk_cmds is still using libss. And buildworld fails. === usr.bin/mk_cmds yacc -d /usr/src/usr.bin/mk_cmds/ct.y cp y.tab.c ct.c lex -t -l /usr/src/usr.bin/mk_cmds/cmd_tbl.l cmd_tbl.c rm -f .depend mkdep -f .depend -a -nostdinc -I. -I/usr/src/usr.bin/mk_cmds/../../lib/libss -DIN_MK_CMDS -I/usr/obj/usr/src/i386/usr/include /usr/src/usr.bin/mk_cmds/mk_cmds.c /usr/src/usr.bin/mk_cmds/options.c /usr/src/usr.bin/mk_cmds/utils.c ct.c cmd_tbl.c /usr/src/usr.bin/mk_cmds/mk_cmds.c:16: ss_internal.h: No such file or directory /usr/src/usr.bin/mk_cmds/options.c:8: ss.h: No such file or directory /usr/src/usr.bin/mk_cmds/utils.c:9: ss_internal.h: No such file or directory /usr/src/usr.bin/mk_cmds/ct.y:30: ss.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.bin/mk_cmds. -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libss termination
On Mon, Aug 20, 2001 at 04:28:07PM +0900, NAKAJI Hiroyuki wrote: Mark Murray [EMAIL PROTECTED] wrote: MM MM As far as I can tell, there's nothing in the tree which uses libss any MM longer, and hasnt been for quite some time. Is there any reason to MM keep it? MM MM Nope. MM Right. Kill it. Usr.bin/mk_cmds is still using libss. And buildworld fails. Thanks; I fixed this already (by removing mk_cmds too :-) Kris PGP signature
Re: libss termination
In [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] wrote: nakaji Usr.bin/mk_cmds is still using libss. And buildworld fails. Kris Thanks; I fixed this already (by removing mk_cmds too :-) Oops... I should have checked http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.bin/mk_cmds/ first. Thanks. -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: no new snapshotonftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/
wosch Sorry, my fault.
Never mind :-)
wosch Nevertheless, current sucks. No successfully builds since 9 days ;-{{
I've checked the original CVS code. It seems that
URL:http://ccvs.cvshome.org/source/browse/ccvs/src/client.c.diff?r1=1.302r2=1.303
will fix our problem (sorry I don't test it).
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
It seems Jim Bryant wrote: Yups, reverting this, even in a newer kernel makes sound work again, well the VIA support is still not sounding proberly, but it didn't before as well so thats not related to this bogon... Perhaps the bug in the chipset^wPCI-spec? I dont think so, before the latest changes it worked just fine... What's the problem? I didn't noticed anything. It seems that there is either a slight pause, or random noise between each DMA buffer played... -Søren Was this chipset or motherboard-dependant? That particualar problem is dependend on the VIA 82c686[ab] I'd say, but having no other sound HW right now, I really cant tell, I think I've seen other sound HW with this problem too lately on the lists... Like I said, I had no problems running SMP and with a SB/Live!-Value... Current as of yesterday morning [6-7AMish CDT], Tyan S1696DLUA motherboard, 2 Pentium-II/333's, SB/Live! Value card. Did not produce thse issues. I'm pretty sure the problem with no sound due to jhb's commit mentioned earlier hoses more than just the VIA chips... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
On 19 Aug, Søren Schmidt wrote: What's the problem? I didn't noticed anything. It seems that there is either a slight pause, or random noise between each DMA buffer played... Verry strange... with a normal Aug 18 kernel and the VIA chipset I'm able to listen to xmms-played audio without noticing anything I didn't like (except there slipped in a song into the playlist I didn't like ;-)). Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Syntax change in ppp?
Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? I have an idea which might cause the accidential removal of the defaultroute after redialing: Before the first connection I have to set a dummy IP pair: set ifaddr 172.23.11.1/0 172.23.11.2/0 255.255.255.255 0.0.0.0 so my defaulroute will be set to 172.23.11.2 After dialing I'm getting a different destination IP address from my provider, and the old route will be deleted: route del $OLDADDR But after that, even if my own address will be different, the destination address will be the same: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1492 inet6 fe80::2e0:7dff:fe75:fdfb%tun0 prefixlen 64 scopeid 0x6 inet 217.224.28.71 -- 217.5.98.90 netmask 0x inet 217.224.27.153 -- 217.5.98.90 netmask 0x so after executing iface clear from /etc/ppp/ppp.linkup, ppp will also delete the old route - but this time the old route is the same as the current one. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
SÜren Schmidt wrote: It seems Jim Bryant wrote: Yups, reverting this, even in a newer kernel makes sound work again, well the VIA support is still not sounding proberly, but it didn't before as well so thats not related to this bogon... Perhaps the bug in the chipset^wPCI-spec? I dont think so, before the latest changes it worked just fine... What's the problem? I didn't noticed anything. It seems that there is either a slight pause, or random noise between each DMA buffer played... -SÜren Was this chipset or motherboard-dependant? That particualar problem is dependend on the VIA 82c686[ab] I'd say, but having no other sound HW right now, I really cant tell, I think I've seen other sound HW with this problem too lately on the lists... Like I said, I had no problems running SMP and with a SB/Live!-Value... Current as of yesterday morning [6-7AMish CDT], Tyan S1696DLUA motherboard, 2 Pentium-II/333's, SB/Live! Value card. Did not produce thse issues. I'm pretty sure the problem with no sound due to jhb's commit mentioned earlier hoses more than just the VIA chips... Yes, as I reported my OPL3-SA sound card was also affected by the same commit, so it is certainly not a VIA-specific. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Disk I/O problems with -current.
I'm having strange problems with -current on a laptop with 64mb of memory. Periodically things go strange [tm]. Because of the lack of memory I'm using a fair amount of swap. Everything runs smoothly up until a point, which seems to depend upon not running too many large processes for too long. Then the file system grinds to a halt for seconds at a time. Some processes run, and others just hang. Here's a snapshot from top: last pid: 1861; load averages: 1.58, 1.63, 1.26up 0+00:43:56 09:58:09 39 processes: 1 running, 38 sleeping CPU states: 1.2% user, 0.0% nice, 8.1% system, 5.8% interrupt, 84.9% idle Mem: 14M Active, 2712K Inact, 21M Wired, 1460K Cache, 14M Buf, 20M Free Swap: 512M Total, 16M Used, 496M Free, 3% Inuse PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 594 root 960 23300K 10784K select 0:12 0.00% 0.00% XFree86 1731 joe -80 6056K 3352K biowr0:14 5.08% 5.08% vim 691 joe 960 4092K 1804K select 0:02 0.00% 0.00% wmaker 1719 joe80 3340K 1864K wait 0:00 0.00% 0.00% mutt 658 root 80 2964K 908K wait 0:00 0.00% 0.00% xdm 591 root 200 2800K 632K pause0:00 0.00% 0.00% xdm 279 root 960 2364K 480K select 0:00 0.00% 0.00% sshd 724 joe80 2324K 740K nanslp 0:01 0.00% 0.00% wmCalClock 1209 joe 960 2292K 1168K select 0:01 0.10% 0.10% rxvt 1716 joe 960 2256K 1348K select 0:00 0.00% 0.00% rxvt 1214 joe 200 2088K 1188K pause0:00 0.00% 0.00% zsh 725 joe80 2060K 824K nanslp 0:10 0.00% 0.00% wmtop 1401 joe 960 2028K 888K RUN 0:02 0.00% 0.00% top 1812 joe -120 2012K 768K inode0:01 0.00% 0.00% rxvt 700 joe80 1988K 840K nanslp 0:00 0.00% 0.00% xautolock 701 joe 960 1828K 492K select 0:00 0.00% 0.00% ssh-agent 253 root 84 -12 1388K 564K select 0:00 0.00% 0.00% ntpd 1779 root 960 1232K 760K select 0:00 0.00% 0.00% local 1777 postfix 960 1228K 820K select 0:00 0.00% 0.00% smtpd 649 postfix 960 1204K 656K select 0:01 0.00% 0.00% qmgr 1778 postfix 960 1196K 760K select 0:00 0.00% 0.00% cleanup 271 root 960 1184K 416K select 0:00 0.00% 0.00% inetd 1700 postfix 960 1152K 676K select 0:00 0.00% 0.00% trivial-rewri 648 root 960 1144K 496K select 0:00 0.00% 0.00% pickup 647 root 960 1120K 528K select 0:00 0.00% 0.00% master 273 root 80 1108K 548K nanslp 0:00 0.00% 0.00% cron 276 root 960 1076K 388K select 0:00 0.00% 0.00% lpd 583 root 50 1064K 396K ttyin0:00 0.00% 0.00% getty 588 root 50 1064K 396K ttyin0:00 0.00% 0.00% getty 585 root 50 1064K 396K ttyin0:00 0.00% 0.00% getty 590 root 50 1064K 396K ttyin0:00 0.00% 0.00% getty 586 root 50 1064K 396K ttyin0:00 0.00% 0.00% getty 587 root 50 1064K 396K ttyin0:00 0.00% 0.00% getty 589 root 50 1064K 396K ttyin0:00 0.00% 0.00% getty 584 root 50 1064K 396K ttyin0:00 0.00% 0.00% getty 243 root 960 1060K 492K select 0:00 0.00% 0.00% syslogd 341 root 960 1024K 388K select 0:00 0.00% 0.00% usbd 397 root 960 1020K 400K select 0:03 0.00% 0.00% moused 1730 joe80 816K 156K wait 0:00 0.00% 0.00% sh The vim process (pid=1731) was waiting in biowr for about a minute when I took this snapshot. I'd ZZ'd it, but instead of writing it's file, it just blocked instead. Interestingly take a look at the disk i/o irqs: 2 usersLoad 1.21 1.49 1.24 Aug 20 09:59 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act8368164829620 2824 21312 count All 404721952 2567408 4908 pages Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow1966 total 2 10 7194 15 1038 2031 13 17 21612 wirestray irq0 14404 act stray irq6 7.5%Sys 5.3%Intr 1.2%User 0.0%Nice 86.0%Idl 2984 inact acpi0 irq9 |||||||||| 1472 cache 1697 ata0 irq14 ++ 19840 freeata1 irq15 daefr uhci0 irq5 Namei Name-cacheDir-cache prcfr 1 pcm0 irq5 Calls hits% hits% react atkbd0 irq 504 504
Re: Syntax change in ppp?
Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. I have an idea which might cause the accidential removal of the defaultroute after redialing: Before the first connection I have to set a dummy IP pair: set ifaddr 172.23.11.1/0 172.23.11.2/0 255.255.255.255 0.0.0.0 so my defaulroute will be set to 172.23.11.2 After dialing I'm getting a different destination IP address from my provider, and the old route will be deleted: route del $OLDADDR But after that, even if my own address will be different, the destination address will be the same: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1492 inet6 fe80::2e0:7dff:fe75:fdfb%tun0 prefixlen 64 scopeid 0x6 inet 217.224.28.71 -- 217.5.98.90 netmask 0x inet 217.224.27.153 -- 217.5.98.90 netmask 0x so after executing iface clear from /etc/ppp/ppp.linkup, ppp will also delete the old route - but this time the old route is the same as the current one. When IPCP comes up, ppp adds the new address to the interface. It's *meant* to change the old interface destination address to 255.255.255.255, but is getting this wrong. Then, as you've already spotted, when your ``iface clear'' is run, it blows away the default route. I've just committed a fix for this. It's in version 1.25 of iface.c. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Yep, a fix for that was committed a few days ago too. My apologies. Daniel -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mailing list problem because of DNS
On Sat, Aug 18, 2001 at 05:18:55PM -0400, Buzz Megg wrote: I'm getting an error when attempting to send to [EMAIL PROTECTED] from an address that used to work. Has anything changed recently on the mailing list server? Not that I know of. But you should fix the named problem anyway: ticso@cicely6# host -a 216.12.228.198 rcode = 3 (Non-existent domain), ancount=0 Host not found. Exit 1 It looks like the complete 216.in-addr.arpa is not known by the root servers - which is bad. Your provider should contact ARIN to setup a functional reverse mapping. - Transcript of session follows - ... while talking to hub.freebsd.org.: RCPT To:[EMAIL PROTECTED] 450 Client host rejected: cannot find your hostname, [216.12.228.198] [EMAIL PROTECTED]... Deferred: 450 Client host rejected: cannot find your hostname, [216.12.228.198] Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pam_unix: look and maybe commit bin/29897 please
I was reading login.conf(5) and testing capabilities, when i found this bug. And one-two more questions. How should i mark such reports in the future? Where can I find more info on named accounting limits on login.conf(5) manpage? Maybe i would be able to implement them as PAM modules. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
On Mon, Aug 20, 2001 at 02:05:06AM -0400, Brandon D. Valentine wrote: On Sun, 19 Aug 2001, Kris Kennaway wrote: Devices are just inodes..you shouldn't have anything in /dev other than MAKEDEV, the fd/ subdirectory and a whole bunch of device nodes. You probably have some other file in there which was accidentally created by something like # verbosecommand /dev/nlul The following command should reveal the culprit: du -h /dev/* | grep -v 0B The only problem is devfs is mounted and I can't seem to get around that. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Implications of stdio changes (was Re: cvs commit: src/include stdio.h src/lib/libc Makefilesrc/lib)
On Tuesday, 14th August 2001, Daniel Eischen wrote: So do we allow FILE to be extended only after bumping the library version once (after 5.0-release)? And thereafter all extensions to FILE do not need a version bump? We've already bumped libc for 5.x. Assuming this works ok, we shouldn't need any further bumps for extending FILE. True. I guess the real problem is the other libraries that reference stdin, stdout, stderr. These need to be rebuilt with the new stdio.h and libc in order to avoid any impact from future FILE changes. I might sound like the harbinger of doom, but you have to bump the major number on every library that uses stdio to solve the FILE has changed size problem. It's the same sort of problem that changing errno caused. That was solved by the switch to elf, which caused global recompilation. People are hoping to do this by just waiting. Eventually most libraries will experience a major version bump. Similarly, most useful programs will be recompiled (either against bumped libraries, or recompiled old ones). But some programs will not be recompiled, and will fail in mysterious ways. I often use really old binaries, so odds are it will happen to me. :-) To prevent old binaries from going bad, the libraries they link to must use the old version of stdio. Definite ideas of the offset in __sF of stdout and stderr are embeded in both the old programs, and the old libraries (and of course, the old version of stdio). If you recompile the libraries against the new stdio, you break the old binaries. The solution is to not do that. In short, when FILE changes size (and hence __sF offsets change), then every consumer(*) of stdio must be bumped. The recent __stdinp (and friends) addition prevents this problem happening again in the future, but does not solve the current problem of old binaries and old libraries knowing the internals of stdio. Stephen. (*) OK, technically only uses of stdout and stderr variables screw up when FILE changes size. Uses of macros (like getc variants that are sometimes macros) will screw up if offsets change, but that's easier to avoid. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: The only problem is devfs is mounted and I can't seem to get around that. I haven't had much time lately to fool with my -CURRENT box but it seems that booting singleuser oughta help? -- Never put off until tomorrow what you can do today. There might be a law against it by that time. -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine bandix at looksharp.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
At 11:17 AM 8/20/2001 -0400, Brandon D. Valentine wrote: On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: The only problem is devfs is mounted and I can't seem to get around that. I haven't had much time lately to fool with my -CURRENT box but it seems that booting singleuser oughta help? -- Never put off until tomorrow what you can do today. There might be a law against it by that time. -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine bandix at looksharp.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message I couldn't do this from single user. I forget the error somthing about moving a mount point. What worked for me was to boot off the CDROM and go into the fixit mode then mount the / partition on /mnt. cd /mnt/dev/ rm -r * Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
On Mon, Aug 20, 2001 at 11:17:42AM -0400, Brandon D. Valentine wrote: On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: The only problem is devfs is mounted and I can't seem to get around that. I haven't had much time lately to fool with my -CURRENT box but it seems that booting singleuser oughta help? Already tried that, still mounts devfs immediately. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
Hmm- this is because init gets the 'd' argument if devfs is linked into the kernel with the variable 'devfs_present' set. Isn't there a way for the loader to dork with this? On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: On Mon, Aug 20, 2001 at 11:17:42AM -0400, Brandon D. Valentine wrote: On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: The only problem is devfs is mounted and I can't seem to get around that. I haven't had much time lately to fool with my -CURRENT box but it seems that booting singleuser oughta help? Already tried that, still mounts devfs immediately. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sharing disk between current and stable?
Is it safe to share a disk between -current and -stable these days? I've been away from freebsd for the last few months and have a fuzzy recollection that something about the on-disk superblock structure changed in -current earlier this summer (related to dirprefs?) and fsck on -stable wouldn't be able to fsck a fs used by current. Is that still a problem? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sharing disk between current and stable?
On Mon, Aug 20, 2001 at 01:09:12PM -0400, Andrew Gallatin wrote: Is it safe to share a disk between -current and -stable these days? I've been away from freebsd for the last few months and have a fuzzy recollection that something about the on-disk superblock structure changed in -current earlier this summer (related to dirprefs?) and fsck on -stable wouldn't be able to fsck a fs used by current. Is that still a problem? When I reverted to -stable, I had fsck come up with a long list of complaints about snapshot files which should have been deleted long ago. Probably they were caused by a failed background fsck under -current (I had an unexpected softupdates inconsistency on the partition due to a kernel panic, and background fsck would just wedge the entire machine when trying to deal with it). However, I don't know why they weren't dealt with by fsck under -current. Kris PGP signature
Copyright Contradiction in libalias
I was doing some things in libalias when something caught my eye, $ cat alias.c /* -*- mode: c; tab-width: 8; c-basic-indent: 4; -*- */ /*- * Copyright (c) 2001 Charles Mott [EMAIL PROTECTED] * All rights reserved. * [snip usual BSD licence legalese and comments about the code.] This software is placed into the public domain with no restrictions on its distribution. This is contained in several files in there. This is a contradiction. Public domain software can't also have copyright notices and a bunch of license disclaimers. The BSD-style copyright header was added back in June. You can't just take something in the public domain and slap a copyright on it, but IANAL. Still, the comments in the code as written are self-contradictory. It can't have a BSD-license _and_ be public domain. And since again IANAL, I am not saying which needs to stay or which needs to go, but one of those statements does. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: iso target in release/Makefile
From: David O'Brien [EMAIL PROTECTED] Subject: Re: iso target in release/Makefile Date: Mon, 20 Aug 2001 14:06:34 -0700 It is part of a patch set I sent you for review. And that patch looks good - please commit it and then merge the resulting changes into RELENG_4 if you get the chance. Thanks! - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
On 19-Aug-01 Maxim Sobolev wrote: On Sat, 18 Aug 2001 21:10:40 -0500, Daniel M . Kurry wrote: On Wed, Aug 15, 2001 at 07:01:46PM +0200, some SMTP stream spewed forth: One gets the first DMA buffer full, then the process hangs... Due to the lack of replies, I'll go ahead. I am seeing sound breakage also. My card is a Creative Labs SoundBlaster Live!. xmms will play a short (less than a second) spurt of audio and then stop responding. mpg123 will not play (any audio to the speakers) at all. I ran a buildworld today which apparently broke it. That puts the breakage between today and sometime less than 2 months ago. (I really cannot be more specific.) Suggestions gladly welcomed. -Søren The same is here (OPL3-SA driver on Toshiba Satellite Pro 445CDX notebook). I found that after reverting the following deltas (jhb's 10 August commit) sound starts working again: That's a rather large commit. Is this the ast() fixup? Is the process that has the sound device open hung? Is it stuck in a wait channel? If so, can you do a ps and find the wait channel? Is it chewing up large amounts of CPU time? Has it exited with a signal? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sharing disk between current and stable?
From: Andrew Gallatin [EMAIL PROTECTED] Date: Mon, 20 Aug 2001 13:09:12 -0400 (EDT) Is it safe to share a disk between -current and -stable these days? I've ben doing in since about the 2nd week of March, tracking -STABLE -CURRENT daily (with a few exceptions; sometimes I couldn't build -CURRENT for as much as a day). I've been away from freebsd for the last few months and have a fuzzy recollection that something about the on-disk superblock structure changed in -current earlier this summer (related to dirprefs?) and fsck on -stable wouldn't be able to fsck a fs used by current. Is that still a problem? It doesn't seem to be a problem for me. YMMV; void where prohibited, taxed, or otherwise restricted, etc. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
On 19-Aug-01 Richard Todd wrote: In servalan.mailinglist.fbsd-current Maxim Sobolev writes: I found that after reverting the following deltas (jhb's 10 August commit) sound starts working again: [list of deltas deleted] I found much the same thing; specifically, the problematic change is this one: What wait channel is the process (xmms, mpg123, whatever) in? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: iso target in release/Makefile
On Sun, Aug 19, 2001 at 11:51:31PM -0700, Jordan Hubbard wrote: H. I'm not sure why this reinvents a lot of the wheel in the already existing iso.1 target. Could you explain its purpose a little better as well as why you didn't simply conditionalize the iso.1 target in some way if it didn't currently suit? You didn't MFC the iso.1 target. We are all building releases on RELENG_4 right now :-) (-current releases have been broken for quite a while). Thus my patch was developed on RELENG_4 and only committed to current so I could as the RE about MFC'ing it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs
On Mon, Aug 20, 2001 at 08:02:44AM -0500, David W. Chapman Jr. wrote: On Mon, Aug 20, 2001 at 02:05:06AM -0400, Brandon D. Valentine wrote: On Sun, 19 Aug 2001, Kris Kennaway wrote: Devices are just inodes..you shouldn't have anything in /dev other than MAKEDEV, the fd/ subdirectory and a whole bunch of device nodes. You probably have some other file in there which was accidentally created by something like # verbosecommand /dev/nlul The following command should reveal the culprit: du -h /dev/* | grep -v 0B The only problem is devfs is mounted and I can't seem to get around that. Boot single-user. Kris PGP signature
Re: iso target in release/Makefile
From: David O'Brien [EMAIL PROTECTED] Subject: Re: iso target in release/Makefile Date: Mon, 20 Aug 2001 11:43:16 -0700 You didn't MFC the iso.1 target. We are all building releases on RELENG_4 right now :-) (-current releases have been broken for quite a while). Thus my patch was developed on RELENG_4 and only committed to current so I could as the RE about MFC'ing it. Uh, no offense, but that explanation makes absolutely NO sense whatsoever! If you'd developed something independently in RELENG_4 and only considered it applicable to that branch, then it would NOT go into -current for obvious reasons, especially if it was a duplication of something already there. What you'd do instead is either commit it only to RELENG_4 (and there is some precedent for that) or you'd ask for an MFC of the feature which was already in -current. Please back this out, it's ugly and wrong. Thanks! I'll be happy to MFC the pre-existing stuff if such is wanted. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: iso target in release/Makefile
On Mon, Aug 20, 2001 at 01:15:20PM -0700, Jordan Hubbard wrote: You didn't MFC the iso.1 target. We are all building releases on RELENG_4 right now :-) (-current releases have been broken for quite a while). Thus my patch was developed on RELENG_4 and only committed to current so I could as the RE about MFC'ing it. Uh, no offense, but that explanation makes absolutely NO sense whatsoever! If you'd developed something independently in RELENG_4 and only considered it applicable to that branch, then it would NOT go into -current for obvious reasons, especially if it was a duplication of something already there. Damned if you do, damned if you don't. I've asked you about putting stuff into RELENG_4 before and you said to put it in -current and then immediately MFC it so people wouldn't complain that it didn't go thru current. (I also didn't consider it applicable only to that branch) What you'd do instead is either commit it only to RELENG_4 (and there is some precedent for that) or you'd ask for an MFC of the feature which was already in -current. I didn't know about the feature in current (nor did those on the Alpha list that were asking how to make ISOs). Please back this out, it's ugly and wrong. It is part of a patch set I sent you for review. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syntax change in ppp?
Brian Somers schrieb: Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). Suppose on the first connection I got the IP pair A - B and on the second C - D while the second one still active another person will get A - B assigned by our ISP. Will I be able to talk with A or B? Or will they point back to myself? I put the iface clear in ppp.linkup for exactly this case. Say for example that you do ``set ifaddr A B'' and then ``telnet X'' when the link is down. telnet does a connect(X), resulting in a local binding to address A with a destination address of X. ppp brings the link up and negotiates C -- D, but keeps A -- B on the interface. The initial ``telnet X'' packet (A -- X) can now be transmitted, but ppp's alias address is now C. It NATs the packet to C -- X and sends it out. X gets it and sends a packet back to C. Your ISP routes to C correctly and your ppp process unNATs it back to A. Thus your ``first connection'' works when in reality it should not. If you ``iface clear'' on linkup, ppp doesn't NAT the A -- X packet and X replies to A -- which your ISP (of course) can't route. So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. Hmm, I didn't notice any problems before the last commit... Any automatic connection (even the first) worked without any problems. That may be because most connections consist of a DNS lookup followed by the connect... but I'm not sure about that. But: iface clear just went from ppp.linkdown to ppp.linkup some weeks ago, but after I got DSL. With DSL the destination IP address is always the same. I don't know if this configuration would work with my old ISDN access with changing destination IP addresses. It should work ok now. Adding an interface address only needs to special-case things when either the source or destination addresses conflict with ones that are already assigned to the interface. [.] -- Daniel -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
This is my fault. Charles gave me permission to change these files to a BSD license a while ago. It looks like I got it wrong :-/ I'll fix it now. I was doing some things in libalias when something caught my eye, $ cat alias.c /* -*- mode: c; tab-width: 8; c-basic-indent: 4; -*- */ /*- * Copyright (c) 2001 Charles Mott [EMAIL PROTECTED] * All rights reserved. * [snip usual BSD licence legalese and comments about the code.] This software is placed into the public domain with no restrictions on its distribution. This is contained in several files in there. This is a contradiction. Public domain software can't also have copyright notices and a bunch of license disclaimers. The BSD-style copyright header was added back in June. You can't just take something in the public domain and slap a copyright on it, but IANAL. Still, the comments in the code as written are self-contradictory. It can't have a BSD-license _and_ be public domain. And since again IANAL, I am not saying which needs to stay or which needs to go, but one of those statements does. -- Crist J. Clark [EMAIL PROTECTED] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
+---[ Brian Somers ]-- | This is my fault. Charles gave me permission to change these files | to a BSD license a while ago. It looks like I got it wrong :-/ | | I'll fix it now. Well since copyright was abandoned (being placed into the public domain is abandonment of copyright), the changed file can be copyrighted by whomever makes changes. The new file is then covered by the license from that point forward. If Charles was the copyright holder and licensed them to you under a BSD license then the license still holds (but, not if they were already Public Domain, since you don't need permission if they're abandoned, and Charles no longer holds copyright anyway). This is true even if they are subsequently released to the public domain, although Charles would probably have no recourse if you broke your license with him d8) Charles probably didn't want to really put his code into the public domain, and as it seems Charles has licensed the code under a BSDL to us, the license in the file is correct. Check with Charles to see if he really wants to abandon copyright claims to his code, or whether he was really implying some really liberal open source license. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
QT23 not building
Dear FreeBSD'ers, I am running -CURRENT as of August 18, 2001 -- yet another entry in the -current userbase, BTW. I am using XFree4 and my /etc/make.conf contains the required XFree86 version string. Qt23 will NOT build. It dies here: gmake[2]: Leaving directory `/usr/ports/x11-toolkits/qt23/work/qt-2.3.1/tools' gmake[1]: Leaving directory `/usr/ports/x11-toolkits/qt23/work/qt-2.3.1/tools' The Qt library is now built in ./lib The Qt examples are built in the directories in ./examples The Qt tutorials are built in the directories in ./tutorial Note: be sure to set $QTDIR to point to here or to wherever you move these directories. Enjoy! - the Trolltech team (cd /usr/ports/x11-toolkits/qt23/work/qt-2.3.1/src /usr/bin/env QTDIR=/usr/ports/x11-toolkits/qt23/work/qt-2.3.1 LD_LIBRARY_PATH=/usr/ports/x11-toolkits/qt23/work/qt-2.3.1/lib PORTOBJFORMAT=elf PREFIX=/usr/X11R6 LOCALBASE=/usr/local X11BASE=/usr/X11R6 MOTIFLIB=-L/usr/X11R6/lib -lXm -lXp LIBDIR=/usr/lib CFLAGS=-O -pipe -march=pentiumpro CXXFLAGS= -O -pipe -march=pentiumpro BSD_INSTALL_PROGRAM=install -c -s -o root -g wheel -m 555 BSD_INSTALL_SCRIPT=install -c -o root -g wheel -m 555 BSD_INSTALL_DATA=install -c -o root -g wheel -m 444 BSD_INSTALL_MAN=install -c -o root -g wheel -m 444 gmake -f Makefile opengl/qgl.o opengl/qgl_x11.o opengl/moc_qgl.o) c++ -c -I/usr/X11R6/include -I/usr/ports/x11-toolkits/qt23/work/qt-2.3.1/include -pthread -D_THREAD_SAFE -I/usr/X11R6/include -DQT_PREFIX=\/usr/X11R6\ -pipe -O -fno-exceptions -O -pipe -march=pentiumpro -I/usr/include -D_PTH_H_ -D_PTH_PTHREAD_H_ -frerun-cse-after-loop -fPIC -DQT_BUILTIN_GIF_READER=1 -DQT_XFT -fno-exceptions -I/usr/local/include -o opengl/qgl.o opengl/qgl.cpp In file included from opengl/qgl.cpp:38: opengl/qgl.h:63: GL/gl.h: No such file or directory opengl/qgl.h:64: GL/glu.h: No such file or directory opengl/qgl.cpp: In method `void QGLWidget::glDraw()': opengl/qgl.cpp:1604: `GL_FRONT_LEFT' undeclared (first use this function) opengl/qgl.cpp:1604: (Each undeclared identifier is reported only once opengl/qgl.cpp:1604: for each function it appears in.) opengl/qgl.cpp:1604: implicit declaration of function `int glDrawBuffer(...)' opengl/qgl.cpp:1616: implicit declaration of function `int glFlush(...)' opengl/qgl.cpp: In method `void QGLWidget::qglColor(const QColor ) const': opengl/qgl.cpp:1634: implicit declaration of function `int glColor3ub(...)' opengl/qgl.cpp:1636: implicit declaration of function `int glIndexi(...)' opengl/qgl.cpp: In method `void QGLWidget::qglClearColor(const QColor ) const': opengl/qgl.cpp:1654: `GLfloat' undeclared (first use this function) opengl/qgl.cpp:1654: syntax error before `.' opengl/qgl.cpp:1659: confused by earlier errors, bailing out gmake: *** [opengl/qgl.o] Error 1 *** Error code 2 Stop in /usr/ports/x11-toolkits/qt23. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt23. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt23. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt23. The archives (-questions, -current, -ports) seem to contain other complaints. Is qt supposed to build with XFree86-4 under -CURRENT? What am I missing ? -- Salvo (If I've missed something rivial, many apologies for the noise) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
Check with Charles to see if he really wants to abandon copyright claims to his code, or whether he was really implying some really liberal open source license. With the BSD Copyright (only) he keeps the intellectual copyright on the original. That's what I've changed it to (as per his agreement). -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
+---[ Brian Somers ]-- | Check with Charles to see if he really wants to abandon copyright claims | to his code, or whether he was really implying some really liberal open source | license. | | With the BSD Copyright (only) he keeps the intellectual copyright on | the original. That's what I've changed it to (as per his agreement). Oh, I thought he put in the comment to the effect it was in the Public Domain, if you did that you're naughty! d8) If he did that, he probably needs to rethink it. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
+---[ Brian Somers ]-- | Check with Charles to see if he really wants to abandon copyright claims | to his code, or whether he was really implying some really liberal open source | license. | | With the BSD Copyright (only) he keeps the intellectual copyright on | the original. That's what I've changed it to (as per his agreement). Oh, I thought he put in the comment to the effect it was in the Public Domain, if you did that you're naughty! d8) If he did that, he probably needs to rethink it. He originally wrote it to say it was in the public domain. I asked him if he minded me making it a BSD license and he said ok only I didn't do the whole job :*) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Copyright Contradiction in libalias
On Tue, Aug 21, 2001 at 02:10:42AM +0100, Brian Somers wrote: +---[ Brian Somers ]-- | Check with Charles to see if he really wants to abandon copyright claims | to his code, or whether he was really implying some really liberal open source | license. | | With the BSD Copyright (only) he keeps the intellectual copyright on | the original. That's what I've changed it to (as per his agreement). Oh, I thought he put in the comment to the effect it was in the Public Domain, if you did that you're naughty! d8) If he did that, he probably needs to rethink it. He originally wrote it to say it was in the public domain. I asked him if he minded me making it a BSD license and he said ok only I didn't do the whole job :*) If you look at the history of the files, they were imported into FreeBSD with the statement that they are public domain. I don't think there is any way he can take that back and claim copyright over them. Now, as to whether anyone can now claim a copyright over the contents since (not very substantial) changes have been made is something for lawyers to settle. It is now written policy, and I believe it was the understood, unwritten policy in the past, that any patches and additions to a file in FreeBSD are governed by the existing licensing of the file unless otherwise stated. This would indicate to me that this file is arguably still public domain. Again, IANAL. For now, as they stand, the licensing text within them is contradictory and should be fixed. As for whether it's getting fixed the right way is something only a lawyer could answer, and I really doubt anyone is ever going to care enough about these couple of files to pay a lawyer to have a look. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
In servalan.mailinglist.fbsd-current jhb writes:
On 19-Aug-01 Richard Todd wrote:
In servalan.mailinglist.fbsd-current Maxim Sobolev writes:
I found that after reverting the following deltas (jhb's 10 August commit)
sound starts working again:
[list of deltas deleted]
I found much the same thing; specifically, the problematic change is this
one:
What wait channel is the process (xmms, mpg123, whatever) in?
Looking at a core file from a known-buggy kernel that I'd forced to core
itself with ddb, I find for the madplay process:
(kgdb) proc 855
(kgdb) bt
#0 mi_switch () at ../../../kern/kern_synch.c:707
#1 0xc0273645 in msleep (ident=0xc13e0b00, mtx=0xc13d2800, priority=332,
wmesg=0xc042bcb4 pcmwr, timo=1) at ../../../kern/kern_synch.c:466
#2 0xc01fcad8 in chn_sleep (c=0xc13d1680, str=0xc042bcb4 pcmwr, timeout=1)
at ../../../dev/sound/pcm/channel.c:109
#3 0xc01fcd5c in chn_write (c=0xc13d1680, buf=0xc8f1af00)
at ../../../dev/sound/pcm/channel.c:259
#4 0xc01fef40 in dsp_write (i_dev=0xc13e0f00, buf=0xc8f1af00, flag=2359297)
at ../../../dev/sound/pcm/dsp.c:381
#5 0xc0243095 in spec_write (ap=0xc8f1ae90)
at ../../../fs/specfs/spec_vnops.c:289
#6 0xc0242dc9 in spec_vnoperate (ap=0xc8f1ae90)
at ../../../fs/specfs/spec_vnops.c:119
#7 0xc02b7c5f in vn_write (fp=0xc1623ec0, uio=0xc8f1af00, cred=0xc15c2600,
flags=0, p=0xc8e54100) at vnode_if.h:303
#8 0xc028c073 in dofilewrite (p=0xc8e54100, fp=0xc1623ec0, fd=3,
buf=0xbfbf8b74, nbyte=4608, offset=-1, flags=0) at ../../../sys/file.h:162
#9 0xc028bf26 in write (p=0xc8e54100, uap=0xc8f1af80)
at ../../../kern/sys_generic.c:334
#10 0xc03e2fc9 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077965964, tf_esi = 4608, tf_ebp = -1077937536,
tf_isp = -923684908, tf_ebx = -1077965964, tf_edx = 1103, tf_ecx = -411,
tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 672022312, tf_cs = 31,
tf_eflags = 663, tf_esp = -1077966048, tf_ss = 47})
at ../../../i386/i386/trap.c:1128
#11 0xc03cce0d in syscall_with_err_pushed ()
so apparently it was waiting on 'pcmwr'.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Where to put new bus_dmamap_load_mbuf() code
Okay, I decided today to write a bus_dmamap_load_mbuf() routine to make it a little easier to convert the PCI NIC drivers to use the busdma API. It's not the same as the NetBSD code. There are four new functions: bus_dmamap_load_mbuf() bus_dmamap_unload_mbuf() bus_dmamap_sync_mbuf() bus_dmamap_destroy_mbuf() This is more or less in keeping with the existing API, except the new routines work exclusively on mbuf lists. The thing I need to figure out now is where to put the code. The current suggestion from jhb is to create the following two new files: sys/kern/kern_busdma.c sys/sys/busdma.h The functions are machine-independent, so they shouldn't be in sys/arch/arch/busdma_machdep.c. I mean, they could go there, but that would just result in code duplication. If somebody has a better suggestion, now's the time to speak up. Please let's avoid creating another bikeshed over this. Current code snapshot resides at: http://www.freebsd.org/~wpaul/busdma There's also a modified version if the Adaptec starfire driver there which uses the new routines. I'm running this version of the driver on a test box in the lab right now. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = I like zees guys. Zey are fonny guys. Just keel one of zem. -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
Yay! The current suggestion is fine except that each platform might have a more efficient, or even required, actual h/w mechanism for mapping mbufs. I'd also be a little concerned with the way you're overloading stuff into mbuf itself- but I'm a little shakier on this. Finally- why not make this an inline? -matt On Mon, 20 Aug 2001, Bill Paul wrote: Okay, I decided today to write a bus_dmamap_load_mbuf() routine to make it a little easier to convert the PCI NIC drivers to use the busdma API. It's not the same as the NetBSD code. There are four new functions: bus_dmamap_load_mbuf() bus_dmamap_unload_mbuf() bus_dmamap_sync_mbuf() bus_dmamap_destroy_mbuf() This is more or less in keeping with the existing API, except the new routines work exclusively on mbuf lists. The thing I need to figure out now is where to put the code. The current suggestion from jhb is to create the following two new files: sys/kern/kern_busdma.c sys/sys/busdma.h The functions are machine-independent, so they shouldn't be in sys/arch/arch/busdma_machdep.c. I mean, they could go there, but that would just result in code duplication. If somebody has a better suggestion, now's the time to speak up. Please let's avoid creating another bikeshed over this. Current code snapshot resides at: http://www.freebsd.org/~wpaul/busdma There's also a modified version if the Adaptec starfire driver there which uses the new routines. I'm running this version of the driver on a test box in the lab right now. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = I like zees guys. Zey are fonny guys. Just keel one of zem. -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
Another thing- maybe I'm confused- but I still don't see why you want to require the creating of a map each time you want to load an mbuf chain. Wouldn't it be better and more efficient to let the driver decide when and where the map is created and just use the common code for loads/unloads? On Mon, 20 Aug 2001, Matthew Jacob wrote: Yay! The current suggestion is fine except that each platform might have a more efficient, or even required, actual h/w mechanism for mapping mbufs. I'd also be a little concerned with the way you're overloading stuff into mbuf itself- but I'm a little shakier on this. Finally- why not make this an inline? -matt On Mon, 20 Aug 2001, Bill Paul wrote: Okay, I decided today to write a bus_dmamap_load_mbuf() routine to make it a little easier to convert the PCI NIC drivers to use the busdma API. It's not the same as the NetBSD code. There are four new functions: bus_dmamap_load_mbuf() bus_dmamap_unload_mbuf() bus_dmamap_sync_mbuf() bus_dmamap_destroy_mbuf() This is more or less in keeping with the existing API, except the new routines work exclusively on mbuf lists. The thing I need to figure out now is where to put the code. The current suggestion from jhb is to create the following two new files: sys/kern/kern_busdma.c sys/sys/busdma.h The functions are machine-independent, so they shouldn't be in sys/arch/arch/busdma_machdep.c. I mean, they could go there, but that would just result in code duplication. If somebody has a better suggestion, now's the time to speak up. Please let's avoid creating another bikeshed over this. Current code snapshot resides at: http://www.freebsd.org/~wpaul/busdma There's also a modified version if the Adaptec starfire driver there which uses the new routines. I'm running this version of the driver on a test box in the lab right now. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = I like zees guys. Zey are fonny guys. Just keel one of zem. -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syntax change in ppp?
Brian Somers schrieb: Hi, after the latest updates I just noticed a different behaviour of ppp. in /etc/ppp/ppp.linkup I had an additional line iface clear for my profile to get rid of stuffed up IP pairs. After the latest update this entry also clears my defaultroute, but only after redialing. I now had to put the iface clear into /etc/ppp/ppp.linkdown, but then the old IP pair is still there during the next connection. Putting ``iface clear'' in ppp.linkup will result in the whole iface-alias thing being broken. It's meant to be in ppp.linkdown. The objective is that ppp, once connected, has two IP numbers on the interface, one for what was there before the connection completed and one for the negotiated IP address. When this happens, the ``first connection'' continues to work (the process that caused the dial-up will be bound to the IP number that was on the interface when it started and the nat engine will tweak these packets so that they use the negotiated IP number). Suppose on the first connection I got the IP pair A - B and on the second C - D while the second one still active another person will get A - B assigned by our ISP. Will I be able to talk with A or B? Or will they point back to myself? I put the iface clear in ppp.linkup for exactly this case. So really, you're doing the equivalent of ``disable iface-alias'' and stopping your first connection from working. Moving the ``iface clear'' to ppp.linkdown should be better. Were my assumptions wrong (regarding the iface clear command) or is something broken in ppp? Yes and yes. Hmm, I didn't notice any problems before the last commit... Any automatic connection (even the first) worked without any problems. But: iface clear just went from ppp.linkdown to ppp.linkup some weeks ago, but after I got DSL. With DSL the destination IP address is always the same. I don't know if this configuration would work with my old ISDN access with changing destination IP addresses. [...] When IPCP comes up, ppp adds the new address to the interface. It's *meant* to change the old interface destination address to 255.255.255.255, but is getting this wrong. Then, as you've already spotted, when your ``iface clear'' is run, it blows away the default route. I've just committed a fix for this. It's in version 1.25 of iface.c. BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out tons of messages Error: iface_Add: socket(): Protocol not supported Yep, a fix for that was committed a few days ago too. My apologies. Oh, I just discovered that cvsup didn't update my tree for 3 days. Everything works ok again - even the things which weren't design to work at all. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
Another thing- maybe I'm confused- but I still don't see why you want to require the creating of a map each time you want to load an mbuf chain. Wouldn't it be better and more efficient to let the driver decide when and where the map is created and just use the common code for loads/unloads? Every hear the phrase you get what you pay for? The API isn't all that clear, and we don't have a man page or document that describes in detail how to use it properly. Rather than whining about that, I decided to tinker with it and Use The Source, Luke (tm). This is the result. My understanding is that you need a dmamap for every buffer that you want to map into bus space. Each mbuf has a single data buffer associated with it (either the data area in the mbuf itself, or external storage). We're not allowed to make assumptions about where these buffers are. Also, a single ethernet frame can be fragmented across multiple mbufs in a list. So unless I'm mistaken, for each mbuf in an mbuf list, what we have to do is this: - create a bus_dmamap_t for the data area in the mbuf using bus_dmamap_create() - do the physical to bus mapping with bus_dmamap_load() - call bus_dmamap_sync() as needed (might handle copying if bounce buffers are required) - insert mysterious DMA operation here - do post-DMA sync as needed (again, might require bounce copying) - call bus_dmamap_unload() to un-do the bus mapping (which might free bounce buffers if some were allocated by bus_dmamap_load()) - destroy the bus_dmamap_t One memory region, one DMA map. It seems to me that you can't use a single dmamap for multiple memory buffers, unless you make certain assumptions about where in physical memory those buffers reside, and I thought the idea of busdma was to provide a consistent, opaque API so that you would not have to make any assumptions. Now if I've gotten any of this wrong, please tell me how I should be doing it. Remember to show all work. I don't give partial credit, nor do I grade on a curve. Yay! The current suggestion is fine except that each platform might have a more efficient, or even required, actual h/w mechanism for mapping mbufs. It might, but right now, it doesn't. All I have to work with is the existing API. I'm not here to stick my fingers in it and change it all around. I just want to add a bit of code on top of it so that I don't have to go through quite so many contortions when I use the API in network adapter drivers. I'd also be a little concerned with the way you're overloading stuff into mbuf itself- but I'm a little shakier on this. I thought about this. Like it says in the comments, at the device driver level, you're almost never going to be using some of the pointers in the mbuf header. On the RX side, *we* (i.e. the driver) are allocating the mbufs, so we can do whatever the heck we want with them until such time as we hand them off to ether_input(), and by then we will have put things back the way they were. For the TX side, by the time we get the mbufs off the send queue, we always know we're going to have just an mbuf list (and not an mbuf chain), and we're going to toss the mbufs once we're done with them, so we can trample on certain things that we know don't matter to the OS or network stack anymore. The alternatives are: - Allocate some extra space in the DMA descriptor structures for the necessary bus_dmamap_t pointers. This is tricky with this particular NIC, and a little awkward. - Allocate my own private arrays of bus_dmamap_t that mirror the DMA rings. This is yet more memory I need to allocate and free at device attach and detach time. I've got space in the mbuf header. It's not being used. It's right where I need it. Why not take advantage of it? Finally- why not make this an inline? Er... because that idea offended my delicate sensibilities? :) -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = I like zees guys. Zey are fonny guys. Just keel one of zem. -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Where to put new bus_dmamap_load_mbuf() code
On Mon, 20 Aug 2001, Bill Paul wrote:
Every hear the phrase you get what you pay for? The API isn't all that
clear, and we don't have a man page or document that describes in detail
how to use it properly. Rather than whining about that, I decided to
tinker with it and Use The Source, Luke (tm). This is the result.
Well, I'm more familiar with the NetBSD BusDma code, which is similar, and
heavily documented. I'm also one of the principle authors of the Solaris
DKI/DDI, which is *also* heavily documented, so I have some small notion of
how a few of these subsystems are supposed to work, and where documentation
exists for these- and similar systems (e.g., UDI).
My understanding is that you need a dmamap for every buffer that you want
to map into bus space. Each mbuf has a single data buffer associated with
it (either the data area in the mbuf itself, or external storage). We're
not allowed to make assumptions about where these buffers are. Also, a
single ethernet frame can be fragmented across multiple mbufs in a list.
So unless I'm mistaken, for each mbuf in an mbuf list, what we
have to do is this:
- create a bus_dmamap_t for the data area in the mbuf using
bus_dmamap_create()
- do the physical to bus mapping with bus_dmamap_load()
- call bus_dmamap_sync() as needed (might handle copying if bounce
buffers are required)
- insert mysterious DMA operation here
- do post-DMA sync as needed (again, might require bounce copying)
- call bus_dmamap_unload() to un-do the bus mapping (which might free
bounce buffers if some were allocated by bus_dmamap_load())
- destroy the bus_dmamap_t
One memory region, one DMA map. It seems to me that you can't use a
single dmamap for multiple memory buffers, unless you make certain
assumptions about where in physical memory those buffers reside, and
I thought the idea of busdma was to provide a consistent, opaque API
so that you would not have to make any assumptions.
Now if I've gotten any of this wrong, please tell me how I should be
doing it. Remember to show all work. I don't give partial credit, nor
do I grade on a curve.
This is fine insofar as it goes, but there's nothing, I believe, that requires
you to *create* a bus_dmamap_t each time you wish to map something and then
destroy it when you unmap something. You might ask why one actually has the
separate step from map creation and map load at all then. All the rest of the
stuff for load/sync/sync/unload is fine.
Using The Code (tm)- you can see that, for example, you can create
a tag that describes all of the the addressable space your device
can access, e.g.:
if (bus_dma_tag_create(pci-parent_dmat, PAGE_SIZE, lim,
BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
BUS_SPACE_MAXSIZE_32BIT, 0, pci-cntrol_dmat) != 0) {
isp_prt(isp, ISP_LOGERR,
cannot create a dma tag for control spaces);
free(isp-isp_xflist, M_DEVBUF);
free(pci-dmaps, M_DEVBUF);
return (1);
}
Then, for each possible transaction slot- if you have a device that has a
fixed number of transactions that are possible (as many do), you can create
maps ahead of time:
for (i = 0; i isp-isp_maxcmds; i++) {
error = bus_dmamap_create(pci-parent_dmat, 0, pci-dmaps[i]);
if (error) {
...
so that for each transaction that needs to be mapped, you can dma load it:
bus_dmamap_t *dp;
...
dp = pci-dmaps[isp_handle_index(rq-req_handle)];
...
s = splsoftvm();
error = bus_dmamap_load(pci-parent_dmat, *dp,
csio-data_ptr, csio-dxfer_len, eptr, mp, 0);
...
which as part of the load process can sync it:
dp = pci-dmaps[isp_handle_index(rq-req_handle)];
if ((csio-ccb_h.flags CAM_DIR_MASK) == CAM_DIR_IN) {
bus_dmamap_sync(pci-parent_dmat, *dp, BUS_DMASYNC_PREREAD);
} else {
bus_dmamap_sync(pci-parent_dmat, *dp, BUS_DMASYNC_PREWRITE);
}
and when the transaction is done, you can sync and unload:
static void
isp_pci_dmateardown(struct ispsoftc *isp, XS_T *xs, u_int16_t handle)
{
struct isp_pcisoftc *pci = (struct isp_pcisoftc *)isp;
bus_dmamap_t *dp = pci-dmaps[isp_handle_index(handle)];
if ((xs-ccb_h.flags CAM_DIR_MASK) == CAM_DIR_IN) {
bus_dmamap_sync(pci-parent_dmat, *dp, BUS_DMASYNC_POSTREAD);
} else {
bus_dmamap_sync(pci-parent_dmat, *dp, BUS_DMASYNC_POSTWRITE);
}
bus_dmamap_unload(pci-parent_dmat, *dp);
}
So- my question still stands- from a performance point of view (Networking
people *do* care about performance I believe, yes? :-))- if you don't need to
create the map each time, wouldn't you rather not? So, the mbuf mapping code,
which is cool to have, really might not need this?
The current suggestion is
Re: Where to put new bus_dmamap_load_mbuf() code
Correction.
This sample:
if (bus_dma_tag_create(pci-parent_dmat, PAGE_SIZE, lim,
BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
BUS_SPACE_MAXSIZE_32BIT, 0, pci-cntrol_dmat) != 0) {
isp_prt(isp, ISP_LOGERR,
cannot create a dma tag for control spaces);
free(isp-isp_xflist, M_DEVBUF);
free(pci-dmaps, M_DEVBUF);
return (1);
}
Should have been:
if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT,
BUS_SPACE_MAXADDR, NULL, NULL, lim + 1,
255, lim, 0, pcs-parent_dmat) != 0) {
device_printf(dev, could not create master dma tag\n);
free(isp-isp_param, M_DEVBUF);
free(pcs, M_DEVBUF);
return (ENXIO);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
/usr/games/wtf
hi, there! I would like to add /usr/games/wtf from NetBSD to base system. Any opinions/objections? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/games/wtf
On Tue, Aug 21, 2001 at 01:03:11PM +0700, Max Khon wrote: hi, there! I would like to add /usr/games/wtf from NetBSD to base system. Any opinions/objections? wtf is it? Kris PGP signature
Re: Where to put new bus_dmamap_load_mbuf() code
Every hear the phrase you get what you pay for? The API isn't all that clear, and we don't have a man page or document that describes in detail how to use it properly. Rather than whining about that, I decided to tinker with it and Use The Source, Luke (tm). This is the result. Fair enough. My understanding is that you need a dmamap for every buffer that you want to map into bus space. You need one dmamap for each independantly manageable mapping. A single mapping may result in a long list of segments, regardless of whether you have a single KVA buffer or multiple KVA buffers that might contribute to the mapping. Each mbuf has a single data buffer associated with it (either the data area in the mbuf itself, or external storage). We're not allowed to make assumptions about where these buffers are. Also, a single ethernet frame can be fragmented across multiple mbufs in a list. So unless I'm mistaken, for each mbuf in an mbuf list, what we have to do is this: - create a bus_dmamap_t for the data area in the mbuf using bus_dmamap_create() Creating a dmamap, depending on the architecture, could be expensive. You really want to create them in advance (or pool them), with at most one dmamap per concurrent transaction you support in your driver. - do the physical to bus mapping with bus_dmamap_load() bus_dmamap_load() only understands how to map a single buffer. You will have to pull pieces of bus_dmamap_load into a new function (or create inlines for common bits) to do this correctly. The algorithm goes something like this: foreach mbuf in the mbuf chain to load /* * Parse this contiguous piece of KVA into * its bus space regions. */ foreach bus space discontiguous region if (too_many_segs) return (error); Add new S/G element With the added complications of deferring the mapping if we're out of space, issuing the callback, etc. - call bus_dmamap_sync() as needed (might handle copying if bounce buffers are required) - insert mysterious DMA operation here - do post-DMA sync as needed (again, might require bounce copying) - call bus_dmamap_unload() to un-do the bus mapping (which might free bounce buffers if some were allocated by bus_dmamap_load()) - destroy the bus_dmamap_t Chances are you are going to use the map again soon, so destroying it on every transaction is a waste. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
