Re: [ckrm-tech] Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement
I agree with 97% of what you write, Chandra. > one more level of indirection(instead of task->cpuset->cpus_allowed > it will be task->taskclass->res[CPUSET]->cpus_allowed). No -- two more levels of indirection (task->cpus_allowed becomes task->taskclass->res[CPUSET]->cpus_allowed). > But, for your purposes or our discussions one would need only 3 modules > of the above (core, rcfs and taskclass). Ok. That was not obvious to me until now. If there is a section in your documentation that explains this, and addresses the needs and motivations of someone trying to reuse portions of CKRM in such a manner, I missed it. Whatever ... In any case, on the issue that matters to me right now, we agree: > It won't be a happy, productive marriage. Good. Thanks. Good luck to you. > PS to everyone else: Wow, you have lot of patience :) For sure. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ckrm-e17
Shailabh Nagar wrote:
Version e17 of the Class-based Kernel Resource Management
is now available for download from
http://sourceforge.net/project/showfiles.php?group_id=85838_id=94608
The major updates since the previous version include:
1. Numerous bugfixes
2. Control over rate of process forks through the numtasks controller.
The rate of forking is a single systemwide parameter affecting all
classes. Existing share-based control over total number of forks allowed
per class remains the same.
3. Interface change: The "target" file has been removed from the RCFS
interface. The same functionality can now be obtained by writing to the
"members" file of any class.
Files released:
ckrm-e17.2610.patch
Combined patch against 2.6.10. Includes the numtasks and
listenaq controllers.
e17-incr.tar.bz2
Tarball of broken down patches. First 10 patches constitute
the e16 release and subsequent ones contain the updates since
then.
cpu.ckrm-e17.v10.patch
CPU controller.
Still to come:
memory controller
I/O controller
test packages
Please note that updates to CKRM based on the feedback from lkml on
the previous release (http://lkml.org/lkml/2004/11/29/152) are in
progress and will be included in the next release.
Testing and feedback welcome.
At line 3887 of cpu.ckrm-e17.v10.patch you add the line:
set_task_cpu(p,this_cpu);
to the middle of the function wake_up_new_task() resulting in the
following code:
} else {
this_rq = cpu_rq(this_cpu);
/*
* Not the local CPU - must adjust timestamp. This should
* get optimised away in the !CONFIG_SMP case.
*/
p->sdu.ingosched.timestamp = (p->sdu.ingosched.timestamp -
this_rq->timestamp_last_tick)
+ rq->timestamp_last_tick;
set_task_cpu(p,this_cpu);
__activate_task(p, rq);
if (TASK_PREEMPTS_CURR(p, rq))
resched_task(rq->curr);
schedstat_inc(rq, wunt_moved);
/*
* Parent and child are on different CPUs, now get the
* parent runqueue to update the parent's
->sdu.ingosched.sleep_avg:
*/
task_rq_unlock(rq, );
this_rq = task_rq_lock(current, );
}
where "rq" has been set by the return value of "task_rq_lock(p,
)", and the test "(cpu == this_cpu)" has failed with "cpu" set to
"task_cpu(p)". The result of this when the CKRM CPU code is not
configured into the build is that "p" will be queued on a runqueue that
is not in agreement with "p->thread_info->cpu" which in turn will lead
to future use of "task_rq_lock()" locking the wrong run queue and
eventually triggering some form of race condition.
If CKRM CPU is configured into the build the results are less drastic as
they only result in "nr_running" being incremented for the wrong run
queue. However, even this will have adverse scheduling effects as it
will probably confuse the load balancing code. Another potentially
confusing thing with this code (when CKRM CPU is configured in) is that
__activate_task() does NOT queue "p" on "rq" but on the queue found by
the call "get_task_lrq(p)".
The recommended fix for this problem would be to withdraw the:
set_task_cpu(p,this_cpu);
Peter
PS I reported this to the ckrm-tech list 5 days ago but it was ignored.
--
Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] device-mapper: multipath hardware handler for EMC
On 2005-02-11T19:58:41, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > +/* Code borrowed from dm-lsi-rdac by Mike Christie */
>
> Any reason that module isn't submitted?
No idea why.
> > + bio->bi_bdev = path->dev->bdev;
> > + bio->bi_sector = 0;
> > + bio->bi_private = path;
> > + bio->bi_end_io = emc_endio;
> > +
> > + page = alloc_page(GFP_ATOMIC);
> > + if (!page) {
> > + DMERR("dm-emc: get_failover_bio: alloc_page() failed.");
> > + bio_put(bio);
> > + return NULL;
> > + }
> > +
> > + if (bio_add_page(bio, page, data_size, 0) != data_size) {
> > + DMERR("dm-emc: get_failover_bio: alloc_page() failed.");
> > + __free_page(page);
> > + bio_put(bio);
> > + return NULL;
> > + }
> > +
> > + return bio;
>
> this would benefit from goto unwinding.
OK.
> > + if (h->short_trespass) {
> > + memcpy(page22, short_trespass_pg, data_size);
> > + } else {
> > + memcpy(page22, long_trespass_pg, data_size);
> > + }
>memcpy(page22, h->short_trespass ?
> short_trespass_pg : long_trespass_pg, data_size);
>
> ?
Yes, I first did some other things there than just copying the commands
around, it can surely benefit from cleanup.
> > +static struct emc_handler *alloc_emc_handler(void)
> > +{
> > + struct emc_handler *h = kmalloc(sizeof(*h), GFP_KERNEL);
> > +
> > + if (h) {
> > + h->lock = SPIN_LOCK_UNLOCKED;
> > + }
>
> if (h)
> spin_lock_init(>lock);
Came in via the copy, good catch.
> > +static unsigned emc_err(struct hw_handler *hwh, struct bio *bio)
> > +{
> > + /* FIXME: Patch from axboe still missing */
>
> it's in -mm now afaik??
No, it's not. That's the request sense keys, but here we're dealing with
the bio.
> > +#if 0
> > + int sense;
> > +
> > + if (bio->bi_error & BIO_SENSE) {
> > + sense = bio->bi_error & 0xff; /* sense key / asc / ascq */
> > +
> > + if (sense == 0x020403) {
>
> please use the sense handling helpers from Doug Gilbert so you can handle
> the descriptor sense format aswell. (And make the code a lot clear).
I'll go look them up.
> Also please try to use constants instead of magic numbers.
Noted. I'll clean this part up when I actually have sense keys to try,
so far this was mostly about getting that tiny bit of logic in.
Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] remove unused netlink NL_EMULATE_DEV code
NL_EMULATE_DEV handler functions can't ever be set, so let's rip them
out too. I realize the other half (netlink_attach()) just came out in
2.6.11-rc1, but what's left behind can't be used at all.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
af_netlink.c | 24 +---
1 files changed, 1 insertion(+), 23 deletions(-)
= net/netlink/af_netlink.c 1.69 vs edited =
--- 1.69/net/netlink/af_netlink.c 2005-01-21 12:25:32 -08:00
+++ edited/net/netlink/af_netlink.c 2005-02-11 19:47:08 -08:00
@@ -55,10 +55,6 @@
#define Nprintk(a...)
-#if defined(CONFIG_NETLINK_DEV) || defined(CONFIG_NETLINK_DEV_MODULE)
-#define NL_EMULATE_DEV
-#endif
-
struct netlink_opt
{
u32 pid;
@@ -66,7 +62,6 @@ struct netlink_opt
u32 dst_pid;
unsigned intdst_groups;
unsigned long state;
- int (*handler)(int unit, struct sk_buff *skb);
wait_queue_head_t wait;
struct netlink_callback *cb;
spinlock_t cb_lock;
@@ -596,10 +591,6 @@ int netlink_attachskb(struct sock *sk, s
nlk = nlk_sk(sk);
-#ifdef NL_EMULATE_DEV
- if (nlk->handler)
- return 0;
-#endif
if (atomic_read(>sk_rmem_alloc) > sk->sk_rcvbuf ||
test_bit(0, >state)) {
DECLARE_WAITQUEUE(wait, current);
@@ -639,14 +630,6 @@ int netlink_sendskb(struct sock *sk, str
int len = skb->len;
nlk = nlk_sk(sk);
-#ifdef NL_EMULATE_DEV
- if (nlk->handler) {
- skb_orphan(skb);
- len = nlk->handler(protocol, skb);
- sock_put(sk);
- return len;
- }
-#endif
skb_queue_tail(>sk_receive_queue, skb);
sk->sk_data_ready(sk, len);
@@ -711,12 +694,7 @@ retry:
static __inline__ int netlink_broadcast_deliver(struct sock *sk, struct
sk_buff *skb)
{
struct netlink_opt *nlk = nlk_sk(sk);
-#ifdef NL_EMULATE_DEV
- if (nlk->handler) {
- nlk->handler(sk->sk_protocol, skb);
- return 0;
- } else
-#endif
+
if (atomic_read(>sk_rmem_alloc) <= sk->sk_rcvbuf &&
!test_bit(0, >state)) {
skb_set_owner_r(skb, sk);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()
Jody, This happens every time you connect a device which ends up doing ISO_LISTEN_CHANNEL. We fixed the device disconnect case in -mm recently. I had sent you and Andrew an alternative patch which fixes this dma_pool_create case as well as the dma_pool_destroy case, albeit with a disadvantage - The patch does pre-allocation of the IR Legacy DMA in _pci_probe and deallocates it in _pci_remove. However I am not truly happy with it since it possibly wastes 200K of memory for people who don't have devices which need it. As I said earlier, I think the way to fix this is via schedule_work similar to the disconnect case, but it involves good amount of code change. I am working on it - any better ideas most welcome. Dan - Can you try the attached patch - on top current -mm1? (It's pretty no brainer that it will fix both cases but two testing heads are better than one.. :) Thanks Parag On Fri, 2005-02-11 at 13:43 -0500, Jody McIntyre wrote: > On Fri, Feb 11, 2005 at 10:35:33AM -0500, Dan Dennedy wrote: > > > I am testing this patch in the same manner as you: exiting Kino capture. > > I am getting a similar error in a different location. Can you look into > > it, please? > > > > Debug: sleeping function called from invalid context at mm/slab.c:2082 > > in_atomic():1, irqs_disabled():1 > > [] __might_sleep+0xa1/0xc0 > > [] kmem_cache_alloc+0x64/0x80 > > [] dma_pool_create+0x7b/0x190 > > [] alloc_dma_rcv_ctx+0x1a2/0x400 [ohci1394] > > [] ohci_devctl+0x3d9/0x640 [ohci1394] > > [] handle_iso_listen+0xee/0x160 [raw1394] > > [] state_connected+0x2de/0x2f0 [raw1394] > > [] raw1394_write+0xae/0xe0 [raw1394] > > [] vfs_write+0x14c/0x160 > > [] sys_write+0x51/0x80 > > [] sysenter_past_esp+0x52/0x75 > > Does this happen on exit or on startup? Looks like allocation problems, > which will be harder to fix, since you can't return to userland until > the allocation is complete. AFAICT the correct fix is to use > finer-grained locks, hold them for less time, and not use _irq or > _irqsave unless necessary. host_info_lock, in particular, is held for > far too long. > > Jody > > > > > > > > > > > --- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595_id=14396=click > > ___ > > mailing list [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/linux1394-devel > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Using O_DIRECT for file writing in a kernel module
On Fri, 2005-02-11 at 17:58 -0700, Hanson, Jonathan M wrote: > I'm trying to write to a file with the O_DIRECT flag from a > kernel module in a 2.4 series of kernel on x86 hardware. I've learned > that the O_DIRECT flag requires that the amount of data written and the > file offset pointer must be multiples of the underlying "block size." ehhh why are you writing to a file from a kernel module? That's generally considered a really bad idea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate
This patch introduces the sys_page_migrate() system call:
sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
Its intent is to cause the pages in the range given that are found on
old_nodes[i] to be moved to new_nodes[i]. Count is the the number of
entries in these two arrays of short.
Restrictions and limitations of this version:
(1) va_start and va_end must be mapped by the same vma. (The user
can read /proc/pid/maps to find out the appropriate vma ranges.)
This could easily be generalized, but has not been done for the
moment.
(2) There is no capability or authority checking being done here.
Any process can migrate any other process. This will be fixed
in a future version, once we agree on what the authority model
should be.
(3) Eventually, we plan on adding a page_migrate entry to the
vm_operations_struct. The problem is, in general, that only
the object itself knows how to migrate its pages. For the
moment, we are only handling the case of anonymous private
and memory mapped files, which handles practially all known
cases, but there are som other cases that are peculiar to
SN2 hardware that are not handled by the present code (e. g.
fetch & op storage). So for now, it is sufficient for us
to test vma->vm_ops pointer; if this is null we are in the
anonymoust private case, elsewise we are in the mapped file
case. The mapped file case handles mapped files, shared
anonymouse storage, and shared segments.
Signed-off-by:Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/arch/ia64/kernel/entry.S
===
--- linux-2.6.11-rc2-mm2.orig/arch/ia64/kernel/entry.S 2005-02-11
08:18:58.0 -0800
+++ linux-2.6.11-rc2-mm2/arch/ia64/kernel/entry.S 2005-02-11
16:07:27.0 -0800
@@ -1581,6 +1581,6 @@ sys_call_table:
data8 sys_ni_syscall
data8 sys_ni_syscall
data8 sys_ni_syscall
- data8 sys_ni_syscall
+ data8 sys_page_migrate // 1279
.org sys_call_table + 8*NR_syscalls // guard against failures to
increase NR_syscalls
Index: linux-2.6.11-rc2-mm2/mm/mmigrate.c
===
--- linux-2.6.11-rc2-mm2.orig/mm/mmigrate.c 2005-02-11 16:07:27.0
-0800
+++ linux-2.6.11-rc2-mm2/mm/mmigrate.c 2005-02-11 16:10:13.0 -0800
@@ -588,6 +588,228 @@ int try_to_migrate_pages(struct list_hea
return nr_busy;
}
+static int
+migrate_vma_common(struct list_head *page_list, short *node_map, int count)
+{
+ int pass=0, remains, migrated;
+ struct page *page;
+
+ while(pass<10) {
+
+ remains = try_to_migrate_pages(page_list, node_map);
+
+ if (remains < 0)
+ return remains;
+
+ migrated = 0;
+ if (!list_empty(page_list))
+ list_for_each_entry(page, page_list, lru)
+ migrated++;
+ else {
+ migrated = count;
+ break;
+ }
+
+ pass++;
+
+ migrated = count - migrated;
+
+ /* wait a bit and try again */
+ msleep(10);
+
+ }
+ return migrated;
+}
+
+static int
+migrate_mapped_file_vma(struct task_struct *task, struct mm_struct *mm,
+ struct vm_area_struct *vma, size_t va_start,
+ size_t va_end, short *node_map)
+{
+ struct page *page;
+ struct zone *zone;
+ struct address_space *as;
+ int count = 0, nid, ret;
+ LIST_HEAD(page_list);
+ long idx, start_idx, end_idx;
+
+ va_start = va_start & PAGE_MASK;
+ va_end = va_end & PAGE_MASK;
+ start_idx = (va_start - vma->vm_start) >> PAGE_SHIFT;
+ end_idx = (va_end - vma->vm_start) >> PAGE_SHIFT;
+
+ if (!vma->vm_file || !vma->vm_file->f_mapping)
+ BUG();
+
+ as = vma->vm_file->f_mapping;
+
+ for (idx = start_idx; idx <= end_idx; idx++) {
+ page = find_get_page(as, idx);
+ if (page) {
+ page_cache_release(page);
+
+ if (!page_mapcount(page) && !page->mapping)
+ BUG();
+
+ nid = page_to_nid(page);
+ if (node_map[nid] > 0) {
+ zone = page_zone(page);
+ spin_lock_irq(>lru_lock);
+ if (PageLRU(page) &&
+ __steal_page_from_lru(zone, page)) {
+ count++;
+ list_add(>lru, _list);
+ } else
+ BUG();
+
[RFC 2.6.11-rc2-mm2 4/7] mm: manual page migration -- cleanup 4
Add some extern declarations to include/linux/mmigrate.h to eliminate some "implicitly" declared warnings. Signed-off-by:Ray Bryant <[EMAIL PROTECTED]> Index: linux-2.6.11-rc2-mm2/include/linux/mmigrate.h === --- linux-2.6.11-rc2-mm2.orig/include/linux/mmigrate.h 2005-02-11 11:23:46.0 -0800 +++ linux-2.6.11-rc2-mm2/include/linux/mmigrate.h 2005-02-11 11:50:27.0 -0800 @@ -17,6 +17,9 @@ extern int page_migratable(struct page * struct list_head *); extern struct page * migrate_onepage(struct page *, int nodeid); extern int try_to_migrate_pages(struct list_head *); +extern int migration_duplicate(swp_entry_t); +extern struct page * lookup_migration_cache(int); +extern int migration_remove_reference(struct page *, int); #else static inline int generic_migrate_page(struct page *page, struct page *newpage, -- Best Regards, Ray --- Ray Bryant [EMAIL PROTECTED] The box said: "Requires Windows 98 or better", so I installed Linux. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2.6.11-rc2-mm2 6/7] mm: manual page migration -- add node_map arg to try_to_migrate_pages()
To migrate pages from one node to another, we need to tell
try_to_migrate_pages() which nodes we want to migrate off
of and where to migrate the pages found on each such node.
We do this by adding the node_map array argument to
try_to_migrate_pages(); node_map[N] gives the target
node to migrate pages to from node N.
This patch depends on a previous patch I submiteed that
adds a node argument to migrate_onepage(); this patch
is currently part of the Memory HOTPLUG page migration
patch.
node_migrate_onepage() is introduced to handle the case
where node_map is NULL (i. e. caller doesn't care where
we migrate the page, just migrate it out of here) or
the system is not a NUMA system.
Signed-off-by:Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/include/linux/mmigrate.h
===
--- linux-2.6.11-rc2-mm2.orig/include/linux/mmigrate.h 2005-02-11
11:50:27.0 -0800
+++ linux-2.6.11-rc2-mm2/include/linux/mmigrate.h 2005-02-11
11:52:50.0 -0800
@@ -16,11 +16,29 @@ extern int migrate_page_buffer(struct pa
extern int page_migratable(struct page *, struct page *, int,
struct list_head *);
extern struct page * migrate_onepage(struct page *, int nodeid);
-extern int try_to_migrate_pages(struct list_head *);
+extern int try_to_migrate_pages(struct list_head *, short *);
extern int migration_duplicate(swp_entry_t);
extern struct page * lookup_migration_cache(int);
extern int migration_remove_reference(struct page *, int);
+extern int try_to_migrate_pages(struct list_head *, short *node_map);
+
+#ifdef CONFIG_NUMA
+static inline struct page *node_migrate_onepage(struct page *page, short
*node_map)
+{
+ if (node_map)
+ return migrate_onepage(page, node_map[page_to_nid(page)]);
+ else
+ return migrate_onepage(page, MIGRATE_NODE_ANY);
+
+}
+#else
+static inline struct page *node_migrate_onepage(struct page *page, short
*node_map)
+{
+ return migrate_onepage(page, MIGRATE_NODE_ANY);
+}
+#endif
+
#else
static inline int generic_migrate_page(struct page *page, struct page *newpage,
int (*fn)(struct page *, struct page *))
Index: linux-2.6.11-rc2-mm2/mm/mmigrate.c
===
--- linux-2.6.11-rc2-mm2.orig/mm/mmigrate.c 2005-02-11 11:50:40.0
-0800
+++ linux-2.6.11-rc2-mm2/mm/mmigrate.c 2005-02-11 11:51:04.0 -0800
@@ -502,9 +502,11 @@ out_unlock:
/*
* This is the main entry point to migrate pages in a specific region.
* If a page is inactive, the page may be just released instead of
- * migration.
+ * migration. node_map is supplied in those cases (on NUMA systems)
+ * where the caller wishes to specify to which nodes the pages are
+ * migrated. If node_map is null, the target node is MIGRATE_NODE_ANY.
*/
-int try_to_migrate_pages(struct list_head *page_list)
+int try_to_migrate_pages(struct list_head *page_list, short *node_map)
{
struct page *page, *page2, *newpage;
LIST_HEAD(pass1_list);
@@ -542,7 +544,7 @@ int try_to_migrate_pages(struct list_hea
list_for_each_entry_safe(page, page2, _list, lru) {
list_del(>lru);
if (PageLocked(page) || PageWriteback(page) ||
- IS_ERR(newpage = migrate_onepage(page, MIGRATE_NODE_ANY))) {
+ IS_ERR(newpage = node_migrate_onepage(page, node_map))) {
if (page_count(page) == 1) {
/* the page is already unused */
putback_page_to_lru(page_zone(page), page);
@@ -560,7 +562,7 @@ int try_to_migrate_pages(struct list_hea
*/
list_for_each_entry_safe(page, page2, _list, lru) {
list_del(>lru);
- if (IS_ERR(newpage = migrate_onepage(page, MIGRATE_NODE_ANY))) {
+ if (IS_ERR(newpage = node_migrate_onepage(page, node_map))) {
if (page_count(page) == 1) {
/* the page is already unused */
putback_page_to_lru(page_zone(page), page);
--
Best Regards,
Ray
---
Ray Bryant [EMAIL PROTECTED]
The box said: "Requires Windows 98 or better",
so I installed Linux.
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2.6.11-rc2-mm2 5/7] mm: manual page migration -- cleanup 5
Fix up a switch statement so gcc doesn't complain about it.
Signed-off-by: Ray Bryant <[EMAIL PROTECTED]>
Index: linux/mm/mmigrate.c
===
--- linux.orig/mm/mmigrate.c2005-01-30 11:13:58.0 -0800
+++ linux/mm/mmigrate.c 2005-01-30 11:19:33.0 -0800
@@ -319,17 +319,17 @@ generic_migrate_page(struct page *page,
/* Wait for all operations against the page to finish. */
ret = migrate_fn(page, newpage, );
switch (ret) {
- default:
- /* The page is busy. Try it later. */
- goto out_busy;
case -ENOENT:
/* The file the page belongs to has been truncated. */
page_cache_get(page);
page_cache_release(newpage);
newpage->mapping = NULL;
- /* fall thru */
+ break;
case 0:
- /* fall thru */
+ break;
+ default:
+ /* The page is busy. Try it later. */
+ goto out_busy;
}
arch_migrate_page(page, newpage);
--
Best Regards,
Ray
---
Ray Bryant [EMAIL PROTECTED]
The box said: "Requires Windows 98 or better",
so I installed Linux.
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2.6.11-rc2-mm2 1/7] mm: manual page migration -- cleanup 1
This patch removes some remaining Memory HOTPLUG specific code
from the page migration patch. I have sent Dave Hansen the -R
version of this patch so that this code can be added back
later at the start of the Memory HOTPLUG patches themselves.
In particular, this patchremoves VM_IMMOVABLE and MAP_IMMOVABLE.
Signed-off-by: Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.10-mm1-page-migration/kernel/fork.c
===
--- linux-2.6.10-mm1-page-migration.orig/kernel/fork.c 2005-01-10
08:46:51.0 -0800
+++ linux-2.6.10-mm1-page-migration/kernel/fork.c 2005-01-10
09:14:03.0 -0800
@@ -211,7 +211,7 @@ static inline int dup_mmap(struct mm_str
if (IS_ERR(pol))
goto fail_nomem_policy;
vma_set_policy(tmp, pol);
- tmp->vm_flags &= ~(VM_LOCKED|VM_IMMOVABLE);
+ tmp->vm_flags &= ~(VM_LOCKED);
tmp->vm_mm = mm;
tmp->vm_next = NULL;
anon_vma_link(tmp);
Index: linux-2.6.10-mm1-page-migration/include/linux/mm.h
===
--- linux-2.6.10-mm1-page-migration.orig/include/linux/mm.h 2005-01-10
08:46:51.0 -0800
+++ linux-2.6.10-mm1-page-migration/include/linux/mm.h 2005-01-10
09:14:04.0 -0800
@@ -164,7 +164,6 @@ extern unsigned int kobjsize(const void
#define VM_ACCOUNT 0x0010 /* Is a VM accounted object */
#define VM_HUGETLB 0x0040 /* Huge TLB Page VM */
#define VM_NONLINEAR 0x0080 /* Is non-linear (remap_file_pages) */
-#define VM_IMMOVABLE 0x0100 /* Don't place in hot removable area */
#ifndef VM_STACK_DEFAULT_FLAGS /* arch can override this */
#define VM_STACK_DEFAULT_FLAGS VM_DATA_DEFAULT_FLAGS
Index: linux-2.6.10-mm1-page-migration/include/linux/mman.h
===
--- linux-2.6.10-mm1-page-migration.orig/include/linux/mman.h 2005-01-10
08:46:51.0 -0800
+++ linux-2.6.10-mm1-page-migration/include/linux/mman.h2005-01-10
10:05:54.0 -0800
@@ -61,8 +61,7 @@ calc_vm_flag_bits(unsigned long flags)
return _calc_vm_trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN ) |
_calc_vm_trans(flags, MAP_DENYWRITE, VM_DENYWRITE ) |
_calc_vm_trans(flags, MAP_EXECUTABLE, VM_EXECUTABLE) |
- _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED) |
- _calc_vm_trans(flags, MAP_IMMOVABLE, VM_IMMOVABLE );
+ _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED);
}
#endif /* _LINUX_MMAN_H */
Index: linux-2.6.10-mm1-page-migration/arch/i386/kernel/sys_i386.c
===
--- linux-2.6.10-mm1-page-migration.orig/arch/i386/kernel/sys_i386.c
2005-01-10 08:46:51.0 -0800
+++ linux-2.6.10-mm1-page-migration/arch/i386/kernel/sys_i386.c 2005-01-10
09:14:04.0 -0800
@@ -70,7 +70,7 @@ asmlinkage long sys_mmap2(unsigned long
unsigned long prot, unsigned long flags,
unsigned long fd, unsigned long pgoff)
{
- return do_mmap2(addr, len, prot, flags & ~MAP_IMMOVABLE, fd, pgoff);
+ return do_mmap2(addr, len, prot, flags, fd, pgoff);
}
/*
@@ -101,7 +101,7 @@ asmlinkage int old_mmap(struct mmap_arg_
if (a.offset & ~PAGE_MASK)
goto out;
- err = do_mmap2(a.addr, a.len, a.prot, a.flags & ~MAP_IMMOVABLE,
+ err = do_mmap2(a.addr, a.len, a.prot, a.flags,
a.fd, a.offset >> PAGE_SHIFT);
out:
return err;
Index: linux-2.6.10-mm1-page-migration/include/asm-ppc64/mman.h
===
--- linux-2.6.10-mm1-page-migration.orig/include/asm-ppc64/mman.h
2005-01-10 08:46:51.0 -0800
+++ linux-2.6.10-mm1-page-migration/include/asm-ppc64/mman.h2005-01-10
09:14:04.0 -0800
@@ -38,7 +38,6 @@
#define MAP_POPULATE 0x8000 /* populate (prefault) pagetables */
#define MAP_NONBLOCK 0x1 /* do not block on IO */
-#define MAP_IMMOVABLE 0x2
#define MADV_NORMAL0x0 /* default page-in behavior */
#define MADV_RANDOM0x1 /* page-in minimum required */
Index: linux-2.6.10-mm1-page-migration/include/asm-i386/mman.h
===
--- linux-2.6.10-mm1-page-migration.orig/include/asm-i386/mman.h
2005-01-10 08:46:51.0 -0800
+++ linux-2.6.10-mm1-page-migration/include/asm-i386/mman.h 2005-01-10
09:14:04.0 -0800
@@ -22,7 +22,6 @@
#define MAP_NORESERVE 0x4000 /* don't check for reservations */
#define MAP_POPULATE 0x8000 /* populate (prefault) pagetables */
#define MAP_NONBLOCK 0x1 /* do not block on IO */
-#define MAP_IMMOVABLE 0x2
#define MS_ASYNC 1
[RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview
Overview The purpose of this set of patches is to introduce (one part of) the necessary kernel infrastructure to support "manual page migration". That phrase is intended to describe a facility whereby some user program (most likely a batch scheduler) is given the responsibility of managing where jobs run on a large NUMA system. If it turns out that a job needs to be run on a different set of nodes from where it is running now, then that user program would invoke this facility to move the job to the new set of nodes. We use the word "manual" here to indicate that the facility is invoked in a way that the kernel is told where to move things; we distinguish this approach from "automatic page migration" facilities which have been proposed in the past. To us, "automatic page migration" implies using hardware counters to determine where pages should reside and having the O/S automatically move misplaced pages. The utility of such facilities, for example, on IRIX has, been mixed, and we are not currently proposing such a facility for Linux. The normal sequence of events would be as follows: A job is running on, say nodes 5-8, and a higher priority job arrives and the only place it can be run, for whatever reason, is nodes 5-8. Then the scheduler would suspend the processes of the existing job (by, for example sending them a SIGSTOP) and start the new job on those nodes. At some point in the future, other nodes become available for use, and at this point the batch scheduler would invoke the manual page migration facility to move the processes of the suspended job from nodes 5-8 to the new set of nodes. Note that not all of the pages of all of the processes will need to (or should) be moved. For example, pages of shared libraries are likely to be shared by many processes in the system; these pages should not be moved merely because a few processes using these libraries have been migrated. For the moment, we are going to defer the problem of determining which pages should be moved; a solution to this problem will be the subject of a subsequent patch set. So, for now let us assume that we have determined that a particular set of pages associated with a particular process need to be moved. The kernel interface that we are proposing is the following: page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes); Here va_start and va_end are assumed to be mapped by the same vma; these addresses are effectively ways that we can specify all (or part of) an address space map as given in /proc/pid/maps. count is the number of entries in the old_nodes and new_nodes arrays. The effect of this system call is to cause all pages in the page range specified that are found to be resident on old_nodes[i] to be moved to new_nodes[i]. In addition to its use by batch schedulers, we also envision that this facility could be used by a program to re-arrange the allocation of its own pages on various nodes of the NUMA system, most likely to optimize performance of the application during different phases of its computation. Implementation Details -- This patch depends on the implementation of page migration from the Memory Hotplug Patch (see http://sr71.net/patches; this patch set is maintained by Dave Hansen of IBM and many other contributors). Recently, I worked with Dave to rearrange the sequence of the hotplug patches so that the page migration patch could be applied by itself and then the rest of the Memory Hotplug patches could be applied on top of that patch. (In the following and in the descriptions of the other patches, we will refer to the page migration patch and to the Memory Hotplug patch itself -- by this we mean the patches available as, for example: patch-2.6.11-rc2-mm3-mhp1-pm.gz and the rest of the hotplug patches available in broken-out-2.6.11-rc2-mm2-mhp1.tar.gz The latter actually includes the page migration patch, but we will use the term Memory Hotplug patch to mean the patchset that starts with patch "A1.1-refactor-setup_memory-i386.patch" in the series file for the broken-out patches. The page-migration patch consists of the patches before that, these patches have names ithat start with "AA-".) Given this powerful underlying framework, the implementation of manual page migration is relatively straightforward. There are 7 patches supplied here, the first 5 of those are cleanup patches of various sorts for the page migration patch. Patches 6 and 7 of the series implement the system call described above. Limitations of the Current Patch This is, after all, an RFC and the current patch is only prototype code. It is being sent to the list in its current form to get some early comments back and to allow for careful validation of the approach that has been selected, before so much code has been written that the project has solidified and become difficult to be changed. I welcome the opportunity for others to examine this patch
[RFC 2.6.11-rc2-mm2 3/7] mm: manual page migration -- cleanup 3
Fix a trivial error in include/linux/mmigrate.h
Signed-off-by: Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/include/linux/mmigrate.h
===
--- linux-2.6.11-rc2-mm2.orig/include/linux/mmigrate.h 2005-02-11
10:08:10.0 -0800
+++ linux-2.6.11-rc2-mm2/include/linux/mmigrate.h 2005-02-11
11:22:34.0 -0800
@@ -1,5 +1,5 @@
-#ifndef _LINUX_MEMHOTPLUG_H
-#define _LINUX_MEMHOTPLUG_H
+#ifndef _LINUX_MMIGRATE_H
+#define _LINUX_MMIGRATE_H
#include
#include
@@ -36,4 +36,4 @@ extern void arch_migrate_page(struct pag
static inline void arch_migrate_page(struct page *page, struct page *newpage)
{}
#endif
-#endif /* _LINUX_MEMHOTPLUG_H */
+#endif /* _LINUX_MMIGRATE_H */
--
Best Regards,
Ray
---
Ray Bryant [EMAIL PROTECTED]
The box said: "Requires Windows 98 or better",
so I installed Linux.
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2.6.11-rc2-mm2 2/7] mm: manual page migration -- cleanup 2
This patch removes some remaining Memory HOTPLUG specific code
from the page migration patch. I have sent Dave Hansen the -R
version of this patch so that this code can be added back
later at the start of the Memory HOTPLUG patches themselves.
In particular, this patch removes some #ifdef CONFIG_MEMORY_HOTPLUG
code from the page migration patch.
Signed-off-by: Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/mm/vmalloc.c
===
--- linux-2.6.11-rc2-mm2.orig/mm/vmalloc.c 2005-02-11 10:08:10.0
-0800
+++ linux-2.6.11-rc2-mm2/mm/vmalloc.c 2005-02-11 10:35:47.0 -0800
@@ -523,16 +523,7 @@ EXPORT_SYMBOL(__vmalloc);
*/
void *vmalloc(unsigned long size)
{
-#ifdef CONFIG_MEMORY_HOTPLUG
- /*
-* : This is temprary code, which should be replaced with proper one
-* after the scheme to specify hot removable region has defined.
-* 25/Sep/2004 -- taka
-*/
- return __vmalloc(size, GFP_KERNEL, PAGE_KERNEL);
-#else
return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL);
-#endif
}
EXPORT_SYMBOL(vmalloc);
Index: linux-2.6.11-rc2-mm2/mm/shmem.c
===
--- linux-2.6.11-rc2-mm2.orig/mm/shmem.c2005-02-11 10:08:10.0
-0800
+++ linux-2.6.11-rc2-mm2/mm/shmem.c 2005-02-11 10:35:47.0 -0800
@@ -93,16 +93,7 @@ static inline struct page *shmem_dir_all
* BLOCKS_PER_PAGE on indirect pages, assume PAGE_CACHE_SIZE:
* might be reconsidered if it ever diverges from PAGE_SIZE.
*/
-#ifdef CONFIG_MEMORY_HOTPLUG
- /*
-* : This is temprary code, which should be replaced with proper one
-* after the scheme to specify hot removable region has defined.
-* 25/Sep/2004 -- taka
-*/
- return alloc_pages(gfp_mask & ~__GFP_HIGHMEM,
PAGE_CACHE_SHIFT-PAGE_SHIFT);
-#else
return alloc_pages(gfp_mask, PAGE_CACHE_SHIFT-PAGE_SHIFT);
-#endif
}
static inline void shmem_dir_free(struct page *page)
--
Best Regards,
Ray
---
Ray Bryant [EMAIL PROTECTED]
The box said: "Requires Windows 98 or better",
so I installed Linux.
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Blocking behavior changed for pipes in 2.6.11-rc3
This program [cribbed loosely from tst-cancel17.c in glibc] has changed
behavior with the recent pipe changes. It used to block; which makes sense.
It gets the maximum buffer size for the pipe (or a page if that's larger),
and writes that many bytes plus two to it. It reads one back. The write
"shouldn't" have room to finish.
Checking the POSIX language for _PC_PIPE_BUF I think this is OK - it doesn't
say that no more bytes than that can be written at once, just that this is
the maximum which are guaranteed to be written atomically. So I'm guessing
this change is a feature, not a bug. Right?
[snip]
#include
#include
#include
#include
#include
#include
void *
tf (void *fd)
{
int *fds = fd;
char mem[1];
read (fds[0], mem, 1);
}
int
main (void)
{
pthread_t th;
int len;
int fds[2];
if (pipe (fds) != 0)
{
puts ("pipe failed");
return 1;
}
size_t len2 = fpathconf (fds[1], _PC_PIPE_BUF);
size_t page_size = sysconf (_SC_PAGESIZE);
len2 = (len2 < page_size ? page_size : len2) + 1 + 1;
char *mem2 = malloc (len2);
pthread_create (, NULL, tf, fds);
write (fds[1], mem2, len2);
return 0;
}
[/snip]
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] remove unused ethertap_mc support
There is no Kconfig option to enable CONFIG_ETHERTAP_MC, and if you
could the resulting source would not build. That code uses the obsolete
protinfo union, then further pokes into a privately defined netlink
structure to setup the groups. Remove this broken code altogether.
It'd be nice to remove ethertap altogether in favor of tun/tap, but at
lest remove the bits that won't build in case ethertap is still used.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
drivers/net/ethertap.c | 84 -
1 files changed, 84 deletions(-)
= drivers/net/ethertap.c 1.15 vs edited =
--- 1.15/drivers/net/ethertap.c 2004-10-28 16:32:42 -07:00
+++ edited/drivers/net/ethertap.c 2005-02-11 18:53:25 -08:00
@@ -38,9 +38,6 @@ static int ethertap_start_xmit(struct s
static int ethertap_close(struct net_device *dev);
static struct net_device_stats *ethertap_get_stats(struct net_device *dev);
static void ethertap_rx(struct sock *sk, int len);
-#ifdef CONFIG_ETHERTAP_MC
-static void set_multicast_list(struct net_device *dev);
-#endif
static int ethertap_debug;
@@ -57,9 +54,6 @@ static struct net_device **tap_map; /* R
struct net_local
{
struct sock *nl;
-#ifdef CONFIG_ETHERTAP_MC
- __u32 groups;
-#endif
struct net_device_stats stats;
};
@@ -96,9 +90,6 @@ static int __init ethertap_probe(int un
dev->hard_start_xmit = ethertap_start_xmit;
dev->stop = ethertap_close;
dev->get_stats = ethertap_get_stats;
-#ifdef CONFIG_ETHERTAP_MC
- dev->set_multicast_list = set_multicast_list;
-#endif
dev->tx_queue_len = 0;
dev->flags|=IFF_NOARP;
@@ -134,41 +125,6 @@ static int ethertap_open(struct net_devi
return 0;
}
-#ifdef CONFIG_ETHERTAP_MC
-static unsigned ethertap_mc_hash(__u8 *dest)
-{
- unsigned idx = 0;
- idx ^= dest[0];
- idx ^= dest[1];
- idx ^= dest[2];
- idx ^= dest[3];
- idx ^= dest[4];
- idx ^= dest[5];
- return 1U << (idx&0x1F);
-}
-
-static void set_multicast_list(struct net_device *dev)
-{
- unsigned groups = ~0;
- struct net_local *lp = netdev_priv(dev);
-
- if (!(dev->flags&(IFF_NOARP|IFF_PROMISC|IFF_ALLMULTI))) {
- struct dev_mc_list *dmi;
-
- groups = ethertap_mc_hash(dev->broadcast);
-
- for (dmi=dev->mc_list; dmi; dmi=dmi->next) {
- if (dmi->dmi_addrlen != 6)
- continue;
- groups |= ethertap_mc_hash(dmi->dmi_addr);
- }
- }
- lp->groups = groups;
- if (lp->nl)
- lp->nl->protinfo.af_netlink.groups = groups;
-}
-#endif
-
/*
* We transmit by throwing the packet at netlink. We have to clone
* it for 2.0 so that we dev_kfree_skb() the locked original.
@@ -177,9 +133,6 @@ static void set_multicast_list(struct ne
static int ethertap_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct net_local *lp = netdev_priv(dev);
-#ifdef CONFIG_ETHERTAP_MC
- struct ethhdr *eth = (struct ethhdr*)skb->data;
-#endif
if (skb_headroom(skb) < 2) {
static int once;
@@ -213,31 +166,13 @@ static int ethertap_start_xmit(struct sk
lp->stats.tx_bytes+=skb->len;
lp->stats.tx_packets++;
-#ifndef CONFIG_ETHERTAP_MC
netlink_broadcast(lp->nl, skb, 0, ~0, GFP_ATOMIC);
-#else
- if (dev->flags_NOARP) {
- netlink_broadcast(lp->nl, skb, 0, ~0, GFP_ATOMIC);
- return 0;
- }
-
- if (!(eth->h_dest[0]&1)) {
- /* Unicast packet */
- __u32 pid;
- memcpy(, eth->h_dest+2, 4);
- netlink_unicast(lp->nl, skb, ntohl(pid), MSG_DONTWAIT);
- } else
- netlink_broadcast(lp->nl, skb, 0,
ethertap_mc_hash(eth->h_dest), GFP_ATOMIC);
-#endif
return 0;
}
static __inline__ int ethertap_rx_skb(struct sk_buff *skb, struct net_device
*dev)
{
struct net_local *lp = netdev_priv(dev);
-#ifdef CONFIG_ETHERTAP_MC
- struct ethhdr *eth = (struct ethhdr*)(skb->data + 2);
-#endif
int len = skb->len;
if (len < 16) {
@@ -250,25 +185,6 @@ static __inline__ int ethertap_rx_skb(st
kfree_skb(skb);
return -EPERM;
}
-
-#ifdef CONFIG_ETHERTAP_MC
- if (!(dev->flags&(IFF_NOARP|IFF_PROMISC))) {
- int drop = 0;
-
- if (eth->h_dest[0]&1) {
- if (!(ethertap_mc_hash(eth->h_dest)>groups))
- drop = 1;
- } else if (memcmp(eth->h_dest, dev->dev_addr, 6) != 0)
- drop = 1;
-
- if (drop) {
- if (ethertap_debug > 3)
- printk(KERN_DEBUG "%s : not for us\n",
dev->name);
- kfree_skb(skb);
- return -EINVAL;
-
[PATCH] Fix IPMI LAN bridging
The size of LAN bridged messages was not being returned properly from the function that calculated address sizes. This fixes the problem. Signed-off-by: Corey Minyard <[EMAIL PROTECTED]> Index: linux-2.6.11-rc3/drivers/char/ipmi/ipmi_msghandler.c === --- linux-2.6.11-rc3.orig/drivers/char/ipmi/ipmi_msghandler.c +++ linux-2.6.11-rc3/drivers/char/ipmi/ipmi_msghandler.c @@ -480,6 +480,9 @@ return sizeof(struct ipmi_ipmb_addr); } + if (addr_type == IPMI_LAN_ADDR_TYPE) + return sizeof(struct ipmi_lan_addr); + return 0; }
Re: out-of-line x86 "put_user()" implementation
On Fri, 11 Feb 2005, Chuck Ebbert wrote: > > And in any case is it too much to ask for an 80-column limit? ;) Yes. Dammit, especially for something like this, the long-line version is just _so_ much more readable. Compare my and your version wrt being able to tell what the differences between the four different cases are. In the single-long-line version, the differences are trivially visible. In the "prettified" version (aka "I'm still living in the 60's, and proud of it" version), it's impossible to pick out the differences. If you don't like long lines, use a helper #define for the common part or something. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3 06/11] ide: make disk flush functions use TASKFILE instead
On Thu, 10 Feb 2005 at 17:38:39 +0900, Tejun Heo wrote:
> - (drive->capacity64 >= (1UL << 28)))
> - rq->buffer[0] = WIN_FLUSH_CACHE_EXT;
> + (drive->capacity64 >= (1UL << 28))) {
> + task->tfRegister[IDE_COMMAND_OFFSET] = WIN_FLUSH_CACHE_EXT;
Shouldn't that be "(drive->capacity64 > (1UL << 28))" ??
--
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc2 02/04] ide: __ide_do_rw_disk() rewritten ide_write_taskfil
On Sun, 6 Feb 2005 at 20:26:55 +0900, Tejun Heo wrote:
> + if (drive->using_dma &&
> + !(hwif->no_lba48_dma && block + rq->nr_sectors > 1ULL << 28)) {
> + /* DMA */
> + if (hwif->dma_setup(drive))
> + goto fallback_to_pio;
> + if (rq_data_dir(rq) == READ) {
> + command = lba48 ? WIN_READDMA_EXT : WIN_READDMA;
> + if (drive->vdma)
> + command = lba48 ? WIN_READ_EXT : WIN_READ;
> + } else {
> + command = lba48 ? WIN_WRITEDMA_EXT : WIN_WRITEDMA;
> + if (drive->vdma)
> + command = lba48 ? WIN_WRITE_EXT : WIN_WRITE;
> }
> - /* fallback to PIO */
> - ide_init_sg_cmd(drive, rq);
> + hwif->dma_exec_cmd(drive, command);
> + hwif->dma_start(drive);
> + return ide_started;
> }
Should that be "block + rq->nr_sectors >= 1ULL << 28"?
Legal sector numbers for LBA28 range from 0 thru (1 << 28 - 1).
LBA28 _capacities_ range from 1 thru (1 << 28) sectors.
And why is it using 1ULL some places and 1UL in others in the ide driver?
--
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: out-of-line x86 "put_user()" implementation
On Tue, 8 Feb 2005 at 18:27:08 -0800, Linus Torvalds wrote:
> +/*
> + * Strange magic calling convention: pointer in %ecx,
> + * value in %eax(:%edx), return value in %eax, no clobbers.
> + */
> +extern void __put_user_1(void);
> +extern void __put_user_2(void);
> +extern void __put_user_4(void);
> +extern void __put_user_8(void);
> +
> +#define __put_user_1(x, ptr) __asm__ __volatile__("call __put_user_1":"=a"
> (__ret_pu):"0" ((typeof(*(ptr)))(x)), "c" (ptr))
> +#define __put_user_2(x, ptr) __asm__ __volatile__("call __put_user_2":"=a"
> (__ret_pu):"0" ((typeof(*(ptr)))(x)), "c" (ptr))
> +#define __put_user_4(x, ptr) __asm__ __volatile__("call __put_user_4":"=a"
> (__ret_pu):"0" ((typeof(*(ptr)))(x)), "c" (ptr))
> +#define __put_user_8(x, ptr) __asm__ __volatile__("call __put_user_8":"=a"
> (__ret_pu):"A" ((typeof(*(ptr)))(x)), "c" (ptr))
> +#define __put_user_X(x, ptr) __asm__ __volatile__("call __put_user_X":"=a"
> (__ret_pu):"c" (ptr))
> +
Should "cc" be on the clobber list since all the called functions alter
EFLAGS?
And in any case is it too much to ask for an 80-column limit? ;)
#define __put_user_1(x, ptr)\
__asm__ __volatile__( \
"call __put_user_1" \
: "=a" (__ret_pu) \
: "0" ((typeof(*(ptr)))(x)), "c" (ptr) \
: "cc")
#define __put_user_2(x, ptr)\
__asm__ __volatile__( \
"call __put_user_2" \
: "=a" (__ret_pu) \
: "0" ((typeof(*(ptr)))(x)), "c" (ptr) \
: "cc")
#define __put_user_4(x, ptr)\
__asm__ __volatile__( \
"call __put_user_4" \
: "=a" (__ret_pu) \
: "0" ((typeof(*(ptr)))(x)), "c" (ptr) \
: "cc")
#define __put_user_8(x, ptr)\
__asm__ __volatile__( \
"call __put_user_8" \
: "=a" (__ret_pu) \
: "A" ((typeof(*(ptr)))(x)), "c" (ptr) \
: "cc")
#define __put_user_X(x, ptr)\
__asm__ __volatile__( \
"call __put_user_X" \
: "=a" (__ret_pu) \
: "c" (ptr) \
: "cc")
--
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fixes for cdsymlinks.c
Hi...
I needed this patch to get this working, I think they are obvious
corrections:
--- cdsymlinks.c.orig 2005-02-12 02:51:15.0 +0100
+++ cdsymlinks.c2005-02-12 02:48:35.0 +0100
@@ -218,7 +218,7 @@
list_assign_split (struct list_t *list, char *text)
{
char *token = strchr (text, ':');
- token = strtok (token ? token + 1 : text, " \t");
+ token = strtok (token ? token + 1 : text, " \t\n");
while (token)
{
list_prepend (list, token);
@@ -267,8 +267,8 @@
list_delete (_output);
list_assign_split (_output, p.we_wordv[0] + 7);
}
- else if (!strncmp (p.we_wordv[0], "NUMBERED_LINKS=", 14))
-numbered_links = atoi (p.we_wordv[0] + 14);
+ else if (!strncmp (p.we_wordv[0], "NUMBERED_LINKS=", 15))
+numbered_links = atoi (p.we_wordv[0] + 15);
break;
}
/* fall through */
@@ -325,9 +325,9 @@
list_assign_split (_CDRW, text);
else if (!strncasecmp (text, "Can write CD-R", 14))
list_assign_split (_CDR, text);
-else if (!strncasecmp (text, "Can read MRW", 14))
+else if (!strncasecmp (text, "Can read MRW", 12))
list_assign_split (_CDMRW, text);
-else if (!strncasecmp (text, "Can write MRW", 14))
+else if (!strncasecmp (text, "Can write MRW", 13))
list_assign_split (_CDWMRW, text);
}
if (!feof (info))
Hope this is correct and will be included in udev-054 ;)
TIA
--
J.A. Magallon \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.10-jam9 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1
pgprJwul2AbUT.pgp
Description: PGP signature
Re: [ckrm-tech] Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement
On Fri, Feb 11, 2005 at 01:21:12AM -0800, Paul Jackson wrote: > [ For those who have already reached a conclusion on this > subject, there is little that is new below. It's just > cast in a different light, as an analysis of how well > the CKRM cpuset/memset task class that Chandra describes > meets the needs of cpusets. The conclusion is: not well. > > A pickup truck and a motorcycle both have their uses. > It's just difficult to combine them in a useful fashion. > > Feel free to skim or skip the rest of this message. -pj ] > [ As replied in a earlier mail I am not advocating for cpuset to be a ckrm controller. In this mail I am just providing clarifications for some of Paul's comments. -chandra ] > > Chandra writes: > > If I missed some feature of cpuset that shows a bigger problem, please > > let me know. > > Perhaps it would be better if first you ask yourself what > features your cpuset/memset taskclasses provide beyond First off, I wasn't pitching for 'our' cpuset/memset taskclass. I was suggesting that 'your' cpuset can be a ckrm controller. > what's available in the basic sched_setaffinity (for cpu) > and mbind/set_mempolicy (for memory) calls. Offhand, I don't > see any. and it don't have to be same as what the above functions provide. cpuset can function exactly the same way under ckrm as it does otherwise. > > But, I will grant, with my apologies, that I wrote the above > more in irritation than in a sincere effort to explain. > > So, let me come at this through another door. > > Since it seems apparent by now that both numa placement and > workload management cause some form of mutually exclusive brain > damage to its practitioners, making it difficult for either to > understand the other, let me: > 1) describe the important properties of cpusets, > 2) examine how well your proposal provides such, and > 3) examine its additional costs compared to cpusets. > > 1. The important properties of cpusets. > === > > Cpusets facilitate integrated processor and memory placement > of jobs on large systems, especially useful on numa systems, > where the co-ordinated placement of jobs on cpus and memory is > important, sometimes critical, to obtaining good performance. > > It is becoming increasingly obvious, as Intel, IBM and AMD > push more and more cores into one package at one end, and as > NEC, IBM, Bull, SGI and others push more and more packages into > single image systems at the other end, that complex layered numa > topologies are here to stay, in increasing number and complexity. > > Cpusets helps manage numa placement of jobs in a way that > numa folks seem to find makes sense. The names of key > interface elements, and the opening remarks in commentary and > documentation are specific and relevant to the needs of those > doing numa placement. > > It does so with a minimal, low cost patch in the main kernel. > Running diffstat on the cpuset* patches in 2.6.11-rc1-mm2 shows > the following summary stats: > > 19 files changed, 2362 insertions(+), 253 deletions(-) > > The runtime costs are nearly zero, consisting in the usual > case on any hot paths of a usage counter increment at fork, a > usage counter decrement at exit, a usually inconsequential > bitmask test in mm/page_alloc.c, and a generation number > check in the mm/mempolicy.c alloc_page_vma() wrapper to > __alloc_pages(). > > Cpusets handles any number of CPUs and Memory Nodes, with no > practical hard limit imposed by the API or data types. > > Cpusets can be used in combination with a workload manager > such as CKRM. You can use cpusets to create "soft partitions" > that are subsets of the entire system, and then in each such > partition, you can run a separate instance of a workload manager > to obtain the desired resource sharing. CKRM's controllers currently may not play well with cpusets. > > Cpusets may provide a practical API to support administrative > refinements of scheduler domains, along more optimal natural > job boundaries, instead of just along automatic, artificial > architecture boundaries. Matthew and Nick both seem to be > making mumblings in this direction, but the jury is still out. > Indeed, we're still investigating. I have not heard of anyone > proposing to integrate CKRM and sched domains in this manner, > nor do I expect to. I haven't looked at sched_domains closely. May be I should and see how we can form a synergy. > > There is no reason to artificially limit the depth of the cpuset > hierarchy, which represents subsets of subsets of cpus and nodes. > The rules (invariants) of cpusets have been carefully chosen > so as to never require any global or wide ranging analysis of > the cpuset hierarchy in order to enforce. Each child must be > a subset of its parent, and exclusive cpusets cannot overlap > their siblings. That's about it. Both rules can be evaluated > locally, using just the nearest relatives of an
Re: [PATCH] kmalloc() bug in pci-dma.c
Venkatesh Pallipadi <[EMAIL PROTECTED]> wrote: > > After burning my fingers with a similar mistake in one of the patches > that I am working on, I did a quick grep to find out all faulty kmalloc() > calls and found this. > > dma_declare_coherent_memory() is calling kmalloc with wrong arguments. > Attached patch fixes this. > > Please apply. > > Thanks, > Venki > > Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> > > --- linux-2.6.10/arch/i386/kernel/pci-dma.c.org 2005-02-11 > 15:18:42.596362296 -0800 > +++ linux-2.6.10/arch/i386/kernel/pci-dma.c 2005-02-11 15:19:18.446912184 > -0800 > @@ -89,11 +89,11 @@ int dma_declare_coherent_memory(struct d > if (!mem_base) > goto out; > > -dev->dma_mem = kmalloc(GFP_KERNEL, sizeof(struct dma_coherent_mem)); > +dev->dma_mem = kmalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL); erp. I'll add that to the 2.6.11 queue, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kmalloc() bug in pci-dma.c
After burning my fingers with a similar mistake in one of the patches that I am working on, I did a quick grep to find out all faulty kmalloc() calls and found this. dma_declare_coherent_memory() is calling kmalloc with wrong arguments. Attached patch fixes this. Please apply. Thanks, Venki Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> --- linux-2.6.10/arch/i386/kernel/pci-dma.c.org 2005-02-11 15:18:42.596362296 -0800 +++ linux-2.6.10/arch/i386/kernel/pci-dma.c 2005-02-11 15:19:18.446912184 -0800 @@ -89,11 +89,11 @@ int dma_declare_coherent_memory(struct d if (!mem_base) goto out; - dev->dma_mem = kmalloc(GFP_KERNEL, sizeof(struct dma_coherent_mem)); + dev->dma_mem = kmalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL); if (!dev->dma_mem) goto out; memset(dev->dma_mem, 0, sizeof(struct dma_coherent_mem)); - dev->dma_mem->bitmap = kmalloc(GFP_KERNEL, bitmap_size); + dev->dma_mem->bitmap = kmalloc(bitmap_size, GFP_KERNEL); if (!dev->dma_mem->bitmap) goto free1_out; memset(dev->dma_mem->bitmap, 0, bitmap_size); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: udev::cdsymlinks does not consider a 'cdrw' as a 'cdrom'
On 2005.02.12, J.A. Magallon wrote: > > On 2005.02.12, J.A. Magallon wrote: > > Hi... > > > > I have a little problem with udev. I have udev-051, but have tried > > cdsymlinks.c from 053 and is the same. > > > > It does not give 'cdrom' or 'dvd' for DVD writers. > > In one box, hdb is a DVD, and hdc is a DVDRW: > > > > Opps, and cdsymlinks.c and .sh behave different: > > werewolf:~# /sbin/cdsymlinks hdc -d > Devices: hdb hdc > DVDRAM : 0 1 hdc > DVDRW : 0 1 hdc > DVD: 1 1 hdb hdc > CDRW : 0 1 hdc > CDR: 0 1 hdc > CDWMRW : > CDMRW : > CDROM : (all) hdb hdc > cdrw dvdrw dvdram > > werewolf:~# /etc/udev/scripts/cdsymlinks.sh hdc -d > Devices: hdb hdc > DVDRAM : 0 1 hdc > DVDRW : 0 1 hdc > DVD: 1 1 hdb hdc > CDRW : 0 1 hdc > CD-R : 0 1 hdc > CDMRW : 1 1 hdb hdc > CDM: 1 1 hdb hdc > CDROM : (all) hdb hdc > cdrom1 cdrw dvd1 dvdrw dvdram > Caught it: --- cdsymlinks.c.orig 2005-02-12 02:17:19.0 +0100 +++ cdsymlinks.c2005-02-12 02:17:26.0 +0100 @@ -267,8 +267,8 @@ list_delete (_output); list_assign_split (_output, p.we_wordv[0] + 7); } - else if (!strncmp (p.we_wordv[0], "NUMBERED_LINKS=", 14)) -numbered_links = atoi (p.we_wordv[0] + 14); + else if (!strncmp (p.we_wordv[0], "NUMBERED_LINKS=", 15)) +numbered_links = atoi (p.we_wordv[0] + 15); break; } /* fall through */ -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.10-jam9 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1 pgplrJRQGo0sj.pgp Description: PGP signature
Re: udev::cdsymlinks does not consider a 'cdrw' as a 'cdrom'
On 2005.02.12, J.A. Magallon wrote: > Hi... > > I have a little problem with udev. I have udev-051, but have tried > cdsymlinks.c from 053 and is the same. > > It does not give 'cdrom' or 'dvd' for DVD writers. > In one box, hdb is a DVD, and hdc is a DVDRW: > Opps, and cdsymlinks.c and .sh behave different: werewolf:~# /sbin/cdsymlinks hdc -d Devices: hdb hdc DVDRAM : 0 1 hdc DVDRW : 0 1 hdc DVD: 1 1 hdb hdc CDRW : 0 1 hdc CDR: 0 1 hdc CDWMRW : CDMRW : CDROM : (all) hdb hdc cdrw dvdrw dvdram werewolf:~# /etc/udev/scripts/cdsymlinks.sh hdc -d Devices: hdb hdc DVDRAM : 0 1 hdc DVDRW : 0 1 hdc DVD: 1 1 hdb hdc CDRW : 0 1 hdc CD-R : 0 1 hdc CDMRW : 1 1 hdb hdc CDM: 1 1 hdb hdc CDROM : (all) hdb hdc cdrom1 cdrw dvd1 dvdrw dvdram -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.10-jam9 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1 pgplmWi9mr1WA.pgp Description: PGP signature
udev::cdsymlinks does not consider a 'cdrw' as a 'cdrom'
Hi... I have a little problem with udev. I have udev-051, but have tried cdsymlinks.c from 053 and is the same. It does not give 'cdrom' or 'dvd' for DVD writers. In one box, hdb is a DVD, and hdc is a DVDRW: werewolf:/proc/sys/dev/cdrom> cat info CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: hdc hdb drive speed:40 48 drive # of slots: 1 1 Can close tray: 1 1 Can open tray: 1 1 Can lock tray: 1 1 Can change speed: 1 1 Can select disk:0 0 Can read multisession: 1 1 Can read MCN: 1 1 Reports media changed: 1 1 Can play audio: 1 1 Can write CD-R: 1 0 Can write CD-RW:1 0 Can read DVD: 1 1 Can write DVD-R:1 0 Can write DVD-RAM: 1 0 Can read MRW: 1 1 Can write MRW: 1 1 Can write RAM: 1 1 werewolf:/proc/sys/dev/cdrom> cdsymlinks hdb cdrom dvd werewolf:/proc/sys/dev/cdrom> cdsymlinks hdc cdrw dvdrw dvdram werewolf:/proc/sys/dev/cdrom> cdsymlinks hdc -d Devices: hdb hdc DVDRAM : 0 1 hdc DVDRW : 0 1 hdc DVD: 1 1 hdb hdc CDRW : 0 1 hdc CDR: 0 1 hdc CDWMRW : CDMRW : CDROM : (all) hdb hdc cdrw dvdrw dvdram (btw, I did not know my DVD _reader_ can write anything like MRW or RAM) In other box that just has also a combo drive (DVD + DVDRW 4.7): nada:/proc/sys/dev/cdrom# cat info CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: hdh drive speed:32 drive # of slots: 1 Can close tray: 1 Can open tray: 1 Can lock tray: 1 Can change speed: 1 Can select disk:0 Can read multisession: 1 Can read MCN: 1 Reports media changed: 1 Can play audio: 1 Can write CD-R: 1 Can write CD-RW:1 Can read DVD: 1 Can write DVD-R:1 Can write DVD-RAM: 1 Can read MRW: 1 Can write MRW: 1 Can write RAM: 1 nada:~> cdsymlinks hdh nada:~> cdsymlinks hdh -d Devices: hdh DVDRAM : 1 hdh DVDRW : 1 hdh DVD: 1 hdh CDRW : 1 hdh CDR: 1 hdh CDWMRW : CDMRW : CDROM : (all) hdh And now that I realize it, why the different debug output ??? TIA -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.10-jam9 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1 pgplumSQgJE3a.pgp Description: PGP signature
Using O_DIRECT for file writing in a kernel module
I'm trying to write to a file with the O_DIRECT flag from a kernel module in a 2.4 series of kernel on x86 hardware. I've learned that the O_DIRECT flag requires that the amount of data written and the file offset pointer must be multiples of the underlying "block size." To try things out I've been successful is writing to a file with O_DIRECT in user space using multiples of PAGE_SIZE. However, when I try to do the same from my kernel module I'm always greeted with an -EINVAL as the return code from the write call when trying multiples of PAGE_SIZE. Then I realized that the kernel uses four megabyte pages and not four kilobyte pages so I tried passing four megabytes of data to the write call but also got -EINVAL in return. Is it possible to use O_DIRECT to write a file from a kernel module? If so, what size of data do I need to pass so that it will work? I've been through Google and the kernel source code but didn't see an answer as to the size required to get it to work. Thanks in advance for any assistance offered. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-bk: cpu hotplug + preempt = smp_processor_id warnings galore
On Sat, Feb 12, 2005 at 12:56:54AM +0100, Matthias-Christian Ott wrote: > Nathan Lynch wrote: > > >With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id > >warnings whenever I hotplug cpus: ... > > Use get_cpu() (It disables preemption) or __smp_processor_id () (on a smp). It's not necessarily that simple (ok, maybe the idle loop warning is). But at least one of the warnings I listed appears to be caused by a kernel thread that is normally bound to a particular cpu trying to do normal processing on another cpu before it has stopped. Injudicious use of __smp_processor_id or get_cpu in this case would only obscure the problem. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
Hi, Greg KH write: > Very nice stuff. Ok, that's a good reason not to get rid of these > files, although they can be generated on the fly from the modules > themselves (like depmod does it.) Time to resurrect modinfo? ;-) Didn't we plan to get rid of that, too? If we like to use information from modules, there should be a scriptable tool to extract this kind of information, otherwise it will be a bitch to maintain those tools. Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] stop using "base" argument in __free_pages_bulk()
This patch is somewhat of a companion to the "no buddy bitmap" patches.
It messes with core allocator functions, so it probably deserves a long
turn in -mm.
Appended is a patch which stops using the zone->zone_mem_map to
calculate the buddy and combined page pointers. It uses the fact
that the mem_map array is guaranteed to be contigious for the
surrounding (1 << MAX_ORDER) pages. The relative positions of
the pages in the physical address space to provide the alignment;
which conicidentally fixes the issue where zones are not aligned
at MAX_ORDER. There is a very comprehensive comment in the new
code explaining the mathematical relationship between a page and
its buddy so I won't reproduce it here.
This kind of approach is required for CONFIG_NONLINEAR systems
where the mem_map is not contiguous within a zone, and the
zone->zone_mem_map is not used at all.
This patch has been boot-tested on a large variety of systems and
architectures: my P4 laptop, 16-way NUMAQ, 16-way Summit, 4-way
x86 SMP, ppc64 LPAR, x86_64, and several ia64 configurations.
It has been performance-tested on a 16-way NUMAQ. SDET shows a
very slight (within margin of error) performance gain. Kernbench
shows an approximately ~1% decrease in system time with this
patch applied. So, it has a likely small positive performance impact.
However, the patch has the potential to have a negative performance
impact on systems with an expensive page_to_pfn() implementation.
But, I think the NUMAQ has one of the more expensive ones around,
and it doesn't seem mind too much.
Applies against 2.6.11-rc3.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
-- Dave
Appended is a patch which stops using the zone->zone_mem_map to
calculate the buddy and combined page pointers. It uses the fact
that the mem_map array is guaranteed to be contigious for the
surrounding (1 << MAX_ORDER) pages. The relative positions of
the pages in the physical address space to provide the
alignement; which conicidentally fixes the issue where zones are
not aligned at MAX_ORDER. There is a very comprehensive comment
in the new code explaining the mathematical relationship between
a page and its buddy so I won't reproduce it here.
This kind of approach is required for CONFIG_NONLINEAR systems
where the mem_map is not contiguous within a zone, and the
zone->zone_mem_map is not used at all.
This patch has been boot-tested on a large variety of systems and
architectures: my P4 laptop, 16-way NUMAQ, 16-way Summit, 4-way
x86 SMP, ppc64 LPAR, x86_64, and several ia64 configurations.
It has been performance-tested on a 16-way NUMAQ. SDET shows a
very slight (within margin of error) performance gain. Kernbench
shows an approximately ~1% decrease in system time with this
patch applied. So, it has a likely positive performance impact.
However, the patch has the potential to have a negative performance
impact on systems with an expensive page_to_pfn() implementation.
But, I think the NUMAQ has one of the more expensive ones around,
and it doesn't seem mind too much.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
clean-dave/mm/page_alloc.c | 57 +
1 files changed, 42 insertions(+), 15 deletions(-)
diff -puN mm/page_alloc.c~B-sparse-120-free-pages-no-base mm/page_alloc.c
--- clean/mm/page_alloc.c~B-sparse-120-free-pages-no-base 2005-02-11 16:30:30.0 -0800
+++ clean-dave/mm/page_alloc.c 2005-02-11 16:30:36.0 -0800
@@ -191,6 +191,35 @@ static inline void rmv_page_order(struct
}
/*
+ * Locate the struct page for both the matching buddy in our
+ * pair (buddy1) and the combined O(n+1) page they form (page).
+ *
+ * 1) Any buddy B1 will have an order O twin B2 which satisfies
+ * the following equasion:
+ * B2 = B1 ^ (1 << O)
+ * For example, if the starting buddy (buddy2) is #8 its order
+ * 1 buddy is #10:
+ * B2 = 8 ^ (1 << 1) = 8 ^ 2 = 10
+ *
+ * 2) Any buddy B will have an order O+1 parent P which
+ * satisfies the following equasion:
+ * P = B & ~(1 << O)
+ *
+ * Assumption: *_mem_map is contigious at least up to MAX_ORDER
+ */
+static inline struct page *__page_find_buddy(struct page *page, unsigned long page_idx, unsigned int order)
+{
+ unsigned long buddy_idx = page_idx ^ (1 << order);
+
+ return page + (buddy_idx - page_idx);;
+}
+
+static inline unsigned long __find_combined_index(unsigned long page_idx, unsigned int order)
+{
+ return (page_idx & ~(1 << order));
+}
+
+/*
* This function checks whether a page is free && is the buddy
* we can do coalesce a page and its buddy if
* (a) the buddy is free &&
@@ -233,44 +262,43 @@ static inline int page_is_buddy(struct p
* -- wli
*/
-static inline void __free_pages_bulk (struct page *page, struct page *base,
+static inline void __free_pages_bulk (struct page *page,
struct zone *zone, unsigned int order)
{
unsigned long
Re: 2.6.11-rc3: Kylix application no longer works?
Hi, Rik van Riel wrote: > On Wed, 9 Feb 2005, Daniel Jacobowitz wrote: > > On Tue, Feb 08, 2005 at 06:10:18PM -0800, Andrew Morton wrote: > > It's asking for a lot of unwritable zeroed space. See this: > >> LOAD 0x00 0x08048000 0x08048000 0xb7354 0x1b7354 R E > >> 0x1000 LOAD 0x0b7354 0x08200354 0x08200354 0x1e3e4 0x1f648 RW > >> 0x1000 > > > > clear_user's probably not the right way to provide the extra zeroing. > > Indeed, clear_user() refuses to zero data when it's not writable > to the user process ... So if the application wants an read only range of zeroed pages, why not just map the ZERO_PAGE() multiple times there? I can imagine _valid_ uses for that (templates for zero intitialized data), although there are _better_ ways to do that. Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 01/04] Adding cipher mode context information to crypto_tfm
On Thu, Feb 10, 2005 at 12:17:24PM +0100, Fruhwirth Clemens wrote: > On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote: > > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote: > > > > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote: > > > > Adding a few more fixmap slots wouldn't hurt anyone. But if you want an > > > > arbitrarily large number of them then no, we cannot do that. > > > > > > What magnitude is "few more"? 2, 10, 100? > > > > Not 100. 10 would seem excessive. > > Out of curiosity: Where does this limitation even come from? What > prevents kmap_atomic from adding slots dynamically? There's a single page of PTEs for mapping high memory and the atomic slots are a small subset of that. They're fixed in number for complexity reasons - we don't want to have an allocator here: /* * kmap_atomic/kunmap_atomic is significantly faster than kmap/kunmap because * no global lock is needed and because the kmap code must perform a global TLB * invalidation when the kmap pool wraps. * -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3: intel8x0 alsa outputs no sound
On Feb-05 2005, Sat, 16:06 -0600 Narayan Desai <[EMAIL PROTECTED]> wrote: > Try muting the headphone jack sense control with alsamixer. I had the > same problem with rc2 on my t41p, and that solved it. This doesn't help on a T40p, I'm afraid. No sound in 2.6.11-rc3 with snd-intel8x0.ko, worked all ok in 2.6.10. -- Tomas Szepe <[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/
What is Badness in map_area_pte at mm/vmalloc.c:126
I'm testing some code and I compiled the Virtual framebuffer as a module. When I insert it I get a Badness in map_area_pte at mm/vmalloc.c:126. What causes this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, 2005-02-11 at 09:06 -0800, Greg KH wrote: > On Fri, Feb 11, 2005 at 12:47:07PM +0100, Kasper Sandberg wrote: > > On Thu, 2005-02-10 at 22:41 -0800, Greg KH wrote: > > > On Fri, 2005-02-11 at 02:30 +0100, Kasper Sandberg wrote: > > > > hey greg > > > > > > > > i remember for some months back, you posted something similar.. is this > > > > a version thats ready for use? if it is! im gonna use it! :D > > > > > > Yes, this is that version, cleaned up and given a proper build system, > > > and even tested on my machines here :) > > ah cool. and in that case, you probably also have ebuilds for it, if you > > do, please post them somewhere :) > > I don't have an ebuild for it yet, but it's on my list to get done. And > when I do so, it will just show up in the normal gentoo tree. The main > "issue" with this is I need to create a virtual for the hotplug service > so it doesn't conflict with the existing hotplug package. Not a big > deal, just not as simple as adding a single ebuild to the tree. just make it provide virtual/hotplug, then do a fgrep -r "hotplug" /usr/portage/ and then replace with virtual/hotplug ;) > > thanks, > > greg k-h > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-bk: cpu hotplug + preempt = smp_processor_id warnings galore
Nathan Lynch wrote: Hi- With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id warnings whenever I hotplug cpus: # echo 0 > /sys/devices/system/cpu/cpu1/online cpu 1 (hwid 1) Ready to die... BUG: using smp_processor_id() in preemptible [0001] code: ksoftirqd/1/5 caller is .ksoftirqd+0xbc/0x1f8 Call Trace: [c000fffbbce0] [] 0x (unreliable) [c000fffbbd60] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000fffbbe20] [c005f414] .ksoftirqd+0xbc/0x1f8 [c000fffbbed0] [c00764cc] .kthread+0x128/0x134 [c000fffbbf90] [c0014248] .kernel_thread+0x4c/0x6c I believe the above warning is caused by the local_softirq_pending call on a "foreign" cpu before ksoftirqd/1 has been stopped. Looking at the code, I think this doesn't indicate a real bug, but it would be better if ksoftirqd didn't check local_softirq_pending after it's been kicked off its cpu, right? # echo 1 > /sys/devices/system/cpu/cpu1/online BUG: using smp_processor_id() in preemptible [0001] code: swapper/0 caller is .dedicated_idle+0x68/0x22c Call Trace: [c000fffafc50] [] 0x (unreliable) [c000fffafcd0] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000fffafd90] [c000f998] .dedicated_idle+0x68/0x22c [c000fffafe80] [c000fce8] .cpu_idle+0x34/0x4c [c000fffaff00] [c003a744] .start_secondary+0x10c/0x150 [c000fffaff90] [c000bd28] .enable_64b_mode+0x0/0x28 Should ppc64 simply use _smp_processor_id() in its idle loop code (like i386)? If I online and offline cpus rapidly enough I can eventually get the following: printk: 49 messages suppressed. BUG: using smp_processor_id() in preemptible [0001] code: events/3/1262 caller is .cache_reap+0x21c/0x2b8 Call Trace: [c000ed67bb90] [] 0x (unreliable) [c000ed67bc10] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000ed67bcd0] [c00938e8] .cache_reap+0x21c/0x2b8 [c000ed67bda0] [c006f4bc] .worker_thread+0x230/0x310 [c000ed67bed0] [c00764cc] .kthread+0x128/0x134 [c000ed67bf90] [c0014248] .kernel_thread+0x4c/0x6c And this will repeat over and over even after I stop hotplugging cpus... from the same events thread so I think it's somehow gotten "stuck"? Anything I can do to further debug? Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi! Use get_cpu() (It disables preemption) or __smp_processor_id () (on a smp). Matthias-Christian Ott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ohci_hcd, usb scanner and kernel 2.6.8.1 or 2.6.10 troubles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Barbara Post. On 12.02.2005 02:25 you said the following: | Hi, | I am unable to use my USB Agfa Snapscan 1212_U scanner, with kernel | 2.6.8.1 or 2.6.10 (both compiled by myself from www.kernel.org sources) | and xsane 0.96-1 (Debian). | | It worked with kernel 2.6.7. | | When I use VMware, I'm able to use it though (in Windows), whatever | linux kernel I use. | | When I start xsane, I get "error opening device | 'snapscan:libusb:001:004': I/O error on device" or simply "no device | found" if I restart xsane after the first error message (or sometimes at | first start). | | Sometimes it gets further and when I try to acquire preview, I get "I/O | error" and the following in /var/log/syslog : | | Feb 11 23:19:00 babs1 kernel: ohci_hcd :00:02.2: urb c15e13e0 path | 1.3 ep1in 8216 cc 8 --> status -75 I have the same problem with my Epson 1260 on RHEL4 beta2 (linux-2.6.9). I don't know about 2.6.7, but with 2.4.21 (RHEL3) it works fine. - -- Boris B. Zhmurov mailto: [EMAIL PROTECTED] "wget http://kernelpanic.ru/bb_public_key.pgp -O - | gpg --import" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCDUVdmEQixi5w37YRApP+AJ9I5M7hf/0HPCATTnemFaNbLhvsbgCfZdTz +hQ/jvcu7+xDpaXYTiOFZj4= =6WVB -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb-maintainer] Re: [RFC: 2.6 patch] DVB: possible cleanups
Holger Waechtler wrote: > Adrian Bunk wrote: > > >Before I'm getting flamed to death: > >This patch contains possible cleanups. If parts of this patch conflict > >with pending changes these parts of my patch have to be dropped. > > > >This patch contains the following possible cleanups: > >- make needlessly global code static > >- remove the following EXPORT_SYMBOL'ed but unused function: > > - bt8xx/bt878.c: bt878_find_by_i2c_adap > >- remove the following unused global functions: > > - dvb-core/dvb_demux.c: dmx_get_demuxes > > - dvb-core/dvb_demux.c: dvb_set_crc32 > >- remove the following unneeded EXPORT_SYMBOL's: > > - dvb-core/dvb_demux.c: dvb_dmx_swfilter_packet > > dvb_dmx_swfilter_packet() should remain exported to the public, > accessing this directly makes sense for some architectures. Hm, I don't know any out-of-tree driver which is using it. Do you? Besides, it is roughly equivalent to dvb_dmx_swfilter_packets(demux, buf, 1) (the difference is in locking and the test for the MPEG-2 TS sync byte). IMHO the EXPORT_SYMBOL for dvb_dmx_swfilter_packet() can be removed. To me the patches look good and I'm going to apply them to linuxtv.org CVS. Thanks, Johannes PS: The linuxtv.org server will be down for maintenance over the weekend which includes the linux-dvb-maintainer list. No need to worry. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6-bk: cpu hotplug + preempt = smp_processor_id warnings galore
Hi- With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id warnings whenever I hotplug cpus: # echo 0 > /sys/devices/system/cpu/cpu1/online cpu 1 (hwid 1) Ready to die... BUG: using smp_processor_id() in preemptible [0001] code: ksoftirqd/1/5 caller is .ksoftirqd+0xbc/0x1f8 Call Trace: [c000fffbbce0] [] 0x (unreliable) [c000fffbbd60] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000fffbbe20] [c005f414] .ksoftirqd+0xbc/0x1f8 [c000fffbbed0] [c00764cc] .kthread+0x128/0x134 [c000fffbbf90] [c0014248] .kernel_thread+0x4c/0x6c I believe the above warning is caused by the local_softirq_pending call on a "foreign" cpu before ksoftirqd/1 has been stopped. Looking at the code, I think this doesn't indicate a real bug, but it would be better if ksoftirqd didn't check local_softirq_pending after it's been kicked off its cpu, right? # echo 1 > /sys/devices/system/cpu/cpu1/online BUG: using smp_processor_id() in preemptible [0001] code: swapper/0 caller is .dedicated_idle+0x68/0x22c Call Trace: [c000fffafc50] [] 0x (unreliable) [c000fffafcd0] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000fffafd90] [c000f998] .dedicated_idle+0x68/0x22c [c000fffafe80] [c000fce8] .cpu_idle+0x34/0x4c [c000fffaff00] [c003a744] .start_secondary+0x10c/0x150 [c000fffaff90] [c000bd28] .enable_64b_mode+0x0/0x28 Should ppc64 simply use _smp_processor_id() in its idle loop code (like i386)? If I online and offline cpus rapidly enough I can eventually get the following: printk: 49 messages suppressed. BUG: using smp_processor_id() in preemptible [0001] code: events/3/1262 caller is .cache_reap+0x21c/0x2b8 Call Trace: [c000ed67bb90] [] 0x (unreliable) [c000ed67bc10] [c01c9f1c] .smp_processor_id+0x154/0x168 [c000ed67bcd0] [c00938e8] .cache_reap+0x21c/0x2b8 [c000ed67bda0] [c006f4bc] .worker_thread+0x230/0x310 [c000ed67bed0] [c00764cc] .kthread+0x128/0x134 [c000ed67bf90] [c0014248] .kernel_thread+0x4c/0x6c And this will repeat over and over even after I stop hotplugging cpus... from the same events thread so I think it's somehow gotten "stuck"? Anything I can do to further debug? Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ohci_hcd, usb scanner and kernel 2.6.8.1 or 2.6.10 troubles
Hi, I am unable to use my USB Agfa Snapscan 1212_U scanner, with kernel 2.6.8.1 or 2.6.10 (both compiled by myself from www.kernel.org sources) and xsane 0.96-1 (Debian). It worked with kernel 2.6.7. When I use VMware, I'm able to use it though (in Windows), whatever linux kernel I use. When I start xsane, I get "error opening device 'snapscan:libusb:001:004': I/O error on device" or simply "no device found" if I restart xsane after the first error message (or sometimes at first start). Sometimes it gets further and when I try to acquire preview, I get "I/O error" and the following in /var/log/syslog : Feb 11 23:19:00 babs1 kernel: ohci_hcd :00:02.2: urb c15e13e0 path 1.3 ep1in 8216 cc 8 --> status -75 or this : ohci_hcd :00:02.2 urb c15e1460 path 1.3 ep1in 8216 cc8 --> status -75 Scanner is correctly found by sane-find-scanner. It seems that it changes port every time. Thank you very much for any hint. What could I do since my .config contains CONFIG_USB_DEBUG=y ? Enabling debugging for xscanimage doesn't help. Barbara --- $ lsmod Module Size Used by ohci_hcd 32584 0 sr_mod 13860 0 sd_mod 12368 0 radeon129060 0 vmnet 28124 2 vmmon 153132 0 ipt_REJECT 5568 0 ipt_limit 1920 0 ipt_LOG 6208 0 ipt_MASQUERADE 2688 0 ipt_state 1472 0 iptable_mangle 2176 0 iptable_nat23368 1 ipt_MASQUERADE ip_conntrack 40308 3 ipt_MASQUERADE,ipt_state,iptable_nat iptable_filter 2944 0 ip_tables 16320 8 ipt_REJECT,ipt_limit,ipt_LOG,ipt_MASQUERADE,ipt_state,iptable_mangle,iptable_nat,iptable_filter i2c_sis96x 4484 0 it87 21156 0 i2c_sensor 2880 1 it87 i2c_isa 1664 0 snd_pcm_oss55716 0 snd_mixer_oss 18944 1 snd_pcm_oss apm18092 0 Note : vmnet and vmmon are VMware modules, they never bothered. I have the same error when vmware service is stopped and they are unloaded. --- Here are lenghty log files that may help. - Powering on scanner (usb hub unplugged, unloading ohci-hid module first): Feb 11 23:55:53 babs1 kernel: ohci_hcd :00:02.3: wakeup Feb 11 23:55:53 babs1 kernel: hub 2-0:1.0: state 5 ports 3 chg fff8 evt 0002 Feb 11 23:55:53 babs1 kernel: ohci_hcd :00:02.3: GetStatus roothub.portstatus [0] = 0x00010101 CSC PPS CCS Feb 11 23:55:53 babs1 kernel: hub 2-0:1.0: port 1, status 0101, change 0001, 12 Mb/s Feb 11 23:55:53 babs1 kernel: hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101 Feb 11 23:55:53 babs1 kernel: ohci_hcd :00:02.3: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS PES CCS Feb 11 23:55:53 babs1 kernel: usb 2-1: new full speed USB device using ohci_hcd and address 2 Feb 11 23:55:53 babs1 kernel: ohci_hcd :00:02.3: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS PES CCS Feb 11 23:55:53 babs1 kernel: usb 2-1: ep0 maxpacket = 8 Feb 11 23:55:53 babs1 kernel: usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=0 Feb 11 23:55:53 babs1 kernel: usb 2-1: default language 0x0409 Feb 11 23:55:53 babs1 kernel: usb 2-1: Product: SNAPSCAN Feb 11 23:55:53 babs1 kernel: usb 2-1: Manufacturer: AGFA Feb 11 23:55:53 babs1 kernel: usb 2-1: hotplug Feb 11 23:55:53 babs1 usb.agent[6641]: libusbscanner: loaded successfully Feb 11 23:55:53 babs1 kernel: usb 2-1: adding 2-1:1.0 (config #1, interface 0) Feb 11 23:55:53 babs1 kernel: usb 2-1:1.0: hotplug --- Powering on scanner (plugged on usb hub): Feb 11 23:27:56 babs1 kernel: hub 1-1:1.0: state 5 ports 4 chg fff0 evt 0008 Feb 11 23:27:56 babs1 kernel: hub 1-1:1.0: port 3, status 0100, change 0001, 12Mb/s Feb 11 23:27:56 babs1 kernel: usb 1-1.3: USB disconnect, address 3 Feb 11 23:27:56 babs1 kernel: usb 1-1.3: usb_disable_device nuking all URBs Feb 11 23:27:56 babs1 kernel: usb 1-1.3: unregistering interface 1-1.3:1.0 Feb 11 23:27:56 babs1 kernel: usb 1-1.3:1.0: hotplug Feb 11 23:27:56 babs1 kernel: usb 1-1.3: unregistering device Feb 11 23:27:56 babs1 kernel: usb 1-1.3: hotplug Feb 11 23:27:56 babs1 kernel: hub 1-1:1.0: debounce: port 3: total 100ms stable100ms status 0x100 Feb 11 23:34:56 babs1 kernel: hub 1-1:1.0: state 5 ports 4 chg fff0 evt 0008 Feb 11 23:34:56 babs1 kernel: hub 1-1:1.0: port 3, status 0101, change 0001, 12Mb/s Feb 11 23:34:56 babs1 kernel: hub 1-1:1.0: debounce: port 3: total 100ms stable100ms status 0x101 Feb 11 23:34:56 babs1 kernel: usb 1-1.3: new full speed USB device using ohci_hcd and address 4 Feb 11 23:34:56 babs1 kernel: usb 1-1.3: ep0 maxpacket = 8 Feb 11 23:34:56
Re: [PATCH] [SERIAL] add TP560 data/fax/modem support
On Mon, Feb 07, 2005 at 12:39:42PM -0700, Bjorn Helgaas wrote: > Claim Topic TP560 data/fax/voice modem. This device reports as class 0x0780, > so we don't claim it by default: Applied, thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] device-mapper: multipath hardware handler
Hi Alasdair,
Alasdair G Kergon wrote:
> +/*
> + * Constructs a hardware handler object, takes custom arguments
> + */
> +typedef int (*hwh_ctr_fn) (struct hw_handler *hwh, unsigned arc, char
> **argv); +typedef void (*hwh_dtr_fn) (struct hw_handler *hwh);
> +
> +typedef void (*hwh_pg_init_fn) (struct hw_handler *hwh, unsigned bypassed,
> +struct path *path);
> +typedef unsigned (*hwh_err_fn) (struct hw_handler *hwh, struct bio *bio);
> +typedef int (*hwh_status_fn) (struct hw_handler *hwh,
> + status_type_t type,
> + char *result, unsigned int maxlen);
> +
> +/* Information about a hardware handler type */
> +struct hw_handler_type {
> + char *name;
> + struct module *module;
> +
> + hwh_ctr_fn ctr;
> + hwh_dtr_fn dtr;
> +
> + hwh_pg_init_fn pg_init;
> + hwh_err_fn err;
> + hwh_status_fn status;
> +};
Please loose the prototypes, don't use prefixes/suffixes and use more
descriptive names. Reasons are in Documentation/CodingStyle, Chapter 4.
So I suggest declaring it like this:
struct hardware_handler_operations {
char *name;
struct module *module;
int (*create) (struct hw_handler *handler, unsigned int argc, char **argv);
void (*destroy) (struct hw_handler *handler);
void (*pg_init) (struct hw_handler *handler, unsigned int bypassed,
struct path *path);
unsigned (*error) (struct hw_handler *hwh, struct bio *bio);
int (*status) (struct hw_handler *hwh, status_type_t type, char *result,
unsigned int maxlen);
};
But you might want to loose status_type_t, too. Also hw_foo is a bit generic,
isn't it? We are all dealing with "hardware" in any driver (which is
basically another word for "hardware handler"). So please be a bit more
creative on WHAT you drive.
Regards
Ingo Oeser
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problem on SATA-disk with Promise SATAII 150 TX4 ("DriveReady SeekComplete Error")
Johannes Resch wrote: Hi, [please CC me on replies] I've got a box running 2.6.10 (with the patch[0] needed to support the Promise SATAII 150 TX4 controller). This box has three software raid1 partitions mirrored on a SATA disk on the Promise controller and a disk on the mainboard IDE controller (VIA vt8235). Within 4 days running the raid1, I got those three errors pasted below, each marking the SATA-raidmember as faulty. After "raidhotremove" and "raidhotadd" the SATA-raidmember syncs again fine and works at least a day until it is marked as faulty again. Any pointers where I could look at to resolve this problem? The SATA drive is a new Seagate ST3250823AS. I would change out your cables, and also make sure you are running 2.6.11-rc3-bk-latest, which includes all the SATAII patches and other fixes. JEff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] device-mapper: multipath
On Fri, Feb 11, 2005 at 01:36:32PM -0800, Andrew Morton wrote: > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > +EXPORT_SYMBOL(dm_register_path_selector); > > > +EXPORT_SYMBOL(dm_unregister_path_selector); > Yup, this should be _GPL. Yup - and the same applies to the other exports. Alasdair -- [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] tone down pci=routeirq message
Tone down the message about using "pci=routeirq". I do still get
a few reports, but most are now prompted just by the fact that
my email address appears in dmesg in an "error-type" message.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= arch/i386/pci/acpi.c 1.18 vs edited =
--- 1.18/arch/i386/pci/acpi.c 2004-10-18 22:44:01 -06:00
+++ edited/arch/i386/pci/acpi.c 2005-02-11 15:30:22 -07:00
@@ -37,21 +37,12 @@
* also do it here in case there are still broken drivers that
* don't use pci_enable_device().
*/
- printk(KERN_INFO "** Routing PCI interrupts for all devices
because \"pci=routeirq\"\n");
- printk(KERN_INFO "** was specified. If this was required to
make a driver work,\n");
- printk(KERN_INFO "** please email the output of \"lspci\" to
[EMAIL PROTECTED]");
- printk(KERN_INFO "** so I can fix the driver.\n");
+ printk(KERN_INFO "PCI: Routing PCI interrupts for all devices
because \"pci=routeirq\" specified\n");
while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) !=
NULL)
acpi_pci_irq_enable(dev);
- } else {
- printk(KERN_INFO "** PCI interrupts are no longer routed
automatically. If this\n");
- printk(KERN_INFO "** causes a device to stop working, it is
probably because the\n");
- printk(KERN_INFO "** driver failed to call pci_enable_device().
As a temporary\n");
- printk(KERN_INFO "** workaround, the \"pci=routeirq\" argument
restores the old\n");
- printk(KERN_INFO "** behavior. If this argument makes the
device work again,\n");
- printk(KERN_INFO "** please email the output of \"lspci\" to
[EMAIL PROTECTED]");
- printk(KERN_INFO "** so I can fix the driver.\n");
- }
+ } else
+ printk(KERN_INFO "PCI: If a device doesn't work, try
\"pci=routeirq\". If it helps, post a report\n");
+
#ifdef CONFIG_X86_IO_APIC
if (acpi_ioapic)
print_IO_APIC();
= arch/ia64/pci/pci.c 1.67 vs edited =
--- 1.67/arch/ia64/pci/pci.c2005-01-25 14:23:42 -07:00
+++ edited/arch/ia64/pci/pci.c 2005-02-11 15:28:22 -07:00
@@ -160,21 +160,11 @@
* also do it here in case there are still broken drivers that
* don't use pci_enable_device().
*/
- printk(KERN_INFO "** Routing PCI interrupts for all devices
because \"pci=routeirq\"\n");
- printk(KERN_INFO "** was specified. If this was required to
make a driver work,\n");
- printk(KERN_INFO "** please email the output of \"lspci\" to
[EMAIL PROTECTED]");
- printk(KERN_INFO "** so I can fix the driver.\n");
+ printk(KERN_INFO "PCI: Routing interrupts for all devices
because \"pci=routeirq\" specified\n");
for_each_pci_dev(dev)
acpi_pci_irq_enable(dev);
- } else {
- printk(KERN_INFO "** PCI interrupts are no longer routed
automatically. If this\n");
- printk(KERN_INFO "** causes a device to stop working, it is
probably because the\n");
- printk(KERN_INFO "** driver failed to call pci_enable_device().
As a temporary\n");
- printk(KERN_INFO "** workaround, the \"pci=routeirq\" argument
restores the old\n");
- printk(KERN_INFO "** behavior. If this argument makes the
device work again,\n");
- printk(KERN_INFO "** please email the output of \"lspci\" to
[EMAIL PROTECTED]");
- printk(KERN_INFO "** so I can fix the driver.\n");
- }
+ } else
+ printk(KERN_INFO "PCI: If a device doesn't work, try
\"pci=routeirq\". If it helps, post a report\n");
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ext2/3 32-bit stat() wrap for ~2TB files
On Feb 11, 2005 21:39 +, Stephen C. Tweedie wrote:
> ...i_blocks is counted in fs blocksize units, so we're nowhere near
> overflowing that. It's only when stat() converts it to st_blocks'
> 512-byte units that we get into trouble within the kernel.
Umm, I don't think so. ext3 i_blocks is sectors and not fs blocks (one of
my pet peeves actually). In 2.4 it is as below, 2.6 has one more copy.
ext3_read_inode()
{
:
inode->i_blocks = le32_to_cpu(raw_inode->i_blocks);
cp_new_stat()
{
:
tmp.st_blocks = inode->i_blocks;
I've wondered at times whether it might make sense to store i_blocks in
fs blocksize units when we add some new feature (e.g. high bits for
i_blocks if we overflow 2^32) but I'm not sure the increased complexity
makes up for the minor increase in dynamic range.
In the end, we hit the 2^64 fs size limit before we would run out of
range for i_blocks (assuming 64 bits there) so changing it doesn't help
much. The only reason to change would be to store up to 2^48 fs blocks
(only using 16 bits in the core inode, e.g. i_frag + i_fsize) and assume
we need to use 2^16 blocksize for the largest files with extents.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
pgpUNyrXspuZc.pgp
Description: PGP signature
Re: How to disable slow agpgart in kernel config?
On Friday 11 February 2005 22:19, Terence Ripperda wrote: > > > I just read through the nVidia readme file, and there is a > > > comprehensive section on what module to use for what chipset (and > > > card). It recommends using the nVagp for my setup, > > is that the "CONFIGURING AGP" appendix? I didn't think that we > recommended which agp driver to use. the intention was just to > document which chipsets are supported by nvagp and point out that > agpgart may/probably supports more chipsets. that section also > documents some hardware 'issues' that we work around. we work around > these issues regardless of which agp driver is being used. Thats the one. I read this in APPENDIX F: "The following AGP chipsets are supported by NVIDIA's AGP; for all other chipsets it is recommended that you use the AGPGART module." as saying 'if you have one of these chipsets use nVagp' else use agpgart. > for this via kt133 issue, I looked through the agpgart and nvagp > initializations and didn't see anything much different. both > initialize and flush gart mappings the same way. both seem to allocate > memory the same way (nvagp uses __get_free_pages, which eventually > calls alloc_pages) with the GFP_KERNEL flag. I'm not sure why there > would be much difference between the two. I have had no issue at all running agpgart on Slackware 10 with KDE 3.3.x. It was just when I read this thread I didn't realise there was another option of a different NV module. I just tried it after reading deeper in the readme.txt ref. the Quake2 OpenGL 'rippling wave' I get every 5 minutes or so. It fixed it, BTW. I now have a constant clear display 100% in Quake2 :) I haven't noticed any difference at all in 2d desktop stuff (except maybe it is slightly brighter). Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc/*/statm, exactly what does "shared" mean?
Hello, I can't seem to find clear documentation about the 'share' column from /proc//statm. Does this include pages that are shared with forked children marked as copy-on-write? Does this only reflect libraries that are dynamically loaded? What about shared memory segments/mmaps (ala shmat or mmmap)? If there is a place where I might find documentation that is more clear beyond the proc.txt in the kernel docs and then man pages for procfs, I'd welcome a pointer. Thanks, -- Richard F. Rebel cat /dev/null > `tty` signature.asc Description: This is a digitally signed message part
Re: How to disable slow agpgart in kernel config?
On Fri, Feb 11, 2005 at 01:48:21PM -0500, [EMAIL PROTECTED] wrote: > On Fri, Feb 11, 2005 at 06:04:06PM +, Nick Warne wrote: > > > > > This surprises me, especially considering the in-kernel nvidia-agp > driver > > > > was actually written by NVidia. Are there any agp error messages in > > > > your dmesg / X log ? > > > > > With the nVidia own nv_agp it appears directly in all apps, very fast > > > under GNOME 2.8.1. Why, I do not know. Also game (opengl) performance is > > > faster with the nv_agp, that I haven't used the kernel agp for months, > now. > > > > This is interesting. I always used agpgart without a second thought > (2.4.29, > > GeForce4 MX with Via KT133 chipset). > > > > I just read through the nVidia readme file, and there is a comprehensive > > section on what module to use for what chipset (and card). It recommends > > using the nVagp for my setup, so I just rebuilt excluding agpgart so I can > > use the nVdia module. > > > > I never had slowness as such in KDE or X apps, but playing quake2 openGL I > > used to get a 'wave' type effect rippling down the screen occasionally. A > > quick test using the nVagp module to have fixed that... > > Terrence, any ideas ? I would agree with your assessment Dave, there's very little difference betweeen the agp drivers. it's possible nvagp tweaks some register values that agpgart doesn't, I'd have to look closer at both to know. that might explain *modest* performance differences, but certainly wouldn't explain the dramatic performance differences the original poster described. I wouldn't expect even falling back to pci dma would have this big of an impact on 2d performance, but perhaps there's enough bus activity for this to happen. Marcus, can you verify that you're actually using agpgart in that situation? do you possibly have our XF86Config option set to nvagp only? (with IOMMU compiled in or agpgart loaded, our driver won't allow nvagp) you can verify whether agp is enabled with this command when our driver is loaded and X is started up: % cat /proc/drivers/nvidia/agp/status Status: Disabled (hmm, turns out my own dev machine doesn't have agp enabled and 2d performance isn't very noticeable) > > I just read through the nVidia readme file, and there is a comprehensive > > section on what module to use for what chipset (and card). It recommends > > using the nVagp for my setup, is that the "CONFIGURING AGP" appendix? I didn't think that we recommended which agp driver to use. the intention was just to document which chipsets are supported by nvagp and point out that agpgart may/probably supports more chipsets. that section also documents some hardware 'issues' that we work around. we work around these issues regardless of which agp driver is being used. for this via kt133 issue, I looked through the agpgart and nvagp initializations and didn't see anything much different. both initialize and flush gart mappings the same way. both seem to allocate memory the same way (nvagp uses __get_free_pages, which eventually calls alloc_pages) with the GFP_KERNEL flag. I'm not sure why there would be much difference between the two. > (It'd be really nice to get your PAT support in 2.6 sometime too btw). I've been meaning to finish that up. the actual PAT support is pretty simple; it's the protecting against cache aliasing that's a bit tricky and involved. for our push buffers, we don't worry too much about the cache aliasing, since change_page_attr() marks the kernel mapping uncached, and there shouldn't be any other mappings to the memory. mapping i/o regions like the framebuffer is a bit riskier, since it's more likely someone else has a conflicting mapping to it, but the damage of data corruption is much less fatal. Thanks, Terence - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ppc64: Implement a vDSO and use it for signal trampoline #3
On Fri, 2005-02-11 at 19:10 +0100, Hans-Peter Jansen wrote: > Hi Ben, > > are you copyrighting under a new pseudonym? E.g.: > > On Thursday 10 February 2005 03:32, Benjamin Herrenschmidt wrote: > > === > > --- /dev/null 1970-01-01 00:00:00.0 + > > +++ linux-work/arch/ppc64/kernel/vdso32/sigtramp.S 2005-02-02 > > 13:28:01.0 +1100 @@ -0,0 +1,300 @@ > > +/* > > + * Signal trampolines for 32 bits processes in a ppc64 kernel for > > + * use in the vDSO > > + * > > + * Copyright (C) 2004 Benjamin Herrenschmuidt > ^ > > --- /dev/null 1970-01-01 00:00:00.0 + > > +++ linux-work/arch/ppc64/kernel/vdso32/datapage.S 2005-02-02 > > 13:28:01.0 +1100 @@ -0,0 +1,68 @@ > > +/* > > + * Access to the shared data page by the vDSO & syscall map > > + * > > + * Copyright (C) 2004 Benjamin Herrenschmuidt > > Who's that guy? Hehe, good catch, I'll fix that :) Thanks, 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: out-of-line x86 "put_user()" implementation
Followup to: <[EMAIL PROTECTED]> By author:Richard Henderson <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Tue, Feb 08, 2005 at 06:27:08PM -0800, Linus Torvalds wrote: > > That brings up another issue: if I don't care which registers a 64-bit > > value goes into, can I get the "low reg" and "high reg" names some way? > > Nope. We never needed one in the i386 backend itself, so we never > added anything like that. > I would really like to see that feature. I've missed it more than a few times. -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: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 11, 2005 at 11:06:57PM +0100, Erik van Konijnenburg wrote: > For an old version of the idea, see > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284294 Very nice stuff. Ok, that's a good reason not to get rid of these files, although they can be generated on the fly from the modules themselves (like depmod does it.) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] de214x.c uses uninitialized pci_dev->irq
applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 11, 2005 at 01:49:57PM -0800, Greg KH wrote: > On Fri, Feb 11, 2005 at 10:37:31PM +0100, Erik van Konijnenburg wrote: > > On Fri, Feb 11, 2005 at 11:23:23AM -0800, Greg KH wrote: > > > On Fri, Feb 11, 2005 at 12:01:54PM -0700, Erik Andersen wrote: > > > > On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote: > > > > > It's not only pci, but all types of busses need this kind of > > > > > "coldplug" > > > > > functionality. And yes, I have plans to provide that functionality in > > > > > this package too. > > > > > > > > > > In fact, if anyone looking to contribute some well defined and easy to > > > > > test code... :) > > > > > > > > The pcimodules patch to pciutils does this sortof coldplug device > > > > scanning for pci devices: > > > > http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch > > > > > > Yes, but that uses the modules.pcimap files, which we want to get rid of > > > someday. It also uses the /proc/pci interface instead of sysfs, so it > > > probably doesn't handle machines with pci domains very well... > > > > Could you give pointers to the "get rid of modules.pcimap" discussion? > > Search linux-kernel for it. It's come up many times between me and > Rusty Russell. He's basically waiting for the hotplug scripts (or > whatever) to be fixed up enough to not need them anymore. > > Do you have some other need for them? Yep, I'm working on a proof of concept to show how modules.pcimap can be used to build a more reliable mkinitrd. The interesting part about modules.pcimap is that it can not only describe what's in the running kernel, but also what's in the kernel about to be installed. For an old version of the idea, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284294 Regards, Erik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sundance.c: high interrupt load [resent]
applied to netdev-2.6 so it can get some testing and review. Please send patches according to the format described at http://linux.yyz.us/patch-format.html Particularly, patches should apply with "patch -p1" and should include a signed-off-by line. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ppc32: Fix PCI2 support on MPC8555/41 CDS systems
Andrew,
The following patch fixes an issue related to the second PCI host
controller working on MPC8555/41 systems. If possible we should get this
in before 2.6.11.
Keep track of the last PCI bus number on PCI1 so that the PCI2 host
controller can properly exclude itself at the right time, exclusion should
occur after initial setup so that the early pci config cycles in setting
PCI2 actually get to the controller.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-02-10 18:33:44
-06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-02-10 18:33:44
-06:00
@@ -281,16 +281,17 @@
#define ARCADIA_HOST_BRIDGE_IDSEL 17
#define ARCADIA_2ND_BRIDGE_IDSEL 3
+extern int mpc85xx_pci1_last_busno;
+
int
mpc85xx_exclude_device(u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
#ifdef CONFIG_85xx_PCI2
- /* With the current code we know PCI2 will be bus 2, however this may
-* not be guarnteed */
- if (bus == 2 && PCI_SLOT(devfn) == 0)
- return PCIBIOS_DEVICE_NOT_FOUND;
+ if (mpc85xx_pci1_last_busno)
+ if (bus == (mpc85xx_pci1_last_busno + 1) && PCI_SLOT(devfn) ==
0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
#endif
/* We explicitly do not go past the Tundra 320 Bridge */
if (bus == 1)
diff -Nru a/arch/ppc/syslib/ppc85xx_setup.c b/arch/ppc/syslib/ppc85xx_setup.c
--- a/arch/ppc/syslib/ppc85xx_setup.c 2005-02-10 18:33:44 -06:00
+++ b/arch/ppc/syslib/ppc85xx_setup.c 2005-02-10 18:33:44 -06:00
@@ -243,6 +243,8 @@
}
#endif /* CONFIG_85xx_PCI2 */
+int mpc85xx_pci1_last_busno = 0;
+
void __init
mpc85xx_setup_hose(void)
{
@@ -341,6 +343,9 @@
IORESOURCE_IO, "PCI2 host bridge");
hose_b->last_busno = pciauto_bus_scan(hose_b, hose_b->first_busno);
+
+ /* let board code know what the last bus number was on PCI1 */
+ mpc85xx_pci1_last_busno = hose_a->last_busno;
#endif
return;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt starvation points
On Fri, 2005-02-11 at 12:04, Russell King wrote: > > Please substantiate your claim that up() is very expensive on ARM. > I disagree: I should have made it clear that I was talking about the RT version of up() . The RT version doesn't have any assembly in it, and it is expensive. > Plus, after you've read the above code, wouldn't you think that adding > the "enable interrupts + disable interrupts" around an up() operation > (which itself immediately disables interrupts again) is just adding > extra instructions to the kernel, which corresponds directly to lower > performance? Not in the RT case. However, I never said that was a proper fix, I was just producing code that helped in my tests. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 11, 2005 at 10:37:31PM +0100, Erik van Konijnenburg wrote: > On Fri, Feb 11, 2005 at 11:23:23AM -0800, Greg KH wrote: > > On Fri, Feb 11, 2005 at 12:01:54PM -0700, Erik Andersen wrote: > > > On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote: > > > > It's not only pci, but all types of busses need this kind of "coldplug" > > > > functionality. And yes, I have plans to provide that functionality in > > > > this package too. > > > > > > > > In fact, if anyone looking to contribute some well defined and easy to > > > > test code... :) > > > > > > The pcimodules patch to pciutils does this sortof coldplug device > > > scanning for pci devices: > > > http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch > > > > Yes, but that uses the modules.pcimap files, which we want to get rid of > > someday. It also uses the /proc/pci interface instead of sysfs, so it > > probably doesn't handle machines with pci domains very well... > > Could you give pointers to the "get rid of modules.pcimap" discussion? Search linux-kernel for it. It's come up many times between me and Rusty Russell. He's basically waiting for the hotplug scripts (or whatever) to be fixed up enough to not need them anymore. Do you have some other need for them? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
Ingo,
Here's a trivial patch to help others from freaking out when they see on
a show_trace that most of their processes are TASK_UNINTERRUPTIBLE.
Index: kernel/sched.c
===
--- kernel/sched.c (revision 75)
+++ kernel/sched.c (working copy)
@@ -4489,7 +4489,7 @@
task_t *relative;
unsigned state;
unsigned long free = 0;
- static const char *stat_nam[] = { "R", "S", "D", "T", "t", "Z", "X" };
+ static const char *stat_nam[] = { "R", "M", "S", "D", "T", "t", "Z",
"X" };
printk("%-13.13s [%p]", p->comm, p);
state = p->state ? __ffs(p->state) + 1 : 0;
I figure that "M" would be a good fit for TASK_RUNNING_MUTEX.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] device-mapper: multipath
On Fri, Feb 11, 2005 at 01:36:32PM -0800, Andrew Morton wrote: > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > > +EXPORT_SYMBOL(dm_register_path_selector); > > > +EXPORT_SYMBOL(dm_unregister_path_selector); > > > > I though we agreed to only allow GPL'ed path selectors at OSDL? > > (OSDL?) Argg, I meant OLS, sorry. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext2/3 32-bit stat() wrap for ~2TB files
Hi, On Fri, 2005-02-11 at 21:27, Andreas Dilger wrote: > > Trouble is, that limit *should* be an i_blocks limit, because i_blocks > > is still 32-bits, and (more importantly) is multiplied by the fs > > blocksize / 512 in stat(2) to return st_blocks in 512-byte chunks. > > Overflow 2^32 sectors in i_blocks and stat(2) wraps. > > I agree. The problem AFAIR is that the i_blocks accounting is done in > the quota code, so it was a challenge to get it right, and the i_size > limit was easier to do. The i_size limit is also wrong for dense files; I'd be satisfied with just getting it right! i_blocks handling through the quota calls is cleaner these days, but I don't think that's a particularly satisfactory solution --- reaching maximum file size has all sorts of specific semantics such as sending SIGXFSZ which you don't really want to have to replicate. > Until now I don't think anyone has created > dense 2TB files, so the sparse limit was enough. Yep. > Note also that there was a patch to extend i_blocks floating around > (pretty small hack to use one of the reserved fields), and it might make > sense to get this into the kernel before we actually need it. True, but it's not really a problem right now --- i_blocks is counted in fs blocksize units, so we're nowhere near overflowing that. It's only when stat() converts it to st_blocks' 512-byte units that we get into trouble within the kernel. > > if (res > (512LL << 32) - (1 << bits)) > > res = (512LL << 32) - (1 << bits); > > So, for the quick fix we could reduce this by the number of expected > [td]indirect blocks and submit that to 2.4 also. Agreed. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 11, 2005 at 11:23:23AM -0800, Greg KH wrote: > On Fri, Feb 11, 2005 at 12:01:54PM -0700, Erik Andersen wrote: > > On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote: > > > It's not only pci, but all types of busses need this kind of "coldplug" > > > functionality. And yes, I have plans to provide that functionality in > > > this package too. > > > > > > In fact, if anyone looking to contribute some well defined and easy to > > > test code... :) > > > > The pcimodules patch to pciutils does this sortof coldplug device > > scanning for pci devices: > > http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch > > Yes, but that uses the modules.pcimap files, which we want to get rid of > someday. It also uses the /proc/pci interface instead of sysfs, so it > probably doesn't handle machines with pci domains very well... Could you give pointers to the "get rid of modules.pcimap" discussion? Thanks. Erik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] device-mapper: multipath
Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > +EXPORT_SYMBOL(dm_register_path_selector); > > +EXPORT_SYMBOL(dm_unregister_path_selector); > > I though we agreed to only allow GPL'ed path selectors at OSDL? (OSDL?) Yup, this should be _GPL. Anything which uses these exports is a derived work, isn't it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext2/3 32-bit stat() wrap for ~2TB files
On Feb 11, 2005 20:52 +, Stephen C. Tweedie wrote:
> /*
> * Maximal file size. There is a direct, and {,double-,triple-}indirect
> * block limit, and also a limit of (2^32 - 1) 512-byte sectors in i_blocks.
> * We need to be 1 filesystem block less than the 2^32 sector limit.
> */
>
> Trouble is, that limit *should* be an i_blocks limit, because i_blocks
> is still 32-bits, and (more importantly) is multiplied by the fs
> blocksize / 512 in stat(2) to return st_blocks in 512-byte chunks.
> Overflow 2^32 sectors in i_blocks and stat(2) wraps.
I agree. The problem AFAIR is that the i_blocks accounting is done in
the quota code, so it was a challenge to get it right, and the i_size
limit was easier to do. Until now I don't think anyone has created
dense 2TB files, so the sparse limit was enough.
Fixing this to count i_blocks correctly would also allow us to have
larger sparse files (up to the indirect limit).
Note also that there was a patch to extend i_blocks floating around
(pretty small hack to use one of the reserved fields), and it might make
sense to get this into the kernel before we actually need it.
> But i_blocks includes indirect blocks as well as data, so for a
> non-sparse file we wrap stat(2) st_blocks well before the file is
> 2^32*512 bytes long. Yet ext3_max_size() doesn't understand this:
> it simply caps the size with
>
> if (res > (512LL << 32) - (1 << bits))
> res = (512LL << 32) - (1 << bits);
So, for the quick fix we could reduce this by the number of expected
[td]indirect blocks and submit that to 2.4 also.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
pgpgDW3JowkjV.pgp
Description: PGP signature
Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
On Thu, 2005-02-03 at 22:41 +0100, Ingo Molnar wrote: > > > > It's clever that they do that, but additional control is needed in the > > future. jackd isn't the most sophisticate media app on this planet (not > > too much of an insult :)) [...] > > i think you are underestimating Jack - it is easily amongst the most > sophisticated audio frameworks in existence, and it certainly has one of > the most robust designs. Just shop around on google for Jack-based audio > applications. What i'd love to see is more integration (and cooperation) > between the audio frameworks of desktop projects (KDE, Gnome) and Jack. JACK was not designed as a general purpose sound server, it's main goals were sample accurate synchronization and low latency which a general purpose desktop sound server does not need. But, JACK does provide a superset of the needed functionality - if you can do low latency you should be able to handle high latency/buffering jut as easily, and sample accurate sync will not break apps that don't need it. The main obstacle to JACK-ifying everything is that it requires audio apps to conform to the callback based JACK programming model. JACK-ifying a complex app that expects to be able to read and write audio whenever it wants to amounts to a complete rewrite. But simpler apps like XMMS can use a layer on top of JACK like the bio2jack library. Anyway, Linspire (formerly L*nd*ws, formerly ...) will be using JACK as the sound server in their next release. And GNOME is moving to gstreamer which can use JACK as a backend. Bill has a good point, in that JACK is really just scratching the surface as far as the myriad possibilities that good realtime support will open up. Apps like mplayer that use a broken single threaded design which completely ignores the RT constraint inherent in AV playback will be corrected for example. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tg3: capacitive coupling detection fix
On Fri, 2005-02-11 at 12:44 -0800, Michael Chan wrote: > This patch fixes the problem reported in: > > http://marc.theaimsgroup.com/?l=linux-kernel=110798711911645=2 > > > The 5700 link problem was caused by reading uninitialized values in sram and > causing capacitive coupling mode to be enabled by mistake. This patch fixes > the problem by properly validating the sram contents. Verified as working on the x440 I was seeing the trouble with. Thanks! -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc3 05/11] ide: fixes io_32bit race in ide_taskfile_ioctl()
applied to ide-dev-2.6, thanks I need some more time for the other patches - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] tg3: capacitive coupling detection fix
On Fri, 11 Feb 2005 12:44:10 -0800 "Michael Chan" <[EMAIL PROTECTED]> wrote: > This patch fixes the problem reported in: > > http://marc.theaimsgroup.com/?l=linux-kernel=110798711911645=2 > > The 5700 link problem was caused by reading uninitialized values in sram and > causing capacitive coupling mode to be enabled by mistake. This patch fixes > the problem by properly validating the sram contents. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied, thanks a lot 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/
Self-destruct in 5 seconds?
Hi, I posted this to the linux-arm mailing list, and Russell King referred me to the main list. I'm running an AT91RM9200DK-based board with the 2.6.10 kernel. I'm trying to use TmpFS for my root so I don't have a hard-coded ramdisk size. My /linuxrc script looks something like this: mount -t tmpfs tmpfs /mnt/tmp mkdir /mnt/tmp/initrd [ copy files from / to /mnt/tmp ] mount -t devfs devfs /mnt/tmp/dev echo "Changing mount points..." cd /mnt/tmp pivot_root . initrd cd / mount -t proc proc /proc exec chroot . /sbin/init dev/console 2>&1 Init then kicks off a "sysinit" script that immediately does this: echo "Unmounting old root..." umount /initrd echo "Freeing initrd..." freeramdisk /dev/rd/0 This actually works fine. The system boots properly, my memory usage looks good, etc. But this is what prints to the screen, and it's pretty scary looking: Unmounting old root... VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... Freeing initrd... Although things seem to work [consistently - it does it every time during boot], this message frightens me. Is it safe to ignore, or is my embedded device about to self-destruct? :) Thanks for the help -- Matthew L. Creech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt starvation points
On Fri, Feb 11, 2005 at 09:05:21AM -0800, Daniel Walker wrote:
> The other patch enabled interrupt before calling up on
> kernel_sem ..This one could use some thinking over. I did this cause
> up() is very expensive on ARM , and combined with the looping above
> interrupts can stay off for a long time ..
Please substantiate your claim that up() is very expensive on ARM.
I disagree:
#define __up_op(ptr,wake) \
({ \
__asm__ __volatile__( \
"@ up_op\n" \
" mrs ip, cpsr\n" \
" orr lr, ip, #128\n" \
" msr cpsr_c, lr\n" \
" ldr lr, [%0]\n" \
" addslr, lr, %1\n" \
" str lr, [%0]\n" \
" msr cpsr_c, ip\n" \
" movle ip, %0\n" \
" blle" #wake \
: \
: "r" (ptr), "I" (1)\
: "ip", "lr", "cc", "memory"); \
})
static inline void up(struct semaphore * sem)
{
__up_op(sem, __up_wakeup);
}
Looks like 9 instructions for the uncontended case to me. If you're
worried about 9 instructions being expensive, please work on GCC to
improve its optimisation capabilities first. There's room there for
improvement across the whole kernel than just the above 9 instructions.
Plus, after you've read the above code, wouldn't you think that adding
the "enable interrupts + disable interrupts" around an up() operation
(which itself immediately disables interrupts again) is just adding
extra instructions to the kernel, which corresponds directly to lower
performance?
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to disable slow agpgart in kernel config?
Dave Jones wrote: > *shrug*, if the nvidia module is properly configured, it should make no difference at all. AGPGART operation isn't a performance critical thing, as the hardware does 99% of the work. Yes, that was also my opinion, but after using AGPGART, hmm. And it was on my last 32 bit FC2 systems with other hardware the same slow operations on the desktop. And I'm not alone, there are some nvnews.net linux forum users which report the same slow performance with AGPGART. Maybe the linux kernel AGPGART do not run well with the nVidia 2D acceleration renderer or the kernel driver and is a nvidia problem. http://www.marcush.de/Xorg.0.log Greetings, Marcus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 11, 2005 at 09:06:40PM +0100, Harald Dunkel wrote: > Greg KH wrote: > >I'd like to announce, yet-another-hotplug based userspace project: > >linux-ng. This collection of code replaces the existing linux-hotplug > >package with very tiny, compiled executable programs, instead of the > >existing bash scripts. > > > > cpio is running to setup a test partition. > > But one question: This is yet another package with its > own private copy of klibc. Whats the reason behind this > non-modular approach? Because we don't have an easy way yet to build against a copy of klibc on a system? For right now, it's the simplest way to ensure that it works for everyone, once klibc moves into the kernel tree I can remove it from udev and hotplug-ng. Is it causing problems for you? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ext2/3 32-bit stat() wrap for ~2TB files
Hi all,
In testing large (>4TB) device support on 2.6, I've been using a simple
write/verify test to check both block device and regular file
correctness.
Set to write 1MB poison patterns for the whole of a file until EOF is
encountered, it worked just fine on ext3: the file got a short write on
the last write, leaving the file at its largest permitted size of
0x1fff000 (2^32 sectors minus a page.) Verify works fine.
This 2^32 sector limit is set in ext3_max_size(), which has the comment
/*
* Maximal file size. There is a direct, and {,double-,triple-}indirect
* block limit, and also a limit of (2^32 - 1) 512-byte sectors in i_blocks.
* We need to be 1 filesystem block less than the 2^32 sector limit.
*/
Trouble is, that limit *should* be an i_blocks limit, because i_blocks
is still 32-bits, and (more importantly) is multiplied by the fs
blocksize / 512 in stat(2) to return st_blocks in 512-byte chunks.
Overflow 2^32 sectors in i_blocks and stat(2) wraps.
But i_blocks includes indirect blocks as well as data, so for a
non-sparse file we wrap stat(2) st_blocks well before the file is
2^32*512 bytes long. Yet ext3_max_size() doesn't understand this:
it simply caps the size with
if (res > (512LL << 32) - (1 << bits))
res = (512LL << 32) - (1 << bits);
so write() keeps writing past the wrap, resulting in a file which looks
like:
[EMAIL PROTECTED] scratch]# ls -lh verif-file9.tmp
-rw-r--r-- 1 root root 2.0T Feb 10 05:49 verif-file9.tmp
[EMAIL PROTECTED] scratch]# du -h verif-file9.tmp
2.1Gverif-file9.tmp
Worse comes at e2fsck time: near the end of walking the indirect tree,
e2fsck decides that the file has grown too large, as in this fsck -n
output:
Pass 1: Checking inodes, blocks, and sizes
Inode 20 is too big. Truncate? no
Block #536346622 (980630816) causes file to be too big. IGNORED.
Block #536346623 (980630817) causes file to be too big. IGNORED.
Block #536346624 (980630818) causes file to be too big. IGNORED.
...
Whoops. e2fsck sees that st_blocks is too large at this point, and
decides that it wants to truncate the file to make it fit. So if a user
has legitimately created such a file, fsck will effectively attempt to
corrupt it at the next fsck.
So who is right? Should ext3 let the file grow that large?
For now, I think we need to constrain ext2/3 files so that i_blocks does
not exceed 2^32*512/blocksize. Even if we fix up all the stat() stuff
to pass back 64-bit st_blocks, we still have every e2fsck in existence
which will not be able to deal with those files. Eventually 64-bit
st_blocks would be good to have, but it needs to have a fs feature flag
to let e2fsck know about it.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] tg3: capacitive coupling detection fix
This patch fixes the problem reported in: http://marc.theaimsgroup.com/?l=linux-kernel=110798711911645=2 The 5700 link problem was caused by reading uninitialized values in sram and causing capacitive coupling mode to be enabled by mistake. This patch fixes the problem by properly validating the sram contents. Signed-off-by: Michael Chan <[EMAIL PROTECTED]> tg3_cap_cpling.patch Description: tg3_cap_cpling.patch
Re: Latest ext3 patches (extents, mballoc, delayed allocation)
Good day all, I've updated the patchset against 2.6.10. A bunch of bugs have been fixed and mballoc now behaves smarter a bit. Extents and mballoc patches collects some stats they print upon umount. NOTE: they must not be used to store important data. A lot of things are to be done. Please review. Any comments and suggestions are very welcome. The patches are too big to send in a message (previous time they got rejected). I put them in ftp://ftp.clusterfs.com/pub/people/alex/2.6.10 The following names are used: ext3rs - ext3 mounted with data=writeback,reservation options ext3i - ext3 mounted with extents,mballoc,delalloc options reiser - reiserfs v3 I did some benchmarking. Two systems were used: SMP - dual PIII-1GHz, 1GB, FC-connected to 2 disks raid0 UP - PIII-933MHz, 256MB, FC-connected to 2 disks raid0 The tests dd500 and dd1000 generate 500M and 1000M using dd on fresh fs. Real time varies run from run because of disks, but sys.time is stable. SMPUP TEST / FS real sys real sys dd500/ext2 - 9.14 2.3319.03 2.50 dd500/ext3 - 12.23 4.0618.99 4.19 dd500/ext3rs- 13.39 4.0115.08 4.16 dd500/ext3i - 9.19 2.3119.07 2.52 dd500/reiser- 7.95 2.8721.23 3.09 dd500/xfs - 17.88 2.4219.25 2.67 dd1000/ext2 - 37.47 4.6944.59 5.02 dd1000/ext3 - 38.03 7.9040.77 8.31 dd1000/ext3rs - 34.62 7.9540.51 8.30 dd1000/ext3i- 33.73 4.6538.74 4.93 dd1000/reiser - 29.29 5.7944.88 6.08 dd1000/xfs - 37.11 5.0339.98 5.27 The test untar unpacks linux-2.6.0.tar: SMP UP TEST / FS real sys real sys untar/ext2 - 9.21 2.4727.31 2.57 untar/ext3 - 15.63 3.3834.54 3.61 untar/ext3rs- 15.91 3.2735.98 3.65 untar/ext3i - 8.33 2.7016.75 2.84 untar/reiser- 13.38 5.4725.88 5.96 untar/xfs - 44.62 5.6451.92 4.88 The next test is dbench: SMP UP TEST / FS real sys MB/s real sys MB/s dbench1/ext2- 5.87 1.4363.72565.93 1.5463.79 dbench1/ext3- 2.46 1.75139.7943.60 1.85131.372 dbench1/ext3rs - 2.46 1.73140.3783.55 1.85133.071 dbench1/ext3i - 2.19 1.48156.9762.28 1.53150.403 dbench1/reiser - 2.80 2.05122.7612.88 2.11119.815 dbench1/xfs - 2.83 1.81122.1592.87 1.91119.564 dbench4/ext2- 4.99 7.13274.2169.96 6.22137.316 dbench4/ext3- 5.79 8.64236.85811.49 7.40130.146 dbench4/ext3rs - 5.80 8.57236.35611.45 7.38130.467 dbench4/ext3i - 5.16 7.16265.6219.25 6.31147.872 dbench4/reiser - 7.11 10.85 192.49111.85 8.59115.392 dbench4/xfs - 6.60 8.88207.59911.98 7.69114.177 dbench8/ext2- 16.04 14.27 181.93 18.32 12.14 149.228 dbench8/ext3- 18.87 17.04 165.21423.77 14.88 119.995 dbench8/ext3rs - 11.52 17.21 237.64723.35 15.04 123.088 dbench8/ext3i - 11.20 14.66 268.05221.00 12.49 130.223 dbench8/reiser - 13.92 21.65 196.30624.98 17.67 114.083 dbench8/xfs - 14.84 18.23 184.26325.84 15.53 105.743 dbench16/ext2 - 20.39 28.79 267.97947.37 25.13 115.582 dbench16/ext3 - 25.69 34.54 212.74553.43 30.78 102.266 dbench16/ext3rs - 24.47 34.36 223.37 54.68 30.44 100.082 dbench16/ext3i - 22.94 29.40 238.21544.89 25.73 121.962 dbench16/reiser - 28.56 43.86 191.40756.48 36.41 96.9686 dbench16/xfs- 33.49 36.94 163.15978.68 32.56 69.4764 dbench32/ext2 - 43.54 58.87 250.947108.1 51.24 101.354 dbench32/ext3 - 61.83 70.66 176.707139.84 63.77 78.8818 dbench32/ext3rs - 67.24 71.69 162.651145.03 63.38 75.5155 dbench32/ext3i - 55.29 59.41 197.757100.24 52.50 109.26 dbench32/reiser - 76.32 93.45 143.127128.77 77.94 85.7179 dbench32/xfs- 119.4 88.09 91.4746670.45 76.19 16.298 The followins crazy listing shows tiobench's results for SMP box: Sequential Reads File Blk Num Avg CPU IdentifierSize Size Thr Rate (CPU%) Latency Eff -- - --- -- -- - - ext2 512 40961 40.95 12.80% 0.095 320 ext3 512 40961 45.03 13.99% 0.086 322 ext3rs512 40961 50.53
Re: [PATCH] general split_vma hugetlb fix
On Fri, Feb 11, 2005 at 08:06:08PM +, Hugh Dickins wrote: > My recent do_munmap hugetlb fix has proved inadequate. There are > other places (madvise, mbind, mlock, mprotect) where split_vma is > called. Only mprotect excludes a hugetlb vma: the others are in > danger of splitting at a misaligned address, causing later BUGs. > So move the ~HPAGE_MASK check from do_munmap to split_vma itself; > and fix up those places (madvise and mlock) which expect split_vma > can fail only with -ENOMEM, and wish to convert that to -EAGAIN. > (It appears genuine that some of these syscalls should be failing > with -ENOMEM and some with -EAGAIN, so respect those behaviours.) > madvise_dontneed doesn't use split_vma, but is equally in danger > of causing a hugetlb BUG via zap_page_range. Whereas elsewhere the > patch is permissive (allowing the operation on a hugetlb vma even when > pointless, so long as it doesn't missplit it), here we must use -EINVAL > on any hugetlb vma, since a page fault would hit the BUG in its nopage. > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> As usual, excellent work, Hugh. akpm, Linus, please apply. Acked-by: William Irwin <[EMAIL PROTECTED]> -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Thu, Feb 10, 2005 at 05:16:09PM -0800, Greg KH wrote: > > Please, continue this project and encourage distros to switch to it (when > > it exceeds hotplug in functionality and stability). Ubuntu currently is > > trying to reduce boot time, and I bet something like this would factor in > > (even a few seconds helps). > > Thanks for the kind words. > > All distros are trying to reduce boot time. I don't think that the > module autoload time has been fingered as taking any serious ammount of > boot time due to it happening in the background of everything else. Hotplug scripts were identified as one of the major culprits of slow boot when we did the analysis for SuSE 9.2. They took 40+ seconds from the total boot time. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6 ISDN Eicon driver: code cleanups
bincdAai5MuZi.bin Description: Binary data
[rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver
Hi!
I've reimplemented the Lifebook touchscreen driver using libps2 and
input, to make it short and fitting into the kernel drivers.
Please comment on code and test for functionality!
PS.: The driver should register two input devices. It doesn't yet,
since that isn't very straightforward in the psmouse framework.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
[EMAIL PROTECTED], 2005-02-11 21:03:32+01:00, [EMAIL PROTECTED]
input: Fujitsu Lifebook driver, experimental.
Signed-off-by: Vojtech Pavlik <[EMAIL PROTECTED]>
Makefile |2
lifebook.c | 134 +
lifebook.h | 16 ++
psmouse-base.c |6 ++
psmouse.h |1
5 files changed, 157 insertions(+), 2 deletions(-)
diff -Nru a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
--- a/drivers/input/mouse/Makefile 2005-02-11 21:04:00 +01:00
+++ b/drivers/input/mouse/Makefile 2005-02-11 21:04:00 +01:00
@@ -15,4 +15,4 @@
obj-$(CONFIG_MOUSE_HIL)+= hil_ptr.o
obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
-psmouse-objs := psmouse-base.o alps.o logips2pp.o synaptics.o
+psmouse-objs := psmouse-base.o alps.o logips2pp.o synaptics.o lifebook.o
diff -Nru a/drivers/input/mouse/lifebook.c b/drivers/input/mouse/lifebook.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/input/mouse/lifebook.c2005-02-11 21:04:00 +01:00
@@ -0,0 +1,134 @@
+/*
+ * Fujitsu B-series Lifebook PS/2 TouchScreen driver
+ *
+ * Copyright (c) 2005 Vojtech Pavlik <[EMAIL PROTECTED]>
+ *
+ * TouchSceeen detection, absolute mode setting and packet layout is taken from
+ * Harald Hoyer's description of the device.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+#include "psmouse.h"
+#include "lifebook.h"
+
+static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct
pt_regs *regs)
+{
+ unsigned char *packet = psmouse->packet;
+ struct input_dev *dev = >dev;
+
+ if ((psmouse->packet[0] & 0xc8) == 0x08) { /* PS/2 packet */
+ if (psmouse->pktcnt == 3) {
+
+ input_regs(dev, regs);
+ input_report_key(dev, BTN_LEFT,packet[0] & 1);
+ input_report_key(dev, BTN_MIDDLE, (packet[0] >> 2) & 1);
+ input_report_key(dev, BTN_RIGHT, (packet[0] >> 1) & 1);
+ input_report_rel(dev, REL_X, packet[1] ?
+ (int) packet[1] - (int) ((packet[0] << 4) &
0x100) : 0);
+ input_report_rel(dev, REL_Y, packet[2] ?
+ (int) ((packet[0] << 3) & 0x100) - (int)
packet[2] : 0);
+ input_sync(dev);
+
+ return PSMOUSE_FULL_PACKET;
+ }
+ return PSMOUSE_GOOD_DATA;
+ }
+
+ if ((psmouse->packet[0] & 0x0b) == 0x00) { /* Absolute packet */
+ if (psmouse->pktcnt == 3) {
+
+ input_regs(dev, regs);
+ input_report_key(dev, BTN_TOUCH, packet[0] & 4);
+ input_report_rel(dev, ABS_X, ((packet[0] & 0x30) << 4)
| packet[1]);
+ input_report_rel(dev, ABS_Y, ((packet[0] & 0xc0) << 2)
| packet[2]);
+ input_sync(dev);
+
+ return PSMOUSE_FULL_PACKET;
+ }
+ return PSMOUSE_GOOD_DATA;
+ }
+
+ return PSMOUSE_BAD_DATA;
+}
+
+static int lifebook_reconnect(struct psmouse *psmouse)
+{
+ struct ps2dev *ps2dev = >ps2dev;
+ unsigned char param;
+
+ param = 7;
+ if (ps2_command(ps2dev, , PSMOUSE_CMD_SETRES))
+ return -1;
+
+ if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE))
+ return -1;
+
+ return 0;
+}
+
+static void lifebook_disconnect(struct psmouse *psmouse)
+{
+ psmouse_reset(psmouse);
+}
+
+int lifebook_detect(struct psmouse *psmouse, int set_properties)
+{
+ struct ps2dev *ps2dev = >ps2dev;
+ unsigned char param;
+
+/*
+ * This might be a magic knock sequence, or just a part of
+ * a standard mouse init for the mouse behind the screen.
+ * Rate of 40 also seems pretty low, but that's what the
+ * Windows driver supposedly does.
+ */
+
+ if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_SETSCALE11))
+ return -1;
+
+ param = 40;
+ if (ps2_command(ps2dev, , PSMOUSE_CMD_SETRATE))
+ return -1;
+
+ param = 3;
+ if (ps2_command(ps2dev, , PSMOUSE_CMD_SETRES))
+ return -1;
+
+/*
+ * This should fail on normal mice, SETRES only accepts
+ * values from 0 to 3.
+ */
+
+ param = 7;
+ if (ps2_command(ps2dev, , PSMOUSE_CMD_SETRES))
+ return -1;
+
+ if
Re: 2.6.11-rc3-mm2
On Fri, Feb 11, 2005 at 06:49:05PM +0100, Ingo Molnar wrote: > > * Matt Mackall <[EMAIL PROTECTED]> wrote: > > > > > Yes. There's also the whole soft limit thing. > > > > > > i'm curious, how does this 'per-app' rlimit thing work? If a user has > > > jackd installed and runs it from X unprivileged, how does it get the > > > elevated rlimit? > > > > It needs a setuid launcher. It would be nice to be able to elevate the > > rlimits of running processes but the API doesn't exist yet. > > With a setuid launcher you need _zero_ kernel help to get SCHED_FIFO: if > you have a launcher then already today it can just give SCHED_FIFO to > jackd and be done with it! I'm sure you know all this already but I'll spell it out so we're all clear: a) rlimits are tracked per-process so they're fundamentally per-process b) there are hard and soft limits, with soft always <= hard c) only root can raise hard rlimits, but normal users can lower them d) if a user owns a process, he can gain the privileges of that process by various means, so in the strict sense per-process privileges are meaningless - all privileges are per-uid e) so we either need to segregate all privileged processes into separate uid domains f) or we're assuming non-malicious users and soft limits are sufficient. Now I suspect we don't want to insist people do (e) (though I'd certainly encourage them to try). Don't forget that the rlimits approach allows us to reserve the highest priorities for root. I'm pretty sure an effective watchdog policy can thus be implemented in userspace, which RT-LSM can't really offer. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] general split_vma hugetlb fix
My recent do_munmap hugetlb fix has proved inadequate. There are
other places (madvise, mbind, mlock, mprotect) where split_vma is
called. Only mprotect excludes a hugetlb vma: the others are in
danger of splitting at a misaligned address, causing later BUGs.
So move the ~HPAGE_MASK check from do_munmap to split_vma itself;
and fix up those places (madvise and mlock) which expect split_vma
can fail only with -ENOMEM, and wish to convert that to -EAGAIN.
(It appears genuine that some of these syscalls should be failing
with -ENOMEM and some with -EAGAIN, so respect those behaviours.)
madvise_dontneed doesn't use split_vma, but is equally in danger
of causing a hugetlb BUG via zap_page_range. Whereas elsewhere the
patch is permissive (allowing the operation on a hugetlb vma even when
pointless, so long as it doesn't missplit it), here we must use -EINVAL
on any hugetlb vma, since a page fault would hit the BUG in its nopage.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
--- 2.6.11-rc3-bk8/mm/madvise.c 2004-12-24 21:36:31.0 +
+++ linux/mm/madvise.c 2005-02-11 19:07:35.0 +
@@ -8,7 +8,7 @@
#include
#include
#include
-
+#include
/*
* We can potentially split a vm area into separate
@@ -18,18 +18,18 @@ static long madvise_behavior(struct vm_a
unsigned long end, int behavior)
{
struct mm_struct * mm = vma->vm_mm;
- int error;
+ int error = 0;
if (start != vma->vm_start) {
error = split_vma(mm, vma, start, 1);
if (error)
- return -EAGAIN;
+ goto out;
}
if (end != vma->vm_end) {
error = split_vma(mm, vma, end, 0);
if (error)
- return -EAGAIN;
+ goto out;
}
/*
@@ -48,7 +48,10 @@ static long madvise_behavior(struct vm_a
break;
}
- return 0;
+out:
+ if (error == -ENOMEM)
+ error = -EAGAIN;
+ return error;
}
/*
@@ -94,7 +97,7 @@ static long madvise_willneed(struct vm_a
static long madvise_dontneed(struct vm_area_struct * vma,
unsigned long start, unsigned long end)
{
- if (vma->vm_flags & VM_LOCKED)
+ if ((vma->vm_flags & VM_LOCKED) || is_vm_hugetlb_page(vma))
return -EINVAL;
if (unlikely(vma->vm_flags & VM_NONLINEAR)) {
--- 2.6.11-rc3-bk8/mm/mlock.c 2005-02-03 09:06:16.0 +
+++ linux/mm/mlock.c2005-02-11 19:07:35.0 +
@@ -21,17 +21,15 @@ static int mlock_fixup(struct vm_area_st
goto out;
if (start != vma->vm_start) {
- if (split_vma(mm, vma, start, 1)) {
- ret = -EAGAIN;
+ ret = split_vma(mm, vma, start, 1);
+ if (ret)
goto out;
- }
}
if (end != vma->vm_end) {
- if (split_vma(mm, vma, end, 0)) {
- ret = -EAGAIN;
+ ret = split_vma(mm, vma, end, 0);
+ if (ret)
goto out;
- }
}
/*
@@ -53,6 +51,8 @@ static int mlock_fixup(struct vm_area_st
vma->vm_mm->locked_vm -= pages;
out:
+ if (ret == -ENOMEM)
+ ret = -EAGAIN;
return ret;
}
--- 2.6.11-rc3-bk8/mm/mmap.c2005-02-11 15:49:13.0 +
+++ linux/mm/mmap.c 2005-02-11 19:07:35.0 +
@@ -1747,6 +1747,9 @@ int split_vma(struct mm_struct * mm, str
struct mempolicy *pol;
struct vm_area_struct *new;
+ if (is_vm_hugetlb_page(vma) && (addr & ~HPAGE_MASK))
+ return -EINVAL;
+
if (mm->map_count >= sysctl_max_map_count)
return -ENOMEM;
@@ -1821,20 +1824,18 @@ int do_munmap(struct mm_struct *mm, unsi
* places tmp vma above, and higher split_vma places tmp vma below.
*/
if (start > mpnt->vm_start) {
- if (is_vm_hugetlb_page(mpnt) && (start & ~HPAGE_MASK))
- return -EINVAL;
- if (split_vma(mm, mpnt, start, 0))
- return -ENOMEM;
+ int error = split_vma(mm, mpnt, start, 0);
+ if (error)
+ return error;
prev = mpnt;
}
/* Does it split the last one? */
last = find_vma(mm, end);
if (last && end > last->vm_start) {
- if (is_vm_hugetlb_page(last) && (end & ~HPAGE_MASK))
- return -EINVAL;
- if (split_vma(mm, last, end, 1))
- return -ENOMEM;
+ int error = split_vma(mm, last, end, 1);
+ if (error)
+ return error;
}
mpnt = prev? prev->vm_next: mm->mmap;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Re: [ANNOUNCE] hotplug-ng 001 release
Greg KH wrote: I'd like to announce, yet-another-hotplug based userspace project: linux-ng. This collection of code replaces the existing linux-hotplug package with very tiny, compiled executable programs, instead of the existing bash scripts. cpio is running to setup a test partition. But one question: This is yet another package with its own private copy of klibc. Whats the reason behind this non-modular approach? Regards Harri signature.asc Description: OpenPGP digital signature
[PATCH] 2.6 ISDN Eicon driver: convert to pci_register_driver
Description:
convert from pci_module_init to pci_register_driver
Signed-off-by: Christophe Lucas <[EMAIL PROTECTED]>
Signed-off-by: Armin Schindler <[EMAIL PROTECTED]>
diff -u linux.orig/drivers/isdn/hardware/eicon/divasmain.c
linux/drivers/isdn/hardware/eicon/divasmain.c
--- linux.orig/drivers/isdn/hardware/eicon/divasmain.c 2005-02-11
17:50:39.0 +0100
+++ linux/drivers/isdn/hardware/eicon/divasmain.c 2005-02-11
20:41:25.398402952 +0100
@@ -1,4 +1,4 @@
-/* $Id: divasmain.c,v 1.55.4.1 2004/05/21 12:15:00 armin Exp $
+/* $Id: divasmain.c,v 1.55.4.6 2005/02/09 19:28:20 armin Exp $
*
* Low level driver for Eicon DIVA Server ISDN cards.
*
@@ -41,7 +41,7 @@
#include "diva_dma.h"
#include "diva_pci.h"
-static char *main_revision = "$Revision: 1.55.4.1 $";
+static char *main_revision = "$Revision: 1.55.4.6 $";
static int major;
@@ -823,7 +823,7 @@
goto out;
}
- if ((ret = pci_module_init(_pci_driver))) {
+ if ((ret = pci_register_driver(_pci_driver))) {
#ifdef MODULE
remove_divas_proc();
divas_unregister_chrdev();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] device-mapper: multipath hardware handler for EMC
> +/* Code borrowed from dm-lsi-rdac by Mike Christie */
Any reason that module isn't submitted?
> + bio->bi_bdev = path->dev->bdev;
> + bio->bi_sector = 0;
> + bio->bi_private = path;
> + bio->bi_end_io = emc_endio;
> +
> + page = alloc_page(GFP_ATOMIC);
> + if (!page) {
> + DMERR("dm-emc: get_failover_bio: alloc_page() failed.");
> + bio_put(bio);
> + return NULL;
> + }
> +
> + if (bio_add_page(bio, page, data_size, 0) != data_size) {
> + DMERR("dm-emc: get_failover_bio: alloc_page() failed.");
> + __free_page(page);
> + bio_put(bio);
> + return NULL;
> + }
> +
> + return bio;
this would benefit from goto unwinding.
> + if (h->short_trespass) {
> + memcpy(page22, short_trespass_pg, data_size);
> + } else {
> + memcpy(page22, long_trespass_pg, data_size);
> + }
memcpy(page22, h->short_trespass ?
short_trespass_pg : long_trespass_pg, data_size);
?
> +static struct emc_handler *alloc_emc_handler(void)
> +{
> + struct emc_handler *h = kmalloc(sizeof(*h), GFP_KERNEL);
> +
> + if (h) {
> + h->lock = SPIN_LOCK_UNLOCKED;
> + }
if (h)
spin_lock_init(>lock);
> +static unsigned emc_err(struct hw_handler *hwh, struct bio *bio)
> +{
> + /* FIXME: Patch from axboe still missing */
it's in -mm now afaik??
> +#if 0
> + int sense;
> +
> + if (bio->bi_error & BIO_SENSE) {
> + sense = bio->bi_error & 0xff; /* sense key / asc / ascq */
> +
> + if (sense == 0x020403) {
please use the sense handling helpers from Doug Gilbert so you can handle
the descriptor sense format aswell. (And make the code a lot clear).
Also please try to use constants instead of magic numbers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Linux Kernel Subversion Howto
On Fri, Feb 11, 2005 at 03:22:34PM -0200, Alexandre Oliva wrote: > On Feb 11, 2005, Jon Smirl <[EMAIL PROTECTED]> wrote: > > > It's not Larry choosing not to have you do the work, you are self > > selecting not to do it because you won't sign the contracts. > > No. We don't want access to the BK software. We want access to the > data that is stored in the repository, that's all. No, you want access to the metadata that BK uses to store the data. It would be nice if you were to stop pretending that access to that data wouldn't teach you anything, we all know that not to be true. All the claims you make that it is your data are as wrong as saying you own the file system metadata when you store a file or the database metadata when you store a record. You don't. You just want it. It's not a smart move for us to give it to you since you have stated that the only good use of a commercial product is to create an open source copy of it. It's pretty clear what you want to do and you keep asking for us to help you and the answer now, and forever, is no, we aren't going to help you create a copy of our product. You or Roman or whoever will say "we aren't trying to create a copy of your product" and that's nonsense. You want a product that stores the data in exactly the same way as BK, that's why you keep asking for the metadata. If you wanted to create your own system you wouldn't care, you already have the CVS tree, it has 96% of the deltas that the BK tree has. 96%. So you are trying to tell us all that you need the last 4% of the deltas so you can create a *different* system than BK? Come on, gimme a break already, you aren't fooling anyone. -- --- Larry McVoylm at bitmover.com http://www.bitkeeper.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm2
On Fri, 2005-02-11 at 11:42 -0800, Matt Mackall wrote: > On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote: > > >RT-LSM introduces architectural problems in the form of bogus API. And > > > > that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't > > introduce *any* API whatsoever - it simply allows software to call > > various existing APIs (mostly from POSIX) and have them not fail as > > result of not being root and/or not running on a capabilities-enabled > > kernel without the required caps. > > The API is the parameters to modprobe or sysfs. > I think you are talking about the API for root to administer it vs. the (lack of) API for apps to use the RT capabilities. I think Paul's point is that we can transparently replace it with something better (IMO the RT rlimit is better) in the future, and the apps don't have to know about it at all. Comparing it to devfs/udev is bogus because those are way, way more complicated. > > >it's implemented as an LSM is meaningless if Redhat and SuSE ship it > > >on by default. > > > > We haven't encouraged anyone to ship anything with it on by default: > > the idea is for the module to be present and usable, not turned on. > > On as in turned on for build in the kernel config and shipped. But I > expect people will eventually actually ship it _on_ with a group > called 'rt' and possibly even put the primary user in there on install > unless you start slapping some big fat warnings on it. (I just noticed > the new Debian installer is putting the primary user in audio, cdrom, > video, etc.) > Sorry, if the distros are so dumb they need a big fat warning to know that this is not a safe thing to enable by default, at least on anything you would ever consider a multiuser system, then they get what they deserve. If they have half a brain they will use the setgid approach that Ingo suggested, and only enable this for apps like JACK and cdrecord that have been farily well audited and can be trusted to use this feature (for example JACK has the internal watchdog to keep a bad client from locking the system). Really it only makes sense for a distro to enable this if the user selects the "low latency desktop" or "multimedia desktop" or whatever install option and makes clear that this profile is NOT suitable for a multiuser system. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC UPDATE PATCH] add wait_event_*_lock() functions and comments
On Fri, Feb 11, 2005 at 01:07:08AM -0600, Al Borchers wrote:
>
>
> On Thursday 10 February 2005 9:39 am, Nishanth Aravamudan wrote:
> >> It came up on IRC that the wait_cond*() functions from
> >> usb/serial/gadget.c could be useful in other parts of the kernel. Does
> >> the following patch make sense towards this?
>
> Sure, if people want to use these.
>
> I did not push them because they seemed a bit "heavy weight",
> but the construct is useful and general.
>
> The docs should explain that the purpose is to wait atomically on
> a complex condition, and that the usage pattern is to hold the
> lock when using the wait_event_* functions or when changing any
> variable that might affect the condition and waking up the waiting
> processes.
How does this patch look? I wasn't sure if macros and DocBook-style
comments played well together, and the names of the macros pretty much
explain what they do :)
Description: The following patch attempts to make the wait_cond*()
functions from usb/serial/gadget.c, which are basically the same
as wait_event*() but with locks, globally available via wait.h. Adds a
comment to explain the usage pattern for all of the wait_event*()
macros.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
--- 2.6.11-rc3-v/include/linux/wait.h 2004-12-24 13:34:57.0 -0800
+++ 2.6.11-rc3/include/linux/wait.h 2005-02-11 11:55:07.0 -0800
@@ -156,6 +156,32 @@ wait_queue_head_t *FASTCALL(bit_waitqueu
#definewake_up_locked(x) __wake_up_locked((x),
TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE)
#define wake_up_interruptible_sync(x) __wake_up_sync((x),TASK_INTERRUPTIBLE,
1)
+/*
+ * The wait_event*() macros wait atomically on @wq for a complex
+ * @condition to become true, thus avoiding the race conditions
+ * associated with the deprecated sleep_on*() family of functions.
+ *
+ * The macros indicate their usage in their name. Unless explicitly
+ * requested to be different, the following defaults are the case:
+ * - no lock needs to be grabbed/released;
+ * - a timeout is not requested, i.e. only @condition being true
+ * will cause the macro to return; and
+ * - the sleep will be in TASK_UNINTERRUPTIBLE, i.e. signals will
+ * be ignored.
+ * If the macro name contains:
+ * lock, then @lock should be held before calling wait_event*().
+ * It is released before sleeping and grabbed after
+ * waking, saving the current IRQ mask in @flags. This lock
+ * should also be held when changing any variables
+ * affecting the condition and when waking up the process.
+ * timeout, then even if @condition is not true, but @timeout
+ * jiffies have passed, the macro will return. The number
+ * of jiffies remaining in the delay will be returned
+ * interruptible, then signals will cause the macro to return
+ * early with a return code of -ERESTARTSYS
+ * exclusive, then current is an exclusive process and must be
+ * selectively woken.
+ */
#define __wait_event(wq, condition)\
do { \
DEFINE_WAIT(__wait);\
@@ -176,6 +202,28 @@ do {
\
__wait_event(wq, condition);\
} while (0)
+#define __wait_event_lock(wq, condition, lock, flags) \
+do { \
+ DEFINE_WAIT(__wait);\
+ \
+ for (;;) { \
+ prepare_to_wait(, &__wait, TASK_UNINTERRUPTIBLE);\
+ if (condition) \
+ break; \
+ spin_unlock_irqrestore(lock, flags);\
+ schedule(); \
+ spin_lock_irqsave(lock, flags); \
+ } \
+ finish_wait(, &__wait); \
+} while (0)
+
+#define wait_event_lock(wq, condition, lock, flags)\
+do { \
+ if (condition) \
+ break; \
+ __wait_event_lock(wq, condition, lock, flags); \
+} while (0)
+
#define __wait_event_timeout(wq, condition, ret) \
do {
Re: [RFC] Linux Kernel Subversion Howto
On Fri, Feb 11, 2005 at 10:56:02AM -0800, none given wrote: > On Fri, February 11, 2005 11:18 am, Larry McVoy said: > >The mails have started flowing in saying "I don't agree with Alexandre > >and please don't pull the plug" so a point of clarification. We have > >no intention of shutting down the BK free product. We are aware that > >there are 10's of thousands of developers in the open source world > >who do not agree with Alexandre's narrow view of things. You're fine, > >we're not taking BK away. I only trying to get Alexandre to see that > >his definition of "help" is somewhat narrow-minded. > > > > Then why don't you stop threatening to take it away every time someone > points out to you that your "help" for free software isn't ideal? Just > can't help yourself? Your cheap shot at Alexandre doesn't change the fact > that you've shown yet again why people who believe in free software should > work to replace BK. Maybe because I'm a little sick and tired of all the "BK is evil" crap without any accompanying "thank your all the good it's done"? If every time someone sent you a bug report on your open source software it started with "this software sucks, and you're a pinko anti-capitalist commy" how long would it be before you stopped giving it away? Don't bother to answer that, I know you are perfect and that you'd keep doing it any way because yours is The One True Way (tm). -- --- Larry McVoylm at bitmover.com http://www.bitkeeper.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix warning in gkc (make gconfig) {Scanned}
Hi,
this patch against 2.6.11-rc3 fixes some warnings about GtkToolButton in gkc
(the GTK Kernel Configurator).
Please apply.
Thanks, Romain.
Signed-off-by: Romain Liévin <[EMAIL PROTECTED]>
[cut here]
diff -Naur linux-2.6.11-rc3/scripts/kconfig/gconf.c
linux/scripts/kconfig/gconf.c
--- linux-2.6.11-rc3/scripts/kconfig/gconf.c2005-02-11 20:41:34.0
+0100
+++ linux/scripts/kconfig/gconf.c 2005-02-11 20:43:23.0 +0100
@@ -222,15 +222,15 @@
switch (view_mode) {
case SINGLE_VIEW:
widget = glade_xml_get_widget(xml, "button4");
- gtk_button_clicked(GTK_BUTTON(widget));
+ g_signal_emit_by_name(widget, "clicked");
break;
case SPLIT_VIEW:
widget = glade_xml_get_widget(xml, "button5");
- gtk_button_clicked(GTK_BUTTON(widget));
+ g_signal_emit_by_name(widget, "clicked");
break;
case FULL_VIEW:
widget = glade_xml_get_widget(xml, "button6");
- gtk_button_clicked(GTK_BUTTON(widget));
+ g_signal_emit_by_name(widget, "clicked");
break;
}
[cut here]
--
Romain Liévin : <[EMAIL PROTECTED]>
Web site : http://www.lievin.net
"Linux, y'a moins bien mais c'est plus cher !"
diff -Naur linux-2.6.11-rc3/scripts/kconfig/gconf.c
linux/scripts/kconfig/gconf.c
--- linux-2.6.11-rc3/scripts/kconfig/gconf.c2005-02-11 20:41:34.0
+0100
+++ linux/scripts/kconfig/gconf.c 2005-02-11 20:43:23.0 +0100
@@ -222,15 +222,15 @@
switch (view_mode) {
case SINGLE_VIEW:
widget = glade_xml_get_widget(xml, "button4");
- gtk_button_clicked(GTK_BUTTON(widget));
+ g_signal_emit_by_name(widget, "clicked");
break;
case SPLIT_VIEW:
widget = glade_xml_get_widget(xml, "button5");
- gtk_button_clicked(GTK_BUTTON(widget));
+ g_signal_emit_by_name(widget, "clicked");
break;
case FULL_VIEW:
widget = glade_xml_get_widget(xml, "button6");
- gtk_button_clicked(GTK_BUTTON(widget));
+ g_signal_emit_by_name(widget, "clicked");
break;
}
Re: 2.6.11-rc3-mm2
On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote: > >RT-LSM introduces architectural problems in the form of bogus API. And > > that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't > introduce *any* API whatsoever - it simply allows software to call > various existing APIs (mostly from POSIX) and have them not fail as > result of not being root and/or not running on a capabilities-enabled > kernel without the required caps. The API is the parameters to modprobe or sysfs. > >it's implemented as an LSM is meaningless if Redhat and SuSE ship it > >on by default. > > We haven't encouraged anyone to ship anything with it on by default: > the idea is for the module to be present and usable, not turned on. On as in turned on for build in the kernel config and shipped. But I expect people will eventually actually ship it _on_ with a group called 'rt' and possibly even put the primary user in there on install unless you start slapping some big fat warnings on it. (I just noticed the new Debian installer is putting the primary user in audio, cdrom, video, etc.) -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb-maintainer] [RFC: 2.6 patch] DVB: possible cleanups
Adrian Bunk wrote: Before I'm getting flamed to death: This patch contains possible cleanups. If parts of this patch conflict with pending changes these parts of my patch have to be dropped. This patch contains the following possible cleanups: - make needlessly global code static - remove the following EXPORT_SYMBOL'ed but unused function: - bt8xx/bt878.c: bt878_find_by_i2c_adap - remove the following unused global functions: - dvb-core/dvb_demux.c: dmx_get_demuxes - dvb-core/dvb_demux.c: dvb_set_crc32 - remove the following unneeded EXPORT_SYMBOL's: - dvb-core/dvb_demux.c: dvb_dmx_swfilter_packet dvb_dmx_swfilter_packet() should remain exported to the public, accessing this directly makes sense for some architectures. Holger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri, Feb 11, 2005 at 12:01:54PM -0700, Erik Andersen wrote: > On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote: > > It's not only pci, but all types of busses need this kind of "coldplug" > > functionality. And yes, I have plans to provide that functionality in > > this package too. > > > > In fact, if anyone looking to contribute some well defined and easy to > > test code... :) > > The pcimodules patch to pciutils does this sortof coldplug device > scanning for pci devices: > http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch Yes, but that uses the modules.pcimap files, which we want to get rid of someday. It also uses the /proc/pci interface instead of sysfs, so it probably doesn't handle machines with pci domains very well... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] i386 io_apic.c: make two variables static
This patch makes two needlessly global variables static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 16 Jan 2005
--- linux-2.6.11-rc1-mm1-full/arch/i386/kernel/io_apic.c.old2005-01-16
04:38:36.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/kernel/io_apic.c2005-01-16
04:38:57.0 +0100
@@ -264,7 +264,7 @@
static int irqbalance_disabled = IRQBALANCE_CHECK_ARCH;
static int physical_balance = 0;
-struct irq_cpu_info {
+static struct irq_cpu_info {
unsigned long * last_irq;
unsigned long * irq_delta;
unsigned long irq;
@@ -286,7 +286,7 @@
#define BALANCED_IRQ_MORE_DELTA(HZ/10)
#define BALANCED_IRQ_LESS_DELTA(HZ)
-long balanced_irq_interval = MAX_BALANCED_IRQ_INTERVAL;
+static long balanced_irq_interval = MAX_BALANCED_IRQ_INTERVAL;
static unsigned long move(int curr_cpu, cpumask_t allowed_mask,
unsigned long now, int direction)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 2.6.11-rc3-mm2] Relay Fork Module
On Fri, Feb 11, 2005 at 04:08:40PM +0100, Guillaume Thouvenin wrote:
> +void kobject_fork(struct kobject *kobj, pid_t parent, pid_t child)
> +{
> +#ifdef CONFIG_KOBJECT_UEVENT
No, provide two different functions. In a header file make it a static
inline function that does nothing if this option is not selected, so as
to make the code just go away, and the call is never made.
> + char *kobj_path = NULL;
> + char *action_string = NULL;
> + char **envp = NULL;
> + char ppid_string[FORK_BUFFER_SIZE];
> + char cpid_string[FORK_BUFFER_SIZE];
> +
> + if (!uevent_sock)
> + return;
> +
> + action_string = action_to_string(KOBJ_FORK);
> + if (!action_string)
> + return;
> +
> + kobj_path = kobject_get_path(kobj, GFP_KERNEL);
> + if (!kobj_path)
> + return;
How is there a path for a kobject that is never registered with sysfs?
I agree with Andrew, why are you using a kobject for this? Have you
looked at the "connector" code that is in the -mm tree? That might be a
better solution for this, and it will be going into the kernel tree
after 2.6.11 is released.
> +EXPORT_SYMBOL(kobject_fork);
EXPORT_SYMBOL_GPL() for something like this please.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] hotplug-ng 001 release
On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote: > It's not only pci, but all types of busses need this kind of "coldplug" > functionality. And yes, I have plans to provide that functionality in > this package too. > > In fact, if anyone looking to contribute some well defined and easy to > test code... :) The pcimodules patch to pciutils does this sortof coldplug device scanning for pci devices: http://www.linuxfromscratch.org/patches/downloads/pciutils/pciutils-2.1.11-pcimodules-1.patch -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] drivers/video/: misc cleanups
This patch contains cleanups under drivers/video/ including:
- make some needlessly global code static
- the following was needlessly EXPORT_SYMBOL'ed:
- fbcon.c: fb_con
- fbmon.c: get_EDID_from_firmware (completely unused)
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/video/cfbfillrect.c| 12 ++--
drivers/video/console/fbcon.c | 26 --
drivers/video/console/fbcon.h |1 -
drivers/video/console/mdacon.c |4 ++--
drivers/video/fbmem.c |4 ++--
drivers/video/fbmon.c | 20 +---
drivers/video/modedb.c |4 ++--
drivers/video/vga16fb.c| 24
include/linux/console.h|1 -
9 files changed, 37 insertions(+), 59 deletions(-)
--- linux-2.6.10-rc2-mm2-full/include/linux/console.h.old 2004-11-21
15:20:38.0 +0100
+++ linux-2.6.10-rc2-mm2-full/include/linux/console.h 2004-11-21
15:20:46.0 +0100
@@ -59,7 +59,6 @@
extern const struct consw *conswitchp;
extern const struct consw dummy_con; /* dummy console buffer */
-extern const struct consw fb_con; /* frame buffer based console */
extern const struct consw vga_con; /* VGA text console */
extern const struct consw newport_con; /* SGI Newport console */
extern const struct consw prom_con;/* SPARC PROM console */
--- linux-2.6.10-rc2-mm2-full/drivers/video/cfbfillrect.c.old 2004-11-21
15:17:46.0 +0100
+++ linux-2.6.10-rc2-mm2-full/drivers/video/cfbfillrect.c 2004-11-21
15:18:53.0 +0100
@@ -119,7 +119,7 @@
* Unaligned 32-bit pattern fill using 32/64-bit memory accesses
*/
-void bitfill32(unsigned long __iomem *dst, int dst_idx, u32 pat, u32 n)
+static void bitfill32(unsigned long __iomem *dst, int dst_idx, u32 pat, u32 n)
{
unsigned long val = pat;
unsigned long first, last;
@@ -178,8 +178,8 @@
* used for the next 32/64-bit word
*/
-void bitfill(unsigned long __iomem *dst, int dst_idx, unsigned long pat, int
left,
-int right, u32 n)
+static void bitfill(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
+ int left, int right, u32 n)
{
unsigned long first, last;
@@ -228,7 +228,7 @@
}
}
-void bitfill32_rev(unsigned long __iomem *dst, int dst_idx, u32 pat, u32 n)
+static void bitfill32_rev(unsigned long __iomem *dst, int dst_idx, u32 pat,
u32 n)
{
unsigned long val = pat, dat;
unsigned long first, last;
@@ -300,8 +300,8 @@
* used for the next 32/64-bit word
*/
-void bitfill_rev(unsigned long __iomem *dst, int dst_idx, unsigned long pat,
int left,
-int right, u32 n)
+static void bitfill_rev(unsigned long __iomem *dst, int dst_idx, unsigned long
pat,
+ int left, int right, u32 n)
{
unsigned long first, last, dat;
--- linux-2.6.10-rc2-mm2-full/drivers/video/console/fbcon.h.old 2004-11-21
15:26:10.0 +0100
+++ linux-2.6.10-rc2-mm2-full/drivers/video/console/fbcon.h 2004-11-21
15:26:19.0 +0100
@@ -155,7 +155,6 @@
#define SCROLL_REDRAW 0x004
#define SCROLL_PAN_REDRAW 0x005
-extern int fb_console_init(void);
#ifdef CONFIG_FB_TILEBLITTING
extern void fbcon_set_tileops(struct vc_data *vc, struct fb_info *info,
struct display *p, struct fbcon_ops *ops);
--- linux-2.6.10-rc2-mm2-full/drivers/video/console/fbcon.c.old 2004-11-21
15:19:18.0 +0100
+++ linux-2.6.10-rc2-mm2-full/drivers/video/console/fbcon.c 2004-11-21
15:54:54.0 +0100
@@ -107,15 +107,15 @@
};
struct display fb_display[MAX_NR_CONSOLES];
-signed char con2fb_map[MAX_NR_CONSOLES];
-signed char con2fb_map_boot[MAX_NR_CONSOLES];
+static signed char con2fb_map[MAX_NR_CONSOLES];
+static signed char con2fb_map_boot[MAX_NR_CONSOLES];
static int logo_height;
static int logo_lines;
/* logo_shown is an index to vc_cons when >= 0; otherwise follows FBCON_LOGO
enums. */
static int logo_shown = FBCON_LOGO_CANSHOW;
/* Software scrollback */
-int fbcon_softback_size = 32768;
+static int fbcon_softback_size = 32768;
static unsigned long softback_buf, softback_curr;
static unsigned long softback_in;
static unsigned long softback_top, softback_end;
@@ -130,6 +130,8 @@
/* current fb_info */
static int info_idx = -1;
+static const struct consw fb_con;
+
#define CM_SOFTBACK(8)
#define advance_row(p, delta) (unsigned short *)((unsigned long)(p) + (delta)
* vc->vc_size_row)
@@ -305,7 +307,8 @@
mod_timer(>cursor_timer, jiffies + HZ/5);
}
-int __init fb_console_setup(char *this_opt)
+#ifndef MODULE
+static int __init fb_console_setup(char *this_opt)
{
char *options;
int i, j;
@@ -359,6 +362,7 @@
}
__setup("fbcon=", fb_console_setup);
+#endif
static int search_fb_in_map(int idx)
{
@@ -1114,7 +1118,7 @@
static int scrollback_max = 0;
static int scrollback_current = 0;
-int
[2.6 patch] i386/x86_64: mpparse.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 16 Jan 2005
arch/i386/kernel/mpparse.c |4 ++--
arch/x86_64/kernel/mpparse.c |4 ++--
include/asm-i386/mpspec.h|1 -
include/asm-x86_64/mpspec.h |1 -
4 files changed, 4 insertions(+), 6 deletions(-)
--- linux-2.6.11-rc1-mm1-full/include/asm-i386/mpspec.h.old 2005-01-16
04:40:50.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/asm-i386/mpspec.h 2005-01-16
04:40:59.0 +0100
@@ -22,7 +22,6 @@
extern struct mpc_config_intsrc mp_irqs [MAX_IRQ_SOURCES];
extern int mpc_default_type;
extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
-extern int mp_current_pci_id;
extern unsigned long mp_lapic_addr;
extern int pic_mode;
extern int using_apic_timer;
--- linux-2.6.11-rc1-mm1-full/include/asm-x86_64/mpspec.h.old 2005-01-16
04:41:07.0 +0100
+++ linux-2.6.11-rc1-mm1-full/include/asm-x86_64/mpspec.h 2005-01-16
04:41:11.0 +0100
@@ -176,7 +176,6 @@
extern int mp_irq_entries;
extern struct mpc_config_intsrc mp_irqs [MAX_IRQ_SOURCES];
extern int mpc_default_type;
-extern int mp_current_pci_id;
extern unsigned long mp_lapic_addr;
extern int pic_mode;
--- linux-2.6.11-rc1-mm1-full/arch/i386/kernel/mpparse.c.old2005-01-16
04:41:18.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/kernel/mpparse.c2005-01-16
04:42:20.0 +0100
@@ -49,7 +49,7 @@
int mp_bus_id_to_local [MAX_MP_BUSSES];
int quad_local_to_mp_bus_id [NR_CPUS/4][4];
int mp_bus_id_to_pci_bus [MAX_MP_BUSSES] = { [0 ... MAX_MP_BUSSES-1] = -1 };
-int mp_current_pci_id;
+static int mp_current_pci_id;
/* I/O APIC entries */
struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
@@ -863,7 +863,7 @@
#define MP_ISA_BUS 0
#define MP_MAX_IOAPIC_PIN 127
-struct mp_ioapic_routing {
+static struct mp_ioapic_routing {
int apic_id;
int gsi_base;
int gsi_end;
--- linux-2.6.11-rc1-mm1-full/arch/x86_64/kernel/mpparse.c.old 2005-01-16
04:41:36.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/x86_64/kernel/mpparse.c 2005-01-16
04:42:24.0 +0100
@@ -46,7 +46,7 @@
int mp_bus_id_to_pci_bus [MAX_MP_BUSSES] = { [0 ... MAX_MP_BUSSES-1] = -1 };
cpumask_t pci_bus_to_cpumask [256] = { [0 ... 255] = CPU_MASK_ALL };
-int mp_current_pci_id = 0;
+static int mp_current_pci_id = 0;
/* I/O APIC entries */
struct mpc_config_ioapic mp_ioapics[MAX_IO_APICS];
@@ -708,7 +708,7 @@
#define MP_ISA_BUS 0
#define MP_MAX_IOAPIC_PIN 127
-struct mp_ioapic_routing {
+static struct mp_ioapic_routing {
int apic_id;
int gsi_start;
int gsi_end;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] i386 quirks.c: make a function static
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 16 Jan 2005
--- linux-2.6.11-rc1-mm1-full/arch/i386/kernel/quirks.c.old 2005-01-16
04:42:55.0 +0100
+++ linux-2.6.11-rc1-mm1-full/arch/i386/kernel/quirks.c 2005-01-16
04:43:39.0 +0100
@@ -7,7 +7,7 @@
#if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
-void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
+static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
{
u8 config, rev;
u32 word;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
