Bug#575241: initramfs-tools: long delay with nouveau module in the initramfs
On Wed, Mar 24, 2010 at 02:27:55PM +0100, Sven Joachim wrote:
> Package: initramfs-tools
> Version: 0.93.4
>
> I decided to give nouveau a try and built a vanilla 2.6.33.1 kernel with
> it. This works okay if the nouveau module is not in the initramfs, it
> then gets loaded by udev in runlevel S. But when I added it to
> /etc/initramfs-tools/modules to set the resolution as early as possible,
> the next boot took ~1 minute before the module got loaded and the
> resolution was set. This is reproducible both with "video=nouveau" and
> without any video or vga parameter on the commandline.
>
> Any advice how to debug this is appreciated.
kms stuff has no place in initramfs, will close.
the 1 min hang is due to loading the module while udev is not running
this will be cured soon but isn't yet.
anyway happ to see that people test out nouveau, also you should see
it in latest 2.6.32 in sid.
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100324132729.GH22870@baikonur.stro.at">http://lists.debian.org/20100324132729.GH22870@baikonur.stro.at
03-24-2010, 12:27 PM
Sven Joachim
Bug#575241: initramfs-tools: long delay with nouveau module in the initramfs
Package: initramfs-tools
Version: 0.93.4
I decided to give nouveau a try and built a vanilla 2.6.33.1 kernel with
it. This works okay if the nouveau module is not in the initramfs, it
then gets loaded by udev in runlevel S. But when I added it to
/etc/initramfs-tools/modules to set the resolution as early as possible,
the next boot took ~1 minute before the module got loaded and the
resolution was set. This is reproducible both with "video=nouveau" and
without any video or vga parameter on the commandline.
-- /etc/kernel-img.conf
# This is the /etc/kernel-img.conf file
# Set to Yes if you want the kernel image vmlinuz in /boot rather
# than the default /.
link_in_boot = Yes
# By default, the kernel image post installation script shall create or
# update the /vmlinuz and /vmlinuz.old symbolic links. This is true if
# a /vmlinuz link already exists, however, in absence of /vmlinuz, the
# script looks to see if this configuration file exists. If it does
# not, the configuration script asks the user whether to create the
# symbolic link, and stashes the answer in a newly created
# /etc/kernel-img.conf. If the configuration file already exists, and
# if this option is set to No, no symbolic link is ever created. This
# for people who have other means of booting their machines, and do not
# like the symbolic links cluttering up their / directory.
do_symlink = No
# Whether to use symlinks to the image file. Mutually exclusive to
# reverse_symlink. Can be used with link_in_boot. If set to Yes, the
# image is placed in vmlinuz (instead of /boot/vmlinuz- X.X.XX). The
# old vmlinuz is moved to vmlinuz.old unconditionally. (Normally, that
# is only done if the version of the new image differs from the old
# one). This restricts you to two images, unless you take additional
# action and save copies of older images. This is for people who have
# boot on a system that does not use symbolic links (and say, they use
# loadlin as a boot loader).
no_symlink = No
# Whether to use reverse symlinks (that is, the real file is the one
# without the version number, and the number version is the link) to
# the image file. Mutually exclusive to no_symlink. Can be used with
# link_in_boot. Just like no_symlink, except that the
# /boot/vmlinuz-X.XX is a symbolic link to the real new image,
# vmlinuz. This, too, restricts you to just two images unless further
# action is taken. The older symlinks are left dangling. This is for
# people with boot on umsdos, and who can't see the link in dos, but do
# want to know the image version when in Linux. This is a Hack.
reverse_symlink = No
# If you want the symbolic link (or image, if move_image is set) to be
# stored elsewhere than / set this variable to the dir where you
# want the symbolic link. Please note that this is not a Boolean
# variable. This may be of help to loadlin users, who may set both
# this and move_image. Defaults to /. This can be used in conjunction
# with all above options except link_in_boot, which would not make
# sense. (If both image_dest and link_in_boot are set, link_in_boot
# overrides).
image_dest = /
# Instead of creating symbolic links to (or, if reverse_symlinks is
# set, from) image_dest, the image is moved from its location in /boot
# into image_dest. If reverse_symlinks is set, /boot shall contain a
# symbolic link to the actual image. This option can be useful to
# people using loadlin, who may need the image to be moved to a
# different dos partition.
#move_image = NO
# If set, the preinst shall silently try to move /lib/modules/version
# out of the way if it is the same version as the image being
# installed. Use at your own risk.
#clobber_modules = NO
# If not set, the preinst will warn if /lib/modules/version exists.
# Use at your own risk.
silent_modules = Yes
# If set to NO, this shortcircuits all attempts to create boot
# floppies, run lilo, etc. This has the additional side effect that the
# postinst is silent. Setting both do_bootfloppy and do_bootloader to
# NO implies setting do_boot_enable to NO.
do_boot_enable = No
# If set to NO, this prevents the postinst from asking questions about
# creating a boot floppy, and no boot floppy is created. The bootloader
# shall still be run. This may cut down on the interaction the
# postinst has. (It still prompts before formatting /dev/fd0)
do_bootfloppy = No
# If set to NO, this prevents the postinst from running the boot
# loader. The user may still be asked to create a floppy, unless
# do_bootfloppy is also set to NO.
do_bootloader = No
# If set to yes, the kernel image postinst script shall go to
# extraordinary lengths to ensure that the symbolic links are
# relative. Normally, the symbolic links are relative when it
# is easily determinable that relative links shall work.
relative_links = No
# If set to yes, causes an annoying warning everytime a kernel image
# with initramfs support is installed.
warn_initrd = No
Kernel: Linux 2.6.33.1-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages initramfs-tools depends on:
ii cpio 2.11-1 GNU cpio -- a program to manage ar
ii findutils 4.4.2-1 utilities for finding files--find,
ii klibc-utils 1.5.17-4 small utilities built with klibc f
ii module-init-tools 3.12~pre2-2 tools for managing Linux kernel mo
ii udev 151-3 /dev/ and hotplug management daemo
Versions of packages initramfs-tools recommends:
ii busybox 1:1.15.3-1 Tiny utilities for small and embed
initramfs-tools suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mxxxx31g.fsf@turtle.gmx.de">http://lists.debian.org/87mxxxx31g.fsf@turtle.gmx.de
03-24-2010, 02:58 PM
Sven Joachim
Bug#575241: initramfs-tools: long delay with nouveau module in the initramfs
On 2010-03-24 14:27 +0100, maximilian attems wrote:
> On Wed, Mar 24, 2010 at 02:27:55PM +0100, Sven Joachim wrote:
>> Package: initramfs-tools
>> Version: 0.93.4
>>
>> I decided to give nouveau a try and built a vanilla 2.6.33.1 kernel with
>> it. This works okay if the nouveau module is not in the initramfs, it
>> then gets loaded by udev in runlevel S. But when I added it to
>> /etc/initramfs-tools/modules to set the resolution as early as possible,
>> the next boot took ~1 minute before the module got loaded and the
>> resolution was set. This is reproducible both with "video=nouveau" and
>> without any video or vga parameter on the commandline.
>>
>> Any advice how to debug this is appreciated.
>
> kms stuff has no place in initramfs, will close.
Well, i915 works perfectly fine from initramfs on my laptop.
> the 1 min hang is due to loading the module while udev is not running
> this will be cured soon but isn't yet.
Okay, I removed nouveau from initramfs for now.
> anyway happ to see that people test out nouveau, also you should see
> it in latest 2.6.32 in sid.
Actually it is me who started to work on getting
xserver-xorg-video-nouveau into shape, see #568162 and #568168.
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hbo5ww20.fsf@turtle.gmx.de">http://lists.debian.org/87hbo5ww20.fsf@turtle.gmx.de
03-24-2010, 05:38 PM
Ben Hutchings
Bug#575241: initramfs-tools: long delay with nouveau module in the initramfs
On Wed, Mar 24, 2010 at 04:58:47PM +0100, Sven Joachim wrote:
> On 2010-03-24 14:27 +0100, maximilian attems wrote:
>
> > On Wed, Mar 24, 2010 at 02:27:55PM +0100, Sven Joachim wrote:
> >> Package: initramfs-tools
> >> Version: 0.93.4
> >>
> >> I decided to give nouveau a try and built a vanilla 2.6.33.1 kernel with
> >> it. This works okay if the nouveau module is not in the initramfs, it
> >> then gets loaded by udev in runlevel S. But when I added it to
> >> /etc/initramfs-tools/modules to set the resolution as early as possible,
> >> the next boot took ~1 minute before the module got loaded and the
> >> resolution was set. This is reproducible both with "video=nouveau" and
> >> without any video or vga parameter on the commandline.
> >>
> >> Any advice how to debug this is appreciated.
> >
> > kms stuff has no place in initramfs, will close.
>
> Well, i915 works perfectly fine from initramfs on my laptop.
[...]
The general conditions for the bug are:
1. Module is manually loaded using /etc/initramfs-tools/modules
2. Module needs to load firmware
i915 doesn't need to load firmware and is enabled for auto-loading.
nouveau does require firmware and will not be enabled for auto-loading
until we have user-space packages that work with it.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100324183859.GN16821@decadent.org.uk">http://lists.debian.org/20100324183859.GN16821@decadent.org.uk
03-26-2010, 08:51 AM
Sven Joachim
Bug#575241: initramfs-tools: long delay with nouveau module in the initramfs
On 2010-03-24 19:38 +0100, Ben Hutchings wrote:
> The general conditions for the bug are:
> 1. Module is manually loaded using /etc/initramfs-tools/modules
> 2. Module needs to load firmware
Thanks for the explanation. Speaking of the firmware, is anyone working
on packaging it? Ubuntu has a package¹ in multiverse which works fine
for me and could be used as a base, although it should probably named
firmware-nouveau for consistency.
> i915 doesn't need to load firmware and is enabled for auto-loading.
> nouveau does require firmware and will not be enabled for auto-loading
> until we have user-space packages that work with it.
With my locally built xserver-xorg-video-nouveau package and
linux-image-2.6.32-4-amd64, the module gets loaded when X starts up
which is certainly soon enough for now.
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sk7nxvfx.fsf@turtle.gmx.de">http://lists.debian.org/87sk7nxvfx.fsf@turtle.gmx.de
03-26-2010, 02:06 PM
maximilian attems
Bug#575241: initramfs-tools: long delay with nouveau module in the initramfs
reasign firmware-nonfree
stop
On Fri, Mar 26, 2010 at 10:51:14AM +0100, Sven Joachim wrote:
> On 2010-03-24 19:38 +0100, Ben Hutchings wrote:
>
> > The general conditions for the bug are:
> > 1. Module is manually loaded using /etc/initramfs-tools/modules
> > 2. Module needs to load firmware
this bug is already worked on, so no need for another report.
> Thanks for the explanation. Speaking of the firmware, is anyone working
> on packaging it? Ubuntu has a package¹ in multiverse which works fine
> for me and could be used as a base, although it should probably named
> firmware-nouveau for consistency.
where does one find the firmware? what's legal status
>
> With my locally built xserver-xorg-video-nouveau package and
> linux-image-2.6.32-4-amd64, the module gets loaded when X starts up
> which is certainly soon enough for now.
>
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100326150613.GB22870@baikonur.stro.at">http://lists.debian.org/20100326150613.GB22870@baikonur.stro.at
Bug#575241: initramfs-tools: long delay with nouveau module in the initramfs
