From pemmaiah@cc.usu.edu Wed Apr 3 18:27:01 2002 From: pemmaiah@cc.usu.edu (Napanda. C. Pemmaiah) Date: Wed Apr 3 18:27:01 2002 Subject: [vortex] About 3c59x Driver Message-ID: <3CADA807@webmail.usu.edu> Hello Everyone, I am N.C.Pemmaiah doing my masters in computer science at Utah state university. I am very interested in networking and system level programming. I have a "3c905 100BaseTX [Boomerang]" network interface card with me. The driver used for this card is "3c59x". To know more about drivers and its inner details I am writing a module for the above mentioned card. I am using the 3c59x.c code as my main reference and using Red Hat 7.2 (kernel ver 2.4) as the platform. I want to write a simple module which does the basic work. I am in the initial stage of writing the code. Right now my module is able to get registered by telling to PCI which in turn calls my probe and detects the MAC address. All these I learnt by going into 3c59x.c source code. The ports allocated to the card is from dc80 to dce4 which is as shown in /proc/ioports. The problem I am facing is I don’t have detailed information about each of these ports. For e.g.:- Before getting values into eeprom array in the probing function, an EL3WINDOW(0) is done, which writes "Selectwindow + 0" into "ioaddr + 0x0e" port. As far as I understood it writes 2048 into the above port. I was curious why this number is written. Down the code I find some other number written to the same above port. It will be really great and helpful if some one gives me a link which gives the detailed specifications of the above ports and also other aspects. Also important tips for writing the above module will be greatly appreciated. The referance book I am using for writing drivers is "Linux Device Drivers by Rubini and Corbet, O'REILLY". I am very grateful to Mr.Becker for making the code available. I will be eagerly waiting for the reply. Thank you, N.C.Pemmaiah ------------------------------------------------- N.C.Pemmaiah (Anup) 620E, 700N, Apt# 2 Logan, UT-84321,USA. email: pemmaiah@cc.usu.edu, anup_pemmaiah@yahoo.com Ph: 435-512-0935(mob.), 435-752-5976 (Res.) ------------------------------------------------- From gatgul@voicenet.com Thu Apr 11 00:53:52 2002 From: gatgul@voicenet.com (Uncle George) Date: Wed Apr 10 23:53:52 2002 Subject: [vortex] About 3c59x Driver References: <3CADA807@webmail.usu.edu> Message-ID: <3CAB9F00.D948823D@voicenet.com> I suppose you can do all this, But wouldnt it be simpler to obtain the 3c90x driver from 3com? Just a thought. /gat "Napanda. C. Pemmaiah" wrote: > > Hello Everyone, > I am N.C.Pemmaiah doing my masters in computer science at Utah state > university. I am very interested in networking and system level programming. I > have a "3c905 100BaseTX [Boomerang]" network interface card with me. The > From samael@btka.net Thu Apr 11 01:06:30 2002 From: samael@btka.net (samae|) Date: Thu Apr 11 00:06:30 2002 Subject: [vortex] one cyclone-boomerang question Message-ID: <3CAD0BD6.9ABDB3F6@btka.net> Which is better between the two chipsets ? From jack@email.com Thu Apr 11 01:56:29 2002 From: jack@email.com (eyou321) Date: Thu Apr 11 00:56:29 2002 Subject: [vortex] ADV:Harvest lots of Target Email address quickly Message-ID: <200204090113.g391Dkj03844@blueraja.scyld.com>

           Want To Get A Lot Of Target Email   Addresses In A Very Short Time?

Target Email Extractor is  a  powerful  Email  Software that  harvests Target Email Addresses from search engines, any specified starting URLs , including cgi , asp pages etc.

  It Quickly and automatically search and spider from search engine, any specified starting URLs to find and extract e-mail addresses

  • Powerful targeting ability. Only extract the specific email addresses that directly related to your business.
  • Integrated with 18 top popular search engines: Yahoo, Google, MSN, AOL
  • Fast Search Ability. Nearly can find thousands of e-mail addresses in an hour, allowing up to 500 simultaneous search threads!
  • Helpful for anyone for internet Email marketing purposes.
  • Free version updates.

    Click The Following Link To Download This Program:

    • Download Site 1

    Download Site 2            ¡¡If  you can not download this program ,  please copy the following link into your URL , and then click " Enter" on your Computer Keyboard.

    Here is the download links:

    http://www.wldinfo.com/download/email/ESE.zip

    http://bestsoft.3322.org/onlinedown/ESE.zip
    Disclaimer:
    We are strongly against continuously sending unsolicited emails to those who do not wish to receive our special mailings. We have attained the services of an independent 3rd party to overlook list management and removal services. This is not unsolicited email. If you do not wish to receive further mailings, please click this link http://www.autoemailremoval.com/cgi-bin/remove.pl . Auto Email Removal Company. Ref# 01222263545
    This message is a commercial advertisement. It is compliant with all federal and state laws regarding email messages including the California Business and Professions Code. We have provided the subject line "ADV" to provide you notification that this is a commercial advertisement for persons over 18yrs old.










    From udr@grzzr.com Thu Apr 11 02:00:47 2002 From: udr@grzzr.com (udr@grzzr.com) Date: Thu Apr 11 01:00:47 2002 Subject: [vortex] ADV: WA Survey Message-ID: WASHINGTON GAMING FORM

    TARGET ADVERTISING LLC

    We are Target Advetising LLC a marketing and resouce company. We are conducting an E-mail Survey among voters in Washington State. Let us assure you that we are not selling anything. We are only gathering information that will better help us keep all Washington State Residents better informed about important issues in your area. At the bottom of this page is an opt out link for your use. Please note we do not encourage spam and if you feel you have received this letter in error please use the unsubscribe link and we immediatly remove you from our list.

    WASHINGTON STATE GAMINING

    The following survey deals with the issue of tribal and non-tribal gaming establishments in the State of Washington. To aid in compiling data please fill in all the required fields marked with a red asterik and please answer the questions as they apply to you.
    All of the information will be kept confidential.


      

    * Your Name    

    * E-Mail Address   

    Your Street Address   

    * Your City   

    *Your State                  Your Zip Code   

    Phone: Home Number            

    WHAT DO YOU THINK



    *1- First, which one of the following statements comes closest to the way you personally feel about gambling?
    Do you feel it is,


    **2-As you may know, there are different regulations for tribal and non-tribal gaming establishments in Washington state. Tribal casinos, operated by Indian tribes, can offer card games, roulette, dice games, and electronic games. Non-tribal mini casinos, operated by non-tribal businesses and individuals, can only offer card games and are prohibited from offering roulette, dice games, and electronic games. Would you favor or oppose a law that allowed all licensed gaming establishments in Washington state, whether tribal or non-tribal, to operate under similar regulations and offer similar games?


    *3- Would you favor or oppose a law in Washington state that allowed all licensed gaming establishments to operate under similar regulations and offer similar games, if it would generate $200 million in gambling tax dollars for state and local governments that would help pay for education, law enforcement and other important programs?


    *4-As you may know, the Washington State budget has $1.5 billion dollar budget deficit. Which of the following taxes would you most prefer to help reduce the budget deficit?

    Now I'd like to read you some statements about gaming. Please tell me if you agree or disagree with each statement. IF AGREE/DISAGREE: Is that strongly agree/disagree or somewhat agree/disagree? ---AGREE--- Don't --DISAGREE--

    *5-People should be able to go into a casino and spend their disposable income any way they want.


    *6- Gambling is a question of personal freedom. The government should not tell American adults they cannot gamble.


    *7- Thanks to revenues from casinos, local communities have more money to pay for roads, schools, hospitals, and other projects.
    .

    *8- Casinos bring widespread economic benefits to other industries and businesses within the region.


    *9- A casino can be an important part of a community's entertainment and tourism options.


    *10- Casino companies should have programs to discourage compulsive gambling.


    *11- Casino companies should have programs to discourage underage gambling.

    Now a few questions for statistical purposes.


    *12- What is your approximate age?


    *13- Which one of the following best describes how you usually vote?


    *14- Gender


    *15-County


    *16- IF KING COUNTY: Do you live inside or outside the city of Seattle?

    Thank you for your answers. Your answers will be used to help shape the future of the great State of Washington.

    Unsubscribe Here

                       

     

     

    From devdrvr@davis.com Thu Apr 11 14:09:02 2002 From: devdrvr@davis.com (engineering@devdrvr.net) Date: Thu Apr 11 13:09:02 2002 Subject: [vortex] Perry Gregg Cross Platform Programmer Available Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3101364507_421178_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Merger cancelled a project I was relying upon for June. My smile is available and looking for a project, contract or full-time. Lately (past 4 years), I've done a slew of commercial network device driver and AP firmware work (C, C++ and some assembly) on MacOS, Linux and Win- dows (NDIS model). Each project had an associated Config app and sometimes a suite of tools so I'm fresh on doing application development. My last project was an 802.11a set of cards. Many times I've had to move project sources working on one platform to another. I'm wrapping up moving code from Linux to MacOS X in the coming weeks. Where ever I sit down to work I bring 2 portables with Linux, Win 2K, BSD Unix, MacOS X & Classic partitions with full development systems and debugging tools; switchable at boot. I'm versed and have written code to make most of the Web illusions happen with the Internet protocols (Perl mostly and not Java). For larger projects I have 2 engineers that work with me here in town and a Web graphic artist for the visual stuff & dialogs. Resume attached. Have wireless LAN AP U.S. patent pending that isn't on the resume. If list server doesn't let the .pdf through please email me for the resume. --Perry Gregg Davis, CA mailto:perry_gregg@post.harvard.edu 01 (530) 400-5692 --MS_Mac_OE_3101364507_421178_MIME_Part Content-type: application/pdf; name="Perry_Gregg_Resume.pdf"; x-mac-creator="4341524F"; x-mac-type="50444620" Content-disposition: attachment Content-transfer-encoding: base64 JVBERi0xLjMNJeLjz9MNCjEgMCBvYmoNPDwgDS9DcmVhdG9yIChNaWNyb3NvZnQgV29yZCkN L0NyZWF0aW9uRGF0ZSAoRDoyMDAwMTAyODE2MTkxNSkNL1N1YmplY3QgKCkNL1RpdGxlICgp DS9BdXRob3IgKGRldmRydnIpDS9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIgNC4wIGZv ciBQb3dlciBNYWNpbnRvc2gpDS9LZXl3b3JkcyAoKQ0vTW9kRGF0ZSAoRDoyMDAyMDEwNDE1 NDAwNy0wOCcwMCcpDT4+IA1lbmRvYmoNMyAwIG9iag08PCANL1BhZ2VzIDUgMCBSIA0vVHlw ZSAvQ2F0YWxvZyANL0RlZmF1bHRHcmF5IDEwIDAgUiANL0RlZmF1bHRSR0IgMTEgMCBSIA0v T3V0bGluZXMgMTIgMCBSIA0+PiANZW5kb2JqDTQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v UGFyZW50IDUgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMSA2IDAgUiAvRjIgNyAw IFIgPj4gL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gPj4gDS9Db250ZW50cyA3MyAwIFIgDT4+ IA1lbmRvYmoNNSAwIG9iag08PCANL0tpZHMgWyA0IDAgUiBdIA0vQ291bnQgMSANL1R5cGUg L1BhZ2VzIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0+PiANZW5kb2JqDTYgMCBvYmoN PDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9OYW1lIC9GMSANL0Jhc2VG b250IC9UaW1lcy1Cb2xkIA0vRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgDT4+IA1lbmRv YmoNNyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL05hbWUg L0YyIA0vQmFzZUZvbnQgL1RpbWVzLVJvbWFuIA0vRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rp bmcgDT4+IA1lbmRvYmoNMTAgMCBvYmoNWyANL0NhbEdyYXkgPDwgL1doaXRlUG9pbnQgWyAw LjkwMjg5IDEgMS4xMDg4IF0gL0dhbW1hIDEuODAwOCA+PiANXQ1lbmRvYmoNMTEgMCBvYmoN WyANL0NhbFJHQiA8PCAvV2hpdGVQb2ludCBbIDAuOTAyODkgMSAxLjEwODggXSAvR2FtbWEg WyAxLjgwMDggMS44MDA4IDEuODAwOCBdIA0vTWF0cml4IFsgMC4zNzQ1IDAuMjMxNTEgMC4w NTk4IDAuMzM1NjkgMC41OTc0IDAuMTc5MiAwLjE5MjcgMC4xNzEwMSAwLjg2OTcxIA1dID4+ IA0NXQ1lbmRvYmoNMTIgMCBvYmoNPDwgDS9Db3VudCAwIA0vVHlwZSAvT3V0bGluZXMgDT4+ IA1lbmRvYmoNNzMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3NCAw IFIgPj4gDXN0cmVhbQ0KSIm0Vmtz2jgU/QX8h/tpx96CsWz86qdS4mabISkTvG132p0dxVZA W1tiJAPNv98r/CDk0dfMhplg4Eg69+jcI73OBi6sBgQ4DMbXrKQ137GZLKXiFasVz0HxwfgN AQLZLbiOS0g4gSwHF7K9+adgQAg+uIBviesEEBEPsmpgLdLr67/g/Do9P7ezf3ES7zhJ0kwy QOQcst8tL/IiSFkJi5LmzMAR5UbJAUQa0CfrjO64HsJsCkkQktC2Rrbl2VZCbCuw/84uzCDi kvgwygxIK9ui3LZK23ppW2BbG2ZbStnWnW39s8JH/LjC91f4i9S2VduWY1trir/scCQCC/wG QcXWDO+WIElDzIXm5YWhE0SuD2EYH0ov2K5QO/XKFOJ7URg5Cf7BvcesQJQpx8ll1dbrTyZB U/CpoGEQNYKupWAv4bMV+O5nGyauOwrCxDuMvq/mJ2smhd6WNRX1EI6i2SPPn3jE8S1vnMSj vpxJ6N/X2VooLnK+oSWkYsUFYwp+gzOFxlAwVfma1yyv4YrVe6m+wLSgm5op3RZBvMg/2drp ZlMymMlqs0XYEN6K3EE62w1TNReyYdaODVpb+J4TmXncg06EjJNgZDh3uEm7x6MOOCIH5JIJ LhW8W8JS3tZ7qtixhGmxoyJnBVxSrWFZS0VXzBTG9aakdx1/Nw4mrX+sK/Yxe8T8mhV7KQuY 8fruB8gn48QfEXecTB4K9JD8GVeoK9J/xJ2LFVylH7Nlli6G8G6RXpmn474j1Wta8K3uOC6p gAup2Qk/zw+f4BeOE29kSHYw4iZPa9ux6ngOj2bYKjTLnNGiV3MI73nBJMzQHFvFHtb+k754 mjo6wh0Z/n1ekG8zv6QC91zB7MULMMvzHOMOWwXeKFox4+YhXC4+dNMFCenIZuuGaslqBovZ TynsjePYuNftYEkQfMu9vWOXORXi0HzY+bWEtOC1sUJXT79jYe/YqV7XUowyWiOzTCplLD+E 85KJgpbG7nOp4ZzWUv+QN2LTd3Hfd94zfYd5UyuKofC47ZYbhb7Qa8Ywiz5IVcBCyZxpLVU3 q986Dvmf0Zpih2m5VYhpPTFnX7FsrAt353uUyTgm6Im4s7NHWtizpuiZprkUsj30kOMKPVEZ uVOx40qKiom6V7zj+wdVO4o1LXPOUGmYIciYeUarG8WLFfsByuE4iu9Txgb8jo+P8Y4bmjGK XYg8p1pzbb7s5okj7yHP+4kypzeYgdjId7/A1+jcwaLn+N7pmlX6RMxLmitpTjZky6qb8g53 G7Mjw9tG13YJSR7S/lOYw0c3iftTVNENyTj2emmfyd5exDesLOW+P2fCPq7mkt3gIUgr+oub HLuGyXdDoG+lk4DqJDTnWJ7LrTgEwYLmXzDQ/hfhTj3ped5znd/kN7zD3DZmaq563X2x45MW 26aUhzdB9+SK9wTvvuVavRD02pk6cMZWimEpU+yIAk91ksQ+FkbrNatwpby/j/TD3tPDhNgw QnBt+qa7eLkh3j5b1HFlkLeoWclvpRKcthepPrOOdJb5WsrSoOd0P4QL5+xJdmG3mB/38bFQ TOMxaa5pOBbamWYl3lBOdBzdd0x3sXprXMh0rR9pGrWN36k6o2qDi5hGrw/FD2Ely9sh7M3x DXtqNlDRW2OqIWiMmRtalvgk5B70F374GlGfB4hrPmPwmLUpnvx94HjhMchvtrwsEOeY39Js 8J8AAwD5Z2LrDWVuZHN0cmVhbQ1lbmRvYmoNNzQgMCBvYmoNMTI5MCANZW5kb2JqDXhyZWYN MCA3NSANMDAwMDAwMDAwMiA2NTUzNSBmIA0wMDAwMDAwMDE2IDAwMDAwIG4gDTAwMDAwMDAw MDggMDAwMDEgZiANMDAwMDAwMDI0MCAwMDAwMCBuIA0wMDAwMDAwMzUyIDAwMDAwIG4gDTAw MDAwMDA0OTUgMDAwMDAgbiANMDAwMDAwMDU4NiAwMDAwMCBuIA0wMDAwMDAwNzA1IDAwMDAw IG4gDTAwMDAwMDAwMDkgMDAwMDEgZiANMDAwMDAwMDAxMyAwMDAwMSBmIA0wMDAwMDAwODI1 IDAwMDAwIG4gDTAwMDAwMDA5MDkgMDAwMDAgbiANMDAwMDAwMTA5MiAwMDAwMCBuIA0wMDAw MDAwMDE0IDAwMDAxIGYgDTAwMDAwMDAwMTUgMDAwMDEgZiANMDAwMDAwMDAxNiAwMDAwMSBm IA0wMDAwMDAwMDE3IDAwMDAxIGYgDTAwMDAwMDAwMTggMDAwMDEgZiANMDAwMDAwMDAxOSAw MDAwMSBmIA0wMDAwMDAwMDIwIDAwMDAxIGYgDTAwMDAwMDAwMjEgMDAwMDEgZiANMDAwMDAw MDAyMiAwMDAwMSBmIA0wMDAwMDAwMDIzIDAwMDAxIGYgDTAwMDAwMDAwMjQgMDAwMDEgZiAN MDAwMDAwMDAyNSAwMDAwMSBmIA0wMDAwMDAwMDI2IDAwMDAxIGYgDTAwMDAwMDAwMjcgMDAw MDEgZiANMDAwMDAwMDAyOCAwMDAwMSBmIA0wMDAwMDAwMDI5IDAwMDAxIGYgDTAwMDAwMDAw MzAgMDAwMDEgZiANMDAwMDAwMDAzMSAwMDAwMSBmIA0wMDAwMDAwMDMyIDAwMDAxIGYgDTAw MDAwMDAwMzMgMDAwMDEgZiANMDAwMDAwMDAzNCAwMDAwMSBmIA0wMDAwMDAwMDM1IDAwMDAx IGYgDTAwMDAwMDAwMzYgMDAwMDEgZiANMDAwMDAwMDAzNyAwMDAwMSBmIA0wMDAwMDAwMDM4 IDAwMDAxIGYgDTAwMDAwMDAwMzkgMDAwMDEgZiANMDAwMDAwMDA0MCAwMDAwMSBmIA0wMDAw MDAwMDQxIDAwMDAxIGYgDTAwMDAwMDAwNDIgMDAwMDEgZiANMDAwMDAwMDA0MyAwMDAwMSBm IA0wMDAwMDAwMDQ0IDAwMDAxIGYgDTAwMDAwMDAwNDUgMDAwMDEgZiANMDAwMDAwMDA0NiAw MDAwMSBmIA0wMDAwMDAwMDQ3IDAwMDAxIGYgDTAwMDAwMDAwNDggMDAwMDEgZiANMDAwMDAw MDA0OSAwMDAwMSBmIA0wMDAwMDAwMDUwIDAwMDAxIGYgDTAwMDAwMDAwNTEgMDAwMDEgZiAN MDAwMDAwMDA1MiAwMDAwMSBmIA0wMDAwMDAwMDUzIDAwMDAxIGYgDTAwMDAwMDAwNTQgMDAw MDEgZiANMDAwMDAwMDA1NSAwMDAwMSBmIA0wMDAwMDAwMDU2IDAwMDAxIGYgDTAwMDAwMDAw NTcgMDAwMDEgZiANMDAwMDAwMDA1OCAwMDAwMSBmIA0wMDAwMDAwMDU5IDAwMDAxIGYgDTAw MDAwMDAwNjAgMDAwMDEgZiANMDAwMDAwMDA2MSAwMDAwMSBmIA0wMDAwMDAwMDYyIDAwMDAx IGYgDTAwMDAwMDAwNjMgMDAwMDEgZiANMDAwMDAwMDA2NCAwMDAwMSBmIA0wMDAwMDAwMDY1 IDAwMDAxIGYgDTAwMDAwMDAwNjYgMDAwMDEgZiANMDAwMDAwMDA2NyAwMDAwMSBmIA0wMDAw MDAwMDY4IDAwMDAxIGYgDTAwMDAwMDAwNjkgMDAwMDEgZiANMDAwMDAwMDA3MCAwMDAwMSBm IA0wMDAwMDAwMDcxIDAwMDAxIGYgDTAwMDAwMDAwNzIgMDAwMDEgZiANMDAwMDAwMDAwMCAw MDAwMSBmIA0wMDAwMDAxMTQzIDAwMDAwIG4gDTAwMDAwMDI1MTEgMDAwMDAgbiANdHJhaWxl cg08PA0vU2l6ZSA3NQ0vSW5mbyAxIDAgUiANL1Jvb3QgMyAwIFIgDS9JRFs8ZWEwNzhhNGJl ZDVkMjZmN2IwMmRhMWFhMmUzNmMzYTA+PDljNTIyYzgyMzNhNDA1MGJhYmNmZjIxODBkMzBm MTZhPl0NPj4Nc3RhcnR4cmVmDTI1MzMNJSVFT0YN --MS_Mac_OE_3101364507_421178_MIME_Part-- From gschimmel@techtel.com.ar Mon Apr 15 17:27:01 2002 From: gschimmel@techtel.com.ar (SCHIMMEL Guillermo TECHTEL) Date: Mon Apr 15 16:27:01 2002 Subject: [vortex] 802.1q VLAN problem Message-ID: Hi: Before I start, I have to thank you for the great driver 3c59x.c. It´s working great in all our servers. Recentrly we have started tests in order to develop a vlan based network around the 3com vortex card. The problem is that the driver doesn't like the oversized 1504 bytes packets that the 802.1q module gives to him. Are you aware of that problem? Do you intend to patch the driver? We have tried to do so following the instructions at some page, which said that we should change the mtu from 1500 to 1504 in the driver code. But this didn't worked. Can you please give me a hint? Thanks a lot. Guillermo Schimmel Techtel (Argentina) From ydwoo0722@hotmail.com Tue Apr 16 03:06:01 2002 From: ydwoo0722@hotmail.com (Wu Yadong) Date: Tue Apr 16 02:06:01 2002 Subject: [vortex] (no subject) Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C1E54F.012FC710 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpJIHdyaXRlIGEgcHJvZ3JhbSBpbiBsaW51eCBrZXJuZWwgdG8gdGVzdCBuZXQgd29yayBkZXZp Y2Ugc3VjaCBhcyBmaXJld2FsbCAsdnBuLiBUaGlzIHByb2dyYW0gbXVzdCBnZW5lcmF0ZSBncmVh dCBuZXQgdHJhZmZpYywgbXkgbmV0IGNhcmQgaXMgM2NvbSAzYzkwNS4gQnV0IHdoZW4gSSB0ZXN0 IGEgMTBNIGJwcyBodWIsIHRvbyBtdWNoIHRyYWZmaWMgd2lsbCBjYXVzZSBuZXQgY2FyZCB0byBj cmFzaC4NClNvIG1heWJlIHNvbWVvbmUgY291bGQgdGVsbCBtZSBob3cgdG8gZ2V0IG1heCB0cmFu c21pdCBzcGVlZCBpbiBkaWZmZXJlbnQgc2l0dWF0aW9ucyxzb3VyY2UgY29kZSBpcyBiZXN0Lg0K DQpUaGFuayB5b3UuDQo= ------=_NextPart_000_001D_01C1E54F.012FC710 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ SSB3cml0ZSBhIHByb2dyYW0gaW4gbGludXgga2VybmVsIHRvIHRlc3QgbmV0IHdvcmsgZGV2aWNl IHN1Y2ggDQphcyBmaXJld2FsbCAsdnBuLiBUaGlzIHByb2dyYW0gbXVzdCBnZW5lcmF0ZSBncmVh dCBuZXQgdHJhZmZpYywgbXkgbmV0IGNhcmQgaXMgDQozY29tIDNjOTA1LiBCdXQgd2hlbiBJIHRl c3QgYSAxME0gYnBzIGh1YiwgdG9vIG11Y2ggdHJhZmZpYyB3aWxsIGNhdXNlIG5ldCBjYXJkIA0K dG8gY3Jhc2guPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U28gbWF5YmUgc29tZW9u ZSBjb3VsZCB0ZWxsIG1lIGhvdyB0byBnZXQgbWF4IHRyYW5zbWl0IHNwZWVkIA0KaW4gZGlmZmVy ZW50IHNpdHVhdGlvbnMsc291cmNlIGNvZGUgaXMgYmVzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmsgeW91LjwvRk9OVD48L0RJVj48L0JP RFk+PC9IVE1MPg0K ------=_NextPart_000_001D_01C1E54F.012FC710-- From ydwoo0722@hotmail.com Tue Apr 16 18:07:02 2002 From: ydwoo0722@hotmail.com (=?gb2312?B?zuLRx7arIHd1X3lk?=) Date: Tue Apr 16 17:07:02 2002 Subject: [vortex] re:how to get max speed in different situation Message-ID: from:Wu Yadong in Beijing China Dear sir: I am working on a program written in linux kernel, this program is to test net device such as firewall or vpn,so it has to generate great net traffic.My net card is 3com 3c905,but when I tested a 10Mbps hub,too much traffic would cause net card to crash. So it would be highly appreciated if you would give me some sample source code from which I can get the max supported speed of net card in different situation. I am looking forward to your reply. Best regards. _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄ Web µç×ÓÓʼþϵͳ ¡ª¡ª MSN Hotmail¡£ http://www.hotmail.com/cn From biwu.xie@mic.com.tw Wed Apr 17 00:52:01 2002 From: biwu.xie@mic.com.tw (=?big5?B?Yml3dS54aWUgW8HCpbKqWl0=?=) Date: Tue Apr 16 23:52:01 2002 Subject: [vortex] Sorry to trouble you, I wonder if you could help me. Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E5C3.16D229E0 Content-Type: text/plain; charset="big5" Hi, I have some problems about ethernet diagnostic.I have tried to look for the information about them, but the information are very limited. So I am still puzzled and have no solution. 1) what are MAC loopback and PHY loopback? 2) I know that remote loopback can check PHY/MAC level loop back for each layer health. But how to do remote loopback? Wish you can give me some experience and documents about them. Thank you very much. Best regards. Biwu.xie ------_=_NextPart_001_01C1E5C3.16D229E0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

    Hi,

    I have some problems = about ethernet  diagnostic.I = have tried to look for the information

    about them, but the information = are very limited. So I am still puzzled and have no = solution.

    1) what are MAC loopback and PHY = loopback?

    2) I know that = remote loopback can check PHY/MAC level loop = back for each layer health. But how to do remote = loopback?

       Wish you can give me some = documents about = them.

       Thank you = very much.

    Best regards.

    Biwu.xie

     

    ------_=_NextPart_001_01C1E5C3.16D229E0-- From bogdan.costescu@iwr.uni-heidelberg.de Wed Apr 17 14:28:00 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Wed Apr 17 13:28:00 2002 Subject: [vortex] 802.1q VLAN problem In-Reply-To: Message-ID: On Mon, 15 Apr 2002, SCHIMMEL Guillermo TECHTEL wrote: > Recentrly we have started tests in order to develop a vlan based > network around the 3com vortex card. > The problem is that the driver doesn't like the oversized 1504 bytes > packets that the 802.1q module gives to him. > > Are you aware of that problem? Do you intend to patch the driver? Yes and maybe. First of all, you didn't say which cards/chips you are using; both Cyclone (905B) and Tornado (905C) have some support for over-sized frames, but I don't know about the older ones (as the expression "3Com vortex card" covers quite a lot of them). I don't have the documentation at hand so the following is just from memory: Cyclone and Tornado have support for up to FDDI (4.5 Kb) frames; there is one bit which enables this behaviour. However, I don't know if the VLAN support really needs to have over-sized frame support activated. There is support for ignoring the 4 bytes VLAN tag when computing checksums (in the Rx path or zero-copy Tx path) and this can also be enabled easily. There were some messages on netdev list some weeks ago (unfortunately the archive at http://oss.sgi.com/projects/netdev/archive/ seems to be dead, maybe you can find another one) related to this which included a link to a patch. My feelings on the matter are mixed: I do understand that VLANs are useful (or even required) in some situations or that generally speaking over-sized frames might be useful for more efficient transmission (less header overhead). However, enabling over-sized frames (there is nothing like allow over-size frames up to a variable limit; you can only turn on or off the over-sized frame support) can have bad effects due to: limited FIFO buffers on the card (2 Kib), limited buffers on the switch (today's switches are almost all store-and-forward), incompatibilities which can appear if the recipient(s) of the packet do(es) not have support for over-sized frames (I think that there are switches that do GB Jumbo -> Ethernet conversions, but there are not some to do arbitrary size -> Ethernet conversions). In any case, I'd be willing to spend some time helping adding support to the driver. Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From bogdan.costescu@iwr.uni-heidelberg.de Wed Apr 17 14:32:01 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Wed Apr 17 13:32:01 2002 Subject: [vortex] (no subject) In-Reply-To: Message-ID: On Tue, 16 Apr 2002, Wu Yadong wrote: > I write a program in linux kernel to test net work device such as firewall ,vpn. This program must generate great net traffic, my net card is 3com 3c905. But when I test a 10M bps hub, too much traffic will cause net card to crash. With a 10 Mbps hub, you can easily get collisions when several computers send packets at the same time, so this is not a good testing environment. You should probably get a switch or connect the source of packets and the target directly with a crossover cable. I think that this is not really a vortex specific question, so you might find better results asking on linux-net mailing list. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From greearb@candelatech.com Wed Apr 17 14:52:02 2002 From: greearb@candelatech.com (Ben Greear) Date: Wed Apr 17 13:52:02 2002 Subject: [vortex] 802.1q VLAN problem References: Message-ID: <3CBDB623.6040108@candelatech.com> Bogdan Costescu wrote: > On Mon, 15 Apr 2002, SCHIMMEL Guillermo TECHTEL wrote: > > >> Recentrly we have started tests in order to develop a vlan based >>network around the 3com vortex card. >> The problem is that the driver doesn't like the oversized 1504 bytes >>packets that the 802.1q module gives to him. >> >> Are you aware of that problem? Do you intend to patch the driver? >> > > Yes and maybe. First of all, you didn't say which cards/chips you are > using; both Cyclone (905B) and Tornado (905C) have some support for > over-sized frames, but I don't know about the older ones (as the > expression "3Com vortex card" covers quite a lot of them). > > I don't have the documentation at hand so the following is just from > memory: > > Cyclone and Tornado have support for up to FDDI (4.5 Kb) frames; > there is one bit which enables this behaviour. However, I don't know if > the VLAN support really needs to have over-sized frame support activated. > There is support for ignoring the 4 bytes VLAN tag when computing > checksums (in the Rx path or zero-copy Tx path) and this can also be > enabled easily. > > There were some messages on netdev list some weeks ago (unfortunately > the archive at http://oss.sgi.com/projects/netdev/archive/ seems to be > dead, maybe you can find another one) related to this which included a > link to a patch. > > My feelings on the matter are mixed: I do understand that VLANs are useful > (or even required) in some situations or that generally speaking > over-sized frames might be useful for more efficient transmission (less > header overhead). However, enabling over-sized frames (there is nothing > like allow over-size frames up to a variable limit; you can only turn on > or off the over-sized frame support) can have bad effects due to: limited > FIFO buffers on the card (2 Kib), limited buffers on the switch (today's > switches are almost all store-and-forward), incompatibilities which can > appear if the recipient(s) of the packet do(es) not have support for > over-sized frames (I think that there are switches that do GB Jumbo -> > Ethernet conversions, but there are not some to do arbitrary size -> > Ethernet conversions). In any case, I'd be willing to spend some time > helping adding support to the driver. Just enabling the larger frame sizes does not mean that all of a sudden we'll be using 4k packets, so I think many of your concerns relating to switch support etc are not big problems. Note that the standard VLAN setup does not increase the MTU of the ethernet interface, so the max sized packet will be just 4 bytes bigger than normal. If there are performance tradeoffs, then just having a module variable to toggle VLAN or regular support would be much better than nothing. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From bogdan.costescu@iwr.uni-heidelberg.de Wed Apr 17 14:57:02 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Wed Apr 17 13:57:02 2002 Subject: [vortex] Sorry to trouble you, I wonder if you could help me. In-Reply-To: Message-ID: On Wed, 17 Apr 2002, [big5] biwu.xie [ÁÂ¥²ªZ] wrote: > 1) what are MAC loopback and PHY loopback? AFAIK, a loopback means that the Tx path is wired to the Rx path, so that whatever is sent comes back immediately. The fact that you have them integrated on the card makes easy to test both paths without the need for an external device. > 2) I know that remote loopback can check PHY/MAC level loop back for each > layer health. But how to do remote loopback? Uh, what is a "remote loopback" ? > Wish you can give me some experience and documents about them. You can always register for free as a developer on the 3Com site and have access to the documentation in PDF format. That's all I have, anyway. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From gschimmel@techtel.com.ar Wed Apr 17 15:55:01 2002 From: gschimmel@techtel.com.ar (SCHIMMEL Guillermo TECHTEL) Date: Wed Apr 17 14:55:01 2002 Subject: [vortex] 802.1q VLAN problem Message-ID: Hi, and thank you for taking the time to answer my question. The cards that we are using are of a lot of models (all 3com). However we can use the 3c905C or whichever that can actually understand the vlan frame. I do not intend to start playing with 4k packets, I just want to do inter vlan routing with a PC and a Cisco 2900 switch. As in the same PC I also have a STM-1 card, I'll save a lot of money. It's a shame that the only limitation to that is that the driver doesn't like that 4 bytes. More even knowing that the hardware itself supports that. Any help would be really apreciated. Thanks again for your time. Guillermo > -----Mensaje original----- > De: Bogdan Costescu [mailto:bogdan.costescu@iwr.uni-heidelberg.de] > Enviado el: Wednesday, April 17, 2002 2:27 PM > Para: SCHIMMEL Guillermo TECHTEL > Cc: 'vortex@scyld.com' > Asunto: Re: [vortex] 802.1q VLAN problem > > > On Mon, 15 Apr 2002, SCHIMMEL Guillermo TECHTEL wrote: > > > Recentrly we have started tests in order to develop a vlan based > > network around the 3com vortex card. > > The problem is that the driver doesn't like the > oversized 1504 bytes > > packets that the 802.1q module gives to him. > > > > Are you aware of that problem? Do you intend to patch > the driver? > > Yes and maybe. First of all, you didn't say which cards/chips you are > using; both Cyclone (905B) and Tornado (905C) have some support for > over-sized frames, but I don't know about the older ones (as the > expression "3Com vortex card" covers quite a lot of them). > > I don't have the documentation at hand so the following is just from > memory: > > Cyclone and Tornado have support for up to FDDI (4.5 Kb) frames; > there is one bit which enables this behaviour. However, I > don't know if > the VLAN support really needs to have over-sized frame > support activated. > There is support for ignoring the 4 bytes VLAN tag when computing > checksums (in the Rx path or zero-copy Tx path) and this can also be > enabled easily. > > There were some messages on netdev list some weeks ago (unfortunately > the archive at http://oss.sgi.com/projects/netdev/archive/ > seems to be > dead, maybe you can find another one) related to this which > included a > link to a patch. > > My feelings on the matter are mixed: I do understand that > VLANs are useful > (or even required) in some situations or that generally speaking > over-sized frames might be useful for more efficient > transmission (less > header overhead). However, enabling over-sized frames (there > is nothing > like allow over-size frames up to a variable limit; you can > only turn on > or off the over-sized frame support) can have bad effects due > to: limited > FIFO buffers on the card (2 Kib), limited buffers on the > switch (today's > switches are almost all store-and-forward), incompatibilities > which can > appear if the recipient(s) of the packet do(es) not have support for > over-sized frames (I think that there are switches that do GB > Jumbo -> > Ethernet conversions, but there are not some to do arbitrary size -> > Ethernet conversions). In any case, I'd be willing to spend some time > helping adding support to the driver. > > Bogdan Costescu > > IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen > Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY > Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 > E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De > > > From becker@scyld.com Wed Apr 17 16:55:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Apr 17 15:55:01 2002 Subject: [vortex] Sorry to trouble you, I wonder if you could help me. In-Reply-To: Message-ID: On Wed, 17 Apr 2002, Bogdan Costescu wrote: > On Wed, 17 Apr 2002, [big5] biwu.xie [ÁÂ¥²ªZ] wrote: > > 1) what are MAC loopback and PHY loopback? [[ I answered this one privately earlier today. ]] > > 2) I know that remote loopback can check PHY/MAC level loop back for each > > layer health. But how to do remote loopback? > > Uh, what is a "remote loopback" ? Loopback past the PHY (transceiver). It used to be implemented with a relay or a physical plug. Picture a RJ45 with a 2" loop of wire feeding the Tx back to the Rx pair. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From biwu.xie@mic.com.tw Thu Apr 18 00:34:02 2002 From: biwu.xie@mic.com.tw (BIWU.XIE) Date: Wed Apr 17 23:34:02 2002 Subject: [vortex] Sorry to trouble you, I wonder if you could help me. Message-ID: Dear Boqdan, Thank you for your help and kindness. Now I know more about MAC loopback and PHY loopback. :-) Exactly how to do remote loopback control is an issue. somebody is trying to decide. In general, a signal is sent to the other end of the link. That signal may be carried within the preamble bits or within an Ethernet control frame. The signal is intepreted by the far end as an indication to go into loopback mode, where either bits or frames are received and then echoed out the interface. I want to know what your idear about that? You know that the MAC loopback test occurs before the transceiver, while the PHY loopback occurs after the transceiver. So I have another detail questions: How to decide the MAC loopback test and the PHY loopback test success or failed? Best regards. Biwu.xie -----Original Message----- From: Bogdan Costescu [mailto:bogdan.costescu@iwr.uni-heidelberg.de] Sent: 2002?4?18? 1:57 To: biwu.xie [???] Cc: 'vortex@scyld.com' Subject: Re: [vortex] Sorry to trouble you, I wonder if you could help me. On Wed, 17 Apr 2002, [big5] biwu.xie [ÁÂ¥²ªZ] wrote: > 1) what are MAC loopback and PHY loopback? AFAIK, a loopback means that the Tx path is wired to the Rx path, so that whatever is sent comes back immediately. The fact that you have them integrated on the card makes easy to test both paths without the need for an external device. > 2) I know that remote loopback can check PHY/MAC level loop back for each > layer health. But how to do remote loopback? Uh, what is a "remote loopback" ? > Wish you can give me some experience and documents about them. You can always register for free as a developer on the 3Com site and have access to the documentation in PDF format. That's all I have, anyway. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From bogdan.costescu@iwr.uni-heidelberg.de Thu Apr 18 09:44:01 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Thu Apr 18 08:44:01 2002 Subject: [vortex] Sorry to trouble you, I wonder if you could help me. In-Reply-To: Message-ID: On Thu, 18 Apr 2002, BIWU.XIE wrote: > Exactly how to do remote loopback control is an issue. somebody is > trying to decide. In general, a signal is sent to the other end of the > link. That signal may be carried within the preamble bits or within an > Ethernet control frame. The signal is intepreted by the far end as an > indication to go into loopback mode, where either bits or frames are > received and then echoed out the interface. Err, in the previous message Donald said that this is a hardware device which just links Rx to Tx (I've used one of those some years ago, just didn't know how it's called). Now you say (if I understand your statement) that this should be a feature _on the card_ which can be controlled remotely. So I don't understand anymore... Anyway, there is nothing in the documentation about what you are asking. I think that this would be a _very big_ design mistake as that would allow anybody on the local network to just stop the networking on any remote computer by putting it in loopback mode. Plus, I don't understand what would be the purpose: you'd be able to test cabling and maybe some intermediate device (hub/switch) ? This can probably be better done in software, by receiving a packet and putting it as early as possible back into the Tx queue; however, that means that what is going over the wire should be a valid packet. > How to decide the MAC loopback test and the PHY loopback test success or > failed? There are some diagnostic bits which can give at least partly information about the health status of the card, check the documentation. In the AutoSelect sequence there is even a description for a check for media where the presence of the link cannot be determined easily (like a link beat) and where a valid packet has to be sent and some answer received; you could use it for loopback too. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From hansv@jazzter.xs4all.nl Thu Apr 18 13:19:02 2002 From: hansv@jazzter.xs4all.nl (Hans Voss) Date: Thu Apr 18 12:19:02 2002 Subject: [vortex] Multiple 3c905C cards in machine not working? Message-ID: <11884.213.84.174.81.1019144070.squirrel@webmail.xs4all.nl> Hello list, (1st I appologize if this is covered in some FAQ or somesuch, but I am slightly stressed out at the moment). I have a Slackware Linux box (2.4.5) with 3 3c905C cards in it. The cards are properly detected by the 'vortex' driver. However I can't connect with them to my network. (I did with one). Now I think I have an interrupt problem (all cards share IRQ10). But I can't find a way to change this (going into the system BIOS is not an option (an older Compaq Deskpro with a new, blank harddisk has NO bios setup program to use :-(. Does the list have any idea how I can achieve what I need? -- Hans Voss CMG Public Sector B.V. hansv@jazzter.xs4all.nl PGP Public Key: http://www.xs4all.nl/~hvoss/pgppublic.htm From bogdan.costescu@iwr.uni-heidelberg.de Thu Apr 18 13:46:01 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Thu Apr 18 12:46:01 2002 Subject: [vortex] 802.1q VLAN problem In-Reply-To: <3CBDB623.6040108@candelatech.com> Message-ID: On Wed, 17 Apr 2002, Ben Greear wrote: > Just enabling the larger frame sizes does not mean that all of a sudden we'll > be using 4k packets, so I think many of your concerns relating to switch support > etc are not big problems. Note that the standard VLAN setup does not increase > the MTU of the ethernet interface, so the max sized packet will be just 4 bytes > bigger than normal. I can see that our views differ: I was thinking of adding over-sized frame support with the added benefit of supporting VLAN, while you are probably thinking about adding VLAN support with the added benefit of supporting over-sized frames. 8-) > If there are performance tradeoffs, then just having a module variable to > toggle VLAN or regular support would be much better than nothing. I've taken a short look at the existing patches and it seems that the "always-on" mode of accepting VLAN or over-sized frames was already discussed. Probably a module option is the best solution, with the default "off". Is there any common name for such a module option ? I've taken a look through the documentation and I found out that: - Boomerang only has an "allowLargePackets" bit in MacControl register, so it's all-or-nothing. I don't have documentation for older chips. - Cyclone has "allowLargePackets", but also has a "MaxPktSize" register which defines when the oversizedFrame error occurs. - Tornado has "allowLargePackets", "MaxPktSize" and goes one step further with another MacControl bit (10) call "vlanOversizeEn" which if set, allows packets to be 4 bytes more than "MaxPktSize" before signaling the oversizedFrame error. So, IMHO the easiest to add support for VLAN is Tornado where only the "vlanOversizeEn" bit should be set; for Cyclone, "MaxPktSize" should be set to MTU+4. As the method for Cyclone should work for both, we should probably use it in both cases in order not to introduce extra complexity in the code. OTOH, the driver doesn't take advantage of the MTU size, it only sets the "allowLargePackets" bit when MTU > 1500, all skb allocations are done based on PKT_BUF_SZ, so to properly support different MTU sizes more changes to the driver are needed... Any thoughts ? -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From greearb@candelatech.com Thu Apr 18 14:10:00 2002 From: greearb@candelatech.com (Ben Greear) Date: Thu Apr 18 13:10:00 2002 Subject: [vortex] 802.1q VLAN problem References: Message-ID: <3CBEFDBE.2040808@candelatech.com> Bogdan Costescu wrote: > On Wed, 17 Apr 2002, Ben Greear wrote: > > >>Just enabling the larger frame sizes does not mean that all of a sudden we'll >>be using 4k packets, so I think many of your concerns relating to switch support >>etc are not big problems. Note that the standard VLAN setup does not increase >>the MTU of the ethernet interface, so the max sized packet will be just 4 bytes >>bigger than normal. >> > > I can see that our views differ: I was thinking of adding over-sized frame > support with the added benefit of supporting VLAN, while you are probably > thinking about adding VLAN support with the added benefit of supporting > over-sized frames. 8-) Hehe, I like both features, so whatever motivation we have, the end result should be good for all! :) > > >>If there are performance tradeoffs, then just having a module variable to >>toggle VLAN or regular support would be much better than nothing. >> > > I've taken a short look at the existing patches and it seems that the > "always-on" mode of accepting VLAN or over-sized frames was already > discussed. Probably a module option is the best solution, with the > default "off". Is there any common name for such a module option ? Consider programatic driver hooks to allow the vlan code to enable the feature run-time too? (An IOCTL would be fine, as the vconfig program could attempt it, maybe IOCTL_VLAN_ENABLE). I believe Dave added a nice clean interface for this kind of thing to 2.5, btw). > > I've taken a look through the documentation and I found out that: > > - Boomerang only has an "allowLargePackets" bit in MacControl register, so > it's all-or-nothing. I don't have documentation for older chips. Seems a good module-load time option. > - Cyclone has "allowLargePackets", but also has a "MaxPktSize" register > which defines when the oversizedFrame error occurs. Since you can increase this by only 4 if you wish, this might be a good feature to have default to ON. > - Tornado has "allowLargePackets", "MaxPktSize" and goes one step further > with another MacControl bit (10) call "vlanOversizeEn" which if set, > allows packets to be 4 bytes more than "MaxPktSize" before signaling the > oversizedFrame error. Even better, in this case it looks like you could enable the vlanOversizeEn bit by default w/out any other hackery. I can't imagine this would effect performance, but I obviously haven't tested it to be sure... > So, IMHO the easiest to add support for VLAN is Tornado where only the > "vlanOversizeEn" bit should be set; for Cyclone, "MaxPktSize" should be > set to MTU+4. As the method for Cyclone should work for both, we > should probably use it in both cases in order not to introduce extra > complexity in the code. OTOH, the driver doesn't take advantage of the MTU > size, it only sets the "allowLargePackets" bit when MTU > 1500, all skb > allocations are done based on PKT_BUF_SZ, so to properly support different > MTU sizes more changes to the driver are needed... Yes, I can see there would be more work to support larger (ie, 4k packets), but the wee little 4 extra bytes for vlan shouldn't cause any problems :) Thanks, Ben > > Any thoughts ? > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From ruben@blacklisted.nl Thu Apr 18 14:28:02 2002 From: ruben@blacklisted.nl (Ruben van der Leij) Date: Thu Apr 18 13:28:02 2002 Subject: [vortex] Re: 802.1q VLAN problem In-Reply-To: References: Message-ID: <20020418172750.GB25733@blacklisted.nl> +++ SCHIMMEL Guillermo TECHTEL [17/04/02 15:03 -0300]: > I do not intend to start playing with 4k packets, I just want to do inter > vlan routing with a PC and a Cisco 2900 switch. Note that ISL and 802.1q/802.10 differs with regards to packetsize. Cisco says this about the subject: "The biggest implication for systems using ISL encapsulation is that the encapsulation is a total of 30 bytes and fragmentation is not required. Therefore, if the encapsulated packet is 1518 bytes long, the ISL packet will be 1548 bytes long for Ethernet. Additionally, if packets other than Ethernet packets are encapsulated, the maximum length can be greatly increased. This length change must be considered when evaluating whether a MAC can support ISL packets. Another system implication is that ISL packets contain two FCSs. One on the internal encapsulated packet, and another covering the entire ISL packet. If the original data does not contain a valid CRC, two will have to be calculated as the packet is transmitted and the invalid CRC will not be detected until the ISL header is stripped off and the end device checks the encapsulated FCS. This typically is not a problem for switching hardware, but may be difficult for routers and Network Interface Cards (NICs)." http://www.cisco.com/warp/public/473/#Trunking http://www.cisco.com/warp/public/473/741_3.html http://www.cisco.com/warp/public/473/741_4.html HTH, HAND. :) -- Ruben van der Leij Bride, n.: A woman with a fine prospect of happiness behind her. -- Ambrose Bierce, "The Devil's Dictionary" From ruben@blacklisted.nl Thu Apr 18 14:38:01 2002 From: ruben@blacklisted.nl (Ruben van der Leij) Date: Thu Apr 18 13:38:01 2002 Subject: [vortex] Re: Multiple 3c905C cards in machine not working? In-Reply-To: <11884.213.84.174.81.1019144070.squirrel@webmail.xs4all.nl> References: <11884.213.84.174.81.1019144070.squirrel@webmail.xs4all.nl> Message-ID: <20020418173708.GC25733@blacklisted.nl> +++ Hans Voss [18/04/02 17:34 +0200]: > Does the list have any idea how I can achieve what I need? No need to. On PCI interrupt-sharing works. Just alias all three eth*'s to 3c90x in /etc/conf.modules, (or /etc/modules.conf) or be lazy and use some tool like linuxconf to configure them. cat /etc/modules.conf alias eth0 3c90x alias eth1 3c90x alias eth2 3c90x You can check wether you system see's all three of them with either lspci (which interprets and formats nicely) or the ugly way with 'cat /proc/pci' /sbin/lspci 00:0d.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) 00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) 00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) -- Ruben van der Leij Rule of Defactualization: Information deteriorates upward through bureaucracies. From verch@panix.com Thu Apr 18 17:49:00 2002 From: verch@panix.com (Jason Verch) Date: Thu Apr 18 16:49:00 2002 Subject: [vortex] programatically disable PXE? Message-ID: <200204182048.g3IKmSN09815@panix3.panix.com> First off, sorry if this list isn't the place to ask about this.. Its the most appropriate forum I've found.. I'm looking for a program under linux that can turn PXE booting on and off on a 3c905B-TX. I want a way to automate things instead of having to go into BIOS while the PC is booting and change it. Using vortex-diag and comparing the registry dumps with it enabled and disabled I think I've found the bits that get twidddled, but I'm not sure how to twiddle them. A search of the net has come up with suprisingly little. Any help/pointers appreciated. Thanks! -Jason From ydwoo0722@hotmail.com Fri Apr 19 04:07:01 2002 From: ydwoo0722@hotmail.com (Wu Yadong) Date: Fri Apr 19 03:07:01 2002 Subject: [vortex] re:how to avoid net card crash Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C1E7B1.77BBF980 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB3cml0ZSBhIHByb2dyYW0gaW4gbGludXgga2VybmVsIHRvIHRlc3QgbmV0IHdvcmsgZGV2aWNl IHN1Y2ggYXMgZmlyZXdhbGwgLHZwbiBpbiBkaWZmZXJlbnQgc2l0dWF0aW9ucy4gVGhpcyBwcm9n cmFtIG11c3QgZ2VuZXJhdGUgZ3JlYXQgbmV0IHRyYWZmaWMsIG15IG5ldCBjYXJkIGlzIDNjb20g M2M5MDUuIFdoZW4gSSB0ZXN0IDEwMCBNYnBzIGh1YiwgZXZlcnl0aGluZyBpcyBvay4gQnV0IHdo ZW4gSSB0ZXN0IGEgMTBiYXNlLVQgaHViLGV2ZW4gaWYgbXkgc2VuZGluZyBzcGVlZCBub3QgZXhj ZWVkIDEwIE1icHMsIHNvbWV0aW1lcyBuZXQgY2FyZCB3aWxsIGNyYXNoLg0KDQpJcyB0aGVyZSBz b21ldGhpbmcgd2hpY2ggY2FuIGF2b2lkIHRoaXM/IFNob3VsZCBJIGFkanVzdCBzZW5kaW5nIHNw ZWVkIHdoaWxlIHRlc3RpbmcsIG9yIGRvIHNvbWV0aGluZyBlbHNlKCB3YWl0IHVudGlsIGFsbCBm cmFtZXMgaW4gcXVldWUgaGF2ZSBiZWVuIHNlbnQpPw0KDQpUaGFuayB5b3UuDQo= ------=_NextPart_000_0087_01C1E7B1.77BBF980 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEZPTlQgc2l6ZT0y Pkkgd3JpdGUgYSBwcm9ncmFtIGluIGxpbnV4IGtlcm5lbCB0byB0ZXN0IG5ldCB3b3JrIGRldmlj ZSBzdWNoIA0KYXMgZmlyZXdhbGwgLHZwbiBpbiBkaWZmZXJlbnQgc2l0dWF0aW9ucy4gVGhpcyBw cm9ncmFtIG11c3QgZ2VuZXJhdGUgZ3JlYXQgbmV0IA0KdHJhZmZpYywgbXkgbmV0IGNhcmQgaXMg M2NvbSAzYzkwNS4gV2hlbiBJIHRlc3QgMTAwIE1icHMgaHViLCBldmVyeXRoaW5nIGlzIG9rLiAN CkJ1dCB3aGVuIEkgdGVzdCBhIDEwYmFzZS1UIGh1YixldmVuIGlmIG15IHNlbmRpbmcgc3BlZWQg bm90IGV4Y2VlZCAxMCBNYnBzLCANCnNvbWV0aW1lcyBuZXQgY2FyZCB3aWxsIGNyYXNoLjwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPklzIHRoZXJlIHNvbWV0aGluZyB3aGlj aCBjYW4gYXZvaWQgdGhpcz8mbmJzcDtTaG91bGQgSSBhZGp1c3Qgc2VuZGluZyBzcGVlZCANCndo aWxlIHRlc3RpbmcsIG9yIGRvIHNvbWV0aGluZyBlbHNlKCB3YWl0IHVudGlsIGFsbCBmcmFtZXMg aW4gcXVldWUgaGF2ZSBiZWVuIA0Kc2VudCk/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+VGhhbmsgeW91LjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZ PjwvSFRNTD4NCg== ------=_NextPart_000_0087_01C1E7B1.77BBF980-- From ydwoo0722@hotmail.com Fri Apr 19 04:39:01 2002 From: ydwoo0722@hotmail.com (Wu Yadong) Date: Fri Apr 19 03:39:01 2002 Subject: [vortex] re :message when net card crash Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C1E7B7.38094E90 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB3cml0ZSBhIHByb2dyYW0gaW4gbGludXgga2VybmVsIHRvIHRlc3QgbmV0IHdvcmsgZGV2aWNl IHN1Y2ggYXMgZmlyZXdhbGwgLHZwbiBpbiBkaWZmZXJlbnQgc2l0dWF0aW9ucy4gVGhpcyBwcm9n cmFtIG11c3QgZ2VuZXJhdGUgZ3JlYXQgbmV0IHRyYWZmaWMsIG15IG5ldCBjYXJkIGlzIDNjb20g M2M5MDUuIFdoZW4gSSB0ZXN0IDEwMCBNYnBzIGh1YiwgZXZlcnl0aGluZyBpcyBvay4gQnV0IHdo ZW4gSSB0ZXN0IGEgMTBiYXNlLVQgaHViLGV2ZW4gaWYgbXkgc2VuZGluZyBzcGVlZCBub3QgZXhj ZWVkIDEwIE1icHMsIHNvbWV0aW1lcyBuZXQgY2FyZCB3aWxsIGNyYXNoLg0KDQpXaGVuIG5ldCBj YXJkIGNyYXNoICwgc3lzdGVtIGlzIG9rICxvdGhlciBwcm9jZXNzZXMgY2FuIHJ1biB3aXRob3V0 IHByb2JsZW1zLCB0aGUgbmV0IGNhcmQgY2FuIG5vdCBzZW5kIGZyYW1lcyBhbnkgbW9yZSwgYW5k IHRoZSBzY3JlZW4gIHdpbGwgY29udGludW91c2x5IGRpc3BsYXkgYmVsb3cgbWVzc2FnZXMgdW50 aWwgc3lzdGVtIHNodXQgZG93biA6DQoNCmV0aDA6dHJhbnNtaXQgdGltZWQgb3V0LCB0eF9zdGF0 dXMgMDAgc3RhdHVzIGUwMDAuDQpGbGFncztidXMtbWFzdGVyIDEsZnVsbCAxO2RpcnR5IDMxMjk1 Myg5KSBjdXJyZW50IDMxMjk2OSg5KS4NClRyYW5zbWl0IGxpc3QgMDEyYjkyOTAgdnMuIGMxMmI5 MjkwLg0KZm9sbG93ZWQgYnkgYSBsaXN0IG9mIGZyYW1lcw0KDQpJcyB0aGVyZSBzb21ldGhpbmcg d2hpY2ggSSBjYW4gZG8gdG8gYXZvaWQgdGhpcz8gU2hvdWxkIEkgYWRqdXN0IHNlbmRpbmcgc3Bl ZWQgd2hpbGUgdGVzdGluZywgb3IgZG8gc29tZXRoaW5nIGVsc2UoIHdhaXQgdW50aWwgYWxsIGZy YW1lcyBpbiBxdWV1ZSBoYXZlIGJlZW4gc2VudCk/DQoNClRoYW5rIHlvdS4NCg== ------=_NextPart_000_0043_01C1E7B7.38094E90 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEZPTlQgc2l6ZT0y Pg0KPERJVj48Rk9OVCBzaXplPTI+SSB3cml0ZSBhIHByb2dyYW0gaW4gbGludXgga2VybmVsIHRv IHRlc3QgbmV0IHdvcmsgZGV2aWNlIHN1Y2ggDQphcyBmaXJld2FsbCAsdnBuIGluIGRpZmZlcmVu dCBzaXR1YXRpb25zLiBUaGlzIHByb2dyYW0gbXVzdCBnZW5lcmF0ZSBncmVhdCBuZXQgDQp0cmFm ZmljLCBteSBuZXQgY2FyZCBpcyAzY29tIDNjOTA1LiBXaGVuIEkgdGVzdCAxMDAgTWJwcyBodWIs IGV2ZXJ5dGhpbmcgaXMgb2suIA0KQnV0IHdoZW4gSSB0ZXN0IGEgMTBiYXNlLVQgaHViLGV2ZW4g aWYgbXkgc2VuZGluZyBzcGVlZCBub3QgZXhjZWVkIDEwIE1icHMsIA0Kc29tZXRpbWVzIG5ldCBj YXJkIHdpbGwgY3Jhc2guPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+V2hl biBuZXQgY2FyZCBjcmFzaCAsIHN5c3RlbSBpcyBvayAsb3RoZXIgcHJvY2Vzc2VzIGNhbiBydW4g d2l0aG91dCANCnByb2JsZW1zLCZuYnNwO3RoZSBuZXQgY2FyZCBjYW4gbm90IHNlbmQgZnJhbWVz IGFueSBtb3JlLCBhbmQgdGhlIHNjcmVlbiAgd2lsbCANCmNvbnRpbnVvdXNseSBkaXNwbGF5IGJl bG93IG1lc3NhZ2VzIHVudGlsIHN5c3RlbSBzaHV0IGRvd24mbmJzcDs6PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5ldGgwOnRyYW5zbWl0IHRpbWVkIG91dCwgdHhfc3RhdHVzIDAwIHN0 YXR1cyBlMDAwLjwvRElWPg0KPERJVj5GbGFncztidXMtbWFzdGVyIDEsZnVsbCAxO2RpcnR5IDMx Mjk1Myg5KSBjdXJyZW50IDMxMjk2OSg5KS48L0RJVj4NCjxESVY+VHJhbnNtaXQgbGlzdCAwMTJi OTI5MCB2cy4gYzEyYjkyOTAuPC9ESVY+DQo8RElWPmZvbGxvd2VkIGJ5IGEgbGlzdCBvZiBmcmFt ZXM8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPklzIHRoZXJlIHNvbWV0aGluZyB3aGlj aCBJIGNhbiBkbyB0byBhdm9pZCB0aGlzPyZuYnNwO1Nob3VsZCBJIGFkanVzdCANCnNlbmRpbmcg c3BlZWQgd2hpbGUgdGVzdGluZywgb3IgZG8gc29tZXRoaW5nIGVsc2UoIHdhaXQgdW50aWwgYWxs IGZyYW1lcyBpbiANCnF1ZXVlIGhhdmUgYmVlbiBzZW50KT88L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFuayANCnlvdS48L0ZPTlQ+PC9ESVY+PC9GT05UPjwv RElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0043_01C1E7B7.38094E90-- From bogdan.costescu@iwr.uni-heidelberg.de Fri Apr 19 07:08:01 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Fri Apr 19 06:08:01 2002 Subject: [vortex] re :message when net card crash In-Reply-To: Message-ID: On Fri, 19 Apr 2002, Wu Yadong wrote: > When net card crash , system is ok ,other processes can run without problems, the net card can not send frames any more, and the screen will continuously display below messages until system shut down : > > eth0:transmit timed out, tx_status 00 status e000. > Flags;bus-master 1,full 1;dirty 312953(9) current 312969(9). ^^^^^^ - what kernel/driver version is this ? > Transmit list 012b9290 vs. c12b9290. > followed by a list of frames OK, more details this time, better chances to diagnoze. First, check if there are no other error messages from the driver - the one liners can easily be overlooked through the tens of lines the Tx timeouts write. A Tx timeout is nothing special on a 10baseT hub. Because of the lower speed (compared with a 100baseTx one) and the fact that is a hub (so it's affected by collisions), the Tx queue can stay full for some time and the Tx timeout condition be triggered more often than for a 100baseTx one. You can try to increase the Tx timeout value and see what happens. > Is there something which I can do to avoid this? Should I adjust sending speed while testing, or do something else( wait until all frames in queue have been sent)? The return value of the dev_start_xmit function can tell if the packet was succesfully queued or not, in which case most likely the queue is full. But I don't know if your packet generator is so low level to have access to this info. Limiting sending speed might not be a solution, as even with a low one there might a situation when packets are just sitting in the queue and accumulate and some time later the Tx timeout will occur. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From bogdan.costescu@iwr.uni-heidelberg.de Fri Apr 19 07:15:02 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Fri Apr 19 06:15:02 2002 Subject: [vortex] programatically disable PXE? In-Reply-To: <200204182048.g3IKmSN09815@panix3.panix.com> Message-ID: On Thu, 18 Apr 2002, Jason Verch wrote: > I'm looking for a program under linux that can turn PXE booting > on and off on a 3c905B-TX. I want a way to automate things instead of having > to go into BIOS while the PC is booting and change it. See: http://www.iwr.uni-heidelberg.de/groups/biocomp/bogdan/tornado/ As these features didn't receive much testing, please post your results (either good or bad). -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From bogdan.costescu@iwr.uni-heidelberg.de Fri Apr 19 07:29:01 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Fri Apr 19 06:29:01 2002 Subject: [vortex] 802.1q VLAN problem In-Reply-To: <3CBEFDBE.2040808@candelatech.com> Message-ID: On Thu, 18 Apr 2002, Ben Greear wrote: > Consider programatic driver hooks to allow the vlan code to enable > the feature run-time too? (An IOCTL would be fine, as the vconfig > program could attempt it, maybe IOCTL_VLAN_ENABLE). I believe Dave > added a nice clean interface for this kind of thing to 2.5, btw). No, at least at the beginning, but I will try to make everything modular so that they can be called from up()/open() at init time based on module options or later from ioctl/ethtool/whatever. I couldn't find anything that would suggest races/misbehaviour if these features are enabled while the interface is UP/RUNNING. > Yes, I can see there would be more work to support larger (ie, 4k packets), > but the wee little 4 extra bytes for vlan shouldn't cause any problems :) Yep, I'll try to split it into 2 parts: one that does the VLAN part (which doesn't really depend on MTU size) and one that allows variable MTU. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From bogdan.costescu@IWR.Uni-Heidelberg.De Fri Apr 19 16:49:01 2002 From: bogdan.costescu@IWR.Uni-Heidelberg.De (Bogdan Costescu) Date: Fri Apr 19 15:49:01 2002 Subject: [vortex] programatically disable PXE? In-Reply-To: <200204191458.g3JEwdZ15435@panix2.panix.com> Message-ID: On Fri, 19 Apr 2002, Jason Verch wrote: > Unfortunately my results were bad. :( It claims to be writing > the settings, but it seems to have no effect. If you want any more details > to try and debug, feel free to ask. What sort of hardware have you run it > on? I'm trying it on a dell optiplex GX1 where the 3c905B is onboard. Are you sure that you used the "-w" option (which is mentioned on the web page) ? By default vortex-diag does not touch the EEPROM content, it only prints what it thinks the differences are. Can you just send me the output from "vortex-diag -ee" ? I ran it on 3c905C (normal PCI card). -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From verch@panix.com Fri Apr 19 20:31:02 2002 From: verch@panix.com (Jason Verch) Date: Fri Apr 19 19:31:02 2002 Subject: [vortex] programatically disable PXE? In-Reply-To: from "Bogdan Costescu" at Apr 19, 2002 12:10:49 PM Message-ID: <200204191458.g3JEwdZ15435@panix2.panix.com> Unfortunately my results were bad. :( It claims to be writing the settings, but it seems to have no effect. If you want any more details to try and debug, feel free to ask. What sort of hardware have you run it on? I'm trying it on a dell optiplex GX1 where the 3c905B is onboard. Thanks, -Jason > http://www.iwr.uni-heidelberg.de/groups/biocomp/bogdan/tornado/ > > As these features didn't receive much testing, please post your results > (either good or bad). > > -- > Bogdan Costescu From ydwoo0722@hotmail.com Sun Apr 21 09:13:03 2002 From: ydwoo0722@hotmail.com (Wu Yadong) Date: Sun Apr 21 08:13:03 2002 Subject: [vortex] re :message when net card crash References: Message-ID: ----- Original Message ----- From: "Bogdan Costescu" To: "Wu Yadong" Cc: Sent: Friday, April 19, 2002 6:06 PM Subject: Re: [vortex] re :message when net card crash > On Fri, 19 Apr 2002, Wu Yadong wrote: > > > When net card crash , system is ok ,other processes can run without problems, the net card can not send frames any more, and the screen will continuously display below messages until system shut down : > > > > eth0:transmit timed out, tx_status 00 status e000. > > Flags;bus-master 1,full 1;dirty 312953(9) current 312969(9). > > ^^^^^^ - what kernel/driver version is this ? > > > Transmit list 012b9290 vs. c12b9290. > > followed by a list of frames > > OK, more details this time, better chances to diagnoze. First, check if > there are no other error messages from the driver - the one liners can > easily be overlooked through the tens of lines the Tx timeouts write. > > A Tx timeout is nothing special on a 10baseT hub. Because of the lower > speed (compared with a 100baseTx one) and the fact that is a hub (so it's > affected by collisions), the Tx queue can stay full for some time and the > Tx timeout condition be triggered more often than for a 100baseTx one. > You can try to increase the Tx timeout value and see what happens. > > > Is there something which I can do to avoid this? Should I adjust sending speed while testing, or do something else( wait until all frames in queue have been sent)? > > The return value of the dev_start_xmit function can tell if the packet was > succesfully queued or not, in which case most likely the queue is full. > But I don't know if your packet generator is so low level to have access > to this info. > > Limiting sending speed might not be a solution, as even with a low one > there might a situation when packets are just sitting in the queue and > accumulate and some time later the Tx timeout will occur. > > -- > Bogdan Costescu > > IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen > Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY > Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 > E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De > > _______________________________________________ > vortex mailing list > vortex@scyld.com > http://www.scyld.com/mailman/listinfo/vortex > Thank Mr Bogdan Costescu for kindly answering my question. My kernel version is 2.4.0, and driver version is 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html " "$Revision: 1.102.2.46 $\n". As you mention, there are error messages in lines timeout write: eth1 :command 0x3002 did not complete, status=0xf401 or status=0xf000 but it is strange that always eth0 crashed, but eth0 did not write above messages, only eth1 did write above message and eth1 did not crash, and eth0 only write timeout messages. I use dev_queue_xmit function to send frames.Is the function dev_start_xmit you mention is vortex_start_xmit. Thank you. From bogdan.costescu@iwr.uni-heidelberg.de Sun Apr 21 19:46:01 2002 From: bogdan.costescu@iwr.uni-heidelberg.de (Bogdan Costescu) Date: Sun Apr 21 18:46:01 2002 Subject: [vortex] MTU/VLAN support for 3c59x Message-ID: Hi, There is a patch at: http://www.iwr.uni-heidelberg.de/groups/biocomp/bogdan/tornado/ which adds support for different MTU sizes and VLAN to the 3c59x.c driver from kernel 2.4.18 (LK1.1.16). I couldn't test the new features apart from the fact that the driver doesn't oops because I only have one box to play with at the moment; the functionality for standard MTU seems to remain unchanged. So those of you brave enough (or forced 8-)) to use it, please send feedback; only after I get enough good reports I'll think about implementing the run-time stuff. And most important: if you have opinions/ideas about the code and/or the remarks on the web page, please send them to the list. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From becker@scyld.com Sun Apr 21 23:53:01 2002 From: becker@scyld.com (Donald Becker) Date: Sun Apr 21 22:53:01 2002 Subject: [vortex] programatically disable PXE? In-Reply-To: <200204182048.g3IKmSN09815@panix3.panix.com> Message-ID: On Thu, 18 Apr 2002, Jason Verch wrote: > First off, sorry if this list isn't the place to ask about this.. This is the correct list for this question. > I'm looking for a program under linux that can turn PXE booting > on and off on a 3c905B-TX. I want a way to automate things instead of having > to go into BIOS while the PC is booting and change it. Using vortex-diag and > comparing the registry dumps with it enabled and disabled I think I've found > the bits that get twidddled, but I'm not sure how to twiddle them. Which EEPROM bits are you seeing changed? The option that changes the boot ROM configuration in the EEPROM is mostly undocumented. I haven't yet figured out the general case, and thus some diagnostic programs have ad hoc code. The code is around line 747, and is triggered with the '-P' option. You will have to edit vortex-diag.c to have it set the value you wish. Change the '0x3001' at line 749 to the proper value. I don't have the datasheet here, but I think the correct value is 0x3000. I comment on what the code is doing: /* If -P is passed. */ if (set_ee_rom) { /* Used for calculating the checksum. */ unsigned short sum = 0; /* We will be working on a copy. Note that we should be using ee_tbl_offset here and below! */ memcpy(new_ee_contents, eeprom_contents, eesize << 1); /* Set the boot ROM size. */ new_ee_contents[9] = 0x3001; /* Recalculate the checksum: This calculation is valid for the Cyclone only, while we may have a Vortex or Hurricane. */ for (i = 0; i < 0x1B; i++) sum ^= new_ee_contents[i]; new_ee_contents[0x20] = (sum ^ (sum>>8)) & 0xff; printf("Setting the EEPROM BIOS ROM field to %4.4x, new checksum " "%2.2x.\n", new_ee_contents[9], new_ee_contents[0x20]); /* Do the write. Re-read rather than assume that it worked. */ do_update(ioaddr, eeaddrlen, new_ee_contents, eeprom_contents); for (i = 0; i < eesize; i++) eeprom_contents[i] = read_eeprom(ioaddr, eeaddrlen, i); } -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From pemmaiah@cc.usu.edu Tue Apr 23 07:23:02 2002 From: pemmaiah@cc.usu.edu (Napanda. C. Pemmaiah) Date: Tue Apr 23 06:23:02 2002 Subject: [vortex] About 3c59x Message-ID: <3CC52C5B@webmail.usu.edu> Hello Everyone, How all of you are doing? I have a "3c905 100BaseTX [Boomerang]" card in my machine. When the system boots up, the 3c59x driver gets installed and the network works fine. I removed all the occurances of 3c59x.o file from all directories including the /lib/modules/2...../drivers/net directory and rebooted the system, but still the driver gets installed. Is the driver been statically linked to my kernel while it was compiled? Another question is, I removed the 3c59x module by rmmod and I created an "3c59x.o" object file from the "3c59x.c" file present in /usr/src/linux.2.4/drivers/net directory. I moved this object file to /lib/modules/...../drivers/net from where the modprobe will load the module. When I installed the driver saying "modprobe eth0" it got installed. But when I started the network by "\etc\rc.d\init.d\network start" the "lo" interface started but the "eth0" interface does not start. The dhcp waits for sometime and gets timed out. The following lines are the clippings from the /var/log/messages file. "Apr 20 13:48:37 localhost kernel: eth0: Host error, FIFO diagnostic register 2000. Apr 20 13:48:37 localhost kernel: eth0: PCI bus error, bus status 00a00029 Apr 20 13:48:37 localhost kernel: eth0: Transmit error, Tx status register 90. Apr 20 13:48:37 localhost kernel: Flags; bus-master 1, dirty 1(1) current 1" I compiled the 3c59x.c file as "gcc -DMODULE -D__KERNEL__ -O6 -c 3c59x.c". Should I do any settings or pass any parameters during compiling. It will be really great if you can help me regarding these questions. I will be eagerly waiting for your reply. Have a nice day. Thank you, Anup Pemmaiah ------------------------------------------------- N.C.Pemmaiah (Anup) 620E, 700N, Apt# 2 Logan, UT-84321,USA. email: pemmaiah@cc.usu.edu, anup_pemmaiah@yahoo.com Ph: 435-512-0935(mob.), 435-752-5976 (Res.) ------------------------------------------------- From einhoff@i4.informatik.rwth-aachen.de Wed Apr 24 12:00:05 2002 From: einhoff@i4.informatik.rwth-aachen.de (Gerrit Einhoff) Date: Wed Apr 24 11:00:05 2002 Subject: [vortex] Packet-loss and/or interface blocking on 3c905C-TX cards Message-ID: <200204241459.g3OExed12061@r220-1.rz.RWTH-Aachen.DE> Hello. I got this address from the source of the 3c59x-driver. If this is the wrong place to ask for help, please point me to a better one. Thanks. We are experiencing weird problems with our 3Com nics. We use the following setup: - 8 SMP (2 x 1GHz Pentium III) machines - each has three 3Com 905C-TX nics - the first one is connected two a switch, the second via a patch cable to the third of the next machine to form a ring - kernel is linux-2.4.17-mosix (the mosix-stuff wasn't used during our tests) To test the throughput of the interfaces I wrote a program that sends UDP-packets from one system to the next and measures the throughput/losses/jitter/etc. I used it to send batches of one million packets over the second interface of one machine to the third of the next (i.e. over the direct connection) with different packet-sizes. First we tried it with the latest drivers from www.scyld.com. Unfortunately after the first million packets, the sending interface suddenly blocked, meaning it wouldn't send any more packets, although it returned fine from all send()-calls. This could be solved by an 'ifconfig eth1 down' + 'ifconfig eth1 up', but only for the next million packets. Next, we tried the driver distributed with the kernel sources. With that, the interface didn't block anymore, even after millions of packets. You can see the results at http://www.einhoff.de/plot.png (sorry, the legend is in German. Red is bandwidth in Mbps, green are losses in %). As you can see we experienced packet losses up to 80%, but only for the packet-sizes from 112 bytes to 354 bytes. These results are reliable reproducible. With packet-sizes of 354 bytes, we have losses of 80%, with 355 bytes no losses at all! Apparently the packets are lost at the sending side, because the program finishes five times faster with 354 bytes packets than with 355 bytes packets. When we tried the scyld-driver again, with smaller packet batches, we noticed that it produces losses to, this time from 91 to 385 bytes. We didn't notice the first time, because the interface kept blocking. At last we tried the driver from the 3com website. This time we saw no losses, but the interface started blocking again after a million packets. To summarize: - scyld-driver: losses for packet sizes from 91 to 385 bytes, interface blocks after the first million packets. - kernel-driver: losses for packet sizes from 112 to 354 bytes, no blocking. - 3Com-driver: no losses, interface blocks after first million packets. So we've seen all combinations of losses and blocking except the one we're looking for... We tried all this on several (identical) machines, so a hardware-failure is highly unlikely. Any ideas? Thanks, Gerrit Einhoff From hansv@jazzter.xs4all.nl Thu Apr 25 12:18:01 2002 From: hansv@jazzter.xs4all.nl (Hans Voss) Date: Thu Apr 25 11:18:01 2002 Subject: [vortex] Re: vortex digest, Vol 1 #403 - 1 msg References: <200204241601.g3OG1Eb06034@blueraja.scyld.com> Message-ID: <001801c1ec6c$4e3713a0$0138a8c0@hancock> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I seem to be having the same kind of problem. (Multiple 3c905TX'es screws up the whole thing. I can see the three cards perfectly. The electrical signalling works (my WXP laptop says it has a network connection when I do ifconfig and says that it looses connection when I do ifconfig ... down). But no PING (which is small packet size), sometimes some ping - ----- Original Message ----- From: To: Sent: Wednesday, April 24, 2002 6:01 PM Subject: vortex digest, Vol 1 #403 - 1 msg > Send vortex mailing list submissions to > vortex@scyld.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.scyld.com/mailman/listinfo/vortex > or, via email, send a message with subject or body 'help' to > vortex-request@scyld.com > > You can reach the person managing the list at > vortex-admin@scyld.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vortex digest..." > > > Today's Topics: > > 1. Packet-loss and/or interface blocking on 3c905C-TX cards > (Gerrit Einhoff) > > --__--__-- > > Message: 1 > From: Gerrit Einhoff > Reply-To: einhoff@i4.informatik.rwth-aachen.de > To: vortex@scyld.com > Date: Wed, 24 Apr 2002 17:01:11 +0200 > Organization: RWTH-Aachen > Cc: diepolder@i4.informatik.rwth-aachen.de > Subject: [vortex] Packet-loss and/or interface blocking on > 3c905C-TX cards > > Hello. > > I got this address from the source of the 3c59x-driver. If this is > the wrong place to ask for help, please point me to a better one. > Thanks. > > We are experiencing weird problems with our 3Com nics. We use the > following setup: > > - 8 SMP (2 x 1GHz Pentium III) machines > - each has three 3Com 905C-TX nics > - the first one is connected two a switch, the second via a patch > cable to the third of the next machine to form a ring > - kernel is linux-2.4.17-mosix (the mosix-stuff wasn't used during > our tests) > > To test the throughput of the interfaces I wrote a program that > sends UDP-packets from one system to the next and measures the > throughput/losses/jitter/etc. I used it to send batches of one > million packets over the second interface of one machine to the > third of the next (i.e. over the direct connection) with different > packet-sizes. > > First we tried it with the latest drivers from www.scyld.com. > Unfortunately after the first million packets, the sending > interface suddenly blocked, meaning it wouldn't send any more > packets, although it returned fine from all send()-calls. This > could be solved by an 'ifconfig eth1 down' + 'ifconfig eth1 up', > but only for the next million packets. > > Next, we tried the driver distributed with the kernel sources. With > that, the interface didn't block anymore, even after millions of > packets. You can see the results at http://www.einhoff.de/plot.png > (sorry, the legend is in German. Red is bandwidth in Mbps, green > are losses in %). As you can see we experienced packet losses up > to 80%, but only for the packet-sizes from 112 bytes to 354 bytes. > These results are reliable reproducible. With packet-sizes of 354 > bytes, we have losses of 80%, with 355 bytes no losses at all! > Apparently the packets are lost at the sending side, because the > program finishes five times faster with 354 bytes packets than > with 355 bytes packets. > > When we tried the scyld-driver again, with smaller packet batches, > we noticed that it produces losses to, this time from 91 to 385 > bytes. We didn't notice the first time, because the interface kept > blocking. > > At last we tried the driver from the 3com website. This time we saw > no losses, but the interface started blocking again after a > million packets. > > To summarize: > > - scyld-driver: losses for packet sizes from 91 to 385 bytes, > interface blocks after the first million packets. > - kernel-driver: losses for packet sizes from 112 to 354 bytes, no > blocking. > - 3Com-driver: no losses, interface blocks after first million > packets. > > So we've seen all combinations of losses and blocking except the > one we're looking for... > > We tried all this on several (identical) machines, so a > hardware-failure is highly unlikely. > > Any ideas? > > Thanks, > > Gerrit Einhoff > > > > --__--__-- > > _______________________________________________ > vortex mailing list > vortex@scyld.com > http://www.scyld.com/mailman/listinfo/vortex > > > End of vortex Digest -----BEGIN PGP SIGNATURE----- Version: PGP 7.1 iQA/AwUBPMgeAjyvc2N6Oeg+EQLS7ACglZ+0FE8RoJkyihUs8qtxK8QNz2wAnjW4 ND2L06jW87/H43ytR/hBrg6e =epDA -----END PGP SIGNATURE----- From akpm@zip.com.au Thu Apr 25 16:19:01 2002 From: akpm@zip.com.au (Andrew Morton) Date: Thu Apr 25 15:19:01 2002 Subject: [vortex] Packet-loss and/or interface blocking on 3c905C-TX cards References: <200204241459.g3OExed12061@r220-1.rz.RWTH-Aachen.DE> Message-ID: <3CC85642.100B7987@zip.com.au> Gerrit Einhoff wrote: > > ... > As you can see we > experienced packet losses up to 80%, but only for the packet-sizes from 112 > bytes to 354 bytes. These results are reliable reproducible. With > packet-sizes of 354 bytes, we have losses of 80%, with 355 bytes no losses at > all! Apparently the packets are lost at the sending side, because the program > finishes five times faster with 354 bytes packets than with 355 bytes packets. I'm not 100% sure about this, but I suspect it's a UDP thing. If an application is squirting UDP packets out faster than the interface can sustain, the kernel just drops them on the floor when the socket send buffer fills up. From Jan.Ceuleers@alcatel.be Sat Apr 27 15:02:01 2002 From: Jan.Ceuleers@alcatel.be (Jan.Ceuleers@alcatel.be) Date: Sat Apr 27 14:02:01 2002 Subject: [vortex] 3C905C-TX / 2.0.29 Message-ID: I know, I know: I've got an ancient kernel. Nevertheless, I'm trying to get a second Ethernet card working. The first-one is a 3C509B and that's working fine. The second-one is a 3C905C and I can't get that to work. ifconfig yields: eth1 Link encap:10Mbps Ethernet HWaddr 00:02:1B:F3:02:13 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13 errors:0 dropped:0 overruns:0 TX packets:17 errors:0 dropped:0 overruns:0 Interrupt:10 Base address:0xfc80 vortex-diag yields: vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xfc80. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 7, registers values by window: Window 0: 0000 0000 0000 0000 0000 00bf ffff 0000. Window 1: FIFO FIFO 0700 0000 0000 007f 0000 2000. Window 2: 0200 f31b 1302 0000 0000 0000 0052 4000. Window 3: 0000 0380 05ea 0000 000a 0800 0800 6000. Window 4: 0000 0000 0000 0cfa 0001 8c80 0000 8000. Window 5: 1ffc 0000 0000 0600 0805 06de 06c6 a000. Window 6: 0000 0000 0000 0400 0000 01b1 00b4 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0xfc80 0xFC90: **FIFO** 00000000 0000000a *STATUS* 0xFCA0: 000000a0 011f12f0 00080000 00001404 0xFCB0: 00000000 4f2db0d3 011f10c0 00080004 Indication enable is 06c6, interrupt enable is 06de. No interrupt sources are pending. Transceiver/media interfaces available: 100baseTx 10baseT. Transceiver type in use: Autonegotiate. MAC settings: half-duplex. Station address set to 00:02:1b:f3:02:13. Configuration options 0052. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:02:1B:F3:02:13 (used as a unique ID only). OEM Station address 00:02:1B:F3:02:13 (used as the ethernet address). Manufacture date (MM/DD/YYYY) 11/13/2000, division H, product FJ. Options: negotiated duplex, link beat required. Vortex format checksum is incorrect (0003 vs. 10b7). Cyclone format checksum is incorrect (0x93 vs. 0x9b). Hurricane format checksum is incorrect (0xba vs. 0x9b). MII PHY found at address 24, status 782d. MII PHY 0 at #24 transceiver registers: 3000 782d 0040 6176 05e1 0021 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0000 0000 0000 0000 0000 0300 0000 003c 8006 0f00 ff40 012c 0000 0080 000b. This is what's in dmesg: pci-scan: Handling APM event 11 for driver list vortex... ... VFS: Disk change detected on device 02:00 pci-scan: Handling APM event 11 for driver list vortex... ... eth1: Media selection timer tick happened, Autonegotiate. eth1: MII transceiver has status 782d. eth1: Media selection timer finished, Autonegotiate. pci-scan: Handling APM event 11 for driver list vortex... ... eth1: interrupt, status e401, latency 4 ticks. eth1: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 000a. Receiving packet size 60 status 803c. eth1: exiting interrupt, status e000. eth1: Queuing Tx packet, index 14. eth1: interrupt, status e201, latency 2 ticks. eth1: In interrupt loop, status e201. eth1: exiting interrupt, status e000. pci-scan: Handling APM event 11 for driver list vortex... eth1: interrupt, status e401, latency 6 ticks. eth1: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 000a. Receiving packet size 60 status 803c. eth1: exiting interrupt, status e000. eth1: Queuing Tx packet, index 15. eth1: interrupt, status e201, latency 2 ticks. eth1: In interrupt loop, status e201. eth1: exiting interrupt, status e000. pci-scan: Handling APM event 11 for driver list vortex... pci-scan: Handling APM event 11 for driver list vortex... eth1: interrupt, status e401, latency 5 ticks. eth1: In interrupt loop, status e401. In boomerang_rx(), status e001, rx_status 000a. Receiving packet size 60 status 803c. eth1: exiting interrupt, status e000. eth1: Queuing Tx packet, index 16. eth1: interrupt, status e201, latency 3 ticks. eth1: In interrupt loop, status e201. eth1: exiting interrupt, status e000. pci-scan: Handling APM event 11 for driver list vortex... ... eth1: Media selection timer tick happened, Autonegotiate. eth1: MII transceiver has status 782d. eth1: Media selection timer finished, Autonegotiate. pci-scan: Handling APM event 11 for driver list vortex... ... The traffic that is at the basis of the above log is a ping to a Windows machine, which failed. Any ideas? Thanks muchly. From einhoff@i4.informatik.rwth-aachen.de Mon Apr 29 09:38:01 2002 From: einhoff@i4.informatik.rwth-aachen.de (Gerrit Einhoff) Date: Mon Apr 29 08:38:01 2002 Subject: [vortex] Packet-loss and/or interface blocking on 3c905C-TX cards In-Reply-To: <3CC85642.100B7987@zip.com.au> References: <200204241459.g3OExed12061@r220-1.rz.RWTH-Aachen.DE> <3CC85642.100B7987@zip.com.au> Message-ID: <20020429123636.81C889C111@i4mail.informatik.rwth-aachen.de> Am Donnerstag, 25. April 2002 21:17 schrieb Andrew Morton: > I'm not 100% sure about this, but I suspect it's a UDP > thing. If an application is squirting UDP packets > out faster than the interface can sustain, the kernel > just drops them on the floor when the socket send buffer > fills up. But I'm using the socket in blocking-mode. As I understand it the kernel should wait for the packet to actually be send out before returning from the send() function in this mode. Or am I wrong here? That could explain the losses, although it seems weird that it only happens for the small packets. It still wouldn't explain the interface blocking, however. - Gerrit From becker@scyld.com Mon Apr 29 09:55:01 2002 From: becker@scyld.com (Donald Becker) Date: Mon Apr 29 08:55:01 2002 Subject: [vortex] 3C905C-TX / 2.0.29 In-Reply-To: Message-ID: On Sat, 27 Apr 2002 Jan.Ceuleers@alcatel.be wrote: > Subject: [vortex] 3C905C-TX / 2.0.29 > > I know, I know: I've got an ancient kernel. That kernel should work fine. > Nevertheless, I'm trying to get a second Ethernet card working. The > first-one is a 3C509B and that's working fine. The second-one is a 3C905C > and I can't get that to work. What driver version are you using? What is the detection message? > ifconfig yields: > > eth1 Link encap:10Mbps Ethernet HWaddr 00:02:1B:F3:02:13 > inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 .. > RX packets:13 errors:0 dropped:0 overruns:0 > TX packets:17 errors:0 dropped:0 overruns:0 This looks fine. You are sending and receiving packets with no errors. Check your routing table. > This is what's in dmesg: > > pci-scan: Handling APM event 11 for driver list vortex... You are getting a lot of APM_STANDBY_RESUME events. From your description I expected a PCI card in a desktop machine, not a laptop with frequent power management events. This is mostly harmless, but unexpected. > eth1: Media selection timer tick happened, Autonegotiate. > eth1: MII transceiver has status 782d. Normal > eth1: interrupt, status e401, latency 4 ticks. > eth1: In interrupt loop, status e401. > In boomerang_rx(), status e001, rx_status 000a. You received a packet with no error. > eth1: Queuing Tx packet, index 14. > eth1: interrupt, status e201, latency 2 ticks. And transmitted one. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993