20:48 <apelete> Hello

20:48 <apelete> larsc mth: are you there ?

20:49 <apelete> I'm trying to debug a kernel issue in the jz4740 musb driver

20:51 <apelete> gdb log: http://paste.debian.net/46591/

20:51 <apelete> jz4740 musb code: http://paste.debian.net/46592/

20:52 <apelete> according to gdb log, driver got stuck in platform_set_drvdata()

20:52 <apelete> but I can't tell why, I don't see anything suspicious

20:54 <apelete> larsc mth: could you please tell me what's wrong in there ?

20:54 <mth> I'll try, looking at the code now

20:55 <apelete> thanks

21:00 <larsc> I don't think it is possible to get stuck in platform_set_drvdata

21:05 <mth> yeah, there is no loop there, so it should always exit

21:06 <mth> clk_put is not necessary if you acquired it with devm_clk_get

21:09 <apelete> ok

21:09 <mth> but I don't see anything obviously wrong

21:10 <apelete> mth: so what's wrong in the code then ? how come the kernel is panicking ?

21:10 <apelete> <mth> but I don't see anything obviously wrong

21:10 <apelete> I still have gdb running right now

21:11 <apelete> mth: I can print some variables if you suspect something, and paste it so you can see

21:11 <mth> where does that SIGHUP come from?

21:12 <apelete> good question, I don't really see where it might come from

21:13 <mth> I mean, why does the debugger stop there, something must have triggered it?

21:14 <mth> does the kernel get stuck as well if you boot it without the debugger?

21:14 <mth> and if so, what is the last thing that it logs?

21:14 <mth> I tend to debug with logging rather than interactive debuggers most of the time; I still mistrust debuggers from my Turbo Pascal days

21:15 <apelete> ok I'll recompile it right away without the debugger option and see what happens

21:15 <viric> gdb isn't that bad :)

21:19 <apelete> I need it to understand how the usb code works (looking at the call stack and printing variables, and so on)

21:19 <apelete> but I will disable it just for now to see what happens

21:28 <mth> viric: a big part of the problem was that the Turbo Pascal IDE ran in the same process as the program being debugged, so if you had any memory corruption the debugger itself or the data it was operating on could be invalidated

21:29 <mth> gdb is more reliable, but still there are situations in which it is feeding nonsense

21:31 <pcercuei> and it's generally a bad idea to trust blindly a program

21:52 <apelete> mth: I'm recompiling, should get the log soon

21:52 <apelete> meanwhile, what does that SIGHUP means in kernel context ?

21:59 <apelete> mth: boot log -> http://paste.debian.net/46609/

21:59 <apelete> not very helpful if you ask me :)

22:01 <qi-bot> [commit] Paul Cercueil: Remove calls to sync() (master) http://qi-hw.com/p/gmenu2x/8452c03

22:01 <qi-bot> [commit] Paul Cercueil: Remove calls to setInputSpeed(), as it only needs to be called once (master) http://qi-hw.com/p/gmenu2x/217a9b5