On Tue, 8 Nov 2005, Cristian Chiarello wrote:
> Please, if you wont, see the source in attachment.
> I'm a newbie with kernel code: if you see something obvious
> wrong, please notify to me.
> My comment is "CC" and there are others modification "GB", who
> have made the porting.
I took a look at a few functions in the driver you
mentioned. At a glance, nothing seemed to be obviously
wrong.
> In the last test I have made, I have only added some "printk"
> start from "usb_free_priv" to end in s1161_unlink_urb.
> The strange thing, is that after this add, when I grab picture
> the output loop with:
>
> dl_done_list( ohci = 0xc1e2dc00, td_list = 0x00000000)
> dldonelist da irqhand
> dl_reverse_done_list td_list 00000000
> dl_done_list( ohci = 0xc1e2dc00, td_list = 0x00000000)
> dldonelist da irqhand
> dl_reverse_done_list td_list 00000000
> dl_done_list( ohci = 0xc1e2dc00, td_list = 0x00000000)
> dldonelist da irqhand
> dl_reverse_done_list td_list 00000000
> dl_done_list( ohci = 0xc1e2dc00, td_list = 0x00000000)
>
> Because pstDoneHead_hcd is never initialized.
Maybe initialized and set back to NULL?
> Can printk be a problem???
Definitely the driver is the culprit and not printk. Playing
with printk may just expose or hide timing-related bugs in
the driver.
> With the only printk in the usb_free_priv I have something
> like:
> CRI_kfree ind = c1bac240
> CRI_kfree ind = c1bac240
> CRI_kfree ind = c1bac680
> CRI_kfree ind = c024bf60
> CRI_kfree ind = c024b960
> usb_control/bulk_msg: timeout
> CRI_kfree ind = c1bac580
> pwc Failed to set LED on/off time.
> CRI_kfree ind = c1bac580
> CRI_kfree ind = c1bac680
> CRI_kfree ind = c1bac680
> CRI_kfree ind = c024be20
> CRI_kfree ind = c024b8e0
> CRI_kfree ind = c1bac5a0
> CRI_kfree ind = c1bac5a0
> CRI_kfree ind = c024b8e0
> CRI_kfree ind = c024be20
> CRI_kfree ind = c1bac680
> CRI_kfree ind = c1bac680
> CRI_kfree ind = c1bac660
> CRI_kfree ind = c1bac660
> CRI_kfree ind = c024be20
> CRI_kfree ind = c024b8e0
> CRI_kfree ind = c1bac4c0
> CRI_kfree ind = c1bac4c0
> CRI_kfree ind = c1bac5a0
> CRI_kfree ind = c1bac5a0
> CRI_kfree ind = c1bac660
> CRI_kfree ind = c1bac660
> CRI_kfree ind = c1bac660
> CRI_kfree ind = c1bac660
> CRI_kfree ind = c024b8e0
> CRI_kfree ind = c024be20
> CRI_kfree ind = c1bac6a0
> CRI_kfree ind = c1bac6a0
>
> usulally system work but after
> usb_control/bulk_msg: timeout
> message the sistem becomes unstable.
> Without any printk, kernel crash with less than 10 grab.
Seems that printk's don't allow you to find out the exact
location of the crash. Then you should try to find out it by
its address in code. Here are a few lines from the oops you
posted to me a few days ago:
Unable to handle kernel paging request at virtual address
5a5a5a6a
Internal error: Oops: e3140001
CPU: 0
pc : [<c489c0dc>] lr : [<c489b33c>] Tainted: P
The 'pc' shows the address of the oopsing instruction in
RAM. To get an idea, which function it is, you should print
at, say, module's init function the addresses of the
suspected functions and compare them to the following oops'
'pc' address. Let's suppose the function is foo() and its
address is FOO_ADDR.
When you know the foo(), then you should compile the module
into assembler (hcd_1161.s). Then the oopsing instruction is
the n-th instruction in foo(), where n = (pc - FOO_FADDR)/4.
If it is hard to figure out, what's the C code corresponding
to this instruction, you can insert into the module, in
foo(), between every C statement comments like these:
__asm__ volatile ("#-1\n");
__asm__ volatile ("#-2\n");
...
They will be present in the .s file.
Well, perhaps there are easier ways to figure all this out.
I really don't know 2.4, as I said. Sorry.
Olav
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
