**** BEGIN LOGGING AT Fri Jul 26 02:59:59 2019
Jul 26 13:22:01 <embden_new[m]> ds2:  any thoughts - https://pastebin.com/FXPuxQ1t , it seems that uart3 clocks are not (de)initializing right
Jul 26 13:28:59 <julieng> embden_new[m]: A few questions
Jul 26 13:29:07 <julieng>   - What is the UART used by Xen?
Jul 26 13:29:28 <julieng>    - How did you implemented the virtual crossbar so far? Is it just NOP?
Jul 26 13:29:54 <julieng>    - Do you see the same error on baremetal?
Jul 26 13:30:11 <embden_new[m]> julieng:  uart2 and the virtual crossbar is not implemented yet
Jul 26 13:30:26 <embden_new[m]> I don't understand how should it be implemented
Jul 26 13:31:04 <julieng> embden_new[m]: I am not sure to understand what you mean by "not implemented" for the UART2
Jul 26 13:31:27 <julieng> Dom0 should use the HVC interface
Jul 26 13:31:48 <embden_new[m]> yes, it uses it
Jul 26 13:32:04 <julieng> So what's the concern with UART2 then?
Jul 26 13:33:08 <julieng> embden_new[m]: Oh, I think I misread your comment :(
Jul 26 13:33:11 <julieng> Sorry for that
Jul 26 13:33:37 <embden_new[m]> julieng:  according to the log. UART2 is debug interface used by xen. But the error happens when dom0 tries to make a softreset for uart3 and probably it hangs when it tries to deinit clocks for uart3
Jul 26 13:34:28 <julieng> embden_new[m]: I am wondering if interrupt are involved while re-initializing the UART3 clock.
Jul 26 13:36:41 <julieng> embden_new[m]: The function doing the reset is omap_hdq1w_reset
Jul 26 13:37:12 <julieng> The function will call omap_hwmod_softreset() that may return an error (but is ignored).
Jul 26 13:37:24 <julieng> It would be interesting to know if the function is actually failing
Jul 26 13:55:25 <pratimugale[m]> zeekhuge: While running the Makefile for 4/2 - channel waveforms, I sometimes get this message: https://pastebin.com/CbjqZbEG. But executing the generated object file again gives correct output on all 4 leds. It happens when I run the Makefile for the first time after booting the BBB: https://github.com/pratimugale/PRUSS-Bindings/blob/master/examples/firmware_examples/example9-multichannel-waveform-gen/Makefile
Jul 26 13:55:25 <pratimugale[m]> After the first time, the messages don't reappear and the Makefile runs correctly. It is something to do with the stack size of prussd.py but what could be causing it
Jul 26 14:25:25 <cwicks[m]> ChanServ: Thank you students and mentors for submitting evaluations on time!  Next formal GSoC org check point is August 19 - 26, 2019 for final code check in and evals.  Let's keep coding!!
Jul 26 14:48:51 <embden_new[m]> julieng:  "Do you see the same error on baremetal?" No
Jul 26 14:52:31 <zeekhuge[m]> pratimugale: whats your 'uname -a'?
Jul 26 14:53:02 <zeekhuge[m]> And do you see something in the dmesg of similar sort? Some error messages?
Jul 26 14:53:24 <pratimugale[m]> zeekhuge: uname -a: Linux beaglebone 4.14.71-ti-r80 #1 SMP PREEMPT Fri Oct 5 23:50:11 UTC 2018 armv7l GNU/Linux
Jul 26 14:56:26 <embden_new[m]> julieng:  "I am wondering if interrupt are involved while re-initializing the UART3 clock." Should be involved since the function waits for 10000 usec for a reply
Jul 26 14:57:47 <julieng> embden_new[m]: That's properly the issue then. But I would double-check first.
Jul 26 15:01:00 <zeekhuge[m]> pratimugale: it is something related to kernel. Check the dmesg
Jul 26 15:01:24 <pratimugale[m]> zeekhuge: dmesg isn't giving out any error messages right now (I am trying to reproduce the error message)P
Jul 26 15:01:41 <pratimugale[m]> checking again
Jul 26 15:02:29 <zeekhuge[m]> Check dmesg when the makefile shows these messages
Jul 26 15:06:45 <pratimugale[m]> zeekhuge: https://pastebin.com/VuSVVD7C
Jul 26 15:06:48 <pratimugale[m]> line 6
Jul 26 15:08:40 <zeekhuge[m]> I dont think line 6 is the problem
Jul 26 15:08:52 <zeekhuge[m]> Error starts from line number 10
Jul 26 15:09:20 <zeekhuge[m]> Its a kernel panic. And yes, i think their is something in the prussd thats causing it.
Jul 26 15:11:54 <pratimugale[m]> <zeekhuge[m] "Its a kernel panic. And yes, i t"> understood, although line 6 wasn't present in the previous dmesg and does show up in red now
Jul 26 15:12:55 <pratimugale[m]> Still I think the error is related to prussd
Jul 26 15:13:34 <zeekhuge[m]> I haven't looked in carefully. Possible. Will try after sometime. If its L6, then looks like something wrong with resource table.
Jul 26 15:13:45 <zeekhuge[m]> In the firmware.
Jul 26 15:14:00 <zeekhuge[m]> Will try to look into.
Jul 26 15:14:40 <pratimugale[m]> zeekhuge: ok, thanks, doing the same
Jul 26 16:34:22 <embden_new[m]> ds2:  julieng  I don't understand how to turn on pr_debug messages.  I enabled dynamic debug and added -DDEBUG option in Makefile but with no success
Jul 26 16:46:25 <embden_new[m]> CFLAGS_omap_hwmod.o := -DDEBUG
Jul 26 16:46:25 <embden_new[m]> for omap_hwmod.c
Jul 26 16:49:15 <julieng> embden_new[m]: I guess by "dynamic debug" you mean "CONFIG_DYNAMIC_DEBUG".
Jul 26 16:49:37 <embden_new[m]> julieng:  yes
Jul 26 16:49:39 <julieng> If so, the dynamic debug has priority of -DDEBUG.
Jul 26 16:50:46 <embden_new[m]> but it doesn't show up
Jul 26 16:51:00 <embden_new[m]> pr_warn does but pr_debug doesn't
Jul 26 16:54:28 <julieng> IIRC, The linux console will suppress debug messages by default.
Jul 26 16:54:44 <julieng> you need to pass ignore_loglevel  on your Linux command line.
Jul 26 16:55:38 <julieng> Or modify the default console level (see CONFIG_CONSOLE_LOGLEVEL_DEFAULT) so debug are not suppressed
Jul 26 17:22:37 <embden_new[m]> julieng:  thanks
Jul 26 21:23:53 <ds2> echo 7 7 7 7 > /proc/sys/kernel/printk will enable it at run time
Jul 26 21:24:01 <ds2> set that to something lower then 7 to filter out
Jul 26 21:24:14 <ds2> practice typing this bind can be helpful if your console is flooded
Jul 26 21:27:21 <julieng> ds2: That's assuming you have access to the console :).
Jul 26 21:27:45 <julieng> ds2: AFAIK, Denis is debugging before init is even started.
Jul 26 21:29:59 <ds2> how far before init?
Jul 26 21:30:32 <ds2> init is optional and eliminating it may be a good idea (cuts down on issues due to badly populated initramfs/dev trees)
Jul 26 21:30:49 <ds2> adding init=/bin/sh to the kernel commandline would do that
Jul 26 21:36:08 <julieng> ds2: Quite far. The crossbar is not implemented so it is quite unlikely to reach init (even from an initramfs)
Jul 26 21:38:48 <ds2> julieng: if that's the case, I wonder if he can use the physical console (frame buffer) to help debug it
Jul 26 21:40:06 <julieng> ds2: He has serial access but debug message are not printed because they are suppressed by the kernel. Hence my suggestion of using ignore_loglevel or CONFIG_CONSOLE_LOGLEVEL_DEFAULT
Jul 26 21:40:37 <julieng> ds2: Also, even if the serial is not properly working. Xen provides debug hypercall that can easily be hooked in Linux.
Jul 26 21:43:21 <ds2> julieng: 'k... only reason I suggested that is there is no interrupts involved in that path
Jul 26 21:48:04 <julieng> ds2: I tend to stay far away from framebuffer :).
**** ENDING LOGGING AT Sat Jul 27 02:59:57 2019