Date: Fri, 23 Jan 1998 13:26:52 -0800 From: Bill Trost <trost@cloud.rain.com> To: mobile@FreeBSD.ORG Subject: Re: SVEC NE2000 "clone" doom and gloom Message-ID: <m0xvqdr-0002TEC@jli.com> In-Reply-To: Your message of Fri, 23 Jan 1998 11:09:25 %2B1030. <199801230039.LAA00343@word.smith.net.au> References: <199801230039.LAA00343@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith writes:
> Since the block is less than the memory quanta of MEMUNIT, bit_fns ends
> up getting asked to allocate a memory region of size zero (ROUNDOFF
> BUG!), which it can't do.
Damn, I've seen this one before too. Want to submit a patch? 8)
It should be trivial -- but for some reason, "make" in usr.sbin/pccard/pccardd
fails, so I am not going to bother unless I get the rest of this sorted out.
Dumb question, but do you have the 'ed' driver in your kernel?
Never hurts to check. Yes, it's there.
If you throw a few printf()'s in sys/pccard.c:allocate_driver() you should
be able to work out what's going wrong pretty quickly.
OK, allocate_driver hangs in drv->enable (the whole system hangs inside the
splhigh(), surprise). That is bound to edinit, which hangs in ed_probe_pccard,
which hangs in ed_probe_WD80x3, which hangs computing the ether address PROM
checksum(???). It doesn't even manage to read the first byte.
What's the TOSH_ETHER in if_ed.c for? If I define that, then I don't get the
hang -- instead, the checksum checks fail, and pccardd says that the driver
allocation fails (and I got an "unfiended interrupt (0)" once, too). The probe
does not believe the card is an NE2000.
All these experiments were run with pccardd coerced into using the second,
larger memory region. Using the smaller or no memory region with TOSH_ETHER
gets similar results.
> AARGH! Yeah, sure, NE2000-compatible my foot!
Could be. Nobody said the code was perfect either.
You mean there might be a *bug*? In the *kernel*? Naaah.... (-:
However, the way things are going, I am becoming more and more convinced that
the vendor botched it (at best).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0xvqdr-0002TEC>