Okay, further trace on that oops w/ 3c507 and 2.1.61.
Greg Alexander (galexand@sietch.bloomington.in.us)
Mon, 3 Nov 1997 23:20:03 -0500 (EST)
Same thing with 2.1.62...I did some looking in the source, and I see that it
occurs at the first memcpy within init_82586_mem...this memcpy is writing to
000dfff6, which is towards the end of my 3c507's 64k buffer from
0xd0000-0xdffff. This is what it did in older kernels and it worked fine
back then...
So I'm thinking that something has either changed about how a
network driver is supposed to signal the rest of the kernel as to where the
card's shared memory is, or (more likely?) something has changed in the
mapping so that 0xd0000-0xdffff is reserved now? If either of these are the
case, I'm sure someone will recognize the change and be able to point it out
to me. If I don't get a response soon, I'll just try changing it to another
address (a bit of a pain to dig up the 3c507 software configurator), but
even if that works, I want to know what changed it...it might cause other
problems in the future.
Greg Alexander - also <gralexan@indiana.edu> - http://sietch.home.ml.org/
----
Trashed filesystems are child's play -- if the hardware ain't smoking,
IT'S RUNNING TOO SLOW!
-- John Kelly, linux-kernel@vger.rutgers.edu contributor