FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 12-20-2009, 08:11 PM
Ionut Biru
 
Default kernel 2.6.32.2-1

On 12/20/2009 10:32 PM, Tobias Powalowski wrote:

Hi guys,

Upstream changes:
http://kernelnewbies.org/LinuxChanges

Arch Linux bugfixes/feature requests:
http://bugs.archlinux.org/task/16855 # added CONFIG_PM_DEBUG
http://bugs.archlinux.org/task/17106 # added CONFIG_MMIOTRACE

Arch Linux changes:
- splitted kernel-headers to extra package
If you want to build external modules please install:
pacman -S kernel26-headers
Please change your PKGBUILDS to makedepend on this package.
- added xen support to 64bit kernel
- changed intel kms enabled by default
- changed to new firewire subsystem:
http://ieee1394.wiki.kernel.org/index.php/Juju_Migration

Please signoff both arches,

greetings
tpowa


signoff x86_64. note that i'm not using any kms driver.

--
Ionut
 
Old 12-21-2009, 07:12 AM
Andreas Radke
 
Default kernel 2.6.32.2-1

I think we need a news item how to fix Radeon kms. What's way you want
to recommend?

-Andy
 
Old 12-22-2009, 01:59 PM
Jan de Groot
 
Default kernel 2.6.32.2-1

On Mon, 2009-12-21 at 09:12 +0100, Andreas Radke wrote:
> I think we need a news item how to fix Radeon kms. What's way you want
> to recommend?
>
> -Andy

First of all, Radeon KMS is not ready for production. Like with the
intel driver, modesetting can be enabled by using radeon.modeset=1 in
the bootflags if KMS is not enabled by default for Radeon.
CONFIG_DRM_RADEON_KMS=y should be disabled.

Next issue is problems with Intel KMS. The 2.6.32 kernel contains
powermanagement features for intel. These new features are utilized by
the driver I uploaded to testing last weekend on hardware that supports
it. However, this causes GPU lockups, requiring a reboot now and then.
This was reverted in 2.6.33, so we should also revert this. A patch has
been posted here:
http://patchwork.kernel.org/patch/67768/

This patch is also committed to the drm-intel git tree, maybe it's
easier to fetch the patch from git.kernel.org.

Besides these changes, I haven't seen problems with this new kernel,
everything has been stable for me for a while now. If we change these
two things, I will give a signoff for both architectures.
 
Old 12-22-2009, 02:35 PM
Thomas Bächler
 
Default kernel 2.6.32.2-1

Am 22.12.2009 15:59, schrieb Jan de Groot:
> On Mon, 2009-12-21 at 09:12 +0100, Andreas Radke wrote:
>> I think we need a news item how to fix Radeon kms. What's way you want
>> to recommend?
>>
>> -Andy
>
> First of all, Radeon KMS is not ready for production. Like with the
> intel driver, modesetting can be enabled by using radeon.modeset=1 in
> the bootflags if KMS is not enabled by default for Radeon.
> CONFIG_DRM_RADEON_KMS=y should be disabled.

Last time I check this was not true: Disabling the CONFIG_DRM_RADEON_KMS
option would not only disable it by default, but remove all KMS code
entirely.
 
Old 12-22-2009, 02:44 PM
Jan de Groot
 
Default kernel 2.6.32.2-1

On Tue, 2009-12-22 at 16:35 +0100, Thomas Bächler wrote:
> Am 22.12.2009 15:59, schrieb Jan de Groot:
> > On Mon, 2009-12-21 at 09:12 +0100, Andreas Radke wrote:
> >> I think we need a news item how to fix Radeon kms. What's way you want
> >> to recommend?
> >>
> >> -Andy
> >
> > First of all, Radeon KMS is not ready for production. Like with the
> > intel driver, modesetting can be enabled by using radeon.modeset=1 in
> > the bootflags if KMS is not enabled by default for Radeon.
> > CONFIG_DRM_RADEON_KMS=y should be disabled.
>
> Last time I check this was not true: Disabling the CONFIG_DRM_RADEON_KMS
> option would not only disable it by default, but remove all KMS code
> entirely.

Andy claimed that also, but with 2.6.32.2, it just disables the module
aliases for autoloading and the default setting of KMS. Check the radeon
driver for the define set by the Kconfig file and you'll see what I
mean.
 
Old 12-22-2009, 03:20 PM
Thomas Bächler
 
Default kernel 2.6.32.2-1

Am 22.12.2009 16:44, schrieb Jan de Groot:
>> Last time I check this was not true: Disabling the CONFIG_DRM_RADEON_KMS
>> option would not only disable it by default, but remove all KMS code
>> entirely.
>
> Andy claimed that also, but with 2.6.32.2, it just disables the module
> aliases for autoloading and the default setting of KMS. Check the radeon
> driver for the define set by the Kconfig file and you'll see what I
> mean.

If they changed that, we can also disable that option. In 2.6.31 it was
definitley like I said.
 
Old 12-22-2009, 08:59 PM
Tobias Powalowski
 
Default kernel 2.6.32.2-1

> First of all, Radeon KMS is not ready for production. Like with the
> intel driver, modesetting can be enabled by using radeon.modeset=1 in
> the bootflags if KMS is not enabled by default for Radeon.
> CONFIG_DRM_RADEON_KMS=y should be disabled.
Will try this in next build then.

>
> Next issue is problems with Intel KMS. The 2.6.32 kernel contains
> powermanagement features for intel. These new features are utilized by
> the driver I uploaded to testing last weekend on hardware that supports
> it. However, this causes GPU lockups, requiring a reboot now and then.
> This was reverted in 2.6.33, so we should also revert this. A patch has
> been posted here:
> http://patchwork.kernel.org/patch/67768/
>
When i apply this patch i get an error:
patching file drivers/gpu/drm/i915/intel_display.c
Reversed (or previously applied) patch detected! Skipping patch.
Could it be they solved this already in 32.2?

greetings
tpowa

--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org
 
Old 12-23-2009, 11:21 AM
Xavier
 
Default kernel 2.6.32.2-1

On Tue, Dec 22, 2009 at 10:59 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
>> First of all, Radeon KMS is not ready for production. Like with the
>> intel driver, modesetting can be enabled by using radeon.modeset=1 in
>> the bootflags if KMS is not enabled by default for Radeon.
>> CONFIG_DRM_RADEON_KMS=y should be disabled.
> Will try this in next build then.
>
>>
>> Next issue is problems with Intel KMS. The 2.6.32 kernel contains
>> powermanagement features for intel. These new features are utilized by
>> the driver I uploaded to testing last weekend on hardware that supports
>> it. However, this causes GPU lockups, requiring a reboot now and then.
>> This was reverted in 2.6.33, so we should also revert this. A patch has
>> been posted here:
>> http://patchwork.kernel.org/patch/67768/
>>
> When i apply this patch i get an error:
> patching file drivers/gpu/drm/i915/intel_display.c
> Reversed (or previously applied) patch detected! *Skipping patch.
> Could it be they solved this already in 32.2?
>

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=blob_plain;f=drivers/gpu/drm/i915/intel_display.c;hb=HEAD

This still contains all the references to renderclock , that the patch
is supposed to remove.
But anyway, just look at the file and the patch side by side to see
whether your local kernel tree has this patch or not.
 
Old 12-25-2009, 06:45 PM
Pierre Schmitz
 
Default kernel 2.6.32.2-1

On Sun, 20 Dec 2009 21:32:10 +0100, Tobias Powalowski <t.powa@gmx.de>
wrote:
> Hi guys,
>
> Upstream changes:
> http://kernelnewbies.org/LinuxChanges
>
> Arch Linux bugfixes/feature requests:
> http://bugs.archlinux.org/task/16855 # added CONFIG_PM_DEBUG
> http://bugs.archlinux.org/task/17106 # added CONFIG_MMIOTRACE
>
> Arch Linux changes:
> - splitted kernel-headers to extra package
> If you want to build external modules please install:
> pacman -S kernel26-headers
> Please change your PKGBUILDS to makedepend on this package.
> - added xen support to 64bit kernel
> - changed intel kms enabled by default
> - changed to new firewire subsystem:
> http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
>
> Please signoff both arches,
>
> greetings
> tpowa

signed off botrh arches. Did not notice any real problem for a while. I
would suggest to not use autodetect in mkinitcpio.conf with software raid
as it does not detect the raid module and the klibc binary (forgot its
name) which detects the filesystem just segfault (for me since .32).

We shouldn't wait that long with the move; our kernel in core has (afaik)
some security issues.

--
Pierre Schmitz, https://users.archlinux.de/~pierre
 

Thread Tools




All times are GMT. The time now is 06:36 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org