**** BEGIN LOGGING AT Tue May 04 02:59:57 2021 May 04 11:42:09 m May 04 13:13:23 Hi Guys, May 04 13:13:24 I am using beaglebone black with the version details Linux beaglebone 4.14.71-ti-r80 Debian 10. I have few node and C applications running all the times. Sometimes, beaglebone freeze and could not do SSH using USB interface. It works only after reboot. Initially I am able to login using putty but I could not login after some time. Please let me May 04 13:13:24 know if any have issue with USB connectivity in between? May 04 13:37:43 it's just the usb connectivity that fails, the system otherwise continues running normally? May 04 13:37:47 oh he left May 04 14:12:43 Hi @zmatt GoodMoring: Previously I asked about accepting user input in service script, I found that chvt command is not working, which causes service not work. But I don't know why chvt command doesn't switch tty May 04 14:27:05 I don't really get the point of switching vt there anyway, why doesn't it just use tty1 May 04 14:29:33 cannot even use tty1. currently /dev/console is on /dev/ttyS0 May 04 14:30:44 /dev/console being on /dev/ttyS0 has no reason to have any relevance on the ability to use tty1 May 04 14:31:13 well. I don't know how to use tty1, then May 04 14:31:40 just to confirm, you're trying to get input via keyboard and display attached directly to the BBB ? (via USB and HDMI respectively) May 04 14:33:03 No. getting input from a Hyperterminal connected to UART0 serial port May 04 14:33:46 then why are you trying to use VTs? those have nothing to do with the serial console May 04 14:33:57 no keyboard directly connected to BBB. No Display connected to HDMI May 04 14:34:58 then nothing to do with VTs has any business being in your service file May 04 14:35:59 Maybe I am wrong to use VTs. So is it possible to get some input from /dev/ttyS0 during booting? May 04 14:36:13 (i.e. any directive containing "VT" or any reference to tty1 or tty13 or whatever is mistaken) May 04 14:36:39 sure May 04 14:37:16 Can you show me some steps/instructions to implement that? May 04 14:37:17 your service can attach to ttyS0 as long as you make sure you run before serial-getty@ttyS0.service May 04 14:38:28 probably mostly similar to what you were already doing, just use ttyS0 instead of tty13, get rid of anything VT-related, and sequence Before=serial-getty@ttyS0.service instead of Before=gettty@tty1.service May 04 14:39:18 Ok, great. Let me try that. I will feed back to you May 04 14:40:57 btw I suggest getting rid of that RequiredBy directive May 04 14:41:06 ok May 04 14:41:13 and there's also no reason to sequence yourself before ssh.service May 04 14:41:20 that will just make debugging difficult May 04 14:42:48 adding Before= clause. Leave After= ? May 04 14:43:02 I don't remember what After clause it had May 04 14:44:43 After=network.target,sshd.service systemd-logind.service May 04 14:46:34 it had After=sshd.service ? huh, I though it sequenced itself before it but I must have misremembered May 04 14:46:50 regardless I don't really see any good reasons for any of those ordering constraints May 04 14:47:48 I just comment the After= May 04 15:05:30 OK. it's not working. I am going to give up. Thank you for you help May 04 15:36:16 zmatt Greeting! Do you have any update for me? If so, please pass on. I am printing my question again for a quick look below. May 04 15:36:17 I am using beaglebone black with the version details Linux beaglebone 4.14.71-ti-r80 Debian 10. I have few node and C applications running all the time. Sometimes, beaglebone freeze and could not do SSH using USB interface. It works only after reboot. Initially, I am able to login using putty but I could not login after some time. Please let me May 04 15:36:17 know if any have issue with USB connectivity in between? May 04 16:00:27 is there a way to bypass the uEnv.txt file from the uboot console? say loading uEnvsafe.txt instead? May 04 16:00:41 it seems to be hardcoded to some env variables. May 04 16:05:20 Konsgn: you can just manually boot from the u-boot console May 04 16:05:51 haven't figured out which things to run to do so. May 04 16:06:22 there's surprisingly little info on how to use the shell May 04 16:07:06 https://pastebin.com/JPMH3bzT May 04 16:07:10 this is some old notes May 04 16:07:18 but I presume they still work May 04 16:07:56 Woot! thank you May 04 16:08:30 the main concern might be whether it will load a dtb that is usable without any overlays May 04 16:09:01 but I think it should May 04 16:09:04 gunna try the load mmc with my uEnvsafe May 04 16:09:26 most settings in the uEnv.txt will be ignored anyway by these steps May 04 16:10:20 basically everything except uname_r= and cmdline= (and dtb= if set) May 04 16:12:43 so unless you're using a custom dtb, don't use these steps with e.g. a CAPE attached May 04 16:12:48 who the hell thought "uname_r" was a logical name for a variable? May 04 16:12:56 mru: it's the output of uname -r May 04 16:13:07 yes, and it's idiotic May 04 16:13:12 *shrug* May 04 16:13:14 why not call it kernel_version? May 04 16:13:30 or cat_proc_version May 04 16:13:47 you're not wrong, but it doesn't bother me May 04 16:14:48 it tells me whoever came up with it is lacking in some basic understanding of the system architecture May 04 16:14:49 woot, it works! kernel panic, but at least it boots, now gotta update to point to my custom kernel. thankyou! May 04 16:15:09 mru: I don't see reason for that conclusion May 04 16:15:24 anyone who did understand things would have named it logically May 04 16:15:50 uname is a shell command that reports various properties of the system May 04 16:15:53 they may have thought this was more user-friendly, I dunno May 04 16:16:00 including the kernel version May 04 16:16:21 at the u-boot stage, it doesn't even exist May 04 16:16:48 right, but the user isn't faced with it "at the u-boot stage", it's a config var May 04 16:16:52 in a file May 04 16:17:03 and the thing it configures is the kernel version May 04 16:17:09 which incidentally is reported by the uname command May 04 16:17:12 I dunno, like I said... you're not wrong, but I can't get worked up about it May 04 16:17:13 and many other methods May 04 16:17:27 it just annoys me a little each time I see it May 04 22:43:29 Does anyone know of the MIO BBB Cape? May 04 22:43:50 I got it to goof around w/ it and found little docs. on it. I think the co. went under. May 04 22:44:12 Let me get the link. May 04 22:45:03 Here is the link: https://www.seeedstudio.com/ZD-MIO-BeagleBone-Black-KIT-p-4761.html May 04 22:45:26 It is, or was, made by zdauto.com people but their link is non-existent. May 04 22:46:27 There is a 'datasheet' and schematic. Anyway, I will promote this 'new' Cape soon w/ a nice write up. May 04 22:53:06 I guess I just need to know if M5S I/O is a standard or some type of made up mechanism for this specific Cape. May 04 23:01:15 Do not fret, I will contact seeed again. May 04 23:01:25 I am sure they have ideas since they sell the item. May 04 23:12:16 Okay, okay...I found TDE Instruments. May 04 23:12:37 Nice, little packages of adapter peripherals! May 04 23:12:41 Neat. May 05 00:54:11 anyone know how to deal with segmentation faults in python May 05 01:17:25 that question is uselessly vague May 05 01:17:47 you might as well ask "does anyonw know how to fix bugs?" May 05 01:17:49 so is the segmentation fault error May 05 01:17:51 lol May 05 01:17:57 well I know what line is doing it May 05 01:18:01 using fault finder May 05 01:18:05 but i do not know why May 05 01:18:16 I am running this on my laptop May 05 01:18:25 so I would not expect to run into that error May 05 01:18:53 pure python code will normally not segfault, typically it will require doing things with modules such as ctypes May 05 01:19:32 but you'll have to share some actual context if you want feedback May 05 01:19:42 i will May 05 01:19:48 trying to play around a bit more May 05 01:20:02 this is taking images from my camera May 05 01:20:04 and displaying it May 05 01:33:16 arg i think it is with my asyncio code May 05 01:35:19 that sounds unlikely May 05 01:35:52 https://pastebin.com/GQc48Hf2 May 05 01:37:04 shttps://pastebin.com/3ZBCkhU4 is my code May 05 01:37:12 so that line 171 is where it always crashes May 05 01:37:19 it is the image with the most info May 05 01:37:31 but raw and unmodified the image is only 1.3mb May 05 01:37:38 and this is thresholded May 05 01:38:01 so it should be even smaller but it chokes something off. If I comment out the display of that image the code runs fine May 05 01:44:43 its like that image file is too larger to stream to qt May 05 01:44:52 which seems a bit ridiculous May 05 01:46:41 I'm a bit confused, you're passing the same width, height, bytesPerLine, and pixelformat for each of the three images, so how can the first one possibly be larger? May 05 01:47:12 the other two just have some shapes drawn on a black background May 05 01:47:52 the first one is just the raw image made thresholded May 05 01:47:53 how is that relevant? the size of each image is necessarily height * bytesPerLine May 05 01:48:04 (size in bytes that is) May 05 01:48:10 hm May 05 01:48:23 so maybe the fact that it is the first one is sort of irrelevant May 05 01:48:33 the code always runs once May 05 01:48:37 on the 2nd pass it fails May 05 01:48:50 ? May 05 01:49:43 anyway, most likely you're just misusing QImage and that's causing the segfault May 05 01:50:18 i got this from a demo May 05 01:50:35 and it works if I take out that first call May 05 01:50:40 but let me look at the documentation May 05 01:51:34 make sure the parameters you pass are actually correct for the image data May 05 01:51:45 ok May 05 01:51:54 something about that image I will double check May 05 01:55:42 in particular, if you're claiming it's RGB888 then ch must be equal to 3 (i.e. bytesPerLine == 3*w), and to meet the alignment requirements in that case w must be a multiple of 4 May 05 01:56:10 and in all cases h * bytesPerLine must be the number of bytes in the image data you pass May 05 01:56:25 good point May 05 01:56:56 if you're saying the original_img has a different size than the other two images, then your QImage construction calls cannot possibly be right since you're passing the same width/height to all of them May 05 01:57:28 that was it May 05 01:57:54 i had a grayscale image but I was treating it like I had 3 channels May 05 01:58:55 I feel like the python qt binding could have checked that, but I guess it doesn't **** ENDING LOGGING AT Wed May 05 02:59:56 2021