Re: [3.18.3 BISECTED REGRESSION] scx200_acb / cs5535-smb / geodewdt / cs5535-clockevt torpedoed

[Bjorn Helgaas]

On Mon, Feb 2, 2015 at 11:36 AM, Nix <nix@xxxxxxxxxxxxx> wrote:
> On 2 Feb 2015, Myron Stowe verbalised:
>
>> Nix:
>>
>> Thanks for the work you've already done with the bisection.  Let's see
>> if we can get to the bottom of this.  Would you capture two couple sets
>> of logs, one without the issue and another set with the commit at issue
>> included for comparison.

>  pci 0000:00:14.0: [1022:2090] type 00 class 0x060100
> -pci 0000:00:14.0: reg 0x10: [io  0x6000-0x7fff]
> -pci 0000:00:14.0: reg 0x14: [io  0x6100-0x61ff]
> -pci 0000:00:14.0: reg 0x18: [io  0x6200-0x63ff]
>  pci 0000:00:14.0: CS5536 ISA bridge bug detected (incorrect header); workaround applied

> +scx200_acb: can't allocate io 0x0-0x7

I think the problem is that these three BARs are read-only.  Prior to
36e8164882ca, we didn't detect that, and we computed the size based on
the lowest order bit that was set in the address.  This gave us
incorrect sizes, but it did work in the sense that the driver could
operate the device.

After 36e8164882ca, we detect that the BARs are read-only and ignore
them completely, which breaks this case because we don't mark the
resource as I/O and we don't fill in the starting address, so even
though the quirk runs, it just sets the first resource to [???
0x0000-0x0007], which doesn't work.

I think this is the right behavior for the PCI core because we can't
tell how big these BARs are.  The only alternative is to assume they
are as big as possible given their current addresses.  But that would
mean a 4KB read-only BAR that happened to be aligned on a 2GB boundary
would have to consume 2GB of address space, and *that* doesn't seem
reasonable.

We already have a quirk for this device, so I think the best fix is to
change the quirk so it reads these three BARs directly and restores
the resources based on its hard-coded knowledge of how big they are.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/