On Sun, Jan 30, 2000 at 09:31:08PM -0800, Chuck Silvers wrote:

> I'm not sure exactly what would be messed up by having the frees not
> match the M_FOO of the allocation, but I wouldn't think it would mask
> the problem like that.

It seems that changing deadbeef to different things somehow masks the
problem. :/ So far 0x0 and 0x10000000 make the error disappear, while
deadbeef allows the error, with this being the one element that varies.

Maybe my C skills are TOO rusty, but is unsigned a proper data type, with
a defined length? I'm just wondering if my using 0x0 resulted in my only
filling one byte of several, or something strange like that. I'd think that
0x10000000 would use the same number of bytes as 0xdeafbeef, but maybe not...?
Maybe it's not using the first three bits? I'm simply at a loss to explain
what's going on.

On another note, I do notice something else:

Feb  3 08:27:51 acheron /netbsd: uhci_device_intr_transfer: not done, ii=0xf05c0d40
Feb  3 08:28:03 acheron /netbsd: uhci_device_intr_transfer: not done, ii=0xf05c0d40

This happens each time I switch from a non-X wscons console to my X session,
on wscons 5.

This is doing something at 0xf05c0d40, and the freelist thing seems to be
happening nearby - 0xf061cdb0 in one instance, although this varies. I
haven't tracked the uhci thing between boots to see if the location changes.

In any event, I *did* get the freelist error with a kernel that didn't have
USB compiled into it, so it's difficult to believe that the error arises
from the uhci code.

I have used the following memory tester:

http://reality.sgi.com/cbrady_denver/memtest86/

I'd be willing to try another if this one is in any way lacking... It looked
really thorough, though.

I'm copying this to current-users, just in case anything jumps out at anyone.

-- 
    Mason Loring Bliss  mason@acheron.middleboro.ma.us  If a cow laughed, would
awake ? sleep : dream;  http://acheron.ne.mediaone.net  milk come out her nose?