Re: PCMCIA WLAN card initialization error
Hi,
I am resending this to the orinoco devel mailing list.
Today I have tried using a Linksys WPC11 WLAN card and another Senao
NL2511 Plus and I am seeing the same errors in the kernel log and
again, the network interface does not show up with iwconfig.
These two cards are known to be working under windows xp.
Linksys WPC11
Feb 19 08:59:30 bonsai pccard: card ejected from slot 0
Feb 19 08:59:39 bonsai pccard: PCMCIA card inserted into slot 0
Feb 19 08:59:39 bonsai pcmcia: registering new device pcmcia0.0
Feb 19 08:59:39 bonsai pcmcia: request for exclusive IRQ could not be fulfilled.
Feb 19 08:59:39 bonsai pcmcia: the driver needs updating to supported shared
IRQ lines.
Feb 19 08:59:39 bonsai eth2: failed to initialize firmware (err = -19)
Feb 19 08:59:39 bonsai orinoco_cs: register_netdev() failed
Feb 19 08:59:39 bonsai pcmcia: request for exclusive IRQ could not be fulfilled.
Feb 19 08:59:39 bonsai pcmcia: the driver needs updating to supported shared
IRQ lines.
Feb 19 08:59:39 bonsai eth2: failed to initialize firmware (err = -19)
Feb 19 08:59:39 bonsai orinoco_cs: register_netdev() failed
SENAO NL2511 Plus
Feb 19 09:01:21 bonsai pccard: card ejected from slot 0
Feb 19 09:01:40 bonsai pccard: PCMCIA card inserted into slot 0
Feb 19 09:01:40 bonsai pcmcia: registering new device pcmcia0.0
Feb 19 09:01:40 bonsai pcmcia: request for exclusive IRQ could not be fulfilled.
Feb 19 09:01:40 bonsai pcmcia: the driver needs updating to supported shared
IRQ lines.
Feb 19 09:01:40 bonsai eth2: failed to initialize firmware (err = -19)
Feb 19 09:01:40 bonsai orinoco_cs: register_netdev() failed
Feb 19 09:01:40 bonsai pcmcia: request for exclusive IRQ could not be fulfilled.
Feb 19 09:01:40 bonsai pcmcia: the driver needs updating to supported shared
IRQ lines.
Feb 19 09:01:40 bonsai eth2: failed to initialize firmware (err = -19)
Feb 19 09:01:40 bonsai orinoco_cs: register_netdev() failed
Feb 19 09:01:56 bonsai pccard: card ejected from slot 0
Timur
Timur Aydin <[EMAIL PROTECTED]> writes:
> Hi,
>
> I have a Prism based PCMCIA WLAN card, which I want to use in my
> workstation PC. I am using a Ricoh RL5c475 based PCMCIA/PCI bridge to
> attach the card to one of the empty PCI slots. I want to use this PC
> as a wireless access point (with hostap), but first I want to make
> sure the card works, so I first want to use the card as a client to an
> existing wireless access point. So I compiled support into the linux
> kernel for only the hermes chipset and the yenta driver (no hostap
> right now).
>
> The problem is that when iwconfig is issued, the wireless interface
> does not show up.
>
> I am seeing some error or warning messages in the kernel logs, but I
> am not sure if they are relevant to this. For example:
>
> ...
> orinoco 0.15 (David Gibson <[EMAIL PROTECTED]>, Pavel Roskin <[EMAIL
> PROTECTED]>, et al)
> orinoco_cs 0.15 (David Gibson <[EMAIL PROTECTED]>, Pavel Roskin <[EMAIL
> PROTECTED]>, et al)
> pcmcia: request for exclusive IRQ could not be fulfilled.
> pcmcia: the driver needs updating to supported shared IRQ lines.
> eth2: failed to initialize firmware (err = -19)
> orinoco_cs: register_netdev() failed
> pcmcia: request for exclusive IRQ could not be fulfilled.
> pcmcia: the driver needs updating to supported shared IRQ lines.
> eth2: failed to initialize firmware (err = -19)
> orinoco_cs: register_netdev() failed
> ...
>
>
> I am also seeing resource allocation errors:
>
> PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for :02:08.0
> PCI: Bus 3, cardbus bridge: :02:08.0
> IO window: 9000-90ff
> IO window: 9400-94ff
> PREFETCH window: 5000-51ff
> PCI: Bridge: :00:0e.0
> IO window: 9000-afff
> MEM window: f500-f6ff
> PREFETCH window: 5000-52ff
>
> I am not sure, but I think the actual error is the (err = -19). I have
> added some extra printk's into hermes.c. This error originates from
> the hermes_init function in hermes.c:
>
> /* Normally it's a "can't happen" for the command register to
>be busy when we go to issue a command because we are
>serializing all commands. However we want to have some
>chance of resetting the card even if it gets into a stupid
>state, so we actually wait to see if the command register
>will unbusy itself here. */
> k = CMD_BUSY_TIMEOUT;
> reg = hermes_read_regn(hw, CMD);
> while (k && (reg & HERMES_CMD_BUSY)) {
> if (reg == 0x) /* Special case - the card has probably been
> removed,
> so don't wait for the timeout */
> return -ENODEV;
>
> k--;
> udelay(1);
> reg = hermes_read_regn(hw, CMD);
> }
>
> reg is indeed 0x and the function returns -ENODEV.
>
> I need help to further troubleshoot the problem, any directions or
> hints welcome...
>
> Here is the
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of > requests (reads partition > table, fs superblocks and such - plenty of room for critical errors). Then, > driver's remove method > will not be called before driver's probe method had finished. So mmc_block is > quite involved, even > though it does not affect the problem's resolution. I agree that mmc_block's probe method will generate a whole bunch of requests. But I don't see how that can be called given the scenario you describe. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH][4/4] RSS controller documentation
Signed-off-by: <[EMAIL PROTECTED]> --- Documentation/memctlr.txt | 70 ++ 1 file changed, 70 insertions(+) diff -puN /dev/null Documentation/memctlr.txt --- /dev/null 2007-02-02 22:51:23.0 +0530 +++ linux-2.6.20-balbir/Documentation/memctlr.txt 2007-02-19 00:51:44.0 +0530 @@ -0,0 +1,70 @@ +Introduction + + +The memory controller is a controller module written under the containers +framework. It can be used to limit the resource usage of a group of +tasks grouped by the container. + +Accounting +-- + +The memory controller tracks the RSS usage of the tasks in the container. +The definition of RSS was debated on lkml in the following thread + + http://lkml.org/lkml/2006/10/10/130 + +This patch is flexible, it is easy to adapt the patch to any definition +of RSS. The current accounting is based on the current definition of +RSS. Each page mapped is charged to the container. + +The accounting is done at two levels, each process has RSS accounting in +the mm_struct and in the container it belongs to. The mm_struct accounting +is used when a task switches (migrates to a different) container(s). The +accounting information for the task is subtracted from the source container +and added to the destination container. If as result of the migration, the +destination container goes over limit, no action is taken until some task +in the destination container runs and tries to map a new page in its +page table. + +The current RSS usage can be seen in the memctlr_usage file. The value +is in units of pages. + +Control +--- + +The memctlr_limit file allows the user to set a limit on the number of +pages that can be mapped by the processes in the container. A special +value of 0 (which is the default limit of any new container), indicates +that the container can use unlimited amount of RSS. + +Reclaim +--- + +When the limit set in the container is hit, the memory controller starts +reclaiming pages belonging to the container (simulating a local LRU in +some sense). isolate_lru_pages() has been modified to isolate lru +pages belonging to a specific container. Parallel reclaims on the same +container are not allowed, other tasks end up waiting for the any existing +reclaim to finish. + +The reclaim code uses two internal knobs, retries and pushback. pushback +specifies the percentage of memory to be reclaimed when the container goes +over limit. The retries knob, controls how many times reclaim is retried +before the task is killed (because reclaim failed). + +Shared pages are treated specially during reclaim. They are not force +reclaimed, they are only unmapped from containers which are over limit. +This ensures that other containers do not pay a penalty for a shared +page being reclaimed when a paritcular container goes over its limit. + +NOTE: All limits are hard limits. + +Future Plans + + +The current controller implements only RSS control. It is planned to add +the following components + +1. Page Cache control +2. mlock'ed memory control +3. kernel memory allocation control (memory allocated on behalf of a task) _ -- Warm Regards, Balbir Singh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH][3/4] Add reclaim support
This patch reclaims pages from a container when the container limit is hit.
The executable is oom'ed only when the container it is running in, is overlimit
and we could not reclaim any pages belonging to the container
A parameter called pushback, controls how much memory is reclaimed when the
limit is hit. It should be easy to expose this knob to user space, but
currently it is hard coded to 20% of the total limit of the container.
isolate_lru_pages() has been modified to isolate pages belonging to a
particular container, so that reclaim code will reclaim only container
pages. For shared pages, reclaim does not unmap all mappings of the page,
it only unmaps those mappings that are over their limit. This ensures
that other containers are not penalized while reclaiming shared pages.
Parallel reclaim per container is not allowed. Each controller has a wait
queue that ensures that only one task per control is running reclaim on
that container.
Signed-off-by: <[EMAIL PROTECTED]>
---
include/linux/memctlr.h |8 ++
include/linux/rmap.h| 13 +++-
include/linux/swap.h|4 +
mm/memctlr.c| 137
mm/migrate.c|2
mm/rmap.c | 96 +++--
mm/vmscan.c | 94
7 files changed, 324 insertions(+), 30 deletions(-)
diff -puN include/linux/memctlr.h~memctlr-reclaim-on-limit
include/linux/memctlr.h
--- linux-2.6.20/include/linux/memctlr.h~memctlr-reclaim-on-limit
2007-02-18 23:29:14.0 +0530
+++ linux-2.6.20-balbir/include/linux/memctlr.h 2007-02-18 23:29:14.0
+0530
@@ -20,6 +20,7 @@ enum {
};
#ifdef CONFIG_CONTAINER_MEMCTLR
+#include
struct res_counter {
atomic_long_t usage;/* The current usage of the resource being */
@@ -33,6 +34,9 @@ extern void memctlr_mm_free(struct mm_st
extern void memctlr_mm_assign_container(struct mm_struct *mm,
struct task_struct *p);
extern int memctlr_update_rss(struct mm_struct *mm, int count, bool check);
+extern int memctlr_mm_overlimit(struct mm_struct *mm, void *sc_cont);
+extern wait_queue_head_t memctlr_reclaim_wq;
+extern bool memctlr_reclaim_in_progress;
#else /* CONFIG_CONTAINER_MEMCTLR */
@@ -56,5 +60,9 @@ static inline int memctlr_update_rss(str
return 0;
}
+int memctlr_mm_overlimit(struct mm_struct *mm, void *sc_cont)
+{
+ return 0;
+}
#endif /* CONFIG_CONTAINER_MEMCTLR */
#endif /* _LINUX_MEMCTLR_H */
diff -puN include/linux/rmap.h~memctlr-reclaim-on-limit include/linux/rmap.h
--- linux-2.6.20/include/linux/rmap.h~memctlr-reclaim-on-limit 2007-02-18
23:29:14.0 +0530
+++ linux-2.6.20-balbir/include/linux/rmap.h2007-02-18 23:29:14.0
+0530
@@ -90,7 +90,15 @@ static inline void page_dup_rmap(struct
* Called from mm/vmscan.c to handle paging out
*/
int page_referenced(struct page *, int is_locked);
-int try_to_unmap(struct page *, int ignore_refs);
+int try_to_unmap(struct page *, int ignore_refs, void *container);
+#ifdef CONFIG_CONTAINER_MEMCTLR
+bool page_in_container(struct page *page, struct zone *zone, void *container);
+#else
+static inline bool page_in_container(struct page *page, struct zone *zone,
void *container)
+{
+ return true;
+}
+#endif /* CONFIG_CONTAINER_MEMCTLR */
/*
* Called from mm/filemap_xip.c to unmap empty zero page
@@ -118,7 +126,8 @@ int page_mkclean(struct page *);
#define anon_vma_link(vma) do {} while (0)
#define page_referenced(page,l) TestClearPageReferenced(page)
-#define try_to_unmap(page, refs) SWAP_FAIL
+#define try_to_unmap(page, refs, container) SWAP_FAIL
+#define page_in_container(page, zone, container) true
static inline int page_mkclean(struct page *page)
{
diff -puN include/linux/swap.h~memctlr-reclaim-on-limit include/linux/swap.h
--- linux-2.6.20/include/linux/swap.h~memctlr-reclaim-on-limit 2007-02-18
23:29:14.0 +0530
+++ linux-2.6.20-balbir/include/linux/swap.h2007-02-18 23:29:14.0
+0530
@@ -188,6 +188,10 @@ extern void swap_setup(void);
/* linux/mm/vmscan.c */
extern unsigned long try_to_free_pages(struct zone **, gfp_t);
extern unsigned long shrink_all_memory(unsigned long nr_pages);
+#ifdef CONFIG_CONTAINER_MEMCTLR
+extern unsigned long memctlr_shrink_mapped_memory(unsigned long nr_pages,
+ void *container);
+#endif
extern int vm_swappiness;
extern int remove_mapping(struct address_space *mapping, struct page *page);
extern long vm_total_pages;
diff -puN mm/memctlr.c~memctlr-reclaim-on-limit mm/memctlr.c
--- linux-2.6.20/mm/memctlr.c~memctlr-reclaim-on-limit 2007-02-18
23:29:14.0 +0530
+++ linux-2.6.20-balbir/mm/memctlr.c2007-02-18 23:34:51.0 +0530
@@ -17,16 +17,26 @@
#include
#include
#include
+#include
#include
-#define RES_USAGE_NO_LIMIT 0
[RFC][PATCH][2/4] Add RSS accounting and control
This patch adds the basic accounting hooks to account for pages allocated
into the RSS of a process. Accounting is maintained at two levels, in
the mm_struct of each task and in the memory controller data structure
associated with each node in the container.
When the limit specified for the container is exceeded, the task is killed.
RSS accounting is consistent with the current definition of RSS in the
kernel. Shared pages are accounted into the RSS of each process as is
done in the kernel currently. The code is flexible in that it can be easily
modified to work with any definition of RSS.
Signed-off-by: <[EMAIL PROTECTED]>
---
fs/exec.c |4 +
include/linux/memctlr.h | 38
include/linux/sched.h | 11 +++
kernel/fork.c | 10 +++
mm/memctlr.c| 148 ++--
mm/memory.c | 33 +-
mm/rmap.c |5 +
mm/swapfile.c |2
8 files changed, 232 insertions(+), 19 deletions(-)
diff -puN fs/exec.c~memctlr-acct fs/exec.c
--- linux-2.6.20/fs/exec.c~memctlr-acct 2007-02-18 22:55:50.0 +0530
+++ linux-2.6.20-balbir/fs/exec.c 2007-02-18 22:55:50.0 +0530
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
@@ -313,6 +314,9 @@ void install_arg_page(struct vm_area_str
if (unlikely(anon_vma_prepare(vma)))
goto out;
+ if (!memctlr_update_rss(mm, 1, MEMCTLR_CHECK_LIMIT))
+ goto out;
+
flush_dcache_page(page);
pte = get_locked_pte(mm, address, );
if (!pte)
diff -puN include/linux/memctlr.h~memctlr-acct include/linux/memctlr.h
--- linux-2.6.20/include/linux/memctlr.h~memctlr-acct 2007-02-18
22:55:50.0 +0530
+++ linux-2.6.20-balbir/include/linux/memctlr.h 2007-02-18 23:28:16.0
+0530
@@ -14,9 +14,47 @@
#ifndef _LINUX_MEMCTLR_H
#define _LINUX_MEMCTLR_H
+enum {
+ MEMCTLR_CHECK_LIMIT = true,
+ MEMCTLR_DONT_CHECK_LIMIT = false,
+};
+
#ifdef CONFIG_CONTAINER_MEMCTLR
+struct res_counter {
+ atomic_long_t usage;/* The current usage of the resource being */
+ /* counted */
+ atomic_long_t limit;/* The limit on the resource */
+ atomic_long_t nr_limit_exceeded;
+};
+
+extern int memctlr_mm_init(struct mm_struct *mm);
+extern void memctlr_mm_free(struct mm_struct *mm);
+extern void memctlr_mm_assign_container(struct mm_struct *mm,
+ struct task_struct *p);
+extern int memctlr_update_rss(struct mm_struct *mm, int count, bool check);
+
#else /* CONFIG_CONTAINER_MEMCTLR */
+static inline int memctlr_mm_init(struct mm_struct *mm)
+{
+ return 0;
+}
+
+static inline void memctlr_mm_free(struct mm_struct *mm)
+{
+}
+
+static inline void memctlr_mm_assign_container(struct mm_struct *mm,
+ struct task_struct *p)
+{
+}
+
+static inline int memctlr_update_rss(struct mm_struct *mm, int count,
+ bool check)
+{
+ return 0;
+}
+
#endif /* CONFIG_CONTAINER_MEMCTLR */
#endif /* _LINUX_MEMCTLR_H */
diff -puN include/linux/sched.h~memctlr-acct include/linux/sched.h
--- linux-2.6.20/include/linux/sched.h~memctlr-acct 2007-02-18
22:55:50.0 +0530
+++ linux-2.6.20-balbir/include/linux/sched.h 2007-02-18 22:57:03.0
+0530
@@ -83,6 +83,7 @@ struct sched_param {
#include
#include
#include
+#include
#include
@@ -373,6 +374,16 @@ struct mm_struct {
/* aio bits */
rwlock_tioctx_list_lock;
struct kioctx *ioctx_list;
+#ifdef CONFIG_CONTAINER_MEMCTLR
+ /*
+* Each mm_struct's container, sums up in the container's counter
+* We can extend this such that, VMA's counters sum up into this
+* counter
+*/
+ struct res_counter *counter;
+ struct container*container;
+ rwlock_tcontainer_lock;
+#endif /* CONFIG_CONTAINER_MEMCTLR */
};
struct sighand_struct {
diff -puN kernel/fork.c~memctlr-acct kernel/fork.c
--- linux-2.6.20/kernel/fork.c~memctlr-acct 2007-02-18 22:55:50.0
+0530
+++ linux-2.6.20-balbir/kernel/fork.c 2007-02-18 22:55:50.0 +0530
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
@@ -342,10 +343,15 @@ static struct mm_struct * mm_init(struct
mm->free_area_cache = TASK_UNMAPPED_BASE;
mm->cached_hole_size = ~0UL;
+ if (!memctlr_mm_init(mm))
+ goto err;
+
if (likely(!mm_alloc_pgd(mm))) {
mm->def_flags = 0;
return mm;
}
+
+err:
free_mm(mm);
return NULL;
}
@@ -361,6 +367,8 @@ struct mm_struct * mm_alloc(void)
if (mm) {
memset(mm, 0, sizeof(*mm));
[RFC][PATCH][1/4] RSS controller setup
This patch sets up the basic controller infrastructure on top of the
containers infrastructure. Two files are provided for monitoring
and control memctlr_usage and memctlr_limit.
memctlr_usage shows the current usage (in pages, of RSS) and the limit
set by the user.
memctlr_limit can be used to set a limit on the RSS usage of the resource.
A special value of 0, indicates that the usage is unlimited. The limit
is set in units of pages.
Signed-off-by: <[EMAIL PROTECTED]>
---
include/linux/memctlr.h | 22 ++
init/Kconfig|7 +
mm/Makefile |1
mm/memctlr.c| 169
4 files changed, 199 insertions(+)
diff -puN /dev/null include/linux/memctlr.h
--- /dev/null 2007-02-02 22:51:23.0 +0530
+++ linux-2.6.20-balbir/include/linux/memctlr.h 2007-02-16 00:22:11.0
+0530
@@ -0,0 +1,22 @@
+/* memctlr.h - Memory Controller for containers
+ *
+ * Copyright (C) Balbir Singh, IBM Corp. 2006-2007
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#ifndef _LINUX_MEMCTLR_H
+#define _LINUX_MEMCTLR_H
+
+#ifdef CONFIG_CONTAINER_MEMCTLR
+
+#else /* CONFIG_CONTAINER_MEMCTLR */
+
+#endif /* CONFIG_CONTAINER_MEMCTLR */
+#endif /* _LINUX_MEMCTLR_H */
diff -puN init/Kconfig~memctlr-setup init/Kconfig
--- linux-2.6.20/init/Kconfig~memctlr-setup 2007-02-15 21:58:42.0
+0530
+++ linux-2.6.20-balbir/init/Kconfig2007-02-15 21:58:42.0 +0530
@@ -306,6 +306,13 @@ config CONTAINER_NS
for instance virtual servers and checkpoint/restart
jobs.
+config CONTAINER_MEMCTLR
+ bool "A simple RSS based memory controller"
+ select CONTAINERS
+ help
+ Provides a simple Resource Controller for monitoring and
+ controlling the total Resident Set Size of the tasks in a container
+
config RELAY
bool "Kernel->user space relay support (formerly relayfs)"
help
diff -puN mm/Makefile~memctlr-setup mm/Makefile
--- linux-2.6.20/mm/Makefile~memctlr-setup 2007-02-15 21:58:42.0
+0530
+++ linux-2.6.20-balbir/mm/Makefile 2007-02-15 21:58:42.0 +0530
@@ -29,3 +29,4 @@ obj-$(CONFIG_MEMORY_HOTPLUG) += memory_h
obj-$(CONFIG_FS_XIP) += filemap_xip.o
obj-$(CONFIG_MIGRATION) += migrate.o
obj-$(CONFIG_SMP) += allocpercpu.o
+obj-$(CONFIG_CONTAINER_MEMCTLR) += memctlr.o
diff -puN /dev/null mm/memctlr.c
--- /dev/null 2007-02-02 22:51:23.0 +0530
+++ linux-2.6.20-balbir/mm/memctlr.c2007-02-16 00:22:11.0 +0530
@@ -0,0 +1,169 @@
+/*
+ * memctlr.c - Memory Controller for containers
+ *
+ * Copyright (C) Balbir Singh, IBM Corp. 2006-2007
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define RES_USAGE_NO_LIMIT 0
+static const char version[] = "0.1";
+
+struct res_counter {
+ unsigned long usage;/* The current usage of the resource being */
+ /* counted */
+ unsigned long limit;/* The limit on the resource */
+ unsigned long nr_limit_exceeded;
+};
+
+struct memctlr {
+ struct container_subsys_state css;
+ struct res_counter counter;
+ spinlock_t lock;
+};
+
+static struct container_subsys memctlr_subsys;
+
+static inline struct memctlr *memctlr_from_cont(struct container *cont)
+{
+ return container_of(container_subsys_state(cont, _subsys),
+ struct memctlr, css);
+}
+
+static inline struct memctlr *memctlr_from_task(struct task_struct *p)
+{
+ return memctlr_from_cont(task_container(p, _subsys));
+}
+
+static int memctlr_create(struct container_subsys *ss, struct container *cont)
+{
+ struct memctlr *mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+ if (!mem)
+ return -ENOMEM;
+
+ spin_lock_init(>lock);
+ cont->subsys[memctlr_subsys.subsys_id] = >css;
+ return 0;
+}
+
+static void memctlr_destroy(struct container_subsys *ss,
+ struct container *cont)
+{
+ kfree(memctlr_from_cont(cont));
+}
+
+static ssize_t memctlr_write(struct container *cont, struct
[RFC][PATCH][0/4] Memory controller (RSS Control)
This patch applies on top of Paul Menage's container patches (V7) posted at http://lkml.org/lkml/2007/2/12/88 It implements a controller within the containers framework for limiting memory usage (RSS usage). The memory controller was discussed at length in the RFC posted to lkml http://lkml.org/lkml/2006/10/30/51 Steps to use the controller -- 0. Download the patches, apply the patches 1. Turn on CONFIG_CONTAINER_MEMCTLR in kernel config, build the kernel and boot into the new kernel 2. mount -t container container -o memctlr / 3. cd / optionally do (mkdir ; cd ) under / 4. echo $$ > tasks (attaches the current shell to the container) 5. echo -n (limit value) > memctlr_limit 6. cat memctlr_usage 7. Run tasks, check the usage of the controller, reclaim behaviour 8. Report bugs, get bug fixes and iterate (goto step 0). Advantages of the patchset -- 1. Zero overhead in struct page (struct page is not expanded) 2. Minimal changes to the core-mm code 3. Shared pages are not reclaimed unless all mappings belong to overlimit containers. 4. It can be used to debug drivers/applications/kernel components in a constrained memory environment (similar to mem=XXX option), except that several containers can be created simultaneously without rebooting and the limits can be changed. NOTE: There is no support for limiting kernel memory allocations and page cache control (presently). Testing --- Ran kernbench and lmbench with containers enabled (container filesystem not mounted), they seemed to run fine Created containers, attached tasks to containers with lower limits than the memory the tasks require (memory hog tests) and ran some basic tests on them TODO's and improvement areas 1. Come up with cool page replacement algorithms for containers (if possible without any changes to struct page) 2. Add page cache control 3. Add kernel memory allocator control 4. Extract benchmark numbers and overhead data Comments & criticism are welcome. Series -- memctlr-setup.patch memctlr-acct.patch memctlr-reclaim-on-limit.patch memctlr-doc.patch -- Warm Regards, Balbir Singh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Re: 2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot
On Sun, 2007-02-18 at 10:27 +0100, Mike Galbraith wrote: > On Sun, 2007-02-18 at 09:02 +0100, Mike Galbraith wrote: > > > The reason it's hanging is that nobody releases the driver, so we wait > > forever in driver_unregister(). With the below, box boots fine... > > > > --- drivers/base/bus.c.org 2007-02-18 08:38:57.0 +0100 > > +++ drivers/base/bus.c 2007-02-18 08:39:09.0 +0100 > > @@ -593,6 +593,7 @@ void bus_remove_driver(struct device_dri > > driver_detach(drv); > > module_remove_driver(drv); > > kobject_unregister(>kobj); > > + driver_release(>kobj); > > put_bus(drv->bus); > > } > > > > > > ...but that can't be right given that the darn thing booted just fine > > prior to the naming patch with an equally unhappy init_ipmi_si(). Hmm. > > Ok. The path it's supposed to take to driver_release() goes like so > > [ 17.495312] bus platform: add driver ipmi > [ 17.506560] ipmi message handler version 39.1 > [ 17.518099] ipmi device interface > [ 17.528491] device class 'ipmi': registering > [ 17.539854] bus platform: add driver ipmi_si > [ 17.551210] IPMI System Interface driver. > [ 17.562242] bus pci: add driver ipmi_si > [ 17.583686] bus pci: remove driver ipmi_si > [ 17.594721] BUG: at drivers/base/bus.c:65 driver_release() > [ 17.607224] [] show_trace_log_lvl+0x1a/0x30 > [ 17.619434] [] show_trace+0x12/0x14 > [ 17.630822] [] dump_stack+0x16/0x18 > [ 17.642098] [] driver_release+0x37/0x39 > [ 17.653703] [] kobject_cleanup+0x43/0x64 > [ 17.665359] [] kobject_release+0xb/0xd > [ 17.676748] [] kref_put+0x28/0x8c > [ 17.687626] [] kobject_put+0x14/0x16 > [ 17.698712] [] kobject_unregister+0x22/0x25 > [ 17.710359] [] bus_remove_driver+0x95/0xa5 > [ 17.721911] [] driver_unregister+0xe/0x47 > [ 17.733317] [] pci_unregister_driver+0x13/0x73 > [ 17.745149] [] init_ipmi_si+0x798/0x7ba > [ 17.756339] [] init+0x114/0x23c > [ 17.766748] [] kernel_thread_helper+0x7/0x1c > > ...so I guess it's a ref counting problem somewhere. The below fixes a reference counting bug exposed by commit 725522b5453dd680412f2b6463a988e4fd148757. If driver.mod_name exists, we take a reference in module_add_driver(), and never release it. Undo that reference in module_remove_driver(). My box now boots fine, and modprobe/rmmod didn't explode, so I'll add a blame line. Signed-off-by: Mike Galbraith <[EMAIL PROTECTED]> --- a/kernel/module.c.org 2007-02-19 06:41:02.0 +0100 +++ b/kernel/module.c 2007-02-19 06:49:08.0 +0100 @@ -2417,6 +2417,12 @@ void module_remove_driver(struct device_ kfree(driver_name); } } + /* +* Undo the additional reference we added in module_add_driver() +* via kset_find_obj() +*/ + if (drv->mod_name) + kobject_put(>kobj); } EXPORT_SYMBOL(module_remove_driver); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about setting affinity in 2.4
On Sun, Feb 18, 2007 at 09:14:21PM -0800, Phy Prabab wrote: > Willy, > > Thanks for the heads up and patch location. It looks like the guys at > RH seemed to have applied a patch to allow one to set affinity, > however, it might be that it is broken. Guess I will have to contact > the RH people to get an update as to what they did/did not do. You should ensure that the syscall has really been added to the syscall table. Their kernel also has a fully working epoll() implementation, but the syscall is missing from the table. It's a shame because you have to add a 10-lines patch to enable it again ! It may be the same problem in your case. > Thanks! > Phy Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Qeustion][Maybe BUG?] simaltaneous wait and SIGCHLD handling
Hi,
>From SUSv3, I expected SIGCHLD from dead processes (already reaped by wait(2))
should be cleared. But it seems that such situation is not handled in Linux.
Here is a test program. set sigchld handler and call waitpid() in main().
==
#include
#include
#include
#include
int sigchld_handler(int sig,siginfo_t *info, void *uc)
{
fprintf(stderr,"Letter from the hell...(%d)\n",info->si_pid);
}
int main(int argc, char *argv)
{
struct sigaction act;
sigset_t block;
int status;
pid_t pid;
sigemptyset();
sigaddset(, SIGCHLD);
act.sa_sigaction = sigchld_handler;
act.sa_mask = block;
act.sa_flags = SA_SIGINFO|SA_RESTART;
sigaction(SIGCHLD,,NULL);
pid = fork();
if (!pid) {
sleep(3);
exit(0);
}
sigprocmask(SIG_BLOCK, , NULL);
pid = waitpid(pid, , 0);
fprintf(stderr,"wait end -> %d\n",pid);
sigprocmask(SIG_UNBLOCK, , NULL);
exit(0);
}
==
Result is here
==
[EMAIL PROTECTED] ~]$ ./waittest
wait end -> 5841
Letter from the hell...(5841)
==
Is this an expected result ? I think SIGCHLD shouldn't be delivered.
-Kame
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] platform: reorder platform_device_del
Hi Jean, On Sunday 18 February 2007 15:30, Jean Delvare wrote: > In platform_device_del(), we currently delete the device resources > first, then we delete the device itself. This causes a (minor) bug to > occur when one unregisters a platform device before unregistering its > platform driver, and the driver is requesting (in .probe()) and > releasing (in .remove()) a resource of the device. The device > resources are already gone by the time the driver gets the chance to > release the resources it had been requesting, causing an error like: > Trying to free nonexistent resource <0295-0296> > > If the platform driver is unregistered first, the problem doesn't > occur, as the driver will have the opportunity to release the > resources it had requested before the device resources themselves are > released. It's a bit odd that unregistering the driver first or the > device first doesn't lead to the same result. I am not sure that this is correct argument. Why does a driver request and release device's resources? "Higher power" has already requested these resources for the device and this is not drivers task to free them. However you are right that we should not free resources until device is marked for deletion and driver's ->remove() method completes but I would not rely on surrounding code for keeping an extra reference and would just take one explicitely in platform_device_del(). -- 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: [patch/rfc 2.6.20-git] parport reports physical devices
On Sunday 18 February 2007 9:28 pm, Randy Dunlap wrote: > On Sun, 18 Feb 2007 21:08:07 -0800 David Brownell wrote: > > > Currently a parport_driver can't get a handle on the device node for the > > underlying parport (PNPACPI, PCI, etc). That prevents correct placement > > of sysfs child nodes, which can affect things like power management. > > > > This patch resolves that issue for non-legacy configurations: > > ... > > Does this patch address http://bugzilla.kernel.org/show_bug.cgi?id=5496 ? I don't think it would affect that behavior, but surprises can happen; like the root cause of 5496 being the lack of hookup to the real device. > What are you wondering about parport DMA? First, whether it ever worked on ports enumerated through PNP. After all, I saw it oops there, ergo the surprisingly-far-afield parts of this patch to update PNP so it now sets up DMA masks. (Which, I was thinking, probably matters mostly for parport; but I'm just assuming 24-bit masks are correct there.) > Please see http://bugzilla.kernel.org/show_bug.cgi?id=7491 > and http://bugzilla.kernel.org/show_bug.cgi?id=7492 Suggesting that no, it's never worked on ports enumerated through PNP. There's a possibility that if it previously worked through PCI, it now works ... someone with a parport printer could check it out. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 2.6.20-git] parport reports physical devices
On Sun, 18 Feb 2007 21:08:07 -0800 David Brownell wrote: > Currently a parport_driver can't get a handle on the device node for the > underlying parport (PNPACPI, PCI, etc). That prevents correct placement > of sysfs child nodes, which can affect things like power management. > > This patch resolves that issue for non-legacy configurations: > > * "struct parport" now has a field pointing to that device node, > and non-legacy port drivers now initialize that device pointer: > - parport_mfc3 (can't test or build; no Amiga + Zorro here) > - parport_pc (and stop using only pci_device internally) > - parport_serial > - parport_sunbpp (can't test or build, no SPARC + SBUS here) > > * pnp now initializes device dma masks (24bits), preventing oopses > when generic dma calls are made using pnp device nodes > > * some of the layered parport_driver code now uses that pointer: > - i2c-parport (parent of i2c_adapter) > - spi_butterfly (parent of spi_master, allowing cruft removal) > - lp (creating class_device) > - ppdev (parent of parportN device) > - tipar (creating class_device) > > Sanity tested on a PC, where PNPACPI provides the device to parport_pc, > using spi_butterfly. But I've got to wonder about parport DMA... Does this patch address http://bugzilla.kernel.org/show_bug.cgi?id=5496 ? What are you wondering about parport DMA? Please see http://bugzilla.kernel.org/show_bug.cgi?id=7491 and http://bugzilla.kernel.org/show_bug.cgi?id=7492 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm2
On Sunday 18 February 2007 4:28 pm, Andrew Morton wrote: > On Mon, 19 Feb 2007 00:32:08 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > One more thing: > > > > rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > > Unable to handle kernel NULL pointer dereference at 0030 RIP: > > [] rtc_sysfs_remove_device+0x23/0x50 > > ... > > Call Trace: > > [] class_device_del+0x86/0x180 > > [] class_device_unregister+0x11/0x20 > > [] rtc_device_unregister+0x3e/0x50 > > [] :rtc_cmos:cmos_pnp_probe+0x219/0x240 > > [] pnp_device_probe+0xa1/0xe0 > > ... > > How did you provoke that? modprobe rtc-cmos? Plus, I'd guess, the old rtc driver statically linked. What I see is a should-not-happen fault of some kind in a cleanup path that's been tested with non-PNP rtc drivers. A quick glance at the code left me puzzled. Would sleeping a second or two before calling rtc_device_unregister() change that behavior? - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch/rfc 2.6.20-git] parport reports physical devices
Currently a parport_driver can't get a handle on the device node for the
underlying parport (PNPACPI, PCI, etc). That prevents correct placement
of sysfs child nodes, which can affect things like power management.
This patch resolves that issue for non-legacy configurations:
* "struct parport" now has a field pointing to that device node,
and non-legacy port drivers now initialize that device pointer:
- parport_mfc3 (can't test or build; no Amiga + Zorro here)
- parport_pc (and stop using only pci_device internally)
- parport_serial
- parport_sunbpp (can't test or build, no SPARC + SBUS here)
* pnp now initializes device dma masks (24bits), preventing oopses
when generic dma calls are made using pnp device nodes
* some of the layered parport_driver code now uses that pointer:
- i2c-parport (parent of i2c_adapter)
- spi_butterfly (parent of spi_master, allowing cruft removal)
- lp (creating class_device)
- ppdev (parent of parportN device)
- tipar (creating class_device)
Sanity tested on a PC, where PNPACPI provides the device to parport_pc,
using spi_butterfly. But I've got to wonder about parport DMA...
There are still drivers that should be updated, like some of the input
drivers; but they won't be any worse off than they are today. And the
legacy port drivers should, like all legacy drivers, be morphed into
proper driver model code ... but until that happens, drivers need to
be prepared for the device node to be null.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/char/lp.c|2 +-
drivers/char/ppdev.c |2 +-
drivers/char/tipar.c |2 +-
drivers/i2c/busses/i2c-parport.c |3 ++-
drivers/parport/parport_mfc3.c |1 +
drivers/parport/parport_pc.c | 31 +--
drivers/parport/parport_serial.c |2 +-
drivers/parport/parport_sunbpp.c |1 +
drivers/pnp/core.c |3 +++
drivers/spi/spi_butterfly.c | 25 -
include/linux/parport.h |8 ++--
include/linux/parport_pc.h |3 +--
include/linux/pnp.h |1 +
13 files changed, 44 insertions(+), 40 deletions(-)
Index: g26/include/linux/parport.h
===
--- g26.orig/include/linux/parport.h2006-10-13 15:41:24.0 -0700
+++ g26/include/linux/parport.h 2007-02-18 14:11:01.0 -0800
@@ -279,6 +279,10 @@ struct parport {
int dma;
int muxport;/* which muxport (if any) this is */
int portnum;/* which physical parallel port (not mux) */
+ struct device *dev; /* Physical device associated with IO/DMA.
+* This may unfortulately be null if the
+* port has a legacy driver.
+*/
struct parport *physport;
/* If this is a non-default mux
@@ -289,7 +293,7 @@ struct parport {
following structure members are
meaningless: devices, cad, muxsel,
waithead, waittail, flags, pdir,
- ieee1284, *_lock.
+ dev, ieee1284, *_lock.
It this is a default mux parport, or
there is no mux involved, this points to
@@ -302,7 +306,7 @@ struct parport {
struct pardevice *waithead;
struct pardevice *waittail;
-
+
struct list_head list;
unsigned int flags;
Index: g26/include/linux/parport_pc.h
===
--- g26.orig/include/linux/parport_pc.h 2006-01-14 18:12:27.0 -0800
+++ g26/include/linux/parport_pc.h 2007-02-18 13:12:21.0 -0800
@@ -38,7 +38,6 @@ struct parport_pc_private {
/* buffer suitable for DMA, if DMA enabled */
char *dma_buf;
dma_addr_t dma_handle;
- struct pci_dev *dev;
struct list_head list;
struct parport *port;
};
@@ -232,7 +231,7 @@ extern int parport_pc_claim_resources(st
extern struct parport *parport_pc_probe_port (unsigned long base,
unsigned long base_hi,
int irq, int dma,
- struct pci_dev *dev);
+ struct device *dev);
extern void parport_pc_unregister_port (struct parport *p);
#endif
Index: g26/drivers/parport/parport_pc.c
===
--- g26.orig/drivers/parport/parport_pc.c 2006-12-07 23:00:32.0
-0800
+++ g26/drivers/parport/parport_pc.c2007-02-18
no backlight on radeon after recent kernel "upgrade"s
Dear Kernel Developers, Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've tried few times to build more recent snapshots and now finally 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but at some point during boot (few moments after Penguin icon in the top left corner appears), light turns off... I still can see something, especially if I light a strong flashlight at a sharp angle. I've enabled back-light support and lcd support for those unsuccessful kernels (with all backlight support features disabled kernel boots ok and backlight shines as bright as always) All my changes of values for files under /sys/class/backlight/radeonbl0 had no impact on the screen. Also I had no files under /sys/class/lcd. Running radeontool light off caused complete turning off of LCD - I could not see anything anymore. sony's spictl -b had no effect as well. Config can be found at http://www.onerussian.com/Linux/bugs/nobacklight.1/config-2.6.20-mm2 lshw http://www.onerussian.com/Linux/bugs/nobacklight.1/lshw other details are available from http://www.onerussian.com/Linux/bugs/nobacklight.1/ Could you please advise? -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about setting affinity in 2.4
Willy,
Thanks for the heads up and patch location. It looks like the guys at
RH seemed to have applied a patch to allow one to set affinity,
however, it might be that it is broken. Guess I will have to contact
the RH people to get an update as to what they did/did not do.
Thanks!
Phy
On 2/18/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
Hi Phy !
On Sun, Feb 18, 2007 at 06:02:17PM -0800, Phy Prabab wrote:
> Hello everyone,
>
> I am trying to set affinity on a program to make sure I can get the
> best use of the cache as possible and to eliminate as much noise as
> possible with running my program. I have tried unsuccessfully to set
> affinity using sched_set/getaffinity and the CPU_SET macros. In
> particular, I can not seem to get the process to use affinity I
> specify as in:
>
> int main () {
> cpu_set_t mask;
> cpu_set_t setmask;
> long long x;
> double foo;
> printf("Mask set to %08lx\n", sched_getaffinity(0, ));
> CPU_SET(1, );
> if (sched_setaffinity(0, ) == -1) {
> printf("error setting affinity.");
> }
>
> printf("Mask is reset to %08lx\n", sched_getaffinity(0, ));
> // do some long lasting calculations
>
> return;
> }
>
> No mater what I do, the process is never bond to the processor in
> question as exposed by this little appy and by cat /proc//cpu.
> Is this just impossible to do?
>
> Ah, the kernel I am using is RH 2.4.21-37.ELsmp.
I don't know for RH kernel, but the affinity syscalls are not in 2.4
mainline. You can apply the patch without much hassle if you want. It's
in Robert Love's directory :
http://www.kernel.org/pub/linux/kernel/people/rml/cpu-affinity/v2.4/
I believe you'll have to use an -ac patch for RHEL.
> TIA!
> Phy
regards,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: console scroll lock causes DOS
On Wed, 7 Feb 2007, Andy wrote: > If the scroll lock is on and there is a bunch of console output, the machine > will eventually stop responding to the network, until scroll lock is turned > off (at sometimes that doesn't even help). > > Easy test: > > hit scroll lock > do a few echo t > /proc/sysrq-trigger on that machine from a ssh/telnet > session > and it should stop responding after two or three of them. > > This is bad (for me) because we have a stupid switch box that uses scroll > lock to bring up the system selection menu, so sometimes scroll lock gets > left on by accident, and the machine eventually locks up. something similar happens on serial console with hardware flow control if the other side goes away. on some boxes i've wired special connectors with CTS=RTS to avoid this... mind you i haven't tested this problem in years. -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/1] fs/stack.c: Copy i_nlink after all other attributes are copied
From: Erez Zadok <[EMAIL PROTECTED]>
A user-specified get_nlinks may depend on other inode attributes.
Cc: Michael Halcrow <[EMAIL PROTECTED]>
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/stack.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/stack.c b/fs/stack.c
index 8ffb880..67716f6 100644
--- a/fs/stack.c
+++ b/fs/stack.c
@@ -20,11 +20,6 @@ EXPORT_SYMBOL_GPL(fsstack_copy_inode_size);
void fsstack_copy_attr_all(struct inode *dest, const struct inode *src,
int (*get_nlinks)(struct inode *))
{
- if (!get_nlinks)
- dest->i_nlink = src->i_nlink;
- else
- dest->i_nlink = (*get_nlinks)(dest);
-
dest->i_mode = src->i_mode;
dest->i_uid = src->i_uid;
dest->i_gid = src->i_gid;
@@ -34,5 +29,14 @@ void fsstack_copy_attr_all(struct inode *dest, const struct
inode *src,
dest->i_ctime = src->i_ctime;
dest->i_blkbits = src->i_blkbits;
dest->i_flags = src->i_flags;
+
+ /*
+* Update the nlinks AFTER updating the above fields, because the
+* get_links callback may depend on them.
+*/
+ if (!get_nlinks)
+ dest->i_nlink = src->i_nlink;
+ else
+ dest->i_nlink = (*get_nlinks)(dest);
}
EXPORT_SYMBOL_GPL(fsstack_copy_attr_all);
--
1.5.0.19.gddff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Question about setting affinity in 2.4
Hi Phy !
On Sun, Feb 18, 2007 at 06:02:17PM -0800, Phy Prabab wrote:
> Hello everyone,
>
> I am trying to set affinity on a program to make sure I can get the
> best use of the cache as possible and to eliminate as much noise as
> possible with running my program. I have tried unsuccessfully to set
> affinity using sched_set/getaffinity and the CPU_SET macros. In
> particular, I can not seem to get the process to use affinity I
> specify as in:
>
> int main () {
> cpu_set_t mask;
> cpu_set_t setmask;
> long long x;
> double foo;
> printf("Mask set to %08lx\n", sched_getaffinity(0, ));
> CPU_SET(1, );
> if (sched_setaffinity(0, ) == -1) {
> printf("error setting affinity.");
> }
>
> printf("Mask is reset to %08lx\n", sched_getaffinity(0, ));
> // do some long lasting calculations
>
> return;
> }
>
> No mater what I do, the process is never bond to the processor in
> question as exposed by this little appy and by cat /proc//cpu.
> Is this just impossible to do?
>
> Ah, the kernel I am using is RH 2.4.21-37.ELsmp.
I don't know for RH kernel, but the affinity syscalls are not in 2.4
mainline. You can apply the patch without much hassle if you want. It's
in Robert Love's directory :
http://www.kernel.org/pub/linux/kernel/people/rml/cpu-affinity/v2.4/
I believe you'll have to use an -ac patch for RHEL.
> TIA!
> Phy
regards,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: > On Sun, Feb 18, 2007 at 05:15:30PM +0100, Udo van den Heuvel wrote: >> FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser >> where only the Device Number can be changed. >> The kernel sees the two DVB cards in there as: >> >> saa7146: register extension 'budget_av'. >> ACPI: PCI Interrupt :00:13.0[A] -> GSI 16 (level, low) -> IRQ 16 >> saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). >> saa7146 (0): dma buffer size 192512 >> DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). >> adapter failed MAC signature check >> encoded MAC from EEPROM was >> ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff >> KNC1-0: MAC addr = 00:0a:ac:01:d6:87 >> DVB: registering frontend 0 (Philips TDA10046H DVB-T)... >> budget-av: ci interface initialised. >> ACPI: PCI Interrupt :00:14.0[A] -> GSI 17 (level, low) -> IRQ 20 >> saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). >> saa7146 (1): dma buffer size 192512 >> DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). >> adapter failed MAC signature check >> encoded MAC from EEPROM was >> ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff >> sd 0:0:0:0: Attached scsi generic sg0 type 0 >> KNC1-1: MAC addr = 00:0a:ac:12:93:8d >> DVB: registering frontend 1 (ST STV0299 DVB-S)... >> budget-av: ci interface initialised. > > Well it says they are slot 13 and 14. What other pci devices are > present in the system and what irq's are they using? lspci and interrupts at the bottom. yes, we have apic. >> So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no >> communication with the DVB-T card (the frontend), so there is no >> /dev/dvb/* entry. This points to an IRQ problem. > > Any documentation on that riser card? The EN12000 is equipped with a PCI riser like the one here: http://www.tranquilpc-shop.co.uk/acatalog/info%5f2%2ehtml Please also see http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html and http://www.tranquilpc.co.uk/support/Files/TPC014/Tranquil%20Riser.pdf for info about how the riser works. > I guess it is possible the card does something weird and the IRQs for > both cards have to actually be the same. If that is the case you could > make the kernel change the IRQ assigned to the second card before > loading the driver. Or you could do it from the boot loader or > something (The system I work with has a stupid bios that doesn't have a > clue about bridges, so we added IRQ fixup code to grub to deal with all > PCI bridges before booting the system). Ah, this sounds interesting. Any pointers about hwo to do this? >> I set the BIOS for 'PnP OS installed'. Should I change that? () > It might actually work better if you change that, although it may also > just make no difference. I will give the change a try. The info: 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) CPU0 0: 15939569 IO-APIC-edge timer 1: 36 IO-APIC-edge i8042 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12:222 IO-APIC-edge i8042 14: 570999 IO-APIC-edge ide0 16:3166202 IO-APIC-fasteoi saa7146 (0), [EMAIL PROTECTED]::01:00.0 17:2619374 IO-APIC-fasteoi eth0 18: 402194 IO-APIC-fasteoi libata 19:
Re: [BUG/WARN] Error initialising drivers in PCI
On 2/19/07, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: Ian, you have an PATA controller so there is no need to use ata_piix. Just disabling ata_piix should workaround the issue. OK. I have done this and the message goes away in boot logs. As you say I don't need the old drivers anymore. If you want me to test any fixes so both can coexist without throwing a warning then just drop me a line. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] GIT 1.5.0.1
The latest maintenance release GIT 1.5.0.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.1.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.0.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.1.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.0.1-1.$arch.rpm (RPM)
GIT v1.5.0.1 Release Notes
==
Fixes since v1.5.0
--
* Documentation updates
- Clarifications and corrections to 1.5.0 release notes.
- The main documentation did not link to git-remote documentation.
- Clarified introductory text of git-rebase documentation.
- Converted remaining mentions of update-index on Porcelain
documents to git-add/git-rm.
- Some i18n.* configuration variables were incorrectly
described as core.*; fixed.
* Bugfixes
- git-add and git-update-index on a filesystem on which
executable bits are unreliable incorrectly reused st_mode
bits even when the path changed between symlink and regular
file.
- git-daemon marks the listening sockets with FD_CLOEXEC so
that it won't be leaked into the children.
- segfault from git-blame when the mandatory pathname
parameter was missing was fixed; usage() message is given
instead.
- git-rev-list did not read $GIT_DIR/config file, which means
that did not honor i18n.logoutputencoding correctly.
* Tweaks
- sliding mmap() inefficiently mmaped the same region of a
packfile with an access pattern that used objects in the
reverse order. This has been made more efficient.
Changes since v1.5.0 are as follows (gitk changes were already
in v1.5.0 -- listed below are the commits that came through
Paul's official gitk repository):
Alexandre Julliard (2):
git-daemon: Avoid leaking the listening sockets into child processes.
sha1_file.c: Round the mmap offset to half the window size.
Fredrik Kuivinen (2):
Read the config in rev-list
Documentation/i18n.txt: it is i18n.commitencoding not core.commitencoding
Junio C Hamano (15):
Documentation: Drop full-stop from git-fast-import title.
cmd-list: add git-remote
Makefile: update check-docs target
Clarify two backward incompatible repository options.
Still updating 1.5.0 release notes.
Add RelNotes 1.5.0.1
Make sure packedgitwindowsize is multiple of (pagesize * 2)
Make gitk work reasonably well on Cygwin.
gitk: Use show-ref instead of ls-remote
GIT-VERSION-FILE: check ./version first.
pretend-sha1: grave bugfix.
git-merge: minor fix for no_trivial_merge_strategies.
Do not take mode bits from index after type change.
Update draft release notes for 1.5.0.1
GIT 1.5.0.1
Mark Levedahl (3):
gitk - remove trailing whitespace from a few lines.
Make gitk save and restore the user set window position.
Make gitk save and restore window pane position on Linux and Cygwin.
Nicolas Pitre (1):
Minor corrections to release notes
Paul Mackerras (1):
Change git repo-config to git config
Shawn O. Pearce (2):
Attempt to improve git-rebase lead-in description.
Convert update-index references in docs to add.
Tommi Kyntola (1):
git-blame: prevent argument parsing segfault
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Question about setting affinity in 2.4
Hello everyone,
I am trying to set affinity on a program to make sure I can get the
best use of the cache as possible and to eliminate as much noise as
possible with running my program. I have tried unsuccessfully to set
affinity using sched_set/getaffinity and the CPU_SET macros. In
particular, I can not seem to get the process to use affinity I
specify as in:
int main () {
cpu_set_t mask;
cpu_set_t setmask;
long long x;
double foo;
printf("Mask set to %08lx\n", sched_getaffinity(0, ));
CPU_SET(1, );
if (sched_setaffinity(0, ) == -1) {
printf("error setting affinity.");
}
printf("Mask is reset to %08lx\n", sched_getaffinity(0, ));
// do some long lasting calculations
return;
}
No mater what I do, the process is never bond to the processor in
question as exposed by this little appy and by cat /proc//cpu.
Is this just impossible to do?
Ah, the kernel I am using is RH 2.4.21-37.ELsmp.
TIA!
Phy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: loopback mount EXT3 oops
On Sun, 2007-02-18 at 19:40 -0600, Eric Sandeen wrote: > Andrew Morton wrote: > > I thought Eric fixed that. Maybe he broke it instead ;) > > Eeek... I'll reserve judgment on who broke what until I see that > corrupted image... ;) is it available? How huge? 2G, but bzip'ed e2image -r is 54M: http://ozlabs.org/~rusty/ubuntu-oopses-e2image-r.bz2 Cheers! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
On Sunday 18 February 2007 19:39, Lennart Sorensen wrote: [snip] > > > On a PC, the BIOS is supposed to assign interrupts to devices based on > > > those rules, since that is how the hardware must be done according to > > > the PCI specifications. > > > > I set the BIOS for 'PnP OS installed'. Should I change that? > > I would NEVER do that. That actually disables the BIOS from doing > configuration of most hardware since it really means "Microsoft wants to > do configuration themselves and asked us to put in a setting to make the > bios only configure drive controllers and sound cards". I know some > people have worked towards making linux a "PnP OS" by microsoft > standards, but whether it is entirely there or not by now I am not sure. > Fortunately most motherboards I have ever bought come preset at 'pnp os > installed' off, which is how I like it. I have had a number of > problems on systems with that setting on, which went away when the > setting was set back to off. I think this option actually _used_ to mean whether the BIOS would _provide_ PNP services to the host OS, allowing it to detect peripherals like parallel ports, etc. In reality, very few devices on modern PCs use or require BIOS PNP support, and in some situations it's just annoying (for example, disabling the parallel port on my Thinkpad has no effect because Linux just uses PNP to redetect it). > It might actually work better if you change that, although it may also > just make no difference. In my experience it just makes no difference. I strongly doubt the option has _anything_ to do with this problem. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loopback mount EXT3 oops
Andrew Morton wrote: On Mon, 19 Feb 2007 10:52:42 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote: Hi all, This happened on 2.6.20-rc6-mm3, so I upgraded to 2.6.20-git14, and same thing happened. Doing a forced fsck on the (corrupted by double-mounting I think) filesystem fixed it, but I took a copy before doing that. Do we care about ext3 barfing on corrupted filesystems? ... I thought Eric fixed that. Maybe he broke it instead ;) Eeek... I'll reserve judgment on who broke what until I see that corrupted image... ;) is it available? How huge? -Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> > > In general, writepage is supposed to do work without blocking on > > > expensive locks that will get pdflush and dirty reclaim stuck in this > > > fashion. You'll probably have to take the same approach reiserfs does > > > in data=journal mode, which is leaving the page dirty if fuse_get_req_wp > > > is going to block without making progress. > > > > Pdflush, and dirty reclaim set wbc->nonblocking to true. > > balance_dirty_pages and fsync don't. The problem here is that > > Andrew's patch is wrong to let balance_dirty_pages() try to write back > > pages from a different queue. > > async or sync, writepage is supposed to either make progress or bail. > loopback aside, if the fuse call is blocking long term, you're going to > run into problems. Hmm, like what? Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
On Mon, Feb 19, 2007 at 01:54:31AM +0100, Miklos Szeredi wrote: > > > > > > If so, writes to B will decrease the dirty memory threshold. > > > > > > > > > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000. > > > > > Some pages queued for writeback (doesn't matter how much). B writes > > > > > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for > > > > > B doesn't know that there's nothing more to write back for B, it's > > > > > just waiting there for those 1099, which'll never get written. > > > > > > > > hm, OK, arguable. I guess something like this.. > > > > > > Doesn't help the fuse case, but does seem to help the loopback mount > > > one. > > > > > > For fuse it's worse with the patch: now the write triggered by the > > > balance recurses into fuse, with disastrous results, since the fuse > > > writeback is now blocked on the userspace queue. > > > > > > fusexmp_fh_no D 40136678 0 505494 506 504 (NOTLB) > > > 08982b78 0001 08f9f9b4 0805d8cb 089a75f8 08982b78 08f98000 > > >08f98000 08f9f9dc 0805a38a 089a7100 08982680 08f9f9cc 08f98000 > > > 08f98000 > > >085d8300 08982680 089a7100 08f9fa34 08183006 089a7100 08982680 > > > 089a7100 Call Trace: > > > 08f9f9a0: [<0805d8cb>] switch_to_skas+0x3b/0x83 > > > 08f9f9b8: [<0805a38a>] _switch_to+0x49/0x99 > > > 08f9f9e0: [<08183006>] schedule+0x246/0x547 > > > 08f9fa38: [<08103c7e>] fuse_get_req_wp+0xe9/0x14a > > > 08f9fa70: [<08103d2e>] fuse_writepage+0x4f/0x12c > > > > In general, writepage is supposed to do work without blocking on > > expensive locks that will get pdflush and dirty reclaim stuck in this > > fashion. You'll probably have to take the same approach reiserfs does > > in data=journal mode, which is leaving the page dirty if fuse_get_req_wp > > is going to block without making progress. > > Pdflush, and dirty reclaim set wbc->nonblocking to true. > balance_dirty_pages and fsync don't. The problem here is that > Andrew's patch is wrong to let balance_dirty_pages() try to write back > pages from a different queue. async or sync, writepage is supposed to either make progress or bail. loopback aside, if the fuse call is blocking long term, you're going to run into problems. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-git13 kernel BUG at /mnt/md0/devel/linux-git/kernel/time/tick-sched.c:168
On 18/02/07, Alex Riesen <[EMAIL PROTECTED]> wrote: Thomas Gleixner, Sun, Feb 18, 2007 13:36:56 +0100: > On Sun, 2007-02-18 at 10:50 +0100, Alex Riesen wrote: > > > The arch/i386/kernel/process.c part of the patch should apply to 2.6.20 > > > as well. Can you check if the problem is there too ? > > > > It does not apply and does not look trivially hackable. > > The code for cpu_idle was introduced in 2ff2d3d7 "i386: add idle notifier". > > Here you go. > Ok, I confirm the message in vanilla v2.6.20 dmesg | grep Idle Idle: local softirq pending: 0020 uname -a Linux bitis-gabonica.linuxtestersgroup.org 2.6.20 #1 SMP PREEMPT Sun Feb 18 15:20:27 CET 2007 i686 i686 i386 GNU/Linux Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> > > > > If so, writes to B will decrease the dirty memory threshold. > > > > > > > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000. > > > > Some pages queued for writeback (doesn't matter how much). B writes > > > > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for > > > > B doesn't know that there's nothing more to write back for B, it's > > > > just waiting there for those 1099, which'll never get written. > > > > > > hm, OK, arguable. I guess something like this.. > > > > Doesn't help the fuse case, but does seem to help the loopback mount > > one. > > > > For fuse it's worse with the patch: now the write triggered by the > > balance recurses into fuse, with disastrous results, since the fuse > > writeback is now blocked on the userspace queue. > > > > fusexmp_fh_no D 40136678 0 505494 506 504 (NOTLB) > > 08982b78 0001 08f9f9b4 0805d8cb 089a75f8 08982b78 08f98000 > >08f98000 08f9f9dc 0805a38a 089a7100 08982680 08f9f9cc 08f98000 > > 08f98000 > >085d8300 08982680 089a7100 08f9fa34 08183006 089a7100 08982680 > > 089a7100 Call Trace: > > 08f9f9a0: [<0805d8cb>] switch_to_skas+0x3b/0x83 > > 08f9f9b8: [<0805a38a>] _switch_to+0x49/0x99 > > 08f9f9e0: [<08183006>] schedule+0x246/0x547 > > 08f9fa38: [<08103c7e>] fuse_get_req_wp+0xe9/0x14a > > 08f9fa70: [<08103d2e>] fuse_writepage+0x4f/0x12c > > In general, writepage is supposed to do work without blocking on > expensive locks that will get pdflush and dirty reclaim stuck in this > fashion. You'll probably have to take the same approach reiserfs does > in data=journal mode, which is leaving the page dirty if fuse_get_req_wp > is going to block without making progress. Pdflush, and dirty reclaim set wbc->nonblocking to true. balance_dirty_pages and fsync don't. The problem here is that Andrew's patch is wrong to let balance_dirty_pages() try to write back pages from a different queue. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
On Mon, Feb 19, 2007 at 01:25:21AM +0100, Miklos Szeredi wrote: > > > > If so, writes to B will decrease the dirty memory threshold. > > > > > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000. > > > Some pages queued for writeback (doesn't matter how much). B writes > > > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for > > > B doesn't know that there's nothing more to write back for B, it's > > > just waiting there for those 1099, which'll never get written. > > > > hm, OK, arguable. I guess something like this.. > > Doesn't help the fuse case, but does seem to help the loopback mount > one. > > For fuse it's worse with the patch: now the write triggered by the > balance recurses into fuse, with disastrous results, since the fuse > writeback is now blocked on the userspace queue. > > fusexmp_fh_no D 40136678 0 505494 506 504 (NOTLB) > 08982b78 0001 08f9f9b4 0805d8cb 089a75f8 08982b78 08f98000 >08f98000 08f9f9dc 0805a38a 089a7100 08982680 08f9f9cc 08f98000 08f98000 >085d8300 08982680 089a7100 08f9fa34 08183006 089a7100 08982680 > 089a7100 Call Trace: > 08f9f9a0: [<0805d8cb>] switch_to_skas+0x3b/0x83 > 08f9f9b8: [<0805a38a>] _switch_to+0x49/0x99 > 08f9f9e0: [<08183006>] schedule+0x246/0x547 > 08f9fa38: [<08103c7e>] fuse_get_req_wp+0xe9/0x14a > 08f9fa70: [<08103d2e>] fuse_writepage+0x4f/0x12c In general, writepage is supposed to do work without blocking on expensive locks that will get pdflush and dirty reclaim stuck in this fashion. You'll probably have to take the same approach reiserfs does in data=journal mode, which is leaving the page dirty if fuse_get_req_wp is going to block without making progress. Queue it somewhere else (ie an internal Fs cleaning thread) and leave the page dirty so that we can move on to other pages that have a chance of being cleaned. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> > > > If so, writes to B will decrease the dirty memory threshold. > > > > > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000. > > > Some pages queued for writeback (doesn't matter how much). B writes > > > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for > > > B doesn't know that there's nothing more to write back for B, it's > > > just waiting there for those 1099, which'll never get written. > > > > hm, OK, arguable. I guess something like this.. > > Doesn't help the fuse case, but does seem to help the loopback mount > one. No sorry, it doesn't even help the loopback deadlock. It sometimes takes quite a while to trigger... Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Don't probe for DDC on VBE1.2
On Sun, 18 Feb 2007, Andi Kleen wrote: > On Saturday 17 February 2007 09:35, Zwane Mwaikambo wrote: > > On Fri, 16 Feb 2007, Andrew Morton wrote: > > > > > On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo <[EMAIL > > > PROTECTED]> wrote: > > > > > > > On Thu, 15 Feb 2007, Andrew Morton wrote: > > > > > > > > > It's not an X problem - the screen is black immediately upon loading > > > > > the > > > > > kernel. > > > > > > > > > > But I guess you knew that and you're just after display info: > > > > > http://userweb.kernel.org/~akpm/Xorg.0.log.txt > > > > > > > > Thanks, the X log told me your VBE version. I tried to reproduce it on > > > > my > > > > thinkpad which seems to have a very similar video setup to no avail, > > > > Could > > > > you test the following on the VAIO? If this isn't the case, i suspect > > > > i'm > > > > corrupting your modelist. > > > > > > It's still all black. > > > > Ok it looks like i was corrupting the modelist. The following should take > > care of your VAIO, but i haven't tested the failure case as Tobias is away > > this weekend. > > I merged this version of the patch now. Still needs some x86-64 testing > I guess (any volunteers?), although I don't expect much trouble > because the early boot code is very similar. I tested the x86_64 VBE3 case (similar to Andrew's VAIO), so we just need a VBE1.2 on x86_64 test. Thanks, Zwane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Updated ext4 patchset: 2.6.20-ext4-2
There is a newly updated ext4 patchset available at: http://www2.kernel.org/pub/linux/kernel/people/tytso/ext4-patches and http://www2.kernel.org/git/?p=linux/kernel/git/tytso/ext4.git Compared to 2.6.20-ext4-1, I've removed the the i_version patch, since they had numerous issues, including not building on ia64. I've also added the nanosecond timestamp patch. Discussion will be happening on the linux-ext4 mailing list. I plan to be pushing extent-overlap-bugfix to Linus soon; other patches still need work before they will be ready. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loopback mount EXT3 oops
On Mon, 19 Feb 2007 10:52:42 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote: > Hi all, > > This happened on 2.6.20-rc6-mm3, so I upgraded to 2.6.20-git14, and > same thing happened. Doing a forced fsck on the (corrupted by > double-mounting I think) filesystem fixed it, but I took a copy before > doing that. > > Do we care about ext3 barfing on corrupted filesystems? yup. > [ 1329.782923] EXT3 FS on loop0, internal journal > [ 1329.782926] EXT3-fs: recovery complete. > [ 1329.783186] EXT3-fs: mounted filesystem with ordered data mode. > [ 1329.921992] EXT3-fs warning (device loop0): ext3_unlink: Deleting > nonexistent file (842294), 0 > [ 1329.922516] EXT3-fs warning (device loop0): ext3_unlink: Deleting > nonexistent file (842295), 0 > [ 1329.922524] list_add corruption. next->prev should be prev (f6705c9c), but > was f21a886c. (next=f21a886c). > [ 1329.922546] [ cut here ] > [ 1329.922548] kernel BUG at lib/list_debug.c:27! > [ 1329.922550] invalid opcode: [#1] > [ 1329.922551] Modules linked in: loop binfmt_misc i915 ipv6 drm > cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table > cpufreq_conservative video thermal processor fan button battery asus_acpi > backlight ac tsdev keyspan usbserial usbhid af_packet evdev psmouse > snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer > ehci_hcd rtc uhci_hcd iTCO_wdt iTCO_vendor_support snd soundcore > snd_page_alloc e1000 intel_agp agpgart usbcore > [ 1329.922574] CPU:0 > [ 1329.922575] EIP:0060:[]Not tainted VLI > [ 1329.922576] EFLAGS: 00010286 (2.6.20-git14 #25) > [ 1329.922581] EIP is at __list_add+0x40/0x60 > [ 1329.922583] eax: 0070 ebx: f6705c9c ecx: c011d791 edx: f6352ac0 > [ 1329.922585] esi: f21a88cc edi: f2056a54 ebp: f2169eac esp: f2169e94 > [ 1329.922587] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > [ 1329.922589] Process rm (pid: 3494, ti=f2168000 task=f6352ac0 > task.ti=f2168000) > [ 1329.922591] Stack: c03a437c f6705c9c f21a886c f21a886c f21a88cc > f2169eb4 c01f0bca > [ 1329.922597]f2169ef4 c01ba4fc f2169ed4 f219a5c8 f21a8b54 f21a8c58 > f69683c4 f69683c4 > [ 1329.922602]f21a87c8 f21a886c f219aba0 0300 00ce > f21a88cc f21a8c58 > [ 1329.922607] Call Trace: > [ 1329.922609] [] show_trace_log_lvl+0x1a/0x30 > [ 1329.922612] [] show_stack_log_lvl+0xb1/0xe0 > [ 1329.922615] [] show_registers+0x1d0/0x2d0 > [ 1329.922618] [] die+0xf9/0x220 > [ 1329.922621] [] do_trap+0x82/0xb0 > [ 1329.922623] [] do_invalid_op+0x97/0xb0 > [ 1329.922626] [] error_code+0x74/0x7c > [ 1329.922630] [] list_add+0xa/0x10 > [ 1329.922632] [] ext3_orphan_add+0x17c/0x210 > [ 1329.922636] [] ext3_unlink+0x127/0x1b0 > [ 1329.922638] [] vfs_unlink+0x88/0xe0 > [ 1329.922642] [] do_unlinkat+0xb8/0x140 > [ 1329.922645] [] sys_unlink+0x10/0x20 > [ 1329.922647] [] sysenter_past_esp+0x69/0xb1 > [ 1329.922650] === I thought Eric fixed that. Maybe he broke it instead ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> --- a/fs/fs-writeback.c~a
> +++ a/fs/fs-writeback.c
> @@ -356,7 +356,7 @@ int generic_sync_sb_inodes(struct super_
> continue; /* Skip a congested blockdev */
> }
>
> - if (wbc->bdi && bdi != wbc->bdi) {
> + if (wbc->bdi && bdi != wbc->bdi && bdi_write_congested(bdi)) {
> if (!sb_is_blkdev_sb(sb))
> break; /* fs has the wrong queue */
> list_move(>i_list, >s_dirty);
Checking bdi_write_congested(bdi) is not reliable, since the queue can
become congested _after_ the check is done.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: memparse(), simple_strtoul() prototypes...
Francis Moreau wrote: Hi, I must miss something... Looking at these prototypes unsigned long simple_strtoul(const char *cp, char **endp,unsigned int base) unsigned long long memparse (char *ptr, char **retptr) I'm really wondering why not all parameters are not all 'const'. None of these functions modify any pointer containts. And simple_strtoul() ends up doing sometghing like: if (endp) *endp = (char *)cp; Could anyone shed some light ? The C standard behaves like that, too, mostly because C doesn't have a way to say "X is const iff Y is const" (unlike C++, btw.) -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm2
On Mon, 19 Feb 2007 00:32:08 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > One more thing: > > rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 > Unable to handle kernel NULL pointer dereference at 0030 RIP: > [] rtc_sysfs_remove_device+0x23/0x50 > PGD 5e10c067 PUD 5dd58067 PMD 0 > Oops: [1] PREEMPT > last sysfs file: /devices/pnp0/00:04/id > CPU 0 > Modules linked in: cdrom rtc_cmos snd_intel8x0 snd_ac97_codec ac97_bus > snd_pcm snd_timer snd soundcore i2c_nforce2 i2c_core snd_page_alloc ohci_hcd > ehci_hcd evdev parport_pc lp parport fan thermal processor > Pid: 2960, comm: modprobe Not tainted 2.6.20-mm2 #1 > RIP: 0010:[] [] > rtc_sysfs_remove_device+0x23/0x50 > RSP: 0018:81005e3f9c18 EFLAGS: 00010202 > RAX: RBX: 81005dabeea0 RCX: > RDX: 804032a0 RSI: 805cfba0 RDI: 81005dabeea0 > RBP: 81005e3f9c28 R08: 0001 R09: > R10: R11: R12: 81005dabeea0 > R13: 810002890258 R14: 810002890268 R15: 810002890098 > FS: 2ac610b906f0() GS:805db000() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 0030 CR3: 5e16d000 CR4: 06e0 > Process modprobe (pid: 2960, threadinfo 81005e3f8000, task > 81005e6a7140) > Stack: 81005fe244e8 805cfba0 81005e3f9c68 803c5786 > 81005dabeea0 81005dabf008 0008 > 81005fe244e8 0008 81005e3f9c88 803c5891 > Call Trace: > [] class_device_del+0x86/0x180 > [] class_device_unregister+0x11/0x20 > [] rtc_device_unregister+0x3e/0x50 > [] :rtc_cmos:cmos_pnp_probe+0x219/0x240 > [] pnp_device_probe+0xa1/0xe0 > [] __driver_attach+0x0/0xa0 > [] driver_probe_device+0x115/0x1c0 > [] __driver_attach+0x0/0xa0 > [] __driver_attach+0x63/0xa0 > [] bus_for_each_dev+0x4f/0x80 > [] driver_attach+0x1c/0x20 > [] bus_add_driver+0x83/0x1d0 > [] driver_register+0x89/0x90 > [] pnp_register_driver+0x1c/0x20 > [] :rtc_cmos:cmos_init+0x10/0x12 > [] sys_init_module+0x158b/0x16f0 > [] dnotify_parent+0x7a/0x90 > [] file_read_actor+0x0/0x170 > [] system_call+0x7e/0x83 > > > Code: 48 83 78 30 00 74 0c 48 c7 c6 60 e1 4a 80 e8 aa 23 fc ff 48 > RIP [] rtc_sysfs_remove_device+0x23/0x50 > RSP > CR2: 0030 How did you provoke that? modprobe rtc-cmos? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm2: compilation fix
On Mon, 19 Feb 2007 00:33:26 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > I think something like this is generally necessary: > > --- > drivers/pci/quirks.c |1 + > 1 file changed, 1 insertion(+) > > Index: linux-2.6.20-mm2/drivers/pci/quirks.c > === > --- linux-2.6.20-mm2.orig/drivers/pci/quirks.c > +++ linux-2.6.20-mm2/drivers/pci/quirks.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > #include "pci.h" > > /* The Mellanox Tavor device gives false positive parity errors Will break all non-x86. What are we trying to fix here? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] killing the NR_IRQS arrays.
On Sun, 2007-02-18 at 22:24 +0100, Arjan van de Ven wrote: > On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote: > > * Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > > > > So I propose we remove all assumptions from the code that we actually > > > have an array of irqs. That will allow for irq_desc to be dynamically > > > allocated instead of statically allocated saving memory and reducing > > > kernel complexity. > > > > hm. I'd suggest to do this without changing request_irq() - and then we > > could avoid the 'massive, every driver affected' change, right? > > if request_irq() changes we might as well make a variant that takes a > PCI device struct rather than a number, for the 99% of PCI drivers that > use that.. (and then msi and other stuff becomes simpler :) As a matter of fact, if IRQs has to be handled properly as resources of their respective devices, I think request_irq replacement should take a struct device... In fact, having IRQs hanging off their respective devices would give a proper way to access them via sysfs and implement the affinity etc... thus providing a long term replacement for the current number based APIs. In addition, to facilitate the job of things like IRQ balancing daemons, a /sys/irqs/ could be created containing symlinks to all irqs in the system. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus' laptop and Num lock status
Randy Dunlap wrote: On Sun, 18 Feb 2007 09:32:15 -0800 H. Peter Anvin wrote: Jean Delvare wrote: On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote: Jean Delvare wrote: On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The BIOS RAM is mapped at 0x400 so all we need to do is to one byte from RAM (offset 0x497). This is how Suse's hwinfo does. Perhaps that's what Suse does, but the proper address is 0x417. 0x497 is the rarely-used LPT2 timeout counter. Still, the information printed by hwinfo is correct, I've tested it myself. Is there some publicly available documentation about the x86 BIOS RAM mapping? Google for Ralf Brown's Interrupt List. (Ralph) I didn't find the BIOS data areas/tables in Ralph's web pages... It's called memory.lst in the Interrupt List. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> > > If so, writes to B will decrease the dirty memory threshold. > > > > Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000. > > Some pages queued for writeback (doesn't matter how much). B writes > > back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for > > B doesn't know that there's nothing more to write back for B, it's > > just waiting there for those 1099, which'll never get written. > > hm, OK, arguable. I guess something like this.. Doesn't help the fuse case, but does seem to help the loopback mount one. For fuse it's worse with the patch: now the write triggered by the balance recurses into fuse, with disastrous results, since the fuse writeback is now blocked on the userspace queue. fusexmp_fh_no D 40136678 0 505494 506 504 (NOTLB) 08982b78 0001 08f9f9b4 0805d8cb 089a75f8 08982b78 08f98000 08f98000 08f9f9dc 0805a38a 089a7100 08982680 08f9f9cc 08f98000 08f98000 085d8300 08982680 089a7100 08f9fa34 08183006 089a7100 08982680 089a7100 Call Trace: 08f9f9a0: [<0805d8cb>] switch_to_skas+0x3b/0x83 08f9f9b8: [<0805a38a>] _switch_to+0x49/0x99 08f9f9e0: [<08183006>] schedule+0x246/0x547 08f9fa38: [<08103c7e>] fuse_get_req_wp+0xe9/0x14a 08f9fa70: [<08103d2e>] fuse_writepage+0x4f/0x12c 08f9faac: [<0809ce3f>] __writepage+0x1e/0x3d 08f9fac0: [<0809cd39>] write_cache_pages+0x222/0x30a 08f9fb44: [<0809ce8d>] generic_writepages+0x2f/0x35 08f9fb5c: [<0809ced6>] do_writepages+0x43/0x45 08f9fb70: [<080cb8d2>] __writeback_single_inode+0xbc/0x173 08f9fbb8: [<080cbb30>] sync_sb_inodes+0x1a7/0x260 08f9fbe8: [<080cbc54>] writeback_inodes+0x6b/0x81 08f9fc04: [<0809c640>] balance_dirty_pages+0x55/0x153 08f9fc5c: [<0809c7bf>] balance_dirty_pages_ratelimited_nr+0x43/0x45 08f9fc68: [<080992b5>] generic_file_buffered_write+0x3e3/0x6f5 08f9fd20: [<0809988e>] __generic_file_aio_write_nolock+0x2c7/0x5dd 08f9fda8: [<08099cb6>] generic_file_aio_write+0x55/0xc7 08f9fddc: [<080ea206>] ext3_file_write+0x39/0xaf 08f9fe04: [<080b060b>] do_sync_write+0xd8/0x10e 08f9febc: [<080b06e3>] vfs_write+0xa2/0x1cb 08f9feec: [<080b09b8>] sys_pwrite64+0x65/0x69 08f9ff10: [<0805dd54>] handle_syscall+0x90/0xbc 08f9ff64: [<0806d56c>] handle_trap+0x27/0x121 08f9ff8c: [<0806dc65>] userspace+0x1de/0x226 08f9ffe4: [<0805da19>] fork_handler+0x76/0x88 08f9fffc: [<>] nosmp+0xf7fb7000/0x14 > but where's pdflush? It should be busily transferring dirtiness from A to > B. The transfer of dirtyness from A to B goes through the narrow channel of i_mutex. And once that is plugged by the stuck balance_dirty_pages() nothing else can pass through. > > > The writeout code _should_ just sit there transferring dirtyiness from A > > > to > > > B and cleaning pages via B, looping around, alternating between both. > > > > > > What does sysrq-t say? > > > > This is the fuse daemon thread that got stuck. > > Where's pdflsuh? Doing nothing I guess. The request queue for the fuse filesystem is full, so writepage with wbc->nonblocking=1 will be skipped. pdflush D 40045401 023 52412 (L-TLB) 088d5bf8 0001 08907df8 0805d8cb 088d55f8 088d5bf8 0890 0890 08907e20 0805a38a 088d5100 088d5700 08907e10 0890 0890 0847c300 088d5700 088d5100 08907e78 08182fe6 088d5100 088d5700 088d5100 Call Trace: 08907de4: [<0805d8cb>] switch_to_skas+0x3b/0x83 08907dfc: [<0805a38a>] _switch_to+0x49/0x99 08907e24: [<08182fe6>] schedule+0x246/0x547 08907e7c: [<08183a03>] schedule_timeout+0x4e/0xb6 08907eb0: [<08183991>] io_schedule_timeout+0x11/0x20 08907eb8: [<080a0cf2>] congestion_wait+0x72/0x87 08907ee8: [<0809c860>] background_writeout+0x35/0xa4 08907f38: [<0809d41e>] __pdflush+0xae/0x152 08907f54: [<0809d4f5>] pdflush+0x33/0x39 08907f84: [<0808a03a>] kthread+0xa7/0xab 08907fb4: [<0806a0f1>] run_kernel_thread+0x41/0x50 08907fe0: [<0805d975>] new_thread_handler+0x62/0x8b 08907ffc: [<>] nosmp+0xf7fb7000/0x14 pdflush D 40045401 024 52523 (L-TLB) 081e1458 0001 088ffe00 0805d8cb 088d5bf8 081e1458 088f8000 088f8000 088ffe28 0805a38a 088d5700 081e0f60 088ffe18 088f8000 088f8000 0847c300 081e0f60 088d5700 088ffe80 08182fe6 088d5700 081e0f60 088d5700 Call Trace: 088ffdec: [<0805d8cb>] switch_to_skas+0x3b/0x83 088ffe04: [<0805a38a>] _switch_to+0x49/0x99 088ffe2c: [<08182fe6>] schedule+0x246/0x547 088ffe84: [<08183a03>] schedule_timeout+0x4e/0xb6 088ffeb8: [<08183991>] io_schedule_timeout+0x11/0x20 088ffec0: [<080a0cf2>] congestion_wait+0x72/0x87 088ffef0: [<0809c98c>] wb_kupdate+0x93/0xd9 088fff38: [<0809d41e>] __pdflush+0xae/0x152 088fff54: [<0809d4f5>] pdflush+0x33/0x39 088fff84: [<0808a03a>] kthread+0xa7/0xab 088fffb4: [<0806a0f1>] run_kernel_thread+0x41/0x50 088fffe0: [<0805d975>] new_thread_handler+0x62/0x8b 088c: [<>] nosmp+0xf7fb7000/0x14 - To unsubscribe from this list: send the line
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
Hi Jiri, > > I m using a Logitech MX 5000 keyboard with an included MX 1000 mouse, > > both bluetooth using the same USB reciever. > > When the USB reciever is already plugged-in at boot-time and the > > Bluetooth service fires-up I get this message: > > === > > BUG: warning: (value > m) at > > drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) > > [] dump_trace+0x69/0x1b6 > > [] show_trace_log_lvl+0x18/0x2c > > [] show_trace+0xf/0x11 > > [] dump_stack+0x15/0x17 > > [] hid_output_report+0x23c/0x2e7 > > [] hid_submit_ctrl+0x4c/0x1d9 > > [] hid_submit_report+0x134/0x15f > > [] hiddev_ioctl+0x327/0x88a > > [] do_ioctl+0x4c/0x62 > > [] vfs_ioctl+0x24a/0x25c > > [] sys_ioctl+0x4c/0x66 > > [] syscall_call+0x7/0xb > > [<005b5402>] 0x5b5402 > > === > > (added Marcel to CC) > > This means that something (I guess that it's hid2hci command?) is trying > to pass through hiddev a value in a field that is greater than a given > bitmask (and is not going to fit into the bitfield). > > Vincent, does the problem go away when you don't use bluetooth (both > keyboard and mouse is switched to HID mode, if they support it)? > > Marcel, do you have any idea how this could happen? we understand the original CSR HID proxy dongles, but for the Logitech ones, it is wild guesses. The current support in hid2hci has been tested on Logitech diNovo first generation and I have no other Logitech hardware to verify it with. We might simply need the full HID report descriptor to see who is at fault. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 02/11] syslets: add syslet.h include file, user API/ABI definitions
Ingo Molnar writes:
> add include/linux/syslet.h which contains the user-space API/ABI
> declarations. Add the new header to include/linux/Kbuild as well.
> +struct syslet_uatom {
> + unsigned long flags;
> + unsigned long nr;
> + long __user *ret_ptr;
> + struct syslet_uatom __user *next;
> + unsigned long __user *arg_ptr[6];
> + /*
> + * User-space can put anything in here, kernel will not
> + * touch it:
> + */
> + void __user *private;
> +};
This structure, with its unsigned longs and pointers, is going to
create enormous headaches for 32-bit processes on 64-bit machines as
far as I can see---and on ppc64 machines, almost all processes are
32-bit, since there is no inherent speed penalty for running in 32-bit
mode, and some space savings.
Have you thought about how you will handle compatibility for 32-bit
processes? The issue will arise for x86_64 and ia64 (among others)
too, I would think.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-mm2
On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > netconsole is good. > > I know. :-) > > In the meantime, I've got something worse on another x86_64 box: > > Asus Laptop ACPI Extras version 0.30 > L5D model detected, supported > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 > general protection fault: [2] PREEMPT > last sysfs file: /class/net/eth2/carrier > CPU 0 > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq > snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 > RIP: 0010:[] [] > __make_request+0x134/0x370 > RSP: :81005ed659a0 EFLAGS: 00010297 > RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 > R10: R11: R12: 810037b4dbb0 > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 > FS: 2ad4a29e6d00() GS:805db000() knlGS: > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 > Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) > Stack: 810002852540 0001 810037b4dbb0 8026be21 > 81005ed65a40 0008 810037b4dbb0 0800 > 0008 8100021d94e0 81005ed65a40 80348e7c > Call Trace: > [] mempool_alloc_slab+0x11/0x20 > [] generic_make_request+0x1ec/0x230 yeah. everyone except me is hitting that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver
On Sun, Feb 18, 2007 at 06:31:23AM -0500, Jaya Kumar wrote: > On 2/17/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > >This would also provide an interesting hook for setting up chained DMA > >for the real framebuffer updates when there's more than a couple of pages > >that have been touched, which would also be nice to have. There's more > >than a few drivers that could take advantage of that. > > I could benefit from knowing which driver and display device you are > considering to be applicable. > > I was thinking the method used in hecubafb would only be useful to > devices with very slow update paths, where "losing" some of the > display activity is not an issue since the device would not have been > able to update fast enough to show that activity anyway. > > What you described with chained DMA sounds different to this. I > suppose one could use this technique to coalesce framebuffer IO to get > better performance/utilization even for fast display devices. Sounds > interesting to try. Did I understand you correctly? > Yes, that's what I'm interested in trying. In the SH case we can basically make use of the on-chip DMAC for any non-PCI device. Some of these permit scatterlists and chained DMA in hardware, others do not. The general problem is that since we have to go and poke at the dcache prior to kicking off the DMA, it's rarely a win for a small number of pages, memory bursts just end up being faster. The other issue is that most of the "big" writers are doing so via mmap() anyways, so it's futile to attempt to handle the DMA case in the ->write() path. Your approach seems like it might be an appropriate interface for building something like this on top of. Given that, this would have to be something that's dealt with at the subsystem level rather than in individual drivers, hence the desire to see something like this more generically visible. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
On Mon, 19 Feb 2007 00:22:11 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > If so, writes to B will decrease the dirty memory threshold.
>
> Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000.
> Some pages queued for writeback (doesn't matter how much). B writes
> back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for
> B doesn't know that there's nothing more to write back for B, it's
> just waiting there for those 1099, which'll never get written.
hm, OK, arguable. I guess something like this..
--- a/fs/fs-writeback.c~a
+++ a/fs/fs-writeback.c
@@ -356,7 +356,7 @@ int generic_sync_sb_inodes(struct super_
continue; /* Skip a congested blockdev */
}
- if (wbc->bdi && bdi != wbc->bdi) {
+ if (wbc->bdi && bdi != wbc->bdi && bdi_write_congested(bdi)) {
if (!sb_is_blkdev_sb(sb))
break; /* fs has the wrong queue */
list_move(>i_list, >s_dirty);
_
but where's pdflush? It should be busily transferring dirtiness from A to
B.
> > The writeout code _should_ just sit there transferring dirtyiness from A to
> > B and cleaning pages via B, looping around, alternating between both.
> >
> > What does sysrq-t say?
>
> This is the fuse daemon thread that got stuck.
Where's pdflsuh?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
loopback mount EXT3 oops
Hi all, This happened on 2.6.20-rc6-mm3, so I upgraded to 2.6.20-git14, and same thing happened. Doing a forced fsck on the (corrupted by double-mounting I think) filesystem fixed it, but I took a copy before doing that. Do we care about ext3 barfing on corrupted filesystems? [ 1329.782923] EXT3 FS on loop0, internal journal [ 1329.782926] EXT3-fs: recovery complete. [ 1329.783186] EXT3-fs: mounted filesystem with ordered data mode. [ 1329.921992] EXT3-fs warning (device loop0): ext3_unlink: Deleting nonexistent file (842294), 0 [ 1329.922516] EXT3-fs warning (device loop0): ext3_unlink: Deleting nonexistent file (842295), 0 [ 1329.922524] list_add corruption. next->prev should be prev (f6705c9c), but was f21a886c. (next=f21a886c). [ 1329.922546] [ cut here ] [ 1329.922548] kernel BUG at lib/list_debug.c:27! [ 1329.922550] invalid opcode: [#1] [ 1329.922551] Modules linked in: loop binfmt_misc i915 ipv6 drm cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative video thermal processor fan button battery asus_acpi backlight ac tsdev keyspan usbserial usbhid af_packet evdev psmouse snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer ehci_hcd rtc uhci_hcd iTCO_wdt iTCO_vendor_support snd soundcore snd_page_alloc e1000 intel_agp agpgart usbcore [ 1329.922574] CPU:0 [ 1329.922575] EIP:0060:[]Not tainted VLI [ 1329.922576] EFLAGS: 00010286 (2.6.20-git14 #25) [ 1329.922581] EIP is at __list_add+0x40/0x60 [ 1329.922583] eax: 0070 ebx: f6705c9c ecx: c011d791 edx: f6352ac0 [ 1329.922585] esi: f21a88cc edi: f2056a54 ebp: f2169eac esp: f2169e94 [ 1329.922587] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 1329.922589] Process rm (pid: 3494, ti=f2168000 task=f6352ac0 task.ti=f2168000) [ 1329.922591] Stack: c03a437c f6705c9c f21a886c f21a886c f21a88cc f2169eb4 c01f0bca [ 1329.922597]f2169ef4 c01ba4fc f2169ed4 f219a5c8 f21a8b54 f21a8c58 f69683c4 f69683c4 [ 1329.922602]f21a87c8 f21a886c f219aba0 0300 00ce f21a88cc f21a8c58 [ 1329.922607] Call Trace: [ 1329.922609] [] show_trace_log_lvl+0x1a/0x30 [ 1329.922612] [] show_stack_log_lvl+0xb1/0xe0 [ 1329.922615] [] show_registers+0x1d0/0x2d0 [ 1329.922618] [] die+0xf9/0x220 [ 1329.922621] [] do_trap+0x82/0xb0 [ 1329.922623] [] do_invalid_op+0x97/0xb0 [ 1329.922626] [] error_code+0x74/0x7c [ 1329.922630] [] list_add+0xa/0x10 [ 1329.922632] [] ext3_orphan_add+0x17c/0x210 [ 1329.922636] [] ext3_unlink+0x127/0x1b0 [ 1329.922638] [] vfs_unlink+0x88/0xe0 [ 1329.922642] [] do_unlinkat+0xb8/0x140 [ 1329.922645] [] sys_unlink+0x10/0x20 [ 1329.922647] [] sysenter_past_esp+0x69/0xb1 [ 1329.922650] === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
> > This is hard to trigger problem, so I'll spare you the rather lengthy log. > > It happens if card timeouts and mmc_remove_host is called while > > mmc_register_card is still in > > progress (the hint was in crash dump). If I sleep before remove, it gives > > the > mmc_register_card > > chance to finish/mark card as dead and everything's fine. > > The remove callback of mmc_block is apparently not executed in this case > > (probably because > device > > has not finished registering). > > Let's see, you manage to call mmc_remove_host() when a detection is pending in > the workqueue? That could indeed generate new request (up until > mmc_free_host() > is called), but as the card is removed the mmc layer shouldn't be able to > detect > anything, hence mmc_block should never get involved. > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of requests (reads partition table, fs superblocks and such - plenty of room for critical errors). Then, driver's remove method will not be called before driver's probe method had finished. So mmc_block is quite involved, even though it does not affect the problem's resolution. Besides this, I have a new version of the tifm driver to submit. It fixes quite a few problems and improves performance a little. Hopefully, it's better tested than the previous one. Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Eensy weensy follow-up. No screed. Well, maybe just a _little_ screed. On 2/18/07, Oleg Verych <[EMAIL PROTECTED]> wrote: Ulrich Drepper is known to be against current FSF's position on glibc licence changing. Will that stop the FSF? Will it stop Red Hat, MontaVista, or CodeSourcery? Even if Ulrich tells the FSF to stuff it where the sun don't shine, and hosts his new fork on Google Code along with the rest of the GNU corpus, the moment he or you or any of us wants to run any binary that was compiled against a newer FSF glibc, we're screwed. All it takes is for that binary to have a post-v3-switch symbol in its link table (which can easily happen _without_ any change in the application source code). It's all very well to say we can live without anything that ships as a binary, but commercial applications atop glibc are a big part of how Linux left the hobbyist ghetto, and I don't want to go back there. Do you? Or do you really want to spend the rest of your precious time on Earth shimming clean-room reverse-engineered crap into glibc-GPLv2-fork to keep Oracle running on a distro that Moglen doesn't have by the 'nads? Not that it really matters whether you're using Oracle or MySQL -- an RDBMS, like any racing thoroughbred, goes lame if you look at it funny, and once you've gotten burned once in production by the unreproducibility of the golden bits, you won't try it again. The existence of GNU-free userlands is nice for us embedded folk but ultimately useless for desktops and servers. Talk to the people who have spent untold person-years scrubbing bashisms out of Debian's /etc/init.d. Talk to the people who have ported their industrial-scale multithreaded apps from linuxthreads (with its annoying non-POSIX behaviors) to NPTL (with its equally annoying POSIX behaviors). Talk to the people struggling to package Gnome and KDE for anything other than glibc, libstdc++, and (worst of all) ld.so.2. Portability ain't all it's cracked up to be. If you think "embrace, extend, destroy" is tattooed on Ballmer's forehead, you should take a good look at an RMS word-portrait sometime. And imagine a nice private chat with the if-you-can't-beat-'em-join-'em club -- from IBM and HP to Apple, Wind River, and Sun. Say what you will about Steve Jobs, he's a survivor -- but the ex-CEOs of all the rest will give you an earful about being shot out of the saddle by the "free software" mafia and replaced with people who know how to do a deal with the devil and call it a come-to-Jesus moment in the press release. Intel is keeping mum -- they've made an industry out of playing both ends against the middle, and they've got a compiler that can more or less do Linux anyway, so they don't really care. Google doesn't care either -- they've got more cash than they can spend and can afford to fork internally and go their merry way. The only heavyweight that had refused to get on board until very recently was Oracle. Not just because Larry Ellison likes to fly solo, either -- read http://www.internetnews.com/dev-news/article.php/3614721. Then read http://www.internetnews.com/dev-news/article.php/3655261. Larry, too, is a survivor. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm2
On 19/02/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
> On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
>
> > On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> > >
> > > Temporarily at
> > >
> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> > >
> > > Will appear later at
> > >
> > >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> >
> > Two problems:
> >
> > 1) A showstopper with the root partition on RAID1:
> >
> > md: raid1 personality registered for level 1
> > [--snip--]
> > md: multipath personality registered for level -4
> > register_blkdev: failed to get major for mdp
> > [--snip--]
> > VFS: Cannot open root device "md1" or unknown-block(0,0)
>
> Someone else reported that against mainline. Can you please debug it a bit?
Sure, tomorrow I will.
> I'd suggested reverting the recent changes in there:
>
> --- a/block/genhd.c~a
> +++ a/block/genhd.c
> @@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
> /* temporary */
> if (major == 0) {
> for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
> - /*
> - * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
> - * majors
> - */
> - if ((60 <= index && index <= 63) ||
> - (120 <= index && index <= 127) ||
> - (240 <= index && index <= 254))
> - continue;
> if (major_names[index] == NULL)
> break;
> }
> _
>
> but I don't see how they could cause this.
>
>
> > At the moment I have no serial console attached to the box, so I had to
rewrite
> > the messages manually.
>
> netconsole is good.
I know. :-)
In the meantime, I've got something worse on another x86_64 box:
Asus Laptop ACPI Extras version 0.30
L5D model detected, supported
audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
general protection fault: [2] PREEMPT
last sysfs file: /class/net/eth2/carrier
CPU 0
Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq
snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
RIP: 0010:[] [] __make_request+0x134/0x370
RSP: :81005ed659a0 EFLAGS: 00010297
RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
R10: R11: R12: 810037b4dbb0
R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
FS: 2ad4a29e6d00() GS:805db000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0)
Stack: 810002852540 0001 810037b4dbb0 8026be21
81005ed65a40 0008 810037b4dbb0 0800
0008 8100021d94e0 81005ed65a40 80348e7c
Call Trace:
[] mempool_alloc_slab+0x11/0x20
[] generic_make_request+0x1ec/0x230
[] submit_bio+0xf6/0x110
[] submit_bh+0x100/0x130
[] __block_write_full_page+0x1ca/0x2e0
[] blkdev_get_block+0x0/0x70
[] blkdev_get_block+0x0/0x70
[] block_write_full_page+0xf3/0x110
[] blkdev_writepage+0x13/0x20
[] __writepage+0x15/0x40
[] write_cache_pages+0x1f3/0x360
[] __writepage+0x0/0x40
[] generic_writepages+0x22/0x30
[] do_writepages+0x46/0x80
[] __writeback_single_inode+0x1d7/0x370
[] generic_sync_sb_inodes+0x35/0x2b0
[] generic_sync_sb_inodes+0x1d9/0x2b0
[] writeback_inodes+0x82/0x100
[] sync_sb_inodes+0x25/0x30
[] writeback_inodes+0x98/0x100
[] pdflush+0x0/0x1e0
[] wb_kupdate+0x94/0x110
[] pdflush+0x128/0x1e0
[] wb_kupdate+0x0/0x110
[] pdflush+0x0/0x1e0
[] kthread+0xd3/0x110
[] keventd_create_kthread+0x0/0x90
[] child_rip+0xa/0x12
[] _spin_unlock_irq+0x2b/0x60
[] restore_args+0x0/0x30
[] kthread+0x0/0x110
[] child_rip+0x0/0x12
Code: 48 8b 43 08 0f 18 08 49 39 dd 75 a2 49 8b be 38 02 00 00 e8
RIP [] __make_request+0x134/0x370
RSP
PM: Adding info for No Bus:vcs10
PM: Adding info for No Bus:vcsa10
It looks _really_ bad to me. :-(
It looks familiar to me
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.2/0646.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.2/0821.html
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: 2.6.20-mm2: compilation fix
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ I think something like this is generally necessary: --- drivers/pci/quirks.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.20-mm2/drivers/pci/quirks.c === --- linux-2.6.20-mm2.orig/drivers/pci/quirks.c +++ linux-2.6.20-mm2/drivers/pci/quirks.c @@ -21,6 +21,7 @@ #include #include #include +#include #include "pci.h" /* The Mellanox Tavor device gives false positive parity errors - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm2
On Sunday, 18 February 2007 06:51, Andrew Morton wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ One more thing: rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 Unable to handle kernel NULL pointer dereference at 0030 RIP: [] rtc_sysfs_remove_device+0x23/0x50 PGD 5e10c067 PUD 5dd58067 PMD 0 Oops: [1] PREEMPT last sysfs file: /devices/pnp0/00:04/id CPU 0 Modules linked in: cdrom rtc_cmos snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore i2c_nforce2 i2c_core snd_page_alloc ohci_hcd ehci_hcd evdev parport_pc lp parport fan thermal processor Pid: 2960, comm: modprobe Not tainted 2.6.20-mm2 #1 RIP: 0010:[] [] rtc_sysfs_remove_device+0x23/0x50 RSP: 0018:81005e3f9c18 EFLAGS: 00010202 RAX: RBX: 81005dabeea0 RCX: RDX: 804032a0 RSI: 805cfba0 RDI: 81005dabeea0 RBP: 81005e3f9c28 R08: 0001 R09: R10: R11: R12: 81005dabeea0 R13: 810002890258 R14: 810002890268 R15: 810002890098 FS: 2ac610b906f0() GS:805db000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0030 CR3: 5e16d000 CR4: 06e0 Process modprobe (pid: 2960, threadinfo 81005e3f8000, task 81005e6a7140) Stack: 81005fe244e8 805cfba0 81005e3f9c68 803c5786 81005dabeea0 81005dabf008 0008 81005fe244e8 0008 81005e3f9c88 803c5891 Call Trace: [] class_device_del+0x86/0x180 [] class_device_unregister+0x11/0x20 [] rtc_device_unregister+0x3e/0x50 [] :rtc_cmos:cmos_pnp_probe+0x219/0x240 [] pnp_device_probe+0xa1/0xe0 [] __driver_attach+0x0/0xa0 [] driver_probe_device+0x115/0x1c0 [] __driver_attach+0x0/0xa0 [] __driver_attach+0x63/0xa0 [] bus_for_each_dev+0x4f/0x80 [] driver_attach+0x1c/0x20 [] bus_add_driver+0x83/0x1d0 [] driver_register+0x89/0x90 [] pnp_register_driver+0x1c/0x20 [] :rtc_cmos:cmos_init+0x10/0x12 [] sys_init_module+0x158b/0x16f0 [] dnotify_parent+0x7a/0x90 [] file_read_actor+0x0/0x170 [] system_call+0x7e/0x83 Code: 48 83 78 30 00 74 0c 48 c7 c6 60 e1 4a 80 e8 aa 23 fc ff 48 RIP [] rtc_sysfs_remove_device+0x23/0x50 RSP CR2: 0030 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix refrigerator() vs thaw_process() race
On Sunday, 18 February 2007 23:17, Oleg Nesterov wrote:
> refrigerator() can miss a wakeup, "wait event" loop needs a proper memory
> ordering.
>
> Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
ACK
> --- WQ/kernel/power/process.c~WAKE2007-02-18 22:56:49.0 +0300
> +++ WQ/kernel/power/process.c 2007-02-19 01:04:26.0 +0300
> @@ -46,8 +46,10 @@ void refrigerator(void)
> recalc_sigpending(); /* We sent fake signal, clean it up */
> spin_unlock_irq(>sighand->siglock);
>
> - while (frozen(current)) {
> - current->state = TASK_UNINTERRUPTIBLE;
> + for (;;) {
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + if (!frozen(current))
> + break;
> schedule();
> }
> pr_debug("%s left refrigerator\n", current->comm);
>
>
>
--
If you don't have the time to read,
you don't have the time or the tools to write.
- Stephen King
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-mm2
On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
> On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> > >
> > > Temporarily at
> > >
> > > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> > >
> > > Will appear later at
> > >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> >
> > Two problems:
> >
> > 1) A showstopper with the root partition on RAID1:
> >
> > md: raid1 personality registered for level 1
> > [--snip--]
> > md: multipath personality registered for level -4
> > register_blkdev: failed to get major for mdp
> > [--snip--]
> > VFS: Cannot open root device "md1" or unknown-block(0,0)
>
> Someone else reported that against mainline. Can you please debug it a bit?
Sure, tomorrow I will.
> I'd suggested reverting the recent changes in there:
>
> --- a/block/genhd.c~a
> +++ a/block/genhd.c
> @@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
> /* temporary */
> if (major == 0) {
> for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
> - /*
> - * Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
> - * majors
> - */
> - if ((60 <= index && index <= 63) ||
> - (120 <= index && index <= 127) ||
> - (240 <= index && index <= 254))
> - continue;
> if (major_names[index] == NULL)
> break;
> }
> _
>
> but I don't see how they could cause this.
>
>
> > At the moment I have no serial console attached to the box, so I had to
> > rewrite
> > the messages manually.
>
> netconsole is good.
I know. :-)
In the meantime, I've got something worse on another x86_64 box:
Asus Laptop ACPI Extras version 0.30
L5D model detected, supported
audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
general protection fault: [2] PREEMPT
last sysfs file: /class/net/eth2/carrier
CPU 0
Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq
snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
RIP: 0010:[] [] __make_request+0x134/0x370
RSP: :81005ed659a0 EFLAGS: 00010297
RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
R10: R11: R12: 810037b4dbb0
R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
FS: 2ad4a29e6d00() GS:805db000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0)
Stack: 810002852540 0001 810037b4dbb0 8026be21
81005ed65a40 0008 810037b4dbb0 0800
0008 8100021d94e0 81005ed65a40 80348e7c
Call Trace:
[] mempool_alloc_slab+0x11/0x20
[] generic_make_request+0x1ec/0x230
[] submit_bio+0xf6/0x110
[] submit_bh+0x100/0x130
[] __block_write_full_page+0x1ca/0x2e0
[] blkdev_get_block+0x0/0x70
[] blkdev_get_block+0x0/0x70
[] block_write_full_page+0xf3/0x110
[] blkdev_writepage+0x13/0x20
[] __writepage+0x15/0x40
[] write_cache_pages+0x1f3/0x360
[] __writepage+0x0/0x40
[] generic_writepages+0x22/0x30
[] do_writepages+0x46/0x80
[] __writeback_single_inode+0x1d7/0x370
[] generic_sync_sb_inodes+0x35/0x2b0
[] generic_sync_sb_inodes+0x1d9/0x2b0
[] writeback_inodes+0x82/0x100
[] sync_sb_inodes+0x25/0x30
[] writeback_inodes+0x98/0x100
[] pdflush+0x0/0x1e0
[] wb_kupdate+0x94/0x110
[] pdflush+0x128/0x1e0
[] wb_kupdate+0x0/0x110
[] pdflush+0x0/0x1e0
[] kthread+0xd3/0x110
[] keventd_create_kthread+0x0/0x90
[] child_rip+0xa/0x12
[] _spin_unlock_irq+0x2b/0x60
[] restore_args+0x0/0x30
[] kthread+0x0/0x110
[] child_rip+0x0/0x12
Code: 48 8b 43 08 0f 18 08 49 39 dd 75 a2 49 8b be 38 02 00 00 e8
RIP [] __make_request+0x134/0x370
RSP
PM: Adding info for No Bus:vcs10
PM: Adding info for No Bus:vcsa10
It looks _really_ bad to me. :-(
> > 2) On HPC nx6325 I get the following 100% of the time during the resume from
> > disk:
> >
> > BUG: at drivers/pci/pci.c:823 pcim_enable_device()
> >
> > Call Trace:
> > [] pcim_enable_device+0x93/0xb3
> > [] ata_pci_device_do_resume+0x21/0x5e
> > [] sil_pci_device_resume+0x1c/0x51
> > [] pci_device_resume+0x22/0x53
> > [] resume_device+0xca/0x131
> > [] dpm_resume+0x81/0xd3
> > [] device_resume+0x30/0x45
> > [] snapshot_ioctl+0x245/0x63e
> > [] do_ioctl+0x5e/0x77
> > [] vfs_ioctl+0x25c/0x279
> > [] sys_ioctl+0x5f/0x82
> >
I2O block driver broken in kernel 2.6.19?
Fedora is getting a bunch of bug reports about the I2O block driver not working in 2.6.19 kernels. Everything looks like it loads OK, but no block IO can be done, not even reading the partition table: I2O subsystem v1.325 i2o: max drivers = 8 i2o: Checking for PCI I2O controllers... ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19 ACPI: PCI Interrupt :01:07.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19 iop0: controller found (:01:07.0) iop0: limit sectors per request to 128 iop0: using 64-bit DMA iop0: PCI I2O controller at E000 size=1048576 iop0: Installed at IRQ 19 i2o: iop0: Activating I2O controller... i2o: iop0: This may take a few minutes if there are many devices iop0: HRT has 1 entries of 16 bytes each. Adapter 0012: TID :[HPC*]:PCI 1: Bus 1 Device 22 Function 0 i2o: iop0: Controller added I2O Block Device OSM v1.325 block-osm: registered device at major 80 i2o/hda:<3>Buffer I/O error on device i2o/hda, logical block 0 Buffer I/O error on device i2o/hda, logical block 0 Buffer I/O error on device i2o/hda, logical block 0 unable to read partition table block-osm: device added (TID: 209): i2o/hda The driver looks unchanged except for cleanups... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: freezer problems
On Sunday, 18 February 2007 23:01, Oleg Nesterov wrote: > On 02/18, Rafael J. Wysocki wrote: > > > > Appended is a patch that does something along these lines. The necessary > > thread_info flags are defined for i386 and x86_64, for now. > > I'll try to look at this patch when I am not so sleepy ... > > just one small nit right now, > > > --- linux-2.6.20-mm2.orig/include/asm-i386/thread_info.h2007-02-18 > > 19:49:34.0 +0100 > > +++ linux-2.6.20-mm2/include/asm-i386/thread_info.h 2007-02-18 > > 19:50:37.0 +0100 > > @@ -135,6 +135,7 @@ static inline struct thread_info *curren > > #define TIF_IO_BITMAP 18 /* uses I/O bitmap */ > > #define TIF_FREEZE 19 /* is freezing for suspend */ > > #define TIF_FORCED_TF 20 /* true if TF in eflags > > artificially */ > > +#define TIF_FREEZER_SKIP 21 /* task freezer should not count us */ > > Do we need to put this flag into thread_info? It is always modified by > "current", so it could live in task_struct->flags instead. I thought we were running low on the task_struct->flags bits. :-) Apart from this, we may need to set it from somewhere else in the future. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> > > > I was testing the new fuse shared writable mmap support, and finding > > > > that bash-shared-mapping deadlocks (which isn't so strange ;). What > > > > is more strange is that this is not an OOM situation at all, with > > > > plenty of free and cached pages. > > > > > > > > A little more investigation shows that a similar deadlock happens > > > > reliably with bash-shared-mapping on a loopback mount, even if only > > > > half the total memory is used. > > > > > > > > The cause is slightly different in the two cases: > > > > > > > > - loopback mount: allocation by the underlying filesystem is stalled > > > > on throttle_vm_writeout() > > > > > > > > - fuse-loop: page dirtying on the underlying filesystem is stalled on > > > > balance_dirty_pages() > > > > > > > > In both cases the underlying fs is totally innocent, with no > > > > dirty/writback pages, yet it's waiting for the global dirty+writeback > > > > to go below the threshold, which obviously won't, until the > > > > allocation/dirtying succeeds. > > > > > > > > I'm not quite sure what the solution is, and asking for thoughts. > > > > > > But these things don't just throttle. They also perform large > > > amounts > > > of writeback, which causes the dirty levels to subside. > > > > > > >From your description it appears that this writeback isn't happening, or > > > isn't working. How come? > > > > - filesystems A and B > > - write to A will end up as write to B > > - dirty pages in A manage to go over dirty_threshold > > - page writeback is started from A > > - this triggers writeback for a couple of pages in B > > - writeback finishes normally, but dirty+writeback pages are still > >over threshold > > - balance_dirty_pages in B gets stuck, nothing ever moves after this > > > > At least this is my theory for what happens. > > > > Is B a real filesystem? Yes. > If so, writes to B will decrease the dirty memory threshold. Yes, but not by enough. Say A dirties a 1100 pages, limit is 1000. Some pages queued for writeback (doesn't matter how much). B writes back 1, 1099 dirty remain in A, zero in B. balance_dirty_pages() for B doesn't know that there's nothing more to write back for B, it's just waiting there for those 1099, which'll never get written. > The writeout code _should_ just sit there transferring dirtyiness from A to > B and cleaning pages via B, looping around, alternating between both. > > What does sysrq-t say? This is the fuse daemon thread that got stuck. There are lots of others that are stuck on some ext3 mutex as a result of this. fusexmp_fh_no D 40045401 0 527493 533 495 (NOTLB) 088d55f8 0001 08dcfb14 0805d8cb 08a09b78 088d55f8 08dc8000 08dc8000 08dcfb3c 0805a38a 08a09680 088d5100 08dcfb2c 08dc8000 08dc8000 0847c300 088d5100 08a09680 08dcfb94 08182fe6 08a09680 088d5100 08a09680 Call Trace: 08dcfb00: [<0805d8cb>] switch_to_skas+0x3b/0x83 08dcfb18: [<0805a38a>] _switch_to+0x49/0x99 08dcfb40: [<08182fe6>] schedule+0x246/0x547 08dcfb98: [<08183a03>] schedule_timeout+0x4e/0xb6 08dcfbcc: [<08183991>] io_schedule_timeout+0x11/0x20 08dcfbd4: [<080a0cf2>] congestion_wait+0x72/0x87 08dcfc04: [<0809c693>] balance_dirty_pages+0xa8/0x153 08dcfc5c: [<0809c7bf>] balance_dirty_pages_ratelimited_nr+0x43/0x45 08dcfc68: [<080992b5>] generic_file_buffered_write+0x3e3/0x6f5 08dcfd20: [<0809988e>] __generic_file_aio_write_nolock+0x2c7/0x5dd 08dcfda8: [<08099cb6>] generic_file_aio_write+0x55/0xc7 08dcfddc: [<080ea1e6>] ext3_file_write+0x39/0xaf 08dcfe04: [<080b060b>] do_sync_write+0xd8/0x10e 08dcfebc: [<080b06e3>] vfs_write+0xa2/0x1cb 08dcfeec: [<080b09b8>] sys_pwrite64+0x65/0x69 08dcff10: [<0805dd54>] handle_syscall+0x90/0xbc 08dcff64: [<0806d56c>] handle_trap+0x27/0x121 08dcff8c: [<0806dc65>] userspace+0x1de/0x226 08dcffe4: [<0805da19>] fork_handler+0x76/0x88 08dcfffc: [] 0xd4cf0007 /proc/vmstat: nr_anon_pages 668 nr_mapped 3168 nr_file_pages 5191 nr_slab_reclaimable 173 nr_slab_unreclaimable 494 nr_page_table_pages 65 nr_dirty 2174 nr_writeback 10 nr_unstable 0 nr_bounce 0 nr_vmscan_write 0 pgpgin 10955 pgpgout 421091 pswpin 0 pswpout 0 pgalloc_dma 0 pgalloc_normal 268761 pgfree 269709 pgactivate 128287 pgdeactivate 31253 pgfault 237350 pgmajfault 4340 pgrefill_dma 0 pgrefill_normal 127899 pgsteal_dma 0 pgsteal_normal 46892 pgscan_kswapd_dma 0 pgscan_kswapd_normal 47104 pgscan_direct_dma 0 pgscan_direct_normal 36544 pginodesteal 0 slabs_scanned 2048 kswapd_steal 25083 kswapd_inodesteal 335 pageoutrun 656 allocstall 423 pgrotated 0 Breakpoint 3, balance_dirty_pages (mapping=0xa01feb0) at mm/page-writeback.c:202 202 dirty_exceeded = 1; (gdb) p dirty_thresh $1 = 2113 (gdb) For completeness' sake, here's the backtrace for the stuck loopback as well: loop0 D BFFFE101 0 499 5 50059 (L-TLB) 088cc578 0001 09197c4c 0805d8cb 084fe6f8 088cc578 0919
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
> You could blacklist the ACPI "thermal" module instead. If you're > interested in monitoring your CPU temperature, k8temp is IMHO more > convenient to use than ACPI, as it interfaces properly with libsensors > and all hardware monitoring user interfaces. That would be somewhat dangerous because ACPI thermal does more than just displaying the temperature. Especially laptops often need it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch
Maynard Johnson wrote: Arnd Bergmann wrote: On Friday 16 February 2007 01:32, Maynard Johnson wrote: config OPROFILE_CELL bool "OProfile for Cell Broadband Engine" depends on OPROFILE && SPU_FS default y if ((SPU_FS = y && OPROFILE = y) || (SPU_FS = m && OPROFILE = m)) help Profiling of Cell BE SPUs requires special support enabled by this option. Both SPU_FS and OPROFILE options must be set 'y' or both be set 'm'. = Can anyone see a problem with any of this . . . or perhaps a suggestion of a better way? The text suggests it doesn't allow SPU_FS=y with OPROFILE=m, which I think should be allowed. Right, good catch. I'll add another OR to the 'default y' and correct the text. Actually, it makes more sense to do the following: config OPROFILE_CELL bool "OProfile for Cell Broadband Engine" depends on (SPU_FS = y && OPROFILE = m) || (SPU_FS = y && OPROFILE = y) || (SPU_FS = m && OPROFILE = m) default y help Profiling of Cell BE SPUs requires special support enabled by this option. > I also don't see any place in the code where you actually use CONFIG_OPROFILE_CELL. As I mentioned, I will use CONFIG_OPROFILE_CELL in the arch/powerpc/oprofile/Makefile as follows: oprofile-$(CONFIG_OPROFILE_CELL) += op_model_cell.o \ cell/spu_profiler.o cell/vma_map.o cell/spu_task_sync.o [snip] Arnd <>< ___ Linuxppc-dev mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-dev - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA WLAN card initialization error
On Sun, 2007-02-18 at 23:40 +0200, Timur Aydin wrote: > reg is indeed 0x and the function returns -ENODEV. > > I need help to further troubleshoot the problem, any directions or > hints welcome... The card is likely dead, but please check it with hostap_cs and on different hardware just in case. If you have further questions, please post them to [EMAIL PROTECTED] -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] libata-core: remove akpm's comments
I have a small hope this patch is correct (compile tested). At least, the code
was not correct before this patch. "Cancel and flush" should do "Cancel", and
then "flush".
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- WQ/drivers/ata/libata-core.c~4_ata 2007-02-18 22:56:47.0 +0300
+++ WQ/drivers/ata/libata-core.c2007-02-19 02:02:06.0 +0300
@@ -1071,8 +1071,6 @@ void ata_port_flush_task(struct ata_port
spin_unlock_irqrestore(ap->lock, flags);
DPRINTK("flush #1\n");
- cancel_work_sync(>port_task.work); /* akpm: seems unneeded */
-
/*
* At this point, if a task is running, it's guaranteed to see
* the FLUSH flag; thus, it will never queue pio tasks again.
@@ -1082,8 +1080,8 @@ void ata_port_flush_task(struct ata_port
if (ata_msg_ctl(ap))
ata_port_printk(ap, KERN_DEBUG, "%s: flush #2\n",
__FUNCTION__);
- cancel_work_sync(>port_task.work);
}
+ cancel_work_sync(>port_task.work);
spin_lock_irqsave(ap->lock, flags);
ap->pflags &= ~ATA_PFLAG_FLUSH_PORT_TASK;
@@ -5889,7 +5887,6 @@ void ata_port_detach(struct ata_port *ap
/* Flush hotplug task. The sequence is similar to
* ata_port_flush_task().
*/
- cancel_work_sync(>hotplug_task.work); /* akpm: why? */
cancel_delayed_work(>hotplug_task);
cancel_work_sync(>hotplug_task.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: dirty balancing deadlock
On Sun, 18 Feb 2007 23:50:14 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > I was testing the new fuse shared writable mmap support, and finding > > > that bash-shared-mapping deadlocks (which isn't so strange ;). What > > > is more strange is that this is not an OOM situation at all, with > > > plenty of free and cached pages. > > > > > > A little more investigation shows that a similar deadlock happens > > > reliably with bash-shared-mapping on a loopback mount, even if only > > > half the total memory is used. > > > > > > The cause is slightly different in the two cases: > > > > > > - loopback mount: allocation by the underlying filesystem is stalled > > > on throttle_vm_writeout() > > > > > > - fuse-loop: page dirtying on the underlying filesystem is stalled on > > > balance_dirty_pages() > > > > > > In both cases the underlying fs is totally innocent, with no > > > dirty/writback pages, yet it's waiting for the global dirty+writeback > > > to go below the threshold, which obviously won't, until the > > > allocation/dirtying succeeds. > > > > > > I'm not quite sure what the solution is, and asking for thoughts. > > > > But these things don't just throttle. They also perform large amounts > > of writeback, which causes the dirty levels to subside. > > > > >From your description it appears that this writeback isn't happening, or > > isn't working. How come? > > - filesystems A and B > - write to A will end up as write to B > - dirty pages in A manage to go over dirty_threshold > - page writeback is started from A > - this triggers writeback for a couple of pages in B > - writeback finishes normally, but dirty+writeback pages are still >over threshold > - balance_dirty_pages in B gets stuck, nothing ever moves after this > > At least this is my theory for what happens. > Is B a real filesystem? If so, writes to B will decrease the dirty memory threshold. The writeout code _should_ just sit there transferring dirtyiness from A to B and cleaning pages via B, looping around, alternating between both. What does sysrq-t say? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> Andrew Morton wrote: > > On Sun, 18 Feb 2007 19:28:18 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > >> I was testing the new fuse shared writable mmap support, and finding > >> that bash-shared-mapping deadlocks (which isn't so strange ;). What > >> is more strange is that this is not an OOM situation at all, with > >> plenty of free and cached pages. > >> > >> A little more investigation shows that a similar deadlock happens > >> reliably with bash-shared-mapping on a loopback mount, even if only > >> half the total memory is used. > >> > >> The cause is slightly different in the two cases: > >> > >> - loopback mount: allocation by the underlying filesystem is stalled > >> on throttle_vm_writeout() > >> > >> - fuse-loop: page dirtying on the underlying filesystem is stalled on > >> balance_dirty_pages() > >> > >> In both cases the underlying fs is totally innocent, with no > >> dirty/writback pages, yet it's waiting for the global dirty+writeback > >> to go below the threshold, which obviously won't, until the > >> allocation/dirtying succeeds. > >> > >> I'm not quite sure what the solution is, and asking for thoughts. > > > > But these things don't just throttle. They also perform large amounts > > of writeback, which causes the dirty levels to subside. > > > >>From your description it appears that this writeback isn't happening, or > > isn't working. How come? > > Is the fuse daemon trying to do writeback to itself, perhaps? > > That is, trying to write out data to the FUSE filesystem, for which > it is also the server. No. It's trying to write out data to a different filesystem. Trying to write out data to itself very obviously deadlocks, but that doesn't affect anything beside the stupid filesystem itself, and there are mechanisms for aborting such a situation (forced umount, abort through fuse-control filesystem). Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> > I was testing the new fuse shared writable mmap support, and finding > > that bash-shared-mapping deadlocks (which isn't so strange ;). What > > is more strange is that this is not an OOM situation at all, with > > plenty of free and cached pages. > > > > A little more investigation shows that a similar deadlock happens > > reliably with bash-shared-mapping on a loopback mount, even if only > > half the total memory is used. > > > > The cause is slightly different in the two cases: > > > > - loopback mount: allocation by the underlying filesystem is stalled > > on throttle_vm_writeout() > > > > - fuse-loop: page dirtying on the underlying filesystem is stalled on > > balance_dirty_pages() > > > > In both cases the underlying fs is totally innocent, with no > > dirty/writback pages, yet it's waiting for the global dirty+writeback > > to go below the threshold, which obviously won't, until the > > allocation/dirtying succeeds. > > > > I'm not quite sure what the solution is, and asking for thoughts. > > But these things don't just throttle. They also perform large amounts > of writeback, which causes the dirty levels to subside. > > >From your description it appears that this writeback isn't happening, or > isn't working. How come? - filesystems A and B - write to A will end up as write to B - dirty pages in A manage to go over dirty_threshold - page writeback is started from A - this triggers writeback for a couple of pages in B - writeback finishes normally, but dirty+writeback pages are still over threshold - balance_dirty_pages in B gets stuck, nothing ever moves after this At least this is my theory for what happens. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm2 -- EIP is at __make_request+0xeb/0x2ee
On Sun, 18 Feb 2007 14:35:17 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > I guess I need to do a git-blockless -mm3 OK, this is looking like a pain - I'd have to drop or significantly redo thirty or more patches. Jens, please fix it asap. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
Hello all,
I got the DSDT from chuck and it seems there is nothing interesting - no
declaration of PCI_config for the registers. If someone wants to check it I can
send him the DSDT.
_TMP looks like this:
Store (\_SB.PCI0.LPC0.EC0.RTMP, Local0)
Store ("Current temp is: ", Debug)
Store (Local0, Debug)
Store (Local0, \_SB.CM25)
Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
This looks quite OK LPC0.EC0 is embedded controller IO RAM at 0x62. Nothing
special. I guess some SMM interrupt is reading the the PCI regs and sends it to
EC.
Chuck, please can you try to use your script which reads the temps from acpi
once a second and in other console run following command: (as root)
watch -d -n 1 lspci -xxx -s 18.3
This will list the pci registers every second and marks the diff. You should see
changes at 0xe6 which is your temperature. However if you see 0xe4 changing and
the k8temp driver is NOT loaded - it means something else is doing that.
If you spot the 0xe4 changes, please stop your script and check if it is still
changing.
Maybe you will not be able to see any changes at all - then the SMM is doing
reads only. Also you did not say how many cores, or places temps you see using
the k8temp driver. You have dual core with two possible places?
Thanks
Rudolf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 41/44 take 2] [UBI] gluebi unit header
On Sunday 18 February 2007 04:02:17 Josh Boyer wrote: > On Sun, Feb 18, 2007 at 03:15:23AM +0100, Arnd Bergmann wrote: > > On Sunday 18 February 2007 03:04, Josh Boyer wrote: > > > No, the MTD interface isn't flawed. gluebi is present to make things > > > like JFFS2 work on top of UBI volumes with very little adaptations. If > > > you go changing _every_ MTD user to now use either an MTD device or a > > > native UBI device, then the code for those users just gets bloated. > > > > Right, that was my point. If the MTD API in the kernel is not flawed, why > > do we need the 'native' UBI interface? Just merge gluebi into UBI and > > get rid of the extra abstraction. > > That suggestion came up several times. gluebi represents a compromise > between the two groups. IIRC, the issue was that representing UBI volumes > as MTD devices only makes sense in the dynamic volume case. Static UBI > volumes require special write/update handling and so there was a need for > a native interface anyway. Which brings be back to my original point ;-) I'm sure this has been discussed before, but I'd still like to understand what is so special with 'static UBI volumes' that they can't be used with a slightly extended MTD interface. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm2 -- EIP is at __make_request+0xeb/0x2ee
On Sun, 18 Feb 2007 13:47:44 -0800 "Miles Lane" <[EMAIL PROTECTED]> wrote: > It looks like there are some slight differences between the stack traces I > have and the ones that have already been posted. > I hope this helps, > Miles > > psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, throwing > 1 bytes away. > BUG: unable to handle kernel paging request at virtual address 6b6b6b6f > printing eip: > c01f238c > *pde = > Oops: [#1] > PREEMPT SMP > last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > Modules linked in: ieee80211_crypt_wep binfmt_misc rfcomm l2cap bluetooth > ipv6 capability commoncap apm i915 drm acpi_cpufreq cpufreq_powersave > cpufreq_performance cpufreq_conservative video dock container button battery > ac nls_ascii nls_cp437 vfat fat nls_base fuse sbp2 parport_pc lp parport > pcmcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss > snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi > snd_seq_midi_event snd_seq snd_timer snd_seq_device sdhci mmc_core tifm_7xx1 > tifm_core yenta_socket rsrc_nonstatic pcmcia_core snd soundcore ipw2200 > ieee80211 ieee80211_crypt firmware_class rtc snd_page_alloc iTCO_wdt > iTCO_vendor_support shpchp pci_hotplug sg sr_mod cdrom sd_mod ohci1394 > ieee1394 8139too mii ehci_hcd uhci_hcd usbcore thermal processor fan unix > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00210297 (2.6.20-mm2 #13) > EIP is at __make_request+0xeb/0x2ee Looks fairly similar. I guess I need to do a git-blockless -mm3 :( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] net/core: change hlist_for_each/hlist_entry to hlist_for_each_entry
change occurrence of hlist_for_each/hlist_entry to hlist_for_each_entry as it
combines the previous two macros
Signed-off-by: Thomas Hisch <[EMAIL PROTECTED]>
---
net/core/dev.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index cf71614..83c2f43 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -475,13 +475,11 @@ __setup("netdev=", netdev_boot_setup);
struct net_device *__dev_get_by_name(const char *name)
{
struct hlist_node *p;
+ struct net_device *dev;
- hlist_for_each(p, dev_name_hash(name)) {
- struct net_device *dev
- = hlist_entry(p, struct net_device, name_hlist);
+ hlist_for_each_entry(dev, p, dev_name_hash(name), name_hlist)
if (!strncmp(dev->name, name, IFNAMSIZ))
return dev;
- }
return NULL;
}
@@ -522,13 +520,11 @@ struct net_device *dev_get_by_name(const char *name)
struct net_device *__dev_get_by_index(int ifindex)
{
struct hlist_node *p;
+ struct net_device *dev;
- hlist_for_each(p, dev_index_hash(ifindex)) {
- struct net_device *dev
- = hlist_entry(p, struct net_device, index_hlist);
+ hlist_for_each_entry(dev, p, dev_index_hash(ifindex), index_hlist)
if (dev->ifindex == ifindex)
return dev;
- }
return NULL;
}
@@ -2878,6 +2874,7 @@ int register_netdevice(struct net_device *dev)
{
struct hlist_head *head;
struct hlist_node *p;
+ struct net_device *d;
int ret;
BUG_ON(dev_boot_phase);
@@ -2918,9 +2915,7 @@ int register_netdevice(struct net_device *dev)
/* Check for existence of name */
head = dev_name_hash(dev->name);
- hlist_for_each(p, head) {
- struct net_device *d
- = hlist_entry(p, struct net_device, name_hlist);
+ hlist_for_each_entry(d, p, head, name_hlist) {
if (!strncmp(d->name, dev->name, IFNAMSIZ)) {
ret = -EEXIST;
goto out;
--
1.5.0-rc2.GIT
--
Thomas Hisch
[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/
[PATCH] fix refrigerator() vs thaw_process() race
refrigerator() can miss a wakeup, "wait event" loop needs a proper memory
ordering.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- WQ/kernel/power/process.c~WAKE 2007-02-18 22:56:49.0 +0300
+++ WQ/kernel/power/process.c 2007-02-19 01:04:26.0 +0300
@@ -46,8 +46,10 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(>sighand->siglock);
- while (frozen(current)) {
- current->state = TASK_UNINTERRUPTIBLE;
+ for (;;) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ if (!frozen(current))
+ break;
schedule();
}
pr_debug("%s left refrigerator\n", current->comm);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot
Turned on lock testing/proving/deadlock detection. Not chasing any
particular
problem, but looking for things "oddities".
Turned on options (under kernel hacking):
Locking API boot-time self-tests
RT Mutex debugging, deadlock detection
Lock debugging: prove locking correctness
Multiple reboots show it to be a constant.
I had tried the new "Asynchronous SCSI scanning" -- thought that might
have been
related, but turning it off makes no difference.
I'm guessing this "error" has been present before this, but the lock
proving algorithms are bringing it to light? So I don't know how serious
this is (if it is anything), but at the least, it doesn't look too clean...
Maybe that
SCSI device sda: write cache: enabled, read cache: enabled, supports DPO
and FUA
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 0:0:0:0: Attached scsi disk sda
UDF-fs: No VRS found
XFS mounting filesystem sda3
Ending clean XFS mount for filesystem: sda3
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 316k freed
=
[ INFO: possible recursive locking detected ]
2.6.20 #3
-
rm/682 is trying to acquire lock:
(&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0
but task is already holding lock:
(&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0
other info that might help us debug this:
3 locks held by rm/682:
#0: (>i_mutex/1){--..}, at: [] do_unlinkat+0x96/0x170
#1: (>i_mutex){--..}, at: [] vfs_unlink+0x5a/0xd0
#2: (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0
stack backtrace:
[] __lock_acquire+0xaf1/0xdf0
[] lock_acquire+0x57/0x70
[] xfs_ilock+0x7d/0xb0
[] down_write+0x2f/0x50
[] xfs_ilock+0x7d/0xb0
[] xfs_ilock+0x7d/0xb0
[] xfs_lock_dir_and_entry+0xfd/0x100
[] xfs_remove+0x198/0x4e0
[] xfs_access+0x26/0x50
[] xfs_access+0x26/0x50
[] vfs_unlink+0x5a/0xd0
[] xfs_vn_unlink+0x23/0x60
[] __mutex_lock_slowpath+0x152/0x2a0
[] mark_held_locks+0x6b/0x90
[] __mutex_lock_slowpath+0x152/0x2a0
[] __mutex_lock_slowpath+0x152/0x2a0
[] trace_hardirqs_on+0xc7/0x170
[] __mutex_lock_slowpath+0x145/0x2a0
[] vfs_unlink+0x5a/0xd0
[] permission+0x137/0x140
[] vfs_unlink+0x90/0xd0
[] do_unlinkat+0xd3/0x170
[] do_page_fault+0x327/0x630
[] sysenter_past_esp+0x5f/0x99
===
XFS mounting filesystem sda1
Ending clean XFS mount for filesystem: sda1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: freezer problems
On 02/18, Rafael J. Wysocki wrote: > > Appended is a patch that does something along these lines. The necessary > thread_info flags are defined for i386 and x86_64, for now. I'll try to look at this patch when I am not so sleepy ... just one small nit right now, > --- linux-2.6.20-mm2.orig/include/asm-i386/thread_info.h 2007-02-18 > 19:49:34.0 +0100 > +++ linux-2.6.20-mm2/include/asm-i386/thread_info.h 2007-02-18 > 19:50:37.0 +0100 > @@ -135,6 +135,7 @@ static inline struct thread_info *curren > #define TIF_IO_BITMAP18 /* uses I/O bitmap */ > #define TIF_FREEZE 19 /* is freezing for suspend */ > #define TIF_FORCED_TF20 /* true if TF in eflags > artificially */ > +#define TIF_FREEZER_SKIP 21 /* task freezer should not count us */ Do we need to put this flag into thread_info? It is always modified by "current", so it could live in task_struct->flags instead. Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Don't probe for DDC on VBE1.2
On Saturday 17 February 2007 09:35, Zwane Mwaikambo wrote: > On Fri, 16 Feb 2007, Andrew Morton wrote: > > > On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo <[EMAIL > > PROTECTED]> wrote: > > > > > On Thu, 15 Feb 2007, Andrew Morton wrote: > > > > > > > It's not an X problem - the screen is black immediately upon loading the > > > > kernel. > > > > > > > > But I guess you knew that and you're just after display info: > > > > http://userweb.kernel.org/~akpm/Xorg.0.log.txt > > > > > > Thanks, the X log told me your VBE version. I tried to reproduce it on my > > > thinkpad which seems to have a very similar video setup to no avail, > > > Could > > > you test the following on the VAIO? If this isn't the case, i suspect i'm > > > corrupting your modelist. > > > > It's still all black. > > Ok it looks like i was corrupting the modelist. The following should take > care of your VAIO, but i haven't tested the failure case as Tobias is away > this weekend. I merged this version of the patch now. Still needs some x86-64 testing I guess (any volunteers?), although I don't expect much trouble because the early boot code is very similar. -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] drivers/media/video/cpia_pp.c: don't use _WORK_NAR
pp_cam_entry->cb_task need not to be _NOAUTOREL ... because in fact it is
never used ???
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- WQ/drivers/media/video/cpia_pp.c~3_cpia_pp 2006-12-17 19:06:40.0
+0300
+++ WQ/drivers/media/video/cpia_pp.c2007-02-19 00:27:41.0 +0300
@@ -141,7 +141,6 @@ static void cpia_pp_run_callback(struct
cam = container_of(work, struct pp_cam_entry, cb_task);
cb_func = cam->cb_func;
cb_data = cam->cb_data;
- work_release(work);
cb_func(cb_data);
}
@@ -682,7 +681,7 @@ static int cpia_pp_registerCallback(void
if(cam->port->irq != PARPORT_IRQ_NONE) {
cam->cb_func = cb;
cam->cb_data = cbdata;
- INIT_WORK_NAR(>cb_task, cpia_pp_run_callback);
+ INIT_WORK(>cb_task, cpia_pp_run_callback);
} else {
retval = -1;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] cpufreq_ondemand.c: don't use _WORK_NAR
Looks like dbs_timer() is very careful wrt per_cpu(cpu_dbs_info), and it doesn't need the help of WORK_STRUCT_NOAUTOREL. Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> --- WQ/drivers/cpufreq/cpufreq_ondemand.c~2_cpufreq 2007-02-18 22:56:47.0 +0300 +++ WQ/drivers/cpufreq/cpufreq_ondemand.c 2007-02-19 00:07:46.0 +0300 @@ -432,9 +432,6 @@ static void do_dbs_timer(struct work_str /* We want all CPUs to do sampling nearly on same jiffy */ int delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate); - /* Permit rescheduling of this work item */ - work_release(work); - delay -= jiffies % delay; if (lock_policy_rwsem_write(cpu) < 0) @@ -473,7 +470,7 @@ static inline void dbs_timer_init(struct dbs_info->enable = 1; ondemand_powersave_bias_init(); dbs_info->sample_type = DBS_NORMAL_SAMPLE; - INIT_DELAYED_WORK_NAR(_info->work, do_dbs_timer); + INIT_DELAYED_WORK(_info->work, do_dbs_timer); queue_delayed_work_on(dbs_info->cpu, kondemand_wq, _info->work, delay); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/3] net/bridge/br_if.c: don't use _WORK_NAR
Afaics, noautorel work_struct buys nothing for "struct net_bridge_port". If del_nbp()->cancel_delayed_work(>carrier_check) fails, port_carrier_check may be called later anyway. So the reading of *work in port_carrier_check() is equally unsafe with or without this patch. Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> --- WQ/net/bridge/br_if.c~1_bridge 2007-02-18 22:56:49.0 +0300 +++ WQ/net/bridge/br_if.c 2007-02-18 23:06:15.0 +0300 @@ -85,7 +85,6 @@ static void port_carrier_check(struct wo dev = container_of(work, struct net_bridge_port, carrier_check.work)->dev; - work_release(work); rtnl_lock(); p = dev->br_port; @@ -282,7 +281,7 @@ static struct net_bridge_port *new_nbp(s p->port_no = index; br_init_port(p); p->state = BR_STATE_DISABLED; - INIT_DELAYED_WORK_NAR(>carrier_check, port_carrier_check); + INIT_DELAYED_WORK(>carrier_check, port_carrier_check); br_stp_port_timer_init(p); kobject_init(>kobj); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 0/3] don't use _WORK_NAR
These patches change the code which I absolutely don't understand. Compile tested. Please review. Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] x86: mtrr range check correction
Jan Beulich wrote:
> Whether a region is below 1Mb is determined by its start rather than
> its end.
>
> This hunk got erroneously dropped from a previous patch.
>
> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
>
> --- linux-2.6.20/arch/i386/kernel/cpu/mtrr/generic.c 2007-02-04
> 19:44:54.0 +0100
> +++ 2.6.20-x86-mtrr-range-check/arch/i386/kernel/cpu/mtrr/generic.c
> 2007-02-09 10:17:26.0 +0100
> @@ -428,7 +428,7 @@ int generic_validate_add_page(unsigned l
> }
> }
>
> - if (base + size < 0x100) {
> + if (base < 0x100) {
> printk(KERN_WARNING "mtrr: cannot set region below 1 MiB
> (0x%lx000,0x%lx000)\n",
> base, size);
> return -EINVAL;
>
What about wraparound?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
Andrew Morton wrote: On Sun, 18 Feb 2007 19:28:18 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: I was testing the new fuse shared writable mmap support, and finding that bash-shared-mapping deadlocks (which isn't so strange ;). What is more strange is that this is not an OOM situation at all, with plenty of free and cached pages. A little more investigation shows that a similar deadlock happens reliably with bash-shared-mapping on a loopback mount, even if only half the total memory is used. The cause is slightly different in the two cases: - loopback mount: allocation by the underlying filesystem is stalled on throttle_vm_writeout() - fuse-loop: page dirtying on the underlying filesystem is stalled on balance_dirty_pages() In both cases the underlying fs is totally innocent, with no dirty/writback pages, yet it's waiting for the global dirty+writeback to go below the threshold, which obviously won't, until the allocation/dirtying succeeds. I'm not quite sure what the solution is, and asking for thoughts. But these things don't just throttle. They also perform large amounts of writeback, which causes the dirty levels to subside. From your description it appears that this writeback isn't happening, or isn't working. How come? Is the fuse daemon trying to do writeback to itself, perhaps? That is, trying to write out data to the FUSE filesystem, for which it is also the server. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] killing the NR_IRQS arrays.
On Fri, 2007-02-16 at 13:41 +0100, Ingo Molnar wrote: > * Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > > So I propose we remove all assumptions from the code that we actually > > have an array of irqs. That will allow for irq_desc to be dynamically > > allocated instead of statically allocated saving memory and reducing > > kernel complexity. > > hm. I'd suggest to do this without changing request_irq() - and then we > could avoid the 'massive, every driver affected' change, right? if request_irq() changes we might as well make a variant that takes a PCI device struct rather than a number, for the 99% of PCI drivers that use that.. (and then msi and other stuff becomes simpler :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Fri, 16 Feb 2007, Fortier,Vincent [Montreal] wrote: > I m using a Logitech MX 5000 keyboard with an included MX 1000 mouse, > both bluetooth using the same USB reciever. > When the USB reciever is already plugged-in at boot-time and the > Bluetooth service fires-up I get this message: > === > BUG: warning: (value > m) at > drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) > [] dump_trace+0x69/0x1b6 > [] show_trace_log_lvl+0x18/0x2c > [] show_trace+0xf/0x11 > [] dump_stack+0x15/0x17 > [] hid_output_report+0x23c/0x2e7 > [] hid_submit_ctrl+0x4c/0x1d9 > [] hid_submit_report+0x134/0x15f > [] hiddev_ioctl+0x327/0x88a > [] do_ioctl+0x4c/0x62 > [] vfs_ioctl+0x24a/0x25c > [] sys_ioctl+0x4c/0x66 > [] syscall_call+0x7/0xb > [<005b5402>] 0x5b5402 > === (added Marcel to CC) This means that something (I guess that it's hid2hci command?) is trying to pass through hiddev a value in a field that is greater than a given bitmask (and is not going to fit into the bitfield). Vincent, does the problem go away when you don't use bluetooth (both keyboard and mouse is switched to HID mode, if they support it)? Marcel, do you have any idea how this could happen? Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/18/07, Theodore Tso <[EMAIL PROTECTED]> wrote: Actually, the FSF and many of its representatives, has claimed, on many occassions, that the GPL infects across dynamic linking. That is, if you write your own code that calls readline which links via a dynamically linked shared library, and perhaps even across dlopen(), they claim that the GPL applies to the code which you write. Given that the only way this could happen is via copyright law, they are basically saying that if you use the readline interface, you have created a derived work and they therefore 0wn your source code. Is that so? Whether or not this would be laughed out of court or not will very much depend on the local legal precedents (and Trent Waddington has quoted some very interesting legal cases based on US court decisions, Wow? I did? Really? I must have been sleep typing. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 05/11] syslets: core code
On 2/18/07, Davide Libenzi wrote: Clets would execute in userspace, like signal handlers, or like "event handlers" in cooperative multitasking environments without the Unix baggage but under the special schedule() handler. or, better yet, as the next tasklet in the chain after the softirq dispatcher, since I/Os almost always unblock as a result of something that happens in an ISR or softirq In that way chains happens by the mean of natural C code, and access to userspace variables happen by the mean of natural C code too (not with special syscalls to manipulate userspace memory). yep. That way you can exploit this nice hardware block called an MMU. I'm not a big fan of chains of syscalls for the reasons I already explained, to a kernel programmer, all userspace programs are chains of syscalls. :-) but at least clets (or whatever name) has a way lower cost for the programmer (easier to code than atom chains), except you still have the 80% of the code that is half-assed exception handling using overloaded semantics on function return values and a thread-local errno, which is totally unsafe with fibrils, syslets, clets, and giblets, since none of them promise to run continuations in the same thread context as the submission. Of course you aren't going to use errno as such, but that means that async-ifying code isn't s/syscall/aio_syscall/, it's a complete rewrite. If you're going to design a new AIO interface, please model it after the only standard that has ever made deeply pipelined, massively parallel execution programmer-friendly -- IEEE 754. and for the kernel (no need of all that atom handling stuff, you still need this, but it has to be centered on a data structure that makes request throttling, dynamic reprioritization, and bulk cancellation practical no need of limited cond/jump interpreters in the kernel, you still need this, for efficient handling of speculative execution, pipeline stalls, and exception propagation, but it's invisible to the interface and you don't have to invent it up front and no need of nightmare compat code). compat code, yes. nighmare, no. Just like kernel FP emulation on any processor other than an x86. Unimplemented instruction traps. x86 is so utterly the wrong architecture on which to prototype this it isn't even funny. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
On Sun, 18 Feb 2007 19:28:18 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > I was testing the new fuse shared writable mmap support, and finding > that bash-shared-mapping deadlocks (which isn't so strange ;). What > is more strange is that this is not an OOM situation at all, with > plenty of free and cached pages. > > A little more investigation shows that a similar deadlock happens > reliably with bash-shared-mapping on a loopback mount, even if only > half the total memory is used. > > The cause is slightly different in the two cases: > > - loopback mount: allocation by the underlying filesystem is stalled > on throttle_vm_writeout() > > - fuse-loop: page dirtying on the underlying filesystem is stalled on > balance_dirty_pages() > > In both cases the underlying fs is totally innocent, with no > dirty/writback pages, yet it's waiting for the global dirty+writeback > to go below the threshold, which obviously won't, until the > allocation/dirtying succeeds. > > I'm not quite sure what the solution is, and asking for thoughts. But these things don't just throttle. They also perform large amounts of writeback, which causes the dirty levels to subside. >From your description it appears that this writeback isn't happening, or isn't working. How come? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG/WARN] Error initialising drivers in PCI
On Sunday 18 February 2007 20:53, Ian McDonald wrote:
> I'm getting this in my logs when starting up after going from a
> 2.6.20rc5 kernel (which didn't do this) to Linus' latest tree as of 36
> hours ago:
>
> Feb 18 14:52:32 localhost kernel: [ 16.392136] Uniform
> Multi-Platform E-IDE driver Revision: 7.00alpha2
> Feb 18 14:52:32 localhost kernel: [ 16.392210] ide: Assuming 33MHz
> system bus speed for PIO modes; override with idebus=xx
> Feb 18 14:52:32 localhost kernel: [ 16.395039] Probing IDE interface ide0...
> Feb 18 14:52:32 localhost kernel: [ 16.780057] hda: ST315310A, ATA DISK
> drive
> Feb 18 14:52:32 localhost kernel: [ 17.391365] Probing IDE interface ide1...
> Feb 18 14:52:32 localhost kernel: [ 18.184752] hdc: LTN485, ATAPI
> CD/DVD-ROM drive
> Feb 18 14:52:32 localhost kernel: [ 18.490570] ide0 at
> 0x1f0-0x1f7,0x3f6 on irq 14
> Feb 18 14:52:32 localhost kernel: [ 18.490978] ide1 at
> 0x170-0x177,0x376 on irq 15
> Feb 18 14:52:32 localhost kernel: [ 18.493214] hda: max request size: 128KiB
> Feb 18 14:52:32 localhost kernel: [ 18.493735] hda: 29336832 sectors
> (15020 MB) w/2048KiB Cache, CHS=29104/16/63
> Feb 18 14:52:32 localhost kernel: [ 18.493899] hda: cache flushes
> not supported
> Feb 18 14:52:32 localhost kernel: [ 18.494530] hda: hda1 hda2 < hda5 >
> Feb 18 14:52:32 localhost kernel: [ 18.536466] ata_piix
> :00:1f.1: version 2.00ac7
> Feb 18 14:52:32 localhost kernel: [ 18.536579] ata: 0x1F0 IDE port busy
> Feb 18 14:52:32 localhost kernel: [ 18.536583] ata: conflict with ide0
> Feb 18 14:52:32 localhost kernel: [ 18.536719] BUG: at
> drivers/pci/pci.c:840 pcim_pin_device()
> Feb 18 14:52:32 localhost kernel: [ 18.536786] []
> show_trace_log_lvl+0x1a/0x2f
> Feb 18 14:52:32 localhost kernel: [ 18.536897] []
> show_trace+0x12/0x14
> Feb 18 14:52:32 localhost kernel: [ 18.536991] []
> dump_stack+0x16/0x18
> Feb 18 14:52:32 localhost kernel: [ 18.537085] []
> pcim_pin_device+0x40/0x4d
> Feb 18 14:52:32 localhost kernel: [ 18.537201] []
> ata_pci_init_one+0x1ac/0x4bb
> Feb 18 14:52:32 localhost kernel: [ 18.537330] []
> piix_init_one+0x418/0x435
> Feb 18 14:52:32 localhost kernel: [ 18.537431] []
> pci_device_probe+0x39/0x5b
> Feb 18 14:52:32 localhost kernel: [ 18.537528] []
> really_probe+0xbd/0x145
> Feb 18 14:52:32 localhost kernel: [ 18.537638] []
> driver_probe_device+0x95/0xa1
> Feb 18 14:52:32 localhost kernel: [ 18.537734] []
> __driver_attach+0x6a/0xa1
> Feb 18 14:52:32 localhost kernel: [ 18.537829] []
> bus_for_each_dev+0x36/0x5b
> Feb 18 14:52:32 localhost kernel: [ 18.537925] []
> driver_attach+0x19/0x1b
> Feb 18 14:52:32 localhost kernel: [ 18.538019] []
> bus_add_driver+0x6a/0x170
> Feb 18 14:52:32 localhost kernel: [ 18.538114] []
> driver_register+0x79/0x7e
> Feb 18 14:52:32 localhost kernel: [ 18.538209] []
> __pci_register_driver+0x7b/0xa8
> Feb 18 14:52:32 localhost kernel: [ 18.538381] []
> piix_init+0x14/0x27
> Feb 18 14:52:32 localhost kernel: [ 18.538496] [] init+0x95/0x17a
> Feb 18 14:52:32 localhost kernel: [ 18.538597] []
> kernel_thread_helper+0x7/0x10
> Feb 18 14:52:32 localhost kernel: [ 18.538693] ===
> Feb 18 14:52:32 localhost kernel: [ 18.538752] ata: 0x170 IDE port busy
> Feb 18 14:52:32 localhost kernel: [ 18.538756] ata: conflict with ide1
> Feb 18 14:52:32 localhost kernel: [ 18.538905] ata_piix: probe of
> :00:1f.1 failed with error -16
Tejun, it seems that resources hacks and devres changes don't mix well.
> Kernel is standard tree with no modifications.
>
> Relevant code which triggers this from devices/pci/pci.c is:
> void pcim_pin_device(struct pci_dev *pdev)
> {
> struct pci_devres *dr;
>
> dr = find_pci_dr(pdev);
> WARN_ON(!dr || !dr->disable);
> if (dr)
> dr->disable = 0;
> }
>
> and it is the WARN_ON that is the line.
>
> .config of kernel is attached.
> output of lspci -vv is attached.
Ian, you have an PATA controller so there is no need to use ata_piix.
Just disabling ata_piix should workaround the issue.
> Can you please cc me on any discussions/requests as not subscribed to lkml.
>
> NB Machine continues with boot and can run after this. Machine is a
> little unstable though but could also be Broadcom 4306 issues as not
> sure these drivers are yet stable on my machine...
>
> Ian
> --
> Web: http://wand.net.nz/~iam4
> Blog: http://iansblog.jandi.co.nz
> WAND Network Research Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser > where only the Device Number can be changed. With jumpers? > So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no > communication with the DVB-T card (the frontend), so there is no > /dev/dvb/* entry. This points to an IRQ problem. > > How can I find out the actual IRQ that the card is using? I would remove the PCI cards and then the riser card and check INT routing with a multimeter. Perhaps a task for someone used to stuff like that. > I set the BIOS for 'PnP OS installed'. Should I change that? Most drivers already enable devices so it probably doesn't matter. I would check it, though. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes: > My understanding (which is better of verified against the specs) is: > > PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So > slot 0, 4, 8, etc see INTA->realINTA, INTB->realINTB. INTC->realINTC, > INTD->realINTD > slot 1, 5, 9, etc see INTA->realINTB, INTB->realINTC. INTC->realINTD, > INTD->realINTA > slot 2, 6, 10, etc see INTA->realINTC, INTB->realINTD. INTC->realINTA, > INTD->realINTB > slot 3, 7, 11, etc see INTA->realINTD, INTB->realINTA. INTC->realINTB, > INTD->realINTC This is common and suggested practice but the PCI specs don't require it. There is no rule - you can, for example, have all INT lines connected to a single CPU IRQ input. > On a PC, the BIOS is supposed to assign interrupts to devices based on > those rules, since that is how the hardware must be done according to > the PCI specifications. On other platforms the firmware may or may not > handle it. Anyway, something has to know how the IRQs are routed. BIOS, other firmware, Linux. > So as long as the riser board is wired according to the PCI bridge > rules, Actually it has to be wired consistently with the BIOS (which is probably consistent with chipset manufacturer's instructions). > Of course if the > riser card is NOT a proper pci bridge, but rather some weird device, > well then it probably isn't even PCI complient and who knows how it > shold be handled. Usually they are just bus splitters, they route IRQs and IDSELs (and maybe JTAG) as required by the BIOS, all others pins are connected 1:1. I.e., they are completely transparent, generally comply to PCI specs and are dedicated to a specific motherboard(s). > Interrupts for PCI are assigned based on the 4 shared interrupts line on > PCI, not really per device. A PCI device may use up to 4 interrupts if > it wants to, and is supposed to always use interrupt A (as seen from > it's slot) as the first interrupt. Actually I think (would have to check the specs for sure) every subdevice (function) may use just one interrupt line. This rotating INTx scheme is common because it's cheap. There are systems which support more than 4 shared INTs per bus, for example you can have different sets of 4 INTx lines for every PCI slot, even if all slots are on the same PCI bus. > The rotating assignment of the 4 > interrupts to the slots are supposed to help balance the distribution of > the interrupts between devices in the system, so that although they are > shared interrupts, as few devices as possible get assigned to each > interrupt. Correct. This scheme assumes at most 4 single-function devices on the bus, otherwise INTs are shared. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 05/11] syslets: core code
On Sun, 18 Feb 2007, Pavel Machek wrote:
> > > The upcall will setup a frame, execute the clet (where jump/conditions
> > > and
> > > userspace variable changes happen in machine code - gcc is pretty good in
> > > taking care of that for us) on its return, come back through a
> > > sys_async_return, and go back to userspace.
> >
> > So, for example, this is the setup code for the current API (and that's a
> > really simple one - immagine going wacko with loops and userspace varaible
> > changes):
> >
> >
> > static struct req *alloc_req(void)
> > {
> > /*
> > * Constants can be picked up by syslets via static variables:
> > */
> > static long O_RDONLY_var = O_RDONLY;
> > static long FILE_BUF_SIZE_var = FILE_BUF_SIZE;
> >
> > struct req *req;
> >
> > if (freelist) {
> > req = freelist;
> > freelist = freelist->next_free;
> > req->next_free = NULL;
> > return req;
> > }
> >
> > req = calloc(1, sizeof(struct req));
> >
> > /*
> > * This is the first atom in the syslet, it opens the file:
> > *
> > * req->fd = open(req->filename, O_RDONLY);
> > *
> > * It is linked to the next read() atom.
> > */
> > req->filename_p = req->filename;
> > init_atom(req, >open_file, __NR_sys_open,
> > >filename_p, _RDONLY_var, NULL, NULL, NULL, NULL,
> > >fd, SYSLET_STOP_ON_NEGATIVE, >read_file);
> >
> > /*
> > * This second read() atom is linked back to itself, it skips to
> > * the next one on stop:
> > */
> > req->file_buf_ptr = req->file_buf;
> > init_atom(req, >read_file, __NR_sys_read,
> > >fd, >file_buf_ptr, _BUF_SIZE_var,
> > NULL, NULL, NULL, NULL,
> > SYSLET_STOP_ON_NON_POSITIVE | SYSLET_SKIP_TO_NEXT_ON_STOP,
> > >read_file);
> >
> > /*
> > * This close() atom has NULL as next, this finishes the syslet:
> > */
> > init_atom(req, >close_file, __NR_sys_close,
> > >fd, NULL, NULL, NULL, NULL, NULL, NULL, 0, NULL);
> >
> > return req;
> > }
> >
> >
> > Here's how your clet would look like:
> >
> > static long main_sync_loop(ctx *c)
> > {
> > int fd;
> > char file_buf[FILE_BUF_SIZE+1];
> >
> > if ((fd = open(c->filename, O_RDONLY)) == -1)
> > return -1;
> > while (read(fd, file_buf, FILE_BUF_SIZE) > 0)
> > ;
> > close(fd);
> > return 0;
> > }
> >
> >
> > Kinda easier to code isn't it? And the cost of the upcall to schedule the
> > clet is widely amortized by the multple syscalls you're going to do inside
> > your clet.
>
> I do not get it. What if clet includes
>
> int *a = 0; *a = 1; /* enjoy your oops, stupid kernel? */
>
> I.e. how do you make sure kernel is protected from malicious clets?
Clets would execute in userspace, like signal handlers, but under the
special schedule() handler. In that way chains happens by the mean of
natural C code, and access to userspace variables happen by the mean of
natural C code too (not with special syscalls to manipulate userspace
memory). I'm not a big fan of chains of syscalls for the reasons I
already explained, but at least clets (or whatever name) has a way lower
cost for the programmer (easier to code than atom chains), and for the
kernel (no need of all that atom handling stuff, no need of limited
cond/jump interpreters in the kernel, and no need of nightmare compat
code).
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Time for a linux-kvm mailing list?
Avi Kivity wrote: Bill Davidsen wrote: There doesn't seem to be a great place for KVM user questions, this is it, and kvm-devel seems a poor place for user questions, while the chat room is real time and depends on the question and the answer being in the same place at the same time. kvm-devel is perfectly suitable for user queries. Just a thought on getting a dialogue going in the right place. You could have started by posting your idea on kvm-devel, where kvm developers and users would actually see it. Why would I post it to a list where it's off-topic by list name? And how would anyone know that the list name can be ignored when so many other lists with "devel" in the name tell people with user questions to go elsewhere? Right now only users who ignore list names would even look there. I was suggesting to improve user participation, since you don't think that's needed I'll stop trying to help. I guess since kvm needs more hardware you have fewer users and don't need user support list like xen. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] platform: reorder platform_device_del
In platform_device_del(), we currently delete the device resources
first, then we delete the device itself. This causes a (minor) bug to
occur when one unregisters a platform device before unregistering its
platform driver, and the driver is requesting (in .probe()) and
releasing (in .remove()) a resource of the device. The device
resources are already gone by the time the driver gets the chance to
release the resources it had been requesting, causing an error like:
Trying to free nonexistent resource <0295-0296>
If the platform driver is unregistered first, the problem doesn't
occur, as the driver will have the opportunity to release the
resources it had requested before the device resources themselves are
released. It's a bit odd that unregistering the driver first or the
device first doesn't lead to the same result.
So I believe that we should delete the device first in
platform_device_del(). I've searched the git history and found that it
used to be the case before 2.6.8, but was changed here:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=96ef7b3689936ee1e64b711511342026a8ce459c
> 2004/07/14 16:09:44-07:00 dtor_core
> [PATCH] Driver core: Fix OOPS in device_platform_unregister
>
> Driver core: platform_device_unregister should release resources first
> and only then call device_unregister, otherwise if there
> are no more references to the device it will be freed and
> the fucntion will try to access freed memory.
However we now have an explicit call to put_device() at the end of
platform_device_unregister() so I guess the original problem no longer
exists and it is safe to revert that change.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/base/platform.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.20.orig/drivers/base/platform.c 2007-02-04 19:44:54.0
+0100
+++ linux-2.6.20/drivers/base/platform.c2007-02-18 19:38:09.0
+0100
@@ -299,13 +299,13 @@ void platform_device_del(struct platform
int i;
if (pdev) {
+ device_del(>dev);
+
for (i = 0; i < pdev->num_resources; i++) {
struct resource *r = >resource[i];
if (r->flags & (IORESOURCE_MEM|IORESOURCE_IO))
release_resource(r);
}
-
- device_del(>dev);
}
}
EXPORT_SYMBOL_GPL(platform_device_del);
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nfs: init req_lock in nfs_alloc_inode
On Fri, Feb 16, 2007 at 05:24:42PM -0800, Andrew Morton wrote: > req_lock is initialsied in fs/nfs/inode.c:init_once(). Oh, it is indeed. Grmbl. > What kernel version were you using? I've reproduced this on a base 2.6.20 g5_defconfig + NFS root and serial console options on a G5 here. The steps I have used are: * Boot with NFS root, default mount options * mount /dev/sda3 /mnt ... that's all. I have not seen it happen without NFS root, even with quite active NFS activity. So it seems to be a factor. I'll continue debugging tomorrow. -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 05/11] syslets: core code
Hi!
> > The upcall will setup a frame, execute the clet (where jump/conditions and
> > userspace variable changes happen in machine code - gcc is pretty good in
> > taking care of that for us) on its return, come back through a
> > sys_async_return, and go back to userspace.
>
> So, for example, this is the setup code for the current API (and that's a
> really simple one - immagine going wacko with loops and userspace varaible
> changes):
>
>
> static struct req *alloc_req(void)
> {
> /*
> * Constants can be picked up by syslets via static variables:
> */
> static long O_RDONLY_var = O_RDONLY;
> static long FILE_BUF_SIZE_var = FILE_BUF_SIZE;
>
> struct req *req;
>
> if (freelist) {
> req = freelist;
> freelist = freelist->next_free;
> req->next_free = NULL;
> return req;
> }
>
> req = calloc(1, sizeof(struct req));
>
> /*
> * This is the first atom in the syslet, it opens the file:
> *
> * req->fd = open(req->filename, O_RDONLY);
> *
> * It is linked to the next read() atom.
> */
> req->filename_p = req->filename;
> init_atom(req, >open_file, __NR_sys_open,
> >filename_p, _RDONLY_var, NULL, NULL, NULL, NULL,
> >fd, SYSLET_STOP_ON_NEGATIVE, >read_file);
>
> /*
> * This second read() atom is linked back to itself, it skips to
> * the next one on stop:
> */
> req->file_buf_ptr = req->file_buf;
> init_atom(req, >read_file, __NR_sys_read,
> >fd, >file_buf_ptr, _BUF_SIZE_var,
> NULL, NULL, NULL, NULL,
> SYSLET_STOP_ON_NON_POSITIVE | SYSLET_SKIP_TO_NEXT_ON_STOP,
> >read_file);
>
> /*
> * This close() atom has NULL as next, this finishes the syslet:
> */
> init_atom(req, >close_file, __NR_sys_close,
> >fd, NULL, NULL, NULL, NULL, NULL, NULL, 0, NULL);
>
> return req;
> }
>
>
> Here's how your clet would look like:
>
> static long main_sync_loop(ctx *c)
> {
> int fd;
> char file_buf[FILE_BUF_SIZE+1];
>
> if ((fd = open(c->filename, O_RDONLY)) == -1)
> return -1;
> while (read(fd, file_buf, FILE_BUF_SIZE) > 0)
> ;
> close(fd);
> return 0;
> }
>
>
> Kinda easier to code isn't it? And the cost of the upcall to schedule the
> clet is widely amortized by the multple syscalls you're going to do inside
> your clet.
I do not get it. What if clet includes
int *a = 0; *a = 1; /* enjoy your oops, stupid kernel? */
I.e. how do you make sure kernel is protected from malicious clets?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] correct CONFIG_GIGASET_M101 Makefile entry
Hi! > Advanced Mathematics, lesson 1: > 101 != 105 > > ;-) > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > --- linux-2.6.20-mm1/drivers/isdn/gigaset/Makefile.old2007-02-15 > 17:38:23.0 +0100 > +++ linux-2.6.20-mm1/drivers/isdn/gigaset/Makefile2007-02-15 > 17:38:41.0 +0100 > @@ -5,4 +5,4 @@ > > obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o > obj-$(CONFIG_GIGASET_BASE) += bas_gigaset.o gigaset.o > -obj-$(CONFIG_GIGASET_M105) += ser_gigaset.o gigaset.o > +obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o gigaset.o Are you sure? M105 is both usb and serial? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Hi! > >Contrawise, if Embedded developers do contribute their > >device driver > >changes back to the kernel, they will be fine. ... > --- > > In fairness, though, some of the developers WILL bitch > about your not > using a recent kernel and not providing patches until > products ship, > despite that meeting the letter of the license. Some of > the notes in Well, of course developers will complain, they _always_ complain. But it is very different kind of complain... first is 'I think you are violating the law, you are evil' and second is 'Thank you for playing by the rules, but you know, your code is not mergeable right now'. > this thread do exactly that. And I HAVE seen real > developers say > something very close to "Your code is based on a kernel > too old to > have any value to us" even though they would also claim > abuse if the > code hadn't been made available at all. And I've seen Yep, and guess what, thats okay. Someone with more time than they do may decide to forward port the code and/or rewrite it for new kernel. I was doing exactly that with 2.4 sharp sl-5500 code. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
Hi! > >> (See, among other cases, Lexmark. v. Static > >> Controls.) A copyright is not a patent, you can only > >own something if there > >> are multiple equally good ways to do it and you claim > >*one* of them. > > > >Only in a world where "write a Linux module" is a > >"functional idea." I > >don't think that the legal world in the US is an > >example of such a > >world, though you clearly do. > --- > > "Interface the xyz device to the Linux kernel" is a > functional idea in > pretty much the same sense that the Lexmark case > involved. You > generally can't copyright functional interfaces; there > is a strong > prejudice towards allowing interoperability. You are welcome to write kernel modules without including *any* header files. That may be ok in parts of US based on precedent you cite. Somehow I do not think v j is doing, so he is violating our copyright. Seems simple to me... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e2b2rom_init_one(): Unable to register resource
On Sun, Feb 18, 2007 at 07:49:34PM +0200, Dan Aloni wrote: | On Sun, Feb 18, 2007 at 06:13:38PM +0100, Andi Kleen wrote: | > [adding mtd maintainer] | > | > On Sunday 18 February 2007 11:42, Cyrill Gorcunov wrote: | > > On Sat, Feb 17, 2007 at 11:29:19PM +0200, Dan Aloni wrote: | > > | Hello, | > > | | > > | I'm running the x86_64 arch of Linux 2.6.20 on a Supermicro X6DH8-XG2 | > > | board and I got this during boot: | > > | | > > | [248660.950695] device id = 2440 | > > | [248660.950699] device id = 2480 | > > | [248660.950703] device id = 24c0 | > > | [248660.950706] device id = 24d0 | > > | [248660.950709] matched device = 24d0 | > > | [248660.950712] matched device id 24d0 | > > | [248660.950716] pci_read_config_byte : 4 | > > | [248660.950723] esb2rom: esb2rom_init_one(): Unable to register resource | > > | 0xffc0-0x - kernel bug? | > > | [248660.950729] esb2rom: ioremap(ffc0, 10040) failed | > > | [248660.956859] retVal = -19 | > > | | > > | Looks like some kind of a 64-bit portability bug... | [...] | > | > Making window->phys u32 seems like a cleaner fix. | > (untested) | | With this fix it still looks somewhat broken: | | [889227.698252] device id = 2440 | [889227.698261] device id = 2480 | [889227.698264] device id = 24c0 | [889227.698268] device id = 24d0 | [889227.698271] matched device = 24d0 | [889227.698274] matched device id 24d0 | [889227.698280] pci_read_config_byte : 4 | [889227.698289] esb2rom: esb2rom_init_one(): Unable to register resource 0xffc0-0x - kernel bug? | [889227.700676] CFI: Found no esb2rom @ffc0 device at location zero | [889227.717995] JEDEC: Found no esb2rom @ffc0 device at location zero | [889227.720811] CFI: Found no esb2rom @ffc0 device at location zero | [889227.747009] JEDEC: Found no esb2rom @ffc0 device at location zero | [889227.748692] CFI: Found no esb2rom @ffc0 device at location zero | [889227.763736] JEDEC: Found no esb2rom @ffc0 device at location zero | [889227.765438] CFI: Found no esb2rom @ffc1 device at location zero | [889227.782755] JEDEC: Found no esb2rom @ffc1 device at location zero | [889227.785566] CFI: Found no esb2rom @ffc1 device at location zero | [889227.810647] JEDEC: Found no esb2rom @ffc1 device at location zero | [889227.812330] CFI: Found no esb2rom @ffc1 device at location zero | [889227.827378] JEDEC: Found no esb2rom @ffc1 device at location zero | [889227.829081] CFI: Found no esb2rom @ffc2 device at location zero | [889227.846390] JEDEC: Found no esb2rom @ffc2 device at location zero | [889227.849202] CFI: Found no esb2rom @ffc2 device at location zero | [889227.874279] JEDEC: Found no esb2rom @ffc2 device at location zero | [889227.875961] CFI: Found no esb2rom @ffc2 device at location zero | [889227.891005] JEDEC: Found no esb2rom @ffc2 device at location zero | [889227.892710] CFI: Found no esb2rom @ffc3 device at location zero | [889227.910022] JEDEC: Found no esb2rom @ffc3 device at location zero | [889227.912835] CFI: Found no esb2rom @ffc3 device at location zero | [889227.937915] JEDEC: Found no esb2rom @ffc3 device at location zero | [889227.939594] CFI: Found no esb2rom @ffc3 device at location zero | [889227.954636] JEDEC: Found no esb2rom @ffc3 device at location zero | [889227.956339] CFI: Found no esb2rom @ffc4 device at location zero | [889227.973647] JEDEC: Found no esb2rom @ffc4 device at location zero | [889227.976461] CFI: Found no esb2rom @ffc4 device at location zero | [889228.001560] JEDEC: Found no esb2rom @ffc4 device at location zero | [889228.003243] CFI: Found no esb2rom @ffc4 device at location zero | [889228.018296] JEDEC: Found no esb2rom @ffc4 device at location zero | [889228.02] CFI: Found no esb2rom @ffc5 device at location zero | [889228.037315] JEDEC: Found no esb2rom @ffc5 device at location zero | [889228.040129] CFI: Found no esb2rom @ffc5 device at location zero | [889228.065218] JEDEC: Found no esb2rom @ffc5 device at location zero | [889228.066899] CFI: Found no esb2rom @ffc5 device at location zero | [889228.081943] JEDEC: Found no esb2rom @ffc5 device at location zero | [889228.083640] CFI: Found no esb2rom @ffc6 device at location zero | [889228.100949] JEDEC: Found no esb2rom @ffc6 device at location zero | [889228.103760] CFI: Found no esb2rom @ffc6 device at location zero | [889228.128850] JEDEC: Found no esb2rom @ffc6 device at location zero | [889228.130529] CFI: Found no esb2rom @ffc6 device at location zero | [889228.145575] JEDEC: Found no esb2rom @ffc6 device at location zero | [889228.147275] CFI: Found no esb2rom @ffc7 device at location zero | [889228.164593] JEDEC: Found no esb2rom @ffc7 device at location zero | [889228.167398] CFI: Found no esb2rom @ffc7 device at location zero | [889228.192491] JEDEC: Found no esb2rom @ffc7
Re: 2.6.20-mm2: Oops in generic_make_request
On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote: > On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > Le 18.02.2007 06:51, Andrew Morton a écrit : > > >Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > >Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > Hello, I've got a fully reproducible Oops. I just have to boot to > > runlevel 2 and wait less than one minute. > > Maybe this oops is related too? Looks that way. > Can't yet tell if it's easily reproducible, this is on a JFS filesystem. > > BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 > printing eip: > c02206aa > *pde = > Oops: [#1] > PREEMPT > last sysfs file: /devices/pci:00/:00:00.0/class > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010297 (2.6.20-mm2-1 #1) > EIP is at __make_request+0x13a/0x390 > eax: ebx: ecx: 042b0dd8 edx: 00010485 > esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) > Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 >c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 >00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 > Call Trace: > [] show_trace_log_lvl+0x1a/0x30 > [] show_stack_log_lvl+0xa9/0xd0 > [] show_registers+0x206/0x350 > [] die+0x10e/0x210 > [] do_page_fault+0x2d2/0x600 > [] error_code+0x74/0x7c > [] generic_make_request+0x15a/0x200 > [] submit_bio+0x58/0xe0 > [] metapage_writepage+0x18f/0x1b0 > [] __writepage+0xb/0x30 > [] write_cache_pages+0x22f/0x300 > [] generic_writepages+0x23/0x30 > [] do_writepages+0x5c/0x60 > [] __filemap_fdatawrite_range+0x67/0x80 > [] filemap_flush+0x25/0x30 > [] lmLogSync+0x19d/0x230 > [] lmLog+0x5e/0x190 > [] txCommit+0x8c0/0x1010 > [] jfs_create+0x324/0x370 > [] vfs_create+0xaf/0x100 > [] open_namei+0x58c/0x640 > [] do_filp_open+0x2c/0x50 > [] do_sys_open+0x47/0xe0 > [] sys_open+0x1c/0x20 > [] syscall_call+0x7/0xb Michal Piotrowski is hitting it too, and has bisected it down to git-block.patch. I have bisected it down to this patches revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch git-block.patch git-block-fixup.patch git-block-dupe-definitions.patch git-block-xfs-barriers-broke.patch Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] killing the NR_IRQS arrays.
> Except for the what appears to be instability of the irq numbers on > simpler configurations I don't have a problem with it. I agree that's a bit annoying and I beleive it can be fixed. In additionm I'd like to look into exposing the domain/HW number -> virq mapping somewhere in sysfs maybe. > Until we find a solution for the user space side of things we seem to > need the unsigned int irq number for user space. Now I don't want > people mapping back and forth which is why I don't intend to provide a > reverse function. Ok. > But of course there will be a for_each_irq in the genirq layer so if > people really want to they will be able to go from the linux irq to > an irq_desc. But we don't have to export that generically (except > possibly something for the isa irqs). Ok. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
