search

dimkr / rlsd

A lightweight, retro Linux-libre distro
http://rlsd.dimakrasner.com
MIT License
72 stars 7 forks source link

Out of range error on booting #56

Open vitamin1 opened 10 years ago

vitamin1 commented 10 years ago

My LCD monitor (19") goes blank and I can see only error message: 'Out of range'.

dimkr commented 10 years ago

Please give me more details - I need to know the native resolution, ratio and GPU model.

vitamin1 commented 10 years ago

1440x900, 16:9, radeon hd5750. But shouldn't booloader auto-detect screen resolution?

dimkr commented 10 years ago

It has nothing to do with the boot loader. Is it a UEFI machine?

vitamin1 commented 10 years ago

No, BIOS. BTW, my screen ratio is 16:10.

dimkr commented 10 years ago

Interesting. Does this happen with another monitor (with a 4:3 or 16:9 ratio)?

vitamin1 commented 10 years ago

I don't have another monitor.

dimkr commented 10 years ago

Do you have another computer? I want to isolate the problem - it could be the VESA BIOS, monitor, GPU or a bug in the resolution guessing code.

vitamin1 commented 10 years ago

I got only one computer.

dimkr commented 10 years ago

Wow, you're problematic. I cannot help you unless you figure out a way to isolate the problem, since I'm unable to reproduce the bug.

butiliero commented 10 years ago

If it can help, it does the same for me on a Radeon 4600 and a 4:3 1280x1024 display. I think the culprit is the radeon card. Fatdog has a special boot code for "problematic radeon" cards... maybe it's a starting point.

dimkr commented 10 years ago

Try to boot RLSD without "vga=ask" - it could be RLSD's resolution guessing patch that causes trouble against Radeon cards.

dimkr commented 10 years ago

Oh, another thing: try to boot with "nomodeset". I've seen several reports about similar issues in other distros. If this solves the problem, I'll disable Radeon KMS in the kernel configuration.

butiliero commented 10 years ago

"nomodeset" didn't make any difference. Booting without "vga=ask" seems to work, although I could not test it fully because it didn't reach the desktop for other reasons (which I know how to solve but didn't have time to address).

dimkr commented 10 years ago

Good, so it must be the kernel patch. Can you upload a photo of the resolutions menu you get with vga=ask, using another distro? I want to see the resolutions it offers.

butiliero commented 10 years ago

This is from Slacko64

image

dimkr commented 10 years ago

Does it boot correctly if you pick 1920x1440x32 (3e6)? I wonder whether Radeon cards just dump all modes they support, while Intel ones omit those unsupported by the VESA BIOS.

butiliero commented 10 years ago

Nope, choosing that resolution it looks exactly the same as rlsd. It seems that rlsd chooses 3E6 instead of 324 which should be the correct one for this elder monitor. I can see some blurred text and it tries to proceed, but then it stops for other reasons (as said above).

dimkr commented 10 years ago

Great - now we know why this happens. Radeon cards report they support all modes, instead of just modes supported by both the GPU and the monitor, so the resolution guessing code picks the highest resolution supported by the GPU but not the monitor.

I've examined the kernel code and I don't know to work around this problem in a generic way (e.g without having a separate ISO for Radeon cards). Let me think more about it.

butiliero commented 10 years ago

I should add that when dropping the vga=ask line, I get a no /dev/fb0 error at xinit, both with and without the "nomodeset" boot parameter. Maybe in the end our relatively old card is not recognized/supported by the kernel driver.

butiliero commented 10 years ago

Indeed, fatdog 700 boots straight to desktop at correct resolution even without selecting the "difficult radeon card" boot option.

dimkr commented 10 years ago

Fatdog doesn't need /dev/fb0, unlike RLSD (which uses Xfbdev). I still think this happens because the card offers resolutions that are too large for the monitor.

dimkr commented 10 years ago

Just a quick update - nothing new in this front. I still have no idea how to solve this problem - kicking the code that causes it would render RLSD's X server unusable under most visualization solutions.

technosaurus commented 10 years ago

I would recommend shifting this bug to the kernel radeon driver. I got to the section of the kernel that adds modes in drm drivers: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_modes.c

From the comments, it appears that the radeon driver in question is omitting the second step where modes "get filtered and all the modes actually supported by the hardware moved to the @connector's modes list" I think this should be done with: http://lxr.free-electrons.com/ident?i=ddrm_mode_prune_invalid which is called by http://lxr.free-electrons.com/ident?i=drm_helper_probe_single_connector_modes (note that radeon is one of the few gpu drm drivers that does not call this function)

....I tried to figure this out manually, but there is virtually no consistency between how the different drivers are implemented, so its not just a cut'n'paste. For now I would manually select video=vesa or specifically set the mode instead of ask for buggy drivers.

dimkr commented 10 years ago

Interesting! The Radeon driver seems to call drm_helper_probe_single_connector_modes(), it's a callback. However, it performs mode probing via EDID.

I think I'm playing with fire here - I don't have a Radeon card to debug this.

EDIT: I think the *_mode_valid() callbacks in the drm_connector_helper_funcs structures cause the problem.

EDIT 2: I think you're wrong - I think this bug has nothing to do with DRM/KMS. The problem happens in video-vesa.c AFAIK.