[PATCH] Remove redundant (deprecated) CONFIG_FORCED_INLINING option.
Remove the superfluous kernel config option FORCED_UNLINING from the kernel debugging menu. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- based on adrian bunk's explanation, and the fact that i just noticed this option was scheduled for removal several months ago anyway, this option clearly has no value. Documentation/feature-removal-schedule.txt |9 - include/linux/compiler-gcc4.h |9 - lib/Kconfig.debug | 14 -- 3 files changed, 32 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index fc53239..bf82ef5 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -109,15 +109,6 @@ Who: Christoph Hellwig <[EMAIL PROTECTED]> --- -What: CONFIG_FORCED_INLINING -When: June 2006 -Why: Config option is there to see if gcc is good enough. (in january -2006). If it is, the behavior should just be the default. If it's not, - the option should just go away entirely. -Who:Arjan van de Ven - - What: eepro100 network driver When: January 2007 Why:replaced by the e100 driver diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index 6f5cc6f..8249115 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -3,15 +3,6 @@ /* These definitions are for GCC v4.x. */ #include -#ifdef CONFIG_FORCED_INLINING -# undef inline -# undef __inline__ -# undef __inline -# define inlineinline __attribute__((always_inline)) -# define __inline____inline__ __attribute__((always_inline)) -# define __inline __inline__attribute__((always_inline)) -#endif - #define __attribute_used__ __attribute__((__used__)) #define __must_check __attribute__((warn_unused_result)) #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 5c26818..70a9b56 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -354,20 +354,6 @@ config FRAME_POINTER some architectures or if you use external debuggers. If you don't debug the kernel, you can say N. -config FORCED_INLINING - bool "Force gcc to inline functions marked 'inline'" - depends on DEBUG_KERNEL - default y - help - This option determines if the kernel forces gcc to inline the functions - developers have marked 'inline'. Doing so takes away freedom from gcc to - do what it thinks is best, which is desirable for the gcc 3.x series of - compilers. The gcc 4.x series have a rewritten inlining algorithm and - disabling this option will generate a smaller kernel there. Hopefully - this algorithm is so good that allowing gcc4 to make the decision can - become the default in the future, until then this option is there to - test gcc for this. - config RCU_TORTURE_TEST tristate "torture tests for RCU" depends on DEBUG_KERNEL - 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] nfs: fix congestion control -v3
Subject: nfs: fix congestion control
The current NFS client congestion logic is severly broken, it marks the backing
device congested during each nfs_writepages() call but doesn't mirror this in
nfs_writepage() which makes for deadlocks. Also it implements its own waitqueue.
Replace this by a more regular congestion implementation that puts a cap on the
number of active writeback pages and uses the bdi congestion waitqueue.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
Cc: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/nfs/super.c |4 -
fs/nfs/sysctl.c |8 +++
fs/nfs/write.c | 116
include/linux/backing-dev.h |1
include/linux/nfs_fs.h |1
include/linux/nfs_fs_sb.h |1
mm/backing-dev.c| 16 ++
7 files changed, 104 insertions(+), 43 deletions(-)
Index: linux-2.6-git/fs/nfs/write.c
===
--- linux-2.6-git.orig/fs/nfs/write.c 2007-01-20 07:20:10.0 +0100
+++ linux-2.6-git/fs/nfs/write.c2007-01-20 07:20:12.0 +0100
@@ -89,8 +89,6 @@ static struct kmem_cache *nfs_wdata_cach
static mempool_t *nfs_wdata_mempool;
static mempool_t *nfs_commit_mempool;
-static DECLARE_WAIT_QUEUE_HEAD(nfs_write_congestion);
-
struct nfs_write_data *nfs_commit_alloc(void)
{
struct nfs_write_data *p = mempool_alloc(nfs_commit_mempool, GFP_NOFS);
@@ -245,6 +243,39 @@ static int wb_priority(struct writeback_
}
/*
+ * NFS congestion control
+ */
+
+int nfs_congestion_kb;
+
+#define NFS_CONGESTION_ON_THRESH (nfs_congestion_kb >> (PAGE_SHIFT-10))
+#define NFS_CONGESTION_OFF_THRESH \
+ (NFS_CONGESTION_ON_THRESH - (NFS_CONGESTION_ON_THRESH >> 2))
+
+static inline void nfs_set_page_writeback(struct page *page)
+{
+ if (!test_set_page_writeback(page)) {
+ struct inode *inode = page->mapping->host;
+ struct nfs_server *nfss = NFS_SERVER(inode);
+
+ if (atomic_inc_return(>writeback) >
NFS_CONGESTION_ON_THRESH)
+ set_bdi_congested(>backing_dev_info, WRITE);
+ }
+}
+
+static inline void nfs_end_page_writeback(struct page *page)
+{
+ struct inode *inode = page->mapping->host;
+ struct nfs_server *nfss = NFS_SERVER(inode);
+
+ end_page_writeback(page);
+ if (atomic_dec_return(>writeback) < NFS_CONGESTION_OFF_THRESH) {
+ clear_bdi_congested(>backing_dev_info, WRITE);
+ congestion_end(WRITE);
+ }
+}
+
+/*
* Find an associated nfs write request, and prepare to flush it out
* Returns 1 if there was no write request, or if the request was
* already tagged by nfs_set_page_dirty.Returns 0 if the request
@@ -281,7 +312,7 @@ static int nfs_page_mark_flush(struct pa
spin_unlock(req_lock);
if (test_and_set_bit(PG_FLUSHING, >wb_flags) == 0) {
nfs_mark_request_dirty(req);
- set_page_writeback(page);
+ nfs_set_page_writeback(page);
}
ret = test_bit(PG_NEED_FLUSH, >wb_flags);
nfs_unlock_request(req);
@@ -336,13 +367,8 @@ int nfs_writepage(struct page *page, str
return err;
}
-/*
- * Note: causes nfs_update_request() to block on the assumption
- * that the writeback is generated due to memory pressure.
- */
int nfs_writepages(struct address_space *mapping, struct writeback_control
*wbc)
{
- struct backing_dev_info *bdi = mapping->backing_dev_info;
struct inode *inode = mapping->host;
int err;
@@ -351,11 +377,6 @@ int nfs_writepages(struct address_space
err = generic_writepages(mapping, wbc);
if (err)
return err;
- while (test_and_set_bit(BDI_write_congested, >state) != 0) {
- if (wbc->nonblocking)
- return 0;
- nfs_wait_on_write_congestion(mapping, 0);
- }
err = nfs_flush_mapping(mapping, wbc, wb_priority(wbc));
if (err < 0)
goto out;
@@ -369,9 +390,6 @@ int nfs_writepages(struct address_space
if (err > 0)
err = 0;
out:
- clear_bit(BDI_write_congested, >state);
- wake_up_all(_write_congestion);
- congestion_end(WRITE);
return err;
}
@@ -401,7 +419,7 @@ static int nfs_inode_add_request(struct
}
/*
- * Insert a write request into an inode
+ * Remove a write request from an inode
*/
static void nfs_inode_remove_request(struct nfs_page *req)
{
@@ -585,8 +603,8 @@ static inline int nfs_scan_commit(struct
static int nfs_wait_on_write_congestion(struct address_space *mapping, int
intr)
{
+ struct inode *inode = mapping->host;
struct backing_dev_info *bdi = mapping->backing_dev_info;
- DEFINE_WAIT(wait);
int ret = 0;
might_sleep();
@@ -594,31 +612,27 @@ static int nfs_wait_on_write_congestion(
if
[patch] buffer: memorder fix
Anyone mind telling me why unlock_buffer, unlike unlock_page, thinks it can
clear the lock without ensuring the critical section is closed (ie. with a
barrier)?
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/buffer.c
===
--- linux-2.6.orig/fs/buffer.c
+++ linux-2.6/fs/buffer.c
@@ -78,6 +78,7 @@ EXPORT_SYMBOL(__lock_buffer);
void fastcall unlock_buffer(struct buffer_head *bh)
{
+ smp_mb__before_clear_bit();
clear_buffer_locked(bh);
smp_mb__after_clear_bit();
wake_up_bit(>b_state, BH_Lock);
-
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 6/7] devres: implement pcim_iomap_regions()
Implement pcim_iomap_regions(). This function takes mask of BARs to
request and iomap. No BAR should have length of zero. BARs are
iomapped using pcim_iomap_table().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/io.h |2 +
lib/iomap.c| 53
2 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index f5edf9c..45a9c94 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -45,6 +45,8 @@ void __iomem * pcim_iomap(struct pci_dev *pdev, int bar,
unsigned long maxlen);
void pcim_iounmap(struct pci_dev *pdev, void __iomem *addr);
void __iomem * const * pcim_iomap_table(struct pci_dev *pdev);
+int pcim_iomap_regions(struct pci_dev *pdev, u16 mask, const char *name);
+
/**
* check_signature - find BIOS signatures
* @io_addr: mmio address to check
diff --git a/lib/iomap.c b/lib/iomap.c
index 3214028..4990c73 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -498,3 +498,56 @@ void pcim_iounmap(struct pci_dev *pdev, void __iomem *addr)
WARN_ON(1);
}
EXPORT_SYMBOL(pcim_iounmap);
+
+/**
+ * pcim_iomap_regions - Request and iomap PCI BARs
+ * @pdev: PCI device to map IO resources for
+ * @mask: Mask of BARs to request and iomap
+ * @name: Name used when requesting regions
+ *
+ * Request and iomap regions specified by @mask.
+ */
+int pcim_iomap_regions(struct pci_dev *pdev, u16 mask, const char *name)
+{
+ void __iomem * const *iomap;
+ int i, rc;
+
+ iomap = pcim_iomap_table(pdev);
+ if (!iomap)
+ return -ENOMEM;
+
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ unsigned long len;
+
+ if (!(mask & (1 << i)))
+ continue;
+
+ rc = -EINVAL;
+ len = pci_resource_len(pdev, i);
+ if (!len)
+ goto err_inval;
+
+ rc = pci_request_region(pdev, i, name);
+ if (rc)
+ goto err_region;
+
+ rc = -ENOMEM;
+ if (!pcim_iomap(pdev, i, 0))
+ goto err_iomap;
+ }
+
+ return 0;
+
+ err_iomap:
+ pcim_iounmap(pdev, iomap[i]);
+ err_region:
+ pci_release_region(pdev, i);
+ err_inval:
+ while (--i >= 0) {
+ pcim_iounmap(pdev, iomap[i]);
+ pci_release_region(pdev, i);
+ }
+
+ return rc;
+}
+EXPORT_SYMBOL(pcim_iomap_regions);
--
1.4.4.4
-
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 5/7] libata: remove unused functions
Now that all LLDs are converted to use devres, default stop callbacks
are unused. Remove them.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 81 +++-
include/linux/libata.h|4 --
2 files changed, 6 insertions(+), 79 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index a9a4c67..34e7f18 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5516,31 +5516,6 @@ int ata_port_start(struct ata_port *ap)
}
/**
- * ata_port_stop - Undo ata_port_start()
- * @ap: Port to shut down
- *
- * Frees the PRD table.
- *
- * May be used as the port_stop() entry in ata_port_operations.
- *
- * LOCKING:
- * Inherited from caller.
- */
-void ata_port_stop (struct ata_port *ap)
-{
- struct device *dev = ap->dev;
-
- dmam_free_coherent(dev, ATA_PRD_TBL_SZ, ap->prd, ap->prd_dma);
- ata_pad_free(ap, dev);
-}
-
-void ata_host_stop (struct ata_host *host)
-{
- if (host->mmio_base)
- iounmap(host->mmio_base);
-}
-
-/**
* ata_dev_init - Initialize an ata_device structure
* @dev: Device structure to initialize
*
@@ -5879,7 +5854,7 @@ int ata_device_add(const struct ata_probe_ent *ent)
}
/* resource acquisition complete */
- devres_close_group(dev, ata_device_add);
+ devres_remove_group(dev, ata_device_add);
/* perform each probe synchronously */
DPRINTK("probe begin\n");
@@ -6034,22 +6009,6 @@ void ata_host_detach(struct ata_host *host)
ata_port_detach(host->ports[i]);
}
-/**
- * ata_host_remove - PCI layer callback for device removal
- * @host: ATA host set that was removed
- *
- * Unregister all objects associated with this host set. Free those
- * objects.
- *
- * LOCKING:
- * Inherited from calling layer (may sleep).
- */
-void ata_host_remove(struct ata_host *host)
-{
- ata_host_detach(host);
- devres_release_group(host->dev, ata_device_add);
-}
-
struct ata_probe_ent *
ata_probe_ent_alloc(struct device *dev, const struct ata_port_info *port)
{
@@ -6109,26 +6068,13 @@ void ata_std_ports(struct ata_ioports *ioaddr)
#ifdef CONFIG_PCI
-void ata_pci_host_stop (struct ata_host *host)
-{
- struct pci_dev *pdev = to_pci_dev(host->dev);
-
- /* XXX - the following if can go away once all LLDs are managed */
- if (!list_empty(>dev->devres_head))
- pcim_iounmap(pdev, host->mmio_base);
- else
- pci_iounmap(pdev, host->mmio_base);
-}
-
/**
* ata_pci_remove_one - PCI layer callback for device removal
* @pdev: PCI device that was removed
*
- * PCI layer indicates to libata via this hook that
- * hot-unplug or module unload event has occurred.
- * Handle this by unregistering all objects associated
- * with this PCI device. Free those objects. Then finally
- * release PCI resources and disable device.
+ * PCI layer indicates to libata via this hook that hot-unplug or
+ * module unload event has occurred. Detach all ports. Resource
+ * release is handled via devres.
*
* LOCKING:
* Inherited from PCI layer (may sleep).
@@ -6138,14 +6084,7 @@ void ata_pci_remove_one(struct pci_dev *pdev)
struct device *dev = pci_dev_to_dev(pdev);
struct ata_host *host = dev_get_drvdata(dev);
- /* XXX - the following if can go away once all LLDs are managed */
- if (!list_empty(>dev->devres_head)) {
- ata_host_remove(host);
- pci_release_regions(pdev);
- pci_disable_device(pdev);
- dev_set_drvdata(dev, NULL);
- } else
- ata_host_detach(host);
+ ata_host_detach(host);
}
/* move to PCI subsystem */
@@ -6199,11 +6138,7 @@ int ata_pci_device_do_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- /* XXX - the following if can go away once all LLDs are managed */
- if (!list_empty(>dev.devres_head))
- rc = pcim_enable_device(pdev);
- else
- rc = pci_enable_device(pdev);
+ rc = pcim_enable_device(pdev);
if (rc) {
dev_printk(KERN_ERR, >dev,
"failed to enable device after resume (%d)\n", rc);
@@ -6383,7 +6318,6 @@ EXPORT_SYMBOL_GPL(ata_std_ports);
EXPORT_SYMBOL_GPL(ata_host_init);
EXPORT_SYMBOL_GPL(ata_device_add);
EXPORT_SYMBOL_GPL(ata_host_detach);
-EXPORT_SYMBOL_GPL(ata_host_remove);
EXPORT_SYMBOL_GPL(ata_sg_init);
EXPORT_SYMBOL_GPL(ata_sg_init_one);
EXPORT_SYMBOL_GPL(ata_hsm_move);
@@ -6400,8 +6334,6 @@ EXPORT_SYMBOL_GPL(ata_check_status);
EXPORT_SYMBOL_GPL(ata_altstatus);
EXPORT_SYMBOL_GPL(ata_exec_command);
EXPORT_SYMBOL_GPL(ata_port_start);
-EXPORT_SYMBOL_GPL(ata_port_stop);
-EXPORT_SYMBOL_GPL(ata_host_stop);
EXPORT_SYMBOL_GPL(ata_interrupt);
[PATCH 3/7] libata: update libata core layer to use devres
Update libata core layer to use devres.
* ata_device_add() acquires all resources in managed mode.
* ata_host is allocated as devres associated with ata_host_release.
* Port attached status is handled as devres associated with
ata_host_attach_release().
* Initialization failure and host removal is handedl by releasing
devres group.
* Except for ata_scsi_release() removal, LLD interface remains the
same. Some functions use hacky is_managed test to support both
managed and unmanaged devices. These will go away once all LLDs are
updated to use devres.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/ahci.c| 21 +-
drivers/ata/libata-core.c | 177 +++--
drivers/ata/libata-scsi.c |3 +-
drivers/ata/libata-sff.c | 56 ++-
include/linux/libata.h|9 +--
5 files changed, 106 insertions(+), 160 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index d089217..7abe138 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1759,37 +1759,24 @@ err_out:
return rc;
}
-static void ahci_remove_one (struct pci_dev *pdev)
+static void ahci_remove_one(struct pci_dev *pdev)
{
struct device *dev = pci_dev_to_dev(pdev);
struct ata_host *host = dev_get_drvdata(dev);
struct ahci_host_priv *hpriv = host->private_data;
- unsigned int i;
- int have_msi;
- ata_host_detach(host);
+ ata_host_remove(host);
- have_msi = hpriv->flags & AHCI_FLAG_MSI;
- free_irq(host->irq, host);
-
- for (i = 0; i < host->n_ports; i++) {
- struct ata_port *ap = host->ports[i];
-
- ata_scsi_release(ap->scsi_host);
- scsi_host_put(ap->scsi_host);
- }
-
- kfree(hpriv);
pci_iounmap(pdev, host->mmio_base);
- kfree(host);
- if (have_msi)
+ if (hpriv->flags & AHCI_FLAG_MSI)
pci_disable_msi(pdev);
else
pci_intx(pdev, 0);
pci_release_regions(pdev);
pci_disable_device(pdev);
dev_set_drvdata(dev, NULL);
+ kfree(hpriv);
}
static int __init ahci_init(void)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 20a943f..a9a4c67 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5496,28 +5496,25 @@ void ata_host_resume(struct ata_host *host)
* LOCKING:
* Inherited from caller.
*/
-
-int ata_port_start (struct ata_port *ap)
+int ata_port_start(struct ata_port *ap)
{
struct device *dev = ap->dev;
int rc;
- ap->prd = dma_alloc_coherent(dev, ATA_PRD_TBL_SZ, >prd_dma,
GFP_KERNEL);
+ ap->prd = dmam_alloc_coherent(dev, ATA_PRD_TBL_SZ, >prd_dma,
+ GFP_KERNEL);
if (!ap->prd)
return -ENOMEM;
rc = ata_pad_alloc(ap, dev);
- if (rc) {
- dma_free_coherent(dev, ATA_PRD_TBL_SZ, ap->prd, ap->prd_dma);
+ if (rc)
return rc;
- }
-
- DPRINTK("prd alloc, virt %p, dma %llx\n", ap->prd, (unsigned long long)
ap->prd_dma);
+ DPRINTK("prd alloc, virt %p, dma %llx\n", ap->prd,
+ (unsigned long long)ap->prd_dma);
return 0;
}
-
/**
* ata_port_stop - Undo ata_port_start()
* @ap: Port to shut down
@@ -5529,12 +5526,11 @@ int ata_port_start (struct ata_port *ap)
* LOCKING:
* Inherited from caller.
*/
-
void ata_port_stop (struct ata_port *ap)
{
struct device *dev = ap->dev;
- dma_free_coherent(dev, ATA_PRD_TBL_SZ, ap->prd, ap->prd_dma);
+ dmam_free_coherent(dev, ATA_PRD_TBL_SZ, ap->prd, ap->prd_dma);
ata_pad_free(ap, dev);
}
@@ -5717,6 +5713,27 @@ static struct ata_port * ata_port_add(const struct
ata_probe_ent *ent,
return ap;
}
+static void ata_host_release(struct device *gendev, void *res)
+{
+ struct ata_host *host = dev_get_drvdata(gendev);
+ int i;
+
+ for (i = 0; i < host->n_ports; i++) {
+ struct ata_port *ap = host->ports[i];
+
+ if (!ap)
+ continue;
+
+ if (ap->ops->port_stop)
+ ap->ops->port_stop(ap);
+
+ scsi_host_put(ap->scsi_host);
+ }
+
+ if (host->ops->host_stop)
+ host->ops->host_stop(host);
+}
+
/**
* ata_sas_host_init - Initialize a host struct
* @host: host to initialize
@@ -5769,11 +5786,17 @@ int ata_device_add(const struct ata_probe_ent *ent)
dev_printk(KERN_ERR, dev, "is not available: No interrupt
assigned.\n");
return 0;
}
+
+ if (!devres_open_group(dev, ata_device_add, GFP_KERNEL))
+ return 0;
+
/* alloc a container for our list of ATA ports (buses) */
- host = kzalloc(sizeof(struct ata_host) +
- (ent->n_ports * sizeof(void *)), GFP_KERNEL);
+
[PATCH 2/7] libata: implement ata_host_detach()
Implement ata_host_detach() which calls ata_port_detach() for each
port in the host and export it. ata_port_detach() is now internal and
thus un-exported. ata_host_detach() will be used as the 'deregister
from libata layer' function after devres conversion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/ahci.c|3 +--
drivers/ata/libata-core.c | 22 +++---
include/linux/libata.h|2 +-
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5998f74..d089217 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1767,8 +1767,7 @@ static void ahci_remove_one (struct pci_dev *pdev)
unsigned int i;
int have_msi;
- for (i = 0; i < host->n_ports; i++)
- ata_port_detach(host->ports[i]);
+ ata_host_detach(host);
have_msi = hpriv->flags & AHCI_FLAG_MSI;
free_irq(host->irq, host);
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 8315ee6..20a943f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6002,6 +6002,23 @@ void ata_port_detach(struct ata_port *ap)
}
/**
+ * ata_host_detach - Detach all ports of an ATA host
+ * @host: Host to detach
+ *
+ * Detach all ports of @host.
+ *
+ * LOCKING:
+ * Kernel thread context (may sleep).
+ */
+void ata_host_detach(struct ata_host *host)
+{
+ int i;
+
+ for (i = 0; i < host->n_ports; i++)
+ ata_port_detach(host->ports[i]);
+}
+
+/**
* ata_host_remove - PCI layer callback for device removal
* @host: ATA host set that was removed
*
@@ -6016,8 +6033,7 @@ void ata_host_remove(struct ata_host *host)
{
unsigned int i;
- for (i = 0; i < host->n_ports; i++)
- ata_port_detach(host->ports[i]);
+ ata_host_detach(host);
free_irq(host->irq, host);
if (host->irq2)
@@ -6392,7 +6408,7 @@ EXPORT_SYMBOL_GPL(ata_std_bios_param);
EXPORT_SYMBOL_GPL(ata_std_ports);
EXPORT_SYMBOL_GPL(ata_host_init);
EXPORT_SYMBOL_GPL(ata_device_add);
-EXPORT_SYMBOL_GPL(ata_port_detach);
+EXPORT_SYMBOL_GPL(ata_host_detach);
EXPORT_SYMBOL_GPL(ata_host_remove);
EXPORT_SYMBOL_GPL(ata_sg_init);
EXPORT_SYMBOL_GPL(ata_sg_init_one);
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 09c110a..8bad682 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -718,7 +718,7 @@ extern int ata_pci_device_resume(struct pci_dev *pdev);
extern int ata_pci_clear_simplex(struct pci_dev *pdev);
#endif /* CONFIG_PCI */
extern int ata_device_add(const struct ata_probe_ent *ent);
-extern void ata_port_detach(struct ata_port *ap);
+extern void ata_host_detach(struct ata_host *host);
extern void ata_host_init(struct ata_host *, struct device *,
unsigned long, const struct ata_port_operations *);
extern void ata_host_remove(struct ata_host *host);
--
1.4.4.4
-
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/
[PATCHSET] Managed device resources, take #3
Hello, This is the third iteration of devres patchset. Changes from the last take[L] are... * devres patches collapsed into one as Jeff requested * updates for sata_inic162x added * rebased to the current upstream Git tree is available at the following URLs. http://htj.dyndns.org/git/?p=libata-tj.git;a=shortlog;h=devres git://htj.dyndns.org/libata-tj devres For detailed info, please read Documentation/driver-model/devres.txt. Similar info can also be found from the initial take[I]. This patchset is against [U] libata-dev#upstream [1] + sata_promise-kill-qc-nsect [2] + lbiata-fix-compile-warning-caused-by-ignoring-__must_check results The git tree contains both previous patches, but this patchset apply okay with either one of or both patches omitted. Thanks. -- tejun [L] http://thread.gmane.org/gmane.linux.kernel/482455 [I] http://thread.gmane.org/gmane.linux.ide/14690 [U] 8ed22df2570dbb7df2bd161bb9381a6fd17de3d3 [1] http://article.gmane.org/gmane.linux.ide/15189 [2] http://article.gmane.org/gmane.linux.ide/15192 - 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: problems with latest smbfs changes on 2.4.34 and security backports
On Fri, Jan 19, 2007 at 06:05:44PM -0700, dann frazier wrote: (...) > Ah, think I see the problem now: > > --- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 17:53:57.247695476 > -0700 > +++ kernel-source-2.4.27/fs/smbfs/proc.c 2007-01-19 17:49:07.480161733 > -0700 > @@ -1997,7 +1997,7 @@ > fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | > S_IRWXO)) | S_IFDIR; > else if ( (server->mnt->flags & SMB_MOUNT_FMODE) && > !(S_ISDIR(fattr->f_mode)) ) > - fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | > S_IRWXO)) | S_IFREG; > + fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | > S_IRWXO)) | (fattr->f_mode & S_IFMT); > > } > > Santiago: Thanks for reporting this - can you test this patch out on > your system and let me know if there are still any problems? > > Willy: I'll do some more testing and get you a patch that fixes this > and the double assignment nonsense. Would you prefer a single patch or > two? Since the double assignment is not a bug per se, don't bother making a separate patch, put everything in the same one. Thanks a lot for your very fast response ! Cheers, Willy - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
On 1/20/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Aubrey Li wrote: > So what's the right way to limit pagecache? Probably something a lot more complicated... if you can say there is a "right way". >> Secondly, your patch isn't actually very good. It unconditionally >> shrinks memory to below the given % mark each time a pagecache alloc >> occurs, regardless of how much pagecache is in the system. Effectively >> that seems to just reduce the amount of memory available to the system. > > > It doesn't reduce the amount of memory available to the system. It > just reduce the amount of memory available to the page cache. So that > page cache is limited and the reserved memory can be allocated by the > application. But the patch doesn't do that, as I explained. I'm not sure you read the correct patch. Let me explain the logic again. assume: min = 123pages pagecache_reserved = 200 pages if( alloc_flags & ALLOC_PAGECACHE) watermark = min + pagecache_reserved ( 323 pages) else watermark = min ( 123 pages) So if request pagecache, when free pages < 323 pages, reclaim is triggered. But at this time if request memory not pagecache, reclaim will be triggered when free pages < 123 as the present reclaimer does. I verified it on my side, why do you think it doesn't work properly? >> Luckily, there are actually good, robust solutions for your higher >> order allocation problem. Do higher order allocations at boot time, >> modifiy userspace applications, or set up otherwise-unused, or easily >> reclaimable reserve pools for higher order allocations. I don't >> understand why you are so resistant to all of these approaches? >> > > I think we have explained the reason too much. We are working on > no-mmu arch and provide a platform running linux to our customer. They > are doing very good things like mplayer, asterisk, ip camera, etc on > our platform, some applications was migrated from mmu arch. I think > that means in some cases no-mmu arch is somewhat better than mmu arch. > So we are taking effort to make the migration smooth or make no-mmu > linux stronger. > It's no way to let our customer modify their applications, we also > unwilling to do it. And we have not an existing mechanism to set up a > pools for the complex applications. So I'm trying to do some coding > hack in the kernel to satisfy these kinds of requirement. Oh, maybe you misunderstand the reserve pools idea: that is an entirely kernel based solution where you can preallocate a large, contiguous pool of memory at boot time which you can use to satisfy your nommu higher order anonymous memory allocations. This is something that will not get fragmented by pagecache, nor will it get fragmented by any other page allocation, slab allocation. Tt is a pretty good solution provided that you size the pool correctly for your application's needs. So if application malloc(1M), how does kernel know to allocate reserved pool not from buddy system? I didn't see any special code about this. Is there any doc or example? -Aubrey - 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: SATA exceptions with 2.6.20-rc5
On 2007.01.19 20:41:36 -0600, Robert Hancock wrote: > Alistair John Strachan wrote: > >On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > >>Robert Hancock wrote: > >>>I'll try your stress test when I get a chance, but I doubt I'll run into > >>>the same problem and I haven't seen any similar reports. Perhaps it's > >>>some kind of wierd timing issue or incompatibility between the > >>>controller and that drive when running in ADMA mode? I seem to remember > >>>various reports of issues with certain Maxtor drives and some nForce > >>>SATA controllers under Windows at least.. > >>Just to eliminate things, has disabling ADMA been attempted? > >> > >>It can be disabled using the sata_nv.adma module parameter. > > > >Setting this option fixes the problem for me. I suggest that ADMA defaults > >off in 2.6.20, if there's still time to do that. > > > > Can you guys that are having this problem try the attached debug patch? > It's possible it will fix the problem, as I'm trying a private > exec_command implementation that flushes the write by reading a > controller register instead of reading altstatus from the drive like the > libata core code does. Will give it a spin in about an hour. > If the problem still happens, I also added some more debugging in to > help figure out what is going on, so please post full dmesg. > > By the way, I assume that you guys are using reiserfs or xfs, as it > appears no other file systems issue flush commands automatically. I had > to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am > using ext3. No, ext3 here, on top of md RAID1 and LVM. Oh, and one ext2, I wonder where that comes from... Björn - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
Aubrey Li wrote: So what's the right way to limit pagecache? Probably something a lot more complicated... if you can say there is a "right way". Secondly, your patch isn't actually very good. It unconditionally shrinks memory to below the given % mark each time a pagecache alloc occurs, regardless of how much pagecache is in the system. Effectively that seems to just reduce the amount of memory available to the system. It doesn't reduce the amount of memory available to the system. It just reduce the amount of memory available to the page cache. So that page cache is limited and the reserved memory can be allocated by the application. But the patch doesn't do that, as I explained. Luckily, there are actually good, robust solutions for your higher order allocation problem. Do higher order allocations at boot time, modifiy userspace applications, or set up otherwise-unused, or easily reclaimable reserve pools for higher order allocations. I don't understand why you are so resistant to all of these approaches? I think we have explained the reason too much. We are working on no-mmu arch and provide a platform running linux to our customer. They are doing very good things like mplayer, asterisk, ip camera, etc on our platform, some applications was migrated from mmu arch. I think that means in some cases no-mmu arch is somewhat better than mmu arch. So we are taking effort to make the migration smooth or make no-mmu linux stronger. It's no way to let our customer modify their applications, we also unwilling to do it. And we have not an existing mechanism to set up a pools for the complex applications. So I'm trying to do some coding hack in the kernel to satisfy these kinds of requirement. Oh, maybe you misunderstand the reserve pools idea: that is an entirely kernel based solution where you can preallocate a large, contiguous pool of memory at boot time which you can use to satisfy your nommu higher order anonymous memory allocations. This is something that will not get fragmented by pagecache, nor will it get fragmented by any other page allocation, slab allocation. Tt is a pretty good solution provided that you size the pool correctly for your application's needs. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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] Statically initialize struct pid for swapper
From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Subject: [PATCH] Statically initialize struct pid for swapper
Statically initialize a struct pid for the swapper process (pid_t == 0)
and attach it to init_task. This is needed so task_pid(), task_pgrp()
and task_session() interfaces work on the swapper process also.
Signed-off-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Cc: Cedric Le Goater <[EMAIL PROTECTED]>
Cc: Dave Hansen <[EMAIL PROTECTED]>
Cc: Serge Hallyn <[EMAIL PROTECTED]>
Cc: Eric Biederman <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
include/linux/init_task.h | 27 +++
include/linux/pid.h |2 ++
kernel/pid.c |2 ++
3 files changed, 31 insertions(+)
Index: lx26-20-rc4-mm1/include/linux/init_task.h
===
--- lx26-20-rc4-mm1.orig/include/linux/init_task.h 2007-01-19
19:13:35.161859112 -0800
+++ lx26-20-rc4-mm1/include/linux/init_task.h 2007-01-19 19:15:05.893065872
-0800
@@ -90,6 +90,28 @@ extern struct nsproxy init_nsproxy;
extern struct group_info init_groups;
+#define INIT_STRUCT_PID { \
+ .count = ATOMIC_INIT(1), \
+ .nr = 0,\
+ /* Don't put this struct pid in pid_hash */ \
+ .pid_chain = { .next = NULL, .pprev = NULL }, \
+ .tasks = { \
+ { .first = _task.pids[PIDTYPE_PID].node }, \
+ { .first = _task.pids[PIDTYPE_PGID].node },\
+ { .first = _task.pids[PIDTYPE_SID].node }, \
+ }, \
+ .rcu= RCU_HEAD_INIT,\
+}
+
+#define INIT_PID_LINK(type)\
+{ \
+ .node = { \
+ .next = NULL, \
+ .pprev = _struct_pid.tasks[type].first,\
+ }, \
+ .pid = _struct_pid,\
+}
+
/*
* INIT_TASK is used to set up the first task table, touch at
* your own risk!. Base=0, limit=0x1f (=2MB)
@@ -141,6 +163,11 @@ extern struct group_info init_groups;
.cpu_timers = INIT_CPU_TIMERS(tsk.cpu_timers), \
.fs_excl= ATOMIC_INIT(0), \
.pi_lock= SPIN_LOCK_UNLOCKED, \
+ .pids = { \
+ [PIDTYPE_PID] = INIT_PID_LINK(PIDTYPE_PID),\
+ [PIDTYPE_PGID] = INIT_PID_LINK(PIDTYPE_PGID), \
+ [PIDTYPE_SID] = INIT_PID_LINK(PIDTYPE_SID),\
+ }, \
INIT_TRACE_IRQFLAGS \
INIT_LOCKDEP\
}
Index: lx26-20-rc4-mm1/kernel/pid.c
===
--- lx26-20-rc4-mm1.orig/kernel/pid.c 2007-01-19 19:13:35.162858960 -0800
+++ lx26-20-rc4-mm1/kernel/pid.c2007-01-19 19:13:38.925286984 -0800
@@ -27,11 +27,13 @@
#include
#include
#include
+#include
#define pid_hashfn(nr) hash_long((unsigned long)nr, pidhash_shift)
static struct hlist_head *pid_hash;
static int pidhash_shift;
static struct kmem_cache *pid_cachep;
+struct pid init_struct_pid = INIT_STRUCT_PID;
int pid_max = PID_MAX_DEFAULT;
Index: lx26-20-rc4-mm1/include/linux/pid.h
===
--- lx26-20-rc4-mm1.orig/include/linux/pid.h2007-01-19 19:13:35.161859112
-0800
+++ lx26-20-rc4-mm1/include/linux/pid.h 2007-01-19 19:13:38.925286984 -0800
@@ -51,6 +51,8 @@ struct pid
struct rcu_head rcu;
};
+extern struct pid init_struct_pid;
+
struct pid_link
{
struct hlist_node node;
-
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: Missing dmesg parameters in 2.6.19.2
On 1/20/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > 1) Compiling with SMP as Generic (CONFIG_X86_PC is not set, CONFIG_M686=y) > > > > Using x86 segment limits to approximate NX protection > > > Using APIC driver default > > > > 2) Compiling with SMP as Processor specific (CONFIG_X86_PC=y, > CONFIG_MPENTIUM4=y) > > I do not find the above mentioned parameters in this case. I don't think the "segment limits" message shows up in stock kernels, are you sure that was from 2.6.19.2? That sounds like a Fedora kernel with Exec Shield. -- Robert Hancock Saskatoon, SK, Canada I am very sorry, have lost my mind with the night out with these kernels (messed up). Yep, you are right. Case 1 is FC6 kernel. Case 2 is my customization with 2.6.19.2. I was thinking about APIC in Case 2 ~Akula2 - 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 6/10] mm: be sure to trim blocks
On Tue, Jan 16, 2007 at 08:14:16PM +0100, Peter Zijlstra wrote:
> On Tue, 2007-01-16 at 18:36 +0100, Peter Zijlstra wrote:
> > buf, bytes);
> > > @@ -1935,10 +1922,9 @@ generic_file_buffered_write(struct kiocb
> > > cur_iov, iov_offset, bytes);
> > > flush_dcache_page(page);
> > > status = a_ops->commit_write(file, page, offset, offset+bytes);
> > > - if (status == AOP_TRUNCATED_PAGE) {
> > > - page_cache_release(page);
> > > - continue;
> > > - }
> > > + if (unlikely(status))
> > > + goto fs_write_aop_error;
> > > +
> >
> > I don't think this is correct, see how status >= 0 is used a few lines
> > downwards. Perhaps something along the lines of an
> > is_positive_aop_return() to test on?
>
> Hmm, if commit_write() will never return non error positive values then
> this and 8/10 look sane.
It's really ugly, but it looks like at least some filesystems do. So
I'll fix up this.
-
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 6/10] mm: be sure to trim blocks
On Sun, Jan 14, 2007 at 05:25:44PM +0300, Dmitriy Monakhov wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > If prepare_write fails with AOP_TRUNCATED_PAGE, or if commit_write fails,
> > then
> > we may have failed the write operation despite prepare_write having
> > instantiated blocks past i_size. Fix this, and consolidate the trimming into
> > one place.
> >
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> >
> > Index: linux-2.6/mm/filemap.c
> > ===
> > --- linux-2.6.orig/mm/filemap.c
> > +++ linux-2.6/mm/filemap.c
> > @@ -1911,22 +1911,9 @@ generic_file_buffered_write(struct kiocb
> > }
> >
> > status = a_ops->prepare_write(file, page, offset, offset+bytes);
> > - if (unlikely(status)) {
> > - loff_t isize = i_size_read(inode);
> > + if (unlikely(status))
> > + goto fs_write_aop_error;
> May be it's stupid question but still..
> Why we treat non zero prepare_write() return code as error, it may be
> positive.
> Positive error code may be used as fine grained 'bytes' limiter in case of
> blksize < pgsize as follows:
>
> status = a_ops->prepare_write(file, page, offset,
> offset+bytes);
> if (unlikely(status)) {
> if (status > 0) {
> bytes = min(bytes, status);
> status = 0;
> } else {
> goto fs_write_aop_error;
> }
> }
> ---
> This is useful because fs may want to reduce 'bytes' by number of reasons,
> for example make it blksize bound.
> Example : filesystem has 1k blksize and only two free blocks. And we try
> write 4k bytes.
> Currently write(fd, buff, 4096) will return -ENOSPC
> But after this fix write(fd, buff, 4096) will return as mutch as it can
> (2048).
It isn't a stupid question. Hmm, while it isn't documented in vfs.txt, it
seems like some filesystems actually do this. AFFS, maybe JFFS. So good
catch, thanks.
-
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: mmc: correct semantics of the mmc_host_remove
> That shouldn't be possible. Are you using the block queue fixes I wrote? > Otherwise you will get problems like this. > > Basically, when you call mmc_host_remove(), it will remove all card > devices. That shouldn't complete until all card drivers have released > control of the card. At that point there is no one else accessing the > device. If you see something else, then we have a bug somewhere. > Indeed, I may be out of sync on this. Simply, I have this rather ugly hack in the tifm_sd remove code which I was forced to add because of the issue in question. I'll do some tests with newer kernels then. Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - 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: Choosing a HyperThreading/SMP/MultiCore kernel ?
On 1/13/07, Lennart Sorensen <[EMAIL PROTECTED]> wrote: On Fri, Jan 12, 2007 at 10:38:43PM -0500, [EMAIL PROTECTED] wrote: > amd64 will only work on a core2duo if it's a T7200 or higher - the > lower numbers are 32-bit-only chipsets. I admit not knowing what > exact variant the Mac has. 2.33GHz Intel Core 2 Duo - 4MB shared L2 cache with ATI Mobility Radeon X1600 with 256MB of GDDR3 SDRAM The Core Duo had 32bit only (being a Pentium M), but the Core 2 Duo should always be 64bit capable (at least that is what this list says: http://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors#Core_2_Duo_2 ) Thank's for that. Yep, it is 64-bit capable with EM64T & with Intel Vitualization. I do not know yet whether 2.6.19 or 2.6.20-rc5 supports and iSight Video Camera, ATI DDR3 support, Apple Mobile Remote Control, and some sensors like Motion, Light, Thermal, etc. (any suggestion where to look for linux support?). > CONFIG_MCORE2=y Got it, thanks -- Len Sorensen Should I wait for 2.6.20 release so that code would run with no oops or less problematic? Thanks, ~Akula2 - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
On 1/19/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Maybe, if you are talking about my advice to fix userspace... but you *are* going to contribute those changes back for the nommu community to use, right? So the end result of that is _not_ actually tweaking the end solutions. not quite sure what you're referring to here, but our approach is to contribute everything back in an acceptable form -mike - 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: Missing dmesg parameters in 2.6.19.2
Sunil Naidu wrote: Hello All, Atlast I have succeeded in booting 2.6.19.2 on mutiple x86 machines. I did observe a strange dmesg parameter behavior in this case:- 1) Compiling with SMP as Generic (CONFIG_X86_PC is not set, CONFIG_M686=y) Using x86 segment limits to approximate NX protection Using APIC driver default 2) Compiling with SMP as Processor specific (CONFIG_X86_PC=y, CONFIG_MPENTIUM4=y) I do not find the above mentioned parameters in this case. I don't think the "segment limits" message shows up in stock kernels, are you sure that was from 2.6.19.2? That sounds like a Fedora kernel with Exec Shield. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
On 1/20/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Aubrey Li wrote: > On 1/20/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote: >> If pagecache is overlimit, we expect old (cold) pagecache pages to >> be thrown out and reused for new file data. We do not expect to >> drop a few text or data pages to make room for new pagecache. >> > Well, actually I think this probably not necessary. Because the > reclaimer has no way to predict the behavior of user mode processes, > how do you make sure the pagecache will not be access again in a short It is not about predicting behaviour, it is about directing the reclaim effort at the actual resource that is under pressure. Even given a pagecache limiting patch which does the proper accounting to keep pagecache pages under a % limit (unlike yours), kicking off an undirected reclaim could (in theory) reclaim all slab and anonymous memory pages before bringing pagecache under the limit. So I think you need to be a bit more thorough than just assuming everything will be OK. Page reclaim behaviour is pretty strange and complex. So what's the right way to limit pagecache? Secondly, your patch isn't actually very good. It unconditionally shrinks memory to below the given % mark each time a pagecache alloc occurs, regardless of how much pagecache is in the system. Effectively that seems to just reduce the amount of memory available to the system. It doesn't reduce the amount of memory available to the system. It just reduce the amount of memory available to the page cache. So that page cache is limited and the reserved memory can be allocated by the application. Luckily, there are actually good, robust solutions for your higher order allocation problem. Do higher order allocations at boot time, modifiy userspace applications, or set up otherwise-unused, or easily reclaimable reserve pools for higher order allocations. I don't understand why you are so resistant to all of these approaches? I think we have explained the reason too much. We are working on no-mmu arch and provide a platform running linux to our customer. They are doing very good things like mplayer, asterisk, ip camera, etc on our platform, some applications was migrated from mmu arch. I think that means in some cases no-mmu arch is somewhat better than mmu arch. So we are taking effort to make the migration smooth or make no-mmu linux stronger. It's no way to let our customer modify their applications, we also unwilling to do it. And we have not an existing mechanism to set up a pools for the complex applications. So I'm trying to do some coding hack in the kernel to satisfy these kinds of requirement. And as you see, the patch seems to solve the problems on my side. But I'm not sure it's the right way to limit vfs cache, So I'm asking for comments and suggestions and help, I'm not asking to clobber the kernel. -Aubrey - 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: BUG: linux 2.6.19 unable to enable acpi
On 1/19/07, Len Brown <[EMAIL PROTECTED]> wrote: On Wednesday 17 January 2007 05:34, you wrote: > On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote: > > I just tried the firmwarekit, and here are the results, attached. > > TYVM, thats a very useful tool. > > I do suspect ACPI issues on my new DG965WH MOBO:- > > http://www.intel.com/products/motherboard/DG965WH/index.htm What acpi issues do you suspect? note that linux-acpi@vger.kernel.org may be able to help. cheers, -Len Thanks Len, am still investigating about this new MOBO. Shall post more info here. ~Akula2 - 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: Realtime-preemption for 2.6.20-rc5 ?
On 1/18/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: the best place to start is: http://rt.wiki.kernel.org Ingo I did refer the same. Is it necessary to use only base kernel, say 2.6.19? Or, can I go ahead with 2.6.19 + 2.6.19.2 patch + 2.6.19-rt patch? If yes, any reason why we need to apply rt patch only to a base kernel? Thanks, ~Akula2 - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
Mike Frysinger wrote: On 1/19/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Luckily, there are actually good, robust solutions for your higher order allocation problem. Do higher order allocations at boot time, modifiy userspace applications, or set up otherwise-unused, or easily reclaimable reserve pools for higher order allocations. I don't understand why you are so resistant to all of these approaches? in a nutshell ... the idea is to try and generalize these things your approach involves tweaking each end solution to maximize the performance Maybe, if you are talking about my advice to fix userspace... but you *are* going to contribute those changes back for the nommu community to use, right? So the end result of that is _not_ actually tweaking the end solutions. But actually, if you take the reserved pool approach, then that will work fine, in-kernel, and it is something that already needs to be done for dynamic hugepage allocations which is almost exactly the same situation. And everybody can use this as well (I think most of the code is written already, but not merged). our approach is to teach the kernel some more tricks so that each solution need not be tweaked these are at obvious odds as they tackle the problem by going in pretty much opposite directions ... yours leads to a tighter system in the end, but ours leads to much more rapid development and deployment OK that's fair enough, but considering that it doesn't actually fix the problem properly; and that it does weird and wonderful things with our already fragile page reclaim path, then it is not a good idea to merge it upstream. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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/
Missing dmesg parameters in 2.6.19.2
Hello All, Atlast I have succeeded in booting 2.6.19.2 on mutiple x86 machines. I did observe a strange dmesg parameter behavior in this case:- 1) Compiling with SMP as Generic (CONFIG_X86_PC is not set, CONFIG_M686=y) . . Using x86 segment limits to approximate NX protection . . Using APIC driver default . . 2) Compiling with SMP as Processor specific (CONFIG_X86_PC=y, CONFIG_MPENTIUM4=y) I do not find the above mentioned parameters in this case. I am trying to figure out what might have happened here? Any clues pl... Thanks, ~Akula2 - 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: SATA exceptions with 2.6.20-rc5
On Saturday 20 January 2007 02:41, Robert Hancock wrote: > By the way, I assume that you guys are using reiserfs or xfs, as it > appears no other file systems issue flush commands automatically. I had > to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am > using ext3. I'll give it a spin now, and yes I'm using several large XFS partitions on this machine, layered on top of md RAID5. That's why this particular defect is so catastrophic (literally _everything_ is stalled). -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: SATA exceptions with 2.6.20-rc5
Alistair John Strachan wrote:
On Tuesday 16 January 2007 01:53, Jeff Garzik wrote:
Robert Hancock wrote:
I'll try your stress test when I get a chance, but I doubt I'll run into
the same problem and I haven't seen any similar reports. Perhaps it's
some kind of wierd timing issue or incompatibility between the
controller and that drive when running in ADMA mode? I seem to remember
various reports of issues with certain Maxtor drives and some nForce
SATA controllers under Windows at least..
Just to eliminate things, has disabling ADMA been attempted?
It can be disabled using the sata_nv.adma module parameter.
Setting this option fixes the problem for me. I suggest that ADMA defaults off
in 2.6.20, if there's still time to do that.
Can you guys that are having this problem try the attached debug patch?
It's possible it will fix the problem, as I'm trying a private
exec_command implementation that flushes the write by reading a
controller register instead of reading altstatus from the drive like the
libata core code does.
If the problem still happens, I also added some more debugging in to
help figure out what is going on, so please post full dmesg.
By the way, I assume that you guys are using reiserfs or xfs, as it
appears no other file systems issue flush commands automatically. I had
to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am
using ext3.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
--- linux-2.6.20-rc5/drivers/ata/sata_nv.c 2007-01-19 19:18:53.0
-0600
+++ linux-2.6.20-rc5debug/drivers/ata/sata_nv.c 2007-01-19 20:25:31.0
-0600
@@ -245,6 +245,7 @@ static void nv_adma_bmdma_setup(struct a
static void nv_adma_bmdma_start(struct ata_queued_cmd *qc);
static void nv_adma_bmdma_stop(struct ata_queued_cmd *qc);
static u8 nv_adma_bmdma_status(struct ata_port *ap);
+static void nv_adma_exec_command(struct ata_port *ap, const struct
ata_taskfile *tf);
enum nv_host_type
{
@@ -409,7 +410,7 @@ static const struct ata_port_operations
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_atapi_dma= nv_adma_check_atapi_dma,
- .exec_command = ata_exec_command,
+ .exec_command = nv_adma_exec_command,
.check_status = ata_check_status,
.dev_select = ata_std_dev_select,
.bmdma_setup= nv_adma_bmdma_setup,
@@ -617,6 +618,14 @@ static int nv_adma_check_atapi_dma(struc
return !(pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE);
}
+static void nv_adma_exec_command(struct ata_port *ap, const struct
ata_taskfile *tf)
+{
+ void __iomem* mmio = nv_adma_ctl_block(ap);
+ writeb(tf->command, (void __iomem *) ap->ioaddr.command_addr);
+ readw(mmio + NV_ADMA_CTL); /* flush */
+ ndelay(400);
+}
+
static unsigned int nv_adma_tf_to_cpb(struct ata_taskfile *tf, __le16 *cpb)
{
unsigned int idx = 0;
@@ -701,6 +710,9 @@ static int nv_host_intr(struct ata_port
{
struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
int handled;
+ u8 cmd = 0;
+ if(qc)
+ cmd = qc->tf.command;
/* freeze if hotplugged */
if (unlikely(irq_stat & (NV_INT_ADDED | NV_INT_REMOVED))) {
@@ -709,8 +721,11 @@ static int nv_host_intr(struct ata_port
}
/* bail out if not our interrupt */
- if (!(irq_stat & NV_INT_DEV))
+ if (!(irq_stat & NV_INT_DEV)) {
+ if( cmd == ATA_CMD_FLUSH || cmd == ATA_CMD_FLUSH_EXT )
+ ata_port_printk(ap, KERN_NOTICE, "cmd 0x%x active but
stat 0x%x\n", cmd, irq_stat);
return 0;
+ }
/* DEV interrupt w/ no active qc? */
if (unlikely(!qc || (qc->tf.flags & ATA_TFLAG_POLLING))) {
@@ -720,6 +735,8 @@ static int nv_host_intr(struct ata_port
/* handle interrupt */
handled = ata_host_intr(ap, qc);
+ if( cmd == ATA_CMD_FLUSH || cmd == ATA_CMD_FLUSH_EXT )
+ ata_port_printk(ap, KERN_NOTICE, "cmd 0x%x active, stat = 0x%x,
handled = 0x%x\n", cmd, irq_stat, handled);
if (unlikely(!handled)) {
/* spurious, clear it */
ata_check_status(ap);
@@ -870,7 +887,7 @@ static void nv_adma_bmdma_setup(struct a
outb(dmactl, ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
/* issue r/w command */
- ata_exec_command(ap, >tf);
+ nv_adma_exec_command(ap, >tf);
}
static void nv_adma_bmdma_start(struct ata_queued_cmd *qc)
@@ -1161,6 +1178,9 @@ static unsigned int nv_adma_qc_issue(str
/* use ATA register mode */
VPRINTK("no dmamap or ATAPI, using ATA register mode: 0x%lx\n",
qc->flags);
nv_adma_register_mode(qc->ap);
+ if(qc->tf.command == ATA_CMD_FLUSH ||
+ qc->tf.command
Re: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
On 1/19/07, Nick Piggin <[EMAIL PROTECTED]> wrote: Luckily, there are actually good, robust solutions for your higher order allocation problem. Do higher order allocations at boot time, modifiy userspace applications, or set up otherwise-unused, or easily reclaimable reserve pools for higher order allocations. I don't understand why you are so resistant to all of these approaches? in a nutshell ... the idea is to try and generalize these things your approach involves tweaking each end solution to maximize the performance our approach is to teach the kernel some more tricks so that each solution need not be tweaked these are at obvious odds as they tackle the problem by going in pretty much opposite directions ... yours leads to a tighter system in the end, but ours leads to much more rapid development and deployment -mike - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
Aubrey Li wrote: On 1/20/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote: If pagecache is overlimit, we expect old (cold) pagecache pages to be thrown out and reused for new file data. We do not expect to drop a few text or data pages to make room for new pagecache. Well, actually I think this probably not necessary. Because the reclaimer has no way to predict the behavior of user mode processes, how do you make sure the pagecache will not be access again in a short It is not about predicting behaviour, it is about directing the reclaim effort at the actual resource that is under pressure. Even given a pagecache limiting patch which does the proper accounting to keep pagecache pages under a % limit (unlike yours), kicking off an undirected reclaim could (in theory) reclaim all slab and anonymous memory pages before bringing pagecache under the limit. So I think you need to be a bit more thorough than just assuming everything will be OK. Page reclaim behaviour is pretty strange and complex. Secondly, your patch isn't actually very good. It unconditionally shrinks memory to below the given % mark each time a pagecache alloc occurs, regardless of how much pagecache is in the system. Effectively that seems to just reduce the amount of memory available to the system. Luckily, there are actually good, robust solutions for your higher order allocation problem. Do higher order allocations at boot time, modifiy userspace applications, or set up otherwise-unused, or easily reclaimable reserve pools for higher order allocations. I don't understand why you are so resistant to all of these approaches? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
On 1/20/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote: Aubrey Li wrote: > On 1/19/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote: >> >> Hi Aubrey, >> >> The idea of creating separate flag for pagecache in page_alloc is >> interesting. The good part is that you flag watermark low and the >> zone reclaimer will do the rest of the job. >> >> However when the zone reclaimer starts to reclaim pages, it will >> remove all cold pages and not specifically pagecache pages. This >> may affect performance of applications. >> >> One possible solution to this reclaim is to use scan control fields >> and ask the shrink_page_list() and shrink_active_list() routines to >> target only pagecache pages. Pagecache pages are not mapped and >> they are easy to find on the LRU list. >> >> Please review my patch at http://lkml.org/lkml/2007/01/17/96 >> > > So you mean the existing reclaimer has the same issue, doesn't it? Well, the existing reclaimer will do the right job if the kernel really runs out of memory and need to recover pages for new allocations. The pages to be removed will be the coldest page in the system. However now with the introduction of pagecache limit, we are artificially creating a memory scarcity and forcing the reclaimer to throw away some pages while we actually have free usable RAM. In this context the choice of pages picked by the present reclaimer may not be the best ones. If pagecache is overlimit, we expect old (cold) pagecache pages to be thrown out and reused for new file data. We do not expect to drop a few text or data pages to make room for new pagecache. Well, actually I think this probably not necessary. Because the reclaimer has no way to predict the behavior of user mode processes, how do you make sure the pagecache will not be access again in a short time? So I think the present reclaimer is suitable. Limit pagecache must affect performance of applications. The key is what do you want to get? In my case, I get more memory to allocate, less fragmentation, it can solve my problem, :) Now the problem in the idea of the patch is, when vfs cache limit is hit, reclaimer doesn't reclaim all of the reclaimable pages, it just give few out. So next time vfs pagecache request, it is quite possible reclaimer is triggered again. That's the point in my mind affecting the performance of the applications. I'll continue to work on this issue to see if I can make a improvement. -Aubrey - 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: Threading...
On Fri, 19 Jan 2007 19:55:41 +0100, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Fri, 2007-01-19 at 10:43 -0800, Brian McGrew wrote: > > I have a very interesting question about something that we're seeing > > happening with threading between Fedora Core 3 and Fedora Core 5. Running > > on Dell PowerEdge 1800 Hardware with a Xeon processor with hyper-threading > > turned on. Both systems are using a 2.6.16.16 kernel (MVP al la special). > > > > We have a multithreaded application that starts two worker threads. On > > Fedora Core 3 both of these we use getpid() to get the PID of the thread and > > then use set_afinity to assign each thread to it's own CPU. Both threads > > run almost symmetrically even on their given CPU watching the system > > monitor. > > this is odd; even in FC3 getpid() is supposed to return the process ID > not the thread ID > > > What am I missing? What do I need to do in FC5 or the kernel or the > > threading library to get my threads to run in symmetric parallel again??? > One thing to try. In linux, pthread_setconcurrency never did nothing (it _really_ did in IRIX...). Can you try that ? Perhaps FC5 has implemented some kind of scheduling policy like that on irix (everything stays on the same CPU until it starts to suck cycles, unless you use setconcurrency). -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.19-jam04 (gcc 4.1.2 20061110 (prerelease) (4.1.2-0.20061110.2mdv2007.1)) #0 SMP PREEMPT - 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 2.6.20 0/2] ehca: fix yield and spinlock conflicts
Hello Roland! Here is patch set for ehca with the following bug fixes: * Fix unproper use of yield within spinlock context * Fix mismatched spin_unlock in irq handler Thanks Nam ehca_cq.c |5 - ehca_irq.c |2 +- 2 files changed, 5 insertions(+), 2 deletions(-) - 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 2.6.20 2/2] ehca: ehca_irq.c: fix mismatched spin_unlock in irq handler
Hello Roland!
This is a patch for ehca_irq.c that fixes an unproper use of spin_unlock
in irq handler.
Thanks
Nam
Signed-off-by Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---
ehca_irq.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c
b/drivers/infiniband/hw/ehca/ehca_irq.c
index e7209af..93788d8 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -440,7 +440,7 @@ void ehca_tasklet_eq(unsigned long data)
cq = idr_find(_cq_idr, token);
if (cq == NULL) {
- spin_unlock(_cq_idr_lock);
+
spin_unlock_irqrestore(_cq_idr_lock, flags);
break;
}
-
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 2.6.20 1/2] ehca: ehca_cq.c: fix unproper use of yield within spinlock context
Hello Roland!
This is a patch for ehca_cq.c that fixes unproper use of yield within
spinlock context.
Thanks
Nam
Signed-off-by Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---
ehca_cq.c |5 -
1 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c
b/drivers/infiniband/hw/ehca/ehca_cq.c
index 93995b6..6074c89 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -344,8 +344,11 @@ int ehca_destroy_cq(struct ib_cq *cq)
unsigned long flags;
spin_lock_irqsave(_cq_idr_lock, flags);
- while (my_cq->nr_callbacks)
+ while (my_cq->nr_callbacks) {
+ spin_unlock_irqrestore(_cq_idr_lock, flags);
yield();
+ spin_lock_irqsave(_cq_idr_lock, flags);
+ }
idr_remove(_cq_idr, my_cq->token);
spin_unlock_irqrestore(_cq_idr_lock, flags);
-
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: cyber2010 framebuffer on ARM Netwinder fix...
Just wondering, did the rtc change for the arm get sent up also? On Tue, 9 Jan 2007, Woody Suwalski wrote: Martin Michlmayr wrote: * Stuart Anderson <[EMAIL PROTECTED]> [2007-01-05 09:40]: shark w/o any changes to the kernel. I dug a bit further, both in the driver, and in the HW spec for the shark, and discovered that the video chip on the shark is connected via the VL bus, not the PCI bus. The shark does have a VL-PCI bridge, but there doesn't seem to be anything connected to the PCI side of it (which matches what lspci says). The function containing the patch in question doesn't appear to even run on the shark (there is a VL version that is #ifdef SHARK'd), so I'd have to say the patch would have not impact on the shark. OK, good news. Thanks for checking. Woody, can you submit the patch (with proper intentation) to [EMAIL PROTECTED] As suggested - I am sending this patch to fbdev-devel The Netwinder machines with Cyber2010 crash badly when starting Xserver. The workaround is to disable pci burst option for this revision of video chip. Thanks, Woody Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 - 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: problems with latest smbfs changes on 2.4.34 and security backports
On Thu, Jan 18, 2007 at 06:00:40PM -0700, dann frazier wrote:
> On Wed, Jan 17, 2007 at 10:55:19PM +0100, Willy Tarreau wrote:
> > @@ -505,8 +510,13 @@
> > mnt->file_mode = (oldmnt->file_mode & S_IRWXUGO) | S_IFREG;
> > mnt->dir_mode = (oldmnt->dir_mode & S_IRWXUGO) | S_IFDIR;
> >
> > - mnt->flags = (oldmnt->file_mode >> 9);
> > + mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
> > + SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
> > } else {
> > + mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > + S_IROTH | S_IXOTH | S_IFREG;
> > + mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
> > + S_IROTH | S_IXOTH | S_IFDIR;
> > if (parse_options(mnt, raw_data))
> > goto out_bad_option;
> > }
> >
> >
> > See above ? mnt->dir_mode being assigned 3 times. It still *seems* to do the
> > expected thing like this but I wonder if the initial intent was
> > exactly this.
>
> Wow - sorry about that, that's certainly a cut & paste error. But the
> end result appears to match current 2.6, which was the intent.
>
> > Also, would not it be necessary to add "|S_IFLNK" to the file_mode ? Maybe
> > what I say is stupid, but it's just a guess.
>
> I really don't know the correct answer to that, I was merely copying
> the 2.6 flags.
>
> [Still working on getting a 2.4 smbfs test system up...]
Ah, think I see the problem now:
--- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 17:53:57.247695476
-0700
+++ kernel-source-2.4.27/fs/smbfs/proc.c2007-01-19 17:49:07.480161733
-0700
@@ -1997,7 +1997,7 @@
fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG |
S_IRWXO)) | S_IFDIR;
else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
!(S_ISDIR(fattr->f_mode)) )
- fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG |
S_IRWXO)) | S_IFREG;
+ fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG |
S_IRWXO)) | (fattr->f_mode & S_IFMT);
}
Santiago: Thanks for reporting this - can you test this patch out on
your system and let me know if there are still any problems?
Willy: I'll do some more testing and get you a patch that fixes this
and the double assignment nonsense. Would you prefer a single patch or
two?
--
dann frazier
-
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 2.6.20-rc5] dm-multipath: fix stall on noflush suspend/resume
Allow noflush suspend/resume of device-mapper device only for
the case where the device size is unchanged.
Otherwise, dm-multipath devices can stall when resumed if noflush
was used when suspending them, all paths have failed and
queue_if_no_path is set.
Explanation:
1. Something is doing fsync() on the block dev,
holding inode->i_sem
2. The fsync write is blocked by all-paths-down and queue_if_no_path
3. Someone requests to suspend the dm device with noflush.
Pending writes are left in queue.
4. In the middle of dm_resume(), __bind() tries to get
inode->i_sem to do __set_size() and waits forever.
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
---
'noflush suspend' is a new device-mapper feature introduced in
early 2.6.20. So I hope the fix being included before 2.6.20 is
released.
Example of reproducer:
1. Create a multipath device by dmsetup
2. Fail all paths during mkfs
3. Do dmsetup suspend --noflush and load new map with healthy paths
4. Do dmsetup resume
drivers/md/dm.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
Index: linux-2.6.19/drivers/md/dm.c
===
--- linux-2.6.19.orig/drivers/md/dm.c 2006-12-12 22:02:29.0 +
+++ linux-2.6.19/drivers/md/dm.c 2007-01-05 15:15:53.0 +
@@ -1116,7 +1116,8 @@ static int __bind(struct mapped_device *
if (size != get_capacity(md->disk))
memset(>geometry, 0, sizeof(md->geometry));
- __set_size(md, size);
+ if (md->suspended_bdev)
+ __set_size(md, size);
if (size == 0)
return 0;
@@ -1265,6 +1266,11 @@ int dm_swap_table(struct mapped_device *
if (!dm_suspended(md))
goto out;
+ /* without bdev, the device size cannot be changed */
+ if (!md->suspended_bdev)
+ if (get_capacity(md->disk) != dm_table_get_size(table))
+ goto out;
+
__unbind(md);
r = __bind(md, table);
@@ -1342,11 +1348,14 @@ int dm_suspend(struct mapped_device *md,
/* This does not get reverted if there's an error later. */
dm_table_presuspend_targets(map);
- md->suspended_bdev = bdget_disk(md->disk, 0);
- if (!md->suspended_bdev) {
- DMWARN("bdget failed in dm_suspend");
- r = -ENOMEM;
- goto flush_and_out;
+ /* bdget() can stall if the pending I/Os are not flushed */
+ if (!noflush) {
+ md->suspended_bdev = bdget_disk(md->disk, 0);
+ if (!md->suspended_bdev) {
+ DMWARN("bdget failed in dm_suspend");
+ r = -ENOMEM;
+ goto flush_and_out;
+ }
}
/*
@@ -1474,8 +1483,10 @@ int dm_resume(struct mapped_device *md)
unlock_fs(md);
- bdput(md->suspended_bdev);
- md->suspended_bdev = NULL;
+ if (md->suspended_bdev) {
+ bdput(md->suspended_bdev);
+ md->suspended_bdev = NULL;
+ }
clear_bit(DMF_SUSPENDED, >flags);
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), I thought that's what I was doing when I applied git-e1000 to 2.6.20-rc5, but I guess not. or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. I'll try to work something out. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. ethtool output attached. that clearly shows that the PHY detected link up status and that all is well as far as the driver and NIC is concerned. This bug really needs to be moved to linux-pci where the folks who know interrupt handling best can handle it. Auke - 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] sysctl.h: Comment out unused constants
Comment out unused constants in include/linux/sysctl.h.
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with allyes and allmod under i386.
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 81480e6..c8d2cb7 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -91,10 +91,10 @@ enum
{
KERN_OSTYPE=1, /* string: system version */
KERN_OSRELEASE=2, /* string: system release */
- KERN_OSREV=3, /* int: system revision */
+/* KERN_OSREV=3,*/ /* int: system revision */
KERN_VERSION=4, /* string: compile time info */
- KERN_SECUREMASK=5, /* struct: maximum rights mask */
- KERN_PROF=6,/* table: profiling information */
+/* KERN_SECUREMASK=5,*//* struct: maximum rights mask */
+/* KERN_PROF=6,*/ /* table: profiling information */
KERN_NODENAME=7,
KERN_DOMAINNAME=8,
@@ -105,22 +105,22 @@ enum
KERN_SPARC_REBOOT=21, /* reboot command on Sparc */
KERN_CTLALTDEL=22, /* int: allow ctl-alt-del to reboot */
KERN_PRINTK=23, /* struct: control printk logging parameters */
- KERN_NAMETRANS=24, /* Name translation */
- KERN_PPC_HTABRECLAIM=25, /* turn htab reclaimation on/off on PPC */
- KERN_PPC_ZEROPAGED=26, /* turn idle page zeroing on/off on PPC */
+/* KERN_NAMETRANS=24,*//* Name translation */
+/* KERN_PPC_HTABRECLAIM=25,*/ /* turn htab reclaimation on/off on PPC */
+/* KERN_PPC_ZEROPAGED=26,*/ /* turn idle page zeroing on/off on PPC */
KERN_PPC_POWERSAVE_NAP=27, /* use nap mode for power saving */
KERN_MODPROBE=28,
KERN_SG_BIG_BUFF=29,
KERN_ACCT=30, /* BSD process accounting parameters */
KERN_PPC_L2CR=31, /* l2cr register on PPC */
- KERN_RTSIGNR=32,/* Number of rt sigs queued */
- KERN_RTSIGMAX=33, /* Max queuable */
+/* KERN_RTSIGNR=32,*/ /* Number of rt sigs queued */
+/* KERN_RTSIGMAX=33,*/ /* Max queuable */
KERN_SHMMAX=34, /* long: Maximum shared memory segment */
KERN_MSGMAX=35, /* int: Maximum size of a messege */
KERN_MSGMNB=36, /* int: Maximum message queue size */
- KERN_MSGPOOL=37,/* int: Maximum system message pool size */
+/* KERN_MSGPOOL=37,*/ /* int: Maximum system message pool size */
KERN_SYSRQ=38, /* int: Sysreq enable */
KERN_MAX_THREADS=39,/* int: Maximum nr of threads in the system */
KERN_RANDOM=40, /* Random driver */
@@ -131,7 +131,7 @@ enum
KERN_SHMMNI=45, /* int: shm array identifiers */
KERN_OVERFLOWUID=46,/* int: overflow UID */
KERN_OVERFLOWGID=47,/* int: overflow GID */
- KERN_SHMPATH=48,/* string: path to shm fs */
+/* KERN_SHMPATH=48,*/ /* string: path to shm fs */
KERN_HOTPLUG=49,/* string: path to uevent helper (deprecated) */
KERN_IEEE_EMULATION_WARNINGS=50, /* int: unimplemented ieee
instructions */
KERN_S390_USER_DEBUG_LOGGING=51, /* int: dumps of user faults */
@@ -167,15 +167,15 @@ enum
/* CTL_VM names: */
enum
{
- VM_UNUSED1=1, /* was: struct: Set vm swapping control */
- VM_UNUSED2=2, /* was; int: Linear or sqrt() swapout for hogs
*/
- VM_UNUSED3=3, /* was: struct: Set free page thresholds */
- VM_UNUSED4=4, /* Spare */
+/* VM_UNUSED1=1,*/ /* was: struct: Set vm swapping control */
+/* VM_UNUSED2=2,*/ /* was; int: Linear or sqrt() swapout for hogs
*/
+/* VM_UNUSED3=3,*/ /* was: struct: Set free page thresholds */
+/* VM_UNUSED4=4,*/ /* Spare */
VM_OVERCOMMIT_MEMORY=5, /* Turn off the virtual memory safety limit */
- VM_UNUSED5=6, /* was: struct: Set buffer memory thresholds */
- VM_UNUSED7=7, /* was: struct: Set cache memory thresholds */
- VM_UNUSED8=8, /* was: struct: Control kswapd behaviour */
- VM_UNUSED9=9, /* was: struct: Set page table cache parameters
*/
+/* VM_UNUSED5=6,*/ /* was: struct: Set buffer memory thresholds */
+/* VM_UNUSED7=7,*/ /* was: struct: Set cache memory thresholds */
+/* VM_UNUSED8=8,*/ /* was: struct: Control kswapd behaviour */
+/* VM_UNUSED9=9,*/ /* was: struct: Set page table cache parameters
*/
VM_PAGE_CLUSTER=10, /* int: set number of pages to swap together */
VM_DIRTY_BACKGROUND=11, /* dirty_background_ratio */
VM_DIRTY_RATIO=12, /* dirty_ratio */
@@ -183,7 +183,7 @@ enum
VM_DIRTY_EXPIRE_CS=14, /* dirty_expire_centisecs */
VM_NR_PDFLUSH_THREADS=15, /* nr_pdflush_threads */
VM_OVERCOMMIT_RATIO=16, /* percent of RAM to allow overcommit in */
- VM_PAGEBUF=17,
Re: [PATCHSET] Managed device resources, take #2
Tejun, Please 1) Collapse patches 1-7 into a single patch, and 2) rediff against latest libata-dev.git#upstream and I will apply straightaway. Jeff - 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 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Auke Kok wrote: Adam Kropelin wrote: I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), I thought that's what I was doing when I applied git-e1000 to 2.6.20-rc5, but I guess not. or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. I'll try to work something out. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. ethtool output attached. More importantly, I suspect that *again* the issue is caused by interrupts not arriving or getting lost. Smells that way to me, too. Can you try running with MSI disabled in your kernel config? That fixes it! The link comes up and tx/rx works well. I get about 300 Mbps using default iperf settings with a nearby windows box. FYI the driver gives an interrupt to signal to the driver that link is up. no interrupt == no link detected. So that explains the symptom. Yep, makes sense. I've worked with a number of PHYs like that. --Adam ethtool-eth1 Description: Binary data ethtool-d-eth1 Description: Binary data
Re: [PATCH] sata_mv HighPoint 2310 support (88SX7042)
Olof Johansson wrote: Hi, With the following patch, my HighPoint 2310 with a Marvell 88SX7042 on it seems to work OK. The controller only has 4 ports, with MV_FLAG_DUAL_HC it seems to init 8 ports and fails miserably at probe time. There are no other devices mapped to that chip, maybe it was just incorrectly specified in the first place? Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> The docs say 8-port. Nonetheless, I will apply your patch, since working-in-the-field proof trumps docs on occasion (including this occasion). We'll revisit if someone complains that their 7042 only sees 4 of 8 ports. Jeff - 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] libata: PIIX3 support
Alan wrote: This I believe completes the PIIX range of support for libata This adds the table entries needed for the PIIX3, both a new PCI identifier and a new mode list. It also fixes an erroneous access to PCI configuration 0x48 on non UDMA capable chips. Signed-off-by: Alan Cox <[EMAIL PROTECTED]> applied. Please submit clean, warning-free C code in the future, rather than relying on Andrew to clean up after you. Jeff - 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.20-rc4] sata_promise: ATAPI cleanup
Mikael Pettersson wrote: Here's a cleanup for yesterday's sata_promise ATAPI patch: - add and use a symbolic constant for the altstatus register - check return status from ata_busy_wait() - add missing newline in a warning printk() - update comment in pdc_issue_atapi_pkt_cmd() to clarify that the maybe-wait-for-INT issue cannot occur in the current driver, but may occur if the driver starts issuing ATAPI non-DMA commands as PDC packets Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]> applied - 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: USB extension (repeater) cable
On Fri, Jan 19, 2007 at 04:40:34PM +0100, Udo van den Heuvel wrote: > Hello, > > I just tried my shiny new usb extension cable (repeater): > > Jan 19 16:01:17 epia kernel: usb 5-1: new high speed USB device using > ehci_hcd and address 60 > Jan 19 16:01:17 epia kernel: usb 5-1: configuration #1 chosen from 1 choice > Jan 19 16:01:17 epia kernel: hub 5-1:1.0: USB hub found > Jan 19 16:01:17 epia kernel: hub 5-1:1.0: 4 ports detected > Jan 19 16:01:18 epia kernel: hub 5-1:1.0: Cannot enable port 1. Maybe > the USB cable is bad? > Jan 19 16:01:22 epia last message repeated 3 times > Jan 19 16:01:23 epia kernel: hub 5-1:1.0: Cannot enable port 2. Maybe > the USB cable is bad? > Jan 19 16:01:26 epia last message repeated 3 times > Jan 19 16:01:27 epia kernel: hub 5-1:1.0: Cannot enable port 3. Maybe > the USB cable is bad? > Jan 19 16:01:31 epia last message repeated 3 times > > The second cable does the same. > Of course we have just one port on this hub... > Any ideas? Perhaps the kernel is not lying and this cable really is bad? :) Your hardware can not handle this device, there really is nothing that the kernel can do about this. USB extension cables are horrible things, and usually violate the USB spec and do not always work, as you are finding out. Sorry about that. good luck, greg k-h - 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 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On 2.6.19 the link status is working (follows cable plug/unplug), but no tx or rx packets get thru. Attempts to transmit occasionally result in tx timed out errors in dmesg, but I cannot seem to generate these at will. On 2.6.20-rc5, the link status does not work (link is always down), and as expected no tx or rx. No tx timed out errors this time, presumably because it thinks the link is down. Note that both the switch and the LEDs on the NIC indicate a good 1000 Mbps link. dmesg, 'cat /proc/interrupts', and 'lspci -vvv' attached for 2.6.20-rc5. The data from 2.6.19 is essentially the same. at least your interrupts look sane. I see you are using MSI, but no interrupts arrive at neither OS nor driver. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. More importantly, I suspect that *again* the issue is caused by interrupts not arriving or getting lost. Can you try running with MSI disabled in your kernel config? FYI the driver gives an interrupt to signal to the driver that link is up. no interrupt == no link detected. So that explains the symptom. Auke - 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: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Hello On Friday 19 January 2007 20:58, Zan Lynx wrote: > I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 > and rc4-mm1 have been giving me these freezes. They were happening > inside X and without external console it was impossible to get anything, > plus I was reluctant to test it since the freeze sometimes requires a > full fsck.reiser4 --build-fs to recover the filesystem. > > But I finally got some output in a console session. I wasn't able to > get it all, I made some notes of what I think the problem is. I may try > again later once I get netconsole working (netconsole fails as a > built-in, I'll try it as a module next). > > 1 lock held by pdflush/185: > #0: (>s_umount_key#15) ... writeback_inodes+0x89 > > 3 locks held by realsync/12942: > #0: (>s_umount_key#15) at ... __sync_inodes+0x78 > #1: (>commit_mutex) ... reiser4_txn_end+0x37a > #2: (>mutex) ... synchronize_qrcu+0x19 > > So, I *think* the problem is two locks on s_umount_key#15. Does that > sound likely? I also noticed QRCU may be involved. > > Perhaps someone will look at this and instantly know what the problem > is. > > If not, I'll be following up with more details like .config and perhaps > a full sysrq-T dump as soon as that fsck finishes. > yes, please provide more information. Full kernel output at time of freeze is very desirable. - 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 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Auke Kok wrote: Adam Kropelin wrote: I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On 2.6.19 the link status is working (follows cable plug/unplug), but no tx or rx packets get thru. Attempts to transmit occasionally result in tx timed out errors in dmesg, but I cannot seem to generate these at will. On 2.6.20-rc5, the link status does not work (link is always down), and as expected no tx or rx. No tx timed out errors this time, presumably because it thinks the link is down. Note that both the switch and the LEDs on the NIC indicate a good 1000 Mbps link. dmesg, 'cat /proc/interrupts', and 'lspci -vvv' attached for 2.6.20-rc5. The data from 2.6.19 is essentially the same. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. --Adam dmesg-2.6.20-rc5 Description: Binary data lspci-2.6.20-rc5 Description: Binary data proc-irq-2.6.20-rc5 Description: Binary data
Re: BUG: linux 2.6.19 unable to enable acpi
On 1/19/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
On 1/19/07, Len Brown <[EMAIL PROTECTED]> wrote:
> I guess I'm losing my mind, because when I read this code,
> there are only two ways out of the while(retry) loop.
> Either return with success, or retry is 0.
> So how the heck is retry printed as 142?!
>
> did you notice any delay between the last two lines of printout above?
>
> please boot with "acpi_dbg_layer=2" "acpi_dbg_level=0x"
> so that we can see each read and write of the hardware look like.
> Success is measured here by looking for SCI_EN being set
> to indicate that we successfully entered ACPI mode.
>
> I guess we should see about 142 reads looking for SCI_EN...
>
> It would be interesting if you could boot a windows disk on this box
> to see if they are able to get into ACPI mode. You'd be able to
> tell by dumping the interrupt list, looking at the device tree,
> or observing if the power button gives immediate poweroff
> or does an OS shutdown.
>
> thanks,
> -Len
printk("ACPI: retry %d\n") -> printk("ACPI: retry %d\n", retry)
;)
ill try this again soon.
Ok, here is what i got:
hwacpi-0207 [C031D380] [04] hw_get_mode : Entry
hwregs-0273 [C031D380] [05] get_register : Entry
hwregs-0487 [C031D380] [06] hw_register_read : Entry
hwregs-0810 [C031D380] [06] hw_low_level_read : Read:
width 16 from 0404 (SystemIO)
hwregs-0575 [C031D380] [06] hw_register_read : Exit- AE_OK
hwregs-0300 [C031D380] [05] get_register : Read value
register 3
hwregs-0303 [C031D380] [05] get_register : Exit- AE_OK
hwacpi-0226 [C031D380] [04] hw_get_mode : Exit- 0002
ACPI: retry 0
ACPI Error (hwacpi-0185): Hardware did not change modes [20060707]
hwacpi-0186 [C031D380] [03] hw_set_mode : Exit-
Exception: AE_NO_HARDWARE_RESPONSE
ACPI Error (evxfevnt-0084): Could not transition to ACPI mode [20060707]
ACPI Warning (utxface-0154): AcpiEnable failed [20060707]
ACPI: Unable to enable ACPI
-
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: Possible ways of dealing with OOM conditions.
On Fri, Jan 19, 2007 at 01:53:15PM +0100, Peter Zijlstra ([EMAIL PROTECTED]) wrote: > > 2. You differentiate by hand between critical and non-critical > > allocations by specifying some kernel users as potentially possible to > > allocate from reserve. > > True, all sockets that are needed for swap, no-one else. > > > This does not prevent from NVIDIA module to > > allocate from that reserve too, does it? > > All users of the NVidiot crap deserve all the pain they get. > If it breaks they get to keep both pieces. I meant that pretty anyone can be those user, who can just add a bit into own gfp_flags which are used for allocation. > > And you artificially limit > > system to process only tiny bits of what it must do, thus potentially > > leaking pathes which must use reserve too. > > How so? I cover pretty much every allocation needed to process an skb by > setting PF_MEMALLOC - the only drawback there is that the reserve might > not actually be large enough because it covers more allocations that > were considered. (thats one of the TODO items, validate the reserve > functions parameters) You only covered ipv4/v6 and arp, maybe some route updates. But it is very possible, that some allocations are missed like multicast/broadcast. Selecting only special pathes out of the whole possible network alocations tends to create a situation, when something is missed or cross dependant on other pathes. > > So, solution is to have a reserve in advance, and manage it using > > special path when system is in OOM. So you will have network memory > > reserve, which will be used when system is in trouble. It is very > > similar to what you had. > > > > But the whole reserve can never be used at all, so it should be used, > > but not by those who can create OOM condition, thus it should be > > exported to, for example, network only, and when system is in trouble, > > network would be still functional (although only critical pathes). > > But the network can create OOM conditions for itself just fine. > > Consider the remote storage disappearing for a while (it got rebooted, > someone tripped over the wire etc..). Now the rest of the network > traffic keeps coming and will queue up - because user-space is stalled, > waiting for more memory - and we run out of memory. Hmm... Neither UDP, nor TCP work that way actually. > There must be a point where we start dropping packets that are not > critical to the survival of the machine. You still can drop them, the main point is that network allocations do not depend on other allocations. > > Even further development of such idea is to prevent such OOM condition > > at all - by starting swapping early (but wisely) and reduce memory > > usage. > > These just postpone execution but will not avoid it. No. If system allows to have such a condition, then something is broken. It must be prevented, instead of creating special hacks to recover from it. -- Evgeniy Polyakov - 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: Probably wrong place to ask
On Friday 19 January 2007 16:22, Bill Davidsen wrote: >Gene Heskett wrote: >> Greetings all; >> >> I have a card reader plugged into a usb port. I recognizes a 512meg >> pny cf card just fine, but wwhen I plug in a 256meg Lexar cf, the led >> comes on, but there is no reaction from linux. /dev/sda is not >> created, nothing. >> >> Is this a kernel config problem, or is this particular cf known to be >> a bad bird? > >I do that with CF and memory stick, what kernel, distribution, etc? I >would suspect something in hotplug not noticing. > >I presume you have tried this from cold boot, so any issues with >unplugging and plugging another flash are removed. No I didn't try that. See the other ignore me message for the answer. Thanks Bill. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - 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: Probably wrong place to ask
On Friday 19 January 2007 14:57, Gene Heskett wrote: >Greetings all; > >I have a card reader plugged into a usb port. I recognizes a 512meg pny >cf card just fine, but wwhen I plug in a 256meg Lexar cf, the led comes >on, but there is no reaction from linux. /dev/sda is not created, >nothing. > >Is this a kernel config problem, or is this particular cf known to be a >bad bird? Ignore me, I opened the second one I'd bought at the same time and it worked as expected. Bad card in the blisterpack. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - 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] Documentation/rbtree.txt
On Thu, 18 Jan 2007 15:33:25 -0500 Rob Landley wrote:
> Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
>
> Documentation for lib/rbtree.c.
>
> --
>
> I'm not an expert on this but I was asked to write up some documentation
> for rbtree in the Linux kernel, and as long as it's there...
>
> I'm sure if I screwed something up somebody will point it out to me, loudly.
> :)
Hi,
Looks pretty good to me. I have a few minor nits (below).
> --- /dev/null 2006-05-30 21:33:22.0 -0400
> +++ linux-2.6.19.2/Documentation/rbtree.txt 2007-01-18 11:57:50.0
> -0500
> @@ -0,0 +1,186 @@
> +Red-black Trees (rbtree) in Linux
> +January 18, 2007
> +Rob Landley <[EMAIL PROTECTED]>
> +=
> +
> +What are red-black trees, and what are they for?
> +
> +
> +Red-black trees are a type of self-balancing binary search tree, used for
> +storing sortable key/value data pairs. This differs from radix trees (which
> +are used to efficiently store sparse arrays and thus use long integer indexes
> +to insert/access/delete nodes) and hash tables (which are not kept sorted to
> +be easily traversed in order, and must be tuned for a specific size and
> +hash function where rbtrees scale gracefully storing arbitrary keys).
> +
> +Red-black trees are similar to AVL trees, but provide faster realtime bounded
real-time
> +worst case performance for insertion and deletion (at most two rotations and
> +three rotations, respectively, to balance the tree), with slightly slower
> +(but still O(log n)) lookup time.
> +
> +To quote Linux Weekly News:
> +
...
> +
> +This document covers use of the Linux rbtree implementation. For more
> +information on the nature and implementation of Red Black Trees, see:
> +
...
> +
> +Linux implementation of red-black trees
> +---
> +
> +Linux's rbtree implementation lives in the file "lib/rbtree.c". To use it,
> +"#include ".
> +
> +The Linux rbtree implementation is optimized for speed, and thus has one
> +less layer of indirection (and better cache locality) than more traditional
> +tree implementations. Instead of using pointers to separate rb_node and data
> +structures, each instance of struct rb_node is embedded in the data structure
> +it organizes. And instead of using a comparison callback function pointer,
> +users are expected to write their own tree search and insert functions
> +which call the provided rbtree functions. Locking is also left up to the
> +user of the rbtree code.
> +
> +Creating a new rbtree
> +-
> +
> +Data nodes in an rbtree tree are structures containing a struct rb_node
> member:
> +
> + struct mytype {
> + struct rb_node node;
> + char *keystring;
> + };
> +
> +When dealing with a pointer to the embedded struct rb_node, the containing
> data
> +structure may be accessed with the standard container_of() macro. In
> addition,
> +individual members may be accessed directly via rb_entry(node, type, member).
> +
> +At the root of each rbtree is a rb_root structure, which is initialized to be
> +empty via:
an rb_root
> +
> + struct rb_root mytree = RB_ROOT;
> +
> +Searching for a value in an rbtree
> +--
> +
> +Writing a search function for your tree is fairly straightforward: start at
> the
> +root, compare each value, and follow the left or right branch as necessary.
> +
> +Example:
> +
> + struct mytype *my_search(struct rb_root *root, char *string)
> + {
> + struct rb_node *node = root->rb_node;
> +
> + while (node) {
> + struct mytype *data = container_of(node, struct mytype, node);
> + int result;
> +
> + result = strcmp(string, data->keystring);
> +
> + if (result < 0) node = node->rb_left;
> + else if (result > 0) node = node->rb_right;
> + else return data;
> + }
> + return NULL;
> + }
> +
> +Inserting data into an rbtree
> +-
> +
> +Inserting data in the tree involves first searching for the place to insert
> the
> +new node, then inserting the node and rebalancing ("recoloring") the tree.
> +
> +The search for insertion differs from the previous search by finding the
> +location of the pointer on which to graft the new node. The new node also
> +needs a link to its' parent node for rebalancing purposes.
its
> +
> +Example:
> +
> + int my_insert(struct rb_root *root, struct mytype *data)
> + {
> + struct rb_node **new = &(root->rb_node), *parent = NULL;
> +
> + // Figure out where to put new node
> + while (*new) {
> + struct mytype *this = container_of(*new, struct mytype, node);
> + int result = strcmp(data->keystring, this->keystring);
> +
> + parent = *new;
> + if (result < 0) new = &((*new)->rb_left);
> + else if
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On 1/19/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: On Jan 19 2007 11:45, Scott Preece wrote: > Hi, attached is a patch for your gentable file, rewriting some of the > user prompts to make them more readable. I still don't get why this is called "SIN" in the Kconfig and code texts though the acronym for System Inactivity Monitor would be "SIM". --- The code calls it "System Inactivity Notifier". scott - 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] include linux/fs.h in linux/cdev.h for struct inode
>Subject: [PATCH] include linux/fs.h in linux/cdev.h for struct inode
NAK.
Better is this:
Add missing struct predeclarations, otherwise we may get
x.c:2: warning: ‘struct inode’ declared inside parameter list
x.c:2: warning: its scope is only this definition or declaration, which is
probably not what you want
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc5/include/linux/cdev.h
===
--- linux-2.6.20-rc5.orig/include/linux/cdev.h
+++ linux-2.6.20-rc5/include/linux/cdev.h
@@ -6,6 +6,10 @@
#include
#include
+struct file_operations;
+struct inode;
+struct module;
+
struct cdev {
struct kobject kobj;
struct module *owner;
Re: [ANNOUNCE] System Inactivity Monitor v1.0
On Jan 19 2007 11:45, Scott Preece wrote: > Hi, attached is a patch for your gentable file, rewriting some of the > user prompts to make them more readable. I still don't get why this is called "SIN" in the Kconfig and code texts though the acronym for System Inactivity Monitor would be "SIM". -`J' -- - 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: unable to mmap /dev/kmem
> But personally I'd prefer it to remain. Similar. I also got some tools who use it to read kernel variables and doing the V->P conversion in user space would be tedious and unreliable (e.g. for vmalloc) -Andi - 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 8/15] ide: disable DMA in ->ide_dma_check for "no IORDY" case
Sergei Shtylyov wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > [PATCH] ide: disable DMA in ->ide_dma_check for "no IORDY" case > >>> I've looked thru the code, and found more issues with the PIO fallback >>> there. Will try to cook up patches for at least some drivers... > >> Great, if possible please base them on top of the IDE tree... > >Erm, I had doubts about it (having in mind that all that code is more of a > cleanups than fixes). Maybe it'd be a good idea to separate the fix and > cleanup series somehow... I generally tend do cleanups as a groundwork for the real fixes and separate cleanups and fixes to have good base for dealing with regressions. Often all changes (cleanups/fixes) could be included in one patch but then I would have had harsh times when debugging the regressions. It matters a lot if you hit an unknown (or known but the documentation is covered by NDA) hardware bug - you can concentrate on a small patch changing the way in which hardware is accessed instead of that big patch moving code around etc. Also the thing is that the same bugs are propagated over many drivers so doing cleanups which merge code before fixing the bug makes sense. We can then fix the damn bug once and for all and not worry about somebody copy-n-pasting the bug from the yet-to-be-fixed driver (i.e. in the next patch IDE update there will be patch to check return value of ->speedproc in ide_tune_dma(), without ide-fix-dma-mask/ide-max-dma-mode/ide-tune-dma-helper patches I would have to go over all drivers to fix this bug and still there won't be a guarantee that same bug wouldn't be introduced in some new driver). The other advantage of doing cleanups is that code becomes cleaner/simpler which matters a lot for this codebase, i.e. ide-dma-off-void.patch exposed (yet to be fixed) bug in set_using_dma() (->ide_dma_off_quietly always returns 0 which is passed by ->ide_dma_check to set_using_dma() which incorrectly then calls ->ide_dma_on). Moreover I don't find the current tree to be more of cleanups than fixes, here is the analysis of current series file: # # -pata extraversion # pata-extraversion.patch -- n/a # # IDE patches from 2.6.20-rc3-mm1 # toshiba-tc86c001-ide-driver-take-2.patch toshiba-tc86c001-ide-driver-take-2-fix.patch toshiba-tc86c001-ide-driver-take-2-fix-2.patch -- new driver hpt3xx-rework-rate-filtering.patch hpt3xx-rework-rate-filtering-tidy.patch hpt3xx-print-the-real-chip-name-at-startup.patch hpt3xx-switch-to-using-pci_get_slot.patch hpt3xx-cache-channels-mcr-address.patch hpt3x7-merge-speedproc-handlers.patch hpt370-clean-up-dma-timeout-handling.patch hpt3xx-init-code-rewrite.patch piix-fix-82371mx-enablebits.patch piix-tuneproc-fixes-cleanups.patch slc90e66-carry-over-fixes-from-piix-driver.patch hpt36x-pci-clock-detection-fix.patch jmicron-warning-fix.patch -- fixes (but most have cleanups mixed in) pdc202xx_new-remove-useless-code.patch pdc202xx_-remove-check_in_drive_lists-abomination.patch -- cleanups # # IDE patches applied by Andrew (2.6.20-rc4-mm1) # atiixpc-remove-unused-code.patch -- cleanup atiixpc-sb600-ide-only-has-one-channel.patch atiixpc-add-cable-detection-support-for-ati-ide.patch ide-generic-jmicron-has-its-own-drivers-now.patch -- fixes ide-maintainers-entry.patch -- n/a # # IT8213 # it8213-ide-driver.patch it8213-ide-driver-update.patch -- new driver # # patches posted on Jan 11 2007 # ia64-pci_get_legacy_ide_irq.patch ide-pci-init-tags.patch -- fixes pdc202xx_old-dead-code.patch au1xxx-dead-code.patch ide-pio-blacklisted.patch ide-no-dsc-flag.patch trm290-dma-ifdefs.patch ide-pci-device-tables.patch ide-dev-openers.patch hpt366-init-dma.patch cs5530-cleanup.patch svwks-cleanup.patch sis5513-config-xfer-rate.patch ide-set-xfer-rate.patch ide-use-fast-pio-v2.patch ide-io-cleanup.patch -- cleanups # # Delkin CardBus CF driver (Mark Lord <[EMAIL PROTECTED]>) # delkin_cb-ide-driver.patch -- new driver # # IDE ACPI support (Hannes Reinecke <[EMAIL PROTECTED]>) # ide-acpi-support.patch -- new functionality (fixes PM on some machines) # # ide-pnp exit fix (Tejun Heo <[EMAIL PROTECTED]>) # ide-pnp-exit-fix.patch -- fix # # VIA IDE update (Josepch Chan <[EMAIL PROTECTED]>) # via-ide-update.patch -- fix # # patches posted on 18 Jan 2007 # it8213-ide-driver-update-fixes.patch -- fix ide-mmio-flag.patch -- cleanup hpt34x-tune-chipset-fix.patch -- fix ide-fix-pio-fallback.patch -- fix piix-cleanup.patch -- cleanup ide-dma-check-disable-dma-fix.patch sgiioc4-ide-dma-check-fix.patch -- fixes ide-set-dma-helper.patch ide-dma-off-void.patch ide-dma-host-on-void.patch ide-fix-dma-masks.patch ide-max-dma-mode.patch ide-tune-dma-helper.patch -- cleanups So it looks more like 50-50 with majority of fixes coming from you :) However I understand that for some applications (stable distro etc)
Re: [patch] optimize o_direct on block device - v3
> On Fri, 19 Jan 2007 12:14:05 -0600 Michael Reed <[EMAIL PROTECTED]> wrote: > Thanks again for finding the fix to the problem I reported. > Can you tell me when I might expect this fix to show up in > 2.6.20-rc? next week.. - 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: Threading...
Brian McGrew wrote: On 1/19/07 10:55 AM, "Arjan van de Ven" <[EMAIL PROTECTED]> wrote: On Fri, 2007-01-19 at 10:43 -0800, Brian McGrew wrote: I have a very interesting question about something that we're seeing happening with threading between Fedora Core 3 and Fedora Core 5. Running on Dell PowerEdge 1800 Hardware with a Xeon processor with hyper-threading turned on. Both systems are using a 2.6.16.16 kernel (MVP al la special). We have a multithreaded application that starts two worker threads. On Fedora Core 3 both of these we use getpid() to get the PID of the thread and then use set_afinity to assign each thread to it's own CPU. Both threads run almost symmetrically even on their given CPU watching the system monitor. this is odd; even in FC3 getpid() is supposed to return the process ID not the thread ID What am I missing? What do I need to do in FC5 or the kernel or the threading library to get my threads to run in symmetric parallel again??? you should fix the app to use something like pthread_self() instead... (or the highly unportable gettid() but that would just be horrible) - And on FC5 I am using pthread_self but my problem isn't simply with pthread_self, it's with the scheduling. On FC3 both threads run simultaneously in almost symmetric parallel. On FC5 one thread don't pick up and start until the previous one is done. On FC3, using getpid for the thread I could use set_afinity to force each thread to its own processor and with FC5 I can't; so I've got one idle processor all the time. This sounds so unlikely I hesitate to mention it, but you are not, by any chance, running pthreads on one and nptl on the other, are you? -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: Probably wrong place to ask
Gene Heskett wrote: Greetings all; I have a card reader plugged into a usb port. I recognizes a 512meg pny cf card just fine, but wwhen I plug in a 256meg Lexar cf, the led comes on, but there is no reaction from linux. /dev/sda is not created, nothing. Is this a kernel config problem, or is this particular cf known to be a bad bird? I do that with CF and memory stick, what kernel, distribution, etc? I would suspect something in hotplug not noticing. I presume you have tried this from cold boot, so any issues with unplugging and plugging another flash are removed. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: [ANNOUNCE] System Inactivity Monitor v1.0
Alessandro Di Marco wrote: Hi all, this is a new 2.6.20 module implementing a user inactivity trigger. Basically it acts as an event sniffer, issuing an ACPI event when no user activity is detected for more than a certain amount of time. This event can be successively grabbed and managed by an user-level daemon such as acpid, blanking the screen, dimming the lcd-panel light à la mac, etc... Any idea how much power this saves? And for the vast rest of us who do run X, this seems to parallel the work of a well-tuned screensaver. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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] Recognize video=gx1fb:... option
Juergen Beisert reported that the following option doesn't work for him
video=gx1fb:[EMAIL PROTECTED]
though sisfb was able to parse similar option correctly.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
drivers/video/geode/gx1fb_core.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
--- a/drivers/video/geode/gx1fb_core.c
+++ b/drivers/video/geode/gx1fb_core.c
@@ -401,6 +401,30 @@ static void gx1fb_remove(struct pci_dev
framebuffer_release(info);
}
+#ifndef MODULE
+static void __init gx1fb_setup(char *options)
+{
+ char *this_opt;
+
+ if (!options || !*options)
+ return;
+
+ while ((this_opt = strsep(, ","))) {
+ if (!*this_opt)
+ continue;
+
+ if (!strncmp(this_opt, "mode:", 5))
+ strlcpy(mode_option, this_opt + 5, sizeof(mode_option));
+ else if (!strncmp(this_opt, "crt:", 4))
+ crt_option = !!simple_strtoul(this_opt + 4, NULL, 0);
+ else if (!strncmp(this_opt, "panel:", 6))
+ strlcpy(panel_option, this_opt + 6,
sizeof(panel_option));
+ else
+ strlcpy(mode_option, this_opt, sizeof(mode_option));
+ }
+}
+#endif
+
static struct pci_device_id gx1fb_id_table[] = {
{ PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5530_VIDEO,
PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY << 16,
@@ -420,8 +444,11 @@ static struct pci_driver gx1fb_driver =
static int __init gx1fb_init(void)
{
#ifndef MODULE
- if (fb_get_options("gx1fb", NULL))
+ char *option = NULL;
+
+ if (fb_get_options("gx1fb", ))
return -ENODEV;
+ gx1fb_setup(option);
#endif
return pci_register_driver(_driver);
}
-
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/5 (try 2)] eCryptfs: convert kmap() to kmap_atomic()
On Fri, Jan 19, 2007 at 02:04:47PM +0200, Pekka Enberg wrote:
> On 1/18/07, Michael Halcrow <[EMAIL PROTECTED]> wrote:
> >+ page_data = (char *)kmap_atomic(page, KM_USER0);
> >+ lower_page_data = (char *)kmap_atomic(lower_page, KM_USER1);
>
> Drop 'em redundant casts, please.
Replace kmap() with kmap_atomic(). Reduce the amount of time that
mappings are held.
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
Signed-off-by: Trevor Highland <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c |8 +--
fs/ecryptfs/ecryptfs_kernel.h |4 -
fs/ecryptfs/mmap.c| 121 -
3 files changed, 39 insertions(+), 94 deletions(-)
ff2dcd23fe6bd49987b2bf98ada70755f114
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index fbb62c8..ac4ea8d 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -429,10 +429,10 @@ static int ecryptfs_read_in_page(struct
goto out;
}
} else {
- rc = ecryptfs_grab_and_map_lower_page(lower_page, NULL,
- lower_inode,
- lower_page_idx);
- if (rc) {
+ *lower_page = grab_cache_page(lower_inode->i_mapping,
+ lower_page_idx);
+ if (!(*lower_page)) {
+ rc = -EINVAL;
ecryptfs_printk(
KERN_ERR, "Error attempting to grab and map "
"lower page with index [0x%.16x]; rc = [%d]\n",
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 859d31b..0e38d0d 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -527,10 +527,6 @@ int ecryptfs_copy_page_to_lower(struct p
struct file *lower_file);
int ecryptfs_do_readpage(struct file *file, struct page *page,
pgoff_t lower_page_index);
-int ecryptfs_grab_and_map_lower_page(struct page **lower_page,
-char **lower_virt,
-struct inode *lower_inode,
-unsigned long lower_page_index);
int ecryptfs_writepage_and_release_lower_page(struct page *lower_page,
struct inode *lower_inode,
struct writeback_control *wbc);
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 94bcabf..3dec846 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -234,22 +234,11 @@ int ecryptfs_do_readpage(struct file *fi
goto out;
}
wait_on_page_locked(lower_page);
- page_data = (char *)kmap(page);
- if (!page_data) {
- rc = -ENOMEM;
- ecryptfs_printk(KERN_ERR, "Error mapping page\n");
- goto out;
- }
- lower_page_data = (char *)kmap(lower_page);
- if (!lower_page_data) {
- rc = -ENOMEM;
- ecryptfs_printk(KERN_ERR, "Error mapping page\n");
- kunmap(page);
- goto out;
- }
+ page_data = kmap_atomic(page, KM_USER0);
+ lower_page_data = kmap_atomic(lower_page, KM_USER1);
memcpy(page_data, lower_page_data, PAGE_CACHE_SIZE);
- kunmap(lower_page);
- kunmap(page);
+ kunmap_atomic(lower_page_data, KM_USER1);
+ kunmap_atomic(page_data, KM_USER0);
rc = 0;
out:
if (likely(lower_page))
@@ -325,19 +314,14 @@ static int ecryptfs_readpage(struct file
if (page->index < num_pages_in_header_region) {
char *page_virt;
- page_virt = (char *)kmap(page);
- if (!page_virt) {
- rc = -ENOMEM;
- printk(KERN_ERR "Error mapping page\n");
- goto out;
- }
+ page_virt = kmap_atomic(page, KM_USER0);
memset(page_virt, 0, PAGE_CACHE_SIZE);
if (page->index == 0) {
rc = ecryptfs_read_xattr_region(
page_virt, file->f_path.dentry);
set_header_info(page_virt, crypt_stat);
}
- kunmap(page);
+ kunmap_atomic(page_virt, KM_USER0);
if (rc) {
printk(KERN_ERR "Error reading xattr "
"region\n");
@@ -387,26 +371,19 @@ static int fill_zeros_to_end_of_page(str
{
struct
Re: SATA exceptions with 2.6.20-rc5
On Friday, 19. January 2007 16:05, Alistair John Strachan wrote: > On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > > Robert Hancock wrote: > > > I'll try your stress test when I get a chance, but I doubt I'll run > > > into the same problem and I haven't seen any similar reports. Perhaps > > > it's some kind of wierd timing issue or incompatibility between the > > > controller and that drive when running in ADMA mode? I seem to remember > > > various reports of issues with certain Maxtor drives and some nForce > > > SATA controllers under Windows at least.. > > > > Just to eliminate things, has disabling ADMA been attempted? > > > > It can be disabled using the sata_nv.adma module parameter. > > Setting this option fixes the problem for me. I suggest that ADMA defaults > off in 2.6.20, if there's still time to do that. Not for me. I'm still have the same trouble, but less (maybe about every hour, instead of every 5 minutes). futhermore, I found a patch cocktail-2.6.20-rc3.patch: http://tinyurl.com/2gza8q, which improves the situation too! Now, the funny thing is that I've two SATA HDDs, but only 1 causes all the headaches. The affected drive is a: sda - @ata3.0 - WDC WD2500KS-00M 02.0 ATA-7, max UDMA/133, 488395055 sectors: LBA48 "ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 out res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133:PIO0 ata3: EH complete SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00" the "good" HDD is a: sdb - @ata4.0 - WDC WD2500YD-01N 10.0 ATA-7, max UDMA/133, 490234752 sectors: LBA48 NCQ (depth 0/1) System: AMD64 4200+ nForce 4 SLI 2 GB SMP PREEMPT kernel - 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] Don't map random pages if swapoff errors
Hello! > Getting an error there is all the more reason to proceed > with the swapoff, not to give up and break out of it. Yes, from this viewpoint more reasonable approach would be to untie corresponding ptes from swap entry and mark them as invalid to trigger fault on access. Not even tried simply because it is definitely not that thing, which we needed. We used this for process migration and for that purpose we really need to know when swapoff() fails ASAP to abort migration, to kill processes which got invalid pages and to resume original copy. Obviously, delayed fault is absolutely inappropriate for this particular purpose. Alexey - 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] include linux/fs.h in linux/cdev.h for struct inode
On Fri, Jan 19, 2007 at 12:54:07PM -0600, Noah Watkins wrote:
> --- a/include/linux/cdev.h
> +++ b/include/linux/cdev.h
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
>
> struct cdev {
> struct kobject kobj;
It is not for "struct inode", but to a pointer to struct inode!
You don't need full-blown header for pointer.
-
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/
Probably wrong place to ask
Greetings all; I have a card reader plugged into a usb port. I recognizes a 512meg pny cf card just fine, but wwhen I plug in a 256meg Lexar cf, the led comes on, but there is no reaction from linux. /dev/sda is not created, nothing. Is this a kernel config problem, or is this particular cf known to be a bad bird? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - 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: Odd USB problem on THOMSON PDP95FM
On Fri, Jan 19, 2007 at 06:55:10PM +, Marco Ferra wrote: > Hi kernel developers > > I don't know if this is the proper list but I have a very odd problem > and it's driving me nuts for the past two days. I suggest posting this to the linux-usb-devel mailing list, and including your kernel version, and enable CONFIG_USB_STORAGE_DEBUG to see the debugging error messages from the usb-storage driver to help us out. thanks, greg k-h - 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: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
Zan Lynx wrote: I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. I didn't investigate it in details yet, other file systems also freeze for me: http://marc.theaimsgroup.com/?l=linux-kernel=116809282829254=2 They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. Why did you decide to recover? Got oops after mount, or? But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (>s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (>s_umount_key#15) at ... __sync_inodes+0x78 #1: (>commit_mutex) ... reiser4_txn_end+0x37a #2: (>mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. - 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 8/15] ide: disable DMA in ->ide_dma_check for "no IORDY" case
Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: disable DMA in ->ide_dma_check for "no IORDY" case
I've looked thru the code, and found more issues with the PIO fallback
there. Will try to cook up patches for at least some drivers...
Great, if possible please base them on top of the IDE tree...
Erm, I had doubts about it (having in mind that all that code is more of a
cleanups than fixes). Maybe it'd be a good idea to separate the fix and
cleanup series somehow...
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Index: b/drivers/ide/pci/aec62xx.c
===
--- a/drivers/ide/pci/aec62xx.c
+++ b/drivers/ide/pci/aec62xx.c
@@ -214,12 +214,10 @@ static int aec62xx_config_drive_xfer_rat
if (ide_use_dma(drive) && config_chipset_for_dma(drive))
return hwif->ide_dma_on(drive);
- if (ide_use_fast_pio(drive)) {
+ if (ide_use_fast_pio(drive))
aec62xx_tune_drive(drive, 5);
This function looks like it's working (thouugh having the wrong limit of
PIO5 on auto-tuning) but is unnecassary complex.
Yes, it seems that there are actually two bugs here:
* the maximum allowed PIO mode should be PIO4 not PIO5
* for auto-tuning ("pio" == 255) it incorrectly sets PIO0
(255 fails to the default case in the switch statement)
Yeah, you if you pass 255, it won't work (so, drive->autotune must be
broken). But the driver itself have the wrong idea of 5 meaning auto-tune, so
fallback should still work.
Heh, the driver is certainly a rip-off form hpt366.c. What a doubtful
example they have chosen... :-)
hehe
The driver's authorship explains it all. :-)
Index: b/drivers/ide/pci/atiixp.c
===
--- a/drivers/ide/pci/atiixp.c
+++ b/drivers/ide/pci/atiixp.c
@@ -264,10 +264,9 @@ static int atiixp_dma_check(ide_drive_t
tspeed = ide_get_best_pio_mode(drive, 255, 5, NULL);
speed = atiixp_dma_2_pio(XFER_PIO_0 + tspeed) + XFER_PIO_0;
It's simply stupid to convert PIO mode to PIO mode. The whole idea is
doubtful as well..
It is side-effect of basing atiixp on piix driver. Fixing it will allow PIO1
to be used (good) because atiixp_dma_2_pio() always downgrades PIO1 to PIO0
(leftover from piix - on Intel chipsets same timings are used for PIO0/1).
hwif->speedproc(drive, speed);
Well, well, the tuneproc() method can't ahndle auto-tunuing here
(255)...
Yes, definitely a bug.
Ugh... don't expect patches form me soon though. My first priority is the
drivers that we support here...
And it also doesn't set up drive's own speed. The code seem to be another
rip-off from piix.c, repeating all its mistakes... :-)
:)
Index: b/drivers/ide/pci/cmd64x.c
===
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -479,12 +479,10 @@ static int cmd64x_config_drive_for_dma (
if (ide_use_dma(drive) && config_chipset_for_dma(drive))
return hwif->ide_dma_on(drive);
- if (ide_use_fast_pio(drive)) {
+ if (ide_use_fast_pio(drive))
config_chipset_for_pio(drive, 1);
This function will always set PIO mode 4. Mess.
Yep.
I'm going to send the patch for both this and siimage.c...
Index: b/drivers/ide/pci/cs5535.c
===
--- a/drivers/ide/pci/cs5535.c
+++ b/drivers/ide/pci/cs5535.c
@@ -206,10 +206,9 @@ static int cs5535_dma_check(ide_drive_t
if (ide_use_fast_pio(drive)) {
speed = ide_get_best_pio_mode(drive, 255, 4, NULL);
cs5535_set_drive(drive, speed);
Could be folded into tuneproc() method call.
Using ->tuneproc() will also set the PIO mode on the drive
which is not done currently...
Hm, ide_config_drive_speed() is called by both tuneproc() method and
cs5535_set_drive(), so I saw no issue there...
Index: b/drivers/ide/pci/sis5513.c
===
--- a/drivers/ide/pci/sis5513.c
+++ b/drivers/ide/pci/sis5513.c
@@ -678,12 +678,10 @@ static int sis5513_config_xfer_rate(ide_
if (ide_use_dma(drive) && config_chipset_for_dma(drive))
return hwif->ide_dma_on(drive);
- if (ide_use_fast_pio(drive)) {
+ if (ide_use_fast_pio(drive))
sis5513_tune_drive(drive, 5);
Ugh, PIO fallback effectively always tries to set mode 4 here (thanks
it's not 5). Mess.
Yep, but it seems to be even more complicated since config_art_rwp_pio()
is a mess^2 - chipset is programmed to the best PIO mode while the
device is set to PIO4... *sigh*...
Sorry, this one is low prio for me... :-)
Thanks,
Bart
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: EDAC chipkill messages
--- Orion Poplawski <[EMAIL PROTECTED]> wrote: > Robert Hancock wrote: > > Orion Poplawski wrote: > >> Can someone please explain to me what these mean? > >> > >> EDAC k8 MC1: general bus error: participating processor(local node > > >> origin), time-out(no timeout) memory transaction type(generic > read), > >> mem or i/o(mem access), cache level(generic) > >> EDAC MC1: CE page 0xfbf6f, offset 0x4d0, grain 8, syndrome 0xc8f4, > row > >> 1, channel 0, label "": k8_edac > >> EDAC MC1: CE - no information available: k8_edac Error Overflow > set > >> EDAC k8 MC1: extended error code: ECC chipkill x4 error > >> > >> Thanks! > >> > > > > Sounds like you're having some memory ECC errors.. some Memtest86, > etc. > > runs may be in order. You may be able to figure out from this info > what > > DIMM is having the problem. > > > > That was my assumption as well, but was hoping someone could decode > the > above information and point me to the problem chip. I ran Memtest86 > overnight but found no problems, but don't know if it needs to run in > a > particular ECC mode. > > This is a dual proc 275 system with 4 1GB DIMMs. Guessing that MC1 > is > the controller on the second CPU. Would row 1 be the second DIMM? No that would be the FIRST DIMM, on Channel 0 Each DIMM has 2 ChipSelect Rows (CSROW) Each csrow covers two channels across, therefore on a 4 socket memory array, there are CSROWS 0 and 1 on the first DIMM row and CSROWS 2 and 3 on the second DIMM row. W XXX Y ZZZ The W and the Y DIMMs are channel 0 The X and the Z DIMMs are channel 1 csrows 0 and 1 would cross over Y and Z DIMMs csrows 2 and 3 would cross over W and X DIMMs The mapping problem occurs in then identifying each of the above goes to which silk screen labeled sockets on the mobo. Usually they are labeled: H0_DIMM2A H0_DIMM2B H0_DIMM1A H0_DIMM1B where A is channel 0 and B is channel 1 and the "DIMM1" would indicate the CSROWs 0 and 1 and "DIMM2" would indicate the CSROWs 2 and 3 The string 'label ""' can be filled in by a userspace script to properly identify the DIMM silk screen according to the motherboard used. The lines with "EDAC MC1:" are EDAC CORE output messages, while the "EDAC K8:" lines are EDAC Memory Controller driver messages. "CE" is correctable error MC1 is memory controller 1 (0 based) ECC ChipKill x4 was what found the error and corrected it. The FRU, (field replaceable unit) is the DIMM located at socket H1_DIMM1A, according to the labeling I mentioned above. caveat: the detector is not 100% perfect but gives a general area to look at, the DIMM specification. Sometimes other errors can cause what looks like a memory error, but usually a bad memory DIMM is the root cause of the vast majority of such errors. In addition, memtest86+ doesn't find all the bad memory in all cases, but it is still a VERY useful tool doug thompson - 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: Threading...
> > And on FC5 I am using pthread_self but my problem isn't simply with > pthread_self, it's with the scheduling. maybe your kernel has a broken scheduler loadbalancing? you really shouldn't have to do this manually. At all. > On FC3 both threads run > simultaneously in almost symmetric parallel. On FC5 one thread don't pick > up and start until the previous one is done. On FC3, using getpid for the > thread I could use set_afinity to force each thread to its own processor and > with FC5 I can't; so I've got one idle processor all the time. again you can use gettid() or pthread_self() in that call (but remember it's a bitmask not a number); but really you shouldn't have to do this. Try a kernel which has a non-broken load balancer? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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] include linux/fs.h in linux/cdev.h for struct inode
On Fri, 19 Jan 2007 12:54:07 -0600 Noah Watkins wrote:
> ---
> include/linux/cdev.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/cdev.h b/include/linux/cdev.h
> index f309b00..b53e2a0 100644
> --- a/include/linux/cdev.h
> +++ b/include/linux/cdev.h
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
>
> struct cdev {
> struct kobject kobj;
> --
You can just do this forward declaration instead:
struct inode;
since no struct members are used/needed.
This cuts down on #include spider webs & nests.
---
~Randy
-
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 3/3] clockevent driver for arm/pxa2xx
On Tue, 9 Jan 2007 [EMAIL PROTECTED] wrote:
> Add a clockevent driver for pxa systems. This patch also removes the pxa
> dyntick support since it is not necessary anymore with generic dynamic
> tick support
>
> Signed-off-by: Luotao Fu <[EMAIL PROTECTED]>
> Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]>
>
> ---
> arch/arm/mach-pxa/time.c | 106
> ++-
> 1 file changed, 51 insertions(+), 55 deletions(-)
>
> Index: arch/arm/mach-pxa/time.c
> ===
> --- a/arch/arm/mach-pxa/time.c.orig
> +++ b/arch/arm/mach-pxa/time.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -29,6 +30,50 @@
> #include
> #include
>
> +static u32 clockevent_mode = 0;
> +
> +static void pxa_set_next_event(unsigned long evt,
> + struct clock_event_device *unused)
> +{
> + OSMR0 = OSCR + evt;
> +}
This doesn't work for me in various nasty ways. Please, check for a
minimum delay or loop to get ahead of time. See code in the "old" timer
ISR. See how it unconditionally adds at least 10 ticks...
Thanks
Guennadi
---
Guennadi Liakhovetski
-
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 8/15] ide: disable DMA in ->ide_dma_check for "no IORDY" case
Sergei Shtylyov wrote:
> Hello.
Hi,
> Bartlomiej Zolnierkiewicz wrote:
>> [PATCH] ide: disable DMA in ->ide_dma_check for "no IORDY" case
>
>I've looked thru the code, and found more issues with the PIO fallback
> there. Will try to cook up patches for at least some drivers...
Great, if possible please base them on top of the IDE tree...
>> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
>
>> Index: b/drivers/ide/pci/aec62xx.c
>> ===
>> --- a/drivers/ide/pci/aec62xx.c
>> +++ b/drivers/ide/pci/aec62xx.c
>> @@ -214,12 +214,10 @@ static int aec62xx_config_drive_xfer_rat
>> if (ide_use_dma(drive) && config_chipset_for_dma(drive))
>> return hwif->ide_dma_on(drive);
>>
>> - if (ide_use_fast_pio(drive)) {
>> + if (ide_use_fast_pio(drive))
>> aec62xx_tune_drive(drive, 5);
>
>This function looks like it's working (thouugh having the wrong limit of
> PIO5 on auto-tuning) but is unnecassary complex.
Yes, it seems that there are actually two bugs here:
* the maximum allowed PIO mode should be PIO4 not PIO5
* for auto-tuning ("pio" == 255) it incorrectly sets PIO0
(255 fails to the default case in the switch statement)
>Heh, the driver is certainly a rip-off form hpt366.c. What a doubtful
> example they have chosen... :-)
hehe
>> Index: b/drivers/ide/pci/atiixp.c
>> ===
>> --- a/drivers/ide/pci/atiixp.c
>> +++ b/drivers/ide/pci/atiixp.c
>> @@ -264,10 +264,9 @@ static int atiixp_dma_check(ide_drive_t
>> tspeed = ide_get_best_pio_mode(drive, 255, 5, NULL);
>> speed = atiixp_dma_2_pio(XFER_PIO_0 + tspeed) + XFER_PIO_0;
>
>It's simply stupid to convert PIO mode to PIO mode. The whole idea is
> doubtful as well..
It is side-effect of basing atiixp on piix driver. Fixing it will allow PIO1
to be used (good) because atiixp_dma_2_pio() always downgrades PIO1 to PIO0
(leftover from piix - on Intel chipsets same timings are used for PIO0/1).
>> hwif->speedproc(drive, speed);
>
>Well, well, the tuneproc() method can't ahndle auto-tunuing here
> (255)...
Yes, definitely a bug.
> And it also doesn't set up drive's own speed. The code seem to be another
> rip-off from piix.c, repeating all its mistakes... :-)
:)
>> Index: b/drivers/ide/pci/cmd64x.c
>> ===
>> --- a/drivers/ide/pci/cmd64x.c
>> +++ b/drivers/ide/pci/cmd64x.c
>> @@ -479,12 +479,10 @@ static int cmd64x_config_drive_for_dma (
>> if (ide_use_dma(drive) && config_chipset_for_dma(drive))
>> return hwif->ide_dma_on(drive);
>>
>> - if (ide_use_fast_pio(drive)) {
>> + if (ide_use_fast_pio(drive))
>> config_chipset_for_pio(drive, 1);
>
>This function will always set PIO mode 4. Mess.
Yep.
>> Index: b/drivers/ide/pci/cs5535.c
>> ===
>> --- a/drivers/ide/pci/cs5535.c
>> +++ b/drivers/ide/pci/cs5535.c
>> @@ -206,10 +206,9 @@ static int cs5535_dma_check(ide_drive_t
>> if (ide_use_fast_pio(drive)) {
>> speed = ide_get_best_pio_mode(drive, 255, 4, NULL);
>> cs5535_set_drive(drive, speed);
>
>Could be folded into tuneproc() method call.
Using ->tuneproc() will also set the PIO mode on the drive
which is not done currently...
>> Index: b/drivers/ide/pci/pdc202xx_old.c
>> ===
>> --- a/drivers/ide/pci/pdc202xx_old.c
>> +++ b/drivers/ide/pci/pdc202xx_old.c
>> @@ -339,12 +339,10 @@ static int pdc202xx_config_drive_xfer_ra
>> if (ide_use_dma(drive) && config_chipset_for_dma(drive))
>> return hwif->ide_dma_on(drive);
>>
>> - if (ide_use_fast_pio(drive)) {
>> + if (ide_use_fast_pio(drive))
>> hwif->tuneproc(drive, 5);
>
>This driver's tuneproc() method always auto-tunes here instead of
> setting
> what it's told too -- I'll send a patch...
Please do...
>> Index: b/drivers/ide/pci/siimage.c
>> ===
>> --- a/drivers/ide/pci/siimage.c
>> +++ b/drivers/ide/pci/siimage.c
>> @@ -420,12 +420,10 @@ static int siimage_config_drive_for_dma
>> if (ide_use_dma(drive) && config_chipset_for_dma(drive))
>> return hwif->ide_dma_on(drive);
>>
>> - if (ide_use_fast_pio(drive)) {
>> + if (ide_use_fast_pio(drive))
>> config_chipset_for_pio(drive, 1);
>
>This function will also always set PIO mode 4. More mess.
Yep, same bug as in cmd64x.c.
>> Index: b/drivers/ide/pci/sis5513.c
>> ===
>> --- a/drivers/ide/pci/sis5513.c
>> +++ b/drivers/ide/pci/sis5513.c
>> @@ -678,12 +678,10 @@ static int sis5513_config_xfer_rate(ide_
>> if (ide_use_dma(drive) &&
[PATCH] include linux/fs.h in linux/cdev.h for struct inode
---
include/linux/cdev.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/cdev.h b/include/linux/cdev.h
index f309b00..b53e2a0 100644
--- a/include/linux/cdev.h
+++ b/include/linux/cdev.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
struct cdev {
struct kobject kobj;
--
1.4.4.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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
On Sat, 20 Jan 2007, Vaidyanathan Srinivasan wrote: > >> However when the zone reclaimer starts to reclaim pages, it will > >> remove all cold pages and not specifically pagecache pages. This > >> may affect performance of applications. The reclaimer is passed a control structure that can be used to disable write to swap (if that is the concern). > I am open to suggestions on reclaim logic. My view is that we need > to selectively reclaim pagecache pages and not just call the > traditional reclaimer to freeup arbitrary type of pages. The traditional reclaim works fine if told what to do. Introducing another LRU list to do reclaim is a significant change to the VM, creates lots of overhead etc. - 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: Threading...
On 1/19/07 10:55 AM, "Arjan van de Ven" <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-01-19 at 10:43 -0800, Brian McGrew wrote:
>> I have a very interesting question about something that we're seeing
>> happening with threading between Fedora Core 3 and Fedora Core 5. Running
>> on Dell PowerEdge 1800 Hardware with a Xeon processor with hyper-threading
>> turned on. Both systems are using a 2.6.16.16 kernel (MVP al la special).
>>
>> We have a multithreaded application that starts two worker threads. On
>> Fedora Core 3 both of these we use getpid() to get the PID of the thread and
>> then use set_afinity to assign each thread to it's own CPU. Both threads
>> run almost symmetrically even on their given CPU watching the system
>> monitor.
>
> this is odd; even in FC3 getpid() is supposed to return the process ID
> not the thread ID
>
>> What am I missing? What do I need to do in FC5 or the kernel or the
>> threading library to get my threads to run in symmetric parallel again???
>
> you should fix the app to use something like pthread_self() instead...
> (or the highly unportable gettid() but that would just be horrible)
-
And on FC5 I am using pthread_self but my problem isn't simply with
pthread_self, it's with the scheduling. On FC3 both threads run
simultaneously in almost symmetric parallel. On FC5 one thread don't pick
up and start until the previous one is done. On FC3, using getpid for the
thread I could use set_afinity to force each thread to its own processor and
with FC5 I can't; so I've got one idle processor all the time.
-brian
Brian McGrew{ [EMAIL PROTECTED] || [EMAIL PROTECTED] }
--
> Do not read this email while waxing that cat!
-
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/
Odd USB problem on THOMSON PDP95FM
Hi kernel developers I don't know if this is the proper list but I have a very odd problem and it's driving me nuts for the past two days. I have a portable mp3 player named: usb-storage: waiting for device to settle before scanning Vendor: THOMSON Model: PDP95FM SeriesRev: 0100 Type: Direct-Access ANSI SCSI revision: 04 usb-storage: device scan complete SCSI device sda: 244288 2048-byte hdwr sectors (500 MB) sda: Write Protect is off sda: Mode Sense: 3e 00 00 00 sda: assuming drive cache: write through SCSI device sda: 244288 2048-byte hdwr sectors (500 MB) sda: Write Protect is off sda: Mode Sense: 3e 00 00 00 sda: assuming drive cache: write through sda: unknown partition table sd 0:0:0:0: Attached scsi removable disk sda that, I think, should act like an USB mass storage disk. I have done: # dd if=/dev/sda of=/dev/sda.dump sucessfully, several times. But I can't do: # dd if=/dev/zero of=/dev/sda The error, all the time: usb 2-1: reset full speed USB device using uhci_hcd and address 3 usb 2-1: reset full speed USB device using uhci_hcd and address 3 usb 2-1: reset full speed USB device using uhci_hcd and address 3 usb 2-1: reset full speed USB device using uhci_hcd and address 3 usb 2-1: reset full speed USB device using uhci_hcd and address 3 usb 2-1: reset full speed USB device using uhci_hcd and address 3 sd 0:0:0:0: SCSI error: return code = 0x5 end_request: I/O error, dev sda, sector 1064 Buffer I/O error on device sda, logical block 133 lost page write due to I/O error on sda and from dd: bash-3.00# dd if=/dev/zero of=/dev/sda dd: writing to `/dev/sda': Input/output error 13489+0 records in 13488+0 records out 6905856 bytes (6.9 MB) copied, 206.473 seconds, 33.4 kB/s dd: closing input file `/dev/zero': Bad file descriptor It never stops on the same place, but is always before reaching the 7 MB. I thought that I could ajust some tuneable parameters here: /sys/block/sda/device But I'm completly lost on the problem. If anyone could be of assistance, it would appreciated. Sincere regards Marco - 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: Threading...
On Fri, 2007-01-19 at 10:43 -0800, Brian McGrew wrote: > I have a very interesting question about something that we're seeing > happening with threading between Fedora Core 3 and Fedora Core 5. Running > on Dell PowerEdge 1800 Hardware with a Xeon processor with hyper-threading > turned on. Both systems are using a 2.6.16.16 kernel (MVP al la special). > > We have a multithreaded application that starts two worker threads. On > Fedora Core 3 both of these we use getpid() to get the PID of the thread and > then use set_afinity to assign each thread to it's own CPU. Both threads > run almost symmetrically even on their given CPU watching the system > monitor. this is odd; even in FC3 getpid() is supposed to return the process ID not the thread ID > What am I missing? What do I need to do in FC5 or the kernel or the > threading library to get my threads to run in symmetric parallel again??? you should fix the app to use something like pthread_self() instead... (or the highly unportable gettid() but that would just be horrible) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
Aubrey Li wrote: > On 1/19/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote: >> >> Hi Aubrey, >> >> The idea of creating separate flag for pagecache in page_alloc is >> interesting. The good part is that you flag watermark low and the >> zone reclaimer will do the rest of the job. >> >> However when the zone reclaimer starts to reclaim pages, it will >> remove all cold pages and not specifically pagecache pages. This >> may affect performance of applications. >> >> One possible solution to this reclaim is to use scan control fields >> and ask the shrink_page_list() and shrink_active_list() routines to >> target only pagecache pages. Pagecache pages are not mapped and >> they are easy to find on the LRU list. >> >> Please review my patch at http://lkml.org/lkml/2007/01/17/96 >> > > So you mean the existing reclaimer has the same issue, doesn't it? Well, the existing reclaimer will do the right job if the kernel really runs out of memory and need to recover pages for new allocations. The pages to be removed will be the coldest page in the system. However now with the introduction of pagecache limit, we are artificially creating a memory scarcity and forcing the reclaimer to throw away some pages while we actually have free usable RAM. In this context the choice of pages picked by the present reclaimer may not be the best ones. If pagecache is overlimit, we expect old (cold) pagecache pages to be thrown out and reused for new file data. We do not expect to drop a few text or data pages to make room for new pagecache. > In your and Roy's patch, balance_pagecache() routine is called on file > backed access. > So you still want to add this checking? or change the current > reclaimer completely? The balance_pagecache() routine is called for file backed access since that is when we would probably exceed the pagecache limit. The routine check if the limit has exceeded and calls the reclaimer. The reclaimer is an extension of the present reclaimer with more checks to remove only pagecache pages and not try to unmap any mapped pages and potentially affect application performance. I am open to suggestions on reclaim logic. My view is that we need to selectively reclaim pagecache pages and not just call the traditional reclaimer to freeup arbitrary type of pages. --Vaidy > -Aubrey > - > 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/
Threading...
I have a very interesting question about something that we're seeing
happening with threading between Fedora Core 3 and Fedora Core 5. Running
on Dell PowerEdge 1800 Hardware with a Xeon processor with hyper-threading
turned on. Both systems are using a 2.6.16.16 kernel (MVP al la special).
We have a multithreaded application that starts two worker threads. On
Fedora Core 3 both of these we use getpid() to get the PID of the thread and
then use set_afinity to assign each thread to it's own CPU. Both threads
run almost symmetrically even on their given CPU watching the system
monitor.
On Fedora Core 5 with whatever new threading mechanism is being used, getpid
no longer works on threads, it returns the same PID as the parent program.
So we're using _pthread_self to get a u_long thread id back. However,
set_afinity doesn't accept that, it wants a real PID. So we're leaving it
to the system to schedule the threads between the CPUS.
On FC3 the threads run on 2 CPUS in symmetry and almost in parallel.
However, the problem is on FC5 it doesn't work like that. We're seeing the
threading is almost more serial, where one thread will run on CPU1 at 100%
then as it's finishing and the CPU utilization is coming down, thread two is
coming up to 100% on CPU2 and they're ping ponging back and forth ... Which
is costing us a lot of time!
What am I missing? What do I need to do in FC5 or the kernel or the
threading library to get my threads to run in symmetric parallel again???
Thanks!
--
-brian
Brian McGrew{ [EMAIL PROTECTED] || [EMAIL PROTECTED] }
--
> With hope comes chance,
with chance comes destiny,
with destiny comes fate,
And with fate comes the courtesy flush!
-
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] Stop making "inline" imply forced inlining.
On Fri, Jan 19, 2007 at 12:39:37PM -0500, Robert P. J. Day wrote: > On Fri, 19 Jan 2007, Adrian Bunk wrote: > > > On Fri, Jan 19, 2007 at 11:56:30AM -0500, Robert P. J. Day wrote: > > > > > > Remove the macros that define simple "inlining" to mean forced > > > inlining, since you can (and *should*) get that effect with the > > > CONFIG_FORCED_INLINING kernel config variable instead. > > > > NAK. > > > > I don't see any place in the kernel where we need a non-forced > > inline. > > that's not the point. the point is that, as it stands now, the build > is *broken* in three ways. > > first, it's broken because declaring something simply as "inline" > *forces* it to be inlined, which flies in the face of historical > convention and is more than a little misleading. In the kernel it's what you should expect since it's defined this way for some time. > second, it's broken because both the use of > "__attribute__((always_inline))" all over the place and the > CONFIG_FORCED_INLINING kernel config option imply that you indeed have > a choice, when you clearly *don't*. quite simply, you can play with > that kernel config option or splash the "always_inline" attributes > around all you want and, unbeknownst to you, none of that is making > the *slightest* bit of difference. that is the very *definition* of a > "broken" build. It's the definition of a broken option. The solution is to remove CONFIG_FORCED_INLINING. > and, finally, you claim that you "don't see any place in the kernel > where we need a non-forced inline." i have already posted an alpha > header file that claims (rightly or wrongly) to need that freedom. > Q.E.D. Not Q.E.D. due to "rightly or wrongly". It could be because Alpha uses "extern inline" and with it's old semantice I'd understand that always_inline might be a problem - but is there actually any place where Alpha uses "extern inline" with this semantics and not in a way that it could be replaced with "static inline"? > > We have tons of inline's in C files that should simply be removed - > > let's do this instead. > > that may be a better idea, but it doesn't address the current > brokenness. > > i'm willing to believe that this patch has zero chance of going > anywhere. but if you want to reject it, at least be honest about it. > don't say, "there's no problem here." instead, say, "yes, the build > is broken but we don't feel like doing anything about it." Can you give at least one concrete example of actually broken code? The only implication I know it has caused is increased code size, but that's different from being "broken". And that's not "but we don't feel like doing anything about it" - it's "we should remove all the inline's from C files". > rday cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
[-mm patch] drivers/mtd/ubi/: possible cleanups
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc3-mm1:
>...
> git-ubi.patch
>...
> git trees
>...
This patch contains the following possible cleanups:
- make needlessly global code static
- remove the following unused variable:
- debug.c: alloc_prints
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
BTW: Do you really need that many different
CONFIG_MTD_UBI_DEBUG_* options?
drivers/mtd/ubi/cdev.c |4 +-
drivers/mtd/ubi/debug.c | 57 ++--
2 files changed, 28 insertions(+), 33 deletions(-)
--- linux-2.6.20-rc4-mm1/drivers/mtd/ubi/cdev.c.old 2007-01-19
17:49:47.0 +0100
+++ linux-2.6.20-rc4-mm1/drivers/mtd/ubi/cdev.c 2007-01-19 17:50:03.0
+0100
@@ -47,7 +47,7 @@
static int vol_cdev_open(struct inode *inode, struct file *file);
static int vol_cdev_release(struct inode *inode, struct file *file);
-loff_t vol_cdev_llseek(struct file *file, loff_t offset, int origin);
+static loff_t vol_cdev_llseek(struct file *file, loff_t offset, int origin);
static ssize_t vol_cdev_read(struct file *file, __user char *buf,
size_t count, loff_t * offp);
static ssize_t vol_cdev_write(struct file *file, const char __user *buf,
@@ -224,7 +224,7 @@
* positive offset in case of success and a negative error code in case of
* failure.
*/
-loff_t vol_cdev_llseek(struct file *file, loff_t offset, int origin)
+static loff_t vol_cdev_llseek(struct file *file, loff_t offset, int origin)
{
const struct ubi_vtbl_vtr *vtr;
struct ubi_vol_desc *desc = file->private_data;
--- linux-2.6.20-rc4-mm1/drivers/mtd/ubi/debug.c.old2007-01-19
17:50:42.0 +0100
+++ linux-2.6.20-rc4-mm1/drivers/mtd/ubi/debug.c2007-01-19
18:43:59.0 +0100
@@ -67,74 +67,69 @@
static int vb_err_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_UIF
-int uif_prints = 1;
+static int uif_prints = 1;
#else
-int uif_prints;
+static int uif_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_CDEV
-int cdev_prints = 1;
+static int cdev_prints = 1;
#else
-int cdev_prints;
+static int cdev_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_GLUEBI
-int gluebi_prints = 1;
+static int gluebi_prints = 1;
#else
-int gluebi_prints;
+static int gluebi_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_VMT
-int vmt_prints = 1;
+static int vmt_prints = 1;
#else
-int vmt_prints;
+static int vmt_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_UPD
-int upd_prints = 1;
+static int upd_prints = 1;
#else
-int upd_prints;
+static int upd_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_VTBL
-int vtbl_prints = 1;
+static int vtbl_prints = 1;
#else
-int vtbl_prints;
+static int vtbl_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_ACC
-int acc_prints = 1;
+static int acc_prints = 1;
#else
-int acc_prints;
+static int acc_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_EBA
-int eba_prints = 1;
+static int eba_prints = 1;
#else
-int eba_prints;
+static int eba_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_WL
-int wl_prints = 1;
+static int wl_prints = 1;
#else
-int wl_prints;
+static int wl_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_BGT
-int bgt_prints = 1;
+static int bgt_prints = 1;
#else
-int bgt_prints;
-#endif
-#ifdef CONFIG_MTD_UBI_DEBUG_MSG_ALLOC
-int alloc_prints = 1;
-#else
-int alloc_prints;
+static int bgt_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_IO
-int io_prints = 1;
+static int io_prints = 1;
#else
-int io_prints;
+static int io_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_BLD
-int bld_prints = 1;
+static int bld_prints = 1;
#else
-int bld_prints;
+static int bld_prints;
#endif
#ifdef CONFIG_MTD_UBI_DEBUG_MSG_SCAN
-int scan_prints = 1;
+static int scan_prints = 1;
#else
-int scan_prints;
+static int scan_prints;
#endif
/* If debugging messages should also go to the console */
-
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] hid: put usb_interface instead of usb_device into hid->dev
The commit 4916b3a57fc94664677d439b911b8aaf86c7ec23 introduced a
hid regression between 2.6.19 and 2.6.20-rc1. The device put in
input_dev->cdev is now of type usb_device instead of usb_interface.
Before:
> # readlink -f /sys/class/input/input6/event4/device
> /sys/devices/pci:00/:00:10.0/usb2/2-1/2-1:1.1
After:
> # readlink -f /sys/class/input/input3/event3/device
> /sys/devices/pci:00/:00:10.0/usb1/1-1
This causes breakage:
> # udevinfo -q all -n /dev/input/event3
> P: /class/input/input3/event3
> N: input/event3
> S: input/by-path/pci-1-1--event-
> E: ID_SERIAL=noserial
> E: ID_PATH=pci-1-1-
No ID_MODEL, ID_VENDOR, ID_REVISION, ID_TYPE etc etc.
Fix this by assigning the intf->dev into hid->dev, and fixing
all the users.
Signed-off-by: Anssi Hannula <[EMAIL PROTECTED]>
---
I recommend this fix to go to the stable tree before 2.6.20 is released.
diff -Nurp -x '*.mod' -x '*~'
linux-2.6.20-rc4-git5-promise-sata-pata-old/drivers/usb/input/hid-core.c
linux-2.6.20-rc4-git5-promise-sata-pata/drivers/usb/input/hid-core.c
--- linux-2.6.20-rc4-git5-promise-sata-pata-old/drivers/usb/input/hid-core.c
2007-01-12 16:16:18.0 +0200
+++ linux-2.6.20-rc4-git5-promise-sata-pata/drivers/usb/input/hid-core.c
2007-01-19 18:58:55.0 +0200
@@ -106,18 +106,18 @@ static void hid_reset(struct work_struct
if (test_bit(HID_CLEAR_HALT, >iofl)) {
dev_dbg(>intf->dev, "clear halt\n");
- rc = usb_clear_halt(to_usb_device(hid->dev),
usbhid->urbin->pipe);
+ rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid->urbin->pipe);
clear_bit(HID_CLEAR_HALT, >iofl);
hid_start_in(hid);
}
else if (test_bit(HID_RESET_PENDING, >iofl)) {
dev_dbg(>intf->dev, "resetting device\n");
- rc = rc_lock =
usb_lock_device_for_reset(to_usb_device(hid->dev), usbhid->intf);
+ rc = rc_lock = usb_lock_device_for_reset(hid_to_usb_dev(hid),
usbhid->intf);
if (rc_lock >= 0) {
- rc =
usb_reset_composite_device(to_usb_device(hid->dev), usbhid->intf);
+ rc = usb_reset_composite_device(hid_to_usb_dev(hid),
usbhid->intf);
if (rc_lock)
- usb_unlock_device(to_usb_device(hid->dev));
+ usb_unlock_device(hid_to_usb_dev(hid));
}
clear_bit(HID_RESET_PENDING, >iofl);
}
@@ -129,8 +129,8 @@ static void hid_reset(struct work_struct
break;
default:
err("can't reset device, %s-%s/input%d, status %d",
- to_usb_device(hid->dev)->bus->bus_name,
- to_usb_device(hid->dev)->devpath,
+ hid_to_usb_dev(hid)->bus->bus_name,
+ hid_to_usb_dev(hid)->devpath,
usbhid->ifnum, rc);
/* FALLTHROUGH */
case -EHOSTUNREACH:
@@ -217,8 +217,8 @@ static void hid_irq_in(struct urb *urb)
clear_bit(HID_IN_RUNNING, >iofl);
if (status != -EPERM) {
err("can't resubmit intr, %s-%s/input%d, status %d",
- to_usb_device(hid->dev)->bus->bus_name,
- to_usb_device(hid->dev)->devpath,
+ hid_to_usb_dev(hid)->bus->bus_name,
+ hid_to_usb_dev(hid)->devpath,
usbhid->ifnum, status);
hid_io_error(hid);
}
@@ -251,7 +251,7 @@ static int hid_submit_out(struct hid_dev
hid_output_report(report, usbhid->outbuf);
usbhid->urbout->transfer_buffer_length = ((report->size - 1) >> 3) + 1
+ (report->id > 0);
- usbhid->urbout->dev = to_usb_device(hid->dev);
+ usbhid->urbout->dev = hid_to_usb_dev(hid);
dbg("submitting out urb");
@@ -276,13 +276,13 @@ static int hid_submit_ctrl(struct hid_de
len = ((report->size - 1) >> 3) + 1 + (report->id > 0);
if (dir == USB_DIR_OUT) {
hid_output_report(report, usbhid->ctrlbuf);
- usbhid->urbctrl->pipe =
usb_sndctrlpipe(to_usb_device(hid->dev), 0);
+ usbhid->urbctrl->pipe = usb_sndctrlpipe(hid_to_usb_dev(hid), 0);
usbhid->urbctrl->transfer_buffer_length = len;
} else {
int maxpacket, padlen;
- usbhid->urbctrl->pipe =
usb_rcvctrlpipe(to_usb_device(hid->dev), 0);
- maxpacket = usb_maxpacket(to_usb_device(hid->dev),
usbhid->urbctrl->pipe, 0);
+ usbhid->urbctrl->pipe = usb_rcvctrlpipe(hid_to_usb_dev(hid), 0);
+ maxpacket = usb_maxpacket(hid_to_usb_dev(hid),
usbhid->urbctrl->pipe, 0);
if (maxpacket > 0) {
Re: [PATCH] nfs: fix congestion control
On Fri, 19 Jan 2007, Trond Myklebust wrote: > That would be good as a default, but I've been thinking that we could > perhaps also add a sysctl in /proc/sys/fs/nfs in order to make it a > tunable? Good idea. - 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] nfs: fix congestion control
On Fri, 2007-01-19 at 18:57 +0100, Peter Zijlstra wrote: > On Fri, 2007-01-19 at 09:20 -0800, Christoph Lameter wrote: > > On Fri, 19 Jan 2007, Peter Zijlstra wrote: > > > > > + /* > > > + * NFS congestion size, scale with available memory. > > > + * > > > > Well this all depends on the memory available to the running process. > > If the process is just allowed to allocate from a subset of memory > > (cpusets) then this may need to be lower. > > > > > + * 64MB:8192k > > > + * 128MB: 11585k > > > + * 256MB: 16384k > > > + * 512MB: 23170k > > > + * 1GB: 32768k > > > + * 2GB: 46340k > > > + * 4GB: 65536k > > > + * 8GB: 92681k > > > + * 16GB: 131072k > > > > Hmmm... lets say we have the worst case of an 8TB IA64 system with 1k > > nodes of 8G each. > > Eeuh, right. Glad to have you around to remind how puny my boxens > are :-) > > > On Ia64 the number of pages is 8TB/16KB pagesize = 512 > > million pages. Thus nfs_congestion_size is 724064 pages which is > > 11.1Gbytes? > > > > If we now restrict a cpuset to a single node then have a > > nfs_congestion_size of 11.1G vs an available memory on a node of 8G. > > Right, perhaps cap this to a max of 256M. That would allow 128 2M RPC > transfers, much more would not be needed I guess. Trond? That would be good as a default, but I've been thinking that we could perhaps also add a sysctl in /proc/sys/fs/nfs in order to make it a tunable? Cheers, Trond - 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: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
On Thu, 18 Jan 2007, Aubrey Li wrote: > +int sysctl_pagecache_ratio = 10; > + Pagecache ratio is the ratio of memory to be left over? Would it not be better to twist this around and to be able to specify how much of the memory of a node may be used by the pagecache? Why limit the size of the pagecache? Some kind of rationale would be useful. Maybe it was there in earlier incarnations of the patch that I did not see? It should be kept with it. zone_reclaim already dynamically limits the size of the pagecache. > + if (alloc_flags & ALLOC_PAGECACHE) > + min = min + (sysctl_pagecache_ratio * z->present_pages) / 100; The calculation of the multiplication / division is usually not done in the hot allocation path. See f.e. how min_unmapped_pages is handled in mm/page_alloc.c - 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] optimize o_direct on block device - v3
Hi Andrew,
Thanks again for finding the fix to the problem I reported.
Can you tell me when I might expect this fix to show up in
2.6.20-rc?
Thanks,
Mike
Andrew Morton wrote:
> On Thu, 11 Jan 2007 13:21:57 -0600
> Michael Reed <[EMAIL PROTECTED]> wrote:
>
>> Testing on my ia64 system reveals that this patch introduces a
>> data integrity error for direct i/o to a block device. Device
>> errors which result in i/o failure do not propagate to the
>> process issuing direct i/o to the device.
>>
>> This can be reproduced by doing writes to a fibre channel block
>> device and then disabling the switch port connecting the host
>> adapter to the switch.
>>
>
> Does this fix it?
>
>
>
>
>
> diff -puN fs/block_dev.c~a fs/block_dev.c
> --- a/fs/block_dev.c~a
> +++ a/fs/block_dev.c
> @@ -146,7 +146,7 @@ static int blk_end_aio(struct bio *bio,
> iocb->ki_nbytes = -EIO;
>
> if (atomic_dec_and_test(bio_count)) {
> - if (iocb->ki_nbytes < 0)
> + if ((long)iocb->ki_nbytes < 0)
> aio_complete(iocb, iocb->ki_nbytes, 0);
> else
> aio_complete(iocb, iocb->ki_left, 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/
>
>
-
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] hid: put usb_interface instead of usb_device into hid->dev
On Fri, 19 Jan 2007, Anssi Hannula wrote: > The commit 4916b3a57fc94664677d439b911b8aaf86c7ec23 introduced a > hid regression between 2.6.19 and 2.6.20-rc1. The device put in > input_dev->cdev is now of type usb_device instead of usb_interface. Yes, this is apparently a bug. Thanks a lot for the patch. > Fix this by assigning the intf->dev into hid->dev, and fixing all the > users. > > Signed-off-by: Anssi Hannula <[EMAIL PROTECTED]> > > --- > > I recommend this fix to go to the stable tree before 2.6.20 is released. Looks OK to me. I have queued it in HID tree - I am going to push this upstream in a few days. -- Jiri Kosina - 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] nfs: fix congestion control
On Fri, 19 Jan 2007, Peter Zijlstra wrote: > Eeuh, right. Glad to have you around to remind how puny my boxens > are :-) Sorry about that but it was unavoidable if we want to get to reasonable limits that will work in all situations. - 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] Don't map random pages if swapoff errors
On Fri, 19 Jan 2007, Alexey Dobriyan wrote:
> From: Alexey Kuznetsov <[EMAIL PROTECTED]>
>
> If read failed we cannot map not-uptodate page to user space.
Good point.
> Actually, we are in serious troubles, we do not even know what
> process to kill.
True, though we don't really want to kill anything yet: the process
may never need that page again. Better to let it continue until it
exits, or hits Kirill's check in do_swap_page. But sure, that's not
going to happen without us making some change here.
> So, the only variant remains: to stop swapoff()
> and allow someone to kill processes to zap invalid pages.
Simple as it is, no, I don't like this patch at all.
Getting an error there is all the more reason to proceed
with the swapoff, not to give up and break out of it.
Let me think a little.
CC'ed Richard, since he's also interested in bad swap, and this
reminds me to look at his patches (though he's been concerned with
when the writeout fails, rather than when the readin fails).
Hugh
>
> Signed-off-by: Alexey Kuznetsov <[EMAIL PROTECTED]>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> ---
>
> mm/swapfile.c | 13 +
> 1 file changed, 13 insertions(+)
>
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -766,6 +766,19 @@ static int try_to_unuse(unsigned int typ
> lock_page(page);
> wait_on_page_writeback(page);
>
> + /* If read failed we cannot map not-uptodate page to
> + * user space. Actually, we are in serious troubles,
> + * we do not even know what process to kill. So, the only
> + * variant remains: to stop swapoff() and allow someone
> + * to kill processes to zap invalid pages.
> + */
> + if (unlikely(!PageUptodate(page))) {
> + unlock_page(page);
> + page_cache_release(page);
> + retval = -EIO;
> + break;
> + }
> +
> /*
>* Remove all references to entry.
>* Whenever we reach init_mm, there's no address space
-
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: BUG: linux 2.6.19 unable to enable acpi
On 1/19/07, Len Brown <[EMAIL PROTECTED]> wrote:
I guess I'm losing my mind, because when I read this code,
there are only two ways out of the while(retry) loop.
Either return with success, or retry is 0.
So how the heck is retry printed as 142?!
did you notice any delay between the last two lines of printout above?
please boot with "acpi_dbg_layer=2" "acpi_dbg_level=0x"
so that we can see each read and write of the hardware look like.
Success is measured here by looking for SCI_EN being set
to indicate that we successfully entered ACPI mode.
I guess we should see about 142 reads looking for SCI_EN...
It would be interesting if you could boot a windows disk on this box
to see if they are able to get into ACPI mode. You'd be able to
tell by dumping the interrupt list, looking at the device tree,
or observing if the power button gives immediate poweroff
or does an OS shutdown.
thanks,
-Len
printk("ACPI: retry %d\n") -> printk("ACPI: retry %d\n", retry)
;)
ill try this again soon.
-
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] nfs: fix congestion control
On Fri, 2007-01-19 at 09:20 -0800, Christoph Lameter wrote: > On Fri, 19 Jan 2007, Peter Zijlstra wrote: > > > + /* > > +* NFS congestion size, scale with available memory. > > +* > > Well this all depends on the memory available to the running process. > If the process is just allowed to allocate from a subset of memory > (cpusets) then this may need to be lower. > > > +* 64MB:8192k > > +* 128MB: 11585k > > +* 256MB: 16384k > > +* 512MB: 23170k > > +* 1GB: 32768k > > +* 2GB: 46340k > > +* 4GB: 65536k > > +* 8GB: 92681k > > +* 16GB: 131072k > > Hmmm... lets say we have the worst case of an 8TB IA64 system with 1k > nodes of 8G each. Eeuh, right. Glad to have you around to remind how puny my boxens are :-) > On Ia64 the number of pages is 8TB/16KB pagesize = 512 > million pages. Thus nfs_congestion_size is 724064 pages which is > 11.1Gbytes? > > If we now restrict a cpuset to a single node then have a > nfs_congestion_size of 11.1G vs an available memory on a node of 8G. Right, perhaps cap this to a max of 256M. That would allow 128 2M RPC transfers, much more would not be needed I guess. Trond? - 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/
linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
I have been running 2.6.20-rc2-mm1 without problems, but both rc3-mm1 and rc4-mm1 have been giving me these freezes. They were happening inside X and without external console it was impossible to get anything, plus I was reluctant to test it since the freeze sometimes requires a full fsck.reiser4 --build-fs to recover the filesystem. But I finally got some output in a console session. I wasn't able to get it all, I made some notes of what I think the problem is. I may try again later once I get netconsole working (netconsole fails as a built-in, I'll try it as a module next). 1 lock held by pdflush/185: #0: (>s_umount_key#15) ... writeback_inodes+0x89 3 locks held by realsync/12942: #0: (>s_umount_key#15) at ... __sync_inodes+0x78 #1: (>commit_mutex) ... reiser4_txn_end+0x37a #2: (>mutex) ... synchronize_qrcu+0x19 So, I *think* the problem is two locks on s_umount_key#15. Does that sound likely? I also noticed QRCU may be involved. Perhaps someone will look at this and instantly know what the problem is. If not, I'll be following up with more details like .config and perhaps a full sysrq-T dump as soon as that fsck finishes. signature.asc Description: This is a digitally signed message part
Re: [PATCH] nfs: fix congestion control
On Fri, 2007-01-19 at 11:51 -0500, Trond Myklebust wrote: > > So with that out of the way I now have this > > Looks much better. Just one obvious buglet... > > @@ -1565,6 +1579,23 @@ int __init nfs_init_writepagecache(void) > > if (nfs_commit_mempool == NULL) > > return -ENOMEM; > > > > + /* > > +* NFS congestion size, scale with available memory. > > +* > > +* 64MB:8192k > > +* 128MB: 11585k > > +* 256MB: 16384k > > +* 512MB: 23170k > > +* 1GB: 32768k > > +* 2GB: 46340k > > +* 4GB: 65536k > > +* 8GB: 92681k > > +* 16GB: 131072k > > +* > > +* This allows larger machines to have larger/more transfers. > > +*/ > > + nfs_congestion_size = 32*int_sqrt(totalram_pages); > > + > ^^^ nfs_congestion_pages? Ah, yeah, forgot to refresh the patch one last time before sending out :-(. - 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: Possible ways of dealing with OOM conditions.
On Thu, 18 Jan 2007, Peter Zijlstra wrote: > > > Cache misses for small packet flow due to the fact, that the same data > > is allocated and freed and accessed on different CPUs will become an > > issue soon, not right now, since two-four core CPUs are not yet to be > > very popular and price for the cache miss is not _that_ high. > > SGI does networking too, right? Sslab deals with those issues the right way. We have per processor queues that attempt to keep the cache hot state. A special shared queue exists between neighboring processors to facilitate exchange of objects between then. - 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] Stop making "inline" imply forced inlining.
On Fri, 19 Jan 2007, Adrian Bunk wrote: > On Fri, Jan 19, 2007 at 11:56:30AM -0500, Robert P. J. Day wrote: > > > > Remove the macros that define simple "inlining" to mean forced > > inlining, since you can (and *should*) get that effect with the > > CONFIG_FORCED_INLINING kernel config variable instead. > > NAK. > > I don't see any place in the kernel where we need a non-forced > inline. that's not the point. the point is that, as it stands now, the build is *broken* in three ways. first, it's broken because declaring something simply as "inline" *forces* it to be inlined, which flies in the face of historical convention and is more than a little misleading. second, it's broken because both the use of "__attribute__((always_inline))" all over the place and the CONFIG_FORCED_INLINING kernel config option imply that you indeed have a choice, when you clearly *don't*. quite simply, you can play with that kernel config option or splash the "always_inline" attributes around all you want and, unbeknownst to you, none of that is making the *slightest* bit of difference. that is the very *definition* of a "broken" build. and, finally, you claim that you "don't see any place in the kernel where we need a non-forced inline." i have already posted an alpha header file that claims (rightly or wrongly) to need that freedom. Q.E.D. > We have tons of inline's in C files that should simply be removed - > let's do this instead. that may be a better idea, but it doesn't address the current brokenness. i'm willing to believe that this patch has zero chance of going anywhere. but if you want to reject it, at least be honest about it. don't say, "there's no problem here." instead, say, "yes, the build is broken but we don't feel like doing anything about it." rday - 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: unable to mmap /dev/kmem
On Fri, 19 Jan 2007, Arjan van de Ven wrote: > On Fri, 2007-01-19 at 17:12 +, Hugh Dickins wrote: > > Though so long as /dev/mem support remains, /dev/kmem might as well? > > they're not the same; for a long time, /dev/mem on actual memory > returned zeros... so you couldn't use it for rootkits ;) > (that got "fixed" a while ago) We fixed (or "fixed") the mmap of them both, not to give zeroes on !PageReserved pages; but read and write were never so restricted. (Oh, I've said "never" again - expect I'll be humiliated shortly.) Can't rootkits work as just about as easily through read & write? Hugh - 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/
