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 <matej.kupljen@xxxxxxxx>
Ultra d.o.o.
