/usr/include/sys/opt_posix.h missing...?
Hi, In trying to compile driver code which includes unistd.h, the compiler complains: cc -D_KERNEL -Wall -O2 -I/usr/include -o ixj.o -c ixj.c In file included from /usr/include/sys/unistd.h:40, from /usr/include/unistd.h:42, from ixj.c:21: /usr/include/sys/_posix.h:45: opt_posix.h: No such file or directory Sure enough...it isn't there!! Is this breakage? Who needs to be notified regarding this? By the way, this is on: FreeBSD dbm.wireless.net 4.1-STABLE FreeBSD 4.1-STABLE #17: Sun Aug 13 03:19:21 -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: code question...
In message <[EMAIL PROTECTED]>, "Chris Ptacek" w rites: >I am getting a warning from a program I wrote: > >lined in free(): warning: chunk is already free. > >Is there anyway I can figure out where exactly this is happening, maybe >cause a core or something. ln -s A /etc/malloc.conf run your program again... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[2]: how to support adaptec 29160 ?
Hi! DM> On Mon, Aug 14, 2000 at 07:25:42PM +0400, Kazennov Vladimir wrote: >> Please, give me some info about support adaptec 29160 with FreeBSD >> Kernel during installation doesn't recognise this adapter DM> What version of FreeBSD? It should be supported in 4.1. 3.5 But I didn't see in hardware.txt for 4.1 this adapter... DM> David. DM> To Unsubscribe: send mail to [EMAIL PROTECTED] DM> with "unsubscribe freebsd-hackers" in the body of the message Best regards, Kazennovmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re[2]: how to support adaptec 29160 ?
> >> Please, give me some info about support adaptec 29160 with FreeBSD > >> Kernel during installation doesn't recognise this adapter > DM> What version of FreeBSD? It should be supported in 4.1. > But I didn't see in hardware.txt for 4.1 this adapter... gosset% grep 29160 /usr/src/release/texts/HARDWARE.TXT Adaptec 274X/284X/2920C/294x/2950/19160/29160/3940/3950/39160 gosset% uname -a FreeBSD gosset.maths.tcd.ie 4.1-STABLE FreeBSD 4.1-STABLE #0: Fri Aug 4 16:14:25 BST 2000 [EMAIL PROTECTED]:/mnt/obj/usr/src/sys/GOSSET i386 This was from a tree checked out just after the release... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re[4]: how to support adaptec 29160 ?
Hi! >> >> Please, give me some info about support adaptec 29160 with FreeBSD >> >> Kernel during installation doesn't recognise this adapter >> DM> What version of FreeBSD? It should be supported in 4.1. >> But I didn't see in hardware.txt for 4.1 this adapter... DM> gosset% grep 29160 /usr/src/release/texts/HARDWARE.TXT DM> Adaptec 274X/284X/2920C/294x/2950/19160/29160/3940/3950/39160 DM> gosset% uname -a DM> FreeBSD gosset.maths.tcd.ie 4.1-STABLE FreeBSD 4.1-STABLE #0: Fri Aug 4 16:14:25 BST 2000 [EMAIL PROTECTED]:/mnt/obj/usr/src/sys/GOSSET i386 DM> This was from a tree checked out just after the release... Sorry for mistake ;( I see wrong file. Thanks for advise! DM> David. DM> To Unsubscribe: send mail to [EMAIL PROTECTED] DM> with "unsubscribe freebsd-hackers" in the body of the message Best regards, Kazennovmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
What is needed to support i815 in XFree86 4.01?
A friend of mine have just bought a computer with i815 chipset, I want to
convert him to FreeBSD so I need to get X running om his machine with the
builtin graphics on his motherboard.
The graphics part of the i815 chipset is believed to be equal to that of
the i810. Of course the PCI id:s are different so it's not detected by
the new agp driver in 4.1-Stable.
I have the two PCI-ids 1132 and 1130 for the video controller and the
host-to-hub bridge. I have tried to add these in src/sys/pci/pcisupport.c
and src/sys/pci/agp_i810.c but I'm not getting any messages from the agp
driver that it is installed (other than the texts I added).
Can someone tell me how this detection is supposed to work and if there
are more places that must be changed to get enable the graphics controller
XFree86-4.0.1 detects the i815 GMCH so it shoud be fine.
The following function must be rewritten as the id:s are now off by two:
/*
* Find bridge device.
*/
static device_t
agp_i810_find_bridge(device_t dev)
{
device_t *children, child;
int nchildren, i;
u_int32_t devid;
/*
* XXX assume that the bridge device's ID is one minus the vga ID.
*/
devid = pci_get_devid(dev) - 0x1;
if (device_get_children(device_get_parent(dev), &children, &nchildren))
return 0;
for (i = 0; i < nchildren; i++) {
child = children[i];
if (pci_get_devid(child) == devid) {
free(children, M_TEMP);
return child;
}
}
free(children, M_TEMP);
return 0;
}
/Martin
--
_
| o | +---+ +---+ | o |
| | | Martin Nilsson M.Sc. CS&E | |Internet & Intranet| | |
| o | | FILEX AB, Lund SWEDEN | | Applications & shopping. | | o |
| | | email: [EMAIL PROTECTED]| | UNIX, TCP/IP, Perl, C/C++ | | |
| o | | Phone: +46-46-304130 | | SQL dev. & consulting | | o |
| | +---+ +---+ | |
| o |You know the old saying - Any technology sufficiently| o |
| |advanced is indistinguishable from a Perl script | |
| o | - The Camel book p.301| o |
~
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
In article <[EMAIL PROTECTED]>, Jonas Bulow <[EMAIL PROTECTED]> wrote: > John Polstra wrote: > > > I think the ideal solution would first try to lock the > > test-and-set lock, maybe spinning on it just a few times. If that > > failed it would fall back to using a system-call lock such as > > flock() which would allow the process to block without spinning. > > But I don't have any code to do that. (If you write some, could I > > have a copy?) > > I am about to. Actually I thought about this some more, and I'm not all that sure it's possible. I haven't actually _tried_ it, but I think you'd end up needing a low-level mutex around parts of the code. That would have to be implemented as a spinlock, which is exactly what we're trying to avoid in this exercise. > don't know it it's bad design to have rtld.c export > lockdflt_init in the same way as dlopen, what di you think? Right, bad design. :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
I am trying to figure out what to do with my /tmp directory under FBSD 4.1 I noticed that /tmp currently lives on the root file system, where I am unable to get the benefit of softupdates or mounting "nosuid". (Is that true?) The handbook mentions mounting the swap partition on /tmp using the MFS. To quote from http://www.freebsd.org/handbook/kernelconfig-config.html: --- options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device This is the memory-mapped filesystem. This is basically a RAM disk for fast storage of temporary files, useful if you have a lot of swap space that you want to take advantage of. A perfect place to mount an MFS partition is on the /tmp directory, since many programs store temporary data here. To mount an MFS RAM disk on /tmp, add the following line to /etc/fstab: /dev/ad1s2b/tmp mfs rw 0 0 I thought I had read on one of the FBSD mailing lists that the MFS is now basically obsolete. As I understood it, the regular file system has sophisticated caching built in and effectively acts like a memory file system if the files are small enough. Conversely, using the MFS results in two stages of caching and wastes RAM. Is that correct? I noticed Matt Dillon wrote a handbook section on the VM system at http://www.freeBSD.org/handbook/internals-vm.html that includes some info on tuning, but it doesn't mention what to do with /tmp. So what's the bottom line? Should I leave /tmp on the root file system, create a dedicated partition for /tmp, or mount the swap partition on /tmp using the MFS? Thanks, Allen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
OK, here's a note from long ago, when this came up before.
Dated: Tue Jul 2 10:48:16 1996
The idea is simple: tset is the fastest, but you only want to spin so
long. Then you want to drop into the kernel, and wait for someone to wake
you up. This thing was quite fast on freebsd, even four years ago. In fact
I have yet to see anything faster, but I'm willing to be corrected.
--
Here's a simple test-and-set function for the 386 (tested and works):
int
tset(int *i, int lockval, int unlockval)
{
int j = 0;
asm("movl 16(%ebp), %eax");
asm("movl 8(%ebp),%ecx");
asm("movl 12(%ebp),%edx");
asm("cmpxchg %edx, (%ecx)");
asm("jne failed");
asm("movl %eax, -4(%ebp)");
asm("jmp done");
asm("failed: movl %eax, -4(%ebp)");
asm("done:");
return j;
}
This will run a bit faster than a file lock system call :-). But what about
contention? notice that this function, if it fails, fails. so we need a
retry strategy. IF you fail, should you spin forever? NO! Do that, and
you eat the processor doing nothing. You ought to have a reasonable way
to, say, spin one or two more times, then go to a more heavyweight sleep.
SO: here's the fastlock library call (#ifdef USEMOD is for LKM )
void
fastlock(int *address, int lockval, int unlockval)
{
int testval;
#ifdef USEMOD
static int syscallnum = -1;
if (syscallnum < 0)
syscallnum = syscallfind("fastlock");
if (syscallnum < 0) {
perror("fastlock syscallfind");
return;
}
#endif
testval = tset(address, lockval, unlockval);
if (testval == unlockval) {
#ifdef FASTLOCKDEBUG
printf("(%d)fastlock quickout\n", getpid());
#endif
return;
}
/* attempt to lock failed. test then wait in kernel sleep() */
while (1)
{
/* set the high-order bit. This tells the unlocker to do the system
* call and free up the lock.
*/
(void) tset(address, testval|0x8000,testval);
#ifdef FASTLOCKDEBUG
printf("(%d)hang in there\n", getpid());
#endif
/* we should be checking here to make sure that high-order bit is
* set. But this second tset fails only
* in the event of contention, in which case
* someone else has set the high-order
* bit too ... seems pointless, esp. given that fastlock has a timeout
*/
syscall(syscallnum, 1, address, unlockval);
testval = tset(address, lockval, unlockval);
if (testval == unlockval)
return;
}
}
So what are we doing? We're doing the tset. If it fails, then we do one
more tset, to set the high order bit, then drop into the fastlock system
call. Once we return from that, we try to tset the variable again. If
that fails, we drop once again into the system call.
Here's fastunlock:
void
fastunlock(int *address, int unlockval)
{
int dosyscall = 0;
static int syscallnum = -1; /* this is really in the file */
#ifdef USEMOD
if (syscallnum < 0)
syscallnum = syscallfind("fastlock");
if (syscallnum < 0) {
perror("fastunlock syscallfind");
return;
}
#endif
if (*address & 0x8000)
dosyscall = 1;
*address = unlockval;
#ifdef FASTLOCKDEBUG
printf("(%d)fastunlock dosyscall is %d\n", getpid(), dosyscall);
if (dosyscall) printf("conflict %d\n", getpid());
fflush(stdout);
#endif
if (dosyscall)
syscall(syscallnum, 0, address, unlockval);
}
Ok, this one tests to see if it needs to wake any sleepers, clears the
memory variable, then drops into the kernel if needed (if (dosyscall) ...)
Here's the system call. Note several things:
1) the definition of 'unlocked' is passed in to the system call for the
final test, not assumed to be zero.
2) The 'address' argument does NOT NEED TO BE AN ADDRESS. it's a number
that all the procs have to agree on, that is all.
3) if you accidently awake more than one sleeper, the loop in fastlock
handles that properly
4) This system call handles both waking up and sleeping
5) For my measurements, this thing is a whole lot faster than anything
else available on (e.g.) freebsd. Questions to me.
int
fastlock(p, uap, retval)
struct proc *p;
struct flu *uap;
int retval[];
{
extern int hz;
retval[0] = 0;
/*
printf("fastlockunlock: com %d address 0x%x unlocked %d\n",
uap->com, uap->address, uap->unlocked);
*/
if (uap->com == 0) /* unlock */
wakeup((void *) uap->address);
else
{
/* last chance */
/* try one last time to see if it is unlocked */
int curval = fuword((void *) uap->address);
if (curval == uap->unlocked)
return;
tsleep((void *) uap->address, PUSER, NULL, 10*
Re: /usr/include/sys/opt_posix.h missing...?
In message <[EMAIL PROTECTED]> Devin Butterfield writes: : In trying to compile driver code which includes unistd.h, the compiler : complains: #include isn't supported for drivers. You should not be including the -I/usr/include on the command line to compile the driver. If you are building a module, you should be using the bsd.kmod.mk framework to build the modules. include instead. You will also need to create an opt_posix.h in your driver's Makefile: KMOD=ifx SRCS=ifx.c device_if.h bus_if.h opt_posix.h .include should be all you need. You may also need to define SYSDIR as well if you don't have it installed in /usr/src/sys. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
John Polstra wrote: > > In article <[EMAIL PROTECTED]>, Jonas Bulow > <[EMAIL PROTECTED]> wrote: > > John Polstra wrote: > Actually I thought about this some more, and I'm not all that sure > it's possible. I haven't actually _tried_ it, but I think you'd end > up needing a low-level mutex around parts of the code. That would > have to be implemented as a spinlock, which is exactly what we're > trying to avoid in this exercise. What do you mean with low-level mutex? I mean, how low is low? :-) After doing some more thinking about the cmpxchgl-lock, it's quite hard to use it together with a technique involving the kernel. It will be a contradiction in many ways. I would be nice to have kqueue a EVFILT_MEM and wait for the contents of a memory adress contain a specific value (or other condition like threshold, range entrance/leaving). Then it can be used to wait for the adress used with cmpxchgl. Well, this was just thinking for this very moment. > > > don't know it it's bad design to have rtld.c export > > lockdflt_init in the same way as dlopen, what di you think? > > Right, bad design. :-) just cheking.. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
On Tue, 15 Aug 2000, Jonas Bulow wrote: > After doing some more thinking about the cmpxchgl-lock, it's quite hard > to use it together with a technique involving the kernel. well, no I don't think it is. I used to use it a lot, see my earlier post from today. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: localhost cannot be resolved
Hello Alexander, > At the same time fetchmail causes ipfw to produce these messages: > Aug 11 21:41:47 mydomain /kernel: Connection attempt to TCP ::0001:25 from > ::0001:1063 > Aug 11 21:41:47 mydomain /kernel: Connection attempt to TCP 127.0.0.1:113 > from 127.0.0.1:1065 > Aug 11 21:41:47 mydomain /kernel: Connection attempt to TCP ::0001:25 from > ::0001:1066 > Aug 11 21:41:47 mydomain /kernel: Connection attempt to TCP 127.0.0.1:113 > from 127.0.0.1:1067 > These strange things started to happen soon after I cvsup'ed ports-all and > reinstalled libtool. I also compiled firewall support into the kernel a > few days ago. Just in case any of this might be related to the problem. Maybe this question sounds trivial, but do you have identd running (or what exactly is it called in *BSD?)? I don't know if smtp somehow depends on ident, some things do. Tell me if it does(n't). Maybe just rejecting connections to port 113 will suffice? I am not really sure about your previous configuration. Bye, Leonard. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: localhost cannot be resolved
On Fri, 11 Aug 2000, Alexander Anderson wrote: > Hello everyone! > > I sent this question to freebsd-questions, but no one had replied, so I > decided to try my luck here. > > I'm having trouble resolving "localhost" for telnet and fetchmail. All > other programs (ftp, rlogin, rsh, ping, lynx) seem to understand > "localhost". > I "me too"; but telnet can't resolve anything, while the others work. I have a current workstation, which makes world almost every night. It resolves ok. I then have my gateway/ppp/proxy which I regularly updates by nfsmounting /usr/src and /usr/obj from the workstation, and then make installworld. However, something must have happened, because as mentioned telnet won't resolve anything. (And perl 5.6 won't install either...) Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
> On Tue, 15 Aug 2000, Jonas Bulow wrote: > > > After doing some more thinking about the cmpxchgl-lock, it's quite hard > > to use it together with a technique involving the kernel. > > well, no I don't think it is. I used to use it a lot, see my earlier post > from today. One point to keep in mind is that you will get a big win from these approaches in low-contention situations. I've got something that I use in bus simulations. When a client process doesn't get the compare-and-swap lock in a few instructions it has to request it from a master process via a single master-request-FIFO which eventually answers it back through a per-client-response FIFO, continuing the blocked clients in the order that they missed the lock, and using up system calls and context switches to ensure that. Thus when I lose, I lose big time, but it gives me the ordering I want. When I win I wind up with no system calls. Sort of like a cache. If I was losing a lot I'd have to rethink the approach and use something to divy up the work properly. If ordering isn't required and you aren't worried about starvation, it simplifies things a lot because you can have a Linda-like pool of work requests to hand out to a swarm of worker bees. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Digital Technical Journal - zhihui
Kanad: I remember you subscribed some journal a while ago. Was it "digital technical journal?" I found two papers on VAXcluster filesytem design on No. 5, september 1987. If so and you happen to keep that issue, please borrow me for a while. Thanks. Regards, -Zhihui - 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
BOCA BB1008
Interesting problem, I have installed two Boca BB1008 boards for console access to a litter of Sun, HPUX, and AIX servers... I installed/configured one board at a time. At the bottom of this email is the info from dmesg as well as from my kernel. However in the /dev directory it only lists "cuaa0" thru "cuaa11". I have tested out the first card and all the ports work as expectecd, on the second board the first three work great (as expected considering the devices that are available)... however because cuaa12 and above don't exists I can do the normal "cu -l /dev/cuaa12 -s 9600" (or 13, 14, et cetera). I have recompiled the kernel, even did a :make clean" first, any ideas how to automajically create the five devices I am missing? Thanks! /tg KERNEL: --- options COM_MULTIPORT # Needed for Boca 4/8 Port sio boards # Serial (COM) ports #device sio0at isa? port IO_COM1 flags 0x10 irq 4 #device sio1at isa? port IO_COM2 irq 3 #device sio2at isa? disable port IO_COM3 irq 5 #device sio3at isa? disable port IO_COM4 irq 9 device sio1at isa? port 0x100 flags 0xb05 device sio2at isa? port 0x108 flags 0xb05 device sio3at isa? port 0x110 flags 0xb05 device sio4at isa? port 0x118 flags 0xb05 device sio5at isa? port 0x120 flags 0xb05 device sio6at isa? port 0x128 flags 0xb05 device sio7at isa? port 0x130 flags 0xb05 device sio8at isa? port 0x138 flags 0xb05 irq 4 device sio9at isa? port 0x200 flags 0xb05 device sio10 at isa? port 0x208 flags 0xb05 device sio11 at isa? port 0x210 flags 0xb05 device sio12 at isa? port 0x218 flags 0xb05 device sio13 at isa? port 0x220 flags 0xb05 device sio14 at isa? port 0x228 flags 0xb05 device sio15 at isa? port 0x230 flags 0xb05 device sio16 at isa? port 0x238 flags 0xb05 irq 3 --- DMESG: --- sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1 at port 0x100-0x107 flags 0xb05 on isa0 sio1: type 16550A (multiport) sio2 at port 0x108-0x10f flags 0xb05 on isa0 sio2: type 16550A (multiport) sio3 at port 0x110-0x117 flags 0xb05 on isa0 sio3: type 16550A (multiport) sio4 at port 0x118-0x11f flags 0xb05 on isa0 sio4: type 16550A (multiport) sio5 at port 0x120-0x127 flags 0xb05 on isa0 sio5: type 16550A (multiport) sio6 at port 0x128-0x12f flags 0xb05 on isa0 sio6: type 16550A (multiport) sio7 at port 0x130-0x137 flags 0xb05 on isa0 sio7: type 16550A (multiport) sio8 at port 0x138-0x13f irq 4 flags 0xb05 on isa0 sio8: type 16550A (multiport) sio9 at port 0x200-0x207 flags 0xb05 on isa0 sio9: type 16550A (multiport) sio10 at port 0x208-0x20f flags 0xb05 on isa0 sio10: type 16550A (multiport) sio11 at port 0x210-0x217 flags 0xb05 on isa0 sio11: type 16550A (multiport master) sio12 at port 0x218-0x21f flags 0xb05 on isa0 sio12: type 16550A (multiport) sio13 at port 0x220-0x227 flags 0xb05 on isa0 sio13: type 16550A (multiport) sio14 at port 0x228-0x22f flags 0xb05 on isa0 sio14: type 16550A (multiport) sio15 at port 0x230-0x237 flags 0xb05 on isa0 sio15: type 16550A (multiport) sio16 at port 0x238-0x23f irq 3 flags 0xb05 on isa0 sio16: type 16550A (multiport) --- -- --- Timothy Grzechowski[EMAIL PROTECTED] --- GTE Data Services AAIS Engineering, Sys. Admin. --- Office: 813/978-4327 Office FAX: 813/978-6812 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
Peter Dufault wrote: > you can have a Linda-like pool of work requests to hand out to a swarm of worker >bees. ^^^ Could you please decode this for me? :) Thanks, Gary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: BOCA BB1008
> However in the /dev directory it only lists "cuaa0" thru "cuaa11". I > have tested out the first card and all the ports work as expectecd, on > the second board the first three work great (as expected > considering the > devices that are available)... however because cuaa12 and above don't > exists I can do the normal "cu -l /dev/cuaa12 -s 9600" (or 13, 14, et > cetera). > > I have recompiled the kernel, even did a :make clean" first, any ideas > how to automajically create the five devices I am missing? They aren't automagically created. You need to make more yourself. The /dev/MAKEDEV script is normally used but may not do this for you based on my first look at the script - it seems to only make single-digit device numbers. You may have to use mknod by hand after looking at how MAKEDEV makes the first cuaaX devices. Jason Young Access US(tm) Chief Network Engineer > > Thanks! > > /tg > > > KERNEL: > --- > options COM_MULTIPORT # Needed for Boca 4/8 Port sio boards > > > # Serial (COM) ports > #device sio0at isa? port IO_COM1 flags 0x10 irq 4 > #device sio1at isa? port IO_COM2 irq 3 > #device sio2at isa? disable port IO_COM3 irq 5 > #device sio3at isa? disable port IO_COM4 irq 9 > > device sio1at isa? port 0x100 flags 0xb05 > device sio2at isa? port 0x108 flags 0xb05 > device sio3at isa? port 0x110 flags 0xb05 > device sio4at isa? port 0x118 flags 0xb05 > device sio5at isa? port 0x120 flags 0xb05 > device sio6at isa? port 0x128 flags 0xb05 > device sio7at isa? port 0x130 flags 0xb05 > device sio8at isa? port 0x138 flags 0xb05 irq 4 > > device sio9at isa? port 0x200 flags 0xb05 > device sio10 at isa? port 0x208 flags 0xb05 > device sio11 at isa? port 0x210 flags 0xb05 > device sio12 at isa? port 0x218 flags 0xb05 > device sio13 at isa? port 0x220 flags 0xb05 > device sio14 at isa? port 0x228 flags 0xb05 > device sio15 at isa? port 0x230 flags 0xb05 > device sio16 at isa? port 0x238 flags 0xb05 irq 3 > --- > > > > DMESG: > --- > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1 at port 0x100-0x107 flags 0xb05 on isa0 > sio1: type 16550A (multiport) > sio2 at port 0x108-0x10f flags 0xb05 on isa0 > sio2: type 16550A (multiport) > sio3 at port 0x110-0x117 flags 0xb05 on isa0 > sio3: type 16550A (multiport) > sio4 at port 0x118-0x11f flags 0xb05 on isa0 > sio4: type 16550A (multiport) > sio5 at port 0x120-0x127 flags 0xb05 on isa0 > sio5: type 16550A (multiport) > sio6 at port 0x128-0x12f flags 0xb05 on isa0 > sio6: type 16550A (multiport) > sio7 at port 0x130-0x137 flags 0xb05 on isa0 > sio7: type 16550A (multiport) > sio8 at port 0x138-0x13f irq 4 flags 0xb05 on isa0 > sio8: type 16550A (multiport) > sio9 at port 0x200-0x207 flags 0xb05 on isa0 > sio9: type 16550A (multiport) > sio10 at port 0x208-0x20f flags 0xb05 on isa0 > sio10: type 16550A (multiport) > sio11 at port 0x210-0x217 flags 0xb05 on isa0 > sio11: type 16550A (multiport master) > sio12 at port 0x218-0x21f flags 0xb05 on isa0 > sio12: type 16550A (multiport) > sio13 at port 0x220-0x227 flags 0xb05 on isa0 > sio13: type 16550A (multiport) > sio14 at port 0x228-0x22f flags 0xb05 on isa0 > sio14: type 16550A (multiport) > sio15 at port 0x230-0x237 flags 0xb05 on isa0 > sio15: type 16550A (multiport) > sio16 at port 0x238-0x23f irq 3 flags 0xb05 on isa0 > sio16: type 16550A (multiport) > --- > > > > > > > -- > --- > Timothy Grzechowski[EMAIL PROTECTED] > --- > GTE Data Services AAIS Engineering, Sys. Admin. > --- > Office: 813/978-4327 Office FAX: 813/978-6812 > --- > > > 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: /usr/include/sys/opt_posix.h missing...?
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Devin Butterfield writes: > : In trying to compile driver code which includes unistd.h, the compiler > : complains: > > #include > > isn't supported for drivers. You should not be including the > -I/usr/include on the command line to compile the driver. If you are > building a module, you should be using the bsd.kmod.mk framework to > build the modules. include instead. > > You will also need to create an opt_posix.h in your driver's Makefile: > > KMOD=ifx > SRCS=ifx.c device_if.h bus_if.h opt_posix.h > > .include > > should be all you need. You may also need to define SYSDIR as well if > you don't have it installed in /usr/src/sys. You're right. I normally always do this as a module but was experimenting with some other code not using an appropriate Makefile. I still wonder why unistd.h (assuming it is not supported for drivers) would make any reference to a file that does not exist where it was looking? Nevertheless, thanks again for your help. All is fine now...:-) -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /usr/include/sys/opt_posix.h missing...?
In message <[EMAIL PROTECTED]> Devin Butterfield writes: : I still wonder why unistd.h (assuming it is not supported for drivers) : would make any reference to a file that does not exist where it was : looking? It isn't unistd.h, per se. Rather it is in sys/unistd.h, which has to deal with some posix things in the kernel... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization AND threads...
|> you can have a Linda-like pool of work requests to |hand out to a swarm of | worker bees. | ^^^ | Could you please decode this for me? :) This page talks about Linda, check out the "Linda Basics" section and read about tuples. http://www.sca.com/ltutorial.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
re: what to do about /tmp
:basically obsolete. As I understood it, the regular file system has :sophisticated caching built in and effectively acts like a memory file :.. : :I noticed Matt Dillon wrote a handbook section on the VM system at :http://www.freeBSD.org/handbook/internals-vm.html that includes :some info on tuning, but it doesn't mention what to do with /tmp. : :So what's the bottom line? Should I leave /tmp on the root file :system, create a dedicated partition for /tmp, or mount the :swap partition on /tmp using the MFS? : :Thanks, : :Allen What I do is make /tmp a softlink to /var/tmp, and make /var/tmp its own partition. I turn softupdates on on all my partitions, including root (you can do that now) I do NOT use MFS or MD for /tmp, nor do I leave it on /. I keep it as a separate partition and combine it with /var/tmp because both /tmp and /var/tmp tend to be used interchangeably anyway, and /tmp (or /var/tmp) is the most likely of all your partitions to get filled up accidently and you don't want that interfering with other things if it happens. Many things use /tmp, so you can wind up with megabytes in it which makes it unsuitable for use with MD and inefficient when used with MFS. Typically I configure my paritions as follows: / 128MB swap(2x main memory, 128MB minimum) /var128MB (minimum, more if using machine for mail/printing) /var/tmp128MB (minimum, more if using machine multiuser) /usr2G /home remainder of disk /tmp softlink to /var/tmp /compat softlink to /usr/compat Even though '/' per say only needs 64MB, having 128MB there is useful. I've seen 64MB / partitions 'fill up' with softupdates turned on when doing an installworld (because softupdates doesn't delete the files being replaced fast enough), and I tend to keep debug kernels sitting around in / as well. I make /usr big (2G) in order to accomodate ports, since /usr/local is part of /usr. The ordering of the partitions is also carefully arranged. The lower sector numbers are the 'faster' sectors on a disk, closer to the outer rim of the disk where transfer rates are much faster. So I put swap there along with the smaller partitions, and put /usr and /home later since those partitions are big enough that you really don't get a uniform performance benefit anyway. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
