[tip:core/urgent] objtool: Do not retrieve data from empty sections
Commit-ID: df968c9329f6e5cf3596a0a54adb6f749747a746
Gitweb: http://git.kernel.org/tip/df968c9329f6e5cf3596a0a54adb6f749747a746
Author: Petr Vandrovec <p...@vandrovec.name>
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 15 Sep 2017 11:31:50 +0200
objtool: Do not retrieve data from empty sections
Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:
elf_getdata: can't manipulate null section
As nothing is done with sections that have zero size, just do not
retrieve their data at all.
Signed-off-by: Petr Vandrovec <p...@vandrovec.name>
Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link:
http://lkml.kernel.org/r/2ce30a44349065b70d0f00e71e286dc0cbe745e6.1505459652.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
tools/objtool/elf.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 1e89a5f..b4cd8bc 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
- sec->data = elf_getdata(s, NULL);
- if (!sec->data) {
- WARN_ELF("elf_getdata");
- return -1;
- }
-
- if (sec->data->d_off != 0 ||
- sec->data->d_size != sec->sh.sh_size) {
- WARN("unexpected data attributes for %s", sec->name);
- return -1;
+ if (sec->sh.sh_size != 0) {
+ sec->data = elf_getdata(s, NULL);
+ if (!sec->data) {
+ WARN_ELF("elf_getdata");
+ return -1;
+ }
+ if (sec->data->d_off != 0 ||
+ sec->data->d_size != sec->sh.sh_size) {
+ WARN("unexpected data attributes for %s",
+sec->name);
+ return -1;
+ }
}
-
- sec->len = sec->data->d_size;
+ sec->len = sec->sh.sh_size;
}
/* sanity check, one more call to elf_nextscn() should return NULL */
[tip:core/urgent] objtool: Do not retrieve data from empty sections
Commit-ID: df968c9329f6e5cf3596a0a54adb6f749747a746
Gitweb: http://git.kernel.org/tip/df968c9329f6e5cf3596a0a54adb6f749747a746
Author: Petr Vandrovec
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer: Ingo Molnar
CommitDate: Fri, 15 Sep 2017 11:31:50 +0200
objtool: Do not retrieve data from empty sections
Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:
elf_getdata: can't manipulate null section
As nothing is done with sections that have zero size, just do not
retrieve their data at all.
Signed-off-by: Petr Vandrovec
Signed-off-by: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/2ce30a44349065b70d0f00e71e286dc0cbe745e6.1505459652.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
---
tools/objtool/elf.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 1e89a5f..b4cd8bc 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
- sec->data = elf_getdata(s, NULL);
- if (!sec->data) {
- WARN_ELF("elf_getdata");
- return -1;
- }
-
- if (sec->data->d_off != 0 ||
- sec->data->d_size != sec->sh.sh_size) {
- WARN("unexpected data attributes for %s", sec->name);
- return -1;
+ if (sec->sh.sh_size != 0) {
+ sec->data = elf_getdata(s, NULL);
+ if (!sec->data) {
+ WARN_ELF("elf_getdata");
+ return -1;
+ }
+ if (sec->data->d_off != 0 ||
+ sec->data->d_size != sec->sh.sh_size) {
+ WARN("unexpected data attributes for %s",
+sec->name);
+ return -1;
+ }
}
-
- sec->len = sec->data->d_size;
+ sec->len = sec->sh.sh_size;
}
/* sanity check, one more call to elf_nextscn() should return NULL */
[tip:core/urgent] objtool: Do not retrieve data from empty sections
Commit-ID: 7156b7141a037420a3cd99dbc1559e0235f57c07
Gitweb: http://git.kernel.org/tip/7156b7141a037420a3cd99dbc1559e0235f57c07
Author: Petr Vandrovec <p...@vandrovec.name>
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 15 Sep 2017 10:30:31 +0200
objtool: Do not retrieve data from empty sections
Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:
elf_getdata: can't manipulate null section
As nothing is done with sections that have zero size, just do not
retrieve their data at all.
Signed-off-by: Petr Vandrovec <p...@vandrovec.name>
Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>
Reviewed-by: Don Zickus <dzic...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link:
http://lkml.kernel.org/r/2ce30a44349065b70d0f00e71e286dc0cbe745e6.1505459652.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
tools/objtool/elf.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 1e89a5f..b4cd8bc 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
- sec->data = elf_getdata(s, NULL);
- if (!sec->data) {
- WARN_ELF("elf_getdata");
- return -1;
- }
-
- if (sec->data->d_off != 0 ||
- sec->data->d_size != sec->sh.sh_size) {
- WARN("unexpected data attributes for %s", sec->name);
- return -1;
+ if (sec->sh.sh_size != 0) {
+ sec->data = elf_getdata(s, NULL);
+ if (!sec->data) {
+ WARN_ELF("elf_getdata");
+ return -1;
+ }
+ if (sec->data->d_off != 0 ||
+ sec->data->d_size != sec->sh.sh_size) {
+ WARN("unexpected data attributes for %s",
+sec->name);
+ return -1;
+ }
}
-
- sec->len = sec->data->d_size;
+ sec->len = sec->sh.sh_size;
}
/* sanity check, one more call to elf_nextscn() should return NULL */
[tip:core/urgent] objtool: Do not retrieve data from empty sections
Commit-ID: 7156b7141a037420a3cd99dbc1559e0235f57c07
Gitweb: http://git.kernel.org/tip/7156b7141a037420a3cd99dbc1559e0235f57c07
Author: Petr Vandrovec
AuthorDate: Fri, 15 Sep 2017 02:15:05 -0500
Committer: Ingo Molnar
CommitDate: Fri, 15 Sep 2017 10:30:31 +0200
objtool: Do not retrieve data from empty sections
Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:
elf_getdata: can't manipulate null section
As nothing is done with sections that have zero size, just do not
retrieve their data at all.
Signed-off-by: Petr Vandrovec
Signed-off-by: Josh Poimboeuf
Reviewed-by: Don Zickus
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/2ce30a44349065b70d0f00e71e286dc0cbe745e6.1505459652.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
---
tools/objtool/elf.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 1e89a5f..b4cd8bc 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
- sec->data = elf_getdata(s, NULL);
- if (!sec->data) {
- WARN_ELF("elf_getdata");
- return -1;
- }
-
- if (sec->data->d_off != 0 ||
- sec->data->d_size != sec->sh.sh_size) {
- WARN("unexpected data attributes for %s", sec->name);
- return -1;
+ if (sec->sh.sh_size != 0) {
+ sec->data = elf_getdata(s, NULL);
+ if (!sec->data) {
+ WARN_ELF("elf_getdata");
+ return -1;
+ }
+ if (sec->data->d_off != 0 ||
+ sec->data->d_size != sec->sh.sh_size) {
+ WARN("unexpected data attributes for %s",
+sec->name);
+ return -1;
+ }
}
-
- sec->len = sec->data->d_size;
+ sec->len = sec->sh.sh_size;
}
/* sanity check, one more call to elf_nextscn() should return NULL */
[PATCH] objtool: Do not retrieve data from empty sections
From: Petr Vandrovec <p...@vandrovec.name>
Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:
elf_getdata: can't manipulate null section
As nothing is done with sections that have zero size, just do not
retrieve their data at all.
Signed-off-by: Petr Vandrovec <p...@vandrovec.name>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
---
tools/objtool/elf.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 6e9f980a7d26..99eccd23023d 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
- sec->data = elf_getdata(s, NULL);
- if (!sec->data) {
- WARN_ELF("elf_getdata");
- return -1;
- }
-
- if (sec->data->d_off != 0 ||
- sec->data->d_size != sec->sh.sh_size) {
- WARN("unexpected data attributes for %s", sec->name);
- return -1;
+ if (sec->sh.sh_size != 0) {
+ sec->data = elf_getdata(s, NULL);
+ if (!sec->data) {
+ WARN_ELF("elf_getdata");
+ return -1;
+ }
+ if (sec->data->d_off != 0 ||
+ sec->data->d_size != sec->sh.sh_size) {
+ WARN("unexpected data attributes for %s",
+sec->name);
+ return -1;
+ }
}
-
- sec->len = sec->data->d_size;
+ sec->len = sec->sh.sh_size;
}
/* sanity check, one more call to elf_nextscn() should return NULL */
--
2.14.1
[PATCH] objtool: Do not retrieve data from empty sections
From: Petr Vandrovec
Binutils 2.29-9 in Debian return an error when elf_getdata is invoked
on empty section (.note.GNU-stack in all kernel files), causing
immediate failure of kernel build with:
elf_getdata: can't manipulate null section
As nothing is done with sections that have zero size, just do not
retrieve their data at all.
Signed-off-by: Petr Vandrovec
Cc: Josh Poimboeuf
---
tools/objtool/elf.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 6e9f980a7d26..99eccd23023d 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -175,19 +175,20 @@ static int read_sections(struct elf *elf)
return -1;
}
- sec->data = elf_getdata(s, NULL);
- if (!sec->data) {
- WARN_ELF("elf_getdata");
- return -1;
- }
-
- if (sec->data->d_off != 0 ||
- sec->data->d_size != sec->sh.sh_size) {
- WARN("unexpected data attributes for %s", sec->name);
- return -1;
+ if (sec->sh.sh_size != 0) {
+ sec->data = elf_getdata(s, NULL);
+ if (!sec->data) {
+ WARN_ELF("elf_getdata");
+ return -1;
+ }
+ if (sec->data->d_off != 0 ||
+ sec->data->d_size != sec->sh.sh_size) {
+ WARN("unexpected data attributes for %s",
+sec->name);
+ return -1;
+ }
}
-
- sec->len = sec->data->d_size;
+ sec->len = sec->sh.sh_size;
}
/* sanity check, one more call to elf_nextscn() should return NULL */
--
2.14.1
[PATCH] vmw_vmci: Fix irq allocation
From: Petr Vandrovec <p...@vmware.com>
Change 3bb434 (vmw_vmci: switch to pci_irq_alloc_vectors) converted
vmw_vmci to use pci_irq_alloc_vectors. Unfortunately for the code
pci_irq_alloc_vectors returns number of allocated vectors on success,
rather than zero. So successful allocation was always treated as
an error, causing slew of warning messages, and then error that
device probe method returned unexpected value 2.
Checking that error is < 0 fixes problem.
While I was there, I've simplified allocation to do just one
pci_irq_alloc_vectors call: VMCI device currently supports only
two MSI-X vectors, so we either get two dedicated vectors, or
one shared vector. Nothing else can happen. So we can ask
for minimum=1, maximum=2, MSI-X | MSI | Legacy, and get back
best possible choice.
Signed-off-by: Petr Vandrovec <p...@vmware.com>
Cc: Christoph Hellwig <h...@lst.de>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Fixes: 3bb434cdcc6a ("vmw_vmci: switch to pci_irq_alloc_vectors")
---
drivers/misc/vmw_vmci/vmci_guest.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index 9d659542a335..6aea073841c8 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -464,7 +464,6 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
}
vmci_dev->dev = >dev;
- vmci_dev->exclusive_vectors = false;
vmci_dev->iobase = iobase;
tasklet_init(_dev->datagram_tasklet,
@@ -564,16 +563,11 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* Enable interrupts. Try MSI-X first, then MSI, and then fallback on
* legacy interrupts.
*/
- error = pci_alloc_irq_vectors(pdev, VMCI_MAX_INTRS, VMCI_MAX_INTRS,
- PCI_IRQ_MSIX);
- if (error) {
- error = pci_alloc_irq_vectors(pdev, 1, 1,
- PCI_IRQ_MSIX | PCI_IRQ_MSI | PCI_IRQ_LEGACY);
- if (error)
- goto err_remove_bitmap;
- } else {
- vmci_dev->exclusive_vectors = true;
- }
+ error = pci_alloc_irq_vectors(pdev, 1, VMCI_MAX_INTRS,
+ PCI_IRQ_MSIX | PCI_IRQ_MSI | PCI_IRQ_LEGACY);
+ if (error < 0)
+ goto err_remove_bitmap;
+ vmci_dev->exclusive_vectors = error == VMCI_MAX_INTRS;
/*
* Request IRQ for legacy or MSI interrupts, or for first
--
2.11.0
[PATCH] vmw_vmci: Fix irq allocation
From: Petr Vandrovec
Change 3bb434 (vmw_vmci: switch to pci_irq_alloc_vectors) converted
vmw_vmci to use pci_irq_alloc_vectors. Unfortunately for the code
pci_irq_alloc_vectors returns number of allocated vectors on success,
rather than zero. So successful allocation was always treated as
an error, causing slew of warning messages, and then error that
device probe method returned unexpected value 2.
Checking that error is < 0 fixes problem.
While I was there, I've simplified allocation to do just one
pci_irq_alloc_vectors call: VMCI device currently supports only
two MSI-X vectors, so we either get two dedicated vectors, or
one shared vector. Nothing else can happen. So we can ask
for minimum=1, maximum=2, MSI-X | MSI | Legacy, and get back
best possible choice.
Signed-off-by: Petr Vandrovec
Cc: Christoph Hellwig
Cc: Greg Kroah-Hartman
Fixes: 3bb434cdcc6a ("vmw_vmci: switch to pci_irq_alloc_vectors")
---
drivers/misc/vmw_vmci/vmci_guest.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index 9d659542a335..6aea073841c8 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -464,7 +464,6 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
}
vmci_dev->dev = >dev;
- vmci_dev->exclusive_vectors = false;
vmci_dev->iobase = iobase;
tasklet_init(_dev->datagram_tasklet,
@@ -564,16 +563,11 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
* Enable interrupts. Try MSI-X first, then MSI, and then fallback on
* legacy interrupts.
*/
- error = pci_alloc_irq_vectors(pdev, VMCI_MAX_INTRS, VMCI_MAX_INTRS,
- PCI_IRQ_MSIX);
- if (error) {
- error = pci_alloc_irq_vectors(pdev, 1, 1,
- PCI_IRQ_MSIX | PCI_IRQ_MSI | PCI_IRQ_LEGACY);
- if (error)
- goto err_remove_bitmap;
- } else {
- vmci_dev->exclusive_vectors = true;
- }
+ error = pci_alloc_irq_vectors(pdev, 1, VMCI_MAX_INTRS,
+ PCI_IRQ_MSIX | PCI_IRQ_MSI | PCI_IRQ_LEGACY);
+ if (error < 0)
+ goto err_remove_bitmap;
+ vmci_dev->exclusive_vectors = error == VMCI_MAX_INTRS;
/*
* Request IRQ for legacy or MSI interrupts, or for first
--
2.11.0
Re: [PATCH] Do not silently discard WRITE_SAME requests
On 10/14/2014 5:57 PM, Martin K. Petersen wrote:
"Petr" == Petr Vandrovec writes:
Petr,
Petr> Logic (from 2011, commit 8af1954d172a46a63e5e79dae523a6d74715e458)
Petr> says that EOPNOTSUPP is returned when DISCARD request failed, as
Petr> discarding is optional, and failures can be safely ignored. That
Petr> is definitely not true for WRITE_SAME failures, and so unsupported
Petr> WRITE_SAME should return different error code than unsupported
Petr> DISCARD.
I agree. With Lukas' change the bio batch error handling is too
permissive for the write same case. It also made the regular zeroout
error handling case a bit fishy but it is unlikely that we'd get
EOPNOTSUPP on a regular write.
So for the block portion:
Acked-by: Martin K. Petersen
Cc: sta...@vger.kernel.org # 3.7+
Petr> revert of blacklisting VMware's LSI (if anything, blacklist should
Petr> be for current firmware version of 'VMware Virtual SCSI Disk', as
Petr> f.e. passed-through (RDM) SCSI disks do support WRITE_SAME under
Petr> VMware) -- see attached updated diff.
If you have a better heuristic then let's by all means use it. Please
adjust the pattern matching strings to match the actual values returned
by the target.
SCSI: Only blacklist WRITE SAME for VMware virtual disks
Commit 4089b71cc820 blacklisted WRITE SAME for all VMware disks.
However, the WRITE SAME commands are supported for passthrough
disks. Change the heuristic so we only blacklist virtual disks.
Hi,
is there any reason to do blacklisting? Why not let first request
fail, and switch to non-write-same code path once that happens?
If you want to go ahead with blacklisting, then entries should be:
{ "VMware", "Virtual disk", "1.0", BLIST_NO_WRITE_SAME }, //ESX
{ "VMware,", "VMware Virtual S", "1.0", BLIST_NO_WRITE_SAME }, //WS,Fusion
(yes, on Workstation and Fusion there is really comma in the vendor name
and VMware is repeated in the device ID - first is 'VMware, Inc.'
truncated to 8 characters, and second is 'VMware Virtual SCSI Hard
Drive' truncated to 16; we got revision right...)
Thanks,
Petr
Signed-off-by: Martin K. Petersen
Reported-by: Petr Vandrovec
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 613231c16194..787933d43d32 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1419,11 +1419,6 @@ mptspi_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto out_mptspi_probe;
}
- /* VMWare emulation doesn't properly implement WRITE_SAME
-*/
- if (pdev->subsystem_vendor == 0x15AD)
- sh->no_write_same = 1;
-
spin_lock_irqsave(>FreeQlock, flags);
/* Attach the SCSI Host to the IOC structure
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 49014a143c6a..402aebfb97dd 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -249,6 +249,7 @@ static struct {
{"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM},
{"Traxdata", "CDR4120", NULL, BLIST_NOLUN}, /* locks up */
{"USB2.0", "SMARTMEDIA/XD", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {"VMware", "Virtual SCSI Disk", NULL, BLIST_NO_WRITE_SAME},
{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
{"WangDAT", "Model 1300", "02.4", BLIST_SELECT_NO_ATN},
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index ba3f1e8d0d57..c57daffe57af 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -955,6 +955,9 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
if (*bflags & BLIST_NO_DIF)
sdev->no_dif = 1;
+ if (*bflags & BLIST_NO_WRITE_SAME)
+ sdev->no_write_same = 1;
+
sdev->eh_timeout = SCSI_DEFAULT_EH_TIMEOUT;
if (*bflags & BLIST_TRY_VPD_PAGES)
diff --git a/include/scsi/scsi_devinfo.h b/include/scsi/scsi_devinfo.h
index 183eaab7c380..1a24efb4b1d6 100644
--- a/include/scsi/scsi_devinfo.h
+++ b/include/scsi/scsi_devinfo.h
@@ -36,5 +36,6 @@
for sequential scan */
#define BLIST_TRY_VPD_PAGES 0x1000 /* Attempt to read VPD pages */
#define BLIST_NO_RSOC 0x2000 /* don't try to issue RSOC */
+#define BLIST_NO_WRITE_SAME0x4000 /* don't try to issue WRITE SAME */
#endif
--
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] Do not silently discard WRITE_SAME requests
On 10/14/2014 5:57 PM, Martin K. Petersen wrote:
Petr == Petr Vandrovec p...@vmware.com writes:
Petr,
Petr Logic (from 2011, commit 8af1954d172a46a63e5e79dae523a6d74715e458)
Petr says that EOPNOTSUPP is returned when DISCARD request failed, as
Petr discarding is optional, and failures can be safely ignored. That
Petr is definitely not true for WRITE_SAME failures, and so unsupported
Petr WRITE_SAME should return different error code than unsupported
Petr DISCARD.
I agree. With Lukas' change the bio batch error handling is too
permissive for the write same case. It also made the regular zeroout
error handling case a bit fishy but it is unlikely that we'd get
EOPNOTSUPP on a regular write.
So for the block portion:
Acked-by: Martin K. Petersen martin.peter...@oracle.com
Cc: sta...@vger.kernel.org # 3.7+
Petr revert of blacklisting VMware's LSI (if anything, blacklist should
Petr be for current firmware version of 'VMware Virtual SCSI Disk', as
Petr f.e. passed-through (RDM) SCSI disks do support WRITE_SAME under
Petr VMware) -- see attached updated diff.
If you have a better heuristic then let's by all means use it. Please
adjust the pattern matching strings to match the actual values returned
by the target.
SCSI: Only blacklist WRITE SAME for VMware virtual disks
Commit 4089b71cc820 blacklisted WRITE SAME for all VMware disks.
However, the WRITE SAME commands are supported for passthrough
disks. Change the heuristic so we only blacklist virtual disks.
Hi,
is there any reason to do blacklisting? Why not let first request
fail, and switch to non-write-same code path once that happens?
If you want to go ahead with blacklisting, then entries should be:
{ VMware, Virtual disk, 1.0, BLIST_NO_WRITE_SAME }, //ESX
{ VMware,, VMware Virtual S, 1.0, BLIST_NO_WRITE_SAME }, //WS,Fusion
(yes, on Workstation and Fusion there is really comma in the vendor name
and VMware is repeated in the device ID - first is 'VMware, Inc.'
truncated to 8 characters, and second is 'VMware Virtual SCSI Hard
Drive' truncated to 16; we got revision right...)
Thanks,
Petr
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
Reported-by: Petr Vandrovec p...@vmware.com
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 613231c16194..787933d43d32 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1419,11 +1419,6 @@ mptspi_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto out_mptspi_probe;
}
- /* VMWare emulation doesn't properly implement WRITE_SAME
-*/
- if (pdev-subsystem_vendor == 0x15AD)
- sh-no_write_same = 1;
-
spin_lock_irqsave(ioc-FreeQlock, flags);
/* Attach the SCSI Host to the IOC structure
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 49014a143c6a..402aebfb97dd 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -249,6 +249,7 @@ static struct {
{TOSHIBA, CD-ROM, NULL, BLIST_ISROM},
{Traxdata, CDR4120, NULL, BLIST_NOLUN}, /* locks up */
{USB2.0, SMARTMEDIA/XD, NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ {VMware, Virtual SCSI Disk, NULL, BLIST_NO_WRITE_SAME},
{WangDAT, Model 2600, 01.7, BLIST_SELECT_NO_ATN},
{WangDAT, Model 3200, 02.2, BLIST_SELECT_NO_ATN},
{WangDAT, Model 1300, 02.4, BLIST_SELECT_NO_ATN},
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index ba3f1e8d0d57..c57daffe57af 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -955,6 +955,9 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
if (*bflags BLIST_NO_DIF)
sdev-no_dif = 1;
+ if (*bflags BLIST_NO_WRITE_SAME)
+ sdev-no_write_same = 1;
+
sdev-eh_timeout = SCSI_DEFAULT_EH_TIMEOUT;
if (*bflags BLIST_TRY_VPD_PAGES)
diff --git a/include/scsi/scsi_devinfo.h b/include/scsi/scsi_devinfo.h
index 183eaab7c380..1a24efb4b1d6 100644
--- a/include/scsi/scsi_devinfo.h
+++ b/include/scsi/scsi_devinfo.h
@@ -36,5 +36,6 @@
for sequential scan */
#define BLIST_TRY_VPD_PAGES 0x1000 /* Attempt to read VPD pages */
#define BLIST_NO_RSOC 0x2000 /* don't try to issue RSOC */
+#define BLIST_NO_WRITE_SAME0x4000 /* don't try to issue WRITE SAME */
#endif
--
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] Do not silently discard WRITE_SAME requests
On 10/11/2014 5:51 AM, Martin K. Petersen wrote:
"Petr" == Petr Vandrovec writes:
Petr> After investigating, problem seems to be in a way completion
Petr> handler for WRITE_SAME handles EOPNOTSUPP error, causing
Petr> all-but-first WRITE_SAME request on the LVM device to be silently
Petr> ignored - command is never issued, but success is returned to
Petr> higher layers.
Commit 7eee4ae2dbb2 was meant to address this issue. Does it still
happen with that in place?
Hi,
that commit alleviates need for change to blk-lib.c. But I believe
that change to blk-core.c that changes return value from EOPNOTSUPP to
EREMOTEIO is still necessary - unless I'm missing some locking
somewhere, there is a race in blkdev_issue_write_same() wrt. updating
max_write_same_sectors:
blkdev_issue_write_same() checks whether max_write_same_sectors is
non-zero at the beginning, and if it is non-zero it proceeds with
generating BIOs. While it generates them, other thread seems to be able
to complete previously issued write_same, find it is not supported, and
clear max_write_same_sectors. Which means that BIOs that are now being
generated will fast-fail in blk-core.c with EOPNOTSUPP, and
blkdev_issue_write_same() will then return success, rather than failure.
It is true that now WRITE_SAME is failing only if second WRITE_SAME is
issued to the device while first ever issued WRITE_SAME on the device is
being completed, but I see no reason why to not close this race.
Logic (from 2011, commit 8af1954d172a46a63e5e79dae523a6d74715e458) says
that EOPNOTSUPP is returned when DISCARD request failed, as discarding
is optional, and failures can be safely ignored. That is definitely not
true for WRITE_SAME failures, and so unsupported WRITE_SAME should
return different error code than unsupported DISCARD.
Which is what patch does. I've removed part that propagates disabling
WRITE_SAME from the diff, keeping only EOPNOTSUPP => EREMOTEIO change,
and revert of blacklisting VMware's LSI (if anything, blacklist should
be for current firmware version of 'VMware Virtual SCSI Disk', as f.e.
passed-through (RDM) SCSI disks do support WRITE_SAME under VMware) --
see attached updated diff.
Petr Vandrovec
>From 975c1f8be719bb297de4bbf704cc5a58edee62b6 Mon Sep 17 00:00:00 2001
From: Petr Vandrovec
Date: Fri, 10 Oct 2014 23:10:25 -0700
Subject: [PATCH] Do not silently discard WRITE_SAME requests
When device does not support WRITE_SAME, after first failure
block layer starts throwing away WRITE_SAME requests without
warning anybody, leading to the data corruption.
Let's do something about it - do not use EOPNOTSUPP error,
as that error code is special, reserved for DISCARD, and
return EREMOTEIO, AKA target failure, like when request
hits hardware..
It also reverts 4089b71cc820a426d601283c92fcd4ffeb5139c2, as
there is nothing wrong with VMware's WRITE_SAME emulation.
Only problem was that block layer did not issue WRITE_SAME
request at all, but reported success, and it affected all
disks that do not support WRITE_SAME.
Signed-off-by: Petr Vandrovec
Cc: Arvind Kumar
Cc: Chris J Arges
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: sta...@vger.kernel.org
---
block/blk-core.c| 2 +-
drivers/message/fusion/mptspi.c | 5 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 9c888bd..b070782 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1822,7 +1822,7 @@ generic_make_request_checks(struct bio *bio)
}
if (bio->bi_rw & REQ_WRITE_SAME && !bdev_write_same(bio->bi_bdev)) {
- err = -EOPNOTSUPP;
+ err = -EREMOTEIO;
goto end_io;
}
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 613231c..787933d 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1419,11 +1419,6 @@ mptspi_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto out_mptspi_probe;
}
- /* VMWare emulation doesn't properly implement WRITE_SAME
-*/
- if (pdev->subsystem_vendor == 0x15AD)
- sh->no_write_same = 1;
-
spin_lock_irqsave(>FreeQlock, flags);
/* Attach the SCSI Host to the IOC structure
--
2.1.1
Re: [PATCH] Do not silently discard WRITE_SAME requests
On 10/11/2014 5:51 AM, Martin K. Petersen wrote:
Petr == Petr Vandrovec p...@vmware.com writes:
Petr After investigating, problem seems to be in a way completion
Petr handler for WRITE_SAME handles EOPNOTSUPP error, causing
Petr all-but-first WRITE_SAME request on the LVM device to be silently
Petr ignored - command is never issued, but success is returned to
Petr higher layers.
Commit 7eee4ae2dbb2 was meant to address this issue. Does it still
happen with that in place?
Hi,
that commit alleviates need for change to blk-lib.c. But I believe
that change to blk-core.c that changes return value from EOPNOTSUPP to
EREMOTEIO is still necessary - unless I'm missing some locking
somewhere, there is a race in blkdev_issue_write_same() wrt. updating
max_write_same_sectors:
blkdev_issue_write_same() checks whether max_write_same_sectors is
non-zero at the beginning, and if it is non-zero it proceeds with
generating BIOs. While it generates them, other thread seems to be able
to complete previously issued write_same, find it is not supported, and
clear max_write_same_sectors. Which means that BIOs that are now being
generated will fast-fail in blk-core.c with EOPNOTSUPP, and
blkdev_issue_write_same() will then return success, rather than failure.
It is true that now WRITE_SAME is failing only if second WRITE_SAME is
issued to the device while first ever issued WRITE_SAME on the device is
being completed, but I see no reason why to not close this race.
Logic (from 2011, commit 8af1954d172a46a63e5e79dae523a6d74715e458) says
that EOPNOTSUPP is returned when DISCARD request failed, as discarding
is optional, and failures can be safely ignored. That is definitely not
true for WRITE_SAME failures, and so unsupported WRITE_SAME should
return different error code than unsupported DISCARD.
Which is what patch does. I've removed part that propagates disabling
WRITE_SAME from the diff, keeping only EOPNOTSUPP = EREMOTEIO change,
and revert of blacklisting VMware's LSI (if anything, blacklist should
be for current firmware version of 'VMware Virtual SCSI Disk', as f.e.
passed-through (RDM) SCSI disks do support WRITE_SAME under VMware) --
see attached updated diff.
Petr Vandrovec
From 975c1f8be719bb297de4bbf704cc5a58edee62b6 Mon Sep 17 00:00:00 2001
From: Petr Vandrovec p...@vandrovec.name
Date: Fri, 10 Oct 2014 23:10:25 -0700
Subject: [PATCH] Do not silently discard WRITE_SAME requests
When device does not support WRITE_SAME, after first failure
block layer starts throwing away WRITE_SAME requests without
warning anybody, leading to the data corruption.
Let's do something about it - do not use EOPNOTSUPP error,
as that error code is special, reserved for DISCARD, and
return EREMOTEIO, AKA target failure, like when request
hits hardware..
It also reverts 4089b71cc820a426d601283c92fcd4ffeb5139c2, as
there is nothing wrong with VMware's WRITE_SAME emulation.
Only problem was that block layer did not issue WRITE_SAME
request at all, but reported success, and it affected all
disks that do not support WRITE_SAME.
Signed-off-by: Petr Vandrovec p...@vmware.com
Cc: Arvind Kumar arvindku...@vmware.com
Cc: Chris J Arges chris.j.ar...@canonical.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: sta...@vger.kernel.org
---
block/blk-core.c| 2 +-
drivers/message/fusion/mptspi.c | 5 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 9c888bd..b070782 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1822,7 +1822,7 @@ generic_make_request_checks(struct bio *bio)
}
if (bio-bi_rw REQ_WRITE_SAME !bdev_write_same(bio-bi_bdev)) {
- err = -EOPNOTSUPP;
+ err = -EREMOTEIO;
goto end_io;
}
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 613231c..787933d 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1419,11 +1419,6 @@ mptspi_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto out_mptspi_probe;
}
- /* VMWare emulation doesn't properly implement WRITE_SAME
-*/
- if (pdev-subsystem_vendor == 0x15AD)
- sh-no_write_same = 1;
-
spin_lock_irqsave(ioc-FreeQlock, flags);
/* Attach the SCSI Host to the IOC structure
--
2.1.1
[PATCH] Do not silently discard WRITE_SAME requests
Hi,
it was brought to my attention that there are claims of data corruption
caused by VMware's SCSI implementation. After investigating, problem
seems to be in a way completion handler for WRITE_SAME handles EOPNOTSUPP
error, causing all-but-first WRITE_SAME request on the LVM device to be
silently ignored - command is never issued, but success is returned to
higher layers. Problem affects all disks without WRITE_SAME support -
and I guess VMware's SCSI emulation is one of few that do not support
this command ATM.
Please apply patch below.
Thanks,
Petr Vandrovec
From: Petr Vandrovec
Subject: [PATCH] Do not silently discard WRITE_SAME requests
When device does not support WRITE_SAME, after first failure
block layer starts throwing away WRITE_SAME requests without
warning anybody, leading to the data corruption.
Let's do something about it - do not use EOPNOTSUPP error,
as apparently that error code is special (use EREMOTEIO, AKA
target failure, like when request hits hardware), and propagate
inabiity to do WRITE_SAME to the top of stack, so we do not
try to issue WRITE_SAME again and again.
It also reverts 4089b71cc820a426d601283c92fcd4ffeb5139c2, as
there is nothing wrong with VMware's WRITE_SAME emulation.
Only problem was that block layer did not issue WRITE_SAME
request at all, but reported success, and it affected all
disks that do not support WRITE_SAME.
Signed-off-by: Petr Vandrovec
Cc: Arvind Kumar
Cc: Chris J Arges
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: sta...@vger.kernel.org
---
block/blk-core.c| 2 +-
block/blk-lib.c | 10 ++
drivers/message/fusion/mptspi.c | 5 -
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 9c888bd..b070782 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1822,7 +1822,7 @@ generic_make_request_checks(struct bio *bio)
}
if (bio->bi_rw & REQ_WRITE_SAME && !bdev_write_same(bio->bi_bdev)) {
- err = -EOPNOTSUPP;
+ err = -EREMOTEIO;
goto end_io;
}
diff --git a/block/blk-lib.c b/block/blk-lib.c
index 8411be3..abad72d 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -298,6 +298,16 @@ int blkdev_issue_zeroout(struct block_device *bdev,
sector_t sector,
ZERO_PAGE(0)))
return 0;
+ /*
+* If WRITE_SAME failed, inability to perform WRITE_SAME was
+* possibly recorded in device's queue by sd.c. But in case
+* of LVM we are issuing request here on LVM device. So
+* we should mark device as ineligible for WRITE_SAME here too,
+* as otherwise we keep trying to submit WRITE_SAME again and
+* again to LVM where they get promptly rejected by underlying
+* disk queue.
+*/
+ blk_queue_max_write_same_sectors(bdev_get_queue(bdev), 0);
bdevname(bdev, bdn);
pr_err("%s: WRITE SAME failed. Manually zeroing.\n", bdn);
}
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 613231c..787933d 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1419,11 +1419,6 @@ mptspi_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto out_mptspi_probe;
}
- /* VMWare emulation doesn't properly implement WRITE_SAME
-*/
- if (pdev->subsystem_vendor == 0x15AD)
- sh->no_write_same = 1;
-
spin_lock_irqsave(>FreeQlock, flags);
/* Attach the SCSI Host to the IOC structure
--
2.1.1
--
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/
[PATCH] Do not silently discard WRITE_SAME requests
Hi,
it was brought to my attention that there are claims of data corruption
caused by VMware's SCSI implementation. After investigating, problem
seems to be in a way completion handler for WRITE_SAME handles EOPNOTSUPP
error, causing all-but-first WRITE_SAME request on the LVM device to be
silently ignored - command is never issued, but success is returned to
higher layers. Problem affects all disks without WRITE_SAME support -
and I guess VMware's SCSI emulation is one of few that do not support
this command ATM.
Please apply patch below.
Thanks,
Petr Vandrovec
From: Petr Vandrovec p...@vmware.com
Subject: [PATCH] Do not silently discard WRITE_SAME requests
When device does not support WRITE_SAME, after first failure
block layer starts throwing away WRITE_SAME requests without
warning anybody, leading to the data corruption.
Let's do something about it - do not use EOPNOTSUPP error,
as apparently that error code is special (use EREMOTEIO, AKA
target failure, like when request hits hardware), and propagate
inabiity to do WRITE_SAME to the top of stack, so we do not
try to issue WRITE_SAME again and again.
It also reverts 4089b71cc820a426d601283c92fcd4ffeb5139c2, as
there is nothing wrong with VMware's WRITE_SAME emulation.
Only problem was that block layer did not issue WRITE_SAME
request at all, but reported success, and it affected all
disks that do not support WRITE_SAME.
Signed-off-by: Petr Vandrovec p...@vmware.com
Cc: Arvind Kumar arvindku...@vmware.com
Cc: Chris J Arges chris.j.ar...@canonical.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: sta...@vger.kernel.org
---
block/blk-core.c| 2 +-
block/blk-lib.c | 10 ++
drivers/message/fusion/mptspi.c | 5 -
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 9c888bd..b070782 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1822,7 +1822,7 @@ generic_make_request_checks(struct bio *bio)
}
if (bio-bi_rw REQ_WRITE_SAME !bdev_write_same(bio-bi_bdev)) {
- err = -EOPNOTSUPP;
+ err = -EREMOTEIO;
goto end_io;
}
diff --git a/block/blk-lib.c b/block/blk-lib.c
index 8411be3..abad72d 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -298,6 +298,16 @@ int blkdev_issue_zeroout(struct block_device *bdev,
sector_t sector,
ZERO_PAGE(0)))
return 0;
+ /*
+* If WRITE_SAME failed, inability to perform WRITE_SAME was
+* possibly recorded in device's queue by sd.c. But in case
+* of LVM we are issuing request here on LVM device. So
+* we should mark device as ineligible for WRITE_SAME here too,
+* as otherwise we keep trying to submit WRITE_SAME again and
+* again to LVM where they get promptly rejected by underlying
+* disk queue.
+*/
+ blk_queue_max_write_same_sectors(bdev_get_queue(bdev), 0);
bdevname(bdev, bdn);
pr_err(%s: WRITE SAME failed. Manually zeroing.\n, bdn);
}
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 613231c..787933d 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1419,11 +1419,6 @@ mptspi_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto out_mptspi_probe;
}
- /* VMWare emulation doesn't properly implement WRITE_SAME
-*/
- if (pdev-subsystem_vendor == 0x15AD)
- sh-no_write_same = 1;
-
spin_lock_irqsave(ioc-FreeQlock, flags);
/* Attach the SCSI Host to the IOC structure
--
2.1.1
--
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] ncpfs: fix rmdir returns Device or resource busy
On Wed, Jun 5, 2013 at 1:20 PM, Dave Chiluk wrote:
> Petr do you still have commit rights to ncpfs? Can you please commit it
> to upstream or do I have to get Al to do that?
Hi,
only thing I can do is to add
Signed-off-by: Petr Vandrovec
on your patch and forward it to Al. Unfortunately patch below is
already whitespace-damaged :-( So you can either send it to me, and
I'll resend it to Al, or you can do that directly...
Petr
> Dave.
>
>
> On 05/31/2013 05:22 PM, Petr Vandrovec wrote:
>> Looks OK to me.
>>
>> As I said elsewhere, I do not use ncpfs for years so I cannot provide
>> any sensible maintainership for it anymore :-(
>>
>> Petr
>>
>> On May 31, 2013 2:40 PM, "Dave Chiluk" > <mailto:chi...@canonical.com>> wrote:
>>
>> Any thoughts on this? NCPFS seems to be the forgotten, left-behind,
>> red-headed stepchild of the fs community.
>>
>> Dave.
>>
>> On 05/28/2013 05:50 PM, Dave Chiluk wrote:
>> > 1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in
>> ncpfs such that
>> > directories could no longer be removed. This was because
>> ncp_rmdir checked
>> > to see if a dentry could be unhashed before allowing it to be
>> removed. Since
>> > 1d2ef5901483004d74947bbf78d5146c24038fe7 introduced a change that
>> incremented
>> > dentry->d_count causing it to always be greater than 1 unhash
>> would always
>> > fail. Thus causing the error path in ncp_rmdir to always be
>> taken. Removing
>> > this error path is safe as unhashing is still accomplished by
>> calls to dput
>> > from vfs_rmdir.
>> > ---
>> > fs/ncpfs/dir.c |9 -
>> > 1 file changed, 9 deletions(-)
>> >
>> > diff --git a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c
>> > index 8163260..6792ce1 100644
>> > --- a/fs/ncpfs/dir.c
>> > +++ b/fs/ncpfs/dir.c
>> > @@ -1029,15 +1029,6 @@ static int ncp_rmdir(struct inode *dir,
>> struct dentry *dentry)
>> > DPRINTK("ncp_rmdir: removing %s/%s\n",
>> > dentry->d_parent->d_name.name <http://d_name.name>,
>> dentry->d_name.name <http://d_name.name>);
>> >
>> > - /*
>> > - * fail with EBUSY if there are still references to this
>> > - * directory.
>> > - */
>> > - dentry_unhash(dentry);
>> > - error = -EBUSY;
>> > - if (!d_unhashed(dentry))
>> > - goto out;
>> > -
>> > len = sizeof(__name);
>> > error = ncp_io2vol(server, __name, , dentry->d_name.name
>> <http://d_name.name>,
>> > dentry->d_name.len, !ncp_preserve_case(dir));
>> >
>>
>
--
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] ncpfs: fix rmdir returns Device or resource busy
On Wed, Jun 5, 2013 at 1:20 PM, Dave Chiluk chi...@canonical.com wrote: Petr do you still have commit rights to ncpfs? Can you please commit it to upstream or do I have to get Al to do that? Hi, only thing I can do is to add Signed-off-by: Petr Vandrovec p...@vandrovec.name on your patch and forward it to Al. Unfortunately patch below is already whitespace-damaged :-( So you can either send it to me, and I'll resend it to Al, or you can do that directly... Petr Dave. On 05/31/2013 05:22 PM, Petr Vandrovec wrote: Looks OK to me. As I said elsewhere, I do not use ncpfs for years so I cannot provide any sensible maintainership for it anymore :-( Petr On May 31, 2013 2:40 PM, Dave Chiluk chi...@canonical.com mailto:chi...@canonical.com wrote: Any thoughts on this? NCPFS seems to be the forgotten, left-behind, red-headed stepchild of the fs community. Dave. On 05/28/2013 05:50 PM, Dave Chiluk wrote: 1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such that directories could no longer be removed. This was because ncp_rmdir checked to see if a dentry could be unhashed before allowing it to be removed. Since 1d2ef5901483004d74947bbf78d5146c24038fe7 introduced a change that incremented dentry-d_count causing it to always be greater than 1 unhash would always fail. Thus causing the error path in ncp_rmdir to always be taken. Removing this error path is safe as unhashing is still accomplished by calls to dput from vfs_rmdir. --- fs/ncpfs/dir.c |9 - 1 file changed, 9 deletions(-) diff --git a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c index 8163260..6792ce1 100644 --- a/fs/ncpfs/dir.c +++ b/fs/ncpfs/dir.c @@ -1029,15 +1029,6 @@ static int ncp_rmdir(struct inode *dir, struct dentry *dentry) DPRINTK(ncp_rmdir: removing %s/%s\n, dentry-d_parent-d_name.name http://d_name.name, dentry-d_name.name http://d_name.name); - /* - * fail with EBUSY if there are still references to this - * directory. - */ - dentry_unhash(dentry); - error = -EBUSY; - if (!d_unhashed(dentry)) - goto out; - len = sizeof(__name); error = ncp_io2vol(server, __name, len, dentry-d_name.name http://d_name.name, dentry-d_name.len, !ncp_preserve_case(dir)); -- 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: Commit f06e4ec breaks vmware
Jan Engelhardt wrote: Hi, sad to say, but f06e4ec... breaks booting the kernel in vmware (bisected). Booting just stops after Checking for 'hlt' instruction... commit f06e4ec1c15691b0cfd2397ae32214fa36c90d71 Author: Ingo Molnar <[EMAIL PROTECTED]> Date: Wed Jan 30 13:32:39 2008 +0100 x86: read_tsc sync make native_read_tsc() always non-speculative. Any debugging hintss? It does not make lot of sense... What is processor (AMD/Intel, VT/SVM, ...), kernel (32/64), and product? Can you try adding monitor_control.disable_rdtscopt_bt="TRUE" or monitor_control.virtual_rdtsc="FALSE" to your configuration file? Thanks, Petr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Commit f06e4ec breaks vmware
Jan Engelhardt wrote: Hi, sad to say, but f06e4ec... breaks booting the kernel in vmware (bisected). Booting just stops after Checking for 'hlt' instruction... commit f06e4ec1c15691b0cfd2397ae32214fa36c90d71 Author: Ingo Molnar [EMAIL PROTECTED] Date: Wed Jan 30 13:32:39 2008 +0100 x86: read_tsc sync make native_read_tsc() always non-speculative. Any debugging hintss? It does not make lot of sense... What is processor (AMD/Intel, VT/SVM, ...), kernel (32/64), and product? Can you try adding monitor_control.disable_rdtscopt_bt=TRUE or monitor_control.virtual_rdtsc=FALSE to your configuration file? Thanks, Petr -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unbreak sky2 on 88E8039 with current git
Stephen Hemminger wrote: On Sat, 2 Feb 2008 11:52:43 +0100 Petr Vandrovec <[EMAIL PROTECTED]> wrote: Hello, since I synced my tree to Linus's one two days ago, sky2's packet receiption dies almost instantly. Device still transmits packets, but no receive. Fortunately fix is simple, unfortunately I do not know why fix works... Commit f03b865491c2f30f2a4d77cdafc69c978ceb38a0 (sky2: align IP header on Rx if possible) stopped aligning receive buffers on devices which do not need HANG_CHECK. Unfortunately there is at least one device (mine, Yukon FE, rev 3) which is not happy if receive buffer is not aligned. I have no idea which other chips/revisions are affected as well. Without patch 'ping -f -b 192.168.101.255' RX count stops incrementing in less than 50 packets. With patch in place it can run like before, for hours... Box is an AMD rev F processor, with nVidia's MCP61 chipset. Petr I don't have a Yukon FE, but I believe that the Yukon FE does have a ram buffer, so you HANG_CHECK should be enabled for that device. You can check by running: ethtool -d eth0 | grep 'Ram Buffer' With ram buffer (like XL, EC) # ethtool -d eth0 | grep 'Ram Buffer' Ram Buffer 0x18 No ram buffer (like EC-U, FE+, ...) # ethtool -d eth0 | grep 'Ram Buffer' Ram Buffer 0x00 Some small one (if it is size): gwy:~# ethtool -d eth0 | grep 'Ram' Ram Buffer 0x01 I've never observed hang on that device, and I have it for over year. I stress it sufficiently to kill EC rev 2 I have in the notebook when I copy some data between these two boxes, but this FE never hung. Petr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
udevd induced deadlock in loading kernel modules?
Mailer on sf.net says that email address in udev's README is obsolete.
Oops...
Petr
Original Message
Subject: udevd induced deadlock in loading kernel modules?
Date: Sat, 2 Feb 2008 12:07:19 +0100
From: Petr Vandrovec <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
CC: [EMAIL PROTECTED]
Hello,
today my system hung during boot, while loading ftdi_sio & loop - I
have two ftdi serial ports,
and apparently this tricked udevd to start two concurrent modprobes for
them - so I ended up with
strance "ftdi_sio: gave up waiting for init of module usbserial." for
each symbol it tried to
import, until I kill-9 process 3137 (see below). After that loop got
loaded, and second ftdi's
load finished as well.
Unfortunately I do not have stacktraces of hung modprobe processes.
Maybe next time, but it
does not look very reproducible.
Kernel is current git (2.6.24,
ed50d6cbc394cd0966469d3e249353c9dd1d38b9), udev is Debian's 0.114-2,
and module-init-tools are Debian's 3.3-pre11-4. Kernel is 64bit amd64
with almost all debugging
enabled, userspace is 32bit.
Thanks,
Petr Vandrovec
usbcore: registered new interface driver usbserial
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial
support registered for generic
usbcore: registered new interface driver usbserial_generic
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial
Driver core
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_port_softint
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_disconnect
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_probe
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_register
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_deregister
loop: module loaded
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial
support registered for FTDI USB Serial Device
ftdi_sio 4-2:1.0: FTDI USB Serial Device converter detected
/usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM
usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0
ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected
/usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM
usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB1
usbcore: registered new interface driver ftdi_sio
/usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI
Serial Converters Driver
fuse init (API version 7.9)
1042 tty1 Ss+0:00 init boot
1045 tty1 S+ 0:00 \_ /bin/sh /etc/init.d/rc S
3954 tty1 S+ 0:00 \_ /bin/sh -e
/etc/rcS.d/S20module-init-tools start
3957 tty1 S+ 0:00 \_ /bin/sh -e
/etc/rcS.d/S20module-init-tools start
3958 tty1 D+ 0:00 \_ modprobe loop
1048 tty1 S+ 0:00 /bin/bash -i -m
4074 tty1 R+ 0:00 \_ ps axf
1136 ?S 3137 ?S< 0:00 | \_ /sbin/modprobe --use-blacklist
usb:v0403p6001d0200dc00dsc00dp00icFFiscFFipFF
3101 ?S< 0:00 \_ udevd --daemon
3138 ?D< 0:00 \_ /sbin/modprobe --use-blacklist
usb:v0403p6001d0200dc00dsc00dp00icFFiscFFipFF
2612 ?S< 0:00 /bin/sh -e /lib/udev/net.agent
4069 ?S< 0:00 \_ sleep 1
2939 ?S< 0:00 /bin/sh -e /lib/udev/net.agent
4073 ?S< 0:00 \_ sleep 1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Unbreak sky2 on 88E8039 with current git
Hello,
since I synced my tree to Linus's one two days ago, sky2's packet receiption
dies almost instantly. Device still transmits packets, but no receive.
Fortunately fix is simple, unfortunately I do not know why fix works...
Commit f03b865491c2f30f2a4d77cdafc69c978ceb38a0 (sky2: align IP header on Rx
if possible) stopped aligning receive buffers on devices which do not need
HANG_CHECK. Unfortunately there is at least one device (mine, Yukon FE, rev 3)
which is not happy if receive buffer is not aligned. I have no idea which
other chips/revisions are affected as well.
Without patch 'ping -f -b 192.168.101.255' RX count stops incrementing in less
than 50 packets. With patch in place it can run like before, for hours...
Box is an AMD rev F processor, with nVidia's MCP61 chipset.
Petr
gwy:/home/petr# lspci -vv -s 4:0.0
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8039 PCI-E Fast
Ethernet Controller (rev 14)
Subsystem: Elitegroup Computer Systems Unknown device 8039
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1
Enable+
Address: fee0300c Data: 41c9
Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+
TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0
<256ns, L1 unlimited
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: sky2
Kernel modules: sky2
Yukon FE, rev 3 needs receive buffers aligned, otherwise receiver hangs
almost instantly. They were aligned before, so let's start aligning
them again - a bit suboptimal networking is much better than no networking
at all.
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1192,7 +1192,7 @@ static struct sk_buff *sky2_rx_alloc(struct sky2_port
*sky2)
struct sk_buff *skb;
int i;
- if (sky2->hw->flags & SKY2_HW_FIFO_HANG_CHECK) {
+ if (sky2->hw->flags & SKY2_HW_FIFO_RX_ALIGN) {
unsigned char *start;
/*
* Workaround for a bug in FIFO that cause hang
@@ -2718,7 +2718,7 @@ static int __devinit sky2_init(struct sky2_hw *hw)
hw->flags = SKY2_HW_GIGABIT
| SKY2_HW_NEWER_PHY;
if (hw->chip_rev < 3)
- hw->flags |= SKY2_HW_FIFO_HANG_CHECK;
+ hw->flags |= SKY2_HW_FIFO_HANG_CHECK |
SKY2_HW_FIFO_RX_ALIGN;
break;
@@ -2745,10 +2745,12 @@ static int __devinit sky2_init(struct sky2_hw *hw)
dev_err(>pdev->dev, "unsupported revision Yukon-EC
rev A1\n");
return -EOPNOTSUPP;
}
- hw->flags = SKY2_HW_GIGABIT | SKY2_HW_FIFO_HANG_CHECK;
+ hw->flags = SKY2_HW_GIGABIT | SKY2_HW_FIFO_HANG_CHECK |
SKY2_HW_FIFO_RX_ALIGN;
break;
case CHIP_ID_YUKON_FE:
+ if (hw->chip_rev == 3)
+ hw->flags |= SKY2_HW_FIFO_RX_ALIGN;
break;
case CHIP_ID_YUKON_FE_P:
diff --git a/drivers/net/sky2.h b/drivers/net/sky2.h
index 2bced1a..b5c1457 100644
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -2049,6 +2049,7 @@ struct sky2_hw {
#define SKY2_HW_NEW_LE 0x0020 /* new LSOv2 format */
#define SKY2_HW_AUTO_TX_SUM0x0040 /* new IP decode for Tx */
#define SKY2_HW_ADV_POWER_CTL 0x0080 /* additional PHY power regs */
+#define SKY2_HW_FIFO_RX_ALIGN 0x0100
u8 chip_id;
u8 chip_rev;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
udevd induced deadlock in loading kernel modules?
Hello,
today my system hung during boot, while loading ftdi_sio & loop - I have two
ftdi serial ports,
and apparently this tricked udevd to start two concurrent modprobes for them -
so I ended up with
strance "ftdi_sio: gave up waiting for init of module usbserial." for each
symbol it tried to
import, until I kill-9 process 3137 (see below). After that loop got loaded,
and second ftdi's
load finished as well.
Unfortunately I do not have stacktraces of hung modprobe processes. Maybe next
time, but it
does not look very reproducible.
Kernel is current git (2.6.24, ed50d6cbc394cd0966469d3e249353c9dd1d38b9), udev
is Debian's 0.114-2,
and module-init-tools are Debian's 3.3-pre11-4. Kernel is 64bit amd64 with
almost all debugging
enabled, userspace is 32bit.
Thanks,
Petr Vandrovec
usbcore: registered new interface driver usbserial
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial support
registered for generic
usbcore: registered new interface driver usbserial_generic
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial Driver core
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_port_softint
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_disconnect
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_probe
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_register
ftdi_sio: gave up waiting for init of module usbserial.
ftdi_sio: Unknown symbol usb_serial_deregister
loop: module loaded
/usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial support
registered for FTDI USB Serial Device
ftdi_sio 4-2:1.0: FTDI USB Serial Device converter detected
/usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM
usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0
ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected
/usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM
usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB1
usbcore: registered new interface driver ftdi_sio
/usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial
Converters Driver
fuse init (API version 7.9)
1042 tty1 Ss+0:00 init boot
1045 tty1 S+ 0:00 \_ /bin/sh /etc/init.d/rc S
3954 tty1 S+ 0:00 \_ /bin/sh -e /etc/rcS.d/S20module-init-tools
start
3957 tty1 S+ 0:00 \_ /bin/sh -e
/etc/rcS.d/S20module-init-tools start
3958 tty1 D+ 0:00 \_ modprobe loop
1048 tty1 S+ 0:00 /bin/bash -i -m
4074 tty1 R+ 0:00 \_ ps axf
1136 ?Shttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
udevd induced deadlock in loading kernel modules?
Hello, today my system hung during boot, while loading ftdi_sio loop - I have two ftdi serial ports, and apparently this tricked udevd to start two concurrent modprobes for them - so I ended up with strance ftdi_sio: gave up waiting for init of module usbserial. for each symbol it tried to import, until I kill-9 process 3137 (see below). After that loop got loaded, and second ftdi's load finished as well. Unfortunately I do not have stacktraces of hung modprobe processes. Maybe next time, but it does not look very reproducible. Kernel is current git (2.6.24, ed50d6cbc394cd0966469d3e249353c9dd1d38b9), udev is Debian's 0.114-2, and module-init-tools are Debian's 3.3-pre11-4. Kernel is 64bit amd64 with almost all debugging enabled, userspace is 32bit. Thanks, Petr Vandrovec usbcore: registered new interface driver usbserial /usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbcore: registered new interface driver usbserial_generic /usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial Driver core ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_port_softint ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_disconnect ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_probe ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_register ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_deregister loop: module loaded /usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device ftdi_sio 4-2:1.0: FTDI USB Serial Device converter detected /usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0 ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected /usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB1 usbcore: registered new interface driver ftdi_sio /usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver fuse init (API version 7.9) 1042 tty1 Ss+0:00 init boot 1045 tty1 S+ 0:00 \_ /bin/sh /etc/init.d/rc S 3954 tty1 S+ 0:00 \_ /bin/sh -e /etc/rcS.d/S20module-init-tools start 3957 tty1 S+ 0:00 \_ /bin/sh -e /etc/rcS.d/S20module-init-tools start 3958 tty1 D+ 0:00 \_ modprobe loop 1048 tty1 S+ 0:00 /bin/bash -i -m 4074 tty1 R+ 0:00 \_ ps axf 1136 ?Ss0:01 udevd --daemon 3096 ?S 0:00 \_ udevd --daemon 3137 ?S 0:00 | \_ /sbin/modprobe --use-blacklist usb:v0403p6001d0200dc00dsc00dp00icFFiscFFipFF 3101 ?S 0:00 \_ udevd --daemon 3138 ?D 0:00 \_ /sbin/modprobe --use-blacklist usb:v0403p6001d0200dc00dsc00dp00icFFiscFFipFF 2612 ?S 0:00 /bin/sh -e /lib/udev/net.agent 4069 ?S 0:00 \_ sleep 1 2939 ?S 0:00 /bin/sh -e /lib/udev/net.agent 4073 ?S 0:00 \_ sleep 1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Unbreak sky2 on 88E8039 with current git
Hello,
since I synced my tree to Linus's one two days ago, sky2's packet receiption
dies almost instantly. Device still transmits packets, but no receive.
Fortunately fix is simple, unfortunately I do not know why fix works...
Commit f03b865491c2f30f2a4d77cdafc69c978ceb38a0 (sky2: align IP header on Rx
if possible) stopped aligning receive buffers on devices which do not need
HANG_CHECK. Unfortunately there is at least one device (mine, Yukon FE, rev 3)
which is not happy if receive buffer is not aligned. I have no idea which
other chips/revisions are affected as well.
Without patch 'ping -f -b 192.168.101.255' RX count stops incrementing in less
than 50 packets. With patch in place it can run like before, for hours...
Box is an AMD rev F processor, with nVidia's MCP61 chipset.
Petr
gwy:/home/petr# lspci -vv -s 4:0.0
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8039 PCI-E Fast
Ethernet Controller (rev 14)
Subsystem: Elitegroup Computer Systems Unknown device 8039
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
Interrupt: pin A routed to IRQ 377
Region 0: Memory at fdcfc000 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at 8c00 [size=256]
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data ?
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1
Enable+
Address: fee0300c Data: 41c9
Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+
TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0
256ns, L1 unlimited
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Advanced Error Reporting ?
Kernel driver in use: sky2
Kernel modules: sky2
Yukon FE, rev 3 needs receive buffers aligned, otherwise receiver hangs
almost instantly. They were aligned before, so let's start aligning
them again - a bit suboptimal networking is much better than no networking
at all.
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1192,7 +1192,7 @@ static struct sk_buff *sky2_rx_alloc(struct sky2_port
*sky2)
struct sk_buff *skb;
int i;
- if (sky2-hw-flags SKY2_HW_FIFO_HANG_CHECK) {
+ if (sky2-hw-flags SKY2_HW_FIFO_RX_ALIGN) {
unsigned char *start;
/*
* Workaround for a bug in FIFO that cause hang
@@ -2718,7 +2718,7 @@ static int __devinit sky2_init(struct sky2_hw *hw)
hw-flags = SKY2_HW_GIGABIT
| SKY2_HW_NEWER_PHY;
if (hw-chip_rev 3)
- hw-flags |= SKY2_HW_FIFO_HANG_CHECK;
+ hw-flags |= SKY2_HW_FIFO_HANG_CHECK |
SKY2_HW_FIFO_RX_ALIGN;
break;
@@ -2745,10 +2745,12 @@ static int __devinit sky2_init(struct sky2_hw *hw)
dev_err(hw-pdev-dev, unsupported revision Yukon-EC
rev A1\n);
return -EOPNOTSUPP;
}
- hw-flags = SKY2_HW_GIGABIT | SKY2_HW_FIFO_HANG_CHECK;
+ hw-flags = SKY2_HW_GIGABIT | SKY2_HW_FIFO_HANG_CHECK |
SKY2_HW_FIFO_RX_ALIGN;
break;
case CHIP_ID_YUKON_FE:
+ if (hw-chip_rev == 3)
+ hw-flags |= SKY2_HW_FIFO_RX_ALIGN;
break;
case CHIP_ID_YUKON_FE_P:
diff --git a/drivers/net/sky2.h b/drivers/net/sky2.h
index 2bced1a..b5c1457 100644
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -2049,6 +2049,7 @@ struct sky2_hw {
#define SKY2_HW_NEW_LE 0x0020 /* new LSOv2 format */
#define SKY2_HW_AUTO_TX_SUM0x0040 /* new IP decode for Tx */
#define
udevd induced deadlock in loading kernel modules?
Mailer on sf.net says that email address in udev's README is obsolete. Oops... Petr Original Message Subject: udevd induced deadlock in loading kernel modules? Date: Sat, 2 Feb 2008 12:07:19 +0100 From: Petr Vandrovec [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org CC: [EMAIL PROTECTED] Hello, today my system hung during boot, while loading ftdi_sio loop - I have two ftdi serial ports, and apparently this tricked udevd to start two concurrent modprobes for them - so I ended up with strance ftdi_sio: gave up waiting for init of module usbserial. for each symbol it tried to import, until I kill-9 process 3137 (see below). After that loop got loaded, and second ftdi's load finished as well. Unfortunately I do not have stacktraces of hung modprobe processes. Maybe next time, but it does not look very reproducible. Kernel is current git (2.6.24, ed50d6cbc394cd0966469d3e249353c9dd1d38b9), udev is Debian's 0.114-2, and module-init-tools are Debian's 3.3-pre11-4. Kernel is 64bit amd64 with almost all debugging enabled, userspace is 32bit. Thanks, Petr Vandrovec usbcore: registered new interface driver usbserial /usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbcore: registered new interface driver usbserial_generic /usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial Driver core ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_port_softint ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_disconnect ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_probe ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_register ftdi_sio: gave up waiting for init of module usbserial. ftdi_sio: Unknown symbol usb_serial_deregister loop: module loaded /usr/src/git/libata-pv/drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device ftdi_sio 4-2:1.0: FTDI USB Serial Device converter detected /usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM usb 4-2: FTDI USB Serial Device converter now attached to ttyUSB0 ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected /usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB1 usbcore: registered new interface driver ftdi_sio /usr/src/git/libata-pv/drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver fuse init (API version 7.9) 1042 tty1 Ss+0:00 init boot 1045 tty1 S+ 0:00 \_ /bin/sh /etc/init.d/rc S 3954 tty1 S+ 0:00 \_ /bin/sh -e /etc/rcS.d/S20module-init-tools start 3957 tty1 S+ 0:00 \_ /bin/sh -e /etc/rcS.d/S20module-init-tools start 3958 tty1 D+ 0:00 \_ modprobe loop 1048 tty1 S+ 0:00 /bin/bash -i -m 4074 tty1 R+ 0:00 \_ ps axf 1136 ?Ss0:01 udevd --daemon 3096 ?S 0:00 \_ udevd --daemon 3137 ?S 0:00 | \_ /sbin/modprobe --use-blacklist usb:v0403p6001d0200dc00dsc00dp00icFFiscFFipFF 3101 ?S 0:00 \_ udevd --daemon 3138 ?D 0:00 \_ /sbin/modprobe --use-blacklist usb:v0403p6001d0200dc00dsc00dp00icFFiscFFipFF 2612 ?S 0:00 /bin/sh -e /lib/udev/net.agent 4069 ?S 0:00 \_ sleep 1 2939 ?S 0:00 /bin/sh -e /lib/udev/net.agent 4073 ?S 0:00 \_ sleep 1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unbreak sky2 on 88E8039 with current git
Stephen Hemminger wrote: On Sat, 2 Feb 2008 11:52:43 +0100 Petr Vandrovec [EMAIL PROTECTED] wrote: Hello, since I synced my tree to Linus's one two days ago, sky2's packet receiption dies almost instantly. Device still transmits packets, but no receive. Fortunately fix is simple, unfortunately I do not know why fix works... Commit f03b865491c2f30f2a4d77cdafc69c978ceb38a0 (sky2: align IP header on Rx if possible) stopped aligning receive buffers on devices which do not need HANG_CHECK. Unfortunately there is at least one device (mine, Yukon FE, rev 3) which is not happy if receive buffer is not aligned. I have no idea which other chips/revisions are affected as well. Without patch 'ping -f -b 192.168.101.255' RX count stops incrementing in less than 50 packets. With patch in place it can run like before, for hours... Box is an AMD rev F processor, with nVidia's MCP61 chipset. Petr I don't have a Yukon FE, but I believe that the Yukon FE does have a ram buffer, so you HANG_CHECK should be enabled for that device. You can check by running: ethtool -d eth0 | grep 'Ram Buffer' With ram buffer (like XL, EC) # ethtool -d eth0 | grep 'Ram Buffer' Ram Buffer 0x18 No ram buffer (like EC-U, FE+, ...) # ethtool -d eth0 | grep 'Ram Buffer' Ram Buffer 0x00 Some small one (if it is size): gwy:~# ethtool -d eth0 | grep 'Ram' Ram Buffer 0x01 I've never observed hang on that device, and I have it for over year. I stress it sufficiently to kill EC rev 2 I have in the notebook when I copy some data between these two boxes, but this FE never hung. Petr -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate
Eric W. Biederman wrote:
Ultimately to implement /proc perfectly we need an implementation
of d_revalidate because files and directories can be removed behind
the back of the VFS, and d_revalidate is the only way we can let
the VFS know that this has happened.
So until we get a proper test for keeping dentries in the dcache
fix the current d_revalidate method by completely removing it. This
returns us to the current status quo.
Hello,
I know that I'm late to the party, but mount points is not only
problem with d_revalidate. With your patch in place module below gets
refcount incremented by two every time I do 'ls -la /proc/fs/vmblock'.
#include
#include
#include
static int vmblockinit(void) {
struct proc_dir_entry *controlProcDirEntry;
/* Create /proc/fs/vmblock */
controlProcDirEntry = proc_mkdir("vmblock", proc_root_fs);
if (!controlProcDirEntry) {
printk(KERN_DEBUG "Bad...\n");
return -EINVAL;
}
controlProcDirEntry->owner = THIS_MODULE;
return 0;
}
static void vmblockexit(void) {
remove_proc_entry("vmblock", proc_root_fs);
}
module_init(vmblockinit);
module_exit(vmblockexit);
(code comes from VMware's vmblock module,
http://sourceforge.net/project/showfiles.php?group_id=204462)
Thanks,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate
Eric W. Biederman wrote:
Ultimately to implement /proc perfectly we need an implementation
of d_revalidate because files and directories can be removed behind
the back of the VFS, and d_revalidate is the only way we can let
the VFS know that this has happened.
So until we get a proper test for keeping dentries in the dcache
fix the current d_revalidate method by completely removing it. This
returns us to the current status quo.
Hello,
I know that I'm late to the party, but mount points is not only
problem with d_revalidate. With your patch in place module below gets
refcount incremented by two every time I do 'ls -la /proc/fs/vmblock'.
#include linux/kernel.h
#include linux/module.h
#include linux/proc_fs.h
static int vmblockinit(void) {
struct proc_dir_entry *controlProcDirEntry;
/* Create /proc/fs/vmblock */
controlProcDirEntry = proc_mkdir(vmblock, proc_root_fs);
if (!controlProcDirEntry) {
printk(KERN_DEBUG Bad...\n);
return -EINVAL;
}
controlProcDirEntry-owner = THIS_MODULE;
return 0;
}
static void vmblockexit(void) {
remove_proc_entry(vmblock, proc_root_fs);
}
module_init(vmblockinit);
module_exit(vmblockexit);
(code comes from VMware's vmblock module,
http://sourceforge.net/project/showfiles.php?group_id=204462)
Thanks,
Petr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Networked filesystems vs backing_dev_info
Peter Zijlstra wrote: On Sat, 2007-10-27 at 23:30 +0200, Peter Zijlstra wrote: So in short, stick a struct backing_dev_info into whatever represents a client, initialize it using bdi_init(), destroy using bdi_destroy(). Oh, and the most important point, make your fresh I_NEW inodes point to this bdi struct. Mark it congested once you have 50 (or more) outstanding requests, clear congestion when you drop below 50. and you should be set. Thanks. Unfortunately I do not think that NCPFS will switch to backing_dev_info - it uses pagecache only for symlinks and directories, and even if it would use pagecache, as most of servers refuse concurrent requests even if TCP is used as a transport, there can be only one request in flight... Petr P.S.: And if anyone wants to step in as ncpfs maintainer, feel free. I did not see NetWare server for over year now... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Networked filesystems vs backing_dev_info
Peter Zijlstra wrote: On Sat, 2007-10-27 at 23:30 +0200, Peter Zijlstra wrote: So in short, stick a struct backing_dev_info into whatever represents a client, initialize it using bdi_init(), destroy using bdi_destroy(). Oh, and the most important point, make your fresh I_NEW inodes point to this bdi struct. Mark it congested once you have 50 (or more) outstanding requests, clear congestion when you drop below 50. and you should be set. Thanks. Unfortunately I do not think that NCPFS will switch to backing_dev_info - it uses pagecache only for symlinks and directories, and even if it would use pagecache, as most of servers refuse concurrent requests even if TCP is used as a transport, there can be only one request in flight... Petr P.S.: And if anyone wants to step in as ncpfs maintainer, feel free. I did not see NetWare server for over year now... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intel Memory Ordering White Paper
dean gaudet wrote:
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?
see section 7.2.3 of intel volume 3A...
"Code dependent upon sequential store ordering should not use the string
operations for the entire data structure to be stored. Data and semaphores
should be separated. Order dependent code should use a discrete semaphore
uniquely stored to after any string operations to allow correctly ordered
data to be seen by all processors."
i think we need sfence after things like copy_page, clear_page, and
possibly copy_user... at least on intel processors with fast strings
option enabled.
I do not think. I believe that authors are trying to say that
struct { uint8 lock; uint8 data; } x;
lea (x.data),%edi
mov $2,%ecx
std
rep movsb
to set both data and lock does not guarantee that x.lock will be set
after x.data and that you should do
lea (x.data),%edi
std
movsb
movsb # or mov (%esi),%al; mov %al,(%edi), but movsb looks discrete
enough to me
instead (and yes, I know that my example is silly).
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Intel Memory Ordering White Paper
dean gaudet wrote:
On Sun, 9 Sep 2007, Nick Piggin wrote:
I've also heard that string operations do not follow the normal ordering, but
that's just with respect to individual loads/stores in the one operation, I
hope? And they will still follow ordering rules WRT surrounding loads and
stores?
see section 7.2.3 of intel volume 3A...
Code dependent upon sequential store ordering should not use the string
operations for the entire data structure to be stored. Data and semaphores
should be separated. Order dependent code should use a discrete semaphore
uniquely stored to after any string operations to allow correctly ordered
data to be seen by all processors.
i think we need sfence after things like copy_page, clear_page, and
possibly copy_user... at least on intel processors with fast strings
option enabled.
I do not think. I believe that authors are trying to say that
struct { uint8 lock; uint8 data; } x;
lea (x.data),%edi
mov $2,%ecx
std
rep movsb
to set both data and lock does not guarantee that x.lock will be set
after x.data and that you should do
lea (x.data),%edi
std
movsb
movsb # or mov (%esi),%al; mov %al,(%edi), but movsb looks discrete
enough to me
instead (and yes, I know that my example is silly).
Petr
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Please remove ab144f5ec64c42218a555ec1dbde6b60cf2982d6 was Re: [discuss] [PATCH] Fix triplefault on x86-64 bootup
Andi Kleen wrote: On Sunday 12 August 2007 10:12, Petr Vandrovec wrote: Hello, after I upgraded kernel on my box to current git, only thing it did was rebooting in a loop. After some digging I found that it is silly to apply alternative to memcpy by using that every same memcpy... Sorry if it is known bug, I do not see it reported in my LKML mailbox... Ok Linus already applied your patch. Even though it's a really bad fragile hack, not better than the old bug. Petr are you double sure you really tested with ab144f5ec64c42218a555ec1dbde6b60cf2982d6 already applied? I bet not -- it is the symptom exactly fixed by this patch I'm quite sure that this patch is in my tree, as I have that "u8 *instr = a->instr;" in apply_alternatives, and it seems that this one was added by checkin you mention... My tree was synced up to: Commit: 3dab307e527f2a9bbb4f9d00240374bb93d1945f Author: Chuck Ebbert <[EMAIL PROTECTED]> Fri, 10 Aug 2007 22:31:11 +0200 which as far as I can tell really *is* after your fix. I'm quite sure that I did not hit any BUG_ON() or anything like that - when patching got to memcpy alternative, it entered text_poke(), and instead of returning to caller it returned to BIOS :-( (although Linus, I would prefer if you reverted b8d3f2448b8f4ba24f301e23585547ba1acc1f04 again -- it should really not be needed with ab144f5ec64c42218a555ec1dbde6b60cf2982d6 And I really dislike Petr's patch because while it might work today (I'm not 100% sure it actually works to only replace 2 bytes) if we change memcpy ever it'll likely cause strange problems again. It does not actually change two bytes - it changes two bytes now because alternative is two bytes long - it makes no sense to replace whole function with NOPs - it is necessary when you fall through that function, but for this (and other x86-64 alternatives) it makes no sense to replace whole function with nops if first instruction in alternative is jump - then you need to only put that jump in place. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix triplefault on x86-64 bootup
Hello, after I upgraded kernel on my box to current git, only thing it did was rebooting in a loop. After some digging I found that it is silly to apply alternative to memcpy by using that every same memcpy... Sorry if it is known bug, I do not see it reported in my LKML mailbox... Petr From: Petr Vandrovec <[EMAIL PROTECTED]> Do not replace whole memcpy in apply alternatives apply_alternatives uses memcpy() to apply alternatives. Which has unfortunate effect that while applying memcpy alternative memcpy itself it tries to overwrite itself with nops - which causes #UD fault as it overwrites half of instruction in copy loop, and from this point on only possible outcome is triplefault and reboot. So let's overwrite only first two instructions of memcpy - as long as main memcpy loop is not in first two bytes it will work fine. Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]> --- commit 7c6f7d582f301e16899a43fd6c775ed103e8a8d2 tree 112d7320e8a21120e4e43f1ac91918ca0352ff56 parent f81e9b8cc6301f6328eafaa553ef35441874b1a4 author Petr Vandrovec <[EMAIL PROTECTED]> Sun, 12 Aug 2007 01:05:11 -0700 committer Petr Vandrovec <[EMAIL PROTECTED]> Sun, 12 Aug 2007 01:05:11 -0700 arch/x86_64/lib/memcpy.S |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/x86_64/lib/memcpy.S b/arch/x86_64/lib/memcpy.S index 0ea0ddc..c22981f 100644 --- a/arch/x86_64/lib/memcpy.S +++ b/arch/x86_64/lib/memcpy.S @@ -124,6 +124,8 @@ ENDPROC(__memcpy) .quad memcpy .quad 1b .byte X86_FEATURE_REP_GOOD - .byte .Lfinal - memcpy + /* Replace only beginning, memcpy is used to apply alternatives, so it +* is silly to overwrite itself with nops - reboot is only outcome... */ + .byte 2b - 1b .byte 2b - 1b .previous - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix triplefault on x86-64 bootup
Hello, after I upgraded kernel on my box to current git, only thing it did was rebooting in a loop. After some digging I found that it is silly to apply alternative to memcpy by using that every same memcpy... Sorry if it is known bug, I do not see it reported in my LKML mailbox... Petr From: Petr Vandrovec [EMAIL PROTECTED] Do not replace whole memcpy in apply alternatives apply_alternatives uses memcpy() to apply alternatives. Which has unfortunate effect that while applying memcpy alternative memcpy itself it tries to overwrite itself with nops - which causes #UD fault as it overwrites half of instruction in copy loop, and from this point on only possible outcome is triplefault and reboot. So let's overwrite only first two instructions of memcpy - as long as main memcpy loop is not in first two bytes it will work fine. Signed-off-by: Petr Vandrovec [EMAIL PROTECTED] --- commit 7c6f7d582f301e16899a43fd6c775ed103e8a8d2 tree 112d7320e8a21120e4e43f1ac91918ca0352ff56 parent f81e9b8cc6301f6328eafaa553ef35441874b1a4 author Petr Vandrovec [EMAIL PROTECTED] Sun, 12 Aug 2007 01:05:11 -0700 committer Petr Vandrovec [EMAIL PROTECTED] Sun, 12 Aug 2007 01:05:11 -0700 arch/x86_64/lib/memcpy.S |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/x86_64/lib/memcpy.S b/arch/x86_64/lib/memcpy.S index 0ea0ddc..c22981f 100644 --- a/arch/x86_64/lib/memcpy.S +++ b/arch/x86_64/lib/memcpy.S @@ -124,6 +124,8 @@ ENDPROC(__memcpy) .quad memcpy .quad 1b .byte X86_FEATURE_REP_GOOD - .byte .Lfinal - memcpy + /* Replace only beginning, memcpy is used to apply alternatives, so it +* is silly to overwrite itself with nops - reboot is only outcome... */ + .byte 2b - 1b .byte 2b - 1b .previous - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please remove ab144f5ec64c42218a555ec1dbde6b60cf2982d6 was Re: [discuss] [PATCH] Fix triplefault on x86-64 bootup
Andi Kleen wrote: On Sunday 12 August 2007 10:12, Petr Vandrovec wrote: Hello, after I upgraded kernel on my box to current git, only thing it did was rebooting in a loop. After some digging I found that it is silly to apply alternative to memcpy by using that every same memcpy... Sorry if it is known bug, I do not see it reported in my LKML mailbox... Ok Linus already applied your patch. Even though it's a really bad fragile hack, not better than the old bug. Petr are you double sure you really tested with ab144f5ec64c42218a555ec1dbde6b60cf2982d6 already applied? I bet not -- it is the symptom exactly fixed by this patch I'm quite sure that this patch is in my tree, as I have that u8 *instr = a-instr; in apply_alternatives, and it seems that this one was added by checkin you mention... My tree was synced up to: Commit: 3dab307e527f2a9bbb4f9d00240374bb93d1945f Author: Chuck Ebbert [EMAIL PROTECTED] Fri, 10 Aug 2007 22:31:11 +0200 which as far as I can tell really *is* after your fix. I'm quite sure that I did not hit any BUG_ON() or anything like that - when patching got to memcpy alternative, it entered text_poke(), and instead of returning to caller it returned to BIOS :-( (although Linus, I would prefer if you reverted b8d3f2448b8f4ba24f301e23585547ba1acc1f04 again -- it should really not be needed with ab144f5ec64c42218a555ec1dbde6b60cf2982d6 And I really dislike Petr's patch because while it might work today (I'm not 100% sure it actually works to only replace 2 bytes) if we change memcpy ever it'll likely cause strange problems again. It does not actually change two bytes - it changes two bytes now because alternative is two bytes long - it makes no sense to replace whole function with NOPs - it is necessary when you fall through that function, but for this (and other x86-64 alternatives) it makes no sense to replace whole function with nops if first instruction in alternative is jump - then you need to only put that jump in place. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inclusion of vmware mptbase regression fix
James Bottomley wrote: On Tue, 2007-07-31 at 20:24 +0200, Maarten Bressers wrote: Hi Petr, The patch you posted for the MPT Fusion driver regression with VMware 5.5.4 (http://lkml.org/lkml/2007/3/23/345) was used to fix a Gentoo kernel bug (http://bugs.gentoo.org/show_bug.cgi?id=185272). Have you received word from upstream (kernel devs) yet as to whether your patch will be included? Or if it will be included at all? That's a slightly worse version of this patch. http://marc.info/?l=linux-scsi=117432237404247 And the answer's still the same: fix the vmware fusion emulation ... it's a software thing too. It is already fixed in WS6.0, and I latest Fusion beta has fixed this as well. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inclusion of vmware mptbase regression fix
James Bottomley wrote: On Tue, 2007-07-31 at 20:24 +0200, Maarten Bressers wrote: Hi Petr, The patch you posted for the MPT Fusion driver regression with VMware 5.5.4 (http://lkml.org/lkml/2007/3/23/345) was used to fix a Gentoo kernel bug (http://bugs.gentoo.org/show_bug.cgi?id=185272). Have you received word from upstream (kernel devs) yet as to whether your patch will be included? Or if it will be included at all? That's a slightly worse version of this patch. http://marc.info/?l=linux-scsim=117432237404247 And the answer's still the same: fix the vmware fusion emulation ... it's a software thing too. It is already fixed in WS6.0, and I latest Fusion beta has fixed this as well. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] List VESA graphics videomodes when vesafb is present
Hello,
I had something like this in video.S for years, so it is probably time
to try to push it upstream... Besides other problems it confirmed that
when I connect HDTV to my nVidia, BIOS decides that 640x480 is largest
possible resolution, as it is largest standard resolution smaller than
non-interlaced 1920x540, and apparently BIOS I have does not believe
that interlaced modes exist.
Thanks,
Petr Vandrovec
List VESA videomodes when vesafb is available
There is no CONFIG_VIDEO_VESA option, so code to retrieve VESA modes
(even text ones) was always disabled - it was introduced by conversion,
old video.S had #define CONFIG_VIDEO_VESA at the beginning.
Modify video-vesa.c to list graphics videomodes when vesafb is built in
and videomode is acceptable.
Because there is lot of videomodes in some VESA BIOSes, list them in three
columns (should be good for anybody - videocards with more than ~70 videomodes
cannot be used with some OSes, so vendors usually try to not cross more
than 60 videomodes reported by VESA). Which unfortunately means that
card_name for "BIOS (scanned)" needs to be made shorter.
And display color depth for videomodes. To avoid confusion depth
is shown only if non-text videomodes are present in the list.
---
commit 9453a2a4afee6cadb020838d0a35c2d11af25aa6
tree 5903315f7fd62db34f22107e63ec37a24bbf8075
parent 5de7fc0bf0e2e36a8dcf619e95576219dcc13d70
author Petr Vandrovec <[EMAIL PROTECTED]> Sun, 22 Jul 2007 23:54:34 -0700
committer Petr Vandrovec <[EMAIL PROTECTED]> Sun, 22 Jul 2007 23:54:34 -0700
arch/i386/boot/video-bios.c |3 ++-
arch/i386/boot/video-vesa.c | 48 +++
arch/i386/boot/video-vga.c | 20 +-
arch/i386/boot/video.c | 39 ---
arch/i386/boot/video.h |3 ++-
5 files changed, 89 insertions(+), 24 deletions(-)
diff --git a/arch/i386/boot/video-bios.c b/arch/i386/boot/video-bios.c
index afea46c..376ff71 100644
--- a/arch/i386/boot/video-bios.c
+++ b/arch/i386/boot/video-bios.c
@@ -104,6 +104,7 @@ static int bios_probe(void)
mi = GET_HEAP(struct mode_info, 1);
mi->mode = VIDEO_FIRST_BIOS+mode;
+ mi->depth = 0; /* text */
mi->x = rdfs16(0x44a);
mi->y = rdfs8(0x484)+1;
nmodes++;
@@ -116,7 +117,7 @@ static int bios_probe(void)
__videocard video_bios =
{
- .card_name = "BIOS (scanned)",
+ .card_name = "BIOS",
.probe = bios_probe,
.set_mode = bios_set_mode,
.unsafe = 1,
diff --git a/arch/i386/boot/video-vesa.c b/arch/i386/boot/video-vesa.c
index e6aa9eb..af7019f 100644
--- a/arch/i386/boot/video-vesa.c
+++ b/arch/i386/boot/video-vesa.c
@@ -28,7 +28,7 @@ static void vesa_store_mode_params_graphics(void);
static int vesa_probe(void)
{
-#if defined(CONFIG_VIDEO_VESA) || defined(CONFIG_FIRMWARE_EDID)
+#if defined(CONFIG_VIDEO_SELECT) || defined(CONFIG_FIRMWARE_EDID)
u16 ax;
u16 mode;
addr_t mode_ptr;
@@ -47,8 +47,8 @@ static int vesa_probe(void)
vginfo.signature != VESA_MAGIC ||
vginfo.version < 0x0102)
return 0; /* Not present */
-#endif /* CONFIG_VIDEO_VESA || CONFIG_FIRMWARE_EDID */
-#ifdef CONFIG_VIDEO_VESA
+#endif /* CONFIG_VIDEO_SELECT || CONFIG_FIRMWARE_EDID */
+#ifdef CONFIG_VIDEO_SELECT
set_fs(vginfo.video_mode_ptr.seg);
mode_ptr = vginfo.video_mode_ptr.off;
@@ -75,19 +75,49 @@ static int vesa_probe(void)
/* Text Mode, TTY BIOS supported,
supported by hardware */
mi = GET_HEAP(struct mode_info, 1);
- mi->mode = mode + VIDEO_FIRST_VESA;
- mi->x= vminfo.h_res;
- mi->y= vminfo.v_res;
+ mi->mode = mode + VIDEO_FIRST_VESA;
+ mi->depth = 0; /* text */
+ mi->x = vminfo.h_res;
+ mi->y = vminfo.v_res;
nmodes++;
} else if ((vminfo.mode_attr & 0x99) == 0x99) {
#ifdef CONFIG_FB
/* Graphics mode, color, linear frame buffer
- supported -- register the mode but hide from
+ supported -- register the mode, and if there
+ is no VESA framebuffer then hide from
the menu. Only do this if framebuffer is
configured, however, otherwise the user will
be left without a screen. */
mi = GET_HEAP(struct mode_info, 1);
- mi->mode = mode + VIDEO_FIRST_VESA;
+
[PATCH] List VESA graphics videomodes when vesafb is present
Hello,
I had something like this in video.S for years, so it is probably time
to try to push it upstream... Besides other problems it confirmed that
when I connect HDTV to my nVidia, BIOS decides that 640x480 is largest
possible resolution, as it is largest standard resolution smaller than
non-interlaced 1920x540, and apparently BIOS I have does not believe
that interlaced modes exist.
Thanks,
Petr Vandrovec
List VESA videomodes when vesafb is available
There is no CONFIG_VIDEO_VESA option, so code to retrieve VESA modes
(even text ones) was always disabled - it was introduced by conversion,
old video.S had #define CONFIG_VIDEO_VESA at the beginning.
Modify video-vesa.c to list graphics videomodes when vesafb is built in
and videomode is acceptable.
Because there is lot of videomodes in some VESA BIOSes, list them in three
columns (should be good for anybody - videocards with more than ~70 videomodes
cannot be used with some OSes, so vendors usually try to not cross more
than 60 videomodes reported by VESA). Which unfortunately means that
card_name for BIOS (scanned) needs to be made shorter.
And display color depth for videomodes. To avoid confusion depth
is shown only if non-text videomodes are present in the list.
---
commit 9453a2a4afee6cadb020838d0a35c2d11af25aa6
tree 5903315f7fd62db34f22107e63ec37a24bbf8075
parent 5de7fc0bf0e2e36a8dcf619e95576219dcc13d70
author Petr Vandrovec [EMAIL PROTECTED] Sun, 22 Jul 2007 23:54:34 -0700
committer Petr Vandrovec [EMAIL PROTECTED] Sun, 22 Jul 2007 23:54:34 -0700
arch/i386/boot/video-bios.c |3 ++-
arch/i386/boot/video-vesa.c | 48 +++
arch/i386/boot/video-vga.c | 20 +-
arch/i386/boot/video.c | 39 ---
arch/i386/boot/video.h |3 ++-
5 files changed, 89 insertions(+), 24 deletions(-)
diff --git a/arch/i386/boot/video-bios.c b/arch/i386/boot/video-bios.c
index afea46c..376ff71 100644
--- a/arch/i386/boot/video-bios.c
+++ b/arch/i386/boot/video-bios.c
@@ -104,6 +104,7 @@ static int bios_probe(void)
mi = GET_HEAP(struct mode_info, 1);
mi-mode = VIDEO_FIRST_BIOS+mode;
+ mi-depth = 0; /* text */
mi-x = rdfs16(0x44a);
mi-y = rdfs8(0x484)+1;
nmodes++;
@@ -116,7 +117,7 @@ static int bios_probe(void)
__videocard video_bios =
{
- .card_name = BIOS (scanned),
+ .card_name = BIOS,
.probe = bios_probe,
.set_mode = bios_set_mode,
.unsafe = 1,
diff --git a/arch/i386/boot/video-vesa.c b/arch/i386/boot/video-vesa.c
index e6aa9eb..af7019f 100644
--- a/arch/i386/boot/video-vesa.c
+++ b/arch/i386/boot/video-vesa.c
@@ -28,7 +28,7 @@ static void vesa_store_mode_params_graphics(void);
static int vesa_probe(void)
{
-#if defined(CONFIG_VIDEO_VESA) || defined(CONFIG_FIRMWARE_EDID)
+#if defined(CONFIG_VIDEO_SELECT) || defined(CONFIG_FIRMWARE_EDID)
u16 ax;
u16 mode;
addr_t mode_ptr;
@@ -47,8 +47,8 @@ static int vesa_probe(void)
vginfo.signature != VESA_MAGIC ||
vginfo.version 0x0102)
return 0; /* Not present */
-#endif /* CONFIG_VIDEO_VESA || CONFIG_FIRMWARE_EDID */
-#ifdef CONFIG_VIDEO_VESA
+#endif /* CONFIG_VIDEO_SELECT || CONFIG_FIRMWARE_EDID */
+#ifdef CONFIG_VIDEO_SELECT
set_fs(vginfo.video_mode_ptr.seg);
mode_ptr = vginfo.video_mode_ptr.off;
@@ -75,19 +75,49 @@ static int vesa_probe(void)
/* Text Mode, TTY BIOS supported,
supported by hardware */
mi = GET_HEAP(struct mode_info, 1);
- mi-mode = mode + VIDEO_FIRST_VESA;
- mi-x= vminfo.h_res;
- mi-y= vminfo.v_res;
+ mi-mode = mode + VIDEO_FIRST_VESA;
+ mi-depth = 0; /* text */
+ mi-x = vminfo.h_res;
+ mi-y = vminfo.v_res;
nmodes++;
} else if ((vminfo.mode_attr 0x99) == 0x99) {
#ifdef CONFIG_FB
/* Graphics mode, color, linear frame buffer
- supported -- register the mode but hide from
+ supported -- register the mode, and if there
+ is no VESA framebuffer then hide from
the menu. Only do this if framebuffer is
configured, however, otherwise the user will
be left without a screen. */
mi = GET_HEAP(struct mode_info, 1);
- mi-mode = mode + VIDEO_FIRST_VESA;
+ mi-mode = mode + VIDEO_FIRST_VESA;
+ mi-depth = 7; /* ugly graphics */
+#ifdef
Re: [PATCH] NCP: Delete test of long-deceased CONFIG_NCPFS_DEBUGDENTRY.
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Fine with me. Thanks.
Acked-by: Petr Vandrovec <[EMAIL PROTECTED]>
---
steve walks warily down the street with the brim pulled way down low
...
diff --git a/fs/ncpfs/ncplib_kernel.c b/fs/ncpfs/ncplib_kernel.c
index 551e0ba..df6d60b 100644
--- a/fs/ncpfs/ncplib_kernel.c
+++ b/fs/ncpfs/ncplib_kernel.c
@@ -726,9 +726,6 @@ ncp_del_file_or_subdir2(struct ncp_server *server,
__le32 dirent;
if (!inode) {
-#ifdef CONFIG_NCPFS_DEBUGDENTRY
- PRINTK("ncpfs: ncpdel2: dentry->d_inode == NULL\n");
-#endif
return 0xFF;/* Any error */
}
volnum = NCP_FINFO(inode)->volNumber;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NCP: Delete test of long-deceased CONFIG_NCPFS_DEBUGDENTRY.
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
Fine with me. Thanks.
Acked-by: Petr Vandrovec [EMAIL PROTECTED]
---
steve walks warily down the street with the brim pulled way down low
...
diff --git a/fs/ncpfs/ncplib_kernel.c b/fs/ncpfs/ncplib_kernel.c
index 551e0ba..df6d60b 100644
--- a/fs/ncpfs/ncplib_kernel.c
+++ b/fs/ncpfs/ncplib_kernel.c
@@ -726,9 +726,6 @@ ncp_del_file_or_subdir2(struct ncp_server *server,
__le32 dirent;
if (!inode) {
-#ifdef CONFIG_NCPFS_DEBUGDENTRY
- PRINTK(ncpfs: ncpdel2: dentry-d_inode == NULL\n);
-#endif
return 0xFF;/* Any error */
}
volnum = NCP_FINFO(inode)-volNumber;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fusion MPT regression, fixed or not?
Matt Sealey wrote: Hello World, I re-stumbled on this installing Gentoo on VMware today; http://lkml.org/lkml/2007/3/23/312 It doesn't seem to be fixed in 2.6.22-rc7, but I might be mistaken somehow. Has anyone done any work on this or looked at the problem in more detail? The trail seems to die at that thread. Not that it is relevant to LKML, but you need either upgrade to VMware Workstation 6.0, or you need patch later in that thread: http://lkml.org/lkml/2007/3/23/345 It is affecting VMware for me mainly but a lot of heavy server hardware seems to use the chip, in fact some I am looking at right now to recommend purchasing on.. I'd really like to use the latest kernel because virtualisation is the key (dynamic ticks and tickless hz and the latest virtualisation options would help eke out more value ;) It affects only VMware's emulation, not real hardware (at least unless you hit one with broken firmware). Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fusion MPT regression, fixed or not?
Matt Sealey wrote: Hello World, I re-stumbled on this installing Gentoo on VMware today; http://lkml.org/lkml/2007/3/23/312 It doesn't seem to be fixed in 2.6.22-rc7, but I might be mistaken somehow. Has anyone done any work on this or looked at the problem in more detail? The trail seems to die at that thread. Not that it is relevant to LKML, but you need either upgrade to VMware Workstation 6.0, or you need patch later in that thread: http://lkml.org/lkml/2007/3/23/345 It is affecting VMware for me mainly but a lot of heavy server hardware seems to use the chip, in fact some I am looking at right now to recommend purchasing on.. I'd really like to use the latest kernel because virtualisation is the key (dynamic ticks and tickless hz and the latest virtualisation options would help eke out more value ;) It affects only VMware's emulation, not real hardware (at least unless you hit one with broken firmware). Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc5-yesterdaygit with VM debug: BUG in mm/rmap.c:66: anon_vma_link ?
Hello,
to catch some memory corruption bug in our code I've modified malloc
to do mmap + mprotect - which has unfortunate effect that it creates
thousands and thousands of VMAs. Everything works (though rather slowly
on kernel with CONFIG_VM_DEBUG) until application does fork() - kernel
crashes on fork() because copy_process()'s anon_vma_link complains that
it could not find anon vma after walking through 10 elements of anon
list - which seems strange, as I did not touch system wide limit (which
is 65536 vmas), and mprotect()s started failing after creating 65536
vmas, as expected.
Full output of test program and full kernel dmesg are at
http://buk.vc.cvut.cz/linux/rmap.
Thanks,
Petr Vandrovec
#include
#include
#include
#include
#define TRY_REGIONS 131072
int main(void) {
unsigned char* ptr[TRY_REGIONS];
int i;
int fd;
int badmprot = 0;
char buf[16384];
ssize_t l;
printf("PID=%u\n", getpid());
for (i = 0; i < TRY_REGIONS; i++) {
ptr[i] = mmap(0, 8192, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS, -1, 0);
if (ptr[i] == MAP_FAILED) {
break;
}
if (mprotect(ptr[i] + 4096, 4096, PROT_NONE)) {
badmprot++;
}
}
printf("Allocated %u regions, %u mprotects failed\n", i, badmprot);
fflush(stdout);
fd = open("/proc/self/maps", O_RDONLY);
while ((l = read(fd, buf, sizeof buf)) > 0) {
write(1, buf, l);
}
close(fd);
fork();
return 0;
}
PID=6101
Allocated 131072 regions, 98310 mprotects failed
08048000-08049000 r-xp 08:05 1163513
/root/test
08049000-0804a000 rw-p 08:05 1163513
/root/test
b7e37000-e7e44000 rw-p b7e37000 00:00 0
e7e44000-e7e45000 ---p e7e44000 00:00 0
e7e45000-e7e46000 rw-p e7e45000 00:00 0
[65525 lines removed]
f7f7b000-f7f7c000 ---p f7f7b000 00:00 0
f7f7c000-f7f7f000 rw-p f7f7c000 00:00 0
f7f7f000-f7f9a000 r-xp 08:05 15581230
/lib/ld-2.5.so
f7f9a000-f7f9c000 rw-p 0001b000 08:05 15581230
/lib/ld-2.5.so
ff869000-ff8ef000 rw-p ff869000 00:00 0
[stack]
e000-f000 r-xp e000 00:00 0
[vdso]
[ cut here ]
kernel BUG at /usr/src/linus/linux-2.6.22-rc5-7515/mm/rmap.c:66!
invalid opcode: [1] PREEMPT SMP
CPU 0
Modules linked in: binfmt_misc rfcomm l2cap nfs nfsd exportfs lockd
nfs_acl sunrpc ipx p8022 psnap llc p8023 ppdev lp af_packet aoe deflate
zlib_deflate zlib_inflate twofish twofish_common camellia serpent
blowfish des cbc ecb blkcipher aes xcbc sha256 sha1 crypto_null hmac
crypto_hash cryptomgr af_key nls_utf8 nls_iso8859_2 ntfs fuse sbp2 loop
hci_usb raw1394 dv1394 bluetooth usb_storage usbhid libusual
snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer firewire_ohci
firewire_core sg snd crc_itu_t parport_pc parport sky2 k8temp 8250_pnp
8250 serial_core sr_mod serio_raw hwmon sata_sil24 ohci1394 ieee1394
ohci_hcd ehci_hcd cdrom snd_page_alloc usbcore i2c_nforce2
Pid: 6101, comm: test Not tainted 2.6.22-rc5-7515-64 #1
RIP: 0010:[] [] anon_vma_link+0x8b/0xa0
RSP: 0018:810111d4fd88 EFLAGS: 00010202
RAX: 8101109fb9e0 RBX: 8101109fb978 RCX: 8101109fb978
RDX: 810112fccf10 RSI: 000186a1 RDI:
RBP: 810111d4fd98 R08: 810112fccf10 R09:
R10: 8029874b R11: R12: 810112fccee0
R13: 01200011 R14: 810111590080 R15: 810111590080
FS: () GS:80652000(0063) knlGS:f7e196c0
CS: 0010 DS: 002b ES: 002b CR0: 8005003b
CR2: f7eaa7c0 CR3: 000111c17000 CR4: 06e0
Process test (pid: 6101, threadinfo 810111d4e000, task 810112fcf080)
Stack: 0001 8101109fb978 810111d4fe78 8023817c
8061d688 8101140e00e0 8101115901b8 81012560d148
8101115906a0 810111ebd760 f7e19708
Call Trace:
[] copy_process+0xb9c/0x1760
[] alloc_pid+0x212/0x320
[] do_fork+0xa3/0x290
[] _spin_unlock+0x30/0x60
[] __fput+0x176/0x1c0
[] sys32_clone+0x27/0x30
[] ia32_ptregs_common+0x25/0x50
Code: 0f 0b eb fe 0f 0b eb fe 66 0f 1f 44 00 00 0f 1f 80 00 00 00
RIP [] anon_vma_link+0x8b/0xa0
RSP
note: test[6101] exited with preempt_count 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc5-yesterdaygit with VM debug: BUG in mm/rmap.c:66: anon_vma_link ?
Hello,
to catch some memory corruption bug in our code I've modified malloc
to do mmap + mprotect - which has unfortunate effect that it creates
thousands and thousands of VMAs. Everything works (though rather slowly
on kernel with CONFIG_VM_DEBUG) until application does fork() - kernel
crashes on fork() because copy_process()'s anon_vma_link complains that
it could not find anon vma after walking through 10 elements of anon
list - which seems strange, as I did not touch system wide limit (which
is 65536 vmas), and mprotect()s started failing after creating 65536
vmas, as expected.
Full output of test program and full kernel dmesg are at
http://buk.vc.cvut.cz/linux/rmap.
Thanks,
Petr Vandrovec
#include sys/mman.h
#include stdio.h
#include unistd.h
#include fcntl.h
#define TRY_REGIONS 131072
int main(void) {
unsigned char* ptr[TRY_REGIONS];
int i;
int fd;
int badmprot = 0;
char buf[16384];
ssize_t l;
printf(PID=%u\n, getpid());
for (i = 0; i TRY_REGIONS; i++) {
ptr[i] = mmap(0, 8192, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS, -1, 0);
if (ptr[i] == MAP_FAILED) {
break;
}
if (mprotect(ptr[i] + 4096, 4096, PROT_NONE)) {
badmprot++;
}
}
printf(Allocated %u regions, %u mprotects failed\n, i, badmprot);
fflush(stdout);
fd = open(/proc/self/maps, O_RDONLY);
while ((l = read(fd, buf, sizeof buf)) 0) {
write(1, buf, l);
}
close(fd);
fork();
return 0;
}
PID=6101
Allocated 131072 regions, 98310 mprotects failed
08048000-08049000 r-xp 08:05 1163513
/root/test
08049000-0804a000 rw-p 08:05 1163513
/root/test
b7e37000-e7e44000 rw-p b7e37000 00:00 0
e7e44000-e7e45000 ---p e7e44000 00:00 0
e7e45000-e7e46000 rw-p e7e45000 00:00 0
[65525 lines removed]
f7f7b000-f7f7c000 ---p f7f7b000 00:00 0
f7f7c000-f7f7f000 rw-p f7f7c000 00:00 0
f7f7f000-f7f9a000 r-xp 08:05 15581230
/lib/ld-2.5.so
f7f9a000-f7f9c000 rw-p 0001b000 08:05 15581230
/lib/ld-2.5.so
ff869000-ff8ef000 rw-p ff869000 00:00 0
[stack]
e000-f000 r-xp e000 00:00 0
[vdso]
[ cut here ]
kernel BUG at /usr/src/linus/linux-2.6.22-rc5-7515/mm/rmap.c:66!
invalid opcode: [1] PREEMPT SMP
CPU 0
Modules linked in: binfmt_misc rfcomm l2cap nfs nfsd exportfs lockd
nfs_acl sunrpc ipx p8022 psnap llc p8023 ppdev lp af_packet aoe deflate
zlib_deflate zlib_inflate twofish twofish_common camellia serpent
blowfish des cbc ecb blkcipher aes xcbc sha256 sha1 crypto_null hmac
crypto_hash cryptomgr af_key nls_utf8 nls_iso8859_2 ntfs fuse sbp2 loop
hci_usb raw1394 dv1394 bluetooth usb_storage usbhid libusual
snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer firewire_ohci
firewire_core sg snd crc_itu_t parport_pc parport sky2 k8temp 8250_pnp
8250 serial_core sr_mod serio_raw hwmon sata_sil24 ohci1394 ieee1394
ohci_hcd ehci_hcd cdrom snd_page_alloc usbcore i2c_nforce2
Pid: 6101, comm: test Not tainted 2.6.22-rc5-7515-64 #1
RIP: 0010:[802987bb] [802987bb] anon_vma_link+0x8b/0xa0
RSP: 0018:810111d4fd88 EFLAGS: 00010202
RAX: 8101109fb9e0 RBX: 8101109fb978 RCX: 8101109fb978
RDX: 810112fccf10 RSI: 000186a1 RDI:
RBP: 810111d4fd98 R08: 810112fccf10 R09:
R10: 8029874b R11: R12: 810112fccee0
R13: 01200011 R14: 810111590080 R15: 810111590080
FS: () GS:80652000(0063) knlGS:f7e196c0
CS: 0010 DS: 002b ES: 002b CR0: 8005003b
CR2: f7eaa7c0 CR3: 000111c17000 CR4: 06e0
Process test (pid: 6101, threadinfo 810111d4e000, task 810112fcf080)
Stack: 0001 8101109fb978 810111d4fe78 8023817c
8061d688 8101140e00e0 8101115901b8 81012560d148
8101115906a0 810111ebd760 f7e19708
Call Trace:
[8023817c] copy_process+0xb9c/0x1760
[8024dd72] alloc_pid+0x212/0x320
[80238ed3] do_fork+0xa3/0x290
[804c6880] _spin_unlock+0x30/0x60
[802aebb6] __fput+0x176/0x1c0
[80227ce7] sys32_clone+0x27/0x30
[802279d5] ia32_ptregs_common+0x25/0x50
Code: 0f 0b eb fe 0f 0b eb fe 66 0f 1f 44 00 00 0f 1f 80 00 00 00
RIP [802987bb] anon_vma_link+0x8b/0xa0
RSP 810111d4fd88
note: test[6101] exited with preempt_count 1
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Hello,
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, "Debug enabled or not");
+static int __init root_plug_debug(char *str)
+{
+ debug = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup("root_plug_debug=", root_plug_debug);
is this necessary? What about just documenting
root_plug.{vendor_id,product_id,debug}, so it won't break existing
root_plug users (if there are any) ? I thought that typed
module_param() is prefered over untyped __setup()...
Thanks,
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Robert Hancock wrote:
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP",ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00","SBDIC7JP",ATA_HORKAGE_NONCQ, },
+{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL,ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
Is that the right ID string? Strange that that one has Hitachi at the
front and the others don't..
Yeah, I realized that and asked Enrico about it. :-)
I think that "new" one is correct, while old ones are incorrect (unless
it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
(which seems to work fine with NCQ):
gwy:~# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
SerialNo= VFA200R208LH5J
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm
output, and I think I verified the patch with the reporter. Hmm... Can
anyone verify these module strings?
Could well be that they've started attaching Hitachi to the ID strings
now.. In the past it hasn't seemed to have been Hitachi's (and IBM's
before that) practice to have it there, but maybe they see the advantage
of being able to figure out who made the drive now :-)
Perhaps ones sold directly by Hitachi are Hitachi, while ones sold
through OEMs are no-name?
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP",ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00","SBDIC7JP",ATA_HORKAGE_NONCQ, },
+{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL,ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
Is that the right ID string? Strange that that one has Hitachi at the
front and the others don't..
Yeah, I realized that and asked Enrico about it. :-)
I think that "new" one is correct, while old ones are incorrect (unless
it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
(which seems to work fine with NCQ):
gwy:~# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
SerialNo= VFA200R208LH5J
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Enrico Sardi [EMAIL PROTECTED]
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ HTS541680J9SA00,SB2IC7EP,ATA_HORKAGE_NONCQ, },
{ HTS541612J9SA00,SBDIC7JP,ATA_HORKAGE_NONCQ, },
+{ Hitachi HTS541616J9SA00, SB4OC70P, ATA_HORKAGE_NONCQ, },
{ WDC WD740ADFD-00NLR1, NULL,ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
Is that the right ID string? Strange that that one has Hitachi at the
front and the others don't..
Yeah, I realized that and asked Enrico about it. :-)
I think that new one is correct, while old ones are incorrect (unless
it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
(which seems to work fine with NCQ):
gwy:~# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
SerialNo= VFA200R208LH5J
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
Petr
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Robert Hancock wrote:
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ HTS541680J9SA00,SB2IC7EP,ATA_HORKAGE_NONCQ, },
{ HTS541612J9SA00,SBDIC7JP,ATA_HORKAGE_NONCQ, },
+{ Hitachi HTS541616J9SA00, SB4OC70P, ATA_HORKAGE_NONCQ, },
{ WDC WD740ADFD-00NLR1, NULL,ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
Is that the right ID string? Strange that that one has Hitachi at the
front and the others don't..
Yeah, I realized that and asked Enrico about it. :-)
I think that new one is correct, while old ones are incorrect (unless
it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
(which seems to work fine with NCQ):
gwy:~# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
SerialNo= VFA200R208LH5J
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm
output, and I think I verified the patch with the reporter. Hmm... Can
anyone verify these module strings?
Could well be that they've started attaching Hitachi to the ID strings
now.. In the past it hasn't seemed to have been Hitachi's (and IBM's
before that) practice to have it there, but maybe they see the advantage
of being able to figure out who made the drive now :-)
Perhaps ones sold directly by Hitachi are Hitachi, while ones sold
through OEMs are no-name?
Petr
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
James Morris wrote:
Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.
Hello,
-module_param(debug, bool, 0600);
-MODULE_PARM_DESC(debug, Debug enabled or not);
+static int __init root_plug_debug(char *str)
+{
+ debug = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup(root_plug_debug=, root_plug_debug);
is this necessary? What about just documenting
root_plug.{vendor_id,product_id,debug}, so it won't break existing
root_plug users (if there are any) ? I thought that typed
module_param() is prefered over untyped __setup()...
Thanks,
Petr
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
Stefan Richter wrote: On 7 May, Petr Vandrovec wrote: This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to 32bit applications running on 64bit kernel (tested on i386 app using x86_64 kernel). [...] With this in place I was able to run my test app and grab some mpegs, so I believe that I got everything necessary done. If you believe I have missed some ioctl, yell at me. Petr, thanks once again for the fixes. I took the liberty to split your patch into the read(), write(), and ioctl() parts but kept your From: and Signed-off-by: and Dan's ACK. Is this OK with you? I will reply to this message with Yes, of course. Thanks a lot. [PATCH 1/3] ieee1394: raw1394: Fix read() for 32bit userland on 64bit kernel [PATCH 2/3] ieee1394: raw1394: Fix write() for 32bit userland on 64bit kernel [PATCH 3/3] ieee1394: raw1394: Add ioctl() for 32bit userland on 64bit kernel I plan to do some own testing on a x86-64 box on Thursday and will then pass it upstream ASAP. Thanks. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
Stefan Richter wrote: On 7 May, Petr Vandrovec wrote: This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to 32bit applications running on 64bit kernel (tested on i386 app using x86_64 kernel). [...] With this in place I was able to run my test app and grab some mpegs, so I believe that I got everything necessary done. If you believe I have missed some ioctl, yell at me. Petr, thanks once again for the fixes. I took the liberty to split your patch into the read(), write(), and ioctl() parts but kept your From: and Signed-off-by: and Dan's ACK. Is this OK with you? I will reply to this message with Yes, of course. Thanks a lot. [PATCH 1/3] ieee1394: raw1394: Fix read() for 32bit userland on 64bit kernel [PATCH 2/3] ieee1394: raw1394: Fix write() for 32bit userland on 64bit kernel [PATCH 3/3] ieee1394: raw1394: Add ioctl() for 32bit userland on 64bit kernel I plan to do some own testing on a x86-64 box on Thursday and will then pass it upstream ASAP. Thanks. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: patch for vmware for Linux-2.6.21
Jeff Chua wrote:
On 5/14/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Mon, 2007-05-14 at 09:18 +0800, Jeff Chua wrote:
I'm sorry... but why are you posting these patches here? Those aren't
GPL modules, and thus very offtopic for lkml, maybe except for if you
want to deliberately have people look at non-gpl code ;(
I don't like these non-gpl code myself, but it allowed me to use
Linux-2.6.22 as a base to test the new kvm and hope to migrate to kvm
soon, and I'm sure some others out there would benefit from it as
well. I don't claim the code to be perfect, but by releasing to
others, hopefully someone can tell me where to improve on.
I would strongly recommend you using my patches from
http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update110.tar.gz.
Patch you've created causes memory corruption on 2.6.22-rc1 (and few
previous kernels, since csum_start got introduced).
Best regards,
Petr Vandrovec
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: patch for vmware for Linux-2.6.21
Jeff Chua wrote: On 5/14/07, Arjan van de Ven [EMAIL PROTECTED] wrote: On Mon, 2007-05-14 at 09:18 +0800, Jeff Chua wrote: I'm sorry... but why are you posting these patches here? Those aren't GPL modules, and thus very offtopic for lkml, maybe except for if you want to deliberately have people look at non-gpl code ;( I don't like these non-gpl code myself, but it allowed me to use Linux-2.6.22 as a base to test the new kvm and hope to migrate to kvm soon, and I'm sure some others out there would benefit from it as well. I don't claim the code to be perfect, but by releasing to others, hopefully someone can tell me where to improve on. I would strongly recommend you using my patches from http://platan.vc.cvut.cz/ftp/pub/vmware/vmware-any-any-update110.tar.gz. Patch you've created causes memory corruption on 2.6.22-rc1 (and few previous kernels, since csum_start got introduced). Best regards, Petr Vandrovec - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix/add raw1394 CONFIG_COMPAT code
Hello Dan,
This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to 32bit
applications running on 64bit kernel (tested on i386 app using x86_64 kernel).
I
had to make following changes:
* read() always failed with -EFAULT. This was happening due to
raw1394_compat_read copying data to wrong location - access_ok always
failed as 'r' is kernel address, not user. Whole function just tried to
copy data from 'r' to 'r', which is not good.
* write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not
care, but some (arm registration) did, and anyway it looks bad if request for
writing 52 bytes returns 56. And returning sizeof anything in 'int' is not
good as well. So all functions now return '0' instead of
sizeof(struct raw1394_request) on success, and write() itself provides correct
return value (it just returns value it was asked to write on success as
raw1394
does not do any partial writes at all).
* Related to this was problem that write() could have returned 0 when kernel
state would become corrupted and moved to different state than
opened/initialized/connected. Now it returns -EBADFD which seemed
appropriate.
* And add compat_ioctl. Although all structures are more or less same,
raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted
padding in the middle. I did not add any translation for ioctls passing array
of integers around as integers seem to have same size (32 bits) on all
architectures supported by Linux.
With this in place I was able to run my test app and grab some mpegs, so I
believe
that I got everything necessary done. If you believe I have missed some ioctl,
yell
at me.
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -uprdN linux/drivers/ieee1394/raw1394.c linux/drivers/ieee1394/raw1394.c
--- linux/drivers/ieee1394/raw1394.c2007-05-06 17:45:47.0 -0700
+++ linux/drivers/ieee1394/raw1394.c2007-05-06 18:08:05.0 -0700
@@ -460,7 +460,7 @@ static const char __user *raw1394_compat
static int
raw1394_compat_read(const char __user *buf, struct raw1394_request *r)
{
- struct compat_raw1394_req __user *cr = (typeof(cr)) r;
+ struct compat_raw1394_req __user *cr = (typeof(cr)) buf;
if (!access_ok(VERIFY_WRITE, cr, sizeof(struct compat_raw1394_req)) ||
P(type) ||
P(error) ||
@@ -588,7 +588,7 @@ static int state_opened(struct file_info
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
static int state_initialized(struct file_info *fi, struct pending_request *req)
@@ -602,7 +602,7 @@ static int state_initialized(struct file
req->req.generation = atomic_read(_generation);
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
switch (req->req.type) {
@@ -674,7 +674,7 @@ out_set_card:
}
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
static void handle_iso_listen(struct file_info *fi, struct pending_request
*req)
@@ -866,7 +866,7 @@ static int handle_async_request(struct f
if (req->req.error) {
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
hpsb_set_packet_complete_task(packet,
@@ -884,7 +884,7 @@ static int handle_async_request(struct f
hpsb_free_tlabel(packet);
queue_complete_req(req);
}
- return sizeof(struct raw1394_request);
+ return 0;
}
static int handle_iso_send(struct file_info *fi, struct pending_request *req,
@@ -908,7 +908,7 @@ static int handle_iso_send(struct file_i
req->req.error = RAW1394_ERROR_MEMFAULT;
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
req->req.length = 0;
@@ -928,7 +928,7 @@ static int handle_iso_send(struct file_i
queue_complete_req(req);
}
- return sizeof(struct raw1394_request);
+ return 0;
}
static int handle_async_send(struct file_info *fi, struct pending_request *req)
@@ -943,7 +943,7 @@ static int handle_async_send(struct file
req->req.error = RAW1394_ERROR_INVALID_ARG;
req->req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
packet = hpsb_alloc_packet(req->req.length - header_length);
@@ -956,7 +956,7 @
[PATCH] Fix/add raw1394 CONFIG_COMPAT code
Hello Dan,
This patch makes raw1394 in current Linux git tree (2.6.21-1570) usable to 32bit
applications running on 64bit kernel (tested on i386 app using x86_64 kernel).
I
had to make following changes:
* read() always failed with -EFAULT. This was happening due to
raw1394_compat_read copying data to wrong location - access_ok always
failed as 'r' is kernel address, not user. Whole function just tried to
copy data from 'r' to 'r', which is not good.
* write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not
care, but some (arm registration) did, and anyway it looks bad if request for
writing 52 bytes returns 56. And returning sizeof anything in 'int' is not
good as well. So all functions now return '0' instead of
sizeof(struct raw1394_request) on success, and write() itself provides correct
return value (it just returns value it was asked to write on success as
raw1394
does not do any partial writes at all).
* Related to this was problem that write() could have returned 0 when kernel
state would become corrupted and moved to different state than
opened/initialized/connected. Now it returns -EBADFD which seemed
appropriate.
* And add compat_ioctl. Although all structures are more or less same,
raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted
padding in the middle. I did not add any translation for ioctls passing array
of integers around as integers seem to have same size (32 bits) on all
architectures supported by Linux.
With this in place I was able to run my test app and grab some mpegs, so I
believe
that I got everything necessary done. If you believe I have missed some ioctl,
yell
at me.
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
diff -uprdN linux/drivers/ieee1394/raw1394.c linux/drivers/ieee1394/raw1394.c
--- linux/drivers/ieee1394/raw1394.c2007-05-06 17:45:47.0 -0700
+++ linux/drivers/ieee1394/raw1394.c2007-05-06 18:08:05.0 -0700
@@ -460,7 +460,7 @@ static const char __user *raw1394_compat
static int
raw1394_compat_read(const char __user *buf, struct raw1394_request *r)
{
- struct compat_raw1394_req __user *cr = (typeof(cr)) r;
+ struct compat_raw1394_req __user *cr = (typeof(cr)) buf;
if (!access_ok(VERIFY_WRITE, cr, sizeof(struct compat_raw1394_req)) ||
P(type) ||
P(error) ||
@@ -588,7 +588,7 @@ static int state_opened(struct file_info
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
static int state_initialized(struct file_info *fi, struct pending_request *req)
@@ -602,7 +602,7 @@ static int state_initialized(struct file
req-req.generation = atomic_read(internal_generation);
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
switch (req-req.type) {
@@ -674,7 +674,7 @@ out_set_card:
}
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
static void handle_iso_listen(struct file_info *fi, struct pending_request
*req)
@@ -866,7 +866,7 @@ static int handle_async_request(struct f
if (req-req.error) {
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
hpsb_set_packet_complete_task(packet,
@@ -884,7 +884,7 @@ static int handle_async_request(struct f
hpsb_free_tlabel(packet);
queue_complete_req(req);
}
- return sizeof(struct raw1394_request);
+ return 0;
}
static int handle_iso_send(struct file_info *fi, struct pending_request *req,
@@ -908,7 +908,7 @@ static int handle_iso_send(struct file_i
req-req.error = RAW1394_ERROR_MEMFAULT;
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
req-req.length = 0;
@@ -928,7 +928,7 @@ static int handle_iso_send(struct file_i
queue_complete_req(req);
}
- return sizeof(struct raw1394_request);
+ return 0;
}
static int handle_async_send(struct file_info *fi, struct pending_request *req)
@@ -943,7 +943,7 @@ static int handle_async_send(struct file
req-req.error = RAW1394_ERROR_INVALID_ARG;
req-req.length = 0;
queue_complete_req(req);
- return sizeof(struct raw1394_request);
+ return 0;
}
packet = hpsb_alloc_packet(req-req.length - header_length);
@@ -956,7 +956,7 @@ static int handle_async_send(struct file
req
Re: VMware, x86_64 and 2.6.21.
Nigel Cunningham wrote: Hi Arjan. On Tue, 2007-05-01 at 07:57 -0700, Arjan van de Ven wrote: On Tue, 2007-05-01 at 15:42 +1000, Nigel Cunningham wrote: Hi. Does anyone have VMware working on x86_64 with 2.6.21? It's working fine for me with 2.6.20, but freezes the whole computer with 2.6.21. Before I start a git-bisect, I thought I might ask if anyone knew of some compilation option I might have missed. if you want to ask questions about proprietary kernel stuff you're better off asking the vendor directly, not lkml I did, but given that it the failure only appeared with a change of vanilla kernel version, I didn't think it was out of place to ask here too. I thought I already talked about that on VMware's forums, but apparently I just discussed it in email only. Culprit (if I can say that) is http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=610142927b5bc149da92b03c7ab08b8b5f205b74 It changed interrupt layout - before that change IRQ 0-15 were using vectors 0x20-0x2F, after change they use interrupts 0x30-0x3F. Which has unfortunate effect that when hardware IRQ 8 arrives while VM is running, vmm believes that it internally used 'INT 0x38' to call some hypervisor service - and (1) hardware interrupt is never acknowledged, and (2) hypervisor issues random operation depending on contents of registers at the time interrupt arrived. Both are quite bad, and usual result is that VMware panics, and while writing core dump kernel hangs as IOAPIC believes that there is IRQ 8 in service, and so it does not ever deliver IRQs 14/15 for legacy IDE harddisks (which are at same level). One of possible fixes (if you need to run older products than VMware Workstation 6 on 64bit 2.6.21+) is replacing #define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x10 with #define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x08 Then IRQ 0x38 will be skipped. Other option is move only IRQ8_VECTOR somewhere else (into 0x21-0x2F range). Petr Vandrovec P.S.: Well, and obviously this has nothing to do with vmmon... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VMware, x86_64 and 2.6.21.
Nigel Cunningham wrote: Hi Arjan. On Tue, 2007-05-01 at 07:57 -0700, Arjan van de Ven wrote: On Tue, 2007-05-01 at 15:42 +1000, Nigel Cunningham wrote: Hi. Does anyone have VMware working on x86_64 with 2.6.21? It's working fine for me with 2.6.20, but freezes the whole computer with 2.6.21. Before I start a git-bisect, I thought I might ask if anyone knew of some compilation option I might have missed. if you want to ask questions about proprietary kernel stuff you're better off asking the vendor directly, not lkml I did, but given that it the failure only appeared with a change of vanilla kernel version, I didn't think it was out of place to ask here too. I thought I already talked about that on VMware's forums, but apparently I just discussed it in email only. Culprit (if I can say that) is http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=610142927b5bc149da92b03c7ab08b8b5f205b74 It changed interrupt layout - before that change IRQ 0-15 were using vectors 0x20-0x2F, after change they use interrupts 0x30-0x3F. Which has unfortunate effect that when hardware IRQ 8 arrives while VM is running, vmm believes that it internally used 'INT 0x38' to call some hypervisor service - and (1) hardware interrupt is never acknowledged, and (2) hypervisor issues random operation depending on contents of registers at the time interrupt arrived. Both are quite bad, and usual result is that VMware panics, and while writing core dump kernel hangs as IOAPIC believes that there is IRQ 8 in service, and so it does not ever deliver IRQs 14/15 for legacy IDE harddisks (which are at same level). One of possible fixes (if you need to run older products than VMware Workstation 6 on 64bit 2.6.21+) is replacing #define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x10 with #define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x08 Then IRQ 0x38 will be skipped. Other option is move only IRQ8_VECTOR somewhere else (into 0x21-0x2F range). Petr Vandrovec P.S.: Well, and obviously this has nothing to do with vmmon... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VMWare Workstation 6 for debugging Linux Kernel (!)
Andi Kleen wrote:
Xavier Bestel <[EMAIL PROTECTED]> writes:
On Fri, 2007-04-20 at 00:46 +0200, roland wrote:
We just quietly added an exciting feature to Workstation 6.0. I believe it
will make WS6 a great tool for Linux kernel development. You can now debug
kernel of Linux VM with gdb running on the Host without changing anything in
the Guest VM. No kdb, no recompiling and no need for second machine. All you
need is a single line in VM's configuration file.
I think qemu has the exact same feature.
It doesn't seem to work for x86-64 there though.
Hello,
Do you mean with qemu or with VMware? Yes, we do not support replay
with 64bit guests, but debug interface should just work. Only gotcha is
that for 64bit guest you need another option:
debugStub.listen.guest64 = "TRUE"
and then you need to attach gdb to port 8864 (*). Unfortunately it does
not seem possible to build gdb which would support 16bit/32bit code
while using 64bit gdb on-wire format, so there are two interfaces. And
if you single-step switch from 64bit mode to 32bit mode or back, you
also have to switch gdbs. Yes, it is a bit unintuitive, and
additionally one gdb silently ignores breakpoints set up by other gdb,
so you need to keep breakpoints in sync between two gdbs yourself :-(
(*) If you are using gdb which has both 32bit and 64bit support, be sure
to issue appropriate 'set architecture xxx' before 'target remote
localhost:88xx' (i386:x86-64 for port 8864, i386 or i8086 for port
8832). Otherwise gdb is going to die complaining it could not parse
remote reply.
Best regards,
Petr Vandrovec
P.S.: Yes, I'm associated with VMware.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VMWare Workstation 6 for debugging Linux Kernel (!)
Andi Kleen wrote: Xavier Bestel [EMAIL PROTECTED] writes: On Fri, 2007-04-20 at 00:46 +0200, roland wrote: We just quietly added an exciting feature to Workstation 6.0. I believe it will make WS6 a great tool for Linux kernel development. You can now debug kernel of Linux VM with gdb running on the Host without changing anything in the Guest VM. No kdb, no recompiling and no need for second machine. All you need is a single line in VM's configuration file. I think qemu has the exact same feature. It doesn't seem to work for x86-64 there though. Hello, Do you mean with qemu or with VMware? Yes, we do not support replay with 64bit guests, but debug interface should just work. Only gotcha is that for 64bit guest you need another option: debugStub.listen.guest64 = TRUE and then you need to attach gdb to port 8864 (*). Unfortunately it does not seem possible to build gdb which would support 16bit/32bit code while using 64bit gdb on-wire format, so there are two interfaces. And if you single-step switch from 64bit mode to 32bit mode or back, you also have to switch gdbs. Yes, it is a bit unintuitive, and additionally one gdb silently ignores breakpoints set up by other gdb, so you need to keep breakpoints in sync between two gdbs yourself :-( (*) If you are using gdb which has both 32bit and 64bit support, be sure to issue appropriate 'set architecture xxx' before 'target remote localhost:88xx' (i386:x86-64 for port 8864, i386 or i8086 for port 8832). Otherwise gdb is going to die complaining it could not parse remote reply. Best regards, Petr Vandrovec P.S.: Yes, I'm associated with VMware. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Correctly report PnP 64bit resources
Hello,
today I noticed that kernel with 64bit I/O resources reports
incorrect /proc/iomem due to resource_size_t => int => resource_size_t
conversion in drivers/pnp/system.c, turning addresses 2-4GB into
very huge addresses at the top of 64bit address space.
Differences between old and new /proc/iomem and dmesg are below, as well
as a patch (for current git tree). After this change kernel with 64bit
resources now reports same errors as one built with 32bit resources only -
- which is apparently correct behavior.
If you are interested, these ranges failed to be reserved:
ceee-ceef are ACPI tables,
cf00-cfff is shared memory for on-board videocard,
f000-f3ff is MMCONFIG, and
feff-feff00ff is part of HPET (seems to be violation of spec)
--- memres-before 2007-03-31 01:41:40.0 -0700
+++ memres-after2007-03-31 01:43:47.0 -0700
@@ -48,12 +48,8 @@
fe02f000-fe02 : ohci_hcd
fec0-fec00fff : IOAPIC 0
fee0-fee00fff : Local APIC
+fefe-fefe01ff : pnp 00:01
+fefe1000-fefe10ff : pnp 00:01
feff-feff03ff : HPET 0
+- : pnp 00:0c
1-12fff : System RAM
-ceee-ceef : pnp 00:0c
-cf00-cfff : pnp 00:01
-f000-f3ff : pnp 00:0b
-fefe-fefe01ff : pnp 00:01
-fefe1000-fefe10ff : pnp 00:01
-feff-feff00ff : pnp 00:0c
-- : pnp 00:0c
--- dmesg-before2007-03-31 00:18:50.0 -0700
+++ dmesg-after 2007-03-31 01:46:20.0 -0700
@@ -225,11 +225,11 @@
pnp: 00:01: iomem range 0x0-0x0 could not be reserved
pnp: 00:01: iomem range 0xfefe-0xfefe01ff has been reserved
pnp: 00:01: iomem range 0xfefe1000-0xfefe10ff has been reserved
-pnp: 00:01: iomem range 0xcf00-0xcfff has been reserved
-pnp: 00:0b: iomem range 0xf000-0xf3ff has been reserved
+pnp: 00:01: iomem range 0xcf00-0xcfff could not be reserved
+pnp: 00:0b: iomem range 0xf000-0xf3ff could not be reserved
pnp: 00:0c: iomem range 0xf-0xf could not be reserved
-pnp: 00:0c: iomem range 0xfeff-0xfeff00ff has been reserved
-pnp: 00:0c: iomem range 0xceee-0xceef has been reserved
+pnp: 00:0c: iomem range 0xfeff-0xfeff00ff could not be reserved
+pnp: 00:0c: iomem range 0xceee-0xceef could not be reserved
pnp: 00:0c: iomem range 0x-0x has been reserved
PCI: Bridge: :00:04.0
IO window: b000-bfff
Thanks,
Petr Vandrovec
Change PnP resource handling code to use proper type for resource start and
length.
Fixes bogus regions reported in /proc/iomem.
I've also made some pointer constant, as they are constant...
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -uprdN linux/drivers/pnp/system.c linux/drivers/pnp/system.c
--- linux/drivers/pnp/system.c 2007-03-30 22:31:34.0 -0700
+++ linux/drivers/pnp/system.c 2007-03-31 01:40:03.0 -0700
@@ -22,7 +22,7 @@ static const struct pnp_device_id pnp_de
{ "", 0 }
};
-static void reserve_range(char *pnpid, int start, int end, int port)
+static void reserve_range(const char *pnpid, resource_size_t start,
resource_size_t end, int port)
{
struct resource *res;
char *regionid;
@@ -32,9 +32,9 @@ static void reserve_range(char *pnpid, i
return;
snprintf(regionid, 16, "pnp %s", pnpid);
if (port)
- res = request_region(start,end-start+1,regionid);
+ res = request_region(start, end-start+1, regionid);
else
- res = request_mem_region(start,end-start+1,regionid);
+ res = request_mem_region(start, end-start+1, regionid);
if (res == NULL)
kfree(regionid);
else
@@ -45,12 +45,13 @@ static void reserve_range(char *pnpid, i
* have double reservations.
*/
printk(KERN_INFO
- "pnp: %s: %s range 0x%x-0x%x %s reserved\n",
- pnpid, port ? "ioport" : "iomem", start, end,
+ "pnp: %s: %s range 0x%llx-0x%llx %s reserved\n",
+ pnpid, port ? "ioport" : "iomem",
+(unsigned long long)start, (unsigned long long)end,
NULL != res ? "has been" : "could not be");
}
-static void reserve_resources_of_dev(struct pnp_dev *dev)
+static void reserve_resources_of_dev(const struct pnp_dev *dev)
{
int i;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Correctly report PnP 64bit resources
Hello,
today I noticed that kernel with 64bit I/O resources reports
incorrect /proc/iomem due to resource_size_t = int = resource_size_t
conversion in drivers/pnp/system.c, turning addresses 2-4GB into
very huge addresses at the top of 64bit address space.
Differences between old and new /proc/iomem and dmesg are below, as well
as a patch (for current git tree). After this change kernel with 64bit
resources now reports same errors as one built with 32bit resources only -
- which is apparently correct behavior.
If you are interested, these ranges failed to be reserved:
ceee-ceef are ACPI tables,
cf00-cfff is shared memory for on-board videocard,
f000-f3ff is MMCONFIG, and
feff-feff00ff is part of HPET (seems to be violation of spec)
--- memres-before 2007-03-31 01:41:40.0 -0700
+++ memres-after2007-03-31 01:43:47.0 -0700
@@ -48,12 +48,8 @@
fe02f000-fe02 : ohci_hcd
fec0-fec00fff : IOAPIC 0
fee0-fee00fff : Local APIC
+fefe-fefe01ff : pnp 00:01
+fefe1000-fefe10ff : pnp 00:01
feff-feff03ff : HPET 0
+- : pnp 00:0c
1-12fff : System RAM
-ceee-ceef : pnp 00:0c
-cf00-cfff : pnp 00:01
-f000-f3ff : pnp 00:0b
-fefe-fefe01ff : pnp 00:01
-fefe1000-fefe10ff : pnp 00:01
-feff-feff00ff : pnp 00:0c
-- : pnp 00:0c
--- dmesg-before2007-03-31 00:18:50.0 -0700
+++ dmesg-after 2007-03-31 01:46:20.0 -0700
@@ -225,11 +225,11 @@
pnp: 00:01: iomem range 0x0-0x0 could not be reserved
pnp: 00:01: iomem range 0xfefe-0xfefe01ff has been reserved
pnp: 00:01: iomem range 0xfefe1000-0xfefe10ff has been reserved
-pnp: 00:01: iomem range 0xcf00-0xcfff has been reserved
-pnp: 00:0b: iomem range 0xf000-0xf3ff has been reserved
+pnp: 00:01: iomem range 0xcf00-0xcfff could not be reserved
+pnp: 00:0b: iomem range 0xf000-0xf3ff could not be reserved
pnp: 00:0c: iomem range 0xf-0xf could not be reserved
-pnp: 00:0c: iomem range 0xfeff-0xfeff00ff has been reserved
-pnp: 00:0c: iomem range 0xceee-0xceef has been reserved
+pnp: 00:0c: iomem range 0xfeff-0xfeff00ff could not be reserved
+pnp: 00:0c: iomem range 0xceee-0xceef could not be reserved
pnp: 00:0c: iomem range 0x-0x has been reserved
PCI: Bridge: :00:04.0
IO window: b000-bfff
Thanks,
Petr Vandrovec
Change PnP resource handling code to use proper type for resource start and
length.
Fixes bogus regions reported in /proc/iomem.
I've also made some pointer constant, as they are constant...
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
diff -uprdN linux/drivers/pnp/system.c linux/drivers/pnp/system.c
--- linux/drivers/pnp/system.c 2007-03-30 22:31:34.0 -0700
+++ linux/drivers/pnp/system.c 2007-03-31 01:40:03.0 -0700
@@ -22,7 +22,7 @@ static const struct pnp_device_id pnp_de
{ , 0 }
};
-static void reserve_range(char *pnpid, int start, int end, int port)
+static void reserve_range(const char *pnpid, resource_size_t start,
resource_size_t end, int port)
{
struct resource *res;
char *regionid;
@@ -32,9 +32,9 @@ static void reserve_range(char *pnpid, i
return;
snprintf(regionid, 16, pnp %s, pnpid);
if (port)
- res = request_region(start,end-start+1,regionid);
+ res = request_region(start, end-start+1, regionid);
else
- res = request_mem_region(start,end-start+1,regionid);
+ res = request_mem_region(start, end-start+1, regionid);
if (res == NULL)
kfree(regionid);
else
@@ -45,12 +45,13 @@ static void reserve_range(char *pnpid, i
* have double reservations.
*/
printk(KERN_INFO
- pnp: %s: %s range 0x%x-0x%x %s reserved\n,
- pnpid, port ? ioport : iomem, start, end,
+ pnp: %s: %s range 0x%llx-0x%llx %s reserved\n,
+ pnpid, port ? ioport : iomem,
+(unsigned long long)start, (unsigned long long)end,
NULL != res ? has been : could not be);
}
-static void reserve_resources_of_dev(struct pnp_dev *dev)
+static void reserve_resources_of_dev(const struct pnp_dev *dev)
{
int i;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc regression in mptbase
> On Fri, Mar 23, 2007 at 11:39:12PM +0100, Jan Engelhardt wrote:
> > Hello world,
> >
> >
> > in at least 2.6.21-rc4, one or more of the mptscsi scsi modules is
> > broken with respect to not detecting any harddisk (VMware provides that
> > virtual LSI MPT controller), which means no working system.
> > No problems in 2.6.20.2.
> >...
>
> Could be a bug in the driver or a bug in the emulation exposed by a
> change in the driver.
>
> Can you bisect which change to the driver broke it?
Hello,
it is bug in the emulation. It should be fixed in Workstation 6.0 RC1. If
you
want to use VMware's LSILogic emulation with older products, you need fix below
until
new releases come out (or unless I'll put out binary patch to fix binaries to
return 16 instead of previous value).
Petr
If port reports that no devices are connected to it, assume that 16 devices
are there. Hopefully nobody will ever build device with port but no devices,
and even for them it should be safe as before code always probed 16 devices
regardless of MaxDevices reported by port facts.
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
--- linux/drivers/message/fusion/mptbase.c.orig 2007-03-20 13:47:28.0
-0700
+++ linux/drivers/message/fusion/mptbase.c 2007-03-23 17:45:51.0
-0700
@@ -2564,6 +2564,16 @@
pfacts->IOCStatus = le16_to_cpu(pfacts->IOCStatus);
pfacts->IOCLogInfo = le32_to_cpu(pfacts->IOCLogInfo);
pfacts->MaxDevices = le16_to_cpu(pfacts->MaxDevices);
+ /*
+* VMware emulation is broken, its PortFact's MaxDevices reports value
+* programmed by IOC Init, so if you program IOC Init to 256 (which is
0,
+* as that field is only 8 bit), it reports back 0 in port facts,
instead
+* of 256... And unfortunately using 256 triggers another bug in the
+* code (parallel SCSI can have only 16 devices).
+*/
+ if (pfacts->MaxDevices == 0) {
+ pfacts->MaxDevices = 16;
+ }
pfacts->PortSCSIID = le16_to_cpu(pfacts->PortSCSIID);
pfacts->ProtocolFlags = le16_to_cpu(pfacts->ProtocolFlags);
pfacts->MaxPostedCmdBuffers = le16_to_cpu(pfacts->MaxPostedCmdBuffers);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc regression in mptbase
On Fri, Mar 23, 2007 at 11:39:12PM +0100, Jan Engelhardt wrote:
Hello world,
in at least 2.6.21-rc4, one or more of the mptscsi scsi modules is
broken with respect to not detecting any harddisk (VMware provides that
virtual LSI MPT controller), which means no working system.
No problems in 2.6.20.2.
...
Could be a bug in the driver or a bug in the emulation exposed by a
change in the driver.
Can you bisect which change to the driver broke it?
Hello,
it is bug in the emulation. It should be fixed in Workstation 6.0 RC1. If
you
want to use VMware's LSILogic emulation with older products, you need fix below
until
new releases come out (or unless I'll put out binary patch to fix binaries to
return 16 instead of previous value).
Petr
If port reports that no devices are connected to it, assume that 16 devices
are there. Hopefully nobody will ever build device with port but no devices,
and even for them it should be safe as before code always probed 16 devices
regardless of MaxDevices reported by port facts.
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
--- linux/drivers/message/fusion/mptbase.c.orig 2007-03-20 13:47:28.0
-0700
+++ linux/drivers/message/fusion/mptbase.c 2007-03-23 17:45:51.0
-0700
@@ -2564,6 +2564,16 @@
pfacts-IOCStatus = le16_to_cpu(pfacts-IOCStatus);
pfacts-IOCLogInfo = le32_to_cpu(pfacts-IOCLogInfo);
pfacts-MaxDevices = le16_to_cpu(pfacts-MaxDevices);
+ /*
+* VMware emulation is broken, its PortFact's MaxDevices reports value
+* programmed by IOC Init, so if you program IOC Init to 256 (which is
0,
+* as that field is only 8 bit), it reports back 0 in port facts,
instead
+* of 256... And unfortunately using 256 triggers another bug in the
+* code (parallel SCSI can have only 16 devices).
+*/
+ if (pfacts-MaxDevices == 0) {
+ pfacts-MaxDevices = 16;
+ }
pfacts-PortSCSIID = le16_to_cpu(pfacts-PortSCSIID);
pfacts-ProtocolFlags = le16_to_cpu(pfacts-ProtocolFlags);
pfacts-MaxPostedCmdBuffers = le16_to_cpu(pfacts-MaxPostedCmdBuffers);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add nForce MCP61 support to i2c-nforce2
Jean Delvare wrote: Hi Petr, On Sat, 10 Mar 2007 09:00:03 +0100, Petr Vandrovec wrote: Hello, patch below adds support for nVidia's SMBus adapter present on Gateway's GT5414E motherboard (ECS's MCP61 PM-AM). Patch is for current Linus's git tree. We already have a patch doing exactly this in -mm: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/broken-out/jdelvare-i2c-i2c-nforce2-add-mcp61-mcp65-support.patch Thanks. 00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2) Subsystem: Elitegroup Computer Systems Unknown device 2601 Flags: 66MHz, fast devsel, IRQ 10 I/O ports at fc00 [size=64] I/O ports at 1c00 [size=64] I/O ports at f400 [size=64] Capabilities: [44] Power Management version 2 BTW, note how the MCP61 has not 2 but 3 64-byte I/O areas declared. The previous chips used BAR 4 and 5, this new one additionally uses BAR 0. Without documentation it's hard to be sure this is a 3rd SMBus channel, but it sure looks so. Maybe you'll want to hack the i2c-nforce2 driver a bit to confirm or infirm this theory. I had same idea as you have, so I tried to modify driver to use BAR0 as well, and (1) i2cdump then said that nobody is there and (2) dump of range fc00 was quite different from range 1c00 and f400. So for my hardware I'm sure that BAR0 is of no use for me - if it is 3rd channel then either it uses different interface from nforce2, or nothing is connected to it. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add nForce MCP61 support to i2c-nforce2
Jean Delvare wrote: Hi Petr, On Sat, 10 Mar 2007 09:00:03 +0100, Petr Vandrovec wrote: Hello, patch below adds support for nVidia's SMBus adapter present on Gateway's GT5414E motherboard (ECS's MCP61 PM-AM). Patch is for current Linus's git tree. We already have a patch doing exactly this in -mm: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/broken-out/jdelvare-i2c-i2c-nforce2-add-mcp61-mcp65-support.patch Thanks. 00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2) Subsystem: Elitegroup Computer Systems Unknown device 2601 Flags: 66MHz, fast devsel, IRQ 10 I/O ports at fc00 [size=64] I/O ports at 1c00 [size=64] I/O ports at f400 [size=64] Capabilities: [44] Power Management version 2 BTW, note how the MCP61 has not 2 but 3 64-byte I/O areas declared. The previous chips used BAR 4 and 5, this new one additionally uses BAR 0. Without documentation it's hard to be sure this is a 3rd SMBus channel, but it sure looks so. Maybe you'll want to hack the i2c-nforce2 driver a bit to confirm or infirm this theory. I had same idea as you have, so I tried to modify driver to use BAR0 as well, and (1) i2cdump then said that nobody is there and (2) dump of range fc00 was quite different from range 1c00 and f400. So for my hardware I'm sure that BAR0 is of no use for me - if it is 3rd channel then either it uses different interface from nforce2, or nothing is connected to it. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add nForce MCP61 support to i2c-nforce2
Hello,
patch below adds support for nVidia's SMBus adapter present on Gateway's
GT5414E
motherboard (ECS's MCP61 PM-AM). Patch is for current Linus's git tree.
Thanks,
Petr
--
Add support for MCP61's SMBus interface to i2c-nforce2. Standard NVIDIA i2c
design,
so just adding new device ID is everything needed.
And move MCP55 defines in pci_ids.h around a bit so NVIDIA's section is really
sorted
by device ID.
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
Subsystem: Elitegroup Computer Systems Unknown device 2601
Flags: 66MHz, fast devsel, IRQ 10
I/O ports at fc00 [size=64]
I/O ports at 1c00 [size=64]
I/O ports at f400 [size=64]
Capabilities: [44] Power Management version 2
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -uprdN linux/drivers/i2c/busses/i2c-nforce2.c
linux/drivers/i2c/busses/i2c-nforce2.c
--- linux/drivers/i2c/busses/i2c-nforce2.c 2007-03-07 22:13:25.0
-0800
+++ linux/drivers/i2c/busses/i2c-nforce2.c 2007-03-09 23:38:47.0
-0800
@@ -33,6 +33,7 @@
nForce4 MCP-04 0034
nForce4 MCP51 0264
nForce4 MCP55 0368
+nForce4 MCP61 03EB
This driver supports the 2 SMBuses that are included in the MCP of the
nForce2/3/4/5xx chipsets.
@@ -200,6 +201,7 @@ static struct pci_device_id nforce2_ids[
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SMBUS) },
+ { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS) },
{ 0 }
};
diff -uprdN linux/include/linux/pci_ids.h linux/include/linux/pci_ids.h
--- linux/include/linux/pci_ids.h 2007-03-07 22:13:27.0 -0800
+++ linux/include/linux/pci_ids.h 2007-03-09 23:12:22.0 -0800
@@ -1157,10 +1157,6 @@
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_IDE 0x0265
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SATA 0x0266
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SATA20x0267
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SMBUS0x0368
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_IDE 0x036E
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA 0x037E
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA20x037F
#define PCI_DEVICE_ID_NVIDIA_NVENET_12 0x0268
#define PCI_DEVICE_ID_NVIDIA_NVENET_13 0x0269
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_TI_4800 0x0280
@@ -1209,11 +1205,16 @@
#define PCI_DEVICE_ID_NVIDIA_GEFORCE_FX_GO5700_20x0348
#define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_GO1000 0x034C
#define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SMBUS 0x0368
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_IDE 0x036E
#define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372
#define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA 0x037E
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA2 0x037F
#define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5
#define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA 0x03E7
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS 0x03EB
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE 0x03EC
#define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE
#define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add nForce MCP61 support to i2c-nforce2
Hello,
patch below adds support for nVidia's SMBus adapter present on Gateway's
GT5414E
motherboard (ECS's MCP61 PM-AM). Patch is for current Linus's git tree.
Thanks,
Petr
--
Add support for MCP61's SMBus interface to i2c-nforce2. Standard NVIDIA i2c
design,
so just adding new device ID is everything needed.
And move MCP55 defines in pci_ids.h around a bit so NVIDIA's section is really
sorted
by device ID.
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
Subsystem: Elitegroup Computer Systems Unknown device 2601
Flags: 66MHz, fast devsel, IRQ 10
I/O ports at fc00 [size=64]
I/O ports at 1c00 [size=64]
I/O ports at f400 [size=64]
Capabilities: [44] Power Management version 2
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
diff -uprdN linux/drivers/i2c/busses/i2c-nforce2.c
linux/drivers/i2c/busses/i2c-nforce2.c
--- linux/drivers/i2c/busses/i2c-nforce2.c 2007-03-07 22:13:25.0
-0800
+++ linux/drivers/i2c/busses/i2c-nforce2.c 2007-03-09 23:38:47.0
-0800
@@ -33,6 +33,7 @@
nForce4 MCP-04 0034
nForce4 MCP51 0264
nForce4 MCP55 0368
+nForce4 MCP61 03EB
This driver supports the 2 SMBuses that are included in the MCP of the
nForce2/3/4/5xx chipsets.
@@ -200,6 +201,7 @@ static struct pci_device_id nforce2_ids[
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SMBUS) },
+ { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS) },
{ 0 }
};
diff -uprdN linux/include/linux/pci_ids.h linux/include/linux/pci_ids.h
--- linux/include/linux/pci_ids.h 2007-03-07 22:13:27.0 -0800
+++ linux/include/linux/pci_ids.h 2007-03-09 23:12:22.0 -0800
@@ -1157,10 +1157,6 @@
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_IDE 0x0265
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SATA 0x0266
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP51_SATA20x0267
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SMBUS0x0368
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_IDE 0x036E
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA 0x037E
-#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA20x037F
#define PCI_DEVICE_ID_NVIDIA_NVENET_12 0x0268
#define PCI_DEVICE_ID_NVIDIA_NVENET_13 0x0269
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_TI_4800 0x0280
@@ -1209,11 +1205,16 @@
#define PCI_DEVICE_ID_NVIDIA_GEFORCE_FX_GO5700_20x0348
#define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_GO1000 0x034C
#define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SMBUS 0x0368
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_IDE 0x036E
#define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372
#define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA 0x037E
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP55_SATA2 0x037F
#define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5
#define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA 0x03E7
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS 0x03EB
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE 0x03EC
#define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE
#define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel warning from Matrox Framebuffer in 2.6.20.1
Ondrej Zary wrote: On Saturday 24 February 2007 14:08, Chris Rankin wrote: Hi, I have just booted 2.6.20.1 on my Pentium 3 machine, which has a G400 MAX graphics card. This machine uses the Matrox framebuffer and TV-OUT modules, and I have found these warnings in the kernel log: **WARNING** I2C adapter driver [DDC:fb0 #0] forgot to specify physical device; fix it! **WARNING** I2C adapter driver [DDC:fb0 #1] forgot to specify physical device; fix it! **WARNING** I2C adapter driver [MAVEN:fb0] forgot to specify physical device; fix it! I'm seeing something like that since installing 2.6.20.1 yesterday: matroxfb: Matrox Mystique (PCI) detected PInS memtype = 0 matroxfb: MTRR's turned on matroxfb: 1024x768x8bpp (virtual: 1024x4096) matroxfb: framebuffer at 0xE100, mapped to 0xcc88, size 4194304 Console: switching to colour frame buffer device 128x48 fb0: MATROX frame buffer device **WARNING** I2C adapter driver [DDC:fb0 #0] forgot to specify physical device; fix it! Can you try current git tree? I believe that it is already fixed by Jean Delvare checkin from Feb 13th (thanks Jean!) Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel warning from Matrox Framebuffer in 2.6.20.1
Ondrej Zary wrote: On Saturday 24 February 2007 14:08, Chris Rankin wrote: Hi, I have just booted 2.6.20.1 on my Pentium 3 machine, which has a G400 MAX graphics card. This machine uses the Matrox framebuffer and TV-OUT modules, and I have found these warnings in the kernel log: **WARNING** I2C adapter driver [DDC:fb0 #0] forgot to specify physical device; fix it! **WARNING** I2C adapter driver [DDC:fb0 #1] forgot to specify physical device; fix it! **WARNING** I2C adapter driver [MAVEN:fb0] forgot to specify physical device; fix it! I'm seeing something like that since installing 2.6.20.1 yesterday: matroxfb: Matrox Mystique (PCI) detected PInS memtype = 0 matroxfb: MTRR's turned on matroxfb: 1024x768x8bpp (virtual: 1024x4096) matroxfb: framebuffer at 0xE100, mapped to 0xcc88, size 4194304 Console: switching to colour frame buffer device 128x48 fb0: MATROX frame buffer device **WARNING** I2C adapter driver [DDC:fb0 #0] forgot to specify physical device; fix it! Can you try current git tree? I believe that it is already fixed by Jean Delvare checkin from Feb 13th (thanks Jean!) Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote:
Sorry this took so long but I got occupied with other things and this
had to move down the pile a bit.
New patch which uses dedicated buffers for the currently active packet.
Also adds a new state RQ_ABANDONED which basically means "the caller no
longer cares about this request so the pointers are no longer valid". It
is used to determine if the global receive buffer should be copied to
the provided one upon completion.
Hello,
it would be nice if these two copies (request->txbuf, and
rxbuf->reply) could be eliminated, but I see no easy way how to do that...
commit 166fb223f9507431fb97820549e3e41980987445
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon Feb 19 11:34:43 2007 +0100
ncpfs: make sure server connection survives a kill
Use internal buffers instead of the ones supplied by the caller
so that a caller can be interrupted without having to abort the
entire ncp connection.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
Acked-by: Petr Vandrovec <[EMAIL PROTECTED]>
(modulo one thing below)
diff --git a/include/linux/ncp_fs_sb.h b/include/linux/ncp_fs_sb.h
index a503052..d5e7ffc 100644
--- a/include/linux/ncp_fs_sb.h
+++ b/include/linux/ncp_fs_sb.h
@@ -50,6 +50,8 @@ struct ncp_server {
int packet_size;
unsigned char *packet; /* Here we prepare requests and
receive replies */
+ unsigned char *txbuf; /* Storage for current requres */
Looks like a typo? requres => request ?
+ unsigned char *rxbuf; /* Storage for reply to current request */
int lock; /* To prevent mismatch in protocols. */
struct mutex mutex;
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote:
Sorry this took so long but I got occupied with other things and this
had to move down the pile a bit.
New patch which uses dedicated buffers for the currently active packet.
Also adds a new state RQ_ABANDONED which basically means the caller no
longer cares about this request so the pointers are no longer valid. It
is used to determine if the global receive buffer should be copied to
the provided one upon completion.
Hello,
it would be nice if these two copies (request-txbuf, and
rxbuf-reply) could be eliminated, but I see no easy way how to do that...
commit 166fb223f9507431fb97820549e3e41980987445
Author: Pierre Ossman [EMAIL PROTECTED]
Date: Mon Feb 19 11:34:43 2007 +0100
ncpfs: make sure server connection survives a kill
Use internal buffers instead of the ones supplied by the caller
so that a caller can be interrupted without having to abort the
entire ncp connection.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
Acked-by: Petr Vandrovec [EMAIL PROTECTED]
(modulo one thing below)
diff --git a/include/linux/ncp_fs_sb.h b/include/linux/ncp_fs_sb.h
index a503052..d5e7ffc 100644
--- a/include/linux/ncp_fs_sb.h
+++ b/include/linux/ncp_fs_sb.h
@@ -50,6 +50,8 @@ struct ncp_server {
int packet_size;
unsigned char *packet; /* Here we prepare requests and
receive replies */
+ unsigned char *txbuf; /* Storage for current requres */
Looks like a typo? requres = request ?
+ unsigned char *rxbuf; /* Storage for reply to current request */
int lock; /* To prevent mismatch in protocols. */
struct mutex mutex;
Petr
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Petr Vandrovec wrote: Problem is with these pointers - reply_buf & server->packet. Now code will just read packet from server->packet, and write result to reply_buf, most probably transmiting some random data to network, and overwriting innocent memory on receiption... I believe that you need to make copies of server->packet/size for transmission, and some simillar solution for receive as well. As both request & response can be up to ~66000 bytes. Hmm.. I thought server->packet was protected until the packet was completed, independent of the process that issued it. Looking closer I see that this isn't quite the case. How about this... We allocate two buffers at startup, one for outgoing and one for incoming. Then we use these during the actual transmission, copying back and forth as need. Then we just need to avoid the final response copy if the process has gone belly up. You must not allow anybody to reuse transmit buffer until you are done with all retransmits and received reply from server... That's why code uses same buffer for both request and reply - you never need both, and as maximum size is more or less same for both (65KB), it avoid problem that you would need two 65KB buffers in worst case. Now my next question in that case is, what is the purpose of server->packet. Couldn't this buffer be provided by the caller like the response buffer? Then you would need to do vmalloc (or maybe kmalloc for some cases) on each request transmit & receive. And only very few callers provide receive buffer - most of them does ncp_request() which receives reply to server->packet, without doing any additional allocation - there are only three callers which use ncp_request2 - two of them (ioctl, ncp_read_bounce) do that because copy_to_user is not allowed while ncp_server is locked, and third one (search for file set) does that because caller may need to issue additional NCP calls while parsing its result. But everybody else gets away with no memory allocation. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Petr Vandrovec wrote: Problem is with these pointers - reply_buf server-packet. Now code will just read packet from server-packet, and write result to reply_buf, most probably transmiting some random data to network, and overwriting innocent memory on receiption... I believe that you need to make copies of server-packet/size for transmission, and some simillar solution for receive as well. As both request response can be up to ~66000 bytes. Hmm.. I thought server-packet was protected until the packet was completed, independent of the process that issued it. Looking closer I see that this isn't quite the case. How about this... We allocate two buffers at startup, one for outgoing and one for incoming. Then we use these during the actual transmission, copying back and forth as need. Then we just need to avoid the final response copy if the process has gone belly up. You must not allow anybody to reuse transmit buffer until you are done with all retransmits and received reply from server... That's why code uses same buffer for both request and reply - you never need both, and as maximum size is more or less same for both (65KB), it avoid problem that you would need two 65KB buffers in worst case. Now my next question in that case is, what is the purpose of server-packet. Couldn't this buffer be provided by the caller like the response buffer? Then you would need to do vmalloc (or maybe kmalloc for some cases) on each request transmit receive. And only very few callers provide receive buffer - most of them does ncp_request() which receives reply to server-packet, without doing any additional allocation - there are only three callers which use ncp_request2 - two of them (ioctl, ncp_read_bounce) do that because copy_to_user is not allowed while ncp_server is locked, and third one (search for file set) does that because caller may need to issue additional NCP calls while parsing its result. But everybody else gets away with no memory allocation. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Ok... how about this baby instead. I've replaced the stack allocated request structure by one allocated with kmalloc() and reference counted using an atomic_t. I couldn't see anything else that was associated to the process, so I believe this should suffice. (This is just a RFC. Once I get an ok from you I'll put together a more proper patch mail) - req.tx_type = *(u_int16_t*)server->packet; - - result = ncp_add_request(server, ); + struct ncp_request_reply *req; + + req = ncp_alloc_req(); + if (!req) + return -ENOMEM; + + req->reply_buf = reply_buf; + req->datalen = max_reply_size; + req->tx_iov[1].iov_base = server->packet; + req->tx_iov[1].iov_len = size; + req->tx_iovlen = 1; + req->tx_totallen = size; + req->tx_type = *(u_int16_t*)server->packet; Problem is with these pointers - reply_buf & server->packet. Now code will just read packet from server->packet, and write result to reply_buf, most probably transmiting some random data to network, and overwriting innocent memory on receiption... I believe that you need to make copies of server->packet/size for transmission, and some simillar solution for receive as well. As both request & response can be up to ~66000 bytes. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Ok... how about this baby instead. I've replaced the stack allocated request structure by one allocated with kmalloc() and reference counted using an atomic_t. I couldn't see anything else that was associated to the process, so I believe this should suffice. (This is just a RFC. Once I get an ok from you I'll put together a more proper patch mail) - req.tx_type = *(u_int16_t*)server-packet; - - result = ncp_add_request(server, req); + struct ncp_request_reply *req; + + req = ncp_alloc_req(); + if (!req) + return -ENOMEM; + + req-reply_buf = reply_buf; + req-datalen = max_reply_size; + req-tx_iov[1].iov_base = server-packet; + req-tx_iov[1].iov_len = size; + req-tx_iovlen = 1; + req-tx_totallen = size; + req-tx_type = *(u_int16_t*)server-packet; Problem is with these pointers - reply_buf server-packet. Now code will just read packet from server-packet, and write result to reply_buf, most probably transmiting some random data to network, and overwriting innocent memory on receiption... I believe that you need to make copies of server-packet/size for transmission, and some simillar solution for receive as well. As both request response can be up to ~66000 bytes. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: C header files for vmware
Philippe Dhont (Sea-ro) wrote: hello, i downloaded latest kernel 2.6.19.2 and installed it and it works fine. Now i am trying to install vmware and it asks the location of the directory of the C header files. So i pointed it to my download/install directory /data/kernel/2.6.19.2/linux-2.6.19.2/include/ and i get the error that the directory of kernel headers does not match my running kernel ?? what am i doing wrong ? do i need to download something else ? Error message most probably also contains additional details... There may be couple of reasons - one of them may be that your product is too old to run on 2.6.19.2 kernel without additional changes. You should discuss these issues on http://www.vmware.com/community/index.jspa. If you are quite sure that you've built your kernel from these sources, and you did not run 'make clean' (or make *config) after build kernel, then you most probably have to download http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update107.tar.gz, untar/ungzip it, run runme.pl from package, and follow directions... It should work with all released Linux products. If you are using Workstation 6.0 beta, you should contact VMware beta support. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: C header files for vmware
Philippe Dhont (Sea-ro) wrote: hello, i downloaded latest kernel 2.6.19.2 and installed it and it works fine. Now i am trying to install vmware and it asks the location of the directory of the C header files. So i pointed it to my download/install directory /data/kernel/2.6.19.2/linux-2.6.19.2/include/ and i get the error that the directory of kernel headers does not match my running kernel ?? what am i doing wrong ? do i need to download something else ? Error message most probably also contains additional details... There may be couple of reasons - one of them may be that your product is too old to run on 2.6.19.2 kernel without additional changes. You should discuss these issues on http://www.vmware.com/community/index.jspa. If you are quite sure that you've built your kernel from these sources, and you did not run 'make clean' (or make *config) after build kernel, then you most probably have to download http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update107.tar.gz, untar/ungzip it, run runme.pl from package, and follow directions... It should work with all released Linux products. If you are using Workstation 6.0 beta, you should contact VMware beta support. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Petr Vandrovec wrote: Hello, create test scenario where first transmit of NCP request is lost by network, and before resend you kill this process. So it stops resending, but local sequence count is already incremented. Then when next process tries to access ncpfs, server will ignore its requests as it expects packet with sequence X, while packet with sequence X+1 arrived. Figured something along those lines, but I couldn't find any docs on the protocol so I wasn't sure. You wouldn't happen to have any pointers to such docs? You can download NCP documentation from Novell website. Or you could, couple of months ago. Unfortunately that documentation just describes different NCP calls, not transport - to my knowledge transport layer was never documented outside of Novell. And unfortunately it is not possible to simple not increment sequence number unless you get reply - when server receives two packets with same sequence number, it simple resends answer it gave to first request, without looking at request's body at all. So in this case server would answer, but would gave you bogus answer. This sounds promising though. In that case it wouldn't be necessary to store the entire request, just the sequence number, right? Not quite. If packet signatures are on then server needs to know packet you sent so it can correctly compute secret used for next packet (it is function of old secret, and data in current packet). As current signatures implementation implement only partial signatures, you need just first 64bytes of the packet same - but at that point it may be better to just resend packet completely, as write request with correct file handle, length, and offset, but with only ~50 bytes of valid data is going to do lot of damage on the server. So I would recommend resending original request... Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Petr Vandrovec wrote: Hello, create test scenario where first transmit of NCP request is lost by network, and before resend you kill this process. So it stops resending, but local sequence count is already incremented. Then when next process tries to access ncpfs, server will ignore its requests as it expects packet with sequence X, while packet with sequence X+1 arrived. Figured something along those lines, but I couldn't find any docs on the protocol so I wasn't sure. You wouldn't happen to have any pointers to such docs? You can download NCP documentation from Novell website. Or you could, couple of months ago. Unfortunately that documentation just describes different NCP calls, not transport - to my knowledge transport layer was never documented outside of Novell. And unfortunately it is not possible to simple not increment sequence number unless you get reply - when server receives two packets with same sequence number, it simple resends answer it gave to first request, without looking at request's body at all. So in this case server would answer, but would gave you bogus answer. This sounds promising though. In that case it wouldn't be necessary to store the entire request, just the sequence number, right? Not quite. If packet signatures are on then server needs to know packet you sent so it can correctly compute secret used for next packet (it is function of old secret, and data in current packet). As current signatures implementation implement only partial signatures, you need just first 64bytes of the packet same - but at that point it may be better to just resend packet completely, as write request with correct file handle, length, and offset, but with only ~50 bytes of valid data is going to do lot of damage on the server. So I would recommend resending original request... Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote:
Sorry this took some time, I've been busy with other things.
Petr Vandrovec wrote:
Unfortunately NCP does not run on top of TCP stream, but on top of
IPX/UDP, and so dropping reply is not sufficient - you must continue
resending request (so you must buffer it somewhere...) until you get
result from server - after you receive answer from server, you can
finally throw away both request & reply, and move on.
I don't quite understand why you need to resend. I did the following and
it seems to work fine with UDP:
Hello,
create test scenario where first transmit of NCP request is lost by
network, and before resend you kill this process. So it stops
resending, but local sequence count is already incremented. Then when
next process tries to access ncpfs, server will ignore its requests as
it expects packet with sequence X, while packet with sequence X+1 arrived.
And unfortunately it is not possible to simple not increment sequence
number unless you get reply - when server receives two packets with same
sequence number, it simple resends answer it gave to first request,
without looking at request's body at all. So in this case server would
answer, but would gave you bogus answer.
So only solution (as far as I can tell) is to keep retrying request
until you get answer - only in this case you can be sure that client and
server state machines are in same state - your solution will work if
packet is never lost. But as we talk about UDP and real networks, this
assumption is not safe.
Petr
diff --git a/fs/ncpfs/sock.c b/fs/ncpfs/sock.c
index e496d8b..5159bae 100644
--- a/fs/ncpfs/sock.c
+++ b/fs/ncpfs/sock.c
@@ -151,6 +153,8 @@ static inline int get_conn_number(struct
ncp_reply_header *rp)
return rp->conn_low | (rp->conn_high << 8);
}
+static void __ncp_next_request(struct ncp_server *server);
+
static inline void __ncp_abort_request(struct ncp_server *server,
struct ncp_request_reply *req, int err)
{
/* If req is done, we got signal, but we also received answer... */
@@ -163,7 +167,10 @@ static inline void __ncp_abort_request(struct
ncp_server *server, struct ncp_req
ncp_finish_request(req, err);
break;
case RQ_INPROGRESS:
- __abort_ncp_connection(server, req, err);
+ printk(KERN_INFO "ncpfs: Killing running
request!\n");
+ ncp_finish_request(req, err);
+ __ncp_next_request(server);
+// __abort_ncp_connection(server, req, err);
break;
}
}
@@ -754,7 +761,8 @@ static int ncp_do_request(struct ncp_server *server,
int size,
if (result < 0) {
/* There was a problem with I/O, so the connections is
* no longer usable. */
- ncp_invalidate_conn(server);
+ printk(KERN_INFO "ncpfs: Invalidating connection!\n");
+// ncp_invalidate_conn(server);
}
return result;
}
I'm not particularly proud of the second chunk though. Ideas on how to
handle when we actually get a transmission problem and not just getting
killed by a signal?
Rgds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote:
Sorry this took some time, I've been busy with other things.
Petr Vandrovec wrote:
Unfortunately NCP does not run on top of TCP stream, but on top of
IPX/UDP, and so dropping reply is not sufficient - you must continue
resending request (so you must buffer it somewhere...) until you get
result from server - after you receive answer from server, you can
finally throw away both request reply, and move on.
I don't quite understand why you need to resend. I did the following and
it seems to work fine with UDP:
Hello,
create test scenario where first transmit of NCP request is lost by
network, and before resend you kill this process. So it stops
resending, but local sequence count is already incremented. Then when
next process tries to access ncpfs, server will ignore its requests as
it expects packet with sequence X, while packet with sequence X+1 arrived.
And unfortunately it is not possible to simple not increment sequence
number unless you get reply - when server receives two packets with same
sequence number, it simple resends answer it gave to first request,
without looking at request's body at all. So in this case server would
answer, but would gave you bogus answer.
So only solution (as far as I can tell) is to keep retrying request
until you get answer - only in this case you can be sure that client and
server state machines are in same state - your solution will work if
packet is never lost. But as we talk about UDP and real networks, this
assumption is not safe.
Petr
diff --git a/fs/ncpfs/sock.c b/fs/ncpfs/sock.c
index e496d8b..5159bae 100644
--- a/fs/ncpfs/sock.c
+++ b/fs/ncpfs/sock.c
@@ -151,6 +153,8 @@ static inline int get_conn_number(struct
ncp_reply_header *rp)
return rp-conn_low | (rp-conn_high 8);
}
+static void __ncp_next_request(struct ncp_server *server);
+
static inline void __ncp_abort_request(struct ncp_server *server,
struct ncp_request_reply *req, int err)
{
/* If req is done, we got signal, but we also received answer... */
@@ -163,7 +167,10 @@ static inline void __ncp_abort_request(struct
ncp_server *server, struct ncp_req
ncp_finish_request(req, err);
break;
case RQ_INPROGRESS:
- __abort_ncp_connection(server, req, err);
+ printk(KERN_INFO ncpfs: Killing running
request!\n);
+ ncp_finish_request(req, err);
+ __ncp_next_request(server);
+// __abort_ncp_connection(server, req, err);
break;
}
}
@@ -754,7 +761,8 @@ static int ncp_do_request(struct ncp_server *server,
int size,
if (result 0) {
/* There was a problem with I/O, so the connections is
* no longer usable. */
- ncp_invalidate_conn(server);
+ printk(KERN_INFO ncpfs: Invalidating connection!\n);
+// ncp_invalidate_conn(server);
}
return result;
}
I'm not particularly proud of the second chunk though. Ideas on how to
handle when we actually get a transmission problem and not just getting
killed by a signal?
Rgds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unbreak MSI on ATI devices
Roland Dreier wrote: > So my question is - what is real reason for disabling INTX when in MSI mode? > According to PCI spec it should not be needed, and it hurts at least chips > listed below: > > 00:13.0 0c03: 1002:4374 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller > 00:13.1 0c03: 1002:4375 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller > 00:13.2 0c03: 1002:4373 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller heh... I'm not gloating or anything... but I am glad that some ASIC designer was careless enough to prove me right when I said going beyond what the PCI spec requires is dangerous. Hi, unfortunately it is not everything :-( I cannot get MSI to work on IDE interface under any circumstances - in legacy mode it always uses IRQ14/15 regardless of whether MSI is enabled or not (that's probably correct), but in native mode as soon as I enable MSI it either does not deliver interrupts at all (definitely not through IRQ14/15, and, if I got routing right, also not through its INTA#), or it delivers them somewhere else than where programmed. As my boot device is connected to this adapter, and it is a notebook, it is not easy to debug what's really going on :-( 00:14.1 0101: 1002:4376 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Rioworks Unknown device 2043 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=4] I/O ports at 0170 [size=8] I/O ports at 0374 [size=4] I/O ports at 8410 [size=16] Capabilities: [70] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unbreak MSI on ATI devices
Roland Dreier wrote: So my question is - what is real reason for disabling INTX when in MSI mode? According to PCI spec it should not be needed, and it hurts at least chips listed below: 00:13.0 0c03: 1002:4374 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.1 0c03: 1002:4375 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.2 0c03: 1002:4373 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller heh... I'm not gloating or anything... but I am glad that some ASIC designer was careless enough to prove me right when I said going beyond what the PCI spec requires is dangerous. Hi, unfortunately it is not everything :-( I cannot get MSI to work on IDE interface under any circumstances - in legacy mode it always uses IRQ14/15 regardless of whether MSI is enabled or not (that's probably correct), but in native mode as soon as I enable MSI it either does not deliver interrupts at all (definitely not through IRQ14/15, and, if I got routing right, also not through its INTA#), or it delivers them somewhere else than where programmed. As my boot device is connected to this adapter, and it is a notebook, it is not easy to debug what's really going on :-( 00:14.1 0101: 1002:4376 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Rioworks Unknown device 2043 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=4] I/O ports at 0170 [size=8] I/O ports at 0374 [size=4] I/O ports at 8410 [size=16] Capabilities: [70] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Petr Vandrovec wrote: Nobody is working on it (at least to my knowledge), and to me it is feature - it always worked this way, like smbfs did back in the past - if you send signal 9 to process using mount point, and there is some transaction in progress, nobody can correctly finish that transaction anymore. Fixing it would require non-trivial amount of code, and given that NCP itself is more or less dead protocol I do not feel that it is necessary. Someone needs to tell our customers then so they'll stop using it. :) When I asked at Brainshare 2001 when support for files over 4GB files will be added to NCP, they told me that I should switch to CIFS or NFS... Years after that confirmed it - only NW6.5SP3 finally got NCPs to support for files over 4GB, although you could have such files even on NW5. If you want to fix it, feel free. Culprit is RQ_INPROGRESS handling in ncp_abort_request - it just aborts whole connection so it does not have to provide temporary buffers and special handling for reply - as buffers currently specified as reply buffers are owned by caller, so after aborting request you cannot use them anymore. Do you have any pointers to how it was solved with smbfs? Relevant patches perhaps? Provided a similar solution can be applied here. I believe it was fixed when smbiod was introduced. When find_request() returns failure, it simple throws away data received from network. Unfortunately NCP does not run on top of TCP stream, but on top of IPX/UDP, and so dropping reply is not sufficient - you must continue resending request (so you must buffer it somewhere...) until you get result from server - after you receive answer from server, you can finally throw away both request & reply, and move on. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Hi Petr, What is the status of this bug? http://bugzilla.kernel.org/show_bug.cgi?id=3328 I do not see anything in the history of fs/ncpfs that seems to suggest that this, rather critical, issue has been resolved. Is anyone working on it? Nobody is working on it (at least to my knowledge), and to me it is feature - it always worked this way, like smbfs did back in the past - if you send signal 9 to process using mount point, and there is some transaction in progress, nobody can correctly finish that transaction anymore. Fixing it would require non-trivial amount of code, and given that NCP itself is more or less dead protocol I do not feel that it is necessary. If you want to fix it, feel free. Culprit is RQ_INPROGRESS handling in ncp_abort_request - it just aborts whole connection so it does not have to provide temporary buffers and special handling for reply - as buffers currently specified as reply buffers are owned by caller, so after aborting request you cannot use them anymore. Petr Vandrovec - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Hi Petr, What is the status of this bug? http://bugzilla.kernel.org/show_bug.cgi?id=3328 I do not see anything in the history of fs/ncpfs that seems to suggest that this, rather critical, issue has been resolved. Is anyone working on it? Nobody is working on it (at least to my knowledge), and to me it is feature - it always worked this way, like smbfs did back in the past - if you send signal 9 to process using mount point, and there is some transaction in progress, nobody can correctly finish that transaction anymore. Fixing it would require non-trivial amount of code, and given that NCP itself is more or less dead protocol I do not feel that it is necessary. If you want to fix it, feel free. Culprit is RQ_INPROGRESS handling in ncp_abort_request - it just aborts whole connection so it does not have to provide temporary buffers and special handling for reply - as buffers currently specified as reply buffers are owned by caller, so after aborting request you cannot use them anymore. Petr Vandrovec - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Pierre Ossman wrote: Petr Vandrovec wrote: Nobody is working on it (at least to my knowledge), and to me it is feature - it always worked this way, like smbfs did back in the past - if you send signal 9 to process using mount point, and there is some transaction in progress, nobody can correctly finish that transaction anymore. Fixing it would require non-trivial amount of code, and given that NCP itself is more or less dead protocol I do not feel that it is necessary. Someone needs to tell our customers then so they'll stop using it. :) When I asked at Brainshare 2001 when support for files over 4GB files will be added to NCP, they told me that I should switch to CIFS or NFS... Years after that confirmed it - only NW6.5SP3 finally got NCPs to support for files over 4GB, although you could have such files even on NW5. If you want to fix it, feel free. Culprit is RQ_INPROGRESS handling in ncp_abort_request - it just aborts whole connection so it does not have to provide temporary buffers and special handling for reply - as buffers currently specified as reply buffers are owned by caller, so after aborting request you cannot use them anymore. Do you have any pointers to how it was solved with smbfs? Relevant patches perhaps? Provided a similar solution can be applied here. I believe it was fixed when smbiod was introduced. When find_request() returns failure, it simple throws away data received from network. Unfortunately NCP does not run on top of TCP stream, but on top of IPX/UDP, and so dropping reply is not sufficient - you must continue resending request (so you must buffer it somewhere...) until you get result from server - after you receive answer from server, you can finally throw away both request reply, and move on. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Unbreak MSI on ATI devices
Hello Jeff, I'm using second patch below for couple of months to get MSI on all devices present on my notebook which are MSI capable (except IDE - notebook uses IDE in legacy mode and seems unhappy with transition to native MSI-based mode; maybe I could try do the job with libata now when I switched; and VGA, I do not use dri...). All worked nicely until last sync, when I noticed that my USB devices suddenly stopped working (it took me few weeks as I do not use USB regulary). After poking around I've found that problem is that at least ATI USB-HCDs apply INTX enable even for MSI, despite warning in the PCI specification that it should apply only to MSI (actually I have feeling that on these USB devices disabling INTX in MSI mode drives their INTA# line active as when ohci1394 module got loaded kernel complained about interrupt being continuously activated for no good reason (TI's 7421 is one of few MSI-incapable devices in my box). So my question is - what is real reason for disabling INTX when in MSI mode? According to PCI spec it should not be needed, and it hurts at least chips listed below: 00:13.0 0c03: 1002:4374 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.1 0c03: 1002:4375 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.2 0c03: 1002:4373 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller I believe that these devices from same vendor accept disabling INTX while in MSI fine (I did not notice problems with them even with INTX disabling code in msi.c): 00:14.5 0401: 1002:4370 (rev 02) Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 02) 00:14.6 0703: 1002:4378 (rev 02) Modem: ATI Technologies Inc ATI SB400 - AC'97 Modem Controller (rev 02) None of devices in the box assert INTX while in MSI even if INTX is enabled. So I'd like to see first patch below accepted. If there are some devices which require INTX disabling, then apparently decision whether to disable it or no has to be moved to device drivers, or some blacklist/whitelist must be created... I'm not sure about second one - I have it in my tree for months, but I run that kernel only on hardware mentioned above, so it is probably too dangerous until pci_enable_msi() gets answer whether MSI works or no always right. Thanks, Petr Vandrovec /proc/interrupts after patch. Before patch *hci_hcd:usb* were at zero, IRQ21 was stuck with IRQ count at 1, and HCD complained about "Unlink after no-IRQ?". CPU0 0: 140326 local-APIC-edge-fasteio timer 1: 10773 IO-APIC-edge i8042 8: 1 IO-APIC-edge rtc 12: 34498 IO-APIC-edge i8042 14: 34714 IO-APIC-edge libata 15: 82 IO-APIC-edge libata 16: 1 IO-APIC-fasteoi tifm_7xx1, yenta, sdhci:slot0, sdhci:slot1, sdhci:slot2 21:265 IO-APIC-fasteoi acpi, ohci1394 22: 28973 IO-APIC-fasteoi ipw2200 216: 1 PCI-MSI-edge ATI IXP Modem 217: 1 PCI-MSI-edge ATI IXP 218: 2 PCI-MSI-edge ehci_hcd:usb3 219: 88 PCI-MSI-edge ohci_hcd:usb2 220: 1 PCI-MSI-edge ohci_hcd:usb1 221: 1 PCI-MSI-edge eth0 NMI: 0 LOC: 140293 ERR: 0 MIS: 0 Do not disable INTX in MSI mode. It breaks ATI USB HCDs (both OHCI and EHCI). Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]> diff -uprdN linux/drivers/pci/msi.c linux/drivers/pci/msi.c --- linux/drivers/pci/msi.c 2006-12-16 13:34:52.0 -0800 +++ linux/drivers/pci/msi.c 2006-12-20 23:18:10.0 -0800 @@ -256,7 +256,7 @@ static void enable_msi_mode(struct pci_d dev->msix_enabled = 1; } - pci_intx(dev, 0); /* disable intx */ + pci_intx(dev, 1); /* enable intx, on some devices it affects MSI as well */ } void disable_msi_mode(struct pci_dev *dev, int pos, int type) Use MSI when available on USB HCDs and on ATI AC'97 hardware. Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]> diff -uprdN linux/drivers/usb/core/hcd-pci.c linux/drivers/usb/core/hcd-pci.c --- linux/drivers/usb/core/hcd-pci.c2006-12-16 13:34:57.0 -0800 +++ linux/drivers/usb/core/hcd-pci.c2006-12-16 13:57:09.0 -0800 @@ -69,6 +69,7 @@ int usb_hcd_pci_probe (struct pci_dev *d if (pci_enable_device (dev) < 0) return -ENODEV; + pci_enable_msi(dev); dev->current_state = PCI_D0; dev->dev.power.power_state = PMSG_ON; @@ -139,6 +140,7 @@ int usb_hcd_pci_probe (struct pci_dev *d release_region (hcd->rsrc_start, hcd->rsrc_len); err2: usb_put_hcd (hcd); + pci_disable_msi (dev); err1: pci_disable_device (dev); dev_err (>dev,
[PATCH] Unbreak MSI on ATI devices
Hello Jeff, I'm using second patch below for couple of months to get MSI on all devices present on my notebook which are MSI capable (except IDE - notebook uses IDE in legacy mode and seems unhappy with transition to native MSI-based mode; maybe I could try do the job with libata now when I switched; and VGA, I do not use dri...). All worked nicely until last sync, when I noticed that my USB devices suddenly stopped working (it took me few weeks as I do not use USB regulary). After poking around I've found that problem is that at least ATI USB-HCDs apply INTX enable even for MSI, despite warning in the PCI specification that it should apply only to MSI (actually I have feeling that on these USB devices disabling INTX in MSI mode drives their INTA# line active as when ohci1394 module got loaded kernel complained about interrupt being continuously activated for no good reason (TI's 7421 is one of few MSI-incapable devices in my box). So my question is - what is real reason for disabling INTX when in MSI mode? According to PCI spec it should not be needed, and it hurts at least chips listed below: 00:13.0 0c03: 1002:4374 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.1 0c03: 1002:4375 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller 00:13.2 0c03: 1002:4373 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller I believe that these devices from same vendor accept disabling INTX while in MSI fine (I did not notice problems with them even with INTX disabling code in msi.c): 00:14.5 0401: 1002:4370 (rev 02) Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 02) 00:14.6 0703: 1002:4378 (rev 02) Modem: ATI Technologies Inc ATI SB400 - AC'97 Modem Controller (rev 02) None of devices in the box assert INTX while in MSI even if INTX is enabled. So I'd like to see first patch below accepted. If there are some devices which require INTX disabling, then apparently decision whether to disable it or no has to be moved to device drivers, or some blacklist/whitelist must be created... I'm not sure about second one - I have it in my tree for months, but I run that kernel only on hardware mentioned above, so it is probably too dangerous until pci_enable_msi() gets answer whether MSI works or no always right. Thanks, Petr Vandrovec /proc/interrupts after patch. Before patch *hci_hcd:usb* were at zero, IRQ21 was stuck with IRQ count at 1, and HCD complained about Unlink after no-IRQ?. CPU0 0: 140326 local-APIC-edge-fasteio timer 1: 10773 IO-APIC-edge i8042 8: 1 IO-APIC-edge rtc 12: 34498 IO-APIC-edge i8042 14: 34714 IO-APIC-edge libata 15: 82 IO-APIC-edge libata 16: 1 IO-APIC-fasteoi tifm_7xx1, yenta, sdhci:slot0, sdhci:slot1, sdhci:slot2 21:265 IO-APIC-fasteoi acpi, ohci1394 22: 28973 IO-APIC-fasteoi ipw2200 216: 1 PCI-MSI-edge ATI IXP Modem 217: 1 PCI-MSI-edge ATI IXP 218: 2 PCI-MSI-edge ehci_hcd:usb3 219: 88 PCI-MSI-edge ohci_hcd:usb2 220: 1 PCI-MSI-edge ohci_hcd:usb1 221: 1 PCI-MSI-edge eth0 NMI: 0 LOC: 140293 ERR: 0 MIS: 0 Do not disable INTX in MSI mode. It breaks ATI USB HCDs (both OHCI and EHCI). Signed-off-by: Petr Vandrovec [EMAIL PROTECTED] diff -uprdN linux/drivers/pci/msi.c linux/drivers/pci/msi.c --- linux/drivers/pci/msi.c 2006-12-16 13:34:52.0 -0800 +++ linux/drivers/pci/msi.c 2006-12-20 23:18:10.0 -0800 @@ -256,7 +256,7 @@ static void enable_msi_mode(struct pci_d dev-msix_enabled = 1; } - pci_intx(dev, 0); /* disable intx */ + pci_intx(dev, 1); /* enable intx, on some devices it affects MSI as well */ } void disable_msi_mode(struct pci_dev *dev, int pos, int type) Use MSI when available on USB HCDs and on ATI AC'97 hardware. Signed-off-by: Petr Vandrovec [EMAIL PROTECTED] diff -uprdN linux/drivers/usb/core/hcd-pci.c linux/drivers/usb/core/hcd-pci.c --- linux/drivers/usb/core/hcd-pci.c2006-12-16 13:34:57.0 -0800 +++ linux/drivers/usb/core/hcd-pci.c2006-12-16 13:57:09.0 -0800 @@ -69,6 +69,7 @@ int usb_hcd_pci_probe (struct pci_dev *d if (pci_enable_device (dev) 0) return -ENODEV; + pci_enable_msi(dev); dev-current_state = PCI_D0; dev-dev.power.power_state = PMSG_ON; @@ -139,6 +140,7 @@ int usb_hcd_pci_probe (struct pci_dev *d release_region (hcd-rsrc_start, hcd-rsrc_len); err2: usb_put_hcd (hcd); + pci_disable_msi (dev); err1: pci_disable_device (dev); dev_err (dev-dev, init %s fail, %d\n, pci_name(dev), retval); @@ -177,6
Re: ncpfs: Connection invalid / Input-/Output Errors
schönfeld / in-medias-res wrote: Hi Petr, the two servers is that the one with the problems does run a nagios nrpe server and some plugins, e.g. to check disk space on the novell disk, while the other server does not. Now i found that heavy operations on the filesystem (e.g. stat'ing many small files in a short time) is a kind of problematic, if you want to do anything else on the filesystem at the same time. The second process just hangs until the first one accessing the ncp filesystem is ready with its operation. Well if You need either another CPU, or semaphore which do not suffer from starvation. Or you have to rewrite ncpfs to use some queue instead of simple semaphore. What happens is that your copy process in a loop acquires ncp_server's semaphore, sends request to server, waits for response, and releases semaphore. It does that for every request sent out. Now your process comes in, finds that ncp_server's semaphore is locked, and starts waiting. Other process gets answer from server, releases semaphore, and as both processes were just waiting before this happened, they both have same priority, and so one which just did up() continues to run. And before waken up process gets chance to do its task, copy process sends another request, and so your second process goes to sleep again. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ncpfs: Connection invalid / Input-/Output Errors
schönfeld / in-medias-res wrote: Hi Petr, the two servers is that the one with the problems does run a nagios nrpe server and some plugins, e.g. to check disk space on the novell disk, while the other server does not. Now i found that heavy operations on the filesystem (e.g. stat'ing many small files in a short time) is a kind of problematic, if you want to do anything else on the filesystem at the same time. The second process just hangs until the first one accessing the ncp filesystem is ready with its operation. Well if You need either another CPU, or semaphore which do not suffer from starvation. Or you have to rewrite ncpfs to use some queue instead of simple semaphore. What happens is that your copy process in a loop acquires ncp_server's semaphore, sends request to server, waits for response, and releases semaphore. It does that for every request sent out. Now your process comes in, finds that ncp_server's semaphore is locked, and starts waiting. Other process gets answer from server, releases semaphore, and as both processes were just waiting before this happened, they both have same priority, and so one which just did up() continues to run. And before waken up process gets chance to do its task, copy process sends another request, and so your second process goes to sleep again. Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Request only really used I/O ports in w83627hf driver
Jean Delvare wrote:
Hi Petr,
my motherboard (Tyan S2885) reports range 295-296 in its PNP hardware
descriptors, and due to this w83627hf driver fails to load, as it
requests 290-297 range, which is not subrange of this PNP resource.
As hardware monitor chip responds to 295/296 addresses only, there is
no reason to request full 8 byte I/O.
Another point of view would be: as the physical address of the chip is
0x290-0x297, there is no reason to even think of requesting a different
range. And there is a very valid reason to request the full 8 byte I/O
range: to let the user know that this range is not available for other
devices. Mapping another device to the unused I/O ports of the W83627HF
would not work, right? Also consider that future chips of this family
could use additional ports.
No, it would perfectly work. W83627HF (and all other hardware monitoring
chips from Winbond) respond only to xxx5 and xxx6 address, not to the
other addresses in the range xxx0-xxx7. So requesting full 8 byte range
is not only unnecessary, but also incorrect.
For example I can place 4-byte printer port at 0xC00-0xC03, while sensors
live at 0xC05-0xC06. If I place sensors and serial port at same address,
I get bytes (from C00-C07) "04 00 01 00 13 40 01 00". When I move senors
away, I get "04 00 01 00 13 06 00 00", so you can see that only address + 5
and + 6 are affected. And when I move serial port away, leaving sensors
in place, I see "FF FF FF FF FF 40 01 FF" - again chip respons to +5 & +6
addresses only, not to the full range.
And even if it would answer to the other addresses, you should not request
them, as driver apparently does not need them, while some other driver might.
Take a look at i2c-amd756 driver for example. It uses bytes 0xE0-0xEF
from large 256 byte I/O window on amd7x6/amd8111 chips. And it correctly
requests only region 0xE0-0xEF, so other drivers can drive other parts
of the chip.
The cause of your trouble is, IMVHO, a buggy BIOS. Ask Tyan to fix their
BIOS to allocate the real I/O range to the W83627HF chip, and you're
done.
http://bugzilla.kernel.org/show_bug.cgi?id=4014
I do not agree with your analysis here. Chip just wants 8 byte aligned
address, nowhere in the documentation is stated that full 8 bytes are
used, actually doc is quite explicit that accesses are decoded only if
low nibble is 5 or 6 (for example w83627hf/f/hg/g datasheet revision A1,
page 28).
Your fix might come in handy for your own situation, but it looks wrong
in the long run. We are not going to shrink the requested I/O range of
every random driver each time a motherboard manufacturer releases a
buggy BIOS.
It is not buggy BIOS. It is incorrect assumption of driver writter about
hardware, and about request_region API. If you want to put potential
resources to the tree, you should not tag them BUSY, as they are not
busy, they are free for use by the driver.
If getting the manufacturers to provide fixed BIOSes doesn't seem to be
feasable, then the PNPACPI code certainly needs to be extended to handle
this case transparently. This could be achived using quirks similar to
what we have for PCI, or PNPACPI could simply accept requests of I/O
ranges which include a single PNP range as defined by the BIOS. Note
that everything was working just fine for everyone before PNPACPI was
added to the kernel.
No. Unfortunately BIOS knows how hardware works while w83627hf driver
apparently does not, so I do not think manufacturers are going to break
BIOS just to match Linux driver expectations.
Petr Vandrovec
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add code for completely disabling I2C interface to the w83627hf driver
Hello,
While getting w83627hf driver to work on Tyan Thunder K7 (BIOS disables
hardware monitoring and forwards only addresses 0xC00 - 0xDFF to the LPC,
so force_address's value must be in this range...) I've noticed that it
is possible to completely disable I2C interface on the w83627hf chip
(BIOS left chip in this state...; other three chips supported by w83627hf
do not have I2C interface at all). So this code does that - by default
it disables w83627hf's I2C interface by switching these pins from I2C
to the input GPIO pins. This is sufficient to stop chip from being
accessible through I2C bus, and as there are no I2C devices on chip,
it seems like right thing to do, instead of programming chip with I2C
address 0x1F.
I've tested this on w83627hf in Tyan Thunder K7 and Tyan S2885, and
with w83627thf in Asus A8V. I have no computer with w637hf & w697hf
chips, but their datasheets suggest that they do not have I2C bus like
w627thf, so there should be no problem.
To revert to old behavior it is still possible to use force_i2c=0x1F,
but note that driver does not reenable i2c bus under any circumstances,
so if you want to reenable i2c you have to clear bits 7,6 in GPIO2_MUX_REG
manually.
Although watchdog driver (w83627hf_wdt) uses GPIO2 bank too (and enables
it), there is no problem, as when GPIO2 logical device is going from
disabled to enabled state, it automatically sets direction for all GPIO2 pins
to input, exactly in the way we want, and watchdog driver itself does
not touch GPIO2 pins at all.
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -urN linux-2.6.13-5bca.dist/drivers/hwmon/w83627hf.c
linux-2.6.13-5bca/drivers/hwmon/w83627hf.c
--- linux-2.6.13-5bca.dist/drivers/hwmon/w83627hf.c 2005-09-06
13:50:03.0 +0200
+++ linux-2.6.13-5bca/drivers/hwmon/w83627hf.c 2005-09-07 19:54:08.0
+0200
@@ -25,7 +25,7 @@
Supports following chips:
Chip #vin#fanin #pwm#temp wchipid vendid i2c ISA
-w83627hf 9 3 2 3 0x200x5ca3 no yes(LPC)
+w83627hf 9 3 2 3 0x200x5ca3 yes yes(LPC)
w83627thf 7 3 3 3 0x900x5ca3 no yes(LPC)
w83637hf 7 3 3 3 0x800x5ca3 no yes(LPC)
w83697hf 8 2 2 2 0x600x5ca3 no yes(LPC)
@@ -53,8 +53,8 @@
module_param(force_addr, ushort, 0);
MODULE_PARM_DESC(force_addr,
"Initialize the base address of the sensors");
-static u8 force_i2c = 0x1f;
-module_param(force_i2c, byte, 0);
+static s16 force_i2c = -1;
+module_param(force_i2c, short, 0);
MODULE_PARM_DESC(force_i2c,
"Initialize the i2c address of the sensors");
@@ -134,8 +134,10 @@
#define W627THF_DEVID 0x82
#define W697_DEVID 0x60
#define W637_DEVID 0x70
-#define WINB_ACT_REG 0x30
-#define WINB_BASE_REG 0x60
+#define WINB_ACT_REG 0x30/* Common for all banks */
+#define WINB_BASE_REG 0x60/* Common for all banks */
+#define WINB_GPIO2_MUX_REG 0x2B/* Not banked */
+#define WINB_GPIO2_DIR_REG 0xF0/* In LD_GPIO2 bank */
/* Constants specified below */
/* Alignment of ISA address */
@@ -1035,7 +1037,7 @@
}
superio_select(W83627HF_LD_HWM);
- if((val = 0x01 & superio_inb(WINB_ACT_REG)) == 0)
+ if((superio_inb(WINB_ACT_REG) & 0x01) == 0)
superio_outb(WINB_ACT_REG, 1);
superio_exit();
@@ -1277,6 +1279,30 @@
return 0;
}
+/* Invoked with superio extended access enabled. */
+static void w83627hf_disable_i2c(void)
+{
+ int mux;
+
+ /* SCL/SDA pins already GPIO => i2c is (already) disabled, or */
+ /* not connected, or whatever. Do not touch. */
+ mux = superio_inb(WINB_GPIO2_MUX_REG);
+ if ((mux & 0xC0) == 0xC0)
+ return;
+ superio_select(W83627HF_LD_GPIO2);
+ /* If GPIO2 function is disabled, GPIO2 pins are always input and */
+ /* GPIO2 direction configuration register is hardwired to 0xFF. */
+ /* If GPIO2 function is enabled, GPIO2 pins are bidirectional and */
+ /* GPIO2 direction configuration register matters. */
+ if (superio_inb(WINB_ACT_REG) & 0x01) {
+ /* Switch GPIO21 (mux with SCL) & GPIO22 (SDA) pins to input. */
+ int dir = superio_inb(WINB_GPIO2_DIR_REG);
+ superio_outb(WINB_GPIO2_DIR_REG, dir | 0x06);
+ }
+ /* Select GPIO functionality on GPIO21/SCL & GPIO22/SDA pins. */
+ superio_outb(WINB_GPIO2_MUX_REG, mux | 0xC0);
+}
+
/* Called when we have found a new W83781D. It should set limits, etc. */
static void w83627hf_init_
[PATCH] Request only really used I/O ports in w83627hf driver
Hello,
my motherboard (Tyan S2885) reports range 295-296 in its PNP hardware
descriptors, and due to this w83627hf driver fails to load, as it requests
290-297 range, which is not subrange of this PNP resource. As hardware
monitor chip responds to 295/296 addresses only, there is no reason to
request full 8 byte I/O.
While I was doing that, I also changed W83781D_*_REG_OFFSET definitions
from 5/6 to 0/1. Code is a bit smaller after doing that, and it looks
better now since we do not allocate full 8 byte range.
cat /proc/ioports is now much happier and monitor finally works.
...
0295-0296 : pnp 00:09
0295-0296 : w83627hf
...
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <[EMAIL PROTECTED]>
diff -urN linux-2.6.13-5bca.dist/drivers/hwmon/w83627hf.c
linux-2.6.13-5bca/drivers/hwmon/w83627hf.c
--- linux-2.6.13-5bca.dist/drivers/hwmon/w83627hf.c 2005-09-06
13:50:03.0 +0200
+++ linux-2.6.13-5bca/drivers/hwmon/w83627hf.c 2005-09-07 19:54:08.0
+0200
@@ -138,12 +138,16 @@
#define WINB_BASE_REG 0x60
/* Constants specified below */
-/* Length of ISA address segment */
-#define WINB_EXTENT 8
+/* Alignment of ISA address */
+#define WINB_ALIGNMENT ~7
-/* Where are the ISA address/data registers relative to the base address */
-#define W83781D_ADDR_REG_OFFSET 5
-#define W83781D_DATA_REG_OFFSET 6
+/* Offset & size of I/O region we are interested in */
+#define WINB_REGION_OFFSET 5
+#define WINB_REGION_SIZE 2
+
+/* Where are the ISA address/data registers relative to the region start */
+#define W83781D_ADDR_REG_OFFSET 0
+#define W83781D_DATA_REG_OFFSET 1
/* The W83781D registers */
/* The W83782D registers for nr=7,8 are in bank 5 */
@@ -977,7 +981,7 @@
superio_select(W83627HF_LD_HWM);
val = (superio_inb(WINB_BASE_REG) << 8) |
superio_inb(WINB_BASE_REG + 1);
- *addr = val & ~(WINB_EXTENT - 1);
+ *addr = val & WINB_ALIGNMENT;
if (*addr == 0 && force_addr == 0) {
superio_exit();
return -ENODEV;
@@ -994,11 +998,13 @@
struct w83627hf_data *data;
int err = 0;
const char *client_name = "";
+ unsigned short addr;
if(force_addr)
- address = force_addr & ~(WINB_EXTENT - 1);
+ address = force_addr & WINB_ALIGNMENT;
+ addr = address + WINB_REGION_OFFSET;
- if (!request_region(address, WINB_EXTENT, w83627hf_driver.name)) {
+ if (!request_region(addr, WINB_REGION_SIZE, w83627hf_driver.name)) {
err = -EBUSY;
goto ERROR0;
}
@@ -1045,7 +1051,7 @@
new_client = >client;
i2c_set_clientdata(new_client, data);
- new_client->addr = address;
+ new_client->addr = addr;
init_MUTEX(>lock);
new_client->adapter = adapter;
new_client->driver = _driver;
@@ -1144,7 +1150,7 @@
ERROR2:
kfree(data);
ERROR1:
- release_region(address, WINB_EXTENT);
+ release_region(addr, WINB_REGION_SIZE);
ERROR0:
return err;
}
@@ -1159,7 +1165,7 @@
if ((err = i2c_detach_client(client)))
return err;
- release_region(client->addr, WINB_EXTENT);
+ release_region(client->addr, WINB_REGION_SIZE);
kfree(data);
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ncpfs: Connection invalid / Input-/Output Errors
schönfeld / in-medias-res wrote: Hi, thanks for your answere. Uhmm... then remains the question: Why should that happen on the first machine but not on the second? Enable displaying of connection watchdog logouts on the server. Do not use 'intr' mount option. Do not send KILL signal to the connection which is waiting for reply from server. If you are not sure that your network infrastructure is fine, use 'hard' mount option to disable timeouts altogether. To see if this is your problem, insert some printk()s in the relevant ncpfs code (depends whether you are using ipx or tcp/udp as to where) Well - i'm using IPX. So where do i insert the printk()s? And what kind of printk()s should i insert? Please don't think of me as an idiot, but i'm just not firm with "kernel hacking". Into 'ncp_invalidate_conn()', or better, into its callers. One is in __abort_ncp_connection (invoked for IPX connections when __ncpdgram_timeout_proc fires), second is in ncp_do_request (if server reports some problem, or if KILL signal is sent to the process). Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ncpfs: Connection invalid / Input-/Output Errors
schönfeld / in-medias-res wrote: Hi, thanks for your answere. Uhmm... then remains the question: Why should that happen on the first machine but not on the second? Enable displaying of connection watchdog logouts on the server. Do not use 'intr' mount option. Do not send KILL signal to the connection which is waiting for reply from server. If you are not sure that your network infrastructure is fine, use 'hard' mount option to disable timeouts altogether. To see if this is your problem, insert some printk()s in the relevant ncpfs code (depends whether you are using ipx or tcp/udp as to where) Well - i'm using IPX. So where do i insert the printk()s? And what kind of printk()s should i insert? Please don't think of me as an idiot, but i'm just not firm with kernel hacking. Into 'ncp_invalidate_conn()', or better, into its callers. One is in __abort_ncp_connection (invoked for IPX connections when __ncpdgram_timeout_proc fires), second is in ncp_do_request (if server reports some problem, or if KILL signal is sent to the process). Petr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Request only really used I/O ports in w83627hf driver
Hello,
my motherboard (Tyan S2885) reports range 295-296 in its PNP hardware
descriptors, and due to this w83627hf driver fails to load, as it requests
290-297 range, which is not subrange of this PNP resource. As hardware
monitor chip responds to 295/296 addresses only, there is no reason to
request full 8 byte I/O.
While I was doing that, I also changed W83781D_*_REG_OFFSET definitions
from 5/6 to 0/1. Code is a bit smaller after doing that, and it looks
better now since we do not allocate full 8 byte range.
cat /proc/ioports is now much happier and monitor finally works.
...
0295-0296 : pnp 00:09
0295-0296 : w83627hf
...
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec [EMAIL PROTECTED]
diff -urN linux-2.6.13-5bca.dist/drivers/hwmon/w83627hf.c
linux-2.6.13-5bca/drivers/hwmon/w83627hf.c
--- linux-2.6.13-5bca.dist/drivers/hwmon/w83627hf.c 2005-09-06
13:50:03.0 +0200
+++ linux-2.6.13-5bca/drivers/hwmon/w83627hf.c 2005-09-07 19:54:08.0
+0200
@@ -138,12 +138,16 @@
#define WINB_BASE_REG 0x60
/* Constants specified below */
-/* Length of ISA address segment */
-#define WINB_EXTENT 8
+/* Alignment of ISA address */
+#define WINB_ALIGNMENT ~7
-/* Where are the ISA address/data registers relative to the base address */
-#define W83781D_ADDR_REG_OFFSET 5
-#define W83781D_DATA_REG_OFFSET 6
+/* Offset size of I/O region we are interested in */
+#define WINB_REGION_OFFSET 5
+#define WINB_REGION_SIZE 2
+
+/* Where are the ISA address/data registers relative to the region start */
+#define W83781D_ADDR_REG_OFFSET 0
+#define W83781D_DATA_REG_OFFSET 1
/* The W83781D registers */
/* The W83782D registers for nr=7,8 are in bank 5 */
@@ -977,7 +981,7 @@
superio_select(W83627HF_LD_HWM);
val = (superio_inb(WINB_BASE_REG) 8) |
superio_inb(WINB_BASE_REG + 1);
- *addr = val ~(WINB_EXTENT - 1);
+ *addr = val WINB_ALIGNMENT;
if (*addr == 0 force_addr == 0) {
superio_exit();
return -ENODEV;
@@ -994,11 +998,13 @@
struct w83627hf_data *data;
int err = 0;
const char *client_name = ;
+ unsigned short addr;
if(force_addr)
- address = force_addr ~(WINB_EXTENT - 1);
+ address = force_addr WINB_ALIGNMENT;
+ addr = address + WINB_REGION_OFFSET;
- if (!request_region(address, WINB_EXTENT, w83627hf_driver.name)) {
+ if (!request_region(addr, WINB_REGION_SIZE, w83627hf_driver.name)) {
err = -EBUSY;
goto ERROR0;
}
@@ -1045,7 +1051,7 @@
new_client = data-client;
i2c_set_clientdata(new_client, data);
- new_client-addr = address;
+ new_client-addr = addr;
init_MUTEX(data-lock);
new_client-adapter = adapter;
new_client-driver = w83627hf_driver;
@@ -1144,7 +1150,7 @@
ERROR2:
kfree(data);
ERROR1:
- release_region(address, WINB_EXTENT);
+ release_region(addr, WINB_REGION_SIZE);
ERROR0:
return err;
}
@@ -1159,7 +1165,7 @@
if ((err = i2c_detach_client(client)))
return err;
- release_region(client-addr, WINB_EXTENT);
+ release_region(client-addr, WINB_REGION_SIZE);
kfree(data);
return 0;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
