I found that bug in this place

(gdb) l *0xc01c8973
0xc01c8973 is in rb_insert_color (lib/rbtree.c:80).
75
76              while ((parent = rb_parent(node)) && rb_is_red(parent))
77              {
78                      gparent = rb_parent(parent);
79
80                      if (parent == gparent->rb_left)
81                      {
82                              {
83                                      register struct rb_node *uncle = 
gparent->rb_right;
84                                      if (uncle && rb_is_red(uncle))


if i not wrong understand message "unable to handle kernel NULL pointer 
dereference at virtual address 00000008" its was known that "gparent == 
Null"?
Or i hope or i try find a mare's-nest?

Ok =) I hope in next week you found bug place and fix it!

PS. if you ask where i can read "kernel panic dump logic" literature 
and try find bugline in code.
I read dump and see that bug in function "rb_insert_color" + some 
shift (in asm?) that called from htb_dequeue? But in htb_dequeue not 
have calling rb_insert_color =( Or some nodes in trace was skipped?

Its for change up my education ;)

quoted

I'll not be able to assist you until monday (but I'll try to look
into the code and maybe to prepare some new patch - but it needs
a lot of checking to not add too much of this locking as well).

I think you can stay with a kernel whichever you like - I'm not sure
any config changes or even more debugging can change much, but maybe
I'm wrong. It looks to me like some locking is missing or interrupted.
If you are working weekends and find something new, don't wait: maybe
somebody else here could be interested too.
 
Cheers,
Jarek P.
  

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html