**** BEGIN LOGGING AT Thu Aug 15 02:59:58 2019
Aug 15 03:50:20 <pratimugale[m]> zeekhuge: I am able to create packages using checkinstall now, also tested them. I think there was a problem with the Makefile I was using previously. This is what I am using now: https://gist.github.com/pratimugale/d01bc6120f7a75454ab9ceff065fff6f
Aug 15 03:52:51 <pratimugale[m]> I am now adding the scripts to be run after installation to 'postinstall-pak'
Aug 15 03:59:11 <pratimugale[m]> <pratimugale[m] "I am now adding the scripts to b"> and the other files to be installed
Aug 15 04:25:02 <zeekhuge[m]> So the packaging is done now. Right ?
Aug 15 04:25:05 <zeekhuge[m]> What else?
Aug 15 04:25:13 <zeekhuge[m]> What else is left?
Aug 15 04:25:23 <zeekhuge[m]> pratimugale ^
Aug 15 04:27:44 <pratimugale[m]> <zeekhuge[m] "So the packaging is done now. Ri"> Yes, it should be completed today
Aug 15 04:29:48 <pratimugale[m]> zeekhuge: So the things left are to complete the documentation, wiki page, to solve the NULL pointer dereference problem(kernel oops)
Aug 15 04:31:23 <pratimugale[m]> and to add the debugger tool (prudebug), should this be a priority?
Aug 15 04:50:49 * zeekhuge[m] sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/VjEyVhNgXcLvYyJeDGIshMgU >
Aug 15 04:52:33 <pratimugale[m]> zeekhuge: ok, thanks
Aug 15 10:17:25 <embden_new[m]> julieng:  should I test a gp timer via kernel module?
Aug 15 10:31:57 <julieng> embden_new[m]: I don't know much the board and how to use the internal timer. Maybe ds2 and drhunter[m] have an idea?
Aug 15 10:32:42 <julieng> embden_new[m]: The console is not using the crossbar but Xen events channels. So it is normal it is still works :)
Aug 15 10:54:23 <embden_new[m]> julieng:  I also tried to pass clocksource="gp_timer" to the kernel but nothing seems to be changed
Aug 15 10:58:51 <julieng> embden_new[m]: Do you see Linux receive interrupt for the timer? If you have console access you can cat /proc/interrupts.
Aug 15 11:03:55 <embden_new[m]> julieng:  https://pastebin.com/kM6rsm76
Aug 15 11:46:22 <embden_new[m]> julieng:  sstabellini  is it possible to see the mapping between irq and virq lines?
Aug 15 11:56:21 * embden_new[m] sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/IwCzBLJJmmorwYuuUCEjjBfc >
Aug 15 12:12:52 <embden_new[m]> s/a lower/higher
Aug 15 13:35:12 <embden_new[m]> julieng:  should I also use vgic_connect_hw_irq to follow the changes in the crossbar by dom0?
Aug 15 14:30:33 <embden_new[m]> julieng:  sstabellini  drhunter  also, whether linux knows about vgic? I thought it thinks that deals with real gic.
Aug 15 14:37:27 <julieng> embden_new[m]: From the pastebin, Linux received one interrupt from the GP timer on CPU0. I am not sure why it didn't receive more.
Aug 15 14:38:31 <julieng> We don't normally dump the mapping between irq and VIRQ line. But you could add some print in route_irq_to_guest() to see how Xen requested the configuration.
Aug 15 14:39:53 <julieng> I am not sure to understand what you mean by "but there are interrupts with a lower IRQ numbers". Which GIC interrupts are meant to be routed to the crossbar?
Aug 15 14:39:54 <embden_new[m]> julieng:  the last question was an ambiguity in linux code, they call crossbar numbers "virq"
Aug 15 14:40:12 <embden_new[m]> with higher*
Aug 15 14:42:05 <embden_new[m]> I meant that though in xen output there is a range: (XEN)     Interrupts { 39-124, 191 } in here https://pastebin.com/kM6rsm76 in the left column there are numbers both lower and higher than the range
Aug 15 14:43:15 <julieng> embden_new[m]: It means that interrupts 39 to 124 and interrupt 191 was routed to Xen.
Aug 15 14:43:30 <julieng> s/Xen/Dom0/
Aug 15 14:45:36 <julieng> This was done by the function map_irq_to_domain. So you could look what they are referring to by print the device name.
Aug 15 14:48:22 <julieng> Regarding the question whether Linux knows about the vGIC. It does not know it. The vGIC is partly using the hardware (virtual CPU interface) and an emulated distributor to let the guest thinks it is using a real one.
Aug 15 14:48:47 <julieng> The beauty is Linux can drive it the same way as it would a real one.
Aug 15 14:49:17 <embden_new[m]> julieng:   hm, and the interesting part that it seems that Linux start to assign interrupts to the crossbar starting from the last crossbar slot. So, most of the Linux'es interrupts are probably not mapped to xen
Aug 15 14:51:39 <embden_new[m]> because I initilise crossbar from low to high slot numbers
Aug 15 14:51:44 <julieng> embden_new[m]: Well, the goal of the crossbar emulation is to setup the routing. For the GIC interrupt, you could use the same approach as acpi_route_spis() for now.
Aug 15 14:52:03 <julieng> The code will route all GIC interrupts to Dom0 but the one used by Xen.
Aug 15 14:52:26 <julieng> This will let you focus on just configuring the crossbar.
Aug 15 14:52:51 <julieng> Once you are sure you receive interrupt, then you can focus on removing the "hack".
Aug 15 14:58:12 <embden_new[m]> ok
Aug 15 15:26:07 <embden_new[m]> julieng:  also, it is strange that console glitches in dom0
Aug 15 15:30:09 <julieng> embden_new[m]: What do you mean? Any example?
Aug 15 15:30:23 <embden_new[m]> julieng:  missing symbols
Aug 15 15:32:19 <embden_new[m]> now it works good, but sometimes it miss random symbols in input
Aug 15 15:33:06 <embden_new[m]> # cat /dev/interrupts
Aug 15 15:33:07 <embden_new[m]> cat: can't open '/dev/trut': No such file or directory
Aug 15 15:34:36 <embden_new[m]> the reason might be that uart registers are not cleaned for some reason, e.g. aftter timeout, for example, because the uart interrupt "timeout" wasn't received
Aug 15 15:34:42 <embden_new[m]> but I don't know
Aug 15 15:35:59 <embden_new[m]> https://pastebin.com/V14c4hw8
Aug 15 15:37:16 <julieng> Oh, I can see two reasons.
Aug 15 15:38:03 <julieng> 1) The hypercall used by the console is not working as expected. I have seen some issues with recent distros. This should be fixed by https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00404.html
Aug 15 15:39:41 <julieng> 2) If 1) does not remove the glitches, then an error in the UART is possible. We don't have automated testing on platform using the OMAP UART.
Aug 15 15:40:14 <julieng> The driver implementation in Xen is drivers/char/omap.c
Aug 15 15:44:40 <embden_new[m]> ok
Aug 15 17:19:41 <jkridner[m]> vaishnav98_: don't forget to run 'npm run-script beautify' on any bonescript modifications....
Aug 15 17:19:55 <jkridner[m]> also, I am not interested in having sudo shell commands put in there.
Aug 15 17:27:11 <vaishnav98_[m]> <jkridner[m] "vaishnav98_: don't forget to run"> jkridner: sorry will fix it , also I didn't remember that I had an open pull request and did directly commit to master branch the addition of insclick/rmclick methods.
Aug 15 17:27:32 <jkridner[m]> yeah, doing pull requests against master can be a double-edged sword.
Aug 15 17:30:59 <vaishnav98_[m]> <jkridner[m] "also, I am not interested in hav"> currently insclick needs to perform writes like sys/class/i2c-adapter/i2c-3/new_device and perform modprobe (for OLED displays)  and thus requires root permission , how can I deal with this?
**** ENDING LOGGING AT Fri Aug 16 03:05:29 2019