Yep, but what ? Is there a way to let kmalloc print a stack trace
when this happens? *(int*)0=0; should cause an oops, right ?
Okay I've added that to kmalloc() in mm/slab.c. Rebooting now (if
Cistron customers read this, sorry I interrupted your news reading ...)
Duh, I'm booting the same kernel, but now with only that tiny change
to mm/slab.c, there is no kmalloc failure, and I have network connectivity.
Weird.
> > .. and I do not have network connectivity with this kernel. It looks
> > like the epic100 driver is busted. It's a module, unloading and reloading
> > gets it to work again ..
>
> The epic100 driver hasnt changed between 2.2.10->2.2.12 and probably for
> longer back than this. What kernel did you used to run ?
Well it used to run 2.0.37-pre5 ;)
I have another machine, a newsserver as well which I upgraded from
2.0.37 -> 2.2.9 -> 2.2.12-pre8. When I got to 2.2.12-pre8, the epic100
stopped working as well until I unloaded and reloaded the module. It
didn't give the kmalloc message though.
The reason I didn't report it was that a lot of other things broke as
well due to the RAID change which was in some 2.2.12-pre versions, and
I manually unloaded and loaded several modules a few times, so I
forgot about it...
Ofcourse this all doesn't make any sense since there only has been
1 minor change to the epic100 driver in patch-2.2.8.
Anyway would the *(int*)0=0; in mm/slab.c be a useful addition to
standard kernels? I've seen the same message on 2.3.13 or so on
my home machine (probably caused by ISDN) and it would be nice to
have a trace of it.
Mike.
-- ... somehow I have a feeling the hurting hasn't even begun yet -- Bill, "The Terrible Thunderlizards"- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/