# Upate to 2.6.14-gentoo-r2 Monitor: Sync Out of Range[SOLVED]

## lyoo

After I updated to 2.6.14-gentoo-r2, some strange problem appeared:

1. I do not change any kernel configure and grub boot configure, all of them can work perfectly on  linux-2.6.13-gentoo-r5;

2. I compiled 2.6.14-gentoo-r2 and recompiled nvidia-kernel, reboot my computer, everything is ok, it can load frambuffer in console environment;

3. run startx, X window runs correctly, but, when I use ctrl+alt+Fn switch to console environment, monitor says: Sync Out of Range.

4. Then, I exit X window, monitor also says: Sync Out of Range, and can't works.

Motion: LG L1715S LCD

Graphics Card: nVidia Gf4200 8X

vesafb-tng:

(1024x768@60) VESA default mode 

grub.conf

```

default 0

timeout 30

splashimage=(hd0,6)/grub/splash.xpm.gz

title=Gentoo Linux (2.6.14-gentoo-r2)

root (hd0,6)

kernel /kernel-genkernel-x86-2.6.14-gentoo-r2 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda9 video=vesafb:mtrr,ywrap,1024x768-32@60

initrd /initramfs-genkernel-x86-2.6.14-gentoo-r2

```

Does anyone know what's wrong?Last edited by lyoo on Sat Nov 26, 2005 3:32 pm; edited 1 time in total

----------

## sonicbhoc

Same problem I'm having! Do you think that we need to downgrade kernels? because that would suck. I'm going to see if I can submit a bug report.

EDIT: Reports filed. Let's see what happens.

----------

## lyoo

yea, I'v downgraded kernels

I have another gentoo workstation, it updated to x86-2.6.14-gentoo-r2, works fine.

Motion: 17" CRT

Graphics Card: nVidia Gf4 MX440

----------

## dispossessed

Any progress on this? I'm having exactly the same problem with an LG 15" CRT and nVidia GeForce. The drivers (nVidia and vesafb-tng) seem to be working fine, presumably it's a bug in 2.6.14-gentoo-r2?

----------

## RandomAccess

I have an Intel i915G motherboard with the Intel GMA900 integrated graphics card, and I'm having the same problem. It only started happening after I upgraded my kernel to 2.6.14-gentoo-r2. So, I guess we can rule out it being a nVidia-only problem?

----------

## RandomAccess

OK, I noticed something just now. When I boot 2.6.14-gentoo-r2, just before the INIT Version 2.8 booting message, vesafb outputs something about "mtrr" being an unknown option. If you hit F2 to see verbose output during boot, you can catch it. You can also do:

dmesg | grep mtrr

When I boot under 2.6.13-gentoo-r5, I do not get the message about "mtrr" being an unknown option. My grub.conf looks like this:

default 0

timeout 10

splashimage=(hd0,0)/grub/splash.xpm.gz

title=Gentoo Linux 2.6.14-r2

root (hd0,0)

kernel /kernel-2.6.14-gentoo-r2 root=/dev/sda3 video=vesafb:mtrr,ywrap,1024x768-32@75 splash=silent CONSOLE=/dev/tty1

title=Gentoo Linux 2.6.13-r5

root (hd0,0)

kernel /kernel-2.6.13-gentoo-r5 root=/dev/sda3 video=vesafb:mtrr,ywrap,1024x768-32@75 splash=silent CONSOLE=/dev/tty1

Could it be that the mtrr option has something to do with it? I'm not exactly sure what it does, but it doesn't make sense to me that it would suddenly become an unknown option in the new kernel.

----------

## dispossessed

I'm seeing that too.. I removed mtrr from the boot options and the error disappeared, but the problem remained. Seems unrelated.

----------

## j-m

Erm, I don't know if anyone noticed yet, but the problem is solved - your kernel is misconfigured...   :Exclamation: 

That's why cross-posting about the same problem is bad.   :Idea: 

----------

## UncleMeat

Same problem here.

It's a new installation so I don't have X yet, when I reboot, my monitor says "out of range" (H=29.2Khz, V=70.0hz) and the specs fot it are H=30-95Khz V=50-150hz

My monitor is a Hyundaï Q995 with a Nvidia Geforce Ti 4200 (vesafb-tng)

My grub.conf:

 *Quote:*   

> default 0
> 
> timeout 30 
> 
> sphashimage=(hd0,0)/grub/splash.xpm.gz
> ...

 

Where could I change the H range?

EDIT:oups, sorry

----------

## dispossessed

Pretty sure that thread is about a different problem. I don't have any drivers other than vesafb-tng checked in the kernel config. Plus this problem occurs after running and exiting X, not initially or during the X session.

----------

## RandomAccess

 *Quote:*   

> Pretty sure that thread is about a different problem. I don't have any drivers other than vesafb-tng checked in the kernel config. Plus this problem occurs after running and exiting X, not initially or during the X session.

 

Same exact thing for me. My video kernel config is exactly the same as it was for <= 2.6.13-gentoo-r5, which _never_ exhibited this behavior.

----------

## sonicbhoc

I'd go out on a limb here and say that this is a little more than a few people misconfiguring their kernels. Any ideas?

----------

## sevo

That must be a different problem. vesafb-tng IS loading here, but does only offer low or wrong resolutions on 2.6.14. Which it emphatically did not with older kernels. Probably vesafb-tng is broken in 2.6.14. I am switching back to vesafb.

Sevo

----------

## j-m

Someone please file a new bug, seems like a different issue than the other thread.

----------

## ribx

i accidently started a new [url=https://forums.gentoo.org/viewtopic.php?p=2900176#2900176

]thread[/url] about the same problem.

i want to add that, when i started with my old vseafb settings:

```
video=vesafb:ywrap,mtrr,maxvf:60,maxhf:80,maxclk:??,1280x1024@60
```

i got a kernel panic complaining about vesafb init. i'm totaly sure about it. i noticed that its connected with the maxclk command. i'm not sure where i got that value from (actually i deleted and forgot the value itself - maybe it was 60 or 80?).

it looks like there where some big changes in vesafb-tng which arent full dokumented at the moment in the kernel doku. (or maybe i missed again something as i did with this post  :Sad:  )

i'm back to vga console for now

----------

## hielvc

Well I have two boxs, 1 is a sis, via c2 itx and a via chipset, sempron with geforce 440. The sis box works fine with 2.6.14 @1200x1024. The geforce box will only run at 1024x768 when running 2.6.14. Ive tried both vesa and vesa-tng, and the console and X at stuck at 1024. When I boot with 2.6.13 ever thing is fine.  I think has to do with 

```
*gentoo-sources-2.6.14 (28 Oct 2005)

  28 Oct 2005; Daniel Drake <dsd@gentoo.org> +gentoo-sources-2.6.14.ebuild:

  Initial release. Features vesafb-tng 1.0-rc1-r1
```

 (stupid "cue" key  just stoped working)

filed bug#113373

----------

## RandomAccess

OK, so you are limited to lower resolutions, but what about the original monitor signal out of range problem? I've never run my fbconsole higher than 1024x768 (call me old fashioned), so my problem doesn't happen to be the resolution. Rather, after X loads, I am unable to return to my fbconsole because my monitor complains about the signal being out of range, just as others have described in this thread. Should we open up a separate bug for this specific case?

 *Quote:*   

>  I think has to do with
> 
> ```
> *gentoo-sources-2.6.14 (28 Oct 2005)
> 
> ...

 

I think you are probably right about this one. There has to be have been a change that is causing both of these problems with 2.6.14, because everything was fine with 2.6.13.

----------

## hielvc

Yes I would recommend opening a new bug for it. One thing you might try is look i your /etc/rc.conf and if UNICODE="yes" set the coment it out and reboot. This is a wild shot,  but what the hay its your computer not mine    :Wink:  If it does work, definitly file a bug umm and mention me in big print  :Very Happy: 

----------

## RandomAccess

Yep, I checked my /etc/rc.conf and I did have UNICODE="yes" for some reason. When I put it to "no" it solved the problem. Obviously it should still work even with UNICODE="yes" so I have filed a new bug:

https://bugs.gentoo.org/show_bug.cgi?id=113408

Thanks for the tip! Hopefully this isn't a tough bug to fix.

----------

## dispossessed

Sorry to report that my UNICODE was already set to "no", but I'm still experiencing the problem..

----------

## lyoo

 *dispossessed wrote:*   

> Sorry to report that my UNICODE was already set to "no", but I'm still experiencing the problem..

 

Me too!   :Crying or Very sad: 

 *j-m wrote:*   

> Erm, I don't know if anyone noticed yet, but the problem is solved - your kernel is misconfigured...  
> 
> That's why cross-posting about the same problem is bad.  

 

I'v read the post, and checked my kernel config, I'm sure I'v "disabled anyother graphics driver other than vesafb".

 *RandomAccess wrote:*   

> Yep, I checked my /etc/rc.conf and I did have UNICODE="yes" for some reason. When I put it to "no" it solved the problem. Obviously it should still work even with UNICODE="yes" so I have filed a new bug:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=113408
> 
> Thanks for the tip! Hopefully this isn't a tough bug to fix.

 

I don't think that is the point. 

I have two gentoo workstations, they have almost the same configure, all have set UNICODE="yes" in /etc/rc.conf, one (Motion: 17" MAG CRT; Graphics Card: nVidia Gf4 MX440) works fine, another (Motion: LG L1715S LCD; Graphics Card: nVidia Gf4200 8X) "Sync Out of Range".

----------

## hielvc

Damn he did   :Cool: 

----------

## RandomAccess

 *Quote:*   

> I have two gentoo workstations, they have almost the same configure, all have set UNICODE="yes" in /etc/rc.conf, one (Motion: 17" MAG CRT; Graphics Card: nVidia Gf4 MX440) works fine, another (Motion: LG L1715S LCD; Graphics Card: nVidia Gf4200 8X) "Sync Out of Range".

 

OK, so in other words you're saying that UNICODE="yes" is NOT causing you a problem on one machine, while the other gets "sync out of range." Have you tried setting UNICODE="no" on the machine that is having problems? Maybe UNICODE="yes" is only causing problems with certain configurations.

----------

## olger901

Try using vesafb instead of vesafb-tng, and see if that solves your problem.

----------

## lyoo

 *olger901 wrote:*   

> Try using vesafb instead of vesafb-tng, and see if that solves your problem.

 

yeah, vesafb works fine.  :Laughing: 

----------

## RandomAccess

All, I was wondering if any of you experiencing the monitor signal out of range problems might check out the bug I submitted at https://bugs.gentoo.org/show_bug.cgi?id=113408 and follow the steps in Additonal Comment #1, to see if we can supply some more info to the devs. In short, after changing my UNICODE setting in /etc/rc.conf to "no," I can't reproduce the problem, even after switching back to "yes." I realize that many of you are experiencing this problem even with UNICODE="no", but any more information we can supply might help. I was getting signal out of range consistently ever since upgrading to 2.6.14, and now it just totally stopped...I do not understand it.

 *Quote:*   

> Try using vesafb instead of vesafb-tng, and see if that solves your problem.

 

While this may be a workaround, it doesn't help us track down the problem with vesafb-tng.

----------

## digitalsy

 *lyoo wrote:*   

>  *olger901 wrote:*   Try using vesafb instead of vesafb-tng, and see if that solves your problem. 
> 
> yeah, vesafb works fine. 

 

Sorry to dwell on this already [solved] case, but I'm experiencing the exact same problems when trying to run my console at 1600x1200-32@65 (my monitor max). It works perfectly fine with 2.6.8-gentoo-r7 kernel, but after I upgraded to 2.6.14-gentoo-r2 it causes my monitor to go OUT OF RANGE. X loads and works fine, I just can't CTRL-ALT-Fx back to a console. The boot process is flawless, the splash screen shows,sets the console to 1600x1200, shows the progress bar, loads kdm and I can login. Everything works except for console being out of range. I've even tried the default "nv" driver for Xorg...nothing. I tried switching back to vesafb driver, but then I got no framebuffer or splash whatsoever. How did you guys solve the problem???

----------

## RandomAccess

Well, I'm not sure why this thread has been marked "SOLVED," because I think most of us are still having problems. There are workarounds in some cases (for me, I can set UNICODE="no" in my /etc/rc.conf), but no solutions. You can try lowering your framebuffer resolution or play with your UNICODE setting in rc.conf to see if either of those helps. Or, you can visit the bug I submitted and try some of the steps the devs listed to see if you have any useful information you can share to help get this fixed.

----------

## hielvc

Ive made progress.  After recompileing my 14 and 14-r2 kernels with no sucess I copied my 13 config over the 14-r2 config and it worked . I looking thru it I  found out that some igiot vesa-thg default to " 1200x1924x75"   :Embarassed:   instead of 1200x1024@75 . That took care of the consul. Now Im going thru the xorg config .

----------

## digitalsy

Man I've tried everything...I already have UNICODE set to "no", setting Option "NoDDC" "1" in xorg.conf does nothing either. Quite simply vesafb-tng and kernel 2.6.14* do not like each other. I'm gonna continue to use it, and deal with having dysfunctional TTYs but ugh....

----------

## lexington

I'm also having the same problems here after switching from 2.6.13-r5 to 2.6.14-*

1.  Using vesa-tng exclusively in framebuffer section of kernel options with a setting of 1280x1024@60 

2.  Unicode set to "no" as by default in rc.conf 

3.  nVidia GeForce2 MX/MX 400 video card. 

I can't handle disfunctional TTY's so I've downgraded back to 2.6.13-r5 for now   :Confused: 

Hopefully this issue will be resolved

----------

## digitalsy

 *lexington wrote:*   

> I'm also having the same problems here after switching from 2.6.13-r5 to 2.6.14-*
> 
> 1.  Using vesa-tng exclusively in framebuffer section of kernel options with a setting of 1280x1024@60 
> 
> 2.  Unicode set to "no" as by default in rc.conf 
> ...

 

Mabye I should do the same... :/

----------

## lexington

Just as a follow up: I've decided to use vesafb instead of vesa-tng which is serving my purposes very well and I have noticed no difference thus far (using gensplash and the likes).  This allowed me to keep up with the current kernel versions (2.6.14-r*) without sacrificing the beauty of framebuffer consoles.  For a quick and dirty switch from vesa-tng to vesafb (at least until the bug is resolved):

Changing from vesa-tng to vesafb

1.  Change the kernel option to use vesafb instead of vesa-tng driver.  select the vga framebuffer device exclusively

2.  Compile and install the kernel

3.  In /boot/grub/grub.conf change the previous kernel option: video=vesafb to vga=#

    **Nothing else changes in your kernel options

4.  To calculate this number first: emerge lrmi

5.  As root, run vbetest and select a mode number (the higher ratios are modes with more colors, eg 8:8:8 )

6.  Look to the left of the mode you selected and note the number in brackets, ie [326]

7.  Take this number and add 512 to it.  This is the number for the vga=# argument in grub.conf

8.  Save grub.conf with the new option and reboot w/ frame buffer.  

Hopefully this helps someone out...especially those with nvidia cards that can't use any other driver except vga   :Confused: 

----------

## philip

The probelm can actually be solved using vesafb-tng

See here: https://forums.gentoo.org/viewtopic-p-2928682.html#2928682

----------

## dispossessed

 *philip wrote:*   

> The probelm can actually be solved using vesafb-tng
> 
> See here: https://forums.gentoo.org/viewtopic-p-2928682.html#2928682

 

Confirmed, this solved my problem. Thanks, philip.

----------

