Re: Can't build 5-current world on 4-stable box (perl doesn't bootstrap properly)
Mark Murray wrote: I reported it about a month ago, but the problem still persists. 5-current buildworld can't be performed on reasonably recent 4-stable system, hence source upgrade path from -stable to -current is broken. Please fix. I just did this on 4-STABLE with no problems at all. Well, then I suspect that it incorrectly works with my non-standard OBJDIR and/or non-standard sources location (/usr/current/src). I'll investigate further and let you know then. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
harvest_interrupt=YES slows down machine
Just installed new world, rebuild kernel, ran mergemaster and after reboot discovered that the system slowed down 4-5 times. Turning harvest_interrupt=NO in /etc/rc.conf solved the problem. The system in question is Toshiba Satellite Pro 445 notebook, see dmesg and kernel config attached with this message. Please investigate and fix what is necessary. In the meantime I would suggest turning harvest_interrupt=NO in default rc.conf, as it may hurt others as well. Thanks! -Maxim 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 #2: Tue Mar 6 15:34:23 EET 2001 root@notebook:/usr/src/sys/compile/NOTEBOOK Timecounter "i8254" frequency 1193125 Hz CPU: Pentium/P55C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 33685504 (32896K bytes) avail memory = 29618176 (28924K bytes) Preloaded elf kernel "kernel" at 0xc0321000. Preloaded elf module "snd_pcm.ko" at 0xc032109c. Preloaded elf module "snd_mss.ko" at 0xc032113c. Intel Pentium detected, installing workaround for F00F bug WARNING: size of kinfo_proc (648) should be 644!!! VESA: v2.0, 2048k memory, flags:0x0, mode table:0xc02af420 (140) VESA: CHIPS 6x554 Super VGA apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface isa0: ISA bus on motherboard ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 fdc0: NEC 765 or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 pcic0: Intel i82365 at port 0x3e0-0x3e1 on isa0 pcic0: Polling mode pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 pcm0: OPL3-SA3 (YMF715) at port 0x530-0x537,0x370-0x371 irq 5 drq 1 flags 0xc110 on isa0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 flags 0x1 on isa0 ppc0: Generic chipset (NIBBLE-only) in NIBBLE mode plip0: PLIP network interface on ppbus0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: TOS7400 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0600 can't assign resources unknown: PNP0600 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0e00 can't assign resources unknown: TOS7009 can't assign resources unknown: YMH0021 can't assign resources ad0: 1376MB TOSHIBA MK1403MAV [2796/16/63] at ata0-master BIOSPIO acd0: CDROM TOSHIBA CD-ROM XM-1502BN at ata1-master using BIOSPIO Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 ed0 at port 0x240-0x25f irq 3 slot 0 on pccard0 ed0: address 00:80:c8:88:86:b1, type NE2000 (16 bit) sio1 at port 0x2e8-0x2ef irq 10 slot 1 on pccard1 sio1: type 16550A machine i386 cpu I586_CPU # Coz we don't need stuff for I386, I486 and I686 ident GENERIC maxusers10 #optionsINVARIANTS #options INVARIANT_SUPPORT #options MUTEX_DEBUG #options WITNESS #options WITNESS_DDB #options DDB #optionsKTR #optionsKTR_EXTEND #optionsKTR_COMPILE=KTR_LOCK #optionsKTR_MASK=KTR_LOCK #optionsKTRACE options FFS options NFS options MSDOSFS options INET#InterNETworking options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options NSWAPDEV=1 options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION #optionsUSER_LDT options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L device random device isa #device pcm device fdc device ata device atadisk device atapicd device atkbdc 1 device atkbd device psm #optionsPSM_HOOKAPM device vga device sc 1 options VESA options SC_PIXEL_MODE #optionsSC_NO_SYSMOUSE options SC_TWOBUTTON_MOUSE options SC_HISTORY_SIZE=1024 device npx device sio device apm device
Can't boot recent kernels
Hi, I've been unable to boot any kernel (including GENERIC) built in the past week or so. The machine restarts immediately the kernel is entered, no console output whatsoever after the loader. Older kernels are fine. Have I missed some important change, and/or how do I go about debugging this? -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED]fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Correct size of kinfo_proc
On Tue, 6 Mar 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Maxim Sobolev writes: Well, we are now well informed about this, could we just fix sys/sys/user.h to match relity (credit goes to phk for broking it and ignoring my posts completely)? I've been kind of waiting for -current to actually work again. I hate commiting to -current when it's börked. Yes, fix it in sys/user.h for now, or better, do the right thing ^ wrong with version numbers. Version numbers would be essentially a regression to the way of doing things before Kirk's changes. The size of the struct used to work almost perfectly as a version number in practice, because changes almost always bloat things. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
Just installed new world, rebuild kernel, ran mergemaster and after reboot discovered that the system slowed down 4-5 times. Turning harvest_interrupt=NO in /etc/rc.conf solved the problem. The system in question is Toshiba Satellite Pro 445 notebook, see dmesg and kernel config attached with this message. Please investigate and fix what is necessary. In the meantime I would suggest turning harvest_interrupt=NO in default rc.conf, as it may hurt others as well. Apart from a ridiculously low maxusers (you have 10, I recommend 128), I'm not sure what the problem is. Please set maxusers to 128, and time a make world with interrupt harvesting on, and again with it off. 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: tape device names and devfs
On Tue, 6 Mar 2001, Christian Weisgerber wrote: Steve Kargl [EMAIL PROTECTED] wrote: dump.8 and dump(8) both refer explicitly to nsa0 and nrsa0 whereas sa0 and nsa0 are the actual device names in -current. The dump sources also refer to only the 'r' devices (_PATH_DEFTAPE is still "/dev/rsa0"). Then this should be fixed. The non-'r' device names have been standard in -CURRENT for quite some time. MAKEDEV only creates 'r'-names for backwards compatibility. The backwards compatibility cruft should have been removed in -current long ago. I removed all 'r' devices from my /dev about a year ago but haven't changed this in MAKEDEV. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
Steve Kargl wrote: The "r" in tape device names has traditionally meant "r"ewind. Nope. When this was discussed a while ago we got some authoritative information to the effect that "r" has always meant raw for tapes too. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Possession is 9/10 of the law. Except for Domain Names. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
Apart from a ridiculously low maxusers (you have 10, I recommend 128), I'm not sure what the problem is. I do not see why it is "ridiculously low". Even GENERIC recommends 32, while this is a small system intended to be used by only one person, so I do not see any problem with it. I never had any `out of descriptors' or `can't fork' during my routine operations on this box (2.5 years). Ok - then please leave it at 32. Please set maxusers to 128, and time a make world with interrupt harvesting on, and again with it off. I do not see what it will buy you. Could you please just believe my opinion based on the boot time? After all, even when this box unslowed make world takes 4-5 hours to complete, so with this slowdown it would take about 20-30, which I certainly can't tolerate without sufficient reason. If you want me to help you, please help me get good info. It's very important to me _know_ wether this is a boot slowdown or a generic - assertions are not good enough, I need hard facts. My own laptop (A Toshiba Libretto 110CT) does a make world in about 8 hours (and it always has). Interrupt harvesting has not made a noticable difference (I have not been keeping records, but an overnight build has not yet progressed into my breakfast). 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: harvest_interrupt=YES slows down machine
On Wed, 7 Mar 2001, Mark Murray wrote: Apart from a ridiculously low maxusers (you have 10, I recommend 128), I'm not sure what the problem is. I do not see why it is "ridiculously low". Even GENERIC recommends 32, while this is a small system intended to be used by only one person, so I do not see any problem with it. I never had any `out of descriptors' or `can't fork' during my routine operations on this box (2.5 years). Ok - then please leave it at 32. I use 10 with no problems. If you want me to help you, please help me get good info. It's very important to me _know_ wether this is a boot slowdown or a generic - assertions are not good enough, I need hard facts. My own laptop (A Toshiba Libretto 110CT) does a make world in about 8 hours (and it always has). Interrupt harvesting has not made a noticable difference (I have not been keeping records, but an overnight build has not yet progressed into my breakfast). Just do something that causes a lot of interrupts that go through the random harvester. E.g.: dd if=/dev/ad0 of=/dev/null causes 7750 interrupts/sec here (on a Celeron 366 overclocked to 522). The random task takes 100% of the available cpu cycles. This slows down cpu-bound processes by a factor of about 3.5. With a block size of 64k instead of the default of 512, this causes only 300 interrupts/sec. The random task takes a measly 27% of the cpu to process these. It can apparently only handle about 10 interrupts/second with a reasonable overhead (1%). Interrupt harvesting doesn't make much difference to makeworld because makeworld is cpu-bound. I estimate it to be about 2% here (20 interrupts per second for disk i/o to local disks. It would be a lot more for nfs). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
Just do something that causes a lot of interrupts that go through the random harvester. E.g.: dd if=/dev/ad0 of=/dev/null causes 7750 interrupts/sec here (on a Celeron 366 overclocked to 522). The random task takes 100% of the available cpu cycles. This slows down cpu-bound processes by a factor of about 3.5. With a block size of 64k instead of the default of 512, this causes only 300 interrupts/sec. The random task takes a measly 27% of the cpu to process these. It can apparently only handle about 10 interrupts/second with a reasonable overhead (1%). OK. Try tweaking the "Computational intensity factor" ;-) by dropping the kern.random.yarrow.bins: # sysctl -w kern.random.yarrow.bins=2 And let me know how well that works. 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
No Subject
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
: causes 7750 interrupts/sec here (on a Celeron 366 overclocked to : 522). The random task takes 100% of the available cpu cycles. This : slows down cpu-bound processes by a factor of about 3.5. With a block : size of 64k instead of the default of 512, this causes only 300 : interrupts/sec. The random task takes a measly 27% of the cpu to : process these. It can apparently only handle about 10 interrupts/second : with a reasonable overhead (1%). : :OK. Try tweaking the "Computational intensity factor" ;-) by dropping :the kern.random.yarrow.bins: : :# sysctl -w kern.random.yarrow.bins=2 : :And let me know how well that works. : :M :-- :Mark Murray I think it would be a much better idea to cap the number of interrupts per second the reseeder accepts. e.g. have a sysctl to set the max and default it to something reasonable, like 200. The seeder would thus only run 200 times a second even if A person were getting 7750 interrupts/sec. Frankly, once we have a good random seed it would only take about 10 interrupts a second to keep the random number generator in good shape, and possibly even less. Overkill is not necessary. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't build 5-current world on 4-stable box (perl doesn't bootstrap properly)
In message [EMAIL PROTECTED] Maxim Sobolev writes: : I reported it about a month ago, but the problem still persists. 5-current : buildworld can't be performed on reasonably recent 4-stable system, hence : source upgrade path from -stable to -current is broken. Please fix. I have the same box that you have (more or less) and I have no problems building my -current sources. Maybe some more details are required before it can be fixed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Reproducable panic
At some point in the past 24 hours, someone broke the kernel so I can
no longer run linux-opera:
root@des /var/crash# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) source ~des/kgdb
(kgdb) kernel 5
IdlePTD 4034560
initial pcb at 326020
panicstr: from debugger
panic messages:
---
panic: cpu_switch: not SRUN
panic: from debugger
Uptime: 7m24s
dumping to dev ad0b, offset 131104
dump ata0: resetting devices .. done
191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171
170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150
149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108
107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82
81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53
52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:478
478 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc019131b in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2 0xc01916e5 in panic (fmt=0xc02940b4 "from debugger")
at ../../kern/kern_shutdown.c:571
#3 0xc011f1d5 in db_panic (addr=-1071226260, have_addr=0, count=-1,
modif=0xd06ffc34 "") at ../../ddb/db_command.c:433
#4 0xc011f175 in db_command (last_cmdp=0xc02cd880, cmd_table=0xc02cd6e0,
aux_cmd_tablep=0xc0310cdc) at ../../ddb/db_command.c:333
#5 0xc011f23a in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc0121403 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7 0xc0265ffe in kdb_trap (type=3, code=0, regs=0xd06ffd34)
at ../../i386/i386/db_interface.c:164
#8 0xc0274a3b in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -798482176, tf_esi = 256, tf_ebp = -797966976,
tf_isp = -797967008, tf_ebx = 2, tf_edx = 1017, tf_ecx = 1021,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071226260, tf_cs = 8,
tf_eflags = 70, tf_esp = -1070857153, tf_ss = -1070967837})
at ../../i386/i386/trap.c:608
#9 0xc026626c in Debugger (msg=0xc02a53e3 "panic") at machine/cpufunc.h:60
#10 0xc01916dc in panic (fmt=0xc0272cdd "cpu_switch: not SRUN")
at ../../kern/kern_shutdown.c:569
#11 0xc0272cdd in sw0_2 ()
#12 0xc019b3d8 in msleep (ident=0xc0356158, mtx=0xd0682100, priority=344,
wmesg=0xc02a7fd8 "poll", timo=201) at ../../kern/kern_synch.c:459
#13 0xc01b00f3 in poll (p=0xd0681fe0, uap=0xd06fff80)
at ../../kern/sys_generic.c:927
#14 0xc0276510 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 142872464, tf_esi = 2000, tf_ebp = 142872424,
tf_isp = -797966380, tf_ebx = 142872464, tf_edx = 2000, tf_ecx = 1,
tf_eax = 168, tf_trapno = 12, tf_err = 2, tf_eip = 678761248,
tf_cs = 31, tf_eflags = 647, tf_esp = 142872400, tf_ss = 47})
at ../../i386/i386/trap.c:1184
#15 0xc026690d in syscall_with_err_pushed ()
#16 0x285cac35 in ?? ()
(kgdb) p *(struct proc *)0xd0681fe0
$1 = {p_procq = {tqe_next = 0xd0681980, tqe_prev = 0xd0680aa0}, p_slpq = {
tqe_next = 0x0, tqe_prev = 0xd0682a88}, p_list = {le_next = 0xd0681980,
le_prev = 0xd0680ab0}, p_cred = 0xc2479f60, p_fd = 0xc245bc00,
p_stats = 0xd06feb74, p_limit = 0xc2476700, p_upages_obj = 0xd06f1900,
p_procsig = 0xc2437140, p_flag = 0, p_sflag = 9, p_intr_nesting_level = 0,
p_stat = 3, p_pid = 448, p_hash = {le_next = 0x0, le_prev = 0xc090db00},
p_pglist = {le_next = 0xd0680aa0, le_prev = 0xd06819cc},
p_pptr = 0xd0681980, p_sibling = {le_next = 0x0, le_prev = 0xd06819e0},
p_children = {lh_first = 0xd0680aa0}, p_oppid = 0, p_dupfd = 0,
p_vmspace = 0xcaab3180, p_estcpu = 58, p_cpticks = 1, p_pctcpu = 0,
p_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
tqe_prev = 0xc5ecea80}}, c_time = 44652, c_arg = 0xd0681fe0,
c_func = 0xc019c88c endtsleep, c_flags = 14}, p_wchan = 0xc0356158,
p_wmesg = 0xc02a7fd8 "poll", p_swtime = 0, p_slptime = 0, p_itcallout = {
c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0,
tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_flags = 0},
p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {
tv_sec = 0, tv_usec = 0}}, p_runtime = 1099, p_uu = 0, p_su = 0,
p_iu = 0, p_uticks = 0, p_sticks = 1, p_iticks = 0, p_traceflag = 0,
p_tracep = 0x0, p_siglist = {__bits = {0, 0, 0, 0}}, p_textvp = 0xd06e3f80,
p_mtx = {mtx_lock =
Re: harvest_interrupt=YES slows down machine
I think it would be a much better idea to cap the number of interrupts per second the reseeder accepts. e.g. have a sysctl to set the max and default it to something reasonable, like 200. The seeder would thus only run 200 times a second even if A person were getting 7750 interrupts/sec. Frankly, once we have a good random seed it would only take about 10 interrupts a second to keep the random number generator in good shape, and possibly even less. Overkill is not necessary. 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reproducable panic
On Wed, Mar 07, 2001 at 07:25:41PM +0100, Dag-Erling Smorgrav wrote: At some point in the past 24 hours, someone broke the kernel so I can no longer run linux-opera: Same here with another Linux binary (Tivoli Storage Manager client). -- I believe the technical term is "Oops!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
: I think it would be a much better idea to cap the number of interrupts : per second the reseeder accepts. e.g. have a sysctl to set the : max and default it to something reasonable, like 200. The seeder would : thus only run 200 times a second even if A person were getting : 7750 interrupts/sec. Frankly, once we have a good random seed it would : only take about 10 interrupts a second to keep the random number : generator in good shape, and possibly even less. Overkill is not : necessary. : :This effectively happens. : :The harvest ring is a limited length, and any overflows are discarded. : :M The harvest ring is *HUGE* -- the ring is 1024 entries. Obviously it does not have a problem keeping up with a high interrupt rate. Also, my read of the thread that eats the data off that ring is that the thread pulls everything off the ring in a tight loop, which means that the ring will effectively be empty most of the time no matter how much data gets stuffed into it. So the 'limited length', even a small limited length, does not effectively limit the amount of work being done by the interrupt code. You need to do two things: 1) Reduce the ring size to something reasonable. 1024 is massive overkill. 32 would be just fine. 2) Add a mandatory tsleep in random_kthread() for EACH entry scanned from the harvest ring. Something reasonable like 1/10 second (similar to what you do if the harvest ring is empty. Or may you could pull off 5 entries at a time and then sleep. Right now you run it in a tight loop until the ring is completely empty. A 1/10 second sleep and a ring limit of 32 still gives you an effective 320 seeds per second. Still overkill, but at least not the massive overkill that its doing now. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
1) Reduce the ring size to something reasonable. 1024 is massive overkill. 32 would be just fine. I'll play with this. 2) Add a mandatory tsleep in random_kthread() for EACH entry scanned from the harvest ring. Something reasonable like 1/10 second (similar to what you do if the harvest ring is empty. Or may you could pull off 5 entries at a time and then sleep. Right now you run it in a tight loop until the ring is completely empty. Hmm. Sounds doable. I'll play. A 1/10 second sleep and a ring limit of 32 still gives you an effective 320 seeds per second. Still overkill, but at least not the massive overkill that its doing now. Event != seed. I'll juggle numbers and see if I can come up with any tweakables (sysctl's) that could give users more control here. Thanks! 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: Reproducable panic
On 07-Mar-01 Dag-Erling Smorgrav wrote:
At some point in the past 24 hours, someone broke the kernel so I can
no longer run linux-opera:
root@des /var/crash# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) source ~des/kgdb
(kgdb) kernel 5
IdlePTD 4034560
initial pcb at 326020
panicstr: from debugger
panic messages:
---
panic: cpu_switch: not SRUN
panic: from debugger
Uptime: 7m24s
dumping to dev ad0b, offset 131104
dump ata0: resetting devices .. done
191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173
172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154
153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135
134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116
115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96
95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70
69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44
43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18
17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:478
478 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc019131b in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2 0xc01916e5 in panic (fmt=0xc02940b4 "from debugger")
at ../../kern/kern_shutdown.c:571
#3 0xc011f1d5 in db_panic (addr=-1071226260, have_addr=0, count=-1,
modif=0xd06ffc34 "") at ../../ddb/db_command.c:433
#4 0xc011f175 in db_command (last_cmdp=0xc02cd880, cmd_table=0xc02cd6e0,
aux_cmd_tablep=0xc0310cdc) at ../../ddb/db_command.c:333
#5 0xc011f23a in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc0121403 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7 0xc0265ffe in kdb_trap (type=3, code=0, regs=0xd06ffd34)
at ../../i386/i386/db_interface.c:164
#8 0xc0274a3b in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -798482176, tf_esi = 256, tf_ebp = -797966976,
tf_isp = -797967008, tf_ebx = 2, tf_edx = 1017, tf_ecx = 1021,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071226260, tf_cs =
8,
tf_eflags = 70, tf_esp = -1070857153, tf_ss = -1070967837})
at ../../i386/i386/trap.c:608
#9 0xc026626c in Debugger (msg=0xc02a53e3 "panic") at machine/cpufunc.h:60
#10 0xc01916dc in panic (fmt=0xc0272cdd "cpu_switch: not SRUN")
at ../../kern/kern_shutdown.c:569
#11 0xc0272cdd in sw0_2 ()
#12 0xc019b3d8 in msleep (ident=0xc0356158, mtx=0xd0682100, priority=344,
wmesg=0xc02a7fd8 "poll", timo=201) at ../../kern/kern_synch.c:459
#13 0xc01b00f3 in poll (p=0xd0681fe0, uap=0xd06fff80)
at ../../kern/sys_generic.c:927
#14 0xc0276510 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 142872464, tf_esi = 2000, tf_ebp = 142872424,
tf_isp = -797966380, tf_ebx = 142872464, tf_edx = 2000, tf_ecx = 1,
tf_eax = 168, tf_trapno = 12, tf_err = 2, tf_eip = 678761248,
tf_cs = 31, tf_eflags = 647, tf_esp = 142872400, tf_ss = 47})
at ../../i386/i386/trap.c:1184
#15 0xc026690d in syscall_with_err_pushed ()
#16 0x285cac35 in ?? ()
(kgdb) p *(struct proc *)0xd0681fe0
Wrong process. This is the process that we just put to sleep. The panic is
complaining about the new process we just chose to run. I'll try and add in
an appropriate KASSERT() to the runqueue code to actually check this before
we get into cpu_switch and print out what process we are switching to, what its
p_stat is, etc.
This may be my fault in the recent change to linux_machdep.c. Hmmm, nope:
mtx_lock_spin(sched_lock);
p2-p_stat = SRUN;
setrunqueue(p2);
mtx_unlock_spin(sched_lock);
It should be fine. :(
(The change was to linux_clone()).
--
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
kernel build failure
Hi all From sources cvsup'd about an hour ago, "make depend" complains: ../../dev/ed/if_ed_pccard.c:58: miibus_if.h: No such file or directory and fails. This is after deleting the old kernel build dir. Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build failure
Did you add "device miibus" to you kernel configuration? Jim Bloom [EMAIL PROTECTED] Paul Allenby wrote: Hi all From sources cvsup'd about an hour ago, "make depend" complains: ../../dev/ed/if_ed_pccard.c:58: miibus_if.h: No such file or directory and fails. This is after deleting the old kernel build dir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
:Hmm. Sounds doable. I'll play. : : A 1/10 second sleep and a ring limit of 32 still gives you an effective : 320 seeds per second. Still overkill, but at least not the massive : overkill that its doing now. : :Event != seed. I'll juggle numbers and see if I can come up with any :tweakables (sysctl's) that could give users more control here. : :Thanks! : :M :-- :Mark Murray That would be cool, thanks! If the interrupt-based random seed stuff can be made really low profile, I think it will make a great addition to the system. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[HipHopProductions] And It HAS BEGUN!!!!!!!!!!!!
Hello! your domain today! My Groups | HipHopProductions Main Page for those who have recieved this e-mail in error, please e-mail [EMAIL PROTECTED] and we appologize for any inconvenience. DO NOT REPLY TO THIS E-MAIL. Hip Hop Productions Newsletter What da deal folk?!?!?!? You've just tuned into the hottest Hip Hop/R Newsletter the web has ever seen. You'll be hit off with the illest Hip Hop and R you've NEVER heard. These are the artist the big boys don't want you to hear cause they bringing more than just gimmicks, but real quality music. Everyone that receives this Newsletter is a trail-blazer in his/her own right, getting the heads up on fresh new music instead of the tired same ole same ole 20 song rotation you get on the radio. The Newsletter's first issue will hit your mailboxes Friday, March 9 approx 5pm Central Time, so be on the look out for that, and be ready for the talent that's gonna hit your mail box. Stay Tuned. HHP Moderator To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Re: Is my USB programmer broken?
On Wed, 7 Mar 2001, Leif Neland wrote: I've got a USB programmer for my Flashram for my Garmin GPS. It doesn't work, and causes blue screen under windows... Is this the proof for it is broken? 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: Tue Mar 6 19:17:59 CET 2001 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 usbd_new_device: addr=2, getting first desc failed uhub_explore: usb_new_device failed, error=IOERROR uhub0: device problem, disabling port 1 It can't be because FreeBSD doesn't know the USB programmer; it doesn't know my USB webcam either, and it still shows up as ugen with manufacturer name at boot. I run -STABLE, and was pondering over a problem I've been having with a USB device when I saw your problem. Could you try something? After you get that error above, move the device to the another USB port. I can manage to panic my system by doing that, except I'm doing it with a USB gamepad. I'm curious if it'll do the same for you. The way that I've come about that error is different from how you got there, though. I have a problem where any time I access my IDE hard drive (where Windows is -- FreeBSD is on SCSI disks), the USB gamepad I have plugged in goes nuts and FreeBSD eventually shuts the USB port off. I know it isn't a FreeBSD-specific problem, because exactly the same "nuttyness" happens when I'm in Windows. The problem with FreeBSD is, after FreeBSD has disabled the USB port, if I remove the device and then plug it back in the same port, I get the same error you've posted above. I can plug/unplug forever and still get that error, as long as I'm using the same USB port. But as soon as I plug it into the the other USB port on the root hub (my only "hub"), the system panics. Nick? :-) I'd have a crashdump for Nick or someone else to look at already, but I found out the hard way that the amr(4) driver doesn't take crashdumps. I then tried using a SCSI ZIP drive for the crashdump after labeling it and pointing dumpon(8) at it, which worked fine, until I tried to actually get the crashdump off of the drive after the crash. dumpon(8) won't accept the device (/dev/da0s1b in this case) so that I can use savecore to get the dump back off of it, but it accepted it to put it on it! Anyone know why that is happening? I don't remember the exact error dumpon was giving me at this time, sorry. I'll get it tonight if this doesn't ring a bell for someone. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MFC of Perl 5.6?
I searched the archives, and found this question asked, but no responses. I wonder when (if) Perl 5.6 will be MFC'd to 4.x. Thanks, _F To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/usr.bin/make suff.c
On Wed, Mar 07, 2001 at 04:55:08PM -0800, Thomas Moestl wrote: Log: Fix two bugs in null suffix handling. Both occured only after the suffix list was cleared. Rules with null suffixes would not be rebuilt when the suffixes were added again. Adding null suffix rules would fail when a rule for the same source was declared before the suffix list was cleared. PR: 23328, 24102 Reviewed by:will Approved by:rwatson Thanks. Remember to MFC this after 4.3-RELEASE, unless jkh objects to MFC'ing it now? -- wca PGP signature
httpd dump on freebsd-current
I use freebsd-current(src-cur.4750.gz),I make world, install new kernel, all thing are right. but i compile my php-4.0.4p1 and apache-1.3.17(static module), when i run /usr/local/www/bin/apachectl start, it die! httpd dump a core file! why? __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is my USB programmer broken?
I run -STABLE, and was pondering over a problem I've been having with a USB device when I saw your problem. Could you try something? After you get that error above, move the device to the another USB port. I can manage to panic my system by doing that, except I'm doing it with a USB gamepad. I'm curious if it'll do the same for you. I typed a longer letter, which pine ate... The short version is: No, I could not get a panic when I plugged it into the other port. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Email being rejected
I am using the standard freebsd.mc created during a buildworld. I have started noticing that I am missing/rejecting a lot of emails from places like: yahoogroups.com. It is a valid domain name, and I can't imagine why I would not want to get their emails (well, actually I can, but that is beside the point :). It appears that the problem is that they do not have a machine named "yahoogroups.com". I have been looking in the sendmail config stuff, and I have not yet figured out what rule I would need to change, but I need it fixed soon, customers are complaining. I think what needs to be done is add a rule that says (if it is a TLD, go ahead and accept it). And, yes, I realize that means I will get a lot of emails from places like: akjasdkfhaskhdf.com, but a "whois" lookup would be WAY TOO SLOW. - brian +---+--+ He rides a cycle of mighty days, and \ Wm Brian and Lori McCane represents the last great schizm among\ McCane Consulting the gods. Evil though he obviously is, \ [EMAIL PROTECTED] he is a mighty figure, this father of \ http://bmccane.maxbaud.net/ my spirit, and I respect him as the sons \ http://www.sellit-here.com/ of old did the fathers of their bodies. \ http://recall.maxbaud.net/ Roger Zelazny - "Lord of Light"\ http://www.maxbaud.net/ +---+--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MFC of Perl 5.6?
On Wed, Mar 07, 2001 at 06:33:09PM -0500, Forrest Aldrich wrote: I searched the archives, and found this question asked, but no responses. I wonder when (if) Perl 5.6 will be MFC'd to 4.x. ^^ Uh, _*WHY*_ are you sending this to freebsd-current rather than freebsd-stable where it is applicable??? BTW, you need to do a much better search. The reason is there are known bugs and issues in Perl 5.6.0, and it is expected 5.6.1 will be MFCed when it comes out. -- -- 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: Email being rejected
root I am using the standard freebsd.mc created during a buildworld. I root have started noticing that I am missing/rejecting a lot of emails root from places like: yahoogroups.com. It would be helpful to show the actual log message so we can determine why it is being rejected. If it is something like: Mar 7 18:45:51 horsey sendmail[69643]: f282jdlg069643: ruleset=check_mail, arg1=[EMAIL PROTECTED], [EMAIL PROTECTED] [10.0.1.1], reject=501 5.1.8 [EMAIL PROTECTED]... Domain of sender address [EMAIL PROTECTED] does not exist Then at the time the mail came in, yahoogroups.com was not resolvable. You can check with: nslookup -q= yahoogroups.com. nslookup -q=A yahoogroups.com. nslookup -q=MX yahoogroups.com. root I have been looking in the sendmail config stuff, and I have not yet root figured out what rule I would need to change, but I need it fixed root soon, customers are complaining. I think what needs to be done is root add a rule that says (if it is a TLD, go ahead and accept it). And, root yes, I realize that means I will get a lot of emails from places root like: akjasdkfhaskhdf.com, but a "whois" lookup would be WAY TOO root SLOW. From /usr/share/sendmail/cf/README: FEATURE(accept_unresolvable_domains) Normally, MAIL FROM: commands in the SMTP session will be refused if the host part of the argument to MAIL FROM: cannot be located in the host name service (e.g., an A or MX record in DNS). If you are inside a firewall that has only a limited view of the Internet host name space, this could cause problems. In this case you probably want to use this feature to accept all domains on input, even if they are unresolvable. ... An ``access'' database can be created to accept or reject mail from selected domains. For example, you may choose to reject all mail originating from known spammers. To enable such a database, use FEATURE(`access_db') ... OK Accept mail even if other rules in the running ruleset would reject it, for example, if the domain name is unresolvable. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/usr.bin/make suff.c
I don't object - they're obvious bug fixes. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
subscribe freensd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
