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 > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 03-24-2010, 12:27 PM
maximilian attems
 
Default 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
 
Old 03-24-2010, 12:27 PM
Sven Joachim
 
Default 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.

Any advice how to debug this is appreciated.


-- Package-specific info:
-- /proc/cmdline
root=LABEL=/ ro acpi_enforce_resources=lax quiet

-- /proc/filesystems
ext2
ext3
ext4
iso9660

-- lsmod
Module Size Used by
aes_generic 26034 2
coretemp 4133 0
w83627ehf 19961 0
hwmon_vid 1700 1 w83627ehf
hwmon 1321 2 coretemp,w83627ehf
arc4 1258 2
ecb 1809 2
cryptomgr 93318 0
crypto_hash 9875 1 cryptomgr
aead 4402 1 cryptomgr
pcompress 1249 1 cryptomgr
crypto_blkcipher 8212 2 ecb,cryptomgr
crypto_algapi 10322 8 aes_generic,arc4,ecb,cryptomgr,crypto_hash,aead,pc ompress,crypto_blkcipher
rt73usb 19312 0
crc_itu_t 1259 1 rt73usb
rt2x00usb 6471 1 rt73usb
rt2x00lib 19021 2 rt73usb,rt2x00usb
mac80211 111168 2 rt2x00usb,rt2x00lib
cfg80211 108371 2 rt2x00lib,mac80211
snd_hda_codec_realtek 239093 1
snd_hda_intel 17410 0
snd_hda_codec 45768 2 snd_hda_codec_realtek,snd_hda_intel
snd_intel8x0 23690 0
snd_ac97_codec 97889 1 snd_intel8x0
ac97_bus 1054 1 snd_ac97_codec
snd_pcm_oss 29453 0
snd_mixer_oss 12211 1 snd_pcm_oss
snd_pcm 54271 5 snd_hda_intel,snd_hda_codec,snd_intel8x0,snd_ac97_ codec,snd_pcm_oss
snd_seq_oss 22664 0
snd_seq_midi_event 4516 1 snd_seq_oss
snd_seq 40365 5 snd_seq_oss,snd_seq_midi_event
sg 20821 0
snd_timer 15357 2 snd_pcm,snd_seq
snd_seq_device 4429 2 snd_seq_oss,snd_seq
snd 42638 13 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec, snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_ oss,snd_pcm,snd_seq_oss,snd_seq,snd_timer,snd_seq_ device
soundcore 4575 1 snd
snd_page_alloc 5817 3 snd_hda_intel,snd_intel8x0,snd_pcm
sr_mod 10451 0
intel_agp 24421 0
uhci_hcd 17900 0
ehci_hcd 28650 0
usbcore 109948 4 rt73usb,rt2x00usb,uhci_hcd,ehci_hcd
sky2 37025 0
cdrom 28292 1 sr_mod
pcspkr 1667 0
evdev 7268 4
8250_pnp 4468 0
parport_pc 28188 0
8250 17437 1 8250_pnp
parport 24995 1 parport_pc
serial_core 14976 1 8250
i2c_i801 6756 0
processor 28535 0
thermal 11743 0
fan 3250 0
nouveau 367386 2
ttm 38346 1 nouveau
drm_kms_helper 19697 1 nouveau
drm 136450 4 nouveau,ttm,drm_kms_helper
i2c_algo_bit 4279 1 nouveau
button 4570 1 nouveau

-- /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

-- /etc/initramfs-tools/initramfs.conf
MODULES=list
BUSYBOX=y
KEYMAP=n
BOOT=local
DEVICE=eth0
NFSROOT=auto


-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (x86_64)

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
 
Old 03-24-2010, 02:58 PM
Sven Joachim
 
Default 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
 
Old 03-24-2010, 05:38 PM
Ben Hutchings
 
Default 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
 
Old 03-26-2010, 08:51 AM
Sven Joachim
 
Default 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.

Sven


¹ http://packages.ubuntu.com/lucid/nouveau-firmware



--
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
 
Old 03-26-2010, 02:06 PM
maximilian attems
 
Default 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
 

Thread Tools




All times are GMT. The time now is 02:34 AM.

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