gi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
---
drivers/pci/host-bridge.c |7 +++
drivers/pci/pci.h |1 +
drivers/pci/probe.c |9 +
dr
On Wed, Dec 10, 2014 at 2:30 PM, Gavin Shan wrote:
> On Tue, Dec 09, 2014 at 01:34:31PM -0800, Yinghai Lu wrote:
>>
>>+ list_for_each_entry(window, &bridge->windows, list) {
>>+ res = window->res;
>>+ if
On Wed, Dec 10, 2014 at 6:34 AM, Wei Yang wrote:
> My mutt hang, in case the mail isn't sent out, I resend it.
>
> On Wed, Dec 10, 2014 at 10:15:37PM +0800, Wei Yang wrote:
>>On Tue, Dec 09, 2014 at 03:13:49PM -0800, Yinghai Lu wrote:
>>>On Tue, Dec 9, 2014 at
lable for that
> purpose, so replace resource_to_addr() with public interfaces.
>
> Signed-off-by: Jiang Liu
> Reviewed-by: Bjorn Helgaas
> Cc: Konrad Rzeszutek Wilk
> Cc: Tony Luck
> Cc: Joerg Roedel
> Cc: Greg Kroah-Hartman
> Cc: Benjamin Herrenschmidt
> Cc: Rafae
On Tue, Dec 9, 2014 at 2:15 PM, Marek Kordík wrote:
> On 12/09/2014 08:42 PM, Yinghai Lu wrote:
>>
>> On Tue, Dec 9, 2014 at 10:22 AM, Bjorn Helgaas
>> wrote:
>>>
>>> On Tue, Dec 9, 2014 at 11:07 AM, Marek Kordík
>>> wrote:
>>>>
>&g
On Tue, Dec 9, 2014 at 1:53 PM, Bjorn Helgaas wrote:
> On Tue, Dec 9, 2014 at 2:34 PM, Yinghai Lu wrote:
>> + list_for_each_entry(window, &bridge->windows, list) {
>> + res = window->res;
>> + if (resou
On Mon, Dec 8, 2014 at 4:09 PM, Yinghai Lu wrote:
> On Mon, Dec 8, 2014 at 3:00 PM, Benjamin Herrenschmidt
> wrote:
>
>>
>> I think an option would be to keep track of whether the PCI host bridge
>> can do 64-bit pref above 4G.
>
> Yes, that could be enhancement
("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
---
drivers/pci/host-bridge.c |7 +++
drivers/pci/pci.h |1 +
drivers/pci/probe.c |9 +
drivers/pci/setup-bus.c |3 +++
include/linux/pci.h
On Mon, Dec 8, 2014 at 11:56 PM, Wei Yang wrote:
> Two comments to this patch:
> 1. realloc_head is not necessary here
why ?
want to align that with pbus_size_mem.
> 2. In case we have two MEM BAR under a bus, one is MEM64|PREF and one is PREF,
> after this patch, the MEM64 flag will be cleare
On Tue, Dec 9, 2014 at 10:22 AM, Bjorn Helgaas wrote:
> On Tue, Dec 9, 2014 at 11:07 AM, Marek Kordík wrote:
>> I have built and booted your branch and it works well. Do you want me to
>> attach some logs?
>> (I am new here and I have read http://www.tux.org/lkml/ and I don't want to
>> break som
On Mon, Dec 8, 2014 at 6:26 PM, Wei Yang wrote:
> On Tue, Dec 09, 2014 at 11:11:19AM +1100, Gavin Shan wrote:
>>
>>I'm going to give it a spin and Richard, could you please apply Yinghai's
>>patch to see if your SRIOV code can work properly?
>>
>
> I did a quick test on my machine. This patch does
On Mon, Dec 8, 2014 at 5:08 PM, Gavin Shan wrote:
> On Mon, Dec 08, 2014 at 03:59:54PM -0800, Yinghai Lu wrote:
>
> Yinghai, With the patch, the Power8 machine boots up and have resources
> assigned properly: 64-bits pref BARs are covered by 64-bits pref windows
> and left memory B
On Mon, Dec 8, 2014 at 3:00 PM, Benjamin Herrenschmidt
wrote:
>
> I think an option would be to keep track of whether the PCI host bridge
> can do 64-bit pref above 4G.
Yes, that could be enhancement.
That should fix the problem Marek's
But not on Zermond's, as his system is not using _CRS.
O
On Mon, Dec 8, 2014 at 2:56 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2014-12-08 at 13:52 -0800, Yinghai Lu wrote:
>> 2. or scan the children resource other than ROM to clear bridge MEM_64
>>for mmio pref.
>>
>> The patch is using second way so will keep child mm
will keep child mmio pref into bridge
mmio pref range.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: zerm...@gmail.com
Reported-and-tested-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signe
tile should be:
[PATCH] x86:
On Tue, Nov 25, 2014 at 11:14 AM, Louis Langholtz wrote:
> The cmp_range function (in kernel/range.c) is returning the difference
> between two s64 values (actually coming from u64 typed variables) in an int
> which can overflow (depending on the size of int).
Link: https://bugzilla.kernel.org/show_bug.cgi?id=88131
Reported-by: Aaron Ma
Tested-by: Aaron Ma
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/page.h|8
arch/x86/include/asm/pgtable.h |4 ++--
arch/x86/mm/ioremap.c |6 --
arch/x86/mm/pat.c |3 +
On Tue, Nov 18, 2014 at 5:44 PM, Yinghai Lu wrote:
> add cleanup_highmap_late to remove highmap for initmem, around rodata, and
> [_brk_end, all_end).
Sorry, title should be 3/3 instead of 3/4.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
-0xa000 444M pmd
So remove some range before rodata with RW+x.
-v4: adapt it to all_end change.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init_64.c | 62 ++
1 file changed, 62 insertions(+)
Index: linux
Need to use it to support holes in highmap when remove not
used range in highmap.
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/pgtable_64.h |2 ++
arch/x86/mm/init_64.c | 22 ++
arch/x86/mm/pageattr.c| 16 +---
3 files
In the comment, should use cleanup_highmap().
and also remove not needed cast for _brk_end, as it is
unsigned long.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init_64.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/x86/mm/init_64.c
limit to avoid overflow.
-v2: add u64 cast to avoid compiler warning.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=88131
Reported-by: Aaron Ma
Tested-by: Aaron Ma
Signed-off-by: Yinghai Lu
---
drivers/pci/probe.c | 22 +++---
1 file changed, 11 insertions(+), 11 dele
really should unmap the reminder along with the holes
> caused by init,initdata etc. but thats a different issue ]
>
> Signed-off-by: Kees Cook
> Cc: Andy Lutomirski
> Cc: Toshi Kani
> Cc: Yasuaki Ishimatsu
> Cc: David Vrabel
> Cc: Wang Nan
> Cc: Yinghai Lu
that area gets used later on then we are
>> going to split up the PMD anyway.
>
> That's fine by me. Yinghai Lu seems to have potentially better
> solutions, but my head is spinning after reading more of this thread.
> :) I just want to make sure that at the end of the day,
On Sun, Nov 16, 2014 at 3:44 PM, Thomas Gleixner wrote:
>
> _brk_end is adjusted at boot time via extend_brk() up to __brk_limit,
> which is the same as _end. We usually do not use all of that space. So
> it's expected that _brk_end < _end.
>
>> Is this correct? It sounded like tglx wanted the pmd
On Sun, Nov 16, 2014 at 1:26 PM, Thomas Gleixner wrote:
> On Sat, 15 Nov 2014, Yinghai Lu wrote:
>> +static pmd_t *last_pmd;
>> /*
>> * The head.S code sets up the kernel high mapping:
>> *
>> @@ -408,9 +409,26 @@ void __init cleanup_highmap(void)
>>
On Sun, Nov 16, 2014 at 10:52 AM, Thomas Gleixner wrote:
>> >
>> > Are you sure? For me, _brk_end isn't far enough:
>> >
>> > [1.475572] all_end: 0x82df5000
>> > [1.476736] _brk_end: 0x82dd6000
>>
>> Yes. _brk_end should be small then &_end.
>
> Wrong. _brk_end can move up
On Fri, Nov 14, 2014 at 7:38 PM, Yinghai Lu wrote:
> On Fri, Nov 14, 2014 at 6:46 PM, Kees Cook wrote:
>> Is this correct? It sounded like tglx wanted the pmd split, like this:
>>
>> 0x8220-0x82c010M RW PSE GLB NX pmd
>> 0x
On Fri, Nov 14, 2014 at 6:46 PM, Kees Cook wrote:
> On Fri, Nov 14, 2014 at 6:29 PM, Yinghai Lu wrote:
>> should use attached one instead.
>>
>> 1. should use _brk_end instead of &end, as we only use partial of
>>brk.
>> 2. [_brk_end, pm_end) page ran
On Fri, Nov 14, 2014 at 7:06 PM, Kees Cook wrote:
> On Fri, Nov 14, 2014 at 5:29 PM, Yinghai Lu wrote:
>>
>> [0.00] .text: [0x0100-0x0200d548]
>> [0.00] .rodata: [0x0220-0x02a1cfff]
>> [0.00] .data: [0x02c0-0x02e50e7f
On Fri, Nov 14, 2014 at 5:29 PM, Yinghai Lu wrote:
> On Fri, Nov 14, 2014 at 12:45 PM, Kees Cook wrote:
>> v2:
>> - added call to free_init_pages(), as suggested by tglx
> something is wrong:
>
> [7.842479] Freeing unused kernel memory: 3844K (82e52
On Fri, Nov 14, 2014 at 12:45 PM, Kees Cook wrote:
> When setting up permissions on kernel memory at boot, the end of the
> PMD that was split from bss remained executable. It should be NX like
> the rest. This performs a PMD alignment instead of a PAGE alignment to
> get the correct span of memor
=88131
Reported-by: Aaron Ma
Tested-by: Aaron Ma
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/page.h|8
arch/x86/include/asm/pgtable.h |4 ++--
arch/x86/mm/ioremap.c |6 --
arch/x86/mm/pat.c |3 +++
4 files changed, 17 insertions
limit to avoid overflow.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=88131
Reported-by: Aaron Ma
Tested-by: Aaron Ma
Signed-off-by: Yinghai Lu
---
drivers/pci/probe.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
Index: linux-2.6/drivers/pci/pr
t or downstream port.
We could just change to pcie_cap_has_lnkctl to cover all pcie devices with
link control cap.
-v2: Do not move pcie_cap_has_lnkctl() out of pci/access.c according to Bjorn.
Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration")
Signed-off-by: Yin
On Mon, Nov 10, 2014 at 8:23 PM, Bjorn Helgaas wrote:
>
> But I don't want to move pcie_cap_has_lnkctl() to pci.h and leave
> pcie_cap_has_sltctl() and pcie_cap_has_rtctl() in access.c. They're all
> related, so I think they should stay together.
>
> What if we left them in access.c, made them no
t or downstream port.
We could just change to pcie_cap_has_lnkctl to cover all pcie devices with
link control cap.
Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration")
Signed-off-by: Yinghai Lu
---
drivers/pci/access.c | 13 -
drivers/pci/pci.h
handle = ACPI_HANDLE(dev);
> + }
> + return handle;
> +}
Also found another problem,
pci_device_add==>pci_configure_device==>program_hpp_type2() path.
and program_hpp_type2() will check dev->subordinate().
but at the time child bridge is not scanned yet.
Maybe we should
On Tue, Nov 4, 2014 at 9:22 AM, tip-bot for Daniel J Blueman
wrote:
> Commit-ID: bdee237c0343a5d1a6cf72c7ea68e88338b26e08
> Gitweb: http://git.kernel.org/tip/bdee237c0343a5d1a6cf72c7ea68e88338b26e08
> Author: Daniel J Blueman
> AuthorDate: Tue, 4 Nov 2014 16:29:44 +0800
> Committer: Tho
Commit-ID: 5e4df93bbb0be6203a0037676a430abf5373a70e
Gitweb: http://git.kernel.org/tip/5e4df93bbb0be6203a0037676a430abf5373a70e
Author: Yinghai Lu
AuthorDate: Mon, 27 Oct 2014 16:11:55 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 5 Nov 2014 18:10:46 +0100
x86, irq: Convert
Commit-ID: ad6b879eac110587bc6dc01ccea479e15de017df
Gitweb: http://git.kernel.org/tip/ad6b879eac110587bc6dc01ccea479e15de017df
Author: Yinghai Lu
AuthorDate: Mon, 27 Oct 2014 16:11:55 +0800
Committer: Thomas Gleixner
CommitDate: Wed, 5 Nov 2014 11:04:46 +0100
x86, irq: Convert
Commit-ID: 8cda974ab278dd8d4a9024085535f71175ddf38d
Gitweb: http://git.kernel.org/tip/8cda974ab278dd8d4a9024085535f71175ddf38d
Author: Yinghai Lu
AuthorDate: Mon, 27 Oct 2014 13:21:39 +0800
Committer: Thomas Gleixner
CommitDate: Mon, 3 Nov 2014 11:56:07 +0100
x86, irq: Split out
Commit-ID: 717ed6192d16cecf06b7412bf07c207ed92a9f52
Gitweb: http://git.kernel.org/tip/717ed6192d16cecf06b7412bf07c207ed92a9f52
Author: Yinghai Lu
AuthorDate: Mon, 27 Oct 2014 13:21:37 +0800
Committer: Thomas Gleixner
CommitDate: Mon, 3 Nov 2014 11:56:07 +0100
ACPI: Add interfaces to
Commit-ID: b141cb5363583a887ab2d6f742bc849f615634ff
Gitweb: http://git.kernel.org/tip/b141cb5363583a887ab2d6f742bc849f615634ff
Author: Yinghai Lu
AuthorDate: Mon, 27 Oct 2014 13:21:40 +0800
Committer: Thomas Gleixner
CommitDate: Mon, 3 Nov 2014 11:56:07 +0100
x86, irq: Prefer assigned
On Fri, Oct 31, 2014 at 5:00 PM, Wilmer van der Gaast wrote:
> Hello,
>
> Patch #1 worked after a simple s/&&/)/. And patch #2 seems to fix the
> problem as well!
updated first #1.
---
drivers/pci/pci.c | 18 ++
1 file changed, 18 insertions(+)
Index: linux-2.6/drivers/pci/pci
printf.c in x86 setup code.
And print out decompress_kernel input and output info.
Later decompresser code could print out more info for debug info.
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/Makefile |2 +-
arch/x86/boot/compressed/misc.c |8
arch/x86/boot/comp
On Fri, Oct 31, 2014 at 2:22 PM, Yinghai Lu wrote:
> On Fri, Oct 31, 2014 at 2:13 PM, Wilmer van der Gaast
> wrote:
>> On 31-10-14 16:11, Yinghai Lu wrote:
>>>
>>>
>>> Good. Please check if attached one on top of 3.17 only would work too.
>>>
On Fri, Oct 31, 2014 at 2:13 PM, Wilmer van der Gaast wrote:
> On 31-10-14 16:11, Yinghai Lu wrote:
>>
>>
>> Good. Please check if attached one on top of 3.17 only would work too.
>>
> No luck, sadly. :-( Unsuccessful third resume.
>
> I forgot to set up the
On Fri, Oct 31, 2014 at 2:39 AM, Wilmer van der Gaast wrote:
> Hello Yinghai,
>
> On 31-10-14 02:13, Yinghai Lu wrote:
>>
>> Last try:
>>
>> Please check attached patch that will keep state consistent.
>
>
> Good news: This last patch worked! For good me
On Thu, Oct 30, 2014 at 5:43 PM, Yinghai Lu wrote:
> On Thu, Oct 30, 2014 at 4:24 PM, Wilmer van der Gaast
> wrote:
>>
>>
>> Same problem like this morning: Failure after the second resume already. :-(
>>
> can not find out any magic line in pci_enable_bridge
On Thu, Oct 30, 2014 at 4:24 PM, Wilmer van der Gaast wrote:
>
>
> Same problem like this morning: Failure after the second resume already. :-(
>
can not find out any magic line in pci_enable_bridge that could cause
the difference.
so either use attached pcie_enable_bridge_ite.patch or just rever
On Thu, Oct 30, 2014 at 2:54 PM, Wilmer van der Gaast wrote:
> http://gaast.net/~wilmer/.lkml/good3.17-patched-megadebug.txt
no difference except on 00:1c.3
--- before.txt2014-10-30 15:20:35.782886485 -0700
+++ after.txt2014-10-30 15:21:37.034882515 -0700
@@ -49,10 +49,10 @@
02f0: 00 0
On Thu, Oct 30, 2014 at 10:09 AM, Bjorn Helgaas wrote:
> [+cc Rafael, linux-acpi]
> This raises the question of what the correct behavior should be. Your
> patch certainly avoids the NULL pointer dereference. It does so by making
> acpi_pci_get_bridge_handle() fail gracefully, which means we wi
t out pci conf space before
...and after...
Subject: [PATCH] pci: print out about pci=dump
debug print out before later driver hang
Signed-off-by: Yinghai Lu
---
drivers/pci/pci.c | 52 +++-
1 file changed, 51 insertions(+), 1 deletion(-)
Ind
On Wed, Oct 29, 2014 at 2:37 AM, Wilmer van der Gaast wrote:
>
>> Anyway please try attached patched on top of 3.17.
>>
> Done, and that did work! Four suspend+resume cycles later and it's still
> stable.
Then can you test attached simplified one.
---
drivers/pci/pci.c | 13 +
1 fi
or every pci_dev,
including VF that is under virtual bus. But virtual bus does not have bridge
set. So we can not refer pbus->self->dev directly.
Add checking with pbus->slef and bail out early.
Fixing: commit 6cd33649fa83 ("PCI: Add pci_configure_device() during
enumeration")
Signe
On Tue, Oct 28, 2014 at 4:34 PM, Wilmer van der Gaast wrote:
>
> I've run the commands twice, once before and once after a single
> suspend+resume cycle. Small difference and only before that cycle:
>
> ruby:~/crashit# diff -u lspcixx-*
> --- lspcixx-nopatch.txt 2014-10-28 23:26:08.679690828 +
On Mon, Oct 27, 2014 at 6:12 PM, Yinghai Lu wrote:
> On Mon, Oct 27, 2014 at 5:03 PM, Wilmer van der Gaast
> wrote:
>> I was curious about that already, did that with a 3.16.6 that I think just
>> had your revert applied (and using lspci - to get the dump which I
>&
On Mon, Oct 27, 2014 at 5:03 PM, Wilmer van der Gaast wrote:
> I was curious about that already, did that with a 3.16.6 that I think just
> had your revert applied (and using lspci - to get the dump which I
> assumed would be the same): No changes to 04:00 at all.
>
> Confirmed that this is th
On Mon, Oct 27, 2014 at 3:22 PM, Wilmer van der Gaast wrote:
> Hello,
>
> On 27-10-14 18:23, Yinghai Lu wrote:
>>
>>
>> 04:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892
>>
>> So that ITE will not work after suspend/resume?
>>
>
fore suspend/resume test.
Thanks
Yinghai
Subject: [PATCH] PCI: Add generic pcie_link_disable
Remove not needed return value checking that Linus pointed out before.
Will use it from /sys/.../pcie/link_disable
Signed-off-by: Yinghai Lu
---
drivers/pci/Makefile|2 +-
drivers/pci/pcie-l
ro BTW.)
Please try attached two debug patches to check the pci registers
between the suspend/resume.
Subject: [PATCH] pci: print out about pci=dump
debug print out before later driver hang
Signed-off-by: Yinghai Lu
---
drivers/pci/pci.c | 52 ++
On Tue, Oct 21, 2014 at 2:40 PM, Wilmer van der Gaast wrote:
> Hello,
>
> Sorry for the delay, finally poked at this again. It looks like the
> no_console_suspend flag was causing troubles, which I didn't really need
> anyway with logging going to my serial port.
>
> This is what I get now on the
On Sat, Oct 18, 2014 at 4:57 PM, Wilmer van der Gaast wrote:
> On 18-10-14 22:28, Yinghai Lu wrote:
>>
>> Please apply attached debug patch on top of v3.17 and boot with
>> "debug ignore_loglevel initcall_debug no_console_suspend".
>>
>> Hope we c
On Thu, Oct 16, 2014 at 2:08 PM, Wilmer van der Gaast wrote:
> Did that on this run, no difference either. For full completeness, I
> reproduced this problem with no modules loaded (done from initramfs) at all,
> with a kernel with your workaround included, logs are here:
> http://gaast.net/~wilme
On Thu, Oct 16, 2014 at 2:36 AM, Wilmer van der Gaast wrote:
> Hello,
>
> On 16-10-14 05:32, Yinghai Lu wrote:
>>
>>
>> Can you please try attached patch? that should workaround the problem.
>>
> Sadly, no luck. (I do assume you meant me to use the patch
On Wed, Oct 15, 2014 at 4:34 PM, Wilmer van der Gaast wrote:
>
> Is there anything I can do now to find out why your change is causing my
> machine to crash?
Can you please try attached patch? that should workaround the problem.
as some driver is using pci_enable_device in .resume instead of
pci
On Wed, Oct 15, 2014 at 6:58 AM, Bjorn Helgaas wrote:
> [+cc Yinghai, author of 928bea964827 ("PCI: Delay enabling bridges
> until they're needed")]
>
> On Wed, Oct 15, 2014 at 5:16 AM, Wilmer van der Gaast
>> Not sure why 2e8b... was initially found guilty by git bisect, I fear
>> that my testin
On Mon, Sep 29, 2014 at 11:25 AM, Yinghai Lu wrote:
> On Mon, Sep 29, 2014 at 7:29 AM, Liviu Dudau wrote:
>> If the firmware has not assigned all the bus resources and we are not just
>> probing the PCI buses, it makes sense to assign the unassigned resources
>>
On Mon, Sep 29, 2014 at 7:29 AM, Liviu Dudau wrote:
> If the firmware has not assigned all the bus resources and we are not just
> probing the PCI buses, it makes sense to assign the unassigned resources
> in pci_scan_root_bus().
>
> Signed-off-by: Liviu Dudau
> Signed-off-by: Bjorn Helgaas
> CC
On Thu, Sep 25, 2014 at 11:19 AM, Joseph Salisbury
wrote:
> On 09/17/2014 03:46 AM, Yinghai Lu wrote:
>> On Tue, Sep 16, 2014 at 3:27 PM, Yinghai Lu wrote:
>>> On Tue, Sep 16, 2014 at 1:21 PM, Joseph Salisbury
>>> wrote:
>>>> A new bug[0] was opened
On Thu, Sep 25, 2014 at 8:49 AM, Joseph Salisbury
wrote:
> On 09/16/2014 06:27 PM, Yinghai Lu wrote:
>> On Tue, Sep 16, 2014 at 1:21 PM, Joseph Salisbury
>> wrote:
>>> A new bug[0] was opened due to enabling PCI_REALLOC_ENABLE_AUTO, which
>>> is similar to
On Tue, Sep 23, 2014 at 12:01 PM, Liviu Dudau wrote:
> Before commit 7b5436635800 the pci_host_bridge was created before the root
> bus.
> As that commit has added a needless dependency on the bus for
> pci_alloc_host_bridge()
> the creation order has been changed for no good reason. Revert the
On Tue, Sep 16, 2014 at 3:27 PM, Yinghai Lu wrote:
> On Tue, Sep 16, 2014 at 1:21 PM, Joseph Salisbury
> wrote:
>>
>> A new bug[0] was opened due to enabling PCI_REALLOC_ENABLE_AUTO, which
>> is similar to the original bug[1] we discussed.
>>
>> Just wonderi
On Tue, Sep 16, 2014 at 1:21 PM, Joseph Salisbury
wrote:
>
> A new bug[0] was opened due to enabling PCI_REALLOC_ENABLE_AUTO, which
> is similar to the original bug[1] we discussed.
>
> Just wondering if there have been any additional ideas on realloc since
> this was last discussed?
>
> [0] http:
On Fri, Sep 12, 2014 at 5:11 PM, Dirk Gouders wrote:
> Yinghai Lu writes:
>
> Yes, I skip them in pci_scan_device() to get the unused bus number space
> that 0a.0 and 0b.0 then can use when reconfiguration is triggered.
That is not right. Can not let two bridges use same bus num.
On Fri, Sep 12, 2014 at 3:05 PM, Dirk Gouders wrote:
> Yinghai Lu writes:
>
>> On Fri, Sep 12, 2014 at 1:54 PM, Dirk Gouders wrote:
>>> Yinghai Lu writes:
>>>
>>>> On Fri, Sep 12, 2014 at 1:05 PM, Dirk Gouders wrote:
>>>>> Dirk G
On Fri, Sep 12, 2014 at 1:54 PM, Dirk Gouders wrote:
> Yinghai Lu writes:
>
>> On Fri, Sep 12, 2014 at 1:05 PM, Dirk Gouders wrote:
>>> Dirk Gouders writes:
> -[:00]-+-01.0-[01-02]--+-0d.0-[02]--
>| +-0e.0 Broadcom BCM5785 [HT1
ize Advanced Error Capabilities and Control Register */
> + pci_read_config_dword(dev, pos + PCI_ERR_CAP, ®32);
> + reg32 = (reg32 & hpp->adv_err_cap_and) | hpp->adv_err_cap_or;
> + pci_write_config_dword(dev, pos + PCI_ERR_CAP, reg32);
> +
> + /*
> +
On Fri, Sep 12, 2014 at 1:05 PM, Dirk Gouders wrote:
> Dirk Gouders writes:
>
> I now applied your patches and tested them:
>
> echo 1 > /sys/bus/pci/devices/\:00\:0a.0/pcie_link_disable
> echo 0 > /sys/bus/pci/devices/\:00\:0a.0/pcie_link_disable
>
> The FC Adapter did not show up, this
reset the pcie link after change bus num
in the pcie bridges ?
Soultion (3)
Or we just revert the offending 1820ffdccb9b4398 (PCI: Make sure
bus number resources stay within their parents bounds) ?
Thanks
Yinghai
Subject: [PATCH] PCI: Add generic pcie_link_disable
Remove not ne
)
> ACPI Warning: AcpiEnable failed (20131218/utxfinit-169)
> ACPI: Unable to enable ACPI
>
> -- [2]
>
> commit 4ce7a8697cb795fda6bdf082c14743b4bcd551c3
> Author: Yinghai Lu
> Date: Mon Jan 27 17:06:50 2014 -0800
>
> x86: revert wrong memblock current limit settin
On Mon, Sep 8, 2014 at 3:52 PM, Rafael J. Wysocki wrote:
> On Monday, August 11, 2014 06:50:52 PM Lee, Chun-Yi wrote:
>> In arch/x86/kernel/setup.c::trim_bios_range(), the codes introduced
>> by 1b5576e6 (base on d8a9e6a5), it updates the first 4Kb of memory
>> to be E820_RESERVED region. That's b
On Thu, Sep 4, 2014 at 11:38 PM, Laszlo Ersek wrote:
> On 09/05/14 07:47, Anders Darander wrote:
> In other words, the rounding up of the kernel will be undone in a
> "somewhat higher level" driver in the firmware, and the request size
> that reaches DiskIo (the "lowel level driver") remains the s
On Thu, Sep 4, 2014 at 2:29 PM, Matt Fleming wrote:
> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>>
>> I am fine with this patch, but at the same time I do want to note that
>> there is an alternative to double-buffer the patch and/or (if that
>> applies to the buggy BIOS) round up the s
trd is too big
and does not fit under 4G.
-v2: add print out for second try, and print out files buf address.
-v3: can not snprintf
-v4: drop address print out for files buf
Reported-by: Mantas Mikulėnas
Tested-by: Anders Darander
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/eboo
trd is too big
and does not fit under 4G.
-v2: add print out for second try, and print out files buf address.
-v3: can not snprintf
Reported-by: Mantas Mikulėnas
Tested-by: Anders Darander
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/eboot.c | 18 +++--
On Tue, Sep 2, 2014 at 12:09 PM, Yinghai Lu wrote:
> Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
> loaded above 4G"), the kernel freezes at the earliest possible moment
> when trying to boot via UEFI on Asus laptop.
>
> Revert to old way to load
trd is too big
and does not fit under 4G.
-v2: add print out for second try, and print out files buf address.
Reported-by: Mantas Mikulėnas
Tested-by: Anders Darander
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/eboot.c | 18 +++---
drivers/firmware/efi/l
On Wed, Aug 27, 2014 at 10:49 AM, H. Peter Anvin wrote:
> On 08/26/2014 03:05 PM, Yinghai Lu wrote:
> This does, however, suggest at least two possible solutions:
>
> 1. We can read the initramfs into a temporary buffer and memcpy() it to
> the target.
>
> 2. We might
On Wed, Aug 27, 2014 at 3:59 AM, Matt Fleming wrote:
> On Tue, 26 Aug, at 02:45:44PM, Yinghai Lu wrote:
> The reason I suggested introducing some kind of kernel parameter to
> allow loading above 4G is because if Mantas loads a 5GB initrd with your
> patch, his machine is still g
On Tue, Aug 26, 2014 at 3:16 PM, Mantas Mikulėnas wrote:
>
> In particular, I just realized yesterday that I don't know whether
> it's referring to physical or virtual addresses in the initrd load
> code -- and the laptop only has 4 GB of memory, so the kernel
> shouldn't be using larger physical
On Tue, Aug 26, 2014 at 2:53 PM, H. Peter Anvin wrote:
> On 08/26/2014 02:45 PM, Yinghai Lu wrote:
>> Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
>> loaded above 4G"), the kernel freezes at the earliest possible moment
>> when trying
nment when buffer is above 4G.
So revert to old way to load initrd on first try,
second try will use above 4G buffer when initrd is more than
2G and does not fit under 4G.
Reported-by: Mantas Mikulėnas
Tested-by: Anders Darander
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/eboo
On Mon, Aug 25, 2014 at 5:53 AM, Matt Fleming wrote:
> On Mon, 25 Aug, at 02:08:59PM, Mantas Mikulėnas wrote:
>> [0.00] RAMDISK: [mem 0xbe22e000-0xbe799fff]
that is pushed down under 4G.
>
> OK, we're out of options here. Yinghai, we're going to have to revert
> your patch, 4bf7111f5016
On Fri, Aug 22, 2014 at 6:59 AM, wrote:
> From: Harald Hoyer
>
> commit 4bf7111f50167133a71c23530ca852a41355e739 enabled loading of the
> initramfs above 4G addresses. So I was wondering, if the early microcode
> code might want to honor the upper 32bit of the 64bit address.
>
https://lkml.org/
quot;acpi, apei, ghes: Make NMI error notification to be GHES
> architecture extension")
>
> Please match or exceed the changelog quality of these commits.
How about this version ?
Subject: [PATCH -v3] x86, acpi: Make cpu sequence to be consistent with MADT
From: Yinghai Lu
On 8 socket
On Sat, Aug 9, 2014 at 3:45 PM, Mantas Mikulėnas wrote:
> On Sat, Aug 9, 2014 at 10:23 PM, Matt Fleming wrote:
> [However... Whether it's five chunks, four (after making the initrd
> smaller), or just one (with your efi=nochunk), I noticed that it
> *always* hangs during the *last* read, and the
On Sat, Aug 9, 2014 at 7:23 AM, Mantas Mikulėnas wrote:
> As of commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"),
> the kernel freezes at the earliest possible moment when trying to boot
> via UEFI on my Asus laptop. (It still boots via BIOS.)
>
> If I revert that commit on current
bios when we don't have idea about hw irq
routing.
Assume new systems will only work with acpi enabled kernel and well tested
on linux, and even system with coreboot and linuxbios support acpi properly
so remove this workaround from the kernel.
Signed-off-by: Yinghai Lu
---
arch/x86/includ
1201 - 1300 of 4418 matches
Mail list logo
