Subject: Tracking down memory corruption.
To: None <tech-kern@netbsd.org>
From: Peter Seebach <seebs@plethora.net>
List: tech-kern
Date: 09/15/2006 17:17:40
Okay, the problem with my zaptel driver has become clear.

Memory is getting trashed something fierce.  Somewhere.

The reason my kernel always panics somewhere in the esiop code is that the
esiop driver's softc is at address 0xc0624000.  The sc provided to my driver,
which is an LKM, is 0xc0622800... But that's for a total size of 10,512 bytes,
meaning the last address in it is 0xc0627910.  And that means that modifying
things near the end of the device's sc trashes the softc for esiop.

The thing is, I am pretty sure it's impossible for any bug in my attach
routine here to cause this.  By the time the first line of my code is run,
the allocation already happened.

My cfattach declaration looks okay to me:
CFATTACH_DECL(wcfxs, sizeof(struct wcfxs_softc),
        wcfxs_match, wcfxs_attach, wcfxs_detach, NULL);

Printing wcfxs_ca.ca_devsize in wcfxs_lkmload gives 10512, so it SHOULD be
allocating enough space; instead, I'm ending up with something only 6,144
bytes before something which was allocated back at boot time.  WTF?

System is 3.0.1/i386.

-s