ADV: Introduction to Marblejar
Take charge of your career by utilizing www.marblejar.com. We offer IT professionals like you all of the services you require to find the most challenging positions in the IT industry. * $500 Signing bonus when you get job through us* Dedicated recruiters to help you identify the best job openings in your skill* Targeted searches that meet your needs* We provide totally privacy on all of your contact information. No one can view your resume without your approval.* Immediate notification anytime a client selects your resume for review.* One short step approval process- upload your resume in less than 5 minutes.Marblejar is full service web based IT recruiting firm. Let us start helping you, login today at www.marblejar.com.Sincerely,John RossProgram ManagerWe respect your time. If you would like to be removed from our mailing list, click on mailto:[EMAIL PROTECTED]?subject=REMOVE and add the email address(es) to remove in your subject line. This message is designed to comply with all U.S. state laws and pending federal legislation regarding electronic mail marketing. You can avoid seeing compliant messages by setting your mail reader to filter messages with "ADV:" at the beginning of the Subject line. Submit questions or comments regarding these matters by clicking on mailto:[EMAIL PROTECTED]?subject=COMPLIANCE. Marblejar LLCManor Oak Two, Suite 2521910 Cochran RoadPittsburgh, PA 15220
how can i wipeout swap pages?
I'm trying to implement wiping of freed swap pages inside swap_pager. I'm using 2.2-branch, here is my thoughts and steps: I have a (starting) block number of swapped page, i know page size, and i know that i have to use some pool of buffers inside kernel. So i get buffer with getpbuf(), then fill in b_data, b_blkno, b_bcount, b_bufsize, b_proc and b_flags fields and call pbgetvp(swapdev_vp,bp) and VOP_STRATEGY(bp). Then i analize error flag in b_flags and call pbrelvp(bp) and relpbuf(bp). This code was copied from getpages/putpages routines, but it hangs kernel and PC. So i misunderstand something and need help. How can i successfully write down some data to the known block number on the known device from the kernel? Or maybe someone can point me where can i find more information on I/O in kernel? Thank you. PS. I've read -current manpages, but they didn't help me much. :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
strange code?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello there!
I've stumbled accross the following in sys/netinet/ip_input.c (v.1.173)
- --- lines 470-477 ---
if (m == NULL) {/* Packet discarded by firewall */
static int __debug=10;
if (__debug >0) {
printf("firewall returns NULL, please update!\n");
__debug-- ;
}
return;
}
What is the meaning of this construct? Isn't it functionally equivalent to
if (m == NULL) { /* Packet discarded by firewall */
printf("firewall returns NULL, please update!\n");
return;
}
Regards,
Alexey.
- --
<->
) May the Sun and Water ( Regards, Alexey V. Neyman
) always fall upon you! ( mailto:[EMAIL PROTECTED]
<->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE71rm49lSeDZjilyARAu7sAKCWGDNMTnMy8NmFPFO9t3dD9fmetQCeN0ON
sHY5niBtHp8C4IO4QDVoOPE=
=0yx6
-END PGP SIGNATURE-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: strange code?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24 October 2001 16:53, Alexey V.Neyman wrote: > What is the meaning of this construct? Isn't it functionally equivalent to Oops, sorry for the post. I haven't noticed `static' there at first glance :\ Regards, Alexey. - -- <-> ) May the Sun and Water ( Regards, Alexey V. Neyman ) always fall upon you! ( mailto:[EMAIL PROTECTED] <-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE71rpw9lSeDZjilyARAvhEAJ43z/Ym3Kbjww/mCBXzgLy5SjejcwCfZELm s8YQS9c7jP08t8OlonVLeEs= =rbBf -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange code?
On Wed, Oct 24, 2001 at 04:53:12PM +0400, Alexey V . Neyman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello there!
>
> I've stumbled accross the following in sys/netinet/ip_input.c (v.1.173)
>
> - --- lines 470-477 ---
> if (m == NULL) {/* Packet discarded by firewall */
> static int __debug=10;
> if (__debug >0) {
> printf("firewall returns NULL, please update!\n");
> __debug-- ;
> }
> return;
> }
>
> What is the meaning of this construct? Isn't it functionally equivalent to
>
> if (m == NULL) { /* Packet discarded by firewall */
> printf("firewall returns NULL, please update!\n");
> return;
> }
No. This is a C syntax issue: if a variable local to a function is
declared as static, this means that it is initialized to the specified
value once at program start, and then its value is preserved across
function calls. That is, the variable does not start over from 10
each time; it starts at 10 at boot time, then with each pass through
this piece of code its value is decremented. At the tenth pass since
boottime, its value reaches 0 and no more warnings are printed out.
G'luck,
Peter
--
This sentence would be seven words long if it were six words shorter.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: domain sockets question (don't laugh)
"Broken pipe" generally means that your socket connection to the server
has either been torn down or hasn't been setup at all. Check to see if
this is really the case, and also check errno (you might get EBADF or
EPIPE depending upon the circumstances).
On Wed, 24 Oct 2001, Anjali Kulkarni wrote:
> Hi,
>
> You have said that reader exits when there is no more data to read, and that
> does not necessarily mean it has read all data being written by writer. And
> if the reader exits before writer finishes sending all data, it will give
> you a broken pipe. You have to either make the no. of bytes being read by
> the reader equal to no. of bytes being written by writer or handle the
> resulting error.
>
> Anjali
>
> - Original Message -
> From: "Kenneth Wayne Culver" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, October 24, 2001 6:52 AM
> Subject: domain sockets question (don't laugh)
>
>
> > While I've been coding for a long time, and am fairly decent at coding in
> > the kernel, I've never really had a chance to get into sockets
> > programming. So I thought I'd write a simple set of programs to see how
> > things work. From what I understand, when you read on a socket, you have
> > to do it in a loop because it won't block and wait for the total amount of
> > data specified, while write will not return until all specified data has
> > been written. My problem is that I've set up a read loop to read in chunks
> > that are the size of the recv/send buffers (16384 bytes) from the socket
> > (until the end of course, when it reads only what's left), then when I
> > write from one program to the socket for the other program to read, the
> > program that's writing exits with the message "broken pipe" while the
> > program that's reading doesn't think there was any error, reads the
> > amount of data it should have read (although I'm not sure if there's any
> > data there). Can anyone tell me what's going on?
> >
> > Ken
> >
> >
-ASR
-
("`-''-/").___..--''"`-._ (\
`6_ 6 ) `-. ( ).`-.__.`)
(_Y_.)' ._ ) `._ `. ``-..-'
_..`--'_..-_/ /--'_.' ,'
(il),-'' (li),' ((!.-'
-
You had mail. Paul read it, so ask him what it said.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
HW question -- can the CPU timeout on accesses to the PCI bus ?
Well, the question is rather simple... i am running some experiments on system with severe load on the PCI bus (basically a router with 4 interfaces trying to forward 2..4 streams of 64-byte packets at 100Mbit/s (i.e. 144kpps on each stream), and from low level timing i notice that the time to access a status register in the card sometimes goes up in the sky (I have measured well over 10us under heavy load, whereas the normal time is in the order of 0.5-1us). 10us is a fairly long time, and while i can explain it easily (there are 4 active cards in the system, each one with a transmit, receive and control engines trying to access the PCI bus -- and there are two bridges between the CPU and the card), i wonder if the CPU can potentially wait forever to get hold of the bus, or it eventually times out. If so, how can i tell that the operation failed ? cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HW question -- can the CPU timeout on accesses to the PCI bus ?
* Luigi Rizzo <[EMAIL PROTECTED]> [011024 14:03] wrote: > Well, the question is rather simple... i am running some experiments > on system with severe load on the PCI bus (basically a router with 4 interfaces > trying to forward 2..4 streams of 64-byte packets at 100Mbit/s (i.e. 144kpps > on each stream), and from low level timing i notice that the > time to access a status register in the card sometimes goes up in the > sky (I have measured well over 10us under heavy load, whereas the > normal time is in the order of 0.5-1us). > > 10us is a fairly long time, and while i can explain it easily (there > are 4 active cards in the system, each one with a transmit, receive > and control engines trying to access the PCI bus -- and there are > two bridges between the CPU and the card), i wonder if the CPU can > potentially wait forever to get hold of the bus, or it eventually > times out. If so, how can i tell that the operation failed ? Rough guess, an NMI? Afaik this is the problem, if the bus hangs it can wedge the CPU unless a higher priority non-masked interrupt somehow makes it across the bus. Afaik this is what a watchdog timer is for. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
fxp patch - bundling receive interrupts
An updated fxp driver patch for bundling receive interrupts, thus saving a noticeable amount of CPU overhead for interrupt processing, can be found at http://www.tel.fer.hr/zec/BSD/fxp/. New features include: - control of microcode parameters through sysctl variables - activation/deactivation of microcode without bringing the interface down - independent control of microcode parameters/activity for each fxp interface instance - new parameter hw.fxp.size_mask - hw.fxp.int_delay is now defined in microseconds, instead of microcode time-counter units The microcode should work on many revisions - if not all - of Intel 8255* chipset, but the BSD driver is currently tested only on 82558-B0, so I would really appreciate any feedback on driver functionality/stability on other chipset revisions. Have fun! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
lots of things (pcic, pccard, ep0) on irq3. Problem ?
I am trying to get two identical 3C589 pc cards working simultaneously on my
laptop. This was accomplished with FreeBSD 4.3 by adding lines like this to
/etc/defaults/pccard.conf :
config auto "ep0" 10
config auto "ep1" 15
(everything else for that cards entry is left the same)
However, this no longer works with FreeBSD 4.4. There are two reasons that
this could be happening:
1. the somewhat arcane changes I show above to pccard.conf are no longer the
way it is done, and I just don't know the _new_ arcane way
2. Somehow, some way, in upgrading from 4.3 to 4.4 on this laptop, I have
developed irq conflicts - maybe 4.4 just arranges things differently.
So in that light, the ONLY ONLY ONLY suspicious thing I see in dmesg is that
a _lot_ of things are using irq3:
pci_cfgintr: 0:19 INTA routed to irq 3
pcic0 ... irq3
pcic1 ... irq3
ep0 ... irq3
Which is odd, since pccard.conf _and_ /etc/rc.conf BOTH tell ep0 to go to
irq10 and ep1 to go to irq15.
The end result ? ep0 works, on irq 3, and ep1 bombs out with the infamous
"No card in database for "(null)"("(null)")
Any help is appreciated. The irq thing looks odd, but given the previous
4.3-era solution to this problem (the pccard.conf configuration shown above)
I would not be surprised if there is some new weird arrangement of the
parameters for that entry that will solve everything.
--joesh
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp patch - bundling receive interrupts
I am not an official FreeBSD commiter, so I can't tell really... Therefore jlemon was in cc: (he is the fxp driver maintainer), so it is his call. Nevertheless, I think this patch needs a little bit more testing - there are many 8255* chipset revisions out there, and as the code is *very* chipset dependent, we should wait for gathering some feedback first from the people testing the driver. Dennis Wong wrote: > Marko, > > Is this going to be rolled into -stable anytime soon? > > Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp patch - bundling receive interrupts
On Wed, 24 Oct 2001, Marko Zec wrote: > An updated fxp driver patch for bundling receive interrupts, thus saving > a noticeable amount of CPU overhead for interrupt processing, can be > found at http://www.tel.fer.hr/zec/BSD/fxp/. New features include: I haven't reviewed the code and don't have a fxp near, but your patch sounds impressive. I'm sure we'd all be proud of its inclusion in -stable once enough testing has been performed. That being said, I thought I should check on one thing: In your original post, you mentioned that these techniques came from the linux drive for these cards. In the process of writing this patch, did you copy any section of code from the Linux driver? If possible, it would be best to avoid any GPL entanglements. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp patch - bundling receive interrupts
Mike Silbersack wrote: > That being said, I thought I should check on one thing: In your original > post, you mentioned that these techniques came from the linux drive for > these cards. In the process of writing this patch, did you copy any > section of code from the Linux driver? If possible, it would be best to > avoid any GPL entanglements. I used the microcode from Intel's proprietary Linux driver, which is definetely not GPL'ed. I'm not nearly a copyright expert, but it seems to me that Intel put a BSD-like copyrihght on mentioned sources. Intel's copyright is included in rcvbundle.h, so I hope some of BSD "legals" can check on that, and if in any doubt the simplest thing to do would be asking Intel for their position before including the code in a official distributon. Marko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
C++ code in the FreeBSD kernel
Has anyone out there tried to get C++ code running in the freebsd kernel (like as a .ko)? I have a piece of code that I got working in userland, and would like to port it in the kernel (I had anecdotal evidence that it worked). The major problem is that the library, when in kernel, uses a whole bunch of kernel specific routines (not surprisingly), some of which are inline C functions. I believe it will be necessary to define _KERNEL in order to get all this to work correctly, but having that flag enabled causes code to be compiled which is not C++ friendly (functions with variable names "new", implicit type casts from void*... things that are ok in C but not in C++). I am also investigating the possibility of tweaking compiler options in such a way to allow these sorts of errors / warnings to be ignored. If anyone has any experience and advice for this situation, I would love to hear it! Thanks! Denis Serenyi Please cc me as I am not on this mailing list. I didn't find anything in the archives on this topic, but I apologize if it has been beaten to death. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: C++ code in the FreeBSD kernel
On Wed, Oct 24, 2001 at 03:28:25PM -0700, Denis Serenyi wrote: > Has anyone out there tried to get C++ code running in the freebsd kernel > (like as a .ko)? I have a piece of code that I got working in userland, have a look at what the Click team did http://www.pdos.lcs.mit.edu/click/ they have a kernel version of Click for FreeBSD. cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HW question -- can the CPU timeout on accesses to the PCI bus ?
> Well, the question is rather simple... i am running some experiments > on system with severe load on the PCI bus (basically a router with 4 interfac > es > trying to forward 2..4 streams of 64-byte packets at 100Mbit/s (i.e. 144kpps > on each stream), and from low level timing i notice that the > time to access a status register in the card sometimes goes up in the > sky (I have measured well over 10us under heavy load, whereas the > normal time is in the order of 0.5-1us). > > 10us is a fairly long time, and while i can explain it easily (there > are 4 active cards in the system, each one with a transmit, receive > and control engines trying to access the PCI bus -- and there are > two bridges between the CPU and the card), i wonder if the CPU can > potentially wait forever to get hold of the bus, or it eventually > times out. If so, how can i tell that the operation failed ? The PCI arbitrator should never allow the system to livelock in that fashion. Furthermore, since the cards will eventually run out of descriptors/buffer space and require CPU intervention, you'll never hit that situation. And no, the CPU will not time out; it will block until it can get the bus. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp patch - bundling receive interrupts
On Wed, 24 Oct 2001, Marko Zec wrote: > The microcode should work on many revisions - if not all - of > Intel 8255* chipset, but the BSD driver is currently tested only > on 82558-B0, so I would really appreciate any feedback on driver > functionality/stability on other chipset revisions. Chalk up another 82558B that it works on. I started using it shortly after you mentioned this patch a couple of days ago and haven't experienced any problems. While doing a large file transfer between two FreeBSD boxes, performance definately did not suffer. I got 11MB/sec over FTP. When communicating with a Windows NT server over SMB, though, performance was bad (max 1.2MB/sec). I haven't yet checked to see if this is because of the interrupt coalescing or if it is just because Windows sucks. I did notice a 33% decrease in interrupts (if about 900 packets came in, about 600 interrupts were generated), so it definately worked. If I get real brave I might try it on my router which has mostly 82558B's but also an 82559 or two. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp patch - bundling receive interrupts
In article [EMAIL PROTECTED]> you write: >I am not an official FreeBSD commiter, so I can't tell really... >Therefore jlemon was in cc: (he is the fxp driver maintainer), so it is >his call. >Nevertheless, I think this patch needs a little bit more testing - there >are many 8255* chipset revisions out there, and as the code is *very* >chipset dependent, we should wait for gathering some feedback first from >the people testing the driver. I have a updated driver that contains a modified version of Marko's patch here that I'm testing, hopefully I'll have time to commit it tonight. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
spkr(4) and platform independence
Has anyone enumerated the hardware platforms that the spkr(4) device works on? And for those platforms where it doesn't work, are there suggestions for (and documentation on) alternative interfaces? --lyndon >What about all the people who hoarded tonnes of spam in their bunkers? I hoard spam on my hard drive. When I heard about the coming Y2K worries, I downloaded a lifetime supply from the net. -- Charlie Gibbs in alt.folklore.computers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
On Tue, Oct 23, 2001 at 07:45:11PM +0200, Gerhard Sittig wrote: > > I get the feeling this - inappropriate - setting of a _program > variable is due to my misguided suggestion in PR conf/20202 > which verbatimly made it into the FreeBSD start scripts. If it > doesn't fit the usual rules feel free to correct it! :) After > all I was a newbee to FreeBSD then (and still I'm not a guru or > seasoned hacker:) as well as I understand Darren to do his > daytime job with SunOS / Solaris and since he might need some > hints on how his software fits even better into FreeBSD. I guess > he will happily accept patches improving a wrong approach. > > Maybe there's need for the following parts: > - ipfilter_program > - ipfilter_prerules_flags > - ipfilter_rules > - ipfilter_postrules_flags > ? The current situation comes from the fact that I wanted to > have a single variable with the rules file only - to check for > its existance (if such an additional constraints check matters). Done. I tested on my -current (compiled on Oct 22) the patch you can find at http://labs.gr/~charon/patches/diff.04.ipf-rc-U It is functionally equivalent to our current rc.network behavior, but it uses the variables you proposed, and it moves all the flags out of all the XXX_program variables. Comments on this are more than welcome... -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NO_AWK
NOTE: THIS IS A STRAWMAN PROPOSAL! Take it all with a grain of salt! For a long while now I've been running with the bwk version of awk in preference to the GNU gawk shipped in the base OS. Nothing has broken as a result of the change, therefore I'm starting to wonder if a NO_AWK macro for make.conf might not be appropriate. The change hasn't broken any of my buildworld's since the beginning, although a naked buildworld without any awk present will certainly fall over hard. Regardless, I would like to float (and ONLY that) the question of adding a NO_AWK macro to make.conf. It can be done in a way that will not break a bootstrap buildworld, yet still allow a third-party awk to be installed into the production system, and I have a(n almost complete) set of patches to submit that accomplish this. So the question is: is there interest? If so, I'll put the patches up (only against STABLE for now I'm afraid) for review. --lyndon The Web site you seek Cannot be located but Countless more exist. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
GCC/G++ links
[ On a related somewhat anti-GNU thread ... ] 18 months ago we had a conversation on the mailing list about g77 vs. f77 as the canonical command name for the FORTRAN compiler. The crux of the argument was that f77 was the canonical BSD name for the command, and that's what it has been since. There was a related argument as to whether gcc (as a name) should die as well, but the argument was made that too many third party packages would break as a result. For the last year I've been running my systems with the gcc and g++ links to the respective binaries removed, and I haven't seen much break as a result, other than a (very) few ports which were fixed with a quick edit of their Makefile. Meanwhile, it has been useful to install different versions of the GNU C compiler, and in those cases it has also been useful to call them by their real names: gcc and g++. Practical experience shows that cc and gcc can live side-by-side. And also shows that the base OS environment lives well without the GNU naming conventions. Based on this, what do you think about adding a NO_GNU_COMPLER_CMD_LINKS macro to make.conf? If set, if would prevent the linking of cc -> gcc and c++ -> g++, freeing up /usr/local/bin/g* for the site to decide? (And I'm not tied to that horribly long macro name, either.) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
In article <[EMAIL PROTECTED]> you write: >Done. I tested on my -current (compiled on Oct 22) the patch you can >find at http://labs.gr/~charon/patches/diff.04.ipf-rc-U >It is functionally equivalent to our current rc.network behavior, but >it uses the variables you proposed, and it moves all the flags out of >all the XXX_program variables. > >Comments on this are more than welcome... Hmm, yesterday I submitted a PR (conf/31482) with -stable and -current patches (for rc.conf.5 too) doing almost the same cleanup. I'm happy to see I'm not the only one who wants to see some cleanups (including bugfixes) to the ipfilter /etc/rc.* code and manual pages :). Arjan -- Arjan de Vet, Eindhoven, The Netherlands <[EMAIL PROTECTED]> URL: http://www.iae.nl/users/devet/ <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fiskars UPS
Hello, We are using from 1993 Fiskars UPS 0.8 A UPS unit (Type UPS 1008A- 10EU, PartNo: 10 02 891 Rev A1, SerNo: 119355 9345, Made in Finland) and few days ago the Battery failure control light started blinking. We replaced accus (5 pcs 12V 4Ah) and we charged them for 48 hours but the control light is still blinking. Do you have any advice what to do? Where it is possible to get the electrical plans of this unit? I would be grateful for any help. Regards Marjan Mihelin Assoc. Prof. Marjan Mihelin, Ph.D. !!! AGAIN NEW TELEPHONE NUMBERS University Medical Centre University Institute of Clinical Neurophysiology Ljubljana - SLOVENIA tel: +386-1-522-4730, fax: +386-1-543-1533 E-mail: [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[Fwd: colisions!]
i have the follow problem: i use etinc in one FreeBSD box (4.2). it works fine. this freebsd make bridge (one interface in switch), and another cross over to router. in the conection to router, there are one colision led, that are almost always up! i did put one rule for bridge only ip in rl0 (switch interface). why there are colisions betwen etinc and router??? the etinc interface are 10Mbps (half-duplex) and router too. the cross over is: etinc 12 orange/white 3 6 blue/white router 1 2 blue/white 3 6 orange/white thanks ___ The ISP-WIRELESS Discussion List ___ To Join: mailto:[EMAIL PROTECTED] To Remove: mailto:[EMAIL PROTECTED] Archives: http://isp-lists.isp-planet.com/isp-wireless/archives/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
