Re: connector.c
On Thu, 2005-03-31 at 23:42 -0800, Andrew Morton wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > What happens if we expect a reply to our message but userspace never sends > > > one? Does the kernel leak memory? Do other processes hang? > > > > It is only advice, one may easily skip seq/ack initialization. > > I could remove it totally from the header, but decided to > > place it to force people to use more reliable protocols over netlink > > by introducing such overhead. > > hm. I don't know what that means. Messages that are passed between agents must have only id, but I decided to force people to use provided seq/ack fields to store there some information about message order. Neither kernel nor userspace requires that fields to be somehow initialized. > > > > nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - > > > > sizeof(*nlh)); > > > > > > > > data = (struct cn_msg *)NLMSG_DATA(nlh); > > > > > > Unneeded typecast. > > > > Is it really an issue? > > Well it adds clutter, but more significantly the cast defeats typechecking. > If someone was to change NLMSG_DATA() to return something other than > void*, the compiler wouldn't complain. > > > > > > > Why is spin_lock_bh() being used here? > > > > skb may be delivered in soft irq context, and may race with sending. > > And actually it can be sent from irq context, like it is done in test > > module. > > But spin_lock_bh() in irq context will deadlock if interruptible context is > also doing spin_lock_bh(). skbs are delivered in softirq context and, yes, I need to exactly point that sending also must be limited to soft irq context. > > > What's all the above code doing? What do `a' and `b' mean? Needs > > > commentary and better-chosen identifiers. > > > > It searches for idx and val to match requested notification, > > if "a" is true - idx is found, if b - val is found. > > Let me rephrase: please comment the code and choose identifiers in a manner > which makes it clearer what's going on. Sure. > > > Please document all functions with comments. Functions which constitute > > > part of the external API should be commented using the kernel-doc format. > > > > There is Documentation/connector/connector.txt which describes all > > exported functions and structures. > > Should it be ported to docbook? > > connector.txt is pitched at about the right level: an in-kernel and > userspace API description. It's rather unclear with respect to mesage > directions though - whether the callback is invoked after kernel->user > messages, or for user->kernel or what, for example. Some clarification > there would help. Callback is invoked each time message is received - either from userspace [original aim] or from kernelspace [one can send notification request or just send a message from one kernelspace subsystem to another]. Callback can also be called when notification for given idx/val range was requested and new callback is being registered/unregistered which mathces given idx/val range. > But an API description is a different thing from code commentary which > explains the internal design - the latter should be coupled to the code > itself. I will begin create in-code documentation after all technical issues are resolved. Patches will be ready soon I think. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Thu, 2005-03-31 at 16:10 -0800, Jay Lan wrote: > Andrew Morton wrote: > > >Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: > > > > > >> This patch adds a fork connector in the do_fork() routine. > >>... > >> > >> The fork connector is used by the Enhanced Linux System Accounting > >>project http://elsa.sourceforge.net > >> > >> > > > >Does it also meet all the in-kernel requirements for other accounting > >projects? > > > >If not, what else do those other projects need? > > > > > Hi Andrew, > > As the discussion in this thread of the past few days showed, this > patch intends to take care of process grouping, but not the > accounting data collection. Besides my concern of possibility of > data loss, this patch also provides CSA information to handle process > grouping as it intends to do. I plan to run some testing to see percentage > of data loss when system is under stress test, but improvement at > CBUS as Evgeniy indicated should help! > > Please be advised that i still need an do_exit handling to save accounting > data. But, it is a separate issue. My five copecks [or two cents]: fork connector with CBUS [with theirs upto 2.5 % degradation with huge disk writes per fork] are still much faster than any existing accounting models. But it is purely accounting project author to think about accounting design though... > Thanks, > - jay -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: connector.h
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-03-31 at 17:31 -0800, Andrew Morton wrote:
> > >
> > > struct cb_id
> > > {
> > > __u32 idx;
> > > __u32 val;
> > > };
> >
> > It is vital that all data structures be skilfully commented - they are the
> > key to understanding the code. Why the struct exists, which actor passes
> > it to which other actor(s), whether the data structure is communicated with
> > userspace, what other data structures it is aggregated with or linked to,
> > locking rules, etc.
>
> It is described in Documentation/connector/connector.txt.
> Should it also be placed here?
I think it's better to document these things in the code. Those structs
which are communicated to userspace should be described in connector.txt
because they are part of the API. But a lot of the structs you have there
are purely knerel-internal.
> > > struct cn_msg
> > > {
> >
> > Please do
> >
> > struct cn_msg {
>
> Neither structure declaration should have opening brace on the new
> string?
I don't understand your question.
We lay out struct definitions thusly:
struct foo {
int a;
int b;
};
-
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: connector.c
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > What happens if we expect a reply to our message but userspace never sends > > one? Does the kernel leak memory? Do other processes hang? > > It is only advice, one may easily skip seq/ack initialization. > I could remove it totally from the header, but decided to > place it to force people to use more reliable protocols over netlink > by introducing such overhead. hm. I don't know what that means. > > > nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh)); > > > > > > data = (struct cn_msg *)NLMSG_DATA(nlh); > > > > Unneeded typecast. > > Is it really an issue? Well it adds clutter, but more significantly the cast defeats typechecking. If someone was to change NLMSG_DATA() to return something other than void*, the compiler wouldn't complain. > > > > Why is spin_lock_bh() being used here? > > skb may be delivered in soft irq context, and may race with sending. > And actually it can be sent from irq context, like it is done in test > module. But spin_lock_bh() in irq context will deadlock if interruptible context is also doing spin_lock_bh(). > > What's all the above code doing? What do `a' and `b' mean? Needs > > commentary and better-chosen identifiers. > > It searches for idx and val to match requested notification, > if "a" is true - idx is found, if b - val is found. Let me rephrase: please comment the code and choose identifiers in a manner which makes it clearer what's going on. > > Please document all functions with comments. Functions which constitute > > part of the external API should be commented using the kernel-doc format. > > There is Documentation/connector/connector.txt which describes all > exported functions and structures. > Should it be ported to docbook? connector.txt is pitched at about the right level: an in-kernel and userspace API description. It's rather unclear with respect to mesage directions though - whether the callback is invoked after kernel->user messages, or for user->kernel or what, for example. Some clarification there would help. But an API description is a different thing from code commentary which explains the internal design - the latter should be coupled to the code itself. - 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] wbsd update
Russell King wrote:
>Please use platform_device_register_simple() instead of providing a buggy
>release function.
>
>
>
>You might like to consider using mmc->dev instead of duplicating it
>here.
>
>
>
Sorry about the delay. It's been a rather busy week. Included is the
same patch with the two issues above fixed.
Rgds
Pierre
Index: linux/drivers/mmc/wbsd.c
===
--- linux/drivers/mmc/wbsd.c(revision 132)
+++ linux/drivers/mmc/wbsd.c(working copy)
@@ -28,7 +28,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -40,7 +42,7 @@
#include "wbsd.h"
#define DRIVER_NAME "wbsd"
-#define DRIVER_VERSION "1.1"
+#define DRIVER_VERSION "1.2"
#ifdef CONFIG_MMC_DEBUG
#define DBG(x...) \
@@ -52,10 +54,6 @@
#define DBGF(x...) do { } while (0)
#endif
-static unsigned int io = 0x248;
-static unsigned int irq = 6;
-static int dma = 2;
-
#ifdef CONFIG_MMC_DEBUG
void DBG_REG(int reg, u8 value)
{
@@ -79,28 +77,61 @@
#endif
/*
+ * Device resources
+ */
+
+#ifdef CONFIG_PNP
+
+static const struct pnp_device_id pnp_dev_table[] = {
+ { "WEC0517", 0 },
+ { "WEC0518", 0 },
+ { "", 0 },
+};
+
+MODULE_DEVICE_TABLE(pnp, pnp_dev_table);
+
+#endif /* CONFIG_PNP */
+
+#ifdef CONFIG_PNP
+static unsigned int nopnp = 0;
+#else
+static const unsigned int nopnp = 1;
+#endif
+static unsigned int io = 0x248;
+static unsigned int irq = 6;
+static int dma = 2;
+
+/*
* Basic functions
*/
static inline void wbsd_unlock_config(struct wbsd_host* host)
{
+ BUG_ON(host->config == 0);
+
outb(host->unlock_code, host->config);
outb(host->unlock_code, host->config);
}
static inline void wbsd_lock_config(struct wbsd_host* host)
{
+ BUG_ON(host->config == 0);
+
outb(LOCK_CODE, host->config);
}
static inline void wbsd_write_config(struct wbsd_host* host, u8 reg, u8 value)
{
+ BUG_ON(host->config == 0);
+
outb(reg, host->config);
outb(value, host->config + 1);
}
static inline u8 wbsd_read_config(struct wbsd_host* host, u8 reg)
{
+ BUG_ON(host->config == 0);
+
outb(reg, host->config);
return inb(host->config + 1);
}
@@ -133,6 +164,13 @@
wbsd_write_index(host, WBSD_IDX_SETUP, setup);
/*
+* Set DAT3 to input
+*/
+ setup &= ~WBSD_DAT3_H;
+ wbsd_write_index(host, WBSD_IDX_SETUP, setup);
+ host->flags &= ~WBSD_FIGNORE_DETECT;
+
+ /*
* Read back default clock.
*/
host->clk = wbsd_read_index(host, WBSD_IDX_CLK);
@@ -148,6 +186,14 @@
wbsd_write_index(host, WBSD_IDX_TAAC, 0x7F);
/*
+* Test for card presence
+*/
+ if (inb(host->base + WBSD_CSR) & WBSD_CARDPRESENT)
+ host->flags |= WBSD_FCARD_PRESENT;
+ else
+ host->flags &= ~WBSD_FCARD_PRESENT;
+
+ /*
* Enable interesting interrupts.
*/
ier = 0;
@@ -407,8 +453,6 @@
}
}
-static irqreturn_t wbsd_irq(int irq, void *dev_id, struct pt_regs *regs);
-
static void wbsd_send_command(struct wbsd_host* host, struct mmc_command* cmd)
{
int i;
@@ -646,6 +690,13 @@
}
wbsd_kunmap_sg(host);
+
+ /*
+* The controller stops sending interrupts for
+* 'FIFO empty' under certain conditions. So we
+* need to be a bit more pro-active.
+*/
+ tasklet_schedule(>fifo_tasklet);
}
static void wbsd_prepare_data(struct wbsd_host* host, struct mmc_data* data)
@@ -850,9 +901,11 @@
wbsd_request_end(host, host->mrq);
}
-/*
- * MMC Callbacks
- */
+/*\
+ * *
+ * MMC layer callbacks *
+ * *
+\*/
static void wbsd_request(struct mmc_host* mmc, struct mmc_request* mrq)
{
@@ -874,7 +927,7 @@
* If there is no card in the slot then
* timeout immediatly.
*/
- if (!(inb(host->base + WBSD_CSR) & WBSD_CARDPRESENT))
+ if (!(host->flags & WBSD_FCARD_PRESENT))
{
cmd->error = MMC_ERR_TIMEOUT;
goto done;
@@ -953,33 +1006,50 @@
host->clk = clk;
}
+ /*
+* Power up card.
+*/
if (ios->power_mode != MMC_POWER_OFF)
{
- /*
-* Power up card.
-*/
pwr = inb(host->base + WBSD_CSR);
pwr &= ~WBSD_POWER_N;
outb(pwr, host->base + WBSD_CSR);
+ }
- /*
-
Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
On Thu, 2005-03-31 at 23:26 -0800, Andrew Morton wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > > > +static int cbus_event_thread(void *data)
> > > > +{
> > > > + int i, non_empty = 0, empty = 0;
> > > > + struct cbus_event_container *c;
> > > > +
> > > > + daemonize(cbus_name);
> > > > + allow_signal(SIGTERM);
> > > > + set_user_nice(current, 19);
> > >
> > > Please use the kthread api for managing this thread.
> > >
> > > Is a new kernel thread needed?
> >
> > Logic behind cbus is following:
> > 1. make insert operation return as soon as possible,
> > 2. deferring actual message delivering to the safe time
> >
> > That thread does second point.
>
> But does it need a new thread rather than using the existing keventd?
Yes, it is much cleaner [especially from performance tuning point]
to use own kernel thread than pospone all work to the queued work.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: cn_queue.c
On Thu, 2005-03-31 at 17:32 -0800, Andrew Morton wrote:
> > /*
> > * cn_queue.c
> > *
> > * 2004 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
> > * All rights reserved.
> > *
> > * 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, write to the Free Software
> > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> > *
> > */
>
> It's conventinal to add at the start of the file a description of what it
> all does.
Yep, I need to force myself to write better docs...
> > static void cn_queue_wrapper(void *data)
> > {
> > struct cn_callback_entry *cbq = (struct cn_callback_entry *)data;
> >
> > smp_mb__before_atomic_inc();
> > atomic_inc(>cb->refcnt);
> > smp_mb__after_atomic_inc();
> > cbq->cb->callback(cbq->cb->priv);
> > smp_mb__before_atomic_inc();
> > atomic_dec(>cb->refcnt);
> > smp_mb__after_atomic_inc();
> >
> > cbq->destruct_data(cbq->ddata);
> > }
>
> What on earth are all these barriers for? Barriers should have an
> associated comment describing why they were added, and what they are
> defending against, becuase it is very hard to tell that from reading the
> code.
>
> Please describe (via code comments) what the refcounting rules are for
> these data structures. It all looks very strange. You basically have:
>
>
> atomic_inc(refcnt);
> use(some_object);
> atomic_dec(refcnt);
>
> Which looks very racy. Some other CPU could see a zero refcount just
> before this CPU did the atomic_inc() and the other CPU will go and free up
> some_object. There should be locking associated with refcounting to
> prevent such races, and I don't see any.
It can not happen in the above case.
It can race with callback removing, but remove path
call cancel_delayed_work() which calls del_timer_sync(),
so above code can not be run or will not run,
only after it refcnt is being checked to be zero.
It is probably an overhead since sinchronization is done
in other places.
All above barriers are introduced to remove already not theoretical
atomic vs. non-atomic reordering [ppc64 very like it],
when reference counter must be decremented after object was used,
but due to reordering it can happen before use [and it will be seen
atomically on all CPUs],
and other CPU may free object based on knowledge that
refcnt is zero.
> > static struct cn_callback_entry *cn_queue_alloc_callback_entry(struct
> > cn_callback *cb)
>
> 80 cols again.
>
> > static void cn_queue_free_callback(struct cn_callback_entry *cbq)
> > {
> > cancel_delayed_work(>work);
> >
> > while (atomic_read(>cb->refcnt)) {
> > printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n",
> >cbq->pdev->name, atomic_read(>cb->refcnt));
> >
> > msleep_interruptible(1000);
> >
> > if (current->flags & PF_FREEZE)
> > refrigerator(PF_FREEZE);
> >
> > if (signal_pending(current))
> > flush_signals(current);
> > }
> >
> > kfree(cbq);
> > }
>
> erp. Can you please do this properly?
>
> Free the object on the refcount going to zero (with appropriate locking)?
> If you want (for some reason) to wait until all users of an object have
> gone away then you should take a ref on the object (inside locking), then
> sleep on a waitqueue_head embedded in that object. Make all
> refcount-droppers do a wake_up.
>
> Why is this function playing with signals?
It is not, just can be interrupted to check state befor timeout expires.
It is not a problem to remove signal interrupting here.
> > int cn_cb_equal(struct cb_id *i1, struct cb_id *i2)
> > {
> > #if 0
> > printk(KERN_INFO "%s: comparing %04x.%04x and %04x.%04x\n",
> > __func__,
> > i1->idx, i1->val,
> > i2->idx, i2->val);
> > #endif
> > return ((i1->idx == i2->idx) && (i1->val == i2->val));
> > }
>
> Please review all functions, check that they really need kernel-wide scope.
It is not exported, but is used in the other files which build
connector.
Only callback adding/removing and message sending functions are
exported.
> Please comment all functions.
Yep...
> > int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb)
> > {
> > struct cn_callback_entry *cbq, *n, *__cbq;
> > int found = 0;
> >
>
Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > > +static int cbus_event_thread(void *data)
> > > +{
> > > +int i, non_empty = 0, empty = 0;
> > > +struct cbus_event_container *c;
> > > +
> > > +daemonize(cbus_name);
> > > +allow_signal(SIGTERM);
> > > +set_user_nice(current, 19);
> >
> > Please use the kthread api for managing this thread.
> >
> > Is a new kernel thread needed?
>
> Logic behind cbus is following:
> 1. make insert operation return as soon as possible,
> 2. deferring actual message delivering to the safe time
>
> That thread does second point.
But does it need a new thread rather than using the existing keventd?
-
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.12-rc1-mm4
Andrew Morton wrote: > bk-audit.patch This seems to have broken compile for uml: CC arch/um/kernel/ptrace.o arch/um/kernel/ptrace.c:345:74: macro "audit_syscall_entry" requires 7 arguments, but only 6 given arch/um/kernel/ptrace.c: In function `syscall_trace': arch/um/kernel/ptrace.c:340: error: `audit_syscall_entry' undeclared (first use in this function) arch/um/kernel/ptrace.c:340: error: (Each undeclared identifier is reported only once arch/um/kernel/ptrace.c:340: error: for each function it appears in.) arch/um/kernel/ptrace.c:348:72: macro "audit_syscall_exit" requires 3 arguments, but only 2 given arch/um/kernel/ptrace.c:347: error: `audit_syscall_exit' undeclared (first use in this function) make[1]: *** [arch/um/kernel/ptrace.o] Error 1 make: *** [arch/um/kernel] Error 2 Fri, 01 Apr 2005 09:08:16 +0200 in particular I suspect: # include/linux/audit.h # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +44 -4 # Add AUDIT_ARCH and its definitions # Add arch to audit_syscall_entry() # Add success/failure to audit_syscall_exit() # # arch/x86_64/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +8 -5 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/s390/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +11 -10 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/ppc64/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +10 -6 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/mips/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +28 -10 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/ia64/kernel/ptrace.c # 2005/03/25 13:53:14+00:00 [EMAIL PROTECTED] +13 -8 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/i386/kernel/ptrace.c # 2005/03/25 13:53:14+00:00 [EMAIL PROTECTED] +9 -10 # Reorder audit w.r.t ptrace, provide arch and success. defconfig, gcc 3.3.5, see http://l4x.org/k/?d=3004 for details. Jan - 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: Industry db benchmark result on recent 2.6 kernels
> Couple of observations: yeah - plausible enough. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - 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: Industry db benchmark result on recent 2.6 kernels
* Paul Jackson <[EMAIL PROTECTED]> wrote: > Nick wrote: > > Ingo had a cool patch to estimate dirty => dirty cacheline transfer latency > > ... Unfortunately ... and it is an O(cpus^2) operation. > > Yes - a cool patch. > > If we had an arch-specific bit of code, that for any two cpus, could > give a 'pseudo-distance' between them, where the only real > requirements were that (1) if two pairs of cpus had the same > pseudo-distance, then that meant they had the same size, layout, kind > and speed of bus amd cache hardware between them (*), and (2) it was > cheap - hardly more than a few lines of code and a subroutine call to > obtain, then Ingo's code could be: yeah. The search can be limited quite drastically if all duplicate constellations of CPUs (which is a function of the topology) are only measured once. but can be 'pseudo-distance' be calculated accurately enough? If it's a scalar, how do you make sure that unique paths for data to flow have different distances? The danger is 'false sharing' in the following scenario: lets say CPUs #1 and #2 are connected via hardware H1,H2,H3, CPUs #3 and #4 are connected via H4,H5,H6. Each hardware component is unique and has different characteristics. (e.g. this scenario can happen when different speed CPUs are mixed into the same system - or if there is some bus assymetry) It has to be made sure that H1+H2+H3 != H4+H5+H6, otherwise false sharing will happen. For that 'uniqueness of sum' to be guaranteed, one has to assign power-of-two values to each separate type of hardware component. [ or one has to assing very accurate 'distance' values to hardware components. (adding another source for errors - i.e. false sharing of the migration value) ] and even the power-of-two assignment method has its limitations: it obviously runs out at 32/64 components (i'm not sure we can do that), and if a given component type can be present in the same path _twice_, that component will have to take two bits. or is the 'at most 64 different hardware component types' limit ok? (it feels like a limit we might regret later.) Ingo - 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: connector.h
On Thu, 2005-03-31 at 17:31 -0800, Andrew Morton wrote:
> >
> > struct cb_id
> > {
> > __u32 idx;
> > __u32 val;
> > };
>
> It is vital that all data structures be skilfully commented - they are the
> key to understanding the code. Why the struct exists, which actor passes
> it to which other actor(s), whether the data structure is communicated with
> userspace, what other data structures it is aggregated with or linked to,
> locking rules, etc.
It is described in Documentation/connector/connector.txt.
Should it also be placed here?
> > struct cn_msg
> > {
>
> Please do
>
> struct cn_msg {
Neither structure declaration should have opening brace on the new
string?
> >
> > #define CN_CBQ_NAMELEN 32
>
> Commentary?
Maximum allowed callback name - name will be truncated if
it exceeds that limit.
I will place this doc in the code.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: connector.c
On Thu, 2005-03-31 at 17:30 -0800, Andrew Morton wrote:
> Some belated comments...
>
>
> >
> > module_param(unit, int, 0);
> > module_param(cn_idx, uint, 0);
> > module_param(cn_val, uint, 0);
>
> MODULE_PARM_DESC needed, please.
Yep.
> > static DEFINE_SPINLOCK(notify_lock);
> > static LIST_HEAD(notify_list);
> >
> > static struct cn_dev cdev;
> >
> > int cn_already_initialized = 0;
> >
> > /*
> > * msg->seq and msg->ack are used to determine message genealogy.
> > * When someone sends message it puts there locally unique sequence
> > * and random acknowledge numbers.
> > * Sequence number may be copied into nlmsghdr->nlmsg_seq too.
> > *
> > * Sequence number is incremented with each message to be sent.
> > *
> > * If we expect reply to our message,
> > * then sequence number in received message MUST be the same as in original
> > message,
> > * and acknowledge number MUST be the same + 1.
> > *
> > * If we receive message and it's sequence number is not equal to one we
> > are expecting,
> > * then it is new message.
> > * If we receive message and it's sequence number is the same as one we are
> > expecting,
> > * but it's acknowledge is not equal acknowledge number in original message
> > + 1,
> > * then it is new message.
> > *
> > */
>
> This comment looks crappy in an 80-col xterm.
Does anyone still use it? :)
> What happens if we expect a reply to our message but userspace never sends
> one? Does the kernel leak memory? Do other processes hang?
It is only advice, one may easily skip seq/ack initialization.
I could remove it totally from the header, but decided to
place it to force people to use more reliable protocols over netlink
by introducing such overhead.
> > void cn_netlink_send(struct cn_msg *msg, u32 __groups)
> > {
> > struct cn_callback_entry *n, *__cbq;
> > unsigned int size;
> > struct sk_buff *skb, *uskb;
> > struct nlmsghdr *nlh;
> > struct cn_msg *data;
> > struct cn_dev *dev =
> > u32 groups = 0;
> > int found = 0;
> >
> > if (!__groups)
> > {
>
> Wrong indenting.
Yep, my fault...
> > spin_lock_bh(>cbdev->queue_lock);
> > list_for_each_entry_safe(__cbq, n, >cbdev->queue_list,
> > callback_entry) {
> > if (cn_cb_equal(&__cbq->cb->id, >id)) {
> > found = 1;
> > groups = __cbq->group;
> > }
> > }
> > spin_unlock_bh(>cbdev->queue_lock);
> >
> > if (!found) {
> > printk(KERN_ERR "Failed to find multicast netlink group
> > for callback[0x%x.0x%x]. seq=%u\n",
> >msg->id.idx, msg->id.val, msg->seq);
>
> Needs wrapping.
>
> > return;
> > }
> > }
> > else
> > groups = __groups;
> >
> > size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> >
> > skb = alloc_skb(size, GFP_ATOMIC);
>
> GFP_ATOMIC is quite unreliable. Better to find a way to use GFP_KERNEL here.
It can be used in bh context, my first TODO entryf for connector is
provideing
extended API with GFP flags provided by caller.
> > if (!skb) {
> > printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
> > size);
> > return;
> > }
>
> Surely we should return -ENOMEM here? How is the caller to know that the
> send attempt worked?
It is notification area, notification may fail and original applicant
can not
and should not know about it.
If it was direct call, then error must be propagated to the caller,
but indirect notification is not.
> > nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh));
> >
> > data = (struct cn_msg *)NLMSG_DATA(nlh);
>
> Unneeded typecast.
Is it really an issue?
I try to always dereference void pointer to the given type...
> > memcpy(data, msg, sizeof(*data) + msg->len);
> > #if 0
> > printk("%s: len=%u, seq=%u, ack=%u, group=%u.\n",
> >__func__, msg->len, msg->seq, msg->ack, groups);
> > #endif
> >
> > NETLINK_CB(skb).dst_groups = groups;
> >
> > uskb = skb_clone(skb, GFP_ATOMIC);
> > if (uskb) {
> > netlink_unicast(dev->nls, uskb, 0, 0);
> > }
>
> Unneeded {}
Ok.
> > netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
>
> GFP_ATOMIC is quite undesirable.
It will be changed to provided GFP flags by caller soon.
> >
> > static int cn_call_callback(struct cn_msg *msg, void (*destruct_data) (void
> > *), void *data)
>
> 80 cols
>
> > {
> > struct cn_callback_entry *n, *__cbq;
> > struct cn_dev *dev =
> > int found = 0;
> >
> > spin_lock_bh(>cbdev->queue_lock);
> > list_for_each_entry_safe(__cbq, n, >cbdev->queue_list,
> > callback_entry) {
>
> 80 cols
Grrr
> > if (cn_cb_equal(&__cbq->cb->id, >id)) {
> > __cbq->cb->priv = msg;
> >
> >
Re: 64bit build of tulip driver
On Thu, Mar 31, 2005 at 07:52:06PM -0800, Jim Gifford wrote: > Grant >Thanx for your feedback. I got it working, but I don't think the > patch is the best. Here is the patch, and the information, but if you > can recommend a different way to fix it, let me know. I can not "reccomend" one. I can suggest other things to try since I'm very skeptical this patch will get accepted by the maintainer (Jeff Garzik). He's normally wants a much better explanation of the problem than "this works". > The patch was done by Peter Horton. > Here is the link to the full patch, > http://ftp.jg555.com/patches/raq2/linux/linux-2.6.11.6-raq2_fix-2.patch > but here is the section for this issue Jim, You have other changes to tulip_core.c: + /* Avoid a chip errata by prefixing a dummy entr y. Don't do + this on the ULI526X as it triggers a differen t problem */ Picking a few nits: o comment extends past 80 columns - please wrap before 80 columns o *Which* chip errata? o *Which* other problem? o I prefer diffs with "-p" when reviewing patches so I know which function is getting mangled. - /* No media table either */ - tp->flags &= ~HAS_MEDIA_TABLE; + /* Ensure our media table fixup get's applied */ + memcpy(ee_data + 16, ee_data, 8); This isn't likely to get far either unless it's better explained. You don't have to explain it to me, now. But have something handy if you want jgarzik to accept it. > @@ -1628,6 +1631,16 @@ > } > } > > +#if defined(CONFIG_MIPS_COBALT) && defined(CONFIG_MIPS64) > +/* > + * something very bad is happening. without this > + * cache flush the PHY can't be read. I've tried > + * various ins & outs, delays etc but only a call > + * to printk or this flush seems to fix it ... help! > + */ > +flush_cache_all(); > +#endif The code immediately before this calls tulip_select_media(). Code paths exist in tulip_select_media() where the last thing the driver does to the NIC is io_write(). This could easily be a posted write flush problem. Does replacing flush_cache_all() with "ioread32(ioaddr + CSR12)" also work? Can you find out how long one has to wait after banging on CSR12 before it's safe to call tulip_find_mii()? How long does flush_cache_all() take in microseconds? It's possible this is a very fast PPC chip and it's executing the code path between tulip_select_media() and tulip_find_mii() faster than the chips can finish dealing with the writes to CSR12. I'd consider this issue if flushing posted PCI writes doesn't help. The tulip changes I maintain in parisc-linux port deal with similar issues where the driver is not following the specified timing requirements. Search google for "tulip 802.3 22.2.4 Management functions" or look into http://cvs.parisc-linux.org/linux-2.6/. > + > /* Find the connected MII xcvrs. >Doing this in open() would allow detecting external xcvrs >later, but takes much time. */ > > >Are there any config option differences? > >e.g. MWI or MMIO options enabled on 64-bit but not 32-bit? > > I verified that there are no differences. ok. thanks. ... > Applied the patch, here is the output > > :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) ... Sorry, I don't have time to decode what these mean right now. But I think the publicly available tulip chips docs sufficiently explain what the registers mean and what state the chip is in. > I was able to get some more information on the bootup sequence with the > updates. > Here is the output now from the driver > > Linux Tulip driver version 1.1.13 (May 11, 2002) > PCI: Enabling device :00:07.0 (0045 -> 0047) > tulip0: Old format EEPROM on 'Cobalt Microserver' board. Using > substitute media control info. > tulip0: EEPROM default media type Autosense. > tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. > tulip0: ***WARNING***: No MII transceiver found! ok. I assume this is unpatched. thanks, grant > eth0: Digital DS21143 Tulip rev 65 at b0001400, > 00:10:E0:00:32:DE, IRQ 19. > PCI: Enabling device :00:0c.0 (0005 -> 0007) > tulip1: Old format EEPROM on 'Cobalt Microserver' board. Using > substitute media control info. > tulip1: EEPROM default media type Autosense. > tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. > tulip1: ***WARNING***: No MII transceiver found! > eth1: Digital DS21143 Tulip rev 65 at b0001480, > 00:10:E0:00:32:DF, IRQ 20. > > > -- > > Jim Gifford > [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: Industry db benchmark result on recent 2.6 kernels
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Nick wrote:
> > Ingo had a cool patch to estimate dirty => dirty cacheline transfer latency
> > ... Unfortunately ... and it is an O(cpus^2) operation.
>
> Yes - a cool patch.
before we get into complexities, i'd like to see whether it solves Ken's
performance problem. The attached patch (against BK-curr, but should
apply to vanilla 2.6.12-rc1 too) adds the autodetection feature. (For
ia64 i've hacked in a cachesize of 9MB for Ken's testsystem.)
boots fine on x86, and gives this on a 4-way box:
Brought up 4 CPUs
migration cost matrix (cache_size: 524288, cpu: 2379 MHz):
[00] [01] [02] [03]
[00]:1.3 1.3 1.4 1.2
[01]:1.5 1.3 1.3 1.5
[02]:1.5 1.3 1.3 1.5
[03]:1.3 1.3 1.3 1.3
min_delta: 1351361
using cache_decay nsec: 1351361 (1 msec)
which is a pretty reasonable estimate on that box. (fast P4s, small
cache)
Ken, could you give it a go?
Ingo
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -4699,6 +4699,232 @@ static void check_sibling_maps(void)
#endif
/*
+ * Task migration cost measurement between source and target CPUs.
+ *
+ * This is done by measuring the worst-case cost. Here are the
+ * steps that are taken:
+ *
+ * 1) the source CPU dirties its L2 cache with a shared buffer
+ * 2) the target CPU dirties its L2 cache with a local buffer
+ * 3) the target CPU dirties the shared buffer
+ *
+ * We measure the time step #3 takes - this is the cost of migrating
+ * a cache-hot task that has a large, dirty dataset in the L2 cache,
+ * to another CPU.
+ */
+
+
+/*
+ * Dirty a big buffer in a hard-to-predict (for the L2 cache) way. This
+ * is the operation that is timed, so we try to generate unpredictable
+ * cachemisses that still end up filling the L2 cache:
+ */
+__init static void fill_cache(void *__cache, unsigned long __size)
+{
+ unsigned long size = __size/sizeof(long);
+ unsigned long *cache = __cache;
+ unsigned long data = 0xdeadbeef;
+ int i;
+
+ for (i = 0; i < size/4; i++) {
+ if ((i & 3) == 0)
+ cache[i] = data;
+ if ((i & 3) == 1)
+ cache[size-1-i] = data;
+ if ((i & 3) == 2)
+ cache[size/2-i] = data;
+ if ((i & 3) == 3)
+ cache[size/2+i] = data;
+ }
+}
+
+struct flush_data {
+ unsigned long source, target;
+ void (*fn)(void *, unsigned long);
+ void *cache;
+ void *local_cache;
+ unsigned long size;
+ unsigned long long delta;
+};
+
+/*
+ * Dirty L2 on the source CPU:
+ */
+__init static void source_handler(void *__data)
+{
+ struct flush_data *data = __data;
+
+ if (smp_processor_id() != data->source)
+ return;
+
+ memset(data->cache, 0, data->size);
+}
+
+/*
+ * Dirty the L2 cache on this CPU and then access the shared
+ * buffer. (which represents the working set of the migrated task.)
+ */
+__init static void target_handler(void *__data)
+{
+ struct flush_data *data = __data;
+ unsigned long long t0, t1;
+ unsigned long flags;
+
+ if (smp_processor_id() != data->target)
+ return;
+
+ memset(data->local_cache, 0, data->size);
+ local_irq_save(flags);
+ t0 = sched_clock();
+ fill_cache(data->cache, data->size);
+ t1 = sched_clock();
+ local_irq_restore(flags);
+
+ data->delta = t1 - t0;
+}
+
+/*
+ * Measure the cache-cost of one task migration:
+ */
+__init static unsigned long long measure_one(void *cache, unsigned long size,
+int source, int target)
+{
+ struct flush_data data;
+ unsigned long flags;
+ void *local_cache;
+
+ local_cache = vmalloc(size);
+ if (!local_cache) {
+ printk("couldnt allocate local cache ...\n");
+ return 0;
+ }
+ memset(local_cache, 0, size);
+
+ local_irq_save(flags);
+ local_irq_enable();
+
+ data.source = source;
+ data.target = target;
+ data.size = size;
+ data.cache = cache;
+ data.local_cache = local_cache;
+
+ if (on_each_cpu(source_handler, , 1, 1) != 0) {
+ printk("measure_one: timed out waiting for other CPUs\n");
+ local_irq_restore(flags);
+ return -1;
+ }
+ if (on_each_cpu(target_handler, , 1, 1) != 0) {
+ printk("measure_one: timed out waiting for other CPUs\n");
+ local_irq_restore(flags);
+ return -1;
+ }
+
+ vfree(local_cache);
+
+ return data.delta;
+}
+
+__initdata unsigned long sched_cache_size;
+
+/*
+ * Measure a series of task migrations and return the maximum
+ * result - the worst-case. Since this code runs early during
+ * bootup the system is 'undisturbed' and the maximum latency
+ * makes sense.
+ *
+ *
RE: 2.6.11, USB: High latency?
> > > The latencies are almost certainly caused by the USB host > controller > > > driver. I'm planning improvements to uhci-hcd which should > > > help reduce > > > the latency, but it will still be on the large side. And I > > > won't have > > > time to write the changes to the driver for several months. > > > > Any numbers about the expected "large side"? > > We would need <30 microseconds irq latency, > > and <<1 milliseconds rt application latency. > > The biggest advantage would come from using a bottom-half > handler to do > most of the work. Right now the uhci-hcd driver does > everything in its > interrupt handler. This would certainly help IRQ latency; it > might not > affect application latency very much. Sounds very reasonable, thanks. Also helps application latency, because with the RT patches, I can tune the rt prio of softirq execution (that's where bottom-half goes, doesn't it?) w.r.t. the rt prio of the application threads. However, if I understand things correctly, if you really need to disable all interrupts while doing the USB work, it will not make any difference if IRQs are disabled while you are in the USB IRQ handler, or if they are disabled for the same amount of work/time in the bottom-half code. > I'll try adding a bottom half in my next series of patches. > Maybe it will > be ready in time to appear in the -mm kernels before 2.6.12-final is > released. > We'll see what happens with the upcoming changes. Maybe > you'll be able to > test them for me? Basically, yes (as long as our company doesn't decide to stop the linux experiments). However, I depend on Ingo's RT patch, which is against the -rc series, not against the -mm series. So I will probably not be able to apply patches created against -mm. -- Klaus Kusche Entwicklung Software - Steuerung Software Development - Control KEBA AG A-4041 Linz Gewerbepark Urfahr Tel +43 / 732 / 7090-3120 Fax +43 / 732 / 7090-8919 E-Mail: [EMAIL PROTECTED] www.keba.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
On Thu, 2005-03-31 at 16:27 -0800, Andrew Morton wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > I'm pleased to annouce CBUS - ultra fast (for insert operations)
> > message bus.
>
> > +static int cbus_enqueue(struct cbus_event_container *c, struct cn_msg *msg)
> > +{
> > + int err;
> > + struct cbus_event *event;
> > + unsigned long flags;
> > +
> > + event = kmalloc(sizeof(*event) + msg->len, GFP_ATOMIC);
>
> Using GFP_ATOMIC is a bit lame. It would be better to require the caller
> to pass in the gfp_flags. Or simply require that all callers not hold
> locks and use GFP_KERNEL.
New API with GFP flags provided is a next step in connector's TODO list.
> > +static int cbus_process(struct cbus_event_container *c, int all)
> > +{
> > + struct cbus_event *event;
> > + int len, i, num;
> > +
> > + if (list_empty(>event_list))
> > + return 0;
> > +
> > + if (all)
> > + len = c->qlen;
> > + else
> > + len = 1;
> > +
> > + num = 0;
> > + for (i=0; i > + event = cbus_dequeue(c);
> > + if (!event)
> > + continue;
> > +
> > + cn_netlink_send(>msg, 0);
> > + num++;
> > +
> > + kfree(event);
> > + }
> > +
> > + return num;
> > +}
>
> It might be cleaner to pass in an item count rather than a boolean `all'
> here. Then again, it seems racy.
It was called somehow like
we_are_at_the_end_and_must_process_all_events_remain,
so cbus_process() could be called from the ->exit() routing.
So I decided to call it that way, but I'm not so impracticabile about
it.
> The initial list_empty() call could fail to detect new events due to lack
> of locking and memory barriers.
It is perfectly normal, and locking does not exist here for performance
reasons.
cbus_process() is too low priority in comparison with insert operation,
so it can easily miss one entry and process it next time.
> We conventionally code for loops as
>
> for (i = 0; i < len; i++)
Grrr
> > +static int cbus_event_thread(void *data)
> > +{
> > + int i, non_empty = 0, empty = 0;
> > + struct cbus_event_container *c;
> > +
> > + daemonize(cbus_name);
> > + allow_signal(SIGTERM);
> > + set_user_nice(current, 19);
>
> Please use the kthread api for managing this thread.
>
> Is a new kernel thread needed?
Logic behind cbus is following:
1. make insert operation return as soon as possible,
2. deferring actual message delivering to the safe time
That thread does second point.
> > + while (!cbus_need_exit) {
> > + if (empty || non_empty == 0 || non_empty > 10) {
> > + interruptible_sleep_on_timeout(_wait_queue, 10);
>
> interruptible_sleep_on_timeout() is heavily deprecated and is racy without
> external locking (it pretty much has to be the BKL). Use
> wait_event_timeout().
Ok.
> > +int __devinit cbus_init(void)
> > +{
> > + int i, err = 0;
> > + struct cbus_event_container *c;
> > +
> > + for_each_cpu(i) {
> > + c = _cpu(cbus_event_list, i);
> > + cbus_init_event_container(c);
> > + }
> > +
> > + init_completion(_thread_exited);
> > +
> > + cbus_pid = kernel_thread(cbus_event_thread, NULL, CLONE_FS |
> > CLONE_FILES);
>
> Using the kthread API would clean this up.
>
> > + if (IS_ERR((void *)cbus_pid)) {
>
> The weird cast here might not even work at all on 64-bit architectures. It
> depends if they sign extend ints when casting them to pointers. I guess
> they do. If cbus_pid is indeed an s32.
>
> Much better to do
>
> if (cbus_pid < 0)
I will do it after above issues resolved.
> > +void __devexit cbus_fini(void)
> > +{
> > + int i;
> > + struct cbus_event_container *c;
> > +
> > + cbus_need_exit = 1;
> > + kill_proc(cbus_pid, SIGTERM, 0);
> > + wait_for_completion(_thread_exited);
> > +
> > + for_each_cpu(i) {
> > + c = _cpu(cbus_event_list, i);
> > + cbus_fini_event_container(c);
> > + }
> > +}
>
> I think this is racy. What stops new events from being queued while this
> function is in progress?
cbus_insert() should check need_exit flag - patch exists,
but against my tree, so I wait untill CBUS showed in public,
so I can resync with it.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: [2.6 patch] drivers/isdn/i4l/isdn_ppp.c: fix off by one errors
On Fri, 25 Mar 2005 19:32:15 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote: > This patch fixes several off by one errors found by the Coverity checker > (ippp_table has ISDN_MAX_CHANNELS elements). > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied, thanks Adrian. - 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: Industry db benchmark result on recent 2.6 kernels
On Thu, 2005-03-31 at 22:05 -0800, Paul Jackson wrote: > > Then us poor slobs with big honkin numa iron could code up a real > pseudo_distance() routine, to avoid the actual pain of doing real work > for cpus^2 iterations for large cpu counts. > > Our big boxes have regular geometries with much symmetry, so would > provide significant opportunity to exploit equal pseudo-distances. > Couple of observations: This doesn't actually need to be an O(n^2) operation. The result of it is only going to be used in the sched domains code, so what is really wanted is "how far away is one sched_group from another", although we may also scale that based on the *amount* of cache in the path between 2 cpus, that is often just a property of the CPUs themselves in smaller systems, so also not O(n^2). Secondly, we could use Ingo's O(n^2) code for the *SMP* domain on all architectures (so in your case of only 2 CPUs per node, it is obviously much cheaper, even over 256 nodes). Then the NUMA domain could just inherit this SMP value as a default, and allow architectures to override it individually. This may allow us to set up decent baseline numbers, properly scaled by cache size vs memory bandwidth without going overboard in complexity (while still allowing arch code to do more fancy stuff). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BUG] 2.6.11: Random SCSI/USB errors when reading from USB memory stick
> > > Latency is the subject of a separate email. Does this > > > increase in latency > > > occur only when you see the errors, or whenever you do a > large data > > > transfer? In fact, I would suspect the errors to _decrease_ > > > the latency > > > with respect to a normal transfer. > > > > I observe from <1 to 2 ms on successful transfers, and around 15 ms > > latency when things go wrong. > > I hate to ask this question; it sounds an awful lot like > "Monty Python and > the Holy Grail", but... Is that IRQ latency or application latency? With Ingo's RT kernels, it is not possible for me to tell the difference, because IRQ handlers are also running as kernel threads, scheduled by the scheduler according to their rt prio (which is around 50 by default, 95 for the RTC IRQ in my case). I can tell for sure that the RTC IRQ handler was not executed in that time, but I can't tell if that's because IRQs were blocked or because it didn't get scheduled. > I can't think of any reason why IRQ latency should change > during the error > handling. Application latency might change because the SCSI > error handler > could start using up a lot of CPU time. I don't know what > priority it > runs at; you can check with ps. Ingo just suggested that error handling (writing kernel messages to console/disk) in general is causing the trouble. I'll check that and post the results. -- Klaus Kusche Entwicklung Software - Steuerung Software Development - Control KEBA AG A-4041 Linz Gewerbepark Urfahr Tel +43 / 732 / 7090-3120 Fax +43 / 732 / 7090-8919 E-Mail: [EMAIL PROTECTED] www.keba.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] xfrm_policy destructor fix
On Sat, 26 Mar 2005 12:11:45 +1100 Herbert Xu <[EMAIL PROTECTED]> wrote: > So here is a patch to simplify xfrm_policy_kill() by moving the > GC linking after the write_unlock_bh(). > > Actually, as the code stands, xfrm_policy_kill() should/will never > be called twice on the same policy. So we can add a warning to > catch that. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Applied, thanks Herbert. - 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] the MPU/noMMU support for ARM Linux 2.6.11.6 (-hsc0)
Greetings, I'm glad to announce the MPU and noMMU support patch for ARM against 2.6.11.6 at: http://opensrc.sec.samsung.com/download/linux-2.6.11.6-hsc0.patch.gz Actually the patch was "armnommu" architecture patch by 2.6.9, but it is just merged into "arm" architecture, and provides selection option, "MMU" for linux and "MPU", "NONE" for uclinux. It means that you can choose "MMU" or even "NONE" for your MMU based arm platform with a few modification (i.e. virtual addr --> physical addr), if you want to use "singular address space" which is proven to have performance improvement. (I'd like to provide some benchmark result on same h/w platform for both cases.) some addtional MPU support API is pending to support new features like memory protection for uclinux, but I need more suggestions on that. You can reach the project at : http://opensrc.sec.samsung.com/ currently officially supported platforms are : s3c24a0, s5c7375, atmel, espd_s3c510b, P2001, s3c3410, s3cb0x. Best Regards, Hyok --- CHOI, HYOK-SUNG Engineer (Kernel/System Architecture) Digital Media R Center, Samsung Electronics Co.,Ltd. tel: +82-31-200-8594 fax: +82-31-200-3427 e-mail: [EMAIL PROTECTED] [Linux 2.6 ARM MPU/noMMU Kernel Maintainer] http://opensrc.sec.samsung.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Industry db benchmark result on recent 2.6 kernels
Nick wrote:
> Ingo had a cool patch to estimate dirty => dirty cacheline transfer latency
> ... Unfortunately ... and it is an O(cpus^2) operation.
Yes - a cool patch.
If we had an arch-specific bit of code, that for any two cpus, could
give a 'pseudo-distance' between them, where the only real requirements
were that (1) if two pairs of cpus had the same pseudo-distance, then
that meant they had the same size, layout, kind and speed of bus amd
cache hardware between them (*), and (2) it was cheap - hardly more than
a few lines of code and a subroutine call to obtain, then Ingo's code
could be:
for each cpu c1:
for each cpu c2:
psdist = pseudo_distance(c1, c2)
if I've seen psdist before, use the latency computed for that
psdist
else compute a real latency number and remember it for that
psdist
A generic form of pseudo_distance, which would work for all normal
sized systems, would be:
int pseudo_distance(int c1, int c2)
{
static int x;
return x++;
}
Then us poor slobs with big honkin numa iron could code up a real
pseudo_distance() routine, to avoid the actual pain of doing real work
for cpus^2 iterations for large cpu counts.
Our big boxes have regular geometries with much symmetry, so would
provide significant opportunity to exploit equal pseudo-distances.
And I would imagine that costs of K * NCPU * NCPU are tolerable in this
estimation routine. for sufficiently small K, and existing values of
NCPU.
(*) That is, if pseudo_distance(c1, c2) == pseudo_distance(d1, d2), then
this meant that however c1 and c2 were connected to each other in the
system (intervening buses and caches and such), cpus d1 and d2 were
connected the same way, so could be presumed to have the same latency,
close enough.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
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: queue_work from interrupt Real time preemption2.6.11-rc2-RT-V0.7.37-03
* Mark Gross <[EMAIL PROTECTED]> wrote: > BTW: > > My work on this has been mostly in the context of a 2.6 kernel based > generalization of a softIRQ as thread patch for 2.4 that enables > priority tuning of the bottom half processing as well as /proc support > for turning on and off the feature. We got it to work. > > However; I don't know what good workloads and metrics to measure the > goodness of the work look like. If folks think priority tuning of > bottom half processing is worth persuing and can help me quantify its > effectiveness better than running a jitter test while doing a BONNIE > test run on a SCSI JBOD, then I'm happy to do more with this. anything that generates a consistent interrupt rate is pretty good for testing. Networking is the most softirq-dependent code, so i'd say tbench over a real network ought to be a good benchmark. Ingo - 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 scsi-misc-2.6 10/13] scsi: rewrite scsi_request_fn()
Hello, Christoph. On Thu, Mar 31, 2005 at 12:14:16PM +0100, Christoph Hellwig wrote: > the changes look good to me (although I haven't tested any of your patches > yet), but the code flow is rather confusing. What do you think about > the not even compile version of scsi_request_fn() below that should be > functionally identical to yours: Yes, it's rather confusing. I was a bit concerned about forward gotos which are not error handling/exit and possible needs for unlikely()'s by putting error handling on hotter path, IOW, untaken forward branch. For the records, I think the likely/unlikely thingies are ugly & over-optimization in many cases. However, your code is aesthetically much better. If there are no opjections regarding the forward non-error-exit jumps, I'll reorganize the code mostly as you suggested in the next take of this patchset. Thanks a lot. :-) -- tejun - 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 scsi-misc-2.6 11/13] scsi: add reprep arg to scsi_requeue_command() and make it public
Hello, Christoph.
On Thu, Mar 31, 2005 at 11:32:03AM +0100, Christoph Hellwig wrote:
> > - * Arguments: q - queue to operate on
> > - * cmd - command that may need to be requeued.
> > + * Arguments: cmd - command that may need to be requeued.
> > + * reprep - needs to prep the command again?
> > *
> > * Returns:Nothing
> > *
> > @@ -478,11 +478,16 @@ void scsi_device_unbusy(struct scsi_devi
> > * we need to request the blocks that come after the bad
> > * sector.
> > */
> > -static void scsi_requeue_command(struct request_queue *q, struct scsi_cmnd
> > *cmd)
> > +void scsi_requeue_command(struct scsi_cmnd *cmd, int reprep)
> > {
> > + struct request_queue *q = cmd->device->request_queue;
> > unsigned long flags;
> >
> > - cmd->request->flags &= ~REQ_DONTPREP;
> > + cmd->state = SCSI_STATE_MLQUEUE;
> > + cmd->owner = SCSI_OWNER_MIDLEVEL;
> > +
> > + if (reprep)
> > + cmd->request->flags &= ~REQ_DONTPREP;
>
> the flag is not needed, you can move the clearing of the flag to the
> caller. And given that there's lots of callers rename the
> scsi_requeue_command without it to __scsi_requeue_command and make
> scsi_requeue_command a tiny inline wrapper around it that clears it.
I opt for scsi_requeue_command() and scsi_requeue_command_reprep()
for clarity (the latter being static inline).
Thanks a lot for all your inputs. :-)
--
tejun
-
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 scsi-misc-2.6 09/13] scsi: in scsi_prep_fn(), remove bogus comments & clean up
Hello, James.
On Thu, Mar 31, 2005 at 12:02:20PM -0600, James Bottomley wrote:
> On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote:
> > -* come up when there is a medium error. We have to treat
> > -* these two cases differently. We differentiate by looking
> > -* at request->cmd, as this tells us the real story.
> > +* come up when there is a medium error.
>
> This comment isn't wrong. That's exactly what this piece of code:
>
> if (sreq->sr_magic == SCSI_REQ_MAGIC) {
>
> is all about ... that's how it distinguishes between the two cases.
>
> The comment is misleading --- what it actually should say is that req-
> >special has different contents depending upon the two cases, so
> rephrasing it to be more accurate would be helpful.
Yes, it was misleading, even more so with previous REQ_SPECIAL
patches. I'll rewrite the comment once we resolve the REQ_SPECIAL
issue.
Thanks.
--
tejun
-
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: [uml-devel] Re: [patch 03/12] uml: export getgid for hostfs
On Thursday 31 March 2005 09:40 am, Christoph Hellwig wrote:
> > Sorry, I wasn't clear... I read *that* answer, but it says "as mentioned
> > in the discussion about ROOT_DEV", and I couldn't find it.
>
> That'd be:
>
> http://marc.theaimsgroup.com/?l=linux-fsdevel=110664428918937=2
As the only user who seems to be crazy enough to regularly run UML with a
hostfs root (ala "./linux rootfstype=hostfs rw init=/bin/sh"), I'd just like
to say that I'm fairly certain I'm _not_ using ROOT_DEV special casing (my
root files actually do belong to root, I'm just borrowing the parent's
filesystem to avoid the trouble of setting up a whole filesystem under
loopback.)
And actually, the ROOT_DEV hack wouldn't help me, because my project is using
a dirty trick where I make a loopback mounted ext2 image (which could easily
be ramfs or tmpfs if my project didn't need 500 megs of scratch space),
--bind mount all the directories from the parent I need into it, and chroot
into it. (Thus I have the parent's binaries and libraries, but the rest is
writeable space I can mknod and chown and such in.) This is done with a
trivial shell script, the guts of which are:
---
for i in /*
do
i="${i:1}"
if [ "$i" != "lost+found" ]
then
if [ -h "$i" ]
then
# Copy symlinks
ln -s `readlink "$i"` "$i"
elif [ -d "/$i" ]
then
# Bind mount directories
mkdir "$i" &&
mount -n -o bind "/$i" "$i"
fi
fi
if [ $? -ne 0 ]; then exit 1; fi
done
# Don't use system /tmp, use a tmp in workspace.img.
umount tmp
mount -n -t devpts /dev/pts dev/pts
With that, the hostfs might as well be read-only.
And as you can see, the above will very much NOT work with anything that cares
about ROOT_DEV, since ROOT_DEV gets chrooted away fairly quickly...
> > Also, I'd like to know whether there's a correct way to implement this
> > (using something different than root_dev, for instance the init[1] root
> > directory mount device). I understand that with the possibility for
> > multiple mounts the "root device" is more difficult to know (and maybe
> > this is the reason for which ROOT_DEV is bogus, is this?), but at least a
> > check on the param "rootfstype=hostfs" could be done.
>
> personally I think it's a bad misfeature by itself. If you absolutely
> want it make it a mount option so it's explicit at least.
If it's going to have it at all, then yes it should be done the way. Lots of
filesystems have something close to this (The affs uid= and gid= options
aren't that far off, for example.)
I'd like to point out that hostfs's rootflags= parsing needs an update. Right
now, it sets the path to the parent directory hostfs is to mount from,
period. (If omitted, the default is "rootflags=/".) Appending something
like ,rw gets treated as part of the path, so right now turning this feature
on would require a remount after UML came up.
Unless it's ALWAYS the default that a hostfs mount turns files belonging to
the user running UML into files belonging to root. It's possible that this
is really the intended behavior, by the way. Whether the mount point is
ROOT_DEV or not is probably irrelevant.
Then again, I haven't personally needed this behavior yet. Mounting hostfs
when UML is run by a non-root user means I can't mknod or chown, no matter
what ownership or permissions the directory I'm in has. And THAT is
something that means I have to supplement hostfs with a loopback mount to get
real writeable space in which I can get anything major done. Making files
look like they belong to root is a purely cosmetic change under those
circumstances.
> And yes, the only place where ROOT_DEV makes sense is in the early boot
> process where the first filesystem in the first namespace is mounted,
> that's why I want to get rid of the export to modules for it.
>
> > Ok, this is nice. I'll repost the (updated) patch CC'ing Ingo Molnar
> > (unless there's another Ingo).
>
> Yupp, mingo
Is anyone, anywhere, actually USING this? I'm using hostfs root fairly
extensively and _not_ using the funky ownership rewriting feature. Is this
something people thought might be needed, or is somewhere somewhere actually
inconvenienced by the lack?
Rob
-
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 scsi-misc-2.6 08/13] scsi: move request preps in other places into prep_fn()
Hello, Christoph. On Thu, Mar 31, 2005 at 11:20:40AM +0100, Christoph Hellwig wrote: > > +/* > > + * Macro to determine the size of SCSI command. This macro takes vendor > > + * unique commands into account. SCSI commands in groups 6 and 7 are > > + * vendor unique and we will depend upon the command length being > > + * supplied correctly in cmd_len. > > + */ > > +#define CDB_SIZE(cmd) (cmd)->cmnd[0] >> 5) & 7) < 6) ? \ > > + COMMAND_SIZE((cmd)->cmnd[0]) : (cmd)->cmd_len) > > should probably go to scsi.h as it's generally usefull. I don't know. Currently it's used only in one place. Actually, I was thinking about moving it into the function where it's used. But if it's useful, renaming it to something like SCSI_CMD_CDB_SIZE() (maybe make it inline function?) and moving to scsi.h shouldn't be any problem. I think we need to hear other people's opinions. Some inputs please. Thanks. -- tejun - 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 scsi-misc-2.6 08/13] scsi: move request preps in other places into prep_fn()
Hello, James. On Thu, Mar 31, 2005 at 12:07:44PM -0600, James Bottomley wrote: > On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote: > > Move request preparations scattered in scsi_request_fn() and > > scsi_dispatch_cmd() into scsi_prep_fn(). > > > > * CDB_SIZE check in scsi_dispatch_cmd() > > * SCSI-2 LUN preparation in scsi_dispatch_cmd() > > * scsi_init_cmd_errh() in scsi_request_fn() > > > > No invalid request reaches scsi_request_fn() anymore. > > This one, I like, there's just one small problem: > > You can't move scsi_init_cmd_errh() out of the request function path: > It's where we set up the sense buffer handling, so it has to be done > every time the command is prepared for execution (the prep function is > only called once)---think what happens if we turn a command around for > retry based on a sense indication. > > So redo the patch and I'll put it in. Ah.. with later requeue path consolidation patches, all requests get their sense buffer cleared during requeueing, which, IMHO, is more logical. Moving scsi_init_cmd_errh() should come after the patch. Sorry. :-) I'll make another take of this patchset (maybe subset) after issues are resolved. I'll split and reorder relocation of scsi_init_cmd_errh then. Thanks. -- tejun - 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] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > > could you send me your latest patch for the bit-spin issue? My main > > issue was cleanliness, so that the patch doesnt get stuck in the -RT > > tree forever. > > I think that's the main problem. Without changing the design of the > ext3 system, I don't think there is a clean patch. The implementation > that I finally settled down with was to make the j_state and > j_journal_head locks two global locks. I had to make a few > modifications to some spots to avoid deadlocks, but this worked out > well. The problem I was worried about was this causing too much > overhead. So the ext3 buffers would have to contend with each other. I > don't have any tests to see if this had too much of an impact. yeah - i think Andrew said that a global lock at that particular place might not be that much of an issue. Ingo - 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 scsi-misc-2.6 04/13] scsi: remove meaningless volatile qualifiers from structure definitions
Hello, Chritoph. On Thu, Mar 31, 2005 at 11:11:45AM +0100, Christoph Hellwig wrote: > On Thu, Mar 31, 2005 at 06:08:10PM +0900, Tejun Heo wrote: > > struct list_headsiblings; /* list of all devices on this host */ > > struct list_headsame_target_siblings; /* just the devices sharing > > same target id */ > > > > - volatile unsigned short device_busy;/* commands actually active on > > low-level */ > > + unsigned short device_busy; /* commands actually active on > > +* low-level. protected by sdev_lock. */ > > You should probably switch it to just unsigned. The other 16bit are wasted > due to alignment anyway, and some architectures produce better code for 32bit > accesses. > > > - volatile unsigned short host_busy; /* commands actually active on > > low-level */ > > - volatile unsigned short host_failed; /* commands that failed. */ > > + > > + /* > > +* The following two fields are protected with host_lock; > > +* however, eh routines can safely access during eh processing > > +* without acquiring the lock. > > +*/ > > + unsigned short host_busy; /* commands actually active on > > low-level */ > > + unsigned short host_failed;/* commands that failed. */ > > Here it would actually increase the struct size but might make sense anyway. Sure, I'll make them unsigned. Thanks. -- tejun - 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 scsi-misc-2.6 05/13] scsi: remove a timer race from scsi_queue_insert() and cleanup timer
Hello, Chritoph. On Thu, Mar 31, 2005 at 11:13:53AM +0100, Christoph Hellwig wrote: > > /* Queue the command and wait for it to complete */ > > /* Abuse eh_timeout in the scsi_cmnd struct for our purposes */ > > init_timer(>eh_timeout); > > + cmd->eh_timeout.function = NULL; > > I'd rather not see aic7xxx poke even deeper into this internal code. > Can you please switch it to use a timer of it's own first? Yes, I'll. Thanks. -- tejun - 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: HELP: PC104 IO card driver Problem
On Thu, 2005-03-31 at 11:07, nobin matthew wrote:
> Dear Friends,
>
> Can anybody Help me in this Pc104 driver Problem;
> What is the basics steps in doing read and write on
> Pc104 cards.
>
> Deatails Given Below:
> I am writing a Linux device driver for
> Diamond systems
> IR104 digital IO card. This is a PC104 bus device(that
> means it ISA
> bus compatible).
> The Platform is Arcom Viper borad(with support for
> PC104), This is a
> Xscale, Little endian Platform.
>
> The Specification of PC104 interface given in Viper
> borad manual is:
> 0x3C00-0x3CFF PC/104 memory space(16MB)
> 0x3000-0x33FF PC/104 IO space(1KB)
>
> Specification given in IR104 manual is:
> I made the jumber setting so that, the IO space
> addresses taken by 8
> registers will be 0x300-0x307
>
> The driver should do read and write on this
> registers(character device
> driver).
>
> I took two approaches one is:
> i added IO space and 0x300, did inb() and oub().(IO
> space base address
> and 0x300)
> otherway i did ioremap on added result, did inb() and
> oub().
/* Remap a not (necessarily) aligned port region */
void *short_remap(unsigned long phys_addr)
{
/* The code comes mainly from arch/any/mm/ioremap.c */
unsigned long offset, last_addr, size;
last_addr = phys_addr + SHORT_NR_PORTS - 1;
offset = phys_addr & ~PAGE_MASK;
/* Adjust the begin and end to remap a full page */
phys_addr &= PAGE_MASK;
size = PAGE_ALIGN(last_addr) - phys_addr;
return ioremap(phys_addr, size) + offset;
}
/* Unmap a region obtained with short_remap */
void short_unmap(void *virt_add)
{
iounmap((void *)((unsigned long)virt_add & PAGE_MASK));
}
>
> In the second method:
> I did same procedures using IO memory space
Here Use ioremap to get a base address in the
region(0x3C00-0x3CFF).
Suppose ISA_BEGIN = 0x3C00, ISA_END = 0x3CFF
void *base;
base = ioremap(ISA_BEGIN, ISA_END - ISA_BEGIN);
base = base - ISA_BEGIN; /* offset */
Use these base address to read and write the IO region.
For more details go to http://www.xml.com/ldd/chapter/book/ch08.html
to get more info.
>
> both methods are giving errors, i think that is
> related to paging. i think
> there is a need for disabling paging in this space.
>
> Please help regarding this. How to solve this.
>
> Nobin Mathew
>
>
>
>
> __
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
>
>
-
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 scsi-misc-2.6 02/13] scsi: don't turn on REQ_SPECIAL on sgtable allocation failure.
Hello, James. On Thu, Mar 31, 2005 at 11:53:45AM -0600, James Bottomley wrote: > On Thu, 2005-03-31 at 18:08 +0900, Tejun Heo wrote: > > Don't turn on REQ_SPECIAL on sgtable allocation failure. This > > was the last place where REQ_SPECIAL is turned on for normal > > requests. > > If you do this, you'll leak a command every time the sgtable allocation > fails. AFAICT, not really. We don't allocate another scsi_cmnd for normal requests if req->special != NULL. Thanks. -- tejun - 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: Industry db benchmark result on recent 2.6 kernels
Ingo Molnar wrote on Thursday, March 31, 2005 8:52 PM > the current scheduler queue in -mm has some experimental bits as well > which will reduce the amount of balancing. But we cannot just merge them > an bloc right now, there's been too much back and forth in recent > kernels. The safe-to-merge-for-2.6.12 bits are already in -BK. I agree, please give me some time to go through these patches on our db setup. > the current defaults for cache_hot_time are 10 msec for NUMA domains, > and 2.5 msec for SMP domains. Clearly too low for CPUs with 9MB cache. > Are you increasing cache_hot_time in your experiment? If that solves > most of the problem that would be an easy thing to fix for 2.6.12. Yes, we are increasing the number in our experiments. It's in the queue and I should have a result soon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
On Fri, 2005-04-01 at 06:43 +0200, Ingo Molnar wrote: > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > Hi Ingo, > > > > I was wondering if the issue the bit_spin_lock has gone into the side > > burner? [...] > > could you send me your latest patch for the bit-spin issue? My main > issue was cleanliness, so that the patch doesnt get stuck in the -RT > tree forever. I think that's the main problem. Without changing the design of the ext3 system, I don't think there is a clean patch. The implementation that I finally settled down with was to make the j_state and j_journal_head locks two global locks. I had to make a few modifications to some spots to avoid deadlocks, but this worked out well. The problem I was worried about was this causing too much overhead. So the ext3 buffers would have to contend with each other. I don't have any tests to see if this had too much of an impact. If you are still interested, then let me know and I'll pull it out and send it to you. I preferred this method over the other wait_on_bit, since using normal spin_locks gives priority inheritance, but to put this into the buffer head seemed too much of an overhead. Also, there was that inverted_lock crap in commit.c that also caused problems. I just used the expensive wait_queue fix, where instead of just calling schedule, I put the task on the wait queue to wake up when the lock was released, and had unlock of j_state_lock wake it up. But this is expensive since every time j_state_lock is unlocked, you need to try to wake up a task that is most likely not there. This I still need to optimize. -- Steve - 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 scsi-misc-2.6 01/13] scsi: don't use blk_insert_request() for requeueing
Hello, James. On Thu, Mar 31, 2005 at 11:53:20AM -0600, James Bottomley wrote: > On Thu, 2005-03-31 at 18:07 +0900, Tejun Heo wrote: > > 01_scsi_no_REQ_SPECIAL_on_requeue.patch > > > > blk_insert_request() has 'reinsert' argument, which, when set, > > turns on REQ_SPECIAL and REQ_SOFTBARRIER and requeues the > > request. SCSI midlayer was the only user of this feature and > > all requeued requests become special requests defeating > > quiesce state. This patch makes scsi midlayer use > > blk_requeue_request() for requeueing and removes 'reinsert' > > feature from blk_insert_request(). > > Well, REQ_SPECIAL is the signal to the mid-layer that we've allocated > the resources necessary to process the command, so in practice it will > be turned on for every requeue request (because we set it when the > command is prepared), Sorry, but where? AFAICT, only blk_insert_request() and scsi_init_io() on sgtable allocation failure set REQ_SPECIAL during scsi midlayer processing. This patch replaces blk_insert_request() with blk_requeue_request() and the next patch removes REQ_SPECIAL setting in scsi_init_io(). REQ_SPECIAL is currently overloaded to mean two different things. * The request is a special request. * The request has been requeued using scsi_queue_insert(). i.e. It has been prepped. However, #2 can be tested by rq->special != NULL condition, and, in fact, the prep_fn already has the code. This is why this and the next patch don't break the requeue path. IMHO, this proves the subtlety of the REQ_SPECIAL semantics. Which path is taken on which case gets kind of confusing by meaning two different things with REQ_SPECIAL. > so this patch would have no effect on your stated > quiesce problem. However, if you think about how requests work with > head insertion and one command following another, there's really not a > huge problem here either. I agree that it's not a huge problem, but it's subtle and has the potential of causing probably non-destructive but confusing behavior on rare cases. > The other reason I don't like this is that we've been trying hard to > sweep excess block knowledge out of the mid-layer. I don't think > REQ_SOFTBARRIER is anything we really have to know about. We currently requeue using two different block functions. * blk_insert_request(): this function does two things 1. enqueue special requests 2. turn on REQ_SPECIAL|REQ_SOFTBARRIER and call blk_requeue_request(). This is used only by scsi midlayer. * blk_requeue_request() REQ_SOFTBARRIER tells the request queue that other requests shouldn't pass this one. We need this to be set for prepped requests; otherwise, it may, theoretically, deadlock (unprepped request waiting for the prepped request back in the queue). So, the current code * depends on blk_insert_request() sets REQ_SOFTBARRIER when requeueing. It works but nothing in the interface or semantics is clear about it. Why expect a request reinserted using blk_insert_request() gets REQ_SOFTBARRIER turned on while a request reinserted with blk_requeue_request() doesn't? or why are there two different paths doing mostly the same thing with slightly different semantics? * requeueing using blk_requeue_request() in scsi_request_fn() doesn't turn on either REQ_SPECIAL or REQ_SOFTBARRIER. Missing REQ_SPECIAL is okay, as we have the extra path in prep_fn (if it ever gets requeued due to medium failure, so gets re-prepped), but missing REQ_SOFTBARRIER can *theoretically* cause problem. So, it's more likely becoming less dependent on unobvious behavior of block layer. As we need the request to stay on top, we tell the block layer to do so, instead of depending on blk_insert_request() unobviously doing it for us. Thanks. -- tejun - 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: Industry db benchmark result on recent 2.6 kernels
* Chen, Kenneth W <[EMAIL PROTECTED]> wrote: > The low point in 2.6.11 could very well be the change in the > scheduler. It does too many load balancing in the wake up path and > possibly made a lot of unwise decision. For example, in > try_to_wake_up(), it will try SD_WAKE_AFFINE for task that is not hot. > By not hot, it looks at when it was last ran and compare to a constant > sd->cache_hot_time. The problem is this cache_hot_time is fixed for > the entire universe, whether it is a little celeron processor with > 128KB of cache or a sever class Itanium2 processor with 9MB L3 cache. > This one size fit all isn't really working at all. the current scheduler queue in -mm has some experimental bits as well which will reduce the amount of balancing. But we cannot just merge them an bloc right now, there's been too much back and forth in recent kernels. The safe-to-merge-for-2.6.12 bits are already in -BK. > We had experimented that parameter earlier and found it was one of the > major source of low point in 2.6.8. I debated the issue on LKML about > 4 month ago and finally everyone agreed to make that parameter a boot > time param. The change made into bk tree for 2.6.9 release, but > somehow it got ripped right out 2 days after it went in. I suspect > 2.6.11 is a replay of 2.6.8 for the regression in the scheduler. We > are running experiment to confirm this theory. the current defaults for cache_hot_time are 10 msec for NUMA domains, and 2.5 msec for SMP domains. Clearly too low for CPUs with 9MB cache. Are you increasing cache_hot_time in your experiment? If that solves most of the problem that would be an easy thing to fix for 2.6.12. Ingo - 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] IPoIB: set skb->mac.raw on receive
David> Roland, netdev@oss.sgi.com CC:'ing either Jeff Garzik and David> myself, please. Sorry, will do next time around, unless you'd like me to resend this batch as well. All 3 patches are pretty trivial, though. The biggest one is just deleting a lot of code by switching to debugfs. - R. - 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/
Unusable/non working PCI-Express on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that work with all 2.6.11.[1-6] kernels. Its a real odd right now. I have 25 computers with an Intel 925XE Chipset and Intel 6xx CPU. It does not metter which vendor I choose the problem spread all over.I tried to boot with pci=routeicq but it did not help to get one device working ith 2.6.12-rc1-xx kernel. As I mentioned before I tested it with over 25 computer (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system [EMT64] and SMP/SMT enabled and preempt. My first look was on PCI Routingtable and what I found in difference to 2.6.11.x working kernel is that: Here I print the posssible bug/problem, lspci and dmesg output from kernel. So far Thanks in advance and best regards //possible bug/problem PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 Boot video device is :04:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :04:00.0 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:09.0 ACPI: Can't get handler for :01:0a.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) //lspci -v output :00:00.0 Host bridge: Intel Corporation 925X/XE Memory Controller Hub (rev 0e) Subsystem: Intel Corporation: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [0109] :00:01.0 PCI bridge: Intel Corporation 925X/XE PCI Express Root Port (rev 0e) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: d2f0-d7ff Prefetchable memory behind bridge: d800-dfff Expansion ROM at e000 [disabled] [size=4K] Capabilities: [88] #0d [] Capabilities: [80] Power Management version 2 Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [a0] #10 [0141] :00:1b.0 Class 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 169 Memory at d2cf4000 (64-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] :00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: d000-dfff Expansion ROM at d000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d2e0-d2ef Expansion ROM at c000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 50 I/O ports at 9880 [size=32] :00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 233 I/O ports at 9c00 [size=32] :00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > Hi Ingo, > > I was wondering if the issue the bit_spin_lock has gone into the side > burner? [...] could you send me your latest patch for the bit-spin issue? My main issue was cleanliness, so that the patch doesnt get stuck in the -RT tree forever. Ingo - 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: AMD64 Machine hardlocks when using memset
Stelian Pop wrote: Just a thought: does deactivating cpufreq change anything ? I haven't tested yet your program, but on my Asus K8NE-Deluxe very strange things happen if cpufreq/powernow is activated *and* the cpu frequency is changed... Didn't change anything for me, I tried deactivating cpufreq, still crashes when I run that test program. This is getting pretty ridiculous.. I've tried memory timings down to the slowest possible, ran Memtest86 for 4 passes with no errors, and it's been stable in Windows for a few months now. Still something is blowing up in Linux with this test though.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS client latencies
* Lee Revell <[EMAIL PROTECTED]> wrote:
> > > ah - cool! This was a 100 MB writeout so having 3.7 msecs to process
> > > 20K+ pages is not unreasonable. To break the latency, can i just do a
> > > simple lock-break, via the patch below?
> >
> > with this patch the worst-case latency during NFS writeout is down to 40
> > usecs (!).
> >
> > Lee: i've uploaded the -42-05 release with this patch included - could
> > you test it on your (no doubt more complex than mine) NFS setup?
>
> This fixes all the NFS related latency problems I was seeing. Now the
> longest latency from an NFS kernel compile with "make -j64" is 391
> usecs in get_swap_page.
great! The latest patches (-42-08 and later) have the reworked
nfs_scan_list() lock-breaker, which should perform similarly.
i bet these NFS patches also improve generic NFS performance on fast
networks. I've attached the full patchset with all fixes and
improvements included - might be worth a try in -mm?
Ingo
--- linux/fs/nfs/inode.c.orig
+++ linux/fs/nfs/inode.c
@@ -118,7 +118,7 @@ nfs_write_inode(struct inode *inode, int
int flags = sync ? FLUSH_WAIT : 0;
int ret;
- ret = nfs_commit_inode(inode, 0, 0, flags);
+ ret = nfs_commit_inode(inode, flags);
if (ret < 0)
return ret;
return 0;
--- linux/fs/nfs/write.c.orig
+++ linux/fs/nfs/write.c
@@ -352,7 +352,7 @@ int nfs_writepages(struct address_space
if (err < 0)
goto out;
}
- err = nfs_commit_inode(inode, 0, 0, wb_priority(wbc));
+ err = nfs_commit_inode(inode, wb_priority(wbc));
if (err > 0) {
wbc->nr_to_write -= err;
err = 0;
@@ -446,6 +446,8 @@ nfs_mark_request_dirty(struct nfs_page *
struct nfs_inode *nfsi = NFS_I(inode);
spin_lock(>req_lock);
+ radix_tree_tag_set(>nfs_page_tree,
+ req->wb_index, NFS_PAGE_TAG_DIRTY);
nfs_list_add_request(req, >dirty);
nfsi->ndirty++;
spin_unlock(>req_lock);
@@ -503,13 +505,12 @@ nfs_wait_on_requests(struct inode *inode
spin_lock(>req_lock);
next = idx_start;
- while (radix_tree_gang_lookup(>nfs_page_tree, (void **),
next, 1)) {
+ while (radix_tree_gang_lookup_tag(>nfs_page_tree, (void **),
next, 1, NFS_PAGE_TAG_WRITEBACK)) {
if (req->wb_index > idx_end)
break;
next = req->wb_index + 1;
- if (!NFS_WBACK_BUSY(req))
- continue;
+ BUG_ON(!NFS_WBACK_BUSY(req));
atomic_inc(>wb_count);
spin_unlock(>req_lock);
@@ -538,12 +539,15 @@ static int
nfs_scan_dirty(struct inode *inode, struct list_head *dst, unsigned long
idx_start, unsigned int npages)
{
struct nfs_inode *nfsi = NFS_I(inode);
- int res;
- res = nfs_scan_list(>dirty, dst, idx_start, npages);
- nfsi->ndirty -= res;
- sub_page_state(nr_dirty,res);
- if ((nfsi->ndirty == 0) != list_empty(>dirty))
- printk(KERN_ERR "NFS: desynchronized value of nfs_i.ndirty.\n");
+ int res = 0;
+
+ if (nfsi->ndirty != 0) {
+ res = nfs_scan_lock_dirty(nfsi, dst, idx_start, npages);
+ nfsi->ndirty -= res;
+ sub_page_state(nr_dirty,res);
+ if ((nfsi->ndirty == 0) != list_empty(>dirty))
+ printk(KERN_ERR "NFS: desynchronized value of
nfs_i.ndirty.\n");
+ }
return res;
}
@@ -562,11 +566,14 @@ static int
nfs_scan_commit(struct inode *inode, struct list_head *dst, unsigned long
idx_start, unsigned int npages)
{
struct nfs_inode *nfsi = NFS_I(inode);
- int res;
- res = nfs_scan_list(>commit, dst, idx_start, npages);
- nfsi->ncommit -= res;
- if ((nfsi->ncommit == 0) != list_empty(>commit))
- printk(KERN_ERR "NFS: desynchronized value of
nfs_i.ncommit.\n");
+ int res = 0;
+
+ if (nfsi->ncommit != 0) {
+ res = nfs_scan_list(nfsi, >commit, dst, idx_start,
npages);
+ nfsi->ncommit -= res;
+ if ((nfsi->ncommit == 0) != list_empty(>commit))
+ printk(KERN_ERR "NFS: desynchronized value of
nfs_i.ncommit.\n");
+ }
return res;
}
#endif
@@ -821,7 +828,7 @@ out:
#else
nfs_inode_remove_request(req);
#endif
- nfs_unlock_request(req);
+ nfs_clear_page_writeback(req);
}
static inline int flush_task_priority(int how)
@@ -952,7 +959,7 @@ out_bad:
nfs_writedata_free(data);
}
nfs_mark_request_dirty(req);
- nfs_unlock_request(req);
+ nfs_clear_page_writeback(req);
return -ENOMEM;
}
@@ -1002,7 +1009,7 @@ static int nfs_flush_one(struct list_hea
struct nfs_page *req = nfs_list_entry(head->next);
nfs_list_remove_request(req);
Re: sysfs for IPMI, for new mm kernels
Dmitry Torokhov wrote:
On Thursday 31 March 2005 22:02, Corey Minyard wrote:
+ snprintf(name, sizeof(name), "ipmi%d", if_num);
+ class_device_create(ipmi_class, dev, NULL, name);
class_device_create(ipmi_class, dev, NULL, "ipmi%d", if_num) ?
Yes, much better. Let's try again...
-Corey
Add support for sysfs to the IPMI device interface.
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
Index: linux-2.6.12-rc1/drivers/char/ipmi/ipmi_devintf.c
===
--- linux-2.6.12-rc1.orig/drivers/char/ipmi/ipmi_devintf.c
+++ linux-2.6.12-rc1/drivers/char/ipmi/ipmi_devintf.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#define IPMI_DEVINTF_VERSION "v33"
@@ -519,15 +520,21 @@
" interface. Other values will set the major device number"
" to that value.");
+static struct class *ipmi_class;
+
static void ipmi_new_smi(int if_num)
{
- devfs_mk_cdev(MKDEV(ipmi_major, if_num),
- S_IFCHR | S_IRUSR | S_IWUSR,
+ dev_t dev = MKDEV(ipmi_major, if_num);
+
+ devfs_mk_cdev(dev, S_IFCHR | S_IRUSR | S_IWUSR,
"ipmidev/%d", if_num);
+
+ class_device_create(ipmi_class, dev, NULL, "ipmi%d", if_num);
}
static void ipmi_smi_gone(int if_num)
{
+ class_device_destroy(ipmi_class, MKDEV(ipmi_major, if_num));
devfs_remove("ipmidev/%d", if_num);
}
@@ -548,8 +555,15 @@
printk(KERN_INFO "ipmi device interface version "
IPMI_DEVINTF_VERSION "\n");
+ ipmi_class = class_create(THIS_MODULE, "ipmi");
+ if (IS_ERR(ipmi_class)) {
+ printk(KERN_ERR "ipmi: can't register device class\n");
+ return PTR_ERR(ipmi_class);
+ }
+
rv = register_chrdev(ipmi_major, DEVICE_NAME, _fops);
if (rv < 0) {
+ class_destroy(ipmi_class);
printk(KERN_ERR "ipmi: can't get major %d\n", ipmi_major);
return rv;
}
@@ -563,6 +577,7 @@
rv = ipmi_smi_watcher_register(_watcher);
if (rv) {
unregister_chrdev(ipmi_major, DEVICE_NAME);
+ class_destroy(ipmi_class);
printk(KERN_WARNING "ipmi: can't register smi watcher\n");
return rv;
}
@@ -573,6 +588,7 @@
static __exit void cleanup_ipmi(void)
{
+ class_destroy(ipmi_class);
ipmi_smi_watcher_unregister(_watcher);
devfs_remove(DEVICE_NAME);
unregister_chrdev(ipmi_major, DEVICE_NAME);
Re: [PATCH scsi-misc-2.6 01/13] scsi: don't use blk_insert_request() for requeueing
On Thu, Mar 31, 2005 at 11:12:11AM +0100, Christoph Hellwig wrote: > On Thu, Mar 31, 2005 at 06:07:55PM +0900, Tejun Heo wrote: > > 01_scsi_no_REQ_SPECIAL_on_requeue.patch > > > > blk_insert_request() has 'reinsert' argument, which, when set, > > turns on REQ_SPECIAL and REQ_SOFTBARRIER and requeues the > > request. SCSI midlayer was the only user of this feature and > > all requeued requests become special requests defeating > > quiesce state. This patch makes scsi midlayer use > > blk_requeue_request() for requeueing and removes 'reinsert' > > feature from blk_insert_request(). > > > > Note: In drivers/scsi/scsi_lib.c, scsi_single_lun_run() and > > scsi_run_queue() are moved upward unchanged. > > That lest part doesn't belong into this patch at all. Actually, it is, as scsi_queue_insert() is changed to call scsi_run_queue() explicitly. However, scsi_queue_insert() is removed later, so the change is pretty dumb. Maybe I'll add prototype and remove it together later, or reorder patches. Thanks. -- tejun - 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] IPoIB: set skb->mac.raw on receive
Roland, netdev@oss.sgi.com CC:'ing either Jeff Garzik and myself, please. - 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/
[no subject]
Geachte dames en heren, Ergert u zich ook altijd over de hoge prijzen die voor software gevraagd worden? Daar komt nu een einde aan. Wij leveren u alle mogelijke software voor een fractie van de normale prijs. De software wordt vanuit het buitenland direct naar uw adres verzonden, omdat het daar minder kost dan in de winkels alhier. Originele versies met originele serienummers en de normale support voor weinig geld, bijvoorbeeld: Microsoft Windows XP prof. voor 50 USD in plaats van 270 USD Adobe Photoshop 80 USD in plaats van 650 USD Deze en andere topprodukten kunt u verwachten. Aarzel niet en bezoek onze winkel. De winkel is geheel Engelstalig, maar alle produkten kunnen in elke taal geinstalleerd worden. Veel winkelplezier. Met vriendelijke groet, ResellerNews - 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/
Photoshop 80 USD
Geachte dames en heren, Ergert u zich ook altijd over de hoge prijzen die voor software gevraagd worden? Daar komt nu een einde aan. Wij leveren u alle mogelijke software voor een fractie van de normale prijs. De software wordt vanuit het buitenland direct naar uw adres verzonden, omdat het daar minder kost dan in de winkels alhier. Originele versies met originele serienummers en de normale support voor weinig geld, bijvoorbeeld: Microsoft Windows XP prof. voor 50 USD in plaats van 270 USD Adobe Photoshop 80 USD in plaats van 650 USD Deze en andere topprodukten kunt u verwachten. Aarzel niet en bezoek onze winkel. De winkel is geheel Engelstalig, maar alle produkten kunnen in elke taal geinstalleerd worden. Veel winkelplezier. Met vriendelijke groet, ResellerNews - 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] IPoIB: convert to debugfs
Convert IPoIB to use debugfs instead of its own custom debugging filesystem.
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_fs.c 2005-03-31
19:07:14.463965782 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_fs.c2005-03-31
19:31:28.624283013 -0800
@@ -32,19 +32,16 @@
* $Id: ipoib_fs.c 1389 2004-12-27 22:56:47Z roland $
*/
-#include
+#include
#include
-#include "ipoib.h"
+struct file_operations;
-enum {
- IPOIB_MAGIC = 0x49504942 /* "IPIB" */
-};
+#include
+
+#include "ipoib.h"
-static DECLARE_MUTEX(ipoib_fs_mutex);
static struct dentry *ipoib_root;
-static struct super_block *ipoib_sb;
-static LIST_HEAD(ipoib_device_list);
static void *ipoib_mcg_seq_start(struct seq_file *file, loff_t *pos)
{
@@ -145,143 +142,34 @@
.release = seq_release
};
-static struct inode *ipoib_get_inode(void)
-{
- struct inode *inode = new_inode(ipoib_sb);
-
- if (inode) {
- inode->i_mode= S_IFREG | S_IRUGO;
- inode->i_uid = 0;
- inode->i_gid = 0;
- inode->i_blksize = PAGE_CACHE_SIZE;
- inode->i_blocks = 0;
- inode->i_atime = inode->i_mtime = inode->i_ctime =
CURRENT_TIME;
- inode->i_fop = _fops;
- }
-
- return inode;
-}
-
-static int __ipoib_create_debug_file(struct net_device *dev)
+int ipoib_create_debug_file(struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
- struct dentry *dentry;
- struct inode *inode;
char name[IFNAMSIZ + sizeof "_mcg"];
snprintf(name, sizeof name, "%s_mcg", dev->name);
- dentry = d_alloc_name(ipoib_root, name);
- if (!dentry)
- return -ENOMEM;
-
- inode = ipoib_get_inode();
- if (!inode) {
- dput(dentry);
- return -ENOMEM;
- }
-
- inode->u.generic_ip = dev;
- priv->mcg_dentry = dentry;
-
- d_add(dentry, inode);
-
- return 0;
-}
-
-int ipoib_create_debug_file(struct net_device *dev)
-{
- struct ipoib_dev_priv *priv = netdev_priv(dev);
-
- down(_fs_mutex);
-
- list_add_tail(>fs_list, _device_list);
-
- if (!ipoib_sb) {
- up(_fs_mutex);
- return 0;
- }
-
- up(_fs_mutex);
+ priv->mcg_dentry = debugfs_create_file(name, S_IFREG | S_IRUGO,
+ ipoib_root, dev, _fops);
- return __ipoib_create_debug_file(dev);
+ return priv->mcg_dentry ? 0 : -ENOMEM;
}
void ipoib_delete_debug_file(struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
- down(_fs_mutex);
- list_del(>fs_list);
- if (!ipoib_sb) {
- up(_fs_mutex);
- return;
- }
- up(_fs_mutex);
-
- if (priv->mcg_dentry) {
- d_drop(priv->mcg_dentry);
- simple_unlink(ipoib_root->d_inode, priv->mcg_dentry);
- }
-}
-
-static int ipoib_fill_super(struct super_block *sb, void *data, int silent)
-{
- static struct tree_descr ipoib_files[] = {
- { "" }
- };
- struct ipoib_dev_priv *priv;
- int ret;
-
- ret = simple_fill_super(sb, IPOIB_MAGIC, ipoib_files);
- if (ret)
- return ret;
-
- ipoib_root = sb->s_root;
-
- down(_fs_mutex);
-
- ipoib_sb = sb;
-
- list_for_each_entry(priv, _device_list, fs_list) {
- ret = __ipoib_create_debug_file(priv->dev);
- if (ret)
- break;
- }
-
- up(_fs_mutex);
-
- return ret;
-}
-
-static struct super_block *ipoib_get_sb(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
-{
- return get_sb_single(fs_type, flags, data, ipoib_fill_super);
+ if (priv->mcg_dentry)
+ debugfs_remove(priv->mcg_dentry);
}
-static void ipoib_kill_sb(struct super_block *sb)
-{
- down(_fs_mutex);
- ipoib_sb = NULL;
- up(_fs_mutex);
-
- kill_litter_super(sb);
-}
-
-static struct file_system_type ipoib_fs_type = {
- .owner = THIS_MODULE,
- .name = "ipoib_debugfs",
- .get_sb = ipoib_get_sb,
- .kill_sb= ipoib_kill_sb,
-};
-
int ipoib_register_debugfs(void)
{
- return register_filesystem(_fs_type);
+ ipoib_root = debugfs_create_dir("ipoib", NULL);
+ return ipoib_root ? 0 : -ENOMEM;
}
void ipoib_unregister_debugfs(void)
{
- unregister_filesystem(_fs_type);
+ debugfs_remove(ipoib_root);
}
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-31
19:26:39.094134171 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-31
19:30:51.117424929 -0800
@@ -1082,19 +1082,19 @@
return 0;
-err_fs:
- ipoib_unregister_debugfs();
[PATCH][1/3] IPoIB: set skb->mac.raw on receive
From: Hal Rosenstock <[EMAIL PROTECTED]>
Set skb->mac.raw on receive. This fixes crashes when this is
dereferenced, for example by netfilter or when PF_PACKET is used.
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
--- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2005-03-31
19:07:06.912605203 -0800
+++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_ib.c2005-03-31
19:23:30.599053347 -0800
@@ -201,7 +201,7 @@
if (wc->slid != priv->local_lid ||
wc->src_qp != priv->qp->qp_num) {
skb->protocol = ((struct ipoib_header *)
skb->data)->proto;
-
+ skb->mac.raw = skb->data;
skb_pull(skb, IPOIB_ENCAP_LEN);
dev->last_rx = jiffies;
-
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] IPoIB: fix static rate calculation
Correct and simplify calculation of static rate. We need to round up the quotient of (local_rate - path_rate) / path_rate. To round up we add (path_rate - 1) to the numerator, so the quotient simplifies to (local_rate - 1) / path_rate. No idea how I came up with the old formula. Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> --- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-31 19:06:47.984714505 -0800 +++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_main.c 2005-03-31 19:26:39.094134171 -0800 @@ -302,11 +302,10 @@ .sl= pathrec->sl, .port_num = priv->port }; + int path_rate = ib_sa_rate_enum_to_int(pathrec->rate); - if (ib_sa_rate_enum_to_int(pathrec->rate) > 0) - av.static_rate = (2 * priv->local_rate - - ib_sa_rate_enum_to_int(pathrec->rate) - 1) / - (priv->local_rate ? priv->local_rate : 1); + if (path_rate > 0 && priv->local_rate > path_rate) + av.static_rate = (priv->local_rate - 1) / path_rate; ipoib_dbg(priv, "static_rate %d for local port %dX, path %dX\n", av.static_rate, priv->local_rate, --- linux-export.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2005-03-31 19:07:01.877698296 -0800 +++ linux-export/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2005-03-31 19:26:03.861782487 -0800 @@ -258,13 +258,12 @@ .traffic_class = mcast->mcmember.traffic_class } }; + int path_rate = ib_sa_rate_enum_to_int(mcast->mcmember.rate); av.grh.dgid = mcast->mcmember.mgid; - if (ib_sa_rate_enum_to_int(mcast->mcmember.rate) > 0) - av.static_rate = (2 * priv->local_rate - - ib_sa_rate_enum_to_int(mcast->mcmember.rate) - 1) / - (priv->local_rate ? priv->local_rate : 1); + if (path_rate > 0 && priv->local_rate > path_rate) + av.static_rate = (priv->local_rate - 1) / path_rate; ipoib_dbg_mcast(priv, "static_rate %d for local port %dX, mcmember %dX\n", av.static_rate, priv->local_rate, - 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: 64bit build of tulip driver
Grant Thanx for your feedback. I got it working, but I don't think the patch is the best. Here is the patch, and the information, but if you can recommend a different way to fix it, let me know. The patch was done by Peter Horton. Here is the link to the full patch, http://ftp.jg555.com/patches/raq2/linux/linux-2.6.11.6-raq2_fix-2.patch but here is the section for this issue @@ -1628,6 +1631,16 @@ } } +#if defined(CONFIG_MIPS_COBALT) && defined(CONFIG_MIPS64) +/* + * something very bad is happening. without this + * cache flush the PHY can't be read. I've tried + * various ins & outs, delays etc but only a call + * to printk or this flush seems to fix it ... help! + */ +flush_cache_all(); +#endif + /* Find the connected MII xcvrs. Doing this in open() would allow detecting external xcvrs later, but takes much time. */ Are there any config option differences? e.g. MWI or MMIO options enabled on 64-bit but not 32-bit? I verified that there are no differences. ISTR to remember submitting a patch so additional data gets printed in tulip_stop_rxtx. Here is a reference to the patch but I don't think it is relevant to the this problem: http://lkml.org/lkml/2004/12/15/119 Applied the patch, here is the output :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) I was able to get some more information on the bootup sequence with the updates. Here is the output now from the driver Linux Tulip driver version 1.1.13 (May 11, 2002) PCI: Enabling device :00:07.0 (0045 -> 0047) tulip0: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. tulip0: EEPROM default media type Autosense. tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. tulip0: ***WARNING***: No MII transceiver found! eth0: Digital DS21143 Tulip rev 65 at b0001400, 00:10:E0:00:32:DE, IRQ 19. PCI: Enabling device :00:0c.0 (0005 -> 0007) tulip1: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. tulip1: EEPROM default media type Autosense. tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. tulip1: ***WARNING***: No MII transceiver found! eth1: Digital DS21143 Tulip rev 65 at b0001480, 00:10:E0:00:32:DF, IRQ 20. -- Jim Gifford [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: sysfs for IPMI, for new mm kernels
On Thursday 31 March 2005 22:02, Corey Minyard wrote: > +ÂÂÂsnprintf(name, sizeof(name), "ipmi%d", if_num); > +ÂÂÂclass_device_create(ipmi_class, dev, NULL, name); > class_device_create(ipmi_class, dev, NULL, "ipmi%d", if_num) ? -- Dmitry - 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: LSM hooks
Quoting Chris Wright ([EMAIL PROTECTED]): > * John Richard Moser ([EMAIL PROTECTED]) wrote: > > So, Which version of Linux will first implement stacking in LSM as per > > Serge Hallyn's patches? > > None are ready yet. Serge is still wading through performance testing. > There's no telling about merging without a magic eightball, a handle on > the performance issues, and some bonafide users. Oh, just to keep anyone interested up to date: It turns out nearly all of the inordinate performance degredation I was seeing in the last set of results which I reported was due to a prefetch weirdness on my ppc64 test system. In particular, the hlist_for_each_entry macro automatically prefetches tmp->next. Since my tests were done with selinux+capability, it was the case that tmp->next was always NULL (which always causes a bad prefetch case on ppc64) and, to boot, never used, since the comparison inside the loop always succeeded and immediately returned the first entry. A new set of results should hopefully be coming next week. -serge - 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/2] fork_connector: add a fork connector
On Tue, 29 Mar 2005 07:23:35 -0800, Paul Jackson <[EMAIL PROTECTED]> wrote: > Out of curiosity, what are these 'several user space applications?' The > only one I know of is this extension to bsd accounting to include > capturing parent and child pid at fork. Probably you've mentioned some > other uses of fork_connector before here, but I missed it. I have a user-space batch job scheduler that could use fork_connector to track which processes belong to a job. It looks perfect for what I need. I would also like to see a do_exit hook, but only as a convenience. I can probably scrape the BSD accounting files in lieu of a do_exit hook, but if I had one, I wouldn't need to touch disk for my job accounting. d - 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: noresume breaks next suspend [was Re: 2.6.12-rc1 swsusp broken]
Hi again. On Fri, 2005-04-01 at 10:50, Nigel Cunningham wrote: > > OTOH, perhaps refusing suspend is right thing to do. If user is > > running in "safe mode" (with noresume), we don't want him to be able > > to suspend... > > What? If you suspend, then decide not to resume, you can suspend again > until after your next reboot?! err... "...can't suspend again..." > Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://suspend2.net - 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/
sysfs for IPMI, for new mm kernels
Andrew,
There are some major changes in the current mm kernels to the class
interface that require changes to the IPMI driver. Thus the previously
posted sysfs changes for IPMI are now incorrect. Here's a new one.
-Corey
Add support for sysfs to the IPMI device interface.
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
Index: linux-2.6.12-rc1/drivers/char/ipmi/ipmi_devintf.c
===
--- linux-2.6.12-rc1.orig/drivers/char/ipmi/ipmi_devintf.c
+++ linux-2.6.12-rc1/drivers/char/ipmi/ipmi_devintf.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#define IPMI_DEVINTF_VERSION "v33"
@@ -519,15 +520,24 @@
" interface. Other values will set the major device number"
" to that value.");
+static struct class *ipmi_class;
+
static void ipmi_new_smi(int if_num)
{
+ char name[10];
+ dev_t dev = MKDEV(ipmi_major, if_num);
+
devfs_mk_cdev(MKDEV(ipmi_major, if_num),
S_IFCHR | S_IRUSR | S_IWUSR,
"ipmidev/%d", if_num);
+
+ snprintf(name, sizeof(name), "ipmi%d", if_num);
+ class_device_create(ipmi_class, dev, NULL, name);
}
static void ipmi_smi_gone(int if_num)
{
+ class_device_destroy(ipmi_class, MKDEV(ipmi_major, if_num));
devfs_remove("ipmidev/%d", if_num);
}
@@ -548,8 +558,15 @@
printk(KERN_INFO "ipmi device interface version "
IPMI_DEVINTF_VERSION "\n");
+ ipmi_class = class_create(THIS_MODULE, "ipmi");
+ if (IS_ERR(ipmi_class)) {
+ printk(KERN_ERR "ipmi: can't register device class\n");
+ return PTR_ERR(ipmi_class);
+ }
+
rv = register_chrdev(ipmi_major, DEVICE_NAME, _fops);
if (rv < 0) {
+ class_destroy(ipmi_class);
printk(KERN_ERR "ipmi: can't get major %d\n", ipmi_major);
return rv;
}
@@ -563,6 +580,7 @@
rv = ipmi_smi_watcher_register(_watcher);
if (rv) {
unregister_chrdev(ipmi_major, DEVICE_NAME);
+ class_destroy(ipmi_class);
printk(KERN_WARNING "ipmi: can't register smi watcher\n");
return rv;
}
@@ -573,6 +591,7 @@
static __exit void cleanup_ipmi(void)
{
+ class_destroy(ipmi_class);
ipmi_smi_watcher_unregister(_watcher);
devfs_remove(DEVICE_NAME);
unregister_chrdev(ipmi_major, DEVICE_NAME);
Re: connector.c
Uttered Andrew Morton <[EMAIL PROTECTED]>, spake thus:
> > if (uskb) {
> > netlink_unicast(dev->nls, uskb, 0, 0);
> > }
>
> Unneeded {}
Speaking strictly as a language lawyer, they are not needed.
However, for maintainability (and best practices) they are essential.
They make the scope of the test explicit and ensure that a one-line-
change really doesn't affect more lines that needed. Think context
diffs here.
Cheers!
pgpxmU7zEZWpd.pgp
Description: PGP signature
Re: NFS client latencies
On Thu, 2005-03-31 at 16:50 +0200, Ingo Molnar wrote: > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > So the overhead you are currently seeing should just be that of > > > iterating through the list, locking said requests and adding them to > > > our private list. > > > > ah - cool! This was a 100 MB writeout so having 3.7 msecs to process > > 20K+ pages is not unreasonable. To break the latency, can i just do a > > simple lock-break, via the patch below? > > with this patch the worst-case latency during NFS writeout is down to 40 > usecs (!). > > Lee: i've uploaded the -42-05 release with this patch included - could > you test it on your (no doubt more complex than mine) NFS setup? This fixes all the NFS related latency problems I was seeing. Now the longest latency from an NFS kernel compile with "make -j64" is 391 usecs in get_swap_page. Lee - 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/
Beursverkoop software
Geachte dames en heren, Ergert u zich ook altijd over de hoge prijzen die voor software gevraagd worden? Daar komt nu een einde aan. Wij leveren u alle mogelijke software voor een fractie van de normale prijs. De software wordt vanuit het buitenland direct naar uw adres verzonden, omdat het daar minder kost dan in de winkels alhier. Originele versies met originele serienummers en de normale support voor weinig geld, bijvoorbeeld: Microsoft Windows XP prof. voor 50 USD in plaats van 270 USD Adobe Photoshop 80 USD in plaats van 650 USD Deze en andere topprodukten kunt u verwachten. Aarzel niet en bezoek onze winkel. De winkel is geheel Engelstalig, maar alle produkten kunnen in elke taal geinstalleerd worden. Veel winkelplezier. Met vriendelijke groet, ResellerNews - 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: AMD64 Machine hardlocks when using memset
Philip Lawatsch wrote:
I've now tried the most conservative settings available. The 32 bit
kernel now hangs after about 15 Iterations (compared to about 16000
before) but the 64 bit kernel still hangs after about 5000.
I'm still seeing this on my system as well, using the most conservative
timings possible (DDR200, all delay parameters except the refresh time
set to the largest possible value) as well as DDR333 with the same
timings and DDR400 with everything set to auto. I also tried the kernel
on the Fedora Core 3 rescue disc (same crash) and in single user mode
(same crash).
So far, the crashes have consisted of either a hang, reboot or panic.
One panic was a "spinlock already locked at kernel/module.c:2022" error.
The other one is below, for what it's worth:
Mar 31 18:55:43 Newcastle kernel: Unable to handle kernel paging request
at 8100588f5000 RIP:
Mar 31 18:55:43 Newcastle kernel: {clear_page+7}
Mar 31 18:55:43 Newcastle kernel: PGD 8063 PUD a063 PMD 0
Mar 31 18:55:43 Newcastle kernel: Oops: 0002 [1]
Mar 31 18:55:43 Newcastle kernel: CPU 0
Mar 31 18:55:43 Newcastle kernel: Modules linked in: md5(U) ipv6(U)
parport_pc(U) lp(U) parport(U) autofs4(U) it87(U) i2c_sensor(U)
i2c_isa(U) i2c_dev(U) i2c_core(U) sunrpc(U) pcmcia(U) yenta_socket(U)
rsrc_nonstatic(U) pcmcia_core(U) joydev(U) nls_utf8(U) ntfs(U) vfat(U)
fat(U) dm_mod(U) video(U) button(U) battery(U) ac(U) usb_storage(U)
ohci1394(U) ieee1394(U) ohci_hcd(U) ehci_hcd(U) snd_ice1724(U)
snd_ice17xx_ak4xxx(U) snd_ac97_codec(U) snd_pcm_oss(U) snd_mixer_oss(U)
snd_pcm(U) snd_timer(U) snd_page_alloc(U) snd_ak4xxx_adda(U)
snd_mpu401_uart(U) snd_rawmidi(U) snd_seq_device(U) snd(U) soundcore(U)
forcedeth(U) floppy(U) ext3(U) jbd(U) sata_nv(U) libata(U) sd_mod(U)
scsi_mod(U)
Mar 31 18:55:43 Newcastle kernel: Pid: 4928, comm: crashtest Not tainted
2.6.11-1.7_FC3custom
Mar 31 18:55:43 Newcastle kernel: RIP: 0010:[]
{clear_page+7}
Mar 31 18:55:43 Newcastle kernel: RSP: :810078299ca0 EFLAGS:
00010246
Mar 31 18:55:43 Newcastle kernel: RAX: RBX:
0001 RCX: 0200
Mar 31 18:55:43 Newcastle kernel: RDX: 80478940 RSI:
RDI: 8100588f5000
Mar 31 18:55:43 Newcastle kernel: RBP: 81000235f5d0 R08:
R09:
Mar 31 18:55:43 Newcastle kernel: R10: 000552fa R11:
R12: 8100
Mar 31 18:55:43 Newcastle kernel: R13: 81000235f598 R14:
6db6db6db6db6db7 R15:
Mar 31 18:55:43 Newcastle kernel: FS: 2aabeb00()
GS:80552300() knlGS:
Mar 31 18:55:43 Newcastle kernel: CS: 0010 DS: ES: CR0:
8005003b
Mar 31 18:55:43 Newcastle kernel: CR2: 8100588f5000 CR3:
791b CR4: 06e0
Mar 31 18:55:43 Newcastle kernel: Process crashtest (pid: 4928,
threadinfo 810078298000, task 8100788d67e0)
Mar 31 18:55:43 Newcastle kernel: Stack: 80170bc2
0019 0286
Mar 31 18:55:43 Newcastle kernel:000a
80d2000a 0286 0256
Mar 31 18:55:43 Newcastle kernel:80478bc0
Mar 31 18:55:43 Newcastle kernel: Call
Trace:{buffered_rmqueue+1154}
{__alloc_pages+220}
Mar 31 18:55:43 Newcastle kernel:
{do_no_page+370} {handle_mm_fault+560}
Mar 31 18:55:43 Newcastle kernel:
{write_chan+860} {do_page_fault+1044}
Mar 31 18:55:43 Newcastle kernel:
{thread_return+41} {error_exit+0}
Mar 31 18:55:43 Newcastle kernel:
Mar 31 18:55:43 Newcastle kernel:
Mar 31 18:55:43 Newcastle kernel: Code: f3 48 ab c3 66 66 66 90 66 66 66
90 66 66 66 90 66 66 66 90
Mar 31 18:55:43 Newcastle kernel: RIP {clear_page+7}
RSP
Mar 31 18:55:43 Newcastle kernel: CR2: 8100588f5000
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.12-rc1-mm5 1/3] perfctr: ppc64 arch hooks
David Gibson <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote: > > Mikael Pettersson <[EMAIL PROTECTED]> wrote: > > > > > > Here's a 3-part patch kit which adds a ppc64 driver to perfctr, > > > written by David Gibson <[EMAIL PROTECTED]>. > > > > Well that seems like progress. Where do we feel that we stand wrt > > preparedness for merging all this up? > > I'm still uneasy about it. There were sufficient changes made getting > this one ready to go that I'm not confident there aren't more > important things to be found. That's a bit open-ended. How do we determine whether more things will be needed? How do we know when we're done? - 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/
cn_queue.c
> /*
> *cn_queue.c
> *
> * 2004 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
> * All rights reserved.
> *
> * 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, write to the Free Software
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> *
> */
It's conventinal to add at the start of the file a description of what it
all does.
> static void cn_queue_wrapper(void *data)
> {
> struct cn_callback_entry *cbq = (struct cn_callback_entry *)data;
>
> smp_mb__before_atomic_inc();
> atomic_inc(>cb->refcnt);
> smp_mb__after_atomic_inc();
> cbq->cb->callback(cbq->cb->priv);
> smp_mb__before_atomic_inc();
> atomic_dec(>cb->refcnt);
> smp_mb__after_atomic_inc();
>
> cbq->destruct_data(cbq->ddata);
> }
What on earth are all these barriers for? Barriers should have an
associated comment describing why they were added, and what they are
defending against, becuase it is very hard to tell that from reading the
code.
Please describe (via code comments) what the refcounting rules are for
these data structures. It all looks very strange. You basically have:
atomic_inc(refcnt);
use(some_object);
atomic_dec(refcnt);
Which looks very racy. Some other CPU could see a zero refcount just
before this CPU did the atomic_inc() and the other CPU will go and free up
some_object. There should be locking associated with refcounting to
prevent such races, and I don't see any.
> static struct cn_callback_entry *cn_queue_alloc_callback_entry(struct
> cn_callback *cb)
80 cols again.
> static void cn_queue_free_callback(struct cn_callback_entry *cbq)
> {
> cancel_delayed_work(>work);
>
> while (atomic_read(>cb->refcnt)) {
> printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n",
> cbq->pdev->name, atomic_read(>cb->refcnt));
>
> msleep_interruptible(1000);
>
> if (current->flags & PF_FREEZE)
> refrigerator(PF_FREEZE);
>
> if (signal_pending(current))
> flush_signals(current);
> }
>
> kfree(cbq);
> }
erp. Can you please do this properly?
Free the object on the refcount going to zero (with appropriate locking)?
If you want (for some reason) to wait until all users of an object have
gone away then you should take a ref on the object (inside locking), then
sleep on a waitqueue_head embedded in that object. Make all
refcount-droppers do a wake_up.
Why is this function playing with signals?
> int cn_cb_equal(struct cb_id *i1, struct cb_id *i2)
> {
> #if 0
> printk(KERN_INFO "%s: comparing %04x.%04x and %04x.%04x\n",
> __func__,
> i1->idx, i1->val,
> i2->idx, i2->val);
> #endif
> return ((i1->idx == i2->idx) && (i1->val == i2->val));
> }
Please review all functions, check that they really need kernel-wide scope.
Please comment all functions.
> int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb)
> {
> struct cn_callback_entry *cbq, *n, *__cbq;
> int found = 0;
>
> cbq = cn_queue_alloc_callback_entry(cb);
> if (!cbq)
> return -ENOMEM;
>
> atomic_inc(>refcnt);
> smp_mb__after_atomic_inc();
> cbq->pdev = dev;
>
> spin_lock_bh(>queue_lock);
> list_for_each_entry_safe(__cbq, n, >queue_list, callback_entry) {
> if (cn_cb_equal(&__cbq->cb->id, >id)) {
> found = 1;
> break;
> }
> }
> if (!found) {
> atomic_set(>cb->refcnt, 1);
> list_add_tail(>callback_entry, >queue_list);
> }
> spin_unlock_bh(>queue_lock);
Why use spin_lock_bh()? Does none of this code ever get called from IRQ
context?
> if (found) {
> smp_mb__before_atomic_inc();
> atomic_dec(>refcnt);
> smp_mb__after_atomic_inc();
> atomic_set(>cb->refcnt, 0);
> cn_queue_free_callback(cbq);
> return -EINVAL;
> }
More strange barriers. This practice seems to be unique to this part of the
kernel. That's probably a bad sign.
> struct cn_queue_dev *cn_queue_alloc_dev(char *name, struct sock *nls)
> {
> struct cn_queue_dev *dev;
>
>
connector.h
>
> struct cb_id
> {
> __u32 idx;
> __u32 val;
> };
It is vital that all data structures be skilfully commented - they are the
key to understanding the code. Why the struct exists, which actor passes
it to which other actor(s), whether the data structure is communicated with
userspace, what other data structures it is aggregated with or linked to,
locking rules, etc.
> struct cn_msg
> {
Please do
struct cn_msg {
>
> #define CN_CBQ_NAMELEN32
Commentary?
-
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/
connector.c
Some belated comments...
>
> module_param(unit, int, 0);
> module_param(cn_idx, uint, 0);
> module_param(cn_val, uint, 0);
MODULE_PARM_DESC needed, please.
> static DEFINE_SPINLOCK(notify_lock);
> static LIST_HEAD(notify_list);
>
> static struct cn_dev cdev;
>
> int cn_already_initialized = 0;
>
> /*
> * msg->seq and msg->ack are used to determine message genealogy.
> * When someone sends message it puts there locally unique sequence
> * and random acknowledge numbers.
> * Sequence number may be copied into nlmsghdr->nlmsg_seq too.
> *
> * Sequence number is incremented with each message to be sent.
> *
> * If we expect reply to our message,
> * then sequence number in received message MUST be the same as in original
> message,
> * and acknowledge number MUST be the same + 1.
> *
> * If we receive message and it's sequence number is not equal to one we are
> expecting,
> * then it is new message.
> * If we receive message and it's sequence number is the same as one we are
> expecting,
> * but it's acknowledge is not equal acknowledge number in original message +
> 1,
> * then it is new message.
> *
> */
This comment looks crappy in an 80-col xterm.
What happens if we expect a reply to our message but userspace never sends
one? Does the kernel leak memory? Do other processes hang?
> void cn_netlink_send(struct cn_msg *msg, u32 __groups)
> {
> struct cn_callback_entry *n, *__cbq;
> unsigned int size;
> struct sk_buff *skb, *uskb;
> struct nlmsghdr *nlh;
> struct cn_msg *data;
> struct cn_dev *dev =
> u32 groups = 0;
> int found = 0;
>
> if (!__groups)
> {
Wrong indenting.
> spin_lock_bh(>cbdev->queue_lock);
> list_for_each_entry_safe(__cbq, n, >cbdev->queue_list,
> callback_entry) {
> if (cn_cb_equal(&__cbq->cb->id, >id)) {
> found = 1;
> groups = __cbq->group;
> }
> }
> spin_unlock_bh(>cbdev->queue_lock);
>
> if (!found) {
> printk(KERN_ERR "Failed to find multicast netlink group
> for callback[0x%x.0x%x]. seq=%u\n",
> msg->id.idx, msg->id.val, msg->seq);
Needs wrapping.
> return;
> }
> }
> else
> groups = __groups;
>
> size = NLMSG_SPACE(sizeof(*msg) + msg->len);
>
> skb = alloc_skb(size, GFP_ATOMIC);
GFP_ATOMIC is quite unreliable. Better to find a way to use GFP_KERNEL here.
> if (!skb) {
> printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
> size);
> return;
> }
Surely we should return -ENOMEM here? How is the caller to know that the
send attempt worked?
> nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh));
>
> data = (struct cn_msg *)NLMSG_DATA(nlh);
Unneeded typecast.
> memcpy(data, msg, sizeof(*data) + msg->len);
> #if 0
> printk("%s: len=%u, seq=%u, ack=%u, group=%u.\n",
> __func__, msg->len, msg->seq, msg->ack, groups);
> #endif
>
> NETLINK_CB(skb).dst_groups = groups;
>
> uskb = skb_clone(skb, GFP_ATOMIC);
> if (uskb) {
> netlink_unicast(dev->nls, uskb, 0, 0);
> }
Unneeded {}
> netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
GFP_ATOMIC is quite undesirable.
>
> static int cn_call_callback(struct cn_msg *msg, void (*destruct_data) (void
> *), void *data)
80 cols
> {
> struct cn_callback_entry *n, *__cbq;
> struct cn_dev *dev =
> int found = 0;
>
> spin_lock_bh(>cbdev->queue_lock);
> list_for_each_entry_safe(__cbq, n, >cbdev->queue_list,
> callback_entry) {
80 cols
> if (cn_cb_equal(&__cbq->cb->id, >id)) {
> __cbq->cb->priv = msg;
>
> __cbq->ddata = data;
> __cbq->destruct_data = destruct_data;
>
> queue_work(dev->cbdev->cn_queue, &__cbq->work);
> found = 1;
> break;
> }
> }
> spin_unlock_bh(>cbdev->queue_lock);
>
> return found;
> }
Why is spin_lock_bh() being used here?
> static int __cn_rx_skb(struct sk_buff *skb, struct nlmsghdr *nlh)
> {
> u32 pid, uid, seq, group;
> struct cn_msg *msg;
>
> pid = NETLINK_CREDS(skb)->pid;
> uid = NETLINK_CREDS(skb)->uid;
> seq = nlh->nlmsg_seq;
> group = NETLINK_CB((skb)).groups;
> msg = (struct cn_msg *)NLMSG_DATA(nlh);
>
> if (NLMSG_SPACE(msg->len + sizeof(*msg)) != nlh->nlmsg_len) {
> printk(KERN_ERR "skb does not have enough length: "
> "requested msg->len=%u[%u], nlh->nlmsg_len=%u,
> skb->len=%u.\n",
80 cols (all over the place)
> static void cn_notify(struct cb_id
Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O
to den 31.03.2005 Klokka 16:13 (-0800) skreiv Andrew Morton: > Trond Myklebust <[EMAIL PROTECTED]> wrote: > > > > on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust: > > > > Or have I misunderstood the intent? Some /* comments */ would be > > appropriate.. > > > > > > Will do. > > > > OK. Plenty of comments added that will hopefully clarify what is going > > on and how to use the API. Also some cleanups of the code. > > Ah, so that's what it does ;) > > I guess once we have a caller in-tree we could merge this. I wonder if > there's other existing code which should be converted to iosems. I can put it into the NFS client stream which feeds into the -mm kernel. That will enable me to queue up the NFSv4 patches that depend on it too... > You chose to not use the aio kernel threads? I thought I'd do that in a separate patch since the aio workqueue is currently statically defined in aio.c. > Does iosem_lock_and_schedule_function() need locking? It nonatomically > alters *lk_state. iosem_lock_and_schedule_function() will always be called with the iosem->wait.lock held, since it is a waitqueue notification function. In practice it is called by iosem_unlock(). The call to wake_up_locked() will trigger a call to __wake_up_common() which again tries the notification function of each waiter on the queue until it finds one that succeeds. Cheers, Trond -- Trond Myklebust <[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/
$B
$B!{!,!,!#(B $B(,(,(,(,(,(,(,(,(,(,!{(B $B(,(,(,(,(,!{(,(,(,(,(,(,(,(,(,(B
$B!,!!#o!!!#!!(B $B#o!!(B
$B!!(B $B(B $B#o!,!E!D(,!!=P!!2q!!$$!!(BPC$B!!(B
$B(,!D!E!!(B
$B!!(B $B!{#o!,#o(B $B(B
$B(,(,(,!!!{!!#o!!(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!!!{!!(B
$B!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(B
$B(B $BK\5$$G0)$($k!!$*4+$a%5%$%H(B
$B(#(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!($(B
$B"!B~:#%]%$%s%HBgI}%5!<%S%9Cf"!(B
$B!!(B
$B!XK\5$!Y$G%d%j$?$$$J$i!"$^$:$O$46a=j8!:w$G$3$A$i$+$i(B
$B!!"-!!"-!!"-!!"-!!"-!!"-!!"-!!"-!!"-!!"-!!"-(B
$B!!(Bhttp://com.deai-pc.com/?num=5001
$B!|%5%$%HFb=q$-9~$_>R2p(B
$B!&$f$-!'(B22$B:P!!!XNx?MJg=8!Y(B
$B:#F|$_$?$$$JF|$OBg9%$-$J?M$H0l=o$K$$$?$$$J$!!y$:$C$H(B
$B$/[EMAIL PROTECTED]"v$=$s$J$U$&$K$7$F$/$l$k?M(B
$BC5$7$F$k%h!*%i%V$b$7$?$$$J$!!A!y(B
$B!&??F`H~!'(B20$B:P!!!XM7$SAjhttp://com.deai-pc.com/index.php?num=601
$B".".".".".".".".".".".".".".".".".".".".".".".".".".".".".".".".".(B
$B%5%$%HFb$N$d$jpJs$r$*http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07
Hi Ingo, I was wondering if the issue the bit_spin_lock has gone into the side burner? I understand that this is a major problem to change it, if you want to get into the mainline kernel. But I still believe it to be a problem. With kjournald spinning on a bit lock until it finishes it's quota, can be bad for latencies. Although it only deadlocks on your system if it was a real-time task, it still has the ability to become one. Since it can hold two different locks at the time of the spin, if a rt-task tries to grab it, with priority inheritance it becomes rt, and if that just happened to be the highest priority task on the system, you just created a deadlock. It's not so much of an issue with me, since I'm working with a parallel kernel, and have implemented my earlier fixes to it. I just wanted to know if there's any plan to deal with them on your end. I do see this causing a random lockup once in a while, and wanted the user to beware. Of course if you just avoid ext3, you wont have a problem. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.12-rc1-mm5 1/3] perfctr: ppc64 arch hooks
On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote: > Mikael Pettersson <[EMAIL PROTECTED]> wrote: > > > > Here's a 3-part patch kit which adds a ppc64 driver to perfctr, > > written by David Gibson <[EMAIL PROTECTED]>. > > Well that seems like progress. Where do we feel that we stand wrt > preparedness for merging all this up? I'm still uneasy about it. There were sufficient changes made getting this one ready to go that I'm not confident there aren't more important things to be found. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/people/dgibson - 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: noresume breaks next suspend [was Re: 2.6.12-rc1 swsusp broken]
Hi. On Fri, 2005-04-01 at 08:25, Pavel Machek wrote: > Hi! > > > > Yes! With this it works ok. > > > > > > > Also, could you please try sticking psmouse_reset(psmouse) call at the > > > > beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if > > > > it can suspend _without_ the patch above. > > > > > > > Both patches are working for me (Dell D600). before i was unable to > > suspend to disk on this laptop (it was stuck in alps code). > > > > By the way, i have an unrelated problem: > > if the kernel was booted with the "noresume" option, it cannot be > > suspended, it fails with: > > > > swsusp: FATAL: cannot find swap device, try swapon -a! > > Uh, okay, logic error, probably introduced by resume-from-initrd > patch. Does this fix it? > > OTOH, perhaps refusing suspend is right thing to do. If user is > running in "safe mode" (with noresume), we don't want him to be able > to suspend... What? If you suspend, then decide not to resume, you can suspend again until after your next reboot?! Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://suspend2.net - 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/
double April fools (Fw: Linux kernel 2.7.0 released)
As vger co-postmaster I see some interesting stuff sometimes. Sadly, this guy not only choose a lame april fools posting, he couldn't even post it to the correct email address. (he sent it to *-owner@ which goes effectively to me) So here it is in it's full glory :-) Begin forwarded message: Date: Fri, 01 Apr 2005 01:03:50 +0200 From: Hal9000 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Linux kernel 2.7.0 released Linux kernel version 2.7.0 has been released. It is available from: Patch: ftp://ftp.kernel.org/pub/linux/kernel/v2.7/patch-2.7.0.bz2 Full source:ftp://ftp.kernel.org/pub/linux/kernel/v2.7/linux-2.7.0.tar.bz2 Sizes in bytes Compressed Uncompressed Patch 895 3666 Full source 50508495 608465132 - This is an automatically generated message. To unsubscribe from this list, please send a message to [EMAIL PROTECTED] containing the line: unsubscribe linux-kernel-announce ... where is the email address you are receiving this message at. - The following files were changed in this release: * (pretty much everything, as usual...) - Finally the kernel tree has been forked. The 2.6 tree will now concentrate on stabilization and security issues only, while all the crazy und uncontrolled development experimental shit will continue on the 2.7.x.y(.z?) kernel tree. It was about time! oh yeah... too bad this is just an april fool :( - 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] I2C: Fix broken force parameter handling
ChangeSet 1.2348, 2005/03/31 14:32:17-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Fix broken force parameter handling
I just noticed a nasty bug in the way the "force" parameter is handled
for non-sensors i2c chip drivers. The "force" parameter supposedy is a
list of adapter, address *pairs* where supported chips are
unquestionably assumed to be. However, after handling one pair, the i2c
core code searches for the next one *three* values later, not two. So
with the current code, the second and third pairs wouldn't be properly
handled. The fourth one would be, and so on.
As a side note, this questions the need of an array parameter handling
up to 24 of such pairs, when obviously nobody ever required more than
one for the past 6 years.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/i2c-core.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Nru a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
--- a/drivers/i2c/i2c-core.c2005-03-31 15:16:10 -08:00
+++ b/drivers/i2c/i2c-core.c2005-03-31 15:16:10 -08:00
@@ -715,7 +715,7 @@
at all */
found = 0;
- for (i = 0; !found && (address_data->force[i] !=
I2C_CLIENT_END); i += 3) {
+ for (i = 0; !found && (address_data->force[i] !=
I2C_CLIENT_END); i += 2) {
if (((adap_id == address_data->force[i]) ||
(address_data->force[i] == ANY_I2C_BUS)) &&
(addr == address_data->force[i+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] I2C: Fix indentation of lm87 driver
ChangeSet 1.2349, 2005/03/31 14:32:36-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Fix indentation of lm87 driver
This trivial patch fixes indentation in the lm87 driver. I need this
'cause I'll soon post patches affecting these portions of code, and I'd
like these patches to be easily readable.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/lm87.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff -Nru a/drivers/i2c/chips/lm87.c b/drivers/i2c/chips/lm87.c
--- a/drivers/i2c/chips/lm87.c 2005-03-31 15:16:03 -08:00
+++ b/drivers/i2c/chips/lm87.c 2005-03-31 15:16:03 -08:00
@@ -317,20 +317,20 @@
static void set_temp_low(struct device *dev, const char *buf, int nr)
{
-struct i2c_client *client = to_i2c_client(dev);
-struct lm87_data *data = i2c_get_clientdata(client);
-long val = simple_strtol(buf, NULL, 10);
-data->temp_low[nr] = TEMP_TO_REG(val);
-lm87_write_value(client, LM87_REG_TEMP_LOW[nr], data->temp_low[nr]);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct lm87_data *data = i2c_get_clientdata(client);
+ long val = simple_strtol(buf, NULL, 10);
+ data->temp_low[nr] = TEMP_TO_REG(val);
+ lm87_write_value(client, LM87_REG_TEMP_LOW[nr], data->temp_low[nr]);
}
static void set_temp_high(struct device *dev, const char *buf, int nr)
{
-struct i2c_client *client = to_i2c_client(dev);
-struct lm87_data *data = i2c_get_clientdata(client);
-long val = simple_strtol(buf, NULL, 10);
-data->temp_high[nr] = TEMP_TO_REG(val);
-lm87_write_value(client, LM87_REG_TEMP_HIGH[nr], data->temp_high[nr]);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct lm87_data *data = i2c_get_clientdata(client);
+ long val = simple_strtol(buf, NULL, 10);
+ data->temp_high[nr] = TEMP_TO_REG(val);
+ lm87_write_value(client, LM87_REG_TEMP_HIGH[nr], data->temp_high[nr]);
}
#define set_temp(offset) \
-
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: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> I'm pleased to annouce CBUS - ultra fast (for insert operations)
> message bus.
> +static int cbus_enqueue(struct cbus_event_container *c, struct cn_msg *msg)
> +{
> + int err;
> + struct cbus_event *event;
> + unsigned long flags;
> +
> + event = kmalloc(sizeof(*event) + msg->len, GFP_ATOMIC);
Using GFP_ATOMIC is a bit lame. It would be better to require the caller
to pass in the gfp_flags. Or simply require that all callers not hold
locks and use GFP_KERNEL.
> +static int cbus_process(struct cbus_event_container *c, int all)
> +{
> + struct cbus_event *event;
> + int len, i, num;
> +
> + if (list_empty(>event_list))
> + return 0;
> +
> + if (all)
> + len = c->qlen;
> + else
> + len = 1;
> +
> + num = 0;
> + for (i=0; i + event = cbus_dequeue(c);
> + if (!event)
> + continue;
> +
> + cn_netlink_send(>msg, 0);
> + num++;
> +
> + kfree(event);
> + }
> +
> + return num;
> +}
It might be cleaner to pass in an item count rather than a boolean `all'
here. Then again, it seems racy.
The initial list_empty() call could fail to detect new events due to lack
of locking and memory barriers.
We conventionally code for loops as
for (i = 0; i < len; i++)
> +static int cbus_event_thread(void *data)
> +{
> + int i, non_empty = 0, empty = 0;
> + struct cbus_event_container *c;
> +
> + daemonize(cbus_name);
> + allow_signal(SIGTERM);
> + set_user_nice(current, 19);
Please use the kthread api for managing this thread.
Is a new kernel thread needed?
> + while (!cbus_need_exit) {
> + if (empty || non_empty == 0 || non_empty > 10) {
> + interruptible_sleep_on_timeout(_wait_queue, 10);
interruptible_sleep_on_timeout() is heavily deprecated and is racy without
external locking (it pretty much has to be the BKL). Use wait_event_timeout().
> +int __devinit cbus_init(void)
> +{
> + int i, err = 0;
> + struct cbus_event_container *c;
> +
> + for_each_cpu(i) {
> + c = _cpu(cbus_event_list, i);
> + cbus_init_event_container(c);
> + }
> +
> + init_completion(_thread_exited);
> +
> + cbus_pid = kernel_thread(cbus_event_thread, NULL, CLONE_FS |
> CLONE_FILES);
Using the kthread API would clean this up.
> + if (IS_ERR((void *)cbus_pid)) {
The weird cast here might not even work at all on 64-bit architectures. It
depends if they sign extend ints when casting them to pointers. I guess
they do. If cbus_pid is indeed an s32.
Much better to do
if (cbus_pid < 0)
> +void __devexit cbus_fini(void)
> +{
> + int i;
> + struct cbus_event_container *c;
> +
> + cbus_need_exit = 1;
> + kill_proc(cbus_pid, SIGTERM, 0);
> + wait_for_completion(_thread_exited);
> +
> + for_each_cpu(i) {
> + c = _cpu(cbus_event_list, i);
> + cbus_fini_event_container(c);
> + }
> +}
I think this is racy. What stops new events from being queued while this
function is in progress?
-
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] I2C: Fix breakage in m41t00 i2c rtc driver
ChangeSet 1.2334, 2005/03/31 14:09:00-08:00, [EMAIL PROTECTED] [PATCH] I2C: Fix breakage in m41t00 i2c rtc driver Remove setting of deleted i2c_client structure member. The latest include/linux/i2c.h:i2c_client structure no longer has an 'id' member. This patch removes the setting of that no longer existing member. Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> drivers/i2c/chips/m41t00.c |1 - 1 files changed, 1 deletion(-) diff -Nru a/drivers/i2c/chips/m41t00.c b/drivers/i2c/chips/m41t00.c --- a/drivers/i2c/chips/m41t00.c2005-03-31 15:17:53 -08:00 +++ b/drivers/i2c/chips/m41t00.c2005-03-31 15:17:53 -08:00 @@ -184,7 +184,6 @@ memset(client, 0, sizeof(struct i2c_client)); strncpy(client->name, M41T00_DRV_NAME, I2C_NAME_SIZE); - client->id = m41t00_driver.id; client->flags = I2C_DF_NOTIFY; client->addr = addr; client->adapter = adap; - 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] i2c/i2c-elektor: remove interruptible_sleep_on_timeout() usage
ChangeSet 1.2323, 2005/03/31 14:05:31-08:00, [EMAIL PROTECTED]
[PATCH] i2c/i2c-elektor: remove interruptible_sleep_on_timeout() usage
Replace deprecated interruptible_sleep_on_timeout() with direct
wait-queue usage. Patch is compile-tested.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/busses/i2c-elektor.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff -Nru a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
--- a/drivers/i2c/busses/i2c-elektor.c 2005-03-31 15:19:14 -08:00
+++ b/drivers/i2c/busses/i2c-elektor.c 2005-03-31 15:19:14 -08:00
@@ -110,7 +110,7 @@
}
static void pcf_isa_waitforpin(void) {
-
+ DEFINE_WAIT(wait);
int timeout = 2;
long flags;
@@ -118,14 +118,15 @@
spin_lock_irqsave(, flags);
if (pcf_pending == 0) {
spin_unlock_irqrestore(, flags);
- if (interruptible_sleep_on_timeout(_wait,
- timeout*HZ)) {
+ prepare_to_wait(_wait, , TASK_INTERRUPTIBLE);
+ if (schedule_timeout(timeout*HZ)) {
spin_lock_irqsave(, flags);
if (pcf_pending == 1) {
pcf_pending = 0;
}
spin_unlock_irqrestore(, flags);
}
+ finish_wait(_wait, );
} else {
pcf_pending = 0;
spin_unlock_irqrestore(, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: busses documentation update 1 of 2
ChangeSet 1.2340, 2005/03/31 14:29:46-08:00, [EMAIL PROTECTED] [PATCH] I2C: busses documentation update 1 of 2 This patch just moves i2c-parport file to busses directory. Patch for other busses documentation will follow. Signed-off-by: Rudolf Marek <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> Documentation/i2c/i2c-parport| 156 --- Documentation/i2c/busses/i2c-parport | 156 +++ 2 files changed, 156 insertions(+), 156 deletions(-) diff -Nru a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/i2c/busses/i2c-parport 2005-03-31 15:17:11 -08:00 @@ -0,0 +1,156 @@ +== +i2c-parport driver +== + +2004-07-06, Jean Delvare + +This is a unified driver for several i2c-over-parallel-port adapters, +such as the ones made by Philips, Velleman or ELV. This driver is +meant as a replacement for the older, individual drivers: + * i2c-philips-par + * i2c-elv + * i2c-velleman + * video/i2c-parport (NOT the same as this one, dedicated to home brew + teletext adapters) + +It currently supports the following devices: + * Philips adapter + * home brew teletext adapter + * Velleman K8000 adapter + * ELV adapter + * Analog Devices evaluation boards (ADM1025, ADM1030, ADM1031, ADM1032) + +These devices use different pinout configurations, so you have to tell +the driver what you have, using the type module parameter. There is no +way to autodetect the devices. Support for different pinout configurations +can be easily added when needed. + + +Building your own adapter +- + +If you want to build you own i2c-over-parallel-port adapter, here is +a sample electronics schema (credits go to Sylvain Munaut): + +Device PC +Side ___Vdd (+)Side + || | + --- --- --- + | | | | | | + |R| |R| |R| + | | | | | | + --- --- --- + || | + ||/| | +SCL --xo |---x--- pin 2 +|\| | | +| | | +| |\| | +SDA --xx---| o---x--- pin 13 + ||/| + | | + | /| | + -o |x-- pin 3 + \| || + || + --- --- + | | | | + |R| |R| + | | | | + --- --- + || + ### ### + GND GND + +Remarks: + - This is the exact pinout and electronics used on the Analog Devices + evaluation boards. + /| + - All inverters -o |- must be 74HC05, they must be open collector output. + \| + - All resitors are 10k. + - Pins 18-25 of the parallel port connected to GND. + - Pins 4-9 (D2-D7) could be used as VDD is the driver drives them high. + The ADM1032 evaluation board uses D4-D7. Beware that the amount of + current you can draw from the parallel port is limited. Also note that + all connected lines MUST BE driven at the same state, else you'll short + circuit the output buffers! So plugging the I2C adapter after loading + the i2c-parport module might be a good safety since data line state + prior to init may be unknown. + - This is 5V! + - Obviously you cannot read SCL (so it's not really standard-compliant). + Pretty easy to add, just copy the SDA part and use another input pin. + That would give (ELV compatible pinout): + + +Device PC +Side __Vdd (+) Side + |||| + --- --- --- --- + | | | | | | | | + |R| |R| |R| |R| + | | | | | | | | + --- --- --- --- + |||| + || |\|| +SCL --xx--| o---x pin 15 +| | |/ | +| | | +| | /|| +| ---o |-x-- pin 2 +| \||| +
[PATCH] i2c: add adt7461 chip support to lm90 driver
ChangeSet 1.2332, 2005/03/31 14:08:21-08:00, [EMAIL PROTECTED]
[PATCH] i2c: add adt7461 chip support to lm90 driver
i2c: add adt7461 chip support
The Analog Devices ADT7461 temperature sensor chip is compatible with
the lm90 device provided its extended temperature range is not
enabled. The chip will be ignored if the boot firmware enables
extended temperature range.
Also, since the adt7461 treats temp values <0 as 0 and >127 as 127,
the driver prevents temperature values outside the supported range
from being set.
Signed-off-by: James Chapman <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/lm90.c | 44 +---
1 files changed, 41 insertions(+), 3 deletions(-)
diff -Nru a/drivers/i2c/chips/lm90.c b/drivers/i2c/chips/lm90.c
--- a/drivers/i2c/chips/lm90.c 2005-03-31 15:18:08 -08:00
+++ b/drivers/i2c/chips/lm90.c 2005-03-31 15:18:08 -08:00
@@ -43,6 +43,14 @@
* variants. The extra address and features of the MAX6659 are not
* supported by this driver.
*
+ * This driver also supports the ADT7461 chip from Analog Devices but
+ * only in its "compatability mode". If an ADT7461 chip is found but
+ * is configured in non-compatible mode (where its temperature
+ * register values are decoded differently) it is ignored by this
+ * driver. Complete datasheet can be obtained from Analog's website
+ * at:
+ * http://products.analog.com/products/info.asp?product=ADT7461
+ *
* Since the LM90 was the first chipset supported by this driver, most
* comments will refer to this chipset, but are actually general and
* concern all supported chipsets, unless mentioned otherwise.
@@ -77,6 +85,7 @@
* LM86, LM89, LM90, LM99, ADM1032, MAX6657 and MAX6658 have address 0x4c.
* LM89-1, and LM99-1 have address 0x4d.
* MAX6659 can have address 0x4c, 0x4d or 0x4e (unsupported).
+ * ADT7461 always has address 0x4c.
*/
static unsigned short normal_i2c[] = { 0x4c, 0x4d, I2C_CLIENT_END };
@@ -86,7 +95,7 @@
* Insmod parameters
*/
-SENSORS_INSMOD_5(lm90, adm1032, lm99, lm86, max6657);
+SENSORS_INSMOD_6(lm90, adm1032, lm99, lm86, max6657, adt7461);
/*
* The LM90 registers
@@ -148,6 +157,19 @@
#define HYST_TO_REG(val) ((val) <= 0 ? 0 : (val) >= 30500 ? 31 : \
((val) + 500) / 1000)
+/*
+ * ADT7461 is almost identical to LM90 except that attempts to write
+ * values that are outside the range 0 < temp < 127 are treated as
+ * the boundary value.
+ */
+
+#define TEMP1_TO_REG_ADT7461(val) ((val) <= 0 ? 0 : \
+(val) >= 127000 ? 127 : \
+((val) + 500) / 1000)
+#define TEMP2_TO_REG_ADT7461(val) ((val) <= 0 ? 0 : \
+(val) >= 127750 ? 0x7FC0 : \
+((val) + 125) / 250 * 64)
+
/*
* Functions declaration
*/
@@ -181,6 +203,7 @@
struct semaphore update_lock;
char valid; /* zero until following fields are valid */
unsigned long last_updated; /* in jiffies */
+ int kind;
/* registers values */
s8 temp_input1, temp_low1, temp_high1; /* local */
@@ -216,7 +239,10 @@
struct i2c_client *client = to_i2c_client(dev); \
struct lm90_data *data = i2c_get_clientdata(client); \
long val = simple_strtol(buf, NULL, 10); \
- data->value = TEMP1_TO_REG(val); \
+ if (data->kind == adt7461) \
+ data->value = TEMP1_TO_REG_ADT7461(val); \
+ else \
+ data->value = TEMP1_TO_REG(val); \
i2c_smbus_write_byte_data(client, reg, data->value); \
return count; \
}
@@ -227,7 +253,10 @@
struct i2c_client *client = to_i2c_client(dev); \
struct lm90_data *data = i2c_get_clientdata(client); \
long val = simple_strtol(buf, NULL, 10); \
- data->value = TEMP2_TO_REG(val); \
+ if (data->kind == adt7461) \
+ data->value = TEMP2_TO_REG_ADT7461(val); \
+ else \
+ data->value = TEMP2_TO_REG(val); \
i2c_smbus_write_byte_data(client, regh, data->value >> 8); \
i2c_smbus_write_byte_data(client, regl, data->value & 0xff); \
return count; \
@@ -381,6 +410,12 @@
&& (reg_config1 & 0x3F) == 0x00
&& reg_convrate <= 0x0A) {
kind = adm1032;
+ } else
+ if (address == 0x4c
+&& chip_id == 0x51 /* ADT7461 */
+&& (reg_config1 & 0x1F) == 0x00 /* check compat mode */
+&& reg_convrate <= 0x0A) {
+ kind = adt7461;
}
} else
if (man_id == 0x4D) { /* Maxim */
@@ -418,11 +453,14 @@
name = "lm86";
} else if (kind == max6657) {
name = "max6657";
+ } else if (kind == adt7461) {
[PATCH] I2C: lsb in emc6d102 and adm1027
ChangeSet 1.2343, 2005/03/31 14:30:43-08:00, [EMAIL PROTECTED]
[PATCH] I2C: lsb in emc6d102 and adm1027
The attached patches add support for reading the lsb from the emc6d102
and change how they are read from the adm1027.
The lm85_update_device function decodes the LSBs to temp_ext and in_ext.
This strategy was suggested by Philip Pokorny.
The patch also changes some macros to use the SCALE macro. I think that
they become more readable this way.
Signed-off-by: Rafael Ávila de Espíndola <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/lm85.c | 100 ---
1 files changed, 77 insertions(+), 23 deletions(-)
diff -Nru a/drivers/i2c/chips/lm85.c b/drivers/i2c/chips/lm85.c
--- a/drivers/i2c/chips/lm85.c 2005-03-31 15:16:46 -08:00
+++ b/drivers/i2c/chips/lm85.c 2005-03-31 15:16:46 -08:00
@@ -37,7 +37,7 @@
static unsigned int normal_isa[] = { I2C_CLIENT_ISA_END };
/* Insmod parameters */
-SENSORS_INSMOD_5(lm85b, lm85c, adm1027, adt7463, emc6d100);
+SENSORS_INSMOD_6(lm85b, lm85c, adm1027, adt7463, emc6d100, emc6d102);
/* The LM85 registers */
@@ -77,6 +77,7 @@
#defineLM85_VERSTEP_ADT7463C 0x6A
#defineLM85_VERSTEP_EMC6D100_A00x60
#defineLM85_VERSTEP_EMC6D100_A10x61
+#defineLM85_VERSTEP_EMC6D102 0x65
#defineLM85_REG_CONFIG 0x40
@@ -113,9 +114,13 @@
#define EMC6D100_REG_ALARM3 0x7d
/* IN5, IN6 and IN7 */
-#define EMC6D100_REG_IN(nr) (0x70 + ((nr)-5))
-#define EMC6D100_REG_IN_MIN(nr) (0x73 + ((nr)-5) * 2)
-#define EMC6D100_REG_IN_MAX(nr) (0x74 + ((nr)-5) * 2)
+#defineEMC6D100_REG_IN(nr) (0x70 + ((nr)-5))
+#defineEMC6D100_REG_IN_MIN(nr) (0x73 + ((nr)-5) * 2)
+#defineEMC6D100_REG_IN_MAX(nr) (0x74 + ((nr)-5) * 2)
+#defineEMC6D102_REG_EXTEND_ADC10x85
+#defineEMC6D102_REG_EXTEND_ADC20x86
+#defineEMC6D102_REG_EXTEND_ADC30x87
+#defineEMC6D102_REG_EXTEND_ADC40x88
#defineLM85_ALARM_IN0 0x0001
#defineLM85_ALARM_IN1 0x0002
@@ -140,35 +145,36 @@
these macros are called: arguments may be evaluated more than once.
*/
-/* IN are scaled 1.000 == 0xc0, mag = 3 */
-#define IN_TO_REG(val) (SENSORS_LIMITval)*0xc0+500)/1000),0,255))
-#define INEXT_FROM_REG(val,ext) (((val)*1000 + (ext)*250 + 96)/0xc0)
-#define IN_FROM_REG(val) (INEXT_FROM_REG(val,0))
-
/* IN are scaled acording to built-in resistors */
static int lm85_scaling[] = { /* .001 Volts */
2500, 2250, 3300, 5000, 12000,
3300, 1500, 1800 /*EMC6D100*/
};
#define SCALE(val,from,to) (((val)*(to) + ((from)/2))/(from))
-#define INS_TO_REG(n,val)
(SENSORS_LIMIT(SCALE(val,lm85_scaling[n],192),0,255))
-#define INSEXT_FROM_REG(n,val,ext) (SCALE((val)*4 +
(ext),192*4,lm85_scaling[n]))
-#define INS_FROM_REG(n,val)(INSEXT_FROM_REG(n,val,0))
+
+#define INS_TO_REG(n,val) \
+ SENSORS_LIMIT(SCALE(val,lm85_scaling[n],192),0,255)
+
+#define INSEXT_FROM_REG(n,val,ext,scale) \
+ SCALE((val)*(scale) + (ext),192*(scale),lm85_scaling[n])
+
+#define INS_FROM_REG(n,val) INSEXT_FROM_REG(n,val,0,1)
/* FAN speed is measured using 90kHz clock */
#define FAN_TO_REG(val)(SENSORS_LIMIT( (val)<=0?0:
540/(val),0,65534))
#define FAN_FROM_REG(val) ((val)==0?-1:(val)==0x?0:540/(val))
/* Temperature is reported in .001 degC increments */
-#define TEMP_TO_REG(val)
(SENSORS_LIMIT(((val)+500)/1000,-127,127))
-#define TEMPEXT_FROM_REG(val,ext) ((val)*1000 + (ext)*250)
-#define TEMP_FROM_REG(val) (TEMPEXT_FROM_REG(val,0))
-#define EXTTEMP_TO_REG(val)(SENSORS_LIMIT((val)/250,-127,127))
+#define TEMP_TO_REG(val) \
+ SENSORS_LIMIT(SCALE(val,1000,1),-127,127)
+#define TEMPEXT_FROM_REG(val,ext,scale)\
+ SCALE((val)*scale + (ext),scale,1000)
+#define TEMP_FROM_REG(val) \
+ TEMPEXT_FROM_REG(val,0,1)
#define PWM_TO_REG(val)(SENSORS_LIMIT(val,0,255))
#define PWM_FROM_REG(val) (val)
-#define EXT_FROM_REG(val,sensor) (((val)>>(sensor * 2))&0x03)
/* ZONEs have the following parameters:
*Limit (low) temp, 1. degC
@@ -356,7 +362,9 @@
u8 pwm[3]; /* Register value */
u8 spinup_ctl; /* Register encoding, combined */
u8 tach_mode; /* Register encoding, combined */
- u16 extend_adc; /* Register value */
+ u8 temp_ext[3]; /* Decoded values */
+ u8 in_ext[8]; /* Decoded values */
+ u8 adc_scale; /* ADC Extended bits scaling factor */
u8 fan_ppr;
[PATCH] I2C: group Intel on I2C Hardware Bus support
ChangeSet 1.2330, 2005/03/31 14:07:43-08:00, [EMAIL PROTECTED] [PATCH] I2C: group Intel on I2C Hardware Bus support From an end-user perspective it is easy to miss the third Intel PIIX entry on the menuconfig "I2C Hardware Bus support" screen. Also the Intel 801 menu item does not mention ICH. This trivial patch groups three Intel entries together, adds ICH to menu item, and ICH5/ICH5R to the help section. Includes suggestions from Jean Delvare. Signed-off-by: Grant Coady <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> drivers/i2c/busses/Kconfig | 38 +++--- 1 files changed, 19 insertions(+), 19 deletions(-) diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig --- a/drivers/i2c/busses/Kconfig2005-03-31 15:18:22 -08:00 +++ b/drivers/i2c/busses/Kconfig2005-03-31 15:18:22 -08:00 @@ -108,7 +108,7 @@ will be called i2c-hydra. config I2C_I801 - tristate "Intel 801" + tristate "Intel 82801 (ICH)" depends on I2C && PCI && EXPERIMENTAL help If you say yes to this option, support will be included for the Intel @@ -119,7 +119,7 @@ 82801BA 82801CA/CAM 82801DB - 82801EB + 82801EB/ER (ICH5/ICH5R) 6300ESB ICH6 ICH7 @@ -143,6 +143,23 @@ This driver can also be built as a module. If so, the module will be called i2c-i810. +config I2C_PIIX4 + tristate "Intel PIIX4" + depends on I2C && PCI + help + If you say yes to this option, support will be included for the Intel + PIIX4 family of mainboard I2C interfaces. Specifically, the following + versions of the chipset are supported: + Intel PIIX4 + Intel 440MX + Serverworks OSB4 + Serverworks CSB5 + Serverworks CSB6 + SMSC Victory66 + + This driver can also be built as a module. If so, the module + will be called i2c-piix4. + config I2C_IBM_IIC tristate "IBM PPC 4xx on-chip I2C interface" depends on IBM_OCP && I2C @@ -284,23 +301,6 @@ This support is also available as a module. If so, the module will be called i2c-parport-light. - -config I2C_PIIX4 - tristate "Intel PIIX4" - depends on I2C && PCI && EXPERIMENTAL - help - If you say yes to this option, support will be included for the Intel - PIIX4 family of mainboard I2C interfaces. Specifically, the following - versions of the chipset are supported: - Intel PIIX4 - Intel 440MX - Serverworks OSB4 - Serverworks CSB5 - Serverworks CSB6 - SMSC Victory66 - - This driver can also be built as a module. If so, the module - will be called i2c-piix4. config I2C_PROSAVAGE tristate "S3/VIA (Pro)Savage" - 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] Add support for semaphore-like structure with support for asynchronous I/O
Trond Myklebust <[EMAIL PROTECTED]> wrote: > > on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust: > > > Or have I misunderstood the intent? Some /* comments */ would be > appropriate.. > > > > Will do. > > OK. Plenty of comments added that will hopefully clarify what is going > on and how to use the API. Also some cleanups of the code. Ah, so that's what it does ;) I guess once we have a caller in-tree we could merge this. I wonder if there's other existing code which should be converted to iosems. You chose to not use the aio kernel threads? Does iosem_lock_and_schedule_function() need locking? It nonatomically alters *lk_state. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Andrew Morton wrote: Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: This patch adds a fork connector in the do_fork() routine. ... The fork connector is used by the Enhanced Linux System Accounting project http://elsa.sourceforge.net Does it also meet all the in-kernel requirements for other accounting projects? If not, what else do those other projects need? Hi Andrew, As the discussion in this thread of the past few days showed, this patch intends to take care of process grouping, but not the accounting data collection. Besides my concern of possibility of data loss, this patch also provides CSA information to handle process grouping as it intends to do. I plan to run some testing to see percentage of data loss when system is under stress test, but improvement at CBUS as Evgeniy indicated should help! Please be advised that i still need an do_exit handling to save accounting data. But, it is a separate issue. Thanks, - jay - 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: Low file-system performance for 2.6.11 compared to 2.4.26
linux-os wrote: For those interested, some file-system tests and a test-tools are attached. I'll give it a run when I get a chance. Thanks. In the meantime, can you try with different io schedulers? Also, my .signature disappeared during the file-system tests. There were no errors and e2fsck thinks everything is fine! You seem to be constantly plagued by gremlins. I don't know whether to laugh or cry. - 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] I2C: Kill unused struct members in w83627hf driver
ChangeSet 1.2327, 2005/03/31 14:06:47-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Kill unused struct members in w83627hf driver
I just noticed that the pwmenable struct members in the w83627hf driver
are not used anywhere (and quite rightly so, as PWM cannot be disabled
in these chips as far as I know). Let's just get rid of them and save
some bytes of memory.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/w83627hf.c |5 -
1 files changed, 5 deletions(-)
diff -Nru a/drivers/i2c/chips/w83627hf.c b/drivers/i2c/chips/w83627hf.c
--- a/drivers/i2c/chips/w83627hf.c 2005-03-31 15:18:44 -08:00
+++ b/drivers/i2c/chips/w83627hf.c 2005-03-31 15:18:44 -08:00
@@ -304,7 +304,6 @@
u32 beep_mask; /* Register encoding, combined */
u8 beep_enable; /* Boolean */
u8 pwm[3]; /* Register value */
- u8 pwmenable[3];/* bool */
u16 sens[3];/* 782D/783S only.
1 = pentium diode; 2 = 3904 diode;
3000-5000 = thermistor beta.
@@ -1316,10 +1315,6 @@
if ((type == w83697hf) && (i == 2))
break;
}
-
- data->pwmenable[0] = 1;
- data->pwmenable[1] = 1;
- data->pwmenable[2] = 1;
if(init) {
/* Enable temp2 */
-
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] I2C: Cleanup adm1021 unused defines
ChangeSet 1.2325, 2005/03/31 14:06:09-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Cleanup adm1021 unused defines
While working on the adm1021 driver, I found that this driver has a
number of unused (and useless) defines we could get rid of.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/adm1021.c | 12
1 files changed, 12 deletions(-)
diff -Nru a/drivers/i2c/chips/adm1021.c b/drivers/i2c/chips/adm1021.c
--- a/drivers/i2c/chips/adm1021.c 2005-03-31 15:19:00 -08:00
+++ b/drivers/i2c/chips/adm1021.c 2005-03-31 15:19:00 -08:00
@@ -28,18 +28,6 @@
#include
-/* Registers */
-#define ADM1021_SYSCTL_TEMP1200
-#define ADM1021_SYSCTL_REMOTE_TEMP 1201
-#define ADM1021_SYSCTL_DIE_CODE1202
-#define ADM1021_SYSCTL_ALARMS 1203
-
-#define ADM1021_ALARM_TEMP_HIGH0x40
-#define ADM1021_ALARM_TEMP_LOW 0x20
-#define ADM1021_ALARM_RTEMP_HIGH 0x10
-#define ADM1021_ALARM_RTEMP_LOW0x08
-#define ADM1021_ALARM_RTEMP_NA 0x04
-
/* Addresses to scan */
static unsigned short normal_i2c[] = { 0x18, 0x19, 0x1a,
0x29, 0x2a, 0x2b,
-
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] i2c: add adt7461 chip support to lm90 driver's Kconfig entry
ChangeSet 1.2347, 2005/03/31 14:31:59-08:00, [EMAIL PROTECTED] [PATCH] i2c: add adt7461 chip support to lm90 driver's Kconfig entry Hi Greg, James, all, > > > Attached is another version of my adt7461 patch, for inclusion in > > > the 2.6 tree. Reviewed by Jean. > > May we have an additional patch to Kconfig for this one? Here it finally comes. This simple patch adds a mention to the ADT7461 chip in Kconfig, now that the lm90 driver supports it. Signed-off-by: Jean Delvare <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> drivers/i2c/chips/Kconfig |3 +++ 1 files changed, 3 insertions(+) diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig --- a/drivers/i2c/chips/Kconfig 2005-03-31 15:16:17 -08:00 +++ b/drivers/i2c/chips/Kconfig 2005-03-31 15:16:17 -08:00 @@ -233,6 +233,9 @@ LM86, LM89 and LM99, Analog Devices ADM1032 and Maxim MAX6657 and MAX6658 sensor chips. + The Analog Devices ADT7461 sensor chip is also supported, but only + if found in ADM1032 compatibility mode. + This driver can also be built as a module. If so, the module will be called lm90. - 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] I2C: Fix some i2c algorithm initialization
ChangeSet 1.2335, 2005/03/31 14:09:20-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Fix some i2c algorithm initialization
While searching for i2c_algorithm declarations missing their
.functionality member, I found three of them which were not properly
initialized. i2c-algo-ite and i2c_sibyte_algo do not use the C99
initialization syntax, and i2c-ibm_iic.c explicitely initializes NULL
members. Following patch puts some order in there.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/algos/i2c-algo-ite.c| 13 +
drivers/i2c/algos/i2c-algo-sibyte.c | 13 +
drivers/i2c/busses/i2c-ibm_iic.c|4
3 files changed, 10 insertions(+), 20 deletions(-)
diff -Nru a/drivers/i2c/algos/i2c-algo-ite.c b/drivers/i2c/algos/i2c-algo-ite.c
--- a/drivers/i2c/algos/i2c-algo-ite.c 2005-03-31 15:17:46 -08:00
+++ b/drivers/i2c/algos/i2c-algo-ite.c 2005-03-31 15:17:46 -08:00
@@ -713,14 +713,11 @@
/* -exported algorithm data: - */
static struct i2c_algorithm iic_algo = {
- "ITE IIC algorithm",
- I2C_ALGO_IIC,
- iic_xfer, /* master_xfer */
- NULL, /* smbus_xfer */
- NULL, /* slave_xmit */
- NULL, /* slave_recv */
- algo_control, /* ioctl*/
- iic_func, /* functionality*/
+ .name = "ITE IIC algorithm",
+ .id = I2C_ALGO_IIC,
+ .master_xfer= iic_xfer,
+ .algo_control = algo_control, /* ioctl */
+ .functionality = iic_func,
};
diff -Nru a/drivers/i2c/algos/i2c-algo-sibyte.c
b/drivers/i2c/algos/i2c-algo-sibyte.c
--- a/drivers/i2c/algos/i2c-algo-sibyte.c 2005-03-31 15:17:46 -08:00
+++ b/drivers/i2c/algos/i2c-algo-sibyte.c 2005-03-31 15:17:46 -08:00
@@ -136,14 +136,11 @@
/* -exported algorithm data: - */
static struct i2c_algorithm i2c_sibyte_algo = {
- "SiByte algorithm",
- I2C_ALGO_SIBYTE,
- NULL, /* master_xfer */
- smbus_xfer, /* smbus_xfer */
- NULL, /* slave_xmit */
- NULL, /* slave_recv */
- algo_control, /* ioctl*/
- bit_func, /* functionality*/
+ .name = "SiByte algorithm",
+ .id = I2C_ALGO_SIBYTE,
+ .smbus_xfer = smbus_xfer,
+ .algo_control = algo_control, /* ioctl */
+ .functionality = bit_func,
};
/*
diff -Nru a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
--- a/drivers/i2c/busses/i2c-ibm_iic.c 2005-03-31 15:17:46 -08:00
+++ b/drivers/i2c/busses/i2c-ibm_iic.c 2005-03-31 15:17:46 -08:00
@@ -630,10 +630,6 @@
.name = "IBM IIC algorithm",
.id = I2C_ALGO_OCP,
.master_xfer= iic_xfer,
- .smbus_xfer = NULL,
- .slave_send = NULL,
- .slave_recv = NULL,
- .algo_control = NULL,
.functionality = iic_func
};
-
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] i2c/i2c-ite: remove interruptible_sleep_on_timeout() usage
ChangeSet 1.2322, 2005/03/31 14:05:14-08:00, [EMAIL PROTECTED]
[PATCH] i2c/i2c-ite: remove interruptible_sleep_on_timeout() usage
Replace deprecated interruptible_sleep_on_timeout() with direct
wait-queue usage. Patch is compile-tested, sort of; the driver does not build in
vanilla kernel either, but I don't seem to add any warnings..
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/busses/i2c-ite.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff -Nru a/drivers/i2c/busses/i2c-ite.c b/drivers/i2c/busses/i2c-ite.c
--- a/drivers/i2c/busses/i2c-ite.c 2005-03-31 15:19:21 -08:00
+++ b/drivers/i2c/busses/i2c-ite.c 2005-03-31 15:19:21 -08:00
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,7 +108,7 @@
* IIC controller interrupts.
*/
static void iic_ite_waitforpin(void) {
-
+ DEFINE_WAIT(wait);
int timeout = 2;
long flags;
@@ -121,13 +122,15 @@
spin_lock_irqsave(, flags);
if (iic_pending == 0) {
spin_unlock_irqrestore(, flags);
- if (interruptible_sleep_on_timeout(_wait, timeout*HZ)) {
+ prepare_to_wait(_wait, , TASK_INTERRUPTIBLE);
+ if (schedule_timeout(timeout*HZ)) {
spin_lock_irqsave(, flags);
if (iic_pending == 1) {
iic_pending = 0;
}
spin_unlock_irqrestore(, flags);
}
+ finish_wait(_wait, );
} else {
iic_pending = 0;
spin_unlock_irqrestore(, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Low file-system performance for 2.6.11 compared to 2.4.26
At 02:34 AM 1/04/2005, linux-os wrote: For those interested, some file-system tests and a test-tools are attached. in high-performance-I/O-testing i perform regularly, i notice no slowdown in 2.6 compared to 2.4. looking at your test-tools, i would hardly call your workload anywhere near 'realistic' in terms of its I/O patterns. a few suggestions / constructive comments: (1) 100 processes each performing i/o in the pattern of write 8MB, fsync(), wait, read 8MB, wait, delete probably isn't realistic (2) you don't mention whether you're performing testing on ext2 or ext3 (3) you also don't mention what i/o scheduled is being used (4) your benchmark doesn't measure 'fairness' between processes (5) your benchmark sleeps for a random amount of time at various parts it is well known that in 2.4 kernels, processes can 'hog' the i/o channel - which may result in higher overall throughput but at the detriment of being 'fair' to the rest of the system. you should address point (4) above. can you modify your program to present the time-taken-per-process? if i'm a betting man, i'd say that 2.6 will be a lot more 'fair' compared to 2.4. default settings for 2.6 likely also means that there is a lot less data outstanding in the buffer-cache. 2.6's fsync() behavior is also quite different to that of 2.4. also note that if you're using a journalled filesystem, fsync() likely does different things ... you don't seed rand, so the random numbers out of rand() aren't actually random. it probably doesn't matter so much since we're only talking microseconds here (up to 0.511 msec) - but given 2.4 kernels will have HZ of 100 and 2.6 will have HZ of 1000, you're clearly going to get a different end result - perhaps with 2.6 resulting in a busy-wait from usleep(). cheers, lincoln. - 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] I2C: New lm92 chip driver
ChangeSet 1.2324, 2005/03/31 14:05:50-08:00, [EMAIL PROTECTED]
[PATCH] I2C: New lm92 chip driver
This is a new i2c chip driver named lm92. It supports the National
Semiconductor LM92 and Maxim MAX6635 chips. This time I did not port the
driver from the lm_sensors project but instead rewrote it. The reason is
that the original driver has a different structure from the other i2c
chip drivers, which would have made maintenance harder.
I don't have a compatible chip myself but could test my code thanks to
Mark Hoffman's i2c-stub fake bus driver. Later on, James Chapman tested
it on a real chip, successfully.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/Kconfig | 11 +
drivers/i2c/chips/Makefile |1
drivers/i2c/chips/lm92.c | 423 +
3 files changed, 435 insertions(+)
diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig 2005-03-31 15:19:07 -08:00
+++ b/drivers/i2c/chips/Kconfig 2005-03-31 15:19:07 -08:00
@@ -236,6 +236,17 @@
This driver can also be built as a module. If so, the module
will be called lm90.
+config SENSORS_LM92
+ tristate "National Semiconductor LM92 and compatibles"
+ depends on I2C && EXPERIMENTAL
+ select I2C_SENSOR
+ help
+ If you say yes here you get support for National Semiconductor LM92
+ and Maxim MAX6635 sensor chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called lm92.
+
config SENSORS_MAX1619
tristate "Maxim MAX1619 sensor chip"
depends on I2C && EXPERIMENTAL
diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
--- a/drivers/i2c/chips/Makefile2005-03-31 15:19:07 -08:00
+++ b/drivers/i2c/chips/Makefile2005-03-31 15:19:07 -08:00
@@ -27,6 +27,7 @@
obj-$(CONFIG_SENSORS_LM85) += lm85.o
obj-$(CONFIG_SENSORS_LM87) += lm87.o
obj-$(CONFIG_SENSORS_LM90) += lm90.o
+obj-$(CONFIG_SENSORS_LM92) += lm92.o
obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
diff -Nru a/drivers/i2c/chips/lm92.c b/drivers/i2c/chips/lm92.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/chips/lm92.c 2005-03-31 15:19:07 -08:00
@@ -0,0 +1,423 @@
+/*
+ * lm92 - Hardware monitoring driver
+ * Copyright (C) 2005 Jean Delvare <[EMAIL PROTECTED]>
+ *
+ * Based on the lm90 driver, with some ideas taken from the lm_sensors
+ * lm92 driver as well.
+ *
+ * The LM92 is a sensor chip made by National Semiconductor. It reports
+ * its own temperature with a 0.0625 deg resolution and a 0.33 deg
+ * accuracy. Complete datasheet can be obtained from National's website
+ * at:
+ * http://www.national.com/pf/LM/LM92.html
+ *
+ * This driver also supports the MAX6635 sensor chip made by Maxim.
+ * This chip is compatible with the LM92, but has a lesser accuracy
+ * (1.0 deg). Complete datasheet can be obtained from Maxim's website
+ * at:
+ * http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
+ *
+ * Since the LM92 was the first chipset supported by this driver, most
+ * comments will refer to this chipset, but are actually general and
+ * concern all supported chipsets, unless mentioned otherwise.
+ *
+ * Support could easily be added for the National Semiconductor LM76
+ * and Maxim MAX6633 and MAX6634 chips, which are mostly compatible
+ * with the LM92.
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+
+/* The LM92 and MAX6635 have 2 two-state pins for address selection,
+ resulting in 4 possible addresses. */
+static unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
+ I2C_CLIENT_END };
+static unsigned int normal_isa[] = { I2C_CLIENT_ISA_END };
+
+/* Insmod parameters */
+SENSORS_INSMOD_1(lm92);
+
+/* The LM92 registers */
+#define LM92_REG_CONFIG0x01 /* 8-bit, RW */
+#define LM92_REG_TEMP 0x00 /* 16-bit, RO */
+#define LM92_REG_TEMP_HYST 0x02 /* 16-bit, RW */
+#define LM92_REG_TEMP_CRIT 0x03 /* 16-bit, RW */
+#define LM92_REG_TEMP_LOW
[PATCH] I2C: i2c-s3c2410 functionality and fixes
ChangeSet 1.2346, 2005/03/31 14:31:40-08:00, [EMAIL PROTECTED]
[PATCH] I2C: i2c-s3c2410 functionality and fixes
This patch does the following updates to the i2c-s3c2410 bus driver:
* Properly report the i2c functionality by adding to the
`.functionality` field of the adapter
* Change the dev_err() call on no-ack to an dev_dbg() to make
it less noisy when the bus is being probed by i2cdetect, etc.
* Add I2C_M_REV_DIR_ADDR to fully implement the
I2C_FUNC_PROTOCOLO_MANGLING.
* Ensure that the adapter owner field is set to THIS_MODULE
Please apply, thanks.
(Once this is applied, all i2c bus drivers will be properly reporting
their functionality so I'll be able to go on with the i2c functionality
core cleanups.)
Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/busses/i2c-s3c2410.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff -Nru a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
--- a/drivers/i2c/busses/i2c-s3c2410.c 2005-03-31 15:16:24 -08:00
+++ b/drivers/i2c/busses/i2c-s3c2410.c 2005-03-31 15:16:24 -08:00
@@ -1,6 +1,6 @@
/* linux/drivers/i2c/busses/i2c-s3c2410.c
*
- * Copyright (C) 2004 Simtec Electronics
+ * Copyright (C) 2004,2005 Simtec Electronics
* Ben Dooks <[EMAIL PROTECTED]>
*
* S3C2410 I2C Controller
@@ -188,6 +188,9 @@
} else
stat |= S3C2410_IICSTAT_MASTER_TX;
+ if (msg->flags & I2C_M_REV_DIR_ADDR)
+ addr ^= 1;
+
// todo - check for wether ack wanted or not
s3c24xx_i2c_enable_ack(i2c);
@@ -287,7 +290,7 @@
!(i2c->msg->flags & I2C_M_IGNORE_NAK)) {
/* ack was not received... */
- dev_err(i2c->dev, "ack was not received\n" );
+ dev_dbg(i2c->dev, "ack was not received\n");
s3c24xx_i2c_stop(i2c, -EREMOTEIO);
goto out_ack;
}
@@ -555,11 +558,18 @@
return -EREMOTEIO;
}
+/* declare our i2c functionality */
+static u32 s3c24xx_i2c_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_PROTOCOL_MANGLING;
+}
+
/* i2c bus registration info */
static struct i2c_algorithm s3c24xx_i2c_algorithm = {
.name = "S3C2410-I2C-Algorithm",
.master_xfer= s3c24xx_i2c_xfer,
+ .functionality = s3c24xx_i2c_func,
};
static struct s3c24xx_i2c s3c24xx_i2c = {
@@ -567,6 +577,7 @@
.wait = __WAIT_QUEUE_HEAD_INITIALIZER(s3c24xx_i2c.wait),
.adap = {
.name = "s3c2410-i2c",
+ .owner = THIS_MODULE,
.algo = _i2c_algorithm,
.retries= 2,
.class = I2C_CLASS_HWMON,
-
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: Industry db benchmark result on recent 2.6 kernels
Chen, Kenneth W wrote: Linus Torvalds wrote on Thursday, March 31, 2005 12:09 PM Btw, I realize that you can't give good oprofiles for the user-mode components, but a kernel profile with even just single "time spent in user mode" datapoint would be good, since a kernel scheduling problem might just make caches work worse, and so the biggest negative might be visible in the amount of time we spend in user mode due to more cache misses.. I was going to bring it up in another thread. Since you brought it up, I will ride it along. The low point in 2.6.11 could very well be the change in the scheduler. It does too many load balancing in the wake up path and possibly made a lot of unwise decision. OK, and considering you have got no idle time at all, and the 2.6.11 kernel included some scheduler changes to make balancing much more aggressive, so unfortunately that's likely to have caused the latest drop. For example, in try_to_wake_up(), it will try SD_WAKE_AFFINE for task that is not hot. By not hot, it looks at when it was last ran and compare to a constant sd->cache_hot_time. The other problem with using that value there is that it represents a hard cutoff point in behaviour. For example, on a workload that really wants to have wakers and wakees together, it will work poorly on low loads, but when things get loaded up enough that we start seeing cache cold tasks there, behaviour suddenly changes. In the -mm kernels, there are a large number of scheduler changes that reduce the amount of balancing. They also remove cache_hot_time from this path (though it is still useful for periodic balancing). > The problem > is this cache_hot_time is fixed for the entire universe, whether it is a > little celeron processor with 128KB of cache or a sever class Itanium2 > processor with 9MB L3 cache. This one size fit all isn't really working > at all. Ingo had a cool patch to estimate dirty => dirty cacheline transfer latency for all processors with respect to all others, and dynamically tune cache_hot_time. Unfortunately it was never completely polished, and it is an O(cpus^2) operation. It is a good idea to look into though. We had experimented that parameter earlier and found it was one of the major source of low point in 2.6.8. I debated the issue on LKML about 4 month ago and finally everyone agreed to make that parameter a boot time param. The change made into bk tree for 2.6.9 release, but somehow it got ripped right out 2 days after it went in. I suspect 2.6.11 is a replay of 2.6.8 for the regression in the scheduler. We are running experiment to confirm this theory. That actually brings up more thoughts: what about all other sched parameters? We found values other than the default helps to push performance up, but it is probably not acceptable to pick a default number from a db benchmark. Kernel needs either a dynamic closed feedback loop to adapt to the workload or some runtime tunables to control them. Though the latter option did not go anywhere in the past. They're in -mm. I think Andrew would rather see things (like auto tuning cache hot time) rather than putting more runtime variables in. If you were to make a program which adjusted various parameters using a feedback loop, then that would be a good argument to put runtime tunables in. Oh, one last thing - if you do a great deal of scheduler tuning, it would be very good if you could possibly use the patchset in -mm. Things have changed sufficiently that optimal values you find in 2.6 will not be the same as those in -mm. I realise this may be difficult to justify, but I would hate for the whole cycle to have to happen again when the patches go into 2.6. - 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] i2c: i2c-mv64xxx - set adapter owner and class fields
ChangeSet 1.2351, 2005/03/31 14:33:14-08:00, [EMAIL PROTECTED] [PATCH] i2c: i2c-mv64xxx - set adapter owner and class fields This patch adds the correct values for the 'owner' and 'class' fields of the adapter structure in the mv64xxx i2c bus driver. The missing class field caused some i2c chip drivers to refuse to attempt a probe on the mv64xxx i2c bus. Signed-off-by: Chris Elston <[EMAIL PROTECTED]> Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> drivers/i2c/busses/i2c-mv64xxx.c |2 ++ 1 files changed, 2 insertions(+) diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c --- a/drivers/i2c/busses/i2c-mv64xxx.c 2005-03-31 15:15:49 -08:00 +++ b/drivers/i2c/busses/i2c-mv64xxx.c 2005-03-31 15:15:49 -08:00 @@ -525,6 +525,8 @@ drv_data->irq = platform_get_irq(pd, 0); drv_data->adapter.id = I2C_ALGO_MV64XXX | I2C_HW_MV64XXX; drv_data->adapter.algo = _i2c_algo; + drv_data->adapter.owner = THIS_MODULE; + drv_data->adapter.class = I2C_CLASS_HWMON; drv_data->adapter.timeout = pdata->timeout; drv_data->adapter.retries = pdata->retries; dev_set_drvdata(dev, drv_data); - 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] I2C: busses documentation update 2 of 2
ChangeSet 1.2341, 2005/03/31 14:30:05-08:00, [EMAIL PROTECTED] [PATCH] I2C: busses documentation update 2 of 2 Patch contains promised documentation update for i2c bus drivers. I would like to thank Jean Delvare and Aurelien Jarno for their comments. Signed-off-by: Rudolf Marek <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> Documentation/i2c/busses/i2c-ali1535 | 42 ++ Documentation/i2c/busses/i2c-ali1563 | 27 ++ Documentation/i2c/busses/i2c-ali15x3 | 112 + Documentation/i2c/busses/i2c-amd756| 25 ++ Documentation/i2c/busses/i2c-amd8111 | 41 ++ Documentation/i2c/busses/i2c-i801 | 80 Documentation/i2c/busses/i2c-i810 | 46 +++ Documentation/i2c/busses/i2c-nforce2 | 41 ++ Documentation/i2c/busses/i2c-parport | 18 ++-- Documentation/i2c/busses/i2c-parport-light | 11 ++ Documentation/i2c/busses/i2c-pca-isa | 23 + Documentation/i2c/busses/i2c-piix4 | 72 ++ Documentation/i2c/busses/i2c-prosavage | 23 + Documentation/i2c/busses/i2c-savage4 | 26 ++ Documentation/i2c/busses/i2c-sis5595 | 59 +++ Documentation/i2c/busses/i2c-sis630| 49 Documentation/i2c/busses/i2c-sis69x| 73 ++ Documentation/i2c/busses/i2c-via | 34 Documentation/i2c/busses/i2c-viapro| 47 Documentation/i2c/busses/i2c-voodoo3 | 62 Documentation/i2c/busses/scx200_acb| 14 +++ 21 files changed, 915 insertions(+), 10 deletions(-) diff -Nru a/Documentation/i2c/busses/i2c-ali1535 b/Documentation/i2c/busses/i2c-ali1535 --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/i2c/busses/i2c-ali1535 2005-03-31 15:17:04 -08:00 @@ -0,0 +1,42 @@ +Kernel driver i2c-ali1535 + +Supported adapters: + * Acer Labs, Inc. ALI 1535 (south bridge) +Datasheet: Now under NDA + http://www.ali.com.tw/eng/support/datasheet_request.php + +Authors: + Frodo Looijaard <[EMAIL PROTECTED]>, + Philip Edelbrock <[EMAIL PROTECTED]>, + Mark D. Studebaker <[EMAIL PROTECTED]>, + Dan Eaton <[EMAIL PROTECTED]>, + Stephen Rousset<[EMAIL PROTECTED]> + +Description +--- + +This is the driver for the SMB Host controller on Acer Labs Inc. (ALI) +M1535 South Bridge. + +The M1535 is a South bridge for portable systems. It is very similar to the +M15x3 South bridges also produced by Acer Labs Inc. Some of the registers +within the part have moved and some have been redefined slightly. +Additionally, the sequencing of the SMBus transactions has been modified to +be more consistent with the sequencing recommended by the manufacturer and +observed through testing. These changes are reflected in this driver and +can be identified by comparing this driver to the i2c-ali15x3 driver. For +an overview of these chips see http://www.acerlabs.com + +The SMB controller is part of the M7101 device, which is an ACPI-compliant +Power Management Unit (PMU). + +The whole M7101 device has to be enabled for the SMB to work. You can't +just enable the SMB alone. The SMB and the ACPI have separate I/O spaces. +We make sure that the SMB is enabled. We leave the ACPI alone. + + +Features + + +This driver controls the SMB Host only. This driver does not use +interrupts. diff -Nru a/Documentation/i2c/busses/i2c-ali1563 b/Documentation/i2c/busses/i2c-ali1563 --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/i2c/busses/i2c-ali1563 2005-03-31 15:17:04 -08:00 @@ -0,0 +1,27 @@ +Kernel driver i2c-ali1563 + +Supported adapters: + * Acer Labs, Inc. ALI 1563 (south bridge) +Datasheet: Now under NDA + http://www.ali.com.tw/eng/support/datasheet_request.php + +Author: Patrick Mochel <[EMAIL PROTECTED]> + +Description +--- + +This is the driver for the SMB Host controller on Acer Labs Inc. (ALI) +M1563 South Bridge. + +For an overview of these chips see http://www.acerlabs.com + +The M1563 southbridge is deceptively similar to the M1533, with a few +notable exceptions. One of those happens to be the fact they upgraded the +i2c core to be SMBus 2.0 compliant, and happens to be almost identical to +the i2c controller found in the Intel 801 south bridges. + +Features + + +This driver controls the SMB Host only. This driver does not use +interrupts. diff -Nru a/Documentation/i2c/busses/i2c-ali15x3 b/Documentation/i2c/busses/i2c-ali15x3 --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/i2c/busses/i2c-ali15x3 2005-03-31 15:17:04 -08:00 @@ -0,0 +1,112 @@ +Kernel driver i2c-ali15x3 + +Supported adapters: + * Acer Labs, Inc. ALI 1533 and 1543C (south bridge) +Datasheet: Now under NDA +
[PATCH] I2C: Fix adm1021 alarms mask
ChangeSet 1.2326, 2005/03/31 14:06:28-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Fix adm1021 alarms mask
This patch fixes an incorrect bitmasking on the status register in the
adm1021 driver, which was causing high alarm on remote temperature to be
hidden.
This bug was found and reported by Jayakrishnan:
http://bugzilla.kernel.org/show_bug.cgi?id=4285
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/adm1021.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Nru a/drivers/i2c/chips/adm1021.c b/drivers/i2c/chips/adm1021.c
--- a/drivers/i2c/chips/adm1021.c 2005-03-31 15:18:52 -08:00
+++ b/drivers/i2c/chips/adm1021.c 2005-03-31 15:18:52 -08:00
@@ -368,7 +368,7 @@
data->remote_temp_input = adm1021_read_value(client,
ADM1021_REG_REMOTE_TEMP);
data->remote_temp_max = adm1021_read_value(client,
ADM1021_REG_REMOTE_TOS_R);
data->remote_temp_hyst = adm1021_read_value(client,
ADM1021_REG_REMOTE_THYST_R);
- data->alarms = adm1021_read_value(client, ADM1021_REG_STATUS) &
0xec;
+ data->alarms = adm1021_read_value(client, ADM1021_REG_STATUS) &
0x7c;
if (data->type == adm1021)
data->die_code = adm1021_read_value(client,
ADM1021_REG_DIE_CODE);
if (data->type == adm1023) {
-
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] I2C: Make master_xfer debug messages more useful
ChangeSet 1.2328, 2005/03/31 14:07:05-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Make master_xfer debug messages more useful
While working on the recent saa7110 mess, I found that the debug message
displayed when calling master_xfer wasn't as useful as it could be. Here
is a patch improving this.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/i2c-core.c |8 +++-
1 files changed, 7 insertions(+), 1 deletion(-)
diff -Nru a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
--- a/drivers/i2c/i2c-core.c2005-03-31 15:18:36 -08:00
+++ b/drivers/i2c/i2c-core.c2005-03-31 15:18:36 -08:00
@@ -587,7 +587,13 @@
int ret;
if (adap->algo->master_xfer) {
- dev_dbg(>dev, "master_xfer: with %d msgs.\n", num);
+#ifdef DEBUG
+ for (ret = 0; ret < num; ret++) {
+ dev_dbg(>dev, "master_xfer[%d] %c, addr=0x%02x, "
+ "len=%d\n", ret, msgs[ret].flags & I2C_M_RD ?
+ 'R' : 'W', msgs[ret].addr, msgs[ret].len);
+ }
+#endif
down(>bus_lock);
ret = adap->algo->master_xfer(adap,msgs,num);
-
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] I2C: Skip broken detection step in it87
ChangeSet 1.2329, 2005/03/31 14:07:24-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Skip broken detection step in it87
One of the detection steps in the it87 chip driver was reported to be
broken for some revisions of the IT8712F chip [1] [2]. This detection
step is a legacy from the lm78 driver and the documentation available
for the IT8705F and IT8712F chips does not mention it at all. For this
reason, I propose to skip this detection step for Super-I/O chips.
Super-I/O chips have already been identified when we reach this step, so
it is redundant (additionally do being broken). This closes bug #4335.
[1] http://bugzilla.kernel.org/show_bug.cgi?id=4335
[2] http://archives.andrew.net.au/lm-sensors/msg29962.html
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/it87.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff -Nru a/drivers/i2c/chips/it87.c b/drivers/i2c/chips/it87.c
--- a/drivers/i2c/chips/it87.c 2005-03-31 15:18:29 -08:00
+++ b/drivers/i2c/chips/it87.c 2005-03-31 15:18:29 -08:00
@@ -734,10 +734,9 @@
goto ERROR0;
/* Probe whether there is anything available on this address. Already
- done for SMBus clients */
+ done for SMBus and Super-I/O clients */
if (kind < 0) {
- if (is_isa) {
-
+ if (is_isa && !chip_type) {
#define REALLY_SLOW_IO
/* We need the timeouts for at least some IT87-like
chips. But only
if we read 'undefined' registers. */
-
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] I2C: Fix Vaio EEPROM detection
ChangeSet 1.2339, 2005/03/31 14:29:23-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Fix Vaio EEPROM detection
This fixes a bug in the eeprom driver, which made all EEPROMs at
location 0x57 be erroneously treated as Vaio EEPROMs. I have to say I'm
quite ashamed that I introduced the bug in the first place, as this was
a really stupid one.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/chips/eeprom.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -Nru a/drivers/i2c/chips/eeprom.c b/drivers/i2c/chips/eeprom.c
--- a/drivers/i2c/chips/eeprom.c2005-03-31 15:17:18 -08:00
+++ b/drivers/i2c/chips/eeprom.c2005-03-31 15:17:18 -08:00
@@ -210,10 +210,11 @@
if (i2c_smbus_read_byte_data(new_client, 0x80) == 'P'
&& i2c_smbus_read_byte(new_client) == 'C'
&& i2c_smbus_read_byte(new_client) == 'G'
-&& i2c_smbus_read_byte(new_client) == '-')
+&& i2c_smbus_read_byte(new_client) == '-') {
dev_info(_client->dev, "Vaio EEPROM detected, "
"enabling password protection\n");
data->nature = VAIO;
+ }
}
/* create the sysfs eeprom file */
-
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] I2C: Clean up of i2c-elektor.c build
ChangeSet 1.2333, 2005/03/31 14:08:41-08:00, [EMAIL PROTECTED]
[PATCH] I2C: Clean up of i2c-elektor.c build
This patch changes the flags variable type from long to unsigned long in
one function. This removes a couple of warnings from the compile
messages for elektor i2c bus driver.
Signed-off-by: Frank Beesley <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
drivers/i2c/busses/i2c-elektor.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Nru a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
--- a/drivers/i2c/busses/i2c-elektor.c 2005-03-31 15:18:01 -08:00
+++ b/drivers/i2c/busses/i2c-elektor.c 2005-03-31 15:18:01 -08:00
@@ -112,7 +112,7 @@
static void pcf_isa_waitforpin(void) {
DEFINE_WAIT(wait);
int timeout = 2;
- long flags;
+ unsigned long flags;
if (irq > 0) {
spin_lock_irqsave(, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
