Re: KAME IPv6 and freebsd
Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More than 32 signals. Thought?
On Mon, 30 Aug 1999 12:26:06 CST, Warner Losh wrote: : On LITTLE_ENDIAN machines? Endian shouldn't matter. Yup, it was the kind of stupid comment someone who doesn't actually know what's going on would make. ;-) I hadn't cottoned on to the notion of using an array. Thanks, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: icmp raw sockets
On Mon, Aug 30, 1999 at 05:34:00PM -0700, Dima Dorfman wrote: hi, i was reading some of the mailing list archives to get an answer to 'why dont icmp echo requests get passed to the raw sockets', and now that i have the answer i was wondering... is there a way to tell the kernel NOT to process echo/timestamp/mask requests and instead pass those to the raw sockets? i'm looking for a solution that doesnt involve kernel modifications. thanks in advance, --dima divert(4)? -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message 10335.936082907@localhost, "Jordan K. Hubbard" writes: Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have "kern-developer" still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have "kern-developer" still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... Thanks! It makes the most sense to keep this exactly as it it, except for the files in src/sys/netinet6/ which should move to src/sys/crypto/ if they have crypto in them. Please do not import this until we (JDP!) gets the distribution channels crypto-happy. This is not difficult. itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
On Tue, 31 Aug 1999, Mark Murray wrote: I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. I would prefer src/sys/crypto. I tend to have a lot of kernel-only trees around for my work and the more self-contained they are the better. Moving softupdates into sys/crypto was a good thing (IMHO). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Hmmm. That's a point. I was thinking primarily of the "segregate the crypto" issue, but you're right that this would also put us back to the "bad old days" where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) - Jordan In message 10335.936082907@localhost, "Jordan K. Hubbard" writes: Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have "kern-developer" still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message 506.936093482@localhost, "Jordan K. Hubbard" writes: Hmmm. That's a point. I was thinking primarily of the "segregate the crypto" issue, but you're right that this would also put us back to the "bad old days" where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) That's certainly an improvement in that particular battle :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [mount.c]: Option user-patch
On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a "user"-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * [EMAIL PROTECTED] * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More than 32 signals. Thought?
On Mon, 30 Aug 1999, Francis Jordan wrote:
Marcel Moolenaar wrote:
[cc'd to David E. Cross ([EMAIL PROTECTED]) and James Raynard
([EMAIL PROTECTED])]
I'm thinking about extending the number of signals. I like your thoughts
and opinions.
Basicly what I'm going to do is rewrite the signalling code to use a new
sigset_t and provide new syscalls to use it. The current syscalls convert
between the current and the new types for compatibility. I think I'm going
to borrow a thought or two from Linux which allows further increasing of
the number of signals without rewriting the logic, but that's basicly
undecided yet and open for discussion.
Do as NetBSD does to remain compatible? Or borrow a few thoughts from
Solaris, which also has 128 signals:
typedef struct {/* signal set type */
unsigned long __sigbits[4];
} sigset_t;
Please be careful with your datatypes when formulating this. If you are
going to pack 32 signals into one field, make it u_int32_t, not int or
long.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ndc(8)
* Jeroen Ruigrok/Asmodai ([EMAIL PROTECTED]) [990829 14:40]: They shouldn't. That's what we have /var for like you said. OK, I totally agree that named should dump to /var/somegoodpath but this I guess falls out of my own hacking limits. I think we need a desiscion if to move named dumps from /etc/namedb to /var/namedb perhaps. And where does a default named dump it? Any commiter that can decide this? Anders -- Anders Andersson[EMAIL PROTECTED] Sanyusan International AB http://www.sanyusan.se/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More than 32 signals. Thought?
Doug Rabson wrote:
On Mon, 30 Aug 1999, Francis Jordan wrote:
Do as NetBSD does to remain compatible? Or borrow a few thoughts from
Solaris, which also has 128 signals:
typedef struct {/* signal set type */
unsigned long __sigbits[4];
} sigset_t;
Please be careful with your datatypes when formulating this. If you are
going to pack 32 signals into one field, make it u_int32_t, not int or
long.
I also was not quite happy with the choice of type for __sigbits. Is it
worth having __sigbits to be the size that most suits the architecture (32
for i386; 64 for alpha) because of the frequent bit manipulations that are
expected to be performed with it?
--
Marcel Moolenaar mailto:[EMAIL PROTECTED]
SCC Internetworking Databases http://www.scc.nl/
Amsterdam, The Netherlands tel: +31 20 4200655
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Hmmm. That's a point. I was thinking primarily of the "segregate the crypto" issue, but you're right that this would also put us back to the "bad old days" where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) Yes, this is very pity... Hoping to see more open US export policy in the near future. KAME has "options IPSEC" (framework, authentication and compression) and "options IPSEC_ESP" (encryption) separately defined. Therefore, even if you do not have access to South Africa, you can use AH and IPComp. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make aout-to-elf-build Failing
On Mon, Aug 30, 1999 at 03:55:42PM -0700, Doug wrote: `make' has changed. Ok, that's the cause then, so what's the solution? :) And meanwhile is it going to hurt anything if I put a suggestion on my 'make upgrade' web page that users do 'make -DMACHINE_ARCH=i386 upgrade' as a temporary measure to get the thing to work? The solution is to fix `make'. I could commit the fix, but I'm not in a position to build -stable just now. I'm not supposed to commit without testing. The fix looks straight forward though, so "it should just work". 8-) -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New boot loader
I developed boot loader, which is more powerful and looks better than
boot loader, which is usually installed with FreeBSD release. I used
it for a long time and decided to send it to FreeBSD.
I haven't own home page and can't give you URL where you can read
information about my boot loader. So, here it is some lines from README
(as description) and UUEencoded full packet of my boot loader.
Please analyze this and say what you think about it. Sorry, if you
aren't
interesting in my boot loader and I took some your time.
-
1
Q: What is UNILOAD?
A: UNILOAD (UNIversal LOADer) is a program, which allows to boot OS from
any partition from any of 4 hard disk. It is a replacement for the
ordinary master boot record.
-
3
Q: You said that UNILOAD takes more than one sector on hard disk. So,
it uses MBR and some sectors. Does it damage my information?
A: Usually first partition on hard disk begin from track 0 head 1 sector
1
and some sectors from track 0 head 0 sector 1 to track 0 head 1 sector
1
are free. That's why it doesn't damage your information.
-
5
Q: How can I be sure that UNILOAD didn't damage my information?
A: When you run UNILOAD install program it will check your partition
table and inform you about problems.
-
6
Q: What does it look like?
A: On my computer it looks like:
Booted from hdd0:
00: DOS 16-bit =32
02: Linux native
03: BSD/386
Command [press m for help]: _
String ... really is highlighted bar. I can choose partition by
arrows and make bootstrap by pressing Enter button. Also it's
possible
to press m and view additional options.
-
7
Q: I have got 2 (3, 4) hard disks. Is it possible to boot OS from second
(third, fourth) disk?
A: Yes. UNILOAD automatically detects all hard disks on you computer.
You
can boot from any partition from any of 4 hard disks. First digit in
string shows number of hard disk, second digit represents number of
partition on that disk.
-28
Q: Can the author give any warranty? Can I give UNILOAD to somebody?
A: No, I can't give you any warranty. You should not pay any money for
this version of UNILOAD. With UNILOAD binary and install program you
should received sources. If you has sources you can analyze them and
recompile, so you know what you use.
You can copy and distribute this software while original copyright
messages are present, provided that sources are included.
** REMEMBER THAT YOU USE UNILOAD ON YOUR OWN RISC **
---
begin 644 uload-10.zip
M4$L#!!0``@`(`,^8'BO85\U@```#H!```+1DE,15])1"Y$25I=CD%+
MPU`0A.^!_(YV:(-K8(83P8+(H@MU'I_)IMFRO;L]CR;^W%5O%NXW'_/
MYNDYVQ?GU]6Q3)-WDDC2SA7BVR)DMG?V'S%%LG[#(\_Q04BR5SNM?E3@
M"(=9:NP[[ALH'S7O81)O@0,:PVJ%4ZN#"B=VI\=%RE"?Z%[2*"@Y'WO*-@
MAT%QD4,D716*U.H_/A-:.U*RM*D*P1_?TN9/P4$H7QY@%V9MSUG+])D-
M#I,B5$HC-D(0BO3-%E[9[5H=U*L'SYO+Z[G7X!4$L#!!0``@`(`'VC'B=7
M6+,J?A$``*PX```4D5!1$U%O5OK4QNYEO_L5.5_T(["V2-L0UY3-D
M("$SK@J0QDFJ:W=*;E;MG7I;OE*:HSO7[_G=Z1^,C.)(%U%1T2T?G_53$
M-SX7)T=O3T_$56_0ZXN9L+3V?C]^=';QX\/QJ+5"4Z5:GP1JRL]JI:K@OQ
MCU(YKTVQ*PNW4A9[\QYVO=?."S.K%[@1GHK!2'Q2"^TJXYX34^'(_[68G4
MJ/JQ6!E[B7?[(_'5E,))30A@:[7`RTM:GANK\+P0IE#"J03]J80"VE3D6IW
MV1,3TQ7:B](I1_#HWI\(621"F?R:HOKB;XG=:E,I=S)?(UT0=R)-`')@?`
M?5V?3R0X(Z9Z_EJ^P71/C7B\S(5%G'V!$V1JG$4?$TT!C0IB.Q93.+0/B
M#4I3HNM_^/\9Y%W:40T,^929/I2X7S$8%=R"LEYH3%4SO=\7!3L,(G#,
MNY;.3W-%*3))]/Q,R:'(PP11HXM.T7VJ9=$F=I_6*'("4%R-QNHXK]C,
M"N7+)1@?7DI+RS*@0W]Y:[),V1ZS#]B'0RJZW8+X0IA))P;]KA@,Z8!20"
MZ2\WJ)N\F8S;`GY[4V_$2OL%+Z/-@W[@/-K"^=EEK54;S``Y/AI6)-!(O_
M^?5?G_S+WVJ(P(2DX=;.J[R2$EC7"_(@_,LL)3"I`1AX%%8#6Q0*"!_.2
M)+QB+KS.E9B67A1!,RJX@3\`ON6$7RBQM(9$E@/\_FB3WMRDK862VF]9D,3
MBABNE7LMWK"N542;FTK:#L%JJHH2U("%-%#V1FE4S7#6MP]L$FL]H,TLR'
ME1-$DJ7?MT5ZMJK`GZCP2U2%L61PT9@0:4LQJX,EFTUN/0ISBT=`1'%U[1
MP8D75LW!.AQ(;T)V*K;.@UQ(Z#E:LMUCQ`.I9R\^H:YGX;+VI-[JX=0CV
M/1_5JKNIM3--AT11^_52P/5V/GBU40K"/I72.#@(I`!1UD+4;,F,7ZTL+
M9W8WM9M@NJP\N9)L%:!ZDW+FAD[5[2`I)\L9#%7+JILJJO*VN*.2$P[^8
M%QQI8]LX=4*#E#!`,.IY/=S[I(21=\XJ=3QA10@(_';V:^]+LKK+AWN
M#,Z2A=F$F2C-ZZMCG=:TW#P)ZC=TM._B%A/',73UG(.3$P*ME[PJWW335G
M(PV@'.$=1?F0V`N4Q@`T.9`M8E[(Z:RBD:-YD[9B`F3%JM'GPL`)H97$,
M=.!\LNF8@J^7]Z.A8W#^X#K:`LBOU:8O)E"0VZRYIF)LO,2A=SDGZA$,2!
MS'CO7"AKC0U_OGJUM,HY`K`6EVI]-CXKSI8Y4K"((8'HSO\6G"0#7,X+,(5
M-=%]T!\B1-6""\`E+E%X2Z-EXGQ((VUH=3A41E1/6M65J[\2,]S[#WL!V
M$C7NWKL(,8IIT*?HV8+DN_,!8[V17H9,F[QJ96Y4H?:4V7#W61P`8@,0
M,RLHEK96%7U.FE_4V8UAA9B:%)[K\:-=,=B]Q\_C1_\QZMS.Q(YG0J!
M;?IR1:R6F#?RNY@J83(YE;F7;%B-DCHA[N93#Q^U`%M2L,08D1@.VK%[
Re: make aout-to-elf-build Failing
John Birrell wrote: On Mon, Aug 30, 1999 at 03:55:42PM -0700, Doug wrote: `make' has changed. Ok, that's the cause then, so what's the solution? :) And meanwhile is it going to hurt anything if I put a suggestion on my 'make upgrade' web page that users do 'make -DMACHINE_ARCH=i386 upgrade' as a temporary measure to get the thing to work? The solution is to fix `make'. I could commit the fix, but I'm not in a position to build -stable just now. I'm not supposed to commit without testing. The fix looks straight forward though, so "it should just work". 8-) If all it takes is a make world (as opposed to make upgrade) I can test it if you'll send me the patch. I'm on 3.2-Stable as of 8/8 right now. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD MCA
Righty-o, I've finally got a kernel to boot on my MCA box! Yay! Its a rather large "Apricot FTs 486" with the Panther Rev F MB: http://www.mitsubishi-computers.com/insight/en/products/servers/fts/ftsmain.htm It is currently running NT4 (SP5) with all the adapters in it recognised and supported. It is also known to run OS/2 Warp 4, and I once briefly had Solaris 2.4 (x86) on it. Here is what happened while trying to boot FreeBSD... Firstly, the keyboard did not work! It loaded the kernel, and then asked for the mfs disk and said 'press enter to continue' but the keyboard doesn't do anything. The num-lock and caps-locks LEDs do not toggle either. Ok, so I boot using a serial console... yay! I can continue with loading the mfs disk! It loads, then says "booting in n seconds...", I press enter, it starts probing! Yay! Oh, hang on, its hanged :( Hmmm. It hangs while probing npx. Ok... vi src/sys/i386/isa/npx.c ... hmmm, lets bypass that "if ((status 0xb8ff) == 0)" bit and just return 0 - we'll use the emulator... Tada!!! Well, almost... it doesn't grok the AHA-1640 and no disks are found. I will play with your driver over the next couple of days. In case it helps, here is what is in the machine: Motherboard - 8Mb RAM, com1, lpt1, standard VGA slot 1 - Hypertec HyperPort [3 serial, 1 parallel] port: 2f8 irq 3 [only com2 is enabled] slot 2 - AHA-1640 SCSI Host Adapter port: 330 irq 15 dma 4 rom dc00 slot 3 - Hyperam MC 32/16[32Mb RAM] EMS window: c000-c3ff slot 4 - 3Com EtherLink/MC port: 300 irq 12 rom c800 slot 5 - Hyperam MC 32/16[23Mb RAM] EMS window: c400-c7ff slot 6 - BusLogic 32bit BusMaster MCA-to-SCSI Host Adapter (v1.42a) port: 334 irq 14 dma 5 slot 7 - BusLogic...[same as above] port: 234 irq 11 dma 6 slot 8 - BusLogic...[same as above] port: 134 irq 10 dma 7 [there are 11 scsi disks spread across the 4 controllers] And now finally to the nitty-gritty: Here is the output from a successfull boot: [options KBDIO_DEBUG, NPX_DEBUG, DIAGNOSTIC, DEBUG are also in kernel] [start script] Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 FreeBSD/i386 bootstrap loader, Revision 0.7 639/63488kB (jkh@cathair, Tue May 18 03:22:02 GMT 1999) kernel text=0x1289fb data=0x1c478+0x19d5c syms=[0x4+0x1e780+0x4+0x201fb] Please insert MFS root floppy and press enter: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. disk0s4a: disk0s4a: boot -v Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #4: Tue Aug 31 17:39:32 EST 1999 [EMAIL PROTECTED]:/fast1/src/sys/compile/MCA Calibrating clock(s) ... i8254 clock: 1193221 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CPU: i486 DX2 (486-class CPU) Origin = "GenuineIntel" Id = 0x435 Stepping = 5 Features=0x3FPU,VME real memory = 66060288 (64512K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00589000 - 0x03efdfff, 60248064 bytes (14709 pages) avail memory = 58454016 (57084K bytes) BIOS SDT: model 0xf8, submodel 0x1b, bios_rev 0x00 BIOS SDT: features 0xf6MCABUS,EBDA,KBDINT,RTC,IC2 MicroChannel Architecture System detected. Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel" at 0xc057. Preloaded mfs_root "/mfsroot" at 0xc057009c. Math emulator present npx_probe: start npx_probe1: start npx_probe1: device_set_desc npx_probe1: fnstsw npx_probe1: status $0 npx_probe1: end npx_probe: end npx0: math processor on motherboard npx0: 387 emulator mca_probe... POS REG 00 01 02 03 04 05 06 07 --- mca slot 1: 8f 60 b1 02 fd 60 ff ff mca slot 2: 1f 0f 01 3b ff b4 ff ff mca slot 3: 07 70 03 bf 88 ff 08 00 mca slot 4: 42 60 09 01 ff ff ff ff mca slot 5: 07 70 45 bf c9 ff 08 00 mca slot 6: 08 07 1d 03 f7 c5 ff ff mca slot 7: 08 07 17 02 00 46 00 30 mca slot 8: 08 07 15 01 00 47 00 30 mca0: MCA bus on motherboard mca0: unknown card (id 0x608f, enabled) at slot 1 mca0: unknown card (id 0x0f1f, enabled) at slot 2 mca0: unknown card (id 0x7007, enabled) at slot 3 mca0: unknown card (id 0x6042, enabled) at slot 4 mca0: unknown card (id 0x7007, enabled) at slot 5 mca0: unknown card (id 0x0708, enabled) at slot 6 mca0: unknown card (id 0x0708, enabled) at slot 7 mca0: unknown card (id 0x0708, enabled) at slot 8 isa0: ISA bus on motherboard fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 aha0: INQUIRE failed 28 aha0: Geometry Register test failed 0x15 aha0: status reg test failed ff aha0: Geometry
Re: FreeBSD MCA
On Wed, 1 Sep 1999, Andy Farkas wrote: Righty-o, I've finally got a kernel to boot on my MCA box! Yay! Its a rather large "Apricot FTs 486" with the Panther Rev F MB: http://www.mitsubishi-computers.com/insight/en/products/servers/fts/ftsmain.htm Ah! This is good since it means that Int 0x15 Func 0xc0 detects non-PS/2 machines correctly. The 'BIOS SDT: ...' lines are what we're looking at for this. Since you were good enough to capture an entire verbose boot and transcribed the config of all your cards I'll be able to get working on the Buslogic probe/attach bits. It is currently running NT4 (SP5) with all the adapters in it recognised and supported. It is also known to run OS/2 Warp 4, and I once briefly had Solaris 2.4 (x86) on it. Here is what happened while trying to boot FreeBSD... Firstly, the keyboard did not work! It loaded the kernel, and then asked for the mfs disk and said 'press enter to continue' but the keyboard doesn't do anything. The num-lock and caps-locks LEDs do not toggle either. Ok, so I boot using a serial console... yay! I can continue with loading the mfs disk! It loads, then says "booting in n seconds...", I press enter, it starts probing! Yay! Oh, hang on, its hanged :( Hmmm. It hangs while probing npx. Ok... vi src/sys/i386/isa/npx.c ... hmmm, lets bypass that "if ((status 0xb8ff) == 0)" bit and just return 0 - we'll use the emulator... Weird. I have no idea what the deal is there. Tada!!! Well, almost... it doesn't grok the AHA-1640 and no disks are found. I will play with your driver over the next couple of days. Hummm... I know there are some issues with DMA channels. Did I maybe forget to mention adding the line to sys/i386/conf/files.i386? i386/mca/aha_mca.c optionalmca aha Add that and make sure you have: controller aha0 to your config file. I should probably compile the MCA bus support as a module and compile the drivers as modules as well to make testing a tad easier. In case it helps, here is what is in the machine: Motherboard - 8Mb RAM, com1, lpt1, standard VGA slot 1 - Hypertec HyperPort [3 serial, 1 parallel] port: 2f8 irq 3 [only com2 is enabled] slot 2 - AHA-1640 SCSI Host Adapter port: 330 irq 15 dma 4 rom dc00 slot 3 - Hyperam MC 32/16[32Mb RAM] EMS window: c000-c3ff slot 4 - 3Com EtherLink/MC port: 300 irq 12 rom c800 slot 5 - Hyperam MC 32/16[23Mb RAM] EMS window: c400-c7ff slot 6 - BusLogic 32bit BusMaster MCA-to-SCSI Host Adapter (v1.42a) port: 334 irq 14 dma 5 slot 7 - BusLogic...[same as above] port: 234 irq 11 dma 6 slot 8 - BusLogic...[same as above] port: 134 irq 10 dma 7 [there are 11 scsi disks spread across the 4 controllers] And now finally to the nitty-gritty: Here is the output from a successfull boot: [options KBDIO_DEBUG, NPX_DEBUG, DIAGNOSTIC, DEBUG are also in kernel] [start script] Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 FreeBSD/i386 bootstrap loader, Revision 0.7 639/63488kB (jkh@cathair, Tue May 18 03:22:02 GMT 1999) kernel text=0x1289fb data=0x1c478+0x19d5c syms=[0x4+0x1e780+0x4+0x201fb] Please insert MFS root floppy and press enter: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. disk0s4a: disk0s4a: boot -v Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #4: Tue Aug 31 17:39:32 EST 1999 [EMAIL PROTECTED]:/fast1/src/sys/compile/MCA Calibrating clock(s) ... i8254 clock: 1193221 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CPU: i486 DX2 (486-class CPU) Origin = "GenuineIntel" Id = 0x435 Stepping = 5 Features=0x3FPU,VME real memory = 66060288 (64512K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00589000 - 0x03efdfff, 60248064 bytes (14709 pages) avail memory = 58454016 (57084K bytes) BIOS SDT: model 0xf8, submodel 0x1b, bios_rev 0x00 BIOS SDT: features 0xf6MCABUS,EBDA,KBDINT,RTC,IC2 MicroChannel Architecture System detected. Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel" at 0xc057. Preloaded mfs_root "/mfsroot" at 0xc057009c. Math emulator present npx_probe: start npx_probe1: start npx_probe1: device_set_desc npx_probe1: fnstsw npx_probe1: status $0 npx_probe1: end npx_probe: end npx0: math processor on motherboard npx0: 387 emulator mca_probe... POS REG 00 01 02 03 04 05 06 07 --- mca slot 1: 8f 60 b1 02 fd 60 ff ff mca slot 2: 1f 0f 01 3b ff b4
Re: [mount.c]: Option user-patch
On Tue, Aug 31, 1999, Doug Rabson wrote: On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a "user"-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * [EMAIL PROTECTED] * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. http://www.freebsd.org/~adrian/usermount/ Read the README, I wrote this in a hurry, and its more a proof of concept things more than anything else.. Comments welcome. Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD MCA
On Tue, 31 Aug 1999, Matthew N. Dodd wrote:
Did I maybe forget to mention adding the line to sys/i386/conf/files.i386?
i386/mca/aha_mca.c optionalmca aha
yes.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
free space problem
Hello, I am using 3.2-Stable and I have a 9GB disk drive used as cache for squid proxy. I have changed the min free space with tunefs program to 0 but now I have a problem. Even though I have 250MB free space on the file system, I get file system full error. usr/local/squid/cache/disk1: write failed, file system is full cp: ./backup.28-08-1999.tgz: No space left on device turkey:/usr/local/squid/cache/disk1#df Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a25406390875 14286339%/ /dev/da0s1f 3432241 1684020 147364253%/usr /dev/da0s1e127023 1234 115628 1%/var /dev/da1s1e 8617428 8363169 25425997% /usr/local/squid/cache/disk1 /dev/da2s1e 8617428 7696737 92069189% /usr/local/squid/cache/disk2 procfs 440 100%/proc turkey:/usr/local/squid/cache/disk1# the output below is taken later after I deleted that big backup file with the -i option of the df command Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on /dev/da0s1a25406390875 14286339%5518 57968 9% / /dev/da0s1f 3432241 1686306 147135653% 50425 807621 6% /usr /dev/da0s1e127023 1243 115619 1% 148 31594 0% /var /dev/da1s1e 8617428 7775826 84160290% 700170 145842032% /usr/local/squid/cache/disk1 /dev/da2s1e 8617428 7717658 89977090% 708745 144984533% /usr/local/squid/cache/disk2 procfs 440 100% 37 495 7% /proc turkey:/root# how come this is possible? also if now I am not able to use 250MB then is this mean that when the min free space was 8% which makes nearly 650MB of space; the system was not able to use 650MB of space for the defragmentation etc. stuff? because we are not able to access to 250MB so 400MB is left for the space and time optimazation thingies? also if I had 500MB hard drive then 8% would make 40MB but even under same load if I had 5000MB hard drive then 8% makes 400MB which is a lot of space... is not it possible for ffs to work with 40MB again? why does it need more space for time optimization? Evren Yurtesen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
troubles with ipfw!
Hai!, Is the add option in ipfw removed? if i do a simple thing like : ipfw add pass tcp from any to any setup ipfw: setsockopt(IP_FW_ADD): Invalid argument please give me some hints.. Thanks in advance!. - Martin - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: free space problem
:Hello, : :I am using 3.2-Stable and I have a 9GB disk drive used as cache for :squid proxy. I have changed the min free space with tunefs program to 0 :but now I have a problem. Even though I have 250MB free space on the :file system, I get file system full error. : :usr/local/squid/cache/disk1: write failed, file system is full :cp: ./backup.28-08-1999.tgz: No space left on device You may have run out of inodes. Do a 'df -i' If this is the case you will have to newfs the filesystem again, this time using the -i option to change the inode ratio. Use df -i to see where you are now. Take the system offline. Make sure you have saved whatever data you need to save from the squid cache(s) unmount the filesystem(s) newfs them using varying values for the inode ratio. The smaller the value, the more inodes you will have. For example: newfs -i 8192 (thefilesystem) newfs -i 6144 (thefilesystem) newfs -i 4096 (thefilesystem) newfs will tell you how many inodes/cyl which you multiply by the number of cylinders to get the total. Find a value for -i that matches what you believe is appropriate for the filesystem based on your previous experience. You can also mount the filesystem and 'df -i' to see how many inodes you created. Then unmount it and newfs with a different value and see how that works. Etc... Be careful not to accidently newfs an active filesystem! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: troubles with ipfw!
On Tue, Aug 31, 1999, Martin Borghoff wrote: Hai!, Is the add option in ipfw removed? if i do a simple thing like : ipfw add pass tcp from any to any setup ipfw: setsockopt(IP_FW_ADD): Invalid argument please give me some hints.. Have you either: a.) Loaded /modules/ipfw.ko? b.) Enabled the IPFIREWALL option in your kernel and recompiled the system? -- |Chris Costello [EMAIL PROTECTED] |When in doubt, don't bother. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: readdir() broken?
On Tue, Aug 31, 1999 at 11:15:49AM +0100, Doug Rabson wrote: [...] Attached is a patch for GNU fileutils-4.0 that will make rm yield when the workaround code catches a bad readdir(). Are you using a FreeBSD port for GNU fileutils? If so, your patch should be directed to the port maintainer. I suggest that you also forward the patch to the GNU fileutils maintainers. I'm not aware of a FreeBSD port, but I will send a patch to the GNU fileutils maintainer. I just would like to fix our readdir() rather than struggling with the symptoms. Unfortunately I have no idea how to deal with this target. The first thing I did was finding out where to look for the bug---in GNU rm or in FreeBSD readdir(). The Single Unix Specification Version 2 says: [...] files may be removed from a directory or added to a directory asynchronously to the operation of readdir(). [...] and [...] If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified. [...] But what happens here is the stream position pointer get mixed up and it seems that it skips one or two directory entries on susequent calls to readdir(). So I think it should be concidered as broken. I started looking at nfs_vnops.c but at the time I have no idea how it works. Björn -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L+++(--) !E W- N+ o+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: troubles with ipfw!
If you're cvsuping to -stable or -current, rebuild world and rebuild kernel. Binary compatibility got broken somewhere in there.. Chuck Youse Director of Engineering CyberSites, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Martin Borghoff Sent: Tuesday, August 31, 1999 1:26 PM To: [EMAIL PROTECTED] Subject: troubles with ipfw! Hai!, Is the add option in ipfw removed? if i do a simple thing like : ipfw add pass tcp from any to any setup ipfw: setsockopt(IP_FW_ADD): Invalid argument please give me some hints.. Thanks in advance!. - Martin - 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-hackers" in the body of the message
Re: make aout-to-elf-build Failing
On Tue, Aug 31, 1999 at 08:27:00AM -0700, Doug wrote: John Birrell wrote: The solution is to fix `make'. I could commit the fix, but I'm not in a position to build -stable just now. I'm not supposed to commit without testing. The fix looks straight forward though, so "it should just work". 8-) If all it takes is a make world (as opposed to make upgrade) I can test it if you'll send me the patch. I'm on 3.2-Stable as of 8/8 right now. If you've already upgraded, it's too late to test the patch because you won't execute the code in question. Do I really need to send you a patch to change one word in /usr/src/usr.bin/make/main.c?! Please take a few moments to have a look for "unknown" in that file. Sigh. If there is someone with a scratch disk on which they can install 2.2.8 (or 2.2.7 or 2.2.6) and do a `make aout-to-elf' and report the results, we could get this sorted out. I don't have the hardware to do that anymore. Any list-lurkers want to help out? -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make aout-to-elf-build Failing
On Wed, 1 Sep 1999, John Birrell wrote: If there is someone with a scratch disk on which they can install 2.2.8 (or 2.2.7 or 2.2.6) and do a `make aout-to-elf' and report the results, we could get this sorted out. I don't have the hardware to do that anymore. Any list-lurkers want to help out? Assuming I can find my 2.2.6 CDs, I will do this tonight. You don't even need to send me the patch. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
In message [EMAIL PROTECTED] Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Nope. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
AHA-1640 driver (MCA)
I've got what I think is a working MCA shim for the AHA driver. I'd like someone with an MCA box and an aha-1640 to test it for me as my 1640 isn't here yet. Please see: http://www.jurai.net/~winter/mca/README.aha If you've not seen the MCA bus code that this driver requires also see: http://www.jurai.net/~winter/mca/README.mca I'm working on an MCA bus shim for the Buslogic/Bustek/StorageTek cards too and will post information regarding that driver later tonite. Thanks! -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Buslogic/Bustek/Storage Dimensions driver (MCA)
I've got what I think is a working MCA shim for the 'BT' driver. I'd like someone with an MCA box and one of these cards to test it for me as I have not yet found a card to. (Anyone want to give me one?) Please see: http://www.jurai.net/~winter/mca/README.bt If you've not seen the MCA bus code that this driver requires also see: http://www.jurai.net/~winter/mca/README.mca Thanks! -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Minor patches to pwd_mkdb
Got tired of the dinky cachesize for pwd_mkdb, especially since vipw
doesn't take advantage of the -u or -s options.
So here a couple patches that make the cachesize tweakable from make.conf.
Dramatically helps on those 10-15k line password files.
I would appreciate it if somebody would at least consider committing
this...
*** Makefile.orig Tue Aug 31 18:01:58 1999
--- MakefileTue Aug 31 18:22:05 1999
***
*** 3,8
PROG= pwd_mkdb
SRCS= pw_scan.c pwd_mkdb.c
MAN8= pwd_mkdb.8
! CFLAGS+= -DPASSWD_IGNORE_COMMENTS
.include bsd.prog.mk
--- 3,23
PROG= pwd_mkdb
SRCS= pw_scan.c pwd_mkdb.c
MAN8= pwd_mkdb.8
! PWD_MKDB_DEFAULT_CACHESIZE=2
! CFLAGS+= -DPASSWD_IGNORE_COMMENTS
!
! #
! # The cache size defaults to 2MB. If you have a large passwd file
! # increasing the size of the cache will help.
! # There is a command line option to set this, however, it is not
! # set by vipw.
! #
!
! .if defined(PWD_MKDB_CACHESIZE)
! CFLAGS+= -DPWD_MKDB_DEFAULT_CACHESIZE=${PWD_MKDB_CACHESIZE}
! .else
! CFLAGS+= -DPWD_MKDB_DEFAULT_CACHESIZE=${PWD_MKDB_DEFAULT_CACHESIZE}
! .endif
!
.include bsd.prog.mk
*** pwd_mkdb.c.orig Tue Aug 31 18:10:47 1999
--- pwd_mkdb.c Tue Aug 31 18:12:04 1999
***
*** 71,77
4096, /* bsize */
32, /* ffactor */
256,/* nelem */
! 2048 * 1024,/* cachesize */
NULL, /* hash() */
0 /* lorder */
};
--- 71,77
4096, /* bsize */
32, /* ffactor */
256,/* nelem */
! PWD_MKDB_DEFAULT_CACHESIZE * 1024 * 1024, /* cachesize */
NULL, /* hash() */
0 /* lorder */
};
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: make aout-to-elf-build Failing
On Wed, 1 Sep 1999, John Birrell wrote: On Tue, Aug 31, 1999 at 08:27:00AM -0700, Doug wrote: John Birrell wrote: a patch to change one word in /usr/src/usr.bin/make/main.c?! Please take a few moments to have a look for "unknown" in that file. Sigh. If there is someone with a scratch disk on which they can install 2.2.8 (or 2.2.7 or 2.2.6) and do a `make aout-to-elf' and report the results, we could get this sorted out. I don't have the hardware to do that anymore. Any list-lurkers want to help out? The obvious one-line fix appears to work. My 2.2.6 to RELENG_3 build hasn't finished yet, but it makes it past the point where it fails due to machine_arch be ing undefined. Do I need to check if 2.2.6 to -CURRENT works? David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Buslogic/Bustek/Storage Dimensions driver (MCA)
On Wed, 1 Sep 1999, Andy Farkas wrote:
I've got what I think is a working MCA shim for the 'BT' driver.
not quite...
The io, irq and drq values are correct on both aha bt...
aha0 is still failing the INQUIRE command...
if (reply_len != reply_buf_size) {
/* Too much or too little data received */
return (EMSGSIZE);
}
aha0: Adaptec AHA-1640 SCSI Adapter io 0x330-0x333, irq 15, drq 4
aha0: on mca0 id 0f1f slot 2
aha0: INQUIRE failed 28
This should read:
aha0: INQUIRE failed 0x28
since 'error' is printed in hex. Why we're printing errors in hex I don't
know (other than to make me waste 10 minutes tracing down bugs that don't
exist that is.)
Now, anyone have a good idea why AOP_INQUIRE_BOARD_ID is getting too much
or too little data?
Andy, try changing sys/dev/aha.c:aha_cmd() so that the test before the
last return() looks like this:
if (reply_len != reply_buf_size) {
+ printf("reply_len %d, reply_buf_size %d\n",
+ reply_len, reply_buf_size);
/* Too much or too little data received */
return (EMSGSIZE);
}
/* We were successful */
return (0);
}
And show me the line when the error occurs.
aha0: Card not responding!
I added this message for some reason or another. Its not really helpful
at all. :)
device_probe_and_attach: aha0 attach returned -1
mca0: unknown card (id 0x7007, enabled) at slot 3
mca0: unknown card (id 0x6042, enabled) at slot 4
mca0: unknown card (id 0x7007, enabled) at slot 5
bt0: BusLogic 32 Bit Bus Master MCA-to-SCSI Host Adapter (v1.50)
bt0: io 0x334-0x337, irq 14, drq 5 on mca0 id 0708 slot 6
panic: contigmalloc1: size must not be 0
I've rewritten the bt_mca driver to hopefully do the right thing. I was
trying to avoid excess code but I'll worry about trimming stuff down
later.
Get the new versions of {aha,bt}_mca.c and recompile.
Thanks for doing such a good job of testing!
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Tulip device driver question
I am modifying the tulip device driver to support this xircom card. I have it
almost entirely working, *except* that it goes into infinite re-neogitiate
loops. The card probes correctly at bootup, but any attempt to change
information via ifconfig ("ifconfig de0 inet ..." and "ifconfig de0 up",
and "ifconfig de0 media 10baseTX" will all do it) results in it probing,
then resetting, then probing again. over and over in an infinite loop.
Ideas?
--
David Cross | email: [EMAIL PROTECTED]
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself. | WinNT:Linux::Linux:FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Mark Murray writes : Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. Important thing to remember, and Mark and I have discussed this a little (I think we need a couple more beers when I come to Cape Town next week) there are countries like South Africa, which are not Wassennaar signataries. That makes SA a safe haven for crypto code. grin Geoff. -- Geoff Rehmet, The Internet Solution [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] tel: +27-83-292-5800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP address caching bug?
On Fri, 27 Aug 1999, Dennis wrote: It seems that an interface configured with an address, which is then deleted, and then set to a different address on the same network, the machine continues to use the original address although all evidence of it is gone. examples. ifconfig fxp0 207.252.1.31 netmask 255.255.255.0 ping something,and the .31 address is sent out. ifconfig fxp0 delete ifconfig ftp0 207.252.1.60 netmask 255.255.255.0 ping something, and the .31 address is still sent! something is cached somewhere, because ifconfig and route show the correct entries. Dennis Maybe deleting the arp entry for the old IP will bring it around. - Barrett To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.2-s nfsv3/udp server daily panic
: :cvsuped 18 aug 1999 00:35 MSD : I would definitely update it, but that may not be your problem. If you could email your mount setup (df output) and your kernel configuration (dmesg output) I would appreciate it. If you are running softupdates, try turning it off (but I doubt this is the problem). we dont run softupdate because of posible problems with nfs+softupdate This could be a new bug. -Matt Matthew Dillon dil...@backplane.com df on nfsserver : Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a 2977230 2137569 60148378%/ /dev/da1e26113904 16289356 773543668%/public procfs 440 100%/proc df on one of nfsclients: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a 1488607 1114748 25477181%/ procfs 440 100%/proc 10.0.1.2:/public/nfsroot 26113904 16289840 773495268% /public/nfsroot dmesg on nfsserver: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Thu Aug 18 02:54:22 MSD 1999 root@:/usr/src/sys/compile/NFSSERVER Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 299942298 Hz CPU: Pentium II (299.94-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping = 4 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 536870912 (524288K bytes) avail memory = 519643136 (507464K bytes) Preloaded elf kernel kernel at 0xc028c000. Probing for devices on PCI bus 0: chip0: Intel 82443LX host to PCI bridge rev 0x03 on pci0.0.0 chip1: Intel 82443LX PCI-PCI bridge rev 0x03 on pci0.1.0 chip2: DEC 21050 PCI-PCI bridge rev 0x02 on pci0.9.0 ahc0: Adaptec aic7880 Ultra SCSI adapter rev 0x01 int a irq 9 on pci0.11.0 ahc0: Using left over BIOS settings ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x01 int a irq 9 on pci0.15.0 fxp0: Ethernet address 00:a0:c9:1d:b3:df fxp1: Intel EtherExpress Pro 10/100B Ethernet rev 0x02 int a irq 11 on pci0.16.0 fxp1: Ethernet address 00:a0:c9:82:17:9f vga0: Cirrus Logic GD5446 SVGA controller rev 0x00 on pci0.18.0 chip3: Intel 82371AB PCI to ISA bridge rev 0x01 on pci0.20.0 chip4: Intel 82371AB Power management controller rev 0x01 on pci0.20.3 Probing for devices on PCI bus 1: Probing for devices on PCI bus 2: ahc1: Adaptec 3940 Ultra SCSI adapter rev 0x00 int a irq 10 on pci2.4.0 ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: Adaptec 3940 Ultra SCSI adapter rev 0x00 int a irq 5 on pci2.5.0 ahc2: aic7880 Wide Channel B, SCSI Id=7, 16/255 SCBs Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa npx0 on motherboard npx0: INT 16 interface vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa Waiting 2 seconds for SCSI devices to settle da1 at ahc1 bus 0 target 1 lun 0 da1: IFT 3102 0131 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 26049MB (53349312 512 byte sectors: 255H 63S/T 3320C) da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST34572W 0876 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4340MB (924 512 byte sectors: 64H 32S/T 4340C) changing root device to da0s1a To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). FreeBSD has the src/crypto directory for this purpose. It works in exactly the same way as src/contrib, but contains code that may get Americans into trouble if they export it, so I maintain a copy in South Africa (on internat.freebsd.org). I'll be very happy to work with you on this one. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
KAME team really needs your suggestions on how to integrate crypto part. In case of NetBSD/KAME integration, we did like this: - place IPsec core part and AH part into cvs.netbsd.org (in US) - place ESP part and crypto algorithms (DES, Blowfish and whatever in cvs.fi.netbsd.org (in finland) We need some tricky symbolic link, or makefile/config hack for this separated repository (NetBSD has makefile and config hack). FreeBSD has the src/crypto directory for this purpose. It works in exactly the same way as src/contrib, but contains code that may get Americans into trouble if they export it, so I maintain a copy in South Africa (on internat.freebsd.org). I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). itojun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More than 32 signals. Thought?
On Mon, 30 Aug 1999 12:26:06 CST, Warner Losh wrote: : On LITTLE_ENDIAN machines? Endian shouldn't matter. Yup, it was the kind of stupid comment someone who doesn't actually know what's going on would make. ;-) I hadn't cottoned on to the notion of using an array. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Sharing file descriptors
bri...@wintelcom.net (Alfred Perlstein) writes: 1) file descriptor passing (described in Unix Network Programming Vol I) Or just read recv(2), search for SCM_RIGHTS. 2) shared address fork (should be on http://lt.tar.com) Or just read rfork(2), and you don't need to share the address space. The general idea of software server redundancy seems a bit odd, though, debugging the software carefully and automatically restarting it on failures is generally a better idea. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: seek to negative offset?
On Tue, Aug 24, 1999 at 04:25:26PM -0400, John W. DeBoskey wrote: The subject says it all... We have some code that scans files backwards... In looking through /usr/src/sys/kern/vfs_syscalls.c I can't see where we do any validation on the resulting seek location... Do the appropriate folks think this is a bug? How about posix? Should I go ahead and submit a pr with a patch? I've just discovered kern/6184 (from Mar 1998, state: open). Seems like patch which fixes it was never commited. V. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: icmp raw sockets
On Mon, Aug 30, 1999 at 05:34:00PM -0700, Dima Dorfman wrote: hi, i was reading some of the mailing list archives to get an answer to 'why dont icmp echo requests get passed to the raw sockets', and now that i have the answer i was wondering... is there a way to tell the kernel NOT to process echo/timestamp/mask requests and instead pass those to the raw sockets? i'm looking for a solution that doesnt involve kernel modifications. thanks in advance, --dima divert(4)? -- Ruslan Ermilov Sysadmin and DBA of the r...@ucb.crimea.ua United Commercial Bank, r...@freebsd.orgFreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
In message 10335.936082...@localhost, Jordan K. Hubbard writes: Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have kern-developer still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have kern-developer still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
FYI, There are crypto-related files in the following locations. I'll take a detailed look into both repositories... Thanks! It makes the most sense to keep this exactly as it it, except for the files in src/sys/netinet6/ which should move to src/sys/crypto/ if they have crypto in them. Please do not import this until we (JDP!) gets the distribution channels crypto-happy. This is not difficult. itojun src/sys/netinet6/esp_output.c src/sys/netinet6/esp_input.c src/sys/netinet6/esp_core.c src/sys/crypto/cast128/cast128.c src/sys/crypto/cast128/cast128.h src/sys/crypto/cast128/cast128_cbc.c src/sys/crypto/cast128/cast128_subkey.h src/sys/crypto/blowfish/bf_cbc.c src/sys/crypto/blowfish/bf_cbc_m.c src/sys/crypto/blowfish/bf_enc.c src/sys/crypto/blowfish/bf_locl.h src/sys/crypto/blowfish/bf_pi.h src/sys/crypto/blowfish/bf_skey.c src/sys/crypto/blowfish/blowfish.h src/sys/crypto/des/des_3cbc.c src/sys/crypto/des/des.h src/sys/crypto/des/des_cbc.c src/sys/crypto/des/des_ecb.c src/sys/crypto/des/des_locl.h src/sys/crypto/des/des_setkey.c src/sys/crypto/des/podd.h src/sys/crypto/des/sk.h src/sys/crypto/des/spr.h -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
On Tue, 31 Aug 1999, Mark Murray wrote: I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. I would prefer src/sys/crypto. I tend to have a lot of kernel-only trees around for my work and the more self-contained they are the better. Moving softupdates into sys/crypto was a good thing (IMHO). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Hmmm. That's a point. I was thinking primarily of the segregate the crypto issue, but you're right that this would also put us back to the bad old days where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) - Jordan In message 10335.936082...@localhost, Jordan K. Hubbard writes: Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I'd say it makes a lot of sense. Yes, but shouldn't it be src/sys/crypto if we want to have kern-developer still have a sensible meaning ? (and for all the other reasons which made us move src/contrib/sys to src/sys/contrib) -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
In message 506.936093...@localhost, Jordan K. Hubbard writes: Hmmm. That's a point. I was thinking primarily of the segregate the crypto issue, but you're right that this would also put us back to the bad old days where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) That's certainly an improvement in that particular battle :-) -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD???
On Sat, 28 Aug 1999, Sergey Babkin wrote:
Mark Ovens wrote:
On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote:
A funny thing is that Microsoft is porting essentially a
32-bit version of Windows to Merced. All the programs for
Windows that want to use 64-bit support will have to be
modified because the MS compiler defines both int and long
as 32-bit. On the other hand the Unix compilers (at least
UnixWare and as far as I understood that's the common Unix
convention) provide a mode with 64-bit longs that gives
certain degree of 64-bit awareness just by recompiling.
marder-1:/usr/marko{57}% cat size.c
#include stdio.h
int main (void)
{
printf(short == %d\n, sizeof(short));
printf(int == %d\n, sizeof(int));
printf(long == %d\n, sizeof(long));
printf(long long == %d\n, sizeof(long long));
return(0);
}
^D
marder-1:/usr/marko{57}% cc !$
marder-1:/usr/marko{57}% ./a.out
short == 2
int == 4
long == 4
long long == 8
marder-1:/usr/marko{57}%
And the same is true on SunOS 4.1.x as well (although not 100% sure
about long long).
I was talking about compilers for the 64-bit machines. As far
as I understood to make porting easier the major Unix vendors
have agreed on 2 64-bit modes in addition to the compatibility
32-bit mode:
- 32-bit int, 32-bit long, 64-bit long long, 64-bit pointers
- 32-bit int, 64-bit long, 64-bit long long, 64-bit pointers
While the 64-bit Windows NT has 32-bit int, 32-bit long,
64-bit long long, 32-bit pointers, 64-bit some special
kind of pointers.
Oh my god, please say it isn't true! Its the return of the Large Model...
Much of my prejudices against Wintel were formed by trying to write
programs in the large model.
Although I may be confusing something.
I sure hope so.
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: readdir() broken?
On Sun, 29 Aug 1999, Bjoern Fischer wrote: Hello Doug, hello Matthew, hello list members, there are some hints that readdir() in -STABLE has problems when used on NFSv3 (UDP; and TCP probably, too) mounted file systems. The reason may be the recovery code for stale READDIR cookies. The problem occurs when using GNU rm (fileutils-4.0) on our systems (NFS servers and clients -STABLE) for deleting large directory trees (e.g. egcs source tree). rm failed to delete some directories: rm: cannot remove directory `egcs-1.1.2/gcc': Directory not empty I've roughly looked through the sources and found a workaround for a readdir() bug on SunOS 4.1.4. The SunOS readdir() sometimes returned NULL although there were still entries to be read when a directory with more than 254 entries was previously modified. The workaround rewound the directory stream and read it again. Interestingly this workaround also works for FreeBSD although our readdir() passes the autoconfig tests that trigger the workaround without a hinch. Attached is a patch for GNU fileutils-4.0 that will make rm yield when the workaround code catches a bad readdir(). Are you using a FreeBSD port for GNU fileutils? If so, your patch should be directed to the port maintainer. I suggest that you also forward the patch to the GNU fileutils maintainers. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a user-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More than 32 signals. Thought?
On Mon, 30 Aug 1999, Francis Jordan wrote:
Marcel Moolenaar wrote:
[cc'd to David E. Cross (cro...@cs.rpi.edu) and James Raynard
(jrayn...@freebsd.org)]
I'm thinking about extending the number of signals. I like your thoughts
and opinions.
Basicly what I'm going to do is rewrite the signalling code to use a new
sigset_t and provide new syscalls to use it. The current syscalls convert
between the current and the new types for compatibility. I think I'm going
to borrow a thought or two from Linux which allows further increasing of
the number of signals without rewriting the logic, but that's basicly
undecided yet and open for discussion.
Do as NetBSD does to remain compatible? Or borrow a few thoughts from
Solaris, which also has 128 signals:
typedef struct {/* signal set type */
unsigned long __sigbits[4];
} sigset_t;
Please be careful with your datatypes when formulating this. If you are
going to pack 32 signals into one field, make it u_int32_t, not int or
long.
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: ndc(8)
* Jeroen Ruigrok/Asmodai (asmo...@wxs.nl) [990829 14:40]: They shouldn't. That's what we have /var for like you said. OK, I totally agree that named should dump to /var/somegoodpath but this I guess falls out of my own hacking limits. I think we need a desiscion if to move named dumps from /etc/namedb to /var/namedb perhaps. And where does a default named dump it? Any commiter that can decide this? Anders -- Anders Anderssonand...@sanyusan.se Sanyusan International AB http://www.sanyusan.se/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More than 32 signals. Thought?
Doug Rabson wrote:
On Mon, 30 Aug 1999, Francis Jordan wrote:
Do as NetBSD does to remain compatible? Or borrow a few thoughts from
Solaris, which also has 128 signals:
typedef struct {/* signal set type */
unsigned long __sigbits[4];
} sigset_t;
Please be careful with your datatypes when formulating this. If you are
going to pack 32 signals into one field, make it u_int32_t, not int or
long.
I also was not quite happy with the choice of type for __sigbits. Is it
worth having __sigbits to be the size that most suits the architecture (32
for i386; 64 for alpha) because of the frequent bit manipulations that are
expected to be performed with it?
--
Marcel Moolenaar mailto:mar...@scc.nl
SCC Internetworking Databases http://www.scc.nl/
Amsterdam, The Netherlands tel: +31 20 4200655
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Hmmm. That's a point. I was thinking primarily of the segregate the crypto issue, but you're right that this would also put us back to the bad old days where sys/ was broken across multiple directories. Hmph. I guess common sense wins over ITAR in this case. :) Yes, this is very pity... Hoping to see more open US export policy in the near future. KAME has options IPSEC (framework, authentication and compression) and options IPSEC_ESP (encryption) separately defined. Therefore, even if you do not have access to South Africa, you can use AH and IPComp. itojun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: make aout-to-elf-build Failing
On Mon, Aug 30, 1999 at 03:55:42PM -0700, Doug wrote: `make' has changed. Ok, that's the cause then, so what's the solution? :) And meanwhile is it going to hurt anything if I put a suggestion on my 'make upgrade' web page that users do 'make -DMACHINE_ARCH=i386 upgrade' as a temporary measure to get the thing to work? The solution is to fix `make'. I could commit the fix, but I'm not in a position to build -stable just now. I'm not supposed to commit without testing. The fix looks straight forward though, so it should just work. 8-) -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
New boot loader
I developed boot loader, which is more powerful and looks better than boot loader, which is usually installed with FreeBSD release. I used it for a long time and decided to send it to FreeBSD. I haven't own home page and can't give you URL where you can read information about my boot loader. So, here it is some lines from README (as description) and UUEencoded full packet of my boot loader. Please analyze this and say what you think about it. Sorry, if you aren't interesting in my boot loader and I took some your time. - 1 Q: What is UNILOAD? A: UNILOAD (UNIversal LOADer) is a program, which allows to boot OS from any partition from any of 4 hard disk. It is a replacement for the ordinary master boot record. - 3 Q: You said that UNILOAD takes more than one sector on hard disk. So, it uses MBR and some sectors. Does it damage my information? A: Usually first partition on hard disk begin from track 0 head 1 sector 1 and some sectors from track 0 head 0 sector 1 to track 0 head 1 sector 1 are free. That's why it doesn't damage your information. - 5 Q: How can I be sure that UNILOAD didn't damage my information? A: When you run UNILOAD install program it will check your partition table and inform you about problems. - 6 Q: What does it look like? A: On my computer it looks like: Booted from hdd0: 00: DOS 16-bit =32 02: Linux native 03: BSD/386 Command [press m for help]: _ String ... really is highlighted bar. I can choose partition by arrows and make bootstrap by pressing Enter button. Also it's possible to press m and view additional options. - 7 Q: I have got 2 (3, 4) hard disks. Is it possible to boot OS from second (third, fourth) disk? A: Yes. UNILOAD automatically detects all hard disks on you computer. You can boot from any partition from any of 4 hard disks. First digit in string shows number of hard disk, second digit represents number of partition on that disk. -28 Q: Can the author give any warranty? Can I give UNILOAD to somebody? A: No, I can't give you any warranty. You should not pay any money for this version of UNILOAD. With UNILOAD binary and install program you should received sources. If you has sources you can analyze them and recompile, so you know what you use. You can copy and distribute this software while original copyright messages are present, provided that sources are included. ** REMEMBER THAT YOU USE UNILOAD ON YOUR OWN RISC ** --- begin 644 uload-10.zip m4$l#!!...@`(`,^8'BO85\...@```#h!```+1de,15])1Y$25I=CD%+ MPU`0A.^!_(YV:(-K8(83P8+(h...@mu'I_)IMFRO;L]CR;^W%5O%NXW'_/ MYNDYVQ?GU]6Q3)-WDDC2SA7BVR)DMG?V'S%%LG[#(\_Q04BR5SNM?E3@ M(=9:NP[[ALH'S7O81)o...@0,:PVJ%4ZN#B=VI\=%RE?Z%[2*@Y'WO*-@ MAT%QD4,D716*U.H_/A-:.U*RM*D*P1_?TN9/p4$h...@%V9MSUG+])D- M#I,B5$HC-D(0BO3-%E[9[5H=U*L'Syo+z[g7x!4$l#!!...@`(`'VC'B=7 M6+,J?A$``*PX```4D5!1$U%O5OK4QNYEO_L5.5_T([V2-L0UY3-D M($...@j0qDFJ:W=*;E;MG7I;OE*:HSO7[_G=Z1^,C.)(%U%1T2T?G_53$ M-SX7)T=O3T_$56_0ZXN9L+3V?C]^=';QX\/QJ+54Z5:GP1JRL]JI:k...@oq MCU(YKTVQ*PNW4A9[\QYVO=?.s@1ghk!2'Q2^TJXYX34^'(_[68G4 MJ/JQ6!E[B7?[(_'5E,))30A@:[7`RTM:GANK\+P0IE#J03]J80VE3D6IW MV1,3TQ7:B](I1_#HWI\(621F?R:HOKB;XG=:E,I=S)?(UT0=R)-`')@?` M?5V?3R0X(Z9Z_EJ^P71/C7B\S(5%G'V!$V1JG$4?$TT!C0IB.Q93.+0/B M#4I3HNM_^/\9Y%W:40T,^929/I2X7S$8%=RLEYH3%4SO=\7!3L,(G#, MNY;.3W-%*3))]/Q,R:'(PP11HXM.T7VJ9=$F=I_6*'(4%R-QNHXK]C, MN7+)1...@?7di+rs*@0W]Y:[),V1ZS#]B'0RJZW8+X0IA))P;]KA@,Z8!20 MZ2\WJ)N\F8S;`GY[4V_$2OL%+Z/-...@w[@/-K^=EEK54;S``Y/AI6)-!(O_ M^?5?G_S+WVJ(P(2DX=;.J[R2$EC7_(@_,LL)3I`1AX%%8#6Q0*!_.2 M)+QB+KS.E9B67A1!,r...@3\`on6$7rbqm(9$E@/\_FB3WMRDK862VF]9D,3 MBABNE7LMWKN542;FTK:#L%JJHH2U(%-%#V1FE4S7#6MP]L$FL]H,TLR' ME1-$DJ7?MT5ZMJK`GZCP2U2%L61PT9@0:4LQJX,EFTUN/0ISBT=`1'%U[1 MP8D75LW!.AQ(;T)V*K;@uq(Z#E:LMUCQ`.I9R\^H:YGX;+VI-[JX=0CV M/1_5JKNIM3--AT11^_52P/5V/GBU40K/I72.#@(I`!1UD+4;,F,7ZTL+ m9w8w...@njp\N9)L%:!ZDW+FAD[5[2`I)\L9#%7+JILJJO*VN*.2$P[^8 M%QQI8]LX=4*#E#!`,.IY/=S[I(21=\XJ=3QA10@(_';V:^]+LKK+AWN M#,Z2A=F$F2C-ZZMCG=:TW#P)ZC=TM._B%A/',73UG(.3$P*ME[PJWW335G M(PV@'.$=1?f0v`...@`t.9`m8e[(Z:RBD:-YD[9B`F3%JM'GPL`)H97$, m=.!\l...@j^7]Z.A8W#^X#K:`LBOU:8O)E0VZRYIF)LO,2A=SDGZA$,2! MS'CO7AKC0U_OGJUM,HY`K`6EVI]-CXKSI8Y4K((8'HSO\6G0#7,X+,(5 M-=%]T!\B1-6\`E+E%X2Z-EXGQ((VUH=3A41E1/6M65J[\2,]S[#WL!V M$C7NWKL(,8IIT*?HV8+DN_,!8[V17H9,F[QJ96Y4H?:4V7#W61P`8@,0 M,RLHEK96%7U.FE_4V8UAA9B:%)[K\:-=,=B]Q\_C1_\QZMS.Q(YG0J! M;?IR1:R6F#?...@j83(YE;F7;%B-DCHA[N93#Q^U`%M2L,08d...@.vk%[
Re: make aout-to-elf-build Failing
John Birrell wrote: On Mon, Aug 30, 1999 at 03:55:42PM -0700, Doug wrote: `make' has changed. Ok, that's the cause then, so what's the solution? :) And meanwhile is it going to hurt anything if I put a suggestion on my 'make upgrade' web page that users do 'make -DMACHINE_ARCH=i386 upgrade' as a temporary measure to get the thing to work? The solution is to fix `make'. I could commit the fix, but I'm not in a position to build -stable just now. I'm not supposed to commit without testing. The fix looks straight forward though, so it should just work. 8-) If all it takes is a make world (as opposed to make upgrade) I can test it if you'll send me the patch. I'm on 3.2-Stable as of 8/8 right now. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
FreeBSD MCA
Righty-o, I've finally got a kernel to boot on my MCA box! Yay! Its a rather large Apricot FTs 486 with the Panther Rev F MB: http://www.mitsubishi-computers.com/insight/en/products/servers/fts/ftsmain.htm It is currently running NT4 (SP5) with all the adapters in it recognised and supported. It is also known to run OS/2 Warp 4, and I once briefly had Solaris 2.4 (x86) on it. Here is what happened while trying to boot FreeBSD... Firstly, the keyboard did not work! It loaded the kernel, and then asked for the mfs disk and said 'press enter to continue' but the keyboard doesn't do anything. The num-lock and caps-locks LEDs do not toggle either. Ok, so I boot using a serial console... yay! I can continue with loading the mfs disk! It loads, then says booting in n seconds..., I press enter, it starts probing! Yay! Oh, hang on, its hanged :( Hmmm. It hangs while probing npx. Ok... vi src/sys/i386/isa/npx.c ... hmmm, lets bypass that if ((status 0xb8ff) == 0) bit and just return 0 - we'll use the emulator... Tada!!! Well, almost... it doesn't grok the AHA-1640 and no disks are found. I will play with your driver over the next couple of days. In case it helps, here is what is in the machine: Motherboard - 8Mb RAM, com1, lpt1, standard VGA slot 1 - Hypertec HyperPort [3 serial, 1 parallel] port: 2f8 irq 3 [only com2 is enabled] slot 2 - AHA-1640 SCSI Host Adapter port: 330 irq 15 dma 4 rom dc00 slot 3 - Hyperam MC 32/16[32Mb RAM] EMS window: c000-c3ff slot 4 - 3Com EtherLink/MC port: 300 irq 12 rom c800 slot 5 - Hyperam MC 32/16[23Mb RAM] EMS window: c400-c7ff slot 6 - BusLogic 32bit BusMaster MCA-to-SCSI Host Adapter (v1.42a) port: 334 irq 14 dma 5 slot 7 - BusLogic...[same as above] port: 234 irq 11 dma 6 slot 8 - BusLogic...[same as above] port: 134 irq 10 dma 7 [there are 11 scsi disks spread across the 4 controllers] And now finally to the nitty-gritty: Here is the output from a successfull boot: [options KBDIO_DEBUG, NPX_DEBUG, DIAGNOSTIC, DEBUG are also in kernel] [start script] Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 FreeBSD/i386 bootstrap loader, Revision 0.7 639/63488kB (j...@cathair, Tue May 18 03:22:02 GMT 1999) kernel text=0x1289fb data=0x1c478+0x19d5c syms=[0x4+0x1e780+0x4+0x201fb] Please insert MFS root floppy and press enter: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. disk0s4a: disk0s4a: boot -v Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #4: Tue Aug 31 17:39:32 EST 1999 r...@doohan.af.speednet.com.au:/fast1/src/sys/compile/MCA Calibrating clock(s) ... i8254 clock: 1193221 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CPU: i486 DX2 (486-class CPU) Origin = GenuineIntel Id = 0x435 Stepping = 5 Features=0x3FPU,VME real memory = 66060288 (64512K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00589000 - 0x03efdfff, 60248064 bytes (14709 pages) avail memory = 58454016 (57084K bytes) BIOS SDT: model 0xf8, submodel 0x1b, bios_rev 0x00 BIOS SDT: features 0xf6MCABUS,EBDA,KBDINT,RTC,IC2 MicroChannel Architecture System detected. Other BIOS signatures found: ACPI: Preloaded elf kernel kernel at 0xc057. Preloaded mfs_root /mfsroot at 0xc057009c. Math emulator present npx_probe: start npx_probe1: start npx_probe1: device_set_desc npx_probe1: fnstsw npx_probe1: status $0 npx_probe1: end npx_probe: end npx0: math processor on motherboard npx0: 387 emulator mca_probe... POS REG 00 01 02 03 04 05 06 07 --- mca slot 1: 8f 60 b1 02 fd 60 ff ff mca slot 2: 1f 0f 01 3b ff b4 ff ff mca slot 3: 07 70 03 bf 88 ff 08 00 mca slot 4: 42 60 09 01 ff ff ff ff mca slot 5: 07 70 45 bf c9 ff 08 00 mca slot 6: 08 07 1d 03 f7 c5 ff ff mca slot 7: 08 07 17 02 00 46 00 30 mca slot 8: 08 07 15 01 00 47 00 30 mca0: MCA bus on motherboard mca0: unknown card (id 0x608f, enabled) at slot 1 mca0: unknown card (id 0x0f1f, enabled) at slot 2 mca0: unknown card (id 0x7007, enabled) at slot 3 mca0: unknown card (id 0x6042, enabled) at slot 4 mca0: unknown card (id 0x7007, enabled) at slot 5 mca0: unknown card (id 0x0708, enabled) at slot 6 mca0: unknown card (id 0x0708, enabled) at slot 7 mca0: unknown card (id 0x0708, enabled) at slot 8 isa0: ISA bus on motherboard fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 aha0: INQUIRE failed 28 aha0: Geometry Register test failed 0x15 aha0: status reg test failed ff aha0: Geometry
Re: FreeBSD MCA
On Wed, 1 Sep 1999, Andy Farkas wrote: Righty-o, I've finally got a kernel to boot on my MCA box! Yay! Its a rather large Apricot FTs 486 with the Panther Rev F MB: http://www.mitsubishi-computers.com/insight/en/products/servers/fts/ftsmain.htm Ah! This is good since it means that Int 0x15 Func 0xc0 detects non-PS/2 machines correctly. The 'BIOS SDT: ...' lines are what we're looking at for this. Since you were good enough to capture an entire verbose boot and transcribed the config of all your cards I'll be able to get working on the Buslogic probe/attach bits. It is currently running NT4 (SP5) with all the adapters in it recognised and supported. It is also known to run OS/2 Warp 4, and I once briefly had Solaris 2.4 (x86) on it. Here is what happened while trying to boot FreeBSD... Firstly, the keyboard did not work! It loaded the kernel, and then asked for the mfs disk and said 'press enter to continue' but the keyboard doesn't do anything. The num-lock and caps-locks LEDs do not toggle either. Ok, so I boot using a serial console... yay! I can continue with loading the mfs disk! It loads, then says booting in n seconds..., I press enter, it starts probing! Yay! Oh, hang on, its hanged :( Hmmm. It hangs while probing npx. Ok... vi src/sys/i386/isa/npx.c ... hmmm, lets bypass that if ((status 0xb8ff) == 0) bit and just return 0 - we'll use the emulator... Weird. I have no idea what the deal is there. Tada!!! Well, almost... it doesn't grok the AHA-1640 and no disks are found. I will play with your driver over the next couple of days. Hummm... I know there are some issues with DMA channels. Did I maybe forget to mention adding the line to sys/i386/conf/files.i386? i386/mca/aha_mca.c optionalmca aha Add that and make sure you have: controller aha0 to your config file. I should probably compile the MCA bus support as a module and compile the drivers as modules as well to make testing a tad easier. In case it helps, here is what is in the machine: Motherboard - 8Mb RAM, com1, lpt1, standard VGA slot 1 - Hypertec HyperPort [3 serial, 1 parallel] port: 2f8 irq 3 [only com2 is enabled] slot 2 - AHA-1640 SCSI Host Adapter port: 330 irq 15 dma 4 rom dc00 slot 3 - Hyperam MC 32/16[32Mb RAM] EMS window: c000-c3ff slot 4 - 3Com EtherLink/MC port: 300 irq 12 rom c800 slot 5 - Hyperam MC 32/16[23Mb RAM] EMS window: c400-c7ff slot 6 - BusLogic 32bit BusMaster MCA-to-SCSI Host Adapter (v1.42a) port: 334 irq 14 dma 5 slot 7 - BusLogic...[same as above] port: 234 irq 11 dma 6 slot 8 - BusLogic...[same as above] port: 134 irq 10 dma 7 [there are 11 scsi disks spread across the 4 controllers] And now finally to the nitty-gritty: Here is the output from a successfull boot: [options KBDIO_DEBUG, NPX_DEBUG, DIAGNOSTIC, DEBUG are also in kernel] [start script] Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 FreeBSD/i386 bootstrap loader, Revision 0.7 639/63488kB (j...@cathair, Tue May 18 03:22:02 GMT 1999) kernel text=0x1289fb data=0x1c478+0x19d5c syms=[0x4+0x1e780+0x4+0x201fb] Please insert MFS root floppy and press enter: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. disk0s4a: disk0s4a: boot -v Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #4: Tue Aug 31 17:39:32 EST 1999 r...@doohan.af.speednet.com.au:/fast1/src/sys/compile/MCA Calibrating clock(s) ... i8254 clock: 1193221 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CPU: i486 DX2 (486-class CPU) Origin = GenuineIntel Id = 0x435 Stepping = 5 Features=0x3FPU,VME real memory = 66060288 (64512K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00589000 - 0x03efdfff, 60248064 bytes (14709 pages) avail memory = 58454016 (57084K bytes) BIOS SDT: model 0xf8, submodel 0x1b, bios_rev 0x00 BIOS SDT: features 0xf6MCABUS,EBDA,KBDINT,RTC,IC2 MicroChannel Architecture System detected. Other BIOS signatures found: ACPI: Preloaded elf kernel kernel at 0xc057. Preloaded mfs_root /mfsroot at 0xc057009c. Math emulator present npx_probe: start npx_probe1: start npx_probe1: device_set_desc npx_probe1: fnstsw npx_probe1: status $0 npx_probe1: end npx_probe: end npx0: math processor on motherboard npx0: 387 emulator mca_probe... POS REG 00 01 02 03 04 05 06 07 --- mca slot 1: 8f 60 b1 02 fd 60 ff ff mca slot 2: 1f 0f 01 3b ff b4
Re: [mount.c]: Option user-patch
On Tue, Aug 31, 1999, Doug Rabson wrote: On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a user-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. You realise that this kind of stuff can be done in kernelspace, without needing yet another setuid binary/binaries.. http://www.freebsd.org/~adrian/usermount/ Read the README, I wrote this in a hurry, and its more a proof of concept things more than anything else.. Comments welcome. Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD MCA
On Tue, 31 Aug 1999, Matthew N. Dodd wrote:
Did I maybe forget to mention adding the line to sys/i386/conf/files.i386?
i386/mca/aha_mca.c optionalmca aha
yes.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |
--
:{ an...@speednet.com.au
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
free space problem
Hello, I am using 3.2-Stable and I have a 9GB disk drive used as cache for squid proxy. I have changed the min free space with tunefs program to 0 but now I have a problem. Even though I have 250MB free space on the file system, I get file system full error. usr/local/squid/cache/disk1: write failed, file system is full cp: ./backup.28-08-1999.tgz: No space left on device turkey:/usr/local/squid/cache/disk1#df Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da0s1a25406390875 14286339%/ /dev/da0s1f 3432241 1684020 147364253%/usr /dev/da0s1e127023 1234 115628 1%/var /dev/da1s1e 8617428 8363169 25425997% /usr/local/squid/cache/disk1 /dev/da2s1e 8617428 7696737 92069189% /usr/local/squid/cache/disk2 procfs 440 100%/proc turkey:/usr/local/squid/cache/disk1# the output below is taken later after I deleted that big backup file with the -i option of the df command Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on /dev/da0s1a25406390875 14286339%5518 57968 9% / /dev/da0s1f 3432241 1686306 147135653% 50425 807621 6% /usr /dev/da0s1e127023 1243 115619 1% 148 31594 0% /var /dev/da1s1e 8617428 7775826 84160290% 700170 145842032% /usr/local/squid/cache/disk1 /dev/da2s1e 8617428 7717658 89977090% 708745 144984533% /usr/local/squid/cache/disk2 procfs 440 100% 37 495 7% /proc turkey:/root# how come this is possible? also if now I am not able to use 250MB then is this mean that when the min free space was 8% which makes nearly 650MB of space; the system was not able to use 650MB of space for the defragmentation etc. stuff? because we are not able to access to 250MB so 400MB is left for the space and time optimazation thingies? also if I had 500MB hard drive then 8% would make 40MB but even under same load if I had 5000MB hard drive then 8% makes 400MB which is a lot of space... is not it possible for ffs to work with 40MB again? why does it need more space for time optimization? Evren Yurtesen yurte...@ispro.net.tr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
troubles with ipfw!
Hai!, Is the add option in ipfw removed? if i do a simple thing like : ipfw add pass tcp from any to any setup ipfw: setsockopt(IP_FW_ADD): Invalid argument please give me some hints.. Thanks in advance!. - Martin - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: free space problem
:Hello, : :I am using 3.2-Stable and I have a 9GB disk drive used as cache for :squid proxy. I have changed the min free space with tunefs program to 0 :but now I have a problem. Even though I have 250MB free space on the :file system, I get file system full error. : :usr/local/squid/cache/disk1: write failed, file system is full :cp: ./backup.28-08-1999.tgz: No space left on device You may have run out of inodes. Do a 'df -i' If this is the case you will have to newfs the filesystem again, this time using the -i option to change the inode ratio. Use df -i to see where you are now. Take the system offline. Make sure you have saved whatever data you need to save from the squid cache(s) unmount the filesystem(s) newfs them using varying values for the inode ratio. The smaller the value, the more inodes you will have. For example: newfs -i 8192 (thefilesystem) newfs -i 6144 (thefilesystem) newfs -i 4096 (thefilesystem) newfs will tell you how many inodes/cyl which you multiply by the number of cylinders to get the total. Find a value for -i that matches what you believe is appropriate for the filesystem based on your previous experience. You can also mount the filesystem and 'df -i' to see how many inodes you created. Then unmount it and newfs with a different value and see how that works. Etc... Be careful not to accidently newfs an active filesystem! -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: troubles with ipfw!
On Tue, Aug 31, 1999, Martin Borghoff wrote: Hai!, Is the add option in ipfw removed? if i do a simple thing like : ipfw add pass tcp from any to any setup ipfw: setsockopt(IP_FW_ADD): Invalid argument please give me some hints.. Have you either: a.) Loaded /modules/ipfw.ko? b.) Enabled the IPFIREWALL option in your kernel and recompiled the system? -- |Chris Costello ch...@calldei.com |When in doubt, don't bother. `-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
In message 28661.936093...@critter.freebsd.dk Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: readdir() broken?
On Tue, Aug 31, 1999 at 11:15:49AM +0100, Doug Rabson wrote: [...] Attached is a patch for GNU fileutils-4.0 that will make rm yield when the workaround code catches a bad readdir(). Are you using a FreeBSD port for GNU fileutils? If so, your patch should be directed to the port maintainer. I suggest that you also forward the patch to the GNU fileutils maintainers. I'm not aware of a FreeBSD port, but I will send a patch to the GNU fileutils maintainer. I just would like to fix our readdir() rather than struggling with the symptoms. Unfortunately I have no idea how to deal with this target. The first thing I did was finding out where to look for the bug---in GNU rm or in FreeBSD readdir(). The Single Unix Specification Version 2 says: [...] files may be removed from a directory or added to a directory asynchronously to the operation of readdir(). [...] and [...] If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified. [...] But what happens here is the stream position pointer get mixed up and it seems that it skips one or two directory entries on susequent calls to readdir(). So I think it should be concidered as broken. I started looking at nfs_vnops.c but at the time I have no idea how it works. Björn -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L+++(--) !E W- N+ o+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: troubles with ipfw!
If you're cvsuping to -stable or -current, rebuild world and rebuild kernel. Binary compatibility got broken somewhere in there.. Chuck Youse Director of Engineering CyberSites, Inc. -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org]on Behalf Of Martin Borghoff Sent: Tuesday, August 31, 1999 1:26 PM To: freebsd-hackers@FreeBSD.ORG Subject: troubles with ipfw! Hai!, Is the add option in ipfw removed? if i do a simple thing like : ipfw add pass tcp from any to any setup ipfw: setsockopt(IP_FW_ADD): Invalid argument please give me some hints.. Thanks in advance!. - Martin - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: make aout-to-elf-build Failing
On Tue, Aug 31, 1999 at 08:27:00AM -0700, Doug wrote: John Birrell wrote: The solution is to fix `make'. I could commit the fix, but I'm not in a position to build -stable just now. I'm not supposed to commit without testing. The fix looks straight forward though, so it should just work. 8-) If all it takes is a make world (as opposed to make upgrade) I can test it if you'll send me the patch. I'm on 3.2-Stable as of 8/8 right now. If you've already upgraded, it's too late to test the patch because you won't execute the code in question. Do I really need to send you a patch to change one word in /usr/src/usr.bin/make/main.c?! Please take a few moments to have a look for unknown in that file. Sigh. If there is someone with a scratch disk on which they can install 2.2.8 (or 2.2.7 or 2.2.6) and do a `make aout-to-elf' and report the results, we could get this sorted out. I don't have the hardware to do that anymore. Any list-lurkers want to help out? -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: make aout-to-elf-build Failing
On Wed, 1 Sep 1999, John Birrell wrote: If there is someone with a scratch disk on which they can install 2.2.8 (or 2.2.7 or 2.2.6) and do a `make aout-to-elf' and report the results, we could get this sorted out. I don't have the hardware to do that anymore. Any list-lurkers want to help out? Assuming I can find my 2.2.6 CDs, I will do this tonight. You don't even need to send me the patch. David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [mount.c]: Option user-patch
so where re you at the moment? julian On Wed, 1 Sep 1999 adr...@freebsd.org wrote: Comments welcome. Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: make aout-to-elf-build Failing
On Wed, 1 Sep 1999, John Birrell wrote: On Tue, Aug 31, 1999 at 08:27:00AM -0700, Doug wrote: John Birrell wrote: The solution is to fix `make'. I could commit the fix, but I'm not in a position to build -stable just now. I'm not supposed to commit without testing. The fix looks straight forward though, so it should just work. 8-) If all it takes is a make world (as opposed to make upgrade) I can test it if you'll send me the patch. I'm on 3.2-Stable as of 8/8 right now. If you've already upgraded, it's too late to test the patch because you won't execute the code in question. I had a feeling that I misunderstood you, which is why I asked for a clarification. Do I really need to send you a patch to change one word in /usr/src/usr.bin/make/main.c?! Please take a few moments to have a look for unknown in that file. Sigh. Straight forward (sic) to you isn't necessarily so to me, especially where issues related to make are concerned. To start with, I wouldn't even have know where to start looking (make code, some other code, *.mk files, make.conf...). If all it took was a simple change you could have said so. Given that someone more knowledgeable than I has already stepped forward, it looks like it will get taken care of anyway, so no sweat. If not, I do have a scratch disk that I can run through the procedure on, and now that I know where to look, yes, the fix is obvious enough. Thanks for your help, Doug -- My mama told me, my mama said, 'don't cry.' She said, 'you're too young a man to have as many women you got.' I looked at my mother dear and didn't even crack a smile. I said, 'If women kill me, I don't mind dyin!' - John Belushi as Joliet Jake Blues, I Don't Know To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
In message 28661.936093...@critter.freebsd.dk Poul-Henning Kamp writes: : Hmph. I guess common sense wins over ITAR in this case. :) : : That's certainly an improvement in that particular battle :-) Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? Nope. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
AHA-1640 driver (MCA)
I've got what I think is a working MCA shim for the AHA driver. I'd like someone with an MCA box and an aha-1640 to test it for me as my 1640 isn't here yet. Please see: http://www.jurai.net/~winter/mca/README.aha If you've not seen the MCA bus code that this driver requires also see: http://www.jurai.net/~winter/mca/README.mca I'm working on an MCA bus shim for the Buslogic/Bustek/StorageTek cards too and will post information regarding that driver later tonite. Thanks! -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Buslogic/Bustek/Storage Dimensions driver (MCA)
I've got what I think is a working MCA shim for the 'BT' driver. I'd like someone with an MCA box and one of these cards to test it for me as I have not yet found a card to. (Anyone want to give me one?) Please see: http://www.jurai.net/~winter/mca/README.bt If you've not seen the MCA bus code that this driver requires also see: http://www.jurai.net/~winter/mca/README.mca Thanks! -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Minor patches to pwd_mkdb
Got tired of the dinky cachesize for pwd_mkdb, especially since vipw
doesn't take advantage of the -u or -s options.
So here a couple patches that make the cachesize tweakable from make.conf.
Dramatically helps on those 10-15k line password files.
I would appreciate it if somebody would at least consider committing
this...
*** Makefile.orig Tue Aug 31 18:01:58 1999
--- MakefileTue Aug 31 18:22:05 1999
***
*** 3,8
PROG= pwd_mkdb
SRCS= pw_scan.c pwd_mkdb.c
MAN8= pwd_mkdb.8
! CFLAGS+= -DPASSWD_IGNORE_COMMENTS
.include bsd.prog.mk
--- 3,23
PROG= pwd_mkdb
SRCS= pw_scan.c pwd_mkdb.c
MAN8= pwd_mkdb.8
! PWD_MKDB_DEFAULT_CACHESIZE=2
! CFLAGS+= -DPASSWD_IGNORE_COMMENTS
!
! #
! # The cache size defaults to 2MB. If you have a large passwd file
! # increasing the size of the cache will help.
! # There is a command line option to set this, however, it is not
! # set by vipw.
! #
!
! .if defined(PWD_MKDB_CACHESIZE)
! CFLAGS+= -DPWD_MKDB_DEFAULT_CACHESIZE=${PWD_MKDB_CACHESIZE}
! .else
! CFLAGS+= -DPWD_MKDB_DEFAULT_CACHESIZE=${PWD_MKDB_DEFAULT_CACHESIZE}
! .endif
!
.include bsd.prog.mk
*** pwd_mkdb.c.orig Tue Aug 31 18:10:47 1999
--- pwd_mkdb.c Tue Aug 31 18:12:04 1999
***
*** 71,77
4096, /* bsize */
32, /* ffactor */
256,/* nelem */
! 2048 * 1024,/* cachesize */
NULL, /* hash() */
0 /* lorder */
};
--- 71,77
4096, /* bsize */
32, /* ffactor */
256,/* nelem */
! PWD_MKDB_DEFAULT_CACHESIZE * 1024 * 1024, /* cachesize */
NULL, /* hash() */
0 /* lorder */
};
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Buslogic/Bustek/Storage Dimensions driver (MCA)
I've got what I think is a working MCA shim for the 'BT' driver.
not quite...
The io, irq and drq values are correct on both aha bt...
aha0 is still failing the INQUIRE command...
disk0s4a: boot -v
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #0: Wed Sep 1 12:13:01 EST 1999
r...@doohan.af.speednet.com.au:/fast1/src/sys/compile/MCA
Calibrating clock(s) ... i8254 clock: 1193222 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz
CPU: i486 DX2 (486-class CPU)
Origin = GenuineIntel Id = 0x435 Stepping = 5
Features=0x3FPU,VME
real memory = 66060288 (64512K bytes)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0058e000 - 0x03efdfff, 60227584 bytes (14704 pages)
avail memory = 58433536 (57064K bytes)
BIOS SDT: model 0xf8, submodel 0x1b, bios_rev 0x00
BIOS SDT: features 0xf6MCABUS,EBDA,KBDINT,RTC,IC2
MicroChannel Architecture System detected.
Other BIOS signatures found:
ACPI:
Preloaded elf kernel kernel at 0xc0575000.
Preloaded mfs_root /mfsroot at 0xc057509c.
Math emulator present
npx0: math processor on motherboard
npx0: 387 emulator
mca_probe...
POS REG 00 01 02 03 04 05 06 07
---
mca slot 1: 8f 60 d0 82 81 60 60 ff
mca slot 2: 1f 0f 01 3b ff b4 ff ff
mca slot 3: 07 70 03 bf 88 ff 08 00
mca slot 4: 42 60 09 01 ff ff ff ff
mca slot 5: 07 70 45 bf c9 ff 08 00
mca slot 6: 08 07 1d 03 f7 c5 ff ff
mca slot 7: 08 07 17 02 00 46 00 30
mca slot 8: 08 07 15 01 00 47 00 30
mca0: MCA bus on motherboard
mca0: unknown card (id 0x608f, disabled) at slot 1
aha0: Adaptec AHA-1640 SCSI Adapter io 0x330-0x333, irq 15, drq 4
aha0: on mca0 id 0f1f slot 2
aha0: INQUIRE failed 28
aha0: Card not responding!
device_probe_and_attach: aha0 attach returned -1
mca0: unknown card (id 0x7007, enabled) at slot 3
mca0: unknown card (id 0x6042, enabled) at slot 4
mca0: unknown card (id 0x7007, enabled) at slot 5
bt0: BusLogic 32 Bit Bus Master MCA-to-SCSI Host Adapter (v1.50)
bt0: io 0x334-0x337, irq 14, drq 5 on mca0 id 0708 slot 6
panic: contigmalloc1: size must not be 0
Automatic reboot in 15 seconds - press a key on the console to abort
-- Press a key on the console to reboot --
Rebooting...
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |
--
:{ an...@speednet.com.au
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: make aout-to-elf-build Failing
On Wed, 1 Sep 1999, John Birrell wrote: On Tue, Aug 31, 1999 at 08:27:00AM -0700, Doug wrote: John Birrell wrote: a patch to change one word in /usr/src/usr.bin/make/main.c?! Please take a few moments to have a look for unknown in that file. Sigh. If there is someone with a scratch disk on which they can install 2.2.8 (or 2.2.7 or 2.2.6) and do a `make aout-to-elf' and report the results, we could get this sorted out. I don't have the hardware to do that anymore. Any list-lurkers want to help out? The obvious one-line fix appears to work. My 2.2.6 to RELENG_3 build hasn't finished yet, but it makes it past the point where it fails due to machine_arch be ing undefined. Do I need to check if 2.2.6 to -CURRENT works? David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Buslogic/Bustek/Storage Dimensions driver (MCA)
On Wed, 1 Sep 1999, Andy Farkas wrote:
I've got what I think is a working MCA shim for the 'BT' driver.
not quite...
The io, irq and drq values are correct on both aha bt...
aha0 is still failing the INQUIRE command...
if (reply_len != reply_buf_size) {
/* Too much or too little data received */
return (EMSGSIZE);
}
aha0: Adaptec AHA-1640 SCSI Adapter io 0x330-0x333, irq 15, drq 4
aha0: on mca0 id 0f1f slot 2
aha0: INQUIRE failed 28
This should read:
aha0: INQUIRE failed 0x28
since 'error' is printed in hex. Why we're printing errors in hex I don't
know (other than to make me waste 10 minutes tracing down bugs that don't
exist that is.)
Now, anyone have a good idea why AOP_INQUIRE_BOARD_ID is getting too much
or too little data?
Andy, try changing sys/dev/aha.c:aha_cmd() so that the test before the
last return() looks like this:
if (reply_len != reply_buf_size) {
+ printf(reply_len %d, reply_buf_size %d\n,
+ reply_len, reply_buf_size);
/* Too much or too little data received */
return (EMSGSIZE);
}
/* We were successful */
return (0);
}
And show me the line when the error occurs.
aha0: Card not responding!
I added this message for some reason or another. Its not really helpful
at all. :)
device_probe_and_attach: aha0 attach returned -1
mca0: unknown card (id 0x7007, enabled) at slot 3
mca0: unknown card (id 0x6042, enabled) at slot 4
mca0: unknown card (id 0x7007, enabled) at slot 5
bt0: BusLogic 32 Bit Bus Master MCA-to-SCSI Host Adapter (v1.50)
bt0: io 0x334-0x337, irq 14, drq 5 on mca0 id 0708 slot 6
panic: contigmalloc1: size must not be 0
I've rewritten the bt_mca driver to hopefully do the right thing. I was
trying to avoid excess code but I'll worry about trimming stuff down
later.
Get the new versions of {aha,bt}_mca.c and recompile.
Thanks for doing such a good job of testing!
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Tulip device driver question
I am modifying the tulip device driver to support this xircom card. I have it almost entirely working, *except* that it goes into infinite re-neogitiate loops. The card probes correctly at bootup, but any attempt to change information via ifconfig (ifconfig de0 inet ... and ifconfig de0 up, and ifconfig de0 media 10baseTX will all do it) results in it probing, then resetting, then probing again. over and over in an infinite loop. Ideas? -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: KAME IPv6 and freebsd
Mark Murray writes : Speaking of ITAR, has anybody actually every approached FreeBSD to say what we're doing is in violation of ITAR? IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days (at least outside the USA). The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all passing the buck very fast nowadays. Important thing to remember, and Mark and I have discussed this a little (I think we need a couple more beers when I come to Cape Town next week) there are countries like South Africa, which are not Wassennaar signataries. That makes SA a safe haven for crypto code. grin Geoff. -- Geoff Rehmet, The Internet Solution geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org tel: +27-83-292-5800 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
