It wasn't memory. Or at least nothing obvious. I ran Memtest86+ 5.01 in SMP mode for 3 full passes (about 10 hours) with no errors.
On reflection, it didn't seem likely to be a kernel freeze anyway. It wasn't that the light on the keyboard was unresponsive, or not just that, but that all the lights were off including the mouse laser. The sort of general "on" light in the tower was on, and the power supply fan was going, but that's all. I now wish I had looked at the motherboard readouts. Anyway, that suggested a power distribution or power supply problem to me. I just don't know how to bifurcate between the power supply and something on the mobo USB interface. And it hasn't happened again. On Wed, Dec 7, 2016 at 5:18 PM, Kevin O'Gorman <kevinogorm...@gmail.com> wrote: > Good feedback. I haven't done a memory check on that machine in a > while.... > > Next on my list. > > On Sun, Dec 4, 2016 at 11:25 AM, Keith Medcalf <kmedc...@dessus.com> > wrote: > >> >> 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 >> > > > > -- > #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
