I seem to have a problem for one the servers that i am handling, i have reinstalled CentOS for nth times, and formated everything, edited the grub.conf time out = 0, but all still the same, the grub timer wont move, always stuck.
Did you end up finding a solution to this? I just had a server with this exact issue right after a fresh install of CentOS 6.x. Even though the system seemed to be keeping correct time, replacing the CMOS battery resolved the issue for me. This was either due to a faulty battery, or the CMOS settings getting reset when I replaced the battery.
Here are the sites that led me to that solution:
https://serverfault.com/questions/42877/grub-hangs-after-x-2-seconds
http://www.tomshardware.com/answers/id-1809044/centos-grub-countdown-stops.html
A user on one of those sites said that clearing the "System Event Log" fixed the issue for them. Here are some guides on accessing and clearing the SEL/BMC log:
http://download.intel.com/support/motherboards/server/s7000fc4ur/sb/sel_viewer_ug_e1246101.pdf
http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-59226
The issue could also be related to Grub's recordfail logic. More info here:
https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away?newreg=dc178d813fbb4f0d803644799bb89c5e
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/872244
Try adding this to /etc/default/grub
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT
Then run sudo update-grub
Support for GRUB_RECORDFAIL_TIMEOUT was added in the middle of the 12.04 cycle, starting from version 1.99-21ubuntu3.3
Check the date/time setup of your server. After I changed the CMOS battery, server's (HP Proliant) clock was 4 days behind and had same issue, the problem was fixed after setting it up correctly.
Related
I since a few months, I have been using a Hyperpixel 4.0 Touchscreen with my Raspberry 3B+ without any problems. Since a few weeks i use my touchscreen with the Raspberry Pi 4 Compute module and mounted both on my own designed PCB. Unfortunately, I’m facing some difficulties with the Touch function of my Hyperpixel 4.0. I have no clue how to solve these problems because the circumstances, which cause the fault don’t make sense to me.
Which System do I use?
Hyperpixel 4.0 in combination with Raspberry ComputeModule 4 with 2GB RAM and 8GB onBoard eMMC. Both is mounted on my custom PCB, which is supplied with 24V, stepped down by an «APP63300WU-7» Step down converter, which provides 3A # 5.1V continuous output. The measured Voltage over 2 Days of measurement is a maximum of 5.2V and a minimum of 5.05V. The software ist the latest Raspbian.
What error is caused?
I have been running a GUI on my Raspberry Pi. I have one Page on which i have three sliders for changing brightness of my room light, colortemperature and one slide is to regulate the speed of some fans. Everything works fine in darkmode, but if I change to lightmode and touch the screen for about 1.5 seconds, the touch- function hangs up. My GUI doesn’t move anymore and I have a still image. I know that it’s only the touch function beacause if I plug in a keyboard and mouse, I can open for example chromium or other stuff without problems. With «i2cdetect »-command I can detect the Goodix GT911 driver on Address 0x14. Even if the touch has hung up, i can detect the Goodix GT911. I know that the address should probably be 0x5D but I thought it isn’t necessary to care about this problem as long as it works. After a reboot, the touchscreen works fine again until i use the lightmode of my GUI. Interesting to mention is, that i can click a thousand times for around 0,25seconds and no problems occur. But if I touch the screen permanently for around 1,5seconds, I instantly get my above described problems. Generally considered, this problems seems very strange to me and it doesn’t behave like any physical law i know…
On the first view, the error seems like a software issue ? Hear this!
If i use the official «Compute Module 4 IO-Board » to mount my Compute Module and Touchscreen, I don’t get the issue at all… My actual designed PCB ist the 2nd version. On the 1st version It also worked fine without any problems. The only differnce between version 1 and 2 is the wiring, which I tried to improve on the 2nd version and viewer parts which I only put on my 1st version to evaluate some functionalities like ethernet or 2nd I2C-Bus, which I’m not using on my 2nd version. The wiring did not change between these two versions, i only tried to increase the distance between the GPIO-traces to improve signal integrity.
So it seems like a hardware problem? But why does the GUI work fine in darkmode? I don’t have any explanation to that.
What did I do to narrow down the error?
I flashed a new image on my Compute Module and also used another Compute Module, Custom PCB and touchscreen as well, but without any success. As far as I experienced, the issue is only caused on my GUI and not on any other websites or images, etc. An interesting thing was the interrupt line, which is typically only drawn to 0Volts if the touchscreen gets touched. After the touchscreen hung up, I measured 0,084V on that line and as long as I touched the screen, this voltage rised to about 0,2V, which for me seems also like a strange behaviour. I also checked the «dmseg» file and got some entries for failed i2c tests of the GoodixGT911. I also tried the github fix for the swapped i2c address, but without success. I used the command «git clone GitHub - pimoroni/hyperpixel4: Driver for the Pimoroni HyperPixel 4.0" Touchscreen Display -b pi4-i2c-fix » for that.
What do I try next?
I dont have any clue what to do next. My only solution in mind, is to undo the «improved» wiring of my 2nd PCB to get as close as possible my first PCB version.
Conclusion :
I really need help and hope, someone can do me this favour. I’ve never found my described error behaviour in any forum. Are there any other usable forums for problems with the Hyperpixel 4.0? Let me please know.
Update:
I tried to reproduce the errors and specify the error source. As above mentioned, the touchdriver hangs up on lightmode (nearly every pixel on rgb(255,255,255)). If i change the color in lightmode to around rgb(245,245,245) the error does not occur. I also noticed that there are two flatband cables on the Hyperpixel 4.0: One for displaying the image and another for the whole I2C-Communication to the touch driver. I plugged out the one for displaying the image and got no problems at all. Even if was theoretically in lightmode(if display would have been on). The touchscreen worked fine and transmitted everyting flawless:
Conclusion on my Update: It seems as the rgb(666) datalines for displaying the image on the screen cause some problems on the I2C bus. I also checked the bus and the power supply with an oscilloscope but I haven't seen any unusual behaviour in any case. Voltage ripple was around 200mV Peak to Peak and the I2C-Datalines rised and fell really sharp
I still need help from you!
Thanks, Manuel
I recently had a frustrating problem:
Modbus-connection throws in bError 4 as soon as bExecute is turned on. No variables could be read, and error persisted until reboot.
Previously working project stopped working over the weekend.
I might have fiddled around inside PLC, uninstalling couple libraries mainly, but logically thinking nothing should be wrong and I didnt do much at all. Its still possible I done goofed on friday, and didnt notice until after weekend.
On to the troubleshooting:
Reboot both machines
State machine is fine. Even made stripped-down project with one input and output and previously working minimalist state machine.
Reinstalled Modbus library in PC and PLC
Git revert the code couple weeks to a time when I 100% knew it worked.
PLC can ping PC in 1ms
Had an old project zipped in store, including "original" libraries
Reboot again
I still could wipe out PLC OS and start anew, but lets save that off for now.
"Thats all a mere mortal can do." I thought, and shot off a mail to Beckhoff.
Lets shoot off a mail to Beckhoff support.
Troubleshooting ensues:
Strip down the program even further, so only FB_MBReadInputs stays and bExecute can be flipped on or off manually.
Running only MBReadInputs, only MBWriteCoils, both at the same time
bError 4 problem persists no matter how much is stripped or ran.
Running the same project Locally on PC works just fine. Inputs can be read and output bits can be written.
In the end, flashing new image ended up being the solution.
Still in process of fiddling that out, so the actual problem isnt yet solved.
Update: Stuff works as it should. Some cosmic ray must have hit SD-card just right so during the weekend things got awry and problems surfaced.
Beckhoff image repo in my case: https://download.beckhoff.com/download/software/embPC-Control/CX90xx/CX9020/CE/TC3
Thats it, in the end wiping out SD-card is pretty basic thing to do when facing larger problems, but I just wanted to go through all the troubleshooting steps and end results for anyone struggling with Modbus and Twincat as much as I have.
I just reached out the same problem on CX8180. In my case there was some program uploaded before mine. I've activate my configuration and run PLC - get bError 4. TwinCAT errors code list says that is something with ADS mailbox and too much ADS calls. My program works fine on the same hardware elsewhere. Restart origin and activate configuration doesn't work.
I need to login with CeRHost and make a reboot of PLC. After that move communication works like a charm. The problem was the previous modbus communication.
I don't know if this is allowed here but can someone help me why am I getting this random blue screen? It say's whea uncorrectable error but I don't know which part of my PC is faulty. I noticed the BSOD appears when there is a heavy task like when I am coding in VSCode (running npm install, etc). I will attach here the minidump if someone can read it. If you need more information about my PC, let me know. Please I really need your help. I want to use this PC for programming. Thanks!
Latest Minidump File
This usually happens due to the high temperature in your pc, driver related issues or corrupted hardware. I recommend you try stopping overclocking for some time (if it is) and check if the problem persists. If not, then I think there could be a problem with your hardware itself. Try replacing the motherboard.
I am new here but I hope you can help me to find a solution to my problem.
I have four PIGRRL Kit from Adafruit and I need to install in it Raspbian (Operating System), the PiTFT and the gamepad as shown here (https://learn.adafruit.com/pigrrl-2/software).
But, when I try to install the gamepad, the OS goes in loop and the only way to exit it is to restart everything. I have checked if there were some problems with the soldering, but the voltage machine is not showing me any problem of the kind. The problem is just on the gamepad, because at the PITFT installation step everything goes fine and works.
But when I install the gamepad it goes in loop.
I used these commands:
cd
curl -O https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/retrogame.sh
sudo bash retrogame.sh
And then I follow the instructions for PIGRRL 2.0. But when I reboot, the OS loops.
Any idea or suggestion?
Thanks anyway!
I didn't tried retrogame, but I'm trying to use PiTFT 28 capacitive.
What I can say is that have some troubles with the display :).
In the first time I follow exactly they procedure and made my software work perfectly. But at some point in time it started to reboot after starting the software.
So I tried to start all over again, but this time I used Diet Pi and follow an alternative solution. I follow the procedure on this page: http://www.0xf8.org/2016/01/complete-rotation-support-for-the-adafruit-pitft-2-8-capacitive-touchscreen-display/
The display works, but:
1. If I use other console font, it starting immediately the font is going active.
2. The mouse don't work so well, it seems to start all the time in the left corner. So I didn't manage this part. :).
Maybe my answer can be useful in the combination of your experience.
Bafta
I found a solution. The problem for me was solved by charging the batteries. Basically, when it first reboots the OS needs more energy and with no charged batteries it went in loop.
All the best!
Because my work will get lighter for the next month or so, I decided to mess around with OS's, just to see how they work. I found this website, and I'm trying to run the code he provided. I am following the instructions exactly (to the best of my ability), but when I go to try booting with QEMU, I get this text:
SeaBios (version-blahblah)
Booting from Hard Disk...
Boot failed: could not read the boot disk.
Booting from Floppy...
And it never actually boots. I am relatively new to Ubuntu, and hoping that somebody would be able to point me towards where I made a mistake. I hope this is enough information to diagnose my error, and thanks in advance!
EDIT: Alright, I tried another tutorial which took me through very similar steps (but with slightly different code), and I still had the same issue. I also booted MikeOS from the floppy image it comes with, and it worked fine.
EDIT 2: Aaaaah! I just realized that when I pressed Ctrl+C, the text that was supposed to appear appeared for just a moment, then went away, along with QEMU. What can I do to make the text appear sooner? I've tried moving the infinite loop to after the display command, but to no avail.
I want to start by saying that I didn't read the entire page you provided (as I don't have enough time). However, the error that you cannot boot from HDD, regardless of the OS, usually (always in my previous experiences) means that either the MBA (Master Boot Record) is messed up/incorrect or you don't have a partition with a boot flag on it.
When I have some time I'll look deeper into that page and see if i can find exactly what the problem could be.
Do you have the bytes 0x55, 0xAA at offset 510 of your MBR?