Re: Apples linking
On Thu, Nov 27, 2003 at 11:24:23AM -0500, Robert Watson wrote: [Darwin pre-binding] presumably applies to other processor architectures. The one thing that turns me off to this scheme is that I'd like it if we could find a way to represent this using solely existing BSD/UNIX kernel primitives (mmap, et al) and userspace, rather than adding special-purpose system calls that complicated various code paths, and that aren't portable. Compaq/HP Tru64 supports link-time pre-binding, called Quickstart. To use it, shared libraries are linked to load at mutually exclusive addresses and applications are linked assuming the preferred .so load addresses. At run-time, the rtld verifies that it can map every shared library at its preferred address and that each shared library is the same one the application was linked against (using checksums in the COFF headers). If all this is true, all the relocations are correct and execution starts immediately. If any checks fail, rtld falls back to the traditional check-every-symbol-and-relocation approach. The benefit is very fast start times - not much more overhead than starting a static executable. The disadvantages are: - if any library changes, all dependent applications must be relinked to maintain the fast start. In some cases a utility can be used to re-validate the checksums in the application if the library hasn't grown and is at the same address. - circular shared library dependencies aren't allowed - a writable common list of .so load addresses is needed at .so link time. - having reserved address space for each shared library results in a fragmented process address space and may impact on the space available to the application. For more details see the following links http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/ARH9VDTE/SHLBCHPX.HTM#using-quickstart http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/SUPPDOCS/OBJSPEC/NV140XXX.HTM#nav14-54 I don't believe it is feasible to do much about the i386 PIC overheads other than moving to a saner processor architecture. What other techniques are used to improve shared library startup times in other operating systems? Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
On Thu, Nov 27, 2003 at 02:10:22PM -0700, M. Warner Losh wrote: I'm wondering if anybody is using, or even able to use, the gpib driver. It uses the old ISA shims, and is one of the drivers that no one has acked working in when I ask about the old isa shim drivers. I always wanted to use it. I have plenty of old ISA GPIB cards here, but unfortunately I never found the time to play around with them so far. I'd also like to say that I'd love to see a good, and proper gpib framework in the tree, I second this. ;-) but it certainly won't be based on this driver! Oops, is it /that/ bad? The questions here are only 'does this driver work?' and 'is anybody able to use it?' Well, as I said above: I'm not using it so far, but given some time I may be able to find out if it's still working. cu Gerrit -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
dhcpclient problem
hi I have current from last friday and it takes ages for dhclient to get configuration its NOT problem of respodning server cause other computers get their IPs instantly... 5.1R didn show such behaviour in my log is Sending on BPF/mac-adress Sending on Socket/fallback whats this? this happens in aproximatly 50% cases so I really dont know what can be wrong... any sugests? thnx a lot r.d. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on 5.2 BETA: blockable sleep lock
On Fri, 2003-11-28 at 01:02, Don Lewis wrote: On 27 Nov, Stefan Ehmann wrote: On Wed, 2003-11-26 at 08:33, Don Lewis wrote: The problem is that selrecord() wants to lock a MTX_DEF mutex, which can cause a context switch if the mutex is already locked by another thread. This is contrary to what bktr_poll() wants to accomplish by calling critical_enter(). Strange enough that does not seem to happen with a kernel built without INVARIANTS and WITNESS. Does this make any sense or is this just by chance? You might try the patch below with WITNESS enabled. I don't have the hardware, so I can't test it. It compiles for me, but for all I know it could delete all your files if you run it. Tested it a few times and no panics - seems to work fine. Tested it again without the patch: panics immediately after starting alevt (not xawtv as initially stated). Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic: if_simloop: attempted use of a free mbuf!
Hello. I'm reaching assertion from /sys/net/if_loop.c:270. This is very easy to reproduce: First you need to put loopback into promiscuous mode: # tcpdump -i lo0 Then try to connect to loopback, for example: # telnet 127.0.0.1 22 Enjoy!:) -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Anybody using gp driver?
In message: [EMAIL PROTECTED] Gerrit Kühn [EMAIL PROTECTED] writes: : but it certainly won't be based on this driver! : : Oops, is it /that/ bad? I can't convince myself that it would have any chance of working. That's why I asked. : The questions here are only 'does this driver work?' and 'is anybody : able to use it?' : : Well, as I said above: I'm not using it so far, but given some time I may be : able to find out if it's still working. Please let me know if you succeed. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. Do you have options INVARIANTS in your kernel configuration? M_ASSERTVALID(..) (that was added to BPF_MTAP macro) do nothing if you don't have INVARIANTS enabled. Yuriy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Fri, 28 Nov 2003, Yuriy Tsibizov wrote: It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. Do you have options INVARIANTS in your kernel configuration? M_ASSERTVALID(..) (that was added to BPF_MTAP macro) do nothing if you don't have INVARIANTS enabled. Yes, I do: makeoptions DEBUG=-g # Debugging for use in -current options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on 5.2 BETA: blockable sleep lock
On Fri, 2003-11-28 at 01:02, Don Lewis wrote:
On 27 Nov, Stefan Ehmann wrote:
On Wed, 2003-11-26 at 08:33, Don Lewis wrote:
The problem is that selrecord() wants to lock a MTX_DEF mutex, which can
cause a context switch if the mutex is already locked by another thread.
This is contrary to what bktr_poll() wants to accomplish by calling
critical_enter().
Strange enough that does not seem to happen with a kernel built without
INVARIANTS and WITNESS. Does this make any sense or is this just by
chance?
You might try the patch below with WITNESS enabled. I don't have the
hardware, so I can't test it. It compiles for me, but for all I know it
could delete all your files if you run it.
Unfortunately, after running the patched kernel some time I got a
slightly different panic:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1145
panic messages:
---
panic: blockable sleep lock (sleep mutex) sellck @
/usr/src/sys/kern/sys_generic.c:1145
syncing disks, buffers remaining... 2248 2248 panic: mi_switch: switch
in a critical section
Uptime: 4m11s
Dumping 383 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368
---
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_csa.ko...done.
Loaded symbols for /boot/kernel/snd_csa.ko
Reading symbols from /boot/kernel/bktr_mem.ko...done.
Loaded symbols for /boot/kernel/bktr_mem.ko
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ext2fs/ext2fs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHOE/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug
Reading symbols from /boot/kernel/bktr.ko...done.
Loaded symbols for /boot/kernel/bktr.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc050f482 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc050f7d8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc05174e5 in mi_switch () at /usr/src/sys/kern/kern_synch.c:470
#4 0xc050f16e in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:312
#5 0xc050f7d8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#6 0xc0535e19 in witness_lock (lock=0xc075c8a0, flags=8,
file=0xc06c4d72 /usr/src/sys/kern/sys_generic.c, line=1145)
at /usr/src/sys/kern/subr_witness.c:609
#7 0xc0505aaa in _mtx_lock_flags (m=0xc075c8a0, opts=0,
file=0xc06f10bc äLmÀ\t, line=-1009577024)
at /usr/src/sys/kern/kern_mutex.c:221
#8 0xc053a016 in selrecord (selector=0xc3d313c0, sip=0xc075c8a0)
at /usr/src/sys/kern/sys_generic.c:1145
#9 0xc4174981 in bktr_close () from /boot/kernel/bktr.ko
#10 0xc04c6650 in spec_poll (ap=0xd8cdbafc)
at /usr/src/sys/fs/specfs/spec_vnops.c:379
#11 0xc04c5a88 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:122
#12 0xc057635c in vn_poll (fp=0x0, events=0, active_cred=0xc412b080,
td=0x0)
at vnode_if.h:537
#13 0xc0539851 in selscan (td=0xc3d313c0, ibits=0xd8cdbb9c,
obits=0xd8cdbb8c,
nfd=6) at /usr/src/sys/sys/file.h:272
#14 0xc05393bf in kern_select (td=0xc3d313c0, nd=6, fd_in=0xbfbfeb90,
fd_ou=0x0, fd_ex=0x0, tvp=0x0) at
/usr/src/sys/kern/sys_generic.c:816
#15 0xc0539026 in select (td=0x0, uap=0xd8cdbd14)
at /usr/src/sys/kern/sys_generic.c:720
#16 0xc06827e0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi =
134598312, tf_ebp = -1077941208, tf_isp = -657605260, tf_ebx = 0, tf_edx
= 6, tf_ecx = -1077941360, tf_eax = 93, tf_trapno = 12, tf_err = 2,
tf_eip = 673044815, tf_cs = 31, tf_eflags = 658, tf_esp = -1077941444,
tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#17 0xc067444d in Xint0x80_syscall () at {standard input}:136
(kgdb)
___
[EMAIL PROTECTED] mailing list
Re: panic on 5.2 BETA: blockable sleep lock
On Fri, 2003-11-28 at 10:31, Stefan Ehmann wrote: On Fri, 2003-11-28 at 01:02, Don Lewis wrote: On 27 Nov, Stefan Ehmann wrote: On Wed, 2003-11-26 at 08:33, Don Lewis wrote: The problem is that selrecord() wants to lock a MTX_DEF mutex, which can cause a context switch if the mutex is already locked by another thread. This is contrary to what bktr_poll() wants to accomplish by calling critical_enter(). Strange enough that does not seem to happen with a kernel built without INVARIANTS and WITNESS. Does this make any sense or is this just by chance? You might try the patch below with WITNESS enabled. I don't have the hardware, so I can't test it. It compiles for me, but for all I know it could delete all your files if you run it. Unfortunately, after running the patched kernel some time I got a slightly different panic: Please ignore the message above - this was the panic from an unpatched kernel - I was debugging the wrong core. Thanks again for quick help. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for 5.2-BETA lockup problems
Andre Oppermann wrote: Hello all, I've found what probably is going wrong in tcp_hostcache. The problem is me cutting corners (what goes around comes around...) in tcp_hc_insert when the bucket limit is reached. I made the #if 0 too big and the bucket was not removed from the tailqueue when we hit the bucket limit. A couple of lines later it is inserted again as head element which leads to an infinite loop either when the next lookup on the same bucket row is done, or when the the tcp_hc_purge function is run to timeout the entries. Please try the attached patch which should fix it. This appears to have succesfully cured my lockup. I now have the original kernel config booted again with full inet6 etc and it's not locked up. Regards, Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apples linking
On Fri, 2003-11-28 at 07:59, Peter Jeremy wrote: On Thu, Nov 27, 2003 at 11:24:23AM -0500, Robert Watson wrote: [Darwin pre-binding] presumably applies to other processor architectures. The one thing that turns me off to this scheme is that I'd like it if we could find a way to represent this using solely existing BSD/UNIX kernel primitives (mmap, et al) and userspace, rather than adding special-purpose system calls that complicated various code paths, and that aren't portable. Compaq/HP Tru64 supports link-time pre-binding, called Quickstart. To use it, shared libraries are linked to load at mutually exclusive addresses and applications are linked assuming the preferred .so load addresses. At run-time, the rtld verifies that it can map every shared library at its preferred address and that each shared library is the same one the application was linked against (using checksums in the COFF headers). If all this is true, all the relocations are correct and execution starts immediately. If any checks fail, rtld falls back to the traditional check-every-symbol-and-relocation approach. The benefit is very fast start times - not much more overhead than starting a static executable. This is approximately what happens on Win32 too. When developing DLLs for windows, I tend to manually pick a load address at link time. This is messy but it helps load time a lot for large projects. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent current panic
On Fri, 2003-11-28 at 08:49, Yuriy Tsibizov wrote: It looks very similar to http://www.freebsd.org/cgi/query-pr.cgi?pr=59576. You can revert to version 1.28 of net/bpf.h if you need tcpdump on lo, tun, ic, plip, disc or gif interface right now. just to note: I ran tcpdump on tunN (which was a pppoe interface) w/o problems two days ago (with a recent world) while debugging and testing other net related things. Do you have options INVARIANTS in your kernel configuration? M_ASSERTVALID(..) (that was added to BPF_MTAP macro) do nothing if you don't have INVARIANTS enabled. Im getting the same problem with the realtek driver (also getting lock ups but Ill post something else for that). I removed the error by patching if_re.c with a patch like :- http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_dc.c.diff?r1=1.9.2.53r2=1.9.2.54 (basically pass the mbuf to XX_encap instead of a pointer to it) which was the reason for the INVARIANT in the 1st place. This may not be the correct way to fix it. -- Simon Loader ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR or panic with ips driver (was Re: cvs commit: src/sys/dev/ips ips.c ips.h ips_commands.c)
Hello. On 2003/11/27 00:37:36, Martin Blapp wrote: mbr 2003/11/27 00:37:36 PST FreeBSD src repository Modified files: sys/dev/ips ips.c ips.h ips_commands.c Log: ServeRaid (at least 5i) didn't initialize correctly. To get them working (cache, automatic rebuild and hotswap) the FFDC info (First Failure Data Capture) on the adapter must be initialised. Logical drives in critical/degraded states weren't added to the drive list. FreeBSD was not able to see a degraded array after a reboot. Degraded drives are now also added to the drivelist and the state of the logical drive is given at boottime. The adapter type is detected from informations in nvram page 5 and displayed at boottime. Change IPS_OS_FREEBSD definition from 10 to 8 according to IBM specs. Submitted by: Patrick Guelat [EMAIL PROTECTED] Reviewed by:mbr, scottl Approved by:re Revision ChangesPath 1.6 +64 -2 src/sys/dev/ips/ips.c 1.5 +57 -2 src/sys/dev/ips/ips.h 1.7 +90 -0 src/sys/dev/ips/ips_commands.c After seeing this commit message, I've upgraded -CURRENT installed on NetFinity 6000R(with ServeRAID 4H) to catch up with the recent changes. However, LOR or panic still persists. You can panic your -CURRENT machine by creating a log of files in a directory. You can do it with a simple shell script like this: $ mkdir foo; i=0; while :; do echo $i foo/$i; i=$(($i+1)); done - If you have WITNESS_* options in the kernel config file, you'll see a lot of LOR messages on the console or in /var/log/messages, along with a bunch of `iobuf error 5', but the kernel doesn't panic(or takes very long time before it panics). - If you don't have WITNESS_* options in the kernel config file and run the code above, the kernel panics in a few minutes after seeing `iobuf error 5' messages. I've already submitted a PR for this as kern/57832, but still have no idea how to fix this. The traceback looks almost the same as it was a few months ago. Regards. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apples linking
David Rhodus wrote:
Terry Lambert wrote:
FWIW, even though I support the idea of dynamically linking
everything, the flipping of the switch there followed this
same pattern.
First, a disclaimer: this is me speaking for me; I do not speak
for Apple.
Terry, what are some of the changes that Apple made to have everything
dynamically linked in darwin ?
I can't speak authoritatively, since I wasn't ther when it happened;
however, there are two types of dynamic linking in MacOS X, and that's
probably the major thing.
The first kind of dynamic linking is more or less the traditional
sort, where you have a single library image, and binding occurs
at runtime.
The second kind uses what's called a split image, where code and
data sections are split and relocated at offsets relative to the
addresses 0x8000 and 0x9000. These addresses were chosen
because, like FreeBSD, the Intel version of Darwin maps process
memory into the kernel address space. I expect that Intel Darwin
is going to have to separate the kernel map from the user map, and
thus free up 3G of address space for the kernel and 1G of address
space for user processes, at some point, but I have no idea if there
are plans for this or not, it's just that I think it would be a good
idea. The 1:3 relationship between KVA and UVA in Intel Darwin is
problematic for large memory machines, for obvious reasons, and
dictates the location of the slit library map and the location of
the commpage (introduced in the most recent Darwin release). The
library code is loaded via a load_shared_file() system call. The
management of this space is given over to Apple's BI: third parties
can't create new split libraries; split libraries are limited to
system libraries supplied by Apple.
In the split image case, the libraries are prebound in the
executable images because they are at known offsets. The code is
mapped directly, and the data is also mapped directly, but mapped
as copy on write. In this case, the libraries most resemble the
System V shared library model, with no support for versioning, and
the binding occurs at installation time, and may occur again at
runtime, should conditions change. The same map area is used for
both code and data (there's no good reason for this), meaning the
reserved space is max(sizeof(code),sizeof(data)), plus some fudge
so that the library offsets need not be recalculated for every new
instance.
Obviously, this prebinding is much more explicit, and does not
suffer the runtime penalty for most of the shared libraries in OS's
like FreeBSD or Linux, it's not like the prebinding in DragonFlyBSD
(which has a higher runtime penalty than the Darwin approach).
Has anyone done timed runs lately on dynamically vers. static linking
on darwin ?
Yes. It's my understanding that this is why prebinding exists.
Again, this predates me, so my understanding here may be flawed.
Or did they find just cleaning up the dlopen code path seems
to be enough to pull dynamically linking everything ?
Dynamic linking in Darwin doesn't use dlopen, it uses another
family of routines. The dlopen code didn't exist in Darwin until
the latest release (Darwin uses dyld internally); in the latest
release, there is a compatability wrapper for dyld that implements
dlopen and family as conformant interfaces, but it's important to
note that these are library wrappers for library wrappers for
system calls, and are implemented indirectly; it's somewhat faster
to use the dyld code directly, if you have speed requirements.
Neither of these are used for shared library linking, for split
shared libraries, so the question isn't meaningful to ask in the
context of shared libraries.
FWIW: If FreeBSD wanted to use this approach, the safest way to do
it would b to split the user and kernel address space mappings; in
general, this will only mean modifying uiomove/copy{in|out}[str],
and dealing with the address mapping itself. This would free up
the KVA space not available to user space for use in mapping the
split shared libraries.
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apples linking
Robert Watson wrote: On Thu, 27 Nov 2003, David Rhodus wrote: what are some of the changes that Apple made to have everything dynamically linked in darwin ? Has anyone done timed runs lately on dynamically vers. static linking on darwin ? Or did they find just cleaning up the dlopen code path seems to be enough to pull dynamically linking everything ? In Darwin, all binaries but /sbin/init are dynamically linked. There are actually a couple more than that. I specifically did an audit of which programs on a fully installed binary Panther system were statically vs. dynamically linked. 8-). There are a number of interesting optimizations, including prebinding. The most interesting variation on the them is a series of system calls that manage a special shared region for prebound libraries. These calls are: int load_shared_file(); int reset_shared_file(); int new_system_shared_region(); Correct. You should also read this as never use these calls in your own code. My understanding is that they are always mapped into processes at the same address, so a prebound version of the library can be used across many applications. Yes. Their location is arrived at dynamically, and fixed statically; this has the same advantage as System V shared libraries, but doesn't burn chunks of address space for different versions of the same thing, as time goes forward. In particular, the libraries can be moved around, but when they are, the code that depends on them is re-prebound to know about the new location. If a library isn't found in the prebinding cache, the application does the work itself, but probably sends a message off. It does. This message triggers a prebinding. Normally, this is done automatically at the time the applicaiton is installed, but there are circumstances where it needs to be triggered lazily, and this handles that case. During system/application install, I believe OS X kicks off a tool to see if its current prebinding cache/layout/etc is optimal for the set of applications, and adjusts the cache as needed. If you use the standard installation tools (ViSE), yes. I don't have access to any of the performance measurements -- perhaps Terry does -- but this approach has a number of important benefits. I do, but the information is proprietary, for obvious reasons. In particular, it addresses the following issues: [ ... ] (4) It deals with the issue of needing fixup tables for shared libraries to get the right address, so it saves the fixup and the indirect that would be otherwise needed, as well. The one thing that turns me off to this scheme is that I'd like it if we could find a way to represent this using solely existing BSD/UNIX kernel primitives (mmap, et al) and userspace, rather than adding special-purpose system calls that complicated various code paths, and that aren't portable. It would b relatively trivial to add two flags, on to mmap(), and one to madvise(). The mmap() flag would indicate a global mapping into all process address spaces (and select a mapping in a reserved memory range for that purpose). The madvise() flag would indicate that the prebind region was being recreated for use by subsequently started processes. As I mentioned previously in this thread, it could be we could witness a lot of the benefits of this approach by simply using heuristics to increase the likelihood of libraries getting mapped to the same address in different processes, increasing the effectiveness (and reducing the size) of the prebinding cache. This is actually unlikely. Minimally, you would need to ensure against collisions, which is hard nough, but then you must also avoid collisions with shared memory/mmap/dlopen objects, as well. For this to work, a reserved address region is required. And for that, you would ned to take it from the KVA by splitting out the address spaces so that UVA = 4G, KVA = 4G instead of UVA + KVA = 4G, as it is today. This is something FreeBSD should consider anyway: a reserved space could be very useful, if only to represent the proc struct as R/O in user space to avoid all system call overhead for getpid/getppid/etc. system calls. It would also be useful to avoid reducing UVA to 2G or 1G (depending on intended memory usage patterns) when you have 4G of physical RAM installed in a machine. It would also give enough room so that the kmem_map would not need careful tuning to avoid mmory exhaustion panics. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI: VMware Workstation, ACPI support for FreeBSD guest
On Fri, 28 Nov 2003 21:03:24 +0900 Makoto Matsushita [EMAIL PROTECTED] wrote: is enabled, etc. Moreover, it seems that long standing random/slower/ faster clock-time bug is resolved! Wow! I want new one:-). Please note that this is about FreeBSD as VMware's *guest* OS, not as *host* OS. Anyone, do you try to support it like emulators/vmware[23]? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rtld + static linking
Marcel Moolenaar wrote: On Thu, Nov 27, 2003 at 03:41:14AM -0800, Terry Lambert wrote: If you can get gcc and binutils to add the necessary support, then we can talk further. Until then it's academic. I think there are political reasons for not doing this. The number one reason would be that you could load GPL'ed code as a module into a non-GPL'ed program, and then use it without neding to change your own license to GPL. The use of dlopen() does not circumvent that you're creating a modified version. The GPL-incompatible code and the GPL code do not communicate at arms length. Hence, the GPL-incompatible code is to be relicensed if the modified work is to be distributed. No. IF you separately distibute your code and the GPL'ed module code, AND you have an alternate user of the interface, THEN you can distribute the code at will without GPL'ing it, even if the intent is to link against the GPL'ed code at runtime. Be, Inc. did this with GPL'd Linux device drivers, and the one lawsuit the FSF began to bring on the basis of a GPL'ed library was resolved when the authors of the original code provided their own non-GPL'ed library, thus putting the GPL'ed code at arms length, legally, with regard to whether or not the combined code was a derivative work of the GPL'ed code. Like it or not, being able to dlopen a GPL'ed module means that you can circumvent the intent of the GPL. In fact, there are a number of PAM modules that are GPL'ed (go ahead and check). Alternatively, ask the license holder for an exception or see if the library can be relicensed under the LGPL. Why ask, when you can simply circumvent? The only thing it would buy you is the ability to not redistribute modularized source, which is of questionable benefit. From a GPL licensing point of view dlopen() is no different than static linking. Incorrect. The linking occurs at the behest of the person running the program, rather than at the behest of the person distributing the program,. As distributed, the program and the module together constitute a mere agregation, and therefore the program itself is not subject to the module's GPL nature. Well, it specifically mentions being able to do something like linking libc to libresolv, so that you implicitly get the resolver library when you explicitly link in the C library. That doesn't work with static linking of ELF binaries, so I think we can either say static linking is completely broken and needs to be fixed before it is allowed to be used, or static linking is undefined by the ELF standard. Recording dependencies in ELF files is specific to dynamic linking. No, it's specific to all relocatable ELF objects, at least according to the specification. In fact, there's nothing that you need to add to ELF headers or sections to make static linking work. It's irrelevant to an ELF specification. That's why it's not mentioned. Dynamic linking needs special headers and/or sections in the ELF file to make it work. I don't think you can infer from the ELF specification that static linking is undefined. I don't think that you can infer that it's defined. 8-). Anything that's not defined is, by definition, undefined. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fork speed vs /bin/sh
Peter Wemm wrote: What this shows is that vfork() is 3 times faster than fork() on static binaries, and 9 times faster on dynamic binaries. If people are worried about a 40% slowdown, then perhaps they'd like to investigate a speedup that works no matter whether its static or dynamic? There is a reason that popen(3) uses vfork(). /bin/sh should too, regardless of whether its dynamic or static. csh/tcsh already uses vfork() for the same reason. I'm a big fan of vfork(); the on problem I have with the use of it is that people tend to treat it as a faster fork(), when it definitely is not. The utility of vfork() is limited to the list of allowed system calls, which are _exit() and execve(); all other usage is undefined -- specifically, you cannot control things like whether it's the parent or the child that gets effected by calls like setsid(), setpgrp(), etc.. The other place that vfork() really sucks is in applications like screen or other applications that have multiple children and act as mux'es for them: during the vfork() to spawn off a new child from the parent, the parent is stalled, and this in turn stalls all the children, as well. The vfork() system call is a good thing, particularly compared to the fork() system call, IFF it's used appropriately. For the most part, FreeBSD should consider creating a posix_spawn() system call, instead, for most uses to which people put either the fork() or vfork() system calls today. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for 5.2-BETA lockup problems
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Andre Oppermann [EMAIL PROTECTED] writes: : Please try the attached patch which should fix it. I've been having crashes all the time since the hostcache went into the tree. I've been running a few hours with this patch (in which time I should have had a crash). I think it makes it better. Thank you for testing. I've sent the patch to re@ for approval. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR or panic with ips driver (was Re: cvs commit:src/sys/dev/ips ips.c ips.h ips_commands.c)
Hi, After seeing this commit message, I've upgraded -CURRENT installed on NetFinity 6000R(with ServeRAID 4H) to catch up with the recent changes. However, LOR or panic still persists. You can panic your -CURRENT machine by creating a log of files in a directory. You can do it with a simple shell script like this: $ mkdir foo; i=0; while :; do echo $i foo/$i; i=$(($i+1)); done Just tested this bug on our ServeRaid 5i, it doesn't happen here. The machines just runs out of inodes. Anyone else with a ServeRAID 4H can try this ? Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA + netatalk = crash
On Thursday 27 November 2003 06:35 pm, Leo Bicknell wrote: Since applying your patch I'd have IPv4 stop working 4 times. No panic, no console errors, just IPv4 traffic no longer does anything. Can't forward through the box. Can't ping the box, can't do anything. Logging in on console everything appears fine, and a reboot clears it up. I just reverted to the old kernel, we'll see if it happens again. The change I gave you should have nothing to do with IPv4. There is a change pending commit that appears to fix certain system lockups. I completed a make buildworld on a portable which NFS mounts /usr/src on the 5.2-BETA box which also runs netatalk, no obvious problems. Network hardware is a Compaq/Intel Pro100+ card using the fxp driver. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with ugen
Martin wrote:
Could you try the attached patch, to see if it fixes the panic on the second
run of your program?
No success. Still same panic.
Oops, my bad. I misread your backtrace, and fixed a similar bug in
ugen_set_interface rather than ugen_set_config.
Could you try the attached patch (rm -f sys/dev/usb/ugen.c, cvs up
sys/dev/usb/ugen.c, patch ...) to see if it alleviates the panic? It
should at least give a more specific panic, if it doesn't fix the problem.
--
Cheers,
Jay
http://www.imperial.ac.uk/ - 3rd year CS student
Index: sys/dev/usb/ugen.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.81
diff -u -3 -p -r1.81 ugen.c
--- sys/dev/usb/ugen.c 9 Nov 2003 09:17:22 - 1.81
+++ sys/dev/usb/ugen.c 28 Nov 2003 13:36:27 -
@@ -322,10 +322,6 @@ ugen_set_config(struct ugen_softc *sc, i
DPRINTFN(1,(ugen_set_config: %s to configno %d, sc=%p\n,
USBDEVNAME(sc-sc_dev), configno, sc));
-#if defined(__FreeBSD__)
- ugen_destroy_devnodes(sc);
-#endif
-
/* We start at 1, not 0, because we don't care whether the
* control endpoint is open or not. It is always present.
*/
@@ -347,15 +343,22 @@ ugen_set_config(struct ugen_softc *sc, i
err = usbd_interface_count(dev, niface);
if (err)
return (err);
+
+#if defined(__FreeBSD__)
+ ugen_destroy_devnodes(sc);
+#endif
+
memset(sc-sc_endpoints, 0, sizeof sc-sc_endpoints);
for (ifaceno = 0; ifaceno niface; ifaceno++) {
DPRINTFN(1,(ugen_set_config: ifaceno %d\n, ifaceno));
err = usbd_device2interface_handle(dev, ifaceno, iface);
- if (err)
- return (err);
+ if (err) {
+ panic(ugen_set_config: can't obtain interface handle);
+ }
err = usbd_endpoint_count(iface, nendpt);
- if (err)
- return (err);
+ if (err) {
+ panic(ugen_set_config: endpoint count failed);
+ }
for (endptno = 0; endptno nendpt; endptno++) {
ed = usbd_interface2endpoint_descriptor(iface,endptno);
endpt = ed-bEndpointAddress;
@@ -1014,8 +1017,8 @@ ugen_set_interface(struct ugen_softc *sc
usbd_interface_handle iface;
usb_endpoint_descriptor_t *ed;
usbd_status err;
- struct ugen_endpoint *sce;
- u_int8_t niface, nendpt, endptno, endpt;
+ struct ugen_endpoint *sce, **sce_cache;
+ u_int8_t niface, nendpt, nendpt_cache, endptno, endpt;
int dir;
DPRINTFN(15, (ugen_set_interface %d %d\n, ifaceidx, altno));
@@ -1033,30 +1036,46 @@ ugen_set_interface(struct ugen_softc *sc
if (err)
return (err);
-#if defined(__FreeBSD__)
- /* destroy the existing devices, we remake the new ones in a moment */
- ugen_destroy_devnodes(sc);
-#endif
+ /* store an array of endpoint descriptors to destroy if the interface
+* change succeeds - these aren't available afterwards */
+ sce_cache = malloc(sizeof(struct ugen_endpoint *) * nendpt, M_TEMP,
+ M_WAITOK);
+ nendpt_cache = nendpt;
- /* XXX should only do this after setting new altno has succeeded */
for (endptno = 0; endptno nendpt; endptno++) {
ed = usbd_interface2endpoint_descriptor(iface,endptno);
endpt = ed-bEndpointAddress;
dir = UE_GET_DIR(endpt) == UE_DIR_IN ? IN : OUT;
- sce = sc-sc_endpoints[UE_GET_ADDR(endpt)][dir];
- sce-sc = 0;
- sce-edesc = 0;
- sce-iface = 0;
+ sce_cache[endptno] = sc-sc_endpoints[UE_GET_ADDR(endpt)][dir];
}
/* change setting */
err = usbd_set_interface(iface, altno);
- if (err)
+ if (err) {
+ free(sce_cache, M_TEMP);
return (err);
+ }
err = usbd_endpoint_count(iface, nendpt);
- if (err)
- return (err);
+ if (err) {
+ panic(ugen_set_interface: endpoint count failed);
+ }
+
+#if defined(__FreeBSD__)
+ /* destroy the existing devices, we remake the new ones in a moment */
+ ugen_destroy_devnodes(sc);
+#endif
+
+ /* now we can clear the old interface's ugen_endpoints */
+ for (endptno = 0; endptno nendpt_cache; endptno++) {
+ sce = sce_cache[endptno];
+ sce-sc = 0;
+ sce-edesc = 0;
+ sce-iface = 0;
+ }
+ free(sce_cache, M_TEMP);
+
+ /* set the new interface's ugen_endpoints */
for (endptno = 0; endptno nendpt; endptno++) {
ed = usbd_interface2endpoint_descriptor(iface,endptno);
endpt = ed-bEndpointAddress;
Re: Hanging at boot
On Thursday 27 November 2003 06:04, Bruce Evans wrote: On Wed, 26 Nov 2003, Manfred Lotz wrote: On Mon, 24 Nov 2003 08:00:49 +0100, Manfred Lotz wrote: Hi there, Last time (around middle of October) when I tried out a new current kernel it was hanging at boot time at acd1 ata1 is: acd1: DVD-ROM TOSHIBA DVD-ROM SD-M1612 at ata1-slave UDMA33 I tried it again yesterday. Now acd1 seems to be fine. However it hangs at acd2.After the following message acd2: CD-RW MITSUMI DW-7801TE at ata3-master UDMA33 it stops working. No error message is showing up. In the meantime I found out that the cause of the problem is atapicam. If I remove it from my kernel config I'm fine (but I have no atapicam). Try backing out rev.1.23 of ata_lowlevel.c. Bruce I tried 1.22 of ata-lowlevel.c. Same problem as with 1.23. Manfred ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam broken by ata_lowlevel.c rev.1.23
At Thu, 27 Nov 2003 13:56:03 -0400, Bremner David wrote: /dev/pass0: flushing cache /dev/pass0: closing track - [unable to TEST UNIT READY]: Input/output error Following up to myself again; are we annoyed yet? Anyway, I remember reading about someone trying burncd fixate in a similar situation, so I did. It prints an error message, but seems to work. This is with a Plextor PX708A. convex# burncd -f /dev/acd0 fixate fixating CD, please wait.. burncd: ioctl(CDRIOCFIXATE): Input/output error To summarize, here is what I had to do to get writing DVD+R media working on FreeBSD 5.1-current (Nov 10), on a Plextor PX708A. (DVD+RW worked out of the box with burncd -f /dev/acd0 dvdrw data.iso fixate). 1) roll ata-lowlevel.c back to version 1.22 2) enable atapicam in the kernel 3) rebuild/reinstall kernel 4) install dvd+rw-tools from ports. 5) use growisofs -Z /dev/cd0=premastered.iso to burn the disk (no idea if premastered makes a difference). 6) use burncd -f /dev/acd0 fixate to close the session. 7) Ignore the error message from burncd. Hope this helps. db ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
On Fri, Nov 28, 2003 at 01:48:59AM -0700, M. Warner Losh wrote: : Oops, is it /that/ bad? I can't convince myself that it would have any chance of working. That's why I asked. Hm, doesn't sound very promising then. :) : Well, as I said above: I'm not using it so far, but given some time I may be : able to find out if it's still working. Please let me know if you succeed. I'll send you a message then. Although I really don't know when I should find time to play around with those things. I have working gpib PCI/PCMCIA cards under Linux and need to get some measurements done before I can think about making things more challanging (like changing over to FreeBSD or trying out some of the ancient 8bit cards :-). Anyway, do I need FreeBSD 4.x for the tests or is there any chance that 5.x will work with this driver, too? BTW: Are there more people around (except for you and me :-) who would like to see decent gpib-support in FreeBSD? I can remember that even the free gpib driver for Linux was unmaintained for some years until it became almost unusable (only for kernel 2.0.x then, with 2.4.x already out in the streets). Luckily some people have taken up the development some months ago, so there is a version working for 2.4.x now. Is there any chance to benefit from the Linux driver, or will a FreeBSD driver require to be rewritten from scratch? cu Gerrit -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Turkeys and dynamic linking
Michael Edenfield wrote: * Kent Stewart [EMAIL PROTECTED] [031127 17:50]: On Thursday 27 November 2003 12:31 pm, Bill Moran wrote: walt wrote: To all of you who celebrate Thanksgiving today, I wish you a happy one! And speaking of turkeys, does anyone know how Microsoft handles the performance issues associated with dynamic linking? Do they do anything special, or just ignore the whole thing? Don't they fix the performance hit by moving performance-critical parts of the application into kernel space (such as IIS and MSSQL)? At least, that's what Eric Raymond claims in his latest book. I don't think that's an approach I would like to see FreeBSD take. snip As far as moving things into the kernel, I'm not sure what ESR is referring to. It's easy to get code into kernel-space by making it a device driver, but AFAIK SQL Server code comes all from normal DLL libraries, all in user space. Looks like I overstated it a bit, from the book: While NT will use an MMU, NT versions after 3.5 have the system GUI wired into the same address space as the privileged kernel for performance reasons. Recent versions even wire the webserver into kernel space in an attempt to match the speed of Unix-based webservers. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA and related ports issues
Things are actually looking pretty good at this point; I'm probably going to move from 4.9-STABLE to 5.2-RELEASE on my main home server, but I'm seeing the following with 5.2-BETA at this point: I'm running 5.2-BETA cvsup'd at about 9 PM 11/25 on two systems; one is a Supermicro P6DGH, dual PIII/850, SCSI disks, Compaq/Intel Pro100+ NIC; the other is a Toshiba 8100 Tecra using the built-in 3Com 10/100 port in the docking station (xl driver). The P6DGH is running netatalk with the (apparently) as yet uncommitted patch to the netatalk kernel interface, which appears to be running fine. I am not seeing any IP lockups (just finished a buildword/buildkernel/ installkernel/installword cycle with the portable NFS mounting the P6DGH). The following appeared before 5.2-BETA but are continuing with that version. On the portable I'm getting the following lock order reversal: Nov 28 10:32:33 mikes-port kernel: lock order reversal Nov 28 10:32:33 mikes-port kernel: 1st 0xc340eb00 pcm0 (sound softc) @ /usr/src/sys/dev/sound/pci/ds1.c:734 Nov 28 10:32:33 mikes-port kernel: 2nd 0xc340e740 pcm0:play:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/channel.c:440 Nov 28 10:32:33 mikes-port kernel: Stack backtrace: The related parts of dmesg are as follows (an improvement from 5.1-CURRENT, where the AC97 driver didn't load): pcm0: Yamaha DS-1E (YMF744) port 0xbf3c-0xbf3f,0xbf40-0xbf7f mem 0xefdf8000-0x efdf irq 11 at device 12.0 on pci0 ds1: setmap (226000, 3de4), nseg=1, error=0 pcm0: Unknown AC97 Codec (id = 0x414b4d05) pcm0: Codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, AKM 3D Audio pcm0: Primary codec extended features variable rate PCM, AMAP pcm0: sndbuf_setmap 135db000, 1000; 0xc3407000 - 135db000 pcm0: sndbuf_setmap 13579000, 1000; 0xc3405000 - 13579000 pcm0: sndbuf_setmap 13134000, 1000; 0xc340 - 13134000 pcm0: sndbuf_setmap 134b2000, 1000; 0xc341e000 - 134b2000 pcm0: sndbuf_setmap 134d, 1000; 0xc341c000 - 134d pcm0: sndbuf_setmap 1348e000, 1000; 0xc341a000 - 1348e000 postgreSQL startup called twice On both systems I'm running postgreSQL7 from ports. In both cases the pgctl (the startup script) is called twice, and obviously it fails the second time. It is called both by /etc/rc.d/localdaemons and by /etc/rc.d/localpkg. I haven't looked any deeper than that, yet. On the portable the IP number, netmask, and router address are set in /etc/rc.conf. Both /etc/rc.d/netoptions and /etc/rc.d/network3 appear to be execuring (I see 'Additional TCP options: twice) and one of them is trying to reset the router address set by rc.conf, resulting in an error. The plus side is that a lot of the ACPI errors I used to get on the admittedly wierd P6DGH (11 PCI slots, onboard I2O, etc) have gone away. I'm not adding anything else at this point, since I don't know if these have been already reported (or fixed), but I can provide other info if necessary. Mike Squires UN*X at home since 1986 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
In message [EMAIL PROTECTED], Gerrit =?iso-8859-1?Q? K=FChn?= writes: BTW: Are there more people around (except for you and me :-) who would like to see decent gpib-support in FreeBSD? Yes, me. I'm currently running on a hacked up GPIB from userland I did myself, unfortunately it works well enough that I have never gotten around to push it into the kernel. http://phk.freebsd.dk/patch/GPIB.tgz On the other hand, GPIB is not going to be a major market for us, but merely a fringe convenience feature I suspect. -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Michael L. Squires [EMAIL PROTECTED] writes: On both systems I'm running postgreSQL7 from ports. In both cases the pgctl (the startup script) is called twice, and obviously it fails the second time. It is called both by /etc/rc.d/localdaemons and by /etc/rc.d/localpkg. I haven't looked any deeper than that, yet. On the portable the IP number, netmask, and router address are set in /etc/rc.conf. Both /etc/rc.d/netoptions and /etc/rc.d/network3 appear to be execuring (I see 'Additional TCP options: twice) and one of them is trying to reset the router address set by rc.conf, resulting in an error. There is an item in UPGRADING that explains this: 20030829: The following rc.d scripts have been removed and should be deleted from your installation: atm2.sh atm3.sh devdb localdaemons network1 network2 network3. Depending on when you last updated world and used mergemaster(8) you may or may not have problems during the rc boot sequence. The simplest solution is an 'rm -rf /etc/rc.d/*' and then 'mergemaster -i'. The atm2.sh atm3.sh and devdb scripts were removed some time ago, so depending on when you installed -CURRENT these scripts may or may not exist on your system. -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Fri, Nov 28, 2003 at 10:53:29AM -0500, Michael L. Squires wrote: On both systems I'm running postgreSQL7 from ports. In both cases the pgctl (the startup script) is called twice, and obviously it fails the second time. It is called both by /etc/rc.d/localdaemons and by /etc/rc.d/localpkg. [snip] Both /etc/rc.d/netoptions and /etc/rc.d/network3 appear to be execuring (I see 'Additional TCP options: twice) I can't comment on the other stuff, but both these problems are because of the `20030829' entry in /usr/src/UPDATING. ATB, james ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
On Fri, Nov 28, 2003 at 03:43:12PM +0100, Gerrit K?hn wrote: On Fri, Nov 28, 2003 at 01:48:59AM -0700, M. Warner Losh wrote: : Oops, is it /that/ bad? I can't convince myself that it would have any chance of working. That's why I asked. Hm, doesn't sound very promising then. :) John Galbraith wrote a driver for National Instruments' AT-GPIB/TNT and AT-GPIB cards a few years ago. It reportedly was much better than the driver in the tree. I don't know whatever happen to his code. : Well, as I said above: I'm not using it so far, but given some time I may be : able to find out if it's still working. Please let me know if you succeed. BTW: Are there more people around (except for you and me :-) who would like to see decent gpib-support in FreeBSD?i See the mailing list archives for people who have discussed the gpib driver in the past. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: cvs commit: src/sys/netinet tcp_hostcache.c]
This is the committed fix for the lockup problems a couple of you have experienced. If you don't have this fix already please re- cvsup and remake the kernel. -- Andre---BeginMessage--- andre 2003/11/28 08:33:03 PST FreeBSD src repository Modified files: sys/netinet tcp_hostcache.c Log: Fix an optimization where I made an ifdef'd out section to broad. When the hostcache bucket limit is reached the last bucket wasn't removed from the bucket row but inserted a few lines later at the bucket row head again. This leads to infinite loop when the same bucket row is accessed the next time for a lookup/insert or purge action. Tested by: imp, Matt Smith Approved by:re (rwatson) Revision ChangesPath 1.2 +4 -4 src/sys/netinet/tcp_hostcache.c ---End Message--- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Losing ld-elf.so.1 while make installworld, system shrotted
Hello, some days ago I tried to update my system. As usual I typed in make buildworld, went into single user mode and gave the command make installworld. This command never succeded, because of: install -o root -g wheel -m 444 test.1.gz /usr/share/man/man1 ELF interpreter /libexec/ld-elf.so.1 not found *** Signal 6 Stop in /usr/CURRENT/bin/test. *** Error code 1 Stop in /usr/CURRENT/bin. *** Error code 1 Stop in /usr/CURRENT. *** Error code 1 Stop in /usr/CURRENT. *** Error code 1 Stop in /usr/CURRENT. *** Error code 1 Stop in /usr/CURRENT. I found out, that all programms under /bin and /sbin are now dynamical linked. Actually no problem, but how can I update without having trouble? What did I miss? Regards, Oliver Fischer -- Dummheit is ooch 'ne Jabe Jottes, aber man muß se nich mißbrauchen. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Losing ld-elf.so.1 while make installworld, system shrotted
On Fri, Nov 28, 2003 at 05:50:21PM +0100, Oliver Fischer wrote: Hello, some days ago I tried to update my system. As usual I typed in make buildworld, went into single user mode and gave the command make installworld. Did you do make buildkernel, make installkernel , and mergemaster in the order specified in src/UPDATING. This command never succeded, because of: install -o root -g wheel -m 444 test.1.gz /usr/share/man/man1 ELF interpreter /libexec/ld-elf.so.1 not found *** Signal 6 I found out, that all programms under /bin and /sbin are now dynamical linked. Actually no problem, but how can I update without having trouble? What did I miss? mergemaster? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
Gerrit Kühn wrote: BTW: Are there more people around (except for you and me :-) who would like to see decent gpib-support in FreeBSD? Me! :-) I have a PCI gpib card lying around that I just haven't had time to play with. If there were a working driver, though, it would be very useful. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Losing ld-elf.so.1 while make installworld, system shrotted
On Fri, Nov 28, 2003 at 05:50:21PM +0100, Oliver Fischer wrote: install -o root -g wheel -m 444 test.1.gz /usr/share/man/man1 ELF interpreter /libexec/ld-elf.so.1 not found Was /libexec a symlink to /usr/libexec by any chance? I upgraded a system yesterday with /libexec as a symlink to /usr/libexec and the outcome was exactly what you are seeing. Reading through the Makefiles, the installworld procedure is 1. Install /libexec/ld-elf.so.1 2. Delete /usr/libexec/ld-elf.so.1 3. Link /libexec/ld-elf.so.1 to /usr/libexec/ld-elf.so.1 If you perform those steps with /libexec - /usr/libexec symlinks, the end result is no ld-elf.so.1 anywhere! Use the fixit CD, remove the /libexec symlink and make a directory /libexec. Then copy /usr/obj/usr/src/libexec/rtld-elf/ld-elf.so.1 into /libexec (making sure its modes are 555). You should then be able to reboot into single-user from the disk-based filesystems and redo `make installworld'. ATB, james ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Losing ld-elf.so.1 while make installworld, system shrotted
Steve Kargl wrote: Did you do make buildkernel, make installkernel , and mergemaster in the order specified in src/UPDATING. :0 Until now I have been doing it always in the wrong order... Thanks, now I will try it in the right order. Regards, Oliver Fischer -- Dummheit is ooch 'ne Jabe Jottes, aber man muß se nich mißbrauchen. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
Re John Galbraith's driver, I did a quick Google search and the latest version (dated 9/22/98) is available on Thomas Gellekum's FreeBSD page: http://people.freebsd.org/~tg/gpib.Sep22b.tar.gz (Galbraith's old site is dead.) Just FYI, so that others can avoid the inconvenience of doing the same search. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
On Fri, Nov 28, 2003 at 05:03:22PM +0100, Poul-Henning Kamp wrote: BTW: Are there more people around (except for you and me :-) who would like to see decent gpib-support in FreeBSD? Yes, me. I might have guessed it. Is there anything around FreeBSD you're not working with or on? ;-) I'm currently running on a hacked up GPIB from userland I did myself, unfortunately it works well enough that I have never gotten around to push it into the kernel. http://phk.freebsd.dk/patch/GPIB.tgz Perhaps I'll be able to have a look at it next week. Which gpib chipsets does it support (apart from NI, which seems to be some kind of standard)? On the other hand, GPIB is not going to be a major market for us, but merely a fringe convenience feature I suspect. Hm, FreeBSD is not supposed to do measurements and steering devices? When I was looking for an OS with gpib support apart from Windows some time ago, the only thing I could find was an old driver for Linux 2.0.x and the one for FreeBSD; even NetBSD didn't offer gpib support, though I supposed that it is more targeted to that kind of things. Now we have most of our high-level software for gpib written in Java, and it runs on Linux and Windows. For BSD I would just need the driver (and probably a new JNI). cu Gerrit -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
On Fri, Nov 28, 2003 at 09:17:54AM -0800, Frank Mayhar wrote: http://people.freebsd.org/~tg/gpib.Sep22b.tar.gz (Galbraith's old site is dead.) Just FYI, so that others can avoid the inconvenience of doing the same search. Thanks! cu Gerrit -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
In message [EMAIL PROTECTED], Gerrit =?iso-8859-1?Q? K=FChn?= writes: On Fri, Nov 28, 2003 at 05:03:22PM +0100, Poul-Henning Kamp wrote: BTW: Are there more people around (except for you and me :-) who would like to see decent gpib-support in FreeBSD? Yes, me. I might have guessed it. Is there anything around FreeBSD you're not working with or on? ;-) sound cards :-) I'm currently running on a hacked up GPIB from userland I did myself, unfortunately it works well enough that I have never gotten around to push it into the kernel. http://phk.freebsd.dk/patch/GPIB.tgz Perhaps I'll be able to have a look at it next week. Which gpib chipsets does it support (apart from NI, which seems to be some kind of standard)? The idea was to have the generic NI API and per-chip driver code. I only have the old PCIIA card with the NEC chip 7210 for which I have not been able to find a proper datasheet anywhere. On the other hand, GPIB is not going to be a major market for us, but merely a fringe convenience feature I suspect. Hm, FreeBSD is not supposed to do measurements and steering devices? Sure it is, but only if there is sufficient hacker momentum will it gain the ability and retain the ability. GPIB has been discussed about once per year for the last 5 year and we've gotten nowhere further for that... -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Losing ld-elf.so.1 while make installworld, system shrotted
On Fri, 28 Nov 2003, Oliver Fischer wrote: Steve Kargl wrote: Did you do make buildkernel, make installkernel , and mergemaster in the order specified in src/UPDATING. :0 Until now I have been doing it always in the wrong order... Thanks, now I will try it in the right order. Unfortunately, that step can be a little hazy: sometimes buildworld is required to run mergemaster, but occasionally you have to run mergemaster first to add new users that are required for installworld :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for 5.2-BETA lockup problems
In message: [EMAIL PROTECTED] Andre Oppermann [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Andre Oppermann [EMAIL PROTECTED] writes: : : Please try the attached patch which should fix it. : : I've been having crashes all the time since the hostcache went into : the tree. I've been running a few hours with this patch (in which : time I should have had a crash). I think it makes it better. : : Thank you for testing. I've sent the patch to re@ for approval. I was able to run overnight. First time since the hostcache code went in, so it definitely helps things! Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR and Panic in 5.2-BETA
On Fri, 28 Nov 2003, Ruben de Groot wrote: This is on a machine running 5.2-BETA, compiled with last night's sources ... Also, a repeatable panic when I run tcpdump on a gif interface. Without tcpdump, the tunnel is working as expected, but when tcpdump is listening on the gif0 interface and any traffic (e.g. a ping) is generated, I get the following panic : ... If there's any other info I should provide, please let me know. sounds like http://www.freebsd.org/cgi/query-pr.cgi?pr=59576 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
David O'Brien wrote: On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote: and [/usr/bin/ftp] doesn't support HTTP. $ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html Requesting http://www.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
OT [was: Re: HEADS UP: /bin and /sbin are now dynamically linked]
On Friday 28 November 2003 21:03, Tim Kientzle wrote: David O'Brien wrote: On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote: and [/usr/bin/ftp] doesn't support HTTP. $ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html Requesting http://www.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. Well that's bizarre IMHO. I never had guessed a tool called ftp would unterstand http! Just my 2¢ -Harry Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message [EMAIL PROTECTED], Tim Kientzle writes: David O'Brien wrote: On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote: and [/usr/bin/ftp] doesn't support HTTP. $ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html Requesting http://www.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. For consistency, we should link ftp(1) to http(1) I guess... -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ath0 lost connection!
Hi there. I have got running a PCI atheros wireless card on b/g in hostap mode and connecting 33 clients. for some razon all the customers lost the traffic, (the wireless cards has connection but dosen't send and recive any thing). When I login on the Freebsd hostap all looks happy but I can't ping any customer, so all start to work again if I restart the PC, I tried with a different harware and in differents modes 11b and 11g, but still same thing. I have installed the last driver versions, less the if_ath_pci.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ath/if_ath_pci.c I using the version 1.5 and I see the 1.6 this morning (someone know if update this fix the problem). thanks!! My setting is very simple: bridge option on the kernel. rc.conf # Network Card rl0 # ifconfig_rl0=inet 202.49.94.22 netmask 255.255.255.0 defaultrouter=202.49.94.254 # Wireless Card ath0 # ifconfig_ath0=inet up ssid default channel 6 media autoselect mode 11b mediaopt hostap dmsg: real memory = 369033216 (351 MB) avail memory = 348782592 (332 MB) Pentium Pro MTRR support enabled acpi0: AMIINT VIA_K7 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00f7e00 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 10 INTA is routed to irq 9 pcib0: slot 19 INTA is routed to irq 9 agp0: VIA Generic host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pci1: display, VGA at device 0.0 (no driver attached) ath0: Atheros 5212 mem 0xdfff-0xdfff irq 9 at device 10.0 on pci0 ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 802.11 address: 00:09:5b:94:63:e5 isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 8233A UDMA133 controller port 0xfc00-0xfc0f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] rl0: RealTek 8139 10/100BaseTX port 0xec00-0xecff mem 0xdffeff00-0xdffe irq 9 at device 19.0 on pci0 rl0: Ethernet address: 00:20:ed:2d:8b:a2 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A fdc0: cmd 3 failed at out byte 1 of 3 npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface orm0: Option ROM at iomem 0xc-0xcbfff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 fdc0: cannot reserve I/O port range (6 ports) ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 959452349 Hz quality 800 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% GEOM: create disk ad0 dp=0xc37c5660 ad0: 19130MB SAMSUNG SV0221H [38869/16/63] at ata0-master UDMA100 acd0: CDROM OEM CD-ROM F563E at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s1a ath0: promiscuous mode enabled rl0: promiscuous mode enabled -- Marcos Biscaysaqu Systems Administrator ThePacific.Net Ltd. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR and Panic in 5.2-BETA
On Fri, Nov 28, 2003 at 03:25:02PM +0100, Ruben de Groot wrote: This is on a machine running 5.2-BETA, compiled with last night's sources Both problems are known and have been reported a number of times..the second one should be fixed now. Kris pgp0.pgp Description: PGP signature
another 5.2-BETA lock order reversal
Checked the archive and didn't see this one listed yet: lock order reversal 1st 0xc4047134 filedesc structure (filedesc structure)[EMAIL PROTECTED]/usr/src/sys/kern/sys_ generic.c:896 2nd 0xc0956a80 Giant (Giant)[EMAIL PROTECTED]/usr/src/sys/fs/specfs/spec_vnops.c:377 Stack backtrace: backtrace(c089b89c,c0956a80,c0897b1f,c0897b1f,c0893352) at backtrace+0x17 witness_lock(c0956a80,8,c0893352,179,0) at witness_lock+0x672 _mtx_lock_flags(c0956a80,0,c0893352,179,c089bea3) at _mtx_lock_flags+0xba spec_poll(e476fafc,e476fb1c,c06d600c,e476fafc,c0937ca0) at spec_poll+0x134 spec_vnoperate(e476fafc,c0937ca0,c3c7e410,40,c435d680) at spec_vnoperate+0x18 vn_poll(c45992a8,40,c435d680,c43323c0,c435d680) at vn_poll+0x3c selscan(c43323c0,e476fb9c,e476fb8c,1,4) at selscan+0x141 kern_select(c43323c0,1,bfbfe890,0,bfbfe810) at kern_select+0x37f select(c43323c0,e476fd14,c08b631d,3ee,5) at select+0x66 syscall(2f,2f,2f,0,0) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (93), eip = 0x2845b94f, esp = 0xbfbfe7cc, ebp = 0xbfbfe928 --- -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: another 5.2-BETA lock order reversal
On Fri, Nov 28, 2003 at 04:37:49PM -0500, Jesse Guardiani wrote: Checked the archive and didn't see this one listed yet: lock order reversal ?1st?0xc4047134?filedesc?structure?(filedesc?structure)[EMAIL PROTECTED]/usr/src/sys/kern/sys_ generic.c:896 ?2nd?0xc0956a80?Giant?(Giant)[EMAIL PROTECTED]/usr/src/sys/fs/specfs/spec_vnops.c:377 Known problem, frequently reported. Thanks anyway, though. Kris pgp0.pgp Description: PGP signature
Re: Getting USB detach events enabled in time for 5.2-R?
On Wed, 26 Nov 2003, Johny Mattsson wrote: Hi all, I was wondering if there's any possibility in getting USB detach events working in time for the 5.2 release? The PR in question is kern/46488, and I submitted patches for this issue quite a while ago (Oct 24). Unfortunately jmg appears to be busy with other things as I have been unable to get in touch with him to discuss this one. FYI jmg has been out of the country of late. I bdbout he'll have any time to work on this in the near future. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
page fault panic -CURRENT
I'm getting a repeatable panic when try to access my cdrom drive. -CURRENT as
of yesterday. I seem to get this when I try to mount my cdrom drive a second
time.
I seem to get these error sometimes when trying to mount a cd for the first
time and it doesn't end up work, and the second time I get the panic.
acd0: FAILURE - READ_CD status=51READY,DSC,ERROR sensekey=MEDIUM ERROR
error=0
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04f8a59 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04f8e38 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0613fc6 in trap_fatal (frame=0xcdb1cc44, eva=0)
at /usr/src/sys/i386/i386/trap.c:821
#4 0xc0613c62 in trap_pfault (frame=0xcdb1cc44, usermode=0, eva=28)
at /usr/src/sys/i386/i386/trap.c:735
#5 0xc061379d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1031146752,
tf_
ebp = -843985768, tf_isp = -843985808, tf_ebx = -1031197888, tf_edx = 0,
tf_ecx
= -1066906236, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1068409245,
tf_
cs = 8, tf_eflags = 66055, tf_esp = -843985744, tf_ss = -1068781253})
at /usr/src/sys/i386/i386/trap.c:420
#6 0xc0604898 in calltrap () at {standard input}:94
#7 0xc04bfad8 in g_destroy_provider (pp=0xc2892b40)
at /usr/src/sys/geom/geom_subr.c:426
#8 0xc04bcaa5 in g_orphan_register (pp=0xc289f300)
at /usr/src/sys/geom/geom_event.c:143
#9 0xc04bcbcc in one_event () at /usr/src/sys/geom/geom_event.c:169
#10 0xc04bcdf5 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#11 0xc04bde05 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#12 0xc04e1700 in fork_exit (callout=0xc04bdde0 g_event_procbody, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.369.2.1 2002/12/18 08:11:24 scottl Exp $
machine i386
cpu I586_CPU
ident LITTLEGUY
maxusers0
#To statically compile in device wiring instead of /boot/device.hints
#hints GENERIC.hints #Default places to look for devices.
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options DDB, DDB_UNATTENDED
options INET#InterNETworking
#optionsINET6 #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options UFS_ACL #Support for access control lists
options UFS_DIRHASH #Improve performance on big directories
options MD_ROOT #MD is a potential root device
#optionsNFSCLIENT #Network Filesystem Client
#optionsNFSSERVER #Network Filesystem Server
#optionsNFS_ROOT#NFS usable as root device, requires NFSCLIENT
options MSDOSFS #MSDOS Filesystem
options NTFS# NT Filesystem
options CD9660 #ISO 9660 Filesystem
options PROCFS #Process filesystem (requires PSEUDOFS)
options PSEUDOFS#Pseudo-filesystem framework
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 #Compatible with FreeBSD4
#optionsSCSI_DELAY=15000#Delay (in ms) before probing SCSI
options KTRACE #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options AHC_REG_PRETTY_PRINT# Print register bitfields in debug
# output. Adds ~128k to driver.
options AHD_REG_PRETTY_PRINT# Print register bitfields in debug
# output. Adds ~215k to driver.
# Debugging for use in -current
#optionsDDB #Enable the kernel
Re: NSS and PAM, dynamic vs. static
Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. That is a bug in NSS, PAM or both. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT: buildworld fails
Kris Kennaway [EMAIL PROTECTED] writes: On Thu, Nov 27, 2003 at 01:02:18PM +0400, rihad wrote: CFLAGS= -O2 -pipe I'll try to build it without -O2, thanks. *sigh*, I see we need more figlet in the documentation. -O2 is bad, mmkay? \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA/x86: softupdates on / kills installation
This is from 5.2-BETA-20031127-JPSNAP.iso on a P4/800FSB/HT system: Note: this was manually transcribed because of the nature of the bug (installation failure), was unable to obtain a crash dump to be saved. It's completely reproducible on every installation attempt *IFF* softupdates is enabled for the / filesystem. If softupdates is not enabled for / at installation time, the installation succeeds normally. It crashes to DDB when it's about to extract files from base/base.ag: 9073664 bytes read from base dist, chunk 7 of 35 @ 1814.7 KBytes/sec. kernel: type 12 trap, code=0 Stopped at _mtx_assert+0x4e: movl0x1c(%ebx),%eax db trace _mtx_assert(0,1,c08afff0,63e,1000) at mtx_assert+0x4e vm_page_set_invalid(c22540d0,0,1000,554,0) at vm_page_set_invalid+0x35 brelse(d3505a60,0,e2242b90,c70a1a00,cbcf) at brelse+0x52b softdep_disk_io_initiation(d35056f0,c6cf,e2242bc4,246,c089e678) at softdesk_disk_io_initialization+0xc4 spec_xstrategy(c721e30c,d35056f0,d5b,c089e678,d35056f0) at spec_xstrategy+0x117 spec_specstrategy(e2242bf8,f4,c2278310,4,d35056f0) at spec_specstrategy+0x72 ufs_strategy(e2242c3c,e2242c6c,c06b718d,e2242c3c,1) at ufs_strategy+0x13c ufs_vnoperate(e2242c3c,1,c089e678,360,c0980340) at ufs_vnoperate+0x18 bwrite(d35056f0,0,c089e678,69b,880aa40) at bwrite+0x44d vfs_bio_awrite(d35056f0,0,c089e678,88e,c6cf) at vfs_bio_awrite+0x252 flushbufqueues(0,0,c089e678,819,64) at flushbufqueues+0x247 buf_daemon(0,e2242d48,c0896058,311,fcd2e824) at buf_daemon+0xdc fork_exit(c06b97c0,0,e2242d48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe2242d7c, ebp = 0 --- db So it's clearly a bug tickled by softupdates being enabled; eventually works its way to brelse() which then calls vm_page_set_invalid() and that fails due to some sort of mutex assertion. I don't know the VM system well enough to debug it further. I'd be happy to do any additional testing with a customized image or whatever -- I've got an external drive dedicated solely for fbsd overwrite install tests. I've run into this bug whenever I tried to install from 5.1-CURRENT for a few months now (didn't try before then) so it doesn't seem to be a new issue. I've also found at least two mentions of this bug seen by others in this mailing list in the past few months, but nothing in the bugs tracking db so guess I'll send-pr a report along, soon. Looks like it crashes and burns at installation time only if / has softupdates enabled; if either a single / fs has softupdates disabled OR if in a multiple filesystem setup, only / has softupdates disabled, then installation works fine. Perhaps a note in the installation document to have softupdates for / disabled for at least the installation as a current workaround would be warranted? (I imagine it should work ok post-installation to enable softupdates on / if desired, but haven't tested that scenario yet.) Hardware details of system in question provided upon request; didn't supply since this looks more like a software issue (since it's reproducible at will on various hard drives, both internal and external, on different controllers and busses... IDE, USB, and Firewire, as well as given the particular backtrace.) -Dan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot process is too slow during installation
Zhang Shu [EMAIL PROTECTED] writes: When I install netbsd with the same floppy drive, it turns to be pretty fast. So I guess this is a FreeBSD problem but do not know where it is... FreeBSD's boot code reads the disk sector by sector rather than track by track. Last time I brought this up I was told that it doesn't matter on modern drives... I wouldn't be surprised if track-by-track turns out to be 18 times faster than sector-by-sector with USB drives. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port of Niels Provos's file descriptor allocation code
At 1:32 AM +0100 2003/11/29, Dag-Erling Smørgrav wrote: What exactly would be the point? If this is the OpenBSD fdalloc code, recent widely-publicized benchmarks have shown it to be inferior to ours. Perhaps you should concentrate on improving vm_map_find() and vm_map_findspace() performance instead? Perhaps the implementation on OpenBSD may be worse than ours, but it may add features that help improve our performance further. Certainly, both issues should be checked as broadly as possible. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Losing ld-elf.so.1 while make installworld, system shrotted
Robert Watson [EMAIL PROTECTED] writes: Unfortunately, that step can be a little hazy: sometimes buildworld is required to run mergemaster, but occasionally you have to run mergemaster first to add new users that are required for installworld :-). It is not hazy at all: run 'mergemaster -p' before buildworld, and plain 'mergemaster' after installworld. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
anoncvs
is there still an ongoing problem with anoncvs? anoncvs.freebsd.org(209.181.243.20):2401 failed: Connection refused Matt Bell [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port of Niels Provos's file descriptor allocation code
On Sat, Nov 29, 2003 at 01:32:01AM +0100, Dag-Erling Sm?rgrav wrote: Tim Robbins [EMAIL PROTECTED] writes: I've ported Niels Provos's file descriptor allocation code to FreeBSD in case anyone wants to try it out run some benchmarks. If the performance boost turns out to be worth the added complexity, I might clean it up a bit and commit it. What exactly would be the point? If this is the OpenBSD fdalloc code, recent widely-publicized benchmarks have shown it to be inferior to ours. Perhaps you should concentrate on improving vm_map_find() and vm_map_findspace() performance instead? It's also the NetBSD fdalloc code. They started with code similar to ours, in that it did a linear search of the file descriptor array to find an empty slot and used hints to speed up some common allocation patterns, then recently switched over to using the multi-level bitmap allocator. I can't think of any reason why we wouldn't see improvements similar to what they saw: http://www.citi.umich.edu/u/provos/benchmark/netbsd-fdalloc.jpg ... but I'm still working on benchmarking FreeBSD with without the new allocator; I just posted the patch so that other people could experiment with it if they were interested. I don't plan on committing it until I have good evidence that it's an improvement over the current code. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
[Threading intentionally broken.] On Sat, Nov 29, 2003 at 01:16:25AM +0100, Dag-Erling Smørgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. That is a bug in NSS, PAM or both. Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) heh, Yes, that's a spell-o from which spell-check could not save me. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Jacques A. Vidrine [EMAIL PROTECTED] writes: Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. No, the two are essentially one. We just think they aren't because we've been brainwashed to think of users in terms of uids and gids and especially struct passwd, which deserves to die. NSS itself doesn't make much sense to me; it's an elaborate hack designed to drag all those nice shiny directory services down in the mud where struct passwd has been wallowing for the past twenty years, instead of allowing applications to take advantage of their superior functionality. As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port of Niels Provos's file descriptor allocation code
Tim Robbins [EMAIL PROTECTED] writes: It's also the NetBSD fdalloc code. They started with code similar to ours, in that it did a linear search of the file descriptor array to find an empty slot and used hints to speed up some common allocation patterns, then recently switched over to using the multi-level bitmap allocator. I can't think of any reason why we wouldn't see improvements similar to what they saw: http://www.citi.umich.edu/u/provos/benchmark/netbsd-fdalloc.jpg Having looked at the code, I believe that the graph is the result of an improperly designed benchmark. FreeBSD's performance *with a properly designed benchmark* should be similar to the red line (it's not as bad as it looks; the sharp rise caused by cache trashing occurs around 30k fds which is a pretty respectable number). The same benchmark would show a similar but less steep curve for the multi- level bitmap (which is just a fancy way of saying micro-optimized trie). A proper trie would result in a logarithmic curve. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
no /dev/dsp.x
I searched the list archive, but I didn't see anything specific to this question. Dell Latitude C600, running 5.2-BETA from 11/24/2003... I didn't notice until I started up KDE that I had no /dev/dsp of any kind in my /dev directory. I mount_nfs'd /usr/src and /usr/obj from my adjacent desktop Dell Optiplex (running same OS and build date), installed the kernel, installed world, mergemaster'd and rebooted. Still no /dev/dsp (or /dev/ dsp.x) on the Latitude laptop (they do exist on the Optiplex --which has working sound in KDE). The desktop with the working sound had KDE built from sources, the laptop's KDE environment was installed by building instant-workstation. The laptop has a sound_maestro3 card and I have the .ko loaded for it (and sound_pcm). Both machines have device pcm in the kernel. Appreciate any guidance. Tim Kellers CPE/NJIT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Fri, Nov 28, 2003 at 09:40:57PM -0500, T Kellers wrote: I searched the list archive, but I didn't see anything specific to this question. Dell Latitude C600, running 5.2-BETA from 11/24/2003... I didn't notice until I started up KDE that I had no /dev/dsp of any kind in my /dev directory. I mount_nfs'd /usr/src and /usr/obj from my adjacent desktop Dell Optiplex (running same OS and build date), installed the kernel, installed world, mergemaster'd and rebooted. Still no /dev/dsp (or /dev/ dsp.x) on the Latitude laptop (they do exist on the Optiplex --which has working sound in KDE). The desktop with the working sound had KDE built from sources, the laptop's KDE environment was installed by building instant-workstation. The laptop has a sound_maestro3 card and I have the .ko loaded for it (and sound_pcm). Both machines have device pcm in the kernel. ...and does the kernel detect the sound card? These device nodes are created by the driver when it configures detected devices. Kris pgp0.pgp Description: PGP signature
Re: no /dev/dsp.x
On Friday 28 November 2003 09:46 pm, Kris Kennaway wrote: On Fri, Nov 28, 2003 at 09:40:57PM -0500, T Kellers wrote: I searched the list archive, but I didn't see anything specific to this question. Dell Latitude C600, running 5.2-BETA from 11/24/2003... I didn't notice until I started up KDE that I had no /dev/dsp of any kind in my /dev directory. I mount_nfs'd /usr/src and /usr/obj from my adjacent desktop Dell Optiplex (running same OS and build date), installed the kernel, installed world, mergemaster'd and rebooted. Still no /dev/dsp (or /dev/ dsp.x) on the Latitude laptop (they do exist on the Optiplex --which has working sound in KDE). The desktop with the working sound had KDE built from sources, the laptop's KDE environment was installed by building instant-workstation. The laptop has a sound_maestro3 card and I have the .ko loaded for it (and sound_pcm). Both machines have device pcm in the kernel. ...and does the kernel detect the sound card? These device nodes are created by the driver when it configures detected devices. Kris I can't ssh to the laptop at this moment, but if the sound card is not detected by the kernel, can I force the detection by editing /boot/ loader.conf with: userconfig_script_load=YES snd_maestro3_load=YES ? I have that in loader.conf on an identical laptop running 4.9-STABLE, and on that laptop: dmesg -a | grep pcm Preloaded elf module snd_pcm.ko at 0xc0588140. pcm0: ESS Technology Maestro3 port 0xec00-0xecff mem 0xf8ffe000-0xf8ff irq 5 at device 3.0 on pci2 pcm0: SigmaTel STAC9721/23 AC97 Codec Preloaded elf module snd_pcm.ko at 0xc0588140. pcm0: ESS Technology Maestro3 port 0xec00-0xecff mem 0xf8ffe000-0xf8ff irq 5 at device 3.0 on pci2 pcm0: SigmaTel STAC9721/23 AC97 Codec I suppose on the 5.2-BETA laptop I should see something similar? Thanks, Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Fri, Nov 28, 2003 at 10:00:53PM -0500, T Kellers wrote: On Friday 28 November 2003 09:46 pm, Kris Kennaway wrote: On Fri, Nov 28, 2003 at 09:40:57PM -0500, T Kellers wrote: I searched the list archive, but I didn't see anything specific to this question. Dell Latitude C600, running 5.2-BETA from 11/24/2003... I didn't notice until I started up KDE that I had no /dev/dsp of any kind in my /dev directory. I mount_nfs'd /usr/src and /usr/obj from my adjacent desktop Dell Optiplex (running same OS and build date), installed the kernel, installed world, mergemaster'd and rebooted. Still no /dev/dsp (or /dev/ dsp.x) on the Latitude laptop (they do exist on the Optiplex --which has working sound in KDE). The desktop with the working sound had KDE built from sources, the laptop's KDE environment was installed by building instant-workstation. The laptop has a sound_maestro3 card and I have the .ko loaded for it (and sound_pcm). Both machines have device pcm in the kernel. ...and does the kernel detect the sound card? These device nodes are created by the driver when it configures detected devices. Kris I can't ssh to the laptop at this moment, but if the sound card is not detected by the kernel, can I force the detection by editing /boot/ loader.conf with: userconfig_script_load=YES snd_maestro3_load=YES ? You can't force the driver to detect your soundcard if the driver doesn't detect it :-) If you have a supported sound card and are loading the correct driver, then the device will be probed when you load the driver (at boot, after boot, whenever), and the device node will be created at that time if the probe is successful. I suppose on the 5.2-BETA laptop I should see something similar? You should, yes. Kris pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Fri, Nov 28, 2003 at 09:17:39PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Tim Kientzle writes: David O'Brien wrote: On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote: and [/usr/bin/ftp] doesn't support HTTP. $ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html Requesting http://www.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. For consistency, we should link ftp(1) to http(1) I guess... Good idea. I'll ask RE. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Friday 28 November 2003 10:19 pm, Kris Kennaway wrote: You can't force the driver to detect your soundcard if the driver doesn't detect it :-) If you have a supported sound card and are loading the correct driver, then the device will be probed when you load the driver (at boot, after boot, whenever), and the device node will be created at that time if the probe is successful. I suppose on the 5.2-BETA laptop I should see something similar? You should, yes. Kris Thanks, I'll check the dmesg on the laptop tomorrow and see what it contains. Is it likely that a soundcard recognized by 4.7 - 4.9 kernel wonouldn't be recognized by 5.2-Beta? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Fri, Nov 28, 2003 at 10:36:00PM -0500, T Kellers wrote: On Friday 28 November 2003 10:19 pm, Kris Kennaway wrote: You can't force the driver to detect your soundcard if the driver doesn't detect it :-) If you have a supported sound card and are loading the correct driver, then the device will be probed when you load the driver (at boot, after boot, whenever), and the device node will be created at that time if the probe is successful. I suppose on the 5.2-BETA laptop I should see something similar? You should, yes. Kris Thanks, I'll check the dmesg on the laptop tomorrow and see what it contains. Is it likely that a soundcard recognized by 4.7 - 4.9 kernel wonouldn't be recognized by 5.2-Beta? Once again, depends if it's configured correctly. kris pgp0.pgp Description: PGP signature
Re: 5.1-CURRENT: buildworld fails
On Sat, Nov 29, 2003 at 01:36:03AM +0100, Dag-Erling Sm?rgrav wrote: Kris Kennaway [EMAIL PROTECTED] writes: On Thu, Nov 27, 2003 at 01:02:18PM +0400, rihad wrote: CFLAGS= -O2 -pipe I'll try to build it without -O2, thanks. *sigh*, I see we need more figlet in the documentation. -O2 is bad, mmkay? It shouldn't be today. I'm convenced that all of our problems with 'gcc-3.3.3 -O2' are FreeBSD code bugs. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT: buildworld fails
Hot Diggety! David O'Brien was rumored to have written: It shouldn't be today. I'm convenced that all of our problems with 'gcc-3.3.3 -O2' are FreeBSD code bugs. I'm certainly deferring to someone with greater expertise, especially given a freebsd.org email address. :-) Just out of curiosity (and to mitigate my own personal ignorance), I'm curious how you determined them to be actual coding issues rather than compiler bugs? I've certainly seen both things in the past on other platforms, so I have an healthy amount of appreciation for both sides of the problem. -Dan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Fri, 28 Nov 2003, T Kellers wrote: I can't ssh to the laptop at this moment, but if the sound card is not detected by the kernel, can I force the detection by editing /boot/ loader.conf with: userconfig_script_load=YES snd_maestro3_load=YES ? I have that in loader.conf on an identical laptop running 4.9-STABLE, and on that laptop: dmesg -a | grep pcm Preloaded elf module snd_pcm.ko at 0xc0588140. pcm0: ESS Technology Maestro3 port 0xec00-0xecff mem 0xf8ffe000-0xf8ff irq 5 at device 3.0 on pci2 pcm0: SigmaTel STAC9721/23 AC97 Codec Preloaded elf module snd_pcm.ko at 0xc0588140. pcm0: ESS Technology Maestro3 port 0xec00-0xecff mem 0xf8ffe000-0xf8ff irq 5 at device 3.0 on pci2 pcm0: SigmaTel STAC9721/23 AC97 Codec I suppose on the 5.2-BETA laptop I should see something similar? I'm running 5.1-CURRENT from about a month ago on my notebook right now, and it sounds like I have almost identical hardware (Dell C600, etc). paprika:/boot dmesg | grep -i pcm Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0aa8280. pcm0: ESS Technology Maestro3 port 0xd800-0xd8ff mem 0xf3ffe000-0xf3ff irq 5 at device 8.0 on pci0 pcm0: SigmaTel STAC9721/23 AC97 Codec Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0aa8280. pcm0: ESS Technology Maestro3 port 0xd800-0xd8ff mem 0xf3ffe000-0xf3ff irq 5 at device 8.0 on pci0 pcm0: SigmaTel STAC9721/23 AC97 Codec I have the following in my loader.conf: paprika:/boot grep -i maes /boot/loader.conf snd_maestro3_load=YES I'm about to update to 5.2-BETA on the notebook; I'm running 5.1-CURRENT with some modifications to ACPI to make it like my configuration better (the old Dell notebook patch that's floating around). I don't believe that patch applies in the new world order, so once I update my notebook tomorrow, I'll see if I have the same problem. It looks like most of that patch has been applied to the vendor ACPI code, so I'm hopeful it won't :-). You might try disabling ACPI in device.hints and see if your sound device magically appears. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Friday 28 November 2003 11:27 pm, Robert Watson wrote: On Fri, 28 Nov 2003, T Kellers wrote: I can't ssh to the laptop at this moment, but if the sound card is not detected by the kernel, can I force the detection by editing /boot/ loader.conf with: userconfig_script_load=YES snd_maestro3_load=YES ? I have that in loader.conf on an identical laptop running 4.9-STABLE, and on that laptop: dmesg -a | grep pcm Preloaded elf module snd_pcm.ko at 0xc0588140. pcm0: ESS Technology Maestro3 port 0xec00-0xecff mem 0xf8ffe000-0xf8ff irq 5 at device 3.0 on pci2 pcm0: SigmaTel STAC9721/23 AC97 Codec Preloaded elf module snd_pcm.ko at 0xc0588140. pcm0: ESS Technology Maestro3 port 0xec00-0xecff mem 0xf8ffe000-0xf8ff irq 5 at device 3.0 on pci2 pcm0: SigmaTel STAC9721/23 AC97 Codec I suppose on the 5.2-BETA laptop I should see something similar? I'm running 5.1-CURRENT from about a month ago on my notebook right now, and it sounds like I have almost identical hardware (Dell C600, etc). paprika:/boot dmesg | grep -i pcm Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0aa8280. pcm0: ESS Technology Maestro3 port 0xd800-0xd8ff mem 0xf3ffe000-0xf3ff irq 5 at device 8.0 on pci0 pcm0: SigmaTel STAC9721/23 AC97 Codec Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0aa8280. pcm0: ESS Technology Maestro3 port 0xd800-0xd8ff mem 0xf3ffe000-0xf3ff irq 5 at device 8.0 on pci0 pcm0: SigmaTel STAC9721/23 AC97 Codec I have the following in my loader.conf: paprika:/boot grep -i maes /boot/loader.conf snd_maestro3_load=YES I'm about to update to 5.2-BETA on the notebook; I'm running 5.1-CURRENT with some modifications to ACPI to make it like my configuration better (the old Dell notebook patch that's floating around). I don't believe that patch applies in the new world order, so once I update my notebook tomorrow, I'll see if I have the same problem. It looks like most of that patch has been applied to the vendor ACPI code, so I'm hopeful it won't :-). You might try disabling ACPI in device.hints and see if your sound device magically appears. Thanks, I'll try disabling ACPI in device.hints, tomorrow. When I first upgraded from 5.1-RELEASE to 5.2-BETA on Monday, I had to disable ACPI on the FreeBSD text startup menu or the laptop wouldn't talk network with anything. Although an nmap from a remote machine said that ssh and ftp ports were open, I couldn't ftp or ssh to or from the machine with the default boot (number 1) selection. Another cvs update and buildkernel/ buildworld seems to have corrected the problem. Unfortunately, I didn't install the KDE stuff until after the 5.2-BETA upgrade, so I don't know if the /dev/dsp issue was there with 5.1-RELEASE. Please let me know if you encounter similar wierdness after you do the 5.2-BETA upgrade. Thanks Tim Kellers CPE/NJIT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port of Niels Provos's file descriptor allocation code
I've run some benchmarks of my own with and without the patch, and it's a definite improvement... I expected it to go linear for large number of open file descriptors, and it does, but the slope is much less steep than I expected, which explains why it looked like O(1). I have two objections to the patch, however: the first is the use of NDENTRYSHIFT to obfuscate multiplications and divisions by NDENTRIES (which is a constant, so the compiler will optimize it anyway). The second is the use of uint32_t instead of unsigned long which should be more efficient on 64-bit machines (NDENTRIES would have to be made dependent on sizeof(unsigned long)) and it scares me a bit that the Banga Mogul paper has been floating around for five years and nobody took any notice... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Dag-Erling Smørgrav wrote: NSS itself doesn't make much sense to me; it's an elaborate hack designed to drag all those nice shiny directory services down in the mud where struct passwd has been wallowing for the past twenty years, instead of allowing applications to take advantage of their superior functionality. As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. DES Replacing passwd/group/NSS/PAM/whatever with a real database or directory backend is a kind of holy grail for Unix that's been discussed for many years. I would love to see it happen. But I doubt it could ever happen within a collaborative project like FreeBSD, since it would be impossible to get enough people to agree upon the innumerable small details. I don't want to sound so pessimistic, but I think that's just a reality of group projects. I think this is part of the reason that many people are passionate about the dynamic library implementation of PAM/NSS. We realize that the odds are very high that the alternatives will be endlessly discussed, but never implemented. Since this is a feature that many of us really need, we prefer the less than perfect but existing implementation to the perfect, but never implemented solution. This discussion has really reminded me of the classic paper by Richard Gabriel on Lisp: Good News, Bad News, How to Win Big. This is one of the best essays on the Worse is Better phenomenon. http://www.ai.mit.edu/docs/articles/good-news/good-news.html http://www.dreamsongs.com/WorseIsBetter.html Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.2-BETA installation failed on VMware 4
I can remember that somebody already reports somewhere, but this bug(?) is still standing there, so here's again: I failed to install recent 5-current (5.2-BETA as of Nov/29/2003) to VMware Workstation 4.x (tested with 4.0.5 and 4.1 beta). I've observed that: * It seems that FreeBSD misunderstands that the computer is a SMP machine or something like that. * 'set kern.smp.disabled=1 to loader prompt' is not working as my expectation, it seems that SMP feature is still available. * After acd/ad devices are found by kernel, VMware panics. I've also reported this problem to VMware Inc. However, it seems that there's something troubles or bugs on FreeBSD. Anybody knows what's the problem, how to fix it, or any workarounds? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time jumping on both 4.x and 5.x ...
On Nov 28, Marc G. Fournier wrote: In trying to isolate an issue where the PostgreSQL 'explain analyze' is showing odd results (namely, negative time estimates on queries), Tom Lane wrote a quick C program to test gettimeofday() (program attached) ... the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows: neptune# time ./timetest out of order tv_sec: 1070068479 99040, prev 1070069174 725235 out of order tv_usec: 1070068479 99040, prev 1070069174 725235 out of order tv_sec: 1070069175 19687, prev 1070068479 99040 out of order tv_usec: 1070069175 19687, prev 1070068479 99040 out of order tv_sec: 1070068499 99377, prev 1070069194 625573 out of order tv_usec: 1070068499 99377, prev 1070069194 625573 out of order tv_sec: 1070069194 808542, prev 1070068499 99377 ^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w One person on the list has tried the same script on a 5.2 kernel, and reports seeing similar results, but after a longer period of time (~30min) ... In most (all?) cases, the offset appears to be ~+/-695 secs ... Linux ppl on the list, running the same problem, seem to be able to reproduce the issue, except they are only finding differences of 1 microsecond, and then only on older kernels (2.2.x, apparently) ... those running newer Linux kernels are reporting a clean run ... FreeBSD 5.2 (up, no acpia): I get the errors only when I force heavy load and swapping. - kern.timecounter.hardware: TSC - FreeBSD tube.xx.xx5.2-BETA FreeBSD 5.2-BETA #6: Fri Nov 28 14:20:25 EST 2003 [EMAIL PROTECTED] i386 FreeBSD 4.8 (up): Didn't see the error on a nominally loaded server, I tested for about ten minutes. - kern.timecounter.hardware: i8254 - FreeBSD yy.yy.yy.yy4.8-STABLE FreeBSD 4.8-STABLE #0: Wed Jul 30 13:51:04 EDT 2003 [EMAIL PROTECTED] i386 --Mat -- sig machine boken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Time jumping on both 4.x and 5.x ...
In trying to isolate an issue where the PostgreSQL 'explain analyze' is
showing odd results (namely, negative time estimates on queries), Tom
Lane wrote a quick C program to test gettimeofday() (program attached) ...
the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows:
neptune# time ./timetest
out of order tv_sec: 1070068479 99040, prev 1070069174 725235
out of order tv_usec: 1070068479 99040, prev 1070069174 725235
out of order tv_sec: 1070069175 19687, prev 1070068479 99040
out of order tv_usec: 1070069175 19687, prev 1070068479 99040
out of order tv_sec: 1070068499 99377, prev 1070069194 625573
out of order tv_usec: 1070068499 99377, prev 1070069194 625573
out of order tv_sec: 1070069194 808542, prev 1070068499 99377
^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w
One person on the list has tried the same script on a 5.2 kernel, and
reports seeing similar results, but after a longer period of time (~30min)
...
In most (all?) cases, the offset appears to be ~+/-695 secs ... Linux ppl
on the list, running the same problem, seem to be able to reproduce the
issue, except they are only finding differences of 1 microsecond, and then
only on older kernels (2.2.x, apparently) ... those running newer Linux
kernels are reporting a clean run ...
Known problem?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664#include stdio.h
#include sys/time.h
int
main()
{
struct timeval prevtime;
struct timeval curtime;
gettimeofday(prevtime, NULL);
for (;;)
{
gettimeofday(curtime, NULL);
if (curtime.tv_usec 0 || curtime.tv_usec = 100)
fprintf(stderr, bogus tv_usec: %ld %ld, prev %ld %ld\n,
(long int) curtime.tv_sec,
(long int) curtime.tv_usec,
(long int) prevtime.tv_sec,
(long int) prevtime.tv_usec);
if (curtime.tv_sec prevtime.tv_sec ||
curtime.tv_sec prevtime.tv_sec + 1)
fprintf(stderr, out of order tv_sec: %ld %ld, prev %ld %ld\n,
(long int) curtime.tv_sec,
(long int) curtime.tv_usec,
(long int) prevtime.tv_sec,
(long int) prevtime.tv_usec);
if (curtime.tv_usec prevtime.tv_usec
curtime.tv_sec != prevtime.tv_sec + 1)
fprintf(stderr, out of order tv_usec: %ld %ld, prev %ld
%ld\n,
(long int) curtime.tv_sec,
(long int) curtime.tv_usec,
(long int) prevtime.tv_sec,
(long int) prevtime.tv_usec);
prevtime = curtime;
}
return 0;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time jumping on both 4.x and 5.x ...
On Fri, Nov 28, 2003 at 09:32:30PM -0400, Marc G. Fournier wrote: In trying to isolate an issue where the PostgreSQL 'explain analyze' is showing odd results (namely, negative time estimates on queries), Tom Lane wrote a quick C program to test gettimeofday() (program attached) ... the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows: neptune# time ./timetest out of order tv_sec: 1070068479 99040, prev 1070069174 725235 out of order tv_usec: 1070068479 99040, prev 1070069174 725235 out of order tv_sec: 1070069175 19687, prev 1070068479 99040 out of order tv_usec: 1070069175 19687, prev 1070068479 99040 out of order tv_sec: 1070068499 99377, prev 1070069194 625573 out of order tv_usec: 1070068499 99377, prev 1070069194 625573 out of order tv_sec: 1070069194 808542, prev 1070068499 99377 ^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w One person on the list has tried the same script on a 5.2 kernel, and reports seeing similar results, but after a longer period of time (~30min) ... What hardware, kernel configuration, etc? Do you have a misconfigured ntpd/timed that is manually flapping the time around? I've run that test for a few minutes on 4.9 without problems. Kris pgp0.pgp Description: PGP signature
Re: Time jumping on both 4.x and 5.x ...
On Fri, 28 Nov 2003, Kris Kennaway wrote: On Fri, Nov 28, 2003 at 09:32:30PM -0400, Marc G. Fournier wrote: In trying to isolate an issue where the PostgreSQL 'explain analyze' is showing odd results (namely, negative time estimates on queries), Tom Lane wrote a quick C program to test gettimeofday() (program attached) ... the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows: neptune# time ./timetest out of order tv_sec: 1070068479 99040, prev 1070069174 725235 out of order tv_usec: 1070068479 99040, prev 1070069174 725235 out of order tv_sec: 1070069175 19687, prev 1070068479 99040 out of order tv_usec: 1070069175 19687, prev 1070068479 99040 out of order tv_sec: 1070068499 99377, prev 1070069194 625573 out of order tv_usec: 1070068499 99377, prev 1070069194 625573 out of order tv_sec: 1070069194 808542, prev 1070068499 99377 ^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w One person on the list has tried the same script on a 5.2 kernel, and reports seeing similar results, but after a longer period of time (~30min) ... What hardware, kernel configuration, etc? Do you have a misconfigured ntpd/timed that is manually flapping the time around? Hardware for the above is a Dual-Xeon, 4Gig of RAM, and about 421 processes running on it currently ... kernel config is at the bottom, but I don't think there is anything 'abnormal' about it ... and note that I've had others be able to reproduce the problem on both 4.x and 5.x systems ... as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 and 23:59), but that is it as far as playing with the clock is concerned ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 machine i386 cpu I686_CPU ident kernel maxusers0 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options NMBCLUSTERS=16384 options VM_KMEM_SIZE=(400*1024*1024) options VM_KMEM_SIZE_MAX=(400*1024*1024) options NULLFS #NULL filesystem options UNION #Union filesystem options NFS #Network File System options COMPAT_LINUX options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM options SHMMAXPGS=199608 options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) options SYSVSEM options SEMMNI=4096 options SEMMNS=8192 options SYSVMSG #SYSV-style message queues options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options KBD_INSTALL_CDEV# install a CDEV entry in /dev options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O device isa device pci device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. device scbus # SCSI bus (required) device da # Direct Access (disks) device pass# Passthrough device (direct SCSI access) device ses device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0at atkbdc? irq 12 device vga0at isa? pseudo-device splash device sc0 at isa? flags 0x100 device npx0at nexus? port IO_NPX irq 13 device em # Intel PRO/1000 adapter Gigabit Ethernet Card ( ``Wiseman'') pseudo-device loop# Network loopback pseudo-device ether # Ethernet support pseudo-device pty 256 # Pseudo-ttys (telnet etc) pseudo-device bpf #Berkeley packet filter options DDB options DDB_UNATTENDED options INCLUDE_CONFIG_FILE # Include this file in kernel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL
Re: Time jumping on both 4.x and 5.x ...
Hello. On Sat, Nov 29, 2003 at 12:36:22AM -0400, Marc G. Fournier wrote: What hardware, kernel configuration, etc? Do you have a misconfigured ntpd/timed that is manually flapping the time around? Hardware for the above is a Dual-Xeon, 4Gig of RAM, and about 421 processes running on it currently ... kernel config is at the bottom, but I don't think there is anything 'abnormal' about it ... and note that I've had others be able to reproduce the problem on both 4.x and 5.x systems ... as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 and 23:59), but that is it as far as playing with the clock is concerned ... What does `sysctl kern.timecounter' show? Also, does changing kern.timecounter.hardware (TSC, i8254, ACPI-safe, ...) affect the results from your test program? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time jumping on both 4.x and 5.x ...
Marc G. Fournier [EMAIL PROTECTED] writes: as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 and 23:59) Don't Do That. It will lead to all kinds of trouble that will take you ages to figure out. Really, ntpd is so ridiculously easy to set up (especially if you already have ntpdate working) that there is no reason not to use it. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time jumping on both 4.x and 5.x ...
On Sat, Nov 29, 2003 at 12:36:22AM -0400, Marc G. Fournier wrote: Hardware for the above is a Dual-Xeon, 4Gig of RAM, and about 421 processes running on it currently ... kernel config is at the bottom, but I don't think there is anything 'abnormal' about it ... and note that I've had others be able to reproduce the problem on both 4.x and 5.x systems ... dmesg output? You need to be VERY specific when reporting bugs that not everyone can reproduce. Kris pgp0.pgp Description: PGP signature
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 05:57, Dag-Erling Smørgrav wrote: Marc G. Fournier [EMAIL PROTECTED] writes: as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 and 23:59) Don't Do That. It will lead to all kinds of trouble that will take you ages to figure out. Really, ntpd is so ridiculously easy to set up (especially if you already have ntpdate working) that there is no reason not to use it. FWIW, it can reproduce this on two machines (one 4.9-RELEASE, one 5.1-RELEASE) which both run ntpd. Takes some 10 minutes on both before the first steps backwards turn up. Unfortunately, both machines aren't very good datapoints because both have pretty customized kernels and have -Os and -march optimized worlds/kernels... Both have kern.timecounter.hardware: ACPI-fast, too. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
