When using the system does it seem to be slower than it use to be when the hard drive is being accessed? My guess is from a cold start the system does more checks, then what it does from a reboot, before accessing the drive, giving it time to speed back up.
My other thought earlier was a video card problem.

1 members found this post helpful.

That's a good description of the internal sound that I heard last night. I need to read your links to see under what conditions this happens. As I said above, the audible buzz seems to occur when the cpu is not busy.

1 members found this post helpful.

No idea! I doubt if I would notice. It does take a long while to do the monthly system dumps but I haven't been timing them so I couldn't tell you if they have slowed up recently. Would it help if, after the next dump, I told you the time taken and the size of the dump file?
No. it's definitely not video. The video part of the boot looks completely normal.

No, I don’t have anything to compare it to. Maybe someone will chime in that had this happen on a system.

It just started buzzing again. I put my hand on the casing to stop the buzz, then listened carefully for noise coming from inside. And I heard it again quite clearly: a quiet hiss like the noise from my immersion heater. Once more this has happened when nothing much else was going on. Mind you, there's nothing going on during a stalled boot either, so maybe that is why I got this coil whine last night. It doesn't necessarily mean that the two things are connected.

1 members found this post helpful.

The noise:

At a guess, leaky capacitors, if the thing was cold. If it's been on for hours, they should have heated up. The noise gradually diminisges over 5 minutes, becoming inaudible.

The procedure is cold or dying inferior electrolytes leak plenty under high frequency, hence the hiss. They'd be fine under mains usually, but they get noisy when leaking. Often, they bulge. Then they die.

No, that's not the pattern. There's no buzz at startup. It happens much later, always when there's nothing much else going on.

But enough of that! This thread is really about my reboot problem and I have new information which has sent my mind down a new track completely.

Yesterday, I shut down X and then ran shutdown -r from the console. This time it got past the block and showed the elilo menu. I chose slackware and elilo loaded both the kernel and the initrd. And then it stopped dead. And I suddenly realised that I had seen this before, at least once and possibly more often. I saw it once when I was rebooting out of my experimental OpenBSD installation, which didn't have a gui.

So there are actually two potential freeze points, not one. And what do they have in common? Simply this: they both involve one program handing over control to another. The first is where the uefi program hands over to elilo. There are actually two steps here: loading elilo from disk and then giving it control of the hardware. I was assuming that it was the disk read which was failing, but now I think otherwise.

The second potential freeze point occurs after the kernel and initrd have been successfully read from the ESP. I know this because elilo prints out diagnostic messages:
Loading kernel.........done
Loading initrd.........done.

The next thing that is supposed to happen is that the kernel takes over the video. The elilo messages disappear and a cursor appears at the top of the screen, which has now become the kernel console. But when there is a freeze, that doesn't happen. I just see the frozen elilo messages.

Similarly with the first break point: as soon as the POST is over, control of the screen should be transferred from uefi to elilo and the menu should appear. But instead I see the frozen uefi messages.

It's a video problem. And that may explain why it seems to be worse when I shut down from X.

Now can anyone take this further?

i have read this thread through a couple of times and can't get a super clear idea if what is happening does so when any kind of system logging is taking place. if it is truly somewhere around when uefi is handing off to elilo, that seems improbable.

that being said, just in case there are logs from when you are trying to shutdown i have found lnav to be a great tool for looking into logs since it can integrate /var/log into one view. it also color codes warnings yellow and errors red to help them stand out from what might otherwise be tedious to suss from reading a bare log file. i have used this mostly on debian- and ubuntu-based systems so i don't know how helpful or portable it would be beyond that scope, but the home page makes it seem like it is fairly os/distro agnostic across mac and linux.

The shutdown is flawless. The console messages are the expected ones and there are no shutdown error messages of any kind in the system logs. It's the restarting that's problematic. Something in the state of the hardware after shutdown spooks the machine, something that normally gets reset by the electrical pulse of switching on.

PS: If someone could contribute a concise account of how this kind of handover is done, that would be useful. All three programs concerned (uefi, elilo, linux kernel) run on bare metal and control hardware directly. So how does one launch another?

1 members found this post helpful.

This is also happening with X not starting?

the only thing I could find is this not sure how it relates to uefi systems. https://en.wikipedia.org/wiki/Reboot

1 members found this post helpful.

That I don't know yet. I am going to have to experiment systematically with different kinds of reboot and see if a consistent pattern emerges. Most of my reboots so far have been from X, and that usually leads to a freeze when elilo tries to take over. I have seen at least two cases where rebooting from a console led to a freeze when the kernel took over. One of these was from OpenBSD and the other was yesterday, after shutting down X. OpenBSD did have X on it, I remember now, but I don't think I ever rebooted it directly from X.

Of course there may be no consistent pattern but I still think it's worth testing for one.

My video setup is eccentric btw: the Lenovo doesn't have a separate graphics chip but a composite Intel Bay Trail processor that does the graphics as well.

I read through the thread and my initial response to the first post is still what I want to add, and your later discussions about 'the noise' (coil whine was my first thought too) strengthen that: it sounds like there's a problem with the system's power supply. I've seen this exact behavior on machines with flaky or failing power supplies (or if the VRM sections on the motherboard are failing) a number of times and switching power supplies usually is the 'fix', but then you mentioned it has an 'external power supply.' What I'm guessing your system is, then, is DC-DC internally, and you have an external power brick (like a laptop) but if that's wrong, please fill in the blanks.

What I would try: do you have a replacement PS that you can try? Or any other replacement hardware that you can swap out? How does the machine handle booting/running/rebooting in a live environment? In other words:
1. Completely sidestep the entire software/disk nexus here - if it works 'flawlessly' with something like an Ubuntu live disk, probably the issue is configuration/OS-side.
2. From there, if the issue 'persists' then you can more confidently move on to hardware, or go back to software troubleshooting.
3. If the issue pushes you to look at hardware, I'd start with the PS, and then consider the motherboard or RAM.

Coil whine is by itself not a 'bad thing' (but some people find it very annoying) - its just resonance/noise from the coil(s) (inductors usually, but other coils can also exhibit it) having current passed through them. As I understand it, it's in the same 'family' of physical effects that cause MRI machines to make the sounds they do, and can be exploited to make weird electronic music as well (like the 'Floppotron' videos you may have seen online). But if it's a 'new' noise that may be the result of something in hardware changing/failing. I would be very suspicious of power or motherboard condition if a machine is locking up during power cycle *and* you're hearing new noises from the machine when it happens - that makes me think its hardware, but I'd double-check that with a live boot of something independent of your disks/configuration just to see (as in, boot up Ubuntu on live disk, play around it, reboot it, etc - does it work? does it throw errors? etc), and then move on to the hardware thing as above.

1 members found this post helpful.

obobskivich,

hazel’s PC is a Lenovo ThinkStation E50 (90BX0018UK), which is also known as the ThinkCenter E50. It uses an external power supply unit, a 65W model, just like a laptop, to power the base unit, rather than an integrated one.

https://kingworldnews.com/review-len...nkstation-e50/

1 members found this post helpful.

@hazel: One way you can check for coil whine is this. Power supplies switch faster on heavier load as a rule, and coils should be above audible frequency. Get loads of power through the pc, peripherals running on usb, bright screen doing intensive gpu work, maybe a backup running to a usb disk, and coil whine should vanish. Get the reverse, low brightness, pc doing nothing, and it might come back.

Sounds like a good program, but I don't have any replacements that I could use. As beachboy says, this machine actually has laptop electronics in a tower casing and uses an external "brick" for power. And I only have the one example of that.

I can certainly check rebooting from a live CD. That's one thing I haven't tried so far. At the moment I'm working my way systematically through reboots in different video environments. I still think it's a video problem because the two freeze points both occur when one program is handing over the screen to another. So far I've consistently got the earlier one (uefi -> elilo)when rebooting from X and the later one (elilo -> linux) when rebooting from the command line. And it has never happened (so far!!) in a fresh boot.
I get the buzz quite often now during normal use. And I don't usually get it during a "freeze" though I did on one occasion. The one consistent thing is that it seems to happen when the cpu is idle. That's why I thought it might be a disk thing, because disks are synced when nothing else is going on. But my second freeze point doesn't involve any kind of disk access. I know that because the loading of both the kernel and its initrd go to completion (reported "done") and then I get the freeeze just when the kernel should take over the screen. So I'm now inclined to think that the buzz is a red herring here.