*Debian X11/LDE display problem ?* hello,
I was having trouble to debug a problem related with the bootup process and the LDE GUI display. I am just a beginner so I'm not really sure what or why, but in the end it worked for me. *Configuration / Notes:* * BBB: Rev A5C * Power source: Using barrel connector +/- USB connector * Monitor: Samsung S22B300 Sync-master * Debian Build: root@beaglebone:# uname -a => Linux beaglebone 3.8.13-bone41 #1 SMP Tue Mar 4 22:51:47 UTC 2014 armv7l GNU/Linux * uEnv: cat /proc/cmdline => console=ttyO0,115200n8 video=HDMI-A-1:1024x768 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd * Good HDMI cable, validated with stock Angstrom & Ubuntu image; GUI works fine with these images * Debian configuration tested on separate TV monitor works fine - boots to GUI * VNC to Debian display GUI - no problem *Observation / Issue* * Boot process looks normal, Linux Penguin displays; proceeds to display * "The IP Address for eth0 ...." displays login prompt; auto login continues, screen goes blank and then after about 5 seconds the screen goes into power save mode. * Selecting tty2, the screen exists from power save mode and shows login prompt * Returning to tty7 the screen is blank and then returns to power save mode * echo 0 > /sys/class/graphics/fb0/blank has no impact (as root) * Pulled the EDID info following http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI and tried different resolutions with no change in the observations noted above. Finally, after many tests, google-ing, re-flashing, trying to understand the systemd/init.d/start process (still confused about how the boot process works) , I found some hints here; http://archlinuxarm.org/forum/viewtopic.php?f=28&t=5780 In the end, I (*waning => I am a beginner so use this at your own risk*) sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup sudo apt-get install xserver-xorg-video-fbdev sudo reboot and I have the LDE desktop !!! I'm noticing some errors in /var/logs/Xorg.0.log related to FBDEV(0): FBIOPUTCMAP: Invalid argument ,....but I'll leave that for another day. cheers On 22 March 2014 13:38, <selsin...@gmail.com> wrote: > On 20/03/14 15:56, Robert Nelson wrote: > > > bootup (wicd seems to take a good 5-15 seconds to get a valid ip > > address over dhcp, conman is slightly faster). > > > > You can see the ethernet driver taking it's sweet time over dmesg: > > > > [ 29.139188] net eth0: initializing cpsw version 1.12 (0) > > [ 29.142439] net eth0: phy found : id is : 0x7c0f1 > > [ 29.142650] libphy: PHY 4a101000.mdio:01 not found > > [ 29.147705] net eth0: phy 4a101000.mdio:01 not found on slave 1 > > [ 29.164068] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 32.222827] libphy: 4a101000.mdio:00 - Link is Up - 100/Full > > [ 32.222962] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > [ 34.697540] net eth0: initializing cpsw version 1.12 (0) > > [ 34.699719] net eth0: phy found : id is : 0x7c0f1 > > [ 34.699817] libphy: PHY 4a101000.mdio:01 not found > > [ 34.705082] net eth0: phy 4a101000.mdio:01 not found on slave 1 > > [ 34.715656] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 35.108521] net eth0: initializing cpsw version 1.12 (0) > > [ 35.110713] net eth0: phy found : id is : 0x7c0f1 > > [ 35.110812] libphy: PHY 4a101000.mdio:01 not found > > [ 35.116039] net eth0: phy 4a101000.mdio:01 not found on slave 1 > > [ 35.126630] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 37.102955] libphy: 4a101000.mdio:00 - Link is Up - 100/Full > > [ 37.103082] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > > However, if we enable it in [/etc/network/interfaces], the serial > > login prompt will not show up till after eth0 gets a valid ip or the 2 > > minute dhcp time out. So boot times fall from the 12-15 seconds to > > 30ish. > > Something is wrong there, it appears that something is bringing the > link up/down three times. > I think three seconds to get link is a bit long, but I see the same. It's > doing it three times that's costing all the extra time. > > Any possibility of dodgy cable or hardware somewhere ? > > Regardless, DHCP shouldn't block serial console, it should immediately > daemonize and let startup move on. If it doesn't then that's a bug. > > FWIW I see a single cycle of what's in your dmesg like this: > > [ 5.480948] net eth0: initializing cpsw version 1.12 (0) > [ 5.557625] net eth0: phy found : id is : 0x7c0f1 > [ 5.557707] libphy: PHY 4a101000.mdio:01 not found > [ 5.557716] net eth0: phy 4a101000.mdio:01 not found on slave 1 > [ 5.564342] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 8.637383] libphy: 4a101000.mdio:00 - Link is Up - 100/Full > [ 8.637428] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > In context it looks like > > 13:47:40.543 kernel: [ 4.948036] NET: Registered protocol family 10 > 13:47:40.543 kernel: [ 5.024912] EXT4-fs (mmcblk0p2): re-mounted. Opts: > (null) > 13:47:40+00: dhcpcd[131]: version 6.1.0 starting > 13:47:40.557 kernel: [ 5.480948] net eth0: initializing cpsw version > 1.12 (0) > 13:47:40+00: dhcpcd[131]: forked to background, child pid 135 > 13:47:40.638 kernel: [ 5.557625] net eth0: phy found : id is : 0x7c0f1 > 13:47:40.638 kernel: [ 5.564342] IPv6: ADDRCONF(NETDEV_UP): eth0: link > is not ready > 13:47:40+00: dhcpcd[135]: eth0: waiting for carrier > 13:47:40+00: dhcpcd[135]: eth0: carrier acquired > 13:47:40+00: dhcpcd[135]: eth0: carrier lost > 13:47:40+00: dhcpcd[135]: eth0: waiting for carrier > 13:47:40+00: ntpd[143]: ntpd 4.2.6p5@1.2349-o Fri Jan 3 16:05:29 UTC > 2014 (1) > 13:47:40+00: ntpd[156]: proto: precision = 1.000 usec > 13:47:40+00: ntpd[156]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 > 13:47:40+00: ntpd[156]: Listen normally on 2 lo 127.0.0.1 UDP 123 > 13:47:40+00: ntpd[156]: peers refreshed > 13:47:40+00: ntpd[156]: Listening on routing socket on fd #20 for > interface updates > 13:47:41+00: sshd[157]: Server listening on 0.0.0.0 port 22. > 13:47:41+00: sshd[157]: Server listening on :: port 22. > 13:47:43+00: dhcpcd[135]: eth0: carrier acquired > 13:47:43.717 kernel: [ 8.637383] libphy: 4a101000.mdio:00 - Link is Up > - 100/Full > 13:47:43.717 kernel: [ 8.637428] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: > link becomes ready > 13:47:43+00: dhcpcd[135]: eth0: rebinding lease of 172.20.0.21 > 13:47:43+00: dhcpcd[135]: eth0: leased 172.20.0.21 for 86400 seconds > 13:47:43+00: dhcpcd[135]: eth0: adding host route to 172.20.0.21 via > 127.0.0.1 > 13:47:43+00: dhcpcd[135]: eth0: adding route to 172.20.0.0/16 > 13:47:43+00: dhcpcd[135]: eth0: adding default route via 172.20.255.1 > 13:47:44+00: ntpd[156]: Listen normally on 4 eth0 172.20.0.21 UDP 123 > 13:47:44+00: ntpd[156]: peers refreshed > > and dhcp gets a lease pretty much immediately the link comes up > > So if it's not a cable or hardware problem causing your link to flap three > times then > it's a software problem, but that could be in the distro network scripts, > wicd or > the kernel. Kernel driver seems stable for a while now, so I'd think one > of the other > two is more likely. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
