Re: [patch -mm series] ia64 specific /dev/mem handlers
> "Arjan" == Arjan van de Ven <[EMAIL PROTECTED]> writes: Arjan> On Tue, 2005-02-22 at 17:30 -0500, Jes Sorensen wrote: >> For userspace it's used by some of the MPI type apps in userland. Arjan> you got to be kidding. Why are these MPI apps accessing memory Arjan> that the kernel has mapped cached (eg ram) via /dev/mem? Oh sorry, I think we're misunderstanding eachother. /dev/mem is used by lcrash. Arjan> (eg my proposal is to make /dev/mem to be just device memory Arjan> not kernel accessable ram; wouldn't that solve the entire issue Arjan> cleanly ?) It would kill lcrash support, but sure it would solve this specific problem. However what happens if someone wants to share say some texture ram between the kernel and a video card and that has to be mapped uncached? Though up example here though. Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch -mm series] ia64 specific /dev/mem handlers
> However what happens if someone wants to share say some > texture ram between the kernel and a video card and that has to be > mapped uncached? Though up example here though. also that's surely supposed to be controlled by some kernel driver, which in turn can and should export it's own mmap instead with all the proper attributes... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: uninterruptible sleep lockups
In article <[EMAIL PROTECTED]> you write: > The most recent one was yesterday: I had run lsusb in the morning and had no > problems, but at the end of the day I ran it again, and after outputting 3 > lines of data, it hung, stuck in D-state. So now I have this: > > [/home/user]$ ps aux|grep D > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root92 0.0 0.0 00 ?DFeb19 0:00 [khubd] > root 845 0.0 0.0 00 ?DFeb19 0:00 [knodemgrd_0] > root 29016 0.0 0.1 1512 592 ?D00:28 0:00 lsusb I'm getting fairly repeatable deadlocks of this kind involving khubd with a USB storage device. Perhaps there's just a faulty locking issue in khubd. Olaf PS. Linux 2.6.9 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Lse-tech] Re: A common layer for Accounting packages
On Tue, 2005-02-22 at 23:20 -0800, Andrew Morton wrote: > Kaigai Kohei <[EMAIL PROTECTED]> wrote: > > > > The common agreement for the method of dealing with process aggregation > > has not been constructed yet, I understood. And, we will not able to > > integrate each process aggregation model because of its diverseness. > > > > For example, a process which belong to JOB-A must not belong any other > > 'JOB-X' in CSA-model. But, In ELSA-model, a process in BANK-B can > > concurrently > > belong to BANK-B1 which is a child of BANK-B. > > > > And, there are other defferences: > > Whether a process not to belong to any process-aggregation is permitted or > > not ? > > Whether a process-aggregation should be inherited to child process or not ? > > (There is possibility not to be inherited in a rule-based process > > aggregation like CKRM) > > > > Some process-aggregation model have own philosophy and implemantation, > > so it's hard to integrate. Thus, I think that common 'fork/exec/exit' > > event handling > > framework to implement any kinds of process-aggregation. I can add "policies". With ELSA, a process belongs to one or several groups and if a process is removed from one group, its children still belong to the group. Thus a good idea could be to associate a "philosophy" to a group. For exemple, when a group of processes is created it can be tagged as UNIQUE or SHARED. UNIQUE means that a process that belongs to it could not be added in another group by opposition to SHARED. It's not needed inside the kernel. > We really want to avoid doing such stuff in-kernel if at all possible, of > course. > > Is it not possible to implement the fork/exec/exit notifications to > userspace so that a daemon can track the process relationships and perform > aggregation based upon individual tasks' accounting? That's what one of > the accounting systems is proposing doing, I believe. It's what I'm proposing. The problem is to be alerted when a new process is created in order to add it in the correct group of processes if the parent belongs to one (or several) groups. The notification can be done with the fork connector patch. > (In fact, why do we even need the notifications? /bin/ps can work this > stuff out). Yes it can but the risk is to lose some forks no? I think that /bin/ps is using the /proc interface. If we're polling the /proc to catch process creation we may lost some of them. With the fork connector we catch all forks and we can check that by using the sequence number (incremented by each fork) of the message. Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Lse-tech] Re: A common layer for Accounting packages
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: > > ... > > > We really want to avoid doing such stuff in-kernel if at all possible, of > > course. > > > > Is it not possible to implement the fork/exec/exit notifications to > > userspace so that a daemon can track the process relationships and perform > > aggregation based upon individual tasks' accounting? That's what one of > > the accounting systems is proposing doing, I believe. > > It's what I'm proposing. The problem is to be alerted when a new process > is created in order to add it in the correct group of processes if the > parent belongs to one (or several) groups. The notification can be done > with the fork connector patch. Yes, it sounds sane. The 2.6.8.1 ELSA patch adds quite a bit of kernel code, but from what you're saying it seems like most of that has become redundant, and all you now need is the fork notifier. Is that correct? That 2.6.8.1 ELSA patch looks reasonable to me - it only adds two lines to generic code and the rest looks pretty straightforward. Are we sure that this level of functionality is not sufficient for everyone else? > > (In fact, why do we even need the notifications? /bin/ps can work this > > stuff out). > > Yes it can but the risk is to lose some forks no? > I think that /bin/ps is using the /proc interface. If we're polling > the /proc to catch process creation we may lost some of them. With the > fork connector we catch all forks and we can check that by using the > sequence number (incremented by each fork) of the message. Oh, I wasn't proposing that it all be done via existing /proc interfaces - I was just getting my head straight ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc3-mm2] connector: Add a fork connector
Hello,
This patch replaces the relay_fork module and it implements a fork
connector in the kernel/fork.c:do_fork() routine. The connector sends
information about parent PID and child PID over a netlink interface. It
allows to several user space applications to be informed when a fork
occurs in the kernel. The main drawback is that even if nobody listens,
message is send. I don't know how to avoid that.
It is used by ELSA to manage group of processes in user space.
ChangeLog:
- Add a "depends on CONNECTOR=y" in the Kconfig
- Remove the macro #if defined(CONFIG_CONNECTOR)
- cn_netlink_send() sends messages to the correct group which is
CN_IDX_FORK
Thanks to Evgeniy and to everyone for the comments,
Guillaume
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig |8
include/linux/connector.h |2 ++
kernel/fork.c | 41 +
3 files changed, 51 insertions(+)
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/drivers/connector/Kconfig
linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc3-mm2/drivers/connector/Kconfig 2005-02-11
11:00:16.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig 2005-02-21
09:52:22.0 +0100
@@ -10,4 +10,12 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+
endmenu
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/include/linux/connector.h
linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h
--- linux-2.6.11-rc3-mm2/include/linux/connector.h 2005-02-11
11:00:18.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h 2005-02-16
15:07:46.0 +0100
@@ -28,6 +28,8 @@
#define CN_VAL_KOBJECT_UEVENT 0x
#define CN_IDX_SUPERIO 0xaabb /* SuperIO subsystem */
#define CN_VAL_SUPERIO 0xccdd
+#define CN_IDX_FORK0xfeed /* fork events */
+#define CN_VAL_FORK0xbeef
#define CONNECTOR_MAX_MSG_SIZE 1024
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/kernel/fork.c
linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c
--- linux-2.6.11-rc3-mm2/kernel/fork.c 2005-02-11 11:00:18.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c 2005-02-21 09:52:40.0
+0100
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -63,6 +64,44 @@ DEFINE_PER_CPU(unsigned long, process_co
EXPORT_SYMBOL(tasklist_lock);
+#ifdef CONFIG_FORK_CONNECTOR
+#define FORK_CN_INFO_SIZE 64
+static inline void fork_connector(pid_t parent, pid_t child)
+{
+ struct cb_id fork_id = {CN_IDX_FORK, CN_VAL_FORK};
+ static __u32 seq; /* used to test if we lost message */
+
+ if (cn_already_initialized) {
+ struct cn_msg *msg;
+ size_t size;
+
+ size = sizeof(*msg) + FORK_CN_INFO_SIZE;
+ msg = kmalloc(size, GFP_KERNEL);
+ if (msg) {
+ memset(msg, '\0', size);
+ memcpy(&msg->id, &fork_id, sizeof(msg->id));
+ msg->seq = seq++;
+ msg->ack = 0; /* not used */
+ /*
+* size of data is the number of characters
+* printed plus one for the trailing '\0'
+*/
+ msg->len = snprintf(msg->data, FORK_CN_INFO_SIZE-1,
+ "%i %i", parent, child) + 1;
+
+ cn_netlink_send(msg, CN_IDX_FORK);
+
+ kfree(msg);
+ }
+ }
+}
+#else
+static inline void fork_connector(pid_t parent, pid_t child)
+{
+ return;
+}
+#endif
+
int nr_processes(void)
{
int cpu;
@@ -1238,6 +1277,8 @@ long do_fork(unsigned long clone_flags,
if (unlikely (current->ptrace & PT_TRACE_VFORK_DONE))
ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8) |
SIGTRAP);
}
+
+ fork_connector(current->pid, p->pid);
} else {
free_pidmap(pid);
pid = PTR_ERR(p);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rft/update] r8169 changes in 2.6.x
Andrew Morton <[EMAIL PROTECTED]> :
> There are already a bunch of r8169 patches in Jeff's tree. The combination
> isn't pretty:
[removed by parental advisory]
I sent r8169-4{0/1/2/3/4}0 on netdev + Jeff the 22/02/2005. Jeff's netdev
(thus your tree) already had the r8169-3xx changes.
Jeff has acked r8169-4{0/1/2/3}0 on 23/02/2005. r8169-440 (PCI-ID) won't
be applied (there should be no functionnal change nor merge side-effect).
r8169-4{5/6}0 have been published only here (so far).
So you can:
- apply r8169-4{0/1/2/3/5/6}0 if you have not updated to Jeff -netdev beyond
what is currently available through plain old patch
- apply r8169-4{5/6}0 if you are bk-synced with Jeff -netdev (assuming that
Jeff acked after he actually pushed to its bk repo)
- do something else until I verify the above and generate a dedicated
patchsets for your tree.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc3-mm2] connector: Add a fork connector
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> This patch replaces the relay_fork module and it implements a fork
> connector in the kernel/fork.c:do_fork() routine. The connector sends
> information about parent PID and child PID over a netlink interface. It
> allows to several user space applications to be informed when a fork
> occurs in the kernel. The main drawback is that even if nobody listens,
> message is send. I don't know how to avoid that.
We really should find a way to fix that. Especially if we want all the
distributors to enable the connector in their builds (we do).
What happened to the idea of sending an on/off message down the netlink
socket?
> +#ifdef CONFIG_FORK_CONNECTOR
> +#define FORK_CN_INFO_SIZE64
> +static inline void fork_connector(pid_t parent, pid_t child)
> +{
> + struct cb_id fork_id = {CN_IDX_FORK, CN_VAL_FORK};
This can be static const, which will save some stack and cycles.
> + static __u32 seq; /* used to test if we lost message */
> +
> + if (cn_already_initialized) {
> + struct cn_msg *msg;
> + size_t size;
> +
> + size = sizeof(*msg) + FORK_CN_INFO_SIZE;
> + msg = kmalloc(size, GFP_KERNEL);
> + if (msg) {
> + memset(msg, '\0', size);
Do we really need to memset the whole thing?
> + memcpy(&msg->id, &fork_id, sizeof(msg->id));
> + msg->seq = seq++;
`seq' needs a lock to protect it. Or use atomic_add_return(), maybe.
> + msg->ack = 0; /* not used */
> + /*
> + * size of data is the number of characters
> + * printed plus one for the trailing '\0'
> + */
> + msg->len = snprintf(msg->data, FORK_CN_INFO_SIZE-1,
> + "%i %i", parent, child) + 1;
scnprintf() would be more appropriate here, even though it should be a "can't
happen".
> + cn_netlink_send(msg, CN_IDX_FORK);
> +
> + kfree(msg);
`msg' is only 84 bytes and do_fork() has a shallow call graph. Make `msg'
a local?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rft/update] r8169 changes in 2.6.x
Francois Romieu <[EMAIL PROTECTED]> wrote: > > - do something else until I verify the above and generate a dedicated >patchsets for your tree. That sounds great to me ;) 2.6.11-rc4-mm1 should be on kernel.org in an hour or so. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Lse-tech] Re: A common layer for Accounting packages
On Wed, 2005-02-23 at 00:51 -0800, Andrew Morton wrote: > > It's what I'm proposing. The problem is to be alerted when a new process > > is created in order to add it in the correct group of processes if the > > parent belongs to one (or several) groups. The notification can be done > > with the fork connector patch. > > Yes, it sounds sane. > > The 2.6.8.1 ELSA patch adds quite a bit of kernel code, but from what > you're saying it seems like most of that has become redundant, and all > you now need is the fork notifier. Is that correct? Yes, that's correct. All I need is the fork connector patch. It needs more work like, as you said, sending an on/off message down the netlink socket. I'm working on this (thank you very much Andrew for your comments). I will run benchmarks found at http://bulk.fefe.de/scalability/ to see how the fork connector impacts on the kernel. All stuff that was previously done in kernel space and provided by the 2.6.8.1 ELSA patch has been moved in the ELSA user space daemon called "jobd". Best, Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Lse-tech] Re: A common layer for Accounting packages
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: > > I will run benchmarks found at http://bulk.fefe.de/scalability/ to see > how the fork connector impacts on the kernel. The lmbench fork microbenchmark would suffice. >All stuff that was previously done in kernel space and provided by the > 2.6.8.1 ELSA patch has been moved in the ELSA user space daemon called > "jobd". Excellent. Will it work? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Symlink /sys/class/block to /sys/block (fwd)
Greg KH writes: Following the discussion in [1], the attached patch creates /sys/class/block as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7. Please cc: me on any replies - I'm not subscribed to the mailing list. Hm, your patch is linewrapped, and can't be applied :( Bah, and I did send it to myself first, but I guess my mailer un-flowed it for me :-(. I'll try to find a better mailer. But more importantly: static void disk_release(struct kobject * kobj) Did you try to remove a disk (like a usb device) and see what happens here? Hint, this isn't the proper place to remove the symlink... Er, yeah. Oops. *Is* there a sensible place to remove the symlink from, though? Nobody seems to call subsystem_unregister(&block_subsys), which is the place I'd expect to add a call to, and I can't see anything that's otherwise obvious... Regards, Malcolm [resent using the right address for linux-kernel. Sorry for the duplicate, Greg] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Lse-tech] Re: A common layer for Accounting packages
On Tue, 22 Feb 2005, Andrew Morton wrote: > We really want to avoid doing such stuff in-kernel if at all possible, of > course. > > Is it not possible to implement the fork/exec/exit notifications to > userspace so that a daemon can track the process relationships and perform > aggregation based upon individual tasks' accounting? That's what one of > the accounting systems is proposing doing, I believe. > > (In fact, why do we even need the notifications? /bin/ps can work this > stuff out). I had started a proof of concept implementation that could reconstruct the whole process tree from userspace just from the BSD accounting currently in the kernel (+ the conceptual bug-fix that I misnamed "[RFC] "biological parent" pid"). This could do the whole job ID thing from userspace. Unfortunately, I haven't had time to work on it recently. Also, doing per-job accounting might actually be more lightweight than per-process accounting, so I'm not at all opposed to unifying CSA and BSD accounting into one mechanism that just writes different file formats. A complete framework seems like overkill to me, too. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch -mm series] ia64 specific /dev/mem handlers
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> Jes Sorensen <[EMAIL PROTECTED]> wrote:
>> After applying the clue 2x4 to my head a couple of times, I came
>> up with this patch. Hopefully it will work a bit better ;-)
>>
Andrew> I know it's repetitious, but it's nice to maintain a changelog
Andrew> entry along with the patch. Especially when seventy people
Andrew> have asked "wtf is this patch for?".
True, that got lost in the multi-iteration game. Added one now.
Andrew> Implementation-wise, do you really need to clone-and-own the
Andrew> mem.c functions? Would it not be sufficient to do
Andrew> ptr = arch_translate_mem_ptr(page, ptr);
Andrew> inside mem.c?
I tried to avoid making too many changes to drivers/char/mem.c but on
the long run this is probably cleaner. It makes it slightly more
complex on all architectures to do large read/write calls on /dev/mem
but it's not exactly a performance path.
>> + * arch/ia64/kernel/mem.c ... +extern loff_t memory_lseek(struct
>> file * file, loff_t offset, int orig); +extern int mmap_kmem(struct
>> file * file, struct vm_area_struct * vma); +extern int
>> open_port(struct inode * inode, struct file * filp); +
Andrew> Please find a .h file for the function prototypes.
All gone with the merge into drivers/char/mem.c
Note, I put the macros in include/asm-ia64/uaccess.h to avoid all hell
breaking lose in the ia64 build process which generates offsets.h. We
can introduce a new header file but it seems a bit overkill imho.
Cheers,
Jes
Convert /dev/mem read/write calls to use arch_translate_mem_ptr if
available. Needed on ia64 for pages converted fo uncached mappings to
avoid it being accessed in cached mode after the conversion which can
lead to memory corruption. Introduces PG_uncached page flag for
marking pages uncached.
Also folds do_write_mem into write_mem as it was it's only user.
Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
diff -urN -X /usr/people/jes/exclude-linux --exclude=shubio.h
linux-2.6.11-rc3-mm2-vanilla/drivers/char/mem.c
linux-2.6.11-rc3-mm2-2/drivers/char/mem.c
--- linux-2.6.11-rc3-mm2-vanilla/drivers/char/mem.c 2005-02-16 11:20:55
-08:00
+++ linux-2.6.11-rc3-mm2-2/drivers/char/mem.c 2005-02-23 01:51:54 -08:00
@@ -125,39 +125,6 @@
}
return 1;
}
-static ssize_t do_write_mem(void *p, unsigned long realp,
- const char __user * buf, size_t count, loff_t *ppos)
-{
- ssize_t written;
- unsigned long copied;
-
- written = 0;
-#if defined(__sparc__) || (defined(__mc68000__) && defined(CONFIG_MMU))
- /* we don't have page 0 mapped on sparc and m68k.. */
- if (realp < PAGE_SIZE) {
- unsigned long sz = PAGE_SIZE-realp;
- if (sz > count) sz = count;
- /* Hmm. Do something? */
- buf+=sz;
- p+=sz;
- count-=sz;
- written+=sz;
- }
-#endif
- if (!range_is_allowed(realp, realp+count))
- return -EPERM;
- copied = copy_from_user(p, buf, count);
- if (copied) {
- ssize_t ret = written + (count - copied);
-
- if (ret)
- return ret;
- return -EFAULT;
- }
- written += count;
- *ppos += written;
- return written;
-}
#ifndef ARCH_HAS_DEV_MEM
/*
@@ -168,7 +135,9 @@
size_t count, loff_t *ppos)
{
unsigned long p = *ppos;
- ssize_t read;
+ ssize_t read, sz;
+ struct page *page;
+ char *ptr;
if (!valid_phys_addr_range(p, &count))
return -EFAULT;
@@ -176,7 +145,7 @@
#if defined(__sparc__) || (defined(__mc68000__) && defined(CONFIG_MMU))
/* we don't have page 0 mapped on sparc and m68k.. */
if (p < PAGE_SIZE) {
- unsigned long sz = PAGE_SIZE-p;
+ sz = PAGE_SIZE - p;
if (sz > count)
sz = count;
if (sz > 0) {
@@ -189,9 +158,35 @@
}
}
#endif
- if (copy_to_user(buf, __va(p), count))
- return -EFAULT;
- read += count;
+
+ while (count > 0) {
+ /*
+* Handle first page in case it's not aligned
+*/
+ if (-p & (PAGE_SIZE - 1))
+ sz = -p & (PAGE_SIZE - 1);
+ else
+ sz = min(PAGE_SIZE, count);
+
+ page = pfn_to_page(p >> PAGE_SHIFT);
+ /*
+* On ia64 if a page has been mapped somewhere as
+* uncached, then it must also be accessed uncached
+* by the kernel or data corruption may occur
+*/
+#ifdef ARCH_HAS_TRANSLATE_MEM_PTR
+ ptr = arch_translate_mem_ptr(page, p);
+#else
+ ptr = __va(p);
+#endif
+ if (copy_to_user(buf, ptr, sz))
+ r
Re: uninterruptible sleep lockups
On Tue, 2005-02-22 at 22:05 -0300, Horst von Brand wrote: > Chris Friesen <[EMAIL PROTECTED]> said: [...] > > Maybe I'm on crack, but would it not be technically possible to have all > > resource usage be tracked so that when a task tries to do something and > > hangs, eventually it gets cleaned up? > > Sure. But there is /no way/ to know if the task will ever do something > (Turing's undecibility sees to that, even with perfect hardware), so the ACK. But if root says "it will not come" (through whatever method), the we have a decision good enough for real life. The downside is that we need for each usage of these items explicit checks and cleanup code (which wants to be written and tested) after each usage. Does this pay off? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Q: Shared Memory vs. Ramdisk?
Hi all, I have an application on x86-64 that will require me sharing two memory segments upwards of 10+ GB each among several processes. Would it be better performance-wise to mmap in two files from a tmpfs filesystem, or, create two large ramdisks (/dev/ram0 & /dev/ram1) and mmap those in? I'm not concerned about swap, but rather just trying to avoid as much kernel overhead as possible while accessing gobs of memory. Thanks, -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
On Wed, 23 Feb 2005 01:07:47 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > This patch replaces the relay_fork module and it implements a fork
> > connector in the kernel/fork.c:do_fork() routine. The connector sends
> > information about parent PID and child PID over a netlink interface. It
> > allows to several user space applications to be informed when a fork
> > occurs in the kernel. The main drawback is that even if nobody listens,
> > message is send. I don't know how to avoid that.
>
> We really should find a way to fix that. Especially if we want all the
> distributors to enable the connector in their builds (we do).
Mesage is never reached anyone if there are no listeners, skb will be just
freed,
even without any linking.
do_one_broadcast() in net/netlink/af_netlink.c takes care of it.
Unicast message also will be discarded in cn_rx_skb().
These operations are quite cheap - just link/unlink skb to/from appropriate
queues.
> What happened to the idea of sending an on/off message down the netlink
> socket?
?
> > +#ifdef CONFIG_FORK_CONNECTOR
> > +#define FORK_CN_INFO_SIZE 64
> > +static inline void fork_connector(pid_t parent, pid_t child)
> > +{
> > + struct cb_id fork_id = {CN_IDX_FORK, CN_VAL_FORK};
>
> This can be static const, which will save some stack and cycles.
>
> > + static __u32 seq; /* used to test if we lost message */
> > +
> > + if (cn_already_initialized) {
> > + struct cn_msg *msg;
> > + size_t size;
> > +
> > + size = sizeof(*msg) + FORK_CN_INFO_SIZE;
> > + msg = kmalloc(size, GFP_KERNEL);
> > + if (msg) {
> > + memset(msg, '\0', size);
>
> Do we really need to memset the whole thing?
Yes, to not leak kernel memory context.
> > + memcpy(&msg->id, &fork_id, sizeof(msg->id));
> > + msg->seq = seq++;
>
> `seq' needs a lock to protect it. Or use atomic_add_return(), maybe.
Not necessary, I doubt fork userspace listener uses protocol described in
connector.c and relies on seq field since it is not needed to have acks/replays.
Although it can be used as a flag that it is new fork, but message itself
is already such an event.
> > + msg->ack = 0; /* not used */
> > + /*
> > +* size of data is the number of characters
> > +* printed plus one for the trailing '\0'
> > +*/
> > + msg->len = snprintf(msg->data, FORK_CN_INFO_SIZE-1,
> > + "%i %i", parent, child) + 1;
>
> scnprintf() would be more appropriate here, even though it should be a "can't
> happen".
>
> > + cn_netlink_send(msg, CN_IDX_FORK);
> > +
> > + kfree(msg);
>
> `msg' is only 84 bytes and do_fork() has a shallow call graph. Make `msg'
> a local?
Yes it can be local.
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc3-mm2] connector: Add a fork connector
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> On Wed, 23 Feb 2005 01:07:47 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > >
> > > This patch replaces the relay_fork module and it implements a fork
> > > connector in the kernel/fork.c:do_fork() routine. The connector sends
> > > information about parent PID and child PID over a netlink interface. It
> > > allows to several user space applications to be informed when a fork
> > > occurs in the kernel. The main drawback is that even if nobody listens,
> > > message is send. I don't know how to avoid that.
> >
> > We really should find a way to fix that. Especially if we want all the
> > distributors to enable the connector in their builds (we do).
>
> Mesage is never reached anyone if there are no listeners, skb will be just
> freed,
> even without any linking.
> do_one_broadcast() in net/netlink/af_netlink.c takes care of it.
> Unicast message also will be discarded in cn_rx_skb().
We should assume that there will always be listeners. (why was the
connector thing added anyway? Its changelog is pathetic).
> These operations are quite cheap - just link/unlink skb to/from appropriate
> queues.
Please assume that will always be listening.
> > What happened to the idea of sending an on/off message down the netlink
> > socket?
>
> ?
All those emails I sent last week.
Arrange for the userspace daemon to send a message to the fork_connector
subsystem turning it on or off. So we can bypass all this code in the
common case where is listening, but your daemon is
not.
> > > + if (msg) {
> > > + memset(msg, '\0', size);
> >
> > Do we really need to memset the whole thing?
>
> Yes, to not leak kernel memory context.
How would we do that? There are no gaps in the payload and we tell netlink
the exact length.
> > > + memcpy(&msg->id, &fork_id, sizeof(msg->id));
> > > + msg->seq = seq++;
> >
> > `seq' needs a lock to protect it. Or use atomic_add_return(), maybe.
>
> Not necessary, I doubt fork userspace listener uses protocol described in
> connector.c and relies on seq field since it is not needed to have
> acks/replays.
> Although it can be used as a flag that it is new fork, but message itself
> is already such an event.
Without a lock you can have two messages with the same sequence number.
Even if the daemon which you're planning on implementing can handle that,
we shouldn't allow it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc4-mm1
Andrew Morton <[EMAIL PROTECTED]> disait derniÃrement que :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/
>
>
> - Various fixes and updates all over the place. Things seem to have slowed
> down a bit.
>
> - Last, final, ultimate call: if anyone has patches in here which are 2.6.11
> material, please tell me.
>
>
>
> Changes since 2.6.11-rc3-mm1:
[snip]
> +inotify.patch
>
> Not sure if this is the latest version.
it is the latest Robert Love posted against -mm kernels, but in
inotify_ignore():
static int inotify_ignore(struct inotify_device *dev, s32 wd)
{
struct inotify_watch *watch;
int ret = 0;
spin_lock(&dev->lock);
watch = dev_find_wd(dev, wd);
spin_unlock(&dev->lock); <- lock is released, but
if (!watch) {
ret = -EINVAL;
goto out;
}
__remove_watch(watch, dev); <-- must be called with lock held
out:
spin_unlock(&dev->lock); <- anyway, lock is
return ret; released and sub_preempt_count
} BUG's on SMP and PREEMPT
__remove_watch() must be called with ->lock held on dev.
Anyway, ->lock is released after label out.
Signed-off-by: Mathieu Segaud <[EMAIL PROTECTED]>
--- a/drivers/char/inotify.c 2005-02-23 11:55:21.321385752 +0100
+++ b/drivers/char/inotify.c 2005-02-23 11:55:29.772101048 +0100
@@ -952,7 +952,7 @@
spin_lock(&dev->lock);
watch = dev_find_wd(dev, wd);
- spin_unlock(&dev->lock);
+
if (!watch) {
ret = -EINVAL;
goto out;
--
> Can you explain this behaviour?
Yes
--
Alan
[Oh wait you want to know why...]
- Alan Cox on linux-kernel
Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
On Wed, 23 Feb 2005 02:58:06 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 23 Feb 2005 01:07:47 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello,
> > > >
> > > > This patch replaces the relay_fork module and it implements a fork
> > > > connector in the kernel/fork.c:do_fork() routine. The connector sends
> > > > information about parent PID and child PID over a netlink interface. It
> > > > allows to several user space applications to be informed when a fork
> > > > occurs in the kernel. The main drawback is that even if nobody listens,
> > > > message is send. I don't know how to avoid that.
> > >
> > > We really should find a way to fix that. Especially if we want all the
> > > distributors to enable the connector in their builds (we do).
> >
> > Mesage is never reached anyone if there are no listeners, skb will be just
> > freed,
> > even without any linking.
> > do_one_broadcast() in net/netlink/af_netlink.c takes care of it.
> > Unicast message also will be discarded in cn_rx_skb().
>
> We should assume that there will always be listeners. (why was the
> connector thing added anyway? Its changelog is pathetic).
>
> > These operations are quite cheap - just link/unlink skb to/from appropriate
> > queues.
>
> Please assume that originally written for> will always be listening.
>
> > > What happened to the idea of sending an on/off message down the netlink
> > > socket?
> >
> > ?
>
> All those emails I sent last week.
>
> Arrange for the userspace daemon to send a message to the fork_connector
> subsystem turning it on or off. So we can bypass all this code in the
> common case where is listening, but your daemon is
> not.
Ok, now I see(I'm not a fork connector author, so I did not receive them).
That will require to add real fork connector with callback routing.
Guillaume?
> > > > + if (msg) {
> > > > + memset(msg, '\0', size);
> > >
> > > Do we really need to memset the whole thing?
> >
> > Yes, to not leak kernel memory context.
>
> How would we do that? There are no gaps in the payload and we tell netlink
> the exact length.
Without memset kernel memory from slab cache will be sent to the userspace.
Neither kmalloc() itself nor cache does not prefill the allocated area.
> > > > + memcpy(&msg->id, &fork_id, sizeof(msg->id));
> > > > + msg->seq = seq++;
> > >
> > > `seq' needs a lock to protect it. Or use atomic_add_return(), maybe.
> >
> > Not necessary, I doubt fork userspace listener uses protocol described in
> > connector.c and relies on seq field since it is not needed to have
> > acks/replays.
> > Although it can be used as a flag that it is new fork, but message itself
> > is already such an event.
>
> Without a lock you can have two messages with the same sequence number.
> Even if the daemon which you're planning on implementing can handle that,
> we shouldn't allow it.
Yes, they can have the same number, but does it cost atomic/lock overhead?
Anyway, simple spin_lock() should be enough in do_fork() context.
Guillaume?
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> It shouldn't be. If one read writer is active, another should be able to
> come in, regardless of any pending writer trying to access it. At least
> that's always been the rule for the rw-spinlocks _exactly_ for this
> reaseon.
But not with rw-semaphores. I've designed them to be as fair as I can possibly
make them. This means holding reads up if there's a write pending.
> The rwsem code tries to be fairer, maybe it has broken this case in the
> name of fairness. I personally think fairness is overrated, and would
> rather have the rwsem implementation let readers come in.
I've seen writer starvation happening due to a continuous flow of overlapping
reads... That's one of the reasons I reimplemented rwsems.
Also, fair rwsems are easier to provide an assembly optimised form for that
doesn't involve the "thundering-herd" approach. Obviously, with the spinlock
approach, you can implement any semantics you desire once you're holding the
spinlock. With the optimised form as implemented, you can't determine how many
active readers there are. This information isn't stored anywhere.
> We have a notion of "atomic get_user()" calls, which is a lot more
> efficient, and is already used for other cases where we have _real_
> deadlocks (inode semaphore for reads into shared memory mappigns).
That's okay, provided the data you're trying to access isn't lurking on a disk
somewhere.
> > Auditing other read-takers of mmap_sem, I found one more exposure that
> > could be solved by just moving code around.
>
> DavidH - what's the word on nested read-semaphores like this? Are they
> supposed to work (like nested read-spinlocks), or do we need to do the
> things Olof does?
Nesting rwsems like this is definitely on the not-recommended list.
For the special case of the mmap semaphore, I'd advocate following something
like Jamie Lokier's solution, and note when a task holds its own mmap_sem
semaphore read-locked such that page-fault can avoid taking it again.
Something like:
struct task_struct {
...
unsigned mmsem_nest;
...
};
static inline void lock_mm_for_read(struct mm_struct *mm) {
if (current->mm == mm &&
current->mmsem_nest++ != 0)
;
else
down_read(&mm->mmap_sem);
}
static inline void unlock_mm_for_read(struct mm_struct *mm) {
if (current->mm == mm &&
--current->mmsem_nest != 0)
;
else
up_read(&mm->mmap_sem);
}
static inline void lock_mm_for_write(struct mm_struct *mm) {
down_write(&mm->mmap_sem);
}
static inline void unlock_mm_for_write(struct mm_struct *mm) {
up_write(&mm->mmap_sem);
}
Though I'd be tempted to say that faulting is the only case in which recursion
is permitted, and change the first two functions to reflect this and add an
extra pair specially for page-fault:
static inline void lock_mm_for_read(struct mm_struct *mm) {
down_read(&mm->mmap_sem);
if (current->mm == mm &&
current->flags |= PF_MMAP_SEM)
}
static inline void unlock_mm_for_read(struct mm_struct *mm) {
if (current->mm == mm &&
current->flags &= ~PF_MMAP_SEM)
up_read(&mm->mmap_sem);
}
static inline void lock_mm_for_fault(struct mm_struct *mm) {
if (!(current->flags & PF_MMAP_SEM))
down_read(&mm->mmap_sem);
}
static inline void unlock_mm_for_fault(struct mm_struct *mm) {
if (!(current->flags & PF_MMAP_SEM))
up_read(&mm->mmap_sem);
}
If current->mm is passed as the argument, the compiler's optimiser should
discard the first comparison in the if-statement.
Then futex.c would hold:
lock_mm_for_read(¤t->mm);
get_futex_key(...) etc.
queue_me(...) etc.
ret = get_user(...);
/* the rest */
unlock_mm_for_read(¤t->mm);
And do_page_fault() would hold:
lock_mm_for_fault(¤t->mm);
...
unlock_mm_for_fault(¤t->mm);
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Lse-tech] Re: A common layer for Accounting packages
Hi, Thanks for your comments. Andrew Morton wrote: >> Some process-aggregation model have own philosophy and implemantation, >> so it's hard to integrate. Thus, I think that common 'fork/exec/exit' event handling >> framework to implement any kinds of process-aggregation. > > > We really want to avoid doing such stuff in-kernel if at all possible, of > course. > > Is it not possible to implement the fork/exec/exit notifications to > userspace so that a daemon can track the process relationships and perform > aggregation based upon individual tasks' accounting? That's what one of > the accounting systems is proposing doing, I believe. > > (In fact, why do we even need the notifications? /bin/ps can work this > stuff out). It's hard to prove that we can't implement the process-aggregation only in user-space, but there are some difficulties on imaplementation, I think. For example, each process must have a tag or another identifier to explain what process-aggregation does it belong, but kernel does not support thoes kind of information, currently. Thus, we can't guarantee associating one process-aggregation with one process. # /proc//loginuid might be candidate, but it's out of original purpose. We might be able to make alike system, but is it hard to implement strict process-aggregation without any kernel supports? I think that well thought out kernel-modification is better than ad-hoc implementation on user-space. Thanks. -- Linux Promotion Center, NEC KaiGai Kohei <[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/
2.6.11-rc4-RT-V0.7.39-02 kernel BUG
Hi,
I'm back :) just shortly, to report an annoying kernel crash that
sometimes I'm experiencing at boot time on my laptop ([EMAIL PROTECTED]/UP),
running 2.6.11-rc4-RT-V0.7.39-02 (PREEMPT_RT=y, config attached).
This BUG is happening in some probabilistic fashion, like 1 on each 3
boots, rendering the whole USB subsystem completely unusable as the most
notable consequence.
Taken from dmesg (integral output is attached):
BUG: Unable to handle kernel paging request at virtual address 0811eb68
printing eip:
c0127927
*pde = 1e41d067
*pte =
Oops: [#1]
PREEMPT
Modules linked in: natsemi crc32 ohci1394 ieee1394 loop subfs evdev
ohci_hcd usbcore video thermal processor fan button battery ac
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010082 (2.6.11-rc4-RT-V0.7.39-02.0)
EIP is at change_owner+0x1a/0x5a
eax: de65c550 ebx: de65c550 ecx: 0811eb68 edx: df180550
esi: df0c3cc8 edi: df180a48 ebp: df0c3cc8 esp: de59ded0
ds: 007b es: 007b ss: 0068 preempt: 0004
Process IRQ 10 (pid: 1439, threadinfo=de59c000 task=df406000)
Stack: de65c550 df0c3cc8 df03ff70 df180550 c0127b5c de65c550 df0c3cc8
c0127d31
df03ff70 0286 de59c000 de558000 0001
0001
c01283f5 e00d4400 e00c2cb0 0001 de55a4d4 e00b0bf6 0001
0017
Call Trace:
[] set_new_owner+0x17/0x2b (20)
[] __up_mutex+0xa4/0x193 (12)
[] up+0x35/0x3d (36)
[] highlevel_host_reset+0x3b/0x49 [ieee1394] (8)
[] ohci_irq_handler+0x576/0x713 [ohci1394] (12)
[] __sched_text_start+0x5a/0x5d7 (28)
[] __do_IRQ+0xca/0x180 (4)
[] handle_IRQ_event+0x5c/0xc8 (36)
[] do_hardirq+0x61/0x112 (48)
[] do_sched_setscheduler+0x73/0xa0 (4)
[] do_irqd+0x0/0x96 (20)
[] do_irqd+0x66/0x96 (4)
[] kthread+0x94/0xc8 (28)
[] kthread+0x0/0xc8 (16)
[] kernel_thread_helper+0x5/0xb (16)
Code: 8b 6c 24 18 83 c4 1c c3 b8 da ff ff ff c3 90 90 c3 55 39 ca 89 c5 57
89 c8 56 53 74 49 8b 8a f8 04 00 00 8d ba f8 04 00 00 39 cf <8b> 19 74 37
8d b0 f8 04 00 00 eb 08 89 d9 8b 1b 39 cf 74 27 39
<6>note: IRQ 10[1439] exited with preempt_count 3
BUG: scheduling while atomic: IRQ 10/0x0003/1439
caller is do_exit+0x1da/0x34d
[] __sched_text_start+0x48e/0x5d7 (8)
[] exit_notify+0x60b/0x8f4 (24)
[] vprintk+0x101/0x142 (24)
[] do_exit+0x1da/0x34d (32)
[] do_trap+0x0/0xfe (40)
[] do_page_fault+0x0/0x524 (48)
[] do_page_fault+0x0/0x524 (12)
[] do_page_fault+0x346/0x524 (4)
[] preempt_schedule+0x50/0x6b (80)
[] try_to_wake_up+0x104/0x106 (20)
[] dma_trm_reset+0x36/0x11e [ohci1394] (24)
[] __wake_up_common+0x35/0x55 (16)
[] do_page_fault+0x0/0x524 (60)
[] error_code+0x2b/0x30 (8)
[] change_owner+0x1a/0x5a (44)
[] set_new_owner+0x17/0x2b (28)
[] __up_mutex+0xa4/0x193 (12)
[] up+0x35/0x3d (36)
[] highlevel_host_reset+0x3b/0x49 [ieee1394] (8)
[] ohci_irq_handler+0x576/0x713 [ohci1394] (12)
[] __sched_text_start+0x5a/0x5d7 (28)
[] __do_IRQ+0xca/0x180 (4)
[] handle_IRQ_event+0x5c/0xc8 (36)
[] do_hardirq+0x61/0x112 (48)
[] do_sched_setscheduler+0x73/0xa0 (4)
[] do_irqd+0x0/0x96 (20)
[] do_irqd+0x66/0x96 (4)
[] kthread+0x94/0xc8 (28)
[] kthread+0x0/0xc8 (16)
[] kernel_thread_helper+0x5/0xb (16)
prev->state: 2 != TASK_RUNNING??
IRQ 10/1439: BUG in __schedule at kernel/sched.c:3028
[] __sched_text_start+0x3fd/0x5d7 (8)
[] do_exit+0x1da/0x34d (80)
[] do_trap+0x0/0xfe (40)
[] do_page_fault+0x0/0x524 (48)
[] do_page_fault+0x0/0x524 (12)
[] do_page_fault+0x346/0x524 (4)
[] preempt_schedule+0x50/0x6b (80)
[] try_to_wake_up+0x104/0x106 (20)
[] dma_trm_reset+0x36/0x11e [ohci1394] (24)
[] __wake_up_common+0x35/0x55 (16)
[] do_page_fault+0x0/0x524 (60)
[] error_code+0x2b/0x30 (8)
[] change_owner+0x1a/0x5a (44)
[] set_new_owner+0x17/0x2b (28)
[] __up_mutex+0xa4/0x193 (12)
[] up+0x35/0x3d (36)
[] highlevel_host_reset+0x3b/0x49 [ieee1394] (8)
[] ohci_irq_handler+0x576/0x713 [ohci1394] (12)
[] __sched_text_start+0x5a/0x5d7 (28)
[] __do_IRQ+0xca/0x180 (4)
[] handle_IRQ_event+0x5c/0xc8 (36)
[] do_hardirq+0x61/0x112 (48)
[] do_sched_setscheduler+0x73/0xa0 (4)
[] do_irqd+0x0/0x96 (20)
[] do_irqd+0x66/0x96 (4)
[] kthread+0x94/0xc8 (28)
[] kthread+0x0/0xc8 (16)
[] kernel_thread_helper+0x5/0xb (16)
Please, feel free to ask me for anything else, if relevant to get rid of
this casual crash behavior. I'm already running the RT patch/kernel 100%
of the time, on all my boxes, althought I have no record of this happening
on my other [EMAIL PROTECTED]/HT(SMP) box.
Cheers.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
Linux version 2.6.11-rc4-RT-V0.7.39-02.0 ([EMAIL PROTECTED]) (gcc version 3.4.1
(Mandrakelinux 10.1 3.4.1-4mdk)) #1 Tue Feb 15 09:37:36 WET 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009f800 (usable)
BIOS-e820: 0009f800 - 000a (reserved)
BIOS-e820: 000dc000 - 0010 (reserved)
BIOS-e820: 0010 - 1f77 (usable)
BIOS-e820: 1f77 - 1f77f000 (ACPI data)
BIOS-e820:
Re: [PATCH/RFC] Futex mmap_sem deadlock
Linus Torvalds <[EMAIL PROTECTED]> wrote: > That is uglee. True. You could just wrap it up in inline functions and hide it in a header file as I suggested in the email I've just sent. > We really have this already, and it's called "current->preempt". It > handles any lock at all, and doesn't add yet another special case to all > the architectures. > > Just do > > repeat: Alternately, you could just have do_page_fault() do: while (!down_read_trylock(¤t->mm->mmap_sem)) continue; However, note that this can suffer from starvation due to a never ending flow of mixed write-locks and read-locks on other CPUs. Unlikely, true, but not impossible. There is yet another way, now that I think about it... Another rwsem could be added to mm_struct, one that you have to get immediately before mmap_sem and release immediately after; one that page fault doesn't ever touch... but that isn't very pleasant either:-/ A yet further way would be to make a second kind of rwsem; one that's unfair. But if you do that, a few threads that're swapping a lot, combined with a few tops could starve out another thread that's trying to do an mmap... Actually, there's an added benefit to your suggested method... It doesn't involve changing what's in task_struct or mm_struct and doesn't involve changing the semantics of the mmap_sem lock. > That's assuming we can't just make rwsem's nest nicely. rwsems themselves? No, not really. It'd either mean keeing track of which task holds what sort of lock on every rwsem (which'd be nice for debugging, granted; but not something you really want in a normal system), or it'd mean making rwsems unfair - something I think will be a really bad idea. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
Andrew Morton <[EMAIL PROTECTED]> wrote: > wrt this down_read/down_write/down_read deadlock: iirc, the reason why > down_write() takes precedence over down_read() is to avoid the permanent > writer starvation which would occur if there is heavy down_read() traffic. down_write() doesn't actually take precedence over down_read() as such. The rwsems try to implement a strict FIFO queue (the fairness thing). David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
> - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 > material, please tell me. I guess that depends on how you define 2.6.11 material at this point, but I have a few patches that I wrote in there, that I think are potential candidates due to them being fairly trivial, obviously correct and not having caused any problems since entering -mm. Those patches might as well get merged into 2.6.11 now and get out of your queue/hair. The patches I have in mind are these: fix-placement-of-static-inline-in-nfsdh.patch -- This one has no actual impact on the generated code, it just kills a few warnings when building with gcc -W, so merging that up should be harmless. kyrofb-copy__user-return-value-checks-added-to-kyro-fb.patch -- This one just adds a few return value checks to copy_*_user calls and returns -EFAULT when failing. I've seen no complains about the patch on the list and it seems to be the obviously correct thing to do - might as well get merged. warning-fix-in-drivers-cdrom-mcdc.patch -- Trivial, obviously correct, warning fix to an ancient driver. No point in having you carry it around in -mm, let's just merge it. make-loglevels-in-init-mainc-a-little-more-sane.patch -- This one just changes a few loglevels, so the potential for breakage is extremely low. Besides I believe I've argued the case for the new loglevels being more sane than the old ones well enough, and noone has complained about the patch. The patches above are all very low risk, so they shouldn't cause any problems for 2.6.11. Let us merge them now to a) get the bennefit of them in 2.6.11 and b) get them out of your -mm queue. nitpick note: despite some of these patches having From: lines in them in your -mm patch set that list other people they where all written by me. Other people getting listed as From: (and thus later as patch author in the changelogs and bk) seems to happen when other people resend the patches to the list or when they pass through maintainers before they reach you. Just to set the record straight; I initially wrote the patches above. Kind regards, Jesper Juhl <[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/
Slightly OT: We should move linux related channels off of FreeNode
Today lilo (the FreeNode network owner) has decided to make one step away in a direction opposite of freedom, and banned all Tor users from the FreeNode network. Tor ( http://tor.eff.org ) is an open source anonymous gateway system. Many users who are not in the position to be able to use IRC otherwise (such as those who live in countries who do not believe in free speech) now cannot use Freenode any longer. Do we want to use an IRC network that no longer supports freedom? Our only option is to move to another network, such as irc.noderebellion.net or irc.oftc.net. Channels such as #kernelnewbies have already moved to oftc due to lilo's past actions. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpJ5asJtRHBB.pgp Description: PGP signature
Re: [PATCH] TCP-Hybla proposal
On Tue, 22 Feb 2005 09:42:19 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > Probably the best long term solution is to make the protocol choice > be a property of the destination cache [..] > The protocol choices are mutually exclusive, if you walk through the code > (or do experiments), you find that that only one gets used. As part of the > longer term plan, I would like to: > - have one sysctl > - choice by route and destination > - union for fields in control block I think it should be nice if we substitute in the struct tcp_opt all the structs related to the congestion control algorithms with a more generic one which could be initialized when the connection is open by reading just one sysctl which defines the algorithm to be used. This could allow later even a user-space application to set the congestion control it desires to use. > Is there interest in setting up a semi official "-tcp" tree to hold these? > because it might not be of wide interest or stability to be ready for mainline > kernel. I perfectly agree. -- Angelo Dell'Aera 'buffer' Antifork Research, Inc. http://buffer.antifork.org Metro Olografix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 tracking down problem --- endless loop in __find_get_block_slow
> > dd if=/dev/zero of=/mnt/testfile count=N, N>6 It turns out N>6 is variable. But large enough and it will hang. Sugests some kind of race I am afraid. > > I get into an endless loop in __find_get_block_slow. > > The only way in which __find_get_block_slow() can loop is if something > wrecked the buffer_head ring at page->private: something caused an internal > loop via bh->b_this_page. > > Are you sure that's where things are hanging? That it's not stuck on a > spinlock? I get the same message again and again all over (this trace with count=100 and a BUG() and panic inserted into buffer.c) Feb 23 13:38:34 localhost kernel: __find_get_block_slow() failed. block=101, b_blocknr=100 Feb 23 13:38:34 localhost kernel: b_state=0x0010, b_size=2048 Feb 23 13:38:34 localhost kernel: device blocksize: 2048 Ad inf. The output of the BUG() is show below. My questions remain: 1. Whos fault is this? 2. How do I fix/avoid this problem? Regards Thomas __find_get_block_slow() failed. block=101, b_blocknr=100 b_state=0x0010, b_size=2048 device blocksize: 2048 [ cut here ] DEBUG_PAGEALLOC Modules linked in: ufs sha512 aes_i586 dm_bde md5 ipv6 af_packet evdev ehci_hcd usbcore agpgart dm_mod rtc unix CPU:0 EIP: 0060:[__find_get_block_slow+202/304]Not tainted EFLAGS: 00010286 (2.6.8) EIP is at __find_get_block_slow+0xca/0x130 eax: 0017 ebx: dcd21208 ecx: c02c6950 edx: 41e4 esi: c138d600 edi: 0065 ebp: da63aed0 esp: da7e9c54 ds: 007b es: 007b ss: 0068 Process dd (pid: 1742, threadinfo=da7e8000 task=dc76da70) Stack: c029a003 0800 0800 0064 da63ae6c 0065 0800 c014ab5f da63ae6c 0065 0800 0800 0065 da63ae6c da764df8 c014abdb da63ae6c 0065 0800 Call Trace: [__find_get_block+95/176] __find_get_block+0x5f/0xb0 [__getblk+43/96] __getblk+0x2b/0x60 [pg0+542048932/1070055424] ufs_new_fragments+0x1c4/0x740 [ufs] [pg0+542070875/1070055424] ufs_inode_getfrag+0x23b/0x3f0 [ufs] [pg0+542072873/1070055424] ufs_getfrag_block+0x349/0x3b0 [ufs] [create_empty_buffers+37/128] create_empty_buffers+0x25/0x80 [__block_prepare_write+467/960] __block_prepare_write+0x1d3/0x3c0 [kernel_map_pages+40/144] kernel_map_pages+0x28/0x90 [inode_update_time+167/224] inode_update_time+0xa7/0xe0 [block_prepare_write+52/80] block_prepare_write+0x34/0x50 [pg0+542072032/1070055424] ufs_getfrag_block+0x0/0x3b0 [ufs] [generic_file_aio_write_nolock+821/2624] generic_file_aio_write_nolock+0x335/0xa40 [pg0+542072032/1070055424] ufs_getfrag_block+0x0/0x3b0 [ufs] [do_no_page+99/688] do_no_page+0x63/0x2b0 [generic_file_write_nolock+116/144] generic_file_write_nolock+0x74/0x90 [clear_user+51/80] clear_user+0x33/0x50 [read_zero+452/528] read_zero+0x1c4/0x210 [generic_file_write+85/112] generic_file_write+0x55/0x70 [generic_file_write+0/112] generic_file_write+0x0/0x70 [vfs_write+184/304] vfs_write+0xb8/0x130 [copy_to_user+62/80] copy_to_user+0x3e/0x50 [sys_write+81/128] sys_write+0x51/0x80 [syscall_call+7/11] syscall_call+0x7/0xb Code: 0f 0b 15 02 c2 9f 29 c0 8b 06 f6 c4 08 75 17 8b 46 04 40 74 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 tracking down problem --- endless loop in __find_get_block_slow
[EMAIL PROTECTED] (Thomas S. Iversen) wrote:
>
> > > dd if=/dev/zero of=/mnt/testfile count=N, N>6
>
> It turns out N>6 is variable. But large enough and it will hang. Sugests
> some kind of race I am afraid.
>
> > > I get into an endless loop in __find_get_block_slow.
> >
> > The only way in which __find_get_block_slow() can loop is if something
> > wrecked the buffer_head ring at page->private: something caused an internal
> > loop via bh->b_this_page.
> >
> > Are you sure that's where things are hanging? That it's not stuck on a
> > spinlock?
>
> I get the same message again and again all over (this trace with
> count=100 and a BUG() and panic inserted into buffer.c)
>
> Feb 23 13:38:34 localhost kernel: __find_get_block_slow() failed.
> block=101, b_blocknr=100
> Feb 23 13:38:34 localhost kernel: b_state=0x0010, b_size=2048
> Feb 23 13:38:34 localhost kernel: device blocksize: 2048
OK, so we're looking for the buffer_head for block 101 and the first
buffer_head which is attached to the page represents block 100. So the
next buffer_head _should_ represent block 101. Please print it out:
--- 25/fs/buffer.c~a2005-02-23 04:06:12.0 -0800
+++ 25-akpm/fs/buffer.c 2005-02-23 04:06:51.0 -0800
@@ -459,8 +459,10 @@ __find_get_block_slow(struct block_devic
*/
if (all_mapped) {
printk("__find_get_block_slow() failed. "
- "block=%llu, b_blocknr=%llu\n",
- (unsigned long long)block, (unsigned long
long)bh->b_blocknr);
+ "block=%llu, b_blocknr=%llu, next=%llu\n",
+ (unsigned long long)block,
+ (unsigned long long)bh->b_blocknr,
+ (unsigned long long)bh->b_this_page->b_blocknr);
printk("b_state=0x%08lx, b_size=%u\n", bh->b_state, bh->b_size);
printk("device blocksize: %d\n", 1 << bd_inode->i_blkbits);
}
_
> Ad inf. The output of the BUG() is show below. My questions remain:
>
> 1. Whos fault is this?
Could be UFS. But what does "transparent block encryption and sector
shuffling" mean? How is the sector shuffling implemented?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [NET]: Add sock_create_kern()
On 2004-05-08 at 22:00, James Morris wrote: > Under SELinux, and potentially other LSMs, we need > to be able to distinguish between user sockets and > kernel sockets. For SELinux specifically, kernel > sockets need to be specially labeled during > creation, then bypass access control checks (they > are controlled by the kernel itself and not subject > to SELinux mediation). Do both user sockets and kernel sockets have a socket structure and a corresponding sock structure (i.e. a BSD socket and a INET socket) with them? In 8.1.1 of "Integrating Flexible Support for Security Policies into the Linux Operating System", It says: "The Linux network component creates two special purpose sockets for use by the AF_INET protocol family. The tcp socket is used to send resets when a TCP packet is rejected, since there may be no local socket corresponding to the packet. The icmp socket is used to send ICMP messages.Two initial SIDs were defined for these sockets, with the corresponding security context determined by the security server." Does the "local socket" here refer to the "user socket" as you mentioned above? Thank you very much. = Best Regards, Park Lee __ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
Hi, I wrote a kernel tool for my personnal usage which goal is to keep a record of recent task preemptions and interruptions that appears under linux. Either for debugging through KDB, or for monitoring/analyze with a graphics representation. as adviced, SourceForge project is now opened: http://sourceforge.net/projects/kernelanalyzer/ Best regards, Sylvain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Determine SCx200 CB address at run-time
The current SCx200 drivers use a fixed base address of 0x9000 for the
Configuration Block, but some systems (at least the Soekris net4801)
uses a base address of 0x6000. This patch first tries the fixed address
then - if no configuration block could be found - tries the address
written to the Configuration Block Address Scratchpad register by the
BIOS.
Signed-off-by: Henrik Brix Andersen <[EMAIL PROTECTED]>
---
--- linux-2.6.11-rc4/arch/i386/kernel/scx200.c.orig 2005-02-22
12:44:24.0 +0100
+++ linux-2.6.11-rc4/arch/i386/kernel/scx200.c 2005-02-23 11:48:39.0
+0100
@@ -13,6 +13,9 @@
#include
+/* Verify that the configuration block really is there */
+#define scx200_cb_probe(base) (inw((base) + SCx200_CBA) == (base))
+
#define NAME "scx200"
MODULE_AUTHOR("Christer Weinigel <[EMAIL PROTECTED]>");
@@ -22,9 +25,13 @@ MODULE_LICENSE("GPL");
unsigned scx200_gpio_base = 0;
long scx200_gpio_shadow[2];
+unsigned scx200_cb_base = 0;
+
static struct pci_device_id scx200_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_SCx200_BRIDGE) },
{ PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_SC1100_BRIDGE) },
+ { PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_SCx200_XBUS) },
+ { PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_SC1100_XBUS) },
{ },
};
MODULE_DEVICE_TABLE(pci,scx200_tbl);
@@ -45,22 +52,39 @@ static int __devinit scx200_probe(struct
int bank;
unsigned base;
- base = pci_resource_start(pdev, 0);
- printk(KERN_INFO NAME ": GPIO base 0x%x\n", base);
-
- if (request_region(base, SCx200_GPIO_SIZE, "NatSemi SCx200 GPIO") == 0)
{
- printk(KERN_ERR NAME ": can't allocate I/O for GPIOs\n");
- return -EBUSY;
+ if (pdev->device == PCI_DEVICE_ID_NS_SCx200_BRIDGE ||
+ pdev->device == PCI_DEVICE_ID_NS_SC1100_BRIDGE) {
+ base = pci_resource_start(pdev, 0);
+ printk(KERN_INFO NAME ": GPIO base 0x%x\n", base);
+
+ if (request_region(base, SCx200_GPIO_SIZE, "NatSemi SCx200
GPIO") == 0) {
+ printk(KERN_ERR NAME ": can't allocate I/O for
GPIOs\n");
+ return -EBUSY;
+ }
+
+ scx200_gpio_base = base;
+
+ /* read the current values driven on the GPIO signals */
+ for (bank = 0; bank < 2; ++bank)
+ scx200_gpio_shadow[bank] = inl(scx200_gpio_base + 0x10
* bank);
+
+ } else {
+ /* find the base of the Configuration Block */
+ if (scx200_cb_probe(SCx200_CB_BASE_FIXED)) {
+ scx200_cb_base = SCx200_CB_BASE_FIXED;
+ } else {
+ pci_read_config_dword(pdev, SCx200_CBA_SCRATCH, &base);
+ if (scx200_cb_probe(base)) {
+ scx200_cb_base = base;
+ } else {
+ printk(KERN_WARNING NAME ": Configuration Block
not found\n");
+ return -ENODEV;
+ }
+ }
+ printk(KERN_INFO NAME ": Configuration Block base 0x%x\n",
scx200_cb_base);
}
- scx200_gpio_base = base;
-
- /* read the current values driven on the GPIO signals */
- for (bank = 0; bank < 2; ++bank)
- scx200_gpio_shadow[bank] = inl(scx200_gpio_base + 0x10 * bank);
-
return 0;
-
}
u32 scx200_gpio_configure(int index, u32 mask, u32 bits)
@@ -134,6 +158,7 @@ EXPORT_SYMBOL(scx200_gpio_shadow);
EXPORT_SYMBOL(scx200_gpio_lock);
EXPORT_SYMBOL(scx200_gpio_configure);
EXPORT_SYMBOL(scx200_gpio_dump);
+EXPORT_SYMBOL(scx200_cb_base);
/*
Local variables:
--- linux-2.6.11-rc4/drivers/mtd/maps/scx200_docflash.c.orig2005-02-22
14:27:59.0 +0100
+++ linux-2.6.11-rc4/drivers/mtd/maps/scx200_docflash.c 2005-02-22
16:12:00.0 +0100
@@ -92,17 +92,16 @@ static int __init init_scx200_docflash(v
PCI_DEVICE_ID_NS_SCx200_BRIDGE,
NULL)) == NULL)
return -ENODEV;
-
- if (!scx200_cb_probe(SCx200_CB_BASE)) {
- printk(KERN_WARNING NAME ": no configuration block found\n");
+
+ /* check that we have found the configuration block */
+ if (!scx200_cb_present())
return -ENODEV;
- }
if (probe) {
/* Try to use the present flash mapping if any */
pci_read_config_dword(bridge, SCx200_DOCCS_BASE, &base);
pci_read_config_dword(bridge, SCx200_DOCCS_CTRL, &ctrl);
- pmr = inl(SCx200_CB_BASE + SCx200_PMR);
+ pmr = inl(scx200_cb_base + SCx200_PMR);
if (base == 0
|| (ctrl & 0x0700) != 0x0700
@@ -155,14 +154,14 @@ static int __init init_scx200_docflash(v
pci_w
Re: Help tracking down problem --- endless loop in __find_get_block_slow
> OK, so we're looking for the buffer_head for block 101 and the first > buffer_head which is attached to the page represents block 100. So the > next buffer_head _should_ represent block 101. Please print it out: Not quite the same, but simelar: Feb 23 14:50:24 localhost kernel: __find_get_block_slow() failed. block=102, b_blocknr=128, next=129 Feb 23 14:50:24 localhost kernel: b_state=0x0013, b_size=2048 Feb 23 14:50:24 localhost kernel: device blocksize: 2048 Feb 23 14:50:24 localhost kernel: [ cut here ] > Could be UFS. But what does "transparent block encryption and sector > shuffling" mean? How is the sector shuffling implemented? GDBE is a block level encrypter. It encrypts the actual sectors transparently via the GEOM API (corresponds to the devicemapper api in linux). GBDE assigns a key for each block, thereby introducing keysectors. Furthermore the sectors are remapped so that one can not guess where e.g. metadata is located on the physical disk. It is a rather simple remap: Taken from GDBE: /* * Convert an unencrypted side offset to offsets on the encrypted side. * * Security objective: Make it harder to identify what sectors contain what * on a "cold" disk image. * * We do this by adding the "keyoffset" from the lock to the physical sector * number modulus the available number of sectors. Since all physical sectors * presumably look the same cold, this will do. * * As part of the mapping we have to skip the lock sectors which we know * the physical address off. We also truncate the work packet, respecting * zone boundaries and lock sectors, so that we end up with a sequence of * sectors which are physically contiguous. * * Shuffling things further is an option, but the incremental frustration is * not currently deemed worth the run-time performance hit resulting from the * increased number of disk arm movements it would incur. * * This function offers nothing but a trivial diversion for an attacker able * to do "the cleaning lady attack" in its current static mapping form. */" Further reading: http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf Regards Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 : IDE crazy numbers, hdb renumbered to hdq ?
This kernel came up, but my boot script complained about no /dev/hdb3 when trying to mount /var. (I have two IDE disks on the same cable, and an IDE cdrom on another.) They are usually hda, hdb, and hdc. MAKEDEV hdq did not help. Looking at sysfs, it turns out that /dev/hdq1 is at major:3 minor:1025 if I interpret things right. (/dev/hda1 is at 3:1, which is correct.) These numbers did not work with my mknod, it created 7:1 instead. So I didn't get to test this mysterious device. But I assume this is a mistake of some sort, I haven't heard about any change in the IDE numbering coming up? 2.6.1-rc3-mm1 works as expected. It may be interesting to note that my root raid-1 came up fine, consisting of hdq1 and hda1 instead of the usual hdb1 and hda1. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: OT: Why is usb data many times the cpu hog that firewire is?
Matt Mackall wrote: [...] JPEG data is DCT of 8x8 pixel chunks. If you can get at that, you can compare the DC terms of each chunk with minimal decoding. Various thumbnailers do this for speed already. I really doubt that this would work. It seems to me that you can have very different DC terms with very similar results. In other words, even a little noise in the picture might produce very different DC terms. Instead of comparing the DC terms, you could compare just the luminance. You would have to decompress just half the data for that and you wouldn't need to make the YUV->RGB conversion. That would probably save a few cycles. -- Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mouse still losing sync and thus jumping around
Hi! I still get the following messages and my mouse jumps around weirdly making work rather difficult regardless of which 2.6 kernel I use (tried 2.6.8, 2.6.9, 2.6.10, 2.6.11-rc2 with patch-see below, 2.6.11-rc4): psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 2 bytes away. psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing 2 bytes away. psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 (using either the touchpad or the connected PS/2 mouse) I tried the patch Dmitry Torokhov supplied in the message with subject "Re: Really annoying bug in the mouse driver" from Jan 27 which supposedly fixes this problem. unfortunately it only got worse. the problem is really annoying with windows sometimes closing because of sporadic mouse clicks etc. I would happily try patches and help in debugging, so if anyone has an idea or if more info about my setup/config is needed, just tell me. thanks a lot, Nils - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.10-ck6
These are patches designed to improve system responsiveness. It is configurable to any workload but the default ck* patch is aimed at the desktop and ck*-server is available with more emphasis on serverspace. This is a maintenance release and is identical to 2.6.10-ck5 apart from using 2.6.10-as5 with it's updated security and bugfixes for 2.6.10 (thanks to Andres Salomon for maintaining this). http://ck.kolivas.org/patches/2.6/2.6.10/2.6.10-ck6/ Full patchlist: patch-2.6.10-as5 2.6.10_to_staircase9.2.diff schedrange.diff schedbatch2.6.diff schediso2.8.diff mwII.diff 1g_lowmem1_i386.diff defaultcfq.diff 2.6.10-mingoll.diff cddvd-cmdfilter-drop.patch vm-pageout-throttling.patch nvidia_6111-6629_compat2.diff fix-ll-resume.diff s9.2_s9.3.diff i2.8_i2.9.diff s9.3_s9.4.diff i2.9_i2.10.diff b2.6_b2.7.diff s9.4_s10.diff s10_test1.diff s10_s10.1.diff s10.1_s10.2.diff s10.2_s10.3.diff 1504_vmscan-writeback-pages.patch s10.3_s10.4.diff s10.4_s10.5.diff 2610ck6-version.diff and available separately: supermount-ng208-10ck5.diff Cheers, Con signature.asc Description: OpenPGP digital signature
Re: uninterruptible sleep lockups
On Wed, 23 Feb 2005, Bodo Eggert wrote: linux-os <[EMAIL PROTECTED]> wrote: You don't seem to understand. A process that's stuck in 'D' state shows a SEVERE error, usually with a hardware driver. Or a network filesystem mount to a no longer existing server or share. But that's a whole different problem. That's a systemic problem of "fail-over". Network file-systems really need to interface with an intermediate virtual device that can isolate failed systems and make them look "perfect" to individual machines. If you don't do this, then as soon as somebody trips over a wire, your database is trashed. I'm surprised that NFS, PCNFS, SMB, etc., actually work as well as everybody seems to think they do. Until the architectural problem is resolved, there are still going to be hung processes, trashed databases, etc. For instance, somebody may have coded something in a critical section that will wait forever for some bit to be set when, in fact, that bit may never be set because of a hardware glitch. Such problems must be found. One can't just suck some process out of the 'D' state. But you can easily fall into one, e.g. by mounting a SMB share to ~/mnt, working until after the windows box breaks down and trying to save the work of the last hour (which involves enumerating and stat()ing all entries in ~). Yes. See above. The 'D' state usually stands for 'Down' where a task was 'down()' on a semaphore. To get out of that state, that task (and none other) needs to execute `up()`. This means that whatever that task was waiting for needs to happen or it won't call 'up()'. Maybe the device/mountpoint causing the processes to hang can be declared dead (This is the more important part to me) and/or the syscall can be forced to fail. If it involves wasting some MB of RAM for copying all possibly affected memory in order to avoid corrupting used RAM, that will be the price to pay for not losing your data. That's not how it's done. How to clean up the stuck processes: (This requires a MMU) Add an error path to each syscall (or create some generic error paths) and keep the original stack frame. On errors, you can "longjump" (not exactly, but similar) to the error path after copying the memory. The semaphore will not be taken, and the code depending on the semaphore will not be executed. Again, you are attacking the symptom. The problem could be resolved by using a local disk (or a disk file) for the immediate I/O and the I/O to the file-servers could occur whenever they are available. It's just ordinary transaction processing. Nothing new. It's just that people continue to use primitive garbage (really, usually developed by amateur hackers with no formal education) that is then specified by the likes of Microsoft and then, to be compatible, other operating systems create clones with the same kinds of unfixable bugs. BTW: Your Reply-To: should be omited if it's equal to the From: The problem with From: is this machine is not "known" to the outside world, although somebody has entries in the auth02.ns.uu.net name-server that claims to be my machine, which gets cached and cloned everywhere. Mail to this system needs to go to the Reply-To: address. Our network "experts" here have tried to track down the bad name-server entry and they say it's not here. All of my machine names mysteriously appear in auth02.ns.uu.net with 204.178.40.nnn IP addresses. This really screws up email because email tries to verify the sender by contacting those bogus addresses. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] pdirops: vfs patch
> Jan Blunck (JB) writes: JB> Nope, d_alloc() is setting d_flags to DCACHE_UNHASHED. Therefore it is not found JB> by __d_lookup() until it is rehashed which is implicit done by ->lookup(). that means we can have two processes allocated dentry for same name. they'll call ->lookup() each against own dentry, fill them and hash. so, we'll get two equal dentries. is that OK? thanks, Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-RT-V0.7.39-02 kernel BUG
Rui Nuno Capela wrote: Hi, I'm back :) just shortly, to report an annoying kernel crash that sometimes I'm experiencing at boot time on my laptop ([EMAIL PROTECTED]/UP), running 2.6.11-rc4-RT-V0.7.39-02 (PREEMPT_RT=y, config attached). This BUG is happening in some probabilistic fashion, like 1 on each 3 boots, rendering the whole USB subsystem completely unusable as the most notable consequence. Taken from dmesg (integral output is attached): BUG: Unable to handle kernel paging request at virtual address 0811eb68 printing eip: c0127927 *pde = 1e41d067 *pte = Oops: [#1] PREEMPT Modules linked in: natsemi crc32 ohci1394 ieee1394 loop subfs evdev ohci_hcd usbcore video thermal processor fan button battery ac CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010082 (2.6.11-rc4-RT-V0.7.39-02.0) EIP is at change_owner+0x1a/0x5a eax: de65c550 ebx: de65c550 ecx: 0811eb68 edx: df180550 esi: df0c3cc8 edi: df180a48 ebp: df0c3cc8 esp: de59ded0 ds: 007b es: 007b ss: 0068 preempt: 0004 Process IRQ 10 (pid: 1439, threadinfo=de59c000 task=df406000) Stack: de65c550 df0c3cc8 df03ff70 df180550 c0127b5c de65c550 df0c3cc8 c0127d31 df03ff70 0286 de59c000 de558000 0001 0001 c01283f5 e00d4400 e00c2cb0 0001 de55a4d4 e00b0bf6 0001 0017 Call Trace: [] set_new_owner+0x17/0x2b (20) [] __up_mutex+0xa4/0x193 (12) [] up+0x35/0x3d (36) [] highlevel_host_reset+0x3b/0x49 [ieee1394] (8) [] ohci_irq_handler+0x576/0x713 [ohci1394] (12) [] __sched_text_start+0x5a/0x5d7 (28) [] __do_IRQ+0xca/0x180 (4) [] handle_IRQ_event+0x5c/0xc8 (36) [] do_hardirq+0x61/0x112 (48) [] do_sched_setscheduler+0x73/0xa0 (4) [] do_irqd+0x0/0x96 (20) [] do_irqd+0x66/0x96 (4) [] kthread+0x94/0xc8 (28) [] kthread+0x0/0xc8 (16) [] kernel_thread_helper+0x5/0xb (16) Code: 8b 6c 24 18 83 c4 1c c3 b8 da ff ff ff c3 90 90 c3 55 39 ca 89 c5 57 89 c8 56 53 74 49 8b 8a f8 04 00 00 8d ba f8 04 00 00 39 cf <8b> 19 74 37 8d b0 f8 04 00 00 eb 08 89 d9 8b 1b 39 cf 74 27 39 <6>note: IRQ 10[1439] exited with preempt_count 3 BUG: scheduling while atomic: IRQ 10/0x0003/1439 caller is do_exit+0x1da/0x34d [] __sched_text_start+0x48e/0x5d7 (8) [] exit_notify+0x60b/0x8f4 (24) [] vprintk+0x101/0x142 (24) [] do_exit+0x1da/0x34d (32) [] do_trap+0x0/0xfe (40) [] do_page_fault+0x0/0x524 (48) [] do_page_fault+0x0/0x524 (12) [] do_page_fault+0x346/0x524 (4) [] preempt_schedule+0x50/0x6b (80) [] try_to_wake_up+0x104/0x106 (20) [] dma_trm_reset+0x36/0x11e [ohci1394] (24) [] __wake_up_common+0x35/0x55 (16) [] do_page_fault+0x0/0x524 (60) [] error_code+0x2b/0x30 (8) [] change_owner+0x1a/0x5a (44) [] set_new_owner+0x17/0x2b (28) [] __up_mutex+0xa4/0x193 (12) [] up+0x35/0x3d (36) [] highlevel_host_reset+0x3b/0x49 [ieee1394] (8) [] ohci_irq_handler+0x576/0x713 [ohci1394] (12) [] __sched_text_start+0x5a/0x5d7 (28) [] __do_IRQ+0xca/0x180 (4) [] handle_IRQ_event+0x5c/0xc8 (36) [] do_hardirq+0x61/0x112 (48) [] do_sched_setscheduler+0x73/0xa0 (4) [] do_irqd+0x0/0x96 (20) [] do_irqd+0x66/0x96 (4) [] kthread+0x94/0xc8 (28) [] kthread+0x0/0xc8 (16) [] kernel_thread_helper+0x5/0xb (16) prev->state: 2 != TASK_RUNNING?? IRQ 10/1439: BUG in __schedule at kernel/sched.c:3028 [] __sched_text_start+0x3fd/0x5d7 (8) [] do_exit+0x1da/0x34d (80) [] do_trap+0x0/0xfe (40) [] do_page_fault+0x0/0x524 (48) [] do_page_fault+0x0/0x524 (12) [] do_page_fault+0x346/0x524 (4) [] preempt_schedule+0x50/0x6b (80) [] try_to_wake_up+0x104/0x106 (20) [] dma_trm_reset+0x36/0x11e [ohci1394] (24) [] __wake_up_common+0x35/0x55 (16) [] do_page_fault+0x0/0x524 (60) [] error_code+0x2b/0x30 (8) [] change_owner+0x1a/0x5a (44) [] set_new_owner+0x17/0x2b (28) [] __up_mutex+0xa4/0x193 (12) [] up+0x35/0x3d (36) [] highlevel_host_reset+0x3b/0x49 [ieee1394] (8) [] ohci_irq_handler+0x576/0x713 [ohci1394] (12) [] __sched_text_start+0x5a/0x5d7 (28) [] __do_IRQ+0xca/0x180 (4) [] handle_IRQ_event+0x5c/0xc8 (36) [] do_hardirq+0x61/0x112 (48) [] do_sched_setscheduler+0x73/0xa0 (4) [] do_irqd+0x0/0x96 (20) [] do_irqd+0x66/0x96 (4) [] kthread+0x94/0xc8 (28) [] kthread+0x0/0xc8 (16) [] kernel_thread_helper+0x5/0xb (16) Please, feel free to ask me for anything else, if relevant to get rid of this casual crash behavior. I'm already running the RT patch/kernel 100% of the time, on all my boxes, althought I have no record of this happening on my other [EMAIL PROTECTED]/HT(SMP) box. Cheers. Linux version 2.6.11-rc4-RT-V0.7.39-02.0 ([EMAIL PROTECTED]) (gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #1 Tue Feb 15 09:37:36 WET 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 1f77 (usable) BIOS-e820: 1f77 - 1f77f000 (ACPI data) BIOS-e820: 1f77f000 - 1f78 (ACPI NVS) BIOS-e820: 1f78 - 0
Re: mouse still losing sync and thus jumping around
On Wed, 23 Feb 2005 14:22:42 +0100, Nils Kalchhauser <[EMAIL PROTECTED]> wrote: > Hi! > > I still get the following messages and my mouse jumps around weirdly > making work rather difficult regardless of which 2.6 kernel I use (tried > 2.6.8, 2.6.9, 2.6.10, 2.6.11-rc2 with patch-see below, 2.6.11-rc4): > > psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing > 2 bytes away. > psmouse.c: Mouse at isa0060/serio4/input0 lost synchronization, throwing > 2 bytes away. > psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4 > psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 > psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. > psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 > > (using either the touchpad or the connected PS/2 mouse) > > I tried the patch Dmitry Torokhov supplied in the message with subject > "Re: Really annoying bug in the mouse driver" from Jan 27 which > supposedly fixes this problem. unfortunately it only got worse. > Hi, There were 2 versions of the psmouse-resend patch, the first one was indeed producing worse results, the second one should work better. Could you please try grabbing the patch against 2.6.10 from here: http://www.geocities.com/dt_or/input/2_6_10/ and letting me know if it gives better results. Thanks! -- 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: loading driver automatically & manually
On Tue, Feb 22, 2005 at 06:34:54PM -0800, Anil Kumar wrote: > Hi, > > I am trying to install RHEL 4, 2.6.9-5.EL. I have adaptec 39320 > controller, The install CD already has aic79xx driver in it. The > driver does NOT load for some reason. If I take the same aic79xx > driver source, Create an img and install RHEL4 using linux dd, it > works fine. I'm quite sure you should be contacting RedHat for support with their commercial product. mh -- Martin HicksWild Open Source Inc. [EMAIL PROTECTED] 613-266-2296 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BK-kernel-tools/shortlog update
Hello Linus, you can either use "bk receive" to patch with this mail, or you can Pull from: bk://krusty.dt.e-technik.uni-dortmund.de/BK-kernel-tools or in cases of dire need, you can apply the patch below. BK: Parent repository is file://var/bitkeeper/BK-kernel-tools Patch description: [EMAIL PROTECTED], 2005-02-23 15:43:14+01:00, [EMAIL PROTECTED] Add six new address -> name mappings. Matthias # DIFFSTAT # shortlog |6 ++ 1 files changed, 6 insertions(+) # GNUPATCH # --- 1.241/shortlog 2005-02-09 10:22:16 +01:00 +++ 1.242/shortlog 2005-02-23 15:43:14 +01:00 @@ -116,6 +116,7 @@ 'davej:codemonkey.org.u' => 'Dave Jones', 'davej:codemonkey.org.uk' => 'Dave Jones', 'davej:delerium.codemonkey.org.uk' => 'Dave Jones', +'davej:delerium.kernelslacker.org' => 'Dave Jones', 'davej:wopr.codemonkey.org.uk' => 'Dave Jones', 'davem:cheetah.ninka.net' => 'David S. Miller', 'davem:nuts.ninka.net' => 'David S. Miller', @@ -438,6 +439,7 @@ 'bheilbrun:paypal.com' => 'Brad Heilbrun', # by himself 'bjoern:j3e.de' => 'Bjoern Jacke', 'bjohnson:sgi.com' => 'Brian J. Johnson', +'bjorn-helgaas:comcast.net' => 'Bjorn Helgaas', 'bjorn.andersson:erc.ericsson.se' => 'Björn Andersson', # google, guessed ö 'bjorn.helgaas:com.rmk.(none)' => 'Bjorn Helgaas', 'bjorn.helgaas:hp.com' => 'Bjorn Helgaas', @@ -945,6 +947,7 @@ 'ganesh:veritas.com' => 'Ganesh Varadarajan', 'ganesh:vxindia.veritas.com' => 'Ganesh Varadarajan', 'garloff:suse.de' => 'Kurt Garloff', +'gary.spiess:intermec.com' => 'Gary N. Spiess', 'gary_lerhaupt:dell.com' => 'Gary Lerhaupt', 'garyhade:us.ibm.com' => 'Gary Hade', 'gbarzini:virata.com' => 'Guido Barzini', @@ -1783,6 +1786,7 @@ 'mikma:users.sourceforge.net' => 'Mikael Magnusson', 'mikpe:csd.uu.se' => 'Mikael Pettersson', 'mikpe:user.it.uu.se' => 'Mikael Pettersson', +'mikukkon:gmail.com' => 'Mika Kukkonen', 'mikulas:artax.karlin.mff.cuni.cz' => 'Mikulas Patocka', 'miles:gnu.org' => 'Miles Bader', 'miles:lsi.nec.co.jp' => 'Miles Bader', @@ -2158,6 +2162,7 @@ 'rathamahata:php4.ru' => 'Sergey S. Kostyliov', 'raul:pleyades.net' => 'Raul Nunez de Arenas Coronado', 'raven:themaw.net' => 'Ian Kent', +'ravinandan.arakali:neterion.com' => 'Ravinandan Arakali', 'ravinandan.arakali:s2io.com' => 'Ravinandan Arakali', 'ray-lk:madrabbit.org' => 'Ray Lee', 'rbh00:utsglobal.com' => 'Richard Hitt', # asked him, he prefers Richard @@ -2530,6 +2535,7 @@ 'temnota:kmv.ru' => 'Andrey Melnikov', 'tes:sgi.com' => 'Timothy Shimmin', 'tetapi:utu.fi' => 'Tero Pirkkanen', # by Kristian Peters +'tglx:de.rmk.(none)' => 'Thomas Gleixner', 'tglx:linutronix.de' => 'Thomas Gleixner', 'tgraf:suug.ch' => 'Thomas Graf', 'th122948:scl1.sfbay.sun.com' => 'Tim Hockin', # by Duncan Laurie # BKPATCH # ## Wrapped with gzip_b64 ## H4sIAJWWHEICA8VU7U7bMBT9XT+FJX50E4trO0nTRCoCxgSMfaAyHuA2uaQhiV3ZaSlSHn5O M1qBNGlsSMuHFPvec33P8YkP6OVZMmi0WUOV2eMlqnxVKNYYULbGBliq6/bjAlSON9i0knPp biF9Pg7jVsbjMGxRYhimgYB5NIkwleSA3lo0yaCGplkUYBmozCC6+Qttm2SQ1xuWdcOZ1m44 siuLoxKNwmp0euUerx94jdaVJS7xGpp0QddobDIQzN/NNI9LTAazT+e3X05mhEyndNcrnU7J G/Pal1umccSZtlnFtMmfFwq5FKGIROxH7TiUMiJnVDAZBZSHIy5H0qciTAI/EcEhFwnn9IVO x70+9FBQj5NT+sYsPpKUnmQZtcWGKnygkLlFraXeEVVQo+tmuSxUbhm5oq5/Icn1XlXivfIi hAMnR3sSC13jCwZ2oU1T6bwnEIoJj4JITFpfRHHY3mEMd2nEY+CYwTz7jVzPqrg9kL4IAve6 KiLwt954ynhmjX/uh/xZPzzmsZRi3PKxGP/yRCBf7Ynxf/dEr+d36pmHTfd4G2eQJ7J/4Y9L ISZUkGEGa7xPMqzQFKua9UeArSB1X91fNqTTIzo8c1n0s1Zohx/IZRDwDjq/10Z5C6xyAJs4 AVKwDVPY9JjTLkwv+nAHi4Oog+VgHpldFo5pUqgGTY1pJ1+POndR+o3Rm21CBxPRJOxwdVGu ylKrJK+hqPaIr0UJ9GobQtUB3HZv+zOwLpTbSFAMDJRQFYlrzvHUao+e7ZLoSZ+0LRH6sivR 5NXGicNMXbJ3yi3wvkf9cP4FS88rLDYKjYPsDsd0gWlpV/U0DgVM7uZAfgLic5DZ7gUAAA== - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WORK WITH US
DEAR SIR/MADAM, WE WILL BE VERY GLAD IF YOU CAN BE OUR REPRESENTATIVE IN YOUR COUNTRY AND EARN 10% OF EVERY PAYMENT MADE THROUGH YOU TO US.FOR MORE INFORMATION CONTACT US THROUGH EMAIL. THANKS Mr. rawlings CEO. ___ Mail sent from WebMail service at PHP-Nuke Powered Site - http://yoursite.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/RFC] Futex mmap_sem deadlock
On Tue, Feb 22, 2005 at 01:30:27PM -0800, Linus Torvalds wrote: > > We really have this already, and it's called "current->preempt". It > handles any lock at all, and doesn't add yet another special case to all > the architectures. > > Just do > > repeat: > down_read(¤t->mm->mmap_sem); > get_futex_key(...) etc. > queue_me(...) etc. > inc_preempt_count(); > ret = get_user(...); > dec_preempt_count(); Perhaps this should be preempt_disable preempt_enable. Otherwise, a preempt attempt in get_user would not be seen until some future preempt_enable was executed. Regards, Joe -- "Money can buy bandwidth, but latency is forever" -- John Mashey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
accept() fails with EINTER
Trying to run an old server with a new kernel. A connection fails with "interrupted system call" as soon as a client attempts to connect. A trap in the code to continue works, but subsequent send() and recv() calls fail in the same way. Anybody know how to mask that SIGIO (or whatever signal)? Setting signal(SIGIO, SIG_IGN) doesn't do anything useful. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xfsdump broken with Kernel 2.6.11-rc4
Hi there, looks like xfsdumpis broken with recent 2.6.11-rc Kernels. 2.6.11-rc4 is the one I tried. Strange enough ist does seem to work _sometimes_, but it does not work most of the time. If it does not work I just get the following message: xfsdump: ERROR: /dev/sda2 does not identify a file system I'm using Version 2.2.23 from debian sarge. It seems to always work with the Distribution Kernel from Debian sarge. Sven -- "If you continue running Windows, your system may become unstable." (Windows 95 BSOD) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.10-as5
Hi Andreas On Tue, 22 Feb 2005 23:08:40 -0500, Andres Salomon <[EMAIL PROTECTED]> wrote: > Hi, > > Here's 2.6.10-as5. 2.6.10-as4 was never officially announced; it had > issues (note to self; test, *then* tag). Distributors should note that > there is an ABI/API change in this release, due to > 114-netfilter_private_queues.patch changing ipv4 related function args. > Modules that use these will most likely need to be rebuilt. > > Lots of security fixes in here; it's probably a good idea to upgrade. > If I'm missing any security related stuff, please let me know. I have [...] Are you in contact with OSDL ? I don't recall who (too lazy for searching in the archive) but someone was willing to manintain a 2.6.x.y kernel including only security fixes. It could be a good idea to share with him your work. -- Paolo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Freenode, Tor, Linux channels (Was: Slightly OT: We should move linux...)
Patrick, Today lilo (the FreeNode network owner) has decided to make one step away in a direction opposite of freedom, and banned all Tor users from the FreeNode network. The actual PDPC policy on access to Freenode via the Electronic Frontier Foundation's Tor project is here: http://freenode.net/policy.shtml#tor To summarize, freenode supports the Tor project and works closely with its developers. Any anonymizing service can be abused, and we have to deal on a daily basis with the results of such abuse. Freenode provides Tor users with randomly-generated, per-session, easily-identifiable hostname cloaks and thus gives each channel the option of either allowing access to Tor users or denying it. We do occasionally block access from Tor exit nodes or remove Tor users from the network, in the course of trying to deal with attacks on channels. We're trying to cut down. ;) For example, this morning we repeatedly killed out a small clonebot net that was causing problems on unattended channels. We added the capability of specifically turning off new Tor connections during periods when there's no other way to prevent abuse. In the process of resolving bugs in that new network feature, we killed out several legitimate Tor users by mistake. Nevertheless, we're committed to keeping freenode available to Tor users as continuously as it is possible to do so. Patrick, I'm sorry you felt the need to spam multiple community mailing lists with this distorted interpretation of freenode policy. I'm willing to assume that you are simply ignorant of network policy, rather than advancing some malicious agenda. I'm posting this single reply in LKML only, to try to avoid adding to off-topic discussion in the mailing lists Patrick has posted his comments in; anyone who feels the need can quote this email in some other forum. Regards, Robert Levin Head of Staff, freenode Executive Director, PDPC Peer-Directed Projects Center 10100 Main Street #31 /Houston, Texas 77025-5237 USA Ph. +1.832.4768694 PDPC is a Texas nonprofit corporation and an IRS 501(c)(03) charitable and educational organization, chartered in 2002 to provide resources to peer-directed projects, including those of the Free and Open Source Software communities. PDPC runs the freenode interactive network. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.11-rc4-mm1] mips: fixed confliction types for pcibios_align_resource
This patch fixes confliction types for pcibios_align_resource.
CC arch/mips/pci/pci.o
arch/mips/pci/pci.c:55: error: conflicting types for 'pcibios_align_resource'
include/linux/pci.h:729: error: previous declaration of
'pcibios_align_resource' was here
make[1]: *** [arch/mips/pci/pci.o] Error 1
make: *** [arch/mips/pci] Error 2
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/pci/pci.c a/arch/mips/pci/pci.c
--- a-orig/arch/mips/pci/pci.c Sun Feb 13 12:06:55 2005
+++ a/arch/mips/pci/pci.c Thu Feb 24 00:11:17 2005
@@ -50,8 +50,7 @@
* which might have be mirrored at 0x0100-0x03ff..
*/
void
-pcibios_align_resource(void *data, struct resource *res,
- unsigned long size, unsigned long align)
+pcibios_align_resource(void *data, struct resource *res, u64 size, u64 align)
{
struct pci_dev *dev = data;
struct pci_controller *hose = dev->sysdata;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.9.11-rc4-mm1] mips: fixed kernel code resource initialization errors
This patch fixes the following errores.
We need C99 struct initialization.
CC arch/mips/kernel/setup.o
arch/mips/kernel/setup.c:89: warning: initialization makes integer from pointer
without a cast
arch/mips/kernel/setup.c:89: error: initializer element is not computable at
load time
arch/mips/kernel/setup.c:89: error: (near initialization for
'code_resource.start')
arch/mips/kernel/setup.c:90: warning: initialization makes integer from pointer
without a cast
arch/mips/kernel/setup.c:90: error: initializer element is not computable at
load time
arch/mips/kernel/setup.c:90: error: (near initialization for
'data_resource.start')
make[1]: *** [arch/mips/kernel/setup.o] Error 1
make: *** [arch/mips/kernel] Error 2
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff a-orig/arch/mips/kernel/setup.c a/arch/mips/kernel/setup.c
--- a-orig/arch/mips/kernel/setup.c Sun Feb 13 12:05:29 2005
+++ a/arch/mips/kernel/setup.c Thu Feb 24 00:33:49 2005
@@ -86,8 +86,8 @@
unsigned long isa_slot_offset;
EXPORT_SYMBOL(isa_slot_offset);
-static struct resource code_resource = { "Kernel code" };
-static struct resource data_resource = { "Kernel data" };
+static struct resource code_resource = { .name = "Kernel code", };
+static struct resource data_resource = { .name = "Kernel data", };
void __init add_memory_region(phys_t start, phys_t size, long type)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BKCVS still updated?
Hi, Does anyone know whether the BKCVS repository (rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.5) is still updated? The last ChangeSet,v revision I got is 1.26750 which was checked in more than a week ago. (Sorry if I missed some e-mails about a planned down-time) Thanks, Catalin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6: USB Storage hangs machine on bootup for ~2 minutes
On Tue, 22 Feb 2005, Parag Warudkar wrote:
> Alan,
> See below for stack traces and also note that the stack traces are after I
> modified usb_device_read to do down_interruptible instead of down. (kudzu
> gets stuck regardless though.) Let me know if you want me to revert the
> down_interruptible change and repost the stack trace.
>
> I wrongly related this to the 2 minute hang - this one is forever if I let
> kudzu start during boot. If I run kudzu after boot is complete, it gets stuck
> and everything else on that drive (mount, unmount ..) also gets stuck. Sorry
> about the confusion.
Well, this problem looks like something for which a patch was submitted
about a week ago. Try applying
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110859441830485&w=2
and see if it helps. This doesn't bring us any closer to understanding
the 2-minute delay, though.
> Attached is the disassembly of usb_device_read from my machine.
I hope it doesn't become necessary to decode that!
Alan Stern
> Parag
>
> SysRQ + T for relevant processes
> ==
> hald D 0020e12be31a 0 2558 1 3272 2545
> (NOTLB)
> 81002c76fb48 0082 81002c76fb28 88515044
>00862c76fb08 81002eb10800 0249 810001c56030
>81002c76fc08 0002
> Call Trace:
> {:scsi_mod:scsi_request_fn+2356}
>{io_schedule+15} {sync_page+70}
>{__wait_on_bit_lock+69}
> {sync_page+0}
>{__lock_page+167}
> {wake_bit_function+0}
>{wake_bit_function+0}
> {do_generic_mapping_read+660}
>{file_read_actor+0}
> {__generic_file_aio_read+420}
>{generic_file_read+187}
> {autoremove_wake_function+0}
>{do_brk+720} {vfs_read+225}
>{sys_read+80} {system_call+126}
>
> scsi_eh_2 D 0 3581 1 3582 3277
> (L-TLB)
> 81002bdc1d88 0046 01e3 81002bed8800
> 81002bdc1d48 81002c25a800 0812 803df080
> 81002bdc1ed0 81002c25a800
> Call Trace:
> {wait_for_completion+437}
> {default_wake_function+0}
> {default_wake_function+0}
> {:usb_storage:usb_stor_stop_transport+35}
> {:usb_storage:command_abort+256}
> {:scsi_mod:scsi_error_handler+2172}
> {child_rip+8}
> {:scsi_mod:scsi_error_handler+0}
> {child_rip+0}
> usb-storage D 0 3582 1 3627 3581
> (L-TLB)
> 81002b8e1c08 0046 81002b9e1000 0010
> 00762b8e1c98 81002bed8800 03dd 81002eb10800
> c0040280 001f
> Call Trace:
> {wait_for_completion+437}
> {thread_return+253}
> {default_wake_function+0}
> {default_wake_function+0}
> {:usb_storage:usb_stor_msg_common+550}
> {dma_unmap_sg+134}
> {:usb_storage:usb_stor_bulk_transfer_buf+143}
> {:usb_storage:usb_stor_Bulk_transport+203}
> {:usb_storage:usb_stor_invoke_transport+59}
> {:usb_storage:usb_stor_transparent_scsi_command+27}
> {:usb_storage:usb_stor_control_thread+756}
> {finish_task_switch+195}
> {child_rip+8}
> {:usb_storage:usb_stor_control_thread+0}
> {child_rip+0}
>
> scsi_eh_3 S 0 3627 1 3634 3582
> (L-TLB)
> 81002bd47d68 0046 81002bd47d28 80219b32
> 00742bc387c0 81002bc387c0 0226 81002b9fc030
> 81002bd47d48 80147ab1
> Call Trace:
> {_atomic_dec_and_lock+290} {free_uid+33}
> {__down_interruptible+486}
> {default_wake_function+0}
> {__down_failed_interruptible+53}
> {:scsi_mod:.text.lock.scsi_error+45}
> {child_rip+8}
> {:scsi_mod:scsi_error_handler+0}
> {child_rip+0}
> usb-storage S 0020f04e3d81 0 3634 13627
> (L-TLB)
> 81002bc53df8 0046 81002bc53d80 1000
> 00732b9eba7c 81002b9fc030 05ad 81002ebc9800
> 81002bc53de8 8853570f
> Call Trace:
> {:usb_storage:usb_stor_bulk_transfer_buf+143}
> {__down_interruptible+486}
> {default_wake_function+0}
> {__down_failed_interruptible+53}
> {:usb_storage:.text.lock.usb+5}
> {finish_task_switch+195}
> {child_rip+8}
> {:usb_storage:usb_stor_control_thread+0}
>{child_rip+0}
>
> khubd S 001ddd381da1 0 125 1 182 9
> (L-TLB)
> 810001ecbe18 0046 0246 81002ba2c400
>007401ecbdd8 810001e9a800 3023 81002bed8070
>810001ecbe18 8015c4c9
> Call Trace:
> {prepare_to_wait+345} {hub_thread+4118}
>{free_pages_bulk+1007}
> {autoremove_wake_function+0}
>{autoremove_wake_function+0}
> {child_rip+8}
>{hub_thread+0} {child_rip+
Re: [PATCH/RFC] Futex mmap_sem deadlock
On Wed, 23 Feb 2005, Joe Korty wrote: > > Perhaps this should be preempt_disable preempt_enable. No, the problem with preempt_disable/enable is that they go away if preemption is not enabled. So you really do have to do it by hand with the "inc_preempt_count". > Otherwise, a preempt attempt in get_user would not be seen > until some future preempt_enable was executed. True. I guess we should have a "preempt_check_resched()" there too. That's what "kunmap_atomic()" does too (which is what we rely on in the other case we do this..) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: AHCI oops
Jeff Garzik wrote: Can you try this patch? If it fixes the oops, I'll forward upstream ASAP. Jeff, It fixes the oops (pasted below) for me; please do push it ASAP. thanks, BR xlated vfy cmd LBA 0x14f500 cnt 20 ahci_interrupt: int on port 2 ahci_host_intr: fatal int seen ahci_intr_error: port 2 irq_stat 0x4001 struct ata_port *ap = 0xc1bf79bc ap->ioaddr.error_addr = 0x Unable to handle kernel NULL pointer dereference at virtual address printing eip: c0279bfd *pde = Oops: [#1] Modules linked in: af_packet ipmi_devintf ipmi_msghandler CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.11-rc4) EIP is at ata_to_sense_error+0x22d/0x3a0 eax: ebx: ecx: 563ff726 edx: 07bf esi: c1bf79bc edi: c1bf08bc ebp: esp: c03a5ed4 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c03a4000 task=c0350b20) Stack: c0329736 0282 001f7934 c1bf0800 01000246 c1bf7e78 c1bf0800 c1bf7e78 4001 c1bf7e78 c027a48e c1bf7e78 c1bf79bc c0277fd4 c0333e88 0002 0002 4001 0002 01bf79bc 0002 c027baa2 c032995e Call Trace: [] ata_scsi_qc_complete+0x5e/0x60 [] ata_qc_complete+0x34/0xf0 [] ahci_interrupt+0x152/0x1a0 [] handle_IRQ_event+0x32/0x70 [] __do_IRQ+0xa7/0x110 [] do_IRQ+0x36/0x70 [] common_interrupt+0x1a/0x20 [] mwait_idle+0x25/0x50 [] cpu_idle+0x49/0x60 [] start_kernel+0x16a/0x1b0 [] unknown_bootoption+0x0/0x1e0 Code: e9 ff 8d b6 00 00 00 00 8d bf 00 00 00 00 b8 58 89 41 00 4b e8 e5 e6 f7 f <0>Kernel panic - not syncing: Fatal exception in interrupt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB Storage problem (usb hangs)
Hi. The device is: USB2.0 to IDE 3.5" hard disk enclosure. Producer: Seven. Part of /var/log/messages with USB debug enabled in kernel is attached to this email. Kernel: 2.6.9, 2.6.10 (i cant remember from which one is attached log). Distribution: Gentoo. I'm not subscribed to the list, pleas CC me. -- Regards Sebastian Fabrycki [EMAIL PROTECTED] Jan 10 23:34:30 globtel usb-storage: USB Mass Storage device detected Jan 10 23:34:30 globtel usb-storage: -- associate_dev Jan 10 23:34:30 globtel usb-storage: Vendor: 0x05e3, Product: 0x0702, Revision: 0x0002 Jan 10 23:34:30 globtel usb-storage: Interface Subclass: 0x06, Protocol: 0x50 Jan 10 23:34:30 globtel usb-storage: Vendor: Genesys Logic, Product: USB TO IDE Jan 10 23:34:30 globtel usb-storage: Transport: Bulk Jan 10 23:34:30 globtel usb-storage: Protocol: Transparent SCSI Jan 10 23:34:30 globtel usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value= index=00 len=1 Jan 10 23:34:30 globtel usb-storage: GetMaxLUN command result is 1, data is 0 Jan 10 23:34:30 globtel usb-storage: *** thread sleeping. Jan 10 23:34:30 globtel scsi0 : SCSI emulation for USB Mass Storage devices Jan 10 23:34:30 globtel usb-storage: queuecommand called Jan 10 23:34:30 globtel usb-storage: *** thread awakened. Jan 10 23:34:30 globtel usb-storage: Faking INQUIRY command Jan 10 23:34:30 globtel usb-storage: scsi cmd done, result=0x0 Jan 10 23:34:30 globtel usb-storage: *** thread sleeping. Jan 10 23:34:30 globtel Vendor: Genesys Model: USB to IDE Disk Rev: 0002 Jan 10 23:34:30 globtel Type: Direct-Access ANSI SCSI revision: 02 Jan 10 23:34:30 globtel usb-storage: queuecommand called Jan 10 23:34:30 globtel usb-storage: *** thread awakened. Jan 10 23:34:30 globtel usb-storage: Command TEST_UNIT_READY (6 bytes) Jan 10 23:34:30 globtel usb-storage: 00 00 00 00 00 00 Jan 10 23:34:30 globtel usb-storage: Bulk Command S 0x43425355 T 0x2 L 0 F 0 Trg 0 LUN 0 CL 6 Jan 10 23:34:30 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jan 10 23:34:30 globtel usb-storage: Status code 0; transferred 31/31 Jan 10 23:34:30 globtel usb-storage: -- transfer complete Jan 10 23:34:30 globtel usb-storage: Bulk command transfer result=0 Jan 10 23:34:30 globtel usb-storage: Attempting to get CSW... Jan 10 23:34:30 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jan 10 23:34:40 globtel scsi.agent[7459]: Attribute /sys/devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.0/host0/0:0:0:0/type does not exist Jan 10 23:35:00 globtel usb-storage: command_abort called Jan 10 23:35:00 globtel usb-storage: usb_stor_stop_transport called Jan 10 23:35:00 globtel usb-storage: -- cancelling URB Jan 10 23:35:00 globtel usb-storage: Status code -104; transferred 0/13 Jan 10 23:35:00 globtel usb-storage: -- transfer cancelled Jan 10 23:35:00 globtel usb-storage: Bulk status result = 4 Jan 10 23:35:00 globtel usb-storage: -- command was aborted Jan 10 23:35:00 globtel usb-storage: usb_stor_Bulk_reset called Jan 10 23:35:00 globtel usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 Jan 10 23:35:20 globtel usb-storage: Timeout -- cancelling URB Jan 10 23:35:20 globtel usb-storage: Soft reset failed: -104 Jan 10 23:35:20 globtel usb-storage: scsi command aborted Jan 10 23:35:20 globtel usb-storage: *** thread sleeping. Jan 10 23:35:20 globtel usb-storage: queuecommand called Jan 10 23:35:20 globtel usb-storage: *** thread awakened. Jan 10 23:35:20 globtel usb-storage: Command TEST_UNIT_READY (6 bytes) Jan 10 23:35:20 globtel usb-storage: 00 00 00 00 00 00 Jan 10 23:35:20 globtel usb-storage: Bulk Command S 0x43425355 T 0x2 L 0 F 0 Trg 0 LUN 0 CL 6 Jan 10 23:35:20 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jan 10 23:35:20 globtel usb-storage: Status code 0; transferred 31/31 Jan 10 23:35:20 globtel usb-storage: -- transfer complete Jan 10 23:35:20 globtel usb-storage: Bulk command transfer result=0 Jan 10 23:35:20 globtel usb-storage: Attempting to get CSW... Jan 10 23:35:20 globtel usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jan 10 23:35:30 globtel usb-storage: command_abort called Jan 10 23:35:30 globtel usb-storage: usb_stor_stop_transport called Jan 10 23:35:30 globtel usb-storage: -- cancelling URB Jan 10 23:35:30 globtel usb-storage: Status code -104; transferred 0/13 Jan 10 23:35:30 globtel usb-storage: -- transfer cancelled Jan 10 23:35:30 globtel usb-storage: Bulk status result = 4 Jan 10 23:35:30 globtel usb-storage: -- command was aborted Jan 10 23:35:30 globtel usb-storage: usb_stor_Bulk_reset called Jan 10 23:35:30 globtel usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value= index=00 len=0 Jan 10 23:35:50 globtel usb-storage: Timeout -- cancelling URB Jan 10 23:35:50 globtel usb-storage: Soft reset failed: -104 Jan 10 23:35:50 globtel usb-storage: scsi command aborted Jan 10 23:35:50 globtel usb-storage: *** thread sleeping. Jan 10 23:35:50 globtel usb-storage: device_reset call
Re: USB Storage problem (usb hangs)
Sebastian, Try upgrading to 2.6.11-rc2-mm4 or newer, I've had better luck with my USB/Firewire external case on there. Just make sure you don't turn on usb-storage logging, it's way too verbose for general use! John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
On Wed, Feb 23, 2005 at 11:39:08AM +, David Howells wrote: > Alternately, you could just have do_page_fault() do: > > while (!down_read_trylock(¤t->mm->mmap_sem)) > continue; > > However, note that this can suffer from starvation due to a never ending flow > of mixed write-locks and read-locks on other CPUs. Unlikely, true, but not > impossible. How can this help? The semaphore is held for reading by the thread that faulted in futex_wait() -> get_user(), so no writers will be let through. Until the writer has been let through, the down_read_trylock will never succeed either. No forward progress can be made even with the above loop. -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: mouse still losing sync and thus jumping around
Dmitry Torokhov wrote: On Wed, 23 Feb 2005 14:22:42 +0100, Nils Kalchhauser There were 2 versions of the psmouse-resend patch, the first one was indeed producing worse results, the second one should work better. Could you please try grabbing the patch against 2.6.10 from here: http://www.geocities.com/dt_or/input/2_6_10/ and letting me know if it gives better results. sorry for not realising that there was a newer patch. I tried that one now and indeed it seems a lot better. I did not have any lost sync message for about an hour but then the mouse started jumping again. and it seems to me like it is connected to disk activity... is that possible? Nils - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
On Wed, 2005-02-23 at 12:03 +0100, Mathieu Segaud wrote: > it is the latest Robert Love posted against -mm kernels, but in > inotify_ignore(): I posted an updated patch last Friday, which fixed this. Anyhow, this is the correct fix. Signed-off-by: Robert Love <[EMAIL PROTECTED]> Thanks, Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1 (VFS: Cannot open root device "301")
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ - Various fixes and updates all over the place. Things seem to have slowed down a bit. I am having trouble getting recent -mm kernels to boot on my test box. For 2.6.11-rc3-mm2 and 2.6.11-rc4-mm1 I get the following: VFS: Cannot open root device "301" or unknown-block(3,1) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1) 2.6.11-rc2-mm1 boots fine, and so do plain -rc3 and -rc4. I copied a working .config from an earlier kernel(-rc3), and ran make oldconfig, answering most of the new questions 'n'. I did try appending root=0301 (which worked last year after similar symptoms, but that didn't help this time). The root fs is ext3, which is compiled in. Any help appreciated. Steven Output of grep ^CONFIG .config: CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCALVERSION="-GX110" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_BASE_SMALL=1 CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_X86_PC=y CONFIG_MPENTIUMIII=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_EDD=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_PHYSICAL_START=0x10 CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_LEGACY_PROC=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=32000 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_XFRM=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y CONFIG_SERIO_LIBPS2=y CONFIG_SOUND_GAMEPORT=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_FTAPE=y CONFIG_ZFTAPE=y CONFIG_ZFT_DFLT_BLK_SZ=10240 CONFIG_ZFT_COMPRESSOR=y CONFIG_FT_NR_BUFFERS=3 CONFIG_FT_PROC_FS=y CONFIG_FT_NORMAL_DEBUG=y CONFIG_FT_STD_FDC=y CONFIG_FT_FDC_THR=8 CONFIG_FT_FDC_MAX_RATE=2000 CONFIG_FT_ALPHA_CLOCK=0 CONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_VIDEO_DEV=y CONFIG_VIDEO_SELECT=y CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_REISER4_FS=y CONFIG_REISERFS_FS=y CONFIG_ISO9660_FS=y CONFIG_FAT_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y CONFIG_NTFS_RW=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVFS_FS=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_FRAME_POINTER=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y CONFIG_CRC_CCITT=y CONFIG_CRC32=y CONFIG_LIBCRC32C=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org
Re: uninterruptible sleep lockups
On Tue, 22 Feb 2005 22:31:03 +0100, Olaf Titz <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]> you write: > > The most recent one was yesterday: I had run lsusb in the morning and had no > > problems, but at the end of the day I ran it again, and after outputting 3 > > lines of data, it hung, stuck in D-state. So now I have this: > > > > [/home/user]$ ps aux|grep D > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > > root92 0.0 0.0 00 ?DFeb19 0:00 [khubd] > > root 845 0.0 0.0 00 ?DFeb19 0:00 [knodemgrd_0] > > root 29016 0.0 0.1 1512 592 ?D00:28 0:00 lsusb > > I'm getting fairly repeatable deadlocks of this kind involving khubd > with a USB storage device. Perhaps there's just a faulty locking issue > in khubd. Would you be willing to file a bugzilla (bugzilla.kernel.org) bug, if it's still happening with 2.6.11-rc4? Or, if you have filed one, please refer to it? Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: uninterruptible sleep lockups
I have recently run into similar issue involving processes stuck in D state - involves khubd and usb-storage. This happens with 2.6.11-rc4. Check lkml for subject Re: [linux-usb-devel] 2.6: USB Storage hangs mac.. Parag > On Tue, 22 Feb 2005 22:31:03 +0100, Olaf Titz <[EMAIL PROTECTED]> wrote: > > In article <[EMAIL PROTECTED]> you write: > > > The most recent one was yesterday: I had run lsusb in the morning and had > > > no > > > problems, but at the end of the day I ran it again, and after outputting 3 > > > lines of data, it hung, stuck in D-state. So now I have this: > > > > > > [/home/user]$ ps aux|grep D > > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > > > root92 0.0 0.0 00 ?DFeb19 0:00 [khubd] > > > root 845 0.0 0.0 00 ?DFeb19 0:00 > > > [knodemgrd_0] > > > root 29016 0.0 0.1 1512 592 ?D00:28 0:00 lsusb > > > > I'm getting fairly repeatable deadlocks of this kind involving khubd > > with a USB storage device. Perhaps there's just a faulty locking issue > > in khubd. > > Would you be willing to file a bugzilla (bugzilla.kernel.org) bug, if > it's still happening with 2.6.11-rc4? Or, if you have filed one, > please refer to it? > > Thanks, > Nish > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the famous Tyan S2885 PCI IDE problem, additional experiences [resolved]
Dap, I too have the same problem in relation to the IAL completion errors and have upgraded from 2.6.9 to 2.6.11. But now I am unable to compile the openbuild drivers for the highpoint 1820a raid controllers. May I ask how you successfully comiled the drivers to work with 2.6.11? My setup: Tyan S2882 dual opteron 240 4 gig ram 2 Highpoint 1820a 12 seagate 7200.7 baracudas Thank you Billy Stewart - exerpt below I've upgraded from 2.6.9 to 2.6.11-rc1 and the problem has been gone! On Sun, 2005-01-16 at 23:14 +0100, Pallai Roland wrote: > I've read a thread about Tyan S2885 IDE problems > (http://www.ussg.iu.edu/hypermail/linux/kernel/0412.3/0457.html), > unfortunately I suffered from it too, but in a different hardware setup > and I noticed some more details about it, I hope this may help somehow. > > My config is a Tyan Thunder K8W (S2885) dual Operon244 with 5 HighPoint > 1820 PCI-X sata controllers and 44/4 SATA/UATA drives, and I get daily > 2-3 messages like this, sometimes followed by a lockup: > > Jan 12 09:16:45 EverDream kernel: IAL: COMPLETION ERROR, adapter 2, channel 5, flags=101 > Jan 12 09:16:45 EverDream kernel: Retry on channel(5) > Jan 12 11:05:52 EverDream kernel: IAL: COMPLETION ERROR, adapter 1, channel 7, flags=101 > Jan 12 11:05:52 EverDream kernel: IAL: COMPLETION ERROR, adapter 2, channel 7, flags=101 > Jan 12 11:05:52 EverDream kernel: Retry on channel(7) > Jan 12 11:05:52 EverDream kernel: Retry on channel(7) -- dap - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc4-mm1
I'm getting several modules with undefined symbols : Kernel: arch/i386/boot/bzImage is ready Building modules, stage 2. MODPOST *** Warning: "match_octal" [fs/udf/udf.ko] undefined! *** Warning: "match_token" [fs/udf/udf.ko] undefined! *** Warning: "match_int" [fs/udf/udf.ko] undefined! *** Warning: "match_strdup" [fs/isofs/isofs.ko] undefined! *** Warning: "match_token" [fs/isofs/isofs.ko] undefined! *** Warning: "match_int" [fs/isofs/isofs.ko] undefined! *** Warning: "match_octal" [fs/fuse/fuse.ko] undefined! *** Warning: "match_token" [fs/fuse/fuse.ko] undefined! *** Warning: "match_int" [fs/fuse/fuse.ko] undefined! *** Warning: "match_octal" [fs/fat/fat.ko] undefined! *** Warning: "match_strdup" [fs/fat/fat.ko] undefined! *** Warning: "match_token" [fs/fat/fat.ko] undefined! *** Warning: "match_int" [fs/fat/fat.ko] undefined! *** Warning: "match_token" [fs/ext3/ext3.ko] undefined! *** Warning: "match_int" [fs/ext3/ext3.ko] undefined! *** Warning: "match_token" [fs/ext2/ext2.ko] undefined! *** Warning: "match_int" [fs/ext2/ext2.ko] undefined! *** Warning: "match_octal" [drivers/usb/core/usbcore.ko] undefined! *** Warning: "match_token" [drivers/usb/core/usbcore.ko] undefined! *** Warning: "match_int" [drivers/usb/core/usbcore.ko] undefined! my .config is attached Regards, Vincent config-2.6.11-rc4-mm1 Description: Binary data
Re: [darcs-users] Re: [BK] upgrade will be needed
On Mon, 2005-02-21 at 20:45, [EMAIL PROTECTED] wrote: > CVS was pretty good at keeping files sane, but I'll go for a solution that > completely sidesteps said problem any day. One way to get the benefits of both worlds would be to keep an additional history of changes (in whatever form) that allows to rebuild the ,v files. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
On Wed, Feb 23, 2005 at 07:54:06AM -0800, Linus Torvalds wrote:
> > Otherwise, a preempt attempt in get_user would not be seen
> > until some future preempt_enable was executed.
>
> True. I guess we should have a "preempt_check_resched()" there too. That's
> what "kunmap_atomic()" does too (which is what we rely on in the other
> case we do this..)
Ok, this is getting complex enough to warrant get_user_inatomic(),
which means adding it to every arch's uaccess.h.
Below patch does so. Unfortunately I don't have a Viro setup with cross
compilers for nearly every arch, so I can't make sure it doesn't break
anything. But since I pasted the same code everywhere it shouldn't.
-
Some futex functions do get_user calls while holding mmap_sem for
reading. If get_user() faults, and another thread happens to be in mmap
(or somewhere else holding waiting on down_write for the same semaphore),
then do_page_fault will deadlock. Most architectures seem to be exposed
to this.
To avoid it, make sure the page is available. If not, release the
semaphore, fault it in and retry.
I also found another exposure by inspection, moving some of the code
around avoids the possible deadlock there.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: linux-2.5/kernel/futex.c
===
--- linux-2.5.orig/kernel/futex.c 2005-02-21 16:09:38.0 -0600
+++ linux-2.5/kernel/futex.c2005-02-23 10:55:37.0 -0600
@@ -329,6 +329,7 @@
int ret, drop_count = 0;
unsigned int nqueued;
+ retry:
down_read(¤t->mm->mmap_sem);
ret = get_futex_key(uaddr1, &key1);
@@ -355,9 +356,17 @@
before *uaddr1. */
smp_mb();
- if (get_user(curval, (int __user *)uaddr1) != 0) {
- ret = -EFAULT;
- goto out;
+ ret = get_user_inatomic(curval, (int __user *)uaddr1);
+
+ if (unlikely(ret)) {
+ up_read(¤t->mm->mmap_sem);
+ /* Re-do the access outside the lock */
+ ret = get_user(curval, (int __user *)uaddr1);
+
+ if (!ret)
+ goto retry;
+
+ return ret;
}
if (curval != *valp) {
ret = -EAGAIN;
@@ -480,6 +489,7 @@
int ret, curval;
struct futex_q q;
+ retry:
down_read(¤t->mm->mmap_sem);
ret = get_futex_key(uaddr, &q.key);
@@ -508,9 +518,21 @@
* We hold the mmap semaphore, so the mapping cannot have changed
* since we looked it up in get_futex_key.
*/
- if (get_user(curval, (int __user *)uaddr) != 0) {
- ret = -EFAULT;
- goto out_unqueue;
+
+ ret = get_user_inatomic(curval, (int __user *)uaddr);
+
+ if (unlikely(ret)) {
+ up_read(¤t->mm->mmap_sem);
+
+ if (!unqueue_me(&q)) /* There's a chance we got woken already */
+ return 0;
+
+ /* Re-do the access outside the lock */
+ ret = get_user(curval, (int __user *)uaddr);
+
+ if (!ret)
+ goto retry;
+ return ret;
}
if (curval != val) {
ret = -EWOULDBLOCK;
Index: linux-2.5/mm/mempolicy.c
===
--- linux-2.5.orig/mm/mempolicy.c 2005-02-04 00:27:40.0 -0600
+++ linux-2.5/mm/mempolicy.c2005-02-23 10:16:46.0 -0600
@@ -524,9 +524,13 @@
} else
pval = pol->policy;
- err = -EFAULT;
+ if (vma) {
+ up_read(¤t->mm->mmap_sem);
+ vma = NULL;
+ }
+
if (policy && put_user(pval, policy))
- goto out;
+ return -EFAULT;
err = 0;
if (nmask) {
Index: linux-2.5/include/asm-ppc64/uaccess.h
===
--- linux-2.5.orig/include/asm-ppc64/uaccess.h 2005-02-04 00:27:13.0
-0600
+++ linux-2.5/include/asm-ppc64/uaccess.h 2005-02-23 11:01:44.0
-0600
@@ -217,6 +217,17 @@
: "=r"(err), "=r"(x)\
: "b"(addr), "i"(errret), "0"(err))
+
+#define get_user_inatomic(x,ptr) \
+({ \
+ int __ret; \
+ inc_preempt_count();\
+ __ret = __copy_from_user_inatomic(&(x),(ptr),sizeof(*(ptr))); \
+ dec_preempt_count();\
+ preempt_check_resched();\
+ __ret; \
+})
Re: OT: Why is usb data many times the cpu hog that firewire is?
On Wed, 23 Feb 2005, Paulo Marques wrote:
> Matt Mackall wrote:
> > [...]
> > JPEG data is DCT of 8x8 pixel chunks. If you can get at that, you can
> > compare the DC terms of each chunk with minimal decoding. Various
> > thumbnailers do this for speed already.
>
> I really doubt that this would work. It seems to me that you can have very
> different DC terms with very similar results. In other words, even a little
> noise in the picture might produce very different DC terms.
It will cause only a slight difference, noise is mainly visible in the
high-frequence parts.
> Instead of comparing the DC terms, you could compare just the luminance. You
> would have to decompress just half the data for that and you wouldn't need to
> make the YUV->RGB conversion. That would probably save a few cycles.
And since you cannot do `exact' comparisons of the luminance due to noise, but
have to do some averaging, you're back to the previous solution: Hence compare
the DC terms of the luminance. They're the average luminance of the 8x8 chunks.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.11-rc4-mm1 and dpt_i2o Adaptec I2O RAID controller
Hi all, i'm trying to get an Adaptec 2015S Zero Channel Raid Controller up and running in a very new Asus Mainboard (NCL-DS) with Dual Xeons. I already tried kernel 2.4.29 and plain 2.6.10 but both just lock up when loading the dpt_i2o driver. With 2.6.11-rc4-mm1 i could gather the following output while booting: -- Loading Adaptec I2O RAID: Version 2.4 Build 5go Detecting Adaptec I2O RAID controllers... ACPI: PCI interrupt :09:01.0[A] -> GSI 11 (level, low) -> IRQ 11 Adaptec I2O RAID controller 0 irq=11 BAR0 f888 - size= 10 BAR1 f8a0 - size= 100 BUG: soft lockup detected on CPU#0! Pid: 1, comm: swapper EIP: 0060:[] CPU: 0 EIP is at __do_softirq+0x2e/0x90 EFLAGS: 0246Not tainted (2.6.11-rc4-mm1) EAX: dfcb EBX: 0022 ECX: 0022 EDX: ESI: c04c8ea0 EDI: 000a EBP: 0246 DS: 007b ES: 007b CR0: 8005003b CR2: fffcd000 CR3: 004a3000 CR4: 06d0 [] do_softirq+0x27/0x30 [] do_IRQ+0x3b/0x70 [] common_interrupt+0x1a/0x20 [] setup_irq+0xa2/0xf0 [] adpt_isr+0x0/0x1f0 [more] [] request_irq+0x71/0x90 [] adpt_install_hba+0x2a1/0x420 [] bus_add_driver+0xc3/0xd0 [] adpt_detect+0x50/0x1e0 [] init_this_scsi_driver+0x3a/0x100 [] do_initcalls+0x2b/0xc0 [] init+0x0/0xf0 [] init+0x0/0xf0 [] init+0x25/0xf0 [] kernel_thread_helper+0x0/0x18 [] kernel_thread_helper+0x5/0x18 -- I have several machines running with dpt_i2o raid controller and 2.4.29 for example but they are on older Tyan boards. Any suggestions how to get this controller up and running ? I suppose it has something to do with APIC and/or IRQ routing ? If you need any additional information just let me know. Best Regards, Sebastian Faerber __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] yaird 0.0.4, a mkinitrd based on hotplug concepts
Version 0.0.4 of yaird is now available at: http://www.xs4all.nl/~ekonijn/yaird/yaird-0.0.4.tar.gz Yaird is a perl rewrite of mkinitrd. It aims to reliably identify the necessary modules by using the same algorithms as hotplug, and comes with a template system to to tune the tool for different distributions and experiment with different image layouts. It requires a 2.6 kernel with hotplug. There is a paper discussing it at: http://www.xs4all.nl/~ekonijn/yaird/yaird.html There are rough edges in practically every feature, and numerous features still need to be added: this is suitable for testing, but not for production use. Thanks to all who gave feedback, sent patches and were brave enough to test this stuff. Below are highlights from the change log and todo list. Summary of user visible changes for version 0.0.4: * Process kernel command line options: init=, ro, rw. * Boot into single user mode supported * Support modules outside /lib/modules * Support modules with extension other than .ko * Warn about duplicates in modules.dep * Generated image now waits for device to become visible in /sys, and gives error message if it doesn't * Support 2.6.10 sysfs layout: SCSI now has a new subdirectory 'target'. (Thanks to Harald Dunkel for testing) * Warn about unrecognised paths in /sys * Empty lines in /etc/fstab are valid. (Patch Goffredo Baroncelli) On top of the todo list are now: * add command line option (--root=/dev/hdb) to simplify testing. * add tree copying to the templates, to allow all of firmware to be copied to the image. Or all of /lib/modules, if you want to have hotplug on the image. * get klibc run_init working. Test by switching the Debian template to initramfs. This should make Debian and Fedora templates more similar, it is also groundwork for possible hotplug-ng support. * any patches you may wish to send :) Regards, Erik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ignored return value of __clear_user in fs/binfmt_elf.c?
Machine is sparc64, bk of today, gcc-3.4.2-6.fc3 (Aurora Corona). First 2.6 I try to build here, so it might be something known. Build fails due to -Werror with: include/asm/uaccess.h: In function `load_elf_binary': arch/sparc64/kernel/../../../fs/binfmt_elf.c:811: warning: ignoring return value of `__clear_user', declared with attribute warn_unused_result Around line 811 of fs/binfmt_elf.c I see: /* * This bss-zeroing can fail if the ELF file * specifies odd protections. So we don't check * the return value */ (void)clear_user((void __user *)elf_bss + load_bias, nbyte); so presumably this discarding is OK here... I wonder why an explicit (void) cast is not considered "use" by the compiler. But then again, explicitly throwing away isn't really "use"... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] TCP-Hybla proposal
On Wednesday 23 February 2005 05:00, Matt Mackall wrote: > It's disappointing that this paper appears to be available only > through subscription sources. If I'm mistaken, please post a URL. > The authors are making a webpage with info and documentation. I suppose that article you are referring has been published, then rights go with the editor. -- Daniele Lacamera root at danielinux.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/
Re: [PATCH/RFC] Futex mmap_sem deadlock
On Wed, 2005-02-23 at 11:10 -0600, Olof Johansson wrote: > On Wed, Feb 23, 2005 at 07:54:06AM -0800, Linus Torvalds wrote: > > > > Otherwise, a preempt attempt in get_user would not be seen > > > until some future preempt_enable was executed. > > > > True. I guess we should have a "preempt_check_resched()" there too. That's > > what "kunmap_atomic()" does too (which is what we rely on in the other > > case we do this..) > > Ok, this is getting complex enough to warrant get_user_inatomic(), > which means adding it to every arch's uaccess.h. > > Below patch does so. Unfortunately I don't have a Viro setup with cross > compilers for nearly every arch, so I can't make sure it doesn't break > anything. But since I pasted the same code everywhere it shouldn't. I hate to do this to you, but get_user is a bit horrible in that it is an untyped interface. Fixing it is hard (ugh) but when adding new variants should/could we consider to please make it a typed (eg inline and not a define) interface 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/
Re: mouse still losing sync and thus jumping around
On Wed, 23 Feb 2005 17:29:49 +0100, Nils Kalchhauser <[EMAIL PROTECTED]> wrote: > Dmitry Torokhov wrote: > > On Wed, 23 Feb 2005 14:22:42 +0100, Nils Kalchhauser > > There were 2 versions of the psmouse-resend patch, the first one was > > indeed producing worse results, the second one should work better. > > Could you please try grabbing the patch against 2.6.10 from here: > > > > http://www.geocities.com/dt_or/input/2_6_10/ > > > > and letting me know if it gives better results. > > sorry for not realising that there was a newer patch. I tried that one > now and indeed it seems a lot better. I did not have any lost sync > message for about an hour but then the mouse started jumping again. and Was it clicking around or just the movement was jerky? > it seems to me like it is connected to disk activity... is that possible? Yes, It usually happens either under high load, when mouse interrupts are significantly delayed. Or sometimes it happen when applications poll battey status and on some boxes it takes pretty long time. And because it is usually the same chip that serves keyboard/mouse it again delays mouse interrupts. Btw, what kind of laptop/touchpad is that? -- 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/
More latency regressions with 2.6.11-rc4-RT-V0.7.39-02
Ingo,
Did something change recently in the VM that made copy_pte_range and
clear_page_range a lot more expensive? I noticed a reference in the
"Page Table Iterators" thread to excessive overhead introduced by
aggressive page freeing. That sure looks like what is going on in
trace2. trace1 and trace3 look like big fork latencies associated with
copy_pte_range.
This is all with PREEMPT_DESKTOP.
Lee
preemption latency trace v1.1.4 on 2.6.11-rc4-RT-V0.7.39-02
latency: 323 µs, #22/22, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
(T1/#0) valgrind.bin 15934 0 9 0002 [0032064022903959] 0.000ms
(+3534259.157ms): <676c6176> (<646e6972>)
(T1/#2) valgrind.bin 15934 0 9 0002 0002 [0032064022904377] 0.000ms
(+0.000ms): __trace_start_sched_wakeup+0x96/0xc0
(try_to_wake_up+0x81/0x150 )
(T1/#3) valgrind.bin 15934 0 9 0003 [0032064022904934] 0.001ms
(+0.000ms): wake_up_process+0x1c/0x30 (do_softirq+0x4b/0x60
)
(T6/#4) valgrind-15934 0dn.22µs!< (1)
(T1/#5) valgrind.bin 15934 0 2 0001 0005 [0032064023088406] 0.307ms
(+0.000ms): preempt_schedule+0xa/0x70 (copy_pte_range+0xb7/0x1c0
)
(T1/#6) valgrind.bin 15934 0 2 0001 0006 [0032064023088847] 0.308ms
(+0.000ms): __cond_resched_raw_spinlock+0x8/0x50
(copy_pte_range+0xa7/0x1c0 )
(T1/#7) valgrind.bin 15934 0 2 0007 [0032064023089269] 0.308ms
(+0.001ms): __cond_resched+0x9/0x70
(__cond_resched_raw_spinlock+0x3d/0x50 )
(T1/#8) valgrind.bin 15934 0 3 0008 [0032064023089903] 0.309ms
(+0.000ms): __schedule+0xe/0x630 (__cond_resched+0x45/0x70
)
(T1/#9) valgrind.bin 15934 0 3 0009 [0032064023090288] 0.310ms
(+0.000ms): profile_hit+0x9/0x50 (__schedule+0x3a/0x630 )
(T1/#10) valgrind.bin 15934 0 3 0001 000a [0032064023090866]
0.311ms (+0.001ms): sched_clock+0xe/0xe0 (__schedule+0x62/0x630
)
(T1/#11) valgrind.bin 15934 0 3 0002 000b [0032064023091857]
0.313ms (+0.000ms): dequeue_task+0xa/0x50 (__schedule+0x1ab/0x630
)
(T1/#12) valgrind.bin 15934 0 3 0002 000c [0032064023092280]
0.313ms (+0.000ms): recalc_task_prio+0xc/0x1a0
(__schedule+0x1c5/0x630 )
(T1/#13) valgrind.bin 15934 0 3 0002 000d [0032064023092690]
0.314ms (+0.000ms): effective_prio+0x8/0x50
(recalc_task_prio+0xa6/0x1a0 )
(T1/#14) valgrind.bin 15934 0 3 0002 000e [0032064023093035]
0.315ms (+0.001ms): enqueue_task+0xa/0x80 (__schedule+0x1cc/0x630
)
(T4/#15) [ => valgrind.bin ] 0.316ms (+0.001ms)
(T1/#16)<...> 2 0 1 0002 0010 [0032064023094748]
0.317ms (+0.001ms): __switch_to+0xb/0x1a0 (__schedule+0x2bd/0x630
)
(T3/#17)<...>-2 0d..2 319µs : __schedule+0x2ea/0x630
(7d 69):
(T1/#18)<...> 2 0 1 0002 0012 [0032064023095766]
0.319ms (+0.000ms): finish_task_switch+0xc/0x90
(__schedule+0x2f6/0x630 )
(T1/#19)<...> 2 0 1 0001 0013 [0032064023096192]
0.320ms (+0.000ms): trace_stop_sched_switched+0xa/0x150
(finish_task_switch+0x43/0x90 )
(T3/#20)<...>-2 0d..1 320µs : trace_stop_sched_switched+0x42/0x150
<<...>-2> (69 0):
(T1/#21)<...> 2 0 1 0001 0015 [0032064023097511]
0.322ms (+0.000ms): trace_stop_sched_switched+0xfe/0x150
(finish_task_switch+0x43/0x90 )
vim:ft=help
preemption latency trace v1.1.4 on 2.6.11-rc4-RT-V0.7.39-02
latency: 361 µs, #289/289, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
(T1/#0)evolution 16047 0 9 0002 [0032772517080312] 0.000ms
(+3483891.566ms): <6c6f7665> (<6f697475>)
(T1/#2)evolution 16047 0 9 0002 0002 [0032772517080803] 0.000ms
(+0.000ms): __trace_start_sched_wakeup+0x96/0xc0
(try_to_wake_up+0x81/0x150 )
(T1/#3)evolution 16047 0 9 0003 [0032772517081392] 0.001ms
v2.4 megaraid2 update Re: [PATCH] Prevent NMI oopser
Hi, As the megaraid2 maintainers dont seem to care about v2.4 mainline at all, completly ignoring my requests to fix the NMI oopser bug for several months, I'm applying the RHEL3 update + inline reordering, which should do it. At this point I'm quite sure they wont answer this message either. :( Thanks Vasily and Andrey. On Mon, Feb 07, 2005 at 11:27:45PM +0300, Andrey J. Melnikoff (TEMHOTA) wrote: > Hi Matt, Marcelo! > On Wed, Feb 02, 2005 at 02:19:14PM -0600, Matt Domsch wrote next: > > > On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote: > > > >As a hack, one could #define inline /*nothing*/ in megaraid2.h to > > > >avoid this, but it would be nice if the functions could all get > > > >reordered such that inlining works properly, and the need for function > > > >declarations in megaraid2.h would disappear completely. > > > > > > > > > Could you fix it by additional patch? Or you going to prepare a new one? > > Any chance to include this two patches before 2.4.30 release? > > Vasily Averin patch: > http://marc.theaimsgroup.com/?l=linux-kernel&m=110737085714273&w=2 > And my (incremental) patch: > http://marc.theaimsgroup.com/?l=linux-kernel&m=110738438005846&w=2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c.h: Fix another gcc 4.0 compile failure
On Sun, Feb 20, 2005 at 07:40:24AM -0800, Mickey Stein wrote:
> Greg KH wrote:
>
> >On Sat, Feb 19, 2005 at 08:58:48AM -0800, Mickey Stein wrote:
> >
> >
> >>From: Mickey Stein
> >>Versions: linux-2.6.11-rc4-bk7, gcc4 (GCC) 4.0.0 20050217 (latest fc
> >>rawhide from 19Feb DL)
> >>
> >>gcc4 cvs seems to dislike "include/linux/i2c.h file":
> >>
> >>Error msg: include/linux/i2c.h:{55,194} error: array type has
> >>incomplete element type
> >>
> >>A. Daplas has recently done a workaround for this on another header
> >>file. A thread discussing this
> >>can be found by following the link below:
> >>
> >>http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
> >>
> >>The patch changes the array declaration from "struct x y[]" format to
> >>"struct x *y".
> >>I realize its only a workaround, but the gcc guys seem to be aware of
> >>this.
> >>** Note: I'm a noob at this, so feel free to make chopped liver out of
> >>this if its incorrect.
> >>patch below is also attached since I'm not sure formatting survives
> >>the cut&paste.
> >>
> >>
> >
> >The patch looks sane, but before I apply it, care to also fix up all of
> >the function pointers that are affected by this patch? Also the
> >i2c_transfer() function itself should be changed (not just the header
> >file.)
> >
> >thanks,
> >
> >greg k-h
> >
> >
> >
> Greg,
>
> I took a look for other references similar to those in my first take at
> this and found a couple more files.
> Attached is another patch that hopefully addresses the all the similar
> cases. I tried it on today's (-bk8) kernel,
> with all i2c switches enabled.
What about the i2c drivers that implement the master_xfer function? You
will now have a bunch of compiler warnings if you build them with this
patch, right?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bootsplash for 2.6.11-rc4
On Sun, Feb 20, 2005 at 02:15:05PM +0100, Michal Januszewski wrote: > On Sat, Feb 19, 2005 at 03:03:26PM -0800, Greg KH wrote: > > > Pavel, I agree with Michal, take a look at this version of the code > > instead of the version that you posted. It's a _whole_ lot more sane, > > and possibly even mergable. > > > > Michal, any thoughts on submitting it for inclusion? It seems pretty > > stable now. > > It is pretty stable indeed, I haven't had any major bug reports for > quite some time now. It's probably as ready as it's ever going to be. > So the question is: what should I do with it? Who do I send it to? As per Documentation/SubmittingPatches, you take the patch, split it up into logic parts, and post it here at lkml, with a Signed-off-by: line and a good ChangeLog description in each email. We can take it from there... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
Olof Johansson wrote: > On Wed, Feb 23, 2005 at 07:54:06AM -0800, Linus Torvalds wrote: > > > > Otherwise, a preempt attempt in get_user would not be seen > > > until some future preempt_enable was executed. > > > > True. I guess we should have a "preempt_check_resched()" there too. That's > > what "kunmap_atomic()" does too (which is what we rely on in the other > > case we do this..) > > Ok, this is getting complex enough to warrant get_user_inatomic(), > which means adding it to every arch's uaccess.h. > > Below patch does so. Unfortunately I don't have a Viro setup with cross > compilers for nearly every arch, so I can't make sure it doesn't break > anything. But since I pasted the same code everywhere it shouldn't. My turn to say uglee. Firstly, get_user_inatomic is the wrong name. "inatomic" in __copy_from_user_inatomic means it's called inside a non-premptable region (in atomic...). Your macro get_user_inatomic is _not_ called inside a non-preemptable region, so it shouldn't be called "inatomic". (A better name is get_user_no_paging). Secondly, does this _one_ use (it's not likely to be used elsewhere) justify copying & pasting the same code into every asm-*/uaccess, especially when the code is not in any way arch-specific? I suggest putting it into futex.c, and make it an inline function which takes "u32 __user *". -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
On Wed, 23 Feb 2005, Jamie Lokier wrote: > > I suggest putting it into futex.c, and make it an inline function > which takes "u32 __user *". Agreed, except we've traditionally just made it "int __user *". Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Removes unnecessary "if" statement from drivers/block/z2ram.c
This Patch removes unnecessary "if" statement from a function without
implementation (in kernel 2.6.x and 2.4.x),
the function returns "0" with or without the "if" statement.
Signed-off-by: Telemaque Ndizihiwe <[EMAIL PROTECTED]>
--- linux-2.6.10/drivers/block/z2ram.c.orig2005-02-23
18:02:51.011967584 +
+++ linux-2.6.10/drivers/block/z2ram.c2005-02-23 18:05:31.617551824
+
@@ -304,9 +304,6 @@ err_out:
static int
z2_release( struct inode *inode, struct file *filp )
{
-if ( current_device == -1 )
-return 0;
-
/*
* FIXME: unmap memory
*/
--- linux-2.6.10/drivers/block/z2ram.c.orig 2005-02-23 18:02:51.011967584 +
+++ linux-2.6.10/drivers/block/z2ram.c 2005-02-23 18:05:31.617551824 +
@@ -304,9 +304,6 @@ err_out:
static int
z2_release( struct inode *inode, struct file *filp )
{
-if ( current_device == -1 )
- return 0;
-
/*
* FIXME: unmap memory
*/
[PATCH] Replaces (2 * HZ) with DATA_TIMEOUT in /drivers/usb/atm/speedtch.c
This Patch replaces "(2 * HZ)" with "DATA_TIMEOUT" which is defined as
#define DATA_TIMEOUT (2 * HZ)
in /drivers/usb/atm/speedtch.c in kernel 2.6.10.
Signed-off-by: Telemaque Ndizihiwe <[EMAIL PROTECTED]>
--- linux-2.6.10/drivers/usb/atm/speedtch.c.orig2005-02-20
12:44:22.235267848 +
+++ linux-2.6.10/drivers/usb/atm/speedtch.c2005-02-20
12:50:52.205983288 +
@@ -494,7 +494,7 @@ static void speedtch_upload_firmware(str
/* URB 7 */
if (dl_512_first) {/* some modems need a read before writing
the firmware */
ret = usb_bulk_msg(usb_dev, usb_rcvbulkpipe(usb_dev,
SPEEDTCH_ENDPOINT_FIRMWARE),
- buffer, 0x200, &actual_length, 2 * HZ);
+ buffer, 0x200, &actual_length, DATA_TIMEOUT);
if (ret < 0 && ret != -ETIMEDOUT)
dbg("speedtch_upload_firmware: read BLOCK0 from modem
failed (%d)!", ret);
--- linux-2.6.10/drivers/usb/atm/speedtch.c.orig2005-02-20
12:44:22.235267848 +
+++ linux-2.6.10/drivers/usb/atm/speedtch.c 2005-02-20 12:50:52.205983288
+
@@ -494,7 +494,7 @@ static void speedtch_upload_firmware(str
/* URB 7 */
if (dl_512_first) { /* some modems need a read before writing the
firmware */
ret = usb_bulk_msg(usb_dev, usb_rcvbulkpipe(usb_dev,
SPEEDTCH_ENDPOINT_FIRMWARE),
- buffer, 0x200, &actual_length, 2 * HZ);
+ buffer, 0x200, &actual_length, DATA_TIMEOUT);
if (ret < 0 && ret != -ETIMEDOUT)
dbg("speedtch_upload_firmware: read BLOCK0 from modem
failed (%d)!", ret);
Re: [PATCH/RFC] Futex mmap_sem deadlock
On Wed, Feb 23, 2005 at 06:22:04PM +, Jamie Lokier wrote: > Olof Johansson wrote: > > On Wed, Feb 23, 2005 at 07:54:06AM -0800, Linus Torvalds wrote: > > > > > > Otherwise, a preempt attempt in get_user would not be seen > > > > until some future preempt_enable was executed. > > > > > > True. I guess we should have a "preempt_check_resched()" there too. > > > That's > > > what "kunmap_atomic()" does too (which is what we rely on in the other > > > case we do this..) > > > > Ok, this is getting complex enough to warrant get_user_inatomic(), > > which means adding it to every arch's uaccess.h. > > > > Below patch does so. Unfortunately I don't have a Viro setup with cross > > compilers for nearly every arch, so I can't make sure it doesn't break > > anything. But since I pasted the same code everywhere it shouldn't. > > My turn to say uglee. Yeah, I wasn't entirely happy about it, but it seems that suggestions are coming in on how to do it better. :-) > Firstly, get_user_inatomic is the wrong name. > > "inatomic" in __copy_from_user_inatomic means it's called inside a > non-premptable region (in atomic...). > > Your macro get_user_inatomic is _not_ called inside a > non-preemptable region, so it shouldn't be called "inatomic". > > (A better name is get_user_no_paging). > > Secondly, does this _one_ use (it's not likely to be used elsewhere) > justify copying & pasting the same code into every asm-*/uaccess, > especially when the code is not in any way arch-specific? Arjan suggested creating a linux/uaccess.h that includes asm/uaccess.h, and start moving the users over since that's where the trend is moving anyway (avoiding including asm/* from common code). futex.c would be the first user, and could be followed by more later as a janitorial patch. That'd mean only one addition of the common function instead of having to add it to every arch. > I suggest putting it into futex.c, and make it an inline function > which takes "u32 __user *". Sure, for now that's good enough. Above janitorial work could be done later, if more users get introduced. -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
Olof Johansson <[EMAIL PROTECTED]> wrote: > > Alternately, you could just have do_page_fault() do: > > > > while (!down_read_trylock(¤t->mm->mmap_sem)) > > continue; > > > > However, note that this can suffer from starvation due to a never ending > > flow of mixed write-locks and read-locks on other CPUs. Unlikely, true, > > but not impossible. > > How can this help? > > The semaphore is held for reading by the thread that faulted in > futex_wait() -> get_user(), so no writers will be let through. Until the > writer has been let through, the down_read_trylock will never succeed > either. No forward progress can be made even with the above loop. You're right. The "writers" would have to spin instead. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
Linus Torvalds wrote: > > I suggest putting it into futex.c, and make it an inline function > > which takes "u32 __user *". > > Agreed, except we've traditionally just made it "int __user *". The type signatures in futex.c are a bit mixed up - most places say "int __user *" but sys_futex() says "u32 __user *". get_futex_key uses sizeof(u32) to check the address. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Replaces (2 * HZ) with DATA_TIMEOUT in /drivers/usb/atm/speedtch.c
On Wed, 23 Feb 2005, Telemaque Ndizihiwe wrote: > > This Patch replaces "(2 * HZ)" with "DATA_TIMEOUT" which is defined as > #define DATA_TIMEOUT (2 * HZ) > in /drivers/usb/atm/speedtch.c in kernel 2.6.10. Your patches are white-space damaged due to linewrap (and possibly other issues, but the line-wrap was the obvious one). Looks like you use Thunderbird, and I'm sure there's some way to just tell it to not mess with whitespace. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
Guillaume Thouvenin wrote: On Tue, 2005-02-22 at 23:20 -0800, Andrew Morton wrote: Kaigai Kohei <[EMAIL PROTECTED]> wrote: The common agreement for the method of dealing with process aggregation has not been constructed yet, I understood. And, we will not able to integrate each process aggregation model because of its diverseness. For example, a process which belong to JOB-A must not belong any other 'JOB-X' in CSA-model. But, In ELSA-model, a process in BANK-B can concurrently belong to BANK-B1 which is a child of BANK-B. And, there are other defferences: Whether a process not to belong to any process-aggregation is permitted or not ? Whether a process-aggregation should be inherited to child process or not ? (There is possibility not to be inherited in a rule-based process aggregation like CKRM) Some process-aggregation model have own philosophy and implemantation, so it's hard to integrate. Thus, I think that common 'fork/exec/exit' event handling framework to implement any kinds of process-aggregation. I can add "policies". With ELSA, a process belongs to one or several groups and if a process is removed from one group, its children still belong to the group. Thus a good idea could be to associate a "philosophy" to a group. For exemple, when a group of processes is created it can be tagged as UNIQUE or SHARED. UNIQUE means that a process that belongs to it could not be added in another group by opposition to SHARED. It's not needed inside the kernel. This makes sense to me. CSA can use the UNIQUE policy to enforce its "can't escape from job container" philisophy. We really want to avoid doing such stuff in-kernel if at all possible, of course. Is it not possible to implement the fork/exec/exit notifications to userspace so that a daemon can track the process relationships and perform aggregation based upon individual tasks' accounting? That's what one of the accounting systems is proposing doing, I believe. It's what I'm proposing. The problem is to be alerted when a new process is created in order to add it in the correct group of processes if the parent belongs to one (or several) groups. The notification can be done with the fork connector patch. I am not quite comfortable of ELSA requesting a fork hook this way. How many hooks in the stock kernel that are related to accounting? Can anyone answer this question? I know of 'acct_process()' in exit.c used by the BSD accounting and ELSA is requesting a hook in fork. If people raise the same question again a few years later, how many people will still remember this ELSA hook? That was the reason i thought a central piece was a good idea. I would rather see the fork hook is coded in acct.c and then invokes a routine that handles what ELSA needs. If CSA would adopt the ELSA's daemon's approach, CSA may also need to use the fork hook. Actually the acct_process() was modified not long ago to become a wrapper, which then invokes do_acct_process() which is completely BSD specific. The fork hook can be the same. - jay (In fact, why do we even need the notifications? /bin/ps can work this stuff out). Yes it can but the risk is to lose some forks no? I think that /bin/ps is using the /proc interface. If we're polling the /proc to catch process creation we may lost some of them. With the fork connector we catch all forks and we can check that by using the sequence number (incremented by each fork) of the message. Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [BK] upgrade will be needed
d.c wrote: El Fri, 18 Feb 2005 13:34:23 -0500 (EST), "Sean" <[EMAIL PROTECTED]> escribió: BK already feeds patches out at the head, surely if it's as powerful as you think, it could feed a free SCM too for your non-bk friends in the community. Who cares, really? 1) Linux was never supposed to have a "head", but -pre/-rc diff patches 2) And more important, *nobody* works against "linus' bk head". Everyone who is implementing something so intrusive that needs to keep track of the "development head" developes again the _true_ "head" of the linux kernel - akpm's tree. If I wanted to develop something which would eventually go into mainline, I certainly would do it against Linus' tree. There are many things going on in -mm which might or might not require significant changes in approach to work. I think -mm is a great place to try the scheduler of the week, but unless some feature requires one of those, it's easier to start from a known base. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: More latency regressions with 2.6.11-rc4-RT-V0.7.39-02
On Wed, 23 Feb 2005, Lee Revell wrote: > > Did something change recently in the VM that made copy_pte_range and > clear_page_range a lot more expensive? I noticed a reference in the > "Page Table Iterators" thread to excessive overhead introduced by > aggressive page freeing. That sure looks like what is going on in > trace2. trace1 and trace3 look like big fork latencies associated with > copy_pte_range. I'm just about to test this patch below: please give it a try: thanks... Ingo's patch to reduce scheduling latencies, by checking for lockbreak in copy_page_range, was in the -VP and -mm patchsets some months ago; but got preempted by the 4level rework, and not reinstated since. Restore it now in copy_pte_range - which mercifully makes it easier. Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> --- 2.6.11-rc4-bk9/mm/memory.c 2005-02-21 11:32:19.0 + +++ linux/mm/memory.c 2005-02-23 18:35:28.0 + @@ -328,6 +328,7 @@ static int copy_pte_range(struct mm_stru pte_t *s, *d; unsigned long vm_flags = vma->vm_flags; +again: d = dst_pte = pte_alloc_map(dst_mm, dst_pmd, addr); if (!dst_pte) return -ENOMEM; @@ -338,11 +339,22 @@ static int copy_pte_range(struct mm_stru if (pte_none(*s)) continue; copy_one_pte(dst_mm, src_mm, d, s, vm_flags, addr); + /* +* We are holding two locks at this point - either of them +* could generate latencies in another task on another CPU. +*/ + if (need_resched() || + need_lockbreak(&src_mm->page_table_lock) || + need_lockbreak(&dst_mm->page_table_lock)) + break; } pte_unmap_nested(src_pte); pte_unmap(dst_pte); spin_unlock(&src_mm->page_table_lock); + cond_resched_lock(&dst_mm->page_table_lock); + if (addr < end) + goto again; return 0; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Futex mmap_sem deadlock
On Wed, Feb 23, 2005 at 06:49:46PM +, Jamie Lokier wrote:
> Linus Torvalds wrote:
> > > I suggest putting it into futex.c, and make it an inline function
> > > which takes "u32 __user *".
> >
> > Agreed, except we've traditionally just made it "int __user *".
>
> The type signatures in futex.c are a bit mixed up - most places say
> "int __user *" but sys_futex() says "u32 __user *". get_futex_key
> uses sizeof(u32) to check the address.
How's this? I went with get_val_no_fault(), since it isn't really a
get_user.*() any more (ptr being passed in), and no_paging is a little
misleading (not all faults are due to paging).
-
Some futex functions do get_user calls while holding mmap_sem for
reading. If get_user() faults, and another thread happens to be in mmap
(or somewhere else holding waiting on down_write for the same semaphore),
then do_page_fault will deadlock. Most architectures seem to be exposed
to this.
To avoid it, make sure the page is available. If not, release the
semaphore, fault it in and retry.
I also found another exposure by inspection, moving some of the code
around avoids the possible deadlock there.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: linux-2.5/kernel/futex.c
===
--- linux-2.5.orig/kernel/futex.c 2005-02-21 16:09:38.0 -0600
+++ linux-2.5/kernel/futex.c2005-02-23 13:10:16.0 -0600
@@ -258,6 +258,18 @@
}
}
+static inline int get_val_no_fault(int *dest, int __user *from)
+{
+ int ret;
+
+ inc_preempt_count();
+ ret = __copy_from_user_inatomic(dest, from, sizeof(int));
+ dec_preempt_count();
+ preempt_check_resched();
+
+ return ret;
+}
+
/*
* The hash bucket lock must be held when this is called.
* Afterwards, the futex_q must not be accessed.
@@ -329,6 +341,7 @@
int ret, drop_count = 0;
unsigned int nqueued;
+ retry:
down_read(¤t->mm->mmap_sem);
ret = get_futex_key(uaddr1, &key1);
@@ -355,9 +368,20 @@
before *uaddr1. */
smp_mb();
- if (get_user(curval, (int __user *)uaddr1) != 0) {
- ret = -EFAULT;
- goto out;
+ ret = get_val_no_fault(&curval, (int __user *)uaddr1);
+
+ if (unlikely(ret)) {
+ /* If we would have faulted, release mmap_sem, fault
+* it in and start all over again.
+*/
+ up_read(¤t->mm->mmap_sem);
+
+ ret = get_user(curval, (int __user *)uaddr1);
+
+ if (!ret)
+ goto retry;
+
+ return ret;
}
if (curval != *valp) {
ret = -EAGAIN;
@@ -480,6 +504,7 @@
int ret, curval;
struct futex_q q;
+ retry:
down_read(¤t->mm->mmap_sem);
ret = get_futex_key(uaddr, &q.key);
@@ -508,9 +533,23 @@
* We hold the mmap semaphore, so the mapping cannot have changed
* since we looked it up in get_futex_key.
*/
- if (get_user(curval, (int __user *)uaddr) != 0) {
- ret = -EFAULT;
- goto out_unqueue;
+
+ ret = get_val_no_fault(&curval, (int __user *)uaddr);
+
+ if (unlikely(ret)) {
+ /* If we would have faulted, release mmap_sem, fault it in and
+* start all over again.
+*/
+ up_read(¤t->mm->mmap_sem);
+
+ if (!unqueue_me(&q)) /* There's a chance we got woken already */
+ return 0;
+
+ ret = get_user(curval, (int __user *)uaddr);
+
+ if (!ret)
+ goto retry;
+ return ret;
}
if (curval != val) {
ret = -EWOULDBLOCK;
Index: linux-2.5/mm/mempolicy.c
===
--- linux-2.5.orig/mm/mempolicy.c 2005-02-04 00:27:40.0 -0600
+++ linux-2.5/mm/mempolicy.c2005-02-23 12:53:22.0 -0600
@@ -524,9 +524,13 @@
} else
pval = pol->policy;
- err = -EFAULT;
+ if (vma) {
+ up_read(¤t->mm->mmap_sem);
+ vma = NULL;
+ }
+
if (policy && put_user(pval, policy))
- goto out;
+ return -EFAULT;
err = 0;
if (nmask) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: intel8x0: no sound in 2.6.11 rc3 & 4 (fine with 2.6.10)
[EMAIL PROTECTED] wrote: Hello I have read a post in lkml.org that states that the problem experienced in rc3 has gone (1). That is not the case for me. My audio device is :00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) Subsystem: IBM: Unknown device 0554 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- In 2.6.10 and in 2.6.11-rc3 & 4 the clock is set to 48khz. eg: intel8x0_measure_ac97_clock: measured 49502 usecs intel8x0: clocking to 48000 It uses an Analog Devices AD1981B I have put a tar file of the /proc/asound directory of 2.6.10 and 2.6.11-rc4 in http://pusa.uv.es/~ulisses/asound-intel8x0/ the tar files were done while playing pcm audio, (not being eard in rc4). I have found that I had to Mute __both__ "Headphone Jack Sense" and "Line Jack Sense" in order to ear the audio in rc4. I keep seeing this advice, but what tool do you use to mute them? I don't see anything like that in alsamixer, aumix, or any other program I tried. Please let me know if you need further info or you want a tester All this is on a IBM Thinkpad R51 - Type 2887 -AVG ASUS 1681 - same symptoms. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Call for help: list of machines with working S3
On Mon, 14 Feb 2005 22:11:05 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
> Table of known working systems:
>
> Model hack (or "how to do it")
> --
> IBM TP R32 / Type 2658-MMG none (1)
> Athlon HP Omnibook XE3 none (1)
> Compaq Armada E500 - P3-700 none (1) (S1 also works OK)
> IBM t41pnone (1)
I am not sure if this is a problem with my machine or the code, but my
T41p does not work "correctly." [1] Pressing the sleep key (Fn-F4),
does sleep the machine, very quickly and nicely. However, on wake-up,
only an external CRT will display video. I see the LCD's backlight
come on, but no video is displayed there. I also noticed that my USB
mouse does not seem to work (this may be a BIOS setting issue, which
I'll check out on next reboot -- soon).
I have noticed that the IBM ACPI extras seems to do some things
incorrectly for me. /proc/acpi/ibm/dock always reports "status:
undocked," even though I'm very much docked right now. Echo'ing
auto_enable/auto_disable into /proc/acpi/ibm/video does change the
auto state, but doing the same for {lcd,crt}_{enable,disable} does
nothing (including not changing the displayed state).
I'm more than happy to try patches, BIOS setting changes, etc.
Thanks,
Nish
[1] Attached dmidecode output (hopefully not screwed up by gmail)
dmidecode.out
Description: Binary data
Linux 2.4.30-pre2
Hi, Here goes the second pre of v2.4.30. It contains a bunch of important networking fixes, most noticeably the brlocks rework. Plus USB fixes, megaraid2 driver update, JFS update, amongst others. Read the changelog for detailed information Summary of changes from v2.4.30-pre1 to v2.4.30-pre2 : o [SPARC32]: Need to clear PSR_EF in psr of childregs on fork() on SMP : o Changed VERSION to v2.4.30-pre2 : o megaraid2 reorder inline functions : o megaraid2 update 2.10.8.2 Charles-Edouard Ruault: o Reserve only needed regions for PC timers on i386 and x86_64 Dave Kleikamp: o JFS: remove invalid NULL assignments to i_sb o JFS: fix livelock waiting for stale metapage o JFS: mount option iocharset=none o JFS: change project url to http://jfs.sourceforge.net/ David S. Miller: o [SPARC]: Fix bogus trailing semicolon in smb_*() macros o [SPARC]: nop() macro has bogus trailing semicolon o [TG3]: Update driver version and reldate o [SPARC64]: Fix trailing semicolon in membar macros o [COMPAT]: TUNSETIFF needs to copy back data after ioctl o [TG3]: Always check tg3_readphy() return value o [TG3]: Update driver version and reldate o [BRLOCKS]: Delete atomic version, is buggy and deadlock prone Domen Puncer: o JFS: delete unused file Eugene Surovegin: o 2.4: fix bogus 440GX rev.C PVR Hideaki Yoshifuji: o [NET]: Fix kernel oops if base_reachable_time is set to 0 Jean Tourrilhes: o [NET]: Backport SIOCSIFNAME wildcarding support from 2.6.x Kenneth Sumrall: o Kenneth Sumrall: In lp_write(), copy_from_user() is called to copy data into a statically allocated kernel buffer before down_interruptible() Michael Chan: o [TG3]: capacitive coupling detection fix Patrick McHardy: o [PKT_SCHED]: Fix u32 double listing o [NETLINK]: Unhash sockets correctly Pete Zaitcev: o USB: ftdi_sio o USB: hid for ia64 o USB: fix modem_run o USB: mct_u232 Stephen Hemminger: o [TCP]: Fix BIC max_cwnd calculation error Stephen Rothwell: o PPC64: 32 bit sys_recvmsg corruption o Fixup 32 bit sys_recvmsg corruption patch Thomas Graf: o [TCP]: Fix calculation for collapsed skb size - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Reserve only needed regions for PC timers on i386 and x86_64
On Mon, Feb 21, 2005 at 02:06:18PM +0100, Charles-Edouard Ruault wrote:
> Alan Cox wrote:
> >On Llu, 2005-02-07 at 09:29, Charles-Edouard Ruault wrote:
> >>- Why is the generic timer using this address ? isn't it reserving a too
> >>wide portion of IO ports ? Should it be modified for this board ?
> >
> >It just reserved the entire chip space since way back when.
> >>- If there's a good reason for the timer to request this address, is
> >>there a clean way to share it with the timer ?
> >
> >Submit a small patch to Linus/Andrew to make the generic code only
> >reserve the ports it should. It's just a historical oversight
> >
> >
> >
> Linus, Andrew,
> As suggested by Alan, here's a small patch against kernel 2.4.29 to
> split the IO addresses reserved for the PC timer into two regions
> instead of a large one.
> It mimics what has been done in kernel 2.6.
> Instead of reserving 0x40 through 0x5f it reserves only what the two
> timers need, i.e 0x40-0x43 and 0x50-0x53.
> It patches both i386 and x86_64 architecture.
Applied,
Thanks Charles.
> --- linux/arch/i386/kernel/setup.c.orig Fri Feb 18 18:46:55 2005
> +++ linux/arch/i386/kernel/setup.cMon Feb 21 11:19:45 2005
> @@ -354,7 +354,8 @@
> struct resource standard_io_resources[] = {
> { "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
> { "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
> - { "timer", 0x40, 0x5f, IORESOURCE_BUSY },
> + { "timer0", 0x40, 0x43, IORESOURCE_BUSY },
> + { "timer1", 0x50, 0x53, IORESOURCE_BUSY },
> { "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
> { "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
> { "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
> --- linux/arch/x86_64/kernel/setup.c.orig Mon Feb 21 11:56:11 2005
> +++ linux/arch/x86_64/kernel/setup.c Mon Feb 21 11:54:41 2005
> @@ -93,7 +93,8 @@
> struct resource standard_io_resources[] = {
> { "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
> { "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
> - { "timer", 0x40, 0x5f, IORESOURCE_BUSY },
> + { "timer0", 0x40, 0x43, IORESOURCE_BUSY },
> + { "timer1", 0x50, 0x53, IORESOURCE_BUSY },
> { "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
> { "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
> { "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: More latency regressions with 2.6.11-rc4-RT-V0.7.39-02
On Wed, 2005-02-23 at 19:16 +, Hugh Dickins wrote:
> On Wed, 23 Feb 2005, Lee Revell wrote:
> >
> > Did something change recently in the VM that made copy_pte_range and
> > clear_page_range a lot more expensive? I noticed a reference in the
> > "Page Table Iterators" thread to excessive overhead introduced by
> > aggressive page freeing. That sure looks like what is going on in
> > trace2. trace1 and trace3 look like big fork latencies associated with
> > copy_pte_range.
>
> I'm just about to test this patch below: please give it a try: thanks...
>
> Ingo's patch to reduce scheduling latencies, by checking for lockbreak
> in copy_page_range, was in the -VP and -mm patchsets some months ago;
> but got preempted by the 4level rework, and not reinstated since.
> Restore it now in copy_pte_range - which mercifully makes it easier.
Aha, that explains why all the latency regressions involve the VM
subsystem.
Thanks, your patch fixes the copy_pte_range latency. Now zap_pte_range,
which Ingo also fixed a few months ago, is the worst offender. Can this
fix be easily ported too?
Lee
preemption latency trace v1.1.4 on 2.6.11-rc4-RT-V0.7.39-02
latency: 197 µs, #74/74, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
(T1/#0)dmesg 3249 0 9 0002 [163455166655] 0.000ms
(+886841.090ms): <73656d64> (<61700067>)
(T1/#2)dmesg 3249 0 9 0002 0002 [163455167105] 0.000ms
(+0.000ms): __trace_start_sched_wakeup+0x96/0xc0
(try_to_wake_up+0x81/0x150 )
(T1/#3)dmesg 3249 0 9 0003 [163455167685] 0.001ms
(+0.001ms): wake_up_process+0x1c/0x30 (do_softirq+0x4b/0x60
)
(T6/#4)dmesg-3249 0dn.22µs < (1)
(T1/#5)dmesg 3249 0 2 0002 0005 [163455168677] 0.003ms
(+0.000ms): page_remove_rmap+0x8/0x40 (zap_pte_range+0x13a/0x250
)
(T1/#6)dmesg 3249 0 2 0002 0006 [163455168975] 0.003ms
(+0.000ms): __mod_page_state+0xa/0x30 (page_remove_rmap+0x2c/0x40
)
(T1/#7)dmesg 3249 0 2 0002 0007 [163455169390] 0.004ms
(+0.000ms): free_page_and_swap_cache+0x9/0x70
(zap_pte_range+0x14c/0x250 )
(T1/#8)dmesg 3249 0 2 0002 0008 [163455169687] 0.005ms
(+0.001ms): __page_cache_release+0xb/0xc0 (zap_pte_range+0x14c/0x250
)
(T1/#9)dmesg 3249 0 2 0002 0009 [163455170314] 0.006ms
(+0.000ms): preempt_schedule+0xa/0x70
(__page_cache_release+0xad/0xc0 )
(T1/#10)dmesg 3249 0 2 0002 000a [163455170636]
0.006ms (+0.000ms): free_hot_page+0x8/0x10
(zap_pte_range+0x14c/0x250 )
(T1/#11)dmesg 3249 0 2 0002 000b [163455170944]
0.007ms (+0.000ms): free_hot_cold_page+0xe/0x130
(zap_pte_range+0x14c/0x250 )
(T1/#12)dmesg 3249 0 2 0002 000c [163455171314]
0.007ms (+0.001ms): __mod_page_state+0xa/0x30
(free_hot_cold_page+0x2a/0x130 )
(T1/#13)dmesg 3249 0 2 0002 000d [163455172090]
0.009ms (+0.000ms): preempt_schedule+0xa/0x70
(zap_pte_range+0x14c/0x250 )
(T1/#14)dmesg 3249 0 2 0002 000e [163455172432]
0.009ms (+0.000ms): set_page_dirty+0x8/0x60
(zap_pte_range+0x168/0x250 )
(T1/#15)dmesg 3249 0 2 0002 000f [163455172774]
0.010ms (+0.000ms): page_remove_rmap+0x8/0x40
(zap_pte_range+0x13a/0x250 )
(T1/#16)dmesg 3249 0 2 0002 0010 [163455173040]
0.010ms (+0.000ms): __mod_page_state+0xa/0x30
(page_remove_rmap+0x2c/0x40 )
(T1/#17)dmesg 3249 0 2 0002 0011 [163455173421]
0.011ms (+0.000ms): free_page_and_swap_cache+0x9/0x70
(zap_pte_range+0x14c/0x250 )
(T1/#18)dmesg 3249 0 2 0002 0012 [163455173704]
0.011ms (+0.001ms): __page_cache_release+0xb/0xc0
(zap_pte_range+0x14c/0x250 )
(T1/#19)dmesg 3249 0 2 0002 0013 [163455174397]
0.012ms (+0.000ms): preempt_schedule+0xa/0x70
(__page_cache_release+0xad/0xc0 )
(T1/#20)dmesg 3249 0 2 0002 0014 [163455174687]
0.013ms (+0.000ms): free_hot_page+0x8/0x10
(zap_pte_range+0x14c/0x250 )
(T1/#21)dmesg 3249 0 2 0002 0015 [163455175101]
0.014ms (+0.000ms): free_hot_cold_page+0xe/0x130
(zap_pte_range+0x14c/0x250 )
(T1/#22)dmesg 3249 0 2 0002 0016 [163455175436]
0.014ms (+0.001ms): __mod_page_state+0xa/0x3
Re: [Patch 6/6] Bind Mount Extensions 0.06
On Tue, Feb 22, 2005 at 09:58:45AM -0500, Trond Myklebust wrote:
> ty den 22.02.2005 Klokka 13:13 (+0100) skreiv Herbert Poetzl:
>
> > diff -NurpP --minimal
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01/arch/sparc64/solaris/fs.c
> >
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01-ro0.01/arch/sparc64/solaris/fs.c
> > ---
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01/arch/sparc64/solaris/fs.c
> >2004-12-25 01:54:50 +0100
> > +++
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01-ro0.01/arch/sparc64/solaris/fs.c
> > 2005-02-19 06:32:05 +0100
> > @@ -362,7 +362,7 @@ static int report_statvfs(struct vfsmoun
> > int j = strlen (p);
> >
> > if (j > 15) j = 15;
> > - if (IS_RDONLY(inode)) i = 1;
> > + if (IS_RDONLY(inode) || (mnt && MNT_IS_RDONLY(mnt))) i = 1;
>
> Redundant check of mnt != NULL.
yep,
> > if (mnt->mnt_flags & MNT_NOSUID) i |= 2;
> > if (!sysv_valid_dev(inode->i_sb->s_dev))
> > return -EOVERFLOW;
> > @@ -398,7 +398,7 @@ static int report_statvfs64(struct vfsmo
> > int j = strlen (p);
> >
> > if (j > 15) j = 15;
> > - if (IS_RDONLY(inode)) i = 1;
> > + if (IS_RDONLY(inode) || (mnt && MNT_IS_RDONLY(mnt))) i = 1;
>
> Redundant check of mnt != NULL
agreed, thanks!
> > if (mnt->mnt_flags & MNT_NOSUID) i |= 2;
> > if (!sysv_valid_dev(inode->i_sb->s_dev))
> > return -EOVERFLOW;
> > diff -NurpP --minimal
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01/fs/namei.c
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01-ro0.01/fs/namei.c
> > --- linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01/fs/namei.c
> > 2005-02-19 06:31:50 +0100
> > +++
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01-ro0.01/fs/namei.c
> >2005-02-19 06:32:05 +0100
> > @@ -220,7 +220,7 @@ int permission(struct inode *inode, int
> > /*
> > * Nobody gets write access to a read-only fs.
> > */
> > - if (IS_RDONLY(inode) &&
> > + if ((IS_RDONLY(inode) || (nd && MNT_IS_RDONLY(nd->mnt))) &&
> > (S_ISREG(mode) || S_ISDIR(mode) || S_ISLNK(mode)))
> > return -EROFS;
>
> This is very dodgy. What if the user is calling permission without
> setting the (currently optional) nameidata hint? Have you audited the
> kernel to find out if this is safe?
safe yes, aybe not 'correct' I agree that moving
the check 'upwards' into the callers might be
the better solution here, will look into it ...
> > diff -NurpP --minimal
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01/fs/open.c
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01-ro0.01/fs/open.c
> > --- linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01/fs/open.c
> > 2005-02-19 06:31:43 +0100
> > +++
> > linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01-ro0.01/fs/open.c
> > 2005-02-19 06:32:05 +0100
> > @@ -239,7 +239,7 @@ static inline long do_sys_truncate(const
> > goto dput_and_out;
> >
> > error = -EROFS;
> > - if (IS_RDONLY(inode))
> > + if (IS_RDONLY(inode) || MNT_IS_RDONLY(nd.mnt))
> > goto dput_and_out;
> >
> > error = -EPERM;
> > @@ -363,7 +363,7 @@ asmlinkage long sys_utime(char __user *
> > inode = nd.dentry->d_inode;
> >
> > error = -EROFS;
> > - if (IS_RDONLY(inode))
> > + if (IS_RDONLY(inode) || MNT_IS_RDONLY(nd.mnt))
> > goto dput_and_out;
> >
> > /* Don't worry, the checks are done in inode_change_ok() */
> > @@ -420,7 +420,7 @@ long do_utimes(char __user * filename, s
> > inode = nd.dentry->d_inode;
> >
> > error = -EROFS;
> > - if (IS_RDONLY(inode))
> > + if (IS_RDONLY(inode) || MNT_IS_RDONLY(nd.mnt))
> > goto dput_and_out;
> >
> > /* Don't worry, the checks are done in inode_change_ok() */
> > @@ -502,7 +502,8 @@ asmlinkage long sys_access(const char __
> > if (!res) {
> > res = permission(nd.dentry->d_inode, mode, &nd);
> > /* SuS v2 requires we report a read only fs too */
> > - if(!res && (mode & S_IWOTH) && IS_RDONLY(nd.dentry->d_inode)
> > + if(!res && (mode & S_IWOTH)
> > + && (IS_RDONLY(nd.dentry->d_inode) || MNT_IS_RDONLY(nd.mnt))
> >&& !special_file(nd.dentry->d_inode->i_mode))
> > res = -EROFS;
> > path_release(&nd);
> > @@ -608,7 +609,7 @@ asmlinkage long sys_fchmod(unsigned int
> > inode = dentry->d_inode;
> >
> > err = -EROFS;
> > - if (IS_RDONLY(inode))
> > + if (IS_RDONLY(inode) || (file && MNT_IS_RDONLY(file->f_vfsmnt)))
> > goto out_putf;
>
> Redundant check of file != NULL.
ack!
> > err = -EPERM;
> > if (IS_IMMUTABLE(inode) || IS_APPE
Re: More latency regressions with 2.6.11-rc4-RT-V0.7.39-02
On Wed, 23 Feb 2005, Lee Revell wrote:
> On Wed, 2005-02-23 at 19:16 +, Hugh Dickins wrote:
> >
> > I'm just about to test this patch below: please give it a try: thanks...
I'm very sorry, there's two things wrong with that version: _must_
increment addr before breaking out, and better to check after pte_none
too (we can question whether it might be checking too often, but this
replicates what Ingo was doing). Please replace by new patch below,
which I'm now running through lmbench.
> Aha, that explains why all the latency regressions involve the VM
> subsystem.
>
> Thanks, your patch fixes the copy_pte_range latency.
Great, if the previous patch fixed that latency then this new one
will too, no need to report on that; but please get rid of the old
patch before it leaks too many of your pages.
> Now zap_pte_range,
> which Ingo also fixed a few months ago, is the worst offender. Can this
> fix be easily ported too?
That surprises me: all the zap_pte_range latency fixes I know of
are in 2.6.11-rc, perhaps Ingo knows of something missing there?
Hugh
Ingo's patch to reduce scheduling latencies, by checking for lockbreak
in copy_page_range, was in the -VP and -mm patchsets some months ago;
but got preempted by the 4level rework, and not reinstated since.
Restore it now in copy_pte_range - which mercifully makes it easier.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
--- 2.6.11-rc4-bk/mm/memory.c 2005-02-21 11:32:19.0 +
+++ linux/mm/memory.c 2005-02-23 19:46:40.0 +
@@ -328,21 +328,33 @@ static int copy_pte_range(struct mm_stru
pte_t *s, *d;
unsigned long vm_flags = vma->vm_flags;
+again:
d = dst_pte = pte_alloc_map(dst_mm, dst_pmd, addr);
if (!dst_pte)
return -ENOMEM;
spin_lock(&src_mm->page_table_lock);
s = src_pte = pte_offset_map_nested(src_pmd, addr);
- for (; addr < end; addr += PAGE_SIZE, s++, d++) {
- if (pte_none(*s))
- continue;
- copy_one_pte(dst_mm, src_mm, d, s, vm_flags, addr);
+ for (; addr < end; s++, d++) {
+ if (!pte_none(*s))
+ copy_one_pte(dst_mm, src_mm, d, s, vm_flags, addr);
+ addr += PAGE_SIZE;
+ /*
+* We are holding two locks at this point - either of them
+* could generate latencies in another task on another CPU.
+*/
+ if (need_resched() ||
+ need_lockbreak(&src_mm->page_table_lock) ||
+ need_lockbreak(&dst_mm->page_table_lock))
+ break;
}
pte_unmap_nested(src_pte);
pte_unmap(dst_pte);
spin_unlock(&src_mm->page_table_lock);
+
cond_resched_lock(&dst_mm->page_table_lock);
+ if (addr < end)
+ goto again;
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BK PATCHES] 2.6.x libata fixes (mostly)
This BK push includes additional hardware support, but that's only
because it's (a) obviously low impact and (b) it was in the queue.
Far more important are:
1) API additions, to fix a severe bug: advanced drivers such as AHCI
were directly bitbanging --non-existent-- PCI IDE registers, causing an
oops, because of function calls buried deep within libata.
Solution: add the necessary hooks that should have existed all along,
for this functionality.
2) Fix stomping on active devices, if pci_request_regions() fails. It
is rather more urgent for libata than other situations, since we must
deal with PCI devices that secretly export ISA device regions (legacy
IDE 0x1f0, 0x170).
3) Fix command queue leak, if SCSI->ATA translation fails.
Please do a
bk pull bk://gkernel.bkbits.net/libata-2.6
This will update the following files:
drivers/scsi/Kconfig|8
drivers/scsi/Makefile |1
drivers/scsi/ahci.c | 18 +
drivers/scsi/ata_piix.c |4
drivers/scsi/libata-core.c | 115 ++-
drivers/scsi/libata-scsi.c |1
drivers/scsi/libata.h |1
drivers/scsi/sata_nv.c | 10
drivers/scsi/sata_promise.c |8
drivers/scsi/sata_qstor.c | 700
drivers/scsi/sata_sil.c | 10
drivers/scsi/sata_sis.c | 10
drivers/scsi/sata_svw.c | 10
drivers/scsi/sata_sx4.c |8
drivers/scsi/sata_uli.c | 10
drivers/scsi/sata_via.c | 213 +
drivers/scsi/sata_vsc.c | 10
include/linux/libata.h | 64
18 files changed, 1058 insertions(+), 143 deletions(-)
through these ChangeSets:
<[EMAIL PROTECTED]> (05/02/23 1.2043)
[libata] Add missing hooks, to avoid oops in advanced SATA drivers
Advanced SATA drivers should not (and cannot) use the basic
PCI IDE hooks for checking the Status and Error registers, as these
registers are either in non-standard locations, or simply don't
exist.
In the error handling path, libata was unconditionally calling some
PCI IDE hardware bitbanging functions, which would cause an oops
in the AHCI driver and any other advanced libata driver.
<[EMAIL PROTECTED]> (05/02/18 1.2040)
[PATCH] libata: fix command queue leak when xlat_func fails
ata_scsi_translate allocates from the libata command queue by calling
ata_scsi_qc_new. If xlat_func returns non-zero, control jumps to
err_out which fails to free the allocated command. Fix is to add a
new API to free unused commands.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> (05/02/17 1.2035.16.1)
[libata] add ->bmdma_{stop,status} hooks
The timeout/error handling path was assuming that the hardware in
question was PCI IDE BMDMA-like, which is incorrect in a few cases.
Turn direct function calls into two new hooks.
<[EMAIL PROTECTED]> (05/02/17 1.2038)
[PATCH] sata_qstor: new basic driver for Pacific Digital
This is a new basic libata SATA driver
for the Pacific Digital QStor SATA/RAID card.
It features ordinary per-drive SATA with single-request DMA
for R/W commands, and PIO for everything else.
It currently does not implement any of the hardware RAID support,
nor hot-plug, nor the tagged/native command-queuing features.
On the other hand, it is small and simple as a result.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> (05/02/13 1.2037)
[libata] do not call pci_disable_device() for certain errors
If PCI request regions fails, then someone else is using the
hardware we wish to use. For that one case, calling pci_disable_device()
is rather rude.
<[EMAIL PROTECTED]> (04/11/16 1.1938.367.2)
[libata sata_via] add support for VT6421 SATA
<[EMAIL PROTECTED]> (04/11/16 1.1938.367.1)
[libata sata_via] minor cleanups
Preparation for addition of VT6421 support. Mostly moving bits
of code into discrete functions.
diff -Nru a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
--- a/drivers/scsi/Kconfig 2005-02-23 14:50:15 -05:00
+++ b/drivers/scsi/Kconfig 2005-02-23 14:50:15 -05:00
@@ -457,6 +457,14 @@
If unsure, say N.
+config SCSI_SATA_QSTOR
+ tristate "Pacific Digital SATA QStor support"
+ depends on SCSI_SATA && PCI
+ help
+ This option enables support for Pacific Digital Serial ATA QStor.
+
+ If unsure, say N.
+
config SCSI_SATA_SX4
tristate "Promise SATA SX4 support"
depends on SCSI_SATA && PCI && EXPERIMENTAL
diff -Nru a/drivers/scsi/Makefile b/drivers/scsi/Makefile
--- a/drivers/scsi/Makefile 2005-02-23 14:50:15 -05:00
+++ b/drivers/scsi/Makefile 2005-02-23 14:50:15 -05:00
@@ -125,6 +125,7 @@
obj-$(CONFIG_SCSI_SATA_SVW)+= libata.o sata_svw.o
obj-$(CONFIG_SCSI_ATA_PIIX)+= libata.o ata_pii
Re: Help tracking down problem --- endless loop in __find_get_block_slow
[EMAIL PROTECTED] (Thomas S. Iversen) wrote: > > > OK, so we're looking for the buffer_head for block 101 and the first > > buffer_head which is attached to the page represents block 100. So the > > next buffer_head _should_ represent block 101. Please print it out: > > Not quite the same, but simelar: > > Feb 23 14:50:24 localhost kernel: __find_get_block_slow() failed. block=102, > b_blocknr=128, next=129 > Feb 23 14:50:24 localhost kernel: b_state=0x0013, b_size=2048 > Feb 23 14:50:24 localhost kernel: device blocksize: 2048 > Feb 23 14:50:24 localhost kernel: [ cut here ] Something has caused the page at offset 51 (block 102) to have buffer_heads for blocks 128 and 129 attached to it. > > Could be UFS. But what does "transparent block encryption and sector > > shuffling" mean? How is the sector shuffling implemented? > > GDBE is a block level encrypter. It encrypts the actual sectors > transparently via the GEOM API (corresponds to the devicemapper api in linux). > > GBDE assigns a key for each block, thereby introducing keysectors. > Furthermore the sectors are remapped so that one can not guess where e.g. > metadata is located on the physical disk. It is a rather simple remap: I'd be suspecting that the sector remapping is the cause of the problem. How is it implemented? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
