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...
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
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...
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.
04-10-2017, 05:31 AM (This post was last modified: 04-10-2017, 06:16 AM by Luke.)
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:
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: in 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 and12: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
