[PATCH fixed] Better document profile=
Be more explicit on what the step/bucket size accomplishes. Signed-off-by: Russ Dill <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index eb24799..3c6fd27 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1427,7 +1427,10 @@ and is between 256 and 4096 characters. It is defined in the file Format: [schedule,] Param: "schedule" - profile schedule points. Param: - step/bucket size as a power of 2 for - statistical time based profiling. + statistical time based profiling. A value of + 2 will provide a granularity of 4 bytes, a + value of 3 will provide a granularity of 8 + bytes and so on. Param: "sleep" - profile D-state sleeping (millisecs) processor.max_cstate= [HW,ACPI] -- 1.5.2.5 - 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/6] forcedeth: use NAPI for TX completion
commit a7c00e796597b797ceac3c18e8b85c124196c5ab
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue Oct 16 17:33:19 2007 -0400
[netdrvr] forcedeth: use NAPI for TX completion
A hand-rolled TX poll & work limit system was already in place, so it
was easy to convert the TX path to use NAPI.
This simplifies the code, and enables future improvements and
simplifications.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/forcedeth.c | 170 +---
1 file changed, 90 insertions(+), 80 deletions(-)
a7c00e796597b797ceac3c18e8b85c124196c5ab
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 32a8893..81fe016 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -660,6 +660,7 @@ struct fe_priv {
struct net_device *dev;
struct napi_struct napi;
+ struct napi_struct tx_napi;
/* General data:
* Locking: spin_lock(>lock); */
@@ -725,7 +726,6 @@ struct fe_priv {
union ring_type tx_ring;
u32 tx_flags;
int tx_ring_size;
- int tx_stop;
/* vlan fields */
struct vlan_group *vlangrp;
@@ -1732,10 +1732,7 @@ static int nv_start_xmit(struct sk_buff *skb, struct
net_device *dev)
empty_slots = nv_get_empty_tx_slots(np);
if (unlikely(empty_slots <= entries)) {
- spin_lock_irq(>lock);
netif_stop_queue(dev);
- np->tx_stop = 1;
- spin_unlock_irq(>lock);
return NETDEV_TX_BUSY;
}
@@ -1848,10 +1845,7 @@ static int nv_start_xmit_optimized(struct sk_buff *skb,
struct net_device *dev)
empty_slots = nv_get_empty_tx_slots(np);
if (unlikely(empty_slots <= entries)) {
- spin_lock_irq(>lock);
netif_stop_queue(dev);
- np->tx_stop = 1;
- spin_unlock_irq(>lock);
return NETDEV_TX_BUSY;
}
@@ -1956,14 +1950,15 @@ static int nv_start_xmit_optimized(struct sk_buff *skb,
struct net_device *dev)
*
* Caller must own np->lock.
*/
-static void nv_tx_done(struct net_device *dev)
+static int nv_tx_done(struct net_device *dev, int limit)
{
struct fe_priv *np = netdev_priv(dev);
u32 flags;
- struct ring_desc* orig_get_tx = np->get_tx.orig;
+ int tx_work = 0;
while ((np->get_tx.orig != np->put_tx.orig) &&
- !((flags = le32_to_cpu(np->get_tx.orig->flaglen)) &
NV_TX_VALID)) {
+ !((flags = le32_to_cpu(np->get_tx.orig->flaglen)) & NV_TX_VALID)
&&
+ (tx_work < limit)) {
dprintk(KERN_DEBUG "%s: nv_tx_done: flags 0x%x.\n",
dev->name, flags);
@@ -2008,22 +2003,25 @@ static void nv_tx_done(struct net_device *dev)
np->get_tx.orig = np->first_tx.orig;
if (unlikely(np->get_tx_ctx++ == np->last_tx_ctx))
np->get_tx_ctx = np->first_tx_ctx;
+
+ tx_work++;
}
- if (unlikely((np->tx_stop == 1) && (np->get_tx.orig != orig_get_tx))) {
- np->tx_stop = 0;
+
+ if (tx_work)
netif_wake_queue(dev);
- }
+
+ return tx_work;
}
-static void nv_tx_done_optimized(struct net_device *dev, int limit)
+static int nv_tx_done_optimized(struct net_device *dev, int limit)
{
struct fe_priv *np = netdev_priv(dev);
u32 flags;
- struct ring_desc_ex* orig_get_tx = np->get_tx.ex;
+ int tx_work = 0;
while ((np->get_tx.ex != np->put_tx.ex) &&
!((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX_VALID) &&
- (limit-- > 0)) {
+ (tx_work < limit)) {
dprintk(KERN_DEBUG "%s: nv_tx_done_optimized: flags 0x%x.\n",
dev->name, flags);
@@ -2043,11 +2041,14 @@ static void nv_tx_done_optimized(struct net_device
*dev, int limit)
np->get_tx.ex = np->first_tx.ex;
if (unlikely(np->get_tx_ctx++ == np->last_tx_ctx))
np->get_tx_ctx = np->first_tx_ctx;
+
+ tx_work++;
}
- if (unlikely((np->tx_stop == 1) && (np->get_tx.ex != orig_get_tx))) {
- np->tx_stop = 0;
+
+ if (tx_work)
netif_wake_queue(dev);
- }
+
+ return tx_work;
}
/*
@@ -2120,7 +2121,7 @@ static void nv_tx_timeout(struct net_device *dev)
/* 2) check that the packets were not sent already: */
if (!nv_optimized(np))
- nv_tx_done(dev);
+ nv_tx_done(dev, np->tx_ring_size);
else
nv_tx_done_optimized(dev, np->tx_ring_size);
@@ -2888,7 +2889,7 @@ static irqreturn_t __nv_nic_irq(struct net_device *dev,
bool optimized)
{
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = np->base;
- u32 events;
+
[PATCH 6/6] [netdrvr] interrupt handling overhaul
commit 4f97856cd73ad3ccee06f1856c60cb1ed8f44ceb
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue Oct 16 19:48:15 2007 -0400
[netdrvr] interrupt handling overhaul
* eliminate the work loops in the interrupt handlers. they are no
longer needed, now that NAPI and other asynchronous tasks handle our
work (and can be independently controlled by means other than
disable_irq or spin_lock_irqsave).
* make ->poll_controller call interrupt handler directly
* now that nv_do_nic_poll()'s only users are those that request
recovery, we can rename it to nv_reset_task(), and convert it from a
timer-context function to a workqueue.
* ->tx_timeout TX reset is replaced by requesting recovery
* in the main irq handler (INTx or MSI), the spinlock is always
taken in the common case: TX-or-RX work available. take the lock once
for any work, near the beginning of the irq handler (after status is
read and cleared).
This accomplishes the goal of getting a np->irqmask access inside the
lock, simplifies the code, and enables better control over irq
masking.
* no need to take lock, simply to schedule timer
* MSI-X RX/TX irq handling micro-optimization
* use IRQ_NONE/IRQ_HANDLED in nv_nic_irq_test(), rather than the less
readable versions of the same values.
* in nv_close(), make sure to cancel the workqueue tasks first thing,
to ensure they (mainly the reset task) will not race with interface
shutdown.
* move now-pointless tests of np->recover_error and netif_running()
in nv_reset_task(), resulting in a large de-indent of existing code.
* eliminate now-useless max_interrupt_work module option. though we
might want to consider permitting tuning of NAPI weights via ethtool,
in the future.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/forcedeth.c | 385 +++-
1 file changed, 158 insertions(+), 227 deletions(-)
4f97856cd73ad3ccee06f1856c60cb1ed8f44ceb
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 81fe016..8af9a96 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -58,6 +58,7 @@
#include
#include
#include
+#include
#include
#include
@@ -676,7 +677,6 @@ struct fe_priv {
unsigned int phy_model;
u16 gigabit;
int intr_test;
- int recover_error;
/* General data: RO fields */
dma_addr_t ring_addr;
@@ -701,14 +701,14 @@ struct fe_priv {
struct nv_skb_map *first_rx_ctx, *last_rx_ctx;
struct nv_skb_map *rx_skb;
- union ring_type rx_ring;
- unsigned int rx_buf_sz;
- unsigned int pkt_limit;
- struct timer_list oom_kick;
- struct timer_list nic_poll;
- struct delayed_work stats_task;
- u32 nic_poll_irq;
- int rx_ring_size;
+ union ring_type rx_ring;
+ unsigned intrx_buf_sz;
+ unsigned intpkt_limit;
+ struct timer_list oom_kick;
+ struct work_struct reset_task;
+ struct delayed_work stats_task;
+ u32 nic_poll_irq;
+ int rx_ring_size;
/* media detection workaround.
* Locking: Within irq hander or disable_irq+spin_lock(>lock);
@@ -739,12 +739,6 @@ struct fe_priv {
};
/*
- * Maximum number of loops until we assume that a bit in the irq mask
- * is stuck. Overridable with module param.
- */
-static int max_interrupt_work = 5;
-
-/*
* Optimization can be either throuput mode or cpu mode
*
* Throughput Mode: Every tx and rx packet will generate an interrupt.
@@ -2116,27 +2110,9 @@ static void nv_tx_timeout(struct net_device *dev)
spin_lock_irq(>lock);
- /* 1) stop tx engine */
- nv_stop_tx(dev);
-
- /* 2) check that the packets were not sent already: */
- if (!nv_optimized(np))
- nv_tx_done(dev, np->tx_ring_size);
- else
- nv_tx_done_optimized(dev, np->tx_ring_size);
-
- /* 3) if there are dead entries: clear everything */
- if (np->get_tx_ctx != np->put_tx_ctx) {
- printk(KERN_DEBUG "%s: tx_timeout: dead entries!\n", dev->name);
- nv_drain_tx(dev);
- nv_init_tx(dev);
- setup_hw_rings(dev, NV_SETUP_TX_RING);
- }
-
- netif_wake_queue(dev);
+ np->nic_poll_irq = np->irqmask;
+ schedule_work(>reset_task);
- /* 4) restart tx engine */
- nv_start_tx(dev);
spin_unlock_irq(>lock);
}
@@ -2890,101 +2866,82 @@ static irqreturn_t __nv_nic_irq(struct net_device
*dev, bool optimized)
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = np->base;
u32 events, updmask = 0;
- int i;
+ bool msix = np->msi_flags & NV_MSI_X_ENABLED;
[PATCH 4/6] forcedeth: unconditionally enable NAPI
commit 8f61debaeb334bce0ccba1a1384d549a377c1e8e
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue Oct 16 12:55:08 2007 -0400
[netdrvr] forcedeth: unconditionally enable NAPI
Remove all !CONFIG_FORCEDETH_NAPI code, and the Kconfig option,
enabling NAPI unconditionally.
The NIC driver recreates a lot of this functionality manually.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/Kconfig | 17 -
drivers/net/forcedeth.c | 143 ++--
2 files changed, 7 insertions(+), 153 deletions(-)
8f61debaeb334bce0ccba1a1384d549a377c1e8e
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 83d52c8..eafdd58 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1430,23 +1430,6 @@ config FORCEDETH
. The module will be
called forcedeth.
-config FORCEDETH_NAPI
- bool "Use Rx and Tx Polling (NAPI) (EXPERIMENTAL)"
- depends on FORCEDETH && EXPERIMENTAL
- help
- NAPI is a new driver API designed to reduce CPU and interrupt load
- when the driver is receiving lots of packets from the card. It is
- still somewhat experimental and thus not yet enabled by default.
-
- If your estimated Rx load is 10kpps or more, or if the card will be
- deployed on potentially unfriendly networks (e.g. in a firewall),
- then say Y here.
-
- See for more
- information.
-
- If in doubt, say N.
-
config CS89x0
tristate "CS89x0 support"
depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 ||
ARCH_PNX010X)
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index a4baad7..32a8893 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -1546,7 +1546,6 @@ static int nv_alloc_rx_optimized(struct net_device *dev)
}
/* If rx bufs are exhausted called after 50ms to attempt to refresh */
-#ifdef CONFIG_FORCEDETH_NAPI
static void nv_do_rx_refill(unsigned long data)
{
struct net_device *dev = (struct net_device *) data;
@@ -1555,41 +1554,6 @@ static void nv_do_rx_refill(unsigned long data)
/* Just reschedule NAPI rx processing */
netif_rx_schedule(dev, >napi);
}
-#else
-static void nv_do_rx_refill(unsigned long data)
-{
- struct net_device *dev = (struct net_device *) data;
- struct fe_priv *np = netdev_priv(dev);
- int retcode;
-
- if (!using_multi_irqs(dev)) {
- if (np->msi_flags & NV_MSI_X_ENABLED)
-
disable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_ALL].vector);
- else
- disable_irq(dev->irq);
- } else {
- disable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_RX].vector);
- }
- if (!nv_optimized(np))
- retcode = nv_alloc_rx(dev);
- else
- retcode = nv_alloc_rx_optimized(dev);
- if (retcode) {
- spin_lock_irq(>lock);
- if (netif_running(dev))
- mod_timer(>oom_kick, jiffies + OOM_REFILL);
- spin_unlock_irq(>lock);
- }
- if (!using_multi_irqs(dev)) {
- if (np->msi_flags & NV_MSI_X_ENABLED)
- enable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_ALL].vector);
- else
- enable_irq(dev->irq);
- } else {
- enable_irq(np->msi_x_entry[NV_MSI_X_VECTOR_RX].vector);
- }
-}
-#endif
static void nv_init_rx(struct net_device *dev)
{
@@ -2347,11 +2311,7 @@ static int nv_rx_process(struct net_device *dev, int
limit)
skb->protocol = eth_type_trans(skb, dev);
dprintk(KERN_DEBUG "%s: nv_rx_process: %d bytes, proto %d
accepted.\n",
dev->name, len, skb->protocol);
-#ifdef CONFIG_FORCEDETH_NAPI
netif_receive_skb(skb);
-#else
- netif_rx(skb);
-#endif
dev->last_rx = jiffies;
dev->stats.rx_packets++;
dev->stats.rx_bytes += len;
@@ -2446,27 +2406,14 @@ static int nv_rx_process_optimized(struct net_device
*dev, int limit)
dev->name, len, skb->protocol);
if (likely(!np->vlangrp)) {
-#ifdef CONFIG_FORCEDETH_NAPI
netif_receive_skb(skb);
-#else
- netif_rx(skb);
-#endif
} else {
vlanflags = le32_to_cpu(np->get_rx.ex->buflow);
if (vlanflags & NV_RX3_VLAN_TAG_PRESENT) {
-#ifdef CONFIG_FORCEDETH_NAPI
vlan_hwaccel_receive_skb(skb,
np->vlangrp,
vlanflags &
NV_RX3_VLAN_TAG_MASK);
-#else
- vlan_hwaccel_rx(skb, np->vlangrp,
-
[PATCH 3/6] forcedeth: eliminate some duplicate irq handling code
commit c6ad879c65e6f91c7f61b86936e2ea39b16711da
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue Oct 16 11:43:27 2007 -0400
[netdrvr] forcedeth: eliminate some duplicate irq handling code
* nv_nic_irq_optimized() is the exactly same as nv_nic_irq(), save
for three function calls. Consolidate together into a single function
__nv_nic_irq().
* remove pointless casts from void* in other irq handling code
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/forcedeth.c | 167 ++--
1 file changed, 38 insertions(+), 129 deletions(-)
c6ad879c65e6f91c7f61b86936e2ea39b16711da
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 39ade56..a4baad7 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2937,15 +2937,14 @@ static void nv_link_irq(struct net_device *dev)
dprintk(KERN_DEBUG "%s: link change notification done.\n", dev->name);
}
-static irqreturn_t nv_nic_irq(int foo, void *data)
+static irqreturn_t __nv_nic_irq(struct net_device *dev, bool optimized)
{
- struct net_device *dev = (struct net_device *) data;
struct fe_priv *np = netdev_priv(dev);
- u8 __iomem *base = get_hwbase(dev);
+ u8 __iomem *base = np->base;
u32 events;
int i;
- dprintk(KERN_DEBUG "%s: nv_nic_irq\n", dev->name);
+ dprintk(KERN_DEBUG "%s: __nv_nic_irq\n", dev->name);
for (i=0; ; i++) {
if (!(np->msi_flags & NV_MSI_X_ENABLED)) {
@@ -2960,7 +2959,10 @@ static irqreturn_t nv_nic_irq(int foo, void *data)
break;
spin_lock(>lock);
- nv_tx_done(dev);
+ if (optimized)
+ nv_tx_done_optimized(dev, TX_WORK_PER_LOOP);
+ else
+ nv_tx_done(dev);
spin_unlock(>lock);
#ifdef CONFIG_FORCEDETH_NAPI
@@ -2978,12 +2980,23 @@ static irqreturn_t nv_nic_irq(int foo, void *data)
spin_unlock(>lock);
}
#else
- if (nv_rx_process(dev, RX_WORK_PER_LOOP)) {
- if (unlikely(nv_alloc_rx(dev))) {
- spin_lock(>lock);
- if (netif_running(dev))
- mod_timer(>oom_kick, jiffies +
OOM_REFILL);
- spin_unlock(>lock);
+ if (optimized) {
+ if (nv_rx_process_optimized(dev, RX_WORK_PER_LOOP)) {
+ if (unlikely(nv_alloc_rx_optimized(dev))) {
+ spin_lock(>lock);
+ if (netif_running(dev))
+ mod_timer(>oom_kick,
jiffies + OOM_REFILL);
+ spin_unlock(>lock);
+ }
+ }
+ } else {
+ if (nv_rx_process(dev, RX_WORK_PER_LOOP)) {
+ if (unlikely(nv_alloc_rx(dev))) {
+ spin_lock(>lock);
+ if (netif_running(dev))
+ mod_timer(>oom_kick,
jiffies + OOM_REFILL);
+ spin_unlock(>lock);
+ }
}
}
#endif
@@ -3042,130 +3055,26 @@ static irqreturn_t nv_nic_irq(int foo, void *data)
}
}
- dprintk(KERN_DEBUG "%s: nv_nic_irq completed\n", dev->name);
+ dprintk(KERN_DEBUG "%s: __nv_nic_irq completed\n", dev->name);
return IRQ_RETVAL(i);
}
-/**
- * All _optimized functions are used to help increase performance
- * (reduce CPU and increase throughput). They use descripter version 3,
- * compiler directives, and reduce memory accesses.
- */
-static irqreturn_t nv_nic_irq_optimized(int foo, void *data)
+static irqreturn_t nv_nic_irq(int foo, void *data)
{
- struct net_device *dev = (struct net_device *) data;
- struct fe_priv *np = netdev_priv(dev);
- u8 __iomem *base = get_hwbase(dev);
- u32 events;
- int i;
-
- dprintk(KERN_DEBUG "%s: nv_nic_irq_optimized\n", dev->name);
-
- for (i=0; ; i++) {
- if (!(np->msi_flags & NV_MSI_X_ENABLED)) {
- events = readl(base + NvRegIrqStatus) &
NVREG_IRQSTAT_MASK;
- writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus);
- } else {
- events = readl(base + NvRegMSIXIrqStatus) &
NVREG_IRQSTAT_MASK;
- writel(NVREG_IRQSTAT_MASK, base + NvRegMSIXIrqStatus);
- }
- dprintk(KERN_DEBUG "%s: irq: %08x\n", dev->name, events);
- if (!(events & np->irqmask))
- break;
-
-
[PATCH 2/6] forcedeth: timer overhaul
commit 160511126b6be7f15da33f7cab7374b12cb5
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue Oct 16 02:22:39 2007 -0400
[netdrvr] forcedeth: timer overhaul
* remove np->in_shutdown, it mirrors netif_running()
* convert stats timer to delayed workqueue
* retrieve hw stats inside spinlock
* split out the 'stop' portions of nv_stop_rx() and nv_stop_rx(),
to enable future calling of these operations without the reg_delay()
that immediately follows.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/forcedeth.c | 135 +++-
1 file changed, 77 insertions(+), 58 deletions(-)
160511126b6be7f15da33f7cab7374b12cb5
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 2d518fc..39ade56 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -664,7 +664,7 @@ struct fe_priv {
/* General data:
* Locking: spin_lock(>lock); */
struct nv_ethtool_stats estats;
- int in_shutdown;
+
u32 linkspeed;
int duplex;
int autoneg;
@@ -705,7 +705,7 @@ struct fe_priv {
unsigned int pkt_limit;
struct timer_list oom_kick;
struct timer_list nic_poll;
- struct timer_list stats_poll;
+ struct delayed_work stats_task;
u32 nic_poll_irq;
int rx_ring_size;
@@ -1264,18 +1264,28 @@ static void nv_start_rx(struct net_device *dev)
pci_push(base);
}
-static void nv_stop_rx(struct net_device *dev)
+static void __nv_stop_rx(struct fe_priv *np)
{
- struct fe_priv *np = netdev_priv(dev);
- u8 __iomem *base = get_hwbase(dev);
+ u8 __iomem *base = np->base;
u32 rx_ctrl = readl(base + NvRegReceiverControl);
- dprintk(KERN_DEBUG "%s: nv_stop_rx\n", dev->name);
+ dprintk(KERN_DEBUG "%s: __nv_stop_rx\n", dev->name);
if (!np->mac_in_use)
rx_ctrl &= ~NVREG_RCVCTL_START;
else
rx_ctrl |= NVREG_RCVCTL_RX_PATH_EN;
writel(rx_ctrl, base + NvRegReceiverControl);
+}
+
+static void nv_stop_rx(struct net_device *dev)
+{
+ struct fe_priv *np = netdev_priv(dev);
+ u8 __iomem *base = get_hwbase(dev);
+
+ dprintk(KERN_DEBUG "%s: nv_stop_rx\n", dev->name);
+
+ __nv_stop_rx(np);
+
reg_delay(dev, NvRegReceiverStatus, NVREG_RCVSTAT_BUSY, 0,
NV_RXSTOP_DELAY1, NV_RXSTOP_DELAY1MAX,
KERN_INFO "nv_stop_rx: ReceiverStatus remained busy");
@@ -1299,18 +1309,29 @@ static void nv_start_tx(struct net_device *dev)
pci_push(base);
}
-static void nv_stop_tx(struct net_device *dev)
+static void __nv_stop_tx(struct fe_priv *np)
{
- struct fe_priv *np = netdev_priv(dev);
- u8 __iomem *base = get_hwbase(dev);
+ u8 __iomem *base = np->base;
u32 tx_ctrl = readl(base + NvRegTransmitterControl);
- dprintk(KERN_DEBUG "%s: nv_stop_tx\n", dev->name);
+ dprintk(KERN_DEBUG "%s: __nv_stop_tx\n", dev->name);
+
if (!np->mac_in_use)
tx_ctrl &= ~NVREG_XMITCTL_START;
else
tx_ctrl |= NVREG_XMITCTL_TX_PATH_EN;
writel(tx_ctrl, base + NvRegTransmitterControl);
+}
+
+static void nv_stop_tx(struct net_device *dev)
+{
+ struct fe_priv *np = netdev_priv(dev);
+ u8 __iomem *base = get_hwbase(dev);
+
+ dprintk(KERN_DEBUG "%s: nv_stop_tx\n", dev->name);
+
+ __nv_stop_tx(np);
+
reg_delay(dev, NvRegTransmitterStatus, NVREG_XMITSTAT_BUSY, 0,
NV_TXSTOP_DELAY1, NV_TXSTOP_DELAY1MAX,
KERN_INFO "nv_stop_tx: TransmitterStatus remained
busy");
@@ -1364,10 +1385,9 @@ static void nv_mac_reset(struct net_device *dev)
pci_push(base);
}
-static void nv_get_hw_stats(struct net_device *dev)
+static void __nv_get_hw_stats(struct fe_priv *np)
{
- struct fe_priv *np = netdev_priv(dev);
- u8 __iomem *base = get_hwbase(dev);
+ u8 __iomem *base = np->base;
np->estats.tx_bytes += readl(base + NvRegTxCnt);
np->estats.tx_zero_rexmt += readl(base + NvRegTxZeroReXmt);
@@ -1419,6 +1439,15 @@ static void nv_get_hw_stats(struct net_device *dev)
}
}
+static void nv_get_hw_stats(struct fe_priv *np)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ __nv_get_hw_stats(np);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
/*
* nv_get_stats: dev->get_stats function
* Get latest stats value from the nic.
@@ -1431,7 +1460,7 @@ static struct net_device_stats *nv_get_stats(struct
net_device *dev)
/* If the nic supports hw counters then retrieve latest values */
if (np->driver_data & (DEV_HAS_STATISTICS_V1|DEV_HAS_STATISTICS_V2)) {
- nv_get_hw_stats(dev);
+ nv_get_hw_stats(np);
/* copy to net_device stats */
dev->stats.tx_bytes = np->estats.tx_bytes;
@@
[PATCH 1/6] forcedeth: internal simplifications; changelog removal
commit 0aeb1f867bc76029f599f73ac757a50f7641ccc5 Author: Jeff Garzik <[EMAIL PROTECTED]> Date: Tue Oct 16 01:40:30 2007 -0400 [netdrvr] forcedeth: internal simplifications; changelog removal * remove changelog from source; its kept in git repository * consolidate descriptor version tests using nv_optimized() * consolidate NIC DMA start, stop and drain into nv_start_txrx(), nv_stop_txrx(), nv_drain_txrx() Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> drivers/net/forcedeth.c | 234 +++- 1 file changed, 74 insertions(+), 160 deletions(-) 0aeb1f867bc76029f599f73ac757a50f7641ccc5 diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c index cfbb7aa..2d518fc 100644 --- a/drivers/net/forcedeth.c +++ b/drivers/net/forcedeth.c @@ -29,90 +29,6 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * - * Changelog: - * 0.01: 05 Oct 2003: First release that compiles without warnings. - * 0.02: 05 Oct 2003: Fix bug for nv_drain_tx: do not try to free NULL skbs. - *Check all PCI BARs for the register window. - *udelay added to mii_rw. - * 0.03: 06 Oct 2003: Initialize dev->irq. - * 0.04: 07 Oct 2003: Initialize np->lock, reduce handled irqs, add printks. - * 0.05: 09 Oct 2003: printk removed again, irq status print tx_timeout. - * 0.06: 10 Oct 2003: MAC Address read updated, pff flag generation updated, - *irq mask updated - * 0.07: 14 Oct 2003: Further irq mask updates. - * 0.08: 20 Oct 2003: rx_desc.Length initialization added, nv_alloc_rx refill - *added into irq handler, NULL check for drain_ring. - * 0.09: 20 Oct 2003: Basic link speed irq implementation. Only handle the - *requested interrupt sources. - * 0.10: 20 Oct 2003: First cleanup for release. - * 0.11: 21 Oct 2003: hexdump for tx added, rx buffer sizes increased. - *MAC Address init fix, set_multicast cleanup. - * 0.12: 23 Oct 2003: Cleanups for release. - * 0.13: 25 Oct 2003: Limit for concurrent tx packets increased to 10. - *Set link speed correctly. start rx before starting - *tx (nv_start_rx sets the link speed). - * 0.14: 25 Oct 2003: Nic dependant irq mask. - * 0.15: 08 Nov 2003: fix smp deadlock with set_multicast_list during - *open. - * 0.16: 15 Nov 2003: include file cleanup for ppc64, rx buffer size - *increased to 1628 bytes. - * 0.17: 16 Nov 2003: undo rx buffer size increase. Substract 1 from - *the tx length. - * 0.18: 17 Nov 2003: fix oops due to late initialization of dev_stats - * 0.19: 29 Nov 2003: Handle RxNoBuf, detect & handle invalid mac - *addresses, really stop rx if already running - *in nv_start_rx, clean up a bit. - * 0.20: 07 Dec 2003: alloc fixes - * 0.21: 12 Jan 2004: additional alloc fix, nic polling fix. - * 0.22: 19 Jan 2004: reprogram timer to a sane rate, avoid lockup - *on close. - * 0.23: 26 Jan 2004: various small cleanups - * 0.24: 27 Feb 2004: make driver even less anonymous in backtraces - * 0.25: 09 Mar 2004: wol support - * 0.26: 03 Jun 2004: netdriver specific annotation, sparse-related fixes - * 0.27: 19 Jun 2004: Gigabit support, new descriptor rings, - *added CK804/MCP04 device IDs, code fixes - *for registers, link status and other minor fixes. - * 0.28: 21 Jun 2004: Big cleanup, making driver mostly endian safe - * 0.29: 31 Aug 2004: Add backup timer for link change notification. - * 0.30: 25 Sep 2004: rx checksum support for nf 250 Gb. Add rx reset - *into nv_close, otherwise reenabling for wol can - *cause DMA to kfree'd memory. - * 0.31: 14 Nov 2004: ethtool support for getting/setting link - *capabilities. - * 0.32: 16 Apr 2005: RX_ERROR4 handling added. - * 0.33: 16 May 2005: Support for MCP51 added. - * 0.34: 18 Jun 2005: Add DEV_NEED_LINKTIMER to all nForce nics. - * 0.35: 26 Jun 2005: Support for MCP55 added. - * 0.36: 28 Jun 2005: Add jumbo frame support. - * 0.37: 10 Jul 2005: Additional ethtool support, cleanup of pci id list - * 0.38: 16 Jul 2005: tx irq rewrite: Use global flags instead of - *per-packet flags. - * 0.39: 18 Jul 2005: Add 64bit descriptor support. - * 0.40: 19 Jul 2005: Add support for mac address change. - * 0.41: 30 Jul 2005: Write back original MAC in nv_close instead - *of nv_remove - * 0.42: 06 Aug 2005: Fix lack of
[PATCH 0/6] forcedeth interrupt and task overhaul, v2
These six changes can be found in the 'fe' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git [netdrvr] forcedeth: internal simplifications; changelog removal [netdrvr] forcedeth: timer overhaul [netdrvr] forcedeth: eliminate some duplicate irq handling code [netdrvr] forcedeth: unconditionally enable NAPI [netdrvr] forcedeth: use NAPI for TX completion [netdrvr] interrupt handling overhaul I rewrote the previous forcedeth patchset, even though the direction and methods are quite similar to the last patchset. This hammers out bugs, problems, inconsistencies, mainly with interrupt handling and locking. This moves the driver towards removing the disable_irq() usage, but does not actually take that step (yet). A few changes just went upstream, too: Ingo Molnar (1): forcedeth: fix NAPI rx poll function Jeff Garzik (2): [netdrvr] forcedeth: improved probe info; dev_printk() cleanups [netdrvr] forcedeth: remove in-driver copy of net_device_stats This patchset is diff'd against the latest linux-2.6.git as of an hour ago or so. It applies on top of the three changes listed immediately above this paragraph. At this point, it has been tested on nVidia Corporation CK804 Ethernet Controller (rev a3) but I'm definitely interested in other testing, particularly performance numbers (wire speed? or below?), CPU usage and memory usage info. Most particularly CPU usage info. And maybe interrupt count with/without this patchset, too. If you send feedback, 'dmesg' and 'lspci' output is helpful. The current forcedeth driver in upstream (0.61) prints out useful diagnostic information about your chip at bootup. - 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: LFENCE instruction (was: [rfc][patch 3/3] x86: optimise barriers)
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> Also, for non-wb memory. I don't think the Intel document referenced
> says anything about this, but the AMD document says that loads can pass
> loads (page 8, rule b).
>
> This is why our rmb() is still an lfence.
BTW, Xen (in particular, the code in drivers/xen) uses mb/rmb/wmb
instead of smp_mb/smp_rmb/smp_wmb when it accesses memory that's
shared with other Xen domains or the hypervisor.
The reason this is necessary is because even if a Xen domain is
UP the hypervisor might be SMP.
It would be nice if we can have these adopt the new SMP barriers
on x86 instead of the IO ones as they currently do.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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][resend]gx-suspmod.c use boot_cpu_data instead of current_cpu_data
in preemptible kernel will report BUG: using smp_processor_id() in
preemptible, so use boot_cpu_data instead of current_cpu_data.
discussion in :
http://lkml.org/lkml/2007/7/25/32
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/cpufreq/gx-suspmod.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -pur linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c
linux.new/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c
--- linux/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c 2007-07-25
14:11:06.0 +
+++ linux.new/arch/i386/kernel/cpu/cpufreq/gx-suspmod.c 2007-07-25
13:57:29.0 +
@@ -181,8 +181,8 @@ static __init struct pci_dev *gx_detect_
struct pci_dev *gx_pci = NULL;
/* check if CPU is a MediaGX or a Geode. */
- if ((current_cpu_data.x86_vendor != X86_VENDOR_NSC) &&
- (current_cpu_data.x86_vendor != X86_VENDOR_CYRIX)) {
+ if ((boot_cpu_data.x86_vendor != X86_VENDOR_NSC) &&
+ (boot_cpu_data.x86_vendor != X86_VENDOR_CYRIX)) {
dprintk("error: no MediaGX/Geode processor found!\n");
return NULL;
}
-
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: [RFC PATCH 1/4] Refcount Based Cpu-Hotplug Implementation
On Wed, Oct 17, 2007 at 10:47:41AM +1000, Rusty Russell wrote:
> On Tuesday 16 October 2007 20:34:17 Gautham R Shenoy wrote:
> > This patch implements a Refcount + Waitqueue based model for
> > cpu-hotplug.
>
> Hi Gautham,
Hi Rusty,
>
> I can't see where you re-initialize the completion.
The cpu_hotplug.readers_done is a global variable which has been
initialized in cpu_hotplug_init.
So I am wondering is the re-initialization required ?
>
> > +static void cpu_hotplug_begin(void)
> > +{
> > + mutex_lock(_hotplug.lock);
> > + cpu_hotplug.active_writer = current;
> > + while (cpu_hotplug.refcount) {
> > + mutex_unlock(_hotplug.lock);
> > + wait_for_completion(_hotplug.readers_done);
> > + mutex_lock(_hotplug.lock);
> > + }
>
> AFAICT this will busy-wait on the second CPU hotplug.
>
Well when the first cpu_hotplug comes out of wait_for_completion, it
would have decremented the ->done count, so it's as good as new
for the second CPU hotplug, no?
> Cheers,
> Rusty.
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
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: What still uses the block layer?
On Mon, 15 Oct 2007 03:04:00 CDT, Rob Landley said: > I note that the eth0 and eth1 names are dynamically assigned on a first come > first serve basis (like scsi). This never causes me a problem because the > driver loading order is constant, and once you figure out that eth0 is > gigabit and eth1 is the 80211g it _stays_ that way across reboots, reliably. > Yeah, it's a heuristic. Hands up everybody relying on such a heuristic in > the real world. I've gotten burned by that heuristic enough times to not rely on it. My last laptop had an ethernet on the motherboard, a *separate* ethernet in the docking station, an ethernet on a multifunction pcmcia card (I usually just used the modem side), and a wireless that looked like an ethernet - so it was possible for a given interface to be eth1 (if no dock and no pcmcia card) or eth3 (if both were present). And that's on a laptop from almost 5 years ago. And then there's the recent Sun and Dell 1U rack-mounts that have 4 ethernets on the motherboard, and they *never* seem to assign in a 0,1,2,3 order that matches the 0 1 2 3 printed above the 4 RJ45's ;) So I have for years been a proponent of 'ethN is nailed by MAC address' :) pgpjpjon3rc5T.pgp Description: PGP signature
Re: [PATCH 2/3] [kexec-tools] Pass vmcoreinfo's address and size
On Wed, 17 Oct 2007 14:16:19 +0900 "Ken'ichi Ohmichi" <[EMAIL PROTECTED]> wrote: > Simon Horman wrote: > > On Wed, Aug 22, 2007 at 09:13:39PM +0900, Ken'ichi Ohmichi wrote: > >> [2/3] [kexec-tools] Pass vmcoreinfo's address and size > >> The patch is for kexec-tools-testing-20070330. > >> (http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/) > >> kexec command gets the address and size of the vmcoreinfo data from > >> /sys/kernel/vmcoreinfo, and passes them to the second kernel through > >> ELF header of /proc/vmcore. When the second kernel is booting, the > >> kernel gets them from the ELF header and creates vmcoreinfo's PT_NOTE > >> segment into /proc/vmcore. > > > > Sorry for the long delay, I completely missed this patch. > > > > The kexec-tools change seems ok to me. What is the status of > > the kernel portion of the change? > > The kernel portion is merged into linux-2.6.23-mm1. > According to Andrew's mail "-mm merge plans for 2.6.24", its status is > "The infamous misc. Will re-review and will merge basically all of them". It's all in this evening's batch, which is going through final QA (heh) now. Is looking OK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix build breakage if !SYSFS
On Tue, Oct 16, 2007 at 08:00:44PM +0100, Ralf Baechle wrote:
> On Tue, Oct 16, 2007 at 11:10:16PM +0530, Dhaval Giani wrote:
>
> > On Tue, Oct 16, 2007 at 02:02:31PM +0100, Ralf Baechle wrote:
> > > Changeset 5cb350baf580017da38199625b7365b1763d7180 causes build breakage
> > > if sysfs support is disabled:
> > >
> > > kernel/built-in.o: In function `uids_kobject_init':
> > > (.init.text+0x1488): undefined reference to `kernel_subsys'
> > > kernel/built-in.o: In function `uids_kobject_init':
> > > (.init.text+0x1490): undefined reference to `kernel_subsys'
> > > kernel/built-in.o: In function `uids_kobject_init':
> > > (.init.text+0x1480): undefined reference to `kernel_subsys'
> > > kernel/built-in.o: In function `uids_kobject_init':
> > > (.init.text+0x1494): undefined reference to `kernel_subsys'
> > >
> > > This breaks for example mipssim_defconfig.
> > >
> > > Ralf
> >
> > Hi Ralf,
> >
> > Can you try this and confirm if it works?
>
> Yes, this solves the issue.
Hi,
Could you please include this patch to fix the build breakage?
thanks
Dhaval
--
When CONFIG_SYSFS is not set, CONFIG_FAIR_USER_SCHED fails to build
with
kernel/built-in.o: In function `uids_kobject_init':
(.init.text+0x1488): undefined reference to `kernel_subsys'
kernel/built-in.o: In function `uids_kobject_init':
(.init.text+0x1490): undefined reference to `kernel_subsys'
kernel/built-in.o: In function `uids_kobject_init':
(.init.text+0x1480): undefined reference to `kernel_subsys'
kernel/built-in.o: In function `uids_kobject_init':
(.init.text+0x1494): undefined reference to `kernel_subsys'
This patch fixes this build error.
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]>
---
include/linux/sched.h |2 ++
kernel/user.c | 23 +++
2 files changed, 17 insertions(+), 8 deletions(-)
Index: current/include/linux/sched.h
===
--- current.orig/include/linux/sched.h
+++ current/include/linux/sched.h
@@ -602,10 +602,12 @@ struct user_struct {
#ifdef CONFIG_FAIR_USER_SCHED
struct task_group *tg;
+#ifdef CONFIG_SYSFS
struct kset kset;
struct subsys_attribute user_attr;
struct work_struct work;
#endif
+#endif
};
#ifdef CONFIG_FAIR_USER_SCHED
Index: current/kernel/user.c
===
--- current.orig/kernel/user.c
+++ current/kernel/user.c
@@ -87,9 +87,6 @@ static inline struct user_struct *uid_ha
#ifdef CONFIG_FAIR_USER_SCHED
-static struct kobject uids_kobject; /* represents /sys/kernel/uids directory */
-static DEFINE_MUTEX(uids_mutex);
-
static void sched_destroy_user(struct user_struct *up)
{
sched_destroy_group(up->tg);
@@ -111,6 +108,19 @@ static void sched_switch_user(struct tas
sched_move_task(p);
}
+#else /* CONFIG_FAIR_USER_SCHED */
+
+static void sched_destroy_user(struct user_struct *up) { }
+static int sched_create_user(struct user_struct *up) { return 0; }
+static void sched_switch_user(struct task_struct *p) { }
+
+#endif /* CONFIG_FAIR_USER_SCHED */
+
+#if defined(CONFIG_FAIR_USER_SCHED) && defined(CONFIG_SYSFS)
+
+static struct kobject uids_kobject; /* represents /sys/kernel/uids directory */
+static DEFINE_MUTEX(uids_mutex);
+
static inline void uids_mutex_lock(void)
{
mutex_lock(_mutex);
@@ -257,11 +267,8 @@ static inline void free_user(struct user
schedule_work(>work);
}
-#else /* CONFIG_FAIR_USER_SCHED */
+#else /* CONFIG_FAIR_USER_SCHED && CONFIG_SYSFS */
-static void sched_destroy_user(struct user_struct *up) { }
-static int sched_create_user(struct user_struct *up) { return 0; }
-static void sched_switch_user(struct task_struct *p) { }
static inline int user_kobject_create(struct user_struct *up) { return 0; }
static inline void uids_mutex_lock(void) { }
static inline void uids_mutex_unlock(void) { }
@@ -280,7 +287,7 @@ static inline void free_user(struct user
kmem_cache_free(uid_cachep, up);
}
-#endif /* CONFIG_FAIR_USER_SCHED */
+#endif
/*
* Locate the user_struct for the passed UID. If found, take a ref on it. The
--
regards,
Dhaval
-
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] /proc Security Hooks
On Wed, 17 Oct 2007 07:13:57 +0200 Max Kellermann <[EMAIL PROTECTED]> wrote: > On 2007/10/16 21:54, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > On Tue, 16 Oct 2007 21:38:50 +0200 > > Max Kellermann <[EMAIL PROTECTED]> wrote: > > > This patch attempts to unify duplicated code found in modules like > > > Linux VServer. > > > > can you please merge this patch only when you also merge the first > > user > > of it? That's the only way we can keep the LSM hooks sane... is to > > see > > them in thew conect of a user. > > I wrote a module which uses this, but it's non-free and only used on > my employer's servers. But I could have a closer look at the Vserver > code and try to make it use my patch. doesn't sound like something we'd want overhead for in the generic 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 2/3] [kexec-tools] Pass vmcoreinfo's address and size
Hi Simon, Simon Horman wrote: > On Wed, Aug 22, 2007 at 09:13:39PM +0900, Ken'ichi Ohmichi wrote: >> [2/3] [kexec-tools] Pass vmcoreinfo's address and size >> The patch is for kexec-tools-testing-20070330. >> (http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/) >> kexec command gets the address and size of the vmcoreinfo data from >> /sys/kernel/vmcoreinfo, and passes them to the second kernel through >> ELF header of /proc/vmcore. When the second kernel is booting, the >> kernel gets them from the ELF header and creates vmcoreinfo's PT_NOTE >> segment into /proc/vmcore. > > Sorry for the long delay, I completely missed this patch. > > The kexec-tools change seems ok to me. What is the status of > the kernel portion of the change? The kernel portion is merged into linux-2.6.23-mm1. According to Andrew's mail "-mm merge plans for 2.6.24", its status is "The infamous misc. Will re-review and will merge basically all of them". http://www.ussg.iu.edu/hypermail/linux/kernel/0710.0/0313.html > Do you still want the kexec-tools portion applied? Yes, I hope so. Thanks Ken'ichi Ohmichi - 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/
mtd: onenand_sim crashes
on x86_64, 2.6.23-git7, no MTD devices. Same config file as mtd crash a few minutes earlier. loading onenand_sim a _second_ time crashes: OneNAND Manufacturer: Samsung (0xec) OneNAND 16MB 1.8V 16-bit (0x04) OneNAND version = 0x001e Lock scheme is Continuous Lock Scanning device for bad blocks Creating 1 MTD partitions on "OneNAND simulator": 0x-0x0100 : "OneNAND simulator partition" mtd: Giving out device 0 to OneNAND simulator partition [ cut here ] kernel BUG at mm/slab.c:2983! invalid opcode: [1] SMP CPU 0 Modules linked in: hidp l2cap bluetooth snd_via82xx snd_ac97_codec ac97_bus snd_seq_dummy s nd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_ alloc snd_mpu401_uart parport snd_rawmidi snd_seq_device snd soundcore Pid: 3676, comm: bash Not tainted 2.6.23-git7 #11 RIP: 0010:[] [] cache_alloc_refill+0xcc/0x1b3 RSP: 0018:81002f199e18 EFLAGS: 00010046 RAX: 0004 RBX: 0006 RCX: 8100010ff8a0 RDX: 81003e7c0800 RSI: 8100010ff880 RDI: 81003d545680 RBP: 81002f199e68 R08: 8100010ff880 R09: 810037ff4000 R10: 8028a15c R11: 0202 R12: 81003d545680 R13: 810037ff1a00 R14: 8100010ff880 R15: 000a FS: 2b8d51d76f10() GS:806b4000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 008e1f28 CR3: 30508000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process bash (pid: 3676, threadinfo 81002f198000, task 81002fc5c040) Stack: 81002fc5c040 80d0806708d8 81003e7c0800 8100010ff8c0 0246 0246 80d0 81003e7c0800 81002f199e98 8028a42b Call Trace: [] kmem_cache_alloc+0x8c/0xd1 [] alloc_pipe_info+0x1b/0x48 [] create_write_pipe+0x5d/0x1b5 [] do_pipe+0x1a/0x105 [] sys_pipe+0x1c/0x4b [] tracesys+0x71/0xe1 [] tracesys+0xdc/0xe1 Code: 0f 0b eb fe 41 8b 5d 00 8b 55 d4 4c 89 e6 48 8b 7d c0 e8 1e RIP [] cache_alloc_refill+0xcc/0x1b3 RSP BUG: spinlock lockup on CPU#0, events/0/6, 8100010ff8c0 Call Trace: [] _raw_spin_lock+0xd1/0xf9 [] _spin_lock_irq+0x47/0x54 [] drain_array+0x4e/0xc9 [] cache_reap+0x0/0x20a [] cache_reap+0xad/0x20a [] cache_reap+0x0/0x20a [] run_workqueue+0x97/0x16a [] worker_thread+0x0/0xea [] worker_thread+0xdf/0xea [] autoremove_wake_function+0x0/0x38 [] kthread+0x49/0x78 [] child_rip+0xa/0x12 [] kthreadd+0x120/0x145 [] kthread+0x0/0x78 [] child_rip+0x0/0x12 --- ~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/
[PATCH] Better document profile=
Be more explicit on what the step/bucket size accomplishes. Signed-off-by: Russ Dill <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index eb24799..3c6fd27 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1427,7 +1427,10 @@ and is between 256 and 4096 characters. It is defined in the file Format: [schedule,] Param: "schedule" - profile schedule points. Param: - step/bucket size as a power of 2 for - statistical time based profiling. + statistical time based profiling. A value of + 2 will provide a granularity of 4 bytes, a + value of 3 will provide a granularity of 8 + bytes and so on. Param: "sleep" - profile D-state sleeping (millisecs) processor.max_cstate= [HW,ACPI] -- 1.5.2.5 - 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: mtd: pnc2000 module crashes
>On 10/17/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > 2.6.23-git7, on x86_64, no MTD devices: > > modprobe pnc2000 crashes like so: > > Photron PNC-2000 flash mapping: 40 at bf00 > Unable to handle kernel paging request at bf00 RIP: > [] :map_funcs:simple_map_write+0x54/0x82 > PGD 3476f067 PUD 0 > Oops: 0002 [1] SMP > CPU 0 > Modules linked in: cfi_probe gen_probe pnc2000 mtd chipreg map_funcs hidp > l2cap bluetooth snd_via82xx snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss > snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_timer > snd_page_alloc snd_mpu401_uart parport_pc ohci1394 parport snd_rawmidi > ieee1394 snd_seq_device shpchp snd soundcore pci_hotplug > Pid: 4027, comm: modprobe Not tainted 2.6.23-git7 #11 > RIP: 0010:[] [] > :map_funcs:simple_map_write+0x54/0x82 > RSP: 0018:81002ec9f828 EFLAGS: 00010206 > RAX: f0f0f0f0 RBX: 0008 RCX: > RDX: 0004 RSI: 81002ec9f878 RDI: 81002ec9f848 > RBP: 81002ec9f848 R08: bf00 R09: 880e35a0 > R10: 0004 R11: 0002 R12: > R13: 880e35a0 R14: R15: 81002ec9fd68 > FS: 2ac0707cf6f0() GS:806b4000() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: bf00 CR3: 2f5ea000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process modprobe (pid: 4027, threadinfo 81002ec9e000, task > 81002ec269c0) > Stack: f0f0f0f0 > 81002ec9fd28 8810b5ce f0f0f0f0 > 81002ec9f898 > Call Trace: > [] :cfi_probe:cfi_probe_chip+0x17f/0x1379 > [] get_page_from_freelist+0x38b/0x4d4 > [] __lock_acquire+0x3ed/0x6af > [] __lock_acquire+0x3ed/0x6af > [] lock_release_holdtime+0x45/0x4a > [] update_curr+0xf8/0x119 > [] enqueue_entity+0x24a/0x279 > [] lock_release_holdtime+0x45/0x4a > [] __lock_acquire+0x3ed/0x6af > [] lock_release_holdtime+0x45/0x4a > [] kprobe_flush_task+0x63/0xa9 > [] __mmdrop+0x87/0x90 > [] __lock_acquire+0x3ed/0x6af > [] lock_release_holdtime+0x45/0x4a > [] __wake_up+0x43/0x50 > [] request_module+0x14b/0x162 > [] vprintk+0x2bd/0x2ff > [] :gen_probe:mtd_do_chip_probe+0x7f/0x35c > [] __lock_acquire+0x3ed/0x6af > [] lock_release_holdtime+0x45/0x4a > [] _spin_unlock+0x26/0x2a > [] :cfi_probe:cfi_probe+0x10/0x12 > [] :chipreg:do_map_probe+0x4a/0x66 > [] :pnc2000:init_pnc2000+0x3b/0x6d > [] sys_init_module+0x146c/0x15cd > [] :map_funcs:simple_map_init+0x0/0x4b > [] syscall_trace_enter+0x95/0x99 > [] tracesys+0xdc/0xe1 > > > Code: 41 89 00 eb 24 83 fa 08 75 0d 4d 03 41 18 48 8b 45 e0 49 89 > RIP [] :map_funcs:simple_map_write+0x54/0x82 > RSP > CR2: bf00 > Possible reason : it's iomem region is not be remaped. I have reported this bug, but get no response. http://lkml.org/lkml/2007/8/1/83 Regards dave > > config file is attached. > > --- > ~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] /proc Security Hooks
On 2007/10/16 21:54, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Tue, 16 Oct 2007 21:38:50 +0200 > Max Kellermann <[EMAIL PROTECTED]> wrote: > > This patch attempts to unify duplicated code found in modules like > > Linux VServer. > > can you please merge this patch only when you also merge the first > user > of it? That's the only way we can keep the LSM hooks sane... is to > see > them in thew conect of a user. I wrote a module which uses this, but it's non-free and only used on my employer's servers. But I could have a closer look at the Vserver code and try to make it use my patch. > > +#ifdef CONFIG_SECURITY_PROC > > + if (security_proc_task(task) != 0) > > +continue; > > +#endif > > please don't use an ifdef like this; just make security_proc_task() > be > a define to 0 in the header for that CONFIG_ .. > In addition, why is this a separate config option? LSM should really > only be one big switch... microswitches like this don't make any > sense. Right, I initially wrote this patch some time ago when linux/security.h didn't have an "#ifdef CONFIG_SECURITY". I'll adapt that. > > +#ifdef CONFIG_SECURITY_PROC > > + if (security_proc_generic(de) != 0) > > + > > goto skip; > > +#endif > > as does this one... but the goto looks horrid to me I'm all against gotos, but seeing gotos all over the kernel, and my code being in an #ifdef, this one goto looked "normal" to me. You're right, I should change it. Max - 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] [275/2many] MAINTAINERS - KDUMP
On Wed, 2007-10-17 at 12:48 +0900, Simon Horman wrote: > Do you have a criteria for including files. A file or file pattern specific to a maintained "subsystem". Any time a subsystem file pattern matches a file, maintainers would be cc'd. The matching is non-exclusive. Multiple subsystems can include the same file pattern. For KDUMP, maybe a file pattern should be: F: arch/*/kernel/crash_dump.c F: include/linux/crash_dump.h > Are they files that only apply to KEXEC/KDUMP, > or files that have KEXEC/KDUMP code and other code? I think it should be files specific to KDUMP and not files shared with other subsystems but perhaps it's maintainer taste. If the files patterns are not specific to kdump, the kdump maintainers will be cc'd on patches that change files where kdump functions aren't modified. The list of files that include crash_dump.h is pretty long. $ grep -P -l -r --include=*.[ch] crash_dump.h * arch/i386/kernel/crash_dump.c arch/i386/kernel/setup.c arch/ia64/hp/common/sba_iommu.c arch/ia64/kernel/crash.c arch/ia64/kernel/setup.c arch/powerpc/kernel/crash.c arch/powerpc/kernel/crash_dump.c arch/sh/kernel/crash_dump.c arch/x86_64/kernel/crash_dump.c arch/x86_64/kernel/setup.c drivers/char/mem.c fs/proc/proc_misc.c fs/proc/vmcore.c The list of files that use CONFIG_CRASH_DUMP is also pretty long and seemingly unrelated. $ grep -P -l -r --include=*.[ch] CONFIG_CRASH_DUMP * arch/i386/kernel/apic.c arch/i386/kernel/e820.c arch/ia64/hp/common/sba_iommu.c arch/ia64/kernel/efi.c arch/powerpc/kernel/iommu.c arch/powerpc/platforms/cell/ras.c arch/powerpc/platforms/pseries/iommu.c arch/x86_64/kernel/e820.c drivers/char/mem.c include/asm-powerpc/kdump.h include/linux/bootmem.h include/linux/crash_dump.h mm/bootmem.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/
[PATCH] SPARC64: fix iommu sg chaining
Commit 2c941a204070ab32d92d40318a3196a7fb994c00 looks incomplete. The
helper functions like prepare_sg() need to support sg chaining too.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
arch/sparc64/kernel/iommu.c|1 -
arch/sparc64/kernel/iommu_common.c | 51 +---
arch/sparc64/kernel/iommu_common.h |1 +
arch/sparc64/kernel/pci_sun4v.c|1 -
4 files changed, 31 insertions(+), 23 deletions(-)
diff --git a/arch/sparc64/kernel/iommu.c b/arch/sparc64/kernel/iommu.c
index db3ffcf..5d4e96d 100644
--- a/arch/sparc64/kernel/iommu.c
+++ b/arch/sparc64/kernel/iommu.c
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
#ifdef CONFIG_PCI
#include
diff --git a/arch/sparc64/kernel/iommu_common.c
b/arch/sparc64/kernel/iommu_common.c
index 12c93a3..d7ca900 100644
--- a/arch/sparc64/kernel/iommu_common.c
+++ b/arch/sparc64/kernel/iommu_common.c
@@ -12,18 +12,22 @@
*/
#ifdef VERIFY_SG
-static int verify_lengths(struct scatterlist *sg, int nents, int npages)
+static int verify_lengths(struct scatterlist *sglist, int nents, int npages)
{
int sg_len, dma_len;
int i, pgcount;
+ struct scatterlist *sg;
sg_len = 0;
- for (i = 0; i < nents; i++)
- sg_len += sg[i].length;
+ for_each_sg(sglist, sg, nents, i)
+ sg_len += sg->length;
dma_len = 0;
- for (i = 0; i < nents && sg[i].dma_length; i++)
- dma_len += sg[i].dma_length;
+ for_each_sg(sglist, sg, nents, i) {
+ if (!sg->dma_length)
+ break;
+ dma_len += sg->dma_length;
+ }
if (sg_len != dma_len) {
printk("verify_lengths: Error, different, sg[%d] dma[%d]\n",
@@ -32,13 +36,16 @@ static int verify_lengths(struct scatterlist *sg, int
nents, int npages)
}
pgcount = 0;
- for (i = 0; i < nents && sg[i].dma_length; i++) {
+ for_each_sg(sglist, sg, nents, i) {
unsigned long start, end;
- start = sg[i].dma_address;
+ if (!sg->dma_length)
+ break;
+
+ start = sg->dma_address;
start = start & IO_PAGE_MASK;
- end = sg[i].dma_address + sg[i].dma_length;
+ end = sg->dma_address + sg->dma_length;
end = (end + (IO_PAGE_SIZE - 1)) & IO_PAGE_MASK;
pgcount += ((end - start) >> IO_PAGE_SHIFT);
@@ -113,7 +120,7 @@ static int verify_one_map(struct scatterlist *dma_sg,
struct scatterlist **__sg,
if (dlen > 0 && ((daddr & ~IO_PAGE_MASK) == 0))
iopte++;
- sg++;
+ sg = sg_next(sg);
if (--nents <= 0)
break;
sgaddr = (unsigned long) (page_address(sg->page) + sg->offset);
@@ -147,7 +154,7 @@ static int verify_maps(struct scatterlist *sg, int nents,
iopte_t *iopte)
nents = verify_one_map(dma_sg, , nents, );
if (nents <= 0)
break;
- dma_sg++;
+ dma_sg = sg_next(dma_sg);
if (dma_sg->dma_length == 0)
break;
}
@@ -169,22 +176,24 @@ static int verify_maps(struct scatterlist *sg, int nents,
iopte_t *iopte)
return 0;
}
-void verify_sglist(struct scatterlist *sg, int nents, iopte_t *iopte, int
npages)
+void verify_sglist(struct scatterlist *sglist, int nents, iopte_t *iopte, int
npages)
{
- if (verify_lengths(sg, nents, npages) < 0 ||
- verify_maps(sg, nents, iopte) < 0) {
+ struct scatterlist *sg;
+
+ if (verify_lengths(sglist, nents, npages) < 0 ||
+ verify_maps(sglist, nents, iopte) < 0) {
int i;
printk("verify_sglist: Crap, messed up mappings, dumping, iodma
at ");
- printk("%016lx.\n", sg->dma_address & IO_PAGE_MASK);
+ printk("%016lx.\n", sglist->dma_address & IO_PAGE_MASK);
- for (i = 0; i < nents; i++) {
+ for_each_sg(sglist, sg, nents, i) {
printk("sg(%d): page_addr(%p) off(%x) length(%x) "
- "dma_address[%016lx] dma_length[%016lx]\n",
+ "dma_address[%016x] dma_length[%016x]\n",
i,
- page_address(sg[i].page), sg[i].offset,
- sg[i].length,
- sg[i].dma_address, sg[i].dma_length);
+ page_address(sg->page), sg->offset,
+ sg->length,
+ sg->dma_address, sg->dma_length);
}
}
@@ -205,12 +214,12 @@ unsigned long prepare_sg(struct scatterlist *sg, int
nents)
while (--nents) {
unsigned long addr;
- sg++;
+
Re: [GIT PULL] ext4 update
On Wed, 17 Oct 2007, Theodore Ts'o wrote: Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git for_linus It has a number random cleanups and bug fixes, and two new features. The first is uninitialized block groups, which allows fast mke2fs operations plus as well as speeding up e2fsck by allowing it to skip parts of the inode tables that haven't been used yet. nice feature, is there any work on a tool to go through a well-used filesystem and mark unused block groups as uninitialized? (I would guess that such a tool may want to move files to make this so) David Lang A checksum has been added to block group descriptors so we can tell detect corruption in that data structure, since we are depending on it being accurate so we know what portion of the inode table is really in use. The second feature is flexible block groups, which allows inode tables and block/inode bitmaps to be grouped together outside of the block group that they administer, to allow contiguous regions of data blocks to span multiple block groups, which helps for large files significantly bigger than the size of a block group (i.e., 32 gigabytes on a 4k block filesystem). All of these patches have been baking in -mm for a while. Regards, - Ted Andreas Dilger (1): Ext4: Uninitialized Block Groups Aneesh Kumar K.V (8): ext4: Fix sparse warnings ext4: Convert bg_block_bitmap to bg_block_bitmap_lo ext4: Convert bg_inode_bitmap and bg_inode_table ext4: Convert s_blocks_count to s_blocks_count_lo ext4: Convert s_r_blocks_count and s_free_blocks_count ext4: Convert ext4_extent.ee_start to ext4_extent.ee_start_lo ext4: Convert ext4_extent_idx.ei_leaf to ext4_extent_idx.ei_leaf_lo ext4: sparse fixes Coly Li (1): ext4: Remove (partial, never completed) fragment support Eric Sandeen (3): ext4: remove #ifdef CONFIG_EXT4_INDEX ext4: fix setup_new_group_blocks locking ext4: lighten up resize transaction requirements Jan Kara (1): jbd2: fix commit code to properly abort journal Jose R. Santos (2): JBD2: debug code cleanup. ext4: FLEX_BG Kernel support v2. Mingming Cao (6): JBD: JBD slab allocation cleanups JBD2: jbd2 slab allocation cleanups JBD: replace jbd_kmalloc with kmalloc directly JBD2: replace jbd_kmalloc with kmalloc directly. JBD2/Ext4: Convert kmalloc to kzalloc in jbd2/ext4 jbd2: JBD_XXX to JBD2_XXX naming cleanup fs/Kconfig |1 + fs/ext4/balloc.c| 112 - fs/ext4/dir.c |7 -- fs/ext4/extents.c | 14 ++-- fs/ext4/fsync.c |2 +- fs/ext4/group.h | 27 +++ fs/ext4/ialloc.c| 151 +++ fs/ext4/inode.c | 18 ++ fs/ext4/namei.c | 20 - fs/ext4/resize.c| 59 +++- fs/ext4/super.c | 97 + fs/ext4/xattr.c |7 +- fs/jbd/commit.c |6 +- fs/jbd/journal.c| 99 ++ fs/jbd/transaction.c| 12 ++-- fs/jbd2/commit.c| 16 ++-- fs/jbd2/journal.c | 128 - fs/jbd2/recovery.c |2 +- fs/jbd2/revoke.c|4 +- fs/jbd2/transaction.c | 19 +++--- include/linux/ext4_fs.h | 103 ++ include/linux/ext4_fs_extents.h |4 +- include/linux/ext4_fs_i.h |5 -- include/linux/ext4_fs_sb.h |3 - include/linux/ext4_jbd2.h |6 +- include/linux/jbd.h | 17 +++-- include/linux/jbd2.h| 49 +++-- include/linux/poison.h |3 +- 28 files changed, 527 insertions(+), 464 deletions(-) create mode 100644 fs/ext4/group.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/ - 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: [RFC patch] fallback to "no irq" hack for case of no pnp_irq allocated for 8250_pnp
On Wed, Oct 17, 2007 at 10:50:53AM +0800, Luming Yu wrote: > There is a "ttyS1 irq is -1" problem observed on tiger4 which cause > the serial port broken. > It is because that there is __no__ ACPI IRQ resource assigned for the > serial port. So the value of the IRQ for the port is never changed > since it got initialized to -1. The attached patch falls back to the > "no irq" hack for this case. It works for me. Please review and test. Seems reasonable to me. Although arguably pnp_irq is broken, since Linus has decreed that 0 means no irq on Linux. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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: Fix to "All wake-up devices are disabled after suspend-to disk" isn't yet included in mainline
On Wednesday 17 October 2007 05:48:02 Andrew Morton wrote: > On Wed, 17 Oct 2007 04:39:30 +0200 Maxim Levitsky <[EMAIL PROTECTED]> wrote: > > > A while ago I asked on LKML about the problem of loosing all wake device > > capabilities, after a suspend to disk > > (eg: I can't wake the system from keyboard if I suspend to disk and then to > > ram) > > > > I was provided with the patch that fixes this problem completely. > > The merge window is open, but I still don't see it in the kernel. > > Due to changes it doesn't anymore apply to latest git. > > > > Was it missed? > > No, it's in Len's git tree. > > Len's git-pull request from a few days ago didn't work, perhaps because I > wanted to know if a recent -mm regression had been fixed and that hasn't > been answered yet. I assume that Len is offline. Other acpi developers > could presumably have answered that question but for some reason chose not to. > > I'm presently holding off 20-odd power management patches due to their > dependency upon an acpi merge... > Thanks a lot. Best regards, Maxim Levitsky - 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/
[GIT PULL] ext4 update
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git for_linus It has a number random cleanups and bug fixes, and two new features. The first is uninitialized block groups, which allows fast mke2fs operations plus as well as speeding up e2fsck by allowing it to skip parts of the inode tables that haven't been used yet. A checksum has been added to block group descriptors so we can tell detect corruption in that data structure, since we are depending on it being accurate so we know what portion of the inode table is really in use. The second feature is flexible block groups, which allows inode tables and block/inode bitmaps to be grouped together outside of the block group that they administer, to allow contiguous regions of data blocks to span multiple block groups, which helps for large files significantly bigger than the size of a block group (i.e., 32 gigabytes on a 4k block filesystem). All of these patches have been baking in -mm for a while. Regards, - Ted Andreas Dilger (1): Ext4: Uninitialized Block Groups Aneesh Kumar K.V (8): ext4: Fix sparse warnings ext4: Convert bg_block_bitmap to bg_block_bitmap_lo ext4: Convert bg_inode_bitmap and bg_inode_table ext4: Convert s_blocks_count to s_blocks_count_lo ext4: Convert s_r_blocks_count and s_free_blocks_count ext4: Convert ext4_extent.ee_start to ext4_extent.ee_start_lo ext4: Convert ext4_extent_idx.ei_leaf to ext4_extent_idx.ei_leaf_lo ext4: sparse fixes Coly Li (1): ext4: Remove (partial, never completed) fragment support Eric Sandeen (3): ext4: remove #ifdef CONFIG_EXT4_INDEX ext4: fix setup_new_group_blocks locking ext4: lighten up resize transaction requirements Jan Kara (1): jbd2: fix commit code to properly abort journal Jose R. Santos (2): JBD2: debug code cleanup. ext4: FLEX_BG Kernel support v2. Mingming Cao (6): JBD: JBD slab allocation cleanups JBD2: jbd2 slab allocation cleanups JBD: replace jbd_kmalloc with kmalloc directly JBD2: replace jbd_kmalloc with kmalloc directly. JBD2/Ext4: Convert kmalloc to kzalloc in jbd2/ext4 jbd2: JBD_XXX to JBD2_XXX naming cleanup fs/Kconfig |1 + fs/ext4/balloc.c| 112 - fs/ext4/dir.c |7 -- fs/ext4/extents.c | 14 ++-- fs/ext4/fsync.c |2 +- fs/ext4/group.h | 27 +++ fs/ext4/ialloc.c| 151 +++ fs/ext4/inode.c | 18 ++ fs/ext4/namei.c | 20 - fs/ext4/resize.c| 59 +++- fs/ext4/super.c | 97 + fs/ext4/xattr.c |7 +- fs/jbd/commit.c |6 +- fs/jbd/journal.c| 99 ++ fs/jbd/transaction.c| 12 ++-- fs/jbd2/commit.c| 16 ++-- fs/jbd2/journal.c | 128 - fs/jbd2/recovery.c |2 +- fs/jbd2/revoke.c|4 +- fs/jbd2/transaction.c | 19 +++--- include/linux/ext4_fs.h | 103 ++ include/linux/ext4_fs_extents.h |4 +- include/linux/ext4_fs_i.h |5 -- include/linux/ext4_fs_sb.h |3 - include/linux/ext4_jbd2.h |6 +- include/linux/jbd.h | 17 +++-- include/linux/jbd2.h| 49 +++-- include/linux/poison.h |3 +- 28 files changed, 527 insertions(+), 464 deletions(-) create mode 100644 fs/ext4/group.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: [GIT PATCH] SCSI updates for 2.6.24
On Mon, 15 Oct 2007 00:09:41 -0400 James Bottomley <[EMAIL PROTECTED]> wrote: > This is the accumulated updates queued for 2.6.24. It contains the > usual slew of driver updates, plus some gdth and advansys rewrites. We > still have some outstanding bugs in gdth and fc4 for which I'm hoping to > sweep fixes into the next update. > > The patch is available here: > > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git > > The short changelog is: (snip) > James Bottomley (4): > Fix device not ready printk > sg: use idr to replace static arrays > move ULD attachment into the prep function > arcmsr: fix compile problems The patch to beautify supported_mode and active_mode in sysfs? http://marc.info/?l=linux-kernel=119077857701415=2 - 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] setup vma->vm_page_prot by vm_get_page_prot()
This patch uses vm_get_page_prot() to setup vma->vm_page_prot.
use-vm_read-write-exec-to-set-vm_page_prot.patch just only replaces "& 0x7"
with "&
(VM_READ|VM_WRITE|VM_EXEC)". This is a non-unified method, because there is a
vm_get_page_prot() in
mm/mmap.c and exported to kerenl.
Though inside vm_get_page_prot() the protection flags is AND with
(VM_READ|VM_WRITE|VM_EXEC|VM_SHARED), it does not hurt correct code.
This patch can replace use-vm_read-write-exec-to-set-vm_page_prot.patch.
Signed-off-by: Coly Li <[EMAIL PROTECTED]>
Cc: Hugh Dickins <[EMAIL PROTECTED]>
Cc: Tony Luck <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
---
arch/ia64/mm/init.c |2 +-
fs/exec.c |2 +-
mm/mmap.c | 11 ---
mm/mprotect.c |6 ++
4 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index c14abef..4065280 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -130,8 +130,8 @@ ia64_init_addr_space (void)
vma->vm_mm = current->mm;
vma->vm_start = current->thread.rbs_bot & PAGE_MASK;
vma->vm_end = vma->vm_start + PAGE_SIZE;
- vma->vm_page_prot = protection_map[VM_DATA_DEFAULT_FLAGS & 0x7];
vma->vm_flags = VM_DATA_DEFAULT_FLAGS|VM_GROWSUP|VM_ACCOUNT;
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
down_write(>mm->mmap_sem);
if (insert_vm_struct(current->mm, vma)) {
up_write(>mm->mmap_sem);
diff --git a/fs/exec.c b/fs/exec.c
index 073b0b8..2794fee 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -260,7 +260,7 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
vma->vm_start = vma->vm_end - PAGE_SIZE;
vma->vm_flags = VM_STACK_FLAGS;
- vma->vm_page_prot = protection_map[vma->vm_flags & 0x7];
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
err = insert_vm_struct(mm, vma);
if (err) {
up_write(>mmap_sem);
diff --git a/mm/mmap.c b/mm/mmap.c
index 0d40e66..57f5628 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1049,8 +1049,7 @@ int vma_wants_writenotify(struct vm_area_struct *vma)
/* The open routine did something to the protections already? */
if (pgprot_val(vma->vm_page_prot) !=
- pgprot_val(protection_map[vm_flags &
- (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]))
+ pgprot_val(vm_get_page_prot(vm_flags)))
return 0;
/* Specialty mapping? */
@@ -1131,8 +1130,7 @@ munmap_back:
vma->vm_start = addr;
vma->vm_end = addr + len;
vma->vm_flags = vm_flags;
- vma->vm_page_prot = protection_map[vm_flags &
- (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
+ vma->vm_page_prot = vm_get_page_prot(vm_flags);
vma->vm_pgoff = pgoff;
if (file) {
@@ -2003,8 +2001,7 @@ unsigned long do_brk(unsigned long addr, unsigned long
len)
vma->vm_end = addr + len;
vma->vm_pgoff = pgoff;
vma->vm_flags = flags;
- vma->vm_page_prot = protection_map[flags &
- (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
+ vma->vm_page_prot = vm_get_page_prot(flags);
vma_link(mm, vma, prev, rb_link, rb_parent);
out:
mm->total_vm += len >> PAGE_SHIFT;
@@ -2210,7 +2207,7 @@ int install_special_mapping(struct mm_struct *mm,
vma->vm_end = addr + len;
vma->vm_flags = vm_flags | mm->def_flags;
- vma->vm_page_prot = protection_map[vma->vm_flags & 7];
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
vma->vm_ops = _mapping_vmops;
vma->vm_private_data = pages;
diff --git a/mm/mprotect.c b/mm/mprotect.c
index e8346c3..d21c358 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -193,11 +193,9 @@ success:
* held in write mode.
*/
vma->vm_flags = newflags;
- vma->vm_page_prot = protection_map[newflags &
- (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
+ vma->vm_page_prot = vm_get_page_prot(newflags);
if (vma_wants_writenotify(vma)) {
- vma->vm_page_prot = protection_map[newflags &
- (VM_READ|VM_WRITE|VM_EXEC)];
+ vma->vm_page_prot = vm_get_page_prot(newflags);
dirty_accountable = 1;
}
--
Coly Li
SuSE PRC Labs
-
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: [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit.
On Tue, Oct 16, 2007 at 07:23:38PM -0700, Linus Torvalds wrote: > > > On Wed, 17 Oct 2007, Dipankar Sarma wrote: > > > > Unless I am reading the patch wrongly, it seems cpu_hotplug_begin() is > > called > > while holding the cpu_add_remove_lock mutex. So, another CPU cannot come in > > and do the same until _cpu_down() is over. > > Ahh, in that case I take back that objection, although maybe a comment > about the required nesting within the other mutex is in order? Or maybe > it's there and I just missed it (blush). Good point! I'll add the comment before cpu_hotplug_begin(). > > Linus Thanks and Regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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] swsusp: Use platform mode by default
On Wed, Oct 17, 2007 at 10:46:12AM +0800, Qi Yong wrote: > On 12/05/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > On Fri, 11 May 2007, Rafael J. Wysocki wrote: > > > > > > We're working on fixing the breakage, but currently it's difficult, > > > because > > > none of my testboxes has problems with the 'platform' hibernation and I > > > cannot reproduce the reported issues. > > > > The rule for anything ACPI-related has been: no regressions. > > > > It doesn't matter if something fixes 10 boxes, if it breaks a single one, > > it's going to get reverted. > > > > We had much too much of the "two steps forward, one step back" dance with > > ACPI a few years ago, which is the reason that rule got installed (and > > which is why it's ACPI-only: in some other subsystems we accept the fact > > that sometimes we don't know how to fix some hardware issue, but the new > > situation is at least better than the old one). > > > > I agree that it can be aggravating to know that you can fix a problem for > > some people, but then being limited by the fact that it breaks for others. > > But beign able to *rely* on something that used to work is just too > > important, and with ACPI, you can never make a good judgement of which way > > works better (since it really just depends on some random firmware issues > > that we have zero visibility into). > > > > Also, quite often, it may *seem* like something fixes more boxes than it > > breaks, but it's because people report *breakage* only, and then a few > > months later it turns out that it's exactly the other way around: now it's > > a hundred people who report breakage with the *new* code, and the reason > > people thought it fixed more than it broke was that the people for whom > > the old code worked fine obviously never reported it! > > > > So this is why "a single regression is considered more important than ten > > fixes" - because a single regressionr report tends to actually be just the > > first indication of a lot of people who simply haven't tested the new code > > yet! People for whom the old code is broken are more likely to test new > > things. > > > > So I'd just suggest changing the default back to PM_DISK_SHUTDOWN (but > > leave the "pm_ops->enter" testing in place - ie not reverting the other > > commits in the series). > > > > The patch would look something like this. Coywolf, does this fix it for > > you? > > > > Yes, it fixes my problem. > > (Sorry for this long delayed report. I didn't get the chance to test > and reboot my box.) > > This quick test explains me the problem that we should not set > hibernation_mode to HIBERNATION_PLATFORM if it is not !ops". I will > post a formal patch later. > > diff --git a/kernel/power/disk.c b/kernel/power/disk.c > index eb72255..8e52553 100644 > --- a/kernel/power/disk.c > +++ b/kernel/power/disk.c > @@ -62,7 +62,7 @@ void hibernation_set_ops(struct hibernation_ops *ops) > mutex_lock(_mutex); > hibernation_ops = ops; > if (ops) > - hibernation_mode = HIBERNATION_PLATFORM; > + ; > else if (hibernation_mode == HIBERNATION_PLATFORM) > hibernation_mode = HIBERNATION_SHUTDOWN; please apply. Signed-off-by: Qi Yong <[EMAIL PROTECTED]> --- diff --git a/kernel/power/disk.c b/kernel/power/disk.c index eb72255..95b66ee 100644 --- a/kernel/power/disk.c +++ b/kernel/power/disk.c @@ -61,9 +61,11 @@ void hibernation_set_ops(struct hibernation_ops *ops) } mutex_lock(_mutex); hibernation_ops = ops; - if (ops) - hibernation_mode = HIBERNATION_PLATFORM; - else if (hibernation_mode == HIBERNATION_PLATFORM) + + /* +* Turn off HIBERNATION_PLATFORM if we no longer have any platform ops. +*/ + if (!ops && hibernation_mode == HIBERNATION_PLATFORM) hibernation_mode = HIBERNATION_SHUTDOWN; mutex_unlock(_mutex); > > > Linus > > > > --- > > kernel/power/disk.c |6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/power/disk.c b/kernel/power/disk.c > > index b5f0543..f6aa06e 100644 > > --- a/kernel/power/disk.c > > +++ b/kernel/power/disk.c > > @@ -60,9 +60,9 @@ void hibernation_set_ops(struct hibernation_ops *ops) > > } > > mutex_lock(_mutex); > > hibernation_ops = ops; > > - if (ops) > > - hibernation_mode = HIBERNATION_PLATFORM; > > - else if (hibernation_mode == HIBERNATION_PLATFORM) > > + > > + /* Turn off HIBERNATION_PLATFORM if we no longer have any platform > > ops */ > > + if (!ops && hibernation_mode == HIBERNATION_PLATFORM) > > hibernation_mode = HIBERNATION_SHUTDOWN; > > > > mutex_unlock(_mutex); > > > > > -- > Qi Yong > - > 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: [PATCH 2/3] dma: redefine dma_flags_set/get_*() for sn-ia64
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 16 Oct 2007 20:29:04 -0700 > So we take an `enum data_direction' and then wedge it into a word alongside > some extra flags? > > Can we do something nicer than that? Yes, I discussed this last time around, this type abuse stinks and it's confusing. - 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: Boot Failure with 2.6.23-rc10
Thank you, that worked great. Chris On Wed, 2007-10-17 at 05:06 +0200, Gabriel C wrote: > Chris Holvenstot wrote: > > Greetings - > > Hi, > > > > > This is likely something I am doing wrong (or stupid) but I have run > > through the build process a couple of times with the same result. > > > > When booted, the following messages are displayed: > > > > Linux zimage kernel to big, try "make bzImage" > > > > Error 28: Selected item can into fit into memory > > > > I have tried the "make bzImage" and manually copied forward to /boot - > > no joy. > > > > If you use git just pull is already fixed if not get that patch : > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=7eebb9348655b3d65fc7cb6cfad292d28dbb > > > Regards, > > Gabriel - 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: Fix to "All wake-up devices are disabled after suspend-to disk" isn't yet included in mainline
On Wed, 17 Oct 2007 04:39:30 +0200 Maxim Levitsky <[EMAIL PROTECTED]> wrote: > A while ago I asked on LKML about the problem of loosing all wake device > capabilities, after a suspend to disk > (eg: I can't wake the system from keyboard if I suspend to disk and then to > ram) > > I was provided with the patch that fixes this problem completely. > The merge window is open, but I still don't see it in the kernel. > Due to changes it doesn't anymore apply to latest git. > > Was it missed? No, it's in Len's git tree. Len's git-pull request from a few days ago didn't work, perhaps because I wanted to know if a recent -mm regression had been fixed and that hasn't been answered yet. I assume that Len is offline. Other acpi developers could presumably have answered that question but for some reason chose not to. I'm presently holding off 20-odd power management patches due to their dependency upon an acpi merge... - 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] [275/2many] MAINTAINERS - KDUMP
On Tue, Oct 16, 2007 at 07:45:34PM -0700, Joe Perches wrote: > On Wed, 2007-10-17 at 11:19 +0900, Simon Horman wrote: > > > I take it that these changes got shelved or canned, > > as I still don't seem them in Linus' tree. > > I have all the changes kept up-to-date. > I still hope to get some variant into a future release. > > > But just for the record, the file lists seem > > to be somewhat sort. I'm not sure exactly what the criteria is, but for > > starters, shouldn't all the architecture specific files that only > > contain kexec or kdump code be in there too? > > If one of the maintainers, Vivek Goyal or Haren Myneni, cared > to improve the kdump list of files, I'd happily accept it. Understood. I'm happy to make a start on that. Do you have a criteria for including files. Are they files that only apply to KEXEC/KDUMP, or files that have KEXEC/KDUMP code and other code? > My maintainer entry for kdump is: > > KDUMP > P:Vivek Goyal > M:[EMAIL PROTECTED] > P:Haren Myneni > M:[EMAIL PROTECTED] > L:[EMAIL PROTECTED] > L:linux-kernel@vger.kernel.org > W:http://lse.sourceforge.net/kdump/ > S:Maintained > F:Documentation/kdump > > and if Eric Biederman wants to improve kexec: > > KEXEC > P:Eric Biederman > M:[EMAIL PROTECTED] > W:http://www.xmission.com/~ebiederm/files/kexec/ > L:linux-kernel@vger.kernel.org > L:[EMAIL PROTECTED] > S:Maintained > F:include/linux/kexec.h > F:kernel/kexec.c > > > > > ___ > kexec mailing list > [EMAIL PROTECTED] > http://lists.infradead.org/mailman/listinfo/kexec -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - 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 try#2] Input/Touchscreen Driver: add support AD7877 touchscreen driver
From: Michael Hennerich <[EMAIL PROTECTED]> Subject: [PATCH try#2] Input/Touchscreen Driver: add support AD7877 touchscreen driver [try #2] Changelog: - move locking inside ad7877_enable and ad7877_disable - use setup_timer - use input_dev->dev.parent - fix unregister device - kill EV_KEY since it's not used - fix indention style Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- drivers/input/touchscreen/Kconfig | 13 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/ad7877.c | 945 3 files changed, 959 insertions(+), 0 deletions(-) create mode 100644 drivers/input/touchscreen/ad7877.c diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index e3e0baa..b706910 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -29,6 +29,19 @@ config TOUCHSCREEN_ADS7846 To compile this driver as a module, choose M here: the module will be called ads7846. +config TOUCHSCREEN_AD7877 + tristate "AD7877 based touchscreens" + depends on SPI_MASTER + help + Say Y here if you have a touchscreen interface using the + AD7877 controller, and your board-specific initialization + code includes that in its table of SPI devices. + + If unsure, say N (but it's safe to say "Y"). + + To compile this driver as a module, choose M here: the + module will be called ad7877. + config TOUCHSCREEN_BITSY tristate "Compaq iPAQ H3600 (Bitsy) touchscreen" depends on SA1100_BITSY diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index 35d4097..49561b2 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -4,6 +4,7 @@ # Each configuration option enables a list of files. +obj-$(CONFIG_TOUCHSCREEN_AD7877) += ad7877.o obj-$(CONFIG_TOUCHSCREEN_ADS7846) += ads7846.o obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o diff --git a/drivers/input/touchscreen/ad7877.c b/drivers/input/touchscreen/ad7877.c new file mode 100644 index 000..6f27dda --- /dev/null +++ b/drivers/input/touchscreen/ad7877.c @@ -0,0 +1,945 @@ +/* + * File:drivers/input/touchscreen/ad7877.c + * + * Based on: ads7846.c + * + * Copyright (C) 2006 Michael Hennerich, Analog Devices Inc. + * + * Author: Michael Hennerich, Analog Devices Inc. + * + * Created:Nov, 10th 2006 + * Description:AD7877 based touchscreen, sensor (ADCs), DAC and GPIO driver + * + * Rev: $Id: ad7877.c 3731 2007-10-16 09:20:34Z hennerich $ + * + * Modified: + * Copyright 2004-2007 Analog Devices Inc. + * + * Bugs:Enter bugs at http://blackfin.uclinux.org/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see the file COPYING, or write + * to the Free Software Foundation, Inc., + * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + * History: + * Copyright (c) 2005 David Brownell + * Copyright (c) 2006 Nokia Corporation + * Various changes: Imre Deak <[EMAIL PROTECTED]> + * + * Using code from: + * - corgi_ts.c + * Copyright (C) 2004-2005 Richard Purdie + * - omap_ts.[hc], ads7846.h, ts_osk.c + * Copyright (C) 2002 MontaVista Software + * Copyright (C) 2004 Texas Instruments + * Copyright (C) 2005 Dirk Behme + */ + + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifdef CONFIG_BFIN +#include +#endif + +#defineTS_PEN_UP_TIMEOUT msecs_to_jiffies(50) + +/*--*/ + +#define MAX_SPI_FREQ_HZ2000 +#defineMAX_12BIT ((1<<12)-1) + +#define AD7877_REG_ZEROS 0 +#define AD7877_REG_CTRL1 1 +#define AD7877_REG_CTRL2 2 +#define AD7877_REG_ALERT 3 +#define AD7877_REG_AUX1HIGH4 +#define AD7877_REG_AUX1LOW 5 +#define AD7877_REG_BAT1HIGH6 +#define AD7877_REG_BAT1LOW 7 +#define AD7877_REG_BAT2HIGH8 +#define
Re: [PATCH] [275/2many] MAINTAINERS - KDUMP
On Tue, 16 Oct 2007 19:45:34 -0700 Joe Perches <[EMAIL PROTECTED]> wrote: > If one of the maintainers, Vivek Goyal or Haren Myneni, cared > to improve the kdump list of files, I'd happily accept it. meh. Bug-reporters only manage to cc the right mailing list 10% of the time even when it's utterly obvious which subsystem went splat. I wouldn't worry about fine details such as this. Anyway, everyone just sends stuff to the great kernel routing service (ie: me) for the traditional forward-and-ignore treatment. - 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] document dma_flags_set/get_*()
On Tue, 16 Oct 2007 18:44:17 -0700 [EMAIL PROTECTED] wrote: > @@ -547,3 +547,41 @@ size is the size (and should be a page-sized multiple). > The return value will be either a pointer to the processor virtual > address of the memory, or an error (via PTR_ERR()) if any part of the > region is occupied. > + > +int > +dma_flags_set_attr(u32 attr, enum dma_data_direction dir) > + > +Amend dir with a platform-specific "dma attribute". > + > +The only attribute currently defined is DMA_BARRIER_ATTR, which causes > +in-flight DMA to be flushed when the associated memory region is written > +to (see example below). Setting DMA_BARRIER_ATTR provides a mechanism > +to enforce ordering of DMA on platforms that permit DMA to be reordered > +between device and host memory (within a NUMA interconnect). On other > +platforms this is a nop. > + > +DMA_BARRIER_ATTR would be set when the memory region is mapped for DMA, > +e.g.: > + > + int count; > + int flags = dma_flags_set_attr(DMA_BARRIER_ATTR, DMA_BIDIRECTIONAL); > + > + count = dma_map_sg(dev, sglist, nents, flags); > + Isn't this rather a kludge? What would be the cost of doing this cleanly and either redefining dma_data_direction to be a field-of-bits or just leave dma_data_direction alone (it is quite unrelated to this work, isn't it?) and adding new fields/arguments to manage this new functionality? - 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: [Pcihpd-discuss] [PATCH 2/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
On Tue, Oct 16, 2007 at 09:54:42PM -0400, Mark Lord wrote:
> if (rc)
> goto err_out_free_ctrl_slot;
> - }
> + } else if (pciehp_force)
> + pciehp_enable_slot(t_slot);
>
I find the construct if () { ... } else ...; to be a bit jarring. How
about adding the extra braces?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
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: [Pcihpd-discuss] [PATCH 1/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
On Tue, Oct 16, 2007 at 09:54:08PM -0400, Mark Lord wrote:
> - t_slot->hpc_ops->get_adapter_status(t_slot, ); /* Check if slot
> is occupied */
> + /* Check if slot is occupied */
> + t_slot->hpc_ops->get_adapter_status(t_slot, );
> if ((POWER_CTRL(ctrl->ctrlcap)) && !value) {
> - rc = t_slot->hpc_ops->power_off_slot(t_slot); /* Power off slot
> if not occupied*/
> + /* Power off slot if not occupied*/
> + rc = t_slot->hpc_ops->power_off_slot(t_slot);
I'd argue these comments fall under "stating the bleedin' obvious", but
that's Kristen's call.
> case INT_PRESENCE_OFF:
> if (!HP_SUPR_RM(ctrl->ctrlcap))
> break;
> - dbg("Surprise Removal\n");
> + dbg("Surprise Event\n");
> update_slot_info(p_slot);
> handle_surprise_event(p_slot);
> break;
That doesn't seem like an obviously correct change to me. Can you
explain?
> - if (((cap_reg & SLOT_IMPL) == 0) || (((cap_reg & DEV_PORT_TYPE) !=
> 0x0040)
> + if (((cap_reg & SLOT_IMPL) == 0)
> + || (((cap_reg & DEV_PORT_TYPE) != 0x0040)
> && ((cap_reg & DEV_PORT_TYPE) != 0x0060))) {
> - dbg("%s : This is not a root port or the port is not connected
> to a slot\n", __FUNCTION__);
> + dbg("%s : This is not a root port"
> + " or the port is not connected to a slot\n", __FUNCTION__);
> goto abort_free_ctlr;
Normal style would be more like ...
if (((cap_reg & SLOT_IMPL) == 0) ||
(((cap_reg & DEV_PORT_TYPE) != 0x0040) &&
((cap_reg & DEV_PORT_TYPE) != 0x0060))) {
dbg("%s : This is not a root port or the port is not "
"connected to a slot\n", __FUNCTION__);
> - info("HPC vendor_id %x device_id %x ss_vid %x ss_did %x\n",
> pdev->vendor, pdev->device,
> + info("HPC vendor_id %x device_id %x ss_vid %x"
> + " ss_did %x\n", pdev->vendor, pdev->device,
> pdev->subsystem_vendor, pdev->subsystem_device);
Why did you choose to break the format string?
info("HPC vendor_id %x device_id %x ss_vid %x ss_did %x\n",
pdev->vendor, pdev->device,
pdev->subsystem_vendor, pdev->subsystem_device);
> - temp_word = (temp_word & ~HP_INTR_ENABLE & ~CMD_CMPL_INTR_ENABLE) |
> 0x00;
> + temp_word = (temp_word & ~HP_INTR_ENABLE & ~CMD_CMPL_INTR_ENABLE)|0x00;
Just delete the | 0x00?
> - temp_word = (temp_word & ~intr_enable) | intr_enable;
> + temp_word = (temp_word & ~intr_enable) | intr_enable;
*boggle*
temp_word |= intr_enable;
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
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/3] dma: redefine dma_flags_set/get_*() for sn-ia64
On Tue, 16 Oct 2007 18:43:16 -0700 [EMAIL PROTECTED] wrote:
> @@ -153,7 +153,7 @@ EXPORT_SYMBOL(sn_dma_free_coherent);
> * @dev: device to map for
> * @cpu_addr: kernel virtual address of the region to map
> * @size: size of the region
> - * @direction: DMA direction
> + * @flags: DMA direction, and arch-specific attributes
> *
> * Map the region pointed to by @cpu_addr for DMA and return the
> * DMA address.
> @@ -167,17 +167,23 @@ EXPORT_SYMBOL(sn_dma_free_coherent);
> * figure out how to save dmamap handle so can use two step.
> */
> dma_addr_t sn_dma_map_single(struct device *dev, void *cpu_addr, size_t size,
> - int direction)
> + int flags)
> {
> dma_addr_t dma_addr;
> unsigned long phys_addr;
> struct pci_dev *pdev = to_pci_dev(dev);
> struct sn_pcibus_provider *provider = SN_PCIDEV_BUSPROVIDER(pdev);
> + int dmabarrier = dma_flags_get_attr(flags) & DMA_BARRIER_ATTR;
So we take an `enum data_direction' and then wedge it into a word alongside
some extra flags?
Can we do something nicer than that?
-
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 1/3] dma: add dma_flags_set/get_*() interfaces
On Tue, 16 Oct 2007 18:41:28 -0700 [EMAIL PROTECTED] wrote:
> +#define DMA_BARRIER_ATTR 0x1
> +#ifndef ARCH_USES_DMA_ATTRS
> +static inline int dma_flags_set_attr(u32 attr, enum dma_data_direction dir)
> +{
> + return dir;
> +}
This function takes an `enum dma_data_direction' as its second arg, but your
ia64 implementation takes an 'int'.
> +static inline int dma_flags_get_dir(int flags)
> +{
> + return flags;
> +}
> +
> +static inline int dma_flags_get_attr(int flags)
> +{
> + return 0;
> +}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Have zonelist contains structs with both a zone pointer and zone_idx
On Fri, 28 Sep 2007, Mel Gorman wrote: > > Filtering zonelists requires very frequent use of zone_idx(). This is costly > as it involves a lookup of another structure and a substraction operation. As > the zone_idx is often required, it should be quickly accessible. The node > idx could also be stored here if it was found that accessing zone->node is > significant which may be the case on workloads where nodemasks are heavily > used. > > This patch introduces a struct zoneref to store a zone pointer and a zone > index. The zonelist then consists of an array of this struct zonerefs which > are looked up as necessary. Helpers are given for accessing the zone index > as well as the node index. > > [EMAIL PROTECTED]: Suggested struct zoneref instead of embedding information > in pointers] > Signed-off-by: Mel Gorman <[EMAIL PROTECTED]> > Acked-by: Christoph Lameter <[EMAIL PROTECTED]> OOM locking looks good, thanks. Acked-by: David Rientjes <[EMAIL PROTECTED]> - 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] missing include in mmc
> > > AFAICS, fallout from repacing include of blkdev.h with include of bio.h. > > > > Out of curiousity, which architecture(s) need this? > > Umm... IIRC, m32r had been the first build to step into that, at which point > the missing include had been added; the rest had reached that point later, so > I'm not sure which ones would trigger the same crap. Not hard to test, > though... > > Aha. m68k as well. FWIW this driver originally started out on ColdFire (m68k derived), a few years back. :) Every time I seee a case where architectures don't act the same with respect to #includes, I count it as an unpleasant surprise. Not one that's very easy to avoid, unfortunately, but I think it's been happening less often lately. Thanks for the fix. - Dave - 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: Distinguishing releases from pre-rc snapshots
On Tue, 2007-10-16 at 22:41 -0400, Rik van Riel wrote: > On Tue, 16 Oct 2007 22:22:43 -0400 > Pavel Roskin <[EMAIL PROTECTED]> wrote: > > > I'm trying to keep some external drivers up to date with the kernel, > > and the first two weeks after the release is the worst time for me. > > Consider this an incentive to submit your code for inclusion > in the upstream kernel. Having all the common drivers integrated > in the mainline kernel makes it much easier for users to use all > their hardware, external drivers are not just a pain for the developers. The incentive has already worked for MadWifi, which has landed in the wireless-2.6 repository under the name "ath5k". Still, there is a lot of work to do, and some features won't appear in the kernel driver soon, partly because they rely on the chipset features that still need to be reverse engineered. In the meantime, somebody has to maintain the old madwifi and release fixed for security and kernel compatibility. Also, there are drivers that are just to unwieldy to be shaped into something resembling a typical Linux driver. linux-wlan-ng is such project. No matter what the incentive, it won't go to the kernel. Maybe somebody will write a clean driver for Prism USB devices one day, but it didn't happen so far. Finally, there is a little at76_usb driver, which supports quite old 802.11b devices. It's in wireless-2.6 as well, but I simply cannot expect users to test it from there. And if I make a standalone release, I'd rather not make another one when 2.6.24 comes out. -- Regards, Pavel Roskin - 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: Boot Failure with 2.6.23-rc10
Chris Holvenstot wrote: > Greetings - Hi, > > This is likely something I am doing wrong (or stupid) but I have run > through the build process a couple of times with the same result. > > When booted, the following messages are displayed: > > Linux zimage kernel to big, try "make bzImage" > > Error 28: Selected item can into fit into memory > > I have tried the "make bzImage" and manually copied forward to /boot - > no joy. > If you use git just pull is already fixed if not get that patch : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=7eebb9348655b3d65fc7cb6cfad292d28dbb Regards, Gabriel - 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: Distinguishing releases from pre-rc snapshots
On Tue, Oct 16, 2007 at 10:45:17PM -0400, Pavel Roskin wrote: > > On Tue, 2007-10-16 at 22:34 -0400, Dave Jones wrote: > > On Tue, Oct 16, 2007 at 10:22:43PM -0400, Pavel Roskin wrote: > > > > > It would be nice to establish a rule to increment the version number > > > immediately after the kernel release and have a suffix to indicate that > > > it's a pre-rc version. "rc0" is my personal favorite. > > > > fwiw, rc0 is also what the Fedora kernel uses for versioning when we're > > shipping pre-rc1 kernels. > > Thanks! I didn't think of the possibility of anyone distributing > precompiled kernels from the "pre-rc" window, but if Fedora does it > (hopefully for beta-testers only), it should be absolutely clear that > it's not just a release with some minor fixes. yeah, this is just in our 'development' pool (also known as 'rawhide') Proper releases only ever get full point releases + -stable as updates. Dave -- http://www.codemonkey.org.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/
[RFC patch] fallback to "no irq" hack for case of no pnp_irq allocated for 8250_pnp
Hello list, There is a "ttyS1 irq is -1" problem observed on tiger4 which cause the serial port broken. It is because that there is __no__ ACPI IRQ resource assigned for the serial port. So the value of the IRQ for the port is never changed since it got initialized to -1. The attached patch falls back to the "no irq" hack for this case. It works for me. Please review and test. Thanks, Luming Signed-off-by: Yu Luming <[EMAIL PROTECTED]> 8250_pnp.c |3 +++ 1 files changed, 3 insertions(+) 8250_pnp.patch Description: Binary data
Re: [PATCH] jiffies_round -> jiffies_round_relative conversion - ipw2100/ipw2200
On Mon, 2007-10-15 at 00:38 -0500, Anton Blanchard wrote: > > When rounding a relative timeout we need to use > round_jiffies_relative(). ACK. John, please apply this patch to wireless-2.6. Thanks. -yi - 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] swsusp: Use platform mode by default
On Wed, 17 Oct 2007, Qi Yong wrote: > > The key point is "fall back to shutdown _only_ if !ops, otherwise > don't touch hibernation_mode". And that solves my problem. Please, when resurrecting a five-month-old discussion, give more of the old context. I don't know about anybody else, but I get enough email that "five months" might as well be "last century" when it comes to email discussions, and I have long since forgotten the details of whatever caused the issue to begin with ;) Linus - 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: hda-intel: no soundcard with current linus' git tree
On Wednesday 17 October 2007 00:18:42 Thomas Meyer wrote: > $ dmesg > > [schnipp] > > ACPI: PCI Interrupt :00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21 > PCI: Enabling bus mastering for device :00:1b.0 > PCI: Setting latency timer of device :00:1b.0 to 64 > hda_codec: STAC922x, Apple subsys_id=106b0200 > ACPI: PCI interrupt for device :00:1b.0 disabled > HDA Intel: probe of :00:1b.0 failed with error -16 > > [schnipp] > > > - > 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/ > Please bisect this (the alsa merge happened just short time ago) Which kernel did work? Best regards, Maxim Levitsky - 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] [275/2many] MAINTAINERS - KDUMP
On Wed, 2007-10-17 at 11:19 +0900, Simon Horman wrote: > I take it that these changes got shelved or canned, > as I still don't seem them in Linus' tree. I have all the changes kept up-to-date. I still hope to get some variant into a future release. > But just for the record, the file lists seem > to be somewhat sort. I'm not sure exactly what the criteria is, but for > starters, shouldn't all the architecture specific files that only > contain kexec or kdump code be in there too? If one of the maintainers, Vivek Goyal or Haren Myneni, cared to improve the kdump list of files, I'd happily accept it. My maintainer entry for kdump is: KDUMP P: Vivek Goyal M: [EMAIL PROTECTED] P: Haren Myneni M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-kernel@vger.kernel.org W: http://lse.sourceforge.net/kdump/ S: Maintained F: Documentation/kdump and if Eric Biederman wants to improve kexec: KEXEC P: Eric Biederman M: [EMAIL PROTECTED] W: http://www.xmission.com/~ebiederm/files/kexec/ L: linux-kernel@vger.kernel.org L: [EMAIL PROTECTED] S: Maintained F: include/linux/kexec.h F: kernel/kexec.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] swsusp: Use platform mode by default
On 12/05/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Fri, 11 May 2007, Rafael J. Wysocki wrote: > > > > We're working on fixing the breakage, but currently it's difficult, because > > none of my testboxes has problems with the 'platform' hibernation and I > > cannot reproduce the reported issues. > > The rule for anything ACPI-related has been: no regressions. > > It doesn't matter if something fixes 10 boxes, if it breaks a single one, > it's going to get reverted. > > We had much too much of the "two steps forward, one step back" dance with > ACPI a few years ago, which is the reason that rule got installed (and > which is why it's ACPI-only: in some other subsystems we accept the fact > that sometimes we don't know how to fix some hardware issue, but the new > situation is at least better than the old one). > > I agree that it can be aggravating to know that you can fix a problem for > some people, but then being limited by the fact that it breaks for others. > But beign able to *rely* on something that used to work is just too > important, and with ACPI, you can never make a good judgement of which way > works better (since it really just depends on some random firmware issues > that we have zero visibility into). > > Also, quite often, it may *seem* like something fixes more boxes than it > breaks, but it's because people report *breakage* only, and then a few > months later it turns out that it's exactly the other way around: now it's > a hundred people who report breakage with the *new* code, and the reason > people thought it fixed more than it broke was that the people for whom > the old code worked fine obviously never reported it! > > So this is why "a single regression is considered more important than ten > fixes" - because a single regressionr report tends to actually be just the > first indication of a lot of people who simply haven't tested the new code > yet! People for whom the old code is broken are more likely to test new > things. > > So I'd just suggest changing the default back to PM_DISK_SHUTDOWN (but > leave the "pm_ops->enter" testing in place - ie not reverting the other > commits in the series). > > The patch would look something like this. Coywolf, does this fix it for > you? > Yes, it fixes my problem. (Sorry for this long delayed report. I didn't get the chance to test and reboot my box.) This quick test explains me the problem that we should not set hibernation_mode to HIBERNATION_PLATFORM if it is not !ops". I will post a formal patch later. diff --git a/kernel/power/disk.c b/kernel/power/disk.c index eb72255..8e52553 100644 --- a/kernel/power/disk.c +++ b/kernel/power/disk.c @@ -62,7 +62,7 @@ void hibernation_set_ops(struct hibernation_ops *ops) mutex_lock(_mutex); hibernation_ops = ops; if (ops) - hibernation_mode = HIBERNATION_PLATFORM; + ; else if (hibernation_mode == HIBERNATION_PLATFORM) hibernation_mode = HIBERNATION_SHUTDOWN; > Linus > > --- > kernel/power/disk.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/kernel/power/disk.c b/kernel/power/disk.c > index b5f0543..f6aa06e 100644 > --- a/kernel/power/disk.c > +++ b/kernel/power/disk.c > @@ -60,9 +60,9 @@ void hibernation_set_ops(struct hibernation_ops *ops) > } > mutex_lock(_mutex); > hibernation_ops = ops; > - if (ops) > - hibernation_mode = HIBERNATION_PLATFORM; > - else if (hibernation_mode == HIBERNATION_PLATFORM) > + > + /* Turn off HIBERNATION_PLATFORM if we no longer have any platform > ops */ > + if (!ops && hibernation_mode == HIBERNATION_PLATFORM) > hibernation_mode = HIBERNATION_SHUTDOWN; > > mutex_unlock(_mutex); > -- Qi Yong - 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: Distinguishing releases from pre-rc snapshots
On Tue, 2007-10-16 at 22:34 -0400, Dave Jones wrote: > On Tue, Oct 16, 2007 at 10:22:43PM -0400, Pavel Roskin wrote: > > > It would be nice to establish a rule to increment the version number > > immediately after the kernel release and have a suffix to indicate that > > it's a pre-rc version. "rc0" is my personal favorite. > > fwiw, rc0 is also what the Fedora kernel uses for versioning when we're > shipping pre-rc1 kernels. Thanks! I didn't think of the possibility of anyone distributing precompiled kernels from the "pre-rc" window, but if Fedora does it (hopefully for beta-testers only), it should be absolutely clear that it's not just a release with some minor fixes. Anyone adjusting any software for that kernel would be adjusting for the next kernel release. -- Regards, Pavel Roskin - 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: Distinguishing releases from pre-rc snapshots
On Tue, 16 Oct 2007 22:22:43 -0400 Pavel Roskin <[EMAIL PROTECTED]> wrote: > I'm trying to keep some external drivers up to date with the kernel, > and the first two weeks after the release is the worst time for me. Consider this an incentive to submit your code for inclusion in the upstream kernel. Having all the common drivers integrated in the mainline kernel makes it much easier for users to use all their hardware, external drivers are not just a pain for the developers. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - 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] Map volume and brightness events on thinkpads
On Tuesday, October 16, 2007 2:18 am Henrique de Moraes Holschuh wrote: > On Tue, 16 Oct 2007, Jesse Barnes wrote: > > On Tuesday, October 16, 2007 1:36 am Henrique de Moraes Holschuh wrote: > > > You want ACPI video to just pass the messages to userspace when > > > X.org is driving the backlight? Fine with me. That *still* > > > doesn't make it right to get these messages as hot key presses > > > over the input layer through the thinkpad-acpi driver. So the > > > NAK stands. Any changes should be done to the ACPI video driver > > > in this case. > > > > So is this really the direction that input is going? Last time I > > talked with Dmitry, he seemed ok with adding input events for ACPI > > and other firmware hotkeys... > > Last time the issue was brought up (and I do believe it was because > of thinkpad-acpi :-) ), he made it clear that any events you are to > act upon are fine in input, but events that are just notifications > (i.e. the firmware already did the action) are not. Ah yeah, I agree with that. Regular events should be uevents or something, not input events. Actual keyboard keys though (whether they generate firmware event messages or actual scancodes) should probably go through the input layer. I thought that's what Jeremy's patch was doing, maybe I didn't look closely enough. Jesse - 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/
Fix to "All wake-up devices are disabled after suspend-to disk" isn't yet included in mainline
Hi,
A while ago I asked on LKML about the problem of loosing all wake device
capabilities, after a suspend to disk
(eg: I can't wake the system from keyboard if I suspend to disk and then to ram)
I was provided with the patch that fixes this problem completely.
The merge window is open, but I still don't see it in the kernel.
Due to changes it doesn't anymore apply to latest git.
Was it missed?
The patch below for the reference,
(acpi_sleep_prepare was moved to /drivers/acpi/sleep/main.c, so I did in-line
change in the patch)
Best regards,
Maxim Levitsky
commit ea256a37b093b9c0c0fa639eb9a0bff10df41998
Author: Alexey Starikovskiy <[EMAIL PROTECTED]>
Date: Wed Sep 12 14:04:32 2007 +0400
ACPI: Hibernate erroneously disabled Suspend wakeup devices
S4 suspend to disk will disable GPE's permanently
because acpi_gpe_sleep_prepare() does not have
a counterpart at resume time. Thus, those devices
became unavailable for wakeup from subsequent
S3 suspend-to-ram.
Here acpi_gpe_sleep_prepare() is removed, and upon suspend
acpi_enable_wakeup_device() gets its functionality.
Upon resume, acpi_disable_wakeup_device() restores the state.
https://bugzilla.novell.com/show_bug.cgi?id=292300
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/sleep/poweroff.c |1 -
drivers/acpi/sleep/sleep.h|1 -
drivers/acpi/sleep/wakeup.c | 117 ++---
include/acpi/acpi_bus.h |1 -
4 files changed, 40 insertions(+), 80 deletions(-)
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 39e40d5..2725a60 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -32,7 +32,6 @@ int acpi_sleep_prepare(u32 acpi_state)
ACPI_FLUSH_CPU_CACHE();
acpi_enable_wakeup_device_prep(acpi_state);
#endif
- acpi_gpe_sleep_prepare(acpi_state);
acpi_enter_sleep_state_prep(acpi_state);
return 0;
}
diff --git a/drivers/acpi/sleep/sleep.h b/drivers/acpi/sleep/sleep.h
index ff1f850..a2ea125 100644
--- a/drivers/acpi/sleep/sleep.h
+++ b/drivers/acpi/sleep/sleep.h
@@ -5,6 +5,5 @@ extern int acpi_suspend (u32 state);
extern void acpi_enable_wakeup_device_prep(u8 sleep_state);
extern void acpi_enable_wakeup_device(u8 sleep_state);
extern void acpi_disable_wakeup_device(u8 sleep_state);
-extern void acpi_gpe_sleep_prepare(u32 sleep_state);
extern int acpi_sleep_prepare(u32 acpi_state);
diff --git a/drivers/acpi/sleep/wakeup.c b/drivers/acpi/sleep/wakeup.c
index 97c27dd..ed8e41b 100644
--- a/drivers/acpi/sleep/wakeup.c
+++ b/drivers/acpi/sleep/wakeup.c
@@ -64,36 +64,29 @@ void acpi_enable_wakeup_device(u8 sleep_state)
ACPI_FUNCTION_TRACE("acpi_enable_wakeup_device");
spin_lock(_device_lock);
list_for_each_safe(node, next, _wakeup_device_list) {
- struct acpi_device *dev = container_of(node,
- struct acpi_device,
- wakeup_list);
-
+ struct acpi_device *dev =
+ container_of(node, struct acpi_device, wakeup_list);
+ if (!dev->wakeup.flags.valid)
+ continue;
/* If users want to disable run-wake GPE,
* we only disable it for wake and leave it for runtime
*/
- if (dev->wakeup.flags.run_wake && !dev->wakeup.state.enabled) {
- spin_unlock(_device_lock);
- acpi_set_gpe_type(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number,
- ACPI_GPE_TYPE_RUNTIME);
- /* Re-enable it, since set_gpe_type will disable it */
- acpi_enable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number, ACPI_ISR);
- spin_lock(_device_lock);
+ if (!dev->wakeup.state.enabled ||
+ sleep_state > (u32) dev->wakeup.sleep_state) {
+ if (dev->wakeup.flags.run_wake) {
+ spin_unlock(_device_lock);
+ /* set_gpe_type will disable GPE, leave it like
that */
+ acpi_set_gpe_type(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number,
+ ACPI_GPE_TYPE_RUNTIME);
+ spin_lock(_device_lock);
+ }
continue;
}
-
- if (!dev->wakeup.flags.valid ||
- !dev->wakeup.state.enabled ||
- (sleep_state > (u32) dev->wakeup.sleep_state))
-
Re: error: Eeek! page_mapcount(page) went negative! (-1) with different process and kernels
On Wed, Oct 17, 2007 at 01:03:02AM +0200, Arnaud Fontaine wrote: > > "Dave" == Dave Jones <[EMAIL PROTECTED]> writes: > > Dave> Many of these that I've seen have turned out to be a hardware > Dave> problem. Try running memtest86+ on that machine for a while. > Dave> It doesn't catch all problems, but it will highlight more > Dave> common memory faults. > > Hello, > > We ran memtest86+ before production, it was about one month ago. Do you > think it could come from that anyway? Not impossible. Hardware failures can occur at any time. Somewhat unlikely though. As I mentioned, memtest also doesn't trap all hardware problems. I have a board that passes memtest with flying colours, yet dies under even slight load. Examination of the board shows that it has leaking capacitors. Dave -- http://www.codemonkey.org.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: [PATCH] swsusp: Use platform mode by default
On 14/05/2007, Stefan Seyfried <[EMAIL PROTECTED]> wrote: > On Fri, May 11, 2007 at 03:51:38PM -0700, Linus Torvalds wrote: > > > > > > On Fri, 11 May 2007, Rafael J. Wysocki wrote: > > > > > > Just to clarify, the change in question isn't new. It was introduced by > > > the > > > commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's > > > request and with Pavel's acceptance. > > > > Ok, if it's that old, we migt as leave it in. Clearly there weren't many > > regressions, and this isn't a case of other monsters lurking behind a lack > > of testers. > > I pushed for this since on ACPI machines, "platform" is the right thing to do, > and i still think it will only break on machines that have a broken ACPI BIOS. > (Are there machines with broken ACPI BIOS around? ;-) > > Your additional "fall back to shutdown if !(ops)"-fix looks very sane, > however, and is definitely a good idea. The key point is "fall back to shutdown _only_ if !ops, otherwise don't touch hibernation_mode". And that solves my problem. -- Qi Yong - 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: Distinguishing releases from pre-rc snapshots
On Tue, Oct 16, 2007 at 10:22:43PM -0400, Pavel Roskin wrote: > It would be nice to establish a rule to increment the version number > immediately after the kernel release and have a suffix to indicate that > it's a pre-rc version. "rc0" is my personal favorite. fwiw, rc0 is also what the Fedora kernel uses for versioning when we're shipping pre-rc1 kernels. Dave -- http://www.codemonkey.org.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: [PATCH 2/3] [kexec-tools] Pass vmcoreinfo's address and size
On Wed, Aug 22, 2007 at 09:13:39PM +0900, Ken'ichi Ohmichi wrote:
>
> [2/3] [kexec-tools] Pass vmcoreinfo's address and size
> The patch is for kexec-tools-testing-20070330.
> (http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/)
> kexec command gets the address and size of the vmcoreinfo data from
> /sys/kernel/vmcoreinfo, and passes them to the second kernel through
> ELF header of /proc/vmcore. When the second kernel is booting, the
> kernel gets them from the ELF header and creates vmcoreinfo's PT_NOTE
> segment into /proc/vmcore.
Sorry for the long delay, I completely missed this patch.
The kexec-tools change seems ok to me. What is the status of
the kernel portion of the change? Do you still want the
kexec-tools portion applied?
>
> Thanks
> Ken'ichi Ohmichi
>
> ---
> Signed-off-by: Dan Aloni <[EMAIL PROTECTED]>
> Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
>
> ---
> diff -rpuN backup/kexec-tools-testing-20070330/kexec/crashdump-elf.c
> kexec-tools/kexec/crashdump-elf.c
> --- backup/kexec-tools-testing-20070330/kexec/crashdump-elf.c 2007-03-30
> 13:34:36.0 +0900
> +++ kexec-tools/kexec/crashdump-elf.c 2007-08-03 14:45:47.0 +0900
> @@ -36,6 +36,8 @@ int FUNC(struct kexec_info *info,
> char *bufp;
> long int nr_cpus = 0;
> uint64_t notes_addr, notes_len;
> + uint64_t vmcoreinfo_addr, vmcoreinfo_len;
> + int has_vmcoreinfo = 0;
> int (*get_note_info)(int cpu, uint64_t *addr, uint64_t *len);
>
> if (xen_present())
> @@ -47,7 +49,11 @@ int FUNC(struct kexec_info *info,
> return -1;
> }
>
> - sz = sizeof(EHDR) + nr_cpus * sizeof(PHDR) + ranges * sizeof(PHDR);
> + if (get_kernel_vmcoreinfo(_addr, _len) == 0) {
> + has_vmcoreinfo = 1;
> + }
> +
> + sz = sizeof(EHDR) + (nr_cpus + has_vmcoreinfo) * sizeof(PHDR) + ranges
> * sizeof(PHDR);
>
> /*
>* Certain architectures such as x86_64 and ia64 require a separate
> @@ -148,6 +154,21 @@ int FUNC(struct kexec_info *info,
> dfprintf_phdr(stdout, "Elf header", phdr);
> }
>
> + if (has_vmcoreinfo) {
> + phdr = (PHDR *) bufp;
> + bufp += sizeof(PHDR);
> + phdr->p_type= PT_NOTE;
> + phdr->p_flags = 0;
> + phdr->p_offset = phdr->p_paddr = vmcoreinfo_addr;
> + phdr->p_vaddr = 0;
> + phdr->p_filesz = phdr->p_memsz = vmcoreinfo_len;
> + /* Do we need any alignment of segments? */
> + phdr->p_align = 0;
> +
> + (elf->e_phnum)++;
> + dfprintf_phdr(stdout, "vmcoreinfo header", phdr);
> + }
> +
> /* Setup an PT_LOAD type program header for the region where
>* Kernel is mapped if info->kern_size is non-zero.
>*/
> diff -rpuN backup/kexec-tools-testing-20070330/kexec/crashdump.c
> kexec-tools/kexec/crashdump.c
> --- backup/kexec-tools-testing-20070330/kexec/crashdump.c 2007-03-30
> 13:34:36.0 +0900
> +++ kexec-tools/kexec/crashdump.c 2007-08-03 14:45:05.0 +0900
> @@ -108,3 +108,35 @@ int get_crash_notes_per_cpu(int cpu, uin
>
> return 0;
> }
> +
> +/* Returns the physical address of start of crash notes buffer for a kernel.
> */
> +int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
> +{
> + char kdump_info[PATH_MAX];
> + char line[MAX_LINE];
> + int count;
> + FILE *fp;
> + unsigned long long temp, temp2;
> +
> + *addr = 0;
> + *len = 0;
> +
> + sprintf(kdump_info, "/sys/kernel/vmcoreinfo");
> + fp = fopen(kdump_info, "r");
> + if (!fp) {
> + die("Could not open \"%s\": %s\n", kdump_info,
> + strerror(errno));
> + return -1;
> + }
> +
> + if (!fgets(line, sizeof(line), fp))
> + die("Cannot parse %s: %s\n", kdump_info, strerror(errno));
> + count = sscanf(line, "%Lx %Lx", , );
> + if (count != 2)
> + die("Cannot parse %s: %s\n", kdump_info, strerror(errno));
> +
> + *addr = (uint64_t) temp;
> + *len = (uint64_t) temp2;
> +
> + return 0;
> +}
> diff -rpuN backup/kexec-tools-testing-20070330/kexec/crashdump.h
> kexec-tools/kexec/crashdump.h
> --- backup/kexec-tools-testing-20070330/kexec/crashdump.h 2007-03-30
> 13:34:36.0 +0900
> +++ kexec-tools/kexec/crashdump.h 2007-08-03 14:45:05.0 +0900
> @@ -2,6 +2,7 @@
> #define CRASHDUMP_H
>
> extern int get_crash_notes_per_cpu(int cpu, uint64_t *addr, uint64_t *len);
> +extern int get_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len);
>
> /* Need to find a better way to determine per cpu notes section size. */
> #define MAX_NOTE_BYTES 1024
> _
>
> ___
> kexec mailing list
> [EMAIL PROTECTED]
> http://lists.infradead.org/mailman/listinfo/kexec
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit.
On Wed, 17 Oct 2007, Dipankar Sarma wrote: > > Unless I am reading the patch wrongly, it seems cpu_hotplug_begin() is called > while holding the cpu_add_remove_lock mutex. So, another CPU cannot come in > and do the same until _cpu_down() is over. Ahh, in that case I take back that objection, although maybe a comment about the required nesting within the other mutex is in order? Or maybe it's there and I just missed it (blush). Linus - 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] sched: fix improper load balance across sched domain
On Tue, Oct 16, 2007 at 12:07:06PM -0700, Ken Chen wrote: > We recently discovered a nasty performance bug in the kernel CPU load > balancer where we were hit by 50% performance regression. > > When tasks are assigned to a subset of CPUs that span across > sched_domains (either ccNUMA node or the new multi-core domain) via > cpu affinity, kernel fails to perform proper load balance at > these domains, due to several logic in find_busiest_group() miss > identified busiest sched group within a given domain. This leads to > inadequate load balance and causes 50% performance hit. > > To give you a concrete example, on a dual-core, 2 socket numa system, > there are 4 logical cpu, organized as: oops, this issue can easily happen when cores are not sharing caches. I think this is what happening on your setup, right? thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix adbhid mismerge
On Tue, 16 Oct 2007, Linus Torvalds wrote:
>
> I don't think you did anything wrong. You used both --full-history
> (implicitly: git-whatchanged) and you made sure to see the diffs for both
> sides of any merge (-m), and that means that you should see every single
> diff involved.
Btw, if anybody can come up with a better way to find these kinds of
mis-merges, I'd love to hear about it.
In *this* particular case, the -c flag ("combined" merge diff) probably
comes closest, and is certainly a lot better than passing in -m (which
shows each merge against both parents separately), and in fact, I think
you would have found the mis-merge immediately if you had used
git whatchanged -p -c v2.6.23.. drivers/macintosh/adbhid.c
but I'm not going to guarantee that -c always gives you what you want.
In general, the rules are:
- the default for merge diffs is to show "condensed combined" merge, ie
the diff of only those parts where the result actively differs from
*both* parents.
This is very terse, and it has the wonderful property of showing merges
where you actually ended up doing "real work" and not just picking one
side or the other, but in this case the very fact that the mis-merge
had picked one side (and it really would have _needed_ a correct manual
merge) also meant that the default "--cc" format didn't show anything
at all.
- "-c" is for regular combined merges: any file that was modified in both
parents will show up as a combination of the diffs of both sides, while
a file that was taken in its *entirety* is ignored.
In this case that's exactly what you wanted. It's just too noisy to
necessarily be the default, and you can still have a silent mis-merge
if the merger picked *only* one side.
But in general, I suspect that "-c" is often a good thing to try if you
cannot find the cause of some change in a regular commit, and suspect a
merge error.
- "-m" shows each side totally independently. Quite frankly, I've never
found it useful. It is essentially guaranteed to show all changes,
since it shows the patches against all parents individually, so even if
we took only one side, we'll still show the patch against the *other*
side, but quite frankly, while it's thus useful in theory, in practice
the end result is just too noisy to likely ever really be useful as
anything but a "yes, the information is there (..but it's practically
impossible to find for all the other noise that is also there)"
The main reason "-m" exists is historical: before Junio implemented the
combined formats, -m was the easy way to show *any* information. I bet -m
can be useful in some case where you have some pattern you can search for
(ie I used -m in this case to find the mis-merge, but realized only later
that I would have been better off using -c), but it's not something I'd
recommend unless you were really desperate.
What I'd actually really like would be something that shows the original
conflict, but that's really expensive to compute (it basically involves
re-doing the merge from scratch - finding the proper base commit(s) etc).
So we never did that.
Linus
-
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/
Distinguishing releases from pre-rc snapshots
Hello! I'm trying to keep some external drivers up to date with the kernel, and the first two weeks after the release is the worst time for me. There is no way to distinguish the current git kernel from the latest release. It's only after rc1 is released that I can use preprocessor to check LINUX_VERSION_CODE. Before that, I have to rely on tricks or change the kernel version myself in a separate patch and tell other team members to do the same. Basically, I only care about kernel releases, but I also want to increase the probability that the next standalone release of my drivers will work with the next release on the kernel. That's why I check compatibility with the tip of the linux-2.6 repository. Calling git version of Linux "2.6.23" one day before 2.6.24-rc1 is preposterous, as it's likely to be compatible with 2.6.24, not 2.6.23. Calling git version of Linux "2.6.24-pre" or something next day after 2.6.23 release is OK in comparison, since nobody developing external drivers cares about old revisions of the kernel. And the developers of the kernel itself shouldn't care about versions at all. It would be nice to establish a rule to increment the version number immediately after the kernel release and have a suffix to indicate that it's a pre-rc version. "rc0" is my personal favorite. It would also be helpful for other repositories, as it would indicate whether any post-release changes have been merged in. -- Regards, Pavel Roskin - 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] [275/2many] MAINTAINERS - KDUMP
On Sun, Aug 12, 2007 at 11:30:38PM -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1ea2c63..d61676a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2634,6 +2634,7 @@ L: [EMAIL PROTECTED] > L: linux-kernel@vger.kernel.org > W: http://lse.sourceforge.net/kdump/ > S: Maintained > +F: Documentation/kdump > > KERNEL AUTOMOUNTER (AUTOFS) > P: H. Peter Anvin > > ___ > kexec mailing list > [EMAIL PROTECTED] > http://lists.infradead.org/mailman/listinfo/kexec On Sun, Aug 12, 2007 at 11:30:49PM -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index d9a53d9..71738bd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2694,6 +2694,8 @@ W: http://www.xmission.com/~ebiederm/files/kexec/ > L: linux-kernel@vger.kernel.org > L: [EMAIL PROTECTED] > S: Maintained > +F: include/linux/kexec.h > +F: kernel/kexec.c > > KPROBES > P: Prasanna S Panchamukhi I take it that these changes got shelved or canned, as I still don't seem them in Linus' tree. But just for the record, the file lists seem to be somewhat sort. I'm not sure exactly what the criteria is, but for starters, shouldn't all the architecture specific files that only contain kexec or kdump code be in there too? -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - 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: [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit.
On Tue, Oct 16, 2007 at 10:20:37AM -0700, Linus Torvalds wrote:
> On Tue, 16 Oct 2007, Gautham R Shenoy wrote:
>
> Well, afaik, the patch series is fairly clean, and I'm obviously perfectly
> happy with the approach, so I have no objections.
>
> But it looks buggy. This:
>
> +static void cpu_hotplug_begin(void)
> +{
> + mutex_lock(_hotplug.lock);
> + cpu_hotplug.active_writer = current;
> + while (cpu_hotplug.refcount) {
> + mutex_unlock(_hotplug.lock);
> + wait_for_completion(_hotplug.readers_done);
> + mutex_lock(_hotplug.lock);
> + }
> +
> +}
>
> drops the cpu_hotplug.lock, which - as far as I can see - means that
> another process can come in and do the same, and mess up the
> "active_writer" thing. The oerson that actually *gets* the lock may not be
> the same one that has "active_writer" set to itself. No? Am I missing
> something.
Unless I am reading the patch wrongly, it seems cpu_hotplug_begin() is called
while holding the cpu_add_remove_lock mutex. So, another CPU cannot come in
and do the same until _cpu_down() is over.
Thanks
Dipankar
-
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] ssb: Fix regression in 2.6.23-git3 due to change in calling add_uevent_var
On Sat, Oct 13, 2007 at 11:46:47PM -0500, Larry Finger wrote: > In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence > for add_uevent_var was changed, but the ssb driver was not modified, which > leads to a "Unable to handle kernel paging request" oops. This patch fixes > the problem. Sorry, Al Viro got a patch merged before I got to yours! Thanks anyway! John -- John W. Linville [EMAIL PROTECTED] - 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] missing include in mmc
On Tue, Oct 16, 2007 at 05:25:51PM -0700, David Brownell wrote: > > From [EMAIL PROTECTED] Tue Oct 16 17:18:43 2007 > > Date: Wed, 17 Oct 2007 01:09:07 +0100 > > From: Al Viro <[EMAIL PROTECTED]> > > To: Linus Torvalds <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED], linux-kernel@vger.kernel.org > > Subject: [PATCH] missing include in mmc > > > > AFAICS, fallout from repacing include of blkdev.h with include of bio.h. > > Out of curiousity, which architecture(s) need this? Umm... IIRC, m32r had been the first build to step into that, at which point the missing include had been added; the rest had reached that point later, so I'm not sure which ones would trigger the same crap. Not hard to test, though... Aha. m68k as well. - 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 -mm -v5 0/3] i386/x86_64 boot: 32-bit boot protocol
On Fri, 2007-10-12 at 13:52 +0800, Huang, Ying wrote: > Known Issues: > > - Where is safe to place the linked list of setup_data? Because the > length of the linked list of setup_data is variable, it can not be > copied into BSS segment of kernel as that of "zero page". We must > find a safe place for it, where it will not be overwritten by kernel > during booting up. The i386 kernel will overwrite some pages after > _end. The x86_64 kernel will overwrite some pages from 0x1000 on. Do you think it is a good idea to check the collision between setup data and memory area used during kernel boot through bootmem allocator? If any memory area used by setup data is reserved in bootmem allocator by some other kernel subsystem, there is a collision, otherwise, the setup data should be safe. Best Regards, Huang Ying - 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 4/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
Make use of the previously split out pcie_init_enable_events() function
to reinitialize the hotplug hardware on resume from suspend,
but only when pciehp_force==1. Otherwise behaviour is unmodified.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-16 21:17:27.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-16 21:28:36.0
-0400
@@ -37,7 +37,6 @@
#include "pciehp.h"
static void interrupt_event_handler(struct work_struct *work);
-static int pciehp_disable_slot(struct slot *p_slot);
static int queue_interrupt_event(struct slot *p_slot, u32 event_type)
{
--- old/drivers/pci/hotplug/pciehp.h2007-10-16 21:17:27.0 -0400
+++ linux/drivers/pci/hotplug/pciehp.h 2007-10-16 21:28:42.0 -0400
@@ -162,6 +162,8 @@
extern void pciehp_queue_pushbutton_work(struct work_struct *work);
int pcie_init(struct controller *ctrl, struct pcie_device *dev);
int pciehp_enable_slot(struct slot *p_slot);
+int pciehp_disable_slot(struct slot *p_slot);
+int pcie_init_enable_events(struct controller *ctrl, struct pcie_device *dev);
static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8 device)
{
--- old/drivers/pci/hotplug/pciehp_core.c 2007-10-16 21:17:27.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-16 21:30:19.0
-0400
@@ -512,6 +512,24 @@
static int pciehp_resume (struct pcie_device *dev)
{
printk("%s ENTRY\n", __FUNCTION__);
+ if (pciehp_force) {
+ struct pci_dev *pdev = dev->port;
+ struct controller *ctrl = pci_get_drvdata(pdev);
+ struct slot *t_slot;
+ u8 status;
+
+ /* reinitialize the chipset's event detection logic */
+ pcie_init_enable_events(ctrl, dev);
+
+ t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
+
+ /* Check if slot is occupied */
+ t_slot->hpc_ops->get_adapter_status(t_slot, );
+ if (status)
+ pciehp_enable_slot(t_slot);
+ else
+ pciehp_disable_slot(t_slot);
+ }
return 0;
}
#endif
-
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/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
Fix pciehp_probe() to deal with pre-inserted ExpressCard cards,
but only when pciehp_force==1. Otherwise behaviour is unmodified.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-16 21:14:44.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-16 21:16:36.0
-0400
@@ -37,7 +37,6 @@
#include "pciehp.h"
static void interrupt_event_handler(struct work_struct *work);
-static int pciehp_enable_slot(struct slot *p_slot);
static int pciehp_disable_slot(struct slot *p_slot);
static int queue_interrupt_event(struct slot *p_slot, u32 event_type)
--- old/drivers/pci/hotplug/pciehp.h2007-10-12 12:43:44.0 -0400
+++ linux/drivers/pci/hotplug/pciehp.h 2007-10-16 21:16:06.0 -0400
@@ -161,6 +161,7 @@
extern int pciehp_unconfigure_device(struct slot *p_slot);
extern void pciehp_queue_pushbutton_work(struct work_struct *work);
int pcie_init(struct controller *ctrl, struct pcie_device *dev);
+int pciehp_enable_slot(struct slot *p_slot);
static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8 device)
{
--- old/drivers/pci/hotplug/pciehp_core.c 2007-10-16 21:14:44.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-16 21:15:56.0
-0400
@@ -477,7 +477,8 @@
rc = t_slot->hpc_ops->power_off_slot(t_slot);
if (rc)
goto err_out_free_ctrl_slot;
- }
+ } else if (pciehp_force)
+ pciehp_enable_slot(t_slot);
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
Split out the hotplug hardware initialization code from pcie_init()
into pcie_init_enable_events(), without changing any functionality.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp_hpc.c2007-10-16 21:14:44.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_hpc.c 2007-10-16 21:21:11.0
-0400
@@ -1163,101 +1163,23 @@
}
#endif
-int pcie_init(struct controller *ctrl, struct pcie_device *dev)
+int pcie_init_enable_events(struct controller *ctrl, struct pcie_device *dev)
{
int rc;
u16 temp_word;
- u16 cap_reg;
u16 intr_enable = 0;
u32 slot_cap;
- int cap_base;
- u16 slot_status, slot_ctrl;
+ u16 slot_status;
struct pci_dev *pdev;
DBG_ENTER_ROUTINE
pdev = dev->port;
- ctrl->pci_dev = pdev;/* save pci_dev in context */
-
- dbg("%s: hotplug controller vendor id 0x%x device id 0x%x\n",
- __FUNCTION__, pdev->vendor, pdev->device);
-
- if ((cap_base = pci_find_capability(pdev, PCI_CAP_ID_EXP)) == 0) {
- dbg("%s: Can't find PCI_CAP_ID_EXP (0x10)\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
-
- ctrl->cap_base = cap_base;
-
- dbg("%s: pcie_cap_base %x\n", __FUNCTION__, cap_base);
-
- rc = pciehp_readw(ctrl, CAPREG, _reg);
- if (rc) {
- err("%s: Cannot read CAPREG register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: CAPREG offset %x cap_reg %x\n",
- __FUNCTION__, ctrl->cap_base + CAPREG, cap_reg);
-
- if (((cap_reg & SLOT_IMPL) == 0)
- || (((cap_reg & DEV_PORT_TYPE) != 0x0040)
- && ((cap_reg & DEV_PORT_TYPE) != 0x0060))) {
- dbg("%s : This is not a root port"
- " or the port is not connected to a slot\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
-
rc = pciehp_readl(ctrl, SLOTCAP, _cap);
if (rc) {
err("%s: Cannot read SLOTCAP register\n", __FUNCTION__);
goto abort_free_ctlr;
}
- dbg("%s: SLOTCAP offset %x slot_cap %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTCAP, slot_cap);
-
- if (!(slot_cap & HP_CAP)) {
- dbg("%s : This slot is not hot-plug capable\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- /* For debugging purpose */
- rc = pciehp_readw(ctrl, SLOTSTATUS, _status);
- if (rc) {
- err("%s: Cannot read SLOTSTATUS register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: SLOTSTATUS offset %x slot_status %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTSTATUS, slot_status);
-
- rc = pciehp_readw(ctrl, SLOTCTRL, _ctrl);
- if (rc) {
- err("%s: Cannot read SLOTCTRL register\n", __FUNCTION__);
- goto abort_free_ctlr;
- }
- dbg("%s: SLOTCTRL offset %x slot_ctrl %x\n",
- __FUNCTION__, ctrl->cap_base + SLOTCTRL, slot_ctrl);
-
- for ( rc = 0; rc < DEVICE_COUNT_RESOURCE; rc++)
- if (pci_resource_len(pdev, rc) > 0)
- dbg("pci resource[%d] start=0x%llx(len=0x%llx)\n", rc,
- (unsigned long long)pci_resource_start(pdev, rc),
- (unsigned long long)pci_resource_len(pdev, rc));
-
- info("HPC vendor_id %x device_id %x ss_vid %x"
- " ss_did %x\n", pdev->vendor, pdev->device,
- pdev->subsystem_vendor, pdev->subsystem_device);
-
- mutex_init(>crit_sect);
- mutex_init(>ctrl_lock);
- spin_lock_init(>lock);
-
- /* setup wait queue */
- init_waitqueue_head(>queue);
-
- /* return PCI Controller Info */
- ctrl->slot_device_offset = 0;
- ctrl->num_slots = 1;
- ctrl->first_slot = slot_cap >> 19;
- ctrl->ctrlcap = slot_cap & 0x007f;
/* Mask Hot-plug Interrupt Enable */
rc = pciehp_readw(ctrl, SLOTCTRL, _word);
@@ -1346,7 +1268,7 @@
temp_word = (temp_word & ~HP_INTR_ENABLE) | HP_INTR_ENABLE;
}
- /* Unmask Hotplug Intr Enable for intr notification mechanism case */
+ /* Unmask hp Interrupt Enable for intr notification mechanism case */
rc = pciehp_writew(ctrl, SLOTCTRL, temp_word);
if (rc) {
err("%s: Cannot write to SLOTCTRL register\n", __FUNCTION__);
@@ -1374,8 +1296,6 @@
goto abort_disable_intr;
}
- ctrl->hpc_ops = _hpc_ops;
-
DBG_LEAVE_ROUTINE
return 0;
@@ -1399,3 +1319,111 @@
DBG_LEAVE_ROUTINE
return -1;
}
+
+int pcie_init(struct controller *ctrl, struct pcie_device *dev)
+{
+ int rc;
+ u16 cap_reg;
+ u32 slot_cap;
+ int cap_base;
+ u16 slot_status, slot_ctrl;
+ struct pci_dev *pdev;
+
+ DBG_ENTER_ROUTINE
+
+ pdev =
[PATCH 1/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
Whitespace and other cosmetic fixes so that checkpatch.pl
is happy with the remainder of patches in this series.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/drivers/pci/hotplug/pciehp_core.c 2007-10-12 12:43:44.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_core.c 2007-10-16 21:14:03.0
-0400
@@ -470,9 +470,11 @@
t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
- t_slot->hpc_ops->get_adapter_status(t_slot, ); /* Check if slot
is occupied */
+ /* Check if slot is occupied */
+ t_slot->hpc_ops->get_adapter_status(t_slot, );
if ((POWER_CTRL(ctrl->ctrlcap)) && !value) {
- rc = t_slot->hpc_ops->power_off_slot(t_slot); /* Power off slot
if not occupied*/
+ /* Power off slot if not occupied*/
+ rc = t_slot->hpc_ops->power_off_slot(t_slot);
if (rc)
goto err_out_free_ctrl_slot;
}
--- old/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-16 21:12:54.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_ctrl.c 2007-10-16 21:08:18.0
-0400
@@ -520,7 +520,7 @@
case INT_PRESENCE_OFF:
if (!HP_SUPR_RM(ctrl->ctrlcap))
break;
- dbg("Surprise Removal\n");
+ dbg("Surprise Event\n");
update_slot_info(p_slot);
handle_surprise_event(p_slot);
break;
--- old/drivers/pci/hotplug/pciehp_hpc.c2007-10-16 21:12:54.0
-0400
+++ linux/drivers/pci/hotplug/pciehp_hpc.c 2007-10-16 21:13:32.0
-0400
@@ -160,10 +160,10 @@
/* Link Width Encoding */
#define LNK_X1 0x01
#define LNK_X2 0x02
-#define LNK_X4 0x04
+#define LNK_X4 0x04
#define LNK_X8 0x08
#define LNK_X12 0x0C
-#define LNK_X160x10
+#define LNK_X160x10
#define LNK_X32 0x20
/*Field definitions of Link Status Register */
@@ -289,7 +289,7 @@
u16 slot_ctrl;
unsigned long flags;
- DBG_ENTER_ROUTINE
+ DBG_ENTER_ROUTINE
mutex_lock(>ctrl_lock);
@@ -299,7 +299,7 @@
goto out;
}
- if ((slot_status & CMD_COMPLETED) == CMD_COMPLETED ) {
+ if ((slot_status & CMD_COMPLETED) == CMD_COMPLETED) {
/* After 1 sec and CMD_COMPLETED still not set, just
proceed forward to issue the next command according
to spec. Just print out the error message */
@@ -332,7 +332,7 @@
retval = pcie_wait_cmd(ctrl);
out:
mutex_unlock(>ctrl_lock);
- DBG_LEAVE_ROUTINE
+ DBG_LEAVE_ROUTINE
return retval;
}
@@ -341,7 +341,7 @@
u16 lnk_status;
int retval = 0;
- DBG_ENTER_ROUTINE
+ DBG_ENTER_ROUTINE
retval = pciehp_readw(ctrl, LNKSTATUS, _status);
if (retval) {
@@ -350,14 +350,14 @@
}
dbg("%s: lnk_status = %x\n", __FUNCTION__, lnk_status);
- if ( (lnk_status & LNK_TRN) || (lnk_status & LNK_TRN_ERR) ||
+ if ((lnk_status & LNK_TRN) || (lnk_status & LNK_TRN_ERR) ||
!(lnk_status & NEG_LINK_WD)) {
err("%s : Link Training Error occurs \n", __FUNCTION__);
retval = -1;
return retval;
}
- DBG_LEAVE_ROUTINE
+ DBG_LEAVE_ROUTINE
return retval;
}
@@ -368,8 +368,8 @@
u16 slot_ctrl;
u8 atten_led_state;
int retval = 0;
-
- DBG_ENTER_ROUTINE
+
+ DBG_ENTER_ROUTINE
retval = pciehp_readw(ctrl, SLOTCTRL, _ctrl);
if (retval) {
@@ -400,7 +400,7 @@
break;
}
- DBG_LEAVE_ROUTINE
+ DBG_LEAVE_ROUTINE
return 0;
}
@@ -410,8 +410,8 @@
u16 slot_ctrl;
u8 pwr_state;
int retval = 0;
-
- DBG_ENTER_ROUTINE
+
+ DBG_ENTER_ROUTINE
retval = pciehp_readw(ctrl, SLOTCTRL, _ctrl);
if (retval) {
@@ -428,14 +428,14 @@
*status = 1;
break;
case 1:
- *status = 0;
+ *status = 0;
break;
default:
*status = 0xFF;
break;
}
- DBG_LEAVE_ROUTINE
+ DBG_LEAVE_ROUTINE
return retval;
}
@@ -446,7 +446,7 @@
u16 slot_status;
int retval = 0;
- DBG_ENTER_ROUTINE
+ DBG_ENTER_ROUTINE
retval = pciehp_readw(ctrl, SLOTSTATUS, _status);
if (retval) {
@@ -454,9 +454,9 @@
return retval;
}
- *status = (((slot_status & MRL_STATE) >> 5) == 0) ? 0 : 1;
+ *status = (((slot_status & MRL_STATE) >> 5) == 0) ? 0 : 1;
- DBG_LEAVE_ROUTINE
+ DBG_LEAVE_ROUTINE
return 0;
}
@@ -467,7 +467,7 @@
u8 card_state;
int retval = 0;
- DBG_ENTER_ROUTINE
+ DBG_ENTER_ROUTINE
retval = pciehp_readw(ctrl, SLOTSTATUS, _status);
if (retval) {
@@ -477,7 +477,7 @@
card_state = (u8)((slot_status & PRSN_STATE) >> 6);
[PATCH 0/4] Fix PCIe hotplug for non-ACPI ExpressCard slots (version 2)
Original single patch is now broken out into tiny pieces for easier review. Also, valuable feedback from Ted has been incorporated, to avoid any possible side effects on regular use of the PCIe hotplug stuff (when used without pciehp_force=1 mod parm). * * * Fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks in conjunction with the modparam of pciehp_force=1. The PCIe Hotplug driver has two shortcomings when used on Dell notebooks which lack ACPI BIOS support for PCIe hotplug: 1. The driver does not recognise cards that were inserted prior to the driver being modprobe'd. 2. The driver stops functioning after a suspend/resume (RAM) cycle, and needs to be rmmod'd and modprobe'd to get it working again. This patch series addresses those issues, resulting in a completely functional PCIe Hotplug driver for Dell notebooks, and probably others as well, which may lack ACPI BIOS support for this. There are four patches in this series: 01_pciehp_cosmetic_fixes.patch -- cosmetic fixes, mostly to keep checkpatch.pl happy 02_pciehp_handle_preinserted_card.patch -- fixes problem number 1 (above). 03_pciehp_split_pcie_init.patch -- preparation for the resume patch. 04_pciehp_resume.patch -- fixes problem number 2 (above). diffstat summary for 01_pciehp_cosmetic_fixes.patch only: drivers/pci/hotplug/pciehp_core.c |6 - drivers/pci/hotplug/pciehp_ctrl.c |2 drivers/pci/hotplug/pciehp_hpc.c | 119 ++-- 3 files changed, 65 insertions(+), 62 deletions(-) diffstat summary for the other three patches combined: drivers/pci/hotplug/pciehp.h |3 drivers/pci/hotplug/pciehp_core.c | 21 ++- drivers/pci/hotplug/pciehp_ctrl.c |2 drivers/pci/hotplug/pciehp_hpc.c | 194 4 files changed, 134 insertions(+), 86 deletions(-) Cheers -- Mark Lord <[EMAIL PROTECTED]> - 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][rfc] rewrite ramdisk
On Wednesday 17 October 2007 11:13, Eric W. Biederman wrote: > Nick Piggin <[EMAIL PROTECTED]> writes: > > We have 2 problems. First is that, for testing/consistency, we > > don't want BLKFLSBUF to throw out the data. Maybe hardly anything > > uses BLKFLSBUF now, so it could be just a minor problem, but still > > one to fix. > > Hmm. This is interesting because we won't be doing anything that > effects correctness if we don't special case BLKFLSBUF just something > that effects efficiency. So I think we can get away with just > changing blkflsbuf as long as there is a way to get rid of > the data. Technically, it does change correctness: after BLKFLSBUF, the ramdisk should contain zeroes. I'm assuming it would also cause problems in tight embedded environments if ramdisk ram is supposed to be thrown away but isn't. So maybe not technically a correctness problem, but could be the difference between working and not working. > > Second is actually throwing out the ramdisk data. dd from /dev/null > > isn't trivial because it isn't a "command" from the kernel's POV. > > rd could examine the writes to see if they are zero and page aligned, > > I suppose... but if you're transitioning everyone over to a new > > method anyway, might as well make it a nice one ;) > > Well I was thinking you can examine the page you just wrote to > and if it is all zero's you don't need to cache that page anymore. > Call it intelligent compression. > > Further it does make forwards and backwards compatibility simple > because all you would have to do to reliably free a ramdisk is: > > dd if=/dev/zero of=/dev/ramX > blockdev --flushbufs /dev/ramX Sure, you could do that, but you still presumably need to support the old behaviour. As a test vehicle for filesystems, I'd much rather it didn't do this of course, because subsequent writes would need to reallocate the page again. - 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 3/3] document dma_flags_set/get_*()
Document the dma_flags_set/get_*() interfaces. Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]> --- DMA-API.txt | 38 ++ 1 files changed, 38 insertions(+) diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index b939ebb..00919b0 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -547,3 +547,41 @@ size is the size (and should be a page-sized multiple). The return value will be either a pointer to the processor virtual address of the memory, or an error (via PTR_ERR()) if any part of the region is occupied. + +int +dma_flags_set_attr(u32 attr, enum dma_data_direction dir) + +Amend dir with a platform-specific "dma attribute". + +The only attribute currently defined is DMA_BARRIER_ATTR, which causes +in-flight DMA to be flushed when the associated memory region is written +to (see example below). Setting DMA_BARRIER_ATTR provides a mechanism +to enforce ordering of DMA on platforms that permit DMA to be reordered +between device and host memory (within a NUMA interconnect). On other +platforms this is a nop. + +DMA_BARRIER_ATTR would be set when the memory region is mapped for DMA, +e.g.: + + int count; + int flags = dma_flags_set_attr(DMA_BARRIER_ATTR, DMA_BIDIRECTIONAL); + + count = dma_map_sg(dev, sglist, nents, flags); + +As an example of a situation where this would be useful, suppose that +the device does a DMA write to indicate that data is ready and +available in memory. The DMA of the "completion indication" could +race with data DMA. Using DMA_BARRIER_ATTR on the memory used for +completion indications would prevent the race. + +int +dma_flags_get_dir(int flags) + +Retrieve the original DMA direction, where flags was returned from +dma_flags_set_attr(). + +int +dma_flags_get_attr(int flags) + +Retrieve the "dma attributes", where flags was returned from +dma_flags_set_attr(). - 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/3] dma: redefine dma_flags_set/get_*() for sn-ia64
Redefine dma_flags_set/get_*() for sn-ia64.
dma_flags_set_attr() "borrows" bits from the dma_map_* routines'
direction arguments (renamed "flags"). It uses the borrowed bits
to pass additional attributes.
dma_flags_get_dir() and dma_flags_get_attr() return the direction
and attributes that were set with dma_flags_set_attr().
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
arch/ia64/sn/pci/pci_dma.c | 37 +++--
include/asm-ia64/sn/io.h | 27 +++
2 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/arch/ia64/sn/pci/pci_dma.c b/arch/ia64/sn/pci/pci_dma.c
index ecd8a52..73d3897 100644
--- a/arch/ia64/sn/pci/pci_dma.c
+++ b/arch/ia64/sn/pci/pci_dma.c
@@ -153,7 +153,7 @@ EXPORT_SYMBOL(sn_dma_free_coherent);
* @dev: device to map for
* @cpu_addr: kernel virtual address of the region to map
* @size: size of the region
- * @direction: DMA direction
+ * @flags: DMA direction, and arch-specific attributes
*
* Map the region pointed to by @cpu_addr for DMA and return the
* DMA address.
@@ -167,17 +167,23 @@ EXPORT_SYMBOL(sn_dma_free_coherent);
* figure out how to save dmamap handle so can use two step.
*/
dma_addr_t sn_dma_map_single(struct device *dev, void *cpu_addr, size_t size,
-int direction)
+int flags)
{
dma_addr_t dma_addr;
unsigned long phys_addr;
struct pci_dev *pdev = to_pci_dev(dev);
struct sn_pcibus_provider *provider = SN_PCIDEV_BUSPROVIDER(pdev);
+ int dmabarrier = dma_flags_get_attr(flags) & DMA_BARRIER_ATTR;
BUG_ON(dev->bus != _bus_type);
phys_addr = __pa(cpu_addr);
- dma_addr = provider->dma_map(pdev, phys_addr, size, SN_DMA_ADDR_PHYS);
+ if (dmabarrier)
+ dma_addr = provider->dma_map_consistent(pdev, phys_addr, size,
+ SN_DMA_ADDR_PHYS);
+ else
+ dma_addr = provider->dma_map(pdev, phys_addr, size,
+SN_DMA_ADDR_PHYS);
if (!dma_addr) {
printk(KERN_ERR "%s: out of ATEs\n", __FUNCTION__);
return 0;
@@ -241,18 +247,20 @@ EXPORT_SYMBOL(sn_dma_unmap_sg);
* @dev: device to map for
* @sg: scatterlist to map
* @nhwentries: number of entries
- * @direction: direction of the DMA transaction
+ * @flags: direction of the DMA transaction, and arch-specific attributes
*
* Maps each entry of @sg for DMA.
*/
int sn_dma_map_sg(struct device *dev, struct scatterlist *sgl, int nhwentries,
- int direction)
+ int flags)
{
unsigned long phys_addr;
struct scatterlist *saved_sg = sgl, *sg;
struct pci_dev *pdev = to_pci_dev(dev);
struct sn_pcibus_provider *provider = SN_PCIDEV_BUSPROVIDER(pdev);
int i;
+ int dmabarrier = dma_flags_get_attr(flags) & DMA_BARRIER_ATTR;
+ int dir = dma_flags_get_dir(flags);
BUG_ON(dev->bus != _bus_type);
@@ -260,19 +268,28 @@ int sn_dma_map_sg(struct device *dev, struct scatterlist
*sgl, int nhwentries,
* Setup a DMA address for each entry in the scatterlist.
*/
for_each_sg(sgl, sg, nhwentries, i) {
+ dma_addr_t dma_addr;
phys_addr = SG_ENT_PHYS_ADDRESS(sg);
- sg->dma_address = provider->dma_map(pdev,
- phys_addr, sg->length,
- SN_DMA_ADDR_PHYS);
- if (!sg->dma_address) {
+ if (dmabarrier) {
+ dma_addr = provider->dma_map_consistent(pdev,
+ phys_addr,
+ sg->length,
+
SN_DMA_ADDR_PHYS);
+ } else {
+ dma_addr = provider->dma_map(pdev,
+phys_addr, sg->length,
+SN_DMA_ADDR_PHYS);
+ }
+
+ if (!(sg->dma_address = dma_addr)) {
printk(KERN_ERR "%s: out of ATEs\n", __FUNCTION__);
/*
* Free any successfully allocated entries.
*/
if (i > 0)
- sn_dma_unmap_sg(dev, saved_sg, i, direction);
+ sn_dma_unmap_sg(dev, saved_sg, i, dir);
return 0;
}
diff --git a/include/asm-ia64/sn/io.h b/include/asm-ia64/sn/io.h
index 41c73a7..52a6fdb 100644
--- a/include/asm-ia64/sn/io.h
+++ b/include/asm-ia64/sn/io.h
@@ -271,4 +271,31 @@ sn_pci_set_vchan(struct pci_dev *pci_dev, unsigned long
*addr, int vchan)
return
[PATCH 1/3] dma: add dma_flags_set/get_*() interfaces
Introduce the dma_flags_set/get_*() interfaces and give them
default implementations.
Architectures which allow DMA to be reordered between a device and
host memory (within a NUMA interconnect) can redefine these to allow
a driver to explicitly synchronize DMA from the device when necessary.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
Andrew, this is the first in a series of three patches:
[1/3] dma: add dma_flags_set/get_*() interfaces
[2/3] dma: redefine dma_flags_set/get_*() for sn-ia64
[3/3] dma: document dma_flags_set/get_*()
Variants of these patches have been discussed on several
occasions, most recently in a thread beginning:
http://marc.info/?l=linux-kernel=119137949604365=2
Please consider this for 2.6.24.
Jes, Tony, please note that I added an explicit test for
CONFIG_IA64_SGI_SN2 in asm-ia64/sn/io.h (Yuck). This is
needed for IA64_GENERIC to build, since there's at least one
driver (qla1280) that includes asm-ia64/sn/io.h for
CONFIG_IA64_GENERIC.
dma-mapping.h | 18 ++
1 files changed, 18 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 0ebfafb..132b559 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -106,4 +106,22 @@ static inline void dmam_release_declared_memory(struct
device *dev)
}
#endif /* ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY */
+#define DMA_BARRIER_ATTR 0x1
+#ifndef ARCH_USES_DMA_ATTRS
+static inline int dma_flags_set_attr(u32 attr, enum dma_data_direction dir)
+{
+ return dir;
+}
+
+static inline int dma_flags_get_dir(int flags)
+{
+ return flags;
+}
+
+static inline int dma_flags_get_attr(int flags)
+{
+ return 0;
+}
+#endif /* ARCH_USES_DMA_ATTRS */
+
#endif
-
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-usb-devel] usb+sysfs: duplicate filename 'bInterfaceNumber'
>On 10/17/07, Matthew Dharm <[EMAIL PROTECTED]> wrote: > On Tue, Oct 16, 2007 at 02:04:43PM -0400, Alan Stern wrote: > > On Tue, 16 Oct 2007, Matthew Dharm wrote: > > > > > I haven't looked at this code at all, but neither approach feels right to > > > me. > > > > > > How does this work at all? Even if you load a driver later, wouldn't it > > > call usb_set_interface(), which would call usb_create_sysfs_intf_files() > > > and hit the same issue? > > > > usb_set_interface() is smart enough to remove the old interface files > > before creating new ones, since it expects them to exist already. > > Hence there's no problem in that scenario. > > > > But usb_set_configuration doesn't expect there to be any pre-existing > > interface files, because there isn't even an interface until the > > registration is performed. > > And I'm guessing that you can't call usb_create_sysfs_intf_files() until > registration is performed, right? > > > The most important reason has to do with the endpoint pseudo-devices. > > Different altsettings can have different endpoints, so those have to be > > removed and re-created whenever the altsetting changes. > > Right, altsettings. I forgot about those. I only ever think in terms of > multiple configurations. > > *grumble* > > If usb_set_interface() has to be smart enough to remove existing files > first already, then I guess it's reasonably symmetric to have > usb_set_configuration() have the same smarts. Maybe they can share some > common code, even. > > Matt > > -- > Matthew Dharm Home: [EMAIL PROTECTED] > Maintainer, Linux USB Mass Storage Driver > > C: Why are you upgrading to NT? > AJ: It must be the sick, sadistic streak that runs through me. > -- Chief and A.J. > User Friendly, 5/12/1998 > Hi, I prefer "remove then create". But IMHO the sysfs or driver core layer should have such functions to set some bit for the sysfs files creating. Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix adbhid mismerge
On Wed, 17 Oct 2007, Al Viro wrote: > > Something really odd has happened: the last couple of changesets > have > - int up_flag; > + int keycode, up_flag; > and > - int up_flag; > + int up_flag, key; > in another, both in adb_input_keycode(). Even with -m passed to > git-whatchanged there's no sign of anything in that area. I don't think you did anything wrong. You used both --full-history (implicitly: git-whatchanged) and you made sure to see the diffs for both sides of any merge (-m), and that means that you should see every single diff involved. Looking into it, the "key" variable was declared in the commit that introduced the new line int up_flag, key; .. key = adbhid[id]->keycode[keycode]; which is commit 555ddbb4e2191c8823df2d61525218ac39481385. But then that declaration of "int key" goes away at some later time. And doing a git whatchanged -p -m 555ddbb4e2191c8823df2d61525218ac39481385.. drivers/macintosh/adbhid.c does actually show the culprit. It's just that the "-p -m" format is so damn unreadable that it's almost impossible to see. Anyway, it's b981d8b3f5e008ff10d993be633ad00564fc22cd, which had a conflict in that file, and Dmitry apparently mis-merged it and edited the result down so that it didn't have 'key' declared any more. So the way I found it was to just search for the line in the diffs that makes that thing go away, ie just look for the line in the diffs that says - int up_flag, key; and then you need to look at which of those are totally bogus and are just because it shows the diff against one of the earlier trees that also don't have that "key = adbhid[...]" line! (And that is actually *much* less obvious than it should be, since a lot of the case of those lines going away is becuase I had merged Dmitry's tree in the first place) You can make git help you narrow it down a bit more by using -S, ie some horrible command line from hell like this: git whatchanged -S'int up_flag, key;' -m -p \ 555ddbb4e2191c8823df2d61525218ac39481385.. \ drivers/macintosh/adbhid.c will actually show only those commits that add/remove a line like the one you are wondering where it went. That can cut down on the noise a bit, but you'll get all the same false alarms, so no, it's probably not worth it. In general, I'm afraid that merge errors are simply not very easy to find. The problem in this case is in that b981d8b3f5 merge, but if you actually then do a "git show b981d8b3f5" you won't even see the problem spot in the default "--cc" format output, because Dmitry had resolved that problmatic place to be the same as one of the parent branches, and that makes git not show the diff for it (since it's "uninteresting") Linus - 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/
[git patches] net driver fixes (mostly)
Mostly fixes, except a couple things from Stephen H and myself.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/3c59x.c |8 +-
drivers/net/Kconfig | 10 +
drivers/net/bonding/bond_main.c | 11 +-
drivers/net/bonding/bonding.h |4 +-
drivers/net/e1000e/ethtool.c| 35 ++-
drivers/net/e1000e/hw.h |2 +-
drivers/net/forcedeth.c | 168 --
drivers/net/gianfar.c |7 +-
drivers/net/ibm_newemac/mal.c | 25 ++-
drivers/net/skge.c | 485 ++-
drivers/net/skge.h | 17 +-
drivers/net/tokenring/3c359.c |2 +-
12 files changed, 558 insertions(+), 216 deletions(-)
Adrian Bunk (1):
e1000e: fix error checks
Auke Kok (2):
e1000e: Fix debug printk macro
e1000e: don't poke PHY registers to retreive link status
Benjamin Herrenschmidt (1):
net: Fix new EMAC driver for NAPI changes
Ingo Molnar (1):
forcedeth: fix NAPI rx poll function
Jay Vosburgh (1):
bonding: two small fixes for IPoIB support
Jeff Garzik (2):
[netdrvr] forcedeth: improved probe info; dev_printk() cleanups
[netdrvr] forcedeth: remove in-driver copy of net_device_stats
Li Yang (1):
gianfar: Fix compile regression caused by 09f75cd7
Marcus Meissner (1):
tokenring/3c359.c: fixed array index problem
Steffen Klassert (1):
WOL bugfix for 3c59x.c
Stephen Hemminger (7):
skge: fix ram buffer size calculation
skge: changing MTU while running causes problems
skge: XM PHY handling fixes
skge: internal stats
skge: eeprom support
skge: add a debug interface
skge 1.12
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 8d3893d..862f472 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -3118,7 +3118,13 @@ static void acpi_set_WOL(struct net_device *dev)
iowrite16(SetRxFilter|RxStation|RxMulticast|RxBroadcast, ioaddr
+ EL3_CMD);
iowrite16(RxEnable, ioaddr + EL3_CMD);
- pci_enable_wake(VORTEX_PCI(vp), 0, 1);
+ if (pci_enable_wake(VORTEX_PCI(vp), PCI_D3hot, 1)) {
+ printk(KERN_INFO "%s: WOL not supported.\n",
+ pci_name(VORTEX_PCI(vp)));
+
+ vp->enable_wol = 0;
+ return;
+ }
/* Change the power state to D3; RxEnable doesn't take effect.
*/
pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot);
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8f99a06..83d52c8 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2173,6 +2173,16 @@ config SKGE
To compile this driver as a module, choose M here: the module
will be called skge. This is recommended.
+config SKGE_DEBUG
+ bool "Debugging interface"
+ depends on SKGE && DEBUG_FS
+ help
+This option adds the ability to dump driver state for debugging.
+The file debugfs/skge/ethX displays the state of the internal
+transmit and receive rings.
+
+If unsure, say N.
+
config SKY2
tristate "SysKonnect Yukon2 support"
depends on PCI
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index db80f24..6f85cc3 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1263,6 +1263,7 @@ static void bond_setup_by_slave(struct net_device
*bond_dev,
struct bonding *bond = bond_dev->priv;
bond_dev->neigh_setup = slave_dev->neigh_setup;
+ bond_dev->header_ops= slave_dev->header_ops;
bond_dev->type = slave_dev->type;
bond_dev->hard_header_len = slave_dev->hard_header_len;
@@ -3351,7 +3352,10 @@ static int bond_slave_netdev_event(unsigned long event,
struct net_device *slave
switch (event) {
case NETDEV_UNREGISTER:
if (bond_dev) {
- bond_release(bond_dev, slave_dev);
+ if (bond->setup_by_slave)
+ bond_release_and_destroy(bond_dev, slave_dev);
+ else
+ bond_release(bond_dev, slave_dev);
}
break;
case NETDEV_CHANGE:
@@ -3366,11 +3370,6 @@ static int bond_slave_netdev_event(unsigned long event,
struct net_device *slave
* ... Or is it this?
*/
break;
- case NETDEV_GOING_DOWN:
- dprintk("slave %s is going down\n", slave_dev->name);
- if (bond->setup_by_slave)
- bond_release_and_destroy(bond_dev, slave_dev);
- break;
case NETDEV_CHANGEMTU:
/*
Re: [PATCH] tokenring/3c359.c: fixed array index problem
Marcus Meissner wrote: Hi, I tried to send this to netdev and various maintainers, but they seem not to have seen it. Please add to -mm and have it merged somewhere. The xl_laa array is just 6 bytes long, so we should substract 10 from the index, like is also done some lines above already. Signed-Off-By: Marcus Meissner <[EMAIL PROTECTED]> --- drivers/net/tokenring/3c359.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 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: [patch][rfc] rewrite ramdisk
Nick Piggin <[EMAIL PROTECTED]> writes: > On Wednesday 17 October 2007 09:48, Eric W. Biederman wrote: >> Nick Piggin <[EMAIL PROTECTED]> writes: >> > On Wednesday 17 October 2007 07:28, Theodore Tso wrote: >> >> On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote: >> >> > + /* >> >> > + * ram device BLKFLSBUF has special semantics, we want to actually >> >> > +* release and destroy the ramdisk data. >> >> > +*/ >> >> >> >> We won't be able to fix completely this for a while time, but the fact >> >> that BLKFLSBUF has special semantics has always been a major wart. >> >> Could we perhaps create a new ioctl, say RAMDISKDESTORY, and add a >> >> deperecation printk for BLKFLSBUF when passed to the ramdisk? I doubt >> >> there are many tools that actually take advantage of this wierd aspect >> >> of ramdisks, so hopefully it's something we could remove in a 18 >> >> months or so... >> > >> > It would be nice to be able to do that, I agree. The new ramdisk >> > code will be able to flush the buffer cache and destroy its data >> > separately, so it can actually be implemented. >> >> So the practical problem are peoples legacy boot setups but those >> are quickly going away. > > After that, is the ramdisk useful for anything aside from testing? > > >> The sane thing is probably something that can be taken as a low >> level format command for the block device. >> >> Say: dd if=/dev/zero of=/dev/ramX > > We have 2 problems. First is that, for testing/consistency, we > don't want BLKFLSBUF to throw out the data. Maybe hardly anything > uses BLKFLSBUF now, so it could be just a minor problem, but still > one to fix. Hmm. This is interesting because we won't be doing anything that effects correctness if we don't special case BLKFLSBUF just something that effects efficiency. So I think we can get away with just changing blkflsbuf as long as there is a way to get rid of the data. > Second is actually throwing out the ramdisk data. dd from /dev/null > isn't trivial because it isn't a "command" from the kernel's POV. > rd could examine the writes to see if they are zero and page aligned, > I suppose... but if you're transitioning everyone over to a new > method anyway, might as well make it a nice one ;) Well I was thinking you can examine the page you just wrote to and if it is all zero's you don't need to cache that page anymore. Call it intelligent compression. Further it does make forwards and backwards compatibility simple because all you would have to do to reliably free a ramdisk is: dd if=/dev/zero of=/dev/ramX blockdev --flushbufs /dev/ramX >> I know rewriting the drive with all zeroes can cause a modern >> disk to redo it's low level format. And that is something >> we can definitely implement without any backwards compatibility >> problems. >> >> Hmm. Do we have anything special for punching holes in files? >> That would be another sane route to take to remove the special >> case for clearing the memory. > > truncate_range, I suppose. A file descriptor syscall based > alternative for madvise would be nice though (like fallocate). > > We could always put something in /sys/block/ram*/xxx I guess when I look at this it looks like an operation that is unique to a ramdisk. Real hard drives have a low level format operations and the like. If we can find something standard there that is guaranteed to trash your data we can use that, and have gone from less consistency to more. Eric - 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: Regression: GRUB from openSUSE 10.2 doesn't boot current -git
On Wed, 17 Oct 2007 02:33:19 +0200 Rafael J. Wysocki wrote: > Hi, > > As stated in the subject, I cannot boot the current -git (most recent commit > 821f3eff7cdb9d6c7076effabd46c96c322daed1) using GRUB on x86-64 openSUSE 10.2. > > The GRUB says that the kernel image is too big and doesn't fit into memory, > but > the kernel has been built and installed in exactly the same way as all of the > previous -git kernels. kbuild patch from Sam should fix it: http://lkml.org/lkml/2007/10/16/395 or one from Eric: http://lkml.org/lkml/2007/10/16/429 --- ~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: arcmsr changelog differs from diffs
On 2007.10.17 00:07:19 +0200, Hans-Peter Jansen wrote:
> Hi Jeff,
>
> while browsing through Linus' current check ins, I stumbled upon:
>
> [SCSI] arcmsr: irq handler fixes, cleanups, micro-opts:
>
> --8<--
> 488a5c8a9a3b67ae117784cd0d73bef53a73d57d
> drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
> b/drivers/scsi/arcmsr/arcmsr_hba.c
> index 7832a10..f4d2d52 100644
> --- a/drivers/scsi/arcmsr/arcmsr_hba.c
> +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
> @@ -422,7 +422,7 @@ static int arcmsr_probe(struct pci_dev *pdev,
> goto out_release_regions;
>
> error = request_irq(pdev->irq, arcmsr_do_interrupt,
> - IRQF_SHARED, "arcmsr", acb);
> + IRQF_SHARED, "arcmsr", acb);
> if (error)
> goto out_free_ccb_pool;
>
> -->8--
>
> and: [SCSI] arcmsr: Fix hardware wait loops
>
> --8<--
> 24430458bb924e371ff894e26bfa9f73707f53fb
> drivers/scsi/arcmsr/arcmsr_hba.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
> b/drivers/scsi/arcmsr/arcmsr_hba.c
> index 50e1310..7832a10 100644
> --- a/drivers/scsi/arcmsr/arcmsr_hba.c
> +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
> @@ -2092,8 +2092,10 @@ static void arcmsr_iop_reset(struct
> AdapterControlBlock *acb)
> if (atomic_read(>ccboutstandingcount) != 0) {
> /* talk to iop 331 outstanding command aborted */
> arcmsr_abort_allcmd(acb);
> +
> /* wait for 3 sec for all command aborted*/
> ssleep(3);
> +
> /* disable all outbound interrupt */
> intmask_org = arcmsr_disable_outbound_ints(acb);
> /* clear all outbound posted Q */
> -->8--
>
> where both changelogs differ significantly from the actual diffs, which both
> are simple WS fixups and nothing else. Does qgit fools me here, or is
> anything else wrong on my side?
Nothing wrong on your side. I took a look at the second one, and
everything but the whitespace changes already found its way into Linus'
tree via 1a4f550a09f89e3a15eff1971bc9db977571b9f6. One hunk of the
original patch[1] was actually made redundant because the code was
removed in that commit, so that's probably what James fixed (see full
commit message).
And then, if I may guess, James probably just noticed that there were
changes left and commited them (while they were now down to just the
whitespace change), without checking what changes were actually left (no
offense intended). At least I think that git wouldn't cripple the diff
if the changes that James checked in were not already whitespace-only at
the time he commited them, and the git history of his tree seems to
agree.
Probably the other commit is similar.
Björn
[1] http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg11957.html
-
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: [RFC PATCH 1/4] Refcount Based Cpu-Hotplug Implementation
On Tuesday 16 October 2007 20:34:17 Gautham R Shenoy wrote:
> This patch implements a Refcount + Waitqueue based model for
> cpu-hotplug.
Hi Gautham,
I can't see where you re-initialize the completion.
> +static void cpu_hotplug_begin(void)
> +{
> + mutex_lock(_hotplug.lock);
> + cpu_hotplug.active_writer = current;
> + while (cpu_hotplug.refcount) {
> + mutex_unlock(_hotplug.lock);
> + wait_for_completion(_hotplug.readers_done);
> + mutex_lock(_hotplug.lock);
> + }
AFAICT this will busy-wait on the second CPU hotplug.
Cheers,
Rusty.
-
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: LFENCE instruction (was: [rfc][patch 3/3] x86: optimise barriers)
> > You already must not place any data structures into WC memory --- for
> > example, spinlocks wouldn't work there.
>
> What do you mean "already"?
I mean "in current kernel" (I checked it in 2.6.22)
> If we already have drivers loading data from
> WC memory, then rmb() needs to order them, whether or not they actually
> need it. If that were prohibitively costly, then we'd introduce a new
> barrier which does not order WC memory, right?
>
>
> > wmb() also won't work on WC
> > memory, because it assumes that writes are ordered.
>
> You mean the one defined like this:
> #define wmb() asm volatile("sfence" ::: "memory")
> ? If it assumed writes are ordered, then it would just be a barrier().
You read wrong part of the include file. Really, it is
(2.6.22,include/asm-i386/system.h):
#ifdef CONFIG_X86_OOSTORE
#define wmb() alternative("lock; addl $0,0(%%esp)", "sfence",
X86_FEATURE_XMM)
#else
#define wmb() __asm__ __volatile__ ("": : :"memory")
#endif
CONFIG_X86_OOSTORE is dependent on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6
--- so on Intel and AMD, it is really just barrier().
So drivers can't assume that wmb() works on write-combining memory.
> > > Doing that would lead to an unmaintainable mess. If drivers don't
> > > need rmb, then they don't call it.
> >
> > If wmb() doesn't currently work on write-combining memory, why should
> > rmb() work there?
>
> I don't understand why you say wmb() doesn't work on WC memory.
Because it is defined as __asm__ __volatile__ ("": : :"memory")
And WC memory can reorder writes (WB memory can't).
> > The purpose of rmb() is to enforce ordering on architectures that don't
> > force it in hardware --- that is not the case of x86.
>
> Well it clearly is the case because I just pointed you to a document
> that says they can go out of order.
> If you want to argue that existing
> implementations do not, then by all means go ahead and send a patch to
> Linus and see what he says about it ;)
I mean this: wmb() assumes that the data to be ordered are not in WC
memory. rmb() assumes that the data can be in WC memory (lfence is only
useful on WC --- it doesn't have any effect on other memory types).
Mikulas
-
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] trivial: fix do_sys_open() prototype
Fix an argument name in do_sys_open()'s prototype. Signed-off-by: Jason Uhlenkott <[EMAIL PROTECTED]> Index: linux/include/linux/fs.h === --- linux.orig/include/linux/fs.h 2007-10-16 15:19:26.632794062 -0700 +++ linux/include/linux/fs.h2007-10-16 16:46:38.000182413 -0700 @@ -1426,7 +1426,7 @@ extern int do_truncate(struct dentry *, loff_t start, unsigned int time_attrs, struct file *filp); -extern long do_sys_open(int fdf, const char __user *filename, int flags, +extern long do_sys_open(int dfd, const char __user *filename, int flags, int mode); extern struct file *filp_open(const char *, int, int); extern struct file * dentry_open(struct dentry *, struct vfsmount *, int); - 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] missing include in mmc
> From [EMAIL PROTECTED] Tue Oct 16 17:18:43 2007 > Date: Wed, 17 Oct 2007 01:09:07 +0100 > From: Al Viro <[EMAIL PROTECTED]> > To: Linus Torvalds <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], linux-kernel@vger.kernel.org > Subject: [PATCH] missing include in mmc > > AFAICS, fallout from repacing include of blkdev.h with include of bio.h. Out of curiousity, which architecture(s) need this? I did test builds on three, and didn't see a need for it ... > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > --- > diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c > index 71b986b..7ae18ea 100644 > --- a/drivers/mmc/host/mmc_spi.c > +++ b/drivers/mmc/host/mmc_spi.c > @@ -30,6 +30,7 @@ > #include > #include > #include > +#include > > #include > #include/* for R1_SPI_* bit values */ > - 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: ioctl32: Unknown cmd
David Miller <[EMAIL PROTECTED]> writes: > From: Arnd Bergmann <[EMAIL PROTECTED]> > Date: Tue, 16 Oct 2007 21:50:35 +0200 > > > The one point where it is expected to have changed now is when you > > try to do these ioctls on something that is not a block device. Are > > you sure that the files you tried them on were created correctly? > > Many many many programs do this exact sort of thing. > > It is one of the bad aspects of moving the compat handling > down into the file ops for a specific device. When this happens one should add respective IGNORE_IOCTL()s to compat_ioctl.c -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][rfc] rewrite ramdisk
On Wednesday 17 October 2007 09:48, Eric W. Biederman wrote: > Nick Piggin <[EMAIL PROTECTED]> writes: > > On Wednesday 17 October 2007 07:28, Theodore Tso wrote: > >> On Tue, Oct 16, 2007 at 05:47:12PM +1000, Nick Piggin wrote: > >> > +/* > >> > + * ram device BLKFLSBUF has special semantics, we want to > >> > actually > >> > + * release and destroy the ramdisk data. > >> > + */ > >> > >> We won't be able to fix completely this for a while time, but the fact > >> that BLKFLSBUF has special semantics has always been a major wart. > >> Could we perhaps create a new ioctl, say RAMDISKDESTORY, and add a > >> deperecation printk for BLKFLSBUF when passed to the ramdisk? I doubt > >> there are many tools that actually take advantage of this wierd aspect > >> of ramdisks, so hopefully it's something we could remove in a 18 > >> months or so... > > > > It would be nice to be able to do that, I agree. The new ramdisk > > code will be able to flush the buffer cache and destroy its data > > separately, so it can actually be implemented. > > So the practical problem are peoples legacy boot setups but those > are quickly going away. After that, is the ramdisk useful for anything aside from testing? > The sane thing is probably something that can be taken as a low > level format command for the block device. > > Say: dd if=/dev/zero of=/dev/ramX We have 2 problems. First is that, for testing/consistency, we don't want BLKFLSBUF to throw out the data. Maybe hardly anything uses BLKFLSBUF now, so it could be just a minor problem, but still one to fix. Second is actually throwing out the ramdisk data. dd from /dev/null isn't trivial because it isn't a "command" from the kernel's POV. rd could examine the writes to see if they are zero and page aligned, I suppose... but if you're transitioning everyone over to a new method anyway, might as well make it a nice one ;) > I know rewriting the drive with all zeroes can cause a modern > disk to redo it's low level format. And that is something > we can definitely implement without any backwards compatibility > problems. > > Hmm. Do we have anything special for punching holes in files? > That would be another sane route to take to remove the special > case for clearing the memory. truncate_range, I suppose. A file descriptor syscall based alternative for madvise would be nice though (like fallocate). We could always put something in /sys/block/ram*/xxx - 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] sched: Rationalize sys_sched_rr_get_interval()
Jarek Poplawski wrote: On 16-10-2007 03:16, Peter Williams wrote: ... I'd suggest that we modify sched_rr_get_interval() to return -EINVAL (with *interval set to zero) if the target task is not SCHED_RR. That way we can save a lot of unnecessary code. I'll work on a patch. ... I like this idea! But, since this a system call maybe at least something like RFC would be nicer... We would be just modifying the code to meet that specification so a patch would be OK. Anyone who wants to comment will do so anyway :-). Sorry for too harsh words. I didn't consider them harsh. So, I can't be mistaken for a rapper yet? I'll work on it... Cheers, Jarek P. PS: Peter, for some unknown reason I don't receive your messages. If you get back some errors from my side I'd be interested to see it (alternative: jarkao2 at gmail.com). I haven't seen any bounce notifications. I've added the qmail address as a CC. Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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/
Regression: GRUB from openSUSE 10.2 doesn't boot current -git
Hi, As stated in the subject, I cannot boot the current -git (most recent commit 821f3eff7cdb9d6c7076effabd46c96c322daed1) using GRUB on x86-64 openSUSE 10.2. The GRUB says that the kernel image is too big and doesn't fit into memory, but the kernel has been built and installed in exactly the same way as all of the previous -git kernels. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git10 make bzImage problem
Sid Boyce wrote: When booted, it complains that kernel size is too big, but size OK for a bzImage, not for zImage as is returned by the file command, -git9 was OK, x86_64 SMP kernel on two 64x2 boxes. I shall supplymy .config if needed, but they are the same as for -git9. # l arch/x86/boot/bzImage -rw-r--r-- 1 root root 1761496 2007-10-16 22:45 arch/x86/boot/bzImage # file arch/x86_64/boot/bzImage arch/x86_64/boot/bzImage: symbolic link to `/usr/src/linux-2.6.23-git10/arch/x86/boot/bzImage' # file arch/x86/boot/bzImage arch/x86/boot/bzImage: Linux/x86 Kernel, Setup Version 0x206, zImage, RO-rootFS, root_dev 0x801, swap_dev 0x1, Prompt for Videomode Regards Sid. Fixed by the following patch. = Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- arch/x86/boot/Makefile | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index d6ed8e5..0e4912f 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -64,10 +64,10 @@ KBUILD_CFLAGS := $(LINUXINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \ KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ $(obj)/zImage: IMAGE_OFFSET := 0x1000 -$(obj)/zImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) +$(obj)/zImage: asflags-y += $(SVGA_MODE) $(RAMDISK) $(obj)/bzImage: IMAGE_OFFSET := 0x10 -$(obj)/bzImage: EXTRA_CFLAGS := -D__BIG_KERNEL__ -$(obj)/bzImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ +$(obj)/bzImage: ccflags-y += -D__BIG_KERNEL__ +$(obj)/bzImage: asflags-y += $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ $(obj)/bzImage: BUILDFLAGS := -b quiet_cmd_image = BUILD $@ Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - 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] missing include in mmc
AFAICS, fallout from repacing include of blkdev.h with include of bio.h. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c index 71b986b..7ae18ea 100644 --- a/drivers/mmc/host/mmc_spi.c +++ b/drivers/mmc/host/mmc_spi.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include /* for R1_SPI_* bit values */ - 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] CFS scheduler, -v19
Well, I am now running a 2.6.22 (without cfs) and could now see it once (within a month...) that exactly the same message from konqueror was produced. So I think its a general problem of konqueror that was hidden and somehow its triggered much more often with the cfs. I just wonder why nobody else has this problem. Markus PS: I am currently building a 2.6.23.1... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix adbhid mismerge
Something really odd has happened: the last couple of changesets
have
- int up_flag;
+ int keycode, up_flag;
and
- int up_flag;
+ int up_flag, key;
in another, both in adb_input_keycode(). Even with -m passed to
git-whatchanged there's no sign of anything in that area.
Aside of trivial conflict resolution (see below), what's the right
way to trace the things like that? Linus?
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/macintosh/adbhid.c b/drivers/macintosh/adbhid.c
index 8cce016..2766e4f 100644
--- a/drivers/macintosh/adbhid.c
+++ b/drivers/macintosh/adbhid.c
@@ -282,7 +282,7 @@ static void
adbhid_input_keycode(int id, int scancode, int repeat)
{
struct adbhid *ahid = adbhid[id];
- int keycode, up_flag;
+ int keycode, up_flag, key;
keycode = scancode & 0x7f;
up_flag = scancode & 0x80;
-
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: OOM killer gripe (was Re: What still uses the block layer?)
On Tuesday 16 October 2007 5:28:59 am Alan Cox wrote: > > I'm sure somebody will eventually write an OLS paper or something on the > > advisability of making swapping decisions with 4k granularity when disks > > really want bigger I/O transactions. > > Funnily enough someone thought of that many years ago. They even added > and documented it, then they made it adjustable. > > See the vm section of Documentation/filesystems/proc.txt I presume you refer to: page-cluster page-cluster controls the number of pages which are written to swap in a single attempt. The swap I/O size. It is a logarithmic value - setting it to zero means "1 page", setting it to 1 means "2 pages", setting it to 2 means "4 pages", etc. The default value is three (eight pages at a time). There may be some small benefits in tuning this to a different value if your workload is swap-intensive. I didn't know that controlled whether the pages were contiguous (or written to contiguous locations in swap). I thought it was just how many the VM tried to free at a time. Still, worth a tweak. Thanks. > Alan Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken 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: [PATCHSET 3/4] sysfs: divorce sysfs from kobject and driver model
[EMAIL PROTECTED] writes: > | No. The "other" device namespace I would construct on machine B to > | look just like the device namespace that existed on machine A. > | Making /sys/devices/block/sda would still be 8:0. > | > | So to be very clear on machine B when talking about disk-1 I would have. > | initial device namespace: > | /sys/devices/block/sdb > | /sys/devices/block/sdb/dev 8:16 > | > | "other" device namespace: > | /sys/devices/block/sda > | /sys/devices/block/sda/dev 8:0 > | > | Similarly on machine B when talking about disk-2 I would have. > | initial device namespace: > | /sys/devices/block/sda > | /sys/devices/block/sda/dev 8:0 > | > | "other" device namespace: > | /sys/devices/block/sdb > | /sys/devices/block/sdb/dev 8:16 > | > | So between the two devices namespaces on machine B the two disks > | would exchange their user visible identities. > > So an application that would migrate from machine A to B has to > use virtual names (like "disk-1" and "disk-2") to access the disk > right ? No. It is worse you need to access a filesystem and probably a block device that is available on both machine A and machine B. With care we can introduce appropriate namespaces and namespace semantics so we can make the names be what we need. For a classic tricky case think what it would require to migrate a git archive with checked out files and not need to say "git-update-index --refresh" before you work with the files. I used names like disk-1 and disk-2 instead of UUIDs because it was easier for me to type and think about. You do need some kind of absolute disk or filesystem identity you can refer back to. Eric - 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: [git pull] scheduler updates for v2.6.24
Dmitry Adamushko wrote: > [ cc'ed Srivatsa ] > > On 17/10/2007, Gabriel C <[EMAIL PROTECTED]> wrote: >> Ingo Molnar wrote: >> [15692.917111] BUG: unable to handle kernel NULL pointer dereference at >> virtual address 0044 >> ... >> [15692.917629] EFLAGS: 00010046 (2.6.23-g65a6ec0d #330) >> [15692.917661] EIP is at pick_next_task_fair+0x1f/0x2d > > Gabriel, could you please post a disassembled code for pick_next_task_fair()? > (objdump -d kernel/sched.o and then search for pick_next_task_fair -- > copy_and_past) Sure here it is : 0e49 : e49: 53 push %ebx e4a: 31 d2 xor%edx,%edx e4c: 83 78 40 00 cmpl $0x0,0x40(%eax) e50: 74 20 je e72 e52: 83 c0 38add$0x38,%eax e55: 8b 50 20mov0x20(%eax),%edx e58: 31 db xor%ebx,%ebx e5a: 85 d2 test %edx,%edx e5c: 74 0a je e68 e5e: 8d 5a f8lea-0x8(%edx),%ebx e61: 89 da mov%ebx,%edx e63: e8 a9 ff ff ff call e11 e68: 8b 43 44mov0x44(%ebx),%eax e6b: 85 c0 test %eax,%eax e6d: 75 e6 jnee55 e6f: 8d 53 d0lea-0x30(%ebx),%edx e72: 89 d0 mov%edx,%eax e74: 5b pop%ebx e75: c3 ret > > anyway, my guess is that it's : > > se = pick_next_entity(cfs_rq); > cfs_rq = group_cfs_rq(se); > > 'se' _happens_ to be NULL and group_cf_rq(se) does se->my_q and > (according to my calculations) offset(my_q) == 68 (0x44) for x86 32bit > system with CONFIG_SCHEDSTATS=n and CONFIG_FAIR_GROUP_SCHED=y > (according to the config). > > that might take place provided put_prev_task_fair() failed for some > reason to insert 'current' (or its corresponding group element) back > into the tree in schedule()... say, due to some inconsistency in > cfs_rq's data. > > Srivatsa, that's somewhat similar to another issue that has been > posted earlier today (crash in put_prev_task_fair() --> > __enqueue_task() --> rb_insert_color()) that you are already aware of > ... (/me will continue tomorrow). > > - 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/
