* [Patch Part3 V2 17/21] iommu/vt-d: search _DSM method for DMAR hotplug
From: Jiang Liu @ 2014-05-06 7:05 UTC (permalink / raw)
To: Joerg Roedel, David Woodhouse, Yinghai Lu, Bjorn Helgaas,
Dan Williams, Vinod Koul, Rafael J . Wysocki
Cc: Jiang Liu, Ashok Raj, Yijing Wang, Tony Luck, iommu, linux-pci,
linux-hotplug, linux-kernel, dmaengine
In-Reply-To: <1399359932-28972-1-git-send-email-jiang.liu@linux.intel.com>
According to Intel VT-d specification, _DSM method to support DMAR
hotplug should exist directly under corresponding ACPI object
representing PCI host bridge. But some BIOSes doesn't conform to
this, so search for _DSM method in the subtree starting from the
ACPI object representing the PCI host bridge.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
drivers/iommu/dmar.c | 35 +++++++++++++++++++++++++++++++----
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 2006e1cd8c0f..a1b436b105a0 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1921,21 +1921,48 @@ static int dmar_hotplug_remove(acpi_handle handle)
return ret;
}
-static int dmar_device_hotplug(acpi_handle handle, bool insert)
+static acpi_status dmar_get_dsm_handle(acpi_handle handle, u32 lvl,
+ void *context, void **retval)
+{
+ acpi_handle *phdl = retval;
+
+ if (dmar_detect_dsm(handle, DMAR_DSM_FUNC_DRHD)) {
+ *phdl = handle;
+ return AE_CTRL_TERMINATE;
+ }
+
+ return AE_OK;
+}
+
+int dmar_device_hotplug(acpi_handle handle, bool insert)
{
int ret;
+ acpi_handle tmp = NULL;
+ acpi_status status;
if (!dmar_in_use())
return 0;
- if (!dmar_detect_dsm(handle, DMAR_DSM_FUNC_DRHD))
+ if (dmar_detect_dsm(handle, DMAR_DSM_FUNC_DRHD)) {
+ tmp = handle;
+ } else {
+ status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
+ ACPI_UINT32_MAX,
+ dmar_get_dsm_handle,
+ NULL, NULL, &tmp);
+ if (ACPI_FAILURE(status)) {
+ pr_warn("Failed to locate _DSM method.\n");
+ return -ENXIO;
+ }
+ }
+ if (tmp = NULL)
return 0;
down_write(&dmar_global_lock);
if (insert)
- ret = dmar_hotplug_insert(handle);
+ ret = dmar_hotplug_insert(tmp);
else
- ret = dmar_hotplug_remove(handle);
+ ret = dmar_hotplug_remove(tmp);
up_write(&dmar_global_lock);
return ret;
--
1.7.10.4
^ permalink raw reply related
* [Patch Part3 V2 18/21] iommu/vt-d: enhance intel_irq_remapping driver to support DMAR unit hotplug
From: Jiang Liu @ 2014-05-06 7:05 UTC (permalink / raw)
To: Joerg Roedel, David Woodhouse, Yinghai Lu, Bjorn Helgaas,
Dan Williams, Vinod Koul, Rafael J . Wysocki
Cc: Jiang Liu, Ashok Raj, Yijing Wang, Tony Luck, iommu, linux-pci,
linux-hotplug, linux-kernel, dmaengine
In-Reply-To: <1399359932-28972-1-git-send-email-jiang.liu@linux.intel.com>
Implement required callback functions for intel_irq_remapping driver
to support DMAR unit hotplug.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
drivers/iommu/intel_irq_remapping.c | 222 ++++++++++++++++++++++++++---------
1 file changed, 169 insertions(+), 53 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
index aa309a8e4d3a..9f1c86566452 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -36,7 +36,6 @@ struct hpet_scope {
static struct ioapic_scope ir_ioapic[MAX_IO_APICS];
static struct hpet_scope ir_hpet[MAX_HPET_TBS];
-static int ir_ioapic_num, ir_hpet_num;
/*
* Lock ordering:
@@ -320,7 +319,7 @@ static int set_ioapic_sid(struct irte *irte, int apic)
down_read(&dmar_global_lock);
for (i = 0; i < MAX_IO_APICS; i++) {
- if (ir_ioapic[i].id = apic) {
+ if (ir_ioapic[i].iommu && ir_ioapic[i].id = apic) {
sid = (ir_ioapic[i].bus << 8) | ir_ioapic[i].devfn;
break;
}
@@ -347,7 +346,7 @@ static int set_hpet_sid(struct irte *irte, u8 id)
down_read(&dmar_global_lock);
for (i = 0; i < MAX_HPET_TBS; i++) {
- if (ir_hpet[i].id = id) {
+ if (ir_hpet[i].iommu && ir_hpet[i].id = id) {
sid = (ir_hpet[i].bus << 8) | ir_hpet[i].devfn;
break;
}
@@ -446,17 +445,17 @@ static void iommu_set_irq_remapping(struct intel_iommu *iommu, int mode)
raw_spin_unlock_irqrestore(&iommu->register_lock, flags);
}
-
-static int intel_setup_irq_remapping(struct intel_iommu *iommu, int mode)
+static int intel_setup_irq_remapping(struct intel_iommu *iommu)
{
struct ir_table *ir_table;
struct page *pages;
unsigned long *bitmap;
- ir_table = iommu->ir_table = kzalloc(sizeof(struct ir_table),
- GFP_ATOMIC);
+ if (iommu->ir_table)
+ return 0;
- if (!iommu->ir_table)
+ ir_table = kzalloc(sizeof(struct ir_table), GFP_ATOMIC);
+ if (!ir_table)
return -ENOMEM;
pages = alloc_pages_node(iommu->node, GFP_ATOMIC | __GFP_ZERO,
@@ -465,7 +464,7 @@ static int intel_setup_irq_remapping(struct intel_iommu *iommu, int mode)
if (!pages) {
pr_err("IR%d: failed to allocate pages of order %d\n",
iommu->seq_id, INTR_REMAP_PAGE_ORDER);
- kfree(iommu->ir_table);
+ kfree(ir_table);
return -ENOMEM;
}
@@ -480,11 +479,22 @@ static int intel_setup_irq_remapping(struct intel_iommu *iommu, int mode)
ir_table->base = page_address(pages);
ir_table->bitmap = bitmap;
+ iommu->ir_table = ir_table;
- iommu_set_irq_remapping(iommu, mode);
return 0;
}
+static void intel_teardown_irq_remapping(struct intel_iommu *iommu)
+{
+ if (iommu && iommu->ir_table) {
+ free_pages((unsigned long)iommu->ir_table->base,
+ INTR_REMAP_PAGE_ORDER);
+ kfree(iommu->ir_table->bitmap);
+ kfree(iommu->ir_table);
+ iommu->ir_table = NULL;
+ }
+}
+
/*
* Disable Interrupt Remapping.
*/
@@ -639,9 +649,10 @@ static int __init intel_enable_irq_remapping(void)
if (!ecap_ir_support(iommu->ecap))
continue;
- if (intel_setup_irq_remapping(iommu, eim))
+ if (intel_setup_irq_remapping(iommu))
goto error;
+ iommu_set_irq_remapping(iommu, eim);
setup = 1;
}
@@ -672,12 +683,13 @@ error:
return -1;
}
-static void ir_parse_one_hpet_scope(struct acpi_dmar_device_scope *scope,
- struct intel_iommu *iommu)
+static int ir_parse_one_hpet_scope(struct acpi_dmar_device_scope *scope,
+ struct intel_iommu *iommu,
+ struct acpi_dmar_hardware_unit *drhd)
{
struct acpi_dmar_pci_path *path;
u8 bus;
- int count;
+ int count, free = -1;
bus = scope->bus;
path = (struct acpi_dmar_pci_path *)(scope + 1);
@@ -693,19 +705,36 @@ static void ir_parse_one_hpet_scope(struct acpi_dmar_device_scope *scope,
PCI_SECONDARY_BUS);
path++;
}
- ir_hpet[ir_hpet_num].bus = bus;
- ir_hpet[ir_hpet_num].devfn = PCI_DEVFN(path->device, path->function);
- ir_hpet[ir_hpet_num].iommu = iommu;
- ir_hpet[ir_hpet_num].id = scope->enumeration_id;
- ir_hpet_num++;
+
+ for (count = 0; count < MAX_HPET_TBS; count++) {
+ if (ir_hpet[count].iommu = iommu &&
+ ir_hpet[count].id = scope->enumeration_id)
+ return 0;
+ else if (ir_hpet[count].iommu = NULL && free = -1)
+ free = count;
+ }
+ if (free = -1) {
+ pr_warn("Exceeded Max HPET blocks\n");
+ return -ENOSPC;
+ }
+
+ ir_hpet[free].iommu = iommu;
+ ir_hpet[free].id = scope->enumeration_id;
+ ir_hpet[free].bus = bus;
+ ir_hpet[free].devfn = PCI_DEVFN(path->device, path->function);
+ pr_info("HPET id %d under DRHD base 0x%Lx\n",
+ scope->enumeration_id, drhd->address);
+
+ return 0;
}
-static void ir_parse_one_ioapic_scope(struct acpi_dmar_device_scope *scope,
- struct intel_iommu *iommu)
+static int ir_parse_one_ioapic_scope(struct acpi_dmar_device_scope *scope,
+ struct intel_iommu *iommu,
+ struct acpi_dmar_hardware_unit *drhd)
{
struct acpi_dmar_pci_path *path;
u8 bus;
- int count;
+ int count, free = -1;
bus = scope->bus;
path = (struct acpi_dmar_pci_path *)(scope + 1);
@@ -722,54 +751,63 @@ static void ir_parse_one_ioapic_scope(struct acpi_dmar_device_scope *scope,
path++;
}
- ir_ioapic[ir_ioapic_num].bus = bus;
- ir_ioapic[ir_ioapic_num].devfn = PCI_DEVFN(path->device, path->function);
- ir_ioapic[ir_ioapic_num].iommu = iommu;
- ir_ioapic[ir_ioapic_num].id = scope->enumeration_id;
- ir_ioapic_num++;
+ for (count = 0; count < MAX_IO_APICS; count++) {
+ if (ir_ioapic[count].iommu = iommu &&
+ ir_ioapic[count].id = scope->enumeration_id)
+ return 0;
+ else if (ir_ioapic[count].iommu = NULL && free = -1)
+ free = count;
+ }
+ if (free = -1) {
+ pr_warn("Exceeded Max IO APICS\n");
+ return -ENOSPC;
+ }
+
+ ir_ioapic[free].bus = bus;
+ ir_ioapic[free].devfn = PCI_DEVFN(path->device, path->function);
+ ir_ioapic[free].iommu = iommu;
+ ir_ioapic[free].id = scope->enumeration_id;
+ pr_info("IOAPIC id %d under DRHD base 0x%Lx IOMMU %d\n",
+ scope->enumeration_id, drhd->address, iommu->seq_id);
+
+ return 0;
}
static int ir_parse_ioapic_hpet_scope(struct acpi_dmar_header *header,
struct intel_iommu *iommu)
{
+ int ret = 0;
struct acpi_dmar_hardware_unit *drhd;
struct acpi_dmar_device_scope *scope;
void *start, *end;
drhd = (struct acpi_dmar_hardware_unit *)header;
-
start = (void *)(drhd + 1);
end = ((void *)drhd) + header->length;
- while (start < end) {
+ while (start < end && ret = 0) {
scope = start;
- if (scope->entry_type = ACPI_DMAR_SCOPE_TYPE_IOAPIC) {
- if (ir_ioapic_num = MAX_IO_APICS) {
- printk(KERN_WARNING "Exceeded Max IO APICS\n");
- return -1;
- }
-
- printk(KERN_INFO "IOAPIC id %d under DRHD base "
- " 0x%Lx IOMMU %d\n", scope->enumeration_id,
- drhd->address, iommu->seq_id);
+ if (scope->entry_type = ACPI_DMAR_SCOPE_TYPE_IOAPIC)
+ ret = ir_parse_one_ioapic_scope(scope, iommu, drhd);
+ else if (scope->entry_type = ACPI_DMAR_SCOPE_TYPE_HPET)
+ ret = ir_parse_one_hpet_scope(scope, iommu, drhd);
+ start += scope->length;
+ }
- ir_parse_one_ioapic_scope(scope, iommu);
- } else if (scope->entry_type = ACPI_DMAR_SCOPE_TYPE_HPET) {
- if (ir_hpet_num = MAX_HPET_TBS) {
- printk(KERN_WARNING "Exceeded Max HPET blocks\n");
- return -1;
- }
+ return ret;
+}
- printk(KERN_INFO "HPET id %d under DRHD base"
- " 0x%Lx\n", scope->enumeration_id,
- drhd->address);
+static void ir_remove_ioapic_hpet_scope(struct intel_iommu *iommu)
+{
+ int i;
- ir_parse_one_hpet_scope(scope, iommu);
- }
- start += scope->length;
- }
+ for (i = 0; i < MAX_HPET_TBS; i++)
+ if (ir_hpet[i].iommu = iommu)
+ ir_hpet[i].iommu = NULL;
- return 0;
+ for (i = 0; i < MAX_IO_APICS; i++)
+ if (ir_ioapic[i].iommu = iommu)
+ ir_ioapic[i].iommu = NULL;
}
/*
@@ -1145,7 +1183,85 @@ struct irq_remap_ops intel_irq_remap_ops = {
.setup_hpet_msi = intel_setup_hpet_msi,
};
+/*
+ * Support of Interrupt Remapping Unit Hotplug
+ */
+static int dmar_ir_add(struct dmar_drhd_unit *dmaru, struct intel_iommu *iommu)
+{
+ int ret;
+ int eim = x2apic_enabled();
+
+ if (eim && !ecap_eim_support(iommu->ecap)) {
+ pr_info("DRHD %Lx: EIM not supported by DRHD, ecap %Lx\n",
+ iommu->reg_phys, iommu->ecap);
+ return -ENODEV;
+ }
+
+ if (ir_parse_ioapic_hpet_scope(dmaru->hdr, iommu)) {
+ pr_warn("DRHD %Lx: failed to parse managed IOAPIC/HPET\n",
+ iommu->reg_phys);
+ return -ENODEV;
+ }
+
+ /* TODO: check all IOAPICs are covered by IOMMU */
+
+ /* Setup Interrupt-remapping now. */
+ ret = intel_setup_irq_remapping(iommu);
+ if (ret) {
+ pr_err("DRHD %Lx: failed to allocate resource\n",
+ iommu->reg_phys);
+ ir_remove_ioapic_hpet_scope(iommu);
+ return ret;
+ }
+
+ if (!iommu->qi) {
+ /* Clear previous faults. */
+ dmar_fault(-1, iommu);
+ iommu_disable_irq_remapping(iommu);
+ dmar_disable_qi(iommu);
+ }
+
+ /* Enable queued invalidation */
+ ret = dmar_enable_qi(iommu);
+ if (!ret) {
+ iommu_set_irq_remapping(iommu, eim);
+ } else {
+ pr_err("DRHD %Lx: failed to enable queued invalidation, ecap %Lx, ret %d\n",
+ iommu->reg_phys, iommu->ecap, ret);
+ intel_teardown_irq_remapping(iommu);
+ ir_remove_ioapic_hpet_scope(iommu);
+ }
+
+ return ret;
+}
+
int dmar_ir_hotplug(struct dmar_drhd_unit *dmaru, bool insert)
{
- return irq_remapping_enabled ? -ENOSYS : 0;
+ int ret = 0;
+ struct intel_iommu *iommu = dmaru->iommu;
+
+ if (!irq_remapping_enabled)
+ return 0;
+ if (iommu = NULL)
+ return -EINVAL;
+ if (!ecap_ir_support(iommu->ecap))
+ return 0;
+
+ if (insert) {
+ if (!iommu->ir_table)
+ ret = dmar_ir_add(dmaru, iommu);
+ } else {
+ if (iommu->ir_table) {
+ if (!bitmap_empty(iommu->ir_table->bitmap,
+ INTR_REMAP_TABLE_ENTRIES)) {
+ ret = -EBUSY;
+ } else {
+ iommu_disable_irq_remapping(iommu);
+ intel_teardown_irq_remapping(iommu);
+ ir_remove_ioapic_hpet_scope(iommu);
+ }
+ }
+ }
+
+ return ret;
}
--
1.7.10.4
^ permalink raw reply related
* [Patch Part3 V2 19/21] iommu/vt-d: enhance error recovery in function intel_enable_irq_remapping()
From: Jiang Liu @ 2014-05-06 7:05 UTC (permalink / raw)
To: Joerg Roedel, David Woodhouse, Yinghai Lu, Bjorn Helgaas,
Dan Williams, Vinod Koul, Rafael J . Wysocki
Cc: Jiang Liu, Ashok Raj, Yijing Wang, Tony Luck, iommu, linux-pci,
linux-hotplug, linux-kernel, dmaengine
In-Reply-To: <1399359932-28972-1-git-send-email-jiang.liu@linux.intel.com>
Enhance error recovery in function intel_enable_irq_remapping()
by tearing down all created data structures.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
drivers/iommu/intel_irq_remapping.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
index 9f1c86566452..f65b68d3de10 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -673,9 +673,11 @@ static int __init intel_enable_irq_remapping(void)
return eim ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
error:
- /*
- * handle error condition gracefully here!
- */
+ for_each_iommu(iommu, drhd)
+ if (ecap_ir_support(iommu->ecap)) {
+ iommu_disable_irq_remapping(iommu);
+ intel_teardown_irq_remapping(iommu);
+ }
if (x2apic_present)
pr_warn("Failed to enable irq remapping. You are vulnerable to irq-injection attacks.\n");
--
1.7.10.4
^ permalink raw reply related
* [Patch Part3 V2 20/21] iommu/vt-d: enhance intel-iommu driver to support DMAR unit hotplug
From: Jiang Liu @ 2014-05-06 7:05 UTC (permalink / raw)
To: Joerg Roedel, David Woodhouse, Yinghai Lu, Bjorn Helgaas,
Dan Williams, Vinod Koul, Rafael J . Wysocki
Cc: Jiang Liu, Ashok Raj, Yijing Wang, Tony Luck, iommu, linux-pci,
linux-hotplug, linux-kernel, dmaengine
In-Reply-To: <1399359932-28972-1-git-send-email-jiang.liu@linux.intel.com>
Implement required callback functions for intel-iommu driver
to support DMAR unit hotplug.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
drivers/iommu/intel-iommu.c | 206 +++++++++++++++++++++++++++++++------------
1 file changed, 151 insertions(+), 55 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index f8db3788d08a..fabafb7a0c9a 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1127,8 +1127,11 @@ static int iommu_alloc_root_entry(struct intel_iommu *iommu)
unsigned long flags;
root = (struct root_entry *)alloc_pgtable_page(iommu->node);
- if (!root)
+ if (!root) {
+ pr_err("IOMMU: allocating root entry for %s failed\n",
+ iommu->name);
return -ENOMEM;
+ }
__iommu_flush_cache(iommu, root, ROOT_SIZE);
@@ -1468,7 +1471,7 @@ static int iommu_init_domains(struct intel_iommu *iommu)
return 0;
}
-static void free_dmar_iommu(struct intel_iommu *iommu)
+static void disable_dmar_iommu(struct intel_iommu *iommu)
{
struct dmar_domain *domain;
int i;
@@ -1492,11 +1495,16 @@ static void free_dmar_iommu(struct intel_iommu *iommu)
if (iommu->gcmd & DMA_GCMD_TE)
iommu_disable_translation(iommu);
+}
- kfree(iommu->domains);
- kfree(iommu->domain_ids);
- iommu->domains = NULL;
- iommu->domain_ids = NULL;
+static void free_dmar_iommu(struct intel_iommu *iommu)
+{
+ if ((iommu->domains) && (iommu->domain_ids)) {
+ kfree(iommu->domains);
+ kfree(iommu->domain_ids);
+ iommu->domains = NULL;
+ iommu->domain_ids = NULL;
+ }
g_iommus[iommu->seq_id] = NULL;
@@ -2692,6 +2700,41 @@ static int __init iommu_prepare_static_identity_mapping(int hw)
return 0;
}
+static void intel_iommu_init_qi(struct intel_iommu *iommu)
+{
+ /*
+ * Start from the sane iommu hardware state.
+ * If the queued invalidation is already initialized by us
+ * (for example, while enabling interrupt-remapping) then
+ * we got the things already rolling from a sane state.
+ */
+ if (!iommu->qi) {
+ /*
+ * Clear any previous faults.
+ */
+ dmar_fault(-1, iommu);
+ /*
+ * Disable queued invalidation if supported and already enabled
+ * before OS handover.
+ */
+ dmar_disable_qi(iommu);
+ }
+
+ if (dmar_enable_qi(iommu)) {
+ /*
+ * Queued Invalidate not enabled, use Register Based Invalidate
+ */
+ iommu->flush.flush_context = __iommu_flush_context;
+ iommu->flush.flush_iotlb = __iommu_flush_iotlb;
+ pr_info("IOMMU: %s using Register based invalidation\n",
+ iommu->name);
+ } else {
+ iommu->flush.flush_context = qi_flush_context;
+ iommu->flush.flush_iotlb = qi_flush_iotlb;
+ pr_info("IOMMU: %s using Queued invalidation\n", iommu->name);
+ }
+}
+
static int __init init_dmars(void)
{
struct dmar_drhd_unit *drhd;
@@ -2720,6 +2763,10 @@ static int __init init_dmars(void)
DMAR_UNITS_SUPPORTED);
}
+ /* Preallocate enough resources for IOMMU hot-addition */
+ if (g_num_of_iommus < DMAR_UNITS_SUPPORTED)
+ g_num_of_iommus = DMAR_UNITS_SUPPORTED;
+
g_iommus = kcalloc(g_num_of_iommus, sizeof(struct intel_iommu *),
GFP_KERNEL);
if (!g_iommus) {
@@ -2748,58 +2795,14 @@ static int __init init_dmars(void)
* among all IOMMU's. Need to Split it later.
*/
ret = iommu_alloc_root_entry(iommu);
- if (ret) {
- printk(KERN_ERR "IOMMU: allocate root entry failed\n");
+ if (ret)
goto free_iommu;
- }
if (!ecap_pass_through(iommu->ecap))
hw_pass_through = 0;
}
- /*
- * Start from the sane iommu hardware state.
- */
- for_each_active_iommu(iommu, drhd) {
- /*
- * If the queued invalidation is already initialized by us
- * (for example, while enabling interrupt-remapping) then
- * we got the things already rolling from a sane state.
- */
- if (iommu->qi)
- continue;
-
- /*
- * Clear any previous faults.
- */
- dmar_fault(-1, iommu);
- /*
- * Disable queued invalidation if supported and already enabled
- * before OS handover.
- */
- dmar_disable_qi(iommu);
- }
-
- for_each_active_iommu(iommu, drhd) {
- if (dmar_enable_qi(iommu)) {
- /*
- * Queued Invalidate not enabled, use Register Based
- * Invalidate
- */
- iommu->flush.flush_context = __iommu_flush_context;
- iommu->flush.flush_iotlb = __iommu_flush_iotlb;
- printk(KERN_INFO "IOMMU %d 0x%Lx: using Register based "
- "invalidation\n",
- iommu->seq_id,
- (unsigned long long)drhd->reg_base_addr);
- } else {
- iommu->flush.flush_context = qi_flush_context;
- iommu->flush.flush_iotlb = qi_flush_iotlb;
- printk(KERN_INFO "IOMMU %d 0x%Lx: using Queued "
- "invalidation\n",
- iommu->seq_id,
- (unsigned long long)drhd->reg_base_addr);
- }
- }
+ for_each_active_iommu(iommu, drhd)
+ intel_iommu_init_qi(iommu);
if (iommu_pass_through)
iommu_identity_mapping |= IDENTMAP_ALL;
@@ -2885,8 +2888,10 @@ static int __init init_dmars(void)
return 0;
free_iommu:
- for_each_active_iommu(iommu, drhd)
+ for_each_active_iommu(iommu, drhd) {
+ disable_dmar_iommu(iommu);
free_dmar_iommu(iommu);
+ }
kfree(deferred_flush);
free_g_iommus:
kfree(g_iommus);
@@ -3771,9 +3776,100 @@ int dmar_check_one_atsr(struct acpi_dmar_header *hdr, void *arg)
return 0;
}
+static int intel_iommu_add(struct dmar_drhd_unit *dmaru)
+{
+ int ret = 0;
+ struct intel_iommu *iommu = dmaru->iommu;
+
+ if (g_iommus[iommu->seq_id])
+ return 0;
+
+ if (hw_pass_through && !ecap_pass_through(iommu->ecap)) {
+ pr_warn("IOMMU: %s doesn't support hardware pass through.\n",
+ iommu->name);
+ return -ENXIO;
+ }
+ if (!ecap_sc_support(iommu->ecap) &&
+ domain_update_iommu_snooping(iommu)) {
+ pr_warn("IOMMU: %s doesn't support snooping.\n",
+ iommu->name);
+ return -ENXIO;
+ }
+ if ((cap_super_page_val(iommu->cap) &
+ (1 << domain_update_iommu_superpage(iommu))) = 0) {
+ pr_warn("IOMMU: %s doesn't support large page.\n",
+ iommu->name);
+ return -ENXIO;
+ }
+
+ /*
+ * Disable translation if already enabled prior to OS handover.
+ */
+ if (iommu->gcmd & DMA_GCMD_TE)
+ iommu_disable_translation(iommu);
+
+ g_iommus[iommu->seq_id] = iommu;
+ ret = iommu_init_domains(iommu);
+ if (ret = 0)
+ ret = iommu_alloc_root_entry(iommu);
+ if (ret)
+ goto out;
+
+ if (dmaru->ignored) {
+ /*
+ * we always have to disable PMRs or DMA may fail on this device
+ */
+ if (force_on)
+ iommu_disable_protect_mem_regions(iommu);
+ return 0;
+ }
+
+ intel_iommu_init_qi(iommu);
+ iommu_flush_write_buffer(iommu);
+ ret = dmar_set_interrupt(iommu);
+ if (ret)
+ goto disable_iommu;
+
+ iommu_set_root_entry(iommu);
+ iommu->flush.flush_context(iommu, 0, 0, 0, DMA_CCMD_GLOBAL_INVL);
+ iommu->flush.flush_iotlb(iommu, 0, 0, 0, DMA_TLB_GLOBAL_FLUSH);
+ iommu_enable_translation(iommu);
+
+ if (si_domain) {
+ ret = iommu_attach_domain(si_domain, iommu);
+ if (ret < 0 || si_domain->id != ret)
+ goto disable_iommu;
+ domain_attach_iommu(si_domain, iommu);
+ }
+
+ iommu_disable_protect_mem_regions(iommu);
+ return 0;
+
+disable_iommu:
+ disable_dmar_iommu(iommu);
+out:
+ free_dmar_iommu(iommu);
+ return ret;
+}
+
int dmar_iommu_hotplug(struct dmar_drhd_unit *dmaru, bool insert)
{
- return intel_iommu_enabled ? -ENOSYS : 0;
+ int ret = 0;
+ struct intel_iommu *iommu = dmaru->iommu;
+
+ if (!intel_iommu_enabled)
+ return 0;
+ if (iommu = NULL)
+ return -EINVAL;
+
+ if (insert) {
+ ret = intel_iommu_add(dmaru);
+ } else {
+ disable_dmar_iommu(iommu);
+ free_dmar_iommu(iommu);
+ }
+
+ return ret;
}
static void intel_iommu_free_dmars(void)
--
1.7.10.4
^ permalink raw reply related
* [Patch Part3 V2 21/21] pci, ACPI, iommu: enhance pci_root to support DMAR device hotplug
From: Jiang Liu @ 2014-05-06 7:05 UTC (permalink / raw)
To: Joerg Roedel, David Woodhouse, Yinghai Lu, Bjorn Helgaas,
Dan Williams, Vinod Koul, Rafael J . Wysocki, Rafael J. Wysocki,
Len Brown
Cc: Jiang Liu, Ashok Raj, Yijing Wang, Tony Luck, iommu, linux-pci,
linux-hotplug, linux-kernel, dmaengine, linux-acpi
In-Reply-To: <1399359932-28972-1-git-send-email-jiang.liu@linux.intel.com>
Finally enhance pci_root driver to support DMAR device hotplug when
hot-plugging PCI host bridges.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
drivers/acpi/pci_root.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index d388f13d48b4..99c2b9761c12 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -33,6 +33,7 @@
#include <linux/pci.h>
#include <linux/pci-acpi.h>
#include <linux/pci-aspm.h>
+#include <linux/dmar.h>
#include <linux/acpi.h>
#include <linux/slab.h>
#include <acpi/apei.h> /* for acpi_hest_init() */
@@ -511,6 +512,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
struct acpi_pci_root *root;
acpi_handle handle = device->handle;
int no_aspm = 0, clear_aspm = 0;
+ bool hotadd = system_state != SYSTEM_BOOTING;
root = kzalloc(sizeof(struct acpi_pci_root), GFP_KERNEL);
if (!root)
@@ -557,6 +559,11 @@ static int acpi_pci_root_add(struct acpi_device *device,
strcpy(acpi_device_class(device), ACPI_PCI_ROOT_CLASS);
device->driver_data = root;
+ if (hotadd && dmar_device_add(handle)) {
+ result = -ENXIO;
+ goto end;
+ }
+
pr_info(PREFIX "%s [%s] (domain %04x %pR)\n",
acpi_device_name(device), acpi_device_bid(device),
root->segment, &root->secondary);
@@ -583,7 +590,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
root->segment, (unsigned int)root->secondary.start);
device->driver_data = NULL;
result = -ENODEV;
- goto end;
+ goto remove_dmar;
}
if (clear_aspm) {
@@ -597,7 +604,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
if (device->wakeup.flags.run_wake)
device_set_run_wake(root->bus->bridge, true);
- if (system_state != SYSTEM_BOOTING) {
+ if (hotadd) {
pcibios_resource_survey_bus(root->bus);
pci_assign_unassigned_root_bus_resources(root->bus);
}
@@ -607,6 +614,9 @@ static int acpi_pci_root_add(struct acpi_device *device,
pci_unlock_rescan_remove();
return 1;
+remove_dmar:
+ if (hotadd)
+ dmar_device_remove(handle);
end:
kfree(root);
return result;
@@ -625,6 +635,8 @@ static void acpi_pci_root_remove(struct acpi_device *device)
pci_remove_root_bus(root->bus);
+ dmar_device_remove(device->handle);
+
pci_unlock_rescan_remove();
kfree(root);
--
1.7.10.4
^ permalink raw reply related
* Re: Fn keys on Dell Latitude E6440
From: Pali Rohár @ 2014-05-17 14:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201404141651.08779@pali>
[-- Attachment #1: Type: Text/Plain, Size: 1815 bytes --]
On Monday 14 April 2014 16:51:07 Pali Rohár wrote:
> Hello,
>
> on my notebook dell-wmi kernel driver generates some scan
> codes when I press some of Fn key combinations. Now all these
> scan codes are mapped to key "prog3". I would like to add
> some actions for these Fn key combinations, so what do you
> think? Which key codes should be assigned for these scan
> codes? Note that these combinations are not special (and
> labeled) as other (like Fn+F11 = play/pause) and seems like
> windows does not recognize them.
>
> Matthew, you are author of dell-wmi driver, do you know if
> there are some other secrets key combinations? And why first
> 10 Fn key combinations generate scan codes?
>
> Output of commands:
>
> $ lsinput
>
> /dev/input/event7
> bustype : BUS_HOST
> vendor : 0x0
> product : 0x0
> version : 0
> name : "Dell WMI hotkeys"
> phys : "wmi/input0"
> bits ev : EV_SYN EV_KEY EV_MSC
>
> $ /lib/udev/keymap -i /dev/input/event7
>
> scan code: 0x10 key code: prog3 --> Fn+Q
> scan code: 0x11 key code: prog3 --> Fn+W
> scan code: 0x12 key code: prog3 --> Fn+E
> scan code: 0x13 key code: prog3 --> Fn+R
> scan code: 0x14 key code: prog3 --> Fn+T
>
> scan code: 0x1E key code: prog3 --> Fn+A
> scan code: 0x1F key code: prog3 --> Fn+S
> scan code: 0x20 key code: prog3 --> Fn+D
> scan code: 0x21 key code: prog3 --> Fn+F
> scan code: 0x22 key code: prog3 --> Fn+G
>
> $ cat /sys/class/dmi/id/sys_vendor
> Dell Inc.
>
> $ cat /sys/class/dmi/id/product_name
> Latitude E6440
I looked deeper into dell-wmi driver and bios DMI keycode table.
I will send patch for dell-wmi driver which adding support for Fn
key combinations.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 0/2] dell-wmi: Add support for Fn key combinations
From: Pali Rohár @ 2014-05-17 14:43 UTC (permalink / raw)
To: Dmitry Torokhov, Matthew Garrett
Cc: linux-input, platform-driver-x86, linux-hotplug, Matthew Garrett,
linux-kernel, Pali Rohár
In-Reply-To: <201405171639.45722@pali>
This patch series add support for Fn key combinations to dell-wmi driver.
I tested this patch series on laptop Dell Latitude E6440.
Here is Bios DMI table which contains scancode to keycode mapping:
Handle 0xB200, DMI type 178, 80 bytes
OEM-specific Type
Header and Data:
B2 50 00 B2 07 01 0C 00 08 01 0A 00 09 01 0B 00
0A 01 12 00 3B 00 20 00 42 00 18 00 48 00 14 00
50 00 13 00 10 00 FF 00 11 00 FF 00 12 00 FF 00
13 00 FF 00 14 00 FF 00 1E 00 FF 00 1F 00 FF 00
20 00 FF 00 21 00 FF 00 22 00 FF 00 4D 00 16 00
Strings:
As you can see, more different keys are mapped to one keycode 0xFF.
Pali Roh√°r (2):
Input: Add keycodes for some missing Fn key combinations
dell-wmi: Add support for Fn key combinations
drivers/platform/x86/dell-wmi.c | 27 ++++++++++++++++++++++++++-
include/uapi/linux/input.h | 6 ++++++
2 files changed, 32 insertions(+), 1 deletion(-)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
From: Pali Rohár @ 2014-05-17 14:43 UTC (permalink / raw)
To: Dmitry Torokhov, Matthew Garrett
Cc: linux-input, platform-driver-x86, linux-hotplug, Matthew Garrett,
linux-kernel, Pali Rohár
In-Reply-To: <1400337817-14473-1-git-send-email-pali.rohar@gmail.com>
There are already defined some Fn key combinations, but not all.
This patch adds missing combinations for support in dell-wmi driver.
Signed-off-by: Pali Roh√°r <pali.rohar@gmail.com>
---
include/uapi/linux/input.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index f484952..3a32799 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -672,6 +672,12 @@ struct input_keymap_entry {
#define KEY_FN_F 0x1e2
#define KEY_FN_S 0x1e3
#define KEY_FN_B 0x1e4
+#define KEY_FN_Q 0x1e5
+#define KEY_FN_W 0x1e6
+#define KEY_FN_R 0x1e7
+#define KEY_FN_T 0x1e8
+#define KEY_FN_A 0x1e9
+#define KEY_FN_G 0x1ea
#define KEY_BRL_DOT1 0x1f1
#define KEY_BRL_DOT2 0x1f2
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] dell-wmi: Add support for Fn key combinations
From: Pali Rohár @ 2014-05-17 14:43 UTC (permalink / raw)
To: Dmitry Torokhov, Matthew Garrett
Cc: linux-input, platform-driver-x86, linux-hotplug, Matthew Garrett,
linux-kernel, Pali Rohár
In-Reply-To: <1400337817-14473-1-git-send-email-pali.rohar@gmail.com>
Bios DMI table contains scancodes for some Fn key combinations. But
corresponding keycodes in DMI table have same value 255. And dell-wmi driver
map value 255 to KEY_PROG3. This means that it is not possible to distinguish
between Fn key combinations (e.g Fn+Q and Fn+W), because kernel reports for all
of them only KEY_PROG3.
This patch adding new table for mapping Bios DMI scancodes to linux keycodes
when bios DMI keycode is set to "generic" keycode 255. So different Fn key
combinations will have different keycodes.
Signed-off-by: Pali Roh√°r <pali.rohar@gmail.com>
---
drivers/platform/x86/dell-wmi.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 390e8e3..c54d675 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -140,7 +140,27 @@ static const u16 bios_to_linux_keycode[256] __initconst = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, KEY_PROG3
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+};
+
+/* table for bios code 0xff */
+static const u16 scancode_to_linux_keycode[256] __initconst = {
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ KEY_FN_Q, KEY_FN_W, KEY_FN_E, KEY_FN_R,
+ KEY_FN_T, 0, 0, 0,
+ 0, 0, 0, 0,
+ 0, 0, KEY_FN_A, KEY_FN_S,
+ KEY_FN_D, KEY_FN_F, KEY_FN_G, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
static struct input_dev *dell_wmi_input_dev;
@@ -212,6 +232,11 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
keymap[i].keycode = bios_entry->keycode < 256 ?
bios_to_linux_keycode[bios_entry->keycode] :
KEY_RESERVED;
+ if (bios_entry->keycode = 255 && bios_entry->scancode < 256)
+ keymap[i].keycode + scancode_to_linux_keycode[bios_entry->scancode];
+ if (!keymap[i].keycode)
+ keymap[i].keycode = KEY_RESERVED;
}
keymap[hotkey_num].type = KE_END;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
From: Dmitry Torokhov @ 2014-05-17 20:30 UTC (permalink / raw)
To: Pali Rohár
Cc: Matthew Garrett, linux-input, platform-driver-x86, linux-hotplug,
Matthew Garrett, linux-kernel
In-Reply-To: <1400337817-14473-2-git-send-email-pali.rohar@gmail.com>
Hi Pali,
On Sat, May 17, 2014 at 04:43:36PM +0200, Pali Rohár wrote:
> There are already defined some Fn key combinations, but not all.
> This patch adds missing combinations for support in dell-wmi driver.
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
> include/uapi/linux/input.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index f484952..3a32799 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -672,6 +672,12 @@ struct input_keymap_entry {
> #define KEY_FN_F 0x1e2
> #define KEY_FN_S 0x1e3
> #define KEY_FN_B 0x1e4
> +#define KEY_FN_Q 0x1e5
> +#define KEY_FN_W 0x1e6
> +#define KEY_FN_R 0x1e7
> +#define KEY_FN_T 0x1e8
> +#define KEY_FN_A 0x1e9
> +#define KEY_FN_G 0x1ea
What do they actually do?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
From: Pali Rohár @ 2014-05-17 20:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Matthew Garrett, linux-input, platform-driver-x86, linux-hotplug,
Matthew Garrett, linux-kernel
In-Reply-To: <20140517203054.GA19657@core.coreip.homeip.net>
[-- Attachment #1: Type: Text/Plain, Size: 1482 bytes --]
On Saturday 17 May 2014 22:30:54 Dmitry Torokhov wrote:
> Hi Pali,
>
> On Sat, May 17, 2014 at 04:43:36PM +0200, Pali Rohár wrote:
> > There are already defined some Fn key combinations, but not
> > all. This patch adds missing combinations for support in
> > dell-wmi driver.
> >
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> >
> > include/uapi/linux/input.h | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/include/uapi/linux/input.h
> > b/include/uapi/linux/input.h index f484952..3a32799 100644
> > --- a/include/uapi/linux/input.h
> > +++ b/include/uapi/linux/input.h
> > @@ -672,6 +672,12 @@ struct input_keymap_entry {
> >
> > #define KEY_FN_F 0x1e2
> > #define KEY_FN_S 0x1e3
> > #define KEY_FN_B 0x1e4
> >
> > +#define KEY_FN_Q 0x1e5
> > +#define KEY_FN_W 0x1e6
> > +#define KEY_FN_R 0x1e7
> > +#define KEY_FN_T 0x1e8
> > +#define KEY_FN_A 0x1e9
> > +#define KEY_FN_G 0x1ea
>
> What do they actually do?
>
> Thanks.
All 10 combinations Fn+Q ... Fn+T, Fn+A ... Fn+G are reported by
WMI and I need to assign some keycodes for them in dell-wmi
driver. And because More FN_* constants are already defined in
input.h I added those which are missing.
With this patch series I'm able to use above Fn combinations for
my own keyboard shortcuts. Before this patch all Fn combinations
were one same keycode - which was useless.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
From: Dmitry Torokhov @ 2014-05-17 21:32 UTC (permalink / raw)
To: Pali Rohár
Cc: Matthew Garrett, linux-input, platform-driver-x86, linux-hotplug,
Matthew Garrett, linux-kernel
In-Reply-To: <201405172238.30089@pali>
On Sat, May 17, 2014 at 10:38:30PM +0200, Pali Rohár wrote:
> On Saturday 17 May 2014 22:30:54 Dmitry Torokhov wrote:
> > Hi Pali,
> >
> > On Sat, May 17, 2014 at 04:43:36PM +0200, Pali Rohár wrote:
> > > There are already defined some Fn key combinations, but not
> > > all. This patch adds missing combinations for support in
> > > dell-wmi driver.
> > >
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > ---
> > >
> > > include/uapi/linux/input.h | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/input.h
> > > b/include/uapi/linux/input.h index f484952..3a32799 100644
> > > --- a/include/uapi/linux/input.h
> > > +++ b/include/uapi/linux/input.h
> > > @@ -672,6 +672,12 @@ struct input_keymap_entry {
> > >
> > > #define KEY_FN_F 0x1e2
> > > #define KEY_FN_S 0x1e3
> > > #define KEY_FN_B 0x1e4
> > >
> > > +#define KEY_FN_Q 0x1e5
> > > +#define KEY_FN_W 0x1e6
> > > +#define KEY_FN_R 0x1e7
> > > +#define KEY_FN_T 0x1e8
> > > +#define KEY_FN_A 0x1e9
> > > +#define KEY_FN_G 0x1ea
> >
> > What do they actually do?
> >
> > Thanks.
>
> All 10 combinations Fn+Q ... Fn+T, Fn+A ... Fn+G are reported by
> WMI and I need to assign some keycodes for them in dell-wmi
> driver.
If they do not have a well-defined meaning then KEY_UNKNOWN is
appropriate and user later can redefine via EVIOCSKEYCODE to the code
they wish.
> And because More FN_* constants are already defined in
> input.h I added those which are missing.
I am not sure if adding existing generic KEY_FN_* was a good idea.
>
> With this patch series I'm able to use above Fn combinations for
> my own keyboard shortcuts. Before this patch all Fn combinations
> were one same keycode - which was useless.
Are there not enough key definitions already to accommodate actions you
want? dell-wmi supports changing keymap from usersopace so you should be
able to remap entries you want to the actions you need.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [Patch Part3 V2 00/21] Enable support of Intel DMAR device hotplug
From: Joerg Roedel @ 2014-05-19 9:23 UTC (permalink / raw)
To: Jiang Liu
Cc: David Woodhouse, Yinghai Lu, Bjorn Helgaas, Dan Williams,
Vinod Koul, Rafael J . Wysocki, Ashok Raj, Yijing Wang, Tony Luck,
iommu, linux-pci, linux-hotplug, linux-kernel, dmaengine
In-Reply-To: <1399359932-28972-1-git-send-email-jiang.liu@linux.intel.com>
Hey David,
On Tue, May 06, 2014 at 03:05:11PM +0800, Jiang Liu wrote:
> Patch 1-13 are bugfixes and code improvement for current drivers.
> Patch 14-17 enhances DMAR framework to support hotplug
> Patch 18 enhances Intel interrupt remapping driver to support hotplug
> Patch 19 enhances error handling in Intel IR driver
> Patch 20 enhance Intel IOMMU to support hotplug
> Patch 21 enhance ACPI pci_root driver to handle DMAR units
Have you had a chance to look into this patch-set? I'll wonder whether
it should be merged for 3.16.
Joerg
^ permalink raw reply
* [linux-hotplug] 3g modem is not recognized as an ethernet device without rebooting
From: Niyazi Sırt @ 2014-05-24 13:36 UTC (permalink / raw)
To: linux-hotplug
I have two CentOS5 servers with kernel versions 3.4.52 and Huawei e353
usb 3g modem.
When I plug the modem to my server usb_modeswitch runs and I can
see the modem as an ethernet device with "ifconfig -a" command on the
properly working server.
But other server is not working properly. I can't see any ethernet after
I plug the modem device.
- All of servers have the same versions of the usb_modeswitch rpm.
before running usb_modeswitch
working properly not working properly
# lsusb | grep 12d1 # lsusb | grep 12d1
before Bus 001 Device 005: ID 12d1:1f01 Bus 001 Device 005: ID
12d1:1f01
after running usb_modeswitch
working properly not working properly
# lsusb | grep 12d1 # lsusb | grep 12d1
Bus 001 Device 005: ID 12d1:14db Bus 001 Device 005: ID 12d1:14db
working properly not working properly
# rpm -qa | grep modesw # rpm -qa | grep modesw
usb_modeswitch-data-20130610-1.lbr usb_modeswitch-data-20130610-1.lbr
usb_modeswitch-1.2.6-2 usb_modeswitch-1.2.6-2
- I have compared /etc/udev directories of the two servers with diff but
there
isn't any difference
There is an interesting thing about the not properly working server.
After I reboot the
server while the usb 3g modem plugged, the modem works properly and I
can see
it as an ethernet device with the "ifconfig -a" command. So I thought
that if i can
reload udev, I would see the modem as an ethernet device so I run the
following commands:
/sbin/udevcontrol reload_rules
/sbin/start_udev
But it did not solve the problem. And also I thought that the two
servers may have been
builded with different kernel parameters. So I compared the output of
"sysctl -a" on each server.
# diff config_workingProperly config_notWorkingProperly -y
CONFIG_TREE_PREEMPT_RCU=y |
CONFIG_TREE_RCU=y
CONFIG_PREEMPT_RCU=y | #
CONFIG_PREEMPT_RCU is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set |
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK is not set |
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set |
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK is not set |
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set |
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_PREEMPT_NONE is not set |
CONFIG_PREEMPT_NONE=y
CONFIG_PREEMPT=y | #
CONFIG_PREEMPT is not set
# CONFIG_BLK_DEV_FD is not set |
CONFIG_BLK_DEV_FD=m
# CONFIG_IDE_GD is not set |
CONFIG_IDE_GD=m
# CONFIG_BLK_DEV_IDECD is not set |
CONFIG_IDE_GD_ATA=y
# CONFIG_BLK_DEV_SR_VENDOR is not set |
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_JFS_FS=m | #
CONFIG_JFS_FS is not set
# CONFIG_CUSE is not set |
CONFIG_CUSE=y
CONFIG_ISO9660_FS=m |
CONFIG_ISO9660_FS=y
CONFIG_UDF_FS=m |
CONFIG_UDF_FS=y
CONFIG_FAT_FS=m |
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=m |
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=m |
CONFIG_VFAT_FS=y
CONFIG_SQUASHFS=m |
CONFIG_SQUASHFS=y
# CONFIG_SQUASHFS_XATTR is not set |
CONFIG_SQUASHFS_XATTR=y
# CONFIG_SQUASHFS_LZO is not set |
CONFIG_SQUASHFS_LZO=y
# CONFIG_SQUASHFS_XZ is not set |
CONFIG_SQUASHFS_XZ=y
CONFIG_CRC_ITU_T=m |
CONFIG_CRC_ITU_T=y
# CONFIG_RCU_BOOST is not set <
CONFIG_UNINLINE_SPIN_UNLOCK=y <
CONFIG_PREEMPT_COUNT=y <
CONFIG_JFS_POSIX_ACL=y <
CONFIG_JFS_SECURITY=y <
# CONFIG_JFS_DEBUG is not set <
CONFIG_JFS_STATISTICS=y <
CONFIG_DEBUG_PREEMPT=y <
CONFIG_RCU_CPU_STALL_VERBOSE=y <
# CONFIG_PREEMPT_TRACER is not set <
>
CONFIG_OPTPROBES=y
>
CONFIG_IDE_ATAPI=y
> #
CONFIG_IDE_GD_ATAPI is not set
>
CONFIG_BLK_DEV_IDECD=m
>
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
> #
CONFIG_LEDS_TRIGGER_IDE_DISK is not set
So what might be causing the problem? Why can't the other server
identify my 3g modem as an ethernet device without rebooting?
^ permalink raw reply
* Why do we need usb_modeswitch?
From: Suresh Kumar N. @ 2014-05-26 3:54 UTC (permalink / raw)
To: linux-hotplug
Hi,
I am new to udev and plug-n-play.
Please let me know -
1. Why do we need usb_modeswitch?
2. In case usb_modeswitch is used to just convert USB device to Serial
or Ethernet device (as per my understanding), then why not enumerate
the device as Serial or Ethernet device itself?
Good Day!
Warm Regards,
Suresh
^ permalink raw reply
* Re: Why do we need usb_modeswitch?
From: Greg KH @ 2014-05-26 4:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CALR+S1jo537Ov6EWp4Y19yuBek9-ZqregV3bch6iVZQoJVWqAA@mail.gmail.com>
On Mon, May 26, 2014 at 09:24:49AM +0530, Suresh Kumar N. wrote:
>
> Please let me know -
> 1. Why do we need usb_modeswitch?
Why do you think we do not?
> 2. In case usb_modeswitch is used to just convert USB device to Serial
> or Ethernet device (as per my understanding), then why not enumerate
> the device as Serial or Ethernet device itself?
Have you looked at the devices that need this program to be run? I
think if you look at the USB descriptors of them, you will answer
question #1 yourself :)
Hope this helps,
greg k-h
^ permalink raw reply
* Cross building udev cannot creat device node
From: 李建文 @ 2014-06-03 3:05 UTC (permalink / raw)
To: linux-hotplug
I cross build Udev and run on arm and found cannot creat device node.
Linux version 3.0.35 (gcc version 4.6.2 20110630 (prerelease)
(Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) ) #161
SMP PREEMPT Fri May 30 18:21:18 CST 2014
udev 182
/sbin # [ 7350.371305] mmc1: new high speed SDHC card at address 1234
[7350.154204] [7540] builtin_kmod[ 7350.380433] mmcblk1: mmc1:1234
SA04G 3.63 GiB
_validate: validate module index
[7350.157103] [7540] event_queu[ 7350.389884] mmcblk1: p1
e_insert: seq 733 queued, 'add' 'mmc'
[7350.161978] [7550] worker_new: seq 733 running
[7350.162079] [7550] udev_device_new_from_syspath: device 0x450a8 has
devpath '/devices/platform/sdhci-esdhc-imx.0/mmc_host/mmc1/mmc1:1234'
[7350.162486] [7540] udev_monitor_send_device: passed 229 bytes to
netlink monitor 0x43360
[7350.162632] [7540] event_queue_insert: seq 734 queued, 'add' 'bdi'
[7350.163103] [7554] worker_new: seq 734 running
[7350.163277] [7554] udev_device_new_from_syspath: device 0x43360 has
devpath '/devices/virtual/bdi/179:24'
[7350.163669] [7550] udev_device_read_db: no db file to read
/run/udev/data/+mmc:mmc1:1234: No such file or directory
[7350.163734] [7550] udev_rules_apply_to_event: RUN
'/etc/dev.d/default/gs_hotplug.dev %k %n %M %m'
/etc/udev/rules.d/50-udev.rules:48
[7350.164178] [7540] udev_monitor_send_device: passed 151 bytes to
netlink monitor 0x43360
[7350.164645] [7554] udev_device_read_db: no db file to read
/run/udev/data/+bdi:179:24: No such file or directory
[7350.164710] [7554] udev_rules_apply_to_event: RUN
'/etc/dev.d/default/gs_hotplug.dev %k %n %M %m'
/etc/udev/rules.d/50-udev.rules:48
[7350.164987] [8725] udev_event_spawn: starting
'/etc/dev.d/default/gs_hotplug.dev mmc1:1234 1234 0 0'
[7350.166045] [8726] udev_event_spawn: starting
'/etc/dev.d/default/gs_hotplug.dev 179:24 24 0 0'
[7350.172073] [7540] event_queue_insert: seq 735 queued, 'add' 'block'
[7350.173630] [7540] event_queue_insert: seq 736 queued, 'add' 'block'
[7350.175565] [7554] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
179:24 24 0 0'(out) '179:24 24 0 0'
[7350.176439] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmc1:1234 1234 0 0'(out) 'mmc1:1234 1234 0 0'
[7350.223230] [7554] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
179:24 24 0 0'(err) 'sh: hid_mouse: unknown operand'
[7350.223278] [7554] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
179:24 24 0 0'(err) 'sh: hid_keyboard: unknown operand'
[7350.223361] [7554] spawn_wait: '/etc/dev.d/default/gs_hotplug.dev
179:24 24 0 0' [8726] exit with return code 0
[7350.223572] [7554] udev_monitor_send_device: passed -1 bytes to
netlink monitor 0x45220
[7350.223620] [7554] worker_new: seq 734 processed with 0
[7350.223750] [7540] event_queue_delete: seq 734 done with 0
[7350.225500] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmc1:1234 1234 0 0'(err) 'sh: hid_mouse: unknown operand'
[7350.225532] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmc1:1234 1234 0 0'(err) 'sh: hid_keyboard: unknown operand'
[7350.225606] [7550] spawn_wait: '/etc/dev.d/default/gs_hotplug.dev
mmc1:1234 1234 0 0' [8725] exit with return code 0
[7350.225852] [7550] udev_monitor_send_device: passed -1 bytes to
netlink monitor 0x44ca8
[7350.225890] [7550] worker_new: seq 733 processed with 0
[7350.225940] [7540] event_queue_delete: seq 733 done with 0
[7350.226030] [7540] udev_monitor_send_device: passed 252 bytes to
netlink monitor 0x43360
[7350.226137] [7550] worker_new: seq 735 running
[7350.226263] [7550] udev_device_new_from_syspath: device 0x450a8 has
devpath '/devices/platform/sdhci-esdhc-imx.0/mmc_host/mmc1/mmc1:1234/block/mmcblk1'
[7350.226888] [7550] udev_device_read_db: no db file to read
/run/udev/data/b179:24: No such file or directory
[7350.226948] [7550] udev_rules_apply_to_event: RUN
'/etc/dev.d/default/gs_hotplug.dev %k %n %M %m'
/etc/udev/rules.d/50-udev.rules:48
[7350.226988] [7550] udev_node_add: handling device node
'/dev/mmcblk1', devnum±79:24, mode\x0600, uid=0, gid=0
[7350.227038] [7550] node_fixup: can not stat() node '/dev/mmcblk1'
(No such file or directory)
[7350.229375] [7550] udev_device_update_db: created empty file
'/run/udev/data/b179:24' for
'/devices/platform/sdhci-esdhc-imx.0/mmc_host/mmc1/mmc1:1234/block/mmcblk1'
[7350.230143] [8761] udev_event_spawn: starting
'/etc/dev.d/default/gs_hotplug.dev mmcblk1 1 179 24'
[7350.234969] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmcblk1 1 179 24'(out) 'mmcblk1 1 179 24'
[7350.276693] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmcblk1 1 179 24'(err) '/dev/mmcblk1: error opening volume'
[7350.278910] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmcblk1 1 179 24'(err) 'sh: vfat: unknown operand'
[7350.284648] [7550] spawn_wait: '/etc/dev.d/default/gs_hotplug.dev
mmcblk1 1 179 24' [8761] exit with return code 0
[7350.284733] [7550] udev_monitor_send_device: passed -1 bytes to
netlink monitor 0x44ca8
[7350.284776] [7550] worker_new: seq 735 processed with 0
[7350.284854] [7540] event_queue_delete: seq 735 done with 0
[7350.284945] [7540] udev_monitor_send_device: passed 269 bytes to
netlink monitor 0x43360
[7350.285044] [7550] worker_new: seq 736 running
[7350.285187] [7550] udev_device_new_from_syspath: device 0x43410 has
devpath '/devices/platform/sdhci-esdhc-imx.0/mmc_host/mmc1/mmc1:1234/block/mmcblk1/mmcblk1p1'
[7350.286144] [7550] udev_device_read_db: no db file to read
/run/udev/data/b179:25: No such file or directory
[7350.286207] [7550] udev_rules_apply_to_event: RUN
'/etc/dev.d/default/gs_hotplug.dev %k %n %M %m'
/etc/udev/rules.d/50-udev.rules:48
[7350.286246] [7550] udev_node_add: handling device node
'/dev/mmcblk1p1', devnum±79:25, mode\x0600, uid=0, gid=0
[7350.286295] [7550] node_fixup: can not stat() node '/dev/mmcblk1p1'
(No such file or directory)
[7350.288551] [7550] udev_device_update_db: created empty file
'/run/udev/data/b179:25' for
'/devices/platform/sdhci-esdhc-imx.0/mmc_host/mmc1/mmc1:1234/block/mmcblk1/mmcblk1p1'
[7350.620473] [8780] udev_event_spawn: starting
'/etc/dev.d/default/gs_hotplug.dev mmcblk1p1 1 179 25'
[7350.625424] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmcblk1p1 1 179 25'(out) 'mmcblk1p1 1 179 25'
[7350.664754] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmcblk1p1 1 179 25'(err) '/dev/mmcblk1p1: error opening volume'
[7350.666344] [7550] spawn_read: '/etc/dev.d/default/gs_hotplug.dev
mmcblk1p1 1 179 25'(err) 'sh: vfat: unknown operand'
[7350.671612] [7550] spawn_wait: '/etc/dev.d/default/gs_hotplug.dev
mmcblk1p1 1 179 25' [8780] exit with return code 0
[7350.671697] [7550] udev_monitor_send_device: passed -1 bytes to
netlink monitor 0x44ca8
[7350.671742] [7550] worker_new: seq 736 processed with 0
[7350.719399] [7540] event_queue_delete: seq 736 done with 0
^ permalink raw reply
* Re: Cross building udev cannot creat device node
From: Greg KH @ 2014-06-03 3:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CADVuKbpPPj_8O8wu1tAsfPztdv0ipPy03FKNZgnDd75f6n3cLA@mail.gmail.com>
On Tue, Jun 03, 2014 at 11:05:08AM +0800, 李建文 wrote:
> I cross build Udev and run on arm and found cannot creat device node.
>
> Linux version 3.0.35 (gcc version 4.6.2 20110630 (prerelease)
> (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) ) #161
> SMP PREEMPT Fri May 30 18:21:18 CST 2014
>
> udev 182
Are you using DEVTMPFS in your kernel? udev no longer creates the
device nodes, the kernel does.
thanks,
greg k-h
^ permalink raw reply
* Re: Cross building udev cannot creat device node
From: 李建文 @ 2014-06-03 4:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CADVuKbpPPj_8O8wu1tAsfPztdv0ipPy03FKNZgnDd75f6n3cLA@mail.gmail.com>
greg k-h
thanks for your reply, from which verison of udev no longger creates
the device nodes?
I awaly use a very old udev. now I want upgrade udev to 182, but
failed, should I enable
DEVTMPFS ?
and I had tried to build kernel with CONFIG_DEVTMPFS, and also cannot
find dynamic device node be created.
/ # zcat /proc/config.gz |grep CONFIG_DEVTMPFS
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
On Tue, Jun 3, 2014 at 11:55 AM, Greg KH <greg@kroah.com> wrote:
> On Tue, Jun 03, 2014 at 11:05:08AM +0800, 李建文 wrote:
>> I cross build Udev and run on arm and found cannot creat device node.
>>
>> Linux version 3.0.35 (gcc version 4.6.2 20110630 (prerelease)
>> (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) ) #161
>> SMP PREEMPT Fri May 30 18:21:18 CST 2014
>>
>> udev 182
>
> Are you using DEVTMPFS in your kernel? udev no longer creates the
> device nodes, the kernel does.
>
> thanks,
>
> greg k-h
--
Javen / Jianwen Li / 李建文
Tel：086-0571-86849591 EXT 3516
Mob:15067198505
Email:jwli@grandstream.com
Department: System Development（HZ）
Posts: Linux Drvier Engineer
Grandstream Networks, inc. (China)
^ permalink raw reply
* Re: Cross building udev cannot creat device node
From: Greg KH @ 2014-06-03 4:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CADVuKbpPPj_8O8wu1tAsfPztdv0ipPy03FKNZgnDd75f6n3cLA@mail.gmail.com>
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Tue, Jun 03, 2014 at 12:18:34PM +0800, 李建文 wrote:
> greg k-h
> thanks for your reply, from which verison of udev no longger creates
> the device nodes?
I do not remember, read the release notes, or look at the git commit log
for the details on when this happened.
> I awaly use a very old udev. now I want upgrade udev to 182, but
> failed, should I enable
> DEVTMPFS ?
>
Yes, you always should.
> and I had tried to build kernel with CONFIG_DEVTMPFS, and also cannot
> find dynamic device node be created.
> / # zcat /proc/config.gz |grep CONFIG_DEVTMPFS
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
I don't know what is going on, sorry. 3.0 is very old and obsolete,
please move to a modern kernel version if you want help from the
community.
good luck,
greg k-h
^ permalink raw reply
* Re: Cross building udev cannot creat device node
From: 李建文 @ 2014-06-03 7:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CADVuKbpPPj_8O8wu1tAsfPztdv0ipPy03FKNZgnDd75f6n3cLA@mail.gmail.com>
>> and I had tried to build kernel with CONFIG_DEVTMPFS, and also cannot
>> find dynamic device node be created.
>> / # zcat /proc/config.gz |grep CONFIG_DEVTMPFS
>> CONFIG_DEVTMPFS=y
>> CONFIG_DEVTMPFS_MOUNT=y
>
> I don't know what is going on, sorry. 3.0 is very old and obsolete,
> please move to a modern kernel version if you want help from the
> community.
greg, thank you for your help. previously, DEVTMPFS not work for me
because I mount /dev as ramfs (mount -t ramfs udev /dev)
once I remove "mount -t ramfs udev /dev" in my bootscript， devtmpfs
can created device node correctly
Javen
^ permalink raw reply
* Kernel BUG() in block/blk-tag.c:89 causing panic.
From: Saran Neti @ 2014-06-19 4:42 UTC (permalink / raw)
To: linux-hotplug
Hi,
I have a many identical looking USB drives in two btrfs multi-device
configurations. I was unplugging and replugging a few devices to
identify which physical device belonged to which btrfs filesystem.
Running "btrfs fi show" during this unplugging/replugging business
produced the BUG() stack trace shown below. "btrfs fi show" wouldn't
return and neither would "fdisk -l". When I tried to reboot the
computer, it panicked forcing me to do a hard reset.
All hard disks are run-of-the-mill Seagate Expansion or Backup Plus
drives. They all work fine (data and SMART) when kernel
detects them at the start. I hit the BUG() twice during
unplugging/replugging them randomly and I think it could've been when
I swapped USB ports for identical drives (model/version etc.)
If more lspci/lsusb information if needed, let me know. I should be
able to reproduce it again and if needed insert printks and debug on
mainline.
# uname -a
Linux godel 3.15.1-1-ARCH #1 SMP PREEMPT Tue Jun 17 09:32:20 CEST 2014
x86_64 GNU/Linux
------------[ cut here ]------------
kernel BUG at block/blk-tag.c:89!
invalid opcode: 0000 [#1] PREEMPT SMP
Modules linked in: bridge stp llc tun nct6775 hwmon_vid hid_microsoft
uas usb_storage joydev hid_generic ir_lirc_codec mousedev lirc_dev
ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder
ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_rc6_mce
usbhid mceusb rc_core hid snd_hda_codec_hdmi coretemp hwmon
x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm iTCO_wdt
iTCO_vendor_support ppdev mxm_wmi evdev mac_hid ext4 crc16 mbcache
jbd2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel cryptd
microcode snd_hda_codec_realtek i915 snd_hda_codec_generic psmouse
serio_raw pcspkr snd_hda_intel snd_hda_controller drm_kms_helper drm
snd_hda_codec snd_hwdep parport_pc i2c_i801 snd_pcm lpc_ich r8169 mii
parport mei_me thermal fan wmi battery tpm_infineon tpm_tis tpm
mei snd_timer video shpchp intel_gtt snd i2c_algo_bit button i2c_core
soundcore processor btrfs xor atkbd libps2 c
rc32c_intel ehci_pci ehci_hcd xhci_hcd usbcore usb_common raid6_pq
i8042 serio sd_mod crc_t10dif crct10dif_common ahci libahci libata
scsi_mod
CPU: 0 PID: 821 Comm: systemd-udevd Not tainted 3.15.1-1-ARCH #1
Hardware name: MSI MS-7850/Z87-G41 PC Mate(MS-7850), BIOS V1.6 02/21/2014
task: ffff88020a369460 ti: ffff8801f4ff8000 task.ti: ffff8801f4ff8000
RIP: 0010:[<ffffffff8126b188>] [<ffffffff8126b188>] blk_free_tags+0x18/0x20
RSP: 0018:ffff8801f4ffbbb0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801f2845000 RCX: 0000000000340780
RDX: 0000000000000000 RSI: ffff880037d1a600 RDI: ffff8802112a3a00
RBP: ffff8801f4ffbbb0 R08: 000000000001b760 R09: ffff880214873800
R10: ffff88021fa1b760 R11: ffffea0000df4680 R12: ffff88020629f030
R13: ffff8800b65ca480 R14: ffff8801f28451a0 R15: ffff8800b65c4120
FS: 00007f4256c9f7c0(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2ba863e038 CR3: 00000001f4fe0000 CR4: 00000000000407f0
Stack:
ffff8801f4ffbbd8 ffffffffa0003230 ffff8801f28451a0 ffff8801f2845190
ffff8800b65ca480 ffff8801f4ffbc00 ffffffff8138c552 ffff8801f28451d8
ffffffff8189e2c0 ffff8802106f8ac0 ffff8801f4ffbc30 ffffffff8129466a
Call Trace:
[<ffffffffa0003230>] scsi_host_dev_release+0xb0/0xf0 [scsi_mod]
[<ffffffff8138c552>] device_release+0x32/0xa0
[<ffffffff8129466a>] kobject_release+0x7a/0x1c0
[<ffffffff812947dd>] kobject_put+0x2d/0x60
[<ffffffff8138c997>] put_device+0x17/0x20
[<ffffffffa000af7f>] scsi_target_dev_release+0x1f/0x30 [scsi_mod]
[<ffffffff8138c552>] device_release+0x32/0xa0
[<ffffffff8129466a>] kobject_release+0x7a/0x1c0
[<ffffffff812947dd>] kobject_put+0x2d/0x60
[<ffffffff8138c997>] put_device+0x17/0x20
[<ffffffffa000e435>] scsi_device_dev_release_usercontext+0x195/0x1a0 [scsi_mod]
[<ffffffff81085257>] execute_in_process_context+0x67/0x70
[<ffffffffa000e29c>] scsi_device_dev_release+0x1c/0x20 [scsi_mod]
[<ffffffff8138c552>] device_release+0x32/0xa0
[<ffffffff8129466a>] kobject_release+0x7a/0x1c0
[<ffffffff812947dd>] kobject_put+0x2d/0x60
[<ffffffff8138c997>] put_device+0x17/0x20
[<ffffffffa000180a>] scsi_device_put+0x3a/0x50 [scsi_mod]
[<ffffffffa00a4810>] scsi_disk_put+0x30/0x50 [sd_mod]
[<ffffffffa00a5821>] sd_release+0x31/0x70 [sd_mod]
[<ffffffff811ef642>] __blkdev_put+0x182/0x1c0
[<ffffffff811f000c>] blkdev_put+0x4c/0x150
[<ffffffff811f01c5>] blkdev_close+0x25/0x30
[<ffffffff811b609c>] __fput+0x9c/0x200
[<ffffffff811b624e>] ____fput+0xe/0x10
[<ffffffff8108a35f>] task_work_run+0x9f/0xe0
[<ffffffff81014c55>] do_notify_resume+0x95/0xa0
[<ffffffff81515be0>] int_signal+0x12/0x17
Code: c3 66 90 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 55 48 89 e5 e8 82 ff ff ff 85 c0 74 0
6 5d c3 0f 1f 40 00 <0f> 0b 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89
e5 53 48 89 fb
RIP [<ffffffff8126b188>] blk_free_tags+0x18/0x20
RSP <ffff8801f4ffbbb0>
---[ end trace bc3cb23eb685d10a ]---
systemd-udevd[185]: worker [821] terminated by signal 11 (Segmentation fault)
--
Saran
^ permalink raw reply
* Re: Kernel BUG() in block/blk-tag.c:89 causing panic.
From: Greg KH @ 2014-06-19 4:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAE6A3M1pvsHYAH4XVDpBJqVodrc-yJ-mtKRz98UsnwB2yWScRw@mail.gmail.com>
On Thu, Jun 19, 2014 at 12:42:51AM -0400, Saran Neti wrote:
> Hi,
>
> I have a many identical looking USB drives in two btrfs multi-device
> configurations. I was unplugging and replugging a few devices to
> identify which physical device belonged to which btrfs filesystem.
> Running "btrfs fi show" during this unplugging/replugging business
> produced the BUG() stack trace shown below. "btrfs fi show" wouldn't
> return and neither would "fdisk -l". When I tried to reboot the
> computer, it panicked forcing me to do a hard reset.
>
> All hard disks are run-of-the-mill Seagate Expansion or Backup Plus
> drives. They all work fine (data and SMART) when kernel
> detects them at the start. I hit the BUG() twice during
> unplugging/replugging them randomly and I think it could've been when
> I swapped USB ports for identical drives (model/version etc.)
>
> If more lspci/lsusb information if needed, let me know. I should be
> able to reproduce it again and if needed insert printks and debug on
> mainline.
>
> # uname -a
> Linux godel 3.15.1-1-ARCH #1 SMP PREEMPT Tue Jun 17 09:32:20 CEST 2014
> x86_64 GNU/Linux
This looks like a scsi bug, can you send this to the
linux-scsi@vger.kernel.org mailing list?
thanks,
greg k-h
^ permalink raw reply
* [Patch] iommu/vt-d: fix bug in handling multiple RMRRs for the same PCI device
From: Jiang Liu @ 2014-06-20 7:08 UTC (permalink / raw)
To: Joerg Roedel, David Woodhouse
Cc: Jiang Liu, iommu, linux-pci, linux-hotplug, linux-kernel
Function dmar_iommu_notify_scope_dev() makes a wrong assumption that
there's one RMRR for each PCI device at most, which causes DMA failure
on some HP platforms. So enhance dmar_iommu_notify_scope_dev() to
handle multiple RMRRs for the same PCI device.
Fixbug: https://bugzilla.novell.com/show_bug.cgi?id‡9482
Cc: <stable@vger.kernel.org> # 3.15
Reported-by: Tom Mingarelli <thomas.mingarelli@hp.com>
Tested-by: Linda Knippers <linda.knippers@hp.com>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
drivers/iommu/intel-iommu.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 6bb32773c3ac..51b6b77dc3e5 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3816,14 +3816,11 @@ int dmar_iommu_notify_scope_dev(struct dmar_pci_notify_info *info)
((void *)rmrr) + rmrr->header.length,
rmrr->segment, rmrru->devices,
rmrru->devices_cnt);
- if (ret > 0)
- break;
- else if(ret < 0)
+ if(ret < 0)
return ret;
} else if (info->event = BUS_NOTIFY_DEL_DEVICE) {
- if (dmar_remove_dev_scope(info, rmrr->segment,
- rmrru->devices, rmrru->devices_cnt))
- break;
+ dmar_remove_dev_scope(info, rmrr->segment,
+ rmrru->devices, rmrru->devices_cnt);
}
}
--
1.7.10.4
^ permalink raw reply related
* Re: [Patch] iommu/vt-d: fix bug in handling multiple RMRRs for the same PCI device
From: Joerg Roedel @ 2014-06-20 12:23 UTC (permalink / raw)
To: Jiang Liu; +Cc: David Woodhouse, iommu, linux-pci, linux-hotplug, linux-kernel
In-Reply-To: <1403248086-13853-1-git-send-email-jiang.liu@linux.intel.com>
On Fri, Jun 20, 2014 at 03:08:06PM +0800, Jiang Liu wrote:
> Function dmar_iommu_notify_scope_dev() makes a wrong assumption that
> there's one RMRR for each PCI device at most, which causes DMA failure
> on some HP platforms. So enhance dmar_iommu_notify_scope_dev() to
> handle multiple RMRRs for the same PCI device.
>
> Fixbug: https://bugzilla.novell.com/show_bug.cgi?id‡9482
>
> Cc: <stable@vger.kernel.org> # 3.15
> Reported-by: Tom Mingarelli <thomas.mingarelli@hp.com>
> Tested-by: Linda Knippers <linda.knippers@hp.com>
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Applied to iommu/fixes, thans Jiang.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox