Date: Thu, 30 Jul 1998 10:58:53 -0700 From: Ted Faber <faber@ISI.EDU> To: 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: <199807301758.KAA24012@tnt.isi.edu> In-Reply-To: Your message of "29 Jul 1998 17:38:28 PDT." <199807300038.RAA19554@daemonweed.reanimators.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Frank McConnell wrote: >Ted Faber <faber@ISI.EDU> wrote: >> Frank McConnell wrote: >> >Ted Faber <faber@ISI.EDU> wrote: >> >>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. >> > >> >What led you to that conclusion? > >Whoops. Poor choice of words on my part -- I wasn't questioning your >intelligence when I wrote that, I really wanted to know what behavior >you saw on your Hitachi that got you thinking along those lines. Sorry, didn't mean to jump down your throat. I misread the code wrt PCI support. As far as the rest of it, because I couldn't find specs for the chipset (this was all done a year or more ago) I treated it as a black box and poked around in the driver. I thought it was coming up in ISA emulation mode because the stock driver attached it as a PCI device which didn't work: it locked up the kernel under load. I tweaked the driver to stop the PCI attach after mapping the chipset in via pci_map_port() (using the pci_conf_read() and a mask fails, too; from the comments in pci_map_port, I'm guessing it's because the latter correctly initializes some bridges). After that the ISA probe succeeded (at the I/O port that a verbose boot revealed) and the driver worked flawlessly. As I said, I may have the term wrong, but that sounds like ISA emulation to me. >Hey, I'm no expert on these things either, just a wannabe looking for >enlightenment. > >Here's what I was thinking. The probing for PCI and ISA cards looks >(and largely is) the same -- I can't see why it should work from one >code path and fail from the other, except by way of different I/O base >addresses where one doesn't address an appropriate device. So there's >one potential problem -- if you have a PCI card, and it's getting >mapped at some I/O address for which you have a "device lnc[n]" entry >in your kernel config (as for an ISA card), it'll get probed and >attached twice. I believe that with the stock driver and default configuration that's roughly what happens, but with a little weirdness in the mix. The PCI probe maps the ethernet to an unconventional port (0xfce0), modulo bridge chip initializations. The ISA probe fails, because it's looking in the wrong place. Probing the correct port also fails without some work. Modifying the driver not to do the rest of the PCI initialization (not assigning the PCI interrupt in the PCI probe routine) allows the ISA probe on port 0xfce0 to succeed, and the driver to run. I avoid the interrupt assignment by passing a NULL pointer out of the lnc_attach_ne2100_pci() routine if I notice the chip ID in my Hitachi. If I either take out the change to from pci_conf_read() to pci_map_port() or restore the assignment of the PCI interrupt (pci_map_int()) in the pci attach routines, the driver fails. >So that's why I was wondering what you were seeing that would make >you think you could use it in "ISA emulation" only -- as near as I can >tell it should either work from either code path or not work at all. There's a nutshell of what I understand and why. There seem to be a couple ways to proceed. If we can determine how the chip is set up that allows my bizarre system to work, we can test for that instead of the chip ID, avoid the interrupt assignment and use the ISA port. This doesn't strike me as the best plan, but it may be feasible. If you want to do this, if you can send me a snippet of code to plunk into the driver to dump the values of the appropriate configuration registers, I'm happy to do it. On the other hand Robert Swindells's driver seems to attach the chip as a PCI device and work fine. If his modifications are small and acceptable, maybe the best plan is to incorporate them. If his mods are too far-sweeping, maybe we can isolate the modifications that he uses to probe and initialize the PCI chip and import them. If you want to incorporate only some of his changes, I'm happy to munge around or help munge and extract the appropriate code. Of the two I'm leaning toward the PCI attach, which seems cleaner. If Robert's driver doesn't break other configurations, importing his changes seems like a good idea. Opinions? Consensus? - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNcC0XIb4eisfQ5rpAQEiMwP/ZlT+QtB5DXqJDMOHF7TFd/iuPbo0Yz3a /QI+N1fT10nqGYHr1wqoTM+Mz8KmMm0a7nyWcjdbOUBiomMbNay21PJG3Zf44Rkd JWD/8xPO6qBphOVnlmj0zLsHlCxinFpmoPKPAwo5rNq6OV1MM7UEyWSmVfxK+Q6K qgxmAlzoNzw= =BG3S -----END PGP SIGNATURE----- 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?199807301758.KAA24012>