Re: i4b: PCBIT PCI card support
> Until some time ago I had a regular modem dial-up connection to my ISP, which > was recently upgraded to a ISDN 64k connection. > Along with the ISP ISDN Pack I purchased came a PCBIT PCI TigerJet Tiger300 > ISDN card which works perfectly under Linux with ippp and the HiSAX module > (loaded with these settings: insmod hisax type=20 protocol=2 id="HiSax"). > > Just out of pure curiosity, I ordered FreeBSD-4.0 from freebsdmall a couple of > weeks ago and it arrived earlier this week. > After installing, reading the docs and lots of other stuff, I came to the sad > conclusion that i4b does not support my ISDN card. This card is not supported under i4b. Docs for the Tiger300 chip are available on request from the mailaddresses given in http://www.tjnet.com. I'd be happy to include a driver into i4b in case somebody would write one. hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dutchmen at LinuxTag
Who of our dutch FreeBSD fellows were present at LinuxTag (LinuxDay in Germany) recently, spreading the word for FreeBSD? I have got a positive response of a Linux addict who said that these guys were very friendly, and he was considering buying a FreeBSD CD and using it in a webserver environment. But 90 Deutsch Marks OTOH was too expensive to him. (I'm feeling to be obligued to send him a complimentary copy of one of my 4.0 FreeBSD CDs). -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dutchmen at LinuxTag
[moving from -hackers to -advocacy] On Thursday, 6 July 2000 at 10:10:59 +0200, Christoph Kukulies wrote: > > Who of our dutch FreeBSD fellows were present at LinuxTag (LinuxDay in > Germany) recently, spreading the word for FreeBSD? > > I have got a positive response of a Linux addict who said that > these guys were very friendly, and he was considering buying a FreeBSD > CD and using it in a webserver environment. But 90 Deutsch Marks OTOH was > too expensive to him. (I'm feeling to be obligued to send him a > complimentary copy of one of my 4.0 FreeBSD CDs). You should contact Pat Reitz <[EMAIL PROTECTED]> and get her to send you some giveaway CDs for the next Linuxtag. We're having a Linux Installfest here in Adelaide next weekend (15th) (see http://www.linuxsa.org.au/meetings/installfest2000/), and BSDi have contributed 200 giveaways, which should be ample. You'll notice it figures quite prominently in the web page. 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
Re: /etc/security -> /etc/periodic/security ?
> > why not even something like security_enable=[YES|NO] and > > security_periode=[daily|weekly|monthly] defaulting to daily? /etc/security is hard-wired in many respects to be run on a daily basis, i.e. it does lots of 'today/yesterday' diff reports. Anyway, I think security reports are important enough that you'd want to be informed daily, at the very least. > That's just what we need - a configuration option that lets the admin > turn security off. 8) :) While we're on the subject of /etc/security, just a few comments/suggestions.. For 'logfile' reports (login failures, kernel messages, refused connections, etc.), I think we should use the 'logtail' program or something similar. This could be run from cron on a frequent [i.e. hourly] basis, coinciding with newsyslog. This way, you don't have to wait for the daily security report to tell you something's wrong, and it should also eliminate duplicated data in reports as each report only shows the 'bad' messages since last run, as opposed to all the bad messages currently in the respective logfiles. [which is what it certainly does on 3.4, anyway] Also, /var/log/kernel [syslog: kern.*] should be used in preference to dmesg as the source of kernel messages, as there's no risk of losing kernel messages that have disappeared from the system message buffer. Better support for ipfw and ipf/ipmon would be nice, but I'd imagine most people just roll-their-own, when it comes to firewall scripts/status reports. -- Cillian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cocaine snorting reported in Michigan, details at 11 (was Re: data corruption)
> > I fully expect to be physically assulted by all who I encounter the > next time I'm in California for this act of stupidity. > Physically assaulted? No, why do that when we can point and laugh? It's legal, and much more devastating. Just noticed you're in Michigan. Are you aware of any Michigan FreeBSD groups? I've been looking around Detroit for a while, and haven't found any. ==ml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BPF and Promiscuous Mode
On Mon, 3 Jul 2000, Nick Rogness wrote: > On Mon, 3 Jul 2000, Dan Nelson wrote: > > > In the last episode (Jul 03), Nick Evans said: > > > How do I set an interface in promiscous mode permanently? In Linux > > > it's simply ifconfig PROMISC. Is there something similar > > > in BSD? Is it somekind of sysctl command? > > Stupid Man's Answer: > > I would just run on bootup: > >/usr/sbin/tcpdump >> /dev/null & > > Probaby not the answer you are looking for, but maybe it will > help. You'll notice a lot of DNS traffic from your machine if you do this. Include -n at least! -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] Bolstered by my success with vi, I proceeded to learn C with 'learn c'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cocaine snorting reported in Michigan, details at 11 (was Re:data corruption)
On Thu, 6 Jul 2000, Michael Lucas wrote: >> >> I fully expect to be physically assulted by all who I encounter the >> next time I'm in California for this act of stupidity. >> > >Physically assaulted? No, why do that when we can point and laugh? >It's legal, and much more devastating. > >Just noticed you're in Michigan. Are you aware of any Michigan >FreeBSD groups? I've been looking around Detroit for a while, and >haven't found any. > >==ml I keep mentioning to bill and others on irc from michigan that someone should start one :p To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf re-write(s), v 0.1
On Mon, 3 Jul 2000, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bill Fumerola writes:
>
> >I'd love to have FreeBSD be able to reclaim memory quicker at the sacrifice
> >of a few cpu cycles. Why? Well, the "add more memory" arguement doesn't work
> >well when I get DoS attacks that will eat any memory available because they
> >can connect quicker then I can reclaim the memory.
>
> I have this dream of a global "VM availability flag":
>
> Imagine if the kernel kept a global variable:
>
> enum {VM_PLENTY, VM_TIGHT, VM_NONE, VM_PANIC} vm_state;
> /* VM_PLENTY: No worries */
> /* VM_TIGHT: Don't make it any worse if you can avoid it */
> /* VM_NONE: Fail if you must, free some if you can */
> /* VM_PANIC: "VM, VM, my panic for some VM" */
>
> At least a few pieces of our memory-gobbling code could examine
> and adjust their caching behaviour from that. Take the vfs
> name-cache as an example:
>
> /* Create a new vfs_name-cache entry */
> cache_enter(...)
> switch (vm_state) {
> case VM_PLENTY:
> /* do as today */
> break;
> case VM_TIGHT:
> /* delete at least as many bytes as we add (LRU wise) */
> break;
> case VM_NONE:
> /* delete two entries, don't add the new one */
> break;
> case VM_PANIC:
> /* delete the entire cache */
> break;
> }
>
> The mbuf allocator can use this to great effect if the various
> MGET() calls were labeled according to their importance.
>
> Respecting such a flag in the various kernels provide great resistance
> against DoS.
>
> User land processes can benefit from this as well: a sysctl would
> allow malloc(3) to investigate this state whenever it had was
> dealing with a full page, and if needed it could release all it's
> cached pages, possibly even call an optional "GC" callback into
> the program to force a realloc(3) sequence in long-running daemons.
> (An alternative scenario is to have a SIGVMSTATE defaulting to
> ignore which gets sent when the variable changes, but that would
> have thundering herd issues if a lot of processes was paged out.)
>
> If only somebody would add that variable, I don't feel like diving
> into the VM system right now.
>
> --
> 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.
I've recently had the chance to get some profiling done.
I used metrics obtained from gprof, as well as the (basic block
length) * (number of executions) metric generated by kernbb. The latter
reveals an approximate 30% increase in the new code, but does not
necessarily imply that time of execution is increased by that amount.
gprof makes a fair estimate on execution time, and reveals that the
new code is, worse case scenario 30% slower, and best case scenario,
negligeably slower. Of course, I'm leaving out some details here, because
I've decided to change things a little, in order to further improve (and
significantly, at that) the performance of the new code. Note however
that the 30% overall APPROXIMATE increase is not something I would
consider significant, especially since the allocator/free routines don't
hold much %time, and are not the bottleneck in any of the call graphs. I
did decide to make drastic changes, however, in order to maintain with
the 0-tolerance policy, even if it involves somewhat getting rid of a
cleaner interface and adopting a "kernel process." See below.
Following your suggestion for vm_state, which I am not about to implement
at this time until I finish this work (so if somebody else wants to take
it up, go ahead; just make sure to let all of us know, in case that we
decide to do it later). However, the planned changes I am going to make
this upcoming weekend to the mbuf code will be aimed at fitting in nicely
with the vm_state stuff. Please note, however, that I am not going to dip
into net code (yet) and begin inserting "good measure" code that will
prevent new PCB allocations depending on vm_state, this is however
extremely useful and should be considered in the near future. What I'm
planning to do, on the other hand, is have the free routine never
explicitly drain pages back to the map. What this means is that there
will be a kernel process which can be awoken optionally when
number_of_allocated_pages is by far exceeding average_allocated_pages
(or, in the future, when vm_state is in a meaningful state). That process
will be responsible for walking the "free list" and draining all pages
associated with "complete" page descriptor structures until hitting
Re: cocaine snorting reported in Michigan, details at 11 (was Re: data corruption)
Out of da blue Adam aka ([EMAIL PROTECTED]) said: > On Thu, 6 Jul 2000, Michael Lucas wrote: > > >> > >> I fully expect to be physically assulted by all who I encounter the > >> next time I'm in California for this act of stupidity. > >> > > > >Physically assaulted? No, why do that when we can point and laugh? > >It's legal, and much more devastating. > > > >Just noticed you're in Michigan. Are you aware of any Michigan > >FreeBSD groups? I've been looking around Detroit for a while, and > >haven't found any. > > > >==ml > > I keep mentioning to bill and others on irc from michigan that someone > should start one :p Well if anyone is ever down East Lansing way, a couple of co-workers and I have an informal group. Everyone is more than welcome to come here or maybe we could meet somewhere in between ... > > i'khala #;^) -- f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng. bush doctor <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf re-write(s), v 0.1
On Thu, 6 Jul 2000, Bosko Milekic wrote: > I've recently had the chance to get some profiling done. > > I used metrics obtained from gprof, as well as the (basic block > length) * (number of executions) metric generated by kernbb. The latter > reveals an approximate 30% increase in the new code, but does not > necessarily imply that time of execution is increased by that amount. > gprof makes a fair estimate on execution time, and reveals that the > new code is, worse case scenario 30% slower, and best case scenario, > negligeably slower. Of course, I'm leaving out some details here, because > I've decided to change things a little, in order to further improve (and > significantly, at that) the performance of the new code. Note however > that the 30% overall APPROXIMATE increase is not something I would > consider significant, especially since the allocator/free routines don't > hold much %time, and are not the bottleneck in any of the call graphs. I > did decide to make drastic changes, however, in order to maintain with > the 0-tolerance policy, even if it involves somewhat getting rid of a > cleaner interface and adopting a "kernel process." See below. You can disregard the above data. I actually found something detrimental (seriously) to performance. During MFREE, the code would free the page in question if at the time the number of mbufs on the free list exceeds (even by a little) min_on_avail. This is fine. The problem was in MGET/MGETHDR where the code would explicitly allocate when how==M_WAIT and number of mbufs on free list < min_on_avail (this was a feeble attempt at making M_NOWAIT allocations even faster). The potential problem is not so obvious: numerous M_WAIT allocs will ALWAYS allocate a page from the map while min_on_avail < mbufs on free lists. And, MFREE would almost ALWAYS have to free back to the map as at this point, the number of mbufs on the free lists fairly quickly reaches min_on_avail. So what would happen is a page would be allocated, freed, allocated, freed, etc. m_get + m_free would be an endless cycle of m_mbmapalloc and m_mbmapfree, which increases overhead significantly. After fixing MGET/MGETHDR, I'm getting more promising results. I'll get some hard data and post it later tonight, hopefully. Oh, and I'm still open to the kernel process idea. I'll need one such beast anyway, because it will help minimize page fragmentation for the allocator, on request. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bridging
Title: bridging Correct me if I am wrong, but isn't bridging of two interfaces supposed to make a duplicate of the traffic from one onto another? Why is it then that on the second interface I bridge to I only see broadcast and multicast packets? I have fxp0 and fxp1 acting as a bridge, fxp0 sees all kinds of http traffic, napster, IM, etc. but fxp1 sees only multi/broadcast packets. any ideas? -- nick.evans network.engineering NextVenue, Inc. phone: (212) 909.2988 pager: (888) 642.5541
Re: bridging
On Thu, Jul 06, 2000 at 12:13:07PM -0400, Nick Evans wrote: > Correct me if I am wrong, but isn't bridging of two interfaces supposed to > make a duplicate of the traffic from one onto another? Why is it then that > on the second interface I bridge to I only see broadcast and multicast > packets? I have fxp0 and fxp1 acting as a bridge, fxp0 sees all kinds of > http traffic, napster, IM, etc. but fxp1 sees only multi/broadcast packets. Bridging will only bridge unicast packet's who's destination MAC adress is on the other side of the bridge. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stray interrupts in 4.0
>> >> We're seeing lots of "stray" interrupts in 4.0 while running 3.4 on the >> >> same hardware reports nothing. The interrupt its complaining about is IRQ7 >> >> even though parallel port is disabled and no other device. It happens on >> >> more than 1 MB. [snip] > >Generally this message indicates that you have hardware in the system >that is not signalling interrupts correctly. great, so intel doesnt know how to make MBs with their own parts...so how can the message be turned off. Its using more resources printing the message thsn the "stray interrupts" themselves. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[Fwd: Re: Cant build 3.5-stable?]
Reports about this are getting more frequent, FYI. Original Message Subject: Re: Cant build 3.5-stable? Date: Thu, 06 Jul 2000 11:36:16 -0400 From: Daniel Frazier <[EMAIL PROTECTED]> Organization: Magpage Internet Services To: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> Adam wrote: > > I am trying to build 3.5-stable on a 3.4-stable system of about two > months old. /usr/src/UPDATING is empty. Can anyone throw a clue or patch > my way? > Sorry Adam, can't help you. CVSupped last night. make buildworld is dying for me at exactly the same point. I hope this gets fixed soon. ===> libfetch compile_et /usr/src/lib/libfetch/fetch_err.et cc -O -pipe -I. -Wall -pedantic -DNDEBUG -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/lib/libfetch/fetch.c -o fetch.o In file included from /usr/src/lib/libfetch/fetch.h:34, from /usr/src/lib/libfetch/fetch.c:39: fetch_err.h:6: com_right.h: No such file or directory In file included from /usr/src/lib/libfetch/fetch.h:34, from /usr/src/lib/libfetch/fetch.c:39: fetch_err.h:8: warning: `struct et_list' declared inside parameter list fetch_err.h:8: warning: its scope is only this definition or declaration, fetch_err.h:8: warning: which is probably not what you want. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. -- Daniel Frazier <[EMAIL PROTECTED]> Tel: 302-239-5900 Ext. 231 System Administrator Fax: 302-239-3909 MAGPAGE, We Power the Internet WWW: http://www.magpage.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bridging
At 12:13 PM 7/6/00 -0400, Nick Evans wrote: > > Correct me if I am wrong, but isn't bridging of two interfaces supposed to > make a duplicate of the traffic from one onto another? Why is it then that on > the second interface I bridge to I only see broadcast and multicast packets? > I have fxp0 and fxp1 acting as a bridge, fxp0 sees all kinds of http traffic, > napster, IM, etc. but fxp1 sees only multi/broadcast packets. Bridges only forward traffic that it thinks it need to...broadcasts, TO known devices and TO unknown devices.It doesnt forward traffic that it knows is destined for the local network. dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bridging
(* On Thu, Jul 06, 2000 at 12:13:07PM -0400, Nick Evans wrote: (* > Correct me if I am wrong, but isn't bridging of two interfaces supposed to (* > make a duplicate of the traffic from one onto another? Why is it then that (* > on the second interface I bridge to I only see broadcast and multicast (* > packets? I have fxp0 and fxp1 acting as a bridge, fxp0 sees all kinds of (* > http traffic, napster, IM, etc. but fxp1 sees only multi/broadcast packets. (* (* Bridging will only bridge unicast packet's who's destination MAC adress is (* on the other side of the bridge. How about RIP? I recently tried to upgrade my FreeBSD 4.0 bridging-firewall to CURRENT and I could no longer get RIP packets through (reliably) (even with no rules and "DEFAULT_TOACCEPT") and had all kinds of routing problems... Routers could not learn the route out because RIP was not going through. Of course I backed back off to 4.0-RELEASE and life was good again... I sent in a PR but have not heard anything yet. Advice? Thanks -- | Ted Wisniewski INET: [EMAIL PROTECTED] | | Computer Services [EMAIL PROTECTED] | | Plymouth State College [EMAIL PROTECTED] | | Plymouth NH, 03264 HTTP: http://oz.plymouth.edu/~ted/ | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
UPS Daemons
I know that APC SmartUPS and BackUPS are supported under FreeBSD but what about the APC PowerStack? I was looking at the APC PowerStack 250 Rackmount UPS. It comes with a RS-232 cables and supports that same kind of emergency shutdown that the SmartUPS systems have. Anybody use a PowerStack? I would only use if I knew that I could tie it in to FreeBSD for automatic shutdown when battery power is used up. -john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf re-write(s), v 0.1
:... :> What was previously done at some point was use the kernel malloc() to :> allocate mbufs. As you know, this is a general purpose allocator that has :> to first determine what algorithm to use and then store the object :> correctly according to its size. This allocator is faster than that :> one. This allocator knows that it only has to deal with mbufs and knows :> that all of these mbufs are of the same size. : : Yes, malloc is slow for other reasons, but it is especially slow when VM :pages are freed back to the general pool. Of course it is possible to :introduce hysteresis in the algorithm such that it doesn't free the pages as :often, but this (and all the tunables that you proposed) has the negative :effect of making the allocator more complex. We've tried very hard not to do :this in the current mbuf allocator, making it nearly as efficient as you can :get. : I guess I just don't see the problem on any of the servers that I manage :(ftp.cdrom.com and ftp.freesoftware.com, for example). There are peaks in :usage, but they tend to reach the peaks often enough that freeing the pages :for short term memory gain is just a waste of CPU cycles. Memory is so cheap :these days that throwing memory at the problem seems to be a very reasonable :solution, especially when the system clearly needs it during the peaks. : :-DG : :David Greenman Our userland malloc() has been quite successful using MADV_FREE to 'release' free pages without actually releasing them. The system would reclaim the pages only when it needed them. We might be able to do something similar for our kernelland malloc, though at the moment I don't see much of a point (it seems fast enough to me and I don't see much wasteage either). -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stray interrupts in 4.0
On Thu, 6 Jul 2000, Dennis wrote: > great, so intel doesnt know how to make MBs with their own parts...so how > can the message be turned off. Its using more resources printing the > message thsn the "stray interrupts" themselves. > > DB Well, it stops after 5 messages or so, just ignore it. Actually, one of my systems stopped doing it a few months back, I have no clue why. Either way, I wouldn't worry about it. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cocaine snorting reported in Michigan, details at 11 (was Re: data corruption)
On Thu, Jul 06, 2000 at 08:46:10AM -0400, Michael Lucas wrote: > > I fully expect to be physically assulted by all who I encounter the > > next time I'm in California for this act of stupidity. > > Physically assaulted? No, why do that when we can point and laugh? > It's legal, and much more devastating. > > Just noticed you're in Michigan. Are you aware of any Michigan > FreeBSD groups? I've been looking around Detroit for a while, and > haven't found any. There was talks of starting a Southeastern Michigan group, but most of us around here are too lazy to actually do it. -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Southeast MI users' group (was re: cocaine snorting in Michigan)
> > There was talks of starting a Southeastern Michigan group, but most > of us around here are too lazy to actually do it. > I'll take on the job of attempting to coordinate a Southeast Michigan users' group. If anyone's interested, email me. Perhaps the Royal Oak or Farmington Hills area? They're somewhat central, with any number of decent restaurants/bars/whatnot for an initial meeting. Followups to, uh, -advocacy, I suppose. ==ml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cocaine snorting reported in Michigan, details at 11 (was Re: data corruption)
[ moved to -advocacy from -hackers ] On Thu, Jul 06, 2000 at 11:51:29AM -0400, Bush Doctor wrote: > > I keep mentioning to bill and others on irc from michigan that someone > > should start one :p > Well if anyone is ever down East Lansing way, a couple of co-workers > and I have an informal group. Everyone is more than welcome to come > here or maybe we could meet somewhere in between ... There's also a large OpenBSD assembly of people at UofM. -- Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Max DMA size
Can anyone tell me what factors determine the max DMA size (DMA counter on each controller or PCI bus related)? What is the typical max DMA size for a SCSI disk connected to a PCI bus? It seems to be much larger than MAXPHYS (128K). If so, does it mean we are not using full potential of DMA? So what's the problem if we enlarge MAXPHYS? Any help is appreciated. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Max DMA size
> > Can anyone tell me what factors determine the max DMA size (DMA counter on > each controller or PCI bus related)? What is the typical max DMA size for > a SCSI disk connected to a PCI bus? It seems to be much larger than > MAXPHYS (128K). If so, does it mean we are not using full potential of > DMA? So what's the problem if we enlarge MAXPHYS? You can enlarge MAXPHYS, but watch out that you don't also then make MAXBSIZE so big that the creation of buffers eats up all of your memory. IMO MAXPHYS is way too small, but there are a number of current VM implementation reasons why making it larger by default is not right. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Learning
I am interested in learning about the freebsd operating system, I dont have very much exerience yet but I am motivated to learn. I have poked around other OS but have found them unappealing to my interest, I like the concept of free source systems like linux and have played with SUSE a little but found the limited availability of learning materials in english a hinderance. I have downloaded and printed the manual as of page 34 where I came upon your invitation I decided to reach out and touch someone. I woud like some quick advice as to what version I should install via ftp to begin my learning, and what would be the best path to follow. I am particularily interested in learning to program in an acceptable language and want to concentrate on network protocols and reliable secure communications, as well as network security and firewalls. Thank you for any advice that you can offer. Arnold Murphy [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Max DMA size
On Thu, Jul 06, 2000 at 15:51:34 -0400, Zhihui Zhang wrote: > > Can anyone tell me what factors determine the max DMA size (DMA counter on > each controller or PCI bus related)? What is the typical max DMA size for > a SCSI disk connected to a PCI bus? It seems to be much larger than > MAXPHYS (128K). If so, does it mean we are not using full potential of > DMA? So what's the problem if we enlarge MAXPHYS? > > Any help is appreciated. MAXPHYS determines the size of struct buf, which at the moment determines the maximum size of a given DMA transaction to a SCSI controller. Typical modern SCSI controllers can handle much more than MAXPHYS data (currently 128K) at a time. An exception is the Adaptec 154x controllers, which can only handle about 64K of data. (Thus the reason I/O through the CAM passthrough interface is limited to 64K instead of the full 128K. We will have that limitation until we implement a way of determining the maximum DMA size allowable for a given controller.) However, as Matt said, you have to be careful about increasing MAXPHYS too much, since you could end up allocating too much memory. I think a better approach to increasing the amount of data that can be sent at one time to a SCSI controller would be to implement some sort of buffer chaining scheme. Most SCSI controllers can do scatter/gather DMA, and CAM has facilities for it, so that would probably be the easiest way to go. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning
Congratulations, I wish you much luck. I presume, from your email address, that you work for Weyerhauser? I think that I might know one of the salesmen there, he used to work for Mac Blo and come to our store but got transfered from Edmonton to Saskatoon. Anyway, I would install 4.0 release and play with that for a while then upgrade to -stable or -current. BTW if you would like, I can lend you my 4.0 cd's for a week. I'm in central AB and could mail them to you, that would save a lot of time in downloading, unless you have a really fast connection. Darren Wiebe [EMAIL PROTECTED] Commissionnaires wrote: > > I am interested in learning about the freebsd operating system, I dont have > very much exerience yet but I am motivated to learn. I have poked around > other OS but have found them unappealing to my interest, I like the concept > of free source systems like linux and have played with SUSE a little but > found the limited availability of learning materials in english a > hinderance. I have downloaded and printed the manual as of page 34 where I > came upon your invitation I decided to reach out and touch someone. I woud > like some quick advice as to what version I should install via ftp to begin > my learning, and what would be the best path to follow. I am particularily > interested in learning to program in an acceptable language and want to > concentrate on network protocols and reliable secure communications, as well > as network security and firewalls. > > Thank you for any advice that you can offer. > > Arnold Murphy > > [EMAIL PROTECTED] > > 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: cocaine snorting reported in Michigan, details at 11 (was Re:data corruption)
On Thu, 6 Jul 2000, Bush Doctor wrote: >Out of da blue Adam aka ([EMAIL PROTECTED]) said: >> On Thu, 6 Jul 2000, Michael Lucas wrote: >> >> >> >> >> I fully expect to be physically assulted by all who I encounter the >> >> next time I'm in California for this act of stupidity. >> >> >> > >> >Physically assaulted? No, why do that when we can point and laugh? >> >It's legal, and much more devastating. >> > >> >Just noticed you're in Michigan. Are you aware of any Michigan >> >FreeBSD groups? I've been looking around Detroit for a while, and >> >haven't found any. >> > >> >==ml >> >> I keep mentioning to bill and others on irc from michigan that someone >> should start one :p >Well if anyone is ever down East Lansing way, a couple of co-workers >and I have an informal group. Everyone is more than welcome to come >here or maybe we could meet somewhere in between ... > >bush doctor ><[EMAIL PROTECTED]> Oh really! Why didnt Ed ever tell me about it! I'd assume he knows because he works at cl ;) (I work at egr) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UPS Daemons
Essenz Consulting <[EMAIL PROTECTED]> writes: > I know that APC SmartUPS and BackUPS are supported under FreeBSD but what > about the APC PowerStack? I was looking at the APC PowerStack 250 > Rackmount UPS. It comes with a RS-232 cables and supports that same kind > of emergency shutdown that the SmartUPS systems have. Anybody use a > PowerStack? I would only use if I knew that I could tie it in to FreeBSD > for automatic shutdown when battery power is used up. I don't have a SmartUPS system but a BackUPS, so I use bkupsd. you should probably use something like : Port: upsd-2.0.1.6 Path: /usr/ports/sysutils/upsd Info: APC Smart UPS Monitoring Daemon Maint: [EMAIL PROTECTED] Index: sysutils or Port: upsmon-2.1.3 Path: /usr/ports/sysutils/upsmon Info: Basic UPS monitor for the APC SmartUPS devices Maint: [EMAIL PROTECTED] Index: sysutils as "make search key=ups" in /usr/ports says :) links and descriptions are respectively : MASTER_SITES= ftp://www.ww.net/pub/wildwind/upsd/ \ http://www.cre8tivegroup.com/ \ ftp://ftp.sw.ru/pub/unix/upsd/ upsd is a daemon with flexible configuration which lets you to shutdown your system properly when source power line fails and measure its frequency, voltage etc MASTER_SITES= ftp://newcorridor.com/pub/upsmon/ Designed specifically for the APC SmartUPS devices, the software is dependent on the SmartUPS interface and will only function with SmartUPS devices. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cocaine snorting reported in Michigan, details at 11 (was Re: data corruption)
> Well if anyone is ever down East Lansing way, a couple of co-workers > and I have an informal group. Everyone is more than welcome to come > here or maybe we could meet somewhere in between ... I always wondered why the Voyager Michigan guys were a little screwy :-) (incidentally also located in East Lansing) -- ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: Cant build 3.5-stable?]
The problem seems to stem from a corrupt /usr/obj/usr/src/lib/libfetch/fetch_err.h If I manually delete it and make from the libfetch directory, it seems to be created properly. So, I have two lingering questions: 1. Did the tools used to create the file change? As far as I can tell, libfetch itself did _not_ change from 3.4 to 3.5. 2. Why isn't the file auto-cleaned? On the other hand, I haven't run a full buildworld yet, so it could be something else in the build process casuing the problem. Details after it finishes. Mike "Silby" Silbersack On Thu, 6 Jul 2000, Doug Barton wrote: > Reports about this are getting more frequent, FYI. > > Original Message > Subject: Re: Cant build 3.5-stable? > Date: Thu, 06 Jul 2000 11:36:16 -0400 > From: Daniel Frazier <[EMAIL PROTECTED]> > Organization: Magpage Internet Services > To: [EMAIL PROTECTED] > References: > <[EMAIL PROTECTED]> > > Adam wrote: > > > > I am trying to build 3.5-stable on a 3.4-stable system of about two > > months old. /usr/src/UPDATING is empty. Can anyone throw a clue or patch > > my way? > > > > Sorry Adam, can't help you. CVSupped last night. make buildworld is > dying > for me at exactly the same point. I hope this gets fixed soon. > > ===> libfetch > compile_et /usr/src/lib/libfetch/fetch_err.et > cc -O -pipe -I. -Wall -pedantic -DNDEBUG > -I/usr/obj/usr/src/tmp/usr/include -c > /usr/src/lib/libfetch/fetch.c -o fetch.o > In file included from /usr/src/lib/libfetch/fetch.h:34, > from /usr/src/lib/libfetch/fetch.c:39: > fetch_err.h:6: com_right.h: No such file or directory > In file included from /usr/src/lib/libfetch/fetch.h:34, > from /usr/src/lib/libfetch/fetch.c:39: > fetch_err.h:8: warning: `struct et_list' declared inside parameter list > fetch_err.h:8: warning: its scope is only this definition or > declaration, > fetch_err.h:8: warning: which is probably not what you want. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > > -- > Daniel Frazier <[EMAIL PROTECTED]> Tel: 302-239-5900 Ext. 231 > System Administrator Fax: 302-239-3909 > MAGPAGE, We Power the Internet WWW: http://www.magpage.com/ > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > > > 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: [Fwd: Re: Cant build 3.5-stable?]
Ok, the problem seems to stem from the fact that if I do a buildworld, I
get the following:
achilles# vi /usr/obj/usr/src/lib/libfetch/fetch_err.h
/* Generated from /usr/src/lib/libfetch/fetch_err.et */
#ifndef __fetch_err_h__
#define __fetch_err_h__
#include
void initialize_ftch_error_table_r(struct et_list **);
void initialize_ftch_error_table(void);
#define init_ftch_err_tbl initialize_ftch_error_table
typedef enum ftch_error_number{
ERROR_TABLE_BASE_ftch = -2098765312,
ftch_err_base = -2098765312,
FETCH_ABORT = -2098765312,
FETCH_AUTH = -2098765311,
FETCH_DOWN = -2098765310,
FETCH_EXISTS = -2098765309,
FETCH_FULL = -2098765308,
FETCH_INFO = -2098765307,
FETCH_MEMORY = -2098765306,
(etc)
You may note that this differs greatly from what you get if you just go
into /usr/src/lib/libfetch and make clean ; make.
Anyone with a better knowledge of the buildworld process have any ideas?
Mike "Silby" Silbersack
On Thu, 6 Jul 2000, Mike Silbersack wrote:
> The problem seems to stem from a corrupt
> /usr/obj/usr/src/lib/libfetch/fetch_err.h
>
> If I manually delete it and make from the libfetch directory, it seems
> to be created properly.
>
> So, I have two lingering questions:
>
> 1. Did the tools used to create the file change? As far as I can tell,
> libfetch itself did _not_ change from 3.4 to 3.5.
>
> 2. Why isn't the file auto-cleaned?
>
> On the other hand, I haven't run a full buildworld yet, so it could be
> something else in the build process casuing the problem. Details after it
> finishes.
>
> Mike "Silby" Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: Cant build 3.5-stable?]
Ok, the problem seems to be that the new version of compile_et which was MFC'd is creating broken header files, it just happens that libfetch is the first part of the buildworld that hits it. According to cvs: 1.2.2.2 Tue Jul 4 15:15:12 2000 UTC by assar Branch: RELENG_3 Diffs to 1.2.2.1 FILE REMOVED merge differences from -current and build this from ../../contrib/com_err Reviewed by:kris, markm Go to work, guys! Mike "Silby" Silbersack On Thu, 6 Jul 2000, Mike Silbersack wrote: > Ok, the problem seems to stem from the fact that if I do a buildworld, I > get the following: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bridging
Bridges create a broadcast zone. broadcast packets will cross the bridge unobstructed. On Thu, 6 Jul 2000, Nick Evans wrote: > Correct me if I am wrong, but isn't bridging of two interfaces supposed to > make a duplicate of the traffic from one onto another? Why is it then that > on the second interface I bridge to I only see broadcast and multicast > packets? I have fxp0 and fxp1 acting as a bridge, fxp0 sees all kinds of > http traffic, napster, IM, etc. but fxp1 sees only multi/broadcast packets. > > any ideas? > > > -- > nick.evans > network.engineering > NextVenue, Inc. > phone: (212) 909.2988 > pager: (888) 642.5541 > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: Cant build 3.5-stable?]
Mike Silbersack <[EMAIL PROTECTED]> writes:
> Ok, the problem seems to be that the new version of compile_et which was
> MFC'd is creating broken header files, it just happens that libfetch is
> the first part of the buildworld that hits it.
Please try the following patch. It will get comitted when my
buildworld has completed (successfully).
/assar
Index: src/lib/libcom_err/Makefile
===
RCS file: /home/ncvs/src/lib/libcom_err/Makefile,v
retrieving revision 1.8.2.2
diff -u -w -u -w -r1.8.2.2 Makefile
--- src/lib/libcom_err/Makefile 2000/07/04 15:13:05 1.8.2.2
+++ src/lib/libcom_err/Makefile 2000/07/07 03:35:57
@@ -9,6 +9,12 @@
SUBDIR=doc
+beforeinstall:
+ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \
+ ${COM_ERRDIR}/com_err.h ${DESTDIR}/usr/include
+ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \
+ ${COM_ERRDIR}/com_right.h ${DESTDIR}/usr/include
+
.include
.PATH: ${COM_ERRDIR}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: bridging
On Thu, 6 Jul 2000, Sean Lutner wrote: > > Bridges create a broadcast zone. broadcast packets will cross the bridge > unobstructed. OK. So do bridged interfaces fall within the same collision domain?... or are they just members of the same broadcast domain? Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: Cant build 3.5-stable?]
I wrote: > Please try the following patch. It will get comitted when my > buildworld has completed (successfully). And my buildworld suceeded so the patch has been comitted as version 1.8.2.3 /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: Cant build 3.5-stable?]
On 7 Jul 2000, Assar Westerlund wrote: >I wrote: >> Please try the following patch. It will get comitted when my >> buildworld has completed (successfully). > >And my buildworld suceeded so the patch has been comitted as version >1.8.2.3 Thanks for taking care of it so quickly Assar. My buildworld has also gotten past the point it died before with that Makefile patch. Looks good. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Re: Cant build 3.5-stable?]
On 7 Jul 2000, Assar Westerlund wrote: > I wrote: > > Please try the following patch. It will get comitted when my > > buildworld has completed (successfully). > > And my buildworld suceeded so the patch has been comitted as version > 1.8.2.3 > > /assar Thanks for the quick fix. LET THE BUILDING BEGIN! Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
driver
Dear Sir, To make the QuickCam (grayscale) work with Windows NT machines you must install an NT driver. I'd like to know as to get this driver. P.S.: I didn't obtain success in the site of Connectix. I thank your attention.
Re: stray interrupts in 4.0
In message <[EMAIL PROTECTED]> Dennis writes: : great, so intel doesnt know how to make MBs with their own parts...so how : can the message be turned off. Its using more resources printing the : message thsn the "stray interrupts" themselves. I doubt that. Only about 5 of them are printed then we stop. At least that's what I've seen when I have hardware that is like this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Max DMA size
On Thu, 6 Jul 2000, Kenneth D. Merry wrote: > On Thu, Jul 06, 2000 at 15:51:34 -0400, Zhihui Zhang wrote: > > > > Can anyone tell me what factors determine the max DMA size (DMA counter on > > each controller or PCI bus related)? What is the typical max DMA size for > > a SCSI disk connected to a PCI bus? It seems to be much larger than > > MAXPHYS (128K). If so, does it mean we are not using full potential of > > DMA? So what's the problem if we enlarge MAXPHYS? > > > > Any help is appreciated. > > MAXPHYS determines the size of struct buf, which at the moment determines > the maximum size of a given DMA transaction to a SCSI controller. > > Typical modern SCSI controllers can handle much more than MAXPHYS data > (currently 128K) at a time. An exception is the Adaptec 154x controllers, > which can only handle about 64K of data. (Thus the reason I/O through the > CAM passthrough interface is limited to 64K instead of the full 128K. We > will have that limitation until we implement a way of determining the > maximum DMA size allowable for a given controller.) > > However, as Matt said, you have to be careful about increasing MAXPHYS too > much, since you could end up allocating too much memory. > > I think a better approach to increasing the amount of data that can be sent > at one time to a SCSI controller would be to implement some sort of buffer > chaining scheme. Most SCSI controllers can do scatter/gather DMA, and CAM > has facilities for it, so that would probably be the easiest way to go. > Hmm. My knowledge may be a bit dated in this matter, but as I recall the 8237 DMA controller standard on PCs only supports DMA requests up to 128k (and then only on the upper 4 DMA channels). The low 4 DMA channels were byte-granular and could only transfer 64k. Am I correct in assuming from this discussion that the state of affairs is somewhat different nowadays? Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Max DMA size
> Hmm. My knowledge may be a bit dated in this matter, but as I recall the > 8237 DMA controller standard on PCs only supports DMA requests up to 128k (and > then only on the upper 4 DMA channels). The low 4 DMA channels were > byte-granular and could only transfer 64k. Am I correct in assuming from this > discussion that the state of affairs is somewhat different nowadays? Uh, yeah. Standard PCI h/w usually has 32 bit dma engines, and a lot have 64 bit. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
