I'm encountering a really frustrating problem. I'm trying to use my Pine64 in a headless configuration, so failing to boot is a big problem. When I plug into the console, the failure always seems to be at the point of loading "cfg80211". I don't have a wireless module and I don't want any such thing loaded. Any ideas?
Code:
[ 38.587273] Modules linked in: cfg80211(+)
[ 38.596878]
[ 38.603529] CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.105-0-pine64-longsleep #3
[ 38.617457] Workqueue: events start_work
[ 38.626878] task: ffffffc039b52f80 ti: ffffffc039b54000 task.ti: ffffffc039b54000
[ 38.640301] PC is at __do_softirq+0xb4/0x2d8
[ 38.650188] LR is at __do_softirq+0x30/0x2d8
[ 38.660029] pc : [<ffffffc0000b5fc4>] lr : [<ffffffc0000b5f40>] pstate: 40000145
[ 38.673344] sp : ffffffc039b57910
[ 38.682132] x29: ffffffc039b57910 x28: ffffffc000a760c0
[ 38.693105] x27: ffffffc000a76000 x26: ffffffc039b57910
...
(03-27-2017, 01:04 PM)grobbs Wrote: [ -> ]I'm encountering a really frustrating problem. I'm trying to use my Pine64 in a headless configuration, so failing to boot is a big problem. When I plug into the console, the failure always seems to be at the point of loading "cfg80211". I don't have a wireless module and I don't want any such thing loaded. Any ideas?
Code:
[ 38.587273] Modules linked in: cfg80211(+)
[ 38.596878]
[ 38.603529] CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.105-0-pine64-longsleep #3
[ 38.617457] Workqueue: events start_work
[ 38.626878] task: ffffffc039b52f80 ti: ffffffc039b54000 task.ti: ffffffc039b54000
[ 38.640301] PC is at __do_softirq+0xb4/0x2d8
[ 38.650188] LR is at __do_softirq+0x30/0x2d8
[ 38.660029] pc : [<ffffffc0000b5fc4>] lr : [<ffffffc0000b5f40>] pstate: 40000145
[ 38.673344] sp : ffffffc039b57910
[ 38.682132] x29: ffffffc039b57910 x28: ffffffc000a760c0
[ 38.693105] x27: ffffffc000a76000 x26: ffffffc039b57910
...
Just a stab in the dark here as it is halting around 38 seconds after boot... did you have the ethernet plugged in? If not, you might want to plug it in, or wait for five minutes for it to timeout, as the default config is not set to allow-hotplug but to require a DHCP IP to be discovered on boot.
If there are unexplained crashes during boot, first check if you have an appropriate power supply. You need something that can deliver at least 5V/2.5A with proper cabling to the micro-USB port or use the headers for DC-IN connection. Random phone chargers are usually more trouble because they are trying to be smart about what current limits a device will require...
Thanks for the replies.
pfeerick: Yes, I noticed there is a long delay without the Ethernet plugged in, at least if it's expecting to get a DHCP response. However, I have the Ethernet cable plugged in and waiting for the network doesn't result in the long spew of debug information that I saw. I only copied the first few lines.
xalius: I'm using the 2A/5v adapter supplied by Pine.
Yea, I'm having similar issues. My Pine64 will boot with an HDMI monitor (well, TV technically, whatever) plugged in, but with no HDMI, I can't login via SSH even 10 minutes later.
Ok, looking at a serial console connection, I get... so many messages I have no idea where to look. See full log attached.
I'm guessing the problem is something to do with:
[ 38.595837] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:1:30]
Working back from that, I find:
[ 12.511696] [HDMI WRN] file:drivers/video/sunxi/disp2/hdmi/drv_hdmi.c,line:331: [ 12.521649] systemd[1]: Starting udev Coldplug all Devices...
unsupported video mode 65535 when set display mode
Anyone got any ideas?
Ok, after chatting with nice helpful folks on IRC channel:
Created new image on different SD card. Boots fine headless. I don't know yet if my SD card is mildly incompatible, if the OS files got corrupted, or if I shouldn't have done a dist-upgrade on my install. Now to find out...
Solved! My crash on headless boot is caused by the most recent kernel installed via /usr/local/sbin/pine64_update_kernel.sh.
3.10.105-0-pine64-longsleep for anyone playing along later.
Now I just have to figure out how to roll that back.
Figured out how to roll back:
pine64_update_kernel.sh 3.10.104-2-pine64-longsleep-113
And after that... still crashes. Plug monitor back in, try again with 3.10.104-1-pine64-longsleep-103...
And it works! So it's something that changed in 3.10.104-2-pine64-longsleep-113
(04-09-2017, 05:16 PM)TinkerBear Wrote: [ -> ]Figured out how to roll back:
pine64_update_kernel.sh 3.10.104-2-pine64-longsleep-113
And after that... still crashes. Plug monitor back in, try again with 3.10.104-1-pine64-longsleep-103...
And it works! So it's something that changed in 3.10.104-2-pine64-longsleep-113
Hm interesting... there are two people who have noted
issues with headless booting, specifically if the HDMI isn't connected. I've started to notice it on one of my pine64s with the current 105 kernel which won't come up properly on a reboot, but it boots up fine once I plug the HDMI in, and it's most certainly not a power issue as it runs from it's own battery + a 4A 5.2v power supply. Didn't seem have any of these issues with the 104 kernel, so that much seems consistent.
pfeerick
I've now heard more than 4 reports of this in the IRC. It seems like if you first boot with HDMI connected then after consequent reboots headless doesn't work. Based on the feedback from other users who had this issue, the "solution" is too boot headless on first boot...
(04-09-2017, 05:16 PM)TinkerBear Wrote: [ -> ]Figured out how to roll back:
pine64_update_kernel.sh 3.10.104-2-pine64-longsleep-113
And after that... still crashes. Plug monitor back in, try again with 3.10.104-1-pine64-longsleep-103...
And it works! So it's something that changed in 3.10.104-2-pine64-longsleep-113
Thanks for letting us know! Just a heads up: i
n 3.10.104-1 you will still likely experience problems with GbE ethernet.
See longsleep's potential explenation for the issue at:
12:04:16 and
12:09:06
Quote:11:32:59 <lukasz> longsleep: looks like people encounter issues booting headless if they boot WITH HDMI on first boot.
11:33:14 <lukasz> Seems to only affect 3.10.105 ?
11:34:16 <longsleep> lukasz: mhm - well some touch screen related modules were enabled in .105, but i still think that it might be a power issue. Has anyone reproduced this when powering through euler?
11:35:09 <lukasz> not to my knowledge
11:36:28 <longsleep> lukasz: what exactly is the problem? Can you describe it?
11:38:44 <lukasz> Unfortunately no, as I myself havent experienced the problem
11:38:58 <lukasz> but from what I understand some users boot with mouse/keyboard and monitor first
11:39:34 <lukasz> then disconnect the mouse/keyboard and monitor and attempt to ssh on subsequent boots
11:39:36 <lukasz> and cannot do so
11:40:01 <lukasz> longsleep: ah, take a look here: https://forum.pine64.org/showthread.php?tid=4417
11:41:41 <lukasz> see TinkerBear's last commnet (#8)
11:41:47 <lukasz> comment*
11:42:17 <lukasz> he rolled back and wrote "And it works! So it's something that changed in 3.10.104-2-pine64-longsleep-113"
11:43:53 <maya> new distros to look like old windows
11:44:29 <longsleep> lukasz: rolled back where?
11:44:48 <lukasz> to an older kernel
11:44:54 <longsleep> lukasz: yes to which one?
11:45:27 <lukasz> 3.10.104-1
11:46:12 <longsleep> lukasz: mhm thats without GbE fix, does he use ethernet?
11:46:30 <lukasz> dont know - will let him know
11:53:24 <longsleep> lukasz: please tell people with that problem to add their details to https://github.com/longsleep/build-pine6.../issues/51 - as it seems to be related
11:56:27 <lukasz> pfeerick already added that
11:56:37 <lukasz> *linked that
12:02:50 <longsleep> lukasz: so just for me to understand this correctly,people have issues when booting for the first time when HDMI is connected, right?
12:03:00 <lukasz> right
12:03:04 <lukasz> thats how I understand it too
12:04:16 <longsleep> lukasz: mhm, HDMI draws power - maybe in some cases it draws to much and the extra current cannot be provided through HDMI
12:05:09 <lukasz> longsleep: Well the issue is that hte board doesnt boot AFTER no HDMI is connected on subsequent boots
12:05:14 <lukasz> thats how I understand it
12:06:12 <longsleep> lukasz: i do not get that part - does not boot after no HDMI .. ?
12:07:19 <Pepe> Hello guys
12:07:23 <longsleep> lukasz: also the log https://forum.pine64.org/attachment.php?aid=775 is from debian, no idea what so ever was modified there
12:07:50 <longsleep> lukasz: that log pretty much starts crashing once wifi gets enabled, most likely power issue
12:08:28 <longsleep> lukasz: also the wifi driver is crap and can cause all kind of crashes
12:08:31 <lukasz> First time the user boots in a desktop configuration - mouse, keyboard, screen all connected. Then, they disconnect all peripherals and decide to run headless. As I understand it, this is where problems arise - the board wont boot without a screen attached.
12:08:34 <longsleep> lukasz: i suggest to not use it
12:09:06 <longsleep> lukasz: yes, they most likely remove stuff which feed extra power - now lacking that power things stop working
12:09:22 <lukasz> ah, understand ...
12:10:02 <lukasz> but, would this explain why rolling back to an older kernel (3.10.104-1) would solve the issue ?
12:11:24 <longsleep> lukasz: just a coincidence, and it might draw less power as it does not load various modules and in case you have one of those boards with GbE timing issues also does use almost no power
12:11:46 <lukasz> alright