[arch-dev-public] kernel 2.6.32-1
Hi guys, kernel 2.6.32 first test run ... 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 Broken binary modules: - lirc still needs to be patched, though no fix available yet. Enjoy have fun and give me feedback, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Samstag 05 Dezember 2009 09:00:38 schrieb Tobias Powalowski:
- 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.
Was this done to reduce the kernel package size? It's a little confusing to have kernel26-headers and kernel-headers. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Pierre Schmitz schrieb:
Am Samstag 05 Dezember 2009 09:00:38 schrieb Tobias Powalowski:
- 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.
Was this done to reduce the kernel package size? It's a little confusing to have kernel26-headers and kernel-headers.
People have been confused by "kernel-headers" anyway, so there is no harm. The point is to 1) Make the PKGBUILD more readable (everything except the "header-installation" is simple, and that is now in a separate function) 2) Remove confusion about many people thinking there was a kernel source in /usr/src/linux-foo 3) Do not install a bunch of useless headers with the kernel. 4) Because we can.
Tobias Powalowski wrote:
Hi guys, kernel 2.6.32 first test run ... <snip>
- changed intel kms enabled by default
That works for me. I initially thought it was strange that it came on but now I see why. extreme-tuxracer is giving me (>50%) more FPS with this update. Anyway, this update fix the interesting kbd error I had when using the x86_64 kernel on an i686 system, which is nice. No issues noted. Allan
Allan McRae schrieb:
That works for me. I initially thought it was strange that it came on but now I see why. extreme-tuxracer is giving me (>50%) more FPS with this update.
Intel DRM has been improved, I noticed that too - probably due to framebuffer compression. KMS is enabled by default because the next intel driver version will require it to work.
Thomas Bächler wrote:
Allan McRae schrieb:
That works for me. I initially thought it was strange that it came on but now I see why. extreme-tuxracer is giving me (>50%) more FPS with this update.
Intel DRM has been improved, I noticed that too - probably due to framebuffer compression.
KMS is enabled by default because the next intel driver version will require it to work.
With KMS on, my screen flickers every 20sec or so. Tried with no xorg.conf and the same thing. I even got some sort of yellow/orange screen of death. I did not use KMS with 2.6.31 so this may not be kernel related. I'll look into it later but disabling kms from the grub prompt works fine... As an aside, how do you see the resolution for the tty's with KMS? Native is really too high a resolution for me. Allan
On Sat, Dec 5, 2009 at 17:46, Allan McRae <allan@archlinux.org> wrote:
As an aside, how do you see the resolution for the tty's with KMS? Native is really too high a resolution for me.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif... -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych schrieb:
On Sat, Dec 5, 2009 at 17:46, Allan McRae <allan@archlinux.org> wrote:
As an aside, how do you see the resolution for the tty's with KMS? Native is really too high a resolution for me.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif...
I wouldn't change the resolution on a TFT, but rather just choose a bigger console font.
On Sat, Dec 5, 2009 at 3:00 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Hi guys, kernel 2.6.32 first test run ...
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
I don't know if it's because the kms-enabled kernel or the new xorg packages, but the intel drivers are working again on my i686 with 855GM Intel graphics. Xv support is not working but it's still much better than the vesa drivers that I had to use since the intel-legacy drivers stopped working a while ago. Eric
- changed to new firewire subsystem: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
Broken binary modules: - lirc still needs to be patched, though no fix available yet.
Enjoy have fun and give me feedback, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Eric Bélanger schrieb:
- changed intel kms enabled by default
I don't know if it's because the kms-enabled kernel or the new xorg packages, but the intel drivers are working again on my i686 with 855GM Intel graphics. Xv support is not working but it's still much better than the vesa drivers that I had to use since the intel-legacy drivers stopped working a while ago.
Xv doesn't work with KMS on the 8xx series. This will be fixed with the next upstream release of libdrm/mesa/xf86-video-intel. If you need it, you should be able run without KMS for now (i915.modeset=0), I guess this is also fixed now.
1) as posted some weeks ago: early KMS mode is broken for me. mkinitcpio fails to load the firmware though the firmware hook is enabled and is included in the image. last line I see is: platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin then it stops working. CTRL+ALT+DEL is working so I expect the kernel not to be crashed. 2) KMS late mode is working in proper resolution now but it's highly unstable for me in X. I will try to update to a new ddx git shot and maybe we need a new libdrm to get this stable. 3) without kms radeon seems stable for me. 4) glxgears nearly doubled to 31 kernels but supertuxkart instantly crashes: [andyrtr@laptop64 ~]$ unset LC_ALL; LANG=C supertuxkart Data files will be fetched from: '/usr/share/supertuxkart/' Highscores will be saved in '/home/andyrtr/.supertuxkart/highscore.data'. *********************************WARN_ONCE********************************* File radeon_dma.c function radeonReleaseDmaRegions line 348 Leaking dma buffer object! *************************************************************************** supertuxkart: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed. Abgebrochen Just a few first impressions with this "stable" kernel release. -Andy
Andreas Radke schrieb:
1) as posted some weeks ago: early KMS mode is broken for me. mkinitcpio fails to load the firmware though the firmware hook is enabled and is included in the image. last line I see is:
platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
Okay, mkinitcpio does add the firmware to the image, the firmware loader is basically identical to the one in normal userspace and when I switch the shebang in my normal firmware loader to klibc-dash, it still works. I cannot find any more possible sources of error in here. You could add some "echo something > /dev/console" to the firmware.sh script to see if it finished correctly, or where it hangs.
Nouveau upgrade path was broken for me. It printed out to the screen something like "module 'nouveau' not found" while building the new initrd. It's not in the pacman.log. I'm using early kms mode. This probably happens because the new nouveau module is not yet present when the kernel is updated and new initrd is built. Maybe we should start to rebuild the initrd from nouveau post.update because we recommend early kms mode anyway whenever possible? After reboot kms wasn't enabled. I did pacman -S kernel26 again and this time it picked up the module into the initrd. -Andy [2009-12-07 05:47] upgraded kernel26-firmware (2.6.31-1 -> 2.6.32-1) [2009-12-07 05:47] >>> Updating module dependencies. Please wait ... [2009-12-07 05:47] >>> MKINITCPIO SETUP [2009-12-07 05:47] >>> ---------------- [2009-12-07 05:47] >>> If you use LVM2, Encrypted root or software RAID, [2009-12-07 05:47] >>> Ensure you enable support in /etc/mkinitcpio.conf . [2009-12-07 05:47] >>> More information about mkinitcpio setup can be found here: [2009-12-07 05:47] >>> http://wiki.archlinux.org/index.php/Mkinitcpio [2009-12-07 05:47] [2009-12-07 05:47] >>> Generating initial ramdisk, using mkinitcpio. Please wait... [2009-12-07 05:47] ==> Building image "default" [2009-12-07 05:47] ==> Running command: /sbin/mkinitcpio -k 2.6.32-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img [2009-12-07 05:47] :: Begin build [2009-12-07 05:47] :: Parsing hook [base] [2009-12-07 05:47] :: Parsing hook [udev] [2009-12-07 05:47] :: Parsing hook [autodetect] [2009-12-07 05:47] :: Parsing hook [sata] [2009-12-07 05:48] :: Parsing hook [filesystems] [2009-12-07 05:48] :: Generating module dependencies [2009-12-07 05:48] :: Generating image '/boot/kernel26.img'...SUCCESS [2009-12-07 05:48] ==> SUCCESS [2009-12-07 05:48] ==> Building image "fallback" [2009-12-07 05:48] ==> Running command: /sbin/mkinitcpio -k 2.6.32-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26-fallback.img -S autodetect [2009-12-07 05:48] :: Begin build [2009-12-07 05:48] :: Parsing hook [base] [2009-12-07 05:48] :: Parsing hook [udev] [2009-12-07 05:48] :: Parsing hook [sata] [2009-12-07 05:48] :: Parsing hook [filesystems] [2009-12-07 05:48] :: Generating module dependencies [2009-12-07 05:48] :: Generating image '/boot/kernel26-fallback.img'...SUCCESS [2009-12-07 05:48] ==> SUCCESS [2009-12-07 05:48] upgraded kernel26 (2.6.31.6-1 -> 2.6.32-1) [2009-12-07 05:48] upgraded kexec-tools (2.0.0-1 -> 2.0.1-1) [2009-12-07 05:48] upgraded lib32-fontconfig (2.6.0-2 -> 2.8.0-1) [2009-12-07 05:48] upgraded libcddb (1.3.2-1 -> 1.3.2-1.1) [2009-12-07 05:48] upgraded libv4l (0.6.3-1 -> 0.6.3-2) [2009-12-07 05:48] upgraded miro (2.5.3-1 -> 2.5.3-2) [2009-12-07 05:48] upgraded mpd (0.15.5-2 -> 0.15.6-1) [2009-12-07 05:48] if you are running kms in early mode please rebuild your initrd [2009-12-07 05:48] In order to use the new nouveau module, exit Xserver and unload it manually. [2009-12-07 05:48] upgraded nouveau-drm (0.0.15_20091120-1 -> 0.0.15_20091120-2)
On Mon, Dec 7, 2009 at 6:33 AM, Andreas Radke <a.radke@arcor.de> wrote:
Nouveau upgrade path was broken for me. It printed out to the screen something like "module 'nouveau' not found" while building the new initrd. It's not in the pacman.log.
I'm using early kms mode. This probably happens because the new nouveau module is not yet present when the kernel is updated and new initrd is built.
Maybe we should start to rebuild the initrd from nouveau post.update because we recommend early kms mode anyway whenever possible?
Why would you recommend such a thing ? I would rather disrecommend it to avoid problems. But it's true that the main problem when using initrd is forgetting to rebuild it (as you experienced yourself), so having the package do that automatically might help.. hmm.. What I don't like is forcing a rebuild in all cases, even when nouveau is not even in the initrd. Is there a good way to detect that ?
Andreas Radke schrieb:
Nouveau upgrade path was broken for me. It printed out to the screen something like "module 'nouveau' not found" while building the new initrd. It's not in the pacman.log.
I'm using early kms mode. This probably happens because the new nouveau module is not yet present when the kernel is updated and new initrd is built.
Maybe we should start to rebuild the initrd from nouveau post.update because we recommend early kms mode anyway whenever possible?
After reboot kms wasn't enabled. I did pacman -S kernel26 again and this time it picked up the module into the initrd.
That is to be expected, as nouveau depends on kernel26. I have asked Dan a while ago if we can have "delayed post_install", such that certain tasks can be queued for the end, after ALL packages have been upgraded. No idea what he responded, but it is the only clean way to solve this.
Am Montag 07 Dezember 2009 14:56:34 schrieb Thomas Bächler:
That is to be expected, as nouveau depends on kernel26. I have asked Dan a while ago if we can have "delayed post_install", such that certain tasks can be queued for the end, after ALL packages have been upgraded. No idea what he responded, but it is the only clean way to solve this.
I think there were some discussion about hook scripts that pacman will execute on certain events (e.g. to update desktop database, icon cache etc.). Running mkinitcpio would be another use case. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Pierre Schmitz wrote:
Am Montag 07 Dezember 2009 14:56:34 schrieb Thomas Bächler:
That is to be expected, as nouveau depends on kernel26. I have asked Dan a while ago if we can have "delayed post_install", such that certain tasks can be queued for the end, after ALL packages have been upgraded. No idea what he responded, but it is the only clean way to solve this.
I think there were some discussion about hook scripts that pacman will execute on certain events (e.g. to update desktop database, icon cache etc.). Running mkinitcpio would be another use case.
I started writing about it here: http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks Still a long way off...
participants (8)
-
Allan McRae
-
Andreas Radke
-
Eric Bélanger
-
Pierre Schmitz
-
Roman Kyrylych
-
Thomas Bächler
-
Tobias Powalowski
-
Xavier