Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Dec 1996 11:54:05 +0100 (MET)
From:      Greg Lehey <grog@lemis.de>
To:        freebsd-mobile@freebsd.org (FreeBSD mobile Mailing List)
Cc:        FreeBSD-current@freebsd.org (FreeBSD current users)
Subject:   It works!  Solved my problem wih Etherlink III on AcerNote Light
Message-ID:  <199612101054.LAA18102@freebie.lemis.de>

next in thread | raw e-mail | index | archive | help
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  <Link>      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  <Link>      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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612101054.LAA18102>