Date: Tue, 28 Jul 1998 14:51:53 -0700 From: Ulf Zimmermann <ulf@Alameda.net> To: Ted Faber <faber@ISI.EDU>, Frank McConnell <fmc@reanimators.org> Cc: Mike Smith <mike@smith.net.au>, Robert Swindells <swindellsr@genrad.co.uk>, hackers@FreeBSD.ORG Subject: Re: AMD PCNet/FAST cards; suppliers? Message-ID: <19980728145153.B13777@Alameda.net> In-Reply-To: <199807281812.LAA18644@tnt.isi.edu>; from Ted Faber on Tue, Jul 28, 1998 at 11:12:59AM -0700 References: <199807281751.KAA22144@daemonweed.reanimators.org> <199807281812.LAA18644@tnt.isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 28, 1998 at 11:12:59AM -0700, Ted Faber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > Frank McConnell wrote: > >Ted Faber <faber@ISI.EDU> wrote: > >> So, if this is a known chip that works on other machines, what's so > >> different about the Hitachi MX-133? I'm happy to run any diagnostics > >> that you guys think will help find the differences. > > > >Funny, that's what I was thinking to ask you: what is it about the > >Hitachi Mx133 (and apparently other Hitachi notebooks) that needs this > >patch? > > The ethernet on the MX-133 is integrated into the case, i.e. it's not > a PCMCIA card or an add-on. I haven't opened the thing up, but for > all I know the controller's on the motherboard. Apparently they've > made some interesting choices about the defaults for the PCNET chip > they used. It seems to come up in ISA compatibility mode. > > If the chip *does* work in native PCI mode, maybe we should > concentrate on bringing up the controller in direct PCI mode. I don't > have the relevent chip specs, but if you can tell me anything I'll be > happy to help. I have a hitachi M100D, which worked with a 2.2.2-STABLE and the lnc1 driver as PCI. I tried to install 2.2.6 but 2.2.6 had very many page faults. I was going to try 2.2.7 again. > > > I've looked at the original patch in the mailing list archives > >and now I think I really don't get it -- does this thing satisfy two > >different probes and so get attached twice? > > Here's what I sent Mike Smith about the patch. If other people are > successfully using this chip as a pure PCI chip, my comments that > there's no way to do so are obviously wrong. > > - --- > Mike Smith said (among other things: > >The ne2100_probe() function returns zero if pcnet_probe() fails. > >However, you've patched this function to return nonzero, so you > >shouldn't need this case. > > > >Comments? Are you still using this code? > > I'm still using this code, and here's my rationale behind it: > > (You'll probably want to open /sys/i386/isa/if_lnc.c up to follow this...) > > As far as I can tell, there's no support for using the Hitachi's > internal PCI lance board in native PCI mode, so the card can only be > used in ISA emulation mode. This means that pcnet_probe() is called > *twice*, once when PCI cards are probed, and once when ISA cards are > probed. When PCI cards are probed, lnc_attach_ne2100_pci() needs an > indication that there is a PCI card around in emulation mode so that > it doesn't call lnc_attach_sc() to attach the PCI card as a native PCI > device. (This is somewhat obfuscated by putting it in a short circuit > operator, but that construct was there when I showed up....) The zero > from pcnet_probe() serves as a placeholder in lnc_attach_ne2100_pci(), > but during ISA probing, lnc_probe() expects pcnet_probe() to return a > non-zero value if there is a card in emulation mode. > > pcnet_probe() can't (easily :-)) tell which function's calling it, so > it can't return different values. > > This patch was the first thing I submitted to the source tree, and as > a new kid, I thought that keeping my changes as small as possible > would make them more likely to be adopted (and smaller to mail!!). > In retrospect, probably not the best parameter to optimize. :-) > > The problem seems to be that the various probe routines (or at least > pcnet_probe()) are doung double duty as both ISA and PCI probe > routines. Two answers suggest themselves: 1) Comment the hell out of > this so it's not so confusing; 2) add a separate pcnet_probe_pci() > routine that returns an appropriate value while reusing as much > pcnet_probe() code as possible (all of it, I think). Of course, I > could also be way off base, in which case, I hope you'll tell me. > > I'm happy to leave it as is, implement either of the above solutions, > or be persuaded that there's another, better solution. > > - --- > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQCVAwUBNb4UqYb4eisfQ5rpAQF10AQAncU9SPLgvMZWVPt8/XYjhQOi4MLFd9of > hVoyGzjHsGQ+2jJSajbeAwtJXXwe9QW42X64ReJFVpSxQd5FhthMapAMDFpYkUhA > cCsiipT5PEs7REqOY4BDN5rTNnh+KYfP/s/vBdQKQOJVBg28DMqSvFUGVCfmfE8a > OP3DDk8bzog= > =z/yG > -----END PGP SIGNATURE----- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980728145153.B13777>