Re: question about shared libraries and the library cache.
Peter Pentchev wrote: The original posting did not mention a reboot, but rather a manual ldconfig(8) invocation immediately after installing the libraries. In this case, your advice about ldconfig -m was correct, as I noted in the part of my message that you snipped; but there are other directories to be considered besides /usr/local/lib. FWIW: IMO, the value of the path list was probably corrupt, since the ldconfig -R he said he ran failed to find it, or the other shared libraries in /usr/local/lib. In other words, he munged something and broke it, some time ago, and was only now feeling the pain. One of the problems with upgrading from an older version of FreeBSD to a newer version is that the process fails to deal with transporting the current configuration to the new version of the OS, for a lot of corner cases. The reason I said what I said, and said it the way that I did, was to give something that would work, no matter how screwed up the situation was. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: documentation on kernel locks, mutexes?
On Sat, Nov 30, 2002 at 10:27:27PM -0800, Terry Lambert wrote: Robert Watson wrote: On Mon, 25 Nov 2002, Terry Lambert wrote: Yury Tarasievich wrote: I need to port some driver from linux to freebsd and, somehow, I can't find documentation on kernel locks and mutexes. There are no man pages, links from handbook are broken, and search on freebsd site gives nothing (besides the handbook itself). [...] I was thinking more in terms of device driver information. All of the how to write a driver for newbus, how to write a CAM driver, how to use devfs from the kernel, what XXX to do in FreeBSD, given YYY in Linux, how to port a driver from Linux to FreeBSD, etc., are missing. Well, perhaps not THAT generic information... :) While it's true that kernel locks and mutexes are documented for SMPng, he posted to -hackers, not -current, and so he's probably not interested in -current primitives that aren't available in the 4.x -RELEASE and -STABLE branches. Exactly my point, thanks! And I'll point again that: - links in handbook DO NOT work (freebsd.org does not have these pages (specifically lockmgr(9), mutex(9)) - and there are no man pages for them in distribution I've even checked this with 4.4-RELEASE at hand -- seen same. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: documentation on kernel locks, mutexes?
Yury Tarasievich wrote: While it's true that kernel locks and mutexes are documented for SMPng, he posted to -hackers, not -current, and so he's probably not interested in -current primitives that aren't available in the 4.x -RELEASE and -STABLE branches. Exactly my point, thanks! And I'll point again that: - links in handbook DO NOT work (freebsd.org does not have these pages (specifically lockmgr(9), mutex(9)) The handbook is old, and non-authoritative, and non-version-linked. It's a good place to get started, but a poor place to find this kind of specific information (e.g. the section on changing KVA space size is incomplete for the version it applies to, and only applies to some versions of FreeBSD, not others, so the information is not generally useful). - and there are no man pages for them in distribution I've even checked this with 4.4-RELEASE at hand -- seen same. The easiest place to look for this is on a FreeBSD -current (5.x) system manual pages, as they currently exist. If you don't have a 5.x system (most commercial shops I know of do not maintain one, since they never ship product except on -RELEASE systems), then you can access manual pages online. Since the lockmgr() interface is (practically) deprecated at this point, it hasn't changed much, and is unlikely to change much. So you can use the 5.x documentation; here is the one for lockmgr(9): http://www.FreeBSD.org/cgi/man.cgi?query=lockmgrapropos=0sektion=9manpath=FreeBSD+5.0-currentformat=html Note that the 4.x version of this code takes a struct proc * as a sleep context, not a struct thread *. In any case, you probably don't want to be using this in 4.x code at all in a driver, since drivers operate at interrupt; it's only useful in the top end, to protect against reentrancy, and to provide a sleep context. For your purposes, you are more likely to not have to worry about it at all, considering that you can't enter the kernel in 4.x without hilding giant. If the reason you are needing this is for a rendevous (what would normally be implemented in other SMP OS's as a condition variable), so you can sleep on work being done, then you *may* want to use lockmgr -- if you *NEVER* call it at interrupt. Otherwise, you probably want to use tsleep() and wakeup(), so long as tsleep() is never called at interrupt. Basically, you can not suspend an interrupt processing routine, for any reason. As I said before, it's generally a good idea to pick a similar driver, and use it as a template, rather than trying to program from documentation (which doesn't have a high enough density at this point to make it a useful pursuit). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
/usr/bin/finger problems...
Whom it concerns, I just upgraded a myriad of my systems from 4.6R-p2 to 4.7 and lo-and-behold I could no longer use /usr/bin/finger to get a finger from remote Ascend NAS. Funnily enough, it still worked on remote Cisco and unix boxen. Still - i got shitty with it, and dug into the problem. In 4.6R there was no INET6 support - 4.7 onwards now has it and someone just very simply screwed up typing in the new code, as you'll plainly see. Old Code snippet from net.c iov[msg.msg_iovlen].iov_base = \r\n; New code snippet from net.c static char neteol[] = \n\r; . . . iov[msg.msg_iovlen].iov_base = neteol; Well, it's pretty obvious what the problem now isnt it? :) And, of course - changing it to the old behavior of \r\n does fix it and my problems are no more. I can submit a patch to fix this if you want or not.. I honestly dont give a damn to be honest ;) Regards, Jenna PLEASE NOTE: I'm not on the freebsd-questions list. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[CFR] diskpart(1) buffer overflow fix
Hi, As noted on the vuln-dev list recently, the diskpart(1) program in -stable is susceptible to a buffer overflow in the parsing of command-line arguments. This is a low-risk problem, since diskpart(1) is not - and has never been, and has no reason to ever be - a privileged program, but still, there should be no harm in fixing it :) Attached are two patches: a trivial one which just fixes up two problems in diskpart's argument parsing, and a more complex one, which does it the right way IMHO, using getopt(3). Comments? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI msg38425/pgp0.pgp Description: PGP signature
Re: USB support for new HP printers?
On Sun, Aug 25, 2002 at 11:36:15PM -0600, John Nielsen wrote: Are there plans to add USB support for HP's newer printers to FreeBSD? Specificially, the OfficeJets and the LaserJet 1200? They use a new/different/broken USB interface so they're just recognized as ugen devices at the moment.. Can you tell details about the difference? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: /usr/bin/finger problems...
On Mon, Dec 02, 2002 at 10:01:22PM +1100, J R Matthews wrote: I can submit a patch to fix this if you want or not.. I honestly dont give a damn to be honest ;) Submitting a PR containing a patch is the best way to get this fixed. Thanks! Kris msg38430/pgp0.pgp Description: PGP signature
fh
Thanks, Tim Kientzle, but i still need one c code to add to
autoconf.c, and gets a NFS file handle to my root directory. We have
the solution (diskless) with dhcp/bootp... but we do not want this
anymore, due the things that i have sad before. Thanks.
All that i need, is that c code... :)
In vfs_syscalls.c i have found this code:
---
/*
* Get (NFS) file handle
*/
#ifndef _SYS_SYSPROTO_H_
struct getfh_args {
char*fname;
fhandle_t *fhp;
};
#endif
int
getfh(p, uap)
struct proc *p;
register struct getfh_args *uap;
{
struct nameidata nd;
fhandle_t fh;
register struct vnode *vp;
int error;
/*
* Must be super user
*/
error = suser(p);
if (error)
return (error);
NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE, uap-fname,
p);
error = namei(nd);
if (error)
return (error);
NDFREE(nd, NDF_ONLY_PNBUF);
vp = nd.ni_vp;
bzero(fh, sizeof(fh));
fh.fh_fsid = vp-v_mount-mnt_stat.f_fsid;
error = VFS_VPTOFH(vp, fh.fh_fid);
vput(vp);
if (error)
return (error);
error = copyout(fh, uap-fhp, sizeof (fh));
return (error);
}
---
Can i adapt it for my porpouses?
I need help, and i guess that here is the place... :)
Somebody can help?
[EMAIL PROTECTED]
SDF Public Access UNIX System - http://sdf.lonestar.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
[nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
Hi,
Summary: this is going to be a rather long email about the timing of various
_sleep functions, compared to the same on Linux.
I ran across this at the xmame mailing list, and I have seen some
interesting results.
First the original mail which Steve sent, which will explain the question:
- Forwarded message from Steve Freeland [EMAIL PROTECTED] -
From: Steve Freeland [EMAIL PROTECTED]
Date: Sun, 1 Dec 2002 23:17:18 -0500
Subject: [Xmame] Use of usleep() with -sleepidle
So in the course of testing the next release of NetMAME (Real Soon
Now!) I had a look at how -sleepidle was implemented. Turns out it works
by calling usleep() in 0.1 ms increments.
The thing is, usleep() has a (relatively) huge overhead. I did
some testing (see below) and it turns out that you can't really usleep()
for less than 20 ms, for all practical purposes, at least on my system
(i386 Linux 2.4). I assumed the difference was due to usleep() being
based on using SIGALM, but nanosleep(), which supposedly isn't,
seems to have exactly the same precision (or lack thereof), so who knows.
Anyways, one possible alternative is using select() instead (with
no fd sets, just a timeout value), which seems to have a lower overhead --
about 10 ms, which is still large but at least is less than the duration
of one emulated frame.
I don't know how much this would benefit other platforms --
I tried on an OpenBSD machine (some sort of i386, don't have details
about the hardware) and the minimum overhead is about the same (20 ms) for
both calls. I've attached the program I used to test this in case anyone
wants to try it out on their systems (I'd be especially curious to see
what the results are for people which some sort of low-latency kernel.)
So: anyone see a reason why the usleep() calls shouldn't be
replaced by select()s, for benefits where they may be found?
- End forwarded message -
Steve attached the program I also attach. Of course I was interested in
running times on FreeBSD so I ran it on my fairly -STABLE box, an
Athlon XP1700+ (I'm assuming CPU speed is the only relevant attribute
here, please correct me if I'm wrong). The result is attached, as
'sleep-bsd-1700.log'. Others on the list did the same, using their
various Linux boxes, and this is where it got interesting. Their logs
are attached as well, as sleep-lnx-*.log based on CPU speed [1].
One had an Athlon 1400XP, and got the following for the select speeds:
%%%
Testing _select_sleep (x 1000), delay 8
Total time: .906000 ms; unit time: 9.06 ms; estimated overhead: 1.06 ms
%%%
Someone else had an Athlon Thunderbird 1.2Ghz, and got the following:
%%%
Testing _select_sleep (x 1000), delay 8
Total time: 8276.96 ms; unit time: 8.276960 ms; estimated overhead: 0.276960 ms
%%%
(admittedly that person had applied some kernel patches).
Compared to my 1700XP, that's a factor 6 slower than the slowest Linux case
on a lesser processor:
%%%
Testing _select_sleep (x 1000), delay 8
Total time: 2.027000 ms; unit time: 20.27 ms; estimated overhead: 12.27 ms
%%%
What's going on here? Is our select really that much slower, or is the program
measuring the wrong values, or doesn't this speed make a difference in
'real-world' applications, or what?
--Stijn
[1] Yes I know an Athlon 1400XP isn't 1400 MHz but that's not really relevant
here. I'm doing a comparison, not a real numbercrunching benchmark.
--
SIGSIG -- signature too long (core dumped)
#include sys/time.h
#include unistd.h
#include stdio.h
static int
_tv_subtract(struct timeval *tv1, struct timeval *tv2)
{
int result;
result = (tv1-tv_sec - tv2-tv_sec) * 100;
result += (tv1-tv_usec - tv2-tv_usec);
return result;
}
void
_select_sleep(unsigned usec)
{
struct timeval delay = { usec / (1000 * 1000), usec % (1000 * 1000) };
select(0, NULL, NULL, NULL, delay);
}
void
_usleep_sleep(unsigned usec)
{
usleep(usec);
}
void
_nanosleep_sleep(unsigned usec)
{
struct timespec delay = { (usec * 1000) / (1000 * 1000 * 1000),
(usec * 1000) % (1000 * 1000 * 1000) };
nanosleep(delay, NULL);
}
typedef void (*sleep_fn_t)(unsigned);
#define TEST_COUNT 1000
void
main()
{
unsigned i, j, k;
unsigned delays[] = { 3, 8, 13, 18, 23, 28 }; /* milliseconds */
sleep_fn_t sleep_fn[] = { _select_sleep,
_usleep_sleep,
_nanosleep_sleep };
const char *sleep_fn_name[] = { _select_sleep,
_usleep_sleep,
_nanosleep_sleep };
struct timeval start_time, end_time;
for (i = 0; i sizeof(delays) / sizeof(delays[0]); i++) {
for (j = 0; j sizeof(sleep_fn) / sizeof(sleep_fn[0]); j++) {
double total_ms;
printf(Testing %s (x %d), delay %d\n,
sleep_fn_name[j],
TEST_COUNT,
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Mon, 2 Dec 2002, Stijn Hoop wrote: Hi, Summary: this is going to be a rather long email about the timing of various _sleep functions, compared to the same on Linux. I ran across this at the xmame mailing list, and I have seen some interesting results. One had an Athlon 1400XP, and got the following for the select speeds: %%% Testing _select_sleep (x 1000), delay 8 Total time: .906000 ms; unit time: 9.06 ms; estimated overhead: 1.06 ms %%% What's going on here? Is our select really that much slower, or is the program measuring the wrong values, or doesn't this speed make a difference in 'real-world' applications, or what? --Stijn The time select() takes should be directly related to your system's hz setting. The default for FreeBSD is 100, which means that the interrupt timer will fire every 10ms. If you want to play with that, edit /etc/sysctl.conf and set kern.hz=1000, which should give you 1 ms accuracy. As to why Linux may appear better... I believe that Linux defaults to hz=100, but that the default switched to hz=1000 sometime in the recent past. To answer your final question: Sleep accuracy doesn't matter to most applications, but I'm sure counterexamples could be found. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
Le Monday 02 December 2002 18:49, Mike Silbersack a écrit : [SNIP] The time select() takes should be directly related to your system's hz setting. The default for FreeBSD is 100, which means that the interrupt timer will fire every 10ms. If you want to play with that, edit /etc/sysctl.conf and set kern.hz=1000, which should give you 1 ms accuracy. the line : kern.hz=1000 must be placed in /boot/loader.conf TfH [SNIP] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB support for new HP printers?
On Monday 02 December 2002 05:13, Bernd Walter wrote: On Sun, Aug 25, 2002 at 11:36:15PM -0600, John Nielsen wrote: Are there plans to add USB support for HP's newer printers to FreeBSD? Specificially, the OfficeJets and the LaserJet 1200? They use a new/different/broken USB interface so they're just recognized as ugen devices at the moment.. Can you tell details about the difference? Not really. Pretty much everything I know I learned from corresponding with David Paschal on the hpoj-devel mailing list (see hpoj.sourceforge.net). If Geocrawler ever comes back up today you can browse the list. See the thread FreeBSD howto? starting August 26 2002. Here is a quote from Mr. Paschal in one of those e-mails: Hi, John. The LaserJet 1200 advertises several alternate settings for the printer-class interface: 7/1/3 (for IEEE 1284.4 packets, the new and different USB interface you mentioned), 7/1/2 (bidirectional raw print data), and 7/1/1 (unidirectional raw print data). If you can somehow convince the ulpt driver to bind to 7/1/2 or 7/1/1 rather than just blindly binding to the first alternate setting it finds, then that should be all you need. The above quote is in reference to getting printing (and only printing) to work on an LJ 1200. For full functionality, you'd need to do a bit more. I think the hpoj project was leaning towards a cross-platform userland solution (hack?) rather than doing kernel mods on several different platforms. JN To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
usleep will sleep until the next tick if you give is a value 1 tick. The default HZ setting on FreeBSD is 100, giving you a tick of 10ms. I'm not sure why you are seeing it sleep for 2 ticks instead of one, however. Try building a kernel with an HZ of 1000 and see what happens. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs -rbranch:date + val-tags
I am still looking into the -j flag and (r)tag. This patch was done quickly, and I am still trying to see what it breaks. I realized some of the issues I had were also broken with an unpatched cvs. So I might have broken something that is already broken. I am looking through diff -rv1_11_2 -rHEAD in the FreeBSD repository and diff -rCVS1_11_2 -rHEAD in the NetBSD repository and comparing that with -rHEAD cvs/ccvs from the cvshome repository. I don't know what the CVS people think of my patch, but I based it off a patch on their website that they have had for over 4 years. http://www.cvshome.org/cyclic/cvs/dev-branch.html I would really appreciate it if anyone would give me feedback on what they feel is broken about cvs. --- Archie Cobbs [EMAIL PROTECTED] wrote: David Yeske wrote: I am working on getting cvs more usable so I don't have to worry about val-tags when I have read only media, and so I can do stuff like this. cvs update -rRELENG_4:2002/10/01 cvs diff -rRELENG_4:2002/09/01 -rRELENG_4:2002/09/30 I would appreciate any testing or feedback. I have tested this some, but it probably has bugs. Awesome! I've wanted to be able to do tags like '-rRELENG_4:2002/09/01' for years.. Haven't tested your changes but the patch looks reasonable to me. ISTR that the '-j' option allows some combinations of branch + date. Are you aware of that? Does anything need to be rectified between the '-j' stuff and your changes? Also, what do the CVS people think of your patch? Cheers, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [CFR] diskpart(1) buffer overflow fix
Le 2002-12-02, Peter Pentchev écrivait : Ahhh; of course this would be better. Updated patch attached. Looks fine. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: jail
Just for the record, I've had this problem without using vnode backing files. It's exactly the same in all other areas. The machine would lock up at a specific time each week during 'find' in one of the periodic scripts. This occurred when the host and approximately 15 jails executed that command at the same time. Removing the periodic script from the host system solved the problem. This has occurred on a number of machines, and apparently has nothing to do with vn's although that may agravate the problem. Nate Nielsen Terry Lambert [EMAIL PROTECTED] Robert Watson wrote: On Thu, 28 Nov 2002, Terry Lambert wrote: I'm positive it's a problem. Someone posted test code for it already, which is simpler than the code I've seen the problem reported with. I don't personally use jails this way, and it was really complicated to repeat before the new test code. If you are interested, I can find the previous report for you; it had to do with the guy's system with multiple jails locking up every day at the same time, which turned out to be the time the /etc/security cron job ran it's 'find'. This was about 4 months ago, and I helped him work around the problem by rearranging his directories so that the vnode files acting as backing store were never in the same subdirectory as a similar file, if you want to look for it in the archives. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: /usr/bin/finger problems...
On Mon, 2 Dec 2002, Kris Kennaway wrote: On Mon, Dec 02, 2002 at 10:01:22PM +1100, J R Matthews wrote: I can submit a patch to fix this if you want or not.. I honestly dont give a damn to be honest ;) Submitting a PR containing a patch is the best way to get this fixed. Thanks! Well the guy who emailed me who dealt with the 'send-pr' which I submitted agreed that it was kinda stupid submitting a patch with it. If you cant figure out the one-liner then there's something seriously wrong ;) jen Alright! I'll tell you! Do you know... the muffin man? The muffin man? The muffin man. Yes I know the muffin man - who lives on Drury Lane? Well ... she's married to the muffin man. The MUFFIN man!?!? THE MUFFIN MAN!!! -- Shrek To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
CHINESE SEARCH ENGINE / YOU WANTED
You wanted information on chinese search engine Please note which one is being used by Australian sites To great success http://www.chinawebs.com/comp/list_sub2.php?sub2_id=2234 Regards Steven Sanders 1479Xnnw6-866PQQw5405btvQ9-886uxzJ6391GGnI5-650MfbI837l51 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
