Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Tue, Jun 24, 2008 at 6:30 PM, Jiří Paleček <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jun 2008 23:21:09 +0200, Alex Deucher <[EMAIL PROTECTED]> > wrote: > >> 2008/6/24 Jiri Palecek <[EMAIL PROTECTED]>: >>> >>> Last, would it be possible to make it also consider the maximum >>> pixelclock of >>> the CRT (for example, if you want the maximum pixelclock of the CRT, the >>> algorithm might get a higher frequency)? >> >> The algorithm is limited by the range of clocks that the pll is able >> to produce. Presumably mode validation has culled out any modes that >> the monitor is not able to handle. > > True, but I was thinking about cases where monitor can handle some (upper > limit) frequency, but the pll cannot produce it, and can produce some higher > frequency (which can be the best match). > Ah, I see, > PS: As I think about it once more, I think the line > > + max_ref_div = 2*max_ref_div - min_ref_div; > > is an error. I added it to ensure the algorithm wouldn't cut the range of > ref_divs if they are all valid, but now I think it's unneeded and > errorneous. Pushed! thanks. Alex
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Tue, 24 Jun 2008 23:21:09 +0200, Alex Deucher <[EMAIL PROTECTED]> wrote: 2008/6/24 Jiri Palecek <[EMAIL PROTECTED]>: Last, would it be possible to make it also consider the maximum pixelclock of the CRT (for example, if you want the maximum pixelclock of the CRT, the algorithm might get a higher frequency)? The algorithm is limited by the range of clocks that the pll is able to produce. Presumably mode validation has culled out any modes that the monitor is not able to handle. True, but I was thinking about cases where monitor can handle some (upper limit) frequency, but the pll cannot produce it, and can produce some higher frequency (which can be the best match). PS: As I think about it once more, I think the line + max_ref_div = 2*max_ref_div - min_ref_div; is an error. I added it to ensure the algorithm wouldn't cut the range of ref_divs if they are all valid, but now I think it's unneeded and errorneous. Regards Jiri Palecek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
2008/6/24 Jiri Palecek <[EMAIL PROTECTED]>:
> Tags: fixed-upstream
>
> On Monday 23 June 2008 21:55:21 Alex Deucher wrote:
>> On Sun, Jun 22, 2008 at 10:47 AM, Jiří Paleček <[EMAIL PROTECTED]> wrote:
>> > Hello,
>> >
>> > I prepared a new (better) version of the patch. Please consider applying
>> > it or otherwise fixing the bug.
>> >
>> > Some comments:
>> >
>> > The first patch causes abort instead of hangs when PLL computation fails.
>> >
>> > The second changes the algorithm so it doesn't miss any solution which
>> > might be better than current and finds a solution iff there is one.
>> >
>> > The third patch removes a condition which seems to be bogus for me - it
>> > cannot force pll->reference_div in the solution, but will probably poison
>> > the solution with a bad solution having good ref_div, for the next
>> > ref_div to override it with a better solution.
>>
>> Thanks for doing this!
>
> You're welcome. It wouldn't have been possible without your suggestion.
>
>> I've pushed a variation on this set of patches
>> to ati git master (72feaa37ea07620f5f2ead438dbc72a1c8883cd3). Please
>> let me know if you are still having problems.
>
> Looking (and working) good. Just some non-issues (at least for me):
>
> + if ((best_vco == 0 && error < best_error) ||
> + (best_vco != 0 &&
> +(error < best_error - 100 ||
> + (abs(error - best_error) < 100 && vco_diff <
> best_vco_diff {
>
> Is the "100" on the previous line 100 meaning 100 Hz, or a relict from the
> "10kHz-unit" times (meaning 1 MHz)?
100 Hz.
>
> + } else if (current_freq == freq) {
>
> Can this ever work? I mean, if the condition is true, error is zero so the
> previous "if" likely matched. How should the preference for low ref_divs work?
It only happens if the frequency is an exact match and there are
several possible combinations available. The error will be 0, but the
vco diff becomes the same as the vco so the first part of that "if"
block fails. It happens more often on newer cards as they have a
wider range of available dividers. For example on some of my cards,
there are quite a few matches for 65 Mhz (27 Mhz ref clk):
260, 6, 18 (feedback, ref, post)
650, 27, 10
715, 27, 11
260, 9, 12
650, 18, 15
130, 3, 18
etc.
For whatever reason, monitors seem to prefer the clk generated with a
lower ref divider, given these choices.
> For example, I have pixelclock of 175 MHz, which is
>
> 2.7 MHz/27(ref)*350(feedback)/2
>
> Would it be better to have
>
> 2.7 MHz/3*194/1 = 174.6 MHz?
>
hard to say. Generally, an exact match would be preferred. The flag
really is really just to help choose a preferred set of dividers when
you have more than one match. Monitors (especially DVI/HDMI) are
rather picky.
> Last, would it be possible to make it also consider the maximum pixelclock of
> the CRT (for example, if you want the maximum pixelclock of the CRT, the
> algorithm might get a higher frequency)?
The algorithm is limited by the range of clocks that the pll is able
to produce. Presumably mode validation has culled out any modes that
the monitor is not able to handle.
Alex
>
> I don't think any of these are important, they're just suggestions.
>
> Regards
>Jiri Palecek
>
>
>
>
>
>
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
Tags: fixed-upstream
On Monday 23 June 2008 21:55:21 Alex Deucher wrote:
> On Sun, Jun 22, 2008 at 10:47 AM, Jiří Paleček <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I prepared a new (better) version of the patch. Please consider applying
> > it or otherwise fixing the bug.
> >
> > Some comments:
> >
> > The first patch causes abort instead of hangs when PLL computation fails.
> >
> > The second changes the algorithm so it doesn't miss any solution which
> > might be better than current and finds a solution iff there is one.
> >
> > The third patch removes a condition which seems to be bogus for me - it
> > cannot force pll->reference_div in the solution, but will probably poison
> > the solution with a bad solution having good ref_div, for the next
> > ref_div to override it with a better solution.
>
> Thanks for doing this!
You're welcome. It wouldn't have been possible without your suggestion.
> I've pushed a variation on this set of patches
> to ati git master (72feaa37ea07620f5f2ead438dbc72a1c8883cd3). Please
> let me know if you are still having problems.
Looking (and working) good. Just some non-issues (at least for me):
+ if ((best_vco == 0 && error < best_error) ||
+ (best_vco != 0 &&
+(error < best_error - 100 ||
+ (abs(error - best_error) < 100 && vco_diff <
best_vco_diff {
Is the "100" on the previous line 100 meaning 100 Hz, or a relict from the
"10kHz-unit" times (meaning 1 MHz)?
+ } else if (current_freq == freq) {
Can this ever work? I mean, if the condition is true, error is zero so the
previous "if" likely matched. How should the preference for low ref_divs work?
For example, I have pixelclock of 175 MHz, which is
2.7 MHz/27(ref)*350(feedback)/2
Would it be better to have
2.7 MHz/3*194/1 = 174.6 MHz?
Last, would it be possible to make it also consider the maximum pixelclock of
the CRT (for example, if you want the maximum pixelclock of the CRT, the
algorithm might get a higher frequency)?
I don't think any of these are important, they're just suggestions.
Regards
Jiri Palecek
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Sun, Jun 22, 2008 at 10:47 AM, Jiří Paleček <[EMAIL PROTECTED]> wrote: > Hello, > > I prepared a new (better) version of the patch. Please consider applying it > or otherwise fixing the bug. > > Some comments: > > The first patch causes abort instead of hangs when PLL computation fails. > > The second changes the algorithm so it doesn't miss any solution which might > be better than current and finds a solution iff there is one. > > The third patch removes a condition which seems to be bogus for me - it > cannot force pll->reference_div in the solution, but will probably poison > the solution with a bad solution having good ref_div, for the next ref_div > to override it with a better solution. Thanks for doing this! I've pushed a variation on this set of patches to ati git master (72feaa37ea07620f5f2ead438dbc72a1c8883cd3). Please let me know if you are still having problems. Thanks, Alex
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
Hello, I prepared a new (better) version of the patch. Please consider applying it or otherwise fixing the bug. Some comments: The first patch causes abort instead of hangs when PLL computation fails. The second changes the algorithm so it doesn't miss any solution which might be better than current and finds a solution iff there is one. The third patch removes a condition which seems to be bogus for me - it cannot force pll->reference_div in the solution, but will probably poison the solution with a bad solution having good ref_div, for the next ref_div to override it with a better solution. Regards Jiri Palecek binehU0bcrQTP.bin Description: Binary data binj2NRIpka1q.bin Description: Binary data binKVyGucXgNA.bin Description: Binary data
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Thu, 06 Mar 2008 01:58:38 +0100, Alex Deucher <[EMAIL PROTECTED]> wrote: On Wed, Mar 5, 2008 at 11:26 AM, Jiří Paleček <[EMAIL PROTECTED]> wrote: Hello, sorry that I mystified you in the last email, it seems that I've done the test with a different version if the driver (not 6.8.0). The correct results are: 82 Hz works, 84 and 86 not. The base problem here is that the pll algorithm is not able to find clock as close as it would like to the desired frequency so it fails and you end up with an invalid divders programmed to the hw which causes the hang. I guess there are two options: widen the error range or try a slightly different clock if it fails to find valid dividers. Ahuh, so you say that the frequencies in the range 175 MHz - 200 MHz are impossible to create on my card, so 184 MHz fails. Well, it really seems so. But why not choose the 175 MHz then, and do it like that (see patch). You may wanna optimize it a bit, but it starts on my machine so it may be unnecessary. Regards Jiri Palecek radeon.patch Description: Binary data
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Wed, Mar 5, 2008 at 11:26 AM, Jiří Paleček <[EMAIL PROTECTED]> wrote: > Hello, > > sorry that I mystified you in the last email, it seems that I've done the > test with a different version if the driver (not 6.8.0). The correct > results are: 82 Hz works, 84 and 86 not. The base problem here is that the pll algorithm is not able to find clock as close as it would like to the desired frequency so it fails and you end up with an invalid divders programmed to the hw which causes the hang. I guess there are two options: widen the error range or try a slightly different clock if it fails to find valid dividers. Alex
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Thu, 28 Feb 2008 01:44:28 +0100, Alex Deucher <[EMAIL PROTECTED]> wrote: On Wed, Feb 27, 2008 at 7:01 PM, Jiří Paleček <[EMAIL PROTECTED]> wrote: On Wed, 27 Feb 2008 23:32:24 +0100, Alex Deucher <[EMAIL PROTECTED]> wrote: > 2008/2/27 Jiri Palecek <[EMAIL PROTECTED]>: >> >> On Monday 25 February 2008 18:18:32 Alex Deucher wrote: >> > There's something about 1400x1050 mode that the driver doesn't like. >> > if you remove the preferred mode from your monitor section, does the >> > server come up? You might want to try another modeline for >> 1400x1050. >> >> Indeed, the server started with the "PreferredMode" commented out. >> However, >> changing the mode to this mode hang the computer. >> >> What other modeline do you mean? I copied this one from earlier xorg, >> where it >> was autodetected. > > try cvt: > > $ cvt 1400 1050 60 > # 1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz > Modeline "1400x1050_60.00" 121.75 1400 1488 1632 1864 1050 1053 > 1057 1089 -hsync +vsync > > $ cvt 1400 1050 75 > # 1400x1050 74.87 Hz (CVT 1.47M3) hsync: 82.28 kHz; pclk: 156.00 MHz > Modeline "1400x1050_75.00" 156.00 1400 1504 1648 1896 1050 1053 > 1057 1099 -hsync +vsync OK. So I tried this: Section "Monitor" Identifier "Generic Monitor" Option "DPMS" HorizSync 30-95 VertRefresh 50-160 Modeline"1400x1050" 184.00 1400 1464 1656 1960 1050 1051 1054 1100 +hsync +vsync # 1400x1050 84.96 Hz (CVT 1.47M3) hsync: 93.88 kHz; pclk: 179.50 MHz Modeline "1400x1050_85.00" 179.50 1400 1512 1656 1912 1050 1053 1057 1105 -hsync +vsync # 1400x1050 74.87 Hz (CVT 1.47M3) hsync: 82.28 kHz; pclk: 156.00 MHz Modeline "1400x1050_75.00" 156.00 1400 1504 1648 1896 1050 1053 1057 1099 -hsync +vsync # 1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz Modeline "1400x1050_60.00" 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync Option "PreferredMode" "1400x1050" EndSection The 60 an 75 Hz variants work under 6.8.0, the 85 Hz doesn't. Strange. you might try tweaking it slightly, maybe 87 Hz, etc. OK. From these modes # 1400x1050 81.89 Hz (CVT) hsync: 90.32 kHz; pclk: 171.25 MHz Modeline "1400x1050_82.00" 171.25 1400 1504 1648 1896 1050 1053 1057 1103 -hsync +vsync # 1400x1050 86.89 Hz (CVT) hsync: 96.10 kHz; pclk: 183.75 MHz Modeline "1400x1050_87.00" 183.75 1400 1512 1656 1912 1050 1053 1057 1106 -hsync +vsync # 1400x1050 83.89 Hz (CVT) hsync: 92.70 kHz; pclk: 175.75 MHz Modeline "1400x1050_84.00" 175.75 1400 1504 1648 1896 1050 1053 1057 1105 -hsync +vsync 87 Hz correctly fails (96 kHz is too much for a horizontal refresh), the other two work. Regards Jiri Palecek
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Wed, Feb 27, 2008 at 7:01 PM, Jiří Paleček <[EMAIL PROTECTED]> wrote: > On Wed, 27 Feb 2008 23:32:24 +0100, Alex Deucher <[EMAIL PROTECTED]> > wrote: > > > > 2008/2/27 Jiri Palecek <[EMAIL PROTECTED]>: > >> > >> On Monday 25 February 2008 18:18:32 Alex Deucher wrote: > > >> > There's something about 1400x1050 mode that the driver doesn't like. > >> > if you remove the preferred mode from your monitor section, does the > >> > server come up? You might want to try another modeline for > >> 1400x1050. > >> > >> Indeed, the server started with the "PreferredMode" commented out. > >> However, > >> changing the mode to this mode hang the computer. > >> > >> What other modeline do you mean? I copied this one from earlier xorg, > >> where it > >> was autodetected. > > > > try cvt: > > > > $ cvt 1400 1050 60 > > # 1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz > > Modeline "1400x1050_60.00" 121.75 1400 1488 1632 1864 1050 1053 > > 1057 1089 -hsync +vsync > > > > $ cvt 1400 1050 75 > > # 1400x1050 74.87 Hz (CVT 1.47M3) hsync: 82.28 kHz; pclk: 156.00 MHz > > Modeline "1400x1050_75.00" 156.00 1400 1504 1648 1896 1050 1053 > > 1057 1099 -hsync +vsync > > OK. So I tried this: > > Section "Monitor" > Identifier "Generic Monitor" > Option "DPMS" > HorizSync 30-95 > VertRefresh 50-160 > Modeline"1400x1050" 184.00 1400 1464 1656 1960 1050 > 1051 1054 1100 +hsync +vsync > # 1400x1050 84.96 Hz (CVT 1.47M3) hsync: 93.88 kHz; pclk: 179.50 MHz > Modeline "1400x1050_85.00" 179.50 1400 1512 1656 1912 1050 1053 1057 > 1105 -hsync +vsync > > # 1400x1050 74.87 Hz (CVT 1.47M3) hsync: 82.28 kHz; pclk: 156.00 MHz > Modeline "1400x1050_75.00" 156.00 1400 1504 1648 1896 1050 1053 1057 > 1099 -hsync +vsync > > # 1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz > Modeline "1400x1050_60.00" 121.75 1400 1488 1632 1864 1050 1053 1057 > 1089 -hsync +vsync > Option "PreferredMode" "1400x1050" > EndSection > > The 60 an 75 Hz variants work under 6.8.0, the 85 Hz doesn't. Strange. you might try tweaking it slightly, maybe 87 Hz, etc. Alex
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Wed, 27 Feb 2008 23:32:24 +0100, Alex Deucher <[EMAIL PROTECTED]> wrote: 2008/2/27 Jiri Palecek <[EMAIL PROTECTED]>: On Monday 25 February 2008 18:18:32 Alex Deucher wrote: > There's something about 1400x1050 mode that the driver doesn't like. > if you remove the preferred mode from your monitor section, does the > server come up? You might want to try another modeline for 1400x1050. Indeed, the server started with the "PreferredMode" commented out. However, changing the mode to this mode hang the computer. What other modeline do you mean? I copied this one from earlier xorg, where it was autodetected. try cvt: $ cvt 1400 1050 60 # 1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz Modeline "1400x1050_60.00" 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync $ cvt 1400 1050 75 # 1400x1050 74.87 Hz (CVT 1.47M3) hsync: 82.28 kHz; pclk: 156.00 MHz Modeline "1400x1050_75.00" 156.00 1400 1504 1648 1896 1050 1053 1057 1099 -hsync +vsync OK. So I tried this: Section "Monitor" Identifier "Generic Monitor" Option "DPMS" HorizSync 30-95 VertRefresh 50-160 Modeline"1400x1050" 184.00 1400 1464 1656 1960 1050 1051 1054 1100 +hsync +vsync # 1400x1050 84.96 Hz (CVT 1.47M3) hsync: 93.88 kHz; pclk: 179.50 MHz Modeline "1400x1050_85.00" 179.50 1400 1512 1656 1912 1050 1053 1057 1105 -hsync +vsync # 1400x1050 74.87 Hz (CVT 1.47M3) hsync: 82.28 kHz; pclk: 156.00 MHz Modeline "1400x1050_75.00" 156.00 1400 1504 1648 1896 1050 1053 1057 1099 -hsync +vsync # 1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz Modeline "1400x1050_60.00" 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync Option "PreferredMode" "1400x1050" EndSection The 60 an 75 Hz variants work under 6.8.0, the 85 Hz doesn't. Regards Jiri Palecek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
2008/2/27 Jiri Palecek <[EMAIL PROTECTED]>: > > On Monday 25 February 2008 18:18:32 Alex Deucher wrote: > > 2008/2/21 Jiří Paleček <[EMAIL PROTECTED]>: > > > On Wed, 20 Feb 2008 22:09:04 +0100, Brice Goglin > > > > > > <[EMAIL PROTECTED]> wrote: > > > > Jiří Paleček wrote: > > > >> Sorry, it was my fault. I was doing it in a local copy of git, and > > > >> there was a new include directory added which I didn't have in the > > > >> makefiles... autoreconf did the job. Anyway, the patch didn't help. > > > > > > > > Can you send the corresponding log? Alex Deucher (the author of the > > > > patch) wanted to see it. > > > > > > Yes. > > > > There's something about 1400x1050 mode that the driver doesn't like. > > if you remove the preferred mode from your monitor section, does the > > server come up? You might want to try another modeline for 1400x1050. > > Indeed, the server started with the "PreferredMode" commented out. However, > changing the mode to this mode hang the computer. > > What other modeline do you mean? I copied this one from earlier xorg, where > it > was autodetected. try cvt: $ cvt 1400 1050 60 # 1400x1050 59.98 Hz (CVT 1.47M3) hsync: 65.32 kHz; pclk: 121.75 MHz Modeline "1400x1050_60.00" 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync $ cvt 1400 1050 75 # 1400x1050 74.87 Hz (CVT 1.47M3) hsync: 82.28 kHz; pclk: 156.00 MHz Modeline "1400x1050_75.00" 156.00 1400 1504 1648 1896 1050 1053 1057 1099 -hsync +vsync etc. Alex
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Monday 25 February 2008 18:18:32 Alex Deucher wrote: > 2008/2/21 Jiří Paleček <[EMAIL PROTECTED]>: > > On Wed, 20 Feb 2008 22:09:04 +0100, Brice Goglin > > > > <[EMAIL PROTECTED]> wrote: > > > Jiří Paleček wrote: > > >> Sorry, it was my fault. I was doing it in a local copy of git, and > > >> there was a new include directory added which I didn't have in the > > >> makefiles... autoreconf did the job. Anyway, the patch didn't help. > > > > > > Can you send the corresponding log? Alex Deucher (the author of the > > > patch) wanted to see it. > > > > Yes. > > There's something about 1400x1050 mode that the driver doesn't like. > if you remove the preferred mode from your monitor section, does the > server come up? You might want to try another modeline for 1400x1050. Indeed, the server started with the "PreferredMode" commented out. However, changing the mode to this mode hang the computer. What other modeline do you mean? I copied this one from earlier xorg, where it was autodetected. Regards Jiri Palecek
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
2008/2/21 Jiří Paleček <[EMAIL PROTECTED]>: > On Wed, 20 Feb 2008 22:09:04 +0100, Brice Goglin > > <[EMAIL PROTECTED]> wrote: > > > > Jiří Paleček wrote: > >> Sorry, it was my fault. I was doing it in a local copy of git, and > >> there was a new include directory added which I didn't have in the > >> makefiles... autoreconf did the job. Anyway, the patch didn't help. > > > > Can you send the corresponding log? Alex Deucher (the author of the > > patch) wanted to see it. > > Yes. There's something about 1400x1050 mode that the driver doesn't like. if you remove the preferred mode from your monitor section, does the server come up? You might want to try another modeline for 1400x1050. Alex
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
Jiří Paleček wrote: > Sorry, it was my fault. I was doing it in a local copy of git, and > there was a new include directory added which I didn't have in the > makefiles... autoreconf did the job. Anyway, the patch didn't help. Can you send the corresponding log? Alex Deucher (the author of the patch) wanted to see it. Thanks, Brice
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Wed, 20 Feb 2008 20:07:09 +0100, Brice Goglin <[EMAIL PROTECTED]> wrote: Jiří Paleček wrote: On Tue, 19 Feb 2008 16:36:35 +0100, Brice Goglin <[EMAIL PROTECTED]> wrote: On Sat, Feb 16, 2008 at 11:30:22PM +0100, Ji??í Pale??ek wrote: OK. The bad commit is commit f3d2ec3a5ae61215c792018320158750e7aa937c Author: Alex Deucher <[EMAIL PROTECTED](none)> Date: Tue Dec 11 11:57:27 2007 -0500 RADEON: rewrite PLL computation Can you try the patch at http://www.botchco.com/alex/xorg/debian465864.diff ? Sorry, I cannot compile it. The revisions that have legacy_crtc.c fail with "undefined symbol ATOM_xxx" (among others). I just did apt-get source xserver-xorg-video-ati -t unstable ... patch -p1 < ../debian465864.diff debuild and it compiled 6.8.0+patch fine. Can you send the exact error messages that you got? Sorry, it was my fault. I was doing it in a local copy of git, and there was a new include directory added which I didn't have in the makefiles... autoreconf did the job. Anyway, the patch didn't help. Regards Jiri Palecek
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Tue, 19 Feb 2008 16:36:35 +0100, Brice Goglin <[EMAIL PROTECTED]> wrote: On Sat, Feb 16, 2008 at 11:30:22PM +0100, Ji??í Pale??ek wrote: OK. The bad commit is commit f3d2ec3a5ae61215c792018320158750e7aa937c Author: Alex Deucher <[EMAIL PROTECTED](none)> Date: Tue Dec 11 11:57:27 2007 -0500 RADEON: rewrite PLL computation Can you try the patch at http://www.botchco.com/alex/xorg/debian465864.diff ? Sorry, I cannot compile it. The revisions that have legacy_crtc.c fail with "undefined symbol ATOM_xxx" (among others). I have xserver-xorg-dev 2:1.4.1~git20080131-1 Regards Jiri Palecek
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
Jiří Paleček wrote: > On Tue, 19 Feb 2008 16:36:35 +0100, Brice Goglin > <[EMAIL PROTECTED]> wrote: > >> On Sat, Feb 16, 2008 at 11:30:22PM +0100, Ji??í Pale??ek wrote: >>> OK. The bad commit is >>> >>> commit f3d2ec3a5ae61215c792018320158750e7aa937c >>> Author: Alex Deucher <[EMAIL PROTECTED](none)> >>> Date: Tue Dec 11 11:57:27 2007 -0500 >>> >>> RADEON: rewrite PLL computation >> >> Can you try the patch at >> http://www.botchco.com/alex/xorg/debian465864.diff ? > > Sorry, I cannot compile it. The revisions that have legacy_crtc.c fail > with "undefined symbol ATOM_xxx" (among others). I just did apt-get source xserver-xorg-video-ati -t unstable ... patch -p1 < ../debian465864.diff debuild and it compiled 6.8.0+patch fine. Can you send the exact error messages that you got? Brice
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Sat, Feb 16, 2008 at 11:30:22PM +0100, Ji??í Pale??ek wrote: > OK. The bad commit is > > commit f3d2ec3a5ae61215c792018320158750e7aa937c > Author: Alex Deucher <[EMAIL PROTECTED](none)> > Date: Tue Dec 11 11:57:27 2007 -0500 > > RADEON: rewrite PLL computation Can you try the patch at http://www.botchco.com/alex/xorg/debian465864.diff ? Thanks, Brice
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
On Fri, 15 Feb 2008 19:32:37 +0100, Brice Goglin <[EMAIL PROTECTED]> wrote: Jiří Paleček wrote: Package: xserver-xorg-video-ati Version: 1:6.7.198~git20080203.f65e8dfa-1 Severity: important Hello when I start X, the computer freezes and doesn't react even to magic SysRq. This happens with -video-ati versions > 6.7.196. The log and the diff to normal startup is attached. I tried option "BusType" "PCI" without positive effect. The biggest candidate from such a problem appearing after 6.7.196 would have been AGP mode problems for sure. But if BusType PCI or AGPMode 4/8 doesn't help, there's something else. Since we have plenty of snapshots available in snapshot.debian.net, and git-bisect'ing between should be very fast, could you try to locate the breaking commit? OK. The bad commit is commit f3d2ec3a5ae61215c792018320158750e7aa937c Author: Alex Deucher <[EMAIL PROTECTED](none)> Date: Tue Dec 11 11:57:27 2007 -0500 RADEON: rewrite PLL computation Algorithm adapted from BeOS radeon driver with some tweaks by me. Actually calulate and use the reference divider rather than using the bios default. Also, always calculate the PLL, rather than falling back to bios dividers. This should fix bugs 12913, 13590, 13533, possibly others. Regards Jiri Palecek
Bug#465864: xserver-xorg-video-ati: xserver freezes the computer on startup
Jiří Paleček wrote: > Package: xserver-xorg-video-ati > Version: 1:6.7.198~git20080203.f65e8dfa-1 > Severity: important > > Hello > > when I start X, the computer freezes and doesn't react even to magic > SysRq. This happens with -video-ati versions > 6.7.196. > > The log and the diff to normal startup is attached. I tried option > "BusType" "PCI" without positive effect. The biggest candidate from such a problem appearing after 6.7.196 would have been AGP mode problems for sure. But if BusType PCI or AGPMode 4/8 doesn't help, there's something else. Since we have plenty of snapshots available in snapshot.debian.net, and git-bisect'ing between should be very fast, could you try to locate the breaking commit? Brice
