Hi Bernd...
Just trying to share some thoughts here..
Two things I saw in your stack trace:
1. The crash (probably) happened when the kernel was executing interrupt
handler. In that case, the code path is somewhat irregular. I mean,
since interrupt handling could happen anytime, it doesn't always A then
B then C, it could be A then D then B. In simple words, IMHO stack trace
couldn't be interpreted as is when dealing with bugs inside interrupt
handler
2. RIP ended in address 0. Quite strange isn't it? The clue here is
there was a call to bond_check_dev_link() before it hit the null
deference. And since gdb isn't realiable in this case, how about manual
code inspection? try to observe anything that could lead to null
derefence. BTW, does the machine use channel bonding?
Also, please check the Makefile located in the top tree of kernel
source. When you enable kernel debugging, besides adding -g, does it
throw away -O2 ( or -O3 or even -O1)? AFAIK, mixing -g and -O (greater
than 0) would still confuse gdb due to code optimization.
regards,
Mulyadi
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
