From owner-freebsd-mobile Fri Jul 24 08:14:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA23524 for freebsd-mobile-outgoing; Fri, 24 Jul 1998 08:14:54 -0700 (PDT) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from lily.ezo.net (root@lily.ezo.net [206.102.130.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA23516 for ; Fri, 24 Jul 1998 08:14:51 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from violet.eznets.canton.oh.us (violet.ezo.net [206.102.130.138]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id LAA09424; Fri, 24 Jul 1998 11:12:34 -0400 (EDT) From: "Jim Flowers" To: "Mike Smith" Cc: Subject: Re: WaveLAN Driver for FreeBSD Date: Fri, 24 Jul 1998 11:15:10 -0400 Message-ID: <01bdb715$d921a920$8a8266ce@violet.eznets.canton.oh.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike, Many hours later, the details of which are boring, I managed to get this running with a couple of minor hacks to if_wl.c and if_wl.h. The WaveLAN/ISA card now runs well (900 Kbps with 500 byte packets point-to-point) and reliably (starts up every time) on four different machines (486, P133, P200 and Cyrix Gx86). The 486 and Gx86 run OK with unmodified code. The first is a SLOW_CMD that inserts a 20 mS delay via DELAY() in wlhwrst() when issuing the clear reset and set PIO#1 in autoincrement mode command. Apparently the next call to wlmmcstat() or wlbldcu() interferes with completion of the hardware reset. The P133 worked OK with 10 mS but the P200 needed more. Issuing 2 regular (1 mS) CMDs also provided the same effect. DELAY(15000000) does check in at 15 mS. While this allows the initial routines to complete without error and marks wl0 up and running it does not actually transmit/receive packets until a wlconfig wl0 currnwid 0x#### command is issued. So the second hack was to perform the same MMC_WRITE(MMC_NETW_ID_?) commands just before leaving wlhwrst(). Other MMC_WRITE commands (I only tried MMC_FREEZE) don't do it. Don't know why but this starts the mmc running and everything works OK. Thought this information might be useful to you or anyone else having problems or in updating the driver code. A copy of the universal diffs and the dmesg from each machine is attached. Now, if I can just get the lnc Ethernet driver to work with the built in Am79C971 chip on the unit with the Gx86 processor I'll be happy. Next project (shudder :-( Any other ideas here? Regards, Jim > >The ISA Wavelans are *extremely* touchy about timing. You might want >to start by checking the ISA config on your new board, and perhaps >crank out some of the I/O delays, etc. > >> wl0: bldcu() not ready after reset >> wl0: diag() failed; status=0,inw=0,outw=e0a0 >> scb_status 0 >> scb_command 100 >> scb_cbl adaa >> cu_cmd 8007 >> wl0: init(): trouble resetting board > >You could also try upping STATUS_TRIES in sys/i386/isa/if_wl.c. There >are quite a few hardcoded spin loops in this driver; the diag() failure >may be symptomatic of this too. > >What motherboard chipset(s) are you using? > >> Pings to the ifconfigged address work; beyond that, no response. Not >> surprising as it's marked up but not running. Same problem on a Pentium >> 200MMX. > >Um, actually if it's responding to pings, then it's more or less >working. > >> Any suggestions on where to start looking? I know the driver is well >> documented so that's where I'll be but I'm hoping this is something obvious >> as I would like to use a lot of these boxes for a wireless network. > >Try increasing the STATUS_TRIES value to start with, and see if that >makes the 'not ready after reset' message go away. If that works, then >increase the value in the poll loop above the 'failed; status' message. > >It may be that when the first is fixed, the card will be happy enough >that the rest work. Apart from that, it actually appears to be running >well enough - the interrupt handler is being called, and it's sending >stuff in response OK, it's just not passing the startup tests. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message