Martin Brown <'''newspam'''@nonad.co.uk> wrote:

> On 18/04/2022 12:45, Mike Monett wrote:

[...]

>> This happened suddenly. Can you write to the keyboard?
>
> I think a stuck key is a more likely fault and by several orders of
> magnitude.
I have had plenty of stuck keys. I tried to check by pressing all the keys to
see if one was stuck on or jammed. None were.

A fault with the Enter key is possible, but it would scroll the screen up.
This problem is completely different. The entire screen flashes then flashes
again. What key would do that?

--
MRM

On 24/04/2022 07:54, Mike Monett wrote:
> Martin Brown <'''newspam'''@nonad.co.uk> wrote:
>
>> On 18/04/2022 12:45, Mike Monett wrote:
>
> [...]
>
>>> This happened suddenly. Can you write to the keyboard?
>>
>> I think a stuck key is a more likely fault and by several orders of
>> magnitude.
>
> I have had plenty of stuck keys. I tried to check by pressing all the keys to
> see if one was stuck on or jammed. None were.
>
> A fault with the Enter key is possible, but it would scroll the screen up.
> This problem is completely different. The entire screen flashes then flashes
> again. What key would do that?

The "clear screen" key perhaps?

--
Regards,
Martin Brown

On 4/24/2022 1:25 AM, Martin Brown wrote:
> On 24/04/2022 07:54, Mike Monett wrote:
>> Martin Brown <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 18/04/2022 12:45, Mike Monett wrote:
>>
>> [...]
>>
>>>> This happened suddenly. Can you write to the keyboard?
>>>
>>> I think a stuck key is a more likely fault and by several orders of
>>> magnitude.
>> I have had plenty of stuck keys. I tried to check by pressing all the keys to
>> see if one was stuck on or jammed. None were.
>>
>> A fault with the Enter key is possible, but it would scroll the screen up.
>> This problem is completely different. The entire screen flashes then flashes
>> again. What key would do that?
>
> The "clear screen" key perhaps?

Or, a keyboard malfunctioning in a way that breaks its contract with the
BIOS (this is preboot, right?). Programmers are notoriously bad at imagining
how hardware can fail and coding defensively enough to protect their systems.

A behaving keyboard is a trivial design -- up, down, repeat. So, equally
trivial expectations of what that keyboard will deliver to the PC.

[I've got a keyboard that is often "not recognized" by it's PC -- until
Windows starts. I.e., none of the indicators illuminate (nor does the
ball-less mouse). This makes for some interesting conditions when you want
to interrupt the boot process beyond opting for an alternate boot device
(which the boot order will already handle)!]

Of course, one should be able to make the problem appear and disappear,
ON DEMAND, just by replugging the suspect keyboard. And, if the problem
did NOT reappear, that casts suspicion on whether or not the keyboard
*was* the source of the problem (and not a bad connection, noisy power,
"gremlins", etc.).

I had a disk drive *appear* to fail, recently. I pulled it. Recovered
its contents. Then, put it on my "sanitizer" -- to scrub it clean AND
give me an assessment of it's reliability (the sanitizer is intended to
"qualify" drives for reuse, purging them of their contents before that).
It passed with flying colors! It's back in the machine, waiting to see
if the machine misbehaves, again.

When I get a chance, I'll open the machine and check caps, supplies,
pull/reseat memory, processor, etc. But, after a ~week running 24/7,
it is still purring nicely!

Martin Brown <'''newspam'''@nonad.co.uk> wrote:

> On 24/04/2022 07:54, Mike Monett wrote:
>> Martin Brown <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 18/04/2022 12:45, Mike Monett wrote:
>>
>> [...]
>>
>>>> This happened suddenly. Can you write to the keyboard?
>>>
>>> I think a stuck key is a more likely fault and by several orders of
>>> magnitude.
>>
>> I have had plenty of stuck keys. I tried to check by pressing all the
>> keys to see if one was stuck on or jammed. None were.
>>
>> A fault with the Enter key is possible, but it would scroll the screen
>> up. This problem is completely different. The entire screen flashes
>> then flashes again. What key would do that?
>
> The "clear screen" key perhaps?

That appears to be a hidden key on the keyboard, although it appears in DOS
and all versions of windows starting with 95 as CLS. But it actually clears
the screen and only leaves a prompt.

--
MRM

On Mon, 18 Apr 2022 15:28:12 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 4/18/2022 3:07 PM, legg wrote:
>> Booted into power-off, then powered on into the OS log-in screen
>> and POWERED OFF AGAIN - within the count of a few chimpanzees.
>
>But the MB is known good?
>
>Did it seem to deliberately shut itself down? Or, just "die"
>(e.g., like a power supply shutting down due to load)?
>IIRC, the "4 second shutdown" is (was?) implemented in hardware;
>that can be a low-end figure for how long you might expect the
>system to stay up, at a minimum.
>
>Remove all loads (disks, PCI/PCIe/etc. cards). Remove *memory*.
>EXPECT it to complain about "no memory" when it boots. If this
>doesn't happen, then the fundamentals aren't working.
>
>[You can also pull the CPU and some MBs will signal an error
>based on that, as well]
>
>> Trying to figure out if a power button or harness failure can be
>> responsible. Surely those signals are processed up the wazoo after
>> they hit the motherboard - can't just shut it down cold?
>
>If it was at 4 seconds, you could hypothesize the power button
>was "stuck"/shorted/miswired (one problem I've seen with generic
>MBs is the sheer number of connections that have to be made...
>disk activity indicator, power button, reset (sometimes), pigtails
>to USB and serial ports, etc.
>
>> Vibration around the procesor? Processor itself ? (carried over
>> to replacement MB) Dirty processor socket?
>
>For the hell of it, try removing the processor to see if it alerts.
>Or, if the symptoms change.
>
>> Wouldn't be surprised if the new HDD is now toast.
>
>Unplug it for the time being. Easy to check that on another machine
>(I prefer a USB enclosure so the disk is isolated from the test machines
>power, SATA controller, etc.)

Well, it's not the processor (swapped out) or bios (reflashed).
Re-cycled PSU, in the off-chance that the new one was to blame,
but made no difference. Optical drive has failed in the meantime.
Rechecked harnessing. Reran memtest.

Am at point where I'm reinstalling OS fresh with each attempt.
Gets to the time zone and password settings, then shuts off
in the next process (of hardware enumeration?).

Time to shut it down for good.

RL

On 4/26/2022 5:12 PM, legg wrote:
> On Mon, 18 Apr 2022 15:28:12 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 4/18/2022 3:07 PM, legg wrote:
>>> Booted into power-off, then powered on into the OS log-in screen
>>> and POWERED OFF AGAIN - within the count of a few chimpanzees.
>>
>> But the MB is known good?
>>
>> Did it seem to deliberately shut itself down? Or, just "die"
>> (e.g., like a power supply shutting down due to load)?
>> IIRC, the "4 second shutdown" is (was?) implemented in hardware;
>> that can be a low-end figure for how long you might expect the
>> system to stay up, at a minimum.
>>
>> Remove all loads (disks, PCI/PCIe/etc. cards). Remove *memory*.
>> EXPECT it to complain about "no memory" when it boots. If this
>> doesn't happen, then the fundamentals aren't working.
>>
>> [You can also pull the CPU and some MBs will signal an error
>> based on that, as well]
>>
>>> Trying to figure out if a power button or harness failure can be
>>> responsible. Surely those signals are processed up the wazoo after
>>> they hit the motherboard - can't just shut it down cold?
>>
>> If it was at 4 seconds, you could hypothesize the power button
>> was "stuck"/shorted/miswired (one problem I've seen with generic
>> MBs is the sheer number of connections that have to be made...
>> disk activity indicator, power button, reset (sometimes), pigtails
>> to USB and serial ports, etc.
>>
>>> Vibration around the procesor? Processor itself ? (carried over
>>> to replacement MB) Dirty processor socket?
>>
>> For the hell of it, try removing the processor to see if it alerts.
>> Or, if the symptoms change.
>>
>>> Wouldn't be surprised if the new HDD is now toast.
>>
>> Unplug it for the time being. Easy to check that on another machine
>> (I prefer a USB enclosure so the disk is isolated from the test machines
>> power, SATA controller, etc.)
>
> Well, it's not the processor (swapped out) or bios (reflashed).
> Re-cycled PSU, in the off-chance that the new one was to blame,
> but made no difference. Optical drive has failed in the meantime.
> Rechecked harnessing. Reran memtest.

Could be a bad solder joint, broken trace, etc. Too much trouble
to chase down, definitively.

> Am at point where I'm reinstalling OS fresh with each attempt.
> Gets to the time zone and password settings, then shuts off
> in the next process (of hardware enumeration?).

Ah. If you'd been able to install it successfully *once*, then
taking an image would save you the trouble of going through MS's
painfully slow installer.

> Time to shut it down for good.

Yup. Take it out back and shoot it.

Nowadays, most machines aren't very expensive to replace. All
the real "value" is whatever YOU have added to the disk drive...

I've very little patience for tools that don't perform as expected.
Hardware is usually pretty easy to identify as faulty (swap out, try
a second instance, etc.). Software is a PITA as you tend to be
dependent on the supplier to fix bugs. And, most suppliers' process
is to just give you a NEWER set of bugs!

Moral: identify quirky behavior and discover ways to work around it
or compensate for it instead of perpetually replacing one known
behavior with a new yet-to-be-known behavior!

["Update? No thank you..."]

Take the opportunity to "treat yourself" :>

On Wednesday, 27 April 2022 at 10:33:13 UTC+1, Don Y wrote:
> On 4/26/2022 5:12 PM, legg wrote:
> > On Mon, 18 Apr 2022 15:28:12 -0700, Don Y
> > <blocked...@foo.invalid> wrote:
> >
> >> On 4/18/2022 3:07 PM, legg wrote:
> >>> Booted into power-off, then powered on into the OS log-in screen
> >>> and POWERED OFF AGAIN - within the count of a few chimpanzees.
> >>
> >> But the MB is known good?
> >>
> >> Did it seem to deliberately shut itself down? Or, just "die"
> >> (e.g., like a power supply shutting down due to load)?
> >> IIRC, the "4 second shutdown" is (was?) implemented in hardware;
> >> that can be a low-end figure for how long you might expect the
> >> system to stay up, at a minimum.
> >>
> >> Remove all loads (disks, PCI/PCIe/etc. cards). Remove *memory*.
> >> EXPECT it to complain about "no memory" when it boots. If this
> >> doesn't happen, then the fundamentals aren't working.
> >>
> >> [You can also pull the CPU and some MBs will signal an error
> >> based on that, as well]
> >>
> >>> Trying to figure out if a power button or harness failure can be
> >>> responsible. Surely those signals are processed up the wazoo after
> >>> they hit the motherboard - can't just shut it down cold?
> >>
> >> If it was at 4 seconds, you could hypothesize the power button
> >> was "stuck"/shorted/miswired (one problem I've seen with generic
> >> MBs is the sheer number of connections that have to be made...
> >> disk activity indicator, power button, reset (sometimes), pigtails
> >> to USB and serial ports, etc.
> >>
> >>> Vibration around the procesor? Processor itself ? (carried over
> >>> to replacement MB) Dirty processor socket?
> >>
> >> For the hell of it, try removing the processor to see if it alerts.
> >> Or, if the symptoms change.
> >>
> >>> Wouldn't be surprised if the new HDD is now toast.
> >>
> >> Unplug it for the time being. Easy to check that on another machine
> >> (I prefer a USB enclosure so the disk is isolated from the test machines
> >> power, SATA controller, etc.)
> >
> > Well, it's not the processor (swapped out) or bios (reflashed).
> > Re-cycled PSU, in the off-chance that the new one was to blame,
> > but made no difference. Optical drive has failed in the meantime.
> > Rechecked harnessing. Reran memtest.
> Could be a bad solder joint, broken trace, etc. Too much trouble
> to chase down, definitively.
> > Am at point where I'm reinstalling OS fresh with each attempt.
> > Gets to the time zone and password settings, then shuts off
> > in the next process (of hardware enumeration?).
> Ah. If you'd been able to install it successfully *once*, then
> taking an image would save you the trouble of going through MS's
> painfully slow installer.
> > Time to shut it down for good.
> Yup. Take it out back and shoot it.
>
> Nowadays, most machines aren't very expensive to replace. All
> the real "value" is whatever YOU have added to the disk drive...
>
> I've very little patience for tools that don't perform as expected.
> Hardware is usually pretty easy to identify as faulty (swap out, try
> a second instance, etc.). Software is a PITA as you tend to be
> dependent on the supplier to fix bugs. And, most suppliers' process
> is to just give you a NEWER set of bugs!
>
> Moral: identify quirky behavior and discover ways to work around it
> or compensate for it instead of perpetually replacing one known
> behavior with a new yet-to-be-known behavior!
>
> ["Update? No thank you..."]
>
> Take the opportunity to "treat yourself" :>

One of the weirdest hardware oddities is an industrial motherboard
(with soldered in cpu) that appears to work fine with Windows but will
not complete the installation process for Linux (I tried several varieties).
Its definitely not the memory or power supply or BIOS version or settings
(or the keyboard).
Needless to say I don't trust it running Windows either so its on my
scrap pile. I have another one, bought at the same time and configured
identically, which works fine with both.
John

On 4/27/2022 2:57 AM, John Walliker wrote:
> One of the weirdest hardware oddities is an industrial motherboard
> (with soldered in cpu) that appears to work fine with Windows but will
> not complete the installation process for Linux (I tried several varieties).
> Its definitely not the memory or power supply or BIOS version or settings
> (or the keyboard).

Windows tries very hard NOT to complain about hardware. I guess the
thinking is that the user wouldn't be able to do much *if* it complained.
And, would likely see *windows* as The Problem.

Often, the only way to expose a hardware problem, in Windows, is to
go *looking* for it (logs, etc.). Even "failures" tend to be "polite"
(write error; your data is lost!)

OTOH, my UN*X boxen tend to complain, more, when they encounter
odd situations (like an intermittent SCSI cable). I suspect the
folks coding them weren't as tolerant of "unexpected events".

> Needless to say I don't trust it running Windows either so its on my
> scrap pile. I have another one, bought at the same time and configured
> identically, which works fine with both.

Yeah, if you've *seen* it screwup, how can you rationalize ignoring
that fact?

I've got an AiO that I use as a "console" to talk to my archive/repository.
It misbehaved, recently. Suspecting a failing disk, I replaced that.
But, then determined the original disk to be functioning properly
(so, the problem lies elsewhere!)

OTOH, as it is simply taking typed commands and passing them along
to another node on the network, it is very unlikely that it will
"silently" corrupt some of my SQL in a way that the other node
won't detect as incorrect. And, simultaneously corrupt the
reply from that node in such a way that I won't consider it
suspect!

(i.e., if it screws up, again, I'll be there to witness it!)

I've always shuddered when I hear folks overclocking machines
or using recapped motherboards; how do you know the system is
really working as intended, now? If you rendered a 3D object,
would you be able to tell if it messed up one of 100,000 polygons?
Two? Five hundred??

On Wednesday, 27 April 2022 at 11:31:52 UTC+1, Don Y wrote:
> On 4/27/2022 2:57 AM, John Walliker wrote:
> I've always shuddered when I hear folks overclocking machines
> or using recapped motherboards; how do you know the system is
> really working as intended, now? If you rendered a 3D object,
> would you be able to tell if it messed up one of 100,000 polygons?
> Two? Five hundred??

I once had a PC/AT clone motherboard where the supplier had changed the
main clock oscillator for a faster one. It worked fine for nearly everything,
but a multi-channel audio acquisition board I had designed did not work
properly. It turned out that the setup and hold times were completely
wrong on the DMA channels so my hardware failed. After I replaced the
oscillator with one having the correct frequency everything was fine again.
In contrast, I once needed to use a TMS320C51 DSP at a combination of
power supply voltage and clock frequency that was not allowed in the data
sheet rules, but which looked as if it should work reliably. It was a medical
application. In those days, TI had good technical support in the UK and I was
given some test code which exercised the critical timing paths that were known
to be the most likely to fail under voltage or frequency stress conditions.
This was built into the power-on startup code, so each device was known to be
happy with its operating conditions at that point.

John

On Wed, 27 Apr 2022 02:32:56 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 4/26/2022 5:12 PM, legg wrote:
>> On Mon, 18 Apr 2022 15:28:12 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>>
>>> On 4/18/2022 3:07 PM, legg wrote:
>>>> Booted into power-off, then powered on into the OS log-in screen
>>>> and POWERED OFF AGAIN - within the count of a few chimpanzees.
>>>
>>> But the MB is known good?
>>>
>>> Did it seem to deliberately shut itself down? Or, just "die"
>>> (e.g., like a power supply shutting down due to load)?
>>> IIRC, the "4 second shutdown" is (was?) implemented in hardware;
>>> that can be a low-end figure for how long you might expect the
>>> system to stay up, at a minimum.
>>>
>>> Remove all loads (disks, PCI/PCIe/etc. cards). Remove *memory*.
>>> EXPECT it to complain about "no memory" when it boots. If this
>>> doesn't happen, then the fundamentals aren't working.
>>>
>>> [You can also pull the CPU and some MBs will signal an error
>>> based on that, as well]
>>>
>>>> Trying to figure out if a power button or harness failure can be
>>>> responsible. Surely those signals are processed up the wazoo after
>>>> they hit the motherboard - can't just shut it down cold?
>>>
>>> If it was at 4 seconds, you could hypothesize the power button
>>> was "stuck"/shorted/miswired (one problem I've seen with generic
>>> MBs is the sheer number of connections that have to be made...
>>> disk activity indicator, power button, reset (sometimes), pigtails
>>> to USB and serial ports, etc.
>>>
>>>> Vibration around the procesor? Processor itself ? (carried over
>>>> to replacement MB) Dirty processor socket?
>>>
>>> For the hell of it, try removing the processor to see if it alerts.
>>> Or, if the symptoms change.
>>>
>>>> Wouldn't be surprised if the new HDD is now toast.
>>>
>>> Unplug it for the time being. Easy to check that on another machine
>>> (I prefer a USB enclosure so the disk is isolated from the test machines
>>> power, SATA controller, etc.)
>>
>> Well, it's not the processor (swapped out) or bios (reflashed).
>> Re-cycled PSU, in the off-chance that the new one was to blame,
>> but made no difference. Optical drive has failed in the meantime.
>> Rechecked harnessing. Reran memtest.
>
>Could be a bad solder joint, broken trace, etc. Too much trouble
>to chase down, definitively.
>
>> Am at point where I'm reinstalling OS fresh with each attempt.
>> Gets to the time zone and password settings, then shuts off
>> in the next process (of hardware enumeration?).
>
>Ah. If you'd been able to install it successfully *once*, then
>taking an image would save you the trouble of going through MS's
>painfully slow installer.
>
>> Time to shut it down for good.
>
>Yup. Take it out back and shoot it.
>
>Nowadays, most machines aren't very expensive to replace. All
>the real "value" is whatever YOU have added to the disk drive...
>
Just trying to get it safe enough to stick a system HDD into it.
It already ate one. The back-up will not work in new hardware,
but I guess there's no choice. In cat years, it's no spring
chicken. The LXLE dual-boot was intended to nurse the thing
into it's golden years . . .was just teaching LXLE to print.
Brings a tear to the eye.

A HDD is a place to stick your data, until it 'goes'. HDD rel
has seemed to improve for me, particularly since the adoption
of SATA. Sticking a reliable HDD into junk doesn't raise the
reliability of the junk.
A lot of things are built on crumbly foundations these days.

RL

On 4/27/2022 4:53 AM, John Walliker wrote:
> On Wednesday, 27 April 2022 at 11:31:52 UTC+1, Don Y wrote:
>> On 4/27/2022 2:57 AM, John Walliker wrote:
>
>> I've always shuddered when I hear folks overclocking machines
>> or using recapped motherboards; how do you know the system is
>> really working as intended, now? If you rendered a 3D object,
>> would you be able to tell if it messed up one of 100,000 polygons?
>> Two? Five hundred??
>
> I once had a PC/AT clone motherboard where the supplier had changed the
> main clock oscillator for a faster one. It worked fine for nearly everything,
> but a multi-channel audio acquisition board I had designed did not work
> properly. It turned out that the setup and hold times were completely
> wrong on the DMA channels so my hardware failed.

Be thankful it was a hard/observable failure! Imagine if it had been
intermittent -- plaguing your product "in the field"!

> After I replaced the
> oscillator with one having the correct frequency everything was fine again.
> In contrast, I once needed to use a TMS320C51 DSP at a combination of
> power supply voltage and clock frequency that was not allowed in the data
> sheet rules, but which looked as if it should work reliably. It was a medical
> application. In those days, TI had good technical support in the UK and I was
> given some test code which exercised the critical timing paths that were known
> to be the most likely to fail under voltage or frequency stress conditions.
> This was built into the power-on startup code, so each device was known to be
> happy with its operating conditions at that point.

You've more guts than I. I like being able to point to a document and
prove that my design is 100% compliant so any "problems" lie in the components
being used. (regardless of temperature, power supply noise, etc.)

I like to dick with RESET on processors as it often lets me implement
special features cheaply. But, RESET is often a poorly defined event.
I can empirically verify that a particular design MIGHT work... but, have
no guarantee that some mask revision won't break my solution.

Give me something that I can hang my hat on to justify to boss/client/customer
that my approach has addressed due diligence... or, I'll look for another,
better documented device -- or approach.

On 4/27/2022 7:35 AM, legg wrote:
>> Nowadays, most machines aren't very expensive to replace. All
>> the real "value" is whatever YOU have added to the disk drive...
>>
> Just trying to get it safe enough to stick a system HDD into it.

What is your goal AFTER that? Are you trying to recover data from
some OTHER drive present in the system? Or, are you hoping to
actually USE the system once the system drive is installed?

I keep external USB drive enclosures (and/or "docks") on hand
to let me "mount" a drive on some other system -- without
worrying about how the drive will dick with the hardware *in*
that system. If the drive has a problem, then the DRIVE has a
problem, not the system that I'm using to examine it.

> It already ate one. The back-up will not work in new hardware,

PATA vs SATA? (hence the value of keeping external USB drives
around as "test fixtures")

> but I guess there's no choice. In cat years, it's no spring
> chicken. The LXLE dual-boot was intended to nurse the thing
> into it's golden years . . .was just teaching LXLE to print.
> Brings a tear to the eye.
>
> A HDD is a place to stick your data, until it 'goes'. HDD rel
> has seemed to improve for me, particularly since the adoption
> of SATA.

I still have small (megabyte!) IDE disks that power some of my
older (collectable) kit. But, the total PoHr stays low because
they don't see much use. And, as they are so small, it is easy to
keep an image of the entire system around -- on something
as small as a CD-ROM! <frown>

Newer drives (in my workstations) tend to run 24/7/365 so I'm
potentially at more risk. But, most of the content on my
machines is "applications" and "libraries" (of sorts). Which
can be restored from their originals, if need be.

> Sticking a reliable HDD into junk doesn't raise the
> reliability of the junk.

Consider moving the media into a NAS or SAN? The advantage being
that you can share the media "for free".

> A lot of things are built on crumbly foundations these days.

People want features, not reliability.

And, developers often find improving reliability/robustness to
be "interesting" -- compared to starting off in some NEW direction
(on a new, half-baked feature).

My solution has been to "settle" for something known. And, then
replicate it so I'm not reliant on a single unit.

On Wed, 27 Apr 2022 13:18:24 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 4/27/2022 7:35 AM, legg wrote:
>>> Nowadays, most machines aren't very expensive to replace. All
>>> the real "value" is whatever YOU have added to the disk drive...
>>>
>> Just trying to get it safe enough to stick a system HDD into it.
>
>What is your goal AFTER that? Are you trying to recover data from
>some OTHER drive present in the system? Or, are you hoping to
>actually USE the system once the system drive is installed?
>
>I keep external USB drive enclosures (and/or "docks") on hand
>to let me "mount" a drive on some other system -- without
>worrying about how the drive will dick with the hardware *in*
>that system. If the drive has a problem, then the DRIVE has a
>problem, not the system that I'm using to examine it.
>
>> It already ate one. The back-up will not work in new hardware,
>
>PATA vs SATA? (hence the value of keeping external USB drives
>around as "test fixtures")
>
>> but I guess there's no choice. In cat years, it's no spring
>> chicken. The LXLE dual-boot was intended to nurse the thing
>> into it's golden years . . .was just teaching LXLE to print.
>> Brings a tear to the eye.
>>
>> A HDD is a place to stick your data, until it 'goes'. HDD rel
>> has seemed to improve for me, particularly since the adoption
>> of SATA.
>
>I still have small (megabyte!) IDE disks that power some of my
>older (collectable) kit. But, the total PoHr stays low because
>they don't see much use. And, as they are so small, it is easy to
>keep an image of the entire system around -- on something
>as small as a CD-ROM! <frown>
>

I'm developing an aversion to attempting an LXLE dual boot system
(with an MS OS). I'm looking at my HDD morgue and now see 4 dead
HDD associated with such an endeavor.

Two were in Dell refurbs - now both still running with non-dual
boot clones (WXP)in 2020, The other two are from this attempt
in the PC Chips A13G+ v3.0 home-brew (W2K). This is now officially
junk.

There are only two things in common; LXLE and me.

A Ubuntu single or dual boot (it doesn't seem to care -
on separate hard drives) is still in progress.

Meanwhile, other obligations call.

RL

On 4/28/2022 11:01 AM, legg wrote:
> I'm developing an aversion to attempting an LXLE dual boot system
> (with an MS OS). I'm looking at my HDD morgue and now see 4 dead
> HDD associated with such an endeavor.

I'm having a hard time thinking that they are truly *dead* (as in
"scrap"). Have you tried:
dd if=/dev/zero of=/dev/r<drivedevice> bs=1024k count=100
just to ensure there's no cruft on it -- esp the boot/MBR area?

> Two were in Dell refurbs - now both still running with non-dual
> boot clones (WXP)in 2020, The other two are from this attempt
> in the PC Chips A13G+ v3.0 home-brew (W2K). This is now officially
> junk.
>
> There are only two things in common; LXLE and me.
>
> A Ubuntu single or dual boot (it doesn't seem to care -
> on separate hard drives) is still in progress.

I used to run a "quad boot" tower -- {Net,Open,Free}BSD
(not a fan of Linux, nor its license!) plus Windows -- when
I was writing drivers. Back then, a 4G drive was $1K so
it was easier to put 4 of them in a box than to try to
share a single drive.

Now, I have a clean demarcation between boxes. It's a
Windows box or a Sun box or a *BSD box... but never more
than one.

You might consider running your non-windows boxen headless
and installing an X server *under* Windows. Or, a bunch of
VMs. I run an ESXi server for my VMs -- so any workstation
can run any VM, served over the wire. Or, copy the VMDK onto
the host and run it locally if A/V performance is an issue.
(my VMs are on a big SAN)

Bottom line: figure out how to REDUCE your sysadmin tasks
and the time wasted on them.

> Meanwhile, other obligations call.

Always! It's a wonder we get ANYTHING done!

Don Y <blockedofcourse@foo.invalid> wrote:
> On 4/28/2022 11:01 AM, legg wrote:
>> I'm developing an aversion to attempting an LXLE dual boot system
>> (with an MS OS). I'm looking at my HDD morgue and now see 4 dead
>> HDD associated with such an endeavor.
>
> I'm having a hard time thinking that they are truly *dead* (as in
> "scrap"). Have you tried:
> dd if=/dev/zero of=/dev/r<drivedevice> bs=1024k count=100
> just to ensure there's no cruft on it -- esp the boot/MBR area?
>
>> Two were in Dell refurbs - now both still running with non-dual
>> boot clones (WXP)in 2020, The other two are from this attempt
>> in the PC Chips A13G+ v3.0 home-brew (W2K). This is now officially
>> junk.
>>
>> There are only two things in common; LXLE and me.
>>
>> A Ubuntu single or dual boot (it doesn't seem to care -
>> on separate hard drives) is still in progress.
>
> I used to run a "quad boot" tower -- {Net,Open,Free}BSD
> (not a fan of Linux, nor its license!) plus Windows -- when
> I was writing drivers. Back then, a 4G drive was $1K so
> it was easier to put 4 of them in a box than to try to
> share a single drive.
>
> Now, I have a clean demarcation between boxes. It's a
> Windows box or a Sun box or a *BSD box... but never more
> than one.
>
> You might consider running your non-windows boxen headless
> and installing an X server *under* Windows. Or, a bunch of

No, don't run X. X is garbage, always has been, always will be.

> VMs. I run an ESXi server for my VMs -- so any workstation
> can run any VM, served over the wire. Or, copy the VMDK onto
> the host and run it locally if A/V performance is an issue.
> (my VMs are on a big SAN)

Lol, this clown has a "big SAN", but can't quite tackle NTP yet.

> Bottom line: figure out how to REDUCE your sysadmin tasks
> and the time wasted on them.

Say the guy running a "sun box", which is likely some 22 year old piece of
shit with no networking enabled.

On Wednesday, 27 April 2022 at 20:33:52 UTC+1, Don Y wrote:
> On 4/27/2022 4:53 AM, John Walliker wrote:

> > In contrast, I once needed to use a TMS320C51 DSP at a combination of
> > power supply voltage and clock frequency that was not allowed in the data
> > sheet rules, but which looked as if it should work reliably. It was a medical
> > application. In those days, TI had good technical support in the UK and I was
> > given some test code which exercised the critical timing paths that were known
> > to be the most likely to fail under voltage or frequency stress conditions.
> > This was built into the power-on startup code, so each device was known to be
> > happy with its operating conditions at that point.
> You've more guts than I. I like being able to point to a document and
> prove that my design is 100% compliant so any "problems" lie in the components
> being used. (regardless of temperature, power supply noise, etc.)

This was a research project with less than 100 units being made and they were
all under our control. There was no alternative device at that time that met our
other constraints, so the choice was to make the best of what we had or do nothing.
The fundamental problem was that TI had specified maximum clock frequencies
at a couple of different supply voltages. We needed to operate at an intermediate
voltage and intermediate clock frequency. The code was the same as TI used
for production testing, so I don't think it was particularly risky - quite the opposite.
....
> Give me something that I can hang my hat on to justify to boss/client/customer
> that my approach has addressed due diligence... or, I'll look for another,
> better documented device -- or approach.

In an ideal world, yes, definitely.

John

On Thu, 28 Apr 2022 18:51:09 -0000 (UTC), Cydrome Leader
<presence@MUNGEpanix.com> wrote:

>Don Y <blockedofcourse@foo.invalid> wrote:
>> On 4/28/2022 11:01 AM, legg wrote:
>>> I'm developing an aversion to attempting an LXLE dual boot system
>>> (with an MS OS). I'm looking at my HDD morgue and now see 4 dead
>>> HDD associated with such an endeavor.
>>
>> I'm having a hard time thinking that they are truly *dead* (as in
>> "scrap"). Have you tried:
>> dd if=/dev/zero of=/dev/r<drivedevice> bs=1024k count=100
>> just to ensure there's no cruft on it -- esp the boot/MBR area?
>>
>>> Two were in Dell refurbs - now both still running with non-dual
>>> boot clones (WXP)in 2020, The other two are from this attempt
>>> in the PC Chips A13G+ v3.0 home-brew (W2K). This is now officially
>>> junk.
>>>
>>> There are only two things in common; LXLE and me.
>>>
>>> A Ubuntu single or dual boot (it doesn't seem to care -
>>> on separate hard drives) is still in progress.
>>
>> I used to run a "quad boot" tower -- {Net,Open,Free}BSD
>> (not a fan of Linux, nor its license!) plus Windows -- when
>> I was writing drivers. Back then, a 4G drive was $1K so
>> it was easier to put 4 of them in a box than to try to
>> share a single drive.
>>
>> Now, I have a clean demarcation between boxes. It's a
>> Windows box or a Sun box or a *BSD box... but never more
>> than one.
>>
>> You might consider running your non-windows boxen headless
>> and installing an X server *under* Windows. Or, a bunch of
>
>No, don't run X. X is garbage, always has been, always will be.
>
>> VMs. I run an ESXi server for my VMs -- so any workstation
>> can run any VM, served over the wire. Or, copy the VMDK onto
>> the host and run it locally if A/V performance is an issue.
>> (my VMs are on a big SAN)
>
>Lol, this clown has a "big SAN", but can't quite tackle NTP yet.
>
>> Bottom line: figure out how to REDUCE your sysadmin tasks
>> and the time wasted on them.
>
>Say the guy running a "sun box", which is likely some 22 year old piece of
>shit with no networking enabled.
>

I have not been following this thread very closely, but I will add one
details: The source code for NTP is publicly available at NTP.org, is
about 70,000 lines of plain C code, and have become a bit convoluted
over the years. It would take a solid year to become reasonable
familiar with that bit of code.

Joe Gwinn

On 4/29/2022 10:04 AM, John Walliker wrote:
> On Wednesday, 27 April 2022 at 20:33:52 UTC+1, Don Y wrote:
>> On 4/27/2022 4:53 AM, John Walliker wrote:
>
>> You've more guts than I. I like being able to point to a document and
>> prove that my design is 100% compliant so any "problems" lie in the components
>> being used. (regardless of temperature, power supply noise, etc.)
>
> This was a research project with less than 100 units being made and they were
> all under our control. There was no alternative device at that time that met our
> other constraints, so the choice was to make the best of what we had or do nothing.

Ah. I often have had to make "proof of concept" prototypes -- but, the
approach that I took had to be able to move into manufacturing without
significant redesign. So, I had to be able to defend the design as
ready for manufacturing.

Other designs were intended for manufacture so not a good strategy to
"hope" for something that isn't published (my contracts provide "free"
fixes, indefinitely -- but, only for things that I have control over!)

> The fundamental problem was that TI had specified maximum clock frequencies
> at a couple of different supply voltages. We needed to operate at an intermediate
> voltage and intermediate clock frequency. The code was the same as TI used
> for production testing, so I don't think it was particularly risky - quite the opposite.

OK, so you just wanted another point on an already bounded curve.
You weren't trying to look beyond the horizon...

>> Give me something that I can hang my hat on to justify to boss/client/customer
>> that my approach has addressed due diligence... or, I'll look for another,
>> better documented device -- or approach.
>
> In an ideal world, yes, definitely.

It needn't be an "ideal" world -- just one in which I am comfortable dotting
i's and crossing t's. Warts are fine -- as long as they are visible and
acknowledged.

Joe Gwinn <joegwinn@comcast.net> wrote:
> On Thu, 28 Apr 2022 18:51:09 -0000 (UTC), Cydrome Leader
> <presence@MUNGEpanix.com> wrote:
>
>>Don Y <blockedofcourse@foo.invalid> wrote:
>>> On 4/28/2022 11:01 AM, legg wrote:
>>>> I'm developing an aversion to attempting an LXLE dual boot system
>>>> (with an MS OS). I'm looking at my HDD morgue and now see 4 dead
>>>> HDD associated with such an endeavor.
>>>
>>> I'm having a hard time thinking that they are truly *dead* (as in
>>> "scrap"). Have you tried:
>>> dd if=/dev/zero of=/dev/r<drivedevice> bs=1024k count=100
>>> just to ensure there's no cruft on it -- esp the boot/MBR area?
>>>
>>>> Two were in Dell refurbs - now both still running with non-dual
>>>> boot clones (WXP)in 2020, The other two are from this attempt
>>>> in the PC Chips A13G+ v3.0 home-brew (W2K). This is now officially
>>>> junk.
>>>>
>>>> There are only two things in common; LXLE and me.
>>>>
>>>> A Ubuntu single or dual boot (it doesn't seem to care -
>>>> on separate hard drives) is still in progress.
>>>
>>> I used to run a "quad boot" tower -- {Net,Open,Free}BSD
>>> (not a fan of Linux, nor its license!) plus Windows -- when
>>> I was writing drivers. Back then, a 4G drive was $1K so
>>> it was easier to put 4 of them in a box than to try to
>>> share a single drive.
>>>
>>> Now, I have a clean demarcation between boxes. It's a
>>> Windows box or a Sun box or a *BSD box... but never more
>>> than one.
>>>
>>> You might consider running your non-windows boxen headless
>>> and installing an X server *under* Windows. Or, a bunch of
>>
>>No, don't run X. X is garbage, always has been, always will be.
>>
>>> VMs. I run an ESXi server for my VMs -- so any workstation
>>> can run any VM, served over the wire. Or, copy the VMDK onto
>>> the host and run it locally if A/V performance is an issue.
>>> (my VMs are on a big SAN)
>>
>>Lol, this clown has a "big SAN", but can't quite tackle NTP yet.
>>
>>> Bottom line: figure out how to REDUCE your sysadmin tasks
>>> and the time wasted on them.
>>
>>Say the guy running a "sun box", which is likely some 22 year old piece of
>>shit with no networking enabled.
>>
>
> I have not been following this thread very closely, but I will add one
> details: The source code for NTP is publicly available at NTP.org, is
> about 70,000 lines of plain C code, and have become a bit convoluted
> over the years. It would take a solid year to become reasonable
> familiar with that bit of code.
>
> Joe Gwinn

You're using forte agent for your post. How many lines of code is it? Are
you able to use the program without reading all the code?