Re: StrongARM support?
the freebsd-arm mailing list is now ready for use. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to make *real* random bits.
http://www.fourmilab.ch/hotbits/ jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onboard Intel NIC
Dennis, Your statement is false. Poul-Henning has NOT asked me to filter you from the lists. No one has (recently?) asked me to filter you from the lists. I do not believe that I have ever filtered you from the lists. as postmaster, i am responsible for spam filtering and removing serious problem people from teh lists. In the past 5 or 6 years, i have filtered about 6 people total. jmb -- Jonathan M. Bresler FreeBSD Core Team, Postmaster [EMAIL PROTECTED] FreeBSD--The Power to Serve JMB193 http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB > Delivered-To: [EMAIL PROTECTED] > X-Sender: [EMAIL PROTECTED] > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 > Date: Mon, 27 Mar 2000 15:35:24 -0500 > From: Dennis <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > References: <[EMAIL PROTECTED]> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Sender: [EMAIL PROTECTED] > X-Loop: FreeBSD.ORG > Precedence: bulk > > At 03:08 PM 3/27/00 -0500, Andy wrote: > >On Mon, 27 Mar 2000, Dennis wrote: > > > >> If you dont have time then perhaps someone else should do it. THATS the > >> point. > > > >> Plus I've already fixed it myself. So if you fix it its not for me at all. > > > > Since you appear to have fixed the problems and updated the code, > >would you like to submit it for review? > > I would, except as we speak Poul-Henning Kamp is trying to have my posts > censored,so they dont seem to want my help. > > Hint: Look at the netbsd driver, file name is i82557.c > > Dennis > > > 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: freebsd-hackers-digest V4 #792
Ben, relax, the gentleman in question subscribed to freebsd-hackers-digest and confused that list with freebsd-hackers. i have sent him email explaining the situation. > > >> 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 > > >> 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
s/line/list/ NIL is what you test against to determin if you have reached the end of a list. the empty list is just a NIL ( hand wave over all the car and cdr reality in favor of a simpler albeit not-correct description of how it works.) jmb > > In message <[EMAIL PROTECTED]> "Jonathan M. Bresler" writes: > : The terminology is very simple. Anyone that can cope with > : either vi or emacs can learn: > : > : NUL: an ascii character (0x00) > : NIL: a pointer at the end of the line > : NULL pointer: used in C to refer to NIL. > : not to be confused with NUL. > > But NIL is not a poitner at the end of the line in gnu emacs. It is > the empty list. > > Warner > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
> Matt Dillon wrote: > > :> Ah, indeed! nul/NUL == ascii. 'nil' should removed from our vocabulary. > :> Jonathan Bresler wrote: > : > : NIL or nil, is the nil pointer from lisp. lisp is often the > :first time many people start to understans that data can drive > :programs. this is a good thing. > : > :jmb > > I don't know anybody under the age of 30 who knows lisp. And, frankly, > since both the system and virtually all of its support programs are written > in C, C terminology is going to be considerably more effective then lisp > or pascal terminology. There are a number of people, under 30, that write code using emacs and create their own macros in lisp. The terminology is very simple. Anyone that can cope with either vi or emacs can learn: NUL: an ascii character (0x00) NIL: a pointer at the end of the line NULL pointer: used in C to refer to NIL. not to be confused with NUL. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
> > Ah, indeed! nul/NUL == ascii. 'nil' should removed from our vocabulary. > NIL or nil, is the nil pointer from lisp. lisp is often the first time many people start to understans that data can drive programs. this is a good thing. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: unsubscribe
you were subscribed to only one list "freebsd-hackers-digest". i have removed you from that list. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATA w/ today's -CURRENT
> It seems Nick Hibma wrote: > > > > ata_command: timeout waiting for interrupt > > > > ^^^ > > > > > > Thats an aritifact from the ATAPI probes, it should be of no harm... > > > > In that case, is there some way of getting rid of the message? > > Erhm well, I said harmless, but it indicates there is a problem with > drive compliance perhaps change the message to indicate that the drive is non-compliant. as it appears now, it seems to say that there it a problem that may affect the user. how about: "timeout waiting for interrupt, non-compliant drive, compensating". ;) jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: firewall problem?
your ip address 62.20.54.54 is not in DNS, you must have your address in DNS. we do not accept email from machines that do not have entries in DNS. amny spammer use addresses that do not appear in DNS jmb > Delivered-To: [EMAIL PROTECTED] > Delivered-To: [EMAIL PROTECTED] > X-Mailer: TjohooMAIL > X-WebsiteUser-IP: 62.20.54.54 > From: Ralph Utbult <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > MIME-Version: 1.0 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: Quoted-printable > Date: Thu, 9 Dec 1999 03:35:26 -0800 (PST) > Sender: [EMAIL PROTECTED] > X-Loop: FreeBSD.ORG > Precedence: bulk > > Hi > > I=B4m sitting behind a firewall consisting av FreeBsd and Squid. My mail pr= > ogram is Popper. I can mail to (and from) every adress I=B4ve tried - excep= > t freebsd.org. Here=B4s the error. > The original message was received at Wed, 8 Dec 1999 16:40:08 +0100 (CET) > from [192.168.1.2] > > >- The following addresses had transient non-fatal errors - > <[EMAIL PROTECTED]> > > >- Transcript of session follows - > .. while talking to hub.freebsd.org.: > >>> RCPT To:<[EMAIL PROTECTED]> > <<< 450 Client host rejected: cannot find your hostname, [62.20.54.54] > <[EMAIL PROTECTED]>... Deferred: 450 Client host rejected: cannot= > find your hostname, [62.20.54.54] > Warning: message still undelivered after 4 hours > Will keep trying until message is 5 days old > Reporting-MTA: dns; hyndan.gbg.abf.se > Arrival-Date: Wed, 8 Dec 1999 16:40:08 +0100 (CET) > > > Final-Recipient: RFC822; [EMAIL PROTECTED] > Action: delayed > Status: 4.2.0 > Remote-MTA: DNS; hub.freebsd.org > Diagnostic-Code: SMTP; 450 Client host rejected: cannot find your hostname,= > [62.20.54.54] > Last-Attempt-Date: Wed, 8 Dec 1999 20:52:11 +0100 (CET) > Will-Retry-Until: Mon, 13 Dec 1999 16:40:08 +0100 (CET) > Return-Path: <[EMAIL PROTECTED]> > Received: from ralph ([192.168.1.2]) > by hyndan.gbg.abf.se (8.9.3/8.9.3) with ESMTP id QAA63400; > Wed, 8 Dec 1999 16:40:08 +0100 (CET) > Message-Id: <[EMAIL PROTECTED]> > X-Sender: [EMAIL PROTECTED] > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 > Date: Wed, 08 Dec 1999 17:45:52 +0100 > To: [EMAIL PROTECTED] > From: Ralph Utbult <[EMAIL PROTECTED]> > Subject: Test - ignore! > Cc: [EMAIL PROTECTED] > Mime-Version: 1.0 > Content-Type: text/plain; charset=3D"iso-8859-1"; format=3Dflowed > > What is the problem? > > Regards, > Ralph Utbult > Systems Operator > ABF G=F6teborg > Sweden > > Gratis epost med TJOHOOMAIL > http://www.tjohoo.se > > > > > 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: ELF & putting inode at the front of a file
> > > The big benefits to locality of meta & file data are to allow > > drive/driver caching to do sequential (or close to) reads in as large > > blocks as possible. There was a recent SigOS paper on a modified Unix > > filesystem that was designed to take advantage of modern disk systems, > > Do you still remember the title of that paper and tell me where can I find > it (preferebly online)? > > -Zhihui Author: Gregory R. Ganger Author: M. Frans Kaashoek Title: Embedded Inodes and Explicit Grouping: Exploiting Disk Bandwidth for Small Files Pages: 1-17 Publisher: USENIX Proceedings: 1997 Annual Technical Conference Date: January 6-10, 1997 Location: Anaheim, CA Institution: MIT available to usenix members in the online lirary at https://www.usenix.org//publications/publications.html. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
[snip] > I am a good programmer and can fix things :-). But I've had to deal with > a number of nightmare situations by commercial entities deploying FreeBSD > and at least three (including one very recently) where commercial entities > have refused to upgrade past 2.2.x due to perceived stability problems. [snip] > > -Matt > Matthew Dillon we can not identify the specific problem from this message. without sufficient information to indentify and hopefully reproduce the problem, we can not address it. please provide this information if it is available to you. if it is not, please provide us contact information for the commercial entities experiencing the problem. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD at IETF (was: Re: IETF gettogether)
> How about Wednesday for dinner (1730-1930 EST) before the open plenary? where would we be getting together? jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
> > > > In agreement. Now if someone will give me commit priviledges I'll commit it :) > > I think the correct procedure is to ply the right people with lots of > beers at FreeBSDCon 8*) me! me! ply me! jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Surplus 3.2-RELEASE cds
bill, i should have said that i can pick these up from you next week at the FreeBSDcon. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Surplus 3.2-RELEASE cds
bill, please send me one box. i can give them out at the Washington Area FreeBSD User's Group...as well as to people at work. After a year of quiet work a number of die hard Linux folks are coming around to see the light. ;) jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: arch@freebsd.org
my problem with 'subscribers-only' posting policy is that people have more than one email address that they use. which one is teh honored one? if non-subscribers are a problem, i have ways of dealing with them. ;P Stopping Spam talk at FreeBSDcon jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: arch@freebsd.org
Please note that freebsd-arch was created to provide a place for amicable high-level technical discussion. Anyone straying from the list charter will be removed. Anyone straying from the list charter will be removed. Discuss technical matters. Dont argue or state catagorically that "this is the only way" or "that is unacceptable". Anyone straying from this or departing from civil discourse will be removed. jmb -- Jonathan M. Bresler FreeBSD Core Team, Postmaster [EMAIL PROTECTED] FreeBSD--The Power to Serve JMB193 http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB > So, here goes a call. Freebsd-arch is supposed to be a list were > technical content can be discussed, and with a sufficient high > signal/noise ratio to make it possible for committers to subscribe > to it. While -committers fit this description, it is not of open > subscription. > > Thus, I ask you, committers, to subscribe to that mailing list. > Right now, you won't increase your mailing load by a single byte, so > there is no immediate risk... :-) Please, give it a try. We need > something like that list. > > And the same I ask of you, hackers-subscribed non-committers. > > Just to clarify, -arch is supposed to be used when discussing > changes to FreeBSD itself. Things that might (or might not, > depending on how the discussion goes) end up committed. The kind of > thing we have been using -committers for, but when we want input of > a larger group. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Itojun, does KAME IPv6 and IPSec define additional facilities for syslog? I have been working with IPSec devices from a company called Network-Alchemy. They have additional syslog facilities including: IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others. Does KAME IPv6 and IPSec have these as well, or are they are creation of Network-Alchemy? jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: KAME IPv6 and freebsd
Itojun, does KAME IPv6 and IPSec define additional facilities for syslog? I have been working with IPSec devices from a company called Network-Alchemy. They have additional syslog facilities including: IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others. Does KAME IPv6 and IPSec have these as well, or are they are creation of Network-Alchemy? jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
> > > That's a option too... Only problem is that can take forever. :-) > > Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst > running 100Mbps. > that is due to the spanning tree algorithm being run. takes about 30 seconds. you can disable this with "spantree portfast" applied to the port. be careful. ;) jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
> > > That's a option too... Only problem is that can take forever. :-) > > Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst > running 100Mbps. > that is due to the spanning tree algorithm being run. takes about 30 seconds. you can disable this with "spantree portfast" applied to the port. be careful. ;) jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
> We have previously done many network performance tests for our > products running on FreeBSD ... > > We have found that when ever there is disk accessing involved, it > is not a good idea to look at the transfer figures. We did tests > with ftp and is was slow (compared to only memory generated data > e.g. ttcp) > > 1. If you want to test the network speed ... use ttcp or something >that generates the data and doesn't read it from disk. > absolutely right. netperf generates its own data on the fly. it does not generate any disk activity. > 2. When doing full-duplex and using fxp cards, stay away from X-over >cables ... use a full-duplex switch etc. ... the fxp cards are not >made to work with X-over cables (as far as I know - ala Intel spec) >note ... only for full-duplex tests. hmmi have used intel cards on a cross-over cable regularly without any problems whatsoever. jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
> We have previously done many network performance tests for our > products running on FreeBSD ... > > We have found that when ever there is disk accessing involved, it > is not a good idea to look at the transfer figures. We did tests > with ftp and is was slow (compared to only memory generated data > e.g. ttcp) > > 1. If you want to test the network speed ... use ttcp or something >that generates the data and doesn't read it from disk. > absolutely right. netperf generates its own data on the fly. it does not generate any disk activity. > 2. When doing full-duplex and using fxp cards, stay away from X-over >cables ... use a full-duplex switch etc. ... the fxp cards are not >made to work with X-over cables (as far as I know - ala Intel spec) >note ... only for full-duplex tests. hmmi have used intel cards on a cross-over cable regularly without any problems whatsoever. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
> > I guess I forgot about the overhead. I've tested between two > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL > Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
> > I guess I forgot about the overhead. I've tested between two > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL > Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting up a firewall with dynamic IPs
> On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > > the simple example relied on a fixed IP address for the external interface. > > I > > don't know ahead of time what IP address is going to be allocated to me > > before > > I dial up. Would it be possible to specify an interface (tun0) rather than > > an > > IP address? > > Yes. That's what the "via" keyword is for. very late followup, but i am behind in my mail again. to deal with this issue i use the following: /etc/ppp/linkup: #!/bin/sh sh /etc/rc.firewall /etc/rc.firewall (exerpt) [snip] if [ "${firewall_type}" = "MINE" ]; then # # # tun0=`ifconfig tun0 | grep netmask | cut -f 2 -d ' ' | tail -1` ep0=`ifconfig ep0 | grep netmask | cut -f 2 -d ' '` loopback="127.0.0.0/8" net10="10.0.0.0/8" net172="172.16.0.0/12" net192="192.168.0.0/16" localnet="192.168.250.0/24" localhost="127.0.0.1" ntpdate_host="128.115.14.97" xntpd_host="204.91.99.129" preppp="10.0.0.1" # # clear all rules # $fwcmd -f flush # # prevent source address spoofing # $fwcmd add 100 deny log all from ${tun0} to any in recv tun0 [snip] this way, whenever i dialup, i get a new ip address. the new ip address is used to create the firewall rules. jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting up a firewall with dynamic IPs
> On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > > the simple example relied on a fixed IP address for the external interface. I > > don't know ahead of time what IP address is going to be allocated to me before > > I dial up. Would it be possible to specify an interface (tun0) rather than an > > IP address? > > Yes. That's what the "via" keyword is for. very late followup, but i am behind in my mail again. to deal with this issue i use the following: /etc/ppp/linkup: #!/bin/sh sh /etc/rc.firewall /etc/rc.firewall (exerpt) [snip] if [ "${firewall_type}" = "MINE" ]; then # # # tun0=`ifconfig tun0 | grep netmask | cut -f 2 -d ' ' | tail -1` ep0=`ifconfig ep0 | grep netmask | cut -f 2 -d ' '` loopback="127.0.0.0/8" net10="10.0.0.0/8" net172="172.16.0.0/12" net192="192.168.0.0/16" localnet="192.168.250.0/24" localhost="127.0.0.1" ntpdate_host="128.115.14.97" xntpd_host="204.91.99.129" preppp="10.0.0.1" # # clear all rules # $fwcmd -f flush # # prevent source address spoofing # $fwcmd add 100 deny log all from ${tun0} to any in recv tun0 [snip] this way, whenever i dialup, i get a new ip address. the new ip address is used to create the firewall rules. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
> > > > It also clears up the misconception that being a member of -core requires > > a beard. > > > > A constant 5 o'clock shadow, maybe, but not a beard. > > And what's wrong with a beard? beards are great...women love them, getting fluffed is much better than getting scratchedkids love them. brush the beard whenever you brush your hair. dont hae to deal with a buzzing razor, very unkind to newly awoken folk. dont ahve to wield a blade across you neck in a fogged monring stupor. jmb--i aint shaved in 18 years. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
> > > > It also clears up the misconception that being a member of -core requires > > a beard. > > > > A constant 5 o'clock shadow, maybe, but not a beard. > > And what's wrong with a beard? beards are great...women love them, getting fluffed is much better than getting scratchedkids love them. brush the beard whenever you brush your hair. dont hae to deal with a buzzing razor, very unkind to newly awoken folk. dont ahve to wield a blade across you neck in a fogged monring stupor. jmb--i aint shaved in 18 years. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PATCH for NE2000 driver--if_ed.c
patch adds support for the Linksys 10/100 PCMCIA card if you have a NE2000 type card which is supported by if_ed.c, please apply this patch and provide feedback. it work wonderfully for me, but i have only two cards that use this driver.there are a wide variety of cards that use the if_ed.c driver. i want to make sure of the change before committing it. *** /sys/i386/isa/if_ed.c.orig Tue Jan 2 05:33:53 1990 --- /sys/i386/isa/if_ed.c Sun Jun 6 06:59:40 1999 *** *** 193,198 --- 193,200 static u_long ds_crc __P((u_char *ep)); + static inted_get_Linksys __P((struct ed_softc *)); + #if (NCARD > 0) || (NPNP > 0) #include #endif *** *** 410,415 --- 412,435 return (1); } + static int + ed_get_Linksys(sc) + struct ed_softc *sc; + { + u_char sum; + int i; + + for (sum = 0, i = 0x14; i < 0x1c; i++) + sum += inb(sc->nic_addr +i); + if (sum != 0xff) + return (0); + for (i = 0; i < ETHER_ADDR_LEN; i++) { + sc->arpcom.ac_enaddr[i] = inb(sc->nic_addr + 0x14 + i); + printf("%02x.", sc->arpcom.ac_enaddr[i]); + } + return (1); + } + /* * Probe and vendor-specific initialization routine for SMC/WD80x3 boards */ *** *** 1072,1077 --- 1092,1098 u_char romdata[16], tmp; static char test_pattern[32] = "THIS is A memory TEST pattern"; chartest_buffer[32]; + int linksys = 0; sc->asic_addr = port + ED_NOVELL_ASIC_OFFSET; sc->nic_addr = port + ED_NOVELL_NIC_OFFSET; *** *** 1141,1147 ed_pio_writemem(sc, test_pattern, 8192, sizeof(test_pattern)); ed_pio_readmem(sc, 8192, test_buffer, sizeof(test_pattern)); ! if (bcmp(test_pattern, test_buffer, sizeof(test_pattern))) { /* not an NE1000 - try NE2000 */ outb(sc->nic_addr + ED_P0_DCR, ED_DCR_WTS | ED_DCR_FT1 | ED_DCR_LS); --- 1162,1174 ed_pio_writemem(sc, test_pattern, 8192, sizeof(test_pattern)); ed_pio_readmem(sc, 8192, test_buffer, sizeof(test_pattern)); ! linksys = ed_get_Linksys(sc); ! if (linksys) { ! outb(sc->nic_addr + ED_P0_DCR, ED_DCR_WTS | ED_DCR_FT1 | ED_DCR_LS); ! sc->isa16bit = 1; ! sc->type = ED_TYPE_NE2000; ! sc->type_str = "Linksys"; ! } else if (bcmp(test_pattern, test_buffer, sizeof(test_pattern))) { /* not an NE1000 - try NE2000 */ outb(sc->nic_addr + ED_P0_DCR, ED_DCR_WTS | ED_DCR_FT1 | ED_DCR_LS); *** *** 1251,1269 * Use one xmit buffer if < 16k, two buffers otherwise (if not told * otherwise). */ ! if ((memsize < 16384) || (flags & ED_FLAGS_NO_MULTI_BUFFERING)) sc->txb_cnt = 1; else sc->txb_cnt = 2; sc->rec_page_start = sc->tx_page_start + sc->txb_cnt * ED_TXBUF_SIZE; ! sc->rec_page_stop = sc->tx_page_start + memsize / ED_PAGE_SIZE; sc->mem_ring = sc->mem_start + sc->txb_cnt * ED_PAGE_SIZE * ED_TXBUF_SIZE; ! ! ed_pio_readmem(sc, 0, romdata, 16); ! for (n = 0; n < ETHER_ADDR_LEN; n++) ! sc->arpcom.ac_enaddr[n] = romdata[n * (sc->isa16bit + 1)]; #ifdef GWETHER if (sc->arpcom.ac_enaddr[2] == 0x86) { --- 1278,1298 * Use one xmit buffer if < 16k, two buffers otherwise (if not told * otherwise). */ ! if ((sc->mem_size < 16384) || (flags & ED_FLAGS_NO_MULTI_BUFFERING)) sc->txb_cnt = 1; else sc->txb_cnt = 2; sc->rec_page_start = sc->tx_page_start + sc->txb_cnt * ED_TXBUF_SIZE; ! n = sc->tx_page_start + sc->mem_size / ED_PAGE_SIZE; ! sc->rec_page_stop = (n > 0xff) ? 0xff : n; sc->mem_ring = sc->mem_start + sc->txb_cnt * ED_PAGE_SIZE * ED_TXBUF_SIZE; ! if (!linksys) { ! ed_pio_readmem(sc, 0, romdata, 16); ! for (n = 0; n < ETHER_ADDR_LEN; n++) ! sc->arpcom.ac_enaddr[n] = romdata[n * (sc->isa16bit + 1)]; ! } #ifdef GWETHER if (sc->arpcom.ac_enaddr[2] == 0x86) { To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: xl driver for 3Com
> > If your nic driver chains packets (such that there is no time in between) > you will see good throughput from the box but your overall network > performance will suffer. A PCI card with continueous traffic can completely > hog your lan (particularly at 10Mb/s)...which can cause a lot more > collisions on your network as other devices will not have access until the > hog is finished sending. For "Fairness" gaps in between frames are better > as you approach capacity of your wire. > > Dennis the interframce gap will allow other hosts to contend for the wire. the ethernet capture effect decreases as the number of hosts on the segment increases. the interpacket gap is 9.6uS (or 96 bit times). an ethernet card listens to the wire before transmitting a card that is not able to transmit because the wire is busy will begin transmitting as soon as the wire goes quiet. the max length of an ethernet is 46 bit times. so a waiting card will alaways get first crack at the wire. capture effect is due to stations colliding in trying to access the wire. those that dont collide, are immune to the capture effect and get the wire first. http://wwwhost.ots.utexas.edu/ethernet/papers.html jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: USENIX FreeBSD Dinner
> > How about Klingon? I doubt anyone would question how authentic your accent > is ;-) how about gelfi'll bring a handkerchief so that everyone stays dry. ;P jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: USENIX FreeBSD Dinner
> > As long as you don't insist on trying your ?Irish? (Not) accent out > like last time... no problem, mate, got a new one fer you this year. ;) jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: USENIX FreeBSD Dinner
> > Is there any plan for which evening of the conference this big dinner will > happen? or will we all just be out each night getting crazy? ;-) getting crazy every night works for me. jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf wait code (revisited) -- review?
> > The solution that I took with BestWWWD was to have just one process > accept all the connections and then have it dole the descriptor out to the > appropriate sub-processes over a unix-domain socket. > > -Matt > yes. clearly, thats the way to go, to use the ability to pass a file descriptor over a unix-domain socket. one socket per handler (web server), and the process doing the accept doles out the work as each handler (web server) finishes a task and is ready to accept another task. in my memory, i can almost see the description of this problem and its resolution in a book on threads (i think). could it have been the addison-wesley swoosh book on threads by behlendorf? sigh...gotta get better memory installed. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Netgear FA410 pccard ethernet?
> > In message <[EMAIL PROTECTED]> Robert Withrow >writes: > : When the card attaches it is called a Linksys and it runs with the ed driver, > : and gives me good performance on a 100Tx network. > > Date: Thu, 04 Nov 1999 14:05:07 -0700 > From: Warner Losh <[EMAIL PROTECTED]> > The linksys support in normal freebsd was added only since FreeBSD > Con. If this card uses the same linksys chipset, we may make it work > in freebsd by removing the check against NIC interface address that is > there now. if we remove the OUI check, then we are relying on the checksum alone. that sounds fine provided that other none Lninksys/dl10019c cards will fail the checksum. what do other nic cards have at those addresses (sc->asic_addr[0x04..0x0f])? jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD FibreChannel support
Matt, Thank you for lunch at the South American resturant in Berkeley during the FreeBSDCon. Do we have a FibreChannel driver for FreeBSD? Ideally, I am looking for arbitrated loop support on the emulex cards. jmb -- Jonathan M. Bresler FreeBSD Core Team, Postmaster [EMAIL PROTECTED] FreeBSD--The Power to Serve JMB193 http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message