Skip to content

Black Screen Issue On Boot #28

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ryancito02 opened this issue May 2, 2016 · 14 comments
Closed

Black Screen Issue On Boot #28

ryancito02 opened this issue May 2, 2016 · 14 comments

Comments

@ryancito02
Copy link

ryancito02 commented May 2, 2016

I have looked all over for the answer to this, as it seems others have encountered this problem as well, but I could never find a clear answer. Putting "avoid_warnings=2" in my /boot/config.txt did not do anything at all, and using another screen did not work either. I did switch out PSU from a 5V 2.1A to a 5V 2.3A but I still received the red-blue-green-yellow square on bootup, which indicates a brownout, or not enough voltage being supplied. When I had a Raspberry Pi 1, this sign would appear quite frequently and it still worked perfectly, so I don't believe that voltage has anything to do with it. Anyway, on to the problem. I have a Sandisk 8GB SD Card, which is compatible with the Raspberry Pi 2, according to the website. I flashed the latest Raspbian version (March 2016) onto the SD card using the command "sudo dd bs=4M if=~/Downloads/March2016/raspbian-jessie-March2016.img of=/dev/sdb" and successfully flash Raspbian. I then remove the SD card from the computer, take it out of the adapter, and insert it into my Raspberry Pi 2. It boots up fine, and I reboot it once out-of-the-box to make sure there is no corruption or problems, and after a reboot, I realize everything is working fine. The first things I do is go to my terminal and issue "sudo apt-get update && sudo apt-get -y upgrade" and patiently wait for that to finish. Afterwards, I go to the Raspbian Preferences and click Expand Filesystem, and I reboot. Upon entering Desktop again, I issue "sudo apt-get -y install xcompmgr libgl1-mesa-dri && sudo apt-get -y install libalut0 libalut-dev"
and receive the latest drivers. I issued "sudo raspi-config" and enabled the new OpenGL driver located in Advanced Options. I then reboot my Raspberry Pi 2 in high hopes, and my hopes are dashed by after reboot, a low voltage / brownout symbol covering the whole screen, after that, a flash of NO SIGNAL and then suddenly, just blackness. A pure black screen.

I have tried this on two different screens, one 1020x600 Touchscreen 7" which I mainly use for my Raspberry Pi's and another a large screen television to which I don't exactly know the resolution, but I would guess between 1080p and 1700p.

Any fix to this?

( I have not tried SSH yet to retrieve the logs, but if you absolutely require the logs, I will do good to enable and get them to you. However, it seems this problem has been answered before, so, I don't really expect to need to give you the logs. If you need them, just ask. )

@anholt
Copy link
Owner

anholt commented May 3, 2016

Only HDMI is supported: See #8 for tracking DSI panel support.

Yes, logs ar required if we're going to do anything here. Full dmesg, with drm.debug=0xf on the kernel's command line. Also probably /var/log/Xorg.0.log.

@ryancito02
Copy link
Author

I am currently using the screen through HDMI, although it supports VGA and AV as well.

As for my logs, here they are:

/boot/config.txt

http://pastebin.com/QZFH2TCu

(The driver is commented out for me to be able to use the Raspberry Pi 2)

/var/log/Xorg.0.log

http://pastebin.com/sB2QbHvU

And here is my Xorg.0.log.old:

http://pastebin.com/ngkaNbNF

and my dmesg output will be in my next comment, since I need to restart
my Raspberry Pi 2 to pass the drm.debug=0xf parameter to my kernel, in /proc/cmdline

Sent from my Raspberry Pi 2, GL driver disabled.

@anholt
Copy link
Owner

anholt commented May 3, 2016

Your xorg log indicates that the vc4 driver didn't actually load, so the details will be in dmesg. /boot/cmdline.txt is what controls your kernel command line, if you were trying something else. The dmesg might even be useful without the parameter, though, if it's a probing problem.

@ryancito02
Copy link
Author

I have successfully extracted the log from the Raspberry Pi 2 by using the command "dmesg --follow > dmesg.log" and doing a "scp pi@192.168.1.93:~/dmesg.log ~/Desktop" to transfer the file over to my Desktop. Here is the complete log file from the dmesg output:

http://pastebin.com/zEapN4fr

@anholt
Copy link
Owner

anholt commented May 4, 2016

The dmesg is missing the part from when it was probing modes, and just says that it didn't find any. You probably want to disable booting into X and just go to console, to shorten the dmesg from starting boot.

@ryancito02
Copy link
Author

Alright, I did an SSH into my Raspberry Pi 2, and did "sudo raspi-config" and made it auto login user pi to console. Strangely enough, when I rebooted, the Raspberry Pi 2 still does not connect to the screen. I assume it's a problem with loading the driver, but this is your forte.

Here is the log from the Console Pi:
http://pastebin.com/fD36NSmL

@anholt
Copy link
Owner

anholt commented May 5, 2016

dmesg.new.log.txt

Could you do "cat /sys/class/drm/card0-HDMI-A-1/edid > ~/edid" and attach the file? (there's a link for attaching files at the bottom of the comment box here. it's really good to use that instead, since pastebins expire)

@anholt
Copy link
Owner

anholt commented May 5, 2016

Also relevant: if you could plug that monitor into another Linux system with HDMI output and radeon, intel, or nouveau graphics, and get the edid from the corresponding file in their /sys/class/drm/card0, that might narrow things down.

@sharpener13
Copy link

Hi, just feeling this might be related (if not, ignore this message). Having RPI3, Arch Linux 4.4.9-1. When enabling "dtoverlay=vc4-kms-v3d" in config.txt only blank screen is also shown after reboot (then the monitor enters sleep mode, so probably even no signal is generated at all). The (coloured) dmesg outputs attached. It seems there is a stack trace, so something probably went wrong.
dmesg.vc4.txt
dmesg.working.txt

@ryancito02
Copy link
Author

The only reason I use Raspbian is because I thought that was the only operating system that the graphics driver was built for. Arch built for Raspberry Pi 2? Please! I have Arch on all my other machines, and to put it on my Raspberry Pi 2 would be great. (I knew there were Arch versions before, but I never knew the OpenGL drivers worked) and now you're saying that the driver would work on Arch? It seems like a Win-Win that I should switch to Arch.

Please, Mr. Sharpener, direct me to the download link for the driver for Arch.

Going to have a blast with my Raspberry Pi 2 now.

@ryancito02
Copy link
Author

After replicating the problem, but with 128 GPU mem, and avoid_warnings=2, I got the huge brownout sign covering the screen, again, and after NO SIGNAL, than a flash of blackness, then "NOT SUPPORT" which I assume means NOT SUPPORTED.

Anholt, does this remind you of any past issues?

@anholt
Copy link
Owner

anholt commented May 17, 2016

Note: The gpu mem setting in config.txt reserves memory that doesn't get used by the open graphics driver.

If you got the rainbow screen with the warnings setting in config.txt, then I don't know what's going on. That should only happen if something used dispmanx, and that's either the undervoltage warning or some ARM program you ran that used dispmanx. Very recent firmware should prevent anything on ARM from using dispmanx.

@ryancito02
Copy link
Author

It must be an exterior problem..

My screen is 1020 x 600. Is that a problem?

My PSU is 5.0V and 2.1A wall charger, connected to a USB to MICROUSB to my RPI2.
Is that a problem?

If both of those are not problems, then please, make a tutorial on setting this up correctly, or direct me to one. Thanks!

@ryancito02
Copy link
Author

Solved it, you need not worry.
I looked at Mr. Shapener's comment, and discovered I could run Arch.
So, I booted up Arch according to the Arch Linux ARM website.
I got into Arch, installed myself an LXDE desktop environment coupled with a login manager, then I went and did a pacman -Syu and installed the correct packages.
I installed raspberrypi-linux, the official raspberry pi linux package, and then I had a /boot/config.txt and the rest of it. I then edited my cmdline.txt to contain cma=256M and my config.txt to contain avoid_warnings=2 gpu_mem=256 and the line of code to enable the vc4 driver. Upon reboot, my login manager popped up, and fitted itself to all the sides of my screen. I logged in and it worked perfectly with GLXGEARS and other 3D OPENGL programs. Thanks!

anholt pushed a commit that referenced this issue Feb 5, 2018
commit b888fb6 upstream.

Move the workaround from stmpe_gpio_irq_unmask() which is executed
in atomic context to stmpe_gpio_irq_sync_unlock() which is not.

It fixes the following issue:

[    1.500000] BUG: scheduling while atomic: swapper/1/0x00000002
[    1.500000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.15.0-rc2-00020-gbd4301f-dirty #28
[    1.520000] Hardware name: STM32 (Device Tree Support)
[    1.520000] [<0000bfc9>] (unwind_backtrace) from [<0000b347>] (show_stack+0xb/0xc)
[    1.530000] [<0000b347>] (show_stack) from [<0001fc49>] (__schedule_bug+0x39/0x58)
[    1.530000] [<0001fc49>] (__schedule_bug) from [<00168211>] (__schedule+0x23/0x2b2)
[    1.550000] [<00168211>] (__schedule) from [<001684f7>] (schedule+0x57/0x64)
[    1.550000] [<001684f7>] (schedule) from [<0016a513>] (schedule_timeout+0x137/0x164)
[    1.550000] [<0016a513>] (schedule_timeout) from [<00168b91>] (wait_for_common+0x8d/0xfc)
[    1.570000] [<00168b91>] (wait_for_common) from [<00139753>] (stm32f4_i2c_xfer+0xe9/0xfe)
[    1.580000] [<00139753>] (stm32f4_i2c_xfer) from [<00138545>] (__i2c_transfer+0x111/0x148)
[    1.590000] [<00138545>] (__i2c_transfer) from [<001385cf>] (i2c_transfer+0x53/0x70)
[    1.590000] [<001385cf>] (i2c_transfer) from [<001388a5>] (i2c_smbus_xfer+0x12f/0x36e)
[    1.600000] [<001388a5>] (i2c_smbus_xfer) from [<00138b49>] (i2c_smbus_read_byte_data+0x1f/0x2a)
[    1.610000] [<00138b49>] (i2c_smbus_read_byte_data) from [<00124fdd>] (__stmpe_reg_read+0xd/0x24)
[    1.620000] [<00124fdd>] (__stmpe_reg_read) from [<001252b3>] (stmpe_reg_read+0x19/0x24)
[    1.630000] [<001252b3>] (stmpe_reg_read) from [<0002c4d1>] (unmask_irq+0x17/0x22)
[    1.640000] [<0002c4d1>] (unmask_irq) from [<0002c57f>] (irq_startup+0x6f/0x78)
[    1.650000] [<0002c57f>] (irq_startup) from [<0002b7a1>] (__setup_irq+0x319/0x47c)
[    1.650000] [<0002b7a1>] (__setup_irq) from [<0002bad3>] (request_threaded_irq+0x6b/0xe8)
[    1.660000] [<0002bad3>] (request_threaded_irq) from [<0002d0b9>] (devm_request_threaded_irq+0x3b/0x6a)
[    1.670000] [<0002d0b9>] (devm_request_threaded_irq) from [<001446e7>] (mmc_gpiod_request_cd_irq+0x49/0x8a)
[    1.680000] [<001446e7>] (mmc_gpiod_request_cd_irq) from [<0013d45d>] (mmc_start_host+0x49/0x60)
[    1.690000] [<0013d45d>] (mmc_start_host) from [<0013e40b>] (mmc_add_host+0x3b/0x54)
[    1.700000] [<0013e40b>] (mmc_add_host) from [<00148119>] (mmci_probe+0x4d1/0x60c)
[    1.710000] [<00148119>] (mmci_probe) from [<000f903b>] (amba_probe+0x7b/0xbe)
[    1.720000] [<000f903b>] (amba_probe) from [<001170e5>] (driver_probe_device+0x169/0x1f8)
[    1.730000] [<001170e5>] (driver_probe_device) from [<001171b7>] (__driver_attach+0x43/0x5c)
[    1.740000] [<001171b7>] (__driver_attach) from [<0011618d>] (bus_for_each_dev+0x3d/0x46)
[    1.740000] [<0011618d>] (bus_for_each_dev) from [<001165cd>] (bus_add_driver+0xcd/0x124)
[    1.740000] [<001165cd>] (bus_add_driver) from [<00117713>] (driver_register+0x4d/0x7a)
[    1.760000] [<00117713>] (driver_register) from [<001fc765>] (do_one_initcall+0xbd/0xe8)
[    1.770000] [<001fc765>] (do_one_initcall) from [<001fc88b>] (kernel_init_freeable+0xfb/0x134)
[    1.780000] [<001fc88b>] (kernel_init_freeable) from [<00167ee3>] (kernel_init+0x7/0x9c)
[    1.790000] [<00167ee3>] (kernel_init) from [<00009b65>] (ret_from_fork+0x11/0x2c)

Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
stschake pushed a commit to stschake/linux that referenced this issue Apr 11, 2018
A tty is hung up by __tty_hangup() setting file->f_op to
hung_up_tty_fops, which is skipped on ttys whose write operation isn't
tty_write().  This means that, for example, /dev/console whose write
op is redirected_tty_write() is never actually marked hung up.

Because n_tty_read() uses the hung up status to decide whether to
abort the waiting readers, the lack of hung-up marking can lead to the
following scenario.

 1. A session contains two processes.  The leader and its child.  The
    child ignores SIGHUP.

 2. The leader exits and starts disassociating from the controlling
    terminal (/dev/console).

 3. __tty_hangup() skips setting f_op to hung_up_tty_fops.

 4. SIGHUP is delivered and ignored.

 5. tty_ldisc_hangup() is invoked.  It wakes up the waits which should
    clear the read lockers of tty->ldisc_sem.

 6. The reader wakes up but because tty_hung_up_p() is false, it
    doesn't abort and goes back to sleep while read-holding
    tty->ldisc_sem.

 7. The leader progresses to tty_ldisc_lock() in tty_ldisc_hangup()
    and is now stuck in D sleep indefinitely waiting for
    tty->ldisc_sem.

The following is Alan's explanation on why some ttys aren't hung up.

 http://lkml.kernel.org/r/20171101170908.6ad08580@alans-desktop

 1. It broke the serial consoles because they would hang up and close
    down the hardware. With tty_port that *should* be fixable properly
    for any cases remaining.

 2. The console layer was (and still is) completely broken and doens't
    refcount properly. So if you turn on console hangups it breaks (as
    indeed does freeing consoles and half a dozen other things).

As neither can be fixed quickly, this patch works around the problem
by introducing a new flag, TTY_HUPPING, which is used solely to tell
n_tty_read() that hang-up is in progress for the console and the
readers should be aborted regardless of the hung-up status of the
device.

The following is a sample hung task warning caused by this issue.

  INFO: task agetty:2662 blocked for more than 120 seconds.
        Not tainted 4.11.3-dbg-tty-lockup-02478-gfd6c7ee-dirty anholt#28
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      0  2662      1 0x00000086
  Call Trace:
   __schedule+0x267/0x890
   schedule+0x36/0x80
   schedule_timeout+0x23c/0x2e0
   ldsem_down_write+0xce/0x1f6
   tty_ldisc_lock+0x16/0x30
   tty_ldisc_hangup+0xb3/0x1b0
   __tty_hangup+0x300/0x410
   disassociate_ctty+0x6c/0x290
   do_exit+0x7ef/0xb00
   do_group_exit+0x3f/0xa0
   get_signal+0x1b3/0x5d0
   do_signal+0x28/0x660
   exit_to_usermode_loop+0x46/0x86
   do_syscall_64+0x9c/0xb0
   entry_SYSCALL64_slow_path+0x25/0x25

The following is the repro.  Run "$PROG /dev/console".  The parent
process hangs in D state.

  #include <sys/types.h>
  #include <sys/stat.h>
  #include <sys/wait.h>
  #include <sys/ioctl.h>
  #include <fcntl.h>
  #include <unistd.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <errno.h>
  #include <signal.h>
  #include <time.h>
  #include <termios.h>

  int main(int argc, char **argv)
  {
	  struct sigaction sact = { .sa_handler = SIG_IGN };
	  struct timespec ts1s = { .tv_sec = 1 };
	  pid_t pid;
	  int fd;

	  if (argc < 2) {
		  fprintf(stderr, "test-hung-tty /dev/$TTY\n");
		  return 1;
	  }

	  /* fork a child to ensure that it isn't already the session leader */
	  pid = fork();
	  if (pid < 0) {
		  perror("fork");
		  return 1;
	  }

	  if (pid > 0) {
		  /* top parent, wait for everyone */
		  while (waitpid(-1, NULL, 0) >= 0)
			  ;
		  if (errno != ECHILD)
			  perror("waitpid");
		  return 0;
	  }

	  /* new session, start a new session and set the controlling tty */
	  if (setsid() < 0) {
		  perror("setsid");
		  return 1;
	  }

	  fd = open(argv[1], O_RDWR);
	  if (fd < 0) {
		  perror("open");
		  return 1;
	  }

	  if (ioctl(fd, TIOCSCTTY, 1) < 0) {
		  perror("ioctl");
		  return 1;
	  }

	  /* fork a child, sleep a bit and exit */
	  pid = fork();
	  if (pid < 0) {
		  perror("fork");
		  return 1;
	  }

	  if (pid > 0) {
		  nanosleep(&ts1s, NULL);
		  printf("Session leader exiting\n");
		  exit(0);
	  }

	  /*
	   * The child ignores SIGHUP and keeps reading from the controlling
	   * tty.  Because SIGHUP is ignored, the child doesn't get killed on
	   * parent exit and the bug in n_tty makes the read(2) block the
	   * parent's control terminal hangup attempt.  The parent ends up in
	   * D sleep until the child is explicitly killed.
	   */
	  sigaction(SIGHUP, &sact, NULL);
	  printf("Child reading tty\n");
	  while (1) {
		  char buf[1024];

		  if (read(fd, buf, sizeof(buf)) < 0) {
			  perror("read");
			  return 1;
		  }
	  }

	  return 0;
  }

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
anholt pushed a commit that referenced this issue May 7, 2018
commit 28b0f8a upstream.

A tty is hung up by __tty_hangup() setting file->f_op to
hung_up_tty_fops, which is skipped on ttys whose write operation isn't
tty_write().  This means that, for example, /dev/console whose write
op is redirected_tty_write() is never actually marked hung up.

Because n_tty_read() uses the hung up status to decide whether to
abort the waiting readers, the lack of hung-up marking can lead to the
following scenario.

 1. A session contains two processes.  The leader and its child.  The
    child ignores SIGHUP.

 2. The leader exits and starts disassociating from the controlling
    terminal (/dev/console).

 3. __tty_hangup() skips setting f_op to hung_up_tty_fops.

 4. SIGHUP is delivered and ignored.

 5. tty_ldisc_hangup() is invoked.  It wakes up the waits which should
    clear the read lockers of tty->ldisc_sem.

 6. The reader wakes up but because tty_hung_up_p() is false, it
    doesn't abort and goes back to sleep while read-holding
    tty->ldisc_sem.

 7. The leader progresses to tty_ldisc_lock() in tty_ldisc_hangup()
    and is now stuck in D sleep indefinitely waiting for
    tty->ldisc_sem.

The following is Alan's explanation on why some ttys aren't hung up.

 http://lkml.kernel.org/r/20171101170908.6ad08580@alans-desktop

 1. It broke the serial consoles because they would hang up and close
    down the hardware. With tty_port that *should* be fixable properly
    for any cases remaining.

 2. The console layer was (and still is) completely broken and doens't
    refcount properly. So if you turn on console hangups it breaks (as
    indeed does freeing consoles and half a dozen other things).

As neither can be fixed quickly, this patch works around the problem
by introducing a new flag, TTY_HUPPING, which is used solely to tell
n_tty_read() that hang-up is in progress for the console and the
readers should be aborted regardless of the hung-up status of the
device.

The following is a sample hung task warning caused by this issue.

  INFO: task agetty:2662 blocked for more than 120 seconds.
        Not tainted 4.11.3-dbg-tty-lockup-02478-gfd6c7ee-dirty #28
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      0  2662      1 0x00000086
  Call Trace:
   __schedule+0x267/0x890
   schedule+0x36/0x80
   schedule_timeout+0x23c/0x2e0
   ldsem_down_write+0xce/0x1f6
   tty_ldisc_lock+0x16/0x30
   tty_ldisc_hangup+0xb3/0x1b0
   __tty_hangup+0x300/0x410
   disassociate_ctty+0x6c/0x290
   do_exit+0x7ef/0xb00
   do_group_exit+0x3f/0xa0
   get_signal+0x1b3/0x5d0
   do_signal+0x28/0x660
   exit_to_usermode_loop+0x46/0x86
   do_syscall_64+0x9c/0xb0
   entry_SYSCALL64_slow_path+0x25/0x25

The following is the repro.  Run "$PROG /dev/console".  The parent
process hangs in D state.

  #include <sys/types.h>
  #include <sys/stat.h>
  #include <sys/wait.h>
  #include <sys/ioctl.h>
  #include <fcntl.h>
  #include <unistd.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <errno.h>
  #include <signal.h>
  #include <time.h>
  #include <termios.h>

  int main(int argc, char **argv)
  {
	  struct sigaction sact = { .sa_handler = SIG_IGN };
	  struct timespec ts1s = { .tv_sec = 1 };
	  pid_t pid;
	  int fd;

	  if (argc < 2) {
		  fprintf(stderr, "test-hung-tty /dev/$TTY\n");
		  return 1;
	  }

	  /* fork a child to ensure that it isn't already the session leader */
	  pid = fork();
	  if (pid < 0) {
		  perror("fork");
		  return 1;
	  }

	  if (pid > 0) {
		  /* top parent, wait for everyone */
		  while (waitpid(-1, NULL, 0) >= 0)
			  ;
		  if (errno != ECHILD)
			  perror("waitpid");
		  return 0;
	  }

	  /* new session, start a new session and set the controlling tty */
	  if (setsid() < 0) {
		  perror("setsid");
		  return 1;
	  }

	  fd = open(argv[1], O_RDWR);
	  if (fd < 0) {
		  perror("open");
		  return 1;
	  }

	  if (ioctl(fd, TIOCSCTTY, 1) < 0) {
		  perror("ioctl");
		  return 1;
	  }

	  /* fork a child, sleep a bit and exit */
	  pid = fork();
	  if (pid < 0) {
		  perror("fork");
		  return 1;
	  }

	  if (pid > 0) {
		  nanosleep(&ts1s, NULL);
		  printf("Session leader exiting\n");
		  exit(0);
	  }

	  /*
	   * The child ignores SIGHUP and keeps reading from the controlling
	   * tty.  Because SIGHUP is ignored, the child doesn't get killed on
	   * parent exit and the bug in n_tty makes the read(2) block the
	   * parent's control terminal hangup attempt.  The parent ends up in
	   * D sleep until the child is explicitly killed.
	   */
	  sigaction(SIGHUP, &sact, NULL);
	  printf("Child reading tty\n");
	  while (1) {
		  char buf[1024];

		  if (read(fd, buf, sizeof(buf)) < 0) {
			  perror("read");
			  return 1;
		  }
	  }

	  return 0;
  }

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants