Hi
> > I tried you patch, and this is what I get on 2.6.16-rc5:
I meant, 2.5.15-rc5 of course, and NOT 2.6.15-rc5. Sorry.
> Well, thats a fun one. I'm assuming you tried to boot with a device
> plugged in. I'm a bit confused by the __reqest_region coming from
> usb_create_hcd - I quickly glanced at the function, and I don't see anything
> that would have called request_region / request_mem_region. However,
> there *is* a request_mem_region call immediately after the usb_create_hcd
> call in usb_ehci_au1xxx_probe, and I wonder that might be the guilty party.
I set up my BDI and tried to debug this. This is what I can tell you,
and maybe you can then be able to help me:
I get past the request_mem_region and ioremap in ehci-au1xxx.c.
I get to line 144:
if ((retval = driver->reset (hcd)) < 0) {
now, driver->reset points to the
(gdb) p driver->reset
$6 = (int (*)(struct usb_hcd *)) 0x803505d4 <ehci_init>
I step into the call and I get to ehci_init in
drivers/usb/host/ehci-hcd.c.
If I continue, i get to the ehci_mem_init in the
drivers/usb/host/ehci-mem.c
On line:
228 memset (ehci->pshadow, 0, ehci->periodic_size * sizeof (void *));
If I do next in gdb, I end up in include/asm-mips/io.h, line
425 BUILDIO_MEM(l, u32)
(Well, I am lost here now)
Now if I disassemble at $pc:
(gdb) x/20i $pc
0x80350760 <ehci_init+396>: lw v1,0(s0)
0x80350764 <ehci_init+400>: lw a2,8(v1)
0x80350768 <ehci_init+404>: andi v0,a2,0x80
0x8035076c <ehci_init+408>: beqz v0,0x80350888 <ehci_init+692>
0x80350770 <ehci_init+412>: srl v0,a2,0x4
0x80350774 <ehci_init+416>: li v0,8
0x80350778 <ehci_init+420>: sw v0,40(s0)
0x8035077c <ehci_init+424>: lw v0,24(s0)
0x80350780 <ehci_init+428>: lw a1,16(s0)
0x80350784 <ehci_init+432>: li v1,-2
0x80350788 <ehci_init+436>: and v0,v0,v1
0x8035078c <ehci_init+440>: li v1,-1
0x80350790 <ehci_init+444>: sw v1,48(s0)
0x80350794 <ehci_init+448>: sw v0,24(s0)
0x80350798 <ehci_init+452>: sw zero,20(s0)
0x8035079c <ehci_init+456>: sw zero,72(a1)
0x803507a0 <ehci_init+460>: lw a0,16(s0)
0x803507a4 <ehci_init+464>: li v1,-32
0x803507a8 <ehci_init+468>: li a1,1
0x803507ac <ehci_init+472>: lw v0,68(a0)
(gdb) p $s0
$9 = 0x8053c0d0
(gdb) x/x $s0
0x8053c0d0: 0x00000000
So I guess, that the instruction at 0x80350764 is loading from location
0 and offset 8, which can be seen also in the original post:
[4294668.602000] CPU 0 Unable to handle kernel paging request at virtual
address 00000008, epc == 80350764, ra == 80350760
What is going on here?
Is this some stack corruption, because of all this strange jumps
over the source code (I know optimisation is turned on, but still).
I hope this can help someone, I still have a lot of learning
to do to figure this out.
BR,
Matej
--
Matej Kupljen <[EMAIL PROTECTED]>
Ultra d.o.o.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
