Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Tue, 9 Aug 2005, Bodo Eggert wrote: > On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote: > > On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote: > > > The wrong values are constant across reboots (see my first mail), and I > > > have a CRT. > > > > > > Can you tell me where the timing values are read? > > > > radeon_write_mode() programs the mode. The monitor timing infos are read > > by the various bits of code in radeon_monitor.c > > > > I'd be curious if you could identify what bit of code is misbehaving > > I added preempt_*able around radeon_probe_i2c_connector, and now I get the > output from below and still no sync. Obviously you shouldn't msleep in > preempt-disabled code. I'll try voluntary preemption, but that will at > best hide the error. Update: voluntary preemption does not cause bad readings. -- Who is General Failure and why is he reading my disk? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote: > On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote: > > The wrong values are constant across reboots (see my first mail), and I > > have a CRT. > > > > Can you tell me where the timing values are read? > > radeon_write_mode() programs the mode. The monitor timing infos are read > by the various bits of code in radeon_monitor.c > > I'd be curious if you could identify what bit of code is misbehaving I added preempt_*able around radeon_probe_i2c_connector, and now I get the output from below and still no sync. Obviously you shouldn't msleep in preempt-disabled code. I'll try voluntary preemption, but that will at best hide the error. Maybe I can mess with the msleep()s like thorndike's cat, but any success will be an accident. Aug 9 20:58:26 be1 __mod_timer+0xb4/0x100 Aug 9 20:58:27 be1 [] schedule_timeout+0x51/0xa0 Aug 9 20:58:27 be1 [] process_timeout+0x0/0x10 Aug 9 20:58:27 be1 [] msleep+0x2f/0x40 Aug 9 20:58:27 be1 [] radeon_probe_i2c_connector+0xaa/0x320 Aug 9 20:58:27 be1 [] radeon_probe_screens+0x482/0x5d0 Aug 9 20:58:27 be1 [] radeonfb_pci_register+0x309/0x570 ... Aug 9 20:58:27 be1 scheduling while atomic: swapper/0x0001/1 Aug 9 20:58:27 be1 [] schedule+0x589/0x640 Aug 9 20:58:27 be1 [] lock_timer_base+0x32/0x70 Aug 9 20:58:27 be1 [] __mod_timer+0xb4/0x100 Aug 9 20:58:27 be1 [] schedule_timeout+0x51/0xa0 Aug 9 20:58:27 be1 [] process_timeout+0x0/0x10 Aug 9 20:58:27 be1 [] msleep+0x2f/0x40 Aug 9 20:58:27 be1 [] radeon_probe_i2c_connector+0xaa/0x320 Aug 9 20:58:27 be1 [] radeon_probe_screens+0x482/0x5d0 Aug 9 20:58:27 be1 [] radeonfb_pci_register+0x309/0x570 Aug 9 20:58:27 be1 [] __pci_device_probe+0x48/0x60 -- It is still called paranoia when they really are out to get you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote: On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote: The wrong values are constant across reboots (see my first mail), and I have a CRT. Can you tell me where the timing values are read? radeon_write_mode() programs the mode. The monitor timing infos are read by the various bits of code in radeon_monitor.c I'd be curious if you could identify what bit of code is misbehaving I added preempt_*able around radeon_probe_i2c_connector, and now I get the output from below and still no sync. Obviously you shouldn't msleep in preempt-disabled code. I'll try voluntary preemption, but that will at best hide the error. Maybe I can mess with the msleep()s like thorndike's cat, but any success will be an accident. Aug 9 20:58:26 be1 __mod_timer+0xb4/0x100 Aug 9 20:58:27 be1 [c04019b1] schedule_timeout+0x51/0xa0 Aug 9 20:58:27 be1 [c011ff60] process_timeout+0x0/0x10 Aug 9 20:58:27 be1 [c012031f] msleep+0x2f/0x40 Aug 9 20:58:27 be1 [c02a3aca] radeon_probe_i2c_connector+0xaa/0x320 Aug 9 20:58:27 be1 [c02a1da2] radeon_probe_screens+0x482/0x5d0 Aug 9 20:58:27 be1 [c0298689] radeonfb_pci_register+0x309/0x570 ... Aug 9 20:58:27 be1 scheduling while atomic: swapper/0x0001/1 Aug 9 20:58:27 be1 [c0400ed9] schedule+0x589/0x640 Aug 9 20:58:27 be1 [c011f492] lock_timer_base+0x32/0x70 Aug 9 20:58:27 be1 [c011f584] __mod_timer+0xb4/0x100 Aug 9 20:58:27 be1 [c04019b1] schedule_timeout+0x51/0xa0 Aug 9 20:58:27 be1 [c011ff60] process_timeout+0x0/0x10 Aug 9 20:58:27 be1 [c012031f] msleep+0x2f/0x40 Aug 9 20:58:27 be1 [c02a3aca] radeon_probe_i2c_connector+0xaa/0x320 Aug 9 20:58:27 be1 [c02a1da2] radeon_probe_screens+0x482/0x5d0 Aug 9 20:58:27 be1 [c0298689] radeonfb_pci_register+0x309/0x570 Aug 9 20:58:27 be1 [c0281318] __pci_device_probe+0x48/0x60 -- It is still called paranoia when they really are out to get you. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Tue, 9 Aug 2005, Bodo Eggert wrote: On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote: On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote: The wrong values are constant across reboots (see my first mail), and I have a CRT. Can you tell me where the timing values are read? radeon_write_mode() programs the mode. The monitor timing infos are read by the various bits of code in radeon_monitor.c I'd be curious if you could identify what bit of code is misbehaving I added preempt_*able around radeon_probe_i2c_connector, and now I get the output from below and still no sync. Obviously you shouldn't msleep in preempt-disabled code. I'll try voluntary preemption, but that will at best hide the error. Update: voluntary preemption does not cause bad readings. -- Who is General Failure and why is he reading my disk? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote: > The wrong values are constant across reboots (see my first mail), and I > have a CRT. > > Can you tell me where the timing values are read? radeon_write_mode() programs the mode. The monitor timing infos are read by the various bits of code in radeon_monitor.c I'd be curious if you could identify what bit of code is misbehaving Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote: The wrong values are constant across reboots (see my first mail), and I have a CRT. Can you tell me where the timing values are read? radeon_write_mode() programs the mode. The monitor timing infos are read by the various bits of code in radeon_monitor.c I'd be curious if you could identify what bit of code is misbehaving Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 21:13:54, Kyle Moffett wrote: On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote: _However_ there is an unrelated problem with some panels, including some of the 17": The panel doesn't always "sync" properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it "catches". Hmm. This doesn't really fit as my issues are very reproducible. The behaviour under stock Debian 2.6.8 is identical during reboots and after fblevel 0 ; sleep X ; fblevel 15. Likewise, stock 2.6.11, 2.6.12.4, and 2.6.13-rc5, although I'm just getting back to testing things. Damn. As soon as I say this, I go back and am completely unable to make 2.6.13-rc5 reproduce the issue. *grumble* black magic *grumble* :-D. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote: I've got an LCD, and on mine it looks like every third pixel-line gets shifted about 32-64 pixels to the left, and they move with display refresh. My guess is that something is interrupting radeonfb during a critical time in display syncing and forcing the video card to wait too far into the next line before sending pixels. radeonfb is mostly inactive after it has setup the framebuffer and unless you actually draw something, in which case, accel code is called. _However_ there is an unrelated problem with some panels, including some of the 17": The panel doesn't always "sync" properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it "catches". Hmm. This doesn't really fit as my issues are very reproducible. The behaviour under stock Debian 2.6.8 is identical during reboots and after fblevel 0 ; sleep X ; fblevel 15. Likewise, stock 2.6.11, 2.6.12.4, and 2.6.13-rc5, although I'm just getting back to testing things. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 7 Aug 2005, Benjamin Herrenschmidt wrote: > On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote: > > On Sun, 7 Aug 2005, Kyle Moffett wrote: > > > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: > > > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb > > > > though ... Can you try something like wrapper radeon_write_mode() with > > > > preempt_disable()/preempt_enable() and tell me if it makes a > > > > difference ? > > > > Did not help. The values used to initialize the mode seem to be wrong. > > Copying the aty directory from 2.6.12 did not help, too. > > I don't see how PREEMPT could have any impact there unless you are > experiencing memory corruption... or one of those panels that have so > subtle timing issues that they sometimes don't sync depending on how > many flies you have in your room The wrong values are constant across reboots (see my first mail), and I have a CRT. Can you tell me where the timing values are read? -- E.G.G.E.R.T.: Electronic Guardian Generated for Efficient Repair and Troubleshooting -- http://www.brunching.com/toys/toy-cyborger.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote: > On Sun, 7 Aug 2005, Kyle Moffett wrote: > > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: > > > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb > > > though ... Can you try something like wrapper radeon_write_mode() with > > > preempt_disable()/preempt_enable() and tell me if it makes a > > > difference ? > > Did not help. The values used to initialize the mode seem to be wrong. > Copying the aty directory from 2.6.12 did not help, too. I don't see how PREEMPT could have any impact there unless you are experiencing memory corruption... or one of those panels that have so subtle timing issues that they sometimes don't sync depending on how many flies you have in your room Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 7 Aug 2005, Kyle Moffett wrote: > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb > > though ... Can you try something like wrapper radeon_write_mode() with > > preempt_disable()/preempt_enable() and tell me if it makes a > > difference ? Did not help. The values used to initialize the mode seem to be wrong. Copying the aty directory from 2.6.12 did not help, too. -- "Never tell the Platoon Sergeant you have nothing to do." -Unknown Marine Recruit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
> I'm having a similar issue with my shiny new 17" Powerbook G4. The > radeon chip works fine with framebuffer in 2.6.12.4 _with_ PREEMPT, > but not in 2.6.13-rc5 _with_ PREEMPT (configs are virtually identical). > I'll try your idea this afternoon when I get the chance. Note that PREEMPT is known to cause problems on ppc32 ... I'm not sure what's up yet. (Random SIGILLs/SEGVs in userland typically) > I wonder if perhaps some code in radeonfb is used under the BKL, which > is now preemptable (Or maybe an ordinary spinlock changed or went > away?), because I also set PREEMPT_BKL. radeonfb should only rely on the console semaphore > I've got an LCD, and on mine > it looks like every third pixel-line gets shifted about 32-64 pixels to > the left, and they move with display refresh. My guess is that > something is interrupting radeonfb during a critical time in display > syncing and forcing the video card to wait too far into the next line > before sending pixels. radeonfb is mostly inactive after it has setup the framebuffer and unless you actually draw something, in which case, accel code is called. _However_ there is an unrelated problem with some panels, including some of the 17": The panel doesn't always "sync" properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it "catches". > One other data point, I've seen something like this, except not nearly > as bad, is stock debian 2.6.8 vs. stock debian 2.6.11 on powerpc. The > former exhibits some similar (but not nearly as bad) symptoms. (Same > Powerbook), whereas 2.6.11 doesn't. In that case, neither has PREEMPT. > I'll run more tests this afternoon/evening, to try to track it down. > > Cheers, > Kyle Moffett > > -- > There are two ways of constructing a software design. One way is to > make it so > simple that there are obviously no deficiencies. And the other way is > to make > it so complicated that there are no obvious deficiencies. The first > method is > far more difficult. >-- C.A.R. Hoare > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote: On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote: On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working & non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... There were no changes in radeonfb.c, but I could trace to to CONFIG_PREEMPT. With _NONE, it works as expected. Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? I'm having a similar issue with my shiny new 17" Powerbook G4. The radeon chip works fine with framebuffer in 2.6.12.4 _with_ PREEMPT, but not in 2.6.13-rc5 _with_ PREEMPT (configs are virtually identical). I'll try your idea this afternoon when I get the chance. I wonder if perhaps some code in radeonfb is used under the BKL, which is now preemptable (Or maybe an ordinary spinlock changed or went away?), because I also set PREEMPT_BKL. I've got an LCD, and on mine it looks like every third pixel-line gets shifted about 32-64 pixels to the left, and they move with display refresh. My guess is that something is interrupting radeonfb during a critical time in display syncing and forcing the video card to wait too far into the next line before sending pixels. One other data point, I've seen something like this, except not nearly as bad, is stock debian 2.6.8 vs. stock debian 2.6.11 on powerpc. The former exhibits some similar (but not nearly as bad) symptoms. (Same Powerbook), whereas 2.6.11 doesn't. In that case, neither has PREEMPT. I'll run more tests this afternoon/evening, to try to track it down. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote: > On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote: > > > On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: > > > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. > > > 2.6.12 does not show this behaviour. > > > > I'm out of town at the moment, could you maybe diff radeonfb between > > working & non-working and CC me the diff ? I don't have my work stuff at > > hand not my kernel images so... > > There were no changes in radeonfb.c, but I could trace to to > CONFIG_PREEMPT. With _NONE, it works as expected. Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote: On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote: On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... There were no changes in radeonfb.c, but I could trace to to CONFIG_PREEMPT. With _NONE, it works as expected. Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote: On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote: On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... There were no changes in radeonfb.c, but I could trace to to CONFIG_PREEMPT. With _NONE, it works as expected. Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? I'm having a similar issue with my shiny new 17 Powerbook G4. The radeon chip works fine with framebuffer in 2.6.12.4 _with_ PREEMPT, but not in 2.6.13-rc5 _with_ PREEMPT (configs are virtually identical). I'll try your idea this afternoon when I get the chance. I wonder if perhaps some code in radeonfb is used under the BKL, which is now preemptable (Or maybe an ordinary spinlock changed or went away?), because I also set PREEMPT_BKL. I've got an LCD, and on mine it looks like every third pixel-line gets shifted about 32-64 pixels to the left, and they move with display refresh. My guess is that something is interrupting radeonfb during a critical time in display syncing and forcing the video card to wait too far into the next line before sending pixels. One other data point, I've seen something like this, except not nearly as bad, is stock debian 2.6.8 vs. stock debian 2.6.11 on powerpc. The former exhibits some similar (but not nearly as bad) symptoms. (Same Powerbook), whereas 2.6.11 doesn't. In that case, neither has PREEMPT. I'll run more tests this afternoon/evening, to try to track it down. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
I'm having a similar issue with my shiny new 17 Powerbook G4. The radeon chip works fine with framebuffer in 2.6.12.4 _with_ PREEMPT, but not in 2.6.13-rc5 _with_ PREEMPT (configs are virtually identical). I'll try your idea this afternoon when I get the chance. Note that PREEMPT is known to cause problems on ppc32 ... I'm not sure what's up yet. (Random SIGILLs/SEGVs in userland typically) I wonder if perhaps some code in radeonfb is used under the BKL, which is now preemptable (Or maybe an ordinary spinlock changed or went away?), because I also set PREEMPT_BKL. radeonfb should only rely on the console semaphore I've got an LCD, and on mine it looks like every third pixel-line gets shifted about 32-64 pixels to the left, and they move with display refresh. My guess is that something is interrupting radeonfb during a critical time in display syncing and forcing the video card to wait too far into the next line before sending pixels. radeonfb is mostly inactive after it has setup the framebuffer and unless you actually draw something, in which case, accel code is called. _However_ there is an unrelated problem with some panels, including some of the 17: The panel doesn't always sync properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it catches. One other data point, I've seen something like this, except not nearly as bad, is stock debian 2.6.8 vs. stock debian 2.6.11 on powerpc. The former exhibits some similar (but not nearly as bad) symptoms. (Same Powerbook), whereas 2.6.11 doesn't. In that case, neither has PREEMPT. I'll run more tests this afternoon/evening, to try to track it down. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 7 Aug 2005, Kyle Moffett wrote: On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? Did not help. The values used to initialize the mode seem to be wrong. Copying the aty directory from 2.6.12 did not help, too. -- Never tell the Platoon Sergeant you have nothing to do. -Unknown Marine Recruit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote: On Sun, 7 Aug 2005, Kyle Moffett wrote: On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? Did not help. The values used to initialize the mode seem to be wrong. Copying the aty directory from 2.6.12 did not help, too. I don't see how PREEMPT could have any impact there unless you are experiencing memory corruption... or one of those panels that have so subtle timing issues that they sometimes don't sync depending on how many flies you have in your room Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 7 Aug 2005, Benjamin Herrenschmidt wrote: On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote: On Sun, 7 Aug 2005, Kyle Moffett wrote: On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? Did not help. The values used to initialize the mode seem to be wrong. Copying the aty directory from 2.6.12 did not help, too. I don't see how PREEMPT could have any impact there unless you are experiencing memory corruption... or one of those panels that have so subtle timing issues that they sometimes don't sync depending on how many flies you have in your room The wrong values are constant across reboots (see my first mail), and I have a CRT. Can you tell me where the timing values are read? -- E.G.G.E.R.T.: Electronic Guardian Generated for Efficient Repair and Troubleshooting -- http://www.brunching.com/toys/toy-cyborger.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote: I've got an LCD, and on mine it looks like every third pixel-line gets shifted about 32-64 pixels to the left, and they move with display refresh. My guess is that something is interrupting radeonfb during a critical time in display syncing and forcing the video card to wait too far into the next line before sending pixels. radeonfb is mostly inactive after it has setup the framebuffer and unless you actually draw something, in which case, accel code is called. _However_ there is an unrelated problem with some panels, including some of the 17: The panel doesn't always sync properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it catches. Hmm. This doesn't really fit as my issues are very reproducible. The behaviour under stock Debian 2.6.8 is identical during reboots and after fblevel 0 ; sleep X ; fblevel 15. Likewise, stock 2.6.11, 2.6.12.4, and 2.6.13-rc5, although I'm just getting back to testing things. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 21:13:54, Kyle Moffett wrote: On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote: _However_ there is an unrelated problem with some panels, including some of the 17: The panel doesn't always sync properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it catches. Hmm. This doesn't really fit as my issues are very reproducible. The behaviour under stock Debian 2.6.8 is identical during reboots and after fblevel 0 ; sleep X ; fblevel 15. Likewise, stock 2.6.11, 2.6.12.4, and 2.6.13-rc5, although I'm just getting back to testing things. Damn. As soon as I say this, I go back and am completely unable to make 2.6.13-rc5 reproduce the issue. *grumble* black magic *grumble* :-D. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote: > On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: > > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. > > 2.6.12 does not show this behaviour. > > I'm out of town at the moment, could you maybe diff radeonfb between > working & non-working and CC me the diff ? I don't have my work stuff at > hand not my kernel images so... There were no changes in radeonfb.c, but I could trace to to CONFIG_PREEMPT. With _NONE, it works as expected. -- There is no such thing as an atheist in a foxhole. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote: On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... There were no changes in radeonfb.c, but I could trace to to CONFIG_PREEMPT. With _NONE, it works as expected. -- There is no such thing as an atheist in a foxhole. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. > 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working & non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... Thanks, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. dmesg from both systems, trimmed down: 2.6.13-rc5: PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 PCI: Using IRQ router VIA [1106/0686] at :00:07.0 PCI: Bridge: :00:01.0 IO window: c000-cfff MEM window: e800-e9ff PREFETCH window: d000-dfff PCI: Setting latency timer of device :00:01.0 to 64 Machine check exception polling timer started. ... Applying VIA southbridge workaround. radeonfb_pci_register BEGIN radeonfb (:01:00.0): Found 131072k of DDR 128 bits wide videoram radeonfb (:01:00.0): mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz radeonfb: PLL min 2 max 4 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 3 (DVI-I) : 3201 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type no found hStart = 694, hEnd = 757, hTotal = 795 vStart = 402, vEnd = 408, vTotal = 418 h_total_disp = 0x590062hsync_strt_wid = 0x8702c0 v_total_disp = 0x18f01a1 vsync_strt_wid = 0x860191 pixclock = 85925 freq = 1163 freq = 1666, PLL min = 2, PLL max = 4 ref_div = 12, ref_clk = 2700, output_freq = 26656 ref_div = 12, ref_clk = 2700, output_freq = 26656 post div = 0x5 fb_div = 0x76 ppll_div_3 = 0x50076 Console: switching to colour frame buffer device 90x25 radeonfb (:01:00.0): ATI Radeon AS radeonfb_pci_register END PCI: Enabling device :00:09.0 ( -> 0003) PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 fb: 3Dfx Banshee memory = 16384K Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Twister-K/KT133x/KM133 chipset agpgart: AGP aperture is 64M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 [drm] Initialized tdfx 1.0.0 20010216 on minor 0: [drm] Initialized radeon 1.16.0 20050311 on minor 1: 2.6.12: PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 PCI: Using IRQ router VIA [1106/0686] at :00:07.0 ... Applying VIA southbridge workaround. radeonfb_pci_register BEGIN radeonfb (:01:00.0): Found 131072k of DDR 128 bits wide videoram radeonfb (:01:00.0): mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz radeonfb: PLL min 2 max 4 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 3 (DVI-I) : 3201 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type no found hStart = 737, hEnd = 808, hTotal = 896 vStart = 401, vEnd = 404, vTotal = 417 h_total_disp = 0x59006fhsync_strt_wid = 0x8802eb v_total_disp = 0x18f01a0 vsync_strt_wid = 0x830190 pixclock = 38210 freq = 2617 freq = 2617, PLL min = 2, PLL max = 4 ref_div = 12, ref_clk = 2700, output_freq = 20936 ref_div = 12, ref_clk = 2700, output_freq = 20936 post div = 0x3 fb_div = 0x5d ppll_div_3 = 0x3005d Console: switching to colour frame buffer device 90x25 radeonfb (:01:00.0): ATI Radeon AS radeonfb_pci_register END ... fb: 3Dfx Banshee memory = 16384K Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Twister-K/KT133x/KM133 chipset agpgart: AGP aperture is 64M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 [drm] Initialized tdfx 1.0.0 20010216 on minor 0: [drm] Initialized radeon 1.16.0 20050311 on minor 1: -- Top 100 things you don't want the sysadmin to say: 10. I don't care what he says, I'm _NOT_ having it on _my_ network - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. dmesg from both systems, trimmed down: 2.6.13-rc5: PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 PCI: Using IRQ router VIA [1106/0686] at :00:07.0 PCI: Bridge: :00:01.0 IO window: c000-cfff MEM window: e800-e9ff PREFETCH window: d000-dfff PCI: Setting latency timer of device :00:01.0 to 64 Machine check exception polling timer started. ... Applying VIA southbridge workaround. radeonfb_pci_register BEGIN radeonfb (:01:00.0): Found 131072k of DDR 128 bits wide videoram radeonfb (:01:00.0): mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz radeonfb: PLL min 2 max 4 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 3 (DVI-I) : 3201 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type no found hStart = 694, hEnd = 757, hTotal = 795 vStart = 402, vEnd = 408, vTotal = 418 h_total_disp = 0x590062hsync_strt_wid = 0x8702c0 v_total_disp = 0x18f01a1 vsync_strt_wid = 0x860191 pixclock = 85925 freq = 1163 freq = 1666, PLL min = 2, PLL max = 4 ref_div = 12, ref_clk = 2700, output_freq = 26656 ref_div = 12, ref_clk = 2700, output_freq = 26656 post div = 0x5 fb_div = 0x76 ppll_div_3 = 0x50076 Console: switching to colour frame buffer device 90x25 radeonfb (:01:00.0): ATI Radeon AS radeonfb_pci_register END PCI: Enabling device :00:09.0 ( - 0003) PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 fb: 3Dfx Banshee memory = 16384K Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Twister-K/KT133x/KM133 chipset agpgart: AGP aperture is 64M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 [drm] Initialized tdfx 1.0.0 20010216 on minor 0: [drm] Initialized radeon 1.16.0 20050311 on minor 1: 2.6.12: PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 PCI: Using IRQ router VIA [1106/0686] at :00:07.0 ... Applying VIA southbridge workaround. radeonfb_pci_register BEGIN radeonfb (:01:00.0): Found 131072k of DDR 128 bits wide videoram radeonfb (:01:00.0): mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz radeonfb: PLL min 2 max 4 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 3 (DVI-I) : 3201 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type no found hStart = 737, hEnd = 808, hTotal = 896 vStart = 401, vEnd = 404, vTotal = 417 h_total_disp = 0x59006fhsync_strt_wid = 0x8802eb v_total_disp = 0x18f01a0 vsync_strt_wid = 0x830190 pixclock = 38210 freq = 2617 freq = 2617, PLL min = 2, PLL max = 4 ref_div = 12, ref_clk = 2700, output_freq = 20936 ref_div = 12, ref_clk = 2700, output_freq = 20936 post div = 0x3 fb_div = 0x5d ppll_div_3 = 0x3005d Console: switching to colour frame buffer device 90x25 radeonfb (:01:00.0): ATI Radeon AS radeonfb_pci_register END ... fb: 3Dfx Banshee memory = 16384K Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Twister-K/KT133x/KM133 chipset agpgart: AGP aperture is 64M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 [drm] Initialized tdfx 1.0.0 20010216 on minor 0: [drm] Initialized radeon 1.16.0 20050311 on minor 1: -- Top 100 things you don't want the sysadmin to say: 10. I don't care what he says, I'm _NOT_ having it on _my_ network - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... Thanks, Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
