Re: NFS/VM deadlock report and help request
On Fri, Oct 20, 2000 at 09:24:03AM -0700, Matt Dillon wrote: :The kernel config I supply as an attachment. Kernel-mode stack : trace for the thttpd process looks like this: : :I think we've seen a similar problem and have a work around for it. :You could try the following patch, though it might take more fiddling :to get it right. : :(The patch is by Ian Dowse, Matt Dillon had a quick look at it and said :it looked OK, we've been testing it for a bit here). : : David. Ah yes, that problem... if Ian's patch solves the problem for Vadim, I think you should go ahead and commit it. After a day of testing I confirm that the patch does work. -- /Voland Vadim Belman E-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to install BootEasy?
Bob Bishop wrote: Apologies for this, I'm sure I've seen the answer recently but I'm *^%ed if I can find it in the archives[1]. I have an installed FreeBSD hard disk that I want to use as the second drive on a machine with other stuff on the first drive. How do I install BootEasy on the first drive? TIA We don't use BootEasy any longer, but something called boot0 ... which is probably why you couldn't find anything in the archives. Something like boot0cfg -Bv $DRIVE should work, though see the man page. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs. Linux
On Sat, 21 Oct 2000, Frederik Meerwaldt wrote: -Differences... FreeBSD is a real Unix, while Linux is a ..how should I Hmmm. FreeBSD is not a UNIX, rather it's a UNIX alike OS. (Which really doesn't matter IMHO) Don't forget UNIX is a trademark of Open Group. Actually, it's a trademark of USL, licensed to The Open Group. People with paid up USL licenses are grandfathered to be able to call it UNIX, since it's derived from USL sources. I believe there was actually a full POSIX certification of a version of Linux at one time, but it's certainly dated, and the trademark usage rules have since changed. I believe that the The Open Group license is exclusive, so I don't know what impact Caldera's recent purchase has on their ability to call Caldera Linux "UNIX". Last time I checked, they wanted an unholy amount of money to permit you to use the trademark, or they wanted a similar amount for an SVR4 source license, so there was practically no difference in the money they got out of the deal (so I guess the value is in the name, not the code). On a similar note, Novell was licensing NetWare for UNIX for $150,000, the Netware for UNIX Client for $100,000, or you could get UNIX sources and both NetWare products for $250,000, which also makes a statement about the value of the SVR4 source code... Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cache Questions
We're working on a driver for a PCI card, we're currently running into a problem that's symptomatic of a cache coherency problem. We have a area of memory that we manipulate and pass a physical address to our card. In other OS's (Linux, NT), before we manipulate this memory area, we mark the area as non-cachable. Are there similar operations/system calls we can use in FreeBSD? Are there any FAQ's, Docs or man-pages that explain memory usage/attributes? FreeBSD has a unified VM and buffer cache, so you should not really be having cache coherency issues. This sounds like the DMA from the card is getting bad data transferred into the card memory from the host memory, since the data is in the chip cache, and hasn't been written to main memory yet? I think this is the only possible failure mode. This indicates to me that your cache is not properly configured for write-through, or that you are using an older chipset, with more than two PCI devices. You could always mark it non-cacheable, of course: there are primitives to support this (see other postings in this thread), but I would really be surprised about you needing to do this. Another alternative might be that your card is eating the high bits (i.e. it can only see a region of low memory), or that you are doing unaligned transfers (many cards hate them), so there might be other avenues you should explore (I know that there are a number of video boards, for example, which can only access low memory correctly). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cache Questions
We're working on a driver for a PCI card, we're currently running into a problem that's symptomatic of a cache coherency problem. We have a area of memory that we manipulate and pass a physical address to our card. In other OS's (Linux, NT), before we manipulate this memory area, we mark the area as non-cachable. Are there similar operations/system calls we can use in FreeBSD? Are there any FAQ's, Docs or man-pages that explain memory usage/attributes? Take a look at sys/memrange.h, and particularly mem_range_attr_set(). *However*, since the PC architecture is strongly cache coherent, you probably have a problem with the design or implementation of your driver:adapter protocol. Marking an entire region of memory as uncacheable is *very* inefficient; there are much better ways of maintaining synchronisation without doing this. Mark had a good point about wiring the pages so they don't get swapped, if they are in a swappable region in another thread discussion DMA. He also pointed out that if he was talking about physical pages, that he needs to make sure that they are either contiguous, or that the DMA region doesn't span a page boundary. If the original poster follows -hackers, look for a subject with "DMA in drivers", since the topic appears to be over similar general issues. For that matter, your scatter/gather comments in that thread were also potentially relevent. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Cache Questions
Terry, Thanks for the information, you're right in that we are not experiencing cache problems. It's a timing issue we haven't tracked down yet, but I'm sure we will. Thanks for the DMA pointers. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Terry Lambert Sent: Tuesday, October 24, 2000 3:54 AM To: Christopher Harrer Cc: Freebsd-Hackers Subject: Re: Cache Questions We're working on a driver for a PCI card, we're currently running into a problem that's symptomatic of a cache coherency problem. We have a area of memory that we manipulate and pass a physical address to our card. In other OS's (Linux, NT), before we manipulate this memory area, we mark the area as non-cachable. Are there similar operations/system calls we can use in FreeBSD? Are there any FAQ's, Docs or man-pages that explain memory usage/attributes? FreeBSD has a unified VM and buffer cache, so you should not really be having cache coherency issues. This sounds like the DMA from the card is getting bad data transferred into the card memory from the host memory, since the data is in the chip cache, and hasn't been written to main memory yet? I think this is the only possible failure mode. This indicates to me that your cache is not properly configured for write-through, or that you are using an older chipset, with more than two PCI devices. You could always mark it non-cacheable, of course: there are primitives to support this (see other postings in this thread), but I would really be surprised about you needing to do this. Another alternative might be that your card is eating the high bits (i.e. it can only see a region of low memory), or that you are doing unaligned transfers (many cards hate them), so there might be other avenues you should explore (I know that there are a number of video boards, for example, which can only access low memory correctly). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS/VM deadlock report and help request
On Tue, Oct 24, 2000 at 09:21:01AM +0200, Vadim Belman wrote: After a day of testing I confirm that the patch does work. I've just committed the patch to -current, I'll MFC it in a few days. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Conflicting C/H/S values
Trent Nelson wrote: Could someone explain to me why the following HDD BIOS Geometries don't represent the values proposed by the drives. What am I missing? (snippets from boot -v) BIOS Geometries: 0:030c7f3f 0..780=781 cylinders, 0..127=128 heads, 1..63=63 sectors 1:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 2:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 3:026dfe3f 0..621=622 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for These don't correlate to the C/H/S values proposed by the drives: ad0: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S ad1: 9787MB (20044080 sectors), 19885 cyls, 16 heads, 63 S/T, 512 B/S ad2: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S ad3: 4892MB (10018890 sectors), 10602 cyls, 15 heads, 63 S/T, 512 B/S I'm running 5.0 as of mid-September, but I don't think that's the issue as Windows tends to exhibit the same behaviour. The way the PC BIOS CHS disk interface was designed, too few cylinders (1024) and too many heads (256) are supported, compared with the geometry disk drives pretend to have nowadays. So most modern BIOSes do translation by default, representing 6256 cyls x 16 heads as (6256/8 x 16*8 =) 782 cyls x 128 heads. The off-by-one difference (782 vs. 781 given as BIOS geometry for drive 0) is due to reserving the last cylinder for diagnostics, etc., another BIOS quirk. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Determining CPU on SMP box
Hello All, Is there a way to determine which CPU I'm currently executing on in a SMP box? I've found references to proc-p_oncpu, but I'm not sure if this is the best way to determine where I'm executing. I'd like to be able to "trace" various actions within my driver and one of the fields I want to keep track of is what CPU I'm executing on. Thanks! Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/nfs nfs.h nfs_subs.c nfsm_subs.h
[Redirecting to -hackers after this one] -On [20001024 13:55], David Malone ([EMAIL PROTECTED]) wrote: On Tue, Oct 24, 2000 at 01:03:16PM +0200, Jeroen Ruigrok van der Werven wrote: Does this solve the problem reported by me in MSG-ID: [EMAIL PROTECTED] on -stable back in June/July? Possibly, but probably not. We do know about another bug which causes this sort of problem, but haven't quite figured out how to fix it yet. See Ian's message to -hackers: [EMAIL PROTECTED] Just read through the thread, the situation looks like the one we had. At least for the vmopar problems. We run a bunch of webservers who get the data off of a read-only NFS mount from a NetApp. Of course when an user updates the files the Apache webserver might reference that file and you get the same problem as Vadim described. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl But touch my Tears, with your lips, touch my World, with your fingertips, and we can have forever... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Who broke ls in FreeBSD? and why?
[ redirected to -hackers ] On Tue, Oct 24, 2000 at 12:23:57AM -0700, Jordan Hubbard wrote: What's wrong with -a? And what the heck does this have to do with mobile computing? -a doesn't disable -A, it adds to it (also shows . and ..). I think this guy's looking for an option to disable this flag.. no idea why. One could simply invoke `ls' as a normal user (say, `nobody') if they so desired. -- Will Andrews [EMAIL PROTECTED] - Physics Computer Network wench To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Who broke ls in FreeBSD? and why?
In message [EMAIL PROTECTED] Will Andrews writes: : [ redirected to -hackers ] : : On Tue, Oct 24, 2000 at 12:23:57AM -0700, Jordan Hubbard wrote: : What's wrong with -a? And what the heck does this have to do with : mobile computing? : : -a doesn't disable -A, it adds to it (also shows . and ..). I think : this guy's looking for an option to disable this flag.. no idea why. : One could simply invoke `ls' as a normal user (say, `nobody') if they so : desired. Yes. Last night I misunderstood what he was saying. For normal users, ls -a lists all files, not counting . and .., but for root it does list all files. ls -A lists all files for normal users, but omits . and .. for root. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gateway on different subnet
IT WORKED ! the arp way is the true way hehehe I edited /sbin/dhclient-script to automate the process: - removed the code that was supposed to add the default gateway - added following lines in its place: arp -s 208.59.162.1 00:20:cd:02:f1:59# MAC address of cable modem gateway route add default 208.59.162.1 Later I'll have to figure out a way to take the $new_ip_address variable and modify it into my dummy gateway, so that the script would handle any IP my provider throws at it. And to make it work with any modem, I'd need an automatic way to get the MAC based on gateway IP (10.17.56.12). Any standard way to do this ? Thanks to everyone who has replied with suggestions, especially to Nick whose suggestion was the answer I needed :) Nick Rogness wrote: On Mon, 23 Oct 2000, Les Biffle wrote: Hm -- how about using proxy-arp style routing? Here's what I've done in the past: 1. Have a friend out in the net ping your address 208.59.162.242 2. Run tcpdump and look for someone ARPing for you. That someone will very likely be your default gateway as seen from your site. If that router is in your subnet, set your default to it and you're done. If not, continue at the next step. 3. Pick an IP Address in your cable subnet that feels like a really good router address to you. Make something up. 208.59.162.1 perhaps? 4. Use "arp -s 208.59.162.1 xx:xx:xx:xx:xx:xx" to install an arp entry in your route table for this made-up address. That will keep you from ARPing for 208.59.162.1 and discovering the device that really owns that address. 5. Set your default gateway to 208.59.162.1. If that doesn't work (it should), you could also look into the ipfw fwd option. I would like to know when you get it to work... Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gateway on different subnet
On Tue, 24 Oct 2000, Marko Ruban wrote: IT WORKED ! the arp way is the true way hehehe Thanks to everyone who has replied with suggestions, especially to Nick whose suggestion was the answer I needed :) Actually it was Mr. Biffle (Les Biffle [EMAIL PROTECTED]). I will make sure to document it though. Thanks for the reply. Nick Rogness - Drive defensively. Buy a tank. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vm_pageout_scan badness
Matt, I'm not sure if Paul mailed you yet so I thought I'd take the
initiative of bugging you about some reported problems (lockups)
when dealing with machines that have substantial MAP_NOSYNC'd
data along with a page shortage.
What seems to happen is that vm_pageout_scan (src/sys/vm/vm_pageout.c
line 618) keeps rescanning the inactive queue.
My guess is that it just doesn't expect someone to have hosed themselves
by having so many pages that need laundering (maxlaunder/launder_loop)
along with the fact that the comment and code here are doing the wrong
thing for the situation:
/*
* Figure out what to do with dirty pages when they are encountered.
* Assume that 1/3 of the pages on the inactive list are clean. If
* we think we can reach our target, disable laundering (do not
* clean any dirty pages). If we miss the target we will loop back
* up and do a laundering run.
*/
if (cnt.v_inactive_count / 3 page_shortage) {
maxlaunder = 0;
launder_loop = 0;
} else {
maxlaunder =
(cnt.v_inactive_target max_page_launder) ?
max_page_launder : cnt.v_inactive_target;
launder_loop = 1;
}
The problem is that there's a chance that nearly all the pages on
the inactive queue need laundering and the loop that starts with
the lable 'rescan0:' is never able to clean enough pages before
stumbling across a block that has moved to another queue. This
forces a jump back to the 'rescan0' lable with effectively nothing
accomplished.
Here's a patch that may help, it's untested, but shows what I'm
hoping to achieve which is force a maximum on the amount of times
rescan0 will be jumped to while not laundering.
Index: vm_pageout.c
===
RCS file: /home/ncvs/src/sys/vm/vm_pageout.c,v
retrieving revision 1.151.2.4
diff -u -u -r1.151.2.4 vm_pageout.c
--- vm_pageout.c2000/08/04 22:31:11 1.151.2.4
+++ vm_pageout.c2000/10/24 07:31:39
@@ -618,7 +618,7 @@
vm_pageout_scan()
{
vm_page_t m, next;
- int page_shortage, maxscan, pcount;
+ int page_shortage, maxscan, maxtotscan, pcount;
int addl_page_shortage, addl_page_shortage_init;
int maxlaunder;
int launder_loop = 0;
@@ -672,13 +672,23 @@
* we have scanned the entire inactive queue.
*/
+rescantot:
+ /* make sure we don't hit rescan0 too many times */
+ maxtotscan = cnt.v_inactive_count;
rescan0:
addl_page_shortage = addl_page_shortage_init;
maxscan = cnt.v_inactive_count;
+ if (maxtotscan 1) {
+ maxlaunder =
+ (cnt.v_inactive_target max_page_launder) ?
+ max_page_launder : cnt.v_inactive_target;
+ }
for (m = TAILQ_FIRST(vm_page_queues[PQ_INACTIVE].pl);
m != NULL maxscan-- 0 page_shortage 0;
m = next) {
+ --maxtotscan;
+
cnt.v_pdpages++;
if (m-queue != PQ_INACTIVE) {
@@ -930,7 +940,7 @@
maxlaunder =
(cnt.v_inactive_target max_page_launder) ?
max_page_launder : cnt.v_inactive_target;
- goto rescan0;
+ goto rescantot;
}
/*
(still talking about vm_pageout_scan()):
I'm pretty sure that there's yet another problem here, when paging
out a vnode's pages the output routine attempts to cluster them,
this could easily make 'next' point to a page that is cleaned and
put on the FREE queue, when the loop then tests it for
'm-queue != PQ_INACTIVE' it forces 'rescan0' to happen.
I think one could fix this by keeping a pointer to the previous
page then the 'goto rescan0;' test might become something like
this:
/*
* We keep a back reference just in case the vm_pageout_clean()
* happens to clean the page after the one we just cleaned
* via clustering, this would make next point to something not
* one the INACTIVE queue, as a stop-gap we keep a pointer
* to the previous page and attempt to use it as a fallback
* starting point before actually starting at the head of the
* INACTIVE queue again
*/
if (m-queue != PQ_INACTIVE) {
if (prev != NULL prev-queue == PQ_INACTIVE) {
m = TAILQ_NEXT(prev, pageq);
if (m == NULL || m-queue != PQ_INACTIVE)
goto rescan0;
} else {
goto rescan0;
}
}
Of course we need to set 'prev' properly, but I need to get back
to my database stuff right now. :)
Also... I wish there was a good hueristic to make max_page_launder
a bit more adaptive, you've done some wonders with bufdaemon so
I'm wondering if
Solaris 8's split cache
http://sunsolve.Sun.COM/pub-cgi/show.pl?target=content/content8#cyclical BSD doesn't do anything like this (distinguishing between instructions and data in the VM cache), does it? Should it? -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solaris 8's split cache
* void [EMAIL PROTECTED] [001024 11:37] wrote: http://sunsolve.Sun.COM/pub-cgi/show.pl?target=content/content8#cyclical BSD doesn't do anything like this (distinguishing between instructions and data in the VM cache), does it? Should it? It's an interesting idea, the only weirdness is that one could pretty easily tie down a lot of memory with underused instruction data and force the filesystem cache to use a much smaller subset of memory than it should degrading performance, it could also work against you in the opposite direction. If solaris is able to put these pages on a "general inactive+free queue" after some time so that pages can migrate between the two caches it would help out some. Interestingly enough we're trying to address a problem related to this in FreeBSD right now, but I'm not sure the Solaris solution is the right way to go. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
Ouch. The original VM code assumed that pages would not often be
ripped out from under the pageadaemon, so it felt free to restart
whenever. I think you are absolutely correct in regards to the
clustering code causing nearby-page ripouts.
I don't have much time available, but let me take a crack at the
problem tonight. I don't think we want to add another workaround to
code that already has too many of them. The solution may be
to create a dummy placemarker vm_page_t and to insert it into the pagelist
just after the current page after we've locked it and decided we have
to do something significant to it. We would then be able to pick the
scan up where we left off using the placemarker.
This would allow us to get rid of the restart code entirely, or at least
devolve it back into its original design (i.e. something that would not
happen very often). Since we already have cache locality of reference for
the list node, the placemarker idea ought to be quite fast.
I'll take a crack at implementing the openbsd (or was it netbsd?) partial
fsync() code as well, to prevent the update daemon from locking up large
files that have lots of dirty pages for long periods of time.
-Matt
:
:Matt, I'm not sure if Paul mailed you yet so I thought I'd take the
:initiative of bugging you about some reported problems (lockups)
:when dealing with machines that have substantial MAP_NOSYNC'd
:data along with a page shortage.
:
:What seems to happen is that vm_pageout_scan (src/sys/vm/vm_pageout.c
:line 618) keeps rescanning the inactive queue.
:
:My guess is that it just doesn't expect someone to have hosed themselves
:by having so many pages that need laundering (maxlaunder/launder_loop)
:along with the fact that the comment and code here are doing the wrong
:thing for the situation:
:
: /*
:* Figure out what to do with dirty pages when they are encountered.
:* Assume that 1/3 of the pages on the inactive list are clean. If
:* we think we can reach our target, disable laundering (do not
:* clean any dirty pages). If we miss the target we will loop back
:* up and do a laundering run.
:*/
:
: if (cnt.v_inactive_count / 3 page_shortage) {
: maxlaunder = 0;
: launder_loop = 0;
: } else {
: maxlaunder =
: (cnt.v_inactive_target max_page_launder) ?
: max_page_launder : cnt.v_inactive_target;
: launder_loop = 1;
: }
:
:The problem is that there's a chance that nearly all the pages on
:the inactive queue need laundering and the loop that starts with
:the lable 'rescan0:' is never able to clean enough pages before
:stumbling across a block that has moved to another queue. This
:forces a jump back to the 'rescan0' lable with effectively nothing
:accomplished.
:
:Here's a patch that may help, it's untested, but shows what I'm
:hoping to achieve which is force a maximum on the amount of times
:rescan0 will be jumped to while not laundering.
:...
:
:I'm pretty sure that there's yet another problem here, when paging
:out a vnode's pages the output routine attempts to cluster them,
:this could easily make 'next' point to a page that is cleaned and
:put on the FREE queue, when the loop then tests it for
:'m-queue != PQ_INACTIVE' it forces 'rescan0' to happen.
:
:I think one could fix this by keeping a pointer to the previous
:page then the 'goto rescan0;' test might become something like
:this:
:...
:
:Of course we need to set 'prev' properly, but I need to get back
:to my database stuff right now. :)
:
:Also... I wish there was a good hueristic to make max_page_launder
:a bit more adaptive, you've done some wonders with bufdaemon so
:I'm wondering if you had some ideas about that.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
:"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
PCI Device Remapping
I've written a device driver for a proprietary PCI card, and have run into what seems to be a show-stopping bug. The device I'm writing the driver for is responsible for running DMA transfers to other PCI devices, and all of our initial work was going well. I locked down a contiguous range of host memory and was able to do DMA fine. I'm now trying to get the card to do DMA to other PCI cards, and have found a bug in our chip. Basically, the high bit of the address on PCI transfers gets dropped. This means that the chip can't address PCI memory physical addresses over 0x7FFF. Big problem, since the BIOS on our computers maps PCI device memory from 0x downward. So my question is, under FreeBSD (any version -- we're currently running 3.4, but I can upgrade to -current if it will help), is there any support for overriding the BIOS-assigned PCI address maps? I've read through the 3.4 pci.c code and didn't see anything, and am not thrilled about writing code to remap all the devices on the PCI bus. I'm talking to our BIOS vendor about getting them to do the rework for us, but as in all dealing with BIOS vendors, I am not hopeful :-( Thanks for any and all suggestions! DaveG o_,o, o_ o_ o' Programmer )-' /|' ),` ) ' (\^o Gymnast Dancer \/ \ ^' \' Hiker [EMAIL PROTECTED] www.mit.edu/~daveg/ (617)216-4705 [EMAIL PROTECTED] www.conexant.com(508)621-0658 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining CPU on SMP box
Is there a way to determine which CPU I'm currently executing on in a SMP box? I've found references to proc-p_oncpu, but I'm not sure if this is the best way to determine where I'm executing. I'd like to be able to "trace" various actions within my driver and one of the fields I want to keep track of is what CPU I'm executing on. There's a per-CPU variable 'cpuid' (at least, there used to be) that you could use for this. However, it's kinda pointless working out what CPU you're on, since you're liable to be rescheduled onto another CPU if an interrupt occurs... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs. Linux
Hi, Terry Lambert wrote: On Sat, 21 Oct 2000, Frederik Meerwaldt wrote: -Differences... FreeBSD is a real Unix, while Linux is a ..how should I Hmmm. FreeBSD is not a UNIX, rather it's a UNIX alike OS. (Which really doesn't matter IMHO) Don't forget UNIX is a trademark of Open Group. Actually, it's a trademark of USL, licensed to The Open Group. `Actually' ;-) ... Well I'm not sure, ... the TM ownership has ceased to be of real relevance to me, but AFAIR Unix the TM was bought by SCO a few years back, (SCO=Santa Cruz Org, server div. of which is busy being bought by Caldera, a Linux distrib.) I believe that the The Open Group license is exclusive, so I Exclusion not possible regarding current licensed usage of the name, only regarding granting of future licences to use the name. don't know what impact Caldera's recent purchase has on their ability to call Caldera Linux "UNIX". Unix the TM has moved a lot: ATT Bell Labs NJ, then also licensed by Unix Europe in Putney London (a European subsidiary of ATT) used to flog licences in the 80s, I guess just about every major computer co. can dig up a licence that they too are allowed to flog some ancient version of Unix, use the name Unix in marketing etc (probably with a `this is not the original, but is based on' clause). Who this season holds the right to sell licenses to use the Unix TM I'm not sure, but as the Bavarian (Germany) division of SCO holds its quarterly business briefing this thursday (supported by Caldera, backed by Compaq), I'll ask them if they know who's the current owner of the trademark. Julian - Julian Stacey http://bim.bsn.com/~jhs/ Munich Unix Consultant. Free BSD Unix with 3900 packages sources. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody want to review vi patch?
I did some additions to vi long ago: http://bim.bsn.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/contrib/nvi/ I seem to recall sending them to Keith Bostik maybe (the/an author I recall), my patches ars still outstanding AFAIK. (my patches signal link vi to chimera ghostscript xfig to do a WYSIWYG linkage between an xterm editing a source, a graphical output viewer ). Reference: From: Christian Weisgerber [EMAIL PROTECTED] Date: Sat, 21 Oct 2000 13:28:00 +0200 Message-id: [EMAIL PROTECTED] Hi, Christian Weisgerber wrote: --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline There's a bug in nvi 1.79. The options "noprint", "print", and "octal" don't work properly. When these options are changed, the routine that evaluates them is called before the option has been set. Do we have any people who know their way around the guts of nvi? I've appended a patch, partly based on a change in nvi 1.81 where this is fixed incompletely, and I'd like somebody to review this. Julian - Julian Stacey http://bim.bsn.com/~jhs/ Munich Unix Consultant. Free BSD Unix with 3900 packages sources. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pci maps
if your cards are on pci bus 0, not behind a bridge, you can set the base addresses to pretty much any value you want even after the OS is up -- you just have to make sure the drivers are all informed. But it's no big deal, you can do it from user mode if you have access to ports cf8/cfc. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Device Remapping
I've written a device driver for a proprietary PCI card, and have run
into what seems to be a show-stopping bug. The device I'm writing the
driver for is responsible for running DMA transfers to other PCI
devices, and all of our initial work was going well. I locked down a
contiguous range of host memory and was able to do DMA fine. I'm now
trying to get the card to do DMA to other PCI cards, and have found a
bug in our chip. Basically, the high bit of the address on PCI
transfers gets dropped. This means that the chip can't address PCI
memory physical addresses over 0x7FFF. Big problem, since the
BIOS on our computers maps PCI device memory from 0x downward.
Whoops.
So my question is, under FreeBSD (any version -- we're currently
running 3.4, but I can upgrade to -current if it will help), is there
any support for overriding the BIOS-assigned PCI address maps? I've
read through the 3.4 pci.c code and didn't see anything, and am not
thrilled about writing code to remap all the devices on the PCI bus.
There is no support, no. You really have one serious option - fix your
chip.
I'm talking to our BIOS vendor about getting them to do the rework for
us, but as in all dealing with BIOS vendors, I am not hopeful :-(
If you're working on a single, fixed platform, this should be pretty
simple; they just lop the top bit off the base address they use for PCI
address allocation.
Here's an evil trick you can pull though, if you're *really* desperate
and if you're *certain* that you're in control of your platform, and
*certain* that you'll never have more than ~1.9GB of physical memory.
In sys/pci/pci.c:pci_readmaps(), fix the loop that reads maps to knock the
high bit off memory ranges and write them back:
for (i = 0; i maxmaps; i++) {
int reg = PCIR_MAPS + i*4;
u_int32_t base;
u_int32_t ln2range;
base = pci_cfgread(cfg, reg, 4);
ln2range = pci_maprange(base);
if (base == 0 || ln2range == 0 || base == 0x)
continue; /* skip invalid entry */
else {
/* remap below 2GB */
if (pci_maptype(base) == PCI_MAPMEM) {
base = ~0x8000;
pci_cfgwrite(cfg, reg, base, 4);
ln2range = pci_maprange(base);
}
j++;
if (ln2range 32) {
i++;
j++;
}
}
}
This is, of course, only a solution if you have total control over the
system as well; if you plan to ship the product for inclusion in general
FreeBSD systems, you're prettymuch hosed.
I hope this helps though.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI Device Remapping
Mike Smith [EMAIL PROTECTED] writes:
If you're working on a single, fixed platform, this should be pretty
simple; they just lop the top bit off the base address they use for PCI
address allocation.
Here's an evil trick you can pull though, if you're *really* desperate
and if you're *certain* that you're in control of your platform, and
*certain* that you'll never have more than ~1.9GB of physical memory.
In sys/pci/pci.c:pci_readmaps(), fix the loop that reads maps to knock the
high bit off memory ranges and write them back:
for (i = 0; i maxmaps; i++) {
int reg = PCIR_MAPS + i*4;
u_int32_t base;
u_int32_t ln2range;
base = pci_cfgread(cfg, reg, 4);
ln2range = pci_maprange(base);
if (base == 0 || ln2range == 0 || base == 0x)
continue; /* skip invalid entry */
else {
/* remap below 2GB */
if (pci_maptype(base) == PCI_MAPMEM) {
base = ~0x8000;
pci_cfgwrite(cfg, reg, base, 4);
ln2range = pci_maprange(base);
}
j++;
if (ln2range 32) {
i++;
j++;
}
}
}
This is, of course, only a solution if you have total control over the
system as well; if you plan to ship the product for inclusion in general
FreeBSD systems, you're prettymuch hosed.
This is actually only needed for an internal use project, and this
hack is exactly what I was looking for! It works wonderfully,
although I had to change the code slightly:
if ((pci_maptype(base) PCI_MAPMEM) == PCI_MAPMEM) {
base = ~0x8000;
printf("0x%x)\n", base);
pci_cfgwrite(cfg, reg, base, 4);
ln2range = pci_maprange(base);
}
to handle prefetchable memory as well.
Thank you very much for the suggestion -- I'd read through that code,
but didn't think about the simple fix you've suggested!
DaveG o_,o, o_ o_ o'
Programmer )-' /|' ),` ) ' (\^o Gymnast
Dancer \/ \ ^' \' Hiker
[EMAIL PROTECTED] www.mit.edu/~daveg/ (617)216-4705
[EMAIL PROTECTED] www.conexant.com(508)621-0658
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
* Matt Dillon [EMAIL PROTECTED] [001024 13:11] wrote:
Ouch. The original VM code assumed that pages would not often be
ripped out from under the pageadaemon, so it felt free to restart
whenever. I think you are absolutely correct in regards to the
clustering code causing nearby-page ripouts.
Yes, it would make sense to me that if you did a sequential write
to a file after some time it would be likely that those pages would
be put in order on the inactive queue and when cluster written
'next' would be on a different queue as it was written along with
the preceeding page.
I don't have much time available, but let me take a crack at the
problem tonight. I don't think we want to add another workaround to
code that already has too many of them. The solution may be
to create a dummy placemarker vm_page_t and to insert it into the pagelist
just after the current page after we've locked it and decided we have
to do something significant to it. We would then be able to pick the
scan up where we left off using the placemarker.
This would allow us to get rid of the restart code entirely, or at least
devolve it back into its original design (i.e. something that would not
happen very often). Since we already have cache locality of reference for
the list node, the placemarker idea ought to be quite fast.
I'll take a crack at implementing the openbsd (or was it netbsd?) partial
fsync() code as well, to prevent the update daemon from locking up large
files that have lots of dirty pages for long periods of time.
Making the partial fsync would help some people but probably not
these folks.
The people getting hit by this are Yahoo! boxes, they have giant areas
of NOSYNC mmap'd data, the issue is that for them the first scan through
the loop always sees dirty data that needs to be written out. I think
they also need a _lot_ more than 32 pages cleaned per pass because all
of thier pages need laundering.
Perhaps if you detected how often the routine was being called you
could slowly raise max_page_launder to compensate and lower it
after some time without a shortage. Perhaps adding a quarter of
'should_have_laundered' to maxlaunder for a short interval.
It might be wise to switch to a 'launder mode' if this sort of
usage pattern is detected and figure some better figure to use than
32, I was hoping you'd have some suggestions for a heuristic to
detect this along the lines of what you have implemented in bufdaemon.
What you could also do is count the amount of pages that could/should have
been laundered during the first pass and if it exceeds a certain threshold
passing the amount of pages that were free'd via:
if (m-object-ref_count == 0) {
and:
if (m-valid == 0) {
and:
} else if (m-dirty == 0) {
basically if maxlaunder is equal to zero and we miss all those tests
you might want to bump up a counter and if it exceeds a threshold
immediately start rescanning and double(?) maxlaunder.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
:The people getting hit by this are Yahoo! boxes, they have giant areas :of NOSYNC mmap'd data, the issue is that for them the first scan through :the loop always sees dirty data that needs to be written out. I think :they also need a _lot_ more than 32 pages cleaned per pass because all :of thier pages need laundering. : :Perhaps if you detected how often the routine was being called you :could slowly raise max_page_launder to compensate and lower it :after some time without a shortage. Perhaps adding a quarter of :'should_have_laundered' to maxlaunder for a short interval. : :It might be wise to switch to a 'launder mode' if this sort of :usage pattern is detected and figure some better figure to use than :32, I was hoping you'd have some suggestions for a heuristic to :detect this along the lines of what you have implemented in bufdaemon. We definitely don't want to increase max_page_launder too much... the problem is that there is a relationship between it and the number of simultanious async writes that can be queued in one go, and that can interfere with normal I/O. But perhaps we should decouple it from the I/O count and have it count clusters instead of pages. i.e. this line: written = vm_pageout_clean(m); if (vp) vput(vp) maxlaunder -= written; Can turn into: if (vm_pageout_clean(m)) --maxlaunder; if (vp) vput(vp); In regards to speeding up paging, perhaps we can implement a heuristic similar to what buf_daemon() does. We could wake the pageout daemon up more often. I'll experiment with it a bit. We certainly have enough statistical information to come up with something good. -Matt :-Alfred : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Anyone have uhid working and stable?
After just buying a device and attempting to use uhid for a while, I got a
nice little crash. I can't figure out what's going on, because the clist
queue seems to be corrupted. Is it valid for a clist to have a non-zero
c_cc and NULL c_cf? I wonder if this is just me, because it seems to have
been provoked with little effort.
Maybe I'm missing something as to where exactly the crash occurs -- the line
of code is wrong, and I don't exactly see where the bcopy is coming from
(other than probably q_to_b or uiomove, but I don't know how they can't show
up on the stack trace).
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:461
#1 0xc016873f in boot (howto=0x100) at ../../kern/kern_shutdown.c:302
#2 0xc0168ae1 in panic (fmt=0xc029198f "page fault") at ../../kern/kern_shutdown.c:550
#3 0xc024ef2a in trap_fatal (frame=0xd02f6cac, eva=0x0) at ../../i386/i386/trap.c:951
#4 0xc024ebdd in trap_pfault (frame=0xd02f6cac, usermode=0x0, eva=0x0) at
../../i386/i386/trap.c:844
#5 0xc024e77f in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10, tf_edi =
0xd02f6d3c, tf_esi = 0x0,
tf_ebp = 0xd02f6d1c, tf_isp = 0xd02f6cd8, tf_ebx = 0x4, tf_edx = 0x80, tf_ecx =
0x1, tf_eax = 0xd02f6d3c,
tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc024d34a, tf_cs = 0x8, tf_eflags =
0x10212, tf_esp = 0x0,
tf_ss = 0xc14f6bb4}) at ../../i386/i386/trap.c:443
#6 0xc024d34a in generic_bcopy ()
#7 0xc18695e9 in uhid_do_read (sc=0xc14f6b80, uio=0xd02f6edc, flag=0x7f0010)
at /usr/src/sys/modules/uhid/../../dev/usb/uhid.c:504
#8 0xc1869649 in uhidread () at /usr/src/sys/modules/uhid/../../dev/usb/uhid.c:513
#9 0xc01a5e29 in spec_read (ap=0xd02f6e6c) at ../../miscfs/specfs/spec_vnops.c:261
#10 0xc02144f8 in ufsspec_read (ap=0xd02f6e6c) at ../../ufs/ufs/ufs_vnops.c:1802
#11 0xc02149f9 in ufs_vnoperatespec (ap=0xd02f6e6c) at ../../ufs/ufs/ufs_vnops.c:2281
#12 0xc01a2ef4 in vn_read (fp=0xc105d080, uio=0xd02f6edc, cred=0xc11e1280, flags=0x0,
p=0xc7e65380) at vnode_if.h:334
#13 0xc017a1f4 in dofileread (p=0xc7e65380, fp=0xc105d080, fd=0x6, buf=0x8baf180,
nbyte=0x4,
offset=0x, flags=0x0) at ../../sys/file.h:141
#14 0xc017a0db in read (p=0xc7e65380, uap=0xd02f6f80) at ../../kern/sys_generic.c:110
#15 0xc024f1dd in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi =
0x0, tf_esi = 0x8bac6e4,
tf_ebp = 0x0, tf_isp = 0xd02f6fd4, tf_ebx = 0x8bac6ec, tf_edx = 0x140, tf_ecx =
0x8, tf_eax = 0x3,
tf_trapno = 0x16, tf_err = 0x2, tf_eip = 0x28846858, tf_cs = 0x1f, tf_eflags =
0x256, tf_esp = 0xbfbff6a4,
tf_ss = 0x2f}) at ../../i386/i386/trap.c:1150
(kgdb) p ((struct uhid_softc *)$foo-softc)-sc_q
$18 = {
c_cc = 0x1c,
c_cbcount = 0x0,
c_cbmax = 0xb,
c_cbreserved = 0xb,
c_cf = 0x0,
c_cl = 0xc1178fb0 "åÚD6\tÄæ\037zk\036óÄIä!\nXÂ\022\212K§\233\207òS\217\203"
}
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
* Matt Dillon [EMAIL PROTECTED] [001024 15:32] wrote: :The people getting hit by this are Yahoo! boxes, they have giant areas :of NOSYNC mmap'd data, the issue is that for them the first scan through :the loop always sees dirty data that needs to be written out. I think :they also need a _lot_ more than 32 pages cleaned per pass because all :of thier pages need laundering. : :Perhaps if you detected how often the routine was being called you :could slowly raise max_page_launder to compensate and lower it :after some time without a shortage. Perhaps adding a quarter of :'should_have_laundered' to maxlaunder for a short interval. : :It might be wise to switch to a 'launder mode' if this sort of :usage pattern is detected and figure some better figure to use than :32, I was hoping you'd have some suggestions for a heuristic to :detect this along the lines of what you have implemented in bufdaemon. We definitely don't want to increase max_page_launder too much... the problem is that there is a relationship between it and the number of simultanious async writes that can be queued in one go, and that can interfere with normal I/O. But perhaps we should decouple it from the I/O count and have it count clusters instead of pages. i.e. this line: Ok, now I feel pretty lost, how is there a relationship between max_page_launder and async writes? If increasing max_page_launder increases the amount of async writes, isn't that a good thing? written = vm_pageout_clean(m); if (vp) vput(vp) maxlaunder -= written; Can turn into: if (vm_pageout_clean(m)) --maxlaunder; if (vp) vput(vp); In regards to speeding up paging, perhaps we can implement a heuristic similar to what buf_daemon() does. We could wake the pageout daemon up more often. I'll experiment with it a bit. We certainly have enough statistical information to come up with something good. That looks like it would help by ignoring the clustered data which probably got written out pretty quickly and reducing the negative cost/gain to a single page. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs. Linux
Terry Lambert wrote: On Sat, 21 Oct 2000, Frederik Meerwaldt wrote: -Differences... FreeBSD is a real Unix, while Linux is a ..how should I Hmmm. FreeBSD is not a UNIX, rather it's a UNIX alike OS. (Which really doesn't matter IMHO) Don't forget UNIX is a trademark of Open Group. Actually, it's a trademark of USL, licensed to The Open Group. USL is no more, for quite a few years now. I believe that SCO gave the ownership of UNIX trademark to Open Group. I believe that the The Open Group license is exclusive, so I don't know what impact Caldera's recent purchase has on their ability to call Caldera Linux "UNIX". Well, actually Caldera has opposite problem: how to call UnixWare with Linux emulator "Linux". -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
:Ok, now I feel pretty lost, how is there a relationship between :max_page_launder and async writes? If increasing max_page_launder :increases the amount of async writes, isn't that a good thing? The async writes are competing against the rest of the system for disk resources. While it is ok for an async write to stall, the fact that it will cause other processes read() or page-in (which is nominally synchronous) requests to stall can result in seriously degraded operation for those processes. Piling on the number of async writes running in parallel is not going to improve the performance of page-out daemon, but it will degrade the performance of I/O issued by other processes in the system. The only two reasons the pageout daemon is not doing synchronous writes are: (1) because it can't afford to stall on a slow device (or NFS, etc.) and (2) so it can parallelize I/O across different devices. But since the pageout daemon isn't really all that smart and doesn't track what it does, the whole algorithm devolves into issueing a certain number of asynchronous I/O's all at once governed by max_page_launder. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Who broke ls in FreeBSD? and why?
Speaking of ls(1)...
$ mkdir Arghh
$ touch Arghh/{one,two,three}
$ ls Arghh
one three two
$ chmod a-x Arghh
$ ls Arghh echo SUCCESS
SUCCESS
$ ls -l Arghh echo SUCCESS
SUCCESS
ARH :-)
This is not the expected behavior. If a directory does not have
search permission, but it has read permission, a plain "ls" (or "ls -i")
should list its contents, while "ls -l" should fail. And still worse,
when ls fails to list the non-searchable directory contents, it
does _not_ return an error code.
I tried to find the cause of this behavior in the ls source code,
but it uses the fts(3) functions, which I am not used to.
Cheers,
-- JMA
** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] **
** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein **
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
AutoFS on FreeBSD
I was wondering if there is anyone working on AutoFS for FreeBSD. We currently have 4 studios with around 1000 unix systems of all kinds. Currently there are only 2 OSes that do not have autofs, FreeBSD and one that is known for its number crunching capabilties (and those are being phased out of production). Amd will not meet our needs because of the use of sym links. This is why AutoFS was written in the first place. I quote the 1993 USENIX paper on AutoFS (check http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/callaghan.txt for the full paper). Symbolic links A single automount daemon can service many mountpoints. At each mountpoint the daemon associates a map, and emulates either a symbolic link (direct map) or a directory of symbolic links (indirect map). The symbolic links point to a directory where the automounter performs NFS mounts - /tmp_mnt or /a. The automounter unmounts what it considers to be "idle" mounts - those that have not been active - or that can be unmounted (not busy). As long as all references to these mounts are made through the daemon mountpoint, the dae- mon can replace the mounts as necessary. However, if a process invokes the getwd() function to obtain the path of the current directory while in an automounted filesystem, it will obtain a "/tmp_mnt/..." path. If this "back door" path is cached and used sometime later, there is no guarantee that the filesystem will still be mounted there. The automounter cannot detect references to empty mount- points unless they are made through the automounter's mountpoint. A common victim of this behavior is the at com- mand. It uses the pwd command to record the current directory so that it can be cd'ed to for subsequent invocation of the script. The symbolic links also confuse users because "/tmp_mnt" frequently appears as a prefix to the current directory. Various workarounds have been proposed for this problem. The most common was for the getwd() function to strip prepended "/tmp_mnt/" from paths. This workaround didn't take into account the effect of the automounter's -M flag that allowed users to specify a directory other than "/tmp_mnt/". It is also questionable whether the semantics of getwd() should be changed this way. The symbolic links present a problem for relative references between separate automounter mounts. For instance given the two directories /home/bob and /home/carol it seems reasonable that Bob should be able to "cd ../carol" but this will fail if Carol's directory isn't already mounted. If no one is using it, how is it looked apon if AutoFS was ported from Linux (with the GPL and that stuff) or would a complete rewrite be better? - JimP -- --- @(#) $Id: dot.signature,v 1.9 2000/07/10 16:43:05 pirzyk Exp $ __o [EMAIL PROTECTED] - _'\,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AutoFS on FreeBSD
On Tue, Oct 24, 2000 at 05:24:06PM -0700, Jim Pirzyk wrote: I was wondering if there is anyone working on AutoFS for FreeBSD. We currently have 4 studios with around 1000 unix systems of all kinds. Currently there are only 2 OSes that do not have autofs, FreeBSD and one that is known for its number crunching capabilties (and those are being phased out of production). Amd will not meet our needs because of the use of sym links. This is why AutoFS was written in the first place. I quote the 1993 USENIX paper on AutoFS (check http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/callaghan.txt for the full paper). Do you mean amd(8)? AMD(8) FreeBSD System Manager's Manual AMD(8) NAME amd - automatically mount file systems ... DESCRIPTION Amd is a daemon that automatically mounts filesystems whenever a file or directory within that filesystem is accessed. Filesystems are automati- cally unmounted when they appear to be quiescent. ... HISTORY The amd utility first appeared in 4.4BSD. BSD April 19, 1994 3 -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: named changes between 4.0 and 4.1 releases
On Wed, Oct 25, 2000 at 11:49:15AM +1100, Christopher F. Moran wrote: Hi, How can I find what changes occurred to named as shipped on the 4.1 CDs? on 4.0-RELEASE we could do zone transfers with a Windows 2000 DNS, but putting the same config onto a 4.1-RELEASE machine we can't. I'm guessing something changed, and I need to try and figure out what. In general, RELNOTES.TXT; although the source is the definitive answer. -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: named changes between 4.0 and 4.1 releases
On Wed, 25 Oct 2000, Christopher F. Moran wrote: Hi, How can I find what changes occurred to named as shipped on the 4.1 CDs? on 4.0-RELEASE we could do zone transfers with a Windows 2000 DNS, but putting the same config onto a 4.1-RELEASE machine we can't. I'm guessing something changed, and I need to try and figure out what. 4.0 had 8.2.2-P5, 4.1 has 8.2.3-T5B. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AutoFS on FreeBSD
No, I think he means the kernel VFS layer based AutoFS... ala SUN which was ported to AIX and I'm sure a bunch more platforms.. On Tue, 24 Oct 2000 20:52:22 -0400 you said: On Tue, Oct 24, 2000 at 05:24:06PM -0700, Jim Pirzyk wrote: I was wondering if there is anyone working on AutoFS for FreeBSD. We currently have 4 studios with around 1000 unix systems of all kinds. Currently there are only 2 OSes that do not have autofs, FreeBSD and one that is known for its number crunching capabilties (and those are being phased out of production). Amd will not meet our needs because of the use of sym links. This is why AutoFS was written in the first place. I quote the 1993 USENIX paper on AutoFS (check http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/callaghan.txt for the full paper). Do you mean amd(8)? AMD(8) FreeBSD System Manager's Manual AMD(8) NAME amd - automatically mount file systems ... DESCRIPTION Amd is a daemon that automatically mounts filesystems whenever a file or directory within that filesystem is accessed. Filesystems are automati- cally unmounted when they appear to be quiescent. ... HISTORY The amd utility first appeared in 4.4BSD. BSD April 19, 1994 3 -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message _ Robert Gordon [EMAIL PROTECTED] IP Performance, Inc Austin, Texas. http://www.ipperf.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: named changes between 4.0 and 4.1 releases
Thanks, And for what it's worth there were notes on ISC about a "problem" with IXFR in T5B. T6B fixed it. - Original Message - From: "Mike Silbersack" [EMAIL PROTECTED] To: "Christopher F. Moran" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, October 25, 2000 11:55 AM Subject: Re: named changes between 4.0 and 4.1 releases On Wed, 25 Oct 2000, Christopher F. Moran wrote: Hi, How can I find what changes occurred to named as shipped on the 4.1 CDs? on 4.0-RELEASE we could do zone transfers with a Windows 2000 DNS, but putting the same config onto a 4.1-RELEASE machine we can't. I'm guessing something changed, and I need to try and figure out what. 4.0 had 8.2.2-P5, 4.1 has 8.2.3-T5B. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs. Linux
Don't forget UNIX is a trademark of Open Group. Actually, it's a trademark of USL, licensed to The Open Group. USL is no more, for quite a few years now. I believe that SCO gave the ownership of UNIX trademark to Open Group. The WIPO database shows a GB registration fro X/Open Company Limited. Application numbers are 000227991 and 000431569. This is from the Community Trade Mark Consulatation Service (CTM-Online search engine): http://oami.eu.int/search/trademark/la/en_tm_search.cfm The US-PTO search engine, Trademark Electronic Search System (TESS), appears to be dead right now; it's normally at: http://tess.uspto.gov/bin/gate.exe?f=loginp_lang=englishp_d=trmk The last time I searched there, it was still owned by USL and exclusively licensed. The Canadian online database is still up at: http://strategis.ic.gc.ca/cgi-bin/sc_consu/trade-marks/search_e.pl And a search there yields: REGISTRANT: AMERICAN TELEPHONE AND TELEGRAPH COMPANY, 550 MADISON AVENUE, NEW YORK, NEW YORK 10022, UNITED STATES OF AMERICA CURRENT OWNER: X/Open Company Limited Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, UNITED KINGDOM REPRESENTATIVE FOR SERVICE: SHAPIRO, COHEN P.O. BOX 3440, STATION D 112 KENT STREET, SUITE 2001 OTTAWA ONTARIO K1P 6P1 INTERESTED PARTIES OLD OWNER NOVELL INC., A DELAWARE CORPORATION, 1555 NORTH TECHNOLOGY WAY, OREM UTAH 84057, UNITED STATES OF AMERICA In the U.S., I'm still not sure; the applicable U.S. law implies that there are problems with transfer of ownership, just like transfer of ownership of patents and copyrights (in the U.S., a patent or copyright can not be transferred, only assigned, since there are time limits who clock would otherwise reset, especially for Copyright). In any case, it looks like use of the UNIX trademark is still subject to testing and certification, per: http://www.opengroup.org/testing/checklist/ It's interesting that they require CDE certification, if you want to use the UNIX trademark in association with a workstation, and that you must support their Internet Server Product Registration checklist to use it in association with a server. As an intersting aside, here are registered products by company (note that Caldera isn't lists -- yet, anyway): http://www.opengroup.org/regproducts/company.htm Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining CPU on SMP box
On Tuesday, 24 October 2000 at 7:37:12 -0400, Christopher Harrer wrote: Hello All, Is there a way to determine which CPU I'm currently executing on in a SMP box? I've found references to proc-p_oncpu, but I'm not sure if this is the best way to determine where I'm executing. I'd like to be able to "trace" various actions within my driver and one of the fields I want to keep track of is what CPU I'm executing on. Which version of FreeBSD? 5-CURRENT has the ktr functions, which you could use for your tracing. They include CPU information. Unfortunately we don't have a man page yet. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Interval Timer Question
Greetings, Hackers. This is my first post to -hackers, so forgive me if I'm asking in the wrong list. I've been writing a little program to wait for a specified length of time, then beep on the terminal and exit. I originally made the process wait the specified number of seconds with a call to sleep(3). Once invoked, the program would sit there, not give any indication that it was running, until the interval had passed and it beeped. So I wrote a cheap little twirling baton routine and stuck it into my program. Obviously, the baton won't twirl if the process is sleep(3)ing, so I delved into the manual and came across the setitimer(2) system call. Setitimer takes three arguments: a #define from time.h specifying whether the timer should run in real time, process virtual time, or on the profiling timer; a pointer to a struct itimerval (which contains two struct timevals) which indicates how long the timer should run for and what to do when it runs out; and a pointer to a struct itimerval to store the old value of the timer before setitimer resets it. When the interval timer expires, it sends the process a SIGALRM, the default action for which is to terminate the process. I rewrote my timer program to use setitimer, defining a signal handler for SIGALRM with signal(3), and it worked as I expected. In this version, the process called setitimer, then pause(3)ed until the process received a signal and invoked the signal handler (which beeped the terminal and exited). I then rewrote the program again to include the twirling baton, and this is where things went awry. The baton is a for loop, which putchars an element of the baton, flushes the stdout, write a backspace, and tests to see if we're at the end of the array which stores the -\|/ of the baton and if so, reset the for loop iterator. After adding the for loop, the interval timer I established with setitimer stopped working. I removed the fflush and the backspace, and couldn't get it to work. I can kill -ALRM the process and make it invoke the signal handler, but the setitimer interval timer isn't sending a SIGALRM. I rewrote the program again to use alarm(3) instead of setitimer, and the program works as expected. I am confused as to why setitimer didn't work in this case, but alarm did. The question is: I would like to know the reason why doesn't setitimer work when I invoke this for loop? If someone knows, or at least can give me a pointer to where I can start looking for the answer, that would be great. Maybe I can add something to the setitimer man page to document this gotcha. I can provide source code, either in the list or on a Web page, if it would help anyone so kind as to answer my question. Cheers, William Richard [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
