Hello,
at boot udev (175-7.2 from debian unstable) blocks for maybe 30 seconds
and then gives (handcopied)
timeout: killing '/sbin/modprobe -b
pci:v00008086d0000293Esv0000144Dsd0000C045bc04sc03i00'
when booting 3.9.8. 3.8.13 has the same issue, 3.6.0 is fine.
The pci id matches the audio device and in fact the module is not loaded:
00:1b.0 0403: 8086:293e (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
Controller (rev 03)
Subsystem: Samsung Electronics Co Ltd Device c045
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at f8620000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [130] Root Complex Link
Kernel driver in use: snd_hda_intel
In /etc/modprobe.d/options.conf i have:
options snd-hda-intel model=ultra
A manual `modprobe snd-hda-intel` works perfectly fine:
[16018.432762] snd_hda_intel 0000:00:1b.0: irq 46 for MSI/MSI-X
[16018.509390] input: HDA Digital PCBeep as
/devices/pci0000:00/0000:00:1b.0/input/input12
[16018.565581] input: HDA Intel HDMI/DP,pcm=3 as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input13
[16018.565671] input: HDA Intel Mic as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input14
[16018.565749] input: HDA Intel Headphone as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input15
I've tried both these with 3.9.8 but does not change anything:
@@ -969,7 +981,7 @@
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
-# CONFIG_FW_LOADER_USER_HELPER is not set
+CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_SYS_HYPERVISOR=y
The only sound related change from 3.6.0 config to 3.9.8 one is:
@@ -2133,7 +2246,6 @@
# CONFIG_SND_HDA_CODEC_CMEDIA is not set
# CONFIG_SND_HDA_CODEC_SI3054 is not set
CONFIG_SND_HDA_GENERIC=y
-CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
thanks in advance,
riccardo
Hi
On Friday 28 June 2013, Riccardo Magliocchetti wrote:
> Hello,
>
> at boot udev (175-7.2 from debian unstable) blocks for maybe 30 seconds
> and then gives (handcopied)
>
> timeout: killing '/sbin/modprobe -b
> pci:v00008086d0000293Esv0000144Dsd0000C045bc04sc03i00'
>
> when booting 3.9.8. 3.8.13 has the same issue, 3.6.0 is fine.
[…]
I think oss-compat might interfere here. Given that it was recently
(2013-06-18) updated, this would explain why only new'ish kernels are
affected (initramfs not updated for the older ones). Therefore I'd
suggest to purge oss-compat (simple removal is not sufficient, as the
modprobe.d/ snippets are dpkg conffiles) for testing - and to file a
bug[1] against the new version of oss-compat, if you can confirm it
to be responsible.
Regards
Stefan Lippers-Hollmann
[1] http://www.debian.org/Bugs/Reporting
Hi Stefan,
Il 28/06/2013 22:08, Stefan Lippers-Hollmann ha scritto:
> Hi
>
> On Friday 28 June 2013, Riccardo Magliocchetti wrote:
>> Hello,
>>
>> at boot udev (175-7.2 from debian unstable) blocks for maybe 30 seconds
>> and then gives (handcopied)
>>
>> timeout: killing '/sbin/modprobe -b
>> pci:v00008086d0000293Esv0000144Dsd0000C045bc04sc03i00'
>>
>> when booting 3.9.8. 3.8.13 has the same issue, 3.6.0 is fine.
> [?]
>
> I think oss-compat might interfere here. Given that it was recently
> (2013-06-18) updated, this would explain why only new'ish kernels are
> affected (initramfs not updated for the older ones). Therefore I'd
> suggest to purge oss-compat (simple removal is not sufficient, as the
> modprobe.d/ snippets are dpkg conffiles) for testing - and to file a
> bug[1] against the new version of oss-compat, if you can confirm it
> to be responsible.
Confirm that after purging oss-compat 3.9.8 boot is fine. Please note
that a yesterday build of 3.6.11 used to work fine too so there's also
something that changed kernel side.
FYI there was already a bug in debian bug tracker:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660803#130
thanks a lot,
riccardo
On Sat, Jun 29, 2013 at 02:39:58PM +0200, Riccardo Magliocchetti wrote:
> Confirm that after purging oss-compat 3.9.8 boot is fine. Please
> note that a yesterday build of 3.6.11 used to work fine too so
> there's also something that changed kernel side.
> FYI there was already a bug in debian bug tracker:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660803#130
I found myself in the same situation. Unfortunately, right after doing
a BIOS update on my T520, which has led me into the wrong direction.
Additionally, he real colprit is snd.ko, which is loaded as a
dependency of snd-hda-intel and - surprisingly for me - thinkpad_acpi.
The latter sent me into another round of trying to debug ACPI. I
suspected ACPI to be the culprit because my notebook wouldn't suspend.
The issue does not appear when one uses a Debian kernel, or uses the
configuration that Debian uses for its kernels to build a vanilla
kernel.org kernel. This has, after a gazillion of reoboots and
experimenting with man different blacklist entries and kernel
configuration, led me to the fact that this bug does not show if the
kernel is compiled with CONFIG_SND_SUPPORT_OLD_API=y.
So it was my error to dump backwards compatibility and to remove the
old api support. I have now set CONFIG_SND_SUPPORT_OLD_API=y again and
everything is fine.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
* Marc Haber <[email protected]> [130701 17:50]:
> The issue does not appear when one uses a Debian kernel, or uses the
> configuration that Debian uses for its kernels to build a vanilla
> kernel.org kernel. This has, after a gazillion of reoboots and
> experimenting with man different blacklist entries and kernel
> configuration, led me to the fact that this bug does not show if the
> kernel is compiled with CONFIG_SND_SUPPORT_OLD_API=y.
> So it was my error to dump backwards compatibility and to remove the
> old api support. I have now set CONFIG_SND_SUPPORT_OLD_API=y again and
> everything is fine.
Even with this option, I get the problem, so this is not enough...
--
Damien