On Sat, 30 Sep 2006, Paolo Ornati wrote: > This one should be correct: > > 00000000 <str>: > 0: 5c pop %esp > 1: 89 57 2c mov %edx,0x2c(%edi) > 4: 8b 40 44 mov 0x44(%eax),%eax > 7: c7 47 40 00 00 00 00 movl $0x0,0x40(%edi) > e: 89 47 3c mov %eax,0x3c(%edi) > 11: 8b 45 00 mov 0x0(%ebp),%eax > 14: 8b 55 04 mov 0x4(%ebp),%edx > 17: 89 02 mov %eax,(%edx) > 19: 89 50 04 mov %edx,0x4(%eax) > 1c: 89 6d 00 mov %ebp,0x0(%ebp) > 1f: 8d 47 18 lea 0x18(%edi),%eax > 22: 89 6d 04 mov %ebp,0x4(%ebp) > 25: 39 47 18 cmp %eax,0x18(%edi) > 28: 75 4b jne 75 <main+0x75> > 2a: 0f b6 47 50 movzbl 0x50(%edi),%eax || ---> _This_ is where the crash occurred.
> 2e: a8 02 test $0x2,%al > 30: 88 44 24 08 mov %al,0x8(%esp) > 34: 74 3f je 75 <main+0x75> > 36: 0f b6 46 20 movzbl 0x20(%esi),%eax <----- crash! || ---> Not here. > 3a: 8b 4e 20 mov 0x20(%esi),%ecx > 3d: ba .byte 0xba > 3e: fe (bad) > 3f: ff .byte 0xff The actual last instruction looks like this: > 3d: ba fe ff ff ff mov $0xfffffffe,%edx > So now the problem is, as you pointed out, to discover why EIP is > pointing to "b6" intead of "0f". Another problem: The oops message shows that edi = 0. So there should have been an addressing exception in the line at offset 25, assuming the CPU ran straight through this code. Comparing the disassembly to the source code shows the instruction that crashed was in this part of drivers/usb/host/uhci-q.c:uhci_giveback_urb() /* Take the URB off the QH's queue. If the queue is now empty, * this is a perfect time for a toggle fixup. */ list_del_init(&urbp->node); if (list_empty(&qh->queue) && qh->needs_fixup) { It was the fetch of qh->needs_fixup, which is a bitfield. The alternative is that something caused a jump directly to the byte at 2b. Maybe a return address got corrupted on the stack; obviously there aren't any direct jumps to that location. I don't have a clue how to track this any further. We can rule out the possibility that the kernel's object code was corrupted. The dump in the oops message agrees exactly with the objdump output. The simplest answer is that Arkadiusz's CPU is a little flakey. But that would be too easy. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users