From: Bodo Eggert <hidden> Date: 2005-08-04 22:05:29
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 0000:01:00.0
PCI: Using IRQ router VIA [1106/0686] at 0000:00:07.0
PCI: Bridge: 0000:00:01.0
IO window: c000-cfff
MEM window: e8000000-e9ffffff
PREFETCH window: d0000000-dfffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
Machine check exception polling timer started.
...
Applying VIA southbridge workaround.
radeonfb_pci_register BEGIN
radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000: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 20000 max 40000
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 = 0x590062 hsync_strt_wid = 0x8702c0
v_total_disp = 0x18f01a1 vsync_strt_wid = 0x860191
pixclock = 85925
freq = 1163
freq = 1666, PLL min = 20000, PLL max = 40000
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 (0000:01:00.0): ATI Radeon AS
radeonfb_pci_register END
PCI: Enabling device 0000:00:09.0 (0000 -> 0003)
PCI: Found IRQ 5 for device 0000:00:09.0
PCI: Sharing IRQ 5 with 0000: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 @ 0xe0000000
[drm] Initialized drm 1.0.0 20040925
PCI: Found IRQ 5 for device 0000:00:09.0
PCI: Sharing IRQ 5 with 0000: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 0000:01:00.0
PCI: Using IRQ router VIA [1106/0686] at 0000:00:07.0
...
Applying VIA southbridge workaround.
radeonfb_pci_register BEGIN
radeonfb (0000:01:00.0): Found 131072k of DDR 128 bits wide videoram
radeonfb (0000: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 20000 max 40000
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 = 0x59006f hsync_strt_wid = 0x8802eb
v_total_disp = 0x18f01a0 vsync_strt_wid = 0x830190
pixclock = 38210
freq = 2617
freq = 2617, PLL min = 20000, PLL max = 40000
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 (0000: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 @ 0xe0000000
[drm] Initialized drm 1.0.0 20040925
PCI: Found IRQ 5 for device 0000:00:09.0
PCI: Sharing IRQ 5 with 0000: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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-08-04 22:53:44
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.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Bodo Eggert <hidden> Date: 2005-08-05 17:38:39
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
quoted
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.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-08-07 07:55:52
On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote:
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
quoted
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
quoted
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.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote:
quoted
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
quoted
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
quoted
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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-08-07 16:18:31
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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Bodo Eggert <hidden> Date: 2005-08-07 17:25:24
On Sun, 7 Aug 2005, Kyle Moffett wrote:
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
quoted
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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-08-07 21:53:07
On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote:
On Sun, 7 Aug 2005, Kyle Moffett wrote:
quoted
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
quoted
quoted
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.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Bodo Eggert <hidden> Date: 2005-08-08 00:07:02
On Sun, 7 Aug 2005, Benjamin Herrenschmidt wrote:
On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote:
quoted
On Sun, 7 Aug 2005, Kyle Moffett wrote:
quoted
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
quoted
quoted
quoted
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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote:
quoted
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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote:
quoted
_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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-08-08 08:25:08
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.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Bodo Eggert <hidden> Date: 2005-08-09 20:13:08
On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote:
On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
quoted
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/0x00000001/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.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
From: Bodo Eggert <hidden> Date: 2005-08-09 23:14:08
On Tue, 9 Aug 2005, Bodo Eggert wrote:
On Mon, 8 Aug 2005, Benjamin Herrenschmidt wrote:
quoted
On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
quoted
quoted
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?
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf