The sequence of instructions really is different each time you boot. Certainly interrupts and task switching happens in different places. The classic "goof" programmers make in writing systems that have multiple tasks going on at the same time is the "race". Program "A" saves the value of "X" and program "B" reads the value of "X" and this works 99.999 % of the time but fails randomly 0.0001% of the time. Same code. The programmer forgets that "X" is more then one byte and take a couple machine cycles to write and as lick would have it program A is interrupted when X is 1/2 written so program B sees gibberish. Then A continues and writes the other half of X. So the cost is the same but where each task gets interrupted is different and with cooperating real tie tasks, you have to put up critical sections around accesses to shared shared data. there are other things like this too. Mistakes like this typically look like flaky hardware
I'm not surprised this kind of stuff happens on a system that was ported from Intel to Arm. Different things are atomic on the two CPUs and as I said, slow computers show this kind of problem more then faster ones On Wed, May 10, 2017 at 8:42 PM, Gene Heskett <ghesk...@shentel.net> wrote: > On Wednesday 10 May 2017 21:31:14 Chris Albertson wrote: > > > Are you running a real time OS on the Pi 3? Sorry to ask I just > > can't keep details of your project in my head. What you are > > describing sound like you might be. Seems lie whatever software > > runs in Kernal mode is being a "hog" and running for more than a > > microsecond with interrupts disabled, suffering like that really > > messes with software other than the hog. > > > > I used to like to use slow computers to test my software because this > > problems showed up. Tossing a gross over kill of raw cpu power many > > times fixes where one driver or real time task is not being nice to > > others. > > > > I saw simmons like your MANY times going back to my days as a device > > driver writer on CDC mainframe computers. I wrote driver for a > > printer multiplexer (the allowed an old line printer to connect to up > > to four different mainframes and it works real well but almost NOTHING > > else works on the our big machines. My driver was using $24M worth of > > hardware to spin and wait on a bit. THAT is the type of thing I > > bet is going on. Some privileged task is hogging the CPU. > > > Not according to htop Chris. This is a quad core, 64 bit per core armhf > processor supposedly running at a minimum speed of 800MHz, claims 1.2 > GHz top. And the effect is apparently random per boot, I'll reboot > after doing something, the keyboard is unusable, I give up and reboot it > again, and its working 100%. It may, or may not, go to pot with > extended uptime. Its on now, and amanda will back it up about 1:30 in > the morning, and tomorrow morning it may act as if the keyboard stuff is > out in the swap file. Thats laggy, but nothing like when it decides to > start ignoring keyup's. ATM its loaded under 2.0, and the screensaver > metaballs is by far the biggest load. htop says swap is empty, but I've > never had any experience using a swap file till now. So I wonder if htop > is lying to me about it. > > I've had the usb monitor thing running several times, and that got me to > throw away a usb extension cord that was picking up megabits of raw > noise so I plugged the rx buttons directly into the pi, and without too > much between the keyboard and the button but 25 feet of air, and it > never misses a keystroke. Of course since the sd card is on the usb > stuff, I also see the "disk" traffic, but its not "busy". Next reboot, > the usbtrace looks the same but no response to keyup events about 90% of > the time. The events are getting thru the rx buttons, but the pi is > ignoring them. > > I would think, since the boot is the same sequence of events every time, > that the results would be pretty consistent, but they are not. Random > as all get out. > > Were you getting an up-board? Or was that Erik? > > > This does not happen in a normal non-real time OS unless you have a > > buggy device driver (as these run in Kernel mode. > > > > The "correct' way to implement real time is to ONLY do the minimum you > > need to in the privileged mode and if more work or some calculation > > needs to be done. You put an entry on a work queue and a user mode > > task reads the queue, > > > This is the only realtime kernel thats been built for the armhf that I > know of. uname says: > Linux raspberrypi 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC > 2016 armv7l GNU/Linux > > I have a boatload of stuff in the jog dial setup, but all of that stuff > is running in its own thread at 100Hz. > > It certainly a puzzle, and if there are tools to take a closer look at > something like this, I'm unaware of them. If you know of any, plz > enlighten me. > > Thanks. > > > In short problem is simtomatic of the bugs that are common in real > > time systems. Especially RT system with a significant computational > > load on them. Hangs, missed interrupts and so on. Debufgging is > > hard, you end up doing stuff like writing debug messages by toggling a > > GPIO pin and watching for the toggle with a logic analyzer. > > > > My method now days is to never even try. I run the real-time stuff on > > a micro controller running an RTOS and the higher level stuff on a Pi3 > > or PC running Linux. > > > > On Wed, May 10, 2017 at 5:49 PM, Gene Heskett <ghesk...@shentel.net> > wrote: > > > Greetings all; > > > > > > Detective stuffs, electronically, have always been my specialty. > > > But I have one now that is a bit of a puzzle even for me. > > > > > > First, I mesaflash verified all 3 of my 7i90's. > > > > > > Then I hung them on the pi, and all of them returned the error I > > > have posted quite a few times already. > > > > > > So I ordered that up-board. In the meantime I am less than ecstatic > > > about that 1366x768 monitor, so I hit wallies and found a 1920x1080 > > > AOC that the sales type said had an hdmi input. $88, so it followed > > > me home. > > > > > > On unpacking I noted two things, first being that its power supply > > > was a wall wart that plugged into the usual round socket on the > > > bottom of the interface ridge on the back. 2nd was that DVI was the > > > best input it had, requiring an hdmi to DVI adapter be inserted and > > > screwed down, and the hdmi plugged into that. > > > > > > Mounted it where the other 1366x768 had been hanging, discovering > > > the arm's bracket nicely covered the I/O shelf, making it quite > > > difficult to get things plugged in and screwed down. > > > > > > Several hours later I finally got /boot/config.txt configured so it > > > ran at its 1920x1080 rated resolution. Looked good. Tried linuxcnc, > > > and darned if it didn't run normally once I had taken a pin > > > reference to a units pin back out. No biggie, that card didn't have > > > that module on it. > > > > > > So now I am wondering if the old, bastard 1366x768 rated monitor was > > > somehow grabbing a gpio pin and mucking things up by interfering > > > with the SPI buss. > > > > > > Am I on the right track, or barking at the moon? Discussion please. > > > > > > In the FWIW category, the 3 adapters I made, using the OSHPark 40 > > > pin to 26 pin board with the 3 88 ohm terminator resistors, which > > > because there were not any 88 ohm r's at digikey, so mine are 86.7 > > > ohms. None of them work at all. They all return: > > > > > > 00000000 00000000 00000000 00000000 when queried for the boards id. > > > > > > My home made cable is the only one that works, about 8" of overall > > > length. > > > > > > The very poor keyboard and mouse response continues unabated. This > > > is regardless of the cpu load. Reboot it. 3 out of 4 times that > > > will fix it for a while, 4th time its even worse. Misses key up > > > events, so it goes into the autorepeat until another key is tapped. > > > Hit backspace to get rid of the unwanted characters and the > > > backspace goes into autorepeat. nano or geany makes no difference. > > > Changing keyboards has no effect. > > > > > > I don't have the machine moving yet, when I decided to test ALL the > > > 7i90's I had, I ripped stuff off the 50 pin sockets w/o drawing a > > > map, so now I am tracing down each wire in turn, and plugging it > > > back into the 7i90 by looking up that items function in my .hal > > > files. That and because many weren't in a connector housing, and I > > > want to rectify that, I tried to glue up 2 and a half of the 2x10 > > > styles, but apparently the latest and greatest in super glues is not > > > up to butt gluing these things, it breaks VERY easily. Made more > > > difficult because there are not any Mesa 7i42TA's in the states and > > > I want to get three of them to serve as static voltage absorber's to > > > protect the ultra sensitive 7i90 outputs. Not to mention that it > > > will make the hookup buckets neater. > > > > > > And wasted the afternoon getting the 1st of a 3 shot series under my > > > left kneecap. And Dee, who watches the news, says we are supposed > > > to get around 2.5" additional rain over the next 2 days. I wish > > > humans could hibernate... Sometimes I try, but I still have recycle > > > the water. :) > > > > > > Cheers, Gene Heskett > > > -- > > > "There are four boxes to be used in defense of liberty: > > > soap, ballot, jury, and ammo. Please use in that order." > > > -Ed Howdershelt (Author) > > > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > > > > ------------------------------------------------------------ > > > ------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
