Difference between reboot and Off then On again?

One of my Pis misbehaves (randomly it seems). A sudo reboot fails to reboot properly but unplugging it and then plugging it in again restores it to seemingly normal behaviour.

What precisely is the difference between the two restarts?

Do the symptoms mean that the FAT partition isn't included in the reboot?

Or something else?

Another Dave

--
Change nospam to gmx in e-mail.
Reply to
Another Dave
Loading thread data ...

In the latter you make sure that the hardware is reset. Your Pi's misbehaviour may be caused by a faulty driver.

- j -

--
Mail address is valid for a limited time only. 

And now for something completely different...
Reply to
Joerg Walther

Hm... I have one Pi that does this. The very first Pi I bought, from the original first 10K batch.

I've tried the same SD card in other Pi's and the reboot fine, tried other SD cards in this Pi and it doesn't reboot fine, but almost always needs a power cycle.

That Pi was somewhat used and abused in the early days - over volted, overclocked... I tested its GPIO to past when I thought the magic black smoke ought to come out, (35mA out a single pin, rebooting it by shoting GPIO pins to 0v in output mode), accidentally fed 5v into the pins - maybe I've done somthing internally that causes it, who knows... The Pi still works fine, as does its GPIO, it just won't reboot most of the time and needs a power cycle.

Gordon

Reply to
Gordon Henderson

Interesting. That may also explain a problem I had with a dual-boot desktop machine a couple of years ago. When switching from Linux to Windows Vista (or vice versa, I can't remember which) the sound would go dead if I did a software restart. A power off/power on cycle would cure the problem.

Moving to Windows 8.1 and/or Linux Mint 17 cured it.

Like Gordon Henderson's Pi this one is very old and has had some abuse. I suspect the DVB tuner stick's driver also.

Another Dave

--
Change nospam to gmx in e-mail.
Reply to
Another Dave

OK, then it's not a driver, but it certainly is a part of the hardware which locks up and must be reawakened with a power cycle.

- j -

--
Mail address is valid for a limited time only. 

And now for something completely different...
Reply to
Joerg Walther

This machine usually fails to soft reboot too. It gets as far as the bios splash screen and then hangs...

..I assume the bios assumes 'cold' hardware...

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

six of one. If th driver is expecting a cold start state and doesn't find it...and issue 'total reset'

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

That should mean that it expects *nothing* of the hardware. Unless there is a power on hardware reset, registers can assume any value on power on. If there is a power on reset, the soft reset needs to have a way to assert that reset. If that can't be done, the hardware is faulty and can't be counted on to ever soft reset properly.

--

Rick
Reply to
rickman

power on resets are done by the hardware.

How do you think a CPU knows how to boot at all?

Its the same for peripherals

Chip designers go to a lot of trouble to make sure the hardware is in a defined state when power comes up.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

I have seen this happen as well. It appears to be caused by a recent update, but I have not been able to pinpoint what it is, yet.

I think it hangs somewhere in the shutdown, shortly before it reboots. It needs more debugging.

Reply to
Rob

I'm not clear about your point. There are any number of CPUs with a pin for reset that is bidirectional. It can be asserted by hardware on the board such as a reset controller, or it can be asserted by software in the CPU. That is my point, this is the right way to do a soft reset.

On the other hand, it has happened more than once that a chip has not been designed properly so that the reset does not fully reset all the internal state. In that case the portions that are lacking a power on reset need special consideration from the software if even that will fully reset the chip. It's called a bug and even hardware can have them... just not as often as the software.

--

Rick
Reply to
rickman

I am wondering what you had for breakfast.

How can a CPU reset itself if its not in a state where its software is working at all?

Hard resets are absolutely de rigeur.

A CU executing random code in a random place will never reliably soft reset.

It MUST start from a given state on power on.

The last thing a soft reboot does is go to that state.

And its the same for all chips.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

I am wondering why you want to turn a discussion into a personal statement.

It can't. But when a CPU *can* reset itself from software the proper way to do it is to assert a hard reset.

What's your point..?

If the CPU is lost in the weeds there is *no* way to assert a soft reset, no? So what is your point?

You aren't making sense. You talk about being lost in the weeds and then talk about the CPU being able to perform a soft reset.

The point is that sometimes chips are not designed so that every FF can be accessed from the control interface. I have seen any number of boards that can not be fully reset from software because of problems with the chips and poor reset design. That is a fact.

--

Rick
Reply to
rickman

Only a guess, but I suspect that "sudo reboot" shuts things down safely then zeros the program counter, restarting the OS. A power cycle is much cruder and doesn't shut anything down safely or otherwise. Have you tried the reset input?

Reply to
mick

It is correct what he wrote. E.g. a 68000 CPU has a RESET instruction that pulls down the RESET* for some time (100 clockcycles or so) and then executes the normal CPU reset sequence, what it also does when something external pulls down the RESET* line.

This instruction would be executed as part of a "reboot" systemcall in the operating system (it is of course a privileged instruction).

Doing it this way makes sure that all hardware gets a reset signal as well, and you don't have to rely on the BIOS and Driver code to be written very carefully for each device to be reset and initialized from a completely unknown state.

I don't know how the Raspberry Pi handles this form of reset, but it does have a watchdog. When you want to reboot you can arm the watchdog and not trigger it, and a few seconds later it gets a hard reset.

I will try if the Pi I have at home that will not survive "reboot" will recover when I reset it that way. I want to know, because I have a Pi in colocation that I don't dare to reboot now. (someone else who has a Pi there has done "reboot" two times now and two times had to call the operators to powercycle it)

Reply to
Rob

How can it execute a reboot instruction if is as he said 'its registers (including the program counter) all 'all random''

I never said such instructions dont exist, I merely said that on power up, they are useless.

The C{PU has to be started at a defined pint in some code in order to even get to that instruction.

well no it doesn't guarantee any such thing. Only that the CPU has reset .

It certainly doesnt guarantee all attached peripheral hardware is reset

Particularly since what hardware IS attached is not known to the CPU at boot time.

And the boot process is what discovers it.

And to discover what it is, requires that the CPU can interrogate it.

IIRC the Pi does something with the GPU to reboot.

If the GPU is in a weird state it wont boot.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

I have not seen that written. The issue is not that registers are random, but that they have values different from what they have after a hard reset, and the BIOS or drivers assume differently.

You appear to think that only a processor has registers, but that is wrong. I/O devices have registers as well.

The thread topic is problems with reboot. Not power up.

You clearly do not understand the design of that hardware. I'll leave you with it.

Let's go back (without you) to the original topic.

Reply to
Rob

Most (or maybe half?) of the rpi-updates I do result in non-responsive RPi on reboot, requiring a power cycle. When I look at the LEDs it seems to be all right except there just isn't an ethernet connection. Wondered if it was a power issue but same trouble after switching to a 2 A quality adapter. Sometimes, and I have no idea why, it requires TWO power cycles. So far, everything always worked again after at most two hard boots. So now I try & avoid rpi-update. But improvements listed at

formatting link
do seem useful sometimes.

Maaaaaybe it's a router problem. AVM Fritzbox not exactly known for bug free firmware :(

Reply to
A. Dumas

There is no reset input, or rather that's just a hard reboot (power yanked).

Reply to
A. Dumas

But the author mentioned that it works fine from power up.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.