CONFIG_DEBUG_STACKOVERFLOW is enabled, but doesn't give any information. I even increased STACK_WARN to see if it's just on the edge...
Basically all debug options are enabled, but none produces any useful output...
In addition I was playing a little bit more and got more useful information.
First, CONFIG_PREEMPT should be enabled, because without, the oops seems to be reported at the wrong position!! (no idea why ...)
Hence, the position of the oops in the call trace I send in my first mail is wrong :-(
The right position is:
list_del (&qtd->qtd_list);
More precisely in the inlined function from include/linux/list.h:
static inline void __list_del(struct list_head * prev, struct list_head * next)
{
next->prev = prev; <---- here
prev->next = next;
}
static inline void list_del(struct list_head *entry)
{
__list_del(entry->prev, entry->next);
entry->next = LIST_POISON1;
entry->prev = LIST_POISON2;
}--------------------------------
After introducing the following check
if (qtd->qtd_list.prev != LIST_POISON2 && qtd->qtd_list.next != LIST_POISON1) {
list_del (&qtd->qtd_list);
} else {
printk("double list_del %x %x %x \n",qtd->qtd_list,qtd->qtd_list.prev,qtd->qtd_list.next);
}
I get the following messages
Apr 19 15:28:52 kernel: double list_del 100100 200200 200200
Apr 19 15:28:52 kernel: ehci_hcd 0000:01:06.2: dma_pool_free ehci_qtd, f797d540/a7a7a7a7 (bad dma)
Apr 19 15:28:52 kernel: double list_del 100100 200200 200200
Apr 19 15:28:52 kernel: ehci_hcd 0000:01:06.2: dma_pool_free ehci_qtd, f797d5a0/a7a7a7a7 (bad dma)
....
and more of those (200200 = POISON2 ; 100100 = LIST_POISON1; 0000:01:06.2 is the NEC USB 2.0 controller)
Of course other functions don't like it and produce this output:
....
Apr 19 15:28:52 kernel: Slab corruption: start=f798194c, len=128
Apr 19 15:28:52 kernel: Redzone: 0x5a2cf071/0x5a2cf071.
Apr 19 15:28:52 kernel: Last user: [<f8a31e36>](ehci_urb_done+0xd5/0x162 [ehci_hcd])
Apr 19 15:28:52 kernel: 000: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b
Apr 19 15:28:52 kernel: Prev obj: start=f79818c0, len=128
Apr 19 15:28:52 kernel: Redzone: 0x5a2cf071/0x5a2cf071.
Apr 19 15:28:52 kernel: Last user: [<f8a19f04>](sg_clean+0x2d/0x8b [usbcore])
Apr 19 15:28:52 kernel: 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Apr 19 15:28:52 kernel: 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Apr 19 15:28:52 kernel: Next obj: start=f79819d8, len=128
Apr 19 15:28:52 kernel: Redzone: 0x5a2cf071/0x5a2cf071.
Apr 19 15:28:52 kernel: Last user: [<f8a19f04>](sg_clean+0x2d/0x8b [usbcore])
Apr 19 15:28:52 kernel: 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Apr 19 15:28:52 kernel: 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
.... and the kernel doesn't oops!
------------------------------
There is obviously something wrong in the handling of qtd->qtd_list.
In the kernel without preempt the kernel also doesn't oops with the above check, so the oops can't be at the position, where it is reported...
Andreas
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
