If pressing the CAPS LOCK or NUM LOCK keys on the keyboard does not toggle the light on the keyboard then you have lost the all interrupt processing since those keypresses have to be processed by the kernel mode keyboard driver toggling the internal state of the keyboard driver, and then the kernel driver sends output to the keyboard to change the status LEDs. Typically (all Operating Systems) this means you have suffered a complete kernel crash (or halt) and the system is not running.
Since the system must be running in order to output indicator status, all indicators will stay "stuck" in their last known position (hold output). Only a power-cycle (or hardware reset -- assuming the RESET is a hardware reset and not just a request to reset which will be ignored) triggering a reboot will restart the system. The most frequent cause is a Parity Check. Or in these latter days of not having ECC or even Parity checked memory, just an undetected memory fault which will cause random AHTBL. > -----Original Message----- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > On Behalf Of Kevin O'Gorman > Sent: Sunday, 4 December, 2016 09:21 > To: SQLite mailing list > Subject: Re: [sqlite] I keep getting seg faults building my database using > python sqlite3 > > Well, the i7 system failed again, but this time it was quite different. > And peculiar. > The system wasn't doing anything, but it should have been. So I tried > something. It didn't matter what, because I could not get the mouse or > keyboard to work -- it was like they weren't plugged in. Really like it, > because the caps lock light wasn't on, nor was the laser light visible in > the mouse. Even when I changed mouse, keyboard and USB slot. I couldn't > get in with SSH from elsewhere either. But the computer's "I'm running" > light was on. > So I'm suspecting a partial power failure. I don't know enough about > mobos > and USB to diagnose whether the problem was on the mobo or the power > supply. > > Creepty. I had to do a hard reset to get thing going again, and it's > been > running fine for a day now. > > On Mon, Nov 21, 2016 at 9:51 AM, Kevin O'Gorman <kevinogorm...@gmail.com> > wrote: > > > On Mon, Nov 21, 2016 at 9:41 AM, Roger Binns <rog...@rogerbinns.com> > > wrote: > > > >> On 19/11/16 08:08, Kevin O'Gorman wrote: > >> > System with problems: Running Xubuntu Linux 16.04.1, Python 3.5.2. > >> [...] > >> > System without this problem: Running Ubuntu Linux 14.04.5, Python > 3.4.3. > >> > >> You are good on Python versions then. My remaining recommendation is > to > >> make the process that does SQLite be a child process (ie no making its > >> own children). That will eliminate an entire class of potential > >> problems, although it appears unlikely you are experiencing any of > them. > >> > >> The final option is to run the process under valgrind. That will > >> definitively show the cause. Do note however that you may want to > >> change some of the default options since you have nice big systems. > For > >> example I like to set --freelist-vol and related to very big numbers > >> (several gigabytes) which ensures that freed memory is not reused for a > >> long time. You could also set the valgrind option so that only one > >> thread is allowed - it will catch inadvertent threading you may note be > >> aware of. > >> > >> Roger > >> > > > > Thanks for that. I may do the valgrind thing -- it sounds useful. But > > just to add > > to my annoyance about this whole things, I've been having both systems > > running > > for a couple of days now with no problems or interruptions. Remember, > the > > i7 system was failing after 2 hours at most. I did tweak the code a > > little, but > > the only thing that seems likely to have stopped the problem is that I > put > > in > > code to do a commit after every 10,000 INSERT statements. The two > systems > > are running identical Python code on the same inputs. I had intended > this > > to > > verify that one fails and the other does not. What I got is something > > different, > > but on balance I like it best when my processes do not fail out. Maybe > > this > > time the code will finish (at this rate it will be at least a week, > maybe > > three. > > > > -- > > #define QUESTION ((bb) || (!bb)) /* Shakespeare */ > > > > > > -- > #define QUESTION ((bb) || (!bb)) /* Shakespeare */ > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
