Bug 99221

The message looks weird:

[   12.133262] snd_hda_intel 0000:00:1b.0: CORB reset timeout#2, CORBRP = 65535

so it reads 0xffff, which usually indicates the wrong iomem mapping, and can be rather a problem in a deeper level.

Please try git bisect.

I found the problems appears from kernel 3.13 series to 3.14, so I hope have done the git bisect process properly.

The result at the end of the tests is:

----------------------------------------------------------------
d56dbf5bab8ce44c5407bb099f71987f58d18bb4 is the first bad commit
commit d56dbf5bab8ce44c5407bb099f71987f58d18bb4
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri Dec 20 10:55:44 2013 -0700

    PCI: Allocate 64-bit BARs above 4G when possible
    
    Try to allocate space for 64-bit BARs above 4G first, to preserve the space
    below 4G for 32-bit BARs.  If there's no space above 4G available, fall
    back to allocating anywhere.
    
    [bhelgaas: reworked starting from http://lkml.kernel.org/r/1387485843-17403-2-git-send-email-yinghai@kernel.org]
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

:040000 040000 124ccf2587c6f72d88d8002d6e1f21c18d700d49 c46d5797cf209b3d111b81e8d6ec89d388fc92cc M      drivers
----------------------------------------------------------------

and the git bisect log:

----------------------------------------------------------------
$ git bisect log
git bisect start
# good: [2d20120bba8475c963a8d28dd0ffa13637fa3ad7] Linux 3.13.11
git bisect good 2d20120bba8475c963a8d28dd0ffa13637fa3ad7
# bad: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14
git bisect bad 455c6fdbd219161bd09b1165f11699d6d73de11c
# good: [d8ec26d7f8287f5788a494f56e8814210f0e64be] Linux 3.13
git bisect good d8ec26d7f8287f5788a494f56e8814210f0e64be
# bad: [82c477669a4665eb4e52030792051e0559ee2a36] Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 82c477669a4665eb4e52030792051e0559ee2a36
# good: [d4371f94bc003e912d4825f5c4bdf57959857073] Merge tag 'sound-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good d4371f94bc003e912d4825f5c4bdf57959857073
# bad: [f2c73464d7b399cf4e0c601c1c7d7b079080fa52] Merge tag 'cleanup-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad f2c73464d7b399cf4e0c601c1c7d7b079080fa52
# bad: [bb1281f2aae08e5ef23eb0692c8833e95579cdf2] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
git bisect bad bb1281f2aae08e5ef23eb0692c8833e95579cdf2
# good: [60eaa0190f6b39dce18eb1975d9773ed8bc9a534] Merge tag 'trace-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
git bisect good 60eaa0190f6b39dce18eb1975d9773ed8bc9a534
# bad: [e1ba84597c9012b9f9075aac283ac7537d7561ba] Merge tag 'pci-v3.14-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
git bisect bad e1ba84597c9012b9f9075aac283ac7537d7561ba
# good: [f72e11123ba122c4ed8fcee52ab57cf3fbe81178] Merge branch 'pci/deletion' into next
git bisect good f72e11123ba122c4ed8fcee52ab57cf3fbe81178
# bad: [96702be560374ee7e7139a34cab03554129abbb4] Merge branch 'pci/resource' into next
git bisect bad 96702be560374ee7e7139a34cab03554129abbb4
# good: [ccb126545448136d36da8661f2941372554015d1] Merge branch 'pci/misc' into next
git bisect good ccb126545448136d36da8661f2941372554015d1
# good: [b5e350f919acb8ef6961bc1b62e395f53cea123a] agp/intel: Use pci_bus_address() to get GTTADR bus address
git bisect good b5e350f919acb8ef6961bc1b62e395f53cea123a
# bad: [d56dbf5bab8ce44c5407bb099f71987f58d18bb4] PCI: Allocate 64-bit BARs above 4G when possible
git bisect bad d56dbf5bab8ce44c5407bb099f71987f58d18bb4
# good: [167b1f049008b367a9003a6a8df090af4282a6b0] agp/ati: Use PCI_COMMAND instead of hard-coded 4
git bisect good 167b1f049008b367a9003a6a8df090af4282a6b0
# good: [f75b99d5a77d63f20e07bd276d5a427808ac8ef6] PCI: Enforce bus address limits in resource allocation
git bisect good f75b99d5a77d63f20e07bd276d5a427808ac8ef6
----------------------------------------------------------------

Great, thanks for doing this!

Could you try to revert this commit and check whether it makes things working?
It seems still cleanly revertable on the latest Linus git tree via
   git revert d56dbf5bab8ce44c5407bb099f71987f58d18bb4

Great! The soundcard is detected in the last version (with the applied revert):

$ cat /proc/asound/cards
 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xd0080000 irq 26

$ dmesg | grep -i snd
[    8.999253] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[    9.243600] snd_hda_codec_analog hdaudioC0D0: autoconfig for AD1981: line_outs=1 (0x5/0x0/0x0/0x0/0x0) type:speaker
[    9.243605] snd_hda_codec_analog hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    9.243625] snd_hda_codec_analog hdaudioC0D0:    hp_outs=1 (0x6/0x0/0x0/0x0/0x0)
[    9.243628] snd_hda_codec_analog hdaudioC0D0:    mono: mono_out=0x0
[    9.243630] snd_hda_codec_analog hdaudioC0D0:    inputs:
[    9.243634] snd_hda_codec_analog hdaudioC0D0:      Internal Mic=0x18
[    9.243637] snd_hda_codec_analog hdaudioC0D0:      Mic=0x8


I think I've done well to come back from the tests and revert the commit:

$ git bisect reset
$ git fetch --all
$ git reset --hard origin/master
$ git revert d56dbf5bab8ce44c5407bb099f71987f58d18bb4
$ make silentoldconfig
... and build, install, reboot,..

What do you thing?

Yes, thanks, that's very helpful.

Yinghai, Bjorn, could you guys take a look?  I've got a few other bug reports (no codec detected), and all are relatively old hardware.

Sounds like the PCI core is assigning an address to the card that doesn't work.

Dayer, can you attach a complete dmesg log from the newest kernel where it doesn't work?

d56dbf5bab8c had a problem that was fixed by 7fc986d8a972 ("PCI: Support 64-bit bridge windows if we have 64-bit dma_addr_t").  d56dbf5bab8c appeared in v3.14, and the fix (7fc986d8a972) appeared in v3.18.  You're seeing the problem in v4.0.2, so this must be a different problem.  The dmesg log should help clarify things.

Takashi, do you have pointers to the other similar reports?  Maybe they already contain enough information to tell if they're the same problem as Dayer is seeing.

One bug I remember is this:
  https://apibugzilla.novell.com/show_bug.cgi?id=907092

The last entry contains the dmesg from 4.0.2.

There are some others, IIRC, on bugzilla.kernel.org.  But one bug I took a look was based on 3.16.

Created attachment 178731 [details]
dmesg in 4.1.0-rc5 (no detected soundcard)

dmesg log requested from https://bugzilla.kernel.org/show_bug.cgi?id=99221#c6
without soundcard detected.

If you need I could attach also the config file.
Yesterday and today I'm building the kernel after use "make localmodconfig", although when I put the first message I'd tried the 4.0.2 version from Debian, with a configuration more general.

Takashi, the Novell bugzilla (907092) is private, so I can't see it.

Dayer, can you try booting with "pci=use_crs"?

Your BIOS is from 2007, and we only use PCI _CRS info by default for 2008 and later.  On machines like yours, we assume the whole physical address space (excluding RAM and other devices) is available for PCI.  So we assume the [mem 0x100000000-0x100003fff] area is available, and we assign that to the 00:1b.0 sound device.  We put the _CRS info in the dmesg log even though we're ignoring it, and it doesn't show any space above 4G as being available:

  DMI: TOSHIBA SATELLITE PRO U200/Portable PC, BIOS Version 3.60 04/26/2007
  PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
  acpi PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xd0000000-0xefffffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xf4000000-0xfebfffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xfec18000-0xfec1ffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xfec28000-0xfecfffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xfed00400-0xfed13fff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xfed1a000-0xfed1bfff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xfed40000-0xfed44fff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xfed90000-0xfed9ffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xfedc0000-0xfedfffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xfee01000-0xffafffff window] (ignored)
  acpi PNP0A08:00: host bridge window [mem 0xffc00000-0xffdfffff window] (ignored)
  PCI: root bus 00: using default resources
  pci_bus 0000:00: root bus resource [mem 0x00000000-0xfffffffff]

I think it's foolish to ignore _CRS and then assume that space above 4GB is usable for PCI.

Created attachment 178771 [details]
dmesg from 4.1.0-rc5 launched with pci=use_crs

Great! With your idea the sound card is detected.

It's tempting to get rid of the date check in pci_acpi_crs_quirks() and just use _CRS all the time.

We really haven't found any problems with the current _CRS parsing code.  We *do* blacklist two systems and explicitly turn off _CRS because of a suspend/resume problem, but I don't believe the bug report (https://bugzilla.redhat.com/show_bug.cgi?id=769657) ever got to a root cause, so I doubt it's really a _CRS problem.

Dayer, your log in comment #11 includes this error:

  [drm:intel_enable_lvds [i915]] *ERROR* timed out waiting for panel to power on

I doubt that's related to _CRS, but it doesn't appear in your other log, so I don't know what it means.  Do you have any idea?

Created attachment 178831 [details]
dmesg from 4.1.0-rc5 (2)

dmesg without pci=use_crs.
Second attempt.

Created attachment 178841 [details]
dmesg from 4.1.0-rc5 (2) with pci=use_crs

dmesg with pci=use_crs.
Second attempt, with the same conditions than the previous second attempt but with pci=use_crs.

I've repeated the tests in order to avoid some possible influence of disconnect a WiFi interface or start session with X.

I think the error about i915 with pci=use_crs is present in both files from this second attempt:

$ grep i915 dmesg_2_4.1.0-rc5.txt 
[drm] Initialized i915 1.6.0 20150327 for 0000:00:02.0 on minor 0
[drm:intel_enable_lvds [i915]] *ERROR* timed out waiting for panel to power on
i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
i915 0000:00:02.0: registered panic notifier

$ grep i915 dmesg_2_4.1.0-rc5_pci-use-crs.txt 
[drm] Initialized i915 1.6.0 20150327 for 0000:00:02.0 on minor 0
[drm:intel_enable_lvds [i915]] *ERROR* timed out waiting for panel to power on
i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
i915 0000:00:02.0: registered panic notifier

(In reply to Bjorn Helgaas from comment #10)
> Takashi, the Novell bugzilla (907092) is private, so I can't see it.

Oops, sorry.  Try to look from bugzilla.opensuse.org:
   https://bugzilla.opensuse.org/show_bug.cgi?id=907092

> Dayer, can you try booting with "pci=use_crs"?

I'll ask the reporter of the bug above, too.

It seems the use of "pci=use_crs" fix also the problem of the another bug: https://bugzilla.opensuse.org/show_bug.cgi?id=907092#c55

Created attachment 180111 [details]
quirk to enable pci=use_crs

Dayer, would you mind testing this patch?  With it, you shouldn't need to use "pci=use_crs".  Please attach a complete dmesg log if you test it.  Thanks!

Created attachment 180121 [details]
4.1.0 rc8 with patch

Created attachment 180131 [details]
4.1.0 without patch

I've updated to 4.1-rc8 (commit 0f57d86787d8b1076ea8f9cbdddda2a46d534a27) and tested your patch. I don't know why I get sound with and without your patch.
I've seen something related to problems with sound and HDA (like commits 2fbbada1e1f321a0d525eae77d45acb56e7e9b52, 535115b5ff51c702a9a22feb918707c2fe1fbd17, a686ec4c5f28eb1b384e4b87b08543155c970072, bf06848bdbe549175d25d2327ab9f37d4bd556b7,..)

I attach the dmesg with and without the patch.

If you need I could checkout an older version and apply the patch.

Thanks, Dayer.  Hmm, another puzzle.

In attachment 178731 [details], where sound did not work, there was an e100 NIC at 03:08.0, and the BIOS didn't assign space to the sound device at 00:1b.0.  Linux assigned the wrong space, so it didn't work.

In attachments 180121 and 180131, where sound does work, there was no e100 NIC, and BIOS did assign space to the 00:1b.0 sound device, so Linux didn't even try any address assignment, so the patch really didn't make any difference.

Do you have any idea why the e100 device would be different?  Was that an ExpressCard or something?  Maybe sound is only broken with an ExpressCard installed?

Created attachment 180141 [details]
4.1.0 rc8 without patch and with NIC enabled

Sorry! That was my fault trying to disable the wake on lan from the BIOS four days ago. I was wrong and I disabled the interface unintentionally.
But I've reactivated the NIC from the BIOS and now I can see it again in dmesg and I get sound.

I don't know what recent commit fix my problem, but I hope it stays.

I'm pretty sure no recent Linux change fixed the problem.

It works when BIOS assigns resources to all the devices, and it fails when BIOS leaves some unassigned and Linux does the assignment.

Here's a diff of the device resource assignments from BIOS (-failing, +working):

-pci 0000:00:02.1: reg 0x10: [mem 0x00000000-0x0007ffff]
-pci 0000:00:1b.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
+pci 0000:00:02.1: reg 0x10: [mem 0xffc80000-0xffcfffff]
+pci 0000:00:1b.0: reg 0x10: [mem 0xffd3c000-0xffd3ffff 64bit]
-pci 0000:03:0b.1: reg 0x10: [mem 0x00000000-0x000007ff]
-pci 0000:03:0b.1: reg 0x14: [mem 0x00000000-0x00003fff]
-pci 0000:03:0b.2: reg 0x10: [mem 0x00000000-0x00000fff]
-pci 0000:03:0b.3: reg 0x10: [mem 0x00000000-0x000000ff]
+pci 0000:03:0b.1: reg 0x10: [mem 0xff9fe800-0xff9fefff]
+pci 0000:03:0b.1: reg 0x14: [mem 0xff9f8000-0xff9fbfff]
+pci 0000:03:0b.2: reg 0x10: [mem 0xff9fd000-0xff9fdfff]
+pci 0000:03:0b.3: reg 0x10: [mem 0xff9fe700-0xff9fe7ff]

When sound doesn't work, BIOS has not assigned resources to:

  00:02.1 [8086:27a6] Intel graphics
  00:1b.0 [8086:27d8] Intel sound
  03:0b.1 [104c:803a] TI 1394 controller
  03:0b.2 [104c:803b] TI multimedia card reader
  03:0b.3 [104c:803c] TI SD controller

So if you can figure what configuration or BIOS switch caused the BIOS to leave them unassigned, I'm pretty sure sound (and maybe other things) will still fail.

Created attachment 180201 [details]
dmesg 4.1.0-rc5 wihout pci=use_crs but with sound

Excuse me Bjorn Helgaas. I can't find what was causing the bug.

Now I've tried running v4.1.0-rc5 (the same, without rebuild, because I've saved its image) without pci=use_crs and I get sound.

I've compared its dmesg from now with the attachment #178831 [details] (the same version who I tested without pci=use_crs and without sound a few days ago) and I don't know the reason, but the sound goes. It's the same kernel, the same build,..

I've also rebooted the laptop, reset the BIOS config with default values and tried with a live distro and another kernel version who had no sound two weeks ago (4.0.4 version) and now the sound runs. It goes also with my installed Linux and 3.14.0 and 3.16.7 kernels.

Could it be for any BIOS settings that I didn't know? Now I'm not sure if my problem was the same that the other bug[1].

Perhaps, for me it's time to change this computer...

[1] https://bugzilla.opensuse.org/show_bug.cgi?id=907092

Created attachment 180221 [details]
dmesg from 4.1.0-rc8 with patch after Windows

Hi again. I've found the guilty: MS Windows. I forgot to say.

After the previous comment, I've booted in Windows and in Linux. Then, I haven't sound in others kernels. I've went into the BIOS, save, reboot in Linux and the sound has came back.

Bjorn Helgaas, according to this discovery I've tested your patch (attachment #180111 [details]) with this results in kernel 4.1.0-rc8 after boot in Windows:

- With patch: I get sound.
- Without patch, with pci=use_crs in grub: I get sound.
- Without patch, without pci=use_crs in grub: I get no sound.

I'm closing this as fixed by 3d9fecf6bfb8 ("x86/PCI: Use host bridge _CRS info on systems with >32 bit addressing"), which appeared in v4.2 [1].

If this is still a problem, please re-open and we can take another look.

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d9fecf6bfb8