Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On 12/12/14 at 10:25am, Li, ZhenHua wrote: > Sorry I have no plan yet. > Could you send me your logs on your AMD system? Sure, please check the attachment. AMD iommu seems a little different on action. On the machine I reserved for testing, it always hang the system bootup. As Joerg said, we can just know this issue, vt-d is still the first thing. [root@hp-sl4545g7-01 ~]# echo c >/proc/sysrq-trigger [ 4178.349174] SysRq : Trigger a crash [ 4178.367887] BUG: unable to handle kernel NULL pointer dereference at (null) [ 4178.413933] IP: [] sysrq_handle_crash+0x16/0x20 [ 4178.449637] PGD 8219eb067 PUD 824b4f067 PMD 0 [ 4178.475360] Oops: 0002 [#1] SMP [ 4178.494112] Modules linked in: cfg80211 sg rfkill kvm_amd kvm nfsd igb crct10dif_pclmul crc32_pclmul ptp crc32c_intel ghash_clmulni_intel auth_rpcgss aesni_intel pps_core dca ipmi_si hpwdt sp5100_tco lrw nfs_acl gf128mul hpilo pcspkr ipmi_msghandler serio_raw fam15h_power amd64_edac_mod glue_helper i2c_piix4 edac_mce_amd k10temp lockd edac_core ablk_helper cryptd shpchp sunrpc xfs libcrc32c radeon i2c_algo_bit drm_kms_helper ttm sd_mod ata_generic crc_t10dif pata_acpi ahci drm crct10dif_common libahci pata_atiixp libata hpsa i2c_core dm_mirror dm_region_hash dm_log dm_mod [ 4178.785689] CPU: 1 PID: 1872 Comm: bash Not tainted 3.14.0+ #44 [ 4178.819575] Hardware name: HP ProLiant SL4545 G7/, BIOS A31 12/08/2012 [ 4178.856427] task: 88081ab9b680 ti: 88082036 task.ti: 88082036 [ 4178.899369] RIP: 0010:[] [] sysrq_handle_crash+0x16/0x20 [ 4178.947941] RSP: 0018:880820361e80 EFLAGS: 00010046 [ 4178.977106] RAX: 000f RBX: 81a0b6c0 RCX: [ 4179.018848] RDX: RSI: 88083ea0e708 RDI: 0063 [ 4179.059550] RBP: 880820361e80 R08: 0092 R09: 051b [ 4179.099603] R10: 051a R11: 0003 R12: 0063 [ 4179.140142] R13: 0246 R14: 0007 R15: [ 4179.179475] FS: 7f4edd746740() GS:88083ea0() knlGS: [ 4179.225437] CS: 0010 DS: ES: CR0: 80050033 [ 4179.256725] CR2: CR3: 000821b75000 CR4: 000406e0 [ 4179.297414] Stack: [ 4179.308744] 880820361eb8 813a8882 0002 7f4edd744000 [ 4179.349142] 880820361f48 0002 880820361ed0 [ 4179.390914] 813a8d8f 88082405fa40 880820361ef0 81236d5d [ 4179.440766] Call Trace: [ 4179.453918] [] __handle_sysrq+0xa2/0x170 [ 4179.485923] [] write_sysrq_trigger+0x2f/0x40 [ 4179.518602] [] proc_reg_write+0x3d/0x80 [ 4179.548870] [] vfs_write+0xba/0x1e0 [ 4179.578130] [] SyS_write+0x55/0xd0 [ 4179.606615] [] system_call_fastpath+0x16/0x1b [ 4179.640318] Code: 65 34 75 e5 4c 89 ef e8 d9 f7 ff ff eb db 0f 1f 80 00 00 00 00 66 66 66 66 90 55 c7 05 a0 d5 5b 00 01 00 00 00 48 89 e5 0f ae f8 04 25 00 00 00 00 01 5d c3 66 66 66 66 90 55 31 c0 c7 05 1e [ 4179.748149] RIP [] sysrq_handle_crash+0x16/0x20 [ 4179.783683] RSP [ 4179.802762] CR2: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.14.0+ (b...@ibm-x3755m3-02.lab.bos.redhat.com) (gcc version 4.8.2 20140120 (Red Hat 4.8.2-13) (GCC) ) #44 SMP Thu Apr 10 22:28:02 EDT 2014 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.14.0+ root=/dev/mapper/rhel_hp--sl4545g7--01-root ro console=ttyS1,115200n81 rd.lvm.lv=rhel_hp-sl4545g7-01/root rd.lvm.lv=rhel_hp-sl4545g7-01/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=us LANG=en_US.UTF-8 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 memmap=exactmap memmap=592K@4K memmap=523672K@311296K elfcorehdr=834968K memmap=192K#3141752K [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x0100-0x00094fff] usable [0.00] BIOS-e820: [mem 0x00095000-0x00095bff] reserved [0.00] BIOS-e820: [mem 0x00098000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbfc1dfff] usable [ [mem 0xbfc1e000-0xbfc4dfff] ACPI data [0.00] BIOS-e820: [mem 0xbfc4e000-0xbfc4efff] usable [0.00] BIOS-e820: [mem 0xbfc4f000-0xcfff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfee0] reserved [0.00] BIOS-e820: [mem 0xff80-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00083effefff] usable [0.00] e820: last_pfn = 0x83efff max_arch_pfn = 0x4 [0.00] NX
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On 12/12/14 at 05:11pm, Joerg Roedel wrote: > On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote: > > Sorry I have no plan yet. > > Could you send me your logs on your AMD system? > > > On 12/10/2014 04:46 PM, Baoquan He wrote: > > >This issue happens on AMD iommu too, do you have any plans or > > >thoughts on that? > > I think the best approach for now is to get a prove-of-concept on the > VT-d driver. If it works there the way we expect, we can implement the > same handling in the AMD driver. But I see no reason to hold back the > VT-d patches until it is also fixed for AMD systems. Yes, I agree with you. Just raise this issue to upstream. Thanks, Joerg. -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On 12/12/14 at 05:11pm, Joerg Roedel wrote: On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote: Sorry I have no plan yet. Could you send me your logs on your AMD system? On 12/10/2014 04:46 PM, Baoquan He wrote: This issue happens on AMD iommu too, do you have any plans or thoughts on that? I think the best approach for now is to get a prove-of-concept on the VT-d driver. If it works there the way we expect, we can implement the same handling in the AMD driver. But I see no reason to hold back the VT-d patches until it is also fixed for AMD systems. Yes, I agree with you. Just raise this issue to upstream. Thanks, Joerg. -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On 12/12/14 at 10:25am, Li, ZhenHua wrote: Sorry I have no plan yet. Could you send me your logs on your AMD system? Sure, please check the attachment. AMD iommu seems a little different on action. On the machine I reserved for testing, it always hang the system bootup. As Joerg said, we can just know this issue, vt-d is still the first thing. [root@hp-sl4545g7-01 ~]# echo c /proc/sysrq-trigger [ 4178.349174] SysRq : Trigger a crash [ 4178.367887] BUG: unable to handle kernel NULL pointer dereference at (null) [ 4178.413933] IP: [813a80b6] sysrq_handle_crash+0x16/0x20 [ 4178.449637] PGD 8219eb067 PUD 824b4f067 PMD 0 [ 4178.475360] Oops: 0002 [#1] SMP [ 4178.494112] Modules linked in: cfg80211 sg rfkill kvm_amd kvm nfsd igb crct10dif_pclmul crc32_pclmul ptp crc32c_intel ghash_clmulni_intel auth_rpcgss aesni_intel pps_core dca ipmi_si hpwdt sp5100_tco lrw nfs_acl gf128mul hpilo pcspkr ipmi_msghandler serio_raw fam15h_power amd64_edac_mod glue_helper i2c_piix4 edac_mce_amd k10temp lockd edac_core ablk_helper cryptd shpchp sunrpc xfs libcrc32c radeon i2c_algo_bit drm_kms_helper ttm sd_mod ata_generic crc_t10dif pata_acpi ahci drm crct10dif_common libahci pata_atiixp libata hpsa i2c_core dm_mirror dm_region_hash dm_log dm_mod [ 4178.785689] CPU: 1 PID: 1872 Comm: bash Not tainted 3.14.0+ #44 [ 4178.819575] Hardware name: HP ProLiant SL4545 G7/, BIOS A31 12/08/2012 [ 4178.856427] task: 88081ab9b680 ti: 88082036 task.ti: 88082036 [ 4178.899369] RIP: 0010:[813a80b6] [813a80b6] sysrq_handle_crash+0x16/0x20 [ 4178.947941] RSP: 0018:880820361e80 EFLAGS: 00010046 [ 4178.977106] RAX: 000f RBX: 81a0b6c0 RCX: [ 4179.018848] RDX: RSI: 88083ea0e708 RDI: 0063 [ 4179.059550] RBP: 880820361e80 R08: 0092 R09: 051b [ 4179.099603] R10: 051a R11: 0003 R12: 0063 [ 4179.140142] R13: 0246 R14: 0007 R15: [ 4179.179475] FS: 7f4edd746740() GS:88083ea0() knlGS: [ 4179.225437] CS: 0010 DS: ES: CR0: 80050033 [ 4179.256725] CR2: CR3: 000821b75000 CR4: 000406e0 [ 4179.297414] Stack: [ 4179.308744] 880820361eb8 813a8882 0002 7f4edd744000 [ 4179.349142] 880820361f48 0002 880820361ed0 [ 4179.390914] 813a8d8f 88082405fa40 880820361ef0 81236d5d [ 4179.440766] Call Trace: [ 4179.453918] [813a8882] __handle_sysrq+0xa2/0x170 [ 4179.485923] [813a8d8f] write_sysrq_trigger+0x2f/0x40 [ 4179.518602] [81236d5d] proc_reg_write+0x3d/0x80 [ 4179.548870] [811ce0ea] vfs_write+0xba/0x1e0 [ 4179.578130] [811ceca5] SyS_write+0x55/0xd0 [ 4179.606615] [81636829] system_call_fastpath+0x16/0x1b [ 4179.640318] Code: 65 34 75 e5 4c 89 ef e8 d9 f7 ff ff eb db 0f 1f 80 00 00 00 00 66 66 66 66 90 55 c7 05 a0 d5 5b 00 01 00 00 00 48 89 e5 0f ae f8 c6 04 25 00 00 00 00 01 5d c3 66 66 66 66 90 55 31 c0 c7 05 1e [ 4179.748149] RIP [813a80b6] sysrq_handle_crash+0x16/0x20 [ 4179.783683] RSP 880820361e80 [ 4179.802762] CR2: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.14.0+ (b...@ibm-x3755m3-02.lab.bos.redhat.com) (gcc version 4.8.2 20140120 (Red Hat 4.8.2-13) (GCC) ) #44 SMP Thu Apr 10 22:28:02 EDT 2014 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.14.0+ root=/dev/mapper/rhel_hp--sl4545g7--01-root ro console=ttyS1,115200n81 rd.lvm.lv=rhel_hp-sl4545g7-01/root rd.lvm.lv=rhel_hp-sl4545g7-01/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=us LANG=en_US.UTF-8 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 memmap=exactmap memmap=592K@4K memmap=523672K@311296K elfcorehdr=834968K memmap=192K#3141752K [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x0100-0x00094fff] usable [0.00] BIOS-e820: [mem 0x00095000-0x00095bff] reserved [0.00] BIOS-e820: [mem 0x00098000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbfc1dfff] usable [ [mem 0xbfc1e000-0xbfc4dfff] ACPI data [0.00] BIOS-e820: [mem 0xbfc4e000-0xbfc4efff] usable [0.00] BIOS-e820: [mem 0xbfc4f000-0xcfff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfee0] reserved [0.00] BIOS-e820: [mem 0xff80-0x]
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote: > Sorry I have no plan yet. > Could you send me your logs on your AMD system? > On 12/10/2014 04:46 PM, Baoquan He wrote: > >This issue happens on AMD iommu too, do you have any plans or > >thoughts on that? I think the best approach for now is to get a prove-of-concept on the VT-d driver. If it works there the way we expect, we can implement the same handling in the AMD driver. But I see no reason to hold back the VT-d patches until it is also fixed for AMD systems. Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote: Sorry I have no plan yet. Could you send me your logs on your AMD system? On 12/10/2014 04:46 PM, Baoquan He wrote: This issue happens on AMD iommu too, do you have any plans or thoughts on that? I think the best approach for now is to get a prove-of-concept on the VT-d driver. If it works there the way we expect, we can implement the same handling in the AMD driver. But I see no reason to hold back the VT-d patches until it is also fixed for AMD systems. Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Sorry I have no plan yet. Could you send me your logs on your AMD system? Thanks Zhenhua On 12/10/2014 04:46 PM, Baoquan He wrote: Hi Joerg, ZhenHua, This issue happens on AMD iommu too, do you have any plans or thoughts on that? Thanks Baoquan On 11/17/14 at 02:38pm, Joerg Roedel wrote: On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: I am working following your directions: 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry table, and do NOT disable-enable iommu. Other data will be copied. 2. When a device driver issues the first dma_map command for a device, we assign a new and empty page-table, thus removing all mappings from the old kernel for the device. Please let me know if I get something wrong. Yes, this sounds right. Happily waiting for patches :) Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Sorry I have no plan yet. Could you send me your logs on your AMD system? Thanks Zhenhua On 12/10/2014 04:46 PM, Baoquan He wrote: Hi Joerg, ZhenHua, This issue happens on AMD iommu too, do you have any plans or thoughts on that? Thanks Baoquan On 11/17/14 at 02:38pm, Joerg Roedel wrote: On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: I am working following your directions: 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry table, and do NOT disable-enable iommu. Other data will be copied. 2. When a device driver issues the first dma_map command for a device, we assign a new and empty page-table, thus removing all mappings from the old kernel for the device. Please let me know if I get something wrong. Yes, this sounds right. Happily waiting for patches :) Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Joerg, ZhenHua, This issue happens on AMD iommu too, do you have any plans or thoughts on that? Thanks Baoquan On 11/17/14 at 02:38pm, Joerg Roedel wrote: > On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: > > I am working following your directions: > > > > 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry > > table, and do NOT disable-enable iommu. Other data will be copied. > > > > 2. When a device driver issues the first dma_map command for a > > device, we assign a new and empty page-table, thus removing all > > mappings from the old kernel for the device. > > > > Please let me know if I get something wrong. > > Yes, this sounds right. Happily waiting for patches :) > > > Joerg > -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Joerg, ZhenHua, This issue happens on AMD iommu too, do you have any plans or thoughts on that? Thanks Baoquan On 11/17/14 at 02:38pm, Joerg Roedel wrote: On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: I am working following your directions: 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry table, and do NOT disable-enable iommu. Other data will be copied. 2. When a device driver issues the first dma_map command for a device, we assign a new and empty page-table, thus removing all mappings from the old kernel for the device. Please let me know if I get something wrong. Yes, this sounds right. Happily waiting for patches :) Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On Mon, Dec 01, 2014 at 02:31:38PM +0800, Li, ZhenHua wrote: > After I implement these two steps, there comes a new fault: > > [1.594890] dmar: DRHD: handling fault status reg 2 > [1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d > [1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry > is clear > > It is caused by similar reason, so I will fix it like fixing the DMAR > faults: Do NOT disable and re-enable the interrupt remapping, try to > use data from old kernel. Yes, that sounds right, thanks. Looking forward to your patches. Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On Mon, Dec 01, 2014 at 02:31:38PM +0800, Li, ZhenHua wrote: After I implement these two steps, there comes a new fault: [1.594890] dmar: DRHD: handling fault status reg 2 [1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d [1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear It is caused by similar reason, so I will fix it like fixing the DMAR faults: Do NOT disable and re-enable the interrupt remapping, try to use data from old kernel. Yes, that sounds right, thanks. Looking forward to your patches. Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Joerg, After I implement these two steps, there comes a new fault: [1.594890] dmar: DRHD: handling fault status reg 2 [1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d [1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear It is caused by similar reason, so I will fix it like fixing the DMAR faults: Do NOT disable and re-enable the interrupt remapping, try to use data from old kernel. Thanks Zhenhua On 11/17/2014 09:38 PM, Joerg Roedel wrote: On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: I am working following your directions: 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry table, and do NOT disable-enable iommu. Other data will be copied. 2. When a device driver issues the first dma_map command for a device, we assign a new and empty page-table, thus removing all mappings from the old kernel for the device. Please let me know if I get something wrong. Yes, this sounds right. Happily waiting for patches :) Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Joerg, After I implement these two steps, there comes a new fault: [1.594890] dmar: DRHD: handling fault status reg 2 [1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d [1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear It is caused by similar reason, so I will fix it like fixing the DMAR faults: Do NOT disable and re-enable the interrupt remapping, try to use data from old kernel. Thanks Zhenhua On 11/17/2014 09:38 PM, Joerg Roedel wrote: On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: I am working following your directions: 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry table, and do NOT disable-enable iommu. Other data will be copied. 2. When a device driver issues the first dma_map command for a device, we assign a new and empty page-table, thus removing all mappings from the old kernel for the device. Please let me know if I get something wrong. Yes, this sounds right. Happily waiting for patches :) Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: > I am working following your directions: > > 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry > table, and do NOT disable-enable iommu. Other data will be copied. > > 2. When a device driver issues the first dma_map command for a > device, we assign a new and empty page-table, thus removing all > mappings from the old kernel for the device. > > Please let me know if I get something wrong. Yes, this sounds right. Happily waiting for patches :) Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote: I am working following your directions: 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry table, and do NOT disable-enable iommu. Other data will be copied. 2. When a device driver issues the first dma_map command for a device, we assign a new and empty page-table, thus removing all mappings from the old kernel for the device. Please let me know if I get something wrong. Yes, this sounds right. Happily waiting for patches :) Joerg -- 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: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Takao Indoh,
Your update for the patchset works fine. Thanks.
Joerg,
I am working following your directions:
1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry
table, and do NOT disable-enable iommu. Other data will be copied.
2. When a device driver issues the first dma_map command for a
device, we assign a new and empty page-table, thus removing all
mappings from the old kernel for the device.
Please let me know if I get something wrong.
Thanks
Zhenhua
On 11/06/2014 04:06 PM, Li, ZhenHua wrote:
> Thank you very much for your testing and fix. I will also test it on my
> system.
> I will let you know when I get a result.
>
> Regards
> Zhenhua
>
> On 11/06/2014 03:51 PM, Takao Indoh wrote:
>> (2014/11/06 11:11), Li, ZhenHua wrote:
>>> This patch does the same thing as you said in your mail.
>>> It should work, I have tested on my HP huge system.
>>
>> Yep, I also confirmed it worked.
>>
>> BTW, I found another problem. When I tested your patches with 3.17
>> kernel, iommu initialization failed with the following message.
>>
>> IOMMU intel_iommu_in_crashdump = true
>> IOMMU Skip disabling iommu hardware translations
>> IOMMU Copying translate tables from panicked kernel
>> IOMMU: Copy translate tables failed
>> IOMMU: dmar init failed
>>
>>
>> I found that oldcopy() from physical address 0x15000 was failed.
>> oldcopy() copies data using ioremap, and ioremap for the memory region
>> around 0x15000 does not work because it is already mapped to virtual
>> space.
>>
>>
>> static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>> unsigned long size, unsigned long prot_val, void *caller)
>> {
>> (snip)
>> /*
>>* Don't allow anybody to remap normal RAM that we're using..
>>*/
>> pfn = phys_addr >> PAGE_SHIFT;
>> last_pfn = last_addr >> PAGE_SHIFT;
>> if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
>> __ioremap_check_ram) == 1)
>> return NULL;
>>
>>
>>
>> I'm not sure how we should handle this, but as far as I tested the
>> following fix works.
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 3a9e7b8..8d2bd23 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -4871,7 +4871,12 @@ static int oldcopy(void *to, void *from, int size)
>>
>> pfn = ((unsigned long) from) >> VTD_PAGE_SHIFT;
>> offset = ((unsigned long) from) & (~VTD_PAGE_MASK);
>> - ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
>> +
>> + if (page_is_ram(pfn)) {
>> + memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
>> + ret = size;
>> + } else
>> + ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
>>
>> return (int) ret;
>>}
>>
>>
>> Thanks,
>> Takao Indoh
>>
>>
>>>
>>> On 11/06/2014 09:48 AM, Takao Indoh wrote:
(2014/11/06 10:35), Li, ZhenHua wrote:
> Yes, that's it. The function context_set_address_root does not set the
> address root correctly.
>
> I have created another patch for it, see
> https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
>
> Thanks
> Zhenhua
>
> On 11/06/2014 09:31 AM, Takao Indoh wrote:
>> Hi Zhenhua, Baoquan,
>>
>> (2014/10/22 19:05), Baoquan He wrote:
>>> Hi Zhenhua,
>>>
>>> I tested your latest patch on 3.18.0-rc1+, there are still some dmar
>>> errors. I remember it worked well with Bill's original patchset.
>>
>> This should be a problem in copy_context_entry().
>>
>>> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
>>> devfn,
>>> + void *ppap, struct context_entry *ce)
>>> +{
>>> + int ret = 0;/* Integer Return Code */
>>> + u32 shift = 0; /* bits to shift page_addr */
>>> + u64 page_addr = 0; /* Address of translated page */
>>> + struct dma_pte *pgt_old_phys; /* Adr(page_table in the old
>>> kernel) */
>>> + struct dma_pte *pgt_new_phys; /* Adr(page_table in the new
>>> kernel) */
>>> + u8 t; /* Translation-type from
>>> context */
>>> + u8 aw; /* Address-width from context */
>>> + u32 aw_shift[8] = {
>>> + 12+9+9, /* [000b] 30-bit AGAW (2-level page
>>> table) */
>>> + 12+9+9+9, /* [001b] 39-bit AGAW (3-level page
>>> table) */
>>> + 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page
>>> table) */
>>> + 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page
>>> table) */
>>> +
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Takao Indoh,
Your update for the patchset works fine. Thanks.
Joerg,
I am working following your directions:
1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry
table, and do NOT disable-enable iommu. Other data will be copied.
2. When a device driver issues the first dma_map command for a
device, we assign a new and empty page-table, thus removing all
mappings from the old kernel for the device.
Please let me know if I get something wrong.
Thanks
Zhenhua
On 11/06/2014 04:06 PM, Li, ZhenHua wrote:
Thank you very much for your testing and fix. I will also test it on my
system.
I will let you know when I get a result.
Regards
Zhenhua
On 11/06/2014 03:51 PM, Takao Indoh wrote:
(2014/11/06 11:11), Li, ZhenHua wrote:
This patch does the same thing as you said in your mail.
It should work, I have tested on my HP huge system.
Yep, I also confirmed it worked.
BTW, I found another problem. When I tested your patches with 3.17
kernel, iommu initialization failed with the following message.
IOMMU intel_iommu_in_crashdump = true
IOMMU Skip disabling iommu hardware translations
IOMMU Copying translate tables from panicked kernel
IOMMU: Copy translate tables failed
IOMMU: dmar init failed
I found that oldcopy() from physical address 0x15000 was failed.
oldcopy() copies data using ioremap, and ioremap for the memory region
around 0x15000 does not work because it is already mapped to virtual
space.
arch/x86/mm/ioremap.c
static void __iomem *__ioremap_caller(resource_size_t phys_addr,
unsigned long size, unsigned long prot_val, void *caller)
{
(snip)
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
pfn = phys_addr PAGE_SHIFT;
last_pfn = last_addr PAGE_SHIFT;
if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
__ioremap_check_ram) == 1)
return NULL;
ioreamp failed HERE!
I'm not sure how we should handle this, but as far as I tested the
following fix works.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3a9e7b8..8d2bd23 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4871,7 +4871,12 @@ static int oldcopy(void *to, void *from, int size)
pfn = ((unsigned long) from) VTD_PAGE_SHIFT;
offset = ((unsigned long) from) (~VTD_PAGE_MASK);
- ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+
+ if (page_is_ram(pfn)) {
+ memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
+ ret = size;
+ } else
+ ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
return (int) ret;
}
Thanks,
Takao Indoh
On 11/06/2014 09:48 AM, Takao Indoh wrote:
(2014/11/06 10:35), Li, ZhenHua wrote:
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
+static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
devfn,
+ void *ppap, struct context_entry *ce)
+{
+ int ret = 0;/* Integer Return Code */
+ u32 shift = 0; /* bits to shift page_addr */
+ u64 page_addr = 0; /* Address of translated page */
+ struct dma_pte *pgt_old_phys; /* Adr(page_table in the old
kernel) */
+ struct dma_pte *pgt_new_phys; /* Adr(page_table in the new
kernel) */
+ u8 t; /* Translation-type from
context */
+ u8 aw; /* Address-width from context */
+ u32 aw_shift[8] = {
+ 12+9+9, /* [000b] 30-bit AGAW (2-level page
table) */
+ 12+9+9+9, /* [001b] 39-bit AGAW (3-level page
table) */
+ 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page
table) */
+ 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page
table) */
+ 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page
table) */
+ 0, /* [111b] Reserved */
+ 0, /* [110b] Reserved */
+ 0, /* [111b] Reserved */
+ };
+
+ struct domain_values_entry *dve = NULL;
+
+
+ if (!context_present(ce)) { /* If (context not present) */
+ ret = RET_CCE_NOT_PRESENT;
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Thank you very much for your testing and fix. I will also test it on my
system.
I will let you know when I get a result.
Regards
Zhenhua
On 11/06/2014 03:51 PM, Takao Indoh wrote:
> (2014/11/06 11:11), Li, ZhenHua wrote:
>> This patch does the same thing as you said in your mail.
>> It should work, I have tested on my HP huge system.
>
> Yep, I also confirmed it worked.
>
> BTW, I found another problem. When I tested your patches with 3.17
> kernel, iommu initialization failed with the following message.
>
> IOMMU intel_iommu_in_crashdump = true
> IOMMU Skip disabling iommu hardware translations
> IOMMU Copying translate tables from panicked kernel
> IOMMU: Copy translate tables failed
> IOMMU: dmar init failed
>
>
> I found that oldcopy() from physical address 0x15000 was failed.
> oldcopy() copies data using ioremap, and ioremap for the memory region
> around 0x15000 does not work because it is already mapped to virtual
> space.
>
>
> static void __iomem *__ioremap_caller(resource_size_t phys_addr,
> unsigned long size, unsigned long prot_val, void *caller)
> {
> (snip)
> /*
> * Don't allow anybody to remap normal RAM that we're using..
> */
> pfn = phys_addr >> PAGE_SHIFT;
> last_pfn = last_addr >> PAGE_SHIFT;
> if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
>__ioremap_check_ram) == 1)
> return NULL;
>
>
>
> I'm not sure how we should handle this, but as far as I tested the
> following fix works.
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 3a9e7b8..8d2bd23 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -4871,7 +4871,12 @@ static int oldcopy(void *to, void *from, int size)
>
> pfn = ((unsigned long) from) >> VTD_PAGE_SHIFT;
> offset = ((unsigned long) from) & (~VTD_PAGE_MASK);
> - ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
> +
> + if (page_is_ram(pfn)) {
> + memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
> + ret = size;
> + } else
> + ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
>
> return (int) ret;
> }
>
>
> Thanks,
> Takao Indoh
>
>
>>
>> On 11/06/2014 09:48 AM, Takao Indoh wrote:
>>> (2014/11/06 10:35), Li, ZhenHua wrote:
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
>>>
>>> Oh, ok. I'll try again with this patch, thank you.
>>>
>>> Thanks,
>>> Takao Indoh
>>>
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
> Hi Zhenhua, Baoquan,
>
> (2014/10/22 19:05), Baoquan He wrote:
>> Hi Zhenhua,
>>
>> I tested your latest patch on 3.18.0-rc1+, there are still some dmar
>> errors. I remember it worked well with Bill's original patchset.
>
> This should be a problem in copy_context_entry().
>
>> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
>> devfn,
>> + void *ppap, struct context_entry *ce)
>> +{
>> +int ret = 0;/* Integer Return Code */
>> +u32 shift = 0; /* bits to shift page_addr */
>> +u64 page_addr = 0; /* Address of translated page */
>> +struct dma_pte *pgt_old_phys; /* Adr(page_table in the old
>> kernel) */
>> +struct dma_pte *pgt_new_phys; /* Adr(page_table in the new
>> kernel) */
>> +u8 t; /* Translation-type from
>> context */
>> +u8 aw; /* Address-width from context */
>> +u32 aw_shift[8] = {
>> +12+9+9, /* [000b] 30-bit AGAW (2-level page
>> table) */
>> +12+9+9+9, /* [001b] 39-bit AGAW (3-level page
>> table) */
>> +12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page
>> table) */
>> +12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page
>> table) */
>> +12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page
>> table) */
>> +0, /* [111b] Reserved */
>> +0, /* [110b] Reserved */
>> +0, /* [111b] Reserved */
>> +};
>> +
>> +struct domain_values_entry *dve = NULL;
>> +
>> +
>> +if (!context_present(ce)) { /* If (context not present) */
>> +ret = RET_CCE_NOT_PRESENT; /* Skip it */
>> +goto exit;
>> +}
>> +
>> +t = context_translation_type(ce);
>> +
>> +/* If
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Thank you very much for your testing and fix. I will also test it on my
system.
I will let you know when I get a result.
Regards
Zhenhua
On 11/06/2014 03:51 PM, Takao Indoh wrote:
(2014/11/06 11:11), Li, ZhenHua wrote:
This patch does the same thing as you said in your mail.
It should work, I have tested on my HP huge system.
Yep, I also confirmed it worked.
BTW, I found another problem. When I tested your patches with 3.17
kernel, iommu initialization failed with the following message.
IOMMU intel_iommu_in_crashdump = true
IOMMU Skip disabling iommu hardware translations
IOMMU Copying translate tables from panicked kernel
IOMMU: Copy translate tables failed
IOMMU: dmar init failed
I found that oldcopy() from physical address 0x15000 was failed.
oldcopy() copies data using ioremap, and ioremap for the memory region
around 0x15000 does not work because it is already mapped to virtual
space.
arch/x86/mm/ioremap.c
static void __iomem *__ioremap_caller(resource_size_t phys_addr,
unsigned long size, unsigned long prot_val, void *caller)
{
(snip)
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
pfn = phys_addr PAGE_SHIFT;
last_pfn = last_addr PAGE_SHIFT;
if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
__ioremap_check_ram) == 1)
return NULL;
ioreamp failed HERE!
I'm not sure how we should handle this, but as far as I tested the
following fix works.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3a9e7b8..8d2bd23 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4871,7 +4871,12 @@ static int oldcopy(void *to, void *from, int size)
pfn = ((unsigned long) from) VTD_PAGE_SHIFT;
offset = ((unsigned long) from) (~VTD_PAGE_MASK);
- ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+
+ if (page_is_ram(pfn)) {
+ memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
+ ret = size;
+ } else
+ ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
return (int) ret;
}
Thanks,
Takao Indoh
On 11/06/2014 09:48 AM, Takao Indoh wrote:
(2014/11/06 10:35), Li, ZhenHua wrote:
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
+static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
devfn,
+ void *ppap, struct context_entry *ce)
+{
+int ret = 0;/* Integer Return Code */
+u32 shift = 0; /* bits to shift page_addr */
+u64 page_addr = 0; /* Address of translated page */
+struct dma_pte *pgt_old_phys; /* Adr(page_table in the old
kernel) */
+struct dma_pte *pgt_new_phys; /* Adr(page_table in the new
kernel) */
+u8 t; /* Translation-type from
context */
+u8 aw; /* Address-width from context */
+u32 aw_shift[8] = {
+12+9+9, /* [000b] 30-bit AGAW (2-level page
table) */
+12+9+9+9, /* [001b] 39-bit AGAW (3-level page
table) */
+12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page
table) */
+12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page
table) */
+12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page
table) */
+0, /* [111b] Reserved */
+0, /* [110b] Reserved */
+0, /* [111b] Reserved */
+};
+
+struct domain_values_entry *dve = NULL;
+
+
+if (!context_present(ce)) { /* If (context not present) */
+ret = RET_CCE_NOT_PRESENT; /* Skip it */
+goto exit;
+}
+
+t = context_translation_type(ce);
+
+/* If we have seen this domain-id before on this iommu,
+ * give this context the same page-tables and we are done.
+ */
+list_for_each_entry(dve, domain_values_list[iommu-seq_id],
link) {
+if (dve-did == (int) context_domain_id(ce)) {
+switch (t) {
+case 0: /* page tables */
+case
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
(2014/11/06 11:11), Li, ZhenHua wrote:
> This patch does the same thing as you said in your mail.
> It should work, I have tested on my HP huge system.
Yep, I also confirmed it worked.
BTW, I found another problem. When I tested your patches with 3.17
kernel, iommu initialization failed with the following message.
IOMMU intel_iommu_in_crashdump = true
IOMMU Skip disabling iommu hardware translations
IOMMU Copying translate tables from panicked kernel
IOMMU: Copy translate tables failed
IOMMU: dmar init failed
I found that oldcopy() from physical address 0x15000 was failed.
oldcopy() copies data using ioremap, and ioremap for the memory region
around 0x15000 does not work because it is already mapped to virtual
space.
static void __iomem *__ioremap_caller(resource_size_t phys_addr,
unsigned long size, unsigned long prot_val, void *caller)
{
(snip)
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
pfn = phys_addr >> PAGE_SHIFT;
last_pfn = last_addr >> PAGE_SHIFT;
if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
__ioremap_check_ram) == 1)
return NULL;
I'm not sure how we should handle this, but as far as I tested the
following fix works.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3a9e7b8..8d2bd23 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4871,7 +4871,12 @@ static int oldcopy(void *to, void *from, int size)
pfn = ((unsigned long) from) >> VTD_PAGE_SHIFT;
offset = ((unsigned long) from) & (~VTD_PAGE_MASK);
- ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+
+ if (page_is_ram(pfn)) {
+ memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
+ ret = size;
+ } else
+ ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
return (int) ret;
}
Thanks,
Takao Indoh
>
> On 11/06/2014 09:48 AM, Takao Indoh wrote:
>> (2014/11/06 10:35), Li, ZhenHua wrote:
>>> Yes, that's it. The function context_set_address_root does not set the
>>> address root correctly.
>>>
>>> I have created another patch for it, see
>>> https://lkml.org/lkml/2014/11/5/43
>>
>> Oh, ok. I'll try again with this patch, thank you.
>>
>> Thanks,
>> Takao Indoh
>>
>>>
>>> Thanks
>>> Zhenhua
>>>
>>> On 11/06/2014 09:31 AM, Takao Indoh wrote:
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
> Hi Zhenhua,
>
> I tested your latest patch on 3.18.0-rc1+, there are still some dmar
> errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
> devfn,
> + void *ppap, struct context_entry *ce)
> +{
> + int ret = 0;/* Integer Return Code */
> + u32 shift = 0; /* bits to shift page_addr */
> + u64 page_addr = 0; /* Address of translated page */
> + struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
> + struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
> + u8 t; /* Translation-type from context */
> + u8 aw; /* Address-width from context */
> + u32 aw_shift[8] = {
> + 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
> + 12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
> + 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
> + 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
> + 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
> + 0, /* [111b] Reserved */
> + 0, /* [110b] Reserved */
> + 0, /* [111b] Reserved */
> + };
> +
> + struct domain_values_entry *dve = NULL;
> +
> +
> + if (!context_present(ce)) { /* If (context not present) */
> + ret = RET_CCE_NOT_PRESENT; /* Skip it */
> + goto exit;
> + }
> +
> + t = context_translation_type(ce);
> +
> + /* If we have seen this domain-id before on this iommu,
> + * give this context the same page-tables and we are done.
> + */
> + list_for_each_entry(dve, _values_list[iommu->seq_id], link) {
> + if (dve->did == (int) context_domain_id(ce)) {
> + switch (t) {
> + case 0: /* page tables */
> + case 1: /* page tables */
> + context_set_address_root(ce,
> + virt_to_phys(dve->pgd));
Here, in context_set_address_root(), the new address is set like this:
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
This patch does the same thing as you said in your mail.
It should work, I have tested on my HP huge system.
On 11/06/2014 09:48 AM, Takao Indoh wrote:
> (2014/11/06 10:35), Li, ZhenHua wrote:
>> Yes, that's it. The function context_set_address_root does not set the
>> address root correctly.
>>
>> I have created another patch for it, see
>> https://lkml.org/lkml/2014/11/5/43
>
> Oh, ok. I'll try again with this patch, thank you.
>
> Thanks,
> Takao Indoh
>
>>
>> Thanks
>> Zhenhua
>>
>> On 11/06/2014 09:31 AM, Takao Indoh wrote:
>>> Hi Zhenhua, Baoquan,
>>>
>>> (2014/10/22 19:05), Baoquan He wrote:
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
>>>
>>> This should be a problem in copy_context_entry().
>>>
+static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
devfn,
+void *ppap, struct context_entry *ce)
+{
+ int ret = 0;/* Integer Return Code */
+ u32 shift = 0; /* bits to shift page_addr */
+ u64 page_addr = 0; /* Address of translated page */
+ struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
+ struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
+ u8 t; /* Translation-type from context */
+ u8 aw; /* Address-width from context */
+ u32 aw_shift[8] = {
+ 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
+ 12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
+ 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
+ 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
+ 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
+ 0, /* [111b] Reserved */
+ 0, /* [110b] Reserved */
+ 0, /* [111b] Reserved */
+ };
+
+ struct domain_values_entry *dve = NULL;
+
+
+ if (!context_present(ce)) { /* If (context not present) */
+ ret = RET_CCE_NOT_PRESENT; /* Skip it */
+ goto exit;
+ }
+
+ t = context_translation_type(ce);
+
+ /* If we have seen this domain-id before on this iommu,
+ * give this context the same page-tables and we are done.
+ */
+ list_for_each_entry(dve, _values_list[iommu->seq_id], link) {
+ if (dve->did == (int) context_domain_id(ce)) {
+ switch (t) {
+ case 0: /* page tables */
+ case 1: /* page tables */
+ context_set_address_root(ce,
+ virt_to_phys(dve->pgd));
>>>
>>> Here, in context_set_address_root(), the new address is set like this:
>>>
>>> context->lo |= value & VTD_PAGE_MASK;
>>>
>>> This is wrong, the logical disjunction of old address and new address
>>> becomes invalid address.
>>>
>>> This should be like this.
>>>
>>> case 1: /* page tables */
>>> ce->lo &= (~VTD_PAGE_MASK);
>>> context_set_address_root(ce,
>>> virt_to_phys(dve->pgd));
>>>
>>> And one more,
>>>
+ ret = RET_CCE_PREVIOUS_DID;
+ break;
+
+ case 2: /* Pass through */
+ if (dve->pgd == NULL)
+ ret = RET_CCE_PASS_THROUGH_2;
+ else
+ ret = RET_BADCOPY;
+ break;
+
+ default: /* Bad value of 't'*/
+ ret = RET_BADCOPY;
+ break;
+ }
+ goto exit;
+ }
+ }
>>> (snip)
+ if (t == 0 || t == 1) { /* If (context has page tables) */
+ aw = context_address_width(ce);
+ shift = aw_shift[aw];
+
+ pgt_old_phys = (struct dma_pte *)
+ (context_address_root(ce) << VTD_PAGE_SHIFT);
+
+ ret = copy_page_table(_new_phys, pgt_old_phys,
+ shift-9, page_addr, iommu, bus, devfn, dve, ppap);
+
+ if (ret)/* if (problem) bail out */
+ goto exit;
+
+ context_set_address_root(ce, (unsigned long)(pgt_new_phys));
>>>
>>> ditto.
>>>
>>> Thanks,
>>> Takao Indoh
>>>
>>>
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
(2014/11/06 10:35), Li, ZhenHua wrote:
> Yes, that's it. The function context_set_address_root does not set the
> address root correctly.
>
> I have created another patch for it, see
> https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
>
> Thanks
> Zhenhua
>
> On 11/06/2014 09:31 AM, Takao Indoh wrote:
>> Hi Zhenhua, Baoquan,
>>
>> (2014/10/22 19:05), Baoquan He wrote:
>>> Hi Zhenhua,
>>>
>>> I tested your latest patch on 3.18.0-rc1+, there are still some dmar
>>> errors. I remember it worked well with Bill's original patchset.
>>
>> This should be a problem in copy_context_entry().
>>
>>> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
>>> devfn,
>>> + void *ppap, struct context_entry *ce)
>>> +{
>>> + int ret = 0;/* Integer Return Code */
>>> + u32 shift = 0; /* bits to shift page_addr */
>>> + u64 page_addr = 0; /* Address of translated page */
>>> + struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
>>> + struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
>>> + u8 t; /* Translation-type from context */
>>> + u8 aw; /* Address-width from context */
>>> + u32 aw_shift[8] = {
>>> + 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
>>> + 12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
>>> + 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
>>> + 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
>>> + 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
>>> + 0, /* [111b] Reserved */
>>> + 0, /* [110b] Reserved */
>>> + 0, /* [111b] Reserved */
>>> + };
>>> +
>>> + struct domain_values_entry *dve = NULL;
>>> +
>>> +
>>> + if (!context_present(ce)) { /* If (context not present) */
>>> + ret = RET_CCE_NOT_PRESENT; /* Skip it */
>>> + goto exit;
>>> + }
>>> +
>>> + t = context_translation_type(ce);
>>> +
>>> + /* If we have seen this domain-id before on this iommu,
>>> +* give this context the same page-tables and we are done.
>>> +*/
>>> + list_for_each_entry(dve, _values_list[iommu->seq_id], link) {
>>> + if (dve->did == (int) context_domain_id(ce)) {
>>> + switch (t) {
>>> + case 0: /* page tables */
>>> + case 1: /* page tables */
>>> + context_set_address_root(ce,
>>> + virt_to_phys(dve->pgd));
>>
>> Here, in context_set_address_root(), the new address is set like this:
>>
>> context->lo |= value & VTD_PAGE_MASK;
>>
>> This is wrong, the logical disjunction of old address and new address
>> becomes invalid address.
>>
>> This should be like this.
>>
>> case 1: /* page tables */
>> ce->lo &= (~VTD_PAGE_MASK);
>> context_set_address_root(ce,
>> virt_to_phys(dve->pgd));
>>
>> And one more,
>>
>>> + ret = RET_CCE_PREVIOUS_DID;
>>> + break;
>>> +
>>> + case 2: /* Pass through */
>>> + if (dve->pgd == NULL)
>>> + ret = RET_CCE_PASS_THROUGH_2;
>>> + else
>>> + ret = RET_BADCOPY;
>>> + break;
>>> +
>>> + default: /* Bad value of 't'*/
>>> + ret = RET_BADCOPY;
>>> + break;
>>> + }
>>> + goto exit;
>>> + }
>>> + }
>> (snip)
>>> + if (t == 0 || t == 1) { /* If (context has page tables) */
>>> + aw = context_address_width(ce);
>>> + shift = aw_shift[aw];
>>> +
>>> + pgt_old_phys = (struct dma_pte *)
>>> + (context_address_root(ce) << VTD_PAGE_SHIFT);
>>> +
>>> + ret = copy_page_table(_new_phys, pgt_old_phys,
>>> + shift-9, page_addr, iommu, bus, devfn, dve, ppap);
>>> +
>>> + if (ret)/* if (problem) bail out */
>>> + goto exit;
>>> +
>>> + context_set_address_root(ce, (unsigned long)(pgt_new_phys));
>>
>> ditto.
>>
>> Thanks,
>> Takao Indoh
>>
>>
>>>
>>>
>>> 0console [earlya[0.00] allocate tes of page_cg 'a ong[
>>> 0.00] tsc: Fast TSC calibration using PIT
>>> 0031] Calibrating delay loop (skipped), value calculated using timer
>>> frequency.. 5586.77 BogoMIPS (lpj=2793386)
>>> [0.010682] pid_max: default: 32768 minimum: 301
>>> [0.015317] ACPI: Core revision
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
> Hi Zhenhua,
>
> I tested your latest patch on 3.18.0-rc1+, there are still some dmar
> errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32 devfn,
> + void *ppap, struct context_entry *ce)
> +{
> + int ret = 0;/* Integer Return Code */
> + u32 shift = 0; /* bits to shift page_addr */
> + u64 page_addr = 0; /* Address of translated page */
> + struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
> + struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
> + u8 t; /* Translation-type from context */
> + u8 aw; /* Address-width from context */
> + u32 aw_shift[8] = {
> + 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
> + 12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
> + 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
> + 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
> + 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
> + 0, /* [111b] Reserved */
> + 0, /* [110b] Reserved */
> + 0, /* [111b] Reserved */
> + };
> +
> + struct domain_values_entry *dve = NULL;
> +
> +
> + if (!context_present(ce)) { /* If (context not present) */
> + ret = RET_CCE_NOT_PRESENT; /* Skip it */
> + goto exit;
> + }
> +
> + t = context_translation_type(ce);
> +
> + /* If we have seen this domain-id before on this iommu,
> + * give this context the same page-tables and we are done.
> + */
> + list_for_each_entry(dve, _values_list[iommu->seq_id], link) {
> + if (dve->did == (int) context_domain_id(ce)) {
> + switch (t) {
> + case 0: /* page tables */
> + case 1: /* page tables */
> + context_set_address_root(ce,
> + virt_to_phys(dve->pgd));
Here, in context_set_address_root(), the new address is set like this:
context->lo |= value & VTD_PAGE_MASK;
This is wrong, the logical disjunction of old address and new address
becomes invalid address.
This should be like this.
case 1: /* page tables */
ce->lo &= (~VTD_PAGE_MASK);
context_set_address_root(ce,
virt_to_phys(dve->pgd));
And one more,
> + ret = RET_CCE_PREVIOUS_DID;
> + break;
> +
> + case 2: /* Pass through */
> + if (dve->pgd == NULL)
> + ret = RET_CCE_PASS_THROUGH_2;
> + else
> + ret = RET_BADCOPY;
> + break;
> +
> + default: /* Bad value of 't'*/
> + ret = RET_BADCOPY;
> + break;
> + }
> + goto exit;
> + }
> + }
(snip)
> + if (t == 0 || t == 1) { /* If (context has page tables) */
> + aw = context_address_width(ce);
> + shift = aw_shift[aw];
> +
> + pgt_old_phys = (struct dma_pte *)
> + (context_address_root(ce) << VTD_PAGE_SHIFT);
> +
> + ret = copy_page_table(_new_phys, pgt_old_phys,
> + shift-9, page_addr, iommu, bus, devfn, dve, ppap);
> +
> + if (ret)/* if (problem) bail out */
> + goto exit;
> +
> + context_set_address_root(ce, (unsigned long)(pgt_new_phys));
ditto.
Thanks,
Takao Indoh
>
>
> 0console [earlya[0.00] allocate tes of page_cg 'a ong[
> 0.00] tsc: Fast TSC calibration using PIT
> 0031] Calibrating delay loop (skipped), value calculated using timer
> frequency.. 5586.77 BogoMIPS (lpj=2793386)
> [0.010682] pid_max: default: 32768 minimum: 301
> [0.015317] ACPI: Core revision 20140828
> [0.044598] ACPI: All ACPI Tables successfully acquired
> [0.126450] Security Framework initialized
> [0.130569] SELinux: Initializing.
> [0.135211] Dentry cache hash table entries: 2097152 (order: 12,
> 16777216 bytes)
> [0.145731] Inode-cache hash table entries: 1048576 (order: 11,
> 8388608 bytes)
> [0.154249] Mount-cache hash table entries: 32768 (order: 6, 262144
> bytes)
> [0.161163] Mountpoint-cache hash table entries: 32768 (order: 6,
>
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
> Hi Zhenhua, Baoquan,
>
> (2014/10/22 19:05), Baoquan He wrote:
>> Hi Zhenhua,
>>
>> I tested your latest patch on 3.18.0-rc1+, there are still some dmar
>> errors. I remember it worked well with Bill's original patchset.
>
> This should be a problem in copy_context_entry().
>
>> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32 devfn,
>> + void *ppap, struct context_entry *ce)
>> +{
>> +int ret = 0;/* Integer Return Code */
>> +u32 shift = 0; /* bits to shift page_addr */
>> +u64 page_addr = 0; /* Address of translated page */
>> +struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
>> +struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
>> +u8 t; /* Translation-type from context */
>> +u8 aw; /* Address-width from context */
>> +u32 aw_shift[8] = {
>> +12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
>> +12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
>> +12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
>> +12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
>> +12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
>> +0, /* [111b] Reserved */
>> +0, /* [110b] Reserved */
>> +0, /* [111b] Reserved */
>> +};
>> +
>> +struct domain_values_entry *dve = NULL;
>> +
>> +
>> +if (!context_present(ce)) { /* If (context not present) */
>> +ret = RET_CCE_NOT_PRESENT; /* Skip it */
>> +goto exit;
>> +}
>> +
>> +t = context_translation_type(ce);
>> +
>> +/* If we have seen this domain-id before on this iommu,
>> + * give this context the same page-tables and we are done.
>> + */
>> +list_for_each_entry(dve, _values_list[iommu->seq_id], link) {
>> +if (dve->did == (int) context_domain_id(ce)) {
>> +switch (t) {
>> +case 0: /* page tables */
>> +case 1: /* page tables */
>> +context_set_address_root(ce,
>> +virt_to_phys(dve->pgd));
>
> Here, in context_set_address_root(), the new address is set like this:
>
> context->lo |= value & VTD_PAGE_MASK;
>
> This is wrong, the logical disjunction of old address and new address
> becomes invalid address.
>
> This should be like this.
>
> case 1: /* page tables */
> ce->lo &= (~VTD_PAGE_MASK);
> context_set_address_root(ce,
> virt_to_phys(dve->pgd));
>
> And one more,
>
>> +ret = RET_CCE_PREVIOUS_DID;
>> +break;
>> +
>> +case 2: /* Pass through */
>> +if (dve->pgd == NULL)
>> +ret = RET_CCE_PASS_THROUGH_2;
>> +else
>> +ret = RET_BADCOPY;
>> +break;
>> +
>> +default: /* Bad value of 't'*/
>> +ret = RET_BADCOPY;
>> +break;
>> +}
>> +goto exit;
>> +}
>> +}
> (snip)
>> +if (t == 0 || t == 1) { /* If (context has page tables) */
>> +aw = context_address_width(ce);
>> +shift = aw_shift[aw];
>> +
>> +pgt_old_phys = (struct dma_pte *)
>> +(context_address_root(ce) << VTD_PAGE_SHIFT);
>> +
>> +ret = copy_page_table(_new_phys, pgt_old_phys,
>> +shift-9, page_addr, iommu, bus, devfn, dve, ppap);
>> +
>> +if (ret)/* if (problem) bail out */
>> +goto exit;
>> +
>> +context_set_address_root(ce, (unsigned long)(pgt_new_phys));
>
> ditto.
>
> Thanks,
> Takao Indoh
>
>
>>
>>
>> 0console [earlya[0.00] allocate tes of page_cg 'a ong[
>> 0.00] tsc: Fast TSC calibration using PIT
>> 0031] Calibrating delay loop (skipped), value calculated using timer
>> frequency.. 5586.77 BogoMIPS (lpj=2793386)
>> [0.010682] pid_max: default: 32768 minimum: 301
>> [0.015317] ACPI: Core revision 20140828
>> [0.044598] ACPI: All ACPI Tables successfully acquired
>> [0.126450] Security Framework initialized
>> [0.130569] SELinux: Initializing.
>> [
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
+static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32 devfn,
+ void *ppap, struct context_entry *ce)
+{
+int ret = 0;/* Integer Return Code */
+u32 shift = 0; /* bits to shift page_addr */
+u64 page_addr = 0; /* Address of translated page */
+struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
+struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
+u8 t; /* Translation-type from context */
+u8 aw; /* Address-width from context */
+u32 aw_shift[8] = {
+12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
+12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
+12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
+12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
+12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
+0, /* [111b] Reserved */
+0, /* [110b] Reserved */
+0, /* [111b] Reserved */
+};
+
+struct domain_values_entry *dve = NULL;
+
+
+if (!context_present(ce)) { /* If (context not present) */
+ret = RET_CCE_NOT_PRESENT; /* Skip it */
+goto exit;
+}
+
+t = context_translation_type(ce);
+
+/* If we have seen this domain-id before on this iommu,
+ * give this context the same page-tables and we are done.
+ */
+list_for_each_entry(dve, domain_values_list[iommu-seq_id], link) {
+if (dve-did == (int) context_domain_id(ce)) {
+switch (t) {
+case 0: /* page tables */
+case 1: /* page tables */
+context_set_address_root(ce,
+virt_to_phys(dve-pgd));
Here, in context_set_address_root(), the new address is set like this:
context-lo |= value VTD_PAGE_MASK;
This is wrong, the logical disjunction of old address and new address
becomes invalid address.
This should be like this.
case 1: /* page tables */
ce-lo = (~VTD_PAGE_MASK);
context_set_address_root(ce,
virt_to_phys(dve-pgd));
And one more,
+ret = RET_CCE_PREVIOUS_DID;
+break;
+
+case 2: /* Pass through */
+if (dve-pgd == NULL)
+ret = RET_CCE_PASS_THROUGH_2;
+else
+ret = RET_BADCOPY;
+break;
+
+default: /* Bad value of 't'*/
+ret = RET_BADCOPY;
+break;
+}
+goto exit;
+}
+}
(snip)
+if (t == 0 || t == 1) { /* If (context has page tables) */
+aw = context_address_width(ce);
+shift = aw_shift[aw];
+
+pgt_old_phys = (struct dma_pte *)
+(context_address_root(ce) VTD_PAGE_SHIFT);
+
+ret = copy_page_table(pgt_new_phys, pgt_old_phys,
+shift-9, page_addr, iommu, bus, devfn, dve, ppap);
+
+if (ret)/* if (problem) bail out */
+goto exit;
+
+context_set_address_root(ce, (unsigned long)(pgt_new_phys));
ditto.
Thanks,
Takao Indoh
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using PIT
0031] Calibrating delay loop (skipped), value calculated using timer
frequency.. 5586.77 BogoMIPS (lpj=2793386)
[0.010682] pid_max: default: 32768 minimum: 301
[0.015317] ACPI: Core revision 20140828
[0.044598] ACPI: All ACPI Tables successfully acquired
[0.126450] Security Framework initialized
[0.130569] SELinux: Initializing.
[0.135211] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[0.145731] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[0.154249] Mount-cache hash table entries:
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
+static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32 devfn,
+ void *ppap, struct context_entry *ce)
+{
+ int ret = 0;/* Integer Return Code */
+ u32 shift = 0; /* bits to shift page_addr */
+ u64 page_addr = 0; /* Address of translated page */
+ struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
+ struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
+ u8 t; /* Translation-type from context */
+ u8 aw; /* Address-width from context */
+ u32 aw_shift[8] = {
+ 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
+ 12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
+ 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
+ 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
+ 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
+ 0, /* [111b] Reserved */
+ 0, /* [110b] Reserved */
+ 0, /* [111b] Reserved */
+ };
+
+ struct domain_values_entry *dve = NULL;
+
+
+ if (!context_present(ce)) { /* If (context not present) */
+ ret = RET_CCE_NOT_PRESENT; /* Skip it */
+ goto exit;
+ }
+
+ t = context_translation_type(ce);
+
+ /* If we have seen this domain-id before on this iommu,
+ * give this context the same page-tables and we are done.
+ */
+ list_for_each_entry(dve, domain_values_list[iommu-seq_id], link) {
+ if (dve-did == (int) context_domain_id(ce)) {
+ switch (t) {
+ case 0: /* page tables */
+ case 1: /* page tables */
+ context_set_address_root(ce,
+ virt_to_phys(dve-pgd));
Here, in context_set_address_root(), the new address is set like this:
context-lo |= value VTD_PAGE_MASK;
This is wrong, the logical disjunction of old address and new address
becomes invalid address.
This should be like this.
case 1: /* page tables */
ce-lo = (~VTD_PAGE_MASK);
context_set_address_root(ce,
virt_to_phys(dve-pgd));
And one more,
+ ret = RET_CCE_PREVIOUS_DID;
+ break;
+
+ case 2: /* Pass through */
+ if (dve-pgd == NULL)
+ ret = RET_CCE_PASS_THROUGH_2;
+ else
+ ret = RET_BADCOPY;
+ break;
+
+ default: /* Bad value of 't'*/
+ ret = RET_BADCOPY;
+ break;
+ }
+ goto exit;
+ }
+ }
(snip)
+ if (t == 0 || t == 1) { /* If (context has page tables) */
+ aw = context_address_width(ce);
+ shift = aw_shift[aw];
+
+ pgt_old_phys = (struct dma_pte *)
+ (context_address_root(ce) VTD_PAGE_SHIFT);
+
+ ret = copy_page_table(pgt_new_phys, pgt_old_phys,
+ shift-9, page_addr, iommu, bus, devfn, dve, ppap);
+
+ if (ret)/* if (problem) bail out */
+ goto exit;
+
+ context_set_address_root(ce, (unsigned long)(pgt_new_phys));
ditto.
Thanks,
Takao Indoh
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using PIT
0031] Calibrating delay loop (skipped), value calculated using timer
frequency.. 5586.77 BogoMIPS (lpj=2793386)
[0.010682] pid_max: default: 32768 minimum: 301
[0.015317] ACPI: Core revision 20140828
[0.044598] ACPI: All ACPI Tables successfully acquired
[0.126450] Security Framework initialized
[0.130569] SELinux: Initializing.
[0.135211] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[0.145731] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[0.154249] Mount-cache hash table entries: 32768 (order: 6, 262144
bytes)
[0.161163] Mountpoint-cache hash table entries: 32768 (order: 6,
262144 bytes)
[0.168731] Initializing cgroup subsys memory
[0.173110] Initializing cgroup
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
(2014/11/06 10:35), Li, ZhenHua wrote:
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
+static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
devfn,
+ void *ppap, struct context_entry *ce)
+{
+ int ret = 0;/* Integer Return Code */
+ u32 shift = 0; /* bits to shift page_addr */
+ u64 page_addr = 0; /* Address of translated page */
+ struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
+ struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
+ u8 t; /* Translation-type from context */
+ u8 aw; /* Address-width from context */
+ u32 aw_shift[8] = {
+ 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
+ 12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
+ 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
+ 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
+ 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
+ 0, /* [111b] Reserved */
+ 0, /* [110b] Reserved */
+ 0, /* [111b] Reserved */
+ };
+
+ struct domain_values_entry *dve = NULL;
+
+
+ if (!context_present(ce)) { /* If (context not present) */
+ ret = RET_CCE_NOT_PRESENT; /* Skip it */
+ goto exit;
+ }
+
+ t = context_translation_type(ce);
+
+ /* If we have seen this domain-id before on this iommu,
+* give this context the same page-tables and we are done.
+*/
+ list_for_each_entry(dve, domain_values_list[iommu-seq_id], link) {
+ if (dve-did == (int) context_domain_id(ce)) {
+ switch (t) {
+ case 0: /* page tables */
+ case 1: /* page tables */
+ context_set_address_root(ce,
+ virt_to_phys(dve-pgd));
Here, in context_set_address_root(), the new address is set like this:
context-lo |= value VTD_PAGE_MASK;
This is wrong, the logical disjunction of old address and new address
becomes invalid address.
This should be like this.
case 1: /* page tables */
ce-lo = (~VTD_PAGE_MASK);
context_set_address_root(ce,
virt_to_phys(dve-pgd));
And one more,
+ ret = RET_CCE_PREVIOUS_DID;
+ break;
+
+ case 2: /* Pass through */
+ if (dve-pgd == NULL)
+ ret = RET_CCE_PASS_THROUGH_2;
+ else
+ ret = RET_BADCOPY;
+ break;
+
+ default: /* Bad value of 't'*/
+ ret = RET_BADCOPY;
+ break;
+ }
+ goto exit;
+ }
+ }
(snip)
+ if (t == 0 || t == 1) { /* If (context has page tables) */
+ aw = context_address_width(ce);
+ shift = aw_shift[aw];
+
+ pgt_old_phys = (struct dma_pte *)
+ (context_address_root(ce) VTD_PAGE_SHIFT);
+
+ ret = copy_page_table(pgt_new_phys, pgt_old_phys,
+ shift-9, page_addr, iommu, bus, devfn, dve, ppap);
+
+ if (ret)/* if (problem) bail out */
+ goto exit;
+
+ context_set_address_root(ce, (unsigned long)(pgt_new_phys));
ditto.
Thanks,
Takao Indoh
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using PIT
0031] Calibrating delay loop (skipped), value calculated using timer
frequency.. 5586.77 BogoMIPS (lpj=2793386)
[0.010682] pid_max: default: 32768 minimum: 301
[0.015317] ACPI: Core revision 20140828
[0.044598] ACPI: All ACPI Tables successfully acquired
[0.126450] Security Framework initialized
[0.130569] SELinux: Initializing.
[0.135211] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes)
[0.145731] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes)
[
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
This patch does the same thing as you said in your mail.
It should work, I have tested on my HP huge system.
On 11/06/2014 09:48 AM, Takao Indoh wrote:
(2014/11/06 10:35), Li, ZhenHua wrote:
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
+static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
devfn,
+void *ppap, struct context_entry *ce)
+{
+ int ret = 0;/* Integer Return Code */
+ u32 shift = 0; /* bits to shift page_addr */
+ u64 page_addr = 0; /* Address of translated page */
+ struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
+ struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
+ u8 t; /* Translation-type from context */
+ u8 aw; /* Address-width from context */
+ u32 aw_shift[8] = {
+ 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
+ 12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
+ 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
+ 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
+ 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
+ 0, /* [111b] Reserved */
+ 0, /* [110b] Reserved */
+ 0, /* [111b] Reserved */
+ };
+
+ struct domain_values_entry *dve = NULL;
+
+
+ if (!context_present(ce)) { /* If (context not present) */
+ ret = RET_CCE_NOT_PRESENT; /* Skip it */
+ goto exit;
+ }
+
+ t = context_translation_type(ce);
+
+ /* If we have seen this domain-id before on this iommu,
+ * give this context the same page-tables and we are done.
+ */
+ list_for_each_entry(dve, domain_values_list[iommu-seq_id], link) {
+ if (dve-did == (int) context_domain_id(ce)) {
+ switch (t) {
+ case 0: /* page tables */
+ case 1: /* page tables */
+ context_set_address_root(ce,
+ virt_to_phys(dve-pgd));
Here, in context_set_address_root(), the new address is set like this:
context-lo |= value VTD_PAGE_MASK;
This is wrong, the logical disjunction of old address and new address
becomes invalid address.
This should be like this.
case 1: /* page tables */
ce-lo = (~VTD_PAGE_MASK);
context_set_address_root(ce,
virt_to_phys(dve-pgd));
And one more,
+ ret = RET_CCE_PREVIOUS_DID;
+ break;
+
+ case 2: /* Pass through */
+ if (dve-pgd == NULL)
+ ret = RET_CCE_PASS_THROUGH_2;
+ else
+ ret = RET_BADCOPY;
+ break;
+
+ default: /* Bad value of 't'*/
+ ret = RET_BADCOPY;
+ break;
+ }
+ goto exit;
+ }
+ }
(snip)
+ if (t == 0 || t == 1) { /* If (context has page tables) */
+ aw = context_address_width(ce);
+ shift = aw_shift[aw];
+
+ pgt_old_phys = (struct dma_pte *)
+ (context_address_root(ce) VTD_PAGE_SHIFT);
+
+ ret = copy_page_table(pgt_new_phys, pgt_old_phys,
+ shift-9, page_addr, iommu, bus, devfn, dve, ppap);
+
+ if (ret)/* if (problem) bail out */
+ goto exit;
+
+ context_set_address_root(ce, (unsigned long)(pgt_new_phys));
ditto.
Thanks,
Takao Indoh
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using PIT
0031] Calibrating delay loop (skipped), value calculated using timer
frequency.. 5586.77 BogoMIPS (lpj=2793386)
[0.010682] pid_max: default: 32768 minimum: 301
[0.015317] ACPI: Core revision 20140828
[0.044598] ACPI: All ACPI Tables successfully acquired
[0.126450] Security Framework initialized
[0.130569] SELinux: Initializing.
[0.135211] Dentry cache hash table entries: 2097152 (order: 12,
16777216
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
(2014/11/06 11:11), Li, ZhenHua wrote:
This patch does the same thing as you said in your mail.
It should work, I have tested on my HP huge system.
Yep, I also confirmed it worked.
BTW, I found another problem. When I tested your patches with 3.17
kernel, iommu initialization failed with the following message.
IOMMU intel_iommu_in_crashdump = true
IOMMU Skip disabling iommu hardware translations
IOMMU Copying translate tables from panicked kernel
IOMMU: Copy translate tables failed
IOMMU: dmar init failed
I found that oldcopy() from physical address 0x15000 was failed.
oldcopy() copies data using ioremap, and ioremap for the memory region
around 0x15000 does not work because it is already mapped to virtual
space.
arch/x86/mm/ioremap.c
static void __iomem *__ioremap_caller(resource_size_t phys_addr,
unsigned long size, unsigned long prot_val, void *caller)
{
(snip)
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
pfn = phys_addr PAGE_SHIFT;
last_pfn = last_addr PAGE_SHIFT;
if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
__ioremap_check_ram) == 1)
return NULL;
ioreamp failed HERE!
I'm not sure how we should handle this, but as far as I tested the
following fix works.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3a9e7b8..8d2bd23 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4871,7 +4871,12 @@ static int oldcopy(void *to, void *from, int size)
pfn = ((unsigned long) from) VTD_PAGE_SHIFT;
offset = ((unsigned long) from) (~VTD_PAGE_MASK);
- ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
+
+ if (page_is_ram(pfn)) {
+ memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
+ ret = size;
+ } else
+ ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
return (int) ret;
}
Thanks,
Takao Indoh
On 11/06/2014 09:48 AM, Takao Indoh wrote:
(2014/11/06 10:35), Li, ZhenHua wrote:
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
Hi Zhenhua, Baoquan,
(2014/10/22 19:05), Baoquan He wrote:
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
+static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
devfn,
+ void *ppap, struct context_entry *ce)
+{
+ int ret = 0;/* Integer Return Code */
+ u32 shift = 0; /* bits to shift page_addr */
+ u64 page_addr = 0; /* Address of translated page */
+ struct dma_pte *pgt_old_phys; /* Adr(page_table in the old kernel) */
+ struct dma_pte *pgt_new_phys; /* Adr(page_table in the new kernel) */
+ u8 t; /* Translation-type from context */
+ u8 aw; /* Address-width from context */
+ u32 aw_shift[8] = {
+ 12+9+9, /* [000b] 30-bit AGAW (2-level page table) */
+ 12+9+9+9, /* [001b] 39-bit AGAW (3-level page table) */
+ 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page table) */
+ 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page table) */
+ 12+9+9+9+9+9+9, /* [100b] 64-bit AGAW (6-level page table) */
+ 0, /* [111b] Reserved */
+ 0, /* [110b] Reserved */
+ 0, /* [111b] Reserved */
+ };
+
+ struct domain_values_entry *dve = NULL;
+
+
+ if (!context_present(ce)) { /* If (context not present) */
+ ret = RET_CCE_NOT_PRESENT; /* Skip it */
+ goto exit;
+ }
+
+ t = context_translation_type(ce);
+
+ /* If we have seen this domain-id before on this iommu,
+ * give this context the same page-tables and we are done.
+ */
+ list_for_each_entry(dve, domain_values_list[iommu-seq_id], link) {
+ if (dve-did == (int) context_domain_id(ce)) {
+ switch (t) {
+ case 0: /* page tables */
+ case 1: /* page tables */
+ context_set_address_root(ce,
+ virt_to_phys(dve-pgd));
Here, in context_set_address_root(), the new address is set like this:
context-lo |= value VTD_PAGE_MASK;
This is wrong, the logical disjunction of old address and new address
becomes invalid address.
This should be like this.
case 1: /* page tables */
ce-lo = (~VTD_PAGE_MASK);
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On 10/27/14 at 03:29pm, Li, ZhenHua wrote: > Hi Baoquan, > I failed in testing this patchset for 3.18.0-rc1, this upstream > 3.18.0-rc1 kernel cannot boot on my system, have not found out the > reason. > > Could you please test this patchset on 3.17.0 to see whether it has > these faults? > > Thanks > Zhenhua Failed too on 3.17.0, check the log as below: [0.103751] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) [0.110285] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) [0.117549] Initializing cgroup subsys memory [0.121917] Initializing cgroup subsys devices [0.126367] Initializing cgroup subsys freezer [0.130817] Initializing cgroup subsys net_cls [0.135265] Initializing cgroup subsys blkio [0.139545] Initializing cgroup subsys perf_event [0.144254] Initializing cgroup subsys hugetlb [0.148741] CPU: Physical Processor ID: 0 [0.152751] CPU: Processor Core ID: 1 [0.156427] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [0.156427] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [0.180040] Freeing SMP alternatives memory: 24K (ade7a000 - ade8) [0.190787] ftrace: allocating 26881 entries in 106 pages [0.222955] dmar: Host address width 46 [0.226796] dmar: DRHD base: 0x00dfffc000 flags: 0x1 [0.232128] dmar: IOMMU 0: reg_base_addr dfffc000 ver 1:0 cap d2078c106f0462 ecap f020fe [0.240223] dmar: RMRR base: 0x00cba11000 end: 0x00cba27fff [0.246495] dmar: ATSR flags: 0x0 [0.249921] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 0 [0.255499] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 0 [0.261076] HPET id 0 under DRHD base 0xdfffc000 [0.265899] Enabled IRQ remapping in xapic mode [0.271030] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [0.287077] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz (fam: 06, model: 2d, stepping: 07) [0.296535] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, full-width counters, Broken BIOS detected, complain to your hardware vendor. [0.310427] [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is b0) [0.318087] Intel PMU driver. [0.321065] ... version:3 [0.325077] ... bit width: 48 [0.329180] ... generic registers: 8 [0.333198] ... value mask: [0.338516] ... max period: [0.343834] ... fixed-purpose events: 3 [0.347848] ... event mask: 000700ff [0.355607] x86: Booted up 1 node, 1 CPUs [0.359627] smpboot: Total of 1 processors activated (5586.06 BogoMIPS) [0.366281] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [0.377496] devtmpfs: initialized [0.386629] PM: Registering ACPI NVS region [mem 0xcb75-0xcb7dafff] (569344 bytes) [0.394583] PM: Registering ACPI NVS region [mem 0xcbaad000-0xcbaaefff] (8192 bytes) [0.402337] PM: Registering ACPI NVS region [mem 0xcbabb000-0xcbacdfff] (77824 bytes) [0.410169] PM: Registering ACPI NVS region [mem 0xcbb56000-0xcbb5dfff] (32768 bytes) [0.418005] PM: Registering ACPI NVS region [mem 0xcbb71000-0xcbff] (4780032 bytes) [0.427905] atomic64_test: passed for x86-64 platform with CX8 and with SSE [0.434883] pinctrl core: initialized pinctrl subsystem [0.440171] RTC time: 10:38:17, date: 10/27/14 [0.444783] NET: Registered protocol family 16 [0.449652] cpuidle: using governor menu [0.453820] ACPI: bus type PCI registered [0.457841] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [0.464406] PCI: MMCONFIG for domain [bus 00-ff] at [mem 0xe000-0xefff] (base 0xe000) [0.473718] PCI: MMCONFIG at [mem 0xe000-0xefff] reserved in E820 [0.481119] PCI: Using configuration type 1 for base access [0.489116] ACPI: Added _OSI(Module Device) [0.493313] ACPI: Added _OSI(Processor Device) [0.497768] ACPI: Added _OSI(3.0 _SCP Extensions) [0.502477] ACPI: Added _OSI(Processor Aggregator Device) [0.521054] ACPI: Executed 1 blocks of module-level executable AML code [0.653647] ACPI: Interpreter enabled [0.657334] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140724/hwxface-580) [0.10] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140724/hwxface-580) [0.675902] ACPI: (supports S0 S3 S4 S5) [0.679833] ACPI: Using IOAPIC for interrupt routing [0.684858] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [0.695495] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [0.717663] ACPI: PCI Root Bridge [PCI0] (domain [bus 00-7f]) [0.723860] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [0.732282] acpi PNP0A08:00: _OSC: platform does not support [PCIeCapability] [0.739533] acpi
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Baoquan, I failed in testing this patchset for 3.18.0-rc1, this upstream 3.18.0-rc1 kernel cannot boot on my system, have not found out the reason. Could you please test this patchset on 3.17.0 to see whether it has these faults? Thanks Zhenhua On 10/22/2014 06:05 PM, Baoquan He wrote: Hi Zhenhua, I tested your latest patch on 3.18.0-rc1+, there are still some dmar errors. I remember it worked well with Bill's original patchset. 0console [earlya[0.00] allocate tes of page_cg 'a ong[ 0.00] tsc: Fast TSC calibration using PIT 0031] Calibrating delay loop (skipped), value calculated using timer frequency.. 5586.77 BogoMIPS (lpj=2793386) [0.010682] pid_max: default: 32768 minimum: 301 [0.015317] ACPI: Core revision 20140828 [0.044598] ACPI: All ACPI Tables successfully acquired [0.126450] Security Framework initialized [0.130569] SELinux: Initializing. [0.135211] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) [0.145731] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) [0.154249] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.161163] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.168731] Initializing cgroup subsys memory [0.173110] Initializing cgroup subsys devices [0.177570] Initializing cgroup subsys freezer [0.182026] Initializing cgroup subsys net_cls [0.186483] Initializing cgroup subsys blkio [0.190763] Initializing cgroup subsys perf_event [0.195479] Initializing cgroup subsys hugetlb [0.199955] CPU: Physical Processor ID: 0 [0.203972] CPU: Processor Core ID: 0 [0.207649] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [0.207649] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [0.220704] mce: CPU supports 16 MCE banks [0.224832] CPU0: Thermal monitoring enabled (TM1) [0.229658] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [0.229658] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [0.241537] Freeing SMP alternatives memory: 24K (81e8 - 81e86000) [0.250740] ftrace: allocating 27051 entries in 106 pages [0.268137] dmar: Host address width 46 [0.271986] dmar: DRHD base: 0x00dfffc000 flags: 0x1 [0.277314] dmar: IOMMU 0: reg_base_addr dfffc000 ver 1:0 cap d2078c106f0462 ecap f020fe [0.285423] dmar: RMRR base: 0x00cba11000 end: 0x00cba27fff [0.291703] dmar: ATSR flags: 0x0 [0.295122] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 0 [0.300704] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 0 [0.306281] HPET id 0 under DRHD base 0xdfffc000 [0.311011] Enabled IRQ remapping in xapic mode [0.316070] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [0.332096] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz (fam: 06, model: 2d, stepping: 07) [0.341495] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, full-width counters, Intel PMU driver. [0.352047] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode [0.360060] ... version:3 [0.364081] ... bit width: 48 [0.368182] ... generic registers: 8 [0.372196] ... value mask: [0.377513] ... max period: [0.382829] ... fixed-purpose events: 3 [0.386842] ... event mask: 000700ff [0.393368] x86: Booting SMP configuration: [0.397563] node #0, CPUs: #1 [0.414672] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [0.422957] #2 #3 [0.451320] x86: Booted up 1 node, 4 CPUs [0.455539] smpboot: Total of 4 processors activated (22347.08 BogoMIPS) [0.466369] devtmpfs: initialized [0.472993] PM: Registering ACPI NVS region [mem 0xcb75-0xcb7dafff] (569344 bytes) [0.480930] PM: Registering ACPI NVS region [mem 0xcbaad000-0xcbaaefff] (8192 bytes) [0.488689] PM: Registering ACPI NVS region [mem 0xcbabb000-0xcbacdfff] (77824 bytes) [0.496535] PM: Registering ACPI NVS region [mem 0xcbb56000-0xcbb5dfff] (32768 bytes) [0.504380] PM: Registering ACPI NVS region [mem 0xcbb71000-0xcbff] (4780032 bytes) [0.513294] atomic64_test: passed for x86-64 platform with CX8 and with SSE [0.520272] pinctrl core: initialized pinctrl subsystem [0.525549] RTC time: 9:52:43, date: 10/22/14 [0.530096] NET: Registered protocol family 16 [0.539573] cpuidle: using governor menu [0.543583] ACPI: bus type PCI registered [0.547608] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [0.554133] PCI: MMCONFIG for domain [bus 00-ff] at [mem 0xe000-0xefff] (base 0xe000) [0.563457] PCI: MMCONFIG at [mem 0xe000-0xefff] reserved in E820 [0.570548] PCI: Using configuration type 1 for base access [0.582492] ACPI: Added _OSI(Module Device) [0.586683]
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Baoquan, I failed in testing this patchset for 3.18.0-rc1, this upstream 3.18.0-rc1 kernel cannot boot on my system, have not found out the reason. Could you please test this patchset on 3.17.0 to see whether it has these faults? Thanks Zhenhua On 10/22/2014 06:05 PM, Baoquan He wrote: Hi Zhenhua, I tested your latest patch on 3.18.0-rc1+, there are still some dmar errors. I remember it worked well with Bill's original patchset. 0console [earlya[0.00] allocate tes of page_cg 'a ong[ 0.00] tsc: Fast TSC calibration using PIT 0031] Calibrating delay loop (skipped), value calculated using timer frequency.. 5586.77 BogoMIPS (lpj=2793386) [0.010682] pid_max: default: 32768 minimum: 301 [0.015317] ACPI: Core revision 20140828 [0.044598] ACPI: All ACPI Tables successfully acquired [0.126450] Security Framework initialized [0.130569] SELinux: Initializing. [0.135211] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) [0.145731] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) [0.154249] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.161163] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.168731] Initializing cgroup subsys memory [0.173110] Initializing cgroup subsys devices [0.177570] Initializing cgroup subsys freezer [0.182026] Initializing cgroup subsys net_cls [0.186483] Initializing cgroup subsys blkio [0.190763] Initializing cgroup subsys perf_event [0.195479] Initializing cgroup subsys hugetlb [0.199955] CPU: Physical Processor ID: 0 [0.203972] CPU: Processor Core ID: 0 [0.207649] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [0.207649] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [0.220704] mce: CPU supports 16 MCE banks [0.224832] CPU0: Thermal monitoring enabled (TM1) [0.229658] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [0.229658] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [0.241537] Freeing SMP alternatives memory: 24K (81e8 - 81e86000) [0.250740] ftrace: allocating 27051 entries in 106 pages [0.268137] dmar: Host address width 46 [0.271986] dmar: DRHD base: 0x00dfffc000 flags: 0x1 [0.277314] dmar: IOMMU 0: reg_base_addr dfffc000 ver 1:0 cap d2078c106f0462 ecap f020fe [0.285423] dmar: RMRR base: 0x00cba11000 end: 0x00cba27fff [0.291703] dmar: ATSR flags: 0x0 [0.295122] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 0 [0.300704] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 0 [0.306281] HPET id 0 under DRHD base 0xdfffc000 [0.311011] Enabled IRQ remapping in xapic mode [0.316070] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [0.332096] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz (fam: 06, model: 2d, stepping: 07) [0.341495] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, full-width counters, Intel PMU driver. [0.352047] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode [0.360060] ... version:3 [0.364081] ... bit width: 48 [0.368182] ... generic registers: 8 [0.372196] ... value mask: [0.377513] ... max period: [0.382829] ... fixed-purpose events: 3 [0.386842] ... event mask: 000700ff [0.393368] x86: Booting SMP configuration: [0.397563] node #0, CPUs: #1 [0.414672] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [0.422957] #2 #3 [0.451320] x86: Booted up 1 node, 4 CPUs [0.455539] smpboot: Total of 4 processors activated (22347.08 BogoMIPS) [0.466369] devtmpfs: initialized [0.472993] PM: Registering ACPI NVS region [mem 0xcb75-0xcb7dafff] (569344 bytes) [0.480930] PM: Registering ACPI NVS region [mem 0xcbaad000-0xcbaaefff] (8192 bytes) [0.488689] PM: Registering ACPI NVS region [mem 0xcbabb000-0xcbacdfff] (77824 bytes) [0.496535] PM: Registering ACPI NVS region [mem 0xcbb56000-0xcbb5dfff] (32768 bytes) [0.504380] PM: Registering ACPI NVS region [mem 0xcbb71000-0xcbff] (4780032 bytes) [0.513294] atomic64_test: passed for x86-64 platform with CX8 and with SSE [0.520272] pinctrl core: initialized pinctrl subsystem [0.525549] RTC time: 9:52:43, date: 10/22/14 [0.530096] NET: Registered protocol family 16 [0.539573] cpuidle: using governor menu [0.543583] ACPI: bus type PCI registered [0.547608] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [0.554133] PCI: MMCONFIG for domain [bus 00-ff] at [mem 0xe000-0xefff] (base 0xe000) [0.563457] PCI: MMCONFIG at [mem 0xe000-0xefff] reserved in E820 [0.570548] PCI: Using configuration type 1 for base access [0.582492] ACPI: Added _OSI(Module Device) [0.586683]
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On 10/27/14 at 03:29pm, Li, ZhenHua wrote: Hi Baoquan, I failed in testing this patchset for 3.18.0-rc1, this upstream 3.18.0-rc1 kernel cannot boot on my system, have not found out the reason. Could you please test this patchset on 3.17.0 to see whether it has these faults? Thanks Zhenhua Failed too on 3.17.0, check the log as below: [0.103751] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) [0.110285] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) [0.117549] Initializing cgroup subsys memory [0.121917] Initializing cgroup subsys devices [0.126367] Initializing cgroup subsys freezer [0.130817] Initializing cgroup subsys net_cls [0.135265] Initializing cgroup subsys blkio [0.139545] Initializing cgroup subsys perf_event [0.144254] Initializing cgroup subsys hugetlb [0.148741] CPU: Physical Processor ID: 0 [0.152751] CPU: Processor Core ID: 1 [0.156427] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [0.156427] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [0.180040] Freeing SMP alternatives memory: 24K (ade7a000 - ade8) [0.190787] ftrace: allocating 26881 entries in 106 pages [0.222955] dmar: Host address width 46 [0.226796] dmar: DRHD base: 0x00dfffc000 flags: 0x1 [0.232128] dmar: IOMMU 0: reg_base_addr dfffc000 ver 1:0 cap d2078c106f0462 ecap f020fe [0.240223] dmar: RMRR base: 0x00cba11000 end: 0x00cba27fff [0.246495] dmar: ATSR flags: 0x0 [0.249921] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 0 [0.255499] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 0 [0.261076] HPET id 0 under DRHD base 0xdfffc000 [0.265899] Enabled IRQ remapping in xapic mode [0.271030] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [0.287077] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz (fam: 06, model: 2d, stepping: 07) [0.296535] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, full-width counters, Broken BIOS detected, complain to your hardware vendor. [0.310427] [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is b0) [0.318087] Intel PMU driver. [0.321065] ... version:3 [0.325077] ... bit width: 48 [0.329180] ... generic registers: 8 [0.333198] ... value mask: [0.338516] ... max period: [0.343834] ... fixed-purpose events: 3 [0.347848] ... event mask: 000700ff [0.355607] x86: Booted up 1 node, 1 CPUs [0.359627] smpboot: Total of 1 processors activated (5586.06 BogoMIPS) [0.366281] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [0.377496] devtmpfs: initialized [0.386629] PM: Registering ACPI NVS region [mem 0xcb75-0xcb7dafff] (569344 bytes) [0.394583] PM: Registering ACPI NVS region [mem 0xcbaad000-0xcbaaefff] (8192 bytes) [0.402337] PM: Registering ACPI NVS region [mem 0xcbabb000-0xcbacdfff] (77824 bytes) [0.410169] PM: Registering ACPI NVS region [mem 0xcbb56000-0xcbb5dfff] (32768 bytes) [0.418005] PM: Registering ACPI NVS region [mem 0xcbb71000-0xcbff] (4780032 bytes) [0.427905] atomic64_test: passed for x86-64 platform with CX8 and with SSE [0.434883] pinctrl core: initialized pinctrl subsystem [0.440171] RTC time: 10:38:17, date: 10/27/14 [0.444783] NET: Registered protocol family 16 [0.449652] cpuidle: using governor menu [0.453820] ACPI: bus type PCI registered [0.457841] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [0.464406] PCI: MMCONFIG for domain [bus 00-ff] at [mem 0xe000-0xefff] (base 0xe000) [0.473718] PCI: MMCONFIG at [mem 0xe000-0xefff] reserved in E820 [0.481119] PCI: Using configuration type 1 for base access [0.489116] ACPI: Added _OSI(Module Device) [0.493313] ACPI: Added _OSI(Processor Device) [0.497768] ACPI: Added _OSI(3.0 _SCP Extensions) [0.502477] ACPI: Added _OSI(Processor Aggregator Device) [0.521054] ACPI: Executed 1 blocks of module-level executable AML code [0.653647] ACPI: Interpreter enabled [0.657334] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140724/hwxface-580) [0.10] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140724/hwxface-580) [0.675902] ACPI: (supports S0 S3 S4 S5) [0.679833] ACPI: Using IOAPIC for interrupt routing [0.684858] PCI: Using host bridge windows from ACPI; if necessary, use pci=nocrs and report a bug [0.695495] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [0.717663] ACPI: PCI Root Bridge [PCI0] (domain [bus 00-7f]) [0.723860] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [0.732282] acpi PNP0A08:00: _OSC: platform does not support [PCIeCapability] [0.739533] acpi PNP0A08:00: _OSC:
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On 10/22/14 at 10:22am, Li, Zhen-Hua wrote: > > Hi Baoquan, > I tested it on 3.17, it does not have these faults. There are little > differences between this version and Bill's last version. > > I will test it on 3.18.0-rc1+ on my system and let you know the result. > > And could you send me the result of "lspci -vvv " on your system? I have pasted them here. [~]$ lspci -vvv 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) (prog-if 20 [IO(X)-APIC]) Subsystem: Intel Corporation Xeon E5/Core i7 I/O APIC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 05) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me 00:16.2 IDE interface: Intel Corporation C600/X79 series chipset IDE-r Controller (rev 05) (prog-if 85 [Master SecO PriO]) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ata_generic 00:16.3 Serial controller: Intel Corporation C600/X79 series chipset KT Controller (rev 05) (prog-if 02 [16550]) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: serial 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O+ Mem+ BusMaster+
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Baoquan, I tested it on 3.17, it does not have these faults. There are little differences between this version and Bill's last version. I will test it on 3.18.0-rc1+ on my system and let you know the result. And could you send me the result of "lspci -vvv " on your system? Thanks Zhenhua > 在 2014年10月22日，18:05，"Baoquan He" 写道： > > Hi Zhenhua, > > I tested your latest patch on 3.18.0-rc1+, there are still some dmar > errors. I remember it worked well with Bill's original patchset. > > > 0console [earlya[0.00] allocate tes of page_cg 'a ong[ > 0.00] tsc: Fast TSC calibration using PIT > 0031] Calibrating delay loop (skipped), value calculated using timer > frequency.. 5586.77 BogoMIPS (lpj=2793386) > [0.010682] pid_max: default: 32768 minimum: 301 > [0.015317] ACPI: Core revision 20140828 > [0.044598] ACPI: All ACPI Tables successfully acquired > [0.126450] Security Framework initialized > [0.130569] SELinux: Initializing. > [0.135211] Dentry cache hash table entries: 2097152 (order: 12, > 16777216 bytes) > [0.145731] Inode-cache hash table entries: 1048576 (order: 11, > 8388608 bytes) > [0.154249] Mount-cache hash table entries: 32768 (order: 6, 262144 > bytes) > [0.161163] Mountpoint-cache hash table entries: 32768 (order: 6, > 262144 bytes) > [0.168731] Initializing cgroup subsys memory > [0.173110] Initializing cgroup subsys devices > [0.177570] Initializing cgroup subsys freezer > [0.182026] Initializing cgroup subsys net_cls > [0.186483] Initializing cgroup subsys blkio > [0.190763] Initializing cgroup subsys perf_event > [0.195479] Initializing cgroup subsys hugetlb > [0.199955] CPU: Physical Processor ID: 0 > [0.203972] CPU: Processor Core ID: 0 > [0.207649] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' > [0.207649] ENERGY_PERF_BIAS: View and update with > x86_energy_perf_policy(8) > [0.220704] mce: CPU supports 16 MCE banks > [0.224832] CPU0: Thermal monitoring enabled (TM1) > [0.229658] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 > [0.229658] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 > [0.241537] Freeing SMP alternatives memory: 24K (81e8 - > 81e86000) > [0.250740] ftrace: allocating 27051 entries in 106 pages > [0.268137] dmar: Host address width 46 > [0.271986] dmar: DRHD base: 0x00dfffc000 flags: 0x1 > [0.277314] dmar: IOMMU 0: reg_base_addr dfffc000 ver 1:0 cap > d2078c106f0462 ecap f020fe > [0.285423] dmar: RMRR base: 0x00cba11000 end: 0x00cba27fff > [0.291703] dmar: ATSR flags: 0x0 > [0.295122] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 0 > [0.300704] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 0 > [0.306281] HPET id 0 under DRHD base 0xdfffc000 > [0.311011] Enabled IRQ remapping in xapic mode > [0.316070] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [0.332096] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz > (fam: 06, model: 2d, stepping: 07) > [0.341495] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge > events, full-width counters, Intel PMU driver. > [0.352047] perf_event_intel: PEBS disabled due to CPU errata, please > upgrade microcode > [0.360060] ... version:3 > [0.364081] ... bit width: 48 > [0.368182] ... generic registers: 8 > [0.372196] ... value mask: > [0.377513] ... max period: > [0.382829] ... fixed-purpose events: 3 > [0.386842] ... event mask: 000700ff > [0.393368] x86: Booting SMP configuration: > [0.397563] node #0, CPUs: #1 > [0.414672] NMI watchdog: enabled on all CPUs, permanently consumes > one hw-PMU counter. > [0.422957] #2 #3 > [0.451320] x86: Booted up 1 node, 4 CPUs > [0.455539] smpboot: Total of 4 processors activated (22347.08 > BogoMIPS) > [0.466369] devtmpfs: initialized > [0.472993] PM: Registering ACPI NVS region [mem > 0xcb75-0xcb7dafff] (569344 bytes) > [0.480930] PM: Registering ACPI NVS region [mem > 0xcbaad000-0xcbaaefff] (8192 bytes) > [0.488689] PM: Registering ACPI NVS region [mem > 0xcbabb000-0xcbacdfff] (77824 bytes) > [0.496535] PM: Registering ACPI NVS region [mem > 0xcbb56000-0xcbb5dfff] (32768 bytes) > [0.504380] PM: Registering ACPI NVS region [mem > 0xcbb71000-0xcbff] (4780032 bytes) > [0.513294] atomic64_test: passed for x86-64 platform with CX8 and > with SSE > [0.520272] pinctrl core: initialized pinctrl subsystem > [0.525549] RTC time: 9:52:43, date: 10/22/14 > [0.530096] NET: Registered protocol family 16 > [0.539573] cpuidle: using governor menu > [0.543583] ACPI: bus type PCI registered > [0.547608] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [0.554133] PCI: MMCONFIG for domain [bus 00-ff] at [mem >
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Zhenhua, I tested your latest patch on 3.18.0-rc1+, there are still some dmar errors. I remember it worked well with Bill's original patchset. 0console [earlya[0.00] allocate tes of page_cg 'a ong[ 0.00] tsc: Fast TSC calibration using PIT 0031] Calibrating delay loop (skipped), value calculated using timer frequency.. 5586.77 BogoMIPS (lpj=2793386) [0.010682] pid_max: default: 32768 minimum: 301 [0.015317] ACPI: Core revision 20140828 [0.044598] ACPI: All ACPI Tables successfully acquired [0.126450] Security Framework initialized [0.130569] SELinux: Initializing. [0.135211] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) [0.145731] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) [0.154249] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.161163] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.168731] Initializing cgroup subsys memory [0.173110] Initializing cgroup subsys devices [0.177570] Initializing cgroup subsys freezer [0.182026] Initializing cgroup subsys net_cls [0.186483] Initializing cgroup subsys blkio [0.190763] Initializing cgroup subsys perf_event [0.195479] Initializing cgroup subsys hugetlb [0.199955] CPU: Physical Processor ID: 0 [0.203972] CPU: Processor Core ID: 0 [0.207649] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [0.207649] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [0.220704] mce: CPU supports 16 MCE banks [0.224832] CPU0: Thermal monitoring enabled (TM1) [0.229658] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [0.229658] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [0.241537] Freeing SMP alternatives memory: 24K (81e8 - 81e86000) [0.250740] ftrace: allocating 27051 entries in 106 pages [0.268137] dmar: Host address width 46 [0.271986] dmar: DRHD base: 0x00dfffc000 flags: 0x1 [0.277314] dmar: IOMMU 0: reg_base_addr dfffc000 ver 1:0 cap d2078c106f0462 ecap f020fe [0.285423] dmar: RMRR base: 0x00cba11000 end: 0x00cba27fff [0.291703] dmar: ATSR flags: 0x0 [0.295122] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 0 [0.300704] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 0 [0.306281] HPET id 0 under DRHD base 0xdfffc000 [0.311011] Enabled IRQ remapping in xapic mode [0.316070] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [0.332096] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz (fam: 06, model: 2d, stepping: 07) [0.341495] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, full-width counters, Intel PMU driver. [0.352047] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode [0.360060] ... version:3 [0.364081] ... bit width: 48 [0.368182] ... generic registers: 8 [0.372196] ... value mask: [0.377513] ... max period: [0.382829] ... fixed-purpose events: 3 [0.386842] ... event mask: 000700ff [0.393368] x86: Booting SMP configuration: [0.397563] node #0, CPUs: #1 [0.414672] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [0.422957] #2 #3 [0.451320] x86: Booted up 1 node, 4 CPUs [0.455539] smpboot: Total of 4 processors activated (22347.08 BogoMIPS) [0.466369] devtmpfs: initialized [0.472993] PM: Registering ACPI NVS region [mem 0xcb75-0xcb7dafff] (569344 bytes) [0.480930] PM: Registering ACPI NVS region [mem 0xcbaad000-0xcbaaefff] (8192 bytes) [0.488689] PM: Registering ACPI NVS region [mem 0xcbabb000-0xcbacdfff] (77824 bytes) [0.496535] PM: Registering ACPI NVS region [mem 0xcbb56000-0xcbb5dfff] (32768 bytes) [0.504380] PM: Registering ACPI NVS region [mem 0xcbb71000-0xcbff] (4780032 bytes) [0.513294] atomic64_test: passed for x86-64 platform with CX8 and with SSE [0.520272] pinctrl core: initialized pinctrl subsystem [0.525549] RTC time: 9:52:43, date: 10/22/14 [0.530096] NET: Registered protocol family 16 [0.539573] cpuidle: using governor menu [0.543583] ACPI: bus type PCI registered [0.547608] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [0.554133] PCI: MMCONFIG for domain [bus 00-ff] at [mem 0xe000-0xefff] (base 0xe000) [0.563457] PCI: MMCONFIG at [mem 0xe000-0xefff] reserved in E820 [0.570548] PCI: Using configuration type 1 for base access [0.582492] ACPI: Added _OSI(Module Device) [0.586683] ACPI: Added _OSI(Processor Device) [0.591140] ACPI: Added _OSI(3.0 _SCP Extensions) [0.595849] ACPI: Added _OSI(Processor Aggregator Device) [0.608829] ACPI: Executed 1 blocks of module-level executable AML code [0.670857] ACPI: Interpreter enabled [0.674537] ACPI Exception:
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Zhenhua, I tested your latest patch on 3.18.0-rc1+, there are still some dmar errors. I remember it worked well with Bill's original patchset. 0console [earlya[0.00] allocate tes of page_cg 'a ong[ 0.00] tsc: Fast TSC calibration using PIT 0031] Calibrating delay loop (skipped), value calculated using timer frequency.. 5586.77 BogoMIPS (lpj=2793386) [0.010682] pid_max: default: 32768 minimum: 301 [0.015317] ACPI: Core revision 20140828 [0.044598] ACPI: All ACPI Tables successfully acquired [0.126450] Security Framework initialized [0.130569] SELinux: Initializing. [0.135211] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) [0.145731] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) [0.154249] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.161163] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.168731] Initializing cgroup subsys memory [0.173110] Initializing cgroup subsys devices [0.177570] Initializing cgroup subsys freezer [0.182026] Initializing cgroup subsys net_cls [0.186483] Initializing cgroup subsys blkio [0.190763] Initializing cgroup subsys perf_event [0.195479] Initializing cgroup subsys hugetlb [0.199955] CPU: Physical Processor ID: 0 [0.203972] CPU: Processor Core ID: 0 [0.207649] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [0.207649] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [0.220704] mce: CPU supports 16 MCE banks [0.224832] CPU0: Thermal monitoring enabled (TM1) [0.229658] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [0.229658] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [0.241537] Freeing SMP alternatives memory: 24K (81e8 - 81e86000) [0.250740] ftrace: allocating 27051 entries in 106 pages [0.268137] dmar: Host address width 46 [0.271986] dmar: DRHD base: 0x00dfffc000 flags: 0x1 [0.277314] dmar: IOMMU 0: reg_base_addr dfffc000 ver 1:0 cap d2078c106f0462 ecap f020fe [0.285423] dmar: RMRR base: 0x00cba11000 end: 0x00cba27fff [0.291703] dmar: ATSR flags: 0x0 [0.295122] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 0 [0.300704] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 0 [0.306281] HPET id 0 under DRHD base 0xdfffc000 [0.311011] Enabled IRQ remapping in xapic mode [0.316070] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [0.332096] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz (fam: 06, model: 2d, stepping: 07) [0.341495] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, full-width counters, Intel PMU driver. [0.352047] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode [0.360060] ... version:3 [0.364081] ... bit width: 48 [0.368182] ... generic registers: 8 [0.372196] ... value mask: [0.377513] ... max period: [0.382829] ... fixed-purpose events: 3 [0.386842] ... event mask: 000700ff [0.393368] x86: Booting SMP configuration: [0.397563] node #0, CPUs: #1 [0.414672] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [0.422957] #2 #3 [0.451320] x86: Booted up 1 node, 4 CPUs [0.455539] smpboot: Total of 4 processors activated (22347.08 BogoMIPS) [0.466369] devtmpfs: initialized [0.472993] PM: Registering ACPI NVS region [mem 0xcb75-0xcb7dafff] (569344 bytes) [0.480930] PM: Registering ACPI NVS region [mem 0xcbaad000-0xcbaaefff] (8192 bytes) [0.488689] PM: Registering ACPI NVS region [mem 0xcbabb000-0xcbacdfff] (77824 bytes) [0.496535] PM: Registering ACPI NVS region [mem 0xcbb56000-0xcbb5dfff] (32768 bytes) [0.504380] PM: Registering ACPI NVS region [mem 0xcbb71000-0xcbff] (4780032 bytes) [0.513294] atomic64_test: passed for x86-64 platform with CX8 and with SSE [0.520272] pinctrl core: initialized pinctrl subsystem [0.525549] RTC time: 9:52:43, date: 10/22/14 [0.530096] NET: Registered protocol family 16 [0.539573] cpuidle: using governor menu [0.543583] ACPI: bus type PCI registered [0.547608] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [0.554133] PCI: MMCONFIG for domain [bus 00-ff] at [mem 0xe000-0xefff] (base 0xe000) [0.563457] PCI: MMCONFIG at [mem 0xe000-0xefff] reserved in E820 [0.570548] PCI: Using configuration type 1 for base access [0.582492] ACPI: Added _OSI(Module Device) [0.586683] ACPI: Added _OSI(Processor Device) [0.591140] ACPI: Added _OSI(3.0 _SCP Extensions) [0.595849] ACPI: Added _OSI(Processor Aggregator Device) [0.608829] ACPI: Executed 1 blocks of module-level executable AML code [0.670857] ACPI: Interpreter enabled [0.674537] ACPI Exception:
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Baoquan, I tested it on 3.17, it does not have these faults. There are little differences between this version and Bill's last version. I will test it on 3.18.0-rc1+ on my system and let you know the result. And could you send me the result of lspci -vvv on your system? Thanks Zhenhua 在 2014年10月22日，18:05，Baoquan He b...@redhat.com 写道： Hi Zhenhua, I tested your latest patch on 3.18.0-rc1+, there are still some dmar errors. I remember it worked well with Bill's original patchset. 0console [earlya[0.00] allocate tes of page_cg 'a ong[ 0.00] tsc: Fast TSC calibration using PIT 0031] Calibrating delay loop (skipped), value calculated using timer frequency.. 5586.77 BogoMIPS (lpj=2793386) [0.010682] pid_max: default: 32768 minimum: 301 [0.015317] ACPI: Core revision 20140828 [0.044598] ACPI: All ACPI Tables successfully acquired [0.126450] Security Framework initialized [0.130569] SELinux: Initializing. [0.135211] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes) [0.145731] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes) [0.154249] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.161163] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.168731] Initializing cgroup subsys memory [0.173110] Initializing cgroup subsys devices [0.177570] Initializing cgroup subsys freezer [0.182026] Initializing cgroup subsys net_cls [0.186483] Initializing cgroup subsys blkio [0.190763] Initializing cgroup subsys perf_event [0.195479] Initializing cgroup subsys hugetlb [0.199955] CPU: Physical Processor ID: 0 [0.203972] CPU: Processor Core ID: 0 [0.207649] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [0.207649] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [0.220704] mce: CPU supports 16 MCE banks [0.224832] CPU0: Thermal monitoring enabled (TM1) [0.229658] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [0.229658] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [0.241537] Freeing SMP alternatives memory: 24K (81e8 - 81e86000) [0.250740] ftrace: allocating 27051 entries in 106 pages [0.268137] dmar: Host address width 46 [0.271986] dmar: DRHD base: 0x00dfffc000 flags: 0x1 [0.277314] dmar: IOMMU 0: reg_base_addr dfffc000 ver 1:0 cap d2078c106f0462 ecap f020fe [0.285423] dmar: RMRR base: 0x00cba11000 end: 0x00cba27fff [0.291703] dmar: ATSR flags: 0x0 [0.295122] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 0 [0.300704] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 0 [0.306281] HPET id 0 under DRHD base 0xdfffc000 [0.311011] Enabled IRQ remapping in xapic mode [0.316070] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [0.332096] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1603 0 @ 2.80GHz (fam: 06, model: 2d, stepping: 07) [0.341495] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, full-width counters, Intel PMU driver. [0.352047] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode [0.360060] ... version:3 [0.364081] ... bit width: 48 [0.368182] ... generic registers: 8 [0.372196] ... value mask: [0.377513] ... max period: [0.382829] ... fixed-purpose events: 3 [0.386842] ... event mask: 000700ff [0.393368] x86: Booting SMP configuration: [0.397563] node #0, CPUs: #1 [0.414672] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [0.422957] #2 #3 [0.451320] x86: Booted up 1 node, 4 CPUs [0.455539] smpboot: Total of 4 processors activated (22347.08 BogoMIPS) [0.466369] devtmpfs: initialized [0.472993] PM: Registering ACPI NVS region [mem 0xcb75-0xcb7dafff] (569344 bytes) [0.480930] PM: Registering ACPI NVS region [mem 0xcbaad000-0xcbaaefff] (8192 bytes) [0.488689] PM: Registering ACPI NVS region [mem 0xcbabb000-0xcbacdfff] (77824 bytes) [0.496535] PM: Registering ACPI NVS region [mem 0xcbb56000-0xcbb5dfff] (32768 bytes) [0.504380] PM: Registering ACPI NVS region [mem 0xcbb71000-0xcbff] (4780032 bytes) [0.513294] atomic64_test: passed for x86-64 platform with CX8 and with SSE [0.520272] pinctrl core: initialized pinctrl subsystem [0.525549] RTC time: 9:52:43, date: 10/22/14 [0.530096] NET: Registered protocol family 16 [0.539573] cpuidle: using governor menu [0.543583] ACPI: bus type PCI registered [0.547608] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [0.554133] PCI: MMCONFIG for domain [bus 00-ff] at [mem 0xe000-0xefff] (base 0xe000) [0.563457] PCI: MMCONFIG at [mem
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
On 10/22/14 at 10:22am, Li, Zhen-Hua wrote: Hi Baoquan, I tested it on 3.17, it does not have these faults. There are little differences between this version and Bill's last version. I will test it on 3.18.0-rc1+ on my system and let you know the result. And could you send me the result of lspci -vvv on your system? I have pasted them here. [~]$ lspci -vvv 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 0 Capabilities: access denied 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: f000-0fff Memory behind bridge: fff0-000f Prefetchable memory behind bridge: fff0-000f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: d600-d70f Prefetchable memory behind bridge: d800-ddff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: f000-0fff Memory behind bridge: fff0-000f Prefetchable memory behind bridge: fff0-000f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Capabilities: access denied 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07) Subsystem: Hewlett-Packard Company Device 1589 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Capabilities: access denied 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) (prog-if 20 [IO(X)-APIC]) Subsystem: Intel Corporation Xeon E5/Core i7 I/O APIC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Region 0: Memory at d7346000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied 00:11.0 PCI bridge: Intel Corporation
