@MSGID: 1@dont-email.me> 688dcf1b
@REPLY: <op.2a91pirva3w0dxdave@hodgins.homeip.net>
8f5d448d
@REPLYADDR The Natural Philosopher
<tnp@invalid.invalid>
@REPLYTO 2:5075/128 The Natural Philosopher
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
<ygamsxoixhx.fsf@akutech.de> 4@dont-email.me> <op.2a9vj3yca3w0dxdave@hodgins.homeip.net>
2@dont-email.me> <op.2a9yq7lva3w0dxdave@hodgins.homeip.net> 6@dont-email.me>
<op.2a91pirva3w0dxdave@hodgins.homeip.net>
@TZUTC: 0100
@PID: Mozilla/5.0 (X11; Linux x86_64; rv:102.0)
Gecko/20100101 Thunderbird/102.15.1
@TID: FIDOGATE-5.12-ge4e8b94
On 14/09/2023 20:57, David W. Hodgins wrote:
> On Thu, 14 Sep 2023 14:57:36 -0400, The Natural Philosopher 
> <tnp@invalid.invalid> wrote:
> 
>> On 14/09/2023 19:53, David W. Hodgins wrote:
>>> journalctl -b --no-h|grep fsck
>>
>> Sep 14 14:17:03 systemd[1]: Created slice system-systemd-fsck.slice.
>> Sep 14 14:17:03 systemd[1]: Listening on fsck to fsckd communication 
>> Socket.
>> Sep 14 14:17:04 systemd-fsck[109]: e2fsck 1.46.2 (28-Feb-2021)
>> Sep 14 14:17:04 systemd-fsck[109]: rootfs: clean, 51075/932256 files,
>> 460111/3822976 blocks
>> Sep 14 14:17:14 systemd-fsck[178]: fsck.fat 4.2 (2021-01-31)
>> Sep 14 14:17:14 systemd-fsck[178]: There are differences between boot
>> sector and its backup.
>> Sep 14 14:17:14 systemd-fsck[178]: This is mostly harmless. Differences:
>> (offset:original/backup)
>> Sep 14 14:17:14 systemd-fsck[178]:   65:01/00
>> Sep 14 14:17:14 systemd-fsck[178]:   Not automatically fixing this.
>> Sep 14 14:17:14 systemd-fsck[178]: Dirty bit is set. Fs was not properly
>> unmounted and some data may be corrupt.
>> Sep 14 14:17:14 systemd-fsck[178]:  Automatically removing dirty bit.
>> Sep 14 14:17:14 systemd-fsck[178]: *** Filesystem was changed ***
>> Sep 14 14:17:14 systemd-fsck[178]: Writing changes.
>> Sep 14 14:17:14 systemd-fsck[178]: /dev/mmcblk0p1: 330 files,
>> 25815/130554 clusters
>> Sep 14 14:30:12 systemd[1]: systemd-fsckd.service: Succeeded.
> 
> If there are any corrupted files, diagnosing any problems they cause 
> will be
> difficult. I strongly recommend re-installing.
> 
> Regards, Dave Hodgins

If it persists I may do that, but now it is been rock steady for 20 hours.

The actual code has been replaced because I recompiled it anyway, but 
the problem persisted after that.

Then I twisted the board a bit, and now it hasn`t failed since, No 
guarantees of course.

Does anyone else remember Tracy Kidder`s `Soul of a New Machine`* where 
they had a wire wrapped backplane on the prototype and a strange 
intermittent bug? And the director came in, twisted the backplane and 
the bug instantly reappeared?

One of the more curious `bugs` I encountered was early in my software 
career, when code that I wrote suddenly went crazy, in a way in which 
the actual software as written could not possibly have caused. And only 
on one machine, equipped with a custom video capture card. We removed 
the card, but it made no difference.

I then compared the code on the machine with the code as compiled.  Two 
bytes were FFH

I burned a new floppy and transferred the code again, and the code ran 
correctly.

Then we reinstalled the video card. The code ran correctly. Then we 
copied over the code again with the video card installed. The code again 
was corrupted.

Then the hardware guys looked at the address decide in the video card. 
It was a mass of gates one after the other. The total delay was well out 
of spec. It dawned on us that what was happening was that the DMA 
controller on the floppy was using bus addresses that were being decoded 
by the card, and then the IO request came along to access the floppy and 
those addresses were still on the bus as far as the sluglike video card 
was concerned, so it grabbed the data bus and shoved FFH on it.

Hardware is not perfect. That is the lesson. And chasing software when 
its really hardware is a losing game.

Anyway, I have in reserve all the great techniques suggested, but for 
now I am playing a wait and see game to see if any pattern emerges. My 
experience suggests that the same code running a loop in the same memory 
wont crash and burn unless there is a malloc/free mismatch, and that 
happens fairly quickly and shows in `top`.

This kind of weird utterly asynchronous behaviour is often hardware.
And. since I trod on the bloody PCB, I may simple get another one and 
test that. It doesn`t need to be installed till winter. There is time. 
And my PCB design for the relay and PSU module isn`t back from China yet...


*https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine . Definitely 
recommended if you haven`t read it.



-- 
"When one man dies it`s a tragedy. When thousands die it`s statistics."

Josef Stalin


 --- Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
 * Origin: A little, after lunch (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441