Re: regression in 4.0.0-rc1 with r8169 ethernet
On Sat, 28 Feb 2015, Jiang Liu wrote: On 2015/2/28 6:24, Rafael J. Wysocki wrote: On Friday, February 27, 2015 03:50:32 PM Thomas Voegtle wrote: Hi, I have the same problem with a Asrock Q1900B-ITX mainboard with a Intel Celeron J1900 onboard. I did a bisect and ended up with: 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit commit 593669c2ac0fe18baee04a3cd5539a148aa48574 Author: Jiang Liu Date: Thu Feb 5 13:44:46 2015 +0800 x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation I can revert this quite big commit on current git head (4f671fe) with no problems and then everything is fine again. Thanks for nailing this one! It really wasn't supposed to make any functional difference, though, so there must be some subtle mistake that escaped everyone in it. I'll have a look at that and hopefully Jiang Liu will be able to help in the meantime too. Hi all, Sorry for slow response, just return from Chinese New Holidays:) Hi Thomas, Could you please help to provide the dmesgs before and after the revert? Attached. Thanks, Thomas[0.00] Linux version 4.0.0-rc1-celeron-00037-gec3360c (thomas@maggie) (gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) ) #218 SMP Sat Feb 28 10:54:22 CET 2015 [0.00] Command line: root=/dev/sda3 console=ttyS0,115200N8 panic=30 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009c7ff] usable [0.00] BIOS-e820: [mem 0x0009c800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x200f] reserved [0.00] BIOS-e820: [mem 0x2010-0x79578fff] usable [0.00] BIOS-e820: [mem 0x79579000-0x795a8fff] reserved [0.00] BIOS-e820: [mem 0x795a9000-0x795fcfff] usable [0.00] BIOS-e820: [mem 0x795fd000-0x7970dfff] ACPI NVS [0.00] BIOS-e820: [mem 0x7970e000-0x79a7afff] reserved [0.00] BIOS-e820: [mem 0x79a7b000-0x79a7bfff] usable [0.00] BIOS-e820: [mem 0x79a7c000-0x79abdfff] reserved [0.00] BIOS-e820: [mem 0x79abe000-0x79c2bfff] usable [0.00] BIOS-e820: [mem 0x79c2c000-0x79ff9fff] reserved [0.00] BIOS-e820: [mem 0x79ffa000-0x79ff] usable [0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved [0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved [0.00] BIOS-e820: [mem 0xffb0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.8 present. [0.00] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./Q1900B-ITX, BIOS P1.70 11/04/2014 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x7a000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-E7FFF write-through [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 07A80 mask FFF80 uncachable [0.00] 2 base 07B00 mask FFF00 uncachable [0.00] 3 base 07C00 mask FFC00 uncachable [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88096000] 96000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x01a0f000, 0x01a0] PGTABLE [0.00] BRK [0x01a1, 0x01a10fff] PGTABLE [0.00] BRK [0x01a11000, 0x01a11fff] PGTABLE [0.00] init_memory_mapping: [mem 0x7920-0x793f] [0.00] [mem 0x7920-0x793f] page 2M [0.00] BRK [0x01a12000, 0x01a12fff] PGTABLE [0.00] init_memory_mapping: [mem 0x6000-0x791f] [0.00] [mem 0x6000-0x791f] page 2M [0.00] init_memory_mapping: [mem 0x4000-0x5fff] [0.00] [mem 0x4000-0x5fff] page 2M [0.00] init_memory_mapping: [mem 0x0010-0x1fff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x1fff] page 2M [0.00] init_memory_mapping: [mem 0x2010
Re: regression in 4.0.0-rc1 with r8169 ethernet
On 2015/2/28 16:36, Marcel Holtmann wrote: > Hi Jiang, > I have the same problem with a Asrock Q1900B-ITX mainboard with a Intel Celeron J1900 onboard. I did a bisect and ended up with: 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit commit 593669c2ac0fe18baee04a3cd5539a148aa48574 Author: Jiang Liu Date: Thu Feb 5 13:44:46 2015 +0800 x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation I can revert this quite big commit on current git head (4f671fe) with no problems and then everything is fine again. >>> >>> Thanks for nailing this one! >>> >>> It really wasn't supposed to make any functional difference, though, so >>> there >>> must be some subtle mistake that escaped everyone in it. >>> >>> I'll have a look at that and hopefully Jiang Liu will be able to help in the >>> meantime too. >> Hi all, >> Sorry for slow response, just return from Chinese New Holidays:) >> Hi Thomas, >> Could you please help to provide the dmesgs before and after the >> revert? > > just grab a Minnowboard Max and test this by yourself. It has the same > problem. The MAC address is ff:ff:ff:ff:ff:ff with this patch. Once I > reverted it, the MAC address is correctly read again. Hi Marcel, I have no access to any Minnowboard Max board, so couldn't test it by myself. Could you please help to forward the two dmesg files you have sent to Bjorn in the original email? Thanks! Gerry > > Regards > > Marcel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
On 2015/2/25 15:10, Bjorn Helgaas wrote: > [+cc Jiang, Thomas, Lv, Rafael, linux-pci, linux-acpi] > > On Tue, Feb 24, 2015 at 9:47 PM, Dave Airlie wrote: >> Hey, >> >> just booted an old AMD rs780 box with new kernel and my ethernet >> failed to come up! >> >> Looks like the MAC addr is all ff's because the PCI bridge windows are >> messed up. >> >> I've attached two dmesg one from a 3.19.0-rc6 I had on it, and one >> failing from the 4.0.0-rc1 time. >> >> b24e2bdde4af656bb0679a101265ebb8f8735d3c is latest Linus commit in >> that tree (I have some radeon patches on top). >> >> motherboard is a Gigabyte GA-MA78GM-S2H, lspci also attached. > > Here's the dmesg diff that looks relevant to me: > > -pci_bus :00: root bus resource [io 0x-0x0cf7] > -pci_bus :00: root bus resource [io 0x0d00-0x] > -pci_bus :00: root bus resource [mem 0x000a-0x000b] > -pci_bus :00: root bus resource [mem 0x000c-0x000d] > -pci_bus :00: root bus resource [mem 0xfed4-0xfed44fff] > -pci_bus :00: root bus resource [mem 0x7ff0-0xfebf] > +pci_bus :00: root bus resource [io 0x0cf8-0x0cff] > +pci_bus :00: root bus resource [io 0x-0x0cf7 window] > +pci_bus :00: root bus resource [io 0x0d00-0x window] > +pci_bus :00: root bus resource [mem 0x000a-0x000b window] > +pci_bus :00: root bus resource [mem 0x000c-0x000d window] > +pci_bus :00: root bus resource [mem 0xfed4-0xfed44fff window] > > What's interesting is: > > * v3.19 ignored [io 0x0cf8-0x0cff], but v4.0 includes it. I think > it's wrong to include it because that's the configuration space > address/data registers, so it's consumed by the host bridge and not > produced on the downstream side. Hi Bjorn, We should ignore resources occupied by host bridge itself. Will work out a patch to fix this issue. > > * v3.19 includes [mem 0x7ff0-0xfebf], but v4.0 does not. This > is what's screwing up the devices. I need more information to figure out why resource [mem 0x7ff0-0xfebf] is ignored by new ACPI parser. Could you please help to forward the original dmesg attachments? Regards! Gerry > > I think all the windows should be marked as ACPI_PRODUCER in _CRS > since the space is "produced" on the downstream side of the bridge. > The [io 0x0cf8-0x0cff] region should probably be marked > ACPI_CONSUMER, and maybe that accounts for why v3.19 ignores it. But > I haven't found the code that does that yet. > > I suspect this is all related to the ACPI resource parsing rework. I > looked through that briefly, but no issues jumped out at me, so this > is just a heads-up in case it is obvious to you guys. > > Dave, it'd be useful if you could collect an acpidump so we can look > at the _CRS data in more detail. > > Bjorn > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
Hi Jiang, >>> I have the same problem with a Asrock Q1900B-ITX mainboard with >>> a Intel Celeron J1900 onboard. >>> >>> I did a bisect and ended up with: >>> >>> 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit >>> >>> commit 593669c2ac0fe18baee04a3cd5539a148aa48574 >>> Author: Jiang Liu >>> Date: Thu Feb 5 13:44:46 2015 +0800 >>> >>> x86/PCI/ACPI: Use common ACPI resource interfaces to simplify >>> implementation >>> >>> >>> I can revert this quite big commit on current git head (4f671fe) with no >>> problems and then everything is fine again. >> >> Thanks for nailing this one! >> >> It really wasn't supposed to make any functional difference, though, so there >> must be some subtle mistake that escaped everyone in it. >> >> I'll have a look at that and hopefully Jiang Liu will be able to help in the >> meantime too. > Hi all, > Sorry for slow response, just return from Chinese New Holidays:) > Hi Thomas, > Could you please help to provide the dmesgs before and after the > revert? just grab a Minnowboard Max and test this by yourself. It has the same problem. The MAC address is ff:ff:ff:ff:ff:ff with this patch. Once I reverted it, the MAC address is correctly read again. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
On 2015/2/28 6:24, Rafael J. Wysocki wrote: > On Friday, February 27, 2015 03:50:32 PM Thomas Voegtle wrote: >> >> Hi, >> >> I have the same problem with a Asrock Q1900B-ITX mainboard with >> a Intel Celeron J1900 onboard. >> >> I did a bisect and ended up with: >> >> 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit >> >> commit 593669c2ac0fe18baee04a3cd5539a148aa48574 >> Author: Jiang Liu >> Date: Thu Feb 5 13:44:46 2015 +0800 >> >> x86/PCI/ACPI: Use common ACPI resource interfaces to simplify >> implementation >> >> >> I can revert this quite big commit on current git head (4f671fe) with no >> problems and then everything is fine again. > > Thanks for nailing this one! > > It really wasn't supposed to make any functional difference, though, so there > must be some subtle mistake that escaped everyone in it. > > I'll have a look at that and hopefully Jiang Liu will be able to help in the > meantime too. Hi all, Sorry for slow response, just return from Chinese New Holidays:) Hi Thomas, Could you please help to provide the dmesgs before and after the revert? Thanks! Gerry > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
On Friday, February 27, 2015 03:50:32 PM Thomas Voegtle wrote: > > Hi, > > I have the same problem with a Asrock Q1900B-ITX mainboard with > a Intel Celeron J1900 onboard. > > I did a bisect and ended up with: > > 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit > > commit 593669c2ac0fe18baee04a3cd5539a148aa48574 > Author: Jiang Liu > Date: Thu Feb 5 13:44:46 2015 +0800 > > x86/PCI/ACPI: Use common ACPI resource interfaces to simplify > implementation > > > I can revert this quite big commit on current git head (4f671fe) with no > problems and then everything is fine again. Thanks for nailing this one! It really wasn't supposed to make any functional difference, though, so there must be some subtle mistake that escaped everyone in it. I'll have a look at that and hopefully Jiang Liu will be able to help in the meantime too. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
Hi, I have the same problem with a Asrock Q1900B-ITX mainboard with a Intel Celeron J1900 onboard. I did a bisect and ended up with: 593669c2ac0fe18baee04a3cd5539a148aa48574 is the first bad commit commit 593669c2ac0fe18baee04a3cd5539a148aa48574 Author: Jiang Liu Date: Thu Feb 5 13:44:46 2015 +0800 x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation I can revert this quite big commit on current git head (4f671fe) with no problems and then everything is fine again. Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
On Wednesday, February 25, 2015 06:03:56 PM Dave Airlie wrote: > > * v3.19 ignored [io 0x0cf8-0x0cff], but v4.0 includes it. I think > > it's wrong to include it because that's the configuration space > > address/data registers, so it's consumed by the host bridge and not > > produced on the downstream side. > > > > * v3.19 includes [mem 0x7ff0-0xfebf], but v4.0 does not. This > > is what's screwing up the devices. > > > > I think all the windows should be marked as ACPI_PRODUCER in _CRS > > since the space is "produced" on the downstream side of the bridge. > > The [io 0x0cf8-0x0cff] region should probably be marked > > ACPI_CONSUMER, and maybe that accounts for why v3.19 ignores it. But > > I haven't found the code that does that yet. > > > > I suspect this is all related to the ACPI resource parsing rework. I > > looked through that briefly, but no issues jumped out at me, so this > > is just a heads-up in case it is obvious to you guys. > > > > Dave, it'd be useful if you could collect an acpidump so we can look > > at the _CRS data in more detail. > > acpidump fails here with a /dev/mem warning in the kernel, > > now I'm not near the machine again until next week most likely, so I > only have ssh for now, > and the kernel it is running for which I don't have the source anymore! > > is there any of tables from /sys I can grab instead? /sys/firmware/acpi/tables/DSDT /sys/firmware/acpi/tables/SSDT* Also I'm wondering if reverting commit 2ea3d266bab3 (ACPI: Translate resource into master side address for bridge window resources) makes any difference? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
> * v3.19 ignored [io 0x0cf8-0x0cff], but v4.0 includes it. I think > it's wrong to include it because that's the configuration space > address/data registers, so it's consumed by the host bridge and not > produced on the downstream side. > > * v3.19 includes [mem 0x7ff0-0xfebf], but v4.0 does not. This > is what's screwing up the devices. > > I think all the windows should be marked as ACPI_PRODUCER in _CRS > since the space is "produced" on the downstream side of the bridge. > The [io 0x0cf8-0x0cff] region should probably be marked > ACPI_CONSUMER, and maybe that accounts for why v3.19 ignores it. But > I haven't found the code that does that yet. > > I suspect this is all related to the ACPI resource parsing rework. I > looked through that briefly, but no issues jumped out at me, so this > is just a heads-up in case it is obvious to you guys. > > Dave, it'd be useful if you could collect an acpidump so we can look > at the _CRS data in more detail. acpidump fails here with a /dev/mem warning in the kernel, now I'm not near the machine again until next week most likely, so I only have ssh for now, and the kernel it is running for which I don't have the source anymore! is there any of tables from /sys I can grab instead? Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
[+cc Jiang, Thomas, Lv, Rafael, linux-pci, linux-acpi] On Tue, Feb 24, 2015 at 9:47 PM, Dave Airlie wrote: > Hey, > > just booted an old AMD rs780 box with new kernel and my ethernet > failed to come up! > > Looks like the MAC addr is all ff's because the PCI bridge windows are > messed up. > > I've attached two dmesg one from a 3.19.0-rc6 I had on it, and one > failing from the 4.0.0-rc1 time. > > b24e2bdde4af656bb0679a101265ebb8f8735d3c is latest Linus commit in > that tree (I have some radeon patches on top). > > motherboard is a Gigabyte GA-MA78GM-S2H, lspci also attached. Here's the dmesg diff that looks relevant to me: -pci_bus :00: root bus resource [io 0x-0x0cf7] -pci_bus :00: root bus resource [io 0x0d00-0x] -pci_bus :00: root bus resource [mem 0x000a-0x000b] -pci_bus :00: root bus resource [mem 0x000c-0x000d] -pci_bus :00: root bus resource [mem 0xfed4-0xfed44fff] -pci_bus :00: root bus resource [mem 0x7ff0-0xfebf] +pci_bus :00: root bus resource [io 0x0cf8-0x0cff] +pci_bus :00: root bus resource [io 0x-0x0cf7 window] +pci_bus :00: root bus resource [io 0x0d00-0x window] +pci_bus :00: root bus resource [mem 0x000a-0x000b window] +pci_bus :00: root bus resource [mem 0x000c-0x000d window] +pci_bus :00: root bus resource [mem 0xfed4-0xfed44fff window] What's interesting is: * v3.19 ignored [io 0x0cf8-0x0cff], but v4.0 includes it. I think it's wrong to include it because that's the configuration space address/data registers, so it's consumed by the host bridge and not produced on the downstream side. * v3.19 includes [mem 0x7ff0-0xfebf], but v4.0 does not. This is what's screwing up the devices. I think all the windows should be marked as ACPI_PRODUCER in _CRS since the space is "produced" on the downstream side of the bridge. The [io 0x0cf8-0x0cff] region should probably be marked ACPI_CONSUMER, and maybe that accounts for why v3.19 ignores it. But I haven't found the code that does that yet. I suspect this is all related to the ACPI resource parsing rework. I looked through that briefly, but no issues jumped out at me, so this is just a heads-up in case it is obvious to you guys. Dave, it'd be useful if you could collect an acpidump so we can look at the _CRS data in more detail. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression in 4.0.0-rc1 with r8169 ethernet
[+cc linux-pci] On Tue, Feb 24, 2015 at 9:47 PM, Dave Airlie wrote: > Hey, > > just booted an old AMD rs780 box with new kernel and my ethernet > failed to come up! > > Looks like the MAC addr is all ff's because the PCI bridge windows are > messed up. > > I've attached two dmesg one from a 3.19.0-rc6 I had on it, and one > failing from the 4.0.0-rc1 time. > > b24e2bdde4af656bb0679a101265ebb8f8735d3c is latest Linus commit in > that tree (I have some radeon patches on top). > > motherboard is a Gigabyte GA-MA78GM-S2H, lspci also attached. Hi Dave, Looking, thanks for the report and sorry for the inconvenience. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
