teaching libutil about home directories
PR 19755 seeks to teach nologin(8) to look for .nologin files in a user's home directory. However, I feel that such knowledge is better obtained via the nologin capability in login.conf. Basically, file and program capabilities should perform tilde expansion. Libutil already does tilde-expansion for path capabilities, although the implemention would certainly be different for files/programs. The problem is that the libutil interface does not differentiate between strings, files, and programs. User-land utilities call login_getcapstr() to get capabilitiy values for any of these types. What would be needed is a separate interface, login_getcapfile, specifically for files/programs. Unfortunately, this would then require modifying all user-land utilities to use the new interface. Is this acceptable? Is so, I'll have patches together for review shortly. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: cvs commit: src/lib/libftpio Makefile (fwd)
"David O'Brien" wrote: On Thu, Jul 06, 2000 at 06:05:50PM -0700, Peter Wemm wrote: This is *not* the same as the a.out behavior which searched directories to find the largest number. ELF uses the symlinks and no searching, which is why ld and ld-elf.so is faster when locating directories and does not need ldconfig or the ld.so.cache. Correct me if I am wrong, ld-elf.so does still need ldconfig. And ld-elf.so does not use the symlink (if it did compat libs would not work). The ELF ldconfig does nothing except set the default search path for finding libraries: peter@t8000[12:54am]~-183 hd /var/run/ld-elf.so.hints 45 68 6e 74 01 00 00 00 80 00 00 00 37 00 00 00 |Ehnt7...| 0010 00 00 00 00 36 00 00 00 00 00 00 00 00 00 00 00 |6...| 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0080 2f 75 73 72 2f 6c 69 62 3a 2f 75 73 72 2f 6c 69 |/usr/lib:/usr/li| 0090 62 2f 63 6f 6d 70 61 74 3a 2f 75 73 72 2f 58 31 |b/compat:/usr/X1| 00a0 31 52 36 2f 6c 69 62 3a 2f 75 73 72 2f 6c 6f 63 |1R6/lib:/usr/loc| 00b0 61 6c 2f 6c 69 62 00 |al/lib.| ld(1) resolves the symlinks. ld-elf.so.1 searches for the full filename in the directory path from ldconfig -elf. objdump --all-headers /usr/bin/vi: ... Dynamic Section: NEEDED libncurses.so.5 NEEDED libc.so.4 .. All ld-elf.so.1 has to do is look for the first one of: /usr/lib/libc.so.4 /usr/lib/compat/libc.so.4 /usr/X11R6/lib/libc.so.4 /usr/local/lib/libc.so.4 This is just done with a series of open(2) calls and is very cheap. The first one it can open it uses. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config/hints changes: panic booting pcvt kernel
Hellmuth Michaelis wrote: After the latest config/hints changes, just commenting the syscons driver "sc" line and uncommenting the pcvt "vt" line in the GENERIC kernel config file, a booting kernel panics after the the message "atkbdc0: Keyboard controller (i8042) .." with a fatal trap 12, page fault while in kernel mode. This is reliably reproducible on my 2 test machines running current cvsuped a day ago. I'm now trying and searching for two days and i'm running out of ideas. It might be that i'm doing something very stupid here, but i tried hard to make shure i'm doing not. Help I recall there were lots of problems with syscons after the hints change. *IF* people had the USERCONFIG option, things would work. Otherwise... I do not know if vt suffers from the same problem, nor do I know if the fix done was specific to syscons or not. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
On Sun, 11 Jun 2000, Luigi Rizzo wrote:
Hi,
i understand that this means maybe a somwthat
large change in the system, but what do you think
if we have a lok at implementing the CPU scheduler using
weights instead of strict priorities ?
Do we have parts of the kernel which rely on priority
to implement locking etc ?
This would not be too different from what the EclipseBSD people
did, and the code i recently committed to dummynet can be easily
reused to this purpose, and it is efficient.
With a little bit of guidance (I am not too familiar with that area
of the code) i think we can do something good with little
effort.
I've been thinking about this a lot. As for the current scheduler, a
NICE_WEIGHT of 1.8 seems to work nicely; see the attached patch. I
have been looking more into making things more like Eclipse. I have to
say I'm very impressed with their work in implementing QoS, and we
would do well to update some of our ancient designs to a model that
resembles theirs. I'm looking at their process and disk scheduler now,
after reading their network scheduling paper from the Usenix proceedings.
I'm very interested in finding a better algorithm than the current one,
yes :)
cheers
luigi
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
Index: sys/kern/kern_synch.c
===
RCS file: /usr2/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.95
diff -u -r1.95 kern_synch.c
--- sys/kern/kern_synch.c 2000/07/04 11:25:23 1.95
+++ sys/kern/kern_synch.c 2000/07/08 00:20:23
@@ -916,7 +916,7 @@
if (p-p_rtprio.type == RTP_PRIO_NORMAL) {
newpriority = PUSER + p-p_estcpu / INVERSE_ESTCPU_WEIGHT +
- NICE_WEIGHT * (p-p_nice - PRIO_MIN);
+ (p-p_nice - PRIO_MIN) * NICE_WEIGHT;
newpriority = min(newpriority, MAXPRI);
p-p_usrpri = newpriority;
}
Index: sys/sys/proc.h
===
RCS file: /usr2/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.106
diff -u -r1.106 proc.h
--- sys/sys/proc.h 2000/06/22 22:27:16 1.106
+++ sys/sys/proc.h 2000/07/08 00:21:14
@@ -405,10 +405,10 @@
* the range 100-256 Hz (approximately).
*/
#defineINVERSE_ESTCPU_WEIGHT 8 /* 1 / (priorities per estcpu level)
*/
-#defineNICE_WEIGHT 1 /* priorities per nice level */
+#defineNICE_WEIGHT 9 / 5 /* priorities per nice level */
#definePPQ (128 / NQS) /* priorities per queue */
#defineESTCPULIM(e) \
-min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * PRIO_TOTAL - PPQ) + \
+min((e), INVERSE_ESTCPU_WEIGHT * (PRIO_TOTAL * NICE_WEIGHT - PPQ) + \
INVERSE_ESTCPU_WEIGHT - 1)
extern u_long ps_arg_cache_limit;
Re: config/hints changes: panic booting pcvt kernel
From the keyboard of Daniel C. Sobral:
After the latest config/hints changes, just commenting the syscons driver
"sc" line and uncommenting the pcvt "vt" line in the GENERIC kernel config
file, a booting kernel panics after the the message "atkbdc0: Keyboard
controller (i8042) .." with a fatal trap 12, page fault while in kernel mode.
This is reliably reproducible on my 2 test machines running current cvsuped
a day ago.
I'm now trying and searching for two days and i'm running out of ideas. It
might be that i'm doing something very stupid here, but i tried hard to make
shure i'm doing not. Help
I recall there were lots of problems with syscons after the hints
change. *IF* people had the USERCONFIG option, things would work.
Otherwise...
I do not know if vt suffers from the same problem, nor do I know if the
fix done was specific to syscons or not.
Thanks for the reply - it seems indeed to be a strange problem. In the mean-
time i found out that the pcvt probe routine was never called until i added
something like DEVMETHOD(device_identify, pcvt_identify) to the device
methods structure.
But the effect is the same, it still panics after
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
with
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc019c73f
stack pointer = 0x10:0xc0346aac
frame pointer = 0x10:0xc0346aac
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
interrupt mask = net tty bio cam
kernel: type 12 trap, code=0
Stopped at strcmp+0x1b:cmpb%al,0(%edx)
a ddb trace gives:
strcmp(0,c026a120) at strcmp+0x1b
kbd_get_switch(c026a120,c0a2d060,c0a6a880,c0346b10,c0241bb8) at kbd_get_switch+$
atkbd_probe_unit(0,0,1,1,c0a2e078) at atkbd_probe_unit+0x10
atkbdprobe(c0a72a80,c0a72a80,c0a6a880,c0a72a80,1) at atkbdprobe+0xdc
device_probe_child(c0a6a880,c0a72a80,c0a72a80,c0a6a880,0) at device_probe_child$
device_probe_and_attach(c0a72a80) at device_probe_and_attach+0x35
bus_generic_attach(c0a6a880,c0a2d080,c0a5b780,c0a6a880,1) at bus_generic_attach$
atkbdc_attach(c0a6a880,c0a6a880,c0346bc8,8,0) at atkbdc_attach+0x18c
device_probe_and_attach(c0a6a880) at device_probe_and_attach+0x8e
isa_probe_children(c0a5b780) at isa_probe_children+0xde
configure(0,344c00,34b000,0,c011c6d4) at configure+0x4a
mi_startup(c0346fb4,b0246,ffe,34b000,c017417d) at mi_startup+0x70
begin() at begin+0x4b
The code where it panics is in /sys/dev/kbd/kbd.c:
SLIST_FOREACH(p, keyboard_drivers, link) {
if (strcmp(p-name, driver) == 0)
return p-kbdsw;
}
list = (const keyboard_driver_t **)kbddriver_set.ls_items;
while ((p = *list++) != NULL) {
if (strcmp(p-name, driver) == 0)
^
return p-kbdsw;
}
when this statement should get executed.
The strange thing is that now pcvt is correctly probed and attached (and
the keyboard is accessed and does function) so the keyboard structures should
have been initialised correctly - but still there is this null pointer in the
kbd_get_switch ..
Any hints from the more "hints-knowledged" would be highly appreciated .. ;-)
hellmuth
--
Hellmuth MichaelisTel +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77
Oldesloer Strasse 97-99 Mail hm [at] hcs.de
D-22457 Hamburg WWW http://www.hcs.de
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Softupdates panic on SMP system
Hi,
I just got a softupdates related panic on my dual PPro during
buildworld. Sources from July, 4th. Build with -j4.
I'll keep the dump if there's any need.
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc0177a29 in panic (fmt=0xc0298c54 "from debugger")
at ../../kern/kern_shutdown.c:553
#2 0xc0133195 in db_panic (addr=-1071190004, have_addr=0, count=-1,
modif=0xc688e84c "") at ../../ddb/db_command.c:433
#3 0xc0133135 in db_command (last_cmdp=0xc02d4994, cmd_table=0xc02d47f4,
aux_cmd_tablep=0xc0315320) at ../../ddb/db_command.c:333
#4 0xc01331fa in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc01353b7 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc026ed51 in kdb_trap (type=3, code=0, regs=0xc688e95c)
at ../../i386/i386/db_interface.c:158
#7 0xc028095c in trap (frame={tf_fs = -964165608, tf_es = -1072103408,
tf_ds = -1039466480, tf_edi = 0, tf_esi = 256, tf_ebp = -964105820,
tf_isp = -964105848, tf_ebx = -1070871776, tf_edx = -1744831553,
tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1071190004, tf_cs = 8, tf_eflags = 598, tf_esp = -1070836221,
tf_ss = -1070971726}) at ../../i386/i386/trap.c:552
#8 0xc026f00c in Debugger (msg=0xc02a44b2 "panic") at machine/cpufunc.h:64
#9 0xc0177a20 in panic (fmt=0xc02bcb20 "flush_pagedep_deps: flush failed")
at ../../kern/kern_shutdown.c:551
#10 0xc0243521 in flush_pagedep_deps (pvp=0xc656a380, mp=0xc0d05400,
diraddhdp=0xc0f08ba4) at ../../ufs/ffs/ffs_softdep.c:4296
#11 0xc0242de8 in softdep_sync_metadata (ap=0xc688eaf0)
at ../../ufs/ffs/ffs_softdep.c:3980
#12 0xc0246f62 in ffs_fsync (ap=0xc688eaf0) at ../../ufs/ffs/ffs_vnops.c:257
#13 0xc023dce8 in ffs_truncate (vp=0xc656a380, length=10752, flags=4,
cred=0xc0dd6c80, p=0xc6866f60) at vnode_if.h:537
#14 0xc0249d47 in ufs_direnter (dvp=0xc656a380, tvp=0xc66d7980,
dirp=0xc688ec3c, cnp=0xc688ee90, newdirbp=0x0)
at ../../ufs/ufs/ufs_lookup.c:844
#15 0xc024dcf3 in ufs_makeinode (mode=33188, dvp=0xc656a380, vpp=0xc688ee7c,
cnp=0xc688ee90) at ../../ufs/ufs/ufs_vnops.c:2163
#16 0xc024b530 in ufs_create (ap=0xc688ed94) at ../../ufs/ufs/ufs_vnops.c:186
#17 0xc024dd7d in ufs_vnoperate (ap=0xc688ed94)
at ../../ufs/ufs/ufs_vnops.c:2287
#18 0xc01ad4ea in vn_open (ndp=0xc688ee68, flagp=0xc688ee34, cmode=420)
at vnode_if.h:106
#19 0xc01a9685 in open (p=0xc6866f60, uap=0xc688ef80)
at ../../kern/vfs_syscalls.c:992
#20 0xc0281385 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 8, tf_esi = 672435712, tf_ebp = -1077939112,
tf_isp = -964104236, tf_ebx = 672369188, tf_edx = 672435712,
tf_ecx = 16, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 672284676,
tf_cs = 31, tf_eflags = 647, tf_esp = -1077939156, tf_ss = 47})
at ../../i386/i386/trap.c:1126
#21 0xc026f71b in Xint0x80_syscall ()
cannot read proc at 0
(kgdb) up 9
#9 0xc0177a20 in panic (fmt=0xc02bcb20 "flush_pagedep_deps: flush failed")
at ../../kern/kern_shutdown.c:551
551 Debugger ("panic");
(kgdb) list
546 printf("lapic.id = %08x\n", lapic.id);
547 #endif
548
549 #if defined(DDB)
550 if (debugger_on_panic)
551 Debugger ("panic");
552 #endif
553 boot(bootopt);
554 }
555
(kgdb) up
#10 0xc0243521 in flush_pagedep_deps (pvp=0xc656a380, mp=0xc0d05400,
diraddhdp=0xc0f08ba4) at ../../ufs/ffs/ffs_softdep.c:4296
warning: Source file is more recent than executable.
/*
* If we have failed to get rid of all the dependencies
* then something is seriously wrong.
*/
if (dap == LIST_FIRST(diraddhdp))
panic("flush_pagedep_deps: flush failed");
(kgdb) print dap
$1 = (struct diradd *) 0xc0e87200
(kgdb) print *dap
$2 = {da_list = {wk_list = {le_next = 0x0, le_prev = 0xc104e9bc},
wk_type = 10, wk_state = 32777}, da_pdlist = {le_next = 0xc10dada0,
le_prev = 0xc0f08ba4}, da_offset = 8088, da_newinum = 104878, da_un = {
dau_previous = 0xc0f08b80, dau_pagedep = 0xc0f08b80}}
(kgdb) print diraddhdp
$3 = (struct diraddhd *) 0xc0f08ba4
(kgdb) print *diraddhdp
$4 = {lh_first = 0xc0e87200}
(kgdb) print *(diraddhdp-lh_first)
$5 = {da_list = {wk_list = {le_next = 0x0, le_prev = 0xc104e9bc},
wk_type = 10, wk_state = 32777}, da_pdlist = {le_next = 0xc10dada0,
le_prev = 0xc0f08ba4}, da_offset = 8088, da_newinum = 104878, da_un = {
dau_previous = 0xc0f08b80, dau_pagedep = 0xc0f08b80}}
(kgdb) print lk
$7 = {lkt_spl = 0, lkt_held = 60344}
(kgdb) print bp
$8 = (struct buf *) 0xc20b2300
(kgdb) print *bp
$9 = {b_io = {bio_cmd = 2, bio_dev = 0xc0d57a80, bio_blkno = 852656,
bio_offset = 436559872, bio_bcount = 8192,
bio_data = 0xc2b09000 "¤\201\001", bio_flags = 4, _bio_buf = 0x0,
bio_error = 0, bio_resid = 0, bio_done = 0xc01a09ac bufdonebio,
bio_driver1 = 0x0,
Re: config/hints changes: panic booting pcvt kernel
Hellmuth Michaelis wrote: Thanks for the reply - it seems indeed to be a strange problem. In the mean- time i found out that the pcvt probe routine was never called until i added something like DEVMETHOD(device_identify, pcvt_identify) to the device methods structure. It didn't? Please, interrupt loader(8) and type "show", and verify that hint.vt.0.at="isa" is present. If not... Either it is somehow missing from /boot/device.hints (it shouldn't -- GENERIC.hints does have it), or you don't have the default /boot/loader.rc cia. But the effect is the same, it still panics after atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 Did you add options USERCONFIG to see if that helps? Any hints from the more "hints-knowledged" would be highly appreciated .. ;-) Well, I'm definitely not the people to ask for help. That's why I'm cc'ing Peter on this, though. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jkh _DES: The Book of Bruce has only one sentence in it, and it says "the actual directives of my cult are left as an exercise for the reader. Good luck." EE jkh: does it really include the 'good luck' part? jkh EE: OK, I made that part up. jkh EE: I figured it should sound a bit more cheery than how Bruce initially dictated it to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Multiple free panic on SMP
After updating to the very latest current code, I get a multiple free panic on
my SMP machine. It always happen during buildworld in libc_r.
Important note : I have the snapshot code from Kirk.
The panic is in random_read which does a free. Here is the trace.
panic: free: multiple freed item 0xc0e92d00
mp_lock = 0003; cpuid = 0; lapic.id =
panic: from debugger
mp_lock = 0004; cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 41m7s
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc017819d in panic (fmt=0xc029dc34 "from debugger")
at ../../kern/kern_shutdown.c:553
#2 0xc0133435 in db_panic (addr=-1071169600, have_addr=0, count=-1,
modif=0xc667bc38 "") at ../../ddb/db_command.c:433
#3 0xc01333d5 in db_command (last_cmdp=0xc02d9db4, cmd_table=0xc02d9c14,
aux_cmd_tablep=0xc031a8f4) at ../../ddb/db_command.c:333
#4 0xc013349a in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc0135657 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc0273d05 in kdb_trap (type=3, code=0, regs=0xc667bd48)
at ../../i386/i386/db_interface.c:158
#7 0xc028590c in trap (frame={tf_fs = -1070399464, tf_es = -1070399472,
tf_ds = -966328304, tf_edi = 128, tf_esi = 256, tf_ebp = -966279792,
tf_isp = -966279820, tf_ebx = -1070954959, tf_edx = 0, tf_ecx = 32,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071169600, tf_cs = 8,
tf_eflags = 524886, tf_esp = -1070814813, tf_ss = -1070951182})
at ../../i386/i386/trap.c:552
#8 0xc0273fc0 in Debugger (msg=0xc02a94f2 "panic") at machine/cpufunc.h:64
#9 0xc0178194 in panic (fmt=0xc02a8631 "free: multiple freed item %p")
at ../../kern/kern_shutdown.c:551
#10 0xc0173d43 in free (addr=0xc0e92d00, type=0xc03035e0)
at ../../kern/kern_malloc.c:336
#11 0xc0144340 in random_read (dev=0xc031e3c8, uio=0xc667bed8, flag=131072)
at ../../dev/randomdev/randomdev.c:100
#12 0xc01b1e67 in spec_read (ap=0xc667be6c)
at ../../miscfs/specfs/spec_vnops.c:262
#13 0xc0252774 in ufsspec_read (ap=0xc667be6c)
at ../../ufs/ufs/ufs_vnops.c:1830
#14 0xc0252ca1 in ufs_vnoperatespec (ap=0xc667be6c)
at ../../ufs/ufs/ufs_vnops.c:2308
#15 0xc01af0e8 in vn_read (fp=0xc1135d40, uio=0xc667bed8, cred=0xc0d9a780,
flags=0, p=0xc6580820) at vnode_if.h:334
#16 0xc0188db5 in dofileread (p=0xc6580820, fp=0xc1135d40, fd=3,
buf=0xbfbff064, nbyte=116, offset=-1, flags=0) at ../../sys/file.h:141
#17 0xc0188cab in read (p=0xc6580820, uap=0xc667bf80)
at ../../kern/sys_generic.c:110
#18 0xc0286335 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 1717986919, tf_esi = 3, tf_ebp = -1077940008,
tf_isp = -966279212, tf_ebx = 672082468, tf_edx = 63956,
tf_ecx = 672148482, tf_eax = 3, tf_trapno = 12, tf_err = 2,
tf_eip = 672042240, tf_cs = 31, tf_eflags = 643, tf_esp = -1077940196,
tf_ss = 47}) at ../../i386/i386/trap.c:1126
#19 0xc02746cb in Xint0x80_syscall ()
(kgdb) up 10
#10 0xc0173d43 in free (addr=0xc0e92d00, type=0xc03035e0)
at ../../kern/kern_malloc.c:336
336 panic("free: multiple freed item %p", addr);
(kgdb) print addr
$1 = (void *) 0xc0e92d00
(kgdb) print *addr
Attempt to dereference a generic pointer.
(kgdb) up
#11 0xc0144340 in random_read (dev=0xc031e3c8, uio=0xc667bed8, flag=131072)
at ../../dev/randomdev/randomdev.c:100
warning: Source file is more recent than executable.
100 ret = read_random(random_buf, c);
(kgdb) list
95 void *random_buf;
96
97 c = min(uio-uio_resid, PAGE_SIZE);
98 random_buf = (void *)malloc(c, M_TEMP, M_WAITOK);
99 while (uio-uio_resid 0 error == 0) {
100 ret = read_random(random_buf, c);
101 error = uiomove(random_buf, ret, uio);
102 }
103 free(random_buf, M_TEMP);
104 return error;
(kgdb) print random_buf
$2 = (void *) 0xc0e92d00
(kgdb) print uio
$3 = (struct uio *) 0xc667bed8
(kgdb) print *uio
$4 = {uio_iov = 0xc667beb0, uio_iovcnt = 1, uio_offset = 116, uio_resid = 0,
uio_segflg = UIO_USERSPACE, uio_rw = UIO_READ, uio_procp = 0xc6580820}
More details if needed of course.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs-crypto unknown
In article [EMAIL PROTECTED], Trevor Johnson [EMAIL PROTECTED] wrote: Personally, I use the separate collections because cvsup times out otherwise (I guess my connection is too slow). A slow network won't cause this. There must be some other problem. The cvsupd server times out a connection only if it has had no network traffic for 15 minutes. Even 1 byte every 15 minutes will keep it from timing out. Also, assuming you're grabbing the whole src tree, using separate collections instead of src-all doesn't decrease the network traffic. In fact, it increases the traffic slightly. I should also mention that using separate collections loads the servers more than using src-all. Really if you want to sync with the whole src tree, using src-all is the best in every way. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
smbfs problem
Hi Boris, I have a strange problem with smbfs, where the mounted share times out and becomes inaccessible after a period of time. I haven't been able to pinpoint the exact moment when it happens, but basically: hightemplar:/home/alex$ mount /dev/da0s1a on / (ufs, local, writes: sync 135 async 19893, reads: sync 3575 async 133) /dev/da0s1f on /usr (ufs, local, writes: sync 33050 async 168568, reads: sync 228738 async 13847) /dev/da0s1e on /var (ufs, local, writes: sync 13939 async 350912, reads: sync 14959 async 546) procfs on /proc (procfs, local) linprocfs on /usr/compat/linux/proc (linprocfs, local) //ALEX@PLUTO/USERS on /mnt/pluto (smbfs) hightemplar:/home/alex$ ls -l /mnt/pluto/ ls: : Broken pipe hightemplar:/home/alex$ cd /mnt/pluto hightemplar:/mnt/pluto$ pwd /mnt/pluto hightemplar:/mnt/pluto$ ls -al ls: .: Broken pipe umounting and mounting it again solves the problem. Also, smbutil doesn't seem to work: hightemplar:~$ smbutil lc SMB connections: Server: PLUTO VC: ALEX(root:wheel) 711 Share:USERS(root:wheel) 711 hightemplar:~$ smbutil view //alex@pluto smbutil: can't get handle to requester smbutil: could not login to server PLUTO: syserr = Invalid argument PLUTO is running Windows NT 4, not sure which Service Pack, either 5 or 6. I will be happy to help you debug this. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ppp -auto gone again
On Sun, Jul 09, 2000 at 06:04:47PM +0200, Daniel Rock wrote: - if (pri 0) + if (pri = 0) Groan. "The problem must be somewhere in ip.c, the other changes were purely cosmetic". Famous last words. Thanks, I've re-reverted to the current version, applied your patch and -auto mode works. /s/Udo (I need new glasses) -- I have learned over the years, that if it is the truth you seek, then honesty on your own part, is the best policy. That and torture. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Virus alert, was: Re: SCSI Question
These messages are infected with the kak virus. See http://www.cai.com/virusinfo/encyclopedia/descriptions/wscript.htm - Original Message - From: Josh Paetzel To: Robert Small ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Sunday, January 14, 1990 6:02 AM Subject: Re: SCSI Question - Original Message - From: Robert Small To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Saturday, July 08, 2000 5:45 PM Subject: SCSI Question Damon Hammis wrote: The jumpers are set wrong on the card. I had the exact same problem with an aha-1542 and aha-1540 card recently. The docs on the jumpers that you can get on Adaptec's site are kind of cryptic, but the card will work once you get the jumpers placed correctly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: regex(3)
* Daniel C. Sobral [EMAIL PROTECTED] [000709 12:46] wrote: I think all bugs with the performance improvements to regex(3) have all been solved now. I haven't heard of any problems for over a week about the first improvement (Boyer-Moore search), and I have now tested the code against the original test suit for Spencer's library. I'd like, thus, to merge the changes. If anyone have objections, please raise them now. :-) None other than waiting at least 2 weeks, or for 4.1 to come out. thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Virus alert, was: Re: SCSI Question
On Sun, 9 Jul 2000, Jeroen Ruigrok van der Werven wrote: -On [2709 21:20], Leif Neland ([EMAIL PROTECTED]) wrote: These messages are infected with the kak virus. See http://www.cai.com/virusinfo/encyclopedia/descriptions/wscript.htm Am I the only one to NOT see this? Probably not. It wasn't in the "Content-Type: text/plain" part of the attachment, just the "text/html" part. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Virus alert, was: Re: SCSI Question
-On [2709 22:40], Paul Herman ([EMAIL PROTECTED]) wrote: On Sun, 9 Jul 2000, Jeroen Ruigrok van der Werven wrote: -On [2709 21:20], Leif Neland ([EMAIL PROTECTED]) wrote: These messages are infected with the kak virus. See http://www.cai.com/virusinfo/encyclopedia/descriptions/wscript.htm Am I the only one to NOT see this? Probably not. It wasn't in the "Content-Type: text/plain" part of the attachment, just the "text/html" part. Ah right. Spotted it. Which brings us back to a few good rules: - do NOT post in HTML - do not configure your mailer to mail lame virus warnings back to lists where precedence is set to bulk. Thanks for reminding me of the text/html. I looked there before but failed to spot it. *sigh* -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl ``...by God I *KNOW* what this network is for, and you can't have it.'' -- Russ Albery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: etc/rc.d things...
Mike Meyer [EMAIL PROTECTED] writes: By all means, use start/stop args, but hard link the .sh files into seperate directories or something so that the order can be tweaked.. If all you want is to make sure that shutdown happens in the reverse order of startup, that can be done by reversing the list in rc.shutdown. But how about going a step further, and starting towards a user-friendly configuration process? Instead of being globbed at init time, etc/rc.d is a repository for things that take start/stop arguments. They are symlinked to /etc/init.d with numeric prefixes to control order at initialization time. Likewise, they can be symlinked to /etc/down.d (or shutdown.d) with numeric prefixes to control order at shutdown time. Note that the directories full of symlinks are in /etc, not in /usr/X11R6/etc, etc. The rc.d's in those are also treated as repositories, so you can symlink to files in those asd well. These should save a bit of time at boot; no need to fool with lists of directories, etc. - just one directory. The real work will be adding a one-line description near the start of the file: # Init: 300. Shutdown: -1. Description: Standard smtp (mail) daemon. (indicating that it should be installed as /etc/init.d/300sendmail.sh, and no shutdown installation is necessary). I guess you would like to says that scripts.sh lives in /etc/init.d while XXXscripts.sh lives in /etc/rc.d and /etc/shutdown.d. if not, you are at the oposite of the SystemV semantic ! and would be a pain for system administrators. why not to simply adopt the SystemV semantic ? not all is bad in System V :) Later, we can add a tool that globs the etc/rc.d directories for files with those lines, and provides a nice visual "system process configuration" tool, allowing you to click on these things to move them back and forth. Some rules regarding the shutdown/startup priorites might be needed for ports. Given some prodding, I might even be talked into taking a crack at the tool (an X tool, maybe) before there's a commitment to supporting this structure. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "%no-spam" pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "%no-spam" to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: regex(3)
On Mon, 10 Jul 2000, Daniel C. Sobral wrote: I think all bugs with the performance improvements to regex(3) have all been solved now. I haven't heard of any problems for over a week about the first improvement (Boyer-Moore search), and I have now tested the code against the original test suit for Spencer's library. I'd like, thus, to merge the changes. If anyone have objections, please raise them now. :-) I'd prefer you waited a bit longer. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Virus alert, was: Re: SCSI Question
Jeroen Ruigrok van der Werven wrote: -On [2709 21:20], Leif Neland ([EMAIL PROTECTED]) wrote: These messages are infected with the kak virus. See http://www.cai.com/virusinfo/encyclopedia/descriptions/wscript.htm Am I the only one to NOT see this? Both the original postings look normal in mutt whichever way I use to look at them. Try "|less". I think it says a lot that you have to make special effort to even _see_ the virus on FreeBSD, when on Windows it probably gets executed by default... -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D PGP signature
Re: Softupdates panic on SMP system
I did some thinking about this, but no real code inspection, on a walk today- I think what is occurring is that the list of directory updates is getting refreshed from another process while the first process' list is being written out. A quick hack would be to make sure this doesn't happen (no -j4 for loose and gross and incomplete, some kind of worklist ownership token so that when process A wakes back up and looks at the worklist again it can see whether it still owns that list (after all, it drops the locks so it do the write). This is mostly a Kirk issue- he could say much quicker than I about this- I'd file this as a PR - I could fool around with it a little myself, but later this week. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0-20000706-SNAP boot floppy failure
Hi, In case anyone else it seeing this yet, or possibly working on it, the 0706 snap boot floppy boots up into sysinstall and then hangs. Switching to the debug screen yields: DEBUG: ioctl(3, TIOCCONS, NULL) = 0 (success) DEBUG: Can't open PC-card controller /dev/card0. and that's it. I'll try to take a look at this later this evenning, or in the morning. Any comments are appreciated. Thanks! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic with latest pcm commits?
I just cvsup'd new sources as of an hour of this posting, and built a kernel. When I try to play an MP3 with mpg123, a kernel panic occurs. Also, rev. 1.27 of src/sys/dev/sound/pcm/channel.c is the latest version of this file that doesn't cause loud popping sounds when I try to play an MP3, i.e., versions 1.28-1.32 cause problems. My sound card is an ESS 1868 ISA. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Virus alert, was: Re: SCSI Question
Ben Smithurst wrote: Jeroen Ruigrok van der Werven wrote: -On [2709 21:20], Leif Neland ([EMAIL PROTECTED]) wrote: These messages are infected with the kak virus. See http://www.cai.com/virusinfo/encyclopedia/descriptions/wscript.htm Am I the only one to NOT see this? Both the original postings look normal in mutt whichever way I use to look at them. Try "|less". I think it says a lot that you have to make special effort to even _see_ the virus on FreeBSD, when on Windows it probably gets executed by default... Netscape runs it as well. Seeing Netscape start java is a clear sign. It's probably harmless in this case, but I didn't wait to find that out. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
