From owner-freebsd-mobile Tue Dec 10 05:36:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA00910 for mobile-outgoing; Tue, 10 Dec 1996 05:36:16 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA00881; Tue, 10 Dec 1996 05:36:12 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id EAA13262 ; Tue, 10 Dec 1996 04:20:50 -0800 (PST) From: Greg Lehey Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0vXR9i-000QXiC; Tue, 10 Dec 96 13:19 MET Received: (grog@localhost) by freebie.lemis.de (8.8.4/8.6.12) id LAA18102; Tue, 10 Dec 1996 11:54:06 +0100 (MET) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Message-Id: <199612101054.LAA18102@freebie.lemis.de> Subject: It works! Solved my problem wih Etherlink III on AcerNote Light To: freebsd-mobile@freebsd.org (FreeBSD mobile Mailing List) Date: Tue, 10 Dec 1996 11:54:05 +0100 (MET) Cc: FreeBSD-current@freebsd.org (FreeBSD current users) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk For those of you who've been following my tribulations installing -current on an AcerNote Light, the good news: finally it works. I've learnt a number of things on the way, however, so I thought I'd share the story: 1. Initially, I tried installing with the 2.1.5 boot floppy. It recognized the card, but couldn't get it to work. I sent a message off, I think to -current, and got a number of replies, including "set your link0 and link1 correctly", and "you need the PAO floppy". 2. In the meantime, several things happened to muddy the waters: i. I tried the 3Com "diagnostic", which must be the worst piece of junk I have ever seen. It told me that the Ethernet card was defective--it failed every test. So I changed the Ethernet card. ii. At the same time, the hard disk on the notebook died. So I changed the notebook. iii. The handbook for the notebook suggested that the standard settings for the board (I/O 0x300, IRQ 10) wouldn't work. IRQ 10 is "reserved", so they say, though they don't say for what. They also give a map of upper memory showing nothing free at all; obviously a misprint, but another cause for uncertainty. I tried moving the board to 0x320, IRQ 11 (at least they say IRQ 11 is available), but that didn't help. It just meant that, after I could no longer run the diagnostic, I found that I had forgotten how I had last set it. iv. The new notebook and the new diagnostic still claimed that the new Ethernet card was defective. I decided that the diagnostic was defective, and sent off a mail message to 3Com asking for help. Despite their promises of a callback, it hasn't happened yet. The diagnostic appears to want to run under Windoze 95% with card services enabled. If you boot DOS from floppy, it will run, but it will fail the test. In order for it to pass the test in this mode, you need first to read the configuration, store the same configuration back, and then run the diagnostic, which will succeed. Leave the diagnostic program, restart it, and run it again, and it will fail. I can't see a means of distinguishing this behaviour from that of a board which can't keep its configuration. This kind of diagnostic is just one step removed from being completely useless. To be fair (though not necessarily generous), I didn't verify whether the diagnostic worked correctly under Windoze 95%. That would have required finishing the installation and answering all sorts of stupid questions, including serial numbers and such junk. To make matters worse, after I wiped Windoze 95% from the disk, the diagnostic would not even start. Instead, it said Can't Run Install, files missing. Make sure you have INSTALL.EXE, INST1.SAC and STRINGS.BIN in your directory (-1, 2) These files are, of course, all there, on the original, write-protected diskette. I re-created a second diskette from the backup, and I downloaded the file 3C589.EXE from your web site, but the results were the same. I'm pretty sure the real reason is that it didn't find a DOS or Windoze hard disk partition. Summary: the diagnostic software is broke, but bad. 3. I built a number of kernels with a number of different options, set up my /etc/pccard.conf as various people have suggested--all in vain. I suspect that the pccard setup is very version-sensitive. My pccardd didn't even accept the definitions that some people had put in their /etc/pccard.conf, for example. Nevertheless, things looked *very* bad. pccardd couldn't find anything which looked like PCMCIA resources (though the kernel did notice when I inserted and removed the boards). I shelved this and went away for some serious head-scratching. 4. During the head-scratching, I decided to retry the 2.1.5 vanilla boot diskette. Bingo! it found the board. Not much I could do with it, of course, but it was better than what I had had with the PAO diskette. I then attempted it with what I thought was the 2.1.5 generic kernel, only to find it was a 2.1.0-SNAP kernel dated 28 September 1995. It didn't find the board. Subsequent attempts with the generic 2.1.5 kernel showed that it didn't find the board either. Huh? Back to the boot diskette. It no longer found it, either. After power cycling, it did, and so did the generic kernel. So then I built a -current kernel without crd0 and pcic[01]. It FOund the baord. And it was able to correctly configure zp0. But I still couldn't get things to work. On closer examination, there seems to be something wrong with the routing table entry: there was no entry at all for zp0, and I couldn't find a way to put one in. In /etc/sysconfig, I did effectively: ifconfig lp0 192.109.197.159 192.109.197.137 ifconfig zp0 192.109.197.159 This had the strange effect that no entry at all for zp0 appeared in the routing table. I don't understand this: at the other end (freebie) I had an almost completely symmetrical configuration, which worked with no problems. I still don't know what happened here, but I'll take a look once I clean up the backlog that this marathon has caused. So I removed lp0 from /etc/sysconfig and rebooted. Now the routing tables looked OK, but it still didn't work. OK, I've got RG-58, what links do I need? Where's the man page for zp? Nowhere. I played around with the links and found that link1 will do the trick: it works. Not very fast, but it works. The hard disk on this machine seems to be the slowest I've every come across. ftp'ing a 67 MB file gave me a throughput of about 220 kB/s when copying to disk, about 750 kB/s when copying to /dev/null. By comparison, the same file ftp'd to (IDE) disk on freebie at 860 kB/s, and to /dev/null at 940 kB/s. The error rate might explain some of this: on freebie, netstat -in shows: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ep0 1500 00.a0.24.37.0d.2b 3042959 1 3470819 1 0 ep0 1500 192.109.197 192.109.197.137 3042959 1 3470819 1 0 By contrast, on papillon (the notebook), I have: zp0 1500 00.60.97.40.fb.e1 221769 198 52256 3 0 zp0 1500 192.109.197 192.109.197.159 221769 198 52256 3 0 The morals of the story ----------------------- 1. We obviously need to look at the pccard stuff a lot more carefully. The documentation needs to mention this. In fact, we need documentation. I'll see what I can put together. 2. We probably need to document the vagaries of "diagnostic" programs such as the junk that 3Com supplies. You'd think 3Com would be interested, too. After all, I can't be the only person to return hardware because the accompanying software says it's defective. 3. PCMCIA is obviously a good subject for the internals book we're talking about writing. 4. It would be nice to have a general diagnostic utility for snooping around in the PC hardware to see what's there and what isn't. I'll think about writing one. If anybody has any ideas, I'd be interested to hear of them. 5. The probe routines are probably not all they should be. I'd guess that the 2.1-SNAP kernel got the board into a state where no kernel could successfully probe it, and I had to power down to get any improvement. This is partially documented in the kernel config files, but it might be an idea to make it more prominent. 6. We need man pages for all the Ethernet drivers, even if they're substantially clones. It would also be nice to have an overview of what the ifconfig flags mean for the various drivers. Greg