Re: update on the Grim Reaper...
Matthew Jacob wrote: I found all of the knobs that turn off harvesting, and with those off, my alpha 4100 boots again w/o hanging. So- there are knobs (but nothing in UPDATING warned me to turn them off in order to boot again). The commit message described that the option would be on by default, and I did a followup to -current that described the situation in detail. Sorry if you missed it. I still think this should be in a separate rc file, but no matter. The timing (i.e., asap) really indicates that /etc/rc is the best home. The item that causes the alpha to hang on boot is interrupt harvesting. Has anyone else running non-ia32 run into problems? I'm not sure about that, but I know Mark appreciates all the feedback he can get, especially on non-intel stuff. Doug -- Perhaps the greatest damage the American system of education has done to its children is to teach them that their opinions are relevant simply because they are their opinions. Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Ethernet entropy harvesting seriously pessimizes performance
Hi, In addition to reported earlier general machine slowdown with interrupt harvesting is turning on, ethernet entropy harvesting seriously hammers network performance as well. Ftping big file over my 10M network now about 15% slower with ethernet harvesting turning on. Mark, please get slow machine (say 100MHz or slower) and test you fu^H^Hboring harvester on it before committing anything. The whole devrandom affair gone too far and shown exactly how things should not be developed in FreeBSD. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
In addition to reported earlier general machine slowdown with interrupt harvesting is turning on, ethernet entropy harvesting seriously hammers network performance as well. Ftping big file over my 10M network now about 15% slower with ethernet harvesting turning on. Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? Mark, please get slow machine (say 100MHz or slower) and test you fu^H^Hboring harvester on it before committing anything. The whole devrandom affair gone too far and shown exactly how things should not be developed in FreeBSD. I've done this. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Mark Murray wrote: In addition to reported earlier general machine slowdown with interrupt harvesting is turning on, ethernet entropy harvesting seriously hammers network performance as well. Ftping big file over my 10M network now about 15% slower with ethernet harvesting turning on. Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? I've not tried Rijndael code yet, do you think that it could make a noticeable difference? As for kern.random.sys.burst=$SMALLNUMBER I think that it is your task to tune defaults in such a way that it would not disturb even low-profile users (i.e. would not cause any measureable performance degradation). Tuning defaults with power users in mind is extremly bad idea - we are not an OS with mininal configuration PIII-500/128MB. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fix for OpenSSL -j build
Can everyone please test this patch against OpenSSL, which should fix
the problems observed with -j builds as well as cleaning out the
temporary ASM files.
This fix will need to be committed to -stable prior to the release, as
it shares the same code.
Kris
Index: Makefile
===
RCS file: /mnt/ncvs/src/secure/lib/libcrypto/Makefile,v
retrieving revision 1.36
diff -u -r1.36 Makefile
--- Makefile2001/03/08 07:57:49 1.36
+++ Makefile2001/03/12 10:30:15
@@ -380,16 +380,12 @@
.include bsd.lib.mk
.if !defined(NOPERL) ${MACHINE_ARCH} == "i386"
-.SUFFIXES: .o .pl
-.SUFFIXES: .po .pl
-.SUFFIXES: .So .pl
-.pl.o:
- perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} $(.PREFIX).pl.s ;
${AS} ${AFLAGS} $(.PREFIX).pl.s -o $(.TARGET)
+CLEANFILES+= ${SRCS:M*.pl:S/.pl$/.cmt/} ${SRCS:M*.pl:S/.pl$/.s/}
+.SUFFIXES: .pl .cmt
+.pl.cmt:
+ perl -I${PERLPATH} ${.ALLSRC} elf ${CPUTYPE:Mi386:S/i//} ${.TARGET}
-.pl.po:
- perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} $(.PREFIX).pl.s ;
${AS} ${AFLAGS} $(.PREFIX).pl.s -o $(.TARGET)
-
-.pl.So:
- perl -I${PERLPATH} $(.ALLSRC) elf ${CPUTYPE:Mi386:S/i//} $(.PREFIX).pl.s ;
${AS} ${AFLAGS} $(.PREFIX).pl.s -o $(.TARGET)
+.cmt.s:
+ tr -d "'" ${.ALLSRC} ${.TARGET}
.endif
PGP signature
Re: swap-backed md-based /tmp to replace mfs-based one
David Wolfskill wrote: Date: Sun, 11 Mar 2001 15:11:09 -0800 From: Kris Kennaway [EMAIL PROTECTED] To: Hajimu UMEMOTO [EMAIL PROTECTED] We really need to provide a better rc.conf hook for doing this -- expecting people to write their own script just to create a /tmp is lame. I appreciate the validation that what I'm trying to do makes sense (at least to some folks). And I appreciate Hajimu Umemoto's contribution, since I hadn't been aware of the "diskless_mount" specification. But basically, I agree with the sentiment re: making it easier. I would be very pleased if it were made as easy as the use of an mfs-based /tmp (merely specify "filesystem type" as "mfs"), but my (very!) brief acquaintance with the semantics of the md device gives me the impression that the exact approach is unlikely to be useful. A while ago someone suggested a /etc/md.conf and an mdon(1) similar to swapon(1). The md.conf file would contain a simple table indicating what manner of md devices needs to be created, including fs type and a flag indicating if it needs to be newfs'ed (as well as newfs parameters, one assumes), and the mdon(1) would scan fstab and mount any filesystems on /dev/md*. This solution is much more flexible than simple /tmp fs on md devices, seems more appropriate (and scalable) than poluting rc.conf(5) with a host of new options, and avoids the mount_mdfs criticism leveled by phk that md is not an fs (which is true enough). It doesn't look even much difficult to implement either. I bet the most annoying part would be writing md.conf(5). Moreover, this solution seemed, at the time, to please all involved in the discussion. Only none of them went out and implemented it. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] It's a rewarding life, but hey, somebody has to have all the fun, right? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
aic7880 prints some timeouts after recent commit (yesterday)
Hi,
dmesg and the output of "ident /sys/dev/aic7xxx/*" and pciconf is
attached (BTW: the -v options to pciconf isn't documented in the
synopsis section of the man page).
Do you need more information, e.g. the output of a verbose boot?
Bye,
Alexander.
--
Where do you think you're going today?
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #6: Sun Mar 11 20:42:30 CET 2001
[EMAIL PROTECTED]:/big/usr/src/sys/compile/WORK
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.93-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x665 Stepping = 5
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory = 134205440 (131060K bytes)
avail memory = 126312448 (123352K bytes)
Preloaded elf kernel "kernel" at 0xc0419000.
Preloaded elf module "vesa.ko" at 0xc041909c.
Preloaded elf module "cd9660.ko" at 0xc0419138.
Preloaded elf module "mfs.ko" at 0xc04191d8.
Preloaded elf module "msdos.ko" at 0xc0419274.
Preloaded elf module "procfs.ko" at 0xc0419314.
Preloaded elf module "linux.ko" at 0xc04193b4.
Preloaded elf module "usb.ko" at 0xc0419454.
Preloaded elf module "random.ko" at 0xc04194f0.
Preloaded elf module "atspeaker.ko" at 0xc0419590.
Preloaded elf module "agp.ko" at 0xc0419634.
Preloaded elf module "accf_data.ko" at 0xc04196d0.
Preloaded elf module "accf_http.ko" at 0xc0419774.
Preloaded elf module "joy.ko" at 0xc0419818.
Preloaded elf module "snd_pcm.ko" at 0xc04198b4.
Preloaded elf module "snd_sbc.ko" at 0xc0419954.
Preloaded elf module "snd_sb16.ko" at 0xc04199f4.
Pentium Pro MTRR support enabled
VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc036b357 (1000117)
VESA: 3dfx Interactive, Inc.
Using $PIR table, 7 entries at 0xc00f0d10
apm0: APM BIOS on motherboard
apm0: found APM BIOS v1.2, connected at v1.2
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443LX (440 LX) host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
agp0: Intel 82443LX (440 LX) host to PCI bridge mem 0xe000-0xe7ff at device
0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: display, VGA at 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 4.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0xb800-0xb80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xb400-0xb41f irq 9 at device
4.2 on pci0
usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
intpm0: Intel 82371AB Power management controller port 0xe800-0xe80f irq 9 at device
4.3 on pci0
intpm0: I/O mapped e800
intpm0: intr IRQ 9 enabled revision 0
smbus0: System Management Bus on intsmb0
smb0: SMBus general purpose I/O on smbus0
intpm0: PM I/O mapped e400
ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xb000-0xb0ff mem
0xd980-0xd9800fff irq 9 at device 6.0 on pci0
aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs
ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xa800-0xa81f irq 9 at device 10.0 on
pci0
ed0: address 00:80:ad:40:bd:e7, type NE2000 (16 bit)
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: System console at flags 0x6 on isa0
sc0: VGA 16 virtual consoles, flags=0x206
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x20010 on isa0
sio0: type ST16650A
sio1 at port 0x2e8-0x2ef irq 10 flags 0x2 on isa0
sio1: type ST16650A
pca0 at port 0x40 on isa0
isic0 at port
0x1b00-0x1b1f,0x16e0-0x16ff,0x6e0-0x6ff,0xee0-0xeff,0x1300-0x131f,0x300-0x31f,0xb00-0xb1f
irq 3 flags 0x4 on isa0
isic0: passive stack unit 0
isic0: AVM A1 or Fritz!Card Classic
ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
pcfclock0: PCF-1.0 on ppbus0
ppi0: Parallel I/O on ppbus0
pps0: Pulse per second Timing Interface on ppbus0
sc1: System console on isa0
sc1: MDA 16 virtual consoles, flags=0x0
WARNING: Driver mistake: repeat make_dev("consolectl")
vga1: Generic ISA VGA at port 0x3b0-0x3bb iomem 0xb-0xb7fff on isa0
sbc0: Creative ViBRA16C
midi causes panic on boot? + entropy gatherer works fine
Hello everybody, I had been away for two weeks and after upgrading to the latest -CURRENT I noticed that leaving device midi (and maybe device seq, I did not test separately) in my kernel config file causes a Trap 12 with interrupts disabled on _mtx_lock_sleep+0x29a: movl 0x1a0(%edx),%eax quite early on boot. Dumping was not possible, my attempts at this were only honoured with a reboot. Although I never tested if the midi support actually does something but up until now I always had it in the kernel and it never caused problems. I wonder if this is known? If not, I can certainly provide more information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It works fine otherwise. (as it always has) BTW: the new entropy gatherer really works nice for me. Even with the usual set of debugging options, I did not notice any slowdown, more, I think the computer has become more responsive than it has been lately. Congrats to Mark and all, I just did not want to send an email separately for this!:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cp MAKEDEV /dev - on a system with devfs
Hi, In /usr/src/etc/Makefile: "make distribution" is still trying to copy MAKEDEV to /dev on a system with devfs mounted to /dev. Since devfs is default, is this behaviour correct or my /etc/make.conf is missing something ? regards, -- Jean Louis Ntakpe Texas Instruments - Freising [EMAIL PROTECTED] Wafer Fab Automation Group [EMAIL PROTECTED] Haggerty Str. 1 85350 Freising Telefon +49 (8161) 80-3816 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Maxim Sobolev wrote: Mark Murray wrote: In addition to reported earlier general machine slowdown with interrupt harvesting is turning on, ethernet entropy harvesting seriously hammers network performance as well. Ftping big file over my 10M network now about 15% slower with ethernet harvesting turning on. Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? I've not tried Rijndael code yet, do you think that it could make a noticeable difference? As for kern.random.sys.burst=$SMALLNUMBER I think that it is your task to tune defaults in such a way that it would not disturb even low-profile users (i.e. would not cause any measureable performance degradation). Tuning defaults with power users in mind is extremly bad idea - we are not an OS with mininal configuration PIII-500/128MB. Have to admit that after updating my kernel all these and several other harvester-related problems are gone. Now there is no measureable difference in performance with harvesting turning on and off and mouse moves smothly without usual patch for scmouse.c. ;) Finally I can thank you for a good work Mark! -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp MAKEDEV /dev - on a system with devfs
In message [EMAIL PROTECTED], Jean Louis Ntakpe writes: Hi, In /usr/src/etc/Makefile: "make distribution" is still trying to copy MAKEDEV to /dev on a system with devfs mounted to /dev. Since devfs is default, is this behaviour correct or my /etc/make.conf is missing something ? I think that MAKEDEV should be moved away from /dev. Ideally it belongs somewhere rather obscure, but /etc/MAKEDEV is ok with me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Entropy harvesting? Grim reaper is more like it...
I changed nothing from whatever the default is. It seems like a bit of POLA to freeze now. But I'll check this - if I can get that machine up again :-)... OK - if this is the entropy driver, then typing about 2 lines of shit will unlock it. That did not fix the problem. Only disabling interrupt harvesting fixed it. Please put some echo's into the rc scripts to tie down where this is happening. M To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Entropy harvesting? Grim reaper is more like it...
On Fri, 9 Mar 2001, Kris Kennaway wrote: On Fri, Mar 09, 2001 at 09:32:29AM -0800, Matthew Jacob wrote: I changed nothing from whatever the default is. It seems like a bit of POLA to freeze now. But I'll check this - if I can get that machine up again :-)... Press ^T when it freezes and see if it's just blocked in rndslp or truly frozen. Again, as per previous, that didn't show anything. WHen I have a tad more time today or tomorrow, I'll try and narrow it further. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Entropy harvesting? Grim reaper is more like it...
On Fri, 9 Mar 2001, John Baldwin wrote: On 09-Mar-01 Matthew Jacob wrote: On Fri, 9 Mar 2001, Mark Murray wrote: I changed nothing from whatever the default is. It seems like a bit of POLA to freeze now. But I'll check this - if I can get that machine up again :-)... OK - if this is the entropy driver, then typing about 2 lines of shit will unlock it. Neither ^T or typing does anything. I'll have to do some surgery from another boot disk to find out what's what. Uk. Erm, just so you know. The 4100 here at WC doesn't even make it past the SCSI probe due to interrupt issues. John- both you David have seen this. Both Doug I have working 4100s. It's not the same issue, I believe. If it's running really up to date current, try changing sys/alpha/include/mutex.h to define mtx_intr_enable() to nothing, which will hackishly run ithreads with a raised IPL and might solve the problem if its an interrupt storm you are seeing. I don't believe it's this issue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Entropy harvesting? Grim reaper is more like it...
Wait a minute. isn't this all old mail being resent? What's going on? I did a buildworld/installworld on an alpha yesterday, and now I'm left with: start_init: trying /sbin/init Entropy harvesting: interrupts ethernet. hangs And this is even with booting from an older kernel. Umm... anyone gotta clue on this one? You have your entropy device set to block on boot? M To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
On Mon, 12 Mar 2001, Mark Murray wrote: In addition to reported earlier general machine slowdown with interrupt harvesting is turning on, ethernet entropy harvesting seriously hammers network performance as well. Ftping big file over my 10M network now about 15% slower with ethernet harvesting turning on. Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? Rijndael stops it showing up much in top -S. I'm wondering where it is hiding :-). kern.random.sys.burst=$SMALLNUMBER had very little effect. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf lack of CPUTYPE=k6-3 support
On Mon, 12 Mar 2001, Maxim Sobolev wrote: Maxim Sobolev wrote: On Mon, Mar 12, 2001 at 12:29:58AM -0300, Mario Sergio Fujikawa Ferreira wr= ote: Hi, =20 Is there anything against adding support for k6-3 to the just added CPUTYPE mechanism? :) My little machine feels left out. Hehehhe I made a simple patch to etc/defaults/make.conf and share/mk/bsd.cpu.mk Should I have touched anything else? =20 Regards, =20 ps: I think this can be MFCed asap (even during the veil period) since it is very straightforward. Looks fine to me. I'll commit it. I see no reason for it. k6-3 is essentially k6-2 core with extra cache on chip. Threre are no other significant differencies in the features or instruction set. Not even to mention that there is such a beast as k6-2+ I would suggest to rename k6-2 into k6/3dnow (similarly to what we have for i586/mmx) and put a note saying that k6/3dnow should be used for k6-2/k6-2+/k6-3. k6-2 is already over-engineered. The only difference between it and k6 is 3dnow, but neither gcc nor any source files support 3dnow (now :-). OTOH, bsd.cpu.mk is too under-engineered to support any compiler except gcc. It unconditionally translates FreeBSD-specific names like k6-2 to gcc-specific flags like -march=k6. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -CURRENT no longer boots
Do you have WITNESS_SKIPSPIN option in your kernel config? Here is what supposedly causing the trouble: a) the process p_spinlocks variable is initialized to one in fork1 during the process creation b) the sched_lock is released later in fork_exit, but the process' p_spinlocks field is not decreased because sched_lock is not tracked by the witness subsystem b) process tried to grab Giant but sees p_spinlocks 0 ... instant panic :) The quick and dirty fix is to either set debug.witness_skipspin=0 in /boot/loader.conf or modify witness_enter function to ignore p_skipspin counter if debug.witness_skipspin is non-zero. -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 12-Mar-2001 Time: 12:40:36 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -CURRENT no longer boots
On 12-Mar-01 Alexander N. Kabaev wrote: Do you have WITNESS_SKIPSPIN option in your kernel config? Here is what supposedly causing the trouble: a) the process p_spinlocks variable is initialized to one in fork1 during the process creation b) the sched_lock is released later in fork_exit, but the process' p_spinlocks field is not decreased because sched_lock is not tracked by the witness subsystem b) process tried to grab Giant but sees p_spinlocks 0 ... instant panic :) c) As part of the new witness code, move p_spinlocks (well, a variation thereof) to be a per-CPU variable. The quick and dirty fix is to either set debug.witness_skipspin=0 in /boot/loader.conf or modify witness_enter function to ignore p_skipspin counter if debug.witness_skipspin is non-zero. Just don't use the skipspin stuff, it shouldn't hurt at all. The new witness code will hopefully be in by the end of the week. *crosses fingers* -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? Rijndael stops it showing up much in top -S. I'm wondering where it is hiding :-). kern.random.sys.burst=$SMALLNUMBER had very little effect. The Rijndael code makes a 2-orders-of-magnitude difference to the speed of the Davies-Meyer hash in hash.c. In order for the random kthread to show me numbers (I got paranoid when it didn't seem to show up), I slowed it down by looping the hashing "guts" 100 times :). This very clearly shows the superior key agility of Rijndael over Blowfish. Now kern.random.sys.burst is still available for those very slow, very high interrupt cases. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Please try this patch. This should solve all the random harvesting
performance issues no matter how efficient or inefficient the hash
function (untested as I do not have a -current box at the moment).
-Matt
Index: yarrow.c
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.c,v
retrieving revision 1.31
diff -u -r1.31 yarrow.c
--- yarrow.c2001/02/11 16:21:35 1.31
+++ yarrow.c2001/03/12 19:09:15
@@ -104,11 +104,8 @@
for (;;) {
- if (harvestring.tail == harvestring.head)
- tsleep(harvestring, PUSER, "rndslp", hz/10);
-
- else {
-
+ tsleep(harvestring, PUSER, "rndslp", hz/10);
+ if (harvestring.tail != harvestring.head) {
/* Suck the harvested entropy out of the queue and hash
* it into the appropriate pool.
*/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
On Tue, Mar 13, 2001 at 12:12:35AM +0900, Daniel C. Sobral wrote: A while ago someone suggested a /etc/md.conf and an mdon(1) similar to swapon(1). Putting it in terms of this analogy make this approach sound quite reasonable. This solution is much more flexible than simple /tmp fs on md devices, seems more appropriate (and scalable) than poluting rc.conf(5) with a host of new options, As long as someone that is familiar with all the "cool" and more esoteric uses of `md' was consulted to ensure the framework is sufficiently capable. and avoids the mount_mdfs criticism leveled by phk that md is not an fs (which is true enough). If it looks like a duck, swims like a duck, quacks like a duck, -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
In message [EMAIL PROTECTED], "David O'Brien" writes: On Tue, Mar 13, 2001 at 12:12:35AM +0900, Daniel C. Sobral wrote: A while ago someone suggested a /etc/md.conf and an mdon(1) similar to swapon(1). Putting it in terms of this analogy make this approach sound quite reasonable. I can fully support this approach, or if people want to add a config file to mdconfig(8) I can live with that as well. and avoids the mount_mdfs criticism leveled by phk that md is not an fs (which is true enough). If it looks like a duck, swims like a duck, quacks like a duck, Sorry David, but it there is nothing duck-like about at all... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
On Sat, Mar 10, 2001 at 10:32:23PM -0800, Dima Dorfman wrote: Peter Wemm [EMAIL PROTECTED] writes: The version of the patch for -current uses the softdep mount option only. If you remove the mount option, you dont get softupdates. In this case, it might be better to just turn it on by default and let Problem is many still feel it should not be used on / . -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
Speaking of md, and such, since MFS got nuked, and I died horribly every time I tried to use md as a tmpfs, have the panics been fixed so I can use it now as a replacement for MFS? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Sorry, the last patch won't patch cleanly, I forget to update my
-current source before diffing. A new patch is attached, and it
also includes reducing the sdize of the entropy ring from 1024 to a
more reasonable 64.
Mark, what I said last month still holds... you need to make the random
code less intrusive to the rest of the system. You need to do it as a
matter of course, not as an afterthought. A better hashing algorithm
is all well and fine, but doesn't really solve the lots-of-interrupts
problem, it just moves the bar a little. It doesn't scale, whereas
a hard limit on interrupt seeds per second does scale.
If you need a larger ring for initial seeding, then I recommend adding
a flag to the harvester. e.g. manual reseeding would use
the whole ring, but interrupt seeding would only operate if the current
number of entries in the ring is 32 and be a NOP otherwise. Or
something like that. Even 32 could be too large... that would be
32 x 10 or 320 interrupt seeds a second, which is overkill. Perhaps
something like 8 would be better (8 x 10 = maximum of 80 interrupt
reseeds a second).
-Matt
Index: yarrow.c
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.c,v
retrieving revision 1.31
diff -u -r1.31 yarrow.c
--- yarrow.c2001/02/11 16:21:35 1.31
+++ yarrow.c2001/03/12 19:27:02
@@ -104,11 +104,9 @@
for (;;) {
- if (harvestring.tail == harvestring.head)
- tsleep(harvestring, PUSER, "rndslp", hz/10);
+ tsleep(harvestring, PUSER, "rndslp", hz/10);
- else {
-
+ if (harvestring.tail != harvestring.head) {
/* Suck the harvested entropy out of the queue and hash
* it into the appropriate pool.
*/
Index: yarrow.h
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.h,v
retrieving revision 1.15
diff -u -r1.15 yarrow.h
--- yarrow.h2001/02/11 16:21:35 1.15
+++ yarrow.h2001/03/12 19:27:20
@@ -32,7 +32,7 @@
*/
/* The ring size _MUST_ be a power of 2 */
-#define HARVEST_RING_SIZE 1024/* harvest ring buffer size */
+#define HARVEST_RING_SIZE 64 /* harvest ring buffer size */
#define HARVEST_RING_MASK (HARVEST_RING_SIZE - 1)
#define TIMEBIN16 /* max value for Pt/t */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
In message [EMAIL PROTECTED], Matthew Jacob writes: Speaking of md, and such, since MFS got nuked, and I died horribly every time I tried to use md as a tmpfs, have the panics been fixed so I can use it now as a replacement for MFS? Uhm, I'm drawing a blank here. When did you have panics ? Which panics ? Have you tried -current ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
In message [EMAIL PROTECTED], "David O'Brien" writes: On Sat, Mar 10, 2001 at 10:32:23PM -0800, Dima Dorfman wrote: Peter Wemm [EMAIL PROTECTED] writes: The version of the patch for -current uses the softdep mount option only. If you remove the mount option, you dont get softupdates. In this case, it might be better to just turn it on by default and let Problem is many still feel it should not be used on / . Why not ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Please try this patch. This should solve all the random harvesting
performance issues no matter how efficient or inefficient the hash
function (untested as I do not have a -current box at the moment).
Erm, you are behind :-)
I have already committed something that does this in a much more
configurable way.
M
-Matt
Index: yarrow.c
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.c,v
retrieving revision 1.31
diff -u -r1.31 yarrow.c
--- yarrow.c 2001/02/11 16:21:35 1.31
+++ yarrow.c 2001/03/12 19:09:15
@@ -104,11 +104,8 @@
for (;;) {
- if (harvestring.tail == harvestring.head)
- tsleep(harvestring, PUSER, "rndslp", hz/10);
-
- else {
-
+ tsleep(harvestring, PUSER, "rndslp", hz/10);
+ if (harvestring.tail != harvestring.head) {
/* Suck the harvested entropy out of the queue and hash
* it into the appropriate pool.
*/
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
: : Please try this patch. This should solve all the random harvesting : performance issues no matter how efficient or inefficient the hash : function (untested as I do not have a -current box at the moment). : :Erm, you are behind :-) : :I have already committed something that does this in a much more :configurable way. : :M : Mark, something like this doesn't REQUIRE any configuration!!! Don't add confusion to the system. Just make the default something reasonable. There is absolutely no reason to have to be able to adjust the interrupt seeding code if the default is made something reasonable. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
On Mon, Mar 12, 2001 at 08:27:54PM +0100, Poul-Henning Kamp wrote: If it looks like a duck, swims like a duck, quacks like a duck, Sorry David, but it there is nothing duck-like about at all... From a user's stand point, it acts just like the old MFS when used to create a swap backed /tmp. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
Date: Mon, 12 Mar 2001 11:29:50 -0800 (PST) From: Matthew Jacob [EMAIL PROTECTED] Speaking of md, and such, since MFS got nuked, and I died horribly every time I tried to use md as a tmpfs, have the panics been fixed so I can use it now as a replacement for MFS? Well, it appears to work OK for me so far. That said, I haven't been exercising it tremendously; I usually run -STBALE on the laptop. (Trying to watch for weirdnesses as we approach 4.3-R) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
On Mon, 12 Mar 2001 20:33:59 +0100, Poul-Henning Kamp wrote: Problem is many still feel it should not be used on / . Why not ? Because a small root partition fills up artificially during "make installworld" and/or "make installkernel". Everybody understands _why_ it happens, but that doesn't make enyone any more comfortable about using softupdates on their root partition. I don't think it has anything to do with reliability. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
In message [EMAIL PROTECTED], "David O'Brien" writes: On Mon, Mar 12, 2001 at 08:27:54PM +0100, Poul-Henning Kamp wrote: If it looks like a duck, swims like a duck, quacks like a duck, Sorry David, but it there is nothing duck-like about at all... From a user's stand point, it acts just like the old MFS when used to create a swap backed /tmp. That's like saying that a skateboard acts like a truck when you put a parcel on it :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
In message [EMAIL PROTECTED], Matthew Jacob writes: Speaking of md, and such, since MFS got nuked, and I died horribly every time I tried to use md as a tmpfs, have the panics been fixed so I can use it now as a replacement for MFS? Uhm, I'm drawing a blank here. When did you have panics ? Which panics ? Have you tried -current ? The last we'd left this after you nuked MFS was I had an instant way of panic'ing -current. I can find the email for you if I must. You said you'd think about it. That's the last I heard. I can try it again, but I thought it'd be easier to find out whether the person who destroyed an important function and offered a replacement which failed to work might remember fixing it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Mark, something like this doesn't REQUIRE any configuration!!! Don't add confusion to the system. Just make the default something reasonable. There is absolutely no reason to have to be able to adjust the interrupt seeding code if the default is made something reasonable. Matt, At it is very obvious to me that you have not even looked at the new code, let alone run it, I suggest that you do both before further engaging in this conversation. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
Date: Mon, 12 Mar 2001 20:33:59 +0100
From: Poul-Henning Kamp [EMAIL PROTECTED]
In message [EMAIL PROTECTED], "David O'Brien" writes:
On Sat, Mar 10, 2001 at 10:32:23PM -0800, Dima Dorfman wrote:
Peter Wemm [EMAIL PROTECTED] writes:
The version of the patch for -current uses the softdep mount option only.
If you remove the mount option, you dont get softupdates.
In this case, it might be better to just turn it on by default and let
Problem is many still feel it should not be used on / .
Why not ?
Probably because of the behavior when a softupdates-enabled filesystem is
active near full. This can be exacerbated on / if /tmp isn't a separate
filesystem.
Since I mount /tmp as a separate filesystem, and since I boot the laptop
in any of 3 different environments (with the "other environments"
represented as other filesystems), I've enabled softupdates on all of
the disk-based filesystems on the box. No problems so far (a few hours
shy of 1 week). Biggest workload is the make {build,install}{world,kernel}
stuff.
Cheers,
david
--
David H. Wolfskill [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
In message [EMAIL PROTECTED], Matthew Jacob writes: In message [EMAIL PROTECTED], Matthew Jacob writes: Speaking of md, and such, since MFS got nuked, and I died horribly every time I tried to use md as a tmpfs, have the panics been fixed so I can use it now as a replacement for MFS? Uhm, I'm drawing a blank here. When did you have panics ? Which panics ? Have you tried -current ? The last we'd left this after you nuked MFS was I had an instant way of panic'ing -current. I can find the email for you if I must. You said you'd think about it. That's the last I heard. I can try it again, but I thought it'd be easier to find out whether the person who destroyed an important function and offered a replacement which failed to work might remember fixing it. The last month has been pretty rough on me, so bear with me, please. Can you resend the email please ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
The last month has been pretty rough on me, so bear with me, please. Okay. That's a very reasonable response. Can you resend the email please ? I'll just retry it now. Thank you for the above- I totally understand. My previous mail was just a "check-in" on it- not a demand. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -CURRENT no longer boots
Just don't use the skipspin stuff, it shouldn't hurt at all. The new witness code will hopefully be in by the end of the week. *crosses fingers* Cool. WITNESS_SKIPSPIN was quite useful for NETGRAPH users because of some unregistered spin mutexes there. Julian fixed the problem already, so you are right - skipspin is not that useful anymore. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Latest with 'swap-backed md-based /tmp to replace mfs-based one '
It doesn't panic, yet. Good! Much improved! All is good, ahem, except that when I ran this tmp filesystem out of space, it takes a while before the space comes back if you remove files :-) farrago.feral.com lmdd of=/tmp/file /tmp: write failed, file system is full 117.19 MB in 9.07 seconds (12.9239 MB/sec) farrago.feral.com rm /tmp/file; ls /tmp; while : ; do df -k /tmp date sleep 1; done Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:48 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:49 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:50 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:51 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:52 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:53 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:54 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:55 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:56 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:57 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:58 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:59 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:30:00 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:30:01 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 1305208 120072 0%/tmp Mon Mar 12 12:30:02 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 1305208 120072 0%/tmp Mon Mar 12 12:30:03 PST 2001 -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Latest with 'swap-backed md-based /tmp to replace mfs-based one '
That looks like regular softupdates behaviour to me ? In message [EMAIL PROTECTED], Matthew Jacob writes: It doesn't panic, yet. Good! Much improved! All is good, ahem, except that when I ran this tmp filesystem out of space, it takes a while before the space comes back if you remove files :-) farrago.feral.com lmdd of=/tmp/file /tmp: write failed, file system is full 117.19 MB in 9.07 seconds (12.9239 MB/sec) farrago.feral.com rm /tmp/file; ls /tmp; while : ; do df -k /tmp date sleep 1; done Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:48 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:49 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:50 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:51 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:52 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:53 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:54 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:55 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:56 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:57 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:58 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:29:59 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:30:00 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 130520 1200800 100%/tmp Mon Mar 12 12:30:01 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 1305208 120072 0%/tmp Mon Mar 12 12:30:02 PST 2001 Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/md10c 1305208 120072 0%/tmp Mon Mar 12 12:30:03 PST 2001 -matt -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Latest with 'swap-backed md-based /tmp to replace mfs-based one'
That looks like regular softupdates behaviour to me ? Huh. I didn't know that there was this big of a delay. At any rate, thanks! I'll do some more testing and see if I can break it but I sure am happier to have something back! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aic7880 prints some timeouts after recent commit (yesterday)
Hi,
dmesg and the output of "ident /sys/dev/aic7xxx/*" and pciconf is
attached (BTW: the -v options to pciconf isn't documented in the
synopsis section of the man page).
Do you need more information, e.g. the output of a verbose boot?
Bye,
Alexander.
I wish I had a system that exhibited this problem. Unfortunately
I don't, so it has been difficult to get the workaround for this
particular hardware bug correct.
Can you see if this patch works for you?
--
Justin
Index: aic7xxx.c
===
RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.c,v
retrieving revision 1.41.2.17
diff -c -r1.41.2.17 aic7xxx.c
*** aic7xxx.c 2001/03/12 14:57:40 1.41.2.17
--- aic7xxx.c 2001/03/12 20:30:40
***
*** 2006,2018
ahc_lookup_phase_entry(int phase)
{
struct ahc_phase_table_entry *entry;
! int i;
/*
* num_phases doesn't include the default entry which
* will be returned if the phase doesn't match.
*/
! for (i = 0, entry = ahc_phase_table; i num_phases; i++) {
if (phase == entry-phase)
break;
}
--- 2006,2019
ahc_lookup_phase_entry(int phase)
{
struct ahc_phase_table_entry *entry;
! struct ahc_phase_table_entry *last_entry;
/*
* num_phases doesn't include the default entry which
* will be returned if the phase doesn't match.
*/
! last_entry = ahc_phase_table[num_phases];
! for (entry = ahc_phase_table; entry = last_entry; entry++) {
if (phase == entry-phase)
break;
}
Index: aic7xxx.seq
===
RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.seq,v
retrieving revision 1.94.2.11
diff -c -r1.94.2.11 aic7xxx.seq
*** aic7xxx.seq 2001/03/12 14:57:43 1.94.2.11
--- aic7xxx.seq 2001/03/12 20:47:35
***
*** 2076,2082
testDFSTATUS, HDONE jnz dma_scb_hang_dma_done;
testDFSTATUS, HDONE jnz dma_scb_hang_dma_done;
testDFSTATUS, HDONE jnz dma_scb_hang_dma_done;
- testDFSTATUS, HDONE jnz dma_scb_hang_dma_done;
/*
* The PCI module no longer intends to perform
* a PCI transaction and HDONE has not come true.
--- 2076,2081
***
*** 2102,2107
--- 2101,2107
*/
not SINDEX;
add A, 5, SINDEX;
+ cmp A, 4je dma_finish;
jmp dma_scb_hang_fifo;
dma_scb_hang_dma_done:
and DFCNTRL, ~HDMAEN;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
:Matt, : :At it is very obvious to me that you have not even looked at the new :code, let alone run it, I suggest that you do both before further :engaging in this conversation. : :M :-- :Mark Murray :Warning: this .sig is umop ap!sdn I looked at it. I'm sorry, I don't see how your adjustments make the code any better from an algorithmic point of view. As far as I can tell, things can still run away and interrupts still have an unnecessarily large fixed overhead when they call the random_harvest_internal(). I don't understand what is so difficult about simply rate-limiting the code at the proper point -- at the very beginning of the call that the interrupt harvester makes, removing most of the fixed overhead for the case where a system is getting a large number of interrupts per second? Why are you going through loops to create complex, sensitive code paths when a simple solution can be plopped down and will work, SNAP, just like that? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
promiscuous mode
Hi all, Does anybody knows to say when the computer changes to promiscous mode? /kernel: promiscuous mode enable [ ]´s Ronan Lucio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
I don't understand what is so difficult about simply rate-limiting the code at the proper point -- at the very beginning of the call that the interrupt harvester makes, removing most of the fixed overhead for the case where a system is getting a large number of interrupts per second? Why are you going through loops to create complex, sensitive code paths when a simple solution can be plopped down and will work, SNAP, just like that? Because I need to make folks other than you happy. Lots of security minded people what _all_ the interrupt entropy they can get, and this method gives them that while allowing others to throttle the harvester back. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
trouble with pkg_add
ticso@cicely5:/tmp# pkg_add -f -v png-1.0.9_1.tgz Requested space: 831096 bytes, free space: 13705216 bytes in /var/tmp/instmp.ijZaPY extract: Package name is png-1.0.9_1 extract: CWD to /usr/local pkg_add: extract_plist: unable to cwd to '/usr/local' Exit 2 The reason is that /usr/local is a softlink to an amd volume instead of a directory: ticso@cicely5:/tmp# ls -ald /usr/local lrwxr-xr-x 1 root wheel 10 Nov 29 1998 /usr/local - /vol/local ticso@cicely5:/tmp# ls -ald /usr/local/. drwxr-xr-x 41 root wheel 1024 Dec 21 21:05 /usr/local/. If I make /usr/local a real directory everything works fine, but that's something I don't want to do generaly when installing a package. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
Mikhail Teterin [EMAIL PROTECTED] writes: If you can, please reproduce the panic on a kernel compiled with the INVARIANTS, INVARIANT_SUPPORT and WITNESS options. Well, with this options on, the machine does not crash, but the program segfaults on startup: The trace you're showing looks like it's from a shell script that starts civctp. I need to see the trace from the civctp binary itself. lock order reversal 1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239 2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183 3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560 Haven't seen this one before... If it's reproducible, could you do the following: 1) recompile your kernel with WITNESS_DDB 2) hook up a serial console and boot with '-h' in /boot.config 3) provoke the reversal, then get the output from 'trace', 'show mutex' and 'show witness' at the DDB prompt 4) type 'continue' to exit DDB and continue running normally. lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 2nd 0xc0419680 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:939 3rd 0xcefb986c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:948 This is a known (and probably benign) bug. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
: down and will work, SNAP, just like that? : :Because I need to make folks other than you happy. : :Lots of security minded people what _all_ the interrupt entropy :they can get, and this method gives them that while allowing others :to throttle the harvester back. : :M :-- :Mark Murray :Warning: this .sig is umop ap!sdn And if I were paranoid I could setup an interrupt a thousand times a second to scan all of physical memory and harvest the randomness from that. I am a security minded person... and I am also pragmatic. There's such a thing as overkill and your random number generator is doing it in spades. It is entirely unnecessary. Maybe rather then throw in the overkill you should actually *test* the random number generator to see where the randomness starts to break down when lowering the harvest rate. Thousands of harvests a second is just plain insane, no matter how security minded your 'lots of security minded people' are. Just ten a second should be plenty good enough, frankly, even for a paranoid security minded guy, especially considering the amount of memory the random number generator is using for state. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT no longer boots
"Alexander N. Kabaev" [EMAIL PROTECTED] writes: Do you have WITNESS_SKIPSPIN option in your kernel config? Yes. Here is what supposedly causing the trouble: You're telling the guy who did the analysis. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: promiscuous mode
Your ethernet card went into promiscuous mode presumably. Did you run tcpdump? Tom Veldhouse [EMAIL PROTECTED] - Original Message - From: "Ronan Lucio" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 12, 2001 3:25 PM Subject: promiscuous mode Hi all, Does anybody knows to say when the computer changes to promiscous mode? /kernel: promiscuous mode enable [ ]´s Ronan Lucio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
On 12 Mar, Dag-Erling Smorgrav wrote: = Mikhail Teterin [EMAIL PROTECTED] writes: = If you can, please reproduce the panic on a kernel compiled with the = INVARIANTS, INVARIANT_SUPPORT and WITNESS options. = Well, with this options on, the machine does not crash, but the = program segfaults on startup: = = The trace you're showing looks like it's from a shell script that = starts civctp. I need to see the trace from the civctp binary itself. No, that trace was obtained from a simple ktrace civctp There is no shell-wrapper around the binary: file /opt/bin/civctp /opt/bin/civctp: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, stripped It is just one big executable. You are welcome to download it from: http://aldan.algebra.com:8015/~mi/civctp-crash/civctp.bz2 uncompress it and try to run it (just 43Kb compressed). May be, it is because it is a _staticly_ linked Linux executable (the _dynamicly_ linked Netscape works fine). = lock order reversal = 1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239 = 2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183 = 3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560 = = Haven't seen this one before... If it's reproducible, could you do the = following: No... This the only machine I have at home. No serial console or cable... It is reproduceable -- happens now at boot time... -mi = 1) recompile your kernel with WITNESS_DDB = = 2) hook up a serial console and boot with '-h' in /boot.config = = 3) provoke the reversal, then get the output from 'trace', 'show = mutex' and 'show witness' at the DDB prompt = = 4) type 'continue' to exit DDB and continue running normally. = lock order reversal = 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 = 2nd 0xc0419680 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:939 = 3rd 0xcefb986c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:948 = = This is a known (and probably benign) bug. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[ list spamming ]
The domain austin.rr.com is running some software that seems to come from north of San Francisco that appears to be repackaging up and re-forwarding old mail. Twice now I've responded to what are apparently legitimate (until I look at full headers) resends of old mail. I've asked our postmaster to turn on the death rays. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
:This effectively happens. : :The harvest ring is a limited length, and any overflows are discarded. : :M :-- :Mark Murray :Warning: this .sig is umop ap!sdn Are you resending this mail from 5 dats ago or is there a bounce occuring somewhere on the list? Currently the queue size does not limit the interrupt rate due to the way the harvester processes the queue. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf lack of CPUTYPE=k6-3 support
On Tue, Mar 13, 2001 at 05:32:36AM +1100, Bruce Evans wrote: k6-2 is already over-engineered. The only difference between it and k6 is 3dnow, but neither gcc nor any source files support 3dnow (now :-). 3dnow support exists in several ports, though. OTOH, k6-3 doesn't add any new features, so it's debatable on those grounds. OTOH, bsd.cpu.mk is too under-engineered to support any compiler except gcc. It unconditionally translates FreeBSD-specific names like k6-2 to gcc-specific flags like -march=k6. I'm not sure what can be done about that -- is there a way for make(1) to know it's being used with a gcc compiler so we can .ifdef the whole lot? Kris PGP signature
Re: make.conf lack of CPUTYPE=k6-3 support
On Mon, 12 Mar 2001, Kris Kennaway wrote: On Tue, Mar 13, 2001 at 05:32:36AM +1100, Bruce Evans wrote: OTOH, bsd.cpu.mk is too under-engineered to support any compiler except gcc. It unconditionally translates FreeBSD-specific names like k6-2 to gcc-specific flags like -march=k6. I'm not sure what can be done about that -- is there a way for make(1) to know it's being used with a gcc compiler so we can .ifdef the whole lot? Not really, but it should use that same way that it should use to configure -pipe, etc. :-) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
On 12-Mar-01 Dag-Erling Smorgrav wrote: Mikhail Teterin [EMAIL PROTECTED] writes: If you can, please reproduce the panic on a kernel compiled with the INVARIANTS, INVARIANT_SUPPORT and WITNESS options. Well, with this options on, the machine does not crash, but the program segfaults on startup: The trace you're showing looks like it's from a shell script that starts civctp. I need to see the trace from the civctp binary itself. lock order reversal 1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239 2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183 3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560 Haven't seen this one before... If it's reproducible, could you do the following: It's stupidness due to proctree and allproc locks being backed by lockmgr I think. I'm waiting on looking at this one until proctree and allproc are converted to sx locks. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fixed - pthread altsigstack problem
Both of the patches below fix the problem mentioned in PR bin/25110. The
first one fixes it inside of kern_fork.c and would appear to apply the
corrective behaviour regardless of whether the process uses libc_r or not.
The second patch fixes the problem inside of uthread_fork.c. Whether the
first approach imposes an extra cost on non-threaded applications I'm not
kernel-experienced enough to say, but hopefully between two of you gents you
can decide which is the better fix to apply.
As I mentioned in my original post, this is a bug that we are experiencing
in 4.3-BETA, so if this could make it into 4.3-RELEASE it would be of great
help. One note regarding the second (libc_r) patch: the reference to
__sys_sigaltstack needs to be changed to _thread_sys_sigaltstack in order to
prevent undefined symbols on 4.x systems.
Patch #1 (kernel fix):
--- kern_fork.c.origSat Mar 10 12:17:40 2001
+++ kern_fork.c Sat Mar 10 12:20:39 2001
@@ -434,7 +434,7 @@
* Preserve some more flags in subprocess. P_PROFIL has already
* been preserved.
*/
- p2-p_flag |= p1-p_flag P_SUGID;
+ p2-p_flag |= p1-p_flag (P_SUGID | P_ALTSTACK);
if (p1-p_session-s_ttyvp != NULL p1-p_flag P_CONTROLT)
p2-p_flag |= P_CONTROLT;
if (flags RFPPWAIT)
Patch #2 (libc_r fix):
--- uthread_fork.c 2001/01/24 13:03:33 1.21
+++ uthread_fork.c 2001/03/09 17:53:37
+
@@ -32,6 +32,7 @@
* $FreeBSD: src/lib/libc_r/uthread/uthread_fork.c,v 1.21 2001/01/24 13:03:33
deischen Exp $
*/
#include errno.h
+#include signal.h
+
#include string.h
#include stdlib.h
#include unistd.h
@@ -110,7 +111,16 @@
else if (_pq_init(_readyq) != 0) {
/* Abort this application: */
PANIC("Cannot initialize priority ready queue.");
- } else {
+ } else if ((_thread_sigstack.ss_sp == NULL)
+
+ ((_thread_sigstack.ss_sp = malloc(SIGSTKSZ)) == NULL))
+
+ PANIC("Unable to allocate alternate signal stack");
+
+ else {
+
+ /* Install the alternate signal stack: */
+
+ _thread_sigstack.ss_size = SIGSTKSZ;
+
+ _thread_sigstack.ss_flags = 0;
+
+ if (__sys_sigaltstack(_thread_sigstack, NULL) != 0)
+
+ PANIC("Unable to install alternate signal stack");
+
+
+
/*
* Enter a loop to remove all threads other than
* the running thread from the thread list:
Thanks for the help guys.
--
j.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
** HEADS UP **
I committed a miibus'ified fxp driver to the tree today, and made it the default. If you compile fxp into your kernel statically, you will also need "device miibus" as well, if it isn't there already. If you notice any problems with the driver (things that were working and are not working now), please let me know. If you happend to have a chip that did _NOT_ work but now DOES work, please boot the machine with -v, and send me the line that says "PCI IDs:". If you have a fxp device that still doesn't work, then please get in touch with me (and send the output of the line above). -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new breakage in mounting root? a devfs issue?
complete fresh build, etc da0: invalid primary partition table: no magic start_init: trying /sbin/init fatal kernel trap: trap entry = 0x4 (unaligned access fault) a0 = 0xc3615fe1a88f382 a1 = 0x29 a2 = 0x1b pc = 0xfc467578 ra = 0xfc4627c4 curproc= 0xfe0009f5dbe0 pid = 1, comm = init Stopped at vfs_object_create+0x38: jsr ra,(pv),vfs_object_create+0x3c ra=0xfc4627c4,pv=0xfc467540 db t vfs_object_create() at vfs_object_create+0x38 getnewvnode() at getnewvnode+0x564 devfs_allocv() at devfs_allocv+0xe0 devfs_root() at devfs_root+0x38 devfs_mount() at devfs_mount+0xf0 vfs_mount() at vfs_mount+0x910 mount() at mount+0xd8 syscall() at syscall+0x3f4 XentSys1() at XentSys1+0x10 Ummm... vfs_object_create(vp, p, p-p_ucred); is there actually a ucred this early in startup? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
Just today I started using DEVFS again after a long time, and it works perfectly. From the scarce info you provide, our only apparent difference is I don't have SCSI. If it weren't you, I'd ask if you are sure you have the very latest sources, but of course I wonder you have more than enough clue to already have checked that ;-) Seriously, if it's a new breakage, it's not breaking for everybody. On Mon, Mar 12, 2001 at 04:30:52PM -0800, Matthew Jacob wrote: complete fresh build, etc da0: invalid primary partition table: no magic start_init: trying /sbin/init fatal kernel trap: trap entry = 0x4 (unaligned access fault) a0 = 0xc3615fe1a88f382 a1 = 0x29 a2 = 0x1b pc = 0xfc467578 ra = 0xfc4627c4 curproc= 0xfe0009f5dbe0 pid = 1, comm = init Stopped at vfs_object_create+0x38: jsr ra,(pv),vfs_object_create+0x3c ra=0xfc4627c4,pv=0xfc467540 db t vfs_object_create() at vfs_object_create+0x38 getnewvnode() at getnewvnode+0x564 devfs_allocv() at devfs_allocv+0xe0 devfs_root() at devfs_root+0x38 devfs_mount() at devfs_mount+0xf0 vfs_mount() at vfs_mount+0x910 mount() at mount+0xd8 syscall() at syscall+0x3f4 XentSys1() at XentSys1+0x10 Ummm... vfs_object_create(vp, p, p-p_ucred); is there actually a ucred this early in startup? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new breakage in mounting root? a devfs issue?
On Tue, 13 Mar 2001, Andrea Campi wrote: Just today I started using DEVFS again after a long time, and it works perfectly. From the scarce info you provide, our only apparent difference is I don't have SCSI. If it weren't you, I'd ask if you are sure you have the very latest sources, but of course I wonder you have more than enough clue to already have checked that ;-) Seriously, if it's a new breakage, it's not breaking for everybody. Huh... Yeah.. it's top of tree... and it's the first devfs breakage I've had in quite a while. It may not even be that... well, we got some garbage pointer in vfs_object_create... this alpha funnies maybeguess I'll try and track it down... On Mon, Mar 12, 2001 at 04:30:52PM -0800, Matthew Jacob wrote: complete fresh build, etc da0: invalid primary partition table: no magic start_init: trying /sbin/init fatal kernel trap: trap entry = 0x4 (unaligned access fault) a0 = 0xc3615fe1a88f382 a1 = 0x29 a2 = 0x1b pc = 0xfc467578 ra = 0xfc4627c4 curproc= 0xfe0009f5dbe0 pid = 1, comm = init Stopped at vfs_object_create+0x38: jsr ra,(pv),vfs_object_create+0x3c ra=0xfc4627c4,pv=0xfc467540 db t vfs_object_create() at vfs_object_create+0x38 getnewvnode() at getnewvnode+0x564 devfs_allocv() at devfs_allocv+0xe0 devfs_root() at devfs_root+0x38 devfs_mount() at devfs_mount+0xf0 vfs_mount() at vfs_mount+0x910 mount() at mount+0xd8 syscall() at syscall+0x3f4 XentSys1() at XentSys1+0x10 Ummm... vfs_object_create(vp, p, p-p_ucred); is there actually a ucred this early in startup? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: promiscuous mode
This server runs only ssh, bind and natd, but I´m certain in my case the problem is with bind and it have cause me a problem, the machine delay a lot to resolve a DNS when it change to promiscous mode, but I don´t why it is change to. Ronan Lucio Many programs put the ethernet card into permiscuous mode (i.e. tcpdump). Tom - Original Message - From: "Ronan Lucio" [EMAIL PROTECTED] To: "Thomas T. Veldhouse" [EMAIL PROTECTED] Sent: Monday, March 12, 2001 5:22 PM Subject: Re: promiscuous mode Your ethernet card went into promiscuous mode presumably. Did you run tcpdump? I ran trafshow, but I didn´t see anything weird, I think there was something happend but I didn´t get to see what. Ronan Lucio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
"David O'Brien" [EMAIL PROTECTED] writes: On Sat, Mar 10, 2001 at 10:32:23PM -0800, Dima Dorfman wrote: Peter Wemm [EMAIL PROTECTED] writes: The version of the patch for -current uses the softdep mount option only. If you remove the mount option, you dont get softupdates. In this case, it might be better to just turn it on by default and let Problem is many still feel it should not be used on / . There's always the 'nosoftdep' mount option. It's also possible to enable it by default on everything except the root filesystem, but that's a [minor] POLA violation. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
"David O'Brien" [EMAIL PROTECTED] writes: As long as someone that is familiar with all the "cool" and more esoteric uses of `md' was consulted to ensure the framework is sufficiently capable. If everyone (well, I guess mostly everyone) can agree on a suitable format for this md.conf, I'll write the code. Someone already proposed that mdconfig should be able to parse a config and configure the devices based on that, but it was dropped in favor of a mount_md wrapper some time ago. Again, if someone can come up with a format for md.conf that most people won't object to, I will write the code. I don't care if you want to call it mdon or stick it in mdconfig. Regards Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
On Mon, Mar 12, 2001 at 05:12:13PM -0800, Dima Dorfman wrote: There's always the 'nosoftdep' mount option. It's also possible to enable it by default on everything except the root filesystem, but that's a [minor] POLA violation. I fail to see what is wrong with defaulting to `off'. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall option for softupdates
"David O'Brien" [EMAIL PROTECTED] writes: On Mon, Mar 12, 2001 at 05:12:13PM -0800, Dima Dorfman wrote: There's always the 'nosoftdep' mount option. It's also possible to enable it by default on everything except the root filesystem, but that's a [minor] POLA violation. I fail to see what is wrong with defaulting to `off'. Right now, nothing. What mckusick was saying was that he didn't want to have a "field day" where everyone would have to put "softdep" for their filesystems in /etc/fstab. Yes, this isn't happening now since ps's patches are backwards-compatible, but unless you always want to keep that backwards-compatibility (which isn't bad, IMO), everyone will eventually have to do it. I've no opinion either way; I'm simply restating what I saw mckusick agree to. Regards Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
On Mon, 12 Mar 2001, Mark Murray wrote: Lots of security minded people what _all_ the interrupt entropy they can get, and this method gives them that while allowing others to throttle the harvester back. Lots of -CURRENT users want to be able to use their systems to write code without tripping over /dev/random and friends. I hear lots of people objecting to this code and alot of handwaving in response. Choose reasonable defaults already. The -CURRENT cvs tree isn't the proper venue for doing crypto research. 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-current" in the body of the message
Re: cp MAKEDEV /dev - on a system with devfs
In message [EMAIL PROTECTED], Jean Louis Ntakpe writes: Hi, In /usr/src/etc/Makefile: "make distribution" is still trying to copy MAKEDEV to /dev on a system with devfs mounted to /dev. Since devfs is default, is this behaviour correct or my /etc/make.conf is missing something ? I think that MAKEDEV should be moved away from /dev. Ideally it belongs somewhere rather obscure, but /etc/MAKEDEV is ok with me. /sbin would be better. I thought only sysv kept non-startup executables in /etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
I mostly agree with this, but let's also remember that this is -CURRENT too and that Kris Mark others have been pretty good about feeling sorry for you when you get hung up... ahem- responding to and fixing issues :-) On Mon, 12 Mar 2001, Matthew N. Dodd wrote: On Mon, 12 Mar 2001, Mark Murray wrote: Lots of security minded people what _all_ the interrupt entropy they can get, and this method gives them that while allowing others to throttle the harvester back. Lots of -CURRENT users want to be able to use their systems to write code without tripping over /dev/random and friends. I hear lots of people objecting to this code and alot of handwaving in response. Choose reasonable defaults already. The -CURRENT cvs tree isn't the proper venue for doing crypto research. 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-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fix for OpenSSL -j build
Kris Kennaway [EMAIL PROTECTED] writes: Can everyone please test this patch against OpenSSL, which should fix the problems observed with -j builds as well as cleaning out the temporary ASM files. I can confirm that this fixes -j-enabled builds on a -current host a few days old. Thanks! Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fix for OpenSSL -j build
On Mon, Mar 12, 2001 at 07:55:01PM -0800, Dima Dorfman wrote: Kris Kennaway [EMAIL PROTECTED] writes: Can everyone please test this patch against OpenSSL, which should fix the problems observed with -j builds as well as cleaning out the temporary ASM files. I can confirm that this fixes -j-enabled builds on a -current host a few days old. Thanks! Great, thanks for testing! I'll commit this later. Kris PGP signature
double panic in kernel
I have 100% reproducable trap 12 panic in kernel. I thouhgt it appeared somewhere after 5th of february, but i was wrong. The problem is that when i try to compile something with "make -j 2" - it panics and i can't backtrace the first fault point. :( If i simply use make, i have a chanse to build and install this something. So what am i doing wrong? How can i solve this problem? Any help? Here is dmesg, config and gdb -k output: dmesg: Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #7: Mon Mar 12 16:49:57 MSK 2001 root@ws-ilmar:/usr/src/sys/compile/WS_ILMAR3 Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 167046521 Hz CPU: Pentium/P55C (167.05-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 41943040 (40960K bytes) avail memory = 37654528 (36772K bytes) Preloaded elf kernel "kernel" at 0xc032d000. Preloaded elf module "fire_saver.ko" at 0xc032d09c. Intel Pentium detected, installing workaround for F00F bug Random initialise Random initialise finish Using $PIR table, 7 entries at 0xc00f0a90 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xe000-0xe00f at device 1.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: serial bus, USB at 1.2 (no driver attached) pci0: bridge, PCI-unknown at 1.3 (no driver attached) pci0: display, VGA at 12.0 (no driver attached) atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ed0 at port 0x340-0x35f iomem 0xd8000 irq 5 on isa0 ed0: address 00:50:4d:00:53:32, type NE2000 (16 bit) fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0303 can't assign resources Generator gate Generator gate finish Generator gate Generator gate finish Generator gate Generator gate finish Generator gate Generator gate finish OWNERSHIP Giant == 1 sched_lock == 0 ad0: 2014MB ST32122A [4092/16/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0a WARNING: / was not properly dismounted config: machine i386 cpu I586_CPU ident WS_ILMAR2 maxusers32 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options FFS #Berkeley Fast Filesystem #optionsFFS_EXTATTR #Extended attributes support #optionsUFS_ACL #UFS ACL Support #optionsMAC options SOFTUPDATES #Enable FFS soft updates support options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev device isa device pci device fdc device ata device atadisk # ATA disk drives device atkbdc 1 device atkbd device vga device splash device sc 1 device npx # Power management support (see NOTES for more options) #device apm device sio device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi #
Re: Ethernet entropy harvesting seriously pessimizes performance
Let me be clear about what I mean by interrupt rate limiting:
interrupt()
{
harvester(...)
}
It does that already.
harvester(...)
{
if (queue is not full) {
... add data to queue (reasonably sized queue, like 32 entries)
}
}
It does that. I guess we differ on the idea of "reasonable".
queue-runner(...)
{
for(;;) {
sleep for 1/10 second
Pull next item (if any) off queue
}
}
It almost does that, except it sleeps every N items where the user
is given control of N.
That is what my patch does. If a high rate of interrupts occur, the
queue becomes full almost instantly because the queue-runner only
pulls one item off per 1/10 second. The result is that the
harvester() routine effectively becomes a NOP for most of the
interrupts.
My code does that. Do a "cat /dev/zero /dev/random"
to see it in action.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Tracking down problem with booting large kernels (bug in locore.s)
On my system (dual PII/400 running -current), I've noticed for some time that if I build a kernel with too many device drivers in it (where "too many" seems to correspond to text size 3M for the resulting kernel), the system reboots itself immediately upon booting with the new kernel. Other people have noticed this before (see the thread "Recent kernels won't boot" in the mailing list archives at http://www.freebsd.org/mail/archive/2000/freebsd-current/20001015.freebsd-current.html ). However, no fix for or cause of the problem was ever identified, and the problem still exists in -current cvsuped as of today. I spent some time tonight seeing if I could localize the exact place of the crash, and had some luck finding where it's crashing. The problem is annoyingly hard to track down, as even booting with DDB and boot -d wouldn't catch the bug; the kernel reboots before DDB starts. I had to resort to sticking "hlt" instructions (or calls to cpu_halt()) in various places and seeing if I could get the kernel to hang (telling me that the kernel had gotten as far as where I stuck the halt.) I narrowed the crash down to this area of locore.s (note the arrows). --- /* Now enable paging */ movlR(IdlePTD), %eax movl%eax,%cr3 /* load ptd addr into mmu */ movl%cr0,%eax /* get control word */ orl $CR0_PE|CR0_PG,%eax /* enable paging */ movl%eax,%cr0 /* and let's page NOW! */ #ifdef BDE_DEBUGGER /* * Complete the adjustments for paging so that we can keep tracing through * initi386() after the low (physical) addresses for the gdt and idt become * invalid. */ callbdb_commit_paging #endif No crashes as of here pushl $begin /* jump to high virtualized address */ ret /* now running relocated at KERNBASE where the system is linked to run */ begin: crashes before it gets here!!! /* set up bootstrap stack */ movlproc0paddr,%eax /* location of in-kernel pages */ -- The pushl and ret is where the boot code is jumping to "begin:" at its proper virtual address after the page tables are setup. I'm guessing that create_pagetables is somehow losing and creating bogus page tables such that the jump to the kernel virtual address space goes into deep space somewhere, but frankly the details of page tables on the i386 are beyond my expertise. So I'm posting this in hopes that someone on here *does* know enough to figure out what's going wrong when the kernel size is sufficiently large. Any takers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
kris We really need to provide a better rc.conf hook for doing this --
kris expecting people to write their own script just to create a /tmp
kris is lame.
Here is just an example script (CAUTION: not well-tested) to create a
filesystem/swap with mdconfig(8). This script support not only '/tmp
by mdconfig(8)', but also replaces 'swapfile' variable of rc.conf with
more generic way.
Sorry no diffs for rc.conf(5) nor any comments of this script, but
seeing is believing:)
-- -
Makoto `MAR' MATSUSHITA
#!/bin/sh
#
# mdconfig(8) knob for /etc/rc
#
# Example:
# mdconfig_filesystems='tmp swap'
#
# mdconfig_tmp_type='swap'
# mdconfig_tmp_size='32M'
# mdconfig_tmp_newfs_enable='YES'
# mdconfig_tmp_newfs_flags=''
# mdconfig_tmp_tunefs_enable='YES'
# mdconfig_tmp_tunefs_flags='-n enable'
# mdconfig_tmp_dir='/tmp'
# mdconfig_tmp_mode='1777'
# mdconfig_tmp_owner='root:wheel'
#
# mdconfig_swap_type="vnode"
# mdconfig_swap_file="/swapfile"
# mdconfig_swap_dir="swap"
#
# Note:
# - No support of 'mdconfig -u unit'.
# - No error checking of mdconfig(8).
#
for mdfs in ${mdconfig_filesystems}; do
eval _type=\$mdconfig_${mdfs}_type
eval _size=\$mdconfig_${mdfs}_size
eval _file=\$mdconfig_${mdfs}_file
eval _flags=\$mdconfig_${mdfs}_flags
eval _newfs_enable=\$mdconfig_${mdfs}_newfs_enable
eval _newfs_flags=\$mdconfig_${mdfs}_newfs_flags
eval _tunefs_enable=\$mdconfig_${mdfs}_tunefs_enable
eval _tunefs_flags=\$mdconfig_${mdfs}_tunefs_flags
eval _dir=\$mdconfig_${mdfs}_dir
eval _mode=\$mdconfig_${mdfs}_mode
eval _owner=\$mdconfig_${mdfs}_owner
case ${_type} in
[Ss][Ww][Aa][Pp])
_args="-t swap -s ${_size}"
;;
[Vv][Nn][Oo][Dd][Ee])
_args="-t vnode -f ${_file}"
;;
[Mm][Aa][Ll][Ll][Oo][Cc])
_args="-t malloc -s ${size}"
;;
esac
_mddev=`mdconfig -a ${_args} ${_flags}`
case ${_newfs_enable} in
[Yy][Ee][Ss])
disklabel -r -w ${_mddev} auto
newfs ${_newfs_flags} /dev/${_mddev}c /dev/null 21
;;
*)
;;
esac
case ${_tunefs_enable} in
[Yy][Ee][Ss])
tunefs ${_tunefs_flags} /dev/${_mddev}c /dev/null 21
;;
*)
;;
esac
case ${_dir} in
[Ss][Ww][Aa][Pp])
swapon /dev/${_mddev}
;;
*)
if [ ! -d ${_dir} ]; then
mkdir -p ${_dir}
fi
mount /dev/${_mddev}c ${_dir}
if [ -n "${_mode}" ]; then
chmod ${_mode} ${_dir}
fi
if [ -n "${_owner}" ]; then
chown ${_owner} ${_dir}
fi
;;
esac
done
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
