9:05 a.m.
Compose started at Thu May 28 06:15:03 UTC 2009
Updated Packages:
kernel-2.6.29.4-167.fc11
------------------------
* Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-164
- drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855,
and 865. It can be forced on with i915.modeset=1 boot parameter.
* Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-165
- Enable KMS/gem on I865.
- drm-no-gem-on-i8xx.patch: Remove I865 so GEM will be enabled.
- drm-intel-disable-kms-i8xx.patch: Enable KMS on I865.
- Two fixes from Eric Anholt to fix i8x5:
drm-i915-apply-a-big-hammer-to-865-gem-object.patch
drm-i915-fix-tiling-pitch.patch
* Wed May 27 2009 Kristian Høgsberg <krh(a)redhat.com> - 2.6.29.4-166
- Add drm-intel-set-domain-on-fault.patch to fix random gem object
corruption when swapping (495323 and probably others).
- Enable kms on 845 and 855 as well, Erics tiling patch should fix
those too.
* Wed May 27 2009 Kristian Høgsberg <krh(a)madara.bos.redhat.com> - 2.6.4.167
- Actually disable drm-intel-disable-kms-i8xx.patch.
* Tue May 26 2009 Ben Skeggs <bskeggs(a)redhat.com> 2.6.29.4-163
- drm-nouveau.patch: fix sor dpms (rh#501877)
Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 1
Broken deps for ppc64
----------------------------------------------------------
cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7
12:23 a.m.
On 05/28/2009 07:35 PM, Rawhide Report wrote:
Compose started at Thu May 28 06:15:03 UTC 2009
Updated Packages:
kernel-2.6.29.4-167.fc11
------------------------
* Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-164
- drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855,
and 865. It can be forced on with i915.modeset=1 boot parameter.
* Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-165
- Enable KMS/gem on I865.
- drm-no-gem-on-i8xx.patch: Remove I865 so GEM will be enabled.
- drm-intel-disable-kms-i8xx.patch: Enable KMS on I865.
- Two fixes from Eric Anholt to fix i8x5:
drm-i915-apply-a-big-hammer-to-865-gem-object.patch
drm-i915-fix-tiling-pitch.patch
* Wed May 27 2009 Kristian Høgsberg <krh(a)redhat.com> - 2.6.29.4-166
- Add drm-intel-set-domain-on-fault.patch to fix random gem object
corruption when swapping (495323 and probably others).
- Enable kms on 845 and 855 as well, Erics tiling patch should fix
those too.
* Wed May 27 2009 Kristian Høgsberg <krh(a)madara.bos.redhat.com> - 2.6.4.167
- Actually disable drm-intel-disable-kms-i8xx.patch.
Seems a lot of back and forth. What's going on? Can someone tell me the
final state of expected behaviour is various cards? It would be useful
to point users to this.
Rahul
11:11 a.m.
On Fri, 2009-05-29 at 10:53 +0530, Rahul Sundaram wrote:
On 05/28/2009 07:35 PM, Rawhide Report wrote:
> Compose started at Thu May 28 06:15:03 UTC 2009
>
> Updated Packages:
>
> kernel-2.6.29.4-167.fc11
> ------------------------
> * Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-164
> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855,
> and 865. It can be forced on with i915.modeset=1 boot parameter.
>
> * Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-165
> - Enable KMS/gem on I865.
> - drm-no-gem-on-i8xx.patch: Remove I865 so GEM will be enabled.
> - drm-intel-disable-kms-i8xx.patch: Enable KMS on I865.
> - Two fixes from Eric Anholt to fix i8x5:
> drm-i915-apply-a-big-hammer-to-865-gem-object.patch
> drm-i915-fix-tiling-pitch.patch
>
> * Wed May 27 2009 Kristian Høgsberg <krh(a)redhat.com> - 2.6.29.4-166
> - Add drm-intel-set-domain-on-fault.patch to fix random gem object
> corruption when swapping (495323 and probably others).
> - Enable kms on 845 and 855 as well, Erics tiling patch should fix
> those too.
>
> * Wed May 27 2009 Kristian Høgsberg <krh(a)madara.bos.redhat.com> - 2.6.4.167
> - Actually disable drm-intel-disable-kms-i8xx.patch.
Seems a lot of back and forth. What's going on? Can someone tell me the
final state of expected behaviour is various cards? It would be useful
to point users to this.
I was going to explain yesterday and then decided I shouldn't - guess I
should have :)
This mostly relates to bug 502077, filed on May 21st (so quite late in
cycle). Intel i865 cards were experiencing random hangs with kernel
modesetting enabled (which was the default). There was a single
unconfirmed report of the same issue affect i845, and another single
unconfirmed report for i855.
Since it was so late in the cycle and it felt like every time we zapped
one KMS bug, another popped up to take its place, QA team / RelEng, at a
blocker meeting, recommended disabling KMS for i865 chips. Kyle came in
to make this change, and he (along with the other intel/kernel devs)
decided to disable KMS for i845 and i855 as well because of the other
reports (I think they were under the impression it was more certain that
i845 / i855 also suffered from this issue). That's -164.
Kristian wasn't happy with this approach, and preferred to try and fix
the real bug. Together with Kyle, he identified a potential fix, and
built a kernel with that fix included and KMS re-enabled on i865 (that's
-165) and got testing for it. A couple of i865 users confirmed that it
fixed their issue.
We then discussed it a bit further and I explained that we'd only one
one unconfirmed report of hangs for both i845 and i855, and I'd actually
actively asked other users of those chips if they were experiencing
hangs and they'd said no. So we decided that, as it was unclear whether
i845 and i855 had really ever suffered from this exact issue, and the
patch should fix it for them as well as i865 even if they did, we should
go ahead and re-enable KMS for all three chipsets (that's -166 and
-167).
So, from 163 to 167, the sum total of changes was really just the
addition of the patch to fix the hanging problem (and also
drm-intel-set-domain-on-fault.patch , which is for another bug that we
considered critical).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:47 a.m.
On 05/29/2009 09:41 PM, Adam Williamson wrote:
On Fri, 2009-05-29 at 10:53 +0530, Rahul Sundaram wrote:
>> kernel-2.6.29.4-167.fc11
>> ------------------------
>> * Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-164
>> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855,
>> and 865. It can be forced on with i915.modeset=1 boot parameter.
So, from 163 to 167, the sum total of changes was really just the
addition of the patch to fix the hanging problem (and also
drm-intel-set-domain-on-fault.patch , which is for another bug that we
considered critical).
The last change on 167 says that KMS is disabled on these chipsets. You
seem to be saying it is actually enabled by default?
Rahul
11:53 a.m.
Rahul Sundaram wrote:
>>> * Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com>
2.6.29.4-164
>>> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855,
>>> and 865. It can be forced on with i915.modeset=1 boot parameter.
The last change on 167 says that KMS is disabled on these chipsets. You
seem to be saying it is actually enabled by default?
That's not the last change, it's the change in -164. The changelog is not
properly ordered.
Kevin Kofler
12:22 p.m.
On 05/29/2009 10:23 PM, Kevin Kofler wrote:
Rahul Sundaram wrote:
>>>> * Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-164
>>>> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855,
>>>> and 865. It can be forced on with i915.modeset=1 boot parameter.
>
> The last change on 167 says that KMS is disabled on these chipsets. You
> seem to be saying it is actually enabled by default?
That's not the last change, it's the change in -164. The changelog is not
properly ordered.
Ugh. That explains my confusion. Thanks.
Rahul
12:11 p.m.
On Fri, 2009-05-29 at 22:17 +0530, Rahul Sundaram wrote:
On 05/29/2009 09:41 PM, Adam Williamson wrote:
> On Fri, 2009-05-29 at 10:53 +0530, Rahul Sundaram wrote:
>>> kernel-2.6.29.4-167.fc11
>>> ------------------------
>>> * Wed May 27 2009 Kyle McMartin <kyle(a)redhat.com> 2.6.29.4-164
>>> - drm-intel-disable-kms-i8xx.patch: disable KMS by default on 845, 855,
>>> and 865. It can be forced on with i915.modeset=1 boot parameter.
>
> So, from 163 to 167, the sum total of changes was really just the
> addition of the patch to fix the hanging problem (and also
> drm-intel-set-domain-on-fault.patch , which is for another bug that we
> considered critical).
The last change on 167 says that KMS is disabled on these chipsets. You
seem to be saying it is actually enabled by default?
As Kevin says, the changelog isn't well ordered - note the
date/email/revision line, that's the changes in -164. The changelog
shows 164, 165, 166, 167, 163. I wonder if this will ever get fixed :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:11 a.m.
On Fri, 29 May 2009 10:11:26 -0700, Adam wrote:
As Kevin says, the changelog isn't well ordered - note the
date/email/revision line, that's the changes in -164. The changelog
shows 164, 165, 166, 167, 163. I wonder if this will ever get fixed :)
http://yum.baseurl.org/ticket/6 with patches - 12/19/08
("james" disagrees with me, but he's wrong [1])
http://yum.baseurl.org/ticket/7 with patch - 12/20/08
adds the missing changelog entries for rebuilds done on the same day
(no reply yet)
And of course, once the tools are fixed, infrastructure needs updates.
--
[1] To reverse the changelog entries (oldest first) in the metadata means
that every utility that wants to display the changelog entries must
reverse them once more. *urks*
10:28 a.m.
Michael Schwendt wrote:
[1] To reverse the changelog entries (oldest first) in the metadata
means
that every utility that wants to display the changelog entries must
reverse them once more. *urks*
Why do we care at all whether the changelog entries are newest first or
oldest first? All I care about is that the order is consistent!
Kevin Kofler
11 a.m.
On Sat, 30 May 2009 17:28:29 +0200, Kevin wrote:
Michael Schwendt wrote:
> [1] To reverse the changelog entries (oldest first) in the metadata means
> that every utility that wants to display the changelog entries must
> reverse them once more. *urks*
Why do we care at all whether the changelog entries are newest first or
oldest first? All I care about is that the order is consistent!
Kevin Kofler
In RPM they are newest first, so why reverse them in the metadata?
The order is only inconsistent because createrepo sorts them, which
doesn't work because the timestamps are not accurate enough.
10:47 a.m.
fr., 29.05.2009 kl. 09.11 -0700, skrev Adam Williamson:
This mostly relates to bug 502077, filed on May 21st (so quite late in
cycle). Intel i865 cards were experiencing random hangs with kernel
modesetting enabled (which was the default). There was a single
unconfirmed report of the same issue affect i845, and another single
unconfirmed report for i855.
I just tried the latest kernel now and was rewarded with a hang during
boot.
I've filed a bug earlier about hangs with more information here:
https://bugzilla.redhat.com/show_bug.cgi?id=492686
This all started around the time KMS was introduced, and the only way
I've found to have a working system is to pass maxcpus=1 to the boot
command line. The latest kernel even hung with this passed to it.
Cheers
Kjartan
5442
days inactive
5445
days old
10 comments
6 participants
participants (6)
-
Adam Williamson -
Fedora compose checker -
Kevin Kofler -
Kjartan Maraas -
Michael Schwendt -
Rahul Sundaram