Re: Using make to allow parallel operations?
Kris Kirby wrote:
In my project root, I have the following makefile:
SUBDIR = 1 2 3 4 5 6 7 8 9
.include bsd.subdir.mk
Assuming you have an `encode' target that you want to run in parallel;
you need something like:
.for entry in ${SUBDIR}
${entry}.encode__D: .PHONY
@if test -d ${.CURDIR}/${entry}.${MACHINE_ARCH}; then \
${ECHODIR} "=== ${DIRPRFX}${entry}.${MACHINE_ARCH}"; \
edir=${entry}.${MACHINE_ARCH}; \
cd ${.CURDIR}/$${edir}; \
else \
${ECHODIR} "=== ${DIRPRFX}${entry}"; \
edir=${entry}; \
cd ${.CURDIR}/$${edir}; \
fi; \
${MAKE} encode DIRPRFX=${DIRPRFX}$${edir}/
.endfor
par-encode: ${SUBDIR:S/$/.encode__D/}
(Taken from src/Makefile.inc1)
By having all the subdirs as dependencies for the par-encode target,
make will start doing them in parallel.
@for prog in ${OBJ} ; do \
${PROG} ${PAF}/$$prog ; \
done
I am thinking that the for loop is not the way to run things parallel,
but I see no other option. This is a batch MP3 encode, not a compling
run, but the concepts are similar (programs and thier arguments).
Correct. The for-loop is expanded before any targets are made. That's
why the normal use of SUBDIR is non-parallel; it's used in a for-loop.
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
pccard disruptions : how did it go?
Hello All, I've just scoured the archives, and found a thread from late October 1999 titled: Massive pccard disruptions to continue So, have these disruptions continued? And what is the current status with pccard support in the kernel? I've noticed that a few files still contain the PCCARD_MODULE macro - in particular, the dev/pccard/if_xe.c Xircom driver. I'm interested in getting the if_xe.c driver to work under -current (12-Dec sources). I'd be interested in any ideas on how to convert the old if_xe.c driver to the 'newbus' code. (I'm not familiar with either the old PCCARD_MODULE, or the newbus code.) Regards, Mike Kennett ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard disruptions : how did it go?
In message [EMAIL PROTECTED] Michael Kennett writes: : I've just scoured the archives, and found a thread from late October 1999 : titled: : Massive pccard disruptions to continue : : So, have these disruptions continued? And what is the current status with : pccard support in the kernel? The new pccard code is still being worked on. However, the old pccard code mostly works again, modulo a couple of if_detach issues that I'm trying to work through. : I've noticed that a few files still contain the PCCARD_MODULE macro : - in particular, the dev/pccard/if_xe.c Xircom driver. I'm : interested in getting the if_xe.c driver to work under -current : (12-Dec sources). I'd be interested in any ideas on how to convert : the old if_xe.c driver to the 'newbus' code. (I'm not familiar with : either the old PCCARD_MODULE, or the newbus code.) The if_xe and if_fe drivers no longer work for pccard. You may wish to investigate how the ep and ed drivers were converted. There is one issue with the if_xe driver, namely it needs to access the CIS of the card to determine which kind of card it is and that will need some work in -current to get working again... I can provide support for this effort, but I'm not sure that I have time to do this effort. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using make to allow parallel operations?
Kris Kirby wrote: I am attempting to start a program on a impromptu cluster, one program per machine. I am using make, and seq from the cluster-it package in the ports collection. My problem is that make doesn't start the jobs parallel, it just goes from one to the other. Have you explored pmake, in ports/devel? I use it at work on a large farm of Sun Ultra servers and workstations and it works quite well there. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard disruptions : how did it go?
Warner Losh writes: | In message [EMAIL PROTECTED] Michael Kennett writes: | : I've just scoured the archives, and found a thread from late October 1999 | : titled: | : Massive pccard disruptions to continue | : | : So, have these disruptions continued? And what is the current status with | : pccard support in the kernel? | | The new pccard code is still being worked on. | | However, the old pccard code mostly works again, modulo a couple of | if_detach issues that I'm trying to work through. | | : I've noticed that a few files still contain the PCCARD_MODULE macro | : - in particular, the dev/pccard/if_xe.c Xircom driver. I'm | : interested in getting the if_xe.c driver to work under -current | : (12-Dec sources). I'd be interested in any ideas on how to convert | : the old if_xe.c driver to the 'newbus' code. (I'm not familiar with | : either the old PCCARD_MODULE, or the newbus code.) | | The if_xe and if_fe drivers no longer work for pccard. You may wish | to investigate how the ep and ed drivers were converted. There is one | issue with the if_xe driver, namely it needs to access the CIS of the | card to determine which kind of card it is and that will need some | work in -current to get working again... I will try to take a look at the Xircom driver and try to newbus it after I finish some work on the Arionet driver (It's annoying have to deal with non robust dongles and then I don't have to carry a modem 2 ethernet adapters). However, Linksys has an interesting card .. unfortunately you can't stick 2 of them in at the same time. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ncr scsi timeout
L.S. The kernel hangs (rather an endless loop) with messages like: ncr0: timeout nccb=0xc0c38000 if I attach a fujitsu M2513A2 640MB MO drive. From a quick glance in the ncr source it seems there's a problem with the script stuff in case of a timeout. Anyway, this doesn't happen with either the obsd or linux ncr driver (both derived from the fbsd one I believe), so that may provide some info for whoever maintains this driver. Please mail me with suggestions or pacthes to try out as I need the MO drive. Regards, Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCI/ISA device name
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED] Be sure to reply to that address. Hello, My driver support ISA/PCI network boards. Can I use the same name for ISA and PCI devices in kernel configuration file? Like this: device wanpipe0 at isa? ... # for ISA device wanpipe0 # for PCI In files.i386 I added: i386/isa/sdladev.c optional wanpipe device-driver Or this is can be cause for some problem? Thank you Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Major device number
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED] Be sure to reply to that address. Hello, How can I choose major device number for our network adapter driver? Thank you, Alex Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ncr scsi timeout
The kernel hangs (rather an endless loop) with messages like: ncr0: timeout nccb=0xc0c38000 if I attach a fujitsu M2513A2 640MB MO drive. From a quick glance in the ncr source it seems there's a problem with the script stuff in case of a timeout. Anyway, this doesn't happen with either the obsd or linux ncr driver (both derived from the fbsd one I believe), so that may provide some info for whoever maintains this driver. Please mail me with suggestions or pacthes to try out as I need the MO drive. Regards, Wouter You didn't say which version of FreeBSD you're using - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Major device number
This message was sent from Geocrawler.com by "Alex" [EMAIL PROTECTED] Be sure to reply to that address. Hello, How can I choose major device number for our network adapter driver? Network adapters don't have major/minor numbers, so you don't need to do this. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard disruptions : how did it go?
Warner wrote: In message [EMAIL PROTECTED] Michael Kennett writes: : I've just scoured the archives, and found a thread from late October 1999 : titled: : Massive pccard disruptions to continue : : So, have these disruptions continued? And what is the current status with : pccard support in the kernel? The new pccard code is still being worked on. To confirm: The new pccard code contains the `controller pccard' config directive. - the source code is in sys/dev/pcic sys/dev/pccard The old pccard code contains the `controller card' config directive. - the source code is in sys/pccard Is this correct ? However, the old pccard code mostly works again, modulo a couple of if_detach issues that I'm trying to work through. : I've noticed that a few files still contain the PCCARD_MODULE macro : - in particular, the dev/pccard/if_xe.c Xircom driver. I'm : interested in getting the if_xe.c driver to work under -current : (12-Dec sources). I'd be interested in any ideas on how to convert : the old if_xe.c driver to the 'newbus' code. (I'm not familiar with : either the old PCCARD_MODULE, or the newbus code.) The if_xe and if_fe drivers no longer work for pccard. You may wish to investigate how the ep and ed drivers were converted. There is one issue with the if_xe driver, namely it needs to access the CIS of the card to determine which kind of card it is and that will need some work in -current to get working again... I can provide support for this effort, but I'm not sure that I have time to do this effort. Thank you for your help. I'm not asking you to do it all, but instead what needs to be done, and in what direction I should be going! I think hacking the xe driver to work with the newbus kludge is less than desirable. Instead, I'd like to aim for support under the new pccard code. However, I've noticed that the file /dev/pcic/i82365_isasubr.c is missing from the Dec 12 -current sources, and compilation fails for `controller pccard'. Regards, Mike Kennett ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ncr scsi timeout
On Thu, Dec 16, 1999 at 00:49:47 +, WHS wrote: Thomas David Rivers wrote: The kernel hangs (rather an endless loop) with messages like: ncr0: timeout nccb=0xc0c38000 if I attach a fujitsu M2513A2 640MB MO drive. From a quick glance in the ncr source it seems there's a problem with the script stuff in case of a timeout. Anyway, this doesn't happen with either the obsd or linux ncr driver (both derived from the fbsd one I believe), so that may provide some info for whoever maintains this driver. Please mail me with suggestions or pacthes to try out as I need the MO drive. Regards, Wouter You didn't say which version of FreeBSD you're using Oops.. It's 3.3 (RELEASE I guess, the oct cdrom). Depending on what sort of NCR board you have, I would suggest trying out the new sym driver, written by Gerard Roudier [EMAIL PROTECTED]. It is located here: ftp://ftp.tux.org/tux/roudier/drivers/freebsd/experimental/ Look at the readme file in that directory to determine whether your board is supported. If you have questions, problems, etc., with the sym driver, contact Gerard. In general, the stock NCR driver isn't being actively maintained, and your problem could be the result of a bug in the driver, or some problem with your MO drive. It's hard to say for sure. Gerard's driver is actively maintained, though, so if you still have problems with his driver, it'll be easier to get the problems fixed. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard disruptions : how did it go?
In message [EMAIL PROTECTED] Michael Kennett writes: : To confirm: : : The new pccard code contains the `controller pccard' config directive. : - the source code is in sys/dev/pcic : sys/dev/pccard : : The old pccard code contains the `controller card' config directive. : - the source code is in sys/pccard : : Is this correct ? Yes. That's right. : Thank you for your help. I'm not asking you to do it all, but : instead what needs to be done, and in what direction I should be : going! I think hacking the xe driver to work with the newbus kludge : is less than desirable. Instead, I'd like to aim for support under : the new pccard code. It is indended attach will be the same, and that probe will nearly be the same, at least at first. The probe code for the drivers will be longer for newcard in that it will have to claim the device if the driver supports it. In the old pccard code probe is just a nice dummy which calls the usual probe routine for its side effects (the sio driver's probe routine leaves the uart in a known state, for example). I've been toying with the idea of having an identify routine which would make it possible to have the same binary for both the old driver and new, but that's not completely settled. I'm slogging through hooking up the newbus routines to the old chip tag stuff. I need to map the rid into the window that they currently return. I also need to figure out how to get the card's address (in card space) mapped with the allocation routines that we have now. Then I move into pccard and convert the chip tag calls into newbus calls. I also need to go through and make sure that the softc/ivars stuff connected and working properly. The pcic is the bridge driver. It will have n children, one per slot. Each slot will have zero or more children drivers based on the cards that are connected. It is intended that we'll support multiple functions in this way. The pccard children devices will have pcic_ivars as their ivars. The children of the pccard children will have pccard_ivars. : However, I've noticed that the file /dev/pcic/i82365_isasubr.c is missing : from the Dec 12 -current sources, and compilation fails for `controller : pccard'. Did you rerun config (or did I botch the commit and not commit conf/files wich removed it)? Oh, looks like my botch sorry about that... fixed. What can you do to help? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solaris 2.7 ufs file systems ...
[redirected to -hackers] On Sunday, 12 December 1999 at 8:34:51 -0500, David Bein wrote: Hi ... I have a PC with triple boot partitions setup, one of which is loaded with Solaris 2.7 (officially called version 7). I am wondering if anyone has any experience directly mounting ufs partitions which Solaris created. It should be pretty straight forward to come up with a modified ufs source to read them (much like ext2fs), but of course figuring out where Solaris keeps the partition tables needed to get at the slices within the partition is apparently a military secret. Can anyone offer any advice on how to go about this? You'll probably find more interested people on -hackers, so I've redirected the message there. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html 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
Re: ncr scsi timeout
Kenneth D. Merry wrote: In general, the stock NCR driver isn't being actively maintained, and your problem could be the result of a bug in the driver, or some problem with your MO drive. It's hard to say for sure. Gerard's driver is actively maintained, though, so if you still have problems with his driver, it'll be easier to get the problems fixed. I'm using a Tekram DC 390U (ncr 875 ultra, not wide) controller which the readme said was supported, so I just compiled a new kernel with the new driver and everything works hunky dory now :-) Thanks. Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ncr scsi timeout
On Thu, Dec 16, 1999 at 02:03:10 +, W.H.Scholten wrote: Kenneth D. Merry wrote: In general, the stock NCR driver isn't being actively maintained, and your problem could be the result of a bug in the driver, or some problem with your MO drive. It's hard to say for sure. Gerard's driver is actively maintained, though, so if you still have problems with his driver, it'll be easier to get the problems fixed. I'm using a Tekram DC 390U (ncr 875 ultra, not wide) controller which the readme said was supported, so I just compiled a new kernel with the new driver and everything works hunky dory now :-) Good, glad to hear it! Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
fixing a catch-22 with getty
(this is on 3.4-RC as of Dec. 11)
Here's the situation -- a lot of modems are brain-dead, and don't do a
full reset when you tell them to (by a DTR drop, with (usually) ATD3)...
The DTE baud rate likes to stay where it was, instead of returning to the
115200 that (my) gettys are expecting. I was hoping to fix this by using
the "ic" init-chat script ability from gettytab -- send it a 115200
"ATS0=1\r" or something, and that's where the problems started... :)
Apparently, the chat scripts like to see a carrier on the line before it
will write to the tty. Tried setting gettytab to impose CLOCAL on the
line, no luck. Went into main.c and added the following to main():
(lines marked with "--")
-- struct termios tmpbmode;
...
...
if (IC) {
if (!opentty(ttyn, O_RDWR|O_NONBLOCK))
exit(1);
setdefttymode(tname);
-- /* create a copy to work with */
-- (void)tcgetattr(STDIN_FILENO, tmpbmode);
-- /* set CLOCAL in the working copy, and tcsetattr() it */
-- tmpbmode.c_cflag |= CLOCAL;
-- (void)tcsetattr(STDIN_FILENO, TCSANOW, tmpbmode);
if (getty_chat(IC, CT, DC) 0) {
syslog(LOG_ERR, "modem init problem on %s", tty);
(void)tcsetattr(STDIN_FILENO, TCSANOW, tmode);
exit(1);
}
-- /* restore the saved copy of the terminal attrs */
-- setdefttymode(tname);
}
if (AC) {
..
(yes, I know it's icky, but it's an experiment.)
This did allow the chat script to work, and the modem did init correctly
at the right baud rate, but now I'm running into the fact that nothing
other than getty can talk to the port (UUCP, kermit, etc.), probably due
to the non-blocking open... A "ps ax" shows the "TT" column with a value
of "c04" with the init script, where it is normally "--" when I just use
the "wait for carrier before becoming active" (blocking open) method.
I DO want it to switch back to the wait-for-carrier way of life after the
init script is finished
I'm going to continue working on this until the wee hours of the morning,
but maybe somebody has some ideas?
thanks - mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
