Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#26452 - Syslinux boots with white block on screen when having modeset on

Attached to Project: Arch Linux
Opened by Tasos (twilight) - Saturday, 15 October 2011, 13:05 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 02 March 2012, 09:31 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture i686
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Everytime I boot with syslinux I see on screen a white block which gets smaller when modesetting sets the native resolution for my monitor. I have an ATI Radeon 9200 (R200) using opensource drivers. I ve tried the stock kernel as well. This is the topic discussing the matter:

https://bbs.archlinux.org/viewtopic.php?id=119312

And here is a video I captured demonstrating the issue:

http://www.youtube.com/watch?v=uEY-HcxN6xg

Additional info:
* package version(s)

Name : syslinux
Version : 4.04-2
URL : http://syslinux.zytor.com/
Licenses : GPL2
Groups : None
Provides : None
Depends On : perl glibc
Optional Deps : perl-passwd-md5: For md5pass
perl-digest-sha1: For sha1pass
mtools: For mkdiskimage and syslinux
Required By : unetbootin
Conflicts With : None
Replaces : None
Installed Size : 3592.00 K
Packager : Ionut Biru <ibiru@archlinux.org>
Architecture : i686
Build Date : Tue 02 Aug 2011 04:44:07 PM EEST
Install Date : Tue 16 Aug 2011 12:27:16 AM EEST
Install Reason : Explicitly installed
Install Script : Yes
Description : Collection of boot loaders that boot from FAT, ext2/3/4 and btrfs filesystems, from CDs and via PXE

* config and/or log files etc.

syslinux.cfg:

http://pastebin.com/8WrzgmUs

dmesg log:

http://pastebin.com/0Atz1WeL

/etc/mkinitcpio.conf:

http://pastebin.com/Yu7LiCnq

Steps to reproduce:

Boot with syslinux bootloader and have activated modesetting.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Friday, 02 March 2012, 09:31 GMT
Reason for closing:  Won't fix
Comment by Thomas Bächler (brain0) - Monday, 17 October 2011, 09:09 GMT
As of 3.0, the modesetting driver tries to keep the current contents of the screen after changing the resolution (at least it does so with my intel, when having syslinux in text mode). It seems that this goes wrong when combined with the vesamenu module in syslinux (the white block is actually an attempt to keep the syslinux menu, but the driver fails to capture the picture from vesa graphics mode).

It is my understanding that this block goes away when you either scroll it away or clear the screen. As this is likely a restriction in the graphics hardware, I am tempted to close this as "Won't fix".

In any case, I will try to reproduce this (I do not use vesamenu currently, but the text-based syslinux menu).
Comment by Tasos (twilight) - Monday, 17 October 2011, 10:56 GMT
Is there any change that settings in syslinux.cfg somehow workaround it? Except setting framebuffer off course, its not an option. I havent seen this on any other livecd with syslinux, including Arch's. It does not happen with GRUB2 either.
Comment by Thomas Bächler (brain0) - Monday, 17 October 2011, 12:02 GMT
Maybe GRUB2 clears the screen and sets it back to text mode before starting Linux, and that makes a difference. I don't know of any possible workaround, sorry.

First, I need to check if I can reproduce this with the intel KMS driver as well, or if it is only in ATI.
Comment by Antonis (birdflesh) - Tuesday, 18 October 2011, 10:29 GMT
I used to have the same. I worked around it by adding vga=current in my kernel boot line in syslinux.cfg
Comment by Tasos (twilight) - Tuesday, 18 October 2011, 10:49 GMT
Antonis, what graphic card do you have? Your workaround activates the framebuffer and clears the screen, that's why you dont have the white block.
Comment by Antonis (birdflesh) - Tuesday, 18 October 2011, 11:37 GMT
Intel GMA X4500 with early kms enabled.
Comment by Tasos (twilight) - Wednesday, 19 October 2011, 22:07 GMT
Antonis you cant use KMS and framebuffer at the same time without getting an error.
Comment by Antonis (birdflesh) - Thursday, 20 October 2011, 07:02 GMT
And I'm not. This is explained by a syslinux developer here:
http://www.syslinux.org/archives/2010-August/015173.html
Comment by Tasos (twilight) - Saturday, 22 October 2011, 23:34 GMT
In that case, I ll try appending vga=current on kernel line and report back asap.
Comment by Tasos (twilight) - Monday, 24 October 2011, 10:27 GMT
Appending vga=current seems to workaroung this issue successfully! It keeps the preset resolution (1400x1050) and now I have a smooth transition from the bootloader to plymouth.
Comment by Antonis (birdflesh) - Monday, 24 October 2011, 14:02 GMT
Nice to hear that. I guess that this could be closed now and the info can be added in the troubleshooting section of the syslinux wiki page.
Comment by Tasos (twilight) - Monday, 24 October 2011, 14:21 GMT
Yes, I agree this can be closed now and marked as "won't fix", as this is an upstream issue (kernel & kms related). Furthermore I ll edit the syslinux wiki page with this workaround.
Comment by Tasos (twilight) - Tuesday, 25 October 2011, 12:14 GMT
Now that I 've been thinking of it. I am using a custom syslinux.cfg file with resolution set at 1400x1050 pixels. How is it supposed for the modesetting driver to keep the current contents on the screen if 1400x1050 resolution is used in the first place and changed back and forth with the 640x480 resolution? That's probably why I see the white block (that block is actually 640x480 pixels). If I had a syslinux 640x480 resolution, I would probably not see a white block, but the syslinux menu. And that's why vga=current fixes it because it does not change resolution. So I think this is a modesetting bug rather than a syslinux one, if not a bug at all. I also wonder what will happen if I have two monitors connected with different native resolution, but in anyway its not in the scope of this bug report and neither it is for discussion.

Loading...