linux-kernel - Re: [BUGFIX 0/9] Fix bug 59501 and code improvement for dock driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE9FiQX-jCZYPyxeHCp2h-6qx1GMyQYuaTk5JwZR6H1t4jRg9g@mail.gmail.com>
Date:	Thu, 13 Jun 2013 19:30:14 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	"Jiang Liu (Gerry)" <jiang.liu@...wei.com>
Cc:	"Rafael J . Wysocki" <rjw@...k.pl>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"Alexander E . Patrakov" <patrakov@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Yijing Wang <wangyijing@...wei.com>,
	Jiang Liu <liuj97@...il.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [BUGFIX 0/9] Fix bug 59501 and code improvement for dock driver

On Thu, Jun 13, 2013 at 7:09 PM, Jiang Liu (Gerry) <jiang.liu@...wei.com> wrote:
> On 2013/6/14 2:42, Yinghai Lu wrote:
>>
>> On Thu, Jun 13, 2013 at 9:32 AM, Jiang Liu <jiang.liu@...wei.com> wrote:
>>>
>>> Alexander E. Patrakov <patrakov@...il.com> reports two bugs related to
>>> dock station support on Sony VAIO VPCZ23A4R. Actually there are at least
>>> four bugs related to Sony VAIO VPCZ23A4R dock support.
>>> 1) can't correctly detect hotplug slot for dock state
>>> 2) resource leak on undocking
>>> 3) resource allocation failure for dock devices
>>> 4) one bug in intel_snd_hda driver
>>>
>>> The first patch fixes issue 1, and the second patch fixes issue 2.
>>> These two patches, if accepted, should be material for stable branches
>>> too.
>>> Patch 3-9 are code improvement for ACPI and dock driver.
>>>
>>> I have found the root cause for issue three, but still working on
>>> solutions, and seems can't be solve in short time. So please help
>>> to review and test patches for issue 1) and 2) first.
>>
>>
>> the 3) is about pci resource allocation?
>> because pcibios_add_bus is called too early?
>>
>> If that is case, we should have something like attached patch for it.
>>
>> With that, we will not need to worry about _OSC set for 3.10 etc.
>>
> Hi Yinghai,
>    Seems not related to pcibios_add_bus(). According to my
> investigation, the issue is caused by difference in PCI resource
> assignment between boot time and runtime hotplug. On x86 platforms,
> it respects PCI resource assignment from BIOS and only reassign
> resources for unassigned BARs. But with acpiphp, it ignores BIOS
> resource assignment and reassign all resources by OS.
>    If we have enough resources, reassigning all PCI resources should
> work too, but may fail if we are under resource constraints. On the
> other handle, current PCI IOMM align algorithm may waste huge MMIO
> address space if we have some PCI devices with huge IOMM BAR.
>    On this Sony laptop, BIOS allocates limited IOMM resources for
> the dock station and the dock station has a gfx which has a 256MB
> IOMM BAR. So current acpiphp driver fails to allocate resources
> for most devices on the dock station.

Is it a regression?

>     Currently I'm trying to change acpiphp to respect BIOS resource
> assignment by calling pcibios_survey_resource_bus(), as in pci_root.c.
> The other way is to change the IOMM resource allocation algorithm,
> but obviously it's much more risky of regressions if changing the
> algorithm.

that is not going to help, need to increase bridge resource.

please check if BIOS have setup option about hotplug MMIO pad size.

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